要件定義書（本編）が必要な方は、こちらの記事からダウンロードいただけます。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.はじめに

申し送り事項一覧に関しては、前の工程で決まり切らなかった仕様や課題などについて、後工程で検討するために記録して残しておくものとなります。

要件定義工程では、要求事項を取り纏めますが、詳細な設計などについては、設計工程以降で検討する内容となりますので、申し送り対象として記録しておきます。

そのほかには、本来要件定義で決めるべきものが、決めきれなかったりした場合にも後続フェーズで引き続き検討が必要な場合がありますので、この場合にも申し送りとして記録しておきます。

1.申し送り事項一覧（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更（例では、「移行要件定義書」として設定）

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

もしくは、要件定義以外でも申し送り事項として利用する場合もあると思いますので、その場合本書の構成は不要であれば削除してご利用ください。

4.申し送り事項一覧

申し送り事項について、一覧形式で以下の内容を記録していきます。

• No.：シーケンスで番号を登録しておきます。
• カテゴリ：申し送りの種別（課題、仕様検討、タスクなど）を定義します。複数のカテゴリが必要であれば列を追加して大中小などで管理してください。
• 件名：申し送りの内容がすぐにわかるようにタイトルをつけておきます。
• 申し送り内容：申し送りの内容を記入しますが、後工程で担当者が変わる場合には内容がわかるように丁寧に記載しておく必要があります。
• 申し送りの経緯（理由）：申し送りとなった経緯や理由があれば記載しておきます。
• 起票者：申し送りを記入した担当者の名前を記入
• 起票日：申し送りを記入した日付を入力
• 承認者：申し送りの内容について承認した方の名前を記入します。（基本的にはお客様のプロジェクト責任者を記入）
• 承認日：申し送りの内容が承認された日付を入力
• 備考：備考があれば記入

以上となりますが、上記以外に必要な添付ファイルがあれば、別紙や補足資料としてページを追加しておきましょう。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

要件定義_要件定義書_別紙9「申し送り事項一覧」（Excel版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。

もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

PPT（パワーポイント版）のテンプレートはこちらで提供しています。

参考

Salesforce導入プロジェクト 要件定義書_別紙4「非機能要件定義書」テンプレート

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.はじめに（非機能要件の検討にあたって）

非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。

非機能要件の検討が初めてという方は、以下IPAが提供する非機能要求グレードのエクセルから全体像とそれぞれの要求事項の中の定義を再確認しておくことをお勧めします。

図１「IPA（情報処理機構）非機能要求グレードの（06_活用シート.xls）「https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html」

上記のエクセルには、システム導入にあたって検討するべき非機能の全体像を確認することができます。

資料をダウンロードして全体をみていただくとわかると思いますが、非機能要件で検討するべき項目はかなりのボリュームがあります。

行政機関や金融機関など、かなりの大規模案件で、非常に高いセキュリティなどが求められるのシステム開発では、かなり詳細までこれらの全体像にたいして検討する必要が出てきますが、非機能の検討だけでかなりの期間や工数を要する作業となり、またインフラやセキュリティなど高度な専門性が求められる領域でもあるため、中規模以下の案件では、これらの中から最低限検討するべき非機能についてのみ検討・実施を行うというのが現状かと思います。

幸いなことにSalesforceはパブリッククラウドサービスのため、多くの非機能に関する要件はSalesforce側で自動的に制御、運用される部分が多いため、一般的なシステム開発と比べて検討すべき事項はかなり絞り込まれます。

※Salesforceのヘルプサイトなどを検索すると非機能要求に対するSalesforceとしての回答も記載されているものがあるので、非機能要件の検討の際にはその回答ベースに検討を行うこともできます。

上記の図でセールスフォースは、SaaS型サービスのため、ハードウェア、ネットワーク、負荷分散、障害対策など管理が難しい部分は、全てSalesforceのサービスとして管理・運用されます。

まず、基本はお客様のRFPで提示されている非機能の要求事項に対しては必ず検討対象とし、その他、権限やセキュリティなどリスクが高い項目については最低限検討すべきかと思います。

また、業務内容によっては、処理性能や高いユーザビリティなどが求められることもあるため、業務要件の整理の際に検討するとよいでしょう。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

要件定義書の別紙４として非機能要件定義書を定義していますが、プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

5.RFPの要求仕様（非機能要求）

最初に、RFPで要求されている非機能要件がある場合には、その内容を定義しておきます。

最低限こちらに記載の要件については要件定義の中で検討する必要があります。

6.非機能要求の分類

続いては、本書で取り扱う非機能要求とその分類を定義しています。

上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。

非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。

纏め方や呼び方はプロジェクトや作成者によって多少異なると思いますが、それぞれのカテゴリの中で検討すべき事項が網羅されていて、わかりやすく定義されていれば問題ないです。

7.非機能要件詳細

ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。

ユーザビリティに関する記載例

1. 利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部　役割：全国各支部の活動状況の把握・分析　/　利用ユーザ：100名　ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
2. クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
3. 使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
4. 操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
5. 入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
6. システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

補足

これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、Salesforceの非機能要件への対応方針やプロジェクト個別の対応方針など具体的な施策に関しては、上記とは別に詳細な資料を作成して説明するとよいでしょう。

例えば、可用性については以下の例のような資料を作成して説明するなど。

１．可用性（継続性・耐障害性・災害対策・回復性）

Salesforce（パブリッククラウドサービス）を利用するため、指定日時でのメンテナンスの制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

可用性の各項目については、開発ベンダー側では制御できない内容となるため、基本的にSalesforce社の可用性に対する回答の内容を説明するだけとなります。

【重要】Salesforceは、実績として99.9% の稼働率となっていますが、セールスフォース社としては、SLAや個別契約などで可用性に関して担保するようなサービスは提供していません。（※2022年3月現在）

そのため、同社が提供するサービスとしての可用性はこのようになっていますという説明とともに、制約事項として承諾していただく必要があります。

リアルタイムのサービスの運用状況やインシデント、メンテンナンス状況については、Salesforceが提供する以下、「Salesforce Trustサイト」にて、運用担当者にて確認してもらう運用が基本となることを合わせて説明しておくほうがよいでしょう。

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

Salesforceサービスは拡張性と冗長性にすぐれているため、需要の変動やユーザの増加にも対応できるうえ、長時間のサービス停止リスクも大幅に軽減されます。設計面では、ネットワークの負荷分散、アプリケーションサーバのプール、およびデータベースのクラスタ化を特徴とします。

災害対策、回復性

事業（業務）継続性の要件として、災害対策の検討がありますが、Salesforceのサービスは単一拠点（一か所）での障害によって、サービスが中断してしまわないように地理的に離れた場所に複数のデータセンターが設けられています。

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

など。

サポーターさん

各非機能要件に対する具体的な定義例や補足資料のサンプルは別途記事を作成してご紹介したいと思います。

今回はここまでとなります。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

