アジャイルなので無理です（言い訳）
この記事はコインチェック株式会社（以下コインチェック）のアドベントカレンダー20日目（シリーズ1）の記事です。
「アジャイルなんだから仕方ないでしょ」
アジャイル実践者の方なら開発がうまく回らない言い訳にアジャイルやアジャイルフレームワークが使われてしまう場面に一度は遭遇したことがあるのではないでしょうか？
かく言う私もプロダクトオーナーとして、スクラムマスターとして、そのようなコミュニケーションを取りたくなる状況に陥ることもあります。
しかし、その状況の裏には必ずアジャイル以外の別の原因があると断言します。
なぜなら、アジャイル開発とは開発プロセスを遮るものではなく、ビジネス価値の最大化を目的に、ユーザーにとって価値のあるプロダクトを速く、継続的に提供するためのものだからです。
この記事では、アジャイルを盾にする言い訳あるあるとその問題の原因及び対策を、自戒の念を込めて書き記していきます。
こんにちは、コインチェックの林和正です。
私は取引所事業部のフロントエンドチームでプロダクトオーナー兼スクラムマスターをしています。少し前までは販売所事業部の3チームでスクラムマスターとして活動していました。
今回は、アジャイルやスクラムに関するよくある誤解を無くし、アジャイルの本質的な価値を再認識できるような解決策をご紹介します。
エントリーナンバー1：「計画なんてしてないよ、アジャイルだからね」
「進行中のそのプロジェクトいつごろリリースできそうですか？」と言う質問に対しての回答としてつい言ってしまいそうなこの言葉。
確かに、アジャイルは変化に柔軟に対応できるように、ジャストインタイムで計画を変更する必要がありますし、それをできるのがアジャイルの良いところです。
しかし、当然ながら計画を立てないことを善としているわけではありません。
スクラムにおいては「透明性」「検査」「適応」と言う三本柱があり、これらを実現するにはリファインメントで透明性を持ったプロダクトバックログを作成し、スプリントプランニングでスプリントゴールを達成するための計画を作り、その計画とのズレをデイリースクラムで検査し、必要があれば計画を変更し適応していきます。
このように、毎日計画を用いて検査と適応を繰り返す開発プロセスにおいて、計画が不要であるわけがありません。
変化に柔軟な計画はどのように作れば良い？
簡単です。
プロダクトバックログアイテムのリファインメントを行い、ストーリーポイントをつける
下記の計算を行う
リリースに必要なスプリント数 ＝ ストーリーポイントの合計 / チームのベロシティ
リリース日（何日後か） = リリースに必要なスプリント数 * スプリントの日数
変化に柔軟に対応する以上、これより詳細なスケジュールは、計画コスト > 計画による恩恵となる可能性が高いでしょう。
決められた期日を守ることがビジネス価値そのものとなるプロジェクトは、そもそもアジャイルには向いていません。
長くなるので詳細は割愛しますが、アジャイルに向いているのは、市場の不確実性と向き合う「複雑系プロジェクト」です。期日の不確実性と向き合うことが本質的な価値となる「煩雑系プロジェクト」は計画駆動開発で行いましょう。
エントリーナンバー2：「品質が低い？とりあえずリリースするのがアジャイルさ」
「品質とスピードはトレードオフの関係にあるから、スピードを重視するアジャイルにおいては品質が低くなるのは仕方がない」
これはアジャイル開発で不具合を経験したことのある方なら一度は考えたことがあるのではないでしょうか。
2段階に分けて考えていきましょう。
① 品質とスピードはトレードオフの関係にあるのか
確かに、期日を守ることがビジネス価値そのものであるプロジェクトの場合やリソースに限りがある場合は、トレードオフであると言えるでしょう。
例えば、1週間後にクリスマス会を開催するプロジェクトの場合、クリスマスと言う期日に間に合わなければビジネス価値は皆無です。この場合においては、1週間で多くの出し物を用意するのか、数を絞ったハイクオリティな出し物を用意するのかを決める必要が出てきます。
② スピードを重視するアジャイルにおいては品質が低くなるのは仕方がないのか
これは明確にNoと言えます。
そもそも、アジャイルで重要なことはビジネス価値であり、アジャイルだからスピードを重視すると捉えるのは適切ではありません。
プロダクトがユーザーに受け入れられるかといった市場に潜む不確実性と向き合うには、最低限の機能（＝価値）を備えたMVPを高速で継続的に提供し続けることが合理的な手段であり、それがスピードを重視しているように見えるだけです。
品質が低いプロダクトを開発することは、ビジネス価値の低いものを生み出すという行為なので、アジャイルチームの目指すところではありません。
品質とスピードを両立するには？
簡単です。
全ての開発タスクに共通する完成の条件（＝完成の定義）をチームで定める
各開発タスクに存在する固有の完成の条件（＝受け入れ基準）を記載する
完成の定義と受け入れ基準を満たすかを確認するテストを実施する
リリースする
これらのプロセスを踏まえれば、ビジネス価値を毀損することがない一定の品質が担保されたリリースを最速で行うことができます。
エントリーナンバー3：「スクラムイベントの時間が多すぎて開発工率悪くなってね？」
開発者の方がコインチェックに入社された時にスクラムのイメージを聞くと、「スクラムイベントが長くて微妙」と言う回答が何度かありました。
このようなイメージになってしまうのは、経験したスクラムチームにおいて、スクラムイベントが効果的に機能していなかったことが原因だと思います。
前述したように、スクラムイベントは「検査」と「適応」を行うための場です。
適切にスクラムイベントが行われていれば、開発プロセスは変化し続け、その効果を実感することができるでしょう。
適切なスクラムイベントは下記のように明確な成果を生み出します。
効果的なスクラムイベントを実施するには？
簡単です。
各スクラムイベント実施後の成果に着目する
成果が出ていないスクラムイベントについてレトロスペクティブで議論し、イベントを再構築する
1~2をスプリントごとに繰り返す
レトロスペクティブでは、定期的に観測することでチームの課題を発見できる定量的な振り返りと、チームメンバーが一人一人感じている課題を議論する定性的な振り返りどちらも行う必要があります。
まずは、リーンコーヒーなどの定性的な振り返りの場で、スクラムイベントの見直しを議題に挙げてみましょう。
効果的なレトロスペクティブの実施方法は下記のnoteに記載しているので、ご参考までに。
最後に
ここまで読んでいただきありがとうございました。
「こんなの綺麗事でしょ！ここに書いていないアジャイルの穴なんていくらでもあるよ。そのような状況になったらどうすればいいのよ！」と思う方がいるかもしれません。
簡単です。
ビジネス価値が何かを考える
置かれている状況を言語化し、ビジネス価値を最大化するための開発プロセスを再構築する
ビジネス価値を理解できれば、いくらでも手段を変えることができる。それがアジャイルです。
自問自答するような記事になりましたが、何か少しでも気づきを得ていただけていれば幸いです。