information-technology promotion agency, japan 機能要件に関す … · 技術本部...

Information-technology Promotion Agency, Japan

Software Engineering Center

Copyright© 2010-2013 Information-technology Promotion Agency, Japan. All rights reserved. Software Engineering Center

機能要件に関する発注者と開発者の合意形成を目指して

～機能要件の合意形成ガイド～

独立行政法人情報処理推進機構(IPA) 技術本部ソフトウェア・エンジニアリング・センター(SEC)

柏木雅之

エンタプライズ系総合セミナー第２日：「ITサービスを取り巻く環境と要求」

2013年3月5日

SEC Software Engineering for Mo･No･Zu･Ku･Ri

Software Engineering Center 1 エンタプライズ系総合セミナー, 2013-03-05 Copyright © 2010-2013 IPA, All Rights Reserved.

本日のメニュー

1. 「機能要件の合意形成ガイド」とその開発背景

2. 「機能要件の合意形成ガイド」内容の紹介

3. 「機能要件の合意形成ガイド」の適用例

4. まとめ～どのように使ったらよいか？～



「機能要件の合意形成ガイド」とその開発背景



「機能要件の合意形成ガイド」って何？

機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するためのコツを集めたもの

実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ

発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ

ZZ9／ZZ9 (ZZ9)

YYYY/MM/DD 23:59

出荷元コード XXXXXXXXXX出荷部門 NNNNNNNNNNNNNN

伝票番号 XXXXXXXXXX お届け先コード XXXXXXXXXXお届け先名 NNNNNNNNNNNNNN 御中売上区分 Xお届け先住所 NNNNNNNNNNNNNNNNNNNNN 発注区分 X

NNNNNNNNNNNNNNNNNNNNN 支払期限 YYYY年MM月DD日

No123456789

1011121314151617181920

ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ



ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ


ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ






納品書

納品明細単　価数量商品名品　番合　価消費税備　考

概要編

システム振舞い編

バッチ編

画面編データモデル編

外部インタフェース編帳票編

概説編および６つの技術領域毎の編の計７冊から構成



発見工程別相対修正コスト

ソフトウェアテスト

システムテスト

運用テスト

システム仕様

プログラミング

要件定義

システムテスト

運用テスト

ソフトウェア仕様

ソフトウェアテスト

5

10～100

修正コ

ス

ト

右の出典：B.W.Boehm “Soft. Eng.” IEEE Trans. com (Nov ‘76)

「機能要件の合意形成ガイド」を作った背景

SEC BOOKS『経営者が参画する要求品質の確保』（P26)より

システム開発における手戻りとコストの関係

1



出典：共通フレーム2007「ソフトウェアとシステム」に追記


事業

人による活動

人による活動業務D

業務C

業務A

人による活動

システム人による活動

システム

人による活動

システム

業務B

業務E

業務E 人による活動

システム

システム利用

ハードウェアソフトウェア

その他設備 (ネットワークなど)

事業・業務とシステム、ソフトウェアとの関係

業務要件のブレークダウン

業務要件

システム要件

システム要件

機能要件

ソフトウェア要件

アーキテクチャ設計

非機能要件

要件定義

システム設計

ソフトウェア設計



開発者

発注者

監督官庁

開発グループ

アウトソーサ

ヘルプデスク

コールセンタ

運用・業務支援グループ

代理店企業・個人ユーザ

顧客社外ユーザ

SEC BOOKS 共通フレーム2007(第2版)P.6

「コミュニケーションチャネルの複雑さ」を参考

オフショア先

ソフトハウス

開発ベンダ

システム開発におけるステークホルダーの増加により、発注者間、発注者と開発者間の認識の齟齬、意思伝達の漏れが多く発生


企画／業務設計担当

システム開発担当

経営者

顧客社内ユーザ

システム開発に係るステークホルダー



「機能要件の合意形成ガイド」を作った背景システム開発において起こりうるギャップの例

発注者と開発者の認識の齟齬により要求と実現されるソフトとの間にギャップが生じるこれの解決支援が目的

システム化計画

業務部門の要求内容

要件定義内容

①要件定義すべき内容が抜けており、開発者に説明していない。

②発注者が開発者に説明したが、何らかの理由で漏れた。

参考文献：IPA/SEC 発注者ビューガイドラインの活用と拡張(p.4)

外部設計内容

実現される

ソフトウェア

④開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。

③発注者が開発者に説明し、共通理解が得られた。

この絵は、発注者が要件定義までを行い、それ以降の工程を開発者が行う場合の例

発注者開発者

A B C

バグや障害

バグや障害

バグや障害



２００６年度～２００７年度２００８年度２００９年度 2010年度～

・Webサイトによる成果物の公開・IPA/SEC、JUASとの連携

・書籍出版

発注者ビュー検討会(注)

8月

書籍

「失敗しない｣外部設計」日経ＢＰ社

課題整理・領域拡大

成果物「発注者ビューガイドラインの活用と拡張」

ＩＰＡ／ＳＥＣ機能要件の合意形成技法ＷＧ

３月

改訂版の作成

成果物機能要件の合意形成ガイド

発注者ビューガイドライン

IPAにて７月より公開

注：発注者ビュー検討会＝実践的アプローチに基づく要求仕様の発注者ビュー検討会

「機能要件の合意形成ガイド」開発のあゆみ

（情報システムにおける「仕様」について、お客様にわかりやすい記述方法および合意方法を共同検討することを目的に国内主要SI事業者（９社）が結集した検討会）

発注者ﾋﾞｭｰｶﾞｲﾄﾞﾗｲﾝの作成／評価成果物｢発注者ビューガイドライン ver. 1.0｣

評価

３技術領域コツ数 187

６技術領域コツ数 278



「機能要件の合意形成ガイド」普及のあゆみ

Web公開文書の利用実績

「機能要件の合意形成ガイド」 2010/4~2010/11のダウンロード単純合計：約42,000件(約5,000件/月) ユニークユーザは月700～800人

「発注者ビューガイドライン」2008/7～2010/６末のダウンロード単純合計：約132,000件（約5,000件/月）



「機能要件の合意形成ガイド」内容の紹介



「機能要件の合意形成ガイド」の目的

要件定義・外部設計におけるお客様との認識の齟齬を防ぐ

機能要件の合意形成ガイド

非機能ではなく、機能寄り（機能要件、動作仕様etc…)

お客様との認識の齟齬を防ぐ

情報システムの実現開発者発注者視点で書き、説明する

目的とする情報システム像

（外部設計として整備する事項）

外部設計書発注者発注者視点で、見える・わかる

業務モデルの構築



機能要件の合意形成ガイドとは

278のコツを適用する技術領域・適用画面に分類・整理したもの

278 言い切る／聞き切る 44 図表に書く 101 もれ／矛盾をチェックする 22 一緒にレビューする 94発注者が事前に意識する

17・言い切る/聞き切る５・システム化業務一覧７・システム化業務フロー２・全レベルでレビュー(要件との整合) ３

・システム化業務フロー１１・全レベルでレビュー(設計書の正しさ) ３・システム化業務説明４・仕掛レベルのレビュー５・システム振舞い共通ﾙｰﾙ５・充実レベルのレビュー８・工程成果物間の関連２・充実・完成レベルのレビュー５

60・言い切る/聞き切る６・画面一覧６・画面一覧２・設計書レビューの進め方８

