ソリューション
基幹システムの刷新・運用保守から業務部門のシステム化まで、部門ごとの課題とFormulaの解き方をご覧いただけます。
モダナイゼーションAI
仕様書のない現行システムを、読める状態に戻してから刷新する
よくある課題
仕様書が残っておらず、現行システムの中身を誰も説明できない——動いてはいるが、なぜ動いているのか答えられない
有識者の退職が近づき、ブラックボックスのまま塩漬けになっている——設計書はあっても実装と食い違い、確認の拠り所にならない
刷新をSIerに頼むと、現行調査だけで期間も費用もかさむ見積になる
移行先を検討しようにも、現行で何が動いているか分からず要件を固められない
Formulaの解き方
COBOLをはじめとする現行システムのソースコード、JCL、テーブル定義、帳票をそのまま読み込む
画面・API・ルールがIDでつながった読める仕様書に復元する
仕様書から動くアプリケーションを立ち上げ、関係者が同じ画面を見て確認・議論できる
設計書はExcel形式でダウンロードでき、慣れた形式のまま社内レビューに回せる
仕様書を土台に、刷新の範囲と順序を判断できる状態をつくる
導入後の姿
いま現行の中身を知る手がかりは、有識者の記憶と古い設計書の断片だけ
導入後画面・API・ルールがIDでつながった仕様書を、誰でも辿れる
いま「まず現行調査から」で刷新の議論が止まる
導入後仕様書から生成した動くアプリケーションを前に、何を残し何を変えるかを議論できる
いま影響調査のたびにベンダーへ依頼し、回答を待つ
導入後依存関係を仕様書の関係から自社で確認できる
進め方
資産のお預かり——ソースコード・JCL・テーブル定義・帳票を秘密保持契約のもとで受け入れる
仕様書への復元——読める仕様書に起こす。有識者は書かずにレビューに集中する
動くアプリで突き合わせ——仕様書から生成した画面を、業務部門・IT部門・経営層が同じ目線で確認する
刷新計画へ——何を残し何を変えるか、範囲と順序を判断して次の段階に進む
手元に残る成果物
運用保守AI
ベテランの記憶に頼っていた保守調査を、経緯まで辿れる自社資産に置き換える
よくある課題
障害時の勘所・過去の経緯・「なぜこの設定か」はベテランの記憶にしかない——退職や異動で、戻らない形で消えていく
マニュアルも手順書もある。しかし本当に要る情報ほど文書になく、探すより人に聞くほうが早い——だから資料は更新されず、さらに古くなる
開発も保守もベンダー任せが続き、社員の仕事は管理業務が中心に——AIでコードを読み解ける時代が来たのに、コードに触れる経路も読み解ける人も社内に残っていない
開発ベンダーと保守ベンダーが別々で、システムの知識が契約の切れ目で分断されている
品質は多重チェックと有識者の張り付きで保っている——「いま問題が起きていない」ことが投資判断を鈍らせ、人が減った瞬間に成立しなくなる
Formulaの解き方
ソースコード・JCL・設計書・運用資料を読み込み、読める仕様書=自社のテキスト資産に復元する
「どこで使われているか」だけでなく、「なぜ」という変更の経緯、「そもそも」という業務要件まで、関係を辿って答える
回答は根拠となる仕様書とコードにひも付き、監査や引き継ぎにも使える
日々の調査や変更の判断が関係として蓄積し、使うほど資産が育つ——そのまま刷新の土台になる
仕様書は特定のAIモデルに依存しないテキストで残る——モデルが世代交代しても、業務の知識は自社の手元に残り続ける
答えられる3つの問い
どこ
この項目はどこで使われているか
構造の関係|画面・API・ルール・テーブル
なぜ
なぜこの仕様にしたのか
経緯の関係|仕様・変更の履歴・そのときの判断
そもそも
そもそも何の業務要件のためにあるのか
起点の関係|仕様・業務要件
会話も変更も運用判断もIDを持ち——すべて関係としてデータ化され参照できる
導入後の姿
いま影響調査は「あの人に聞く」から始まり、不在なら止まる
導入後使用箇所・影響範囲を仕様書の関係から誰でも辿れる
いま「なぜこの設定か」の経緯がどこにも記録されず、人とともに消えていく
導入後変更の経緯と当時の判断が関係として残り、遡って確認できる
いま品質は多重チェックと有識者の張り付きが支えている
導入後調査と判断の履歴が組織に蓄積し、人の増減に左右されにくくなる
進め方
資産の収集——ソースコード・設計書・運用資料を集める
仕様書への復元——ベテランは書かずにレビューのみ
答えるAIの構築——使用箇所・影響範囲・経緯まで答える
資産が育つ——回答実績と運用判断が関係として蓄積される
手元に残る成果物
業務システム内製AI
業務部門からの要求に、内製のスピードで応える
よくある課題
業務部門からのシステム化要求が積み上がり、順番待ちが年単位
外注すると小さな案件でも数百万円・数ヶ月かかる
全社にAIチャットは配った——しかし使い道は要約とメールの下書き止まりで、業務プロセスは何も変わっていない
ノーコード・ローコードを試したが、基幹データに触れる本格的な業務には届かない
内製化を掲げたものの、作れる人が足りない
Formulaの解き方
業務資料とヒアリングから、要件定義書と動く画面を短期間で生成する
実際の画面を見ながら業務部門と合意し、手戻りを防ぐ
合意した内容がそのまま仕様書になり、あとから「なぜこの仕様か」を辿れる
権限・監査ログを備えた基盤の上で動くため、IT部門の統制のもとで内製が回る——統制の外で野良ツールを増やさない
そのまま構築へ進み、仕様書と検証記録が資産として残る
導入後の姿
いま要求は起案してから順番待ちで年単位
導入後小さな業務システムにも内製という選択肢を持てる
いま待ちきれない現場が、統制の外で野良ExcelマクロやSaaSを増やす
導入後公式の基盤の上で作るから、統制と速さが両立する
いま外注したシステムの仕様は、納品書類の中にしかない
導入後仕様書が資産として残り、次の変更はそこから始められる
進め方
要求の受け入れ——業務資料と短いヒアリングで要件の種を集める
動く画面で合意——業務部門と同じ画面を見ながら要件を確かめる
統制下で本番へ——権限・監査ログの効く環境で稼働させる
変更は仕様書から——業務が変わったら仕様書を直して作り直す
手元に残る成果物
販売・需給計画AI
需給の判断こそ競争優位——パッケージの型には収めない
02 需給ギャップ調整

