Digital Heroes: Guide to IT World

うわっ…言語が変わるだけで、人はここまで不安になるのか!? ■社会人6年目、突然の「Java化」 社会人6年目。私は、日本の金融業界の中心を司る巨大企業の基幹システム刷新プロジェクトにいた。これまで長年、COBOLで作り上げられてきた巨大なシステム。その変換先として提示されたのが「Java」だった。 最大時には200人を超える大規模プロジェクト。だが現場に広がったのは期待ではなく、不安だった。 「COBOLしかやってきていない自分たちは、Javaに対応できるのか？」 ■COBOLという“設計至上主義” COBOLは手続き型言語だ。プログラムは上から下へ、順番通りに積み上げる。 一行の文字数、配置、メモリの使い方まで厳密に意識しながら書く。 部品を呼び出すというより、「業務の流れ」をそのままコードに落とし込む。 だからこそ、設計がすべてだった。 設計で全体の順序を完璧に組み立て、それを忠実にコードに写す。 このスタイルに慣れたエンジニアにとって、「自由度の高いJava」は未知の世界に見えた。 ■Javaがもたらした“構造の解放” しかし、実際にプロジェクトが動き出すと、状況は大きく変わった。 Javaはオブジェクト指向をベースに、部品化・再利用・柔軟な構造を許容する。 さらに、メモリ管理の負担も軽減されている。 COBOL時代のように、細かい領域を意識し続ける必要はない。 この“制約の解放”が、現場に新しい風を吹き込んだ。 設計者もプログラマーも、思った以上にスムーズに適応していったのだ。 ■「言語は違えど、本質は同じ」 振り返ると、気づくことがある。 プログラム言語は違っても、「構造を理解し、論理を組み立てる」という本質は変わらない。 実際、Java以降の言語は構造が似ている。 現在主流のPythonやRubyといったスクリプト言語も、オブジェクト指向ベースであり、英語に近い記述で理解しやすい。 つまり、一つの言語で“構造”を理解した人は、次の言語にも応用が効くのだ。 当時のJava移行は、今で言えば「Javaからクラウド（Lambdaなど）への移行」に近いインパクトだった。 それでも、現場は乗り越えた。 ■200人が証明した「進化できる力」 最終的に、この200人規模のプロジェクトは成立した。 COBOLの...

Cobol世代からAI時代へ——学び方が変わる瞬間 うわっ…英語ができないとコードすら書けなくなるのか!? ■「Javaってどう学べばいいの？」という時代 社会人になりたての頃、Cobolをずっと習ってきた先輩たちから、こんなことを聞かれた。 「Javaって、どうやって学べばいいんだ？」 今なら簡単だ。YouTubeを開けば、いくらでも解説動画がある。 だが当時は違った。まだYouTubeはそこまで流行っていなかった。 だから、基本は“本”。 それが唯一の学習手段だった。     ■分厚い本＝ステータスだった時代 Javaの日本語の本も確かにあった。 しかし、正直に言えば難しかった。 理解が追いつかない。 読み進めるほどに、自信が削られていく。 そんな中で、多くのエンジニアが持っていたのが、オライリーの分厚い本だった。 あの本を持っていること自体がステータスだった。 「これを読んでいる自分は、できるエンジニアだ」 だが現実は違う。 その分厚さと難解さに、多くの人が挫折していった。 ■答えはシンプルだった——英語で学ぶ では、どうすれば良かったのか。 答えはシンプルだった。 “英語で学ぶ” 最新の情報は、いつも英語から始まる。 だから英語の本を読み漁るしかなかった。 辞書を片手に、一文ずつ理解していく。 正直、かなり難しかった。 それでも、得られるものは大きかった。 ■“システム英語”という武器 そこには、単なる英語以上の価値があった。 「システム特有の言い回し」が身についたのだ。 これは普通の英会話では絶対に学べない。 そもそも、英会話の先生でシステム開発を理解している人はほとんどいない。 日本の開発事情を理解している人もいない。 だからこそ思う。 「システムを英語で学ぶ」のは、非常に合理的な選択だ。 ■今の時代の学び方はどう変わったか では、今の人たちはどうしているのだろうか？ YouTube？ネット記事？ 確かに、それも正解だ。 だが、もう一歩踏み込める方法がある。 ■日英で学ぶという新しいスタイル 例えば、システム開発について日英両方で発信しているYouTubeを使う方法だ。 同じ内容を、日本語と英語で比較する。 それだけで理解が一気に深まる。 字幕を付けることもできる。 だが、あえて付けない方がいい。 耳と文脈で理解する力が鍛えられるからだ...

