More Effective Agileを読みました

書評

Twitter で書評をまとめてたのを、集約するために転記。

More Effective Agile “ソフトウェアリーダー”になるための28の道標

More Effective Agile “ソフトウェアリーダー”になるための28の道標

アオアシから学ぶ、ふりかえりに大切な行動特性やマインドセット

みなさん、アオアシというサッカー漫画はご存知でしょうか？純粋に漫画としても面白いのですが、漫画の中のセリフや考え方がいちいち自分にいい意味で刺さってくるので、私が特に心に残った場面をふりかえりと絡めて紹介したいと思います。


言語化

アオアシ / alu.jp
alu.jp

最初は言語化について。この場面は、それまで感覚でプレーしていた主人公が、おぼろげながらもプレー時に考えてたこと・感じたことを言語化しようとしている場面です。「いいぞ、言語化できてる」

ここで取り上げられているように、言語化することによって、自分の考えをふりかえって整理できるようになります。いいことは、再現性を高く / 改善の余地あることは、同じ失敗を繰り返さないように。逆に言うと、言語化できないうちは何でうまくいったか・いかなかったかを意識しないので、同じところから成長できない。

また、いい言語化ができるようになると、他人に考えを分かってもらう・動いてもらうのがスムーズになります。

大事なのは、だからどうするか、だ / 厳しい意見をもらいにいく

アオアシ / alu.jp
alu.jp

自分的ナンバーワンワード。主人公に差をつけられたサブキャラが、差をつけられたということを認めた上で、じゃあどうするか？というのを宣言する場面です。

自分も他人と比べて凹んだり、やろうとしたことが全然できなくてで凹んだりで、よくボコボコになっています。ただ、そこで凹んだままだと成長がない。「自分はできない」を自覚した、その上で「だからどうするか」に意識を切り替えるようにしています。

で、どうするか？に対しては、厳しい意見でも率直にくれる信頼できるメンターがいると、より効果的です。メンターと話す際には、↑の言語化もセットで活きてくるでしょう。

いろんなことがいずれ考えなくてもできるようになる。そうしたら、ようやくそれが自分のものになる / 人間は考える葦である

アオアシ / alu.jp
alu.jp
アオアシ / alu.jp
alu.jp

「真摯に考え続けていたら、だんだんそれが染み付いて、考えなくても自然とできるようになる。だからガンバレ」というのを、ヒロインが応援してくれる場面。なお、主人公の名前は「青井葦人」で、「人間は考える葦である」や漫画タイトルの「アオアシ」は、そこにかけているものと思われます。

サッカーに限らず、個人やチームに染み込んだ理念や行動は、いずれ考えなくてもできるようになるでしょう。KPTで言うと、最初はKeepに掲げていちいち意識しないと続けられなかったことが、だんだん当たり前になってくるイメージ。

なお、このブログは以下の記事にインスパイアされています。漫画好きなんですよね。
dev.confengine.com
next.rikunabi.com

あと、著作権を配慮した漫画のコマ引用ができるとのことだったので、一度試してみたかったのもあったのでした。
alu.jp

以上、みなさんのおすすめの漫画・セリフもぜひ聞かせてください！

フェニックスプロジェクトワークショップを体験してきました

今日、クリエーションラインさんのフェニックスプロジェクトワークショップというのがありました。それに参加してきたので、忘れないうちにメモっておこうと思います。

www.creationline.com


目的

今日の参加者は、普段とは違ってアジャイルコーチの人たちばかりで構成されてました*1。

めんどくさいアジャイルコーチな人たちはよく「自律的なチームがー」みたいに言ってるけど、その人たちが集まったときにほんとにそういう風に振る舞えるの？というのが気になってたので、この機会にいっちょ確かめてみようかというのが目的。

感想

