DX推進、システム関連の刷新・再構築プロジェクトは発足したけれど、何から手をつければ良いのか？どこまでやればゴールになるのか？何をすることでプロジェクトを成功に導けるのか不安になってはいませんか？
システムを開発や導入する時に一番始めに行うことは「要件定義」です。
要件定義は平たくいうと、システム化する対象の業務を整理・明文化していくことです。
業務を整理・明文化することで、必要な機能はなにか？業務で今後何をして行きたいのか？が見えてくるようになり、業務部署とシステム部署ですり合わせをすべきことが双方認識できます。
この記事では、私が5年間に渡り業務部署メンバーとして参加した、マスタ再構築とシステム刷新プロジェクト参画の経験から「漏れ」「認識齟齬」が起こりにくい要件定義をしていくために行った流れをお伝えします。
「うまく整理が進まなかったこと」や「システム稼働後の認識齟齬が起きた理由」なども合わせてご紹介を致します。
どのようなプロジェクトでも全体像を把握し、整流化された情報で認識を合わせることができれば、手戻りの削減や稼働時開始時のトラブルも回避しやすくなります。
プロジェクト概要（マスタ再構築とシステム刷新）
始めに、どういったプロジェクトだったのかをご説明致します。
一つめのプロジェクトは「全社的なマスタ再構築」です。
目的：マスタ項目のスリム化、未来のデータ活用を見据えた項目追加とマスタ項目間の関係の見直しです。会社としてマスタ（データ）そのものの価値をあげることが目的でした。
参加者：全業務部署（一部はスポットで参加）から各1〜２名程度で、20名程度。
打ち合わせ時間：期間は2年間で、打合せは毎週4時間を2回、計8時間を継続し合計で約800時間を費やしました。
個人作業時間：通常業務との比率は3:7ほどになり、定義書・業務説明書類・マスタモデル図の作成で、週20〜25時間程度の割合でした。
二つめのプロジェクトは「物流システム刷新」です。
目的：「定型業務の自動化」と「操作方法の変更」による業務効率改善です。
参加者：物流部４部署から３〜４名ずつ、商品部、財務部など必要に応じて参加。20名程度。
打ち合わせ時間：2023年に開始して、2026年完成をめざし、週5時間の打合せを4年間で合計で約1,000時間を程度になる予定です。
個人作業時間：業務フロー図・要望事項リスト・仕様書作成などで、ばらつきもありますが、おおよそ週10〜20時間程度です。
全社マスタ再構築の流れ
プロジェクトの狙い
「必要な時」に「必要な情報」を抽出できる環境を構築し、DX視点で価値あるデータ活用ができる状態とする。
立ち上げ当初の試行錯誤
最初の3か月
- 自社の各部署から代表が集まり、現行システムのマスタ項目をExcelへ書き出し
- 「要否」を判断しようとしたが、中身を正確に把握していない項目が多数あることが判明
- わからない項目は「とりあえず残す」となり停滞
上記のような流れで取り組みを開始しました。進め方に明確な計画がなかったものの、現行システムに不要なマスタ項目が存在いているので、洗い出しをして削る行為が必要だということはメンバー共通の認識としてありました。しかしながら、ジョブローテーションが頻繁な企業文化のため、詳細を把握していた担当者が異動でいなくなっている状況も多く、要否の判断ができないことが多く発生しました。
コンサル導入で加速
背景
立ち上げから6か月の成果物が、現行システムから抜き出したマスタ項目名のExcel一覧だけだったため、プロジェクトリーダーと上層部が危機感を抱きました。
そこでマスタ再構築を得意とするコンサルティング企業様に伴走してもらう形への切り替えに至りました。
コンサルティング企業様の役割
- ミーティングでのファシリテーション
- 定義書やモデル図を作成するためのノウハウ提供
- 作った成果物の添削や改良点を指導
業務部署が作業主体で、コンサルティング企業様には手順を明確化し、議論を整理するサポートをしていただきました。
マスタ項目の意味定義
定義書の作成
コンサルティング企業様と一番始めに行ったことは、もともと自分たちでリストアップしたマスタ項目の定義づけです。「言葉そのものの意味を明確にする」ということももちろんありますが、「どの部署が」「どんな時に」「何のために」使う項目かを言葉にしてまとめることが重要です。
定義づけの効果
- 認識の齟齬が起きにくい状態とすることが可能に
- 項目の要否を論理的に判断が可能に
- 必要な項目は用途や価値が明らかになり、集計や分析に活用しやすく
意味定義での目的は、今ある情報の重複の洗い出し、会社の誰もがそれぞれのマスタ項目を同じものと認識ができる状態とすることです。
＼定義についてはこちらの記事で詳しく説明しています！／
実際に発生した手戻り事案！
システムからマスタ項目を抽出し整理を行いましたが、終盤で多くの未整理の項目があることが判明しました。それは、各部署で独自にExcel管理をしていたマスタ項目です。システム管理されていなかったこともあり、粒度も精度も整っていない状態になっていました。
しかしながら、各部署で独自管理をされるような情報ほど、より今の現場で重視される情報ということになります。DX推進の観点で見ても分析軸として使われることも想定されます。
改めて意味定義を行ったのちにマスタ項目に組み込んで、他のマスタ項目同様会社の資産として管理ができる状態としました。
私の参加したプロジェクトでは、気づくことが遅くなってしまったため、後からの整理になってしまいましたが、既存システムのマスタ項目抽出と同じタイミングで整理をする事をお勧めします。
マスタ項目の使用状況の確認
不要項目の整理
- 意味定義をするまでもなく使っていないことが明確なので、不要と判断
- 意味定義ができず意味をなしていないことがわかったので、不要と判断
上記の２点が、ここまで進めたことにより整理ができている部分です。
言葉そのものの整理は進めてきたものの、業務にとって必要なマスタ項目であるかどうか整合を取ることを行います。長く使われているシステムであればあるほど、過去の業務に合わせたものになっています。業務オペレーションそのものも大きく変わっていることでマスタ項目もそぐわなくなっているかもしれません。
業務と付け合わせによる成果
一つ一つのマスタ項目を丁寧業務と付け合わせして行くことで「わからないから残す」ができなくなります。
また、更新の頻度や担当が明確化し、業務そのものも整流化したことでマスタ自体が自然とスリム化して行きました。
DX視点でマスタ新規項目の追加検討
マスタ項目追加の狙い
これまで社内では管理されていない情報であっても、未来のデータ活用を考えた時に加えるべきマスタ項目を検討する必要があります。業務との付け合わせをして行く中で、業務部署として必要な項目を精査します。
新しいマスタ項目の追加をすることで、より会社のマスタの価値を高めることができます。
マスタ項目を追加する時の注意点
正しく運用されることが計画されていないマスタ項目が増加すると、無駄な管理コストとデータ量が増えることになります。
具体的な分析事例を想定し、得られる効果を明文化することが重要です。
マスタモデル図による構造の視覚化
マスタモデル図の作成の目的
モデル図は、情報の塊単位で作成したものを関連した情報通しを線で繋いでいくようなものになります。
マスタ項目同士を関係を視覚的に捉えることが可能となり、観点が不足していないかどうかの判断材料となります。また、実際にシステムを開発をする際にシステム側としてはマスタ項目の関係性を見ながらテーブルの設計を行なって行くこととなります。
検討経緯の資料化
資料化の必要性
検討経緯の資料化の目的は、過去の経緯を明文化しシステム開発という長期のスパンになるプロジェクトで、風化することがないように情報を残すことで、ブレのないシステム開発を推進できます。
資料には、2年間の議論を500ページ超のパワーポイントにまとめることなりました。
「なぜこの項目を残し、新規項目を追加したか」を時系列で記録し、仮に開発期間中に方針が変わった場合でも検討経緯に追記を行なって行くことで、適切な管理を継続することが可能になります。
少しずつ検討を進めていた時と変わっていってしまうことで、思い描くデータ活用ができなくなる事を避けなければなりません。
実現がされなかったこと
プロジェクト内では、マスタを管理する部署の新設も上層部へ提案をしましが、残念ながら実現することはありませんでした。
マスタ項目の管理をするにあたり、部署関係なく横串を通していくことで、より精度高く情報を保つことができると思います。
物流システム刷新の流れ
プロジェクトの狙い
発注・入出庫・在庫管理・物流経費精算を行うシステムの改修・更新するプロジェクト。
IE（Internet Explorer）のサポート終了に伴うセキュリティ脆弱化への対応と刷新時の業務見直しによる効率化の検討がメインで行われています。
2つの視点で見る機能要望リストの作成
要望リスト作成
まずは物流部だけで、現行システムの課題や機能要望の洗い出しをしました。
- 「検索条件に〇〇を追加したい」
- 「発注フローを自動化したい」
上記のように大小関係なく、各業務部署が要望をあげ連ねました。
要望を出すにあたり大きく2つの視点で、リストアップする事をお勧めします。
１）業務を一連の流れで捉えた時の業務デザインの変更希望
未来を見据えた業務を部・課全体で検討する必要があります。
２）日々の業務の中で、使いづらさを感じる点の変更希望
どんな些細な内容でも問題ありません。不要であれば、後から取り下げれば良いのです。
要望出しが漏れることの方が、後で後悔をすることになります・・・
要望リストの全体レビュー
各課の要望が偏っていないかを部署全体でチェックし、必要性をすり合わせします。
同一画面を複数部署が使用することもあり、それぞれの要件がぶつかることで、
一部の偏った要望しか満たせない可能性がないか確認をしていきます。
業務要件のリストアップは、8か月程度で完成しました。
具体化な表現で、誰にでもわかる言葉を使い、資料を作成するということは多くの時間を要することとなります。
新旧業務フローと機能仕様のすり合わせ
業務フロー図と仕様書は、現行版と刷新版の両方を用意します。
上記が、新旧双方をみることのメリットです。
刷新後の業務フロー図と機能要望書との整合
新しいシステムに実装したい機能については、前段で整理をしました。
しかしながら、ただ実装をすれば良いというものではありません。
- 前後の業務と正しくつながっているか。
- 業務を一連の流れで見た時に筋が通っているか。
上記２点確認をするのに使用するのが、業務フロー図と仕様書です。
また、システムができた時のテストケース検討する際にも業務フロー図は利用されます。
画面サンプル作成
要望事項を実際の画面で表現
業務担当目線で「こんな画面なら使いやすい」という案を作成します。
すでにある機能の画面は、現行システムに追記をして行くと業務部署メンバーとしては作業がしやすいです。
注意をして見て行きたいポイントは以下です。
- 検索条件
- 検索結果の表示項目
- 各画面に必要な機能（登録・更新・削除・計算 etc…）
全て現行のままでいいということはないと思います。日々の業務の中で、こうなっているともう少し作業がしやすいのに。この情報がこの画面にもあれば、画面遷移する回数を減らせるのに。といったことがあると思います。もちろん全てを実現できるとは限りませんが、改善ができる事を明確にお伝えできる内容については漏れなく全てを共有して行くことが重要です。
完全新規の機能を要望している場合は、業務部署のイメージする画面をExcelベースで作成します。
レビューと修正
課によって使い方が異なる機能は、同じ部署内でも衝突が起きることがあります。
画面サンプルをもとに共通仕様を固め、最終的にシステム部署へ提出することとなります。
仕様書の見直し
業務部署が検討すべき内容の精査
仕様書の見直しと聞くとシステムの業務と思われるかもしれません。確かに、システム部署が見るような内容が多いです。しかしながら、業務的な判断基準はシステム部署にはわかりません。業務部署がどんな時にどのような判断をして欲しいのか？をロジックとしてシステムに組み込んでいく必要があリます。
業務部署が仕様書を見直すことで、より精度高くシステムをコントロールしていくことが可能になります。
細かい点をあげればキリがないですが、主に見るべき点は３点
- 計算ロジックがある時には、どんな計算式なのか？
- 自動通知などがある場合、どんな時になんの通知がでるのか？
- 画面あるいは帳票上に表現するべき情報はなにか？
過去から残っているロジックを見た際に、どのように修正をするべきなのかが読み解けないということも往々にしてあります。読み解けないロジックを修正していくと、必要な要件を満たせているかの判断ができません。そういった場合は、思い切って業務に合わせてロジックを新たに組み直すことも検討してみてください。
本稼働までの今後の流れ
モック画面作成とレビュー
システム部署やベンダーが仮の画面を業務部署に提示し、業務側が操作感や項目を確認していくことになります。
情報の過不足がないか？画面の遷移は思ったような動きか？などこのタイミングで見直しをかけることができないとシステムが稼働した時に思ったような業務効率改善にならないことも発生しかねません。
完成は2026年春を予定
開発の途中でも機能追加や仕様変更があると想定されます。
しかし、前段の定義やフロー化をしっかり行ったため、大幅な手戻りは抑えられる見込みです。
ただし、マスタの再構築同様にこちらでも検討の経緯は残しておく必要があります。
特にマスタの再構築よりさらに長くなることで、部署内のメンバーが変わることも想定されます。
部署として実現をしたかったこと、会社方針との整合が確認できる状態にしておくことで、ブレのない開発推進をすることができます。
まとめ
結論
成功するDX推進やシステム刷新の鍵は、初期段階からの「正しいステップを踏んだ要件定義」にあると考えます。
業務内容を整理し、各部署の認識を統一することで、不要な情報の混在や認識齟齬を防止できるからです。
体系的な要件定義により、手戻りの削減やシステム稼働時のトラブル防止が実現できます。
マスタ再構築の流れ
初期の試行錯誤
現行システムからマスタ項目を洗い出し、「とりあえず残す」だけでは進まないことが明らかになりました。
外部コンサルタントの活用
定義書やマスタモデル図の作成、議論の整理により、各部署間での認識が統一され、進行がスムーズになりました。
具体的なプロセスの実施
マスタ項目の意味定義、使用状況の確認、新規項目の追加検討、モデル図の作成、要望リストの整理、業務フローと仕様書の整合など、体系的な手順を踏むことで、DX推進の基盤がしっかりと構築されました。
システム刷新の流れ
機能要望リストの作成
物流部内で現行システムの課題や要望を洗い出し、業務デザインの変更希望と日常業務での使いづらさの改善を具体的に整理しました。
新旧業務フロー・仕様書の整合
現行と刷新後の業務フロー図および機能仕様書を並行して作成し、変更点や不足事項を明確化することで、システム実装時の整合性を確認しました。
画面サンプル作成とレビュー
業務担当者の視点を取り入れた画面サンプルを作成し、操作性や表示項目について詳細なレビューを実施することで、現場の使いやすさを重視しました。
仕様書の見直し
自動計算ロジックや通知条件など、業務上必要な細部まで検証し、システムが実際の業務に適合するよう、仕様書の精度を高めました。
以上のように、体系的に要件定義を進めることが、プロジェクト全体の整流化とDX実現に大きく寄与するといえます。
ぜひ、今回ご紹介した要件定義の手法やプロセスを参考に、貴社のDX推進・システム刷新プロジェクトにお役立てください。今すぐ具体的な業務整理に取り組み、部署間での認識統一を図ることで、プロジェクトの成功に大きく近づくことができます。まずは現状の業務を見直し、明確な要件定義からスタートしましょう。