・画面遷移５・画面遷移１・画面全体に渡る共通事項のレビュー５・画面レイアウト４・画面レイアウト３・画面の一連の動きのレビュー４・画面入出力項目一覧３・画面遷移・ﾚｲｱｳﾄ共通ﾙｰﾙ６・１つの画面のレビュー１０・画面アクション明細６・画面入出力項目一覧２・画面遷移・ﾚｲｱｳﾄ共通ﾙｰﾙ８・工程成果物間の関連１・工程成果物間の関連４

84・言い切る/聞き切る８・ＥＲ図４・エンティティ・属性を抽出する３

・エンティティ一覧５・データモデルの概要を説明する１・ＣＲＵＤ図４・データモデルの詳細を説明する１１

・データの変化を確認する３・業務とデータの関係を確認する２・他ｼｽﾃﾑとやりとりするﾃﾞｰﾀを確認する３・業務量を確認する１

45・言い切る/聞き切る１０・外部システム関連図１・もれ／矛盾をチェックする２・一緒にレビューする７９

・外部インタフェース一覧２・外部インタフェース項目説明３

・外部インタフェース処理説明１

35・言い切る/聞き切る７・バッチ処理一覧２・もれ／矛盾をチェックする１・一緒にレビューする４

・バッチ処理フロー４・バッチ処理定義２・バッチ共通ルール３

23・言い切る/聞き切る８・帳票レイアウト２・もれ／矛盾をチェックする２・一緒にレビューする８８

・帳票項目説明１・帳票概要１・帳票編集定義１

31

帳票編

８５２８８

・発注者が事前に意識する

バ

ッチ編

７１１１４０

フ

ェー

ス

編

イ

ン

タ

外

部・発注者が事前に意識する

１０７２７９

デー

タモデル編

８１３０２４０

画面編

６３６１５２７０

振舞い編

システム

５２９２２４０



「機能要件の合意形成ガイド」コツとは

発注者と開発者との認識の齟齬を防止する為のノウハウ「○○の様な場面に△△のような行動を取る（記述する）と□□の様な効果

がでる」といったイメージ

事例から生まれたものガイド執筆メンバにおける認識の齟齬防止に効果があった事例を抽象化した

もの

目的、施策、メリットがはっきりしているはっきり出来なかった中途半端なモノ⇒コラム

※ コツが主役である。 →「工程成果物」、「合意成熟度レベル」、「４つの作業」などは、

コツを分類する為に用意された仕切り版の様なもの。これらを規定するガイドではない。

※ あらゆる場面に効果が出る訳ではない →利用時には取捨選択必要（コツ間の矛盾も存在）



技術領域エンタープライズ系業務システムを構築するにあたり、機能要件として設計対象となる主要な要素。次の６つの技術領域からなる。

「機能要件の合意形成ガイド」技術領域

画面データモデル

バッチ処理帳票

システム振舞い

外部インタフェース

ZZ9／ZZ9 (ZZ9)

YYYY/MM/DD 23:59




No123456789

1011121314151617181920












納品書

納品明細単　価数量商品名品　番合　価消費税備　考

これらの１つひとつが技術領域



「機能要件の合意形成ガイド」工程成果物

工程成果物とは？各技術領域において、設計書の一部として書かれ、合意形成のために必要な設計要素（名称は一般的なもの）

※ コツに登場する設計要素のみ収録

開発で必要なもの全てを収録しているわけではない。

画面設計書

発注者

画面レイアウト

確認

「工程成果物」設計書

画面入出力項目一覧

画面アクション明細




システム振舞い編の紹介要件定義プロセスで作成される業務フローや業務処理定義書を元に、システム化する範囲を識別し、その範囲の設計を発注者と開発者が合意するためのコツを、４つの「工程成果物」を中心に解説。




画面編の紹介要件定義、外部設計工程で作成される業務フローやシステム化業務フローを元に、導き出されるユーザインターフェースの１つである「画面」を設計するためのコツを、6つの「工程成果物」を中心に解説。

画面遷移・レイアウト共通ルール

画面一覧画面間の遷移関係を示した図。画面から画面への遷移と画面遷移を起こすキッカケとなるイベント。

条件分岐がある場合は、その条件と対応する分岐遷移

画面レイアウトと画面遷移に関する共通ルールおよび諸々の画面（群）が準じる典型的なレイアウトや遷移のポリシ

システムで使用する画面の一覧

項目・イベント発生オブジェクト名、それらに対応する画面部品（ボタン、入力出力項目など）およびその配置

No 分類画面名画面ID

…

1 入力フォーム

ペット登録画面 S-01 …


販売者登録画面

S-02 …


ログイン画面 S-05 …

… … … … …

余白

ユーティリ

ティエリコンテンツエリア

フッターエリア

20% 60% 20%

ヘッダーエリアコンテンツエリア

（main）コンテンツエリア

（sub2）

80ﾋﾟｸ

80ﾋﾟｸ

60ﾋﾟｸ

画面遷移

画面レイアウト

画面アクション明細画面遷移に伴って起動させる動作

アクションの処理概要

アクションの処理詳細

①顧客情報の入力チェック②検索処理入力された情報をもとに顧客情報テーブルを検索する③-1 合致するデータが存在しない場合顧客情報を登録し、顧客登録画面を初期表示する③-2 合致するデータが存在した場合エラーメッセージを表示する

入力された情報をもとに顧客情報を登録する

画面入出力項目一覧

画面を介して入出力する項目の外部仕様

識別ID

表示用のラベル部品の種類入力

表示桁数

入力桁数

データ型入力制約

1 ユーザ名ラベル × 18 - 文字列 - ○ ユーザ名値2 新しいパスワーテキストボック △ 18 10 文字列パスワード入力パターン × -3 再入力パスワーテキストボック △ 18 10 文字列パスワード入力パターン × -4 名前（姓）テキストボック △ 19 18 文字列 × -5 名前（名）テキストボック △ 19 18 文字列 - × -6 Ｅメールアドレステキストボック ○ 39 38 文字列 Eメール入力パターン × -7 電話テキストボック ○ 19 18 文字列電話番号入力パターン × -8 住所１テキストボック ○ 39 38 文字列 - × -9 住所２テキストボック ○ 39 38 文字列 - × -

初期表示




データモデル編の紹介開発対象システムのデータモデルを設計するためのコツを、４つの「工程成果物」を中心に解説。

データモデルデータ辞書

ユーザ企業内で利用するデータをモデル化して表現したもの

エンティティとリレーションを表現するシンボルを用いて作図する。

ユーザ企業内で利用するデータに関する規則集

ER図

データの最小単位であるデータ項目を定義

ドメイン一覧／定義

データ項目定義

コード一覧／定義

データ項目をカテゴリ分けするための基準

データの内部構造や値が決まっているデータ項目の仕様を定義

その他資料

エンティティ一覧エンティティの一覧

項番エンティティ名説明1 顧客・・・2 商品・・・3 受注・・・

項番エンティティ名説明1 顧客・・・2 商品・・・3 受注・・・

エンティティ名およびエンティティごとの属性の一覧

エンティティ定義エンティティ名商品

項番属性名型桁 PK 説明1 商品番号 X 10 P ・・・2 商品名 X 100 ・・・3 商品区分コードX 3 ・・・

・・・

エンティティ名商品

項番属性名型桁 PK 説明1 商品番号 X 10 P ・・・2 商品名 X 100 ・・・3 商品区分コードX 3 ・・・

・・・

業務とエンティティの関係を表現したもの

