Digital Heroes: Guide to IT World

うわっ、完成を見届けない仕事に意味なんてあるのか！？——そんな疑問が、社会人7年目の終わりに頭をよぎった。 走り続けた7年間の現場 社会人7年目も終わりを迎えようとしていた私は、これまでいくつものプロジェクトに関わってきた。大規模案件もあれば、小規模なものもある。所属しているのはアプリケーション開発部隊。各前線のSEが持ち帰ってくる案件のうち、大規模なシステム開発が必要な場合に投入される舞台だ。 仕事は山ほどあるが、主役は限られる SEが持ってくる仕事は多い。パソコンの置き換え、ネットワーク工事。しかし、その中でも最もインパクトが大きいのはシステム開発プロジェクトだ。かかる金額は桁違い。だからこそ人も集まり、そして去っていく。私もそのうちの1人だった。 「最後まで関わる」とは何か？ 当然、最後まで関われたプロジェクトもあれば、途中で離れたものもある。ではここでいう「最後」とは何か？運用まで含めて見届けることなのか。それとも本番ローンチまでか。アプリケーション開発部隊の役割は明確だ。基本は本番ローンチまで。ハイパーケアまでは関わるが、その先の運用には踏み込まない。 200人プロジェクトでも同じ現実 ある200人規模のプロジェクトで、私は構成管理担当として多くの仕組みを整備した。システムテストからテスト環境への移行はやりきった。そして、その仕組みを本番にも適用する段階まで持っていった。 しかし——そのタイミングで次のプロジェクトの話が来た。 選択の分岐点 このプロジェクトの最後まで見届けるか。それとも新しい挑戦に踏み出すか。断ることもできた。しかし、新しい環境で自分の力を試す機会でもある。 ここで一つの問いが浮かぶ。 「完成を見ない仕事に価値はあるのか？」 私は思う。価値はある。ただし、それは“成果物”ではなく“仕組み”に宿る。誰かが作った仕組みの上に、次の誰かが乗り、本番を迎える。プロジェクトはリレーだ。全員がゴールテープを切る必要はない。 ビジネスとしてのリアル むしろ、すべてを見届けることに固執する方が非効率な場合もある。人材は有限であり、機会は連続する。重要なのは「どこで価値を最大化するか」という視点だ。 選択できる立場にいること自体が、すでに価値だ。ならば、止まる理由はない。 私は次のプロジェクトへ進むことを選んだ。 この...

うわっ、キーボードよりも先に“床”と戦う仕事だったのか!? ■システム構築＝机に座る仕事？ 「システム構築って、パソコンに向かってコードを書く仕事ですよね？」 そんな問いに、私は一瞬、言葉を失う。 確かに、そういう側面もある。 だが、それだけで語るにはあまりにも現場は“泥臭い”。 私はこれまで、いくつものシステムプロジェクトを回してきた。 立場としてはどちらかと言えばマネジメント側。 しかし、プログラムも書いてきた。 サーバも構築した。DBも当然やってきた。 「ネットワークは？」 ——もちろんやっている。 ■まだWi-Fiがなかった時代 今でこそWi-Fiは当たり前だが、10何年前は違った。 開発環境は基本、有線。 青いLANケーブルをHUBに差し込む。 それが“インフラ構築”の基本動作だった。 だが現実は、そんなに綺麗ではない。 青で統一されていればまだ良い方。 黄色、白、どこから来たかわからない古いケーブル。 現場はカオスだった。 ■200人プロジェクトの“現実” 200人規模のプロジェクトになると、話はさらに変わる。 急ごしらえのテーブルを並べる。 当然、ネットワークが追いつかない。 ルーターからHUBをいくつもつなぎ、 そこからさらにLANケーブルを伸ばす。 だが、当然足りなくなる。 ではどうするか？ LANケーブルのソケットを買ってきて、 長いケーブルを切断し、つなぎ直す。 “増やす”のではなく、“作る”。 それが現場だった。 ■昼は会議、夜は職人 昼は会議。 進捗、課題、顧客説明。 完全にマネジメントの顔だ。 だが夜になると違う。 誰もいないオフィスで、 LANケーブルを作り続ける。 ペンチを握り、端子をかしめる。 気づけば、エンジニアというより職人だ。 ■床の下にある“本当のシステム” さらに作業は続く。 LANケーブルは床の上には置かない。 OAフロアを開け、 その下に配線していく。 絨毯を剥がし、床を持ち上げ、 ケーブルを通す。 人がいない時間しかできない。 だから、夜か朝。 急いで配線し、 床を閉じ、絨毯を戻す。 ——あ、ネジ締め忘れた。 次の日、床が“ボコッ”と沈む。 そんなことも日常だった。 ■スーツは泥まみれになる ...

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

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

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

