Digital Heroes: Guide to IT World

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

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

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

うわっ、終わったはずの戦場に、また呼び戻されるなんて ■支援のはずが、踏み込めない違和感 あのプロジェクトは、支援として入った現場だった。同期が苦しんでいる。だから助けたい——そう思って動いていた。 だが現実は違った。手を出そうとすると、どこかで止まる。 「そこは依頼範囲外です」 「契約上、難しいですね」 まるで見えない壁があるようだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■組織をまたぐと“お金”が発生する構造 大企業では、組織間の支援にも明確なルールがある。 プロジェクトに必要な人員を計画し、その分の人件費を依頼元に請求する。 依頼元が顧客から収益を得ていれば、そこから支払われる。 もし得られていなければ、戦略案件として赤字覚悟で進める。 つまり、支援ですら“コスト”として管理される。 これは冷たい仕組みに見えるかもしれない。 だが、いくつかの企業を見てきた今なら言える。 この仕組みは、むしろ健全だった。 ■支援の終わりは、突然に ある日、判断が下った。 「依頼元からの予算が尽きた。撤退する」 あっけなかった。 我々の部隊は、そのプロジェクトから外れることになった。 残るのは、元の部署。 それが、本来の姿だった。 彼らは、自分たちでできると信じて仕事を取り、プロジェクトを立ち上げた。 しかし回らなかった。 だから、我々が支援に入った。 だが、お金がなければ、支援は続けられない。 ■残された責任 その後どうするか。 リスケするのか、顧客と再交渉するのか。 それは、依頼した部署の責任になる。 企業として一枚岩ではないのか？ そう感じる瞬間もあった。 正直に言えば、もっとできたと思っている。 あのとき、もう一歩踏み込めていたら——。 だが、上の判断は明確だった。 そして、次の指示が来た。 ■次のプロジェクトは、同じ場所だった 次の案件。 それは、日本の証券業界のど真ん中にある会社の基幹システム。 そして、その開発拠点は—— 前のプロジェクトで、必死に戦っていた場所だった。 また、同じ場所。 だが、役割は違う。 状況も違う。 あのときの悔しさが、胸に残っている。 ■ビジネスにおける“支援”の本質 この経験から見えたことがあ...

うわっ、プロジェクトってこんなに人がいるのか！ 若い頃、大規模システムプロジェクトの会議室に入った瞬間、そう思ったのを覚えています。 私はこれまでIT屋として、多くのシステム構築プロジェクトに関わってきました。 日本だけではありません。インド、中国、ポーランド。いまやITプロジェクトは完全にグローバルに広がっています。 大きなシステムになればなるほど、プロジェクトは巨大になります。 そしてその構造は、実はとても複雑な「多段の社会構造」になっています。     プロジェクトの裏側にある「多段構造」 システム開発の世界では、よくこんな言葉を聞きます。 「システムはシステムのプロが作る」 これは半分正解で、半分間違いです。 確かに設計やアーキテクチャは専門家が担います。 しかし、大きなシステム、大きなプロジェクトになればなるほど、最後は人海戦術になります。 テスト作業、データ確認、操作確認。 パソコンが触れればできる仕事は数多く存在します。 日本語ができなくても、パソコンは触れる。 言われた通りにテストはできる。 こうして世界中から人が集まり、プロジェクトはどんどん拡大していきます。 知識労働ではなく「人数ビジネス」 しかし、この構造にはもう一つの側面があります。 プロジェクトは、元請けから順番に費用が抜かれていきます。 そして末端のエンジニアに届く頃には、かなり安価なコストになっています。 つまり、評価されているのは知識ではなく「人数」です。 人を集めれば売上になる。 だから価格競争が起きる。 そして、縄張り争いが始まります。 プロジェクトの現場で起きること 当初考えていない作業が出てくると、 「それはうちの責任ではない」 簡単な作業が出てくると、 「それはうちがやる」 責任は押し付け合い、 作業は取り合いになる。 管理者たちは、その中で自分の領域を広げるために、 コミュニケーション、調整、そして飲み会に奔走します。 こうしてプロジェクトは進むのですが、 その裏では多くの人が疲弊しています。 鬱になる人もいる。 プロジェクトは遅延する。 そして最後には、責任の追及が始まる。 残念ながら、この構図は世界中であまり変わりません。 PMBOKでも解決できないこと もちろん...

