メインフレームの場合は、多くは開発環境がCOBOLと決まっているため、ここに挙げたような開発環境に左右される費用変動の要素（開発工数・習得時間・SE単価）を見逃してしまいがちである。部門管理者は、メインフレーム経験者がこれらの重要な費用変動の要素を看過しないように留意する必要がある。

さて、業務パッケージを適用する場合は、そのパッケージについて深い理解が必要であるため、コンサルタントとの協力が必要になる。したがって、後述の人件費の部分はコンサルタント料として余裕を持って見積もる必要がある。

また当然のことだが、業務パッケージは一般の開発ツールに比べて、パッケージに凝縮されたノウハウの分ライセンス料がやや高めであると考えてよい。費用の面から考えると、このことは実質的に要求仕様の実装を外注したのと同じことになるため、この費用を回収するだけの業務改革による効果が見込まれない場合は、決して業務パッケージを導入してはならない。

一般の開発ツールを利用して「業務にシステムを合わせる場合」は、逆に、業務を熟知しているエンドユーザの協力が必要になるが、企業として支出は発生しないので、開発費用の削減効果がある。

また一般の開発ツールは、業務パッケージのアドイン開発環境と正反対に、バージョンを重ねるにしたがって開発効率が向上しているものが多く、開発ノウハウも市販の入門書が大量に出版され、かつ習熟したSEも多いので、上記に挙げた３つのどの点でも開発コストも低く抑えられる。

以上のように、開発環境となる応用ソフトウェアを適切に選択することだけでも、ソフトウェアのライセンス費用と、予測される人件費を低く抑えることができる。逆に言えば、クライアントサーバシステムの開発の場合、開発環境の選択を誤ると開発プロジェクトそのものに大きな禍根を残すことになる。開発環境の選択に当たっては、必ずクライアントサーバベースでの開発経験者が意思決定すべきであり、間違ってもクライアントサーバの経験のないメインフレーム出身者が最終的な決定を下すべきではない。

では次に、人件費の問題について考えてみる。

すでにソフトウェアに関して、一部人件費の問題にも触れたが、これは飽くまで開発環境の選択による「潜在的な」費用効果についてだけである。具体的にどのような人員構成で開発に望むかは、一応これと切り離して考えることができる。

人件費の大きなコストドライバーになるのは、開発期間であることは言うまでもない。開発期間が長引けば、人件費部分が膨らむのは一見自明のようであるけれども、実は、内製化するか外注化するか、という問題と、開発期間の問題は独立した問題である。

つまり、外注化した場合はもちろん開発期間を短くしなければ人件費の総額は削減できない。しかし、外注化して、なおかつ開発期間を短くすることが可能であるかどうか疑ってみる必要がある。

外注化してなおかつ開発期間を短くするためには、外注先を増やすか、外注先をしぼって、外注先一社あたりの依頼工数を引き上げるかのいずれかである。一般に前者の方がリスクが大きいことは自明なので、外注先をしぼることになる。

ここでよく考えてみよう。外注先をしぼることで削減されるのは、発注元の外注管理者の作業だけである。個々の外注先では、より多くのSEやPGを抱えることになるので、外注先のプロジェクト管理者の作業負荷は逆に増大する。つまり、外注先をしぼることは、実際には、プロジェクト管理の負荷を社内から社外に転嫁する効果しか持っていないことになる。これは、外注先の作業負荷を増加させ、外注費を引き上げる結果になるので、「外注先を増やすより、しぼった方が総コストが削減できる」とは必ずしも言えないことになる。

さらにさかのぼって、そもそも外注化することで総コストが削減できるかという問いを立ててみよう。この場合、完成したシステムの運用面も考慮に入れる必要がある。

できることなら100％内製が理想的であるが、システム運用については運用ノウハウの連続性も考えると外注化するのが望ましい。すると、運用を委託する会社をシステム開発の外注先として選択するのが、最適な解でることは容易に理解できる。

それでもまかないきれない開発負荷はどのようにすべきか。ここで初めて、開発期間に関する戦略的な意思決定の必要性が出てくる。

2000年問題にはタイムリミットがあり、開発期間についての大義名分が立てやすい。しかし、このように根拠のない大義名分に依拠してプロジェクトを急き立てることは誰でもできる。プロジェクトを成功に導くための正しい問題意識は「本当にその期間で十分か？」ということであるのに、「いついつまでにやれ」という大義名分が通ってしまう。

大義名分はつまり、管理者が合理的な判断を自ら放棄したという意味だ。本来ならプロジェクトに必要な開発期間を見積もり、その中で最適なコストの計画を立案すべきであるのに、大義名分という不条理によって何ら合理的な根拠もなしに開発期間が決められてしまう。

よく言われることに、これだと思った開発期間の２倍を見積もるべきだ、ということがある。それこそが、企業としての正しいリスクマネージメントである。「ふたを開けてみたら当初の予算の５０％オーバーでした。ごめんなさい」というのはマネージメントではなく、単なる無責任だ。そのためには大義名分をあえて拒絶する勇気を持たねばならない。

例えばメインフレームで2000年問題の一時的な回避策を講じるなどの代替案を用意した上で、本当に効果の出るダウンサイジング計画を十分な時間をかけて立案するなど、リスク回避と同時に企業としてのイノベーションを実行に移す。それこそが英断と言うにふさわしい決断である。

十分な時間があれば、開発工数の大部分を内製化し、外注を運用のアウトソーシング先に限定することができる。開発期間は延びるが、総費用は大幅に削減できるし、メインフレームでの2000年対策によって、リスクも回避できる。

もちろん内製化するためには、期間を限定した人員のシフトなどの対応は必要である。極力情報システム部門内の異動に納め、プロジェクトへ集中的に人的資源を投入する。固定費の増加にはならないので、トップの了解も得やすい。人員シフトのメリットはコスト面だけでなく、異なる業務を経験することによる人材育成の効果としても現れるだろう。

さらに、プロジェクト人員が同じ職場で作業することにより、開発環境が新規に導入したものであっても、相乗効果のために学習効率が飛躍的に伸びる点、問題意識の共有が容易になり、グループとしての意思決定が迅速になる点、汎用性の高い開発環境に関するノウハウを社内に蓄積できる点、などなど、メリットを挙げればきりがない。

以上のように、本当に総開発コストを削減しようと思えば、取れる対策はいくらでもある。簡単にまとめると、まず一般的な開発環境を採用し、開発環境そのものから派生するコストを最小限に抑えること。次に、外注先は運用を委託する会社に絞って、集中的な人員シフトによって極力内製化をすすめ、社外に流出する人件費を抑えること。

ただし、これらの施策を実現するには、何よりマネージメントの能力が問われていることを忘れてはならない。形式的な大義名分を自分の言い訳にすることなく、開発プロジェクトに対して正しい意味でのリスク管理ができるかどうか？結果が出てから「ごめんなさい」するような無責任な発想で着手していないか？すべてはそこにかかっているのだ。