システム乗り換え前の「棚卸し」実践法：機能の見える化

「今のシステムを乗り換えたいが、まず何から手をつければいいのか分からない」——こうした相談は、Salesforceのようなクラウドサービスからの乗り換えを検討する企業からよく寄せられます。長年運用してきたシステムほど、当初の想定にはなかった使い方が現場に根付いていたり、逆に導入時に期待されていた機能がまったく使われていなかったりすることが少なくありません。

乗り換え先の要件定義をいきなり始めてしまうと、こうした「実際の使われ方」を見落としたまま設計が進んでしまい、後になって「あの機能がないと現場が回らない」「逆にこの機能は誰も使っていなかった」といった手戻りが発生しがちです。乗り換えプロジェクトの成否は、着手前の棚卸しの精度に大きく左右されると言っても過言ではありません。

この記事では、システム乗り換え前に行うべき棚卸しの具体的な進め方と、実務でよく直面するつまずきポイントについて解説します。

この記事の要点（30秒でわかるまとめ）

• 棚卸しの目的は「使っている機能」と「使われていない機能」を客観的に見える化することであり、思い込みで判断しないことが重要
• 棚卸しはログ・データ分析による定量調査と、現場ヒアリングによる定性調査を組み合わせて行う
• 棚卸しを飛ばすと、乗り換え後に「必要な機能が抜けていた」という手戻りが起きやすい
• 棚卸しの結果は、そのまま乗り換え先の要件定義のインプットとして活用できる

なぜ乗り換え前の棚卸しが必要なのか

結論：システムの発注担当者と実際に使う現場の認識にはズレが生じやすく、そのズレを埋める作業が棚卸しです。

システムを長期間運用していると、導入時に想定していた使い方と、実際に現場に定着した使い方との間にズレが生まれることがあります。管理部門は「この機能は重要だ」と考えていても、現場では別のやり方で代替していたり、逆に管理部門が把握していない使い方が現場で自然発生的に定着していたりするケースも珍しくありません。乗り換え先のシステムを設計する際にこのズレを放置すると、実態に合わない仕様になってしまうリスクが高まります。

定量調査：利用ログとデータからの棚卸し

結論：システムの操作ログやデータの更新状況を分析することで、「実際に使われている機能」を客観的な数字で把握できます。

• オブジェクト・項目ごとの更新頻度：直近半年〜1年でどの項目が実際に更新されているかを確認する
• 画面・機能ごとのアクセス頻度：ログが取得できる場合は、どの画面がよく開かれているかを確認する
• レポート・ダッシュボードの閲覧状況：作成されたレポートのうち、実際に定期的に見られているものはどれかを確認する
• 連携先システムとのデータ授受の有無：他システムとの連携が実際に機能しているかを確認する

こうした定量データは、担当者の主観に頼らず「使われている／いない」を判断する材料になります。ログが十分に取得できない場合でも、データの更新日時から間接的に利用状況を推測することは可能です。

定性調査：現場ヒアリングでしか分からないこと

結論：ログだけでは見えない「なぜその機能を使っているか／使っていないか」という背景は、現場へのヒアリングでしか把握できません。

定量データだけで判断すると、「更新頻度が低い＝不要な機能」と早合点してしまう危険があります。たとえば更新頻度が低くても、契約更新のタイミングなど特定の場面でだけ使われる重要な機能である可能性もあります。逆に、頻繁に使われているように見えても、実は代替手段がなく仕方なく使っているだけで、本来はもっと効率的な方法を望んでいる場合もあります。こうした背景を把握するために、実際に日常的にシステムを使っている現場担当者へのヒアリングを組み合わせることが欠かせません。

ヒアリングで確認すべき項目

• その機能・画面を、どのような場面で・どれくらいの頻度で使っているか
• 使いにくさを感じて、Excelなど別の手段で代替していないか
• 「本当はこうしてほしい」という要望や不満があるか
• 乗り換え後になくなると困る機能はどれか

棚卸し結果の整理と優先順位づけ

結論：洗い出した機能を「必須」「あると便利」「不要」の3段階に分類し、乗り換え先の要件定義に落とし込みます。

定量・定性の両面から洗い出した機能は、一覧表にまとめたうえで優先順位をつけることが次のステップになります。すべての機能を同じ重みで移行しようとすると、乗り換え先のシステムが不必要に複雑になってしまうため、「業務上どうしても必要な機能」「あれば便利だが代替可能な機能」「実質的に使われていない機能」を切り分けることが重要です。この整理表がそのまま、乗り換え先の開発会社選びや要件定義を進める際の土台になります。

棚卸しを飛ばすとどうなるか

結論：棚卸しを省略すると、乗り換え後に「機能が足りない」「使わない機能ばかり作られた」という手戻りが発生しやすくなります。

現場ヒアリングを行わずに管理部門の認識だけで要件を固めてしまうと、実際に現場で使われている運用が反映されないまま新システムが完成してしまうことがあります。その結果、稼働開始後に「この機能がないと業務が止まる」といった声が上がり、追加開発が必要になるケースも見受けられます。こうした手戻りは、開発の後半になるほど修正コストが大きくなる傾向があるため、着手前の棚卸しに時間をかけることが、結果的にプロジェクト全体の効率を高めることにつながります。

よくある質問（FAQ）

Q. 棚卸しにはどれくらいの期間をかけるべきですか？ A. システムの規模や関係部署の数によって異なりますが、定量調査と現場ヒアリングを合わせて数週間程度を見込んでおくと、後工程での手戻りを防ぎやすくなります。

Q. 複数部署で同じシステムを使っている場合、どう進めればよいですか？ A. 部署ごとに使い方が異なるケースが多いため、代表者だけでなく各部署から複数名にヒアリングを行い、部署間で要望が食い違う場合は擦り合わせる場を設けることをおすすめします。

Q. ログが十分に取得できていない場合はどうすればよいですか？ A. データの更新日時や作成者の履歴など、間接的に利用状況を推測できる情報を活用しつつ、ヒアリングの比重を高めて補うことになります。

Q. 棚卸しの結果は誰がまとめるべきですか？ A. システム担当部門が主導しつつ、現場の実態を正確に反映するために、各部署の代表者とすり合わせながらまとめる体制が望ましいです。

まとめ

システム乗り換え前の棚卸しは、利用ログなどの定量調査と現場ヒアリングによる定性調査を組み合わせ、使っている機能・使われていない機能を客観的に見える化する作業です。この棚卸しを丁寧に行うことが、乗り換え後の「機能が足りない」「使われない機能ばかり」といった手戻りを防ぐ最も確実な方法になります。

Irwin&co株式会社は、こうした棚卸しから要件定義、開発までを一気通貫で支援しており、フォームにご回答いただくと約3分で見積書・要件定義書を自動生成できる仕組みも用意しています。初回商談では実際に動くデモをご覧いただけますので、乗り換えを検討している場合はお問い合わせからご相談ください。開発事例はこちらでもご紹介しています。