ニトリHDの基幹システムOCI移行を読む——成果は「4倍」より「始業に間に合うか」で測る

業務システム・基幹システム開発公開日:2026年9月17日最終更新日:2026年9月20日
徐 聖博
徐 聖博

株式会社シンシア 代表取締役社長

Share
目次開く
  1. 要点(発表内容の事実のみ)
  2. 成果を「業務の締め切り」で定義している
  3. アプリを据え置き、DBに投資を集中させた判断
  4. SIer・開発会社と発注側が持ち帰るべきこと
  5. まとめ

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

日本オラクルが2026年9月15日、ニトリホールディングス(以下ニトリHD)の基幹システムを Oracle Cloud Infrastructure(OCI)へ移行し、本番稼働を始めたと発表しました。本記事では、この基幹システムのクラウド移行事例で公表された事実を整理し、受託開発の立場から「移行の成果を何で測るか」を論じます。

要点(発表内容の事実のみ)

  • 従来はアプリケーションをオンプレミスの仮想化基盤、データベースをオンプレミスの Oracle AI Database で運用していた。課題はハードウェア保守期限の満了、処理能力不足、春の需要期の負荷、内製の需要予測計算・自動発注処理の長時間化
  • 移行先は、DB が Oracle Exadata Database Service、アプリ基盤が Oracle Cloud VMware Solution。Oracle Data Guard で東京・大阪の2リージョン間を同期する DR 構成を組んだ
  • 主要処理の性能は旧環境比で最大約4倍。日次の需要予測計算は、始業に間に合わない問題を抱えていた6時間弱から1時間半に短縮
  • DR 環境への切り替え運用に要する時間は12時間から3時間に。2026年春の需要期も安定稼働を続けている
  • コスト削減は主目的ではなかったが、運用コストは当初見込みの約8割。支援は SCSK(プロジェクト推進とアプリ基盤構築)とアシスト(DB基盤の検討・移行)

成果を「業務の締め切り」で定義している

私がこの発表で一番注目したのは「最大約4倍」ではなく、「始業に間に合わない」という一文です。基幹システムのクラウド移行の相談を受託の現場で受けると、要件は「今より速く」「落ちないように」で止まりがちです。しかしニトリHDの課題設定は、需要予測の計算が翌朝の業務開始に間に合うかどうか、という業務側の締め切りでした。6時間弱が1時間半になった価値は、処理時間の比率ではなく、発注や配送の判断を始められる時刻が前に動いたことにあります。

研究をしていた頃から、ベンチマークの平均値だけで性能を語ると実運用とずれることは何度も見てきました。基幹システムで効くのは平均ではなく、繁忙期のピークと締め切り時刻です。春の需要期を乗り切ったことを成果に並べているのは、この点を正しく押さえていると私は読みました。移行計画に繁忙期をどう置くかは、Currysが繁忙期の手前でクラウド移行を止めた事例も参考になります。

アプリを据え置き、DBに投資を集中させた判断

構成を見ると、アプリ基盤は VMware の仮想化環境をそのままクラウドへ移す形で、性能課題の中心だった DB に Exadata を充てています。作る側から見ると、これは改修範囲を絞る判断です。アプリを作り直す移行はコストも期間も読みにくくなります。ボトルネックが DB 待機にあると分かっているなら、そこに投資を集中するのは合理的です。

一方で、特定ベンダーの DB 最適化に深く寄せるほど、将来の選択肢は狭まります。私たち Xincere は AWS を中心に構築しており、どちらが正しいという話ではありません。大事なのは、ロックインを「避けるか」ではなく「どこで受け入れるか」を決めて選ぶことです。判断の整理にはベンダーロックインの発生パターンと脱却費用の見積もり方をまとめています。

SIer・開発会社と発注側が持ち帰るべきこと

開発会社の経営側として見ると、この案件はアプリ基盤(SCSK)と DB(アシスト)で支援の役割を分けています。基幹刷新を1社で丸ごと受けるより、得意領域で責任範囲を切る体制のほうが、発注側にとってもリスクの所在が明確になります。自社がどの層を担い、どの層を専門会社と組むのかは、受注の勝ち筋そのものです。

