Digital Heroes: Guide to IT World

社内コンサル4年目、現場の最前線で気づいた「チームの力」の本質 うわっ、気づけば“支援者”のはずの私が、プロジェクトのど真ん中に立っていた！     ■ 社内コンサルという“安全地帯”のはずが 社会人4年目。私は社内コンサルとしてプロジェクトに入った。 本来の役割は支援だ。サーバ構築で詰まれば助言をし、新しいフレームワークの理解を促し、迷ったときには設計の指針を示す。あくまで一歩引いた立場のはずだった。 しかし現場は違った。 議論が膠着すれば意見を求められ、障害が出れば判断を委ねられ、スケジュールが揺らげば調整役を担う。気づけば“困ったときのあの人”になっていた。 支援者として入ったはずが、いつの間にかプロジェクトをリードしている。 私はもう完全に“プロジェクト側の人間”だった。 ■ 新人研修で教えた、あの後輩 私は新人研修の担当もしていた。だから下との接点は多い。 そんな中、かつて教えた新人の一人がプロジェクトに加わることになった。 京大卒。地頭は抜群。理論も強い。 だが、どこか少し抜けている。資料の詰めが甘かったり、段取りが少し不器用だったりする。 そして彼は、フレームワークチームから“新たな社内コンサル”として送り込まれてきた。 正直に言えば、私はホッとした。 孤軍奮闘していた現場に、理解者が来たと感じたからだ。 ■ 技術を超えた“対話”の時間 彼とはよく話し込んだ。 昼ご飯を一緒に食べ、設計の悩みを議論し、新しいフレームワークの仕様を確認する。夜の飲み会にも誘ったし、合コンにも連れていった。 仕事では効率が悪い部分もある。 だが彼は、常に最新情報を持ち込み、設計に新しい視点を与えてくれる存在だった。 「その実装だと、将来の拡張性が弱いかもしれません」 そんな一言が、設計の方向を変えることもある。 彼との議論を通じて、私自身のJava理解も一段と深まった。 教える側のはずが、学ばされている。 プロジェクトは技術力だけで動くのではない。 対話で動くのだ。 ■ 結束が生む“見えない推進力” プロジェクト成功の秘訣は何か。 優秀なエンジニアの数ではない。最新技術の導入でもない。 結束だ。 信頼関係があるからこそ、本音でぶつかれる。 心理的安全性があるからこそ、新しい挑戦ができる。 昼の雑談も、夜の飲み会も、無駄ではなかっ...

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

20年超の現場で何度も見た、後回しタスクの恐怖 うわっ、動くはずのシステムが“英語”で止まるなんて誰が想像しただろう！ 社会人20年以上。これまでいくつものプロジェクトに入ってきた。要件定義、設計、開発、炎上、立て直し――一通りは経験してきたつもりだ。 お客様側のプロジェクトに入ったのは、金融機関のWebシステム。私はJavaの自社フレームワークを適用する社内コンサルタントとして参画した。立場はコンサルタント。リードする責任者ではなかった。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ コンサルか、リードか しかし、プロジェクト内の社員の少なさを見た瞬間、違和感を覚えた。この体制で本当に最後まで走り切れるのか。 気づけば私は一歩踏み込み、設計レビューに入り、仕様調整に入り、いつの間にかリードチームの一角にいた。 「あなたはコンサルですか？それともリードですか？」 そんな冗談交じりの会話をしたこともある。 だが、あるテーマを前にしたとき、迷いは消えた。 ここは自分がやらなければならない、と。 ■ 多くのプロジェクトでネックになるもの それが「英語化」だった。 機能、画面、メッセージ、帳票。すべてを英語にする。 日本語で作っているものを英語に置き換え、フォーマットを整え、レイアウトを確認し、画面上で正しく動くかを検証する。 やることは単純だ。 プログラムをコピーし、文言を英語にするだけ。 しかし現実は甘くない。 日本語と英語では文字の長さが違う。ボタンがはみ出す。テーブルが崩れる。メッセージが途中で切れる。一つひとつ合わせていく地道な作業だ。 ■ なぜ後回しにされるのか プロジェクトメンバーは、仕様やロジックにこだわる。 パフォーマンス改善、機能追加、バグ修正。目に見える成果に集中する。 英語化は「最後でいい」となりやすい。 しかも英語が得意な人は多くない。 結果、夏休みの宿題のように後ろへ後ろへと押しやられる。そして終盤、リソースが尽きる。誰もやらない。 リリース直前になって「あれ？英語画面が崩れている」「海外拠点で使えない」と問題になる。 私はこの光景を、何度も経験してきた。 ■ 最初に詰まった金融Webプロジェクト この金融機関のWebシステムは、私にとって最初に...

