Digital Heroes: Guide to IT World

えっ、システムって一つ完成させれば終わりじゃないの？ 以前、私はロンドンから金融システムを導入するプロジェクトに関わっていました。 当時の私は、まず「メインとなる金融システムを日本でどう動かすか」を考えていました。 海外から導入するシステムですから、当然、日本の業務に合わせた調整が必要です。 ただ、基本的な考え方はシンプルでした。 メインシステムは、できるだけ設定で変更する。 どうしても設定では対応できない部分だけ開発する。 そして、その開発については日本で全部作るのではなく、基本的にはロンドン側へ依頼する。そこから必要な開発が、しかるべき場所で行われていく。 「これなら、なんとか進められそうだ」 そう思ったのを覚えています。 ところが、次に待っていたのが「周辺システム」でした。 メインシステムが来ると、周りも変わる 新しい金融システムが入る。 すると、当然ながら、そのシステムとつながっている周辺システムも変えなければなりません。 データ項目が変わる。 インターフェースが変わる。 送信する形式が変わる。 受け取る側も、それに合わせて改修する。 一つずつ確認し、一つずつ接続していく。 すると、少しずつ社内システム全体の姿が見えてきました。 「よし。社内はなんとか目途が立ってきた」 そう思った瞬間、次の課題が出てきました。 今度は、 別の会社のシステムです。 金融システムは「会社の中」だけでは完成しない 金融の世界では、一つの会社のシステムだけですべての業務を完結できません。 注文が入る。 確認する。 承認する。 支払う。 記帳する。 そして、その情報を別のシステムや企業へ連携する。 つまり、一つの取引を成立させるために、多くの企業、多くのシステムがつながっています。 ここで重要になるのが、「どうつなぐか」です。 どのプロキシーを使うのか。 どのデータフォーマットで送るのか。 どのくらいの頻度で送信するのか。 システムはこちらから接続しに行くのか。 それとも相手に接続してもらうのか。 さらに、接続に料金は発生するのか。 こうしたことを一つずつ決め、相手企業に通知しなければなりません。 そして、通知して終わりではありません。 「この項目は何ですか？」 「この形式には対応できますか？」 「テスト環境はどうしますか？」 次々と質問が来ます。 それに回答しながら、今度は接続テス...

「すみません。これ、いつ直りますか？」 その質問を受けるたびに、私は答えに困っていました。 なぜなら、私自身も分からなかったからです。 開発会社に聞いても、 「確認します」 「担当に確認中です」 「もう少しお時間ください」 そんな回答ばかり。 でも、社内からは毎日のように聞かれます。 「進んでますか？」 「いつリリースできますか？」 「この問題、まだ直らないんですか？」 私はDX担当者。 プロジェクトの責任者です。 でも、自分でプログラムを書いて直すことはできない。 だから、開発会社に頼るしかありません。 そして、その開発会社が動いてくれない。 これが、私が外注開発で経験した、かなり苦しい時期でした。 ▼開発会社選びに悩んでいる方はこちら   最初は、こんなことになるとは思っていなかった もちろん、最初から怪しい会社を選んだつもりはありません。 提案書はきれいでした。 営業担当者も優秀でした。 「この領域は経験があります」 「お客様の要望に柔軟に対応できます」 「経験豊富なエンジニアをアサインします」 こちらも安心します。 「これなら大丈夫だろう」 そう思って契約する。 ところが、プロジェクトが始まってみると、少しずつ違和感が出てきました。 「それ、営業から聞いてません」 最初に出てきたのが、これでした。 こちらが契約前の打ち合わせで話した内容について確認すると、 「その件は聞いていません」 と言われる。 「いや、営業の方と話しているんですが……」 「営業と現場で認識が違うかもしれません」 ……。 この瞬間、本当に嫌な予感がします。 その後、 「それは追加開発です」 「そこまでの対応は含まれていません」 「仕様変更になります」 という話が増えていきました。 契約前には、 「できます」 と言っていたことが、 契約後には、 「条件によります」 に変わっていく。 そして最終的には、 「それは難しいです」 になる。 この変化を何度経験したか分かりません。 そして、問題が起きる システム開発で一番怖いのは、問題が起きることではありません。 問題が起きたときに、 誰も責任を持って前に進めてくれないこと です。 ある時、システムで問題が発生しました。 当然、私は開発会社に連絡します。 「原因を調べてください」 「いつまでに対応できますか？」 すると、 「まず調査します」 ...

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

