ソリューション

基幹システムの刷新・運用保守から業務部門のシステム化まで、部門ごとの課題とFormulaの解き方をご覧いただけます。

モダナイゼーションAI

仕様書のない現行システムを、読める状態に戻してから刷新する

よくある課題

仕様書が残っておらず、現行システムの中身を誰も説明できない——動いてはいるが、なぜ動いているのか答えられない

有識者の退職が近づき、ブラックボックスのまま塩漬けになっている——設計書はあっても実装と食い違い、確認の拠り所にならない

刷新をSIerに頼むと、現行調査だけで期間も費用もかさむ見積になる

移行先を検討しようにも、現行で何が動いているか分からず要件を固められない

Formulaの解き方

COBOLをはじめとする現行システムのソースコード、JCL、テーブル定義、帳票をそのまま読み込む

画面・API・ルールがIDでつながった読める仕様書に復元する

仕様書から動くアプリケーションを立ち上げ、関係者が同じ画面を見て確認・議論できる

設計書はExcel形式でダウンロードでき、慣れた形式のまま社内レビューに回せる

仕様書を土台に、刷新の範囲と順序を判断できる状態をつくる

導入後の姿

いま現行の中身を知る手がかりは、有識者の記憶と古い設計書の断片だけ

導入後画面・API・ルールがIDでつながった仕様書を、誰でも辿れる

いま「まず現行調査から」で刷新の議論が止まる

導入後仕様書から生成した動くアプリケーションを前に、何を残し何を変えるかを議論できる

いま影響調査のたびにベンダーへ依頼し、回答を待つ

導入後依存関係を仕様書の関係から自社で確認できる

進め方

資産のお預かり——ソースコード・JCL・テーブル定義・帳票を秘密保持契約のもとで受け入れる

仕様書への復元——読める仕様書に起こす。有識者は書かずにレビューに集中する

動くアプリで突き合わせ——仕様書から生成した画面を、業務部門・IT部門・経営層が同じ目線で確認する

刷新計画へ——何を残し何を変えるか、範囲と順序を判断して次の段階に進む

手元に残る成果物

仕様書画面・API・ルールがIDで相互参照
設計書Excel形式でダウンロード可
アプリケーション仕様書から生成されて動く
検証記録何をどう確認したかが残る

生成される成果物のサンプルを見る →

運用保守AI

ベテランの記憶に頼っていた保守調査を、経緯まで辿れる自社資産に置き換える

よくある課題

障害時の勘所・過去の経緯・「なぜこの設定か」はベテランの記憶にしかない——退職や異動で、戻らない形で消えていく

マニュアルも手順書もある。しかし本当に要る情報ほど文書になく、探すより人に聞くほうが早い——だから資料は更新されず、さらに古くなる

開発も保守もベンダー任せが続き、社員の仕事は管理業務が中心に——AIでコードを読み解ける時代が来たのに、コードに触れる経路も読み解ける人も社内に残っていない

開発ベンダーと保守ベンダーが別々で、システムの知識が契約の切れ目で分断されている

品質は多重チェックと有識者の張り付きで保っている——「いま問題が起きていない」ことが投資判断を鈍らせ、人が減った瞬間に成立しなくなる

Formulaの解き方

ソースコード・JCL・設計書・運用資料を読み込み、読める仕様書=自社のテキスト資産に復元する

「どこで使われているか」だけでなく、「なぜ」という変更の経緯、「そもそも」という業務要件まで、関係を辿って答える

回答は根拠となる仕様書とコードにひも付き、監査や引き継ぎにも使える

日々の調査や変更の判断が関係として蓄積し、使うほど資産が育つ——そのまま刷新の土台になる

仕様書は特定のAIモデルに依存しないテキストで残る——モデルが世代交代しても、業務の知識は自社の手元に残り続ける

答えられる3つの問い

どこ

この項目はどこで使われているか

構造の関係|画面・API・ルール・テーブル

なぜ

なぜこの仕様にしたのか

経緯の関係|仕様・変更の履歴・そのときの判断

そもそも

そもそも何の業務要件のためにあるのか

起点の関係|仕様・業務要件

