NewsPicks Advent Calendar 2024 一日目の記事です。
こんにちは！ソーシャル経済メディア「NewsPicks」の安藤です。長らくSREチームのプレイングマネージャーをしていたのですが、最近はEMとして自分の技術的専門性とは異なる担当領域の開発チームもサポートしています。
その中で気づいたのが、「プロジェクトマネジメントを通じてならどのチームでもエンジニアリングマネージャーとして一定のバリューを発揮できるかもしれない」ということです。
私自身は前職で10年以上プライムのSIerに在籍しており、PMを務めたことはありませんが一流のPMの元で開発リーダーとして一緒に仕事をした経験はあります。*1
SEの必須研修として『プロジェクトマネジメント基礎』という一週間の座学をした程度の知識ですが、スクラムが中心の事業会社のエンジニアにとっても意外と役立つTIPSがあるので思い出しつつ調べつつご紹介したいと思います。
プロジェクトマネジメントとは
「エンジニアも知っておきたい」という趣旨と後述のTIPSにフォーカスするためここではあえて正確な定義ではなく私見を書きます。 プロジェクトマネジメントとは「プロジェクトをなんとかすること」だと考えています。
マネジメントは日本語では「管理」という印象を持たれがちですが、英語のmanageという動詞は、辞書を引くと「どうにかする」「うまく対処する」といった意味があることがわかります。
manage
〖manage to do〗 (苦労の末に)どうにか…する; ｟皮肉で｠ ものの見事に…する;
｟話｠ …にうまく対処する; 〈時間･金など〉の都合をつける
〈時間･金･資源など〉をうまく使う, 活用する
〈事業･組織など〉を運営する, 経営する; 〈土地･建物など〉を管理する; 〈チームなど〉を監督[指揮]する; 〈芸能人など〉のマネージャーをする; ｟主に英｠ 〈庭など〉をきれいにしておく
〈扱いにくい物事〉をうまく処理する; 〈機械･道具など〉を使いこなす; 〈人･動物など〉をうまく扱う, 操る
(出典：ウィズダム英和辞典)
「〈時間･金･資源など〉をうまく使って」「〈扱いにくい物事〉をうまく処理する」もまさにプロジェクトマネジメントだと思います。これらの意味をまとめて「なんとかする」のがマネジメントです。
プロジェクトとは
「なんとかする」プロジェクトとは何ぞやという話がありますが、こちらは素直に定義を引っ張ってきます。
プロジェクトは「独自性」と「有期性」を持つ取り組みです。*2
- 独自性：プロジェクトには独自の成果物がある（定型化された既知の作業ではない）
- 有期性：プロジェクトには明確な始まりと終わりがある（完了条件のない定常業務ではない）
つまり、すでに手順書があったり繰り返し行われる業務以外のすべての仕事はプロジェクトと言えるでしょう。
新しい機能を開発してリリースすることもプロジェクトですし、サービスの不具合対応もプロジェクトです。
懇親会の企画もプロジェクトです。「プロジェクトをなんとかすること」を自分ごとにできそうですね。
プロジェクトには大きなものから小さなものまであります。歴史上有名な大規模プロジェクトには「マンハッタン計画」や「アポロ計画」があります。
月面着陸のような人類史上初の偉業を達成するためのプロジェクトマネジメントは想像を絶する困難で比較にならないと思えますが、「独自性と有期性を持つ業務をなんとかする方法」まで抽象化すれば「自分にとって初めての開発」といったエンジニアの業務にも同じPMBOK（プロジェクトマネジメント知識体系）の手法を適用できます。
カレー作りで学ぶPMBOKの実践的TIPS
プロジェクトマネジメントの身近な例として、カレー作りを考えてみましょう。
あなたは夫・妻・3歳の子供の3人家族で夫役だとします。妻がプロジェクトオーナーであり、あなたが担当者です。
妻「私が子供と遊んでるから、あなたは夕食のカレーを作ってくれない？作り方はカレールウの箱の裏面に書いてあるからその通りにやれば1時間くらいでできるはず。それより時間がかかりそうだったら教えてね」
夫「わかった。作ったことないけどやってみるね」
「1時間でカレーを作る」という目標のもと、作り方の通りにざっくりと計画を立てました。
作り方のステップに見込みで所要時間を当てはめただけですが、これなら40分弱でカレーが完成しそうです。
段階的詳細化
さて、具材を炒めようと冷蔵庫を開けましたが、そもそも具材を切る必要があることに気づきます。具材を切る時間を一旦10分程度と考え「炒める」タスクの先行に配置しました。
冷蔵庫から具材を出していくうちに、この量の具材を10分で切るのは自分のスキルでは難しいと気づきます。肉は包丁を数回いれるだけだからいいとして、野菜の皮むきと一口大に切る作業は1個あたり3分ほどかかりそうです。
最初は10分と考えた「具材を切る」タスクは25分となりました。このように、プロジェクトの進行に伴って入手する情報によって取り組むタスクが具体的になり、計画が詳細化していくことを 「段階的詳細化」といいます。ほとんどのプロジェクトにはこの特性があります。定型作業でも定常業務でもないので、不確実性はどうしても発生するものです。
当然、後続の工程でも同じように計画が詳細化されることが予想できますが、実際にタスクに取り掛かってみないと入手できない情報もあり予測がつきにくいため、直近で実施する作業のみを詳細化しておき、先のタスクは大まかな計画に留めておくことで、直近のタスク状況の変化から全体タスクの調整余地を残しつつ目の前の作業に集中することができます。このような進め方を「ローリング・ウェーブ計画法」といいます。
実際には、野菜を1つ処理するごとに見積もりの時間との予実を補正し、有利差異が発生すれば再度計画を見直して予定より早く終る可能性もあります。とはいえ、この計画時点で1時間を少し越えそうなことがわかり、プロジェクトオーナーである妻にアラートを上げることを考え始める頃合いです。
クリティカル・パス
ここでプロジェクトオーナーである妻から追加オーダーが入りました。
妻「ご飯が炊けてないから、炊いておいてね〜」
米を研いで炊く作業を単純にここまでのタスクの後続に追加すると、炊飯で55分程度追加の時間がかかります。
ただし、米を炊くためにカレーの完成を待つ必要はないことから、米を研ぐ作業を先に行って炊飯器に任せてしまえば、完了時間への影響は3分で済みます。
このように並行するタスクを組んだときに、最も時間がかかる最長経路のことを「クリティカル・パス」といいます。
米を研いだ後に、炊飯器で米を炊く時間よりもカレーを完成させる時間の方が長いからです。そのため、
夫「追加タスクによるクリティカル・パスへの影響は研ぎ時間の3分で、今時点で目標完成時間である1時間を少々超える可能性が出てきています。」
とプロジェクトオーナーに一報できると良いでしょう。クリティカルパスを管理できている言動に安心感を持たれ、予定していた1時間のギリギリになって「遅れます」というより心象が良いですし、後続で相談を持ちかける時に心の準備ができます。
（実際の夫婦生活でこのように事務的な受け答えをすると別の問題が発生する可能性があるのでご注意ください。）
ファスト・トラッキング
現時点でクリティカル・パス上の作業工程の完了予定時間が64分となっています。どこかで5分短縮して1時間以内に収めることはできないかと考えました。
「水を入れ、煮込む(20分)」の作業では、水を入れ、沸騰してから15分と記載されていたため、沸騰に要する時間を加味して見積もっていました。しかし、具材を炒めた後で最初から沸騰したお湯を入れれば沸騰にかかる時間は短縮できます。そこで、具材を炒めている間に電気ケトルを使って沸騰したお湯を作ることにしました。
このように、通常は順番に実施されるタスクを所要期間の一部で並行して実行することを「ファスト・トラッキング」といいます。
作業順序の変更になるので、作業や成果物の品質についてのリスクを考慮する必要があります。例えばこの場合、「沸騰してから15分」という作り方こそ守っているものの、「沸騰するまでの時間で具材に火が通っている時間が省略され、十分に火が通らないかもしれない」という品質面のリスクが発生する可能性があります。
システム開発によるファスト・トラッキングでよくある対応は、「複数機能の開発を同時に進める」「開発とテストを同時に進める」などがあります。上手くいけばスケジュールを短縮できますが、デグレードや品質不良に対する考慮が必要です。
品質面のリスクを許容できるかが判断できなかったため、別の方法も検討することにしました。
クラッシング
炒める・煮込むなど加熱の作業には短縮の余地があまりないものの、「具材を切る(25分)」については自分のスキルと作業スピードがネックになっていることがわかっていたため、この作業のみ妻に手伝ってもらうことを考えました。具材の皮を剥く・切るにタスクを分割し、2人で並行作業することで具材を切る作業の時間短縮ができます。
このように、クリティカル・アクティビティ（クリティカルパス上のアクティビティ）に資源追加（人員追加・残業・追加発注など）によって期間を短縮することを「クラッシング」といいます。上記の例ではタスクの並行も行っているためファスト・トラッキングも組み合わさっていますが、具材の皮を剥く・切るを一部並行しても品質面に問題はないので、妻に手伝ってもらうという資源追加が可能かどうかの判断になります。
QCDSを調整する
ファスト・トラッキング、クラッシングのどちらかの案をを採用すれば1時間以内に完了することは可能な見込みができましたが、どちらもPros/Consがあるため採用しない方法もあります。
プロジェクトにおける不確実性に対処する意思決定のフレームワークとして、QCDSを利用すると良いでしょう。QCDSは品質(Quality)、価格(Cost)、納期(Delivery)のQCDにSを加えたもので、Sは業界によって安全(Safety)だったりサービス(Service)だったりします。システム開発においては責任範囲(Scope)で考えることが多いです。
今回のカレー作りプロジェクトにおいては、QCDSすべてを達成するのが難しいと思われるため、「品質に妥協する(Quality)」「妻の工数を投入する(Cost)」「時間をオーバーする(Delivery)」「作るカレーの量を減らす(Scope)」などいずれかを調整する必要があります。それぞれの案のPros/Consをプロジェクトオーナーである妻に真摯にコミュニケーションすることが重要です。
| 調整事項 | 対処 | Pros | Cons |
|---|---|---|---|
| Quality | ファスト・トラッキングにより煮込む前のお湯の沸騰に電気ケトルを使う | 追加コストなしでDelivery・Scopeを達成可能 | 具材に火が通るのが不十分になる可能性がある |
| Cost | クラッシングにより妻に具材を切る作業工程を手伝ってもらう | 品質リスクなくDelivery・Scopeを達成可能 | 子供を見ている妻の作業工数が取れるかどうか |
| Delivery | 予定完了時間の1時間をオーバーする | Quality・Costを達成可能 | 子供が空腹に耐えられるかどうか |
| Scope | カレーを12皿分ではなくルウ半量(6皿分)で提供する | 1人でQuality・Cost・Deliveryを達成可能 | 翌日のカレーが用意できない |
プロジェクトオーナーの視点に立てば、どれを調整するのが一番楽か、現場の担当とは違うものが見えています。4パターンの提案があれば「子供は今テレビを見てるから具材切るの手伝えるよ」「子供はおやつ食べたから多少遅くなっても大丈夫だよ」など、あっさり調整できるポイントもあるはずです。
システム開発なら「テストを省略してリリース後不具合のリスクを許容する」「追加人員を投入したり残業をしてリリースに間に合わせる」「リリース延期を希望する」「リリースする対象の機能を削減する」などがあります。
終わりに
本記事で紹介したTIPSはPMBOKで紹介されているごく一部の戦術的な項目ですが、プロジェクトの計画を段階的に詳細化し、クリティカルパスを意識したタスクの先行関係の組み替えを行い、工期を短縮するためにファストトラッキングやクラッシングを行い、プロジェクトゴールのQCDSを調整することで、「プロジェクトをなんとかする」ことができると理解いただけたのではないでしょうか。
プロジェクトマネジメントと言っても大仰なスキルではなく社会人の普段の仕事で求められる「報連相」や「段取り」を的確に行うことに尽きるのですが、エンジニアがこれをできると意外と差別化要素になり、リーダーやPdM・ビジネス関係者からの信頼につながるでしょう。結果ただリスケになるとしても、自分から説明して提案するのと何も言わずに直前で「できませんでした」を繰り返すのではプロとしての見え方が大きく異なります。
システム開発には不確実性がつきものであり、チームスポーツです。仕事の完成という目標の中で、圧倒的な技術力・手を動かす速さ・時には残業する体力でやり遂げる「力こそパワー」の戦い方もありますが、プロジェクトマネジメントを知って調整・交渉・合意形成を含めたしなやかな立ち振る舞いも覚えておくといつか役に立つのではないかと思います。特にチームを率いるリーダーやエンジニアリングマネージャーのお役に立てれば幸いです。
