アジャイルソフトウェア開発

昨年の12月24日の日記に書いたソフトウェア開発の属人性にも関連するが、ソフトウェア開発から属人性を切り離せない理由が間接的にかかれているところを見つけたので引用しておく。以下の文章は序章に書かれている。

完全かつ完結したコミュニケーションは決して存在しない。そのようなことはまったく不可能だ。自分では自分の意図する内容がわかっていたとしても、コミュニケーションの受け手はどこかでギャップを埋めなければいけない。しかも受け手だけで行わなければいけない。
類似した経験があるなら、大きなギャップも埋めることができる。話が苦手でも、ジェスチャでも、うまくできる。
類似した経験がなくなるほど、埋められるギャップは小さくなる。基本的な概念を説明して手助けし、相手が「経験の橋」を構築して何を言おうとしているのかを理解するまで、努力しなければいけない。
この手助けには終わりがない。どんなに手助けしても、理解できない人は必ずいる。
皮肉な実情がある。コンピュータ業界では、仕様書や設計書が、「あたかも」意味する内容を実際に説明できるかのように書いている。説明などできない。要求や設計を完全に特定できると期待することすらできない。
読者は特定のレベルの経験があると仮定する。より多くの経験を仮定すると、記述内容は少なくてよい。仮定できる経験が少なければ、より多くを記述しなければいけない。

実は、この本は年末に読み始めたばかりで、また、途中で別の本に手を出してしまったりして、なんとか序章を読み終えたところだったりする。でも、結構オススメっぽいように思う。
全体のおよそ半分が、コミュニケーションについて書かれている。目次を抜粋して引用する。

序章　導入：未知と伝達不能 1
第1章　創作とコミュニケーションの協調ゲーム 27
第2章　個人 53
第3章　チーム内のコミュニケーションと協調 97
第4章　方法論 151
第5章　アジャイルと自己適応 231
第6章　クリスタル方法論 263

それだけ、ソフトウェア開発ではコミュニケーションが重要だということなんだろう。コミュニケーションというあたりまえのことがうまくいかないと、当然のことだがソフトウェア開発は失敗する。
特に第2章から第3章は興味深い。

第2章　個人 53
2.1　あの愉快な人たち 54
　:
2.3.5　集中とコミュニケーションのサポート 77
2.3.6　性格に合わせたメンバ配置 78
2.3.7　才能 79
　:
第3章　チーム内のコミュニケーションと協調 97
　:
3.3　コミュニティとしてのチーム 132
3.3.1　友好と衝突 135
3.3.2　労働時間内の帰属意識 136
3.3.3　敵対的なXP対友好的なXP 137
3.3.4　勝利のための「チーム」編成 139
3.4　生態系としてのチーム 146

この辺からも、ソフトウェア開発から属人性を切り離すのはいかに困難だってことがうかがえる。