工場からグローバルへ──横河電機を変えた「カイゼン × IT」の軌跡

現場からITの最前線へ──「カイゼン文化」が育てたキャリアの軌跡  ──これまでのキャリアについて教えてください。 1992年に横河電機に入社し、製造業ならではの現場からキャリアをスタートしました。最初の配属先は生産ラインに部品を供給する購買部門で、その後も生産管理など現場を数多く経験してきました。そこからIT部門に異動し、現在に至っています。 現場にいた頃から、実は担当していたのはIT系の仕事でした。具体的には、グループ内の基幹システムや業務システムの導入プロジェクトに関わっていたのです。最初は業務側の立場で要件をまとめる役割でしたが、その要件を具体的にシステム化していくIT部門へと移りました。 横河電機には、生産ラインに対する改善手法が確立されているという大きな特徴があります。トヨタのカイゼンをベースに、社内でも改善を進めており、業務プロセスの標準化や無駄の排除といったプロセスを経てIT化するという明確な流れがあります。私のキャリアは、このように現場からIT部門という流れの中で形作られてきたと言えます。 工場から全社、そしてグローバルへ──段階的「標準化」で成し遂げたIT基盤の統一  ──これまでのキャリアにおける最も大きな実績をお教えください。 これまでITシステムの導入プロジェクトにほぼ一貫して関わってきましたが、その取り組みの広がりが段階的に大きくなっていったことが最大の実績だと考えています。 最初は工場単位の取り組みでした。工場の中でも業務が標準化されておらず、使われるITシステムもバラバラという状況からのスタートです。そこからまず工場単位で業務プロセスを標準化してIT化する。次の段階では工場を超えて、会社全体でさまざまなプロセスの標準化を行い、IT化していく。そして最終的には、グループ内の会社、つまりグローバルにプロセスを標準化してIT化する——という流れを経験してきました。 それぞれのプロジェクトで精一杯やってきましたから、難しいところは当然ありました。特に、業務プロセスを標準化するところは、現場の今の業務を変えていくということなので、ユーザーである現場の方々から慎重な声は必ず上がます。 「なぜ標準化やIT化をやらないといけないのか」を丁寧にユーザー部門の方にお伝えし、共感を得る──。これは毎回、プロジェクトごとに苦労がありました。しかし、ここを達成できた時の達成感は本当に大きなものがあります。 対立を越えて前へ──IT標準化を推進するための「覚悟と対話」 ──大きな実績を上げるまでにはどのようなチャレンジがあり、それは現職でどう生かされていますか。 プロジェクトを進めるためには現場と丁寧に向き合わなければなりません。一方で経営としては、プロジェクトを前に進めてやりきることが重要です。この間に立ってしっかり目標を達成することが一番のポイントだと思っています。 この取り組みの範囲が広がることで、最終的には横河電機グループ全体をグローバルで標準化し、関わりのあるパートナー企業やお客さまとデジタルでつながっていく──ここには明確なストーリーがあると考えています。今はそのストーリーの最終コーナーにいると感じています。何事にも前工程があり、後工程があります。過去があるから今がある、そして将来がある。そう考えながら取り組んでいます。 異なる「正義」を束ねる仕事──関係者をまとめるために ──仕事をする上でのアドバイスはありますか? IT部門は関わる関係者が非常に幅広いのが特徴です。社内のグループ内のITシステムだけを見ても、生産部門、営業部門、エンジニアリング部門、サービス部門、会計部門など、実にさまざまな業務領域があります。 その業務領域の方々としっかり会話してプロセスを標準化したり、IT化したりするわけですから、IT部門にいると、深くはありませんが各業務領域の知識がかなり備わります。業務プロセスを私たちは「エンドトゥエンド」と呼んでいますが、つながった形できちんと理解できるというのがIT部門ならではの特徴です。これがメンバーのキャリアアップにもつながっていくと思っています。 何より重要なのは、関係者と共感を持つことで、ここを常に目指すべきだと考えています。 私たちもそうですし、ユーザー部門もそうですが、腹落ちしないと次に進めないところがあります。最初はお互いの思いや考え方が違うところから始まるわけですが、ここを同じ目標に向かって共感できるようにすることが非常に重要です。「共感できればゴールに近づく」ということを、今までの経験を通じて実感してきました。 こうした課題はまだ進行形の部分もあり、解決できていない部分もあります。しかし少なくとも、全体最適で見るようにしないといけません。 ユーザー部門の方は、どうしても自身の業務領域がありますから、「自分の業務がどうか」という目線で来られます。しかし、エンドトゥエンドで標準化する、効率化するということを考えた時には、やはり全員が全体最適で考えないといけない。ここがポイントだと思っています。 IT戦略のやりがいは「アプリ・インフラ・セキュリティの”最適解”」をいかに導くか ──IT戦略本部長として、どのようなところにやりがいを感じますか? 現在、私はIT戦略本部におり、さまざまなユーザーと向き合っています。IT部門ですから、アプリケーションもあればインフラもあり、ITセキュリティのことも考えなければなりません。そうした中で、バランスをとることが非常に重要だと考えています。 セキュリティは、アプリでもインフラでも同じことが言えます。ただ、アプリは一つひとつのアプリケーションで事情が違います。インフラもインフラで、ネットワークや電話など、いろいろなものがありますが、それぞれ事情が異なります。そういったものを全体でどう実現していくか。 セキュリティやガバナンスはそのベースになるわけですが、そうしたところをしっかり整合をとりながら、戦略を立て、施策を実行する──ここがキーポイントになると思いますし、ここがきちんとできるかどうかが組織の成功の鍵になると考えています。 今、特に注力している施策はERPの刷新です。既存のERPを次世代のERPに切り替える。これをグループグローバルで、全業務領域を新しいERPに刷新していくという大規模なプロジェクトです。先日プロジェクトのメンバーをカウントしたところ、700人いました。 グループグローバルの拠点を含めて700人というのは非常に大きな規模ですし、かつ重要なプロジェクトです。今年度、来年度は、このプロジェクトが施策の中心になる状況です。 ITは入れて終わりではない──「使ってもらえる仕組み」をつくるために ──ITリーダーやマネジメント層に必要な資質とは何でしょうか? 最近、特に注力しているのがコミュニケーションです。IT技術、デジタル技術をしっかり習得して活用するのは私たちのミッションとして当然ですが、IT技術をいかに活用して成果を出すかが鍵だと思います。 ITシステムは「入れて終わり」ではありません。入れて使いこなしてどうか、というところが重要です。 その時、そういった技術を使うのはユーザー、つまり私の職制で言うところのグループ社員です。ですからグループ社員としっかりコミュニケーションできることがポイントだと考えています。ユーザーとコミュニケーションして、「しっかり握る」ためには、「こういうIT技術を使うとこんな効果が出て、このようなメリットがある」ということを実感してもらわなければなりません。そこをしっかりユーザーと握ることが重要です。 そのためには、いろいろな社員とコミュニケーションをすることです。よく「事件は現場で起きている」と言いますが、IT部門は「現場と会話してなんぼの世界」があると思います。そういうコミュニケーションをしっかりできるようにすることがポイントです。 私はいつもメンバーに「現場と会話しよう」と伝えるようにしています。 ユーザーが納得して初めて変革は動く──ITリーダーの使命とは ──これからITリーダーやマネジメント層を目指す人材に求められるスキルは何でしょうか? IT部門の皆さんもさまざまな役割分担があると思いますが、「現場に行く」「会話する」「共感を得る」というサイクルは非常に必要だと考えています。 IT部門のマネジメントには、IT技術も重要ですが、コミュニケーション力や現場力といったスキルをしっかり磨いて自分の業務に活かすことが重要です。そういったマネジメントがこれから求められると思います。 バリューチェーン全体をデジタルでつなぐ──横河電機が描く「次のDXステージ」 ──今後の展望と取り組みをお教えください。 私たちが今目指しているのは、グループ会社がデジタルにつながるところを超えて、関係するパートナー企業やお客さまとつながる──こういったバリューチェーンをしっかりデジタルで実現することです。 これは長期にわたる取り組みになるので、私たちの世代もしっかり取り組まなければなりませんが、次の世代も過去、現在、未来の流れから継続していかなければなりません。その時に、次の世代がきちんと育っていくかということは、私たちの世代の使命だと思っています。 私の部署を見ると、ある世代の人口分布が極端に少ないところがあります。そういうところについてはしっかり採用して育成していく。中長期的に見た時、そこに力を入れないと、連続性のあるIT戦略が実行できないと考えています。 採用については非常に難しいところがあります。製造業に来ていただけるIT人材は限られますから、そういった市場の状況を踏まえてしっかり採用すること、そして採用した後にどう育成するかが重要です。 今、社員に展開している教育は、いわばハードスキルです。それに合わせてしっかりソフトスキルの方も教育していく。将来、横河電機を担えるスタッフ、マネージャーを育てていくことが重要だと考えています。 ——具体的なDXの取り組みについてお聞かせいただけますか。 私たちのDX戦略には2つのDXがあります。一つはインターナルDX、もう一つはエクスターナルDXです。 社内でDXを推進するだけではなく、ビジネス側でもしっかりDXを活用してお客さまに価値あるソリューションを提供しようという考え方があります。 このインターナルDXとエクスターナルDXは密に連携しており、お客さまにDXのソリューションを提案するのであれば、まず社内で成功事例を作って、説得力を持ってお客さまに提供しようと考えています。 インターナルDXでまず社内で実践した上で、その成功事例をエクスターナルに引き継いでお客さまに提供するというつながりがあります。私たちの部隊は今、このインターナルDXのところでさまざまなDX施策を打っています。 具体的な取り組みは大きく2つあります。一つはAIの活用です。社内でしっかり実践してみようということで、2種類のAIの活用を推進しています。ただ、まだ利用が限定的なので、これもしっかり社内で成功事例をつくり、その成功事例を皆で共有し、共感し、成果を出していくという展開になります。 もう一つは、ERPの刷新です。既存のERPから新しいERPに刷新することに、これから数年かけて取り組んでいきます。…