発注側に持ち帰ってほしいのは、要件定義の書き方です。「性能◯倍」ではなく、次の3つを数字で書く。

  1. 締め切り時刻: どの処理が何時までに終わる必要があるか
  2. ピーク: 繁忙期に何倍の負荷がかかるか
  3. 復旧時間: DR 切り替えを何時間で終える必要があるか(ニトリHDは12時間→3時間)

コストの約8割も「削減を主目的にしなかった」結果として出ている点に注意が必要です。コストを先に目標にすると、締め切りやピークの要件が削られがちです。刷新の順番と、何年目に何を測るかは、TIAAの基幹システム刷新の事例とあわせて読むと整理しやすいはずです。基幹システムそのものの基本は基幹システムとはを、基幹を中枢に据えたDXの順番は雲天化集団のSAP ERP事例の論評を参照してください。

まとめ

ニトリHDの事例で学ぶべきなのは、クラウドの銘柄ではなく、移行の成果を「始業に間に合うか」「繁忙期に落ちないか」「何時間で戻せるか」という業務の言葉で定義した点です。基幹システムのクラウド移行を検討しているなら、まず自社の締め切り時刻とピークを数字で書き出すところから始めることをおすすめします。

出典: ニトリホールディングス、店舗販売や配送業務を支える基幹システムをOracle Cloud Infrastructureに移行(日本オラクル, 2026-09-15)

Share

そのまま使えるチェックリスト

既存システムを残したまま進めるときの確認項目

全面刷新を前提にしない場合、先に決めるのは機能ではなくデータの持ち方です。

  • どのシステムのデータを「正」とするか
  • 同期が失敗したとき、どう復旧するか
  • 連携方式の制約(API/CSV/DB直/手作業)
  • 既存システムのベンダーに仕様を聞けるか
  • 止められない処理と、その締め時間
  • 過去データをどこまで移行するか
  • 例外処理の一覧(標準フローから外れる条件)
この続きをPDFで持ち帰る →

PDF版には要件定義ヒアリングシート全項目(目的・業務・データ・非機能・体制)を収録しています。

シンシアへのご相談

自社のAI活用・開発体制について相談する

AIをどこまで内製するか、どの業務から着手するか、体制をどう組むか。開発会社・SIer・事業会社の開発部門の方からのご相談を無料で承っています。同じ問題を自社でも解いている立場としてお話しします。

AI活用の進め方を相談する

まだ検討段階の方は 質問だけでもOK(電話番号は任意)

徐 聖博のプロフィール写真

この記事の書き手に直接相談する

徐 聖博株式会社シンシア 代表取締役社長

記事の内容について、より具体的に自社のケースで聞きたいことがあれば、徐 聖博を指名してご相談いただけます。営業担当ではなく、 実際に手を動かしている本人が回答します。

シンシアの開発事例

株式会社Atsumell様|サービスを止めずにデータ基盤を刷新したBPマッチングプラットフォームの開発事例

