Digital Heroes: Guide to IT World

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

うわっ…この空気、仕事じゃなくて“サバイバル”だろ!? ■80cmという見えない制約 200人の開発要員が、まるで鮨詰めのように並ぶオフィス。 一人に与えられた横幅は、わずか80cm。前後も極端に狭く、椅子を引くだけで誰かにぶつかる。 最初は「まあ、こういうものか」と誰もが思っていた。だが時間が経つにつれ、空気が変わっていく。 ■静かに増えていく“イライラ” 立ち上がるのも一苦労。 トイレに行くにも気を遣う。 小さなストレスが積み重なり、徐々に言葉が荒くなる。 気づけば、明らかにイライラしている人が増えていた。 それでも、開発は止まらない。 夜中まで続く作業。 チームによっては、全員が12時まで残る。 一方で、バラバラに帰るチームもある。 この違いが、さらに空気を歪ませる。 「あのチームは帰っているのに、なぜ自分たちは残るのか」 見えない不公平感が、現場をさらに疲弊させていく。 ■限界ギリギリの現場 この現場は、正直に言えば“過酷”だった。 全員がギリギリの状態で、なんとかコードを書いている。 集中力も、判断力も、確実に落ちている。 それでも止められない。 ここで止まれば、すべてが崩れる。 そんなときだった。 ■突然の「外部の目」 保健所の検査が入った。 結果は、想像以上にシンプルだった。 「二酸化炭素濃度が高い」 つまり、この空間は“人が詰め込まれすぎている”という事実。 上層部は大慌てだった。 即座に改善指示が出る。 ■止められない現場、変えなければならない現実 しかし、開発は止められない。 納期は迫っている。 顧客は待っている。 そこで取られたのは、苦肉の策だった。 まず、窓を開けた。 これまで閉め切っていた窓を。 そう、この現場は“外に漏らさないため”に密閉されていた。 だが、その前提を崩した。 さらに、空気清浄機を大量に購入し、あらゆる場所に配置した。 正直、それが二酸化炭素をどれだけ吸収するかは分からない。 それでも、「何もしない」という選択肢はなかった。 ■わずかな改善と、続く監視 結果として、窓を開けたことで多少の改善は見られた。 だが、状況は“要監視”。 根本解決には至っていない。 それでも、現場は回り続ける。 「あと少しでピークが過ぎる」 「もう止まれ...

うわっ…人の密度でシステムの温度が上がるなんて思わなかった！ ■開発プロジェクトは“人が集まる生き物” 開発プロジェクトとは、単なる作業の集合体ではない。人が集まり、増え、そしてピークを迎える“生き物”だ。私が経験した200人を超えるプロジェクトも、最初から大規模だったわけではない。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■最初は静かに始まる 設計フェーズの最初は、わずか50人程度。要件定義の段階では、さらに少なかったはずだ。議論は深く、密度は高いが、物理的な空間にはまだ余裕がある。 しかし、設計が終わり、プログラミング開発、そしてテストへと進むにつれて状況は一変する。人は一気に増え、最も盛んな時期には200人を超える。 ■最大の問題は「人の置き場」 ここで必ず直面するのが、極めてシンプルでありながら深刻な問題だ。 ——この人たちは、どこで開発するのか？ 1年の中でこれだけ柔軟に人員が変動する。それに対応できる場所など、最初から用意されているわけではない。場所は決まっている。増えたからといって、簡単に広げられるものではない。 近くの会議室を長期で借りる案も出た。しかし、それは数十人単位の話であり、1人単位で柔軟に増減できるものではない。 ■現場で起きた“強引な最適化” 結局、他のプロジェクトに我慢してもらい、同じ開発スペースに人を押し込む形になった。それでも限界はある。 では、どうするか。 削るしかない。 削る対象はただ一つ——1人あたりのスペースだ。 部長を含め、全員のデスク幅を極限まで詰めていく。当時はデスクトップPCが標準だったが、それを横に倒し、その上にディスプレイを置くことで横幅を圧縮した。 ■1人、何センチ必要か？ その答えは、極めて現実的だった。 開発スペース：最大80センチ テストスペース：最大60センチ 実際に座ると、肘と肘が触れ合う。隣との距離はほぼゼロだ。これまで様々なプロジェクトを経験してきたが、あれほど狭い環境はなかった。 ■それでも人は増え続ける そんな極限の環境にもかかわらず、人はさらに増えていく。気づけば周囲は知らない人ばかりだ。プロジェクトの一体感というより、“流入する人波”に近い。 膝をすり合わせながら、コードを書く。テストをする。...

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

