社団法人中小企業診断協会東京支部 中央支会
Search
Mail Magazine
詳しくはこちら
専門家コラム 「情報システムの開発はチームで」(2006年12月)
鈴木 清

< 情報システムの開発はチームで >

 情報システムの構築には、経営者の理解と参画が必要であるといわれている。実際に、プロジェクト失敗の原因として、この理解と参画の不足が指摘されることは少なくない。

 だが、経営者が積極的に参画していたにもかかわらず、失敗に終わった情報システムのプロジェクトもある。なぜだろうか。この点を考えてみたい。

 そのような失敗を私も2件聞いたことがある。うち1件はERPに関するもの、もう一つは、営業関係のシステムである。聞いた話のうち1件は、まんざら知らない企業ではなく、またそのプロジェクトが行われることも知っていた。なお、念のため付け加えると、私がそのプロジェクトに参加していた訳ではない。

 私が聞いたケースでは、いずれも経営者が情報システムの知識がなかったわけではない。

(1)当然ながら、その情報システムは当該企業において重要であった。
(2)情報システム開発プロジェクト・チームにおいて、経営者は実質的にリーダーの位置にあった。
(3)経営者は、かつて情報システム関連の業務経験もあり、情報システムの知識や識見もあった。

 にもかかわらず、プロジェクトは失敗となった。
何よりも、経営者自身が、失敗と判断していた。速やかに損失を処理して、プロジェクトを終了させていた。この辺は、さすがに経営者であり、本当にすごいと思う。

 それだけに、なぜ失敗したか、何をもって失敗としたかは、分かりにくいのである。せいぜいが、「システムがうまく稼働しなかった」、「当初の目的を果たせなかった」、あるいは「業務上の要請に応えられないと判断した」程度が関係者から聞こえてくるだけである。

 したがって、以下の話には、私の推測が相当程度に入っている。もうひとつ、お断りしておきたい。「経営者の理解と参画」は不要といっているのではない。必要なのだ。問題は、どのような参画が望ましいかである。


1.情報システム開発の問題とは何か

 本件に関連した業務系の情報システム開発の問題を示しておきたい。

(1)求めるのは業務上の成果である

 企業が求めているのは、ビジネスあるいは業務における現実の成果である。情報システム自体は、その成果実現のためのプロセス/手段での一要素である。

 当然ながら、ビジネスあるいは業務プロセスが、情報システムの要件を規定する。

(2)情報システムは、人が使ってこそ稼働する

 当たり前であるが、業務系の情報システムは、情報システムだけでは稼働しない。というか役に立たない。業務において担当者が入力し、出力情報がそれを必要とする者に届いて、初めて実効性を問える。

 注意していただきたいのは、環境変化への微妙な対応は、人間がやっているということである。入力すべきデータは毎回きっちり定時に同じように発生するわけではない。データが遅れることもあれば、必要な項目がないこともある。これらの対応は、人間がやっているのである。出力情報も同じである。特異な変動があった場合は、それを勘案して、判断をするのは人間である。

 日常的に起きるさまざまな変動や問題を人間系がうまく吸収するからこそ、情報システムは機能するのである。情報システムが柔軟に判断して対応してくれるのではない。システムの問題は人間系/業務系で吸収できるが、逆は不可である。人の対応が硬直化すれば、システムは機能しない。これが、現場を重視すべき理由のひとつである。

(3)システム開発で最大の問題は利害の衝突である

 情報システム導入は、業務上の成果を得るためであり、人間は情報システムが機能するための重要な要素である。だからこそ、さまざまな利害の衝突が起きる。

 情報システムの導入は、業務処理のプロセスや手順を変える。そのため、益を得る部門と損を被る部門(または担当者)が生じる。社内の関連する部門や担当者の間で利害の対立が生じる。

 情報システムの要件間の不一致や要件の急激な増加の背景には、この利害の衝突があることが多い。ただし、情報システム・プロジェクトの中からは、この利害の衝突は、何がどう問題かが見えにくいのである。

 そのためか、残念ながら、情報システムのプロジェクト内で利害対立のすべてが解決できるとは限らない。むしろ、業務全体の中で調整されて、解消されることが多いと思った方がよい。

2.これらの問題はユーザーだけが解決できる

 上記の3つの問題は、開発会社の苦手とするところ、というよりもユーザー側でしか解決できない。
開発会社がいかに要件定義の技術を駆使しようとも、できるのはユーザー側からの要求をシステムに実装する要件にまとめることである。もともとの要求自体は、開発会社には規定できない。ましてや、業務プロセス自体の変更などは、できるものではない。開発会社にできるのは、ユーザーの要求通りのシステムを作ることである。

(1)開発プロジェクトはユーザーが主体である

 このために、情報システム開発のためには、ユーザー側の資源、つまり十分な予算と優秀な人材、の確保が必要となる。

 通常は、情報システムの開発プロジェクト・チームを編成して、これにあたる。このチームが稼働して十分に機能するか否かが、システム開発の成否を分けるポイントである。
 この開発プロジェクト・チームには、次が必要である。

