ポジティブふりかえりマッピング

アジャイルバンクーバー2010で行われた、リンダ・ライジングさんのポジティブレトロスペクティブと、ジェフ・パットンさんのユーザーストーリーマッピングを活用したふりかえりについてのブログエントリの翻訳です(著者のSteve Rogalskyさんの許可をいただきました)。翻訳にあたっては高橋陽太郎(@poohsunny)さんにレビューのご協力をいただきました。ありがとうございました。

 

ポジティブな点を述べることで「行った事実」にフォーカスできることと(課題を言うとwishが増える)、インデックスカードで整理する手法を組み合わせているところがよいなと思いました。

 

原文はこちら

Agile Retrospectives - a Rising Patton Fusion

http://winnipegagilist.blogspot.com/2010/11/agile-retrospectives-rising-patton.html

 

アジャイル・レトロスペクティブ - リンダ・ライジングとジェフ・パットンの融合

 

アジャイル・バンクーバー2010の最後のセッションは、リンダ・ライジング(Linda Rising)さんがアジャイル・バンクーバーのオーガナイザーたちとカンファレンスのレトロスペクティブ(ふりかえり)をする....ところをみんなで見る...というユニークな機会でした。彼女がどうファシリテートするのかを見るのは面白く、私はいくつかのテクニックを持ち帰って試せるよう、メモしました。翌日のチュートリアルでは、ジェフ・パットン(Jeff Patton)さんが彼のストーリーマッピング手法を組み合わせ、興味深いミニ・レトロスペクティブを指導しました。二人の手法の融合はどんな結果になるでしょう？

 

注意：このレトロスペクティブは、インデックスカードを活用して、机の上でアイデアを簡単に並べ替えたりグループ化します。壁とポストイット使う場合でも、少し工夫すれば大丈夫です。

 

ステップ1 - トーンを設定する：

Norm Kerth*1の最優先指令(prime directive)*2 を思い出します。（リンダはこれを暗誦してました）：

どんな道をだどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。

これを復唱したら、レトロスペクティブの間、この声明を支持し、非難なし(No Blame)ルールに同意するかどうかを、チームメンバー一人一人に尋ねます。簡単に「はい」と合意を示してもらえばOKです。「口に出して合意する」ことは、ふりかえりのトーンを設定するのに役立つ、簡単で影響力のある戦略、ないしパターンです。

 

ステップ2 - レトロスペクティブのフレーミング：

ファシリテーターは、あなたの会社の廊下で同僚に会ったというストーリーを話します。同僚からの「あなたはプロジェクト[X]にいますよね。プロジェクトはどうでしたか？」という質問に対して、それぞれのメンバーが「...という点が素晴らしかったです。」と答えます。大声で応える代わりに、各人に3枚ずつインデックスカードを渡し、黙って答えを書いてもらいます。こうすることで、人々の性格に関係なく各人から意見が出るようになり、回答があなたの影響を受けてしまうのも避けられます。

 

各人がそれぞれ3枚のカードを記入し終えたら、各カードを読み上げながらテーブルに置いていきます。すべてのカードがテーブルに置かれたら、各テーブルで黙って答えをグループ化しました。内容が近いカードは近い場所に動かし、内容が異なるカードは離します。 パットン氏によると、この作業を黙々とやるのは、そのほうが(話しながらやるよりも) 作業が迅速になり、多面的に整理されるからです。私たちの作業でも、その通りになりました。

 

「よいこと」がグループ化されたところで、別の色のインデックスカードを使って、各グループの要約をつけます。例えば、「一緒にうまく作業できた」「ボブが私の仕事に協力してくれた」「チームはストーリーを完成させるために団結した」といったストーリーを「素晴らしいチームワーク」と要約しました。

 

ステップ3 - ほかの方法：

先の声明で、「直近のプロジェクトやイテレーションはよいものだった」と合意しているので、もし全く同じ方法でもう一度やったなら、かならず完璧なプロジェクトになるはずだ、という点をチームに思い起こしてもらいます。でも実際は、他にもやり方があるものです。そこで「ほかの方法」の案を考え、一人3枚以上のインデックスカードを黙って書くようチームに依頼します。非難や間違いの指摘、問題解決の試みなどは書かないようにします。このステップでは、ほかの方法にはどんなものがあるか、見つけたいのです。

 

