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

3. ©2019 YouheiGoto All rights reserved はじめに：本資料の目的情報システムプロジェクトを成功に導くために今日のSIプロジェクトは、新たな技術や代替サービスが次々と登場する環境に置かれています。一方で、クライアントやユーザー、上長の意向や現場の声など、複雑に関連しあい、時々刻々と変化していくステークホルダー間の要求・要件をまとめることは依然として難しく、ものづくりの発注側であっても、制作側であっても、なかなか思い通りに進まないことが増えています。ウォーターフォール型のプロジェクト推進には限界を感じつつ、リーンやアジャイルを取り入れても、いまひとつうまくいった実感が湧きにくい。そんなことを実感されているCTO、プロダクトマネージャの方は多いと思います。実務に忙しくて、他にどんな手法や取り組みがあるのか、キャッチアップの不安を抱えているというプロジェクトマネージャの方の声もよく聞きます。本資料は、マネジメント手法における最新トレンドを概観し、その特徴や課題を整理したものです。多少なりとも、皆さまのヒントになればとの思いで作成致しました。お役に立ちますと幸いです。

8. ©2019 YouheiGoto All rights reserved プロジェクトマネジメントの定石：PMBOK 「こうすればうまくいく」方法を研究し、研鑽してはいるが・・・・PMBOK ：Project Management Body of Knowledge ◯概要 ⇒国際的に標準とされているプロジェクトマネジメントの知識体系 ◯POINT ⇒プロジェクトマネジメントを初めて体系化した ⇒QCDを始めとする「結果」だけでなく「プロセス」をマネジメントするという考え方の重要性を提唱 ⇒大きなプロジェクトでも、小さなものでも、その構造は変わらないゴールプロセス

11. ©2019 YouheiGoto All rights reserved 想定外トラブルに見舞われるプロジェクトそれに関わる人々が抱える「痛み」発注した側受託した側経営プロジェクト推進現場定例会議のたびに納期が後ろに追加費用はいつまで続く？投資対効果への不安ゴールが見えづらい人員配置、リソース確保のさじ加減人月型モデル利益確保の苦労関係各位への説明に奔走本当にリリースできるかの不安手にした成果物への違和感後回しにされるユーザ教育それでも「とにかく使いなさい」相次ぐ変更と手戻り最後はやっぱりデスマーチ顧客、社内、パートナーetc 全方位との合意形成に奔走

15. ©2019 YouheiGoto All rights reserved プロジェクトマネージャとは。時々刻々と変化するプロジェクトにおいて、「タスクの洗い出し、割り振り」「スケジュール調整、議事録」「次のアクションの確認」「進捗具合の確認＆遅延対策」これらは重要な「手段」ですが「目的」ではありません。 ①「なりたい姿」と「現在の姿」の間にあるギャップを理解すること。全体を俯瞰的に、立体的に、有機的に理解する。個々のアクションやアウトプットを、注意を凝らして観察する。そのうえで、「目標」「制約条件」「与えられているもの」の三者の間にある関係性を柔軟に考える。 ②関係者に意思疎通を促して、勝利へのアクションを促すこと。逆説的ですが、実は、「これらを必要としないプロジェクトのほうが、うまくいく」という面もあります。

16. ©2019 YouheiGoto All rights reserved 成功しやすいチーム、そうでないチーム・プロジェクトの全体について考えるのがPMだけ・硬直的な役割分担・各メンバーは自分の作業だけに注力・自分の担当だけ果たせば、全体については気にしない・問題が発生したら責任を問うのが優先、解決は二の次・各メンバーが全体の状況を把握しようと努めている・自身の役割、直近のアクションに取り組んでいる・状況の変化に応じた柔軟な連携、結果隠れた能力の発見・各個人が、チーム全体を到達地点までたどり着かせようとしている・不足していることを補い合う姿勢

18. ©2019 YouheiGoto All rights reserved SI業界における開発手法としても、まさにウォーターフォール型でない様々なプロジェクトの進め方が模索されています。ウォーターフォールプロトタイプスパイラルアジャイル網羅的なテストを行わず、バグも多く存在している、「とりあえず動いている」状態のものを顧客・ユーザに見せ、ソフトウェアがどのように動くかをプロジェクトの早い段階からイメージを共有する。顧客・ユーザの目に触れる最初の段階で高い品質まで保証する。同時に要件定義したフルスコープの機能についても一度に用意するため、図の全体を覆ったものを一気に開発する。フルスコープではなく、スコープを区切って、必須度の高い機能から定義・開発していく。その後、省かれた機能のうち優先度の高いものから追加していく、という形でソフトウェアを成長させていく。ウォーターフォール型開発における要求定義、設計、コーディング、テストの各工程を繰り返す開発モデル。仕様変更やスケジュールの対応のし易さなどメリットがあるが、主な原因として、多大なコストがかかってしまうこと等から、普及率は未だに低い。

