; oi: プロジェクトマネジメント
ラベル プロジェクトマネジメント の投稿を表示しています。 すべての投稿を表示
ラベル プロジェクトマネジメント の投稿を表示しています。 すべての投稿を表示

2017年4月18日火曜日

【SPRINT】Googleで培われた最速な問題解決プロセス

本書の概要

SPRINTとは、Googleの中で培われた短期間(5日間)で、問題を見極め、解決のためのアイデア評価を行い、答えを出す手法である。下記の図で示すように、通常ビジネスにおいては必要な、ビルドやローンチといったプロセスをスキップして、アイデアの良し悪しを学ぶことを可能とする。

Shortcut [the Design Sprintより引用]


本書は、SPRINTについての体系だった説明というよりは、具体的な実践方法が詰め込まれた一冊である。「リーンスタートアップ」よりも速く答えを出すための工夫が、「イシューからはじめよ」よりも実践的で現実に即した内容が盛り込まれている。

例えば、進行役が注意すべき点や、被験者の集め方に加え、文房具の準備の方法や、おすすめのランチのタイミングなど、実践知に基づき、実際にSPRINTを実施して問題解決するための細かいTipsまで記されている。加えて、本書末尾の付録には、SPRINT実施のための留意点をまとめたチェックシートがついており、実際に問題解決策のアイデア出し&評価を実施するためには、ぜひ参考にしたい内容だ(本書をそばに置きつつ、まずはSPRINTの試してみて、その効果を見定めるのはアリだと思う)。

しかしながら、本書は残念な点も多い。章の頭や途中に、方法の説明と前後する形で事例が記載されており、しかも、小説調や語り調で書かれているため、読みにくかったように思う。個人的には、洋書特有の緩い表現をを排して、見出しを構造化して事例は最後にまとめるなどすれば、より読みやすい書籍となったように思う。また、副題に「最速仕事術」とあるが、「仕事」という表現は少しもったいないように思う。本書でいう「仕事を最速に行うこと」は、チームとして問題の特定から、解決アイデアの評価を最速で行うことであり、一般的に「仕事」という言葉が指すことの多い、個人の決まった作業の効率化という内容とは一線を画すからである。

SPRINTの重要な考え方

SPRINTの中で特に重要と感じた考え方について列挙する。

  1. 役割とプロセスの明確化と合理化
    • 問題を深掘りする際の課題の洗い出しなどは、専門家を招聘して実施し、出来上がったプロトタイプの評価は被験者を集めヒアリング評価を行う。また、チームで集めたアイデアの素材は共有し、それを基にメンバは個人でソリューションを考え、スケッチにまとめる。またメンバは投票を行い、意思決定者が最終的にソリューション案を決定する。このように誰がどれを行うかが明確になっており、無駄がなく、合理的である。
  2. 問題の見極めとフォーカスを尊重
    • いきなりソリューションを考えるのではなく、まず問題をしっかりと特定し、チームとして認識し、明確なターゲット(どの顧客の何の瞬間)を定める。
  3. 解決策立案のための素材収集の効率化
    • 定義された問題を解決するための既存のアイデアを持ち寄って、デモを行いチームに共有する。チームは、共有された既存アイデアを改善させたり、組替えたりすることで新しいアイデアを醸成する。
  4. 解決策のアイデアは具体化
    • ブレインストーミングより個人のアイデア出しの方が優れていることは立証済であるため、個人でアイデア出しを行う。また、抽象的なアイデアの場合、感情や主観によって捉え方や評価が変化しやすいため、アイデア自体を公平公正に評価するため具体化を行い、スケッチにまとめる。
  5. アイデアの意思決定/合意形成の効率化/主観の排除
    • 「メンバの品評→メンバの投票→意思決定者の決断」というようにプロセスを決めておくことで、好き勝手に自由なタイミングで品評する無駄な時間を省くことができる。匿名にするなどして、アイデアを公平に客観的に評価できるような工夫をする。

SPRINTの実施内容

本書に記載されたSPRINTのキーワードを、備忘録として曜日ごとに整理しておく。

◼︎月曜日:問題を見極め、特定する ※いきなりソリューションから入らない
長期目標:プロジェクトの1年後に目指すところ
スプリントクエスチョン:スプリントの最後にどのような問いに答えられるか?
マップ:顧客が製品/サービスを利用する流れを整理したもの
専門家にきく:マップを確かめる、課題を知る
どうすればメモ:課題に対して、どうすれば〜という形でまとめる
ターゲットを決める:本SPRINTでどこにフォーカスすべきか?
 ・重要な顧客は誰か?
 ・体験の中で最も重要な瞬間はいつか?
 ・インパクトがある/重要そうなところ

