開発者のためのプロジェクトマネジメント入門

開発者のための プロジェクトマネジメント入門 2023/9 シンプレクス株式会社 松本 頌

コンテンツ 発表のモチベーション 自己紹介 プロジェクトマネジメントの基本 開発者が知っておくと良いこと おわりに ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 2

発表のモチベーション 誰に何を伝えたいか

全メンバーがプロジェクトマネジメントの ことを理解しているプロジェクトは絶対 成功しそうな感じがしませんか？ シンプレクス内で数多ある開発プロジェクトにおいて、プロジェクトマネ ジメントを直接的に担うプロジェクトマネージャーだけでなく、開発リー ダーや開発メンバーに至るまで、全員がプロジェクトマネジメントを一 定以上理解している状態を実現し、プロジェクトの成功を促進したい。 そして生じた余力を組織の更なる成長機会に投下できるようにしたい。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 4

特に若手開発リーダー、メンバーが プロジェクトを乗り切る術を身につける 一助となるような話をしたい プロジェクトは常に順調とは限らない。初めての開発リーダーで右も左 も分からないかもしれないし、頼りにしたいプロジェクトマネージャー自 身がストレッチアサインで困っていたり忙しすぎて十分時間が取れてい なかったりするかもしれない。 そんな環境下でプロジェクトマネジメントの一般的な方法論を拠り所 にプロジェクトの現状を理解し、周囲を導ける人を増やしたい。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 5

重要なことは何度でも 今回の発表で触れるのは教科書的な内容が多く、既にどこかで聞い たことある話も多いかもしれない。が、繰り返し、少し違った説明を受 けることで理解が深まることを狙っている。 また、知っていればそれが出来るとは限らないが、知らずに出来るよう になるよりは知っていて出来るようになる方が簡単なはずと信じ、自 分が出来ているかは棚上げして語っていきたい。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 6

自己紹介 よろしくお願いします

松本 頌 Sho Matsumoto シンプレクス株式会社 クロス・フロンティア ディビジョン アソシエイトプリンシパル 2023 Japan AWS All Certifications Engineers AWS Well Architected Lead PMP® 2015年シンプレクス株式会社に新卒入社。 FX、暗号資産、STO領域のシステム開発や金融機関向けのITコンサ ルティングに従事。SDコンピテンシー(※)所属の(自称)アーキテクト。 資格を目標とすることで勉強するスタイル。 ※SD（システムデベロップメント）コンピテンシー：シンプレクスの中でも技術力の高さを評価さ れている精鋭メンバーからなる全社横断組織。 ソフトウェア開発技術の視点から、シンプレクスグ ループの成長とイノベーションの実現に貢献することがミッション。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 8

【余談】PMP®とは？ ”PMP® とは、PMI 本部が認定しているプロジェクトマネジメントに関する国際資格 です。 PMP® 試験は、受験者のプロジェクトマネジメントに関する経験、教育、知識を測 り、プロフェッショナルとしての確認を目的として実施されます。 専門知識を有していることを証明するために、米国PMI本部が資格認定を行うもの であり、法的な資格、免許ではありません。 PMP® 資格は、プロジェクトマネジメントに関する資格のデファクト・スタンダードとし て広く認知されており、プロジェクトマネジメント・スキルの評価基準として、IT・建設を はじめとする多くの業界から注目されています。“ 転載元：https://www.pmi-japan.org/pmp_license/pmp/ ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 9

• https://www.pmi-japan.org/pmp_license/pmp/

プロジェクトマネジメント の基本 おさらいしましょう

プロジェクトマネジメントとは？ 書いて字の如く、「プロジェクト」を「マネジメント」することだが、 そのまんま過ぎるのでもう少し分解する。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 11

プロジェクトとは？ 以下を全て満たす取り組み。 • 期間が決まっている(有期性) • 予算や資源が独立している(独立性) • 成果物が唯一無二である(独自性) システム導入プロジェクト、オフィス移転プロジェクト、などなど。 なお、プロジェクトではないものは「定常業務」と呼ばれる。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 12

マネジメントとは？ 色んな訳がありえるが、英語の以下がイメージに近い。 management : the activity or job of being in charge of a company, organization, department, or team of employees manage : to succeed in doing or dealing with something, especially something difficult 日本語の「管理」とは異なり、「責任を持って何とかする」というニュア ンス。 手続き通りに進めるだけでは不十分で、最終的な結果にコミットする 必要がある。 参照元：https://dictionary.cambridge.org/dictionary/english ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 13

