チームトポロジー Vol. 3 「向上心のないメンバーをどう評価する？」 吉羽 龍太郎 × 亀田 彗

1部は「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」共訳者の吉羽さんがAmazonレビュー4.5 と高評価の本書を「30分で分かった気になるチームトポロジー」と題し紹介しています。

2部は「組織をチームトポロジーで振り返ると、よりよい未来が見えてくる」と題し、株式会社タイミー 執行役員CTOの亀田さんがチームトポロジーを組織に適用して良かったこと、発生した課題、今後組織をスケールさせていく計画をタイミーの事例として紹介しています。

3部は「Team Topologies Study：チームトポロジーを成功させる実践方法の探求」イベント内のQ&Aの様子をお届けします。

チームトポロジーに興味のある方は必見です。

QAセッション

Q1. 期待に届かないメンバーや向上心のないメンバーをどのように評価すればよい？

「あいつはやる気がない」と断定するのは危ない

吉羽：これについてはチームトポロジーのなかで明言していません。チームトポロジーの誕生背景を振り返ると2001年にアジャイルソフトウェア開発宣言があり、その後 DevOps が生まれ、そこから組織構造に踏み込んでチームトポロジーが生まれました。

つまり、チームトポロジーはアジャイルの思想の影響を強く受けています。アジャイルソフトウェア開発宣言の中身を見ると「やる気のある人たちを集めてチームを作り、その人たちが活躍できる環境を作ってサポートしなさい」と書いてあるので、少なくともモチベーションがあることを前提にしています。

ただし、本当にモチベーションがないのか？本当にスキル不足なのか？などを検証しない間に「あいつはやる気がない」と断定してしまうのは危ない話です。

仮にやる気のないように見える人がいたとしても、例えば過去にチームのなかでいろいろ提案したものの全部否定されてしまい、言うだけムダだと考えて守りに入っているケースなどいろいろな事情やコンテキストがあると思います。そもそも本当にやる気のない人はあまりいないと思うので、事実をとらえることから始めるとよいと考えます。

今スキルがなくても学習していくなかで身に付く

スキルの問題ですが、技術はどんどん進歩していくので、継続的な学習が必要になります。これはチームとして時間を取らないといけない問題です。仮に今スキルがなくても、モチベーションがあればチームで学習していくなかで身に付くものだと考えます。

モデレーター：タイミーさんの場合はモチベーションの高い方が多い組織だと思いますが、一方で吉羽さんのお話にもあったとおり技術は日々進歩しています。アジャイルの文脈においても重要とされている継続的学習に関する実践、期待に届かないメンバーを出さないために取り組まれていることはありますか？

期待した側が間違っている可能性が高いのでは？

亀田：優しいパスをありがとうございます（笑）

どの企業でも期待に届かない人がいる、自分の期待に沿わない人がいるという話は良く聞きます。大きな企業から、シード期のベンチャーでも近しいことを言っているのを聞いたことがあるので環境の問題ではなく、普遍的なな問題として発生するものだと思います。

そのなかで私が重視しているのが期待の大きさとそれに応えるケイパビリティの組み合わせです。そもそも開発は認知負荷が高く、それらを積み上げた先にものづくりがある様な世界です。仮に期待から外れてしまった場合、どちらかといえば期待した側が間違っている可能性が高いのではないでしょうか。

チームに見合った認知負荷に落としたり、それが難しいのであれば、お金をかけて人をアロケーションしていくなどの取り組みがマネジメント側に求められると思います。

とはいえ、タイミーではスキルを向上させるための特別な取り組みはあまりおこなっておらず、OJTなどが中心です。なので生存バイアス盛り盛りな回答になっていますが、今後は継続的学習を支える環境の整備もしていきたいです。

Q2. 採用ハードルの問題で仕方なく開発・運用を分ける会社もありますが、チーム拡大にあたりネガティブになる要素は？

変化に弱い、フロー遅延、センシングの部分が抜け落ちるためリスク大

亀田：私のなかで言語化している最もネガティブな要素は「変化に弱くなること」です。

開発と運用を分けた際に運用側がプラットフォームチームのように振る舞い、開発側がX-as-a-Serviceモードで「運用」を利用する関係性になっていることが多いと思います。

しかし、この状態で変化を生み出すのは難しいと思います。加えて、開発と運用のプロセスは一連のキレイなプロセスになっています。課題の探索からリリースするまでの流れのなかで、何処か一つが遅ければそこがボトルネック化します。