うわっ…コードを書いていないのに、プロジェクトが崩壊する!? ■Cobol時代にはなかった“新たな難しさ” かつてCobol中心の時代、システムは比較的シンプルだった。構成も閉じた世界で管理され、外部依存は限定的だった。しかし、Javaへの移行とともに、ある領域が一気に難しくなった。それが「構成管理」、特にライブラリ管理である。 ■Javaの進化が生んだ“自由と混乱” Javaは極めて拡張性が高い言語だ。豊富な標準機能に加え、世界中の開発者が機能をパッケージやクラスとして公開している。これにより、ゼロから作らなくても高度な機能を簡単に取り込めるようになった。これは生産性の飛躍的向上を意味する。 だが同時に、「どれを使う？」という新たな判断が発生した。     ■パッケージ選定という意思決定の重さ 各パッケージは、世界中の優秀なエンジニアが作り込んだものだ。設計も品質も高く、使わなければ開発規模は膨大になる。だが、選択を誤れば、システム全体に影響を及ぼす。 しかも、必要な機能は複数のパッケージで実現できる場合も多い。どれを選ぶかは、単なる技術選定ではなく、プロジェクトの将来を左右する経営判断に近い。 ■最大のリスクは“見えないセキュリティ” 問題はセキュリティだ。このパッケージ、本当に信じていいのか？変なコードが仕込まれていないか？安全性は？安定性は？ 情報が限られる中、ネットを検索し、仕様を読み、過去の実績を調べる。かつてはSun Microsystemsの情報を読み漁りながら判断することもあった。しかし、それでも確信は持てない。 ■終わらないアップデートとバージョン地獄 さらに難しいのは、これらのパッケージが常に進化していることだ。アップデートは頻繁に行われ、新機能や修正が追加される。だが、複数のパッケージを組み合わせると、バージョンの整合性が問題になる。 あるパッケージを更新すると、別のパッケージと互換性が崩れ、動かなくなる。逆に更新しなければ、セキュリティリスクが高まる。このトレードオフは、現場に重い意思決定を突きつける。 ■それは“迷宮の入り口”だった こうして、構成管理は単なる管理作業ではなくなった。技術、セキュリティ、運用、将来性——あらゆる要素を考慮する複雑な意思決定プロセスへと変わったのだ。 そして...

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

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

