Digital Heroes: Guide to IT World

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

「書かないエンジニア」という衝撃 うわっ!? コードを書かないのにシステムを支配している人がいる——。 社会人7年目、私は200人を超える大規模開発プロジェクトに構成管理リーダーとして参画していた。5社が入り乱れる現場で、各種基準書を整備し、チーム全体を“ルール”で誘導する役割だった。 そんな中、最も密に連携していたのがサーバ管理担当だった。構成管理とサーバ管理は、現場を支える両輪だ。自然と会話も増えていった。 ある日、何気なく聞いた。 「Javaとか、どれくらい書くんですか？」 返ってきたのは、予想外の一言だった。 「いや、書いたことないですね」 現場を動かす“スクリプトという言語” 驚いた私は、さらに聞いた。 「じゃあ、何もプログラムしないんですか？」 彼は少し笑って答えた。 「いや、簡単なものならやってますよ」 そこで出てきたのが、Bashに代表されるシェルスクリプト、そしてWindowsのVBスクリプトだった。 ここで、システムの“裏側の構造”が一気に見えてきた。 サーバは「JOB」という単位で管理される。処理はすべてスケジュールされ、自動化されている。そして、その統制を担うのがJP1だ。 しかしJP1は、単独では動かない。OSの機能を呼び出す際には、必ずスクリプトを介する。つまり、シェルスクリプトやVBスクリプトが“翻訳者”として、JOBの指示をサーバに伝えている。 システムは「3層」で動いている ここで整理すると、構造はこうだ。 ・全体統制：JP1（JOB管理） ・実行主体：各サーバ ・接続役：スクリプト（Shell / VB） そして、その上で我々のJavaなどのアプリケーションが動く。 つまり、派手なアプリケーションの裏側には、無数のスクリプトが存在し、それらがシステム全体を支えているのだ。 “小さなコード”がシステムを支配する 週次処理、バッチ処理、ログ取得、監視連携—— これらはすべて、小さなスクリプトの積み重ねで成り立っている。 大きなプログラムではない。だが、その数は膨大で、どれ一つ欠けてもシステムは止まる。 彼らの仕事は目立たない。しかし、確実に“全体を動かしている”。 エンジニアの価値はどこにあるのか ここで一つ、議論を投げかけたい。 「高度な言語で大規模なコードを書ける人...

えっ!? プログラムを書かないエンジニアが、システムを支えている——そんな現場に出会った。 ■巨大プロジェクトの裏側 私が関わっていたのは、200人を超える大規模プロジェクトだった。日本の中枢を支える金融機関の中核企業。その基幹システムの一つを、COBOLからJavaへと変換するという、まさに時代の転換点とも言える取り組みだ。 私は構成管理担当として参画していた。日々、膨大なソースコードやバージョン、リリースの整合性を保つ役割だ。Javaのプログラムもいくつか書いていたが、主戦場はあくまで“整えること”。     ■環境を守る、もう一つの主役 そんな中で、常に一緒に戦っていたのがサーバ担当だった。開発者が安心してコードを書けるのは、安定した環境があってこそ。その基盤を支えていたのが彼らだ。 自然と会話も増え、距離も近くなったある日、ふと疑問が浮かんだ。 「サーバ担当って、Javaの構成も詳しいし、やっぱりプログラムも上手いんですよね？」 ■予想外の答え 返ってきた答えは、想像とまったく違っていた。 「いや、私、プログラムできないんですよ」 一瞬、思考が止まった。自分はプログラムから入った人間だ。コードを書き、動かし、その中でシステムを理解してきた。だからこそ、プログラムができないという言葉が、どうしても結びつかなかった。 ■異なる入口、同じゴール 話を聞いていくうちに、その違いが少しずつ見えてきた。 自分は“動くもの”から入っている。だから、処理の流れやロジックはイメージしやすい。一方で彼は、サーバ構成という“土台”から入っていた。 「少しずつ組み立てていくんですよ。ブロックみたいに」 その言葉が妙に印象に残った。 ■デジタルのレゴ 確かに彼は、分厚い技術書を片手に、一つひとつパーツを組み合わせるように環境を構築していた。サーバ、ミドルウェア、ネットワーク、設定ファイル——それぞれを積み上げて、ひとつの“動く世界”を作り上げる。 それはまるで、デジタルのレゴのようだった。 プログラムを書くことだけが“ものづくり”ではない。環境を組み上げることもまた、創造なのだと気づかされた瞬間だった。 ■キャリアは一つじゃない この経験から強く感じたのは、エンジニアのキャリアに正解はないということだ。 コードから入る人...

