「クライアント-ベンダーアンチパターン」という根本問題

今更ながら「ユーザーストーリーマッピング」を読んだ。
この本で一番ピーンと来たのが「クライアント-ベンダーアンチパターン」。
自分が理解したメモ。

【参考】
【復習】CSPO研修(2) クライアント-ベンダー アンチパターン - きっと、うまくいく~非IT業界をスクラムで変えるための系譜~

「ユーザーストーリーマッピング」を読んで | GMOインターネット 次世代システム研究室

『ユーザーストーリーマッピング』｜感想・レビュー - 読書メーター

（引用開始）
プロダクトオーナー向けの推薦図書、と紹介を受けて読む。様々な局面でのベストプラクティスとアンチパターンが書かれており、スクラムマスターや開発チームの人達と読んでも面白そう。終始いいこと書くなぁと思いつつ読む。
大きな組織内でも、社内ベンチャー的に何かサービスを作ってみよう、新規サービスを、とするチームにも必読かな。
SIer的には「クライアント-ベンダーアンチパターン」が刺さる。こうはならないように間を取り持つような、うまい関係性を構築したいものだなと思う。近いうちに再読、リファレンス的に使いたい。
（引用終了）

【１】「クライアント-ベンダーアンチパターン」こそが、ストーリーの活用を阻害する最大のアンチパターン。
「ユーザーストーリーマッピング」は、いかにしてこのアンチパターンを解決すべきか、色んな角度から解決方法を述べているように感じた。

「クライアント-ベンダーアンチパターン」では、発注者であるクライアントと提供者であるベンダーが敵対関係になる。
クライアントは要件を話して、ベンダーに見積もりを要求する。
見積もりは契約と同義語なので、ベンダーはリスク回避のために、ガチガチの要件を定義して、コンティンジェンシーも加味した見積もりを出す。
そして、リリース前後にクライアントはこんなものを期待したわけではなかった、と言い出す。

特に、日本のSIとユーザ企業は、まさに「クライアント-ベンダーアンチパターン」に陥っている場合が多い。

「クライアント-ベンダーアンチパターン」の本質は、問題と解決方法の会話が要件とその合意の議論にすり替わっている点にある。
本来、クライアントは業務上の何かの問題を解決して欲しくて、システム導入による解決方法をベンダーに期待する。
ベンダーはIT技術屋なので、技術がどのように役立つのか、をよく知っている。
しかし、「クライアント-ベンダーアンチパターン」のように、クライアントとベンダーで役割が分離されてしまうと、システム開発のリスクをどちらかに投げたい気持ちが強くなり、互いにリスク回避の行動になってしまう。
システムシンキング的には、共有地の悲劇みたいな感じかな。

「ユーザーストーリーマッピング」では、医者と患者の関係に近づけるべきだ、とアドバイスする。
医者は患者を検査し、どこに問題があるのかを調べて処方する。
同様に、ベンダーも医者のように振る舞い、要件ではなく、本来の問題解決の役割に徹するべき。

【２】「プロデューサーとしてのプロダクトオーナー」という節も重要だ。
古いIT部門にいると、プロダクトオーナーという概念が分かりにくい。
特に基幹系情報システムの担当にいると、誰が最終決定を握っているのか分からない。
なぜなら、誰もシステムの全てを知っていないから。
サブシステムや各サービスの要件を決めるプロダクトマネージャがいるだけだ。

すると、こういう古い組織では、ビジネスアナリストなる人が要件収集の役割を与えられる。
彼らは、サブシステムごとのプロダクトマネージャや利害関係者というビジネスピープルと、開発者の間の仲介者の役割を果たす。
この時に、ビジネスピープルがクライアント、ビジネスアナリストがベンダーの役割を演じて、「クライアント-ベンダーアンチパターン」が発生する。
ユーザ企業側にいると、まさにこういう症状が発生しがちで、要件定義フェーズでよく行き詰まる。

「ユーザーストーリーマッピング」では、ビジネスアナリストが音楽バンドに対するプロデューサーのような役割をにない、医者と患者の関係に近づけるべきだ、とアドバイスする。
この比喩はとても上手い。

