Digital Heroes: Guide to IT World

うわっ、動いてるのに“負け”が確定する世界がある——それがシステム開発だ。 ■社会人7年、200人プロジェクトの現場 社会人7年、私はシステム屋として数多くのプロジェクトを回してきた。中でも忘れられないのは、200人を超える巨大プロジェクトだ。しかも、ただ人数が多いだけではない。物理的にも過酷だった。 「この狭い部屋に200人、どう座る？」 そんな議論から始まる現場。だが、本質はそこではない。人が密集するほど、システムもまた“複雑さ”を増していく。 ■構成管理という“裏側の支配者” 私は構成管理担当として、開発そのものではなく、環境の安定を支える役割を担った。プログラマー、サーバ担当、ネットワーク担当——多様な専門家と関わる中で、ある事実に気づく。 「動かすこと」と「支えること」は、まったく別の能力だ。 ■プロの条件は“少なさ”に宿る プログラムの世界は奥深い。だが、真のプロはコード量で語らない。むしろ逆だ。 行数は少ない。コメントは的確。無駄がない。 “読める・書ける”だけでは、ただの作業者に過ぎない。 本質は「設計思想」と「再現性」にある。 ■サーバも同じ、動くかではなく“耐えるか” サーバ構成も同様だ。つなげば一応、動く。日常運用では問題ないかもしれない。 しかし、負荷が急増した瞬間—— その差は一気に露呈する。 耐える構造か、崩壊する構造か。 ここに“プロとそれ以外”の境界線がある。 ■議論：なぜ日本の現場は“動けばいい”に流れるのか ここであえて問題提起したい。 なぜ多くの現場は、「とりあえず動く」ことをゴールにしてしまうのか？ 納期、コスト、評価制度——理由はいくらでもある。 だが、それを言い訳にした瞬間、技術者としての成長は止まる。 ■システム屋に必須なメンタリティ システムの各領域は、それぞれが深い。プログラム、インフラ、ネットワーク——すべてが専門職だ。 だからこそ必要なのは、 「自分の領域に閉じないこと」 そして、 「学び続けること」 変化を前提に、自らをアップデートし続ける。 それができる者だけが、“プロ”として生き残る。 ■ビジネス示唆 これはエンジニアだけの話ではない。 企業も同じだ。 「今、動いている」ことに安心した瞬間、競争力は静かに失われる。 本質は、“未来の負荷”...

 えっ、コードを書く前に“言語そのもの”を日本企業が握っていた世界があったのか!? ■社会人6年目、初めて知った衝撃 社会人6年目、システムの現場に深く入り込んだときだった。 私はそれまで、プログラム言語は“誰かが作ったものを使うもの”だと思っていた。 Javaにはサポート会社があり、Sun Microsystemsが方針を決める。 Pythonにもルールがあり、コミュニティが進化をリードする。 つまり、「言語は世界のどこかが決めるもの」。 そう信じて疑わなかった。 だが、日立に入って初めて、その前提が崩れる。 ■日立が“COBOLを作っていた”という事実 有名なプログラム言語であるCOBOL。 金融、基幹システム、社会インフラ——日本の根幹を支えてきた言語だ。 そのCOBOLを、日立が作り、リードしていた時代があった。 協議会を作り、仕様を整え、改善を重ねる。 まるで今のPythonやJavaのように、「ルールそのもの」を握っていた。 これは単なる利用者ではない。 “言語の設計者”としての立場だ。 ■メインフレームと一体化した言語戦略 当時の主戦場は、汎用機——メインフレーム。 巨大な1台のサーバーに、すべてを詰め込む時代だ。 このメインフレームを導入する際、 単なるハードウェアでは終わらない。 プログラム実行基盤も含めて、ひとつの“完成されたシステム”として提供される。 そして、その中核にあるのがCOBOLだった。 つまり、メインフレームを導入する＝COBOLで作る。 言語は選択肢ではなく、“前提条件”だったのだ。 ■IBMと戦った日本企業の意地 世界ではIBMがメインフレーム市場を席巻していた。 その巨大な牙城に、日本企業は真正面から挑んでいた。 日立は、その中で単なるハード競争では終わらない戦いを選ぶ。 ハードを作り、基盤を作り、 そして、その上で動く言語まで作る。 つまり、“スタック全体”で戦っていた。 メインフレームに入っているCOBOL。 そのCOBOL自体も進化させていく。 オリジナルのCOBOLをベースにしながら、 実運用に合わせて改善を重ねる。 この一連の動きは、まさにプラットフォーム戦略そのものだ。 ■言語を握るということの意味 言語を作るということは、単なる...

うわっ、日本の根幹が、まだこのコードで動いているなんて——。 社会人6年目。私はすでに5つほどのプロジェクトを経験していた。規模はどれも大きく、100人を超える体制はもはや特別ではない。「これが普通のITプロジェクトだ」と自然に思うようになっていた。周囲も同じだ。関わる案件はどれも社会インフラに近く、失敗が許されないものばかりだった。 そんな環境にいたからこそ、ある日ふとした瞬間に見た光景が、強烈に記憶に残っている。 ■巨大プロジェクトの“当たり前”に潜む違和感 日立製作所という巨大な会社の中で、私は一つの基幹システムの改修プロジェクトに関わっていた。関係者は100人を軽く超え、複数のベンダーが入り乱れ、会議は毎日のように続く。進捗、課題、品質——すべてが緻密に管理されていた。 だが、実際に手を動かす現場に入ったとき、私は思わず息を飲んだ。 画面に並んでいたのは、COBOLのコードだった。 整然と並ぶ英字と数字。長年積み重ねられてきたロジック。その一行一行が、日本の金融や物流、社会の根幹を支えている。 「これが、まだ動いているのか」 それは驚きというより、むしろ“現実”だった。 ■社会インフラを支える見えない技術 COBOLは古い言語だと言われる。しかし、そのシステムは何十年も止まらずに動き続けている。信頼性、安定性、そして実績。どれをとっても圧倒的だ。 だからこそ、簡単には変えられない。 100人規模のプロジェクトが当たり前になる理由も、ここにある。変更一つで影響範囲は膨大に広がり、テストには膨大な時間と人手が必要になる。結果として、プロジェクトは巨大化し、慎重になり、変化は遅くなる。 私はその中で、ある種の矛盾を感じていた。 最先端のITを語りながら、最も重要な部分は“変えられない技術”に依存している。 ■変革はなぜ進まないのか この構造は、日本のITが抱える本質的な課題を示している。 変えたい。でも、変えられない。 効率化したい。でも、リスクが大きすぎる。 だから現場は、巨大な体制と緻密なプロセスで“守る”ことに最適化されていく。 それは間違いではない。むしろ合理的だ。 しかし、その一方で、変革のスピードは確実に鈍る。 私は6年目にして、初めて気づいた。 「プロジェクトの大きさ」や「人数」ではなく、 本当に向き...

