ちいとぽ(チームトポロジー)と私

本も2周して、いろんな人とディスカッションしたりで一段落したので、今の理解を書き出しておこう。

目次

ちいとぽとの出会い:チームの成熟度を向上させるには?

はじめてちいとぽの概念を知ったのは、State of DevOps Report 2021でした。4 key metricsやHigh / Lowパフォーマーの分類は知っていたのですが、じゃあHighに近づくにはどうする?に悩んでいたときに、レポートを読んで「あ、これ参考になるかも!?」と思ったのでした。

  • クラウドの利用や自動化を導入するだけでは、DevOpsの成熟度Highにはなれない
  • チームのアイデンティティと明確なコミュニケーションの枠組みが重要
  • これらのモデル(※:チームトポロジー)をうまく組み込んでいる組織ほどDevOpsの成熟度がHighになっている

State of DevOps Report 2021を日本語で解説 ーTeam Topologies Model、プラットフォームが重要な要素ー | TC3株式会社

ちいとぽの理解:ちいとぽから感じたことや、活かせそうなこと

ちいとぽは、現状を表すモデリングツール

ちいとぽのモデルは、最初から何か課題を解決しよう・パターンに当てはめようとするのではなく、まずは現状をモデル化するためのツールなのかな、というのを感じました。ちょうど、UMLのような感じ。UMLも、最初から何かを当てはめようとして使うものじゃないですしね。

「速いフローを実現する」に向かって、判断する

現状をモデリングした後は、必要ならばよりよい改善の方向を考えることになります。その際、認知負荷だったり、チームタイプ・インタラクションモードなどの単語にとらわれ過ぎると、何を軸に判断していいかが迷うことに。

そういうときは、まず実現したいこと「速いフロー」に立ち戻ると話がぶれにくいなというのを、いろんな人とディスカッションしてて感じました。極端な話、十分に速いフローが実現できているなら、チームを分けたりも不要ですしね。

(まあ、通常は人数が増えたり、認知負荷が大きくなったりすると速いフローを妨げることになるので、その辺を紐解いていくことになるでしょうが)

LeSSとちいとぽのかみ合わせ

複数チームの連携といえば、LeSSもありますよね。今の現場では、LeSSの枠組みも取り入れようとしてますが、LeSSとちいとぽは思想がちょっと違うのかなと感じました。

  • LeSS:プロダクト全体思考で、プロダクト全体の全体最適からの優先順位・柔軟性を最大にするようにし、よってたかって対応できるようにする
  • ちいとぽ:個々のチームのフローを効率化にする、そのために複数のチームが必要ならばチーム・人を増やす(↓の図が典型的)

f:id:ikikko:20220320143819p:plain:w400
「Chapter3 チームファースト思考」より

どちらかしか使えないというわけではなく、併用はもちろんできます。ストリームアラインドチームは複数チームでLeSSを構成しつつ、共通インフラをプラットフォームチームに切り出してLeSSチームをインタラクションする、など。

ただ個人的には、まずはLeSSの思想でなんとかできないかを押さえておきたいなーとも思いました。ちいとぽは「大きいものを、大きいまま効率的に扱えるようにしよう」と見えるのですが、その前に「大きいものは、本当に必要なドメインにのみ注力して小さくしよう」が必要だと思ってます。LeSS(スクラム)のように、プロダクトバックログで優先順位を考えて必要なものに絞りつつ、それでも最大限の成果を発揮できることに頭を使いたいかなー。

イネイブリングチームで、チームに新しいスキルの習得を加速

今までは、新しい技術を導入する際は、チーム自身でその能力を獲得してほしいと思って動いてました。ただ、現実的には認知負荷などの問題で、ストリームの業務をこなしながら新しいことを学ぶのは難しいこともありそうだなと感じていました。

そういうときに、イネイブリングチームでストリームアラインドチームの外から技術支援するのは、一つの手としてありそう。例えば、以前自動テストの環境を導入したときは、今思い返すとイネイブリングチーム的な動きをしてたのかなーとも言えますし。