一方、僕は当初は、ユーザ部門がプロダクトオーナーの役割を担うべきだ、と思っていた。
本来は、ユーザ企業のIT部門がベンダーと張り合えるぐらいの技術力を持たいないと、技術の目利きやベンダー管理なんてできないでしょ、と思っていた。
しかし、現実は厳しい。

プロダクトオーナーの仕事もスキルも簡単なものではない。
ユーザ部門がプロダクトオーナーの役割を全て担うのは、スキルがなければ危険だ。
ビジネスアナリストはユーザ部門を手助けするプロデューサーの役割を担う方がいい。

【３】この指摘は、「エッセンシャルスクラム」に出てくる「プロダクトオーナープロキシ」の役割に似ている。
つまり、「プロデューサーとしてのプロダクトオーナー」は「プロダクトオーナープロキシ」、つまり、プロダクトオーナーの代理人と同義語と思える。

ユーザ部門の人に時間を与えて、プロダクトオーナーの仕事を担当してもらうが、ビジネスアナリストまたは情報システム部門がプロダクトオーナーと開発チームのやり取りを担当し、特定の状況ではプロダクトオーナーの代わりに意思決定できる役割も担えるようにする。
つまり、ビジネスアナリストまたは情報システム部門はプロダクトオーナーと同じ立ち位置にいて支援も行い、問題解決を図るようにする。

【４】「クライアント-ベンダーアンチパターン」を読み直すと、日本のソフトウェア開発の問題はここに尽きるのではないか、と思ったりもする。
ユーザ企業は一括請負契約としてベンダーを縛り、開発リスクをベンダーに負わせる。
だから、ベンダーはリスク回避のコストを見積もりに入れて、多額の開発費用を契約する。
そして、要件定義でベンダーの支援範囲を固定し、リスクを回避しようとする。
お互いに敵対関係となり、「クライアント-ベンダーアンチパターン」にはまる。

その点、スクラムはよく考えられていると思う。
プロダクトオーナーの人は、開発チームに入り、スクラムチームの一員になることで、開発チームと一体化する。
その結果、プロダクトオーナーは開発チームとコミュニケーションが取りやすくなるし、開発チームも、要件ではなく本来の問題を認識できるので問題解決がより即した形になる。

また、ユーザ部門がプロダクトオーナーとして完全に発揮できない場合、ビジネスアナリストや情報システム部門がプロダクトオーナープロキシになって、プロダクトオーナーと開発チームの仲介役を担う。
その結果、ユーザ部門の要望や問題意識は、プロダクトオーナープロキシによってシステム内容に置き換えられて、開発チームに渡されるようになる。

【５】こういう話を聞くと、日本人は、大規模な官僚組織を操縦するのが本当に下手なんだな、と思う。
中国や米国や欧州の人も上手いとは言えないが、日本はもっと下手すぎる。

中国は２千年以上も前から、非宗教的な官僚組織を作り出し、それをいかに手懐けるか、に知恵を絞ってきた。
欧米は社会心理学や行動経済学、組織行動学などの学問を揃えることで、官僚組織の運営に、概念や理論を適用してきた。

一方、日本人は腹芸や根回しみたいなスキルばかりに注力して非効率的だ。
もっと、組織運営というスキルを磨くべきなんだろうな、とか思ったりする。

【追記】先日、@ryuzeeさんと、@kyon_mmさんのやり取りも非常に参考になった。

Ryutaro YOSHIBAさんはTwitterを使っています 「そもそもPOとSMは利害相反する箇所があるので、1人に内包すると歯止めが効かない。たくさん作りたいPOと持続可能にやりたいSMでバランス取るみたいなのできないしね」 / Twitter

きょん＠アジャイルコーチ、システムアーキテクトさんはTwitterを使っています 「@ryuzee なぜ人がわかれているとできるんですか?」 / Twitter

Ryutaro YOSHIBAさんはTwitterを使っています 「@kyon_mm 書き方よくなかったかもね。分かれてても出来ないこともある。当たり前だけど健全な関係性の上に成り立つので、PO・SMが主従関係みたいな感じならかわらんね。」 / Twitter