ITロードマップではどのプロジェクトから始めるべきか
倉庫部門は在庫管理システムの入れ替えを希望し、営業部門は各拠点の情報をまとめたレポートを必要としています。経営陣はAIを試したいと考えています。どの提案にも理由があり、予算と担当者が必要です。一度に承認すると、要件の確認や成果の検証、導入後の運用を担う人が足りなくなることがあります。
ITロードマップとは、テクノロジーを使って何を改善するか、どの順番で進めるか、各段階でどんな成果を目指すかを示す計画です。どの提案を先に進め、どの提案を保留にするか、その理由や着手の条件を部門間で共有できます。個々のプロジェクトの詳しい日程は、別途計画します。
ここでは、新拠点の開設を控えながら、在庫を手作業で照合している企業を例に考えます。在庫管理システムの入れ替え、レポートの集約、AIによる需要予測の試行という三つの提案を、業務上の必要性と実行できる体制を踏まえて、どの順番で進めるかを考えます。 技術の話題性だけで着手順を決めると、足元の課題を見落としかねません。
1. プロジェクトを選ぶ前に課題を明確にする
まず各部門に、日々の業務のどこで困っているかを聞きます。「新しいレポートがほしい」だけでは、責任者が何の情報を必要とし、どの判断が遅れているのかが分かりません。「受注できるか判断するために、倉庫ごとに電話で在庫を確認している」と聞けば、解決すべき課題が見えてきます。
新拠点を開設する例では、在庫数がなぜ信用できないのかを確認します。出庫の記録が遅れていたり、同じ商品でも拠点ごとにコードが違っていたり、データが連携されていなかったりするかもしれません。原因によって必要な対応は変わります。記録の仕方が担当者や拠点によって異なるなら、集計ツールを購入する前に入力方法をそろえる必要があるかもしれません。
次に、どんな状態になれば業務が改善したと言えるかを具体的にします。例えば、受注担当者が各倉庫に電話をかけずに販売可能な在庫数を確認できる状態です。在庫確認にかかる時間、手作業で照合した件数、在庫情報の誤りで修正した受注件数などが手掛かりになります。何を測るかを現場と確認し、改善幅は実際の結果を見て判断します。
最初の手掛かりは、実際に起きた事例、普段使っているレポート、作業を担当する人への聞き取りから得られます。数値がそろっていなければ、何を調べる必要があるかを明記し、裏付けが得られるまでは削減率などを見込みとして示さないようにします。解決策を選ぶ前に、目的を絞った短い調査から始める方がよい場合もあります。
導入後の成果に誰が責任を持つかも決めます。開発チームが在庫を表示する機能を納品しても、倉庫と営業の責任者は、在庫情報をどう更新し、照合し、業務で使うかを合意する必要があります。予算が付いたプロジェクトでも、成果を引き受ける担当者がいなければ、現場の仕事が変わらないことがあります。
2. 共通の基準で提案を比較する
各部門には、課題、影響を受ける人、根拠、期待する成果、着手を見送った場合の影響を同じ形式でまとめてもらいます。その上で、想定する範囲、事前に必要な作業、関わる人を確認します。提案の見せ方に左右されず、各部門の実際の必要性を比べやすくなります。
影響の大きさと緊急度は分けて考えます。多くの人に役立つレポートでも、すでに受注が滞っている問題の方が先かもしれません。「急ぎ」という依頼には、開設日が決まっている、業務に支障が出ている、利用中のシステムのサポート終了が近いなど、具体的な理由が必要です。サポート終了日は、対象の製品とバージョンを確認した上で判断します。
購入や開発の後に発生する費用と作業も見込みます。データの整理、社員への操作説明、利用料の支払い、障害対応は誰が担うのでしょうか。初期費用が低い案でも、社内の作業が増える場合があります。情報が足りない段階では、見積もりの前提と、追加で調べる範囲を示しておきます。
必要な人員は開発者だけではありません。別々のプロジェクトでも、業務の説明や成果の確認に同じ倉庫責任者が必要な場合があります。その人が新拠点の開設準備を担当していれば、同時に進めて双方が遅れることもあります。予算とあわせて、現場担当者、承認者、導入後に引き継ぐ人が確保できる時間も見込みます。
点数で比べる場合は、評価項目と採点の理由を明確にします。同点でも、片方がデータの準備を待っていたり、両方で同じ担当者が必要だったりすれば、着手順は変わります。点数を議論の材料にして、最終的には意思決定者が影響、リスク、実行条件を踏まえて判断します。
3. 先に済ませるべき作業を踏まえて順序を決める
提案を比べたら、どの作業が終われば次に進めるのかを確認します。例えば、複数拠点の在庫を集計するには、商品コードと販売可能な在庫数の定義をそろえる必要があります。拠点ごとに記録のルールが違ったままでは、同じ画面に表示しても数字の信頼性は上がりません。
一つの進め方として、どのデータを在庫の基準にするかと商品コードを確認し、一拠点で記録方法を改善してから、複数拠点の情報を集計します。各段階で、コードが確定したか、利用者が同じルールで更新しているか、レポートが照合済みのデータと一致するかを確認します。実際の順序は、自社の業務に合わせて調整します。
販売履歴に抜けがあったり、商品コードが統一されていなかったりする段階では、AIによる需要予測の試行を広げるには早いかもしれません。ロードマップに実施時期を入れる前に、今のデータが予測の目的に合うか確認します。「AI活用の前に整えておきたいデータ」では、モデルに投資する前に確認したいデータの準備について解説しています。
前のプロジェクトがすべて終わるまで待つ必要のない作業もあります。範囲と人員に無理がなければ、ある部門が商品コードを統一する間に、別のチームがシステム連携の方法を調べることはできます。並行して準備できる作業と、前提が整ってから利用を始める作業を分けておくと、不要な待ち時間や作業の重なりを減らせます。
技術面の不明点によって方針が大きく変わるなら、本格開発を承認する前に何を確かめるか決めます。例えば、現在の在庫管理システムから、許可された権限でデータを取得できるかを調べます。「PoCとMVP、まず何を確かめる？」では、機能を作り込む前に、知りたいことに合わせて検証範囲を決める方法を紹介しています。
事業上の都合で順序を変えることもあります。全体の仕組みが整う前に新拠点を開設するなら、開設時に使える最低限の機能と、暫定的な在庫照合の方法を決めます。二つの運用が予定より長く残らないよう、暫定対応の責任者と終了条件も決めておきます。
4. すぐに着手することと見直しの条件を決める
直近の作業は、承認した範囲、責任者、確保できる人員や予算、成果の確認方法まで具体化します。先の施策は、改善の方向と着手条件を示すだけでよい場合があります。ロードマップへの記載と、プロジェクトの実施承認は区別して管理します。
この例では、まず一拠点で在庫の記録方法を調べ、修正ルールを決めます。全社向けのレポートは、データが十分に信頼でき、確認を担当する人が確保できた段階で着手します。AIの試行は、データと業務上の必要性を確認した後に再検討します。これで各部門は、今どの作業が進んでいて、ほかの作業がなぜ待ちになっているかを把握できます。
人員と予算を配分するときは、稼働中のシステムを維持する作業も見込みます。社内チーム全員が新規プロジェクトに入った場合、障害対応や更新、利用者へのサポートは誰が担うのでしょうか。障害が起きてから計画中の作業を中断しなくても済むよう、運用に必要な時間を最初から確保します。
試行結果が出たとき、データについて新たに分かったことがあるとき、事業計画が変わったときには、ロードマップを見直します。情報を取りまとめる担当と、着手順を変える権限を持つ人を決めておきます。提案を保留にする場合は、理由と再検討に必要なことを記録し、関係部門へ共有します。日付だけが変わると、現場は以前の計画がそのまま実施されると思い続けるかもしれません。
実施済みの施策の結果も、次の見直しに反映します。在庫表示機能が稼働しているのに、担当者が今も倉庫に電話しているなら、展開を広げる前に理由を確認しましょう。「導入したシステムの効果をどう確かめる？」では、納品後に現場の仕事がどう変わったかを確認する方法を紹介しています。
Fenixにご相談いただく際は、検討中の提案、現場で困っていること、人員・予算・時期の制約をお聞かせください。導入する技術や長期の投資計画を固める前に、解決すべき課題、確認しておきたい条件、取り組む順番を一緒に整理します。