うわっ、また夜中のローンチか！ 昔のプロジェクトルームでは、そんな声が当たり前のように聞こえていた。 私の経験上、 システムのローンチは夜に行われることが多い 。 それも、かなりの確率で。 なぜか。 理由はとてもシンプルだ。 次の日から使えるようにするため だ。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       夜にローンチする理由 システムの変更は、できれば「区切りの良いタイミング」で行いたい。 たとえば、 ・夜中に切り替え ・翌日から新システム ・もしくは土日作業 ・月曜から新システム この形は、説明がとても楽だ。 「 月曜日からシステムが変わります 」 これだけで済む。 ユーザーにとっても分かりやすいし、 管理側も整理しやすい。 プロジェクトというのは、 技術よりも説明の方が難しいことが多い。 だからこそ、 区切りの良いローンチ が選ばれる。 金融システムはさらに特殊 特に顕著なのが 金融系システム だ。 金融の世界では、 平日の昼間はお金が動いている。 つまり、 平日昼間にシステムを止めるわけにはいかない。 その結果どうなるか。 作業は土日になる。 これが長年の常識だった。 さらに大きな変更になると、 GW（ゴールデンウィーク）作業 も珍しくない。 「GW中に変更作業を行い、 GW明けから新しいシステムになります」 金融プロジェクトでは、 この言葉を何度聞いたか分からない。 システム屋のGWは存在しない 私の若い頃、 システム屋にとってGWは特別な意味を持っていた。 休みではない。 むしろ 最大の作業タイミング だった。 システムローンチが控えている年は、 GWなんて存在しない。 プロジェクトルームに泊まり込み、 深夜の切り替えに備える。 そして夜中。 コマンドが打たれる。 ログが流れる。 沈黙。 「……よし、上がった」 その瞬間の空気は、 今でも忘れられない。 私は長い間、 システム屋ってそういうものだ と思っていた。 しかし時代は変わり始めた 最近、この常識は少しずつ変わってきている。 理由はいくつかある。 まず、 土日に人を集めるのが難しい。 働き方が変わったからだ。 さらに...

古びたプロジェクトルームにあった“最強の道具” うわっ、こんな部屋で巨大プロジェクトが回っているのか――そう思った瞬間があった。 当時、私は金融系のプロジェクトでお客様のシステムを支えていた。 場所は、新しいわけでも古いわけでもない、どこにでもあるオフィスビル。そのワンフロアを丸ごとプロジェクトルームとして借りていた。 実はこのフロア、長年にわたって日立のプロジェクトが使ってきた場所だった。 いわば、歴代プロジェクトの“戦場”のような空間だ。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       昭和の匂いが残るプロジェクトルーム 部屋に入ると、ふわっとタバコの匂いがする。 おそらく、昔はここで多くのエンジニアが夜通し働いていたのだろう。 机を見ると、片足が折れているものもある。 隣の机に寄りかかることで、なんとかバランスを保っている。 床を見ると、何度も開け閉めされた跡があり、ネットワークの配線が飛び出している。 インフラ工事を何度も繰り返した証拠だ。 そんな古びたプロジェクトルームの中に、いくつものチームがいた。 フロアの中で「場所」で分かれている。 あのチームは開発。 あの場所はテスト。 あちらはインフラ。 まるで昔ながらのプロジェクトの縮図のような空間だった。 プロジェクトに本当に必要なもの もちろん、プロジェクトには必要なものがたくさんある。 パソコン。 机。 会議室。 そして、飲み会。 どれも大事だ。 しかし、私が「一番重要だ」と感じていたものがある。 それが ホワイトボード だ。 ホワイトボードは万能ツール ホワイトボードは不思議な道具だ。 課題管理のツールになる。 図を書けばプレゼン資料になる。 みんなで囲めばアイデア会議の場になる。 パワーポイントのように完成された資料ではない。 その代わり、圧倒的に“活動的”だ。 人が立ち、書き、消し、議論する。 ホワイトボードの前では、プロジェクトが動き出す。 プロジェクトを回す人の習慣 私はプロジェクト管理を担当するようになってから、 暇があるとホワイトボードを掃除していた。 もちろん、オフィスの掃除も大切だ。 机の整理も大切だ。 でも、なぜか私はホワイトボードだけは必ず綺麗にしていた。 ...