うわっ、終わったはずの戦場に、また呼び戻されるなんて ■支援のはずが、踏み込めない違和感 あのプロジェクトは、支援として入った現場だった。同期が苦しんでいる。だから助けたい——そう思って動いていた。 だが現実は違った。手を出そうとすると、どこかで止まる。 「そこは依頼範囲外です」 「契約上、難しいですね」 まるで見えない壁があるようだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■組織をまたぐと“お金”が発生する構造 大企業では、組織間の支援にも明確なルールがある。 プロジェクトに必要な人員を計画し、その分の人件費を依頼元に請求する。 依頼元が顧客から収益を得ていれば、そこから支払われる。 もし得られていなければ、戦略案件として赤字覚悟で進める。 つまり、支援ですら“コスト”として管理される。 これは冷たい仕組みに見えるかもしれない。 だが、いくつかの企業を見てきた今なら言える。 この仕組みは、むしろ健全だった。 ■支援の終わりは、突然に ある日、判断が下った。 「依頼元からの予算が尽きた。撤退する」 あっけなかった。 我々の部隊は、そのプロジェクトから外れることになった。 残るのは、元の部署。 それが、本来の姿だった。 彼らは、自分たちでできると信じて仕事を取り、プロジェクトを立ち上げた。 しかし回らなかった。 だから、我々が支援に入った。 だが、お金がなければ、支援は続けられない。 ■残された責任 その後どうするか。 リスケするのか、顧客と再交渉するのか。 それは、依頼した部署の責任になる。 企業として一枚岩ではないのか？ そう感じる瞬間もあった。 正直に言えば、もっとできたと思っている。 あのとき、もう一歩踏み込めていたら——。 だが、上の判断は明確だった。 そして、次の指示が来た。 ■次のプロジェクトは、同じ場所だった 次の案件。 それは、日本の証券業界のど真ん中にある会社の基幹システム。 そして、その開発拠点は—— 前のプロジェクトで、必死に戦っていた場所だった。 また、同じ場所。 だが、役割は違う。 状況も違う。 あのときの悔しさが、胸に残っている。 ■ビジネスにおける“支援”の本質 この経験から見えたことがあ...

 AIもiPhoneも、そして私たちの仕事も——未来は、静かに続く過去の延長線上にある。 「えっ!?　AIって、いきなり現れた“未来の魔法”だと思ってませんか？」 街にはAI搭載の製品があふれ、まるで昨日までなかった世界が突然やってきたように見える。けれど、私のようなシステム屋からすれば、それは少し違う。AIもiPhoneも、決して“ゼロから生まれた革新”ではない。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ AIも、iPhoneも、そして日本の技術も AIは急に出てきた特別なものなのか？ iPhoneって、何も知らないところから生まれた技術なの？ ——答えは「No」だ。 AIの裏には統計学・信号処理・計算理論という数十年単位の研究の積み重ねがある。 iPhoneの背後にも、通信技術、タッチパネル、CPU設計、そして「人が持ち歩く」ことを前提にした思想の連続がある。 「技術立国・日本」がこれまで検討してきた研究も、確実に世界の土台を作ってきた。 ただ、表舞台に立たなかっただけだ。 失われた30年で“経済”を失ったかもしれない。 だが、“技術”まで失ったわけではない。 ■ システム屋から見た「技術の現場」 現場の感覚としては、「急に出てきた技術」なんて存在しない。 新しいシステムも、昨日までのソースコード、過去に書かれた小さな関数、改修の履歴、そのすべてが積み重なって今がある。 まさに「ちりも積もれば山となる」。 プログラムの世界では、魔法のような一行が世界を変えることはあっても、その一行を書くための“千行の実験”が、必ず背後にある。 技術は一日にしてならず。 ■ 技術が「今」にたどり着くまで 理論研究 → 基礎研究 → 実用化研究 → 実証検証 → 製品コンセプト → 課題との紐づけ → ビジネスモデル検討 → POC構築……。 この長いステップを、何度も何度も繰り返す。 一足飛びに最終製品なんて生まれない。 AIも、スマホも、IoTも、同じ道を歩んできた。 そして今、私たちの世代がその“連続の先端”に立っている。 ■ 明日から、私たちがつなぐ未来へ だからこそ、私は思う。 技術の未来は、決して遠い場所にあるわけじゃない。 それは“今日の積み...

😲 驚きのはじまり：「AI」って何の略？ 「AIって、愛の略じゃないの？」——そう冗談を言いたくなるほど、AIという言葉はすっかり私たちの生活に溶け込んでいる。 けれど、本当の意味を知っている人は意外と少ない。 AIとは、 Artificial Intelligence（アーティフィシャル・インテリジェンス） の略。 日本語で言うと「人工知能」だ。つまり、人間のように“考える”ように見せるための仕組み。     💻 実は「考えて」いない!? ここがよくある誤解だ。AIは実際には「判断」しているわけではない。 それはあくまで プログラム処理 によって動いている。 人間の思考プロセスを しくみ化し、プログラムで表現 したものなのだ。 🧩 ニューラルネットワークの秘密 AIの裏側では、「 ニューラルネットワーク 」と呼ばれる基礎理論が動いている。 これは、人間の脳の神経細胞（ニューロン）が複雑に連携しながら信号をやり取りする様子をモデル化したもの。 言葉にすると高尚に聞こえるが、AIの本質は驚くほどシンプルだ。 その根幹にあるのは、 “YES”か“NO”の二択の判断 。 ⚙️ YESかNOか、それだけ たとえば、「この文は正しいか？」という問いに、AIはYESかNOで応える。 NOなら別の問いを出し、YESなら次のステップへ。 この 単純な二軸判断 を、膨大な回数繰り返すことで、まるで人間が考えているような結果を導き出す。 🎓 学生時代からの夢の技術 私は大学時代、この理論を初めて学んだ。あの頃はまだ「夢の技術」だったAIが、いまや誰もが使えるサービスになっている。 当時、多くの論文が山のように書かれ、最先端だったその理論が、いまやスマホの中で当たり前に動いているのだ。 🚀 実用化を支えたのは「積み上げ」 なぜ、こんなにも進化したのか。 答えは、 コンピューターリソースの発展 にある。 メモリやCPU、データベースの性能が飛躍的に伸び、さらに、研究者たちの 地道な努力の積み重ね があった。 AIは「研究」から「実践」へ、そして「サービス」へと成長した。 まさに「ローマは一日にして成らず」ならぬ、「AIは一夜にして賢くならず」だ。 💡 AIから学べる、人間の可能性 AIのすごさ...