19. ©2019 YouheiGoto All rights reserved 特に人気が高いアジャイル。そのなかでも、細かくわけると・・・アジャイルスクラムエクストリームプログラミングユーザー機能駆動開発「スプリントバックログ」と呼ばれる一覧表によってユーザーの要件をタスクに分解。一週間から四週間に渡る「スプリント」と呼ばれる期間で開発を進めていく。ドキュメントの整備よりもソースコードを優先する、プログラマ中心の開発モデル。テスト駆動型開発、リファクタリング、ペアプログラミングなどのプラクティスを重視。反復的にソフトウェアの開発を行う手法。顧客目線での機能価値を重視し、必要な機能の選定を行い、適切な間隔で顧客に提供していく。

20. ©2019 YouheiGoto All rights reserved プロダクト、開発者、ユーザー。この三要素のうち何を優先させるのか。永遠の問いでもあります。アジャイルスクラムエクストリームプログラミングユーザー機能駆動開発「スプリントバックログ」と呼ばれる一覧表によってユーザーの要件をタスクに分解。一週間から四週間に渡る「スプリント」と呼ばれる期間で開発を進めていく。ドキュメントの整備よりもソースコードを優先する、プログラマ中心の開発モデル。テスト駆動型開発、リファクタリング、ペアプログラミングなどのプラクティスを重視。反復的にソフトウェアの開発を行う手法。顧客目線での機能価値を重視し、必要な機能の選定を行い、適切な間隔で顧客に提供していく。プロダクト中心主義開発者至上主義お客様至上主義

22. ©2019 YouheiGoto All rights reserved どのようなプロジェクトに、どのような進め方が向いているのかスクラムエクストリームプログラミングユーザー機能駆動開発ウォーターフォール過去に類似事例や実績が多い。あらかじめ成果物の全体像、構成要素が、ドキュメントで表現しやすい。過去に類似事例や実績が少なく成果物の全体像、構成要素が、ドキュメントで表現しにくい契約重視説明責任信頼関係重視柔軟性スピード

27. ©2019 YouheiGoto All rights reserved プロジェクト工学 ◯メリット ⇒書きやすく、読みやすい ⇒考慮漏れを防ぎやすい ⇒着手前の設計にも、プロジェクト終了後の振り返りにも使える ◯デメリット ⇒初めて書く際には、どのような粒度で記載するか等、要領をつかみづらい ⇒タスクとスケジュールを細かくマネジメントしていくのには向かない拙著刊行後、多数、ワークショップを実施させていただいたなかで、プロジェクト譜を書くことによって、「相手がなにを、どう考えているか、これまでいかに“見えてなかったか”がわかった」「自分が考えていた打ち手が不足していることが発見できた」などのお声をいただいております。

28. ©2019 YouheiGoto All rights reserved プロジェクト例：業務改善アプリケーションを作る。 Cさん（ユーザー）アプリ作りって、初めて！作る過程はよくわからないから、とにかく早く動くものを触ってみたいなぁ Dさん（受注側PM）あとで手戻りが発生しないように、気をつけたい。要件定義とタスク出しが大事だな Aさん（プロジェクトオーナー）使いやすさ重視！デザインどうするんだろう Bさん（発注側PM）予算以内に絶対におさめなきゃ！はやく見積出してほしいけど、まだかな獲得目標何をやるか勝利条件どうなりたいか動機なぜやるか実は、プロジェクトをキックオフしたその時点から、関係各位のイメージのズレは気づかぬうちに、発生するもの。「動機」「獲得目標」「勝利条件」の三位一体を議論して、合意形成を図ることでゴールイメージを具体的に共有します。

29. ©2019 YouheiGoto All rights reserved プロジェクト例：業務改善アプリケーションを作る。 Cさん（ユーザー）設計書だけで本当に内容のOK/NGをチェックできるか不安。どこを確認すべきか、教えてくれないかな Dさん（受注側PM）どこか、手を打たないといけないのに盲点になっているような課題は残っていないだろうか？ Aさん（プロジェクトオーナー）そうかそうか、デザインの話は機能一覧を出してから考えるのか Bさん（発注側PM）要件定義の精度を高くしないと後々の変更が発生しそうだな。部門長全員に声かけて、レビュー会やろう「獲得目標」「勝利条件」を描いたあとは、それを実現するための「中間目的」「施策」を書いて「プロジェクトが実現するための過程」を可視化します。それをメンバー全体で俯瞰することで、抜けもれを防ぎ、各自の役割がどこにあるのかのイメージ共有をはかります。

30. ©2019 YouheiGoto All rights reserved プロジェクト例：業務改善アプリケーションを作る。 Cさん（ユーザー）どんなふうにプロジェクトが進むかがなんとなく見えてきた。楽しみになってきた！ Dさん（受注側PM）さて、いよいよ始まるからリソース確保の件、確定の連絡をしよう Aさん（プロジェクトオーナー）発注の手続きをするためには、来月の役員会までには色々書類が必要だな Bさん（発注側PM）思ったより早く関係部門へのネゴが必要になりそうだ。一度決起会を開催してみようかな実際にプロジェクトを着手するために、定石的なドキュメントに落とし込みます。具体的には、「制作企画書」「プレ要件定義書」「概要スケジュール」によって構成される「Project Startup Document」を作成します。さらにこれを「創造」「客観」「リスク」等の６つの視点でチェックすることで、プロジェクトのブレない軸を見出していきます。

