アフターコロナまたはTwo Loopsモデルによる古いシステムの終焉 #distributed_agile_team
先日、5月5日に開催された「第2回分散アジャイルチームについて考える会」で久々にLTしました。
私達は現在外出が制限されているので時間があり、ZoomやDiscordなど他人とつながるためのツールも溢れている。そんな中、誰かが始めたコミュニティに参加するのも素晴らしいけど、自分自身の関心からコミュニティを作ることはもっと素晴らしいという趣旨でした。
感動したのは、実際に参加者がその会でとあるオンラインコミュニティを立ち上げたことです。
自分の言葉が誰か一人にでも届いたのが嬉しかった。
さて、その後、ふとしたきっかけで社会変化のためのTwo Loopsモデルを知りました。
Two Loopsモデルとは、どのように古いシステムから新しい社会システムが生まれるかを現すMargaret Wheatleyとthe Berkana Instituteによるシンプルなモデルです。
そこでも鍵を握るのがコミュニティです。
自分なりに整理するとTwo Loopsモデルとは、以下のようなモデルです。
- 古いシステムがピークを過ぎ衰退期を迎えると、そこから抜け出す人が出てくる
- 抜け出した人は、はじめは一人で、新しいシステムを作る
- 抜け出した人同士がつながり、コミュニティを作る
- コミュニティ同士がつながり、実践コミュニティを形成する
- 最終的に古いシステムが新しいシステムに置き換わる
システムを内部から変えることはできません。システムを変えるのはシステムの外側にあるコミュニティ同士の連携によるネットワーク効果です。
現在、無数のコミュニティが静かに生まれているのを感じます。
アフターコロナの世界を変えるのは、あなたが何気なく友人と始めたコミュニティかもしれません。
派遣/フリーランス中心でも良い感じにチームビルディングする方法
はじめに、アジャイルにおけるチームビルディングの重要性
マサチューセッツ工科大学のダニエル･キム教授が提唱した「組織の成功循環モデル」という考え方があります。上手くいっている組織は最初にメンバーの信頼関係や相互理解などのメンバーの「関係の質」を高め、結果グッドサイクルが発生し「結果の質」向上に結びつく。という理論です。
また、ジェームス・コプリエンによる『組織パターン』では、全てのパターン言語の起点に「信頼で結ばれた共同体」パターンがあるとし、どんなテクニックを適用しようとしても、最初に信頼関係を構築しなかったら無意味だということが示唆されています。
ですので、もしアジャイルを組織に導入する際にまず何をすべきか? と聞かれたら、私は「チームビルディング」と答えます。一見遠回りに思えるかもしれませんが、チームの相互認識や信頼関係を向上させないままスプリントを開始することは、基礎工事をしないまま高層ビルを建設するようなものです。
そしてチームビルディングが圧倒的にうまく行くのは自社メンバーだけで構成されたチームです。
他社/フリーランス中心チームのチームビルディング
しかし、実際は、経営戦略やエンジニア不足から、自社だけでエンジニアをまかなえず他社またはフリーランスメンバー中心の開発チームになることが多いですし、今後はさらにこのような形態のチームが国籍含め増えていくでしょう。
そして、このような場合、チームが成立するまでに到らず、いわゆる寄せ集めのまま終わってしまうケースが多いのも現実です。
なぜならチームとは「共通の目的のために集まった人物の集合(Wikipediaより)」。にも関わらず、自社メンバーの目的は「自社プロダクトの成功」に対し、自社以外のメンバーの目的は「より高い単価や増員」などと両者の目的が根本的に異なるからです。加えて、チーム内に顧客-受託企業などの階層構造が持ち込まれることも、一致団結することをさらに困難にします。
もちろん、両者の立場による目的のズレを完全に埋めることはできません。
しかし、このようなケースでも目的のズレを調整し寄せ集めからチームになることは決して不可能ではありません。
今回は私がこれまで実施してきた方法と一言解説をお伝えします。
目的の共有
- インセプションデッキ
スキル/価値観/プライベートの共有、「お互いを知る機会」作り
- スキルマップ
- ドラッカー風エクササイズ
- wevox values card
- 雑談
- チームランチ、飲みニケーション
プロダクトの価値やビジョン、POの情熱の共有
- プロダクトへの価値、情熱を共有する
- ユーザー/利用シーンに参加してもらう
組織が支援できること
- 一括請負型契約ではなく準委任型契約にする
- できるだけ会社の教育/福利厚生に参加できるようにする
- チームビルディングに投資する
解説
目的の共有
繰り返しになりますが、チームとは「共通の目的のために集まった人物の集合」です。なのでチームになるためには目的を統一させるのが先決です。そのためにはインセプションデッキなどで、プロジェクトのゴールや目的をしっかりと把握する必要があります。
スキル/価値観/プライベートの共有、「お互いを知る機会」作り
チームの目的を把握したら、次はお互いを知ることが重要です。
複数の立場が混ざったチームビルディングのポイントは、できるだけ立場や役割を超えた一人の人間としてお互いに接すること。スキルだけをシェアするよりも、ドラッカー風エクササイズなどでお互いの期待や価値観をシェアすることをオススメします。また、そのために業務とは関係ない雑談を積極的に取り入れてきました。
プロダクトの価値やビジョン、POの情熱の共有
いくらチームの目的がはっきりし、お互いを知ったところで、肝心のプロダクトビジョンがショボかったら元も子もありません。POは是非プロダクトの価値やビジョンを情熱を持って正面からメンバーに伝えてください。もしも情熱がなくてもあるフリをするのがPOの重要な仕事です。
また、経験上ユーザーインタビューや利用シーンを見学してもらうこともとても効果的でした。実際にプロダクトを求め、利用するユーザーの声を聞くことは、エンジニアにとって大きな励みになります。
組織が支援できること
チームはチームビルディングを頑張っていても、組織はそれに無関心または冷ややかに見つめている現場をよく見かけます。しかし、チームビルディングは組織の支援なしには不可能といっても過言ではありません。たとえば契約。一括請負契約で受託企業にリスクを押しつければ、どんなにチームビルディングを頑張っても次第次第にメンバーが契約によって身動き取れなくなる現場を見てきました。また、困難かもしれませんが、トレーニングやランチなどの福利厚生を自社以外のメンバーに適用することも是非ご検討ください。チームビルディングはアジャイルの要ですが、効果が得られるまで忍耐が必要な投資だと認識してください。
スプリントゴールの効果
私は支援の際、スクラムが健全に機能してるかどうかを示す指標の一つとしてチームがスプリントゴールを設定しているかどうかを見ています。実際、スプリントゴールを設定していないチームは多いです。以前とあるチームに何回かスプリントゴールを設定するよう促しましたが、最後までチームはスプリントゴールを設定することはありませんでした。そこで今回は、今までの経験から、スプリントゴールを設定しないチームの特徴やスプリントゴールの効果について説明します。
スプリントゴールを設定しないチームの特徴
経験上、スプリントゴールを設定しないスクラムチームには共通点があります。
それは、開発チームが「下請け扱いされている」または「ビジネスに関心が薄い」ことです。
具体的には開発チームがPOの下請け扱いされている組織(とそれと似た力関係の組織)、POやUXデザイナー等が詳細な仕様やデザインを決定してしまう組織、またはビジネスに関心が薄い開発チーム、スクラムを始めたばかりの開発チームに多い現象です。
スプリントゴールとは文字通りスプリントで達成したいゴールですが、上記組織での多くの開発チームは「ビジネスゴールの実現ではなく、あらかじめ決定された具体的な機能を実現すること」が求められます。そのため、スクラムチーム全体で抽象的なスプリントゴールを設定する意味が薄く、具体的なバックログリストがスプリントゴールの代わりとして利用されます。
とはいえ、スプリントゴールの欠如はやがて大きな問題につながると筆者は見ています。
スプリントゴールがないことによる問題
スプリントゴールとは、スプリントの目的です。
スプリントゴールとは、チームが一致団結して作業するための旗印です。
スプリントゴールの欠如は、3つの問題を開発チームにもたらし、次第に組織全体にダメージを与えます。
1つ目は、ゴールではなく具体的なバックログのみが与えられた開発チームは「ゴール実現のためにより良い手段はないか」という視点から創意工夫や提案することが必要ないため、自律性や思考力が育たないことです。
2つ目は、ゴールがないと「スプリントでこのバックログを実現しなくてはならない理由」が開発チームがわからないため、次第にモチベーションを失っていくことです。人は作業に意味と目的と求める生き物です。
3つ目は、ゴールは共通の判断基準として機能するため、ないと細かい調整や判断に時間がかかり、やがて集中力が途切れてしまうことです。
では、スプリントゴールを設定するとどのような効果があるのでしょうか？
スプリントゴールの効果
例えば、あるチームでは「できるだけ速く様々なビジネスアイディアをユーザーテストしたい」というスプリントゴールを設定した結果、チーム全員が自動的に下記の共通認識を持てました。
- プロダクションコードを修正しなくてよい
- デザインを凝らなくてよい
- 速さ重視のため、既存プロダクトを積極的に利用しなければならない
- チーム全員で様々なアイディアを出さなければならない
- ユーザーテストをするため、カスタマーサポート部と連携しなければならない
スクラムチーム全体でスプリントゴールを共有することで、何をすべきで何をすべきではないかという判断基準が明確になり、意思決定や調整がどんどん素早くなっていきました。
さらに、チームが向かうべき共通のゴールがあることで、自分のスキル外のタスクを実施し、助け合うカルチャーが生まれるきっかけとなります。
組織を変えるとはマインドセットを変えること。初めての #RSGT2020 参加レポート
会社 (Graat | Growth Architectures & Teams, Inc - Graat（グラーツ）) のブログに Regional Scrum Gathering Tokyo 2020 の参加レポートを書きました、よろしければお読みくださいませ〜!
WE ARE NOT ALONE 〜RSGT2020参加レポート!(非Keynote/セッション編)
今回は、先日1/8(水)〜1/10(金)にかけ開催された Regional Scrum Gathering Tokyo 2020 の感想をレポートします!
チケットは1時間経たずに完売、素晴らしいイベントとは聞いていたものの、内心「どんだけ〜？」と疑っていた私。ただ、終わってみて思うのは想像を遥かに超える良いイベントでした!! 未だに興奮冷めやらず、今朝も興奮を冷ますためにMr.Childrenの『終わりなき旅』やスガシカオの『Progress』を聴きながら近所を歩き回る始末......
Keynoteやセッションについての感想は会社ブログ Graat | Growth Architectures & Teams, Inc - Graat（グラーツ）Graat | Growth Architectures & Teams, Inc - Graat（グラーツ） に書く予定なため、今回はそれ以外で印象に残ったシーンを書きます。
1日目
即席Coaches Clinic
心理的安全性ゲームでおなじみのyattomさんとご一緒したため、即席Coaches Clinicとして「クライアントがAndroid/iOS/サーバーサイド等のコンポーネントチームをフィーチャーチームにする支援をしてますが、AndroidとiOSの開発の両立は自分の経験からも中々上手くいかない気がする」という悩みをご相談しました。
yattomさんの答えは「メンバーひとりひとりの意思を確認したら?」
「iOSで一生食っていきたい、という人もいれば、もしかしたらiOSもAndroidも両方やりたいという人もいるかもしれないし、新しいことをやってみたいという人もいるかもしれない、だからひとりひとりに意思を確認すれば良いのでは?」
それを聞いて確かに自分の経験から「iOS/Androidの両立はむずかしいと開発メンバーは思っている」と一括りにして、各メンバーひとりひとりにきちんと向き合っていなかったなぁと反省、観察が足りない!
あとペア/モブプロもお勧めされました。
Coaches Clinic 活用術
さらにyattomさんからCoaches Clinicは同じ問題を複数のコーチに相談すると良いとお勧めされました。そうすると多角的に問題が捉えるきっかけとなり、問題をはっきりと見ることができるからとのこと。
もちろん私も相談するだけではなく早くコーチ側として(ドヤ顔で)回答できるように精進していきます!
Empathy Boxの説明
さらにyattomさんが持ってきたEmpathy Boxというカードゲームのルールをご紹介していただきました。
どうしても NVC Japan の 共感トランプ (第二版）と比較してしまいましたが、共感トランプと比較すると以下が異なる印象で、「NVC+コーチング」と言った感じでよりビジネスに使いやすそうなとても楽しそうなゲームでした!
- 長時間必要
- 共感だけではなく、自分の印象や提案を述べても良い(←コーチングっぽい)
近々yattomさん主宰で体験会を開催するので、もし参加されたい方はyattomさん(か面識なければ私まで)ご一報ください〜!
Networking Party
初対面の方、Twitterでしかやり取りがない方、様々なコミュニティの方、いろいろな方に勇気を出して声を掛けまくりとにかく様々な方とお話しさせていただきました!
いくつになっても女性の前でカッコつけたい私、SNSで話題の1on1カードと「ズレコミュ本」を購入してしまいました!お恥ずかしながら日常やRSGTでも「ひょっとして私のコミュニケーションってズレてる...!?」と思う機会も多々あるため、擦り切れるまで1on1カードと「ズレコミュ本」を使い倒してやりますー!
そのあとは仲良くしていただいているFukasawaさんとサシで飲んだりして1日目は幕を閉じました。
2日目
懇親会
gaoryuさんやyokomichiさんの思わぬ悩みを聴いて彼らをますます好きになり、IwaoさんやYamadaさんなどの先輩アジャイルコーチからの叱咤激励を受け胸が熱くなり、最初は気の良いおっちゃん位に思っていたNagasawaさんが登壇してた人と知ったり(後日判明)、とにかくとても楽しい懇親会でした。
Nagasawaさんに「すごい人が多くて緊張する」と伝えると、「Jeff(サザーランド)もCope(ジェームス・コプリエン)も、本当に分け隔てなく人と接する人、本当にきさくで日本のお勧めスポットは? なんて誰かれ構わず聞いてる」と言ってくれました。考えてみれば自己組織的なチームを熱心に提唱するアジャイル/スクラム界隈の人たちがすごいとかすごくないとか区別をつけて接するわけないのですよね。ですので、若手のスクラムマスターやアジャイルコーチには、「まだ経験が浅いから」と恐縮せず(経験に最低限のリスペクトを払いつつも)ベテランや登壇者にガンガン想いをぶつけて欲しいと思います!
僕もいきます!
Nagasawaさんはまた「こうやって会社の分け隔てなく熱心に交流しているのは、アジャイル/スクラム界隈だけ」とも言っており、ここにいられて、本当に幸せだと思いました。
3日目
OST(共感トランプ)
OSTで私の人生を救ってくれたと言っても過言ではない、 NVC Japan の 共感トランプ (第二版） を提案しました。実は共感トランプは3〜5人まで用のカードゲームで、ファシリテートも初めてでした。そこでみんなそんなに興味ないだろうと思って提案したら、蓋を開けたら20人以上の方が集まってくださいました!
初対面に近い方々が共感を贈り合うのを見て、本当に心の底からうれしかったです。ブログやTwitterでも何人かがNVCや共感トランプに言及しており、それだけでもRSGTに来た甲斐がありました。
Cope氏の講演にあった「真の自己を見つける」ためや、sahota氏の講演にあった「まず自分が変わる」ためにNVCや共感トランプは個人的にとても有用なツールだと常々感じますので、興味があれば覗いてみてください。こちらも細々とコミュニティを企画しておりますので、興味あればウォッチください!
共感トランプ (第二版） https://t.co/sdpSzY0FyR
— こばせ🥴 (@kobase555) January 11, 2020
さすがにそろそろお財布事情が厳しいのだけど、気になって仕方がない
Harada Kiroさんとの立ち話
今回、初めてお話しさせていただいたのですが、本当に写真通り以上のドヤ顔でプロダクトバックログについて話まくってくださり圧倒されました。とても面白く興奮したので覚えている限りお伝えします。
- ベロシティが安定して爆速で開発していたチーム、ベロシティが不安定な若手のチーム、最終的にアウトカムを多く出したのは後者なんだよぉ!! だって後者はPOが必死に価値あるプロダクトバックログアイテムをリファインメントしてたからだよぉぉ!!
- リファインメントは精錬するって意味なんだよぉ!! だから増やすんじゃねぇよ!! 減らすんだよ!!
- 使われる機能が半分以下だったら、ランダムで50%プロダクトバックログアイテム捨てたほうがいいんだよぉ!
- いいかぁ、企てて(くわだてて)、企らむ(たくらむ)から「企画」なんだよぉ! もっとたくらめよぉぉぉ!!!
- メニューに一つ機能を加えると利用率が10%下がるんだよぉ!!
- いいかぁ、PBIに即死、重症、軽傷、無傷って分けるんだよぉ、そしたら即死以外は捨てんだよぉ!!
- 本当に大事な機能はまた戻ってくるんだから、とにかく捨てんだよぉ!!
- 機能が揃わなくてもとにかくリリースすんだよぉ!!!
- UX屋は全部の機能を使いやすくするからダメなんだよぉ、使われない機能を使わせないように使いづらくするんだよぉ!!!
- これはって機能以外使いづらくするから面白いんだよぉ!!! もっとたくらめよぉ!!!
- 機能じゃなくて行動を設計するんだよぉ!!!
- ジェフにスクラムわかってないって言ったこともあるんだよぉ!!!(←さらにドヤ顔)
- ジェフはどんな人かって? ありゃ化物だよ!!!!
圧倒されたのは話だけではなくそのオーラです、Copeにも聞きたいですが生まれつきなのか、そのオーラ。
ウチの社長のYusukeさんとも長い付き合いとのことなので、やはりこの業界は狭いと感じました......
とにかくまた是非お話を伺いたいと思いました!
懇親会(サイゼリア)
最近とても仲良くしていただいているogasawaraさんから「見積りしないスクラム」のsuyamaさんとCyberAgentで同じアジャイル研究ゼミを運営する仲間をご紹介していただき、昼間からサイゼリアで盛り上がりました!(←中学生かよ!)、それにしてもサイゼリア、本当に安くて美味しいです。
講演資料の感想は別でまとめるとして、suyamaさんだけではなく、CAのアジャイル研究ゼミ(Yoshidaさん、Saitoさん、Ohshimaさん)のみなさんの素晴らしさを感じました。初対面の私を快く受け入れてくださり、私も別れ際には『カリオストロの城』よろしく「なんと気持ちのいい連中だろう」と呟いてしまいました。
ただ、盛り上がりすぎて店員さんに「他のお客様に迷惑なので声のボリュームを下げてください」と注意されたのは今後は気をつけたいと思います。注意された瞬間、私の中でRSGTが終わっていくのをはっきりと感じました。
是非ゼミにも遊びに行かせてください!
その後はogasawaraさんと勢い余ってNext Actionを話しながらお茶の水から高田馬場まで散歩して、私の初RSGTは幕を閉じました。
おわりに、来られなかった人へ
今回は、RSGT2020のレポート(非Keynote/セッション編)を書きました。
今回、チケット争奪戦や家庭や仕事の都合で来られなかった人もたくさんいると思います。ですが、それぞれの現場で必死にスクラムに挑戦する私たちは、すごいとかすごくないの区別もなく、RSGTに行けたとか行けないとかの区別もなく(クロージングセッションの高橋さんの言葉を借りれば)「WE ARE NOT ALONE」です。
そしてCopeの言葉を借りれば、"It is NOT good, It is NOT bad. It's about where you are"
私はまだアジャイル/スクラム界隈に接して1年未満ですが、そんな人もこんなに自由にノビノビと楽しんでいるのがその証拠ですし、そういう方は大勢いました。ですので、RSGTに行けなかったことや経験が浅いことに負い目を感じず、様々な方と、そしてもし良ければ私とも気楽に自由に仲良くしてくださればと思いますー!
最後に、運営委員とスタッフの方々、素晴らしいギャザリングをありがとうございました!
最後までお読みくださり、ありがとうございました!
アーキテクチャ民主化の光と影。『Design It!』を代わりに読む
はじめに
さまざまなロールを転々としてきましたが、10年以上ソフトウェア開発の世界にいます。さまざまなプロジェクトでさまざまなアーキテクトと仕事をしてきましたが、関わったすべてのプロジェクトで、システムを設計したのは一人でした。
1. 新卒で最初に開発したシステム
アーキテクトが設計したものは、メッセージキュー、共有メモリ、マルチスレッド、子プロセスを駆使した複雑なシステムでした。当時、巨大なシステム構成図を作った際に「UNIXプログラミングの遊園地」とジョークを言ったことを覚えています。構成が複雑なためバグが多発したもののマルチスレッドはprintfデバッグできなかったため、GNUデバッガでメモリを追いかけ苦労しながらデバッグしていました。シンプルな目的のシステムだったため、当時から「こんなに複雑なアーキテクチャは必要なのか? ただ自分が使いたい技術を使っているだけではないか?」という疑問を抱いたことを記憶しています。
2. 前職でのマイクロサービス化プロジェクト
アーキテクトが設計したのはモダンなマイクロサービスアーキテクチャでしたが、設計方針を知らされていなかったプロジェクト外のエンジニアにサービスを開放した際、開発方法が変更されることについて大混乱に陥りました。彼が残した豊富な設計文章は前提知識が乏しい人にはむずかしいドキュメントでした。さらに、マイクロサービスの詳細についてSREやビジネス部門に説明していなかったため、マイクロサービス起因の障害について納得させることはむずかしかったです。
----
もちろん、彼らアーキテクトを責めたいわけではなく、彼らがいなかったらシステムもプログラマーとしての私も存在しなかったと思っています。
つまるところ、システムの土台を作ったのは彼らなのです。
ただ、もう少しだけ分かりやすいドキュメントや、周囲への理解と説得が欲しかったのも確かです。
アーキテクチャの民主化、『Design It!』
というわけで今回本書『Design It!』を読む前は「現代的なソフトウェアアーキテクティングの入門書!」と帯文にあったため、最新のアーキテクチャの理論が羅列されているものと想像していましたが、実際はかなりニュアンスの異なる書物でした。もちろんアーキテクチャの理論についても触れられていますが、平鍋健児氏の日本語版序文に「アーキテクトとプログラマーという構造ではなく、アーキテクチャを民主化したのだ」と見事に要約されているように本書のメインテーマはアーキテクチャの民主化だと感じました。著者はアーキテクチャを設計することだけではなく、チームのアーキテクチャを育てることをアーキテクトの重大な責務として挙げています。
ソフトウェアアーキテクトは、プログラミング以外にも、たくさんの責任がある。(中略)そして何より、チームのアーキテクチャを育てる。アーキテクトで満たされたチームこそが最善だと理解しているからだ
Design It! ―プログラマーのためのアーキテクティング入門
- 作者:Michael Keeling
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/11/25
- メディア: 単行本（ソフトカバー）
本書に出てくるびっくりするほどのヒューマンスキル
たとえば、ステークホルダーに共感して共感マップを作成する、ステークホルダーに要求をインタビューする、評価ワークショップをする、「積極的傾聴」スキルの重要性をアーキテクトが語るコラム......さらに本書で登場する架空のプロジェクトでは設計の毎ステップでアーキテクトが一人で意思決定するのではなく、必ずチームやステークホルダーのワークショップで意思決定するほどの徹底ぶりです。私は読んでいてアーキテクトではなくUXデザイナーやスクラムマスターの本ではないかと思ったほどです。アーキテクチャやシステムの理論もたくさん出てきますが、本書の独自性は間違いなくアーキテクトの世界にヒューマンスキルと民主主義を持ち込んだことだと感じます。
個人的には方向性は歓迎
冒頭に書いた通り、今までアーキテクチャが一人で設計するシステムにしか関わったことがなく一人で設計することのデメリットを数々体験してきたため、アーキテクトの意思決定が見える化されること、よりステークホルダーやメンバーと協調して設計すること、分かりやすいドキュメントを残すこと、チームメンバーをアーキテクトとして教育するなどのアーキテクチャの民主化という本書の方向性は良い流れではないかと思います。
またアジャイル宣言の背後にある原則の一つに「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」という原則がありますが、まさにこれをプロセスとして具現化されているので今後サンプルの一つとしてアジャイルコーチの立場からも説明しやすくなるなと感じました。
アーキテクチャ民主化の光と影
とはいえ、アーキテクチャの世界を専制君主制から急激に民主化することが果たして本当に良いことなのかということの自分の答えはまだ出ていません。まずは、アーキテクトの責務に「チームメンバーの教育」を含めると単純にアーキテクトの負荷が増大するのではないかと単純に思います。そして本書ではメンバー全員でアーキテクチャをスケッチし批評し合う『アーキテクチャデザインスタジオ』という手法が紹介されていますが、そこで私は『デザインスタジオ』という言葉から昨今急激に進んでいる(ように見える)デザインの民主化を思い起こさせました。結局デザインは民主化できたのでしょうか? たしかに一部はされたかもしれませんが、自分たちが手軽にデザインできるという思い込み、表面的なデザイン手法の濫用、専門家への軽視、そして反動的な専門家への崇拝の復活といった悪影響も多いように感じます。
民主化は素晴らしい一方、何かを拡げるということは本質を薄めたり無くしたりする危険性と常に隣り合わせです。
ステークホルダーの要求をマッピングし品質特性とアーキテクチャデザインパターンを組み合わせれば、誰でも設計できるようになるのでしょうか。
様々な開発者やアーキテクトによる本書の批評が読みたいと思います。
おわりに
今回は『Design It!』を代わりに読んできました。
色々書きましたが、とりわけアジャイル開発に興味ある方はぜひ一読していただきたい良書です!
本文でも書きましたが、様々な開発者による本書への批評をぜひ読んでみたいと思いました。
賛否両論あるかと思いますが、何はともあれRead It!
最後までお読みいただき、ありがとうございました!
アジャイル導入への最大の敵は、アジャイルを叫ぶあなたかもしれない - 『U理論入門』を代わりに読む
はじめに
アジャイルコミュニティで一番飛びかう質問は、
「組織にアジャイルを導入するにはどうしたらよいか?」
ではないでしょうか?
もしも私に訊ねられたら、以下のように答え『Fearless Change』を勧めていました。
まちがってはいない...はず......。多分...。
ただ、どうもそれだけでは足りないのではないか? と最近考えるようになりました。
というのも、相手の課題を解決したり、アジャイルの重要性を理解させるような「頭で理解させる」手法では今一つ定着しないと感じる場面も多々あるからです。たとえば、ワークショップでアジャイルに納得した某社ビジネス部門のメンバー。はじめのうちはスクラムイベントに意気揚々と参加しレトロスペクティブも一見盛り上がっているように見えたのですが、「忙しい」という理由で次第にスクラムイベントに出席しなくなる、ということを経験しました。しかし、どんなに忙しくとも、本人にとって重要ならば調整しても出席するのではないのでしょうか。私はその時学びました、組織内での深い合意が得られていない施策は、はじめだけ火花を散らしはかなく消える、線香花火のように。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者:Mary Lynn Manns,Linda Rising
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
人はメリットでは動かない
なぜ「頭で理解させたり、メリットに訴えかける」という手法は長続きしないのでしょうか。
それは、各メンバーの信念やメンタルモデルや利害が深く異なっているという現実が横たわっているからです。
そこに目を向けないまま、自分の想いや表面的なメリットを提示しても、その場限りの了解は得られても、本当の意味で相手を納得させることはできません。あと内心相手をどこかで「全然わかってくれないダメな上司」と思いながら話すと相手はその思いを確実に感じとります、人間は賢い。
U理論とは
そんな漠然とした問題意識を抱えていた私にとって、『U理論入門』は一つの大きなヒントになる書物でした。
本書は文字通りUの谷を下っていく中で、メンバー同士の信念やメンタルモデルや利害の相違をどう乗り越えるかが描かれています。
少し長いですが、Amazonより内容紹介を引用します。
U理論は、MITのC・オットー・シャーマー博士とマッキンゼーの知的連携により、世界トップクラスの革新的なリーダー約130人にインタビューした結果生まれたイノベーションの方法です。誰もが頭をかかえる人と組織のやっかいな問題も、これまでと全く異なるアプローチにより、対症療法に終わらない本質的な解決をもたらすことができます。
では、なぜそれができるかというと、我々が変革を起こそうとする際の「盲点」に気づいたからです。我々は革新的なリーダーが「何をどうやるか」には注目し、学んでもいますが、「どんな内面の状態から行動を起こすか」という行動の「源(ソース)」には目を向けていなかったのです。
本書は個人、ペア・チーム、組織・コミュニティにおいて「行動の源(ソース)」を転換すべくU字型の谷をくぐりイノベーションを起こすU理論の実践入門書。重版を重ねている原書『U理論』の訳者で、変革ファシリテーションの実績を豊富にもつ著者が、多数の現場のエピソードをもとに、U理論の本質と実践法をわかりやすく解説します。
【もう少し紹介を続けると…】
オットー博士は、イノベーションを起こすプロセスを、別紙のように「U」字型のモデルで表現しています。U理論は大きく言うと、この3つのプロセスで成り立っています。
(この頁トップ左の表紙下のイメージ図参照)1 センシング ただ、ひたすら観察する
2 プレゼンシング 一歩下がって内省する。内なる「知(ノウイング)」が現れるに任せる
3 クリエイティング 素早く、即興的に行動に移すこれは1のセンシングから2のプレゼンシングの状態にたどり着いたときに「未来」が出現し、そこから得た直感やインスピレーションに、1人あるいは複数で形を与えることでイノベーションが現実化していくことを表しています。
この図を見ただけで、何かピンとくる方もいらっしゃるのではないでしょうか。U理論は我々がすでにもっている知恵や創造性を意図的にひきだす方法論でもあるのです。
アジャイル導入を阻む最大の敵は、アジャイルを叫ぶあなたかもしれない
ここに来てタイトルに戻りますが、なぜ「アジャイル導入への最大の敵は、アジャイルを叫ぶあなたかもしれない」なのでしょうか?
それは、あなた自身が「アジャイルがやりたい」という強い枠組み(信念やマインドセット)に囚われ、知らず知らずのうちに他の人の枠組みに無関心だったり否定しているからであり、それが他の人からの反発を生むからです。それは「アジャイル」や「スクラム」と言った専門用語を使わないことや、自分と同じ枠組みの仲間をコミュニティなどで見つけることで軽減されるかもしれませんが、根本的な解決とはなりえません。
では、一体、本当の意味で他の人の信念やマインドセットにどのように共感すれば良いのでしょうか?
まずは、あなた自身が自分の枠組みを見つめ直し、枠組みから自由になることです。
あなたが自分の枠組みに囚われている限り、真の意味で他者に共感することはできない。
具体的にどうやって実現するのかは今回の記事では触れないため、是非本書か他のブログをあたってみてください。原書の『U理論』は抽象的な記述が多いとの噂(未読)ですが、本書は著者のドラマティックな組織変革の現場やワークショップを通して具体的にどうすれば良いかが豊富に紹介されています(筆者のオススメは「パーソナルUプロセスの実践ワーク「創発型問題解決法」」です、一人でもできるので是非実践されることをオススメします!)。
