羽生田栄一
豆蔵 CEO
2002/1/22

「開発プロセス」は、1つのソフトウェアをどのような手順で作り上げるかの取り決めです。その意味で、ソフトウェア開発の現場には必ず開発プロセスが存在します。本稿では、前編で、開発プロセスの目的とその歴史を眺めながら、ソフトウェア開発の現場が従来の開発プロセスによってどのような課題を抱えてきたのかを整理します。そして後編では、従来の開発プロセスが抱える課題に対する解答として登場してきた、新しい開発プロセスであるRUPやXPを紹介します。

前編　従来の開発プロセスと現場が抱える課題

　最近、プロジェクトマネジメントが話題になっています。ソフトウェア産業が成立して数十年たった現在でも、いまだにシステム開発に失敗する例があまりにも多いからでしょう。しかし、ブームでもてはやされている個々の開発手法を学んでもあまり意味がないように思います。プロセスとは、理論ではなく実際にプロジェクトに具体的に適用し、開発を成功させることができてナンボのものだからです。それよりは、開発プロセスがそもそも何のために存在するのか、その背景にある考え方を知っておく方が、プロジェクトマネージャや開発メンバーの心構えとして役に立つと考えています。

　近年のソフトウェア開発の特徴として、次のようなことがいえます。

　　表1　近年のソフトウェア開発の特徴

（1）	従来の開発に比べて期待される開発工期が相対的に短い
（2）	要求仕様が固まっていない状態で開発を始めねばならないケースが多い
（3）	さらに要求の追加・変更が開発中にも継続的に発生する
（4）	利用すべき技術や製品が次々に登場・改訂される中で開発しなければならない
（5）	アプリケーション固有画面、Web画面、i-モード、そのほか携帯端末などのさまざまなインターフェイスに対応しなければならない

　従って、従来のようにじっくり構えて一歩一歩着実に仕様を固め、その仕様からシステム仕様・設計仕様・実装仕様と落とし込んでいき、最後に実装・テストするというスタイルは取りづらくなっています。マーケットがそれを許さないのです。