根拠 そもそも 根拠 反映 根拠 運用 根拠 どこ 生成 SES-031 会話(発見セッション) 「回収遅延が再発している。与信の 確認を受注の前に挟めないか」 REQ-042 業務要件(WHY) 与信を確認してから受注を確定する Δ2020-14 変更票 与信条件を追加——根拠の会話つき UTT-388 会話(変更ヒアリング) 「長年の取引先まで一律に止まるのは 困る。例外の扱いを決めたい」 Δ2023-02 変更票 例外条件を整理——影響範囲の記録つき OPS-311 運用判断 障害時の暫定運用を決定——経緯が残る SES-142 会話(運用の相談) 「暫定のまま回す間のリスクをどう 抑えるか」の検討記録 RULE-107 仕様 受注確定の条件(業務ルール) SCR-021 受注登録画面 API-014 受注確定API TBL-009 受注テーブル order_rules.py 実装コード TEST-201 検証記録 DOC-115 設計書(Excel) MAN-032 操作マニュアル

会話も変更も運用判断もIDを持ち——すべて関係としてデータ化され参照できる

導入後の姿

いま影響調査は「あの人に聞く」から始まり、不在なら止まる

導入後使用箇所・影響範囲を仕様書の関係から誰でも辿れる

いま「なぜこの設定か」の経緯がどこにも記録されず、人とともに消えていく

導入後変更の経緯と当時の判断が関係として残り、遡って確認できる

いま品質は多重チェックと有識者の張り付きが支えている

導入後調査と判断の履歴が組織に蓄積し、人の増減に左右されにくくなる

進め方

資産の収集——ソースコード・設計書・運用資料を集める

仕様書への復元——ベテランは書かずにレビューのみ

答えるAIの構築——使用箇所・影響範囲・経緯まで答える

資産が育つ——回答実績と運用判断が関係として蓄積される

手元に残る成果物

仕様書IDで相互参照される自社のテキスト資産
経緯の記録どこ・なぜ・そもそもを辿れる関係
設計書Excel形式でダウンロード可
証跡回答の根拠と監査ログが残る

生成される成果物のサンプルを見る →

業務システム内製AI

業務部門からの要求に、内製のスピードで応える

よくある課題

業務部門からのシステム化要求が積み上がり、順番待ちが年単位

外注すると小さな案件でも数百万円・数ヶ月かかる

全社にAIチャットは配った——しかし使い道は要約とメールの下書き止まりで、業務プロセスは何も変わっていない

ノーコード・ローコードを試したが、基幹データに触れる本格的な業務には届かない

内製化を掲げたものの、作れる人が足りない

Formulaの解き方

業務資料とヒアリングから、要件定義書と動く画面を短期間で生成する

実際の画面を見ながら業務部門と合意し、手戻りを防ぐ

合意した内容がそのまま仕様書になり、あとから「なぜこの仕様か」を辿れる

権限・監査ログを備えた基盤の上で動くため、IT部門の統制のもとで内製が回る——統制の外で野良ツールを増やさない

そのまま構築へ進み、仕様書と検証記録が資産として残る

権限・監査ログ——IT部門の統制の内側 生成 合意して稼働 資産化 次の要求へ 業務部門の要求(会話) 「引当の状況を毎朝ひと目で見たい」 動く画面 実際の画面で要件を確かめ合意する 統制下で本番稼働 権限・監査ログの効く環境で動く 仕様書が資産に 次の要求も変更もここから始まる SPEC 仕様書 回るほど積み上がる

導入後の姿

いま要求は起案してから順番待ちで年単位

導入後小さな業務システムにも内製という選択肢を持てる

いま待ちきれない現場が、統制の外で野良ExcelマクロやSaaSを増やす

導入後公式の基盤の上で作るから、統制と速さが両立する

いま外注したシステムの仕様は、納品書類の中にしかない

導入後仕様書が資産として残り、次の変更はそこから始められる

進め方

要求の受け入れ——業務資料と短いヒアリングで要件の種を集める

動く画面で合意——業務部門と同じ画面を見ながら要件を確かめる

統制下で本番へ——権限・監査ログの効く環境で稼働させる

変更は仕様書から——業務が変わったら仕様書を直して作り直す

手元に残る成果物

アプリケーション実際の業務で使える動く画面
仕様書画面・API・ルールがIDで相互参照
設計書Excel形式でダウンロード可
検証記録何をどう確認したかが残る

生成される成果物のサンプルを見る →

販売・需給計画AI

需給の判断こそ競争優位——パッケージの型には収めない

02 需給ギャップ調整

