NEWS

受発注者間の合意を円滑にする「発注者ビューガイドライン」

開発者とユーザーとのシステム要件の解釈の相違は、後々、仕様変更や手戻りの発生などを招き、致命的なトラブルにもつながってしまう。上手にユーザーとの合意に至るコツはないものだろうか？

　システム開発では、ユーザー側（発注者）が求めるシステム要件を調査・分析した後、外部設計工程で開発側（受注者）が作成する「画面レイアウト」や「システム業務フロー」などの成果物によって、システムがより具体化される。

　しかし、これらを基に行われる確認レビューの場で、システム要件に対する双方の認識の違いが分かったり、それが完全に解消されたりするとは必ずしもいえない。この段階での認識のずれは、後工程での仕様変更や手戻り作業の原因ともなり、重大なトラブルにつながる恐れがある。

　こうしたトラブルの回避を目的として、国内のSIベンダー9社が協力し、2007年から2008年にかけて、受発注者間の合意を円滑にするコツをまとめた「発注者ビューガイドライン」を公開した。現在、IPA（情報処理推進機構） が主体となったワーキンググループ（WG）において、改訂に向けた検討作業が行われている。

　発注者ビューガイドラインとは、一体どんなものなのか？　WGの担当者の話を織り交ぜて紹介する。

発注者ビューガイドラインとは？

　発注者ビューガイドラインは、「Webアプリケーション開発における、外部設計工程時の発注者と受注者間のシステム仕様に関する認識のずれを防ぐためのコツ」を取りまとめたもの。「システム振る舞い編」「画面編」「データモデル編」と「概説編」「用語集」で構成されており、IPAの専用サイトからダウンロードできる。国内のSIベンダー9社から構成された「実践的アプローチに基づく要求仕様の発注者ビュー検討会」（以下、発注者ビュー検討会）が各社のこれまでの経験やノウハウを持ち寄って議論・検討を重ね、ユーザー企業3社のフィードバックを踏まえて策定された。

　発注者ビュー検討会は、2007年9月に画面編を、2008年3月にシステム振る舞い編、データモデル編、概説編、用語集を公開して活動を終了した。その後、IPA／SEC（ Software Engineering Center）のエンタープライズ系プロジェクトである「要求・アーキテクチャ領域」の「機能要件の合意形成技法WG」（以下、合意形成技法WG）に検討・普及活動などが移管されている。

　このWGには、発注者ビュー検討会参加ベンダーに加えて、ユーザー企業5社（テプコシステムズ、清水建設、第一生命情報システム、AGS、東京証券取引所）と開発ベンダー企業としてインテックが参加している。

　発注者ビューガイドラインには、外部設計の工程成果物である画面レイアウトや業務フロー、ER図などの図表14点の「分かりやすい書き方」や、ユーザーとのヒアリングや設計書レビュー時の「分かりやすい話し方」などに関するコツが187個掲載されている。

プロジェクト品質の平準化や人材育成にも活用できる

　発注者ビューガイドラインの中には、開発者にとって当然のこととも取れる内容が盛り込まれている。例えば、画面編の画面一覧の書き方のコツとして「項目番号を記述することで、画面の重複や抜け漏れの確認が容易になる」と説明されている。また、画面遷移の書き方のコツでは「画面遷移が上から下、左から右に遷移するように配置する」という内容も含まれている。それはなぜだろうか？

　合意形成技法WGのリーダーである、NTTデータの田中久志氏（技術開発本部ソフトウェア工学推進センタ、シニアエキスパート）は、実際のシステム開発の現場では「当り前のことができているプロジェクトと、そうでないプロジェクトが混在し、プロジェクト間でのバラつきが起きている」と説明した。また、プロジェクトを多く経験している人にとっては常識であることも、実際に設計書を記述する経験の浅い担当者には伝わっていないこともあるという。

　その上で、「ガイドラインとして体系化することで、開発チームの上司・部下という縦の関係性だけでなく、企業・組織単位でのプロジェクトにおいて横断的に活用できる」と語った。発注者ビューガイドラインは、チェックリストや教育教材としても活用できる。

　実際に、発注者ビュー検討会に参画したベンダーの多くは、このガイドラインを自社の開発標準に取り入れてプロジェクト品質の平準化に役立てており、また、大学生を対象とした教育セミナーなどにも活用しているという。

今後の検討課題

　現在、合意形成技法WGの発注者ビューガイドラインに関する活動状況はどうなっているのか？

　IPAのソフトウェア・エンジニアリング・センター企画グループの塚本英昭氏は、「ユーザー企業、ベンダー双方にとって役に立つ、より洗練された発注者ビューガイドラインの公開を目指す」と語った。

現在、合意形成技法WGでは、以下の3点を主な検討課題としている。

1. 検証対象範囲の再検討：発注者側から見た「外部設計工程の開始時点のあいまいさ」の明確化
2. 発注者視点の拡充：発注者視点の課題の整理、発注者の定義、表現のコツの再検討
3. 「共通フレームワーク2007」との位置付けの明確化：IPAの既存ガイドラインとの対応付け

　塚本氏によると、合意形成技法WGでは2008年度の重点課題として2の「発注者視点の拡充」に取り組んでいるという。

　現行のガイドラインでは、発注者の定義を「発注する人」とひとくくりにしているが、実際のレビューに参加する発注者はユーザー部門の担当者や情報システム部門の担当者など、さまざまである。例えば、ER図による説明を行う際に、ユーザー部門の担当者とシステム部門の担当者とでは、同じような説明で理解を求めるわけにはいかない。

　田中氏は、現行のガイドラインにはベンダー側の視点が多く盛り込まれており、発注者側に合わせた表現にするための工夫を施す必要があるとし、「今後は発注者の種類に対応するように、表現のコツを改善する」と説明した。

　合意形成技法WGでは今後、「発注者はシステム要件を開発者に“言い切る”、開発者はシステム要件を発注者から“聞き切る”」ために必要な、合意形成フェーズの定義やガイドライン構成などを検討するという。

　IPAでは2009年3月末までに、ガイドラインを活用するための「使い方ガイドライン（仮称）」の公開を予定しており、2009年度（2009年4月～2010年3月）中には、ガイドラインの改訂版の公開を目指す。

この記事の著者

関連記事

• 

  【Q＆A】ソフトウェア開発における効果的な顧客コミュニケーション

• 

  顧客とのコミュニケーションはファーストクラスで

• 

  現場で使われない開発標準―その理由を尋ねてみると……

• 

  日本HP、「ユーザー要件とテスト間の矛盾を防ぐ」品質管理ソフト

新着ホワイトペーパー PR

• 製品資料
  [株式会社MatrixFlow] 「物流リソース最適化」ガイド：人員・配車・傭車を出庫依頼の確定前に決めきる
• 製品資料
  [株式会社キーエンス] なぜRPA導入は頓挫する？　シナリオ作成の壁を乗り越える解決策とは
• 製品資料
  [株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か？　PLMとの融合で実現する高速開発
• 事例
  [日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える？　「新たな働き手」を支える3要素とは
• 製品資料
  [日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