ディスカバリーの汽水域
おひさしぶりです。Mutureのさらしーです。
前回に引き続き、丸井グループ・marui unite ・Mutureの有志メンバーによるアドベントカレンダーに参加しています。
今回が本編です。コンセプトを実際にプロダクトにするためのディスカバリーとデリバリーの汽水域（合流領域）のお話と、チームに対して私が実際にしていたことの二本建てでお送りします。
なお、前回は前書きとして歴史とコンセプトを作る必要についてお話しました。コンセプトの話なのでちょっと読み辛いですが、よろしければご一読くださいまし。時間が空いたので、少し振り返ってから本編に入ります。
ディスカバリーをしたい理由: https://note.com/sarashino/n/n4a6c783807eb
いろんな土壌と環境で、あなた達だけの音楽が生み出されてるんでしょう？
前回のまとめ
前回はとにかく文脈を読み、ユーザーのパターンを改変できるようなコンセプトを打ち出すことが必要なのだという話をしました。サボって（というか間に合わず）画像を一つも入れなかったので、簡単なものではありますが前回記事の図解も載せておきます。
考えの根底には下図の環世界の概念があります。ユクスキュルの環世界は100年間休む間もなく擦られているので、みなさま飽き飽きしているかもしれません。環世界を踏まえ、上記の図では客体として「世界のありよう」と我々が恣意的に干渉する範囲としての「新たな価値の開発」があり、内的世界に「文脈」と「ふるまい」がある形です。論理学においては紀元前4世紀半ばから18世紀のカントまでアリストテレスから大きな進展がなかったことを鑑みると、ユクスキュルの環世界もまたあと100年は安泰かもしれません。私の生涯はこれを擦りつづけるのですかね。
さて、前回でも少し言及したようにディスカバリーとデリバリーは当然ながらコンセプトを上流から下流へ流すような単純な分離がされた組織構造ではありません。あくまで主要なミッションの違いであり、実際にはデリバリー機能なしに単独でディスカバリーを遂行することは不可能です。ディスカバリーにおいては課題を定義し、仮説を強固なものにし、プロトタイプを用いてソリューションの確度を高めていくこともまた必要なことだからです。コンセプトと具体的なプロダクトの間には、コンセプトが机上の空論にならないためのサイクルがあります。
汽水域 – コンセプトがプロダクトになるために
技術力が必要なふたつのディスカバリー課題があります。ひとつはソリューションの確度を上げるフィジビリティの課題、ひとつは仮説検証サイクルのフロー効率の課題です。
そもそもディスカバリーチームはソリューションを考えられない
精度の良いソリューション案・プロトタイプを作るためには、フィジビリティ（技術的実現性）に対する理解がどうしても必要になります。これには単純に技術に対する理解も必要ですが、一般的な技術についてではなく現行のシステムへの深い理解が不可欠です。しかし、なにもディスカバリーチームの全てがこれに精通している必要はありませんし、そもそも不可能です。チームがアジャイルで流暢になるほどプロダクトは高速に進化し、最新のシステムに対する正しい知見はデリバリーチームにしか存在しないからです。むしろここで重要なのはデリバリーチームがディスカバリーチームとの議論で敏捷に回答や提案をすることです。そのためには適切なソリューションを最適なコストで提供するためには、デリバリーチームの既存システムに対する認知負荷を下げることがとても重要です。これは例えば業務知識を元にドメインモデルについて整理したドキュメントを作成したり、ADR（Architecture Decision Record）などの記録、最終的にはシステムのリファクタリングによって低減させることができます。
システムの認知負荷の源泉は、本質的にはモデルのミスマッチです。前回、世界とユーザーのふるまいにミスマッチがあったように、システムにもミスマッチがあります。詳細は割愛させていただきますが、例えばO/R Impedance Mismatchと呼ばれるミスマッチが有名です*。このミスマッチはシステムの裏側の事情ですが、裏側に限った話ではありません。例えば実際のユーザーのメンタルモデルと画面実装の状態モデルは完全に整合することはないでしょう。つまりメンタルモデルと実際の画面が持つ状態モデルのミスマッチが発生します。このように、その他の様々なステークホルダーの視点からもモデルのミスマッチが存在し、それぞれの視点で局所最適を図ることで認知負荷は増大し続けます。もちろん、このような状態でも開発は進めることができます。
*ざっくりいうとシステムとデータベースのデータ変換のややこしさのことです。個人的な見解としては、RDBMSとフレームワークが発達した現代におけるバックエンドエンジニアの仕事は常にこれをなんとかする仕事です。
そして驚くことに、そのような認知負荷が高い状態の方が開発効率が良いと考えている開発者もいます。むしろそちらの方が主流かもしれません。これはそのような認知負荷の高い状態は、課題が設定された後のエンジニアリソースの稼動率を高く維持し、スループットを出すために局所的に最適化された状態でもあるからです。これは以下の画像のような状態で、後述するフロー効率が悪いということでもあります。反面、このようなケースでは課題を設定するためのリードタイムが非常に大きくなります。誰も全体像を直感的に捉えられないために、ディスカバリーチームのフィジビリティに関する問い掛けに対して臨機応変に回答することができないのです。それどころかちょっとした質問に返答するのに日を跨ぐこともめずらしくありません。これに対してエンジニアは様々なステークホルダーと共通のモデル（ドメインモデル）の用いて凝集と結合を設計することで認知負荷を下げる責務を負います。
実際の現場ではさらに手前の課題もあります。デリバリーチームとディスカバリーチームが密接なコミュニケーションを取れないようなケースです。質を語る以前に、コミュニケーションが存在していないのです。そうするとどうなるのか。言うべくもありません。アジャイルでもなんでもない、ディスカバリーチームがただ手を変え品を変え勝手に考えたソリューションをデリバリーチームに依頼するというプロセスをなぞるだけになります。フィジビリティに向き合わずにディスカバリートラックで自己完結してしまう状況です。それもまだプロジェクトとして管理されていれば良い方で、最も悪いケースではディスカバリーチームがソリューション案の前提となっている技術に対する妄想を明かにできず、ひとりで走り続けてしまうということが起こります。そうこうする間に締切が迫り、内部的に持っているリリースの期日を理由にデリバリーチームに圧をかけるようなことさえ起こり得るのです。
フロー効率が重要なのであって、忙しくする必要はない
フィジビリティのためにデリバリーチームとのコミュニケーションはディスカバリーチームの責任です。一方で仮説検証のサイクルを回したいディスカバリーチームにとって、デリバリーのフロー効率は切実な要求です。
フロー効率が良い状態というのはリードタイムが短かく、新鮮な内に価値がユーザーに届く状態です。これは施策が定義されてデリバリーチームに受け渡された後に、実際にユーザーに届くまでにかかる時間が短かいことを意味します。ディスカバリーチームにとってデリバリーチームのフロー効率がなぜ重要かを明らかにするため、フロー効率が悪いケースについて考えてみましょう。
ディスカバリーチームが新しい施策を小さな仮説から広げていきたいと考えたとします。すると施策の結果はリリース後に判明するので、開発のリードタイム分だけリリースによる学習までに時間がかかります。本来小さな仮説に対する施策によって得た学習は次の同じテーマの企画に反映したいわけですが、このリードタイム分だけ次の企画が停滞することになります。待てるのなら待っても良いのですが、学習を取り入れることができずにスタートする企画は少ない方が良いですし、時間がかかればかかるほど学習する意義が損なわれていきます。ハードウェアのようなリードタイムの長いサイクルさえ、フラグシップモデルとその普及・最適化によるtick-tock戦略を用いてちゃんとリリースによる学習を次企画に回せるようにしているほどです。
さらに、リードタイムが長い状態は悪循環を生みます。まずリードタイムで発生した要求の変化によって、要件が膨らみます。そして次第に小さな開発を長い時間をかけてリリースするより、厳密に区切られた大きな開発を時間をかけてリリースする方が痛みが少ないと考えるようになるのです。このようにして望まれない、しかし強固なウォーターフォールが構築されます。
フロー効率は前述のようなインピーダンス・ミスマッチによっても落ちますし、その他例えばDevOpsへの投資によってCI/CDの整備ができていなければ悪化の一途を辿ります。今回は企画全体から見たフロー効率を考えていますが、デリバリーチームのコントロール範囲に限ってコードを書く能力に着目すると、フロー効率はDevOpsに関する重要な研究であるDORAのFour Keysにあるようなcommitからリリースまでのリードタイムで計測することができます。この指標は間接的に同じ課題に根差して数字が悪化していくので、まずはここを見える化していくことが必要なのだと思います。（「思います」ということはつまり、実際にはまだできていないということです。）
システムの統合と受け入れテスト
ここまでは開発の起点としてのディスカバリーについて考えてきました。しかし「はじまり」があれば「おわり」もあり、ディスカバリーとデリバリーの汽水域にはもう一つの重要な機能があります。受け入れテストです。
受け入れテストに関わらずテストは開発プロセスに不可欠な要素で、その最終ゴールはステークホルダーのビジネスニーズの充足を支援することです。よってテストを行う具体的な方法は、ステークホルダーの要求やチームのリソース状況などの開発組織の複合的な要因によって決定されます。テストの大部分は主要なKPIとしてテストケースのカバレッジを追うものが多いです。ケースカバレッジを目標とする場合はVSTePやCUJなどを用いてケース出し、優先度決めをします。またこのような設計されたテストで捕捉できない欠陥を見付けるために、カバレッジとは別の視点で探索的な経験ベースのテストを実施します。テスト観点やCUJを出す際や経験ベースのテストでは、既存のシステムや業務知識、コンプライアンスの知識など多岐に渡る知見が必要となり、適切なステークホルダーを巻き込むことが不可欠です。
ソフトウェア統合や受け入れテストは先述のフロー効率のボトルネックになり得ます。つまりディスカバリーチーム自身の受け入れテストによって仮説検証のサイクルが回らなくなる可能性があるのです。ボトルネックになる原因は自動化をしていない、単純に作業に慣れていないなどがありますが、ひとつにソフトウェア品質に対する過剰な執着があります。テストカバレッジや観点の充足度に対する完璧主義を排するためには、まず欠陥のないソフトウェアは存在しないということを受け入れる必要があります。これは丁度他分野で歩留まりと呼ばれるような概念です。これを継続的なサービスの世界ではエラーバジェットと呼びます。ゆるく表現すると「許容できるエラーの予算内でガンガン機能リリースしていこうぜ！」という感じです。そのため列挙した観点から発生し得るダウンサイドの規模と確率を見積り、最大限自動化の努力をした後には、最終的には焦点を定めて適度に手を抜いたテストをする必要があります。こう表現すると、真面目そうなテスト設計者のイメージが突然手堅いギャンブラーのように思えませんか？私は本質的にはそういう人が適任だと思っています。
また、かなり応用編の手法ですが、W字テストにある要求テストや仕様テストとしてAlloyなどのモデルベース言語で状態遷移の検証することも可能です。元々バックエンドエンジニアで型理論なんかに関心があった身としてはこういったトライをしてみたい気持ちがありますが、それが可能なチームを編制するのはなかなかに難しいなというのが実感です。しかし（願望も混りますが）いずれ普及することは間違いないでしょう。（普及してくれ……！）
コンセプトがプロダクトになるために
以上のように、ディスカバリーとデリバリーは密接に連携して当然であり、それ以外の仕事に優先します。ここができなければ価値は世に出ないですから。前回書いたようなコンセプトを作る仕事というのは、このような基本の上に立脚したより概念的な仕事であり、今日示したような基本ができていないのであればすべてが無意味です。
私の現実
これまでディスカバリーをしたい理由、ディスカバリーが実際にプロダクトに繋るためにどう仕事をしていくのかの考えをまとめてきました。上記を踏まえて、ここからはチームに対して実施したいくつかの施策とそこから明かになったことを見てみます。
まずは小さくてもリリースを経験してもらおうとした
汽水域の仕事が回らない時、人によって程度の違いはあれど世に出ないものに時間を吸い取られる無意味さに心を蝕まれ続けています。まずは世に出す経験が必要だと思い、比較的小さく要件が明確な案件をさっさとリリースできるように集中的に動いてもらおうとしたことがありました。しかし、ある案件は当初想定よりも影響範囲が広がり、プランニングが甘く、企画が煮詰まらないままリリースがギリギリになるまで時間が過ぎていきました。また同時に進めた本当に軽微な修正は先述の開発リードタイムの餌食になり、その瞬間における小さな成功体験と呼べるものにはなりませんでした。結局のところ残された事実だけを見ればリリース期日に合わせたギリギリの開発しかできず、期日が曖昧な機能や期日が先の機能、見積もりを取っていない機能は劣後し続けます。そのため燃料である締切を求めて、デリバリーチームに意味の薄い見積もりを乱発するということがチームを駆動させるために必要になっていたようにも思います。
チームがアジャイルの流暢さを獲得するためには、バリューチェーンの全てのポイントでボトルネックがなく流暢であることが必要です。全体のボトルネックを見極める前に「小さなものだけでもアジャイルに」と始めたことは実態を明かす上では重要な意味がありました。一方で、それはチームが機能していくためにそれほど寄与しなかったように思います。現在はディスカバリー活動によって良質なプロダクトバックログが生成されたチームから、開発リードタイムの課題の重要性が認知されつつあります。フロー効率の悪さに対して強烈なペインがある状態です。必要だったのは、まず需要を作るという原始的な手法でした。このペインを原点としてアジャイルなプロダクトチームを構築しています。
Sell me this pen.
プロダクトバックログを作るべきだと考えた
価値の源泉であるプロダクトバックログを作らなければいけないと考えました。上記の話を鑑みると、正しい打ち手に思えますね。けれど細部が適当ではなかったため、当時時点では効率の良い施策とは呼べませんでした。単純なユーザーストーリーのリストだけではなく、高機能なnotionを用意したのです。スプリント、PRDの更新ポイントや項目、受け入れ条件、ストーリーポイント、エピックとユーザーストーリーとタスクの区別、ステークホルダーDB、スプリント・ゴールの管理などなど、いくつもの機能を用意しました。当然その時点では多くの機能は使われず、肝心のプロダクトバックログ機能は想定の利用をされませんでした。結果としてプロダクトバックログという名前のタスク管理をするようになりました。
今思えばチームとのフィットを何一つ検証しないまま必要な機能を詰め込んだプロジェクト管理ページは、まさに失敗プロダクトの典型例ですね。私自身ユーザーストーリーの分解ができていませんでした。まさか自分がこんなにわかり易くやらかすとは…… まったくの無駄というわけでも、害のある施策を打ったということでもありませんでしたが、いかんせん課題に対する打ち手として効率が悪かったと反省しています。ツールよりも中身が大切です。そして、実はこの時のチームはプロダクトバックログをそれほど必要としていなかったのです。これは当時のチームは他部署の企画を渡されることがほとんどで、自分達で届ける価値をいちから定義できたわけではないからです。私自身、他部署から企画が降ってくることの意味をしっかりと理解するまでに時間を要してしまいました。
現在では、社内請け負いとしてのふるまいが残留していたバックログが、新たに設立されたプロダクトカンパニー・marui unite（マルイユナイト）によって一定統制されるようになりました。付随して自分たちで届ける価値に向き合う必要が出てきたとで、チームのテーマに合わせたプロダクトバックログが徐々に出揃ってきました。まさにこれからです。
結びに
ディスカバリーとデリバリーの汽水域では、フィジビリティとフロー効率という2つの課題が密接に絡み合います。これを解決しない限り、どれほど優れたコンセプトを打ち出しても価値をユーザーに届けることはできません。
フィジビリティの課題はシステムの認知負荷に関するものでした。一方でフロー効率を改善していくためには、バリューチェーンのボトルネックを解消していかなければならないため、時間もコストもかかります。徐々に、しかし強固な顧客中心のDXを遂げるため、引き続きがんばります。