当時、私はある金融システムの導入プロジェクトに関わっていました。 そのシステムのメイン開発拠点は、なんとロンドン。 「ロンドンで作られているシステムを、日本に持ってきて使う」 今ならオンライン会議やチャットで、世界中のメンバーと簡単につながります。でも、当時は今ほどオンライン会議が当たり前ではありませんでした。 では、一体どうやってプロジェクトを進めたのでしょうか。 日本側の窓口は、たった2人 日本からシステムについて質問したい場合、直接ロンドンの開発者に聞くわけではありません。 まず、日本側にいる2人の担当者に問い合わせます。 「この機能はどういう仕様ですか？」 「このデータは、どういう条件で処理されますか？」 「このエラーは何が原因ですか？」 質問は一覧表に書いていきます。 すると、日本側の担当者が内容を確認し、答えられるものは、その場で回答してくれます。 しかし、当然ながら、すべてを知っているわけではありません。 そこで登場するのがロンドンです。 分からなければ、ロンドンに聞く 日本側の担当者でも分からない。 そんな質問は、ロンドンのチームへ問い合わせます。 「この仕様について確認してください」 「この動きは想定されたものですか？」 そして、しばらくするとロンドンから回答が返ってきます。 その回答を日本側の担当者が整理し、最初に質問した人へ返していく。 今振り返ると、とてもシンプルな仕組みです。 質問する人 → 日本側の担当者 → ロンドン → 日本側の担当者 → 質問した人 まさに、人を介したグローバル開発でした。 そして、時々ロンドンから人がやってくる もちろん、メールや電話だけですべてが解決するわけではありません。 重要な局面になると、ロンドンから何人かが日本へ出張してきます。 直接顔を合わせて、仕様を確認する。 画面を見ながら議論する。 日本側の業務を理解してもらう。 そして、基本的には日本のことは日本側で対応しながら、必要なところだけロンドンの力を借りていく。 なお、ロンドンのシステムが、さらにインドやポーランドなど別の拠点へ発注されていた可能性もあります。そこは当時の私には分かりません。 でも、重要なのは「どこで誰が作っているか」だけではありません。 どうやって世界中の知識をつなぎ、日本で使える形にするか。 そこだったのです。 グローバル開発は、場...

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

グローバルシステムプロジェクトで知った、「システム通訳」というもう一つの専門性 「えっ、システムのことを英語で話せるのに、通訳はできないの？」 グローバルプロジェクトにシステム担当として入っていた頃、私は何度もこの壁にぶつかった。 私は、それまでシステムのことを勉強してきた。 グローバルプロジェクトにも入り、システムについて議論する。英語も、それなりにはできた。当時のTOEICは790点。 だから、当然こう思う。 「システムのことを英語で話せる。だったら、通訳もできるだろう」 ところが、実際にやってみると……。 いや、これはきつい。 「話せる」と「通訳できる」は違う 自分の考えを英語で話す。 これは、なんとかなる。 相手の話している内容も、7割、8割くらいなら追いついていける。 システムの話なら、専門用語そのものが英語になっていることも多い。 System Architecture、Application、Database、Interface、Integration、Cloud…… むしろ、システム用語が共通言語になっているので、普通にコミュニケーションできる。 システム議論も、なんとかできる。 「じゃあ、通訳をお願いします」 そう言われる。 ここからが別世界だった。 通訳は「自分が話す」のとは違う まず、日本人が話している内容を理解しなければならない。 その内容を頭の中で整理する。 そして英語にする。 次に、相手が英語で話す。 それを理解する。 そして、日本語に戻す。 つまり、自分の意見を話すときとは違って、 二人分の思考を処理しなければならない。 しかも、自分が話している時間が長くなる。 すると、すぐにプレッシャーがかかる。 「早く訳してください」 いやいやいや。 結構むずいよ、これ。 専門知識があるからといって、全部を一瞬で理解できるわけではない。 「今のところ、もう一度お願いします」 そう聞き返す。 すると、またプレッシャーがかかる。 「これを同時通訳している人がいるの？」 正直、最初はそう思った。 「いや、無理だよ。意味を理解している暇なんてないじゃないか」 それでも、何度もやる。 聞いて、理解して、整理して、訳す。 そして、また聞く。 その苦しさが、英語を鍛えていった 不思議なのは、そんな経験を繰り返しているうちに、少しずつ英語が鍛えられていったことだ。...

システムを作る側から、システムを「つなぐ側」へ 「えっ、今回はアプリを作らないの？」 今回のシステム開発プロジェクトが始まったとき、少し意外な展開になった。 実は、今回のシステム開発では、自分の部署はそれほど出番がなかった。 というのも、今回導入するシステムは、すでに完成している。ゼロからアプリケーションを開発するのではなく、完成したシステムを日本のビジネス環境に合わせて導入していくプロジェクトだった。 もちろん、話はそんなに簡単ではない。 新しいシステムが突然やってくれば、それまで使っていた周辺システムとの間に「Interface」という問題が発生する。 当然、各周辺システムには改修が必要になる。 「システムは完成しています」 そう言われても、周りのシステムからすれば、 「いやいや、急に新しいものが来たんですけど……」 という話だ。 こうして、Interfaceに四苦八苦するプロジェクトが始まった。 「作る」より「理解する」が仕事になった その周辺システムを作っているのが、私の部署だ。 最初は、今回のシステム導入でも、当然アプリケーション構築が必要になると想定していた。 ところが、システムを理解していくと、少しずつ見え方が変わってきた。 そのシステムは、想像以上に柔軟だった。 Config、つまり設定によって、多彩な調整ができる。 つまり、プログラムそのものを書き換えなくても、多くの要求に対応できる仕様になっていた。 さらに、今回はビジネス側も新しいシステムに合わせて業務を作り込んでいく。 そのため、「日本のビジネスに合わせてシステムを大幅改修する」という場面も、当初想定していたほど多くはなかった。 では、大規模アプリケーション製造部隊にいる自分に、何ができるのか。 そこで役立ったのが、これまで身につけてきた「英語」と「システム」の両方だった。 フルスタックを超える人には、まだかなわない もちろん、世の中には、システムを深く理解し、設計し、実装し、英語でコミュニケーションまで完結できる「フルスタックを超える」ようなメンバーがいる。 正直、そこにはまだかなわない。 でも、自分にはできることがある。 システムの仕様を理解しながら、英語のドキュメントを読み込む。 技術的な意味を理解する。 そして、それを日本のメンバーが理解できる形に翻訳する。 気がつけば、今回の主な作業...

