概評
約2年前、僕の上司が「Team Topologies」「組織デザイン」「他者と働く」の3冊を「3大おすすめ書籍」として挙げていました。「他者と働く」は以前から読もうと思っていたものの、内容をよく知らなかったため、必要なタイミングで読むことができず、放置してしまっていました。
SREという横断的な組織に属している特性上、異なるナラティヴを持つ人たちと一緒に仕事を進めることが多いと感じています。さらに、約1年前にマネージャになってからは、その傾向がより顕著になりました。特に、この本で言及されている「私とそれ」の関係に近い状況がほとんどでした。そのままではうまくいかず、偶然「私とあなた」の関係に変わったことで改善したケースもあれば、依然としてうまくいかないままのケースも多く残っているように感じます。
本書を読み終えた感想としては、日々の仕事の中で自分が抱えていたモヤモヤに対して指針を示してくれる内容だったのではないかと思います。ただし、個人的には「解釈」が非常に難しいテーマだと感じました。「観察」が中途半端になると、「解釈」も当然中途半端になり、その結果、効果のない技術的アプローチを取って挫折する、という状況が目に浮かびます。本書で指摘されているように、「解釈にはパートナーが重要」とのことで、そういったパートナーを見つけることが、自分にとっての課題になるのかもしれません。
印象的だった内容
適応課題を解決するのが「対話」
ハイライト
適応課題（adaptive challenge）とは、既存の方法では一方的に解決できない、複雑で困難な問題を指します1。一方で、既存の方法で解決可能な問題は技術的問題（technical problem）と分類されます。
適応課題に対しては、対話（dialog）を用いたアプローチが有効です。対話とは、一言で言えば「新しい関係性を構築すること」2。権限や立場に関係なく、自分の中に相手を見出し、相手の中に自分を見出すことで、双方向にお互いを受け入れていく過程を指します。
哲学者マルティン・ブーバーは、人間同士の関係性を「私とそれ」という道具的な関係と、「私とあなた」という固有の関係性に分類しました。「私とそれ」の関係性は必ずしも悪いものではなく、効率性を重視した関係を築くことで、円滑な業務や組織運営が可能となります。
本書では、「私とそれ」の関係性の例として、レストランのウェイターが挙げられています。「店員」という役割を持つ相手には、水や料理を提供してくれることを期待します。この場合、相手の年齢や性別は問わず、道具的な応答が求められます。
しかし、「私とそれ」の関係性の中で適応課題が生じた場合、関係性を「私とあなた」へと移行させる必要があります。その第一歩は、「こちら側」のナラティヴ（narrative）の変化です。
ナラティヴとは、物語を生み出す「解釈の枠組み」を指します。この枠組みは、立場や役割、専門性などによって形作られます。例えば、「上司とはこうあるべき」「部下とはこう振る舞うべき」といった暗黙の解釈が挙げられます。一方的なナラティヴに基づいて相手を見ると、相手が誤っているように思えることがあります。しかし、それは相手側のナラティヴから見た場合にも同様です。
対話とは、このような「ナラティヴの溝に橋を架ける」行為であると言えるでしょう。
所感
この「私とそれ」と「私とあなた」の関係性を、無理やり Team Topologies 3 における概念で解釈すると、interaction modes の X-as-a-Service と Collaboration の一部として捉えることもできるかもしれません。X-as-a-Service モデルがうまく機能するのは、「サービス境界が正しく選択され、適切に実装され、さらにサービスを提供するチームが優れたサービスマネジメントを実践している場合のみ」とされています。しかし、例えば環境の変化などによってこのモデルが機能しなくなると、組織課題に発展する可能性があります。そのような状況下では、Collaboration を通じてナラティヴの溝に橋を架けていくアプローチが有効ではないかと感じました。
また、この「ナラティヴの溝に橋を架ける」という作業は、メアリー・フォレットが対立解決の方法として提唱した 統合（Integration） にも通じるものがあるように思います。私は社内研修を通じてこの統合の概念を学びましたが、それは抑圧（domination）や妥協（compromise）のように一方が犠牲を払う解決策ではなく、対話を通じて対立を乗り越え、お互いの利益を最大化する方法です。
複数の書籍や論文で似たような事象が言及されているのは、それぞれが適応課題に直面し、それを解決するために異なる形で整理・言語化を行った結果であり、これが普遍的な解決策として共有されていることの証と言えるのではないでしょうか。
特に「私とそれ」という関係性は、複数の部門や組織をまたがる横断組織においてよく見られるように感じます。本書で述べられている通り、その関係が機能している間は問題ありませんが、機能しなくなる場面も少なくないでしょう。たとえば、従来のDevとOpsの関係性がその一例です。そして、DevOps という概念は、もしかしたらナラティヴの溝に橋を架けるアプローチを具現化した一つの形なのかもしれません。
適応課題の4タイプ
ハイライト
これら4つのタイプに共通するのは、いずれも既存の技法や個人のスキルだけでは解決できない問題であることです。さらに言えば、人と人、組織と組織の「関係性」の中で発生する問題だという点です。
1つ目の「ギャップ型」は、大切にしている「価値観」と実際の「行動」にギャップが生じるケースです。この場合、問題は（狭い意味で）合理的に発生します。そのため、この合理性の根拠を変えるように働きかけることが求められます。
2つ目の「対立型」は、互いの「コミットメント」が衝突するケースです。
3つ目の「抑圧型」は、「言いにくいことを言わない」状態です。関係性が原因で発言しづらかったり、発言するとトラブルや損失を被るリスクがある場合に発生します。たとえば、既存事業の将来性が乏しいとわかっていても撤退できない状況がこれに当てはまります。
4つ目の「回避型」は、痛みや恐れを伴う本質的な問題を避けるため、逃げたり別の行動にすり替えたりするケースです。
所感
例えば、開発組織では、これらのタイプの適応課題がどのような形で現れるかを考えてみました。
ギャップ型
技術的負債への向き合い方が例として挙げられるかと思います。多くのソフトウェアエンジニアは、将来的な開発速度や開発体験、プロダクト品質の悪化を防ぐため、技術的負債の解消を重視し、品質の高いコードベースを維持したいと考えます。一方で、顧客にできるだけ早く機能を届けることは、ビジネスの短期的な目標から見れば非常に合理的です。顧客に早く価値を届けることで評価を得て、売上を伸ばし、投資の原資を作ることも重要な目標です。このように、価値観と行動にギャップが生じる場面があるはずです。
対立型
開発組織とセキュリティ組織のコミットメントの違いが典型例です。開発チームは新機能を迅速に導入したいと考える一方、セキュリティチームはリスクを避けるために厳しいチェックプロセスを設けることがあります。例えば、開発チームが納期内のリリースを目指している一方で、セキュリティチームがセキュリティインシデントの防止を優先している場合、これらの目標の違いが対立を生む可能性がありそうです。
抑圧型
問題を指摘した人やチームが「解決の責任」を押し付けられる雰囲気があると、重要な課題が表面化しない可能性がありそうです。現在、私が所属している開発組織では横断組織が存在し、個人が挙げた課題に対して組織として動く仕組みがあるため、この種の問題が起きにくい構造を作れていると感じます。このような仕組みは、抑圧型の課題を防ぐ上で非常に有効であるように感じます。
回避型
本質的な課題を避け、短期的な解決策に頼る例が挙げられます。たとえば、設計の見直しという本質的な問題を回避し、インフラのスケールアップで対応してしまう状況です。また、サーベイ結果を受けて、本質的な課題やユーザーの真のニーズを深掘りするプロセスを回避し、表面的なHow（解決方法）に飛びついてしまうことも、この型に当てはまるように思います。
溝に橋を架けるステップ
ハイライト
- 準備：「溝に気づく」
- 観察：「溝の向こうを眺める」
- 相手の立場や状況を深く理解するための情報収集を行います。
- 相手にどんなプレッシャーがあるのか。
- 相手の責任や仕事上の関心は何か。それらが生じた背景は何か。
- 具体的には、以下のような行動を取りうると思います。
- フラットに意見交換できる人に聞いてみる。
- 数値的データを収集する。
- 部長や役員クラスの話を聞き、方針を探る。
- 自分が安全な場所にいながら相手にリスクを負わせる関係性があった可能性にも気づけます。
- 相手の立場や状況を深く理解するための情報収集を行います。
- 解釈：「溝を渡り橋を設計する」
- 観察で分かってきたことを眺めて、そこから相手のナラティブを自分なりに構成してみます。
- 相手のナラティブの中に立ってみて自分を眺めると、どう見えるのかを知ります。
- ナラティブの溝に架橋できるポイントを協力者などのリソースを交えて考えます。
- 介入：「溝に橋を架ける」
- 解釈の段階にはいって、橋の設計をし、介入する段階で初めて技術的解決が機能するようになります。
- また、この介入が次の観察への入り口となる循環的なプロセスでもあります。
所感
職種が異なる場合、その職種が大切にしている価値観や文化を知ることは有意義だと思います。ソフトウェアエンジニアの間で重視される価値観や文化には、一般的に共有されるものがいくつかあるように感じます。同様に、他の職種にもそれぞれ固有の価値観や文化が存在するのではないでしょうか。
また、この本の後半で言及されていた「ナラティブに招き入れる」という考えに関連して、「ナラティブに踏み入れる」という視点も有効かもしれません。具体的には、相手のナラティブの中に入り込み、そこから自分のナラティブを眺めるということです。
ちなみに、この本を読むまで「多能工化」というトヨタ生産方式の概念を知りませんでしたが、とても興味深いと感じました。特に、「自分よりも後工程を担当すれば、自分の工程で行ったことが後工程にどのような影響を与えるかを知ることができる」というフレーズが印象に残りました。今後どこかのタイミングで、このテーマについて詳しく読んでみたいと思います。
