ロンドンのシステムを追いかけて、見つけた「地図」
「うわっ、システム構成図って、こんなに面白いのか!」
そう思った瞬間のことを、今でも覚えている。
当時、私はロンドンで開発されたシステムを日本へ導入していくプロジェクトに参加していた。
私のメインタスクは、先方から渡される大量のドキュメントを、英語から日本語へ翻訳すること。
もちろん、単なる翻訳作業ではない。
システムのことも理解しながら翻訳する必要がある。
だから、英語のドキュメントを読み進めるほど、「最先端のシステムの中に入り込んでいく」ような感覚があった。
翻訳しているのに、金融ビジネスまで見えてくる
面白かったのは、システムドキュメントだけではなかった。
プロジェクトでは、ビジネスに関するドキュメントも非常に多かった。
そこで私は、システムだけではなく、金融ビジネスについても勉強するようになった。
日本の金融ビジネスについても調べた。
それまでに取得していたいくつかの資格の知識も、思いがけず役に立った。
「なるほど。この業務があるから、このシステムが必要なのか」
そうやって、業務とシステムが少しずつつながっていった。
翻訳しているはずなのに、気づけば金融の仕組みを勉強している。
そして、その金融ビジネスを支えるシステムの構造まで見えてくる。
これは、とても贅沢な勉強の時間だった。
コード、サーバ、そして増えていく役割
システムドキュメントを読み込んでいくと、コードもいくつか出てくる。
サーバ構成も書かれている。
最初は、
「こんなにサーバがあるのか?」
と思った。
でも、よく見てみると、それぞれ役割が違う。
ログを扱うサーバ。
バッチ処理を行うサーバ。
それぞれの機能を担当するサーバ。
そこで、ふと気づいた。
「なるほど。ものすごく高機能な一つのアプリケーションを作っているというより、少しずつ役割を持った多くのシステムを組み合わせているんだ」
一つひとつの役割を持ったシステムが集まり、大きなサービスを作っている。
そう考えると、システム全体が少しずつ理解できるようになっていった。
そして、A3一枚の「地図」に出会った
そんな中で、私が一番目を見張ったのが「システム構成図」だった。
たくさんのシステムが存在している。
サーバもたくさんある。
それぞれが複雑につながっている。
それなのに、それらがA3一枚に収まっていた。
「えっ、これ、全部入っているの?」
最初に見たときは、そんな驚きだった。
しかも、先方の担当者は、そのシステム構成図をいつも持っていた。
何かを確認するときも、その図を見る。
システムについて説明するときも、その図を見る。
まるで、システムの地図を持ち歩いているようだった。
システム構成図は「地図」だった
そこで私は、システム構成図の意味を初めて強く実感した。
システム構成図は、単なる技術資料ではない。
「このシステム全体の中で、どこで何をやっているのか?」
それを一目で把握するための地図なのだ。
知らない街を歩くとき、地図があれば現在地が分かる。
目的地も分かる。
そして、どの道を通ればいいのかも考えられる。
システムも同じだった。
たくさんのシステムがあっても、全体を俯瞰できる地図があれば理解できる。
「特にシステム構成図!これは良い!」
そう思った。
そして、その後のプロジェクト期間中、私はそのA3のシステム構成図を何度も見ることになった。
分からないことがあれば、まず地図を見る。
新しい機能を知ったら、地図のどこに位置するのか確認する。
誰かに説明するときも、地図を頭に思い浮かべる。
振り返れば、あの日に感動したのは、きれいな図だったからではない。
複雑なシステムを、人間が理解できる形に整理していたからだ。
DXでは、システムを作る力だけではなく、複雑なものを「見える形」にする力も重要になる。
あの一枚のA3図は、私にそんなことを教えてくれた。
私ならできる!明日から踏み出す
コメント
コメントを投稿