あー、ただただ、多人数での作業の進め方に熟練した人たちばかりでやると、ここまで物事が早く進むんだなあというのを実感した場でした。いくつか例をあげると、こちら。こういうのって、別に今回のワークショップに限定した話ではないんですよね。

  • 話しやすいように、ワークショップ始まって最初の第1声で「はいまずテーブル寄せようー」と会場のレイアウト変更
  • 一人で抱え込んでたら情報量過多でどうにもならなくなるってのが直感的にわかってるので、まず全部共有
  • ちょっとあちらこちらでわーわーいってても、「大事なことなんで聞いてくださいー」って手あげたらみんなそっちを聞く
  • なんか不安要素があったら、協調作業する / 並列で進めるより一個一個確実に終わらせていく方向に自然となる
  • バリューストリームに並べたほうがプロセス見えやすいよね、じゃあそう並べようと自然に
  • 何か問題が起きて詰まってたら、周りの人にすぐ相談・周りもすぐに集まって助けに入る
  • タイムキーパーも誰か特定の人がするのではなく、空いた人が自発的に確認して「あと〇〇分だよー」って知らせてくれる
  • 会話だけで空中戦になって何を話しているかの認識が合わなくなってきたら、一回立ち止まろうと誰かが言い出して書いて見える化
  • 何らかの決定時にちょっと意見がわかれても、長々と話し込まずに親指サイン*2で3秒で決を採る
  • 改善のやり方がこなれている：まず現場や起こったことをふりかえって、課題をリストアップして、改善アクションを決めて、アクションを実際にシミュレーションして、その結果をフィードバックしてまた調整するループを回していって・・・
  • 既存の発想にとらわれない：持ち歩いてたドットシールをカードに貼って分類の手助けにしたり、必要な紙が1枚しかないのであれば会場飛び出してコンビニにコピー取りにいくし、挙句の果てにはテーブル狭いよねじゃあ床使おうとなるし

問題もなかったわけじゃなくて、「ちょっと目の前の作業や割り込みに注力し過ぎて、大局的に見てROIが高い施策を進められてるか？」といったところは、改善の余地はありそうではありました。

ちな、自分の中での今日1のパワーワードがこちら。床は最強ですね。

壁にはりものしにくい現場はあるけど、床がない現場はない（ので、壁がなければ、床を使えばいいじゃなーい）

というわけで、開始1分でレイアウトがこうなって・・・

f:id:ikikko:20190705223835p:plain

お昼過ぎたころにはこうじゃ

f:id:ikikko:20190705134235j:plain

自社（自分もメンバーの一員）の中で活かすには

よくあるトラップであろう、役割のサイロ化は、文化的に多分避けられそう。

ただ、作業のやり方をこうまでうまくできる自信はない。その中でも、積極的に上であげたような振る舞いを自分で実演して、いい意味で周りをその雰囲気にのませて当たり前に思ってもらい、みんなが実践しだすように持っていくのがポイントかなと感じました。

どこかの現場を支援する立場のときに活かすには

今回僕たちがやった体験と照らし合わせて、その現場はどこがひっかかるのかを比較するのがおもしろそう。録画とってないから、完全に比較するのは難しいけど。

あとは、実際の組織構造をそのまま連れてたときに、どう変わるかは観察してみたい。今回の僕たちは、みんなロールをガン無視して進められました。けど、実際の組織に当てはめたときは、普段のロールにとらわれてて不要にサイロ化しちゃわないか、など。

ということで、クリエーションラインさんありがとうございました。みなさんも興味があったらぜひ参加してみてください！


（※：写真はフェニックスのポーズ）

*1:ぼくは別にアジャイルコーチとして動いてるわけじゃないけど、主催者にお声掛けしたときに、ちょうどアジャイルコーチで集まってやる機会があるよーとのことだったので、そのタイミングで混ぜてもらいました。

*2:親指サインはじめ、決定を早くする手法は以前まとめたので、https://backlog.com/ja/blog/3-ways-of-effective-meeting/も参照。

「リーンエンタープライズ」を読みました

