逆境からのアジャイル

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

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

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

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

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

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

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

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

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

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

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

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

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

あなたのWhyは何？

第1章 1⼈から
組織で
プロダクト
オーナー
(PO)と

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

具体的には何からはじめるべき？

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

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

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

はじめるのにベストなタイミングは？

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

第2章チームで
組織で
プロダクト
オーナー
(PO)と

チームで。
チームメンバー及び、⼀つ上の⻑
(リーダーやマネージャー)との期待
マネジメントが必要になる。
まず、チームの⾒える化、リズム
仕事に取り組む。次にフィードバッ
クループの構築にトライする。
チームのミッションを
果たせなくなると、死。

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

チームでは、何からはじめるべき？

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

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

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

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

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

第3章 POと
組織で
プロダクト
オーナー
(PO)と

POと。
PO(顧客、ビジネス側)との
期待マネジメントが必要になる。
フィードバックループを素早く
回せるように、POとのコミュニ
ケーションに取り組む。
(同じく)チームのミッションを
果たせなくなると、死。

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

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

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

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

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

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

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

ユーザーストーリー駆動開発
ユーザーストーリーとは、①やりたいことをまとめる
⼿段であり、②計画を⽴てるための材料であり、
③実績を測るための対象である。
※ユーザーストーリーの詳しくは「ユーザーストーリー駆動開発で⾏こう。」を読もう

POとの約束を守れるかしら…

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

ユーザーストーリーマッピング
※「ユーザーストーリー駆動開発で⾏こう。」
※「ユーザーストーリーマッピング」

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

第4章組織で
組織で
プロダクト
オーナー
(PO)と

組織で。
経営との期待マネジメント
取り組みを分かりやすくする。
“型”を最初の理想と置き、“型”との
差分を計画的に倒していく。
経営からの問いに
答えられないと、死

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

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

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

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

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

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

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

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

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

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

最終章いきなり逆境アジャイル
組織で
プロダクト
オーナー
(PO)と
プロダクト
オーナー
(PO)と

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

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

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

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

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

逆境からも越境はできる。

逆境からのアジャイル

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 逆境からのアジャイル

Similar to 逆境からのアジャイル (20)

More from toshihiro ichitani

More from toshihiro ichitani (20)

逆境からのアジャイル