カテゴリー: システム開発内製化

  • (6月28日通信)日本初のDX

    新幹線の予約システムが新幹線開業を揺るがした予約システム「マルス」のDX大惨事と、現代AI開発がもたらす「真の地獄」

    「自然言語(日本語)で指示を出すだけで、誰でも一瞬でシステムやアプリが作れる時代」が到来しています。しかし、画面上で「動く」ことと、本番環境で「壊れない」ことの間には、途方もない技術的ギャップが存在します。

    私たちは今、AIという強力な道具を手に入れたことで、「データ不整合」というシステム開発最大の地獄を忘れかけているのかもしれません。今回は、その教訓を学ぶために、日本のIT史・鉄道史に残るあまりにも有名な大惨事をご紹介します。それが、1964年の東海道新幹線開業に伴い導入された、世界初のオンライン座席予約システム「マルス(MARS)」の黎明期における大混乱です。


    1. システム化以前の「壮絶なアナログ排他制御」

    コンピュータが導入される前、国鉄の指定席券は完全に「人力」で管理されていました。当時の東京・秋葉原などにあった「乗車券センター」の光景は、現代からは想像もつかないものです。

    部屋の中央には、中華料理店の円卓のような巨大な回転テーブル(ターンテーブル)が設置されていました。その上には、すべての列車・日別の「紙の座席管理台帳」がズラリと並べられていたのです。

    • 電話による台帳の奪い合い: 全国の主要駅の窓口から「〇月〇日のひかり号、空いてる?」と電話が殺到します。
    • 肉体的なロック(排他制御): オペレーターは回転するテーブルから該当の台帳を目視で探し出し、手づかみで引き寄せ、鉛筆で座席番号を塗りつぶして発券していました。

    この「台帳を物理的に1人の人間が占有する」という行為こそが、当時の物理的な排他制御(ロック)でした。しかし、新幹線の開業により、この人力システムは限界を迎えることが火を見るより明らかでした。そこで国鉄が社運をかけて挑んだのが、日本初の「DX(デジタルトランスフォーメーション)」、マルスシステムの導入だったのです。


    2. 1964年、新幹線開業と「MARS-101」の大惨事

    1964年10月1日、東海道新幹線の開業に合わせて、最新鋭の座席予約システム「MARS-101(マルス101)」が本格稼働しました。世界に日本の技術力を示す輝かしいスタートになるはずでした。しかし、新幹線が走り出すと同時に、窓口は怒号の飛び交う大パニックに陥ります。

    原因は、新幹線の爆発的な需要に対し、当時のコンピュータの処理能力や通信速度が全く追いつかなかったこと、そしてシステム的な「排他制御(トランザクション処理)」の未熟さにありました。

    「開業当初の新幹線は爆発的な人気を博したが、マルス101の処理能力はパンク状態に陥った。システムが頻繁にフリーズし、処理のタイムラグによって、同じ座席を複数の駅に同時に売ってしまう『ダブルブッキング(二重予約)』が多発したのである。」

    低負荷なテスト環境では問題なく動いていたシステムが、本番の超高負荷環境に置かれた瞬間、データが一瞬にして崩壊したのです。窓口には、同じ座席の特急券を持った乗客が何組も鉢合わせるという、システム起因の「大惨事」が連日発生しました。


    3. 「紙の台帳に戻せ!」押し寄せる先祖返りの波

    連日の二重予約とシステムのダウンにより、駅の窓口は激怒した乗客の対応に追われ、現場のストレスは極限に達しました。この時、国鉄の幹部や現場からは猛烈なシステム撤廃論が巻き起こります。

    「こんな信用できない機械は捨てて、元のターンテーブルと紙の台帳による管理に戻すべきだ!」

    これがいわゆる、システム開発における最悪の罠の一つである「アナログへの先祖返り」です。しかし、国鉄の技術者たちと日立製作所の開発チームは踏みとどまりました。「今さらアナログに戻しても、新幹線の乗客数には物理的に対応できず、パンクするのは目に見えている」と確信していたからです。

    開発チームは不眠不休でシステムを改良し、データの多重更新を防ぐ厳密なファイルロックやキュー(順番待ち)の仕組み、すなわち現代のデータベースにおける「トランザクション処理」の原型を泥臭く作り込みました。このエンジニアたちの意地が、現在の「オンライン稼働率99.999%」という世界最強のモンスターシステムを創り出す礎となったのです。


    4. 現代の「自然言語(AI)開発」に突きつけられた鋭い教訓

    この半世紀以上前のマルスの歴史は、現在の「AIによる自然言語開発」に対する強烈な皮肉であり、教訓となっています。

    現在、AIに日本語で「予約システムを作って」と指示すれば、数分で見栄えの良いシステムが出来上がります。しかし、AIが書くコードの多くは、あのマルス101が失敗した時と同じ罠を抱えています。

    • 「動く」と「壊れない」の勘違い: トランザクションや適切な排他制御(データベースのロック)を明示的に指示しない限り、AIは「低負荷時だけ動く、ダブルブッキングするシステム」を平気で出力します。
    • 中小企業を襲う「遅れてくる負債」: 開発段階や、少人数で運用している「低負荷時」は、処理が抜けることは殆どないため、テストをすり抜けてしまいます。しかし、ビジネスが成長し、アクセスが集中した瞬間にデータがサイレントに汚染され、発覚した時には修復不可能なレベルに達します。

    5. 待ち受ける本当の地獄:誰も触りたがらない「AIのクズコード」

    マルス101の大惨事の際は、国鉄と日立製作所の優秀なエンジニアたちが「自分たちが作ったシステムだから」という圧倒的な当事者意識と責任感を持って、不眠不休で解決に当たりました。だからこそ、アナログへの先祖返りを阻止できたのです。

    しかし、現代の「AIが作ったシステム」が爆発した時、待っているのはさらなる絶望です。AIが無造作に書いたコードの山を触りたがるエンジニアなど、この世に皆無だからです。

    • 狂ったツギハギの怪物(スパゲティコード): AIは指示されるたびに、その場しのぎのコードを無造作に継ぎ足します。全体の設計思想がないため、右側では最新の書き方、左側では古く危険な書き方をしているようなコードになり、自分で一から作り直す(リプレイスする)よりも数倍の時間がかかります。
    • エンジニアのボイコット(拒絶): 中小企業が「AIで安く作ったシステムが壊れたから特急で直してくれ!」と駆け込んでも、プロのエンジニアは「誰が設計したかも分からず、トランザクションもない爆弾の信管を、なぜ自分が責任を負って抜かなければいけないのか」と依頼を拒絶します。
    • 跳ね上がる特急料金: 汚染されたデータのクレンジング(修復)や、AIのクズコードの解読を引き受けてくれるのは、ほんの一握りの「超一流エンジニア」だけです。発覚した時点で、請求される費用は最初の想定の桁が一つ二つ変わるほどの天文学的な金額になります。

    結果として、対応できずにシステムは完全に死亡し、会社はアナログに戻ることもできず、事業停止に追い込まれるという「最悪の結末」を迎えることになります。


    結論:歴史を知る者がAIを制する

    プログラミング言語の構文や文法は、半世紀の間にCOBOLからJava、Python、そして「日本語(プロンプト)」へと形を変え、完全に一般化(ゾルトラーク化)しました。誰でも強力な魔法を放てる時代です。

    しかし、「データをどう守るか」というコンピュータサイエンスの基本原則(ACID特性やトランザクション、論理削除、Decimal型による誤差回避)は、50年前から1ミリも変わっていません。

    道具がどれだけ便利になろうとも、裏側にあるリスクを予見し、ガードレールを設置する「人間の審美眼と設計力」の価値が消えることはありません。「動いている(テストを通った)からといって、正しい設計である保証はどこにもない」という冷徹な現実を理解している者だけが、このAI時代を生き残ることができるのです。


    関連・参考リンク

  • (6月27日通信)操作画面を増やしたくなる、システム開発会社の本音

    画面数で見積もられてしまう前に、企業が知っておきたいシステム開発の構造

    システム開発の見積書を見ると、よく登場するものがあります。

    操作画面の数。
    入力フォームの数。
    一覧画面の数。
    帳票の数。
    機能の数。

    もちろん、画面や機能を作るには工数がかかります。
    ですから、それらが見積もりに反映されること自体が間違いというわけではありません。

    しかし、企業側が注意すべきなのは、画面数や機能数が、システム開発の価値そのもののように扱われてしまうことです。

    本当に価値があるのは、画面を何枚作ったかではありません。

    その会社の業務をどこまで理解したか。
    現場の判断をどこまで整理したか。
    経営者の考えをどこまで業務構造に落とし込んだか。
    会計、権限、承認、顧客管理、外部専門家との関係をどこまで見通したか。

    本来、システム開発で最も重要なのは、こちらの方です。

    画面は分かりやすい。だから請求しやすい

    なぜ、システム開発会社は画面数や機能数を見積もりの根拠にしやすいのでしょうか。

    理由は単純です。

    顧客に説明しやすいからです。

    「入力画面が10枚あります」
    「一覧画面が5枚あります」
    「帳票が3種類あります」
    「管理画面を追加します」

    このように説明されると、発注する企業側も分かった気になります。

    目に見えるものだからです。

    画面が増えれば、作業が増えたように見える。
    機能が増えれば、開発量が増えたように見える。
    帳票が増えれば、業務に合わせて作り込んでいるように見える。

    しかし、ここに落とし穴があります。

    画面は見えます。
    だから分かりやすい。

    一方で、業務理解は見えません。
    権限設計も見えません。
    データ構造も見えません。
    将来のセキュリティ強化に備えた設計も、見積書だけでは分かりにくい。

    その結果、本当に重要な設計よりも、見えやすい画面数が請求根拠として前面に出てきやすくなります。

    本当にコストがかかるのは、画面ではなく業務理解

    企業向けのシステム開発で本当に難しいのは、操作画面を作ることではありません。

    本当に難しいのは、開発する企業の業務を理解することです。

    どの業務が会社の利益を生んでいるのか。
    どの手順が現場の工夫なのか。
    どこに例外処理があるのか。
    どの情報を外部に見せてはいけないのか。
    誰が判断し、誰が承認し、誰が責任を持つのか。
    どのデータが会計・請求・在庫・顧客管理につながるのか。

    こうした情報は、表面的なヒアリングだけでは出てきません。

    企業独自のノウハウには、他社に知られたくない情報もあります。
    経営者が簡単には話したくない判断基準もあります。
    現場担当者が長年の経験で覚えている暗黙知もあります。

    それらを、信用を得ながら聞き出し、守秘しながら整理し、後から読める概要書面に落とし込む。

    ここに、本来のコストがかかります。

    画面を作る前に、会社の業務を言語化する。
    この工程こそ、システム開発の上流で最も価値がある部分です。

    画面から始めると、システムは膨らみやすい

    問題は、画面からシステムを考えてしまうことです。

    最初に画面イメージを作る。
    顧客がそれを見て「分かりやすい」と感じる。
    そこに入力項目を足す。
    一覧画面を足す。
    検索画面を足す。
    管理画面を足す。
    帳票を足す。

    こうして、画面はどんどん増えていきます。

    しかし、画面が増えたからといって、会社の業務構造が整理されるわけではありません。

    むしろ、業務理解が浅いまま画面を増やすと、後から困ることになります。

    同じような情報を複数の画面で入力する。
    どのデータが正しいのか分からなくなる。
    権限管理が後付けになる。
    部署が増えたときに対応できない。
    外部専門家と連携しにくい。
    会計や請求とのつながりが曖昧になる。
    将来のセキュリティ強化で作り直しが必要になる。

    見た目には便利そうな画面が増えていても、裏側の構造が整理されていなければ、システムは複雑になっていきます。

    見積もりコスト回収型の画面増殖

    少し踏み込んだ話をすると、システム開発では、提案や見積もりを作る段階にもコストがかかります。

    顧客の話を聞く。
    業務を整理する。
    提案書を作る。
    概算を出す。
    画面イメージを作る。
    見積書を作る。

    これらは本来、価値ある作業です。

    しかし、顧客側が「提案や業務理解そのもの」に価値を感じにくい場合、そのコストをどこかで回収する必要が出てきます。

    そのとき、画面数や機能数は説明しやすい請求根拠になります。

    「この画面も必要です」
    「この管理機能も必要です」
    「この帳票も作りましょう」

    このようにして、見積もりや提案にかかったコストを、画面や機能の数に乗せて説明する構造が生まれやすくなります。

    もちろん、すべてのシステム開発会社が意図的に画面を増やしているわけではありません。

    しかし、請求根拠が画面数や機能数に偏っていると、どうしても「作るものを増やすほど売上が増える」構造になります。

    これは、発注する企業側にとって注意すべきポイントです。

    画面を増やすことと、アプリケーションを分けることは違う

    ここで誤解してはいけないことがあります。

    画面を増やすことと、アプリケーションを分けることは違います。

    画面を増やすとは、操作する入口や見た目を増やすことです。
    一方で、アプリケーションを分けるとは、業務責任・権限・データ管理・会計連携・外部専門家との役割分担を整理することです。

    たとえば、顧客対応、会計、講座運営、資料管理、外部専門家連携、権限管理を、必要に応じて分けることがあります。

    これは画面数を増やしたいからではありません。

    誰が何を見てよいのか。
    誰がどの情報を変更してよいのか。
    どのデータが正本なのか。
    どの業務が会計とつながるのか。
    外部専門家にはどこまで共有するのか。
    将来、セキュリティ強化や事業分割が必要になったときに対応できるのか。

    こうした境界を明確にするためです。

    つまり、正当なアプリケーション分割は、画面を増やすためではなく、会社の業務と情報を守るために行います。

    画面は少なく、構造は明確に

    企業側が本当に求めるべきなのは、画面が多いシステムではありません。

    使う人にとって画面は少なく、分かりやすい方が良い。
    教育コストも下がります。
    操作ミスも減ります。
    保守対象も減ります。

    一方で、裏側の構造は明確である必要があります。

    業務ごとの責任範囲。
    権限管理。
    承認フロー。
    データの正本。
    会計との接続。
    外部専門家との共有範囲。
    将来のセキュリティ強化への備え。

    ここを曖昧にしたまま画面だけ増やしても、会社にとって本当に使えるシステムにはなりません。

    大切なのは、画面数ではありません。

    会社の業務構造をどこまで理解し、どこまで整理し、どこまで将来に耐える形にできるかです。

    高度な外注開発は、結局「内製化教育」に近づく

    将来的なセキュリティ強化や権限分離まで考えたシステムを提案しようとすると、開発会社は企業側にシステム構造を説明する必要があります。

    なぜ業務ごとに分けるのか。
    なぜ権限管理が必要なのか。
    なぜ顧客情報、会計情報、外部専門家との共有情報を同じ場所に置いてはいけないのか。
    なぜ今は小さな会社でも、将来の部署分割や経営統合を考えた設計が必要なのか。

    ここまで説明するなら、それは単なるシステム開発の提案ではありません。

    企業側が、自社の業務構造とシステム構造を理解するための教育でもあります。

    であれば、最初から「外部に丸投げするシステム開発」ではなく、企業側が構造を理解しながら進める内製化支援として始めた方が自然です。

    内製化とは、すべてを自社だけで作ることではありません。

    外部専門家を活用しながらも、自社の業務構造、権限、データ、会計、セキュリティの考え方を、企業側に残していくことです。

    見積書で見るべきもの

    システム開発の見積書を見るとき、企業側は画面数や機能数だけを見てはいけません。

    見るべきなのは、次のような点です。

    その会社の業務をどこまで理解しているか。
    業務の概要書面が残るか。
    権限や承認の考え方が整理されているか。
    データの正本が明確になっているか。
    会計や請求とのつながりが考えられているか。
    将来のセキュリティ強化に対応できるか。
    外部専門家を活用しても、会社側に判断軸が残るか。

    画面は、システムの入口にすぎません。

    本当に見るべきなのは、その奥にある業務構造です。

    まとめ

    操作画面を増やせば、見積もりは説明しやすくなります。

    しかし、画面が多いことと、良いシステムであることは別です。

    本当に価値があるのは、画面を増やすことではなく、会社の業務を理解し、企業独自のノウハウを尊重しながら、業務構造・権限・データ・会計・セキュリティを整理することです。

    画面を増やすほど、会社のシステムは分かりやすくなるとは限りません。

    むしろ、業務理解が浅いまま画面を増やすと、後から直しにくいシステムになってしまいます。

    雲楼システムパートナーズでは、画面数や機能数を増やすことを価値とは考えていません。

    当社が重視しているのは、企業側が自社の業務構造を理解し、必要に応じて外部専門家を活用しながら、将来に耐えるシステム設計を考えられる状態を作ることです。

    画面から考えるのではなく、会社の業務構造から考える。

    それが、中小企業のDXやシステム内製化で失敗しないための第一歩です。