エンタープライズ

現役コンサルタントが語る

システム開発の落とし穴

2006年2月21日　　文●システムクリエイト代表取締役
田中徹

第3回
SEに求められるコミュニケーションスキル（2/2）

機能の増大で予算オーバーに

　人材活用についての機能を聞いたSEも内容について十分説明を受け、早速システム化に向けての設計作業に取り掛かった。こうしてまとめられた資料を見ると、どういったデータベースを構築し、それをどうやって活用するのかといったところにまで踏み込まれており、さらに各個人からのタイムリーかつ正確なデータ収集が大切になるということをA社に訴えていた。

　少し話がそれてしまうが、システム化が失敗する原因の1つとして、いくら優れた機能を備えていても、元となるデータや情報が十分に蓄積されていないため、宝の持ち腐れになることが挙げられる。その点に設計段階から着目するSEは現在でも少ないといっていい。そういった意味で、データ収集が重要であることをA社に伝えたプロジェクトリーダーのSEに対して、私はさらに「できるSE」という認識を強めた。

　半月ほどしてから人材活用機能を備えた分室・分社常駐社員管理システムの企画提案書ができ上がった。内容については十分であったが、A社を悩ませてしまったのは、見積書に書かれていた金額である。ある程度の開発費は覚悟していたものの、出てきた予算はそれをはるかにオーバーしており、即決できる金額ではなかった。そもそも分室・分社に常駐している社員を管理するためのものであるから、事務処理・経理処理の軽減は多少図れたとしても売上げが伸びるとか、大幅な経費削減になるものではない。攻撃的な経営戦略の発想のもとに立案されたシステムではなく、莫大な金額を掛けられなかったわけだ。

　一方、開発する方は乗り気である。調査段階で提案した内容には満足してもらっている。しかも後から人材活用機能という、大きな追加要求まで舞い込んできたのである。SEにしても決して少なくない時間を掛けており、いまさら縮小されては内心穏やかではないだろう。A社内でも、システム化推進派と見直し派とに分かれているようであった。

コンサルタント開始

　それまで抱えていた業務が一段落したこともあり、私は分室・分社常駐社員管理システムについて相談に乗って欲しいと呼ばれた。それ以前からも情報システム部経由である程度のいきさつは聞いていたので、状況を把握するまでにあまり時間を要しなかった。企画提案書には、データベースを構築する際に必要になると思われるデータの洗い出しや、個人単位の管理方法まで記されており、開発会社が作成した資料はその段階では100点のデキであった。また企画提案書の内容と見積額を比べても妥当な線であり、これだけのスキルをもったSEが見積ったのならスケジュールもうまく行くのではないだろうかと感じた。

　さて、問題はA社が予算をどう捻出するかである。内容は素晴らしいが無いソデは振れないというのでは、話が平行線で終わってしまう。A社も開発会社もなんとかシステム化へ向けて動き出したいという点で一致しているので、解決方法を探るべくA社の代表者と少し話す機会を設けてもらった。

機能追加を想定した分割開発

　A社の代表と話して、改めて分室・分社常駐社員管理システムもそれに組み込ませたい人材活用機能も必要であることが分かった。さらに詳しく話を聞くと、現在分室・分社にいる社員の勤務表は、それぞれのリーダー経由で本社に送られて処理される。そのためタイムラグが発生し、20日締め25日払いの事務処理では、残業代などがひと月遅れで支払われることも多々あったので、これを改善することが第一の目的であり、現場からも強い要望があるということであった。

　ここで私は、システムの機能に対してプライオリティを付ける、つまり重要度別にランク分けし、段階的に開発するよう提言した。現場に望まれており、本部でも必要性を感じている分室・分社常駐社員管理システムを第一優先で開発し、来期もしくは別の予算をとって人材活用機能を盛り込むことにするわけである。分室・分社常駐社員管理システムの主機能と人材活用機能では、データのリンクや共有項目なども多く存在するので、始めから追加機能が分かっている場合は、それを踏まえて一次開発を行なえる。このため、後から開発することとなる人材活用機能の設計は軽減される。また、一次開発を行なっている間に現在までの個人の資格、経験、知識などのデータを収集する期間に充てることもできる。

　A社の希望としては、分室・分社常駐社員管理システムで事務処理の軽減を図り、社員の要望を満たすこととともに、機能の目玉として人材活用を取り込みたかったのだろうが、ここは現実を見てなんとか段階的な開発をすることで納得してもらった。当たり前の解決方法のように思えるが、関係者としてA社を説得するのはかなりの労力を要するものである。A社はトップダウンで経営方針が決まる体質で、社長の強いリーダーシップの元、役員以下従業員全体が業務に取り組んでいるのである。しかし、言い換えれば社長さえ説得できればA社としての方針が決定できるという面もある。説得するにあたって有効材料になったのは、二次開発をあらかじめ想定して一次開発を行なえば設計作業が軽減されるため、それが見積額に反映される（つまり安くなる）という点であった。

顧客の要望をすべて聞くことが正しいとは言えない

　何とかA社の説得が済んだ頃、開発会社のSEと話をする機会があった。その席で私はSEに対し、分割開発の提案をするべきであったと進言した。A社の予算的なことも理解していたはずで、現実的な解決方法は分割して開発するしかなかったはずであると述べた。SEもその点については感じていたそうであるが、A社社長の強い勢いに押されて説得は難しいと感じていたとも漏らした。その気持ちは私も理解できたが、相手の状況に合わせてもっとも有効な提案をするのが真の意味での提案力ではないかと思う。要求されることをすべて受け入れて開発することが妥当ではないと判断されるケースは意外に多い。本当の意味でのコミュニケーションスキルが発揮されるのはこういうケースではないだろうか。

　今回の場合はSEの設計スキルや技術力などが優れていると感じたので、さらにワンランク上のコミュニケーションスキルがあれば、無駄な時間を使わずに済んだのである。

　似たような教訓として、私が開発に携わったプロジェクトでもこんなことがあった。

　機能についてユーザからヒアリングしているとき、さまざまなケースを想定して処理するように要求があった。実際の事務処理に則しているのでもっともな話である。ただし、そのおかげで非常にレアなケースまで組み込むことになったので開発するプログラム本数がかなり増大しそうな雰囲気だった。

　実際の業務担当者に話を聞いたところ、「こんなケースはあり得ないとは言えないが、あったとしても数年に1回起こるかどうか…」ということであった。プログラムの簡単な付け足しで片付けられる場合は問題ないが、開発に要する工数がかかってしまうようなら、システムでの処理から除外して手作業による処理でもいいのではないかと思う。たとえば、手作業を含む指示やその後の処理方法などのアナウンスが出る仕組みだけ作っておけば済むなら、その方法も選択の1つである。このプロジェクトでは、数年に1回起こるかどうかの処理をシステムから除外することにより、数百万の軽減になった。

　技術者、とくにプロジェクトをまとめるリーダーに求められるものが技術だけの時代はとうに終わっている。SEにコミュニケーションスキルの必要性が言われて久しいが、真に求められるコミュニケーションスキルとは何なのかを考えさせられた事案である。