tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

チームトポロジーを読んで考えたこと

書籍 開発プロセス 組織 Team Topologies

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計

Amazon

2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 が発売になります。 本書のレビューに参加させていただき、翻訳者の皆様から一足先に書籍をいただきました。 レビュー時は「なかなか難しいな…」と思っていましたが、翻訳者の皆様の努力とカラー装丁の効果か、読みやすい本に仕上がっております。

チームトポロジーとはどんな本か

翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照するのが良いかと思います。

チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。

自分の言葉で話すと「ソフトウェア開発体制」の定石を扱った本かなと思います。パターンランゲージとかが近いのかもしれません。 チームトポロジーの知見を踏まえつつ、状況に応じた開発体制のあり方を議論し見直していく。うまくいく状態を見いだせてから組織図に反映していく。本書とはそんな付き合い方が良いのではないかなと思います。

"ソフトウェア開発はこうしたらうまくいくんじゃないかな?"という経験や理論が体系化されている

「フロー(デリバリー、バリューストリームとか)を最大化する組織を目指す」「チームを基本単位として長く存続させる」「コミュニケーションパスを整理する」といった、ソフトウェア開発をうまくやるための知識が幅広く紹介・解説されており、関連する書籍や一次情報へのポインタもまとめられています。「サービスが成長し、人も増えて来て組織のあり方を見直したい」というのは"あるある"のよく聞く悩みですが、本書はそんな悩める人が手に取り読み、共通の知識・用語を使って議論を始める土台とするのにちょうど良いと思います。

自分は開発部門のマネージャーとしてチーム編成を見直すことが時々ありますが、チームにどんなコミュニケーションを取ることを期待しているか説明することができていなかったなと本書を読んで感じました。本書で説明されている3つのインタラクションモードは誤解なく伝えることができそうで、業務でも取り入れようと考えています。

逆コンウェイ戦略という用語の難しさ

本書のベースにはコンウェイの法則と逆コンウェイ戦略があります。

先に引用したryuzeeさんの説明も「チーム構造と組織構造を進化させて」とあるので、変えていくこと前提だと思うのですが、「目指すソフトウェアアーキテクチャの正解があって、それに合うように開発体制を作るんだ」と考えている人が一定割合いるんじゃないかなと感じることがあります。本書はそんなこと書いてないんですが、斜め読みして誤解する人が増えると嫌だなーとか用語が出てくるたびに頭をよぎります。

"ドメインの知識はあっても望ましいサービス責務が見えていない"は割とあるケースだと思っています。 ストリームアラインドチームのコラボレーションを促し、チームの責務を意図的に広く・曖昧にして議論を促すと良いのかなーとか考えたりするんですけど、逆コンウェイ戦略かと言われると違う気がしています。「脱コンウェイ戦略」とかなのかな?

ハブやコミュニティをどう表現するか

組織のスケーリングを扱った書籍だとコミュニケーションのハブとなる人材や、ノウハウマネージャーを置いたりして、コミュニケーションパスを短くするアイデアがよく紹介されます。Spotifyモデルのギルドのように職能や目的別のコミュニティを作るというやり方もありますが、これらはチームトポロジーではどう表現するとよいのでしょう。

仮想的なイネーブリングチームがあって、他チームをファシリテートで導いている気もするし、チームの一部メンバーがコラボレーションしているとも言える気がします。

ソフトウェア開発以外の組織体制はどうしていくといいんだろう?

サービスはソフトウェア開発だけで成立しないので、営業や企画など他部門を交えてフローを最大化していく必要があり、開発組織と合わせて進化させていく必要があると思います。チームトポロジーの考え方は使えるような気がするんですが、本書はソフトウェア開発に絞った話なんですよね。

チームトポロジーの狙いはあくまで明快なパターンの提供だとすると、もう少し具体化したルールを定義することで「アジャイルはソフトウェア開発にしか適用できないが、スクラムはソフトウェア開発以外にもで起用できる」ような状態にできるような・・・できないような・・・

