「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想～エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集

「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んだ感想をラフなメモ書き。

【参考】
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン一覧: プログラマの思索

「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」予約開始 - Yasuo's Notebook

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

Fearless Changeアジャイルに効く アイデアを組織に広めるための48のパターンを熟読中 - 未来のいつか/hyoshiokの日記

【1】背景、動機

自分が新しいツール、新しいプロセスを導入したい時、うまくいく場合とうまくいかない場合がある。
例えば、Redmineによるチケット駆動開発を導入したい時、あるいは、アジャイル開発を導入したい時、その結果は、やり方に応じて失敗する時もある。

僕はRedmineのエバンジェリストと思われる時が多く、Redmineの導入によってプロジェクト支援を期待される役割が多い。
僕は過去の経験から、アジャイル開発へ発展させるパターン・アンチパターンを貯めてきたので、どのプロジェクトもそれなりに成功してきたと思っている。
でも、他の人が同様に成功するとは限らないだろう。

2000年代前半、XPユーザグループでは、XPを通じたアジャイル開発をいかに現場に導入するか、という事例とノウハウの議論がたくさん行われた。
実情は、アジャイル開発は日本のSIに導入しづらい、という苦労話ばかりで、たくさんの失敗例ばかりだった。
でも、Scrumが世界で普及し始めた後を追うように、日本でもScrumをベースにしたアジャイル開発の成功事例が少しずつ増えてきているように思う。

「アジャイルに効く アイデアを組織に広めるための48のパターン」は、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストが、そのアイデアを組織へ導入するためのノウハウ集だ。
この本の内容をもっと以前に知っていたら、僕もこのテクニックを使って、もっと容易にRedmineを導入できただろうと思った。

アジャイル開発を実際の現場に導入したいと思う人がいるなら、まずは「アジャイルに効く アイデアを組織に広めるための48のパターン」を読んで、どのように組織へ展開すべきか、構想を巡らすと成功率が高まるだろう。

【2】「アジャイルに効く アイデアを組織に広めるための48のパターン」を適用できる状況

「アジャイルに効く アイデアを組織に広めるための48のパターン」のアイデアは、新しいアイデアを持ち、そのアイデアに熱意を持っているエバンジェリストだけでなく、次の人達にも使えると思う。

(1)PMOや品質管理部(SEPG)の立場で、個別プロジェクトや組織を支援する人達

PMOやSEPGは、普通は火消し役でプロジェクトを支援する立場が多い。
すると、火を噴いているプロジェクトで既に作業しているメンバーやリーダーが、実は抵抗勢力になってしまう場合もある。
現場の問題点を把握せずに、頭ごなしの命令や作業指示をいきなり実施すると、反発されてしまうのだ。

(2)プロジェクトリーダーとして、新しいツールや新しいプロセスを導入したいと考える人達

新しもの好きなアーリーアダプター、イノベーターの精神を持つプロジェクトリーダーは、新しい案件で新しいツールやプロセスを試したくなる場合がある。
新しい技術を試して、新しいノウハウを得たいのだ。
でも、メンバーが新しい技術に付いていけなかったり、上司が予算やコストを理由に圧力をかけてくる時もある。

(3)業務改善のためのシステム提案、要件定義を行う人達

SIがシステムを提案する場合、ユーザ企業にシステムを導入するだけでなく、ユーザ企業の業務プロセスも変わってしまうことも合わせて提案する時が多い。
業務のIT化とは本来、今まで労働集約的だった作業を自動化して、人減らしに使う一つの手法だから。
すると、ユーザ企業の組織構造も変わる事になり、従来の仕事を持つ人達は役割が変わるだけでなく、権限が廃止される場合もあるので、抵抗勢力になってしまう時がある。

【3】プラクティスをパターンとしてまとめる意義

「アジャイルに効く アイデアを組織に広めるための48のパターン」が優れている点の一つは、エバンジェリストが使えるような道具として、パターン形式でまとめていることだ。
パターン形式なので、どんな状況でどんな問題に対してどんな解決策を実施すればよいか、が明確に理解しやすい。
また、パターンの概念はパターン名で名前付けられているので、会話の中でパターン名を呼ぶだけで、その背景や問題意識、パターンを適用した効果についても、他人と共有できる利点がある。

欧米人が日本人よりも優れている点は、PMBOKやCMMIのように、既に知られている経験知を知識体系として抽象的に普遍的な概念としてまとめる能力がある点だと思う。
関西IT勉強会でも、谷島さんが同じようにことを指摘されていた。

