売上データはズレても分析できる。でも経理は1円もズレが許されない～AI時代のシステム開発で本当に重要なのは「開発」ではない～
ニチレイがサーバー攻撃を受けて、業務が一時停止したことを題材に、システム開発と運用・保守における見落としがちな考え方を整理します。AIの台頭によってシステム開発コストが大きく下がりましたが、「その後」を考えて開発できているでしょうか。
サイバー攻撃を受けたニチレイは数日で一部業務を再開
前回の記事では、ニチレイがサイバー攻撃を受け、システム障害が起きた事例について、解説しました。
ニチレイが数日で物流を再開できた理由を考えているうちに、一つの疑問に行き着きました。
「AIでコードを書ける時代なのに、なぜ復旧はこれほど難しいのか。」
AIのおかげでコードを書く時間は劇的に短くなりました。
しかし、システム開発で本当に難しいのは、コードを書くことではありません。
システムを運用し続けることです。
ニチレイのシステム障害を見て、そのことを改めて実感しました。
今回は、その理由を私自身の経験を交えて整理します。
AIによってシステム開発は劇的に変わった
現代は、AIが大量のプログラムを一気に書ける時代になりました。
様々な種類のAIが進化を続けており、
- Cursor
- Claude Code
- GitHub Copilot
といったAIを利用することで、
「非エンジニアでもシステムを作れる」
時代になりました。
中小企業はなぜデータ分析基盤導入が難しいのか
最近はSnowflake（クラウド型データ分析基盤）などのSaaSを利用したデータ分析基盤が増えています。
しかし、こうした事例をみると、
「SaaSは便利だから導入するもの」
とだけ思われることがあります。
しかし実際には、
運用担当者を増やす代わりに、システム利用料を支払っている
という側面があります。
- 監視
- バックアップ
- API管理
- 障害対応
- アップデート
これらを自社でやる代わりに、 SaaSベンダーへ委託しているのです。
高額なシステム利用料を人件費に置き換える
一方、中小企業では費用を抑えるためPythonなどで自製するケースも多く、
その代わり
- 設計
- 保守
- 障害対応
まで自社で行う必要があります。
ここが大企業との大きな違いです。
しかし、システムの完成に至るまでには、開発現場と経営層で大きなギャップがあるため、開発が難航することが多いです。
また、完成しても運用・保守の負担が想像以上に重いことを痛感し、データ分析基盤のプロジェクトがとん挫することも珍しくありません。
大企業であれば何百万というシステム利用料を払える、零細企業であればExcel分析で十分、ですが、中小企業だと事情が異なります。
- 高額なシステム利用料は払えない
- Excelで管理できないほどデータが蓄積されている
この結果、システム内製化→難しくて断念、となるのです。
私は”開発”より難しいものを見てきた
私は通販会社で売上・入金を管理するシステムの開発を行っていました。
BigQueryというクラウドサービスを使って、大量データを処理するシステムです。
私が開発したシステムでは、複数システムからCSVを取得し、Pythonで加工してBigQueryへ取り込み、集計していました。
その開発では、自社開発ならではの現場と上司との認識のギャップを経験しました。
私が経験した経理システム
通販会社では広告運用の分析のために、マーケティング部署が分析システムを自社開発していました。
一方、経理用の売上・入金データは、基本的に通販用のカートシステム上で管理していました。
こうした中、売上の増加に伴い、決済時にイレギュラーな対応が増えてきたため、別途、経理用の集計システムを自社開発する運びとなりました。
ここで、マーケティング用データ集計と経理用データ集計で大きな違いがあります。
経理データの集計は厳密な集計が求められる
マーケティングの分析では、傾向をつかむのが大事である一方、
経理用データは税務・内部統制に関わってくるので、正確な集計が必要です。
カートシステムから出力されるデータは必ずしも完全ではありません。
- 一部のデータが重複
- 未入金データの放置
- 修正データの集計漏れ
といったデータの崩れを網羅的に修正するプログラムを組む必要があります。
つまり、
売上データはズレても分析できる。でも経理は1円もズレが許されない
1円でもズレれば決算書が合わず、原因調査からやり直しになります。
このため、集計前にデータを加工するデータクレンジングに膨大な時間を費やしました。
こうしたケースでは、開発に直接携わらない人からは、集計するだけなのになぜ開発がそんなに難しいのか？という疑問を持たれることがあり、開発現場と認識に大きなギャップが生まれてしまいます。
システムは、利用者によって求められる品質が全く違う
という点を、開発に関わるすべての人に共通認識として持つ必要があります。
システムは作れば終わりではない
ここで、実際にシステム開発や運用をしたことがない人が勘違いしていることをお伝えします。
自社開発システムの大変さは、開発だけではありません。
システムの運用・保守負担は想像以上に大きい
ということについて、開発段階から具体的なイメージを働かせなくてはなりません。
システムの完成は、
要件定義
↓
設計
↓
開発
↓
完成
ではありません。実際は、
完成
↓
運用
↓
障害
↓
保守
↓
改善
↓
引継ぎ
↓
システム更新
↓
老朽化
↓
リプレース
といったように、システム開発が完成した後も対応が必要になってきます。
日々のシステム運用では、完全自動化でない限り、データ投入やリザルト画面の確認など、定例業務が発生するでしょうし、
- 障害時の復旧作業
- 連動システムの更新に伴う改修
- 運用担当者の突然の人事異動
など、事前にスケジューリングするのが難しい対応も発生します。
こうしたイレギュラーな対応は、システム担当者にとって非常にストレスがかかります。
先ほどの売上・入金管理システムを例にとると、決算申告のタイミングでシステムの集計ミスが分かった時に、
- エラーを特定して、システムの改修を優先するのか
- システム利用をあきらめて手作業で集計するのか
といった想定を含めて、システムを設計しておかなければ取り返しがつかなくなります。
データ分析基盤はなぜ難しいのか
私はIT企業で顧客企業のデータ分析基盤の構築を行った経験もありますので、ここからは、中小企業でも利用が進みつつあるデータ分析基盤の構築について解説します。
クラウドの台頭によって、データ分析基盤の構築コストが一気に下がった現代ですが、構築に際してボトルネックとなるポイントがいくつかあります。
データ分析基盤とは
そもそも、データ分析基盤とは何なのか？
一言でいうと、
社内のデータを一つにまとめて分析しやすい形に加工しておくことで、データ分析をスムーズに行うためのシステムです。
中小企業のデータは、
- 会計データは経理部
- 広告データはマーケティング部
- 在庫データは製造部
といったように、各部署ごとに管理しています。
これらを集約し、まとめて分析できるようにすることで、多角的な分析が可能になります。
例えば、原価率が上昇した場合、会計データだけでは「原価率が上昇しました」しかわかりません。
一方、データ分析基盤を導入すると、
- 試供品の無料配布の増加
- 円安による原材料の輸入単価の上昇
- 歩留まり率の低下
など、原価の変動要因を詳細に分析できるようになり、効果的な経営方針の策定につながります。
データの流れ
まず、データ分析基盤のイメージが湧かない方向けに、データの流れを大まかにお伝えします。
各部署のシステム（EC、物流、会計など）
↓
データクレンジング（データを連携用のフォーマットに加工）
↓
データレイクへデータ連携（個別のデータを一つのシステムにまとめる）
↓
データウェアハウスに格納（分析用データに加工）
↓
BIツールやレポート用にデータを出力
データ分析基盤を構築する際は、データを一つに集めればいいというものではありません。
実際はCSVやAPIで連携
データウェアハウスというシステムにデータを集約するには、各種データを連携させる必要があります。
連携するデータはそれぞれのシステムのフォーマットで出力されるので、それを一つのシステムに集約するために加工する必要があります。
例えば、部署ごとに使っているSaaSが異なります。
- EC
- 広告
- 物流
- 会計
これらのシステム要件を把握する必要があります。
また、データの加工・格納方法についても、
- システムからCSVをダウンロード
- SaaSとAPI連携
- ExcelファイルをPythonで取り込み
など、それぞれのシステムに合わせる必要があります。
だからエラーは必ず起きる
データ連携は毎回うまくいくとは限りません。
- APIタイムアウト
- SaaSのシステム障害
- Excelファイルの格納忘れ
- CSVファイルの文字化け
今まで成功していたのに、突然、連携がうまくいかないこともあります。
エラーのパターンを認識するたびに、システムごとに設計しているデータ取り込み・加工プログラムを改修することは根気のいる作業です。
だから運用設計が必要
運用を考えずにシステム開発を進めると、稼働後にエラーが起きるたびに対応しなければなりません。
結果として、システムの改修が二度手間、三度手間になるだけでなく、工数を削減するはずのシステムに工数を奪われることになりかねません。
このため、開発段階から、運用・保守を想定した設計をすることが必要です。
運用設計こそシステム設計
データ基盤は「どう取得するか」よりも失敗した場合に、
- いつ
- どうやって
気づく仕様にするかがとても大事です。
一番最悪なケースは、
間違ったデータがそのまま利用されて、重要な経営判断をミスリードしてしまう
ことだからです。
分析担当者がデータの違和感に気づいてからでは、対応が遅くなってしまう場合があります。
システムがデータを連携する際や、毎朝にSlackで通知を出す設定を加えておくなど、早期にエラーに気づける設計にすることが重要です。
また、今まで経験していないエラーが出ても検知できる設計にしておかないと、エラーを長期間放置することにつながります。
こうした設計を組み込むためには、AIに頼るだけでなく、エンジニアの経験や想像力を働かせる必要があります。
さらに、エラーが起きた場合の対応として、
- システム全体を止めるのか？
- システム利用者への周知はどうするのか？
- いつまでに対応する必要があるのか？
などのシミュレーションをしておくことも開発段階で求められます。
ニチレイのような基幹システムでも重要なのは「障害をゼロにすること」ではなく、「障害が起きてもすぐ気付いて、安全に復旧できること」なのです。
AIでは決められないこと
AIはコード生成は得意です。
一方で、
・運用ルール ・責任分界 ・権限設計 ・部署間調整
までは決めてくれません。
しかし、システムを導入する会社ごとに必要なシステム要件は異なります。
・担当者が退職したら？ ・CSVの仕様が変わったら？ ・APIが廃止されたら？ ・データが欠損したら？ ・Slack通知が止まったら？
AIは汎用的な結果を返すことが多いため、AIのコードをもとに、会社仕様にカスタマイズする必要があります。
もちろん、カスタマイズにAIを使ってもいいですが、そのためにも、社内の運用・保守体制をどうするべきかについて、関係部署と調整することは人間が担う大事な仕事です。
設計の段階で、運用・保守の方針を定めておかなければ、後から大規模な改修が必要になることがあります。
「AIに聞けば楽にシステム開発ができる」という先入観のもと、安易に大きなシステム開発に着手すると、逆に労力が増えるリスクもあることを念頭に開発を進める必要があります。
つまり、AIはコードは書けても、「会社の運営」は設計できません。
まとめ
今回は、エンジニアリング経験をもとに、経理担当者がぜひ習得していただきたいエンジニアリング的思考についてお伝えしました。
AIによってコードを書く時間は短くなりました。
しかし、
止めない 壊さない 引き継げる 長く運営できる
こうした仕組みを考えるのは、今も人間の仕事です。
ニチレイの事例は、「AIで開発が速くなる時代」だからこそ、運用設計や復旧体制の重要性がこれまで以上に高まっていることを改めて教えてくれました。
AI時代になって価値が高まるのは、コードを書く人ではなく、「システムを運営できる人」なのかもしれません。
さらに深掘りする：関連記事
別の記事では、業務効率化やシステム開発において意識しておきたいことを経験をもとに解説しています。
システム開発
以下の記事では、AIによって開発コストが下がった中で、陥りやすいシステム開発失敗の共通点について解説しています。
以下の記事では、通販会社で膨大な量の売上・入金データの突合システムをBigQueryで構築した実体験と大規模システム構築でぶち当たる悩みについて投稿しています。
業務効率化
以下の記事では、会計業務におけるRPA導入における失敗談とその背景や原因について解説しています。
以下の記事では、業務効率化で意識しておきたい、保守負担とのトレードオフについても解説しています。
以下の記事では、会計業務におけるデータの二重入力をデータ連携により効率化したエピソードを紹介しています。
データ分析
以下の記事では、データドリブン経営を進めるうえでのポイントを、有名なFPSゲームAPEXのデータ分析を参考に解説しています。