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企画部が作る。 つまり、自分たちが整理した考えが...

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

えっ、システムって一つ完成させれば終わりじゃないの？ 以前、私はロンドンから金融システムを導入するプロジェクトに関わっていました。 当時の私は、まず「メインとなる金融システムを日本でどう動かすか」を考えていました。 海外から導入するシステムですから、当然、日本の業務に合わせた調整が必要です。 ただ、基本的な考え方はシンプルでした。 メインシステムは、できるだけ設定で変更する。 どうしても設定では対応できない部分だけ開発する。 そして、その開発については日本で全部作るのではなく、基本的にはロンドン側へ依頼する。そこから必要な開発が、しかるべき場所で行われていく。 「これなら、なんとか進められそうだ」 そう思ったのを覚えています。 ところが、次に待っていたのが「周辺システム」でした。 ▼開発会社選びに悩んでいる方はこちら   メインシステムが来ると、周りも変わる 新しい金融システムが入る。 すると、当然ながら、そのシステムとつながっている周辺システムも変えなければなりません。 データ項目が変わる。 インターフェースが変わる。 送信する形式が変わる。 受け取る側も、それに合わせて改修する。 一つずつ確認し、一つずつ接続していく。 すると、少しずつ社内システム全体の姿が見えてきました。 「よし。社内はなんとか目途が立ってきた」 そう思った瞬間、次の課題が出てきました。 今度は、 別の会社のシステムです。 金融システムは「会社の中」だけでは完成しない 金融の世界では、一つの会社のシステムだけですべての業務を完結できません。 注文が入る。 確認する。 承認する。 支払う。 記帳する。 そして、その情報を別のシステムや企業へ連携する。 つまり、一つの取引を成立させるために、多くの企業、多くのシステムがつながっています。 ここで重要になるのが、「どうつなぐか」です。 どのプロキシーを使うのか。 どのデータフォーマットで送るのか。 どのくらいの頻度で送信するのか。 システムはこちらから接続しに行くのか。 それとも相手に接続してもらうのか。 さらに、接続に料金は発生するのか。 こうしたことを一つずつ決め、相手企業に通知しなければなりません。 そして、通知して終わりではありません。 「この項目は何ですか？」 「この形式には対応できますか？」 「テスト環境はどうしますか？」 次々と...

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

「完成」がゴールだと思っていた うわっ！金融システムが“生き物”みたいに成長していた。 私はこれまで、約8年間システム作りに関わってきた。 設計し、開発し、テストし、納品する。 そういう世界で仕事をしてきた。 もちろん、その中で改善提案もしてきた。 しかし、どこかで「システムは作って終わり」という感覚があった。 そんな中、あるプロジェクトに参加することになった。 お客様が、ロンドンから金融系システムを日本へ持ってくるプロジェクトだった。 ロンドンで見た“異様な光景” 私はアプリケーション観点でシステムを理解する担当として、2週間ロンドン研修に参加した。 そこで見たものが衝撃だった。 そのシステムを所有していたのは、システムベンダーではない。 ロンドンの金融会社だった。 つまり、金融会社自身が金融基幹システムを作り、それを自社資産として海外へ販売していたのである。 しかも、それを買ったのは日本の金融会社。 私は驚いた。 日本では、 「金融会社が使うシステムをITベンダーが作る」 という構造が当たり前だった。 しかしロンドンでは違った。 「金融会社が、自分たちで磨き上げたシステムを商品として売る」 なのである。 しかも、国内マーケットだけではない。 海外の金融機関へ販売していた。 システムそのものが、国境を越えるビジネスになっていた。 運用担当者が9画面を操っていた さらに驚いたのは運用現場だった。 運用担当者は、9つのスクリーンを同時に使いこなしていた。 こちらが、 「こういう機能はあるんですか？」 と聞く。 すると返ってきたのは、 「それは現在開発中だ」 という言葉だった。 私はそこで初めて気づいた。 この人たちは、“完成品”を運用しているのではない。 “成長途中のシステム”を運用しているのだ。 そして、現場の知見をもとに、継続的に改善し続けていた。 最初から完璧を目指していた自分 一方、当時の私は違った。 最初の開発で、完璧なシステムを作ろうとしていた。 でも実際には、 要件は曖昧なことも多い。 お客様自身も、 「本当に欲しいもの」 を言語化できていないこともある。 そして何より、自分自身の知識もまだ中途半端だった。 しかし不思議なことに、システムを作り終える頃には、かな...

