こちらは kubell Advent Calendar 2024 シリーズ2 12月13日分の記事です。
こんにちは。都志（@louvre2489）です。 プロダクト開発チームのEMをやっています。
さて、プロダクト開発における「開発スピード」と「プロダクト品質」のバランスを取るのは非常に難しいものです。 概念実証やプロトタイプ開発など、後続の運用保守をあまり考えないで良いケースでは「開発スピード」に全振りできることもあるかと思いますが、多くのケースで求められるのは相応の時間をかけて相応に良い設計を行い、その中で相応に速いリリースを行うことであり、「開発スピード」と「プロダクト品質」に要はバランスを求められることかと思います。
しかし、場合によっては「開発スピード」がとても重要視される（リリース時期に強いコミットが求められる）ケースもあります。そのような場合に、エンジニアとしては「プロダクト品質」を維持するためにはどのようなアプローチが考えられるでしょうか？
直近で私自身がそのようなケースに遭遇したので、その時に立てた計画について紹介したいと思います。
「開発スピード」と「プロダクト品質」
「開発スピード」と「プロダクト品質」は必ずしも反比例の関係にあるわけではありませんが、
- コチラに手を入れるのであれば、全体感的を踏まえてアチラにも手を入れたい
- 今のアーキテクチャーの延長線上に作ると歪になるので、アーキテクチャーを整えたい
- インフラを再設計することで、現インフラの上に構築するよりもコストが安くなる
など、中長期目線で考えるとスピード／品質の両方をペイするが、短期目線で考えると時間をかけざるをえないというケースは往々にして発生します。そのために必要な時間を下手に削ると、中長期的には維持することのできないプロダクトが完成します。
短期目線で考えると時間をかけざるをえないような場合に適切な品質と適切な工数を見極めて計画を立てるのは（多かれ少なかれ各所からの圧もかかるので）ただでさえ難しいものですが、その中でもリリース時期に強くコミットしないといけない場合の計画立案／推進はより一層難しいものとなります。
早くリリースしたいんジャー ＆ ちゃんと作り込まんとらマン
早くリリースしたいんジャーの主張
- 少しでも早くユーザーへ価値を提供したい
- ユーザーに触ってもらって初めてわかることが色々ある
- などなど…
わかる！そりゃあ一刻も早くリリースしないとダメですね！！！
ちゃんと作り込まんとらマンの主張
- プロダクトコードは少しでもキレイに保っていきたい
- バグだらけのプロダクトによって最終的に被害を被るのはユーザーなので、そのような状況は生み出したくない
- などなど…
わかる！そりゃあプロダクトはコードは常にキレイに保っておかないとダメですね！！！
どないすればいいんジャー
どうすればいいんでしょうか？
双方の主張を整理する
この時に意識しないといけないのが、「各関係者が必ず達成したいことは何なのか？」です。これを開発における定数として捉えます。定数は各々の思惑によって都合よく変更することができないものです。
一方で、調整可能な要素を変数として捉えます。変数は擦り合わせによって変更することが可能なものです。
つまり、
- 定数：調整困難な譲れないポイント
- 変数：調整可能なポイント
です。
ステークホルダーの持つ定数（＝必ず達成したいこと）
- ユーザーへの早期価値提供
- そのリリース内容を踏まえて、ユーザーからどのようなフィードバックが来るかを確認したい
エンジニアの持つ定数
- 中長期的に運用可能なプロダクト品質の担保
実際の開発現場は複雑なので他の要素も定数として出てきますが、「開発スピード」と「プロダクト品質」が対立するケースの双方から確実に出てくるのは上記のような内容だと思います。
これら定数を適切に扱いながら計画を立案／遂行していく必要があります。
定数の存在を無視してしまうと...
エンジニアの持つ定数（＝「プロダクト品質」の担保）を蔑ろにして計画／推進する場合、以下のようなやり取りの発生が想定されます。
ステークホルダー：「最速でリリースお願いね！」 〜 開発の進行 ＆ 完了 〜 ステークホルダー：「 お、リリースできたね！じゃあ次はコレでお願い！」 エンジニア：「（品質がどんどん悪化していく…）」
一方で、ステークホルダーの持つ定数（＝ ユーザーへの早期価値提供）を蔑ろにして計画／推進する場合、以下のようなやり取りの発生が想定されます。
エンジニア：「俺ら、良いプロダクトを作っていけてるぜ！」 〜 なかなか終わらない開発〜 エンジニア：「 俺ら、良いプロダクトを作っていけてるぜ！！！」 ステークホルダー：「（で、いつリリースできるんじゃい…）」
いずれにせよ自分たちの持つ定数を蔑ろにされた側が不満を抱くこととなってしまいます。しかし、このままでは双方の定数を維持しながら計画を立案できる気がしません。
どうすれば良いのでしょうか？
こないすればいいんジャー
※
前提が変われば定数が変数に変化する（その逆も然り）ことがありますが、話が複雑になるのでここでは考慮しません。
以下が変数の調整例です。
ステークホルダーへの変数調整
- ユーザーへの早期価値提供ができるならば、その後にプロダクト品質維持活動のための時間を確保できないか？
エンジニアへの変数調整
- 最終的なプロダクト品質は担保できるようにするので一時的な品質劣化は許容して、まずはユーザーへのリリースを優先できないか？
上記例では、「リリース後の時間」と「一時的なコード品質」を変数として扱っています。
※
ここでトレードオフにしているプロダクト品質は、「短期間であれば何とかなる」というレベルの品質を指しています。アーキテクチャーレベルでの課題を抱えていたり、コスト課題があるようなケースを指し、バグだらけのプロダクトを指しているわけではありません。
バグだらけのプロダクトは例え短期間であっても何ともなりません！
もちろん、この擦り合わせの中で新たな定数が見出されることもありますが、それらを適切に扱いつつ計画を立案していく必要があります。
上述した変数の内容で開発計画の調整を行う場合、以下のような計画ができあがります。（計画に絶対的な答えはありません。計画例の１つです。）
- 「中長期の維持が可能な品質状態のプロダクト」を最終的に得られるところまでを開発スコープとする
- そのための経過地点として、「ユーザーからフィードバックが得られる状態」を作り出してリリースを行う
- このタイミングのリリースはあくまでも一連の開発の途中段階、と位置付ける
- 早期リリースを実現するために、短期的に許容可能な範囲での品質劣化は許容する
今回の例では話をシンプルにするために扱う要素を少なくして話を進めましたが、開発における定数と変数を適切に見極めて計画に落とし込むことが関係者間での不満が（比較的）少ないプロダクト開発に繋がります。
注意点 と まとめ
長々と書いてきましたが、ぶっちゃけ今回説明したような「開発スピード」と「プロダクト品質」の調整は可能な限り行うべきではないと考えています。このような調整を行うことで必ず何らかの犠牲が必要となります。（とはいえ、私は直近で採用したのですが...）
そのため、冒頭にも記載した相応の時間をかけて相応に良い設計を行い、その中で相応に速いリリースを行うことを原則とする必要があると考えています。（「開発スピード」と「プロダクト品質」を良いカンジに両立し続けることはとても難しいことですが...）
一方で、開発における要点を定数と変数に抽象化して切り分けた上で調整ポイントを見出す考え方は、どのような開発においても活用することができると考えています。変更困難な要素と変更可能な要素の扱いを誤らないことが、合意を得やすい計画立案に繋がります。
このような考え方はスムーズな計画作りの助けになるので、計画作りに行き詰まったら定数と変数を意識して検討内容を整理してみることをオススメします。
