悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
悪いスケジュールの引き方、良いスケジュールの引き方 （短納期？そんなモノに何の価値がある？）
IT業界、ソフトウェア開発業界において、古典的な名著がある。
IBMが世界で覇権を握ったメインフレームシステムとそのオペレーティングシステム、OS/360を開発した、フレデリック・ブルックスという人が書いた、『人月の神話』である。
日本では、初版が1977年に出版されている。
以降、40年間にも亘って、「ソフトウェア工学のバイブル」と呼ばれている。
この呼ばれ方には、「誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである」という皮肉も含まれているようである。
『ブルックスの法則』として、最も有名な言葉は、おそらく下記の言葉であろう。
遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
私は昨年、現職に復帰する前には、三年間もの間、心身の不調により休職してしまっていた。
その休職する直前に関わっていた顧客側の責任者（権限者）が、とにかく暴君であった。
システム開発者側として、きわめて現実的で、かつ、それでも最短期間で完了させるスケジュールを提出した時、たびたび「なんでこんなに期間がかかるんだ！」と騒がれた。
その部下である顧客側の担当者は上司の言いなりなので、話にならない。
仕方なく、無理のあるスケジュールで進める事になる。
しかし、それでも結局は、顧客側の仕様調整が甘かったりして、手戻りが発生し、当初に私が提示したスケジュールと同じか、それよりも遅く進行する事が常であった。
パッケージを導入し、業務もそれに合わせるような割り切りをするならまだしも、基幹系業務システムの開発などにおいて、「短納期化」なんていうものは、ただ単にやるべき作業を省くだけであり、後工程にツケが回って、結局は余計に期間がかかるだけで終わってしまうのである。
悪いスケジュールの引き方、良いスケジュールの引き方 その例
ここでは敢えて、「悪いスケジュールの引き方」と、「普通のスケジュールの引き方」と言い換えよう。
下の2つのスケジュールを観て欲しい。
ある程度のシステム開発プロジェクトを経験すると、皆、わかることだと思うが、実際には、モノを作ったり書いたりしている時間に比較して、検討したり情報共有したりレビューしたり、といった対人コミュニケーションの方にも、同程度、もしくはそれ以上の時間が必要とされるのである。
もちろん、顧客とのレビューなどの調整にも、時間がかかる。
これが、案外、見過ごされがちなのである。
プロジェクトが炎上したときに欲しいものとは
様々な理由により、プロジェクトが炎上か、それに近い状態に陥ってしまった時。
もしも神様から、「『お金、人、時間』のどれか一つだけ与えてやる」と言われたら、何を選択するだろうか。
たいていの場合は、『時間』と答えるのではないだろうか。
現場の人間にとっては『お金』などどうでも良いのだし、『人』をその段階で投入されても、かえって迷惑なのは、前述した『ブルックスの法則』のとおりである。
疲弊しきった現場に必要とされるのは、一息休むための『時間』、休んだ後に課題を一つずつ整理するための『時間』、建て直すための『時間』なのである。
一度、炎上してしまい、ガタガタになってしまったプロジェクトは、立て直しするのにも、相当の時間がかかる。
数カ月、もしくは一年単位の時間が必要な場合もある。
そのくらいの十分な『時間』が確保されて、はじめて『新たな人員を補強しよう』という話ができるようになる。
エライ人には、これがわからんのである。
