ソフトウェア開発において、1970年代より現代に至るまでその中心を担ってきたものが
Waterfall Modelと呼ばれる開発手法である。Waterfall Modelは今日の日本のソフトウェア
開発でも主流の開発手法として多くのプロジェクトで採用されており、多くの貢献をして きた。特にWaterfall Modelは、次章で検討するかつて日本のソフトウェア開発で中心的存 在を果たしたソフトウェア・ファクトリーと呼ばれる工場型の開発モデルのような開発方 法やその分業構造と親和性が高かった。
一方で、このWaterfall Modelは、今日必要とされる質の高い、革新的なソフトウェアの 開発を行うには限界があり、海外ではこの Waterfall Model に代わる方法として登場した
Agileが開発手法の主流になりつつある。
本章では、ソフトウェア開発の分業構造やその知識労働について検討する前提として、
これらソフトウェアの開発プロセスに関する整理と比較を行う。未だ日本の多くの企業で
Waterfall Modelが採用されている要因について、さらにこうしたWaterfall ModelがAgile
へと取って代わられつつある要因について、その開発プロセスの特徴と限界がいかなると ころに見られるのか検討する。
(1) ソフトウェアの開発プロセス
① 基本的な開発プロセス
Waterfall Model とAgileといった開発手法について検討する前提として、ソフトウェア
の基本的な開発プロセスを確認する。ソフトウェアの開発プロセスは、当初は個人の作業 スタイルで行われていたものの、品質管理などの点から製造業のような工程ごとに分離し、
その工程を順番にこなしていく方法が定着している（表 5-1）。 このソフトウェア開発プロセスの詳細は次のとおりである。
・提案依頼、見積もり
開発プロセスに入る前に、開発の元請けとなる企業の選定のため、コンペティションが 行われる。ユーザー企業から提示された提案依頼書72を元に、コンペティションに参加す るITベンダーはシステム設計のための提案書や見積書などを作成する。このコンペティシ ョンの結果、ユーザー企業とITベンダーの間でシステム開発などの契約が締結され、以降 の開発プロセスへと着手することになる。
72 Request For Proposal。RFPと略されることが多い。発注企業が、ITベンダーに対して、
業務委託や情報システムの導入の際、具体的な提案を依頼するドキュメント。
表 5-1 ソフトウェア開発の標準的なプロセスと職種の作業範囲 プロセス Systems
Engineer
Program mer73
作業人数の
目安74 大まかな作業分類・概要
見積もり 管理・作業 少(1～3 人)
業務の現状や問題点の洗い出し開発の全 体の規模を決める
分析 管理・作業 少(1～3 人)
要件定義 管理・作業 ※ 少(1～3 人) 基本的な事項を決定。システム、プログ ラム、データの構成と仕様などを決める
（定義する）
基本設計 管理・作業 ※ 少(1～3 人)
詳細設計 管理・作業 作業 多(7～10 人)
プログラムの詳細（動作や処理の流れ）
を決定し、作成する プログラム作成 管理 作業 多(7～10 人)
単体テスト 管理 作業 多(7～10 人) できあがったプログラムを動かし、1 つの ソフトウェア・システムとして設計や要 件に合致すること（仕様を満たしている こと）を確認する
結合テスト 管理 作業 中(3～6 人)
システムテスト 管理・作業 ※ 中(3～6 人)
本番移行 管理・作業 少(1～3 人) システムを本番稼働させる（旧システム との切り替えなど）。
稼働後の日々のメンテナンス 運用・保守 管理・作業 少(1～3 人)
出所：筆者作成
73 便宜上、システムエンジニアとプログラマーの職務担当を分けているが、開発プロジェ クトによって、作業範囲は異なる。実際には、プログラマーも要件定義やシステムテスト などに従事する場合もあり（表中の※）、システムエンジニアとプログラマーの職務上の 定義は曖昧である。
さらに、プログラマーに対し、プログラム作成専門のコーダーや、テスト工程を担当す る作業者であるテスター、ゲームソフトウェアでさまざまな操作などを行いプログラムの バグを発見する作業者であるデバッカーなども存在する。中でもコーダーはプログラマー とは異なり、コーディング、つまりプログラム作成作業として設計書通りのプログラムを 記述するような作業者を指すことが多い。ただし、日本ではプログラマーとコーダーの違 いは明確ではなく、また、その定義も企業、プロジェクト、研究者で異なっている。
74 表では例として10人程度のチームの人数を示している。開発に関わる作業人数はソフ トウェア開発の規模によって増減するが、基本設計までの作業人数は少なく、プログラム 作成とそのテスト工程で一番人数が多くなり、その後、徐々に減少していく傾向にある。
例えば、10人程度でチームを組む開発プロジェクトの場合、おおよそ少=1~3人、中=3~6 人、多=7~10人程度で構成され、より大きなプロジェクトの場合、少=2~4人、中=5~8人、
多=8~20人といった具合で構成されることになる。
また、提案依頼書を作成するベンダーを選出するコンペティション自体が行われる場合 もある。官公庁による発注では、企業の売上や営業年数、自己資本、流動比率などの外形 的要素によりランク付けを行い、予定価格の大小に応じて入札への参加資格を分類してお り、これら外形的要素に弱い中小企業は参入しにくい場合もある。
・分析
「分析」は、「システム分析」とも呼ばれ、ソフトウェア開発に着手するための事前の調 査、分析作業であり、ソフトウェアの現状や問題点を洗い出す基礎となる。ユーザー企業 のシステムへの要望は、不完全で曖昧であり、かつ矛盾している部分が多く存在し、実際 の業務に適していない要望が含まれている場合もある。そのため、まずはシステムの現状 を把握、分析していくことが重要となる。
・要件定義
「要件定義」は、分析結果を基に、実際の業務と照らし合わせ、具体的にどのようなソ フトウェアを作成するのかを決める重要なプロセスであり、ここでソフトウェア開発プロ ジェクトの成否を左右する諸要因が決まるといっても過言ではない（萩森, 2007; 中尾, 2009）。
ユーザーの要望は不完全で曖昧なだけでなく、広大で多岐に渡る。しかし、その要望の すべてをソフトウェアとして実装するには、莫大な予算や数年単位に及ぶ開発期間が必要 となり、現実的には不可能なことが多い。特にビジネスのスピードが上がるにつれて、ソ フトウェアの開発スピードも求められており、不要な要望や機能を削ぎ落として、適度な 期間でシステムを作り上げることが重要視されてきている。そこで、要件定義として業務 フローの精査やユーザーヒアリングなどを通じて、どのような機能が必要で何が不必要か を選定していく。この選定を失敗してしまうと、要求に満たないソフトウェアや、想定外 のソフトウェアができあがってしまうのである。
このようにユーザー要件は曖昧なため、後の工程で要件の変更や追加が発生することが 多く、納期が遅延する原因となる。曖昧な条件の中、少しでも正確な見積もりや要件定義 を行うには、先のリスクを予見できるような経験が重要であり、くわえて、業務に精通し ていることも必要となる。
・設計
「設計」は、要件定義で確定した内容を仕様書や設計書に落とし込む工程である。次の プログラム作成工程のために、ここで可能な限り詳細な開発内容を決定する必要がある。
例えば、Webサイトの開発であれば、どのような画面を表示するのか、どのように画面の 遷移や処理を行い、どういったデータや帳票ができあがるようにするのか、といった具体
的な仕組みに関してこの工程で決定する。
このとき、次のプログラム作成工程を海外へアウトソーシングするような場合には、設 計書も英語などアウトソーシング先に合わせた言語で作成する必要があり、外国人技術者 が理解できるレベルまで詳細に作成する必要がある。しかし、外国人技術者は日本特有の 仕様や商業慣習までは理解できない。そのため、設計書が日本人であれば理解できるよう な曖昧な部分を残していると、誤りや齟齬を生じさせ、プログラムの不具合を招き、ひい てはソフトウェア全体の品質が低下してしまう原因となる。
また、こうした設計書は必ず作成されるとは限らず、簡易なものや概要程度でまとめら れたものしか作成されていなかったり、過去に作られたが最新のソフトウェアの情報に更 新されていなかったりなど、不十分なことが多く、次工程のプログラム作成を難しくする 要因の一つとなっている。
・プログラム作成
「プログラム作成」は、設計書を元に実際にシステムを開発、構築する工程である。「製 造」や「実装」、「開発」とも呼ばれ、プログラムのソースコードを作成していく。このプ ログラムをコーディング75する作業者はプログラマーと呼ばれ、その専門性のため、非常 に難解で、かつ複雑で高度な作業であると捉えられることが多い76。
しかしながら、日本の大半のソフトウェア開発の現場においては、このプログラム作成 作業は、要件定義や設計で定められた仕様書や設計書に基づいてプログラムを記述するこ とが目的とされ、ソフトウェア開発における工程のうちそれほど重要なものではないとさ れている。そのため、プログラム作成工程は、設計書を元にコーディングするだけの単純 作業や軽度の作業とみなされ、それゆえ下請け企業への委託や海外へのアウトソーシング の対象となってしまうことが多い77。ただし、設計工程で述べたように、設計書は不十分 であることが多く、設計書の内容次第では想定外のプログラムができあがってしまうため、
安易な外部への委託はシステム開発の失敗の要因となる。
75 coding。プログラム言語を使用し、ソースコードを作成する。プログラミング、プログ
ラムを書く・作る・組む、実装などの呼称がある。
76 極めて高度なプログラマーとして、天才プログラマーと呼ばれる人間も存在する。彼ら は、高度で革新的なソフトウェアを多く生み出すことができる。特に、Windowsといった パソコンのOSなど、非常に複雑で難度が高いソフトウェアは、そのような非常に高度な プログラマーが関わっていることが多く、一般には理解されにくい部分でもある。
また、2000年代半ばから、クラウド・コンピューティングといった技術に注目が集まる に伴いその専門性も日々高まっており、プログラマーを中心としたソフトウェア技術者は そうした新しい技術にも深く精通している必要がある。
77 脚注ですでに述べたが、設計書通りのプログラムを記述するだけの作業者のことをコー ダー（Coder）と呼ぶ。日本では、明確にはコーダーと呼ばないものの、プログラマーの作 業がコーダーと変わらないような場合もある。