CIOはAI予算をどう捻出しているか——現場で実践される6つの方法

AIへの投資は「どこかから奪う」しかない

予算が増えない中でAIプロジェクトの資金を確保する、これは、ITリーダーの判断力を試す課題となっている。予算制約はこれまでも存在したが、Cレベルの経営層や取締役会からAIを最優先にせよというプレッシャーが加わり、ITリーダーは極度の緊張にさらされている。資金の再配分、システム更新の先送り、ベンダーやツールの統合——リスクとイノベーションのバランスを保ちながら、あらゆる手段を講じなければならない。

「AIへの支出は予算の増加スピードをはるかに上回っている。CIOたちは資金を『見つけている』のではない。他のどこかから『奪っている』のだ」と、Twisted ConsultingのファウンダーでAI・ビジネスオペレーションコンサルタントのKayla Williams氏は言う。「今AIに投じられている資金は、ほぼ例外なく、すでに計画されていた何かの予算を奪っている。それが不都合な真実だ」。

調査会社ISGのディスティングイッシュドアナリスト兼ディレクター、Alex Bakker氏は、優先順位の選択が困難なトレードオフを生んでいると指摘する。「AIを拡大したい組織は、わずかな予算成長分をほぼすべてAIに充てるか、内部予算を再配分するかしかない」。再配分には時間もかかり、古いアプリの廃止や技術的負債の解消といった措置が必要になるという。

