DXと従来のシステム開発は何が違う？ 開発工程で知っておくべきことをまとめてみた：デジタル変革のメソッド どこから挑む？ どこから変える？（2/2 ページ）

[池田昭規，豆蔵]

アジャイル開発の重要性

　前述の、オーディナリティケイパビリティとダイナミックケイパビリティの観点で考えると、選択すべき開発プロセスは自然と見えてくる。

　銀行の業務といった要求要件が数年にわたりほぼ変わらないような高いオーディナリティケイパビリティを求められる場合はウオーターフォール型システム開発が向いているが、複雑なシステムであれば、着手からリリースまでに数年かかることもある。

図3 ウオーターフォール開発（出典：豆蔵の提供資料）

DXで構築するシステムは、ビジネスの仮説と検証を繰り返す基盤システムとしての役割を持ち、常に新機能の追加や改造を繰り返す。高いダイナミックケイパビリティが求められるため、ショートスパンでリリースを繰り返すことが想定されているアジャイル開発が向いている。アジャイルプロジェクトを行う上でのフレームワークでは、スクラムが有名だ。

図4 アジャイル・スクラム開発（出典；豆蔵の提供資料）

　スクラムは、プロダクトオーナーと呼ばれる役割のビジネスサイドメンバーと、開発者が一丸となって取り組むスタイルだ。スクラムマスターという役割のメンバーも必要で、チームメンバーへのスクラムの理解と実践を助けるとともに、チームが円滑に開発プロジェクトを進めるためのサポートもする。

求められていることへの対策: DevOps／BizOps／BizDevOpsという概念

　これまでの一般的なシステム開発は、要件定義からスタートし、リリース（または納品）することがゴールだった。運用のことは運用者（Ops）が考え、開発者（Dev）は運用を考慮しない傾向にあったと言える。

　開発者と運用者という関係が変わってきた背景として、DevOpsの浸透がある。DevOpsは「開発」（Development）と「運用」（Operation）を組み合わせた考え方だ。近年、プロダクション環境での対応を自分達でコントロールするという、「自分達で作り、自分達で動かす」という概念が登場したことから、開発者には運用設計への関心が求められるようになった。アジャイル開発においては、バックログアイテムの終了条件に「問題なく運用が可能であること」が盛り込まれるケースも多くなり、開発中に運用を考えることが当たり前になっている。開発とテストを並行で実施するCI/CDの手法などへの関心の高まりも、DevOpsと関連性があると言える。

　開発中に考慮すべき運用のポイントは何か。突発的な事象として考えられるのはトラブル発生時の対応だが、トラブルの中身はハードウェアの故障、クラウドサービスの停止、外部からの攻撃やその攻撃に起因したデータ流出の恐れ、処理量の増加によるパフォーマンス低下といったさまざまな要因と事象が考えられる。これら全ての事項のカテゴリーを分類し、対処プランを策定し、実施計画と訓練を行う必要がある。

　他にも、計画可能な事象としては以下の例が挙げられる。

• ユーザーの管理（新規登録や廃止、権限の付け替えなど）
• データキャパシティーの監視やストレージ追加計画と予算策定の根拠データ抽出
• 導入しているプロダクトサービスやクラウドサービスなどのセキュリティ情報の確認やパッチ対応
• 法定点検などによるシステム停止から再稼働時の状態確認やデータ整合性確認

　どの項目がどの状態であれば問題ないのか、項目と項目の相関関係の定義と確認方法はどうするのか――など、考えることは多くある。開発者が個別に対応することは難しいため、非機能要件として別途定義して考慮することで運用の工数を捻出できる。

　では、この非機能要件はどのようにして決めるのか。非機能要件の根本は「ビジネスサイドからの要求を実現するシステムとはどのようにあるべきなのか」であるため、ビジネスサイドからの要求を考える必要がある。ここでBizOpsと言う概念が生まれる。ビジネスサイドと運用者の双方がビジネスに積極的に関与する方法のことだ。

　いわゆる運用者サイドでよく使う指標に、「SLA」（Service Level Agreement） 、「SLI」 （Service Level Indicators）、「SLO」（Service Level Objectives）がある。SLAはビジネスサイドがユーザーと取り決めた約束だ。よく引用される例として、AWS S3のSLAが有名だ。

