意思決定が収束しないPJを、結合テストで着地させた話

この記事が語ること

立ち行かなくなったPJの中で、私が何を背負い、どこで切り替え、どう境界線を引いたか。
そして、どのように乗り越え、学びを得たか。
その判断と事実の記録。

事例：価格情報連携システムPJ

この話は、成功談でも、失敗談でもない。

マーケ部門からこのPJに呼ばれたとき、正直に言えば関わりたくはなかった。

話を聞いてみると、要求は複雑。
しかも、影響する関係者も多い。
扱おうとしていたのは、価格条件によって関連付けられた商品データをもとに、その関連性を検索などの各種システムや表示挙動に反映させる仕組みだった。
この種の仕組みはECでは珍しくなく、多くのプロダクトで繰り返される要求だ。

当時の私は、「難しいが、制御できる案件だろう」と判断していた。
案件の"出口"は用意できる、そういう読みだった。

結果としては、PJは完了した。
ただし、諸問題を残した。
つまり、明確な負債を残したまま終わったのだった。

制御できると思っていた理由

難易度が高いことは最初から分かっていた。
価格情報は商品データの核である。
そして、価格区分は単純なフラグではない。
ECでは、キャンペーン販売や例外によって揺らぐ。
商品データは外部依存が多く、判定ロジックが複雑化することも自明だった。

それでも制御可能だと考えた理由は二つある。

一つは、連携データの一部は既に資産となっていたからだ。
つまり、価格情報連携のベースはすでに出来上がっており、フロントでの扱いに注力すればいい。
そのはずだった。

もう一つは、最終的な判断が企画部門（PdM的役割）に収束する前提だったからだ。
意思決定の主体が存在するなら、技術側はそこに合わせて構造を組み立てられる。
そのはずだった。

つまり当時の私は、このPJを
「調整コストは高いが、構造としては閉じられる案件」
だと認識していた。

「あ、無理だ」

要件定義や設計が進むにつれ、議論の場は拡張していった。
開発、マーケ部門、企画部門、入荷部門、運用部門。
それぞれが、それぞれの正しさを持っていた。
問題は、どれが正しいか、ではなかった。

• 価格情報に関する複雑なドメイン都合への理解がステークホルダーに浸透しない
• マーケティング上の施策的価値と、その他部門とのデータ整合性のトレードオフが決定しない
• ステークホルダー間の利害調整が、個別の対話では収束不可能なレベルにまで複雑化

PdMを筆頭に、当事者達はこれらの根深い問題を解決できずにいた。

その結果、

• 複雑な要求を要件定義に適切に落とし込めなかった
• 部門毎の個別の理想形を前提に設計せざるを得なくなった

つまり、
前提整理が行われないままPJが動き出した
のだった。
結果、「何をもって正しいとするか」という全体基準が存在しない状態になっていた。

さらに悪いことに、部門間のズレが露呈していく。

• 同一の価格ロジックに対し開発・マーケ・入稿部門が別定義を持っていた
• 同一用語が部門別で違う意味で用いられていた
• PdMが判断を繰り返し保留した

ここで私は 「あ、無理だ」 と感じたのだった。

この状況でさらに関係者が増えれば、各ステークホルダーは自分の責任範囲で判断するしかない。

それぞれの立場には、実際に対立点もあった。
だが、その対立を解消するための前提も基準も存在しなかった。
どれかを優先すれば、必ず別の正しさが破綻する。
PdMが調整すれば解決する、という段階はとっくに過ぎていた。

制御できると思っていた前提は、すでに崩れていた。

線を引いた地点

私はここで立ち位置を切り替えた。
全体最適や整合性を追い、引き取るのをやめ、自分が責任を負える範囲に閉じると決めた。

「もっと手前の工程で何かできたのではないか」という感覚。
正直、悔いはあった。

要件全体の整合は引き受けない。
代わりに、開発部門の範疇で致命的な事故を起こさず完了させることに集中する。
決定が収束しない状態で取り得る現実的な線引きだった。

ここでの私の選択は"後ろ向きな生存"だった。

開発のスタンス

作業者には、とにかくドライに、スピードと単体テストを重視した実装をお願いしていった。
指針としたのは唯一つ、"不完全な"要件定義書だ。

その範囲内で、依存関係がいびつであっても、コードが美しくなくても許容する、という旨を伝えた。
そして、この構造の歪みで発生する責任はアーキテクトとして自分が引き受ける、ということも伝えていた。

将来のコストよりも現在の破綻回避を優先した。
これは負債を残すという明確な意思だった。

「物理的限界」で収束させた空中戦

とはいえ、各部門の成果の結合が機能しなければ、PJとしてはただの失敗だ。
ここまでの前提で、開発・マーケ・入荷・運用の結合テストが通る見込みがあるわけがなかった。
結合テストはQAチームが担当した。
もちろん、指針となったのは"不完全な"要件定義書だ。

私はこれを逆に利用した。
結合テストが問題点を露呈させることに任せた。
報告されたテストエラーという物理的な事実を使い、ステークホルダーに未決だった判断を強制させたのだ。

パワープレイに思われるだろうか。
動くものを作り上げ、棚上げされていた判断や決定を含んだ構造を、結合テストに通す。
そして、エラーを出させ、QA報告をそのまま意思決定テーブルに持ち込む。
主観を入れさせず、即時で強制的に収束させる手段をとったのだ。
これは、結合テストを意思決定装置に転用した、とも言える。

動くものが目の前にあるという事実は、常に強い。
これが毎回通用する手段である保証はないが、このときは、ある程度機能した。
このフローのおかげで、今度こそようやく要件が明確化していったのだった。

収束と負債

最終的にPJは完了した。
機能はリリースされ、形式上の目標は達成された。

しかし前提は整理されていない。
判定ロジックは複雑なまま残り、修正を重ねたコードは可読性を失い、将来の変更コストを押し上げた。
負債は明確に残った。

それでも完了を選んだのは、全体を引き受ける主体が存在しない中で、自分が責任を持てる範囲を限定するしかなかったからだ。

そして、最低限の責務として、複雑怪奇な仕様を記したドキュメントを残し、共有した。

私のPJは、ここで終わった。

残ったもの

このPJは、当初に期待した形では終わらなかった。
だが、判断基準をはっきりさせた経験だった。

"判断不能な構造で、全体最適を求めてはいけない"
​"判断不能な構造で、整合性を約束してはいけない"
"意思決定の主体が不明な構造では、判断を引き取ってはならない"

難易度が高いかどうかよりも、判断がどこに収束する構造になっているか。
そこが成立していなければ、個人の技術力や善意では解決しない。

このPJ以降、私はそこを注意深く見るようになった。
判断の収束点を初期段階で確認するようにし、それがないなら、背負わない。
引き受ける範囲を明確にし、線を引く。

いびつなPJだったが、得た学びは多かった。