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....

In a good and evolved LeSS adoption, there are no projects in product development. — Bas Vodde In LeSS, development changes from project-based development to product-based development. What does that mean in practice? Project-based development Project-based development uses the concept of projects for managing work. A project has a goal,...