うわっ、コードより先に“人間関係”が壊れる瞬間がある——。 ■巨大プロジェクトの中で 社会人7年目、私は開発チームの構成管理チームをリードしていた。プロジェクト規模は拡大を続け、ついに200人を超える体制へ。プログラマー、テスター、インフラ、運用——あらゆる役割が入り乱れる中で、私たち構成管理は「見えない秩序」を作る役割を担っていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ドキュメントという名の“設計図” 私たちは数え切れないほどのドキュメントを作成してきた。 ・プログラム作成基準書 ・環境設定手順 ・パッケージ適用基準書 ・デプロイ手順書 一見すると、テンプレートで回せそうに見える。しかし現実は違う。顧客環境ごとに前提が変わり、細部はすべて作り直しになる。つまり、構成管理とは「コピペ職人」ではなく「環境適応型アーキテクト」なのだ。 ■しかし、1つの壁にぶつかる あるとき、私は気づいた。 「このドキュメント、自分たちだけでは完成しない」 どれだけ整理し、構造化しても、最後のピースが埋まらない。 それは——“現実の環境”だった。 ■構成管理が最も頼る相手 では、構成管理担当は誰にヘルプを求めるのか？ 答えは明確だ。サーバ担当である。 ■サーバとプログラムは分離できない サーバ担当は、サーバ構成やDB構成を設計・管理する。一方で、構成管理はプログラムの構成を握る。しかしこの2つは、決して独立しない。 ・サーバに導入されたパッケージ情報を把握しなければならない ・プログラムが必要とするパッケージはサーバに導入されなければならない どちらが欠けても、アプリケーションは動かない。 ■“交差点”に立つ役割 構成管理は、単なるドキュメント管理ではない。 それは「プログラムチーム」と「環境チーム」が交わる交差点だ。 お客様の環境を見るチームと、コードを書くチーム。その2つが接続されることで、初めて“動くシステム”が生まれる。 ■ここで1つの問い では、構成管理はどちら側の人間なのか？ 開発側か、インフラ側か。 私は断言する。 どちらでもない。だからこそ価値がある。 ■議論を呼ぶポイント 多くのプロジェクトでは、構成管理は「裏方」と見られがちだ。しかし本当にそうだろう...

