ソフトウェアプロダクト開発領域を預かるエンジニアリングマネージャーとして、あなたのミッションは何であるか。そう問われれば迷わず、組織としての「プロダクト開発能力の差異化」だと答える。これはもちろん私個人の見解ではあるが、受託開発組織のマネジメントを離れ、プロダクト開発組織を主としてマネジメントするようになった10年以上前から変わらない。
「プロダクトの差異化ではなく？」と聞き返されることも多い。ユーザーやビジネスにとって価値ある優れたプロダクトやフィーチャを作り出すことはもちろん第一級のミッションだ。そうであっても、そこで得られた成功が "偶然" であるなら組織としての持続性がない。「プロダクト開発能力の差異化」とは、そういった成功に再現性を持たせることを意味する。
- 組織としての「プロダクト開発能力の差異化」
- 開発能力はデリバリパフォーマンスとして表れる
- 組織構造とプロセス、アーキテクチャを進化させ続ける
- 組織構造でコミュニケーションコストを最小化する
- プロセスにフィードバックループを多重に織り込む
- アーキテクチャによってデプロイとテストの容易性を高める
- 保守性を高める技術を学ぶ
- 組織を動かすのは人である
組織としての「プロダクト開発能力の差異化」
そもそも優れたプロダクトやフィーチャは他社に真似されやすい。先発優位が長続きする市場はその数を減らしつつある。競争優位はもはや一時的で、持続しないことを前提に考えるべきだろう。経営学者のリタ・マグレイス（Rita McGrath）は、一時的な競争優位を同時並行的に確立し続けることが、長期間にわたるリードに繋がると説いた。優れたプロダクトやフィーチャを作り出して練り上げるだけでなく、更に新たな価値を生み出す。何度も何度も創造する。ここに、成功への再現性が要る。
この「再現性」というものは、組織が経験を積み重ね続けて得た能力（スキル）だ。それは、組織の存続年数に比例するものではない。ソフトウェアデリバリという実務の遂行に追われているだけでは備わらない。組織レベルでの経験学習サイクルをもって備わるものだ。
「カイゼン」を文化にまで落とし込んだトヨタに代表されるように、学習が文化として定着した組織は強い。この観点では、学習する組織を作り上げることがミッションであるとも言える。
優れたプロダクトやフィーチャは真似されやすくても、こうして組織に備わった能力というものは、そう簡単に真似されるものではない。
開発能力はデリバリパフォーマンスとして表れる
では、肝心な「組織としてのプロダクト開発能力」とは何であるか。ソフトウェアエンジニアリングを担う組織にとってのそれは、ソフトウェアデリバリのパフォーマンスだ。ニコール・フォースグレン（Nicole Forsgren）らの調査によって、ソフトウェアデリバリのパフォーマンスは、組織全体のパフォーマンスに影響する予測要因であり、両者は正の相関関係にあることが明らかにされた。ソフトウェアエンジニアがそれまで経験的に感じていたことが、正しかったと調査によって示されたのだ。
ソフトウェアデリバリのパフォーマンスは、4つのメトリクスで表される。デプロイの頻度（deployment frequency）、変更のリードタイム（lead time for changes）、平均修復時間（time to restore service）、変更失敗率（change failure rate）だ。この4つのキーメトリクスこそ、開発チームが経験を積み重ねて獲得する能力を観測するものだ。
Accelerate State of DevOps Reportでは、調査結果に基づいてこれらのメトリクスをEliteパフォーマンスからLowパフォーマンスまで4段階に分類している。自チームのスコアと比較することで、優位性を把握することが可能となる。もちろん、開発チームはそれぞれ置かれた状況や事情が異なる。必ずしもこのパフォーマンス分類がそのまま当てはまるわけではないが、参考にはなるはずだ。
組織構造とプロセス、アーキテクチャを進化させ続ける
組織としての「プロダクト開発能力の差異化」を実現し、高めていくためには、組織改革は継続的なものとなる。終わりがなく、永遠に完成することはない。進化していくように適応を繰り返す。
そこでの改革対象は、組織構造とプロセス、そしてアーキテクチャの3つを常にセットで考える。取り組む順番は組織構造、プロセス、アーキテクチャの順が良い。組織構造およびプロセスが、アーキテクチャに影響を与えるからだ。これはコンウェイの法則としておなじみだろう。
また、アルフレッド・チャンドラー（Alfred Chandler）の「組織は戦略に従う」という言葉のように、戦略に合わせて組織設計から始めることが自然にも感じる。組織設計には逆コンウェイ戦略を用い、その後に控えるアーキテクチャの変更を連動させる。
「組織は戦略に従い、システムは組織に従う」とでも言えば良いだろうか。ビジネスを取り巻く内外の状況変化に応じて戦略は変化する。その変化に対し、組織を柔軟に変化させ、アーキテクチャを進化させ続けるということだ。
組織構造でコミュニケーションコストを最小化する
組織をどのようにチーム分割するか。その結果が組織構造となる。チームを組織にとってのコンポーネントだと捉えてみると、設計の方向性が見えてくる。
ソフトウェアコンポーネントと同様に、組織コンポーネントたるチームも高凝集であるべきで、かつ、チームは互いに疎結合であるべきだ。そうすれば、それぞれのチームのソフトウェアデリバリは互いに干渉することがない。ソフトウェアの変更もデプロイも、他チームや誰かの助けや承認を得ること無く、チームが独立して実行可能になる。
これについては以前にも『開発組織を分散モノリスにしないチーム分割と協働のデザイン - mtx2s’s blog』というタイトルでブログ記事を書いた。
高凝集で疎結合な組織は、チーム内でのコミュニケーションが密（高帯域幅）に、チーム間でのコミュニケーションが疎（低~中帯域幅）になる。これは、組織内のコミュニケーションコストを最小化するとともに、このコミュニケーション構造がソフトウェア設計にも良い影響をもたらす。
『チームトポロジー』の著者であるマシュー・スケルトン（Matthew Skelton）らに言わせれば、「多くの組織はいつでもコミュニケーションは多いほうがよいと考えるが、実際にはそうではない」ということだ。『アジャイルな見積りと計画づくり』の著者としても知られるマイク・コーン（Mike Cohn）も、ブログ記事 "Nine Questions to Assess Team Structure" にて、「チーム間のコミュニケーションパスの数を最小化する構造になっているか？」と問うている。
組織構造を設計するにあたっては、エリック・エバンス（Eric Evans）のドメイン駆動設計（DDD, Domain-Driven Design）が役立つ。ソフトウェアプロダクトが扱う対象領域を適切にコンテキストに分ける。そしてこのコンテキストをもとに、どのようにチーム分割するかと、それぞれの責務が形作られる。その結果は、戦略に影響を受けるはずだ。こうして作られたチームの多くはストリームアラインドチーム（stream-aligned team）となり、それぞれが独自のバリューストリームに組み込まれることになるだろう。
プロセスにフィードバックループを多重に織り込む
ソフトウェアデリバリのサイクルを重ねる度にチームが生み出す成果と言えば、プロダクトバックログアイテムを実現したインクリメント（フィーチャや機能）をまっさきに思い浮かべる。チームが成果をそのように捉えているならば、そのチームは優れたプロダクト開発能力を得ることはできないだろう。
チームがコミットすべきはその先、つまり、インクリメントのリリースによって、優れたユーザー体験を生み出すことだ。それがユーザー価値となり、ビジネス価値につながっていく。
このような優れたユーザー体験を生み出す開発能力は、どのようにして備わるのだろうか。
優れたチームは、デリバリサイクルを重ねる過程で、プロダクトナレッジとプロジェクトナレッジという、チームの開発能力に対するインクリメントを作り出す。プロダクトナレッジは、「何を（what）作れば良いか」という目標不確実性を低減し、チームを正しいプロダクト価値に近づけていくためのナビゲーション精度を高める。プロジェクトナレッジは、「どう（how）作れば良いか」という方法不確実性を低減し、ソフトウェアデリバリにおける様々なプロセスを洗練させる。
経験に基づいて高濃度で高品質なナレッジを抽出するには、フィードバックの獲得は欠かせない。フィードバックループのサイクルが短いほど、その純度は高まる。アジャイル開発手法やDevOps、リーン開発は、プロセスにフィードバックループが組み込まれている点が優れている。
「スプリントレビュー」は、数日から数週間単位でのフィードバックだ。デプロイ頻度や変更のリードタイムを改善していく目的のひとつがこのフィードバックループの高速化だと考えると良い。「テスト駆動開発」は数十秒から数分単位のフィードバックループだ。「継続的インテグレーション」や、「ユーザーフィードバックの収集と活用」もフィードバックループだ。
上図は、VersionOneのポスター（原典は既に存在しない）をもとに書き起こしたものだ。このように、大小さまざまなフィードバックループを幾重にもプロセスに織り込む。それが、ソフトウェアデリバリのパフォーマンスを大きく左右するほどのナレッジの継続的な獲得につながっていく。
アーキテクチャによってデプロイとテストの容易性を高める
ここで言うアーキテクチャとは、ソフトウェアがどのようにコンポーネント分割されているかと、それらの依存関係を指す。コンポーネントとは、『Clean Architecture』で言うところの「デプロイの単位」であり、「システムの一部としてデプロイできる、最小のまとまり」を指す。
アーキテクチャで注力すべきは、コンポーネントのデプロイとテストの容易性だ。フォースグレンらは、著書『LeanとDevOpsの科学』の中で、デプロイとテストの容易性について次のように定義している（定義内の「アプリケーション」を「コンポーネント」として読み替えて欲しい）。
- テストの大半を、統合環境を必要とせずに実施できる
- アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる（そして実際にもデプロイまたはリリースしている）
この定義に更に、チームの凝集性に関する3つめの要素を加えたい。
これら3つに当てはまるならば、チームは高い独立性を持ってソフトウェアデリバリを遂行できる。逆に言えば、この定義に当てはまらないチームは、独立性が低く、ひとつのプロダクトバックログの実現のために、他のチームの力を借りなければならない事態が頻発するということだ。これではパフォーマンスを発揮できるはずがない。
忘れてはならないのは、組織構造やプロセスの変化がバリューストリームの流れを変え、それが各チームのプロダクトバックログの内容を特徴づけるということだ。つまり、コンテキスト境界に変化が起きているのだ。組織構造、プロセス、アーキテクチャをセットで変えていく必要性は、ここにある。
しかし、経験から言って、組織改革を進める上でアーキテクチャの変更が議題に挙がることはまれだ。組織構造、プロセスをどう変えるか。集中的に議論されるのはそればかりだ。
それはそうだろう。組織構改革にアーキテクチャとの関係性を見出すことは難しい。当たり前のように、アーキテクチャだけが取り残されてしまう。改革前の組織によって形作られたアーキテクチャが、新しい組織と上手く噛み合うとは限らない。
新しい組織構造やプロセスにあわせ、アーキテクチャが理想的な形へと自然に変化することなど期待できない。新しいアーキテクチャを仮説として持ち、それをフィードバックループの中で漸進的に進化させながら形にしていく。その仮説は、ドメイン駆動設計を詳細化する中で、組織構造とプロセスにも反映されている。これこそが、逆コンウェイ戦略だろう。
保守性を高める技術を学ぶ
ソフトウェアプロダクト開発というものは、繰り返し繰り返しソフトウェアを変更する活動だ。この「変更する」という活動を中心にソフトウェアデリバリを見つめ直すと、「変更しやすさ」がデリバリパフォーマンスのキーファクターのひとつであると気付く。変更しにくいソフトウェや変更できなくなったソフトウェアは価値を失い、競争力を失う。プロダクトをそのような状況に追い込んだ組織に、優れたプロダクト開発能力があろうはずがない。
変更しやすさ、すなわち変更容易性（modifiability）は、理解容易性（understandability）、テスト容易性（testability）と並んで保守性（maintainability）を構成する。バリー・ベーム（Barry Boehm）らの定義するこの3つの品質特性は、互いに関連しあっている。理解容易性を高めれば、変更容易性も高まる。テスト容易性が高いコードは、理解容易性も変更容易性も高いと言われる。
コードの保守性を高めるためには、リファクタリングが欠かせない。リファクタリングと言えば、いわゆる「レガシーコード」と呼ばれる既存コードに対する技術的負債を返却する行為というイメージがあるが、実際には新しいコードを書くにも必要な技術だ。それは、ケント・ベック（Kent Beck）がエクストリーム・プログラミングと共に広めたテスト駆動開発にリファクタリングが組み込まれていることからも分かる。
ここで私は、リファクタリングを「技術」と言った。マーティン・ファウラー（Martin Fowler）の著書『リファクタリング』や、マイケル・フェザーズ（Michael Feathers）の著書『レガシーコード改善ガイド』などからも分かるように、リファクタリングはスキルなのだ。そしてリファクタリングの実践にはテストコードが付きものであり、その手法たるテスト駆動開発もまたスキルだ。保守性を高めるためには、この2つのスキルを伸ばす必要がある。
当然ながら、テスト駆動開発やリファクタリングの技術的な基礎となるのは、オブジェクト指向といったプログラミングパラダイムへの深い洞察と理解だ。そしてそこから優れたアーキテクチャが生まれる。
これらのスキルや知識は、必要に迫られてのコードリーディングや、ペアプロなどによるスキルトランスファーといった、OJTでも獲得できる。しかしここにOFF JTを加えることで、その効果はより高められる。良い意味で意識の高いチームは、技術書の読書会を定期的に開いたり、技術研修に参加したり、LT大会でチーム内外の知識の共有を促進している。
ソフトウェア開発組織は、日々のソフトウェアデリバリ業務に忙殺されがちだ。実務外のこのような取り組みはなかなか導入しづらいだろう。しかし、だからこそスキル向上に力を入れられたならば、「差異化」につながるのだ。
組織を動かすのは人である
「組織は戦略に従う」とは言ったものの、組織を動かすのは人である。彼らは、戦略やミッションに理解と共感を示し、誇りを持って業務を遂行できているだろうか。こういった従業員エンゲージメントは、その高さがパフォーマンスに影響を及ぼす。
従業員エンゲージメントはeNPSで定点観測可能であるが、そのスコアの上下が何に起因しているか正確に分析することは難しい。その深層を1on1を通して汲み上げようと試みるも、対策可能なほどに具体的な問題にまで焦点を絞り込むことがなかなかできない。そもそもeNPSの被観測者本人でさえ明確には理由が答えられないからだ。
マネージャーがコーチングスキルを高めていけば解決しそうではあるが、これは結局、1on1やコーチングをマネージャーによる情報収集の手段としている点で適切なアプローチとは言い難い。そもそも、マネージャーが問題を把握し、施策を展開するより、チームで話し合って問題解決に取り組む方が実情に即したものになりやすく、達成感も得られやすいのではないだろうか。それこそが自律的な組織ではないか。マネージャーとして、そこでチームから出てくる相談に協力は惜しまない。
ジェフ・サザーランド（Jeff Sutherland）が、チームによる「幸福度の計測」と呼ぶ手法を著書『スクラム』で紹介している。チームがスプリントレトロスペクティブの度に「どうしたらより幸せになれるか、満足できるか」を問う3つの質問にメンバー全員が答え、チーム全体で改善に取り組むというものだ。これを続けて幸福度を上げていくことでベロシティが3倍になったと言う。
また彼は、チームのメンバーを実際に幸せにする要素とは、主体性、スキルアップ、目的意識だと断言している。さらにこれらをそれぞれ「自分の運命を自分でコントロールできること」「何かについて自分が上達しているという実感」「自分より大きな何かに力を尽くしているという感覚」と言い換えている。エンジニア経験があれば、この言葉に共感できるのではないだろうか。これらの価値を尊重し、チームが自己組織化していく文化の醸成にこそ、マネージャーは力を尽くしたい。
戦略やミッションへの理解と共感は、目的意識を醸成するだろう。それが、組織構造とプロセスの本質を捉えた行動や判断につながる。実践に基づくプロダクトナレッジとプロジェクトナレッジの獲得や、学びの文化は、スキルアップとなってデリバリパフォーマンスを向上させる。チームによる幸福度の計測は、主体性を高め、チームを自己組織化させる。
「成功への再現性」という点では、人材育成や組織内の流動性も欠かせない。人の価値観は変わりくいからだ。長期間、顔ぶれが変わらず役割が固定化した組織は、価値観が固定して新しいものを生み出しにくくなる。属人化も起きるだろう。だからこそ新しい世代の台頭や、新たな文化の流入が必要だ。このサイクルには、我々のようなマネージャーも含まれている。
こうして絶え間ない進化を続ける組織こそ、「プロダクト開発能力の差異化」を手にする組織なのだ。
