ミラクルorリピータブル？（解説編）

スキル

» 2010/07/05

　前回は、奇跡のプロジェクトについてサービス工学の視点から見て「何が成功要因だったのか」という分析結果を（かなり端折ってですが）お話しさせていただきました。

　かなり分かりづらい点もあったかと思いますので、今回は「解説編」ということで、解説や解釈を入れながらフォローしていきたい思います。

■背景（顧客、システム、プロジェクトの特色）

　今回の分析結果がすべての「動かないコンピュータ問題」へのサジェスチョンになるかというと、そういうわけではありませんが、もう少し背景を明確化することにより、今回の知見を応用できるプロジェクトがもう少しはっきりとするのではないかと思います。これまでお話ししてきたことと重複する点もあるかと思いますが、お付き合いください。

1．顧客（業種、規模）概要

社会インフラ系設備産業の一部門
利用者数：約2000名

2．システム（背景、IT化のテーマ、目的）概要

　＜背景＞

高度成長時代を終え、設備は建設の時代から維持管理の時代を迎える。そのため、維持管理に必要なデータの整備、技術の向上、業務運営形態にすべく経営革新が必要となった

　＜テーマ＞

「ITを活用した業務改革」

　＜システム＞

対象：設備管理（計画、工事、運用、保全）に関係する業務全般。これまで保全システム、工事システムと個別専用システムを統合し、計画から保全までデータを一元化し、一度作ったデータを次業務へ引き継げるようにした
開発：開発言語は、サーバサイドはJava、DBはOracle、OSはSolaris、ミドルウェアとしてアプリケーションサーバ、ワークフロー、認証、GIS、データ連携などを導入

3．プロジェクト

　＜規模＞

参加企業：顧客企業、開発会社（大手メーカー3社、地場5社、システムベンダ3社）
参加人数：のべ6000人
予算規模：ウン十億円
期間：3年
（フェーズ1）設備DB構築：1年
（フェーズ2）基幹システム構築：1年
（フェーズ3）EUC機能など構築：1年

■OA化とIT化の違い

　本プロジェクトの開始当初、ユーザーから下記のような質問が出ました。

　「これまでのシステム化と何が違うのか？」

　その時の回答は、以下のようなものでした。

　「これまでは、OA化だったけど、今回はIT化だ」

　言葉の綾のようなものですが、回答にはそれなりの理由があります。図1を参考にしていただきたいのですが、ある業務の流れがあり、その中の一部を人間からコンピュータにやらせること。これをOA（Office Automation）化と定義しております。また、業務のすべてはコンピュータに置き換わるわけではないが、業務自体をIT（PCやモバイル、GIS）を使って行うこと、これを業務のIT化と定義しているのです。

参考図1：OA化とIT化の違い

　また「パソコン化」という言葉もありました。顧客企業は古くからコンピュータ活用は進んでいますが、最初の業務システムは電算センターなどでホストを使っておりました。それがワークステーション化され、各事業所でコンピュータを使えるようになりましたが、2～3台を共用で扱う人は限られていました。一方、並行してPCが1人1台支給されてきました。最初はWordやExcelなどオフィスの利用がメインで、業務システムとしてはほとんど使われてなかったのです。今回のシステム開発で、権限の違いはあるものの、すべての業務機能が全社員のPCで可能となったのです。

■本プロジェクトの大きな課題

　これらを踏まえて、後からの振り返りになるのですが、今回のプロジェクトの特色を整理し、そこに関連する課題を洗い出してみました。

＜特色＞

1．経営革新、業務改革のためのシステム

現場から経営者まで（縦の）関係個所が多くなる
業務フローはIT化を踏まえた新しいものでないといけない

2．IT化、PC化

対象業務が多い。また、すべてが自動化されるわけではないので、人間系とコンピュータ系の境界を見極めなければならない
PC化により、これまで専門のユーザー、一部のユーザーを対象とすればよかったが、全社員がユーザーとなる

3．最新技術の活用

開発会社に経験がない。特にパフォーマンス関係は問題になりやすい
異なるベンダのOS、ミドルを連動させないといけないが、実績が少ない

4．大手メーカーのジョイントベンチャー

同じIT業界とはいえ、大手メーカーとなるとそれぞれやり方も違えば文化も違う
業務も多岐にわたるが、開発会社も同様に多岐にわたるので、スター型のコミュニケーションが必要

　＜課題＞

1．ゴール（仕様）が決まらない

経営課題解決のための仕組みだが、現場の人は経営課題が分からない
ITで何ができるのか分からないので、新しい業務フローは作れない
さらに利用者は、経営者から現場までPCを使っている社員全。個々の要望も多くなるし、要望が二律背反を起こす
結果、仕様が決まらない

2．コミュニケーションがとれない

業務範囲が広いので、ユーザーと開発会社との言葉の違いが出てくる
開発会社も複数あるので、責任範疇に隙間が出てくる
経営と現場のギャップ。SEは経営者ではない
結果、周知徹底は難しい

3．技術課題

普通のことをやっている分には問題ない。しかし特殊なこと、ヘビーなこと、他との連携をやろうとすると、問題が出てきて、その問題解決は難しい

■設計事務所が果たした役割