「えっ、この人、何者なんだ？」 今回、あるイギリスのシステムを日本に適用するプロジェクトに参加しました。 日本側の中心メンバーは2人。 一人は、英語がペラペラの日本人エンジニア。 もう一人は、日本語が少しできるイギリス人エンジニアです。 最初は「技術面でサポートしてくれる人」というくらいに思っていました。 ところが、話をしているうちに、だんだん違和感が出てきました。 日本のビジネス専門家が、その人に直接問い合わせる。 システム担当者が質問すると、「では、このスクリプトを実行しましょう」と、その場で対応する。 さらに、データベースの構造を説明し、ネットワークについても教えてくれる。 「なんなんだ、この人は？」 システムだけではありません。 ビジネスのことも分かる。 英語も分かる。 日本側の事情も分かる。 データベースもネットワークも分かる。 しかも、年収を聞けば1,000万円を超えてくる。 これは確かに、フルスタックを超えている。 でも、本人の言葉は意外だった 「すごいですね。何でもできますね」 そう話しかけると、彼は少し笑って答えました。 「いや、何でも屋なんで。結構つらいですよ」 その言葉が、妙に印象に残りました。 実際、その仕事は簡単ではありません。 突然、イギリスから指示が飛んでくる。 「日本のシステムを、この仕様に変更してください」 ところが、ビジネス側から質問を受けてイギリスに投げても、すぐには答えが返ってこない。 当然です。 日本とイギリスには時差があります。 日本の夕方になると、イギリス側との仕事が本格的に始まる。 夕方から夜まで会議。 そして、日本側では朝から別の会議。 さらに、単純な通訳だけでは終わりません。 ビジネスの意図を理解し、それをシステムの言葉に変換する。 イギリス側の技術的な説明を、日本の現場が理解できる形に戻す。 必要なら自分で検討し、スクリプトを実行し、データベースやネットワークまで確認する。 「システム、ビジネス、検討、実践、通訳。何でも屋ですよ」 そう吐露してくれました。 「何でもできる」は、実は大変だ その姿を見て、私は思いました。 できる人ほど、仕事の境界線を越えてしまう。 「私はシステム担当なので、そこは分かりません」 そう言えば、仕事は楽になるかもしれません。 でも、目の前の問題を解決しようとすると、そうはいかない。 ビ...

うわっ、年収の数字に心を奪われた瞬間、私のエンジニア人生の見え方が変わった。 憧れだった「フルスタック」 エンジニアの世界には、前に出て目立つ人だけではなく、地道にシステムを作り続けている人がたくさんいる。 そして、エンジニアは勉強熱心な人が多い。 私もそうだった。 サーバー、ネットワーク、アプリケーション。 それぞれの専門領域を理解し、さらに全体を見渡して、必要な人に指示を出せる。 プロジェクト開発の全体像を理解し、システムを動かせる。 そんな人は「フルスタックエンジニア」と呼ばれ、エンジニアの中でも目標の的になる存在だった。 実際、IPAの難しい試験を受けに行くと、一日がかりの試験会場に、何人ものエンジニアが集まっている。 「この人たちも、いつかフルスタックを目指しているんだろうな」 そんな空気を感じていた。 私にとって、フルスタックは憧れだった。 ところが、フルスタックの「さらに先」がいた あるとき、ロンドンのシステムを日本へ導入するプロジェクトに関わった。 そこでシステムをサポートしていたのが、イギリス人と日本人のコンビだった。 イギリス人のエンジニアは、システムをよく理解していた。 技術の話をすると、構造をすぐに理解する。 「やっぱり外国人はシステムに強いんだな」 私は、自然にそう思っていた。 でも、ある時ふと気づいた。 「いや、このイギリス人と対等に話している、この日本人は何者なんだ？」 その日本人は、日本で一人だけ採用された、英語も日本語も話せるエンジニアだった。 英語でシステムを議論し、日本語でも議論する。 技術だけではない。 ビジネスの話まで理解し、調整し、そして自分で実装までこなしている。 システム、ビジネス、言語。 そのすべてをつないでいた。 私は、すぐにその人に憧れた。 「日本人でも、ここまでいけるんだ」 後になって分かった。 私が「外国人の方がシステムに強い」と感じていたのは、外国人バイアスだった。 本当にすごかったのは、そのイギリス人と対等に渡り合い、さらに日本側のビジネスまで動かしていた日本人だった。 そして、年収の話になった ある日、その人が年収の話をしていた。 私は、それなりに自分の年収に自信があった。 日本有数の大手SIerで働くエンジニア。 社内でも難しい金融システムの開発をリードしている。 年収は700万円。 年齢を考えれば、...

