「絶対止めないで」「来週要件変わるかも」――急速に変化するビジネス要求に応じるための4カ条：レッドハット伊藤氏とマイクロソフト寺田氏が語るクラウドネイティブ（1）

レッドハットでソリューションアーキテクトを務める伊藤智博氏とMicrosoftでクラウドアドボケイトを務める寺田佳央氏が第3回にわたってクラウドネイティブを語る本連載。第1回はIT部門が変化の激しいビジネス要求に応えられるためどう組織を変化させるべきか。

[伊藤智博, 寺田佳央，共著]

　Web系テクノロジー企業の間で取り組みが広まっている「クラウドネイティブ」について、レッドハットのソリューションアーキテクトを務める伊藤智博氏とMicrosoftでクラウドアドボケイトを務める寺田佳央氏が語る本連載。第1回は、クラウドネイティブというメインテーマに入る前に、ビジネス部門とIT部門の変化を振り返る。

ビジネス部門の要求はどう変化しているのか

　ここ数年でビジネス部門からIT部門への要求が大きく変化していると感じている担当者は少なくないと思います。総務省が発行した「令和2年版 情報通信白書」は、昨今のデジタル活用を以下のように記しています。

これまでもデジタル基盤の整備やデジタル技術の活用によるデジタル・トランスフォーメーションを通じて、産業の効率化や高付加価値化が進められ、その過程において、サイバー空間とリアル空間の融合が進んでいった。

人の生命保護を前提に社会・経済活動の維持を図り、未曾有の困難を乗り越えていく観点から、これまでオンライン化があまり進まなかった領域においても、デジタル化の波が押し寄せつつある。

出典：令和2年版　情報通信白書（総務省）より一部抜粋

　つまり、ビジネス基盤がデジタルではなかった企業、産業がデジタルを重視するようになり「ビジネスに投入するまでの時間を短縮すること」「開発したシステムが止まらないこと」「開発と運用のコストを適正化すること」を望むようになってきたのです。

　振り返ってみると、ビジネスの変化が緩やかだった時代、ユーザーの要望は限られていました。時間をかけて要件を定義しシステムを構築することが効率的だとされていました。

　しかし、現在のビジネスは以前と比べて非常に速く変化しています。今日の時点で正しかったことが明日どうなっているか誰にも予測できません。昨今は新たなビジネスモデルで顧客に価値を提供するDX（デジタルトランスフォーメーション）の実現も急務とされ、ビジネス部門の要望も多様化しています。

　ITがビジネスにもたらす影響も変化しています。以前はビジネスに関わる人数の変化も緩やかで、必要なリソースも容易に予測できました。システムが止まったとしても人や紙で代替したり、復旧まで待機したりするだけで大きな問題にはなりませんでした。

　現在はビジネスの中心がITとなり、システムの停止はビジネスの停止に直結します。よくあるのが、SNSなどメディアで紹介されて、一挙に想定を超えるユーザーがシステムにアクセスして停止するケースです。リソースの増強が間に合わずにシステムが停止してしまうと、顧客との接点を失いかねません。結果としてビジネスに対する信頼性の低下、企業評価に対する影響にまで及んでしまいます。こうした状況から、何があってもシステムの停止が起きないようにする、つまり顧客との接点を失わないようにしたいという思いが強くなってきています。また、ビジネスのはやり廃りが激しい中で、ニーズに応じてシステムを変化させたいという思いも強くなっています。

IT部門は開発の姿をどう変化させていくべきか

　ビジネス部門からの要求が大きく変化する中で、IT部門は今後以下のように開発の姿を変化させていくべきだと考えています。

高可用性、変更容易性といった非機能要件に応えられるようにする

　以前はビジネス部門の「絶対に落とさない」「変化に強くする」という要求に対して、高可用構成を目指すと非常に複雑な仕組みが必要になりコストも高くつきました。ビジネスの半ばでリソース量を増減するのはアーキテクチャ的にも難しかったためです。

　ですが、ビジネスをスモールスタートさせて何度もトライ＆エラーをしていくことが一般化する中で、従来通り「ビジネス需要を予測して多くのリソースを確保しておく」のは現実的ではありません。高い可用性を持たせ、柔軟にリソース量を増減できるような非機能要件を満たす構成にしていくことが重要になるでしょう。

1日に複数回のリリースができるようにする

　以前はシステムに対する要求をまとめて開発することが一般的でした。そのため、ビジネスの変化を受けてシステムをリリース（デプロイ）することは1年に数回が限度でした。

　現在はビジネスの変化をすぐにシステムに適用させるため1日に何度もリリースすることが重要になります。とはいえ、以前より複雑さが増すシステム構成や、人や環境などのリソースの調整による待ち時間がある中で1日に複数回のリリースを実現させることは困難です。まずは開発したシステムを円滑にリリースできる環境を用意することが不可欠になるでしょう。

開発組織の縦割り、壁をなくす

　以前からシステムには品質の高さが求められてきました。そのためコストと時間をかけて細分化された開発チームごとに品質に取り組むのが一般的でした。しかし、チームが縦割りになっているため、システムを組み合わせたり連携させたりする際の境界部分の品質が低くなりがちだったのです。

　システム構築の速度を高めることが不可欠になる中で、目の前のビジネス課題に取り組みつつ、システムの品質を高めていく時間も十分にありません。前述した複数回のリリースをただ続けていくと品質は下がってしまいます。

　そのためシステムの幅広い範囲で品質を向上させる方法を検討、実現していくことがポイントになるでしょう。

SIerとの契約形態を見直す

　自社で開発に取り組んでおらず、SIer（システムインテグレーター）に開発を発注していた企業も見直す余地があります。以前はビジネス要件を満たす仕様を決めて、その仕様を満たすシステムをSIerに依頼して一気に作り上げていたはずです。この方法ではビジネス要件に誤りがあった場合、修正が遅れます。そのため、リリース後にビジネスリスクを抱えてしまう他、修正にもコストがかかってしまうデメリットがあります。

　そこでSIerと一定の工数を契約し、その工数内で実現可能な形で要件定義、開発、リリースをする方法が注目されています。一度作って終わりではなく、これを繰り返すため、同じコストでもビジネスの変化に適応しながらシステム構築を実現で見直していくべきでしょう。

筆者紹介

伊藤智博

OpenJDK Committer、Application Services Solution Architect@Red Hat。外資系ソフトウェアベンダでミドルウェアのコンサルタントとしてミッションクリティカルなシステムの支援、テクノロジストとしてビジネス課題を技術で解決をすることを担当して、現職。趣味では主にHotSpot JVMの機能改善に取り組む。業務ではアプリケーションランタイムのミドルウェアの技術プリセールスやJava関連の情報発信を担当。ビジネス目線でのやりたいことや課題から、システムやそのプロジェクトを改善していくことに注力している。