SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イベントレポート

「4つのP」でひも解くエンジニアリングマネージャーの仕事、そして生成AI時代の戦い方


エンジニアリングマネジメントは「4つのP」で成り立っている

 広木氏は、エンジニアリングマネジメントの領域を「4つのP」として整理した。

People:ピープルマネジメント

 広木氏は、人の成長と不確実性の低減が重要だと指摘する。「人の考え方にもバグが潜んでいることがあり、それをリファクタリングすることが重要」と述べ、「チームメンバーとのランチ中、会話の中で根本的な誤解が見つかり、本番環境のバグに気づいたことがある。考え方の誤りがそのままソフトウェアに反映されるケースがあるのです」と自身の経験を紹介した。

 この課題を解決する鍵は心理的安全性だ。「課題を早めに伝え合う関係性が重要で、これは単なる『機嫌取り』ではなく、プロジェクトの成功に直結する」と強調する。また、人は不確実性に直面すると逃避か攻撃を選びがちで、それを乗り越えるには思考力と関係構築が不可欠だという。さらに、「上長への報告」や「懸念点の共有」を後回しにすると、フィードバックの機会が遅れ、プロジェクトの失敗につながりやすいと警鐘を鳴らした。

 メンタリングとコーチングを通じて、メンバーが自立的に動ける環境を整えることが重要だ。「傾聴」「承認」「自己開示」を通じて信頼関係を築き、失敗を共有するカルチャーを醸成することが重要であることを共有した。

Project:プロジェクトマネジメント

 プロジェクトマネジメントでは、不確実性の低減が重要な課題となる。その本質はタスク管理ではなく、「リスク管理」だと広木氏は強調する。

 不確実性を説明する概念として「不確実性コーン」を紹介。プロジェクト開始時は見積もりの幅が大きく、進行とともに精度が上がるが、自然に収束するわけではなく、意識的な対応が必要だと指摘する。また、タスクが足し算的要素であるのに対し、リスクは掛け算的な性質を持つ。

 「一つのリスクがプロジェクト全体に大きな影響を与えるため、いかにしてリスクを早期に暴露し、対応するかが重要です」(広木氏)

 この違いを統計的な観点から説明すると、「足し算的要素は積み上げると正規分布に近づくのに対し、掛け算的要素は対数正規分布となり、裾野が長くなる」。これがプロジェクトの終了確率が予測しづらい理由だと広木氏は警告した。

リスクの管理によってプロジェクト完了の予測がしやすくなる
リスクの管理によってプロジェクト完了の予測がしやすくなる

 さらに、ソフトウェアの「目に見えない」特性が進捗管理を難しくする。「進捗は何%か」と問われても、実態を伴わない回答が返ってくることが多いため、「動くソフトウェア」を早期に示し、ステークホルダーと状況を共有することが重要だと述べた。このアプローチは、アジャイル開発の基本理念にも通じ、「隠れた進捗の要素を排除する試みでもある」と広木氏は指摘する。

Platform:プラットフォームマネジメント

 プラットフォームマネジメントでは、ソフトウェア開発の効率化と技術的負債の管理が課題となる。広木氏はこれを「ソフトウェアを効率的に開発発展させるための基礎と土台を管理し、開発者体験を向上させること」と定義した。

 そのうえで「早期に不具合を発見することで、修正コストを大幅に削減できる」と説明し、リリース後の修正は開発初期の30倍以上のコストがかかるというデータを示した。この「シフトレフト」と呼ばれるアプローチは、品質管理を開発プロセスの早い段階に移動させる考え方だ。CI/CDや静的解析、SAST/IASTといった技術投資により、品質が自動的に担保される環境を構築する。

 広木氏は「失敗できる環境を技術的に作ることが、プラットフォームマネジメントの重要なテーマ」と語った。これを「コード修正の心理的安全性」と言い換え、修正しても間違ったものが簡単にはリリースされない状況であれば、多くの人がリスクを取って挑戦できると説明した。

 技術的負債の管理も重要な課題だ。広木氏は「技術的負債の問題は、見えるものと見えないものの非対称性から生じる」と指摘し、CT検査の例を用いて説明した。医師はCT画像で内部の問題を見ることができるが、もしもCT画像がなく外見だけ見れば健康と判断するかもしれない。ソフトウェアも外から見ると問題がないように見えても、内部では深刻な問題を抱えていることがある。

 そこでソフトウェアの要素を「見える/見えない」と「プラス価値/マイナス価値」の2軸で分類。「新機能は見えるプラス価値、バグは見えるマイナス価値、アーキテクチャや開発者体験は見えないプラス価値、そして技術的負債は見えないマイナス価値」と整理した。これらの見えない要素を可視化するために、「静的解析」「アーキテクチャテスト」「ADR(Architecture Decision Records)」などの手法を活用することが重要だと提言した。

Product:プロダクトマネジメント

 プロジェクトマネジメントはプロジェクトを終わらせることが目的とも言えるが、プロダクトマネジメントは「(事業を)終わらせないこと」を目的とする。そのため、プロダクトが自律的に成長するサイクル(グロースサイクル)を構築することが本質と示し、「短期的な売上は機能だけでなく、顧客価値によるグロースサイクル、つまりオーガニックに成長していくサイクルを作ることが重要」と説明した。

 顧客にとって価値があり、繰り返し使ってもらえるプロダクトは自然と顧客が増えていく。一方で使いにくいものや価値がないもの、あるいは常に何かを追加し続けなければならないプロダクトは、顧客にとっての価値が減少していく。ここで重要なのは仮説検証のサイクルを管理することだ。広木氏は、大胆な仮説を立てて、それを実験で検証していくプロセスの重要性を説く。

 その例として大陸移動説を挙げ、「南アメリカとアフリカの海岸線の形が似ていることから、かつては一つの大陸だったのではないかという大胆な仮説を立て、それを証明する証拠を探す」というプロセスを紹介した。大胆な仮説を立てるだけでは夢想家で終わるが、それを検証することで大きな発見になるのだ。実施にあたってはすべてのデータがそろってから行動するのではなく、限られた証拠から仮説を立て、実験によって検証していく。

 広木氏は「プロダクトの成長期には、目の前の顧客課題に取り組む『活用』に注力すれば短期的な成長が見込めます。しかし、ある時点で新しいプロダクトや次の展開を『探索』していないと成長が頭打ちになる」と説明した。なお、初期段階では活用に偏ると小さなプロダクトに閉じこもってしまうため、より広い探索が必要になるという。

次のページ
一部の仕事が代替されることで、エンジニア組織が変わる

この記事は参考になりましたか?

イベントレポート連載記事一覧

もっと読む

この記事の著者

森 英信(モリ ヒデノブ)

就職情報誌やMac雑誌の編集業務、モバイルコンテンツ制作会社勤務を経て、2005年に編集プロダクション業務やWebシステム開発事業を展開する会社・アンジーを創業。編集プロダクション業務においては、IT・HR関連の事例取材に加え、英語での海外スタートアップ取材などを手がける。独自開発のAI文字起こし・...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

小林 真一朗(編集部)(コバヤシシンイチロウ)

 2019年6月よりCodeZine編集部所属。カリフォルニア大学バークレー校人文科学部哲学科卒。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/21247 2025/05/29 12:10

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー