Digital Heroes: Guide to IT World

うわっ！テレビに出ているCIOが、普通に目の前を歩いている！ IT企画部に出向して、驚いたことがある。 それは、システム開発の仕事が想像以上に少なかったこと。そして、会社のIT戦略を決める偉い人たちが、想像以上に身近だったことだ。 システムを作る側から、会社のITを考える側へ それまでの私は、ずっとシステム屋だった。 要件定義、設計、開発、テスト、リリース。 プロジェクトを成功させるために、品質、コスト、スケジュールを管理する。 そんな世界で仕事をしてきた。 ところが、IT企画部に出向すると、仕事の景色がガラッと変わった。 「この会社のITは、これからどうあるべきか？」 考えるのは、個別のシステムではない。 会社全体のITの仕組みだった。 IT企画部は、会社のITの司令塔 例えば、ポートフォリオマネジメント。 会社には数多くのシステムが存在する。 営業、経理、人事、生産、物流。 それぞれの部署がシステムを使い、新しい仕組みを求めている。 しかし、全部の要望に応えていたら、予算も人材も足りなくなる。 どこに投資するのか。 何を優先するのか。 どのシステムを維持し、どれを統合するのか。 そんな会社全体のITの方向性を考えるのが、IT企画部だった。 システムを利用する部署は、みんなIT企画部と連携する。 「なるほど。ITって、作ることだけじゃないんだ！」 プロジェクトマネジメントとは違う、新しい挑戦が始まった。 ITベンダーの仲間たちと、会社の未来を考える 面白かったのは、IT企画部には私以外にも、複数のITベンダーから出向してきた人たちがいたことだ。 普段なら違う会社で、時には競合する立場の人たち。 それが同じ部署で、会社のITの将来について議論している。 それぞれの経験や専門知識を持ち寄り、方針を考える。 システムを納品する立場から、システムをどう活用するか考える立場へ。 同じITでも、見ている世界が違っていた。 えっ！ここってCIO直下なの？ そして、もう一つ驚いた。 たまに、CIOがふらっとやってくるのだ。 そう。IT企画部は、CIOの直下にある部署だった。 CIOが社内外で発表するときには、その資料作成をサポートすることもある。 会社のIT方針を説明する資料も、IT企画部が作る。 つまり、自分たちが整理した考えが、経営層のメッセージになっていく。 「えっ、こんな...

Wait… I’m the one moving to the “client side”? It was my eighth year with the company. Until then, I had spent most of my career building systems. I gathered requirements, designed systems, developed them, tested them, and released them. When one project ended, I simply moved on to the next. That was the work I had been doing over and over again. ▼開発会社選びに悩んでいる方はこちら   Suddenly, I Was Moving to the “Client Side” At the time, I was working on the vendor side, receiving orders from another company. I had seen several people around me being assigned to the companies that were actually placing the orders. “Huh. So that’s another way of working.” That was about as far as I had thought about it. Then, one day: “Yamaguchi-san, we have an opportunity for you to be assigned to another company.” My heart skipped a beat. So, it was finally my turn. But when I heard the details, it was different from the assignments I had seen before. I was going to be assigned to the client side . “The client s...

えっ、私が「発注する側」に行くの？ 入社8年目。 それまでの私は、ひたすらシステム構築をやってきた。 要件を聞き、設計して、開発して、テストして、リリースする。 一つのプロジェクトが終われば、また次のプロジェクトへ。 そんな仕事を繰り返していた。 ▼開発会社選びに悩んでいる方はこちら   ある日、突然「お客様側」へ 当時、私はある会社から発注を受ける立場で仕事をしていた。 周囲を見ていると、発注しているベンダー側に出向している人が何人かいる。 「へえ、そういう働き方もあるんだな」 そんな程度に思っていた。 ところが、ある日。 「山口さんにも、出向の話があります」 ドキッとした。 ついに自分にも来たか。 でも、話を聞いてみると、これまで見ていた出向とは少し違う。 私は、 お客様側に出向する というのだ。 「お客様側？」 「発注する側？」 「システムを企画する側？」 頭の中に「？」がいくつも浮かんだ。 今までとは、明らかに立ち位置が違う。 「作る」から「会社全体を見る」へ 幸い、そのポジションには前任者がいた。 だから私は、まず前任者の話を聞くことにした。 そこで分かってきたのが、IT企画部の仕事だった。 システムを作ることだけが仕事ではない。 会社全体のITが今どうなっているのか。 どんなシステムが存在しているのか。 どんなリスクを抱えているのか。 これから何を変えていく必要があるのか。 つまり、個別のシステムを見るのではなく、 会社全体のITを俯瞰して考える仕事 だった。 既に大きなプロジェクトは終わっていた。 だから、これからは管理が中心。 そして、次のプロジェクトの計画も始めなければならない。 「なるほど……。これまでとは全然違うな」 少しずつ、仕事の輪郭が見えてきた。 「2年間」という長さに驚いた そして、この出向には一つのルールがあった。 前任者も2年間。 そして、私も2年間。 泣いても笑っても、2年間で終わり。 「2年間か……」 正直、ちょっと長い気がした。 それまで私が関わってきたプロジェクトは、3カ月から1年程度。 短いプロジェクトをいくつも動かしてきた私にとって、同じ場所で2年間というのは、なんだか奇妙だった。 でも、よく考えてみると、やることはいっぱいありそうだった。 会社全体のITを理解する。 リスクを把握する。 ベンダーと調整する。 経...

