最近はＣＭＭ（特にレベル１から２への取り組み）に関連した話しをする機会が多くなりました。当然、その中で「追跡に耐えられるスケジュール」を書くことを求めることになりますが、開発現場の人たちの強い抵抗を受けるのもこの部分です。どうやらソフトウェアの開発組織の大半で、まともなプロジェクトの開発スケジュールが書かれていないようです。このことは、私のホームページの読者から寄せれる多くのメールからも読み取れます。
開発の当事者自身、今現在、そこで書かれているような「スケジュール」で、プロジェクトが上手く運ぶとは思っていません。少なくとも、「これで予定通りにプロジェクトを完成させることができる」と主張する人は居ません。確かに、プロジェクトの進行中に「予期しなかった」ことは発生しまが、それは２ヶ月前には予期できなかったかも知れませんが、２週間前には予期できたことかもしれません。
実際、適切なスケジュールの書き方と、それに基づく細かな追跡によって、「予期しなかったこと」は大きく減少しますし、発生したときも、遅れを少なくするための代案を考え出すのが容易になります。
では、なぜこのようなスケジュールの書き方を考えださないのか。あるいは探しださないのか。
答えは簡単です。それを書くことを“強く”求められていないからです。そこで求められているのは、単なる“結果”だけです。「１２月２５日に仕上げる」という結果だけが求められているのであって、そこに至るための「プロセス」は放任されています。「放任」であって「任されて」はいないのです。問われていないのです。いや、何を問えばいいのか分かっていないのです。
残念ながら、予定通り（の範囲内）に仕上げるための適切な「プロセス」を持たない限り、プロジェクトは予定通りには進みません。にもかかわらず、その適切な「プロセス」が求められていないのです。その結果、予定を外すことになった「事象」は、すべて「不可抗力」として片付けられてしまうことになります。そして、実際にそれが認められるのです。初めての「不可抗力」が認められるのはいいとしても、そのとき、適切な対策が求められていません。「今後、このような事が起きないように注意します」− 精々、この程度の「約束」が交わされるだけです。
なぜ、誰が見ても、上手く行きそうなスケジュールが“強く”求められないのかというと、それは、その組織（事業部などを含む）や企業自体が「計画」を持っていないからでしょう。本来、企業には「事業計画」というものがあります。ただ、多くの組織にあるのは、「次年度の事業計画」であって、それは意地悪な言い方をすれば、次年度の「予算消化計画」という性質をもったものであって、５年１０年後の計画が作られていることは少ないでしょう。たとえ書かれていたとしても、そこに至るための「現実的なプロセス」まで考えられているケースは少ないでしょう。
本来、企業の「事業計画」というのは、納期限の時点での企業や組織が到達している（べき）状態です。そこでは、製品の「シェア」や「新製品の投入」「サービスの拡大範囲」「利益率」「ＲＯＥ」などの形で到達点が示されているはずです。つまり、「３年後にはシェアを７０％に持っていく」という形で示されているはずです。それは開発プロジェクトで言えば、納期限の時点での、システムの機能や性能の到達すべき状態（すなわち「要求」）と同じ意味を持っています。プロジェクトの開発がまともなスケジュールを持たないままでは、まともに要求を達成しないのと同じように、まともな事業計画なしに、３年後にシェアが「７０％」になっていることはありません。
「まともな事業計画」には、適切なマイルストーンと、そこでの「小目標」、そして「小目標」に到達するための戦略が必要です。勿論、「不可抗力」の発生によって戦術は最初の計画通りに実行されることは稀です。それでも「目標」があることで、別の戦術を考えだし、マイルストーンでのズレを最小にしたり、次のマイルストーンでの挽回策を講じるのです。これが出来るのも、最初に「まともな事業計画」が作られているからです。
もし、組織や企業が、このような「まともな事業計画」を作って、事業の運営を進めているのであれば、あるいは進めていこうというのであれば、その組織の中の、ソフトウェアの開発現場での「いい加減な開発計画」が許される恥ずがないでしょう。「いい加減な開発計画」が存在すること自体、「まともな事業計画」の看板は見せ掛けのものに変わってしまいます。
逆にいえば、「いい加減な開発計画」が放置されていること自体、その組織や企業には「適切な時限」に於ける「目標」（組織や企業としての要求）を持っていないことを意味しています。そこにあるいのは、「のり」を前提とした「単なる旗印」にすぎないということです。ないと困る、あるいは企業や組織として格好がつかないからという動機で書かれた「計画」に過ぎないということです。
実現性の高い、対応能力の高い、まともな開発スケジュールを“強く”求められてないということは、その組織や企業自体が、成り行きで経営されているということになります。もちろん、上級管理者や経営者としては、そのようなつもりは無いと言うでしょう。でも、現場に対して、まともな開発スケジュールを明確に求めていないということは、結果としては同じことです。故意ではないとしても、同じ責任が問われます。
そしてその「責任」の中には、多くのエンジニアが「時代の求める能力を身に付ける機会を得損ねた」責任も含まれることを認識すべきです。