◼︎火曜日:問題解決のアイデアを具体的なスケッチにする
光速デモ:改良と組替えに焦点をあてる。既存のアイデアで使えそうなものを3分でプレゼン。月曜からの宿題でも良い。

メモ: ベストな素材を集める
アイデア: なんでも書く
クレイジー8: アイデアのバリエーションを高速に洗い出す
ソリューションスケッチ:3コマでまとめる:全員が個別に作成する、抽象的なアイデアは誤って評価される、ブレストより個人の方が良いアイデアがでるのは証明済。

◼︎水曜日:解決策の決定とプロトタイプのストーリー作成
ソリューションスケッチの決定:投票して勝者を決める
ストーリーボード:プロトタイプの計画を立てる

◼︎木曜日:リアルなプロトタイプの作成
ファサード:完璧→必要最低限、長期品質→一時的なシミュレーション
プロトタイプ思考:
 ・短時間でリアルさを得る。
 ・時間をかけすぎない。

◼︎金曜日:生身の人間による評価
現実なユーザーによるテスト(5人):それ以上は費用対効果が微妙。

参考情報

The Design Sprint http://www.gv.com/sprint/

2016年1月17日日曜日

話題の資格PRINCE2の受験を通して想ったこと


PRINCE2ファンデーション試験について

PRINCE2® Foundation を受験した結果をまとめる。

試験概要

試験名:
PRINCE2® Foundation Certificate in Project Management

試験時間: 60 分
問題数:  75 (採点対象外のトライアルの質問5つを含む)
合格に必要な正答率: 50% (70問中35問正解)
持込(テキストや電子機器など): 不可
試験の内容:7つのテーマの観点、7つのプロセスの観点からそれぞれ5題程度出題され、合計70問程度となる。

勉強量


  • 3日間の講習
  • 模擬試験1h程度の学習

試験結果


  • 62/70 (89%)

試験における注意事項

試験の翻訳揺れ、誤字、誤訳が多いので、原文を推定して、正しそうな回答を選ぶ必要がある。
  ex1.ワークブックとの翻訳ズレ: マネジメント/管理, リスク選好度/リスク許容限度, etc..
  ex2.翻訳ミス:スタータス(ステータスの間違い)

試験対策

PRINCE2® Foundation の範囲でいえば、以下を押さえておけば問題ないであろう。

  • テーマという分類
  • プロセスの目的
  • プロセスの主要な活動とアウトプット
  • どの役割がどの活動を行うか

PRINCE2について

以下、3日間の講習と試験を通してPRINCE2について、学んだこと想ったことをまとめる。

PRINCE2(参考:PRINCE2 Wikipedia)とは 

英国にて開発されたプロジェクトマネジメント方法論である。イギリスでのプロジェクトマネジメントのデファクトスタンダードとなっており、徐々にイギリス以外の国々でも利用が広がっている。

PRINCE2の歴史

1989年、イギリス政府の情報システムのプロジェクトマネジメントの標準として中央電子計算機局 (CCTA) が PRINCE を開発した。
1996年、より汎用的なプロジェクトマネジメント手法として PRINCE2 が発表された。

(参考:PMBOK Wikipediaより) 
1987年、米国PM学会によって、PMBOKガイドはホワイトペーパーとして出版された。
1996年、初版が出版。
2000年、第2版が出版。
2004年、大幅な変更を加えた第3版が出版。
2008年、第4版の英語版が出版。
2013年、最新の第5版(英語版)が出版。

PRINCE2の内容(概要)

大変ざっくりいうと、以下のNつの〜という切り口でPRINCE2は整理されている。詳細には触れないが、おおよそどのような観点からプロジェクトマネジメント方法論が記述されているかがわかる。

Fig. PRINCE2の構造 (Wikipediaより)

4つの要素


  1. 原則
  2. テーマ
  3. プロセス
  4. テーラリング

7つの原則


  1. ビジネスの継続の正当性★
  2. 経験からの学習
  3. 定義された役割および責任
  4. 段階によるマネジメント◆
  5. 例外によるマネジメント◆
  6. 成果物重視
  7. プロジェクト環境に合わせたテーラリング

7つのテーマ


  1. ビジネスケース★
  2. 組織
  3. 品質
  4. 計画
  5. リスク
  6. 変更
  7. 進捗

