Digital Heroes: Guide to IT World

システムは完成品ではない。育てるものだ。 Configurationが変えた私のシステム観 うわっ！システムがプログラムを書かずに姿を変え始めた！ ■ システム構築には自信があった システム開発に携わってきて、気が付けばプロジェクトをコントロールする立場になって8年が経っていた。 若い頃はJavaを中心としたシステム開発に関わり、設計から開発、テスト、運用まで一通り経験してきた。 正直に言えば、システム構築にはそこそこ自信がついていた。 要件を聞く。 設計する。 開発する。 テストする。 リリースする。 そんな流れが当たり前だと思っていた。 ところが、その考え方を大きく揺さぶられる経験をした。 海外製パッケージシステムの導入プロジェクトだった。 ■ ロンドンで学んだ新しいシステム思想 お客様のシステムを構築するため、私はロンドンで2週間の研修を受けることになった。 そこで学んだのは単なる製品知識ではない。 システム構造そのものの考え方だった。 当時の私は、「お客様の要件はプログラムで実現するもの」だと思っていた。 もちろん設定は使う。 OSの設定。 サーバ設定。 ログの保存期間。 メモリ割り当て。 ジョブスケジュール。 プログラムを最適に動かし、運用しやすくするためのConfigurationである。 つまり、Configurationはシステムを支える裏方だった。 ■ Configurationの役割がまったく違った しかし、そのパッケージは違った。 驚くほど多くのConfigurationが存在していたのである。 しかも目的が違う。 システムを動かすためではない。 顧客ごとにシステムを変えるために存在していた。 承認フロー。 画面項目。 入力ルール。 通知条件。 業務プロセス。 顧客ごとの個別要件をConfigurationで吸収していた。 最初は驚いた。 「こんなことまで設定でできるのか？」 「これ、本当にプログラムを書かなくていいのか？」 研修中、何度もそんな疑問を持った。 ■ システムは完成品ではなく成長するもの だが次第に理解していった。 このシステムは完成品ではない。 成長することを前提に設計されているのだ。 運用しながら改善する。 顧客から新しい要望が出る。 すぐに開発しない。 まずConfigurationで吸収する。 それでも足りなければ次のリリ...

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

プラットフォームを作っていたのに、連携を“深く”考えていなかった頃の話 うわっ！まさか、そこから使われるとは——！ システム屋をやっていると、ふと立ち止まって過去を振り返る瞬間が、何度も訪れる。「あの時、どうしておけばよかったんだろう」「今の自分なら、こう設計するのに」。そんな後悔にも似た問いが、頭をよぎる。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 振り返りは、改修のたびにやってくる システムは一度作って終わりではない。改修され、拡張され、想定外の使われ方をしながら成長していく。そのたびに、「あの設計、甘かったな」「ここ、もう一段考えるべきだったな」と、新しい視点が生まれる。そして不思議なことに、自分自身も同時に進化している。学び続けることで、見える景色が確実に変わっていく。 ■ プラットフォームを作っていたのに 今だから正直に言える。 当時、プラットフォームを作っていながら、 システム間連携の本当の大切さが分かっていなかった 。単体としては完成度が高くても、他システムとどう“シェイクハンズ”するのか。その握手が弱ければ、全体は簡単に崩れる。 ■ データが欠損した瞬間に、すべてが分かる 特に痛感したのが、データ欠損時の設計だ。 「落ちない」ことよりも、「落ちたときにどう振る舞うか」。 今ならはっきり分かる。 ここ、めっちゃ大切。 銀行間連携、会社間連携、さらにはグローバルシステムと日本独自システムの橋渡し。日々、その違いに悩まされながら、当時の自分に言いたくなる。「もっと連携を意識しろ」と。 ■ 今このタスクをやるなら、見える景色が違う もし今、同じタスクを任されたら。 きっと、まったく違う設計をするだろう。 その背景には、 メッセージキューイングシステム の経験がある。非同期、疎結合、耐障害性。これをやっていたからこそ、グローバルのエンジニアとも同じ言語で語れた。 ■ 15年以上経って、原点に戻る 気づけば15年以上が経ち、MQシステムのプロダクトオーナーまでやらせていただいた。今の判断軸は、すべてあの頃の経験が基になっている。 システムは進化していく。でも、過去の思想や技術を、きちんと引き継いでいくことが、次の進化を支える。 振り返ることは、後悔じゃない。 未来の精...

