現役コンサルタントが語る
一方、システム開発を担当したSIに話を聞くと、スケジュールを優先するあまり、個別に行なった各部署へのヒアリングが十分ではなかったのではないかと感じた。もう少し詳しく言えば、発注側から与えられた条件でシステムを開発すればよいという意識が強く、さらによいシステムを実現するための提案が不足していたのではないかということだ。
提案といっても、システムに機能を追加することだけではない。SIはヒアリングをしていく中で、システム化推進派とライン製造との間で温度差を感じたはずであり、両者の溝を埋めなければよい設計はできないということを、多少強い言い方になったとしても言うべきであった。
ただ、SIの言い分にも納得させられることが多かったのも事実である。先に発注側であるA社に話を聞き、そちらの問題点を把握していたので余計にそう感じたのだろう。
システムを開発する側にとって、発注者はあくまでもお客様なわけだが、場合によっては時間を掛けてユーザーを説得することも必要になる。すべてユーザーの指示に従うということが質の高いサービスを提供できるこということではないのである。
現在のシステム開発会社(SI)は、ヒアリングを含むコミュニケーションスキルの重要性を認識し、プロジェクトリーダになるSEには欠かせない要素のひとつとして挙げている。いいシステムを作るためには、開発手法やツールなどに精通することはもちろん、業務の一般的知識やそれぞれの会社特有のやり方を理解するために、発注担当者や関係部署とのコミュニケーションを図ることが強く求められている。
こうして問題点が明らかになったので、解決策を探るべくA社の発注担当者とプロジェクト責任役員、SIの営業とプロジェクトリーダー、そして私の5人で話し合いを行なうことにした。
その席で、まず私がヒアリングを含む調査の中で感じたことを述べた。A社においては、各部署のシステムに対する意識に相当の隔たりがあり、特に重要な役割を果たすライン製造部署にシステム化のメリットや今後の経営方針を理解させていなかった点について明らかにミスであると伝えた。社内体制の不備である。
SIには、設計初期からA社の各部署のシステムに対する温度差を感じていたのなら、時には諫言も必要ではないのかと伝えた。また、開発途中でプロトタイプ版による機能検証も行なわれたのだから、その段階で問題点を明らかにする機会があったことも付け加えた。
問題はここからである。双方にそれぞれ責任があることは理解してもらった。あとは解決策としてこのシステムをどうするのか。作り変えるのか、作り変えるなら費用はどうなるのか。私の出した提案は、まず現在のシステムをもう少し改良して、せめて実用レベルまでに引き上げることが最優先であり、これについてはA社もSIも依存はなかった。今度はA社のすべての部署が協力体制を敷いてくれるとのことで、約1カ月程度で済むだろうということであった。さらにこのシステムを強力な営業支援ツールとしての役割を果たすために、業務改善を含めたシステムの見直しをしていくことになった。これは2次開発という位置付けにして、ある程度の開発費が掛かることをA社にも納得してもらった。
こうしてシステムの手直しを行ない、システムをカットオーバーまで持ち込んだ。その時点で実現している機能だけでも、今までにない営業支援ツールとしての活躍が見込まれたが、会社の更なる発展を実現するべく2次開発の設計に入ったとのことである。
この仕事を通じて再認識したのは、よいシステムを構築するためには、発注側の社内体制の確立ということが極めて重要であるということだ。もし、最初から営業とライン製造との間で意思の疎通が図れていたら、システム開発にかかる無駄な出費は抑えられていただろう。今回に限っては授業料を払って得た教訓である。しかし決して無駄にはならないと思う。
もしあなたがシステムを発注する立場であり、SIに「ユーザー部門から話が聞きにくい」といったことを言われたのなら、そこにシステム開発にあたっての大きな障害が潜んでいると思ったほうがいい。情報システム部とそのほかの部署とで、普段からいいコミュニケーションがとれているかどうか、改めて確認しておこう。
|
|
||||
|
|
|
|
|
|
|
|
||||