「アジャイル開発とスクラム」完全版①

本投稿は、『アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント』（翔泳社）の内容を中心にまとめました。
自身のプロジェクトでスクラムを行っていること、また私自身スクラムマスターとして活動していることから、改めてアジャイルとスクラムの関係性やスクラムのフレームワークについてまとめました。

アジャイル開発は、ソフトウェア開発の手順を変えるだけではなく、そこで働く人に着目し、エンジニアが協調的に、モチベーションをもって仕事に取り組めるような意識改革も含んでいる。

第1部 アジャイル開発とは何か、スクラムとは何か

• 従来のソフトウェア開発
  • 分析・設計・実装・テストという開発工程を踏んで、その工程間を仕様書（ドキュメント）で意図的に伝える。
  • 顧客やユーザは最後まで動くものが見えない。
  • 紙に書かれた文書で仕様を理解しなくてはならず、誤解も生じやすい。
  • そもそもの要求は、ソフトウェア完成時点で古くなっている。
• アジャイル開発
  • 分析・設計・実装・テストを短い期間で並行して行い、それを繰り返す。
  • 顧客にとって価値の高い機能から開発し、短い期間で動くソフトウェアを完成させる。
  • 文書や報告ではなく、動くソフトウェアを一定間隔でつくり、それを成長させる。
  • 開発を通して、ユーザや顧客の意見をフィードバックしながら進める。
  • 途中で修正が入るのは普通、機能の優先順位も途中で変更される。
• アジャイルソフトウェア開発宣言
  • 左側に価値を認めつつも、右側により価値を置く。
  • ※左側を否定しているわけではない。
  • 2001年に、今のアジャイルのような価値観をもつ開発方法論の提唱者が集まって、考えられたもの。
  • アジャイルは、この会議で初めて命名された、このような価値観を持つ開発方法の総称。
  • スクラムのその1つ。

• まとめ
  • アジャイル開発は、手順やプロセスだけでなく、アジャイル宣言に述べられている価値観に根ざしている。

第2部 なぜアジャイルなのか

• 従来の開発手法

  1. ビジネスとITのゴールが分断されている。この結果、リリースされたシステムのうち、3分の2は使われない機能となっている。
     • ビジネス：システムを開発し、投資した以上の効果をあげること
     • IT：契約を満たすこと。仕様どおりのシステムを納品すること。
  2. 開発にかかる時間
     • 市場を調査してから実際にシステムが市場に投入されるまでに半年～1年以上。もはや市場は動いている。

• ゴールを共有した開発へ=アジャイル

  • ITのゴールは仕様を充たすことではなく、ビジネスとしての効果を上げること。

• アジャイル採用の動機

  1. 市場投入までの時間短縮
  2. 要求の優先順位変更が可能

• 採用したアジャイルの方法論

  1. スクラム（52%）
  2. スクラムとXPのハイブリッド（14%）

• まとめ

  • アジャイル開発浸透の背景には、ビジネスの変化の速さがあり、市場投入を早めること、要求の優先順位に対する柔軟性が必要となった。アジャイルはこれを解決可能。このアジャイルの考え方の中で、現在最も浸透している方法論がスクラムである。

第3部 スクラムとは何か

• 開発経緯
  • 1990年代前半に、ケン・シュウェイバーとジェフ・サザーランドによって開発された。
  • 成功率が低く、管理者はいつも不機嫌で、開発者は常にプレッシャーにさらされ、顧客は不満足であるという状況をなんとかしたいという情熱
• 従来プロセスとの違い
  • ウォーターフォール：予見的プロセス
  • スクラム：経験的プロセス
    • 未来を予見することなく、反復による実際の測定を通じて知識を獲得していく
    • そのためには、透明性を確保しながら、検査と適応を繰り返す必要がある
• スクラムのプロセスにおけるワード
  1. スプリント：アジャイルの反復（イテレーション）のこと。30日が基本だが、プロジェクトの性質による。
  2. プロダクトバックログ：開発すべき製品の機能リスト
  3. スプリントバックログ：プロダクトバックログの中で、対象スプリント内で実施する量を取り出したもの
• スクラムの基本的な流れ
  • アジャイルでは、1~4週間の期間を区切って開発を行い、それを繰り返すことでプロダクトを成長させる。
  • プロダクトバックログから取り出したスプリントバックログを、開発チームは製品に機能として追加し、出荷可能な状態にまでスプリント期間内でもっていく。
  • このようなスプリントを繰り返すことで、製品をいつでも出荷可能な状態を保ったまま成長させる。
• スクラムは非常に薄いマネジメントの枠組み
  • 決められているのは、チーム全体が協調するためのコミュニケーションのルールだけ
  • 3つの役割、3つの成果物、5つのイベント

3つの役割、3つの成果物、5つのイベント

1. 3つの役割

2. プロダクトオーナー

   • 開発に対して行う投資に対するROIを最大にすることに責任を持つ役割。
   • 開発チームが最も価値の高いソフトウェアを開発してもらうために、製品に必要な機能を定義し、優先順位付けをする。
   • バックログへの追加、削除、優先順位付けに対する最終的な責任を持つ。
   • プロダクトの機能を開発チームに十分に説明し理解をしてもらう。プロダクトのビジョンを示すことも大きな仕事。

