オブジェクト指向は、パイロットプロジェクトや小・中規模プロジェクトに試験的に適用されてきた時代から、大規模プロジェクトに適用される時代へと移行しています。オブジェクト指向は使っていても、開発プロセス不在のプロジェクトや、旧来のウォーターフォールモデルの開発プロセスを適用したプロジェクトが多く見受けられました。意外にもそのようなプロジェクトもいくつかは成功しています。成功したのでしょうか?筆者は以下の理由によるものと判断しています。リスクが小さいプロジェクトだったプロジェクトメンバーのエンジニアのスキルやモチベーションが高かった小規模プロジェクトであるため、プロジェクトメンバー間での作業の調整や、計画の変更が容易だったこのような成功要因は小・中規模プロジェクトゆえの特徴です。今後増えてくるであろう大規模プロジェクトではこのようにはいきません。大規模プロジェクトは大規模であるがゆえ、大人数の普通のエンジニアで開発しなければなりません。さまざまなリスクが存在します。大規模プロジェクトで成功するためには、このような大規模プロジェクト特有の要因を考慮したプロセスを用意する必要があります。中・大規模プロジェクトを成功させるための仕組みを持つ開発プロセスです。ライフサイクルモデルや、プロジェクトの成功の要となる「フェーズ」と「反復」をどう計画し実行すれば良いのか、説明します。ソフトウェアライフサイクルモデルソフトウェアライフサイクルとは、その名のとおり、ソフトウェアが生まれてから死ぬまでの流れを表す用語です。生まれてから死ぬまでとは、ソフトウェアが構想され、開発され、運用され、保守され、廃棄されるまでを指しています。ソフトウェアライフサイクルモデルとはソフトウェアライフサイクルをある一定のモデル(典型的なライフサイクルのパターン)で表現したものです。ウォーターフォールモデルは最もメジャーなソフトウェアライフサイクルモデルといえるでしょう。ソフトウェアライフサイクルのうち、ソフトウェアの構想から納品までをサポートするプロセスで、運用や廃棄は含んでいません。ライフサイクルの概念において最も長い期間を表すものがサイクルです。サイクルとは、ソフトウェアが構想されてから納品されるまでを表す概念です。つのフェーズに分けてコントロールします。サイクルとフェーズ方向づけフェーズは、ソフトウェア開発プロジェクトを開始しても問題ないか判断することが目的です。この目的のために、ソフトウェアに開発する価値があるか見極め、ソフトウェアのスコープ(ユースケース)を決定し、フィージビリティスタディによりソフトウェアの実現可能性を検証して、その上でプロジェクトを正式に開始します。ソフトウェアに開発する価値がない、実現可能ではない場合には、プロジェクトを中止することもあります。次の推敲フェーズを円滑に進めるための準備もします。推敲フェーズで行う作業についてプロセスを策定します。推敲フェーズは、プロジェクトに存在するさまざまなリスクに対処することが目的です。技術リスク、要求リスク、プロセスのリスクに対処します。この目的のために、ソフトウェアアーキテクチャのベースラインを確立し(技術リスクに対処)、要求を詳細化し(要求リスクに対処)、作成フェーズ移行で行う作業についてプロセスを策定します(プロセスのリスクに対処)。作成フェーズまでにこれらのリスクが対処されていなければ、実際に問題が起きた場合の影響は、作成フェーズを再計画しなければならないほどになるでしょう。作成フェーズでは、すべての要求を実現するソフトウェアを構築することが目的です。推敲フェーズで構築したソフトウェアアーキテクチャ、定義した要求、修正した開発プロセスに従い、開発を行います。移行フェーズでは、運用が可能な状態でソフトウェアを納品することが目的です。バグへの対応、ソフトウェアの改善、納品に伴う作業を行います。最大の特徴は、反復型開発であるということです。ヶ月程度の反復に分割し、その反復中に要求を実現する動くソフトウェアを構築します。プロジェクトは複数回の反復を経て、完成したソフトウェアをリリースすることになります。反復には以下のような特徴があります。期間が決まっている(タイムボックス開発)反復は、あらかじめ1ヶ月から3ヶ月程度の期間を決めてその範囲内で開発を行います。作業の進捗が遅れたからといって、当初決めた期間を延ばしたりするようなことはしません。このような手法をタイムボックス開発といいます。反復の期間は、反復内で行う作業の量に依存します。行う作業が多ければ当然反復の期間も長くなりますし、少なければ反復の期間も短くなります。多くのチームが存在する場合には、チーム間でコミュニケーションをとるために余分に時間がかかるため反復の期間が長くなります。同様に、レビューの基準が厳しいプロジェクトでも反復の期間が長くなります。反復ごとに目標を立て、反復終了時に評価する反復には、実現するソフトウェアアーキテクチャのメカニズムや、ユースケースや、対応するリスクなどさまざまな達成目標を設定します。反復の終了時には、この目標が無事達成できているか評価します。反復の評価を行うことによって、反復時に発生した問題点を次の反復に活かすことができます。動くソフトウェアをリリースする方向づけフェーズ以外のフェーズで実行する反復では、要求を実現する動くソフトウェアを必ずリリース(内部リリース、もしくは外部リリース)します。動くソフトウェアを作ることによって、ソフトウェアを統合するリスクを早期に解決します。反復型開発を行って、短い期間で目標を達成していくことにより、プロジェクトに存在するさまざまなリスクを早期に解決できます。推敲フェーズの反復で、機能要求や機能外要求の実現に必要なソフトウェアアーキテクチャを確立します。そのため、作成フェーズ以降では、技術的な問題について考慮することなく、スムースに開発を行えます。開発環境もプロジェクトの早期に決定します。ソフトウェアアーキテクチャの検討と同時に、開発環境の選定を行うため、ソフトウェアアーキテクチャを実現するために適した開発環境を採用できます。推敲フェーズの反復で、大部分の要求を詳細に定義します。作成フェーズ以降にも、いくつかの要求は追加・変更になるかもしれませんが、そのような要求を要求管理の一環として、変更要求として管理し、反復の計画を見直します。反復の度に動くソフトウェアを構築し、統合し、テストします。統合テスト(場合によってはシステムテストも含む)を行うことによって、致命的なバグをプロジェクトの早期に取り除くことができます。反復の度にソフトウェアを分析し、設計し、実装し、テストします。そのため、プロジェクトの早期から、さまざまな技術要素(UML、オブジェクト指向、開発環境、ミドルウェアなど)について学習する機会が設けられているため、プロジェクトの後半には要員の生産性や、できあがるソフトウェアの品質が向上しています。フェーズや反復の開始時などプロジェクトを見直すタイミングが多く設けられています。プロジェクトの最初に出した見積もりに誤りがあった場合にもこのタイミングで再度見積もりを行うことができます。それぞれのフェーズは目的も作業の内容を大きく異なるため、フェーズの開始時に再見積もりができるように考慮しておいたほうが良いでしょう。テストなどの作業を行って、動くソフトウェアを構築します。この動くソフトウェアをビルドと呼びます。反復では、一連の作業を何度も繰り返します。最後の一連の作業で構築したビルドをリリースします。それぞれの作業にかける時間は、フェーズごとに異なります。フェーズによっては、まったく行わない作業もあります。作成フェーズの反復ではビジネスモデリングの作業を行いませんし、他のフェーズの反復と比べ実装やテストの作業に時間を多く取ります。プロジェクトの計画を立てる上で、方向づけフェーズの開始時に、移行フェーズが終了するまでの詳細な計画を立てようと思ってはいけません。詳細な計画をプロジェクトの最初から立てることは不可能です。フェーズの開始時にそのフェーズの計画を立てます。推敲フェーズの開始時には推敲フェーズの計画を立てる、作成フェーズの開始時には作成フェーズの計画を立てるといった具合です。推敲フェーズの開始時には、作成フェーズ、移行フェーズの計画は仮でしかありません。いうのは、推敲フェーズが終わらないと、要求のボリュームも分かっておらず、また利用するアーキテクチャがどのくらい複雑かも分かっていないため、詳細な見積もりをしようにもできないのです。以下に、どのフェーズの開始時にどのくらいの精度でそれぞれのフェーズの見積もりができるか示します。詳細見積もり(ユースケースの詳細から作業工数を見積もる)フェーズを計画するにはそれぞれフェーズの開始時には、フェーズで反復の回数と期間、要員の人数とスキルの目安を決めます。それぞれの反復で誰にどのような作業を担当させ、どのような順番で作業を実行するのかといった詳細な計画は立てません。それぞれの反復の開始時にそのときの状況を考慮して計画することになります。それぞれのフェーズで何に気をつけて計画を立てるべきかについては、次回以降の記事で説明します。反復を計画するには反復の計画は、プロジェクトと違い、より詳細な計画を立てます。反復の計画では、以下のことを考慮しなければなりません。予算このどれから決めてもよいですが、一般的には反復の目標か、反復の期間から決めます。反復の目標から決める場合には、反復の目標を達成するための作業工数を見積もり、そこから反復の期間と用意できる要員を決定し、予算を決定します。反復の期間から決める場合には、反復の期間内で達成できる目標と用意できる要員を決定し、予算を決定します。作成フェーズの反復を、反復の目標主導で計画する場合まず、目標として反復で実現するユースケースを選択します。つのユースケース(UC01、UC02)を実現することを反復の目標にします。つのユースケースに関連した業務についてシステムテストを実施することを目標にしました。統合テスト、システムテストで見つけたすべての障害に対応することを目標にしました。日かかると分かりました。統合テストやシステムテストで見つけた障害に対応する障害対応作業も必要になります。ように要員に作業を割り当て、スケジュールを立てました。