こんにちは。皆さま、いかがお過ごしでしょうか？

“室長”こと吉島良平（Microsoft MVP for Business Applications|Microsoft Regional Director）です。

3月決算の皆さま、本当にお疲れ様でした！

達成感や課題、反省、安堵。いろいろな思いが、入り混じる1日だと思います。

私どもの会社は、6月締めなのですが、3月締めのお客様も多いので、私自身も強い区切りを感じています。

1年間（2025年4月1日‐2026年3月31日）、DX365Lifeをご覧いただき本当にありがとうございました。

本稿を含め合計60本のblogを公開させていただきました。2本はoasis live、Bryan Adams liveだったので、お仕事に関わる内容は58本です。ただ、この2つのblogへのアクセス数はとんでもなくて、異常値でした。一番読まれたのがこの2つであった事は、内緒ですが🤣、そういうきっかけであったとしても、マイクロソフトのビジネスアプリケーション群を知ってもらえる機会になっていれば本当に嬉しいです！（ 本音は、どっちでもいいんです。楽しんでいただけたら。それが、ここDX365Lifeの趣旨ですから。）

さて、この1年間のDX365Lifeでは、Dynamics 365を継続的に追いかけながら、CopilotやAIをDXの文脈でどう捉えるか、そしてAutomotive領域を中心に、実装の現場で何が起きているのかを見続けてきました。個別のテーマを切り分けるというよりも、それぞれがどこでつながり、どう影響し合っているのかが伝わる形を意識してきた1年だったと思います。

2025年4月から6月にかけては、Dynamics 365 2025 wave 1を起点に、プロダクト理解とイベント・コミュニティ活動に多くの時間を割きました。Business Centralのローンチイベントを皮切りに、Business Application Lunch Event、Directions Asia、Microsoft Buildなどを通じて、個々の機能だけではなくMicrosoftエコシステム全体の流れを把握することを意識していました。Directions Asiaでは4つのセッションを担当（1つはパネリストとして）し、Dynamics 365やCopilotに関するテーマを、登壇という形で整理し直す機会にもなっています。資料を作り、人に説明する過程そのものが、自分の理解を見直す時間になっていました。

この時期は、CopilotやAIに対して感じた率直な驚きや期待を、そのまま言葉にして残しており、「何をAIに任せるべきなのか？」「業務の中で何から変えていくべきなのか？」という問いを自分なりに考え始めたタイミングでもあります。単なる新機能紹介に留めず、背景や前提を整理することを意識するようになったのも、この頃からです。

6月以降、夏にかけてはAutomotive領域を明確なテーマとして扱うようになりました。オートモーティブ業界向けセミナー（日本マイクロソフト31階セミナールーム）、オートサービスショーに加え、Technosoft Automotive Days 2025では、トヨタ、日産、GMといった複数のOEMによる実際の取り組みを35カ国からの参加者へ共有しました。Dynamics 365（CRM/ERP）、Power Platform、DMS（ディーラーマネージメントシステム）、Copilotがどのように業務や組織に組み込まれているのか、グローバル展開や業務標準化の中で、どんな課題があるのかといった、現場に即した論点に触れる機会が多かった時期です。「DXの現在地と未来地図」「生成AIと人間の役割分担」のようにAIとの関わりに悩み、言語化を始めた時期でもありました。

また、これらのイベントや会議を通じて、利用者やパートナーの立場から、Microsoftの製品開発チームに対してフィードバックを行う機会もありました。実際の業務やプロジェクトで感じた点を言語化し、製品側に伝えることで、「現場で何が起きているのか」を共有することも、この1年の取り組みの一部だったと考えています。

8月後半から9月にかけては、Dynamics 365 2025 release wave 2に関する記事が中心となりました。Release Planの読み解きから始まり、Business Central、Sales、Field Service、Customer Insights、Finance、SCM、Contact Center、Project Operations、Human Resources、Commerceまでを順に整理し、最後に総集編としてまとめています。並行して、「きままに勉強会」では、Dynamics 365 2025 release wave 2の内容を共有し、ブログとは異なる形でアウトプットする機会もありました。人に説明することを前提に整理することで、「どこが本質的な変化なのか？」「廃止・停止されていく機能は何か？」を改めて考える時間になっています。

その後のMicrosoft AI Tour Osaka、Microsoft Ignite、Best of Microsoft Recap DaysといったMicrosoft公式イベントでは、CopilotやAIを機能単位で追うのではなく、企業運営やプロジェクトの進め方にどのような影響を与えるのか、という観点で整理してきました。Technosoft Automotive Days 2025で見たトヨタ、日産、GMの事例や「Japan Mobility Show 2025」と照らし合わせながら、AIがどの業務に入り込み始めているのか。人の役割は、どう変わりつつあるのかを考える材料として、イベントの内容を言語化しました。「年末のご挨拶記事」と「年始のご挨拶記事」は、出来事を並べる総括というよりも、この1年で人々の関心がどこに移り、世の中は今後どう変化していくのかについて、自分なりに整理したものです。

2026年に入ってからは、比較や構造化を意識したテーマが増えていきます。「Business CentralとFinance & Operationsの比較」、「Automotive World」や「IAAE（国際オートアフターマーケット）」といった現場系イベントのレポートを挟みつつ、「AIは考える存在から働く存在へ」「制度変更に強いDX、弱いDX」「ERP/CRM UIの終焉｜役割変更」といった切り口で、DXの持続性や強度そのものについて考える記事を書いてきました。個別の事例を追うだけでなく、その背後にある前提や産業構造の変化を言語化することを、より意識するようになった時期です。

3月はDynamics 365 2026 release wave 1にフォーカスし、Deprecations、Business Central、SCM、Finance、Project Operations、Commerce、Human Resources、Sales、Customer Service、Contact Center、Field Service、Customer Insightsまでを一気通貫で整理しました。あわせて、Microsoft MVP/RD Global Summit 2026にも参加し、プロダクトやAIに関するグローバルな議論や視点に触れる機会がありました。これらの内容は、新機能紹介というよりも、「Dynamics 365やCopilotがどこに向かおうとしているのか」を考える材料として整理しています。

また、Microsoft AI Tour Tokyoやモーターサイクルショー2026といったイベントを通じて、AI、DX、業界という三つの要素が、もはや切り分けて語れるものではなくなっていることを改めて感じました。イベントレポートという形式ではありますが、参加した事実を記すのではなく、構造や文脈を整理することを一貫して意識しています。

ビジネスアプリケーション領域のAIに関する知識を習得していく中で、Microsoft Azureの進化の方向性にも変化を感じました。それは、「AIアプリケーションを前提としたクラウド設計」への明確な舵切りです。Azure AI Foundry (旧称Azure AI Studio)を中心に「モデル選定」「Fine-Tuning」「RAG構成」「マルチエージェント連携」「運用・監視」までを１つの開発ライフサイクルとして扱える環境が整備されました。

同様に、IDE・リポジトリ・開発環境が、「AIが参加して働く開発プロセスの舞台」へ変化していることを体感しました。「Copilotがマルチステップ作業を完走する方向性を示したVisualStudio」「CopilotをIssueを割り当てられる実行主体として位置付けたGitHub」「AI支援を外部ツールに接続し拡張可能にする土台を運用段階へ進めたVSCodeとMCP（ModelContextProtocol）」「AI開発の前提条件を整える環境になってきたCodespacesとDevBox」これらは全てAIを中心に考えた開発を行うための製品の進化なのです。

こうして振り返ると、この1年間は、Dynamics 365のrelease waveを継続的に追い、CopilotやAIを業務や組織の文脈で捉え直し、Automotive領域を中心に実装の現場と照らし合わせながら整理する、という取り組みを繰り返してきた期間でした。ブログ、登壇、勉強会、イベント参加やフィードバックとアウトプットの形は異なっていても、考えているテーマは一貫しており、結果として、それらが一つのDXの流れとして読み返せる形になっているのであれば、それがこの1年の取り組みの一つの到達点だと考えています。

Blogを書くこと自体が仕事というわけではないので、業務が終わった深夜から朝にかけて、あるいは週末や祝日に書く、という1年でした。

企業のグループCOOとしての立場と、Microsoft MVP/RDとしての活動を両立する中で、「本当に自分でいいのだろうか」と自問することも少なくありませんでした。正直、体力的に厳しいと感じる場面もありました。それでも振り返ってみると、この1年で手に入れたものは少なくなかったと思います。

ここまでが、DX365Lifeとしてこの1年間に取り組んできた内容の整理です。

プロダクト、イベント、業界、AI―それぞれを切り分けて追いかけてきたように見えるかもしれませんが、振り返ってみると、私自身は一貫して「現場で何が起きているのか」「人の役割はどう変わりつつあるのか」という一点を見続けてきたように思います。

そして、FY25の最後として、今回はいつもとは少し違う形で、この1年を締めくくることにしました。

ここから先は、記録ではなく、物語です。

機能や製品、イベントを整理するのではなく、ある現場の記憶を、そのまま言葉に残すという形です。

描いたのは、2010年10月から2026年3月までの15年半にわたる一つの現場の物語です。本稿に登場する組織や人物、出来事は、複数の現場や時代背景をもとに再構成し、室長が描いた架空のストーリーです。皆さんが、これまで関わってきたプロジェクトと照らし合わせながら見ていただけると嬉しいです。それでは、お楽しみください♪

【ある製造業の物語】

舞台は2010年。まだオンプレミスが当たり前で、業務やデータを一気に統合することこそが正解だと信じられていた時代の話です。当時としては合理的だと考え、開発元が異なるCRMとERPを同時に刷新する判断を選びました。最新の技術を選び、海外子会社（10拠点）にも展開を見据え、正しい判断をしたつもりでした。しかし、その先に待っていたのは、想像以上に長く、重い時間でした。なぜ、あの時うまくいかなかったのか。何が足りず、何を見誤っていたのか。

そして今、クラウドとローコード、CopilotやAIが当たり前になったこの時代に、私たちは本当に「自由」になれたのか。過去を懐かしむためでも、失敗を美化するためでもありません。今のDXやAIを語るためには、どうしても通らなければならない記憶が、そこにあると感じています。成功談でも、教訓集でもありません。技術が進化しても、なお残り続ける課題と、人が引き受けてきたものを、そのまま書き留めた架空の記録です。少し長い話になりますが、FY25の最後に、是非お付き合いください。

【稼働2週間前、静かな合意】

2010年10月中旬。第1工場から運ばれてくる切削油の匂いが、会議室の隅にまで薄く滲んでいた。

窓を閉めても消えない匂いだ。

私たちの会社は、世界10カ国に拠点を構える、質実剛健を絵に描いたような工作機械メーカーだ。

工場では24時間、巨大な旋盤が火花を散らし、熟練工たちがミクロン単位の精度を競い合っている。

機械が動く限り、会社は動く。その単純な真理だけが、私たちを支えていた。

プロジェクトは半年遅延し、予算は当初の1.5倍を使い果たしていた。

CFOの村上が会議室に足を踏み入れるたび、全員の背筋が同じ角度で固まり、胃の奥が冷たく縮んだ。

CIOの宇野は「これ以上、1円も、1日も猶予はない。」と言った。叱責ではなく、宣告だった。

ホワイトボードには、赤いペンで「GoLive」だけが残っている。

誰かが消そうとして、やめた跡が残っている。

だが、誰も「大丈夫です。」と言わない。言ってはいけないと、全員がどこかで理解しているのかもしれない。

「部分的に延期して、段階導入にできないのか？」

若手が口にした瞬間、空気が固まった。

当時の私たちにとって、段階導入は逃げだった。

やり切ることが正義で、同時刷新が整合性で、ビッグバンこそが筋の通った正解だと信じていた。

「今さら分けることはできない。」

誰かがそう言った。反論は出ない。反論できないのは、論理の問題ではなく、覚悟の問題だった。

結局、議事録にはこう残った。

「稼働日（2010年11月2日）は、もう変更しない。ビッグバン。懸念事項は運用で吸収する。」

その一文の軽さに、私の胃だけが重く沈んだ。

サーバー室の空気は、物理サーバーが吐き出す焦げ付いたような熱風で澱んでいた。

【ビッグバンの断末魔】

2010年10月31日（日）。本稼働予定日の前日。

CRMとERPの間でのマスタ・伝票の連携テストが行われていた。

昨日から、並行して開始残高投入もはじまっていた。

徐々に時間がなくなり、情報システム部門、システム構築ベンダーにも焦りが見え始めた。

窓のないサーバー室を支配していたのは、達成感など微塵もない極限の虚無だった。

ファンの唸りが、まるで低い獣の呼吸のように続いている。

冷却の風は冷たいのに、機械の熱だけが床から上がってくる。

今回の導入は、本社とこの第一工場。

世界展開の旗印になるはずの「グローバル標準モデル」の第一歩になるはずだった…

「……だから言ったんだ。CRMとERPを同時に入れ替えるって判断は、正しかったのか？」

「……しかも開発元が異なるCRMとERPを…」

福本（営業責任者）の声は、怒鳴り声というより、骨の奥から漏れた悲鳴だった。

「三上さんのマーケティングデータも、山田さんが必死に集めた商談メモも、未だCRMに取り込まれていないようだが。」

福本が言い切る前に、経理財務部門長の森が返す。目が血走っている。声が乾いている。

「福本さん、こっちだって経理の開始残高データが100万単位でズレてるんだ。

原因がどこにあるかも分からない。」

三上（マーケティング部門/課長）と山田（営業部門/課長）も不安な顔でこっちを見ている。

そこへ、鈴木社長が入ってきた。靴音が重い。工場の床を歩く足取りと同じだ。

社長はモニターを一瞥し、上野（IT部門長）にだけ視線を置く。

「上野さん、本当に動くのか？」

上野は立ち上がった。椅子が擦れる音がやけに大きい。震える声で答える。

「……走らせます。泥を被ってでも、ゴールまで押し込みます。」

その瞬間、プロジェクトマネージャーである桐生（私）は思った。

走らせるのは、システムではない。私たち自身だ、と。

【120万の幽霊と、島名さんの掌】

21時。プロジェクトルームとして使っていたサーバー室の静寂を破るのは、ファンの唸りと、紙が擦れる音だけだった。

経理部門の佐藤は、山積みの経費伝票と、海外子会社からFAXで届くバラバラの報告書の山に埋もれる自席と、

サーバー室を往復する日々だった。

机の端に、冷えた缶コーヒーが置かれたままだ。

佐藤が呟く。

「……120万ほど金額が合わない。」

ERP側には、多くのカスタマイズが実装されていた。以前の仕組みの多くを取り込んだからだ。

修理の年単位の保守契約から生成される前受金や、修理を委託する先への前払金など、

システム用の開始残高の作成、取り込みオペレーションは簡単ではなかった。

システムの変更に合わせ、在庫も棚卸評価計算を標準原価に変更した。その影響もあるのかもしれなかった。

CRMとERPの伝票連携も難易度が高く、時間が徐々になくなっていく。

情報システム部門の上野、溝道、そして桐生（私）たちが、「現場の呼吸に合わせ過ぎた。」その善意が、血流を止めた。

「ERPの開発を導入ベンダーに任せ過ぎた。」結果がこれだ。