非機能要件の検討にあたっては、非機能要求事項の全体像を把握している必要があると思います。

1.はじめに（非機能要件の検討にあたって）

非機能要件の検討が初めてという方は、以下IPAが提供する非機能要求グレードのエクセルから全体像とそれぞれの要求事項の中の定義を再確認しておくことをお勧めします。

図１「IPA（情報処理機構）非機能要求グレードの（06_活用シート.xls）「https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html」

上記のエクセルには、システム導入にあたって検討するべき非機能の全体像を確認することができます。

資料をダウンロードして全体をみていただくとわかると思いますが、非機能要件で検討するべき項目はかなりのボリュームがあります。

行政機関や金融機関など、かなりの大規模案件で、非常に高いセキュリティなどが求められるのシステム開発では、かなり詳細までこれらの全体像にたいして検討する必要が出てきますが、非機能の検討だけでかなりの期間や工数を要する作業となり、またインフラやセキュリティなど高度な専門性が求められる領域でもあるため、中規模以下の案件では、これらの中から最低限検討するべき非機能についてのみ検討・実施を行うというのが現状かと思います。

幸いなことにSalesforceはパブリッククラウドサービスのため、多くの非機能に関する要件はSalesforce側で自動的に制御、運用される部分が多いため、一般的なシステム開発と比べて検討すべき事項はかなり絞り込まれます。

※Salesforceのヘルプサイトなどを検索すると非機能要求に対するSalesforceとしての回答も記載されているものがあるので、非機能要件の検討の際にはその回答ベースに検討を行うこともできます。

上記の図でセールスフォースは、SaaS型サービスのため、ハードウェア、ネットワーク、負荷分散、障害対策など管理が難しい部分は、全てSalesforceのサービスとして管理・運用されます。

まず、基本はお客様のRFPで提示されている非機能の要求事項に対しては必ず検討対象とし、その他、権限やセキュリティなどリスクが高い項目については最低限検討すべきかと思います。

また、業務内容によっては、処理性能や高いユーザビリティなどが求められることもあるため、業務要件の整理の際に検討するとよいでしょう。

1.非機能要件定義書（サンプル）

テンプレートとして提供しているサンプルの書式を使って説明していきます。

1.表紙

画像はクリックすると拡大表示されます。

表紙については、以下の箇所をプロジェクトに合わせて変更してください。

情報種別：社外秘など

情報所有者：基本的にはお客様の会社名となります。

会社名：自社の会社名（正式名称）を記入してください。

タイトル：ドキュメントのタイトルをプロジェクトに合わせて変更

版数、作成日、作成者：※必要に応じて、最終更新日、更新者を入れてください。

2.改訂履歴

3.本書の構成

要件定義書の別紙４として非機能要件定義書を定義していますが、プロジェクトによっては、要件定義書の本体の章立ての中に組み込むこともあると思いますので、適宜修正してご利用ください。

4.はじめに（本書の目的）

非機能要件定義書の目的や位置づけなどについて記載します。※不要なら削除して構いません。

5.RFPの要求仕様（非機能要求）

最初に、RFPで要求されている非機能要件がある場合には、その内容を定義しておきます。

最低限こちらに記載の要件については要件定義の中で検討する必要があります。

6.非機能要求の分類

続いては、本書で取り扱う非機能要求とその分類を定義しています。

上記のように種別１が1から10までの定義となっており、種別1の中でさらに種別2として詳細な要求種別として定義しています。

非機能要件の分類の分け方については、IPAの非機能要求グレードの整理をベースとするとよいでしょう。

纏め方や呼び方はプロジェクトや作成者によって多少異なると思いますが、それぞれのカテゴリの中で検討すべき事項が網羅されていて、わかりやすく定義されていれば問題ないです。

7.ユーザビリティ要件詳細

ここからは各非機能の要求種別に応じて、具体的な要求仕様を定義します。

1. 利用者（ユーザ）の定義：本システムを利用するユーザの所属、組織構成（階層）、担当業務、役割（申請の承認）、作業内容など（例）組織：本部　役割：全国各支部の活動状況の把握・分析　/　利用ユーザ：100名　ユーザ特性：Excelなどは使い慣れているがBIツールなどの利用経験なし
2. クライアント端末：ユーザが利用するクライアント端末（PC/スマホ/タブレットなど）、利用者、利用場所など（例）PC端末（OS：Windows10、ブラウザ：Chrome最新バージョン）、社用携帯（iPhone/Android）、タブレット（iPad）
3. 使いやすさを求められる業務処理：システムの使いやすさを求められる業務や処理（例）システムの使いやすさを求められる業務や処理について、Salesforceのプロトタイプを作成して、システムを利用する現場のユーザの方の意見を聞きながらアジャイル的に開発を行い、UI/UXの改善を図るなど
4. 操作性（操作のしやすさ）：システム操作について、直観的で簡単に操作可能、最小限の入力で登録可能など
5. 入力補助、誤操作防止：不整値の入力防止や、入力候補を表示するなど
6. システム理解や習得のしやすさ：利用者が理解しやすい操作やメニュー、ヘルプの表示、システム操作に関するマニュアルの用意など

8.アクセシビリティ

1. ウェブアクセシビリティ：ターゲットユーザのみではなく、本システムを利用する可能性のあるすべてのユーザ（高齢者や障碍者を含む）を考慮したデザインや操作性

9.可用性

可用性：（機器の故障・災害・アクシデントなどによる障害でシステムを停止させることなく稼働し続けること）について、（システム）継続性、業務継続性、目標復旧水準、稼働率、耐障害性、データの保護、災害対策について、それぞれの要件を確認して定義します。

