プログラム作成の４つの段階：トップダウンか反復か、それとも…

はじめに

「プログラムの作成」というだけでは、なんだか漠然としていますね。そこで、プログラム作成という行為がどのような段階からできているかを、ここでは考えたいと思います。

たとえば私たちの今日の夕ご飯は、だいたい以下のようなステップで作られているはずですね？

1. 今冷蔵庫にあるものを考慮しつつ、今日食べたいものを考える
2. 今日の献立を立てる
3. 足りない食材を買ってきて、調理する（レンジでチン、も含みます）
4. 実際に食べてみて味を確かめる

企業における新規事業も、似たようなステップを踏んでいると思います(*)。

1. マーケティングを踏まえて、世の中が必要としているものを明らかにする
2. ビジネスモデルを立てて、具体的なリソース（人・もの・カネ）の流れを計画する
3. 実際にリソースを集めて事業として立ち上げる
4. 事業を運営して、損益を確かめる

ではプログラムはどうでしょう？プログラムも同じように、必ず（意識的に、かはともかくとして）以下の４つのステップを経て作られています（図1.1）。

1. 要求分析：プログラムに必要な機能を明確にする
2. 設計：どのような方法で実現するか具体化する
3. 実装：コードを書く
4. テスト：思った通りに動くかどうか確かめる

最初の方ほど抽象的・包括的かつプラットフォーム非依存的、後になるほど具体的・個別事例的・プラットフォーム依存的な段階になることがわかると思います。

 

図1.1 プログラム作成の４つの段階

ここで注意してほしいのは「この４つの段階を必ずしもこの順番でしなくてよい」ということです。もちろん、例えば要求分析・設計なしに実装をするのは無謀だと言えますが、逆に実装の途中で思い立って要求分析と設計をやり直す、ということも原理上は可能です。ただ夕ご飯やビジネスの場合と同様、何かを「やり直す」のには様々なコストがともなってしまい、最悪今までしてきたこと全てが無駄になることもあります。

ではどうしたらよいのでしょう？ここでは、今までのソフトウェア開発の歴史で認められてきた二つの代表例、「ウォーターフォール型」と「逐次型」の開発手法を紹介します。

 

---

(*) 実のところ、夕ご飯とビジネス、そしてプログラミングが似ているのは決して偶然ではありません。この４つのステップはもともと工学的な生産プロセスの考え方をプログラム作成に応用したものです。ビジネスの考え方も多分に工学の影響を受けていることを考えれば、この一致は不思議ではありません。夕ご飯はそもそもが生産プロセスなので、同様のプロセスを辿ったほうが生産的だと考えられます。

 

ウォーターフォール型開発

最も有名なのが「ウォーターフォール（落水）型」と呼ばれる開発法です（図1.2）。川の水がいくつかの滝を経て川下に流れて行くように、さかのぼることなく「要求分析」「設計」「実装」「テスト」という順番で行なわれていくことから、そう呼ばれます。

図1.2 ウォーターフォール型開発のモデル

この方法の一番の特徴でありメリットであるのは、個々のステップで「完璧に仕上げる」ことを要請している点です。その結果、（少なくとも理論上は）いったん要求分析や設計が終わってしまえば、それらのステップだけに関わっていた人員をプロジェクトから引き揚げさせることが可能になり、より効率的な人員・プロジェクトの管理が可能になると考えられます。その意味で、大きなプロジェクトでは広く使われる管理手法です。

もちろん「完璧に仕上げる」というのはほぼ不可能なことで、そこがこのモデルの弱点です。予定の遅れに対しても、あまり柔軟な運用は期待できません。例えば要求分析班が、予定期間では計画の３分の２しか要求を定義できなかったとします。すると設計班は３分の２の要求からプログラムの仕様を策定しなければならなくなり、こちらも遅れ気味になります。最悪の場合、実装班が実装を始めた段階で、まだ要求分析班が要求の定義を終えられていない、という状況も起こります。そうなると状況は混沌と化し、いわゆるデスマーチへと坂を転げ落ちて行くこともあります。予定外のことに対応するには、予めリソースに余裕を持たせて計画しなければならないでしょう。

 