システム屋と業務担当、その境界はどこへ行ったのか 社会人8年目、ロンドンで感じた小さな危機感 うわっ！お客様との会話が、まるでシステム設計レビューになっていた！ 社会人8年目。 もう9年目が見え始めていた頃の話だ。 私はシステム屋として、アプリケーション構築に携わってきた。 お客様の要件を聞き、設計し、開発し、導入する。 システムのプロとしてサービスを提供する立場だった。 そんなある日、日本のお客様がロンドンの企業からパッケージシステムを購入した。 その導入プロジェクトに参加することになり、私はシステム研修のためロンドンへ向かった。 研修期間は2週間。 場所はウォータールー周辺。 ロンドンの金融機関や大手企業が集まるエリアだった。 当時の私は、新しいシステムを学ぶことばかり考えていた。 しかし、本当に学んだのはシステムそのものではなかった。 業界構造の変化だった。 ■ お客様との会話に違和感を覚えた 研修やプロジェクトの打ち合わせが始まった。 私はシステムベンダー側として説明を行う。 アーキテクチャ。 データ構造。 運用設計。 インターフェース。 するとお客様から質問が飛んでくる。 しかも、その質問が妙に鋭い。 「その設計だと将来的な拡張性はどうなりますか？」 「データ移行時の整合性はどう担保しますか？」 「パフォーマンス試験はどの条件を想定していますか？」 あれ？ なんかおかしい。 業務要件の質問ではない。 システム屋がする質問だ。 私は少し戸惑った。 ■ なぜお客様がこんなに詳しいのか しばらくして理由が分かった。 実はお客様側の担当者の多くが元システム屋だったのである。 SIer出身。 開発会社出身。 インフラ出身。 転職して事業会社へ移った人たちだった。 つまり、 業務担当者でありながら、 システムのプロでもあった。 私は衝撃を受けた。 それまで私の中には、 お客様＝業務担当 ベンダー＝システム担当 という構図があった。 しかし現実は違った。 境界線がなくなり始めていたのである。 ■ システム屋の価値はどこにあるのか そこで考え始めた。 私たちシステム屋は何を武器にすれば良いのだろうか。 アプリケーションの専門家として技術を磨くべきか。 しかしサーバ担当もいる。 ネットワーク担当もいる。 データベース担当もいる。 インフラ領域は専門ベンダーが支えている。 で...

 DX担当者として何度も外注に苦しんだ私が、本当に大切だと思うこと うわっ！また今日も“言い訳レビュー会議”か――。 システム開発の責任者をしていた頃、私はある意味で毎日戦っていました。 戦う相手はシステムの不具合ではありません。 開発会社の「言い訳」です。 「この会社なら大丈夫」そう思っていた もちろん、世の中には素晴らしい開発会社もたくさんあります。 しかし、残念ながらそうではない会社に当たってしまうこともあります。 最初は営業担当者の説明に感動しました。 柔軟に対応できます 経験豊富なエンジニアがいます お客様に寄り添います プレゼンも上手い。 資料も立派。 実績も申し分ない。 私は「この会社なら大丈夫だろう」と思っていました。 営業と現場が別の会社だった ところが契約後、実務担当者との打ち合わせが始まると違和感を覚えました。 営業担当者が話していた内容と、現場が理解している内容がまるで違うのです。 「そんな話は聞いていません」 「それは追加費用になります」 「対応は難しいです」 営業担当者と実務担当者の間に大きな乖離がありました。 契約前は何でもできるように見えた会社が、契約後には何もできないように見えてしまう。 これは非常につらい経験でした。 口は上手い。でも動けない さらに困ったのは、説明だけは上手い会社です。 会議では立派なことを言います。 しかし実際に問題が発生すると、 契約上は対象外です 前例がありません 社内ルールでできません という回答ばかり。 こちらは問題解決を求めているのに、返ってくるのはできない理由ばかり。 会議のたびに期待し、会議のたびに落胆する。 そんな状況が続きました。 リーダーは優秀。でもチームがついてこない また別の会社では、リーダーだけが非常に優秀でした。 話をすると安心できます。 理解も早い。 提案も的確です。 ところが実際に手を動かすメンバーへ話が伝わっていない。 同じ説明を何度も繰り返し、 同じ課題が何度も再発する。 気付けば、プロジェクトの大半が情報伝達に費やされていました。 ▼開発会社選びに悩んでいる方はこちら   一番苦しかったのは「手が動かない」こと 会議は開かれる。 議事録も出る。 課題管理表も更新される。 しかし成果物が出てこない。 前に進まない。 検討はする。 相談もする。 説明もする。 ...

