ブログ

ryuzeeによるブログ記事。不定期更新

アジャイル開発やスクラムのトレーニングでよく聞かれる質問とその答え (1)

みなさんこんにちは。@ryuzeeです。

弊社ではアジャイル開発、スクラムのトレーニングを提供しているのですが、トレーニング中には多くの質問をいただきます。 今日はよくある質問とその答えについていくつかご紹介したいと思います。 好評そうだったら続編も書く予定です。

■アジャイル開発において、ドキュメント作成の一般的な指針を教えてください

どのようなドキュメントがいつ、どの粒度で必要なのかはプロダクトやプロジェクトに依存します。 プロダクトやプロジェクトにはそれぞれ固有の品質基準があり、それはアジャイルやウォーターフォールといった方法論の違いによって変わるものでもありません。 したがってプロジェクト冒頭でプロダクトオーナーやステークホルダー(品質管理部門や顧客など)と「なんのために」「どのようなドキュメントが」「どのような記述レベルで」「いつまでに必要なのか」を決定してください。 誰も使う予定のないドキュメントはムダなので作成は不要です。

また、チーム内の議論のためのドキュメントであればWikiなどを活用して、ドキュメント作成やメンテナンスの負荷を下げる必要があります。 メンテナンスされていないドキュメントは事故を起こす可能性があるため、機能の実装や更新とあわせて変更しないといけませんが、このときドキュメントが多すぎると必ず不整合を起こすため、数を減らす・一箇所に集める・自動生成するといったことを検討してください。

■アジャイル開発を適用するにあたって、顧客や上司、社内の関係部門がウォーターフォール型の報告を求めるのですがどうすればよいですか

アジャイル開発をきちんと理解できていないと、結果的に従来と同じようにスコープ、期日、費用を全て固定して達成しようとしがちですし、その観点で全体を見ようとしてしまいます。 また、関係者のプロジェクトへの継続的な関与が不十分になることもあります。 したがって関係者がアジャイル開発の概念を理解していない場合は、考え方を説明するセッションやトレーニングを事前に実施します。 後から散発的に説明するとどうしても時間が余計にかかるので、先に理解してもらってから始めるということになります。 それでも報告が従来の形に近いものが求められることはありますが、それぞれの数値からどんなことが知りたいのか把握できれば、アジャイル開発の工程の中でも他のメトリクスを使って説明することもできるはずです。 プロジェクトの立ち上げフェーズで報告の仕方についても議論し決定しておくとよいでしょう。

なお、精緻なデータを集めたりレポートを作る作業を開発チームにさせてしまうと、価値のあるプロダクトを作るのに使える時間が減ります。 スクラムマスターやプロダクトオーナーが良きに計らって報告する形がベストだと思います。 もちろん開発チームは常に透明性のある状態でなければいけないことに変わりはありません。

■プロダクトバックログの上位の項目は見積りができるくらい詳細化されている必要がありますが、この詳細化の作業をスプリント外で他のチームがやってもよいですか

要求を詳細化する(少なくとも開発できるぐらいに具体的にする)作業をバックログリファインメントと呼びます。 このイベントは次のスプリントを始める上で重要な活動なので、前のスプリントの中で開発チームやプロダクトオーナーが自分たちの時間を使って実施します。 つまりスプリントで開発に使える時間はその分減るということです。 一般的にはスプリントの時間の10%程度はこのバックログリファインメントに使います。

要求が具体的になっていない状態でスプリントに投入して開発をはじめてしまうと大きな手戻りが発生したり、プロダクトオーナーとのかなり頻繁なコミュニケーションが必要となってしまい成果の予測ができなくなります。 開発チームとして作れるかどうかの判断をしないといけないので、別チームが要求を詳細化するのではなく、実際に開発を行う人たちを中心として詳細化を行います。 もちろん規模が大きい場合には、アナリストなどの職種の人が詳細化に参加することはありますが、アナリスト単独で詳細化することはないと考えてください。

■アジャイル開発の経験者を採用したいのですが、面接でどんな質問をすればよいですか

これを聞けば絶対という唯一解はないのですが、一例としていくつか紹介します。

  • プロセス全体をホワイトボードに書いて説明してもらう
  • 過去にどのようなふりかえりの方法をとったことがあるか、それぞれの手法のメリットはどのようなものかを聞いてみる
  • どのような計画の立て方をしていたのか説明してもらう
  • プロダクトバックログにどのようなことを書いていたのか説明してもらう
  • 実際にアジャイル開発をしてうまくいったこと・いかなかったことを説明してもらう
  • アジャイル開発におけるエンジニアリングのポイントを説明してもらう

