Digital Heroes: Guide to IT World

ロンドンのシステムを追いかけて、見つけた「地図」 「うわっ、システム構成図って、こんなに面白いのか！」 そう思った瞬間のことを、今でも覚えている。 当時、私はロンドンで開発されたシステムを日本へ導入していくプロジェクトに参加していた。 私のメインタスクは、先方から渡される大量のドキュメントを、英語から日本語へ翻訳すること。 もちろん、単なる翻訳作業ではない。 システムのことも理解しながら翻訳する必要がある。 だから、英語のドキュメントを読み進めるほど、「最先端のシステムの中に入り込んでいく」ような感覚があった。 翻訳しているのに、金融ビジネスまで見えてくる 面白かったのは、システムドキュメントだけではなかった。 プロジェクトでは、ビジネスに関するドキュメントも非常に多かった。 そこで私は、システムだけではなく、金融ビジネスについても勉強するようになった。 日本の金融ビジネスについても調べた。 それまでに取得していたいくつかの資格の知識も、思いがけず役に立った。 「なるほど。この業務があるから、このシステムが必要なのか」 そうやって、業務とシステムが少しずつつながっていった。 翻訳しているはずなのに、気づけば金融の仕組みを勉強している。 そして、その金融ビジネスを支えるシステムの構造まで見えてくる。 これは、とても贅沢な勉強の時間だった。 コード、サーバ、そして増えていく役割 システムドキュメントを読み込んでいくと、コードもいくつか出てくる。 サーバ構成も書かれている。 最初は、 「こんなにサーバがあるのか？」 と思った。 でも、よく見てみると、それぞれ役割が違う。 ログを扱うサーバ。 バッチ処理を行うサーバ。 それぞれの機能を担当するサーバ。 そこで、ふと気づいた。 「なるほど。ものすごく高機能な一つのアプリケーションを作っているというより、少しずつ役割を持った多くのシステムを組み合わせているんだ」 一つひとつの役割を持ったシステムが集まり、大きなサービスを作っている。 そう考えると、システム全体が少しずつ理解できるようになっていった。 そして、A3一枚の「地図」に出会った そんな中で、私が一番目を見張ったのが「システム構成図」だった。 たくさんのシステムが存在している。 サーバもたくさんある。 それぞれが複雑につながっている。 それなのに、それらが A3一枚 に収...

ロンドン生まれのシステムを、日本の現場へつなぐ仕事 「おおっ、地下に行くほど、仕事が面白くなっていく！」 そんな不思議な感覚を持ちながら、私は毎日のようにお客様のビルの地下へ向かっていた。 当時、私はロンドンで開発されたシステムを日本に導入するプロジェクトに、日本側のシステム担当として参加していた。 すでにアプリケーションそのものは完成している。 つまり、ゼロからシステムを作るプロジェクトではない。 しかし、日本で使うとなれば話は別だった。 「完成している」のに、やることは山ほどある 日本側にはインフラチームが大勢集められていた。 さらに、周辺システムとのインターフェース変更など、日本側で追加開発しなければならないものも数多くあった。 私は、その中で少し変わった役割を担っていた。 システムそのものを理解し、それを日本側の関係者に説明する。 ところが、ロンドンから来たシステムの資料は当然ながら英語。 そこで、私が一生懸命取り組んでいたのが「翻訳」だった。 ただ、日本語に訳せばいいわけではない。 「この機能は何のためにあるのか」 「この処理は業務上、何を意味しているのか」 「日本側のシステムとは、どうつながるのか」 翻訳しながら、私は少しずつシステムそのものを理解していった。 私を支えてくれた、二人のスーパー担当者 このプロジェクトには、先方側の担当者が二人いた。 一人は、日本人なのに英語がペラペラ。 しかも、システムのことだけでなく、業務のことまで深く理解している。 まさに「スーパー日本人」だった。 もう一人はイギリス人。 彼も同じようにシステムと業務を理解していて、さらに日本語を勉強していた。 この二人に支えられながら、プロジェクトは少しずつ前へ進んでいった。 二人は基本的に日本にいた。 そして、プロジェクトの開発チームがいた場所が、お客様のビルの地下だった。 地上は「業務」、地下は「作戦」 お客様の業務関係者は上の階。 そして、システムを作り上げていくプロジェクトチームは地下。 なんとも不思議な構造だった。 二人は、ほぼ地下にこもっていた。 私も、翻訳をしたり、システムの説明を聞いたりする機会が増えるにつれて、次第に地下にいる時間が長くなっていった。 地下の部屋で、英語でシステムを勉強する。 分からない言葉があれば聞く。 業務の背景を教えてもらう。 そして、それを...

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