うわっ、動いてるのに“負け”が確定する世界がある——それがシステム開発だ。 ■社会人7年、200人プロジェクトの現場 社会人7年、私はシステム屋として数多くのプロジェクトを回してきた。中でも忘れられないのは、200人を超える巨大プロジェクトだ。しかも、ただ人数が多いだけではない。物理的にも過酷だった。 「この狭い部屋に200人、どう座る？」 そんな議論から始まる現場。だが、本質はそこではない。人が密集するほど、システムもまた“複雑さ”を増していく。 ■構成管理という“裏側の支配者” 私は構成管理担当として、開発そのものではなく、環境の安定を支える役割を担った。プログラマー、サーバ担当、ネットワーク担当——多様な専門家と関わる中で、ある事実に気づく。 「動かすこと」と「支えること」は、まったく別の能力だ。 ■プロの条件は“少なさ”に宿る プログラムの世界は奥深い。だが、真のプロはコード量で語らない。むしろ逆だ。 行数は少ない。コメントは的確。無駄がない。 “読める・書ける”だけでは、ただの作業者に過ぎない。 本質は「設計思想」と「再現性」にある。 ■サーバも同じ、動くかではなく“耐えるか” サーバ構成も同様だ。つなげば一応、動く。日常運用では問題ないかもしれない。 しかし、負荷が急増した瞬間—— その差は一気に露呈する。 耐える構造か、崩壊する構造か。 ここに“プロとそれ以外”の境界線がある。 ■議論：なぜ日本の現場は“動けばいい”に流れるのか ここであえて問題提起したい。 なぜ多くの現場は、「とりあえず動く」ことをゴールにしてしまうのか？ 納期、コスト、評価制度——理由はいくらでもある。 だが、それを言い訳にした瞬間、技術者としての成長は止まる。 ■システム屋に必須なメンタリティ システムの各領域は、それぞれが深い。プログラム、インフラ、ネットワーク——すべてが専門職だ。 だからこそ必要なのは、 「自分の領域に閉じないこと」 そして、 「学び続けること」 変化を前提に、自らをアップデートし続ける。 それができる者だけが、“プロ”として生き残る。 ■ビジネス示唆 これはエンジニアだけの話ではない。 企業も同じだ。 「今、動いている」ことに安心した瞬間、競争力は静かに失われる。 本質は、“未来の負荷”...

「書かないエンジニア」という衝撃 うわっ!? コードを書かないのにシステムを支配している人がいる——。 社会人7年目、私は200人を超える大規模開発プロジェクトに構成管理リーダーとして参画していた。5社が入り乱れる現場で、各種基準書を整備し、チーム全体を“ルール”で誘導する役割だった。 そんな中、最も密に連携していたのがサーバ管理担当だった。構成管理とサーバ管理は、現場を支える両輪だ。自然と会話も増えていった。 ある日、何気なく聞いた。 「Javaとか、どれくらい書くんですか？」 返ってきたのは、予想外の一言だった。 「いや、書いたことないですね」 現場を動かす“スクリプトという言語” 驚いた私は、さらに聞いた。 「じゃあ、何もプログラムしないんですか？」 彼は少し笑って答えた。 「いや、簡単なものならやってますよ」 そこで出てきたのが、Bashに代表されるシェルスクリプト、そしてWindowsのVBスクリプトだった。 ここで、システムの“裏側の構造”が一気に見えてきた。 サーバは「JOB」という単位で管理される。処理はすべてスケジュールされ、自動化されている。そして、その統制を担うのがJP1だ。 しかしJP1は、単独では動かない。OSの機能を呼び出す際には、必ずスクリプトを介する。つまり、シェルスクリプトやVBスクリプトが“翻訳者”として、JOBの指示をサーバに伝えている。 システムは「3層」で動いている ここで整理すると、構造はこうだ。 ・全体統制：JP1（JOB管理） ・実行主体：各サーバ ・接続役：スクリプト（Shell / VB） そして、その上で我々のJavaなどのアプリケーションが動く。 つまり、派手なアプリケーションの裏側には、無数のスクリプトが存在し、それらがシステム全体を支えているのだ。 “小さなコード”がシステムを支配する 週次処理、バッチ処理、ログ取得、監視連携—— これらはすべて、小さなスクリプトの積み重ねで成り立っている。 大きなプログラムではない。だが、その数は膨大で、どれ一つ欠けてもシステムは止まる。 彼らの仕事は目立たない。しかし、確実に“全体を動かしている”。 エンジニアの価値はどこにあるのか ここで一つ、議論を投げかけたい。 「高度な言語で大規模なコードを書ける人...