システムは完成品ではない。育てるものだ。 Configurationが変えた私のシステム観 うわっ！システムがプログラムを書かずに姿を変え始めた！ ■ システム構築には自信があった システム開発に携わってきて、気が付けばプロジェクトをコントロールする立場になって8年が経っていた。 若い頃はJavaを中心としたシステム開発に関わり、設計から開発、テスト、運用まで一通り経験してきた。 正直に言えば、システム構築にはそこそこ自信がついていた。 要件を聞く。 設計する。 開発する。 テストする。 リリースする。 そんな流れが当たり前だと思っていた。 ところが、その考え方を大きく揺さぶられる経験をした。 海外製パッケージシステムの導入プロジェクトだった。 ■ ロンドンで学んだ新しいシステム思想 お客様のシステムを構築するため、私はロンドンで2週間の研修を受けることになった。 そこで学んだのは単なる製品知識ではない。 システム構造そのものの考え方だった。 当時の私は、「お客様の要件はプログラムで実現するもの」だと思っていた。 もちろん設定は使う。 OSの設定。 サーバ設定。 ログの保存期間。 メモリ割り当て。 ジョブスケジュール。 プログラムを最適に動かし、運用しやすくするためのConfigurationである。 つまり、Configurationはシステムを支える裏方だった。 ■ Configurationの役割がまったく違った しかし、そのパッケージは違った。 驚くほど多くのConfigurationが存在していたのである。 しかも目的が違う。 システムを動かすためではない。 顧客ごとにシステムを変えるために存在していた。 承認フロー。 画面項目。 入力ルール。 通知条件。 業務プロセス。 顧客ごとの個別要件をConfigurationで吸収していた。 最初は驚いた。 「こんなことまで設定でできるのか？」 「これ、本当にプログラムを書かなくていいのか？」 研修中、何度もそんな疑問を持った。 ■ システムは完成品ではなく成長するもの だが次第に理解していった。 このシステムは完成品ではない。 成長することを前提に設計されているのだ。 運用しながら改善する。 顧客から新しい要望が出る。 すぐに開発しない。 まずConfigurationで吸収する。 それでも足りなければ次のリリ...

あっ！システムがまるで家庭菜園のように扱われていた！ 私はシステム屋として約8年間、多くのシステム開発に携わってきました。 バッチシステム、Webシステム、メール連携システム。 ベンダーとして様々な案件に関わり、ある程度の規模のシステムであれば一通り経験してきたと思います。 お客様から要望を受ける。 影響調査を行う。 修正計画を立てる。 開発する。 テストする。 リリースする。 そんな流れを何度も繰り返してきました。 私が所属していたのはアプリケーション開発部隊です。 そのため、依頼される内容も比較的大きな改修が中心でした。 小さな変更はほとんど来ません。 結果として、一つひとつの案件がシステム開発プロジェクトになります。 3カ月。 半年。 場合によってはそれ以上。 システムを「作る」という感覚はあっても、「育てる」という感覚はありませんでした。 ■ロンドンで出会ったシステムのオーナーたち そんな私がロンドンであるシステムの説明を受けたときのことです。 説明してくれたのは開発ベンダーではありません。 システムのオーナーメンバー。 おそらくシステムを発注している側の人たちです。 彼らは驚くほど自然にシステムを説明していきました。 機能説明をしながらジョークを挟む。 参加者を笑わせる。 議論を楽しむ。 どこか余裕がある。 正直に言うと、私はそんな会議に少し憧れていました。 システムを熟知しながらも、肩肘張らずに語れる姿です。 ■日本との違いはどこにあったのか 説明が進む中で、日本側から質問が飛びます。 「こんな機能はないのですか？」 「あんな機能も欲しいですね。」 すると彼らは否定しません。 難しい顔もしません。 メモを取りながらこう答えます。 「それは次のリリースに入ります。」 「それはロードマップに追加していきます。」 私はこのやり取りに衝撃を受けました。 なぜなら、日本ではよくこうなるからです。 「その変更は別案件です。」 「見積もりを作ります。」 「来年度予算で検討します。」 もちろん、それも必要です。 しかし、彼らの会話にはもっと長い時間軸がありました。 今できるかどうかではない。 このシステムをどう成長させるか。 その視点で会話していたのです。 ■システムを育てるという発想 彼らはシステムを完成品として見ていませんでした。 リリースはゴールではありません。 ...