そのとき、重い防音ドアが音もなく開いた。外から入り込んできたのは、家庭の匂いだった。

炊きたての米と、醤油の香ばしさ。機械の熱と金属の匂いの中に、あり得ないほど柔らかい匂い。

「……はい、そこまでよ。佐藤さん、少し背中、貸して。」

総務の島名だった。

湯気の立つ急須と、握りたての大きなおにぎり。

冷え切った鉄の檻に、不釣り合いな温度が持ち込まれる。

島名は佐藤の隣に座り、小さく丸まった背中を、節くれだった掌で、ゆっくり、ゆっくりとさすり始めた。

「いいのよ。数字は逃げない。でも、あなたの心は、ここで折れたら逃げちゃう。

いったんハンドルを離して、温かいものを飲みなさい。

……鈴木さんたちも、どうぞ。冷え切った体じゃ、いい決断もできませんよ」

背後に立っていた鈴木社長、宇野CIO、村上CFO。冷徹な経営陣の前に、島名さんは迷いなく茶碗を置いた。

2010年の冬、私たちは彼女のこの掌の温かさに、辛うじて人間としての形を保たせてもらっていた。

CRMとERPのマスターは準備ができ、契約残の移行もなんとか完了した。

24時を回っていた。本番稼働当日だ。

【逃げ場のない夜｜選択が許されなかった時間】

―駅裏の赤提灯、苦いホッピーの誓い

サーバー室を追い出された上野、溝道、桐生（私）は、駅裏の場末の居酒屋にいた。今日は家には帰れない。

注文したのは、一番安いホッピーと、冷めきったモツ煮込み。

湿った空気とタバコの煙が、疲弊した体に重くのしかかる。

「……オンプレは、不自由だよな。物理的な距離に勝てない。」

上野が、ジョッキの結露を指でなぞりながら呟く。

「一度、この溶接跡を物理サーバーに焼き付けたら、OSのアップデートひとつで壊れる可能性がある。

俺たちは、一生この鉄の檻を、怯えながらメンテナンスし続けるしかない。」

最強の実装者である溝道も、この夜ばかりは力なく笑った。

「開発元が異なるCRMとERPが、お互いに殴り合いながら走ってる感じですか。

いつか、この二つの心臓を、一つの血流で繋げる日が来るんですかね？」

桐生（私）は上司の上野に聞いた。

「きっと、来るさ。10年後か、20年後か。ま、知らんけど。」

上野が空のジョッキをカウンターに叩きつけた。

「うちのITプロジェクトはいつもギリギリ。

人もいないのに、CRMとERPのインターフェース開発に、こんなに工数かけたくない。もっと他にやるべき事があるのにな。」

私たちは、暗い夜空を見上げ、苦いホッピーでその誓いを飲み干した。飲み干したのは酒ではない。責任だった。

【泥まみれのダイビングヘッド、そして終わらない延長戦】

2010年11月2日（月）午前9時。結局、私たちは一睡もせず、泥だらけのピッチに立った。

120万円の差額の理由は未だわかっていない。

稼働を優先し、後日金額の差異を調査、調整仕訳を入れる事で、経理部門とは合意した。

10時、本番稼働に関する直前のミーティングが行われ、本番稼働の承認が下りた。

午前中は各部門で、本番運用に関するミーティングが個別に行われた。

16時、現場は阿鼻叫喚に包まれる。

工場長の新井が「現場を殺す気か！」と叫び、物流部門の小野塚は、前システムから出力した伝票を片手に倉庫へ走った。

調査の結果、CRMと部品を販売しているウェブサイトから、ERP側に不可思議なデータが連携された事実が判明した。

上野（IT部門長）は各部署からの怒鳴り声を、全身で受け止め、盾になった。

シンガポールからもドイツからも、深夜にも関わらず「システムパフォーマンスが悪い。」という悲鳴が届く。

実はCRMはグローバル共通の仕組みだった。

現地に赴任する日本人のマネージメントから、日本の経営陣にも報告があがっていただろう。

それでも、システムは動いた。終了間際、泥だらけのピッチで放った決死のダイビングヘッド。

ボールは泥を巻き込みながら、辛うじてゴールラインを割った。私たちは「勝った」ことにされた。

だが、悲劇はその成功という名の呪いから始まった。

稼働後の2年間、私たちは一度も攻めのITを語れなかった。

毎日のように噴出する不具合という名の毒が、時間を、精神を、そして会社の未来を奪い続けた。

「….また、レスポンスが落ちてる….」

CPUの使用率が100％に張り付くたび、私たちは深夜のデータセンターへ走る。

インデックス再構築、肥大化したログ削除、OSのパッチ。

パッチを当てるたびに、どこかに潜む魔改造コードが悲鳴を上げて連鎖的に止まる。

「アップデートが怖い。」それが、当時の共通言語だった。

競合がデジタルを武器に市場へ打って出る中、私たちは鉄の檻の中に閉じこもり、

錆びついた歯車に油を差すだけの保守の番人に成り下がっていた。

IT予算の9割が、ただ現状維持のために消えていく。

三上が望んだ新しいマーケティングのITツール刷新も、福本が求めた営業向けモバイル対応の改善依頼も、

CIOの「今の安定が優先だ。余計なことをするな！」の一言で、検討のテーブルにすら、のらなかった。

島名は、やつれていくプロジェクトメンバーの顔を見るたびに、何も言わずに温かいお茶をだしていた。

その沈黙が、いちばん痛かった。この泥濘が、15年もの間、私たちの足元を掴んで離さない。

その呪縛を解くための、本当の戦いが始まるのは、まだずっと先の話だ。

【言葉にならない夜｜違和感だけが残った5年後】

2015年10月。本稼働から、5年が経とうとしていた。その日は、何かを祝う日ではなかった。

残業を切り上げ、誰かが「今日はもういいだろ。」と言い、誰かが「じゃあ一杯だけ。」と応じた。

気がつくと、6人でエレベーターに乗っていた。仕事終わりに、そのまま流れてきただけの懇親会だった。

店は、駅裏の赤提灯ではない。かといって、洒落た店でもない。

オフィス街の外れにある、少しだけ小綺麗な居酒屋だ。

平日の夜で、周囲の客も似たような顔をしている。

テーブルには6人。桐生（私）、上司の上野、開発の溝道。

アプリ担当の深沢、データ管理の黒田、インターフェース担当の立花。

最初は、完全に仕事の延長だった。

最近の障害。海外拠点からの問い合わせ。

「またあれか。」という愚痴。

だが、深沢がぽつりと言った。

「……もう5年ですよね。」

誰もすぐに返事をしなかった。

「……結局、あの『120万』、どうなったんだっけ？」

少し贅沢に注文したエビスビールのグラスを傾けながら、上野がぽつりと溢した。

隣には、5年前よりも少し白髪の増えた溝道。

「……あれは結局、3年がかりの調査でも原因が特定できず、訂正仕訳として処理されましたよ。

そもそも元々のシステムから抽出した会計データに問題があったとかで…」

黒田が苦笑いしながら答えると、仲間たちが、力なく笑う。

5年経っても、私たちの足元はまだ泥濘（ぬかるみ）の中だった。5年という数字は、節目ではなく、重さだった。

「新しいこと、ほとんどやってない…」

深沢は、言い訳をするようでも、責めるようでもなく続けた。

「正確には、何かやろうとしても、止めざるを得ない理由が多すぎる。アプリ側も同じ…」

黒田が、小さく頷く。

「データも同じです。“正しいかどうか”より、“前と同じかどうか”が優先される。

ズレてると分かってても、触れない…」

立花は、少し間を置いてから言った。

「インターフェースは……

最初は橋だったんですけどね。今は、応急処置を重ねた足場みたいになってます。」

溝道が、グラスを持ったまま苦く笑った。

「それでも、動いてる。止まらないようにだけ、みんなで支えてきた。」

誰も否定しない。動いている。会社も回っている。

それが、この5年間の全てだった。

上野が、静かに口を開いた。

「資料の上では、ずっと“成功”だ。止まってないし、赤字でもない。……でも、楽になった感じは、一度もないよな。」

その一言で、空気が固まった。

サーバーの保守期限（EOS）が迫るたび、私たちは「またあの地獄が来るのか。」と怯え、

多額の予算を投じて延命措置を繰り返していた。

IT予算のほとんどは、錆びついた鉄の檻のメンテナンスに消えていく。

誰もが同じことを思っていた。

上野が、串カツのソースに手を伸ばしながら言った。

「……最近、クラウドっていうのが流行り始めてるらしいじゃないか。海外のベンダー、もうオンプレ前提で話してこない。

サーバーを持たない。アップデートは向こうが勝手にやる。

……そんな夢みたいな話、俺たちの『鉄の熱量』がぶつかり合う現場に、本当に馴染むのかね？」

「無理ですよ。うちの複雑な原価計算や、10カ国のバラバラな商習慣を、標準（Standard）で動かせるはずがない。」

深沢が断言した。

溝道は、即答しなかった。少し考えてから、正直に言った。

「正直、怖い。このシステムが、どれだけ歪んでるか、俺たちが一番知ってる。」

黒田が、低い声で続ける。

「標準に戻すって、過去5年分の判断を、全部引き受け直すことですよね。」

その言葉に、誰も返せなかった。

引き受ける覚悟も、否定する理由も、まだ持っていなかった。

溝道は、話し出した。

「でもね、島名さんが、前に言ってたんです。『いつか、みんなが背負ってる重い鉄の箱を下ろせる日が来るわよ』って。

彼女、不思議な予見がある人でしたから。」

深夜のサーバー室。急須と、おにぎり。佐藤の背中に置かれた、あの掌。

「……島名さん。」私が名前を呟くと、6人全員が黙った。

「あの人が、いなかったら。」

立花が、ぽつりと言った。

「誰か、途中で壊れてたと思います。」

システムは動いている。会社も続いている。

だが、人が無理をしているかどうかを、見ようとする仕組みは、どこにもなかった。

その夜、結論は出なかった。次に何をするかも、誰がやるかも、決まらなかった。

乾杯もしなかった。誓いもなかった。

ただ、6人で静かに飲んだ。同じ場所に、同じ重さを抱えたままで。

それは計画ではない。合意ですらない。

この夜にあったのは、

「このままではいけない。」と全員が思っているという事実だけだった。

その時、居酒屋のテレビから流れてきたニュースが、私たちの目を釘付けにした。

「……海外10カ国を展開する中堅機械メーカー。クラウド移行により、グローバルでの在庫可視化に成功。」

「……先を越されたか。」

上野は、空になったグラスをカウンターに叩きつけた。

店を出ると、夜は冷たかった。

空気は、2010年より少しだけ軽い。

だが、進む道は、まだ見えていなかった。

【2020年｜同じテーブルに座り、同じ前提を探した夜】

2020年12月。年末の打ち上げを兼ねた社内パーティーは、例年より少しだけ簡素だった。

形式的な挨拶が終わり、会場がざわつき始めた頃、自然と一角に人が集まった。

社長の鈴木。CIOの宇野、CFOの村上。

営業部門長の福本、マーケティング課長の三上、営業課長の山田。

工場長の新井、物流の小野塚、製造の田中、修理の高橋。

経理財務部長の森、経理課長の佐藤、佐藤の部下の宮下。

そして、IT部門からは、桐生（私）、上野、溝道、深沢、黒田、立花。

誰かが音頭を取ったわけではない。

ただ、立場も部門も違う人間が、同じテーブルを囲んでいた。

最初に口を開いたのは、工場長の新井だった。

「最近、システムが止まらないのは、本当に助かっている。

ただ……現場を良くしている実感があるかと言われると、正直、ない。」

営業部門長の福本が続ける。

「営業も同じだ。数字は見える。管理もできている。

でも、動きやすくはなっていない。」

マーケティングの三上は、少し間を置いて言った。

「データはあります。顧客も、商談も、問い合わせも。

でも、試そうとすると、必ず誰かに負荷がかかる。」

物流の小野塚が頷く。

「変えると、どこに影響が出るか分からない。

だから、変えない。それが一番安全なんです。」

経理財務部長の森が、グラスを置いて言った。

「経理は、数字を合わせること自体はできている。

だが、なぜその数字になるのかを説明できる人が、退職して減った。」

佐藤が静かに補足する。

「“システムがそうなっている”その一言で済ませる場面が、増えました。」

宮下は黙って聞いていた。

彼女にとって、Excelでつなぐ作業は、最初から「仕事」だった。

修理部門の高橋が言う。

「直したいところは、山ほどある。でも、どこまで触っていいのか分からない。」

製造の田中も続けた。

「現場判断を減らすための仕組みだったはずなのに、結局、現場が一番気を遣っている。」

誰も反論しなかった。責め合う空気はなかった。

ただ、同じ違和感が、違う言葉で並んでいった。

しばらくして、営業部門長の福本がぽつりと言った。

「最近さ、“AIを使えば何とかなる”って話、外ではよく聞くんだ。」

笑いは起きなかった。

「でも、正直なところ、今の状態でAIって言われても、何を食わせればいいのか分からない。」

三上が頷く。

「データはある。でも、全部バラバラ。横断しようとすると、人がExcelでつないでいる。」

森が続ける。

「財務データも同じだ。意味をつなぐのは、結局人だ。」

工場長の新井が腕を組む。

「設備、品質、作業実績。全部あるが、同じ前提で語れない。AI以前の話だ。」

その流れを受けて、CIOの宇野が整理するように口を開いた。

「つまり……

AIが必要かどうかの前に、データを一つの場所で、同じ意味で扱えていない。」

誰も否定しなかった。

「しかも。」

宇野は続ける。

「皆さん、日常業務では、もうMicrosoftのOfficeを普通に使っている。メールも、資料も、会議も。」

社長の鈴木が静かに頷いた。

「別の世界の話ではない、ということだな。

4月から営業とマーケ主管役員と、副社長が外部から来てくれるから、次回は一緒に頑張ってもらおう。」

桐生（私）は、その流れを受けて言葉を選んだ。

「だから、次に何かを考えるなら、“AIを入れる”ではなく、

“業務とデータの前提を揃える”という話から始める必要があると思います。」

誰かが小さく言った。

「ワンプラットフォーム、か。」

「ええ。」

桐生は続ける。

「CRMとERPを別々に考えない。業務とシステムの間を、人が埋め続けない。

考え方はローコードで残し、基盤はクラウドに置く。」

ここで具体的な製品名が議題になることはなかった。

Dynamics 365（CRM/ERP）、Power Platform、Azure。

だが、それらは、“今使っている延長線にある話”として、全員が理解していた。

CFOの村上が、最後に言った。

「それなら、夢の話じゃない。今の延長で、現実として考えられる。」

その夜も、何も決まらなかった。

製品名も、予算も、プロジェクト名も出なかった。

だが、「AIが空論にならない条件」「次のシステムが担うべき役割の輪郭」

それだけは、全員の中で揃った。

この時間は、結論ではない。合意でもない。

ただ、後になって振り返れば、

2023年のあの静かな企画書が生まれるために、

どうしても必要だった“最初の対話”だったと感じる。

だが、その場にいた私たちに、その意味がすぐに分かっていたわけではなかった。

ここで改めて、2010年の判断を言語化しておく必要がある。

【あの頃に戻る｜“別々に最適化した”という過去】