また、現在はその延長線上として、今までの自動テストをよりよい形で見直していこうという動きがストリームアラインドチームから出てきています。そのこと自体はすごくいいことなのですが、チームの中だけだとなかなかうまく進められていない。そこで、ちょっとチーム外から有識者がイネイブリングチーム的に支援することによって、チームのフローが加速するのであれば、よさそうかなと感じてます。

ちいとぽを深める:他の実践者とのディスカッション

書籍を読めば各用語の知識は分かるけど、どう実践するかがいまいちつかめない。ということで、各実践者とディスカッションしながら、理解や活用イメージを深めていきました。

Chatwork with daiksy さん

Scrum@Scaleを推し進めているchatworkさん。Scrum@Scaleの各チーム間の目的やインタラクションの設計に、ちいとぽが相性いいらしいと教えてもらった。ほーなるほど。

Retty with TSUNEMATSU さん

稲野さんチームトポロジーを用いたRettyプロダクト開発体制の解説 #ちいとぽ - Retty Tech Blogを肴にディスカッションするという場に、誘ってもらいました。

「ちいとぽは、モデリングツール」は、このディスカッション中で出た話題。

その他、「逆コンウェイの法則はあるけど、組織図を先に変え過ぎると失敗したときに大変。なので、非公式に変えてみてよさそうなら組織図に反映させるのがよさそう」みたいな話題も。

atama plus with かわきん さん

またまた稲野さんに、atama plusにおけるチームトポロジーとは?(読書会の感想&考察)|かわきん(ちゃんかわ)/atama plus スクラムマスター|noteを肴にディスカッションする場を設定してもらいました。

『LeSSのようにあえて分業しない方法』と『チームトポロジーによる分業の方法』

は、薄々感じてたことを、いい感じに言語化してもらって「それだ!」となりました。

その他、「精神と時の部屋があれば、中長期的にScrum / LeSSでやっていけるけど、現実時間として難しいこともある。その場合に、もう少し現実的に分業などをやりやすくするための一つの方法がちいとぽ」などなど。

Timee @ちいとぽStudy

つい先日開催された、ちいとぽStudyでの事例。節理面をどう切るかが参考になりました。Phase3のようにステークホルダーで切るのは自分も考えてたけど、Phase4のように業務で切るのはなるほど。自分の現場にも当てはめて考えてみたい。

「My Top Ten Worst Scrum Anti-Patterns」を140字で勝手に要約

ほぼTwitterにぶらさげた内容が全てですが、Twitterだけだと残りづらいかと思うので、ブログ化しておきます。

推しアンチパターンの投票結果がちょっと分かりづらいですが、「#1:プロダクトビジョン・プロダクトゴールがない」が5票で最多得票でした。ほかは、3票ぐらいで結構接戦。

なお、僕の推しアンチパターンも、「#1」と「#4:教条主義」。#4は、「あーこうなりがちなので自戒しておかないと・・・」と、訳しながらぐさぐさ刺されてました。

スクラムマスターとして、はじめましてのチームに入ったときの過ごし方

前回のブログの通り、GW明けの5/6から社会復帰しています。そこで、1週間ちょっと経ったわけですが、こんな感じで最初の1週間を過ごしていったよというのを軽くまとめ・紹介します。

なお、前提は以下の通り。

  • 週1,2でスクラムイベントだけとかではなく、スクラムマスターとしてチームにフルタイムで入る
  • アジャイルコーチの知り合いが一人いた程度で、他の人ははじめましてな状態

既存のMTGには、まずは色々参加

  • どういう内容を話してるかや進め方を感じ取る
  • その際にも、いきなり「これがいいよ」「ここはちょっと変えたほうがよさそう」とかは押し付けないように
    • そういうやり方をしている背景・経緯があるはずなので
    • やるにしても、「こういうやり方やってるチームもありましたよ」という情報提供な感じ

開発者がコミュニケーションしてる場にも積極的に参加する

  • 開発的な成果を出すというより、関係の質を作るところや実際の進め方を肌体感するのを重視
    • モブしてたので、乗り込む場があったのはありがたかった
  • 具体的な行動は
    • 分からなくても発言する(「分からないので、教えて下さい」メソッド)
    • ローカルに開発環境を1mmも整えてなくてもコード修正できる(そう、Visual Studio Live Shareならね)
    • 実装のことはついていけなくても、少し引いて貢献できることも多い(テスター的な視点で受け入れテストを整理するとか、不具合なら再現方法・期待する振る舞い・実際の結果を整理するとか)
    • コマンドの使い方などの基礎的なところは、自分の経験から話せることも多いよね

