by Bas Vodde
プロダクトを作ることは簡単だ。しかし、長く使え、保守し続けられるプロダクトを作ることは難しい。持続可能で健全なプロダクト開発組織を築くには、どのような種類の仕事が行われているのかを理解し、適切なバランスを見つけることが鍵となる。
この4年間、Wärtsilä Holistic Agreements Lifecycle Ecosystem というプロダクトは LeSS の構造で開発を進めてきた。その一環として、自分たちが何に取り組んでいるのかを、自分たち自身に対しても、また組織の他の人々に対しても、より透明にする実験を重ねてきた。透明性を高めるための前提条件は、適切に構造化され、チームが行うすべての仕事を含んだ、良質な「ひとつの」プロダクトバックログ（10チームがひとつのバックログで仕事している）だった。プロダクト開発において、チームは新しい顧客向け機能だけに取り組んでいるわけではない。私たちはそれをプロダクトバックログ上に、そして組織全体に見えるようにしたかった。そのために、この仕事の分類を作った。
注：仕事の分類の名称は、組織全体で説明しやすいように、私たちが身を置く業界の用語を反映している。
締切に追われ、AI が何でも生成する今日の世界では、顧客やマネージャーを「おお」と言わせる小さなプロダクトやプロトタイプ、デモを作ることは簡単だ。しかし、より大きく、信頼でき、保守可能なシステムを作ることは難しく、多くの作業を要する。大規模なシステムの多くは、小さなシステムとして、あるいは小さなシステムの組み合わせとして始まっており、その後、過去に行われたことを直すために多大な労力が費やされる。当時は妥当に見えた判断が、今日の知識から見ると間違いに見える、ということはよくある。
行われている仕事を理解することは、大規模なプロダクト開発を理解し、マネジメントするうえで鍵となる。特に興味深いのは次の2つの次元だ。
この2つの次元を図1に示す。
持続可能なプロダクト開発とは、単により多くの機能を作ることではない。そこにはさまざまな仕事が含まれる。健全なプロダクトのための適切なバランスを見つけるには、プロダクト開発における仕事の種類を理解することが重要だ。
私たちが使っているカテゴリーは次のとおり：
典型的な活動: バグ修正、障害対応、データ欠落への対応
１行サマリー:
この仕事をしなければ、プロダクトは正しく機能しない。
何かがうまくいかなかった。間違いが起きた。それは直さなければならない。これらの仕事の多くは、働き方を改善することで防げる。締切のプレッシャーと低い品質基準（たとえばテスト自動化のレベルの低さ）が、通常この仕事を生む原因となる。
完全になくすことはできないが、これをできるだけ小さく保つには継続的な取り組みが必要だ。
典型的な活動: アップグレード、リサイズ、再設定、クリーンアップ、EOL（サポート終了）に伴う一部の書き直し
１行サマリー:
この仕事をしなければ、プロダクトは将来動かなくなる。
まだ何も問題は起きていない。しかし稼働環境の側で変化が起きている。これに応じなければ、ダウンタイムやセキュリティリスクにつながりかねない。
定期的に行わなければ積み上がり、さらに多くの仕事を生む。完全になくすことはできないが、監視と自動化によってリスクと労力を減らすことはできる。
典型的な活動: 自動化、統一と標準化、書き直しやリファクタリング
１行サマリー:
この仕事をすれば、プロダクト開発が改善し、他のメンテナンス活動が減る。
他の種類のメンテナンス活動は、プロアクティブ・メンテナンスを通じて徐々に減っていく。プロアクティブ・メンテナンスの仕事は、開発者体験を高め、効率を上げ、開発とインフラの能力を高める。
この仕事は、コストと労力の削減、そして内部品質と信頼性の向上への投資である。ただし、環境の変化、技術の進化、そして機能開発の活動が新たな改善機会を生み続けるため、終わることはない。
典型的な活動: 監視、問い合わせへの対応、アクティベーション、手動でのリリース作業（dev / acc / prod）
１行サマリー:
この仕事をしなければ、プロダクトが動いているかどうかが分からない。
プロダクトは本番環境にあり、使われており、動き続けさせる必要がある。本番システムの状態を監視し、さまざまなユーザーからの問い合わせに応えることは継続的な活動だ。ときには新しいアクティベーションや設定作業も必要になる。
この作業は継続的であり、その多くはプロダクトの改善と自動化、すなわち改良保全によって減らすことができる。
典型的な活動: フィージビリティスタディ、ユーザーリサーチ
１行サマリー:
これらは洞察を生み、新しい項目や優先順位の変更につながることがある。
プロダクト開発の仕事がすべて直接的な開発活動というわけではない。プロダクトの進むべき方向を調べたり、顧客とその問題についてより深く学んだりするために、時間を取る必要があることもある。
典型的な活動: ユーザーから直接寄せられる小さな機能要望、あるいはロードマップ上の大きな機能開発
新しい機能はプロダクトの目的と用途を高める。理想的にはこれが仕事の大半を占めるべきだが、実際には他の種類の仕事が相当な時間を占める。
どのプロダクトにも、ビジネスケースと、実現したい機能や改善のロードマップがあるべきだ。これは組織がどれだけの投資を行うかを決めるために使われ、大きな組織では通常、予算という形で表現される。しかし、プロダクトが本番で稼働し使われるようになると、そこから創発的な仕事が生まれる。それはしばしば小さいが、重要な仕事だ。こうした創発的な仕事は小さな機能のこともあるが、多くはプロダクトを動かし続け、改善し続けるための仕事である。
なので、仕事をこの視点で見ると：
ロードマップアイテム — ロードマップに載っている大きなアイテム。その多くは新機能だが、保守の労力や運用コストを減らす長期的な改善が含まれることもある。ロードマップ項目は通常、スプリントで選択される前により小さなアイテムへと分割される。
創発的アイテム — ロードマップに紐づかない小さなアイテムで、やる必要性があるもの。フィードバックへの対応や小さなプロダクト改善など、顧客向けのものもある。しかし創発的アイテムのかなりの部分は、何かを直したり改善したりする仕事だ。どんなプロダクトにも創発的な仕事は生じる。
こうした創発的な仕事がすべて「保守（メンテナンス）」とひとくくりにされることがある。そうなると保守はブラックボックスになり、その中で見えるのはバグだけになってしまう。すべての創発的な仕事に保守というラベルを貼ることは誤った印象を与える。その一部は間違いによって引き起こされた仕事であり、一部はプロダクトの改善だからだ。これらの仕事の種類のあいだで健全なバランスを保つことが、より良いプロダクトと、より効率的なプロダクト開発につながる。
「仕事の種類」と「計画 vs 創発」という2つの次元を組み合わせると、労力がどこに向かっているのか、より完全な姿が見えてくる。
| 仕事の種類 | ロードマップ | 創発 |
|---|---|---|
| 受動的メンテナンス (バグ) |
受動的メンテナンスはロードマップの継続的デリバリーにより、逐次的にアイテムを作っている時に発生する可能性がある。 | 典型的なバグ |
| 予防的メンテナンス (アップグレード) |
EOL 技術の置き換えや大規模なアップグレード | 依存のあるライブラリのバージョン更新 |
| プロアクティブ・メンテナンス （内部的な改善） |
大きいもの、多くはアーキテクチャ上の改善 | チームから出てくる小さな改善 |
| 運用 (監視) |
あまりない | 監視や手動でのリリース |
| 調査 （リサーチ） |
大がかりなリサーチやプロダクトの新しい方向性の検討 | 技術調査や顧客訪問 |
| プロダクトの拡張 （機能） |
ビジネスケースに基づく、実現したいロードマップ | 小さな機能要望 |
これらのアイテムの良いミックスは、健全なプロダクト開発にとって重要だ。LeSS の文脈では、プロダクトオーナーはこれらの仕事の種別を使ってスプリントの仕事を優先順位付けし、適切なバランスが取れているかを確かめることができる。以下にいくつかのヒントを挙げる。
Wärtsilä では、プロダクトバックログをこれらのカテゴリーにマッピングしたことが、目からうろこの経験だった。
プロダクトバックログ上で新機能だけを優先順位付けし、マネジメントしていると、可視性が失われ、不健全で持続不可能なプロダクト開発につながる。それを避けるには、プロダクト開発におけるさまざまな種類の仕事を完全に見えるようにすることだ。それが優先順位付けと分析の鍵となる。そしてこれを、開発組織や組織の他の人々に向けたプロダクトバックログと作業報告の基礎とすべきだ。そうすれば誰もが現状を理解し、現実に基づいてマネジメントできるようになる
自分たちの今のバックログを分類してみてほしい。その結果に驚くかもしれない。
RSS feed