2010年、私たちはCRMとERPを同時に刷新した。

選んだのは、当時国内で広く使われていた、開発元の異なる二つの業務システムだった。

当時としては、合理的な判断だったと思う。

CRMは営業とマーケティングを強くし、ERPは会計と製造を堅牢にする。

それぞれの領域で実績のある製品を選び、それぞれを最適化する。

「餅は餅屋」という考え方が、疑われることなく通用していた時代だ。

問題が起きたのは、製品の性能ではなかった。

CRMもERPも、それぞれの世界では、よく出来ていた。

だが二つの間に、業務やデータを「同じ前提」で扱うための設計思想は、最初から置かれていなかった。

顧客とは何か。

契約とはどこから始まり、どこで終わるのか。

売上とは、いつ確定し、誰が責任を持つのか。

それぞれのシステムは、自分の論理では正しかった。

だが、その正しさ同士が噛み合う場所は、誰の責任範囲にも、明確には存在しなかった。

結果として、その隙間を埋めたのは、人だった。

Excelでつなぎ、運用で吸収し、「今回は例外だから」と言い続けた。

別々に最適化されたシステムは、別々に進化し、別々に壊れ、別々に責任が曖昧になっていった。

私たちはようやく、それを「失敗」と呼べる距離まで来た。

失敗の本質は、どの製品を選んだかではない。

業務とデータの前提を分断したまま、それぞれを最適化しようとしたことだった。

だから2020年のあの夜、私たちは製品の名前を、あえて口にしなかった。

「どのCRMが良いか」

「どのERPが強いか」

そんな議論は、誰もしなかった。

先に揃えるべきものが、別にあると分かっていたからだ。

業務とデータの意味。責任の境界。引き受ける場所の線引き。

それらが揃わないまま製品を選べば、どんな選択も、再び「別々の最適化」になる。

後になって振り返れば、CRMとERPの連携を最初から前提とした設計を持つDynamics 365という選択肢、

そして私たちが日常業務でメールや資料、会議といったMicrosoftのオフィス製品を当たり前のように使い続けていたことは、

選定において決して小さな要素ではなかった。

それは、過去のCRMやERPの延長ではない。

業務とデータを一つの文脈で扱うための、現実的な前提条件だった。

今回私たちが選ぼうとしていたのは、特定の製品そのものではない。

「最初から、別々に最適化しない」という選び方だった。

その違いに気づくまでに、私たちは15年かかった。

そしてその時間は、決して無駄ではなかったと、今は思っている。

ただし、それは後になって、ようやく言葉にできた整理だった。

2020年のあの時点では、私たちはまだ、その整理にたどり着いていなかった。

【決めなかった、という選択】

2020年当時、私たちはそれを「選択」だとは呼んでいなかった。

あの対話のあと、何かがすぐに動き出したわけではなかった。

検討会も、構想書も、ロードマップも作られなかった。

「次はこうする」という宣言もなければ、「もう一度やろう」という声も上がらなかった。

それは、無関心だったからではない。むしろ逆だった。

誰もが、あの時の判断がどれだけ長く影響を残したかを知っていた。

だから、軽々しく次の言葉を置けなかった。

AIは話題になり続けた。

クラウドも、ローコードも、当たり前になっていった。

だが、それらを「目的」にしてしまった瞬間、同じ過ちを繰り返すことも、全員が分かっていた。

【二度目の企画書に、夢は書かれていなかった】

今振り返ると、あそこからの長い沈黙は、何も決めなかった時間ではなく、言葉を雑に扱わない為の時間だったのかもしれない。

2023年1月。最初の起案書は、驚くほど静かな文面だった。ページ数は少ない。

図も少ない。代わりに、余白が多い。15年前の起案書は違った。

「世界標準」「完全統合」「拡張性」正しい言葉を重ねることで、不安を押し込めていた。

今回の起案書の一行目には、こう書かれていた。「本プロジェクトは、最新技術の導入を目的としない。」

会議室でその一文が読まれた瞬間、何人かが視線を上げた。

違和感というより、拍子抜けに近い反応だった。

「じゃあ、何をやるんですか？」

若手が率直に聞く。上野は、少し間を置いて答えた。

「壊れない仕組みを作る。それと、壊れそうなときに、ちゃんと止まれる構造を作る」

クラウドも、ローコードも、AIも、前提として並んでいる。

だが、それらは“売り”としては一切強調されていなかった。

代わりに書かれていたのは、「このプロジェクトで“やらないこと”の一覧」だった。

・全業務の一括刷新はしない

・例外処理をコードで吸収しない

・現場判断をシステムに丸投げしない

誰かが小さく息を吐いた。15年前、これが一つでも書かれていただろうか。

【責任者の欄に、個人名を書くという決断】

起案書の後半に、少し異質なページがあった。

「最終判断責任者」その欄には、役職ではなく、個人名が記されている。

しかも一人だけではない。工程ごとに、複数の名前が並んでいた。

「これ、必要ですか？」誰かが聞いた。

AIが提案し、ログが残り、判断プロセスが可視化される時代だ。

理屈だけなら、不要に見える。だが上野は、はっきりと言った。

「必要だ。15年前、俺たちは“システムがそうなった”と言い続けた。今回は、その言い訳を最初から封じる。」

場が静まる。便利になった分、責任の所在は曖昧になりがちだ。

だからこそ、あえて人の名前を書く。

電子承認が回り始めると、一つひとつの承認に、以前よりも時間がかかった。

迷っているのではない。引き受けているのだ。

【実施判断｜正解が揃っている会議ほど、決断は遅れる】

実施可否を決める会議は、淡々と進んだ。リスクは洗い出され、回避策もある。

AIが生成したサマリーは分かりやすく、論点は整理されている。

反対意見は出なかった。同時に、賛成の声も上がらなかった。

「失敗しないですよね？」

誰かが確認するように言った。上野は、首を縦にも横にも振らない。

「失敗はしない。でも、楽でもない。」

その言葉で、全員が理解した。これは“成功させるプロジェクト”ではない。“逃げないためのプロジェクト”だ。

「やりましょう。ただし、」

上野が続ける。

「途中で止める判断を、成功と呼べるようにしよう！」

それは開始宣言ではなく、撤退を含んだ実施判断だった。

【キックオフ｜空いている一席が、全員に同じことを思い出させる】

キックオフ当日。会議室は明るく、設備も整っている。

だが、席が一つ空いていた。誰も何も言わない。

それでも全員が、その空席の意味を知っていた。

15年前、深夜のサーバー室で、数字より先に人を見ていた人。

その席は、島名のために空けられていた。

彼女は、このプロジェクトが始まる前に、静かにこの世を去っていた。

「今回のプロジェクトで、一番大事なことを言います。」

プロジェクトマネージャーを任された桐生（上野の直属の部下である私）は、こう続けた。

「完璧なシステムは作らない。代わりに、誰かが無理をし始めたとき、それを見逃さないプロジェクトにする。」

拍手は起きなかった。士気を煽る言葉もなかった。

だが、不思議と不安はなかった。

全員が、同じ方向を向いていると分かっていたからだ。

15年前とは違う。今回は、走り切ることよりも、“倒れないこと”を最初から目的にしている。

プロジェクトは、静かに動き始めた。

【コンセプトトレーニング｜同じ言葉で迷うために】

要件ヒアリングに入る前に、私たちは一度だけ立ち止まった。コンセプトトレーニング。

Dynamics365 (CRM/ERP)、Power Platform、Azureの原理原則を、参加者全員の頭の中で揃えるための時間だ。

要件定義を早く終わらせるためではない。

要件定義で迷ったときに、同じ地図を見て迷うための準備だった。

15年前なら、この時点でまず環境準備が地獄になる。

誰がどのサーバーに入れるか、どのバージョンで動かすか、手順書があるか。

会議の前に疲弊し、議論が始まる頃には、既に半分の集中力が削れている。

だが今回は違う。トレーニング環境も、CRP環境も、前提がクラウドだ。

必要なのはアクセス権だけで、同じ画面、同じデータ、同じ制約を全員が同時に触れる。

ここで詰まらない、という当たり前が、最初の安心になった。

立ち上げも、作り直しも、驚くほど軽い。だからこそ、逃げ道が減る。

環境が違うから議論が噛み合わない、という言い訳が成立しない。

楽になった分、残るのは純粋に、理解と判断だけになる。

研修の資料は、機能の羅列から始まらない。

最初に語られたのは、標準という言葉の意味だった。

標準は守るものではなく、運用で育てるもの。

ローコードは自由を与えるが、統制を自動では与えない。

クラウドはアップデート前提で、止まってくれない。AIは正解を出すが、責任を引き受けない。

こうした前提を知らないまま要件定義に入ると、議論は必ず、便利な裏道へ流れる。

そのとき誰かが、少し居心地悪そうに言った。

「つまり、要件定義って、機能を決める場じゃないんですね？」

誰も笑わない。笑えない。15年前の私たちは、機能を決めることで安心しようとした。

だがそれは、安心ではなく、後戻りできない溶接の始まりだった。

だから今回は、最初にこの言葉だけを共有した。

「迷ったら、交通ルール（この場合、プロジェクト計画書）に戻る。」

それは、標準に拘るための合言葉であり、過去の自分たちへの戒めだった。

【要件ヒアリング｜交通（運用）ルールが守られているという成長】

コンセプトトレーニングの次に来るのが、要件ヒアリングだ。

この順番自体が、もう一つの交通ルールになっている。最初から要件を固めない。

最初からFit & Gapに飛び込まない。まず現状を理解し、言葉を揃え、それから手を動かす。

ヒアリングの最初に私たちがやったのは、現状システムのドキュメント確認だった。

AS-ISの業務資料、画面と帳票の一覧、データの流れ、インターフェース、例外運用のメモ。

机の上に並べて、全員で黙って眺める。

ここで沈黙が落ちるかどうかで、プロジェクトの質が決まる。

黙れるということは、資料が語っているということだからだ。

前回、私たちはここで苦労した。AS-ISの業務資料がない、あるいは最新化されていないと、深掘りができない。

現状理解に時間がかかり、結局は後工程で吸収することになる。

その結果、要件定義やCRPが薄くなり、議論の主導権がIT側に寄っていく。そんな反省があった。

だからこそ、今回の資料を見たときに、私の呼吸が少しだけ楽になった。

更新日が新しい。版数が振られている。差分の履歴が残っている。

変更理由が短い一文で添えられている。誰かが作って放置した資料ではない。

誰かが運用しながら、交通ルールを守り続けてきた資料だった。

誰かがぽつりと言った。

「これ、ずっとメンテされてたんですね….」

その一言の重さを、私たちは知っている。

ドキュメントが最新であるということは、誰かが地味な作業を積み上げたということだ。

ルールは、守ろうとする人がいないと消える。

15年前は、消えてしまった。今回は、消えていない。ヒアリングは、聞き方も変えた。

「それはシステムで実現すべきですか、それとも運用で整えるべきですか？」

「その例外は顧客価値のためですか、それとも過去の傷を隠すためですか？」

「そのデータはどこで生まれて、どこで変形して、どこで消えていますか？」

資料が最新化されているから、曖昧な答えが通りにくい。人の記憶ではなく、図と履歴で会話ができる。

ここで初めて、標準に寄せるという話が精神論ではなく、現実になる。

オンラインで参加するメンバーもいる為、常にMicrosoft Teamsを利用する。録画もする。

Teamsでミーティングサマリー（簡易議事録）を残しておくことも非常に重要だ。

言った言わないの問題を根こそぎ排除したい。

そして、ヒアリングの最後に一つだけ確認した。

「この要件は、標準に当てにいく。それでも当たらないなら、当たらない理由を先に言語化する。」

それが、次のCRPで迷子にならないための、最後の交通標識だった。

【CRPを活用した要件定義｜標準の型に当てて、当たらない所だけを残す】

そしてCRPに入る。Conference Room Pilot。要件定義とCRPを一体化させるのは、単なる効率化ではない。

標準から議論を始めるための仕組みだ。CRPは、要件を作る場ではなく、要件を削る場になる。

CRPの終わりにマスターデータが50％程度取り込まれていたら、勝ちパターンだ。

ここでもクラウドの軽さが効く。環境はすぐに立ち上がり、すぐに作り直せる。壊しても戻せる。

だから遠慮なく触れる。15年前のように、壊すことが恐怖で、触ることが政治になる、という空気がない。

だがこの自由は、優しさではない。逃げ道が減る。触って確かめるしかなくなる。

CRPでは、ユーザー側もハンズオンで触る。ここが重要だ。ITだけが触ると、要件定義は成立しない。

CRPがIT主導になると、要件定義ができない。前回の反省が、全員の背中を押していた。

最初に起きたのは、期待どおりの失望だった。

「標準だと、うちの呼吸に合わない。」

「画面の順番が違う。」

「現場の判断が吸収されない。」

不満は正しい。だが、ここから先が15年前と違う。

誰かが言う。

「じゃあ、何を変えるべきですか？」

すぐに別の誰かが返す。

「システムを変えるのか、運用を変えるのか？」

この問いが出た瞬間、会議室の温度が少しだけ下がる。冷たくなったのではなく、澄んだのだ。

ここから先は、希望ではなく責任の領域になる。CRPでは、Fit & Gapが自然に浮かび上がる。

標準に業務を当てる。当たらない所だけが残る。残った所に対して、全員で理由を言語化する。

なぜ当たらないのか。それは業務の本質か。過去の癖か。法規制か。顧客体験か。単なる慣習か。

情報システムの部長、上野がいない（他のプロジェクトで海外出張中）ことに、最初は違和感があった。

ちょっと前まで、誰かが前に立って決めていたはずの場面で、今回は、誰も前に出なかった。

だから、決まらない。その代わり、決め方が残っていく。

私たちは、上野さんならどう判断したかを当てにするのではなく、判断の仕方そのものを、構造として残す必要があった。

CRPは続く。マスタの準備も並行して進む。要件定義は、紙の上ではなく、触れる現実の中で前へ進む。

そして、気づけば会議室で一番多く使われる言葉が変わっていた。

「できる」でも「できない」でもない。「やる」でも「やらない」でもない。

一番多いのは、これだった。

「それは標準に寄せたほうがいい。」

寄せる、という言葉は、逃げに聞こえることがある。だがこの現場では違う。

寄せるとは、交通ルールに戻ることだ。ルールを守って初めて、全員が同じ道路を走れる。誰かの裏道に依存しないで済む。

CRPの終盤、若手がふと漏らした。

「環境がこんなに軽いのに、判断は軽くならないんですね。」

誰も否定しなかった。否定できない。クラウドでデプロイが楽になった分、残るのは判断だけになる。

だから重い。だが重いということは、やっと本題に辿り着いたということでもある。

こうして、コンセプトトレーニング、要件ヒアリング、CRPを活用した要件定義が一気に繋がった。

手法の順番ではない。交通ルールを守るための順番だ。

そして、標準に寄せてなお残った当たらない部分だけが、次の章へ進む。

そこから先は、ローコードの誘惑と統制の衝突、AIが正解を出しすぎる瞬間、そして人間が責任を引き受ける場所の話になっていくのだ。

【要件定義の夜｜要求より対話を選んだ人たち】

要件定義が終わった夜は、拍手も達成感もなかった。

