識別した技術リスクには、計画的に対処をしていく。リスク対処の方法は、複数のアプローチがある。「設計」「プロセス」「事前検証」の3ジャンルに分け、七つの現場ノウハウを紹介する。識別した技術リスクの重大さ、ユーザーとの関係性に応じて手法を組み合わせよう。
設計編1：新技術の適用範囲を局所化
「新技術の適用範囲を局所化して、全体の2～3割に抑えるのがよい」。電通国際情報サービス（ISID）の若本航太氏（コミュニケーションIT事業部 ビジネス系ユニット マーケティングIT部 PF開発グループ グループマネージャー）はこう指摘する。
局所化に必要なのが、システムをいくつかの部分（サービス）に分割し、サービス同士を疎結合にするアーキテクチャーを設計することだ（図1）。若本氏は「技術リスクのコントロールに悩み、5年ほど前にたどり着いた。今風に言うとマイクロサービスアーキテクチャーになる」と説明する。
若本氏が手掛けたECサイトの拡張プロジェクトの実践例を見てみよう。ECサイトには「キャンペーン時に急増するアクセスを処理できる必要がある」という、特有の要求があった。この要求を満たすため、若本氏はオープンソースのJavaフレームワーク「Vert.x」の採用を提案した。少ないリソースで、多数のリクエストを処理できるのがVert.xの特徴だ。
ただし、若本氏のチームではVert.xを使った経験がなかった。技術検証は実施していたが、細かい点の実現可能性やチームとしての開発生産性に対するリスクが高かった。
そこで、システムを「注文サービス」「管理画面サービス」「バッチサービス」の三つに分割して設計。Vert.xの利用は、エンドユーザーからのリクエスト処理を担う注文サービスに限定した。サービス間はREST APIを通じて通信する。
管理画面サービス、バッチサービスは使い慣れた技術で実装することにした。これらは、特別な要求がある部分ではないからだ。管理画面では、フレームワークにRuby on Railsを採用し、蓄積したノウハウを使えるようにした。
スキルリスクへの対応策にもなる
新技術の適用範囲を局所化するメリットは大きく二つある。
一つめは、新技術が原因でトラブルが生じても、ほかへの波及が限定的になることだ。技術リスクが顕在化しても、課題対処が必要になる範囲を小さくできる。
二つめはスキルリスクに対処できることだ。未経験の技術を素早く学習して設計、実装を進められるエンジニアは多数派ではない。若本氏は「経験則では2割くらい」と話す。新技術の利用を局所化しておけば、新技術を活用して野心的なサービスを開発する役割、使い慣れた技術で堅実にサービスを開発する役割、と分けてエンジニアをアサインできる。