気づけば“主役”が入れ替わっていた――プロジェクトは静かなる陣取り合戦だった！ ― 足りない現場を救い続けた、中国系ベンダーの底力 ― 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 研修講師からプラットフォーム構築へ 私は新人研修をリードした後、全社プラットフォームの構築に従事した。 標準化・共通化を掲げ、現場で再利用できる仕組みを整える仕事だ。やがてそのプラットフォームを各部門へ適用するため、社内コンサルとして現場に入ることになった。 そして最終的には、現地プロジェクトのリードを任される立場に。 理想と現実のギャップを埋める役割だった。 ■ 三つ巴の体制 そのプロジェクトは、日立と2社のベンダーでスタートした。 バッチ系を担うベンダー、Web系を担うベンダー。役割分担は明確。設計も整然としていた。 だが、実際の現場は予算も人数もギリギリ。 ちょっと人が足りない、少し想定外が出る――それだけで遅延の足音が近づく。 構築とテストのフェーズに入り、中国系のベンダーが加わった。 テスト設計は既存2社、テスト作業を中国系チームがサポートする体制だった。 ■ 宙に浮いた“英語Webページ” そんな中、誰にも振られず宙に浮いていたタスクがあった。 英語Webページの構築だ。 国内向け前提で進んでいた設計。 英語化は「あとでやろう」と先送りされ、気づけば誰の責任範囲でもなくなっていた。 そのとき、手を挙げたのが中国系のベンダーだった。 ■ 辞書を引きながら前に進む 彼らは中国人メンバーだけで構成されていた。 リーダーは日本語が完璧。メンバーは日本語を勉強中。それでも動いた。 Google翻訳の精度も今ほど高くない時代。 辞書を調べながら日本語を英語へ変換し、表現を整え、画面体裁まで調整していく。 「できますよ」と静かに言いながら、確実に形にしていく。 めちゃくちゃ助かった。 気が付けば、最初は2人だった体制が6人に増えていた。 ■ プロジェクトは陣取り合戦 プロジェクトは陣取り合戦だ。 こぼれてくるタスクを誰が拾うか。 不足をどう埋めるか。 特に彼らはハングリーだった。 急に人を増やし、柔軟に対応する。価格も抑えめ。スピードもある。 最初は「サポート役」だった。 ...

