『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』

訳出が待望されていた『Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン』が刊行されたので、さっそく購入して読みました。

この本は、ひとことでいうと組織変革を試みるひとへの手引です。組織には歴史や慣性などもあって、ただ意欲のまま無手勝流に変革に臨んだところで、きっとうまくいかないことでしょう。そこで、先人の知恵を集積したものとして紹介されるのがパターンです。プログラマにとってのデザインパターンが、ソフトウェア設計という困難な仕事に道標を与えるように、この本で紹介されているパターンたちもまた、組織変革にとって役立つことでしょう。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

原書は2005年刊行。それを一昨年あたりにひと通り読んではいました。当時はあまりピンときていない面もあったのですが、今回あらためて訳書を読んでいる中で、これまで自分でもあれこれとやってきたことに知らず知らずのうちに反映されていたのだなあという思いがしました。以下に、我々の実例を本書に掲載されているパターンに沿って記述してみます。あれこれと僕の感想を書くよりも、そうした方がこの本がどういう本であるかという説明にもなるだろうからです。

本書のパターンに基づく実例の記述

一昨年、技術的問題はもとより、プロセスをも改善する必要があると考えた僕と@hsbtさん[エバンジェリスト(1), 相談できる同志(39)(以下、「パターン名(番号)」という本書の記法にならって記述)]は、スクラムの導入を検討し始めました。とはいえいきなりまるっと導入するわけにもいかないので、いくつかの方法を試してみることにしました[ステップバイステップ(3)]。

まずは、ちょうど折よくスクラム関連の本が3冊刊行されたので、「これはとにかくいい本だから読むべきである」と社内で、いろいろな職種の人々に向けていってまわりました[種をまく(22)]。また、いくつかの大きなプロジェクトが完了するタイミングに乗じて、スクラムの提供するイベントの内「ふりかえり」をまずは一部のチームに導入する手伝いをしました[ふりかえりの時間(5), やってみる(17), 便乗(21)]。

そんな感じでちょこちょことやってはいたものの、なかなかそれ以上に導入できないでいたところ、あるチームでとても大きな問題が起きました。そのチームのマネジャーたちは、二度とそのようなことのないよう、根本的にプロセスを見直す必要を感じました。彼らはスクラムの本を読み、それが使えるのではないかと考えました。そこで我々とともにスクラムの導入を始めたのです[適切な時期(23), アーリーアダプター(11)]。

手応えを感じ始めた我々は、スクラムをもっと広く普及させたいと思いました[小さな成功(2)]。そんな折、スクラム本を読み感銘を覚えた人事部長[コネクター(8)]が、予算面・運用面で我々をバックアップしてくれるようになりました。また、我々の部署はもともと社長直轄部署であり、そうした活動は承認の元で行いつつ、定期的にレポーティングしていました[経営層の支持者(28), 正式な推進担当者(29), 定期的な連絡(24)]。

普及へ向けて、いくつかの研修を行いました。まずは、@hsbtさんの元職場の永和システムマネジメントさんに研修を行っていただきました[外部のお墨付き(12)]。その際、現場だけでなく、管理者層にも熱意を届けるために、平鍋健児さんによる講演をお願いしました[著名人を招く(27)]。講演の前段として、社長からも参加者に向けてメッセージを送っていただきました[経営層の支持者(28), 謁見(38)]。平鍋さんの講演の効果は絶大でした。次の日から、あちこちの部署でカンバン立ち並ぶようになりました[アーリーマジョリティ(30)]。

次に、スクラムそのものへの理解をより広い人々に深めてもらうために、LEGO®を使ったスクラム研修（レゴスクラム） | Doorkeeperで学んだ内容を元に、我々はレゴスクラム研修を行いました[勉強会(25)]。全部で10回ほど行って、最終的にはほとんどの社員が参加してくれました[みんなを巻き込む(33)]。また、永和さんに実際に現場に入っていただいて、チームの話をインタビューしたり[予備調査(4)]、実践しているプロセスをよりよいものに改善するためのアドバイスをいただいたりしました[達人を味方に(14)]。また、永和さんだけではなく、既にスクラムを実践しているチームのスクラムマスターも、新たにスクラムを始めるチームへの研修に参加してもらうようにしました[橋渡し役(43)]。

そんなこんなで導入・普及は進みつつあった折、スクラムがうまく回るようになってきたチームから、だんだんマンネリ化しつつあるという相談を受けました。ここで立ち止まっては元の木阿弥です。なんとかしなければなりません[勢いの持続(41)]。そこで、これまでとは違う方法を試みました。我々は基本的には外部からのお手伝いとして関わってきましたが、チームにもっと深く入り込んでひとりひとりと密にコミュニケーションを始めました[個人的な接触(20)]。

特に意欲のあるメンバーといっしょに、大きめの機能開発を行いました[メンター(37)]。プロジェクトが上首尾に終わったため、いつもとは少し異なるふりかえりを行いました[成功の匂い(40), ふりかえりの時間(5)]。それは「組織パターンを実践する」で書いた通り、プロジェクトからパターンを見出すというものでした。見出したパターンのいくつかには、そのチーム固有の名前がつけられ、いまも増え続け、活用されています[グループのアイデンティティ(13)]。

年の瀬に近づいた頃、各チームのスクラムマスターたちがこれまでの活動をふりかえるために、イベントを開催することにしました。その際、スクラムマスターたちだけではなく、スクラムを導入していないチームも含むマネジャー全員にも参加してもらうことにしました[体験談の共有(32), 懐疑派代表(44)]。年明け以降、さらに別のチームや経営陣からも、導入支援の依頼等の引き合いがきています。よりよい組織になり、ひいては業績を上げ成長していくために、これからも改善を続けていきます。

補足

上記は、もちろん実例のすべてではありません。たとえば、上で最初にスクラムを導入したチームとして登場したチームは、プロセスや掲示物を継続的に工夫し[テーラーメイド(26)]、そのことでうまくチームビルディングができているいい例です[グループのアイデンティティ(13)]。そのあたりの詳細は、先日刊行された「WEB+DB PRESS Vol.78」に書かれています[外部のお墨付き(12)]ので、そちらも合わせてお読みいただけると幸いです。

また、本書にもたびたび登場するジム・コープリエン氏らによる『組織パターン』もあわせて読まれると、「パターン」というものに対する理解がより深まり、ひいてはよりよい実践につながるのではないかと思います[達人を味方に(14)]。

WEB+DB PRESS Vol.78

組織パターン