プロダクトオーナー（PO）が仕様案を持ってリファインメントや計画に臨み、エンジニアが実現可能性や曖昧さの観点からダメ出しをして手戻りが起こる……スクラムやデュアルトラックアジャイルを志向する組織においては、一度は目にする光景だろうと思います。しかしこれは、以下のふたつの理由からひどいアンチパターンであると言えます。
このアンチパターンを終わりにするためには、もっと前段にエンジニアが議論に参加する、なんなら議論をリードするくらいのことをしていく必要があるでしょう。POの負担はこれでかなり減ります。単純にPOがひとりでフルスイングし続ける範囲が減ることで、よりアウトカムへのインパクトが大きい部分に思考リソースを割くことができます。最初から技術的な前提を組み込んで議論することで、不確実性を単調に下げていくことができるので、手戻りによる精神的なダメージも大幅に減少することになります。
ひとつはPOが早期にエンジニアを議論に巻き込む工夫です。（PO、PdM、デザイナーなど目的不確実性に取り組むことを主務とするメンバーが複数いるような規模であれば特に）プロダクトに関するすべての議論にエンジニアを巻き込むことはコストに見合わないケースが多いです。どこかでストーリーやドメイン知識、熱量を揃えるコミュニケーションに労力を割かねばなりません。そのタイミングを見極め適切なコンテンツを用意するのは、口で言うほど簡単なものではありません。私も試行錯誤の途中です。
もうひとつはエンジニアの不確実性に対処する能力です。POの能力には限界があり、常に明瞭な期待と質の良い提案をできるとは限りません。程度の差はあれそこには常に不確実性が存在します。エンジニアが、曖昧だから、実現できないからといってそれを差し戻していては状況が改善しません。ゴールに納得できるまで話を聞き出す、ゴールに沿って仕様の詳細を埋めたり、実現可能な別の仕様を提案したり、不確実性を自ら下げていくアプローチこそがプロダクト開発を前進させます。このように不確実性の高い抽象的な期待に応えられることは、多くの組織に普遍的なハイグレードエンジニアの要件でもあるでしょう。メンバーの育成にじっくりと向き合い、事業の売り上げもメンバーの給料も上げられるように頑張っていきたいものです。