Digital Heroes: Guide to IT World

「すみません。これ、いつ直りますか？」 その質問を受けるたびに、私は答えに困っていました。 なぜなら、私自身も分からなかったからです。 開発会社に聞いても、 「確認します」 「担当に確認中です」 「もう少しお時間ください」 そんな回答ばかり。 でも、社内からは毎日のように聞かれます。 「進んでますか？」 「いつリリースできますか？」 「この問題、まだ直らないんですか？」 私はDX担当者。 プロジェクトの責任者です。 でも、自分でプログラムを書いて直すことはできない。 だから、開発会社に頼るしかありません。 そして、その開発会社が動いてくれない。 これが、私が外注開発で経験した、かなり苦しい時期でした。 ▼開発会社選びに悩んでいる方はこちら   最初は、こんなことになるとは思っていなかった もちろん、最初から怪しい会社を選んだつもりはありません。 提案書はきれいでした。 営業担当者も優秀でした。 「この領域は経験があります」 「お客様の要望に柔軟に対応できます」 「経験豊富なエンジニアをアサインします」 こちらも安心します。 「これなら大丈夫だろう」 そう思って契約する。 ところが、プロジェクトが始まってみると、少しずつ違和感が出てきました。 「それ、営業から聞いてません」 最初に出てきたのが、これでした。 こちらが契約前の打ち合わせで話した内容について確認すると、 「その件は聞いていません」 と言われる。 「いや、営業の方と話しているんですが……」 「営業と現場で認識が違うかもしれません」 ……。 この瞬間、本当に嫌な予感がします。 その後、 「それは追加開発です」 「そこまでの対応は含まれていません」 「仕様変更になります」 という話が増えていきました。 契約前には、 「できます」 と言っていたことが、 契約後には、 「条件によります」 に変わっていく。 そして最終的には、 「それは難しいです」 になる。 この変化を何度経験したか分かりません。 そして、問題が起きる システム開発で一番怖いのは、問題が起きることではありません。 問題が起きたときに、 誰も責任を持って前に進めてくれないこと です。 ある時、システムで問題が発生しました。 当然、私は開発会社に連絡します。 「原因を調べてください」 「いつまでに対応できますか？」 すると、 「まず調査します」 ...

ロンドンから届いた“完成品”を前に、初めて見えたプロジェクトの景色 「えっ、こんなに静かでいいの!?」 システム開発プロジェクトの真っ只中にいるはずなのに、目の前には意外なほど静かな現場が広がっていた。 これまで私は、どちらかというと「システムを作る側」のプロジェクトを数多く経験してきた。 要件を整理し、設計し、開発し、テストする。 プロジェクトのピークになれば、開発者が100人を超えることもある。問い合わせが飛び交い、課題が積み上がり、会議が増え、資料が増え、気がつけば机の上までカオスになる。 「システムを作っているのか、机を整理しているのか分からない」 そんな状態で一日が終わることも、珍しくなかった。 ところが今回、ロンドンから導入するシステムプロジェクトでは、その景色がまったく違った。 開発しないプロジェクトに入ってみる 今回のシステムは、すでにロンドン側で開発が進められ、完成したものを日本側へ導入していく。 つまり、私は開発そのものの中にはいない。 これは、私にとって意外と大きな経験だった。 プロジェクトのピークに入っても、人が爆発的に増えるわけではない。 みんな淡々と、自分の担当するテストや準備を進めている。 ロンドンから、開発を終えたシステムが少しずつ届く。 そして、日本側の周辺システムも少しずつ出来上がっていく。 単体テストは終わっている。 システムテストも終わっている。 そして今、最後の大きな山である「システム統合テスト」に、みんなで取り掛かろうとしている。 そこで、ふと思った。 「そうか。システムプロジェクトって、開発が終わってからも、こんなに長いんだ。」 完成したはずなのに、動かない 実際、開発が終わったシステムをテストしてみると、いろいろなことが起こる。 想定した通りに動かない。 データがうまく連携されない。 画面の表示がおかしい。 別のシステムとつなぐと、思わぬ問題が出てくる。 一つ直すと、別の場所で影響が出る。 だから、開発が終わったからといって、すぐに本番を迎えられるわけではない。 そこから約3カ月、しっかりとテストを行う。 そしてテストが終われば、今度は移行計画。 さらに約3カ月をかけて、何度もシミュレーションやリハーサルを行う。 関係者へのアナウンス。 システム説明。 関係会社との接続テスト。 そして、さまざまな確認を一つずつ積み重ね...

