Digital Heroes: Guide to IT World

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

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

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

システムを入れるだけなら、仕様書なんて読めば終わり！……本当にそうでしょうか？      ロンドン出張から帰ってきた。 目的は、イギリスで使われているシステムを日本に導入することだった。 「イギリスのシステムなら、まず仕様書を読めばいい」 最初は、そんなふうに考えていた。 システム要件を理解して、機能を確認して、日本に実装する。 ところが、実際に要件を読み始めると、すぐに壁にぶつかった。 「これ、日本ではそのまま使えない……」 システムは、その国のビジネスを映している 理由はシンプルだった。 システムの前提になっているビジネスルールそのものが、日本とイギリスでは違う。 特に証券業界は、さまざまなルールが多段構造になっている。 まず金融庁や取引所がルールを決める。 そのルールを、大手の銀行や証券会社が自社の業務に落とし込む。 さらに中小の証券会社が、そのルールに対応する。 そして最終的には、顧客にまでルールが配分されていく。 つまり、システムだけを見ても全体像は分からない。 その背景にある「ビジネスの仕組み」を理解しなければ、システムを日本に持ってくることはできないのだ。 イギリスのルールを、日本のルールに翻訳する そこで重要になったのが、単純なシステム導入ではなかった。 イギリスから入ってきたビジネスルール。 それを日本の業務ルールに合わせていく。 そして、その日本の業務を支える形にシステムを実装していく。 つまり、 イギリスのBusiness → 日本のBusiness → 日本のSystem という変換が必要だった。 ロンドンに行ったからといって、システムの導入方法が分かるわけではない。 仕様書を読んだからといって、日本でどう使うかが分かるわけでもない。 そこで、ロンドンのシステムを日本に導入するための「橋渡し役」が必要になる。 そこで出会った、すごい人たち プロジェクト期間中、ロンドンから日本に滞在して支援する人がいた。 一方、日本側にも、英語ができて、システムも分かる人が雇われていた。 彼らの仕事は、単なるシステム担当ではない。 イギリス側の業務内容を理解する。 システムの構造を理解する。 日本側の業務を理解する。 そして、それぞれの違いを言語化して、両者をつなぐ。 英語も、日本語も、業務も、システムも分かる。 私は、その姿を見て...

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

世界の大企業は、意外と“同じ道具”で動いている グローバル企業にいると、ふとした瞬間に気づきます。 「あれ？またこのシステムか」 別の部署、別の国、別の業種なのに、使われているシステムがやけに似ているのです。 理由は明快。 世界で勝ち続けるには、共通言語＝共通システムが必要 だから。 では、実際にどんなシステムが使われているのでしょうか？ 押さえておきたい「グローバル標準」のシステムたち まず、ERPの王者 SAP 。 「使いにくい」「カスタマイズが大変」と言われつつも、財務・購買・物流を一手に支える存在。 もはや、これを外すグローバル企業は少数派です。 人事管理は Workday 。 柔軟なワークフロー設計とグローバル対応で、海外本社ではかなりの採用率。 問い合わせ・環境管理なら ServiceNow 、 CRMは圧倒的なシェアを誇る Salesforce 、 アプリケーション全体の見える化では LeanIX 、 フィールドサービスの管理には ServiceMax ――。 これらが業務の「骨格」として、世界中のグローバル企業で共通して使われています。 世界とつながるには、世界の道具を使いこなせ こうしたグローバルシステムは、ローカル企業との連携時にも力を発揮します。 新しく買収した現地法人が独自システムを使っている場合、徐々にグローバル標準へ統一していく。 契約・セキュリティ・データ連携――そのすべてが「共通化」されることに意味があるのです。 ただし！ この“統一プロジェクト”はそう簡単ではありません。 バイリンガルPM、専門スキルを持った開発者、国ごとの法制度の違い… **そして何より重要なのは、「現場の納得」**です。 変革のカギは、システムではなく“人の想い” どんなに優れた仕組みでも、使う側に熱量がなければ宝の持ち腐れです。 グローバルと連携して勝負したいのか、 世界の中で新しい価値を生み出したいのか。 その想いがあるなら、共通システムは確実に武器になります。 DXの成功とは、ツールを導入することではなく、 ビジネスとITが一体となって「変わることを選ぶ」こと。 境界線なんて必要ありません。手を取り合って前へ進むだけです。 アンケートでおこづかい稼ぎ     明日...

ベンダー？コンサル？担当者？…その前に必要な視点とは 1. 驚きから始まる、システム検討のリアル 「えーっ⁉システムの検討って、そんな風に始まるの!?」 そんな驚きから始まった、ある企業でのシステム導入プロジェクト。 意外と多いのが、「最初に誰が検討するのか」がフワッとしているケース。 2. 実は誰でもできる、システム検討 でもね、実は―― システムの検討って、誰でもできる んです。 業務の中で「これ不便だな」「こんなのあれば楽になるのに」と思う瞬間、 それこそが、検討の“はじまり”。 3. 情報収集は日常の中にある 最近の現場では、情報収集がとにかく簡単。 気になる機能をネットで検索したり、展示会やイベントで話を聞いたり。 そんな日常の中に、 システム企画のヒント がゴロゴロ転がっています。 4. コンサルとベンダー、それぞれの役割 「これを導入すればみんな助かるかも！」 そう思ったあなたが、次に動くのは コンサルやベンダーとの対話 です。 コンサル：全体設計・プロジェクト進行を支援 ベンダー：便利な機能や製品を具体的に提案 このやりとりの中で、夢が少しずつカタチになっていきます。 5. パッケージ製品との出会い 特に、展示会やセミナーで出会う パッケージベンダー は、強い味方。 既に業界のニーズを取り込んだ製品が用意されていて、 「この機能、まさに求めてた！」と驚くことも。 そこから価格交渉 → 社内IT部門との調整へと進みます。 6. 個別最適の落とし穴 ついに、 課題解決のシステムが見えてくる ！ …でもちょっと待って！ そのシステム、他部門との連携は？ 業務全体を見渡せてる？ 個別最適 に陥っていないか、見直しが必要です。 7. 全体を見渡す「つなぎ役」が必要 コンサルもベンダーも、それぞれの領域で最適を目指してくれる。 でも、「全体」を俯瞰して、歴史も未来も含めて調整できる人は少ない。 だから今必要なのは、 システムトータルコーディネーター ！ アンケートでおこづかい稼ぎ     8. まとめ：一歩を踏み出そう 「これでいいのかな」と悩んでいるあなたへ。 システムをつなぎ、未来を支える役割 が、今こそ求められています。 さあ、誰が始めてもいい。 でも、 誰かがつないでいかなくちゃ。 明日からの一歩、私ならできる！ あなたも、踏み出してみ...