アジャイル開発「スクラム」の価値を再認識する
初めてのアジャイル開発 〜スクラム、XP、UP、Evoで学ぶ反復型開発の進め方〜
―――――――――――――――
――――アジャイル開発――――
―――――――――――――――
経験とは、誤りを繰り返したときにそれを
誤りだと認識させてくれる、驚くべきもののことである。
―F.P.ジョーンズ
僕の勤める職場は、アジャイル開発を採用している。
※アジャイル手法は反復型手法のサブセットである。
アジャイルの中でも「スクラム」という開発スタイルを採用している（テスト駆動開発等XPも採用している）のだが、最近自分の中でスクラムの「価値」を忘れている気がしたので、書籍「初めてのアジャイル開発」を読んでスクラムの「価値」を思い起こした。
以下はアウトプットである。
「 スクラム 」
――――――――
―――目次―――
――――――――
●スクラムの主なプラクティス
●手法概要
●ライフサイクル
●ロール
●基本プラクティス
●スクラムミーティングの詳細
●スクラムミーティングの価値
●作業成果物
●スクラムの価値
●ありがちな間違いと誤解
●プロセスの組み合わせ
●採用戦略
●理想と幻想
●長所および「その他」
●導入理由（ここは省略気味に書きます・・・詳細や根拠は書籍を読んでください）
――――――――
―――内容―――
――――――――
●スクラムの主なプラクティスを前提とする
○自立的な自己組織化チーム
○いったんイテレーションの作業がきまったら、チーム外の人間はそれに追加することはできない
○スタンドアップミーティングを毎日行い、特定の質問をする
○原則30日（カレンダー上）のイテレーション
○イテレーション終了時に外部の利害関係者に対してデモを行う
○イテレーションごとにクライアント主導で適応型の計画を立てる
●手法概要
○スクラムが独特なのは、イテレーションの長さが正確に決まっている点である。
○儀式度の点では、スクラムは柔軟である。どのような作業成果物をどの程度作成するかについては述べていないし、どれだけ厳密に行う必要があるかも触れていない。あえて指針となる原則と問えば、スクラムの提唱者は「儀式度はできるだけ低く」というだろう。たとえば医療機器制御システムの場合なら儀式度を高くしてもよいし、ちょっとした情報を表示するだけのWebサイトなら低くする。
○スクラムのチームのメンバーは７人以下にするべきだが、プロジェクトを複数のチームで構成することも可能である。規模を拡大するのには「スクラムのスクラム」を組む。
○スクラムは他のアジャイル方法論のプラクティスを補う使い方が出来るため、生命にかかわるシステムからちょっとしたものまで、あらゆる領域のソフトウエアアプリケーションに適用することができるし、適用されてもいる。
○定義されたプロセスよりも経験的プロセスを重視することがスクラムの重要なテーマである。
●ライフサイクル
○スクラムのライフサイクルは「計画」「準備」「開発」「リリース」の４つのフェーズからなる。
●ロール
○プロダクトオーナー（顧客）・・・次のスプリントの目標を（プロダクトバックログから）選択する。各スプリントの最後には、他の利害関係者と一緒にシステムのレビューを行う。
○スクラムチーム（開発）・・・スプリント（イテレーション）のバックログに従って作業を行う。「チームメンバー」という以外には明示的な肩書きをつけない。
○スクラムマスター（マネジメント）・・・マネジメントだけでなく開発も行う。プロジェクトやイテレーションのビジョンや目標を良く知り、補強する。スクラムの価値やプラクティスが守られるよう気を配る。経営陣とスクラムチームの間に立つ。進捗に耳を傾け、障害を取り除く。日時スクラムを指導する。スプリントレビュー（デモ）を主導する。
○ニワトリ（チーム外のメンバー）・・・イテレーションの間、誰でも見守ることは出来るが、干渉したり口をはさむことは出来ない。
●基本プラクティス
○ゲーム前計画および準備
ゲーム前計画の期間中、利害関係者はだれでも、機能、ユースケース、機能拡張、欠陥などの一覧を作成し、「プロダクトバックログ」に記録することが出来る。プロダクトバックログの所有者として一人のプロダクトオーナーが任命され、要求はプロダクトオーナを通じて取り決められる。このセッションの間に、少なくとも最初のイテレーションを実施するのに十分な量の作業を洗い出す（もっともそれ以上の作業が見つかるのが普通だ）。
○スプリント計画
各イテレーション（スプリント）を開始する前に、２つのミーティングを続けて開催する。最初のミーティングでは、利害関係者があつまって、プロダクトバックログとリリースバックログの精度を上げ、優先順位を付け直し、今回のイテレーションの目標を決定する。優先順位は、通常最も高いビジネス上の価値やリスクによって決定される。２つ目のミーティグでは、スクラムチームとプロダクトオーナが集まって要求をどう実現するか熟考し、目標を達成するためのタスクを列挙した「スプリントバックログ」を作成する。 イテレーションの作業が進むにつれ、スプリントバックログは更新される。
○スプリント
作業は原則３０日（カレンダー上）のイテレーションに分割される。それぞれを「スプリント」と呼ぶ。
○自律的な自己組織化チーム
イテレーションの期間中、経営陣やスクラムマスターは、イテレーションの目標をどのようにして達成するか、問題をどのようにして解決するか、作業順序をどう計画するかについて、（判断を依頼されたり、報告された障害を取り除く必要がない限りは）チームに口出しをしない。
○スクラムミーティング
毎日、同じ時間、同じ場所で、チームメンバーは輪になってミーティングを開き、特定の同じ質問をして、各チームメンバーがそれぞれ答える。
○イテレーションに追加してはならない
イテレーション期間中、経営陣はチームや個人に対して作業を追加してはならない。中断されずに集中できるようにする。万が一何かを追加しなければならない場合は、代わりに他の作業をなくすのが理想である。新たな作業以来の見積もりがリソースの範囲内に収まる限りは、次のイテレーションで何をすべきかを指示することが出来る。
○スクラムマスターのファイアウォール
スクラムマスターは、チームが外部からの作業依頼によって作業を中断されないよう気を配る。中断された場合には、その原因を取り除いたり、政治的な問題や外部のマネジメントの問題に対応したりする。
○１時間以内の判断
スクラムミーティングで障害が報告され、スクラムマスターの判断が必要な場合には、即時に、あるいは１時間以内に判断を下すのが理想である。
｢悪い判断でもないよりはましだし、後で破棄することもできる｣という価値が奨励されている。
○１日以内の障害排除
スクラムミーティングで報告された障害は、次のミーティグの前に取り除かれるのが理想である。
○ニワトリとブタ
スクラムミーティングの間はスクラムチーム（ブタ）だけが発言することが出来る。そのほかの人（ニワトリ）は、出席できるが黙っていなければならない。CEOも同様である。
｢ニワトリとブタ｣の由来：ブタとニワトリが新しく開くレストランの名前について話し合った。ニワトリは｢ハムエッグ｣を提案したが、ブタは｢それはごめんだね｣と言った。｢君は生むだけだけど、僕は切り刻まれるんだよ｣
○７人のチーム
スクラムは、大規模なプロジェクトにも適用することができるが、１チームのメンバーは最大７人にすることが推奨されている。よって大規模プロジェクトでは、複数のチームを構成することになる。
○共通の部屋（推奨）
チームは、別々のオフィスや小部屋ではなく、共通のプロジェクトルームで一緒に作業するのが理想である。
○日次ビルド
少なくとも１日に１回、プロジェクトのチェックインされたコードをすべてを統合し、回帰テストを行う。
XPのプラクティス「継続した統合」を実施するとなおよい。
○スプリントレビュー
各イテレーションの最後には、スクラムマスター主催でレビューミーティングを行う（最大４時間まで）。チーム、プロダクトオーナー、その他の利害関係者が参加する。このレビューでは製品のデモを実施する。レビューの目的の一つは、システムの機能、設計、長所/短所、チームの作業、今後の問題が置きそうな箇所について、利害関係者に知らせることである。
●スクラムミーティングの詳細
スクラムミーティング（あるいは単純にスクラムと呼ぶ）は、スクラムとそれを採用したプロジェクトにとって、まさに心臓の鼓動とも言うべき中心となる活動である。全就業日の同じ時間、同じ場所で、チームメンバーが輪になって立ったままミーティングを行う。この時、特定の同じ質問をして、各チームメンバがそれに答える。
1.前回のスクラム以降、何を行ったか？
2.今から次回のスクラムまでに何を行うか？
3.イテレーションの目的を達成する上での障害は何か？
4.スプリントバックログに追加するタスクはあるか（新しい要求ではなく、忘れられていたタスク）
5.チームメンバーから刺激を得て（技術的なこと、業務知識などで）何か新しく学んだことはあったか？
その他の重要な点には、以下のようなものがある。
・ミーティングは立ったまま輪になって行い、短時間で終わらせるのが理想である。
・７人から１０人の場合、平均１５分から２０分で行う。
・チーム外のメンバー（ニワトリ）は輪の外に出る。
・ ｢ホワイトボードの前で行い、報告されたタスクや障害はすべて書き留める。書き留めた障害をスクラムマスターが消すのは、その障害が取り除かれた場合だけである。｣
・書き留めた障害をスクラムマスターが消すのは、その障害が取り除かれた場合だけである。
・その場にいないメンバーが参加できるように、スピーカーで会話できる電話機を使う（参加は必須である）。
・スクラムマスターは、ルールが守られるよう気を配り、効果的にミーティングを行える場所を準備する。
・時間どおりに開始する。
・ニワトリをブタのルールを適用する。
・質問以外の議論は禁止する。
・他の問題について議論する必要があれば、スクラムミーティングの終了後すぐに、通常はチームの一部のメンバーで別のミーティングを開く。
●スクラムミーティングの価値
価値：自律的な自己組織化チームであり、イテレーション中にマネジャーが作業者に指示したり（依頼されたとき以外に）問題を解決したりするわけではないため、スクラムミーティングはチームがプロジェクトやメンバーの状況について素早く知るための毎日のメカニズムとなる。
価値：次のスクラムミーティングまでに行う自分の作業を報告することは、チームに対してある種の社会的な約束をしたことになる。これによって、責任が生まれ、最後までやりぬくことが多くなる。
価値：スクラムは、ソフトウェア開発とは創造的で予測不可能な新製品開発であり、そのため定義された手法ではなく経験的手法が必要だと言う考え方にもとづいている。スクラムミーティングは、経験的手法には不可欠の頻繁な測定や適応型の応答を行うためのメカニズムとなる。
価値：プロジェクトのリスクには、タスクがすべて洗いだされていない、見積もりが正しくない、障害を迅速に解決していないといったものがある。スクラムミーティングでは、タスクを更新し、障害を浮かび上がらせて取り除くための機会を毎日提供する。
価値：人（やチーム）が常に向上し学習できるような環境を作ることが重要である。スクラムミーティングではこれが促進される。特に五つ目の質問を追加した場合には顕著である。言葉にして語られることのなかった（あるいは暗黙の）情報や知識が口に出され、共有される。
価値：言葉や価値、プラクティスを共有することは、開発チームの支えとなる。これは日次スクラムで作りだされ、強化される。
●作業成果物
○プロダクトバックログ
○スプリントバックログ
○スプリントバックロググラフ
●そのほかのプラクティスおよび価値
○スプリントバックログは毎日更新する。
○PERT図は使用禁止
○スクラムマスターはビジョンを強化する―スクラムマスターは、プロジェクトのビジョンとスプリントの目標を、毎日（たいていはスクラムミーティングの開始時に）共有し、明確にする必要がある。
○マネジャーやスクラムマスターは、開発者に奉仕するのであって、その逆ではない。スクラムマスターが障害を迅速に取り除いたり、ファイアウォールとなったり、必要なリソースを提供できないような場合には、スクラムマスターを交替させることをスクラムの提唱者は勧めている。
●スクラムの価値
○コミットすること―スクラムチームは、そのイテレーションの目標を達成することをコミットする代わりに、達成するにはどうするのが一番よいかを自分たちで判断する権限と自治権を与えられる。経営陣とスクラムマスターは、イテレーションに新しい作業を追加しないこと、チームに指図しないこと、リソースを提供し日次スクラムミーティングで挙げられた障害を迅速に取り除くことをコミットする。プロダクトオーナーは、プロダクトバックログを定義して、その優先順位を付け、次のイテレーションの目標を選択するのに際してチームを導き、各イテレーションの結果をレビューしてフィードバックすることにコミットする。
○集中すること―スクラムチームは、気を散らさずに決められたイテレーションの目標に集中できなければならない。そのため、経営陣とスクラムマスターは、チームにリソースを提供すること、障害を取り除くこと、新たな作業依頼を追加してチームの作業を中断しないよう心がけることに注力する。
○オープンであること―プロダクトバックログをオープンにしてアクセスしやすくすることで、作業と優先順位が見えるようになる。日次スクラムによって、チーム全体およびメンバー個人の状況とコミットメントが直にわかるようになる。バックロググラフを作成することで、作業の傾向と速度が見えるようになる。
○敬意を払うこと―または責任転嫁するのではなく、チームで責任を持つこと。チームメンバーそれぞれの長所／短所に敬意を払い、イテレーションが失敗しても誰か一人の責任にしない。マネジャーではなくチーム全体が、自己組織化と自律によって、グループで解決策を調べて｢個人の｣問題を解決するという姿勢をとる。また、専門のコンサルタントを雇って足りない知識を補うなどといった、難問に対応するための権限とリソースを与えられる。
○勇気を出すこと―経営陣は、勇気を持って、適応型の計画や方向性を示し、メンバー個人やチームを信用してイテレーションを行う方法に口出ししないようにする。
●ありがちな間違いと誤解
○チームがリーダーに指示や解決策を求めることは自然なことだが、それに答えると自律したチームではなくなってしまう。
○メンバーまたは日次追跡担当者（トラッカー）によってスプリントバックログが毎日更新されない。
○いったんイテレーションが始まったら、期間中は要求を変更してはいけないのが、スクラムを実施するうえでのポイントである。 ○スクラムは顧客が中心になって進めるものである。プロダクトオーナーは、プロダクトバックログの優先順位を決め、次のイテレーションで実現する要求を選ぶ必要がある。
○スプリントレビューを行っていない―スクラムはフィードバックと適応によって進む。デモとレビューによる情報提供で、顧客は次のイテレーションの方向を決めることが出来る。
○船頭が多すぎる―スクラムでは、プロダクトバックログの要求、優先順位、次のイテレーションの作業を決めるのはたった一人、プロダクトオーナーである。
○ドキュメントが不十分である―スクラムは反文書主義ではない。プロジェクトの作業成果物として作成するドキュメントをスクラム内部で定義していないだけである。すべてのアジャイル手法にあてはまることだが、コード以外の作業成果物は、プロセスが定めているからと言う理由で作成するのではない。それが実質的な価値をもたらすと期待できるからこそ作成するのである。
○計画や図の作成が不十分である―スクラムは、チームがどう設計を行うかについては、理論よりも実用を重視している。イテレーション中にプログラミングを始める前に設計したり図を描いたりすることに価値があると思うなら、行うべきである。
○顧客および経営陣を含むチーム全員がスクラムとその価値について要点を知らされていない。
○スクラムミーティングが長すぎる、あるいは要点が絞られていない―２０分以下に抑え、スクラムで決められた質問に集中する。 ○イテレーションの最後に、部分的な製品の統合およびテストを行っていない―イテレーションは終了日に終わるだけではない。すべてのソフトウエアを統合し、テストし、次のイテレーションへのベースラインとすることが目標である。
○各イテレーションの最後に必ず製品リリースが作成される―スクラムのイテレーションで製品リリースが出来上がることもあるが、必ずしも想でなくて良い。製品リリースの準備が出来るまでに何回ものイテレーションが必要なこともある。
○予測型計画、PERT図を使った計画―すべてのIIID手法に当てはまることだが、厳密に段取りを決めた計画を作成することは間違いである。
●プロセスの組み合わせ
○スクラム+Evo
Evoのプラクティスの一部は、スクラムと組み合わせることができる。スクラムでは具体的な仕様の記述方法については触れられていないので、EvoのPlanguageを適用することが出来る。Evoが測定を重視していることは、スクラムとうまく適合する。
○スクラム+UP
スクラムのプラクティスは、UPのプラクティスとまったく同じかそれを特化したものになっている。さもなくば矛盾なく追加されたものである。スプリントバックログはUPの反復計画書として扱うことが出来る。スクラムではプロセスや予測可能なステップを定義することを否定しているため、UPの作業を必須の手順だと考えた場合には、この構造と矛盾する。しかし、あるプロジェクトにおいて、これらの作業は参考までにとどめ、任意の順序で作業を遂行し、順序や期間のスケジュールを立てないのなら、そのプロジェクトはスクラムだといえる。
○スクラム+XP
スクラムミーティングなどのスクラムのプラクティスは、ほとんどXPやその改良版と一致する。
●採用戦略
○スクラムの提唱者は、組織の中のもっとも困難で重要なプロジェクトにまず採用することを奨励している。
○最終的にスクラムのプラクティスを開発組織の最上位レベルまで広げるよう奨励している。
●理想と幻想
○プロセスは副次的な効果しか持たない。一人ひとりの個性、感情や素質の方が影響が大きい。
○スクラム現場で実施している人は、スクラムの理想と具体的な使われ方が大きく異なっているとは報告していない。これはおそらく、他のアジャイル手法と比べてプラクティスが比較的少なく明白なためである。
●長所および「その他」
○長所
・簡潔なプラクティスとマネジメントのための作業成果物。
・個人やチームによる問題解決と自己マネジメント
・進化型のインクリメンタルな要求および開発と、適応型の振る舞い。
・顧客参加と顧客主導の舵取り。
・集中。
・オープンで見通しが良い。
・他の手法と組み合わせやすい
・チームのコミュニケーション、学習、価値構築。
・日次スクラムによるチームの構築。共通のプロジェクトルームにいない場合も同様である。
○その他
・プロジェクトマネジメント以外の作業分野（プログラミングなど）の指針は、最低限になっている。つまり、スクラムでは、たとえばソフトウエアや要求工学の技術より、開発のライフサイクルやプロジェクトマネジメントの側面を重視していると言うことである。
・多くのプロジェクトでは何らかのドキュメントが必要になる。スクラムではそれが何かを定義していないため、プロジェクトごとに、目的は同じだけれども、名前や内容の異なるドキュメントを作成する可能性がある。
●導入理由（ここは省略気味に書きます・・・詳細や根拠は書籍を読んでください）
○ソフトウエアの不確実性の原則
ソフトウエア開発プロジェクトの変更の割合が高いことが、アジャイルな反復型手法を取り入れる中心的な動機である。
○反復開発を導入する主な理由
・反復開発のほうがリスクが低く、ウォーターフォール型の方がリスクが高い。
・初期におけるリスクの軽減と発見
・早い段階で変化を引き起こしてそれに対応できる。それは新製品開発と同じである。
・複雑さに対応できる。
・早い段階で繰り返し成功することで得られる自身と満足
・早期の部分的な製品化
・適切な進捗管理と優れた予測性
・高い品質、少ない欠陥
・最終製品がクライアントの真の希望に適ったものになる
・早い段階からの定期的なプロセス改善
・コミュニケーションと参加が必要
・IKIWISI（「見たら分かる」I'll Know It When I See It）が要求される
○タイムボックスの利点
「集中」
｢休暇の前の日にできる仕事の量には驚くばかりだ｣。納期までたった3週間しか残っていない場合と、次のマイルストーンが3ヶ月後の場合とでは、チームが発揮する集中力はまったく異なってくる。パーキンソンの法則への対策。
｢人は期限を守れなかったことはよく覚えているが、内容が少しくらい不足していても気にはしない｣
○要求に関する問題への反復的な対処
｢要求は25%以上変化する｣
○ウォーターフォールの問題点
ウォーターフォールが困難であることの根底にある理由は、変化や目新しさが少なくあまり複雑でない領域でしかうまくいかないことである。ウォーターフォールでは複雑さによる負荷が重くなり、分析麻痺が発生する。
○問題：事前に承認まで済んだ「完全な」仕様の作成
調査の結果を見ると、それはほとんど不可能であり、興味深いことに、大規模な研究の結果、初期の仕様で作成された機能の45%はまったく使われることなく、さらに19%はほとんど使われていないことが分かっている。
○問題：プロジェクト後半での統合とテスト
基本的なところでの思い違いや誤った想定があり、しかもそれが最終段階になるまで表面化しない場合がある。
○問題：「信頼性の高い」事前のスケジュールと見積もりの作成
早い段階で予測型計画を立てることは、変化がすくなくあまり複雑ではない。
○問題：「仕事を計画し、計画を実行する」価値
ソフトウェア開発のように変化が激しく斬新で創造的な領域では、粒度の粗い作業やマイルストーンのような概要レベルの計画しか意味をなさない。