他社の事例も聞きたい

読んで終わりにするのではなく、自社の状況を図示して整理し、共通の用語を使って議論できることにチームトポロジーの価値があると思っています。自社の開発体制を描いたものが手元にありますので、見てみたい方・議論したい方・ツッコミしたい方、お声がけください。

Meety or Meetyのグループディスカッションを考えたのですが、クローズよりはオープンな勉強会とかの方が良いのかなと思ったり。何社か集まってできるといいな。

2021年9〜10月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム コミュニケーション プラクティス プロダクトマネジメント スクラムマスター スプリントレビュー ファシリテーション

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第7弾で2年目に突入しました！

ノウハウ・知見

Ryuzeeさんがまとめてくれたアジャイルに関するFAQ

これもよいし、Waicrew 角さんのも良いまとめだなと思っています。

www.ryuzee.com

山型クロスファンクショナルチーム

クロスファンクショナルチーム/フィーチャーチームを組もうとすると「全部触れるようにならないとダメですか?」と質問がいつもくるのでこういう考え方もあるよって広まってほしい。

Miroの便利機能まとめ

有償でしか使えない機能があったりするので色々探検が必要。

note.com

短期と長期両方大事

理想論から長期目線に引っ張られることが多いけど、短期でも成果を出していくことは大事。

yattom.hatenablog.com

スクラムフェス三河キーノートスピーチ書き起こし

ありがたい

logmi.jp

カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー

3年前の発表資料のようですが何かの拍子にふと見かけて良い内容だったので

しいばさんと咳さんとみわさんの雑談

タイミング合わなくて聞けなかったのが残念。

咳チームのことを考えると、自分の中の不純物に気づくことができるから。

これわかります。

aki-m.hatenadiary.com

bufferings.hatenablog.com

「心理的安全性おじさん」になっていませんか?

概念じゃなくて現場に寄り添いましょう。

www.nakahara-lab.net

余白を作り、埋める動きをする

自分が社内でやっている動きに近い。

他社事例

atama plusのスプリントの紹介記事

スプリントレビューで500件コメント出るのはすごい。見学に行ってみたい。

note.com

atama plusでLeSSを取り入れたことのエンジニア感想

Rettyと大差ないねーという声がありました。

note.com

Twitter

オンラインのアイスブレイクにはしりとりがおすすめ

うまくいかない時は自分と周囲の状況把握こそ大事

仕様通り以上の品質にチャレンジしているか

すぐできる改善はさっさとやろう

ミーティングなんか出てないでディスカバー行ってこいよ

入社したばかりの人に「次にこの人と話すといいよ」というテレフォンショッキング形式 1on1をやるとよい

Rettyでも次に入社した人にやってあげようと思っています。

改善項目の選び方

ほんとこれ

デプロイを自動化したいというPBIはHowを表している

Keepを考えるのが苦手な方へ

POが決める優先順位にはフィードバックをあげる必要がある。

Minimum Viable Productを作るイメージ

mobile.twitter.com

ステークホルダーの紹介をきちんとしてあげよう

スクラムフェス三河 2021でスクラムマスター育成の話をしてきました #scrummikawa

カンファレンス アジャイル スクラムマスター スクラム Scrum Fest Mikawa

はじめに

スクラムフェス三河でスクラムマスターの育成について話してきました。今年は会社からも5名の登壇者が出ており、普段の業務を通じた学びをコミュニティに少しは還元できたかなと思っております。

https://confengine.com/conferences/scrum-fest-mikawa-2021/proposal/15593

資料をSpeaker Deckに公開していますが、はてなブックマークのホットエントリ入りした効果か、スクラムフェス三河の参加者以外にも読まれているようですので、当日の発表・スクラムフェス三河のDiscordで捕捉した事項も本記事で紹介しておきます。

発表の捕捉

なんでこんな話したの?

