Digital Heroes: Guide to IT World

気づけば“主役”が入れ替わっていた――プロジェクトは静かなる陣取り合戦だった！ ― 足りない現場を救い続けた、中国系ベンダーの底力 ― 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■ 研修講師からプラットフォーム構築へ 私は新人研修をリードした後、全社プラットフォームの構築に従事した。 標準化・共通化を掲げ、現場で再利用できる仕組みを整える仕事だ。やがてそのプラットフォームを各部門へ適用するため、社内コンサルとして現場に入ることになった。 そして最終的には、現地プロジェクトのリードを任される立場に。 理想と現実のギャップを埋める役割だった。 ■ 三つ巴の体制 そのプロジェクトは、日立と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代でプロジェクトをリードしている人。派手さはない。だが、迷いがない。若手の意見を聞き、必要な場面では決断を下す。その姿は、長年の経験に裏打ちされた静かな強さだ。プロジェクトがぶれないのは、彼が“軸”を握っているからだ。 働き方は十人十色 定時になると颯爽と帰る人がいる。一方で、なかなか帰らず、最後まで残る人もいる。声が大きく、会議の空気を一瞬で支配する人。お昼は必ず机で寝ると決めている人。ずっと席にいるけれど、正直、成果がどこにあるのか分からない人もいる。 新幹線通勤で遠くからやってくる人もいれば、職場の近くに住み、誰よりも早く来ている人もいる。距離も、リズムも、価値観も違う。それでも同じゴールを目指している。 “ほとけ”という存在 一番上の人は、なぜか「ほとけ」と呼ばれている。いっつもニコニコしている。怒らない。焦らない。だが、何をしているのかは少し不明だ。それでも、彼がそこにいるだけで場の緊張が解ける。まさにプロジェクトのキャラクターマスコット的存在。見えない安心感が、チームを支えている。 人がいるから、前に進む プロジェクトは、完璧な人材で構成されているわけではない。むしろ、ばらばらだ。だが、その違いこそが推進力になる。声が大きい人が勢いをつくり、静かな人が土台を固め、リーダーが方向を示す。 いろんな人に支えられて、プロジェクトは今日も動いている。成果は個人のものではなく、関わる全員のものだ。 だからこそ思う。 この多様さを力に変えられるのは、私たち自身だ。 私ならできる！明日から踏み出す

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

システム開発の“本当の温度”は、夜に現れる うわっ……ドアを開けた瞬間、タバコの匂いと熱気が一気に押し寄せてきた。 それが、私が初めて足を踏み入れた システム開発の最前線 だった。 ■ タバコの匂いが漂う開発部屋 整ったオフィスやオンライン会議に慣れていた私にとって、その開発部屋は別世界だった。 少し薄暗く、モニターの光だけが浮かび上がる空間。 ここが、今まさに動いている“現場”なのだと、肌で感じた。 ■ 現場の重鎮と仲良くなる方法 この現場には、私と同じ社員はわずか3名。 他は関係する開発社員さんたちで、しかも 2社が同じ現場に入り、開発領域を取り合っている関係 だった。 だからこそ、私は考えた。 「まずは現場の重鎮と仲良くなろう」と。 同じ年代の人を見つけ、勇気を出してご飯に誘った。 肩書きよりも、人として向き合うこと。それが最短ルートだった。 ■ 夜になると、現場の顔が変わる そして、私が「現場だなぁ」と強く思ったのは、 夜 だった。 定時になっても、帰る人はゼロ。 8時を過ぎて、ようやく一人、二人が帰りだす。 10時を超えると、少しソワソワした空気が流れ、20代の人たちはだいぶ帰宅している。 それでも、 まだ半分は残っている 。 ■ 不夜城と呼ばれる理由 11時。終電を気にして急ぐ人たちが出てくる。 12時。私も終電に向かって席を立つ。 それでも、まだ残っている人たちがいる。 「あれ？」と目を向けると、50代の人が、変わらずキーボードを叩いている。 帰らない人たちが、確かにそこにいた。 ――不夜城と呼ばれる現場。 都市伝説だと思っていたけれど、 実在していた 。 ■ やっぱり、現場は現場 効率や働き方改革の議論は、もちろん大切だ。 でも、現場には、数字や資料では測れない“熱”がある。 その熱を知っている人たちが、最後まで残っていた。 私は思った。 やっぱり、現場は現場だ、と。 私ならできる！明日から踏み出す