うわっ…言語が変わるだけで、人はここまで不安になるのか!? ■社会人6年目、突然の「Java化」 社会人6年目。私は、日本の金融業界の中心を司る巨大企業の基幹システム刷新プロジェクトにいた。これまで長年、COBOLで作り上げられてきた巨大なシステム。その変換先として提示されたのが「Java」だった。 最大時には200人を超える大規模プロジェクト。だが現場に広がったのは期待ではなく、不安だった。 「COBOLしかやってきていない自分たちは、Javaに対応できるのか？」 ■COBOLという“設計至上主義” COBOLは手続き型言語だ。プログラムは上から下へ、順番通りに積み上げる。 一行の文字数、配置、メモリの使い方まで厳密に意識しながら書く。 部品を呼び出すというより、「業務の流れ」をそのままコードに落とし込む。 だからこそ、設計がすべてだった。 設計で全体の順序を完璧に組み立て、それを忠実にコードに写す。 このスタイルに慣れたエンジニアにとって、「自由度の高いJava」は未知の世界に見えた。 ■Javaがもたらした“構造の解放” しかし、実際にプロジェクトが動き出すと、状況は大きく変わった。 Javaはオブジェクト指向をベースに、部品化・再利用・柔軟な構造を許容する。 さらに、メモリ管理の負担も軽減されている。 COBOL時代のように、細かい領域を意識し続ける必要はない。 この“制約の解放”が、現場に新しい風を吹き込んだ。 設計者もプログラマーも、思った以上にスムーズに適応していったのだ。 ■「言語は違えど、本質は同じ」 振り返ると、気づくことがある。 プログラム言語は違っても、「構造を理解し、論理を組み立てる」という本質は変わらない。 実際、Java以降の言語は構造が似ている。 現在主流のPythonやRubyといったスクリプト言語も、オブジェクト指向ベースであり、英語に近い記述で理解しやすい。 つまり、一つの言語で“構造”を理解した人は、次の言語にも応用が効くのだ。 当時のJava移行は、今で言えば「Javaからクラウド（Lambdaなど）への移行」に近いインパクトだった。 それでも、現場は乗り越えた。 ■200人が証明した「進化できる力」 最終的に、この200人規模のプロジェクトは成立した。 COBOLの...

うわっ…コードを書いていないのに、プロジェクトが崩壊する!? ■Cobol時代にはなかった“新たな難しさ” かつてCobol中心の時代、システムは比較的シンプルだった。構成も閉じた世界で管理され、外部依存は限定的だった。しかし、Javaへの移行とともに、ある領域が一気に難しくなった。それが「構成管理」、特にライブラリ管理である。 ■Javaの進化が生んだ“自由と混乱” Javaは極めて拡張性が高い言語だ。豊富な標準機能に加え、世界中の開発者が機能をパッケージやクラスとして公開している。これにより、ゼロから作らなくても高度な機能を簡単に取り込めるようになった。これは生産性の飛躍的向上を意味する。 だが同時に、「どれを使う？」という新たな判断が発生した。     ■パッケージ選定という意思決定の重さ 各パッケージは、世界中の優秀なエンジニアが作り込んだものだ。設計も品質も高く、使わなければ開発規模は膨大になる。だが、選択を誤れば、システム全体に影響を及ぼす。 しかも、必要な機能は複数のパッケージで実現できる場合も多い。どれを選ぶかは、単なる技術選定ではなく、プロジェクトの将来を左右する経営判断に近い。 ■最大のリスクは“見えないセキュリティ” 問題はセキュリティだ。このパッケージ、本当に信じていいのか？変なコードが仕込まれていないか？安全性は？安定性は？ 情報が限られる中、ネットを検索し、仕様を読み、過去の実績を調べる。かつてはSun Microsystemsの情報を読み漁りながら判断することもあった。しかし、それでも確信は持てない。 ■終わらないアップデートとバージョン地獄 さらに難しいのは、これらのパッケージが常に進化していることだ。アップデートは頻繁に行われ、新機能や修正が追加される。だが、複数のパッケージを組み合わせると、バージョンの整合性が問題になる。 あるパッケージを更新すると、別のパッケージと互換性が崩れ、動かなくなる。逆に更新しなければ、セキュリティリスクが高まる。このトレードオフは、現場に重い意思決定を突きつける。 ■それは“迷宮の入り口”だった こうして、構成管理は単なる管理作業ではなくなった。技術、セキュリティ、運用、将来性——あらゆる要素を考慮する複雑な意思決定プロセスへと変わったのだ。 そして...

