各担当の成果物管理が重要
最近のシステム開発は分業が進んでいます。特に大規模な事務システムについては、要件定義からプログラミングまで全体を一つの会社が一括して担当するということは稀でしょう。SIという名の下で、元受SIerが一括して受注したシステム開発案件でも、多くの会社が共同事業体のように開発に参加し、分担してシステムを作ります。
このように、実際の開発に当たっては、一つのシステムはいくつかのサブシステムに分かれ、それぞれのサブシステム毎に開発が行われます。またそのサブシステムの中でも、担当が階層的に分かれる、つまり同じ会社の中で、要件定義とシステム開発、システム開発の中でも仕様書作成とプログラム作成が分かれるということがおこなわれます。
よく、ウォーターフォール型開発といいます、現実の開発は、確かに、決めて、作り、テストして本番という手順の大きな流れだけ見れば滝のようですが、実際のところ華厳の滝や、那智の滝のような美しい滝は存在しなくて、南米イグアスの滝か、富士の白糸の滝のようで、規模によって違うにしろ、一つのシステム開発プロジェクトの中で多くのサブシステム開発（滝）が発生、数多くのシステム開発が有機的につながりながら進むといったものです。そして大きな滝ほど途中で岩にぶつかり荒れ、滝壺は鳴門の渦潮のように渦を巻きます。
さて、滝の話はこれくらいにして、このように、分業の進んだシステム開発、分業せざるをえない大規模開発においては、各担当の成果物管理が大変重要になります。特に、開発のテスト局面では、何時までにどこが完成する、何時どの部分がテスト出来るようになるか、が大変重要な管理事項になるのです。つまり、同期を取った連係プレーが大変重要な管理要素になります。
現物で確認する
パート図のようにサブシステムのつながりを押さえ、テストを効率的に進めませんと、多くのサブシステムにテスト待ちアイドリングが発生し大変なリソースの無駄になります。何時までに出来るということを鵜呑みにして、確認もせずにプロジェクトを進めますと、全体の足を引っ張ることになります。座礁ということになりかねません。仕事は分業で任せても、必ず現物で成果物を確認し進捗管理を行わなければなりません。
また、出来具合も重要です。成果物について連結テストのための納品前提となる個別テストについて、「できた」「一通りやった」…といった口頭での確認だけでは、なにも品質を保証してくれません。「一通りテストしました」、などと言っても、実は、まだテスト残があったり、極端な場合、バグをつぶしている最中であったりすることを経験されているのではないでしょうか。
みんな一所懸命やっていることを否定しません。しかし、プロジェクトを円滑に確実に進めるためにはやはり、現物で確認、完成度を事実でチェックするべきです。労を惜しまず口頭確認を排し、現物で成果物を確認するのです。これを基本動作にすると、確認を受ける側の仕事のレベル、管理のレベルも必ず上がります、もちろん、確認の程度はケースバイケースで浅く、深くしてもかまいません。現物で、やったことを、やった内容を確認することです。そうすることでプロジェクトの破綻リスクは軽減されますし、個々の成果物の品質も上がります。情報公開による会社健全化の効果と同じで、見える化の力はプロジェクトとプロダクトの品質を上げるのです。
