DX白書③～DXを支える手法と技術：開発手法・技術～

現職が多忙で、やっぱり土日にしかなかなか記載できなくなりました。が、しっかりと継続していきます。

ということで今日はDX白書の集大成となる、「DXを支える手法と技術」について記載していきます。ここは「開発手法・技術」と「データ利活用」に分かれるのですが、今回は前者のみ記載します。

企画開発手法

VUCA時代ではニーズが目まぐるしく変化します。そのため、顧客志向とデジタル技術の活用が鍵となります。
そのため、下図のような開発手法が推奨されます。

消費者の本当のニーズを探るデザイン思考・変化する要求に対応するアジャイル開発・アジャイルを支え、運用改善し続けるDevOps体制、そして効率的な開発のためのノーコード（ローコード）、が重要になります。

デザイン思考

共感フェーズ（①）では、ユーザーの顕在／潜在的な状況や思いを理解します（過去から現在までの背景等も踏まえて）。その共感フェーズで気づいた問題を深堀りするのが問題定義（②）です。

そしてその問題を解決するためのアイデアをブレストのように出し、数個に絞っていくのが創造フェーズ（③）です（ここではアイデアの評価はせず、とにかく洗い出す）。

そしてプロトタイプ（④）を作成し、実際にユーザーからのFBを得るテストフェーズ（⑤）を経て、再度上記①に戻ります。
※ここでのプロトタイプは、ある程度しっかりシステム化したものだけでなく、画面だけのモックやペーパープロトタイプのようなものも含めます。

アジャイル開発

アジャイルでは、マネジメント層（組織長や役員）がアジャイルを正しく理解することが重要です。ウォーターフォールのように、「いつ完成か？」「設計書みせてほしい」「この機能はいくらか？」という質問がされると、現場の温度感と差異が生まれるからです。

その防止のため、マネジメント層と現場エンジニアの間にたち、アジャイル開発概要を理解させるプロダクトオーナーが必要になります。

また、全てにアジャイルを使うのは危険です。要件が明確で改修頻度も少ないシステムでは、ウォーターフォールが向いています。

開発チーム（スクラムチーム）も3～9名が適切なため、大規模システムもウォーターフォールが向いている場合があります。アジャイルで大規模を作るには、大規模アジャイル手法（SAFeやLess）を用いて3～9名で対応可能なシステムに分割して取り組むことが求められます。
※その際、小規模アジャイルの成功体験がある場合が望まれます。

中核を担うのはPOとスクラムマスターです。スクラムマスターはサーバント・リーダーシップをとって開発メンバーのコーチングや開発ルール適用等をし、開発がスムーズにまわるようにします。POと開発メンバーの橋渡しになるケースも多いです。

また、スペシャリストが横断チームとして、品質保証や技術リーダーとして助言することもあります。
例：AWSやGCPがアジャイルに役立つサービスリリースしているので、技術リーダーは最先端なそうしたサービスのキャッチアップおよび適用を行う

あくまで開発を外部SIに委託している例の記載

DevOps

DevOpsは開発担当と運用担当がゴールを共有し、テスト／構成管理／デプロイ等の自動化で、スピードと品質を維持した開発を目指します。

上記各工程で開発部隊が個別に自動化をすすめるのではなく、可能な限り全プロセスを一気通貫で自動化することが求められます。
※作業者毎のばらつきなく、高速／高品質な開発が可能になる。

そしてそのコードデプロイプロセスの自動化実現には、「構成管理」と「CI/CD」の２要素が重要です。

構成管理とは、各種設定情報やPJの内外を含めた環境を管理することです。実際の実行環境は多様なパターンがあるため、各ステージで求められる適切な環境を準備することで、誰でも適切なデプロイが可能になります。

CI/CDでは、コード変更された時点で、コードコミットから本番リリース準備まで一気に自動的に行うことです。全てを一気に自動化するのは時間とコストがかかるので、実現可能なところから着手するのが一般的です。

その際、開発者にも設計／コーディングの際にテストを意識させるTDDの実践を導入しつつ、テスターやユーザーと協力してテストシナリオを作ることで、開発者にもビジネス価値の改善の意識を促すことが重要です。

ノーコード／ローコード

ノーコード／ローコードは迅速な開発ができるため、アジャイル／DevOpsと相性がいいです。