システム屋と業務担当、その境界はどこへ行ったのか 社会人8年目、ロンドンで感じた小さな危機感 うわっ！お客様との会話が、まるでシステム設計レビューになっていた！ 社会人8年目。 もう9年目が見え始めていた頃の話だ。 私はシステム屋として、アプリケーション構築に携わってきた。 お客様の要件を聞き、設計し、開発し、導入する。 システムのプロとしてサービスを提供する立場だった。 そんなある日、日本のお客様がロンドンの企業からパッケージシステムを購入した。 その導入プロジェクトに参加することになり、私はシステム研修のためロンドンへ向かった。 研修期間は2週間。 場所はウォータールー周辺。 ロンドンの金融機関や大手企業が集まるエリアだった。 当時の私は、新しいシステムを学ぶことばかり考えていた。 しかし、本当に学んだのはシステムそのものではなかった。 業界構造の変化だった。 ■ お客様との会話に違和感を覚えた 研修やプロジェクトの打ち合わせが始まった。 私はシステムベンダー側として説明を行う。 アーキテクチャ。 データ構造。 運用設計。 インターフェース。 するとお客様から質問が飛んでくる。 しかも、その質問が妙に鋭い。 「その設計だと将来的な拡張性はどうなりますか？」 「データ移行時の整合性はどう担保しますか？」 「パフォーマンス試験はどの条件を想定していますか？」 あれ？ なんかおかしい。 業務要件の質問ではない。 システム屋がする質問だ。 私は少し戸惑った。 ■ なぜお客様がこんなに詳しいのか しばらくして理由が分かった。 実はお客様側の担当者の多くが元システム屋だったのである。 SIer出身。 開発会社出身。 インフラ出身。 転職して事業会社へ移った人たちだった。 つまり、 業務担当者でありながら、 システムのプロでもあった。 私は衝撃を受けた。 それまで私の中には、 お客様＝業務担当 ベンダー＝システム担当 という構図があった。 しかし現実は違った。 境界線がなくなり始めていたのである。 ■ システム屋の価値はどこにあるのか そこで考え始めた。 私たちシステム屋は何を武器にすれば良いのだろうか。 アプリケーションの専門家として技術を磨くべきか。 しかしサーバ担当もいる。 ネットワーク担当もいる。 データベース担当もいる。 インフラ領域は専門ベンダーが支えている。 で...

 DX担当者として何度も外注に苦しんだ私が、本当に大切だと思うこと うわっ！また今日も“言い訳レビュー会議”か――。 システム開発の責任者をしていた頃、私はある意味で毎日戦っていました。 戦う相手はシステムの不具合ではありません。 開発会社の「言い訳」です。 「この会社なら大丈夫」そう思っていた もちろん、世の中には素晴らしい開発会社もたくさんあります。 しかし、残念ながらそうではない会社に当たってしまうこともあります。 最初は営業担当者の説明に感動しました。 柔軟に対応できます 経験豊富なエンジニアがいます お客様に寄り添います プレゼンも上手い。 資料も立派。 実績も申し分ない。 私は「この会社なら大丈夫だろう」と思っていました。 営業と現場が別の会社だった ところが契約後、実務担当者との打ち合わせが始まると違和感を覚えました。 営業担当者が話していた内容と、現場が理解している内容がまるで違うのです。 「そんな話は聞いていません」 「それは追加費用になります」 「対応は難しいです」 営業担当者と実務担当者の間に大きな乖離がありました。 契約前は何でもできるように見えた会社が、契約後には何もできないように見えてしまう。 これは非常につらい経験でした。 口は上手い。でも動けない さらに困ったのは、説明だけは上手い会社です。 会議では立派なことを言います。 しかし実際に問題が発生すると、 契約上は対象外です 前例がありません 社内ルールでできません という回答ばかり。 こちらは問題解決を求めているのに、返ってくるのはできない理由ばかり。 会議のたびに期待し、会議のたびに落胆する。 そんな状況が続きました。 リーダーは優秀。でもチームがついてこない また別の会社では、リーダーだけが非常に優秀でした。 話をすると安心できます。 理解も早い。 提案も的確です。 ところが実際に手を動かすメンバーへ話が伝わっていない。 同じ説明を何度も繰り返し、 同じ課題が何度も再発する。 気付けば、プロジェクトの大半が情報伝達に費やされていました。 ▼開発会社選びに悩んでいる方はこちら   一番苦しかったのは「手が動かない」こと 会議は開かれる。 議事録も出る。 課題管理表も更新される。 しかし成果物が出てこない。 前に進まない。 検討はする。 相談もする。 説明もする。 ...