過去から今までの日本人も、プロジェクト管理や開発プロセスについて、たくさんの経験を持っているし、たくさんの書籍も出している。
しかし、それらの知識はバラバラであり、他人が使えるような知識や概念になっていない。
そもそも、それらの概念に名前が付けられていないので、他人との会話で流通できるような普遍性を持っていない時が多い。

パターンの良い点は、BOKのような知識体系よりも、帰納的であり、たくさんの経験を元に普遍化されているので、理解しやすい点にあるだろう。

僕は、パターン言語というアイデアが好きだ。
パターン形式で自分の体験に基づくプラクティスを作り出せるし、そのパターンを他人に広めやすくしてくれる。

パターン、Wiki、XPは良書: プログラマの思索

パターン言語のアイデア: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

「アジャイルに効く アイデアを組織に広めるための48のパターン」でパターンに関する興味深い指摘がある。
P.16の「パターンの利用方法」に「初めてパターンを読んだ人は、情報が多すぎると感じるかもしれない」という指摘がある。
つまり、パターン形式には、状況・問題・解決策の3つで十分で、フォースや結果状況、使用例は不要ではないか、ということだ。

しかし、実際にグループでパターン化する議論をしていると、すぐに暗礁に乗りかかった。
ある解決策を用いた時に、副作用として発生する問題はどこに描くのか？
パターンの前提条件となる制約条件はどこに書くのか？
という質問がどんどん出てきた。

ほどなくして、結局、フォースや結果状況などの全てのパターン項目が追加された。
「問題解決に向けて議論していくと、いずれ全てのパターン項目が必要になることを、まさに目の当たりにした」という。

この逸話はとても重要な内容を示唆していると思う。
つまり、アレグザンダーのパターン項目は、単なる思いつきで作られたパラメータではなく、パターンを語る時に必然的に出てくるパラメータなのだ、ということだ。

そして、パターン項目のうち「フォース」がかなり重要であると、最近思うようになった。
以下にもその理由が書かれている。

パターンとフォースとぎゃー！ - 反言子

(引用開始)
8. フォースが問題を定義する
形式上、問題がまず初めに来るので、作者は時折、解法を書く前に問題を記述する。
だが、これもまた問題を含んでいる。
解法をよく理解しないままに、問題を衝動的に記述する。
しかし、作者が解法について詳細に考え抜かない限り、そのような問題の記述はあいまいで、非常に大雑把なもになりがちだ。

問題と解決の結びつきが重要であることはわかっている。
僕はこの手の話が好きなので「問題こそ重要である」という考え方にはなじんでいる。
しかし問題を定義することは難しい。
なるほど、解法がわからない、衝動的に考えられた問題なのだ。

ゆえに問題を記述するためにフォース、そして問題とフォースの関係を考え抜くことが重要になる。
パターンが単なるマニュアルでない理由としてフォースの存在が語れることにも納得がいった。
(引用終了)

【4】各パターンのメモ

「アジャイルに効く アイデアを組織に広めるための48のパターン」の各パターンを読むと、ああそういう意味だったのだな、と経験が整理される気がする。
以下、本の文章を踏まえて、自分の理解と体験を踏まえてメモしてみる。

◆全体に関わるパターン

(1)Evangelist : エバンジェリスト(1)
新しいアイデアを持ち、熱意を持って普及させたいと思う人。

(2)Small Successes : 小さな成功(2)
チームに小さな成功を植えつけて、意気を上げる。
チケット駆動開発なら、完了したチケットが必ず記録されるので、後から自分の実績をふりかえれば自信になる。

(3)Step by Step : ステップバイステップ(3)
トップダウンで一気にやらない。
ボトムアップで少しずつ広めていく。
お試し期間(47)や便乗(21)を使う。

Redmineによるチケット駆動開発は、ステップバイステップで実行しやすい。
運用しながら、ワークフローを修正したり、チケットの項目を追加したり、運用ルールを変えていくことは柔軟に可能。

(4)Test the Waters : 予備調査(4)
あなたは新しいアイデアに興奮して、エバンジェリストになりたいが、新しいアイデアが組織に合うかどうかまだ分からない時に使う。

(5)Time for Reflection : ふりかえりの時間(5)
定期的に評価し、フィードバックを得る。

「なぜ、ふりかえりが必須なのか、自明ではないかもしれない」。
しかし「走りながら考えればいい、経験からの学びは無意識のうちに積み重ねられていく」という考え方は、現実にはうまくいかない。
定期的に活動を評価し、学びの機会を作らなければ、同じような間違いを何度も繰り返す。

◆序盤の活動に関わるパターン