あっ！自信満々で海を渡ったエンジニアが、システムの前で迷子になった。 入社8年目。 私はお客様が導入した金融システムの研修のため、ロンドンへ向かっていた。 サーバ担当、ネットワーク担当、オペレーション担当も一緒だ。 そしてアプリ担当は私一人。 しかも担当するのは単なる業務アプリではない。 金融システム全体。 数多くの機能が連携し、複数のシステムが複雑に接続される巨大なシステムだ。 私はかなり意気込んでいた。 これまで数々のシステムを構築してきた。 Javaによる3層構造。 Webシステム。 データベース設計。 インターフェース設計。 お客様向けシステムの開発。 アプリケーション開発には自信があった。 「このシステム全体を理解し、将来的には開発や運用もサポートする。」 そんな使命感を持ってロンドンへ向かった。 ■ 最初の違和感 研修初日。 講師が説明を始める。 しかし、何かがおかしい。 言っていることが頭に入ってこない。 英語の問題ではなかった。 むしろシステム用語ばかりだ。 知っている単語のはずなのに意味がつながらない。 サーバ担当は理解している。 ネットワーク担当も理解している。 オペレーション担当も質問している。 なのに私だけが取り残されていた。 なぜだろう。 ■ システムを理解していたつもりだった その答えに気づくまで時間がかかった。 私はずっと「アプリケーションの中」を見ていた。 画面があり、 業務ロジックがあり、 データベースがある。 いわゆるJava中心の3層構造だ。 しかしロンドンで説明されていたのは、そのさらに外側だった。 システムとシステムはどうつながるのか。 相手システムをどう認識するのか。 通信経路はどう設計されるのか。 障害が起きたらどこで切り分けるのか。 認証はどう行うのか。 通信先の設定はどこで持つのか。 ロードバランサーはどう動くのか。 ネットワークを越えた先にあるシステムとどう連携するのか。 私はシステム間のデータ連携設計は経験していた。 CSV連携もAPI連携も設計してきた。 だが今振り返ると、それは「つながっている前提」で設計していただけだった。 そもそもどうやってつながるのか。 なぜつながるのか。 どの設定がその接続を支えているのか。 そこへの理解が圧倒的に不足していた。 ■ 焦り続けたロンドンの日々 研修は進む。 しかし理解が...

「完成」がゴールだと思っていた うわっ！金融システムが“生き物”みたいに成長していた。 私はこれまで、約8年間システム作りに関わってきた。 設計し、開発し、テストし、納品する。 そういう世界で仕事をしてきた。 もちろん、その中で改善提案もしてきた。 しかし、どこかで「システムは作って終わり」という感覚があった。 そんな中、あるプロジェクトに参加することになった。 お客様が、ロンドンから金融系システムを日本へ持ってくるプロジェクトだった。 ロンドンで見た“異様な光景” 私はアプリケーション観点でシステムを理解する担当として、2週間ロンドン研修に参加した。 そこで見たものが衝撃だった。 そのシステムを所有していたのは、システムベンダーではない。 ロンドンの金融会社だった。 つまり、金融会社自身が金融基幹システムを作り、それを自社資産として海外へ販売していたのである。 しかも、それを買ったのは日本の金融会社。 私は驚いた。 日本では、 「金融会社が使うシステムをITベンダーが作る」 という構造が当たり前だった。 しかしロンドンでは違った。 「金融会社が、自分たちで磨き上げたシステムを商品として売る」 なのである。 しかも、国内マーケットだけではない。 海外の金融機関へ販売していた。 システムそのものが、国境を越えるビジネスになっていた。 運用担当者が9画面を操っていた さらに驚いたのは運用現場だった。 運用担当者は、9つのスクリーンを同時に使いこなしていた。 こちらが、 「こういう機能はあるんですか？」 と聞く。 すると返ってきたのは、 「それは現在開発中だ」 という言葉だった。 私はそこで初めて気づいた。 この人たちは、“完成品”を運用しているのではない。 “成長途中のシステム”を運用しているのだ。 そして、現場の知見をもとに、継続的に改善し続けていた。 最初から完璧を目指していた自分 一方、当時の私は違った。 最初の開発で、完璧なシステムを作ろうとしていた。 でも実際には、 要件は曖昧なことも多い。 お客様自身も、 「本当に欲しいもの」 を言語化できていないこともある。 そして何より、自分自身の知識もまだ中途半端だった。 しかし不思議なことに、システムを作り終える頃には、かな...

“エコノミーじゃない”だけで感動していた うわっ！空の上にも“会社の階級”って存在するのか——そう思った。 入社8年目。 私はロンドンへ向かう飛行機に乗っていた。 理由は、お客様がロンドンで動いている金融システムを導入するための研修。 当時の自分にとって、“海外金融システム”という言葉だけで別世界だった。 しかもロンドン。 映画でしか見たことのない場所。 そして、さらに驚いたのは飛行機だった。 プレミアムエコノミーですら「すごい世界」 日立のメンバーはプレミアムエコノミー。 正直に言う。 その時の私は、それだけで十分感動していた。 「え？席広い！」 「足伸ばせる！」 「毛布違う！」 そもそも“エコノミー以外”なんて知らない。 飛行機にランクがあることすら、現実感がなかった。 だから、ビジネスクラスなんて、ほとんど異世界だった。 ラウンジって何？ 空港で、お客様側メンバーが別方向へ歩いていく。 「ラウンジ使うので」 ラウンジ？ 何それ？ しかも、お客様はビジネスクラス。 別ルート。 別搭乗。 別空間。 同じプロジェクト。 同じロンドン。 でも、移動の世界が違う。 その時、少しだけ頭によぎった。 「あれ？やっぱりベンダーだから？」 “技術側”なのに、なぜ立場が違う？ その出張には、40代のシステムサーバ担当も参加していた。 金融機関システムを長年支えてきたベテラン。 経験値だけなら、先方の部長クラスに近い。 障害対応。 深夜対応。 性能改善。 運用保守。 現場を知り尽くした人だった。 でも、その人も私と同じプレミアムエコノミー。 そこで、なんとも言えない感情が生まれた。 「飛行機のランクって、個人じゃなくて“企業”で決まるんだ」 モノづくりって、もっと強いと思っていた 私は昔から、システムを作れる人は格好いいと思っていた。 巨大システムを動かす。 社会インフラを支える。 金融を止めない。 そんな技術者に、強い憧れがあった。 だから、どこかで思っていた。 “作れる側”は強い、と。 でも現実は少し違った。 お客様側の方が、立場が上に見える。 待遇も違う。 移動も違う。 給料も、たぶん違う。 もちろん、それは契約構造や責任範囲の違いでもある。 発注側と受託側で...