• https://dictionary.cambridge.org/dictionary/english

プロジェクトマネジメントとは？（再） プロジェクトマネジメントとは、 「有期、独立、独自の取り組み」を「責任を持って何とかする」 ことを指す。 期間が決まっていて、いつもと異なるメンバーで、初めての成果物を作らな いといけないため、プロジェクトは本質的に難しいもの。 そんなプロジェクトをマネジメントするための方法論が PMBOK(Project Management Body of Knowledge)にまとめられているので以降で 紹介していく。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 14

【補足】PMBOKについて プロジェクトマネジメント協会(PMI)が発行する出版物。 初版は1996年だが、現在の最新は2021年刊行の第7版。 第7版は第6版から大きく内容が変わっているが、第6版の内容も依 然有用であったり第7版の前提知識として持っておいて損は無いため、 本発表内ではごった煮で説明する。(発表者自身区別が正確につい ていない面もある) ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 15

プロジェクトマネジメントの10の知識エリア スコープ ステーク スケジュー ホルダー ル 調達 コスト 統合 リスク 品質 コミュニ ケーション ©2023 Simplex Inc. 9の知識エリアとそれをまとめる 統合の計10個 資源 開発者のためのプロジェクトマネジメント入門 16

プロジェクトマネジメントのプロセス群 立ち上げ ©2023 Simplex Inc. 計画 実行 開発者のためのプロジェクトマネジメント入門 監視・コント ロール 終結 17

プロジェクトマネジメントのプロセス プロセス群×知識エリアで やることが定義されている 立ち上げ • • • • • • • • • • 統合 スコープ スケジュール コスト 品質 資源 コミュニケーション リスク 調達 ステークホルダー ©2023 Simplex Inc. 計画 • • • • • • • • • • 統合 スコープ スケジュール コスト 品質 資源 コミュニケーション リスク 調達 ステークホルダー 監視・コント 実行 • • • • • • • • • • 統合 スコープ スケジュール コスト 品質 資源 コミュニケーション リスク 調達 ステークホルダー 開発者のためのプロジェクトマネジメント入門 終結 ロール • • • • • • • • • • 統合 スコープ スケジュール コスト 品質 資源 コミュニケーション リスク 調達 ステークホルダー • • • • • • • • • • 統合 スコープ スケジュール コスト 品質 資源 コミュニケーション リスク 調達 ステークホルダー 18

主要なプロセス間のフロー 計画でスコープ、コスト、スケ ジュールのベースラインを定義 計画に則り実行しつつ、 監視・コントロールを効かせる ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 19

プロジェクトのアプローチの種類 以下の3種類に分類される。 1. 予測型（ウォーターフォール型） 2. 適応型（アジャイル型） 3. ハイブリッド型：1と2の中間 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 20

アプローチをどう選択するか？ 〜ステーシー・マトリックス〜 左下に近い(合意と確実度 が高い)ものは予測型、右上 に近いものは適応型が向く ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 参照元： https://www.praxisframework.org/en/library/stacey- matrix 21

• https://www.praxisframework.org/en/library/stacey-matrix

【余談】プロジェクトマネジメントに 最も重要な資質は？ プロジェクトマネジメントにおける9割の時間はコミュニケーションに費や される。 そのため、コミュニケーション能力が必要ということになるが、これは社 交的であるという意味ではなく、意思を適切に伝えて人を動かすため の論理性や感情的知性やリーダーシップ、顧客の様子から隠れた要 望や不満を見出す洞察力や関係性を築く力、問題が起きた時に日 和見せず仲介し、時に人間的な問題には腹を割って話せる胆力、 などを併せ持つ必要があるということである。 当然最初から全てを備える人は稀だが、覚悟を持つことが第一歩。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 22

開発者が知っておくと 良いこと ようやくメインテーマ

開発リーダーと プロジェクトマネジメント 開発リーダーは開発プロジェクトにおける開発全般に責任を負い、そ の中にはプロジェクトマネジメントの要素も含まれている。プロジェクト マネージャーとそれをどう分担するかはケースバイケースだが、まずは自 分がプロジェクトマネジメントも全てやるぐらいの気概でいた方が安全。 それだけでなく、開発リーダーはアーキテクチャの検討やエンジニアリン グプラクティスの導入、更に自ら開発を担うこともあるので、なかなかヤ バいロールである。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 24

