[勉]アジャイル開発？

家にいる時間が多くなるので、知らないことを調べたり、新しく調べ直したりしよう、というシリーズ。
初回は「アジャイル開発」。

---

実録・KDDI ゼロからのアジャイル開発 - ［1］「うちにアジャイルは無理」、既存の社内常識を打ち破る：ITpro

開発工程の変更は、開発側が苦労するよりも先に、体制側が受け入れられるかどうかが課題になる。
まあ、仕事を増やすのは誰でも嫌だからねぇ。
ISOとかで手続きを標準化して文書化しないといかんので、仕事が増えるどころの騒ぎではないのかもしれない。
私もほとんどのところでウォーターフォール開発しかやったことがない。

上記のリンク先では、まずどうやってアジャイル開発を始められるようになったか、ということが書いてあった。
まだ1回目なのだが、実体験の話は面白い。
社内決済とか、契約の変更とかは、アジャイル開発どうのこうのよりも既存手続きのことだから、どうやって乗り越えたのかというのは興味深い。

---

成功するアジャイル、失敗するアジャイル - 10分で分かるアジャイル開発の基本：ITpro

読むだけなら10分で終わるかもしれないが、10分でわかるかというと難しいな・・・。

言葉がいっぱい出てくるが、「アジャイル宣言」というのが目を引いた。
原本はこちららしい。
アジャイルソフトウェア開発宣言

• プロセスやツールよりも個人と対話
• 包括的なドキュメントよりも動くソフトウェア
• 契約交渉よりも顧客との協調
• 計画に従うよりも変化への対応

アンダーラインを付けたところが「価値」で、左側の価値は認めるが右側の価値に重きを置く、というのがアジャイル宣言の価値とのこと。
開発手法とかは、この価値を考えながら作った手法なのだろう。
この宣言に至った考えは、こちらに（短いので読みやすい）。
アジャイル宣言の背後にある原則

3番目の「契約交渉」と「顧客との協調」が同じレベルに書かれているところが、どう読んでよいのか迷う。
原文だとわかりやすいかと思ったが、「Customer collaboration over contract negotiation」で、同じだった。
どちらも「落としどころを見つける」みたいな読み方をしたけど、そうじゃないよな。
アジャイルの基本原則と価値 (Jeff Sutherland 著)
Microsoftのページによいのがあった（機械訳だけど）。
うーん、お客さんには契約の時だけ参加してもらうんじゃなくて、開発っていう作業も協調してやってもらおう、ということかな。
もちろん、コーディングしてもらうとかじゃなくて、変化に対応するためにも、動くソフトウェアを作ってリリースして実際に動かしてもらうとか、そういうことだろうか。

 

ざっと見ると、うん、右側の価値は認めるけど、左側の価値で動いてるな、という印象だ。
だって、仕事のベースが「納品」で、そこにはをふとウェアもあるけどドキュメントもあり、もちろん納期もある。
だから自然と左側に価値を置く生活になってしまう。

いつもながら「仕様変更」がやってきて、それに対してリスケジュールが発生する（発生させてもらえれば、だが）。
だったら、少なくとも宣言の3番目についてはウォーターフォールだろうとなんだろうと起こるし、リスケジュールを認めてほしいという意味では4番目もありだ（ありにしてほしい。。）。

2番目が、ちょっと悩ましい。
動くソフトウェアは大切だけど、ドキュメントもほしいのよね。。
ただ、きっちりした設計書とかよりも、開発しながらあーでもないこーでもないと悩んだときの開発資料がほしい。
だって、きれいな設計書を見ても、「なんでこの仕様がこういう実装になったの？」がわからないときがあるからだ。
いろいろ考えてこうなったのかもしれないし、仕様書が追いついてなくて直ってないだけのときもあるし。
最終的には「実装が正」となるのがほとんどなので、全体の流れと、めんどくさそうなところの説明をしてくれればいい。
まあ、価値が高いというだけなので、いらないということとは別か。
こちらでも、ドキュメントを作らんと勘違いされて迷惑だ、とおっしゃられとる。
- アジャイル勘違い集

1番目は、原則に「フェイス・トゥ・フェイスで話すのが一番伝えるのに効果的」とあるので、そういうことかな。
それに、意欲を高めるというのもあるだろう。
よくわからないルールに縛られて開発するのは、面白くないものだ。
なので、方法や手法を押しつけるよりも、ちゃんと話をしながら進めましょう、という捉え方でよいのかな。

 

そういう読み方をすると、別にウォーターフォールだろうとなんだろうと、あまり変わらない気もする。
変わらないというか、まるっきり直交するものではないかな、という印象だ。
ウォーターフォール＝会社の開発ルール＝とにかくルールを！＝ルールをはみだすと認めんぞ～、みたいな感じになるし、お金が絡んでくると余計にそうなりやすい。
私なんかは現場では一番下の方なので、逆らうこともできないし（文句は言うけど）。。

ただ、この精神に則って開発するとなると、いろんなところに協力してもらわないとできないだろうな、とも思う。
研究開発のようなことをやっていると、結果として同じようなことをやっていると思うので、それを製品開発にまで昇華できればいいんだろうか。

---

今回は、以上です。

調べる前のイメージとしては、早いサイクルで回す開発のことだろう、くらいだったんだけど、どちらかといえば「こういうことに価値を置く」という概念が先にあるということがわかった。
手法の方はまったく調べてないけど、まあ、いいや。

そういえば、アジャイル開発と言えば、なんとなく「ペアプログラミング」というのが思い出される。
それを聞くと、10年くらい前に読んだ本か何かで、「わからないことを教えてもらおうと人に説明しているうちに自分でわかってしまう、という現象があるので、それを応用してクマのぬいぐるみを横に置いて、そのクマに向かって話しかけることで同じような効果が得られる」みたいなのがあった。
そっちじゃないのね。。。