社会工学的学習で依存関係を効果的に解消する方法

組織は、継続的な発見と価値の提供を通じた持続可能なイノベーションを推進するために、迅速に行動し、顧客からの絶え間ないフィードバックを受け取る必要があります。しかし、そこには問題があります。それが依存関係です。

依存関係は知識のギャップ

Michael James 氏によると、ソフトウェア開発のようなナレッジワーク（知識労働）における依存関係は、物理法則ではなく、知識（ナレッジ）のギャップによって引き起こされるといいます。

確かに、「靴下を履いてから靴を履く」ということは、ナレッジワークには当てはまりません。例えば、第1章の内容を知っていれば、第2章から書籍を書き始めることもできます。知識の創造は、物理的な依存関係ではなく、知識を発見し、創造する能力によってのみ制約されています。

要求が曖昧でプロダクトオーナーが不在の場合、スキーマの変更をするためにデータベース管理者からの指導が必要な場合、開発環境が提供されてからでないと開発を開始できない場合、他のチームによる API の変更が完了してからでないと作業を続行できない場合、変更審査委員会が先に変更を承認する必要がありプロダクトバックログアイテム（PBI）を完了できない場合などがあります。これらは、チームの物理的な依存関係ではなく、単に知識不足が原因である依存関係なのです。

知識のギャップの原因は何でしょうか？それらは本質的に存在するものでしょうか、それとも組織の中で時間をかけて発生しているものでしょうか？誰がその創造に責任を持っているのでしょうか？

依存関係の管理では依存関係は解決しない

ソフトウェア開発における進捗というのは、ソフトウェアの提供を通じてのみ具体的になるものです。フィードバックがなければ、ソフトウェア開発の進捗は、組織からは見えないのです。マネージャーは、このコントロールの喪失に対して、分割統治によって対抗しようとしているのです。

要求が不明確な場合、要求エンジニアは、顧客のニーズをチームに引き渡す前に、文書化する必要があります。テストにおいて問題が次々に発生した場合、チーム間でのテスト活動を調整するためにテストマネージャーを連れてくる必要があります。品質に対して問題がある場合、別途、品質管理部門を設置し、チームの作業を検証し、要求に適合しているならば承認を行います。チームが単独で仕事をする能力を奪い取れれてしまった場合、チームは作業を他の人に引き継がなければなりません。それがチームの依存性を高めることになります。マネージャーは、新しい部門や、ユニット、チーム、調整役を作ることで、専門性と部門を強化しようとします。部門が増えると、依存関係も増えていきます。

一方で、依存関係を知識のギャップとして理解すると、依存関係を管理しても改善が望めないことがわかります。知識は、共有したり、移動させたり、並べたりすることができないのです。知識は、欠けているところを発見して、創造していくしかないのです。

組織はどのようにして知識のギャップを発見することができるのでしょうか？

リファインメントにより知識のギャップを顕在化する

スクラムチームは、知識のギャップを明らかにするためにリファインメントを用います。リファインメントは、チームが次の作業について定期的に議論をすることで、知識のギャップを継続的に発見するのに役に立ちます。複数のスクラムチームが単一のプロダクトで一緒に作業している場合、チームの境界線を超えて知識のギャップを常に確認するために、クロスチームリファインメントが有効であることがわかっています。

依存関係を明らかにした上で、すべての依存関係を考慮した実行順序を見つけることはできますか？

組織は、依存関係を前もって詳細に予測して、チームの作業を計画しようという危険な道を歩むことになるのです。

Nick Tune 氏は、この道の終わりには滝（ウォーターフォール）があると表現しています。深い先読みは、スケールド アジャイルのフレームワークの核心をなすものです。深い先読みの先には滝（ウォーターフォール）があるのです。深い先読みは、水道の蛇口のようなもので、プロセスを何と呼ぼうとも、蛇口をひねればひねるほど、滝（ウォーターフォール）に近づいていくのです。

（プロダクト開発を行っているような）絶えず変化する環境では、上述のような組織は、変化に迅速に対応するという競争優位性を失っていきます。

では、どのようにして知識のギャップを埋めることができるのでしょうか？

チームメンバーがチーム間での協働したり、作業を他のチームに再配置したり、PBI を再配分したり、あるいは、特定のフィーチャーだけを担当させたりといった方法で、短期的には特定の知識のギャップを解消することができます。

この短期的な考え方には代償を伴います。つまり、プロダクトオーナーは、最大の価値を提供しそうなものに基づいてプロダクバックログを並べ替えることができなくなってしまうのです。この考え方は、アジリティの核心である機会的な価値の発見を組織から奪ってしまっているのです。

だからこそ、組織がプロダクトオーナーの意思決定能力を制限することなく、長期的に知識のギャップを埋めていく必要があるのです。どんな方法があるでしょうか？

