このエントリーをはてなブックマークに追加LINEで送る

9.3. 目的と目標の設定

ハッピィ・エンジニアリング表紙

 プロジェクトの目的や目標は、プロジェクト内で共通認識とすべき大前提である。目的や目標の明確化なくして、そのプロジェクトが成功することはないといっても過言ではなかろう。プロジェクトを計画する第一歩はプロジェクトの目的や目標を明確にし、利害関係者を含めた合意を得ることである。そして、さらに綿密なプロジェクト計画へと発展させていく必要がある。

 

 プロジェクトの目的は、ユーザ企業の企画部門によってプロジェクト発生以前に決まっているはずである。システム化の背景にはどのような問題が存在したのか、ということに着目すればよい。その問題の解決や緩和というものがプロジェクトの目的と合致するはずである。

 

 プロジェクトにおいて最小限必要な目標設定は、成果物とQCDである。プロジェクト全体を考えた場合には、このほかにプロジェクトの目的に合致した目標が必要である。プロジェクトの目的に合致した目標を達成することは、プロジェクトが成功したと判断する要因のひとつとして扱えるだろう。

 

 プロジェクトの目標を設定する上で必要な観点は、SMARTを満足していることである。SMARTの概念は、プロジェクト目標にとどまらず、成果物を記述する上での評価基準ともなるので、常に意識しておきたい。

 

  • Specific:具体的な
  • Measurable:計測可能な
  • Agreed Upon:合意された
  • Realistic:現実的な
  • Timely:期限が定められている

 

 明確な目標設定を行うには、プロジェクトの失敗と成功を定義するのが効果的である。当然、利害関係者の全員がプロジェクトの結果責任を持ち、プロジェクトの結果に対する評価を一致させることが望ましい。しかし、関係者の利害が対立する上で、失敗と成功の定義はそれぞれの立場によって異なるであろう。受注側は、納品したシステムの運用が開始され、トラブルがなく、収支が黒字であれば成功と位置付けることができるが、システム投資を行ったユーザ企業は、プロジェクトの成功がシステムの安定稼働と同義ではない。さらに、日本の現実の開発では、「総花的あるいは努力目標的な」成功の定義と「縁起が悪い」失敗の定義の忌避が横行しており、成功と失敗を定義すること自体がかなり難しいのは事実である。

 

 ここでは、ビジネスを考えるうえで当然の観点として、システム投資を行っているユーザ企業の利益に重点を置き、利害の対立を勘案しながら話を進めていくこととする。

 

プロジェクトの失敗

 プロジェクトの失敗による被害を一番多く受けるのは、そのシステムの購入者であるユーザ企業であることは間違いない。ユーザ企業の総意としてプロジェクトを失敗と評価したら、そのほかの利害関係者がどのような反対意見を述べたとしても、その反対意見はなんの意味も持たないだろう。たとえ、その失敗の原因がユーザ企業にあったとしてもである。

 

 ところが、その一方で、ユーザ企業のシステム部門に所属するメンバの多くは、システム基盤のキャパシティプランニングに基づいたサーバのサイジングができなくなってきている。業務システムの事例が多く掲載された専門誌を読んで仕込んだ、とおり一遍の知識をひけらかすのがせいぜいという、非常に困った状況である。このような状況下では、プロジェクトの成否や情報システムの品質をSIベンダに丸投げせざるを得なくなり、丸投げしているユーザ企業が「すべてはSIベンダが悪いんだ」という「被害者意識」を持っても不思議はない。

 

 少々不満に思えるかもしれないが、受発注において、日本の商慣習の上では発注側はそれだけのわがままが許されるのである。SIベンダにはユーザ側のミスリードをコントロールする責任までもが発生している、と言っても過言ではない。

 

 今なお、システム開発プロジェクトが失敗する確率は非常に高いものとされている。それだけに、「失敗しない」プロジェクトマネジメントが求められている。プロジェクトの失敗にはさまざまな観点があり、それらは単に開発の失敗だけにとどまらない。

 

  1. ユーザ企業内の利害調整ミス
  2. そのシステムが実際に利用されなかった場合
  3. 運用・保守などで、回収不可能な莫大なコストを必要とした場合
  4. プロジェクトの必然的な要求である、品質・コスト・納期を守れなかった場合
  5. そもそもシステムが動かなかった場合

 