アジャイル・スクラム系の情報発信、勉強会・カンファレンスで多く登壇機会をいただいているおかげか、「うちも(大規模)スクラムやろうと思っているのですが、少し話を伺えませんか?」というお話をいただく機会が少なからずあります。数社お話して毎回質問されるのが「チームが増えたときにスクラムマスターの成り手がいないのですがどう対処したのですか?」というものです。最初はその会社固有の課題なのかと思いましたが、話を伺った会社全てに聞かれた気がしたのでこれはひょっとして普遍的な悩みなのかと考えるようになりました。あまりにたくさん聞かれたので、このブログでも5月に一度記事を書いています。

tune.hatenadiary.jp

あらためて読み直すとスクフェス三河発表スライドよりも情報量多いですね💦

リーダー・管理職は、どうしてスクラムマスター不向きなの?

「権力勾配を使って自分の意見を押し通しやすい」ため、"名前を付け替えただけで何も変わってない"状態に陥りやすいと思っています。

※リーダー=会社・組織で定義されているチームリーダーのような役職を指してます

「スクラムがやりたい人」は、どうしてスクラムマスター不向きなの?

熱意があるのは素晴らしいのですが「本に書いてあるからこのやり方が正しい！あの人はスクラムの勉強が足りてない！！異論は認めない！！！」という対立構造を引き起こしがちな気がしています。私たちは価値提供・課題解決をしたいのであって、スクラムをやりたいわけではないはずです。

悩み続ける人はスクラムマスターに向いているの?

メンバーからの「どうしてスクラムだとこういうやり方をするんですか?」という質問に対し、自分たちの言葉で答えを考え続ける方が、その組織にあった良いやり方に辿り着ける確率が高いと思います。

スクラムマスターは役割なの?

スクラムガイドを参照したところ「責任」と言う表現を使っていました。

スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。 スクラムはスクラムチームにおいて、開発者、プロダクトオーナー、スクラムマスターという 3 つの明確な責任を定義する。

スクラムガイド 2020版

いずれにせよ、「スクラムチーム全体が、スプリントごとに価値のある有⽤なインクリメントを作成する責任を持つ。」なので、スクラムマスター一人が勉強して、スクラムの全てに責任を負わせているような体制は良くないと思います。

開発者兼任のスクラムマスターってどうなの?

「専任はダメ」としているのではなく「専任でも兼任でもいいよ。結果的に全員兼任を選んでいるよ」という状態です。 スクラムマスターに話を聞くとームの状況に応じ、開発に割く時間は増やしたり減らしたりしているそうです。 「他の開発者と同じぐらいコード書いてね」という前提がなければ良いと私は思うのですが、専任にすべき派の意見も聞いてみたいところです。

スクラムを好きになってくれるかもわからないのに「あなたはスクラムマスターになったのだから真のリーダーとしてサーバントリーダーシップを発揮し、スクラムチームとその外の組織に奉仕する必要がある」と言われても困ってしまうと思うのです。

教科書通りやることが何より難しいんだけど

「教科書通りやることだけ」を注文すると案外できますよ。 最初からいろいろスクラムマスターに色々求めすぎているのでは?

「スクラムマスターじゃなかったら」という前提条件の外し方はどういうこと?

スクラムでの正解が欲しいのか、問題に対しての打ち手が欲しいのかでいうと、ほとんどのケースは後者だと思うのです。

スクラムマスターとしてはお給料上がらないということ?

スライドの表現が紛らわしかったなと思っています。

  • エンジニア共通のグレード定義がされており、社員はいずれかのグレードに分けられる (よくあるグレード制度・役割等級制度)
  • 「スクラムマスターは役割」であり、どのグレードに所属していもスクラムマスターになれる
  • グレードで定義された役割・成果が果たせていれば昇格する。

スライドで伝えたかったことは下記です。 - エンジニアのグレード定義とは別にスクラムマスターのグレード定義を用意しているわけではない。 - スクラムマスターの次に、シニアスクラムマスターとかアジャイルコーチのようなキャリアパスを社内で整備しているわけではない