Williams氏によると、最も多いパターンは、AIを優先するために長期的な最適化プロジェクトを先送りにするケースだという。「インフラの整理、システムの再構築、緊急でないプラットフォームのアップグレードは、すぐに事業インパクトが見えないという理由で後回しにされている。これらのプロジェクトは重要だ。しかし予算が逼迫すると、短期的な効率化や人員削減を約束するAIが優先される」。

削り方にも変化が見られるようだ。「将来を見据えた完璧な設計より、今すぐ使えるものを——そんな割り切りが広がっている。CIOは規模を絞り、統合も最小限に、カスタマイズも後回しにしてAI展開にゴーサインを出している。技術的負債が積み上がることはわかっている。それでも今は、前に進むしかないというのが現実だ」。

「1四半期で成果を出せなければ凍結」——判断基準を明確に

ビデオ監視技術メーカーIC RealtimeのCTO、Andrew Nassar氏の判断基準はシンプルだ。即座に業務効率の改善を証明できないツールは採用しない。成果が出なければ「凍結」し、判断は原則1四半期で下す。

実際に凍結されたのが、カスタマーサポート向けのチャットボット導入案件だ。パイロットでは顧客がサポート記事にたどり着けず、問い合わせ電話がむしろ増えた。立ち上げには数十万ドルが必要な上、維持・設定・プログラミングを担うチームも別途必要だった。