うわっ…コードを書けるだけでは、巨大プロジェクトは1ミリも前に進まない！ ■7年目、200人の渦の中へ あの時、私はエンジニア7年目。200人を超える巨大プロジェクトの「構成管理担当」を任された。CobolからJavaへの大規模な移行。会社としても勝負の案件だった。周囲からは「Javaの専門家」として見られていたが、正直に言えば、それは半分正しく、半分誤解だった。     なぜなら、私は前のプロジェクトで社内フレームワーク「Justware」の導入サポートをしていた。その経験が評価され、この現場に呼ばれただけだったからだ。だが現場に入れば、そんな事情は関係ない。「Javaといえば構成管理が肝」——その期待のもと、私は中心に立たされた。 ■構成管理という“見えない支配” 構成管理とは何か？それは単なるバージョン管理ではない。 誰が、どのルールで、どのパッケージを使い、どうやって統合するか——プロジェクトの秩序そのものだ。 200人の開発者がそれぞれにコードを書く。その全てを束ね、「最新版」を定義する。そしてその先にいるのは、環境エンジニアだ。彼らがデプロイし、システムは初めて動く。 つまり、構成管理は“開発の終点”ではなく、“運用の入口”でもある。ここを間違えれば、全てが崩れる。 ■しかし、現実はそんなに甘くない 問題はすぐに表面化した。 「このライブラリを使いたい」 「そのルールは非効率だ」 「なぜこの命名規則なのか」 200人いれば、200通りの正義がある。ルールを決めることは、誰かの自由を制限することでもある。議論は常に衝突を伴った。 ここで気づいたのは、「技術的に正しいこと」と「プロジェクトが進むこと」は別物だという現実だった。 正論だけでは、人は動かない。 ■開発者の先にいる“もう一つの主役” さらに重要なのは、開発者の先にいる存在だ。 環境エンジニア、そして本番環境を支える対顧客チーム。彼らはシステムの提案を行いながら、運用も担う。 いわゆる「System Engineer」と一括りにされるが、その実態は千差万別だ。コードを書く者、環境を整える者、顧客と向き合う者。それぞれが異なる価値を持ち、異なる責任を背負っている。 にもかかわらず、開発者中心の議論が支配すると、彼らの視点は後回しにされる。結果...

うわっ…コードを書いていないのに、プロジェクトが崩壊する!? ■Cobol時代にはなかった“新たな難しさ” かつてCobol中心の時代、システムは比較的シンプルだった。構成も閉じた世界で管理され、外部依存は限定的だった。しかし、Javaへの移行とともに、ある領域が一気に難しくなった。それが「構成管理」、特にライブラリ管理である。 ■Javaの進化が生んだ“自由と混乱” Javaは極めて拡張性が高い言語だ。豊富な標準機能に加え、世界中の開発者が機能をパッケージやクラスとして公開している。これにより、ゼロから作らなくても高度な機能を簡単に取り込めるようになった。これは生産性の飛躍的向上を意味する。 だが同時に、「どれを使う？」という新たな判断が発生した。     ■パッケージ選定という意思決定の重さ 各パッケージは、世界中の優秀なエンジニアが作り込んだものだ。設計も品質も高く、使わなければ開発規模は膨大になる。だが、選択を誤れば、システム全体に影響を及ぼす。 しかも、必要な機能は複数のパッケージで実現できる場合も多い。どれを選ぶかは、単なる技術選定ではなく、プロジェクトの将来を左右する経営判断に近い。 ■最大のリスクは“見えないセキュリティ” 問題はセキュリティだ。このパッケージ、本当に信じていいのか？変なコードが仕込まれていないか？安全性は？安定性は？ 情報が限られる中、ネットを検索し、仕様を読み、過去の実績を調べる。かつてはSun Microsystemsの情報を読み漁りながら判断することもあった。しかし、それでも確信は持てない。 ■終わらないアップデートとバージョン地獄 さらに難しいのは、これらのパッケージが常に進化していることだ。アップデートは頻繁に行われ、新機能や修正が追加される。だが、複数のパッケージを組み合わせると、バージョンの整合性が問題になる。 あるパッケージを更新すると、別のパッケージと互換性が崩れ、動かなくなる。逆に更新しなければ、セキュリティリスクが高まる。このトレードオフは、現場に重い意思決定を突きつける。 ■それは“迷宮の入り口”だった こうして、構成管理は単なる管理作業ではなくなった。技術、セキュリティ、運用、将来性——あらゆる要素を考慮する複雑な意思決定プロセスへと変わったのだ。 そして...

