最近は開発言語、開発環境、インフラ、フレームワークなど、生産性を向上させるような仕組みがかなり整備され、実際にプログラムを作成する時間はどんどんと短くなっています。至近の例でいえば、.NET Framework 3.5の登場によってVBでもC#でもLINQが使えるようになり、従来なら面倒なコードをこねくり回していた処理が1行で出来てしまうようになりました。
しかし、実際アプリケーションを作成する時間が短くなったかといえば、そんなことはありません。プログラムはあっという間にできるのになぜでしょう？
その原因の一つが「設計が追いつかない」です。厳密に言えば「要件定義」→「概要設計」の部分が全く追いつきません。その為、「詳細設計」以降を見切り発車せざるを得ず、概要設計のレビューの結果、詳細設計にも結局戻り作業が発生するため、単体テストまで終わっても再び修正が入り、工数も膨らみます。
従って、いわゆるウォーターフォールの枠組みの中では、上流と呼ばれる部分がボトルネックとなり、生産性は頭打ちになってしまいます。ここが生産性向上の限界です。
これを何とかするにはどうしたらよいのでしょうか？私がない頭をひねって考えたのは以下の2つです。
- 「要件定義」→「概要設計」→「詳細設計」という流れをやめ、「要件定義」→「機能仕様」とすることにより、概要設計と詳細設計部分の乖離をなくす。
- 「設計」→「プログラミング」→「レビュー」のサイクルを数回回す。（プログラミングには単体テストも含む）
1.については「仕様の書いていない概要設計書」や「コーディング設計書みたいな詳細設計書」ではなく、がるさんも言ってたMECEかつKISSに書かれた「機能仕様」があれば、それでプログラムを作成することは可能だと考えるのです。
ただし、機能仕様作成にもプログラム作成にも相応のスキルは必要とされることが問題です。本来は仕様策定者＝プログラム作成者となるべきですが、大抵のプロジェクトではそうはいきません。コーダレベルのメンバもプロジェクトにはいますし、いなくてはそのメンバ成長も見込めません。
そういったメンバにはやはり先輩（というか相応のスキルを持ったメンバ）がしっかりサポートに着ける体制が必要です。個人的にはペアプロはこういう場合非常に有用でないかなと考えています。（ただ、実行にはまだ移せていません。）
2.についてはいわゆるアジャイルなプロセスがやはり必要かなと感じています。現状は設計とプログラム実装を比べて、設計にかかる時間の割合が大きくなっていて「設計待ち」の状態ができています。ですので、設計の粒度を小さくして段階的に行うようにして、「設計待ち」の時間を短くすることにより、スループットが向上するのではないかと考えました。
ただ、これは「如何に適切な粒度で設計を分けるか」が鍵になり、ある程度こなせるようになるには時間が必要でしょう。また、設計を段階的に行うためにはユーザとの調整が欠かせないでしょうから、政治的な話も出てくるかもしれません。
とりあえず色々と模索してみましたが、なんとかこのボトルネックを回避しなければ、これからの時代システム開発で生き残っていくことはできないでしょう。食いっぱぐれないためにも、今後も個人でできること、できないことを含め、模索を続けていくつもりです。