結局,いかに最初の段階で「無理のない計画」を立てることができるかによると思います。工程が後ろになればなるほど修正も大変です。ただ,残念ながら数値しか責任のない営業が無理な案件を取ってくることは少なくない話と思います。上記の10項目,もっともな話ですが最初の項目で現実味のある計画を立案できないと他の項目は対応することすら難しいのでは?納期,工数の交渉の段階で,営業の交渉に関するスキル不足を,いかに会社が組織として支援するかが鍵かと思います。

納期遅れ。一部機能が仕様を満たせず。

(ユーザー)

 このユーザー企業の方からのコメントは,あらかじめプロジェクトが実現可能かどうかを検討することの重要さを指摘したものです。ご意見にある「上記の10項目」とは,前回のフォーラム「動かないコンピュータ経験は役立つか 」で紹介した「動かないコンピュータ撲滅のための10カ条」のことです。よろしければご覧ください。

 次に,あるエンジニアの方のご意見を紹介します。ご指摘のように,実現可能かどうかに加え,何のためにそのシステムをつくるのか,それによって何が実現するのかといった点について考えることも不可欠です。



1.システムの目的---売上向上・コスト削減・リスク対策のいずれか---と,対象を明確に定めること。「二兎は追わない」ことを原則とする。
2.システムを入れただけでは何も変わらないことを,顧客に周知徹底させること。
3.やみくもに流行技術を追わない---技術者としては「自制」し,業務目的と狙いと投資金額に合うシステムづくりを優先する。

某国内系ITコンサルティング会社に勤務していたころの経験。某顧客に対するシステム全面刷新計画のJOBで,プロジェクト推進チームに所属。時間と巨額のフィーをいただいたにもかかわらず,結局システム構築に至らず,プロジェクト自体が破綻した。問題はあまりにもファジーな要求分析と基本計画,そして業務・技術知識/見識のなさに起因する。ちなみに当方は,この案件で社長と対立し,やむなく退社した。

(その他,エンジニア)

 直接はご指摘されていませんが,このご意見はプロジェクトに対するベンダーやユーザーのトップ関与の仕方についても考えさせるものがあります。

 プロジェクトが具体的にスタートして最初に取り組む,要件定義についての教訓もありました。



要件定義において,充分なユーザー・ニーズのヒアリングと現場も含めた検討会を重ね,コミュニケーションを十分に交わすことを心掛けてきました。やはり,ユーザー企業と開発側で,同じ最終目標を具体的に共有することが,必要だと実感しています。

業務ノウハウ不足と,現場を巻き込まない要件定義による開発側(ユーザー・システム部門と弊社)の独りよがりなシステム構築によって,現場で使ってもらえないシステムをリリース。リリース後に,現場からのクレームで,現場業務の再調査からシステムを全面的に見直し,ほぼすべてをつくり直したことがあります。

(ベンダー)

 十分なコミュニケーションと具体的な目標の共有は,プロジェクトを進めるチームづくりの上で不可欠なものでしょう。時に利害関係が一致しないユーザーとベンダーの間で,この関係を継続させることは簡単ではないのでしょうが。



起案者が経験豊富ということで周囲が根拠のない安心感を持ってしまい,起案内容を十分チェックする機能が働かなかった。起案者が実力者であったということも軌道修正への動きを阻害し,起案者が転勤後,システムは破棄された。実力者であっても独走を許せば再発するとして,委員会形式の横断組織が結成され,さまざまな面から検証することが組織に根付いた。

新方式の検査システムであったが,検査で異常を検出したときにどう組織的に対応すべきかまったく決まっていなかった。起案者は単体の検査装置の開発経験は豊富であったが,システムとして組織的に運用する案を検討していなかった。現場に周知徹底されぬまま導入されたシステムは「オオカミ少年」として迷惑な存在となった。

(ユーザー)

 実力者にすべてを任せるのも危険なようです。IT統治という言葉がありますが,個人のチェック能力には限界があります。このユーザー企業の方のように,横断方式による検証を根付かせるべき組織は多いと思います。

利用実態と離れたものは悔恨を生む

 以下のご意見のように,利用実態や運用実態を想定してシステムをつくることの大切さも,しっかりと意識すべきでしょう。



業務改善のためのシステムは,運用からのノウハウを開発に迅速にフィードバックする必要がある。モノづくりの「カイゼン」と同じポリシーで業務システムを捉えることが重要である。システムの開発者(組織)と運用者(組織)は同一でなければならない。

ベンダー見積もりのシステム更新費用が高価すぎた。

(ユーザー)

 システムを完成させても,利用が進まなければ意味がありません。開発者と運用者を完全に同一にすることは難しいかもしれませんが,両者の意志を疎通させることに心を砕くべきでしょう。

(中村 建助=日経コンピュータ