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

投稿

ラベル(開発現場)が付いた投稿を表示しています

ブログを翻訳

サーバは机じゃない——“お茶事件”が暴いた開発現場の静かな崩壊

うわっ…サーバの上に湯気立つお茶が置かれている現場に、思考がフリーズした! ■社会人6年目、現場のリアル 社会人6年目、私はある開発プロジェクトにアサインされた。そこは、足の踏み場もないほどごちゃごちゃした開発ルームだった。1人あたりのスペースはわずか80cm。隣のキーボードの音が、そのまま自分の思考に割り込んでくる距離感だ。 ■消えていく会議室 本来議論のためにある会議室は、2つがテストルームに転用されていた。残るはたった1つ。結果、打ち合わせは空きスペースか、立ち話。意思決定の質は、確実に下がっていく。 ■食事すらままならない 食べる場所もない。気づけば、ラックマウントサーバが“机代わり”になっていた。熱を持つ機器の上に弁当。これは冗談ではなく、現実だ。しかも結構危険だ。 ■夜は長く、そして遅い 夜はみんな遅い。私のプロジェクトも例外ではない。他の同期からも同じような話を聞く。「どこも似たようなものだよ」と。つまり、これは個別最適ではなく、業界構造の問題だ。 ■衝撃の“お茶事件” そんな中、同期から衝撃的なニュースが入った。 「サーバにお茶こぼしたらしい」 笑えなかった。 きっと同じような環境だったのだろう。 むき出しのサーバ、置き場のない書類、狭すぎる机。 その中で、ほんの一瞬のミス。 ■紙一重のリスク 正直、こちらも紙一重だった。 すぐに「サーバの上に物を置かないように」と通知を出した。 しかし、置く場所がない。 だから机の上にサーバがあり、その上に書類が重なる。 そして、その上に…… ■改善できない構造 問題は分かっている。 でも、すぐには変えられない。 予算、スペース、納期、すべてが制約だ。 だから現場は“危険を内包したまま最適化”されていく。 ■これがシステム業界の現実 同情しかない。 うなづくしかない。 同じ構造の中に、自分もいるからだ。 この話は極端に聞こえるかもしれない。 だが、似たような環境は確実に存在する。 そして、その上に我々は“高品質なシステム”を求められている。 ■ビジネスとしての問い これは単なる美談でも、笑い話でもない。 「この環境で、本当に持続可能な価値提供ができるのか?」 CXOが向き合うべき問いはここにある。 DXとはツール導入ではない。 現場の“物...

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

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

終わった翌日がこんなに晴れるなんて――本番明けに知った「仕事のご褒美」

初めてのシステムローンチが教えてくれた、続けた人だけが見える景色 うわっ、世界が一段明るくなった!? 本番が明けた日の朝、カーテンを開けた瞬間、そんな錯覚を覚えました。 前日の張りつめた空気が嘘のように、空は晴れていて、気持ちも驚くほど軽かったのです。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       ■ 初めて体験した「本番へのシステムローンチ」 社会人1年目。 私は初めて「本番へのシステムローンチ」というものを体験しました。 開発、テスト、修正、確認。その繰り返しの先にある“本番”。 言葉では知っていても、実際に立ち会うまで、その重みは分かっていませんでした。 今振り返ると、本番稼働の瞬間に立ち会えたこと自体が、実はとても幸運だったのだと思います。 ■ ローンチに辿り着けない人もいるという現実 同期の中には、途中で別の業務に移った人もいました。 エンジニアの方々の中にも、このローンチの日を迎えることなく、現場を離れた人がいます。 少し考えれば、それは特別なことではありません。 システム開発には、本当に多くの人が関わります。 部品を作る人、機能を実装する人、設計だけを担当する人、提案だけで終わる人、ドキュメント作成で役割を終える人。 途中で抜けていく人が多いのも、ある意味「普通」なのです。 ■ それでも「最後までいた」から見えたもの そんな中で、ローンチの日まで現場にいて、 市場に“自分が関わったシステムが出ていく”感覚に出会えたこと。 これは、間違いなく自分の財産になりました。 ローンチ当日は、正直、色々ありました。 トラブルもあり、想定外もあり、気持ちはかなり沈みました。 「本当に大丈夫なのか」と、不安が頭から離れなかったのを覚えています。 ■ そして次の日、世界はちゃんと続いていた でも、次の日は晴れていました。 不思議なくらい、僕の気持ちも晴れていました。 次の仕事は、まだ言われていません。 しばらくは、このシステムのメンテナンスを続けていくことになります。 派手ではないけれど、確実に「続きの仕事」です。 そして私は思いました。 また次に向かって、歩み出せる、と。 ■ 本番を越えた人だけが持てる感覚 最後までやり切ったからこそ得られる感覚が...