(6)Ask for Help : 協力を求める(6)

(7)Brown Bag : ブラウンバッグ・ミーティング(7)
ランチミーティングのこと。
日本なら、ノミニュケーションに相当するだろうか。

(8)Connector : コネクター(8)
(9)Do Food : 何か食べながら(9)
(10)e-Forum : 電子フォーラム(10)

(11)Early Adopter : アーリーアダプター(11)
新しいアイデアのオピニオンリーダーになりうる人々。

(12)External Validation : 外部のお墨付き(12)

(13)Group Identity : グループのアイデンティティ(13)
チームや活動に名前をつけること。
例えば、@daipresentsさんは自分のチームに「特攻野郎Aチーム」という名前をつけていたのを思い出す。
また、スティーブ・ジョブズも、Macチームに海賊の旗を掲げていた。

(14)Guru on Your Side : 達人を味方に(14)
組織のメンバーに尊敬されているシニアレベルの人々を味方にする。

(15)In Your Space : 空間を演出する(15)
「見える化」のこと。

(16)Innovator : イノベーター(16)
新しもの好きの同僚。
新しいというだけで好奇心をそそられ、興奮する人々。

(17)Just Do It : やってみる(17)
新しいアイデアの利点や限界は、自分自身の経験から情報を集める。
自分が今やっている仕事にそのアイデアを試して、評価してみる。

(18)Just Say Thanks : 感謝を伝える(18)
協力してくれた人々に感謝の気持を伝える。

僕が過去にKPTによるふりかえりを実施した時、女性SEや女性PGから、Keep欄に、他メンバーに感謝の気持を伝えるPostItが貼られた時がある。
感謝された人はさぞかし嬉しかっただろうと思う。
そんな表現だけでも、チームは和むし、一体感が高まる。

(19)Next Steps : 次のアクション(19)
アイデアをToDoリストに落とすこと。

(20)Personal Touch : 個人的な接触(20)
新しいアイデアの価値を伝えるために、技術的な利点よりも、個人や組織のニーズを理解する。

(21)Piggyback : 便乗(21)
自分のアイデアを既存の慣習に追加機能として載せることで、コストやリソースを減らす。
新しい取り組みよりも、改善として導入する。

Redmineによるチケット駆動開発では、普通、現場の作業ルールをそのままワークフローに当てはめて、運用を開始する。
つまり、AsIsのワークフローから開始して、少しずつ改修しながら、あるべき姿(ToBe)のワークフローへ変えていく。

(22)Plant the Seeds : 種をまく(22)
勝間和代氏が提唱している「Giveの5乗」と同じ。

(23)The Right Time : 適切な時期(23)
イベントの時期や助けを求める時は、タイミングを考慮する。

アジャイル開発では、イテレーションごとに、ふりかえりでフィードバックを得たり、次のアクションを考えるタイミングが取りやすい。
しかし、WF型開発は、実際は、ふりかえりや改善実施のタイミングが取りにくい。
なぜなら、工程単位に前工程のふりかえりやそれをうけた対策を考えたいが、普通は仕様変更や五月雨式のWF開発が多いので、メンバーが常に忙しく、まとまった時間を取るのが非常に難しいから。
結局、プロジェクト完了時の1回だけしか、ふりかえりが行われず、チームが解散するために、せっかく得られた知見や改善案も生かされない。

(24)Stay in Touch : 定期的な連絡(24)
(25)Study Group : 勉強会(25)

(26)Tailor Made : テイラーメイド(26)
新しいアイデアを採用する時、組織のプロセスとゴールを事前調査して、イノベーションが解決できるニーズや問題に適用する。

(27)Big Jolt : 著名人を招く(27)
今なら、アジャイル開発の有名人やアジャイルコーチを呼んで、組織変革を支援してもらうようにする。

◆中盤以降の活動に関わるパターン

(28)Corporate Angel : 経営層の支持者(28)

(29)Dedicated Champion : 正式な推進担当者(29)
組織で認められて、予算と権限を与えられたエバンジェリスト。
新しいアイデアの組織導入を効果的に進めたいなら、ボランティア活動だけでは身が重い。

(30)Early Majority : アーリーマジョリティ(30)
組織内に強力な足場を構築してくれる「より慎重なマジョリティ」。
門番(ゲートキーパー)であるイノベーターやアーリーアダプターだけでは、組織変革は不十分。

(31)Guru Review : 達人のレビュー(31)
組織のメンバーに尊敬されているシニアレベルの人々によるレビューチームを作り、新しいアイデアを評価してもらい、他の聴衆に影響させる。

