以前の記事
5.1 プロジェクトマネージャーは開発生産性をもとに未来予測をする
ソフトウェアデリバリープロセスの中に、エンジニアだけが存在することは稀な環境です。ソフトウェア事業を作っているのはチームメンバーだけではありません。周囲を見渡すと、多くのメンバーが存在します。
特に大きな組織になってくると、チームを跨いで職種が違うメンバー（例えば、営業職やマーケターなど）に開発状況を説明し、販促戦略や営業戦略とすり合わせをして、プロダクトの価値を最大限に引き上げていきます。
そのハブになっていることが多いのは、PM（プロジェクトマネージャー）や開発組織のマネージャーです。彼/彼女らは、開発組織から提供される情報（生産性）をもとに、未来を予測します。
人と人との間に流れる情報（プロセス）を設計し、達成したいリリース目標から工数を鑑みて、開発リソースを調整し予測しながらユーザーへのデリバリー時期、速度を計算していきます。
彼/彼女らはプロセスの予測性を言語化する意味で、ロードマップやWBSを作りながら優先順位を整え、抽象的な課題に対して要求定義や要件定義を作り、開発リソースを調整してプロセス全体をマネジメントしていきます。
昨今では、Lean Startupやアジャイルといった文脈から、BMLループ（Build Measure Learn Loop）といった仮説検証プロセスを取り入れている現場も多いでしょう。
本記事では、開発組織とビジネスサイドの間にいるPMや開発のマネージャーたちが、開発生産性をどう捉えて影響を受けているかを見ていきます。
5.2 仮説検証と開発生産性の相関関係
まず、仮説検証や開発プロセスと開発生産性の紐づけについて考えます。
最初に、プロセスごとに登場する人物を整理していきましょう。BMLループでの流れになぞると、学習から施策を考える部分は、P/L責任を持っている事業責任者やPdM（プロダクトマネージャー）が担うことが多いでしょう。小さい組織や少数精鋭でのフルサイクルエンジニアリングを実践しているところでは、エンジニアやデザイナーもここに参加することはあります。
次に、仮説にもとづく施策をBuildしてProductとして形にするのは、デザイナーやエンジニアのほかに、計画の遂行をマネジメントしながら課題があればアレンジして解決していくプロジェクトマネージャーや、開発マネージャーがいます。ディレクターの場合もあるでしょう。リリースしたあとは分析や仮説の検証をデータアナリストやマーケターが行い、学習していきます。
ではここで、開発生産性が"悪い"と、仮説検証にどんな悪影響があるのかをプロジェクトマネージャー目線でいくつかのパターンから考えていきましょう。
- そもそもやりたい施策に稼働率が手一杯でアサインができない
- プロジェクトを進める中で、計画が見積もりよりも大きくズレてくる
- プロジェクトのどこを犠牲にするのかの判断調整をその都度行う
- スコープクリープによって追加予算の調整承認が必要
