IT (情報技術) 学習記録

主に情報処理技術者試験、オラクルマスター、Linux技術者試験(LPIC)等の、IT系、または電気系の学習記録を中心に。(働き方や世の中も)

悪いスケジュールの引き方、良いスケジュールの引き方 (短納期?そんなモノに何の価値がある?)


悪いスケジュールの引き方、良いスケジュールの引き方 (短納期?そんなモノに何の価値がある?)


IT業界、ソフトウェア開発業界において、古典的な名著がある。

IBMが世界で覇権を握ったメインフレームシステムとそのオペレーティングシステムOS/360を開発した、フレデリック・ブルックスという人が書いた、『人月の神話』である。

日本では、初版が1977年に出版されている。

以降、40年間にも亘って、「ソフトウェア工学のバイブル」と呼ばれている。

この呼ばれ方には、「誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである」という皮肉も含まれているようである。


ブルックスの法則』として、最も有名な言葉は、おそらく下記の言葉であろう。

遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。

人月の神話 - Wikipedia


私は昨年、現職に復帰する前には、三年間もの間、心身の不調により休職してしまっていた。

その休職する直前に関わっていた顧客側の責任者(権限者)が、とにかく暴君であった。

システム開発者側として、きわめて現実的で、かつ、それでも最短期間で完了させるスケジュールを提出した時、たびたび「なんでこんなに期間がかかるんだ!」と騒がれた。

その部下である顧客側の担当者は上司の言いなりなので、話にならない。

仕方なく、無理のあるスケジュールで進める事になる。

しかし、それでも結局は、顧客側の仕様調整が甘かったりして、手戻りが発生し、当初に私が提示したスケジュールと同じか、それよりも遅く進行する事が常であった。

パッケージを導入し、業務もそれに合わせるような割り切りをするならまだしも、基幹系業務システムの開発などにおいて、「短納期化」なんていうものは、ただ単にやるべき作業を省くだけであり後工程にツケが回って、結局は余計に期間がかかるだけで終わってしまうのである。


悪いスケジュールの引き方、良いスケジュールの引き方 その例


ここでは敢えて、「悪いスケジュールの引き方」と、「普通のスケジュールの引き方」と言い換えよう。

下の2つのスケジュールを観て欲しい。


f:id:KF7757:20170708095355g:plain


f:id:KF7757:20170708095422g:plain


ある程度のシステム開発プロジェクトを経験すると、皆、わかることだと思うが、実際には、モノを作ったり書いたりしている時間に比較して、検討したり情報共有したりレビューしたり、といった対人コミュニケーションの方にも、同程度、もしくはそれ以上の時間が必要とされるのである

もちろん、顧客とのレビューなどの調整にも、時間がかかる。

これが、案外、見過ごされがちなのである。


プロジェクトが炎上したときに欲しいものとは


様々な理由により、プロジェクトが炎上か、それに近い状態に陥ってしまった時。

もしも神様から、「『お金、人、時間』のどれか一つだけ与えてやる」と言われたら、何を選択するだろうか。


たいていの場合は、『時間』と答えるのではないだろうか。


現場の人間にとっては『お金』などどうでも良いのだし、『人』をその段階で投入されても、かえって迷惑なのは、前述した『ブルックスの法則』のとおりである。

疲弊しきった現場に必要とされるのは、一息休むための『時間』、休んだ後に課題を一つずつ整理するための『時間』、建て直すための『時間』なのである。

一度、炎上してしまい、ガタガタになってしまったプロジェクトは、立て直しするのにも、相当の時間がかかる。

数カ月、もしくは一年単位の時間が必要な場合もある。

そのくらいの十分な『時間』が確保されて、はじめて『新たな人員を補強しよう』という話ができるようになる。


エライ人には、これがわからんのである。