ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から、というブログ記事を読んで考えたこと。コンウェイの法則の別バージョンとしてこの記事はちょっと面白い。ソフトウェア開発プロジェクトは個別性が高いので、それぞれに適したマネジメントを組み込む必要がある。手抜きの計画や、お仕着せの社内標準WBSを流用すると痛い目に合ってしまう。
そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのＷＢＳをとるか判断するべきなのである。たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。
ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から
ここに書かれている事はその通りだと思う。あまり考えずにWBSを組んでしまうとプロジェクトチーム内に変な力学が働いて思わぬ影響が出たりするので注意が必要。
コンウェイの法則
一応おさらいをしておくと、コンウェイの法則とは「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」というもの。
これは経験則に見えるけれど、この法則は実証されているのが面白い。Windows Vistaのバク発生頻度を分析したところ「バグ密度は担当組織によって決まる」という結論になったそうだ。
実際彼らは、組織構造の指標が、ソフトウェア自体のいかなる属性よりも、ソフトウェアの品質をよりよく示すことを見出しました。もっと簡単に言えば、Vistaの場合、ソフトウェアのある部分にバグがあるかどうかを知りたければ、その部分を書いた人たちがどのように組織化されていたかを見る方が、コードを見るよりもよく分かる、ということなのです!
Making Software ―エビデンスが変えるソフトウェア開発 11章 コンウェイの法則の系
プロジェクト組織も変化する
話を戻すと、プロジェクト内の組織構造はやはり多かれ少なかれ構築対象のソフトウェアに影響を与えてしまう。そして、組織構造は固定的なものではないので、放っておくとプロセスの影響で歪んでしまうのだ。
- WBSはプロジェクトの進捗状況を可視化するツールとしてはいいのだけれども、個別タスクの進捗を上げることを強く意識させてしまう。気をつけないとメンバーはWBS上の進捗を(とにかく)上げることに注力してしまい、変な最適化が行われていく。結果として組織が意図した形を離れて歪んでいく。
- 前述の例では、WBSが組織を形作り、この組織がプロセスに影響していく。おそらくプロセスが品質を形作るので、大なり小なり品質にも影響を与えることになるのだろうと思う。
- 組織の統制を厳しくして（チーム以外のメンバーとは話しちゃだめ！）も、結局はゲリラ的な非公式組織が出来上がったりする。それでも品質などに問題が無ければいいが、非公式チームの決定内容が間違っていたりすると目も当てられない。
組織は盆栽のようなもので、状況の変化や時間の経過で変化するものなのだ。だから時々枝振りを整えてあげる必要がある。個人的にはメンバーを集めて「現状の組織の問題」などについて話し合って、改善していくようなことを定期的にやっていくのが好みだったりする。