31. ©2019 YouheiGoto All rights reserved 「みんなでPM」「みんながPM」を実現するための三段階 ■「因」のワークショップそのプロジェクトに取り組む動機は、だれの、どこにある？獲得目標はなにか、また、その勝利条件は？を明らかにするワークショップ。 ■「縁」のワークショッププロジェクト譜を書いてみるワークショップ。実際にそのプロジェクトを開始させるものと仮定して、その実現過程のなかで、どんな活動をするか、それがどう紐づくのかを構造化して考える。 ■ 「果」のワークショップ「起こり得る想定外」を想定することで、そのプロジェクトを通して「本当に得たいもの」「実は、あってもなくてもいいもの」がどこにあるのかを探るワークショップ。類似事例で発生した教訓をぶつけてみたり、６HATの視点からプロジェクト譜を検証する。成果物として、要件定義書のひな形やおおよそのスケジュール等もアウトプット。プロジェクトに関わる、様々な立場の人がみんなで一緒になって全体像とディテールを往復協議する。そのことによって、解像度の高い「プロジェクト表象」を共有するのがこの三段階です。

33. ©2019 YouheiGoto All rights reserved まとめテーゼ① 新たな技術やプロダクトを導入するにあたっては、事前の想定が極めて困難テーゼ② 時々刻々と状況が変化するプロジェクトに対して、ユーザーとベンダーの双方が、事前に仮想演習を行うことでユーザーにとっては投資判断の精度を高める効果ベンダーにとっては下流工程の備えが万全になる効果が得られるテーゼ③ プロジェクト工学の考え方に基づく「因・縁・果」ワークショップを是非ご体験ください。

34. ©2019 YouheiGoto All rights reserved ワークショップの流れ（フルバージョンの場合） ■ 実施前ヒアリング（「因」のワークショップ）ファシリテーターから、プロジェクトオーナー、マネジャー、メンバーへ、そのプロジェクトを検討するに至った背景や期待すること、懸念等をヒアリングします。またワークショップ本番にむけての事前準備について、ご依頼をさせていただきます。 ■ ワークショップ第一番（「縁」のワークショップ）午前中：プロジェクトがいかにして困難になるのか、またそれへの備えについての座学午後① ：実際にプロジェクト譜を書いて、構造化するワーク午後② ：ユーザー様だけでなく、ベンダー様も交えたプロジェクト譜のレビュー OUTPUT＝プロジェクトの獲得目標と勝利条件を明文化する「プロジェクト譜」 ■ ワークショップ第二番（「果」のワークショップ）ファシリテーターから、「縁」のワークショップ結果に対する仮想演習テーマを提示いたします。それに対してディスカッションを行い、プロジェクトの「軸」を見出します。 OUTPUT＝プロジェクトを実際に着手することを想定した場合の「Project Startup Document」

36. ©2019 YouheiGoto All rights reserved メリット ■ITベンダー様、制作サイドの方々にとって・顧客が求めるものはなにか、どこまでフェアウェイで、どこからがOBかが見える・それにより、その先にある提案の精度を高めることができる・受注後のリソース準備を安心して考えることができ、また工数見積の精度も高まる・プロジェクト実行時のディレクションリソースに余裕が生まれる・マーケティングにおけるメッセージ作成や事例紹介コンテンツ作成時の参考になる・受注にいたらなかったとしても、ターゲット顧客のインサイトを洞察できる ■ユーザー様にとって（またはその声を代弁する、プロデューサー、マーケター、セールスの方々）・パートナーとして、ITベンダーや制作者がどのような価値を提供してくれるのかが事前に感じられる・本当に自社が取り入れて目的を達成できるのか、過去の事例も踏まえた的確な予測ができる・満足できるQCDを得るために、自社側でどのような準備や活動が必要なのかがイメージできる・スムーズにベンダーや制作者と意思疎通するための共通言語が獲得できる・改めて、自社の事業戦略においてどのような機能やプロダクトが必要なのかを内省できる

37. ©2019 YouheiGoto All rights reserved 実施プランのイメージ ■ライトプラン当日関係各位にお集まりいただき、簡単な座学を1時間と「縁」のワークショップを実施します。所要時間：事前準備なし＋WS本番半日程度 ■スタンダードプラン事前準備である「因」のワークショップを上記に加えたプランです。所要時間：事前準備あり＋ WS本番丸一日 ■フルバージョンプラン前述のフルバージョンを実施したプランです。所要時間：事前準備あり＋ WS本番丸一日＋後日半日程度 ※開催内容に関しましては、実際のテーマや実施内容等に応じてご調整させていただきます。お問い合わせは youheigoto@gmail.com まで。

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

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

Youhei Goto

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