よくある課題
既製のパッケージは、自社の強みである需給判断の勘所ほど合わない
足りない部分をExcelで補ううちに、シナリオ比較が属人化している
判断の根拠がベテランの頭の中にあり、記録にも引き継ぎにも残らない
業務に合わせるカスタマイズは高額で、バージョンアップのたびに載せ替えが要る
Formulaの解き方
自社の業務資料と現場の判断基準を、そのまま仕様書にする
パッケージに業務を合わせるのではなく、自社専用の業務システムとして生成する
判断材料を一つの画面に集約し、シナリオを並べて比較できるようにする
どの根拠で何を決めたかが記録に残り、判断が組織の資産になる
業務が変われば仕様書から作り直せる——競争優位を進化させ続けられる
導入後の姿
いま需給の判断はベテランの頭の中——本人にしか再現できない
導入後判断材料が一つの画面に集まり、シナリオを並べて比較して選べる
いまなぜその判断をしたか、後から誰も説明できない
導入後根拠と選択の履歴が残り、振り返りと引き継ぎに使える
いまパッケージに合わせて業務を曲げ、足りない分はExcel
導入後自社の判断のやり方が、そのままシステムになっている
01 需給計画ボード

03 月次S&OPサマリ

購買・調達AI
調達の判断は原価と供給を左右する——既製の購買システムには載らない
02 見積比較・査定

よくある課題
購買パッケージは定型の申請・発注には強い——しかし価格・納期・品質を天秤にかける自社の判断はシステムの外のまま
相見積の比較も発注配分の調整も、担当者のExcelに閉じている
サプライヤーごとの経緯——なぜこの単価か、なぜこの配分か——が引き継がれない
市況や供給リスクが動いたとき、判断の根拠を集め直すところから始まる
Formulaの解き方
品目・サプライヤー・取引条件の管理簿と、現場の判断基準をそのまま読み込む
自社の調達ルールを仕様書にし、選定・配分の判断まで載せた自社専用システムを生成する
見積比較・発注配分の判断材料を一つの画面に集約する
なぜそのサプライヤーに発注したか——判断と根拠が記録として残る
調達方針が変われば仕様書から作り直せる——市況の変化に仕組みが追いつく
導入後の姿
いま相見積の評価軸が担当者ごとにばらばら
導入後自社の評価軸がシステムに載り、誰が担当しても同じ土俵で比較できる
いま単価と配分の経緯は前任者の記憶とメールの中
導入後判断の根拠が記録として残り、監査にも次の交渉にも使える
いまパッケージの外にある判断業務はExcelが受け皿
導入後判断の業務そのものが自社専用システムになっている
01 調達案件ボード

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