What Comes After Building a Financial System? Bringing a London-Based System to Japan At the time, I was part of a project to introduce a financial system developed by a company in London into Japan. My role was application management. I was responsible for supporting the implementation in Japan while working closely with the system team in London and coordinating the applications across the overall system. The London-based system team took the lead in developing and managing the applications themselves. My role was to handle the coordination and confirmation needed on the Japanese side, and I stayed with the project all the way through the final stages of testing. Finally, we could see the launch approaching. I supported the operations team by reviewing their business processes and making sure they would be able to use the system effectively once it went live. I remember thinking, “This project will be finished soon.” It was March. I was starting to think about what would come next. ▼...

金融システムを構築した、その次は ロンドンのシステムを日本へ 当時、私はロンドンの会社が開発した金融システムを、日本に導入するプロジェクトに入っていた。 私の立場は、アプリケーション管理。 システム全体のアプリケーションについて、ロンドン側の担当者と連携しながら、日本での導入を支えていく仕事だった。 アプリケーションそのものは、ロンドンの会社のシステム担当者が中心となって進めていく。 私は、日本側で必要となる調整や確認を行い、テストの最終段階までプロジェクトに付き合った。 そして、いよいよ本番運用が見えてきた。 オペレーションの担当者が実際に使えるように、業務の流れを確認し、運用面もサポートする。 「もうすぐ、このプロジェクトも終わるな」 3月。 そんなことを考え始めていた。 ▼開発会社選びに悩んでいる方はこちら   「次のプロジェクトだ」 そんなタイミングで、声がかかった。 「次のプロジェクトだよ」 私は、当然こう思った。 「次もシステム開発プロジェクトかな？」 ところが、話を聞いてみると違った。 「次は、顧客先への出向」 ……うん？ 出向って、何だ？ システム開発プロジェクトではないのか？ さらに聞いてみる。 「IT企画部門に行ってもらう」 そこで、少し驚いた。 私は、それまでアプリケーションの設計やシステム導入には関わってきた。 プロジェクトの計画を作った経験もある。 しかし、「会社全体のITをどうしていくのか」という企画は初めてだった。 これは、面白い！ でも、考えてみると、とても面白い仕事だった。 これまでは、一つのシステムをどう作るかを考えていた。 今度は違う。 会社全体のシステムを、どうしていくのか。 どんなシステムが必要なのか。 何を残して、何を変えるのか。 どのタイミングで投資するのか。 それを企業レベルでプランニングする。 「プロジェクトのプランニングなら、ある程度やってきた」 正直、基盤側については、まだまだ自信がなかった。 それでも、プロジェクト全体の計画を書き、関係者を整理し、システム導入を前に進めてきた経験はある。 それが、企業全体のIT計画になる。 「かなり面白いじゃないか」 そんな仕事があること自体、当時の私には新鮮だった。 しかも、選ばれたのは一人 さらに驚いた。 会社から選ばれるのは、一人。 その一人として、自分が行くこと...

A System Cannot Run Alone. Every Server Has a Role Some time ago, I was involved in supporting the development of a financial system and helped introduce a system used in London into Japan. One thing left a strong impression on me. I realized that connecting systems and getting people to work together are, fundamentally, very similar. ▼開発会社選びに悩んでいる方はこちら   The London system was not simply one huge program. It was built by combining many servers, each with its own specific role. One server received data. Another processed that data. Then another server passed the processed results to the next system. Each server was simply performing its own role. But that alone does not create a system. Only when each component follows the defined rules and connects properly can the entire system begin to operate as one financial system. Being Connected Is Not Enough This is where system integration becomes difficult. It is not enough to simply connect two systems. What data should be transferred? W...