需給ギャップ調整の画面。3つの対応案を在庫推移チャートと自社ルールの適合状況で比較し、採用案の判断根拠と承認ステップが記録されている

よくある課題

既製のパッケージは、自社の強みである需給判断の勘所ほど合わない

足りない部分をExcelで補ううちに、シナリオ比較が属人化している

判断の根拠がベテランの頭の中にあり、記録にも引き継ぎにも残らない

業務に合わせるカスタマイズは高額で、バージョンアップのたびに載せ替えが要る

Formulaの解き方

自社の業務資料と現場の判断基準を、そのまま仕様書にする

パッケージに業務を合わせるのではなく、自社専用の業務システムとして生成する

判断材料を一つの画面に集約し、シナリオを並べて比較できるようにする

どの根拠で何を決めたかが記録に残り、判断が組織の資産になる

業務が変われば仕様書から作り直せる——競争優位を進化させ続けられる

導入後の姿

いま需給の判断はベテランの頭の中——本人にしか再現できない

導入後判断材料が一つの画面に集まり、シナリオを並べて比較して選べる

いまなぜその判断をしたか、後から誰も説明できない

導入後根拠と選択の履歴が残り、振り返りと引き継ぎに使える

いまパッケージに合わせて業務を曲げ、足りない分はExcel

導入後自社の判断のやり方が、そのままシステムになっている

01 需給計画ボード

需給計画ボードの画面。品目×週のPSIグリッドに欠品リスクと過剰在庫がハイライトされ、KPIタイルと在庫スパークラインが並ぶ

03 月次S&OPサマリ

月次S&OPサマリの画面。計画対実績と在庫金額推移、判断待ち議題、前月の決定事項のその後が一覧になっている

購買・調達AI

調達の判断は原価と供給を左右する——既製の購買システムには載らない

02 見積比較・査定

見積比較・査定の画面。4社の見積を品目単位で横並びにし、自社コストテーブル基準との乖離がハイライトされている

よくある課題

購買パッケージは定型の申請・発注には強い——しかし価格・納期・品質を天秤にかける自社の判断はシステムの外のまま

相見積の比較も発注配分の調整も、担当者のExcelに閉じている

サプライヤーごとの経緯——なぜこの単価か、なぜこの配分か——が引き継がれない

市況や供給リスクが動いたとき、判断の根拠を集め直すところから始まる

Formulaの解き方

品目・サプライヤー・取引条件の管理簿と、現場の判断基準をそのまま読み込む

自社の調達ルールを仕様書にし、選定・配分の判断まで載せた自社専用システムを生成する

見積比較・発注配分の判断材料を一つの画面に集約する

なぜそのサプライヤーに発注したか——判断と根拠が記録として残る

調達方針が変われば仕様書から作り直せる——市況の変化に仕組みが追いつく

導入後の姿

いま相見積の評価軸が担当者ごとにばらばら

導入後自社の評価軸がシステムに載り、誰が担当しても同じ土俵で比較できる

いま単価と配分の経緯は前任者の記憶とメールの中

導入後判断の根拠が記録として残り、監査にも次の交渉にも使える

いまパッケージの外にある判断業務はExcelが受け皿

導入後判断の業務そのものが自社専用システムになっている

01 調達案件ボード

調達案件ボードの画面。進行中の見積案件が査定期限・回答状況・決裁状態つきで一覧されている

03 発注配分シミュレーション

発注配分シミュレーションの画面。購買規程の制約のもとで配分シナリオを比較し、選定理由の記録と決裁への送付までが一つになっている

受発注管理AI

自社の商流どおりに受発注が回る仕組みを持つ

01 受注インボックス

受注インボックスの画面。FAX・メールPDF・Web-EDI・電話メモの注文を一望し、自動確定と要確認が照合結果つきで仕分けられている

よくある課題

受注・配車・生産確認が電話とFAXと手入力の突き合わせ

商流や取引条件が独特で、既製の受発注システムに載せると現場が回らない

調整の状況が担当者にしか見えず、不在時に止まる

先方品番の読み替え表も、特急を受ける条件も、ベテランの頭と個人のExcelにしかない

Formulaの解き方

受注の取り方や調整の押さえどころといった自社のやり方を、要件として書き起こす

受注から配送・生産の確認までを一つの画面で追える形にする

動く画面を見ながら業務部門と要件を精緻化し、現場に合うシステムにする

