ykmc09 blog

Podcast: https://omoiyari.fm

プロダクト企画にエンジニアを早めに巻き込む(嫌がられずに協力を得る方法)

TL;DR : ひとことでいうと

  • 決定事項になる前に早めに巻き込もう
  • 巻き込むときは、
    • その意図や相手に期待することを伝えよう
    • 特性を理解して、ちょっとした工夫(最初の一声はチャットなどの非同期コミュニケーションを使う、etc)をしよう

たまに遭遇するシーン

ソフトウェアプロダクトの企画(プロダクトデザイン、プロダクト設計)を行う人や組織が、 企画の要件や仕様をかっちりと固めてから、エンジニアに渡したほうがいい 、と思っているシーンを見聞きすることがあります。

「重厚なウォーターフォールプロセスを採用しているから」という場合もあると思いますが、 軽量なプロセス下にある Web サービス企業でも、企画と開発で役割分担をしている場合は(程度の大小はあれど)起こってしまう と思っていて、今回はそういったケースを想定しています。

特に、以下のような思いがあるからそうしている、というケースを話題に上げたいと思っています。

  1. エンジニアに企画を説明すると、 多くの指摘(マサカリ)が入ることが多いので、なるべくちゃん作り込みたい
  2. エンジニアを 邪魔してはいけないという考えがある (または、嫌がられる)

ちなみに私は、エンジニア→プロダクトオーナーを経て、今は社内で横断的にチームの何がしかを支援する仕事をしています。エンジニアとプロダクトオーナー(≒ 企画職)両方を経験したので、ある程度どちらの立場もわかるなぁという気持ちです。

こういったケースで起こること

ちなみに、要件や仕様をかっちりと固めてからエンジニアに渡した場合、エンジニアの視点から見て以下が起こります。

  1. 解決したい課題、やりたい事に対する How が、 技術的に不可能、難しい、または最適でない
  2. 納得感が醸成されず、やらされ感のある モチベーションが低い開発になってしまう(上記と相まってのケースが多い)

a. については、企画を行う人にエンジニアリングの知識が少ない場合に起こりうることは想像に難くないと思います。 b. については、「自身が意思決定に関わっていないものは動機づけされづらい」という心理的な作用があると思います。(自己決定理論)

なぜ「かっちり決めないといけない」と思ってしまったか

再掲ですが、冒頭にあげたとおり、以下の理由を見聞きします。

  1. エンジニアに企画を説明すると、多くの指摘(マサカリ)が入ることが多いので、なるべくちゃんとしたい
  2. エンジニアを邪魔してはいけないという考えがある(または嫌がられる)

1. に関しては、「指摘される」=「自身の企画や、ひいては自分の努力が否定された用に感じる」「サンクコスト(これまで投資した時間、労力)を考えると指摘を素直に受け入れづらい」と感じることもあり、この反応がより防御的な行動、つまり「建設的な議論にならない」「次は、よりかっちり固めるように時間を使う」につながることがあります。

もちろんお気づきかと思いますが、完璧なものなど作れない前提において、時間をかけすぎることはリードタイムの不要な増加を起こす、負のスパイラルになってしまいます。

2. については、良かれと思ってやっている場合は「地獄への道は善意で舗装されている」の例だと感じますし、嫌がられるから、というケースは信頼関係が十分に構築できていないのだろうなと思います。(どちらかが悪いという話ではなく)

どうすればいいか

身もふたもないですが、「やっぱり早めに巻き込んでおくこと」です。

タイミングとしては、少なくとも、 やるということが決定する前 です。 先の「b. モチベーションが低い開発になってしまう」に関しては、やることが決定してからの巻き込みでは、人間の感情面でなかなか取り返しは付きません。

巻き込みの方法はなにか特別なものである必要はなく、通常のミーティングスタイルでも良いでしょうし、自席でのカジュアルな話、場合によってはチャットでもいいかもしれません。

「そうは言うけど嫌がられるんですけど」と思うと思います。

嫌がられないために念頭に置いておくと良いことがあり、その中でも特に重要なものは、

  • 目的と期待を伝える
  • エンジニアの仕事の特性に対する知識と共有認識づくり

だと思っています。

目的と期待を伝える

そのミーティングの意図や、相手に期待することをお互いで揃え、 その時間を使う目的、効果をあらかじめ明確にしておく、ということです。

エンジニアはミーティングを嫌う傾向があると思うかもしれませんが、すべてのミーティングが嫌いなわけではなく、「効率、効果が低いミーティング」を嫌っています。 特に良くないケースが、「効果が低い」かどうかも判断できないような、とりあえず設定されたようなミーティングや、過剰な定例ミーティングです。

