システムの最適化目標がなければ組織改革はできない

クレイグ・ラーマン（Craig Larman）氏の著作（例：「Scaling Lean & Agile Development: Thinking and Organizational Tools for Large Scale Scrum (LeSS)」）では、組織改革においてシステムの最適化目標にはっきりと焦点を当てている点が際立った特徴です。アジリティと整合するシステムの最適化目標の一例が、

変化に対する組織の適応力の向上です。

クレイグ・ラーマン氏は次のとおり明快に説明しています。

確かに、 LeSSの組織設計は幅広い適応力を備えています。

…ですが、適応力は適応力それ自体のために存在するわけではありません。適応力の存在理由は別の点にあります。それは、高い価値やインパクトを持つものが何かを事前に知るのは非常に難しく、競争が重要で、新技術や新たなトレンドなどが出現してくる世界において、高い価値やインパクトの発見および提供を目指して学ぶということです。

プロダクト開発グループが適応性（adaptiveness, アダプティブネス） – 予期しない方向性の変更 – を上手く発揮できるための2つの要素：

1. 余計なコスト（手間）なく、迅速に方向性を変えられること
2. 方向性を決めるための情報

適応性を実現するためには（1）、方向性を変更できる体制、も（2）、方向性変更のための情報、も両方必要です。

つまり、この目標を言い換えれば、

全てを知ることは不可能であり全てが変化していく世界において、最高に価値あるものを発見し提供する組織の能力の向上となります。

SAFe、Scrum＠Scale、いわゆる「Spotifyモデル」や、基本的なスクラムについての一部の方による解説の中には、私は、一貫性のあるシステムの最適化目標を見出すことはできません。

「全てを改良する」では駄目なのか

ある意味では改良でも、他の意味では改悪であったりします。例えば、顧客満足度の向上という目標は、今期の株価上昇と矛盾する可能性があります。もう一つ例を挙げましょう。以前、スクラムトレーナーを兼任することになったプロジェクトマネジャーが「自分の経験から言うと、スクラム・オブ・スクラムは素晴らしいものだ！」と言うのを聞いたことがあります。この発言は、最適化しようとするのがプロジェクトマネジャーに解決を依頼する類の問題のためであるなら正しいかもしれません。しかしアジリティ向上のためにスクラムを行うのであれば、より良い別の方法を検討した方が良いでしょう。

システムの最適化目標を欠くとどうなるか

例A：

以前一緒に仕事をしたある会社についてお話しします。 100人に満たない社員は、同じフロアの洒落たモダンなオフィスで全員が一緒に働いていました。経営陣は熱意をもって取り組んでいるように見えました。しかし議論が進むにつれて、経営陣は、過去20年かけて築き上げた、ビザンチン様式のように複雑な組織構造や行き過ぎた専門化について、これを解消したくないと考えていること、人が新しいスキルを学べるとは考えておらず、従業員に対するマイクロマネジメントが最善であると本気で信じていることが明らかになってきました。

その会社がオーバーオールレトロスペクティブを試みたときに行ったのは、組織の複雑性という問題の元凶を増大させることでした。 局所最適化バイアス は非常に強いものです。そのため、最適化目標を明確にしないままレトロスペクティブを盲目的に行ってしまうと、状況を悪化させてしまうおそれがあります。

経営陣が明確な最適化目標を提示し、それに適合する行動をとれないのであれば、経営陣のレベルが低すぎるのかもしれません。

例B：

同規模の別の会社では、モブプログラミングのトレーニングセッションにCEO自らが参加して、自分の眼でコードを見て、自動テストの追加方法を提案してくれました（これはアフマド・ファフミー（Ahmad Fahmy）氏のゲンバスプリント）に類似します）。この行動のおかげで、質の低いコードをかき回してバクを増やし続けるよりも立ち止まって修正する方が適切である場合が多いという明確なメッセージが皆に伝わりました。

適切なシステムの最適化目標とは

例C：

複数チームのプロダクト開発グループと仕事をした時のことです。彼らはホットフィックス地獄に陥っていました。以前のリリースの修正やサポートに多大な労力が費やされており、新機能の開発は不可能でした。製品にはバグが非常に多かったので顧客に拒否されることも多く、いくつものバージョンをホットフィックスするため更にサポートが必要という状況でした。この状況を脱却するためにチームがなすべきことは、自動テストを書くことに集中し、重複コードを減らすことに集中し、他のチームとの協働に集中することです。しかしこれらは、従来奨励されてきた活動、即ち、質の低いコードの量産とは矛盾するものでした。そのため当初は、スクラムが「生産性を減らしている」という不満の声がありました。幸いにも経営幹部が、局所的な効率性や古い「生産性」といった旧来の考え方は組織改革の趣旨ではないと明言してくれました。

最終的には努力が実って、しっかりビルドを行い、確かな製品をリリースできるようになりました。そしてそこで組織の変化を止めてしまったのです。私は、初めは落胆しました。更なる変化（アジャイル）を行えば、顧客ニーズへの適応力をますます高められると分かっていたからです。しかし彼らはまともな製品をリリースできるようになったことで非常に満足し、アジリティ向上にむけて更に変化してゆく意欲を失っていました。

LeSSの主眼は適応力・アジリティの向上であり、まともな製品のリリースではありません。とは言え、まともな製品のリリースも適応力やLeSSのガイダンスと整合するものです。ホットフィックスの海に溺れていては、顧客ニーズの変化に適応することはできません。

私はこの経験から、組織のシステムの最適化目標とはどうあるべきかに関する自らの考えに固執し過ぎないことを学びました。一つの「正解」はないのです。同時に、経営幹部は以下のことを行うべきであると考えるようになりました。

1. 目標を慎重に定めること。
2. 目標を皆に明確に伝えること。
3. 手放すべき執着を伝えること（困難なものは特に）。

目標にとってコンテキストが重要となる場合

人は時に予測可能性を求めます。スクラムでは、出荷可能な製品を数週間ごとに作る等いくつかの点において、予測可能性をできる限り高めることを目指します。必要のない予測不可能性を除去するためです。あるいは、要件への理解の深化や新技術の学習などといった必要な予測不可能性への対応力を高めるためかもしれません。

その組織改革には一貫した最適化目標がありますか？

以下に示すのは、あなたの組織に存在しうる最適化目標¹ のリストです。明示的な場合もあれば、黙示的な場合もあります。あなたの状況下で目標同士に整合性がある場合も、ない場合もあります。

• リリース頻度の向上
• 各リリースにおける欠陥の減少
• 予測可能性
• 快適さ
• 順序である
• 担当者および業務内容の明確性
• 資源活用（従業員のフル活用）
• 発想（アイディアの創造。IDEOや PARCが著名な例。）
• 単一チームの最大のアウトプット
• 秘密性²
• 従業員の満足・定着（従業員のカテゴリ別に分ける。例：コーダー、ラインマネジャー、部門長など）
• 顧客満足度
• 変革戦略が成功したような外観
• 営業収益の増加
• 首位や独占の維持
• 開発者一人あたりのコスト削減
• 製品の汎用性
• 顧客基盤の拡大・多様化
• 現状維持
• 規則・ルールの遵守
• 既存市場の破壊によるリード
• ROI向上
• 生き残り
• 計画適合性
• 直近の機能開発速度（今週の速さ）
• 当期の機能開発速度（当期の速さ）
• 来年の機能開発速度（来年の速さ）

English version: https://seattlescrum.com/you-wont-change-your-organization-without-an-optimization-goal/