成果物を生み出す作業をイメージする

　成果物がイメージされれば、それを産み出すべく作業をイメージすることはそれ程難しいことではありません。当然、その生成される成果物の内容や構成がイメージされているはずです。もちろん、担当者の作業全体に対する「入力データ」も明らかにされているはずです。

　生成される成果物の内容や構成がイメージされていれば、後はそれを産み出すのに必要な「入力データ」を想定するだけです。つまり、「どのようなデータがあれば、この成果物は作れるのか」という視点です。

　「この機能を実現するソース・コードを生成するためには、どのような内容で、どのように構成されたドキュメント（＝設計書）があればいいのか」という事を考えて、そこに「作業」をイメージします。

　そのような設計書を１冊にまとめるか、機能ごとに分冊するかは、インプリメントをどのように進めるか、あるいはその前のレビューをどのように進めるかという方針にかかってきます。もちろんその時には、“設計書”という成果物をどのようにイメージするかという問題と一緒に解決されていなければなりません。

　こうして、成果物を産み出す作業をイメージしたとき、同時にその作業の「入力」となる前作業の成果物がイメージされることになります。こうして「成果物をイメージ」する行為と、その成果物をうまく産み出す「作業をイメージする行為」が繋がっていきます。基本的にはこれを繰り返してさかのぼって行くことになります。

　その結果、その担当者としての最終成果物を産み出すには、彼に与えられた大元の「入力用の成果物」では不十分なこともあります。その場合は、足りないものを補うような作業を新たに設定するか、その「入力用の成果物」を産み出すことになっている担当者の作業を見直すことになります。

　最初に、「分析」という行為がある程度のレベルで為されていれば、このような事態を招くことは殆どないと思いますが、明確な根拠もなく“適当”に分割した場合には、作業の成果物がイメージされていないことが考えられ、そのような時には、このような“不適格”というチグハグに遭遇する可能性があります。

　また、成果物と作業のイメージを繰り返す過程で、既成の成果物を使うこともあります。その場合、それを産み出す作業は必要ないことは言うまでもありません。ただ、この時点で、そのことに気付かないかも知れません。そのような物の存在に関する情報を持っていなければ、気付かないでしょうが、それでも、後の方で、調整する機会が確保できる可能性はあります。

　一方、これとはちょっと違ったやり方で、最初に全ての成果物をイメージしてしまうことも有効です。私は、要求と状況によっては、全ての成果物を「ドキュメント体系」として、早い段階に想定してしまうことを勧めることがあります。こうすることによって、必要な作業が一機にイメージ出来るのです。

　そして、この後に、それを産み出すための作業を想定するのです。そのとき、ドキュメントの構成パターンが同じであることに気付くこともあり、その結果、幾つかの成果物の「原板」を早い段階に作る作業を想定することが出来ます。

　また、成果物の内容や構成を最初に考えることで、網羅性のチェックが非常に早い段階で可能となります。この方法は、どちらかといえばドキュメントの単位を小さくするという方針を採用したときに勧めています。