196冊目：「アジャイル開発とスクラム 顧客・技術・経営をつなぐ協働的ソフトウェア開発マネジメント」

総評：★★★★☆　スクラム開発がとてもよく分かった。
面白い度：★★★☆☆　普通に面白かった。
読みやすい度：★★★★☆　読みやすい。
ためになる度：★★★★★　今の自分にめっちゃためになった。
また読みたい度：★★★★☆　必要なときに読み返したいと思う。

タイトルの通り、システム開発におけるアジャイル開発とスクラムについて書かれた本。

システムは、今までウォーターフォール開発という方法論が主流だったが、10年くらい前からアジャイル開発という手法が勢いを増してきている。

現在自分の入っているプロジェクトでは、新規システムの開発においてアジャイル開発を採用し開発を進めているので、未経験の自分としてはアジャイルの開発方法とは何か？といった所から知識を深めるために図書館で借りて読んでみることにした。

ウォーターフォール開発は、フェーズという開発の段階に区切られていて、そのフェーズ間の作業のインプット・アウトプットとして、成果物のドキュメントの完成をもってフェーズが切り替わる。

フェーズというのは、要件定義、基本設計、詳細設計、製造、単体テスト、結合テスト、統合テストといった段階がある。

その間のインプット・アウトプットの成果物としては、要件定義書、基本設計書、詳細設計書、単体テスト仕様書(テスト結果)、結合テスト仕様書(テスト結果)・・・

といった感じに、それぞれ対応するドキュメントがある。

アジャイルはフェーズというのが明確に区切られておらず、作成するべきドキュメントというのも決まっていない。

アジャイルは実際に動くシステムを見て修正し、改善し、変更していくという、一つの開発サイクルが短く、システムに変更が入ることを前提に、柔軟に開発を行っていくというイメージになる。

そのアジャイルを行っていくためには、「やり方」がとても重要で、チーム全員で同じ認識を共有し、全員が考えながら共同し主体的に動くことが前提になっている。ていうかそういう動き方をしなければうまく行かない。

そのために、「朝会」を行い、日次で情報共有、「振り返り」で次のアジャイルの開発の単位(「スプリント」と言われる)に向けて改善をしていく、などのやり方を採用し、運営を行っていく必要がある。

そういった考え方は今までウォーターフォール開発しかやってこなかった自分としては結構新しい概念であり、アジャイル開発というのを実際にやってみたいなと思った。

アジャイル開発は、「アジャイル宣言」と呼ばれるものが2001年に出されており、開発の価値観の根底をこの宣言に置いているのだった。

アジャイル宣言をここに記載しておく。

「アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践

あるいは実践を手助けする活動を辻て、

よりよい開発方法を見つけだそうとしてる。

この活動を通じて、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。」

これがアジャイル開発の根底に流れている考え方ということで、

すぐに思い出せるようここに書いておくことにしておく。

そんなんで、この本で覚えておくべきと思った内容を以下に抜粋する。

・スクラムの枠組み

■役割

　プロダクトオーナー　何を開発するか決める人

　開発チーム　実際に開発作業に関わる人々

　スクラムマスター　全体を支援・マネジメントする人

■成果物

　インクリメント　スプリントで完成された機能で、出荷判断可能なソフトウェア

　プロダクトバックログ　順序付けられた製品の機能リスト

　スプリントバックログ　スプリント内で開発する機能リスト

■イベント

　スプリント　開発の反復単位

　スプリント計画　スプリント内で行う開発を決定するミーティング

　デイリースクラム(朝会)　毎日行われるミーティング

　スプリントレビュー　スプリントの最後に行われるインクリメントのレビュー

　レトロスペクティブ(振り返り)　スプリントの最後に行う改善活動

・スクラムマスター

　スクラムチーム全体が自律的に協働できるように、場づくりをするファシリテーター的な役割を担う。ときにはコーチとなってメンバーの相談に乗ったり、開発チームが抱えている問題を取り除いたりする。スクラムマスターは、スクラムチーム全体をマネジメントするが、コントロール型の管理を行うのではなく、チームを支援する役割を担う。そのために、開発チームを外部の割り込みから守り、チームの障害を取り除くために外部との交渉を行う。また、製品のビジョン作りやバックログ管理について、プロダクトオーナを支援する。つまり、スクラムマスターはスクラム全体をうまく回す責任を持つキーパーソンだと言える。