日立製作所のプロジェクトで知った、日本を支える構造の正体 うわっ、想像していた世界と全然違う！ 研修が終わり、Web研修も終え、いよいよ実際のシステム開発プロジェクトに配属された日のことだ。胸の奥にあったのは、「ついに現場だ」という高揚感だった。     ■ 日本を代表する大企業・日立製作所 日立製作所は、日本を代表する大企業だ。電力、交通、産業、IT——世界中のインフラを静かに、しかし確実に支えている。金融分野でもその存在感は圧倒的で、日本のほぼすべての銀行に日立のシステムが入り込んでいる。特に大きな銀行であれば、どこかの領域で必ず日立に頼っていると言っていい。 ■ たった一つの銀行、その裏側 そんな日立の中で、私は「一つの銀行のシステムを開発するプロジェクト」に入ることになった。巨大企業のプロジェクトだから、日立の社員だけで回しているのだろう。正直、そう思っていた。 だが、現実は違った。 ■ 正式メンバーではなかった私 私は日立製作所の正式なメンバーとしてではなく、日立製作所の子会社である 日立システムズ の先輩の下についた。少し意外だったが、もともと日立システムズにも行こうかと考えていたこともあり、勝手に親近感を覚えた。 ■ 初めて聞いた言葉の数々 プロジェクトが始まって、初めて知る言葉が次々と出てくる。 「元受け」「二次受け」「三次受け」——。 一つのプロジェクトに、数社が関わっているのだ。日立が元受けとして受注し、その下に日立グループ会社、さらにその下に協力会社が連なる。特に日立グループの下請けが多いことに驚かされた。 ■ 日立って、製作所だけじゃない 「日立って、製作所だけじゃないんですね」 思わず口に出た。グループ会社全体を入れたら、一体何人になるのだろう。一つのプロジェクトを、自分たちの“グループ”だけで回せてしまう。その層の厚さに、ただただ圧倒された。 ■ これが世界を支える大企業 多重構造は、非効率に見えるかもしれない。だが、この分厚い層こそが、止まってはいけない銀行システムを守り、世界のインフラを支えている。巨大企業とは、規模だけでなく「構造そのもの」が強さなのだと知った瞬間だった。 私は、この分厚い層の一番下にいたかもしれない。 でも、その全体を知れたことは、何よりの財...

パソコンから声が聞こえるんだってさ！ そんな話を聞いたのは、配属されたての新人研修中のことだった。正直「何を言ってるんだ」と思った。でも、その彼女は本当にすごかった。プログラム、開発、テスト…何をやらせても一番。僕も負けていないと思っていたけど、彼女の前では素直に白旗を上げた。 理系の大学に、女性はなぜ少ない？ 僕は理系の大学出身だ。クラスは19人、そのうち女性は2人。割合にすると10％ちょっと。講義の内容に男女の違いは全くなかったし、体力を使うわけでもない。それなのに、なぜ女性は少ないのか？当時からずっと不思議だった。 大学では、レポートや研究に追われる日々。でも、性別で差が出る場面なんて一つもなかった。いや、むしろ几帳面で粘り強い女性の方が、プログラミングや実験に向いているんじゃないか？そんな印象すら持っていた。 システムの現場も、やっぱり少数派？ 新卒で入社した日立製作所。配属先の新人同期を見渡すと、女性の比率は約3割。つまり、大学時代よりは少し増えたけど、やっぱり少ない。 でも驚いたのはその後。新人研修でプログラムの課題があったんだけど、一番コードが美しく、動作も完璧だったのは、あの“パソコンから声が聞こえる”彼女だった。彼女は冗談交じりに「コードが話しかけてくるの」と言う。僕にはそんなスキルはなかった。自分でも手応えを感じていたけど、彼女の才能には完全に脱帽だった。 活躍できるのは「わかる人」「できる人」 それから10年以上、数えきれないほどのプロジェクトに参加してきた。業種も内容もバラバラ。でも、一つだけ共通して言えることがある。 「できる人が活躍する」それだけの世界だということ。 もちろん、女性の上司や先輩もたくさんいたし、産休や育休で一時的に離れる人もいた。でも、システムの世界は基本的にプロジェクト単位でチームが組まれ、数か月〜数年でメンバーが入れ替わる。だから「来月から来ません」と言われても、「了解、じゃあ引継ぎどうしようか？」と淡々と進めるだけ。性別や背景にこだわっている暇はない。 ダイバーシティって何だったっけ？ 最近では「ダイバーシティ」「インクルージョン」という言葉をよく耳にする。でも、僕が働いてきたシステムの現場は、言葉として意識しなくても、自然と多様性が存在していた。 性別、年齢、国籍、学歴――本当に...