逆境からのアジャイル

逆境からのアジャイル 逆境から仕事をアジャイルに していくための4章+1 Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

Ichitani Toshihiro 市⾕聡啓 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 0→1 http://about.me/papanda0806 Toshihiro Ichitani All Rights Reserved.

• http://about.me/papanda0806

“アジャイル開発”で⾔っていること なんて⼤なり、⼩なりだいたい 皆取り組んでいるんでしょう？ Toshihiro Ichitani All Rights Reserved.

“アジャイル開発”で⾔っていること なんて⼤なり、⼩なりだいたい 皆取り組んでいるんでしょう？ ⼆極化しているかも？ アジャイルにしていく取り組みを呼吸するように 進められているところはある。 ⼀⽅で、まだ ”アジャイル” に全く⼿を出せていない ところだって結構ある。 当てずっぽうに想像すると、キャズムを越えて、 アーリーマジョリティの端緒についたくらい？(肌感) Toshihiro Ichitani All Rights Reserved.

“これからのアジャイル”は、分が悪い 始められるなら、もう始めている。 始められないのは、理由がある。 それは、始めることに対して逆境にあること。 追い⾵ 「現場ではじめよう、明⽇からはじめよう。 新しい取り組みだから多少失敗したって、 学びにして、次にいかそう」 逆境 「会社の取り組みなんだから、期待される効果を 定量的に⽰して、上⻑の許可を得て、実施時に 定期的なレポートを⾏なう ﹅ ﹅ ﹅ ﹅ …という申請を出して、通らない」 Toshihiro Ichitani All Rights Reserved.

このお話のテーマ 逆境で、 開発をアジャイルにしていくための作戦。 ※逆境の中、それでも開発のあり⽅をより良い⽅向へと 変えていきたいと諦めずに考えている⽅々へ。 Toshihiro Ichitani All Rights Reserved.

コンセプトは、”ドラクエ4” 1⼈から チームで プロダクト オーナー (PO)と 組織で 踏み越える境界を段階的にする まずは1⼈から。1⼈からチーム。チームの外と。 そして、組織へ。 Toshihiro Ichitani All Rights Reserved. Photo credit: hohbukuro via Visualhunt / CC BY-NC-SA

• https://www.flickr.com/photos/hohbukuro/14254869745/

“さくせんをねる” じゅもんをせつやく 呪⽂の使⽤を控えめにする。必要最⼩限の呪⽂しか使わず、回復呪⽂より回復アイテムを先に使う こともある。最終的にMPの消費が少なくなると判断した場合は、強⼒な攻撃呪⽂を使うこともある。 いろいろやろうぜ ⾏動が戦況に関わらずランダムで選択される。結果として、普段使わないアイテムを使ったり、 無意味な呪⽂を唱えたりもする。 いのちをだいじに 仲間が倒れないことを最優先として、HPの回復を徹底して⾏う。最上級の攻撃呪⽂を連発し、 被害が⼤きくならないよう⼿早く戦闘を終える⼿段をとることもある。 Toshihiro Ichitani All Rights Reserved.

• https://ja.wikipedia.org/wiki/ヒットポイント

“じゅもんをせつやく” ⼀気にやらない。 はじめる規模が⼤きいと、⾃分たちの⼒が及び難く、 関係者も多く、期待マネジメントのコストが⾼い。 はじめる規模が⼩さいと、⾃分たちの⼒が及び易く、 関係者も少く、期待マネジメントのコストが低い。 アジャイルのはじめ⽅もリーンスタートアップに。最⼩は1⼈。 期待マネジメント…関係者から寄せられる(たいてい暗黙的な)期待を適切に調整し続けること。 リーンスタートアップ…ざっくりいうと、⼩さく失敗して学びを得て、次に活かすアプローチ。 Toshihiro Ichitani All Rights Reserved.

“いろいろやろうぜ” 仮説を⽴てて、検証し続ける。 やたらめったらに、プラクティスだけ取り⼊れても 効果的ではないし、上からの「何やっているの？」に 答えられない。 アジャイル開発の型(後述)と⾃分たちの現状とを⽐較し その間にあるGapを解消するための取り組み(仮説)を 漸次的に⾏なう。結果(検証)を元に次の取り組みを始める 「何やっているの？」 「開発の上でフィードバックループが回るように、タイムボックスを切って、 Toshihiro Ichitani All Rights Reserved. まずはスプリントレビューをこなせるよう、うごいています。」

