担当者の記憶に頼るDX推進から、チームで進める業務改革へ

DX推進担当者は、全社の業務をよりよくするために、現場の課題を見つけ、関係者をつなぎ、システムや業務の変革を前に進める役割を担います。一方で、日々の仕事では、資料探し、会議後の整理、既存システムの調査、企画書の初稿作成などに多くの時間を使うことがあります。

さらに、過去の判断理由や運用上の注意点が担当者の記憶に残ったままだと、異動や担当変更のたびに同じ調査が繰り返されます。本記事では、情報システム部門、DX推進部門、経営企画部門、AI活用推進室の担当者を対象に、定型作業をチームの知識へ変え、業務改革に集中するためのJitera活用方法を紹介します。

DX推進担当者の1日と、繰り返し発生する定型作業

DX推進担当者の一日は、問い合わせや進行中の案件の確認から始まり、関係者との打ち合わせ、業務調査、資料作成、PoCの確認、進捗整理へと続きます。緊急の障害やセキュリティ確認が入ると、予定していた企画や検証が後ろ倒しになることもあります。

朝：問い合わせと進捗の確認

• 前日のメール、チャット、申請、問い合わせを確認する
• 各部門から寄せられたシステム利用や業務改善の相談を分類する
• 進行中のプロジェクト、PoC、システム導入案件の進捗を確認する
• 経営会議や部門会議に向けた報告事項を整理する
• 障害、権限、セキュリティ、データ利用に関する緊急案件を確認する

午前：ヒアリングと要件整理

• 事業部門から業務上の課題や改善要望を聞く
• 現行業務、既存システム、利用データ、運用ルールを確認する
• 要望を機能要件、運用課題、教育課題、組織課題に分ける
• 開発会社やシステム担当者へ技術面の確認を依頼する
• セキュリティ、権限、データ管理、契約条件を関係部署へ確認する

昼前後：資料作成と社内調整

• 会議議事録を作成する
• 課題一覧、対応方針、担当者、期限を更新する
• 経営層向けの報告資料や稟議資料を作成する
• 複数案を比較し、費用、効果、リスク、導入期間を整理する
• 部門ごとに異なる要望や優先順位を調整する

午後：検証とプロジェクト推進

• PoCや新しいツールの検証結果を確認する
• 業務部門からのフィードバックを整理する
• 現行システムや既存資料を調査する
• 開発、移行、テスト、教育、運用開始までの計画を確認する
• 未解決の課題について、担当者や意思決定者へ確認を依頼する

夕方から夜：報告と翌日の準備

• その日の進捗、課題、判断待ち事項を整理する
• 関係者へ確認依頼や次のアクションを送る
• 会議資料、議事録、課題一覧、検証結果を所定の場所へ保存する
• 翌日の会議や経営報告に必要な情報を集める
• プロジェクトの遅延やリスクを見直す

繰り返し発生する定型作業

「変革を進める仕事」より「資料作成・調査・会議整理」に時間が奪われる構造

資料探しの負荷

過去の企画書、会議資料、議事録、システム構成図、運用手順、検証結果が複数の場所に分散していると、必要な情報を探すだけで時間がかかります。

特に、次のような情報は見つけにくくなりがちです。

• 過去に検討した導入案
• 採用されなかった理由
• 部門ごとの例外運用
• セキュリティ審査で確認された事項
• 過去のPoCで判明した制約
• 現行システムと業務の対応関係
• 経営層が重視する判断基準

資料を見つけても、版や適用範囲が分からなければ、そのまま利用することはできません。担当者は、資料の更新日、対象環境、作成者、確認者を確かめながら、複数の情報を突き合わせる必要があります。

会議後の整理の繰り返し

会議中は議論に参加し、会議後には議事録、課題一覧、担当者、期限、次回確認事項を整理します。複数の会議が続くと情報の更新が後回しになり、決定事項がチームへ共有されるまでに時間差が生じます。

会議で使った資料と議事録、課題管理表が別々に管理されている場合、後から経緯を確認することも難しくなります。何が決まり、何が未決定なのかが分からないまま、同じ確認が繰り返されることもあります。

属人化した判断と検討経緯

DX推進では、正式な資料だけでは判断できない情報が多くあります。

• なぜ現在の導入方針を採用したのか
• 過去に別案を見送った理由は何か
• 特定の業務を担当する部門や担当者は誰か
• 部門固有の例外運用は何か
• セキュリティ審査で注意すべき項目は何か
• PoCを本番展開へ進める条件は何か
• 過去の障害や導入失敗から得られた教訓は何か

これらが担当者の記憶や個人のメールに残っていると、異動や退職の際に知識が失われやすくなります。後任者は、コード、資料、議事録、問い合わせ履歴、口頭説明を組み合わせて、検討経緯を再構築しなければなりません。

チームで共有できていない情報

次の情報が担当者ごとに管理されていると、チームでの判断が難しくなります。

