開発だけじゃない？ アジャイルで業務改革がはかどる理由：Mostly Harmless（1/2 ページ）

木曜日に指示を受けて、土日に休日返上で資料を作り、月曜日に最終版を持って行く――というのは、“ウオーターフォール的”な仕事の進め方です。それに対して、“イテレーション方式”で進めると、より効率的な結果が得られるはずです。

[大越章司，ITmedia]

この記事は大越章司氏のブログ「Mostly Harmless」より転載、編集しています。

　システムやソフトウェアの開発手法として注目を集めているアジャイル開発。その1つに「イテレーション」（iteration）があります。iterationは、「繰り返し」とか「反復」という意味であり、最小限の機能を持つMVP（Minimum Viable Product）を作って短いスパンで機能追加・改善を繰り返すことを指します。

　ここで大事なのは、イテレーションで作るものは「デモ」や「紙芝居」ではなく、「実際に動かせるもの」をリリースすることです。

　そうすることで、システムのエンドユーザーはプロジェクトの進捗や実際の機能を常に確認できるようになります。つまり、仕様のずれや間違いに気付きやすくなり、それに対する修正も早い段階で行えるため、開発の遅れにつながりにくくなるのです。同様に、最初に決めた要件が変化した場合でも柔軟に対応できます。

　ウオーターフォール開発では、開発の最後の段階でやっと全体が結合され、エンドユーザーに提示されるわけですが、そこで「あれ？　これは違うよ」という話になった場合、そこから修正するのは非常に大変です。さらに、最初に決めた要件というのは、開発が終了する数カ月とか数年後には変わってしまうケースが多いものです。むしろ、ビジネス環境が変わるのですから、要件も変わらない方がおかしいのかもしれません。ウオーターフォール開発の問題はここにあります（もちろんシステムの要件によってはウオーターフォールが向く場合もあります。アジャイルとどちらが優れているといった話ではなく、あくまで向き不向きの問題です）。

　ウオーターフォール開発とアジャイル開発の違いは、下記の図が分かりやすいでしょう。

「ウオーターフォール開発とアジャイル開発」（出典：ネットコマース）

　このイテレーションの考え方、開発だけでなく、一般の業務にも適用できそうです。

部長から頼まれた資料、どういった手順で作りますか？

　身近なことで考えてみましょう。木曜日に部長から呼ばれて、「こういう資料を月曜日までに作ってくれ。このデータを使って、こんなイメージで」と言われたとします。皆さんなら、このタスクをどのように進めますか？

　部長が口頭で説明したイメージは少し曖昧で、どのような着地点を目指したらよいのかが分かりません。考えているうちに、金曜日の夕方になってしまい、部長にも聞けなくなってしまいました。仕方がないので、言われたイメージを自分なりに膨らませて、土日に休日出勤して膨大な資料を作成し（筆者としては休日出勤を勧めるつもりはありませんが）、月曜日に持っていくと、「うーん。ちょっとイメージが違うなぁ」という反応。それから急いで直しても、結局半端な資料にしかならない……。こんな経験はありませんか？　せっかく土日も頑張ったのに……。