書評

Switchを買っちゃって、プライベートの時間がどんどんなくなっちゃって、ヤヴァイってなってます。この本も、もう1年以上前に読んでたのに、いまさらの感想ブログになってますし。

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

確か、この本読もうとしたときに、ちょうど↓のスライド見た記憶があります。幅広くカバーしてるってので、もれなく吸収したいなと思ったのでした。


2章 企業ポートフォリオのダイナミクスを管理する

この章では、やっぱり3つのホライゾンですよね。

ホライゾン1 ホライゾン2 ホライゾン3
概要 既存のビジネス：今日のキャッシュフローを生み出す 高成長ビジネス：今日の収益成長と明日のキャッシュフローを生み出す 成長のオプション：将来の高成長ビジネスのオプション。キーワードは、リーンスタートアップや製品／市場フィット（Product / Marget Fit）
目標 経済的リターンの最大化 キャズムを超える、収益に貢献し始める 新しいビジネスを作る
主要指標 計画に対する収益、市場シェア、利益率 売上高利益率、ターゲット顧客数 クチコミ（消費者）、有名顧客（法人）

自分の性質がホライゾン1,2に向いてるのもあって、ホライゾン3はちょっとおろそかになりがち。なので、そうなりがちというのを意識しておかないとなと、再確認しました。合わせて、自分が今手がけてる事業は、ホライゾンのどこに当たるのかな、それにふさわしい指標やら施策になってるんだっけ？というのを踏まえながら。

5章 製品／市場フィットを評価する

海賊指標：AARRRと、課題／解決フィット・製品／市場フィットの関係について、再確認。それぞれ単語は頭に入ってたのですが、それらの関連などを確認・考えるきっかけになりました。

名前 目的 Votizenでの例 気にかけるべきフィット
Acquisition：獲得 サービスを訪れた人の数 アカウントを作成した
Activation：アクティベーション はじめてなんらかの体験をした人の数 信頼性を確証した 課題／解決フィット
Retention：定着 何度も戻ってくる人の数 少なくとも3回システムを使用した 課題／解決フィット・製品／市場フィット
Revenue：収益 収益を生む活動にかかわる人の数 活動を支援した 製品／市場フィット
Referral：紹介 他のユーザーを紹介する人の数 友人に転送した 製品／市場フィット

フィット関連について思い出したのは、下記の記事。製品の時間軸の流れを考えて、AARRR -> ARRRAというようにAcquisitionを最後に持ってきたのと同じことかなと思いました。自分の中の知識がチョットつながってきた。

growiz.us

あとは、ソフトウェア開発には外せない、エンジニアリングプラクティスについて。「あとで技術的負債を支払うために、最初から従っておくべき2つのプラクティス」はこちら。ホライゾン3では製品レベルだけど、ホライゾン2でも機能レベルで技術的負債を扱うことになるので、どのみち避けては通れない。

前者は、エンジニアとしての自分が価値を出せる＆自分もやってて楽しい領域。他は多少優先度下げてでも、ここはちゃんと第一線はれるように腕を磨いておきたい。

後者は、ユーザージャーニーテストって知らなかったんだけど、Fowlerの定義や下記の図いわく、一番下（ユニットテスト）と一番上（ユーザージャーニーテスト）を抑えておくべしということかな？

f:id:ikikko:20190609160927j:plain
( by You cannot Automate a User Journey Test – Toby The Testers Blog )

6章 継続的改善をデプロイする

ソフトウェアに依存している会社がハイパフォーマンスを達成するには、何よりもまず、実行する能力、信頼できるシステムを構築する能力、複雑さを継続的に軽減していく能力にフォーカスすべきです。ビジネスの優先度と連携するのは、それができてからでいいでしょう。

よく「どこから改善していくべきですか？」という質問を受けたり見たりしたとき、雑な手書きだけどこういう風に認識している。いつまでもビジネスの優先度を考えないのも困りものだけど、まずは先立ってIT部門にある程度の実行能力がないと、ビジネスがうまく回っていかないので。
f:id:ikikko:20190515000043j:plain

