質問: 効率の考え方 「人月の神話」の内容の様な事例は、どうしてitシステムにしか当て嵌まらない(http://techtarget.itmedia.co.jp/tt/news/0611/08/news02.html)のでしょうか?
回答: チーム作業を行えばどんな分野でも、必ず人月神話の現象は起きると思います。そこでリスクを軽減するために、互いに独立な作業に仕事をモジュール化し、チーム編成を行います。モジュール化の理想は、モジュール間でコミュニケーション不要ですが、それは実際上不可能です。というのは、もしそれが可能なら、別々のプロジェクトとして分離すべきだからです。 よってモジュール化の実際上の原則は、モジュール間インターフェイス付モジュールです。インターフェイスとして、モジュールメンバーの一人をモジュール管理者(窓口)として選び、管理者レベルの工程会議を頻繁に行わせます。モジュール管理者は、統括プロジェクトマネージャーに管理されます。ここでの最大の議題は、各モジュールの工期のすり合わせです。よって窓口の責務と、自分のモジュールに対する見識が、非常に重くなります。多くの場合、窓口が手を抜く事で、プロジェクトがよじれます。逆に「全部の窓口」がしっかりしていれば、人月以上の効率は可能ですが、実際上はほとんどあり得ません。 要は、手続き志向の構造化プログラミングであり、時間要素を考慮したウォーターフォール開発の徹底です。現在でも、開発(作業)の進め方は、ウォーターフォールが基本です(他の方法が見当たらないので)。 以上を開発技法として具体化したものが、オブジェクト志向であり、反復型開発であり、アジャイル開発です。世界で最初にこのような思想を実現したのが、トヨタの生産ラインの体制だそうです。アジャイル開発が、小規模プロジェクトでしか使えないなどという話は、迷信です。 以上は考えてみれば当たり前の事ですが、窓口が手を抜くのは、窓口に選ばれるのはたいてい中間管理職であり、現在の技術からは既に遅れているか、現場要員も兼務している事が多いからです。さらに管理職なので、残業代が付かない事も大きいです。自分は現場要員ですが、本音を言うと窓口にはなりたくありません。事の重大さをわかっている人間が、管理者への手を挙げないという事も影響している、という印象を持ちます。 すいません。最後は愚痴になりましたが、「当たり前の事をみんなしない」ので、それを明文化し、ルール化する必要が生じ、isoが出来たと思います。このような動機に基づいて生まれたisoのマニュアルを読んでみるとわかりますが、オブジェクト志向,反復型・アジャイル開発の雛形のようになっていて、それらを実現するチーム編成を指示しています。