逐次型開発

ウォーターフォール型開発に対する批判・反省の過程で脚光を浴びたのが、逐次型開発と呼ばれる手法です（図3）。この開発手法のポイントは図で示されているように、以下のような事柄です。

• プログラムの作成プロセスを、複数の「要求分析 → 設計 → 実装 → テスト」というサブプロセスに分解する（このサブプロセスのことを「イテレーション」と呼びます）。
• 個々のイテレーションを順番に終わらせていき、その都度「動くプログラム」として仕上げる。
• イテレーションごとにフィードバックを（ユーザから）得て、次のイテレーションに活かす。

 

図1.3 逐次型開発のモデル

ひとつめのメリットとして、イテレーションごとに段階的に「動くプログラム」が出来上がるので、ウォーターフォール型に比べて設計上のミス等に気づきやすいということが挙げられます。またユーザからもプログラムを動かした感想を随時得られるので、ユーザの要求に沿ったものを開発できる可能性が高まりそうです。まとめると、逐次型はウォーターフォール型に比べてより柔軟に目的のプログラムを作っていける、という特徴があります。

これだけ書くと「逐次型万歳！ウォーターフォール型は過去の遺物」のようにとれるかもしれませんが、逐次型にはそれなりの限界が存在します。その大きなものが、プロジェクトのサイズです。まず逐次型の場合、個々の開発段階に携わる人はイテレーションごとに繰り返し駆り出されます。人員を単一のプロジェクトにのみ集中させる場合、実装の期間中は要求開発班は「遊んで」しまうことになります。一方複数のプロジェクトを同時進行させる場合、プロジェクトを切り替えるたびに頭の中も切り替える必要がでてきてしまい、生産性も正確性も低下する危険があるのです。これとは違う方法として「個々の人間がどの段階にも携わる」というアプローチも取り得ますが、今度は関わる人員が増えれば増えるほどにコミュニケーションが煩雑になり、まとまったプログラムを作りづらくなってしまうのです。これらの事情から逐次型開発をおこなう組織は、個々のプログラマの能力が揃った小規模（1~20人程度）のチームであることが多いかもしれません。

 

折衷案

ここまでで、ウォーターフォール型は柔軟性に乏しいが大規模プロジェクトに使いやすいこと、逐次型は小規模プロジェクトに親和性が高いが柔軟性が高いこと、それぞれを見てきました。もちろんこれらのよいところを活かそうとする折衷案というものも存在します。

逐次型で問題になった「人員が遊んでしまう」という点については、各イテレーションを「重ねて」いくことで対応することがあります。たとえば要求分析班は、最初のイテレーションまでの要求分析を完了させて設計班に渡した後、すぐさま次のイテレーションの作業にとりかかるのです。ちょうど歌の輪唱のように、それぞれの開発ステップが１イテレーション遅れで前のステップについていく、というイメージです。このようにすることで、人員を遊ばせることなく柔軟に開発が進む可能性があります（同時にイテレーションの管理が非常に重要になってしまいます：誰かが遅れてしまったり、最初のステップの人が大きな間違いをしてしまうことに対して、このモデルはかなり脆弱です）。

このように、ウォーターフォール型や逐次型の開発モデルはあくまで参考モデルです。作りたいものの規模などに応じて、開発の方針を立てるのが理想だと思います。

まとめ

プログラム作成のプロセスを、要求分析・設計・実装・テストの４つの段階に分けました。

またこの４段階を組み合わせるための代表的な枠組みとして、「ウォーターフォール型」および「逐次型」の開発モデルを取り上げました。

ウォーターフォール型の場合は「リソースの的確で集中的な活用」が、逐次型の場合は「ユーザの要求に対する的確で段階的な対応」が、それぞれメリットとして挙げられます。実際のプログラム作成では、二つの（極端な）モデル両方のメリットをよく意識することが重要でしょう。