■おすすめ企業

build service- vol.05「プロダクト開発の全プロセスに関わるキーロール、ソリューションオーナーとは？」伊藤忠テクノソリューションズ小岩井裕

2021.07.06 2024.01.22 約4分

世界でも先進的なDX事例として高い評価を得ているスラロームコンサルティング社（Slalom Consulting,以下、Slalom）が策定したアプリケーション開発の内製化手法「PEM（Product Engineering Methodology）」は、AWS（Amazon Web Services）やマイクロソフト、スターバックスなど多くのグローバル企業が採用する注目のフレームワークだ。

この手法をベースとしたデジタルトランスフォーメーション（DX）支援サービスを展開するのが伊藤忠テクノソリューションズ株式会社（CTC）。

CTCが提供する『build serivce』を紹介する連載の5回目は、ソリューションオーナーについて。ほぼすべてのフェーズに深く関わるソリューションオーナーとは一体どんなロールなのか？　Buildサービス推進チームでソリューションオーナーを担っている小岩井裕氏に話を聞いた。

プロダクトマネージャーやプロダクトオーナーを支援するソリューションオーナーとは何か？

「お客様のプロダクトオーナー、プロダクトマネージャーの支援をすることが最大の役割です」

小岩井氏は、自らの担う役割をこう説明する。

「我々が提供するBuildサービスは、プロダクト開発支援であると同時に、お客様との事業開発、共創プロジェクトでもあります。サービスを円滑に進め、成果に責任を負うのがソリューションオーナーと思ってもらえれば」

小岩井氏の言葉通り、ソリューションオーナーは、それぞれのタームでさまざまなロールが有機的にタスクを遂行するBuildサービス全体を包括的に見る役割を持つ。Buildサービスの詳細については、過去4回にわたって紹介してきた記事を参照いただきたいが、世界でも特筆すべき結果を残しているアメリカ・スラロームコンサルティング社（Slalom Consulting,以下、Slalom）のDX導入コンサルティングをお手本にしたBuildサービスのキモは、PEM (Product Engineering Method)と呼ばれるフレームワークに依るところが大きい。

PEMの大きな特徴の一つに、プロジェクト全体を①プレセールスに当たる『ENGAGE』、②クライアントとビジネス要件を議論し、実現可能性を検証する『DISCOVER』、③エンジニアがアジャイル開発を担う『DELIVER』、④クライアントの自走を支援する『TRANSLATION』の四つのフェーズに分割し、スペシャリストが明確なロールと責任を持って個別のフェーズに関わるというフレームワークがある。

これまで各フェーズの実務担当者に生の声を聞きつつ、PEMの開発プロセスを見てきたが、ソリューションオーナーを「唯一全フェーズ、すべてのプロセスに絡んでいるロール」と説明する。

アジャイル開発は魔法の杖ではない　最重要課題は「期待値コントロール」と「合意形成」

CTCがサービスを提供し、すでに稼働しているプロジェクトを例に、ソリューションオーナーの働きぶりを見てみよう。

①ENGAGEのフェーズでは、場合によっては営業活動領域から提案支援に入る。Buildサービスの概要、特徴、従来のサービスとの差異などを伝え、クライアントに正しい理解を促す。

「Buildサービスの内容だけでなくプロジェクトのアプローチや進め方、最終的にお客様がどのような価値を獲得できるのかを理解してもらいます。今までのRFP提案の形式ではなく、お客様と時間をかけて実現したい内容やイメージ合わせを進めて行くので、ここでどれだけBuildサービスに共感してもらえるかがプロジェクトの成否につながると考えています」

続いて②DISCOVERのフェーズに入るのだが、ENGAGE、DICOVERのフェーズを通じてソリューションオーナーが担う重要な“使命”が「期待値コントロール」だ。

Slalom社が実践するPEMは、優れたフレームワークではあるが、CTCにすべて投げてしまえばすべてやってくれるSI型のプロジェクトではない。AWS（Amazon Web Services）やマイクロソフト、スターバックスをクライアントに持ち、北米で大成功を収めたSlalomのフレームワークという売り文句はそれだけで魅力的だが、導入しただけですべてがうまくいく魔法のソリューションはこの世に存在しない。

「プロダクト開発では、検討範囲の幅が非常に広く、実際に開発に入る前の準備がとても重要になります。アジャイル開発だからといってトライ＆エラーを前提に開発に着手することは通常しません。また、すぐに望むものができるという誤解もあります。開発には環境やリソース、スキル、ステークホルダーの理解度や協力体制などが必要になってきます。このあたりの感覚や認識合わせは常に意識しています」

