今回はシステム内部の開発に絞って話をさせてもらいます。
しかも一番古くからあり、一番良くお目にかかる代表的な開発手法である
ウォーターフォール方式の開発手法から話をさせてもらいます。

ウォーターフォールでの開発で陥り易い落とし穴の一つは、
開発の前半において開発工程毎の成果に目を奪われすぎることです。
例えば基本設計工程では基本設計書に、詳細設計工程では詳細設計書を作り上げること自体に
集中しすぎると言うこと自体が問題なのです。

プログラミング直前までで最も大切なのは、一つ先の工程のイメージを作り上げることです。
ですから基本設計書を作成した暁には担当者の頭の中には
詳細設計のイメージが出来上がっていなければなりません。
つまり「備忘録（またしても器のシミュレーション）」で述べたようなイメージは
最低限固まっていなくてはなりません。
もちろん難しい問題領域を解くシステムの場合には、全てが可能なわけではないですが、
難しいほんの一部のブラックボックスを除き大半は出来上がってなくてはいけません。

詳細設計書またはプログラム設計書のようなものを作り上げる場合も同様です。
プログラム設計書を作成しないような場合、詳細設計書を作り上げた暁には、
頭の中にプログラミングイメージが出来上がっていなくてはなりません。

実際開発をしたことがある人であれば、こんなことは誰でも知っています。
でも、プロジェクトがトラブル際には、これが出来ていないことが多いように思います。
見た目はスケジュール通りに進捗が進んでいるにも関わらず、
実態としては（作業者の頭の中では、と言う意味です。）一工程分スケジュールが遅れているのです。

一工程分スケジュールといえば全体の数十％です。トラブらない方が不自然です。
詳細設計工程またはプログラミング工程になってはじめて
矛盾点または無理が発覚して手戻りが多発するはずです。
「こうすればいい」という見通しのないまま進み、
後になって考え直さなくてはいけない部分が明確になる。
誰が考えてもあたりまえのことだと思います。

ただここで一番難しい点は、実務に精通したリーダしか
工場の生産ラインを視察することが出来ず、
その一工程分の遅れを検知できないことです。
そしてそれを改善、コントロールする権限もリーダにしかないのが常なので．．．

今回は設計書等のドキュメントが大事でないかのような
印象をあたえたかもしれませんが、
ドキュメントはコミュニケーション、そしてメンテナンスのためにも
絶対必要で、それを否定している訳ではありません。
（最後に言い訳でした。）