2024/1/4 加筆修正を行いました
初稿を書いた後に、さらなる経験、色々な方との対話、各種資料を通じて考え方が更新された部分があったので加筆修正を行いました。主要なポイントは以下です。
- 仕様案の手戻りが発生しないようにエンジニアに積極的に情報を開示していくのはPOの重要なプラクティスであると分かったので、その考え方に沿って整理しなおしました
- POになりたてのいわゆるパニックゾーンにいる時に書いた文章で、全体的にエンジニアに責任を転嫁するニュアンスになっていたので修正しました
プロダクト開発のアンチパターン
プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。
ひとつは、単純に不確実性を下げる手続きとして効率が悪いからです。そもそも、どうしてシステムの制約や可能性を十分に把握せずに仕様が作れましょうか。技術的に何ができるのかは、仕様を考える上であまりにもインパクトが大きい変数です。それを考慮せずに仕様案を作ること自体が筋が悪いと言えるでしょう。
もうひとつには、こうした状況に陥ってしまった時のPOのダメージが著しく大きいからです。そもそも仕様案を作るのはとても大変な仕事です。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返し辻褄を合わせる膨大な情報処理を行うことで、ようやく筋の通った仕様案に辿り着くのです。そうして血の滲むような工程を経て捻り出したアウトプットがエンジニアのひと声で差し戻されると、口から魂が抜けるような思いを味わいます。これをPOの段取りが悪いと一蹴するのは簡単ですが、あまりにPOの負担が大きくないかとも思うのです。
アンチパターンを終わりにする
このアンチパターンを終わりにするためには、もっと前段でエンジニアが議論に参加してフォローしていく世界観が理想だと考えます。POの負担はこれでかなり減ります。単純にPOがひとりでフルスイングし続ける範囲が減ることで、よりアウトカムへのインパクトが大きい部分に思考リソースを割くことができます。最初から技術的な前提を組み込んで議論することで、不確実性を効率良く下げていくことができるので、手戻りによる工数面と精神面のダメージも大幅に減少することになります。
こうした理想の世界に辿り着くには、少なくともふたつの要素が必要だと考えます。
ひとつはチームで不確実性に対処する能力です。POの能力には限界があり、常に明瞭な期待と質の良い提案をできるとは限りません。程度の差はあれそこには常に不確実性が存在します。エンジニアが、曖昧だから、実現できないからといってそれを差し戻していては状況が改善しません。ゴールに納得できるまで話を聞き出す、ゴールに沿って仕様の詳細を埋めたり、実現可能な別の仕様を提案したり、不確実性を自ら下げていくアプローチこそがプロダクト開発を前進させます。このように不確実性の高い抽象的な期待に応えられることは、多くの組織に普遍的なハイグレードエンジニアの要件でもあるでしょう。
もうひとつはPOが早期にエンジニアを議論に巻き込む努力です。ユーザーの課題やプロダクトの目標に日常的に触れて考えてもらうことが重要になります。他のメンバーを信頼し、自己組織化されたチームとして成長できるよう、自らが抱える課題やアイディアを積極的にオープンにしなければいけません。また、自分と同じ目線で思考して前向きな提案ができる、いわゆる「右腕」のようなエンジニアを見つけて頼るのも有効な手段でしょう。