社員3名。でも物語は無限大 うわっ、たった3人のはずなのに、どうしてこんなに賑やかなんだ！ このプロジェクトは社員3名で走っている。資料上は小規模、予算も大きくない。だが、実際に現場に立つと違う。関わる人は想像以上に多い。応援に入る人、横から助言する人、ただその場にいるだけで空気を変える人。プロジェクトとは「人数」ではなく、「関わる人の多様さ」でできているのだ。     50代リーダーの背中が示すもの 中心にいるのは、50代でプロジェクトをリードしている人。派手さはない。だが、迷いがない。若手の意見を聞き、必要な場面では決断を下す。その姿は、長年の経験に裏打ちされた静かな強さだ。プロジェクトがぶれないのは、彼が“軸”を握っているからだ。 働き方は十人十色 定時になると颯爽と帰る人がいる。一方で、なかなか帰らず、最後まで残る人もいる。声が大きく、会議の空気を一瞬で支配する人。お昼は必ず机で寝ると決めている人。ずっと席にいるけれど、正直、成果がどこにあるのか分からない人もいる。 新幹線通勤で遠くからやってくる人もいれば、職場の近くに住み、誰よりも早く来ている人もいる。距離も、リズムも、価値観も違う。それでも同じゴールを目指している。 “ほとけ”という存在 一番上の人は、なぜか「ほとけ」と呼ばれている。いっつもニコニコしている。怒らない。焦らない。だが、何をしているのかは少し不明だ。それでも、彼がそこにいるだけで場の緊張が解ける。まさにプロジェクトのキャラクターマスコット的存在。見えない安心感が、チームを支えている。 人がいるから、前に進む プロジェクトは、完璧な人材で構成されているわけではない。むしろ、ばらばらだ。だが、その違いこそが推進力になる。声が大きい人が勢いをつくり、静かな人が土台を固め、リーダーが方向を示す。 いろんな人に支えられて、プロジェクトは今日も動いている。成果は個人のものではなく、関わる全員のものだ。 だからこそ思う。 この多様さを力に変えられるのは、私たち自身だ。 私ならできる！明日から踏み出す