会議室のホワイトボードから付箋が剥がされ、椅子が机に戻され、誰もが「やっと終わった。」とは言わずに帰り支度をしていた。

終わったのは、作業ではない。

「増やしたい」という衝動を、いったん抑えたことが終わったのだ。

そのとき、林取締役が、いつもの穏やかな声で言った。

「今日は、軽く行こう。飲んで帰ろう。誰も今日の続きはしない。しないって決めよう。」

冗談みたいに聞こえるのに、誰も笑わない。

笑えないのではなく、助かるのだ。そう言われるだけで、肩の力が一段抜ける。

店は駅前の雑居ビルの二階。古いが清潔で、椅子が柔らかい。

熱い湯気の立つ鍋が出てきた。湯気の匂いに、会議室の乾いた空気が押し出される。

石塚副社長は、席につくなり周囲を一瞥して、箸を置いたまま言った。

「まず、顔色を見ていいか。今日はそれが目的だ。」

その言い方に、誰も否定できなかった。

技術の話をする前に、体調の話をする。

プロジェクトの空気が、そこで少しだけ変わった。

福本（営業部門長）が、乾杯のあとすぐに切り出した。

「いやぁ……正直、今回は我慢しましたよ。要件、まだ山ほどある。」

山田（営業課長）が、苦笑いで続ける。

「言い出したら止まらないと思って、途中から口を閉じてました。自分でも驚きました。」

三上（マーケティング課長）も頷いた。

「本音を言えば、顧客データの取り方も、スコアリングも、キャンペーンも……全部やりたい。

全部やれば売上につながるって、そう思ってしまう。」

その瞬間、場の空気が一瞬だけ戻りかけた。

要件定義とは、夢を並べる場所だ。

人は、夢を語ると安心する。

15年前の起案書がそうだったように。

だが、林取締役が、鍋の具をゆっくり掬いながら言った。

「今日はね、三人に言っておきたかったことがある。」

福本と三上と山田が、同時に顔を上げる。

林の声は柔らかいのに、線がある。

「要件を抑えたんじゃない。要件を減らしたんでもない。君たちがやったのは、“要求”を“対話”に変えたことだ。」

「対話？」

山田が小さく聞き返す。

林は頷いた。

「要件ってさ、書こうと思えばいくらでも書ける。でも、要件が増えるほど、後で誰かが折れる。

折れるのが現場なら、売上が落ちる。折れるのがITなら、未来が止まる。」

福本が、少しだけ目を細めた。

「……俺たちが要求を増やすと、未来が止まるって？」

林は笑わない。

「止まるよ。止まったのを見てきただろ。15年前に。」

その言葉が出た瞬間、誰も箸を動かさなくなった。

居酒屋の雑音だけが残る。

鍋の湯気だけが上がる。

林は続けた。

「要件定義の会議で、君たちが“これも必要”“それも必要”と言いかけた瞬間が、何度もあった。

そのたびに俺は、質問を一つだけ返した。」

福本が思い出したように言う。

「……“それは顧客価値ですか、それとも不安の穴埋めですか”ってやつか？」

林は頷いた。

「そう。要求が出るのは悪いことじゃない。

でも、要求の形で投げると、受け取る側は仕様に変換するしかなくなる。

そうすると、会話が“実装”に落ちて、責任が曖昧になる。」

三上が、静かに言った。

「だから、林さんは会議で、要求を言わせないようにしてたんですね。」

林は首を横に振る。

「言わせないんじゃない。

要求の奥にある“不安”を先に言わせたかった。

顧客が見えない不安。数字が合わない不安。現場が動かない不安。

それを言葉にしてからなら、要件は自然に減る。

減らしたんじゃなくて、残るべきものだけが残る。」

福本が、息を吐いた。

「俺は正直、怖かったんだ。今回は成功させたいって言いながら、また同じことをやるんじゃないかって。」

その横で、石塚副社長が、ようやく口を開いた。

声は低いが、硬くない。

「福本さん、怖いのは正常だ。怖くないほうが危ない。」

石塚は、箸で豆腐を割り、ゆっくり言った。

「要件定義が終わったあと、報告を受けた。

工数が、当初見積より二割増えた、と。」

上野（IT部門長）が一瞬だけ身構える。

桐生（私）も、胃の奥が条件反射で重くなる。

“二割増”は、15年前なら、怒号の合図だった。

だが、石塚は続けた。

「その二割は、贅沢じゃない。嘘をつかないための二割だ。

見ないふりをしないための二割だ。そして、人を潰さないための二割だ。」

誰も言葉を挟めなかった。

石塚は、淡々と事実だけを置くように言う。

「俺は社長に直談判した。予算を増やすべきだと。」

一瞬だけ、全員の目が揃う。

“社長に直談判”という言葉は、この会社では重い。

それは覚悟がないと出せない言葉だ。

「理由は二つだけ言った。一つは、ここで削ると、後で必ず倍になる。もう一つは、ここで削ると、誰かが折れる。」

石塚は、少しだけ目を細めた。

「社長は聞いたよ。“成功の確率は上がるのか”って。

俺はこう返した。

“確率じゃない。事故を減らす。嘘を減らす。人が倒れる可能性を減らす”って。」

その場で、桐生（私）は理解した。

これは予算交渉ではない。

プロジェクトの“交通ルール”を、経営の言葉に翻訳したのだ。

溝道（開発責任者）が、ぽつりと漏らした。

「……それ、めちゃくちゃ助かりました。

要件を削るか、人を削るか、どっちかになると思ってたんで。」

深沢（アプリ担当）も、苦笑いで頷く。

「工数が増えるって言うと、怒られるのが普通ですからね。

でも今回は、“増やした理由”がちゃんと残った。」

黒田（データ管理）が、いつもの淡い声で言った。

「言葉が残ると、怖くないですね。

怖いのは、黙って削られて、最後に爆発することなので。」

立花（インターフェース担当）が、グラスを置いた。

「……結局、あれなんですよね。

技術の話をしてるようで、人の話をしてる。」

その言葉に、林取締役が、静かに頷いた。

「そう。」

旧メンバーの誰もが、島名さんの掌を思い出す。

島名さんがサーバー室でやってたのも、同じことだ。

背中をさするか、言葉を整えるか。やり方が違うだけで、見てるものは同じだ。

湯気の匂い。おにぎりの温度。あの静かな強さ。

石塚が、最後に一言だけ置いた。

「要件定義が終わった。でも、本当の勝負は、これからだ。

だから、今日だけは“終わった顔”をしていい。

明日からまた、倒れないように走れ。」

その言葉は、檄ではなかった。

許可だった。

人が、人でいるための許可。

店を出ると、夜風が冷たかった。

だが、2010年の冷たさとは違う。

あの頃は、孤独だった。

今回は、見られている。

見られているというだけで、人は少しだけ正直になれる。

正直になれば、強さはあとからついてくる。

【開発フェーズ｜標準を壊さず、Microsoftの道具で速度と統制を両立する】

要件定義が終わった時点で、Fit & Gapの結果は、はっきりしていた。

GAPは帳票とインターフェースに集中し、9割を超えた。

標準に拘った結果、業務ロジックそのものはほとんど標準の道路の上に収まっている。

残りの1割。そこには、ユーザーからの強い要望があった。

UI周りの改善。操作の流れ。現場で迷わないための微調整。そして、どうしても外せない一部ロジックの修正。

ここだけは、ローコードで吸収する。Power Appsで画面の呼吸を合わせ、Power Automateで小さな神経系を足す。

標準の骨格は崩さないまま、現場の体温だけを上げていく。

今回の導入はハイブリッドだ。全体の進め方はウォーターフォールで順番を守る。

ただし実開発工程だけはアジャイルで回す。

この組み合わせは矛盾ではない。むしろ、スケジュールと品質を守るための現実解だった。

標準に拘るほど、後戻りのリスクが高い領域と、素早く試せる領域を分ける必要がある。

分析・設計は型に寄せる。開発は短いサイクルで確かめる。

こうして「崩さないための速度」を作る。

コンセプトトレーニング、要件ヒアリング、CRPからの流れが、そのまま開発工程にも接続していく。

【環境構築|Azureの空の下で、マスターの7割を先に揃える】

開発フェーズの最初にやるべきことは、コードを書くことではない。環境を作ることだ。

ただし今回は、環境構築がそのまま勝敗に直結する。ポイントはマスターデータだ。

環境構築の段階で、マスターを70％から80％まで用意できるか。

結合テストの前までに、100%に持っていけるか。この二つが揃えば、このプロジェクトは勝ちだ。

既にCRPの段階でマスターは50％ほど整っている。これがあるとFDD（機能設計書）作成の精度がとてつもなくあがる。

環境はオンプレではない。クラウドだ。

Azure上に検証環境が立ち上がり、Microsoft Dataverseのデータモデルが血流として準備される。

環境の作り直しも、展開も、以前とは比較にならないほど軽い。

Visual StudioとVisual Studio Codeで拡張を管理し、GitHub Codespacesで同じ開発環境をブラウザ一つで揃える。

開発者のPCがWindows Copilot+PCでもMacでも、環境差で議論が止まらない。

そしてコードは、Azure DevOpsのパイプラインで流れる。

ビルド、テスト、デプロイが一本のコンベアになり、手作業の“儀式”が減る。

楽になった分、言い訳が消える。残るのは、マスターを入れる人間の手と、判断の重さだけだ。

Dynamics 365ベンダー側のリーダー、遠藤が前に出て、淡々と説明した。

「環境はすぐできます。でもマスターは、誰も代わりに入れてくれません。

遅れる理由も、人間側にしかありません。最低7割、8割目指してやっていきましょう！」

ユーザー側からは、業務チームの要として山田（営業）、小野塚（物流）、生産（田中）、高橋（リペア）、佐藤（経理）が出てくる。

彼らは以前の失敗を覚えている。

「分かっています。マスターを後回しにしたら、結合テストが茶番になる。今回は業務側で責任を持ちます。」

小野塚が言い放った。

この合意ができた瞬間、プロジェクトの空気が変わる。マスターはITの仕事ではない。

業務の写し鏡だ。その鏡を先に磨けるかどうかが、開発の速度を決める。

【設計→承認→開発｜Azure DevOpsに刻む一枚の合意】

GAPとして残った部分は、いきなり開発に入らない。

まずやるのは機能設計書(FDD)の作成だ。書くのはベンダー側の設計者。

ここで登場するのが淵山と宮治だ。標準を熟知した設計者であり、同時に現場の声を“標準の言葉”に翻訳できるタイプだ。

機能設計書に必ず書くのは三つ。なぜ標準では足りないのか。

どこまでを変えて、どこから先は触らないのか。そして、次のアップデートで何が起きる可能性があるのか。

設計書はAzure DevOpsに登録され、承認の履歴が残る。

レビューするのはユーザー側。

IT部門のアプリ担当深沢が中心に読み、

現場のキーユーザー（山田・小野塚・田中・高橋・佐藤）が確認し、

OKならPMである桐生（私）が承認する。

この一枚が、開発の暴走を止める。紙の厚みで安心する時代は終わった。

今は、合意の履歴で責任を残す。

【実装｜GitHubCopilotとペアで書き、短いサイクルで壊して戻す】

承認が下りて、ようやく実装に入る。ここからはアジャイルだ。

UIの改善は、Power Appsで素早く作って触る。

一部ロジックの修正は、影響範囲を限定し、Visual Studio Codeで拡張を実装する。

開発者はGitHub Copilotとペアで書く。コードを速くするためではない。

バグを減らし、レビューの焦点を「設計の意図」に戻すためだ。

そして必要ならCodespacesで環境を揃え、いつでも同じ前提で検証できるようにする。

PCはWindows Copilot+PCだけではない。Macも混ざる。

それでも同じ品質で進めるために、環境差を潰すことが最初から工程に組み込まれている。

開発の現場は、15年前の「鉄の檻」から解放されていた。

Visual Studio Codeを開けば、GitHub Codespacesが数秒で立ち上がる。

「……コードが、向こうから語りかけてくる。」

溝道が、GitHub Copilotとのペアプログラミングに没頭する。

AIがロジックを提案し、テストケースを自動生成する。

私たちは、Power Appsで現場の「痒いところに手が届く」画面をローコードで組み上げ、

Power Automateで複雑な承認フローを神経系のように繋いでいった。

かつての「泥臭い溶接」は、AIとの「高度な対話」へと昇華されていた。

帳票開発にはWord Layoutを使う。理由は単純だ。帳票は、内製化しやすい形で残したい。

開発が伴う帳票は、いつか“誰も触れないブラックボックス”になる。

Word Layoutなら、現場の変更要求に対して、より現実的に追従できる。

ユーザーが設計でき、テストへのモチベーションも高くなるメリットがあるのだ。

【テストの分業｜単体→機能→結合の順番を崩さない】

開発後、まず単体テストを行うのはプログラマーだ。

コードが意図通りに動くかを、自分の責任で確認する。

次に、ベンダー側の設計者（淵山・宮治）が機能テストを行う。

深沢が画面を触り、設計通りか、業務に耐えるかを確認する。

動くと使えるは違う。この工程を分けることで、その違いが露出する。そして、結合テストに入る。

ここで絶対条件がある。マスターが揃っていない結合テストに、意味はない。

データが足りなければ、流れは再現できない。

権限が未設定なら、エラーは偽物になる。

だから結合テスト前までに、マスターはその時点の100パーセント。

権限設定もロールごとに一通り揃える。これが物凄く重要だ。やりきらないと致命傷になる。

結合テストは「動作確認」ではない。「業務の再現」だ。

再現できないなら、テストのふりをしているだけになる。

インターフェースがあるなら、相手側のテスト環境を準備するのはユーザー企業側だ。

ここを曖昧にしない。繋がらない原因を、ベンダーのせいにしない。

責任分界を先に確定しておく。この線引きが、後半のスピードを守る。

忘れてはならないのは、品質テストだ。各オペレーションで時間をはかる。

非機能要件を満たしている事をしっかりと確認し、パフォーマンスに関する数値情報を取りまとめておく必要がある。

手を抜いた奴の負けなのだ。あとで、パフォーマンス出ませんでしたなんて恥ずかしくて言えない。

【可視化｜Power BIで“マスター投入量”を見える化する】

今回の強みは、進捗が見えることだった。

マスター投入量がPower BIで可視化される。どの領域が何パーセント入ったか、どこが詰まっているかが見える。

感覚ではなく、事実が先に立つ。

「まだ不安です。」

そう言いかけた人が、ダッシュボードを見て黙る。

不安を否定しない。ただ、議論の材料を事実に戻す。これが、無駄な会議を減らした。

【マルチデバイス｜最後の詰めはPCだけでは終わらない】

そして、ここが地味に効く。テストはPCだけでは終わらない。

iPhoneでも、Androidでも確認する。現場は机の前だけではない。

移動中、現場の隅、倉庫の入口、営業車の中。

そういう場所で使われるスマホ画面の癖は、PCのブラウザだけ見ていても分からない。

Windows Copilot+PCでもMacでも同じ。違いが出るなら、そこで止めて潰す。

標準に拘るというのは、画面の見た目を揃えることではない。

“誰がどこで使っても業務が戻らない”状態を作ることだ。