変化やスケールを期待しているのであれば、開発と運用をくっつけたほうがボトルネックの探索が動的におこなえて、結果的にリスクが軽減されると思います。

例えば確定申告のようにフローが決まっていて、いつ何が発生するかが変化しないシステムを作る場合は開発と運用がわかれていても問題ないかもしれません。しかし、タイミーのように新しいビジネスを探索しつつ、既存のビジネスもスケールしている組織で開発と運用を分けるのはリスクが大きいと思います。

吉羽：基本的には亀田さんと同意見です。開発と運用をわけることで発生するネガティブなことの1つは、チームを分断するとフローが遅くなってしまうこと。

もう1つはセンシングの部分が抜け落ちてしまうことです。運用や実環境からのフィードバックはプロダクトに反映していく必要がありますが、チームがわかれていると戻りのパスがないので変化に対応できなくなってしまいます。

Q3. 逆コンウェイが採用しやすい、採用しにくいアーキテクチャは？

逆コンウェイ戦略で組織構造を作っていくことは、アーキテクチャがすでに既に構築されていること、もしくは柔軟に変更できることが前提だと思います。 モノリシックなアーキテクチャではこの戦略は取りにくいと考えています。逆コンウェイが採用しやすいアーキテクチャ、採用しにくいアーキテクチャなどはありますか？

ゆっくり切り離しながら取り組むならスタート地点がモノリスでも問題ないのかな

吉羽：同じコードを複数のチームが触ること自体がしんどいので、サービス分割とチーム分割はある程度セットになります。ただそれがモノリスだとまったくできないかというと、そうではないと思います。

そもそもモノリスを分割したいタイミングは、1チームで運用するには認知負荷が高過ぎる状況だったり、変更のスピードが間に合わなかったりする状況なので、部分的に切り出すアプローチが多くなります。

例えば、認証や課金のところを切り出したり、サービスレベルの違うところを切り出しましょうというタイミングで、そのチームをもう1つのストリームアラインドチームとして切り出す形になると思います。

「組織変更はゆっくりやれ」と言いましたが、この話でモノリスをいきなりたくさんのマイクロサービスに分割するのは無理です。なので、ゆっくり切り離しながら取り組むのですが、であればスタート地点がモノリスでも問題ないと思います。

オライリーから『モノリスからマイクロサービスへ』という本が出てるのでそちらを参考にしてみるのもよいのではないでしょうか。

亀田：タイミーも現在はモノリスな Railsアプリケーションで稼働していますが、ゆくゆくは認知負荷を下げるためにも分割をしたいです。分割方法についてはマイクロサービスに限らず、モジューラーモノリスのような考え方もありますが、基本的な考え方は同じです。参照し辛くすることで認知負荷を下げるアプローチだと認識しています。

その際に逆コンウェイがなぜ、よいかというとその境界面の探索を全員でおこなえるからです。ちゃんとフィードバックサイクルを回すことが前提になりますが、開発者ひとりひとりが書くコードをシグナルにして境界面を探索することができます。運用や DevOps の観点から見てもよい境界面を見つけることが可能です。

頭のよい人が「ここで切ろう」といって切ったものよりも自分たちで探索を続けていき見えた隙間で切るほうがチームにとって大事だと思います。

ただ、やってみると求められる技術力も高いと感じます。今のタイミーではまだよい境界面を見つけるのが難しく、実際に隙間に落ちたものが放置され、Ruby のバージョンが上がらないこともありました。なので、こうしたことをなくすためにも継続的に技術力を上げていくことへの投資がセットになってくると思います。

Q4. タイミーの将来のチーム構成（チームトポロジー）はどのようなメンバーで考えたのでしょうか？

亀田：基点となる部分は私が考えました。現在はこのアイデアを全体で検証していくフェーズを頑張っているところです。

例えばチームを切り、プロダクトマネージャーに任せるとなった時にちゃんとプロダクトゴールが作れるか否か、自律的に成果を出していくチームとなるためにプロダクトの成果は定義できるのかなどもシグナルの1つになると思います。

コンセプト自体にそこまでの価値はないので、どんどんデバッグして組織として磨きをかけています。最初のアイデアこそ私が考えましたが、すでに原型からは変化しており、より不確実性が低い形にブラッシュアップされてきています。考え抜いて、バンっと最終形で組織に落とすよりも30%ぐらいでアウトプットして皆で検証していくのがよいと考えています。

これがうまくいくかは1年後のタイミーを見て貰えばよいのかなと思います。うまくいってなかったら「あー、うまくいかなかったんだなあ」って笑ってもらえればと思います（笑）

