近づく”2025年の崖”

フレームワークとコンテナ化事例を基に内製化のヒントが得られるウェビナー
経済産業省が2018年に発表したDXレポートでは、新たなデジタル技術を活用して新規ビジネスモデルを創出する際に、レガシーシス日商エレクトロニクス株式会社とテムが足かせになるという課題が提起されている。
その課題解決の鍵は、"デジタル戦略の内製化"だ。と題
レッドハット株式会社は、「近づく”2025年の崖” フレームワークとコンテナ化事例を基に内製化のヒントが得られるウェビナー」

また、内製化支援について日商エレクトロニクスとレッドハットのチームしてオンラインセミナーを開催し、なぜ"内製化"が重要なのか、で何が実現できるのか、その社会的背景、フレームワーク、事例、そしてデモを交えて解説した。

アウトカムを得るアジャイル開発の活用

Red Hat Open Innovation Labs レッドハット株式会社 シニアソリューションアーキテクト 奥村剛史
■ DX 実現に向けた時間軸と不確実性への対応

今、企業活動の現場では、テクノロジーの急速な進歩に伴って、VUCAの世界、つまり変動性（ Volatility ）、不確実性（ Uncertainty ）、複雑性コーン企業などは、不確実性に対応するために半年、1年のスパンで実行・結果の確認を行います。

アジャイル開発の言葉で表すと、イテレーション（反復）で考え、見直しをし（Complexity）、曖昧性（Ambiguity）に満ちた不安定な状況の中でビジネながら進めていく。DXを実現するには、こうした時間軸、不確実性への対応スを進めなければならなくなっています。

が不可欠です。

3年で見直していた中期経営計画もこうした状況下ではあまり意味をなさなくなり、創業10年以内で時価総額1,000億円以上になった、いわゆるユニ■ ウォーターフォールとアジャイル開発

VUCAの世界において、ソフトウェア開発に求められる要件とは何でしょうか。
まず従来の開発手法であるウォーターフォールについて考えます。工業製品の製造過程のように開発の工程を分けて進捗管理し、早い段階から品トウェアになってしまう、というのがウォーターフォールの欠点です。

次にアジャイル開発について考えてみます。
アジャイル開発の目的は、一般に開発スピードの向上と言われますが、真の目的は反応スピードの向上で質の作り込みを行おうとするウォーターフォール開発は、要件定義、基本設す。反応スピードとは、最低限の価値を満たしたソフトウェアを早く提供して、が行われます。

場の状況を見ながら、機能追加やアイデアのサービス化の判断スピードが向計、詳細設計、開発、テスト、リリースという各工程でドキュメントによる確認機能や使いやすさなどの評価結果を早く知ること。
これにより経営側では、市

しかし、実際には計画通り進みません。不明確なままの要件をベースに基上する。判断スピードが上がると開発スピードの向上も求められる。仮説と本設計する。
詳細設計で誤差が広がる。
違うものが作られる。
違うものが作ら検証を繰り返すことでアウトカム（成果）を見つけ出す。
ウォーターフォールが計画主義だとすれば、アジャイルは経験主義の開発手法だと言えるでしょう。

れるが、計画通りテストが実施され、ソフトウェアがリリースされる。
最終的にリリースされたものは、想定していた要件を満たしていない、使いづらいソフ

Journey Based Services を支える3つのイニシアティブ

Red Hat Journey Based Services はアジャイルコーチによる Open Innovation Labs、全てのテクノロジーの土台となる DevOps プラッ

トフォームの整備をする Container Adoption Program、既存システムのモダナイズに必須なシステムアーキテクチャのマイクロサービスを実現するApplication Migration and Modernization、これら3つは歯車として密接に関わっています。

Application Migration and Modernization

短期間で要件を反映するために相互に影響を受けない疎結合の状態でシステムが成り立つアー
キテクチャでなければならない

アジャイル
開発

マイクロサービス
アーキテクチャOpen Innovation Labs