エンジニアリングマネージャーとしてどんなことをしているのか？

開発プロセス 育成 組織 採用 マネジメント

はじめに

今流行りの Meetyを使って社外の方とお話しする機会を作っているのですが、「エンジニアリングマネージャーとしてどんなことをしているのですか?」という質問を何度かいただいたので、自分の整理のためにも日々の具体的な行動・活動をまとめてみます。

私はRetty株式会社でtoC Web開発/toB Web開発 両方をみているエンジニアリングマネージャーであり、この記事を書いた2021年9月時点では20名弱のマネジメントを務めています。エンジニアリングマネージャーとなってからは2年が経ちました。

エンジニアリングマネージャーとは?

いろんな議論・定義がありますが、Engineering Managerは何をする人なのかが網羅されていると思います。個人的には「エンジニアリングのマネジメント」であり、開発で生じる様々な問題を監督し、組織が期待する開発力を用意することが一番の役割だと考えています。開発力は分解すると"プロダクトを生み出す力"、"デリバリーのスピード"、"プロダクト品質"など様々な側面があると思いますが、その時々で組織の弱いところを補うように動かざるをえないことが多い結果、各社・各自でエンジニアリングマネージャーの役割の差が生じているのかと考えます。

いくつかの軸でまとめるにあたりラクスルVPoEの高橋さんがまとめた下記資料を思い出しました。この中でも"やってるもの"と、"やってないもの"と、"書かれてないけどやっているもの"があり、本当に領域が広いのだなと改めて感じました。

メンバーのサポート・育成・評価

メンバーの状態観察

週1回〜隔週1回のペースで1on1を1回30分行っています。社内の他部門や他社の話を伺うに、開催頻度は多いようです。 結構な時間が1on1で割かれてしまいますが、問題の芽が小さいうちに拾えることが多く、実施は大変ですがこのペースでやっています。

1on1は相手のための時間とし、何を話すかは基本相手に委ねています。 入社以来使っている1on1テンプレートには先頭に目的が記載してあり、短くまとまっていてとても気に入っています。

[1on1について]
- 1on1される側のための時間であって、進捗確認や伝達命令のためのものではない
- 問題解決ではなく、課題発見をするためのもの
    - 解決は自分で考えて自主的に行っていってほしいです
    - 解決のための相談、アドバイス等の協力は積極的に行います
- お互いの期待値のすり合わせとFBの場

[Topics テンプレート]
- 目標達成の上でもやもやしていること、困っていること
- 業務上での気付き(前回から今回までで学んだこと、うまくいったこと、いかなかったこと)
- チームがもっと良くなるためのアイデア、改善点
- MGR/EM/ボードメンバーへのリクエスト
- プライベートについて(家族や自分の病気、イベントなど仕事に影響があることがあれば。結婚、出産、介護等)
- 将来のキャリアについて(変更や悩みがあれば)

目標設定・人事評価

会社の仕組みとして「3ヶ月単位で目標を建て、評価を行うMBO(Management By Objectives)」を採用しているため、それを実施しています。

プロダクト開発はスクラムで進めていますが、"チームで開発する"・"優先順位に従って開発する”・"やることは適宜見直す"というスクラムの性質から、やりきり目標や個人ごとの開発項目を建てると都度見直しが発生して運用が大変です。そこで組織目標・個人目標・個人課題に分けて設定しています。

  1. 組織目標(部門目標)
    • 複数チームで共通
    • 3ヶ月毎に見直す、大きくは変わらない
  2. 個人目標
    • 全員ほぼ共通、公開する
    • 3ヶ月毎に見直す、あまり変わらない
  3. 個人課題
    • 個人ごとに固有、非公開
    • 業務グレードが変わらない限り変わらない

目標の難易度設定が難しかったり、評価の時期と成果が出る時期がずれたり、評価の時期は毎回悩み事が発生しますが、マネージャーとして重要な職務だと考えて丁寧に説明することを心がけています。

