オリエンタルインフォーメイションサービスの山崎と申します。
社内では現在、10プロジェクト、48名を管理するグループリーダーをつとめています。
今回は「難度の高いプロジェクトを進めるポイント」について少し書いてみようと思います。
プロジェクトを納期通りに、お客様の要求品質に合わせて遂行することがプロジェクトの成功の要件です。
しかし、プロジェクトの成功はそれほど簡単ではありません。
日経コンピュータの調査によれば、プロジェクトの成功率はたった3割ほどです。
［プロジェクト実態調査800社 1］測る企業は成功率が2倍に
編集部では、品質、コスト、納期の3基準すべてで「当初計画通りの成果」を収めたプロジェクトだけを「成功」と定義した。やや厳しいと見る向きもあるかもしれない。確かにプロジェクトの成否をどこで判断するかは難しい問題だが、日経コンピュータではこの3基準を満たしていなければ確実に成功とは言い切れないと考え、このような指標を設定した。
この算出方法から有効回答の814件を分析したところ、プロジェクトの成功率は31.1％だった。前回の26.7％より増加したとはいえ、四捨五入すればどちらも3割。著しい変化はなかったと言っていいだろう。
この数値がどれほど正確なのかはともかくとして、「プロジェクトをうまく進めるのは難しい」というのは、共通の認識と言って良いでしょう。
では、プロジェクトの成功のために必要なこととは一体何か。
システム開発に限定されないかもしれませんが、それは、次の3つではないかと思います。
1.アウトプットイメージの共有は「理解」を優先。
まず最も大事なのはプロジェクトのスポンサー（ほとんどの場合はお客さん、社内プロジェクトなら経営者など）と、アウトプットのイメージを共有することです。
「いつまでに、どのようなアウトプットを出せるか」をスポンサーがよく理解していないと、「成果が見えない」と、ほとんどの場合プロジェクトは頓挫するからです。
ここで重要なのは、アウトプットのイメージをスポンサーに「知らせている」ではなく、「理解してもらっている」でなくてはならない点です。
例えばシステム開発プロジェクトにおいては、「お客さんに見えるところから作る」という鉄則があります。
お客さんが最もよく最終成果物を理解できるのは、「画面」です。
機能の一覧や、プログラムのロジックなども重要ですが、大半のお客さんの理解は見えて、操作できるものがなければ、理解は進みません。
このように、「知らせる」ではなく、「理解」を優先することで、ようやくアウトプットのイメージを共有したことになります。
2.早期の課題洗い出しは、「洗い出し」専門のチームで。
私が必ずプロジェクトの初期段階で行うのが、早期の課題洗い出しです。
具体的には「スポンサーに対しての質問」と、「内部で解決すべき問題」を一覧にします。
スポンサーへの質問
ルールが曖昧、方針が未決定など「決めてもらいたいこと」と、もう1つデザインやインターフェースの仕様について「欲しい資料をもらえないか」の2つです。
内部で解決すべき問題
プロジェクトメンバーの内部で解決すべき問題は「技術的に解決が困難とみられるもの」です。
これらの課題を網羅的に洗い出せるかどうかが、プロジェクトの成功の鍵となります。
そのため、難度の高いプロジェクトでは、ちょうどゲームの開発会社が、開発者とテスターを分けるように、「問題を洗い出す部隊」と、「成果品を作る部隊」に分けてプロジェクトを進めています。
作る人と、チェックする人を分けることは、製造業、印刷業など他業種ではよく行われていますが、品質管理の基本の一つです。
3.進捗チェックは「怒らない」。
アウトプットのイメージを共有でき、課題を洗い出すことができれば、残るはその課題を一つ一つ解決しながら、タスクをこなしていくだけになります。
タスクの管理手法としてはシンプルなものが良いでしょう。
例えば「朝会」です。
高難度のプロジェクトでは、朝回を毎日行います。
それほど難しくないプロジェクトでも、チーム内のコミュニケーションを円滑にするために週に一回は行うべきです。
朝会では「前の日にやるべきだったこと」の完了報告と、「今日やるべきこと」を皆が発表し、予実対比を行います。
ただ、「タスクをこなす」のも平穏無事に、と言う訳にはいきません。
感覚値ですが、8割のタスクはきちんと終わります。しかし、残りの2割は遂行されないままになっています。
やれそうな仕事を割り振ったはずなのに、無理のないように気を配って仕事を配分しているのに、仕事を終わらせていないメンバーがいる。
ここで、プロジェクトリーダーは忍耐力を試されます。
中には、「遂行できなかったタスク」に我慢がならず、メンバーに怒ってしまうリーダーもいます。
私もプロジェクトリーダーになりたての頃は「なんでできないんだ！」と、思わず声を荒げてしまったこともあります。
ですが、実は「怒ること」はNGです。
プロジェクトリーダーは怒ってはいけません。かえってプロジェクトが遅れるだけです。
なぜでしょう。
それは「真面目にやっていない技術者は、ほとんどいない」からです。
私がリーダーをやって気づいたことで一番大事なことの一つはこの、「技術者は性善説で接するべき」というものがあります。
技術者は、自分の技術の低さが皆の前で晒されてしまうことを非常に怖れます。
それなのに勇気を振り絞って「終わりませんでした」と報告している。
要するにこれは、「かなり解決に時間を要する、厄介な問題がひそんでいること」のアラートであることが多いのです。
それなのに怒ってしまえば、メンバーは「ひたすら問題を隠す」ことに邁進するでしょう。
そして、隠された問題は必ず後で大きな問題となって発覚し、そうなってしまっては手遅れのケースも多いのです。
以上、３つをプロジェクトの成功要件として挙げました。
が、もしかしたらプロジェクトに限らず、マネジメントはすべて、同じなのかもしれません。
【お知らせ】Books&Appsでは、企業の広報活動を支援するサービスを行っています。ご興味のある方はこちらからご連絡ください。
(Photo:frank servayge)