「(チャットボットプラットフォームを導入し、)スイッチを入れれば動くというものではない」とNassar氏は言う。先送りの判断は予算だけでなく、複雑性とリスクが理由だった。

「AIに1ドル使うなら、どこか別の場所で1ドル削る」——ゼロサムルール

データプラットフォームプロバイダーのUnidataのデータ収集チームリード、Hanna Parkhots氏は徹底的な削減を実施した。データ検証ソフトの予算を40%カット、3つのプロジェクト管理ツールを1つに統合し、年間約4万7000ドルを捻出。AIベースの品質管理ソフトを導入し、データ分析速度を73%向上させた。

最も苦しかったのは、データアナリスト契約社員の予算を30%削減したことだ。約8万5000ドルをAIソフトウェアに充て、残ったスタッフを補完する形にした。災害復旧テストを四半期から半年に変更し、約1万2000ドルも節約した。

「AIに1ドル使うなら、どこか別の場所で1ドル削る」——Parkhots氏はこのルールを社内に徹底している。「習慣でやっていることと本当に価値があることを見直す、ゼロサムゲームだ」。

インフラ投資を12〜18カ月先送り——浮いた予算をAIへ

デジタルマーケティング会社Helium SEOのCTO、Paul DeMott氏は、サーバー容量の拡張とネットワーク改善を12〜18カ月先送りにした。「既存インフラで十分だったから」というのが理由で、IT年間インフラ予算の約30%をAI開発とAPI費用に充てることができた。サーバーは容量の限界近くで稼働しているが、「AIツールが生み出す価値は、パフォーマンスの微改善を上回る」と言う。

DeMott氏はさらに、AIと直接関係のない新機能開発も棚上げにした。「ユーザー体験を段階的に改善する予定だった機能をエンジニアリングリソースのAI統合に充てた。遅延した機能について顧客から問い合わせがあったが、AIツールの可能性を示すと好意的な反応だった」。

ジュニアが上級職の仕事をこなす——リソースモデルの再定義

プロフェッショナルサービスプラットフォームプロバイダーKantataのCISOおよびデータ保護責任者、Taison Kearney氏は、AIが従来のリソースモデルを変えられるかどうかを検証している。具体的には、これまで上級職が担っていた業務をジュニア・低コストの人員がこなせるようになるかどうかだ。「そのシフトがコスト方程式を大きく変え、AI投資の増加を相殺できる」と言う。

同社では社内AIカウンシルを設立し、組織横断的なアイデアを集めている。ツール要件、総投資額、推定ROI、ビジネスケース、内部開発・変更管理の必要量といった一貫した基準で各アイデアを評価する。Kearney氏はこう強調する。「アプローチは単に『予算を増やす』ことではなく、AIが最大の効率改善と測定可能なROIをもたらせる分野に投資を再配分することだ。限られた予算を実験的な取り組みに分散させるのではなく」。

ベンダー統合と契約再交渉——AI費用を捻出するもう一つの手段

AIの普及に伴い、ベンダーの統合と契約の再交渉も進んでいると先述のコンサルタント、Williams氏は指摘する。「重複するツールを積極的に削減し、ライセンス数を減らし、更新を遅らせることでAIプラットフォームやサービスのための余地を作っている。AI支出は、これまで手いっぱいのチームが吸収していた手作業の代替として正当化されるケースもある」。

IC RealtimeのNassar氏は既存のツールスタックを活用してAIプロジェクトに対応し、必要に応じてサブスクリプションを小幅に増やす戦略をとる。「小さく始めて、パイロットが結果を出したらスケールアップする」という考え方だ。今年のAI予算はIT予算全体の5〜10%程度で、来年は倍増か3倍になる見込みだという。

