アジャイル｜短い反復で価値を届ける開発手法

アジャイル

アジャイルとは、短い反復周期で設計・実装・評価を繰り返し、利用者の反応を取り込みながら製品を少しずつ完成させていく開発の考え方である。英語のagileは「俊敏な」「機敏な」を意味する。主にソフトウェア開発の分野で広まったが、源流の一部は日本の製造業の製品開発にある。近年は機械設計や組込みシステムの開発にも使われるようになった。2001年に公開された「アジャイルソフトウェア開発宣言」によって、この言葉は世界中に定着した。

計画駆動型の開発への反省

1970年、米国のウィンストン・ロイスが論文で示した段階的な開発工程は、のちにウォーターフォールモデルと呼ばれるようになった。要件定義、設計、製造、試験と上流から下流へ順に進む方式で、工程の管理がしやすい。しかし1990年代に入ると市場の変化が速くなり、開発に1〜2年かかる大型案件では、完成した時点で要求が古くなっている例が目立つようになった。ロイス自身も、一方向だけに進む流れは危険であると論文の中で指摘し、工程を繰り返す必要性を説いていた。この点はあまり知られていない。

源流となった日本の製品開発

代表的な手法である「スクラム」の名前は、1986年に竹内弘高と野中郁次郎が『ハーバード・ビジネス・レビュー』に発表した論文「The New New Product Development Game」から来ている。二人は富士ゼロックス、キヤノン、ホンダなどの新製品開発を調べ、部門をまたいだチームが工程を重ねながら一体となって進む様子を、ラグビーのスクラムにたとえた。この論文をヒントに、ジェフ・サザーランドとケン・シュエイバーが1995年、ソフトウェア向けの手法としてスクラムを発表している。トヨタ生産方式やリーン生産方式にあるムダの排除や現場での改善といった考え方も、後の手法にはっきりと受け継がれた。

アジャイルソフトウェア開発宣言の4つの価値

2001年2月、米国ユタ州スノーバードのスキーリゾートに17人の技術者が集まり、当時「軽量開発手法」と呼ばれていた手法の共通点を1つの文書にまとめた。宣言は4つの価値と、それを支える12の原則でできている。「よりも」の前に置かれた項目にも価値はあると認めたうえで、後ろの項目をより大切にするという書き方になっている。

• プロセスやツールよりも個人と対話を
• 包括的なドキュメントよりも動くソフトウェアを
• 契約交渉よりも顧客との協調を
• 計画に従うことよりも変化への対応を

代表的な手法の比較

アジャイルは特定の手順の名前ではなく、複数の手法をまとめて呼ぶための言葉である。最も多く採用されているのはスクラムで、2020年11月に改訂された『スクラムガイド』では、チームを10人以下にすることが勧められている。開発者どうしは毎日15分以内の「デイリースクラム」で進み具合と障害を共有する。技術的な実践を重視するエクストリーム・プログラミングや、トヨタのかんばん方式をもとにしたカンバンも、よく知られた手法である。

ウォーターフォールとの考え方の違い

両者の違いは、何を固定するかにある。ウォーターフォールでは機能の範囲を先に決め、それに合わせて期間と費用を見積もる。これに対してアジャイルは、期間とチームの人数を先に決め、優先度の高い機能から順に作っていく。予定の期間が終わっても全機能がそろわない場合は、価値の低い機能を後回しにすることで調整する。どちらが優れているかという話ではない。要件がはっきり決まっている工事や基幹システムの更新では計画駆動型が向いており、要件が固まりにくい新サービスでは反復型が力を発揮する。プロジェクトマネジメントの知識体系であるPMBOKも、2021年の第7版で反復型の進め方を正式に取り込んだ。

ハードウェア開発と製造現場での使い方

物理的な部品を扱う開発では、作り直しのコストがソフトウェアよりはるかに大きい。たとえば射出成形用の金型は、製作に1〜3か月かかり、費用が数百万円に達することもある。スプリントのたびに作り直すことはできない。そこで実際の現場では、3Dプリンターや切削加工による試作で形状や組み付けの確認を2週間程度の周期で回し、量産用の型の手配だけは従来どおり設計審査（DR）を通す、という組み合わせの進め方がよく使われる。電気回路やファームウェアは反復を短くし、機構部品は長くするなど、部品ごとに周期を変えるのも実務上の工夫である。

アジャイル生産との関係

製造業には、開発手法とは別に「アジャイル生産（Agile Manufacturing）」という言葉がある。1991年、米国リーハイ大学のアイアコッカ研究所が報告書『21世紀製造企業戦略』で示した概念で、需要の変化に合わせて生産の品種や量をすばやく切り替える能力を指す。多品種少量生産への対応を目的としており、ソフトウェアの宣言より10年早く登場した。名前は似ているが、生まれた経緯は別である点に注意したい。

日本企業が導入でつまずきやすい点

日本の受託開発では、成果物の完成を約束する請負契約が多い。そのため、仕様が途中で変わることを前提とする進め方とは相性がよくない。情報処理推進機構（IPA）は2020年3月に「アジャイル開発版」のモデル契約を公開し、準委任契約を基本とする形を示した。社内の仕組みでは、出荷のたびに品質管理部門の承認を必要とする規程が、短い周期を妨げることが多い。テストの自動化や継続的インテグレーションの環境を整えずに周期だけを短くすると、手作業の確認が積み重なり、現場の負担がかえって増える。アジャイルを形だけでなく機能させるには、契約・承認・テストの3つを同時に見直す必要がある。