システムは完成品ではない。育てるものだ。 Configurationが変えた私のシステム観 うわっ！システムがプログラムを書かずに姿を変え始めた！ ■ システム構築には自信があった システム開発に携わってきて、気が付けばプロジェクトをコントロールする立場になって8年が経っていた。 若い頃はJavaを中心としたシステム開発に関わり、設計から開発、テスト、運用まで一通り経験してきた。 正直に言えば、システム構築にはそこそこ自信がついていた。 要件を聞く。 設計する。 開発する。 テストする。 リリースする。 そんな流れが当たり前だと思っていた。 ところが、その考え方を大きく揺さぶられる経験をした。 海外製パッケージシステムの導入プロジェクトだった。 ■ ロンドンで学んだ新しいシステム思想 お客様のシステムを構築するため、私はロンドンで2週間の研修を受けることになった。 そこで学んだのは単なる製品知識ではない。 システム構造そのものの考え方だった。 当時の私は、「お客様の要件はプログラムで実現するもの」だと思っていた。 もちろん設定は使う。 OSの設定。 サーバ設定。 ログの保存期間。 メモリ割り当て。 ジョブスケジュール。 プログラムを最適に動かし、運用しやすくするためのConfigurationである。 つまり、Configurationはシステムを支える裏方だった。 ■ Configurationの役割がまったく違った しかし、そのパッケージは違った。 驚くほど多くのConfigurationが存在していたのである。 しかも目的が違う。 システムを動かすためではない。 顧客ごとにシステムを変えるために存在していた。 承認フロー。 画面項目。 入力ルール。 通知条件。 業務プロセス。 顧客ごとの個別要件をConfigurationで吸収していた。 最初は驚いた。 「こんなことまで設定でできるのか？」 「これ、本当にプログラムを書かなくていいのか？」 研修中、何度もそんな疑問を持った。 ■ システムは完成品ではなく成長するもの だが次第に理解していった。 このシステムは完成品ではない。 成長することを前提に設計されているのだ。 運用しながら改善する。 顧客から新しい要望が出る。 すぐに開発しない。 まずConfigurationで吸収する。 それでも足りなければ次のリリ...