全員がカードを完成させたら、テーブルに置きます。そしてまた、みんなで黙ってグループ化し、別の色のインデックスカードに要約を記入します。ファシリテーターは、チームがカードを読んだり要約している間、問題解決や非難をしないよう、繰り返し指摘する必要があるかもしれません。

 

ステップ4 - 投票：

次のステップでは、チームが「ほかの方法」リストのどの項目が最も重要かについて合意します。公平で公正な投票のために、各メンバーには、上位３つの項目をインデックスカードに記入してもらい、ファシリテーターに集めます。ファシリテーターは投票結果を集計し、要約カードに投票数を記録します。ドット投票を使用することもできますが、私はドット投票があまりに簡単に「攻略される」ことと、最初の投票が後で投票する人々に影響することを発見しました（グループ思考）。

 

ステップ5 - 実験：

上位一位ないし二位の投票項目について、グループを分けて議論します。1項目につき1つのグループに分かれます。グループごとに、次のイテレーションで試せそうな小さな実験や調整を議論します。頻繁にレトロスペクティブを実施している場合、問題解決や根本原因分析をする必要はありません。目標は、問題の解決に向けた小さな実験について、すばやく同意することです。根本原因分析の専門家には怒られるかもしれませんが、問題解決に深い洞察力を使う代わりに、チームで何ができるかを実験してください。この部分は最大10分または15分のタイムボックスに収めます。

 

次に行う実験を決めたあとで、各テーブルの誰かにアイデアを発表してもらいます。出てきたアイデアはイテレーションのバックログに入れ、（個人ではなく）チームとしてイテレーション中に実験をし、完了することをコミットします。

 

 

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

ユーザーストーリーマッピング

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks)

*1:アジャイルのレトロスペクティブの源流になった "Project Retrospectives"という本の著者

*2:もともと第一原則と訳していたのですが、prime directiveはスタートレックの用語ということなので、そちらの訳 "最優先指令" に合わせます。安井力さん情報ありがとうございます。

Fearless Change のタイトルに「アジャイルに効く」を入れた理由

原題の Fearless Change にはアジャイルという表現はございませんで、リンダ・ライジングがアジャイル(とパターンのコミュニティ)で活躍している人だというニュアンスで、アジャイルについて気になっている人に届けたいという思いがありまして、タイトルに入れることになりました。

内容については、もちろんアジャイル開発に限定せず、新しいアイデアや技術、文化などを組織に導入する際に参考になるものになっています。

この「アジャイルに効く」というタイトルを決めるまでにはかなり議論があったのですが、アジャイル開発の導入に効く、と、使い方もアジャイルに柔軟に、というような意味合いでダブルミーニングを志向してみました。

出版後、「アジャイルアレルギーの人はこれで読まなくなるので、ないほうがよかった」というフィードバックもいただきまして、なかなかむつかしいなぁ、と思っております。

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

FEARLESS　CHANGE アジャイルに効くアイデアを組織に広めるための48の [ マリリン・マンズ ]

speakerdeck.com

レッツゴーデベロッパー平成ジェネレーションズFinal

発起人の綿引さん( @bikisuke ) にお誘いいただいて仙台のイベントに行ってきました。

レッツゴーデベロッパー 平成ジェネレーションズ FINAL - connpass

このイベントは、初回は東日本大震災直後に企画開催されて、そこからのお付き合いになります。東京では集まらないような登壇者が集まる、ちょっとおかしなイベントなんです。ハッシュタグは #5000dai です。

場所は楽天仙台支社。社員になる前からイベントで何度もお邪魔していて、ほぼホームです。

会場キャパきっちりというすばらしい集客具合。

講演の後、モブで五班に分かれて腕利き達がファシリテートするバトル。

チームスクラム

基盤チーム

チームDDD

チームTDD (別名チームIntelliJ)

チームマインドストーム

担当はMCだったんですけど、本職の高柳さんが進行としておられたのをいいことに、お茶出し、バトル勝手参加、セキュリティエリアでの片付け手伝い(社員なので)など、好き放題やらせていただきました。

最後にパシャり

懇親会も大変盛り上がりました。

沢山の舟盛りが出港

あの写真はこう撮られていた！

締めのお粥も最高でした。

モエレ沼公園

(2016年8月の日記がdraftに残ってました)

