Digital Heroes: Guide to IT World

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

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

うわっ…サーバの上に湯気立つお茶が置かれている現場に、思考がフリーズした！ ■社会人6年目、現場のリアル 社会人6年目、私はある開発プロジェクトにアサインされた。そこは、足の踏み場もないほどごちゃごちゃした開発ルームだった。1人あたりのスペースはわずか80cm。隣のキーボードの音が、そのまま自分の思考に割り込んでくる距離感だ。 ■消えていく会議室 本来議論のためにある会議室は、2つがテストルームに転用されていた。残るはたった1つ。結果、打ち合わせは空きスペースか、立ち話。意思決定の質は、確実に下がっていく。 ■食事すらままならない 食べる場所もない。気づけば、ラックマウントサーバが“机代わり”になっていた。熱を持つ機器の上に弁当。これは冗談ではなく、現実だ。しかも結構危険だ。 ■夜は長く、そして遅い 夜はみんな遅い。私のプロジェクトも例外ではない。他の同期からも同じような話を聞く。「どこも似たようなものだよ」と。つまり、これは個別最適ではなく、業界構造の問題だ。 ■衝撃の“お茶事件” そんな中、同期から衝撃的なニュースが入った。 「サーバにお茶こぼしたらしい」 笑えなかった。 きっと同じような環境だったのだろう。 むき出しのサーバ、置き場のない書類、狭すぎる机。 その中で、ほんの一瞬のミス。 ■紙一重のリスク 正直、こちらも紙一重だった。 すぐに「サーバの上に物を置かないように」と通知を出した。 しかし、置く場所がない。 だから机の上にサーバがあり、その上に書類が重なる。 そして、その上に…… ■改善できない構造 問題は分かっている。 でも、すぐには変えられない。 予算、スペース、納期、すべてが制約だ。 だから現場は“危険を内包したまま最適化”されていく。 ■これがシステム業界の現実 同情しかない。 うなづくしかない。 同じ構造の中に、自分もいるからだ。 この話は極端に聞こえるかもしれない。 だが、似たような環境は確実に存在する。 そして、その上に我々は“高品質なシステム”を求められている。 ■ビジネスとしての問い これは単なる美談でも、笑い話でもない。 「この環境で、本当に持続可能な価値提供ができるのか？」 CXOが向き合うべき問いはここにある。 DXとはツール導入ではない。 現場の“物...

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

本当のDXは「システム追加」じゃなく「システム断捨離」 「DXを推進しよう！」 そう言われた瞬間、あなたの頭に浮かぶのは何だろうか？ 「最新のクラウドサービスを入れる？」 「AIを導入して自動化する？」 「データ分析ツールを買う？」 …ちょっと待ってくれ！ DXとは「デジタルを活用したビジネス変革」だ。 なのに、なぜ多くの企業が 「DX＝システム導入」 になってしまうのか？ 今日は 「DXをしたつもりが、ただシステムを増やしてるだけ」 という落とし穴について話していく。 DXの話をすると、なぜかシステムの話になる問題 DXの会議を開くと、決まってこんな流れになる。 💬「DXを進めるには何が必要ですか？」 👨「クラウド化ですね」 👩「RPAを入れれば業務効率が上がるのでは？」 🧑‍💻「BIツールを導入すればデータが可視化できますよ！」 …全部システムの話。 確かに、デジタルツールは便利だ。 でも、本来のDXの目的は 「業務やビジネスの変革」 であり、ツールを入れることではない。 例えば、あなたの会社に 10個のシステム があるとしよう。 そこに新しいDXツールを1つ加えたら 11個のシステムが存在する ことになる。 これ、本当に効率化になってる？ むしろ、データの連携が増えて管理が複雑になってない？ ベンダーはシステムを売りたいだけ！最適解を考えるのは自社の仕事 DXの話をすると、ベンダーがすぐに営業をかけてくる。 「今の時代、クラウドですよ！」 「AIでデータ分析を強化しませんか？」 「RPAで業務を自動化できます！」 でも、ちょっと冷静に考えてほしい。 彼らのビジネスは 「システムを売ること」 だ。 つまり、あなたの会社にとって最適な解決策ではなく、 「自社の製品を売る方法」 を考えているだけ。 本当に必要なのは 「何を導入するか？」ではなく「何を減らすか？」 だ。 DXにこそ「システム断捨離」が必要！ DXを成功させるためには、 「新しいシステムを入れること」より「不要なシステムを削ること」 に目を向けるべきだ。 ✔ 既存のシステムを有効活用できないか？ ✔ 同じ機能のシステムが重複していないか？ ✔ そもそも、そのシステムを使って業務を改善しているのか？ ...