Helium SEOのDeMott氏はさらに踏み込み、ツールスタックを「積極的に」削減・統合してサブスクリプションコストを約40%削減。その節約分をAIプラットフォームとエンジニア採用に充てた。現在のベンダーとは契約を再交渉して好条件を引き出した。

本当のリスクは「何を先送りにするか」ではない

International SeawaysのCIO兼CISOのAmit Basu氏は、問題の本質は別のところにあると指摘する。CIOが苦労しているのは予算の確保ではなく、ガバナンスやリスクへの配慮なしに急速なAI導入を求める経営幹部や取締役会への対応だというのだ。

「既存のKPIはアウトプットを測るが、学習速度やモデルの成熟度、リスクの発見といった指標は測られていない。速く動いているように見えながら、実際の進歩を遅らせている組織がある」とBasu氏は言う。即座のROIが出なければ「失敗」と判定されるパイロットも多く、CIOの本当の課題は予算ではなく「組織が責任を持って対応できる以上のスピードで動くよう求められること」だと言う。

「本当のリスクは、何を先送りにするかではない。適切なガードレールなしにAIが導入されているかどうかだ」。同社ではAI導入の前にインフラ、データプラットフォーム、セキュリティへの投資を優先するケースもある。「AIは、組織が長年必要としていた投資を促す触媒になっている」。

AIに乗り遅れることの方が、大きなリスク

AIの速いペースが予想外の難しさをもたらしているとNassar氏は言う。「来週どんなツールが出るかわからない。それが怖い部分だ」。同時に、AIの加速は無視できない現実だとも認める。「選択肢はない。(AI投資は)人類史上最大の設備投資になるのではないか」。

CIOたちの予算判断は軽々しく行われているわけではないとWilliams氏は言う。「ほとんどのCIOは、今の安定を将来の競争力と引き換えにしているとわかっている。それでも動くのは、AIに乗り遅れることの方が、他のイニシアティブを先送りにするよりもはるかに大きなリスクだからだ。今後れをとれば、追いつくコストは今の比ではない」


Read More from This Article: CIOはAI予算をどう捻出しているか——現場で実践される6つの方法
Source: News

クラウド、DevOps、アジャイルの浸透度:日米SIの開発プロセスと技術選定の差

アーキテクチャ選定の基準が違う

日米のSIを技術面で比べるとき、まず押さえるべきは「何を正解とみなすか」の基準だ。日本のSIでは、長期運用と安定稼働を前提に、障害時の影響範囲が読みやすい構成、監査や手続きが通りやすい構成、運用負荷が予測しやすい構成が選ばれやすい。これはミッションクリティカルなシステムを多く扱ってきた歴史の延長であり、止めないことが最大の価値である環境では自然な選好でもある。

米国のSIでは、クラウドのマネージドサービスを前提に、拡張性と変更容易性を優先する設計が前面に出やすい。もちろん安定稼働は最重要だが、その安定を「事前に作り込み過ぎて守る」のではなく、「計測し、復旧し、改善し続ける」ことで担保する思想が強い。たとえば、単一の強固なシステムにまとめるより、疎結合なサービスとして分割し、障害の隔離や部分的な更新を可能にする。結果として、初期の設計段階から運用の計測や自動化が組み込まれ、アーキテクチャの評価軸に運用指標が入りやすくなる。

この違いは、オンプレかクラウドかという単純な話ではない。日本でもクラウドは普及し、米国でも規制や要件でオンプレやハイブリッドを選ぶ。差が出るのは、技術選定の場で誰が何を判断材料にし、どこに不確実性を許容するかだ。日本では要件を固めて最適解を選ぶ方向に寄りやすく、米国では不確実性を残したままでも動かしながら学習する方向に寄りやすい。ここが、後述する開発プロセスの差にも直結していく。


開発プロセスの中心にあるものが違う

日本のSIが得意としてきたのは、工程を定義し、レビューとテストを積み上げ、品質を管理して納期通りに提供するやり方だ。工程ごとの成果物が明確で、関係者が多くても合意形成を取りやすい。品質の考え方も、仕様への適合と例外処理の網羅、障害の未然防止に重心がある。これは大規模案件で強い。変更が少ないほど強く、変更が多いほど苦しくなる、という性格を持っている。

