黒神テンノコエは、なぜ止まらなかったのか｜炎上体制編#05-仕組み屋の記録帖
――「前向きに」が警報を消した日――
谷川です。
難しいプロジェクトほど
前向きさは必要です。
簡単に諦めない。
できる方法を探す。
会社の未来を信じて、挑戦する。
それ自体は、悪いことではありません。
——しかし、
本当に必要だったものは何でしょうか？
『前向き』であることと
『現実を見ない』ことは異なります。
今回は、炎上体制編の中で
幾度となく、その輪郭を見せてきた
『黒神テンノコエ』の話です。
⚔ 境界勢力（登場人物）
黒でも白でもない。当時の現場の皆様。
※登場人物・組織名・製品名は仮名です。
当時の記憶をもとに一部の時系列や構成を
フィクションを交えながら書いています。
📝 今回の話について
🌍 テンノコエは特定の誰かではない
炎上体制編の冒頭で
私は二つの存在を描きました。
現実神リアリス。
その工数で成立するか。
責任と権限は一致しているか。
人を壊してまで進めていないか。
そして、黒神テンノコエ。
前と同じで。
なんとかなる。
まず受けよう。
現場で調整して。
黒神テンノコエとは、
特定の誰か一人ではありません。
会社を成長させたいという夢
新しい事業の柱を持ちたいという願い
長年の顧客に応えたいという責任
売上と利益への期待
迫る期限への焦り
過去の成功体験
それらが混ざり合い
現場へ「変えにくい前提」として
届いてしまう声です。
🏆 会社には実現したい夢があった
当時の会社は
受託開発を中心とした事業から
自社の強みを持つ会社へ
少しずつ変わろうとしていました。
長年、開発側として関わってきた
基幹業務システムの知見を生かし、
要件定義から開発、導入までを一貫して
支援するサービスへと育て、
これからの事業の柱にしたい。
さらに
短納期で導入できることを
自社の強みにしたい。
そんな構想もありました。
今回の案件は
社運がかかった大型案件として
期待されていました。
夢そのものは、理解できます。
受託案件を追い続けるだけではなく、
再現性のある商品やサービスを持ちたい。
会社として自然な願いだったと思います。
ただ…
その初手に選んだ案件が
あまりにも難しすぎました。
⚠️ 初手に選ぶには、難しすぎる案件
今回の案件は
長年取引のある顧客の
業務システムのリプレイス案件でした。
旧システムには
長い年月をかけて積み重なった
独自要件や例外運用がありました。
さらに
旧システム基盤には廃止期限が迫っており
一定期間内に刷新する必要もありました。
・独自要件が多い
・旧システムの再現を求められる
・延期できる余地が少ない
・確実な本番稼働が必要
・失敗すれば、長年の取引関係にも影響
短納期導入モデルの
初期重要案件としてはほぼ最難関です。
新しい導入方式を試すなら
標準機能に寄せやすい。
対象範囲が限定されている。
例外運用が少ない。
段階的な導入ができる。
顧客と試行錯誤しやすい。
そういう案件からスタートすべきでした。
挑戦自体が悪かったのではありません。
挑戦を載せる案件の選び方が
「危険」だったのです。
🧩 要件定義という名の、機能説明
私自身は、要件定義の途中から
他部署の応援として参画しました。
ところが…
実際に行われていたのは
要件定義ではなく
パッケージの機能説明に近いものでした。
顧客から出てくる要望は
『前と同じで。』
という言葉で流れていきました。
旧システムの仕様書がある。
元のソースもある。
過去の対応履歴も残っている。
だから、たどれば分かるだろう。
そんな前提でした。
……無理です。
私も含めて集められた開発メンバーは
ERPパッケージの開発には慣れていました。
しかし、旧システムは別の言語。
私たちはソースを読めませんでした。
ソースは読める方に見てもらえば、
処理の内容は分かります。
けれど、
なぜ、その処理になったのか。
今も、その例外対応が必要なのか。
担当者や業務が変わっても回るのか。
現在の運用に合っているのか。
そこまでは、確認されていませんでした。
それを確認するのが
本来の『要件定義』です。
何を残すのか。
何を変えるのか。
誰がどの運用を担うのか。
その整理が十分でないまま、
開発へ進もうとしていました。
🔀 新規開発か、パッケージか
要件定義の終盤で
二つの案の比較が始まりました。
一つは
旧システム基盤の後継環境に
新しいシステムを一から作り直す再構築案。
もう一つが
ERPパッケージを使う案です。
再構築案は
利益もスケジュールもギリギリでした。
何を作るのか。
どこに工数がかかるのか。
どの工程で何を確認するのか。
ただ、比較的計画は読みやすく
工程を積み上げて進められる案でした。
一方、パッケージ案は
標準機能を使えば
多くの機能を短期間かつ比較的安価に
導入できるように見えます。
ただし、それは…
顧客の業務をパッケージの標準運用へ
寄せられる場合の話です。
「パッケージを入れる」ということは
パッケージが持つルールや制約を
受け入れることとセットです。
スーツに例えるなら
ERPパッケージは既製スーツです。
裾上げをする。
ボタンを替える。
ポケットを追加する。
その程度なら、
比較的小さな調整で済みます。
元の型を残したまま
体型に合わせて調整する
パターンオーダーのような対応もできます。
しかし…
形を大きく変えたい。
生地も変えたい。
着心地も変えたい。
ポケットの位置や数を以前のスーツと同じにしたい。
そこまで求めれば
実質フルオーダーです。
既製スーツを選んだのに
古いフルオーダースーツと
見た目も着心地も使い勝手も同じにする。
しかも、『既製品の価格と納期』で。
…無理です。
技術的に変更できるかどうかだけが
問題ではありません。
手を入れれば、入れるほど
パッケージ導入で得られるはずだった
短納期
低コスト
品質の安定
将来のバージョンアップ
という利点が失われていきます。
旧システムと同じものを
再現しようとすれば
カスタマイズはどんどん増えます。
カスタマイズが増えるほど、
費用
工期
影響範囲
機能間の連携
テスト範囲
品質維持
将来の保守
すべてが揺れます。
今回求められていたのは
『既製スーツの価格と納期で仕上げる
実質フルオーダースーツ』でした。
それでも、当時は…
パッケージ案の方が
余裕のある計画に見えたのでしょう。
短納期で導入。
利益も残る。
新事業のシンボルになる。
導入が成功した未来が、
現実の検証より先に見えていました。
✉️ 開発開始前の退職意思
要件定義が終わる頃、
私は「退職の意思」を伝えました。
引き継ぎ期間を考え、
退職時期は
開発フェーズ終了予定の半年後でした。
正直、この病み上がりの身では
この先の高負荷に
身体がついていかないと感じたから。
そして、
『このまま開発へ入っても、
まともなものが作れる気がしない』から。
私の退職意思を聞いた上長は
言葉を失ったように固まっていました。
私に任されたのは開発担当。
ただ、ERP導入プロジェクトでは
設計から開発、導入まで一通り経験しており
状況はある程度、見えていました。
私が抜ければ
開発以降、必要になる経験者が一人減る。
その意味は
当時の運営側にも
見えていたのかもしれません。
🚨 退職届ではなく、最後のリスク報告
呼び出された場で
私はうまく説明できたわけではありません。正直かなり震えていたと思います。
ただ、覚えているのは
まだ要件定義なのに、
プロジェクトの皆が疲れている。
このまま進めたら、
PMや全体を見られる人の負荷が
高くなりすぎて
誰も冷静に考えられなくなる。
司令塔が潰れたら、案件そのものが沈む。
せめて、
皆がまともな時間に
帰れる計画に見直してほしい。
という趣旨のことを伝えたことです。
返ってきたのは…
マズイとは思う。考えとく。
という言葉でした。
危険性を否定されたわけではありません。
マズイことは、認識されていた。
今振り返ると
あの場は単なる退職相談ではなく
計画見直しの、最後の機会でもありました。
…けれど、何も変わりませんでした。
✂️ 恐怖の見積削り
その後、パッケージ案の
開発見積を求められました。
上からは
短納期での導入を求められていました。
そのために置かれた条件は、
恐ろしいものでした。
詳細設計を省く。
レビューの時間を取らない。
単体テストにも十分な期間を置かない。
代わりに…
基本設計を詳細設計相当の粒度にする
要件定義を担当したメンバーが設計を担当
設計と開発の連携を密に取る
開発は動作確認を厚めに
単体テストで不具合を出さずに通す
後工程の手戻りは起きない前提で進める
私は、その前提を
全く信用できませんでした。
そもそもの要件定義が
「前と同じ」で流されている。
要件が曖昧なのに
手戻りがないはずがありません。
だから、私は…
詳細設計とレビューに
本来必要だった工数を
開発工程の見積へそっと含めました。
必要な工程だったから。
しかし、
戻ってきた見積では
私が追加した分を上回る工数が
削られていました。
その数字では上やお客様に通らない。
という理由でした。
短納期で導入できる案に見せる。
予算内で利益が残る案に見せる。
見積を削った手は、現場にありました。
でも、その手を動かしていたのは、
上から降りてきた納期と予算でした。
🧾 見積書から消えても、作業は消えない
詳細設計を削る。
レビューを削る。
単体テストの時間を削る。
だけど、
本来、必要な確認と作業時間そのものが
消えるわけではありません。
確認されなかった仕様は、
後工程へ送られます。
結合テストで見つかる。
データ移行で見つかる。
本番前に見つかる。
稼働後に見つかる。
そのたびに、
誰かが仕様を掘り直す。
誰かが設計し直す。
誰かが実装を直す。
誰かが顧客へ説明する。
誰かが夜間と休日で穴を埋める。
ことになります。
見積書から消えた作業は、
後で不具合と残業になって戻ってきます。
計画に余裕があったのではありません。
余裕があるように、
数字を整えただけでした。
🏆 そして、パッケージ案が採択された
・短納期で導入できる。
・利益も残る。
・新しい事業のシンボル案件ができる。
・会社の未来をつくる案件になる。
とても魅力的な計画に見えたと思います。
ただ…この二つの案は
本当に同じ物差しだったのでしょうか。
新規開発案は
必要な作業を積み上げた現実的な見積。
パッケージ案は
上に通る数字へ合わせるために、
必要な工程が見積書の外へ
押し出されたように見えました。
選択肢は二つ。
でも、同じ現実を測っていない見積。
その結果…
余裕があるように見える
パッケージ案が選ばれました。
でも、実際は
計画の中にはその余裕は含まれてなく、
見積書の中に作られただけでした。
📢 「このままでは失敗」は抵抗だったのか
退職意思を伝えてから数か月後、
とあるミーティングで
このままでは、失敗すると思います。
と伝えました。
返ってきたのは
今しんどいかもしれないけれど…
前向きに進めよう。
という趣旨の言葉でした。
さらに、全体会議では、
一部の開発者の抵抗はあるが、頑張ろう。
という鼓舞の言葉がありました。
私を指したものだったのかは分かりません。
ただ、その時の私には
危険を伝える声そのものが
弱気
後ろ向き
抵抗
として扱われたように聞こえました。
「このままでは失敗する」
この言葉は反抗ではありません。
将来のリスクを伝えた言葉です。
火災報知器が鳴った時
必要なのは
「報知器の電源を切る」ではなく、
真っ先に火元を確認することです。
危険を知らせる声を
「抵抗」として処理した瞬間
組織は自分で警報器を壊します。
退職日まで、残り1ヶ月足らず。
ここでできることは、もう何もない。
あとは無事に出られることを祈るばかり。
🕯️ テンノコエは、なぜ止まらなかったのか
会社には
過去の危機を乗り越えた
成功体験がありました。
難しい状況でも…
外部の力を借りながらも前へ進んだ。
だから、今回も
立ち止まるより進むこと。
慎重になるより挑戦すること。
弱気にならず、成功を信じること。
それが正しいと
考えられていたのかもしれません。
私は、一担当であり
当時の契約条件や経営判断の背景を
すべて把握していたわけではありません。
それでも…
現場から発せられていた
「ただ事ではない」という警報が
見直す材料にならなかったことは確かです。
以前は
それで会社を救えた。
けれど
今回必要だったのは
まず一度止まることだと思います。
初期重要案件を選び直すこと。
顧客へ頭を下げて再調整すること。
納期、予算、範囲、方式のどれかを動かすこと。
過去に「会社を救った成功体験」が
今回は「引き返す判断を妨げる鎖」になった。
テンノコエは
無知から生まれたのではありません。
過去に正しかった判断を
条件の違う今回の案件にも当てはめた結果
現実と異なる「成功する未来」を
固定してしまった。
そこから生まれたのだと思います。
⚖️ 現実神リアリスの判定
判定
夢を持ったことは、罪ではない。
受託中心の会社から、
自社の柱を持つ会社へ変わろうとしたことも
『悪』ではない。
短納期導入を強みにしようとしたことも
挑戦そのものは『間違い』ではない。
ただ、
未検証の事業モデルを
独自要件が多く、確実な稼働が
必要な案件に採用した。
期限を固定した。
予算を固定した。
方式を固定した。
旧システム踏襲も外さなかった。
結果、
達成が困難な「最難関案件」に変わった。
さらに
品質を守る工程を削り
危険を知らせる声を「抵抗」と遠ざけた。
そして、
最後に調整されたのは人。
・PMを替えた。
・人員を追加した。
・体制を組み替えた。
けれど、前提だけは替えなかった。
夢は『現実を見ない免罪符』ではない。
夢を実装するなら、
まず現実を見なければいけない。
🪽 リアリス判定
黒神テンノコエ。有罪。
真に裁かれるべきは、挑戦ではない。
現実を検証する前に、
会社の夢を
失敗できない顧客案件と
現場の身体に載せた意思決定である。
🚨 罪状
現実を見直す代わりに、
現実を見せる声を削ったこと。
☠️ 結果
前提は守られ、人間が壊れた。
リアリスは
静かに記録を残した。
🖊️ あとがき
私は要件定義終盤に退職意思を伝えました。
それから半年間、開発を担当し、
開発フェーズ終盤でこの案件を離れました。
当時は
自分が弱かったから。
身体がもたなかったから。
途中で逃げたから。
そう思っていました。
でも、今振り返ると
成立しない条件が積み上がっていくのを
私は見ていました。
うまく言葉にはできなくても
一度は止めようとしていました。
まだ要件定義の段階なのに、
プロジェクトの皆が疲れ切っていて…
そのまま司令塔まで潰れたら、
『案件そのもの』が沈んでしまう。
この進め方はまずいのではないか。
震えながら、私は伝えていました。
警報は鳴らした。
それでも、止まらなかった。
あの時、
「私は辞めます」と伝えたことは…
本格的な崩壊に巻き込まれる前に
自分の出口を確保する決断にもなった。
と、今は思います。
もし、あと１か月、
この決断が遅れていたら…
私はもう一度システムの仕事へ
戻れていなかったかもしれません。
私が抜ければ
この案件はさらに危なくなる。
それは分かっていました。
でも、私が残れば、
今度は私自身が危なかった。
だから退職日まで
どうか誰も私の役割に気づきませんように。
ただ祈るように待っていたあの時間は
今思い出しても怖ろしいものです。
同じような現場で
危険を伝える誰かの声が
「弱気」や「抵抗」として
消されませんように。
『前向き』であるためにこそ
一度立ち止まれる組織でありますように。
そう願っています。
📌 初めての方へ
当note「仕組み屋の記録帖」 は
実体験をもとに再構成した記録です。
気になる方は他記事もどうぞ。
▶炎上PJ総集編
「なぜ炎上してしまったのか」
複数の切り口で見てみたい方はこちら。
▶☠️ 前提は守られ、人間が壊れた案件
「何が起きてしまっていたのか」
当時の雰囲気を知りたい方はこちら。
