|
[2006 年 5 月号] |
［技術講座］
正木威寛，山内奈央子
※本稿は、株式会社アイ・ディー・ジー・ジャパン発行の 『ITアーキテクト vol.1』に掲載された「開発プロセスの最適化手法」の元原稿をITアーキテクト編集部の許諾を得て公開したものです。
※一切の転載をお断りします。
筆者らが、オージス総研で「オージステーラリングサービス」という開発プロセスのコンサルティングサービスを行う中で、ユーザー企業の情報システム部門のお客様からは「開発委託先が何をやっているのかわからない」という相談をよく受ける。一方、SIerやソフトハウスのお客様からは「Javaにも慣れたがソフトウェアの品質が一向によくならない」といった相談もよく受ける。どちらも開発組織に明文化された開発プロセスが無いことが原因で、プロジェクトの利害関係者から開発側の活動が見えなくなったり、開発側の品質の改善が進まなくなったりしていることが多い。また「以前、市販の開発プロセスを導入したが大変すぎて使用するのをやめた」ということもよく聞く。これは開発組織に最適化された開発プロセスではないことや、開発組織への開発プロセス導入の進め方に問題あることが多い。
本稿では、開発組織における開発プロセスの位置づけを理解し、どのようにして開発プロセスを開発組織に最適化すればよいのか、開発組織への開発プロセスの導入をどのように進めればよいのかを理解していく。
開発プロセスを最適化するには、開発組織における開発プロセスの位置づけや目的を理解しておく必要がある。開発プロセスは、単に開発者だけのものとして最適化するのではなく、利害関係者も意識した上で最適化を進める必要があるからだ。ここでは、この開発プロセスの開発組織における位置づけと目的を理解していく。
筆者がＩＴ業界に入った８０年代、筆者の在籍していた会社には「ソフトウェア工場」なる施設があった。これはソフトウェア開発を、製造業における工場のラインのように決まった製造プロセスで、１０人が１通りのコードに到達できることを目指し、安く、早く、高品質なソフトウェアを作ろうとした試みであった。残念ながら製造業のラインは、同じ製品をいくつも製造するプロセスであり、製品の設計にあたるソフトウェア開発を当てはめるのはそもそも間違いであったのだが、現在でも「開発プロセスを規定し明文化する」ということが、開発プロセスに沿って開発すれば１０人が１通りのコードに到達できるように目指すことと誤解している方に出会うことがある。このような方には、開発プロセスを規定することに対して否定派、肯定派の両タイプあり、否定派は先に説明したような間違いを挙げ、それゆえに開発プロセスを明文化することよりも、人によってのみソフトウェア開発は改善されると主張する。肯定派は８０年代までの試みと同じく、ソフトウェアの構造やアーキテクチャの選択からループの書き方まで定義しなければ意味が無いと主張する。
否定派には、開発あるいは開発プロセスは開発者だけでのもので、開発者の目線だけで開発を改善しようという考えが根底にある。そのように考える前に、まず企業が行うシステム開発とその利害関係者について理解する必要がある。企業が開発プロジェクトを立ち上げると、そこには費用を提供するプロジェクトオーナー、できたシステムを利用するユーザー、プロジェクトに参加する協力会社やベンダーなど多彩な利害関係者が関係する。詳細は後述するが、企業のシステム開発では、このような利害関係者から見てプロジェクトが今どのような状況で、次にどのようなことをやろうとしていて、自分たちがどのように係わるのか明文化されていなければならない。
ちょうどプロスポーツの競技ルールを思い浮かべると良いだろう。たとえばプロ野球では、プレイヤーだけではなく、審判、観客、視聴者と競技ルールによってゲームの進行に共通の認識が持たれている。競技ルールやゲームの進行が共有されているからこそ審判は特定の試合に依存しない公平な判定ができるし、観客はお金を払って観戦するし、視聴者はテレビ中継をちょっと見ただけで試合の状況がわかる。草野球のようにプレイヤー達の都合だけで勝手に２塁ベースを省略してみたり、試合を６回で終わりにしてみたりにはできないのである。
図 1-1 草野球
図 1-2 プロ野球
肯定派には、開発者から“エンジニアリング”、つまりどのような設計が適切か、どのようなプログラムが効率的かということに知恵を絞る行為を奪い、単に工業用ロボットのように規定したとおりに振る舞わせるべきという考えが根底にある。だが、そのような場で開発を強いられる開発者に生産的な考えは沸かないであろうし、今の技術革新に追従して規定した開発プロセスをメンテナンスしていくには多くのコストがかかるであろう。これもプロスポーツの競技ルールを思い浮かべるとよいだろう。プロ野球の競技ルールは、バットのスイングやボールのキャッチの仕方まで規定はしない。それは開発者におけるエンジニアリングと同様に、選手が工夫すべきことであるからである。開発者の“エンジニアリング”の余地を残しつつ利害関係者の要求を満たす最低限必要な範囲で規定し、明文化すべきである。詳細は次節で述べる。
本節では、開発プロセスを最適化するにあたって、開発プロセスを規定し、明文化することのメリットを確認する。
プロジェクトに参加する開発者にとって、そこに明文化された開発プロセスがあるということは、システム開発やソフトウェア開発を進める上で、どのような作業が必要で、それらの作業のインプットが何で、アウトプットが何かを事前に学ぶことができ、特に経験の浅い開発者にとっては自分がこれから何をするのかを知る拠り所となる。
だが前節で述べたとおり開発プロセスは、開発者の“エンジニアリング”の余地を残しつつ利害関係者の要求を満たす最低限必要な範囲で規定すべきである。では、どのように開発プロセスを文書化すれば良いのかというと、ガイドラインとして規定している部分と、入門者への例としての作業ステップの説明とを文書として明確に区別して示すことである。
実際の開発では、いつも同じプロジェクトメンバー、同じ利害関係者というわけではなく、何社もの協力会社が参加することもあるし、プロジェクトごとにユーザーの代表などの利害関係者が異なる。このような時に明文化された開発プロセスは、プロジェクトがこれから何を行っていくのかについて共通の理解を得ることに寄与する。このことは、熟練した開発者で構成されるプロジェクトであっても同様だ。結局、複数の協力会社から集まったのであれば、開発プロセスに対して合意がされていないと、単に「次は要件定義だ」「次は外部設計だ」という表面的な合意で開発が進められる。しかし実際には、自社や協力会社によってそれらの言葉から連想される作業内容に差がありうまくはいかない。筆者が過去に関わったプロジェクトでも、定義された開発プロセスが無いままに何社もの協力会社が集結し、規模を拡大したがために大きな混乱となったケースがある。このように、協力会社も含む利害関係者間でのプロジェクトの作業内容に関するコミュニケーションギャップを軽減するためには、明文化された開発プロセスが必要である。この場合、協力会社の理解を円滑にするためには、国際規格などに基づいた開発プロセスを導入し、開発プロセスから方言を無くすことも必要である。最近では、インド、中国、ベトナムなど海外にアウトソーシングするケースも多い。このようなケースでは、方言の無い開発プロセスというのは特に重要になってくる。
プロジェクトマネジメントがうまくいっていないプロジェクトでは、共有された開発プロセスが存在しないことが原因となっていることがある。このようなプロジェクトでは、スケジュール、コストなどの状況報告が定期的に行われ、マネジメントが表面上は行われているが、どのような作業を行うのかプロジェクト内で共通の認識が持たれていないので、実際の計画との差異が大きく、計画外の作業も突然発生している。その時に、プロジェクトに適切なコンティンジェンシー予備も確保されていないので、結果として納期遅延やコスト超過を招くことになる。さらにはプロジェクトが、スコープ、納期、予算を変更しようと考えたとしても、これら変更の手続きについて利害関係者間で取り決めが行われていないので、利害関係者間の「言った」「言わない」論争や、変更のための長い交渉が必要になる。
プロジェクトの成熟度を測る標準としてシステム開発の分野で広く参照されているCMMIでは、組織やプロジェクトに定義された開発プロセスが尺度になっている。CMMIの詳細な説明はここでは避けるが、図 1-3 のプロセス成熟度モデルでは、レベル１の開発プロセスが何も無い組織では、場当たり的で、組織としては継続的な改善が行えないという考えに基づいている。
図 1-3 CMMIの成熟度モデル
品質は、テストなどの検証にコストをかけるよりもプロセスとして品質を作り込むほうが効率的で効果があると言われている。けれども、開発プロセスが明文化されていないプロジェクトで、不具合の発見や修正は統合テストやシステムテストに期待して、とにかく設計やプログラミングのスケジュールを見かけ上守っているプロジェクトに遭遇することがある。このようなプロジェクトのテストでは繰り返し「もぐらたたき」が行われ、致命的な不具合には「火消し」と呼ばれるスーパーエンジニアの努力によって対処が行われるのだが、このようなスーパーエンジニアはいつも調達できるとは限らないので、組織やプロジェクトはこのようなスーパーエンジニアに依存しているというリスクについて認識する必要がある。このようなリスクをできるだけ減らしたいのであれば、テストなどの検査を念入りに行うことよりも前に、「品質のばらつき」を減らすことに取り組むことが必要だ。品質のばらつきを減らすには、プロセスを明文化し、プロセスのモニタリングと是正を通してプロセスの改善を、継続的に行っていくことが必要である。
また、プロセスの明文化は、テストなどの検査の質も改善する。プロジェクトスポンサーやユーザーから納品されたソフトウェアの品質が悪いとクレームを受けているプロジェクトを目にすることがあるのだが、テスト戦略、テスト・カバレッジ、合否基準などが、品質計画書やテスト計画書などの文書によってプロジェクトで利害関係者とまったく共有されておらず、すべて現場の開発者任せとなっているケースがある。この場合、作ろうとしているソフトウェア製品に求められる品質、それにかけられるコストに適切な判断や決定の責任があるのは、プロジェクトスポンサーやユーザーの代表を含むステアリング・コミッティーであり、開発者だけでは無い。
本章では、オージス総研の開発プロセス最適化手法を元に、組織やプロジェクトに適した開発プロセスを定義する手法を、図 2-1のワークフローに沿って紹介する。開発プロセスを組織の標準として用意する場合とプロジェクトで用意する場合があるが、ここで紹介する手法はどちらにも対応する。
図 2-1 開発プロセス最適化のワークフロー
開発プロセスを最適化するための最初の作業が、最適化のベースとなる開発ライフサイクルの選択だ。開発ライフサイクルには次のような選択肢がある。
１） 自組織の開発プロセスを利用する
２） ISO12207やPMBOKなどの規格を利用する
３） 商用の開発プロセスを利用する
４） 書籍で公開されている開発プロセスを利用する
１）は、自組織に暗黙であっても繰り返し実践されている開発プロセスが存在する場合に、それを文書化する。だが現行の開発プロセスが手続き指向やDOAで、それをオブジェクト指向に仕立て直すことを考えるのであれば、開発ライフサイクルとして一貫性を維持しながら修整を加えるのは非常に難しく合意を形成するのに多くの時間がかかるのでお勧めしない。このような手法の変更も伴う場合は、他の選択肢が良い。
２）は、ISO12207やPMBOKのような広く認知された規格を利用する。この場合、ISO12207やPMBOKは作業や作業成果物は明記されていないし、特定の手法に限定していないので、それらについては自分達で具体的に定義することが必要となる。
３）は、もしこれまでとは別の手法、たとえばUMLを使ったオブジェクト指向開発など特定の手法を実践するための開発プロセスを導入するのであれば、製品として販売されている開発プロセスを利用する。オージス総研では、最適化する開発プロセスのベースとしてオテラ開発プロセスを提供している。商用の開発プロセスを利用するメリットは、すでに実践されてきた開発プロセスがすぐに手に入るので、プロセスに首尾一貫性があり、結果的に開発プロセスを安く、短期間で用意できることである。また、トレーニングやプロジェクトでのメンターリングなど実践に必要なサポートも用意されている。
４）の書籍で公開されている開発プロセスを利用する場合は、方法論やベストプラクティスの紹介が中心となっている場合もあるので、２）と同様に実践に必要な作業や作業成果物は自分達で記述しなければならない。この時にはISO12207も併用し、開発ライフルサイクルのどこで何をするのか記述していくのも有効である。
いずれの場合も採用する開発プロセスの識者が社内外から調達できるのであれば、最適化の作業に加えたほうが良い。
ソフトウェアライフサイクルプロセスは、ソフトウェアを作り、捨てるまで、すなわち、どのようなソフトウェアが必要か構想し、開発し、運用を行い、保守を行い、最終的に破棄するまでの間に、何を行わなければならないのか、といった一連のプロセスを定義したものだ。国際規格である「ISO/IEC 12207 Software life cycle process」は図 2-2のような体系で、表 2-1のように大きく３つに分類され、３つのライフサイクルプロセスは、さらに詳細に定義されている。従って、開発プロセスを策定するにあたって、自分達の組織、またはプロジェクトには、どの部分のプロセスが必要なのかを見極めるための、よい指標となるだろう。
ISOの規格は、日本規格協会（https://www.jsa.or.jp）から購入することができる。ISO12207については、英語版だけでなく、英和対訳版も販売されている。また、ISO12207は、日本工業規格（JIS）にも採用され、「JIS X 0160:1996 ソフトウェアライフサイクルプロセス」として、規格化されている。JISの場合は、日本工業標準調査会のホームページ（https://www.jisc.go.jp）から無償で閲覧可能となっている。ただし、JIS規格では現在のところISO12207の2002年と2004年の修正票は反映されていない。
図 2-2 ISO12207 ソフトウェアライフサイクルプロセスの体系
表 2-1 ISO12207 ソフトウェアライフサイクルモデルのプロセス群
| 主ライフサイクルプロセス | 主に契約や、開発、運用、保守のプロセスが含まれている。どのようなソフトウェアが必要になるのか構想する、といったアクティビティに始まり、発注者と提供者の契約のアクティビティ、構想を実現するためのソフトウェア開発プロセス、リリースされたソフトウェアの運用と保守、といった一連のプロセスが、ここに含まれている。 |
| 支援ライフサイクルプロセス | 主にソフトウェアの品質に関わるプロセスが含まれる。ソフトウェアが、設計書なども含めて、どのバージョンのどの部品で成り立っているのかを管理する構成管理のプロセスや、定められたプロセスや計画通りに開発が行われているかをチェックする品質保証のプロセス、ソフトウェアが妥当かどうかを確認するプロセスが含まれている。 |
| 組織に関するライフサイクルプロセス | プロジェクトの計画や、計画を実行した際の調整、課題解決などのマネジメントを行うプロセスが含まれる。また、開発環境の整備や、開発者への教育もこのプロセスに含まれている。 |
図 2-3 と表 2-2 は、ISO12207の開発プロセスで、V字型のモデル（V字モデル）として表される。V字の左側は、品質を作りこんでいくプロセス、すなわち要求を定義しコードを作成する流れで、V字の右側は、統合し、品質の検証を行うテストを行う流れである。破線の矢印は、対応関係を表している。たとえば、ソフトウェア要求分析で「検索系のオンライン画面のレスポンスは、４秒以内であること」という要求がある場合、これを実現できたかどうかテストするのは、｢ソフトウェアテスト｣である。
このV字モデルを含むISO12207は、システム開発に必要なアクティビティを定めているが、時系列な実行順序を表しているものではない。つまり、ウォーターフォールのようにV字を左上から逐次的に行うのか、反復型か、はたまたテストファーストか、などといったアクティビティの順序（ライフサイクルモデル）は、この規格では特定していないので、実際のプロジェクトに適用する場合には、組織や各プロジェクトで定義する必要がある。このような実行順序を表すライフサイクルモデルは、ISO12207の関連規格であるISO15271で示されている（後述）。
また、ここで言う「システム」とは、ソフトウェア、ハードウェアやネットワーク、設備、手作業で構成されるシステムを指し、「ソフトウェア」はそのシステムの一構成要素である。
図 2-3 ISO12207の開発プロセス
表 2-2 ISO12207の開発プロセス
| プロセス開始の準備 | ソフトウェアライフサイクルを定義し、文書化する。すなわち本稿のように開発プロセスをプロジェクトにあわせて策定する作業（テーラリング）を指す。また構成管理や変更管理の実施を始める。 |
| システム要求分析 | 利害関係者からの要求を、システムへの要求として明確に定義する。ビジネス上の問題や目標に対して、必要となるシステムの機能や能力を定義する。たとえば、業務フローを用いて、業務を遂行する上でどのような作業（手作業、設備、ソフトウェアでの支援を含めて）を行うのかを明らかにする。システム要求分析で定義したものは、システムテストのテストケースを作成する際のインプットとなる。 |
| システムアーキテクチャ設計 | システム要求を実現するソフトウェア、ハードウェアやネットワーク、手作業といったシステムの構成要素や、関係する外部システムが定義する。 |
| ソフトウェア要求分析 | システム要求分析とシステムアーキテクチャ設計の結果を受けて、ソフトウェアへの要求を定義する。たとえば、ユースケースを定義したり、セキュリティやパフォーマンスなどの機能外要求を定義したりするアクティビティだ。また、システムアーキテクチャ設計が、ソフトウェアを作る上で技術上の制約となる場合には、ここで定義しておく。 |
| ソフトウェア設計 | ソフトウェア要求を実現するソフトウェアの構成要素を定義する。さらにソフトウェアの構成要素であるソフトウェアユニット、コンポーネントなどそれぞれの構成要素を設計する。 |
| ソフトウェア構築 | ソフトウェア設計に従ってコーディングを行い、単体テストを実施する。単体テストを終了してもよい基準や、どのようなテストケースを作成するべきか、といった内容は、プロジェクトマネジメントで作成されるテスト計画に含まれる。 |
| ソフトウェア結合 | ソフトウェアユニットやコンポーネントなどソフトウェアの構成要素を統合し、プラットフォーム上で動くソフトウェアに統合する。Javaであれば、ビルドの作成がこれにあたる。 |
| ソフトウェアテスト | ソフトウェアへの機能や品質への要求が満たされているかを確認する。ユースケースが要求通りの機能を満たしているか、といった機能に対するテストに加え、ユーザビリティなど機能外のテストも実施する。 |
| システム結合 | ソフトウェア、ハードウェアやネットワーク、他のシステムとの接続、手作業などシステムの構成要素を統合し、システムに統合する。 |
| システムテスト | 統合されたシステムがシステム要求を満たしているか確認するテストである。ハードウェアも含め、要求が満たされているかを確認するパフォーマンステストなどは、システムテストで実施する。 |
| ソフトウェア導入 | 本番環境へソフトウェアを導入し、システムとして実行できる状態にする。 |
ISO12207では、プロジェクトマネジメントのアクティビティを「支援ライフサイクルプロセス」と「組織に関するライフサイクルプロセス」に定めているが、プロジェクトマネジメントの分野で昨今、注目を集めているものに、PMBOK（Project Management Body of Knowledge）がある。これは、アメリカの非営利団体PMI（Project Management Institute）(*1)が策定した、プロジェクトマネジメントに必要な知識を体系化したもので、米国では、米国国家規格IEEE1490として98年より採用されている。PMBOKは、プロジェクトに必要なマネジメントプロセスを表 2-3 のように９つのジャンル（知識エリア）に分けて整理されている。
(*1) 米国PMI https://www.pmi.org，PMI東京支部 https://www.pmi-tokyo.org/
表 2-3 PMBOKの知識エリア
| 知識エリア名 | 概要 |
| スコープマネジメント | システム開発の範囲に関するマネジメント |
| タイムマネジメント | 作業の順序やスケジュールに関するマネジメント |
| コストマネジメント | 見積もりや予算、資源に関するマネジメント |
| 品質マネジメント | 成果物の品質保証や品質管理に関するマネジメント |
| 人的資源マネジメント | チームや要員に関するマネジメント |
| コミュニケーションマネジメント | 情報の配布方法や、進捗管理に関するマネジメント |
| リスクマネジメント | リスクの予測や、リスクへの対応に関するマネジメント |
| 調達マネジメント | 選定や発注、契約に関するマネジメント |
| 統合マネジメント | 上記の知識エリアを統合する作業へのマネジメント |
PMBOKは、PMIにより「プロジェクトマネジメント知識体系ガイド」としてまとめられ、書籍として販売されている。第3版（2004年度版）が最新であり、日本のAmazon（https://www.amazon.co.jp）で購入することができる。Amazonで購入の際には、本の表紙に記載されている「プロジェクトマネジメント知識体系ガイド」という書籍名ではなく、「A Guide To The Project Management Body Of Knowledge: Official Japanese Translation」となっていること、洋書扱いになっていること、以上の2点に注意して探すと、簡単に見つけることができる。
適用する開発ライフサイクルのどこからどこまでが自組織やプロジェクトの範囲か確認する。開発ライフサイクルの範囲が図 2-2 のISO12207でのシステム要求分析から始まってカットオーバーまでの場合もあれば、ソフトウェア要求分析から始まってシステムテストまでの場合もある。範囲外の部分は、最適化する上での制約となるので、開発ライフサイクルの範囲の前と後について、どの組織が担当するのか、自分たちの前を担当する組織から期待する作業成果物が得られるのか、自分たちの後を担当する組織が期待している作業成果物を渡せるのかを確認する。
ライフサイクルモデルは開発ライフサイクルの進め方で、もっとも代表的なモデルがウォーターフォールモデルである。ISO15271では３種類のモデルが紹介されており、この内の一つがウォーターフォールモデル、残りが反復型の開発で用いられるモデルである。
ライフサイクルモデルは、プロジェクトの制約やリスク（後述）に応じてプロジェクトの実行時に決定するほうが良いが、現実的には自組織における開発ライフサイクルの範囲の前と後を担当する組織もそのライフサイクルモデルの影響を受けるので、予め選択可能なライフサイクルモデルを検討しておいたほうが良い。反復型開発を適用する際にしばしば障害となるのは、ソフトウェア要求に関係するユーザーや、インフラを調達する部署の同意を得られないことである。この場合はプロジェクトの制約としてライフサイクルモデルをウォーターフォールモデルに限定することになる。
「ISO/IEC TR 15271:1998 Guide for ISO/IEC 12207(Software Life Cycle Processes)」では、３つのライフサイクルモデル（ウォーターフォール、エヴォリューショナリ、インクリメンタル）とその組み合わせ（ハイブリッド）を紹介している。これらのライフサイクルモデルは、どれが悪くてどれが良い、と言えるものではない。それぞれの特徴を理解すること、そしてプロジェクトの性質を見極めた上でライフサイクルモデルを選択することが、プロジェクトに最適なライフサイクルモデルを適用するポイントとなる。
もっとも一般的なライフサイクルモデルであるウォーターフォールモデルは、たとえば図 2-4 のようにISO12207の開発プロセスのV字モデルの左上からV字をなぞるように逐次的に、１回ずつ行うアプローチである。前のアクティビティに後戻りすることがないよう、各中間成果物をすべてチェックを行いながら、進めていく。ウォーターフォールモデルでは、要求事項がはっきりしない場合や、資金や人的資源が不十分で一度に開発できない場合には適していないが、極端に短い期間で開発を行う場合や、システムを一度に納品する場合に適している。
図 2-4 ウォーターフォールモデル
エヴォリューショナリ（進展的）モデルは、前述のウォーターフォールモデルのように一度だけ行うのではなく、開発プロセスの一連のアクティビティを複数回行う反復型のモデルである。要求に従ってソフトウェアを作成し、出来栄えを評価する。その結果改訂された要求に従って作成し、また出来栄えを評価する、、、というように、要求事項やソフトウェアを改訂しながら反復を繰り返し、ユーザーが本当に求めている要求に近づけていくといった特徴を持つ。エヴォリューショナリモデルでは、ユーザーの要求が発散してしまいソフトウェアがいつまでたっても完成しないリスクがある。一方で、要求やソフトウェアの仕様に対して妥当性であるという確信が持てない場合に、繰り返して評価することで精度の高い要求や妥当なソフトウェア仕様に到達できるメリットがある。
図 2-5 エヴォリューショナリモデル
インクリメンタル（漸進的）モデルも、エヴォリューショナリモデルと同様、反復型と言われるモデルである。これは、要求を全部一度に実現するのではなく、複数に分割し、順次実現していくアプローチをとる。たとえば、要求が全部で10個ある場合、1回目の反復で3個、2回目の反復で3個、3回目の反復で4個、といった進め方となる。一見ウォーターフォールモデルを適用しているプロジェクトであっても、段階リリースを行うような開発は、実際にはインクリメンタルモデルである。インクリメンタルモデルでは、ウォーターフォールモデルのプロジェクトよりも小規模で開発期間は長くなるので、要求の変化に対するリスクは高く、同時に全部の機能を納品しなければならない場合には向いていない。一方、早期にそのシステムを使ったビジネスを開始しなければならない場合や、プロジェクトの規模よりも遥かに大きなシステムの場合に、ユーザーにとって早期に必要なものとそうでないもので、段階的に開発できるというメリットがある。
図 2-6 インクリメンタルモデル
以上、３つのライフサイクルモデルを挙げたが、実際はこれだけではなく、組み合わせることも可能だ。反復型のアプローチを採用する場合には、プロジェクトの初期、すなわち、あいまいな要求や利用する技術に試行錯誤が必要な時期にはエヴォリューショナリを用い、要求も明確になり技術リスクが取り除かれた後はインクリメンタルで進めるといったハイブリッドの反復型にすることもできる。
それぞれの作業に担当する役割を割り当てる。役割は兼務が可能なので、細かく定義しても良いがあまり多いと開発の現場では混乱する。開発プロセスによっては、約３０の役割が定義されているが、経験的には、１億円以下の規模のプロジェクトでは、ひとりあたりの役割の兼務が多すぎて、担当者にとってはわかりにくいようである。開発プロセス全体で１０前後の役割が適当な数であろう。
ドキュメント、UMLなどのモデル、プログラムのソースコード、ビルド、テストケースなど作業成果物から、公式なもの、非公式なものを分類する。さらに公式な作業成果物の承認レベルを定義する。たとえば、後続の作業担当者の承認、プロジェクト内の承認、ステアリング・コミッティーの承認などのレベルを決める。ステアリング・コミッティーとは、プロジェクトの重大な決定事項に対して決定権のある利害関係者の集まりを指す。通常、プロジェクトの費用を提供するプロジェクトスポンサー、業務要求を決定するユーザーの代表、プロジェクトマネジメントに責任のあるプロジェクトマネジャーなどで構成される。ここで公式なものの決定には、次のような基準を用いると良い。
１）契約上の納品物である
２）プロジェクトスポンサーやユーザーに決定権がある
３）多くの開発者が知る必要がある
４）プロジェクトマネジメントのコントロールアカウントと関連する
５）組織の監査基準としてそのドキュメントの提出が要求されている
６）組織としてのソフトウェア再利用のニーズ
１）は開発が外部のSIerやソフトハウスの場合に、契約書の納品物一覧に記載されているものを指す。納品物には、プロジェクトの成果物であるシステムそのもの以外に、ドキュメント、UMLのモデル、テスト結果サマリーなどの作業成果物が含まれることが多い。
２）はシステム要求仕様書やソフトウェア要求仕様書など、本質的には依頼する側で作成すべきものを、開発側が支援して作成したドキュメントを指す。
３）は、非公式なピアレビューなどによって二人の開発者で共有すれば良いわけではなく、開発プロジェクトの複数の開発者が知る必要がある情報を含む作業成果物を指す。
４）はプロジェクトのWBS上で、プロジェクトの状況を計る最小単位であるコントロールアカウントとなっているWBS要素、たとえば要素成果物やワークパッケージと関連する作業成果物を指す。たとえばサブシステムの設計がコントロールアカウントで、その作業成果物が設計モデルとするならば、設計モデルは公式な作業成果物として何らかの承認レベルを設定すべきである。そうでなければ、非公式つまりできばえに責任が無い作業の状況に基づきプロジェクトのモニタリングやコントロールが行われることになり、正確なプロジェクトの状況を把握できなくなるであろう。
５）に関しては、監査基準を変更する権限が与えられている場合を除いて無条件に受け入れるしかない。
６）は組織が将来的なプロジェクトでソフトウェア再利用を考えている場合に、必要とされる作業成果物である。たとえば再利用するフレームワークやコンポーネントを構成するプログラムのソースコードだけではなく、それらの用途、使用方法、動作保証範囲などのリリースノートや、SAD（ソフトウェアアーキテクチャ設計書)、バイナリが要求されることが多い。
開発ライフサイクルを構成する作業を公式なものと非公式なものに分類する。先述の非公式な作業成果物をアウトプットとする作業であれば非公式で良いだろう。公式な作業成果物をアウトプットとする作業については、とりあえず公式な作業としておいて、プロジェクト開始時にプロジェクトのリスクを考慮してさらに非公式なものを決定すればよい。プロジェクトのリスクは次のようなリスクを指す。
１）要求のリスク
２）技術的なリスク
３）組織のリスク
１）の要求のリスクとは、要求のあいまいさが予想され、要求仕様を慎重に検討していくことが必要と予測される場合である。たとえば、新規性のあるビジネスシステムで、プロジェクトスポンサーやユーザーの代表などのソフトウェア要求に対して責任のある者から見ても、どのようなユーザインターフェイスが適当かわからないケースである。この場合、ユースケースモデルなどの機能要求の仕様、パフォーマンスなどの機能外要求の仕様、ユーザインターフェイスの仕様、振る舞いプロトタイプによる確認と細かくプロジェクトスポンサーやユーザーの代表に確認していくために、それらを公式な作業とすることが必要となる。
２）の技術的なリスクとは、新技術や新バージョンのソフトウェア製品など自組織に開発実績の無い技術を用いて開発する場合である。この場合は、候補となる利用可能な技術の調査、構造プロトタイプによる技術検証、部分的な機能の実現とプロジーの確認、製作を自動化するツールの製作などを公式な作業とする必要がある。
３）の組織のリスクとは、開発する組織が開発手法、利用技術、開発環境などに習熟していない場合である。たとえば初めてUMLとJavaを使ったオブジェクト指向開発に取り組む組織の場合、それらとその開発環境であるモデリングツール、IDEと学習する課題はとても多い。もし反復型の開発を行うのであれば、開発ライフサイクルの前半でそれらのトレーニングを受けるだけでなく、実開発を通して体験し、段階的に学習できるようなインクリメンタル開発の期間を設けるような工夫が可能である。
以上のようなリスクが無く、公式とすべき作業成果物も少なければ、公式な作業というのはかなり減らせる。そのようなプロジェクトであれば、アジャイルプロセスのように公式な作業はソフトウェア要求分析と実装およびテストという軽量な開発プロセスでも問題は無い。
開発プロセスは、開発環境を利用し実行されるので、そこで利用するツールに合わせて開発プロセスの微修整が必要となることがある。典型的なのがUMLモデリングツールで、開発プロセスで予定していた表記ができないこともありえる。ツール選定がプロジェクトごとであればその時に、組織で標準的なツールを決められるのであれば予め、開発プロセスにあった利用ガイドを用意すると良い。
その他ではIDE、バージョン管理ツール、テストツール、要求管理ツールなどがあるが、これらもうまく連携することが必要である。またツールの信頼性にも注意したい。ツールの不具合で開発が停滞するようなケースは絶対に避けるべきである。私は、新しく高価なツールをプロジェクトへ導入したもののツール間の連携がうまくいかなかったり、ツールの信頼性が無かったりで、次第に開発者がそのストレスのため、ツールを使って開発プロセスを実践するモチベーションが無くなり、結局ツールも開発プロセスも投げ出したのを目にしたことがある。
開発プロセスを策定したら、いよいよ次は開発プロジェクトで実行に移す段階だ。しかし、実際にプロジェクトが始まると、開発プロセスの実践者である開発者が「こういうケースはどうしたらいいのだろう？」と疑問を抱えて作業が効率よく進められなかったり、「覚えることや、守るべきルールが多すぎる！」と投げ出してしまったりするなど、開発プロセスの導入には紆余曲折が待ち構えている。開発者が開発プロセスを理解し、実践しようとする気持ちを持たなければ、開発プロセスの導入は非常に難しいものとなる。せっかく策定したプロセスがお蔵入りするような事態を避けるために、何ができるだろうか？
人が何かを学び、それを使いこなせるようになるための簡単な解決策や特効薬は存在しないが、ここではプロジェクトとして取り組めるいくつかのプラクティスをとりあげてみたい。
そもそも開発者が開発プロセスの存在を知らなければ意味がない。また、策定した開発プロセスを、開発者が参照できるようにしておかなければならない。そんなことは当たり前だという読者の方もおられるとは思うが、プロジェクトの初期では、開発環境の整備が完成していなかったり、構成管理の方針が定まっていなかったりなどの理由で、必要なドキュメントをタイムリーに参照しづらい状況下でプロジェクトを進めなければならない場合がある。開発ライフサイクルと作業のガイドライン、成果物のガイドライン、ツールの利用ガイドラインなど、開発を進める上で目を通さなければならないものは、共通の棚に置く、共通のファイルサーバーに置く、またはプロジェクトのポータルサイトを作るなど、プロジェクトの環境に合わせて実現してみよう。
プロジェクトの初期や、開発者が増員するタイミングで、プロセスに関する説明会を開く。開発プロセスは、開発ライフサイクルと作業のガイドライン、成果物のガイドライン、ツールの利用ガイドラインなど文書で提供された場合、文書を読むだけでは理解に時間がかかるし、誤解も生まれやすい。説明会で、まずはプロセスについてざっと説明し、大まかな理解をしてもらう。（プロセスの詳細の習得方法については、後述のプラクティスで触れる）注意したい点は、説明会はプロセスの是非を議論する場ではないことだ。このような議論は、開発プロセスをプロジェクトに最適化する際に既に行われているべきことである。プロジェクトメンバーへの説明会の場で、終わりのない議論にもつれ込むことがないようにしたい。
また、第１章で述べたように「なぜ開発プロセスが必要なのか？」「開発プロセスがあることによる、開発者自身のメリットは何か？」にまで言及し、動機付けにも気を配るとよい。厳しい納期の中で開発を行う開発者にとって、必要性があるのかどうかわからない作業を行うことは苦痛でしかないからだ。
あるプロジェクトでは、研修などの教育を実施していたのは一部の開発者に対してのみで、プロジェクト内の教育が不十分だった。その上、開発プロセスの説明会は行われず、プロセスに対する理解も得られないままにプロジェクトの規模を拡大した結果、理解不足や誤解がもとで、手戻りが発生し、プロジェクトの進捗に深刻な影響を及ぼすケースがあった。
例えば、UMLを用いてオブジェクト指向で開発を行う場合、UMLなどの理解が必要となる。これらを習得するには、外部の研修を受講したり、プロジェクト内の勉強会を実施したりするなどの方法があるが、このほかにも、例えばオージス総研のテーラリングサービスでは、プロジェクト内のトレーニング教材や、開発者が独習するためのガイドブック、必要な知識を有しているかどうかのスキルアセスメントシステムを用意している。社内の標準プロセスを策定する場合には、教材は再利用できるため、予算に応じて取り組むとよいだろう。
筆者らが以前プロセス担当として参画していたプロジェクトでは、プロジェクトを進める中で出てきた質問について、ＦＡＱを用意し、プロジェクトで共有できるようにしていた。この方法のよいところは、後から参画してきた開発者が、ガイドラインなどを見て疑問に思ったことをまずここで解決できるきっかけがあることだ。また、開発プロセスを他のプロジェクトに再利用する場合にもＦＡＱがそのまま利用できるメリットがある。
開発者の全員が、利用する技術のエキスパートであるケースはまれである。反復型開発は初めて、といった開発者や、オブジェクト指向技術を用いた開発は初めて、といった開発者がプロジェクトには含まれることが多い。しかし、チームのほぼ全員がUMLもオブジェクト指向も初めて、といった状況でオブジェクト指向技術を用いた開発を進めていくのは、たとえ開発プロセスが明文化されていても難しい。なぜならば、第1章で述べたように、開発プロセスは開発者をロボットのように振る舞わせるためのものではないからである。つまり、ガイドラインを読めば、自動的に正しく妥当な成果物が作れるわけではなく、そこには開発者自身のエンジニアリングのノウハウや、慣れが必要となるのである。そこで、「プロセスメンター」、すなわちチームの心の支えとなるような経験者の存在が重要となる。プロセスメンターは、週に１回来て、成果物をレビューするだけ、といったスタイルで仕事をするのではなく、プロジェクトの一員として開発を行う。いわば、開発プロセスの実践者としてのお手本を示し、他の開発者に適切な助言をする役割である。経験の浅い開発者は、身近な存在であるメンターの作業の進め方、考える過程、作成した成果物を参考に、開発プロセスに基づいた作業を行う方法を学んでいく。
自社のプロセスを大幅に変更する場合など、開発者の経験が浅く、いきなり本格的なプロジェクトを行うにはリスクが高い、と判断した場合や、開発プロセス自体にリスクがある場合には、評価を目的としたパイロットプロジェクトを実施する方法がある。このようなパイロットでは、短期間でできる題材を、余裕を持ったスケジュールで行い、その中で開発プロセスの問題点を洗い出し、プロセスの洗練を行う。
パイロットプロジェクト実施で注意したいのは、何の評価が目的なのかを明確にすることだ。開発プロセスの洗練が目的だったにもかかわらず、いつのまにか利用技術の評価にすり替わっていた、ということがないように注意したい。
本稿では、開発プロセスの明文化の必要性とその最適化手法について紹介した。最適化された開発プロセスを明文化しただけで終わりではないことを覚えておいてほしい。開発プロジェクトの初期にプロセスを策定した際、さまざまなケースを想定し、検討していたとしても、実際にプロジェクトが始まってみると、思いもよらぬケースが出てくるものだ。明文化された時点がスタートラインであり、組織に浸透させ、組織で継続的に改善していくことにより、組織にあった最適化が可能となる。
本稿が読者の組織への最適なプロセス策定のきっかけとなれば幸いである。
| © 2006 正木威寛，山内奈央子 |
|
