Digital Heroes: Guide to IT World

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 s...

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

Connecting a London-Built System to the Reality of Japan “Wow! The deeper I went underground, the more interesting the work became!” With that strange but exciting feeling, I found myself heading down to the basement of the client’s building almost every day. At the time, I was working on a project to introduce a system developed in London into Japan, serving as the system lead on the Japanese side. The application itself had already been completed. In other words, this was not a project where we were building a system from scratch. But bringing an existing system into Japan was a completely different story. There Was Still So Much to Do, Even Though the System Was “Finished” On the Japanese side, a large infrastructure team had been assembled. In addition, there was a lot of development work required in Japan, including changes to interfaces with surrounding systems. My role in the project was somewhat different. I needed to understand the system itself and then explain it t...

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

What I Learned from a Global Systems Project About Another Kind of Expertise: “Systems Interpretation” “Wait, if you can talk about systems in English, why can’t you interpret?” When I was working as a systems specialist on a global project, I ran into this wall many times. I had spent years studying systems. I joined global projects and discussed systems with people from around the world. My English was decent, too. At the time, my TOEIC score was 790. So naturally, I thought: “I can talk about systems in English. Then I should be able to interpret, too.” But when I actually tried it… No. This is tough. “Speaking” and “Interpreting” Are Different Speaking about my own ideas in English? I could manage that. I could also follow about 70 or 80 percent of what the other person was saying. When it comes to systems, many technical terms are already in English. System Architecture, Application, Database, Interface, Integration, Cloud… In fact, because system terminology itself becomes a comm...

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

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

From Building Systems to Connecting Systems “Wait… I’m not building an application this time?” When this system development project began, things took a somewhat unexpected turn. In fact, my department did not have that much of a role in the initial development of this system. Why? Because the system itself was already built. This was not a project where we developed an application from scratch. Instead, we were introducing an existing, fully developed system and adapting it to the Japanese business environment. Of course, it was not that simple. When a completely new system suddenly enters an existing environment, it inevitably creates an “interface” problem with the surrounding systems that have been running until then. Naturally, those surrounding systems need to be modified as well. “The system is already complete.” That may be true. But from the perspective of the surrounding systems, the reaction is more like: “Wait a minute… this new system just showed up out of nowhere!” And so...

  “Wait… Who is this guy?” This time, I joined a project to adapt a system from the UK for use in Japan. There were two key members on the Japanese side. One was a Japanese engineer who was completely fluent in English. The other was a British engineer who could speak a little Japanese. At first, I thought of him simply as someone who provided technical support. But as I talked with him, I began to notice something unusual. Japanese business experts would go directly to him with questions. When a system engineer asked a question, he would say, “Okay, let’s run this script,” and handle it right there. He could also explain the database structure and teach us about the network. “Who is this guy?” And it wasn’t just systems. He understood the business. He understood English. He understood the situation in Japan. He understood databases and networks. And when I heard that his annual income was over ¥10 million, I thought: Yes, this really is beyond full-stack. But His Own Words Were Un...

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

Whoa. The moment I became captivated by a salary figure, the way I saw my entire career as an engineer began to change. The “Full-Stack Engineer” I Admired In the world of engineering, there are many people who quietly and steadily build systems behind the scenes—not just those who stand out or take the spotlight. And engineers tend to be remarkably committed to learning. I was no different. Servers. Networks. Applications. A person who understands each specialized area, can see the bigger picture, and knows what needs to be done—and who needs to do it. Someone who understands the entire development project and can make the system work as a whole. People like that are often called full-stack engineers . Among engineers, they are the people others look up to. I remember going to take difficult IPA IT certification exams in Japan. The exam would take an entire day, and dozens of engineers would gather at the venue. I could almost feel the atmosphere: “Maybe these people are also working ...

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

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

If all you have to do is implement a system, then just read the specifications and you're done! …Really? I had just returned from a business trip to London. The purpose of the trip was to introduce a system used in the UK into Japan. At first, I thought: “If it’s a UK system, all we need to do is read the specifications.” Understand the system requirements. Check the functions. Then implement them in Japan. Simple enough. But as soon as I actually started reading the requirements, I ran into a wall. “This simply won’t work as it is in Japan…” A System Reflects the Business of Its Country The reason was simple. The business rules underlying the system itself were different between Japan and the UK. The securities industry, in particular, has a complex, multi-layered structure of rules. First, regulatory authorities and exchanges establish the rules. Large banks and securities firms then translate those rules into their own business processes. Smaller securities firms follow and supp...

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

Where Did the Line Between IT Professionals and Business Users Go? A Small Sense of Crisis I Felt in My Eighth Year as a Professional Wow! My conversation with the customer felt more like a system design review than a business meeting! It was my eighth year as a working professional. I could already see my ninth year approaching. By then, I had spent years building business applications as a systems engineer. I listened to customer requirements, designed solutions, developed systems, and delivered implementations. My role was to provide professional IT services to customers. Then one day, a Japanese customer purchased an enterprise software package from a company in London. I joined the implementation project and traveled to London for system training. The training lasted two weeks. It took place around Waterloo, an area known for its concentration of financial institutions and large corporations. At the time, I thought I was there simply to learn a new system. What I actually learned,...

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

A System Is Not a Finished Product. It Is Something You Grow. How Configuration Changed My View of System Design Wow! The system started transforming itself without writing a single line of code! From Confidence in Development to a New Discovery I have been involved in system development for many years, and before I knew it, I had spent eight years leading and controlling large-scale projects. In my early career, I worked mainly with Java-based systems and gained experience across the entire lifecycle—from design and development to testing and operations. To be honest, I had become fairly confident in my ability to build systems. Gather requirements. Design. Develop. Test. Release. I believed that was simply how systems were built. Then I had an experience that completely challenged that mindset. It was a project to implement an overseas enterprise software package. The Lesson I Learned in London As part of the project, I attended a two-week training program in London to learn the prod...

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