【PM】システム障害の背後にあるもの：江崎グリコの事例から妄想【研究】
◆はじめに
2024年、江崎グリコは大規模なシステム障害に見舞われました。現場の方々や関係者の皆様、本当にお疲れさまです…。
私自身、ITコンサルタントとして、また、同じような境遇を経験した者として、この事態の原因や現場の苦しみを妄想してみました。
正直、自分の炎上経験を重ねて吐き出してるだけなので、世の中そういうプロジェクトもあるんだ、くらいに読んでいただけると幸いです。
本件をご存知ない方は、ご隠居_むらたんさんの記事で概要をご覧くださいませ。とてもきれいにまとまっていて、おもしろい記事でした
◆妄想① システムと業務の理解のギャップは、新システムへの移行を加速度的に困難にする
- プロジェクトの進行中に問題がどんどん顕在化することがある
発注側が業務を熟知し、主体となってシステム開発やプロジェクトを進めることが理想的だが、現実にはそれが難しい。
新システムの方針立案時に、移行後の費用対効果が試算され魅力的に感じ、プロジェクトが開始されることが多い。
特に提案のプロが提案書を作成する以上、論点も美しく整理され、加えてプロジェクト予定メンバーにスキルを持っている人が入るように見えるため、プロジェクト進行の安心感がある。
たまに提案書のために名前貸しとして書かれているパターンも…
しかしその結果、新しいシステムへの移行が強引に進められ、プロジェクトが進む中で既存システムの理解不足などをきっかけに問題が膨れ上がった可能性がある。
もし既存システムのドキュメントが揃っていない、または最新化されておらずブラックボックス化している場合は現状理解に時間が想定よりも時間がかかる
◆妄想② 外部コンサルタントが業務を十分に理解し、外部コンサルタント主体で効果的に進めることは難しい
- その結果、本来やる必要のある重要ポイントが宙ぶらりんになってしまうことも
コンサルタントは途中からプロジェクトに参加するため、システムや業務へ深い理解を持つことは難しい。
ご隠居_むらたんさんも書かれてたのにはおおむね同意
私自身、SE時代に運用保守や障害を経験してデータ構造や業務をシステムに落とし込む仕組みについて初めて理解できることが多かった
コンサルタントは責任範囲を明確に設定し、中途半端な関与（最初の見積もり範囲から超える範囲）を避ける気質があるように思う。
そのため、理想としては発注側がメインで進行し、コンサルタントを効果的に活用するスキルが必要だが、そのスキルを持つ企業は多くない。
◆妄想③ 「追いつき開発」の存在？
- その妥当性や代替方法が不明確になる可能性がある
システム開発では、理想的には一度開発を停止し（システムを凍結し）、その機能を次期システムに移行してから、次期システムで開発を進める。
しかしプロジェクト期間が長いと、既存システムの改修と新システムへの取り込み（追いつき開発）が同時に進行することがある。
この「追いつき開発」の妥当性や、新システム（SAP）での代替方法が不明確になる可能性がある。この追いつき要件は当初の見積もりから明確になっていないことが多いため、プロジェクトの計画・進行にクリティカルに影響する要因となる。
◆妄想④ 本番稼働後のエラーから推測
- 本番切替のリハーサルが不十分だったこと、および十分なテスト時間が取れなかった可能性がある
本番切替のリハーサルや妥当性が不十分だった可能性がある（期間の問題？）。
本番切替前のテストでは、例えば現場が1か月分の業務を行うなどをしてシステムの妥当性を検証するところだが、十分なテスト時間が取れなかったことが原因かも。
例えば、1か月分の業務サイクルも、テスト日付を変えたりして理論上1週間などの短期間で行うこともできる
しかし、それには業務への十分な理解とシステムの仕組みを押さえなければ漏れが発生する
その結果、不十分なテスト量のまま完了していた可能性がある
◆妄想⑤ 問題が山積みでも、もう戻れない状態になり進むしかなかった？
- プロジェクトが一度延長されたことへの考察
開発が大幅に進んでしまい、開発費用も結構かけてしまった以上、もう戻れない状況になっていた。
そんな中、問題が大きくなったとしてもプロジェクトを中止することは、実質プロジェクト失敗の烙印が押されることと同じ
もしかすると、現場ではプロジェクトを止めるかどうかの調整が繰り返し行われていたのかもしれない
その結果、落としどころとして延長という選択肢をとり、プロジェクトを進めてしまったのかも
しかしプロジェクト方針を大幅に変更するには全ステークホルダーを説得することが必要なので、現場は非常に体力を使う
方針転換案を納得させるためには、一度や二度では済まず、少しずつ根回しをしつつ、関係者を説得することになる
特に、ステークホルダーの中に、ひときわ権威を持つ人がいた場合、その人を説得させるためにあの手この手で根回しして説得するしかない
なかなか生の声（現場の本音）を提言することはできず説得の決め手がないまま進み、時間があればなんとかなるのでは？という誘惑で逆に説得されて進めてしまう場合も
プロジェクトを延伸すること自体も大きな方針転換だが、プロジェクトがすでに炎上している時点で止まれないだけで、延伸という手段で問題を先送りにしたまま進めてしまうことも
◆妄想⑥ 正常な工程完了判定がされていた？
- プロジェクトの進行や期間を優先したことにより、工程完了判定が正しく行われず、本来解消すべきバグや申し送り事項が見過ごされる可能性がある
本来、こういう事態にならないために、開発プロセスを体系的にまとめた先人の知恵（PMBOKやたくさんのプロマネの教科書）が多くがある
特に、こういう大規模改修では、各工程ごとに次の工程に進むかの判定が入るはず
デロイトほどの会社がプロジェクトを進める場合、ちゃんとした工程の進め方や工程判定を踏むと推察される。
この工程判定は、バグの解消率や申し送り事項の整理など、さまざまな観点から行われるもの
しかし、もしかするとプロジェクトを前に進めるしかない状態やプロジェクトの期間をずらすことが難しい場合、この正常なプロセスが踏まれず、正しい観点での判定が行われない可能性がある。
その場合、工程判定は、出来レースのような形で合格判定がされ、本来改修されるべきバグや申し送り事項が見過ごされ次の工程に進む場合がある
普通の工程完了判定は、何とかして合格判定を得るものだが、（私も経験した）異常なプロジェクトでは、何とかして合格にして次の工程に進めてあげる、という非常におかしな構図が発生する場合がある
◆これからの状況を妄想
- システム障害の復旧には時間がかかり、その間に多くの課題が浮上する可能性がある
システム障害が起こった後、現場からのフィードバックや課題の優先順位の決定、説得などに時間がかかると予想。
在庫を多く抱えている企業では、現在の在庫の管理や障害対応を踏まえた復旧計画など、現場からも多くの声が上がる可能性がある。
システム側から見ると、最優先事項はデータの復旧だが、データは日々変化する生ものであるため、その復旧方法も課題となる。データ管理とビジネス継続性の間のトレードオフを常に強いられそう
◆まとめ
- システム障害の解決と事業の復旧を心から願っています。そして現場の方々の心労に対して、深くお見舞い申し上げます。
私自身も過去、炎上プロジェクトに関与していたので、自分のプロジェクトと照らし合わせて考えてみました。
この記事が、同じような問題に直面している方々の参考になれば幸いです。
最後にシステム障害の解決と事業の復旧を心から願っています。
この記事が気に入ったらサポートをしてみませんか？