プロダクト開発のアンチパターン
プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。
ひとつには、仕様案を持って臨むPO側の精神的な負担があまりにも大きいやり方だからです。ちゃんとした仕事をしているPOならば、そもそも仕様案なんていう細かいところにたどり着くまでに、とてつもない量の不確実性を捌いてボロボロになっているのです。プロダクトのミッション、戦略、プロダクトゴール、ユーザーの課題、仮説検証の設計、MVPの特定、そういった大上段からのヘビーな分解を繰り返して、ようやくたどり着くのが具体的な仕様案なわけで、それを実装が難しいとかでひっくり返されたらたまりません。私は最近EMの身でPO業にチャレンジしているのですが、まさにこういった場面に遭遇し、口から魂が抜ける、最後のトドメを食らうような思いを味わいました。これまでPOはこんな思いをしていたのかと反省すると共に、それでもPOの仕事を続けてきた同僚たちに畏敬の念を覚えました。
もうひとつは、単純に不確実性を下げる手続きとして効率が悪いからです。そもそも、どうしてシステムの制約や可能性を十分に把握せずに仕様が作れましょうか。技術的に何ができるのかは、仕様を考える上であまりにもインパクトが大きい変数です。それを考慮せずに仕様案を作ること自体が筋が悪いと言えるでしょう。
アンチパターンを終わりにする
このアンチパターンを終わりにするためには、もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。POの負担はこれでかなり減ります。単純にPOがひとりでフルスイングし続ける範囲が減ることで、よりアウトカムへのインパクトが大きい部分に思考リソースを割くことができます。最初から技術的な前提を組み込んで議論することで、不確実性を単調に下げていくことができるので、手戻りによる精神的なダメージも大幅に減少することになります。
こうした理想の世界に辿り着くには、少なくともふたつの要素が必要だと考えます。
ひとつはPOが早期にエンジニアを議論に巻き込む工夫です。（PO、PdM、デザイナーなど目的不確実性に取り組むことを主務とするメンバーが複数いるような規模であれば特に）プロダクトに関するすべての議論にエンジニアを巻き込むことはコストに見合わないケースが多いです。どこかでストーリーやドメイン知識、熱量を揃えるコミュニケーションに労力を割かねばなりません。そのタイミングを見極め適切なコンテンツを用意するのは、口で言うほど簡単なものではありません。私も試行錯誤の途中です。
もうひとつはエンジニアの不確実性に対処する能力です。POの能力には限界があり、常に明瞭な期待と質の良い提案をできるとは限りません。程度の差はあれそこには常に不確実性が存在します。エンジニアが、曖昧だから、実現できないからといってそれを差し戻していては状況が改善しません。ゴールに納得できるまで話を聞き出す、ゴールに沿って仕様の詳細を埋めたり、実現可能な別の仕様を提案したり、不確実性を自ら下げていくアプローチこそがプロダクト開発を前進させます。このように不確実性の高い抽象的な期待に応えられることは、多くの組織に普遍的なハイグレードエンジニアの要件でもあるでしょう。メンバーの育成にじっくりと向き合い、事業の売り上げもメンバーの給料も上げられるように頑張っていきたいものです。
以上です。エンジニアが仕様案を手戻りさせるアンチパターンはもう終わりにしよう。
