スキップしてメイン コンテンツに移動

ブログを翻訳

“This One Page Is Amazing!” — The Day I Was Fascinated by a System Architecture Diagram

Following a London-Built System and Discovering Its “Map”

“Wow! I never knew a system architecture diagram could be this fascinating!”

I still remember the moment I thought that.

At the time, I was involved in a project to introduce a system developed in London into Japan.

My main task was translating a large volume of documentation provided by the other side from English into Japanese.

Of course, it was not simply a translation task.

I had to understand the system while translating the documents.

As I continued reading the English documentation, I felt as though I was gradually stepping inside a cutting-edge system.

Translating Documents While Discovering the World of Finance

What was interesting was that there was much more than just system documentation.

The project included a huge amount of business-related documentation as well.

As a result, I began studying not only the system, but also the financial business behind it.

I also studied the Japanese financial business so that I could better understand how the system would be used in Japan.

The knowledge I had gained through several professional certifications also turned out to be surprisingly useful.

“Ah, so this business process is why this system is needed.”

Little by little, the connection between the business and the system began to make sense.

I was supposed to be translating documents, but before I knew it, I was learning about the structure of financial services.

And then I could begin to see how the systems supported that financial business.

It was a remarkably valuable learning experience.

Code, Servers, and More and More Roles

As I dug deeper into the system documentation, I also encountered pieces of code.

There were server architecture diagrams, too.

At first, I thought:

“There are this many servers?”

But when I looked more closely, I realized that each server had a different role.

A server for handling logs.

A server for batch processing.

Servers responsible for individual functions.

Then I suddenly realized something.

“Ah, I see. Rather than building one extremely sophisticated application, they have combined many systems, each with a relatively focused role.”

Each individual system had its own responsibility, and together they formed a much larger service.

Once I understood that concept, the overall architecture gradually became easier to understand.

And Then I Found the “Map” on a Single A3 Sheet

But among all the documents, the one that impressed me the most was the system architecture diagram.

There were countless systems.

There were numerous servers.

And everything was connected in complex ways.

Yet somehow, all of it fit onto a single A3 sheet of paper.

“Wait… all of this is on one page?”

That was my first reaction.

What impressed me even more was that the people on the other side of the project always carried this system architecture diagram with them.

Whenever they needed to check something, they looked at the diagram.

Whenever they explained the system, they referred to the diagram.

It was almost as if they were carrying a map of the entire system with them.

The System Architecture Diagram Was a “Map”

That was when I truly understood the value of a system architecture diagram.

It is not simply a technical document.

It is a map that allows you to see, at a glance:

“Where does each system fit, and what does it do within the overall architecture?”

When you are walking through an unfamiliar city, a map tells you where you are.

It shows you where you want to go.

And it helps you decide which route to take.

A system is much the same.

Even when there are countless systems, having a map that lets you see the entire landscape makes the whole thing easier to understand.

“Especially this system architecture diagram! This is really good!”

That was exactly what I thought.

And from that point on, throughout the project, that single A3 system architecture diagram became the document I referred to the most.

Whenever I didn't understand something, I looked at the map first.

Whenever I learned about a new function, I checked where it belonged on the map.

Whenever I explained something to someone else, I pictured that map in my head.

Looking back, what fascinated me that day was not simply that it was a beautiful diagram.

It was because it organized a complex system into a form that human beings could understand.

In DX, the ability to build systems is important.

But the ability to make complexity visible and understandable is just as important.

That single A3 diagram taught me that.

I can do it! Tomorrow, I’ll take the next step.

コメント

このブログの人気の投稿

「え、Cosminexusって何?HiRDBってまだあるの!?」— 国産ミドルウェアの光と影

えっ!?Cosminexus(コズミネクサス)って何?HiRDB(ハイアールディービー)ってまだあるの? そう驚く人もいるかもしれない。 実は、 CosminexusやHiRDBは今も販売され続けている 。 しかし、日立を離れた私の耳には、もうその名前が入ってくることはほとんどなくなってしまった。 かつて日本企業のIT基盤を支えてきた 国産ミドルウェアの歴史 と、 グローバル市場での戦い ——。 そこから見えてくる、日本企業が今後学ぶべきこととは何だろうか? ホストからオープンシステムへ—CosminexusとHiRDBの誕生 時は1990年代後半。 メインフレーム(ホストコンピューター)からオープンシステムへ という大転換が世界的に進んでいた。 従来のホストは高価で扱いづらく、企業はより柔軟な アプリケーションサーバ と RDB(リレーショナルデータベース) を求めるようになった。 そこで日立製作所が投入したのが、 Cosminexus(アプリケーションサーバ) と HiRDB(データベース) だ。 これらは 日本の大手企業向けに最適化 されており、特に JP1(統合運用管理ソフトウェア) と組み合わせることで、日立案件では鉄板のセットとなっていた。 しかし——。 世界を席巻するApache、Oracleの波 Cosminexusは、 オープンソースのApache Tomcatを内包 しながらも、パフォーマンス向上やエンタープライズ機能を強化していた。 HiRDBも 高い信頼性とスケーラビリティを誇り、かゆいところに手が届く設計 で、ユーザーからの評判は決して悪くなかった。 ところが、ここで市場の大波が襲いかかる。 世界ではApache TomcatやOracle WebLogic、IBM WebSphereなどのミドルウェアが爆発的にシェアを伸ばしていた。 特に、 ✅ Oracle Database → 巨大なマーケティング戦略+グローバル企業の標準に ✅ Apache Tomcat → 無料&オープンソースで圧倒的普及 こうした 海外勢の猛攻 の前に、国産ミドルウェアは徐々にシェアを失っていく。 競争が激化するミドルウェア市場 1️⃣ コストの問題 オープンソースを活用しているのに、価格競争が厳しい。...