米国のSIが得意としやすいのは、短いサイクルで価値を届け、実際の利用や運用データから学び、次の改善に反映するやり方だ。ここでの中心は、工程よりもフィードバックループにある。仕様が完全でなくても動くものを早く出し、使われた結果を見て優先順位を変える。そのため、プロジェクト管理も「計画を守る」より「価値が出る方向へ舵を切り続ける」ことに重心が置かれる。

このプロセス差は、アジャイルかウォーターフォールかという言葉の対立で語られがちだが、実際にはもっと深い前提の違いがある。日本の現場は、品質と責任を守るために合意形成を厚くし、合意の外側にある変更を例外扱いしやすい。米国の現場は、変更を織り込み、変更を管理することで責任を果たしやすい。前者は「確定したものを確実に作る」ことに強く、後者は「確定できないものを確かめながら作る」ことに強い。どちらの局面なのかを見極めないと、手法だけ移植しても摩擦が増える。


DevOpsと運用自動化の位置づけ

日米の差が特に出やすいのが、DevOpsと運用自動化の扱いだ。日本のSIは運用に強い一方、運用は「守りの仕事」として位置づけられ、開発と運用の役割が組織的に分かれやすい。結果として、運用の都合で変更が慎重になり、開発は運用に配慮して手続きを増やし、リリースが重たくなることがある。これは責任を果たすための合理でもあるが、変化の速度を求められる領域では足かせにもなる。

米国のSIでは、運用は「価値を作るための継続活動」として扱われやすい。CI/CDやInfrastructure as Code、監視とアラート、ログとトレース、インシデント対応の訓練などが、最初から設計に含まれ、運用の成熟度がプロダクトの競争力に直結するという考え方が強い。運用の目的は、障害をゼロにすることだけではなく、障害が起きても早く検知し、早く復旧し、再発を防ぎ、コストを最適化し続けることへ広がる。つまり、運用の強さがスピードを支える。

日本のSIが持つ運用の強みは、実はDevOps的な方向へ伸ばしやすい資産でもある。強い運用文化があるからこそ、計測と自動化と改善のサイクルを組み込めば、安定と速度の両立が可能になる。ただし、そのためには、運用を「後工程の受け手」に固定せず、開発段階から運用設計を一体化する必要がある。運用手順を増やして安全を担保するのではなく、自動化と可観測性によって安全を担保し、変更の頻度を下げずに守る、という発想転換が求められる。


セキュリティとコンプライアンスの統合

セキュリティや監査対応は、日米ともに最重要だが、プロセスへの埋め込み方に違いが出やすい。日本のSIでは、セキュリティは要件として定義され、レビューやテストで確認し、監査に備える、という流れになりやすい。慎重で堅い反面、セキュリティ確認が開発の後半に寄ると、最後に大きな修正が発生しやすい。結果として、セキュリティが「遅くする要因」として感じられ、現場の心理的摩擦が生まれることがある。

米国のSIでは、DevSecOpsの考え方が比較的浸透しており、コードの静的解析や依存関係の脆弱性チェック、設定のポリシー管理などを、パイプラインの中に組み込みやすい。セキュリティレビューを人の手続きだけに頼らず、ツールと自動化で「守る速度」を上げる発想が強い。さらに、権限管理や鍵管理、監査ログの設計などが、運用の計測と同様にアーキテクチャの評価軸に入るため、設計段階から統合されやすい。

ここでも重要なのは、セキュリティ重視かどうかではなく、セキュリティを速度と両立させるための構造を持っているかだ。日本のSIは、手続きを丁寧に積み上げる強みがある。その強みを活かしながら、自動化できる検査を自動化し、レビューの焦点を「人にしか判断できない部分」に寄せることができれば、セキュリティを高めつつスピードも上げられる。セキュリティはブレーキではなく、安心して速く走るための仕組みとして扱えるようになる。


レガシー刷新の進め方が違う

