われわれはなぜアジャイルに向かうのか

Toshihiro Ichitani All Rights Reserved.
われわれはなぜ
アジャイルに向かうのか
Ichitani Toshihiro
市⾕聡啓
開発をアジャイルにしていくために
読むべき最初の⼿引き

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

Copyright (c) 2017 Guild Works Inc.
皆さんは、アジャイル開発という⾔葉に
様々な場⾯で既に遭遇しているかと思います。
どんな⾯持ちでしょう？

「取り組んでいるが上⼿くやれているか分からない」
「アジャイル開発？今更(笑」

「アジャイル開発？今更(笑」
アジャイルに向き合うのに今更も
へったくれもありません！

なぜなら、アジャイルとは度合いだから。
“アジャイル開発”という実体があるわけではない。
(歴史的な成り⽴ちからして)

なぜなら、アジャイルとは度合いだから。
(歴史的な成り⽴ちからして)
実体としては「XP」「スクラム」「リーン開発」
などがよく挙がる。
そして、
「そのチームにとっての開発のあり⽅、やり⽅」も
”アジャイルな開発”と⾔える。

度合いって何のこと？
少しずつ反復的に開発を進めることで
必要とする⼈から必要なフィードバックを得て
調整し続けられる開発
→“アジャイルさ” = 「変化に適応できる度合い」
⼀⾔でアジャイルな開発を表現すると
(共通的な特徴は)
http://gihyo.jp/dev/serial/01/agile
「アジャイル開発者の習慣」

「アジャイル開発？今更w」
アジャイルに向き合うのに今更も
へったくれもありません！
この時間では、アジャイルな開発とは何か
あらためて問い、どのように向き合っていくか
をテーマに致します。

本⽇のテーマ
なぜ、アジャイルに向かうのか。
背景
よくある問題
乗り越える

関係者それぞれの期待が異なり、
出来たモノと違っていたと分かった。

システムテストに⾄るまで、完成品が
確認できなかった。結果、最後の調整が膨⼤に。

でも、考えていること、期待していることを
ドキュメントですべて表現できない。

最後のテストで、技術的な問題噴出。

構想してから、市場に投⼊するまでの
期間が⻑すぎる。

構想してから、市場に投⼊するまでの
期間が⻑すぎる。
アジャイルに向かう意義が⼗分にある

アジャイルな開発のプロセス的な特徴

リリーステスト実装設計
フェーズゲート開発
アジャイルな開発
要件定義
開発された
ボリューム

アジャイルな開発のプロセス的な特徴
「インクリメンタル」(少しずつ)
「イテレーティブ」(繰り返し)
つまり「早く(少しだけ)形にできる」やり⽅

早く(少しだけ)形にできることの意義
フィードバックに基づく調整で、⽬的に適した
ソフトウェアに仕⽴てられる
形にすることで早めに関係者の認識を揃えられる
つくるものやチームについての問題早く気付ける
チームの学習効果が⾼い
早く始められる
結合のリスクを早めに倒せる
Time to market が短い
サンクコストが⼩さくできる
開発チームのリズムを整えられる
①
②
③
④
⑤
⑥
⑦
⑧
⑨

形にすることで早めに関係者の認識を揃えられる
そもそも、関係者(ビジネス側、ビジネスとチーム間、
チーム内で)つくるものの解釈が異なっている。
最初から、完成型が構想できない。
誰かが正解を持っているわけではない。
ドキュメントですべてを書き尽くせない。
それはコードになる。
「形にするためのコミュニケーションの過程」や
「形にしたものの動き」から共通理解を育める

アジャイル開発は、ドキュメント
つくらない？

アジャイル開発は、ドキュメント
つくらない？
開発するために必要なことは減らない！
アジャイルな開発にすることで、急に開発に必要
だった⼿順がなくなるわけではない。
コード以外の記述が全く不要なわけではない。
ただし、「理解や伝達のための成果物」は
最低限にしておくこと。

つくるものやチームについての問題早く気付ける
開発を⼀巡させるのが早いため、プロダクトやチームの
問題に早く気付ける。
コードが書けない = バックログの完成の条件を詳細にする。
バックログが消化できない = チームに必要なタレントを巻き込む。
認識の齟齬が多い = コミュニケーションの内容、頻度の調整。
要件の実現⽅法が分からない = 技術的な実現可能性の検証。
改修時のデグレが多い = ⾃動回帰テストの充実。

チームの学習効果が⾼い
「常に最初から同じメンバーで継続的に活動」が前提
異なる担当者に伝達伝達伝達

早く始められる
全ての要件を決めきる必要がない = 部分を後回しに出来る
結合のリスクを早めに倒すこと
常に結合。
Time to marketが短い
早いスプリントからリリースできる = 早く収益化できる。
サンクコストが⼩さくできる
早いスプリントから評価が出来るため、途中でやめられる。
開発チームのリズムを整えられる
チームの実状に計画をあわせられる。

アジャイル開発は、計画しない？
確かに、綿密な細か〜い、スケジュール表を
最近は⾒かけなくなりましたね！
だけど、
細かいスケジュールをつくらない ≠ 計画しない
というわけでは決してない。

むしろ、頻繁に計画づくりを⾏う。
アジャイルな開発では、イテレーションと呼ばれる
単位で、時間を区切り開発を進める。
各イテレーションで何をするのかは
「イテレーション計画ミーティング」
という場で、イテレーション毎に毎回⾏う。

むしろ、頻繁に計画づくりを⾏う。
アジャイルな開発では、イテレーションと呼ばれる
単位で、時間を区切り開発を進める。
各イテレーションで何をするのかは
「イテレーション計画ミーティング」
という場で、イテレーション毎に毎回⾏う。
毎回。イテレーションを1週間で回しているなら
毎週、計画づくりをするってこと！
なぜやるかって？頻繁に計画づくりしたほうが、
現実から乖離した計画を追わなくて済むよね。

アジャイル開発は、⾒積もりしない？

⾒積もりは、2つのプランニングで必要になるよ。
①「リリースプランニング」
②「イテレーション(スプリント)プランニング」

⾒積もりは、2つのプランニングで必要になるよ。
①「リリースプランニング」
②「イテレーション(スプリント)プランニング」
やることに対して⾒積もりをしないと、全体として
何イテレーション必要なのかが分からない(①)し
⽬の前のイテレーションでチームとしてどこまで
できそうなのか⾒⽴てることができない(②)

⾒積もりは相対的に⾏う
A.コップの⽔の量がどのくらいあるか？
B.右のコップの⽔の量は左に⽐べてどのくらいか？

アジャイル開発は、フェーズゲート開発
よりも早く済むし、お安く済むんでしょ？

アジャイル開発は、フェーズゲート開発
よりも早く済むし、お安く済むんでしょ？
ムダが減らせる分は、早くたどり着けるかもしれ
ないし、コストも抑えられるかもしれない。
…ただし、イテレーション開発とは、そもそも
試⾏錯誤をするために時間を区切っているわけ
だから、つくる⽅向性の調整が今までより細かく
できるようになるということは、期間もコストも
⼤きくなる可能性があるということ。

☓
△
△
⃝

少しずつ形にするにあたっての問題
忙しい。
常に開発をしている、常に確認をするということは
常に開発チームと共にあるということ
(a)

ある程度の腕が求められる。(b)
各タスクにある程度
⻑い時間をかける
最初から⼀通りのスキルが必要。
最初は圧倒される可能性がある。
早めに失敗できるので、何が
ボトルネックになるか気付き易い。
(最初は進捗が上がりにくい)

チームを越えて対象を分割すると、同期が難しい(c)
チームを分割した場合、
フェーズではなくて、
タイムボックスで同期を
取るため、取れ⾼が容易に
ずれる。
作っているモノを同期しなけ
ればならないときに、揃える
難しさがある。

QCDに特徴的な課題がある(d)
「品質の維持」のためのコストが必要
→少しずつ作るので、作る度に既存機能に改修の影響が発⽣する
タイムボックス分割分のオーバーヘッドがある
「品質とコスト」を⼀定とすると、「スコープ」と「納期」で
調整する必要がある = ローンチタイミングが守られるか

そもそも考え⽅が関係者であっていない(e)
「いままでと違うやり⽅」について、
上層部、現場メンバーそれぞれに対して考え⽅が合わない。

「忙しい問題」の乗り越え⽅
(i) ⻑期的には、プロダクトオーナーを育てる。
ふるまいを⾝に付け、時間を取れること。
(ii) 短期的には、代理のプロダクトオーナーを⽴てる。
※ バックログの⼊れ替えである程度対処は可能だが
本質的には「プロダクトオーナーの判断」以上には
全体のスピードは早まらない。

「ある程度腕が求められる」乗り越え⽅
(i) ⼤⽬に⾒る。
(ii) チームの状態にあわせて段階的な移⾏が必要。
・プラクティスを少しずつ取り⼊れる
・第1段階開発上の問題を取り除く
(ふりかえり、タスクボード、スタンドアップミーティング)
・第2段階開発だけ反復
・第3段階プロダクトオーナーを巻き込んだ開発

「同期問題」の乗り越え⽅
(i) チーム内の同期 → 計画ミーティング、デイリー、デモ、
(ii) チーム外との同期 → 階層化=「デイリーカクテルパーティ」
第3章：デイリーカクテルパーティーに参加しよう

「QCD問題」の乗り越え⽅
(i) 品質の維持へのコスト
→ ⾃動回帰テスト
(ii) タイムボックスオーバーヘッド問題
→ 反復の必要性を問う
(iii) ローンチタイミングが守られるか
→ 常にシミュレーションが必要(着地予想)。
納期とスコープのトレードオフを判断し続ける。

「考え⽅あわない問題」の乗り越え⽅
アジャイルな開発に取り組み始める際に準備が必要
→ インセプションデッキ
・なぜ必要なのか
・どうやってやるのか
・この現場での課題とは何か

インセプションデッキは
何のために必要？

インセプションデッキは
何のために必要？
プロジェクトを始めるにあたって、
前提と制約、背景と現状などについて
関係者の間で認識を共通にすることで
⽅針や判断基準を揃える。
その結果、チームが状況に応じた適切な判断を
下せるようになることを期待する。

導⼊にあたっての作戦
① 段階的にやる (プラクティス導⼊)
② コミットメント(特に納期)の調整が効きやすい領域から
③ 経験豊かな⼈を混ぜ込む

自分の現場で何から始めたら良いのか

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

この先にあるのは？
「少しずつ形にできるようになる」
つまり「体のコントロール」と同じ。

「体のコントロール」
= 頭で考えたことを即座に伝えて、
体の部分を思うようにすぐに動かせる

「体のコントロール」
= 頭で考えたことを即座に伝えて、
体の部分を思うようにすぐに動かせる
「体のコントロール」のようにソフトウェアをつくる
= 必要なことを即座に伝えあい、
すぐに試せる、形にできる。

最後に、再び。
実体としては「XP」「スクラム」などがあり、
先⼈の肩越しに、⾃分たちの開発を変化に適応
できるようになることが「アジャイルである」こと。
⾃分たちの意思と、その実現のための開発が
限りなく⼀致していくこと！

https://guildworks.jp/
「正しいものを正しくつくる」ギルドワークス
https://enagile.jp/
「越境をエナジャイズする」エナジャイル
https://www.tagile.org/
「SoE、SoRで越境する戦略と戦術を得る」越境アジャイルアライアンス
「開発現場のためのコミュニティ」DevLOVE
https://devlove.doorkeeper.jp/

われわれはなぜアジャイルに向かうのか

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to われわれはなぜアジャイルに向かうのか

Similar to われわれはなぜアジャイルに向かうのか (20)

More from toshihiro ichitani

More from toshihiro ichitani (20)

われわれはなぜアジャイルに向かうのか