評価の話は2020年のスクラムフェス大阪でも話をしました。

dev.classmethod.jp

後進の育成

新卒1〜3年目くらいのジュニアエンジニアは1on1を通じて成長を阻害している要因を突き止め、アドバイスをしています。 成長曲線や壁を乗り越えるタイミングは人によって異なるため、取り組み姿勢が間違っていなければ焦らず目の前のタスクに取り組むよう話すことが多いです。

中堅・シニアエンジニアになると、複数の人を巻き込んで大きい成果を出してもらいたいことが増えるため、大きな開発の取りまとめや推進役をお願いしたり、ジュニアエンジニアのメンターを依頼したりします。役割の数がどうしても少ないため、機会提供が偏ることが無いよう、乗り換えられそうなちょうど良い難易度になるよう、3ヶ月〜半年ぐらい前から考えることが多いです。

マネージャーの育成は最も時間がかかります。開発とマネジメントは求められるスキルや振る舞いが異なるため、開発タスクを減らし、マネージャーとしての振る舞いを考え・学ぶための余裕を意図的に作ってあげる必要があります。 自分が抱えている問題を移譲して代わりに解決に取り組んでもらったり、実際に起きてしまった問題を題材として「今から戻ってやり直せるならどうしたら良いか」を議論するなど、時間をかけて考え方やアプローチを伝えています。

日常の労務管理

いわゆる勤怠管理ですが、忙しさの山や谷を作らず、一定のペースで働けるように業務量を気をつけて見ています。 より具体的には残業が常態化していないか、残業が一時的に増えた場合はそれが開発の山場として妥当なものかをチェックしています。

開発

プロダクトマネジメント

企画に責任を持つプロダクト部門が別途あり、施策や方針決めは基本委ねています。 アイデアや機能提案をすることはありますが、それよりも技術負債やセキュリティ問題などエンジニアでないと判断がつかないものについて開発優先順位の強めの提言をすることが多いです。

開発タスクを分解したり、メンバーにアサインすることは基本していません。 プロダクトオーナーにより優先順位で並べられたプロダクトバックログを、開発チームが毎週開発できると考える分だけとっていきます。 自分は四半期・半年・2〜3年といったスパンで、"何をやっていきたいか"を社内のいろいろな立場の人から聞き、どう実現していくのが良さそうかを考えることが多いです。

エンジニアリングのリーダーシップ

機能追加や不具合修正関して、プロダクトコードを直接書くことはしていません。 技術採用や開発方針の決定、細かな設計も開発チームに委ねています。

開発への関与としては、チームが将来取り組むであろうふわっとした課題を先に調査しておくことを手が空いた時にしています。 また現場では決められないような「決めの問題」が生じた時に、開発責任者として意思決定したりしますが極めて稀です。 障害・インシデントが発生したときはその影響範囲の大きさによって、対応の陣頭指揮をとったりします。

開発を広く見てはいますが、自身の役割は技術でプロダクトを引っ張ることを期待されるテックリードとは異なるもので、エンジニアリングマネージャーのキャリアの先にCTOがあるとも考えていません。

採用・採用広報・アドバイザーの招聘

上位の目的としては「今の開発体制で足りない人を連れてくる」だと考えています。

採用

採用チームと定例を持ちながら、採用活動に広く協力をしています。 スカウトのフィルタリング、スカウト文面の送信、カジュアル面談の実施、コーディング試験の評価、技術面接など。

またインターンコンテンツを考えたり、採用イベントを準備したりします。 ここ半年だと下記のイベントに携わりました。

採用広報

勉強会の開催、カンファレンス登壇、テックブログ執筆などの活動です。 自分自身の知名度を上げキャリア形成をやりやすくする目的もありますが、組織としても採用活動に遅れて効果が出てくると考えています。 直近だとスクラムフェス三河に会社から5件のプロポーザルをだし全て通過、Go Conference Autumnに会社から7件のプロポーザルを出すことができました。 ノルマや金銭的なメリットを設定しているわけではないため、普段の業務で学んだことを対外的にアウトプットし、学びにつなげるメリットを広く組織に浸透できているのだと思っています。

