自己紹介と企業紹介
柴戸純也氏（以下、柴戸）：よろしくお願いします。こんばんは。こちらのタイトルで弊社で取り組んだことを紹介させてください。
最初に言うと、今日はきれいなテクニック的な話というのは少なくて、けっこう泥くさい話が多めです。しかし全部体験談で、1つのリアルとして聞いてもらえたらうれしいです。よろしくお願いします。
まず自己紹介させてください。リンクアンドモチベーションの柴戸純也と申します。2018年に現職のリンクアンドモチベーションに入社しました。会社の方針をコンサルティングの非テックの状態から、ソフトウェアエンジニア組織を内製化しようとするタイミングで、1人目の社員エンジニアとして入社をしました。現在はプロダクト開発だけでなく、会社全体のDXも推進しています。
弊社の主なプロダクトは、「モチベーションクラウドシリーズ」です。どんなプロダクトかというと、みなさんが所属している組織・チームのエンゲージメント状態を、定量的に診断して改善するクラウドサービスになります。おかげさまで多くのお客さまにご利用いただいております。
（スライドを示して）私の組織については、ざっくりこのようになっています。1人目で入社して、現在の管掌組織全体としては、およそ80名程度。左側（に書かれている）エンジニア、PM、デザイナーの範囲では60名程度という状態です。
私の役割としては、PMを管掌しているCTOということで、この場に立っています。
プロダクトマネジメントトライアングルで整理する組織の分断状態
ここからが本題になります。さっそくですが、こういうことってありませんか？ 経営からは「なんでその投資が必要なんだろう？」「技術負債？」と（言われる）。ビジネスサイドは「顧客のことわかっているかな？」とか（言われる）。エンジニアサイドは、「なぜその方針に？」「そんなんだと価値が蓄積されない」「何のためにやっているんだろう？」とか（言われる）。
恥ずかしながらこういうことは、僕らが通過した状態でもあります。でも、（僕ら以外の）多くの方々も、なんとなく理解できるような状態かなと思います。
これらの状態の構造を、あえてプロダクトマネジメントトライアングルで整理してみました。（スライドを示して）こんな感じの構造かなと思います。
エンジニアとビジネスの間では、「盲従」「懐疑」。エンジニアと経営の間では「不信」「不明」などの関係。組織的負債の1つの状態かなと。なんとなく相互理解、一体感がない状態。
2018年頃の僕たちもこんな状況でしたが、現在はほぼ解消されてきて、仲間と楽しい日々を送っています。
セッションのアジェンダ
ということで、その間に何をしたのかがここからのお話になります。1つ目が分析編。表層的なことをやるのではなくて、根本から改善したかったので、そもそもなぜそうなっていくのかというメカニズムを整理して、認識を揃えました。
次に、そこから対策編としていろいろやった中で、効果的だったことを1つに絞ってお話しします。すでに同じような悩みを抱えている方はもちろんですが、今はそうでもない方も、「放っておくとそうなるかもよ」というメカニズムのお話からします。
なぜ分断が起きてしまうのか？
なぜそんな状態、関係になるのかと。（スライドを示して）このように整理してみました。メタファーとして、モノリスからマイクロサービスをイメージしてもらえればと思います。（スライドの）左側。多くのスタートアップのような立ち上げフェーズの場合。「統合」、いわゆるモノリスとか、モジュラーモノリスのイメージです。最初は同じ人が、Biz、Dev、経営の3つともを見ていたりもします。少人数ですし、統合されていることが多いかなと。そのほうが効率的だし、メリットも大きい。
それからプロダクトが成長したり、複数・多角化したりする中で（スライドの）右側へ。認知負荷を下げたりなど、効率を追求して機能分化していくマイクロサービス化。だんだんと言語が変わって国も変わり、分化していくイメージです。これは非テック企業だから（であって）、古い企業だからとかではないかなと思っています。
ここまでは必然で、成長過程では機能分化しなければならないんじゃないかと僕自身は思っています。
ただ、問題はここからかと。まず上段として、2つの変化が生じる。すると下段で同じ知識レベル、言語を維持できなくなって、相互理解の希薄化、組織全体に強力な遠心力が働くことによるサイロ化（が起きます）。
さらに放っておくと「めんどくせー」とか、諦めが蔓延して分断していく。僕らはここまでではありませんでしたが、2018年頃は近しい状態でした。
ここまでが1つ目のアジェンダです。こういったことは常に起き得ることであり、返済し続けなければならない組織的負債の一部として認識を揃えるところからやりました。
「通訳になる」という対策法
これらを前提に、対策編として改善のお話。開発の優先度のつけ方とか、仮説検証プロセスの改善とか、いろいろやりました。でもそれらはみなさんもよく知っているかなと思うので、あえて今日は技術的なことではなく、もう少し組織寄りで、泥くさくて面倒くさい、でも効果的だったと思う取り組みを1つに絞って共有します。
（スライドを示して）この構図の中で何が効果的だったか？ 僕自身が「通訳」になったことだったと思います。
「は？ 通訳って何？」という話ですが、通訳を英語でいうとinterpreter。単語としてはinterestとも似ていて、役割としては「興味を持って異なる世界をつなぐこと」かなと思っています。
では具体的に何をやったのかと。（スライドを示して）通訳のステップと、具体的にやったことはこちらになります。ステップ1。まず自分から協働意志を示すことをやりました。人と人との関係なので、これが最初でした。
ステップ2「つなげる」。上段が、「言葉をつなげて相互理解を促進しましょう」「相手がイメージできる言葉に変換して、プロトコルを揃えて、自分たちの理解と相手の理解をつなげていきましょう」と。下段が、「指標をつなげて同じことに向かいましょう」というものになります。
これによって協働意志を醸成して、相互理解の希薄化の問題とサイロ化を改善していったと思います。以降では、それぞれの具体と学びとして、「これはやめたほうがいい」「逆にこれがいいと思いました」という構成で紹介します。
まず自分から近づいて協働意志を醸成する。「まず距離を近づけよう」ということの具体例からいきます。
取り組み1：協働意志を醸成
通訳の1つ目です。大前提は、人間と人間なので、感情が大事という話です。面倒くさいことですが、例えば、そもそも自分たちのことを理解してくれない人の言葉なんてまったく響きません。仕組みや制度だけ用意しても、なかなかネガティブの根源の解消にはつながらないし、喜んで受け取る人はいません。
これを前提にして、まず「仲良くしたいし、あなたのことを知りたい」と興味関心を示すことからやりました。「俺たちのことを理解しろよ」ではなくて、営業やコンサルのことを理解することから始めました。どう思っているのかとか、同行してどんなことを言ったりやったりしているのか（を見る）。
学びとして、この工程をすっ飛ばして技術やテクニック的なことで改善に向かうことは、僕としてはやめたほうがいいと痛感したことです。そうではなくて、ふだんから感情や意図を聞いておくと、そこからの合理の理解とか、納得感醸成が双方早くなることをメッチャ実感しました。
なので、非常に面倒くさいと感じられるかもしれませんが、案外盲点でもあって、意外と感情は大事です。なので、翻訳として、最初は仲良くなって協働意志を作ろうとするところからが大事だと思いました。
取り組み2：言葉をつなげて相互理解を促進
通訳として次にやったことが、言葉をつなげて相互理解を促進。僕自身が入社当初にぶつかったのが、常識が違うし、言葉も通じないことでした。ほかにも「なんでそんなエモーショナルな感じで来るんだろう？」とか。
（スライドを示して）そりゃそうだよなと思ったのがこちら。『エンジニアリング組織論への招待』の著者の広木さんは、このように表現されていました。「そもそもスキルも時間軸も常識も違う」「なので、隣接領域の知識を持つ者としかコミュニケーションは成立しないよ」と。「国が、村が違う」「基本原理。グルー、接着剤（のような）人材、つまり通訳がいるといいよ」と。解釈した僕が、通訳としてやったことはこんな感じです。
こちらにメチャクチャわかりやすく書かれていて。食物繊維が20グラムと言われてもぴんと来ない相手には、サツマイモと対比する。「開発したアプリは100万人にアプローチできます」だけではなくて、これまでとの前後で対比すれば、そのすごさが伝わりやすくなる。
どんな対比を実際にしたのかについては、この後に具体的に発表します。こちらの学びとしては、正確な理解を期待すること。難しい言葉を使うのではなく、相手の頭の中にあるものと対比して、プロトコルを揃えて、共通イメージを持つ作戦をやりました。
具体を大きく2つに分けて紹介します。まず1つ目です。「メタファーでイメージを持ってもらおう」シリーズの実例です。（スライドを示して）上から、過去にあったAWSの長期間停止の深刻度であれば、「JRが止まったらアポ遅れますよねと、そのぐらい大きなことなんです」とか（で伝える）。
どれぐらいの人が必要な筋肉かわかりませんが、手戻りであれば、「作った後にそれを言うって、ハンバーグができてからやはりチーズinにしてください」と（伝える）。「作り替えですよ」とか。
副業であれば、「なぜキックボクサーである那須川天心さんが、メイウェザーとボクシングするのか」「キックボクシング界が盛り上がるんです」と。「しかも、練習じゃなくて試合に出ないと」とか。
伝えたいことを相手の持っているもの、知っていることに置き換えて、そこを入口にして伝える。
互いに違いを知ろうというシリーズの実例で、次は対比です。一例をいうと、開発とコンサルの研修商品です。そもそも人材育成の仕方とか学び方とか開発の流れを、クラウドプロダクト、コンサル商品と並べて対比させて違いを知ってもらうとか、同じ部分と違う部分を理解してもらうことに取り組みました。
こんな感じに対比して伝えるようにすることは、効果的だったかなと思います。このようなかたちで、少しずつ壁を越えることができたと思います。
取り組み3：「指標」をつなげる
通訳としての3つ目（に行ったこと）が、指標をつなげて同じコトへ。共通の目標につなげていくことに取り組みました。（スライドを示して）左側です。れぞれアウトプットだけに目が行く。そこから右側のような共通の目的に向かっている協働の状態を作ることに取り組みました。
こちらも同様に学びとして、やめたほうがいいことは、全員が同じ時間軸ではないので、全部を同一にということは狙わないほうがいい。
ミッションとかインパクトは遅行指標過ぎるので、アウトプットとの間にアウトカムを設定して、Why、ミッションに接続してコミュニケーションをすることをやりました。
もう少し実際の例をあげると、前提、中計、ミッション、プロダクトビジョンから落とし込むんですが、事業KPIとプロダクトKPIを対応づける。右側の事業KPI、例えば継続率とか単価などを、左側のプロダクトのアウトカムと対応づける。
例えば、ある担当者のアクセス数だったり、ある画面の設定数だったりを対応づける。それ以外でデータからサイエンスできているものは、ヘルススコアというものを用いて接続して追求することをやりました。
学びとしてはこの領域には「こう」というフレームワークがあるわけではないので、厳密なマップや接続の計算式を完成させて始めるのではなく、更新しながら育てていく方針がいいかなと思いました。
効果としては、こういったことがPMの感覚的なものではなくて、エンジニアにとっても構造化してロジカルに理解できるようになりました。PMだけに閉じた理解だけでなく、エンジニアにとっても関係がわかることで、むやみにアウトプットだけ追う事態は避けられているかなと思います。
まだまだ改善中ですが、エンジニアのオーナーシップ向上につながるといいなと思っています。
以上が僕たちが取り組んだ、相互理解と一体感のある会社作りの活動記録の紹介でした。結果、かなり分断の声は減らせて、改善できたかなと思います。
分断は組織的負債の一部
最後にまとめになります。分断は誰かのせいじゃないと思うし、技術負債のように返済し続けなければならない組織的負債の一部として捉えています。そこを通訳として接着してきました。
やはり経営陣の1人であるCTOだからこそ、同じことにつなげられる大事な役割だなと信じています。大切なことはだいたい面倒くさいので、そう言い聞かせながらやっています。
まだまだ未熟な僕たちで、一度やったら終わりという類のものではないので、文化になるまで、当たり前になるまでし続けたいと思っています。
そもそも、相互に尊重されると感じて、お互いに背中を預け合える関係って楽しいなと思っています。これも幸せなデベロッパーエクスペリエンスを生み出す土台かなと思って取り組んでいます。
以上です。ご清聴ありがとうございました。
