この記事では、避けるべき手法と試してみる価値のある代替案を取り上げる。自分たちのチームが今どこに立っているのかを把握し、取り入れる価値のある協働の手法を見つける助けにしてほしい。 はじめに チームはどのように協力してプロダクトを作るのだろうか。自律的なチームでは、どう働くかはチーム自身が決める。とはいえ、すべてをゼロから考え出さなければならないわけではない。チームは他のチームがこれまでに得た経験から学べるし、学ぶべきである。私は、いくつかの共通した手法が現れるのを見てきた。この記事ではそれらを取り上げ、3つのカテゴリーに分類する。 避ける: 個人主義的なチーム内の手法 試す: 協働的なチーム内の手法 試す: 協働的なチーム横断の手法 より協働的な手法を勧めてはいるが、「協働のための協働」ではない。協働的な手法を好むのには理由がある。 協働的な手法は知識の共有と学習を増やす。これにより、知識のサイロ化や、バス係数（何人いなくなると開発が止まってしまうかの数）の低さといったよくある問題が解消される。 協働的な手法は、チーム内およびチーム間で文脈が共有された状態を作る。これは仕掛かり作業（WIP）の削減につながり、ひいては価値提供の高速化と、アジリティ・柔軟性の向上をもたらす。 協働的な手法は、協働を通じた学習によって新しいメンバーのオンボーディングを速める。 緊密な協働は人と人との関係を強め、離職を減らす。 ここからは、避けるべき手法と試すべき手法をいくつか見ていく。自分たちのチームの現状を評価し、実験してみる協働のやり方を選ぶ材料にしてほしい。 協働手法 避ける: 個人主義的なチーム内の手法 これらの手法は、知識のサイロ化、過度な専門特化、そして高いWIPを招くことが多い。一見すると生産的に感じられるが、それは個人のタスクだけを測った場合の話であって、システム全体のパフォーマンスで見ればそうではない。残念なことに、こうした手法は非常によく見られるため、これが普通で問題ないのだと思い込まれてしまっている。 メンバーそれぞれが自分のアイテムを持つ スプリントの最初に、チームメンバーは自分が個人で取り組むアイテムを選ぶ。スプリント中は、それぞれがかなり独立して自分のアイテムに取り組む。 スプリント中のWIPは非常に高い。チームワークと学習は非常に少ない。 職能の専門特化によるシーケンシャルなプロセス 選んだアイテムを、ウォーターフォールのように逐次的に進める。多くの場合、UXデザイン → 実装 → テストという順序をたどる。チームの中には、これらの活動に対応する役割が明確に残っている。スプリント内で作業量に偏りが出るため、たいていUXの作業は実際のスプリントが始まる前（前のスプリント中）に行われ、テストの作業は次のスプリントで行われることになる。 これでは本当のチームも、本当のスプリントも存在しない状態である。 スプリント中のWIPは非常に高い。チームワークと学習は少ない。アイテムのリードタイムはたいてい3スプリントになる。 メンバーそれぞれが自分の単一スキルから出ない チームには専門特化したメンバーがいて、自分の専門分野から出ようとしない。よくある例はフロントエンド開発、バックエンド開発、DevOpsである。チームは各アイテムをタスクに分割し、各メンバーは自分の専門のタスクだけを取る。アイテムがまだ終わっていなくても、残っているタスクが自分の専門でなければ、その人は自分の専門が必要な次のアイテムに移ってしまう。 スプリント中のWIPは高い。チームワークは専門と専門の引き継ぎのときにしか起きないので、学習は少ない。 フィーチャーの抱え込み（別名「スプリントって何？」） チームは、完成までに何スプリントもかかる大きなフィーチャーに取り組む。フィーチャーをスプリントに収まる縦切りに分割するのではなく、タスクに分割して何スプリントも先まで計画してしまう。実質的にスプリントを無視して、大きなプロジェクトのようにそのフィーチャーに取り組む。毎スプリント、形式上は次のタスクを取るだけである。スプリントは報告のための儀式でしかなくなる。 WIPは高い。スプリントの終わりにプロダクトが本当に出荷可能な状態にはならないため、リードタイムは長い。ユーザーからの早期フィードバックの機会もない。たいていは、大きなフィーチャーの自分の担当部分に一人で取り組むことになる。 依存関係でブロックされる チームのスコープが狭い。プロダクトの定義が小さいチーム、マイクロサービスがチームに対応付けられている場合、あるいは「フロントエンドチーム」のような場合である。バックログのアイテムには他チームの作業も必要になるため、チームはしばしばブロックされる。ブロックされると、他チームが自分たちの分の作業を終えるまで、別のアイテムに移ってしまう。 チームのスコープは組織的に決められていることが多く、これを変えるにはチーム構造の変更が必要になる（後述の「協働的な文脈」を参照）。チーム構造の変更が実施されていない場合、他チームのコンポーネントのコードを自分たちで変更することで、依存を少し軽くするチームもある。その場合、依存は「他チームが変更してくれるのを待つ」から「他チームがレビューして承認してくれるのを待つ」に変わる。 WIPが高く、アイテムは出荷可能な状態でないことが多い。 試す: 協働的なチーム内の手法 これらのチーム内手法は、メンバー間で仕事と文脈が共有された状態を作り、それがさらに協働を生む。これらの手法は、(1) WIPを減らして柔軟性を高め、(2) 知識の共有と学習を増やして知識のサイロ化を減らし、オンボーディングを速める。 同じタスク・同じ文脈に複数人が関わることが多いため、一見すると生産的でないように感じられるかもしれない。しかし、文脈が共有され知識が行き渡ることが、全体としてより良いパフォーマンスにつながる。 協働的なチームは、これらの手法からどれか1つを選ぶというより、好み、都合、すでに持っている知識、アイテムの複雑さなどに応じて、1つのスプリントの中で組み合わせて使うのが普通である。 スプリント計画2での設計と粒度の細かいタスク スプリント計画2で、チーム全員がすべてのアイテムの設計と実装を詳しく議論する。これにより、各メンバーがそれぞれのアイテムについて何をすべきかを深く理解した状態（共通のイメージ）になる。そして、粒度の細かいタスク（たいてい数時間で終わる程度）を作り、それを作業の分担、見える化、同期に使う。チームはアイテムを1つずつ進めることにし、各メンバーは同じ1つ（あるいは少数）のアイテムのタスクを取る。チームは絶えず話し合い、作業を同期させる。これは継続的インテグレーションやトランクベース開発と特に相性がよい。チームが絶えず互いの作業を共有し合う必要があるからである（後述の「協働的な文脈」を参照）。 全員が個々に作業していても、チームの協働の度合いは高い。...

