この記事は Kyash Advent Calendar 2023 21日目の記事です。
Kyashでプロダクトマネージャーをやっている Ueda です。
プロダクト開発に勤しむ皆様も、きっと今ごろ年内最後のリリースに向けて奮闘中でしょうか。
私もなんだか忙しいなあと思う日々が続いており、「なんでこんなに忙しく感じるのだろうか？これが師走か？」とふと振り返った時に自分がプロダクト開発において無意識に意識していることが影響していそうだというのに気づきました。
今回はその「自分がプロダクト開発において意識していること」、具体的には「開発速度を高めるために意識していること」について書いてみようと思います。
*テクニカルな内容を書くつもりはなく、とても当たり前な内容を、未来の自分に釘を打つ意味でも書いています
「開発速度をあげたい」という声
「開発速度をあげたい」という願望を持った方、またはそういう要望を受け止めたことがある方は、たいていの会社にいらっしゃるのではないでしょうか。
また、そういう話題に対して「アーキテクチャを〜」「技術的負債を〜」「コードの品質を〜」など、技術的アプローチで解決しようとする話を聞いた方も多いのではないでしょうか。
しかし、「顧客に価値を届ける」という一連のプロダクト開発において、実装フェーズはあくまで一つのフェーズであるため、それを実現するための工夫や努力は技術的アプローチだけに閉じないはずです。
実際にKyashでも過去に「もっと早くリリースしたい」というステークホルダーからの要望を聞くこともありました。
その時に「価値提供を早くする工夫は、技術的アプローチ以外にないのか？」という疑問が自分自身の意識のスタート地点であり、本エントリーの主旨です。
開発速度を高めるために
今回はタイトルの通り、PdMとして「技術的アプローチ（実装速度）」とは異なる形で開発速度を高めるために何ができるかについて、以下の2軸で書きたいと思います
- プロダクト開発フェーズ毎にできる工夫
- プロダクト開発フェーズを常に並行して行う気概
1.プロダクト開発フェーズ毎にできる工夫
今回は便宜上プロダクト開発フェーズを以下の3つに分類し、各フェーズ毎の工夫についてあまり多くてもアレなので、よくあるchips形式で2つほど羅列します。
- 価値検証フェーズ
- 企画/要件定義フェーズ
- 開発フェーズ
価値検証フェーズ
とにかく早くスタートする
ここが全てのスタート地点となるので、とにかく価値検証を始めましょう。
1つのイシューに対しての解像度や解像度を高めるプロセスの長さは、ものによってバラバラになることもあるため、価値検証フェーズが一定の期間で終わることはありません。
こうした不確実性の高いフェーズでは、誰かのGoの合図を待つのではなく、余裕を持って早く始めてしまうことが重要です。
自信が持てるレベルまで行う
「出したものが使われない」が一番の恐怖であり、一番の時間のロスになります。
百発百中全てのリリースでインパクトを出すというのが究極の目標ではありますが、実際それは難しく、このフェーズでできる大事なことは「とにかく成功確率を高める」ことでありそのために自信が持てるレベルまで検証を行う必要があります。
価値検証はどこまで行っても検証であり、実際に作って提供してみないとわからない領域ではあるので、「最低限ここまでは確認/検証をする」「このフレームワークで情報整理する」といった型があると、次に進めるための自信に繋がるのではと思います。
企画/要件定義フェーズ
不要なものを落とす（優先度を明確に下げる）
単純ですが、不必要にスコープを広げないことはとても重要です。
「仕様の擦り合わせに時間がかかる」「開発工数が膨らむ」「QAのテストケースが増える」といったように、一度広げてしまったスコープは以後全てのプロセスに影響を及ぼします。
初期に要件から落としたものが将来的に必要になることもあるため、最初から要件に記載しないのではなく、「やりたいけれど優先度は低い」といったような形で残しておくと、そういった想定を加味した設計で初期リリースを迎えられるため、再開時の実装もスムーズになります。
ステークホルダーとの連携は早く
KyashのようなFintechサービスでは特に、社内だけではなく社外の事業者と進める機能、場合によっては関係省庁への事前共有が必要になってくる機能もあります。
社内ならまだしも、社外との確認については望んだタイミングで希望通りの確認結果が返ってくる訳ではないので、仮にこの事前確認が少しでも遅れると、そもそものスタートが大幅に遅れてしまいます。
なので価値検証フェーズで大まかな仕様概要が決まり次第、なるべく早く社内の各部署に共有を行い、必要に応じて外部のステークホルダーへ連携することが重要になります。
開発フェーズ
早い意思決定とレスポンス
とても当たり前なことですが、「PdMの意思決定の遅さで開発の手を止めるわけには行かない」という考えはかなり意識しています。
コードを書かないタイプのPdMである自分にとって、開発メンバーの疑問を早く解消し、手が止まる時間を少しでも減らすことがこのフェーズにおいて可能な工夫の一つだと考えています。
他の業務もある中でSlackに張り付いてレスポンスの早さだけを極めていては本末転倒ですが、可能な範囲では質問者が「こいつは bot か！？」と勘違いするぐらいの早さで反応することを目指したいところです。
不要なものを落とす（優先度を明確に下げる）part2
プロダクト開発ではアウトカムが最重要でありますが、その手前ではやはりアウトプット（リリース）が必要です。
「〜月までにアウトカムを出したい」という目標があるのであれば、それを実現するために、開発フェーズのタイミングでも再度要件の取捨選択が求められる場合があります。
企画/要件定義フェーズでの取捨選択との違いは、明確なリリース目標が近づいているという制約があることでさらにシビアな目線での精査が可能になります。
企画/要件定義フェーズで「これは必須だろう」と考えていたものが、リリース目標という制約（ルール）や誓約（覚悟）を課すことによって、「やはり必須ではないな」と考えを改められる程には判断の精度が上がると考えています。
2.プロダクト開発フェーズを常に並行して行う気概
前章で各フェーズについての工夫を記載しましたが、むしろこちらが今回の本題であり、なぜ私が「なんか忙しいな〜」と感じたかの要因です。
前章では色々書きましたが、ここで言いたいことは一つで「開発速度を高めるためにPdMは常にマルチタスク状態であるべき」ということです。
つまりは「前章で書いたフェーズを常に全て同時に走らせている状態を作るべき」ということです。
（ただし開発フェーズによって担当チームが別れており、完全に委任しているといった組織ではこの考えは該当しない）
PdMがシングルタスクで開発フェーズをこなしてしまうと、単純に実装メンバーの次の開発着手まで待ちが発生してしまいます。
実装メンバーが一つのリリースを迎える時、PdMがすぐに次のパスを出せる状態を作ることはProject / Feature単位ではなくProductとして見た時に、開発速度を上げることに大きく寄与すると考えています。
そう思うと「一個人の生産性を下げるマルチタスク状態が、チームの開発速度を上げる」という矛盾に向き合う気概がPdMには求められるのではないでしょうか。
終わりに
プロダクト開発に勤しむ皆様も、きっと今ごろ年内最後のリリースに向けて奮闘中でしょうか。
そしてもう次の価値検証や要件定義は始まっていますでしょうか。
今回の内容が自分自身も完璧にできているかと言われると100%自信を持ってYesといえない部分もありますが、何かあるたびにこの記事を読んで、今後もこの意識していければと思います。
2024年も良いスタートが切れるようにギリギリまで仕込んでいきましょう！
