ObjectSquare [2005 年 7 月号]

[技術講座]


UMLや反復型のソフトウェア開発プロセスを大規模開発へ導入する


正木威寛 PMP

※本稿は、技術評論社刊『UML PRESS Vol.3』に掲載された記事「不安一掃! これでこわくないプロジェクトへのUMLとプロセスの導入 : UMLや開発プロセスを大規模開発へどう導入すべきか」を加筆、修正したものです。UML PRESS 編集部の了承を得たうえで転載しています。

※一切の転載をお断りします。


はじめに

最近、私の勤めるオージス総研では、1000人月を超えるような大規模プロジェクトに、UMLや反復型のソフトウェア開発プロセスを導入し、実践できるようにサポートしてほしいというお客様の依頼がとても多くなりました。
一方で、このような大規模な開発では、それまでの評価プロジェクトや小規模な案件での"とりあえずUMLを使っています"というソフトウェア開発ではもはや対応できないという場合もあります。

大規模な開発のプロジェクトでは、複数のソフトウェア開発ベンダーが参加することや、UMLやオブジェクト指向が初めてというエンジニアの方が参加することも珍しくありません。またプロジェクトスポンサーや企業の上層部からトップダウンで、コンポーネントの再利用や、反復型の開発によるリスク対応、徹底したプロジェクト管理が要求されるケースも少なくありません。

ここでは、そのような大規模開発へUMLや反復型のソフトウェア開発プロセスを導入する過程で、プロジェクトスポンサーや、プロジェクトマネジャーの方から多く寄せられるご質問を、FAQとしてまとめました。

FAQ

Q:プロジェクトが大規模になるとソフトウェア開発プロセスはどのような点が異なりますか?

A:

大規模になるほど

と言えます。ソフトウェア開発プロセスはこのような条件に対応するために次のような要求を満たす必要があります。

1) わかりやすい開発プロセス

オブジェクト指向に精通したエンジニアだけではなく、いろいろな経歴のエンジニアにも理解していただく必要があります。また会社の異なるエンジニアの方にも理解していただく必要があります。UMLの入門書に紹介されていない表記や、難解な作業はできるだけ避けるべきです。

2) 作業、成果物、完了基準の明快さ

規模が大きくなるほどプロジェクト管理が徹底します。私が先日まで参加していた大規模プロジェクトでは、PMBOK 注 1) に沿ったプロジェクト管理をせよという要求がプロジェクトにありました。徹底したプロジェクト管理に対応するには、ソフトウェア開発プロセスで定義する作業、成果物、完了基準が明快で管理可能でなければいけません。

3) プロジェクトメンバーへの展開

プロジェクトのメンバー全員に浸透するように、なるべく時間もコストをかけずに、UMLなどの前提知識のトレーニング、ソフトウェア開発プロセス実践時のサポート役であるプロセスメンターの配置など、教育の機会を用意する必要があります。教える人や書籍などの情報源のない独自性の強い開発プロセスは、どんなに優れていても自分たちでトレーニングを開発したり、プロセスメンターの養成も行わなければならなくなります。

注 1) PMBOK(Project Management Body of Knowledge)
プロジェクトマネジメント協会(PMI)の策定したプロジェクトマネジメントの知識エリア

Q:どのような体制やスケジュールで導入を進めればよいですか?

A:

反復型の開発をする場合は、作業手順や成果物のガイドライン類を、タイムリーにプロジェクトに導入できるように体制やスケジュールを工夫する必要があります。私の経験では図1のように、プロジェクト管理を中心に、開発プロセス策定、開発環境構築、ソフトウェアアーキテクチャの4チームに手分けして進めることをお勧めします。

図1
図1

プロジェクト管理チームで定義する要求管理計画、品質管理計画などは、開発プロセス策定のインプットであり、ソフトウェア開発プロセスの作業やドキュメントなどの成果物はそれらに適合するように定義する必要があります。一方、開発プロセス策定チームで定義した作業や成果物は、プロジェクト管理計画に反映します。

開発プロセス策定チームが策定するソフトウェア開発プロセスでは、作成するモデルとドキュメントの様式までを定義します。これらをどのようなツールで、どのような操作手順で作成し、公式なレビューのためにどのような書式で出力するかは、開発環境構築チームが定義します。開発環境構築チームは、ツールの使いやすさや安定性と、プロジェクト管理の変更管理や構成管理からの要求事項を考慮し、開発環境の選定、導入、管理を行います。