要件を迅速に反映し、少しでも早くメリットを享受できる（利益を上げる）よう機能を短期間で顧客に提供する開発プロセスであるべき

DevOps
プラットフォーム

Container Adoption Program

開発のあらゆる作業部分でかかっている人的工数、手間を可能な限り自動化し、短期間で継続的にリリースできる仕組み

■ アジャイル開発のためのマニフェストと12の原則

著名なアジャイル開発者らがまとめた「アジャイルソフトウェア開発宣言」

見てスタートしてしまった例が日本では少なくないようです。という文書があります。
アジャイル開発について公式に定義した文書として例えば、開発側（Dev）とビジネス側（Ops）はプロジェクトを通して日々一広く認知されているものです。
この文書ではさらに「アジャイル宣言の背後に緒に働かなければならない、意欲に満ちた人々を集めてプロジェクトを構成ある原 則 」がまとめられており、全 部で 1 2 の 原 則 が 紹 介されています

する、チームがもっと効率を高めることができるかを定期的に振り返って最（https://agilemanifesto.org/iso/ja/principles.html）。

適に調整する、などのビジネスと開発のコラボレーションの重要性を示す原

この原則に日本のアジャイル開発における状況をあてはめると、半分以上則が結果的に軽視されてしまいました。
アジャイルという手法は、開発側だの項目においてうまく対応できていません。
これが日本のアジャイル開発がけでは不可能で、ビジネス側と一体となったチームで進めることが不可欠で失敗した原因と言ってもいい。原則とはその全てを満たさなければ成り立たす。
Red Hat Open Innovation Labsでは、開発とビジネスのコラボレーは開発の後期でも歓迎する、といった開発に関する聞こえのいい原則だけをイル開発を成功に導くサポートを行っています。

ないものですが、価値あるソフトウェアを早く継続的に提供する、要求の変更ションを実現するDevOpsプラットフォームの環境を提供し、お客様のアジャ

新生活様式なDevOpsコラボレーション(デモ)日商エレクトロニクス株式会社 エンタープライズ事業本部 アプリケーション企画開発部 SoEアーキテクト課 原木 翔
アイデアを開発して展開するまでを高速化してユーザーにいち早く価値を調べ、プロダクトの品質を一定に保つための指標にします。
さらに、負担をか提供する手法であるDevOpsの実現には、4つの技術的な要素が必要です。

開発
けることなく継続的に指標が取得できる仕組みを整えます。
第4に共有。

も適用できる考え方と言えます。

じ人を同じ時間帯にアサインできない状況でも情報を交換しやすくするメ者と運用者が情報交換できる場をソースコード管理に紐付けて設けます。
同

これはリモートワークによるチーム連携という働き方の変化、新生活様式にリットがあります。

第1に自動化。
CI/CDによるビルド・テスト・デプロイにより、誰がどのタイミDevOpsはお客様に価値を、継続的に、そして迅速に届けるために、人、ングで実行しても同じ成果が得られる環境を構築します。第2にリーン。自動開発プロセス、プロダクトをコラボレーションすることです。
そしてDevOps化により無駄を省きます。障害発生時の運用者から開発者への引き継ぎでが目指す目標は、高いサービス品質を保つことでお客様の満足度を維持する

は、インシデントチケットを自動作成し、修正対象のプロジェクトに紐付けて、こと。
このスタンスはリモートワーク中心の新生活様式でも変わることはあり開発者がすぐに修正に入れる体制を作ります。

ません。

第3に測定。
あらゆるものを測定可能な状態におくことで時系列の変化をデモでは、郵便番号を住所情報に変換する住所コードAPIサービスが、リクエスト数の増加によりレイテンシーが急激に悪化するインシデントに対し、CI/CDツールとしてOpenShift PipelinesとArgoCDを実行してアプリケーションを自動的に修正する様子が実演された。

OpenShift Pipeline実行中…

● ビルド❸● ソースコードの❶取得❺●

コンテナレジストリへ

