基幹システムの移行 ～スクラッチ開発からパッケージ製品への転換～

はじめに

　企業の根幹を支える基幹システム。そのリプレイスは、企業の成長戦略において重要な役割を果たします。しかし、技術革新の波は常に押し寄せ、古いシステムは徐々にその役割を果たすことが難しくなります。
基幹システムの移行という、企業にとって一大転換期となるプロジェクトの過程で、プロジェクトメンバーや関係各社との連携、そして数々の予想外の課題に直面します。
本コラムでは、実務で得られた知見をもとに、スクラッチ開発のシステムから、パッケージ製品のシステムへの移行を検討します。
　特に、製品選定までのフェーズに着目し、フェーズを通して顕在化しやすい、導入初期の構造的な課題を取り上げます。そして、それらの課題とその対策を、体系的に整理して解説します。
移行事例から得られた知見をもとに、製品選定までのフェーズで見落とされがちな論点を整理し、移行を検討中の企業に対して、実務的な判断材料を提供します。

業務ヒヤリング

　業務ヒアリングは、現状把握、ニーズの理解、コミュニケーションの促進、リスクの軽減、要件の明確化など、プロジェクトの成功に不可欠な最初のステップです。実際に業務ヒアリングを行う中で、試行錯誤した点や具体的な留意点を整理します。
業務ヒアリングを行うにあたり、まず直面するのが、ヒアリング対象者の選定という課題です。基幹システムは全社に関わるため、全ての社員にヒアリングを行うことが理想です。
しかしながら、現実的には時間やリソースの制約があり、すべての社員にヒアリングを行うことは不可能です。そこで、対象業務のキーパーソンや、業務に精通している担当者を中心に、ヒアリング対象者を選定する必要があります。
　ヒアリング対象者選定にあたっては、ヒアリングの目的や伺いたい事項などをまとめたヒアリング依頼書を送付し、内容を説明し、理解を得ることも必要です。
　次に管理責任者に意見を聞き、推薦された担当者の中から、業務経験や知識、コミュニケーション能力などを考慮して、最終的にヒアリング対象者を選定します。
　ヒアリング内容を整理するには、漠然とヒアリングを行うのではなく、事前にヒアリング項目を整理し、効率的に情報を収集できるように準備することが重要です。
具体的には、現状の業務フロー、課題点、改善点、新システムに求める機能、将来的な展望などをヒアリング項目に設定します。
　ヒアリング本番前には、一部のヒアリング対象者に協力をいただき、試験的なヒアリング（プレ・ヒアリング）を実施することで、ヒアリングすべき事項の精度向上に繋げられます。
また、ヒアリング項目は、事前に共有し、回答内容を検討してもらうことで、ヒアリング当日の時間を有効活用できるような工夫も必要です。
　次にヒアリングの実施です。ヒアリングは、規模や状況に応じて、オンラインやオフラインを使い分けます。特にオンラインの場合では、オンライン会議用の機器が備わっているか、または機器の貸し出しが可能かなども事前に確認すべきです。例えば先方はノートパソコンのマイクやスピーカーでヒアリングに参加されると、音声品質の問題によってヒアリング精度が低下するリスクがあるため、事前に接続環境の確認と機器の準備が求められます。
　ヒアリングでは、相手の心情に寄り添い、共感を得るよう心がけます。単に業務内容を尋ねるだけでなく、業務に対する不満や課題、改善点などを聞き出すことで、より深い情報を得ることが可能です。
また、ヒアリング対象者が話しやすい雰囲気を作ることも重要です。雑談を交える、笑顔で接するなど、相手が話しやすい雰囲気づくりに努めることで、相手も心を開きやすくなります。オンラインの場合は、録画を行うことで、内容を正確に振り返ることが可能です。
　ヒアリングでは、操作性・応答性・インターフェースに対する不満が特に顕著に現れます。スクラッチ開発の場合、システムは日々アップデートされていますが、ユーザーの利便性をあまり考慮せずにスクラッチ開発が行われるケースもあります。また、基幹システムは、現在主流なブラウザベースのシステムではないことも応答性やインターフェースに対する不満に繋がっています。基幹システムを管理している管理部門と、システムを使用している利用部門では、これらの不満に対してもギャップがあることに気づくかもしれません。
　ヒアリング後は、結果の取りまとめと共有です。ヒアリング結果をまとめ、ヒアリング対象者と共有することで、認識の齟齬を解消し、より正確な情報を得ることができます。
　また、ヒアリング結果をプロジェクトメンバー間で共有することで、問題意識を共有し、より良い解決策を見出すことが重要です。
　共有の際には、ヒアリング内容だけでなく、ヒアリングから得られた示唆や利用部門の温度感を共有することで、プロジェクトメンバー間のコミュニケーションが円滑になり、より深い議論ができるでしょう。
　業務ヒアリングを通して、様々な気づきが得られます。先に挙げた、操作性や応答性、インターフェース以外にも例えば、同じ業務でも担当者によって業務に対する認識が異なることや、利用部門ごとに独自の運用を行っていることが多い点や、本社との連携がうまくいっていないことなど、多岐にわたります。
　これらの気づきは、後の工程で要件定義を行う際に、非常に重要な情報となります。

現状分析（As-Is）