Q5. ストリームアラインドチーム以外のチームを組成するタイミングはどう見極めるのが適当ですか？

認知負荷をベースに考えていくのがベスト

吉羽：書籍のなかにはっきりと書いてあるわけではありません。書籍のなかでは「認知負荷」が大きなキーワードになっていますが、認知負荷が高くなってきてデリバリーが遅くなってきたタイミングがチームを変えていくタイミングだと思います。

例えば、スタートアップでも最初、数人で Rails でスタートして、組織が大きくなって10人、20人となってくると今までどおりのスピードにならないタイミングが来ます。具体的にいつにするかは難しいですが、今までよりスピードが遅くなったら考え始めるタイミングではないでしょうか。

あと、ストリームアラインドチームの次に作られるチームはプラットフォームチームであることが多いです。やはりインフラや共通基盤といった部分はドメイン境界が明確で、「切り離してサービスとして使います」といってもわかりやすいので切り離しがしやすい傾向があります。

亀田：私も認知負荷をベースに考えていくのがよいと思います。基本的に組織は理想的ではない組織の状態からスタートすることが多いでしょう。タイミーも最初は未経験の社員と数ヶ月コミットを約束いただいた業務委託の方という理想からはほど遠い状態からスタートしました。

タイミーでも最初のワンチームの時代からワーカーのみが影響範囲になっていたモバイルアプリチームを切り出しました。この変更はバリューストリームに対してはうまく回りませんでしたが、結果として良かった点もあったと思います。

節理面が技術だったので技術の習熟が進みました。そこまで Viewアーキテクチャに詳しくないし、興味もなかったような人がキチンとモジュール分割をして、デザインパターンの話をしているぐらいには成熟が進みました。

認知負荷の軽減を目指してチームを分割をするのですが、切ったら切ったでその観点での成熟が進みます。技術で切れば技術の成熟が進みますし、ステークホルダーで切れば各チームのステークホルダーへの理解が勝手に進んでいきます。なので、ストリームアラインドなのかを深く考えずに切るのも1つの手段だと思います。

吉羽：今の亀田さんの話は書籍のなかでも触れられています。スキルの獲得は認知負荷のなかでいうと課題内在性負荷に分類されています。要は実現しようとしていることに対する手段を身につけるのにそもそも時間がかかる場合、それを身につけると全体としての認知負荷は下がります。なので、絶対間違っている切り口があるわけではなく、やった結果としてある部分の認知負荷は軽減されると思います。

先ほどお話されていた「そもそも技術を高めていかないとダメだよね」という話はまさにそのとおりで、結局それがないと組織構造をいじっても何も変わらないとなってしまうのでよい話だと思いました。

亀田：ありがとうございます。1、2年前の私は理想っぽい形にチームを無理矢理当てはめようとしていたのですが結果、うまくいかず、それがフィードバックになっているわけなのですが、今はゆっくりと変えていく必要があると思っています。

モデレーター：ここまで亀田さんのお話をお聞きして、組織に向き合って試行錯誤されている印象が強くあります。しかし、組織のことになるとソフトランディングしたり、小さく失敗することが難しい印象もあります。実際に亀田さんもいろいろなご失敗を経験されてきてるのではないかと思いますが、やはり小さく失敗するにはゆっくりと少しずつ変えていくことに尽きるのでしょうか？

吉羽：基本原則はやはり「小さく」です。これはプロダクトも組織も同様です。そもそも正解がわからないものなので失敗したときに簡単にロールバックできるようにするべきです。結局は実験のようなもので、仮説検証なので5つやってうまくいくのは1、2個、それでも十分。といった割り切りが必要ではないでしょうか？

基調講演の冒頭でも話しましたが、世の中は変化のスピードが早くて、不確実性も高い状態で正解がわからない状況なので、むしろ確実性を求めて時間をかけるほうがマイナスになります。失敗してもよいのではないでしょうか。戻せばよいだけなので。

亀田：吉羽さんの仰るとおりだと思います。私がチームを変えていくなかで学んだことがあります。例えばサーバー側のチームで Four Keys（リードタイム、デプロイ頻度、変更失敗率、復元時間）を大事にしていく際はデプロイの頻度を上げることも大事ですが、監視を強化して何かあった際にきづけるようにしておくこととセットになります。それをしないままに変更を加えていくことはリスクが大きいことです。

人って5xxを出さないんですよ。突然レスポンスが返ってこなくなることもあります。