社会工学的学習とは知識のギャップを持続的に解消することである

知識のギャップを解消できるのは、学習だけです。組織的な状況における学習は、社会工学的な活動なのです。ここでは、人同士やチームの協働や、開発プラクティスの進化などを単独で考えることができません。共存しているからです。むしろ、組織をさらに分断するのではなく、チーム間の技術的、組織的な障壁を絶えず取り除いていき、チーム間の依存関係に対処することで、適応力のある組織を作ることに注力すべきなのです。

社会工学的学習はどのように実施されるのでしょうか？観察してきた経験から、あらゆる規模の組織の中で、次のような実践手法がよく取られていると考えています。

インナーソーシング

「チームA」の作業で、「チームB」が所有するコードに変更を求めたい場合、「チームB」には他にもっと優先すべき作業があることで「チームA」の作業はブロックされてしまいます。そこで、「チームA」が「チームB」が所有するコードに対して変更を行い、プルリクエストをすることができます。組織内のオープンソース化は、「インナーソーシング」と呼ばれ、オープンな協働と自己管理による作業を基本としたアプローチです。チームの境界線を超えた協働を可能にします。

コードでの対話

チームは、継続的インテグレーション（CI）を採用しており、それぞれの開発者はすべてのコードを中央のリポジトリにチェックイン（コミット）します。誰もが1日に数回リポジトリと同期をとり、他の人が行ったすべての変更を把握することができます。コードに更新があった後、それぞれの開発者は、他の開発者の変更内容に目を通すことができ、自分たちが何に取り組んでいるかを把握することができるのです。一方、ブランチは統合を遅らせます。結果的に、知識の集中的な共有を妨げるのでブランチは避けるべきです。

コンポーネントプラクティスコミュニティ

「チームA」と「チームB」が同じコードコンポーネントで同時に作業している場合、「チームA」と「チームB」はお互いのことを知っていて、質問をしたり、お互いのコード変更を確認したりする必要があります。コンポーネントのプラクティスコミュニティは、メーリングリストやチャット、不定期のミーティング、その他のチャネルを通じて、コミュニケーションを促進するのに役に立ちます。これらのコミュニティは、通常はチームメンバーでありながら、他のチームの発展に合わせてメンターとしての役割も担うようなコンポーネントメンターによって組織化されます。コンポーネントメンターは、コンポーネントの変更を承認するのではなく、デザインワークショップやコートレビュー、実装に関する質問の窓口として開発者を支援するのです。このようなメンターシップによって、組織内での知識の流通を促進していきます。

組織全体でのペアプログラミング

多くの形式のペアプログラミングは、恩恵が多くあります。例えば、「チームA」と「チームB」の間に依存関係が見られる場合、「チームA」のメンバーは、一時的に「チームB」のメンバーと緊密に連携して、協働で問題を解決して、お互いに学び合うことができるのです。深刻な問題に対してのみ共同作業で解決するのではなく、チームの境界線を超えて、多くの組織でペアプログラミングで開発できる状況になっています。そこでは、開発者は全社的なカレンダーに登録をして、ペアプログラミングセッションのパートナーを探すことができます。このプラクティスによって、組織全体の開発者同士の継続的な知識の構築と交換が促進されます。

チームローテーション

「チームA」のメンバーのひとりが、「チームB」に、「チームB」のメンバーのひとりが「チームA」に、それぞれ定期的にローテーションするのが、チームローテーションです。定期的なローテーションを行うことで、全体像を把握することができ、個人のスキルを向上させ、ひいては、チーム全体のスキルアップに繋がります。経験上では、2〜3ヶ月ごとにそれぞれのチームで少なくともひとりが交代することが望ましいです。このインサイトは、Heidi Helfand 氏が「Dynamic Reteaming」で紹介している事例とも一致しています。チーム間の依存関係が生じた場合、他のチームのシステムに関する知識と強化された個人的な関係性により、共同作業の初期段階で起こり得る知識のギャップや軋轢を減らすのに役立ちます。

組織全体での学習で依存関係を解消

みなさんのチームは依存関係とそれによる遅延に悩まされていませんか？プロダクトオーナーは、価値を最大化するためにプロダクトバックログを並べ替えることができなくなっていませんか？

この記事から得られる直感に反するインサイトは、管理を強化しても依存関係が解消できるわけでなく、むしろ依存関係が増えていくということです！

さらに多くの依存関係を作るには、依存関係管理によって組織をさらに分割していくことなのです。したがって、社会工学的学習のための環境を作ることが望ましいのです。学習する組織とは、ひとりひとりが学び、その知識を他の人たちに伝えていることを意味しているのです。長い目で見れば、依存関係を解消する方法は、組織全体の学習に注力するということです。