― 技術進化の裏側で、静かにプロジェクトを支える存在 ― うわっ、最新バージョンのJavaより、この人の一言のほうが現場を動かしている!? システム開発の現場で、結構不思議だったことがある。 作っているのはJavaによるWeb中心の開発。Javaは結構新しい技術だし、最近もバージョンアップしたばかりだ。その変更点を十分理解し、オブジェクト指向も踏まえて設計しなければならない。正直、追いかけるだけでも大変だ。 だから私は思った。 経験があるとはいえ、50代の人って、これどうやってついて行っているの？     ■ 若手が強い領域、ベテランが強い領域 確かに、金融の仕組みは若い人には分からないことが多い。しかし、Javaの最新仕様は若手のほうが詳しいこともある。では、50代の課長は何をしているのか。Javaのプログラム設計そのものをゴリゴリ書いているわけではない。 彼らの役割は別にあった。 ■ 業務を構造に落とす力 金融システムの仕組みを理解し、それをシステム構造に落としていく。業務フローを整理し、要件を明確化し、詳細設計や画面設計をレビューする。 最新のプログラムが分からなくても、十分どころかリードできる。 なぜか。 業務を知っていることの重み。 そして、開発プロジェクトそのものを知っている強み。 ■ プロジェクトを動かすのは“経験値” 開発計画を立てる。 テスト計画を策定する。 テスト内容をレビューする。 人員計画を考え、各メンバーを教育し、作業計画を整理する。 やることは山ほどある。それを計画し、一つ一つ積み上げていく。 経験があるエンジニアだからこそ、全体を俯瞰し、優先順位をつけられる。 私たち一次受けの立場から見ても安心してお願いできる存在。 まさにベンダーの重鎮だ。 ■ 「新しい技術を知っている」だけでは足りない 新しいプログラムを知っているから何？ そんな言葉が背中からにじみ出ているようだった。 技術は進化する。しかし、業務理解、構造化力、計画力、人を束ねる力は一朝一夕では身につかない。彼らがいないと、開発は回らない。 とっても頼りになる存在だ。 技術を追い続ける若手と、構造を支えるベテラン。その両輪があってこそ、プロジェクトは前に進む。 年齢は壁ではない。 役割が進化し...

見えない土台が、すべてを決めていた うわっ……鼻を突くたばこの匂いと、重たい空気！ 2010年が近づいていたある頃、私は東京の主要駅近くにある、とある開発現場へ向かっていた。交通の便は悪くない。むしろ、有名な“満員電車路線”の駅だ。ぎゅうぎゅうの電車に揺られて辿り着いた先は、日本の金融の大元を司る会社のシステム開発ルームだった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ミスが許されない、極限のシステム そのシステムは、長年にわたり** 日立 **が受けてきたもの。 ミスるわけにはいかない。 もし一つでも誤れば、影響は金融業界全体に及ぶ。 下手をすれば、翌日の新聞に載る。 そんな、緊張感の塊のようなシステムだった。 舞台は“理想”から程遠い場所 だが、その重要システムが作られていた場所は、驚くほど古かった。 開発ルームの一角は薄暗く、たばこの匂いがぷーんと漂う。 絨毯は年季が入り、色もくすんでいる。 正直、モチベーションが上がる環境ではない。 それでも仕事は始まる。 絨毯をめくり、さらにその下のOAフロアを持ち上げ、ネットワーク配線に手を入れる。 机は片足が折れ、隣の机にもたれかからせて、なんとか形を保っているものもあった。 社員3人、あとはベンダーという現実 話を聞くと、常駐している社員はわずか3人ほど。 あとは複数社のベンダーさんたちだ。 社員の役割は、開発方針を語ることよりも、 「環境を整える」「サーバを配置する」「パソコンを用意する」こと。 驚いたのは、パソコンが割り当てられていない開発者がいたことだ。 光の入らない部屋に人が密集し、最低限の設備を奪い合うような状態。 それでも、日本の基盤を支えるシステムは、確かにここで作られていた。 環境整備も、立派なプロジェクト この現場で痛感した。 環境整備は“前段”ではない。 それ自体が、成功を左右する プロジェクトそのもの だということを。 どれほど優秀な設計書があっても、 どれほど優れたエンジニアがいても、 環境が整っていなければ、成果は最大化しない。 見えないところを整える人がいるからこそ、 表に出るシステムは、静かに、確実に動き続ける。 私ならできる！明日から踏み出す