うわっ…巨大組織の心臓が、こんなに小さいなんて誰が想像できるだろうか！ ■社会人6年目、想像していた「大組織」 社会人6年目。私は、日本の金融業界の中心を支える基幹システムのプロジェクトにアサインされた。 規模は200人超。複数ベンダーが参画し、名だたる企業が並ぶ。 「これは完全に、大組織での分業戦だな」 そう思っていた。日立のプロパーも多数入り、重厚なマネジメント体制が敷かれている——はずだった。     ■びっくりするほど“小さい本体” しかし、現場に入って目にした光景は、まったく違っていた。 机の一列に並ぶ、たった6人。 部長はそこにはいないが、その席の横に、課長、主任3人、担当2人。 この6人が、すべてを回していた。 周囲には確かに人がいる。 ベンダーは4社、それぞれ平時でも20名以上。 開発ピーク時には、テスト要員も含めて200人を超える。 だが、意思決定と全体制御は、この6人に集約されていた。 「本体は、ここか…」 その瞬間、プロジェクトの構造が一気に見えた。 ■構成管理チームという“中枢神経” そんな中、私は新たに切り出された構成管理チームを任された。 理由は明確だった。Java化による構成の複雑性。 だが、すぐに気づく。 これは単なる「構成を管理する仕事」ではない。 各チームごとに開発スタイルが違う。 ビルド方法、ブランチ戦略、リリース手順——すべてがバラバラ。 つまり、必要なのは統制ではなく「調整」だった。 ■本当の仕事は“すり合わせ” 構成管理とは、コードを管理することではない。 チーム同士の前提を揃え、衝突を防ぎ、全体最適に導くこと。 4社のベンダー、それぞれの文化。 20人単位のチームが複数動く中で、わずかなズレが致命傷になる。 私は、構成を通じてそれを繋ぐ役割だった。 「ここ、どう合わせます？」 その一言が、プロジェクト全体のスピードを変える。 ■6人が200人を動かす理由 なぜ6人で回るのか。 答えはシンプルだ。 ・意思決定が速い ・構造を理解している ・全体を俯瞰できる 人数ではない。 構造と役割が、すべてを決める。 そして、その中に「調整役」が組み込まれていること。 これが、巨大プロジェクトを動かす本質だった。 ■身震いした責任と、...