● ユーザ企業内の利害調整ミス

 発注側・受注側のみならず、ユーザ企業内でも経営者・企画部門・システム部門・ユーザ部門は、それぞれがお互いの利害を対立させながらプロジェクトを進めている現実がある。システム投資費用を安く抑えたい経営陣、そのシステムを一刻も早く必要としている企画部門、システム開発の現実に直面しプロジェクトの責任を負うシステム部門、そして、複数の部門により構成され、機能的な要求が多いユーザ部門。立場が相違すれば、お互いの利害はおのずと異なる。システム開発のうえで、利害関係者それぞれの利害を損ねないようにしていくことは重要かつ困難な問題である。なぜなら、組織の位置づけや、関係者の上下関係などが大きく影響する分野でもあるからである。

 

 この問題は、システム開発の明暗を分ける重要な問題である。ユーザ企業が利害関係を調整できないままにプロジェクトを進めていくと、重要な要件や仕様が決まらないままに開発が進み、最終的に運用可能なシステムとはならない。例えば、2002年4月に発生した、みずほ銀行のシステム統合失敗のケースのように、複数の企業合併においては、どの会社のシステムを基準として統合するのか、どの会社に発注するのかなどの決定や、開発チームのキックオフが遅れたことが、最終的に大惨事に発展したという事例もある。

 

● そのシステムが実際に利用されなかった場合

 このケースにはパターンがいくつかある。ここでは、運用開始可能な品質であったにも関わらず実際に利用されなかった場合を対象としている。これには、エンドユーザへの展開に失敗し、エンドユーザが意識的に使用しない場合、そもそもシステム化自体に意味がなく利用価値がない場合など、いくつかの問題に分類することができる。

 

● 運用・保守などで、回収不可能な莫大なコストを必要とした場合

 これは、一番多く発生していると思われる問題である。前述したように、SIベンダが安値でシステムを受注し、その赤字を保守プロセスにおいて回収しているようなケースは、もはや公然の秘密とさえなっている感がある。特に公共システムに関連する大規模開発では、その傾向が顕著である。

 

● プロジェクトの必然的な要求である、品質・コスト・納期を守れなかった場合

 この問題は前述した通り、システム開発に関連する要員のスキル低下が著しい現在においては、ますます増加傾向にある。コスト面に関しては、大規模開発の場合は受注金額が決定しており、まずユーザ企業側が追加投資をする必要はない。また、SIベンダが少々の赤字を計上したとしても、保守プロセスでの回収の余地が残されている。割を食うのは丸投げで受託した下請けの開発会社であろう。しかし、品質と納期に関しては明らかにユーザ企業側の損害が大きいものである。運用開始の遅れや障害によるシステムの停止は、機会損失や顧客からの信用の低下につながりかねない問題であり、その被害金額は少なくないはずである。納期が遅れるということは、会計処理上のタイミングもずれてしまうことになり、システムへの投資金額が大きければ大きいほど税務会計上の影響も計り知れないものとなる。

 

