“D”九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。2010/07/05前回は、奇跡のプロジェクトについてサービス工学の視点から見て「何が成功要因だったのか」という分析結果を(かなり端折ってですが)お話しさせていただきました。分かりづらい点もあったかと思いますので、今回は「解説編」ということで、解説や解釈を入れながらフォローしていきたい思います。■背景(顧客、システム、プロジェクトの特色)今回の分析結果がすべての「動かないコンピュータ問題」へのサジェスチョンになるかというと、そういうわけではありませんが、もう少し背景を明確化することにより、今回の知見を応用できるプロジェクトがもう少しはっきりとするのではないかと思います。これまでお話ししてきたことと重複する点もあるかと思いますが、お付き合いください。利用者数:約2000名2.システム(背景、IT化のテーマ、目的)概要<背景>高度成長時代を終え、設備は建設の時代から維持管理の時代を迎える。)に関係する業務全般。■OA化とIT化の違い本プロジェクトの開始当初、ユーザーから下記のような質問が出ました。「これまでのシステム化と何が違うのか?」その時の回答は、以下のようなものでした。言葉の綾のようなものですが、回答にはそれなりの理由があります。図1を参考にしていただきたいのですが、ある業務の流れがあり、その中の一部を人間からコンピュータにやらせること。Automation)化と定義しております。業務のすべてはコンピュータに置き換わるわけではないが、業務自体をIT(PCやモバイル、GIS)を使って行うこと、これを業務のIT化と定義しているのです。参考図1:OA化とIT化の違いまた「パソコン化」という言葉もありました。顧客企業は古くからコンピュータ活用は進んでいますが、最初の業務システムは電算センターなどでホストを使っておりました。それがワークステーション化され、各事業所でコンピュータを使えるようになりましたが、2~3台を共用で扱う人は限られていました。並行してPCが1人1台支給されてきました。最初はWordやExcelなどオフィスの利用がメインで、業務システムとしてはほとんど使われてなかったのです。今回のシステム開発で、権限の違いはあるものの、すべての業務機能が全社員のPCで可能となったのです。■本プロジェクトの大きな課題これらを踏まえて、後からの振り返りになるのですが、今回のプロジェクトの特色を整理し、そこに関連する課題を洗い出してみました。開発会社に経験がない。同じIT業界とはいえ、大手メーカーとなるとそれぞれやり方も違えば文化も違う業務も多岐にわたるが、開発会社も同様に多岐にわたるので、スター型のコミュニケーションが必要<課題>1.ゴール(仕様)が決まらない経営課題解決のための仕組みだが、現場の人は経営課題が分からないITで何ができるのか分からないので、新しい業務フローは作れないさらに利用者は、経営者から現場までPCを使っている社員全。個々の要望も多くなるし、要望が二律背反を起こす結果、仕様が決まらない2.コミュニケーションがとれない業務範囲が広いので、ユーザーと開発会社との言葉の違いが出てくる開発会社も複数あるので、責任範疇に隙間が出てくる経営と現場のギャップ。普通のことをやっている分には問題ない。特殊なこと、ヘビーなこと、他との連携をやろうとすると、問題が出てきて、その問題解決は難しい■設計事務所が果たした役割これも後からの考察になるのですが、上記で挙げさせてもらいました本プロジェクト特有の課題、じつはこの課題にこそ、設計事務所の役割が効いているということが分かりました。仕様を決めるためには、まず経営者から現場まで、関係各所の要望を聞く必要がある。この段階ではまだ開発会社は登場していない。仕様を決める、という事は実は要望を切り捨てる、ということに他ならない。これは社内でも開発会社でも難しい(開発会社は要望を取り入れてコストを上げようと働く)。何なのかここから最も伝えたいことで、でも最もややこしく、伝えることが難しい話をしたいと思います。「設計事務所とは、先述の役割に対してノウハウを持つコンサルタント」と考えてみます。その答えは「ノー」でしょう。結果的にその役割を担って、そこが成功要因だったということはできますが、最初からの役割でも、ノウハウを持っていたわけでもありません。今後、別のプロジェクトに設計事務所と参画することがあれば、上述の定義が当てはまります。奇跡のプロジェクトでは悲しいかな、胸を張っていえるわけではないのです。設計事務所」という概念を導入しました。「狭義の設計事務所」とは、その役割として参画した弊社のことを指します。これがこれまで話してきました「設計事務所」の役割を実態として担っており、「狭義の設計事務所」である弊社は、その実行部隊、という位置付けになります。行ってきた機能ということになります。顧客企業がイニシアティブをとってしまうと、業務改革や改善が主体となってITはおざなりとなり、改革改善は進むがシステムは動かない、ということが起こります。逆に開発会社主体であるとシステムを作ることが目的となり、システムはできたが改革改善は進まず経営者の望む成果は出てきません。それぞれの分野で提供し、顧客満足を実現できた、軸がぶれなかったということだと思います。企業の壁を取っ払って知恵を出し合い、問題解決に努めた、ということです。すると化学変化を起こし、新しいアイディアが生まれ、困難に立ち向かっていける。いわゆる「共創」の実現です。■最後に(後日談)実は本事例のプロジェクトは時代的に少し古く(時効を待って紹介しておりますので)、ちょうどプロジェクトが一段落したころに、世間ではいくつかのシステム開発に関するキーワードが出てきました。EA、要求開発、アジャイル、TOCなどなど。これらは後から出てきた概念なので、プロジェクト当時は意識はされていませんでした。それら概念を知り、後からプロジェクトを振り返ってみると、意外と一致することは多く、世の中考えることは同じようなことなんだな、と感じました。その後日談を紹介して、本稿は終わりにしたいと思います。Architecture)>EAの概念は、プロジェクトが一段落しつつある時期に流行しました。いう調査依頼がきました。そこで本システムのアーキテクチャと照会してみたのですが、言葉の細部などで異なる点はあるものの、大きくずれていない、という結論に達しました。<要求開発>本プロジェクトでは、設計事務所が仕様を決める担当でした。<アジャイル>もしくは反復型開発、という方が正しいかもしれませんが、本プロジェクトは大企業の古い発注形態に基づいた典型的なウォーターフォール型開発でした。断面断面ではアジャイル的な光景が多く見受けられました。仕様を決める際は、顧客、開発会社SEが一緒になって決めた。constraints)>これはまったくの個人的意見なのですが、システム開発の本当の目的価値(課題)を明確にして、それを阻害する問題を順番に解決していく考え方は、TOCに非常に近しいのではないかと思っております。以上、解説編、いかがだったでしょうか?本編をもう少し分かりやすくフォローするつもりでしたが......当初の目標を達成できたどうか不安ですが、もしご興味のある方は下記の論文も参考にしてください。九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。久しぶりの対面研修で思ったことよく学びよく遊びよく寝る、頭の回転が良い子供がたくさん育つ国になるといいな。新着記事SpecialPR@ITメールマガジンのお申し込み新着記事をいち早く知りたい、オリジナルコラムを読みたい――メールマガジンに登録して、@ITを120%使いこなそう。ITmediaはアイティメディア株式会社の登録商標です。