CRUD図エンティティ

顧客

受注

受注明細

機能

顧客登録

受注登録

受注明細登録

顧客検索

C

R

R

R

C

R C

製品

R

エンティティ顧客

受注

受注明細

機能

顧客登録

受注登録

受注明細登録

顧客検索

C

R

R

R

C

R C

製品

R

ファイル一覧／定義システム間でやりとりされるデータファイルの一覧／詳細




外部インタフェース編の紹介外部インタフェースについての「コツ」を、４つの「工程成果物」を中心に解説。

開発対象業務システム

相手先業務システム

やりとりされるデータ

（名称、内容）

外部インタフェースの対象領域

データのやりとりの特性データのやりとりの方向、手段／方法データのやりとりのタイミング

システムＡ

システムＢ

システムＣ

システムＣ

エスケープの規定

外部インタフェース処理説明

・レコード間では次の規則に従っていること。①レコードヘッダレコードの送信件数、レコードフッタレコードの送信件数、ならびにディテールヘッダレコードの数は一致していること。②ディテールヘッダレコードの受注明細件数、ディテールフッタレコードの受注明細件数、ならびに後続するディテールボディレコードの件数③ディテールヘッダレコードの受注金額合計と後続するディテールボディレコードの販売単価×購入数量の合計は一致していること。④レコードヘッダレコードの送信時刻とレコードフッタレコードの送信時刻は一致していること。

・受信側で上記の規則に従っていないデータを受信した場合には、途中でデータが欠落したものとみなし、送信エラー扱いとすること。

・受信側は外部インタフェースレコードを受信したら、受信したレコードが上記に示す規則に従っているかを確認する。規則に従った外部インタフェースレコードであった場合には、送信元に対して「受信成功」のメッセージを送信する。規則に従っていない場合には「送信エラー」のメッセージを送信する。

・送信対象の受注情報がない場合は、レコードヘッダレコードとレコードフッタレコードだけを送信し、その際の送信件数は０とする。

データ量メッセージ長

受注管理システム UNIX(HP-UX11i) 送信可変５００Byte(max)

通信先通信先プラットフォーム送信/受信

エラー時の対応

エラー時のファイルを破棄し、ファイルを再生成後にリトライする。

外部インタフェース処理説明

外部システムとのデータのやりとりの方式について、概要を記述したもの

外部システム関連図

システム間のデータの送受信関係を図示したもの

外部インタフェース一覧出力入力相手先システム情報(To) (From) 自システム名システム名既／新

1 7800001 受注情報 ○ 受注管理システム販売管理システム既存

2 7800002 商品出荷状況情報 ○ 受注管理システム販売管理システム既存

3 7800003 商品情報 ○ 受注管理システム販売管理システム既存

4 7800004 新規顧客情報 ○ 受注管理システム顧客管理システム既存

5 7800005 顧客更新情報 ○ 受注管理システム顧客管理システム既存

6 7800006 受注処理ログ情報 ○ 受注管理システム処理証跡管理システム

既存