受発注管理AI
自社の商流どおりに受発注が回る仕組みを持つ
01 受注インボックス

よくある課題
受注・配車・生産確認が電話とFAXと手入力の突き合わせ
商流や取引条件が独特で、既製の受発注システムに載せると現場が回らない
調整の状況が担当者にしか見えず、不在時に止まる
先方品番の読み替え表も、特急を受ける条件も、ベテランの頭と個人のExcelにしかない
Formulaの解き方
受注の取り方や調整の押さえどころといった自社のやり方を、要件として書き起こす
受注から配送・生産の確認までを一つの画面で追える形にする
動く画面を見ながら業務部門と要件を精緻化し、現場に合うシステムにする
既存の基幹システムには手を入れず、データを参照でつなぐ構成も個別に設計できる
商流が変わっても仕様書から作り直せる——業務の変化にシステムが追いつく
導入後の姿
いま受注から生産確認まで、状況の把握は電話とFAXと手入力の突き合わせ
導入後受注から配送・生産確認まで通しで追える
いま調整の状況は担当者の頭とメモの中——不在なら止まる
導入後部門の誰もが同じ状況を見て動ける
いま現場の工夫が個人のExcelに閉じている
導入後運用のルールがシステムと仕様書に載り、引き継げる
02 受注照合——原本突合

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

生産進度・納期管理AI
納期の答え方は競争力——自社の工程に合った進度管理を持つ
01 生産進度ボード

よくある課題
生産・検査・出荷の進度が見えず、納期の問い合わせに即答できない
工程ごとに管理表が分かれ、全体をつなぐのは人手
生産管理パッケージでは、外注・検査・梱包・船積みといった自社の工程の実態までは対応しきれない
引当の優先順位も、特急の基準も、外注先ごとの納期の読みも——納期回答のルールは経験者の頭の中にしかない
Formulaの解き方
自社の工程と管理の実務を、現場の管理表ごと読み込んで要件にする
受注から船積みまでの進度を一元把握できるようにする
納期回答の裏付けになり、遅れの兆候も早くつかめる
工程や外注構成が変わっても、仕様書から作り直して追随できる
導入後の姿
いま納期の問い合わせは、工程ごとの管理表をかき集めてから回答
導入後進度の裏付けを持ってその場で答えられる
いま全体をつないでいるのは人手の転記と定例会議
導入後受注から船積みまでを一元把握できる
いま遅れの兆候は経験者の勘だけが頼り
導入後兆候を同じ画面で全員が早くつかめる
02 納期回答ワークベンチ

03 外注進捗・納入管理

出荷・輸出入AI
物流の細部にこそ自社らしさが出る——そのやり方ごとシステムにつくり込む
01 輸出出荷ダッシュボード

よくある課題
動静確認・書類・調整がExcelとメールに分散し、担当者しか分からない
可視化SaaSが教えてくれるのは船の位置まで——遅れた船に納期と取引条件を突き合わせて代替便を決める仕事は、人とExcelに残ったまま
長年使い込んだExcelマクロが限界を迎え、作った本人はもう社内にいない
遅延や書類の抜けに気づくのが遅れ、後追いの調整に追われる
Formulaの解き方
自社の運用ルール・帳票・管理簿を読み込み、要件に落とし込む
動静・書類・関係者のやりとりを、自社の業務に合わせた一つのシステムにまとめる
部門の全員が同じ状況を見て動けるようにする
航路や商流、規制の変化に、仕様書からの作り直しで追いつける
導入後の姿
いま動静・書類・調整がExcelとメールに分散し、全体は誰にも見えない
導入後一つのシステムで通して見え、抜けに早く気づける
いま業務が担当者ごとのやり方に閉じ、引き継ぎのたびに崩れる
導入後自社のルールとして共有され、引き継げる
いま長年のExcelマクロは作った本人しか直せない
導入後仕様書が残り、変更のたびにそこから作り直せる
02 出荷案件詳細

03 週次出荷計画ボード