a.開発プロジェクトの目標(経営あるいは業務上の要請)
b.開発プロジェクトの予算とユーザー側人員の確保
c.プロジェクト遂行にかかわる権限と責任

 これらを開発プロジェクト・チームに提供して、必要な支援を与えるに相応しいのは経営者である。これが経営者の理解と参画の必要性の根拠である。

 ここで、開発プロジェクトのチーム編成、とりわけリーダーをどうするか、である。

 ビジネスの目標や要件は、経営者が誰よりもよく知っているのは、間違いない。問題は、情報システムの知識であるが、私の知る例では、その経営者の方は、情報システムの知識・経験においてもその企業の誰にも劣るものではなかった。むしろ、情報システムに対しても卓越した視点と意見をもっていた。
 このような場合、重要な情報システム開発プロジェクトであれば、経営者が直接に指揮をとる、つまりプロジェクトのリーダーとなるのは自然であろう。誰もが、たぶん経営者自身もそう考えたと思う。

 なお、経営者であればフルタイムで情報システムのプロジェクトに携わるわけにはいかないので、事務的な事項のためのチームリーダーは他におくのは不思議ではない。だから、形式的にはリーダーは他にいても、経営者が実質的にチームリーダーとなったらどうかということである。

(2)経営者が開発リーダーのとき、何が問題か

 経営者が実質的なリーダーとなった開発プロジェクトがなぜ失敗したのだろうか。業務プロセスから情報システムが乖離してしまい、担当者/部門による微妙な調整がうまく機能しなくなってしまうのは、なぜだろうか。
 おそらくは、開発プロジェクトのチームがうまく機能しなかったのだ。

(a)チーム構成が脆弱である

□通常、全社的なプロジェクトであれば、全社的な体制が組まれる。しかしながら、この場合は若手中心のチーム編成となりやすい。チームには、経営者がいるのであるから、さらに管理職クラスをチームに配置することは重複であり不要とされる。
□このため、チーム員の情報システムの知識や熱意は十分ではあるとしても、業務知識や社内調整力は経営者に依存することになる。
□したがって、開発プロジェクトでは経営者の判断のみが重視される。誰もが、どのようなものであれ判断を求めるときは、経営者のところに行くことになる。

(b)開発プロジェクトとそれ以外の部門・業務との調整が難しい

□外部からの意見がチームに届きにくくなる。
誰もが、経営者のプロジェクトならば間違はなく心配ないと思ってしまう。皆、自分の業務で忙しいのである。それに批判もし難い。
□したがって、本来起きているべき問題が、隠されたまま開発が進んでしまう
 経営者といえどもすべてを知っているわけではない。「情報システムは人が使ってこそ稼働する」のである。現場での細部の問題もまた重要なのである。

 もう一つ、注意していただきたい点を挙げておく。

(c)いささか難しく微妙なミッションをプロジェクト・チームに持ち込んでしまう

□本来は、役員や本部長レベルの問題を持ち込むことがある。
例えば、グループ経営の微妙な問題や、プロジェクトを機にした新規ビジネスの可能性を探る等である。
□経営者から見れば、同じような経営上の問題かも知れないが、チーム員が理解できるとは限らない。システム開発以外のやっかいな問題の負荷がかかることになる。

3.開発プロジェクト・チームを機能させる

(1)開発プロジェクトの要件

 開発プロジェクトの要件として、次を示した(前述)。

a.開発プロジェクトの目標(経営あるいは業務上の要請)
b.開発プロジェクトの予算とユーザー側人員の確保
c.プロジェクト遂行にかかわる権限と責任

これらの要件は、実際には、開発プロジェクトが正規の決裁承認を受けることで提供される。経営者は、当然この決裁承認にかかわる。これらの要件が整えば、開発プロジェクト・チームが編成され、開発がスタートする。

 問題となるのは、情報システム開発プロジェクトの方向性の確認と社内のその他の部分との調整である。

a.開発プロジェクト方向性のチェックと修正(含む:プロジェクトの中止と撤退)
b.開発プロジェクトとその他の部門・業務との調整
c.その他、開発プロジェクト・チームの問題解決の支援等

これらは、開発プロジェクトのみで対応することは難しい。また場合によっては好ましくない。プロジェクト外部の離れた位置からのコントロールと支援が必要である。

(2)経営者はエグゼクティブ・スポンサー

 上記の要件から、経営者はプロジェクト・チームの外側に位置した方が良いことが分かる。プロジェクトのリーダーではなく、エグゼクティブ・スポンサーの位置がよい。

 エグゼクティブ・スポンサーとは、一般には、経営の立場から、開発プロジェクトを支援する役割を指す。プロジェクトの設置、プロジェクト目的の設定、またプロジェクトに必要な資源を提供、また必要な場合はプロジェクト中止を決断する等の活動を行う。

 情報システムの開発プロジェクトには、経営者の理解と参画は欠かせない。だが、それはプロジェクトのリーダーであることを意味しない。
経営者は、企業全体に責任を持つ。エグゼクティブ・スポンサーとして、全体的なポジションから、プロジェクトの支援とコントロールを行うことをお勧めする。


□鈴木 清(すずき きよし)
有限会社 イーアズイー 代表取締役
資  格:中小企業診断士、ITコーディネータ、システム監査技術者
専門分野:業務系情報システムの構築・運営
Blog  :”情報システム外伝” http://systemtales.way-nifty.com/


Copyright All rights reserved (C)1997-2011 社団法人中小企業診断協会東京支部中央支会
このページのトップへ