経営者が交代し、キーパーソンも異動！――山本一郎氏が聞く、ユーザーの体制変更の影響を最小限にとどめる銀の弾はあるのか？：開発残酷物語（7）（2/3 ページ）

トラブルの原因は何だったのか、どうすれば良かったのか。実在する開発会社がリアルに体験した開発失敗事例を基に、より良いプロジェクトの進め方を山本一郎氏が探る本連載。今回は、ユーザーの体制変化が招いた失敗談を紹介します。

[竹内充彦，＠IT]

システム開発プロジェクトに「設計事務所」

　ベンダーは自社のアーキテクチャにこだわり、経営層は先のことを見据え、現場でシステムを使う人たちは目の前の仕事を最優先に考える。そうなれば、どうしても仲立ちして調整する役割が必要になる。

山村圭氏
キューキエンジニアリング 企画グループ グループ長
＠IT エンジニアライフで「Innovation “D”」執筆中

　かつては「現場業務の効率化」を目指したITの導入が多く、現場サイドにとってもシステム導入のメリットが分かりやすかった。しかし近年では「経営判断の迅速化」を目指すものが増えており、そのメリットを現場と共有するのは難しくなりつつある。経営層の現場サイドへの働きかけが、ますます重要となっているのだ。

　頼りになるのは経営層の強い意志と、社内のキーパーソンの熱意だが、企業においては退任や異動という事態が常に起こり得る。空中分解寸前の社内を、後から来た担当者が再びまとめ上げるのは、なかなか難しい。

　トップが替わる、担当者が異動するということは、ままある。それが分かっているだけに、これは偶発的な事故ではなく、ある程度予見して回避できるのではないか？――そのヒントが、同じキューキエンジニアリングが経験したもう一つの事例にあるという。

　「ユーザー企業の人事に左右されず、またベンダーからも独立した第三者が『設計事務所』として介在すれば、システム化の目的や方針をしっかりと受け継いでいくことができます。これは、開発が終わり、運用、保守のフェーズに入っても、きちんと機能します」（山村氏）

　実際に、同社が手掛けた九州電力のケースでは、同社が設計事務所としての役割を果たし、複数ベンダーによるジョイントベンチャープロジェクトを成功させた。九州電力は毎年の定例異動で多くの担当者が変わり、今は発送分離という大きな変革期に差し掛かっているが、運用開始から17年がたった現在も、その目的意識や思想は継承され、システムが成長を続けているという。

　「どう考えても失敗の香りしかしないんですが、成功までこぎ着けたというのは素晴らしいことですね」（山本氏）

　「紆余（うよ）曲折はありましたけど、トップがやり遂げる意志とプロジェクトの意味、意義を何度も繰り返し組織に伝えてくれたんです」（山村氏）

参考記事

山本一郎×細川義洋対談 発注残酷物語：休日返上で頑張ります！→頑張れませんでした――残酷な発注者にならないために、ユーザー企業が押さえるべきポイントとは

「設計事務所」って一体ナニ？

　キューキエンジニアリングが参画した九州電力輸送部門ITシステム開発プロジェクトは、2000年からスタート。同社は「設計事務所」という立場でシステムコンセプトの策定を行うとともに、プロジェクトの統括管理を行ったという。

山本一郎氏
個人投資家／作家。三児の父にして、介護と社会保障とサイバーセキュリティを生業とする。

　「ITのジョイントベンチャーで、間に設計事務所を置くって、あまり例がありませんよね？　キーワードとして新しい感じがします」（山本氏）

　「そうですね。やろうと思っても難しいかもしれません。特に九州電力さんのようなケースでは、通常はグループ内にシステム子会社があり、そこが一次請けという形を取り、そこから大手の開発会社に発注していくというスタイルになりますから」（山村氏）

　設計事務所として独立した第三者が入り込むことは、通常は“ない”という。

　では、なぜ同プロジェクトで、キューキエンジニアリングは「設計事務所」という立場で活躍できたのだろうか？

　「このプロジェクトは電力輸送にかかわる、いわばERPのようなシステムです。これまでは、保全システムや工事システムなどが個別の業務システム――保全システムならA社、工事システムならB社、というように、それぞれに強みを持つベンダーに発注してきました。しかしこのプロジェクトでは、あらゆるシステムが利用する共通データベースを構築するため、1つのベンダーに任せてしまうわけにはいきませんでした」（山村氏）

　ベンダーごとにシステムのアーキテクチャも開発言語も異なっており、ワークステーションを利用したシステムもあれば、PCとVBを利用したシステムもあった。それぞれの業務に必要なデータは、各ベンダーが設計したデータベースに収められ、分散独立して管理されていたという。

　「設備に関する情報があちこちのデータベースにあり、中には更新されていないデータもありました。それらを一元化したいという思いが九州電力側にありました。このプロジェクトは“腐らないデータベースを構築する”というのも目的でした」（山村氏）

　そこで、大手ベンダーから独立していて、設備にも詳しいということで、キューキエンジニアリングに白羽の矢が立ったのだ。

　サーバ、端末、開発言語、ミドルウェアなどの技術選定は、設計事務所である同社が主導的な立場で提案。ちょうどJavaが普及し始めた時期でもあり、システムを全てWebアプリケーションに置き換えたという。

やはり要は「担当者」

　「しかし、実際にシステムを使う現場を説得するのは大変だったでしょう？」（山本氏）

　ユーザー側の社内関係者をいかにプロジェクトに巻き込んでいくかは、ベンダー側からは手が出しにくい領域だ。

　「九州電力側の新しく来られた担当者も、その辺の事情をとてもよく理解されていて、情報システム部門の方たちや現場、管理職、経営層まで巻き込んで、動かしてくださいました」（山村）

　最初は「フィジビリティスタディー（feasibility study＝実行可能性調査）」から始めた。

　データベースのプロフェッショナルを交えながら、「試しにこういうものを使ってみよう」とアイデアを出し合い、プロトタイプを構築。それを使って、現場、管理職、経営層を交え、ブレーンストーミングを繰り返して、システム化の目的を関係者で合意したという。

　「電力会社は設備保全の時代に突入しています。一般的に電力設備は50年でリプレースの時期を迎えますが、高度成長期に作ってきた大量の設備が、いま一斉にリプレース時期を迎えようとしています。低成長、少子高齢化期を迎えた今、それらのリプレースを一気にやろうとすれば破綻は目に見えています。そこで、各部署で取り扱っている設備に関するデータを一元管理し、それらを活用してデータに基づく保全を実現することで、設備のリプレース時期を50年から80年や100年に伸ばし、リプレース工事を均平化しないといけない。そんな危機感を社内で共有できていたことが大きいと思います」（山村氏）

　「これは幸せな事例ですね」との山本氏のつぶやきに、山村氏は「本当にそうだと思います」と、しみじみと答えた。

参考記事

フィジビリティスタディーを使って、トラブルを回避した例：それでも最善を尽くす、それがベンダーの仕事だ――「旭川医大の惨劇」解説その3