金融最前線、COBOL終焉、そしてWeb革命のただ中で うわっ、ここは本当に昼と夜の境目がない街なのか!? 社会人3年目から4年目に入ろうとする頃、私は金融系企業の最前線プロジェクトにいた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■金融最前線という名の不夜城 そこは長年、COBOLで基幹システムを作り込み、巨大で堅牢な仕組みを築き上げてきた世界。止まらないことが絶対条件。1秒の遅延も許されない緊張感。 しかし、時代は大きく揺れ始めていた。——時はまさにCOBOLの終焉。 ■Web時代の幕開け ホームページは「会社案内」ではなくなりつつあった。問い合わせを受け、データベースとつながり、業務そのものを動かす入口になる。 Javaの機能拡張は、その変化を強く後押ししていた。 私たちは社内で作ったJavaのWebアプリケーションフレームワーク、さらにシステム間連携アプリケーションのフレームワークを適用し、新しい金融の姿を描こうとしていた。 ■気がつけば、どっぷり 最初は「最前線で学べる」と胸を躍らせていた。 だが、気づけばプロジェクトにどっぷり。 深夜残業は当たり前。 「机で寝る？」 「終電、間に合うかな？」 そんな会話が自然に飛び交う。 ほぼ毎日、終電ダッシュ。 それでも、終電を逃す人が何人かいる。 「え？あの人たち、どこに泊まってるの？」 ■先輩が教えてくれたこと ある夜、先輩がぽつりと言った。 「会社、近くのホテルと契約してるんだよ」 何室かキープしていて、空いていれば優先的に泊まれる。会社名を伝えれば、チャージはすべて会社負担。 「急に終電逃しても、そこ行けばいい」 ——え？そんなことあるの？ ■見えない“夜のインフラ” 衝撃だった。 会社は、挑戦する人を放り出していなかった。 最前線で戦う人たちを支える、見えないインフラがあったのだ。 もちろん、働き方として理想かと言われれば議論はある。だがあの時代、Web革命の渦中で、組織は本気だった。 一生懸命働く人を、きちんと守る仕組みを用意していた。 ■今、振り返って思う プロジェクトは技術だけで動かない。 人が動くから、未来が動く。 そして人を支える仕組みがあるから、挑戦は継続できる。 あの“不夜城”を支えていたのは、Javaでもフ...

― 作ったプラットフォームに、人生まで巻き込まれた話 ― うわっ、気づいたら“評論家”のはずが“徹夜組”の一員になっていた！ 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 社内コンサルとしての使命 私は、自分が作ったプラットフォームを社内に浸透させるため、いわば“社内コンサル”の立場に立っていた。 使い方を説明し、思想を語り、未来の運用まで見据えた設計を求める。 さすがプラットフォーム。 検討しにくい細部、もっと先の運用フェーズで問題になる論点まで、設計段階で考えることを前提としている。 私は、それでいいと思っていた。 自分が作ったものだからこそ、その理想に疑いはなかった。 ■ しかし、現実のプロジェクトは甘くない そのプロジェクトは、人が少ない。 設計する人も足りない。 プログラミングする人も足りない。 深夜残業が常態化していた。 私は社内コンサルとして、設計レビューをし、使い方を教えていた。 だが、そもそも設計に必要な情報がない。 開発プロジェクトは情報が少ない。 顧客側も、作る人と運用する人は別。 ベンダー側も、開発担当と運用サポートは別。 だから、運用の要望や将来の課題は、設計段階ではほとんど出てこない。 それでも私は言う。 「運用まで考えましょう」と。 だんだん、言いづらくなってきた。 この状況で“コンサルです”とは。 ■ 手を出すという決断 人は少ない。 検討すべきことは多い。 となると、自分もやるしかない。 私は設計に手を出し始めた。 プログラミングにも手を出した。 研修も受けてきたし、一定の自信はある。 だから、やれる。 そう思った。 そして、ふと気づいた。 自分もしっかり深夜残業組の仲間入りをしていた。 ■ コンサルか、リーダーか コンサルは“答えを示す人”。 プロジェクトリーダーは“背負う人”。 私はどちらなのか。 でも今は、役割よりも大事なものがある。 プロジェクトを前に進めること。 理想と現実の間を埋めること。 助言だけでは、未来は作れない。 手を動かしてこそ、信頼は生まれる。 だから私は、両方やる。 考え、設計し、書き、支える。 私ならできる！明日から踏み出す

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