不良システムを作らないプロジェクトの枠組み：ユーザーサイド・プロジェクト推進ガイド（4）（1/2 ページ）

業務システム構築プロジェクトでは、業務部門の理解と協力が不可欠だ。これらの人々にシステム開発の意義、そしてシステムというものの特性などを説明することを省略してはいけない。

不良システムが業務に及ぼす影響を説明する

　システム開発の成功には、上司や業務部門の理解や協力が絶対に必要です（本連載では、プロジェクトチームの上司はITに不明であることを前提にしています）。

　こうした理解・協力を獲得するには、「不良プロジェクトは不良システムを生み、不良システムを使う業務は未来永劫、業務効率の向上など望めない」という主張が効果的です。プロジェクトチームは折に触れ、何度もこの主張を繰り返すべきです。

不良システムは業務を妨害する

　各業務部門にとって不良システム（すなわち、利用するのに我慢を強いるようなシステム）が業務効率の向上に寄与しないことは当然であり、場合によってはトラブルを頻発させるなど業務効率を悪化させることもあります。問題はこれだけにとどまりません。ここから先です。

　業務部門は開発段階よりも実際に使いだしてからの方が、業務やシステムに対して積極的に要望や提案を出します。しかしこの段階になってから、使いやすい便利なシステムに改造したり、新たな業務パターンに適合させたりしようとしても費用が掛かり過ぎてできないのです。ITに縁遠い人には、ソフトウェアの修正は簡単にできるように思われていますが、そうではないことを認識してもらう必要があります。

不良システムは矯正できない

　不良システムは中身が複雑怪奇で、改造の事前調査にも時間がかかりますし、プログラムやデータベースの変更も信じられないぐらい広範囲に及びます。当然、テスト工数も大きくなりますし、ドキュメントの修正も大作業となります。作り込み型情報システムの納得のいかない点としてよくいわれていることに、システムの価格は機能ベースではなくコストベースで決められることが多く、出来の悪いシステムの方がよくできたシステムより値段が高いということがあります。

　値段が高くなるのは、工数の問題だけではありません。ベンダから見ると不良システムの原因には、プロジェクトチームと業務部門を含むユーザー側の能力不足もあります。このようなユーザーの仕事はリスクが高いと評価され、その分は価格へ転嫁されます。仕様の変更が頻発したシステムの改造では、また仕様の変更が頻発するだろうと考えられるのです。また、ベンダにとってそのシステム開発で損失が出ているならば、利益を取り返さなくてはいけません。この分も価格に反映されます。システムが運用状態に入り、検収の済んだベンダは、見積もり競争中の素直なベンダとは違います。

　さらにユーザー側プロジェクトチームにおいても、プロジェクトの費用が予算を大幅にオーバーし費用のやりくりができなくなれば、業務部門から要求があっても対応することはできなくなります。プロジェクト開始当初は、業務部門に対して「使っていく中で不具合が出れば修正していく」と約束していても、「機能要求を検討する際に何もいわなかった業務部門が悪い」とすり替わってしまうかもしれません。プロジェクトチームとしては、全体的に見て何とか効果を出すことができれば幸いとし、個々の業務部門には使いやすく効率が良いとはいえない稼働当初の状態のまま、我慢を強いることになります。

仕事の遅いところは、いつまでたっても仕事が遅い

　業務効率が向上しないということをもう少し深く考えてみてください。トヨタ自動車で注目すべきは、かんばんなどのリーン生産技術よりもその背景にある“改善”する文化であるともいわれています。これは改善の雪崩効果ともいうべきことを指しているのではないかと思えます。

　例えば、1時間の改善作業で1時間の余裕ができたとすれば、次の改善作業にはもともと改善作業時間であった1時間に、余裕としてできた1時間を足して2時間を改善作業に費やすことができます。つまり、改善で生まれた余裕は次の改善作業に充てることで、業務の効率化が加速度的に進みます。

　つまり、「仕事の遅いところはいつまでたっても仕事が遅い、仕事の速いところはさらに仕事が速くなる」のです。

　不良システム──業務の効率向上に寄与しないシステムを使っていると、いつまでたっても仕事が速くなりません。そのシステムを改善すること自体が困難で、いつまでも効率の悪い仕事をしなければならず、改善策を考える時間を作ることができません。優秀なシステムを使って仕事がどんどん加速するライバルに比べると、差が開く一方となります。

　これは一般業務部門だけではなく、システム担当部署にもいえます。出来の悪いシステムに時間を取られていれば、新たな有用な提案などできません。改善を継続する風土は強い企業を作りますが、出来の悪いシステムはその風土作りを阻害するのです。

システム開発にはユーザーサイドにも時間とエネルギーが必要

　そこで、上司や業務部門に対して不良システムの害を述べるとともに、プロジェクトがそのようなシステムを生み出さないように、逆に仕事を加速するようなシステムとするために、できるだけ早い時期に精度の高い機能要求仕様を決定することが必要であることを説明します。

　ユーザーが実施すべき機能要求仕様の検討はシステム開発プロセスの最上流であり、ここが不安定であると開発などの下流工程に大きな悪影響を及ぼします。そうならないようにするためには、上司（場合によってはトップマネジメント）に対してはプロジェクトにはエネルギーと時間が必要であることを理解してもらい、業務部門に対しては、プロジェクトへの協力は片手間ではなく相応のエネルギーと時間を要することを理解してもらうよう働き掛けます。

　協力内容として、「何をどのようにいつごろどうしてほしい」と伝えられればいいのですが、プロジェクトの立ち上げ段階では具体的なところまでは説明できません。しかし、この段階から業務部門に対し、協力の重要性を言及してください。プロジェクト失敗のリスクを減らすことができます。早い段階からしつこくいうことを惜しまないでください。