他には、活動会計。最終的には時間ではなくて、成果 = アウトカムに結びついてるかを考えたいけど、その手前としてどういう活動にどれぐらいの時間を使ってるかというのは、自分たちでコントロールしやすくてとりかかりやすそう。下記は、本書で取り上げられてた活動会計の表。

コストの割合 活動 以前
2% 継続的インテグレーション 10%
5% アジャイルな計画 20%
15% ひとつのメインブランチ 25%
10% 製品サポート 25%
5% 手動テスト 15%
23% 自動テストスイートの作成と保守 0%
~40 イノベーション ~5%

自分でもちょっとお試しとして、自分でも各人の月次稼働実績をまとめて集計して、何か見えないかを試してみました。もう1,2ヶ月分出してみて、ちょっとふりかえってみよう。

最後に、改善のカタ。これ、フォーマットとしていいんじゃないかと思いつつ、以前やったけどうまく実践できなかった。改めてもう一回トライしてみようかしら。

www.slideshare.net

7章 価値を明らかにしてフローを増やす

バリューストリームマッピング、カンバン、遅延コストの章。これだけでご飯が3杯ぐらい食べられそう。

それぞれ、以前読んだ本にも取り上げられてるぐらい。けど、バリューストリームマッピングは結局素振りもちゃんとできてないので、やらんといけんってのを改めて思い出せました。やるぞー。

ikikko.hatenablog.com
ikikko.hatenablog.com

第IV部 変革

にまつわる話。ですが、まだまだピンとこなかったところが多いです。少しずつ関わるようにもなってきたのですが、まだまだ経験不足ですね。後日もう一回読み直してみましょうかしら。

最後のIT部門に関しては、おそらく今後レビュー書くであろう「LeanとDevOpsの科学」で触れるはず。もう読んだけど、感想文書くときにあらためて考えることにします。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

1回目に読んだときは全然ささらなかった探索のところが、2回目読み直すとチョット分かるようになってきたのは面白い変化。前向きに捉えると、以前よりは成長してるということなんでしょうかね。

RSGT2019の当日ボランティアスタッフをやってきました

2019.scrumgatheringtokyo.org

応募したきっかけ

去年もボランティアスタッフに応募していたのですが、家族がインフルっちゃったので、（自分はかかってなかったけど）念のために直前キャンセルをさせてもらいました。なので、今年が初めて。

スタッフに応募した目的としては、よりRSGTを味わいたかったから。スピーカー枠でいけたら一番よかったんだけど、残念ながらプロポーザル落ちたので、ならばとスタッフで応募したのでした。スタッフ業が少し慌ただしい時間もあったのですが、とは言ってもフル稼働しておかないと追いつかないような体制では全然なかったので、適度にセッション見学や参加者と交流しつつができました。

スタッフみんな自律的！

スタッフ業やってて一番ほーとなったのは、スタッフみんなが自律的に動いてるというところ。ほとんどのスタッフが2回目以上だったり、会場が前年と一緒で慣れていたりというのもあるのでしょうが、各々が判断して作業を進めていました。

理由の一つに、トランシーバーが効果的なのかなと思いました。「ヘルプお願いー」とか声掛けあると、すぐにみんな反応するとかはわかりやすい話。あとは、判断に迷ったときでも「トランシーバー上で共有しておけば、ダメだった場合誰か止めてくれるか」と思って、自分の判断で動きやすいという心理的な安心感はありました。トランシーバーがないと、やっていいか分からないのでちょっと置いておくか、みたいな状況も多分多かっただろうなーとも。

細かいところを見れば、自律的に動いた結果、作業がかぶる（誰かがやったことを、よかれと思って戻す）こともちょいちょい見受けられたのですが、概ね問題なく進められて、全体としてはもろもろかなり早く進められたんじゃないかなと思ってます。自律的な組織・チームをトランシーバーという仕組みで作る、いい体験をできました。