中小企業診断士ってどうなの?―失敗と涙、そして未来への扉

マジで!?中小企業診断士の試験、やばすぎる! かつて、私も何度も挑戦し、幾度も壁にぶつかりました。試験は本当に厳しく、合格するためには何度も失敗を経験。最後に合格できたとき、思わずとんかつを頬張りながら涙を流したほどです。この苦い経験が、今の私のキャリアと人生観を大きく変えました。 試験の苦悩とその価値 中小企業診断士の試験は、全体的な構造化と論理的思考力を問われるため、ただ単に知識を詰め込むだけでは乗り越えられません。 難易度の高さ :私自身、数回の不合格を経験しました。合格できたのは、失敗から学び、試験問題の構造を徹底的に分析した結果でした。 実例に基づく問題 :各サービス企業の事例が盛り込まれ、実際のビジネス現場を想定した複雑な問題が多く出題されます。これにより、単なるテスト以上の実務に近い知識とスキルが求められるのです。 この試験に挑んだ経験は、単に資格を得るためのものではなく、 自分自身の論理的思考力と状況把握能力を飛躍的に伸ばす貴重なトレーニング となりました。 資格取得後の別世界―新たなキャリアの扉 資格を取得した瞬間、私は全く別の世界に足を踏み入れたことに気づきました。中小企業診断士協会や各支部に所属し、そこから仕事依頼が舞い込み、企業の経営改善に貢献する場が広がります。 コンサルティングの現場 :実際、コンサル企業が依頼を受け、チームで対応しているのと似た構造を持ちます。しかし、中小企業を対象としているため、案件の金額は大手コンサルに比べると低いのが現実です。 キャリアとしての厳しさ :中小企業診断士だけで生活するのは容易ではありません。しかし、ITを中心にキャリアを積む場合、取得した経験は日本企業で大きなアドバンテージとなります。 また、グローバルな視点で見ると、MBAの方が知名度は高いかもしれませんが、 日本国内においては中小企業診断士の知識と経験は絶大な価値 を持ちます。私の体験は、試験そのものが非常に難しく、現実に即した問題が出題されるからこそ、実務に役立つ力が自然と身につくということを実感させてくれました。 グローバル市場との認識の違いと今後の展望 世界では、MBAが広く認知され、グローバル企業での評価も高いですが、日本では中小企業診断士も根強い支持を受けています。 グローバルな評価 :今後、海外でも日本の高い技術力や経営手法に対する関心...

EA導入で企業は何が変わる?実践事例を紹介

企業のITシステム環境が複雑化する中、「どのシステムを使えばいいのか分からない」「システム同士が連携しない」といった悩みを抱える企業が増えています。こうした課題を解決するために注目されているのが、エンタープライズアーキテクチャ(EA)です。EAを導入することで、企業はどのように変わるのでしょうか?実際の事例を基に、その効果を解説します。 1. 迷いがちなシステム選び、EAで見える化 企業には、ERP(統合基幹業務システム)、CRM(顧客管理システム)、BIツール(ビジネスインテリジェンス)など、さまざまなITツールがあります。それぞれが高度な機能を持つ一方で、「導入したものの活用できていない」「類似機能を持つシステムが重複している」といった課題に直面する企業も少なくありません。 そこで登場するのがEAです。EAは、企業全体の業務プロセスやシステム構成を可視化し、どのシステムが必要で、どのシステムが不要かを明確にします。これにより、無駄な投資や重複した機能を排除することが可能になります。 2. グローバル企業におけるEAの重要性 特にグローバル展開をしている企業では、EAの導入が「基本の基」と言えるほど重要です。私が関わったある企業では、各国のオフィスが独自のシステムを運用しており、情報の一元化が困難でした。例えば、同じERPを使っているはずが、国ごとに設定が異なり、データの統合に多大なコストがかかっていました。 EAを導入した結果、全世界で統一されたシステム基盤が構築され、データのやり取りがスムーズに。さらに、不要なシステムが削減され、年間数百万ドルのコスト削減が実現しました。 3. EA導入でスリム化するシステム構成 EAを導入すると、システム構成が驚くほどすっきりします。私が担当したある製造業の企業では、導入前は50以上のシステムが稼働しており、どれが本当に必要なのかさえ分からない状態でした。EAを用いて業務プロセスを可視化したところ、実際に使われているシステムは全体の30%程度。残りは重複した機能や過去の遺産的なシステムでした。 最終的には、使うべきシステムが20個に絞り込まれ、メンテナンスコストも約半分に削減。さらに、社員がどのシステムを使えば良いか迷わなくなり、業務効率が大幅に向上しました。 4. 企業に変革をもたらすEAの効果 EAは、単なるシステム整理...