標準を骨格にし、GAPの9割を帳票とインターフェースへ追い込み、残り一割をローコードで吸収する。

Azure DevOpsで流れを作り、GitHub CopilotとCodespacesで速度と再現性を確保し、

Visual StudioとVisual Studio Codeで実装を揃える。

帳票はWord Layoutで内製の余地を残す。

そしてマスターを70％から80％、結合テスト前に100%へ。

ここまで積み上がれば、結合テストは“恐怖”ではなく、“答え合わせ”になる。

次は、結合テストだ。ここで、標準の道路が本当に全員を運べるかが試される。

【結合テスト｜静かな地獄はデータから始まる】

結合テストは、いつも静かだ。画面が落ちるような派手な悲鳴はない。

エラー音も鳴らない。代わりに、数字が合わない。契約が見えない。履歴が繋がらない。

その静かな違和感が、じわじわと現場の神経を削っていく。

だから私たちは、結合テストを「機能のつなぎ確認」だとは呼ばなかった。

結合テストは、業務を再現するための本番前夜。

そして本番前夜に必要なのは、コードではなく、データだ。

まず最初にやるのは、開始残高と契約残の移行リハーサルだった。

ERP側に開始残高を入れる。CRM側に契約残を入れる。

見積が受注になった際に、CRM→ERPにデータが連携される。

受注残はCRMに見積として移管し、手動で受注に切り替え、注文書をCRMで作成、それをERPに連携させるスキーマを採択した。

そしてその状態で、受注から請求、入金、保守更新までの流れを通す。

1回目は、誰も驚かない。必ず、どこかで止まる。

止まるべき場所が見えるかどうかが、このプロジェクトの成熟度だ。

データ移行リードの黒田は、結合テストの初日に、全員へ宣言した。

「開始残高と契約残は、3回、取り込みを行います。

1回目は壊していい。2回目で直す。3回目で黙らせる。」

その言葉の強さは、技術への自信ではない。

15年前の呪いを、ここで終わらせるという覚悟だった。

過去取引データは、別の場所に逃がした。

修理履歴、過去の点検履歴、部品の交換履歴。

それらをERPやCRMの中に全部抱え込まない。

重さは、後で必ず足を引っ張る。だから、修理履歴はMicrosoft Fabricへ移管する。

Fabric IQを活用し、ERP側の修理オーダーを入れる際に、Copilotでそれを参照し、修理の効率を上げるためだ。

ERPとCRMは「今とこれから」を動かすための血流。Fabricは「過去」を沈めて、必要なときだけ引き上げる海。

この分離ができるだけで、結合テストの視界が驚くほどクリアになる。

「過去は捨てない。ただ、足枷にしない。」「必要なら、分析用に外部データもここに集約可能だ。」

黒田が言ったその一言は、今回の設計思想そのものだった。

だが、結合テストが本当に難しいのは、社内の繋ぎだけではない。外が絡むと、戦場になる。

今回、結合テストにはe-Commerceベンダーが開発したウェブ販売の仕組みとのインターフェースが含まれていた。

その仕組みは、現場の心臓に近い。止まれば業務が止まる。

そして、結合テストの開始日が近づくにつれて、嫌な沈黙が増えた。

「相手側のテスト環境、まだ準備中です。」

インターフェース担当の立花（IT部門）が、淡々と報告した。淡々としているからこそ、怖かった。

e-Commerceサイト開発ベンダーの責任者は井上という男だった。

口調は丁寧で、資料も揃っている。

だが、返事が遅い。遅いのではなく、決めない。

決めないまま、時間だけが過ぎていく。

そして、結合テスト当日。最初の接続で、バグが出た。

「接続は通ります。ただ、データが…」

立花の声がそこで切れた。画面上では連携できている。

ログも出ている。だが、肝心のデータが欠けている。

欠けているというより、意図と違う形で歪んで届いている。

井上から来た第一報は、短かった。

「調査します。」

調査は2日で終わらなかった。4日でも終わらなかった。

1週間が消えたころ、井上がようやく言った。

「原因は弊社側です。修正に入ります。」

そして修正後、また別のバグが出た。

2週間遅延。

結合テストは、待ってくれない。

開始残高も契約残も、リハーサルの回数が減れば、確率的に事故が増える。

時間を失うというのは、リスクを積み増すということだ。

会議室の空気が重くなる。

誰かが言いかけた。

「じゃあ、本番日を…」

その言葉は最後まで出なかった。

今回のプロジェクトは、途中で止める勇気を前提にしている。

だが、止めるべき理由は「外が遅れた」ではない。

止めるなら、もっと手前で止めるべきだった。いま止めるのは、ただの敗北になる。

ここで、直下のDynamicsベンダーが動いた。

現場に入っている実装ベンダーのリードは、遠藤という男だった。

彼は、焦らない。だが、逃げもしない。

「2週間、取り戻します。ただし方法は一つ。結合テストを並列化します。」

普通ならやらない。だが今回の開発は、ウォーターフォールの骨格に、アジャイルの筋肉をつけていた。

つまり、順番は守るが、検証の回し方は柔らかい。

遠藤は、結合テストを3つに分解した。

開始残高・契約残の移行リハーサルを止めない。

ERPとCRMの社内結合テストを先に完了させる。

外部インターフェースは、到着次第その枠に流し込む。

「外が遅れても、内側の品質は落とさない。落とすのは、言い訳だけです」

遠藤の言葉は、冷たいが、正しい。

立花はAzure DevOpsのボードを開き、結合テストのタスクを再編した。

修正、再テスト、回帰確認、データ再投入。

全部が一つの線で繋がって見えるようにした。

1つでも遅れれば、どこで詰まるかが可視化される。

黒田はPower BIのダッシュボードを更新した。

開始残高の投入率。契約残の一致率。移行差分の残件。

そしてMicrosoft Fabricへ移した修理履歴の取り込み進捗。

目が疲れるほどの数字が並ぶ。だが、数字が並ぶほど、嘘が減る。

「今日は2回目のリハーサルを回します。」

立花が言う。

「外部インターフェースが止まっていても、こちらは止めません。

リハーサルを減らした瞬間、事故の確率が上がるからです。」

結合テストの夜は長い。だが、15年前と違うところがある。

15年前の夜は、何が起きているか分からなかった。

今回は、分かる。遅れているのはどこか。誰が詰まっているか。

何を待っているか。それが見える。

だから、人は動ける。2週間の遅延は、取り返せるのか。

その問いに、遠藤は「はい」とも「いいえ」とも言わなかった。代わりに、こう言った。

「取り返したように見せることはできます。

でも、取り返した“つもり”にだけはしません。

結合テストで嘘をついたら、本番で人が泣く。それはもう、やりません。」

そして、外部ベンダーが修正を入れて戻ってきた。

井上は疲れた顔で、会議室に現れた。

「申し訳ありません。大変お待たせしました。今度こそ大丈夫です…」

言葉の続きを、誰も求めなかった。求めるのは、言葉ではなく結果だ。

「万が一、何かありましたら、ここで即対応致します。」

井上と一緒にオンサイトに来たシニアエンジニアの浅見と山本が言う。

「では、結合テストに入れます。こちらも、準備できています。

遅れた分、同じバグは二度と許されません。」

立花が説明した。

怖いのは、外部インターフェースが繋がらないことではない。

繋がったふりをすることだ。今回のチームは、その怖さを知っていた。

結合テストは、再開した。開始残高は3回目で黙った。

契約残も一致率が上がっていった。

修理履歴はMicrosoft Fabricの中で過去の海へ沈み、必要なときだけ引き上げられる形に落ち着いていく。

現代の正攻法だ。リペア担当の高橋もデータ移行に関しては細心の注意をはらっていた。

2週間遅れたはずの時間が、いつの間にか追いついていた。

追いついたのではない。

追いつくために、誰も嘘をつかなかったのだ。

その積み上げが、結果として時間を取り戻した。

結合テストが終わるころ、会議室には拍手はなかった。

歓声もなかった。ただ、全員が同じことを感じていた。

「今回は、泥の勝利じゃない。」「静かな勝利だ。」

そして次のフェーズへ進む。トレーニング。ユーザーテスト。

そこで初めて、この結合テストの勝利が「人の手触り」に変わる。

【結合テストの夜｜席が空いている理由】

結合テストが一段落した夜、桐生（私）は一人で店に向かった。

上野と溝道は来ない。理由は、誰も聞かなかった。

上野は、連日の判断と調整で、完全に疲れ切っていた。

溝道は、久しぶりに家族と夕食を取ると言っていた。

それでいい、と全員が思っていた。

今日は、あの二人が前に立つ夜ではない。

店に入ると、すでに何人かが集まっていた。

営業の山田。

物流の小野塚。

生産の田中。

修理の高橋。

経理の佐藤と宮下。

IT部門からは、黒田と立花。

そして、

林取締役と石塚副社長が、少し離れた席で静かに話していた。

乾杯のあと、最初に口を開いたのは山田だった。

「……正直に言いますね。つながった瞬間、ちょっと怖かったです。」

誰も笑わない。

その「怖さ」が何を指しているか、全員分かっている。

「CRMで入れた受注が、そのままERPに流れる。

在庫が引き当たって、出荷予定が立つ。

請求のタイミングまで、一本の線で見える。」

山田は、グラスを置いた。

「便利です。でも、逃げ場がない。」

小野塚が、すぐに頷いた。

「物流も同じ。

“伝票が来てません”って言えなくなった。

どこで止まってるか、全部見える。」

田中が、少し苦い顔で続ける。

「製造指示がズレたら、それが営業の判断なのか、計画の問題なのか、すぐ分かる。」

高橋が言った。

「修理もそうです。契約、請求、履歴。今までは人の頭にあったものが、全部外に出てきた。」

佐藤が、静かに言葉を重ねる。

「……数字が、黙ってくれません。」

宮下が、小さく頷く。

「後で合わせる余地が、ないですね。」

その言葉のあと、一瞬、間が空いた。

黒田が、淡い声で言った。

「それが、結合テストです。機能がつながるテストじゃない。前提がつながっているかのテスト。」

立花が、少し言いづらそうに続ける。

「CRMとERPの連携は、想定どおりでした。でも、怖かったのは、ウェブサイトからの流れです。」

全員の視線が、立花に集まる。

「Webで受けた注文がERPに入り、そこからCRMに返ってくる。

量も、スピードも、現実は想定を超えてました。」

立花は、言葉を選ぶ。

「仕様としては正しい。でも、“現場として耐えられるか”は、別でした。」

黒田が補足する。

「正しいデータが、正しい順番で、正しい量で流れないと、現場は壊れます。」

そのとき、林取締役が、桐生の方を見て言った。

「今日は、上野さんと溝道さんはいないんだね。」

「はい。」

桐生は、短く答えた。

林は、それ以上聞かなかった。

代わりに、全員を見渡して言う。

「じゃあ今日は、“盾役”がいない前提で話そう。」

その言葉で、空気が変わった。

石塚副社長が、静かに口を開く。

「結合テストで、一番良かったのは、止めるべきところで、止めたことだ。」

佐藤が、少し驚いた顔をする。

「止めた、ですか？」

石塚は頷く。

「無理だと思ったときに、“いけます”と言わなかった。そこを評価している。」

立花が、正直に言った。

「……止めるって言うの、正直怖かったです。上野さんがいたら、任せてたかもしれない。」

石塚は即答した。

「それでいい。止める判断を、全部ITに背負わせるのは間違いだ。」

林が、続ける。

「今日は、上野さんと溝道さんが来てない。それは悪いことじゃない。

“誰が無理をしているか”が、いつもよりはっきり見える。」

田中が、ぽつりと言った。

「正直、今日はITの人たちが前に出てない分、自分たちの判断が、重く感じました。」

林は頷く。

「それが、対話だ。誰かが前で受け止める会話じゃない。全員が同じ重さを感じる会話。」

小野塚が言った。

「壊れなかったんじゃない。壊れそうなところで、止まれた。」

山田が続ける。

「止まれた理由が、分かってる。それが、前と違います。」

石塚が、最後に言った。

「結合テストは終わった。だが、ここから先は、“誰が疲れているか”を見続けないと、必ずどこかで歪む。」

桐生は、その言葉を、黙って受け取った。

上野も、溝道も、今日はここにいない。

だが、この夜、彼らがいなくても成り立つ会話が、確かに残った。

店を出ると、夜は深い。

だが、足取りは前より軽い。

結合テストは終わった。

そして、無理を無理だと言える関係が、静かに、ここにあった。

【トレーニング｜教える準備ではなく、使われ続ける準備をする】

結合テストが終わった直後、プロジェクトは次のフェーズに入る。

トレーニングだ。多くのプロジェクトで、トレーニングは「最後の説明会」になりがちだ。

資料を配り、画面を見せ、操作を説明する。

その場では分かった気になるが、翌週には戻れない。

戻れないのは、ユーザーの能力の問題ではない。

プロジェクトが「戻れる構造」を作らなかっただけだ。

今回は最初から、その道を捨てていた。

標準に拘るということは、個人技で回すのではなく、運用の型で回すということだ。

だからトレーニングは、操作の暗記ではなく、型の共有でなければ成立しない。

まず、トレーニング環境を作る。UAT環境は、そのトレーニング環境をコピーして作る。

構成も、マスターも、権限も基本的には同じにする。

環境差があると、学習がズレる。ズレは、結局「現場の不信」になる。

ただし、一つだけ例外がある。契約残のデータ移行だけは、念には念を入れる。

契約残は、業務の神経だ。ここが狂えば、UATはUATとして成立しない。

本番の朝に、誰かが静かに崩れる。

だから契約残の移行は、トレーニング環境とUAT環境の両方で実施する。

二度やる。確認する。差分を潰す。冗長に見えるが、この冗長さこそが、15年前には存在しなかった安全装置だった。

データ移行リードの黒田（IT部門）が、いつもの淡い声で言った。

「一回で終わらせると、事故は必ず本番に移ります。

契約残だけは、二回やって、二回とも黙らせましょう。」

溝道（IT部門開発担当）が頷いた。頷き方が以前と違う。

ため息混じりではなく、腹を括った頷きだ。

「了解です。契約残は、業務側でも責任を持って照合します。

UATの前に、もう一回、数字を握り直しましょう。」

トレーニングの準備は資料作りから始まる。

ただし今回は、資料を一種類にしない。役割に応じて二つに分ける。

一つ目はトレーニングマニュアル。これはベンダーが作る。

画面の意味、データの流れ、標準プロセスの意図。何をすると何が起きるか。

なぜこの順番なのか。システム側の原理原則を、誰が読んでも同じ理解になる形で残す。これはベンダーにしかできない仕事だ。

二つ目は業務オペレーションマニュアル。

これはキーユーザーが作る。入力のタイミング、承認の段取り、例外時の判断、部門間の受け渡し。

システムの手順ではなく、業務の型だ。現場の言葉で書くからこそ、現場に戻れる。

そして重要なのは、キーユーザーが作った業務オペレーションマニュアルを、ベンダーがレビューすることだった。

現場の型が標準の道路から逸れ始めていないか。

知らぬ間に裏道が生まれていないか。

15年前の呪いは、いつも「善意の近道」から始まった。

ベンダー側のトレーナー役としてアサインされたのは、吉田というとても優秀なコンサルタントだった。

