プロジェクトは「アウトプット」ではなく「タスク」で管理したほうがいい

　「プロジェクトマネジメント」なんて言葉がブームとなったのは今は昔。当時は、ブームに乗ってか会社の命令かで、その筋の資格試験の取得に励んだ方もおいででしょう。その後いかがでしょうか？

　やっぱりちゃんと学ぶことが大切！と実感した方が反面、情報処理技術者試験と同じく（？！）「ないよりはまし」程度にしか実感していない方も多いことでしょう。

　ということで、今回は、ある種当たり前の話です。

　プロジェクトが始まると、進捗管理しますよね？　その単位って、何でやってますか？

　何画面中何画面作ったかっていうやり方、やめたほうがいいです。つまりアウトプット（成果物）による管理。

　つくりによっては「一瞬で」終わるような画面もあるわけです。でも、スケジュールの予定には「一瞬」なんて書かないわけですよ。一瞬は、言葉のあやかもしれませんが、それこそ、他の画面は3日かかるのにある画面は3分でできることもあるわけです。それだって、「0.00625人日（1日8時間換算）」なんて書かないわけです。普通だったら書いても「0.1人日」なわけです。つまり、スケジュールが形骸化するわけですね。

　ある画面だけ「一瞬」でできるには、理由があるはずです。たとえば、共通的な振る舞いをする画面が多かったので上手くスーパークラス化できたからとか、ツールをちょっと作ったら仕様書などからいっきに生成できたとか。

　COBOLなんかはコピペ文化ですから、タスク≒アウトプットだったので、アウトプット中心の管理でもほとんど問題ないでしょう。しかし、近代的なプログラミングではそうはなりません。1つのアウトプットに結びつくものが多すぎるのです。なので、「何をするか」で管理したほうがいいのです。

　ときには「○○画面を作る」というようなタスクも現れるでしょう。これはタスク≒アウトプットになります。それはそれでもいいですが「No.01〜No.30の画面を一気に作るツールを作る」というタスクはツールというアウトプットがありこそすれ、旧来型のアウトプット中心の管理とはまた別です。結果として○○画面というアウトプットがあったとしてもそれはスケジュールとはまた別の話ということです。