プロダクトの非機能的な改善をビジネスの中でどのように進めるかは、多くのチームが頭を悩ませる課題であると思います。本記事では私が最近考えていることをまとめてみようと思います。主に自社プロダクトの継続開発を想定した議論をします。
前提
まず非機能改善について議論する上で、重要な前提がふたつあると思っています。
ひとつは、我々は常に共通の目標を持っているということです。プロダクトのミッションや期の目標のことです。ビジネスサイドの人もエンジニアも、そうした目標を達成するためにそこにいることに違いはありません。機能開発も非機能的な改善も、見ている時間軸が多少違うことはあれど、この目標を達成するための手段です。それらが一見対立するように見えるのは影響を与える指標が違うからです。
もうひとつは、非機能改善に「やらない」という選択肢はないということです。システムにはデフォルトで滅びる方向に力が加わっています。変更を加えればそれだけ散らかるし、変更をしなくてもライブラリやミドルウェアが古びていきます。競合はより開発効率がよかったり、採用力のある形へとシステムを変えていきます。技術的に変化のないプロダクトからはエンジニアも離れていきます。それらを見過ごせばプロダクトはいつか必ず望まない形で滅びます。プロダクトに未来があるならば、なんらかの形で非機能改善に投資し続けるのが賢い選択です。僕のメンターはよく「税金みたいなもんです」と説明していて、これは僕もお気に入りです。
非機能改善の工数をどう確保するか
以上の前提を踏まえて、以下のようなルールを設けると上手くいくと考えます。
POと開発チームは機能開発の目標についてのみ詳細を約束する。非機能改善については工数の割合だけ合意して、詳細は開発チームに委ねる。
この立て付けに至る思考
私は機能開発と非機能改善の間で優先度を細かく議論することが不毛であると考えます。先に述べた通り、機能開発と非機能開発で影響を与える指標は違います。ユーザーを増やす機能開発のタスクと、変更のリードタイムを小さくする非機能改善のタスクを戦わせるにも、見ている指標が違うのだから判断のしようがありません。いや、正確には議論の余地はあって「変更のリードタイムがN%下がるなら、Mヶ月後にユーザー増加の損益分岐点がくるから今のうちにやりましょう」といったふうにつながることもあるのですが、そこまでやりたいですか？という話です。
にもかかわらず、非機能改善にやらないという選択肢はありません。であれば、それこそ税金を払うように、ソフトウェア開発というのはそういうものだと割り切って一定の工数を開発チームに渡してしまうのが賢いやり方だと考えます。全く違う視点からプロダクトを思っている二者がいるのであれば、素直に工数を分け合ったら良いのです。その取り分については事業のロードマップやシステムの状況をもとにチームで議論しましょう。そこで具体的な取り組み内容に踏み込むと泥沼に逆戻りするので、非機能改善をおおよそ10〜30%くらいの間で適当にキメをするのが良いとは思います。大きなプロジェクトで、見積やチームのベロシティがわかっていればこうした議論の助けになるでしょう。
この立て付けを機能させるポイント
上に述べた立て付けは、言ってしまえば「やることやったからあとは好きにするね？」ということです。開発チームが事業の重要な目標にコミットし、POが必要とする進捗を生み出し続けることが大前提としてあります。ろくに機能もできあがってこないのに非機能改善をやるといわれても、それを了解するのは難しいでしょう。逆に、POも開発チームがプロダクトを良くすることを信頼し、チームのキャパシティを使い切らないように計画を立てる必要があります。事業の目標を中心にして、POと開発チームが信頼関係を構築することが重要だと考えます。
そもそもこうした関係の構築をできないくらい事業上の要請が厳しかったり、チームが組成されていなかったり、システムがレガシー化しているケースも世の中には溢れているはずで、そういった場合はまずそこを改善しなければ議論は前に進まないでしょう。
また、この立て付けを機能させるには、短期的な小さい目標について約束するスタイルが不可欠です。「3年後に目標を達成できたら良いので工数は自由に使ってください」とだけ言われて、非機能改善の工数をコントロールするのは至難の業でしょう。もっとも典型的なソリューションはスクラムにおけるスプリントゴールで、1週間や2週間といった単位で機能開発に関する目標を設定し、残りのキャパシティを非機能改善に回す形を取るのが簡単でしょう。もちろん、こうしたことをやるための大前提として、全てのタスクに一貫した見積もりが入っていて、チームのベロシティが計測されていることが必要です。
この立て付けの欠点
上に述べた立て付けは、POと開発チームの間の摩擦が減り、開発チームが裁量を持てることから、割と良い形だとは思うのですが、欠点もあります。
それは開発チームの性善説に依ってしまう点です。それほど効果や学びのない非機能改善に時間を使い続けるようでは工数の無駄です。開発チームには、裁量と引き換えに、自分たちがやろうとしていることがプロダクトの成長に寄与するか熟慮する責任が生まれます。もし効果の高いタスクが見つからないのなら、進んで工数を戻して機能開発を前進させるようなフォロワーシップを発揮することも期待されます。こうした姿勢をチームとして維持することは簡単ではありません。
まとめ
ソフトウェアの非機能的な改善の工数をどういう立て付けで確保すると良いかについて書きました。私がいまのところ上手くいくと思っているのは、工数の割合だけ合意して、詳細を開発チームの裁量に委ねるやり方です。イテレーティブな開発プロセスの中でPOと開発チームが信頼関係を構築することが重要になるでしょう。「機能開発をすべきか非機能改善をすべきか」はとても難しい問いで、完璧なロジックを立てて采配するのは困難であると思っています。工数の割合という形で近似して素早くキメをして、集中できる環境を作れると良いのではないかというのが現状の見解です。