既存の基幹システムには手を入れず、データを参照でつなぐ構成も個別に設計できる

商流が変わっても仕様書から作り直せる——業務の変化にシステムが追いつく

導入後の姿

いま受注から生産確認まで、状況の把握は電話とFAXと手入力の突き合わせ

導入後受注から配送・生産確認まで通しで追える

いま調整の状況は担当者の頭とメモの中——不在なら止まる

導入後部門の誰もが同じ状況を見て動ける

いま現場の工夫が個人のExcelに閉じている

導入後運用のルールがシステムと仕様書に載り、引き継げる

02 受注照合——原本突合

受注照合の画面。FAX原本と抽出データを突き合わせ、適用した受注ルールと判断ログが並ぶ

03 納期回答・出荷指示ボード

納期回答・出荷指示ボードの画面。在庫・仕掛・発注残からの引当と便別の出荷指示、回答待ちキューが一画面に収まっている

生産進度・納期管理AI

納期の答え方は競争力——自社の工程に合った進度管理を持つ

01 生産進度ボード

生産進度ボードの画面。製番×工程のマトリクスに遅延リスクと外注先がハイライトされている

よくある課題

生産・検査・出荷の進度が見えず、納期の問い合わせに即答できない

工程ごとに管理表が分かれ、全体をつなぐのは人手

生産管理パッケージでは、外注・検査・梱包・船積みといった自社の工程の実態までは対応しきれない

引当の優先順位も、特急の基準も、外注先ごとの納期の読みも——納期回答のルールは経験者の頭の中にしかない

Formulaの解き方

自社の工程と管理の実務を、現場の管理表ごと読み込んで要件にする

受注から船積みまでの進度を一元把握できるようにする

納期回答の裏付けになり、遅れの兆候も早くつかめる

工程や外注構成が変わっても、仕様書から作り直して追随できる

導入後の姿

いま納期の問い合わせは、工程ごとの管理表をかき集めてから回答

導入後進度の裏付けを持ってその場で答えられる

いま全体をつないでいるのは人手の転記と定例会議

導入後受注から船積みまでを一元把握できる

いま遅れの兆候は経験者の勘だけが頼り

導入後兆候を同じ画面で全員が早くつかめる

02 納期回答ワークベンチ

納期回答ワークベンチの画面。どの工程が納期を決めているかと前倒し案の影響を確認しながら、根拠つきの回答を組み立てる

03 外注進捗・納入管理

外注進捗・納入管理の画面。外注先ごとの発注残と納入予定・実績の差分が横断で見える

出荷・輸出入AI

物流の細部にこそ自社らしさが出る——そのやり方ごとシステムにつくり込む

01 輸出出荷ダッシュボード

輸出出荷ダッシュボードの画面。動静遅延・書類期限・未ブッキングの例外案件が浮かび上がる

よくある課題

動静確認・書類・調整がExcelとメールに分散し、担当者しか分からない

可視化SaaSが教えてくれるのは船の位置まで——遅れた船に納期と取引条件を突き合わせて代替便を決める仕事は、人とExcelに残ったまま

長年使い込んだExcelマクロが限界を迎え、作った本人はもう社内にいない

遅延や書類の抜けに気づくのが遅れ、後追いの調整に追われる

Formulaの解き方

自社の運用ルール・帳票・管理簿を読み込み、要件に落とし込む

動静・書類・関係者のやりとりを、自社の業務に合わせた一つのシステムにまとめる

部門の全員が同じ状況を見て動けるようにする

航路や商流、規制の変化に、仕様書からの作り直しで追いつける

導入後の姿

いま動静・書類・調整がExcelとメールに分散し、全体は誰にも見えない

導入後一つのシステムで通して見え、抜けに早く気づける

いま業務が担当者ごとのやり方に閉じ、引き継ぎのたびに崩れる

導入後自社のルールとして共有され、引き継げる

いま長年のExcelマクロは作った本人しか直せない

導入後仕様書が残り、変更のたびにそこから作り直せる

02 出荷案件詳細

出荷案件詳細の画面。輸送マイルストーンと書類状況・取引条件を突き合わせ、代替本船への振替判断が経緯として残る

03 週次出荷計画ボード

週次出荷計画ボードの画面。4週間のブッキングと書類準備の状況を俯瞰し、締めに間に合わない案件を前倒しで手当てする

自社の業務でどう使えるか
資料でご確認ください