本記事の目的

アジャイル開発についての本[1]を読み終えたので、自身の備忘録として
アジャイル開発の概要などをまとめました。
具体的なアジャイル開発の手法などは次回に書きます。

誤り等ございましたら、ご指摘いただけますと幸いです。

アジャイル開発とは

短期間でソフトウェアの要件定義からリリースまで繰り返すような開発方法の総称です。また、このような開発方法に共通する考え方や哲学を示す言葉でもあります。

アジャイル開発のメリット

アジャイル開発は、ソフトウェアの重要度の高い機能から順に開発していき、短い期間で何度もリリースしては顧客からフィードバックをもらいます。これにより、より正確に顧客の要望が反映され、顧客に高い価値を素早く、そして変化にできるだけ柔軟に対応しながら提供することが可能になっています。

アジャイル開発の背景

アジャイル開発は、1990年代後半に従来行われていたプロセス重視の重い管理手法のアンチテーゼとして生まれました。
2001年に**「アジャイルソフトウェア開発宣言（アジャイルマニュフェスト）」**が発表されて以降、多くの人々に受け入れられ、”アジャイルソフトウェア開発” という言葉が定着しました。
アジャイルマニュフェストには、アジャイル開発におけるマインドセットが書かれていて、「アジャイル宣言の背後にある原則」とセットになっています。「アジャイル宣言の背後にある原則」は、アジャイルマニュフェストに書かれている4つの価値を実現するために、従うことが望ましい12個の原則を記したもので、こちらもアジャイルマニュフェストととも遵守していくべきものです。

アジャイルソフトウェア開発宣言（アジャイルマニュフェスト）

2001年2月にアメリカ合衆国のユタ州にて、様々なアジャイル開発手法を実践していた17名が、それぞれの手法の共通部分を見出すべく議論し、「アジャイルソフトウェア開発宣言（アジャイルマニュフェスト）」を発表しました。
「アジャイルソフトウェア開発宣言」には、アジャイル開発において大切な4つの価値が記されています。ここで注意するべきところは、左の価値も認めながらも、右の価値をより重視しているということです。

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

一つ目の「プロセスやツールよりも個人との対話を」では、
個人を何よりも尊重して、Face to Faceで対話をすることが最も効果的なコミュニケーションであり、より良いチームにするために重要であるということを述べています。

二つ目の「包括的なドキュメントよりも動くソフトウェアを」では、
実際にソフトウェアを動かして確認することで、正確で効率よく情報伝達ができるということを述べています。

三つ目の「契約交渉よりも顧客との協調を」では、
顧客と開発者が、お互いの立場を超えて協働することで、効率的により良い価値を顧客に届けることができると述べています。

四つ目の「計画に従うことよりも変化への対応を」では、
顧客の要求や環境などの変化に対応することで、顧客満足度を向上させることに繋がり、より良い価値を生み出すチャンスであると述べています。

また、「アジャイル宣言の背後にある原則」の詳細については、下記PDFが分かりやすかったので、こちらをご参照ください。
[2]IPA『アジャイル開発宣言の読み解き方』、2020

アジャイル開発の特徴

アジャイル開発には以下の9つの特徴があります。([1]による)

重要度の高い機能から優先的に開発する
短期間繰り返し開発、動くソフトウェアで顧客と確認
開発期間を固定する
反復型開発期間を固定するが開発項目は固定しない
開発対象の機能を1つの反復型開発期間内に収まるように分割
全ての作業をチケット管理する
顧客、チームメンバー間の直接対話
自動化ツールの高度の活用
ドキュメントの作成を最小限にする

重要度の高い機能から優先的に開発する

アジャイル開発では、システム全体の機能をユーザーストーリーと呼ばれる小機能に分割して、優先度をつけます。
ユーザーストーリーには、それぞれの機能についての要件を細かく明記する必要はなく、シンプルに、あくまでユーザー側の観点から記載されます。ユーザーストーリーのテンプレートは「<ユーザーの種類>として、<フィーチャ（機能や性能など）>が欲しい。それは<ビジネス価値>のためだ。」です。具体的に当てはめると、「本の購入者として、本の題名で本を探したい。それは探している本を見つけるためだ。」のようになります。
優先度は、顧客にとってのビジネス的価値に基づいて設定していき、優先度の高い順に開発(着手)します。優先度付け方法の一例ですが、機能と要求のマトリクスを作成し、要求に重み付けをすれば、機能ごとの優先ポイントを算出する事ができます。優先ポイントを元に優先度を決定することで、優先度の判断基準をより明確にする事ができます。