E2Eテスト&❹ カバレッジレポート●❷ コンテナタグ作成●
Git hashからpush❻ ファイルを更新●
マニフェストデジタル戦略内製化までの実行プロセス

日商エレクトロニクス株式会社 エンタープライズ事業本部 アプリケーション企画開発部 ビジネスデザイン課 二宮 新
DXレポートで述べられている2025年の崖を解決する鍵は、デジタル戦略内製化を成功に導くステップは３つです。
ステップ1 は戦略策定と戦術計の内製化です。
外部依存型のウォーターフォール開発では、開発サイクルの要画。開発頻度が求められていないシステムは塩漬けし、スピードが必要なも所でシステムインテグレーターなどの外部リソースとのやり取りが発生し、どのはプラットフォームを共通化してアジャイル開発で回すことを検討します。

うしても年単位のプロジェクトになってしまいます。一方、アジャイル開発でステップ2はターゲット設定とチーム組成。開発リードタイム短縮、平均修復位に劇的に変わります。
ここで重要なのは、品質を担保するアウトカムです。

トカムを設定し、利益を生む体制を構築します。
ステップ3ではアプリケーショ

ジェクト単位で大量雇用が必要だった技術者を一定数に絞ることができましてイテレーションするためにアウトカムに対する達成度を計測します。

アイデアの抽出からリリースまでを日や週の単位で回し、システムの企画やジャイル開発による内製化を実現しています。
自社のBPM製品をMicrosoftは、戦略も内製型に変えることで対象抽出からリリースまでのスピードが日単時間短縮、更新時の失敗率低減、デプロイ頻度低減といった測定可能なアウ

戦略内製型のアジャイル開発に変わると、開発サイクルを小さくして、プロン開発を内製化するプラットフォームを用意して開発サイクルを回します。
そす。小さなチームで高速回転させてイテレーションを繰り返します。
ビジネス

当社では、実際にこの手法を使ってレガシーアプリケーションを刷新し、ア設計はテクノロジーで補い、開発は外部リソースを一定数調達するという考Azure 上のRed Hat OpenShift Container Platformに移行し、コンテナえ方です。
このためには外部の専門家とのラボ型契約が有効で、アジャイル技術を活用した新しいアプリケーション開発プラットフォームを構築しまし

開発に必要なコーチングを受けながらイテレーションを繰り返すことで、いつた。
その結果、アプリケーションの構築・展開にかかる時間を92%削減するこの間にか自立した体制が整えられます。とに成功しました。

お客様と描くデジタルジャーニー ３ STEP
STEP

1

STEP

戦略策定・戦術計画“遅い・高い・悪い”を“早い・安い・良い”へ“どのプロダクト（成果物）”から“プロフィット化”するか

新規

SoE※2
アジャイル
シフトする

既存

Modern
SoR

共通化する
塩漬けする

連携
可能にする

効率性を高める

俊敏性を高める

同一環境・技術

SoR※1

2

ターゲット 設定・チーム組成

Agility

Quality

開発
リードタイム削減

平均修復
時間短縮（MTTR）

ビジネスからの要求速度に対応
デプロイ
頻度短縮

更新回数の増加、変動低減

サービス復旧
障害の局所化
更新時の失敗率低減

変更リスクの最小化

Puppet Labsで定義された計測可能なKPI

STEP

3

共創型近代化 PJ“大きく・長 く・踏襲”を“小さく・速 く・柔軟”へ

Agile

（手法）

Architecture（構造）

Platform
（環境）

VUCA

（時代）

弊社提供サービスNatic
EBC

現状の抽出・整理

Discovery
Session

対象・目標の設定

Iterative
Practice

習得まで反復※1 事業で発生する情報を記録するためのシステム※2 顧客とのつながりを構築するためのシステム

お問い合わせの際は、日商エレクトロニクス NADP担当 宛にご連絡ください。

日商エレクトロニクス 〒102-0084 東京都千代田区二番町3-5 三葉ビル6F Web: https://natic.nissho-ele.co.jp/ mail: nadp@nissho-ele.co.jp Tell:03-6272-3034