前回はWBSの最初のタスク（プロジェクト準備）について説明いたしました。
今回の記事では、要件定義移行の工程のWBSタスクについての説明をしていきたいと思います。
1.要件定義フェーズの主なWBSタスク
Salesforce導入プロジェクトの要件定義工程のタスクは以下のようなものとなります。Salesforce以外のシステム開発以外がない場合については、基本的に基盤（インフラ関連）の要件検討が不要となります。
また、非機能要件に関しても基本的にはセールスフォース・ドットコム社が提示している内容に準拠したものとなるため、一般的なシステム開発と比べると要件の検討にかかる工数は少なめになるかと思います。
ただし、お客様はクラウドサービスに対する不安として、機密情報やお客様の個人情報の漏洩がないかなど、セキュリティ面に関しては、厳しい目でチェックされるため、Salesforceの基本アーキテクチャやセキュリティ対策についてはしっかり内容を理解して説明できるようにしておきましょう。
1.現状調査(AS-IS)
最初に定義するタスクの分類としては以下のようなものになります。
参考
- 現状(AS-IS)調査、要件整理
- 組織構成確認
- 現行システムの調査
- 現行業務プロセスの調査
- 現行業務フロー図の作成
Salesforceでは、ロールやプロファイルを使って、システムの権限設定を行いますが、その際に、お客様の組織図ベースで検討をすることも多いため、最初にお客様の組織構成は把握しておくことをお勧めします。
また、業務体系を把握する場合やヒアリングを行う場合にも、どのような部署が存在して、組織内での業務上の役割は何かということを把握するためにも必要となってきます。
続いて、お客様の現行業務の境調査を行います。プロジェクトによっては、要件定義の前のグランドデザイン（基本構想/戦略）工程で実施する場合もあると思います。その場合には、現状調査した結果の成果物（業務フロー、業務説明書、課題と施策一覧）などがあれば、次の検討を実施することができるため、タスクとしては不要となります。
要件定義工程で実施する場合であっても、要件定義を短期間で効率的に実施するために事前に現状の業務内容についての事前調査を各現場の担当者へ依頼しておくとよいでしょう。
普段実施している業務であっても意外と説明できなかったり、課題として意識されていないこともあるため、事前に検討してもらうことで効率的に課題を抽出したり業務内容を整理することができるようになります。
また、この時点で現場担当者が抱えている課題・問題点や改善要望も合わせて確認しておくことをお勧めします。
現状の業務ヒアリングのテンプレートは以下に公開しておりますので、ご利用ください。
-
-
参考業務ヒアリングシート（Excelテンプレート）
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した業務ヒアリングシートのテンプレートをご提供しております。 他にも要件定義で必要な以下 ...
続きを見る
2.システム要件定義
現状調査が完了したら次は将来像（To-Beモデル）の検討となります。インプットは、現状調査した業務フローや課題・要求事項などとなります。
これらを用いて、業務改善ポイントの検討やシステム化要件を取り纏めていきます。
業務コンサルタントがいる場合には、業務改善の工程が入ってきますが、本記事ではシステム要件定義にフォーカスして説明していきます。
現状調査結果に基づき、システム化の方針を検討し、新システムを用いたプロセスを検討し、新業務フロー図を作成します。また機能要求については、別途要求機能一覧として整理しておきます。
- 将来像（TO-BE）モデルの検討
- 新業務フロー図の作成
- 新業務一覧の作成
- システム化方針
- 機能要件の整理（要求機能一覧）
上記タスクの定義が完了したら、取り纏めた内容をもって、現場担当者を交えて検討会（ワークショップ）を開催して、課題の対応方針や新業務プロセスについて現場の意見を取り入れてブラッシュアップしていくというタスクがあります。
システム化の方針と要求機能一覧が整理できてきたら、システム機能詳細の検討に入っていきます。
システム機能要件の検討段階では、以下のようなタスクが発生します。
（要求機能を具体的なシステム機能に落とし込んでいく作業）
参考
- システム機能要件の検討
- アクター定義、新業務フロー定義、状態遷移（ステートチャート図）の作成
- システム機能一覧の作成
- データモデルの検討
- ER図（データモデル定義）、オブジェクト一覧の作成、項目定義書の作成
- CRUD図（機能レベル）
- UI規約の定義
- UI規約、画面一覧、画面遷移図
- 帳票定義、帳票一覧、帳票定義書
- 外部インタフェース定義
- 外部インタフェース一覧、外部インターフェース連携図（概要）
一般的な要件定義では、要求機能一覧をベースにシステム機能一覧を作成していきます。
システム機能一覧の作成手順などは、別途要件定義の記事で詳細を説明しますが、ここでは要求機能からシステム機能への落とし込みをしていくためのインプットとなる要求仕様の整理を行います。
要求仕様の一覧を作成し、業務領域、プロセス、課題・問題点、業務要求、改善効果、対応方針などを取りまとめておきます。これをもって、業務改善/システム化の切り分けや対応の優先順などを決めていきます。
-
-
参考要求仕様管理一覧（テンプレート）
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成した要求仕様管理一覧のテンプレートをご提供しております。 プロジェクト発足時点でお客様の ...
続きを見る
機能要件の整理とは別に非機能要件の要件検討タスクも定義します。
SalesforceはSaaSのため、インフラ関連の非機能に関しては、検討事項は少なくなりますが、非機能で検討すべき内容は、IPAが公開している非機能要求グレード表を用いて、検討が必要な項目の洗出しのタスクは定義しておきましょう。
参考
- 非機能要件検討
- 非機能要求グレード表を用いた要件のヒアリング
- セキュリティ方針
- 運用・保守性の検討
- 可用性検討、信頼性要件、上位互換性要件
- 規模要件、性能・拡張性検討
非機能要求グレードについては、以下、IPAの公式HPからダウンロードして利用することができます。詳しい利用方法の解説もあります。
IPA情報処理推進機構「システム構築の上流工程強化（非機能要求グレード）」
続いて、設計やテスト方針、教育要件、移行要件に関するタスクを定義しましょう。
教育や移行に関しては、要件定義では方針、スコープ、体制・役割、（大日程）スケジュールについての検討を実施するためこれらの検討タスクを定義しておきましょう。
参考
- 設計・テスト方針書の作成
- 設計方針
- テスト方針
- 教育要件の検討
- 教育方針、対象者、実施方式、スケジュール
- 移行要件の検討
- 移行方針、移行範囲、体制」役割の検討、移行スケジュール（概要）
- 移行環境、業務移行方針、システム移行方針、データ移行方針
- 標準化ドキュメント一覧（更新）
-
- プロジェクト標準用語定義書
- 名称付与基準
- コード定義書
- システム運用作業支援ツール一覧
- 標準化ドキュメント一覧
-
標準化については、プロジェクトで利用する用語集の作成や設計フェーズ以降で必要となる命名規約等のドキュメントの作成タスクを定義します。
そのほか、Salesforceの要件定義では、プロトタイプを作成して、画面イメージや操作感などを検証することが多いと思います。
その場合には、環境の準備やプロトタイプを作成するための設定・開発工数がかかるためこれらもタスクとして定義しておきましょう。
参考
- プロトタイプ作成
- 環境構築
- オブジェクト設定（〇〇）
- 画面レイアウト整理
まとめ
以上が、要件定義工程のタスクの説明となります。
クリエイティブコンテンツラボトウキョウが提供するExcelのWBSテンプレートをダウンロードしたいという方は、こちらをどうぞ。
-
-
参考WBS（work-breakdown-structure）（Excelテンプレート）サンプル
本記事では、Creative Content Lab Tokyo（クリエイティブコンテンツラボトウキョウ）が作成したWBS（work-breakdown-structure）のテンプレートをご提供して ...
続きを見る
関連記事
