顧客とともにアイデアを考え、プロトタイプを開発し、検証する
企業は未来を見据え、ビジネスや組織をアップデートする必要がある。新しいビジネスを開拓する、新しいプロダクトを創造することはそう簡単ではない。緻密な計画を立てて、何年もかけてゆっくり進めていては手遅れになってしまう。スピーディーに進めていくには最新のアプローチを用いていく必要がある。伊藤忠テクノソリューションズが提供している「build service」は、顧客企業が推進するデジタルビジネスやデジタルプロダクトを顧客とともに探索し、実装し、発展させていく伴走型のテクノロジーコンサルティングサービスとなる。
当サービスのコアバリューとなるのがアジャイル文化形成。「ともにアイデアを考え、プロトタイプを開発し、検証することでプロジェクトを後押しします」と伊藤忠テクノソリューションズ 小岩井裕氏は言う。
顧客への支援の柱となるのがUXデザイン、クラウドネイティブアーキテクチャ、アジャイルアプローチだ。そのためデザイナーとエンジニアが顧客のチームに加わる。プロダクト開発のフレームワークとして採用しているのはスラローム社が定義しているPEM（Product Engineering Methodology）。大きく分けてプロダクトを検討するディスカバリーフェーズと、プロダクトを開発するデリバリーフェーズに分かれる。
すべてのプロセスに関与するのが小岩井氏が務めるソリューションオーナーとなる。前段のディスカバリーフェーズではプロジェクトマネージャやコンサルタントとして、後段のデリバリーフェーズではスクラムマスターとして動く。「鍵となるのがサーバントリーダーとしての特性である共感、説得、傾聴、気づき、概念化、先見性」だと小岩井氏は言う。
開発の準備期間、ディスカバリーフェーズにおけるポイント5つ
今回の主要テーマはクライアントワークでのデジタルプロダクト検討の進め方と、当サービスのエンジニアリングアプローチの詳細となる。
まずはデジタルプロダクト検討、つまりディスカバリーフェーズの進め方となる。これは次のフェーズとなる開発に着手するための準備期間だ。チームビルディングしながら進めていく。小岩井氏はポイントを5つ絞り、順に解説する。
1点目は顧客のビジネスへの理解。顧客の課題にフォーカスし「なぜその課題を解決したいのか」「背景になにがあるか？」「どのようなビジョンを持っているか？」など質問して、互いに理解を深めていく。顧客が十分にアイデアを深めていない場合には、フォアキャスティングやバックキャスティングのワークを行う。小岩井氏は「ここではチーム全員が“自分事”として検討や開発を進めるマインドセットとリズムを作ります。場合によっては私たちがお客さまよりもビジネスやプロダクトを考えるくらい前のめりになり検討していきます」と話す。
2点目は仮説検証サイクルの定着。新規事業のデジタルプロダクト検討は不確実性が高いことが前提となる。円滑にプロジェクトを進めるためには仮説検証が重要になる。この仮説検証にはデプスインタビュー（一対一の面談形式）やプロトタイプアプローチなどを使い分ける。この結果からMVP（実用最小限のプロダクト）設計やPRD（製品要求仕様書）など継続アップデートを進めていく。仮説検証サイクルは次の開発フェーズでも行うため、ここで定着させていく。
3点目はチームが目指す姿とチームサイズ。共同作業の人数が増えると、1人あたりの生産性が低下すると各所で証明されているため、スモールチームを前提として自己管理型で機能横断型のチームを目指す。チームビルディングは最初が肝心だ。どういうチームを目指すかを最初に定義し、どんな機能や役割が足りないかを明確にしていく。
なおこの段階ではプロダクトオーナーやプロダクトマネージャーだけで検討が進む場合も多いが、ここではプロダクトオーナーに加えてエクスペリエンスデザイナー、ソリューションオーナー、ソリューションアーキテクトが加わるため、全方位をカバーして進めていくことができるようになっている。
4点目は開発に入る前の準備の定義。「何をもって開発の準備ができているか」は事前にチーム内で合意しておく必要がある。主な項目にはプロダクトチャーター、PRD、アジャイルやスクラムの合意形成、デザイン・プロトタイプ、初期のプロダクトバックログがあり、最も重要になるのが技術要件をどれだけまとめ切れているかになる。非機能要件も含めて、アーキテクチャや開発言語、クラウドやツール選定などをきちんと整理していく。
5点目はデリバリーチームへの連携。一般的にディスカバリー（検討）フェーズとデリバリー（開発）フェーズでメンバーが入れ替わることが多いが、ここではディスカバリーチームがデリバリーチームにジョインする。継続したプロセスとして見なす。こうすると重厚な引き継ぎの資料やドキュメントが不要となり、スムーズにデリバリーチームとの共同ワークに移行できる。
なおこのサービスではエンジニアのロールを細分化している。一般的にスクラムでは推奨されていないものの、小岩井氏は「ロールを分けるデメリット（ハンドオフが発生）をチームの横のつながり（文化）でカバーします。またロールを分けることで、それぞれの専門性を伸ばすことを考えています」と狙いを話す。
実現可能性と実行可能性を確立させていくためのアプローチ
ここからはエンジニアリングアプローチの詳細について、ソリューションアーキテクト 羽田野晋一氏が解説する。ソリューションアーキテクトとはプロダクトオーナーの（開発チーム側の）サポートとテックリード（開発チームをサポート）を担う。ここではディスカバリー（検討）フェーズにおける技術要件のとりまとめ方を中心に見ていこう。次のデリバリーフェーズへきちんとした道筋をつけるという重要な役割となる。
ディスカバリーフェーズにおける3つのキーエリアには「DESIRABILITY（望ましさ）」、「FEASIBILITY（実現可能性）」、「VIABILITY（実行可能性）」がある。ソリューションアーキテクトが担当するのは後の2つ。
実現可能性を確立していくためにはアーキテクチャデザインで進めていく。AIやブロックチェーンなど先端技術を利用するケースであればテクニカルプロトタイピングも用いる。なおチームが用いるプラットフォームはAWS、Azure、GCPのパブリッククラウドを対象とし、クラウドを有効活用するためには必然的に分散アーキテクチャとなる。フレームワークやプログラミング言語などはプロダクトに応じて、顧客と相談しながら最適なものを選択している。
忘れてはならないのが「変更を許容することを前提とする」。そのため要件を全部洗い出して完全なアーキテクチャを提示することはなく、機能の重要度とリスクを見極めた重み付けを行う。加えてフォーカスすべき品質特性、例えば機能性、信頼性、操作性などをマイクロサービスごとに洗い出すようにしている。
それからドキュメント。アジャイル開発においてドキュメント作成は縮小傾向にある。なぜならホワイトボードツールなどでアドホックに図式化してコミュニケーションすることが普及してきているからだ。ただしアドホックなので不明瞭な表記やセマンティックになってしまい、後で見ると理解ができなかったり、間違った解釈をしてしまったりするリスクにもつながる。
そこで当サービスではC4モデルを採用している。これはソフトウェアアーキテクチャのモデル化技法の一つで、コンテキスト、コンテナ、コンポーネント、コードで一連の階層構造を持ち、異なるレベルの抽象化を可能とする。C4モデルを採用した理由として羽田野氏は「分散アーキテクチャをサポートしていることと、ライトウェイトで他の表記法と組み合わせることが可能なため」と説明する。またそれぞれの階層が異なる関心事を持つ聞き手に直結しているため、「ステークスホルダーからエンジニアまで利用できる」と羽田野は評価している。
続いて2つめのキーエリアとなる実行可能性について。エンジニアにとっての実行可能性とは「MVPを形にしてユーザーに届けることと、安定した速さで開発を継続してプロダクトの価値を向上し続けること」と羽田野氏は説明する。ここで重要になるのがプロダクトバックログの作成、チームストラクチャの計画、ポイントや期間の見積もり、開発戦略となる。
なお羽田野氏が初めてアジャイル開発を経験したのは10年前。当時はスプリントという短期間で開発することに慣れず、ベロシティが安定せず散々だったという。しかし今では10年の経験に裏付けられたノウハウがある。ソフトウェア開発の複雑さを理解したうえで、テスト自動化やCI／CDなどを採り入れてエンジニアが機能開発に集中できる環境を作りあげている。「アジャイル開発には適切な準備と計画が必要です」と羽田野氏。
