システム開発はこの10年でますます複雑になった。社内システムの開発チームは、従来の作業(電気技術や機械技術などを駆使する保守・サポートなど)と並行してソフトウェア関連の作業にも対応しなくてはならない。さらに、高機能かつ統合・最適化された分散システムの導入を求める社内関係者たちへの対応も余儀なくされる。次世代システム開発を管理する人々は新たな難問に直面している。本稿ではそんな難問を考察し、(解決の糸口を導き出す)戦略および企業のトップとしてのアプローチを模索する
最初の画像衛星の打ち上げは、人類が達成した技術面の偉大な業績だった。このプロジェクトの開発チームはまず、前代未聞のシステムがユーザーのニーズを満たすために必要な機能の分析をしなくてはならなかった。次に彼らは、既存の技術を使って地上の建造物を画像化し、その画像が地上基地にダウンロードされるまで保存して、アナリストがワークステーションからアクセスできるようにする方法を考え出さなくてはならなかった。当時は、このソリューションだけにリソースを割り当てることも大した問題ではなく、機能を実現するだけで関係者のニーズを満たすことができた。
ところが、現在は状況が大きく変わっている。
現代の画像衛星システムの設計者は、基本機能の実現にはあまりこだわらず、関係者の幅広いニーズを満たすような、システムの最適化の方を重視する。例えば、アナリストはシステムが収集した情報を可能な限り短時間で入手するだけでなく、その情報をほかの情報源からのデータと統合する機能までも要求する。システムの所有者は、1つの機能のためだけに1つのシステムを維持するという余裕はない状況を強いられている。つまり、ハードウェア(およびソフトウェア)の占有を最小限に抑え、既存のリソースを有効に再利用したいと考えているのであり、運用および維持のためのコスト削減に相当な関心を示しているのである。
さらに、状況を複雑にするのはプログラムだ。現代のプログラムは役目を終えるまでに、目的やシステムを実現する技術が何度でも変わる。システムの出資者たちは、最低限のコストと最小限の運用中断でこれらの変化に対応する進化を求める。加えて彼らは、自分たちの投資が再利用可能な知的財産になることも期待しているのだ。
現代のシステム設計では、(個々の技術への特化というよりも)全体的なシステムデザインを優先する開発アプローチの採用が主流である。このようなアプローチは、システムの最適化という複雑な課題に挑む設計者を支援してくれる。例えば、かつて衛星画像システムの設計者には限られたアプローチしかなく、技術的制約の克服にあれこれと知恵をめぐらせる必要があった。しかし今日のシステム設計者には必要十分以上の処理能力が与えられており、システムを最適化するためにサブシステムの負荷を見直すことができる。この現象は通信、航空電子工学、情報技術など、多数の分野に当てはまる。
システム開発現場の3つ目の変化は、アプリケーション・ソフトの肥大化と複雑化だ。オブジェクト技術、コンポーネントフレームワーク、ソフトウェア開発の自動化の到来で、ソフトウェア開発の生産性は1970年当時と比べて3倍も向上した(注1)。同時に、処理能力、内蔵メモリ、データストレージ容量、そしてネットワークの帯域幅も大幅に増加した。要するに、この上なく洗練された運用環境が実現しているのだ。ソフトウェア開発およびシステム開発の両業界は、これらすべての技術的向上を活用しながら、ますます大きく複雑なプログラムを開発するようになった。実際、平均的なソフトウェア・アプリケーションのサイズは競争圧力によってファンクション・ポイントで10倍にまで増大している(注2)。技術の向上が続く限り、おそらくこの傾向も続くことになる。
問題空間の拡大、ソリューション空間の拡大、そしてアプリケーショの肥大化を考えると、最近のプロジェクトに従来のシステム開発手法がまったく役に立たないと判明しても驚かない。もし、システム開発のほとんどがソフトウェアの開発作業に費やされたとしても、いまの企業トップは開発メンバーそれぞれが持つ生産性を最大限に活用する方法を選ぶ必要はない(かつては少ないリソースをいかに工夫して、顧客の要求を満たすシステムを開発するかが最大の課題だった。しかし現代ではリソースはむしろあり余っている状況だ)。企業のトップは、システム全体としての適切さ(つまり顧客に必要とされるサービスの提供)を目指し、相反する関係者のニーズに最も適切に対応するものを確実に構築することが求められるのだ。
このような現代の課題に対処するためのアプローチをいくつか考察してみよう。
システムを概念的に説明する数多くの方法がある。以下、代表的な2つのアプローチを紹介する。
例えば、ロケットエンジンのシステムは、1番目のアプローチで考えるのが最適だが、多くの情報システムは、2番目の見方が主流になる。ところが実際は、すべてのシステムがいくつかの点で両方のアプローチに当てはまる場合がある。ロケットエンジンにはソフトウェアをベースにした制御系システムが組み込まれているし、情報システムはそのパフォーマンス、待ち時間、そして信頼性が物理の法則に規制を受けるからだ。
プロジェクトリーダーはこれまで、システムの種類によって膨大な数のアプローチから1つだけ選択して当てはめ、管理をしてきた。もしシステムを物理的なものだと考えれば、ソフトウェアはハードウェアの機能を実現するための必要悪だと見なした。そして、システムをソフトウェアの観点から見た場合は、ハードウェアを単なる運用メカニズムとしてとらえ、たいていは(開発作業を)後回しにしていた。
情報システムを上記の2つのアプローチのどちらか一方にしかフォーカスしない場合、以下のようなさまざまな品質関連の問題に注目しがちになる。
情報システムをとらえるさまざまな見方に適応する管理方法もさまざまな形態で進化してきた。一般に、物理的要因をベースにするチームが連続的なアプローチで作業を進め、ソフトウェア開発チーム方は反復的なアプローチを採用しがちだといって差し支えないと私は考えている。
技術が進化を続ける中で、上記の物理面・ソフトウェア面両面での検討がますます必要になってくる。物理システムに組み込まれるソフトウェアは経済的価値が大きく高まっている。例えば、現代の自動車エンジンのパフォーマンスは主に、そのエンジンのコントローラを制御するソフトウェアで決まる。実際、現代の自動車は大半がソフトウェア技術に依存しており、ハイブリッドガスや燃料電池ベースのシステムが台頭する中で依存度は高まるばかりだ。これと同じことが通信、医療、航空などの機器にも当てはまる。純粋な物理ベースのアプローチは、ソフトウェア技術の依存性を認識していないが、一方で、純粋なソフトウェアのアプローチは、大規模分散情報システムの増加に伴うTCOの増加を真剣に考えていない。
つまり現代のシステムには、品質の問題に対処するバランスの取れたアプローチが必要とされているのだ。
管理に関する物理面・ソフトウェア面のバランスが取れないと、次のような徴候が現れ、開発プロジェクトを悩ませることになるだろう。
進歩的なシステム開発チームや組織は、数年前からリーダーシップとプロジェクト管理の両アプローチをうまく調整し、システムにおける物理面・ソフトウェア面の両側面のバランスを実現している。また、多くの開発者は数十年かけて大規模ソフトウェアプロジェクトの管理から学んだ教訓を(適切に修正を加えて)システム開発に応用すべきであることを十分に理解している。これらの教訓については以下で述べる。
ソフトウェア開発の専門家が学んだ教訓の1つに、詳細な計画はほとんどがそのとおりには進まない、というものがある。米Standish Groupによると、ソフトウェア開発プロジェクトの49%は、最終的には完成するが当初の予定どおりにはいかなかったという(注3)。結局、多くのプロジェクトはスケジュールや予算が予定どおりにいかなかったり、表1に示したように、当初予定したコンテンツとは異なるコンテンツがプロジェクトによって生み出されてしまう可能性が高い(ただし完全に失敗に終わるプロジェクトの割合は減少傾向にある)。
年 | 計画どおりのスケジュール、予算、コンテンツを実現 | 計画どおりではないが完了 | 失敗 |
---|---|---|---|
2000 | 28% | 49% | 23% |
1998 | 26% | 46% | 28% |
1996 | 27% | 33% | 40% |
1994 | 16% | 53% | 31% |
表1 ソフトウェアプロジェクトの結果 |
詳細な計画を立てるためには、開発にかかる正確な労力と開発期間を見積もる必要がある。コードの規模をかなり正確に見積もる十分な経験があれば、タイトな作業予定や完成予定を立てることができる。しかし、検討中のシステムについて、問題やソリューション空間の考察が必要な場合は、見積もりはもっと難しくなる。例えば、非常に洗練されたCOCOMO見積もりモデルの作者は次のように述べている。
「161のデータポイントでは、1998(COCOMO)リリースは75%の確率で作業工数誤差30%以内(組織による階層化実施後は80%の確率で30%以内の誤差)を示し、インクリメンタルではない開発スケジュールでも72%の確率で誤差30%以内(組織による階層化実施後は81%の確率で誤差 30%以内)という精度を立証している(注5)。」
従来のシステム開発プロセスでは、チームが次の作業へと移る前に各作業(プロジェクトのプランニングであれ、要求分析であれ、設計であれ)に非常に正確で詳細なソリューションが必要になる。もし時間がたって成果物に不具合や欠陥があると分かった場合、それはチームの過失だと考えられる。しかし、問題やソリューション空間が大きいため、現代の多くのプロジェクトには初めから従来のシステムより多くの不確実性がある。そこには関係者と彼らのニーズに対する大まかな理解しかない。さらに、関係者のニーズを満たすための課題や機会を考えると、ソリューションには何らかの創造性が必要になる可能性が高く、これがさらなる不確実性をプロセスに持ち込んでくる。
結局、プロジェクトチームの成長に伴って、プロジェクトがどのように進むかは何千人といるチームメンバーそれぞれが、システム開発のために協力して苦戦する中で下す判断結果によって決まってくる。プロジェクトの進み方を予測するのが困難であることは想像に難くないだろう。
量的アプローチを取るため、ガントチャート(Gantt chart)にあるような、一定期間続く作業の集まりとして指定されたプロジェクトの計画が完了する確率を考えてみたい。シンプルなモデルを使うと、このプロジェクトが予定どおりに完了する確率は、作業Nすべてを完了する場合と同じ確率となり、次のような式で示すことができる。
ソフトウェアやシステムの開発に固有の不確実性や時間のプレッシャーを考えて、95%の確率で完了できるような作業時間をマネージャが設定したとする(私の想像では大半の計画が作業レベルにおけるこの程度の確実性にさえ欠けている)。この場合、N個の作業で構成されるプロジェクトの計画が完了する確率は表2のようになる。
作業数 | P(計画完了率) |
---|---|
10 | .59 |
25 | .27 |
50 | .07 |
100 | .006 |
1500 | 10のマイナス23乗 |
表2 当初計画が完了する確率 |
明らかに、作業の数が増加するほど、計画が完了する確率は低下する。逆にいえば、当初の計画をあまり詳細に詰めないことで、そのプロジェクト固有の不確実性に対処するための柔軟性が生まれ、計画どおりに作業が進む可能性も高まる。
規模が大きく独創的なソフトウェア開発プロジェクトでは、正確で詳細な計画を立てることが不可能なことを考えると、プロジェクト固有の不確実性を加味しながらプログラムをよりうまく管理することが現代のシステム管理の目指すべき必然的ゴールとなる。その一方で、物理システムを構築するには、詳細な計画と早期関与が必要であるように思える。実際、システムや製品の開発が関係するビジネスプロセスには、不可能であるかに思える詳細な計画と関与が必要だろう。そのテンションに対処することがトップと幹部の課題なのだ。
簡単なソリューションはないが、システムプロジェクトをうまく完了させるためにプロジェクトリーダーが利用した一連の原則がある。ここからはそれについて解説する。
プロジェクトの成功とは何かを再考することがまずはカギとなる。成功したプロジェクトに対して自分が抱く概念が表1の最初の列に示されるようなものならば、問題/ソリューション空間がよく理解され、詳細な見積もりと計画が可能なプロジェクトの遂行に力を集中する必要がある。一般的に、これは多少の変更を加えながら同じシステムを繰り返しリリースすることを意味する。しかし、独創性を要するのが成功したプロジェクトだと定義するならば、最初の基準を満たせると見込むのは理にかなわない。むしろ2列目の要件を満たすこと、つまり関係者(ユーザー、所有者、そして出資者)が必要とする価値とバランスを提供することに務めるべきだ。そして、成功は計画をいかに忠実に守ったかではなく、結果として誕生したシステムの価値で判断するのだ。
もし詳細な計画を立てるのが不可能ならば、作業ベースから結果ベースの開発へとそれとなく移行する必要がある。つまり、計画された作業が遂行されたかどうかを見守ることから、プロジェクトの目標達成を確認することへと管理者の役割が変わることになる。プロジェクトが進むにつれ、フォーカスは作業の完了ではなく不確実性の低減へと移っていくのだ。
ライフサイクルのマイルストーン選択にも同じフォーカスを反映する必要がある。Rational Unified Process(RUP)のライフサイクル(図1)では、4つのフェイズで不確実性の排除にフォーカスし、リスクの排除で関係者の同意を実現している(注6)。最初の「開始」フェイズでは問題空間にフォーカスしており、実現すべきシステム、対応範囲、対話部分、サービスなどを決める。このフェイズはシステムの内容について、すべての関係者が同意した時点で完了となる。次の「詳述」フェイズでは、関係者のニーズを十分に満たす堅牢なアーキテクチャの開発にフォーカスする。3つ目の「構築」フェイズでは、リリースを成功させるべくリスクを排除するようシステムを徐々に構築することにフォーカスする。このフェイズは繰り返すたびに機能が増え、より多くのシステムテストに合格するようになる。4つ目の「移行」フェイズは、現場へのリリースに成功した時点で完了する。
結果ベースの開発実現に向けて、このライフサイクルモデルを提供する際には次のような重要なガイドラインがある。
ではガイドラインを簡単に見てみよう。
必要なことはすべて行う:このライフサイクルモデルでは、チームが各フェイズで1つの作業に専念するのではなく、関係者の目的達成を目指して必要な要求分析、アーキテクチャ、インプリメンテーション、そしてテストを組み合わせて実践する。この適切な組み合わせはプロジェクトによって異なる。例えば、人間/システムの対話モデルの合否をテストするために、チームが「開始」部分でシステムのバージョンを1つ構築するプロジェクトなどもある。そして、「詳述」ではアーキテクチャが適切でパフォーマンス目標を達成していることを証明するために、バージョンを1つ構築する場合もある。「構築」では統合とテストを実施しながらシステムを徐々に導入していく。このやり方は、可能な限り早い段階で技術的なリスクを排除し、コンテンツに優先順位を付けるメカニズムを実現してくれる。
広く浅く行う:各フェイズは、システム要求デザインの詳細を修正することで完了となるわけではない。100%の完成度と精度を目指そうとするとコストがかかるし、パレートの法則(得られる恩恵の最後の20%に労力の80%がつぎ込まれる)と衝突する。さらに、100%の完成度と精度を目指そうとすると、精度に対する誤った印象が生まれてしまう。プロセスの後半では排除するのが困難でコストもかかる多くの不具合をデベロッパが持ち込んでしまう可能性が高いのだ。プロジェクト関連ドキュメントの大半は当初理解していた部分については詳述するが、プロジェクト全体の範囲についてはあまり詳述しないことが多いなど、実際は詳述するレベルがバラバラだ。プロセスライフサイクルの目標を達成するには、そのプロジェクトがカバーする範囲とアーキテクチャについて、関係者の同意を得る必要がある。可能な限り正確を期すことは重要だが、ほどほどの精度に抑えることも重要である。
プロジェクトを正しく導く:プロジェクトの展開に合わせて不確実性が排除され、情報が増える。チームは関係者のニーズをもっと理解するようになって技術的リスクを明らかにし、低減するようになり、結果を出す力が適切に修正されてくる。この情報が増えれば、プロジェクトマネージャはプロジェクトの作業を詳細に掘り下げ、最終的に関係者が満足するよう、作業を見直してリソースを割り当てることが可能になる。
結果を管理する:プロジェクトの進行に合わせて作業が調整されれば、作業の計画、トラッキング、そして管理にはあまり意味がない。その代わり、プロジェクトマネージャは機能するコード、検査/承認済みのアーキテクチャ、そして関係者の同意という、望まれる結果の実現にフォーカスしていなくてはならない。このフォーカスは作業階層構造や出来高方法論など、プロジェクト管理のすべての成果物に反映されていなければならない。
われわれは、ソフトウェア開発の管理分野での経験に基づき、プロジェクトが大きく複雑なものになると、チーム内だけでなく、関係者とプロジェクトチーム間のコミュニケーション処理が非常に重要になることを知っている。一般的に、コミュニケーション関連の負担はプロジェクト規模の増加以上の伸びを見せる(注7)。最も重要なのは適切な量のコミュニケーションを維持することだ。優れた判断を下し、全員に同じように理解してもらえるだけのコミュニケーションを取りたいが、作業の大半をコミュニケーションが占めるようではいけない。
カギとなるのは、関係者のニーズを満たし、判断を文書化するための方法について推論できる状況を作り出すシステムアーキテクチャを開発し、維持することだ。アーキテクチャは新しい概念ではないが、そこには新たな問題点がいくつかある。現在のやり方では、アーキテクチャは物理もしくはステートマシンのいずれかの見方がほとんどだ。物理マシンの場合は、アーキテクチャは一連の物理的リソースもしくは集合だと見なされ、ソフトウェアはハードウェアの範囲で判断される。ステートマシンのケースでは、アーキテクチャはオブジェクトのクラスか、そのコードがハードウェアに導入されるUnified Modeling Language(UML)のサブシステムとしてみられる。実際には、どちらの見方(そしてほかの見方)でもシステムの本質と、懸念を排除する方法を見抜くことができる。異なる品質問題や技術的リスクへの対応には異なる見方をすることができるのだ。現在では、この統一アーキテクチャフレームワークの基盤としてUMLの利用を推進する活動が展開されている。ラショナルソフトウェアでは、このようなUMLベースのフレームワークを提供するRational Unified Process for Systems Engineering(RUP SE)(注8)向けの拡張機能開発に向けて顧客との協力を進めている。
このアーキテクチャは、一度開発されれば開発プロセス全体を通じて維持され発展し、数多くの機能を提供する。例えば、これならばチームがデザイン全体の整合性を維持しながら設計とエンジニアリングの作業を同時に進められるよう開発を分割できるようになる。さらに、別のチームがシステムを再度ホスティングしたり、機能を追加できるようにしてくれる知的財産の提供も可能だ。また、プロジェクトの初期段階で技術およびコンテンツのリスクを低下させる反復計画を立てる基盤の役割も担うことができる。
先に述べたように、現代の問題には現代のソリューションが必要だ。この10年でシステム開発のリーダーたちが直面する問題は変化したが、ソフトウェア開発を長年悩ませてきたものと同じ固有の不確実性は今日のシステム開発プロジェクトにもある。それ故に、大規模なソフトウェアの管理で学んだ管理の最優良事例を取り入れることは、現代のシステム開発が抱える課題の克服に効果的かもしれない。RUPにはこれらの最優良事例が組み込まれており、適応させるためのサポートと指標を提供する。
Copyright © ITmedia, Inc. All Rights Reserved.