うわっ！羽田空港の搭乗ゲートが、“人生の難易度変更ボタン”に見えた――。 プロジェクトが始まって、まだ1ヵ月。 突然、上司から言われた。 「ロンドン出張、2週間ね」 え？ 研修ではない。 視察でもない。 完全に“仕事”としての海外出張だった。 しかも行き先は、ロンドン。 金融街Waterloo。 当時の私は、社会人8年目。 グローバル案件への憧れはあった。 しかし、正直に言うと、金融の仕組みなんて、ほとんど分かっていなかった。 もちろん、一生懸命勉強した。 市場、決済、トレーディング、金融ネットワーク…。 でも、難しい。 本を読んでも、会議に出ても、正直「分かった気がする」レベルだった。 そんな状態で、突然決まったロンドン出張。 しかも目的は、 「ロンドンで動いている金融システムを理解しに行くこと」 いや、無理では？ “大企業案件”のリアル 今振り返ると、こういう巨大案件に入れるのは、大企業の強さだと思う。 日本の金融市場にも影響を与えるレベルのシステム。 その現場へ、実際に行ける。 これは普通では経験できない。 だからこそ、私は思った。 「ここで実力を見せないといけない」 まだ何者でもない。 でも、ここで結果を出せれば、自分は変われるかもしれない。 気合だけは、異常に入っていた。 ロンドン金融街・Waterlooへ メンバー構成は5人。 ・サーバチーム ・運用メンバー ・アプリケーション担当の私 ・そして、プロジェクト部長 営業はいなかった。 つまり、“売るための出張”ではない。 純粋に、システムを理解するための出張だった。 このメンバー構成が、逆に緊張感を生んでいた。 特に、システム部長。 寡黙。 静か。 でも圧倒的な威厳がある。 余計なことは話さない。 しかし、質問には本質だけを返す。 当時の私は、その空気だけで緊張していた。 2週間は長いのか？短いのか？ 当時は、「2週間の海外出張」と聞いて、かなり長く感じた。 初めての泊まり出張。 しかも海外。 それだけで非日常だった。 でも、今なら分かる。 巨大金融システムを理解するには、2週間なんて短すぎる。 サーバ構成。 運用設計。 監視。 DB。 ネットワーク。 市場との接続。 一つ理解すると、...

うわっ！机の上に積まれた英語ドキュメントが、まるで金融街のビル群みたいに見えた――。 社会人8年目。 私はずっと「グローバルプロジェクトに入りたい」と手を挙げ続けていた。 英語は少しだけ自信があった。 とはいえ、TOEICは750点。 今思えば、全然ペラペラではない。 でも、海外案件に関わりたい。 海外の人たちと仕事をしたい。 日本だけでは見えない世界を知りたい。 そう思いながら、少しずつ英語を勉強し、その時を待っていた。 そして、ついにそのチャンスがやってきた。 「英語プロジェクトに入ります」 当時の私は、かなり嬉しかった。 やっと来た。 待ちに待ったグローバル案件だ、と。 ただ、そのタイミングで気になっていたことがあった。 チームの中に、かなり強烈な“パワハラ気質”の営業がいたことだ。 正直、空気は重かった。 でも、仕事は仕事。 「せっかく掴んだチャンスだ。全力でやろう」 そう自分に言い聞かせていた。 ロンドンが本拠地の金融システム プロジェクトの中心はロンドン。 ロンドンの金融会社のシステム部門が持つシステムを、日本へ展開する案件だった。 日立は、日本側ベンダーとして参画。 私たちの役割は、そのシステムをプロフェッショナルの視点で確認し、日本への導入方法を探ることだった。 基本的には、ロンドンで動いているシステムをパッケージ化して持ってくる。 日本側にもサポートメンバーはいる。 しかし、本拠地は完全にロンドン。 つまり、情報も文化もルールも、全部“向こう基準”だった。 そして、アプリケーション部隊は――私一人。 最初の仕事は「読むこと」 大量のドキュメントが渡された。 運用設計書。 スケジュール定義。 バッチ処理設計。 DB設定。 サーバ構成。 ネットワーク構成。 外部システム連携。 金融システムらしく、かなり細かく書かれていた。 逆に言えば、読むことができれば、全体像は見えてくる。 だから最初の仕事は明確だった。 「まずは、このドキュメントを読み解くこと」 しかし、最大の問題が発生する 2次ベンダーから、それぞれ専門領域を持ったメンバーがアサインされてきた。 サーバ担当。 ネットワーク担当。 DB担当。 みんな、それぞれのドキュメントを読み始める。 …が。 ...