開発者のためのスコープマネジメント 〜ゴールポストを動かさない〜 適応型は変化が前提のため、厳 密な変更管理は不要で、バックロ グにやりたいことを都度足していく スコープ・クリープの防止 金メッキを避ける • スコープ・クリープや金メッキのように スコープ・ベースライン通りに成果物 が作られないことを防ぐために、変更 管理プロセスを設ける 開発者が良かれと思って起きるこ とが多い • ROI (投資対効果)の悪化につ ながる可能性が高い ベースライン確定後のスコープ変更 は必ず変更管理プロセスで承認を 得る • 大規模なプロジェクトでは第三者に よる変更管理委員会を設ける • スコープ・クリープとは、スコープ・ ベースラインからスコープが変わっ ていくこと • 金メッキとは、元々のスコープ以上 の過剰な機能や品質を提供する こと • ステークホルダー起因で起きること が多い • • 安請け合いしてはいけない • ©2023 Simplex Inc. 変更管理の徹底 開発者のためのプロジェクトマネジメント入門 25

開発者のための スケジュール＆コストマネジメント 〜その順調に根拠はあるか〜 - 見積もり手法 - 現状と見通しの確認 - クリティカル・パスの分析 - ファスト・トラッキングとクラッシング ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 26

見積もり手法色々 手法 説明 類推見積もり • 過去事例や経験による見積もり • トップダウン見積もりとも呼ばれる • 精度はあまり高くない(類似度や経験次第) パラメトリック見積もり • • • • ボトムアップ見積もり • 要素分解して個別に算出したものを積み上げる見積もり • 時間はかかるが精度は最も高い 統計的な情報と変数を用いる見積もり 係数見積もりとも呼ばれる ファンクションポイント法がこれにあたる 類推見積もりよりは精度が期待できる 上記の手法から、楽観値、最頻値、悲観値の三値を算出した上で、三点見積もりを行うこともある。 三点見積もりは類推見積もりと組み合わせられることが多い。 三値は単純平均で加味する場合も重みづけする場合もある。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 27

不確実性のコーン 〜そもそも最初から正確な見積もりは無理〜 見積もりのブレ(縦軸)はプロジェクトの初 期では非常に大きいので、プロジェクトが 進んでから再度見積もること(段階的詳 細化)や適応型を取り入れることが重要 参照元： https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/ ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 28

• https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/

【補足】適応型での見積もり 絶対見積もりと 相対見積もり プランニングポーカー Tシャツ見積もり • 「時間」、「人日」など単位がある のが絶対見積もり、単位がないの が相対見積もり • フィボナッチ数列の書かれたカード を使い、開発者全員で見積もり を行う • Tシャツの一般的なサイズ(S, M, L, XLなど)の表現を使い、開発 者全員で見積もりを行う • 相対見積もりの方が見積もりがサ クサク進むし、合意しやすい • 投票したカードの数字がずれてい たら話し合い、合意する • • https://firepoker.io/ などで オンラインでも実施できる プランニングポーカーと基本は同 様だが、数字でないので時間以 外の要素(複雑さなど)もイメージ しやすいとか ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 29

現状と見通しの確認 〜Earned Value Managementの紹介〜 スケジュール、コストの計画に対し、現在地が どこか、着地見通しがどうなるかを評価する手 法。この手法を使うかはともかく、これらの指標 を計測可能にしておくことは非常に重要。 参照元：https://www.innovationmanagement.co.jp/column/no17/ ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 30

• https://www.innovationmanagement.co.jp/column/no17/

クリティカル・パスの分析 〜アクティビティの依存関係の整理〜 赤のルートがクリティカル・パス。 クリティカル・パス上のアクティビティの 遅延はプロジェクトの遅延に直結す るので特に注視が必要。 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 31

ファスト・トラッキングとクラッシング 〜状況に応じてテコ入れし、スケジュール短縮を図る 〜 ファスト・トラッキング ©2023 Simplex Inc. クラッシング • (本来は順序依存のある)アクティビティを並行で 実施する • クリティカル・パス上のアクティビティに追加で資源 を投入する • (メンバーはそのままなので)直接的な追加コスト は発生しない • (メンバーが増えるので)追加コストが発生する • 既存メンバーが対応するより費用対効果は悪化 する • 作業内容が複雑化し、作業負荷が上がる • 本質的に手戻りリスクがある 開発者のためのプロジェクトマネジメント入門 32