プロダクトオーナーやアジャイルコーチ、リーダー的な人たちとも会話していく

  • この場では、(開発者の場よりも)自分が感じたことや考えも出していく
  • とはいえ、背景分かってないこともあるので、「新鮮な目で見たときに、〇〇のように見えました」という `I message` なスタンスで

言葉だけでなく、目に見えるものを見せる

  • 最初だから観察が多めな時期ではあったけれども、さくっとやれそうなのは提案もしていった
    • お作法が分からないところもあったけど、基本は「許可を求めるな、謝罪せよ(超意訳)」の精神
    • 特に新しい取り組みの場合、言葉だけで説明してもピンとこないので、見える形にするのは大事
  • たとえば、こんな取り組み
    • 「朝会で話にあがってたタスクを、カンバンに優先順に登録してみたので、これ見ながら話しませんか?」
    • 「PBIのステータスを更新しやすいように、各ステータスの定義や更新タイミングを検討して明記してみたけど、これで現状と合ってます?」とかとか


こういうのを、入社2日目からやっていってました。メンバーと同じリズムでMTG参加含めて仕事してた&既存のメンバーと違って新しいインプットも多かったので、だいぶ疲れました。

ただ、時間効率という意味では、ちょっぱやだったんじゃないかなと思ってます。1週間ちょっとで進め方をある程度実体験できたし、一緒にモブしてるチームをはじめとした、みんなとの関係性もできてきたと思う。

まあ、スタートダッシュを切れたのはよかったのですが、疲れたのは疲れたし、ちょっと持続可能ではなさげ。ここからは、少しペースを緩めつつ、スクラムマスター的な視点やアプローチを考える時間を取っていこうかなと思ってます。

というのを、このポスト見てちょうど色々考えたので、今の自分の状況をふりかえってまとめてみました。

転職しました(11年ぶり2回目)

前職では

2021年4月まで、約10年以上もの間、ヌーラボにお世話になりました。

新卒で入ったSIerではSAPやってて、ヌーラボに入った当初はWeb業界のスキルなどがほぼほぼない状態でした。ほんとに「駄目だこいつ、早く何とかしないと…」レベルでしたが、受託開発やら自社サービスのBacklogの開発・運用をやっていく中で、エンジニアとして少しずつ成長していけました。

そんな中、幸運にも自分の興味志向と本業をうまくマッチさせることができました。当初から「一緒に働いているチームの役に立ちたい!」という思いのもと、Backlogをはじめとした開発をサポートするツール群に興味があったのですが、それの延長線上でJenkinsをはじめとしたCI/CD周り、さらにはツールだけにとどまらないチーム・プロセス周りの改善としてアジャイルスクラムなどにのめり込んでいきました。プライベート活動でも動くことができましたし、その成果を社内にも還元できたかなと思います。

(もちろん、うまくできたなと思うこともあった反面、力及ばずだったこともいっぱいあったなという思い出です)

次の会社では

5月から、クリエーションラインで働きます。クリエーションラインでは、エンジニアの知識・スキルを基盤としながらも、スクラムマスター・アジャイルコーチとして、アジャイルのレフトウィング:協調でゴールに向かう「チーム環境」の整備に携わっていければと思っています。

Joyを突き詰める旅へ

クリエーションラインを選んだ理由はいくつかありますが、理由の一つは企業理念にJoyが掲げられていること。以前の感想ブログの通り、Joy, Incがすごい好きなのですが、改めて見直してみて一番感銘を受けたところを抜粋。

メンローでの喜びの根幹にあるものは、僕たちが作ったソフトウェアを人が使ってくれ、うれしい体験だと感じてくれることだ。目標はいつも変わらない。マニュアルも講習会も使い方メモもいらない、使いやすいソフトウェアをデザインして作ることだ。まったく経験をしたことがないような難しい業務領域においても、僕たちはそれを成し遂げてきた。


