今回は、開発プロセスについての基本的な知識をまとめ、開発プロセス策定のポイントを現場のこもごもを交えながらご紹介したいと思います。 1 開発プロセスとは■開発プロセスの目的 開発プロセスはなぜ必要なのでしょう。特に開発プロセスを明文化しなくとも、システムはできあがるのではないでしょうか。ただ、そこにはいくつかのトラブルのもとが隠れています。 - 成果物や作業があいまいとなり、プロジェクトの進行がいきあたりばったりになる
- プロジェクトがいま何をやっていて次に何を行うのかが関係者に見えず、コミュニケーションがうまくいかない
- 作るべき成果物や実施すべきレビュー等、統制ができない
- 行うはずだったことがあいまいとなるため、プロジェクトの評価や改善につながらない
開発プロセスを明文化することは、これらの問題解決に有効です。 ただし、よくある誤解に気をつけなければなりません。それは、プロセスを定義した文書（たとえば開発手順書）を読みさえすれば、誰でも開発ができるようになるという誤解です。システム開発は創造的な作業です。読み手にこのような誤解があると、熟考することをやめ「手順書に書いてあることさえ行えばよい」といった思考につながり、プロジェクトや組織にとって損失となってしまいます ■開発プロセスが定めるもの 開発プロセス策定は、開発を行う際に必要な作業と、作業のインプットとアウトプット（成果物）を定義することが基本となりますが、そのほかにも決めておくべきものがあります。ここでは、開発プロセス策定時に定義する5つの事項について説明します。 - （１）策定の範囲
- どの範囲のプロセスを策定するのかを決める必要があります。検討の際には、プロセスに関する規格類が参考になるでしょう。後述のISO/IEC12207（ソフトウェアライフサイクルプロセス）や共通フレームなどがあります。
- （２）ライフサイクルモデル
- ウォーターフォールや反復型など、プロジェクトの進め方について決定します。
- （３）成果物
- ユースケースや画面設計書、アーキテクチャ設計書やソースコード、テストケースなど、システムを作るうえで必要な成果物を決めます。また、必要に応じて個々の成果物を収録する文書を定義します。たとえば、ユースケースとビジネスルール、非機能要件といった成果物を「要求仕様書」という文書にまとめたり、さまざまな設計書をまとめて「基本設計書」としてまとめる、などです。成果物の定義の際には、契約上決められている成果物だけでなく、監査上必要な成果物も含めるようにします。
- （４）フェーズ
- フェーズとはプロジェクトのゴールにたどり着くまでの主要なマイルストーンに区切られた期間をさします。
たとえばウォーターフォールでプロジェクトを進める場合には、システムに対するユーザーの要求を文書化し終わることをマイルストーンとし、それまでの期間を「要件定義フェーズ」とする、などです。 - （５）作業と役割
- 成果物を作成する作業とその順序、また作業を実施する役割を定義します。
ユーザー部門とIT部門といった大きな分け方ではなく、要件定義担当者やデータベース担当者、アーキテクトなど、スキルセットが異なる場合は分けておくと、人員調達の際の参考になります。
2 知っておきたい規格類 先にも書きました通り、開発プロセスを策定する際には、ISOなどの規格を知っておくと検討しやすくなります。私の経験では、「要件定義フェーズでユーザーの要求を文書化する」といっても、人によって思い描く範囲や詳細度はさまざまです。マルチベンダーで進める場合はなおのこと。したがって、規格類は、さまざまなバックグランドを持つメンバーとのコミュニケーションにおいて有効ですし、自社のプロセス改善を行うケースでも、対象となる範囲を確認の際に役に立つと考えています。 ■ISO/IEC12207 ISO/IEC 12207は、ISO(国際標準化機構：International Organization for Standardization)が定めたソフトウェアのライフサイクル、つまりソフトウェアが作られ破棄されるまでに行われるさまざまなプロセスに関する標準です。
執筆時点で最新の2008年度版では、大きくシステムに関するプロセスとソフトウェアに関するプロセスの２つに分類され、下位の７つのプロセスにグルーピングされています。それぞれのプロセスは、さらに下位のアクティビティが定義されています。 
図1 ISO/IEC12207のプロセスの分類
（１）システムコンテキストプロセス- ◇合意プロセス
- 2つの組織間で合意を確立するためのプロセス。取得と供給の2面から定義されている。
- ◇プロジェクトプロセス
- 計画立案、実行、評価、コントロールするプロセス。
- ◇組織に関するプロジェクト可能プロセス
- プロジェクト支援のために必要なインフラや資源などを管理するプロセス。
- ◇技術プロセス
- 要求の定義からシステムの設計・製造・テスト、および運用・保守、破棄にいたるまでの一連のプロセス。ISO/IEC15288のシステムライフサイクルプロセスと紐づいたものとなっている。また、システムの実現にはソフトウェアの製造も含まれるため、本プロセスは、後述の「ソフトウェア固有プロセス」を包含している。
（２）ソフトウェア固有プロセス- ◇ソフトウェア実施プロセス
- 要求されたシステムの実現のうち、ソフトウェアへの要求分析から設計・構築・テストを実施するプロセス。開発プロセスを策定する場合、このプロセスを含むことが多いでしょう。
- ◇ソフトウェア支援プロセス
- 構成管理や品質保証など、ソフトウェア実施プロセスをサポートするプロセス。
- ◇ソフトウェア再利用プロセス
- ドメインモデルなどの再利用、再利用のための資産管理のプロセス。性質上、１つのプロジェクトだけで扱われるものではなく、プロジェクト横断的に実施される。
このように、ISO/IEC12207はソフトウェアのライフサイクルをカバーしているため、ものづくり以外のプロセスも含んでいます。したがって、開発プロセスだけでなく、システムの発注者側のプロセス（調達プロセス）策定の検討などにも役に立つ規格です。
また、このISO/IEC12207は、JISで定めたソフトウェアライフサイクルプロセスのベースともなっており、以下の場所でJIS規格を参照することができます。 参考）JIS X 0160 ソフトウェアライフサイクルプロセス （日本工業調査会で閲覧可能） 3 開発プロセス策定のポイント さて、ここからは、開発プロセスの策定のポイントを説明します ■開発プロセス策定の目的を明確にする 仕事をする上で当たり前ではありますが、目的は重要です。
たとえば開発プロセス策定の目的が、統制である場合には、統制したい内容と、そうでないことを区別する必要があります。手順書の書き手としては、親切心でつい詳細に書きすぎてしまいがちなのですが、過度に丁寧なマニュアル調になると、現場は最低限何を守るべきなのか、自分たちでどこまで創意工夫してよいのか混乱してしまいます。成果物に記載すべき項目のみ定義するのか、成果物のフォーマットまで規定するのかなど、目的に合わせて予め決めておく必要があります。
また、プロセスやルールを決める際、あらゆるケースに対してカバーできるものを策定することは至難の業です。（たとえできたとしても、手順書が分厚くなりすぎて読む気が失せること請け合いです）。したがって、個々のケースにどう対応するのかはプロジェクト中に判断する必要があります。その判断基準として、「○○を守るべし」というルールの記載だけでなく、手順やルールの目的やコンセプトを記載することがポイントです。 ■誰が決めるのかを明確にする プロセス策定の際には、プロセス策定自体のプロセスも考えなければなりません。開発プロセスは現場の仕事のやり方に影響しますので、ひとこと口を挟みたい人も多いでしょう。
策定した開発プロセスの承認者は誰なのか、社内の有識者の意見を聞く場を設けるのかについて計画し、その計画がプロジェクトまたは組織内で合意される必要があります。さもなくば、策定の終盤になって、いわゆる”声の大きな人”にひっくり返されるリスクがあるので要注意です。 ■プロジェクトの能力を吟味する オブジェクト指向設計分析の経験がまったくない組織で、バリバリのオブジェクト指向の開発プロセスを組むことは現実的でしょうか？ベンダーコントロールが成熟していないユーザー企業で、開発会社の開発プロセスや成果物のフォーマットまで統制するプロセスを組むことは現実的でしょうか？標準化が目的である場合には、いきなり高いハードルを設けるよりは、社員の教育計画も含め、長期的な視野で一歩一歩進めるとよいと思います。 ■プロセス文書自体のテンプレートやルールを作る つい忘れがちなのですが、手順書などプロセス文書自体のルールを決めておくと便利です。それでなくとも手順書を読むのは面倒なことですから、これら文書の体裁がバラバラだったり誤字脱字が多かったりしたら、読み手にとってどんな印象でしょうか？また、策定している側にとっても、後から体裁を整えるのはとても面倒です。あらかじめ決めておきましょう。 ■改善する◇プロジェクト期間中の改善 組織的な対応、たとえば、プロジェクトマネジメントチームに、開発プロセス推進のミッションを持たせ、プロジェクトを通じて対応できるチーム編成とする方法などがあります。手順書は配布するだけではなかなか使ってもらえませんので、説明会を開いたり、FAQを公開したり、また、現場へのインタビューや、メトリクスの収集など現場とのコミュニケーションをとりながら積極的にPDCAを回してゆけるとよいでしょう。 ◇プロジェクト終了後の改善 １つのプロジェクトをターゲットに開発プロセスを策定した場合には、プロジェクトが終わるとプロセス改善の予算の確保が難しくなります。使い捨ての開発プロセスでよい場合は問題ないですが、少なくとも１度実践された実績のあるプロセスですから、ちょっともったいないですね。品質管理部などプロジェクトを横断し継続的に改善できる組織がプロセスを長い目で育ててゆく方法があります。プロセスの改善だけでなく、プロセスを適用したプロジェクトからメトリクス（例えば１ユースケースあたりの平均コスト）を集めて、見積もりやプロジェクトの評価に利用することもできます。 4 最後に いかがでしたでしょうか。
開発プロセスを明文化し有効活用することで、現場の技術者やプロジェクトマネージャー、システムを発注した顧客にとって、よりよいシステム開発につながることを願っています。 *本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。 | 