【補足】人月の神話 〜人と月は交換できない〜 COCOMO法による工期と工数の関係 人数増によるコミュニケーションパス増 3 𝐿 = 2.7 𝐸 L：工期(月) E：工数(人月) 100人月なら12.5ヶ月が標準工期 ※2.7の部分は組織次第 人員追加時のキャッチアップ、チー ムからの頭出し、内容によっては分 業できないことも踏まえると理解の 助けになるかもしれない 参照元： https://qiita.com/hirokidaichi/items/7f7f7881acba9302301f ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 33

• https://qiita.com/hirokidaichi/items/7f7f7881acba9302301f

【補足】リソース効率とフロー効率 タスク単位ではフロー効率の方が早 いが、全体の完了はリソース効率の 方が早い。フロー効率的である方 が将来の変化に対応しやすい。 リソース効率 • メンバーの稼働率を高く維持することを重視 • • 手が空いたら次のタスクに進むので全体が完了 するまでのリードタイムが短くなる 優先度の高い成果物のリードタイムを短くするこ とを重視 • • スコープが決まっている予測型に向いている 並行で複数のタスクを作業するよりも最優先の ものに注力するので、最優先のものはリードタイ ムが短くなるが、全体のリードタイムは(リソース効 率的な作業と比較して)長くなる傾向 • スコープが決まっていない(変わっていく)適応型 に向いている タスクA ©2023 Simplex Inc. フロー効率 タスクB タスクC 開発者のためのプロジェクトマネジメント入門 タスクA タスクB タスクD タスクC 34

開発者のための品質マネジメント 〜品質を作り込む仕組みまで作り込む〜 品質マネジメントの計画 • • • 成果物に対して、いつどのように 品質を保証するかの計画 「SMART※」な品質尺度を定 義し、達成度合いを計測、評価 する ソースコードだけでなく設計書や 作業プロセスも品質保証対象に なる ※Specific, Meaningful, Achievable, Relevant, Timely ©2023 Simplex Inc. カイゼンのPDSAサイクル • • 品質コストの類型 作業プロセス自体を振り返り、 カイゼンしていく 適合のコスト：不良防止のコスト • 予防コスト：品質の作り込み Check(評価)だけでなく Study(学び)を得る • 評価コスト：テスト PLAN ACTION DO 不適合のコスト：不良対応のコスト • 内部不良コスト：内部で発見 • 外部不良コスト：外部で発見 ⇒適合のコストの方が安い STUDY 開発者のためのプロジェクトマネジメント入門 35

開発者のための資源マネジメント 〜集団からチームへ〜 - チームの立ち上げ - チームの動機付け - チームのコンフリクト解決 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 36

チームの立ち上げ 〜参考プラクティスの紹介〜 チームラーニング • • • それぞれのメンバーが自身のワーキ ングスタイル(稼働時間帯、コミュニ ケーションスタイルの好み、得手不 得手など)を共有 予めお互いのことを知ることで摩擦 を減らす 共有された内容を踏まえ、チームと してのルール(チーム憲章)を明文化 すると良い ©2023 Simplex Inc. RACIチャート • あるアクティビティに対して、誰が 実行責任(R)、説明責任(A)、 相談対応(C)、情報提供(I)を 行うかの表 • アクティビティ毎にRは1人だけ • それぞれのメンバーの責任を明確 にし、作業の漏れを防ぐ 開発者のためのプロジェクトマネジメント入門 スキルマップ • あるスキルを誰がどのレベルで保 持しているかの表 • 自己申告で作成しオープンに管 理する • 現状だけでなくプロジェクトを通じ た目標も合わせて表現するとベ ター 37

【補足】タックマン・ラダー 〜チームは急に立ち上がらない〜 短くても1週間程度はかかる 成立期 動乱期 • チーム形成初期 • チーム活動開始 • メンバー追加され るとここに戻る • メンバーが利己 的になり対立す る ©2023 Simplex Inc. 安定期 •チーム内の立場が 安定 •プロジェクトの問題 に集中 開発者のためのプロジェクトマネジメント入門 遂行期 • チームがお互いを 信頼し、高い パフォーマンスを 発揮 解散期 • プロジェクト解散 間際、別れを惜 しみパフォーマン スが低下 38