　現在の開発者たちは、時間とコストと性能に関して厳しい制約とプレッシャーの中での開発を強いられているといえます。こうした状況にある開発チームを、技術面・組織面・精神面でバックアップし、さまざまな障害の起こる中で少しでも安定したプロジェクト運営を行い、クライアントにコミュニケーション上でも製品上でも満足してもらえる、プロジェクト成功のコツ(ベストプラクティス）のようなもの、それが開発プロセスだといえましょう。しかし、従来の開発プロセスは、そこまでには至っていません。いまようやく、オブジェクト指向技術と肩を並べるようにして、新しい開発プロセスの考え方がソフトウェア開発を変えようとする端緒についたばかりではないでしょうか。

UML自体は開発プロセスではない

　それでは、あらためて開発プロセスとは何でしょうか。いまの話の流れでいくと、「システム開発を成功へと導くプロジェクト運営の、一番基になる基本的なプロジェクトの進め方に関する基本的な考え方をまとめたもの」が、開発プロセスであるといえます。従って、通常、開発プロセスには、開発を構成する「アクティビティ」とその時間順序や依存関係を指定した「ワークフロー」、各アクティビティの作業内容の中で生成されるUMLモデルやドキュメントなどの「成果物」、それに作業や管理の指針となる「ガイドライン」が含まれるのが普通です。そのガイドラインに、要求のまとめ方や分析クラス図作成上の注意点、アーキテクチャ設計の技法、個々の局面でのテスト手法、コーディング規約などがまとめられているわけです。

　UML（Unified Modeling Language：統一モデリング言語）は、オブジェクト指向で分析や設計のモデルをダイアグラム化し、表現するための言語です。最近、UMLはシステム開発の現場にも普及し始めていますが、情報システム部門のマネージャさんの中にも、UMLはオブジェクト指向方法論であると誤解されている方がいらっしゃいます。Java Solutionフォーラムの「初歩のUML」をお読みいただいている読者は、UMLというのが単なるビジュアルモデリング言語であって、クラス図やシーケンス図などの各種ダイアグラムの表記法の定義にすぎないということをご理解いただけていると思います。UMLは、オブジェクト指向開発プロセスや、オブジェクト指向分析設計モデリング技法ではありません。

　ソフトウェア開発がまだ産業とは見なされていなかったころ、「開発＝プログラミング」という発想が濃厚でした。これはいまでいう日曜プログラミングのレベルといえるでしょう。しかし少し大きなプログラムを作ろうとすると、全体的な構造やしくみをあらかじめ考えてからプログラミングに入らざるを得なくなってきます。なぜなら、人間は一度にすべてのしくみや制約を頭の中で管理することはできないからです。そこで、デザインという作業が必要になってきます。

図1　デザイン―プログラミング2段階モデル

　ここでデザインという言葉を使い、あえて設計といわないのは、「デザイン」という言葉は「設計」よりも広い作業内容を指しているからです。企画や要求の分析から画面のデザインなどまでを含めて、実装前のすべての段取りをひっくるめたものを、デザインと呼んでいるのです。またプログラミングにも「もろもろ」と修飾がついているのは、ここにもテストやインストール、運用上の準備などが、ごった煮的に含まれているということです。

従来の標準的な開発プロセス

　しかし、この2フェーズだけでは、大規模な開発、特に大人数でチームを組んで開発を行わなければならない場合には対応できず、もっと段階的な作業フローが必要とされるようになってきたのです。そこで考えられたのが、「ウオーターフォール型」プロセスと呼ばれる開発プロセスです。

　ユーザーのシステム要求の獲得定義から始めて、必要な作業とその成果物を着実に1フェーズずつ完成させていけば、必ず正しいシステムにたどり着くという発想で作られています。ウオーターフォールというのは滝のことですが、華厳の滝のような一気に落ちる滝ではなく、何段にも小さな滝がつながったものをイメージしてください。滝の特徴は、水の流れは必ず上から下にしか流れない・逆流することはないというものです。従って、1フェーズずつ必ず正しい成果物（要求定義なら仕様書、実装ならソースコード）を出してその段階をすべて完成させてから次のフェーズに進むことが想定されています。もし、誤った仕様書で設計を始めてしまったら、誤ったコードに導かれざるを得ないのですが、それを押しとどめたり、うまく前に戻って適切に修正したりすることは考えられていないのです。

図2　ウオーターフォール型プロセス

　またこの開発プロセスは、各フェーズで作成されるドキュメントを非常に重視します。ドキュメントが、隣り合わせたフェーズ同士をつなぐ唯一の情報源だからです。しかしながら、そのドキュメントは、形式的には完成されてから次のフェーズに引き渡されますが、プロジェクトの早い時点でシステムの全貌が見えていることは実はまれなのです。結局は不完全な、ずれた内容になっています。つまり実際のユーザーのニーズから少しずつずれた情報が伝言ゲームのように先送りされていき、そうした情報に基づいて作られたソースコードは、常にユーザーからは不満を持たれ、結果としてバグ修正や突発的な追加要求の前に変化し続け、結局は仕様書をほとんど反映していないコードに成り果ててしまうというケースをよく見かけます。

ウオーターフォール型の問題点

　業務領域がいつもの手なれた分野であって、しかも使う技術も相変わらずだという古き良き時代には、この方式でも何とかプロジェクトをものにすることはできたわけですし、逆に効率的だったともいえます。しかし、少しでも状況変数が変わってしまうと悲惨な失敗が待ち受けていました。規模が少し大きくなった、いつもと違う技術を取り入れてみた、要求が隣の組織の都合で突然追加になった……などなど、プロジェクトの状況変数が変わらないことの方が珍しいことを考えると、ウオーターフォール型では本当に大胆な超楽観的計画でプロジェクトを切り盛りすることになるわけで、ほとんど神頼みの世界です。リスクは存在しない、存在しても各ステージをやり過ごせば何とかなる。リスクを想定して保険をかけたり、回避のための別動隊を編成したり、机上訓練をする時間やコストはうまくいけば無用なのだから、無駄な出費だというわけです。

　しかしながら、ソフトウェア開発は複雑さをどう飼いならすかへの挑戦だといわれます。そこには4つの複雑さがお互いに絡み合って、ますます錯綜した状況を作り出しているからです。業務問題領域やそこでの要求内容の複雑さ、それを解決すべく設計し構築すべきソフトウェアシステムの複雑さ、クライアントやその周りの利害関係者と受託開発者の間のコミュニケーションの複雑さ、そして最後にそのソフトウェアシステムを作り出す開発チーム内部のコミュニケーションの複雑さ、この4つがお互いに入れ子になって複雑なマンダラを作り出すことで、開発は不思議なねじれと興奮？ をもたらします。

図3　ソフトウェア開発にまつわる4つの複雑さ

　その結果、ソフトウェアシステムの開発にはいつでもバグや遅延、コスト高や徹夜残業、結局完成できない、といった失敗のリスクが待ち受けています。開発プロジェクトにまつわるリスクは大きく次の4つに分類できるでしょう。

　　表2　ソフトウェア開発にまつわる4つのリスク

（1）	要求リスク	システムに対する要求に関する誤解など
（2）	技術リスク	安定性、設計技術、運用と干渉、製品サポート、将来性など
（3）	要員リスク	適切な人材の確保や教育、チームワークや適性など
（4）	政治リスク	プロジェクトの利害関係者の圧力や対立からの干渉など

　ところが、従来の標準開発プロセスであるウオーターフォール型プロセスでは、ほとんどリスク管理という点を意識していません。メンバーの全員がそのドメインで何度も経験があり、仕様も完全に事前に固定されていて、さらに開発で用いる技術にも手なれていてリスクがない、という状況であれば、確かにウオーターフォール型の開発プロセスはいっさい手戻りもなく、一見効率的に見えます。しかし、どんなプロジェクトにも変更はつきものです。それに対処するというリスクは想定されていませんから、無理やり仕様書や実装コードをやっつけで直すというアドホックな対応になりがちなわけです。こうしたことが何回か積み重なれば、すぐに工数や品質に歪みが累積し、結果としてプロジェクトは、納期の遅れ、コストのオーバーフロー、収束しないバグといった失敗に陥るでしょう。そういった可能性をまったく無視して1回ですべてうまくいくという理想の手順を述べたものを、開発プロセスと称していたわけです。

　この開発プロセスで破たんが明らかになるのは、プログラミング後のテストのフェーズにおいてです。ここで明らかになった機能的、システム的、性能的、そのほかの問題は、非常に大きな設計変更や要求の見直しを伴うことになります。それを修正するための体系だった修正のプロセスは組み込まれていないわけです。

ウオーターフォール型プロセスの改良の方針

　そこで、ウオーターフォール型に対するプロセスの改良が始まりました。まず考え出されたのが、「スパイラル型」の開発です。システム全体の要求を一度に聞いて、いっぺんに設計し、いっぺんに実装するのは無理なので、少しずつ分析し、少しずつ設計し、少しずつ実装し、というサイクルを段階的に繰り返していこうというプロセスです。こうすることで、理解できたところ、要求が固まったところから作業を前に進められ、誤りの修正も1サイクル以内に行えるという柔軟性が手に入ります。

図4　スパイラル型プロセス

　逆に、このプロセスの問題点は、全体を見極めないうちに作業が進んでしまい、プロジェクトの方向性を誤る可能性がある点です。また、最終成果物をきちんとスケジュールに合わせて製造できるようにするプロジェクト管理がしづらいという点も、実システム開発に導入する際には大いに問題となります。これは特に、スパイラル型開発の中でもプロトタイピングと呼ばれる、作っては壊しというサイクルを繰り返すやり方で頻繁に起こりました。こうした問題を、後に述べるRUPに代表される最近のスパイラル型開発では克服しているので、最近ではあえてスパイラル型とは呼ばずに「繰り返し型」というようになってきています。

　スパイラル型のバリエーションとして、「反復型（イテラティブ）」プロセスと「漸増型（インクリメンタル）」プロセスと呼ばれるものがあります。反復型では、1サイクルでシステム全体を薄く仕上げて前サイクルの成果にオーバーラップさせていきます。一方の漸増型では、1サイクルでシステムの明確に分離された一塊のモジュール群（これを1インクリメント＝増分）を前サイクルの結果に上乗せしていくイメージです。管理は、漸増型の方が明確にモジュール化され、やりやすいですが、実際に大きなプロジェクトでうまくこのような境界をインクリメントとして切り出すことができるとは限らないので、通常はこの両者の折衷で開発を進めていくのが普通です。つまり、ある程度大枠は、サブシステム単位で明確に境界を設定しつつも、各サイクルでインクリメントされる増分部分は前回の作業成果物と完全に分離されることはなくオーバーラップしながら開発が進められていきます。従って、構成管理の仕事は非常に重要です。

　また世間一般では、反復型と漸増型の区別を明確にせずにどちらも反復型ないしは繰り返し型と呼んでいるケースが多いです。そこで、本連載でも、これ以後は両者を区別せずに、反復型と呼ぶことにします。

図5　反復型（イテラティブ）プロセス（左側）と 漸増型（インクリメンタル）プロセス（右側）

　もう一つの視点として、「エンジニアリングステージ」と「製造ステージ」という2つの切り口を導入し、両者をうまくバランスさせるというリスク対処の方法が編み出されました。エンジニアリングステージとは、まさに「技術的・工学的」な課題を検討しアーキテクチャを推敲しながら解決手段を見つけ出すことで開発リスクを解消し、要求を理解して開発計画を定義するためのもので、成果物は実働するアーキテクチャの中核部分です。一方、製造ステージでは、エンジニアリングステージで開発されたアーキテクチャの中核部分上で、要求を実現するように開発計画を実施し、利用可能な機能の集合体としてのユーザーシステムを製造します。このようなR&D的な段階といわゆる製造段階とをバランスよく組み合わせることで、エンジニアリングによる要求リスク・技術リスクの軽減とフレームワーク作り、製造段階でのフレームワークに基づく開発生産性や信頼性の増大をともに図ろうというのが、この2ステージモデルの趣旨です。しっかりとしたエンジニアリング作業のおかげで、製造段階に入る前に、システムに対する要求内容の理解とそのソフトウェアによる実現方法についての理解とが、そのプロジェクトの関係者相互で十分に合意できている状態に持っていける、というのが最大の特長なのです。

　一見すると、この2つのステージは、ウオーターフォール型よりさらに以前のあの「デザインもろもろ−プログラミングもろもろ」プロセスと似ているように見えます。しかし、大きく違うのは、この改良された2ステージモデルではエンジニアリングステージでも分析・設計・実装が行われれるし、製造ステージでも分析・設計・実装が行なわれるという点です。つまり、2つのステージは実験室での開発と現実世界での開発という区別であって、作業の目的は違いますが、やる作業項目はだぶっているということです。まずプールで泳ぎの技と危険回避のイメージトレーニングをしっかり積んでから海に出て泳ぐという違いであり、手の使い方や呼吸法やキックの仕方という点では同じ動作が存在する、という比ゆが当たっているでしょうか。

　以上の、繰り返し型開発とエンジニアリング―製造の2ステージモデルの実務的な組み合わせによって、ソフトウェア開発のリスクを何とか飼いならそうというアイデアが生まれるのは時間の問題でした。組み合わせることで、スパイラル型プロセスの問題点である、全体を見極めないうちに作業が進んでいってしまいプロジェクトの方向性を誤るリスクや、最終成果物をきちんとスケジュールに合わせて製造できるようにプロジェクトを管理しづらいという点が改善されるからです。この趣旨で形成されたのが、RUP（Rational Unified Process：ラショナル統一プロセス）です。

　後編は、RUPと最近話題を集めているXP（eXtreme　Programming）代表されるライトウェートな開発プロセスについて紹介し、これらが従来からのソフトウェア開発が抱える課題をどのように解決しようとしているのかについて解説します。

INDEX 　いまなぜ開発プロセスを注目するのか

前編　従来の開発プロセスと現場が抱える課題

後編　新しい開発スタイル「ＲＵＰ」と「ＸＰ」

　

IT Architect 連載記事一覧