“いのちだいじに” 取り組みを⽌められる=死 だけを回避する 関係者からSTOPが⼊るときがすべての終わり。 少なくとも終わることがないようにだけ最⼤限注意する。 例えば コミットを破る … 何の⾒⽴てもない約束をしない。 期待に合わない … そもそも何を期待したらいいか 誰も分かっていないことも。 「⽣産性◯倍や！」=虚栄の評価指標 Toshihiro Ichitani All Rights Reserved.

死(⽌められる)以外は、 負け続けても良い！ 負け=失敗経験こそ、学びだから。 負ければ負けるほど、次が上⼿く出来る。 Toshihiro Ichitani All Rights Reserved.

…さっそく、取り組みをはじめようの前に 必ず「Start with Why」で。 Why How What Why、つまりなぜそれをするのか、を 取り組みの最初に考えるようにする。 ある⽬的を実現するためにHow⼿段が ある。Howを実際に実⾏可能にすると Whatプラクティス・タスクになる。 Why無きWhatからの学びは少ない。 Toshihiro Ichitani All Rights Reserved.

あなたのWhyは何？ Toshihiro Ichitani All Rights Reserved.

第1章 1⼈から 1⼈から チームで プロダクト オーナー (PO)と Toshihiro Ichitani All Rights Reserved. 組織で

1⼈から。 じゅもんをせつやく ⼀気にやらない いろいろやろうぜ 仮説を⽴てて、検証し続ける ⾃分次第。関係者はゼロか少数。 ⾒える化から始める。 1⼈向きではじめやすく、問題解決 につながりやすい。 1⼈活動なので、誰からも いのちだいじに 死だけを回避する 最強の最⼩単位。⾃分のことなので 邪魔されない。 失敗の範囲も⼩さい。 Toshihiro Ichitani All Rights Reserved.

具体的には何からはじめるべき？ Toshihiro Ichitani All Rights Reserved.

具体的には何からはじめるべき？ 基本は「⾒える化」から。 ⾃分の仕事の状況、流れの⾒える化=「1⼈カンバン」 まずはタスクボードレベル(TODO/DOING/DONE)からでも良い。 本格的なカンバンを作りたい⼈は「リーン開発の現場」を読もう！https://www.amazon.co.jp/dp/427406932X リズムで仕事する=「1⼈タイムボックス」 反復開発は⼀定のリズムで⾏なう。まずはリズムで仕事をする ことから慣れる。例えば、タイムボックスを「1週間」として 仕事のサイクルをつくる。カンバンで計画→実施→ふりかえり。 ※よくわからないプラクティスがあればアジャイルプラクティスガイドを読もう！ Toshihiro Ichitani All Rights Reserved. https://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html

• https://www.ipa.go.jp/sec/softwareengineering/reports/20130319.html
• https://www.amazon.co.jp/dp/427406932X

やり⽅が分からない…というか 1⼈で初めての取り組みは不安。 Toshihiro Ichitani All Rights Reserved.

やり⽅が分からない…というか 1⼈で初めての取り組みは不安。 幸いにして、仲間はいる。ただし外に。 「逆境」ならば社内より、外の⽅が出会いやすい。 ちまたの勉強会やコミュニティの活動に参加しましょう。 (社内勉強会は、初期の頃は⼼が折れやすいので無理にやらない) ただし、進めるのは⾃分。1⼈。 仲間とは出会えるが、現場で実践するのは結局、⾃分。1⼈。 外で勉強しているだけでは、1ミリも現場の取り組みは進まない。 まずは1⼈。次に2⼈⽬を巻き込む。2⼈いればやれることが増える。 Toshihiro Ichitani All Rights Reserved. (2⼈⽬を巻き込めると2章(チーム)は近い)

はじめるのにベストなタイミングは？ Toshihiro Ichitani All Rights Reserved.