札幌にあるモエレ沼公園に行ってきました。イサム・ノグチの設計による公園で、以前、石井裕先生の講演で紹介されていて、いつか行きたいなと思っていた場所です。週末だけの札幌小旅行で行ってきました。

これが中央にあるモエレ山。舗装された階段もあり、登ることができます。雨で水たまりがそこかしこにあって、避けながら10分ほど登ると頂上です。高い建物のないエリアなので、あたりを遠くまで一望することがきます。山を見る方角によって見え方が変わる、デザインされた山という感じでした。

頂上の景観は写真では伝わない感じがします。

山の上から階段(このまっすぐなルート以外に登山ルートは二本あります)を見下ろすと、下には十字路があり、ちょっと十字架のように見えます。

十字路から山を見上げるとこんな感じ。

十字路から少し歩くと噴水のオブジェがありました。

 そしてメインの施設、ガラスのピラミッド。

展示場と駐車場になってます。

二階では結婚式してました。駐車場では学生の駅伝地方大会の表彰式。地域に根付いた公園でした。

 モエレ湖を渡るとバス停と貸し自転車施設です。

360度評価は多面的評価の仕組みではなさそう

360度評価ってあるじゃないですか。日本語でググると多面的評価とか出てきたりします。

いくつかの北米企業やコンサルの方に聞いてみたところでは(調査対象が偏っている可能性はあります)、360度評価の目的は、「課題のあるマネージャーをみつけること」です。つまり、部下が「あのマネージャーとは仕事しづらい」というのをフェアに報告できる制度です。もちろん部下のなかでも、仕事しやすいという意見とそうでない意見が混在する可能性も高いかなと思います。なので全員に聞く。

パフォーマンスを引き出すのがマネージャーの仕事

マネージャーの責務、会社が期待することは、部下の人たちに仕事をしてもらって、組織全体としてパフォーマンスを最大化することです。一方で、事業のトップや人事部にとって、マネージャーの評価ってとても難しいんです。うまい人は上司や人事部にはいい顔しつつ、部下にはつらく当たったりしますから。ですので、360度評価という仕組みを使って、直接情報を引き出します。

マネジメントを改善する責務がより上位のマネジメントに課せられる

課題を見つけたら、事業のトップはその課題を改善する(問題を取り除く)必要があります。放っておけば、実際に収益を上げている社員のパフォーマンスが落ちたり、辞めてしまうリスクが高まるのですから。

課題の取り除き方は、その人自体を配置転換/解雇することもあるでしょうし、再教育やメンタリングで改善することもあるでしょう。その実施責任は当該マネージャーの上司にあります。

...と理解したのですが間違ってたら教えてください

私の取材先が偏っている可能性はありますが、個人的にはとても納得しました。マネージャーは組織のパフォーマンスにとって、とても大事 .... だとすれば、きちんと課題を発見して、改善する仕組みを作るというのは、とても健全だなぁ、と思います。

間違っているかもしれないので、違うよー、って話があればぜひ教えていただきたいです。

電動スクーターシェアリング Bird と Lime

先週1年ぶりのアメリカ、1.3年ぶりのサンディエゴに行ってきたのですが、街中に見慣れないものが。キックボードみたいなこれが、電動スクーター Bird です。

結構走ります。どこにモーターやバッテリーが載ってるんだかわからないくらいコンパクトなのに、25km/hくらいでるそうです。セグウェイの技術で作られているようです。

Bird

スマホでポケモンを探すように近くのBirdを探して、筐体のQRコードを読むと、ロックが解除されて乗ることができます。

こちらはもう一つのサービス Lime。後発っぽいけど自転車も探せるし、バッテリーパックが追加されていて航続距離は長そうです。こちらは免許証登録が不要です(Birdは初回に免許証の写真を送ります。日本のでOK。アメリカの免許証だとバーコード写真に撮るだけで登録できるみたい)。

免許が不要なせいか、一緒にカンファレンスに行ってた楽天の内定者の学生さんたちは「ぼくらLime派なんで」って言ってました。

下りて、Ride終了！とすると課金が確定します。星が4つ以下の場合、どこがおかしかったのかを報告する選択肢が出ます。たまにハンドルのバーがぐらつくやつがあったくらいで、ほとんど壊れてるのにはあたりませんでした。（壊れているやつは使用不能ラベルになって、そもそも乗れないようです。）

