Agile Japan 2016 セッションB-1
- セッションタイトル：組織の壁を乗り越えるアジャイル開発
- スピーカー：
- レポーター：カンケ
- 執筆日：2016年9月17日
- 執筆一覧：http://www.manaslink.com/kanke
今までのウォーターフォール開発では、
自分たちの仕事の範囲を組織ごとに決めていたため
お客様の課題解決に結びついていなかった
そんなモヤモヤを抱えた部署も職種も異なる和田さんと北条さんがタッグを組み、試行錯誤しながらアジャイル開発を導入したお話でした。二人が取り組んできた課題、失敗、改善は、これからアジャイル開発を始める方、すでに実践している方の参考になると思います。
はじめに
ウォーターフォール開発からアジャイル開発に変わったことで、二人の思考はどのように変化したのでしょうか。
部門ごとに縦割りで仕事をしていたのが、
一体となって、お客様のためにどうすればいいのか考えるようになった和田圭介さん（KDDI株式会社 クラウドサービス企画部）
今までは、プロセスはあまり意識せず
QCDの結果を出すことだけを目標に働いていたが、
結果だけではなく、プロセスを楽しむことを学べた北条裕樹さん（KDDI株式会社 クラウドサービス開発部）
もともとは、部門縦割りでウォーターフォール開発をしていましたが、「お客様の課題がなかなか解決しない」「もっと早くお客様にプロダクトを提供したい」などからアジャイル開発導入に踏み切ったそうです。企画部の和田さんがプロダクトオーナー、開発部の北条さんがスクラムマスターとして企画部と開発部とが一体化したスクラムチームをつくり、スプリントを回して軌道修正しながら開発を進めています。
導入時に工夫した点は、ウォーターフォール開発の承認プロセスはそのままに、アジャイル開発のアウトプットをアダプトしたことです。今まで培ってきた承認の観点は、とても重要な財産なので、アジャイル開発に変わったからと捨てることなく有効活用しているそうです。
和田さん、北条さんの試行錯誤を以下に箇条書きでまとめたので、気になるものを見つけてみてください。
仕様の検討
課題
みんなの考えていることがバラバラ。企画部、開発部、運用部それぞれの考えのまま進めていた。
- 企画部は、仕様書を説明すれば自分たちの仕事は終わり、という考えだった。
- 予算をとって発注するという仕組みから、盛りだくさんの機能が入った仕様を提示していた。
- 開発部は、後から仕様が増えると考え、こっそりバッファを積んでいた。
改善策
- チームでインセプションデッキを作成し、方向性を共通認識させた。
- ステークホルダーに、サービスの目的や背景をきちんと説明した。
- ストーリーマッピングに参加していない人に、なぜこれを優先したのか、どのようなビジネスモデルなのかを説明した。
- バックログを作成し、なにをどの優先順で進めればいいかを見える化した。
- ユーザーストーリーマッピングを実施し、プロジェクトの全体像を俯瞰できるようにした。
- ステークホルダーが気軽にバックログを見れるように、ツール（Confluence、JIRA）を導入した。
実装・テスト
課題
みんなの考えがバラバラのまま進めてきたことが、ここではじめて重大な課題であることに気づいた。
- 実装したものが仕様書と異なる。
- 仕様が実現不可能。
- 工数、予算が足りなくてリカバリーできない。
改善策
- インセプションデッキやユーザーストーリーマッピングを作成することで、道をそれずに開発できるようにした。
- スプリントごとのレビューでフィードバックしながら開発することで、蓋を開けたら「こうじゃない」を防いだ。
- ストーリーを見積もるときに実現可能性を判断することで、仕様のフィードバックを早くした。
- スプリントで期間を区切りバックログを優先順に消化することで、スコープの調整を可能にした。
受け入れ試験
課題
リリース直前までみんなの考えはバラバラのままだったので、求めるプロダクトはモヤっとしたままだった。
改善策
インセプションデッキやユーザーストーリーマッピングを作成することで、道をそれずに開発できるようにした。
ペルソナ設定
失敗
ペルソナの設定が浅くストーリーを十分に描くことができず、活発な議論や意見出しができなかった。
改善策
- 営業やSEみんなで議論して、ペルソナを決めるようにした。
- チームだけでなく、ステークホルダーにもペルソナを共有した。
- プロジェクトルームにペルソナを掲示し、常に見れるようにした。
ユーザーストーリーマッピング
失敗
行動のみの議論になってしまった。
改善策
- 考え方を変えることで、ソリューションを議論できるようになった。
- ペルソナはどのように考えているのか？どうやって課題を解決するのか？をモットーに実施した。
スプリントのふりかえり
失敗
ふりかえりよりも、実装を優先してしまった。
改善策
- 形骸化しないように心がけながら、KPTを続けた。
- KPTで出た項目をWorking Agreementに入れるようにした。
- チームのルールを定義し、ふりかえりで確認するようにした。
ステークホルダー
失敗
- 「アジャイルだから簡単に仕様を追加できる」と誤解されていたため、スプリント中に仕事の割り込みが発生した。
- 動くソフトウェアだけ見せていたところ、企画部より「考えていたことと違う」「よくわからない」と食い違いが生じた。
- 企画部の関心は、動くソフトウェアよりもプロダクトの方向性と進捗にあることを理解できていなかった。
- スプリントレビューに運用部も参加してもらったが、レビューが進まず3回目で断念した。
- 方向性や目的を共有しないまま、レビューを進めてしまった。
改善策
- ステークホルダーに開発プロセスを説明し、仕様追加には影響が伴うことを理解してもらった。
- 完了の定義を明確にすることで、後から変更しないようにした。
- インセプションデッキで方向性や目的を共有し、エピックレベルの俯瞰を見せてからレビューするようにした。
インセプションデッキは、書籍『アジャイルサムライ』に詳しく記載されているアジャイル開発のプラクティスです。
簡単に言うと「みんなでバスに乗ってプロジェクトのゴールに向かって行こう」です。
「バスに乗ってみんなで同じ方向に進んでいくこと」は、プロジェクトのゴールに向かうたとえです。
リリース後
失敗
リリース後、やることがなくなった。
改善策
- 空き時間をビジネスアライメントマップの作成に割り当て、ビジネス目標に沿ってプロダクトの目標、ソリューション、機能を見える化した。
- ビジネスの方向性を見える化して貼り出し、どこまで進んでいるか、今後どのように進めるかがわかるようにした。
所感
大きい会社では「大企業病」があるあるです。縦割りで自分の仕事しかやらないというのは、よくある話だと感じました。大企業であっても変化の激しい市場について行くためには、すばやい価値の提供が必要ですし、価格もギリギリまで下げなければなりません。いかにお客様に価値を提供するか議論し、どのように実現するのが最適なのかを日々改善することが求められます。そこにアジャイル開発が必要になるんですね。
今までのやり方を変えようとすると、必ず反発が出てくると思います。そのあたりを考えながら導入しているので参考になりました。
もともとの承認プロセスを生かし、上位マネジメント層を安心させながら進めたことが、アジャイル開発導入の勝因ではないかと思います。
「KDDI Cloud Blog」の「Agile Development」カテゴリの記事も参考になりそうです。
参考文献
- 『アジャイルサムライ――達人開発者への道』（Jonathan Rasmusson、オーム社、2011年）
- KDDI Cloud Blog – Agile Development
Agile Japanとは
- Agile Japanとは
- 公式サイト：Agile Japan
- Twitter：@agilejapan
- Facebookページ：Agile Japan