はじめるのにベストなタイミングは？ いつでも！ 1⼈の最⼤のメリットは、今すぐ始められること。 今すぐ始められるし、⽌めるのも⾃分で決められる。 ⽌めても⾃分の意思で再開できる。 1⼈の時だけは、死(再起不能のSTOP)がない。 Toshihiro Ichitani All Rights Reserved.

第2章 チームで 1⼈から チームで プロダクト オーナー (PO)と Toshihiro Ichitani All Rights Reserved. 組織で

チームで。 じゅもんをせつやく ⼀気にやらない (リーダーやマネージャー)との期待 マネジメントが必要になる。 いろいろやろうぜ 仮説を⽴てて、検証し続ける いのちだいじに 死だけを回避する チームメンバー及び、⼀つ上の⻑ まず、チームの⾒える化、リズム 仕事に取り組む。次にフィードバッ クループの構築にトライする。 チームのミッションを 果たせなくなると、死。 Toshihiro Ichitani All Rights Reserved.

２⽅向の期待マネジメント ② ① ① ①チームメンバーとの間の期待マネジメント ②リーダーもしくはマネジメントとの間の 期待マネジメント ①の⽅針 「やってみたけど全然だめじゃん」という⼤いなる失望が 起きないよう、⼿に負える範囲で。適⽤するプラクティス の数を限りなく絞る。 ②の⽅針 チームのミッション(ex. いつまでにプロダクトつくる)の コミットを第⼀に、取り組みを第⼆の優先順位で。 Toshihiro Ichitani All Rights Reserved.

チームでは、何からはじめるべき？ Toshihiro Ichitani All Rights Reserved.

チームでは、何からはじめるべき？ ⾒える化から、フィードバックループの構築。 １⼈と同じように、まずは⾒える化。 鉄板の⾒える化プラクティス ①チームのカンバン ②デイリーミーティング ③ふりかえり フィードバックループの構築に挑戦する。 フィードバックループ、つまり、仕事の結果から次に何をする べきかを意思決定し、結果の改善を⾏っていくこと。 このループを建付けるために、システム(仕組み)が必要になる。 ⾶躍的に取り組むことが増えるため難易度が⾼まる。 Toshihiro Ichitani All Rights Reserved.

フィードバックループをチームで回すシステム サイクル Plan Do Check Action 計画づくり 実⾏ レビュー ふりかえり Toshihiro Ichitani All Rights Reserved. …

フィードバックループをチームで回すシステム サイクル Plan Do Check Action 計画づくり 実⾏ レビュー ふりかえり … スプリント Plan スプリント 計画ミーティング Do Check Action スプリント スプリント開発 スプリントレビュー Toshihiro Ichitani All Rights Reserved. レトロスペクティヴ デイリースクラム …

ここでスクラムガイドを引っ張り出すと 分からないこと、慣れないことが⼀気に増えて 「プラクティスの海」に溺れることになる。 (思考が⽌まる) Toshihiro Ichitani All Rights Reserved.

プラクティスをこなすことを⽬的にしない ① 完璧を⽬指さない 最初から完璧に仕組みをつくることを⽬指さない。 不完全な仕組み化によって起きる弊害をカバーできる ように、 (a)仕事上のバッファを確保する。 (b)スプリントを⽌めることを躊躇しない。 (⾃信をもって終わらせられるやり⽅に戻す) ② 適切なメンターか経験者を調達する Howの詰め込みではなく、Whyからの取り組みを ⽀援してくれる存在が望ましい。 Toshihiro Ichitani All Rights Reserved.

第3章 POと 1⼈から チームで プロダクト オーナー (PO)と Toshihiro Ichitani All Rights Reserved. 組織で

POと。 じゅもんをせつやく ⼀気にやらない いろいろやろうぜ 仮説を⽴てて、検証し続ける いのちだいじに 死だけを回避する PO(顧客、ビジネス側)との 期待マネジメントが必要になる。 フィードバックループを素早く 回せるように、POとのコミュニ ケーションに取り組む。 (同じく)チームのミッションを 果たせなくなると、死。 Toshihiro Ichitani All Rights Reserved.

POを巻き込むのに、 どんな期待マネジメントを⾏なうべき？ Toshihiro Ichitani All Rights Reserved.

