なぜシステムが運用に乗らないのか

システム開発者のスキル

依頼主の意向を直接聞けるポジションにプログラマーがいない

仕事自体が直請けではなく、実際に開発する会社が2次、3次請けとなっているケースが多く、 本当の依頼主の声が届かないところで開発を行っている。

システムコンサルタントや設計を行う担当と、実際にコーディング（プログラミング）する担当が分かれているのがほとんどで、 システム必要性の根拠から、システムポリシーや用途、目的までをきちんと把握してコーディングしている開発者は少ない。

実際にコーディングできないシステムエンジニアが設計をする

おおよそ設計を担当している者は、過去にプログラミングをした経験を持つ者が多いが、今は自分で組んでいないというのがほとんどである。 この場合、最先端の技術論も雑誌や人の話の受け売りで、机上の空論的設計となり、実際の開発で生ずる問題や危険性等を認識できていない場合が多い。

成長のないまま、ただ年数だけを重ねている

１つのプロジェクトを終える（納品する）とすぐに次のプロジェクトへ参加させられる為、ほとんどの場合、自分の仕事の結果を知らないままでいる。 つまりそれが成功だったか、失敗だったか、その後どういう問題が起きたかなどを知ることなく、自分のやり方が正しいと勝手に思い込んでいる。

トータル的な視野を持っていない

１つのシステムは通常、販売管理、財務管理、生産工程管理等、管理業務が相互に関連しながら構成されている。当然開発者は、これらの知識も すべて十分に持っていることが望ましいのだが、すべてを深く知ることは非常に難しい。 また依頼主の経営方針や、管理職の管理方針、オペレータのスキルや資質、システム管理者の管理方針等も十分考慮しなければなら ない。つまりトータル的な視野が必要になってくるのだが、その必要性を理解して視野拡大に努力をしている開発者は少ない。

依頼主の資質

形の無いものをイメージする難しさと危険

システム開発は形の無いものを形にするという作業なので、依頼主がこれから開発されるシステムを開発者並みにイメージすることは難しい。よって 通常プロトタイプと呼ばれる仮システムイメージで、依頼主に確認をしながらお互いのイメージをすり合わせていく。この作業の重大さを、依頼主によく 理解してもらい、十分な協力を得られるかがシステムを運用にのせる１つの鍵となる。

システム開発は建築工事に例えることができる。

ある依頼主が１０階建てのビルを発注したとする。提出された図面に目を通すが依頼主も専門外でよく分からないまま工事を開始させたとする。工事も順調に進み５階まで工事したところで、 依頼主がやっぱり15階建てにしたいと言い出したとする。この場合、ビルの土台や骨格が15階建ての重さに耐久できない為、またすべて取り壊し土台から工事をやり直さなければならないだろう。 その結果膨大な時間とお金をロスすることになる。正にシステムも同じで１度構築したシステムの根幹を修正しなければならないとしたら、それはシステムの作り直しと同義語であると考えた方がよい。

慣れと固定概念

依頼主が「今までこうやってきたから」とか「自分の会社のことは自分が一番よく分かっている」という姿勢では、今まで使っていたシステムより良い システムはできない。少なくともシステムの限界を知っているのは、開発者であるということを依頼主によく理解してもらい、開発者が依頼者の業務を できる限り把握できるように協力を得られるようになっていなければ良いシステムを開発することは難しい。

こんな話がある。

ある大金持ちの男が、およそ＄50Million（50億円以上）の大金をかけて豪邸を作った。 そこには100台以上の駐車場と、地下には世界で最先端のシアターがあり、各部屋には自動で音楽が流れたり、高速回線がはりめぐらされている。工事にかかわったのは実に、300人の作業員と100人の電気工事士たちだった。 男は当初独り者で＄10Millionぐらいの予定だったが、工事途中で細かい要望が増え、さらには結婚して奥さんの意見も入り、なんと工事完了まで実に7年もかかったのだった。そして完成した豪邸に寝室はなぜか２つのみ‥‥。 子供ができたのに子供部屋がなく、家全体が完全にシステム化された作りで、それから部屋を作るのがすごい作業だったとか。

依頼者の「自分が今必要なものは自分が良く分かっている」という過信が、将来の拡張性を見据える目を曇らしてしまった一つの例です。