Digital Heroes: Guide to IT World

システム屋と業務担当、その境界はどこへ行ったのか 社会人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で吸収する。 それでも足りなければ次のリリ...

あっ！システムがまるで家庭菜園のように扱われていた！ 私はシステム屋として約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...