ソフトウェア開発において、アジャイル開発は王道（というかソフトウェア以外ではしたくても出来なかった手法）だと理解しています。 その手法について良くまとめられていると評判だった本書を読んで、個人的なポイントをメモしてみました。

概要

一番大切なことは、常に顧客に価値をもたらすこと。つまりは定期的（一週間毎くらい）に、動く（テスト済みの）ソフトウェアを提供すること。 仕様書や計画書はその補完にしか過ぎない。実際にメリットを提供できて初めて責任を果たしたと言える。

そのために以下を心がける。

• 大きな問題、ストーリーは小さく分割する。
  • 大きすぎると期間・仕様が見積もれない。いざ完成してからズレていたと発覚しては遅い。
• 本当にメリットのあるもののみに注力し、他は忘れる。
  • システムのうち、お客様にメリットを提供している機能はごく一部だから。
• 常に動く状態にする。
  • いつでもテスト可能なようにすることで、仕様を満たしていることを保証する。
• フィードバック、実挙動の確認を求める。
  • 仕様を知っていてお金を出すのはお客様なのだから。
• 必要とあれば方針を変える
  • 定期的に（イテレーション毎に）顧客と話して機能の優先度、仕様を確認する。なぜなら、仕様もスケジュールも常に流動するから。
• 説明責任を果たす。
  • 毎週成果を求められ、また顧客と共に次の計画を考えるため、全てを説明して納得してもらわなければならない。

しかし、ウォーターフォール型で最後に神頼みをするよりマシかもしれない。

なぜagileか。Agileとは何か

Agileとは、ウォーターフォールと比較して、最初に要件を固めすぎずに都度対応していく方法のこと。 これによって、

• 早いうちからユーザーにシステムを使ってもらうことで価値を提供できる。
• 着実に目に見える形で進捗を重ねることができる。
• 急なスケジュール・仕様変更に強くなる。

特に最後の部分で、ソフトウェア開発においては以下の経験則が成り立つことを前提としている。

• プロジェクトの開始時点に全ての要求をヒアリングできない。
• 要求は必ず後で変更される。
• 納期や資金に比べて、やるべきことは常に多すぎる

ただ、これはハードウェアの世界でもおそらく起きているものの、顧客側が仕方ないと理解しているため問題とならないのではと個人的に推測する。

登場人物

要件は誰が決める？

ソフトウェアの要件とは、どんな価値を提供するかに当たる。つまりは顧客（あるいはそのドメインの専門家）しか知ることはない。 どの機能がどのくらいの優先度で必要なのか、もしQCD全てをこなすことが難しければ、どの部分で妥協できるのか、などを決める。 ということは、ソフトウェア開発においては顧客も積極的に参加しなくてはいけない。常に要件を発言し、システムのフィードバックを行うことが必要だ。

もしこれらの作業を引き受けてくれる人がいない場合は、まだそのプロジェクト自体の優先度が高くないのかもしれない。他の事に目を向けよう。

誰が作る？

開発チームは、テスター、プログラマ、デザイナ、アナリストなどの全ての役割を誰かが担うことになる。 それぞれの役割は明確に区切られているものではないため、スピードを求めると同じ人が複数の責務を担うことが重要になる。要するに、ある程度の専門性を持ちつつ、必要に応じて他の分野の作業も担えるゼネラリストが求められる。

代表的な役割を順番に見ていく。

アナリスト

顧客と開発チームの橋渡しを行う。

• 顧客の要求をヒアリングしてシステムの要件に落としこむ。
• 優先度を定義する。
• システムの完了を確認するためのシナリオを用意する。

などを担う。

プログラマ

• 要件のコストを見積もる。
• 要件を機械語に翻訳する。
• 技術選定を行う。
• 実装のゴールを定義するテストを作成する。

テスター

• 非機能要件（性能、セキュリティ、コスト）のテスト設計を行う。
• テスト作成を手伝う。
• テストを自動化し常に回せるようにする。

プロジェクトマネージャ

• プロジェクトの様子（進捗・タスク）を確認し共有する。
• プロジェクトの環境を整える（開発環境・工数確保）

デザイナ

• よりユーザーが使いやすいUIを考案、実装する。
• ユーザーのニーズを深堀りしてシステムに落としこむ。

ステークホルダーは他も居る

組織の中でプロジェクトを行っている場合、利害関係者はプロジェクトメンバーだけでない。品質管理の部門やセキュリティ、インフラ部門なども関わるかもしれない。 メンバーだけで突き進むのではなく、彼らのことも気に留めて、時には情報共有をしておく必要がある。

プロジェクトの進め方

目指す方向を共有する

インセプションデッキと呼ばれるツールを使った例を挙げる。

チームの目的は何か？

まずはチームとして集まった目的、作るシステムの概要を確認する。このとき、2,3センテンスでまとめられるレベルまで落としこみ、かつそれが魅力的（顧客がお金を払ってでも欲しがる）であるかどうかを確認する。 もしそこまで落とし込めなければプロジェクトを止めることも有り。

何をやらないか？

プロジェクトメンバー、お客様への情報共有としてわかりやすい例。これによって、本当にフォーカスする問題が浮かび上がる。 ただし、まだどうするか決まってないことはやらないことではなく未定とする。

期間・予算はどのくらいか？実現可能なラインか？