【補足】心理的安全性 〜Googleの研究から〜 『Google のリサーチチームが発見した、チームの効果性が高いチームに固有の 5 つの力学のうち、圧倒的に重要なのが 心理的安全性です。リサーチ結果によると、心理的安全性の高いチームのメンバーは、Google からの離職率が低く、他 のチームメンバーが発案した多様なアイデアをうまく利用することができ、収益性が高く、「効果的に働く」とマネージャーから 評価される機会が 2 倍多い、という特徴がありました。』 『心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、 無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味し ます。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の 過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余 地があります。』 ※心理的安全性がある＝空気を悪くしないために言うべきことを言わない馴れ合いのチーム、ではないことに要注意 転載元：https://rework.withgoogle.com/jp/guide s/understandingteam-effectiveness/#introduction ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 39

• https://rework.withgoogle.com/jp/guides/understanding-

【補足】ジョハリの窓 意識的な自己開示で「開放の窓」 を広げつつ、1on1、360度評価、 ななめ会議などを通じて 「盲点の窓」を減らしていく 他人は分かっている 開放の窓 盲点の窓 自分は 分かっている 自分は 分かっていない 秘密の窓 未知の窓 他人は分かっていない ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 40

チームの動機付け 〜人は何に動機付けられ働くのか〜 XY理論、Z理論 モチベーション3.0 欲求理論 X理論：働く目的は収入のみ 1.0：生きるため 達成欲求：目標の達成 Y理論：優れた作業を行うこと 2.0：アメとムチ、インセンティブ 権力欲求：責任が増えること Z理論： 3.0：内発的動機付け、楽しさ 親和欲求：チームへの受け入れ ①自己実現、価値のある仕事 ⇒20%Timeによるサイドプロジェクト など、自主性を尊重 ②家族の幸せ、雇用の安定 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 あくまで参考でしかないが、これらを 参考に各メンバーが何に動機付け られるかを推測し、パフォーマンス向 上に役立てる 41

チームのコンフリクト解決 どの対処方法を取るかはケースバイ ケースだが、解決プロセスに公平性 が感じられることが双方の納得感の ために重要 対処方法 状況 例 対峙・問題解決 • コンフリクトを解決すべき問題と扱い、取り組 む • Win-Win 「この問題の根本原因を分析しましょう」 協力 • コンフリクトに複数の見方を取り入れる • Win-Win 「お互いの意見をどちらも満たせる方法を考 えましょう」 妥協 • お互いに譲歩できる点を見つける • Lose-Lose 「折衷案を採用しましょう」 鎮静・適応 • より高次の目標など同意している点を重視 「次のリリースを成功させたいという目標は同 じですよね」 強制 • 時間がない時、一方の意向を強制 • Win-Lose 「今回はこの方針に従ってください」 撤退・回避 • 先送り 「今考えるのはやめよう」 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 42

開発者のためのコミュニケーションマネジメント 〜LISTEN, SYN, ACK〜 送信者と受信者の責任 適切なコミュニケーション方法を選 択する 送信者の責任 多種多様な方法から適切なものを選択する • 明確な情報を伝えること • 書面(Slack、メール、etc) • 正しく伝わっていることを確認すること • 口頭(対面、リモート) • 「伝わったことが伝えたこと」 • 公開、非公開 • 公式、非公式 受信者の責任 ©2023 Simplex Inc. • 情報を完全に受信し、正しく解釈するよう努めること • 受信確認や応答を確実に行うこと 開発者のためのプロジェクトマネジメント入門 重要なことは「顔を見て話す」が原則 43