■各スプリントで回帰テストをしていると大変なのですが、どうすればよいですか。スプリントを経るごとにテストの負荷が増えていくのですが

完成の定義という品質基準をスプリント開始前に定めて、スプリントではその品質を満たすようにしないといけません。 そもそもその基準を満たしていないものは、リリース判断の対象にすらならず、プロダクトバックログアイテムも完成とはなりません。 したがってテストは自動化し、コードの変更を行うたびに全てのテストを毎回自動で実行しリグレッションがないことを検証するといった活動が必要です。 スクラムでは自動化自体は定義されていませんが、毎スプリントでリリース判断可能なものをつくるためには事実上はテスト自動化が必須です。

なお、実際のリリースに際して必要なすべての品質をスプリント中に満たせるのであれば、スプリント中でもいつでもリリース可能となります。 一方でプロダクトの性質によっては数か月単位でのリリースに決まっていたり、リリースするには外部のセキュリティベンダーによるペネトレーション試験が必要だったりすることもあります。 こういったケースでは、リリース前に「リリーススプリント」と呼ばれるテスト期間をとることもあります。 ただし、スプリントで担保している内容と、実際のリリースで担保しなければいけない内容に差が多ければ多いほど、急な変化に対応したりはできなくなりますし、大きな品質問題が最後に見つかる可能性もあります。

■SCRUMとXPを組み合わせる場合、リファクタリングはプロダクトバックログやスプリントのタスクに入れた方がよいですか。それとも各自が定常的に実施すればよいですか

アジャイル開発の場合、インクリメントの考え方のとおり、動作している(役にたっている)プロダクトに機能を追加していく形になります。 したがって、一度書いてテストしたコードは「壊さないために触らない」ということはなく、スプリントを重ねるごとに変更が入ることがあります。 つまり常時変更が入る前提でコードをクリーンな状態に保つことが必要です。

リファクタリングの習慣が開発チームにまだないような状態であれば、明示的にプロダクトバックログを用意したり、スプリントのタスクとしてこなすようにします。 ただし、時間をかけて、リファクタリングを続けるのが開発チームの習慣になるようにしていきます。 なお、前述のとおり、完成の定義(品質の基準)を満たしていないコードは例え動作したとしても、出荷可能ではありません。 つまり完成の定義の中で「コードレビュー」や「コードの複雑度」や「コーディング規約遵守」などを決めていた場合は、スプリントの中でそれらを満たさないといけません。 後になってから問題のある箇所をまとめて直すような形にしてしまうと、それが終わらない場合出荷ができなくなるので、定常的にやる方がリスクが少なくなります。

■1つのプロダクトバックログアイテムが大きくて1スプリントでは作れません。複数スプリントにまたいで開発してよいですか

1つの機能が大きい場合、その機能には多くのサブ機能が含まれていることが多々あります。 例えば、「ホテルの予約をキャンセルできる」というプロダクトバックログアイテムは、

  • プレミアムメンバーであれば24時間前までキャンセルできる
  • 一般メンバーであればN日前までキャンセルできる
  • キャンセルした場合はメールで通知する

という3つに分けられるかもしれません。 このような形で、1スプリントに入るサイズにプロダクトバックログアイテムを分割してください。 なお、コンポーネント単位では分割してはいけません。 あくまで意味ある機能単位で分割してください。 また、そもそも1スプリントで1つのプロダクトバックログアイテムだけを作るというのも、サイズが大きすぎます。こうしてしまうと成果(ベロシティ)が0のスプリントが頻繁に発生する可能性もあります。 スプリント期間の半分程度で終わるサイズになっていると、スプリントでの成果の量が安定しやすくなります。

別の観点として、その機能の設計や調査も含めて時間がかかる、といった場合は、その機能はまだスプリントで着手する準備ができていない状態の可能性もあります。 スプリントに入る前に事前に「機能として何ができていれば完了なのか」「それはどうやってテストできるのか」等が合意できているものだけを着手してください。 準備ができていないもののうち実装の優先順位の高いものは、次のスプリントに入る前に「バックログリファインメント」のイベントなどで準備完了状態にする活動をします。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック