TL;DR : ひとことでいうと
- 決定事項になる前に早めに巻き込もう
- 巻き込むときは、
- その意図や相手に期待することを伝えよう
- 特性を理解して、ちょっとした工夫（最初の一声はチャットなどの非同期コミュニケーションを使う、etc）をしよう
たまに遭遇するシーン
ソフトウェアプロダクトの企画（プロダクトデザイン、プロダクト設計）を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。
「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は（程度の大小はあれど）起こってしまう と思っていて、今回はそういったケースを想定しています。
特に、以下のような思いがあるからそうしている、というケースを話題に上げたいと思っています。
- エンジニアに企画を説明すると、 多くの指摘（マサカリ）が入ることが多いので、なるべくちゃん作り込みたい
- エンジニアを 邪魔してはいけないという考えがある （または、嫌がられる）
ちなみに私は、エンジニア→プロダクトオーナーを経て、今は社内で横断的にチームの何がしかを支援する仕事をしています。エンジニアとプロダクトオーナー（≒ 企画職）両方を経験したので、ある程度どちらの立場もわかるなぁという気持ちです。
こういったケースで起こること
ちなみに、要件や仕様をかっちりと固めてからエンジニアに渡した場合、エンジニアの視点から見て以下が起こります。
- 解決したい課題、やりたい事に対する How が、 技術的に不可能、難しい、または最適でない。
- 納得感が醸成されず、やらされ感のある モチベーションが低い開発になってしまう（上記と相まってのケースが多い）
a. については、企画を行う人にエンジニアリングの知識が少ない場合に起こりうることは想像に難くないと思います。
b. については、「自身が意思決定に関わっていないものは動機づけされづらい」という心理的な作用があると思います。（自己決定理論）
なぜ「かっちり決めないといけない」と思ってしまったか
再掲ですが、冒頭にあげたとおり、以下の理由を見聞きします。
- エンジニアに企画を説明すると、多くの指摘（マサカリ）が入ることが多いので、なるべくちゃんとしたい
- エンジニアを邪魔してはいけないという考えがある（または嫌がられる）
1. に関しては、「指摘される」＝「自身の企画や、ひいては自分の努力が否定された用に感じる」「サンクコスト（これまで投資した時間、労力）を考えると指摘を素直に受け入れづらい」と感じることもあり、この反応がより防御的な行動、つまり「建設的な議論にならない」「次は、よりかっちり固めるように時間を使う」につながることがあります。
もちろんお気づきかと思いますが、完璧なものなど作れない前提において、時間をかけすぎることはリードタイムの不要な増加を起こす、負のスパイラルになってしまいます。
2. については、良かれと思ってやっている場合は「地獄への道は善意で舗装されている」の例だと感じますし、嫌がられるから、というケースは信頼関係が十分に構築できていないのだろうなと思います。（どちらかが悪いという話ではなく）
どうすればいいか
身もふたもないですが、「やっぱり早めに巻き込んでおくこと」です。
タイミングとしては、少なくとも、 やるということが決定する前 です。 先の「b. モチベーションが低い開発になってしまう」に関しては、やることが決定してからの巻き込みでは、人間の感情面でなかなか取り返しは付きません。
巻き込みの方法はなにか特別なものである必要はなく、通常のミーティングスタイルでも良いでしょうし、自席でのカジュアルな話、場合によってはチャットでもいいかもしれません。
「そうは言うけど嫌がられるんですけど」と思うと思います。
嫌がられないために念頭に置いておくと良いことがあり、その中でも特に重要なものは、
- 目的と期待を伝える
- エンジニアの仕事の特性に対する知識と共有認識づくり
だと思っています。
目的と期待を伝える
そのミーティングの意図や、相手に期待することをお互いで揃え、 その時間を使う目的、効果をあらかじめ明確にしておく、ということです。
エンジニアはミーティングを嫌う傾向があると思うかもしれませんが、すべてのミーティングが嫌いなわけではなく、「効率、効果が低いミーティング」を嫌っています。 特に良くないケースが、「効果が低い」かどうかも判断できないような、とりあえず設定されたようなミーティングや、過剰な定例ミーティングです。
だめな例のひとつは、「すみません、とりあえず時間抑えさせてもらいました」というものだと思います。 もちろんこれらすべて、別にエンジニアに限らず嫌ですよね。
ちょっと余談ですが、チャットの第一声で「〇〇さん、お疲れ様です」だけ送ってくる、みたいなコミュニケーションってもやっとしませんか？（重要度や緊急度が判断できないうちに、反応を強制される気がして、僕は嫌なのでやらないようにしています）
意図や期待することについては、難しく考える必要はなく、たとえば以下のようなものだけでもよいと思います。
- 手戻りを減らすために、技術的に不可能なことがないか早めに確認しておきたい
- もっと簡単にできる方法はないかアドバイスがほしい
- 記載内容に不足がないか、レビューを手伝ってほしい
- 先に技術検証しておいたほうがいいことなどがないか相談したい
- 同じプロダクトメンバーとしてシンプルに早めに知っておいてほしい
- 同じプロダクトメンバーとしての意見を聞きたい
- やる/やらない、優先順位を決めるための超ざっくりな見積もりしりたい（数日レベル？数ヶ月レベル？）
合わせて「こういう場ではない」ということも伝えておいたほうが良いと思います。
- やることが決定したという事務連絡ではない
- 「約束になる見積もり」をしてほしいわけではない
- 売上の試算はこの後するので、そういったツッコミは一旦なしにしてほしい
- 仕様のイレギュラーパターンはこの後検討するので、そういったツッコミ（略
目的が達成されたら、ささっと解散してしまいましょう。
もちろんエンジニア側も、設定された打ち合わせの目的が曖昧であればちゃんと事前に確認するのが良いでしょう。 ただ「何が目的ですか？」のように高圧的に感じさせうるワードではなく、「確認の目的って、技術的に不可能じゃないか確認するため、とかでいいですか？」のように、その後のインタラクションのハードルを下げるような歩み寄ったコミュニケーションをぜひすると良いと思います。
そして、目的に沿って意見を言うようにするのがいいでしょう。たとえば、ざっくりとした要件を検討しているフェーズでは重箱の隅になるようなことは言わない、などです。 また、自分が期待するものと程遠かったとしても、それは協調してい作り上げ、ともに成長して行けば良いものだと思います。期待が何かフィードバックしましょう。
※ RSGT2019 で、歩み寄って「どういった要求・仕様がいいのか」を一緒に作り上げていたチームの事例がありました
今後「マサカリが怖い」と不用意に思わせて、結果的にプロダクトや組織に悪影響をあたえるようにならないよう、ほんの少しの思いやりが必要です。 なにかがうまくいっていないとき、ほとんどのケースでは双方に何らかの問題があります。でもそれは逆に言うと、双方にできることがあるということです。
エンジニアの仕事の特性に対する知識と共有認識づくり
確かにエンジニアの「集中の妨げ」というのは生産性に影響すると感じます。
どういったことが「集中の妨げ」になるのか、ある程度知っておき、あらかじめ対話しておくのが良いと思います。
多いケースは、集中している時にいきなり直接声かけて割り込まれるのはきつい（近いイメージは、「数学の問題をといているときに声かけられるときつい」など）というものです。
なので、
- 最初の一声は、チャットなどの非同期コミュニケーションを使う
- 集中している時間帯をお互いわかるようにしておく、共有しておく
などもできるかと思います。
ちなみにエンジニアリングマネージャーは割り込みをいとわないケースもありますし、エンジニアでもまったく気にしない人もいるので、その人の特性を対話の中で確認しておくと良いかと思います。
エンジニアも集中が妨げられたとしても、説明なくつっぱねることはせず「今集中して○○の開発していて、今離れると効率が悪いので、夕方でもいいですか？」「次からは一旦チャットで、相談内容含めて連絡くれると嬉しいです。チャットでも解決できるかもですし」といった説明を、面倒がらずにすることが、中長期的には自分（や組織）の生産性向上につながると思います。
こういった相談などに使う時間量の目安を、あらかじめ定めておく
少し補足的ですが、想定していなかった割り込み作業は、見積もりにも影響するので、あらかじめ時間の目安を取り決めておくのもよいかもしれません。
ガチガチのルールにはせず、あくまでも双方の目安としての認識合わせをしておくイメージです（10％くらいの時間、とか）
また、あまり五月雨にして集中できるまとまった時間を減らさないように、一日のある時間帯にまとまった時間として確保しておくのも良いと思います。
さいごに
プロダクト企画者とエンジニアの対立構造のように書いてしまいましたが、職種によるものではない話だと思いますし、どちらか一方が良い/悪い、偉い/偉くないというつもりではありませんのでご承知おきください。
なんとなくエンジニアが特権階級なような書き方に感じたかもしれませんが、まったくそんなことは思っておらず、プロダクトをより良く作るフラットな関係性として、お互いに敬意を持ち、相手を思いやって歩み寄ることが大切だと思います。
ちなみにスクラムだと、プロダクトバックログのリファインメントがこれに当たると思います。
そういう意味だと、こういったように多く説明しないといけないことを「プロダクトバックログリファインメント」と一言で表現できるのは、フレームワークを採用するメリットともいえますね。
ちょっとまとまらないままつらつらと書いてしまいましたので、ご意見ぜひください