• プロジェクトの背景と目的
• 誰がどの判断をしたか
• 判断の根拠となった資料
• 現時点で未確定の事項
• 部門ごとの要望と優先順位
• PoCの検証結果と残課題
• システムの制約やデータ利用条件
• 過去の問い合わせと回答
• 会議で決まったことと、まだ決まっていないこと
• 導入後の運用ルールと問い合わせ先

情報が共有されていない状態では、同じ調査を複数人が繰り返したり、以前の検討結果を知らずに同じ議論をやり直したりします。DX推進担当者が変革に時間を使うには、資料や判断をチームで参照できる形に整えることが重要です。

Jiteraで変わる6つのDX推進業務

Jiteraは、許可された社内資料、業務ルール、既存システムの情報、過去の判断、プロジェクト記録などをコンテキストとして整理し、情報調査や資料作成の初稿づくりを支援します。出力は担当者が確認・編集するための草案として扱います。

1. 会議情報の整理

会議メモ、議事録、チャットの要点、過去資料をもとに、次の内容を整理します。

• 決定事項
• 未決事項
• 課題
• 担当者
• 期限
• 関係部署
• 追加確認事項
• 判断の根拠
• 次回会議までのアクション

会議終了後の整理を一定の形式で行うことで、決定事項と確認待ち事項を共有しやすくなります。正式な議事録や課題管理表へ反映する前に、参加者が内容を確認します。

2. 業務改善テーマの整理

事業部門から寄せられた相談や要望を、次の観点で分類します。

• 業務上の課題
• 現行システムの制約
• 手作業の多い工程
• データ活用の可能性
• システム改修が必要な事項
• 運用変更で解決できる事項
• 教育やルール整備が必要な事項
• 優先度と緊急度
• 効果測定の方法

課題を機能追加だけでなく、運用、教育、組織、データの観点でも整理することで、改善テーマの選択肢を広げられます。

3. 企画書・稟議書の初稿作成

業務課題、検討背景、目的、対象範囲、導入案、費用、効果、リスク、スケジュールなどを整理し、企画書や稟議書の初稿を作成します。

過去の類似資料や社内の書式を参照しながら、案件固有の情報と組織共通の前提を分けて整理できます。経営方針、予算、実現可能性、関係部署の合意状況は、担当者と責任者が確認して仕上げます。

4. 既存システムの調査

許可されたソースコード、DB定義、設計書、連携仕様、運用手順書などをもとに、次の内容を整理します。

• システムの目的
• 主な機能
• データの流れ
• 画面、API、バッチの関係
• 外部システムとの連携
• 改修時の影響範囲
• 設計書と実装の差異
• 担当者が確認すべき事項

製造業のMES・基幹DBでは、テーブル、画面、API、バッチ、外部システムの関係整理や、改修前の影響調査を支援できます。金融機関のレガシーシステムでは、ソースコード、DB定義、ジョブ定義、運用資料をもとに、処理フローや依存関係の草案を作成できます。

5. PoCの計画と評価

PoCの目的、対象業務、検証範囲、評価項目、必要なデータ、関係者、スケジュール、結果、残課題を整理します。

PoC終了後は、次の観点で結果をまとめます。

• 当初の課題を解決できたか
• 作業時間はどのように変化したか
• 出力内容の修正回数はどうだったか
• 現行業務へ組み込めるか
• セキュリティや権限面の課題はないか
• 本番展開に必要な追加作業は何か
• 継続、見直し、終了の判断材料は何か

検証結果は、定量的な指標だけでなく、利用者の確認負荷、出力の根拠の追跡しやすさ、業務への適合性も含めて評価します。

6. 社内ナレッジの共有

過去の資料、議事録、検証結果、運用ルール、問い合わせ履歴などをコンテキストとして整理し、チーム内で参照できる状態を作ります。

AIが回答できない社内固有の判断や暗黙知については、担当者が確認・回答した内容をAIの参照情報として蓄積し、以降の類似した質問にも活用できるようにする仕組みを使い、適切な担当者へ確認する運用も検討できます。回答された内容は、確認者と確認日を記録したうえで、次回以降の参照情報として整理します。

自動的に整理された情報と、担当者が確認した情報を分けて記録することで、どこまで検証済みなのかを把握しやすくなります。

業務ごとの入力コンテキストと生成されるアウトプットの例

入力するコンテキストには、対象業務、対象システム、環境、版、更新日、機密区分、参照してよい範囲を付けます。現行版と旧版を区別し、個人情報、認証情報、契約上の機密情報などは社内規程に従って扱います。

登録資料にない事実は推測で補わず、「要確認」として分けて出力させます。出力された内容には、可能な範囲で根拠となる資料や参照箇所を添え、担当者が確認しやすい形にします。

AIの出力を担当者・関係者・経営層がレビューする運用