えっ、プログラミング言語の“完成形”が日本にあっただと!? ■COBOLだけではなかった 社会インフラを支える巨大システム。その裏側で、日立はCOBOLを手掛け、協会もリードしながら、日本国内で確固たる地位を築いていた。 しかし、本質はそこでは終わらない。 彼らは“言語”だけでなく、もっと根本的なものに手を伸ばしていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■システムの核に踏み込む サーバを作る。これは分かりやすい。 だが、システムを構築する上で絶対に避けて通れないものがある。 それがDB、データベースだ。 世界を見渡せば、MicrosoftのSQL Server、IBMのDB2、OracleのOracle。 主要なDBはほぼ海外製品が席巻していた。 その中で、日立は挑戦していた。 それがHiRDB。 ■言語の“さらに内側”へ HiRDBは、Cosminexusなど日立のシステム基盤と連携するDBだ。 だが本当に驚くべきはそこではない。 そのHiRDBを操作するためのSQL、つまり“DBを動かす言語”まで、日立は自ら設計していた。 しかもその名称は、あえてのSQL。 ややこしいが、これはHiRDB専用のSQLである。 ■なぜ独自SQLが必要なのか 実務でDBを触るとすぐに気づく。 同じSQLでも、DBごとに微妙に構文が違う。 「あれ？」 「なんでこう書くんだ？」 そう思いながら、例外的なルールを覚えていく。 それが現場の現実だ。 ■“癖がない”という価値 だが、DBを極めた分析屋たちはこう言っていた。 「HiRDBのSQLが一番癖がない」 構文が整っている。 規則性がある。 理解しやすい。 つまり、最も“自然に使える言語”だった。 Oracleでも、SQL Serverでも、どこかで違和感に出会う。 だがHiRDBは違う。 その違和感を排除する方向で設計されていた。 ■技術の深さと広がらなかった理由 残念ながら、HiRDBは世界的に広く普及したとは言えない。 しかし重要なのはそこではない。 DBそのものを作り、 その上で動く言語まで設計し、 さらに“人にとって分かりやすい形”に整える。 このレベルの要素技術を内製できるエンジニア集...

 システム構築プロジェクトは、多くのステークホルダーが関与し、複雑なタスクが絡み合う非常に繊細なプロセスです。しかし、その成功は適切なマネジメントとチームワークにかかっています。ここでは、プロジェクトを成功に導くためのポイントを解説します。 1. スケジュールコントロールがカギ プロジェクトマネージャー（PM）のスケジュール管理能力は、プロジェクト成功の最重要要素です。PMはスケジュールの調整だけでなく、各タスクの依存関係を理解し、現実的な計画を立てる必要があります。プロジェクトの進捗状況を適切に監視し、問題が発生した場合は迅速に対応できる体制を整えましょう。 2. バッファを抱え込まない 各担当者が自分の作業にバッファを持ちすぎると、全体のスケジュールに影響を及ぼします。「遅れたらどうしよう」と考え、過剰に安全マージンを取るのは、プロジェクト全体の効率を損なう原因です。遅延が発生しても、PMが調整役として機能するため、担当者は冷静に状況を共有し、解決を図ることが重要です。 3. 信頼だけに頼らない PMを全面的に信用するのではなく、各自が関与する範囲の責任を持つ姿勢が必要です。例えば、「報告を任せる」「状況を待つ」という受動的な態度ではなく、自ら進捗を確認し、適切なタイミングで状況を共有する意識が大切です。このように、全員が能動的に動くことで、PMも全体像を把握しやすくなり、円滑な運営が可能になります。 4. 先人の知恵を活用する 過去の成功事例やベストプラクティスは、プロジェクトを効率的に進めるための貴重な指針となります。文書化されたテンプレートやフレームワークを活用することで、リスクを最小限に抑えられます。また、経験豊富なエンジニアやコンサルタントからのアドバイスを受け入れる柔軟性を持つことも重要です。 まとめ システム構築プロジェクトの成功は、単に技術力だけではなく、チーム全体のコミュニケーションと責任意識、PMのスケジュール管理能力にかかっています。それぞれが自分の役割を果たしつつ、協力し合うことで、複雑なプロジェクトでも確実に成果を上げることができます。