開発者のためのリスクマネジメント 〜対策のあるリスクはそんなに怖くない〜 リスクにはポジティブなものもあ るが、以下の戦略はネガティブ なリスク(脅威)に対するもの リスクをどれだけ事前に挙げられるか、 リスク一覧をメンテナンスし続けられる かはプロジェクトの安定に直結する リスクの洗い出しと監視 • • • リスクの優先度付け リスクの洗い出しはプロジェクト開 始直後から実施し、記録する • 日々のプロジェクト活動で追加で 検出されたリスクも随時追記する • 個別のリスクは分析の上、優先 度付けし、担当を割り当てて必 要な対策を実施する ©2023 Simplex Inc. リスクの優先度は「発生確率×影 響度」のスコアで決まる 影響度はプロジェクト目標(コスト、 期間、スコープ、品質など)に応じ た影響として定義する 開発者のためのプロジェクトマネジメント入門 リスクの対応戦略決定 戦略 説明 受容 何もしない、または時間、金、 資源を準備だけしておく 回避 脅威を取り除く 転嫁 脅威の影響を第三者に移転 軽減 発生確率や影響度を低減 エスカレー ション 上位マネジメントや別部署に 引き継ぐ 44

開発者のための統合マネジメント 〜We all gonna make it!〜 - リーダーシップの発揮 - プロジェクトの推進 ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 45

リーダーシップの発揮 SL理論 相手の成熟度によって異なる リーダーシップ・スタイルを用いる ©2023 Simplex Inc. PM理論 課題達成機能、集団維持機能 の両方の高いリーダーを目指す 開発者のためのプロジェクトマネジメント入門 重要なのは相手や状況によってリー ダーシップを使い分けること、そのた めに複数のスタイルを身につけること サーバント・リーダーシップ メンバーの成長や自律性を下支 えするリーダーシップ 参照元： https://leadershipinsight.jp/explandict https://www.servantleader.jp/about 46

• https://leadershipinsight.jp/explandict
• https://www.servantleader.jp/about

プロジェクトの推進 日々の状況確認 変更管理、 リスク・課題管理 • メンバーの稼働、健康状態、チー ム内の不和、作業のブロッカー • 日々の状況確認の中で検知した 変更やリスク、課題を記録する • カンバン、バーンダウンチャート、ベ ロシティの状況と傾向 • 変更はプロジェクトマネージャーが 対応余地あるか検討の上で、変 更管理プロセスに回す • マスタスケジュール、ステークホル ダーの状況、顕在化したリスクや 新規リスク、課題がないか • リスク、課題は一覧化して記録し、 必要なら担当を決めて対応、定 期的に状況をアップデートする ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 ナレッジの記録と横展開 • プロジェクト内で得られたナレッジ は随時記録する • その中でプロジェクト外にも還元 可能なものは、組織全体に共有 する 47

【補足】開発チームの定期イベントの例 頻度 イベント 説明 日次 朝会 • • • 前日作業実績、当日作業予定、困っていることの確認 時間をかけすぎずに終わらせる 少なくとも週次程度ではプロジェクトの全体状況も確認する ペアプロ、モブプロ • • 課題解決を全員参加で行うための時間 ナレッジシェアも兼ねている マネジメント報告 • • プロジェクトマネージャーに開発状況やリスク、課題の報告、相談を行う 開発リーダーだけ出ることが多い 顧客報告 • • 顧客にプロジェクト状況の報告、必要に応じ要件の調整や詳細確認、リ スクの共有を行う 開発リーダーや担当者が出る場合がある ※プログラミングに限らず 週次 隔週 振り返り • • 開発チームの作業プロセスを振り返り、改善箇所を発見する 改善もタスクとしてそれ以降の作業計画に盛り込む 月次 全体会 • プロジェクト全体で状況の共有やマネージャー、リーダーからメッセージの発 信を行う ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 48

おわりに これからのはじまりに

全開発者がプロジェクトマネジメント のことを理解している最高の組織へ ここまでプロジェクトの中での開発者の振る舞いに、プロジェクトマネジメントのス キルや考え方がどのように関係するかを述べてきたが、両者は切り離せるものでは なく、特に開発リーダーをやる場合はどちらも出来ることが求められる。 自身の専門性として、プロジェクトマネージャーとエンジニアのどちらの道を突き詰 めるか、といった二項対立もよく聞かれるが、これらは少なくともある程度までは同 じ道であり、プロジェクトの大部分が開発プロジェクトである組織においてはどちら もやれるに越したことはないので、積極的に「二刀流」を目指してほしい。 そしてプロジェクトの炎上を無くし、浮いた時間でもっと楽しく、もっと世の中にイン パクトのある案件を、もっとたくさんやっていける最高な組織にしていこう！ ©2023 Simplex Inc. 開発者のためのプロジェクトマネジメント入門 50