設計/実装のメカニズムはソフトウェアアーキテクチャによって決定されますので、設計/実装のテクニカルなガイドライン類は、ソフトウェアアーキテクチャチームで作成します。プログラミング言語がプロジェクトの制約としてあらかじめ決定している場合は、コーディング規約などを開発プロセス策定チームが代行することもあります。

このように分業し、依存関係をうまくコントロールすると、ツールの決定やソフトウェアアーキテクチャの決定に左右されることなく、先行してソフトウェア開発プロセスの説明会やトレーニングを開催し、いち早くソフトウェア開発プロセスの考えをプロジェクトメンバーに理解していただくことができます。(図2)

図2
図2

Q:今度のUMLを使ったソフトウェア開発プロセスの策定作業は、
①自社にある構造化分析設計のソフトウェア開発プロセスを改造するのか、
②それまでの開発プロセスを捨てて新規にUMLに対応した独自のプロセスを策定するのか、
③RUPなど市販のソフトウェア開発プロセスを導入するのか
迷っています。それぞれのアプローチの特徴を教えてください。

A:

質問の3つのUML導入戦略を絵にしたのが図3です。

図3
図3

①は、策定メンバーが既存のソフトウェア開発プロセスをよく知っている人と、オブジェクト指向やUMLのソフトウェア開発プロセスをよく知っている人が異なる時、意見がなかなかまとまらず長い議論や対立が起こることがあります。その結果、プロジェクトが必要とする時に間に合わないというような事例もあります。このアプローチで策定する場合は、両方のプロセスをよく知っている人物を、策定の責任者に据えることを検討してください。また、ソフトウェア開発プロセスとしての一貫性を失わないようにすることや、重複するような作業やドキュメントを含めてしまわないように注意してください。

②は、基準とするソフトウェア開発プロセスがまったくないままに策定メンバーの経験や知識だけで新たに策定するアプローチと、既存のオブジェクト指向のソフトウェア開発プロセスを基準として修整 注 2) しながら進めるアプローチに分けられます。 前者のアプローチの場合、オブジェクト指向のソフトウェア開発プロセスといっても、すでに古典からXPやアジャイルまで様々ですので、①と同様に議論が長引くことがあります。また、①と異なり再利用できるものが何もないので、策定にかかる時間やコストがアプローチの中で最も必要となります。したがって、特定のプロジェクト中に迅速に策定することは難しいと言えます。

一方で後者のアプローチは、オージス総研のような外部の会社がすでに実践しているソフトウェア開発プロセスなど、特定のプロセスを基準に決め、それをプロジェクトに合うように修整を加え、開発手順やガイドラインなど必要なドキュメンテーションをしていきます。
メリットとしては、

といったことがあり、オージス総研が策定を請け負う場合も、このアプローチが最も多くお勧めします。以前は基準にするソフトウェア開発プロセスが、独自性の強いものを使うこともあったのですが、現在は

ということから、書籍で入手可能なものを基準とするようにしています。また策定のためのプロセスやツール、開発手順書やガイドラインなどのドキュメント類も再利用するようにしています。

注意点としては、プロジェクトのニーズによってソフトウェア開発ライフサイクルの最初から最後まですべて置き換えるのではなく、要求から実装など事前に置き換える範囲を決めて入れ替える場合もあることです。この場合も、基準はあくまで導入するソフトウェア開発プロセスです。

③は、②の後者のメリットに加え、豊富に提供されるドキュメントを再利用できますが、プロジェクトの人数に応じてライセンス費用がかかりますので、大規模開発では数百万〜数千万円の費用になります。通常のソフトウェアの購入と同様に、まず本格的に導入を決定される前に、1本購入するか評価版を入手し、提供されるドキュメントを実際に読んでみて本当に自分たちが理解できる内容か、ご検討されることをお勧めします。また、提供されている開発手順やガイドラインから、プロジェクトに必要な部分を選んでプロジェクトで利用していくことになりますが、まったく知らない人がその選択をすることは難しいですので、その詳細を知っている人を策定メンバーに加えたほうが安全です。

