今朝、こんな話を見かけてたしかにこういうのあるよねとは思ったりしました。
良い表! 「エンジニアじゃない人」って主語が大きくしてしまったのと、デフォルメ表現が燃え気味な理由なのかな。あと「やりたくない」とか「めんどくさい」とかは感情の発露なのでロジカルではないのはそう / “エンジニアの表現には気をつけろ!【エンジニアの意図と非エ…” https://t.co/DP3DBqSKw7
— songmu (@songmu) 2020年8月20日
ただ、これエンジニアだけじゃなくてセールスでもあるなとは思うんですね。だめな例ではありますが、「(ちょっと価格が低すぎて)その案件に手を出すのはちょっとモチベーションが・・・・」って当時の社長に言って喧嘩したことがあったりします。
で、コミュ力云々って話はもちろん事実として存在するわけですが、本当の原因はこのコミュニケーションの交渉コストが高いというところにあると感じたという話です。
自分の立場をもとにした交渉=Positional Bargaining
自分の立場=positionをベースに交渉することをPositional Bargainingというんですが、だいたい余計なコストがかかったりどちらかに不満が残ったりします。
たとえば、プロマネがこんな依頼をエンジニアにします。
Aという機能を2ヶ月後までに作ってくれ
エンジニアが納得できて合理的にOKできる開発期間があれば問題ないのですが、そうではないときはきっとこんな会話が始まります。
ちょっと開発期間が短いので5ヶ月にしてください。
人が足りないので3人増員してください。
などなど・・・・
しかしプロマネも容易にはOKと言えません。「すでに機能リリースを発表しているので伸ばせても3週間くらい」とか言い始めるんではないでしょうか。
「なぜ発表したし。てか、その3週間なんやねん。」って思ったりはしますが、一旦おいておくとして・・・
プロマネは「できるだけ予定を変えずに機能をリリースしたい」という立場を崩さないし、エンジニアも無理な注文は受けられないので「できるだけ期間と人数を稼ごう」という立場を崩しません。これが、立場による交渉=Positional Bargainingです。
ただ、Positional Bargainingはあらゆる面で高コストです。
Positionを維持するためにバッファを取り出す
プロマネはこんな事を考えます。
どうせ全部はできないっていうだろうから、ラッキーでできそうなやつも全部のせとこう
それ、本当に必要なのか謎・・・・・
一方で、エンジニアもこんな事を考えます。
どうせ急げって言うだろうから、まずは硬めの回答をしよう
結果的にどうなるかと言うと、なんかよくわからないけど中庸なところに落ち着きます。高度に訓練された人同士がやると不思議と狙ったところに落ちるんですが、「結論見えてるのにこの儀式必要なのか・・・?」という疑問は拭えません。
この調整に費やすコストは実際のところなんのメリットもありません。どちらかの希望が通ったとしても、効果や効率を考えた話ではないので結局無駄が多いです。
双方のPositionが完全には維持されないので漠然と不満がたまる
結局のところ双方の希望が100%の形で通ることはめったに無いので、だんだんと意見が通らないという事実だけが蓄積します。プロマネの「やりたいことができない」という不満とエンジニアの「いつも無茶ばっかり言ってきやがる」という不満が積もっていってどこかで気持ちが追いつかなくなって鬱々とした空気になります。
これは、誰が悪いと言うよりは、構造的に失敗しているんですね。
双方の利益に着目して交渉する = Interest Bargaining
セールスの基本ではあるんですが、交渉は「お互いの利益が一致してますね」「だから、お金ください」という論法を取ります。いきなり「金くれ!」とは言わないわけですね。
では、プロマネとエンジニアの会話もこうした双方の利益に着目した会話はできないものでしょうか。
結論から言うと可能です。自分の関わっているプロダクトが成長すれば、大抵の場合みんなハッピーでしょうから、プロダクトの成長こそがみんなの共通利益なわけですね。なので本来あってほしい議論としては、
プロマネ「今のユーザ導線だと、この部分が悪くて脱落している人が多い。例えばAという機能改善はどうか。」
エンジニア「Aは、今の実装だと時間がかかってしまう。例えば、Bならスムーズに作れるし導線も良くなるのでは。」
みたいな。お客様の課題が明確であれば、そこに対してどうアプローチすべきかというのは比較的前向きに議論可能*1なのでした。
利益=Interestは時間とともに変わるのでハイレベル合意が効く
しかし、難しい点はその利益は時間や状況によって少しずつ変化していく点です。
例えば、ソシャゲ立ち上げ期*2であれば新規ユーザ獲得やオンボーディング施策に重点があるでしょう。一方で、ユーザが増してくればユーザ・エンゲージメント向上施策やゲームバランスをいじる施策が増えるでしょう。このように、時とともにやるべきことはどんどん変わっていきます。すると、なかなかお互いの利益を理解することも難しくなっていきます。
ここで中長期的な利益に目線を向けたハイレベルな合意というのが効いてきます。
高いレベルで戦略合意できるほど変化しにくくなるので、交渉ごとや調整ごとはスムーズになります。これが、世にいう視座とか経営者視点*3とかいうやつの正体の一部でもあります。とは言っても、エンジニアの目の前にあるのはコードなので中々ハイレベルな話との間にはギャップがあります。
Interestが安定すると開発の抽象度がハイレベルになる
中規模〜大規模開発したことない人にはあまりピンとこないと思うのですが、中長期目標が安定するとアーキテクチャが洗練され抽象度が上がります。素のコードを書くというよりはDomain Specific Language (DSL)を書く感じになっていきます。
例えば、見積書を出すようなロジックを作ろうとすると、センスのいいエンジニアがちゃんと設計すれば下記のようにだんだんと抽象度が上がっていきます。
- 商品名を出力して、単価と数量をかけて小計を作り、小計をまとめて合計を作り、消費税10%を足して、タイトルを見積書にして・・・・
- 商品名、単価、数量から表を出して、タイトルを見積書にして印刷
- 商品名、単価、数量を入れて見積書を印刷
そして「請求書もほしいな」と言われたら「表を出す」機能を流用して、タイトルだけ請求書に変えるというような効率的な開発をします。
このように、中長期的な目標が定まると開発が抽象化されハイレベルになることによって、ハイレベル合意にそった開発をスムーズに進める設計を実現することができます。
中長期目標が安定するとプロマネも技術に詳しくなる
プロマネ側がゼロからコードを書けるようになる日は早々来ないと思いますが、同じ領域・同じコードベースに触れているうちに、段々と勘所がつかめるようになっていきます。「あ、この手の変更はきっと時間かかるだろうなぁ」「このやり方ならすんなり行くはず」とかそういう直感が働くようになります。
特定のドメイン限定ではあるかもしれませんが、こうしたノウハウによって会話が非常にスムーズになっていきます。
Interestに着目したらいいことばかりじゃないですか?
すごく理想的なケースを書いたので、現実はそううまくは行かないことも多いのですが、中長期的に安定したinterestに着目することはプロダクトの発展の効率性に寄与することはご理解いただけたのではないかと思います。
一方で、Product Market Fitが得られるまではScrap&Buildすることを一定レベル覚悟しなければならないでしょう。計算機科学の大家クヌース先生も「早すぎる最適化は諸悪の根源である」と言ってますが、どのタイミングで中長期目標にシフトしていくかは一つの乗り越えるべき壁なのかもしれません。