育てたつもりが、育てられていたのは自分だった話 うわっ、気づいたら終わっていた――そんな感覚が、正直なところだ。 30人の新人講師を務めたこの研修は、期間にして4カ月もない、短いプロジェクトだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■短期決戦、30人×設計×プログラミング 最初に決まっていたのは、「短期決戦」だということ。 設計の考え方から、プログラミング、そして実際のシステム構築まで。 本来なら、もっと時間をかけたい内容を、一気に30人へ伝える。 正直に言えば、自分自身も経験豊富な訳ではない。 完璧な答えを持っている講師ではなかったと思う。 それでも、「現場で生きるための考え方」だけは、全力で渡した。 ■伝えきれないことが、山ほどある 日が経つにつれ、思いは増えていった。 「これも伝えたい」「あれも必要だ」 でも、現実は時間切れ。 まだまだ伝えられていないことが、たくさんある気がする。 それでも、やれることはやった。 限られた時間の中で、今の自分が出せるものは、すべて出した。 ■最後の報告会と、ほっとした瞬間 最後の報告会が終わった瞬間、肩の力が一気に抜けた。 「ああ、終わったな」 かなり、ほっとした。 その後、先輩と交わした「お疲れランチ」。 何気ない会話なのに、不思議と達成感があった。 ■新人たちは、それぞれの現場へ ほどなくして、各新人にプロジェクト割り当ての指示が出た。 みんな、現場へ散っていく。 これからサーバ関係で生きる人。 提案で勝負していく人。 黙々とプログラムを書いていく人。 道は違っても、同じスタートラインに立った仲間たちだ。 それぞれのプロジェクトで、うまく頑張ってくれるといいな、と心から思う。 ■育てた先に、自分の次がある ほっとした。 でも、同時に気づいた。 自分にも、次がある。 教える側として走り切ったこの経験は、確実に次の一歩につながっている。 完璧じゃなくてもいい。 やれることを、やり切ればいい。 私ならできる！明日から踏み出す

言語でも理論でもない。最後に立ちはだかったのは、意外すぎる“敵”だった うわっ、まさかそこ!?——今振り返っても、プログラミングで一番苦労したポイントは、当時の自分の想像を完全に裏切っていました。     ■ プログラムで一番難しかったのは何だろう？ 今では自動でできるようになったことも、昔は一つひとつが壁でした。大学時代、C/C++の分厚い本を常にカバンに入れ、電車の中でも、空き時間でも眺めていました。理解できない。読んでも腑に落ちない。それでも何とか分かろうとして、サンプルコードを何度も作り直す。コンパイルエラーと格闘しながら、頭を抱える日々でした。 ■ 社会人になって、Javaで「ジャバジャバ」 社会人になると、言語はJavaへ。ここで立ちはだかったのがオブジェクト指向です。「オブジェクト指向とは」という本が、完全にバイブルになりました。クラス、継承、インターフェース。理屈は分かるけど、なぜそう設計するのかが分からない。何度も読み返し、コードを書いては壊し、少しずつ感覚をつかんでいきました。 ■ DBは意外とシンプルだった 一方で、DBは思ったよりも分かりやすかった。スキーマの考え方さえ理解できれば、要は整理しているだけ。データをどう分類し、どう関連づけるか。ロジックというより、頭の中をきれいに整頓する感覚でした。 ■ オブジェクト・パターンとの格闘 デザインパターンは正直、苦戦しました。理解できないパターン、結局使えなかったパターンも山ほどあります。それでも「知っている」ことが後で効く場面は確実にあった。全部を使いこなせなくても、引き出しに入っていること自体が価値だったのだと思います。 ■ 本当に一番苦労したのは「空白」 そして、最終的に一番苦労したのは、まさかの「空白」でした。インデント、スペース、タブ。どのテキストツールを使うのが一番良いのか、という悩みも重要でした。IDE（統合開発ツール）の機能がどんどん拡張されていったのもこの頃。でも結局、シンプルで軽快なSakuraエディタが一番しっくりきた。気づけば20年以上使い続けているのは、ExcelとSakuraくらいです。 ■ いつの間にか、言語は増えていた 使えるようになった言語は、C/C++、Java、Cobol、JavaScript、Python、VB、...