それに思っていることをそのまま言わないこともありますし、どうしてもメンバーは直属の上司に期待される振る舞いをするように動くので、レポートラインをうまく設計しないとセンシングの妨げになることが多いです。

チームを前進的に変えていくことと、人に向き合ってシグナルを逃さない体制を作ることをセットで考えることが重要です。タイミーもこれがうまくできずに創業時から在籍していて、とても成長したエンジニアが1名辞めてしまうこともありました。そこから学んでエンジニアマネジメントの組織を立てて、マネジメント専任でおこなうようにしました。

チームの成果と切り離し、プロダクトの成果と利害関係がない人と向き合う人としてエンジニアリングマネージャーを置いています。これによってメンバーがアラートを上げやすい体制にしています。やはり組織を小さく変更し続けることと、組織を検査し続けることはセットであるべきだと思います。

モデレーター：人が5xxを出さないというのはなかなかなパワーワードでしたね。マネジメントをやる人は心に残したほうがよい言葉なのではないかと思いました。

吉羽：知らないうちにいなくなってた404とかのパターンもありますよね（笑）

一同：（笑）

Q6. チームの認知負荷を下げるためにプロダクトの（相対的に価値の低い）機能は捨てる必要性がありますか？

基本的に使っていない価値の低いものがとても多い。捨ててOK

吉羽：これは「捨てろ」で大丈夫です。本当に捨ててください。

いろいろな調査があるのですが、2000年頃にスタンリッシュがおこなった調査では64%の機能はほとんど、もしくはまったく使っていないとされています。

他に2019年頃にも、昨年邦訳が出版された『プロダクト・レッド・オーガニゼーション』の著者トッド・オルソンがCEOを務めるPendo社がおこなった調査では、80%の機能が使われていないとされています。

基本的に使っていない価値の低いものがとても多いわけです。これを残しておくと保守コストも上がり、ボリュームが増えることで認知負荷も高くなるので削除することは非常に重要です。

私がスクラムのトレーニングやコーチングをおこなう際も「機能を作るプロダクトバックログアイテムだけでなく、機能を削除するプロダクトバックログアイテムも入れなさい」と話します。

これを進めるには測定するしかないので、測定する仕かけを作り、測定した事実をもとに進めるのがよいのではないでしょうか。

モデレーター：一方で全体から見たプロダクトの景色とその機能に携わる人たちが見ている局所的な景色は異なるのではないかと思います。全体から見れば使われてなくても、自分のお客さんが使っているので、なくなったら困るという抵抗が発生することもよくあると思います。

タイミーさんでもワーカーとクライアント側の違いなどもあり、こういうことが起こりえると思いますが、機能を削除するためにおこなっている具体的な取り組みなどはありますでしょうか？

亀田：機能要件にない部分について捨てることは結構やってきています。過去にマイクロサービス化に失敗したことがあるのですが、その際に作った相互に循環参照するマイクロサービスは違う言語で作られていたこともあり、認知負荷が高い領域になっていました。そこを1年掛かりで捨ててきました。

あとは運用が回っていない機能などもその対象ですが、幸いタイミーではプロダクトマネジメントもエンジニアリングの経験があるメンバーが中心になっておこなっているので、システムに負荷が強い形で機能追加をおこなう頻度は低いです。

そのなかで捨てることをどうとらえるかですが、捨てない限りは捨てるコストはわからないと思っています。捨てることは本当に大変で、タイミーもマイクロサービスをモノリスに戻すのに手順を踏んで1年ぐらいかけています。ただ、これはぜひやるべきで作りたい人たちに捨てることの大変さを理解してもらう材料になるからです。

その捨てるコストを踏まえたうえでプロダクトに必要なものを議論できるようになるとよいと思います。身をもって体感して貰うという意味では過激派なのですが（笑）

吉羽：弊社の同僚にも過激派が1名いるのですが、その人はフィーチャーフラグで強制的に機能を無効にしてクレームが来なければ捨てればよい、という若干乱暴なやり方を提唱しています。

亀田：いいですね、それ（笑）

捨てることの重要性をどう伝えるか？

モデレーター：お二人はエンジニアリングのバックグラウンドをお持ちですが、特に亀田さんはCTOなのでエンジニアリングのバックグラウンドを持たない経営者とのコミュニケーション機会も多いと思います。

一般的に開発に対するナレッジがないビジネスサイドの人が捨てるという話を聞いたときの自然な反応として「折角、作ったのにもったいないじゃん」となるケースも出てくると思います。

