システム開発を請け負ったベンダ側に、システム開発において苦労している点、
失敗する原因を尋ねると、
1.仕様確定後もユーザ側の仕様変更が多発する
2.ユーザ側で要件を明確に定義できない
3.特定の人の頭の中だけに業務ノウハウがあり文書化されていない
といった回答がよせられる。
このような問題を抱えていると、システムが完成間近になってから追加や変更
が多発し、期限に間に合わない、追加開発費用が必要になる、できあがったシス
テムがつぎはぎだらけになってしまうといったような深刻な事態を発生させるこ
とになる。
このような状況に陥るのはユーザ、ベンダ双方に問題がある。
まずベンダ側であるが、これまでこの業界では、ユーザが決めた仕様に基づい
て、如何に期間内にコスト内で高い品質のシステムを作り上げるかというところ、
すなわちものづくりの技を磨いてきたために、顧客に対して受身になる習性が身
についてしまっている。
一方ユーザ側は、現在の業務の説明はなんとかできるが（それすら危ういケー
スもある）、システム導入後の新しい業務についての検討が担当者では難しい。
できたとしても、担当者の業務の範囲内での小さな見直しにとどまり、抜本的な
業務改革は全く手がでない。このため、要求仕様に対して自信がなく、一度決め
たものの、見落としなどから見直しが随時発生するということになってしまう。
とはいえ、ベンダ側も受身のままでとどまっているのわけではなく、ユーザヒ
アリングをして新旧業務フローを描こうとするのであるが、上述の通り、現状
（ＡＳ ＩＳ）は描けても、あるべき姿（ＴＯ ＢＥ）についてはユーザ側から
はっきりしたものがでてこないので、パッケージの持つ業務フローの押し付けに
なってしまう。当然、ユーザ側はこれでは違和感があるため、ＦＩＴ／ＧＡＰを
通じて、注文を付けるのであるが、あるべき姿のイメージがないままであるので、
どんどん現状業務に近いものになり、業務が整理されないままとなるので、パッ
ケージのカスタマイズや追加開発が大量に発生し、高くて使いにくいシステムが
できてしまうことになる。
このような状況に陥らないように、ＩＴコーディネータは良く考えられ練られ
た次のような方法論を有している。
・顧客の現状業務を体系的に整理する（ＤＭＭ、ＤＦＤ）
・経営戦略を踏まえて、あるべき業務の姿を描く（ＢＳＣ、ＡＢＣ、ＤＦＤ）
・新しい業務をわかりやすく説明する（業務フロー図）
・ベンダに要件を的確に伝える（ＲＦＰ）
特に関西の企業の風潮として、システムといった目に見えるものは金を払うが、
コンサルティングは営業サービスの一貫と見なし、お金を出し渋る傾向があるが、
システム導入にあたっては、その姿勢は「安物買いの銭失い」に直結する。
「損して得とれ」ではないが、システムの導入を成功させたいのであれば、ぜ
ひ、ＩＴコーディネータの力を活用して頂きたい。
■執筆者プロフィール
氏 名 宗平 順己（むねひら としみ）
所 属 (株)オージス総研 ＯＧソリューション事業部 コンサルティング部長
資 格 ＩＴコーディネータインストラクター、ＩＴコーディネータ
e-mail : Munehira_Toshimi@ogis-ri.co.jp
プロフィール
昭和５７年３月 京都大学理学部卒（地球物理学教室）
昭和５７年４月 日本電気(株) 入社 汎用機セールスエンジニア
昭和６１年６月 (株)オージス情報システム総研 入社 社会システム部
（現在のオージス総研 コンサルティング部）
以来、地域情報化、行政情報化、企業情報化コンサルティング業務に従事
平成１０年度 ＪＩＳＡ行政情報化委員会情報化投資評価部会 部会長
平成１１年度 ＪＩＳＡ情報化投資評価委員会 委員
平成１３年度、１４年度 ＪＩＳＡ白書委員会 副委員長
専門分野
・ＢＳＣ（Balanced Scorecard）
・ＡＢＣ／ＡＢＭ
・行政評価
・ＩＴ投資評価
コメントをお書きください