プロジェクトの“間”をつなぐ人、それが社内コンサルタント うわっ!? 会社の中だけで、こんなに世界が違うのか！ 入社してしばらく経った頃、私は強烈な違和感と同時に、妙なワクワクを覚えていました。舞台は、巨大企業である 日立 。想像以上に広く、想像以上に多様なプロジェクトが、同時多発的に社内で動いていたのです。     ■ 巨大企業の中は、小さな会社の集合体 日立の中では、実に多くのプロジェクトが走っていました。 サーバ構築プロジェクト、プラットフォーム構築プロジェクト、お客様のシステム構築プロジェクト、既製品の販売プロジェクト——。それぞれが独立しているようで、実は密接につながっています。 ■ “多段サポート”という見えない構造 社内では、多段でお客様をサポートする構造がありました。 お客様のシステム構築プロジェクトを、プラットフォーム構築プロジェクトが支える。 そのプラットフォーム構築プロジェクトを、さらにサーバ構築プロジェクトが支える。 私は、その中でプラットフォーム構築プロジェクトの末端を担っていました。 ■ 採用の瞬間、立場が変わる ある日、そのプラットフォームが実際にお客様のプロジェクトで採用されました。 「使うことになったから、誰かサポートに行かなければいけない」 当然の流れです。プラットフォームは、何の説明もなく簡単に使えるものではありません。使い方を教え、支え、プロジェクト間をつなぐ人が必要でした。 ■ 社内コンサルタントという役割 こうして私は、“社内コンサルタント”的な立場でプロジェクトを支援することになります。 実は、私のプラットフォームプロジェクトからも、すでに何人かがお客様プロジェクトへ出ていました。そして次は、自分の番。 お客様に近い場所で、システム開発に関わる。 「もっとお客様の気持ちを知りたい」 そう思っていた私は、少し背筋を伸ばしながら、新しい環境へ足を踏み出しました。 ■ 新しい現場、新しい緊張 環境が変われば、見える景色も変わります。 ちょっと気が引き締まる感覚。 それでも、不思議と前向きでした。 また新しい環境でのシステム開発が始まる——その期待が、私を動かしていたのです。 私ならできる！明日から踏み出す

ローンチ後3日間と、3カ月間が教えてくれた「本当の区切り」 うわっ、次のプロジェクト!? 本番リリースが終わった直後、ふと頭をよぎったのは安堵ではなく、次の予定でした。システムは無事に立ち上がった。でも、エンジニアにとって本番は「終わり」ではありません。そこから始まるのが、Hyper Careと呼ばれる期間です。     本番直後の3日間――24時間、気が抜けない時間 私の経験上、ローンチ直後はまず3日間のホットスタンバイ。 基本は24時間、いつでも連絡がつく状態を保ちます。 稼働時間帯にもよりますが、夜間に動くバッチシステム、データ転送処理などがあると、夜も気は休まりません。 「何も起きないこと」を祈りながら、何かが起きた瞬間に即座に動ける体制を取る。それがこの3日間です。 もちろん、1日目はだいたい何かしらあります。 ログの想定外、運用手順の勘違い、小さなデータ不整合。 でも2日目、3日目になると、システムの“癖”が見えてくる。 「ああ、これは大丈夫だな」という感覚が、少しずつ戻ってきます。 4日目から始まるHyper Care――静かな戦い 問題なく3日が過ぎると、24時間のホットスタンバイは徐々に解除され、4日目あたりから本格的なHyper Careに移行します。 Hyper Careは運用メンバーだけでなく、開発プロジェクトのメンバーも残り、一定期間サポートを続けるフェーズです。 ここでは、致命的な問題が次々に起きるわけではありません。 代わりに見つかるのは、「小さいけれど無視できない不具合」。 「この問題は3日で直そう」「これは1週間かかるな」と、優先度を付けながら対応していきます。 修正版はまとめて本番へ。1週間後のリリースまでに、できる修正をすべて入れる。そのサイクルを、淡々と繰り返します。 人は少しずつ抜けていく 時間が経つにつれ、Hyper Careに残る開発メンバーは減っていきます。 次の案件、次の役割、それぞれが次の現場へ向かっていく。 私の最初のプロジェクトでは、Hyper Careにいたのは1カ月間でした。 立ち続けた本番リリースから、ちょうど1カ月。 ようやく「終わった」と実感できた頃、言われた一言。 「じゃあ、次のプロジェクト。」 唯一、思っていたこと そのとき...