Digital Heroes: Guide to IT World

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で吸収する。 それでも足りなければ次のリリ...

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

The Different Mindset About Systems I Discovered in London Wow! They were treating a system as if it were a home garden! For about eight years, I worked as a systems engineer and participated in many system development projects. Batch systems. Web applications. Email integration platforms. As a vendor, I was involved in a wide range of projects and gained experience developing systems of various sizes. The process was always familiar. Receive a request from the customer. Analyze the impact. Create a modification plan. Develop. Test. Release. I repeated this cycle over and over again. I belonged to an application development team, so most of the requests we received were relatively large-scale enhancements. Small changes rarely came our way. As a result, every request became a project of its own. Three months. Six months. Sometimes even longer. I always felt that I was "building" systems. But I never felt that I was "growing" them. The System Owners I Met in London O...

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

The Reality Check I Faced in London as an Engineer Wow! An engineer who crossed the ocean full of confidence found himself completely lost in front of a system. It was my eighth year with the company. I was traveling to London to attend training for a financial system that one of our customers had purchased. The server engineer, network engineer, and operations engineer were all there as well. And I was the only application engineer. What I was responsible for was not just a business application. It was the entire financial system. A massive platform where countless functions worked together and multiple systems were connected in complex ways. I was highly motivated. I had built many systems before. Java-based three-tier architectures. Web applications. Database design. Interface design. Customer-facing systems. I was confident in my application development skills. "My mission is to understand this entire system and eventually support its development and operations." With tha...