えっ、プログラミング言語の“完成形”が日本にあっただと!? ■COBOLだけではなかった 社会インフラを支える巨大システム。その裏側で、日立はCOBOLを手掛け、協会もリードしながら、日本国内で確固たる地位を築いていた。 しかし、本質はそこでは終わらない。 彼らは“言語”だけでなく、もっと根本的なものに手を伸ばしていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■システムの核に踏み込む サーバを作る。これは分かりやすい。 だが、システムを構築する上で絶対に避けて通れないものがある。 それがDB、データベースだ。 世界を見渡せば、MicrosoftのSQL Server、IBMのDB2、OracleのOracle。 主要なDBはほぼ海外製品が席巻していた。 その中で、日立は挑戦していた。 それがHiRDB。 ■言語の“さらに内側”へ HiRDBは、Cosminexusなど日立のシステム基盤と連携するDBだ。 だが本当に驚くべきはそこではない。 そのHiRDBを操作するためのSQL、つまり“DBを動かす言語”まで、日立は自ら設計していた。 しかもその名称は、あえてのSQL。 ややこしいが、これはHiRDB専用のSQLである。 ■なぜ独自SQLが必要なのか 実務でDBを触るとすぐに気づく。 同じSQLでも、DBごとに微妙に構文が違う。 「あれ？」 「なんでこう書くんだ？」 そう思いながら、例外的なルールを覚えていく。 それが現場の現実だ。 ■“癖がない”という価値 だが、DBを極めた分析屋たちはこう言っていた。 「HiRDBのSQLが一番癖がない」 構文が整っている。 規則性がある。 理解しやすい。 つまり、最も“自然に使える言語”だった。 Oracleでも、SQL Serverでも、どこかで違和感に出会う。 だがHiRDBは違う。 その違和感を排除する方向で設計されていた。 ■技術の深さと広がらなかった理由 残念ながら、HiRDBは世界的に広く普及したとは言えない。 しかし重要なのはそこではない。 DBそのものを作り、 その上で動く言語まで設計し、 さらに“人にとって分かりやすい形”に整える。 このレベルの要素技術を内製できるエンジニア集...

 えっ、コードを書く前に“言語そのもの”を日本企業が握っていた世界があったのか!? ■社会人6年目、初めて知った衝撃 社会人6年目、システムの現場に深く入り込んだときだった。 私はそれまで、プログラム言語は“誰かが作ったものを使うもの”だと思っていた。 Javaにはサポート会社があり、Sun Microsystemsが方針を決める。 Pythonにもルールがあり、コミュニティが進化をリードする。 つまり、「言語は世界のどこかが決めるもの」。 そう信じて疑わなかった。 だが、日立に入って初めて、その前提が崩れる。 ■日立が“COBOLを作っていた”という事実 有名なプログラム言語であるCOBOL。 金融、基幹システム、社会インフラ——日本の根幹を支えてきた言語だ。 そのCOBOLを、日立が作り、リードしていた時代があった。 協議会を作り、仕様を整え、改善を重ねる。 まるで今のPythonやJavaのように、「ルールそのもの」を握っていた。 これは単なる利用者ではない。 “言語の設計者”としての立場だ。 ■メインフレームと一体化した言語戦略 当時の主戦場は、汎用機——メインフレーム。 巨大な1台のサーバーに、すべてを詰め込む時代だ。 このメインフレームを導入する際、 単なるハードウェアでは終わらない。 プログラム実行基盤も含めて、ひとつの“完成されたシステム”として提供される。 そして、その中核にあるのがCOBOLだった。 つまり、メインフレームを導入する＝COBOLで作る。 言語は選択肢ではなく、“前提条件”だったのだ。 ■IBMと戦った日本企業の意地 世界ではIBMがメインフレーム市場を席巻していた。 その巨大な牙城に、日本企業は真正面から挑んでいた。 日立は、その中で単なるハード競争では終わらない戦いを選ぶ。 ハードを作り、基盤を作り、 そして、その上で動く言語まで作る。 つまり、“スタック全体”で戦っていた。 メインフレームに入っているCOBOL。 そのCOBOL自体も進化させていく。 オリジナルのCOBOLをベースにしながら、 実運用に合わせて改善を重ねる。 この一連の動きは、まさにプラットフォーム戦略そのものだ。 ■言語を握るということの意味 言語を作るということは、単なる...

