スキップしてメイン コンテンツに移動

投稿

ブログを翻訳

酸素が足りない開発現場——200人が詰め込まれた「80cmの限界」が組織を壊す瞬間

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

システム屋に太った人はいない?——80cmの戦場が突きつけた“非情な現実”

うわっ…人間って、ここまで圧縮できるのか!? ■80cmという名の“戦場” 前回のBlogで、私は「一人80cmの空間設計」について書いた。 あれは単なる効率化の話ではない。現場では、それは完全に“戦場の設計図”だった。 開発がMAXに達したあの時、長机がずらりと並び、そこに一人80cmの幅でパソコンと椅子を配置する。 椅子はパイプ椅子。クッションなどない。 かばんは足元に押し込む。ロッカー?そんな余裕はない。 とにかく、人を集める。 “もう集められるだけ集めた”というのが正直な感覚だった。 ■圧縮された人間関係 その結果、どうなったか。 まず、空気が変わる。 人と人との距離が近すぎると、思考も感情も摩擦を起こす。 キーボードを叩く音、椅子のきしみ、ため息。 すべてが増幅される。 当然、イライラしている人も増えていった。 だが、それでもプロジェクトは止まらない。 いや、止められない。 ■ふと気づいた違和感 そんな極限状態の中で、ある違和感に気づいた。 「あれ?太っている人、少なくないか?」 統計を取ったわけではない。 だが、直感的にそう感じた。 ■例外は、確かにいた もちろん、ゼロではない。 数人はいた。 ただ、その姿が印象的だった。 狭い80cmのスペースに、一生懸命、自分の体を“収めている”。 椅子の幅、机の下の空間、隣との境界。 すべてに気を遣いながら、なんとか仕事をしている。 それは努力というより、“適応”だった。 ■選べない現実 ここで重要なのは一つ。 人の選抜に、体格は使えない。 そんな基準はあり得ないし、あってはならない。 だが現場では、物理的制約がすべてに影響を与える。 結果として、 「我慢してもらうしかない」 という結論に行き着く。 これが、美しい話か? 違う。 だが、これが現実だ。 ■鮨詰めの中から生まれるもの あの空間は、まさに“鮨詰め”だった。 だが、その中から、日本を支えるシステムが生まれていく。 誰かが無理をし、誰かが耐え、誰かが調整する。 その積み重ねで、プロダクトは完成する。 クラウドだ、DXだ、と言われる時代でも、 最終的にシステムを作るのは“人”だ。 そしてその人は、時に80cmの中で戦っている。 ■ビジネスとしての示唆 ここから...

80センチの戦場——200人プロジェクトが教えた「空間」と「成果」のリアル

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

優しさは武器になるのか?——200人プロジェクトで出会った“静かなリーダー”

うわっ…こんなにも“戦い方”が違うのか!? ■システム担当者という幻想 「システム担当者」と一言で言っても、その中身は驚くほど多様だ。 プログラマーと呼ばれる人たちも同じ。 パソコン一つで作業をする職種だからといって、全員が強く押し切るタイプとは限らない。 むしろ現場に入ると、その多様性に戸惑う。 前のプロジェクトでも、リードするイメージのなかった同期が、いつの間にか全体を引っ張っていた。 役割は肩書きでは決まらない。 現場での振る舞いが、その人のポジションを作る。     ■200人プロジェクトという“圧力” 社会人6年目。 私はMAX200人を超えるプロジェクトに入った。 規模が大きくなるにつれ、プロパーのメンバーも後から増えてくる。 組織は流動的で、常に変化し続けていた。 そんな中、隣のプロジェクトで中堅として活躍していた同期が、こちらに移ってきた。 彼は構成管理担当として加わることになった。 ■怒らない男の戦い方 彼を一言で表すなら——とにかく穏やか。 もしかしたら「怒る」という感情を知らないのではないかと思うほどだ。 人の話を真摯に聞く。 そして、ゆっくりと話す。 構成管理という役割は、各チームからの要望が集中する。 時には無理難題も飛んでくる。 それでも彼は、一つ一つ丁寧に耳を傾け、ゆっくりと回答を作っていく。 当然、時間はかかる。 彼はいつも終電だった。 一度、体調を崩して来られなくなったこともあったらしい。 「リハビリ期間なんだよ」と笑いながら話していた。 それでも彼は変わらなかった。 どんな時も、人に向き合う姿勢を崩さなかった。 ■理想と現実の狭間で 正直に言えば、私は迷っていた。 彼の姿勢は、間違いなく見習うべきものだ。 だが、仕事が山積みのプロジェクトで、そのやり方は成立するのか。 スピードが求められる現場で、丁寧さは時にリスクにもなる。 私たちは、終電まで並んでパソコンを叩く日々を過ごした。 彼がいてくれて良かった。 話を聞いてくれる存在がいるだけで、抱え込まずに済んだ。 だが同時に思う。 一度来られなくなった後、リハビリと言いながら終電まで働くこの状態は、本当に正しいのか。 ■正解のない世界で この世界に、明確な正解はない。 速さで押し切る...

