Tabelog Tech Blog

食べログの開発者による技術ブログです

速い開発のためのコミュニケーションと知的謙虚さ

この記事は 食べログアドベントカレンダー2024 の21日目の記事です🎅🎄

はじめに

こんにちは。食べログ開発本部、技術部部長の池上です。

今年の食べログアドベントカレンダーは『開発を圧倒的に速くする』というテーマですが、技術的な話や組織の仕組み化の話ではなくコミュニケーションや知的謙虚さといった少々曖昧なテーマについて取り上げます。

組織文化の重要性

食べログ開発本部では『開発を圧倒的に速くする』上で重要なメッセージとして 「HRTの心(Humility / Respect / Trust)を忘れない」 というメッセージも掲げており、システムや組織の仕組みのように形はなくても皆に持ってもらいたい共通の考え方としています。

プロダクト開発を速くするためにはシステムも組織も速い開発が可能な状態である必要があり、そのために食べログでは技術的負債の返却やシステムを進化させていく様々な取り組みをしていますし、1 組織や開発プロセスといった仕組みの面でも改善に取り組んでいます。2

しかし、それだけでは不十分です。プロダクト開発という活動は人間同士、組織同士のコラボレーションですから、普段のコミュニケーションや判断においても、速い開発が可能な行動ができている必要があると考えます。これは組織文化の領域と言えます。

組織文化醸成のためにはMVV(Mission, Vision, Value)やクレドなどの言葉も大事です。そして、言葉に刻まれた想いや意図は実際の普段からの行動で育まれ、醸成され、組織文化として実をもって定着していくものと考えます。 このエントリでは、そのために重要と考えている事を書いていきます。

境界を尊重したコミュニケーション

人間同士、組織同士のコミュニケーションにおいては、相手の裁量や責任の範囲に入り込み「ああすべき、こうすべき」と強制するのは関係がこじれるリスクをはらんでいます。また、強制の意図が無いとしても相手が「強制された」と感じないようにする事も大事だと考えます。

強制の意図があろうがなかろうが、他者をコントロールしようとする行為は相手に大きなストレスを与えます。人や組織の裁量や責任範囲は、その人や組織のメンバーにとってアイデンティティーに近いところにあります。 特に組織のリーダーはそうでしょう。アイデンティティーが侵されると防衛的か攻撃的か、いずれにせよ良くない感情的な反応を生み関係悪化の原因となります。

境界を侵してしまい少し危なかった話

昔、あるチーム間でこのようなやり取りがありました。

事の起こり

Aチームが主導するプロジェクトにおいてBチームとの共同作業が重要であり、どのように進めていくかを相談するミーティングでした。私はAチームリーダーの上長の立場で出席していました。

Aリーダー 「Bチームは◯◯さんがいるし彼が担当すればいいと思う。△△さんも経験があるし・・・(以下略)」

Bリーダー 「・・・あの、なぜAチームがうちのチームの誰がやるとかを・・・?」

危なかった局面

Bリーダーの言葉、口調、表情から困惑とも不本意とも取れる感情が察知できました。まずいと思って割って入り、強制する意図ではなくこちらで勝手に持っていた腹案を述べたに過ぎないこと、アサインはあくまでBチームの裁量でありBチームが判断して決めるべき事というのが我々の本意と説明しました。そしてその後にAリーダーから、

Aリーダー 「事前に、そういうコミュニケーションは良くないと言われたばかりだったんですよね・・・すいません」

という反省の言葉がありました。

顛末

実は、Aリーダーと私はこのミーティングに望む前、プロジェクトの進め方についてあれこれと話し合いをしていました。その中でAリーダーが「Bチームは◯◯さんがやれると思う、△△さんも経験がある」といった腹案を持っていたので「そういうの考えるのは良いけど、それはBチームが決めること。言うとしても伝え方には注意が必要」とフィードバックしており、その事を即座に思い出して反省の言葉に繋がったのでした。

以後、この話し合いはスムースに進みネクストアクションを決める所まで進めることが出来ました。しかし、このエピソードはより速い開発を阻む下記のような危険性をはらんでいました。

  • 話がこじれてミーティングで結論までたどり着けない
  • 両チームの関係性が悪化する
  • 関係性の悪化から合意までの道のりに新たな課題や障壁が生まれてしまう

両リーダーの資質に助けられた