日本人は“止まらない前提”に慣れすぎている 「うわっ！動いてない!?」 そんな瞬間、あなたはどうしますか？ 日本で暮らしていると、システムが“止まる”経験って本当に少ないですよね。電車の券売機が動かない場面なんて、ほとんど見たことがない。もし使いにくさを感じても、すぐ横に駅員さんが立っていて、笑顔で助けてくれる。銀行システムだって、事前に「メンテナンス時間です」と通知される以外で止まっている光景は、まず見ません。 あの頃の「システム停止＝大事件」 2000年頃、取引所のシステムが一度止まっただけで、新聞の一面を飾る大問題として報じられました。あのとき私はふと考えたのです。 「じゃあ、外国の取引所システムって、どのくらい安定してるんだろう？」 調べてみると、驚くべき事実が出てきました。 実はけっこう止まっているんです。なんと3カ月に1度くらいはトラブルが発生していて、オープンが少し遅れたり、一部の投資家だけアクセスできなかったり。 でも、それが新聞を騒がすことはほとんどありません。 なぜなら──「止まることが当たり前」という文化が根付いているからです。 外国製システムが日本にやってきた 最近は日本にも海外製システムが次々と導入されています。たとえばChatGPTのような生成AIサービス。便利だけれど、止まることもあるし、止まらなくても「え？この回答おかしくない？」という場面も珍しくありません。 つまり、世界標準は「システムは止まるもの」。 にもかかわらず、日本人は「止まらないこと」に慣れすぎている。だからこそ、止まった瞬間に焦ったり、イライラしたりしてしまうのです。 じゃあ、どうすればいいのか？ 答えはシンプルです。 止まってもイライラしないこと → 「ああ、よくあることだ」と心の余裕を持つ。 呼吸を整えること → 一度目を閉じて、深呼吸。瞑想してみるのもありです。 そして、再起動 → 多くの場合、システムは戻ってきます。人間も同じ。リセットして次に進めばいいのです。 アンケートでおこづかい稼ぎ     明日からの一歩 システムが止まる瞬間は、自分の心を見直すチャンスでもあります。 「止まるのが当たり前。だからこそ、立ち止まった時間をどう使うか。」 私はそう考えるようになりま...

