ブログ

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

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

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

先日、弊社がアジャイル開発やスクラムのトレーニングの際によく質問いただく項目とそれへの回答を一部紹介しました。 参考になると言ってくださった方も多かったようなので、第二弾を公開します。

■請負契約でアジャイル開発を進めるコツを教えてください

悪いことは言わないので、請負契約は避けた方が良いです。 最初にスコープを全て洗い出して固定し、そこから期日と費用を見積もって請負契約したのであれば、完成責任と納入責任を負わざるを得ません。 一方でアジャイル開発は「スコープが変化する」「全てのことを事前に予測することはできない」という考えを中心においています。 ですので完了する責任をもって契約するのではなく、「変化に最大限対応すること」「最善をつくすこと」を約束します。 必ず完了させなければならない契約に対してアジャイル開発を適用してしまうと、「変化」の要求は受け手側にとってはコスト増大・期間延長のリスクにしかなりません(定額時間無制限食べ放題みたいなものです)。 準委任型の契約にしましょう。 それでも顧客が請負契約を求める場合があるかもしれませんが、その場合は顧客がそもそもアジャイル開発を理解していない可能性があるので、考え方を説明して理解してもらう活動が必要です。

■スクラムの開発チームメンバーはクロスファンクショナルでいろいろなことができると思いますが、そんな優秀な人たちがいるならウォーターフォールでもうまくいくのではないですか

誤解のないようにいっておくと、個人としてインフラやアプリを始めとするさまざまな領域の設計や実装を全部できないといけないわけではありません。 開発チーム全体を見た時に必要なスキルを網羅していることがだいじです。 外部のチームへの受渡しや依存が増えれば増えるほどリードタイムは長くなり、計画作りも難しくなります。 また、いま複数のスキルがなくても開発チーム一体で開発を進めていけばいろいろなスキルが身に付きますし、開発チーム全体の能力もどんどんあがります (もちろん最初のうち特定のスキルが特定の人に依存する場合もあります。その場合はその人がボトルネックになるためクリティカルな領域であるほどなるべく早く単一障害点の解消が必要です)。

なお、「うまくいく」の基準はウォーターフォールとアジャイルでかなり違います。 ウォーターフォールは事前にたてた計画を守れれば成功、アジャイル開発はプロダクトによってビジネスの成果が出せれば成功です。 その点を抜きにして、開発チームの生産性や効率だけを議論することに意味はありません。

■スプリントの長さは固定ですが、祝祭日があって営業日が減る場合はどうしたらよいですか

スプリントプランニングやスプリントレビューは定期的に実施することにメリットがあるので、基本的に曜日を固定することをお勧めします。 つまり祝祭日があった場合は、その分スプリントの稼働日数は減ります。 開発チームが使える時間も減るので、計画ではそれを考慮して取り組むプロダクトバックログアイテムを減らすのが一般的です。 また研修などでの不在や休暇も考慮に入れるとよいでしょう。 スプリントの総稼働可能時間から不在の時間や各種イベントの時間を抜いたものが開発チームのキャパシティになります。 キャパシティを超えたタスクに取り組もうとしても終わらないので、スプリントプランニングでタスク量とキャパシティを比較し、タスク量が多すぎる場合は末尾のプロダクトバックログから順番にスコープから外していきます。 キャパシティについてはあらかじめ20〜30%程度のバッファを取っておくと安心です(間違っても1日8時間全部が開発に使えるとは決して思わないようにしてください)。

なお、日本は月曜日に休日が多いので、スプリント開始日を月曜日にしない方が運用しやすいと思います。

■プロダクトバックログの見積りについて、規模や工数を算出する時にどんな方法を使えばよいですか

プロダクトバックログアイテムの見積りは継続的に実施する活動なのでタイミングごとに説明します。

まずプロジェクト初期に全体で必要そうな工数や期間などを算出します。 算出の仕方はスクラムでは規定はありませんので好きなやり方を使ってください。 例えばファンクションポイントも使えますし、見積りのノウハウが蓄積されていればそれを使っても構いません。 大事なのは初期のプロダクトバックログアイテムのすべての開発を「約束」するわけではないので、この見積りは開発チームのサイズや期間の算出に使うだけであるというのを意識することです。 ここで開発チームのサイズと期間が決まれば、プロジェクトにかかる費用は算定が可能です。 もちろん先に予算確保や投資可能額が決っているのであれば、それを前提にしても構いません。

次に個々のプロダクトバックログアイテムの見積り方法ですが、これ自体もスクラムでは細かい決まりはありません。 決っているのは「プロダクトバックログアイテムを見積もっておけ」という点です。 人日や人月で見積もっても構いませんが、細かく見積もることにあまり意味はないので、相対的なサイズを1,2,3,5,8,13,20…などのフィボナッチ数列を使って表したりTシャツサイズと呼ばれるS/M/L/XL/XXLなどで表したりします。 最初の何回かのスプリントを実施すると開発チームがどれくらいの量を1スプリントで完了できるかが分かってプロジェクトの着地点の予測精度が向上していきます。

なお、個々のプロダクトバックログアイテムの見積りはスプリントが進んで色々なものができあがったり開発チームの能力が向上することによっても変わっていきますので、バックログリファインメントのイベントを活用して上位のプロダクトバックログアイテムは定期的に見積りしなおしてください。

■スプリントプランニングやレトロスペクティブで、スクラムチーム内の議論についていけないメンバーがいた場合、どうしたらいいでしょうか

基本的にはスクラムチーム内で解決方法を考えてください。 例えば新人であれば話が分からなくてついてこれないのは当然ですが、ずっとそのままにしておくといつまでたってもチームの総合力が上がらないので、優先順位の高い課題として対処しないといけません(例えばペアで作業したり説明の時間をとるなど)。 一方で本人の資質やマインドセットに問題があって、チームとしてできる限りはやってみたということであれば、スクラムマスターやラインマネージャーがその人をチームから除外するという判断をした方がよい場合もあります。 ただしいずれにせよ、まずはチームで全力で解決しにいってください。

なお、似たようなケースでスクラムチーム内で決めた規律を守らない人がいる場合もあります。 たとえばイベントごとに来ない、完成の定義を守らない、着手すべき順番に着手しないで好きなものばかりをやるといったものです。 このような状況を放置すると、スクラムチーム全体の規律が失われていきます。 技術的に優秀かどうかに関係なく対処をしなければいけません。

それでは。

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

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

詳細はこちら
  • スクラム実践者が知るべき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』の著者がコンパクトにまとめた変化のためのガイドブック