少々危ない状況がありながらもミーティングの目的は達せられました。まずは両リーダーの下記のような素晴らしい資質と行動に言及したいです。

  • Aリーダー
    • 自分の良くなかった面を直ぐに認め反省の弁を述べる率直さ
    • 失敗に対する「気づき力」 の高さ
  • Bリーダー
    • ストレスを感じた時点で明らさまな感情的表現をしなかった冷静さ
    • その後の話し合いで引きずらなかったミーティングに対する目的意識の強さ

人間同士ですし、いくら気をつけていてもコミュニケーションにおいて好ましくない局面が発生することは避けられないでしょう。そうなると、その局面において関係性を悪化させず修正する方向への地力が試されます。両リーダーはそのような局面においても関係性を悪化させず、ミーティングの目的を達成する方向へ行動を修正しました。このような行動も良い文化の醸成に大きく寄与します。

しかし、飲み込んでいたら良い議論にならない。どうすべきか?

とは言え、議論において聖域があっては良い議論になりません。より良い議論からより良い意思決定に導くためには、相手の裁量や責任に関わる部分であっても参加者が率直に自身の考えを場に出し、意思決定への一助とする必要があります。 そのような場にするためには、下記の要素が重要だと考えます。

  • 相手を尊重している姿勢がある
  • 「私の意見 vs あなたの意見」というお互いの正義での殴り合いにしない
  • 「場に出た意見 vs 私たち」という一緒に考える構図を保つ

そのためには下記のような伝え方が有効です。

  • 提案、要望、質問として場に出す
  • あくまで個人的な意見として伝える

これらはコミュニケーションのHOWTO本でも良く言われることですが、人間同士だけではなく組織同士でも同様だと実感しています。

しかし、Aリーダーは「〜と思う」と個人的意見であることを表明しており、単に言葉を付け足すだけでは難しい局面もありそうです。提案・要望・質問だとしても、アイデンティティーに近いことについて矢継ぎ早に言われると詰問っぽくなってしまい、強めの「圧」を感じるかも知れません。そうならないためには「〜と思っているんだけど、どうだろうか?」「〜だと嬉しいんだけど、〇〇さんとしてはどうかなぁ?」という具合に、必ず相手に考えてもらうターンを用意すると良さそうです。

やり方はお互いの関係値で変わる

上記のやり方は丁寧すぎてまどろっこしく感じるかもしれません。良い議論にするためのコミュニケーション方法はお互いの関係値が大きく関わりますし、組織形態や開発プロセスなども関係すると考えます。 今期放送している人気サッカー漫画・アニメのように、お互いのエゴを思いっきりぶつけ合い化学反応で自分もチームも成長していくというやり方もあるでしょう。

エンジニアリングにおける相手を尊重する文化

唐突ですが、エンジニアリングにおいては相手のアイデンティティーを尊重したコミュニケーションがあります。そう、コードレビューです。

LGTM(Looking Good To Me)、IMO(In My Opinion)・・・、なんと謙虚で趣き深いフレーズでしょう。コードは書いた人自身の裁量と責任の範囲にあります。また、自分自身が生み出したものであり大げさに言えば分身のようなものです。 裁量や責任と同じく、自分が生み出したものもその人にとってアイデンティティーに近いところにあります。「あなたが書いたコードはあなた自身ではない」としばしば言われますが、同時に、分かっていてもそう考えるのは中々難しいという話も聞きます。だからこそ、より良いコードレビューにするためにこのような習慣、文化が発達し定着してきたのでしょう。

このような、コードレビューで行っている 自分に対しては謙虚に、相手に対してはアイデンティティーを尊重したコミュニケーション は、普段のミーティングでも非常に重要な姿勢だと考えます。

極端な5W1Hや断定表現

「絶対に・間違いなく・決まっている」といった断定表現や、5W1Hにおける極端な度合いの表現の使い所には注意が必要だと考えています。極端な5WHとは下記のようなものです。

5W1H 意味 極端な度合い
WHO 誰が みんな
WHEN いつ いつでも
WHERE どこで どこでも
WHAT なにを 全て
WHY なぜ 何があろうと
HOW どのように どうやっても

プレゼンではこういった表現が効果的な場合があるかも知れませんが、意思決定のための議論では下記のようなデメリットもあると考えます。

  1. 一般化して自分の意見に正当性を持たせようとしていると思われる可能性
  2. 強い言葉に頼ることで根拠の弱さを補っていると思われる可能性
  3. 権威勾配により意見に強制性が出てしまい、議論の方向を決定づけてしまう可能性

1と2については、極論や主語が大きい意見は説得力が乏しくなりがちなのと同様です。意見の「確からしさ」自体に疑念を生じさせてしまう可能性があります。

3.の権威勾配について

3は特に重要な要素なので少々説明します。また、私自身、権威勾配自体を否定する考えは持っていません。注意が必要な場面があるという考えですので、ご了承頂ければと思います。

ここで言う権威勾配は、上司部下という職位の上下関係だけではなく、スキルやナレッジの差や職種による専門性の違いも含まれます。

上司部下という職位の関係性については言うまでもありません。しかし、フラットな関係性においても、スキルが高い人の意見を受け入れがちになることはないでしょうか?また、企画と開発など専門性が異なる場合でも、お互いの領域について知識が全くないわけではないのに専門家から断定的に言われるとやはり自分が間違っていると思ったり、意見を引っ込めてしまう事はないでしょうか?

極端だったり断定的な表現は、権威勾配が加味されるとそのような状況を誘発する可能性を秘めていると言えます。 みんなそう思ってる、いつもそうしている、絶対にこうなる・・・・。つい口をついて出がちなフレーズかもしれませんが、大事な意思決定を伴う議論においては使い方に注意したいところです。

ひらめきは疑いつつ自説の証明にならないよう熟考する

より速くより高い価値を創り出すためには、より良い意思決定が必要となります。しかし、判断の誤り1つで余計な時間を使う羽目になったり、あまり適切ではない施策を実施してしまう状況に陥ります。その上において、思考や認知の歪み(バイアス)は大敵と言えます。

バイアスから判断を誤りそうになった話

事の起こり

昔、新しい基盤の導入のプロジェクトメンバーから、未知のエラーが発生しておりどう対処すべきか緊急の相談を受けました。

結論めいたものを抱いていた前半

私はビジネスやユーザへの影響のリスクを最重視していましたし、関係者の一人は相談のミーティング前から切り戻しが良さそうとの所感を持っていました。相談ミーティングではユーザ影響は否定できないことも分かり、私の考えは切り戻して調査する方に傾いていき、結論としてではないものの「いったん切り戻して調査したほうが良さそうだね」と発言したことを覚えています。

方向転換の後半

しかし、幸い切り戻しを即決する流れにはなりませんでした。メンバーは状況の説明や私からの質問に答えつつ粘り強く調査を続けており、その中で、エラーは限定的なケースで発生すること、エラー率も0.0003%と極めて低く許容範囲内と言えることが分かってきました。

顛末

エラー率が明確にわかったことが決め手でした。結論としては、調査の優先度は下げ前進対応を選択しました。

この話において私の姿勢や判断には反省点がモリモリとあります。私は状況整理の壁打ち相手にはなれていたかもしれませんが、当初の考えに囚われ続けていたら、余計な調査を優先させ基盤導入を遅らせる危険性があったわけです。 自分の反省の前に、まずはメンバーの素晴らしい姿勢について述べたいです。

技術的粘り強さと率直に意見を述べる姿勢

ミーティング中、私はいったん所感として「切り戻したほうが良さそうだ」と発言しています。しかし、プロジェクトメンバーは自分から相談しにいった上長からそのような意見が出ても流されず、より詳細な状況を共有してくれたり、ミーティングしながらでも粘り強く情報を深堀りして不明だったエラー率を明確にしました。その上で、問題ないと思うと定量を論拠に率直に意見を出した行動はファインプレーでした。

このような技術的粘り強さと率直な姿勢は、より良い意思決定をする文化の醸成に欠かせないものだと考えています

私の姿勢や判断の反省点

さて、私の反省点について述べていきます。

  1. 「ビジネスやユーザ影響のリスク重視」という自分のポリシーを重視しすぎていた
  2. 自分のポリシーと親和性が高い関係者の意見を重視していた
  3. 上記1,2から無意識のうちに結論めいたものを抱いてミーティングに望んでしまっていた
  4. 定量の軽視

1〜3については言わずもがな、バイアスに侵されていたと言わざるを得ません。普段から非常に気をつけているにも関わらずです。言い訳がましくなってしまいますが、ミーティング続きでコンテキストスイッチが上手く出来ていなかったこと、緊急性が高かったこと、全社に導入していく重要な基盤技術というプレッシャーなども、定性的で合理性に欠けたリスク重視の姿勢に影響していたと考察しています。