注 2) このように開発プロセスをプロジェクトに合うように修整することを、テーラリング(Tailoring)と言います。昔あったスーツの仕立屋さんの「テーラー××」のテーラーと同じです。

Q:プロジェクトが開始し、ソフトウェア開発プロセスを策定する前にすでに要求定義が開始しています。大丈夫でしょうか?

A:

プロジェクトが始まると、プロジェクトスポンサーなど利害関係者にプロジェクトが進んでいることを示すために、すぐに要求定義を開始するケースも少なくありません。この場合、要求定義に関する作業が既存の開発プロセスに沿って実施され、策定する次の工程と調整がとれていればよいのですが、ソフトウェア開発プロセスが不在のまま開始してしまうプロジェクトもあります。このようなプロジェクトでは、要求定義の成果物や完了条件も規定されていない状態ですので、それぞれ思い思いの要求定義プロセスを実行していることもあります。このまま要求定義を進めると、後で大きな手戻りや混乱を引き起こすことになりかねません。まず実施している要求定義とこれから策定するソフトウェア開発プロセスとの境界となる成果物を明らかにしてください

Q:いろいろな部署や協力会社からエンジニアを増員していくと、「UMLを使うと自分の仕事ができない」という声が出てきました。何が問題でしょうか?

A:

私の参画したプロジェクトでもありましたが、参加するエンジニアの方へ、このプロジェクトの前提条件として「UMLの利用」がよく認識されていないケースで起こります。このような変化を望まない動きに対しては、プロジェクトへの要求事項として開発構想書、協力会社に対してであればRFP 注 3) に明文化し確実に伝えておくことです。そうしなければなし崩し的に、従来のやり方に戻ってしまうことがあります。また、勉強会やプロセスメンターの参加など、UMLの利用に対してプロジェクト計画がよく練られていることを早く示して、変化を望まない方に安心していただくことも大事です。

注 3) RFP(Request for Proposal:提案依頼書)
協力会社に正式に提案を依頼するために、依頼事項や契約条件を文書にしたもの。協力会社は、RFPに沿って提案書(プロポーザル)を作成し、提案します。

失敗事例1)

Javaを使った大規模なシステム開発を受注したA社へ、UMLを使ったオブジェクト指向の開発プロセスを導入する役割でお手伝いすることになり、半月ほどUMLを使った開発プロセスの説明をしました。ではオブジェクト指向でやりましょうということで、A社はB社からエンジニアの増員をしました。オブジェクト指向を推進されているプロジェクトリーダーの方が不在だったある日、B社の考えたソフトウェアアーキテクチャの候補を検討する会議がありました。話を聞いているうちに、どうもオブジェクト指向という感じではなかったので、確認してみるとオブジェクト指向ではなく、自分たちのやり慣れた手法で考えているとのことでした。そして、その会議の終わりには私以外のメンバー全員でオブジェクト指向では開発しないという合意がされました。私はその日でお役ご免となり、2か月ほどたったある日、再び相談があるとのことで訪問しました。例の会議の後、オブジェクト指向で開発しない方向で進めていたのですが、最近プロジェクトスポンサーであるユーザー企業から、「オブジェクト指向で開発することがプロジェクトの条件であるのに、なぜそうしないのか」というクレームがあったとのことです。プロジェクトはオブジェクト指向での開発でやり直すことになりました。このプロジェクトは、オブジェクト指向やUMLで開発することがプロジェクトスポンサーからの条件であることの周知を怠ったために約2か月を失ったのです。

失敗事例2)

J2EEを使った中規模のシステムを、プロジェクトスポンサーであるC社、協力会社のオージス総研とD社の3社で開発することになりました。直前までC社ではUMLとJ2EEを使ったオブジェクト指向のパイロットプロジェクトを我々と行っていましたので、C社と我々はその延長でUMLを使ったオブジェクト指向の開発をするつもりでいたのですが、開発プロセスや開発規約を話し合ううちに、D社はUMLを使うことも含めて、オブジェクト指向では開発をする気がないことがわかりました。結局、D社も我々も譲れない状況になってしまい、C社と我々だけがUMLも使ったオブジェクト指向で開発し、D社は、その会社の開発プロセスや開発規約で開発することになりました。我々も反省すべき点があるものの、このように他社の見積もりや計画が了承された後に、開発プロセスを転換してもらおうとしても難しいです。必ずRFPや開発構想に明記することが、このような無駄な混乱を避ける最良の方法です。