うわっ…人生って、“逃げていた場所”から未来が始まることがある。 入社して8年目。 私は、ある意味で“平穏”なエンジニア人生を送っていた。 いや、正確には違う。 ずっと避け続けていたものがあった。 それが—— パワハラ営業だ。 怒鳴る。詰める。無茶を言う。 現場を振り回し、空気を凍らせる。 そんな人物だった。 だから私は、できるだけ距離を取っていた。 だが、ある日。 突然、その営業案件への参加を命じられる。 「英語できる人、他にいないから」 ……え？ ■ “英語ができるシステム屋”は、実は少ない その時、私は開発部隊の中で唯一の参加者だった。 しかも、アプリチームからも一人だけ。 理由は単純。 「英語が多少読めるから」。 これ、IT業界では意外と議論になる話だ。 システムは作れる。 コードも書ける。 だが、“英語で運営される世界”に入れる人材は極端に少ない。 しかも今回の案件は、普通ではなかった。 新しい金融サービスを、日本で立ち上げる。 だが、そのサービス自体が日本に存在しない。 つまり—— 業務そのものを海外から輸入する。 システムも。 運用も。 考え方も。 全部だ。 ■ ロンドンの金融システム、日本上陸 導入されるのは、ロンドンを中心に使われる世界的金融システム。 当然、ドキュメントは全部英語。 仕様書。 設計書。 運用手順。 会議資料。 全部、英語。 しかも、金融知識まで必要になる。 私は、その頃まだ金融システムの知識は未熟だった。 だが、システムそのものは少しずつ理解できるようになっていた。 だからこそ言われた。 「アプリチーム目線で指摘してほしい」 いや、簡単に言うな。 こっちは、いきなり世界基準の金融システムに放り込まれている。 しかもプロジェクトのコントローラーは、1次受けベンダーの重鎮。 プロパー側も全体統括クラスしかいない。 そこに—— あのパワハラ営業。 そして、その取り巻き。 現場の空気は、常に張り詰めていた。 ■ “嫌いな人間”が、巨大案件を取ってくる現実 ここ、かなり議論を呼ぶと思う。 私はその営業が嫌いだった。 今でも、やり方が正しかったとは思わない。 だが。 こんな巨大プロジェクトを取ってくる。 しかも、日本に存在し...

うわっ、完成を見届けない仕事に意味なんてあるのか！？——そんな疑問が、社会人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人規模の開発プロジェクト。 だが、用意された開発スペースは明らかに足りていなかった。 席はぎゅうぎゅう。 自席で昼ご飯を食べようにも、キーボードの横に弁当を置くスペースすらない。 では、みんなで食べるか？ …その選択肢も消えていた。     ■会議室が消えた世界 本来ならランチの拠点になるはずの会議室。 しかし、1部屋を残してすべてテスト環境に転用されていた。 テスト部屋で食べる？ それも無理だ。 昼休みですらテストは止まらない。 交代で人が出入りし、静寂とは無縁。 「じゃあ、どこで食べる？」 誰も答えられなかった。 ■“サーバ＝机”という禁断の発想 ふと周りを見ると、ラックマウントサーバが雑多に置かれている。 机の上に無造作に置かれたサーバ群。 「場所がなくて…」という言い訳とともに、 誰かがその上に資料を広げた。 そして気づけば—— サーバを囲んで会議が始まり、 そのまま弁当も広げられていた。 ■ありえないが、合理的だった 今振り返れば完全にアウトだ。 サーバはうるさい。 動き出せば熱い。 だが、不思議なことに“あまり動かない”。 だから、なんとかなってしまう。 開発プロジェクトのピーク。 人も設備も限界状態。 そんなとき、 サーバは「IT資産」から「物理資産」へと役割を変えた。 気づけば、最も大切なはずのサーバが、 ただのオブジェであり、テーブルになっていた。 ■現場が意思決定を超える瞬間 これは笑い話ではない。 むしろ、重要な示唆がある。 現場は、 ・スペースが足りない ・時間が足りない ・余裕がない この3つが揃った瞬間、 ルールも常識も超えて「最適化」を始める。 それがどれだけ“ありえない行動”でもだ。 ■DXの落とし穴 ここにDXの本質的な課題がある。 経営は「デジタル資産を大切に」と言う。 しかし現場は「今この瞬間を乗り切る」ことを優先する。 そのギャップが、 サーバを机に変える。 つまりDXとは、 システムの話ではなく、 “現場の制約設計”の話なのだ。 ■あなたの現場は大丈夫か？ ・サーバが机になっていないか？ ...

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

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

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