4について、このようなケースでは定量を重視することは当然です。当初、エラー件数は分かっていましたがエラー率までは明確になっていませんでした。それなら、まず全体でのエラー率を確認するのは当然なのにユーザ影響が否定できない事ばかりを重視してしまい、エラー率での判断に至るのに時間がかかってしまいました

判断を誤りかけた原因となる思考特性

このような判断ミスを犯しかけた原因について考察します。

人間には2つの思考パターンがあるとされています。それは速い思考(システム1)と遅い思考(システム2) です。これは名著「ファスト&スロー」で非常に詳細に説明されていますので、ここでは簡単な説明とさせていただきます。

  • システム1
    • 速い思考。直感的でありほぼ自動運転していてバイアスが混ざりやすい。 規則性がありFBが得られる学習の期間があればスキルとして習得可能な場合もある。
  • システム2
    • 遅い思考。複雑な計算や論理的な思考。労力を使うため怠け者でありシステム1の結論を受け入れてしまうこともある。

バイアスの根本には、こういったシステム1、システム2の特性があるとされています。このケースですと、自分のポリシーおよびそれと親和性が高い意見を重視していた確証バイアス、ミーティング途中まではその考えに縛られていた一貫性バイアス、また、このようなケースにおける自身の成功・失敗体験からくる代表性ヒューリスティックなどが考えられます。

私の怠け者のシステム2はシステム1の判断を安易に受け入れてしまい、自分の中で一定の結論めいたものを形成してしまっていたのでしょう。振り返ってみるとバイアスだらけで反省しきりです。

気をつけていても難しい。思考訓練の実践あるのみ

このようなバイアスは人間に備わっている思考習性からくるものであり、気をつけていても難しいところがあります。今回の話は判断ミス未遂で済みましたが、普段から気をつけてはいたので、すんでのところでメンバーの行動から自身の思考の軌道修正が出来た側面があります。

こういったバイアスに対抗する手段を意識し始めた時期、個人的には下記のような思考の癖を付け、ミーティングや1on1、仕事とは関係ない普段のコミュニケーションでもそのように思考するよう意識していました。

  • 自分のひらめきはいったん疑ってかかる
  • 自分の考えの証明になってないかを振り返る
  • 「”今そう思ってる自分”よりも”情報をアップデートした自分”の方がマシなはずだ」と考える

もちろん今も努力中です。やはり、コンテキストスイッチが激しかったり、難題の熟考中など脳が疲弊してきた時が要注意です。

おわりに:知的謙虚さと組織文化

以上、述べてきたことに共通していることがあります。それは知的謙虚さと呼ばれるものです。

自分の知識には限界あり、それゆえ認知の死角があるし自分の判断には不確実性があるという認識や姿勢です。私なりに言い換えると、私は私が知ってることしか知らない。なので、私は決して完全な合理性を備えていないし、私の知識、判断、信念は間違っているかもしれないという自己認識を持つことと捉えています。

ある人気小説・アニメにおいて、このようなやり取りがあります。

主人公 「◯◯は何でも知ってるな」

ヒロイン 「何でもは知らないわよ。知ってることだけ」

この人気小説・アニメにおける物語のシリーズにおいてお決まりのやり取りなのですが、ヒロインの知的謙虚さを伺うことが出来ます。文字にすると言葉遊びのような、しかし、ごく当たり前の事実を自己認識することだと考えています。決して自分を卑下したり過小評価するということではありません

最初にご紹介した組織同士におけるアイデンティティーのテリトリー侵犯、次にご紹介した断定的で極端な主張のデメリット、最後にご紹介したバイアスによる判断ミス未遂、いずれも直接的にデリバリも品質も低下させる要因となります。しかし、上記で説明した知的謙虚さの前提に立てば回避が可能です。それゆえ、より速くより高い価値を届けることができる組織文化の醸成のためにはとても重要な要素と言えます。

少々大げさかもしれませんが、知的謙虚さはいわば「戒め」のようだと思うことがあります。これを肝に銘じて、システムや開発プロセスといった仕組みではないけれど重要で、「普段からの私たち自身の行動によって育まれ定着していく組織文化」 の発展に努めていきます。

明日は @ame001 さんの「久しぶりにチームリーダーやってみた」です。お楽しみに!

仲間を募集しています!

食べログでは一緒に働く仲間を募集しています。ぜひ食べログでのキャリアをご検討頂けると嬉しいです!