COBOLの職人は“絶滅”するのか?——200人プロジェクトが証明した言語進化の真実

うわっ…言語が変わるだけで、人はここまで不安になるのか!? ■社会人6年目、突然の「Java化」 社会人6年目。私は、日本の金融業界の中心を司る巨大企業の基幹システム刷新プロジェクトにいた。これまで長年、COBOLで作り上げられてきた巨大なシステム。その変換先として提示されたのが「Java」だった。 最大時には200人を超える大規模プロジェクト。だが現場に広がったのは期待ではなく、不安だった。 「COBOLしかやってきていない自分たちは、Javaに対応できるのか?」 ■COBOLという“設計至上主義” COBOLは手続き型言語だ。プログラムは上から下へ、順番通りに積み上げる。 一行の文字数、配置、メモリの使い方まで厳密に意識しながら書く。 部品を呼び出すというより、「業務の流れ」をそのままコードに落とし込む。 だからこそ、設計がすべてだった。 設計で全体の順序を完璧に組み立て、それを忠実にコードに写す。 このスタイルに慣れたエンジニアにとって、「自由度の高いJava」は未知の世界に見えた。 ■Javaがもたらした“構造の解放” しかし、実際にプロジェクトが動き出すと、状況は大きく変わった。 Javaはオブジェクト指向をベースに、部品化・再利用・柔軟な構造を許容する。 さらに、メモリ管理の負担も軽減されている。 COBOL時代のように、細かい領域を意識し続ける必要はない。 この“制約の解放”が、現場に新しい風を吹き込んだ。 設計者もプログラマーも、思った以上にスムーズに適応していったのだ。 ■「言語は違えど、本質は同じ」 振り返ると、気づくことがある。 プログラム言語は違っても、「構造を理解し、論理を組み立てる」という本質は変わらない。 実際、Java以降の言語は構造が似ている。 現在主流のPythonやRubyといったスクリプト言語も、オブジェクト指向ベースであり、英語に近い記述で理解しやすい。 つまり、一つの言語で“構造”を理解した人は、次の言語にも応用が効くのだ。 当時のJava移行は、今で言えば「Javaからクラウド(Lambdaなど)への移行」に近いインパクトだった。 それでも、現場は乗り越えた。 ■200人が証明した「進化できる力」 最終的に、この200人規模のプロジェクトは成立した。 COBOLの...

英語でコードを書く時代が来た!?——“技術×言語”で進化するエンジニアの新常識

Cobol世代からAI時代へ——学び方が変わる瞬間 うわっ…英語ができないとコードすら書けなくなるのか!? ■「Javaってどう学べばいいの?」という時代 社会人になりたての頃、Cobolをずっと習ってきた先輩たちから、こんなことを聞かれた。 「Javaって、どうやって学べばいいんだ?」 今なら簡単だ。YouTubeを開けば、いくらでも解説動画がある。 だが当時は違った。まだYouTubeはそこまで流行っていなかった。 だから、基本は“本”。 それが唯一の学習手段だった。     ■分厚い本=ステータスだった時代 Javaの日本語の本も確かにあった。 しかし、正直に言えば難しかった。 理解が追いつかない。 読み進めるほどに、自信が削られていく。 そんな中で、多くのエンジニアが持っていたのが、オライリーの分厚い本だった。 あの本を持っていること自体がステータスだった。 「これを読んでいる自分は、できるエンジニアだ」 だが現実は違う。 その分厚さと難解さに、多くの人が挫折していった。 ■答えはシンプルだった——英語で学ぶ では、どうすれば良かったのか。 答えはシンプルだった。 “英語で学ぶ” 最新の情報は、いつも英語から始まる。 だから英語の本を読み漁るしかなかった。 辞書を片手に、一文ずつ理解していく。 正直、かなり難しかった。 それでも、得られるものは大きかった。 ■“システム英語”という武器 そこには、単なる英語以上の価値があった。 「システム特有の言い回し」が身についたのだ。 これは普通の英会話では絶対に学べない。 そもそも、英会話の先生でシステム開発を理解している人はほとんどいない。 日本の開発事情を理解している人もいない。 だからこそ思う。 「システムを英語で学ぶ」のは、非常に合理的な選択だ。 ■今の時代の学び方はどう変わったか では、今の人たちはどうしているのだろうか? YouTube?ネット記事? 確かに、それも正解だ。 だが、もう一歩踏み込める方法がある。 ■日英で学ぶという新しいスタイル 例えば、システム開発について日英両方で発信しているYouTubeを使う方法だ。 同じ内容を、日本語と英語で比較する。 それだけで理解が一気に深まる。 字幕を付けることもできる。 だが、あえて付けない方がいい。 耳と文脈で理解する力が鍛えられるからだ...

見えない爆弾を抱えた開発現場——構成管理という“迷宮”の正体

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