POを巻き込むのに、 どんな期待マネジメントを⾏なうべき？ 2つの期待マネジメント インセプションデッキで、期待マネジメント。 プロダクトの⽅向性をPOとチームで整え、どう実現するか お互いの共通理解を深める。 ドラッカー⾵エクササイズ、で期待マネジメント。 メンバーそれぞれの⽴ち振るまいや価値観を可視化し お互いの共通理解を深める。 Toshihiro Ichitani All Rights Reserved.

インセプションデッキ プロジェクトが然るべき⽅向を向いているか チーム全員で明らかにする。 ※インセプションデッキについてはアジャイルサムライを読もう！ Toshihiro Ichitani All Rights Reserved. https://www.amazon.co.jp/dp/4274068560

• https://www.amazon.co.jp/dp/4274068560

ドラッカー⾵エクササイズ 4つの質問をチーム全員で答える。 ⾃分は何が得意なのか？ ⾃分はどうやって貢献するつもりなのか？ ⾃分が⼤切に思う価値は何か？ チームメンバーは⾃分にどんな成果を 期待してると思うか？ 実際にメンバーにも表明してもらってGapを 明らかにする。 ※ドラッカー⾵エクササイズについてもアジャイルサムライを読もう！ Toshihiro Ichitani All Rights Reserved. https://www.amazon.co.jp/dp/4274068560

• https://www.amazon.co.jp/dp/4274068560

巻き込まない(巻き込めない)という選択 外堀(線表)と内堀(調整余地)で 本丸(アジャイル開発)のハードルを⾼めすぎない ※「鉄壁の中のアジャイル」 https://www.slideshare.net/papanda/ss-79239778 Toshihiro Ichitani All Rights Reserved.

• https://www.slideshare.net/papanda/ss-79239778

POとは、どういうコミュニケーション を取ればいいのだろう？ Toshihiro Ichitani All Rights Reserved.

POとは、どういうコミュニケーション を取ればいいのだろう？ ユーザーストーリーで会話しながら フィードバックループを早く回していくためには コミュニケーションの中⼼となるバックログは ユーザーストーリー形式で、記述を軽くする。 記述を軽くする分、内容を対話で補完する、 Toshihiro Ichitani All Rights Reserved.

ユーザーストーリー駆動開発 ユーザーストーリーとは、①やりたいことをまとめる ⼿段であり、②計画を⽴てるための材料であり、 ③実績を測るための対象である。 ※ユーザーストーリーの詳しくは「ユーザーストーリー駆動開発で⾏こう。」を読もう https://www.slideshare.net/papanda/ss-41638116 Toshihiro Ichitani All Rights Reserved.

• https://www.slideshare.net/papanda/ss-41638116

POとの約束を守れるかしら… Toshihiro Ichitani All Rights Reserved.

POとの約束を守れるかしら… コミットは深さと広さで ⼀番の難題はバックログがあいまいな状態で、 どうやって、どこまでを関係者と握るか。 (お互いにやり⽅に慣れていないと後で「コレジャナイ」 が起きやすい) 広さ(範囲)でコミットし、深さ(実現内容)で調整する。 なのでユーザーストーリーマッピングが活きてくる。 Toshihiro Ichitani All Rights Reserved.

ユーザーストーリーマッピング https://www.amazon.co.jp/dp/4873117321 ※「ユーザーストーリー駆動開発で⾏こう。」 https://www.slideshare.net/papanda/ss-41638116 ※「ユーザーストーリーマッピング」 https://www.amazon.co.jp/dp/4873117321 Toshihiro Ichitani All Rights Reserved.

• https://www.slideshare.net/papanda/ss-41638116
• https://www.amazon.co.jp/dp/4873117321

もうちょっと広さと深さの話 ①広さと深さコミット ②深さコミット ③広さコミット 深さ 深さ 深さ 広さ いわゆるスコープ固定。 段階的にやりながら 詳しくしていく開発には 向いていない 広さ 実現したい機能レベルに コミットする。 どこまでやるかを調整。 (いわゆる準委任契約) 期待するボリューム感が 関係者と合わず始められ なかったり、後でコレジャ Toshihiro ナイになりがち。 Ichitani All Rights Reserved. 広さ 実現する範囲にコミット する。⼀つ⼀つをどこまで 作り込むか調整しながら 進める。 実現レベルを松⽵梅を⾒⽴ てることでゆるやかに期待 感をすりあわせる。