ただし、ツール間の互換性がない、標準的なツールもまだ確立していない、業務部門で簡単に作れるため保守管理がされずセキュリティホール生まれがち、といった問題もあります。

なので、費用をかけてシステム化するほどではないが、実現できれば効率化が見込めるシステム（簡易な承認システムや部内の案件管理等）にまず導入し、ツール選定やセキュリティ管理ではシステム部門も入り込むことが求められます。

こうした4つの概念を導入する際は、まずは既存業務への影響が少ないシステムに導入したり、ビジネス部門を巻き込みながらまずは小規模チームでスタートすることが求められます。

ITシステム開発技術

DX推進のためのITシステム開発では、従来の取組とは非連続的な進化を続けるデジタルサービスを用いることが必要です。さらにそこに既存のITシステムも連携させた、全体俯瞰のITアーキテクチャ構想が必要です。

ITアーキテクチャの変遷では、モノリシック構造（密結合）→オブジェクト指向（一つのプログラムをより小さな機能のプログラムの連携とする）と変遷し、そのコンセプトの発展がマイクロサービスアーキテクチャです。

全社業務の効率化を保つ現状維持機能のシステムではウォーターフォールで品質・安定性を重視して、収益拡大用の差別化機能のシステムではアジャイルを採用し、新しいITアーキテクチャの採用が望ましい。

特にクラウド／コンテナ／マイクロサービスアーキテクチャ（およびAPI）の3つに対する理解が重要です。

クラウド

クラウドは品質・コスト・スピードの3つでメリットが強いですが、クラウドエンジニアの不足や、コスト見積もりのノウハウがないなどして、利活用しきれていないケースもあります。
※品質面では、クラウドベンダーのメンテナンス、セキュリティのブラックボックス、ベンダーロックインといったデメリットもあります。

導入には、まずIaaSやCaaSを活用したクラウドリフト（ITシステムの作りはあまり変えず、インフラのみ変革）し、その後DXに最適化されたシステムにアプリも変革させるクラウドシフトを行う順番が一般的です。

なお政府は公共システムについてクラウド・バイ・デフォルト原則を打ち出し、SaaS利用を最優先し、その後IaaS／PaaS、それが無理ならオンプレ利用を検討することとなっている。

コンテナ

コンテナは仮想化かと異なりOSを含まないので、高速な実行環境構築が可能で、スピーディに顧客にシステムを届けるビジネスニーズに適しています。
また、オンプレ／クラウド問わず実行可能です。

多数のコンテナを稼働させる際は、それらを管理するコンテナオーケストレーションツールを用いることで、安定的に実行可能です。
なお、頻繁な変化を持たないシステムでは、仮想化でも十分対応可能です。

マイクロサービスアーキテクチャ／API

マイクロサービスアーキテクチャは、あるサブシステムの変更が他のサブシステムに影響しにくくなることを目的とし、APIによる疎結合を進めたものです。

複数のサービスがAPI連携でのみ通信するようになるため、所要の部分ごとに改修が可能で、システムの改修頻度を高められるようになります。

なおこれもクラウド／コンテナの例に漏れず、導入の際はまずPoCでスモールスタートする必要があります。また、所謂Two Pizza Teamsルール（8名以下）で小規模チームで行ったり、単なるITアーキテクチャとしての採用だけでなく、アジャイル／DevOpsやCI/ CDと組み合わせ、開発スピードを加速化させることが必要です。

開発手法・技術の活用状況と課題

日本ではクラウド領域は少しずつアメリカとの差が縮まったものの、他の部分（特にUI/UX）では大きく差が出ています。

また、日本では共通プラットフォームの利用意向が低いです。これを利用すれば、共通の接続方法やデータの扱いが確立され、コストがおさえられていきます（なお、日本でも例えば経産省主導で水道事業におけるプラットフォーム推進が進められています）。

まとめ

デザイン思考やアジャイル、DevOps、マイクロサービスアーキテクチャ等など、個別概念としては知識はありました。

ただ、これらを全てまとめて、サービスのニーズが不確か×スピーディに変わる現在に活かすための手法としてまとまった概念で捉えるのは非常に納得感があり、DX時代にはどれか一つを作るのではなく、うまく全てを掛け合わせることが重要だと感じました。