年齢の先にあったのは、圧倒的な「経験知」だった うわっ……その人が、全部決めていたの!? プログラミングやシステム開発と聞くと、どんな人を思い浮かべるだろうか。多くの人が「若い」「30代くらい」「最新技術に強い人」と答えるのではないだろうか。私自身も、ずっとそう思っていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       若手が前に立つプロジェクトの記憶 これまで関わってきたプロジェクトでは、実際に30代のエンジニアが前面に立ち、プロジェクトをリードしていた。 プラットフォーム開発でも、40代の課長が大きな方針を決め、30代のメンバーが各エリアの開発を引っ張る。そんな構図が当たり前だった。 Javaも、当時はまだ「新しい」プログラミング言語だった。 だからプラットフォーム開発は、40代から20代までの比較的若いメンバーで作られている。私は、ずっとそういう世界を想像していた。 現場で目にした、想定外の光景 ところが、実際の現場に足を運んだとき、私は本当に驚いた。 プロジェクト全体をリードしていたのは、50代のエンジニアだったのだ。 特に業務中心の領域では、60歳に近い人が意思決定をしている。 「あの人が、すべての仕様を決めている」 誰もがそう口を揃える存在が、確かにそこにいた。 “あの人”の正体 その人は、超が付くほど経験豊富なエンジニアだった。 Windowsが世に出る前から、システムを支え続けてきた人。 技術だけでなく、金融という業界そのものを知り尽くしている。 30代のエンジニアでさえ、まだまだペーペーと言われる世界。 「システムのこと」と「金融のこと」、その両方を本当に理解している人は誰か。 答えは、迷いなく“あの人”だった。 重鎮がつくる、揺るがないシステム その人は、お客様からも絶大な信頼を得ていた。 派手さはない。最新技術を声高に語ることもない。 しかし、その人が形作るシステムは、金融業界の根幹を静かに支えている。 エンジニアの中心は、若者だけではない。 現場を見て、私はその事実をはっきりと理解した。 年齢ではなく、積み重ね 年齢は関係ない。 問われるのは、どれだけの修羅場をくぐり、どれだけの責任を背負ってきたか。 その積み重ねこそが、最後にシステムを...

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

恵まれた環境が“普通”だった私が、現場で学び直したこと うわっ！世界が一気に切り替わった——まるでタイムスリップだ。 これが、私が新しいシステムプロジェクトに足を踏み入れた瞬間の正直な感想だった。     ■ 本社プロジェクトという“標準” これまで私は、本社主導のプロジェクトが当たり前だった。30階を超える最新ビルの一室。フリーアドレスの机にPCを広げ、内装は洗練され、食堂もある。買い物は基本、1階のコンビニで完結する。でも、駅を越えれば活気ある商店街。 ——正直、恵まれた環境だった。そして、それが“普通”だと思っていた。 ■ 新しいプロジェクト、東京の反対側へ そんな私が、今度はお客様のプロジェクトに入っていくことになった。場所は、東京の反対側。関係会社の1フロアを借りているというオフィスだ。 入口はきれい。6階建てで新しくはないが、整然としている。私たちのフロアは5階。エレベーターを降りた瞬間、少しだけ胸がざわついた。 ■ 衝立の向こうにあった“現実” 衝立で区切られた突貫の入口。後で知ったが、会社が違うためのセキュリティ対策だった。その扉を開けると—— 古い机。ぷーんと漂うタバコの匂い。絨毯は、正直きれいとは言えない。窓は開いておらず、段ボールが積まれて光が入らない。 「なるほど、これが現場ってやつか……」 思わず身震いした。 ■ “現場”は条件じゃない、覚悟だ だが、ここにはリアルなエンジニアがいる。制約の中で手を動かし、システムを止めないために知恵を絞る人たちがいる。 私はここで、彼らをサポートしていく。環境の良し悪しではない。必要なのは、寄り添う覚悟と、現実を直視する勇気だ。 ガラス張りの世界を出て、初めて見えた景色がある。 私ならできる！明日から踏み出す

「答えを出す仕事」だと思っていた自分が、最初に突きつけられた問い うわっ……思っていた“コンサル”と、ぜんぜん違う！ そんな感嘆にも似た違和感を覚えたのは、社内コンサルとして証券系のプロジェクトにアサインされた、その初日だった。     ◆ 社内コンサルとして現場に入るということ 社会人になって二度目の「お客様プロジェクト」。 場所は、少し年季の入った古いビル。中には複数のプロジェクトが同時に走っていて、独特の緊張感が漂っていた。 そこでふと浮かんだのが、 「……で、私は何をコンサルすればいいんだ？」 という、根本的な問いだった。 ◆ 求められていたのは“答え”ではなかった 私に求められていた役割は、Justwareそのものの使い方だけではなかった。 Justwareを どう設計し、どう各プロジェクトフェーズに適用していくか 。 要件定義、設計、開発、テスト——それぞれの段階で、どんな設計思想を持つべきか。 その考え方を整理し、支えることだった。 ◆ 説明する相手は「新人」ではない 数人規模の説明会。 やっていること自体は、新人向けにこれまで何度も説明してきた内容と似ていた。 でも、目の前にいるのは各社のプロフェッショナルエンジニアたち。 顔つきが違う。 空気が違う。 「下手したら、鋭く突っ込まれるかもしれない」 そんな、恐怖に近い感覚すらあった。 ◆ 自分が作ってきた“プラットフォーム”を語る 説明したのは、これまで自分が関わり、作ってきたプラットフォームの考え方。 Justwareを“どう使うか”ではなく、 「なぜ、そう設計してきたのか」 「どんな失敗と改善を重ねてきたのか」 話しながらも、心のどこかで不安が消えなかった。 「本当に受け入れてもらえるだろうか？」 ◆ 今思えば、それは杞憂だった 振り返ってみれば、その不安の多くは杞憂だった。 ちゃんと向き合えば、プロはちゃんと聞いてくれる。 もっと自信を持っても、良かったのかもしれない。 でも当時の自分は、それだけ真剣だった。 だからこそ、その現場に真正面から入っていく覚悟ができたのだと思う。 ◆ 違和感は、成長のサイン 「コンサルとしての違和感」。 それは、役割が変わり、視座が一段上がったサインだった。 答えを出すだけ...

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