作業の「量」をイメージする

　その作業が何時間で出来るものかを判断するためには、その作業の結果として産み出される「成果物」の「量」をイメージする必要があります。「量」がイメージされることによって、「時間」に変換できるのです。経験を積み上げることによって、実は、この２つの間の変換が瞬時に行なわれることになります。もっとも、当人も意識していないかも知れませんね。

　ソフトウェア開発の場合、その要求仕様書から「作業量」を見積もる方法として、

　　●ファンクション・ポイント法
　　●フィーチャー・ポイント法
　　●機能量法
　　●モデル法
　　●経験法
　　●積み上げ法

等があります。ファンクション・ポイント法などは、それなりに奥の深いもので、ここでは紹介しきれませんので、別の機会に譲りますが、それに対して、積み上げ法というのは、比較的取り組みやすく、いろんなケースに応用できますので、ここでは、「積み上げ法」をイメージして、話を進めることにします。

　その作業が、ソースコードを産み出す作業なら、そのコードの行数が一体どれくらいになるのか。その作業がテスト作業なら、テストの項目数を明らかにすることでテストの「量」が分かるでしょう。もっとも、テスト作業の場合は、テストの種類によって費やす時間が変わってくるでしょうから、そこまで正確に把握する必要があるでしょう。

　その作業が、設計書などのドキュメントを生成するものなら、そのドキュメントのページ数がどれくらいになるのか。その作業が、文献を読んでの調査であるなら、その調査の元になる文献のページ数と、その結果として産み出される報告書（の類い）のページ数をイメージすることです。

　このとき、「量」がイメージできないとすれば、その原因は２つ。すなわち、

　　１）初めての作業で想像が付かない
　　２）設定されている作業が“抽象作業”である疑い

です。前者は、誰かに聞いて、自分の産み出す成果物の量がどの程度のものか掴むしかありません。

　これに対して後者の場合は、「量」がイメージ出来る程度まで、設定されている作業をブレークダウンしていきます。ブレークダウンすることによって、抽象作業の中に含まれていた実作業が現れます。あるいは、ドキュメントを産み出す作業の場合は、そのドキュメントの構成を考え、その構成の単位ごとに「量」をイメージしていきます。丁度、「目次」を先に考えるようなものです。

　勿論、最初に考えた目次も、途中で気が変わる可能性は残りますが、それでも、そこで書かれなければならないことは、ある程度、取り掛かる前から明らかなはずです。

　ちなみに、このヘージも、最初に「Ｉｎｄｅｘ」のページが用意されます。その段階で、全体の筋立てが行なわれ、私が言いたいことをどのように展開するかイメージされます。そして、書き進めていくうちに、２、３のページが追加されたり、他のページに統合されたりしますが、「Ｉｎｄｅｘ」を考えた時点で、それぞれの項毎に文字数がイメージされます。全体の文字数をイメージすることは困難ですが、項毎ならイメージ出来ます。

　こうして、作業の「量」を追及していきます。これを怠れば、結局裏付けのないスケジュール、あるいは、“その日までに終わらなければならない”スケジュールのままになってしまいます。いわゆる「ネバナラナイ・スケジュール」です。このようなスケジュールを書いていては、そのうちにスケジュールを書く意味を見失うでしょう。

　なお、ここで割り出した「量」は、詳細スケジュールのどこかに記録しておくと、後で結果（＝実績）が出たときに直に評価できるでしょう。