(32)Hometown Story : 体験談の共有(32)
新しいアイデアの有用性を体験談で共有し、形式知として表出化する。
体験談という暗黙知の共有。
SECIモデルの一例。

僕の現場では、KPTによるふりかえりで、成功や失敗の体験談を共有する場合が多い。

(33)Involve Everyone : みんなを巻き込む(33)
イノベーションが一人の人や小さい集団のためだけではなく、組織全体のためにある。
より多くの人に新しいアイデアを「自分ごと」として認識してもらう。
それによって、心から取り組んでくれるだけでなく、貢献したいという力強い感情を生み出し、組織と個人のつながりも強化する。

(34)Just Enough : ちょうど十分(34)
新しいアイデアを学んでもらうには、学習曲線を考慮する。
段階を経て正しく理解してもらう。

Redmineによるチケット駆動開発では、運用ルールを1回説明すれば、その後は細かい説明は不要で運用できる利点がある。

(35)Local Sponsor : 身近な支援者(35)
現場のマネージャに協力を求める。
経営層や下々の人々よりも、中間層のマネジメント職の支援があってこそ、新しいアイデアは現場での仕事のやり方として正式に認められる。
パトロンに近い。
実は、プロジェクトリーダーやプロジェクトマネージャが、組織変革の抵抗勢力になってしまう場合が多い。

(36)Location, Location, Location : 場所重要(36)
半日以上かかるイベントは、仕事の現場を離れて、別の場所で開催する。

(37)Mentor : メンター(37)
新しいアイデアを理解して、チームを手助けできる人。
守護者、ファイアーウォールに近い。

(38)Royal Audience : 謁見(38)
(39)Shoulder to Cry On : 相談できる同志(39)

(40)Smell of Success : 成功の匂い(40)
新しいアイデアが成功し始めると、新参者がイノベーションについてエバンジェリストに尋ねてくるようになる。
そんなときは、教えるタイミングとして捉えよう。

(41)Sustained Momentum : 勢いの持続(41)

(42)Token : トークン(42)
名札のこと。
新しいアイデアを思い出させる小さな名札。
例えば、マグネット、ボタン、カップ、鉛筆、リングノート、クイックリファレンス、記事のコピーなど。
他にも、アバター、ツールのロゴ、ニコニコカレンダーなどが挙げられるだろう。

Redmineにもアバタープラグインがある。
担当者のアバターがあるだけでも、ツールへの関わり方は違ってくる。

◆抵抗と付き合うためのパターン

(43)Bridge-Builder : 橋渡し役(43)
新しいアイデアを受け入れた人を、まだ受け入れてない人に引きあわせて、イノベーションの有用性を受け入れてもらう。

(44)Champion Skeptic : 懐疑派代表(44)
エバンジェリストのアイデアに懐疑的なオピニオンリーダーに、公式な懐疑派の役割を演じさせる。
新しいアイデアの問題点を指摘するように促し、その問題に対処する。
但し、結果状況が悪くならないように注意が必要。

(45)Corridor Politics : 根回し(45)
重要な決議の前に、影響のある意思決定者に非公式に接触して、承認へのストーリーを作る。
文字通り、根回し、腹芸のこと。

(46)Fear Less : 怖れは無用(46)
抵抗勢力を新しいアイデアの強みに変える。

(47)Trial Run : お試し期間(47)
新しいアイデアのトライアル期間。
新しいアイデアを検証する。

(48)Whisper in the General’s Ear : 将軍の耳元でささやく(48)
集団の前でマネージャを説得できない時、非公式な場所でマネージャに懸念点を教えてもらう。

【5】「アジャイルに効く アイデアを組織に広めるための48のパターン」で面白いのは、エバンジェリストをサポートする人々の役割にたくさんのパターン名が付けられていること。

エバンジェリスト(1)、正式な推進担当者(29)がこのパターン言語の主役。
組織内には、コネクター(8)、アーリーアダプター(11)、達人、イノベーター(16)、経営層の支持者(28)、アーリーマジョリティ(30)がいて、彼らに働きかける。

エバンジェリストの味方には、著名人、身近な支援者(35)、メンター(37)、相談できる同志(39)、橋渡し役(43)がいる。
抵抗勢力には、懐疑派代表(44)がいる。

それら役割に相当する人は組織内の誰なのか、をマッピングしておけば、組織変革のどの時点ではキーマンは誰か、を考えるきっかけになりうる。

役割に相当するパターン名を調べてみると、非常によく考えられているなあ、と思う。
他にも色々考えてみる。