　ビジネスサイドもいきなり数値化されたSLAを造り出すことはできないので、システムを運用している運用者と相談することになる。運用者は、SLAをビジネスサイドと一緒に定義するためにSLIを定義し、SLOを決め、それをモニタリングする環境を作り上げる。その際、開発者の協力を必要とするケースも多い。さらに、運用者はシステムの正常稼働とともにSLAを守るための活動を行い、状況をビジネスサイドに報告するなどのレポートラインを構築する。

用語解説

• SLA（Service Level Agreement／サービスレベル契約）：利用するユーザーが期待する数値を明確にする
• SLI（Service Level Indicator／サービスレベル指標）：サービスのレベルを保つために計測するべき対象は何かを明確にする
• SLO（Service Level Objectives／サービスレベル目標）：サービスのレベルとしての目標数値を明確にする

　ここまで、DevOpsとBizOpsを簡単に説明したが、さらに協調関係を強化した概念が「BizDevOps」だ。開発者と運用者、さらにビジネス部門を連携させて、生産性を高めると共にビジネスを促進させるという概念だ。

　個人あるいはチームとしてBizDevOpsを実現することが必要だが、既存の組織構造での対応は厳しく、抜本的な組織改造や組織横断型のプロジェクトチームの立ち上げなどが必要になる。ビジネス要求により開発が行われ、開発したシステムをビジネス要求に従って運用し、運用状況をビジネスサイドへ連携することでビジネスを回すという構図だ。

図5　BizDevOps（出典：豆蔵の提供資料）

品質に対する考察

　品質保証は成し遂げるべき重要な事柄だ。品質の確保については、以下のように早い段階からの準備が必要だ。

図6　品質を高めるためのアプローチ（出典：豆蔵の提供）

　シフトレフトテストは、早い段階でテストを実施するアプローチだ。実践プロセスの一つとして、「Wモデル」という概念がある。

　シフトライトモデルは、本番環境でのテスト活動だ。リリースの前のテストとは趣が異なり、リリース作業直後からのシステム稼働状況やユーザーニーズの測定などを重視する。代表的なものを以下に挙げる。

• カナリアリリース：新旧2つのバージョンを同時に稼働させることで、新バージョンのシステムの稼働状況を監視し、徐々にアクセスするユーザーを移すといった移行を進める方式
• ABテスト：若干異なる機能やUIなどを備えたシステムを別途リリースし、ユーザーの反応などを評価する
• 監視・モニタリング：応答速度や性能などの監視を行い、SLI、SLO、SLAなどの項目や数値をモニタリングする
• カオスエンジニアリング：　意図的に障害を発生させ、耐久性を確認する方式。この構想は、CI/CDに加え、CV（Continuous Verification：継続的ベリフィケーション）検証とも言われ、DevOpsのプロアクティブなプラクティスとして、注目を浴びている

　DXを実践するためのシステムは常に変わり続けることが必要であり、シフトレフトテストだけではなく、シフトライトテストに準ずる取り組みが必要不可欠だ。プロジェクト計画時には、品質を確保するための戦略を考慮することも大事だと言える。

おわりに

　DXを支えるシステムは、これまでの「ビジネスを効率化するための便利なツール」とは異なり、「ビジネスを進める上で必要不可欠なパーツ」との位置付けになる。BizDevOpsという用語に込められている「オーナシップを持った取り組み」を常に考え、当事者意識を持った開発スタイルこそが、DXに必要なシステム開発の根底になる。

　DXで利用することが多い「データ利活用基盤」を構築する際には、データの鮮度や正確さ、利用ガバナンスなどへの注意も必要であり、そのための組織や役割の見直しも大事だ。DMBOK（Data Management Body Of Knowledge）などを利用したデータマネジメントの知識とその実践をお勧めする。

　正確な要求を導き出し、価値を提供するためのシステムを開発・運用し、継続的に改良することで、DXプロジェクトを成功に導いてほしい。

企業紹介：豆蔵

情報化業務の最適化とソフトウェア開発スタイルの革新を推進するコンサルティングファーム。デジタルトランスフォーメーション関連ソリューションでは、ビジネスのデジタル化による事業の効率化、競合優位への判断、新製品や新サービスの創出に求められる高度なデータ解析、AI/機械学習に関するコンサルティングや人材育成を提供する。