　スクラムマスターは、プロジェクト全体をマネジメントする仕事なのだが、指揮命令するものではない。むしろ、メンバーが動きやすいように障害物をどけて回る役回りで、サーバントリーダー(奉仕型のリーダー)だと言える。そして、開発のやり方に関する決定はスクラムマスターではなく、開発チームが行う。スクラムマスターが細かい指示を出すのではなく、自分たちで決めながら動く自律したチームを作ることが、生産性を上げる鍵だ。

　スクラムではこの自律したチームのことを、「自己組織化された」チームと呼ぶ。これには、スクラムチームを含む組織全体が「コマンドーコントロール」型の文化から、「リーダーシップーコラボレーション」型の文化へと意識改革していく必要もある。

・ユーザーストーリ

　「ユーザーストーリ」はXPで提唱されたプラクティスで、ユーザーの言葉で書かれた機能の説明である。そのものではないが、従来の「要求仕様書」を置き換えるものだ。このユーザーストーリはアナログを重視し、紙のカードに書いて会話によって伝えることが推奨されている。スクラムでは、バックログ項目に対して、このユーザーストーリを書くことになる。

　アジャイル開発では対話を重視している。ユーザーストーリは、従来の仕様書による情報伝達の欠点を補う手法として生まれた。従来の問題とはすなわち、完璧な仕様書で伝達しようとするあまり、どこまでも詳しく書くことになり、大きなドキュメントを抱えて「分析麻痺」に陥る問題だ。しかも、書き終えた頃には要求が変化してしまっている。そこで、できる限り簡潔にカードに要求を書き、残りはフェイス・トゥ・フェイスの話(ストーリ)で要求を伝える。カードに書かれた要求は完璧な仕様ではなく、あくまで「会話のきっかけ」として使う。

　書かれたカードは壁に貼っておくとよい。必要であればそのカードを壁からはがしてユーザーにもっていき、詳しい話をユーザーから聞き出す。例えば「このストーリですが最大の入力桁数はどれくらいを想定していますか？」とか「もし検索の結果がゼロの場合、どんな画面を出しましょうか？」と聞くのだ。

　簡潔に、とは言っても、なかなかちょうどよい要求を書くのは難しい。そこでユーザーストーリ記述のフォーマットがいくつか提案されている。その一つを紹介しよう。

　・＜〇〇＞として、(〇〇＝ユーザーの役割)

　・＜△△＞がほしい。(△△＝機能)

　・なぜなら、＜××＞だからだ。(××＝機能の価値や目的)

というものだ。例えば図書館の蔵書検索システムであれば、次のような書き方になる。

　図書館の訪問者として、蔵書を検索する機能がほしい。なぜなら、館内で見たり借りたりしたい本があるかどうか、そして、それがどこにあるかが知りたいからだ。

　ここで大切なのは、機能だけでなくこの機能を実際に使うユーザーの役割(例えばシステムによっては、ユーザーには一般ユーザーと管理者がいたりする)と価値や目的が書かれている点だ。ユーザーの役割が書かれていることによって、使う文脈を想像したりユーザーインターフェイスを考えたりできる。また、価値や目的が書かれていることによって、もしかしたら、書かれている機能そのものよりもよりスマートに、もしくはコストをかけずに目的を達成できる機能を思いつくかもしれない。さらに、この要約記述のほかに、制約や条件、ユーザーインターフェイスの絵、受け入れの基準やデモ手順などの記述が追加される。

・プラクティスには、技術的な課題に対するアプローチと、人間的なあるいは組織的(ソーシャル)な課題に対するアプローチがある。一概にプラクティスを分類することはできないが、これまでに紹介したものは大まかに二つに分類することができる。

　１，技術プラクティス：高速に石橋をたたいて渡る「開発環境」をつくるもの

　・リファクタリング

　・テスト駆動開発

　・継続的インテグレーション

　・ペアプログラミング

　・その他、これら以外にも多数

　２，ソーシャルプラクティス:協働でゴールに向かう「チーム環境」をつくるもの

　・朝会

　・タスクかんばん

　・バーンダウンチャート

　・プランニングポーカー

　・ふりかえり

　・その他、これら以外にも多数

一旦これくらいでしょうか？

図書館から借りた本なのですぐにまた参照することとかは難しいが、一旦エッセンスは書き出せたと思う。

そんなんで以上☆