短納期・低コストのソフトウエア開発プロセスとして注目を集める「アジャイル型プロセス」。取り組みが広がる一方で，アジャイル独特の考え方に疑問を抱くエンジニアも多い。本講座の目的は，アジャイルの基礎から具体的な実践手法までを理解してもらうことにある。Part1ではアジャイル登場の背景や狙いを解説する。
「それは要件定義書に記載されていません」。
システム開発の現場で，よく発せられるフレーズである。筆者自身，これまで何度このフレーズをユーザーに対して言ってきたことだろう。
情報システム開発に仕様の追加・変更は付き物であり，変更を要求するユーザー側にも，それなりの理由がある。もちろん対応できるものもあるが，予算や納期を考えると到底実現は不可能と思える追加要求も少なくない。
あまりに要求が理不尽なときは，要件定義書を“逃げ道”にして，追加開発を断ることもある。しかし，たいていの場合は冒頭の言葉を発しつつ（あるいは心の中で唱えながら），仕方なく追加開発に応じる。結果，そのプロジェクトはデスマーチに突入していくことになる。
ソフトウエア開発者は本来，優れた機能を持つソフトを開発することに喜びを感じるものだ。ましてユーザーの要求するものであれば，予算や納期を度外視してでも何とかしたいと考えるのは，自然な感情である。
しかし当然のことながら，プロジェクトには期限もあり予算にも限りがあるため，ありとあらゆるユーザーの要望を聞き入れることはできない。心の底で，同様なジレンマを感じている読者は少なくないだろう。筆者自身，「決定事項を超えることを受け入れない」のが，優れたプロジェクト・マネジャーの条件の1つと考えていた時期があった。
ところが，数年前に「アジャイル型プロセス」を知り，この考えは大きく変わった。一言でいうとアジャイル型プロセスとは，要件の変更や追加を積極的に受け入れる開発プロセスである。すべてを受け入れることはもちろんできないが，そこにはユーザーとのコミュニケーションをベースとして，必要な機能を一緒に決めていこうとする「思想」が流れている。型にはまった無味乾燥なプロセスや取り決めに縛られるのではなく，開発者のモチベーションや相互のコミュニケーションを重視し，本当に必要なソフトウエアを短期間で，かつ柔軟に構築するための考え方を備えた開発プロセスなのだ。
一方でアジャイル型プロセスには，ウォーターフォール型に代表される従来の開発プロセスに慣れたITエンジニアにとって，とっつきにくい面があることも事実である。最大の特徴である「人間中心」という開発方針は，その最たる例だろう。
本講座では，いくつかの代表的なアジャイル型プロセスを取り上げ，その基本を解説するとともに，実際のプロジェクトでアジャイルを実践する際のポイントを明確にしたいと考えている。Part1では，開発プロセスの歴史をひもときながら，アジャイル型プロセスの背景や，アジャイル型プロセスの理解に欠かせない基本的な考え方を解説する。
「職人技」から「プロセス」へ
1960年代までのコンピュータの黎明期は，高度なプログラミングのスキルを備えた少数のITエンジニアの，いわゆる「職人技」に頼ってシステムを開発していた。当時のシステム開発では設計とプログラミング（テストを含む）という2つの作業だけしか事実上存在せず，しかも両者の区別は曖昧だった。システム開発で実施すべき作業の内容や各作業の実施手順，つまり開発プロセスと呼べるものはなかったのである。
しかし，開発するシステムの規模が大きくなり，実装する機能が複雑になると，この2つの作業工程だけではシステムを完成させることは困難となった。そこで製造業や建設業を手本として，「プロジェクト」で使われていた手法を実践するようになった。つまり，要件定義から始まり分析・設計・実装・テストと，滝が上から下へ流れるように開発を進める「ウォーターフォール型」の開発プロセスである（図1）。
言うまでもないが，ウォーターフォール型プロセスの特徴は，プロジェクトの開始当初に原則としてすべての要件を定義すること。そして開発工程を明確に分割し，それぞれの工程の出力（成果物）を次工程の入力とすることである。例えば要件定義フェーズの成果物である要件定義書は，次の外部設計フェーズでは作業の基になるドキュメントとして利用される。つまり，各フェーズで明確に定義された成果物を次フェーズの作業メンバーが参照する。これにより，属人的な側面を極力減らし，開発すべきシステムの品質を均一化しやすいという利点がある。
その一方で，ウォーターフォール型プロセスには問題点もあった。最も大きいのは，いったん上流工程で決まった仕様が変更されると，大幅な手戻りが発生することだ。システム開発プロジェクトの最初から仕様が明確になっていることは，実際にはまれである。ウォーターフォール型プロセスでは，実装やテストといった作業がプロジェクト終盤に集中しているため，設計ミスがあると手戻りのコストが大きくなりやすい。このほか，各フェーズで定められたドキュメントを作成したりメンテナンスするための手間が大きいことも，問題点の1つである。