えっ、プログラミング言語の“完成形”が日本にあっただと!? ■COBOLだけではなかった 社会インフラを支える巨大システム。その裏側で、日立はCOBOLを手掛け、協会もリードしながら、日本国内で確固たる地位を築いていた。 しかし、本質はそこでは終わらない。 彼らは“言語”だけでなく、もっと根本的なものに手を伸ばしていた。 空いた時間でお小遣いを貯めよう！「アイリサーチ」       ■システムの核に踏み込む サーバを作る。これは分かりやすい。 だが、システムを構築する上で絶対に避けて通れないものがある。 それがDB、データベースだ。 世界を見渡せば、MicrosoftのSQL Server、IBMのDB2、OracleのOracle。 主要なDBはほぼ海外製品が席巻していた。 その中で、日立は挑戦していた。 それがHiRDB。 ■言語の“さらに内側”へ HiRDBは、Cosminexusなど日立のシステム基盤と連携するDBだ。 だが本当に驚くべきはそこではない。 そのHiRDBを操作するためのSQL、つまり“DBを動かす言語”まで、日立は自ら設計していた。 しかもその名称は、あえてのSQL。 ややこしいが、これはHiRDB専用のSQLである。 ■なぜ独自SQLが必要なのか 実務でDBを触るとすぐに気づく。 同じSQLでも、DBごとに微妙に構文が違う。 「あれ？」 「なんでこう書くんだ？」 そう思いながら、例外的なルールを覚えていく。 それが現場の現実だ。 ■“癖がない”という価値 だが、DBを極めた分析屋たちはこう言っていた。 「HiRDBのSQLが一番癖がない」 構文が整っている。 規則性がある。 理解しやすい。 つまり、最も“自然に使える言語”だった。 Oracleでも、SQL Serverでも、どこかで違和感に出会う。 だがHiRDBは違う。 その違和感を排除する方向で設計されていた。 ■技術の深さと広がらなかった理由 残念ながら、HiRDBは世界的に広く普及したとは言えない。 しかし重要なのはそこではない。 DBそのものを作り、 その上で動く言語まで設計し、 さらに“人にとって分かりやすい形”に整える。 このレベルの要素技術を内製できるエンジニア集...

世界の大企業は、意外と“同じ道具”で動いている グローバル企業にいると、ふとした瞬間に気づきます。 「あれ？またこのシステムか」 別の部署、別の国、別の業種なのに、使われているシステムがやけに似ているのです。 理由は明快。 世界で勝ち続けるには、共通言語＝共通システムが必要 だから。 では、実際にどんなシステムが使われているのでしょうか？ 押さえておきたい「グローバル標準」のシステムたち まず、ERPの王者 SAP 。 「使いにくい」「カスタマイズが大変」と言われつつも、財務・購買・物流を一手に支える存在。 もはや、これを外すグローバル企業は少数派です。 人事管理は Workday 。 柔軟なワークフロー設計とグローバル対応で、海外本社ではかなりの採用率。 問い合わせ・環境管理なら ServiceNow 、 CRMは圧倒的なシェアを誇る Salesforce 、 アプリケーション全体の見える化では LeanIX 、 フィールドサービスの管理には ServiceMax ――。 これらが業務の「骨格」として、世界中のグローバル企業で共通して使われています。 世界とつながるには、世界の道具を使いこなせ こうしたグローバルシステムは、ローカル企業との連携時にも力を発揮します。 新しく買収した現地法人が独自システムを使っている場合、徐々にグローバル標準へ統一していく。 契約・セキュリティ・データ連携――そのすべてが「共通化」されることに意味があるのです。 ただし！ この“統一プロジェクト”はそう簡単ではありません。 バイリンガルPM、専門スキルを持った開発者、国ごとの法制度の違い… **そして何より重要なのは、「現場の納得」**です。 変革のカギは、システムではなく“人の想い” どんなに優れた仕組みでも、使う側に熱量がなければ宝の持ち腐れです。 グローバルと連携して勝負したいのか、 世界の中で新しい価値を生み出したいのか。 その想いがあるなら、共通システムは確実に武器になります。 DXの成功とは、ツールを導入することではなく、 ビジネスとITが一体となって「変わることを選ぶ」こと。 境界線なんて必要ありません。手を取り合って前へ進むだけです。 アンケートでおこづかい稼ぎ     明日...