　これも後からの考察になるのですが、上記で挙げさせてもらいました本プロジェクト特有の課題、じつはこの課題にこそ、設計事務所の役割が効いているということが分かりました。

1．ゴール（仕様）を決めるのは設計事務所

仕様を決めるためには、まず経営者から現場まで、関係各所の要望を聞く必要がある。この段階ではまだ開発会社は登場していない。設計事務所が手法を持って遂行
仕様を決める、という事は実は要望を切り捨てる、ということに他ならない。これは社内でも開発会社でも難しい（開発会社は要望を取り入れてコストを上げようと働く）。そこを、第三者として設計事務所が遂行

2．コミュニケーション触媒としての設計事務所

ユーザー－開発会社間、ユーザー－ユーザー間、開発会社－開発会社間、経営－現場間の打ち合わせなどの企画は設計事務所が遂行
業務とシステムの言葉の壁、翻訳については設計事務所が遂行

3．技術方針を決めるのも設計事務所

技術課題を解決するのは開発会社だが、技術採用については設計事務所が遂行
新技術のリスクを見越したスケジューリングは、設計事務所が遂行

Oait

参考図2：設計事務所の役割

■結局、設計事務所とは何なのか

　ここから最も伝えたいことで、でも最もややこしく、伝えることが難しい話をしたいと思います。設計事務所とは何だったのか？という根源的な話です。

　まずは「設計事務所とは、先述の役割に対してノウハウを持つコンサルタント」と考えてみます。しかしその答えは「ノー」でしょう。なぜなら、結果的にその役割を担って、そこが成功要因だったということはできますが、最初からの役割でも、ノウハウを持っていたわけでもありません。もし今後、別のプロジェクトに設計事務所と参画することがあれば、上述の定義が当てはまります。しかしながら、奇跡のプロジェクトでは悲しいかな、胸を張っていえるわけではないのです。

　ここで、この命題を解決するために、「広義の設計事務所」「狭義の設計事務所」という概念を導入しました。

　「狭義の設計事務所」とは、その役割として参画した弊社のことを指します。もう1つ「広義の設計事務所」として、顧客企業のIT担当メンバー、開発会社の統括責任者、そして弊社が参画するチーム（正確には、組織上のチームではなく、会議体、意思決定機関に近い）が存在します。これがこれまで話してきました「設計事務所」の役割を実態として担っており、「狭義の設計事務所」である弊社は、その実行部隊、という位置付けになります。

　ではこの「広義の設計事務所」は何だったのか？

　実は顧客、開発会社、弊社が企業間の壁を取り払い本プロジェクトの目的価値である「ITを活用した業務改革」というテーマを達成すべく推進、意思決定、問題解決を行ってきた機能ということになります。

　得てして、顧客企業がイニシアティブをとってしまうと、業務改革や改善が主体となってITはおざなりとなり、改革改善は進むがシステムは動かない、ということが起こります。逆に開発会社主体であるとシステムを作ることが目的となり、システムはできたが改革改善は進まず経営者の望む成果は出てきません。

　サービス工学的に表現するならば、顧客のRSPである「ITによる業務改革」に作用する機能を顧客IT担当、開発会社、設計事務所が、それぞれの分野で提供し、顧客満足を実現できた、軸がぶれなかったということだと思います。

　中でもミソは、顧客、開発会社、設計事務所が企業の壁を取っ払って知恵を出し合い、問題解決に努めた、ということです。すると化学変化を起こし、新しいアイディアが生まれ、困難に立ち向かっていける。いわゆる「共創」の実現です。

■最後に（後日談）

　実は本事例のプロジェクトは時代的に少し古く（時効を待って紹介しておりますので）、ちょうどプロジェクトが一段落したころに、世間ではいくつかのシステム開発に関するキーワードが出てきました。EA、要求開発、アジャイル、TOCなどなど。

　当然、これらは後から出てきた概念なので、プロジェクト当時は意識はされていませんでした。しかしながら、それら概念を知り、後からプロジェクトを振り返ってみると、意外と一致することは多く、世の中考えることは同じようなことなんだな、と感じました。その後日談を紹介して、本稿は終わりにしたいと思います。

＜EA(Enterprise Architecture)＞

　EAの概念は、プロジェクトが一段落しつつある時期に流行しました。顧客企業は全社を挙げてEAに対応することになり、本プロジェクトは顧客企業内のIT化プロジェクトでも先駆けとなるプロジェクトだったため、他のプロジェクトはEAに順じるが、本プロジェクト（システム）はどうなっているか？という調査依頼がきました。そこで本システムのアーキテクチャと照会してみたのですが、言葉の細部などで異なる点はあるものの、大きくずれていない、という結論に達しました。

＜要求開発＞

　本プロジェクトでは、設計事務所が仕様を決める担当でした。特にユーザーの本質的な要求の定義（NeedsではなくWants）に注力しており、「要求開発」が提唱する内容をみて、まさにその通り！という感じでした。

＜アジャイル＞

　もしくは反復型開発、という方が正しいかもしれませんが、本プロジェクトは大企業の古い発注形態に基づいた典型的なウォーターフォール型開発でした。しかし断面断面ではアジャイル的な光景が多く見受けられました。