アジリティに欠けるプロダクト開発は人手不足に陥りやすい
自社ソフトウェアプロダクト開発が慢性的な人的リソース不足に陥りやすい背景は、いたってシンプルです。「アジリティ（agility）」がないこと。ほんと、これに尽きる。プロダクトマネジメントの問題であって、採用では解決しません。
私自身の経験や、観測可能な範囲からではありますが、アジリティのないプロダクト開発に共通する特徴として、次の三つが挙げられます。
・ロードマップに個々の開発案件をプロットしている
・数か月規模で開発する案件を抱えている
・人的リソースが分散している
本稿では、これらを「人手不足に陥りやすい、アジリティに欠くアンチパターン」としてその問題点を明らかにします。あわせて、それぞれ対にする「人手不足に陥りにくい、アジリティに優れたプラクティス」についてもお話していこうと思います。
［アンチパターン1］ロードマップに個々の開発案件をプロットしている
経営層とのコミュニケーションツールとして「ロードマップ」を用いるプロダクトマネージャーは多いと思いますが、そこに何を描くかについては、組織によって違うようです。その中でも、ここでアンチパターンとして挙げるのは、ロードマップを、リリース計画を明らかにするための「粒度の大きなガントチャート」のように位置付けているケースです。つまり、ロードマップに、個々の開発案件の「着手日」や「リリース日」をプロットしているパターンです。
このパターンにある組織は、そこに書かれた機能追加や機能改善といった開発案件を計画通りリリースまで終わらせることに強く囚われます。「ロードマップを介して経営層とのコミットメントとなった開発案件を簡単に反故にするわけにはいかない」というプロダクトマネージャーの思考が、開発案件をそのように位置付けるからです。その意識は、開発チームにも伝搬します。
この「聖域化」した変更し難い計画の存在が、プロダクト開発からアジリティを奪い、人手不足を頻発させることになるのです。
ロードマップを描くタイミングや、大きく手を加えるタイミングは期初が多いと思います。様々な開発案件がプロットされることになるわけですが、そもそもこの時点では、各開発案件の要件がまだ具体化されていないことも多いのではないでしょうか。そんな段階で計画された開発案件が、実際に問題なく進むとは思えません。当たり前のように遅延が起こり、スコープ調整が頻発します。何とかリリースまで漕ぎ着けても、スコープから外した積み残しの対応に追われることになります。
そのうえ期中には、当然のように新たな開発案件が次から次へと発生します。それでもロードマップに書かれたリリースは変えられない。仕方がないから、無理に並列で開発しようとする。当然ながら、みな手一杯で新たな開発案件に関わる余裕がない。
このようにして人手不足に陥っていき、プロダクト開発は破綻していきます。
［プラクティス1］ロードマップに開発テーマをプロットする
多くのビジネスは、組織目標となるKGIと、それに紐づくKPIツリーを定義しています。プロダクトに対する機能追加や機能改善といった開発案件は、いわばそのツリーの最末端KPIに対する施策（アクション）です。
計画された施策をしっかり実行することも確かに大切なのですが、その通り実行したからといって、期待された成果が伴うとは限りません。十分な成果が得られなければ、新たな施策を追加したり、既存の計画に変更を加えることになります。だから、個々の施策の実行に過度なコミットメントがあることは、成果をあげる上でかえって弊害となり得ます。
経営層とプロダクトマネージャーとの間でコミットすべきは、もう一段階抽象度の高い戦術レベルが適しています。いつからいつまでの間に、どのような戦術に取り組み、それによってどのKPIの数字をどれだけ上げるのか。ロードマップへは、それをプロットします。戦術の具体には、一つ以上の施策の実行が伴いますが、その施策はプロットしません。
プロダクト開発における戦術とは、「開発テーマ」とでも呼べばよいでしょうか。いくつかの機能追加や機能改善を繰り返すことを通してKPIを引き上げる、一貫性のある手段です。
開発テーマのもとでどのような機能追加や機能改善を行うかは、プロダクトマネージャーと開発チームの間で話し合って決めればよいでしょう。こうすることでプロダクト開発は、状況に合わせて施策を臨機応変に組み替え可能にするアジリティを手に入れられます。結果、人手不足に陥りにくくなるというわけです。
※このプラクティスについては、本稿とは少し違った観点で整理された良い記事があります。本稿を書くにあたり、私自身も参考にさせていただきました。
［アンチパターン2］数か月規模で開発する案件を抱えている
開発に何か月もかかるような案件を計画する組織も、アジリティが低いと言えます。
開発期間が長ければ長いほど、環境不確実性が高くなり、状況変化による影響を受けやすくなります。最もよくあるケースは、途中で新たな開発案件が追加され、その人的リソース確保のために、進行中の開発案件の計画変更に追われることです。
こういった計画変更は決して簡単なものではありません。進行中の開発案件のスコープを見直し、それに基づいて開発規模を見積もりし、追加された案件を並走させられるか、リソース計画も含めて調整する。既存案件、新規案件両方のリリース日が期待する範囲におさまらなければ、またスコープの見直しからやり直しです。そうしている間に時間がどんどん過ぎていきます。これではあまりにアジリティがない。
また、同時並行で進める案件が増えると、人手不足に陥ります。この状態から更に開発案件が追加されることになれば、計画変更はますます困難になり、見積もりや調整にばかり時間を取られ、肝心の開発業務に悪影響を及ぼすようになってしまいます。
［プラクティス2］数日規模で開発可能な単位で案件を分ける
だったら、ひとつの開発案件を数日や、長くても1、2週間で開発してリリースできる単位に小さく分ければ良いのです。そうすれば、組織のアジリティが上がります。
途中で新たな開発案件の差し込みがあっても、進行中の開発案件の計画を変える必要はありません。数日や1週間も待てばその案件は終わります。その後に着手を予定していた開発案件を後ろにずらし、新たな開発案件をそこに差し込む。こうすれば並列開発数も増えず、人手不足に陥りにくい。状況の変化に対し、見事に即応できています。
さらにこのやり方は、開発テーマにフォーカスすることとの親和性も高い。開発テーマに紐づく開発案件を、KPIの動きを見ながら短いサイクルで調整していくスタイルを手に入れられるからです。
実際にこのやり方を導入しようとすると、二つの課題にぶち当たります。開発案件を小さく分割すること自体に高い能力が求められることと、短期間でのリリースを可能にする技術力や仕組みが必要になることです。実現難易度は高いのですが、チャレンジする価値は十分にあると思います。
［アンチパターン3］人的リソースが分散している
人的リソースがどのような開発案件にどれぐらい割りあてられているのを精査してみると、興味深い事実が見えてきます。ユーザーやビジネスにとって、短期的にも中長期的にもそれほど大きな価値を生み出さない案件に、リソースが大きく割かれていることが見えてくるからです。優先度の低い開発案件に人が奪われ、優先度の高い開発案件が手薄になっていることがよくあるのです。これが、人的リソースを枯渇させる最も大きな原因です。
「重要な開発案件ほど優先的に人的リソースを割り当てる」という、この当たり前の原則は、思うほど徹底されていないものです。
人的リソースの割り当ては、現場の判断に委ねられています。しかし、現場に近づくほど、ビジネスやプロダクトに関して見える範囲は狭まり、状況が捉え難くなります。その限られた視界の中で、適切に人的リソースを配置することは難しい。個別最適が進み、人的リソースが分散配置されてしまうのも仕方ありません。
しかし、リソースが分散しているということは、並列で進んでいる開発案件が多く存在するということです。その分、個々の開発案件のリソース割り当ては薄く、パフォーマンスを十分に出せない状況に陥っているはず。遅延する開発案件が頻発し、どこも「人手が足りない」と嘆いていることでしょう。
このような状況下にあっては、変化に応じて新たな開発案件を新たに差し込む余裕なんて無くなります。調整しようにも、大変な労力と時間を奪われてしまいます。
［プラクティス3］人的リソースを集中させる
どこにリソースを割くべきか、現場での判断がより適切になるよう、もっと俯瞰的な視座から明らかにしておくことが重要です。
先ほども述べた通り、開発案件は、開発テーマを戦術として具体化された施策です。したがって、リソースを多く割くべきなのは、KPIへの影響度が大きな開発テーマだと考えられます。
このような「重点開発テーマ」とでも呼ぶべき対象をいくつか決めておき、それら全体に対し、常時、何名程度の人員を割くかを決めておきます。「全30名のうち、15名から20名程度は常に重点開発テーマに割く」といった具合です。もちろん、実際のリソース状況を定期的に確認する必要があります。その上で、リソースが集中配置されていないようなら、配置を見直します。
ここで注意が必要となるのは、短期的にはKPIへの影響度が低くても、中長期を見据えて今やるべき開発テーマも、優先度を上げてリソースを割かなければならないという点でしょう。こういったテーマは、プロダクト内部のメンテナンスが多いと思います。そのような取り組みを怠ると、プロダクトは中から徐々に腐ってしまいます。そうなれば、中長期視点でKPIにネガティブな影響を与えてしまいます。
なお、ここで想定している開発体制は、開発案件の都度、チームを編成する「プロジェクトチーム」体制ではありません。5名から9名程度のメンバーが固定で配置された「プロダクトチーム」体制です。この二つの体制の違いは前回の記事を参照いただきたいのですが、重点開発テーマへのリソース割り当ても、この固定メンバーのプロダクトチームを前提に考えることになります。
人的リソースを制約条件として戦略を練る
ここで挙げた3つのプラクティスは、相互に関係しています。ひとつだけを実践しても、大きな効果は得られないかもしれません。基本的な考え方は、人的リソースを「制約条件」として捉えることです。制約があるからこそ、戦略が必要になる。
逆に言えば、人的リソース不足に陥りやすい組織は、戦略性がないのかもしれません。必要だと思う開発案件全てを同列で扱い、その量を基準に人的リソースが不足していると嘆く。そこには、限られたリソースの中で最善の結果を出そうとする戦略性は存在しません。あるのは山のように積み重ねられた一貫性のない施策だけです。
この記事が気に入ったらサポートをしてみませんか？