スマホアプリもあるようなので、小規模のイベントではこっち使えるかもですね。

update.hirochan.org

体力的にはしんどい＞＜

前日準備も含めたら、4日間ほぼ立ちっぱで、棒が足のようになりました。普段座り作業に慣れてる体には、かなりしんどかったです。あと、朝の集合時間がモロに通勤ラッシュの時間帯で、前職以来久しぶりに車掌に体を電車内に押し込まれる体験をしました。

それでも、みんな毎日のように会場1Fの中華料理屋に懇親会に行ってて、スゴイなーと思いましたｗ

参加者の方々、また当日だけでなく事前からコンテンツやら色々考えてもらった実行委員の方々、みなさんお疲れ様でした。

さて、これから発表スライドを一通り眺めて、ふりかえりをしようかな。

https://scontent-nrt1-1.xx.fbcdn.net/v/t1.0-9/49373593_2277340718996243_5580087808078381056_n.jpg?_nc_cat=108&_nc_ht=scontent-nrt1-1.xx&oh=f196090e0416c40cc404ed5bb3bd77f7&oe=5CD17B57

「デザインスプリント」を読みました

書評

基本、読んでる本はWIP 1で進める派（今読んでる本を読み終わる or 諦めるまで、次の本に手を出さない）なのですが、割り込みでデザインスプリントの本を読みました。

背景としては、業務でプロダクトデザインフェーズでのアイデア出しワークショップを開いたことのふりかえりから。ワークショップ内で発散まではまあどうとでもなるとして、収束させることがそのときの自分の引き出しではできなくて、結局ワークショップ内では発散しっぱなしで諦めました。で、そのことを某関西弁のパイセンコーチに壁打ちしたら、「デザインスプリントにアイデアがあるかもね」というありがたい言葉をいただいたので。

というわけで、今回はDay 3の「決定」を一番中心に読みました。言い換えると、「この本を読んだ後に、例のワークショップを開催するとしたら、どこをどう改善するだろうか？」というのを考えながら。

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

ちな、以前下記のスライドは目を通してました。なので、デザインスプリントとは何？ってのをざっくり知ってるけど、実体験として理解はできていないレベルです。

www.slideshare.net
www.slideshare.net


決定に関わること

Day 3 決定：チームでのスケッチ作成

この作業のサイクルを複数回繰り返す時間はないことが多いでしょう。したがって、ユーザージャーニーマップを分割してチームごとにそれぞれ異なる部分を作業してもらいましょう。そして、最後にそれぞれのチームからフィードバックをまとめることで時間短縮が可能です。

ここが一番知りたかったところ。一気に全員で全範囲を収束の議論するのではなくて、分割した上でそれぞれを3~5名程度のグループ単位に割り当てていくわけね。その切り口の一つとして、ユーザージャーニーマップごとに分割するとか。

なるほどー。時間の問題もあったんだけど、一番のネックって思ってたのは、人数が多い状態（6名以上を想定）で収束の議論が難しいそうだなと感じてたんでした。それは、分割して議論の人数を絞った上でそれぞれで議論すればいいのか。もちろん、一人が全部をがっつり見ることはできなくはなるけど、それは各グループの結論を信頼して任せる感じ。

Day 2：発散でも似たように、分割してやってるところがあった。発散を複数回繰り返すときに、一気に全部を考えると、2回目以降同じ範囲を考えても同じアイデアしか出てこないんじゃないかなーと思ってました。けどこれも一緒で、1回目はジャーニーマップの前半で、2回目はジャーニーマップの後半とかやると、考える範囲が違うので、複数回してもよさげ。

Day 3 決定：最終スケッチの作成

「選択肢を2つか3つにまで収束できたなら」的な説明がありました。収束となると、この辺が現実的かなとは感じてます。

