梗概
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディーな開発が求められています。その一方、何が正解（ゴール）なのかが分からない、という不確実性の時代でもあります。不確実性に対処するには「アジャイル開発」が最も有望ですが、その成功裏の実践には、従来の常識の解体と再構築が必要です。エンタープライズにおけるアジャイル開発の実践が待ったなしの状況の中、理論、課題、近年の動向も踏まえ、実例を交えながら幅広く解説します。
「文書を書かない」という誤解
本連載の第1回～第3回において、ウォーターフォール方式に変わる、新たな開発手法が発見され、それが1990年代後半～2000年代の「Linux」やスマートフォンの開発において極めて重要な役割を果たし、それが今日のアジャイル開発手法の原則として受け継がれてきていることを解説しました。今回から、アジャイル開発に関するよくある誤解を数回にわたって解いていきます。
筆者がお客さまのアジャイルトランスフォーメーションに長年携わる中で、恐らく最も多く尋ねられた質問は、文書（成果物）の作成に関するものです。「アジャイルって、設計書を書かずにいきなり作り始めるんでしょ？」という素朴なものから、「アジャイルで標準的に作成する成果物の一覧はないのか？」といった、ウォーターフォール方式との対比で捉えたものまで実にさまざまです。
まず、1つ目の「設計書を書かずにいきなり作る」に関しては、アジャイルの代表的なフレームワークの1つである「スクラム」に、その誤解の原因があるように思います。「スクラム」は、多くのチームで共通して用いられるアジャイル手法の代表的な優れたフレームワークです。一方で、フレームワーク内で実施すべきプラクティスについては、価値があり役に立つとチームが考えるものを自由に持ち込むべきであるとの考えから、詳細なガイダンスを意図的に提供しない軽量なフレームワークであり、一般的に図1に示すような絵で説明されます。
図1 スクラムのライフサイクル
図1を見ると、プロダクトバックログ（ユーザーストーリーと呼ばれる形式で表現される要求のリスト）から優先度の高いものを抽出し、1～4週間で作り、最後に関係者に対し、動くものをデモンストレーションして要求通りかどうかを確認し、かつ必要な軌道修正を行う、といったサイクルを反復的に繰り返していく、ということが分かります。
その一方で、「プロジェクトの全体構想はどのようなものなのだろう、開発するシステムはどのような基盤上で、どのようなアーキテクチャー構成をとり、プロダクトバックログは誰が、いつ、どうやって作るのだろう」、といったさまざまな疑問が湧いてくることでしょう。これらの情報は、実際にスプリントにおいて開発を始められる程度には整理、文書化され、関係者間で合意されている必要があるわけですが、スクラムでは、前述の理由から明確なガイダンスが示されていません。このことが、「文書を書かない」という誤解につながっているように思います。
図2 スクラムでの開発を始める前に整理されている必要がある情報