Introduction Artificial intelligence is reshaping nearly every corner of our lives, including the job market and the professions we’ve long considered uniquely human. Agile coaching and Scrum Mastering are no exception. Parts of these jobs, often the ones that were poorly or superficially defined in the first place, are far...

はじめに プロダクトを作ることは簡単だ。しかし、長く使え、保守し続けられるプロダクトを作ることは難しい。持続可能で健全なプロダクト開発組織を築くには、どのような種類の仕事が行われているのかを理解し、適切なバランスを見つけることが鍵となる。 この4年間、Wärtsilä Holistic Agreements Lifecycle Ecosystem というプロダクトは LeSS の構造で開発を進めてきた。その一環として、自分たちが何に取り組んでいるのかを、自分たち自身に対しても、また組織の他の人々に対しても、より透明にする実験を重ねてきた。透明性を高めるための前提条件は、適切に構造化され、チームが行うすべての仕事を含んだ、良質な「ひとつの」プロダクトバックログ（10チームがひとつのバックログで仕事している）だった。プロダクト開発において、チームは新しい顧客向け機能だけに取り組んでいるわけではない。私たちはそれをプロダクトバックログ上に、そして組織全体に見えるようにしたかった。そのために、この仕事の分類を作った。 注：仕事の分類の名称は、組織全体で説明しやすいように、私たちが身を置く業界の用語を反映している。 プロダクト開発の仕事を理解する 締切に追われ、AI が何でも生成する今日の世界では、顧客やマネージャーを「おお」と言わせる小さなプロダクトやプロトタイプ、デモを作ることは簡単だ。しかし、より大きく、信頼でき、保守可能なシステムを作ることは難しく、多くの作業を要する。大規模なシステムの多くは、小さなシステムとして、あるいは小さなシステムの組み合わせとして始まっており、その後、過去に行われたことを直すために多大な労力が費やされる。当時は妥当に見えた判断が、今日の知識から見ると間違いに見える、ということはよくある。 行われている仕事を理解することは、大規模なプロダクト開発を理解し、マネジメントするうえで鍵となる。特に興味深いのは次の2つの次元だ。 仕事の種類 大きな計画された仕事 vs 小さな創発的な仕事 この2つの次元を図1に示す。 図1：プロダクト開発で仕事に関わるの2つの次元 仕事の種類 持続可能なプロダクト開発とは、単により多くの機能を作ることではない。そこにはさまざまな仕事が含まれる。健全なプロダクトのための適切なバランスを見つけるには、プロダクト開発における仕事の種類を理解することが重要だ。 私たちが使っているカテゴリーは次のとおり： 受動的メンテナンス（バグ） 典型的な活動: バグ修正、障害対応、データ欠落への対応 １行サマリー: この仕事をしなければ、プロダクトは正しく機能しない。 何かがうまくいかなかった。間違いが起きた。それは直さなければならない。これらの仕事の多くは、働き方を改善することで防げる。締切のプレッシャーと低い品質基準（たとえばテスト自動化のレベルの低さ）が、通常この仕事を生む原因となる。 完全になくすことはできないが、これをできるだけ小さく保つには継続的な取り組みが必要だ。 予防的メンテナンス(アップグレード) 典型的な活動: アップグレード、リサイズ、再設定、クリーンアップ、EOL（サポート終了）に伴う一部の書き直し １行サマリー: この仕事をしなければ、プロダクトは将来動かなくなる。 まだ何も問題は起きていない。しかし稼働環境の側で変化が起きている。これに応じなければ、ダウンタイムやセキュリティリスクにつながりかねない。 定期的に行わなければ積み上がり、さらに多くの仕事を生む。完全になくすことはできないが、監視と自動化によってリスクと労力を減らすことはできる。 プロアクティブ・メンテナンス (内部的な改善) 典型的な活動: 自動化、統一と標準化、書き直しやリファクタリング １行サマリー: この仕事をすれば、プロダクト開発が改善し、他のメンテナンス活動が減る。 他の種類のメンテナンス活動は、プロアクティブ・メンテナンスを通じて徐々に減っていく。プロアクティブ・メンテナンスの仕事は、開発者体験を高め、効率を上げ、開発とインフラの能力を高める。 この仕事は、コストと労力の削減、そして内部品質と信頼性の向上への投資である。ただし、環境の変化、技術の進化、そして機能開発の活動が新たな改善機会を生み続けるため、終わることはない。 運用（監視、問い合わせ対応、手動作業） 典型的な活動: 監視、問い合わせへの対応、アクティベーション、手動でのリリース作業（dev /...

Systems Thinking · LeSS · Modelling as conversation Sisko: A Conversation Starter for Systems Modelling Systems modelling is not about producing the perfect picture. It is about helping people talk together about the system they are part of. Inspired by Wolfgang Steffens’ work on Sisko and systems modelling. In LeSS...

There’s a hidden assumption behind most organizational charts and role descriptions — one that shapes how work, teams, and even people are designed. It’s the belief that knowledge is fixed, that what someone knows defines what they can contribute. That’s why we hire specialists, build silos, and admire deep expertise....