“システムを作れる”と思っていた うわっ！飛行機の羽が、やけに軽く見えた。 羽田空港からロンドンへ向かうANA便。 人生初の「海外システム研修」が始まろうとしていた。 入社8年目。 それなりにシステム開発の経験も積み、既に社会で動いているシステムにも関わってきた。 しかも、ただの開発担当ではない。 マネジメント側として、プロジェクト全体を見ながら進める立場にもなっていた。 「システムはこう作るものだ」 そんな感覚も、少しずつ持ち始めていた時期だった。 もちろん、私はJavaのプロフェッショナルではない。 コードを極めるタイプではなく、どちらかと言えば“全体構造”や“業務とITの接続”で戦うタイプ。 自分の戦う領域も、少しずつ理解し始めていた。 だから今回のロンドン出張も、ある意味では「確認作業」だと思っていた。 アプリケーション観点でシステムを評価し、理解し、日本側に持ち帰る。 やるべきことは分かっている。 ……そう思っていた。 “海外システム”は、空気そのものが違った 事前に送られてきたドキュメントも読んでいた。 英語自体は、なんとか理解できる。 技術用語も、そこまで問題ではない。 でも、違和感があった。 自分たちが日本で作ってきたシステムマニュアルと、雰囲気が違う。 日本の資料は、「開発した人」が説明している感じが強い。 一方で、ロンドン側の資料は、“製品”として整理されていた。 どちらかと言えば、パッケージソフトの説明書に近い。 「誰が作ったか」ではなく、 「どう使うか」が中心。 この時点で、私はまだ本当の意味を理解していなかった。 プレミアムエコノミーで感じた“境界線” お客様は別便だった。 私たちはANAのプレミアムエコノミー。 私はその時まで、「エコノミーにプレミアムなんてあるのか」と本気で思っていた。 少し広い座席。 少し前方の席。 それだけなのに、不思議と気持ちが高揚する。 「ああ、自分は今、国際案件に向かっているんだ」 そんな感覚があった。 海外旅行自体は慣れていた。 でも、観光ではない。 “ビジネストリップ”には独特の緊張感がある。 空港ラウンジ。 英語のアナウンス。 ノートPCを開く周囲のビジネスマン。 その空気の中で、自分も“グローバルIT”の入口に立って...

うわっ…人生って、“逃げていた場所”から未来が始まることがある。 入社して8年目。 私は、ある意味で“平穏”なエンジニア人生を送っていた。 いや、正確には違う。 ずっと避け続けていたものがあった。 それが—— パワハラ営業だ。 怒鳴る。詰める。無茶を言う。 現場を振り回し、空気を凍らせる。 そんな人物だった。 だから私は、できるだけ距離を取っていた。 だが、ある日。 突然、その営業案件への参加を命じられる。 「英語できる人、他にいないから」 ……え？ ■ “英語ができるシステム屋”は、実は少ない その時、私は開発部隊の中で唯一の参加者だった。 しかも、アプリチームからも一人だけ。 理由は単純。 「英語が多少読めるから」。 これ、IT業界では意外と議論になる話だ。 システムは作れる。 コードも書ける。 だが、“英語で運営される世界”に入れる人材は極端に少ない。 しかも今回の案件は、普通ではなかった。 新しい金融サービスを、日本で立ち上げる。 だが、そのサービス自体が日本に存在しない。 つまり—— 業務そのものを海外から輸入する。 システムも。 運用も。 考え方も。 全部だ。 ■ ロンドンの金融システム、日本上陸 導入されるのは、ロンドンを中心に使われる世界的金融システム。 当然、ドキュメントは全部英語。 仕様書。 設計書。 運用手順。 会議資料。 全部、英語。 しかも、金融知識まで必要になる。 私は、その頃まだ金融システムの知識は未熟だった。 だが、システムそのものは少しずつ理解できるようになっていた。 だからこそ言われた。 「アプリチーム目線で指摘してほしい」 いや、簡単に言うな。 こっちは、いきなり世界基準の金融システムに放り込まれている。 しかもプロジェクトのコントローラーは、1次受けベンダーの重鎮。 プロパー側も全体統括クラスしかいない。 そこに—— あのパワハラ営業。 そして、その取り巻き。 現場の空気は、常に張り詰めていた。 ■ “嫌いな人間”が、巨大案件を取ってくる現実 ここ、かなり議論を呼ぶと思う。 私はその営業が嫌いだった。 今でも、やり方が正しかったとは思わない。 だが。 こんな巨大プロジェクトを取ってくる。 しかも、日本に存在し...