約11ヶ月・のべ4名のリレーで、機能開発を止めることなく基盤の刷新を完了しました。 参画時期の重なりは最大2〜3名で、メンバーは1ヶ月の短期集中から5ヶ月の継続稼働までさまざまです。それでも積み上げが効いたのは、先に入ったメンバーが構造を残していたからでした。2025年7月に導入された Repository 層の上で、半年後に別のメンバーが移行作業を進めています。認可条件はコード上の仕様コメントとして、スナップショット方式はアーキテクチャドキュメントとして残り、いずれも「引き継いだ人が読んで分かる」形になっています。 この期間に手掛けた業務機能は、協力会社のラベル分類機能、パートナー企業管理画面、CSV による一括招待とデータ出力、案件辞退フロー、ステータス変更通知メールなど多岐にわたります。基盤刷新と機能開発は、どちらかを止めて行ったものではありません。 大規模な基盤刷新は「一度止めて作り直す」以外にも方法があります。呼び出し側を壊さない層を挟み、テーブル単位で少しずつ移し、移行と改善を混ぜない。この3つを守れば、リリースを止めずに土台は入れ替えられます。事業を止められないプロダクトほど、この進め方の価値が出ます。 この事例からの示唆 稼働中のサービスでも基盤は入れ替えられる。 前提は、呼び出し側の契約(戻り値の形)を保つ中間層を挟むこと、移行単位をテーブルや画面まで小さく割ること、そして移行と機能改善を同じコミットに混ぜないことの3点です。この3つが崩れると、不具合が出たときに原因が移行なのか改善なのか切り分けられなくなり、結果として一度止めるしかなくなります。 メンバーが入れ替わる前提の体制では、成果物より「残る構造」が価値になる。 短期参画のエンジニアを増やしても積み上がらないプロジェクトは、設計判断が個人の記憶に閉じていることが原因であるケースが多いです。この事例では、認可条件をコード上の仕様コメントとして、データ設計をアーキテクチャドキュメントとして残す運用を徹底しました。開発体制の失敗パターンについてはシステム開発の失敗から立て直す方法でも整理しています。 要件が固まりきらない領域ほど、データ設計で制約を表現する。 「協力会社が人材情報を編集したら応募内容が変わってしまう」といった問題は、運用ルールやUIの注意書きでは再発します。スキーマとトリガーで表現すれば、アプリ側の実装漏れがあっても壊れません。要件を仕様に落とす工程そのものについては要件定義の進め方を参照してください。 よくある質問 Q. 稼働中のサービスを止めずに基盤刷新はできますか。 A. できます。この事例では約11ヶ月にわたり、機能リリースを継続しながらデータアクセス基盤の移行と主キー変更まで実施しました。ただし「一斉に切り替える」やり方では現実的に困難で、呼び出し側を壊さない中間層を用意して段階移行する設計が前提になります。 Q. 途中でメンバーが入れ替わる体制でも品質は保てますか。 A. 設計判断がドキュメントとコードに残っていれば保てます。この事例では参画時期の重なりが最大2〜3名、1ヶ月だけの参画者もいる体制で、前任の導入した層の上に後任が半年後の移行作業を積み上げています。 Q. どのくらいの規模・期間の支援ですか。 A. 約11ヶ月、のべ4名(同時稼働は最大2〜3名)です。プロジェクトの規模や費用感の考え方はシステム開発とはで解説しています。 関連する支援領域 システム刷新の進め方|検討・計画から移行までの方法 — 稼働中システムを止めずに刷新する判断基準 業務システム開発の要件定義とは?進め方・手順を7ステップで解説 — 要件を仕様に落とす工程 システム開発の失敗から立て直す方法 — 体制・引き継ぎで詰まったときの選択肢 同じように「稼働を止められないプロダクトの基盤を作り替えたい」という課題をお持ちでしたら、開発のご相談からお問い合わせください。現状のコードとデータ構造を確認したうえで、段階移行の設計からご一緒します。

株式会社Atsumellの事例を読む →

この記事が役に立ったら、Google で優先表示を

Google 検索の「優先するソース」に blog.xincere.jp を追加すると、シンシアの新着記事がトップニュースなどで見つけやすくなります。

Google で優先ソースに追加

著者について

徐 聖博のプロフィール写真
徐 聖博
株式会社シンシア 代表取締役社長

株式会社シンシア(Xincere, Inc.)代表取締役。中国生まれ・3歳から日本で育ち、日本語・中国語・英語を操るトリリンガル。大学院でコンピュータサイエンス(進化型ニューラルネットワーク)を研究し、GREE・メドレー・カウンティア・Indeed Japan などで検索エンジン開発やスタートアップの立ち上げ・グロースを経験。2020年に「人の価値をテクノロジーで最大化する」という想いでシンシアを創業した。エンジニア歴15年以上、代表でありながらほぼ毎日コードを書く現役エンジニアとして、基幹システム開発からAIエージェント活用まで顧客の事業成長に並走している。創業に込めた思いはnoteの創業ストーリーに綴っている。

人気記事

    お問い合わせ

    システム開発やAI推進についてのご相談はこちらから

    無料相談を予約する