自分で充電を意識することはなく、アプリに出てくる各個体の電池残量をみながら、いいBirdを探します。では充電は誰がしているのでしょうか？

じつは、アプリで「充電しませんか？」というのが常に出ていて、ここに登録すると家にバッテリー充電キットが送られてくるようです。充電するとキックバックがあるのでしょう。トラックで一気に運んで充電している業者さんみたいな人もいました。  

Birdは21時すぎは使えないみたいでした(LimeはOK)。全般的にBirdの方が先行しているのか、運転免許証登録が必要だったり(日本のでOK)、コンプラ対応が進んでいる印象です。

朝、建物を出るとこんな感じで並んでます。いつのまに。
筐体が小さいので駐輪スペースが少なくてよく、しかも一人一台所有しなくていいんです。

(昼もフル充電で並んでたりします。２毛作かな。)

Agile Conference でも話題でした。
カンファレンスのふりかえりのセッションで、一番よかった経験の第２位がScooter。

Agile2018のふりかえりでも話題に

Bird社は1.25年で評価が20億ドル。史上最速のユニコーン企業(10億=1B超え企業)になったそうです。追いかけるLime社もユニコーン企業になったそうです。

qz.com

www.businessinsider.com

全米に広がっているみたいです。東京にこないかなぁ。

toyokeizai.net

都市部では一気に増殖して問題になっているところもあるようです。サンフランシスコ市では一旦禁止した上で、業者を免許制にすることにしたよう。で、募集したらBirdとLime以外に10社の応募があったそうです。

In SF, Uber, Lyft and 10 others vie for five electric scooter permits - CNET

Twelve companies -- including Uber and Lyft -- are vying for just five permits that would allow them to operate a dockless, rentable electric scooter program on city streets, according to the San Francisco Municipal Transportation Agency (SFMTA).

2020年の東京オリンピックにあわせて、東京でも解禁できたらすごいですね。どうやったらいいんでしょう。

許可を求めるな謝罪せよの源流、グレース・ホッパー

海外カンファレンスの講演でちょくちょくでてくる軍服の女性がいる。

File:Grace Hopper.jpg - Wikimedia Commons

グレース・ホッパーさん。

グレース・ホッパー - Wikipedia

話を聞いてる英語圏のソフトウェア系の人はみんな知っているだろうけど、Wikipediaによれば、最初のコンピュータENIACを設計したエッカートとモークリーが立ち上げた商用コンピュータプロジェクトUNIVACに参加して、「機械語ではなく、英語に近い言語によってプログラミングできるようになるべきである」というポリシーのもとCOBOL作った人でもある(らしい)。

File:Grace Hopper and UNIVAC.jpg - Wikimedia Commons

Wikiquote によると “It's easier to ask forgiveness than it is to get permission.” 許可を求めるより許しを乞う方が容易い、と言っている。

https://en.m.wikiquote.org/wiki/Grace_Hopper

許可を求めるな、謝罪せよ

hyoshiok.hatenablog.com

の源流であった。

ちょっと補足(2020年3月7日)

「許可を求めるな謝罪せよ」 という言葉は、Agile Japan 2009 (第一回) の基調講演であったメアリー・ポッペンディークが長く働いた３Mの社是として紹介したところを、平鍋さんが逐語通訳でこう訳したのを私が聞き取っていたものです。あとでそれをちょくちょく言っていたところを、吉岡さんが拾ってくれて広めてくれた感じのものです。

この訳はどうなんだという議論もあったんですけど(私の記憶があっているのかとかもあります)、今の所まあ、この訳で悪くないんじゃないかな、と思っております。

謝罪するんじゃなくて許しを請うっていう意味だよね、という指摘ですね。

「許可を求めるな、謝罪せよ」はいわば超訳で、原文は「It is easier to ask forgiveness than it is to get permission」なので「事前に許可を得るより、あとで許してもらうほうが楽」と訳すのが良い派です

— Takuto Wada (@t_wada) July 12, 2016

「許可を求めるな謝罪せよ」は、クリエーションラインさんのモットーになってるそうです。

デブサミ再演！クリエーションライン安田氏が語るどん底からのジョイインクジャーニー7年記

世界をみちびいた知られざる女性たち (3) グレース・ホッパー プログラミングの女王