自己組織化とは、雪の結晶などにみられるように、個々の物質の振る舞いが、結果として秩序立った大きな構造を生成する現象を表す言葉として用いられています。これが、人の場合、個々の自律的な行動によって、チーム全体としての成果を成し遂げる状態を表します。組織形態の学習を進めていくと、フラット型組織、アメーバ型組織、自律分散型組織など類似の組織形態がありますが、いずれの形態も、目標に向けて参加者各々が状況判断し行動して目標を達成することを目指すことでは、自己組織化と共通した考えです（図4の右側）。自己組織的なチームの強みは、想定になかった事案や状況に直面した場合に、チームメンバーが早期に判断し、対策を講じることができるようになり、チーム全体での俊敏性が向上することにあります。
図4 – これまでのチーム形態と自己組織的なチーム
各自が状況判断し行動するには、どのような環境をつくる必要があるのでしょうか。各種の組織論などから総合的に勘案すると、「目標設定」「情報開示」「権限移譲」が主に大切であることが分かります。目標設定は、各自で判断は行うとしても、複数のチームメンバーが同じ方向に向かって進むために必要な指標となります。情報開示は、その判断に必要な材料となります。正確な判断を行うには、十分な情報をチームメンバーがすぐに手に入る状態になっていることが必要です。各自が持っている情報や状況を共有し合うことも必要です。また、権限移譲は、実行する上で許可がないと行動できない事項を可能な限り減らします。
チームの自律性と組織が定める規定やルールはトレードオフの関係にあり、やみくもに前者を優先すればいいということではありません。ただし、チームの活動の妨げとなる規定やルールがある場合には、ステークホルダーと協議し、両者のバランスを見直すことが重要です。また、チームは適度なセレモニーを通して繰り返し成果をステークホルダーへ提示することを通じ、両者のバランスを継続的に最適化します。
これまでのチーム組成の考え方では、チームを構成した場合に、管理者（マネジメント）を立てて、その管理者の指示のもとにチームメンバーが動き、状況などの情報も管理者に集中して管理されるといった具合の構図が一般的でした（図4の左側）。これまでのチーム構成でも十分に機能しているという組織もあるでしょう。しかしながら、よく陥る現場の状況としては、管理者が不在の時に、チーム全体の状況を誰も把握できておらず、結局管理者が戻るのを待つといった状態があります。
管理者の不在が数時間程度であれば大きな問題とはならないかもしれませんが、不慮の事故や予期せぬ病欠などで引継ぎが出来ないまま長期の離脱となった場合には、代わりの管理者を立てるなど、チームの状況把握や正常に行動できるようになるまでに時間がかかることがあります。新型コロナウイルス禍の状況においても、急な病欠などに見舞われ、類似の状況を経験された読者も多いのではないかと思います。
一方で、自己組織的なチームを組成することは、危機管理の観点からも、人依存になりにくく、チームのメンバーが意図せず不在となった場合でも、残っているメンバーで対応し解消できるため、強固なチームが構築できるのです。
「ふりかえり」を通じて成長するチーム
前述した「ふりかえり」では、開発サイクルで上手くいったこと、上手くいかなかったことをチームメンバー同士で洗い出し、上手くいかなかったことについては、次回の開発サイクルに向けての対応策を検討します。開発に直接関わる事項だけでなく、日々のチーム運営やコミュニケーション方法なども題材にして、チームとしてさらに効果的にパフォーマンスを発揮するための施策を、チームメンバー全員で話し合って決めていきます。
対応策の中には、技術的な対策のほかに、ルール作りや考え方の指針なども含まれ、そのチームの実情に合った行動様式としてチームの中で醸成し徹底されていきます。この蓄積された行動様式が、個人に判断を委ねることが多い自己組織的なチームであっても、雪の結晶にみられるように、秩序立って目標に向け行動し、チーム全体として力を発揮する礎となるのです。このふりかえりが数週間ごとに行われるため、チームの能力と秩序がおのずと向上していく好循環を生み出します。
従来の開発でも、ふりかえりの機会を設ける組織もあるでしょう。ただし、従来の場合は、開発プロジェクトのクロージングの際に実施されることが多く、プロジェクトの途中で発生していた困難な事項などは、時間が経過しすぎていて思い出せない場合も多々あります。加えて、ふりかえりで反省点や改善策を得られたとしても、クロージングの時期のため、その開発プロジェクトに生かされることはありません。後続のプロジェクトで生かされればまだ良いですが、生かされることなく忘却されることもあります。
このように、ふりかえりが遅くなるほど、成長する機会も失われます。アジャイル開発に限らず、数週間ごとにふりかえりの機会を設けることは可能です。このため、開発期間の最中に、忙しい状況であったとしても、ふりかえりの頻度を増やし、改善を都度行うことでチームやプロジェクト全体の能力を高められれば、その開発は成功に近づくことになるのです。
- 岡本 修治（おかもと・しゅうじ）
- KPMGコンサルティング Technology Strategy & Architecture シニアマネジャー
- 外資系総合ITベンダーにおいて大規模SI開発をはじめ、ソフトウェア開発プロセス／ツール展開のグローバルチーム、コンサルティング部門などを経て現職。金融、製造、情報通信など業界を問わずITソリューション選定、開発プロセスのアセスメント（評価）と改善、BPR支援などさまざまな経験を有し、中でも不確実性の時代と親和性が高いアジャイルトランスフォーメーションを通じた意識改革、開発組織の能力向上支援をライフワークとし注力している。
- 新田 明広（にった・あきひろ）
- KPMGコンサルティング Technology Strategy & Architecture マネジャー
- SEからキャリアを始め、金融、公共、小売りなど幅広く業界を担当し、主に基幹系システムの刷新に携わる。新規事業のプロダクト開発では、ビジネス環境の急速な変化に対応するため、アジャイル開発とデザイン思考を活用し実践。これらの経験を基に、企業のアジリティを高める顧客起点の価値提供を志向したシステム開発手法の推進に取り組んでいる。