静かな口調だが、線引きに迷いがない。

吉田は、会議室の前でこう言った。

「ベンダーが作るのは、システムの教科書です。皆さんが作るのは、現場の辞書です。

辞書が裏道にならないように、私たちがレビューします。道路を守りながら、走り方を作りましょう。」

山田が小さく笑った。

「教科書と辞書、いいですね。前回は地図がなかったから、迷子になりましたよ。」

吉田は笑わない。笑わずに頷く。

「今回は地図を作りながら走ります。だから、迷っても戻れます。」

最初に受講するのはキーユーザーだ。エンドユーザーではない。

キーユーザーが理解し、言語化し、運用の型に落とさなければ、標準は定着しない。

キーユーザートレーニングはベンダーが実施する。

トレーニングマニュアルに沿って画面を説明するが、操作説明で終わらせない。

必ず意図を添える。なぜこの項目が必須なのか。

なぜこの入力順なのか。このデータはどこへ流れ、どこで参照されるのか。

吉田が画面を切り替えながら言う。

「ここは、ボタンの押し方を覚える場所ではありません。

業務の血流を覚える場所です。血流が分かれば、UIが変わっても迷いません。」

キーユーザー、高橋（リペア担当）が手を挙げた。

「契約残の確認って、ここで完結しますか。それとも別の画面で見るべきですか？」

吉田はすぐに答えない。画面を一つ戻し、データの関連を見せた。

「ここで完結させると、後でズレます。

契約残は、見る場所を固定するより、見るための順番を固定した方が壊れません。

今日覚えてほしいのは、画面ではなく順番です。」

アプリケーション担当の深沢（IT部門）が横から補足する。

「順番が固定できたら、それを業務オペレーションマニュアルに落とします。

キーユーザーの仕事は、ここからが本番です。」

ここでトレーニングは、受講者を「教わる側」で終わらせない。

キーユーザーに宿題が渡される。

業務オペレーションマニュアルのドラフト作成だ。

山田が、少し面倒そうに言う。

「マニュアル作りって、結局、夜中になりますよね」

吉田は淡々と言った。

「夜中にするか、本番の朝にするかです。本番の朝にすると、誰かが泣きます。」

誰も笑わなかった。笑えない。全員がその泣き方を知っている。

エンドユーザートレーニングは、キーユーザートレーニングに参加した業務ユーザーが実施する。

ベンダーが直接エンドユーザーに教えると、その場では分かった気になるが、現場の文脈に落ちない。

現場は正しい言葉では動かない。

現場は自分たちの言葉で動く。

福本が営業チームの前に立つ。上野と溝道が並んで座り、スマホを机に置いた。

「今日は操作を覚えなくていいです。まず、いつ何を入力するかだけ揃えます。」

深沢がすぐに突っ込む。

「でも福本さん、現場って急に割り込み入りますよね。

予定通りにならないとき、どうするんですか？遅延しますよ？」

福本は、業務オペレーションマニュアルのドラフトを開いた。

「そこが“例外”の欄。例外は、勝手に裏道を作らない。

例外は、ここに戻す。戻せない例外は、UATで必ず潰す。」

そして、横で吉田が一言だけ添える。

「今の説明が“運用の型”です。これが残れば、標準は崩れません。」

この瞬間、教える側が育っていく。教えながら、キーユーザー自身の理解が完成していく。これが狙いだった。

今回のトレーニングが15年前と決定的に違うのは、ここだ。

トレーニングが「受けたかどうか」ではなく、「使ったかどうか」で評価される。

トレーニング中に投入された伝票、入力されたデータ、実行された処理はPower BIで可視化される。

誰がどれだけ入力しているか。どの業務が止まっているか。

どの拠点が進んでいないか。数字として見える。

それだけではない。Microsoft Teams で録画しているので、マニュアルとベンダー側の講師の説明をいつでも聴き直す事ができる。

これは地味だが強烈だ。

黒田（IT部門、データ管理）がダッシュボードを映しながら言う。

「入力が少ない人がいます。これ、犯人探しじゃないです。

事故予防です。入力が少ない人は、迷ってる可能性が高い。迷ってるなら、今つぶします。」

営業の山田が小さく手を挙げた。

「すみません、入力が少ないの、たぶん自分です。どこから入れるか迷って、止まりました。」

黒田は責めない。

「OKです。止まった場所が分かったなら勝ちです。

終わったら個別に見ましょう。今日のうちに、迷い方を潰します。」

この「個別フォロー」を仕組みにする。注意喚起を入れる。責めない。隣に座る。一定数の入力が入るまで伴走する。

ここを放置すると、本番で必ずつまずく。つまずきは本人の問題ではなく、プロジェクトの問題になる。

だから個別フォローはコストではなく保険だった。

トレーニング後、必ずアンケートを取る。形式的な満足度調査ではない。

分かった点、不安が残る点、業務オペレーションマニュアルに反映すべき点を、具体的に回収する。

福本がアンケート結果を見て、ぽつりと言った。

「15年前のやつ、思い出しました。あの時は“よく分からない”しか書けなかった。」

工場長の新井が頷く。

「今回は違いますね。“どこで迷ったか”が書けてる。迷い方が言語化できてる。」

吉田が最後に一言だけ言った。

「それが、標準に拘った成果です。標準は、迷いを消すんじゃない。迷いを共有できる形にする。」

比較にならないくらい良いフィードバックが並ぶ。だが、喜びすぎない。ここで新たな要望が出るからだ。

【変更要求｜受けないという交通ルール】

トレーニングをすれば要望は出る。出ない方が不自然だ。

だが、ここで拾いすぎるとプロジェクトは終わらない。

裏道がまた増える。方針は明確にした。帳票の微調整以外の変更要求は、プロジェクトとして受けない。

本番稼働後に、本当に必要であれば検討する。今はやらない。

吉田が会議室で言い切った。

「UIを変えたい気持ちは分かります。

でも、今は道路を変えません。道路を変えるなら、稼働後に“必要性”を数字で示してからです。」

吉田は優秀だ。ひょっとしたら、室長が書いたUIの終焉に関する記事を読んだのかもしれない。

桐生（私）も以下のように伝えた。

「帳票の微調整だけは、現場の呼吸に直結するのでやります。

それ以外は、いったん飲み込みます。これはプロジェクトの交通ルールです。」

不満は残る。だが、不満が残ることは悪ではない。

不満を理由に裏道を作らないことの方が、遥かに価値がある。トレーニングが終わるころ、システムはまだ本番ではない。

だが、人はもう動き始めている。運用の型が生まれ、言葉が揃い、入力が積み上がっている。

次はUATだ。トレーニング環境をコピーしたUAT環境で、契約残の移行をもう一度回す。

念には念を入れたその一手が、最後の安定を作る。

【UAT｜試験はコードではなく、人の熟練度で遅れる】

UAT環境は、トレーニング環境をコピーして作る。構成もマスターも権限も同じにして、学習のズレを消す。

だが一つだけ例外がある。契約残のデータ移行だけは、トレーニング環境とUAT環境の両方で回す。

念には念を、というより、ここだけは「二回やらないと安心できない領域」だと全員が理解していた。

UATは、受入テスト計画と結果が揃って初めて成立する。

その前提には運用マニュアルの更新やパラメータの更新も含まれる。

プロジェクトマネージャーの桐生（私）は、UATキックオフの冒頭で、あえて淡々と言った。

「今日は士気を上げる会じゃない。UATは“できるか”じゃなく“回るか”を確認する。

回らないなら、本番は来ない。それだけです。」

佐藤が頷く。山田がメモを開く。小野塚がペンを持ち直す。

この時点で、前回とは空気が違った。

前回苦労したからこそ、今回は“書ける”。

テスト計画書も、テストスクリプトも、すでに出来上がっている。

UATのための型が、現場側に残っていた。

吉田が、静かに補足する。ベンダー側のトレーナーであり、今回もレビュー役として残っている男だ。

「前回の経験が生きているのは、資料があることじゃない。

資料が“使われる前提”で書かれていることです。UATはその前提が本物かどうかを見ます。」

淵山と宮治も吉田と共にユーザーの後ろについてオペレーションをフォローする。

UATで一番怖いのは、社内機能の不具合ではない。

外部システムとのインターフェースが絡んだ瞬間に、試験が「待ち」になることだ。

インターフェース担当の立花が、ホワイトボードに外部依存を並べた。

「外部連携は三系統です。テスト環境の準備はユーザー側がやる前提で合意してます。

相手がいるので、準備が遅れると、こちらのUATも止まります。」

溝道が即答する。

「前回、ここで止まった。今回は止めない。

外部連携用のテスト環境は、今日中に“使える状態”にします。

使えないなら、理由も含めて上げてください。」

“理由も含めて”という言い方が、今回の成熟度だった。できないを、できないまま放置しない。

UATの設計で、ベンダー側から一つ要求が出た。

「1か月分のデータを入れてください。」

言ったのは遠藤だ。今回、基幹システムの構築を委託したDynamicsベンダーのリードで、結合テストの遅延を取り戻した男でもある。

優秀な吉田の上司だ。

「1か月分を入れると、UATで“揺れ”が見えます。例外の頻度も、権限の歪みも、帳票の詰まりも出る。

短いデータだと、見えないまま本番に行く。」

正論だ。だが現場には、もう一つの現実がある。

今のシステムにもデータを入れなければ、業務は回らない。並行稼働の期間は、現場の体力を確実に削る。

製造部門の田中、修理部門の高橋が疲れを隠さずに言った。

「製造、修理共に、1か月分の伝票を登録できる人がいません。

すみません。非機能要件定義の決定事項なのですが、

今のシステムも回しながらだと、現場が先に折れます。」

沈黙が落ちる。

その沈黙の中で、桐生（私）が“交通整理”を始めた。

1か月分を丸ごと入れるのはやめましょう。代わりに、MECEで必要なシナリオを切ります。

必要十分なパターンだけを作る。で、それを回数で担保する。」

深沢が頷く。

「回数で揺れを作る、ですね。」

結論はこうなった。MECEで切った必要なシナリオ分を×10回。それを担当者別に3回ずつ回す。

“1か月分”という量の議論を捨てて、“必要な揺れを作る”という質の議論に切り替えた。

営業の山田が笑う。

「1か月分じゃなくて、“10回分の現実”ですね。」

吉田が笑わずに言う。

「10回、回すと、嘘が出ます。嘘が出るなら、UATの価値があります。」

UATで一番遅れる原因は、意外と単純だ。

キーユーザーとエンドユーザーの習熟度が上がっていないと、試験そのものが進まない。

テストスクリプトはある。計画書もある。

だが、スクリプト通りに操作できない、データの意味が分からない、迷ったときに戻れない。

こういう“小さな詰まり”が連鎖する。

だから桐生（私）は、UATの前に一つだけルールを入れた。

「UATは、誰かが“教える場”ではありません。

教えるのはトレーニングまで。UATは“自分で戻れるか”を試す場です。

戻れない人がいたら、責めない。その代わり、試験を止めない。止めるのは、プロジェクト側の責任です。」

経理の佐藤が、現場側の責任を引き取る。

「エンドユーザー側で詰まったら、経理部門はキーユーザーが拾います。

ただし拾い方は、口頭じゃなく運用マニュアルに落とす。マニュアルを更新して、次の担当が迷わないようにします。」

ここでも、トレーニングで作った「業務オペレーションマニュアル→ベンダーレビュー」の流れが効いてくる。

UATに入ると、運用マニュアルはドラフトから更新版へ変わっていく。

そして今回、UATの現場を救ったのが、またしてもPower BIだった。

データ登録状況が見える。誰がどこまで入力したかが見える。

どのシナリオが何回回ったかが見える。結果も見える。

実は頑張った人を誉める仕組みもPower BIに実装されていた。

こういう心の通う仕組みがつくれるようになったのはチームの成長だ。

黒田が、ダッシュボードを投影して言った。

「入力が遅れているのはここです。原因は二つ。

契約残の照合で止まってるか、インターフェース待ちです。待ちなら待ちでいい。

ただし“待ち”を可視化しないと、遅延は伝染します。」

立花がすぐ返す。

「外部側の準備は今日中に潰します。相手ベンダーの窓口も押さえました。

テスト環境が上がらないなら、こちらのシナリオを先に回して、外部連携は到着次第差し込みます。」

桐生（私）も頷いた。

「よし。UATは止めない。内側を先に固める。

外が来たら合流。結合テストでやったことを、もう一回やるだけです。」

ここでまた、直下ベンダーの遠藤が動く。

Azure DevOpsのボードにUATのタスクを切り直し、シナリオ×10回の消化状況を担当者別に割り当てる。

それをPower BI側で見える化し、詰まっている担当者には個別フォローを入れる。

営業の山田が、半ば冗談のように言った。

「今日のUAT、テストしてるのか、マネジメントされてるのか分からなくなってきました。」

桐生（私）も即答した。

「両方です。UATは、テストであり、運用の予行演習であり、プロジェクト管理の最終試験でもある。」

この一言で、場が引き締まる。

UATで遅延するプロジェクトは、ほぼ例外なく「誰が止めるか」「誰が拾うか」が曖昧だ。

今回は違う。止めないと決めた。拾う役割も決めた。見える仕組みもある。

外部インターフェース側で、また一瞬、空気が揺れた。

相手ベンダーから「準備が間に合わない」という連絡が入る。

立花（IT部門、インターフェース構築担当）が、冷静に言う。

「間に合わないのは仕方ない。だけど、間に合わないまま黙るのはダメです。

テスト環境がいつ上がるか、上がらない理由は何か、その代替は何か。今日中に出してください。」

相手の担当者（井上）が言い訳を始めかけたところで、溝道が割って入る。

「前回は、ここで止まった。今回は止めない。止まらないために、こちらは準備してます。あなたたちも準備してください。」

言い方は強い。だが、攻撃ではない。

交通ルールの確認だ。そして実際、止まらなかった。

外部連携を待たずに回せるシナリオを先に10回回し、担当者別に3回ずつ消化し、外部連携が整った瞬間に差し込んで、UATの形を崩さずに接続試験へ移った。

UAT終盤、最後まで重かったのは契約残だった。

2環境で移行を回しているから、嘘が出ない。その代わり、誤差の原因が逃げない。

物流部門の小野塚が言った。

「これ、どっちが間違ってるじゃなくて、どっちの前提が違ってるかですね。」

工場長の新井が頷く。

「そう。前提が揃えば、数字は揃う。揃わないなら、業務の交通ルールがまだ揃ってない。」

そして、その瞬間こそがUATの価値だった。

バグを潰すだけではない。前提を揃える。人の癖を型に戻す。

「UATは、派手な勝利じゃない。静かに“本番に行ける”と言える状態を作るだけです。今日、それが見えたと思います。」

私はそう付け加えた。

誰も拍手しない。だが、全員が頷いた。次はいよいよ本番稼働に向けた最終準備へと進む。

ここからは、技術ではなく、現場の呼吸と日付が支配する。

そして、15年前にはなかったものが、今はある。

止めない仕組み。戻れる型。そして、見える現実。

【UATの夜｜Readyと呼べる瞬間、そして甘えないための合図】

UATが終わった夜。

誰も「成功した」とは言わなかった。ただ、全員が同じ感覚を持っていた。