動くシステムはある。でも未来のJava版をどう描くか？ ああっ、まるでパズルのピースが逆さまに飛んでくるようだ！ 私が任されたのは、金融システムのCobolからJavaへの変換プロジェクトでの構成管理だ。 すでにCobolで動いているシステムがあり、設計書も残っている。 だが、それを最新のJava設計書に書き換え、プログラムとして組み上げなければならない。     多様なチーム、複雑な利害 プロジェクトには、日立製作所を1次受けとして、5社ほどの2次受けが参加していた。 各社、Cobolが分かるエンジニア、Javaが分かるエンジニア、そして金融分野に精通した設計者を揃えている。 優秀な2次受けベンダーの方々からの圧も相当で、緊張感は増すばかりだ。 Cobolの常識とJavaの自由度 Cobolの世界では、プログラムの作り方や書く環境はほぼ決まっている。 構成管理といえば、ソースの管理だ。 見出し部、環境部、データ部、手続き部などを決め、各チームの書き方を揃えるのが定石だった。 しかし、Javaとなると話は複雑になる。 書き方のルールだけでなく、パッケージ基準やソース構成、オブジェクト指向を活用した共通クラス構成まで考慮する必要がある。 設計書からDebug、バージョン管理まで まず着手したのは、Java設計書の整理だ。 Cobol設計書を参照しつつ、Javaのクラス構成やパッケージ体系に落とし込む作業。 各チームがバラバラに動くと、後々のDebugやテストで混乱する。 だからこそ、Debug順序も先に決めておく。 構成管理の肝は、バージョン管理だ。 Javaのように複雑な環境では、少しのずれが全体の破綻につながる。 GitやSVNを使い、各チームのコミットルールを統一する。 コミット単位、ブランチ戦略、マージ方針まで細かく定め、2次受け全体で共有する。 学びと挑戦の統合 一方で、Cobol時代の常識は無視できない。 既存の環境・手続き・データ部は大きな制約条件だ。 それを踏まえつつ、Javaのモダンな書き方を適用する。 オブジェクト指向の利点を活かし、共通クラスやライブラリの再利用も進める。 毎日の会議では、5社の代表者が設計書とコードの違いを詰める。 Cobol出身者の意見、Javaエン...

ああっ、気がつけば日本の金融システムの心臓部に手をかけている！ 社会人6年目の私は、少しずつ大きなプロジェクトに参加してきた。最初は数人規模、次第に十数人、そして開発人員が最大八十人規模のチームをリードするまでになった。百人規模でもリードできる自信はあった。しかし、次に待っていたのは最大200人規模のプロジェクト。しかも、対象は日本の根幹を支える金融業界の中心となるシステムだ。このシステムが止まれば、新聞に載るどころの話ではなく、たぶん現場では人の生活や仕事に直接影響が出る。それを意識した瞬間、身震いが止まらなかった。     大規模でも“改善プロジェクト” 200人規模と言っても、大規模プロジェクトとしてはそこまで特異ではない。理由は、これは新規構築ではなく、改善プロジェクトだからだ。最初の構築時は壮絶だったらしいが、私が参加した時にはリリース後で、チームは100人にも満たなかった。 私が指示を受けたのはJavaの構成管理。しかし開発の中心はCobolでの管理が主流だった。Cobolでは管理方法を熟知していたが、Javaでの管理は初めて。サーバの構成、プログラムの構成、どのように本番に載せるか、テストはどう行うか、テスト環境の作り方、設定ファイルの扱い――構成管理の領域は多岐にわたる。プログラム中心で考えてきた私にとって、新しい専門分野への挑戦となった。 構成管理の現場 構成管理担当とは、開発段階から常に話してきた。新人のトレーニングでは、自分で全てやっていたこともある。しかし今回は違う。これは日本を支えるシステムであり、責任の重さが桁違いだ。ミスは許されない。どのサーバに、どの順番で反映するか。テストの順序、バックアップの取り方。すべてを設計し、チームに伝える必要がある。 新しい挑戦と学び このプロジェクトでは、ただコードを書くのではなく、チーム全体の作業効率やリスク管理も意識することが求められる。構成管理という専門分野を深く理解し、現場での判断力を磨くこと。これが次世代のリーダーとしての成長につながると感じた。 百人規模の経験が、200人規模の現場で確実に生きる。自信と緊張が混ざり合う中で、私は初めて「自分が日本を支えている」という実感を持った。 私ならできる！明日から踏み出す

