フクロウの図表ラボ

取り巻く状況

私が関わらせて頂いたプロダクト開発は以下のようなものでした。

• 特定の業務というより、フルパッケージ的に一通りの業務をこなせるプロダクトをコンセプトにしていた（範囲が膨大）
• ユーザーヒアリングさせて頂きながら詳細なプロセスを”汎用的に”設計していった（SaaSなので）
• メンバー全員がフルリモート体制
• その会社でアジャイル開発は初めての試み
• 最初は1つのスクラムで、その後2つ、3つへ拡大した

アジャイル宣言通りに実践できない点

アジャイル（×スクラム）で開発を開始するタイミングで、アジャイル宣言をメンバーで文字通り読み上げて認識合わせをしました。

特に実践できていたのは、（少なくとも社内では）対話を重視していたこと、動くソフトウェアの尊重＝文書化の最小化、変更への対応の尊重です。フルリモートだからこそ、意識的に対話しなければと思えたのかもしれません。

一方で、上記の表より細かいレベルで見ていくと、

• 顧客満足を最優先して継続的に価値あるソフトウェアを提供する、のは体力的に厳しかった（継続的な機能アップデートはなかなかできない）
• 「動くソフトウェア」のリリースが頻繁にできなかった（本番稼働前は顧客向けにUATという工程を踏んだ）
• ビジネスサイドと開発者は日々一緒にプロジェクトで働く、は社内でできていない。
• 定期的に振り返りをして、自分たちのやり方を最適に調整する、がPdMチームはなかなかできていなかった

というのはあったかなと思います。（うろ覚えかつあくまで主観ですので実態と齟齬がある部分はあるかもしれません）

UATという言葉が出てくる点に違和感を感じられたかと思いますが、私達が最初のプロダクトローンチをするタイミングでは、あるクライアントに受け入れられるようなプロダクトを要件をすり合わせながら構築する、ということをやっていたためです。将来像としてはSaaSとしてクライアントには我々のプロダクトを提供し、”使いこなしてもらう”ことですが、少なくとも最初のローンチは自分たちが要件決定する主体ではありませんでした。この点でもステークホルダーの複雑性という特殊な状況があったように思います。

顧客が望むプロセスは後で

プロダクトのステークホルダーは誰か？というと、SaaSを生み出し世に広めるという文脈では自社の経営陣、およびプロダクトオーナーです。どんなビジネスモデルを元に、どんなユーザーにどんなプロダクトを届けるか、意思決定しているはずですので。

自分はPOの立場も担っていましたが、正直、「顧客が望むプロセスは後で」という判断を、スクラム以前にPdMで半分以上していたように思います。本来目指したいプロセスとそれを実現する機能は構想にあるのですが、設計もできているのですが、スクラムにも提示していなかったということです。

マイルストーンや開発体力的な論点はもちろんあるのですが、本来は自主的に開発を進めていくことがメリットのスクラム開発において、天井を設定してしまうような、本当に勿体ないことをしていたなあと思っています。

私達がスクラムを選んだ理由の1つに、膨大な開発スコープに対してユーザーストーリーレベルでさえプロダクトアウトラインの具体化が追いつかない＝できることから着手する、という考えがありました。いわば「変更への対応の尊重」に甘えるような形で、”あとから追加で（別範囲の）要件を投げ込むからトータルでいい感じに作ってください”といった流れです。

話を戻しますと、「本来目指したいプロセスの提示 / そのプロセスへの変更」をスクラムに提示できなかった理由は、そのときにはもう影響箇所が多く複雑で、プロセスを理解してもらう労力を割くことができなかった、ためもあるのです。図で見ると各業務がきれいに分かれているかに見えますが、当然（？）そんなことはなく、業務Bでの変更は業務Cにも影響します。

結果として、アップデートするなら一緒に、業務横断的な視点でメンバーがしっかり理解できるタイミング（キリのいいタイミング）で着手しよう、という力学が私には働いていました。

コミュニケーションの肥大化と属人化

前項と重なりますが、この機能って何で必要なんです？将来的にどんな風になるのが理想なんですか？という質問はありがたくもスクラムメンバーから多くもらっていました。開発着手の本当に最初のタイミングでは、ユーザーストーリー（全網羅すると200以上）の読み合わせを何時間もかけてやり、その場を借りて口頭での業務説明もやっていました。

ただし新しいメンバーは入って下さったタイミング、またはスクラムチーム構成の変更があったタイミングに同じことはできていませんでした。都度質問頂けると嬉しいですが、質問者が疑問に思うことも一定ではないので、本来はPdM（PO）の目線から「これはプロダクトを作るうえで知っておいてほしい」という点をこちらから発信しておくべきです。乱暴に言うと、本当に実現したいプロセスの認知が属人化していった過程だったかなと思います。

自主性の力は信じたい

手っ取り早い方法は「この機能を作ってください」と、より細かいレイヤーで指定するやり方なのは自明かと思います。ウォーターフォール的な開発だと、詳細設計レビューを終えてから実装しますので、機能レベルで指定していることと同意ですね。また、特に規模が大きくなればなるほど、アジャイルは開発スピードが早い手法だとは言えないことも実感しました。

アジャイルで「顧客や開発者の問題解決能力と直接的な対話を重視する」における、”開発者の”問題解決能力は、自主性が発揮できる環境があってこそ花開くものです。社外の顧客と開発者が頻繁に空間を共にし、円滑なコミュニケーションができるコンディションなどほぼ無いのですから、そうするとその間に立つであろうPdMがあたかも対話すべき顧客*のように、問題解決に必要な情報を十二分に深く、広く提供することが必要なのです。

*特定の顧客のみならず、ターゲット市場全体を指す”顧客”の場合もあると思います。いずれにせよ、PdMはプロダクトに対する要求の解像度を高く把握できているべきという意図で書いています。

つまり、私が最も強く感じた問題はPdMが顧客の理解することではなく、顧客が求めるプロセスをその背景・根拠を開発者へ同じ解像度で伝えきるのが難しいことでした。これができない限り、真の意味で自主性を発揮できる環境ではないと個人的には思います。また、開発者（ここでは主にエンジニアを指します）には、そのエンジニアリングに必要な専門性を日々キャッチアップすることが求められていて、一方で顧客ニーズについても自主的な深い理解を求めるのは、PdMにコーディングもできるようになってね。と言っているのと同じです。

機能レベルでなくプロセスも含めて、なぜ顧客にとってそれが必要なのか？将来の目指す姿はどう描けそうなのか？を共有できるコミュニケーションは本当に難しいと感じました。PdMはきっと、顧客要求のエバンジェリストたるべきなのでしょう。