3. 開発チーム

   • 実際に開発を行うチーム
   • スクラムでは、ビジネスアナリスト、アーキテクト、デザイナー等の明確な区分けはない。
   • 個人の専門性はあってよく、むしろ強みを持ち寄り、その垣根を越えて貢献しあう。
   • 機能横断的に、様々な技能をもった人が製品を中心に集まり、自律的に行動する。
   • 開発チームは、バックログに入っている項目を完了状態にし、製品の価値を高めることに責任を持つ。

4. スクラムマスター

   • チーム全体が自律的に協調できるように、場作りをするファシリテーター的な役割。
   • 開発チームが抱えている問題を取除く。開発チームを外部の割り込みから守り、チームの障害を取除くために外部との交渉を行う。
   • 製品のビジョン作りやバックログ管理について、プロダクトオーナーを支援する。
   • 開発のやり方に関する決定はスクラムマスターが決めるのではなく、開発チームが行う。
   • スクラムマスターが細かく指示を出すのではなく、自分たちで決めながら動く自律したチームを作ることが生産性をあげる鍵

5. 3つの成果物

6. インクリメント

   • 1回のスプリントの成果。スプリントで完了した製品の機能
   • スプリントの終わりには、インクリメントが動く状態である必要あり
   • レビューして、プロダクトオーナーが実際に製品をリリースするかどうかを決定する

7. プロダクトバックログ

   • 製品へ追加する要求リスト
   • ユーザのわかる言葉で書かれている。
   • プロダクトオーナーが管理
   • 順位付けされていることが重要。製品の開発が続く間変化し続け、維持される。

8. スプリントバックログ

   • 今回のスプリントで追加する機能のリスト
   • スプリント計画でオーナーの決めた順位と開発チームの見積もりの双方の情報を併せて抜きだされる。

9. 5つのイベント

10. スプリント

    • 反復の単位
    • 1~4週間のタイムボックス
    • 予定されている機能が完成できなくても、延長されることはない。

11. スプリント計画

    • スプリントの開始に先立って行われるミーティング
    • プロダクトバックログから今回のスプリントで扱うスプリントバックログを抜き出して決定する
    • プロダクトオーナが、優先順位に従って今回扱うバックログを選び出し、スクラムチーム全体でそれらを理解する。
    • 開発チームが見積もり、前回のスプリントで測定された開発実績に照らして、順位の上からどこまで今回のスプリントに入れるかを決定する。
    • 祖母後、開発チームが計画を詳細化、タスクにまで分割する。

12. デイリースクラム

    • 全員の活動状況の共有。
    • 昨日やったこと、今日やること、障害になっていることを確認
      -　毎日決まった時間に決まった場所で、15分の短い時間で。
    • 開発チームが解決できない障害を取り除くのが、スクラムマスターの役割

13. スプリントレビュー

    • スプリントの終了後、開発者を呼び集めて出来上がった製品のデモを行う。
    • 開発チームにとっては、バックログが動いていることをアピールする場
    • 他の関係者にとっては、スプリントがうまくいっていて、製品が徐々に成長しているのを知る機会

14. レトロスペクティブ

    • 今回のスプリントを振り返る機会
    • うまくいったこと、うまくいかなかったこと、どうやったら次のスプリントでうまくできるか、が話し合われる。
    • 検査と適応の機会。チーム学習、チーム改善の活動

• まとめ
  • スクラムは役割、成果物、イベントからなる非常にシンプルな開発の枠組み
  • もっと色々な決め事やプラクティスを導入する必要があるが、それらはチームが自律的に選択して取り入れていく。

第3部補足：従来の開発手法の問題点

利点は非常に論理的であること。欠点はこのプロセスに人間が関与していることで、多くの問題点が起きる。
不確実性の高い領域においては、アジャイルの方がよい。そしてそういう現場は増えてきている。

1. 人の創造性を奪ってしまう

• 途中で計画外のより良いやり方が見つかっても採用することができない。
• 変更を認めないプロセスは、イノベーションの機会を潰してしまう。
• ウォーターフォールにおいては、最後に見つかったすばらしいアイデアは、幸運ではなくむしろ脅威。

1. 文書によるコミュニケーションの限界

• ウォーターフォールにおいては、情報の伝達手段として、文書化が重要な手段
• 紙に書いた文書は、仕事を完成させたという物理的な根拠となる
• 現実には、文書化されたドキュメントは思考の不完全なコピー
  • 詳細に記述された仕様書はなかなか読まれない。
  • その中には誤解や間違いが含まれる。
  • 別の人がそれを読んで脳内再生すると、元の思考とは2段階離れたものを生み出してしまう。

1. 悪いタイミング

• 実際の製品に触れたときに、より良いアイデアや改善が思いつく
• ウォーターフォールにおいては、最もコストがかかる悪いタイミング

1. 未来を予見できない

• 競合企業の製品リリース
• 予見していなかった技術的な問題

1. 仕事が楽しくない

• 工程を追って仕事を進めるやり方は、仕事を渡す側と受ける側の間に敵対関係を生み出す。
• ウォーターフォールの開発モデルは、製品作りにかかわる人々のモチベーションをそぐ原因になる。
• 成果物は、開発者の創造性、スキル、情熱を表現したものにはならない。
• 人間はロボットではないので、ロボットのように働くことを求めるプロセスは、人々を不幸にする。

1. 部分最適化

• 変更を拒むプロセスからは、平凡な製品しか生まれない
• 最初のアイデア以上にはならない
• かかわる人々が開発で学んだり発見した新しい知識があれば、それ以上の良いものができるはず。。。