うわっ…気づけばどのプロジェクトにも“中国チーム”がいるじゃないか！ ■5つを超えると見えてくる“空気” プロジェクトを1つ、2つと経験しているうちは、個別最適の違いしか見えない。だが、5つ以上回してくると、明らかに「共通の構造」と「チームの空気」が見えてくる。誰が主導し、どこが詰まり、どこで一気に進むのか。そのパターンは驚くほど似ている。 そして、ある事実に気づく。なぜか、どのプロジェクトにも中国チームが必ず入っているのだ。     ■チーム体制には“型”がある いくつかのプロジェクトを横断して見ていくと、チーム体制には明確なパターンが存在する。特に、日本チームと中国チームの役割分担は、意図されたかのように分かれている。 ■日本チームの特徴——分業と複雑性 日本チームは、管理者とエースが明確に分かれているケースが多い。管理者は年配のベテラン、エースは30代前半。役割ははっきりしているが、意思決定や実装スピードはどうしても遅くなりがちだ。 さらに、日本チームは複雑な機能を任されることが多い。業務知識の蓄積があるため、仕様の深い理解や例外処理が必要な領域を担当する。結果として、「難しいが進まない」構造になりやすい。 ■中国チームの特徴——一点集中と圧倒的量 一方、中国チームはまったく異なる。管理者とエースが同一人物、いわば“スーパーマン”が中心にいる。その人物は日本語も堪能で、ブリッジ役を一手に担う。 その周囲を固めるのは20代前半の若手メンバー。彼らの日本語はまだ発展途上だが、手を動かすスピードと量は圧倒的だ。中国チームは、比較的シンプルだが作業量が膨大な機能を担当することが多く、「とにかく進む」。 ■業務知識は誰が持つのか 当初、業務知識は日本チーム側に集中していた。複雑な仕様理解や顧客対応が求められるためだ。しかし、プロジェクトが進むにつれて、中国チームのスーパーマンがその知識を吸収し始める。 すると何が起きるか。スピードと理解が融合し、プロジェクトの推進力が一気に変わる。 ■違いを“楽しめるか”が成否を分ける こうして見ていくと、日本チームと中国チームは対立構造ではなく、補完関係にあることが分かる。 ・日本：複雑性と品質 ・中国：スピードと量 この違いをストレスと捉えるか、強みと捉えるかで、プロジェクトの...