また定期的に対外アウトプットをしておくと、一定期間の自分の活動をまとめるきっかけになるだけでなく、「口だけにならない」と言う自分への戒めにもなるなと感じています。

アドバイザーの招聘

自分が詳しくなく組織としても弱い領域、自分ができるけど手が回らない領域で外部の識者の方にアドバイザー・相談役をお願いしています。 どの方にも豊富な経験に基づいた適切なアドバイスをいただけており、組織として悩む時間を減らせたり、自信を持って取り組む後押しになっています。

社内勉強会での講演や、単発のワークショップももっとやっていけたらなと思っているのですが、開発の状況・予算・開催タイミングなどあり、声はかけながらも開催にいたってないものがいくつもあります。これは私の力不足が大きく、ただ申し訳ないです。

他社との情報交換

エンジニアリングマネージャーとしての打ち手は組織や置かれた状況のコンテキストによって効果があるものもないものもあり、引き出しを増やすことが大事だと考えています。 なので他社の方から相談をいただいた場合は基本的に引き受け、積極的に自分たちの経験を共有しています。 相談を持ち込んだ側は同じ問題で時間を取られることなく、壁を乗り越えた先にあった新しい問題も次回に共有してくれるためどの会社とも学びのある情報交換をさせていただいております。

他にも「自社で起きている問題が一般的なのか、自社固有の問題なのかを切り分ける判断材料になる」「他社の相談を先に受けておくことで、自社で別の相談が出てきた時に相談しやすい」というメリットもあります。

終わりに

会社から与えられた仕事や目標はあるようであまりありません。会社やプロダクトの様子を見ながら社内を広く見渡し、自分で考えて作っています。 直接的な仕事はなく、自分が居なくても開発業務は回ると考えています。 1週間居なくても全く問題ないでしょう。事前に準備しておけば1ヶ月居なくても多分大丈夫だと思います。 ただし3ヶ月居なくなると開発でうまくいかないことが増えてきたとメンバーが感じることが増えるのではないかなと思っています。 エンジニアリングマネージャーとしての貢献はこれぐらい長期で効いてくると考えています。

大変なことが多い、直接的な達成感も得にくいエンジニアリングマネージャーですが、下記が面白さかと考えています。

  • プロダクトの成長 : なんだかんだ方向性に関与できる裁量が大きい。
  • 組織の成長 : 同じメンバーでも雰囲気や成果は異なる。
  • メンバーの成長 : 突然殻を破るような成長を身近で見れるのは嬉しい。

この記事を読んでもっと聞いてみたいと思った方、ディスカッションしたいと思った方、Rettyのエンジニアリングマネージャー職に興味が沸いた方は是非Meetyでお話ししましょう。

meety.net

2021年7〜8月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム コミュニケーション プラクティス プロダクトマネジメント スクラムマスター スプリントレビュー ファシリテーション

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第6弾でトータルで1年間まとめを続けることができました。

ノウハウ・知見

チームで品質を考えるレビュー

speakerdeck.com

プロダクトオーナーとしての成長

わかりやすい。

takaokimura.medium.com

エンジニアが自走する組織の作り方

medium.com

個人が持つタスクに期限を設けてみる

スケジュールにバッファを設けるのは悪か？

不確実性コーンの実例として分かりやすい。

tech.unifa-e.com

体験のデザイン・リーン・アジャイル開発の関係

何が欠けるとどうなるのか説明がわかりやすい。

note.com

アジャイル関連本の年表

app.mural.co

アジリティを支える品質特性

speakerdeck.com

リモートアジャイル開発のノウハウ集

www.agile-studio.jp

片思いマッピング

service.plan-b.co.jp

他社事例