図2　機能の優先度付けの例
(図2では優先度の根拠となる優先ポイントを表示し、機能ごとの分類分けを行っています。あくまで一例なので、チーム内で一番良いと思われる手段で優先度付けを実施する事が一番です。)

アジャイル開発では、優先度の高い機能から開発する為、開発初期の段階から重要な機能を顧客に提供し、その妥当性を検証します。これにより重要な機能の欠陥などがあった場合にも、早めに気づくことができ、プロジェクト全体のリスクを低下させる事ができるのです。
また、優先度付けした後も、常に機能の必要性について議論が行われ、必要性の低い機能は後回しにされます。結果的に開発されない機能が存在することもあります。
使われない機能があったとしても、最終工程で全ての機能が提供されるウォーターフォール型開発に比べて、ROIの観点から、アジャイル開発は非常に有利であると言えます。

短期間繰り返し開発、動くソフトウェアで顧客と確認

アジャイル開発では、全体の機能を小機能(ユーザーストーリー)に分割して、短期間で繰り返し開発を行います。この反復型開発期間(イテレーション)ごとに、実際に動く機能を顧客に提供して、その妥当性を検証します。
機能の動作の妥当性をドキュメントのみで検証することは難しく、実際に動かしてみて確認する方が、より正確に分かりやすく顧客に伝えることができます。検証の際に、機能の不適当な箇所を指摘された場合には、次のイテレーションでこれを修正します。

開発期間を固定する

アジャイル開発では、まずイテレーションの期間を固定し、イテレーション内に最大限開発できるように開発対象を決めます。開発が予定とずれそうな場合には、イテレーションの期間の調整は行わず、開発対象の削減、または追加を行います。
期間が固定されたイテレーションを何度も繰り返すことで、チームが1度のイテレーション内にどの程度開発できるのか把握できるようになり、チームのリズム（ハートビートと言います）を作ることができます。チームの許容量を知ることで、それ以降の開発の見積もりをより正確にし、長期の開発計画が立てやすくします。
また、イテレーションの長さは、開発対象にもよりますが、一般に2週間程度とされます。

反復型開発期間を固定するが開発項目は固定しない

アジャイル開発では、開発内容がプロジェクトの途中で変更されることを歓迎します。
その為、開発項目は、開発途中で変更可能であり、変更に素早く対応します。環境の変化やイテレーション毎の機能検証の結果などにより顧客の要望が変わることは当たり前であり、この開発内容の変更要請に対応可能であることは、顧客にとって大きなメリットとなります。

開発対象の機能を1つの反復型開発期間内に収まるように分割

アジャイル開発では、全体の機能をユーザーストーリーに分け、優先度の高い順に各イテレーション内に収まるように割り振られます。ユーザーストーリーは、必ずユーザーから見える外部機能に基づいて分割され、以下6つの条件(INVEST)を満たすように気をつけます。

Independent：各々のストーリーが他のストーリーと独立している
Negitiable：実現手段が複数ある
Vakuable：顧客にとって価値がある
Estimable：見積もりが可能な程度に小さく明確である
Small：短期間に実現できる
Testable：テストができる（性能基準や機能が明確である）

その後、ユーザーストーリーをさらに細かく分けて作業管理対象(開発対象)とします。ユーザーストーリーや作業管理対象は後から変更される可能性をもつ為、プロジェクトの初めから全てのイテレーションのユーザーストーリｰを分割することはせず、実際に対象の機能を実装するイテレーションになってから、作業管理対象を明確にし、設計作業が行われます。

ウォーターフォール型の開発では、上流工程で全ての機能についての開発計画(設計書)を作りますが、アジャイル開発では、作業の進捗に沿って必要な計画が進められます。計画作成作業が時間軸上で分散されているイメージです。短期間で、設計だけではなく機能を実際に実装し動作させることが求められる為、非常に厳しく綿密な計画作業が要求されます。