うわっ、終わったはずのプロジェクトが、いまだに頭の中で続いている――。 ■プロジェクトは「長さ」で記憶に残るのか 社会人になってから、いくつものプロジェクトを回してきた。 短いものから長いものまで。 短くて2、3か月、長くて2年以上。 やはり記憶に残りやすいのは長いプロジェクトだ。 そりゃそうですよね。 時間をかけ、苦労し、乗り越えた分だけ、思い出は濃くなる。 しかし、例外もある。 短いのに、妙に強烈に残るプロジェクトがあるのだ。 ■3か月で終わった、終われなかったプロジェクト 今回のプロジェクトもそうだった。 わずか3か月で離れることになった案件。 正直、悔しかった。 「役に立ちませんでしたよ」と言われているような気がしたからだ。 もちろん、そんなことはない。 理由はシンプルで、部署間の取り決め。 最初から「いついつまで」という約束が決まっていた。 直前に一つのプロジェクトをやり遂げていた私は、 次も活躍できる自信があった。 だが現実は違った。 ■“関われるのに、踏み込めない”という制約 契約上、メインタスクには関われない。 意思決定にも深く入れない。 できることは、情報を伝えること。 補足説明をすること。 私は、できる範囲で動いた。 説明会の資料作成を手伝い、 何かあればアドバイスをする。 しかし、それ以上は踏み込めない。 目の前では、同期がメインでプロジェクトを回している。 明らかに忙しい。 助けたい。 でも、リードが取れない以上、 そのタスクをカバーすることはできなかった。 ■やり切れなかったという違和感 そして、3か月。 私はプロジェクトを離れた。 形式的には「完了」。 しかし、感覚としては「未完了」だった。 何か引っかかる終わり方。 やり切った感覚が、まったくない。 ■その後に知った“もしも”の連続 そのプロジェクトは、その後も何年か続いた。 そして、かなりドタバタしていたらしい。 作り直し。 方向転換。 混乱。 話を聞くたびに、こう思ってしまう。 あの時、もう少し踏み込んでいれば。 あの時、自分の手を動かしていれば。 何か変えられたのではないか。 もちろん、後からなら何とでも言える。 契約や役割の制約は現実だ。 それでも、この「心残り」は消えない。...

途中 から 入る 者 に しか 見え ない プロジェクト の リアル う わっ、 気 づ い たら プロジェクト が“ 満員 電車” に な って い た！ IT プロジェクト に は、 さまざま な 関わり 方 が あり ます。 その 中でも「 支援」 という 立場 は、 少し 特殊 な ポジション です。 私 が 所属 してき た の は、 大規模 アプリケーション 開発 を サービス として 支援 する 部隊。 プログラム の 整理、 構造 の 整理、 ベンダー 間 の 調整 や 交渉 など、 巨大 化 した プロジェクト を 支える 役割 です。 しかし、 この 仕事 に は 一つ 特徴 が あり ます。 それ は―― プロジェクト の 最初 に 立ち会う こと が ほとんど ない という こと です。 ■ プロジェクト は 最初 から 巨大 では ない 大規模 プロジェクト と 聞く と、 最初 から 大 人数 で 始まる よう に 思える かも し れ ま せん。 しかし 実際は まったく 違い ます。 最初 は 数 人 です。 新しい システム の 検討 は、 ほんの 数 人 の メンバー から 始まり ます。 方向 性 を 議論 し、 必要 な 機能 を 整理 し、 どの 会社 と 組む か を 考える。 やがて 中心 と なる ベンダー が 決まり、 基本 設計 に 入り ます。 この 段階 でも まだ 数 人。 しかし、 設計 が 進む につれて、 少し ずつ 人 が 増え てい き ます。 ■ 設計 から 開発 へ、 人 が 爆発 的 に 増える 設計 が 本格 化 すると、 メンバー は 数 十人 に なり ます。 ここ で 各 ベンダー が 開発 要員 を アサイン し 始め ます。 設計 書 の 承認 が 下り、 開発 フェーズ に 入る 頃 に は、 プロジェクト は 一気に 膨 ら み ます。 設計 が 10 人 なら、 開発 は 5 倍〜 10 倍。 つまり、 50 人 から 100 人 規模。 そして、 テスト 工程 に 入る ころ。 ここ が プロジェクト の ピーク です。 ■ プロジェクト ルーム は 鮨詰め 状態 人 が 一番 多く なる タイミング。 プロジェ...