もう一度ゼロに戻ってやり直す未来は、今日は見えない。

その代わり、別の重さが見えている。

「ここから先は、日付と数字が支配する。」

店は駅から少し歩いた大きな居酒屋だった。個室は取らない。今日は混ざるほうがいい。

テーブルは分かれているのに、人の流れは一つだ。

ユーザー、IT、ベンダー、Microsoft。

立場が違う人間が、同じ温度で座っている。

それだけで、このプロジェクトはもう前と違う。

乾杯は自然に起きた。

声高な音頭はない。

グラスが上がり、静かに触れ合って、終わった。

最初に声を上げたのは営業の山田だった。

「……すみません、最初に言わせてください。

PowerBI、最高です。」

一瞬止まり、次の瞬間、笑いと同意が重なる。

「分かる。」

「それ言いたかった。」

「ほんと、助かった。」

物流の小野塚が、間髪入れずに乗る。

「UAT中、詰まったときに、誰のせいかじゃなくて、どこが詰まってるかを、

全員で同じ画面で見られた。あれだけで、喧嘩が一つ減った。」

生産の田中が頷く。

「会議が短い。“たぶん”が消えると、人は疲れない。」

修理の高橋が、少し笑って言う。

「修理履歴をFabricに逃がしたの、効いてます。

ERPとCRMが軽い。

それでいて、Copilotで必要なときだけ引ける。

現場としては、こういうのが欲しかった。」

経理の佐藤が、低い声で言う。

「経理は、PowerBIが盾でした。説明が必要な数字が減った。

黙ってる数字が増えた。それだけで、月末の怖さが変わります。」

宮下が続ける。

「朝、ダッシュボードを見るのが怖くないんです。今日はどこを見ればいいかが、分かるから。」

その言葉を合図に、人の流れが変わった。

清水の周りに、現場の人間が集まる。

質問が止まらない。

「このKPI、どう切ってるんですか。」

「更新、どのタイミングで走ってます。」

「現場の粒度に合ってるの、なんで分かるんですか。」

清水は照れたように笑う。

「分かったんじゃなくて、聞いたんです。黒田さんに。山田さんに。佐藤さんに。

誰が、いつ、何を見るか。そこだけは最初に決めました。」

黒田が淡く頷く。

「データは、正しいだけじゃ意味がない。見られる形になって、初めて仕事をする。

清水さんは、そこを最初から外さなかった。」

長い髪をかき上げながら、清水が応えた。

「可視化が本当に大切でしたね。数字を黙らせた皆さんの勝利です！」

そこへMicrosoft側が自然に混ざってくる。

営業の久保田がグラスを置いて言った。

「今日は、ライセンスを供給する側としてじゃなく、見届けた側として来ました。

PowerBIを“使われる形”で立たせたのは、皆さんの使い方が正直だったからです。」

宮本が続ける。

「UATの途中で止めた判断、あれが一番印象に残ってます。

止めるって、技術じゃなく文化なんですよね。」

Dynamics365に詳しいマネージャーの佐藤が、少し嬉しそうに言う。

「正直、Dynamics365は何でも魔法みたいに解決する道具じゃない。

標準には癖もある。制約もある。

でも、皆さんはその制約を“敵”にしなかった。

制約を前提として運用を育てる、という使い方をしてくれた。

それが、製品側からすると一番嬉しいです。」

セキュリティの河野が短く言う。

「安全なのは仕組みじゃない。止められる空気です。止めたことがログに残る。

ログが残るから、次も止められる。それが、本当の安全です。」

その言葉に、上野が静かに頷いた。

上野は派手に語らない。今日は特に。

「UATで、“止める”を許してもらえたのが大きかった。昔は止めた瞬間に責められた。

今は止めた瞬間に、議論が始まる。」

深沢が苦笑いする。

「止められると、嘘をつかなくて済みますからね。」

溝道が、珍しく声を張った。

「嘘をつかないと、コードが静かになる。静かなコードは、落ちない。」

その言葉に、Dynamicsベンダー側が笑う。

遠藤が、ようやく腹の中を出す。

「……正直、今回、きつかったです。でも、きつい理由が違った。」

誰かが聞く。

「違った？」

遠藤は頷く。

「昔のきつさは、間に合わせるために嘘をつくきつさだった。

今回は、嘘をつかないために踏ん張るきつさだった。

どっちがいいかって言われたら、後者のほうが、まだ人間らしい。」

淵山が続ける。

「要件定義のときから、空気が違いました。“できるか”より、“やるべきか”を聞かれた。

あれ、実はコンサル側は一番救われるんです。仕様に落とし込む前に、対話があるから。」

宮治が頷く。

「CRPで不満が出た瞬間に、誰かが必ず聞いた。

『それは業務の本質か、過去の癖か』

この問いがある現場は、裏道が生まれにくい。」

トレーナーの吉田が、穏やかに言う。

「トレーニングで一番驚いたのは、ユーザーが“覚えなくていい”と言い始めたことです。」

山田が首をかしげる。

「覚えなくていい？」

吉田が笑わずに頷く。

「はい。『順番を覚える』って言い方をしてくれた。UIは変わる。でも順番は残る。

その理解があると、教育は短くなる。短くなると、現場が折れない。」

佐藤（経理課長）がぽつりと言う。

「前回は、分からないまま本番に行った。今回は、分からないまま行かない。」

宮下が続ける。

「分からない場所が、ダッシュボードに出る。出るから、潰せる。」

その「潰せる」が、自然に「ありがとう」に変わる。

福本がグラスを置いて、遠藤たちのほうを見た。

「正直、ベンダーさんに言うのは気恥ずかしいけど……

今回、こっちが荒れなかったのは、そっちが逃げなかったからだ。ありがとう。」

遠藤が少しだけ照れて言う。

「逃げられない空気でしたから。」

「それが、いい空気だ。」

福本が笑う。

この笑いは、余裕じゃない。信頼だ。

Web側の井上が、深く頭を下げる。

「Web側、結合テストで迷惑かけました。

でも、今回、言い訳を許されないのが逆にありがたかった。

曖昧にして次へ行く癖が、消えました。」

浅見が続く。

「テストを“やったふり”しないって、こういうことなんですね。

ログが残って、証跡が残って、責任が残る。怖いけど、健全です。」

山本が頷く。

「事故るのは、技術じゃなくて、曖昧さだと痛感しました。」

そこへAzureのプロたちが会話にはいってきた。まず、亀渕が口を挟む。

「今回、Azure側の設計で意識したのは、“怖くならない”ことです。」

三宅が補足する。

「監視が見える。スケールが読める。止める判断ができる。クラウドは止まってくれないからこそ、止め方を持っておく。」

小島が笑う。

「祈らない運用、最高です。でも祈らないためには、監視と運用がちゃんと要る。そこは皆さん、ちゃんとやってる。」

この“ちゃんとやってる”が、場に静かな誇りを生む。

誇りは、次の油断を呼ぶ。

そこで、林取締役が立ち上がった。

「今日は、ユーザー側を代表して、二社のベンダーさんにお礼を言わせてください。」

店が静まる。

林の声は柔らかいのに、線がある。

「今回、皆さんは、間に合わせるために人を削らなかった。分からないまま先へ進まなかった。

それを受け止めてくれたのが、2社のベンダーさんでした。」

「ありがとう。今日だけは、心から言わせてください。」

林は深く頭を下げた。

拍手は起きない。

代わりに、全員が静かに頷く。

続いて石塚副社長が、立たずに言った。

立たないのが、彼のやり方だ。

「経営の立場から言います。」

「UATが終わった。ここから先は、もっと厳しい。」

誰も反論できない。

「最後のデータ移行がある。本番稼働後の日々のモニタリングがある。そして月次締め処理がある。」

「今日ここで浮かれていいのは、Readyになったという事実だけです。成功だと思うのは、数字が黙ってからにしましょう。」

その言葉は冷たいのではない。愛がある。未来の自分たちを守る言い方だ。

桐生（私）は、その場の温度を見て思った。

—Readyとは、機能が揃ったことではない。

—テストが通ったことでもない。

—人が、嘘をつかずにこの仕組みを引き受ける覚悟を共有したことだ。

だからこそ、次が怖い。怖いからこそ、進める。

遠藤が、石塚の言葉を受けて言った。

「最後の移行、油断すると必ず事故ります。だから、今夜は喜んでいい。

でも明日からは、淡々と準備しましょう。」

吉田が続ける。

「本番後の問い合わせは、必ず来ます。来るのは悪いことじゃない。

大事なのは、問い合わせを“個人技”で潰さないことです。運用の型に戻しましょう。」

河野が短く言う。

「監視は、安心のためじゃない。異常を早く見つけるためです。
正常を信じない。異常を早く見る。」

清水が、少しだけ真面目な顔で言う。

「PowerBIも、本番後が本番です。数字が喋り始めたら、すぐ気づけるようにしておきます。

黙ってる数字を守るのが、仕事です。」

小野塚が笑う。

「黙ってる数字を守る、いいですね。」

佐藤が頷く。

「数字は黙っていてほしい。でも黙ってる理由を、全員が説明できる状態で。」

上野が、最後に言った。

「よし。今日は終わりにしよう。明日から、また淡々とやる。」

その“淡々”が、全員に刺さる。

15年前の自分たちは、淡々とできなかった。

焦りと恐怖で、何かを誤魔化して、最後に爆発した。

今は違う。

店を出ると、夜は静かだった。

さっきまでの熱が嘘のように、空気は冷たい。

それでも、胸の奥には、まだ火が残っている。

誰かが、独り言のように言った。

「……あとは、数字だな。」

誰も返事をしない。

だが、全員が同じことを思っていた。

UATは終わった。

だが、プロジェクトは、まだ終わっていない。

最後のデータ移行がある。

本番稼働後の日々のモニタリングがある。

そして、月次締め処理がある。

ここから先は、派手な会話はない。

数字が、黙るかどうか。

それだけが、結果になる。

浮かれない。だが、疑わない。

UATの夜に生まれたこの関係を、そのまま持って、私たちは次のフェーズへ進む。

【最終データ移行｜数字が黙るまで、誰も帰れない】

最終のデータ移行日は、2026年1月。正月明けの本番稼働を前提に、準備は年末年始に行う。

カレンダーを見ただけで、誰もが分かっていた。これは、休みを返上するプロジェクトだ。

私（桐生）は、最終移行計画のレビュー会議で言った。

「ここから先は、技術の話じゃない。数字と日付の話です。そして、言い訳が一切きかないフェーズに入ります。」

会議室の空気が、少しだけ張り詰める。

最終移行でやることは、シンプルだ。だが、重い。

・契約残（受注伝票・発注伝票・修理伝票・メンテナンス保守年間契約伝票）と会計データの移行

・在庫評価レポートの出力

・売掛金年齢表、買掛金年齢表の出力

・バランスシートの出力

・CRMとERP、それぞれに必要なデータが正しく流れているかの確認

・不整合がないかの突合

・契約残はPowerBIで再確認する

一つでも曖昧なまま、本番には行かない。経理部門のキーユーザー宮下が、資料をめくりながら言った。

「見る帳票は、もう決まってます。在庫評価、売掛、買掛、BS。これが全部、黙ってればOKですね。」

黒田（IT部門、データ管理担当）が静かに頷く。

「黙ってる数字だけが、正解です。説明が必要な数字は、まだ途中です。」

このやり取りだけで、全員の意識が揃う。最終移行は、説明大会ではない。

年末年始、静かな戦場/12月30日。オフィスは静かだ。だが、この部屋だけは違う。

IT部門から溝道、深沢、黒田、立花と私（桐生）。

そしてユーザー側の山田（営業）、小野塚（物流）、高橋（修理）、佐藤（経理）、宮下（経理）という最低限のキーメンバーだけが集まっている。

「ID登録、終わってます！」

情報システム部のデータ管理担当、黒田が言う。

1月から入社する新規ユーザー分のID登録と権限設定を、年内にすべて終わらせている。

「正月明け初日に、ログインできない人を出さない。それだけは、絶対にやりません。」

黒田の言葉に、

「本当に助かります。本番初日のトラブルは、だいたいIDですから。」と伝えた。

移行は予定通り始まった。最初は、静かすぎるほど静かだった。

契約残。

会計データ。

在庫。

在庫評価レポートが出る。

売掛年齢表が出る。

買掛年齢表が出る。

バランスシートが出る。

経理の佐藤が、しばらく無言で画面を見つめる。

「……問題ないですね。」

黒田が確認する。

「差分、出てませんか？」

「出てません。説明不要です。」

その言葉に、少しだけ空気が緩む。だが、誰も笑わない。まだ終わっていない。

契約残は、移行後にPowerBIで再確認する。

これはUATで決めた、最後の安全装置だ。黒田がダッシュボードを映す。

「ERP側の契約残。CRM側の契約残。一致しています！」

経理財務部門長の森が、念を押す。

「タイミング差は？」

「ありません。更新タイミングも一致しています。」

ここで初めて、全員が一度だけ頷く。だが、その直後だった。

立花が、ログを見つめたまま言った。

「……止まりました….」

全員が一斉に顔を上げる。

「どこだ?」

「ベンダーが開発したe-Commerce用サイトからのデータ連携です。大量データが一気に流れ込んでます。」

遠藤が即座に反応する。

「結合テストでもUATでも、ここは再現してませんよね？」

「してません。この量は、本番相当です。」

一時的に、作業がストップする。時計を見ると、余裕を持って組んだはずのスケジュールが、じわじわ削られていく。

小野塚が、小さく呟く。

「ここまで順調だったのに…」

沈黙の中で、桐生（私）が口を開く。止めるか、切り分けるか

「慌てない。まず切り分けます。」

深沢が頷く。

「連携を一時止めて、影響範囲を確認しましょう。

コアの会計処理と契約残は、もう問題ない。」

黒田が続ける。

「Power BI側も問題なし。この連携は、後続でも切り離せます。」

溝道が確認する。

「正月明けの本番稼働に、致命的な影響は？」

私（桐生）は即答した。

「ない。ただし、このまま放置はしない。年内に原因は潰します。」

“止めないが、妥協もしない”

UATでやってきた判断を、そのまま持ち込む。

年末年始、別ベンダー側と連絡を取り、データ量制御と処理順序を調整する。

派手な修正はない。地味な制御だ。

立花が、深夜に言った。

「流量を制限しました。再開できます。」

再度、移行が進む。誰も拍手しない。誰も声を上げない。ただ、数字が黙っていく。

1月正月明け前日。最後の確認会。桐生が、全員を見渡す。

「契約残は？」

営業部門長の福本が応えた。

「問題なし。PowerBI確認済み！」

「会計側は？」

経理の佐藤が即座に回答する。

「在庫評価、売掛、買掛、BS、すべてOK！」

「CRMとERPの整合は？」

営業の山田が即座に回答する。

「不整合なし。業務側も契約残含め確認済みです！」

桐生（私）は、短く言った。

「行きましょう！」

オフィスを出るとき、溝道が言った。

「15年前だったら、ここで徹夜でしたね。」

上野が少し笑う。

「今は、数字が徹夜してくれました。」

誰もが、その意味を理解している。

準備を重ね、嘘のないテストをしてきたからこそ、今がある。