アジャイル開発の現場では、期間を決めず走りながら考えるというイメージを持ちがちだが、MVP (Minimum Viable Product)を採用し、フェーズを区切ることで成果を最大化するPEMではプロダクトの開発イメージを共有する合意形成が欠かせない。

また、エンジニアがさまざまな機能を実装し、プロダクトを完成していく上で、ENGAGE、DISCOVERフェーズでクライアントの「期待が膨らみすぎないように」コントロールすることも求められる。

「DISCOVERフェーズでは、お客様に必要なプロダクトを文字通り発見していく作業が続きます。その中で、お客様側のプロダクトオーナーやプロダクトマネージャーが、『なぜつくるのか』「何をつくるのか』にフォーカスして整理することで意思決定プロセス形成を支援し、ステークホルダー含めて合意形成しながら進めることがソリューションオーナーの重要な役割です。　

初めてプロダクト開発に携わる、これまではウォーターフォールで開発を進めていましたというお客様ではどうしても『いつまでに完成するのか』、『どのようにつくるのか』にフォーカスしてしまいます。　当然、この観点もとても重要にはなるのですが、より『なぜ』と『何を』に価値を置いて検討を進めることの重要性を理解して頂き、期待値を合わせながらプロジェクトを進めることを意識しています」

期待値コントロール、合意形成のために必要なのは「クライアントと最低限の知識レベルを共有すること」。クライアントに対しての丁寧な説明、時にはトレーニングを行うことでプロダクト開発への理解を深め、共感、共有、課題の可視化を図る。

「具体的にはこのフェーズは３つのステップで構成されています。ステップ１ではお互いの『学習、理解』を目的にインタビューやユーザ分析、必要な場合はトレーニングを実施します。ステップ２は『アイディエーション、定義』をワークショップ形式で進めます。ここではより具体的なイメージ共有をするためにプロトタイプを活用します。また、技術的な実現性検討もこのステップからスタートします。ステップ３は「計画策定」となり、開発に入るための準備とMVP（Minimum Viable Product)の定義、コミュニケーションツールとしてのロードマップまで落とし込みます。

お客様にも十分な理解、正しい理解の下に合意してもらって、我々はプロダクト開発に責任を持つ。ここまでやってようやく実際の開発となるわけです」

開発期はスクラムマスターとしてエンジニア組織に寄り添う

DELIVERフェーズでのソリューションオーナーは、いわゆるスクラムマスターとしての動きが主になる。開発の初期フェーズは、クライアントとの合意に基づいたプロダクト開発のためエンジニアチームに寄り添って仕事を進める。

「開発のリズムやパフォーマンスが安定し、ビジネスが軌道に乗ると、プロダクトのエンハンスを加速する必要性が高くなります。　ソリューションオーナーとしては徐々にお客様の内部にアプローチする必要が出てきます。お客様側のプロダクトオーナー、プロダクトマネージャーと一緒にどういうアプローチでチームを拡張していくかの検討を進めます。このタイミングでTRANSITIONの検討をスタートし、お客様が自走式でプロダクトを運営していくための体制構築支援に移行していきます」

顧客の持つ未知の価値を発見し、そこに寄り添いながらMVPを策定する。CTCのエンジニアが中心になってアジャイル開発を進め、最終的にはクライアントが自力で運営できるサービスとして受け渡す。従来のSIerの動きとはまったく違うサービスだけに、従来型のスクラムとは少し流れが違う点もあるという。

「元来、アジャイル開発、スクラム開発については、優れたフレームワークなのでスクラムガイドを崩さず原理原則を忠実に実行してこそ意味があると思っているのですが、PEMの開発プロセスでは、『ロールを分けている』という部分に大きな違いがあるんです。プロダクトオーナーとスクラムマスター、エンジニアによる開発チームで構成されるスクラム開発に対して、PEMでは、エンジニアをデザイン、バックエンド、フロントエンド、クオリティー、ソリューションアーキテクトみたいな形で細分化しているんです」

役割が細分化していることは責任の所在が明確化され、人材のスケールがしやすいメリットがあると同時に、チームが機能カットになりやすいというデメリットがある。これを防ぐために、チーム力、組織力を発揮するためのカルチャーの形成が必要不可欠だ。

「Slalomで研修をしたときも、そこの実際のオペレーションをどうしているのかなというのは一番見たかったポイントだったんです。特別『これをしている』というのはなかったのですが、とにかくカルチャーの形成にはエンジニア、非エンジニア含めて徹底していました。機能カットによるデメリットをコミュニケーションを重視した組織のカルチャーによりチーム内での効率的な連携を実現してカバーしているんですよね。そこの部分には人事採用の適性から遡って徹底されていました」