ノーコード・ローコードで誰でもアプリが作れる時代！ なんて言葉を聞いてワクワクしている人、ちょっと待った！⚠️ 実はこれ、 30年以上前からずっと同じ話を繰り返している って知ってました？ 確かに、ノーコード・ローコードはプログラミングのハードルを下げ、DX（デジタルトランスフォーメーション）を加速させる夢のような技術です。でも、「誰が管理するのか？」「バグが出たらどうするのか？」という本質的な問題は、昔から変わっていません。私は 20年前にEXCELの設計書からプログラムを自動生成するツールを作っていた けど、その時も同じ問題に直面しました。 では、ノーコード・ローコードの未来は本当に明るいのか？その落とし穴とは？ システム開発の歴史を振り返りながら、DXの進化の本質を探ってみましょう！ 🔍 そもそも、ノーコード・ローコードって本当に新しいの？ 「最近、ノーコード・ローコードがすごい！」なんて話を聞くと、まるで革新的な技術のように感じますよね。でも、よく考えてみてください。 ✅ 1990年代 → HTMLが普及し、「コードを書かずにWebページが作れる！」と話題に ✅ 2000年代 → VBA（Excelのマクロ）が「プログラミング不要で業務自動化ができる！」と流行 ✅ 2010年代 → RPA（ロボティック・プロセス・オートメーション）が「業務を自動化できる！」と話題に ✅ 2020年代 → ノーコード・ローコードが「誰でもアプリが作れる！」とブームに ね？結局、時代が変わっても「簡単にプログラムが作れる」ツールが出てくるたびに、同じことを言ってるんです。 💡 20年前に作った「自動プログラム生成ツール」 私は20年前、EXCELの設計書からプログラムを自動生成するツールを開発しました。考え方は今のノーコード・ローコードと同じで、 「設計書を作るだけで、すぐに動くプログラムができる」 というもの。 当時の企業も「すごい！これがあればプログラマーはいらない！」と盛り上がりました。 でも、現実は違いました。 ❌ ツールが生成するコードにバグがあったら、誰が責任を取るのか？ ❌ セキュリティの問題が発生したとき、誰が対処するのか？ ❌ システムを作るのは簡単になったけど、管理とメンテナンスをどうするのか？ 結果と...

本当のDXは「システム追加」じゃなく「システム断捨離」 「DXを推進しよう！」 そう言われた瞬間、あなたの頭に浮かぶのは何だろうか？ 「最新のクラウドサービスを入れる？」 「AIを導入して自動化する？」 「データ分析ツールを買う？」 …ちょっと待ってくれ！ DXとは「デジタルを活用したビジネス変革」だ。 なのに、なぜ多くの企業が 「DX＝システム導入」 になってしまうのか？ 今日は 「DXをしたつもりが、ただシステムを増やしてるだけ」 という落とし穴について話していく。 DXの話をすると、なぜかシステムの話になる問題 DXの会議を開くと、決まってこんな流れになる。 💬「DXを進めるには何が必要ですか？」 👨「クラウド化ですね」 👩「RPAを入れれば業務効率が上がるのでは？」 🧑‍💻「BIツールを導入すればデータが可視化できますよ！」 …全部システムの話。 確かに、デジタルツールは便利だ。 でも、本来のDXの目的は 「業務やビジネスの変革」 であり、ツールを入れることではない。 例えば、あなたの会社に 10個のシステム があるとしよう。 そこに新しいDXツールを1つ加えたら 11個のシステムが存在する ことになる。 これ、本当に効率化になってる？ むしろ、データの連携が増えて管理が複雑になってない？ ベンダーはシステムを売りたいだけ！最適解を考えるのは自社の仕事 DXの話をすると、ベンダーがすぐに営業をかけてくる。 「今の時代、クラウドですよ！」 「AIでデータ分析を強化しませんか？」 「RPAで業務を自動化できます！」 でも、ちょっと冷静に考えてほしい。 彼らのビジネスは 「システムを売ること」 だ。 つまり、あなたの会社にとって最適な解決策ではなく、 「自社の製品を売る方法」 を考えているだけ。 本当に必要なのは 「何を導入するか？」ではなく「何を減らすか？」 だ。 DXにこそ「システム断捨離」が必要！ DXを成功させるためには、 「新しいシステムを入れること」より「不要なシステムを削ること」 に目を向けるべきだ。 ✔ 既存のシステムを有効活用できないか？ ✔ 同じ機能のシステムが重複していないか？ ✔ そもそも、そのシステムを使って業務を改善しているのか？ ...