DX推進業務へAIを組み込むときは、AIに任せる作業と、人が判断する作業を分けます。AIには、情報の整理、初稿作成、比較、分類、確認事項の抽出を任せます。人は、要件の確定、導入方針、予算、リスク、セキュリティ、業務への適合性、実行可否を判断します。

担当者による一次確認

• 入力した資料の版、対象環境、参照範囲が正しいか確認する
• 出力内容が入力資料の記載と一致しているか確認する
• 推測や根拠のない補完が含まれていないか確認する
• 未確認事項と確認担当者を整理する
• 課題、担当者、期限、判断待ち事項を更新する

関係者による業務・技術レビュー

• 業務担当者が業務ルール、例外条件、現場での実行可能性を確認する
• 情報システム担当者がシステム構成、連携、権限、運用への影響を確認する
• セキュリティ担当者がデータ管理、アクセス権限、外部連携、監査要件を確認する
• 開発会社や保守担当者が技術的な実現可能性と影響範囲を確認する

経営層による意思決定

経営層へ報告する資料では、目的、期待効果、費用、リスク、実施期間、判断が必要な事項を簡潔に整理します。経営層は、AIが作成した文章の見た目ではなく、事実の根拠、未確認事項、実行条件、責任者を確認したうえで意思決定します。

AIの出力を最終判断としないことが重要です。文章や表が整っていても、内容の正確性、網羅性、実現可能性を保証するものではありません。企画書、稟議書、システム調査、PoC評価、予算、セキュリティ、導入可否に関わる情報は、担当者、関係者、責任者が参照元と照合し、必要なレビュー、テスト、承認を行ってください。

製造業・金融・SIerとの組み合わせ展開例

製造業：現場の課題とシステムの構造をつなぐ

製造業では、製造、品質、調達、設備保全、営業、管理などの部門ごとに業務や判断基準が異なります。DX推進担当者は、現場の課題を聞き取り、MES、生産管理、品質管理、在庫管理、販売管理などのシステムとの関係を整理します。

記事では、次のテーマと組み合わせると具体性が出ます。

• 製造現場へのAI展開
• 工場ごとの運用差異の整理
• MESと基幹DBの依存関係の可視化
• 改修前の影響調査
• ベテラン担当者の知識継承
• 小さな業務から始めるPoCと全社展開

製造現場へAIを展開する場合は、ツールを配布するだけでなく、現場ごとの業務課題、参照資料、確認者、成果物、保存先まで運用として設計します。

金融：レガシーシステムと厳格な確認プロセスを両立する

金融機関では、長年稼働しているプログラム、DB、SQLバッチ、ジョブ定義、運用手順が業務を支えています。DX推進担当者や情報システム部門は、業務、開発、運用、セキュリティの各部門をつなぎながら、調査や改善の優先順位を決めます。

記事では、次のテーマと組み合わせると展開しやすくなります。

• レガシーシステムのブラックボックス解消
• 改修時の影響範囲調査
• 古い設計書と現行コードの差異確認
• ベテラン社員の退職に備えた知識継承
• バッチ処理と外部連携の整理
• セキュリティ審査に向けたデータ境界の確認
• 業務単位で範囲を区切る段階的な検証

機密性の高い資料を扱うため、配置場所、通信経路、権限、ログ、保存期間、参照範囲を事前に確認します。移行、改修、リリース、業務判断は、AIの整理結果だけで確定しません。

SIer：案件ごとの経験を組織の開発資産へ変える

SIerでは、要件定義書、設計書、ソースコード、テスト仕様書、運用手順書、チケット、障害記録などが案件ごとに蓄積されます。DX推進担当者は、過去案件の経験を整理し、類似案件の提案、要件整理、設計、レビュー、引き継ぎへつなげます。

案件固有の情報と、組織で再利用できる標準知識を分けて管理すると、顧客情報を適切に扱いながら、チームの知識を育てやすくなります。過去の判断理由、レビュー観点、障害時の注意点を再利用することで、同じ調査や確認の繰り返しを減らせます。

まとめ

DX推進担当者の仕事は、資料を作ることや会議を調整することだけではありません。現場の課題を見つけ、情報を整理し、関係者の認識をそろえ、意思決定と業務改革を前に進めることが本来の役割です。

Jiteraは、許可されたコンテキストをもとに、会議情報の整理、業務改善テーマの整理、企画書・稟議書の初稿作成、既存システムの調査、PoCの計画と評価、社内ナレッジの共有を支援します。担当者の記憶や判断を置き換えるのではなく、情報整理と定型的な資料作成の負荷を軽くし、チームで確認・更新できる状態を作ることが目的です。

まずは、対象範囲と出力形式を定めやすい業務から始めます。会議後の課題整理、特定業務の現状調査、PoCの評価項目作成、問い合わせ回答の整理など、小さな業務で入力、出力、確認者、保存先を定義します。AIが整理した内容と、人が確認した内容を分け、確認者、確認日、参照資料、未解決事項を記録することで、担当者の記憶に依存しない業務資産へ育てていけます。