人に奉仕しない会社は、この世に存在できない。会社とは、生み出すプロダクトやサービスを使ってくれる人たちの要求に応えるために存在するものだ。喜びについてこんなふうに考えれば、全員が価値ある目標に集中して取り組める。ソフトウェアを届けるのは、難しいことだ。コーディングは緻密な作業だし、正しいデザインに至るまでには忍耐と粘り強い努力が必要になる。それは本当に大変な作業で、いつもうまいこと完成できるとは限らない。僕たちもイライラするし、我慢強いわけでもないし、予想外の問題だって起こる。しかし、僕たちの喜びもまた、そうした大変な作業の成果として得られるものなんだ。だから、僕たちがデザインし作り上げるソフトウェアによって、人の生活に喜びを与えたい。

そうそう、そうなんだよねー。大変なことも多いけど、それがユーザーの生活をよくしたときに喜びを感じる。合わせて、自分たちだけ喜びに満ち溢れてるのではなく、使ってくれるユーザーとそのユーザーの生活に喜びを与えるのがいい。

前職とは違った形で、自分なりの、そして企業としてユーザーへのJoyを突き詰めていく旅に出ます。今後をご期待ください!

組織パターンを読みました

有給消化期間中で、この機会に鬼のように積ん読消化していきたい。その一環として、前から気になってたけど読めてなかった、組織パターンをざっと目を通しました。

ついでに、読書のやり方も色々試行錯誤してる途中。今回は、読むスピードを優先して、メモは自分だけで分かるレベルでさくっと取っていく方針で。その中でも、いくつか全体感想的なところだけを出しておいて、なにかの話のネタやこの後読む人の参考になれば程度。

www.amazon.co.jp



この本から得たいこと

パターンをさっと取り出して、自分の意見を補強するため。やっぱり、本とかでまとまったものを引用すると、説得力が違うので。

拠点をまたいだ組織系のパターンが、今はやっぱり大きな関心事の一つかな。その辺を補強できるものがあれば。

感想・得たもの

1回じゃさっと取り出して活用するまではならなさそうなので、2回目以降の読み直しにかけたい。

巻末のパトレットの方がわかりやすいし、まとまってるので、こっちを覚えるようにしよう。

ところどころ、スクラムでイメージできるものがあった。「ワークキュー(≒プロダクトバックログ)」だったり「非公式の労働計画(≒スプリントバックログ)」だったり。

わかりやすく、明日からでも使えそうなやつ。

  • 4.1.26 手を止めて始めた作業を中断するな
  • 4.2.5 ソロ・バイオリニスト
  • 拠点をまたいだ組織系のパターン
    • 5.1.8 組織は拠点配置に従う
    • 5.1.10 離れて作業する前の顔合わせ
    • 「拠点離れているときでも、なんとかなる条件」は、現実解として分かりやすい

1. すべての拠点を合計しても、プロジェクトの開発者の数が少ない
2. ほとんどのコミュニケーションが、Eメール(広く分散され、非同期のコミュニケーション)のようなもので行われている。その場合、コミュニケーションの主な手段が立ち話である場合に比べて、より多くの人が会話の輪に加われる
3. 関わる人が一定期間一緒にいて、お互いを知っていると感じている(キックオフミーティングのように短い期間でもよい。[ 離れて作業する前の顔合わせ( 5.1.10)]も参照)
4. 「不必要」な移動のせいでメンバーが疲れてしまうことのない程度に、必要に応じて喜んで移動する人たちである。状況によっては[拠点間に分かれた作業を完了させることが]プロジェクトの性質上、不可能である。そのため、拠点が離れているという問題に対処する方法が必要だ

RACIチャートで役割 / 責任をまとめるのを推し進めていたことがあったんだけど、そのときに「5.1 組織のスタイルのためのパターン言語」を知っておくと、もう少し自信を持って進められたかもしんない。

「5.1.7 コンウェイの法則」を、この機会にちゃんと学べた。

上の方に位置されてるパターンが、より最初に考えるところかな。特に、どのパターン言語でも「信頼で結ばれた共同体」から始まってるのが、興味深い。