うわっ、完成を見届けない仕事に意味なんてあるのか！？——そんな疑問が、社会人7年目の終わりに頭をよぎった。 走り続けた7年間の現場 社会人7年目も終わりを迎えようとしていた私は、これまでいくつものプロジェクトに関わってきた。大規模案件もあれば、小規模なものもある。所属しているのはアプリケーション開発部隊。各前線のSEが持ち帰ってくる案件のうち、大規模なシステム開発が必要な場合に投入される舞台だ。 仕事は山ほどあるが、主役は限られる SEが持ってくる仕事は多い。パソコンの置き換え、ネットワーク工事。しかし、その中でも最もインパクトが大きいのはシステム開発プロジェクトだ。かかる金額は桁違い。だからこそ人も集まり、そして去っていく。私もそのうちの1人だった。 「最後まで関わる」とは何か？ 当然、最後まで関われたプロジェクトもあれば、途中で離れたものもある。ではここでいう「最後」とは何か？運用まで含めて見届けることなのか。それとも本番ローンチまでか。アプリケーション開発部隊の役割は明確だ。基本は本番ローンチまで。ハイパーケアまでは関わるが、その先の運用には踏み込まない。 200人プロジェクトでも同じ現実 ある200人規模のプロジェクトで、私は構成管理担当として多くの仕組みを整備した。システムテストからテスト環境への移行はやりきった。そして、その仕組みを本番にも適用する段階まで持っていった。 しかし——そのタイミングで次のプロジェクトの話が来た。 選択の分岐点 このプロジェクトの最後まで見届けるか。それとも新しい挑戦に踏み出すか。断ることもできた。しかし、新しい環境で自分の力を試す機会でもある。 ここで一つの問いが浮かぶ。 「完成を見ない仕事に価値はあるのか？」 私は思う。価値はある。ただし、それは“成果物”ではなく“仕組み”に宿る。誰かが作った仕組みの上に、次の誰かが乗り、本番を迎える。プロジェクトはリレーだ。全員がゴールテープを切る必要はない。 ビジネスとしてのリアル むしろ、すべてを見届けることに固執する方が非効率な場合もある。人材は有限であり、機会は連続する。重要なのは「どこで価値を最大化するか」という視点だ。 選択できる立場にいること自体が、すでに価値だ。ならば、止まる理由はない。 私は次のプロジェクトへ進むことを選んだ。 この...

 ・COBOLからJavaへ、その“当たり前”が崩れた日 ・テストケースは消えない資産か、それとも負債か ・量で品質を作る日本的開発のリアル えっ、まだ増えるの！？テストケースが雪崩のように積み上がる金融現場で、誰も笑えなくなった。 ■金融システムは「テストケースが多い」が前提 金融系のシステム構築では、そもそもテストケースが多い。それは常識だ。 勘定系、決済、残高、与信。どれも一つのミスが数億円の事故になる。 だからこそ「テストは多すぎるくらいでちょうどいい」という文化がある。 ■COBOL資産は“何十年分のテストの塊” 今回のプロジェクトは、COBOLで動いていた基幹システムをJavaへ全面刷新するものだった。 COBOLの世界では、何十年もかけてテストケースが積み上がっている。 それは単なるチェック項目ではない。 過去の障害、例外処理、業務のクセ、現場の“痛み”そのものだ。 そして重要なのは、 プログラム言語が変わっても、そのテストケースは消えないということだ。 業務ロジックは変わらない。だから本来はそのまま使える。 ■ただし「そのままでは使えない」 しかし現実は単純ではない。 COBOLからJavaへ移行すると、気にしなくていい領域が出てくる。 たとえばメモリ管理。 これはJavaのガベージコレクションに任せられるため、関連テストはごっそり不要になる。 またエラーハンドリングも構造が変わるため、テスト観点の再設計が必要になる。 一方で、業務ロジック自体は変わらない。 そのため多くのテストケースは“ほぼ流用可能”でもある。 ■結果：テストケースは約1万弱 こうして整理された結果、残ったテストケースは約1万弱。 多いのか少ないのか、現場では誰も断言しない。 ただ一つ言えるのは、「終わりが見えない量」であることだけだ。 ■テストは美しいほど順調に崩れる テスト開始直後は順調だった。 簡単な正常系が次々に通る。 まるで教科書に出てくる消化曲線のように、きれいに進んでいく。 しかし、その曲線は必ずどこかで止まる。 そしてその瞬間が来る。 ■どん詰まりは突然やってくる ある地点を超えた瞬間、テストは止まる。 原因は単純ではない。 ・仕様の解釈違い ・COBOL特有の癖 ・J...