Q:ソフトウェア開発プロセスの策定を進める上でコツはありますか?

A:

ソフトウェア開発プロセスを策定するプロセスも、ソフトウェアの開発のように反復型のタイムボックス開発で行うことを強くお勧めします。結局の所、そのプロジェクトにピッタリ合った開発プロセスかどうかは、使わずにいくら議論してもわかりません。それよりも開発プロセスが必要な時に間に合わせ、実際に使っていただいて、エンジニアの方とプロジェクト管理の方からフィードバックを得て改良していくことです。そのために期限(タイムボックス)を設定し、テクニカルライターが記述のグレードをコントロールしながら、期限に必ず完成するようにします。(図4)

図4
図4

承認レビューであがった指摘事項も、すべて修正するのではなく、内容によってはバックログに記録し、承認済みの完成した開発手順書やガイドラインをコンスタントにリリースしていきます。ここで重要なのは「作りかけ」ではなく、承認済みの完成した開発手順書やガイドラインなどの成果物をリリースし、現場で早く評価していただくことです。注意点としては策定の最初に、承認者の方にも反復型のタイムボックス開発で進めることを合意していただくことです。私は、タイムボックスを2週間(10営業日)にして反復しています。以上のように、早期にベースラインを確定し、実践の結果をフィードバックしていくやり方は、反復型のソフトウェア開発とまったく同じです。

失敗事例3)

E社では、今後予定されている複数の大規模開発に使用するUMLを使ったソフトウェア開発プロセスを策定することになりました。策定が始まったものの、内容を検討する会議やその指摘事項の修正が多く、策定計画からたびたび遅延を起こしました。その結果、何か月たっても作成したドキュメントが、どれ一つ完成した状態ではありませんでした。また予定されていたプロジェクトに必要な時期にも結局間に合いませんでした。 このプロジェクトの問題は、開発プロセスの策定にタイムボックス開発をしていないことで、納得のいくまで議論と修正を繰り替えしていることでした。タイムボックス開発で策定した場合と比較すると、このプロジェクトではまだ完成していないにもかかわらず、期間が2倍、策定要員が2倍、コストが約4倍かかっていました。

Q:現行システムの再構築ですが、入手できるのは現行システムのソースコードだけで、保守された設計書がありません。ソフトウェア開発プロセスとしてどのように進めるようにすればよいでしょうか?

A:

開発のインプットとなるはずの現行システムの成果物をそろえることと、ソフトウェア開発プロセスは別に考えたほうが、プロセスの一貫性を崩さずに策定できます。 データベースなども含めてまったくの新規であれば、現行の担当者をプロジェクトメンバーに含め、現行の業務マニュアルなどを参考にトップダウンで開発し、現行のプログラムから仕様書をリバースしないで開発するやり方もあります。現行のソースコードは、小さなビジネスルールを棚卸しするには参考になることもありますが、現行のソースコードはあくまで、現行のプログラミング言語、現行のソフトウェアアーキテクチャに依存しているものですので、新システムの開発担当者がビジネスルールを読み取るのは非常に難しいようです。
現行システムのプログラムから仕様書をリバースするのであれば、現行システムの開発担当者に今回のソフトウェア開発プロセスをある程度理解していただき、ソフトウェア開発プロセスが必要とすることだけを拾い出し文書化してもらう方法もあります。 私が参画した大規模開発では、現行システムの担当者がソースコードから、ソフトウェア開発プロセスへのインプットとなる仕様書をリバースする専任のチームを組織したケースもあります。

Q:これまでデータベースについては、プロジェクト内に選任のデータベースチームを組織し、テーブルの設計やチューニングをしていました。今度の開発もそのような体制でよいのでしょうか?

A:

