実現可能性と実行可能性を確立させていくためのアプローチ
ここからはエンジニアリングアプローチの詳細について、ソリューションアーキテクト 羽田野晋一氏が解説する。ソリューションアーキテクトとはプロダクトオーナーの（開発チーム側の）サポートとテックリード（開発チームをサポート）を担う。ここではディスカバリー（検討）フェーズにおける技術要件のとりまとめ方を中心に見ていこう。次のデリバリーフェーズへきちんとした道筋をつけるという重要な役割となる。
ディスカバリーフェーズにおける3つのキーエリアには「DESIRABILITY（望ましさ）」、「FEASIBILITY（実現可能性）」、「VIABILITY（実行可能性）」がある。ソリューションアーキテクトが担当するのは後の2つ。
実現可能性を確立していくためにはアーキテクチャデザインで進めていく。AIやブロックチェーンなど先端技術を利用するケースであればテクニカルプロトタイピングも用いる。なおチームが用いるプラットフォームはAWS、Azure、GCPのパブリッククラウドを対象とし、クラウドを有効活用するためには必然的に分散アーキテクチャとなる。フレームワークやプログラミング言語などはプロダクトに応じて、顧客と相談しながら最適なものを選択している。
忘れてはならないのが「変更を許容することを前提とする」。そのため要件を全部洗い出して完全なアーキテクチャを提示することはなく、機能の重要度とリスクを見極めた重み付けを行う。加えてフォーカスすべき品質特性、例えば機能性、信頼性、操作性などをマイクロサービスごとに洗い出すようにしている。
それからドキュメント。アジャイル開発においてドキュメント作成は縮小傾向にある。なぜならホワイトボードツールなどでアドホックに図式化してコミュニケーションすることが普及してきているからだ。ただしアドホックなので不明瞭な表記やセマンティックになってしまい、後で見ると理解ができなかったり、間違った解釈をしてしまったりするリスクにもつながる。
そこで当サービスではC4モデルを採用している。これはソフトウェアアーキテクチャのモデル化技法の一つで、コンテキスト、コンテナ、コンポーネント、コードで一連の階層構造を持ち、異なるレベルの抽象化を可能とする。C4モデルを採用した理由として羽田野氏は「分散アーキテクチャをサポートしていることと、ライトウェイトで他の表記法と組み合わせることが可能なため」と説明する。またそれぞれの階層が異なる関心事を持つ聞き手に直結しているため、「ステークスホルダーからエンジニアまで利用できる」と羽田野は評価している。
続いて2つめのキーエリアとなる実行可能性について。エンジニアにとっての実行可能性とは「MVPを形にしてユーザーに届けることと、安定した速さで開発を継続してプロダクトの価値を向上し続けること」と羽田野氏は説明する。ここで重要になるのがプロダクトバックログの作成、チームストラクチャの計画、ポイントや期間の見積もり、開発戦略となる。
なお羽田野氏が初めてアジャイル開発を経験したのは10年前。当時はスプリントという短期間で開発することに慣れず、ベロシティが安定せず散々だったという。しかし今では10年の経験に裏付けられたノウハウがある。ソフトウェア開発の複雑さを理解したうえで、テスト自動化やCI／CDなどを採り入れてエンジニアが機能開発に集中できる環境を作りあげている。「アジャイル開発には適切な準備と計画が必要です」と羽田野氏。