7 7800007 信用照会問合せ情報 ○ 受注管理システムクレジット信用照会システム(外部）

既存

8 7800008 信用照会結果情報 ○ 受注管理システムクレジット信用照会システム(外部）

既存

9 6800001 出荷指示情報 ○ 販売管理システム集配信システム既存10 6800002 配送結果情報 ○ 販売管理システム集配信システム既存11 6800009 販売管理処理ログ情

報○ 販売管理システム処理証跡管理シス

テム既存

No 外部インタフェースID 外部データ名

外部インタフェースを一覧化したもの

No PKEY 項目名属性桁数必須説明1 1 送信時刻 VARCHAR2 12 ○ 送信処理を開始した時刻

（yyyymmdd/hhmmssの形式）2 送信件数 NUMBER 2 ○ 送信する受注件数（＝ディテールヘッダレコード数）

No PKEY 項目名属性桁数必須説明1 1 受注番号 VARCHAR2 12 ○ 受注（あるいは取消）処理時に採番した番号2 2 受注区分 VARCHAR2 1 ○ 受注あるいは取消の区分、１：受注、０：取消3 顧客コード VARCHAR2 12 ○ 受注を受けた顧客の顧客コード4 受注金額合計 NUMBER 12 ○ 受注金額あるいは取消金額

（＝ディテールボディの単価×購入数量の合計）5 受注日時 VARCHAR2 15 ○ 受注あるいは取消が成立した日時

（yyyymmdd/hhmmssの形式）6 受注明細件数 VARCHAR2 2 ○ 後続するディテールボディーレコード数7 支払区分 VARCHAR2 1 ○ 支払方法区分

（D:送品時支払、C:クレジット支払、S:振込)8 クレジット番号 VARCHAR2 16 クレジット支払いの場合のクレジット番号9 クレジットユーザ名 VARCHAR2 16 クレジット支払いの場合のクレジット所有者名

10 届け先住所 VARCHAR2 100 顧客情報で登録されている住所と異なる場合の送付先住11 届け先氏名 VARCHAR2 50 顧客情報で登録されている住所と異なる場合の送付先氏12 届け先電話番号 VARCHAR2 8 顧客情報で登録されている住所と異なる場合の送付先電

話番号9 希望配送日 VARCHAR2 8 配送希望日9 希望配送時間帯 VARCHAR2 1 配送時間帯区分(1：午前中、2:13-15、3:15-18、4:18-20)

No PKEY 項目名属性桁数必須説明1 1 注文番号 NUMBER 2 ○ 受注した注文明細毎の番号（1から昇順）2 2 商品コード CHAR 12 ○ 受注した商品の商品コード3 3 商品単価 NUMBER 6 ○ 受注時点での商品単価（受注時は必須）4 4 購入数量 NUMBER 2 ○ 受注あるいは取り消した商品数5

No PKEY 項目名属性桁数必須説明1 1 終了レコード2 2 受注明細件数 NUMBER 12 ○ 受注明細件数

（ディテールヘッダの受注明細件数と同じ）3

No PKEY 項目名属性桁数必須説明1 1 送信時刻 VARCHAR2 12 ○ 送信処理を開始した時刻

（yyyymmdd/hhmmssの形式）

レコードフッタ

ディテールヘッダ

ディテールボディ

ディテールフッタ

外部インタフェース項目説明

外部インタフェースに含まれる項目に関する定義




バッチ編の紹介バッチ処理の外部設計とバッチ処理以外の設計要素との接点にあたるコツを、４つの「工程成果物」を中心に解説。




帳票編の紹介開発対象となる業務システムで帳票として扱われる出力成果物を設計するためのコツを、５つの「工程成果物」を中心に解説。

見出し

項目１項目２項目３項目４

□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□

見出し


□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□

見出し


□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□□□□ □□□□ □□□□□ □□□

帳票一覧

作成する帳票を一覧化したもの

種類サイズ文字詰表示桁数内部桁数フォーマット出力編集参照先エンティティ参照カラム【ヘッダ部】

1 ページ番号 MSゴシック 8 右詰 3 3 数字(ZZ9)2 伝票内通しページ番号 MSゴシック 8 右詰 3 3 数字(ZZ9) 通番ページ編集ルールに従う3 通番ページ番号 MSゴシック 8 右詰 3 3 数字(ZZ9) 通番ページ編集ルールに従う

4 出力日、出力時刻 MSゴシック 8 左詰 16 14YYYY/MM/DD△H24:MI(出力日と出力時刻の間は半角空白を空けること）

出力時のシステム時刻を設定（伝票単位に更新）

【伝票ヘッダ】伝票単位に出力5 出荷元コード MSゴシック 10 左詰 10 10 文字列出荷トランザクション部門コード6 出荷元名 MSゴシック 10 左詰 28 28 文字列（日本語）部門マスタ表示用部門名7 伝票番号 MSゴシック 10 左詰 10 10 文字列出荷トランザクション出荷Ｎｏ8 届け先コード MSゴシック 10 左詰 10 10 文字列出荷トランザクション納品先コード9 届け先名 MSゴシック 10 左詰 10 10 文字列（日本語）出荷トランザクション納品先名

10 届け先住所１ MSゴシック 10 左詰 40 40 文字列（日本語）出荷トランザクション納品先住所１11 届け先住所２ MSゴシック 10 左詰 40 40 文字列（日本語）出荷トランザクション納品先住所２12 売上区分 MSゴシック 10 左詰 1 1 文字列出荷トランザクション売上区分13 発注区分 MSゴシック 10 左詰 1 1 文字列出荷トランザクション発注区分14 支払期限（年） MSゴシック 10 左詰 4 4 数字支払期限マスタ支払期限15 支払期限（月） MSゴシック 10 左詰 2 2 数字(Z9)16 支払期限(日） MSゴシック 10 左詰 2 2 数字(Z9)

【明細行】17 NO MSゴシック 10 左詰 2 2 数字(Z9) １から昇順にカウントアップ18 品番 MSゴシック 10 左詰 15 15 文字列出荷明細トランザクション品番19 商品名 MSゴシック 10 左詰 24 24 文字列（日本語）商品マスタ商品名20 単価 MSゴシック 10 左詰 10 7 数字（\Z,ZZZ,ZZ9）商品マスタ単価21 数量 MSゴシック 10 左詰 3 3 数字(ZZ9) 出荷明細トランザクション数量22 合価 MSゴシック 10 左詰 14 10 数字(\Z,ZZZ,ZZZ,ZZ9) 合価＝単価×数量

23 消費税額 MSゴシック 10 左詰 10 7 数字（\Z,ZZZ,ZZ9）消費税額＝(単位消費税額×数量）

商品マスタ単位消費税額

24 備考 MSゴシック 10 左詰 24 24 文字列（日本語）出荷明細トランザクション備考【合計行】

25 合計金額 MSゴシック 10 左詰 16 12 数字(\ZZZ,ZZZ,ZZZ,ZZ9) 合計金額＝Σ（合価）26 仮受消費税 MSゴシック 10 左詰 14 10 数字(\Z,ZZZ,ZZZ,ZZ9) 仮受消費税＝Σ（消費税額）

編集様式フォントNo

表示属性項目名

帳票項目説明

帳票レイアウトに基づいて印字されるデータ項目の属性情報を記載したもの

ZZ9／ZZ9 (ZZ9)

YYYY/MM/DD 24:59




No123456789

1011121314151617181920

合計金額うち消費税

以上、確かに納品致しました。●●県△△市□□町４－２１－２２株式会社　　◇◇◇◇◇◇◇◇

ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ






ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ

ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ


ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ

ZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮZZ\Z,ZZZ,ZZＮＮＮＮＮＮＮＮＮＮＮＮXXXXXXXXXXXXXXX \Z,ZZZ,ZZZ,Z \Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ




納品書

1 2 3

4

5

67 8

9

10

11

12

13

納品明細

16px

10px 10px

10px

10px

単　価数量商品名品　番合　価消費税備　考

\Z,ZZZ,ZZZ,ZZZ,Z\Z,,ZZZ,ZZZ,Z

10px

10px

ヘッダ部

伝票ヘッダ部（２ページ目以降は、売上区分、発注区分、支払期限は印

明細行部（25行を超えたら改ページする）

合計行部（最終ページにのみ印刷すること）

14 15 16

17 18 19 20

21

22 23 24

25

26

帳票レイアウト

帳票上で印字されるデータの出力位置、大きさなどを示したもの

処理説明サブシステム名販売管理帳票名納品書業務名販売管理帳票ＩＤ RZCD-01機能名納品書出力出力様式汎用紙用紙サイズＡ４横モノクロレーザ帳票分類明細表改ページ条件あり出力制御条件あり帳票作成方法バッチ出力なし

処理説明全般本帳票は、出荷に伴う納品書を作成するものである。

本帳票は、出荷トランザクションに格納されたデータと出荷明細トランザクションに格納されたデータをもとに納品書を作成する。本帳票は、出荷トランザクションに格納された出荷元コード、伝票番号をキーとして１つの納品書を作成する。出荷される商品の明細データは出荷明細トランザクションに格納されており、必要なデータは発注番号をキーとして抽出する。

改ページ条件発注番号が変わる毎に改ページを行う。同一の発注番号で納品書に印字される出荷明細（納品明細）が２０件を超える場合には、20件毎に改ページを行う。同一の発注番号で改ページが発生する場合には伝票ヘッダ部、フッタ部の処理が異なるので注意のこと。発注番号が変わる毎に合計行部の印字内容も変わるので注意のこと。

ヘッダ部ヘッダ部は改ページされる毎に作成する。ページ番号伝票番号が変わることに１にリセットする。改ページされたら１カウントアップする。伝票内通しページ同一の伝票番号における総ページ数を示す。

同一の伝票番号の明細行は２０件毎に改ページされるので、出荷明細トランザクションにある同一の伝票番号を持つ明細行数の和から総ページ数を算出する。

通番ページ番号本帳票の通しページである。１から改ページ毎に１カウントアップする。出力日、出力時刻印刷処理の行われたシステム時刻を設定する。この時刻は伝票番号毎にリセットする。

伝票ヘッダ部伝票ヘッダ部は改ページされる毎に作成する。同一の伝票番号の納品書が複数枚にわたる場合には、2ページ目以降は売上区分、発注区分、支払い期限は印字しない。

出荷元情報出荷元コード出荷トランザクションの部門コードを設定する。出荷部門部門コードをキーとして部門マスタを参照し、このコードに合致する表示用部門名を設定する。

納品先情報伝票番号出荷トランザクションに格納されている出荷Ｎｏを設定する。お届け先コード出荷トランザクションに格納されている納品先コードを設定する。お届け先名出荷トランザクションに格納されている納品先名を設定する。お届け先住所１出荷トランザクションに格納されている納品先住所１を設定する。お届け先住所２出荷トランザクションに格納されている納品先住所２を設定する。

帳票編集定義

出力項目のデータ転記／編集、改ページ、ヘッダ／フッタの編集要件を示したもの

No 帳票ID 帳票名作成周期出力様式用紙サイズ

プリンタ種別帳票分類改ページ条件

出力制約条件

業務機能作成方法

1 RZAB-01 商品一覧リスト月次 CSV A4横その他一覧表なしなし販売商品管理バッチ出力

2 RZAB-02 商品明細情報表随時汎用紙 A4横モノクロレーザ詳細表なしあり販売商品管理オンライン出力

3 RZBA-01 送付先宛名シールリストその他専用紙 A4縦モノクロレーザ宛名リストなしなし販売販売促進オンライン出力

4 RZCB-02 得意先別受注明細表月次 PDF A4横その他明細表販売売上管理バッチ出力

5 RZCC-01 得意先別請求書（帳票）月次汎用紙 A4横ページプリンタ明細表販売請求管理バッチ出力

6 RZCC-01 得意先別請求書（FAX）月次 FAX A4横その他明細表販売請求管理オンライン出力

帳票の用途、物理的な属性、動作環境、運用要件などについてまとめたもの

サブシステム名販売管理帳票名商品一覧リスト帳票分類一覧表業務名販売管理帳票ＩＤ RZAB-01 出力枚数 100P／回機能名商品管理作成方法バッチ出力作成環境サーバ出力様式 CSV 用紙サイズ A４横プリンタ種別その他出力タイミング月次保存期間－改ページ条件なし出力制御条件なしセキュリティ条件なし指定プリンタなし再出力可利用部門 ○○部門担当者（●●さん）現行帳票名概要商品管理機能の商品情報一覧画面で表示されている商品リストの一覧を出力する

商品一覧は、商品コード、商品名、商品名（カタカナ）、単価、販売開始時期、当月販売可否、当月販売可能数を掲載する。商品の出力順序は商品コード順である。

備考【利用頻度】月１回【出力条件】そのまま印刷可能な状態とすること。【帳票廃止可能性】電子化し再利用できるなら廃止可

帳票概要



外部設計の工程

合意形成の進め方(合意成熟度と4つの作業)

合意形成を図るための作業

言い切る／聞き切る図表に書く

もれ／矛盾をチェックする

一緒にレビューする

図表に書く



言い切る／聞き切る

「機能要件の合意形成ガイド」合意形成とは

（要件定義から）

（次工程へ）合意成熟度のレベル

仕掛

完成

充実



「機能要件の合意形成ガイド」合意形成成熟度と作業

合意成熟度レベル合意形成の進度に応じた分類

４つの作業合意形成の為に行う作業の大まかな分類

レベル仕掛充実完成

各レベルのゴールのイメージ

作業の種類



作業の種類


一緒にレビューする図表に書く


合意成熟度レベル

４つの作業

定義は細かく書いてあるが、読者はなんとなく

分かっていれば十分




合意形成の進め方（合意成熟度のレベル）



作業の種類




仕掛レベル発注者が「言い切っ

た」、開発者が「聞き切った」と言えるレベル

要件定義が完了していなければ、このレベルで実施します。システム化の目的と範囲が明確になっています。

概要編３１ページ～３３ページからの抜粋



充実レベル言い切った／聞き切っ

た内容から「図表に書いてレビュー」を繰り返し、発注者と開発者の合意内容が充実していくレベル





作業の種類

概要編３１ページ～３６ページからの抜粋










作業の種類




完成レベル合意内容が管理され、

発注者と開発者の双方が「合意内容を確認できた」と言えるレベル

外部設計工程の成果物の最終承認直前までのレベル

概要編３１ページ～３６ページからの抜粋




合意形成の進め方（４つの作業）



作業の種類



発注者は要件定義の結果を伝えます。

• システム化の目的・範囲

• 運用時や保守拡張時の操作や業務

• 業務遂行において変えることのできない制約条件（業務や組織構造、連携システムなどにより生じる制約、及び業務上の法令や規則など）

正しく伝えるために、発注者が言い切ること、開発者が聞き切ることです。

概要編３１ページ～４１ページからの抜粋








作業の種類



開発者は

設計書の記述上の約束事を共通ルールとして記述します。

発注者から聞き切った情報を反映して書きます。

レビューで指摘された欠陥を修正します。



図表に書く







作業の種類


開発者は

共通ルール自体にもれ／矛盾がないことをチェックします。

「工程成果物」が共通ルールに沿っていることをチェックします。

他の技術領域の「工程成果物」を含め、整合をチェックします。



図表に書く








作業の種類

発注者の要件と開発者の設計に齟齬がないことをレビューします。

発注者は開発者が想定していない前提や運用がないかをレビューします。

システム化の目的と範囲に照らし合わせて、「工程成果物」が正しく書かれていることをレビューします。




図表に書く




合意形成の進め方(合意成熟度と4つの作業)再掲


外部設計の工程

合意形成を図るための作業

言い切る／聞き切る図表に書く



図表に書く




（要件定義から）

（次工程へ）合意成熟度のレベル

仕掛

完成

充実



「機能要件の合意形成ガイド」目次構成

若干差異はあるが、各技術領域編内部の構成はほぼ同じ

第１章概要

編全体の概要

・前提条件、スコープ

・工程成果物の定義

第２章合意形成に使う主な図表の解説

各工程成果物の詳細説明（サンプル付き）

第３章

合意形成のコツ

コツの紹介

・「４つの作業」別に記述

・「発注者が事前に意識する」が含まれるものがある



「機能要件の合意形成ガイド」コツの読み方

コツの目的：

何を解決したいコツなのか施策：目的達成のために、どうすればよいのかの概要

合意成熟度レベル：

どのタイミングで使えるか

工程成果物：

このコツに登場する工程成果物具体例：

コツの具体例

メリット：

コツ適応による効果



「機能要件の合意形成ガイド」記述例

言い切る／聞き切るためのコツの例




図表に書くためのコツの例




もれ／矛盾をチェックするためコツの例




一緒にレビューするためのコツの例



「機能要件の合意形成ガイド」の適用例（開発者向け書き方／レビュー編）



事例１：わかりにくい設計書

事例：わかりにくい画面遷移ドキュメント

ユーザの役割（一般ユーザ、サプライヤ、管理者）毎に、異なる遷移を表現しようと、以下の様な遷移図を持っていくと、お客様に「意味がわからない」といわれた。

ログイン画面ログイン画面

《開始点》

メニュー画面メニュー画面

商品一覧画面（ユーザ）商品一覧画面（ユーザ）

《終了点》

商品一覧画面（管理者）商品一覧画面（管理者）

《終了点》

商品一覧画面（サプライヤ）商品一覧画面（サプライヤ）

《終了点》

トップページトップページ管理者トップページ管理者トップページサプライヤトップページサプライヤトップページ

[一般ユーザの場合][管理者の場合]

[サプライヤの場合]


[サプライヤの場合]発注者側（お客様）

遷移と分岐がゴチャゴチャしてて分からん…




何故、そのようなことになってしまったのか？ユーザ役割毎に画面遷移順序が異なるにも拘わらず、１つの画面遷移

ドキュメントに収めてしまったから。

ログイン画面ログイン画面

《開始点》

メニュー画面メニュー画面

商品一覧画面（ユーザ）商品一覧画面（ユーザ）

《終了点》

商品一覧画面（管理者）商品一覧画面（管理者）

《終了点》

商品一覧画面（サプライヤ）商品一覧画面（サプライヤ）

《終了点》

トップページトップページ管理者トップページ管理者トップページサプライヤトップページサプライヤトップページ





一般ユーザの遷移

管理者の遷移

サプライヤの遷移

画面遷移の例

商品一覧(ユーザ編)画面遷移商品一覧(管理者編)画面遷移商品一覧(サプライヤ編)画面遷移

[ログイン ]

[メニュー選択]

ログイン画面（共通）

トップページ

メニュー画面（共通）

商品一覧画面（ユーザ）

[業務種類選択]

《開始点》

《終了点》

[ログイン ]



管理者トップページ


商品一覧画面（管理者）


《開始点》

《終了点》

[ログイン ]



サプライヤトップページ


商品一覧画面（サプライヤ）


《開始点》

《終了点》

望ましい書き方はユーザ役割別に画面遷移を作成する




適用できるコツ（書き方のコツ）



事例２：出来上がった画面遷移をレビューする

事例：出来上がった画面遷移の過不足についてレビューしたい出来上がった画面遷移が過不足なく記述されていることを確認したい。

どうすればいい？

ログイン画面

メニュー画面書籍検索画面

注文入力画面

注文結果確認画面

受付状況確認画面

書籍登録画面書籍登録確認画面

［ログイン］

［受付状況確認］

［書籍検索］

［注文入力］

［注文］

［確認］

［書籍登録］

「OK」「閉じる」

「OK」「閉じる」

開発者側

単に追いかけるだけじゃ芸がないよな…



事例２：出来上がった画面遷移をレビューする

適用できるコツ（レビューのコツ）



事例３：発注者と一緒にレビューする

事例：出来上がったデータモデルについてレビューしたいデータモデルのレビューが表面的になりがち

お客様に、データ構造の意味（出来ること／出来ないことなど）をしっかり伝えるにはどうすればよい？

対象ER図の例

売取引

取引ID

商談ID (FK)

楽器番号 (FK)

取引ステータス希望価格

取引発生日

顧客

顧客ID

顧客名連絡先

商品

楽器番号

ステータス

買取引

取引ID

商談ID (FK)楽器番号 (FK)希望価格取引ステータス取引発生日

取引グループ

グループID

顧客ID (FK)発生日終了日

開発者側発注者側（お客様）

大丈夫かな… たぶん、良いんじゃないかな．．．



事例３：発注者と一緒にレビューする




事例のまとめ（適用する上での注意事項）

取り上げたものは、「お客様との齟齬を防止するノウハウ」ガイドにおいてはこのノウハウをコツと呼ぶ

「機能要件の合意形成ガイド」はこのようなコツが満載

コツについてケーススタディからわかることどの局面にも通用するわけではない

コツの適用可能/不可能はプロジェクト（システム）の特性により異なる。

（例えば、CRUD図は顧客納品物/レビューの対象ではない。）

唯一の解ではない

たとえば、画面遷移の過不足をチェックする方法はこれだけではない

コツは“森”ではなく“木”に近い

大局的な作業プロセスや、成果物構成などを規定するものではなく、特定の場面において役立つノウハウ（記述の仕方、振る舞い）。



「機能要件の合意形成ガイド」の適用例（発注者への要求確認編）



事例１：例外業務システム処理の設計漏れ

事例：会計システムの振込処理における誤振込時の組戻し処理の漏れ会計システムの振込処理において、誤振込が発生した場合、財務部が金融機関に連

絡をした上で、振込データの戻しとこれに伴う会計処理（組み戻し処理）を行うことになっているが、会計システムでは組み戻し処理が設計されていなかった。

本番直前の運用テストの段階で財務部からの指摘で組み戻し処理が抜けている事が判明。急遽追加することになった。

経理部門担当者

当社の支払処理は銀行振込の場合、・・・・・・・・・という手順となります。ここはシステム化の対象です。

<<人の作業>>

<<システム支援>>


販売部門出荷部門（倉庫）

仕入先

<<システム>>

<<システム>>

進捗登録

顧客登録物件仮押

顧客の登録

意思の確認

テナント契約

業務フロー

財務部門担当者

万一、振込口座が誤っていて誤振込になった場合には、銀行に連絡するとともに組戻し処理を行います。

開発担当者ふむふむ。

ヒアリング時

<<人の作業>>




仕入先

<<システム>>

<<システム>>

進捗登録


顧客の登録

意思の確認

テナント契約

システム化業務フロー

なるほど、そういう処理の流れになるんですね？


経理部門担当者開発担当者

振込結果はどうわかるの？

レビュー時システム化される振込処理の流れは次のようになります。




何故、そのようなことになってしまったのか？レビュー時に業務フローとシステム化業務フローを比較・検証しなかったから

。システム化業務フローを見ていただけでは例外業務である組み戻し処理が抜けていることに気付かなかった。


<<人の作業>>




仕入先

<<システム>>

<<システム>>

進捗登録


顧客の登録

意思の確認

テナント契約

業務フロー

財務部門担当者開発担当者

ヒアリング時

ヒアリングでは、業務フローを使って、業務の流れとその中からシステム化対象の業務を確認していた。

<<人の作業>>




仕入先

<<システム>>

<<システム>>

進捗登録


顧客の登録

意思の確認

テナント契約



経理部門担当者開発担当者

レビュー時

レビューでは、システム化業務フローを使って、システム化対象の業務の流れとシステムとのやりとりに齟齬がないかを中心に確認していたため、対象業務に漏れがないかの確認ができていなかった。

業務フローとシステム化業務フローの比較・検証を行い、システム化対象業務の漏れがないかを確認していなかった




適用できるコツ（言い切る／聞き切るコツ）



事例２：業務運用パターンの確認漏れ

事例：売上伝票入力の承認のやり方が不十分と開発途中で発覚

発注者は開発者にシステム化対象業務の説明する際に、開発者に業務の流れを理解してもらおうと思い、最もシンプルなフローで「営業部で手続き」等の曖昧な表現で流れを説明した。その際、伝票入力者と承認者等の役割（ロール）の違いは後で確認されると思い、説明しなかった。

開発者は説明されたとおりに、入力処理と承認処理を同一画面で行うよう設計した。またワークフローもシンプルな構成のものを想定した。

権限階層やワークフローの実態が明確になるにつれ、当初開発者が想定していた規模よりも大きな規模の開発である事がわかり、予算の追加と工期の延長が必要となってしまった。

<<人の作業>>




仕入先

<<システム>>

<<システム>>

進捗登録


顧客の登録

意思の確認

テナント契約


営業部門担当者

開発担当者

ヒアリング時

なるほどそうですか。

システム化される発注処理は各部署でデータ入力して、承認するという流れとなっています。

伝票入力者

伝票承認者承認代行者

内部統制上、伝票入力者と伝票承認者は別々にし、承認者も代行をおけるようになっているが、その辺は販売担当のSEなら常識でわかってくれるよね？




何故、そのようなことが起こってしまったのか？

発注者が、各部署には入力権限、承認権限、代理承認権限のユーザーがいるにも拘らず、役割（ロール）を正確に伝えなかった、また実際のワークフローもデータの内容により複雑な分岐となることを説明しなかったため。

開発者は入力処理と承認処理が分かれていることを確認しているにも拘わらず、入力処理と承認処理の利用者の相違、入力処理、承認処理それぞれの流れについて確認を怠っていたため。

<<人の作業>>




仕入先

<<システム>>

<<システム>>

進捗登録


顧客の登録

意思の確認

テナント契約



開発担当者

ヒアリング／レビュー時入力処理と承認処理に分かれていますが、それぞれの処理を担当する役割は異なるのでしょうか？

また入力処理から承認処理までの一連の処理の流れを確認させていただけませんか？

承認処理はどういう場合でも同一ですか？弊社の場合、受注金額で承認できる職位が異なるんですが？



事例３：要求した画面イメージと異なる

事例：発注者からの注文入力画面に関する不十分な要求

注文入力画面は、同一画面上段に入力欄、下段に注文履歴欄を設け、注文履歴を確認しながら注文入力を行うという要件であるが、発注者は開発者に単に「注文履歴を確認しながら注文入力が行えるよう」という曖昧な要件を伝えたのみで画面レイアウトの提示をしなかった。

開発者は要件に沿うよう注文入力画面と注文履歴画面を分けて設計した。

発注者はレビューの段階で注文入力画面がイメージと異なる事に気付き、急遽仕様変更することになった。

発注者：

注文数：

注文ｷｬﾝｾﾙ

注文入力画面

商品名：

注文番号：

合計

本日の受注一覧：注文番号発注者商品名注文数

注文入力画面と注文履歴画面があり、注文履歴を見ながら注文入力できるようにしてほしい

発注者：

注文数：


注文入力画面

商品名：

注文番号：

合計


メニュー

注文入力

注文履歴

わかりました

開発担当者営業部門担当者

１つの画面で２つの画面で





発注者が具体的な画面レイアウトの提示をしなかった、また開発者が発注者に確認しなかったから。

開発者と発注者の間で業務の流れに沿った注文入力画面と注文履歴画面の流れ、利用シーンを確認しなかったから。

ログイン画面

メニュー画面

注文入力画面

複数件数ある場合

注文入力終了

注文検索画面

確認終了

注文一覧画面

注文更新画面

更新終了

発注者：

注文数：


注文入力画面

商品名：

注文番号：

合計


こんな画面の遷移と画面のイメージでよかったでしょうか？

開発担当者


????



事例：一括注文取消処理の画面遷移がおかしい注文一括取消処理は「発注履歴画面にて取消対象を複数選択後、注文取消画面に遷移し、

選択した個々の注文内容を確認しながら取消処理を選択数分連続して行う」という要件を開発者に提示した。

出来上がったシステムを確認したところ、「発注履歴画面（2件選択）→注文取消画面（1件目）→注文取消画面（2件目） →発注履歴画面」と遷移して欲しいところが、「発注履歴画面（2件選択）→注文取消画面（1件目） →発注履歴画面→注文取消画面（２件目）→発注履歴画面」というように都度発注履歴画面に戻るようになっていた。

削除したい注文を選択（複数）

注文取消画面（取消注文１）注文履歴画面

実行

取消の適否確認

実行

取消注文１に対する注文取消処理および注文取消画面（取消注文２）の表示

注文履歴画面

注文取消画面（取消注文１）

注文取消画面（取消注文２）

実行

削除したい注文を選択（複数）

実行

取消注文１に対する注文取消処理

取消注文２に対する注文取消処理

発注者

開発者

事例４：意図しない画面遷移




何故、そのようなことが起こってしまったのか？レビューでは発注履歴画面と注文取消画面の確認はしたが、画面遷移の確認を

怠ってしまったから。

注文履歴画面画面レイアウト

注文取消画面画面レイアウト

開発者

レビュー時

注文履歴画面注文取消画面

注文取消画面

注文取消画面画面遷移

レビュー対象外

この画面の表示項目は・・・・・・で、操作手順は・・・・・・・・・・・となります。これでＯＫですか？

発注者

ふむふむ。その操作手順でＯＫです。



事例５：無駄な類似した帳票の開発

事例：異なる現場部門から類似した内容の帳票開発要求大規模システム開発のため、発注者側は設計担当者を業務領域毎に分け、個々に帳票レイア

ウト定義を実施。担当者毎に完成時期が異なり、工期も厳しかったため、発注者側は帳票類の整理と合理化の手間を省き、帳票レイアウト完成の都度五月雨式に開発者に提示。

出来上がった帳票を俯瞰すると同じような帳票を幾つも作成してしまい、その無駄を開発担当者から指摘された。

発注者調整役

開発者

この帳票はこのレイアウトでないと使えません。

このレイアウトで何年も業務をしてきたので今更変更できません。

この帳票はうちの部門のノウハウの塊です。変更は無理です。

部門Ａ担当者

部門Ｂ担当者

部門Ｃ担当者

整理・統合調整できず

開発依頼

開発依頼

開発依頼

出力項目もレイアウトもかなり類似しているのに、それぞれ作る必要があるのかな？確認してみよう。

ここここここここここここここここここ





業務担当毎に設計した帳票類を一旦発注者側内部で整理、合理化した上で開発者に開発すべき帳票を提示すべきだったが、厳しい工期で各業務担当部門との調整をつけられず、業務担当毎に必要な帳票の開発依頼をかけたため。

帳票の利用目的、必要な理由の確認が不十分なまま開発依頼を行ったため。

この帳票はこのレイアウトでないと使えません。

このレイアウトで何年も業務をしてきたので今更変更できません。

この帳票はうちの部門のノウハウの塊です。変更は無理です。

部門Ａ担当者部門Ｂ担当者

部門Ｃ担当者

この帳票の利用目的は××なので、代替策があるなら考えます。

この帳票は半年に１回だけ利用します。

この項目とこの項目を演算した結果あればよく、多少の変更はできるかも。Ａ部門の帳票１とＢ部門の帳票２と

Ｃ部門の帳票３はほとんど同じ内容ですが、どのような使われ方をしていますか？

３帳票で異なるのはこの部分だけで、使われ方も３部門とも同じようなのですが、統一すると問題になるのはどんなことですか？

こうした調整を図り、帳票を最低限必要なものに絞りたかった

発注者調整役



事例６：現場業務に精通しない担当者からの帳票要求

事例：現場業務に精通していない業務設計担当者からの帳票開発要求

発注者側の業務設計担当者は現場の業務にあまり精通していなかったが、開発者は業務設計担当者の提示する要件に基づいて帳票設計を実施した。

展開時のユーザー向け説明会で、現場の利用者から帳票に承認印欄が不足しているとの不備を指摘され、急遽設計変更を行うことになった。

開発者発注者側

業務設計担当者現場業務担当者

この帳票の仕様は、・・・・・のようになっています。

現場業務に詳しくない

現場担当者には未確認

はいわかりました。そのように開発します。

開発

折角作っていただいたのに、この帳票には承認印欄がないので、業務では使えません。



事例６：現場業務に精通しない発注者の帳票要求


現場の業務担当者に開発する帳票の仕様に関して意見を聴いていなかったから。帳票レビュー迄に現場の担当者の意見も聞いておけばこのような事態にならなかった。

開発者発注者側

業務設計担当者現場業務担当者

このような帳票の仕様で現場業務で適用していただけますか？何か問題はありませんか？

この帳票のままでは承認印欄がないので、業務では使えません。追加するようにお願いします。

帳票レビュー前に内部で確認しておくべきこと



事例６：現場業務に精通しない発注者の帳票要求




適用事例のまとめ(1/3)

発注者が開発者に曖昧な要件を提示すると、出来上がるシステムは発注者が意図するものと異なるものとなる可能性が高くなる。出来るだけ要件の曖昧さを排除し、開発者に正確に伝える事が肝要

言い切るコツの活用（特にコツID02T001）発注者はシステムに求めるイメージ、業務上のルール、仕事のやり方などを文書にとりまとめ、具体的に開発者に伝える。

発注者は開発者に要件を正確に伝えた心算でいても、正確に伝わっているとは限らない。要件が正しく伝わっている事を確認する事が肝要

レビューのコツの活用



まとめ



おさらい：機能要件の合意形成ガイドとは?

外部設計工程で発注者と受注者の次の作業で合意を得るためコツをまとめたもの。言い切る／聞き切る

図表にまとめる

もれ／矛盾をチェックする（受注者の内部レビュー）

一緒にレビューする（発注者と受注者が）

概要編と次の６つの技術領域のガイドからなる。画面編

システム振る舞い編

データモデル編

外部インターフェース編

帳票編

バッチ編



どのような場面で使うことを想定して作ったか？・・・活用のヒントとして

1. 開発標準に沿った設計業務を補足するコツ集として設計に関するドキュメントを介して、ＳＩベンダの開発担当者間、

あるいは開発担当者とユーザ企業情報システム部門・ユーザとの間のスムーズな意思疎通をはかるために利用する。

2. 教育コンテンツの素材集としてＳＩベンダやユーザ企業の情報システム部門を中心に、

各社の教育コンテンツの素材集として利用する。

3. レビューに臨む際の心得として情報システム開発のステークホルダ間のコミュニケーションを

円滑にするために、レビューのコツを利用する。

どのように使ったらよいか？



活用事例活用のヒントとして（旧発注者ビューガイドライン時の適用事例）


# 企業（順不同）状況

１㈱ＮＴＴデータ開発手順に適用。具体的には、発注者ビューガイドラインをベースに成果物の記述項目と図の凡例を見直し。また、”コツ”については社内の既存のチェックリストと統合。

２富士通㈱標準開発プロセスの設計書の記述要項、記述例、ワークシートの改善を実施済み。

３日本電気㈱社内向けの設計ガイドとして、開発プロセスに合わせてどの作業、どの設計ドキュメントで適用するかを他の設計ガイドと連携させ独自にガイドとして再編集して利用。

４㈱日立製作所標準開発プロセスの設計書の記述要項、記述例、ワークシートの改善を実施済み。

５㈱構造計画研究所社内規定「機能設計書記述要領」の１つとして組み入れ、公開。

６東芝ソリューション㈱情報システム開発標準群の１つとして組み入れ、社内公開。また、コツの使用について優先度表を作成し、併せて公開。

７日本ユニシス㈱社内の（開発関連）知財として管理し展開（公開）するとともに、SE向け説明会等での（書籍も含めた知識の）活用、説明会の実施など。）

８ＴＩＳ㈱社内向け設計ガイドに発注者ビューガイドラインの記述要素を取り込み。発注者ビューガイドライン自体も参考文書として社内公開。

９沖電気工業㈱ 2008年度より、開発標準に適用。具体的には、発注者ビューガイドラインをそのまま採用せずに、システム設計書作成規定の「参考資料」として組み入れております。

10 ㈱インテックガイドラインと社内設計標準の関連付けを実施。その対比表を基に適切な局面でガイドの該当箇所を参照し、活用するように社内に案内。

11 ㈱東京証券取引所社内の参考情報とするとともに、社内システム開発プロセスへの組込みを検討中。

12 清水建設㈱ 2008年上期に特定アプリケーションの開発案件において、「画面編」を適用し、評価を実施。

「発注者ビューガイドラインの活用と拡張～機能要件の合意形成を目指して～」（ 2009年3月31日）からの抜粋・要約




悩み・気づき・ヒント

‼ 設計書レビュー時に、基本的なことの指摘が多くありませんか？

そんな時には「機能要件の合意形成ガイド」を一度見てみよう。 ⇒そこには発注者と開発者間の合意をより良くするためのヒントがあります。

‼ テスト結果の確認や検収時に、手直し要望が多くありませんか？

‼ カットオーバ後に、すぐ手直しということが多くありませんか？



おわりに

情報処理推進機構：ソフトウェアエンジニアリングhp.mht

ダウンロードはこちらから･･･http://sec.ipa.go.jp/reports/20100331.html

7冊構成

DVD-ROMにも含まれています

http://sec.ipa.go.jp/




以上です。

ご清聴ありがとうございました。




ご参考：要件定義のレベルアップ～よりよい合意形成をするために～

「合意形成は発注者と開発者の協同作業であり・・・」の考え方が、要件定義の際にどのように活用できるか？

要件定義を行う際に、ステークホルダ間の合意の取り付けを十分に行ってください。もし、決め切れないことがあったら、課題管理を行ってください。あいまいなままシステムを作り始めると品質・コスト・納期に多大なる影響を及ぼすことがあります。



ご参考：要件定義工程での「ガイド」の活用

「データモデル編」言い切る／聞き切るためのコツより

目的施策（コツ）

用語、単語の解釈の齟齬を防止するには

発注者は業務用語（業界用語、社内用語）の辞書を提示し、説明する。

自社のデータ標準に適合したデータ項目定義にするには

発注者は自社で管理しているマスタやデータ項目の標準について、データ標準を定義したドキュメントを提示して、説明する。データ標準がない場合は、関係部門と整理した結果を提示し、説明する。

社内外の関連システムと整合性の取れたコード定義とするには

発注者は業界標準も含めて自社で使用している既存コードとその値を提示する。

要件定義書に記載する




次頁以降に例示



「ガイド」の活用

「外部インタフェース編」発注者が事前に意識すべきコツより




「システム振舞い編」言い切る／聞き切るためのコツより

目的施策（コツ)

発注者が意図を正しく、言い切るには

発注者は、事前にシステムに求めるイメージ、業務上のルール、仕事のやり方などを文書に取りまとめ、具体的に開発者に伝える。

発注者が業務を正しく伝えるには発注者は、５Wを明記した業務の流れがわかる文書や内容がわかる一覧を用意し、システム化の対象としたい部分を区別して開発者に伝える。

運用管理や環境設定関連機能の考慮漏れを防ぐには

発注者は利用者の機能要件だけでなく、管理者が実施するマスタ管理や運用管理業務機能（カレンダー類、処理制御情報類など）の機能についても説明することで、必要機能の漏れを防ぐ。

他システムおよび社外から受けるあるいは、与える業務上の影響を評価するには

発注者は、他のシステムや社外とのデータ授受の前提・制約条件を明確にするために、データ授受のタイミング、方法、期限、媒体などを社内外の関係者と事前合意したうえで、開発者に説明する。

業務の品質に重大な影響を与える事項を開発者に漏れなく伝達するには

発注者は、システム化業務の特性（オンライン受付件数やレスポンス目標値など）を社内の関係者と事前合意したうえで、開発者に説明する。





次頁に例示




「画面編」言い切る／聞き切るためのコツより目的施策（コツ）

ユーザが使いやすい画面にするには発注者は、利用者層や利用者の情報リテラシ、利用環境も含めたシステムの画面操作性に関する標準を作成し、標準に基づいて内容を説明する。

画面の全体整合性をとるには

発注者が予め、画面のボタン等の機能を入力系・承認系などのように分類し、同一の機能で複数の画面に現れるものは、体裁やその後のアクションの統一を行い確認する。

業務上重要な画面を確実に確認するには発注者が業務上クリティカルな利用シーンを確実に開発者に伝えるために、画面レイアウトや画面遷移イメージを作成し特定して説明する。

画面の種類及び遷移方法が分かるようにするには

発注者が画面遷移と画面呼び出し（ポップアップ）など、画面の種類及び遷移方法の記載を分けて伝える。

既存システムの改善・変更の場合、画面各々について既存・変更・新規が分かるようにするには

発注者が新規作成する画面・変更対象画面・既存画面別に色分けするなど、遷移図の凡例を工夫し、対象を明確に伝える。

画面種別毎における入出力仕様を確認するには

発注者が画面種別毎に、入力帳票・管理方法など入出力項目に関わる内容を明確にする。












「外部インタフェース編」発注者が事前に意識すべきコツより

information-technology promotion agency, japan 機能要件に関す … · 技術本部...

Documents