Written by
on May 10, 2019

社内読書会でアジャイルサムライを読んだ

Tags:

アジャイルサムライという書籍を社内読書会で輪読したので、読んでみた感想を書きたいと思います。

実際に本を読んでみて、この書籍はアジャイルについて初めて学ぶ人がアジャイルの概要について理解するにはとても良い本だと思いました。アジャイルの概要だけではなく、実際のプロダクトで実践すべきプラクティスについても述べられています。この本を読むことでアジャイル開発についての全体像がつかめ、小さなプロジェクトでアジャイル開発を導入することができるレベルまで到達できると思います。

読み始めた当初

かくゆう私もこの本を読み始めた当初は、アジャイルについて全く理解していませんでした。アジャイルでソフトウェア開発もしたことがない全くの素人でした。当初の状態から、この本を通して、自分が所属するチームでアジャイル開発を実践するところまでいきました。実際に本に載っていた、プラクティスを実践することでよりアジャイルに対する理解が深まったと感じました。

アジャイル開発で重要なこと

この本で何度も強調されていた言葉があります。それが以下の２つです。

顧客と共にに開発を進めていくこと
毎週価値のあるものを顧客に提供すること

1つめに関してはアジャイル開発の最も大きな特徴であるとも言えます。アジャイル手法の一つであるスクラムでは、プロダクトオーナーという役割があります。プロダクトオーナーはプロジェクトチームと一緒に、プロダクトの要件を決めます。また、プロダクトの要件を決める最終決定権がプロダクトオーナーにあります。そしてこの役割を顧客サイドの人間が担当します。

ウォーターホール型の開発では要件定義や設計でプロダクトの仕様やスコープを決め、その仕様やスコープを顧客と共有し決定したら、そこから仕様が動くことはありません。

一方アジャイル開発では開発に顧客が参加し、一緒にイテレーションを進めながら仕様を柔軟に変更していきます。

アジャイル開発ではイテレーションの終了時に顧客に開発した成果物を動かしてもらい、即時にフィードバックを受けます。ここでのフィードバックはポジティブなものもあれば、想定していたものと違うといったネガティブなフィードバックもあり得るでしょう。しかしながら、この段階で顧客の要求を再認識し、次回以降のイテレーションで指摘された点を改善していくことでより顧客の要望にマッチしたソフトウェアを開発することができます。

このように顧客を開発チームに引き込むことで、顧客の要望に沿ったソフトウェアを開発することができます。

２つ目の毎週価値のあるものを顧客に提供することは文字通りイテレーションごとに動くソフトウェアを顧客に提供するということです。これがアジャイル（俊敏な）という名前にも繋がっています。

アジャイル開発のプラクティス

インセプションデッキ

インセプションデッキはプロジェクト開発前に、顧客とプロジェクトチームで集まりプロジェクトに対する認識を合わせていく場です。具体的には以下のような質問に対して、議論しながら答えていき、最終的にスライドや文書としてまとめます。

インセプションデッキでの質問

我々はなぜここにいるのか
エレベーターピッチを作成する
パッケージデザインを作成する
やらないことリストを作る
「ご近所さん」を探せ
解決案をかく
夜も眠れなくなるような問題は何か
期間を見極める
トレードオフスライダー
何がどれだけ必要か

詳細についつては述べませんが、ネット上にたくさんの例があるので参照してみてください。

インセプションデッキは実際に社内のチームでも実践しています。上記の様な質問に答えていく過程で、意外とメンバー1人1人の考えていることが違うなということに気づきます。多くのことをチームメンバーで議論することによって、プロジェクトの意義や目的がクリアになります。また、個人的にはスライドや文書に残すということがとても重要だと思います。実際に、プロジェクトを進めていき、メンバー同士で意見が割れたりするときに、インセプションデッキに立ちかえることで意外とスムーズに意見がまとまったという経験もあります。

アジャイルな見積もりとイテレーション

アジャイルではストーリーという単位でタスクを切り出し、イテレーションという単位でタスクを実行していきます。

ストーリーとはソフトウェアの振る舞いをユーザー目線で記述したものです。

例

ユーザーは自分のユーザーidとパスワードでログインできる

ストーリーの集合がスクラムで言うところのプロダクトバックログになります。

ストーリーに対して、ストーリーポイントというものを割り当てます。このストーリーポイントは絶対的な指標ではなく、ストーリー同士を比較することによってポイント化する相対的な指標です。

ます基準となるストーリーを決めます。

例

ストーリーaにストーリーポイントを3割り当てる。

ストーリーbはストーリーaよりビジネスロジックの数が少いので簡単そう。→　ストーリーbにストーリーポイント1を割り当てる。（ストーリポイントには1,3,5,8,13のようなフィボナッチ数列の数を割り当てると良いとよく言われています。）ストーリーポイントやストーリーポイントの割り当て方に関しては「アジャイルな見積もりと計画づくり」という本がとても分かりやすかったです。また、私たちのチームではストーリーポイントを決める際にプランニングポーカーを実践しています。こちらについても「アジャイルな見積もりと計画作り」で述べられているので参照してみてください。

イテレーションは通常2~4週間の開発期間です。イテレーションの期間はプロジェクト開始時に1度定めたら、変更はしません。イテレーションの期間を2週間と定めたら、ずっと2週間になります。

イテレーションを終了するごとに完了できたストーリーのストーリーポイントの合計を求めます。これがベロシティと呼ばれるものになります。

プロジェクトの平均ベロシティと残りのプロダクトバックログのストーリーポイントの合計から、あとどれくらいの期間でプロジェクトが終了するのかを計算することができます。

まとめ

疲れたのでまとめます。この書籍は本当に簡単に読める本なので、アジャイルに興味のある人はぜひ読んでみると良いと思います。