うわっ、日本の根幹が、まだこのコードで動いているなんて——。 社会人6年目。私はすでに5つほどのプロジェクトを経験していた。規模はどれも大きく、100人を超える体制はもはや特別ではない。「これが普通のITプロジェクトだ」と自然に思うようになっていた。周囲も同じだ。関わる案件はどれも社会インフラに近く、失敗が許されないものばかりだった。 そんな環境にいたからこそ、ある日ふとした瞬間に見た光景が、強烈に記憶に残っている。 ■巨大プロジェクトの“当たり前”に潜む違和感 日立製作所という巨大な会社の中で、私は一つの基幹システムの改修プロジェクトに関わっていた。関係者は100人を軽く超え、複数のベンダーが入り乱れ、会議は毎日のように続く。進捗、課題、品質——すべてが緻密に管理されていた。 だが、実際に手を動かす現場に入ったとき、私は思わず息を飲んだ。 画面に並んでいたのは、COBOLのコードだった。 整然と並ぶ英字と数字。長年積み重ねられてきたロジック。その一行一行が、日本の金融や物流、社会の根幹を支えている。 「これが、まだ動いているのか」 それは驚きというより、むしろ“現実”だった。 ■社会インフラを支える見えない技術 COBOLは古い言語だと言われる。しかし、そのシステムは何十年も止まらずに動き続けている。信頼性、安定性、そして実績。どれをとっても圧倒的だ。 だからこそ、簡単には変えられない。 100人規模のプロジェクトが当たり前になる理由も、ここにある。変更一つで影響範囲は膨大に広がり、テストには膨大な時間と人手が必要になる。結果として、プロジェクトは巨大化し、慎重になり、変化は遅くなる。 私はその中で、ある種の矛盾を感じていた。 最先端のITを語りながら、最も重要な部分は“変えられない技術”に依存している。 ■変革はなぜ進まないのか この構造は、日本のITが抱える本質的な課題を示している。 変えたい。でも、変えられない。 効率化したい。でも、リスクが大きすぎる。 だから現場は、巨大な体制と緻密なプロセスで“守る”ことに最適化されていく。 それは間違いではない。むしろ合理的だ。 しかし、その一方で、変革のスピードは確実に鈍る。 私は6年目にして、初めて気づいた。 「プロジェクトの大きさ」や「人数」ではなく、 本当に向き...

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

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

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

う わっ、 助け に 来 た はず なのに、 なぜ こんなに 動き づらい ん だ!? 社会 人 5 年 目。 私 は、 同期 が リード する プロジェクト の 支援 メンバー として 参加 し てい た。 舞台 は 金融 機関 の バック エンド システム。 Java の フレーム ワーク を 活用 し、 大規模 な 業務 システム を 構築 し てい く プロジェクト だ っ た。     私 は、 大規模 システム 開発 部隊。 一方、 プロジェクト を 率いる 同期 は 金融 システム 部隊。 立場 として は「 支援」。 プロジェクト リード の サポート や、 Java フレーム ワーク の 適用 支援 など、 いわば 技術 面 と 開発 管理 面 を 支える 役割 だ っ た。 しかし、 ここ で 一つ の 難 し さ に 直面 する。 支援 プロジェクト の 本当 の 難 し さ は、 「 どこ まで 前 に 出 てい い の か」 が 分 から ない こと だ。 前 の プロジェクト では、 前 に 出 た 実は、 その 前 の プロジェクト では 私 は 違う 立場 だ っ た。 当初 は 支援 に 近い ポジション だ っ た が、 途中 から 全面 的 に 前 に 出 た。 結果 として、 プロジェクト の 中核 メンバー となり、 最後 まで プロジェクト を やり遂げる こと が でき た。 だからこそ 思 って い た。 「 困 って いる なら、 前 に 出 れ ば いい」 しかし 今回 は 違 っ た。 部署 の 壁 という 見え ない 境界 線 この プロジェクト は 金融 システム 部隊 が リード し て いる。 そして、 大規模 システム 開発 部隊 に は 正式 な 依頼 が 来 て いる わけ では ない。 頼 まれ て いる の は、 あくまで「 開発 マネジメント リード の 支援」。 つまり 範囲 は 限定 さ れ て いる。 この 状態 で 支援 する の は、 想像 以上 に 難 しか っ た。 プロジェクト リード の 仕事 は、 開発 管理 だけ では ない 同期 は 多く の タスク を 抱え てい た。 各 ベンダー ...