大切にしているもの
9月になりました。9月と言えば、XP祭りですね。
今年は、縁あってプログラムの一部であるアジャイルコーチ・ラウンドテーブルというセッションに登壇させていただくことになりました。ありがたいことです。
どこかから「え？おまえ、アジャイル・コーチとちゃうやんけ！」というツッコミが聞こえてきそうですが、いわゆるユーザー企業のマネージャーの立場でアジャイルな開発組織（そしてそうじゃない組織も）に関わってきた経験から、何かしらの発信・貢献ができたらいいなと思っています。
で、そのセッションでご一緒させていただく安藤さんが自身のブログに
という記事を書かれていたので、私も見習ってXP祭りに向けて何か書いておこうと思い立った次第です。
とは言え、過去の職歴やそれぞれの会社でやってきた具体的なことをどこまで書いてよいかわからないので、まずは自分が組織の中でアジャイルの導入・展開をする上で大切にしているもの・ことを過去のブログ記事をふりかえる形で書いておきます。（過去記事の再利用とも言うw）
アジャイル導入はアジャイルにやるのだ
Scrumとは、組織の機能不全を表面化させることで、それへの対処を促すフレームワークとしての特性だけでなく、またその実効性を担保するための、人間の行動・振る舞いを規制・規定するアーキテクチャとしての特性をも持っていると言えるのではないでしょうか。
"Transformation is incremental and iterative"
"Run Change Like an Agile Project"
つまり、アジャイルな組織への転換というものはリニアに進めるものではなく、それこそアジャイル開発そのものと同じように進めるべきであるということです。
その根底にあるのは、Scrum（に限らずアジャイル開発全般的にそうだと思うのですが）が、複雑適応系（Complex Adaptive System）を扱うものであるということ。それを忘れると、本来ワークショップの中で気づき・考えるべき「不確実性にどう対応していくのか？」ということを体験できず、参加者はチグハグな印象を受けるだけでなく、場合によってはワークショップで最も気づいてほしいことに気づかずに間違った理解をしてしまいかねません。
この中でも彼が言っていますが、「Scrumをチェンジ・マネジメントのアプローチとして使う」ということが一つのポイントです。以前のエントリでも何回か書いていますが、「アジャイルの導入はアジャイルにやれ」と言うことですね。それを形にしたのが、上の図のEnterprise Transition Teamであり、具体的には、Transition Backlogにユーザーストーリーの形でバックログをぶっ込んでTransitionの戦略をScrumで回していくということです。
Cherry Pickingに関しては現実的な解釈をするのだ
これは必ずしも「トップダウンでビッグバン的に導入する」ことを意味するわけではありません。ミーム複合体としてのScrumを導入するからといって、それが「全てのミーム（プラクティス）を同時に」導入しなくてはならないというわけではないということです。概念として大きな固まりで捉えること、そしてそれを伝えていくことは重要ですが、個々のプラクティスの導入時期や順序などは、それこそその組織のコンテキストに応じて、というのが正しいアプローチではないかと思います。
ここでのキーは、「コンテキストに合わせたり、相手に合わせたり」と「一体となってあるべき方向に」でしょう。逆に言えば、成果を出している現場では、この２つのポイントをしっかり守った上で現場に合ったやり方をしているのであり、それは単に興味や取っ付きやすさなどに基づく「つまみ食い」としてのCherry Pickingではないということでしょう。
その他
「パイロットの成功がアジャイルな組織をダメにすることもある」- これは我々がアジャイルやリーンの導入をする際にパイロットプロジェクトを実施し、またその結果を考察するにあたって念頭においておくべきことだと思います。
この２つに共通することはいくつかありますが、最も重要なのは「学習」だと思います。フィーチャーチームを作ったり、またコンポーネントチームからフィーチャーチームに移行したりするときも、チーム内におけるSpecializatiionとGeneralizationのバランスを取ったりするときも、そこではある意味個人としてあるいは組織としての「学習」が要求されます。その意味では、Scrumは改善のフレームワークであるとともに、組織の学習を強制するフレームワークとも言えるかもしれません。
尊敬されていないイノベーターに、自分のアイデアを売ってしまわないこと
「How to Change the World 〜チェンジ・マネジメント3.0〜」の中で好きな箇所を一つ挙げろと言われたら、私は次の一節を挙げると思います。
決して、あなたが今後説得したいと考えている人々に尊敬されていないイノベーターに、自分のアイデアを売ってしまわないこと。間違った人々にアイデアを売ると、他の人々の抵抗はより強くなってしまう。
翻訳だと少しわかりにくいかもしれませんが（←自分で言うなw）、原文ではこうです。
Don't sell your idea to innovators who are not respected by the rest of the people you want to convince. If you sell to the wrong ones, the rest will resist even harder.
チェンジ・プログラムを推進するには、組織内のイノベーターを見つけて、そこに火をつけることが重要です。しかしながら、それは思考の変化に柔軟で変化にすぐ飛びつく人ようなイノベーターの素質を持つ人なら誰でもよいというわけではないということです。これって忘れがちだけど大事なこと。
ちなみに、この話は、Kerry Pattersonらの"Influencer"という本に出てくるのをもとにしています。
The key to getting the majority of any population to adopt a vital behavior is to find out who these [unwanted] innovators are and avoid them like the plague. If they embrace your new idea, it will surely die.
(Kerry Patterson, et al. "Influencer")
こんな役に立つアドバイスが満載の「How to Change the World 〜チェンジ・マネジメント3.0〜」は、達人出版会で電子書籍として絶賛発売中です♪
「How to Change the World 〜チェンジ・マネジメント3.0〜」
Influencer: The Power to Change Anything
- 作者: Kerry Patterson,Joseph Grenny,David Maxfield,Ron McMillan,Al Switzler
- 出版社/メーカー: McGraw-Hill
- 発売日: 2007/08/22
- メディア: ハードカバー
- クリック: 1回
- この商品を含むブログを見る
チェンジ・マネジメント3.0の何が3.0なのか
最近、宣伝づいているようで恐縮なのですが（実際、宣伝なのですが）、先週末に達人出版会より"How to Change the World〜チェンジ・マネジメント3.0"がリリースされました。
おかげさまでみなさんにTwitterやブログでも取り上げていただき、翻訳者はじめ関係者一同、心より感謝しています。
ところで、この「3.0」ってなんなんでしょうか？
Management 3.0とChange Management 3.0
ご存知の通り、原書の著者であるJurgen Appelo氏は、"Management 3.0"の著者でもあります。チェンジ・マネジメント3.0は元々、"Management 3.0"の研修コースの一部（書籍の"Management 3.0"にはそれに相当する章はない）であり、それ故にその3.0を継承していると考えるのが妥当かと思っています。
Manaement 3.0とは
では、"Management 3.0"の3.0というのは何を示しているのでしょうか？
これは書籍の中に書かれています。また、このブログの過去エントリでもそこを引用しながら以下のように記しています。
著者はMANAGEMENT 1.0から3.0を以下のように定義しています。
Management 1.0 = Hierarchies
Management 2.0 = Fads
Management 3.0 = Complexity要するに、1.0は階層型組織におけるトップダウン型（場合によっては科学的管理とかコマンド＆コントロールとも呼ばれる）のマネジメントであり、2.0は基本的な構造は1.0を引きずりながらその上にいろんなadd-onを載せたもの、そして3.0はこれまでとは全く違う複雑系の理論やホリスティックな考え方に基づくマネジメントであるということです。
扱っているのは複雑で適応的な社会システムを変える方法
つまり、本書が扱っているのも、CAS (Complex Adaptive System)なのです。それを表す文言も中にいくつか出て来ています。
我々はみんな、複雑な社会システムを変える方法を知りたいのだ。
社会システムのような複雑なものの振る舞いを変えるためには、チェンジ・マネジメントの４つの側面を理解する必要がある。
そして、それを全く新しい手法や考え方を持ち出すのではなく、その４つの側面に対応する既存の有名なモデルをラッピングする形のスーパーモデルで説明しようとするのが本書の真骨頂なのです。
「How to Change the World〜チェンジ・マネジメント3.0〜」が出ました！
３月末頃からユルユルと翻訳作業を進めてきた"How to Change the World"(Jurgen Appelo著)の日本語版を、昨日（7/13）無事に出版することができました。
本書は電子書籍版（PDF/EPUB）のみで、達人出版会さんのサイトから購入できます。
この本との出会い
過去の関連記事は、こちら
著者のJurgenは、このブログでも再三取り上げている書籍「Management 3.0」を書いた人で、私が最も影響を受けた人物500人のうちの一人です。ご興味があれば是非、ダウンロードして目を通してみてください。
AgileとChange
アジャイル開発の現場においては、変化を抱擁し変化に適応していくことが求められます。そして、アジャイル開発の導入・適用においては、組織レベルでの変化やトランスフォーメーションが欠かせません。
そこでは、チェンジ・エージェントとして適切に振る舞える人が必要であり、優秀なチェンジ・エージェントになるために必要なことが80ページ足らずのコンパクトな小冊子にまとめられたのが"How to Change the World"です。
Fearless ChangeとHow to Change the World
Changeやチェンジ・エージェントというキーワードから、Linda Risingの"Fearless Change"を思い出された方もいらっしゃるかもしれません。そんな方は是非、無料でダウンロード可能な
を併せてお読みになることをおすすめします。
その中にはチェンジ・エージェントが考えるべき問いが、"Fearless Change"のパターンとのリファレンス付きでリストアップされています。
謝辞
今回の翻訳に際しては、原著がそもそもJurgenの自費出版のような形だったこともあり、翻訳の許諾を得るために著者本人に直接コンタクトを取るところから始まりました。日本語版の出版を快諾してくれたJurgenをはじめ、共訳者の川口さん・吉羽さん、レビューをしてくださった原田さん・ナイスビアの永瀬さん・高江洲さん、契約面でお手伝いいただいたアギレルゴコンサルティングの谷口さん、達人出版会の髙橋さん、その他本書の出版に関わってくださったすべての人々に感謝です。
ハイブリッド型プロジェクトでのBAの身の処し方
昔のブログで、アジャイルなプロジェクトやチームにおけるBA（Business Analyst）の役割についてのいくつかの参考資料のまとめエントリを書いていました。
そこでピックアップした資料群は、どちらかというとトラディショナルなBAがアジャイルの文脈にどう対応していくかという観点のものが多かったと思います。しかしながら、現実にはもう少しハイブリッドな環境（←実際には過渡期を含めてこのような環境の中でどうしていくかというのは非常に大きな課題だと思っています）に直面することも多く、そこでどう考えるべきかということを、以下の記事を参考にして整理してみたいと思います。
基本的にこの記事をベースに以下に展開していますが、元記事には執筆者の過去エントリや関連記事へのリンクなども豊富ですので、興味を持たれた方は是非、元記事をご覧になることをおすすめします。
TraditionalとAgileのハイブリッドの３形態
ハイブリッドなアプローチの是非については諸々議論のあるところだとは思いますが、一旦ここではその点については判断を留保しておきます。ただ、いずれにしても現実問題として世の中にはハイブリッドなアプローチを取らざるを得ない状況もあるだろうということを受け入れた上で、その中で最大限の成果を出すためにBAとしてどう身を処していくかというのが今回のポイントです。
上にリンクを貼り付けた記事の中では、ハイブリッド型のプロジェクトを３つの類型に分けています。
- フランケンシュタイン型
- 異種交配型
- コンボ型
以下、それぞれについてその特徴とそこでのBAのあり方についてみていきましょう。
フランケンシュタイン型
これはあまり望ましくない形ではありますが、現実にはよくある（そしてみんなを悩ませる）かもしれない形ですね。
イメージとして言葉にすると、「今度のプロジェクトではアジャイル開発を採用するよ。でも、開発に着手する前にユーザから要件についてのサインオフをもらおうね。あ、それから、期限通りにすべての機能をリリースするのは必須ね！」みたいな感じのプロジェクト。ほんと、悪夢ですね。
こういうプロジェクトに放り込まれたBAの悲劇としては、
- アジャイルの名のもとに十分な時間を割り当てられない状態で、事前にすべての要件を詳細に定義するという非現実的な期待に応えなければならない
- 期限通りの全機能リリースをコミットさせられた開発チームが要件の変更を受け入れてくれない結果、ユーザのフラストレーションが溜まる（その板挟みになる）
- 結果として、ユーザやビジネスのニーズに応えられないということも含む全般的なプロジェクトリスクの増大
BAの身の処し方
フランケンシュタイン型のプロジェクトにおいては、BAとしてはそのリスクを叫び続けるくらいしかできることがありません。そんな中での一番の戦略は、最初からそんなプロジェクトにアサインされないようにすることです。
異種交配型
これは、トラディショナルとアジャイルが入り混じっているという点ではフランケンシュタイン型と同じですが、プラクティスの取捨選択において、インテグレイティブ・シンキング（Integrative Thinking）に基づいた考え方が適用されているという点で異なるアプローチとなります。
適切に「異種交配」が行われれば、BAとしてもその考え方に則って自分の身の処し方を考えることができます。基本的に、この考え方がうまくいく場合はイテレーションによるリズムの中で必要な要件を必要な時に定義し、またその優先順位を適宜見直していくことが可能になっていると思われます。
コンボ型
これは大規模プロジェクトでよく見られるタイプのやつですね。アーキテクチャーとかセキュリティとかがっちりやりたいところはトラディショナルで、それ以外の要件の変動がありそうなところはアジャイルで、みたいな形。いわゆるWater-agile-fallってやつもこの分類に入るかもしれません。
BAの身の処し方
ここでは、計画駆動のフェーズとアジャイルなフェーズを分けて考えましょう。それぞれのフェーズによって求められる能力や必要な成果物のあり方、仕事のやり方が異なってきます。
従って、コンボ型プロジェクトの場合は、それぞれのフェーズによってそれに適したBAをアサインすることでより大きな成果が得られることもあるかもしれません。
引き算で作る強い組織
なんか、id:kent4989さんの記事にかぶせて書くというのが続いて恐縮ですが、
アジャイル開発に求められる人材像に関する雑感 - 勘と経験と読経
を読んでまたいろいろと刺激を受けたので、いくつか考えたことをまとめておきたいと思います。
プラスアルファかマイナスアルファか？
id:kent4989さんいわく、
これまでの就職や就社では「賢い」ということが重視されてきたのだと考えているのだけど、これからは「賢いプラスアルファ」が必要ということなのだろうか。じゃあ、アルファの部分に入るのは何なのだろうか。
とのことですが、ここで引っかかった点がふたつあります。
「いやいや、もともと賢いだけじゃないさまざまな要素は求められてきていたでしょ？」っていうのがまず１点。そして、氏がプラスアルファの要素として挙げているのって、程度の差こそあれ、氏が冒頭で「PMの97本」や平鍋さんのブログをわざわざ引用している通り、幼稚園で当たり前のように必要とされるものだよね？というのがもう１点。（さらに言えば、この話ってわざわざアジャイル開発に限って言う話でもないよね？というのもありますがw。）
この２点から考えると、幼稚園で学んだことが実践できなくなってしまった要因（社会的通念や規範意識、あるいは「空気」といったもの？）をいかに取り除くか（何をマイナスアルファするか）の方が重要なのではないかというのが私の仮説です。
社会人基礎力と多様性
社会人基礎力についても同様です。
「企業や若者を取り巻く環境変化により」まず変わらなければいけないのは、「社会的基礎力」の一部を封じることで経済成長を実現してきた社会や企業のあり方ではないでしょうか？（よく言われるように「一度の失敗も許されないような環境を作っておいてチャレンジしろと言ったって……」というやつですよ。）
これは、以前のエントリにも書いた、
上で述べたように、自己組織化というのはそれ自体が太古の昔からあるもので、そもそもそっちの方がデフォルトであるとも言えます。ただそれ自体に良い/悪いという概念がないため、道徳・社会規範・ビジネス価値などの視点から有用な方向付けを行うために生まれたのがCommand and Control型のマネジメントや組織であると考えられます。
しかしながら、世の中のComplexityに対応していくためにはそれでは難しいということで、自己組織化が改めて見直されているというのがアジャイル開発への流れの中で見られる現象です。
But...Self-Organization Is Not Enough: 自己組織化チームに関する誤解とマネージャの役割 - Always All Ways
と似た構造に私には見えます。
そしてもうひとつ大事なのは、「社会的基礎力」とはすべての人が等しくバランスよくすべての能力を持つ必要もないし、そこには人それぞれの特徴をいかした「多様性」があってよいだろうということです。（多様性とは社会的基礎力のバラツキのことである、と言ったら言い過ぎでしょうか。）そして、チームや組織における「多様性」こそがイノベーションを生み出す力になるのではないだろうかと思うわけです。
育成の観点から
まぁ、そうは言っても、「幼稚園で学んだこと」や「社会的基礎力」を封じてきた障壁を取り除くだけで、うまくその力が発揮できるかというと、きっとそうではないでしょう。また、そういう「基礎力」を現実世界においてさまざまな「応用力」や「経験」と組み合わせて成果を出していくにはそれなりのトレーニングが必要でしょう。（幼稚園児を集めてきたら、アジャイル開発で素晴らしいシステムが構築できるというわけでもないですよね？）
逆に言えば、これこそがマネージャーの重要な役割の一つなのだと思います。
そのあたりについては、下記の参考記事でも書いているような
- 自己組織化のシステムを作ること（Development）、そのシステムを守ること（Protection）、そしてその方向付けをすること（Direction）
- 「経験から学ぶ力」を高める仕組みを組織の活動に組み入れて行くこと
など、マネージャーが意識して取り組むべきことがいろいろ考えられると私自身は思っています。
ここでも「人ではなくシステム（系）をマネージせよ」（Manage the System, Not the People）というのが通用すると思います。
個人のふるい落としかマネージャーのシフトか
記事の最後でid:kent4989さんは、以下のような見解（危惧）を示されています。
しかし「コミュニティ適応性」でも「情熱」でも「社会人基礎力」でも、何かのトレーニングで簡単に獲得できるようなものではないのが気になるところ。このところ大手サプライヤーでも人材転換の話題が出ているが、これで自社人材に簡単にプラスアルファの力がつくとは思えない。ハードルを上げてふるい落とすといった方向となってしまうのではないだろうか。
もし、実際にそういうことになるのであれば、その企業・組織は力を失っていく一方なのではないかと私は思います。
私が上で述べたような仮説の上に立つならば、やるべきことは新たな能力やスキルを身につけるためのプラスアルファの方策やそれに基づくメンバーのふるい落としではなく、マネジメントの弊害を取り除き、メンバーのマインドセットの変革を促す引き算の施策なのではないでしょうか？
- 工業化を中心とした高度成長時代から続く旧来の思考によるマネジメントの弊害を取り除くこと
- そこで解き放ったメンバーのマインドセットを適切にガイドするチェンジ・エージェントの育成
そして、そこで読むべき本で言えば、個々人レベルでの「自己啓発本」のような話ではなくて、例えば、"Switch"や"Fearless Change"、"Leading Change"、"Influencer"などにより近い話なのではないかという気がしています。
Switch: How to Change Things When Change Is Hard
- 作者: Chip Heath,Dan Heath
- 出版社/メーカー: Crown Business
- 発売日: 2010/02/16
- メディア: ハードカバー
- この商品を含むブログ (1件) を見る
Fearless Change: Patterns for Introducing New Ideas
- 作者: Mary Lynn Rising, Linda Manns
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2003/10/17
- メディア: ハードカバー
- 購入: 11人 クリック: 81回
- この商品を含むブログ (16件) を見る
- 作者: John P. Kotter
- 出版社/メーカー: Harvard Business School Pr
- 発売日: 1996/01/15
- メディア: ハードカバー
- 購入: 1人 クリック: 1回
- この商品を含むブログ (2件) を見る
Influencer: The Power to Change Anything
- 作者: Kerry Patterson,Joseph Grenny,David Maxfield,Ron McMillan,Al Switzler
- 出版社/メーカー: McGraw-Hill
- 発売日: 2007/08/22
- メディア: ハードカバー
- クリック: 1回
- この商品を含むブログを見る
社会的必然性としてのアジャイル
今朝、巷でちょっと盛り上がっていたやつに私も乗っかっておきます（笑）。
# 最初は乗っかるつもりはなかったのですが、読めば読むほど味わい深いので、私なりの解釈や思うところを書き記しておきたいと思った次第です。
# 元記事の著者お二人の意図に反した解釈を勝手にしている部分もあるかもしれませんが、あくまで私なりの解釈とそれらについての個人的見解とご理解くださいね。
元記事ふたつ
著者のお二人は個人的にもお付き合いがありどちらも尊敬している人です。ユーモアまじりの記事の中でそれぞれの視点や考え方が出ていて興味深く読みました。
まず、両記事を読んで私が感じたのは、（おそらくお二方も承知の上で敢えて書かれているのだと思いますが）
- 「どちらが楽か」というのは、PMやコーチとしてメンバーのメンタルモデルに思いを巡らすのは有用かつ必要なことだとは思うけれども、「問い」の立て方としてはあまり筋のよいものではないな。
ということです。
とは言え、これはこれでいろいろ考えるきっかけにはなりました。
社会的必然性としてのアジャイル
そんな中で、この一連の話の中で何か一つだけポイントとなる箇所を選べと言われたら、私は迷わずRyuzeeさんの記事の以下の部分を挙げると思います。
ちなみに、工場でのものづくりにおいて、少ない品種の大量生産から多品種少量生産に変わったのは、社会的必然性があったからで、ウォーターフォールからアジャイルへの流れも社会的必然性と僕は捉えている。
さらに言えば、これは単にソフトウェアやシステム開発の話にとどまらず、経営全体の話の中で認識しておくべきことかと思います。（そのあたりが、このブログの過去記事の経営にとってのアジャイルだとかエンタープライズ・アジリティについて考えるシリーズとかにつながるものと考えます。）
で、本当にそうなのか？
というのをビジュアルに示しているのが、Steve Denningがよく使っているこのグラフたちです。
(Source: How Do You Explain Radical Management (Or Agile) To A CFO? - Forbes)
マネジメント手法との因果関係は明確でないし、結果からサンプルを作為的に抽出しすぎではないかとの批判もあるかと思いますが、Steveの言うところのRadical Management（システム開発におけるアジャイルに相当）を採用する企業と従来型から転換できなかった企業の株価を見れば、歴然でしょ？というグラフです。
コミットメントや最大限の努力に関する誤解
あと、これはその後のtwitter上でのやりとりでも議論されていましたが、まだまだコミットメントとか最大限の努力についての誤解が多いのかな、という印象です。
そのあたりの解説は、id:kent4989さんの方の記事でも引用されている
を落ち着いて読めばRyuzeeさんの言わんとしている真意は誤解なく伝わると思うのですが、なかなか難しいのですかね？
ちなみに、私の昔のブログでも
という記事の中でコミットメントに対する考え方を書いています。
向き不向きの話で終わらせてよいのか？
話を元に戻しますが、もう一つ興味深いのは、Ryuzeeさんの記事の書き方として
となっているところの読み方です。
Ryuzeeさんが意図されているかどうかわかりませんが、私にはこれが「ダメな顧客、ダメな開発者・開発チーム大集合のリスト」に見えてしょうがないのです。
もちろん、商品・サービスの特性や組織の文脈によってそこでのプロセスや方法論に向き不向きがあるとは思います。が、それを「うちはこういう組織でこういう商売なんだから、これでいい」と考えるのか「社会の変化などを考えると、そもそもこういう組織だったりこういう商品やサービスを提供していること自体がマズいのではないか？」というところまで踏み込んで考えられるのかは大きな違いだと思います。
そして、それを考えることこそが、「社会的必然性としてのアジャイル」や「エンタープライズ・アジリティ」を考えることに他ならないのではないでしょうか。（誤解のないように言っておきますと、なにも「アジャイル開発が向かないような組織は会社としてももうダメだ」などという暴言を吐くつもりはないですからね。ただ組織の文脈ありきで向き不向きを判断するのではなくもう一歩踏み込んで考えてみてもいいのでは？という話です。）
