Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

プロジェクトの進め方白書

306 views

Published on

情報システムプロジェクトを成功に導くために:

今日のSIプロジェクトは、新たな技術や代替サービスが次々と登場する環境に置かれています。一方で、クライアントやユーザー、上長の意向や現場の声など、複雑に関連しあい、時々刻々と変化していくステークホルダー間の要求・要件をまとめることは依然として難しく、ものづくりの発注側であっても、制作側であっても、なかなか思い通りに進まないことが増えています。

ウォーターフォール型のプロジェクト推進には限界を感じつつ、リーンやアジャイルを取り入れても、いまひとつうまくいった実感が湧きにくい。そんなことを実感されているCTO、プロダクトマネージャの方は多いと思います。実務に忙しくて、他にどんな手法や取り組みがあるのか、キャッチアップの不安を抱えているというプロジェクトマネージャの方の声もよく聞きます。
本資料は、マネジメント手法における最新トレンドを概観し、その特徴や課題を整理したものです。多少なりとも、皆さまのヒントになればとの思いで作成致しました。お役に立ちますと幸いです。

Published in: Engineering
  • Be the first to comment

プロジェクトの進め方白書

  1. 1. ©2019 YouheiGoto All rights reserved 想定外トラブルを“逆に活用”し メンバーのポテンシャルを引き出したいPMのための プロジェクトの進め方白書 予定通り進まないプロジェクトの進め方 著者 プロジェクトコンサルタント 後藤洋平 2019/3/12 https://peraichi.com/landing_pages/view/yoheigoto
  2. 2. ©2019 YouheiGoto All rights reserved もくじ 0.はじめに:本資料の目的のご説明 1.「起」 ウォーターフォール型マネジメントの限界と、最新トレンド一覧 2.「承」 予定通り進まないプロジェクトを進める方法(事例つき解説) 3.「転」 プロジェクト設計のテンプレート(手引き) 4.「結」 「因・縁・果」ワークショップのご紹介
  3. 3. ©2019 YouheiGoto All rights reserved はじめに:本資料の目的 情報システムプロジェクトを成功に導くために 今日のSIプロジェクトは、新たな技術や代替サービスが次々と登場する環境に置かれています。 一方で、クライアントやユーザー、上長の意向や現場の声など、複雑に関連しあい、時々刻々と変化 していくステークホルダー間の要求・要件をまとめることは依然として難しく、ものづくりの発注側 であっても、制作側であっても、なかなか思い通りに進まないことが増えています。 ウォーターフォール型のプロジェクト推進には限界を感じつつ、リーンやアジャイルを取り入れても、 いまひとつうまくいった実感が湧きにくい。そんなことを実感されているCTO、プロダクトマネー ジャの方は多いと思います。実務に忙しくて、他にどんな手法や取り組みがあるのか、キャッチアッ プの不安を抱えているというプロジェクトマネージャの方の声もよく聞きます。 本資料は、マネジメント手法における最新トレンドを概観し、その特徴や課題を整理したものです。 多少なりとも、皆さまのヒントになればとの思いで作成致しました。お役に立ちますと幸いです。
  4. 4. ©2019 YouheiGoto All rights reserved 問題提起 Chapter.1
  5. 5. ©2019 YouheiGoto All rights reserved なぜプロジェクトマネジメントが必要なのか 世の中にあるほとんどのプロジェクトは 「なんだかよくわからないうちに始まって、 いろいろ試しながら形を作っては直したりして、 これだという確信が得られないなか、終わりを迎える」 未知に取り組む 有限の資源 知識 人 お金 時間 設備 etc…課題 目的 手段 環境 etc…
  6. 6. ©2019 YouheiGoto All rights reserved システム開発プロジェクトにおける一般的な課題:仕様変更の多発と見積もりの甘さ 引用元:2018「日経TECH」調査 システム開発プロジェクトの5割が失敗、1700件を独自分析 進行の遅れは、そもそものシステム投資の 狙いが実現されるかどうかの危機につながる!
  7. 7. ©2019 YouheiGoto All rights reserved 一般的によく言われる、プロジェクトの整理、計画、実行 計画 整理 曖昧な目標を分解し、 ミッションと成果を明確にしよう 目標を達成するための アクションプランを立て、明確化しよう 実行 チームビルディングをして、 メンバーにきちんと割り振って、推進しよう 企画書 WBS 議事録
  8. 8. ©2019 YouheiGoto All rights reserved プロジェクトマネジメントの定石:PMBOK 「こうすればうまくいく」方法を研究し、研鑽してはいるが・・・ ・PMBOK :Project Management Body of Knowledge ◯概要 ⇒国際的に標準とされているプロジェクトマネジメントの知識体系 ◯POINT ⇒プロジェクトマネジメントを初めて体系化した ⇒QCDを始めとする「結果」だけでなく「プロセス」をマネジメントするという考え方の重要性を提唱 ⇒大きなプロジェクトでも、小さなものでも、その構造は変わらない ゴールプロセス
  9. 9. ©2019 YouheiGoto All rights reserved しかし・・・ プロジェクト リーダー あらかじめ描いた青写真に無理やり現実をあわせようとする、 “演繹的に管理”するマネジメントの限界を感じる人も多い。
  10. 10. ©2019 YouheiGoto All rights reserved 上長や顧客からの要求はなお厳しく 環境 デジタル たくさんの成功事例 たくさんのツール 働き方 短い時間で最大の成果? 工数不足 組織 非ラインマネジメント 部門横断 メンバーが皆兼任 経営 スピード! 量! クオリティ! プロジェクトリーダー
  11. 11. ©2019 YouheiGoto All rights reserved 想定外トラブルに見舞われるプロジェクト それに関わる人々が抱える「痛み」 発注した側 受託した側 経営 プロジェクト推進 現場 定例会議のたびに納期が後ろに 追加費用はいつまで続く? 投資対効果への不安 ゴールが見えづらい 人員配置、リソース確保のさじ加減 人月型モデル 利益確保の苦労 関係各位への説明に奔走 本当にリリースできるかの不安 手にした成果物への違和感 後回しにされるユーザ教育 それでも「とにかく使いなさい」 相次ぐ変更と手戻り 最後はやっぱりデスマーチ 顧客、社内、パートナーetc 全方位との合意形成に奔走
  12. 12. ©2019 YouheiGoto All rights reserved 考察篇 Chapter.2
  13. 13. ©2019 YouheiGoto All rights reserved なぜプロジェクトが難しいか 目標制約条件 時々刻々と変化していく 減ったり 増えたり 発見したり 厳しくなったり ゆるくなったり 発生したり 消えたり 遠くなったり 近くなったり 見失ったり 蜃気楼だったり 手にしているもの
  14. 14. ©2019 YouheiGoto All rights reserved あらゆるプロジェクトの過程とは、 抽象化すれば、誠に単純なものである。 しかしこれが、如何ともし難い 企画 • 見直し • 変更 要件定義 • ヌケモレ • 矛盾 設計 • 材料不足 製造 • 時間不足 テスト • 様々なツ ケ 検収 • ・・・ ありとあらゆる手戻りとの戦い・・・
  15. 15. ©2019 YouheiGoto All rights reserved プロジェクトマネージャとは。 時々刻々と変化するプロジェクトにおいて、 「タスクの洗い出し、割り振り」 「スケジュール調整、議事録」 「次のアクションの確認」 「進捗具合の確認&遅延対策」 これらは重要な「手段」ですが「目的」ではありません。 ①「なりたい姿」と「現在の姿」の間にあるギャップを理解すること。 全体を俯瞰的に、立体的に、有機的に理解する。 個々のアクションやアウトプットを、注意を凝らして観察する。 そのうえで、「目標」「制約条件」「与えられているもの」の三者の間にある関係性を柔軟に考える。 ②関係者に意思疎通を促して、勝利へのアクションを促すこと。 逆説的ですが、実は、 「これらを必要としない プロジェクトのほうが、うまくいく」 という面もあります。
  16. 16. ©2019 YouheiGoto All rights reserved 成功しやすいチーム、 そうでないチーム ・プロジェクトの全体について考えるのがPMだけ ・硬直的な役割分担 ・各メンバーは自分の作業だけに注力 ・自分の担当だけ果たせば、全体については気にしない ・問題が発生したら責任を問うのが優先、解決は二の次 ・各メンバーが全体の状況を把握しようと努めている ・自身の役割、直近のアクションに取り組んでいる ・状況の変化に応じた柔軟な連携、結果隠れた能力の発見 ・各個人が、チーム全体を到達地点までたどり着かせようとしている ・不足していることを補い合う姿勢
  17. 17. ©2019 YouheiGoto All rights reserved 近年注目されている マネジメントのトレンド アジャイル 開発 ホラクラ シー ティール 組織 心理的 安全性 リーン スタート アップ これからは、トップダウンではないマネジメント。 そうはいっても、なんでもありのボトムアップでも困る。そこで、 一定の方向性を共有し、発展可能な新たなマネジメントの可能性が模索されています。
  18. 18. ©2019 YouheiGoto All rights reserved SI業界における開発手法としても、まさに ウォーターフォール型でない 様々なプロジェクトの進め方が模索されています。 ウォーターフォール プロトタイプ スパイラル アジャイル 網羅的なテストを行わず、バグも多く存在している、「とりあえず動いている」 状態のものを顧客・ユーザに見せ、ソフトウェアがどのように動くかをプロジェ クトの早い段階からイメージを共有する。 顧客・ユーザの目に触れる最初の段階で高い品質まで保証する。同時に要件定義 したフルスコープの機能についても一度に用意するため、図の全体を覆ったもの を一気に開発する。 フルスコープではなく、スコープを区切って、必須度の高い機能から定義・開発 していく。その後、省かれた機能のうち優先度の高いものから追加していく、と いう形でソフトウェアを成長させていく。 ウォーターフォール型開発における要求定義、設計、コーディング、テストの各 工程を繰り返す開発モデル。仕様変更やスケジュールの対応のし易さなどメリッ トがあるが、主な原因として、多大なコストがかかってしまうこと等から、普及 率は未だに低い。
  19. 19. ©2019 YouheiGoto All rights reserved 特に人気が高いアジャイル。 そのなかでも、細かくわけると・・・ アジャイル スクラム エクストリームプログラミング ユーザー機能駆動開発 「スプリントバックログ」と呼ばれる一覧表によってユーザーの要件 をタスクに分解。一週間から四週間に渡る「スプリント」と呼ばれる 期間で開発を進めていく。 ドキュメントの整備よりもソースコードを優先する、プログラマ中心 の開発モデル。テスト駆動型開発、リファクタリング、ペアプログラ ミングなどのプラクティスを重視。 反復的にソフトウェアの開発を行う手法。 顧客目線での機能価値を重視し、必要な機能の選定を行い、適切な間 隔で顧客に提供していく。
  20. 20. ©2019 YouheiGoto All rights reserved プロダクト、開発者、ユーザー。 この三要素のうち何を優先させるのか。 永遠の問いでもあります。 アジャイル スクラム エクストリームプログラミング ユーザー機能駆動開発 「スプリントバックログ」と呼ばれる一覧表によってユーザーの要件 をタスクに分解。一週間から四週間に渡る「スプリント」と呼ばれる 期間で開発を進めていく。 ドキュメントの整備よりもソースコードを優先する、プログラマ中心 の開発モデル。テスト駆動型開発、リファクタリング、ペアプログラ ミングなどのプラクティスを重視。 反復的にソフトウェアの開発を行う手法。 顧客目線での機能価値を重視し、必要な機能の選定を行い、適切な間 隔で顧客に提供していく。 プロダクト 中心主義 開発者 至上主義 お客様 至上主義
  21. 21. ©2019 YouheiGoto All rights reserved 解法篇 Chapter.3
  22. 22. ©2019 YouheiGoto All rights reserved どのようなプロジェクトに、 どのような進め方が向いているのか スクラム エクストリームプログラミング ユーザー機能駆動開発 ウォーターフォール 過去に類似事例や実績が多い。 あらかじめ成果物の全体像、構成要素が、ドキュメントで表現しやすい。 過去に類似事例や実績が少なく 成果物の全体像、構成要素が、ドキュメントで表現しにくい 契約重視 説明責任 信頼関係重視 柔軟性 スピード
  23. 23. ©2019 YouheiGoto All rights reserved プロジェクト頻出の悩み① うちは「アジャイルでやりますから」と宣言していたが、 メンバーによって「アジャイルとはなにか」について 理解度やイメージが違う。 「そんな進め方だと困る」 「思っていたのと違う」 「進め方の選定が正しい」から「想定通りに進む」わけではない!
  24. 24. ©2019 YouheiGoto All rights reserved プロジェクト頻出の悩み② ドキュメントを書いても、書いても・・・読まれない。 前提条件が変わってしまい、使えなくなる。 なんどもなんども、書き直し! そんなことをやっている暇があったら、作業を進めたくなる。 どんな手法を取ったとしても、悩みはなくならない!?
  25. 25. ©2019 YouheiGoto All rights reserved そこで: 「みんながPM」「みんなでPM」 そんなプロジェクト推進を実現するためのツール プロジェクト譜&「因・縁・果」ワークショップ
  26. 26. ©2019 YouheiGoto All rights reserved プロジェクト工学 詳細はこちらに・・・
  27. 27. ©2019 YouheiGoto All rights reserved プロジェクト工学 ◯メリット ⇒書きやすく、読みやすい ⇒考慮漏れを防ぎやすい ⇒着手前の設計にも、プロジェクト終了後の振り返りにも使える ◯デメリット ⇒初めて書く際には、どのような粒度で記載するか等、要領をつかみづらい ⇒タスクとスケジュールを細かくマネジメントしていくのには向かない 拙著刊行後、多数、ワークショップを実施させていただいたなかで、 プロジェクト譜を書くことによって、 「相手がなにを、どう考えているか、これまでいかに“見えてなかったか”がわかった」 「自分が考えていた打ち手が不足していることが発見できた」 などのお声をいただいております。
  28. 28. ©2019 YouheiGoto All rights reserved プロジェクト例: 業務改善アプリケーションを作る。 Cさん(ユーザー) アプリ作りって、初めて! 作る過程はよくわからないから、 とにかく早く動くものを触ってみたいなぁ Dさん(受注側PM) あとで手戻りが発生しないように、気をつけたい。 要件定義とタスク出しが大事だな Aさん(プロジェクトオーナー) 使いやすさ重視!デザインどうするんだろう Bさん(発注側PM) 予算以内に絶対におさめなきゃ! はやく見積出してほしいけど、まだかな 獲得目標 何をやるか 勝利条件 どうなりたいか 動機 なぜやるか 実は、プロジェクトをキックオフしたその時点から、 関係各位のイメージのズレは気づかぬうちに、発生するもの。 「動機」「獲得目標」「勝利条件」の三位一体を議論して、 合意形成を図ることでゴールイメージを具体的に共有します。
  29. 29. ©2019 YouheiGoto All rights reserved プロジェクト例: 業務改善アプリケーションを作る。 Cさん(ユーザー) 設計書だけで本当に内容のOK/NGを チェックできるか不安。 どこを確認すべきか、教えてくれないかな Dさん(受注側PM) どこか、手を打たないといけないのに 盲点になっているような課題は残っていないだろうか? Aさん(プロジェクトオーナー) そうかそうか、デザインの話は 機能一覧を出してから考えるのか Bさん(発注側PM) 要件定義の精度を高くしないと 後々の変更が発生しそうだな。 部門長全員に声かけて、レビュー会やろう 「獲得目標」「勝利条件」を描いたあとは、 それを実現するための「中間目的」「施策」を書いて 「プロジェクトが実現するための過程」を可視化します。 それをメンバー全体で俯瞰することで、抜けもれを防ぎ、 各自の役割がどこにあるのかのイメージ共有をはかります。
  30. 30. ©2019 YouheiGoto All rights reserved プロジェクト例: 業務改善アプリケーションを作る。 Cさん(ユーザー) どんなふうにプロジェクトが進むかが なんとなく見えてきた。 楽しみになってきた! Dさん(受注側PM) さて、いよいよ始まるから リソース確保の件、確定の連絡をしよう Aさん(プロジェクトオーナー) 発注の手続きをするためには、来月の 役員会までには色々書類が必要だな Bさん(発注側PM) 思ったより早く関係部門へのネゴが 必要になりそうだ。 一度決起会を開催してみようかな 実際にプロジェクトを着手するために、定石的なドキュメントに落と し込みます。具体的には、「制作企画書」「プレ要件定義書」「概要 スケジュール」によって構成される「Project Startup Document」を 作成します。 さらにこれを「創造」「客観」「リスク」等の6つの視点でチェック することで、プロジェクトのブレない軸を見出していきます。
  31. 31. ©2019 YouheiGoto All rights reserved 「みんなでPM」「みんながPM」を 実現するための三段階 ■「因」のワークショップ そのプロジェクトに取り組む動機は、だれの、どこにある? 獲得目標はなにか、また、その勝利条件は?を明らかにするワークショップ。 ■「縁」のワークショップ プロジェクト譜を書いてみるワークショップ。 実際にそのプロジェクトを開始させるものと仮定して、 その実現過程のなかで、どんな活動をするか、それがどう紐づくのかを構造化して考える。 ■ 「果」のワークショップ 「起こり得る想定外」を想定することで、そのプロジェクトを通して 「本当に得たいもの」「実は、あってもなくてもいいもの」がどこにあるのかを探るワークショップ。 類似事例で発生した教訓をぶつけてみたり、6HATの視点からプロジェクト譜を検証する。 成果物として、要件定義書のひな形やおおよそのスケジュール等もアウトプット。 プロジェクトに関わる、様々な立場の人がみんなで一緒になって全体像とディテールを往復協議する。 そのことによって、解像度の高い「プロジェクト表象」を共有するのがこの三段階です。
  32. 32. ©2019 YouheiGoto All rights reserved まとめ Chapter.4
  33. 33. ©2019 YouheiGoto All rights reserved まとめ テーゼ① 新たな技術やプロダクトを導入するにあたっては、事前の想定が極めて困難 テーゼ② 時々刻々と状況が変化するプロジェクトに対して、 ユーザーとベンダーの双方が、事前に仮想演習を行うことで ユーザーにとっては投資判断の精度を高める効果 ベンダーにとっては下流工程の備えが万全になる効果 が得られる テーゼ③ プロジェクト工学の考え方に基づく「因・縁・果」ワークショップを是非ご体験ください。
  34. 34. ©2019 YouheiGoto All rights reserved ワークショップの流れ(フルバージョンの場合) ■ 実施前ヒアリング (「因」のワークショップ) ファシリテーターから、プロジェクトオーナー、マネジャー、メンバーへ、 そのプロジェクトを検討するに至った背景や期待すること、懸念等をヒアリングします。 またワークショップ本番にむけての事前準備について、ご依頼をさせていただきます。 ■ ワークショップ第一番(「縁」のワークショップ) 午前中 :プロジェクトがいかにして困難になるのか、またそれへの備えについての座学 午後① :実際にプロジェクト譜を書いて、構造化するワーク 午後② :ユーザー様だけでなく、ベンダー様も交えたプロジェクト譜のレビュー OUTPUT=プロジェクトの獲得目標と勝利条件を明文化する「プロジェクト譜」 ■ ワークショップ第二番(「果」のワークショップ) ファシリテーターから、「縁」のワークショップ結果に対する仮想演習テーマを提示いたします。 それに対してディスカッションを行い、プロジェクトの「軸」を見出します。 OUTPUT=プロジェクトを実際に着手することを想定した場合の「Project Startup Document」
  35. 35. ©2019 YouheiGoto All rights reserved アウトプットイメージ Project Startup Document ・制作企画書 ・プレ要件定義書 ・概要スケジュール ワークショップ「因」 ワークショップ「縁」 ワークショップ「果」
  36. 36. ©2019 YouheiGoto All rights reserved メリット ■ITベンダー様、制作サイドの方々にとって ・顧客が求めるものはなにか、どこまでフェアウェイで、どこからがOBかが見える ・それにより、その先にある提案の精度を高めることができる ・受注後のリソース準備を安心して考えることができ、また工数見積の精度も高まる ・プロジェクト実行時のディレクションリソースに余裕が生まれる ・マーケティングにおけるメッセージ作成や事例紹介コンテンツ作成時の参考になる ・受注にいたらなかったとしても、ターゲット顧客のインサイトを洞察できる ■ユーザー様にとって(またはその声を代弁する、プロデューサー、マーケター、セールスの方々) ・パートナーとして、ITベンダーや制作者がどのような価値を提供してくれるのかが事前に感じられる ・本当に自社が取り入れて目的を達成できるのか、過去の事例も踏まえた的確な予測ができる ・満足できるQCDを得るために、自社側でどのような準備や活動が必要なのかがイメージできる ・スムーズにベンダーや制作者と意思疎通するための共通言語が獲得できる ・改めて、自社の事業戦略においてどのような機能やプロダクトが必要なのかを内省できる
  37. 37. ©2019 YouheiGoto All rights reserved 実施プランのイメージ ■ライトプラン 当日関係各位にお集まりいただき、簡単な座学を1時間と「縁」のワークショップを実施します。 所要時間:事前準備なし+WS本番半日程度 ■スタンダードプラン 事前準備である「因」のワークショップを上記に加えたプランです。 所要時間:事前準備あり+ WS本番丸一日 ■フルバージョンプラン 前述のフルバージョンを実施したプランです。 所要時間:事前準備あり+ WS本番丸一日+後日半日程度 ※開催内容に関しましては、実際のテーマや実施内容等に応じてご調整させていただきます。 お問い合わせは youheigoto@gmail.com まで。
  38. 38. ©2019 YouheiGoto All rights reserved 著者紹介 予定通りに進まないプロジェクトを“前に”進めるための理論「プロジェクト工学」提唱者。HRビジネ ス向けSaaSのカスタマーサクセスに取り組むかたわら、オピニオン発信、ワークショップ、セミナー 等の活動を精力的に行っている。大小あわせて100を超えるプロジェクトの経験を踏まえつつ、設計学、 軍事学、認知科学、マネジメント理論等様々な学問領域を参照し、研鑽を積んでいる。 自らに課しているミッションは 「世界で一番わかりやすくて、実際に使えるプロジェクト推進フレームワーク」を構築すること。 books ・最新刊 好評販売中! 「予定通り進まないプロジェクトの進め方」 recent activities ・企業向けプロジェクトマネジメント講座@宣伝会議 ・プロジェクト工学研究会@みらいけん ・「因・縁・果」の三段階「プロジェクトプレ要件定義」WS ・チームメンバーの心に火をつける「薪ストーブCycle」WS history 1982年 大阪府生まれ 2000年 私立西大和学園高等学校卒業 2002年 東京大学理科一類入学 2006年 東京大学工学部システム創成学科卒 製造業向けコンサルティングスタートアップ 2009年 新規事業開発コンサルティング 2014年 HRビジネス向けSaaSカスタマーサクセス プロフィールページ: https://peraichi.com/landing_pages/view/yoheigoto

×