● そもそもシステムが動かなかった場合

 もはや言うまでもなく、納品できなかったSIベンダが損失を被るのは当然のことだが、ユーザ側の被害も並大抵ではない。プロジェクトの失敗のパターンはいくつもあるが、開発における根本的な原因は2つに絞られる。第一に「無知からくる判断ミス」、第二に「問題の先送り」である。成功は偶然にすぎないが、失敗は起こるべくして起きている。なぜ、システム開発の現場では、同じような失敗を何度も繰り返してしまうのだろうか?

 

 まず、プロジェクトの反省材料がそろいにくいことが挙げられる。そもそもシステム開発プロジェクトの場合、失敗の理由を個人に帰着させてしまう場合が多い。技術者のコミュニケーション能力や技術力を原因とするパターンはあまりにも多い。また、プロジェクト全体が過ちをもみ消し、管理職や経営陣が実情を把握できないという理由もある。

 

 適材適所に優秀なメンバが配置されないことも大きな原因のひとつである。烏合の衆が100人集まったとしても、まともなシステムは開発できない。また、能力のある技術者が10人いても、技術者をコントロールする立場のマネージャが無能では、まともなシステムは開発できない。個々の機能を開発するものづくりのスキルと、全体をまとめ上げてひとつのシステムにするスキルは別物なのである。

 

 さらに、社内の実力者の指示で着手したようなシステムでは、プロジェクトの反省材料が表に出てくることは絶対にないと言っても過言ではない。このような場合には、誰もがシステムの失敗について公の場で語れない。

 

 一番改善が難しく、毎回のように繰り返されるのが「問題の先送り」である。なにかを決めるということは、結果責任が問われることである。そのため、誰もが「決める」ことに恐怖感を持っている。決めるべきことを決めないままに、プロセスが先に進んでいくが、プロセスが後になればなるほど、手戻りという形でスケジュールに与える影響は大きくなり、最悪の場合、これが致命傷となる。納期に間に合わせることを優先するあまり、品質への手抜きが多く発生し、使いものにならないシステムが作られてしまうからだ。このような状況を改善するには、プロジェクトの利害関係者それぞれが、どのような役割と責任を担っているのかを明確にする以外にない。しかし、それすら「決める」ことができないのである。

 

 このように、結局のところ失敗したプロジェクトは、その失敗の事実のみが残り、反省することすらできず、同じ過ちを繰り返していくのである。

 

プロジェクトの成功

 技術者はプロジェクトの成功を「失敗しなかったこと」や「安定稼働したこと」と定義する場合が多い。しかし、プロジェクトには、顧客・開発者・スポンサーなどのさまざまな利害関係者が参加する。つまり、すべての利害関係者が満足して初めて、プロジェクトが成功したということができる。

 

 ところが、利害関係者すべての立場を超えたプロジェクトチームとしての成功を定義することは容易ではない。「4.5 ROIの検討」に記述したように、単純な効率化、生産性の向上を目的としたシステムでない限り、システム化に対するROIの測定は非常に困難なのである。同様に、利害関係者それぞれの利害が一致しない中で、利害関係者全員が十分に満足するような成功の定義は不可能であるともいえる。

 

 つまり、何をもってプロジェクトが成功したとみなすのか、それを定義するのは非常に難しい問題である。

 

 ここでは、ごくごく小さな成功を定義するにとどめる。それは、以下のような流れである。

 

  1. エンドユーザによって積極的にシステムが利用される
  2. (システムがきちんと利用できる品質である)

  3. そのうちに、エンドユーザがシステムの機能や操作性に不満を感じ、機能追加や改善要求が発生する
  4. (そのシステムは改善点を検討するに値する)

  5. システムの二次開発が発生する
  6. (二次開発投資を行うに値するROIだと判断された)

 

 プロジェクトを推進するうえでは、プロジェクトメンバへの動機づけの意味や、その結果を測定する意味でも、そのプロジェクトの成功をでっち上げておき、そのゴールをプロジェクトメンバが共有できるのが望ましい。しかし、「事前に目標を設定し、それが達成されたら成功とみなす」というやり方が、自己目標設定型の人事評価システムの通弊である「低い目標を立てて達成率を上げる」という逃げ道に走ることのないよう、十分留意したい。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

9.3. 目的と目標の設定 ハッピィ・エンジニアリング関連ページ

9.1. プロジェクト計画の概要
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
9.2. プロジェクト計画書
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング