プロジェクトキックオフ！ オリエンテーションで話すこと：ユーザーサイド・プロジェクト推進ガイド（11）（2/2 ページ）

» 2006年06月20日 12時00分 公開
[山村秀樹，＠IT]
前のページへ 1|2 　　　　　　

失敗事例を語る

　失敗事例そのものは方針ではありませんが、方針を理解するうえで重要です。

　大規模なシステムの開発作業はボリュームが大きく、しかも、複雑で手間の掛かるものです。しかし、これを短期間で行うことが求められています。ノウハウやコツなど作業のやり方が何も分からなければプロジェクトが難渋することは必然です。大規模なシステム開発プロジェクトが失敗する原因には、すべきことをどのようにすればよいのか、してはいけないことは何なのかが分からないということがあります。

　失敗は成功の母とよくいわれるように、失敗から学べる事柄は非常に大きいものです。失敗の原因を分析し、すべきことや手法を考えることは次の成功への重要なステップです。ところが、「失敗を反省しない」「反省点を参考にしない」「失敗事例を語らない」など、失敗を無視することが非常に多いようです。学習する習慣がないのか、当時の担当者を傷付けない配慮なのか、失敗はすべてベンダのせいなのか、自分たちは失敗しないと思い込んでいるのか……。

　成功事例は自慢話のようで身を入れて聞く気になれないとしても、リアルな失敗談は自分たちがそうならないように身をもって考えさせる迫力があります。誰しも失敗したくないので、そこから教訓を得、心に留めようとします。失敗事例があるにもかかわらず、メンバーにそれを語らない、あるいは、リーダー自らその失敗事例を意識しようとしないのは、探せばすぐそこにある海図に気付かずに航海に出るようなものです。これでは安全と効率が脅かされます。

　「注意一秒ケガ一生」という超有名な安全標語があります。わずかなコストをケチって大きなダメージを負わないように警告するものであり、逆にいえば、わずかなコストでリスクを回避できるのだから、そのコストを進んで負担しましょう、というものです。

　メンバーに失敗事例を伝えて注意すべきことを意識付けさせることは、注意一秒ケガ一生を実践することであり、リスクに対してコスト効果の大きな対策です。過去の事例をメンバーに話すことは難しいことでもありませんし、そのプロジェクトの担当者を傷付けるものでもありません。反省がしっかり行われていれば、むしろ、失敗を闇に葬り去ろうと口を閉ざしているよりは、よっぽど評価されます。

ベンダに丸投げしてはいけないことを説明する

　機能要求仕様はユーザー側が主体となってまとめるべきであり、これは大前提です。この作業をベンダに丸投げするということは、業務プロセスの管理を放棄することであり、業務と密接に関係するコンピュータ・システムをうまく構築できるわけがありません。そして、いったん出来上がった使えないシステムは、業務改革や改善の足を引っ張り続けます。

　コスト削減や業務効率の向上を背景に、業者にカネを払って頼んだ作業は業者がすべてに責任を持って実施することは当然、と考える管理職は多くいます。そのためか、業者に作業を丸投げすることを無条件に当然と考える人も増えています。

　プロジェクトメンバーとなった人の中にも「規模の大きなコンピュータ・システムの開発もベンダに任せておけばよい、自分たちはその手伝いだ」と思い込んでいる人がいます（システム担当部署の中にすらいることがあります）。

　丸投げのもたらす結果については別に取り上げるつもりですが、メンバーには、ベンダに丸投げすると、プロジェクトは失敗してしまうことを伝えなければなりません。丸投げしてしまえば、結局は「それは常識だ」「いいや非常識だ」「考えが足りない」「いいや情報提示が不足だ」「いうのが遅い」「いいやずっと前から警告していた」……、などの益のない非難合戦に突入することになります。

システムは小さく始めることを説く

　システムのライフサイクルを通じてローコストなシステムとするには、無駄を排除した小さなシステムから始めて大きく育てることです。

　後から機能を追加することは予算の点で難しいことから、開発の時点で、あれもこれも詰め込もうとするところがあります。しかし、このような機能要求仕様の肥大化は、作業工数を増大させ、プロジェクトを、期間的にも、費用的にも、質的にも、何にしても厳しいものにします。使われるかどうか分からないような機能を実装させようとして、プロジェクトを混乱させることはありません。

　業務部門出身のメンバーには「プロジェクトチームに選ばれたということは要求を出す特権を与えられたのだ」と誤解している人がいるかもしれません。システムの仕様を作成するということは、要求事項を羅列することではありません。むしろ、取捨選択、検討して絞り込むことであることを説明する必要があります。

プロジェクトチーム発足時にメンバーに伝える事柄

  • チームとは、メンバーがお互いに助け合ったり刺激し合ったりして高い成果を出す組織であること
  • 過去のプロジェクトにおけるリアルな失敗談とその教訓
  • 機能要求仕様はユーザー側が主体となってまとめるべきものであり、ベンダへの丸投げはプロジェクトの失敗につながること
  • システム仕様の作成とは要求事項を羅列することではなく、取捨選択、検討して絞り込むことであること


　次回も引き続き、オリエンテーションで話すべき事柄を考えます。

筆者プロフィール

山村 秀樹（やまむら ひでき）

某製造業において、主としてシステムの運用保守作業に従事している。仕事を通して、コンピュータ・システムに関心を持つようになり、中でもシステムの開発プロセスについて興味を感じている。

Elie_Worldを運営し、システムのライフサイクル全般にわたる作業について考えている。



「ユーザーサイド・プロジェクト推進ガイド」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