本番稼働は、2026年正月明け。新しいユーザーがログインし、業務が始まる。

この章の主役は、誰でもない。派手な成功談もない。

ただ、止まらなかったという事実だけが残る。

そしてそれこそが、このプロジェクトの、いちばん大きな勝利だった。

【ステコミ｜本番稼働承認】

データ移行が完了した翌日、会議室には普段とは違う緊張感が漂っていた。

ステコミ。役員、事業責任者、IT統括、経理トップ。“偉い人たち”が揃う場だ。

桐生（私）は、いつもより少しだけ背筋を伸ばしていた。

「本日は、最終データ移行の結果と、本番稼働可否の判断をお願いします！」

スクリーンには、在庫評価レポート、売掛・買掛金の年齢表、バランスシートが並ぶ。説明は最小限だ。数字が語る。

経理役員が口を開く。

「在庫評価、旧システムと差分は？」

佐藤が即答する。

「ありません。評価方法、評価タイミングともに一致しています！」

「売掛・買掛は？」

「年齢表まで含めて一致しています。説明が必要な数字はありません。」

一瞬、間が空く。

その沈黙を、事業責任者が破る。

「契約残は？」

黒田がPower BIを切り替える。

「移行後、ERPとCRMの双方で確認しています。Power BIでの再集計結果も一致しています。」

営業部門長の福本と、課長の山田も頷いた。

「過去の修理履歴も修理伝票からCopilotが呼び出せています。」

修理部門の高橋も付け加えた。

役員の一人が、少し厳しい口調で言った。

「並行稼働はどうする？」

プロジェクトマネージャーの桐生（私）が、迷いなく答える。

「しません。Dynamics 365のCRMからERPへ、データは非機能要件に合致したスピードで流れています。

外部システムとのインターフェースも、本番相当で確認済みです。」

上野が補足する。

「並行稼働をしない前提で、UATと最終移行を設計しています。リスクは洗い出し済みで、対応策も合意しています。」

しばらくの沈黙の後、CIOの宇野が頷いた。

「…いいでしょう。本番稼働に進みましょう。」

その瞬間、誰もガッツポーズはしない。ただ、全員が静かに息を吐いた。

【本番稼働サポート｜課題対応】

2026年1月、正月明け。新しいユーザーがログインする。CRMで入力された伝票系のデータが、ERPへ流れる。

逆にERP側からマスターデータがCRMに流れる。

外部システムとの連携も、非機能要件どおりのスピードで動く。

立花が小さく言った。

「…本番環境思ったより速いですね。」

Dynamics 365ベンダーの遠藤リーダーが返す。

「結合テストとUATで、嘘つかなかった結果です。」

アプリケーション担当の深沢が付け加えた。

「日々、課題は出る。だが、驚くことはない。

課題管理表に記載され、優先度が付けられ、誰がいつ対応するかが決まる。その流れが、自然に回っている。」

黒田が、ぽつりと言った。

「課題が出てるのに、怖くないですね。」

「見えてる課題は、もう半分解決してますから。プロジェクトでは、見えないものが怖いんですよね。

黒田さん、データの可視化、本当に助かったよ。まぢで、ありがとうね。」

心から出た桐生（私）の声だった。

【月次締め処理】

本番稼働後、時間はあっという間に流れる。

Sales Agentが、営業の提案を支援する。

Payable Agentが、買掛処理を静かに助ける。

Expense Agentが、経費精算の無駄を減らす。

Repair Agentが、修理履歴から、適切なTo-Doをメカニックにタイムリーに返す。

営業責任者の福本が言う。

「正直、最初はコンサンプションが心配だったよ。コスト結構いっちゃうんじゃないかって。」

経理部長の森も頷く。

「でも、想像以上に使われてます。むしろ、使わないと。もう前には戻れない….」

一方で、情報システム部の上野が冷静に言う。

「Agentが動いてますが、Entra ID、Defender、Intune、Purviewが裏で効いてます。情報漏洩リスクは、むしろ下がっています。」

CIOの宇野が興味深そうに聞く。

「上野さん、当社はMicrosoft 365のE5プランを使っているが、生産性向上と、セキュリティー対策の為に、E7にしてもいいんじゃないか？」

その一言に、場が少しざわつく。

これは、評価が“検討”から“投資”に変わった瞬間だった。

【リアルタイム経営の衝撃】

月次決算。1か月目。2か月目。3か月目。締め処理は、明らかにはやくなっている。

「3月は5日ほど、前倒しできてます！」

経理部門の佐藤、宮下（佐藤課長の部下）の声には、誇りがにじむ。

「Power BIで必要なレポートが全部見える。集める時間が、考える時間に変わりました。物凄く便利です。」

販売計画も、CRMとERPとAIが連動する。

売上予想Copilotが、過去と現在をつなぐ。

営業部長の福本が言う。

「まだ完璧じゃない。でも、もう前の仕組みには戻れないよ。まぢで、Copilotヤバイって。」

会社設立以来の快挙/3月31日。年度末。

販売、仕入、生産はタイムリーに年度締めができた。

棚卸は、サイクルカウントで前倒しに動き出していた。そして月末。

「まぢか…在庫、リアルタイムで締まってます！」

物流部門の小野塚が呟く。

それは、会社設立以来、初めてのことだった。

桐生（私）は、その報告を聞いても大きく反応しなかった。ただ、一言だけ言った。

「やっと、数字が現場に追いつきましたね。来週は経理の締めですね。」

マネジメントから、改めて求められる。

「AIを活用した成果は？」「投資対効果は？」「今後、どこまで広げられる？」

営業や経理部門からは、ポジティブな声が上がる。

「そろそろ、Copilotは全社で使うべきだろ？」「システムユーザー以外にも展開できないか？」

一方で、別の声もある。

「AIに仕事を取られるんじゃないか？」「自分の役割はどう変わるのか？」

プロジェクトチームは、その両方を受け止めていた。

深沢（IT部門のアプリ責任者）が、最後に言った。

「今回のゴールは、生産性向上じゃない。付加価値をどう作るか、これからが本番だね。」

溝道（IT部門開発責任者）が頷く。

「品質をなんとか保てたから、次の議論ができる。それだけで、このプロジェクトは成功だよ。」

本番稼働から1か月。

変更要求に対応する余力も生まれ、プロジェクトチームとベンダーは、次の改善に向けて動き続けている。

この物語に、派手なヒーローはいない。だが、品質の良さだけは、全員が知っている。

そしてそれは、十五年前には、決して得られなかった感触だった。

【慰労の夜｜記憶が未来に追いついた】

店は、駅から少し外れた古い居酒屋だった。カウンターも、座敷も、どこか年季が入っている。

懐かしい昭和の雰囲気だ。

「……島名さんと、一緒に祝いたかったなぁ。」

そう言って佐藤がグラスを置いた。

今日の席には、これまで物語に登場してきた顔ぶれが、ほぼ全員揃っている。

福本、山田、三上、新井、小野塚、田中、上野、桐生、深沢、溝道、黒田、立花、佐藤、森、宇野CIO、村上CFO。林取締役。石塚副社長。

業務委託をしたベンダー側からは遠藤、淵山、宮治、吉田、井上。

そして、少し遅れて現れたのが、鈴木元社長だった。

「いやあ、もう現場に呼ばれないかと思ってたよ。」

そう言って笑う鈴木元社長に、全員が一瞬だけ背筋を伸ばし、それから力を抜いた。

「今日は慰労会ですから。」

私（桐生）がそういうと、鈴木は頷いた。

「それなら、肩書きはいらないな。みんな、業務システム刷新プロジェクトの大成功、本当におめでとう！」

15年前の話は、もう武勇伝ではなかった。最初に出た話題は、やはり15年前だった。

深沢が切り出した。

「別メーカーのCRMとERPの同時に入れ替え、今思うと狂気ですよね。

いやぁ、それにしても、Dynamics 365めちゃくちゃ進化しましたね。Power Platformとかバケモンでしょ。」

営業の山田が笑う。

「でも、昔のあのとんでもない苦労があっての今回だよね。」

溝道が静かに返す。

財務経理の部門長、森がグラスを傾けながら言う。

「15年前は、数字がずっと喋ってた。今回は、数字が黙ってた。それが一番の違いですね。」

CFOの村上が、ゆっくり頷く。

「黙ってる数字は、いい数字だ。」

その一言に、全員が静かに納得する。

ふと、佐藤が言った。

「……島名さん、今日いないですね。」

空気が一瞬、柔らかく変わる。

鈴木が、少しだけ目を細めた。

「引退したあとも、彼女よく言ってたよ。“あの人たち、ちゃんと人の顔を見てるのだろうか？”ってね。」

新井工場長が、ぽつりと言う。

「今回、誰も倒れなかったのは、あの頃の記憶が、どこかで効いていたからだろうな。」

誰も名前を補足しなかった。それで、十分だった。

その空気を壊さないように、少し離れた席でその会話を聞いていた林取締役は、話の文脈を遮らないように、間を置いてから口を開いた。

「理由が何であれ、今回は“無理をさせなかった”。私は、それが一番よかったと思っています。」

評価でも、総括でもない。ただ、事実を静かに確認するような言い方だった。

石塚副社長は、林の言葉を受けて、グラスを置きながら短く続けた。

「正直に言えば、“頑張った”とは言いにくい。でも、“壊さなかった”とは言える。」

その言葉に、誰かが小さく息を吐いた。

福本が、何も言わずに頷く。

山田も、それを見て杯を口に運んだ。

おしぼりを畳む音がして、誰かが鍋に手を伸ばす。

会話は、そこで一度、自然に切り替わった。

「井上さん、最近どうなの？e-Commerceビジネスって成長分野だよね？」

物流部門の小野塚が聞く。

「おかげ様で、バタバタしておりますが売上は順調です。」

井上が応え、そして続けた。

「e-Commerceサイトの結合テストのバグ問題。ご迷惑をおかけしました。

あの経験が今、本当に活きています。皆さん、本当にありがとうございました。あの時は本当に恥ずかしくて…」

「そかそか、あの時は、本当に大変だったね。」と小野塚がフォローする。

流石だ。物流担当は、心も運ぶのか。

会社には屋台骨を支える人材がいる。

みんなのおかげで、システムは本稼働になったんだな。桐生は改めて感じた。

「メンバー全員との時間。今振り返ると、苦しかったけど、本当に貴重な体験だったよなぁ。みんな持ち場持ち場で頑張ったさ。」

深沢が、全員の顔を見渡す。

「話は変わるけど、AIエージェント、普通に同僚ですよね。」と、山田。

「でも、AIは島名さんみたいにお茶をいれてくれないじゃん。」と、森。

佐藤が笑う。

「これから、もっとAI増やしていかなきゃだね。Payable Agent、文句言わないし、夜中に止まらないし。」

福本も続いた。

「スマートフォンに、Copilot Sales Agentから明日一日の行動指針が届いてる。

昨日顧客との懇親会の時も、AIが世界10カ国の売上見込みを集計して、さくっと教えてくれたよ。四半期決算、安泰だわ。

Sales Agentめちゃ便利。時代が変わったよなぁ。」

黒田が、少し真面目な顔で言う。

「でも、Entra ID、Defender、Intune、Purviewが裏で全部見てます。自由になった分、責任は減ってません。」

上野が頷く。

「むしろ、重くなった。….そろそろ、本気でE7だな。」

上野は続けた。

「15年前、私たちはデータが繋がらないことに絶望していた。

だが2026年の今、私たちは「すべてが繋がりすぎている」ことへの、言葉にできない薄ら寒い不安を抱えている。

Microsoft Dataverseに集約された、会社の全神経。Microsoft Fabricが暴き出した、15年分の成功と失敗の全記録。

それらがAIエージェントという「知能」を得て自律的に動き出したとき、

果たして「ハンドル」を握っているのは本当に人間なのだろうか？

……セキュリティの境界線が、もう目に見えないんだよ。」

溝道が、険しい表情で続けた。

「かつてはオンプレミスの物理的な壁（ファイアウォール）が情報を守っていた。

しかし今は、IDひとつ、AIへのプロンプト1つで、会社の心臓部までが晒される。」

宮治が声を挟む。

「そう言えば、Microsoft AI Tour Tokyoでも、Agent365紹介されていましたね。」

淵山が続ける。

「知り合いの室長が、Microsoft AI Tour Tokyoの実況中継blog書いてた。

フロンティア組織だっけ？凄い時代になったもんですね。」

遠藤も言った。

「いやぁ、西脇さんのデモンストレーションヤバかった。決算報告説明会、あれでやりません？」

経理部門の佐藤、宮下、森が興味津々に室長blogを検索し始めた。

溝道が、冗談めかして言った。

「2040年って、どうなってるんですかね？」

深沢が考える。

「UI、もう無いかもしれないですね。画面触るの、逆に遅いって言われてそう。」

黒田が続ける。

「全部、AIに話しかけたら終わり。でも……」

鈴木が、静かに言葉を挟む。

「それでも、決めるのは人だろ。」

桐生（私）も頷いた。

「AIは提案する。でも、引き受けない。」

上野が、グラスを置いて言う。

「だから2040年も、人は迷ってると思います。でも、迷えるってことは、支配されてないってことです。」

福本が続ける。

「AIが賢くなればなるほど、悪意もまた『賢い知能』を纏って忍び寄ってくる。

俺たちが恐れていたのは『仕事がなくなること』だった。

でも、今本当に恐ろしいのは、システムが『正解』を出しすぎることで、

人間が思考のラストワンマイルを放棄してしまうことじゃないのかな？」

時間は、いつの間にか過ぎていた。

「じゃあ、そろそろ。」

誰かが立ち上がる。

店の外は、少しだけ春の匂いがした。

その問いは、誰の答えも待たずに、夜に溶けていった。

【2040年、私たちはどんな世界に生きているのだろうか？】

UIは消え、AIはさらに賢くなり、多くの判断は、システムやエージェントが肩代わりしているかもしれない。

けれど私（桐生）は、未来のプロジェクトが「正しさ」よりも「引き受け方」を問う場であってほしいと、いまも思っている。

AIは提案する。最適解も、代替案も、瞬時に示す。

だが、それを選び、責任として引き受けることまでは、しない。

15年前も、いまも、そしておそらく2040年も変わらないのは、そこだ。

技術が進めば進むほど、人は「考えなくてよくなる」のではなく、

「考えた結果を引き受ける場面」が、より鮮明になる。

この物語は、成功談でも、教訓集でもありません。

次にあなたが、プロジェクトで迷ったとき、判断を先送りしたくなったとき、「正しい答え」にすがりたくなったときに、

ふと、思い出してもらえればそれでいい。

かつて、数字より先に人を見ていた誰かがいたことを。

そして、AIがどれだけ賢くなっても、

最後にハンドルを握るのは、人であるということを。

【DX365LIFE｜1年間の感謝を込めて】

これは、答えを示すための物語ではありません。問いを、次の現場へ持ち帰るための記録です。

FY25の最後に、この物語をここまで読んでくださった皆さまに、心から感謝します。

AIで便利になっていく時代だからこそ、

プロジェクトで苦楽を共にした仲間との時間を、

改めて思い出すきっかけになればという思いで書きました。

それでは、また。次の現場で。次の問いとともに。

以上、室長でした。