アジャイル開発とは何か、まずは基礎を知ろう：製造業のためのアジャイル開発入門（1）（1/3 ページ）

複雑性／不確実性に対応するためソフトウェア開発業界で広く採用されている「アジャイル開発」の製造業での活用法を紹介する本連載。第1回は、アジャイル開発の定義や向いている領域、アジャイル開発の各手法を中心に、基礎から解説する。

[中村知成（クリエーションライン），MONOist]

　当初の計画通りに作っていればモノが売れていた昔と違い、社会やビジネスの複雑性／不確実性が高いこの時代においては、作るものを事前に完璧に把握することは困難です。そのため、ユーザーからのフィードバックや改善を少しずつ重ねながら進めていくプロセスや考え方の必要性が増しています。

　このような背景の中で、ソフトウェア開発業界では複雑性／不確実性に対応するための「アジャイル開発」が主流になってきています。このアジャイル開発は、製造業においても十分に活用できるはずです。

　本連載では、製造業におけるアジャイル開発の活用法について紹介します。第1回目の今回は、「アジャイル開発とは何か」を、その定義や向いている領域、アジャイル開発の各手法を中心に、基礎から解説します。

アジャイル開発とは

　アジャイル開発とは、コミュニケーションを基盤としながら変化に適応し、顧客に迅速に価値を届けることを重視するソフトウェア開発のことです。

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

　アジャイル開発の概念は、2001年に米国ユタ州のスノーバードに集まった技術者によってまとめられました。これは、「アジャイルソフトウェア開発宣言」として公開されています（図1）。また、4つの価値に基づく12の原則も併せて定義されています。

図1　アジャイルソフトウェア開発宣言［クリックで拡大］

　詳細は後述しますが、アジャイル開発の手法や方法論には、スクラム、XP、カンバンといった幾つかの手法が存在します。それらの手法では、個々に導入するプロセスやプラクティスは異なるものの、重きを置く価値は共通しています。その共通した価値を言語化したものが、アジャイルソフトウェア開発宣言です。

アジャイル開発が向いている領域

　アジャイル開発は、全ての問題を解決する銀の弾丸ではありません。適切な場面で活用することで、高い効果を発揮することができます。

問題領域の認知：クネビンフレームワーク

　どういった領域でアジャイル開発が有効かを判断する指針として、クネビンフレームワークを紹介します。クネビンフレームワークとは、問題領域を認知するためのフレームワークで、下記の5つの領域で構成されます（表1、図2）。

問題領域	状況の特徴	適切な行動
明白	誰が見ても明白な因果関係と適切な解がある	うまくやる方法をベストプラクティスとして利用する
煩雑	専門家が探せば因果関係は見つかり、複数の適切な解がある	専門家の分析に基づいて、対応を進める
複雑	事前に予測不可能で、適切な解はなく、方向性を示すようなパターンが出てくる	何らかのパターンが創発してくるよう、実験を繰り返す
混沌	混乱が渦巻いており、因果関係がはっきりしない	とにかく行動し、コマンドアンドコントロールによって秩序を回復する
混乱	4つの問題領域のどこに属するかが分からず、秩序が存在しない	4つの問題領域に分類し、各領域に応じた方法で意思決定を行う
表1　クネビンフレームワークを構成する5つの問題領域

図2　クネビンフレームワークのイメージ［クリックで拡大］

　アジャイル開発は、事前に予測不可能で、実験を繰り返しながら進める必要がある、複雑な領域にうまく適合します。冒頭で取り上げた、「作るモノを事前に把握することは難しいので、フィードバックを重ねながら対処する時代」とも合致しています。

　逆に言えば、試行錯誤が不要な単純、煩雑な領域では、アジャイル開発を無理に適用しなくても問題ありません。事前にきっちり計画／設計して進める、ウオーターフォール型開発の方が効率よく進められるでしょう。

2種類の不確実性：目的の不確実性／手段の不確実性

　上記で取り上げた複雑な領域を、もう少し詳しく見てみましょう。複雑な領域には、大きく以下の2点が不確実性として存在します。

• 目的の不確実性（Whatの不確実性）：何を作ればよいのか
• 手段の不確実性（Howの不確実性）：どのように作ればよいのか

　ここまでの例では、主に目的の不確実性について取り上げてきました。ただ、手段の不確実性も捨て置くことはできません。

　技術の目覚ましい進歩と高度化に伴って、プロジェクトの初期フェーズでは、どのように作ればよいかの知見を開発チームが備えていないこともあります。また、何を作ればよいかの部分が常に変わっていく状況では、作るものに応じて適切な手段も変わっていくかもしれません。

　つまり、何を作るかだけでなく、どのように作るかに対しても、試行錯誤をする中でチームとして知見を蓄積していく必要があるのです。