24時間365日、止まらない幻想が生む“ぷすんぷすん”の危機 驚きの出発点 「えっ！？システムに休みなんているの？」 そう思ったあなた、ちょっと立ち止まって考えてみてください。 多くの人がこう考えます。 ――システムだから24時間365日動いていいんでしょ？問題ないんでしょ？ でも実際は、そんな安易な発想で作られたシステムが世の中には山ほどあるのです。 システムが休むときとは？ システム設計で重要なことのひとつに、「休む時間を考えてあげる」ことがあります。 「働き続けるわけです。休みなく」。 するとどうなるか？ どこかで必ず限界がやってきます。 ある日突然、煙を出して「ぷすんぷすん……」と止まってしまう。 ――まあ、それは冗談ですが（笑）。 本当の問題は、 アップデートやチェック、クールダウンをするタイミングがなくなる ことです。 動きっぱなしのシステムには、これらを行う余白がありません。 そして「止められないから」という理由で後回しにした結果、ある日突然大きなトラブルに直面するのです。 バスのドライバーに学べ 今はシステムを二重化して、交代させながら運用するという考え方も広がっています。 ですが、交代するなら交代できるように設計をしておかなくてはなりません。 ほら、バスのドライバーだって走行中にいきなり別の人に変わったりしませんよね？ 必ず車庫に戻って、引き継ぎをして、安全に交代します。 システム間でも、同じように“スムーズな交代”ができる仕組みを作る必要があるのです。 「勝手に動かしておけばいい」の末路 「システムは勝手に動かしておけばいい」――そんな設計思想で痛い目を見ている企業は少なくありません。 実際に私も数多くの現場を見てきましたが、ほとんどの場合「休息設計」を意識していないことが原因でした。 人間だって働き続ければ倒れるように、システムにも休息が必要なのです。 みんなにやさしい設計を システムにも休息を！ それは単にメンテナンスの都合ではなく、利用する人、運用する人、そして未来の利用者すべてにやさしい設計へとつながります。 「システム＝常に動くもの」という固定観念を一度壊し、どうすれば健全に長く働けるのかを考えること。 それこそがこれからの時代に求められるエンジニアの姿勢だと思いま...

 システム屋が語る、未来につなぐデータの話 「うわっ！こんなところに、昔の自分の日記が…」 開かれたノートに目を通した瞬間、あの頃の記憶が一気に蘇る。 そう、 データをためる って、そんな感覚に近いんです。 システムには「つなぐ」「見せる」「ためる」がある システムと一口に言っても、いろんな役割があります。 たとえば―― ・他のシステムと つなぐ 仕組み ・画面やアプリで 見せる 仕組み ・そして、静かに ためる 仕組み。 今回フォーカスするのは、「ためる」システム。 つまり、 データをストックするための基盤 です。 データを“ただ置く”では意味がない 「とりあえずデータ置いておけばいいでしょ？」 そう思っていた時期が私にもありました。 でもそれ、 使えない資料をダンボールに詰めて、屋根裏に放り込むようなもの 。 確かに、最近のAI技術で形式変換の手間は減ってきました。 でも、意味のないデータをいくら集めても、活用できない。 “金庫の中が全部ガラクタ”では、価値は生まれない んです。 「ためる」＝データベース。設計次第で価値が決まる データをためるためには「データベース」という箱が必要。 もちろん、これは無料じゃありません。 金庫と同じで、 “容量”にも“堅牢性”にもお金がかかる 。 だからこそ、どうためるかが重要。 今わかっている目的があるなら、データ構造も定義しやすい。 でも未来の目的は…予測できない。 見えない未来に向かって、何をどう残すか。 これが、システム屋としての腕の見せ所。 読めない文章、使えないデータ 昔の重要そうな文書を発掘しても、 「文字化けして読めない」「フォーマットが古すぎて開けない」 そんな経験、ありませんか？ これと同じことが、データの世界でも起こります。 だから私は思うんです。 「今」のデータも、「未来の誰か」が読めるようにしておこうって。 ワクワクする未来を、静かに支えるデータ基盤 データをためるって、地味に聞こえるかもしれません。 でもその一つひとつが、未来のシステムを支える 「種」 になる。 ワクワクしませんか？ 10年後、今貯めたデータがAIや未来のサービスに活用されるなんて。 アンケートでおこづかい稼ぎ   自宅でできる...

システムの重要性って誰が決めてるの？ ああ驚いた！システムの優先順位が「声の大きさ」で決まっていたなんて あなたの会社では、どのシステムが重要か、ちゃんとした基準がありますか？ 使っている人数？コスト？それとも、自分が担当しているかどうか？ 実は、社内で「このシステムが大事！」と一番叫んだ人の意見が通る、なんてことも珍しくありません 私の「絶対に譲れない」システム判断基準 でも、私にはひとつだけ、決して譲れない判断基準があります それは、「人の命に関わるかどうか」 これは、エンジニアとして何よりも大切にしている軸です かつて銀行系のシステムを担当していた頃、あるエラーが原因でATMが一斉停止したことがありました もしもこの障害が長引いていたら、給与の振込が止まり、医療費の支払いができない人が出ていたかもしれません 交通系システムでは、一つのバグが事故の引き金になる可能性もある 食品系のシステムでも、誤った成分表示や温度管理ミスが、命に関わる結果を生むこともあるんです そのシステム、止まったら1億円飛びますか？ 次に重要なのが「損失の大きさ」 そのシステムが止まったら、どれだけの金銭的損害が発生しますか？ 何百万円ではなく、億単位の損失が即座に発生するようなシステムであれば、それは十分に最優先にすべき対象です もちろん、全てのシステムに億単位の影響があるわけではありません だからこそ「損失の規模」というのは、判断の重要な一手になります 自分の感性も、大事にしていい そして最後に、私は「自分の感性」を信じています なぜなら、現場で長年培ってきた経験や直感は、数字では測れない価値を持つからです 「これはなんとなく危ない」「この仕組みは脆弱に見える」 そんな違和感が、実際に大きなトラブルの前兆だったこともありました 人命 → 損失 → 感性 これが、私のシステム判断の３つの軸です 声の大きさに振り回されない、自分の軸を持とう もちろん、社内にはいろんな事情があります 「このシステムを最優先に！」と圧をかけてくる上司や部門もいるでしょう でも、そんなときこそ、自分の軸を見失わずにいてほしいんです エンジニアとして、命を守る視点、未来を見据える視点を持ってほしい 『デイトラ』で仕事につながるWebスキルを身につけよ...