第4章 組織で 1⼈から チームで プロダクト オーナー (PO)と Toshihiro Ichitani All Rights Reserved. 組織で

組織で。 じゅもんをせつやく ⼀気にやらない いろいろやろうぜ 仮説を⽴てて、検証し続ける いのちだいじに 死だけを回避する 経営との期待マネジメント 取り組みを分かりやすくする。 “型”を最初の理想と置き、“型”との 差分を計画的に倒していく。 経営からの問いに 答えられないと、死 Toshihiro Ichitani All Rights Reserved.

屏⾵の⻁を捕まえる問題 経営の期待は？…そもそも存在しているか。 ……。 (何か成果あげてね) Why How What どうやって やるか考えよ アジャイル開発 をやれー！ アジャイル開発の取り組みへの期待が あいまいなまま、「うまいことやって」 は誰も、どこにもたどり着けない。 Toshihiro Ichitani All Rights Reserved.

どうすれば経営側に取り組みを、 理解してもらえるだろうか Toshihiro Ichitani All Rights Reserved.

どうすれば経営側に取り組みを、 理解してもらえるだろうか “型” を置き、”型” との差分で状況を可視化する “アジャイル開発”というやり⽅があるわけではない。 …ので、余計に何をどこまで出来るようになると意義が あるのか、分かりいくい。 あえて分かりやすくする=現状と差分が取れる“型”の⽤意 どの差分の解消から初めて、次に何を、その次は… 可視化された計画を、経営との「共通⾔語」にする。 Toshihiro Ichitani All Rights Reserved.

型としてのアジャイル開発との⽐較を⾏う(1/3) ※ここでの型はスクラムガイド及び アジャイルサムライ、リーン開発の 現場を前提 型としてのアジャイル開発 あなたのチーム ⻘字は今後やると良さそうなこと ・1チーム、両⼿未満 ・プログラマ、デザイナ、プロジェクトマ チーム ネージャ、アナリスト、テスター等 ・開発チーム、PO、スクラムマスター ・必要に応じた役割と定義と期待 ・プロジェクトの⽅向付けやチームビルド ⽅向付け を⾏う e l p m Sa ・フレームは、インセプションデッキ ・管理⼿段は、プロダクトバックログ ・形式は、ユーザーストーリー形式(INVEST) 要求 リリース計画 ・完成の定義がある ・バックログを練る、伝える機会がある (1)型との差分から取り組み内容を決める →バックログリファインメント (2)取り組み内容を「バックログ」として管理する ・プロダクトバックログを元に、リリース 時期を⾒定める →「アジャイル取り組みバックログリスト」の運⽤ ・チームのベロシティ(仮定でおく) ※だから、取り組みのプランニングもふりかえりもやる ・バックログの⾒積もり(相対⾒積) →プランニングポーカー Copyright (c) 2016 Guild Works Inc. 51

“型” は潰せる。”アジャイル”は潰せない。 「アジャイル⾃体がダメ」にしない。 型があれば「型⾃体を⾒直す」選択が取れる。 ※”アジャイル開発の型”という考え⽅⾃体が「便宜上の⼿がかり」みたいなもの。 本来は⾃分たちで、⾃分たちの状況を踏まえて、理想を置く。 ①型が無くて、 上⼿くいかないと… 取り組み 結果 ②型を置いて取り組む アジャイル 開発の”型” 型の⽅が組織にあって アジャイル開発 ない？⾃分たちに なんてできっこない！ とっての型を決め直す Toshihiro Ichitani All Rights Reserved. 取り組み 結果

期待がよく分からなくても成果は求められる！ ①最初の取り組みは「アジャイルとは何なのか」を まずは関係者全員で理解する機会にする (最初で「頓死」するリスクは、”型”で回避) ②次の取り組みで「屏⾵の⻁を出す」=「期待は何」 をデッキのアジェンダで可視化する (デッキ⾃体をやることにこだわらないこと) Toshihiro Ichitani All Rights Reserved.