うわっ…巨大組織の心臓が、こんなに小さいなんて誰が想像できるだろうか！ ■社会人6年目、想像していた「大組織」 社会人6年目。私は、日本の金融業界の中心を支える基幹システムのプロジェクトにアサインされた。 規模は200人超。複数ベンダーが参画し、名だたる企業が並ぶ。 「これは完全に、大組織での分業戦だな」 そう思っていた。日立のプロパーも多数入り、重厚なマネジメント体制が敷かれている——はずだった。     ■びっくりするほど“小さい本体” しかし、現場に入って目にした光景は、まったく違っていた。 机の一列に並ぶ、たった6人。 部長はそこにはいないが、その席の横に、課長、主任3人、担当2人。 この6人が、すべてを回していた。 周囲には確かに人がいる。 ベンダーは4社、それぞれ平時でも20名以上。 開発ピーク時には、テスト要員も含めて200人を超える。 だが、意思決定と全体制御は、この6人に集約されていた。 「本体は、ここか…」 その瞬間、プロジェクトの構造が一気に見えた。 ■構成管理チームという“中枢神経” そんな中、私は新たに切り出された構成管理チームを任された。 理由は明確だった。Java化による構成の複雑性。 だが、すぐに気づく。 これは単なる「構成を管理する仕事」ではない。 各チームごとに開発スタイルが違う。 ビルド方法、ブランチ戦略、リリース手順——すべてがバラバラ。 つまり、必要なのは統制ではなく「調整」だった。 ■本当の仕事は“すり合わせ” 構成管理とは、コードを管理することではない。 チーム同士の前提を揃え、衝突を防ぎ、全体最適に導くこと。 4社のベンダー、それぞれの文化。 20人単位のチームが複数動く中で、わずかなズレが致命傷になる。 私は、構成を通じてそれを繋ぐ役割だった。 「ここ、どう合わせます？」 その一言が、プロジェクト全体のスピードを変える。 ■6人が200人を動かす理由 なぜ6人で回るのか。 答えはシンプルだ。 ・意思決定が速い ・構造を理解している ・全体を俯瞰できる 人数ではない。 構造と役割が、すべてを決める。 そして、その中に「調整役」が組み込まれていること。 これが、巨大プロジェクトを動かす本質だった。 ■身震いした責任と、...

動くシステムはある。でも未来のJava版をどう描くか？ ああっ、まるでパズルのピースが逆さまに飛んでくるようだ！ 私が任されたのは、金融システムのCobolからJavaへの変換プロジェクトでの構成管理だ。 すでにCobolで動いているシステムがあり、設計書も残っている。 だが、それを最新のJava設計書に書き換え、プログラムとして組み上げなければならない。     多様なチーム、複雑な利害 プロジェクトには、日立製作所を1次受けとして、5社ほどの2次受けが参加していた。 各社、Cobolが分かるエンジニア、Javaが分かるエンジニア、そして金融分野に精通した設計者を揃えている。 優秀な2次受けベンダーの方々からの圧も相当で、緊張感は増すばかりだ。 Cobolの常識とJavaの自由度 Cobolの世界では、プログラムの作り方や書く環境はほぼ決まっている。 構成管理といえば、ソースの管理だ。 見出し部、環境部、データ部、手続き部などを決め、各チームの書き方を揃えるのが定石だった。 しかし、Javaとなると話は複雑になる。 書き方のルールだけでなく、パッケージ基準やソース構成、オブジェクト指向を活用した共通クラス構成まで考慮する必要がある。 設計書からDebug、バージョン管理まで まず着手したのは、Java設計書の整理だ。 Cobol設計書を参照しつつ、Javaのクラス構成やパッケージ体系に落とし込む作業。 各チームがバラバラに動くと、後々のDebugやテストで混乱する。 だからこそ、Debug順序も先に決めておく。 構成管理の肝は、バージョン管理だ。 Javaのように複雑な環境では、少しのずれが全体の破綻につながる。 GitやSVNを使い、各チームのコミットルールを統一する。 コミット単位、ブランチ戦略、マージ方針まで細かく定め、2次受け全体で共有する。 学びと挑戦の統合 一方で、Cobol時代の常識は無視できない。 既存の環境・手続き・データ部は大きな制約条件だ。 それを踏まえつつ、Javaのモダンな書き方を適用する。 オブジェクト指向の利点を活かし、共通クラスやライブラリの再利用も進める。 毎日の会議では、5社の代表者が設計書とコードの違いを詰める。 Cobol出身者の意見、Javaエン...