読者です 読者をやめる 読者になる 読者になる

みのわーるど::Blog

茨城のシェアハウスの中にある会社で働くITベンチャー役員の奮闘記。

UniStudyビジネス編振返り #4 ~プロジェクトマネジメント前編~

ビジネスフレームワーク マネジメント 勉強会, コミュニティ

Advent Calendar担当4回目、今回はUniStudyの第4回「プロジェクトマネジメント:前編」の振返りです。色んな人の知見が至る所に公開され、一体何が正しいのか正しくないのか、、。迷っているあなた、ここは一旦、プロジェクトとな何なのか、原則を整理してみてはいかがでしょう?

f:id:yminowa:20161226013230j:plain

バックナンバーはこちら

プロジェクトマネジメントとは?

プロジェクトを成功に導くための知識、スキルやツール、技法。またそれらを使って業務に取り組むこと。

そもそもプロジェクトって、、?

通常(提携)業務の範疇に収まらない、新たな付加価値(独自性)のあるビジネス目標を達成するために期間を限定(有期性)して行う一連の作業のこと。

ここでポイントとなるのは、

  • 独自性
    今までにない付加価値を生み出す一連の作業。以前達成した目標に対し、新たなメンバーやプロセスで挑むのもプロジェクトといえます。
  • 有期性
    期限を必ず定めます。よくありがちな「少し遅れたけど何とか納品したしお疲れ!」は、この定義に照らし合わせると、プロジェクト失敗になります。

(参考)プロジェクトと定型業務の違い f:id:yminowa:20161226014926j:plain

プロジェクトマネジメントの要素(対象)

基本的には、以下の4要素について抑えとくとよいでしょう。やっぱりプロジェクトマネジメントが難しい(面白い)のは、常に各要素がダイナミックに変動し、リソースは不足気味(そしてITの場合は特に、メンバーのスキル差が大きい)の中で、どのように求められるバリューを提供するか、ではないでしょうか?

  • 時間
    よくある「これいつまでにできますか?」です。
  • 資源(リソース)
    ヒト、モノ、カネ。どれたけ投下できるか。
  • スコープ
    よくある「今回どこまでやりますか?」です。
  • 品質
    試作(研究開発)or製品版。Webアプリなら同時に何人使う想定?テストのカバレッジ(網羅率)は?

f:id:yminowa:20161226012417j:plain

これらの要素はトレードオフである、ことを常に念頭におくことが重要です。「予算はないけど、納期までに全部やってほしい」を真に受けてメンバーに伝えるだけならマネージャーなど要らず、そこはプロジェクトオーナーとプロジェクト成功のために戦う姿勢が重要なのであります。

プロジェクトの5つのフェーズ

回し方の差こそあれ、プロジェクトは以下のフェーズで進んでいきます。

  1. 問題把握
    このプロジェクトは何を解決するのか?。いざという時「な、なぜ俺達はこの仕事をしているのだ(Why)??」に答えがないのはしんどい、、
  2. 立ち上げ(要件定義)
    要求事項、対象範囲、GOALを文書化して明確に。
  3. 計画(基本計画の策定)
    達成に向けての作業の洗い出し、作業順序、リソース試算 ここまでで、プロジェクトの目標が6W2H(後述)の観点で定まっているはず。
  4. 実行・管理(開始/進捗管理/計画修正/テスト)
  5. 終結(導入/効果策定/今後の改善案)
    最終成果物の納入、導入。 目標の達成度を定量評価、改善点の洗い出し文書化。定量的に測定できる目標設定が重要→でないと評価できない、次に活かせない。 例) イベントAを通して街の人に活動を知ってもらう→知ってもらうの定義とは? 知ってもらう→活動の認知率70%のようにする。そうすれば、アンケート等で定量評価できる。

プロジェクトマネジメントに役立つフレームワーク

6W2H

プロジェクトを成功させるために、メンバーが目標を正しく知っている必要があります(同じ方向を向いている)。明文化が曖昧で、それぞれの解釈で動いてしまうと、気づいたら違う方向に進んでいた、なんてことはよくある話。そこで、モレなく目標を明文化するのに、6W2Hのフレームワークを使います。

  • Why(なぜ)目的
  • Who(誰が)主体
  • What(何を)内容
  • When(いつからいつまで)開始と期限
  • Whom(誰に)対象
  • Where(どこで)場所
  • How(どのように)方法手段
  • How much(どの程度)達成水準

勉強会の当日は、「シェアハウスでの七夕イベント」開催に当たってのプロジェクト整理というお題のワークショップをやりました(以下参照)。

f:id:yminowa:20161226012442j:plain

PDCA

みんなだいすきPDCA!ほう・れん・そう!並にメジャーな?フレームワークですが、各要素は良いとして、個人的なキモは以下だと思います。

Planを定量的に!

ここが曖昧だと、Checkが定量的に行えず、感情的なものになってしまいます。「あまりうまくいかなかった(あまりとは?)」すると、Actの仮説も精度が悪くなり、どんどん脱線してしまいます。

f:id:yminowa:20161226012454j:plain

QCD

Quality(品質)、Cost(費用)、Delivery(納期)の頭文字を取ったもの。上でもプロジェクトの4要素ということで紹介しましたが、理解としては、トレードオフが存在する、ということで良いと思います。

参考資料

プロジェクトマネジメントの知識体系としてPMBOKがデファクトスタンダードになっています。掘り下げたい方は読んでみてください。

プロジェクトマネジメント標準 PMBOK入門 PMBOK第5版対応版

プロジェクトマネジメント標準 PMBOK入門 PMBOK第5版対応版

以前社内勉強会用に作ったスライドです。プロジェクトとは?あとはマネージャーの心得とは?について軽く触れています。

***

以上のように、前編ではプロジェクトの正体やプロジェクトマネジメント時に役立つフレームワークということで紹介してきました。

プロジェクトをうまく回せないといってHow?を一生懸命追い求める人がいますが、プロジェクトマネジメントが、基本的には人を巻き込んでチームでバリューを出す行為である以上、型にはめることにこだわり過ぎないことが大切だと思います(経験談)。だって、一緒に仕事するのは人間だもの。実践や対話を大切にし、粘り強く現実解を探していく姿勢、が求められます。

次回は後編、「関係者の巻き込み」編です。マネージャーはチーム全体としてバリューを出すことで認められます。チームを巻き込むために考えておくべきこととは?

※当日使用したスライドを公開しています