ここで本番!?――静かな現場に鳴ったカウントダウン

  一人残ったプロジェクトで学んだ、「最後に立つ」という仕事 うわっ、いよいよ来た!? それは、まだ寒さが残る2月のことだった。 「いよいよ本番を迎える」――言葉にすれば簡単だが、その裏側には静かで濃密な時間が流れていた。     ■ 気づけば、自分だけが残っていた 同期は全員、次のプロジェクトへ移っていった。 にぎやかだった現場は少しずつ静かになり、私はこのプロジェクトに残ることになった。 不安がなかったと言えば嘘になる。でも、ここで踏ん張るしかない、そう腹をくくった。 ■ カバーする日々が、力になる 先輩と二人で、同期が残していったプログラムをカバーしながら、追加テストを進める。 合間には、溜まっていたE-learningを消化し、たまに来るお客様からの確認や指摘にも対応する。 メインの機能はできている。残るは微修正――そんなフェーズだった。 ■ 「ちょっとした指摘」のはずが… そんな時、飛んできた大きな指摘。 「画面の見た目を少し変えてほしい」 一見、軽そうに聞こえるその要望は、実はサーバ設定を変更しなければ対応できない内容だった。 ユーザーが見ているポイントと、システム側で手を入れるポイントは、必ずしも一致しない。 「いや……これは……」 先輩と顔を見合わせ、どう解決するかを話し合う。 ■ 折衷案を探し、問題と向き合う 理想を追えば工数が増える。 現実を取れば満足度が下がる。 その間で折衷案を考え、しっかり問題と向き合う。 バグ対応とは、こうした時間の積み重ねなのだと、身をもって知った。 ■ 同期のコードが教えてくれたこと 同期が残していったプログラムにも手を入れる。 ――さすがだ。バグが少ない。 コードがきれいで、意図が読みやすい。 画面越しに、同期の仕事ぶりを感じながら、少しずつ対応を進めていった。 ■ 迫る本番、かけられた一言 気づけば、「いよいよ本番」が目前に迫っていた。 そんなある日、先輩から声がかかる。 「本番の日、一緒に立ち会う?」 返事はもちろん、YESだ。 ■ さ、いよいよ本番だ 派手な達成感はないかもしれない。 でも、最後まで残り、問題と向き合い、責任を持って立ち会う。 その経験は、確実に自分の背中を押してくれる。 私な...

えっ、そこ!?――プロジェクトは「お昼」で回っている

PMの視野が広がる、たった1時間の使い方 うわっ、今日のお昼どうする!?――そんな何気ない一言が、実はプロジェクトの流れを左右しているとしたら。 空いた時間でお小遣いを貯めよう!「アイリサーチ」       ■ 開発プロジェクトと「お昼ごはん」の意外な関係 開発プロジェクトで、結構重要なのが「お昼ごはん」だ。 スケジュールにもWBSにも書かれないけれど、確実に存在する意思決定の場。それがお昼だ。 日立のオフィスで仕事をしていた頃は、恵まれていた。食堂があり、自然と人が集まる。席に座れば、雑談が始まり、ちょっとした相談が生まれる。公式ミーティングよりも早く、空気が伝わる場所だった。 ■ 会議室プロジェクトのリアル 一方で、開発プロジェクトルームという名のホテルの会議室、あるいは貸しオフィスでのプロジェクト。 こうなると事情は変わる。お昼は近所に食べに出るしかない。 ここで重要になるのが、「誰と行くか」だ。 ■ 誰と食べるかで、見える世界が変わる 最初は同期と行っていた。 気楽で安心。でも話題は似通う。 途中から先輩と行くようになった。 経験談や過去の失敗、公式資料には載らない話が聞ける。 たまに、違うチームの人とも行った。 これが、驚くほど視野を広げてくれた。 違うチームの人と話すと、「あ、そんな前提で動いてたのか」「そこ、そう見えてたんだ」という発見がある。プロジェクト全体が立体的に見えてくる瞬間だ。 ■ 結局、仕事の話になる。でもそれがいい なるべく違う話をしようと思う。 天気、週末、ニュース。 でも、結局仕事の話っぽくなる。 それでいい。 夜の飲み会だとか、「軽く飲みに行きますか?」は、正直ハードルが高い。プライベートもあるし、体力的にも厳しい。 その点、お昼はいい。 時間が決まっている。 難しい話でも、「じゃあ午後は戻らないと」で切れる。 だからこそ、話しやすい。 ■ PMにとって、お昼は「使命」 プロジェクトマネジメントをしていくのであれば、プロジェクトのメンバーと話さないといけない。 進捗だけでなく、温度感、違和感、小さな不満。 そんな使命感が、PMにはある。 お昼休みは、単なる休憩ではない。 コミュニケーションの時間だ。 ■ PMって、見る範囲多く...