7つのプロセス


  1. プロジェクトの始動
  2. プロジェクトの立ち上げ
  3. プロジェクトの指揮
  4. 段階のコントロール◆
  5. 段階境界のマネジメント◆
  6. 成果物提供のマネジメント
  7. プロジェクトのクローズ

6つのプロジェクト・パフォーマンス


  1. コスト
  2. 時間
  3. 品質
  4. スコープ
  5. リスク
  6. ベネフィット★

PRINCE2の特徴

上のPRINCE2の内容について特に特徴的な部分に印(★、◆)をつけた。

事業、ビジネスに主眼を置いたコンセプトが多い(★)

PRINCE2においては、ビジネス・ケースという、プロジェクトの存在意義を記したドキュメントを、適宜振り返りることで、継続的にプロジェクトの正当性を確認する。これは単に「プロジェクトとして、あるスコープのものを決まったコスト、納期で開発する」だけに留まらず、「成果物を用いて現業で価値を出す」に強くフォーカスしている。現業のビジネスにおける嬉しさをベネフィットとし、費用対効果があるかを常に確認し続けることが、ビジネス継続性の正当性の原則であり、特徴的な点といえる。

マネジメントがトップダウンの権限委譲によってなされる(◆)

プロジェクトをマネジメントする単位を段階として定義し、段階毎に権限を与えマネジメントを実施する。また、委譲された権限の範囲において、何かしらの指標が許容できる度合いを超えてしまい、マネジメント/実行が困難と判断すれば、例外という形で上に解決を仰ぐ。極めてトップダウンなマネジメントの手法を推奨している。

PRINCE2の理解にあたって

 テーマという観点

各テーマの内容はふわっとしており、テーマ間をオーバーラップするような内容も含む。なぜこのテーマで十分と言えるのかが今ひとつ納得できない。また、各テーマの様々な活動はプロセス横断的に存在するため、プロセスと整合性をとりながら、理解するのが難しく感じる。
 故に、テーマという観点に軸足を置いて、学習を進めるよりは、各テーマの概要、コンセプトだけを先に理解した上で、プロセスの観点でPRINCE2が提唱する様々な活動を理解するほうが効率が良いと考える。ふわっとしたテーマという軸による整理より、時系列や順序関係という軸による整理のほうがブレは少ないと想うのである。

 翻訳の問題

教材の日本語化が十分に進んでおらず、翻訳ミスや翻訳された日本語の揺れも多く、理解を妨げる。英語が読める人であれば、日本語のテキストと英語の原文と照らし合わせながら、不明点の解決に努めた方が効率的である。

参考情報:2016年4月には、PRINCE2のオフィシャルマニュアル(以下はプロマネ向け)が日本語化され、書店に並ぶとのこと。



まとめ:PMBOKを中心に据えて、様々な方法論を集約してはどうか?

今回、PRINCE2を学習し、PMBOKというプロジェクトマネジメント知識体系との違いを踏まえた上で、PMBOKを中心に各種知識を集約させるとプロジェクトマネジメント系の知識が体系的に理解し易いのではないかと考える。
なぜなら、知識の体系化のレベルでいえば、PMBOKが大変にわかり易いからである。PRINCE2に含まれる、事業や投資判断という観点、ビジネスケースの振り返りによる継続的なプロジェクト正当性の確認といった観点は弱いものの、プロジェクトマネージャーが考えておくべき主要な要素は知識エリアとプロセス群という形で整理され、整合性も精緻にとれている上、ツールと技法にまで言及されており、実用性も高い。
PRINCE2のビジネス・事業・投資判断に近い考え方をPMBOKにも取り込み、プロジェクト正当性といった、新しい知識エリアを用意すればPRINCE2は不要ではないかと考える。

その他、ITIL(参考:ITIL Wikipedia)のようなITサービスマネジメントのベストプラクティス(PRINCE2同様イギリス中央電子計算機局 (CCTA)にてまとめられたもの)もPRINCE2やPMBOKと一緒に語られることが多いので、触れておく。ITILはあくまでベストプラクティスであり、知識としては大変有益なものが多く含まれているが、全体としての整合性が弱く、論理的体系的に精緻にまとめられているとは言い難い。そのため、読者の経験の違いによっては、解釈・理解がズレる内容も多いように見受けられる。PRINCE2同様、このような体系化が不十分だが有益な知識をPMBOKに落とし込んでいく、あるいは関連づけていくことが重要だと考える。