技術選定とプロセスの違いが最も難しく表れるのが、レガシー刷新、いわゆるモダナイゼーションだ。日本のSIは、既存システムの複雑な業務要件と運用実態を理解し、置き換えに伴うリスクを丁寧に管理することに強い。だからこそ、大規模な刷新では、段階移行の計画、データ移行の整合、周辺システムとの接続、運用引継ぎなど、失敗が許されない論点を網羅しやすい。

米国のSIでは、段階的に価値を切り出しながら移行する進め方がより強調されやすい。既存を一気に置き換えるより、外側から機能を剥がし、API化し、徐々に新しい側へ移す。ここでの狙いは、学習しながら移行し、途中でも価値が出る状態を作ることにある。移行の途中でアーキテクチャや優先順位を変えることを織り込み、投資対効果を見ながら進める。

日本でモダナイゼーションが難しくなりがちなのは、レガシーの理解が深いがゆえに、最初から完全な移行計画を作ろうとしてしまう点にある。もちろん計画は必要だが、計画に時間をかけ過ぎると、移行の価値が出る前に環境が変わる。逆に米国型の進め方をそのまま持ち込むと、ガバナンスや監査、業務の安定を軽視しているように見え、関係者の合意が取れない。両者をつなぐ鍵は、段階移行を前提にしつつ、各段階で品質と運用の要件を満たす設計を最初から織り込むことだ。日本のSIの強みは、ここで活きる。


日本SIが「強みを活かして速くなる」方法

日米の差を埋めるために、日本のSIが米国のやり方をそのまま真似る必要はない。むしろ、日本が得意な品質と運用の強さを維持したまま、速度を生む構造を足していくほうが現実的だ。ポイントは、現場の頑張りで速くするのではなく、標準化と自動化で速くすることにある。

標準化とは、個別案件の事情を無視して共通化することではなく、共通化できる部分を切り出して再利用可能にすることだ。設計の型、環境構築の型、テストの型、監視の型、障害対応の型を整備し、プロジェクトの立ち上がりを速くする。自動化とは、運用の安全を手続きで担保するのではなく、ツールと仕組みで担保することだ。レビューを無くすのではなく、機械的なチェックを自動化して、人が見るべきポイントに集中する。リリースを減らすのではなく、小さく安全に頻繁に出せるようにする。ここにDevOpsと可観測性が効いてくる。

さらに、速度を出すには意思決定の設計も欠かせない。短いサイクルで価値を出すには、優先順位を決める責任者が必要で、変更の判断を迅速に行える体制が必要になる。日本のSIは、合意形成を丁寧に作る力がある。その力を、意思決定を遅らせる方向ではなく、意思決定に必要な材料を早く揃える方向へ使えるようになると強い。品質を守るために止まるのではなく、品質を守りながら進める仕組みを作る、という方向だ。

日米SIの技術とプロセスの差は、結局のところ「変化を前提に設計しているかどうか」の差として現れる。日本のSIが持つ安定と品質の強みは、変化に弱いことと同義ではない。変化を管理し、計測し、自動化し、改善し続ける構造を組み込めば、安定はむしろ速度の土台になる。止めない力を、変え続ける力へ接続する。それが、クラウド以降の時代に日本SIが発揮できる、最も実務的で再現性の高い進化だ。


Read More from This Article: クラウド、DevOps、アジャイルの浸透度:日米SIの開発プロセスと技術選定の差
Source: News

The AI revolution: Getting culture right for AI success

With effective AI implementations likely to separate winning organizations from the also-rans, many IT leaders are taking various approaches to creating workplace cultures that empower nearly all employees to make productive, innovative use of AI. Underlying such strategies is a focus on training, as well as encouragement to experiment with and implement AI in sync…

How Gen Z can win in the AI era

The “digital divide” used to mean unequal access to devices and the internet. Today, that gap has evolved into something more consequential: An AI divide — not about access to tools, but about who knows how to use them well.  In recent months, while mentoring several newly graduated computer science majors, I was struck by…

How enterprises are rethinking collaborative analytics

A persistent gap among C-suite executives shows that enterprises need to rethink traditional data ownership models as they move toward shared decision-making frameworks that better align their analytics strategy and business goals. Why? Simply asking who owns the data isn’t the right question, especially for leaders who want analytics to become a meaningful aspect of…