だめな例のひとつは、「すみません、とりあえず時間抑えさせてもらいました」というものだと思います。 もちろんこれらすべて、別にエンジニアに限らず嫌ですよね。

ちょっと余談ですが、チャットの第一声で「〇〇さん、お疲れ様です」だけ送ってくる、みたいなコミュニケーションってもやっとしませんか?(重要度や緊急度が判断できないうちに、反応を強制される気がして、僕は嫌なのでやらないようにしています)

意図や期待することについては、難しく考える必要はなく、たとえば以下のようなものだけでもよいと思います。

  • 手戻りを減らすために、技術的に不可能なことがないか早めに確認しておきたい
  • もっと簡単にできる方法はないかアドバイスがほしい
  • 記載内容に不足がないか、レビューを手伝ってほしい
  • 先に技術検証しておいたほうがいいことなどがないか相談したい
  • 同じプロダクトメンバーとしてシンプルに早めに知っておいてほしい
  • 同じプロダクトメンバーとしての意見を聞きたい
  • やる/やらない、優先順位を決めるための超ざっくりな見積もりしりたい(数日レベル?数ヶ月レベル?)

合わせて「こういう場ではない」ということも伝えておいたほうが良いと思います。

  • やることが決定したという事務連絡ではない
  • 「約束になる見積もり」をしてほしいわけではない
  • 売上の試算はこの後するので、そういったツッコミは一旦なしにしてほしい
  • 仕様のイレギュラーパターンはこの後検討するので、そういったツッコミ(略

目的が達成されたら、ささっと解散してしまいましょう。

もちろんエンジニア側も、設定された打ち合わせの目的が曖昧であればちゃんと事前に確認するのが良いでしょう。 ただ「何が目的ですか?」のように高圧的に感じさせうるワードではなく、「確認の目的って、技術的に不可能じゃないか確認するため、とかでいいですかー?」のように、おもいやりを持って歩み寄ったコミュニケーションをぜひしましょう。

そして、目的に沿って意見を言うようにするのがいいでしょう。たとえば、ざっくりとした要件を検討しているフェーズでは重箱の隅になるようなことは言わない、などです。 また、自分が期待するものと程遠かったとしても、それは協調してい作り上げ、ともに成長して行けば良いものだと思います。期待が何かフィードバックしましょう。

※ RSGT2019 で、歩み寄って「どういった要求・仕様がいいのか」を一緒に作り上げていたチームの事例がありました

今後「マサカリが怖い」と不用意に思わせて、結果的にプロダクトや組織に悪影響をあたえるようにならないよう、ほんの少しの思いやりが必要です。 なにかがうまくいっていないとき、ほとんどのケースでは双方に何らかの問題があります。でもそれは逆に言うと、双方にできることがあるということです。

エンジニアの仕事の特性に対する知識と共有認識づくり

確かにエンジニアの「集中の妨げ」というのは生産性に影響すると感じます。

どういったことが「集中の妨げ」になるのか、ある程度知っておき、あらかじめ対話しておくのが良いと思います。

多いケースは、集中している時にいきなり直接声かけて割り込まれるのはきつい(近いイメージは、「数学の問題をといているときに声かけられるときつい」など)というものです。

なので、

  • 最初の一声は、チャットなどの非同期コミュニケーションを使う
  • 集中している時間帯をお互いわかるようにしておく、共有しておく

などもできるかと思います。

ちなみにエンジニアリングマネージャーは割り込みをいとわないケースもありますし、エンジニアでもまったく気にしない人もいるので、その人の特性を対話の中で確認しておくと良いかと思います。

エンジニアも集中が妨げられたとしても、説明なくつっぱねることはせず「今集中して○○の開発していて、今離れると効率が悪いので、夕方でもいいですか?」「次からは一旦チャットで、相談内容含めて連絡くれると嬉しいです。チャットでも解決できるかもですし」といった説明を、面倒がらずにするのが良いと思います。

こういった相談などに使う時間量の目安を、あらかじめ定めておく

少し補足的ですが、想定していなかった割り込み作業は、見積もりにも影響するので、あらかじめ時間の目安を取り決めておくのもよいかもしれません。

ガチガチのルールにはせず、あくまでも双方の目安としての認識合わせをしておくイメージです(10%くらいの時間、とか)

また、あまり五月雨にして集中できるまとまった時間を減らさないように、一日のある時間帯にまとまった時間として確保しておくのも良いと思います。

さいごに

プロダクト企画者とエンジニアの対立構造のように書いてしまいましたが、職種によるものではない話だと思いますし、どちらか一方が良い/悪い、偉い/偉くないというつもりではありませんのでご承知おきください。

なんとなくエンジニアが特権階級なような書き方に感じたかもしれませんが、まったくそんなことは思っておらず、プロダクトをより良く作るフラットな関係性として、お互いに敬意を持ち、相手を思いやって歩み寄ることが大切だと思います。

ちなみにスクラムだと、プロダクトバックログのリファインメントがこれに当たると思います。

そういう意味だと、こういったように多く説明しないといけないことを「プロダクトバックログリファインメント」と一言で表現できるのは、フレームワークを採用するメリットともいえますね。

ちょっとまとまらないままつらつらと書いてしまいましたので、ご意見ぜひください

嫌われるのが怖い人間からの「『嫌われない』を諦めない」 #devlovex 登壇記

DevLOVE X「嫌われない」を諦めない というタイトルで登壇してきました。

伝えたかったこと

伝えたかったことの中で、今回メインに据えたのは

  • ものごとを推し進めるために、「嫌われる要素」を取り除く努力もしよう

ということでした。

このテーマの動機(個人的な部分をメインに)

「嫌われるのを怖がる」という弱み

僕は「嫌われるのを怖がる」タイプです。 「全員に好かれるなんて無理なんだから、嫌われちゃってもいいじゃん」という励ましを受けるやつです。HSP (Highly Sensitive Person) の数値も高めの人間です。

なので、「相手を伺いながら、大きな衝突が起きないように進める」というアプローチを取りがちで、「嫌われることをいとわずに物事を大きく進める」というのはかなり意識しないとできません。克服しようと努めている弱みのひとつです。

前職でメンターをしていただいていた方に「その、周りを見て調整する能力が強みであり最大の弱みだ」とフィードバックをもらったこともあり、今でも胸にとどめています。

「嫌われるのを怖がる」という強み

でも逆に、「嫌われるのを怖がる」という弱みに感じることも、裏返せば強みになりうると言うことだとも思います。

僕と同じように「嫌われるのを怖がる」ことを弱みだと思っている人に、それもうまく活かせば物事をうまく進める要素になるんじゃない?という投げかけをしたかったというのがこのプレゼンテーションの動機です。(もちろん自分への投げかけでもあります)

また同様に、つい「嫌われるのをいとわずに進める」ことが多い人に、ちょっと立ち止まってこういうことを考えてみてもいいんじゃない?という投げかけをしたかったという動機もあります。

「『嫌われない』を諦めない」ことの矛盾

ちなみに僕がスライドに書いたような「嫌われないようにする」行為は、時として「あざとい」「腹黒い」ように映ることがあり、それが結果的に「嫌われる」につながるという矛盾があります。

つまりは完全に嫌われないことなんて不可能で、「全員に好かれるなんて無理なんだから」というのは真理ですね。

ただ、その中でも「無用に嫌われる必要はない」(と同時に「無用に媚びる必要もない」)というのが言いたかったことになります。

どちらのアプローチも一長一短で、どちらのタイプの方も、自分が自然に振る舞えるやり方をベースにしながらも、他方の要素も取り入れることで、成果を強化できるのではと考えています。

まぁ当然のことなんですが、関係者が楽しく成果でるのであれば、アプローチは結果論でしかない話だと思います。

「そのための準備」のスライド

スライド内の「アプローチ編」の各節の最後の「そのための準備」というスライドを入れています。

さらっとシンプルな問いの形で書いていますが、ここに答えていくのはそれなりに大変なことだと私も思っています。 「自分の広めたいこと」を深く理解して、何をどういったアプローチで解決してゆくのか。これをができていると自信を持っているでしょうか?

もちろん自信がないと始めてはいけないというわけではありませんが、これを楽しみながら続けていく必要があると思っています。今回のようなコミュニティは、まさにそのためにもあると思っています。

公演中に余談したこと

「自分の広めたいこと」を、自分が毀損していないか

僕は現場の支援から離れるときに、冗談で「アジャイルのことを嫌いになっても、横道のことは嫌いにならないでください」ということがあります。「逆だろ!」のツッコミ待ちですね(恥)

これはもちろん冗談なのですが、真面目な要素も含んでいると思っています。

人は、「誰が言ったか」でその良し悪しを決めてしまうことがあります。 これは「色眼鏡」な面が大きく、聞き手としては可能な限り避ける努力をすべきことであると思いますが、実際そういった判断が行われることは多いと思います。

つまり「自分の広めたいこと」を、「自分というフィルター」が毀損してしまうようなことは避けたいと思っています。(e.g.「あの人が言ってるから、あれはなんか嫌いだ」)

ykmc09.hateblo.jp

その他もろもろ

舞台裏

私の DevLOVE 初登壇は2013年3月でした。 このあとの私のキャリア選択の大きな転機の一つだったと思います。

devlove.doorkeeper.jp

このとき企画協力してくださった @TAKAKING22 が、今日は裏番組。 そして、このときに共同登壇した当時の会社の同僚が、セッションを見に来てくれていました。 さすが長い歴史を持つ、コミュニティ。私にとってもドラマを提供してくれました。

Peter Senge の名言

人は変化に抵抗するのではなく、変えられようとすることに抵抗する

この言葉は以前 @hiranabe に教えてもらった言葉で、とても気に入っている言葉です。こちらの対談の中で教えてもらったので、ぜひよければ記事もご覧ください。

next.rikunabi.com

スライド内の記事

スライド内で紹介した、「アジャイルをどう紹介しているか」は以下の記事からご覧ください。

flxy.jp

また、同僚の事例スライドは以下です。

さいごに

DevLOVE X 本当に楽しい素晴らしい場でした。 こんなに豪華な登壇者の中にまぜてもらったことを光栄に思います。

運営のみなさん、この規模のイベント運営、本当に大変だったと思います。 お疲れ様でした&ありがとうございました!

人望が集まる人の考え方

人望が集まる人の考え方

flexy に取材いただき、アジャイルの話をしました

取材依頼をいただきまして、話してきました。

言いたかったこと

記事が、ちょっと偉そうな感じのトーンになってしまったかもです・・・。

言いたかったことは、

  • なんでもいいから良くすることを始めてみよう。別にルールなんてないよ。
  • とどまることなく、世界に誇れるくらいまで邁進しなきゃな
  • 経営層、マネジメント層はちゃんと理解して、チーム支援したげてね

という感じです。

嬉しかったこと

取材いただいた担当の方から、

今回の取材を通してアジャイルがすごくクリアにわかるようになりました。そして横道さんに教えていただいたように振り返りを早速実践しています。

というメッセージを後日頂いて、これだけで取材受けた甲斐があったな、と思いました。

武装解除 × アジャイルリーダーシップ(Agile Leadership Summit 2019 をやります)

2019年7月8日(月) に、Agile Leadership Summit 2019 というイベントを開催します。

基調講演 + Open Space Technology*1」という構成で、企業内でアジャイルを推進、実践している方を対象したイベントになります。

基調講演は、日本紛争予防センター(JCCP)理事長の瀬谷ルミ子さんという方で、世界の紛争地の復興、治安改善、兵士の武装解除・動員解除・社会復帰(DDR)を行われている方です。

www.jccp.gr.jp

武装解除・動員解除・社会復帰(DDR」。
究極のコンフリクト・マネジメントですね。 アジャイル導入・推進や、もちろんプロダクトを作る過程においても、さまざまな利害関係者のコンフリクトを解消することが大きな仕事の一つになっていると思います。

今日、瀬谷さんご本人と打ち合わせを、アギレルゴコンサルティングの川口さんとしてきたのですが、対峙している表面上の事象自体やコンフリクトのスケールの大きさは違えど、(失礼ながらも) ひょっとして同じ仕事なのでは? と錯覚するほど共感する内容をたくさんお話いただきました。

私が、瀬谷さんの著書の中で共感を覚えたのは、以下の一節です。

あのときは、私に専門性がないことが問題だとおもっていた。でも、たとえ私がどれほど有能な専門家でも、 人々が自発的に望んで居ないことを押し付けるのは、ただの自己満足なのではないかーーー

職業は武装解除

職業は武装解除

私が行っている仕事は「武装解除」ほどの大義はないかもしれませんが、こういったジレンマを感じた瀬谷さんがどのようなアプローチで紛争地のコンフリクトを実際に解決していったのか。それは私たちの仕事にも大きなインスピレーションを与えると思います。 当日は紛争解決の生々しいエピソードを多くしていただける予定ですので、ぜひお楽しみに・・・!

こういった話を聞いた後の Open Space Technology ってどんなテーマになるのかなぁ・・・今から楽しみ・・・!

チケットはこちらから。(有償ですが、非営利です。) www.eventbrite.com

余談

Linda と瀬谷さんが邂逅するのをみてみたい・・・!

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

*1:参加者自身がテーマを出し、グループに分かれた参加者同士でそのテーマについてディスカッションを進める形式