これが次世代のクラウドです！ ベンダーの熱意あるプレゼンを受け、私たちは最新サービスを採用する決断を下した。 だが、その選択が“地獄の入り口”だったとは、誰も想像していなかった——。 🔥 最新技術に飛びつくと、プロジェクトは炎上する！？ クラウドの進化は目まぐるしい。 AWS、Azure、GCPなど、各クラウドベンダーは 毎年数百もの新機能や新サービスをリリース している。 これだけ聞くと「最新のサービスを使う方が、DXが進んでいいじゃないか！」と思うかもしれない。 しかし、 最新技術＝最適解ではない。 実際、AWSのRedshiftが登場した当初、多くの企業がこぞって導入したが、結果は 炎上続き だった。 理由は簡単で、 ✅ 技術が成熟しておらず、細かなトラブルが続出 ✅ ベンダー側もノウハウがなく、支援が機能しない ✅ 社内に経験者がいないため、運用時にカオス状態 このように、新技術の採用はリスクが高い。 むしろ、 市場に浸透し、各社が痛い目を見た後のサービスのほうが、安定した導入が可能 だ。 📌 経験者のいない運用は、クラウドの強みを殺す クラウドの真のメリットは、 運用時にこそ発揮される。 例えば、リソースのスケールアップ・ダウンを自動化し、コストを最適化したり、 稼働状況をリアルタイムで監視し、障害を事前に察知することもできる。 しかし、 その運用を担う人材のレベルによって、クラウドの良さが全く活かされないケースが多い。 特に日本の多くのベンダーは 開発フェーズで大きく稼ぎ、運用には最低限の人員を置く傾向 にある。 その結果、 ❌ システムは完成したが、運用担当者がクラウドを理解していない ❌ 自動化どころか、手動作業が増え、運用コストが爆増 ❌ コスト削減のために導入したクラウドが、逆に高コスト化 運用を考慮せずにクラウドを採用すると、 DXどころか、ただのコスト増システム になりかねない。 国内唯一の一般社団法人による投資アドバイスができる国の免許を登録済みのFXスクール！生徒の7割が女性で、過半数以上がプラス成績を出しています。 💡 結局、一番コスパが良いクラウドの使い方とは？ クラウド導入を成功させるためには、 ✔ 最新技術に飛びつかず、成熟した技術を選ぶ ✔ 運用担当者のスキルを考慮して設計する ✔ 「攻め」...

プロジェクトが迷走!? そんな時、救世主となるのがEAだ！ システム開発の現場で、「仕様変更が多すぎる」「ビジネスと技術が噛み合わない」「プロジェクトが炎上している…」なんて経験、ありませんか？ その混乱の裏には、 Enterprise Architect（EA）の不在 が影響しているかもしれません。 では、大規模プロジェクトにおいて、EAはどんな役割を果たすのか？ PMとは違う、EAならではの視点 とは？ 今回は、EAの重要性を ストーリー仕立て で解説します。 🌀 混迷するプロジェクト、EAなしでは進めない!? 「システムの要件が増えすぎて、もうカオス状態です…」 プロジェクトマネージャー（PM）の田中さんは、毎日のように 増え続ける変更リクエスト に頭を抱えていました。 ビジネスサイドは「競合に負けないように、もっと機能を追加して！」 開発チームは「技術的に無理です、そんなこと急に言われても…」 このままではプロジェクトは破綻する。 そんなとき、EAである佐藤さんが立ち上がります。 「このまま進めたら失敗する。そもそも、プロジェクトのゴールは何か？」 EAは、 ビジネス、システム、業務オペレーションをつなぐブローカー 。 プロジェクトの目的を明確に意識し、全体の方向性を正すのが仕事です。 🎯 EAの役割①：ビジネスとITの架け橋となる EAがいなかった頃、ビジネスサイドは要望を次々に出し、開発チームはそれに振り回されるばかり。 しかし、佐藤さんが間に入ることで、ビジネスの意図を整理し、 「本当に必要な要件」 を抽出。 さらに、「この機能は本当に今必要なのか？」「代替案はないのか？」と議論を進め、 ビジネスとITのズレを修正していきます。 その結果、 プロジェクトはより現実的で実行可能な計画へと軌道修正 されました。 🛠 EAの役割②：全体システム構成を統括する 佐藤さんは、単なる技術屋ではありません。 プロジェクトの全体システム構成を管理し、各ソリューションアーキテクト（SA）を束ねるのも重要な役割です。 「各モジュールの連携はどうする？」 「このシステムは将来的にスケールできるか？」 個別の機能だけでなく、システム全体がスムーズに動くように設計するのがEAの腕の見せどころ。 技術的な視点とビジネスの視点を組み合わせ、 持続可能なシステム構築をリー...