10も20もアイデア出てきても、全部を実装できるほど僕らの人生は長くないし、ましてや作りっぱなしではなく検証まで含めるのならばなおさら。なので、もう数個に絞る。どれぐらいに絞るかは、プロジェクトの予算やスケジュール感にもよるかな。

決定に関わらないけど、心に残ったもの

Day 1 理解：アイスブレイク
ここだけの話ですが、実は…
自己紹介に続けて、参加している他の参加者が誰も知らないと思われるちょっとした秘密を話してもらう。
希望と心配
2色のポストイットに、それぞれ希望・心配事を書いてもらう。で、それを匿名状態で集めて、任意に一枚ずつ選んで書いた人以外がその意味を推測しながら説明していく。このことによって、他の参加者の共感を持てるようになる。

前者の「ここだけの話ですが、実は…」の派生として、ワークショップで取り上げようとしてる内容に関してのことだと、より味わい出そう。あとは、少人数（1~3名）のみ知ってるとかだと、あまりにもニッチな領域じゃないところを狙いに行きたくなって少しゲーム要素も出そうでよさげ。

後者の「希望と心配」は、単に自己紹介で終わるのではなく、自分以外の誰かのことを考えるってのがよさそうと感じました。ドラッカー風エクササイズの「期待されてると思うこと」と派生の「相手に期待すること」でもそうだけど、他の人の立場で考える機会ってなかなかないけどチーム力を高める上で大事なことだと思ってるので。

Day 1 理解：課題の定義

また、モバイルデジタルプロダクトの1つだったAndroid携帯をFacebook携帯に帰るFacebook Homeを使ったことがある人もいるでしょう。結局我々はFacebook Homeを使いませんでした。このアプリにはまったく使う意義を感じられません。「ユーザーを自社アプリに囲い込む」というFacebookにとっての課題は解決されたのかもしれませんが、ユーザーにとっての本当の課題やニーズにはまったく考慮されていません。

Facebookのとあるプロダクトを例にあげられてて、ぐさっときました。あまり聞いたことないプロダクトの失敗事例を聞いてもぴんとこないところもあったけど、Facebookでさえもそういうことあるという（実際にFacebook Homeなんて知らなかった）。

自分たちに都合のいい解釈で、「自分たちのビジネス的にこうなるといいな」からの「これ作れば使ってくれるだろう」っていう流れに陥らないように、↑の説明文に続いて述べられてた↓の文も合わせて。

ユーザーや顧客のためではなく、自社にとっての課題を解決するためにデザインスプリントを行おうとしている企業は今も多数見受けられます。

Day 1 理解：HEART Framework & Goals-Signals-Metrics

「UX のゴールやメトリクスを設定するときには HEART Framework と Goals-Signals-Metrics プロセスが使いやすい」という触れ込み。ちらっと見ただけだけど、確かによさげ。頭の片隅に入れておこう。

Day 2 発散：ストーリーボード

絵コンテとも。テキストだけより絵も含めて書いた方がより記憶に定着するだろうし、複数のコマで表現されてるとインタラクションがイメージしやすい。これも、アイデアを表現するフォーマットの一つとして、引き出しに入れておこう。

ストーリーボードの説明は、よさげなサイトがあったので、そちらにおまかせ。

esaura.jp

Day 5 テスト：プロトタイプの評価 - よく起こること：辞退者が出た

我々は辞退者の発生を見込んで、7,8 人にインタビューを行うようにしています。そうすれば、辞退者がいても最低でも5,6人からフィードバックを得られます。

いい目安。とりあえずメモだけ。

やっぱり、実際にやること・やったことと照らし合わせて読むと、理解度とかも違いますね。自分が知りたかったことが知れた（収束に至るまでのやり方）のもよかったし、それ以外でもいくつか引き出しができた。今後デザインスプリント自体をがっつりやるかはさておき、一つレベルアップできたんじゃないかな。