大まかな要求が決まったら、実現プランを考えていく。（例えばWebアプリを作るとか、データベースはこんな感じにするとか） ここでは具体的なものではなく、チームや顧客への大まかな道筋の共有ができれば良い。どうせ後で要求も実装も変わってくるから。

また、プロジェクトを進める前に考えられるリスクを先に洗い出しておき、大まかな対策を考える。ここで案を考えておくことで、プロジェクトがひっくり返るリスクを減らしておくことに繋がる。（リスクの起こる確率が大きく、かつ対応不可能であれば、それはプロジェクト自体の筋が悪いのかもしれない。） もちろん、天災などどうしようもないものは考えるだけ無駄だけど。

そうしてプロジェクトを進めても問題なさそうと推測できるようになったら、最後に大まかにスケジュールとコスト感を見積もる。これはコミットではないが、顧客にとって必要な情報だからだ。 このとき、プロジェクトの規模が大きすぎるときは最長半年くらいで小ゴールを引いておく。そうしないと見積りできなり、顧客もGoの判断を下すことのリスクが大きすぎるから。

何を妥協できるか？

往々にしてプロジェクトはスケジュールよりも悪い方向にズレる。 その時になってから妥協案を考えると、顧客に不快感を与えてしまったり、急なことで決断が出来なくなる恐れがある。 そこで事前に妥協できるポイントを聞いておく。

フィーチャのいくつかを削るとか、期日を延ばすとかが典型的な例。 なぜなら、

• 予算は調整が難しく、またソフトウェアにおいてはお金は万能ではないから。
• 品質は、下げたからといって機能が追加できるものではなく、むしろお互いに余計な時間を取られることに繋がりかねないから。

計画を立てる

まず、計画と実装プランは異なる。最初に大まかな見積もりと優先度でもってイテレーションの計画を立て、その時期が来てから詳細設計と実装案を考える。最初に詳細設計までしない理由は、後で変更される可能性が高いため。

何度も記述されているが、大事なことは「要求は顧客が知っているので、もっと対話を増やすこと」。それによって計画すべきシナリオが明確になる。

ユーザーストーリーを聞く

ここでは顧客がシステムに求める機能を簡単にまとめる。これによって、工数の概算やスケジュール感、顧客の要求が共有される。 詳細な仕様や実装案は時期が来たら再度検討するので、ここではキーワードを書き留めて置くことが重要。（技術寄りの実装案などはここでは考えなくて良い。早すぎる最適化になるから。） もちろん、何が達成できればそのストーリーの実装を終えたと判断できるか、といった大まかなゴールも必要になる。

さらに、ここではなるべく粒度を細かくして互いのストーリーを独立させておくことで、作業がしやすくなり、見積もりも正確になる。

時には仕方なく大きい粒度のストーリーになることもあるが、それは計画段階では大きくしておいて、 実装に落としこむ際に複数に分かれることになる。

プロジェクト開始の判断をする

繰り返すが、プロジェクト開始時には、顧客は要求が定まっていないし、開発者もどの技術を使うのかが定まっていない。 またプロジェクトに割ける工数やコストも変化したり、ビジネス環境が変わってプロジェクト自体の見直しを迫られるかもしれない。 上記の情報が一切変動しないような特殊な状態でない限り、初期時に性格な見積もりをすることはできない。（逆に決まってたら、エンジニアは一切頭を使わないコーディングマシンとして働かされることになるだろう。） まずはそこを自覚した上で、ざっくり「与えられた期間・コスト内に、必要最低限のシステム構築ができそうか？」だけチェックする。 決して多くをコミットしてはいけない。それは論理的に算出した数値ではなく希望的観測だから。

実装するストーリーの重み付けをする。

「工数」のような絶対的指標で見積もることは止めたほうがいい。そもそも出来ないし、人によって作業スピードが違うため。 そうではなく、相対的に「この作業はこの作業と同じくらい大変」「この作業ははるかに難しい」などのざっくりした区別をする。

実際に作業をしてPDCAを回す。

実際にストーリーの実装（システム開発）を行っていく。 ここでは小さくイテレーションを切って作業し、都度振り返って進捗を確認する。 イテレーションは１週間〜３週間が目安で、理由としては

• 作業が小さい粒度になっているため細かすぎることはない
• 早めに顧客に見せてFBをもらうことで、期待値コントロールや、問題があった場合の即座の改善ができる。
• 進捗を確認することで、スケジュール変更が必要な場合に早めに気づくことが出来る。

トラブル発生時には

スケジュールが間に合わなさそう

イテレーションを重ね、チームの開発速度がわかったところで残タスクをみると明らかに間に合わなくなることが往々にして起きる。原因は

• 予想より速度が遅かった
• チームメンバーが抜けた。
• 顧客の要望が変わった、増えた。

こういった場合は、顧客に正直に伝え、期限を延ばすか機能を一部削いでもらうことで対応する他ない。

まとめ

アジャイルな開発は今のソフトウェアが複雑化した次代に必須なんだろうけど、それをするには技術やアジャイルな開発に抵抗のない顧客が居ることが大前提だなと思った。 （わかってない人が顧客だと、無理なスケジュールを押し付けてきたり、計画変更を拒絶したりしそう。そのくせ要求をきちんと伝えてくれなくて後から揉めそう。）