開発優先度を決める上で大事にしている事

「開発優先度をどう決めるか？」簡単なようで実は難しいこのIssueについて自分なりの考えをまとめてみたいと思います。

みなさんの会社やチームでは現在開発している開発項目についてチーム全員が腹落ちした状態になっていますか？？

全員が腹落ちした状態で開発に集中できているようであればチームの状態はすごく良好なんだろうなと思います。

チームによってはエンジニアが開発リーダーからアサインされたものを進めるだけで優先度はわからない。とにかく納期を守るべし、という場合もあるかもしれません。

優先度決めの前に、そもそも開発項目にどんな種類のものがあるか？

定義や種類の分け方は様々あるかと思います。

自分なりには大体以下の種類に分けることができると考えています。

1. 戦略案件

事業KPI（ここでは売上向上に関係する指標とします。）を伸ばすための開発。

サービス継続月数を伸ばすためにアプリプッシュ通知で再訪してもらう機能の開発とかですね。

2. 利用者の要望

事業KPIには直接ヒットしないけど、利用者の利便性向上につながる開発。

3. 対応Must案件

OSアップデート対応、個人情報やセキュリティ周りの対応など

4. 整備案件

技術負債の解消、デザイン負債の解消

5. 不具合案件

あまり聞きたくない言葉ですね。不具合の影響範囲などに応じて対応する/しない、いつ対応するのか？？などを考えなくてはなりません。

優先度をどう決めるか？？

これら5つをどう並び替えるか？というシンプルな問いでは無さそうです。

実際のプロジェクトでは1の戦略案件の中にもいくつか案件があるはずで、5つの異なる種類を考慮しながら優先度をつけていく必要があります。

一定のルールを設けないと収拾がつかなくなりそうですね。。。

優先度を決めるルール

大きくこの3つの観点から決めています。

• 時期必須性
• 投資対効果
• やりたいか

時期必須性

リリース時期を守らなければいけないかどうか？の観点です。

法律対応とか、体外的なイベントと連動している、OSのサポートが終了を迎えるなどの場合はリリースを守ることが優先度MAXになるかと思います。

例えば、法改正に伴い消費税の表記を変更する必要がある場合、リリース時期は法改正のタイミングにあわせないとまずいですよね。

投資対効果

よくROIは合うかなどと言ったりしますが、開発工数に対してのリターンはどれくらいか？の観点です。

基本的には数値で試算します。

例えば、あなたのチームでは会員数が5,000人いる月額1,000円の英語学習アプリを運営していたとします。

月額モデルなので継続月数を伸ばすことが事業戦略上重要です。

継続月数を伸ばすためのアイデアA とBがあります。

アイデアA：開発コスト100万円。継続月数は0.1ヶ月伸びることが期待される

アイデアB：開発コスト200万円。継続月数が0.5ヶ月伸びることが期待される

それぞれのリターンはどうなるか？

アイデアA：0.1ヶ月×1,000円×5,000人=500,000円
100万円投資してリターンは50万円でマイナス

アイデアB：0.5ヶ月×1,000円×5,000人=2,500,000円
200万円投資してリターンが250万円でプラス

計算を簡略化してますが、リリース1ヶ月後の結果としてはアイデアBがプラス50万円で勝ち（優先度高）となります。新規会員の影響や数ヶ月後先どうなっているのかなど必要に応じて詳細なシュミレーションは行います。

あと、注意が必要なのが機能を開発して終わりじゃなくて、運用して改善し続ける前提で試算を行う必要があります。人手による運用作業が伴うものは稼働量なども考慮しなければなりません。

やりたいかどうか

なんだそれ？すごい定性的となりそうですがとても大事だと思っています。

やっぱりチームのみんながやりたいと思える開発をしたいですよね。

利用者にとって価値がある（将来的な価値につながる）と信じられるもの、自分自身がやりたいことを出来る瞬間は幸福度も上がって生産性も上がるのかな？とも思っています。

ただ、ここが一番抽象度が高いので気をつけないといけないです。

観点としてはこの2つを意識しています。

• チームとしてやりたいこと（価値観）が一致しているか？
• 腹落ちしているか？

やりたいこと（価値観）が一致しているか？

解きたいIssueやそのソリューションが自社のミッション・バリューに沿っているのか？を大事にしています。

弊社ではミッションやバリューが浸透しており、今まで大きくズレることは無かったのかなとは思っています。

「お客様が求めていることは本当にそれなのか？」、「英語力向上につながるのか？」このような問いは良くでています。

腹落ちしているか？

共通の価値観を持ったメンバーが揃っているとは言え、しっかり議論をしなければ腹落ちしないこともあるかと思います。

起案する側される側それぞれが腹落ちできるよう以下の点を大事にしたいと考えています。

• 案件起案者：ドキュメントとして言語化すること、その際なぜやるのかをしっかりと考え周囲に説明すること
• 周囲のメンバー：忖度することなく疑問や改善提案など案件内容にFBすること

定期的に部署で振り返りを行うのですが、「みんな忖度無く意見言ってるよね〜」などのコメントがあったりとオープンでフランクな環境があるからこそ腹落ちするまで議論できるのかなと思います。

結局どう決めてるのか？

記載したポイントを踏まえて最終的にはプロダクトマネージャーが優先度を決めています。

• 時期必須性
• 投資対効果
• やりたいか
• • チームとしてやりたいこと（価値観）が一致しているか？
  • 腹落ちしているか？

基本的には投資対効果が高いものから順に進めて行くことになりますが、チームとしてお客様のためにどうしてもやりたいって案件は時には優先度が上がることもあります。

プロダクトマネージャーは意見や情報をしっかり収集して短期的なROIだけにフォーカスせず少し先も見ながらチームとしてやりたいこと、実現したい世界を作っていくための推進役なんだなと思います。

最後に

優先度は機械的に決まったりロジカルに説明できないものも一部存在します。

そんな時こそ腹落ちするまでチーム内で議論することが大事なのかなと思います。

• プロダクトに対して自分の意見やスタンスを持ちながら開発をしたい
• みんなで一緒にプロダクトを作って行きたい

こんな考えをもったメンバーがプログリットの開発チームには揃っています。

少しでも興味を持っていただいた方は是非お話しましょう！！