屏⾵の⻁を出すインセプションデッキ 押さえておきたいこと ① われわれはなぜここにいるのか (why) ② アジャイル開発の「ピッチ」 ③ 取り組むにあたっての「トレードオフスライダー」 ④ 取り組みとして「やらないこと」 ⑤ 夜も眠れない問題 ⑥ 期間はどれだけ必要か(線表) …線表？ Toshihiro Ichitani All Rights Reserved.

線表 = いつまでは「何をしない」表明 アジャイル開発の取り組みで、あえて 「線表(マイルストーンのプロット)」をつくる狙いは、 関係者に向けた「意思表明」と「合意の可視化」である。 線表には、いつ、何をするかが書かれている。 逆に「いつまでは何をしない」を表現することになる。 「唐突に全体の評価をし始めない」 「あれもこれもと詰め込みすぎない」 Toshihiro Ichitani All Rights Reserved.

まとめ：コミットコントロールと練度を捉えて ⾏き⽅を決める。 結局チームだけが学びを コミット コントロール かんたん 得られれば良いわけではない。 1⼈で チーム、関係者、経営それぞれの 勝てる ゾーン 学びの進捗が求められる チームで “じゅもんをせつやく” POと コミット コントロール むずかしい 頓死に 注意ゾーン (⼀気にやらない) 組織で “いろいろとやろうぜ” (仮説を⽴てて検証し続ける) “いのちだいじに” 求められる 練度低い 求められる 練度⾼い (死だけ回避する) = 展開範囲と取り組み内容を 時間軸に乗せて段階的に進める Toshihiro Ichitani All Rights Reserved.

これで全部終わり？ 最後に、もう⼀つのケース。 ゼロから、いきなり 「組織として」始めちゃう。 Toshihiro Ichitani All Rights Reserved.

最終章 いきなり逆境アジャイル 1⼈から チームで プロダクト オーナー (PO)と Toshihiro Ichitani All Rights Reserved. 組織で

まだ⾃分⾃⾝の練度が何も⾼まっていないのに チームで取り組みを始めないといけない しかも、PO(ビジネス側)をまきこんで。 もちろん、経営に報告しないといけない。 …どうする？ Toshihiro Ichitani All Rights Reserved.

“みんながんばれ” その状況に応じて攻撃・補助・回復のバランスの取れた平均的な戦闘をする。 これまでのパターンを組み合わせる。あるいは断る。 第1段階 全体の期待調整 セーフティーネット 取り組み⽅針 PO期待マネジメント 社内向けシステム でパイロット的 プロジェクト アジャイルの”型" ⾒える化 2つの 期待マネジメント ⾒える化から始めて フィードバックループ 構築へ プロダクトの⽅向性、メ ンバーの価値観からバッ クログレベルの期待調整 まずはコミット範囲を 限定し、経営と⽬的⾃ 体をつくる 第2段階 屏⾵の⻁デッキ 型から始めて、型の限 界をメンターとともに 越える フィードバック ループ構築 適切なメンター + ユーザー ストーリー駆動開発 Toshihiro Ichitani All Rights Reserved. 広さでコミット 深さで調整

エピローグ おわりに 「いきなり最強チーム」 https://ikinari.guildworks.jp/ Toshihiro Ichitani All Rights Reserved.

• https://ikinari.guildworks.jp/

逆境の中、それでも開発のあり⽅をより良い⽅向へと 変えていきたいと諦めずに考えている⽅々へ。 Toshihiro Ichitani All Rights Reserved.

逆境からのアジャイル=現場から始める 経営が、CIOが、マネージャーが、状況を俯瞰して 取り組みのトリガーを引く…の夢をいつまで⾒るか。 そもそも “アジャイルな開発” とは、現場の仕事の あり⽅、やり⽅そのものなのだから「現場から始める」 で合ってる！(から、躊躇しなくて良い) 変化を、⾃分から、⼀⼈からでも、始めよう。 Toshihiro Ichitani All Rights Reserved.

逆境からも越境はできる。 Toshihiro Ichitani All Rights Reserved.