やばい！これ、かゆいところまで手が届くBIツールだぜ！ 私が初めてMicrostrategy BIに触れたのは、プロジェクトで詳細なデータ分析が求められたときのことでした。最初は「高い…」と思いつつも、使い込むうちにその豊富な機能と、玄人向けの奥深さに圧倒されました。 1. かゆいところまで届くデータ分析 Microstrategy BIは、単純なレポート作成だけでなく、細部にわたるデータの分析や視覚化が可能。データ分析に詳しいエンジニアなら、その詳細な機能がとても扱いやすく、複雑なビジネス課題も鮮明に浮かび上がらせてくれます。一方、シンプルな分析を求めるユーザーにも、使いやすいダッシュボード設定が用意されていますが、 アクセス方法や見せ方の工夫は不可欠 です。 2. サーバ設置で性能アップ！ 内部ではメモリ展開が行われており、専用のサーバを設置すれば、パフォーマンスは確実に向上します。高価な投資ではありますが、これが 本物の玄人向けBIツール である証拠。企業のデータ戦略を支えるために、パフォーマンスと信頼性を追求した設計が光ります。 3. 最新技術との融合で、未来を切り拓け！ さらに、Microstrategy BIはAlexaなど最新の音声アシスタントと連携可能。これにより、音声でデータクエリを実行したり、リアルタイムな情報を得ることができ、まさに未来型のデータ分析環境を実現できます。実際、私もサービス構築のためにこの連携技術を活用し、革新的なソリューションを生み出しています。 『デイトラ』で仕事につながるWebスキルを身につけよう！ まとめ Microstrategy BIは、 「かゆいところまで手が届く」 細部の分析が可能な一方で、シンプルな使い方も追求できる、まさに多面的なBIツールです。値段は高いですが、その分、性能や拡張性、最新技術との連携で、企業のデータ戦略において圧倒的な強みとなります。 データ分析に真剣に取り組むなら、このツールで未来の可能性を切り拓いてみませんか？

やばい…システム乱立でカオス！ これは、多くの企業が直面しているリアルな問題です。営業部門が選んだCRM、経理部門が導入した会計システム、現場が使いやすいと判断した管理ツール…。気がつけば、各部署がバラバラにITを導入し、つながらないデータ、増え続けるコスト、複雑化する運用が企業全体の足かせになっている。 その結果？ ベンダーの言いなり！ 「このツールが便利ですよ」「最新のクラウドサービスを入れましょう！」と次々に提案されるままに導入。結局、システムが増えるばかりで、最適化されるどころか、逆に業務が複雑になってしまう…。 この状況を打破するために必要なのが、**Enterprise Architecture（EA：エンタープライズアーキテクチャ）**の考え方です。 EAとは？企業ITの"設計図" EAとは、簡単に言うと 「企業全体のITの設計図」 です。 例えば、家を建てるとき、 どこに何の部屋を作るのか？テレビは何台必要か？古い冷蔵庫はそのまま使うか？新しいものに買い替えるか？ といった全体の計画を立てますよね。 企業も同じ。 どのシステムを使い、どのデータを統合するか？ 古いシステムは廃止するのか？ 最新のテクノロジーは本当に必要なのか？ こうした戦略をしっかりと設計するのが、 EAの役割 なのです。 EAの目的は「DX」ではない！ 最近のトレンドとして「DX（デジタルトランスフォーメーション）」が叫ばれていますが、EAの目的はDXそのものではありません。企業の最終的なゴールは、 「利益を上げ、コストを下げること」 。 DXはあくまで手段であり、「最新技術を使うこと」自体が目的ではないのです。 むしろ、無駄なシステム投資を削減し、統合や最適化を進めることで 「最小のコストで最大のパフォーマンスを発揮できる企業IT」 を実現することが、EAの本質です。 EAの視点を持つエンジニアは少ない！ 残念ながら、日本企業で EAの観点を持っているエンジニアは本当に少ない のが現実です。 多くのエンジニアが、 システム単位での最適化 には目を向けるものの、 経営全体の視点でITを考える ビジネス戦略とITをつなぐ こうした視点を持っている人はほとんどいません。 だからこそ、EAを理解し、企業のために 本当に必要なITを考えられるエンジニア の価...