ITプロジェクトの完了時期は、プロジェクト開始時点から半年後、１年後、あるいはそれ以上ということもありますから、プロジェクトが完了したときにはプロジェクト開始時期の目標は変化しているかもしれません。つまり、プロジェクトのおかれた環境は時間経過とともに変化しますので、目標の変化は当然といえるでしょう。このことは自動車、家電製品などについても同様ですが、とりわけ企業情報システムは環境の細かな変化に合わせシステムを更新していかなければならないため、環境変化の影響を一層強く受けます。従って、このような情報システムは変化に強いアーキテクチャ設計にする必要があります。また、情報システム開発のプロジェクト管理も臨機応変に対応できるようにする必要があります。つまり、情報システム設計環境もプロジェクト環境も静止していることはないので、変化を前提としたアプローチ法を採らなければなりません。それが具体的にどのようなものか判然としているわけではありませんが、“時間指向”とでも呼んでおきます。ITの進歩と社会システムのIT化が進むにつれて社会の変化を手早く情報システムに反映しなければならなくなってきました。本稿では、変化に強いソフトウェアの設計とプロジェクト管理がどうあるべきか、企業情報システムを中心に考えるところを述べたいと思います。

１．変化に強いソフトウェア設計

変化に強い設計のアプローチ法の一つはソフトウェア・アーキテクチャです。これについては前稿：ソフトウェア・アーキテクチャを参照してください。そこで述べている通り、ソフトウェア・アーキテクチャの狙いはソフトウェアを開発する際、現在の開発環境（使用するマシン、OS、ネットワーク、ツール、市場、など）と将来予測される環境変化に亘って、ソフトウェア開発をコスト・ミニマムにする要素をソフトウェアの設計に織り込むことです。しかし、時代の変化はますます速くなり、そのようなやり方だけでは不十分になっています。今日では開発費用と期間の削減に向けて、前稿：プログラミング言語に依存するソフトウェア設計に述べたように、ソフトウェア・システムは、データベース、設計ツール、パッケージソフトウェア、プログラム部品、フレームワークなどの各種ツールを組み合わせて開発することが当たり前となっています。既存の実証済みのソフトウェアを活用して開発することにより、システム開発のスピードを速めることができ、変化への対応も容易となります。しかし、そうしたツールの使用に際しては先にも述べたように次のような課題があり、十分な事前評価が必要です。

またソフトウェア部品の体系的な再利用を狙うソフトウェアプロダクトラインも有効です。ソフトウェアプロダクトラインは組込みソフトウェアの開発に適しています。カーネルに近い部分は共用し、機種独自の機能と組み合わせることにより重複開発を避け、生産性・品質の向上がはかれます。つまり、カーネルに近い部分は開発に手間がかかるが変化は遅く、機種独自の部分は変化が速く開発も比較的容易であると考えられます。

Web系のソフトウェア開発ではRuby on Rails は変化に強いアプリケーションの開発に有効です。オブジェクト指向の解釈型言語Rubyはオープンソースで、またその上で動作するアプリケーションフレームワークにもオープンソースのものが多数あります。Rubyは解釈型のため速度の速いマシンを要求しますが、Ruby設計者のまつもとゆきひろ氏が述べているように、近年のマシン速度向上により、Rubyのような解釈型の言語で実用的なアプリケーション開発が可能となったのです。このような発想は大変重要です。かつて、オーバーレイ構造などマシンの制約を補う技術が発展しましたが、今日ではそのような技術は不要となっています。むしろ、向上したマシン性能をソフトウェア開発の容易化や生産性・品質の向上などの目的で使うのは意味のあることです。Ruby on Railsは高性能のマシンを十分に活かす時間指向のツールであると言えます。

変化に強いソフトウェア設計のためには、完璧を追求する考え方を捨て、効果があるならば良しとするベストエフォートの考え方を採ることも必要です。完璧を狙うと費用も時間もかかります。実用上、システムのすべての機能が使われるということはありません。必要となった時点で追加・変更開発を行えば良いのです。そのためにはRuby on Railsなどのフレームワークは大変役立つものと考えられます。誤解はないと思いますが、機能についてのベストエフォートに意味があるのであって、品質・信頼性については完全を追求しなければならないことは当然です。

以上述べたように、時間指向はソフトウェアの設計方法を大きく変えて行くことになるでしょう。

２．柔軟なプロジェクト管理

時間指向では、変化（ITの進歩と社会システムのIT化の進展）に強いソフトウェア設計に加え、プロジェクト管理も臨機応変に対応できるものでなければなりません。

プロジェクトはプロジェクト推進チームの立ち上げから始めます。当初はリーダとサブリーダの数人で構成し、最初に行う仕事はプロジェクト組織の編成です。プロジェクト編成は対象ソフトウェアの開発手順に準じて決めます。Waterfall型にするのか、必要な部分から逐次積み上げて行くAgile型を採用するのか、あるいはその中間の方式（例えば　Incremental+Agile）を採るのか。この判断は対象ソフトウェアの構造と利用環境に準じます。