全ての作業をチケット管理する

アジャイル開発では、どんなに軽微であっても、全ての作業をチケットで管理します。
チケットには、チケットID、作業内容概要(1行)、その他が記述されています。開発作業ではなく、調査作業でもチケットを割り当てるので注意が必要です。
あらゆる作業がIDを持つことで、IDをキーとした集計が、各イテレーションの作業全体の実態を表します。チケットの集計ツールなどは、チーム全体で共有し、各作業の進捗状況などをメンバー全員が把握でき流ようにします。

顧客、チームメンバー間の直接対話

アジャイル開発では、顧客も含めたチームのメンバー間の直接対話を非常に大切にします。極めて大切なことですが、対話を行う際には、なるべく「対立」を避け、相互に尊敬し信頼しあうことを念頭におきます。
また、効率的にコミュニケーションを行うために、必ずFace to Faceにて、定期的(毎朝、イテレーション毎など)、非定期的な短い会議を開催します。顧客こそが、真の要求仕様を知っているため、定期的な会議には、必ず顧客も参加するようにします。ただし、顧客は、「協調的で、権限を持っており、任されていて、知識を持っている」人物であるとします。
顧客との対話の中で、最も重要なのは、イテレーションの開始時と終了時の対話です。イテレーションの開始時には、そのイテレーションで開発する機能項目(ユーザーストーリー)の妥当性と、優先度について再度議論し、場合によってはユーザーストーリーを変更します。イテレーションの終了時には、その期間で開発したソフトウェアを動作させながら顧客がレビューを行います。
チームのメンバーは、必ず同じ部屋で仕事を行い、毎朝(または終業前)行われるデイリー会議で、毎日の進捗状況と、進捗上の課題を共有します。15分程度を目安に以下３点をチームの全員（顧客は含まない）が話します。この時、無駄な話は一切行わず、作業はIDで報告するようにします。

この24時間でやったこと
この24時間でやること
作業上の問題点

デイリー会議など定期的に行われる会議の他にも、必要であれば5分から10分程度の短い打ち合わせを臨時に開催します。メンバーは、打ち合わせの要請には気軽に応じる必要があります。

自動化ツールの高度の活用

アジャイル開発では、コーディング工程などで自動化ツールを使用することが当たり前となっています。
例えば、XP(代表的なアジャイル開発手法の一つ)では、コード分析・評価ツール、継続的インテグレーションCIツール、単体テスト支援ツールの活用を標準プロセスに組み込んでいます。
アジャイル開発では、製品の品質を保つために、単体テストが徹底して行われます。単体テストは、実装前に作成され、コードが変更される度に実行されることで、常にコードがテストをクリアしている状態であるか確認します(TDD)。
このような動作はCIツールを用いて自動化され、より効率的な開発を可能にするのです。

ドキュメントの作成を最小限にする

アジャイル開発では、動くソフトウェアを提供することに力を注ぎ、ドキュメントの作成、保守にかかる工数を最小限にする努力をします。ドキュメントを大量に作成するのではなく、コードのリファクタリングを繰り返して理解しやすいコードにしたり、TDDによりテストコードとプログラムをセットにしたりして、コードから直接ソフトウェアを理解しやすくします。
注意点としては、XPのように全くドキュメントを保持しないような手法もあれば、Agile ICONIXのように必要最低限のコンパクトなドキュメントであれば必要であると考える手法もあることです。

最後に

いかがでしたでしょうか。
想定より長くなってしまい、具体的なアジャイル手法(スクラムやSAFeなど)について記載できませんでした...
特に上流工程を含めた拡張アジャイル開発は非常に面白いので、また次回に書きたいと思います。

参考文献

本記事を書くにあたって下記文献を参考にしました。

[1] (著)片岡雅憲,小原由紀夫,光藤昭男 (編集) 日本プロジェクトマネジメント協会『アジャイル開発への道案内』近代科学社、2017
[2]IPA『アジャイル開発宣言の読み解き方』、2020