LINE NEWS

エンジニア40人、企画60人でLeSSっぽく作るLINE NEWS

engineering.linecorp.com

HERPのLeSS事例

note.com

LeSSをやめたRepro

octopass.jp

ラクスのLeSS事例

speakerdeck.com

アカツキのLeSS事例@CEDEC

speakerdeck.com

Twitter

PdMは映画監督説

ツールが問題を解決してくれるのは幻想

ふりかえりでファシリテーターが全ての発言にコメントしてしまうあるある

最初にWhyを明確化しろ

プロダクトバックログの優先順位が守られない困りごとの比喩

スプリントレビューは料理の試食会

スクラムマスターは先頭に立つな

その他

Rettyメンバーからのカンファレンスプロポーザルです。話が聞きたいなと思ったらConfengineにログインして「いいね」をお願いします。 採択されなくても、勉強会に声かけいただければ皆喜んで参加すると思われます。

※8/29時点

[スクラムフェス三河]

[スクラムフェス札幌]

[Regional Scrum Gathering Tokyo 2022]

2021年5〜6月に社内で共有したアジャイル開発関連の記事

LeSS アジャイル スクラム Scrum Fest Osaka コミュニケーション トヨタ生産方式 プラクティス プロダクトマネジメント

社内でアジャイル開発を議論するSlackチャンネル #tech_agile に見かけた良記事のまとめです。この記事は第5弾、次回で祝1周年となります。

ノウハウ・知見

リモートのスプリントレビューを盛り上げるコツ

弊社でもレビュー後のZoomブレイクアウトルームを使った議論タイム設けました。簡単で効果高いのでおすすめ。

medium.com

スクラムマスターの資格まとめ

当方無免許です。

yattom.hatenablog.com

初めて入るチームでの立ち回り例

ikikko.hatenablog.com

内製化に取り組む方へのアドバイス

blog.kengo-toda.jp

スクラムとSECIモデルの関係

iucstscui.hatenablog.com

開発スピードを上げたいなら開発スコープを小さくしよう

はい。

medium.com

ロードマップに機能を書くべきではない

note.com

ブロッコリーさんがよくシェアする記事、シチュエーションも添えて

良記事集です。

nihonbuson.hatenadiary.jp

素早く頻繁に失敗しよう

ゾンビスクラムサバイバルガイド

面白そう。

agnozingdays.hatenablog.com

リチーミングモデル

固定的なチームが成熟しすぎると、サイロ化が生じて学習や改善がチーム内に閉じ、組織学習を阻害するという考え方。下記のどれもやった記憶あり。

  1. 社会化(Socialization) — 新たなチームメンバを参加させるためにチームが継続的な努力を払う。そのような継続的プラクティスを通じて、新たなチームメンバの受け入れ能力が向上する。
  2. 有糸分裂(Mitosis) — 分裂可能な大きなさまで、チームが成長する。新たに生まれたチームは、すでにその時点から、業務に精通している。
  3. ボランティア消防団(Volunteer Fire Department)チームモデル — 有志メンバが一時的なタスクチームを結成して、主要な問題を解決した後に、元のチームに戻る。
  4. 交換所(Trading Places) — チームが他のチームとの間でメンバを一時的に交換することで、組織全体で学習成果を共有する。

www.infoq.com

仕事中は理想のプログラマーを演じ切るといい振る舞いができると言う話

druby.hatenablog.com

他社事例

ヤフー

デイリースクラム(朝会)でチームが見つけたチーム内の課題を話すのよさそうです。

techblog.yahoo.co.jp

SMS

リリース出来たらご褒美にレゴを組み立てる文化

tech.bm-sms.co.jp

LINE

LINE TODAYでのLeSS事例、LeSS成分は少なめ

www.youtube.com

Chatwork

モブレビューのおすすめ

creators-note.chatwork.com

Scrum@Scaleの取り組み

SmartHR

デザイナーのスクラムへの関わり方で「スプリントレビューでステークホルダーを観察する」というのがあって面白い、確かに。