図１　モジュール間結合／変化と開発手順との適性関係

　Waterfall型の場合、時間経過に従って、概ね「要件定義（機能設計）→構造設計→詳細設計→コード化→テスト（この一連の工程をLifecycleと呼ぶ）」の工程順に開発作業を進めますが、Waterfall型ではLifecycleは１つだけです。Agile 型では、同時並行で複数の短いLifecycleの開発作業が進められます。Incremental型では中核部の開発を最初のLifecycleとし、その成果を土台とした次のLifecycleの開発を、そして同様にして前の成果を土台としたLifecycleを繰返して完成させる方式です。図１は対象ソフトウェアを構成するモジュール間結合の強弱および技術・利用環境変化の速さと各開発手順との適性関係を示しています。Waterfall型は一発勝負です。Incremental型は慎重に構えたやり方で、これにAgile型を組み合わせると変化に強い方法となります。変化が速い大規模なソフトウェアの開発に向いています。

開発手順が決まればプロジェクト編成に着手できます。Waterfall型の場合Lifecycleの各工程に専任技術者を配置します。一般的には上工程と下工程の技術者を分けてプロジェクトを編成するケースが多いようです。このケースでは知識が分散されてコミュニケーションコストが増大する傾向があります。そのため、プロジェクト組織を取りまとめるプロジェクト推進チームの役割は重みを増します。

これと対極にあるAgile型の場合、小さな複数のチームがLifecycleを担うことになります。各チームの技術者は上工程から下工程まで少人数で作業することになります。各技術者は規模は小さいながらも質的には全行程の作業内容に通じていなければなりません。

プロジェクトをまとめる役割を担うプロジェクト推進チームのメンバは実践チームのリーダたちです。対象ソフトウェアの開発手順によってプロジェクト推進チームの運営の仕方は異なってきます。Waterfall型ならばプロジェクトは１つのLifecycleを扱い、Agile型ならば同時に複数のLifecycleを扱うという違いに起因した運営が必要となります。いずれの場合もプロジェクト推進チームで重要なことは民主的な運営です。Waterfall型では全体を少数のリーダやサブリーダが統括する必要があるため、中央集権的な運営になりがちです。前稿：ITプロジェクトにおける異能の価値で述べたように、そうしたやり方では本来もっている個人の能力（異能）を十分に発揮させることはできません。対極のAgile型では複数のLifecycle毎に個人の我が出てプロジェクトしての統一性を欠く恐れがあります。プロジェクトの規律を保ちながら、個人の能力を発揮させるプロジェクト運営がどうあるべきかを考える必要があります。

第１に尊重すべきはことは自発性です。プロジェクト推進チームのリーダは目標を提案し、参加する各メンバは自らの立場のその目標に対する合目的性を確認します。リーダは、また、合意形成ルールを含む合意形成を行います。メンバは各実践チームのリーダですから、各チーム内においても各メンバは自らの立場のその分割された目標に対する合目的性を確認し、合意形成を行わなければなりません。ここで成功の鍵となるのはすべての参加者の自発性です。

すべてのメンバは自らの役割を自覚し、必要な仕事を行い、各自がもつ知識をプロジェクト推進チームという合意形成の場に揚げ、プロジェクト推進チームはプロジェクト目標との整合をとります。このような合意形成はプロジェクト推進と成果に必要なすべての作業が対象となります。例えば、次があります。

・ 合意形成のルール
・ 予算配分
・ 計画立案
・ 情報システムの機能範囲
・ 設計方法およびアーキテクチャ
・ 役割分担
・ 人材調達と配置
・ コミュニケーション手段
・ 進捗状況の把握／分析／対策
・ リリース方法
・ その他

これらの合意形成に関して、すべてのメンバが直接/間接に関わらず関与し、納得していることが非常に大切です。プロジェクトリーダがプロジェクト推進に関する完全な知識を持っているということは殆どありません。抽象的な概念を述べることはできても、曖昧で不完全です。一方、他のすべてのメンバにしても自己の得意領域には詳しくても、他のメンバの得意領域やプロジェクト全般について知っていることは少ないでしょう。１人の人間がすべての知識を完全にもっていない以上、必要な知識を重なりあってもつ人々に集まってもらい、彼らの能力（異能）を、プロジェクトの目標達成のために十分に発揮してもらう“場”がプロジェクト推進チームであると言えます。

中央集権的でなく、かつ放任主義でもない、自ら形成した規律の下で、自発性を重んじた上記のプロジェクト推進チームはすべてのメンバがもつ知恵や知識をプロジェクト推進に迅速に反映させる体制と言えます。　■