「システム開発プロジェクトを進める際、要件定義は最初の工程となります。要件定義では、ユーザー様から要求（―がしたい）をヒアリングし、システムの要件（―機能が必要）の整理を行います。この記事では、各拠点の既存システムをグローバルシステムとして統一することを目的に3D EXPERIENCE Platformでシステムを再構築した時の要件定義の体験を紹介します。」（マッキ―）
「マッキ―・グリーンーーーーー！、まだ紹介済んでないんですけど？」（松岡）
「あ、そうですね、失礼しました。いつもセッション時間を気にしてますので、早く始めないと、と思って・・・」（マッキ―）
「わかる わかる、特に要件定義のセッションって時間が足りないものね。」（松岡）
「昨日のセッションも、３時間の予定が４時間半になりました。」（マッキ―）
「私の経験でも、要件定義ってユーザ様が自分の仕事がこんなのでこうなってほしい、もしくはこんな事ありますけど、なんとかしてもらえるんですよね、を語ってくださるによね。そうすると、EBOMの要件定義で、工務さんが出てきて出荷指示や、仕入先からの納入部品の設計変更の切替指示はどのようになりますか？って聞かれるのよ。」（松岡）
「ふんふん」（マッキ―）
「それって、量産後の生産管理の範囲でしょう？ 生産管理の部品表に対してEBOMの設計変更情報をどのように連携するかって言う話で、しかも既に生産開始しているので在庫があるでしょう？ すると、設計変更の種類：つまり即時切替か、ランチェンかによって対応違うし、ランチェンだと生産管理の部品表はキーの品番情報が変わらない場合もあるし・・・ と言うような事をITベンダー側が理解して要望の切り分けしないと、どんどんわけのわからないセッションになって行ってしまうの」（松岡）
「本当に要件定義って難しいし、責任重大よね。じゃ、今回はエスツーアインジャー・グリーン事、マッキ―（実名出すなと言われたので）が説明してくれます。よろしく！」（松岡）
それでは・・・マッキ―です。
今回お話する内容は、要件定義で気を付けたい事を僕の経験の中からまとめてみました。
ユーザー様から要求をヒアリングし、最終的には要求機能一覧・既存業務プロセスを作成します。ヒアリングは、システムへの要求が明確であれば苦労しないが、大抵はユーザー様の要求は漠然としている為、こちらから上手に引き出す必要があります。
- 既存の業務プロセスを迅速に理解する
既存の業務プロセスを理解しないと、ユーザー様が問題に感じていることから要求を引き出せません。既存の業務プロセスを理解し、その後、要求をヒアリングすることになります。
- システム構築の目的を明確にする
ユーザー様の要求をすべてそのままシステムの要件とすると、本来の目的からずれてしまう可能性があります。グローバルシステムとして統一することを目的としている場合、各拠点用にユニークな機能が出来上がってしまった、ということがあるので注意が必要です。
要件定義
要件の整理は、要求機能の実現方法（具体的な機能を考える）を検討し、最終的にはシステムの機能一覧・業務プロセスを作成し、ユーザー様と認識のずれがないかを確認します。3D EXPERIENCE Platformなどのパッケージを用いてシステムを構築する場合、パッケージ標準機能と要求機能のFit&Gapを行います。
パッケージ標準機能を把握する
当たり前のことですが、標準機能を把握していないとFit&Gapは行なえません。標準機能で要求を満たせない場合、カスタマイズによる実現方法を検討する必要がある為、カスタマイズできる範囲も把握しておくべきです。特にルート関連はカスタマイズできる範囲が限られている為、注意が必要です。
パッケージ標準機能を紹介する
Fit&Gapを円滑に進める為にパッケージ標準機能とパッケージのコンセプト（何が出来て何が出来ないか）をユーザー様に紹介した方がよいです。例えば、3D EXPERIENCE Platformの場合、リリース済みデータを運用管理者であれば自由に編集したい、というコンセプトに反する要求がありました。事前にコンセプトを説明しておくことで、早めに代替機能・業務プロセス変更の提案が行えます。
パッケージ標準機能で提案する
開発工数の増大につながる為、標準機能で機能を実現する方法をユーザー様に提案し、パッケージのカスタマイズは避けるべきです。業務プロセスを標準機能に寄せてもらえないかも交渉した方がよいです。標準機能で画面の表示内容をCSV出力する機能がある為、画面とほぼ同じ内容をテキスト出力したい、という要望は標準機能で対応できます。
要件定義でシステム開発プロジェクトは終わりではなく、以降に設計・開発と続きます。要件定義で機能を確定させても、システムを使用するエンドユーザー様からの要望などで仕様変更が発生します。（残念ながら・・・）
例えば、注文数・実績数の入力は誤りがあっては行けないので、同じ内容を2回入力シチェックする、という機能が本番稼働前にエンドユーザー様から「同じ内容を2回も入力するのは手間だ！」と言われ仕様変更したことがあります。
仕様変更の際、要件定義で決めたコンセプトは守るよう心掛けよう！（そうしないとシステムの役割があやふやになります）（マッキ―）
【まとめ】
要件定義の終了前に要件定義の結果に問題がないかユーザーに確認していただくことになりますが、まだシステムはなく資料上でしか確認できない為、ユーザーは要求機能が要件として機能・業務プロセスに反映されているか正確に判断できません。システム開発側で要件定義の精度向上を心掛けるしかありません。
要件定義の精度を上げる為には、各要求の深掘りを行います。期間は限られているので、効率的にユーザーから情報を引き出す必要があります。その都度何をやるか考えるのではなく、準備期間でやるべきことをリストアップし、要件定義を行いましょう。
「要件定義は教科書通りにはいかない事がおおいからね、これからも精進していきましょう！次回最終回は、3DEXPERIENCEの開発(カスタマイズ)についての話を、エスツーアインジャー シルバーこと竹内くんに話してもらいます。乞うご期待！！」（松岡）
＜バックナンバー＞
第一回：BOMから見つめなおす業務改革 第二回：ENOVIAで製造BOM育成過程を管理する 第三回：BOMの活用方法
エスツーアイ株式会社：3Dエクスペリエンス・プラットフォーム ENOVIA
http://www.s2-i.co.jp/handling_products/product_enovia.html
エスツーアイ株式会社へのお問い合わせ：
3Dソフトウェア市場におけるパイオニアであり、3DとPLMソリューションのワールド・リーダーであるDassault Systèmes（仏）の日本法人です。