プログラマの思索

ソフトウェア開発は打ち合わせ駆動開発だ、と思う。
WF型開発でも、アジャイル開発でも、同じように思える。
以下、ラフなメモ。

たとえば、一般的なWF型開発では、各工程の終了ゲートでは、顧客やステアリングコミッティの承認を得るための会議を開いて、そこを通過するのを目的とする。
その会議のために、プロジェクトマネージャはパワポの資料をわんさか作成する。
その会議で報告して最終検収するために、メンバーはその会議資料の元ネタとなるプログラミングしたシステム、その設計書、テスト仕様書、不具合一覧、リリース手順書などを揃える。

もちろん、設計、開発、テストの各工程では、レビューを通過しなければ、先に進めない。
レビューアが承認する、という儀式が待っている。

一方、アジャイル開発では、各工程のゲートはないが、スプリントプラニングやスプリントデモなどのイベントがある。
それらイベントが、開発チームの行動を制約して、プロジェクトの目的をメンバーに思い出させる。

では、ソフトウェア開発以外のビジネスでは、打ち合わせ駆動のスタイルではないのか？
営業であれば、打ち合わせするよりも、お客様の現場に直行して交渉するほうが大事だ。
受付や店頭販売の人であれば、窓口や店頭でお客様に商品説明するほうが大事だ。
工場の生産現場であれば、打ち合わせよりも実際に生産ラインで組み立てるほうが大事だ。

つまり、普通のビジネスでは、SEやPMのように、1日のスケジュールが打ち合わせで一杯になる、なんてあまりないのではないだろうか。
換言すれば、ソフトウェア開発では、打ち合わせで仕様を詰めたり、アーキテクチャの方針を決める、という創造的な仕事よりも、出来上がった成果物のレビューで完了承認する、とか、作業が遅延していないか進捗確認する場の方が良いのではないか。
とにかく、ソフトウェア開発に関わる人は打ち合わせが多すぎる。
だから、会議室をたくさん用意するほど、どんどん会議室が埋まってしまう症状が見られやすい。

ソフトウェア開発が打ち合わせ駆動開発になりやすい原因は何だろうか？
平鍋さんは、ソフトウェアはコミュニケーションウェアだ、と言われたが、まさに、数多くの伝言ゲームを経て、一つのソフトウェアが作られる。
ソフトウェアは目に見えないものなので、逐一、みんなが額を寄せ合って、プログラムの意図や意味、バグ、アーキテクチャなどを説明しなければ伝わらないのかもしれない。

ソフトウェア開発が打ち合わせ駆動開発になりやすい特徴があるならば、その打ち合わせをもっと有意義なものにすればいい。
PMBOKでも、会議体というコミュニケーション計画は重要なマネジメントの一つ。
アジャイル開発では、故意にイベントを設けて、イベントが開発チームのモチベーションを上げるような仕組みを提供した。

そういう事を考えると、打ち合わせを制するものはソフトウェア開発を制するのかもしれない。