亀田さんがエンジニアじゃない人に対して捨てることの重要性を伝える際に工夫されていることはありますか？

亀田：良く伝えていることはエンジニアリングは曖昧さを許容しないのでAという機能を追加したあとにBという機能を追加する場合はAモードのときとBモードのときの組み合わせをすべて考慮しないといけないので2倍のコードを書かないといけないと話しています。

あと、実体験としてタイミーの経営の時間軸が変わってきたタイミングで、このあたりの話がスムーズになりました。長い時間軸で経営が遠くにピンを立てることは経営としても大事なので、最優先でやるべきことだと思います。

こうすることでエンジニアリング的にも場当たりな積み上げ的ではない目標を見据えた議論でよいコンセンサスが取れるようになります。なので、遠くに目標をおいて皆で合意することと、1行のコードのために将来1000行で済むことが2000行のコードを書かないといけなくなるかもしれないなど、機能の複雑性の説明をすることの2点が大事なのではないでしょうか。

偉そうに言ってますが実際には全然伝わらないので最終的には根気強く繰り返し説明する手段しか残されていない部分もあります（笑）

実際に要望を受けて、ちょっと不安を抱えつつ、そのまま作ってしまった機能もあります。そしてことごとく後悔しています。そういう機能に限って2年後ぐらいに障害を起こしたりするので（苦笑）

「あー、あのときとめておけばよかったなぁ」と思うものがいろいろな領域に散らばっているので皆さんには同じ後悔をして欲しくないですね。

モデレーター：吉羽さんにはアジャイルコーチという肩書きもあります。アジャイルとなるとステークホルダー全員がエンジニアというわけではないので、こうしたコミュニケーションの部分にも知見をお持ちかと思いますが、アドバイスなどありますか？

吉羽：基本的には亀田さんの仰った話に尽きると思います。ただし、捨てたいという話をするときに捨てるメリットや捨てないデメリットの説明責任は捨てたい側にあります。

ある日勝手に機能が消えていたとなるとハレーションが起きてしまう可能性もありますので、プロダクトオーナーやプロダクトマネージャーが常日頃からステークホルダーとコミュニケーションを取り、説明していくことが大事ですね。

Q7. プラットフォームチームの立場だと捨てるのが難しいです。（ひたすらにコラボレーションモード）コツはありますか？

「インフラを切り離す」「インフラをサービス化する」

吉羽：プラットフォームが一番簡単に実行できると思います。先ほどの話にもあった「インフラを切り離す」や「インフラをサービス化する」などです。

今だとコンテナもあり、インフラレイヤーの抽象化もしやすいので、寧ろ事例は多い領域で一般的とも思います。仮にプラットフォーム側の立場で捨てるのが難しいとすると、まだプラットフォームの定義が終わっておらず、コラボレーションモードで X-as-a-Service のインタラクションモードになってないのでしょう。

初期の組織や会社としてどのようなプラットフォームが必要なのか？という段階だと試行錯誤が必要なので、その間はどうしても不安定になってしまうと思います。ただ、ある程度インターフェースが定まってくると捨てられないものはなく、インターフェースさえ維持していればそのAPIが一度も呼ばれなかったら捨てればよいだけの話になります。

それこそAPIをバージョニングして「新しいバージョンを出すので古いのは半年以内にクローズしてください」のような Amazon流のやり方でも消せると思います。APIになってしまえば比較的捨てやすいです。

亀田：プラットフォームチームの話に関しては吉羽さんも仰っていたようにインターフェース化しやすいものがプラットフォームチームになりやすいので代替品を当て込むことは難しくないと思います。

質問者の意図をエスパーするとプラットフォームチームが握っているような技術スタックを捨てることが難しいという話なのかなと推測します。

例えば「 kubernetes捨てましょう」や、「DB は AWS Aurora 使ってるけど GCPのCloud SQL に切り替えたいです」などは実際、無理です。いかにビジネスが大きくなっても一番最初に選んだ技術スタックやプラットフォーム的なものにはずっと向き合い続ける必要があると思っていますが、質問者の意図としてはそうした含みもあるのかなと思います。

吉羽：なるほど。本の中ではそれをさらにラップして抽象化しようというプラットフォームラッパーを作り隠蔽しておいてプラットフォームのなかは再構築できるようにしておきましょうという話はあります。

ただ、Aurora 触っているのか RDS 触っているのか、はたまた Azure なのかみたいなことを完全に隠蔽するのは不可能なのでなんらかの苦労はどうしてもあるでしょうね。

---