creatorzine.jp

LeSS開発の話がチラッと。4〜5人/チーム * 5チーム = 20名弱っぽい。

tech.smarthr.jp

スプリントレビューにユーザーを招待した話、すごい！

tech.smarthr.jp

ユーザー要望から機能を開発した場合、要望をくれたユーザーに報告して開発完了となるらしい。素晴らしい。

Mixi / みてね

LeSSをやめた話

[https://atsushisakai.medium.com/%E3%81%BF%E3%81%A6%E3%81%AD%E3%81%AE%E9%96%8B%E7%99%BA%E3%82%B9%E3%82%BF%E3%82%A4%E3% 83%AB%E3%82%92%E5%A4%A7%E3%81%8D%E3%81%8F%E5%A4%89%E3%81%88%E3%81%9F%E8%A9%B1-6e1a206922a6:embed:cite]

Timers

LeSS事例

techblog.timers-inc.com

勉強会・カンファレンス

iCare Dev Meetup

キヤノンメディカルの「あのチーム」の話

www.youtube.com

スクラムフェス大阪

基調講演

qiita.com

サイボウズ天野さんの社会人の基礎としてのアジャイルの背景知識まとめ

家事の話だけど、開発部門が取り組むカイゼンがどういうものかわかりやすいと思い会社の子育てチャンネルに投げた。

世の中いろんなスクラムマスターがいます。

アカツキさんのLeSS事例

ラクスさんのアウトカム指向への転換取り組み。課題感がうちとちょうど同じくらい。

テストを書く前に考えるテストの話

トヨタ主査制度の最初の1人の話

スクラムフェス札幌

残念ながらオンライン開催のようですが、今年も盛り上がって参りましょう。

www.scrumfestsapporo.org

その他

Google Relay

まだ読めてない><

スクラムマスターになると張り切っちゃう問題

スプリントレビューの工夫

ユーザーに近しい方に来てもらい、シナリオを渡して観察する。どんな感じか見学に行ってみたい。

ベロシティを目標においてしまうアンチパターン

社内で何人かにマサカリささってました。

Miroにホワイトボードを置くとトピックが散らからない説

プロダクトチームのあり方

右側を志向していかないといけない。

TRYを翌週振り返るときのよい意思表明のやり方

「直接話した」スタンプ

弊社にもできたんだけど、「話した内容をSlackに書くべきだ！」という主張の方がそれなりにいるみたい。 主張はわかるけど、スタンプもないと話しがあったのかも、誰が話したのかもわからないし、ないよりは全然マシだと思うんだけど。 内容を残しておいて欲しいほどのやつなら「口頭で話したことをメモで残して下さい」と言いやすくなるので。

PBIの打率測ってますか?

スクラムフェス大阪 2021でシステム思考の話をしてきました #scrumosaka

カンファレンス Scrum Fest Osaka アジャイル システム思考

はじめに

今年もスクラムフェス大阪でプロポーザルを採択いただき、話してきました。

confengine.com

社内で向き合う課題が段々と複雑に・難しくなってきているため「システム思考」を布教することが増えてきています。 ただ「これ読んでおいてー」ですむような、最初のとっかかりに適した資料がなかなかなく、「ないなら自分で作るか！」と追い込むためのプロポーザルでした。 他の方の登壇を聞いていてもシステム思考に言及することが最近増えてきたのでニーズはそれなりにあるのではないかと思っています。

登壇準備をしている時は20分枠だといろいろ盛り込むのが難しいなと感じていましたが、使い始めるにあたって必要最小限のことを盛り込むようにまとめられたかと思います。

過去のシステム思考に関連しそうな記事

参考資料

なぜあの人の解決策はいつもうまくいくのか？―小さな力で大きく動かす！システム思考の上手な使い方

世界はシステムで動く ― いま起きていることの本質をつかむ考え方

学習する組織 ― システム思考で未来を創造する