UMLを含むオブジェクト指向や"アーキテクチャ中心"の開発プロセスが浸透していないプロジェクトで、分析での概念的なクラスの定義や、設計での永続化のメカニズムを加えた設計クラスを定義する作業と、データベースのテーブル設計を独立してしまうと、うまくいかないケースが多いようです。このような体制の場合、オブジェクト指向の開発をよく知らないデータベースチームの担当者は、リレーショナルデータベース関連だけは、オブジェクト指向ではない従来のやり方が許されていると感じてしまうようです。

図5
図5

私の経験では、図5の下側のような体制をお勧めします。E−R図で作成していたような、論理モデルは分析モデルで代用可能ですし、データモデラーのモデリングに関する専門的なスキルはエンティティクラスのモデリングに役立ちますので、データモデラーはエンティティクラスのモデリングを担当するアプリケーションのチームに所属するようにします。また、エンティティクラスに対して、データベース上の物理テーブルの構造や設計クラスからのO−Rマッピングの指針も含めて、永続化のメカニズムを検討するのはソフトウェアアーキテクトです。テーブルや表領域のチューニングの専門的な知識があるデータベースエンジニアのスキルは、ソフトウェアアーキテクチャを考える上で必要ですので、ソフトウェアアーキテクチャチームに所属するようにします。

失敗事例4)

J2EEを使った中規模のシステムを、プロジェクトスポンサーであるF社と、協力会社であるオージス総研、アプリケーション開発だけでなくH/W、アプリケーションサーバー、DBMSも販売しているG社の3社で開発することになりました。G社は、販売しているDBMSを専門的にやっているデータベースエンジニアを用意できるとのことから、データベースチームとして、このシステムすべてのテーブルの設計を担当することになりました。ところが開発が進んだある日、アプリケーションチーム側で定義している分析クラスや設計クラスをまったく無視したテーブルの構造になっていることが判明しました。担当したG社のエンジニアにはオブジェクト指向も"アーキテクチャ中心“の開発も経験がなく、それまでに経験したC/Sのシステムを開発していたころと同じつもりで、オブジェクトの構造やソフトウェアアーキテクチャを無視して、独自に非正規化をしてしまっていたのです。

Q:ビジネスモデリング、ユースケースモデリング、分析モデリングなどを担当するエンジニアには、対象業務の業界(ドメイン)知識がありません。モデリングの作業だけでは業務を理解できそうもないのですが、ソフトウェア開発プロセスとして不十分ではありませんか?

A:

通常、ソフトウェア開発プロセスでは、対象業務のソフトウェアへの要求を獲得し、ソフトウェアで実現するまでの作業が定義されますが、業界をまったく知らないエンジニアが、アナリストや要求定義者などの役割に必要とされる前提知識(ここでは業界の知識)を得るための作業は含めません。
もしそれを含めると、担当者と役割に求められる前提知識とのギャップはそれぞれ異なるものですので、ソフトウェア開発プロセスが複雑化し、担当者によっては無駄な作業が含まれてしまうケースがあります。それよりもソフトウェア開発と平行し、業界に関する勉強会など育成計画を立てるようにします。

Q:レビューワである利害関係者がオブジェクト指向やUMLを知らないので、エンジニアが使う概念モデルや分析モデルのドキュメントを、従来の手法のドキュメントに似たものにしてほしいと言われました。どうすればよいでしょうか?

A:

構造化分析設計などの手法で以前から用いているドキュメント書式を、そのままオブジェクト指向の開発で無理に用いることや、UMLのドキュメントを構造化分析設計のドキュメント書式に平行して書き換えてゆくコストより、利害関係者へのUMLの勉強会など、プロジェクトとして利害関係者への教育を計画したほうがはるかにコストはかかりません。(図6)

図6
図6

また、それによって作られるソフトウェアの品質についてもリスクがあります。ただし、利害関係者に経営層も含まれる時など、どうしても従来のドキュメントと同じでなければならないケースもあります。そのような場合は、プロジェクトスポンサーに、リスク、コスト、手間を考慮した上で、それでもやるのか判断してもらうしかありません。

おわりに

みなさんが実際にUMLを使って開発をされると、ここで紹介させていいただいたFAQ以外にも、まだまだいろいろな疑問が出てくると思います。そのような疑問や解決策は必ず記録し、会社や部署のUMLのガイドラインとして蓄積していくことをお勧めします。



© 2005 正木威寛
HOME HOME TOP オブジェクトの広場 TOP