1. 継続性：システム稼働時間や停止に関して（通常運用時間、計画停止（メンテナンス）スケジュールなど）
2. 業務継続性：可用性を保証するにあたり要求される業務範囲と条件（障害発生時のサービス切替時間など）、業務継続性の要求度合い
3. 目標復旧水準：業務停止を伴う障害発生時、何をどこまで、どの程度復旧させるかの目標 RPO(目標復旧地点）、PRT（目標復旧時間）、RLO（目標復旧レベル）など
4. 稼働率：明示された利用条件の下で、システムが要求されたサービスを提供できる割合（例）稼働率：99.99%
5. 耐障害性：サーバで発生する障害に対して、要求されたサービスを維持するための要求。機器、ストレージの冗長化、ネットワーク回線、経路の冗長化など
6. データの保護：データの保護方式（バックアップ方式）、データ復旧範囲、データインテグリティ：改ざんや偽装を防ぎ、データの完全性と正確性が客観的に担保されていること）
7. 災害対策：地震、水害、テロ、火災などの大規模災害時の業務継続性を満たすための要求※Salesforceがサービスとして提供している対策をベースに検討

10.規模・拡張性

1. 利用者：本システムの稼働時点の想定利用者、利用者数、利用時間帯、アクセス方式など　※将来の見込み数も算出
2. 業務処理量：日別・月間のオンラインリクエスト件数、バッチ処理件数、PV、アクティブ接続数、時間平均接続数、ピーク時の接続ユーザ数、同時接続数、帳票出力枚数（日別、月別）など
3. データ量：データ名称、データの種類、データ量（件数、サイズ）、発生頻度
4. データ保有期間：データの保有期間（社内規定や法令法規などによって定められている場合はその期間）
5. 拡張性：利用者、アクセス数、業務処理量、データの増減に応じたシステム（メモリ、CPU、ディスクなど）の拡張対応

11.性能要件

1. オンライン処理性能：画面のオンラインレスポンスタイム、スループットなどの指標と対象機能など
2. バッチ処理性能：バッチ処理の最大処理件数、ターンアラウンドタイム、時間当たり処理件数の指標（通常時、ピーク時）と対象機能など

12.上位互換性

1. バージョンアップ：（メジャー、マイナー）バージョンアップ時の上位互換の保証に関して（保証対象の機能、互換性が保証されない機能に対する対応、検証方法など）

13.中立性

1. 技術・製品（サービス）の利用に関して：ベンダーロックイン（特定の事業者（ベンダー）を利用し続けなくてはならなくて、他社の参入が困難な状態）を回避し、システムの中立性を担保するため、本システムで利用する技術や製品（サービス）に関しての要件※オープンで標準的なものを利用するなど

14.移行性

1. 移行スケジュール：移行スケジュール（移行計画から本番稼働までの移行全体のスケジュールを定義）、システム停止可能期間、平行稼働有無など
2. 展開方式：・複数拠点展開の場合の展開方式（単一拠点の場合は定義不要）、業務の展開方式（全業務一斉展開、または部分展開）
3. 移行対象、ボリューム：移行対象（業務、システム/機器、データ）　※データに関しては、移行対象のデータ名称、データ形式、データ量（件数、サイズ）
4. 移行リハーサル：移行リハーサルの範囲、環境、回数
5. 移行計画（書）：移行対象に関する移行計画書の作成について（計画書に記載する内容）、コンティンジェンシープラン

15.運用保守性

1. 運用監視：異常検知の実施有無、監視対象（システム、プロセス、DB、ストレージ、ネットワーク）、監視方式、間隔など
2. 運用時間、時刻同期：システム運用を行う時間、（利用者や管理者に開放する時間）、時刻同期設定の範囲、システム全体を外部標準時間と同期など
3. 運用負荷軽減：保守運用に関する作業を軽減するための要件、作業の自動化、ソフトウェア更新の自動化など
4. 障害時運用：障害時の運用（検知方法、報告ルート、対応窓口、復旧作業の整理）、対応可能時間、代替業務運用など
5. 運用環境：開発や試験（検証）目的の環境の用意、リモート監視の有無、対象、範囲など
6. サポート体制：保守対象（H/W,S/W）、ライフサイクル期間、メンテナンス役割、体制、サポート要員、操作訓練、運用報告内容に関して
7. その他運用方針：内部統制対応、サービスデスク設定、インシデント管理、問題管理、構成管理、への宇管理、リリース管理

16.セキュリティ

1. 前提条件：順守すべき情報セキュリティに関する規定やルール、法規法令、ガイドラインなど
2. セキュリティリスク分析・診断・管理：リスク分析範囲、セキュリティ診断、リスクの管理について
3. アクセス利用制限：アクセス認証方式、利用者/時間制限、ネットワーク制限、権限など
4. データの秘匿：機密性のあるデータについて、送信時や蓄積時の秘匿（暗号化）について
5. 不正追跡・監視：ログ取得対象、保持期間、IDS（不正侵入検知）・IPS（不正侵入防止）の検知、データ検証（デジタル署名）など
6. ネットワーク対策：ネットワーク制御、不正検知、サービス停止攻撃への対処
7. マルウェア、WEB対策：マルウェア（ウイルス、ワーム、ボット等）の感染防止、Webアプリケーション特有の脅威、脆弱性についての対策
8. セキュリティインシデント対応：セキュリティインシデントの早期発見、被害の最小化、復旧支援に関して

補足

これまで説明してきたフォーマットを使って要件の詳細を定義するとともに、Salesforceの非機能要件への対応方針やプロジェクト個別の対応方針など具体的な施策に関しては、上記とは別に詳細な資料を作成して説明するとよいでしょう。

例えば、可用性については以下の例のような資料を作成して説明するなど。

１．可用性（継続性・耐障害性・災害対策・回復性）

Salesforce（パブリッククラウドサービス）を利用するため、指定日時でのメンテナンスの制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

可用性の各項目については、開発ベンダー側では制御できない内容となるため、基本的にSalesforce社の可用性に対する回答の内容を説明するだけとなります。

【重要】Salesforceは、実績として99.9% の稼働率となっていますが、セールスフォース社としては、SLAや個別契約などで可用性に関して担保するようなサービスは提供していません。（※2022年3月現在）

そのため、同社が提供するサービスとしての可用性はこのようになっていますという説明とともに、制約事項として承諾していただく必要があります。

リアルタイムのサービスの運用状況やインシデント、メンテンナンス状況については、Salesforceが提供する以下、「Salesforce Trustサイト」にて、運用担当者にて確認してもらう運用が基本となることを合わせて説明しておくほうがよいでしょう。

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

Salesforceサービスは拡張性と冗長性にすぐれているため、需要の変動やユーザの増加にも対応できるうえ、長時間のサービス停止リスクも大幅に軽減されます。設計面では、ネットワークの負荷分散、アプリケーションサーバのプール、およびデータベースのクラスタ化を特徴とします。

災害対策、回復性

事業（業務）継続性の要件として、災害対策の検討がありますが、Salesforceのサービスは単一拠点（一か所）での障害によって、サービスが中断してしまわないように地理的に離れた場所に複数のデータセンターが設けられています。

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

など。

サポーターさん

各非機能要件に対する具体的な定義例や補足資料のサンプルは別途記事を作成してご紹介したいと思います。

今回はここまでとなります。

2.テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料（PPT版）

要件定義_要件定義書_別紙4「非機能要件定義書」_20221016_v1.0（PPT版）のダウンロード

※クリックして資料のダウンロードが開始されるまで少し時間がかかる場合がありますので、そのままお待ちください。もしダウンロードが開始されない場合、ブラウザでポップアップブロックされている可能性があるのでご確認ください。

まとめ

そのほか要件定義に関するドキュメントをお探しの場合は、以下の記事にご利用可能な全てのコンテンツ（ドキュメント）が掲載されているので、合わせてご利用ください。

参考

ダウンロード可能なコンテンツ（サンプル・フォーマット）一覧

[st-kaiwa2]お問合せ・ご要望いただいているコンテンツも頑張って作成して…

続きを読む

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

本テンプレートは、Salesforce（セールスフォース）プロジェクト以外にも活用可能なフォーマットとなっておりますので、是非をご活用ください。

要件定義書本編については以下の記事からダウンロード可能です。

参考

Salesforceシステム要件定義書（PPTテンプレート）サンプル・利用方法

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

1.テーラリングガイド

テンプレートをダウンロード後、テーラリングガイドを参考にご自身のプロジェクトに合わせてカスタマイズしてご利用ください。

1.本書の構成

上記の通り、今回のサンプルでは、要件定義書の別紙5の位置づけで作成しておりますので、上記の構成となりますが、要件定義書の構成に合わせてテスト要件を非機能の中に入れて纏める場合もあると思います。

プロジェクトに合わせて、要件定義書の構成を検討してください。

2.目次

続いて、目次としてテスト方針書の章立て（構成）を定義していいます。

こちらについても、プロジェクトの中で章立てを検討し、目次を変更してください。

サンプルは、比較的中規模程度のプロジェクトで必要最低限の項目を定義していますが、大規模プロジェクトの場合には、より詳細な内容を定義しておくことをお勧めします。

特にスコープ、品質管理、体制・役割については、テスト工程の見積に大きく影響するため曖昧に終わらず、しっかり明確になるまで検討しておく方がよいです。

3.テストの目的・概要

テスト実施の目的と実施期間などテスト全体の概要を記載しておきましょう。

4.テスト範囲（スコープの定義）

自社が担当するテスト範囲を明確にするため、まずは、システム全体構成図の中からスコープを定義するとわかりやすいでしょう。また、スコープ外はどこか明確な場合は、同じようにスコープ外を明記しておくほうがよいでしょう。

システム領域や機能単位でスコープが明確な場合は、具体的に定義しておくほうがよいです。（非機能についても同様）

続いて、テストの前提条件や制約事項について定義します。

5.テストの位置づけ

上記は、Salesforceで構築したシステムの機能要件に対するテストの位置づけを表現したものとなります。

Salesforceのサービス基盤（プラットフォーム）部分と、設定・開発したアプリケーション部分に分けてテスト対象を定義しています。機能要件では、アプリケーション部分のみテスト対象とすることを明記し、各テスト工程でどのようなテストを実施するか説明しています。

今回対象の欄については、プロジェクトに合わせて、どの機能をどのようにテストを行うのか定義します。

内部結合テストについては、処理結合テスト、機能結合テスト、業務結合テストに分けて定義していますが、プロジェクトによって実施範囲ややり方が異なることが多いので、規模や方針に合わせて変更してください。

非機能

非機能についても同様にプロジェクトでのテストの位置づけを定義します。

主に性能テスト、セキュリティテスト、基盤テストについてのテスト観点を定義します。

例では、性能については、基本的にアプリケーション（オンライン、バッチ処理）について記載しています。

※Salesforceのプラットフォーム（基盤）に対しての性能試験（主に負荷試験）を実施する場合は、事前にサポートへ連絡して、作業内容や実施日時についての調整が必要となるので注意が必要です。

6.テスト計画書作成方針

テスト計画書の作成に関する方針を定義します。

テスト計画書として定義する項目（目次）や記載内容（粒度）について定義しておきましょう。

・スケジュール、テスト評価基準の定義、テストの開始・終了条件、テスト実施体制と役割、テスト方法（ツール）、テストデータ、テスト環境、テスト観点、エビデンス作成に関する方針、レビュー実施に関する方針など。

7.テスト環境方針

テスト環境の方針について、各テスト工程（単体テスト、結合テスト、総合テスト、受入テスト、移行リハ）毎にどの環境を利用するか定義します。

どのシステムがどのタイミングでどの環境を利用するのかわかるようにしておきましょう。

同じ環境を他のシステムや他のベンダー担当者が利用する場合もあると思いますが、その場合は占有期間や利用方針を定義しておき、テストに影響がでないように調整しておきましょう。

8.テスト設計方針

テスト設計に関して定義します。

通常は各テスト工程に適したテスト観点表を作成して、内部レビューを実施した上で、テスト設計を行う流れになると思います。

9.テスト担当社方針

テスト担当として、テスト設計を行う担当者とテストの実施を行う担当者についてそれぞれ定義します。

記載例）

テスト設計者については、システムの業務要件、各種テスト技法を把握している者など、設計に必要な知識を要しているものを担当社とする

10.テスト実施概要

テスト実施概要の章では、各テスト工程でのテスト概要を記載します。

11.テストデータ作成方針

テストデータの作成方針では、各テスト工程で、それぞれ作成するテストデータの内容が異なるため、どのようなテストデータを作成するのかわかるように記述しておきます。

例：外部結合テストや統合テスト（システムテスト）については、システムの上流側で生成されるデータを利用する

12.テスト実施体制と役割

テスト工程での関係各社の役割を定義します。

特に他社と共同で行うテスト工程では、テストシナリオやケースの作成やテストデータの作成について、誰がどの範囲を担当するのかを明確にしておきましょう。

お客様については、UAT以外は主に設計や実施結果の報告についてのレビューを実施していただくことが多いと思います。

また、UAT（ユーザ受入テスト）について、シナリオの作成やデータの準備はベンダー側で実施すると考えているお客様がいる場合もあるため、誰が実施するのか協議の上確定し、本書に決定内容を記述しておきましょう。

13.テスト品質管理方針

テスト品質は、非常に重要な内容となります。具体的に定量的に品質評価するための評価方法や、メトリクス、定量指標の決定などに関する基本方針を定義します。

システムの品質管理は、しっかりやるとかなりの工数がかかる作業となり、また品質管理のスキルも必要となります。

テスト品質の管理として、どこまで実施するのか、どの部分は実施しないのか明確にしておきましょう。

14.成果物の定義

最後にテスト工程で作成する成果物を定義しておきます。エビデンスの作成が必要な場合は、具体的にどのようなエビデンスを作成するのか明確に定義しておきましょう。

例：画面のスクリーンショット、システムログの取得など

15.補足資料（Appendix）

テスト要件に関する補足資料がある場合は、追加するか別紙として定義しておきましょう。

2.テスト方針書（PPT版）テンプレートのダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

資料ダウンロード

2.まとめ

テスト方針書についてはこちらの記事を参照ください。

参考

テスト方針書（PPT版テンプレート）サンプル

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

テンプレートのご利用に関して不明な点があればお問い合わせください。 また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

※非機能要件書のテンプレートもご用意しています。

一般的なシステム開発の非機能要件については、IPAが提供している非機能要求グレードをベースにヒアリングすることが多いと思います。

これまで何度か改訂されており、2018年が現時点の最新版になるかと思います。AWSなどのクラウドサービスに対しての非機能の評価軸が追加されています。

Salesforceに関する非機能要件定義

基本的に非機能要件として検討するべき事項に関しては、SalesforceであってもベースはIPAが提供する非機能要求グレードにあるような事項についての検討が中心となります。

１．検討すべき非機能の範囲

以下、「IPA（情報処理機構）が提供している「非機能要求グレードの（06_活用シート.xls）」より

この非機能要求グレード表を開いてみるとわかると思いますが、非機能として検討すべき項目や指標はかなりのボリュームがあります。

また、機能要件と異なり非機能は、インフラや運用系の知識や経験がないと理解するのが難しい用語なども含まれます。またお客様の規模や業務に対して、各非機能の指標値として何が適切なのかを検討していくためにもある程度の知識は必要になってくるかと思います。

幸いなことにSalesforceはマルチテナント型のパブリッククラウドサービスのため、多くの非機能に関する要件は制約があり、またSalesforce側で自動的に制御、運用される部分が多いため、一般的なシステム開発と比べて検討すべき事項はかなり絞り込まれます。

上記の図のとおりセールスフォースは、SaaS型サービスのため、ハードウェア、ネットワーク、負荷分散、障害対策など管理が難しい部分は、全てSalesforceのサービスとして管理・運用されます。

そのため、このあたりの非機能要件定義では、セールスフォース・ジャパン社が提供する非機能の内容を説明することで代用することができます。

※１.Salesforce社の非機能要件に対する対応方針を説明する。

非機能要件定義

これまでは、Salesforce導入プロジェクトで検討するべき非機能についての全体像を説明しました。

多くの非機能要件の事項にかんしては、セールスフォース社が提示している非機能要件に対する回答をベースに説明・検討を進めることができるということがご理解いただけたかと思います。

ただし、それ以外にもお客様やプロジェクトの特性に応じて、個別に検討するべき非機能も少なくはないため、それぞれ検討するべき内容の詳細は理解しておく必要があります。

ここからは、各非機能要件について具体的にどのように要件定義していくか説明していきたいと思います。

１．可用性（継続性・耐障害性・災害対策・回復性）

まずは可用性についてから説明していきます。

上記テンプレートで記載している通り、Salesforceというパブリッククラウドサービスを利用するため、個々のテナント毎に制御はできません。

基本的にサービス提供ベンダーのサービス提供方針に従うことになります。

Salesforce社の可用性に関するサービス提供方針は、常に最新の状況を確認するようにしてください。

（１）Salesforce.comのサービス可用性

サービス提供時間：24時間365日（計画停止/定期保守を除く）

※セキュリティ対応やシステム稼働に重要な影響がある場合は、事前通知の上、緊急メンテナンスを実施する可能性有り

計画メンテナンスについては、現時点でSalesforce公式サイトを確認すると「暦月の第 1 週末と第 3 週末」と記載されています。

※リージョンやインスタンスによって実施日時が変わる可能性があります。

稼働率は過去の実績で99.9％を維持しています。現時点のインスタンスの稼働状況については、Trustサイトにて確認していただく運用となります。

https://trust.salesforce.com/ja/

継続性・耐障害性

可用性の各項目については、開発ベンダー側では制御できない内容となるため、基本的にSalesforce社の可用性に対する回答の内容を説明するだけとなります。

【重要】Salesforceは、実績として99.9% の稼働率となっていますが、セールスフォース社としては、SLAや個別契約などで可用性に関して担保するようなサービスは提供していません。（※2022年3月現在）

そのため、同社が提供するサービスとしての可用性はこのようになっていますという説明とともに、制約事項として承諾していただく必要があります。

リアルタイムのサービスの運用状況やインシデント、メンテンナンス状況については、Salesforceが提供する以下、「Salesforce Trustサイト」にて、運用担当者にて確認してもらう運用が基本となることを合わせて説明しておくほうがよいでしょう。

各サービス（機能）のステータスは色で判断することができます。

※以下、公式サイトより

Salesforeのハードウェアやネットワーク構成など基本的に非公開にされているため、基本的には以下のような記述をして説明します。

Salesforceサービスは拡張性と冗長性にすぐれているため、需要の変動やユーザの増加にも対応できるうえ、長時間のサービス停止リスクも大幅に軽減されます。設計面では、ネットワークの負荷分散、アプリケーションサーバのプール、およびデータベースのクラスタ化を特徴とします。

災害対策、回復性

事業（業務）継続性の要件として、災害対策の検討がありますが、Salesforceのサービスは単一拠点（一か所）での障害によって、サービスが中断してしまわないように地理的に離れた場所に複数のデータセンターが設けられています。

またSalesforceのトランザクションは、ほぼリアルタイムで複数拠点のインスタンスに複製されています。

上記のように図やデータなどで示して説明するとよいと思います。

まとめ

今回はここまでとなります。

次回は「性能・拡張性」に関する非機能要件の要件定義について説明していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した変更要求管理プロセスと管理台帳のテンプレートをご提供しております。

お客様から提示された要求仕様に関して、変更が発生した際に本テンプレートを利用して変更内容を管理してください。

変更管理を行う場合の管理プロセスについてもBacklogと本管理台帳を使ったプロセスを定義しておりますので、合わせてご利用ください。

要求仕様管理台帳が必要な方はこちらの記事を参照してください。

参考

要求仕様管理一覧（テンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

資料サンプル

表紙

管理プロセス

変更要求管理台帳

1.テーラリングガイド

1.変更要求管理プロセス

変更要求の管理プロセスについては、お客様社内の変更管理プロセス（起票から承認まで）と、開発ベンダー側での変更管理プロセスの2種類があります。

プロジェクトに合わせて、管理プロセスを定義してください。お客様内部のプロセスを定義する必要がない場合は、開発ベンダー側だけの管理プロセスを記述してください。（ただし、実施可否の最終判断はお客様となるためその部分はプロセスに定義しておきましょう）

管理プロセス（サンプル①）

以下のサンプルでは、お客様側の変更要求起票はバックログを使って運用する想定で記載したものとなります。

管理プロセス（サンプル②）

 画像はクリックすると拡大表示されます。

変更要求管理台帳

主に以下のような内容を記述します。※プロジェクトによって管理項目は適宜変更してご利用ください。

・変更要求管理番号：変更要求を一意に識別するための管理番号を定義します。※命名ルールに準拠すること。

・件名：変更に関するタイトルを定義します。

・変更内容：変更内容（概要レベル）で記載します

・変更対象機能：変更を行う対象の機能を具体的に記述します。

・変更種別：追加・変更・削除などの種別を定義します。

・要求元：変更要求の要求元を定義します。

・業務影響度：変更が業務に与えるインパクトを記述します。

・期待効果：変更による期待効果（改善効果）を記述します。

・納期：対応の納期が決まっている場合には記述します。

・起票日：起票した日付を記述します。

・起票者：起票者を記述します。

・発生日：変更要求が発生した日付を記述します。

・ステータス：変更要求の管理ステータスを記述します。※ステータスは別途定義する必要あり

・開発者項目として、影響する機能の洗出し結果や、技術的に変更が対応可能かなどの項目を定義します。

・対応想定工数が必要な場合には工数の情報も合わせて定義しておきます。

2.変更要求管理台帳のダウンロード

資料のダウンロードおよびご利用に関しては、本サイトのコンテンツ利用規約に同意される場合のみ利用可能となります。

一般公開資料

update 2022/04/17 直接エクセルファイルをダウンロードするリンクを追加

以下は、スプレッドシートでの表示となります。

まとめ

サポーターさん

テンプレートのご利用に関して不明な点があればお問い合わせください。

また、テンプレートに対しての要望がありましたらご意見ください。 皆様の役に立つように改善していきたいと思います。

サポーターさん

ブログランキングに参加しましたので、ご支援していただけると幸いです。

にほんブログ村

第二回の内容としては、業務フローの作成についての説明がメインとなります。

サポーターさん

業務フローを作成するにあたって、ご利用いただけるテンプレートもご用意していますので、是非ご利用ください。

業務フロー図の作成

要件定義で検討する対象の組織と業務が特定出来たら、それぞれ各部門担当者へのヒアリングを実施して、業務詳細を確認します。

それらの情報が集まったら業務フロー図を作成していきましょう。

まずは現状の業務フロー図（As-Isモデル）を作成して、それをもとに新業務フロー図（To-Beモデル）を定義するのが一般的な流れとなります。

ただし、システム導入がメインのプロジェクトでは、業務要件定義自体をやらなかったり、すでに定義されたTo-Beの業務フローに基づき、システム要件定義から開始する場合もあると思います。

そのため、プロジェクトに合わせて、どのような業務フローを作成するのか確認しておきましょう。

To-Beモデルの業務フローを提供していただき、それに基づき新業務フローを作成するのか。または、新業務フローをベースとして、システム化業務フローを作成するのか。

現行業務(As-Is)、新業務（To-Be）フロー図の作成

業務フロー図を作成するにあたっては、前工程で作成した業務機能階層図（業務機能一覧）に基づき作成していきます。

※図はクリックすると拡大表示されます。

業務フローの大中小をいきなりまとめて、フローを書き始めるのではなくて、最初に業務全体の流れを把握して、それをブレークダウンして分析していきます。

具体的には、業務機能階層図の業務分類（大中小）を以下のステップで詳細化していきます。

業務フローを検討するときには大分類の流れを定義して、業務全体の大きな流れをまず把握します。（下図の業務プロセスのレイヤー１に相当）

例では、販売管理→購買管理→生産管理→在庫管理→財務管理のような分類を定義しています。

大分類の中の1業務ごとに、業務内容をブレークダウンして、中分類の業務フローを整理します。（業務プロセスのレイヤー２）

例では、レイヤー１の販売管理について、ブレークダウンして、引き合いから請求までの流れを整理しています。

最後にレイヤー2（中分類）レベルの業務を作業レベルまで落とし込みをしています。

見積管理業務プロセスを例に記載していますが、顧客の登録作業から見積の作成、承認申請、そして見積書の送付までを簡単なフローで表現しています。

【業務プロセスのレイヤー定義】

このように最初に大枠での業務全体を定義して、そこから詳細化していことで、抜けもれの防止にもつながります。

業務フロー図とシステム化業務フロー図

業務フロー図というのは、あくまで業務に関する作業の流れを記載してフロー図を指します。そのため、システム処理に関しては、ほとんど記述しません。

例えば、さきほどのフローの例では、見積書の作成や承認申請の作業を記載していますが、システム化フロー図（システム処理フロー図）の場合には、具体的なシステムの振る舞いまで詳細に記載します。

例：見積書作成画面（SFDC画面）を表示→見積データを入力して保存（SFDC画面）→上長へ承認申請を行う（SFDC承認ボタン）→承認依頼のメール通知（SFDCワークフロー）→上長が内容を確認し承認・却下（SFDC画面）→見積書出力（PDF）（SFDC画面）

業務フロー図では見積書の作成と承認申請と表現される内容について、システム化業務フロー図（システム処理フロー図）では、このような処理プロセスをフロー図として表現していくことになります。

また処理プロセスフローだけではなく、データフローの→も追加して、データベースへの読み書きなども表現します。

ただし、小規模なプロジェクトやシステムでは、作業負荷の低減や効率化により業務フロー図を作成せず、直接システム処理フロー図を作成するような場合もありますので、状況に合わせて方針を検討してください。

業務フロー一覧

業務フロー一覧のシートには、作成する業務フロー図のシートを一覧化して定義しておきましょう。

１つの業務フロー図で業務をどのように区切るのかによって、一覧に記載する粒度も異なってきます。

上記の例では、販売管理を、引き合いから受注管理までとそれ以降で業務フロー図を分けて定義しています。

業務フロー図の目次のような位置づけとなるため、シートの内容が網羅できるように記載しておけばよいでしょう。

凡例

業務フロー図で利用するフロー図の凡例をまとめています。フロー図については、一般的な定義はありますが、可読性などを意識して、わかりやすければ、あまり意識しなくてもよいでしょう。

上記のサンプルも本サイトが提供するテンプレートに入っていますが、ご自由にカスタマイズしてご利用ください。

業務フロー図（システム処理フロー図）

最後に、業務フロー図の作成となりますが、エクセルで業務フローを作成する際は、縦長に作成することをお勧めします。

業務が複雑で細かい場合には、1業務フローでかなりのボリュームになることがあります。横スクロールの場合、処理を確認するのが大変なので、縦スクロールで確認できるようにするとよいでしょう。

レーン（縦線の列）には、業務分類、業務内容を時系列で定義します。また、それぞれの業務で作業を行うアクター（人やシステム）を定義します。

あとは、業務機能階層図の作業手順に沿って、開始から終了までの作業を業務フロー図として表現していきます。

まとめ

いかがでしたでしょうか。業務フロー図の作成手順については、ご理解いただけましたでしょうか。

本記事でご紹介いたしました業務フロー図のテンプレートは以下からダウンロードしてご利用いただけます。

参考

業務フロー図・業務プロセス（Excelテンプレート）

Salesforceの要件定義フェーズで行う、お客様の業務整理の際に利用できる、…

続きを読む

次回は、業務要件のとりまとめと、システム化（システム要件定義）に関して説明していきます。

要件定義の進め方については、会社ごとのメソドロジーや個人の経験に基づく進め方など、プロジェクトの性質や担当されるPMやコンサルタントによって、最適な進め方は異なるものとなります。

ここでは、クリエイティブコンテンツラボトウキョウのメンバーの知識や経験に基づく内容で説明をしていくため、プロジェクトに合わない部分や、ご自身である程度進め方のテンプレートがある場合もあるかもしれません。

サポーターさん

ご利用できる部分があれば、ご活用いただけると幸いです

組織の確認

経営コンサルタントや専門の業務コンサルタントの方がいらっしゃるプロジェクトであれば、すでに組織体系や業務体系など整理されたアウトプットがあると思います。その場合には、アウトプットを引き継いで、システム要件定義に取り掛かればよいと思います。

そういった上流工程のアウトプットがない場合には、自分たちでお客様に必要な情報を提供していただき、整理をしていくところから開始する必要があります。

まずは、お客様の組織図を入手しましょう。業務整理の方法は何通りかありますが、基本的には組織体系ベースで整理していくことをお勧めします。

またSalesforceの権限制御であるロールを検討する際にも組織構成と業務体系をベースに検討することが多いため、権限検討の際にも利用することになります。

組織図の定義

組織図を入手したら、組織構成を把握して、業務整理・システム整理対象となる組織を特定するところから始めましょう。

上記のような組織図を提供していただき、組織構成を以下のように一覧化しておきます。

※上記の組織図・業務体系図のエクセルテンプレートは以下よりダウンロードしていただけます。

参考

組織図・業務体系図（Excelテンプレート）

Salesforceの要件定義フェーズで行う、お客様の業務整理の際に利用できる、…

続きを読む

業務体系の整理

組織の整理が終わり、プロジェクトの対象となる部門が特定できたら、次に業務体系図を作成して、業務体系を整理していきます。

業務体系を整理するためには、まず全社の業務を俯瞰して全体像を明らかにし、その後整理対象部門の各業務について調査・ヒアリングを行い洗い出しする必要があります。

プロジェクト選任の業務担当者がいる場合には、プロジェクトの会議体に参加してもらい業務ヒアリングや課題・システム化の検討ができます。

業務体系図（業務機能階層図・業務機能一覧表）を作成

インプットとなる既存の業務フロー図や業務説明書などがある場合には、事前に提供していただき、それを基に全体の業務を俯瞰することができる業務体系図を作成していきましょう。

業務体系図は、業務機能階層図や業務機能一覧表と呼ばれることもありますが、どれも同じようなものを指します。

業務を大きく3つ程度に分類して階層構造に落とし込んでいく作業となります。階層の粒度については一般的に3階層が利用されますが、3階層でなければいけないということはありません。

業務階層に落とし込みをする場合に重要なことは2つあります。1つ目は、大分類（最上位）をどの粒度の業務と定義するか。

最上位をマスタ管理、購買、販売、会計…のような単位を最上位としているものが多いと思いますが、例えば、製造業の場合には、製品ごとに組織や業務が構成されている場合もあります。

その場合には、以下のような整理になってくると思います。※製品やサービスを大分類として定義

上記のように製品を軸とした業務体系があるということは、最初にご紹介した組織図を見てみると、組織構成も製品を軸としたものになっているのではないでしょうか。

組織構成と業務体系は切り離して考えるのではなく、事業や業務を円滑に行うためにどのような組織なのかという観点でみるとよいでしょう。

ここで組織の話を詳しく書く予定はありませんが、中小企業診断士試験の内容でも出てきますが、組織構成には、以下のようなものがあります。

• 機能別組織
• 事業部制組織
• チーム型組織
• カンパニー型組織
• マトリックス型組織

経営組織に関して興味のある方は、バーナードの組織論など調べてみるとよいでしょう。

話が少しそれてしまいましたが、業務体系の整理には、お客様の業態や業務知識などもある程度必要になってくることもあります。

とはいっても、特殊な業務やお客様しか知らないような専門的な内容まで理解する必要はありません。経験の少ないうちは、最低限ERPで扱うような領域の業務内容を把握しておくとよいでしょう。

まずは、SEが知っておくべき基本となる業務知識を学習しておきましょう。書籍で学習したい方は、こちらがおすすめです。

参考

おすすめの書籍（業務知識）

本日は、Creative Content Lab Tokyo（クリエイティブコン…

続きを読む

業務ヒアリング

組織・業務体系図のドラフト版が出来上がったら、それに基づいて業務ヒアリングを実施しましょう。

お客さまも通常業務があるため、時間には制約があります。

効率的にヒアリングを進めるためにも、どの部署から順番に確認していくのがよいか事前に検討しておきましょう。

ヒアリングのスケジュール表を作成して、具体的な日程を調整するとよいでしょう。

ただし、どうしても業務担当者の方が時間が取れないという場合もあるかと思います。

そのような場合には、なるべく早い段階で、ヒアリングシートを渡しておき、事前に業務内容を整理して記入していただくように手配しましょう。

※本サイトで提供しているヒアリングシートは以下となります。

参考

業務ヒアリングシート（Excelテンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

最低限記入してもらうのは、業務手順、業務説明ですが、可能な限り、必要なインプット、アウトプット、作業時間、業務課題なども記入してもらうようにお願いしましょう。

細かい内容になると嫌がられる場合もあるので、その場合には、テキストに箇条書きで纏めてもらってもいいでしょう。

業務機能階層図の作成

各担当者への業務ヒアリングを進めながら、業務体系の整理をして、最終的には以下のように業務機能階層図として整理します。

また、このあとのシステム要件定義を効率よくすすめられるように、以下の列も追加して確認しておくようにしましょう。

• アクター定義：業務（作業）を実施する人・システムの明確化
• 作業サイクル：随時、日次、月次など処理サイクルを確認
• 現行システム：現在どのようなシステムやツールを使って作業しているのか。（ex.エクセル、ワード、ERPなど）
• 課題・要件：現行業務の課題や改善要件など

次のシステム要件定義では、作成した業務機能階層図をベースにシステム要件を明確にしていく作業となるため、この段階で業務課題や要件は明確にしておきましょう。

上記テンプレートは以下からダウンロードしてご利用いただけます。

参考

業務機能階層図・業務機能一覧（Excelテンプレート）

Salesforceの要件定義工程で業務整理の際に利用できる、業務機能階層図/業…

続きを読む

次に整理する業務プロセス（業務フロー図）のレイヤー階層と3段階（大中小）の分類を意識しておきましょう

まとめ

まずは、要件定義の最初に整理するべき、組織や業務体系の整理に関しての進め方やテンプレートをご紹介いたしました。

このあとは、詳細な業務内容の整理をしていく工程となります。具体的には業務フロー図の作成作業やシステム化に向けたFit＆Gap一覧の作成など

続きは、別の記事で説明する予定です。

まず、要件定義は、大きく業務要件定義とシステム要件定義の2つに分類されます。

業務要件定義では、経営戦略・IT戦略・グランドデザイン（基本構想）の段階から決められた、業務プロセスのあるべき姿を実現するための具体的な業務要件、業務機能の落とし込みを実施します。

そして、システム要件定義では、同じく上流工程で決められたTo-Beモデルの業務システム構築に向けて、業務要件に基づき、具体的なシステムでの実現方法を検討するという流れとなります、

本記事では、まず業務要件定義について説明していきます。

業務要件定義

業務要件定義の目的：

戦略・グランドデザイン（基本構想）の段階で計画した業務改善・業務のあるべき姿（To-Be）を実現するため、現状分析した業務を具体的にどのように改善・改革していくのか詳細を検討し、業務要件として整理すること

検討範囲（スコープ）：

全体の業務領域のうち、計画段階で決定した業務領域のスコープを対象として業務要件定義を実施します。

最初にスコープの定義をしておかないと、お客様との要件定義の中でどんどん検討領域が拡大していく可能性があるので注意しましょう。

実施内容：

業務要件定義を行うには、お客様の業務内容を理解する必要があります。

経験が浅く、まだお客様の業種について一般的な知識やシステムの知識がないという場合には、事前に書籍等で学習しておくことをお勧めします。

業務知識や業務システムに関するお勧めの書籍を知りたい方は、こちらの記事を参考にしてください。

参考

おすすめの書籍（業務知識）

本日は、Creative Content Lab Tokyo（クリエイティブコン…

続きを読む

現状分析（現状の業務フロー、業務内容）

業務要件定義実施にあたり、まずは、現状分析（現状のお客様の業務フローや業務内容の調査、整理）を実施します。

基本的には、お客様の内部で整理した現行の業務フローや業務説明書などをご用意していただき、それについてプロジェクトメンバーで内容の確認と整理をしていくという流れとなります。

業務フローなどのインプットがない場合には、分析対象の部門の方に事前にヒアリング用の資料を配布し、業務内容を確認していただいてから業務内容に関するヒアリングを実施したほうがよいでしょう。

以外に普段行っている業務であっても、正しい処理の流れや何のためにやっているのかわからない作業も多いものです。

そういったものを棚卸し、現状業務の課題や問題点を現場担当者にヒアリングして洗い出していきましょう。

業務フローの修正は意外と時間がかかるため、事前に業務ヒアリングを実施して以下のような表にまとめておきましょう。

テンプレートはこちらからダウンロードしてください。

参考

業務ヒアリングシート（Excelテンプレート）

本記事では、Creative Content Lab Tokyo（クリエイティブ…

続きを読む

本日は、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）がお勧めする業務知識の助けとなる書籍をご紹介していきたいと思います。

Salesforceの導入プロジェクトで、標準のCRM（Customer Relationship Management）の機能だけを利用されるお客さまであれば、専門的な業務知識はあまり必要ないかもしれません。

しかし、多くのシステム導入プロジェクトでは、まずお客様の業務理解が必要となります。

業務改革など専門知識が必要となる業務コンサルタントでなければ高度な専門書を学習する必要はありません。

最低限として、お客様の業界の一般知識は理解すること。そして、お客様の業務についてお客様と会話ができるレベルを目指しましょう。

経験を積んでいけば、様々な業種のお客様の導入に携わり、多くの知識を蓄積していくことができます。そういう経験豊富なコンサルタントの場合、お客様から他社事例を聞かれたり、コンサルタントとしての意見を聞かれる機会も増えるでしょう。

そうなってきた場合には、より高度な知識を学習するという方向にすすむのもよいでしょう。

まずは、アサインされているプロジェクトのお客様の業種を対象として少しずつ学習することをお勧めします。

業種別の学習

業務知識といっても、日本には様々な業種の仕事が存在します。すべての業種の知識を網羅するのは非常に時間がかかり非効率です。

できれば将来的に自分がどの領域で活躍していきたいのかを明確にして、業種を絞り込んで、専門性を高めるという戦略がよいでしょう。

（主な業種一覧）

• 農林・水産
• 林業
• 漁業
• 製造業
• 電気・ガス
• 運輸・通信業
• 卸売・小売・飲食業
• 金融・保険業
• 不動産業
• サービス業

それぞれの業種の中にさらに、細かい分類が多数存在します。例えば、製造業は以下のようなものがあります。

• 繊維、木材、家具、石油、化学工業、出版（書籍）、ゴム、革、鉄鋼
• プラ製品、窯業、非鉄金属、一般機械、電気機械器具、輸送機器、精密機器

製造する製品によって、サプライチェーン（資材の調達、生産管理、在庫管理、販売方法など）変わってきます。

ただし、各業界の一般的な業務内容を理解しておけばある程度、お客様の会話についていくことはできますので、頑張りましょう。

エンジニアが学ぶシリーズ

まず一般的な知識を学ぶには定番の「エンジニアが学ぶシリーズ」をご紹介します。

なぜこちらがよいのかというと、特に新卒の方などはそもそも上記に挙げた各業種でどのような業務が行われているのか具体的にイメージするのは難しいと思います。

そのため、文字だけではイメージが掴みにくく理解が難しい業務内容もでてきますが、このシリーズでは、わかりやすい図が挿入されていて、図解されているため非常に全体像の理解がしやすくなっています。

また、「エンジニアが学ぶ」というタイトルの通り、システムエンジニア向けの内容となっているため、業務知識だけではなく、業務システムと合わせて解説されているため、学んだ知識をそのままシステム導入時に活かせるというのが最大のメリットです。

最初にお勧めする本は、こちらです。

エンジニアが学ぶ生産管理システムの「知識」と「技術

続いて、物流関連であればこちら

エンジニアが学ぶ物流システムの「知識」と「技術」

金融系のシステム導入に携わる場合はこちら
エンジニアが学ぶ金融システムの「知識」と「技術」

最後に、会計ですが、どんなプロジェクトに携わるにしても絶対に学習しておいて損はないです。将来必ず役に立つ日が来るので、是非学習しておきましょう。
エンジニアが学ぶ会計システムの「知識」と「技術」

会計に関しては、できればより専門的な知識を学習することをお勧めします。

会計に関しては、基本的には簿記の資格を勉強しておけば間違いないでしょう。簿記は3級でもよいですが、できれば2級の工業簿記、商業簿記までは学習することをお勧めします。

簿記の試験に合格するためのお勧め本は、TACが出版しているシリーズがお勧めですが、もし簿記って何？とか初めて学習する方には、かなりとっつきにくい内容となりますので、まずはイメージをつかむところから入ったほうがよいでしょう。

簿記教科書 パブロフ流でみんな合格 日商簿記3級 総仕上げ問題集 2021年度版

こちらは、資格対策ではないですが、入門編というか文字だけで理解するのはつらいという方向けです。

本格的にしっかり学習して、試験にも合格したいという方は、ぜひTACのテキストを利用して学習しましょう。
合格テキスト 日商簿記3級 Ver.11.0 (よくわかる簿記シリーズ)

まとめ

今回は、クリエイティブコンテンツラボトウキョウがお勧めする業務知識に関する書籍をご紹介いたしましたが、いかがでしたでしょうか。

主にシステムエンジニア向けや経験の浅い人向けの入門書を多くご紹介しましたが、より専門性の高いものを身に着けたいという方には、また別の機会にお勧めのものをご紹介させていただきます。

まずは一般的な内容を理解して、そのあとは実際のプロジェクトの中で業務要件定義を行い、学んだ知識を活用していきましょう。

関連記事