アジャイル開発でチームに一体感が生まれない。そんな時はプラクティスが有効です。適切にプラクティスを導入することによって、プロジェクトの意義への理解が深まり、チームの自律性を高めることが可能です。
そこでこの記事では、「そもそもアジャイル開発にとってプラクティスとは？」といった疑問から、プラクティス一覧とその手法まで幅広く解説していきます。チームを任された人も、まずはここから始めてみてはどうでしょうか。
1. アジャイル開発における「プラクティス」とはどんな意味？
アジャイル開発における「プラクティス」とは、アジャイルを実現するための取り組み・手段のことです。特に、具体的な開発を進める前の「チーム作り」や、プロダクトバックログ作成のための方向性を提供し、初期フェーズの組み立てに役立てられます。
そもそも「アジャイル開発」はプロダクト開発のための1つの理念・モデルであって、それ自体にあらゆるチームが従うべき細かな取り決めはありません。たしかに、イテレーション（反復）という基本的に則るべき開発プロセスは存在しますが、それさえも形式的なものなのです。
そこでプラクティスです。つまり、理念的・形式的なアジャイル開発を、具体的・実践的なものとするためにプラクティスが求められるのです。
さらにまた、プラクティスが目的達成のための「手段」であって、個別的事例に合った活用がされるべきであることも理解しなければなりません。プロジェクトの性格やチームの特性、そして各プラクティスの持つ目的などの複雑性を無視すると、むしろアジャイル開発の失敗を招きかねません。
1.1 代表的なプラクティス
この記事で紹介するのは、3つの代表的なプラクティスです。その3つのプラクティスとは以下の通りです。
- インセプションデッキ
- ドラッカー風エクササイズ
- 星取表（スキルマップ）
それぞれに目的があり、異なった効果を期待できます。自分のチームに必要なものが何かを想像しながら読み進めるとよいでしょう。「プロジェクトの意義が共有できていない」「新しく入ってくるメンバーの受け入れがスムーズに行えない」など、チームごとに様々な課題があるのではないでしょうか。
1.1.1 インセプションデッキ
インセプションデッキはThoughtWorks社のRobin Gibson氏にが考案し、後に『アジャイルサムライ』の著者Jonathan Rasmusson氏によって、広く知られるようになりました。今では、アジャイル開発に限らず様々なプロジェクトの現場で活用されています。
インセプションデッキとは、プロジェクトの全体像を明確化するためのプラクティスです。特定の10個の質問にチームで話し合いながら回答していきます。そのため、インセプションデッキ作成の過程で、チームでプロジェクトの方向性を共有することが可能です。なお、具体的な質問内容などは、後半で解説します。
1.1.2 ドラッカー風エクササイズ
ドラッカー風エクササイズは、チームビルディングに有効なプラクティスです。Jonathan Rasmusson氏が著書『アジャイルサムライ』で紹介したことによって広く知られるようになりました。
チームメンバーがそれぞれ4個の質問に答える過程で、お互いの得手不得手についての認識や、各メンバーに期待することへの相互理解を深めることができます。さらに新しいメンバー加入時、相互理解をシームレスに行う手段としても有効です。
もっと詳しい活用方法は、後半で詳しく解説します。
1.1.3 星取表（スキルマップ）
星取表（スキルマップ）はチームメンバー各自が持つスキルを可視化するためのプラクティスです。スキルを可視化することによって、プロジェクトの潜在的な危機や、スキルバランスを安定化させるための行動指針を立てることが可能となります。
さらに、持っているスキル内容が共有されていることで、エラー発生時に誰に相談すべきかなどの判断基準にも役立てることができます。
こちらも書き方・使い方は、後半で画像を見ながら解説していきます。
1.2 プラクティスを取り入れてチームを成長させるべき場面
先述した通り、プラクティスはアジャイル開発において必須なものではありません。しかし、プラクティスは「チーム作り」に有効な「手段」です。停滞したチームにプラクティスを導入して、さらなる成長に繋げましょう。
1.2.1 アジャイル開発・スクラム開発を取り入れたがうまくいかない
アジャイル開発・スクラム開発を取り入れてもうまくいかない時は、タスク分割が荒く、粒度が大きすぎるなどの問題が発生している場合があります。結果として未消化タスクが累積し、メンバーがバーンアウトすることになります。
このような事態を避けるためにもプラクティスは有効です。プラクティスを導入することで、プロダクトバックログの方向性が明瞭になり、タスク設定にも荒さが無くなります。
1.2.2 チームに一体感が生まれない・コミュニケーションが取れない
プロジェクトに対してチームの一体感がない場合にも、プラクティスは有効に働きます。チームの一体感やコミュニケーションの活発さは、メンバー各人のプロジェクトへの理解や、他メンバーがプロジェクトを理解しているという信頼によって生まれます。
そういった個々人の自律性や他メンバーへの信頼確立のためにも、ぜひプラクティスは活用すべきだと言えます。それに、そもそもプラクティスを行うワークショップ自体がコミュニケーション活性化を促します。コミュニケーションの場を作る手段としても、プラクティスの導入には意義があります。
2. 実際にアジャイル開発のプラクティスを取り入れてみよう
この記事で紹介する3つのプラクティスは導入が簡単で、かつ短期的・長期的な効果を見込めるものばかりです。また、ある程度の方法は定まっているものの、チームの課題や導入の目的に応じて随時カスタマイズが可能です。
2.1 インセプションデッキの書き方
確認すると、インセプションデッキはプロジェクトの全体像を明確化するプラクティスです。そのために、以下の10個の質問に「チームで」回答していきます。なお1つの問いへの回答は、1枚のスライドにまとめます。
- 我々はなぜここにいるのか
- エレベーターピッチ
- パッケージデザイン
- やらないことリスト
- 「ご近所さん」を探せ
- 解決案を描く
- 夜も眠れなくなるような問題
- 期間を見定める
- 何を諦めるのかを明確にする
- 何がどれだけ必要か
インセプションデッキを作成する時に重要なのが、「Why（なぜ）」を深掘りしていくことです。たとえば、「我々はなぜここにいるのか」のWhyに答えることで、プロジェクトの意義・方向性もはっきりしてきます。
2.2 ドラッカー風エクササイズの書き方
ドラッカー風エクササイズでは、4つの質問に「メンバー各自で」答えていきます。4つの質問とは以下の通りです。
- 何が得意なのか
- どのように仕事をするのか
- 自分にとって大切な価値は何か
- このプロジェクトで自分に期待されていることは何か
各人がこれらの質問の回答を終えた後、メンバーで回答を共有します。すると自己評価と他者評価の間の齟齬が少なくしていき、「チーム」内における各メンバーの立ち位置や役割が明確になっていきます。
プロジェクト立ち上げ時はもちろん、新たなメンバーが加入する際に相互理解を深めることも可能です。また、長期的なプロジェクトの場合は、プロジェクトの間でもスキルの習得などによって自己・他者評価の変化があります。そのため、節目節目にドラッカー風エクササイズを行うことも必要となってきます。
2.3 星取表（スキルマップ）の書き方
星取表（スキルマップ）は、各メンバーが特定の技術に対してどれだけのスキルを有しているかを、直感的に共有できるようにします。以下の画像は、星取表の一例です。
項目数と記号は任意のものを選びましょう。直感的な理解できるものであれば、どのようなものでも構いません。
星取表（スキルマップ）を作成することによって、技術的側面に関するチーム運営を効率化することが可能です。誰が何を勉強し、どのような技術を持った人を採用すべきかの判断基準として利用してみてはどうでしょうか。
3. アジャイル開発のプラクティスは従来型の開発でも役立つ
ここからは、アジャイル開発のプラクティスと従来型の開発（ウォータフォール開発）との関係について解説していきます。現状のウォーターフォール開発に行き詰まりを感じていている方や、「チームに一体感を持たせたい」「変化に対する柔軟性を持たせたい」と考える方は、ぜひ参考にしてみてください。
3.1 【前提】部分的にウォーターフォールを取り入れたアジャイルも増えている
近年では「ハイブリッド開発」として、従来型のウォーターフォール開発とアジャイル開発を組み合わせたものが広がっています。
ハイブリッド開発では上流工程や下流工程はウォーターフォール型で行い、中流工程はアジャイル開発で行います。こうすることで、ウォーターフォール型は「完成像が見えにくい」といったアジャイル開発の弱点を補い、アジャイル開発は仕様変更への弱さやフィードバックの少なさといったウォーターフォール型の弱点を補います。
また以上のように全面的なハイブリッド化でなくとも、部分的に可能な範囲からアジャイルの要素を組み込んでいくだけでも十分な効果が見込めます。
3.2 従来型開発でも役立つプラクティスの例
では、従来型開発に役立つプラクティスの例を紹介していきます。紹介するもの全てを一挙に導入するのではなく、チームの課題に応じて少しづつ取り入れていくとよいでしょう。全体との折り合いを考えない強引な導入は、危険が伴うことを理解しておくことが重要です。
3.2.1 タスクの細分化
タスクの細分化によって、従来型の開発であっても進捗状況の管理が行いやすくなります。スクラムガイドでは作業単位は1日以内と定められており、もし設定しているタスクが日をまたぐことを前提にしているのならば、分割できないか再考してみましょう。
また、タスクを1日ごとに設定しているのにも関わらずマネジメントがうまくいかない場合は、作業時間の変動の可能性が大きいタスクをさらに半日以下に細分化するとよいでしょう。
3.2.2 かんばんの導入・運用改善
かんばんの導入によって、作業状況をチームで共有することが可能となります。作業状況を共有することによって、チームに一体感が生まれやすくなるといった効果も期待できます。
かんばんでは、作業内容が記載されたカードを「TODO」「DOING」「DONE」のセパレーションを移動させていきます。しかし、形式にとらわれず実際の開発現場のワークフローにあったセパレーションを設けるべきです。たとえば、「DONE」の前に「REVIEW」を入れるなどです。
3.2.3 日々のデイリースクラムの改善
デイリースクラムの改善すべき点を探すのもよいでしょう。アジャイル開発では、チームの自律性・自主性に大きな価値を置きます。そこで、日々のスクラムに自律性・自主性を触発するためのテコを加えてみてはどうでしょうか。
たとえば、日頃の振り返りやミーティングの進行役を当番制にするなどです。進行役を任されることによって、意見の調停などを通して日頃の活動意義などにも自覚的になります。その結果、チームの自律性・自主性の高まりにつながります。
3.2.4 リファインメント会議をきちんと行う
週一程度でプロダクトバックログのリファインメントを行うことによって、ユーザーストーリーを意識した開発につながります。
プロダクトバックログのリファインメントとは、スクラムガイドによれば「プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並べ替えをすること」です。
開発の過程で、仕様の変更や優先順位の変動はよく起こります。そのため定期的なリファインメント会議を行うことによって、プロダクトバックログを常にユーザーストーリーに沿った最新のものに維持できるのです。
4. アジャイル開発のプラクティスについてよくある質問
ここからは、アジャイル開発のプラクティスについてよくある質問について答えていきます。取り上げきれなかった質問についても、この記事内のどこかで答えが見つかる可能性があるので、ぜひ探してみてください。
4.1 プラクティスを導入すればアジャイル開発に取り組んでいることになる？
プラクティスを導入しても、その現場がアジャイル開発であるとは必ずしも言えません。先述した通り、アジャイル開発においてプラクティスとは、アジャイル開発を実現するための「手段」なのです。
しかし、アジャイル開発は「プロダクト」「人」「技術・品質」「マネジメント」についてのチームでの共通理解が欠かせません。その共通理解の形成ににおいてプラクティスが有効であることは間違いありません。
ただし、やはり「手段」としてのプラクティスを「目的」のように扱うことによって、プラクティスが形骸化する恐れがあることは忘れるべきではありません。
4.2 スプリントの開始前には具体的に何をするべき？
スプリントの開始前には、プロジェクトについて明らかにしておくべきことを知るための活動を行うとよいでしょう。この記事で紹介した「インセプションデッキ」の作成が良い例です。
スプリント開始前にインセプションデッキ作成のワークショップを行うことによって、プロジェクトの目的・意義について、チームで共通意識を形成することができます。この共通意識が自律性・自主性を促し、効果的なアジャイル開発を可能とします。
4.3 企業文化がアジャイル開発とマッチしない。どうすればいい？
企業文化に抵触しない小さなことから始めてみるとよいでしょう。かんばんの導入や、日々のミーティングの改善などがおすすめです。
逆に、強引な開発手法の変更などはプロジェクトの失敗を招きかねません。たとえば、トップダウンの文化が根強く残っている企業で、チームの自律性・自主性を強く押し出すような開発手法を導入することによって大きな衝突が起こる可能性があります。そのため、まずは効果が期待できる範囲で少しずつ新しいことを始めてみるとよいでしょう。
5. まとめ
この記事でも繰り返したように、アジャイル開発のプラクティスは「手段」であることは忘れてはいけません。「手段」であることを理解して活用されたプラクティスはチームに一体感を与え、開発のパフォーマンスを高めてくれます。チームの課題を見つめつつ、適切かつ積極的にプラクティスを導入していきましょう。
