TOPキャリアアップ> プロジェクトの初動を乗り切る
要求開発
要求をシステム開発に正しく反映させるには

第3回:プロジェクトの初動を乗り切る
著者:ウルシステムズ  河野 正幸   2006/6/2
1   2  3  4  次のページ
プロジェクトの初動を乗り切る

   こんにちは。ウルシステムズの河野です。前回は、要求開発を成功させるために不可欠な現場力をチームが獲得するために役立つ4つのポイントの1番目にあたる「要求開発チームのコア能力を鍛える」について説明しました。今回はその続きを説明していきます。

   「現場力を獲得するための4つのポイント」の2番目は「プロジェクトの初動を乗り切る」ということです。どんなプロジェクトでも立ち上げの当初は、必ず一度は混沌とした状況に陥るものです。特に要求開発プロジェクトは、社内の様々な部門の代表者や私たちのような外部のベンダーからの参加者など、社内外の様々な関係者が集結して開始されます。

   したがって、はじめて顔をあわせる人たちが多く、関係者の利害もそれぞれで異なっているという不安定な状態からプロジェクトを開始せざるを得ません。しかも、プロジェクトが扱う対象は「要求」という非常にあいまいで得体の知れない代物だときています。

   筆者が今までに経験したプロジェクトでも「関係者の意見がなかなかまとまらない」「大量の情報に埋もれて何から手をつければよいのかまったく見当もつかない」という混沌とした状況に必ず一度は陥っています。

   ここで大切なことは、初期の段階で一度は混沌とした状況に陥るのは仕方がないにしても、その状態からいちはやく脱出して、チームがPDCAサイクルをきちんと回してプロジェクトを確実に前進させるように、マネジメントができるかどうかということです。

   なぜなら、要求開発やシステム開発にかぎらず、世の中の多くのプロジェクトは、開始直後の混沌とした状況からいかに素早く正しい方向性を見出して、チームの作業を軌道に乗せることができるかで勝負が決まることが多いからです。


要求開発を失敗させる2つの病気

   筆者の経験からすると、要求開発プロジェクトの初期段階でかかりやすく、そのまま放置しておくとプロジェクトを失敗に追い込みかねない「病気」には次の2つがあります。

   1つめは「情報過多症」です。プロジェクトの初期段階では、とにかく多くの情報を関係者から引き出すことに専念します。しかし、これらの大量の情報にチームが圧倒されてしまい、情報をうまく整理できないまま身動きがとれなくなったり、手のつけやすい情報から断片的に詳細化したために全体としての整合性がまったくとれなくなったりすることがよくあります。

   これを筆者は「情報過多症」と呼んでいます。プロジェクトが開始してから1、2ヶ月は経過しているのに具体的な成果が何も見えない場合は「情報過多症」におかされていることが疑われます。

   2つめは「情報認知不全」です。これはクライアントの重要な要求をチームが見落としてしまうという病気ですが、潜伏期間が長く、なかなか発見することが難しいのでプロジェクトに与える影響もより深刻です。

   例えば、計画どおりに成果物がアウトプットされており、一見順調に進んでいるように思えていたプロジェクトが、システム開発の後期の段階になって大きなトラブルに見舞われることがよくあります。クライアントの受入テストを実施してみたら、彼らが本当に望んでいたことがシステムで実現されていないことが判明するというようなケースがこれに相当します。

   この時点で要求からやり直すことは事実上不可能なことが多いため「情報認知不全」はプロジェクトを中止に追い込みかねないほどのインパクトを持つ可能性があります。

   どちらの病気も、その感染時期を探ってみると、要求開発の初期の混乱状態の中で感染していることがわかります。そして、チームがそれに気づかないままプロジェクトの後期まで放置してしまったために、回復不能なまで悪化してしまい、最終的にプロジェクトを失敗させることにつながっているのです。つまり、要求開発の初動をしっかりとマネジメントしてこれらの病気を予防/早期発見/治療することがプロジェクトの成功に大きく貢献するのです。

1   2  3  4  次のページ


ウルシステムズ  河野 正幸
著者プロフィール
ウルシステムズ株式会社  河野 正幸
山口大学経済学部経済学科卒業後、SIerにて製造業向けシステム開発プロジェクトマネジャーとして従事。2002年8月から現職。得意な分野として、オブジェクト指向分析/設計、開発方法論、プロジェクトマネジメント、製造業の業務などがある。

INDEX
第3回:プロジェクトの初動を乗り切る
プロジェクトの初動を乗り切る
  プロジェクトの全体像を共有する
  3. プロジェクトにおいて各人に期待される役割
  6. 対象業務のコンテキスト