　現状分析は、業務プロセスやシステムの現状を詳細に把握するための重要な情報源です。現状の業務フローやシステムの課題を明確にすることで、どこに改善が必要で、どのような改善が可能かを判断することができます。
　現状分析を行うにあたり、まず取り組むべきことは、業務の一覧化・詳細化です。各業務の実施者、インプット、処理方法、アウトプットなどを洗い出し、業務フロー図として一覧にまとめます。
担当者の協力のもとに作成することで、より業務の実態に即したものができるでしょう。
この作業は、業務全体を把握する上で非常に重要です。また、業務フロー図を作成することで、業務の流れを可視化し、より理解を深めることが可能です。
　次に、問題・課題の導出です。問題・課題は人によって重要度や優先度が異なるため、各担当者にヒアリングを行い、それぞれの意見を収集します。
　また、アンケートを実施することで、より多くの意見を集めることができます。アンケートでは、業務に関する自由記述式の質問だけでなく、具体的な課題を尋ねる選択式の質問も設けることで、より多くの情報を効率的に収集することが可能です。
　現状分析の結果、様々な課題が浮き彫りになります。例えば、業務プロセスが複雑化・属人化していることや、担当者間の連携が不足していること、情報共有がスムーズに行われていない点などです。
これらの課題は、業務効率を低下させるだけでなく、顧客満足度にも影響を与える可能性があるため、注意が必要です。
　これらの課題に対し、どのように対応していくかを検討する中で、様々な葛藤があります。例えば、担当者の意見を尊重するべきか、それともシステムの効率性を優先するべきか、といったことです。また、コストやスケジュール上の制約もあり、全ての課題を解決することは難しい状況です。
　最終的には、担当者の意見を尊重しつつ、システムの効率性を高めるための妥協点を見つけることが必要です。具体的には、業務プロセスの標準化や、システムによる自動化、連携ツールの導入などを検討し、優先度の高い課題から順に対応することが求められます。

業務のあるべき姿（To-Be）

　現状分析によって得られた情報をもとに、業務のあるべき姿を定義することは、理想と現実のギャップを埋め、業務要件を明確化する上でも必要なステップです。
　業務のあるべき姿を定義するにあたり、まず行うべきものは、タスクレベルでの本来の業務のかたち、業務のあるべき姿を導出することです。まずは機械的にあるべき姿を導き出します。
　この段階では、理想的な業務プロセスを追求し、現状の制約にとらわれずに、あるべき姿を具体的にイメージすることが重要です。
　次に、業務のあるべき姿について、担当者とのディスカッションを通じて、価値の共創により現実的な業務モデルの設計を促します。これにより、業務に対する理解を深め、より現実的なモデルを構築することができます。
　また、担当者自身にも業務のあるべき姿を考えてもらうことで、主体的な改善意欲を高めることができます。ディスカッションでは、あるべき姿のメリットだけでなく、デメリットや実現可能性についても議論し、議論結果を全社に共有し、アンケート形式で参加者以外の方々の意見も幅広く取り入れ、ブラッシュアップを行うべきです。
　これにより、参加者からは出てこなかった細かな内容も取り入れることができ、現実的な業務のTo-Beモデルとして結実させることが可能になります。

要件定義　

　要件定義は、新システムに求める機能や性能を明確にするうえで必要不可欠なプロセスです。
要件定義で最も苦労するのは、業務のあるべき姿をシステム要件として具体化する作業です。業務の内容を、システムで実現できる機能に変換する作業は、非常に困難です。
　特に、非定型業務や、判断を伴う業務をどのようにシステム化するのか、頭を悩ませます。この作業では、業務知識だけでなく、システム開発に関する知識も必要となります。時には開発知識を有するメンバーに協力を仰ぎ、要件を整理し、要件定義書の作成を進めることも必要です。
　自身の知識だけでは、対応が難しいものは、迅速に専門家の協力を得るのが重要です。自分で考えることも重要ですが、知識がないものに対して考えようとしても、時間を無駄にするおそれがあります。同時に頼ってばかりではなく、自身も知識をつけるために学習する必要があると感じ、時には学習を促進するきっかけとなることでしょう。
　要求事項の重み付けにあたっては、分析手法を用いることも重要です。例えば、MoSCoW分析という手法を用いて、Must（必須要件）、Should（あるべき要件）、Could（できれば欲しい要件）、Won't（今回は見送る要件）に分類し、優先順位をつけます。
　しかし、どの要求事項も重要に思えてしまい、なかなか優先順位をつけることができません。この作業では、関係者との議論を重ね、各要求事項の重要度を判断する必要があります。
　要件定義書を作成する際には、要求事項を整理し、優先順位をつけることが重要です。要求事項が多岐にわたる場合、すべてを盛り込むことは難しいことがあります。そこで、MoSCoW分析などの手法を用いて、要求事項を分類し、優先順位をつけることで、開発スコープを明確にすることができます。
　また、要求事項を具体的に記述することも重要です。抽象的な表現では、開発者に意図が伝わりにくく、誤解を生む可能性があります。
　例えば、「売上管理機能を強化する」という要求事項ではなく、「売上データを日別、月別、商品別に集計し、グラフ表示する機能を追加する」というように、具体的な内容を記述することが必要です。
　要件定義書は、業務部門や経営層にも共有し、内容について合意を得ることが重要です。これにより、開発段階での手戻りを防ぎ、よりスムーズなプロジェクト進行が可能になります。
　要件定義書は、プロジェクトの初期段階で作成されるため、その後の工程に大きな影響を与えます。したがって、慎重に検討し、関係者全員が納得できるものを作成する必要があります。