DX推進｜知る×学ぶ
プロダクト開発において直面しやすい課題｜確実な一歩を踏み出すためのアプローチとは
デジタルトランスフォーメーション（DX）の取り組み領域は広く、その取り組み目的は新しい価値の創造からコスト削減や効率化まで様々だ。
なかでも「プロダクト開発」や「新規事業開発」は、最も難易度が高く、その理由は「不確実性の高さ」である。
そこで不確実なDXの取り組みに、確実な一歩を踏み出すためのアプローチについて、パネルディスカッションが執り行われた。
図 1. パネルディスカッションのテーマ
- モデレーター
- 株式会社セカンドファクトリー
- 有馬正人 氏
- 株式会社セカンドファクトリー
- パネリスト
- 株式会社セカンドファクトリー
- 東海連 氏
- 伊藤忠テクノソリューションズ株式会社
- 小岩井裕 氏
- 株式会社セカンドファクトリー
図 2. モデレーターとパネリスト
パネルディスカッションでは伊藤忠テクノソリューションズ（以下、CTC） Buildサービス推進チーム 小岩井裕氏、株式会社セカンドファクトリー 有馬正人氏と東海連氏が、プロダクト開発において直面しやすい課題を挙げつつ、豊富なノウハウに基づいて、DX推進における推奨事項を提言した。
図 3. パネルディスカッションで取り上げる課題
本記事では、DXの推進やプロジェクトメンバーにアサインされた方に向けて、DXプロジェクトを成功させてビジネスの競争力の優位を確保いただくための参考として、パネルディスカッションの内容をレポートする。
▼目次
・体制がつくれない課題についての対策は？
・企画がうまく進まない課題についての対策は？
・アジャイル開発が進まない課題についての対策は？
・失敗しないために、プロダクト開発で重要視すべきこと
・無料相談会
1. 体制がつくれない課題についての対策は？
Q1-1. 体制作りのポイント
有馬：まずは最も多く相談いただく問題からお話を伺いたいと思います。
セカンドファクトリー 有馬氏
私の経験上、プロダクト開発を推進できるチームやメンバーがいないといった体制に関わる相談をいただくケースが非常に多いのですが、体制に関する課題に、どのようなにアプローチされていますか？
小岩井：お客様からよく伺う課題は、プロダクトオーナーが不在だったり、兼務していてなかなか時間がとれなかったり、社内の合意形成ができない、などがあります。
CTC Buildサービス推進チーム 小岩井氏
こうした課題への対策は「プロダクト開発に向き合う」という意識を持つことが重要だと思います。
例えば、知識レベルを高める為に、関連部署を含めたトレーニングやワークショップの実施、そしてプロダクトコンセプト、ビジョンを作る上での調査、分析、現状把握も必要になります。
また、投資を必要とする為、初期の事業計画作成もプロダクト開発を進める上で重要になります。
そして、これらの活動を進める上で必要となる要素としては、専任プロダクトオーナーや、プロダクト開発に100％コミットする開発チームのアサイン、そして早い段階からビジネスチームとエンジニアチームが一緒に活動できる環境を作ることだと思います。
まとめると、体制作りのポイントは「関係者間における価値観の共有」、「当事者意識を強く持つメンバーのアサイン」、「プロダクト開発専任チームを作る事」の3つになります。
まずは専任のプロダクトオーナーをアサインするところから始めて、そのプロダクトオーナーを中心に広げて行くことを推奨します。
有馬：プロダクトオーナーの役割について伺いたいのですが、一般的なプロダクトマネージャーとは違うのでしょうか？
小岩井：大きな違いは注力する領域が異なるので、必要となる特性やスキルも異なります。
例えば、プロジェクトマネージャーはプロジェクトの進行を重要視しますので、「プロジェクトの時間や予算管理」、「リスク管理能力」が特に求められます。
一方でプロダクトオーナーは開発するプロダクト全体に責任を持つので、企業家に近い動きが必要になります。
その為、「プロダクトが提供する価値」を重要視するプロダクトオーナーには「先見性」や「決断力」が必要なります。
有馬：「プロダクト開発に100%コミット」という部分なのですが、現実的には100%稼働はなかなか難しいといった方がいると思います。プロダクトオーナーがプロダクト開発に100%稼働する必要性はどこにありますか？
小岩井：通常、プロダクト開発は責任が大きく、掛け持ちで出来る活動ではありません。
プロダクト開発のスピードや効率を上げたいのであれば、100％のアサインが必要になります。
ちなみに、アジャイル・スクラム開発は100%稼働を前提とした開発プロセスになります。
スクラム開発で進める場合は、少なくともスクラムで定義されているロールのメンバーは、100%のアサインを必要とします。
Q1-1. 体制作りのポイント
・関係者間の知識レベルを合わせて「価値観」を共有
・当事者意識を持つメンバーの選定し、「プロダクト開発」に向き合う
・専任のプロダクトオーナーのアサインとプロダクトオーナーを支えるチームを形成
Q1-2. プロジェクトメンバーに必要な意識とは
有馬：エクスペリエンスデザイナーとしてプロダクト開発に関わる立場において、チームや体制について、どのような課題を感じていますか。
東海：おおきく2点、「要件が整理・提供されるのを待っていないか」、「デザイナーとエンジニアに溝がないか」といった点が課題になるケースが多いかなと思います。
セカンドファクトリー 東海氏
前者の「要件が整理・提供されるのを待っていないか」という点は、「ビジネス的な目的や効果測定値などは積極的に現場側もキャッチアップする」、「無ければ設定できるように関わる」、「自身も整理・提供する」という意識でスプリントや画面要件定義、UIの定義をしていくべきです。
そのため、デザイナー自らもオーナーの一人として考え、オーナーと一緒に能動的に行動していく必要があります。
待っていても遅くなるだけで進まないですし、チームのメンバーですからね。
後者の「デザイナーとエンジニアに溝がないか」という点においては、「プロセスやルールの擦り合せなどを目的としたミーティングを頻繁に設け、デザイナーとエンジニア間のコミュニケーション機会を意図的に作っていく」ことが重要です。
それぞれの課題や作業に対する考え方を理解して尊重するためですが、これをしていないプロセスやルールは運用されないということを痛いほど経験しています。
プロジェクトにおいてはデザイナーもエンジニアも、プロパーもパートナーも関係なく、ビジネスとプロダクトとサービスに、親身に成功を望む伴走者のひとりとして臨む姿勢、チームに参加する全ての人たちがオーナーという意識が大切です。
有馬：プロジェクトメンバーの意識を醸成していく上で取り組まれていることはありますか？
東海：繰り返しになりますが「密にコミュニケーションをとる」、「頻繁にミーティング機会を設ける」ことが大切です。プロダクト開発は、ひとつの定義、言葉をベースにプロジェクトを進めていきます。個人ごとに使っている言葉の解釈が異なることは自明であるため、メンバー同士のコミュニケーションを重ね、「どういった言葉を」、「どういう意味で」、「どんな背景から使っているのかを理解・尊重する」ことが大切です。
Q1-2. 行動や意識のポイント
・ミーティングを頻繁に設けて、コミュニケーション機会を意図的に作る
・プロジェクトに対して親身に成功を望む「伴奏者」として臨む姿勢
・境界線を作らずに、誰もがプロダクトオーナーの「意識」を持つ
2. 企画がうまく進まない課題についての対策は？
Q2-1. 企画段階のポイント
有馬：企画フェーズについての相談も多くいただくのですが、企画のアイデアはあるけれども、どれも実現しないというような課題について、提言はありますか？
小岩井：プロダクト開発が進まないケースに挙げられる課題としては、「ターゲットや提供価値が曖昧」、「構想が壮大過ぎる」、「調査や分析に時間がかかり過ぎている」の3つを挙げさせていただきました。
これらの課題に取り組むためには、要件定義ではなく「仮説検証」へのアクションがポイントとなります。
ここに挙げたインタビューや顧客体験の把握、プロトタイプ活用といった点は、多くのお客様において認識されてはいますが、実際にはできていないケースが殆どだと思います。
仮説検証が実施できていない理由としては。「プロダクトビジョンやコンセプトが曖昧で仮説を立てる事ができない」、企画に時間をかけすぎてプロダクトが大きくなり過ぎて、「機能に優先順位が付けられない」、「ペルソナが設定できない」などが良くあるケースになります。
このような状況にならないように、企画段階では、「ユーザ体験の設計」、「プロトタイプの活用によるアイデアの提示」、「市場に提供する最低限の機能を定義したMVP」この3つを軸に進めることで、仮説検証を進めることを推奨しています。
小岩井：プロダクト開発では仮説検証とフィードバックが必須です。早い段階において関係者全体で、この点を理解しておく必要があります。
よって、Q1-1にて述べた「関連する部署も含めてトレーニングやワークショップを実施し、知識レベルを上げる準備」がとても重要になるのです。
全体の知識レベルを合わせておけば、仮説検証をやらなくていいよ、という考えにはならないと思います。
仮に「必要ない」という状況になるのであれば、その時点でプロダクト開発を止める事も必要ではないでしょうか。
Q2-1. 企画段階で意識するポイント
・UX、プロトタイプ、MVP定義などの、基本的なプロダクト開発プロセスを実施すること
・仮説検証を初期のフェーズから繰り返し実施して、プロセスに組み込む
Q2-2. 仮説検討のポイント
有馬：そもそも、うまく仮説を活用でいていないお客様も多いと思います。仮説を立てる上での課題とポイントを教えてください。
東海：外部パートナーのデザイナーという点において、現場で感じている仮説を立てる上での課題は大きく2つあります。
先ず1つ目は「UXデザインをするうえでの課題や背景の理解と解釈」です。
例えば UXを検討する上で、お客様に仮説についてヒアリングをすると回答いただけないケースがあります。
仮説を検討するうえで重要なことは、「自分が持っている課題意識がどこに向いているのか」、「誰の課題を改善して」、「誰にどんな価値を届けたいのか」を軸として明確にし、仮説を自身の言葉で言語化することです。
もう1つは現場が非合理的に考えているのではないか、というものです。
「本当にやる意味があるのか」、「既存の事業と干渉しないか」、「現場に急な共創を強いていないか」、「急な変化を強いていないか」といった内容を客観的に問いかけることで、合理的な進め方が可能になるのではないでしょうか。
仮説を検討する際には最初に「誰に対して」「どのような価値を」「なぜ提供するのか」と言う「組織の活動の出発点」を作り、そこを起点に進めることが重要だと思います。
有馬：仮説立てのために「Business Model Campus」などをワークショップで書いては見たものの、なかなか効果の出るアウトプットにつながらないというケースも多く見られるようです。そのようなアプローチはどう考えられていますか？？
東海：そういったまとめ方やワークショプが無駄だとは思いませんし、実際にそういった手段でクライアントとワークするケースもあります。ただ、書くことがゴールではないので、きれいにまとめる必要はないです。
重要なのは、きれいなアイデアが描かれることよりも、チームでの文脈形成と言葉を交わして理解を深めて、見えなかった視点に気づくことや、チームの方向性がそのキャンバスなどの中で更新され続けるコミュニケーションツールになることです。
あくまで手段・道具なので、うまく使う必要があると思っています。
Q2-2. 仮説検討のポイント
・仮説検討に必要となる課題や背景を自分の言葉で言語化すること
・最初に「誰に対して」、「どのような価値を」、「なぜ提供するのか」と言った「活動の出発点」を作る
・キャンパスはコミュニケーションツールとして「上手く活用」する
3. アジャイル開発が進まない課題についての対策は？
有馬：企画からものつくりのフェーズに進んだとしても、なかなかアジャイル開発が進んでいないケースが多くあります。この点について対策はありますか？
小岩井：よく聞く課題としてはパフォーマンスが悪いとか、改善が進まないとか、スケールできない、といった点です。
アジャイル、スクラム開発におけるエンジニアには、複数のスキル（機能）が必要になります。そのため、スキル（機能）を有するエンジニアを揃える体制作りは非常に重要になります。このスキル（機能）がある事を前提に、開発プロセスの確立や定常的な振り返りと改善をする事で、チームのパフォーマンスが向上します。
東海：振り返りも重要だと思います。
例えば、ワイヤーフレームでモックアップを作ってから、要件を詰めていくように、アジャイル開発でも、ちょっと試してから改善していくというひとつひとつの振り返りが大切です。
仮設を立てて検証する考え方をチームで取り組んでいくべきです。
Q3. アジャイル開発のパフォーマンス改善のポイント
・チームとして提供出来る機能を確認し、アップデートし続ける
・エンジニアの「学習」も重要だが、「スピード」を意識することも重要
・「振り返り」と「改善」を繰り返し、仮説検証の進め方を確立する
4. 失敗しないために、プロダクト開発で重要視すべきこと
有馬：ここまでのディスカッションにより、不確実なプロダクト開発においては「開発に進む前段階の整理・準備、体制作り」が重要であることがわかりました。CTCが提供するDX推進支援サービス「build service」では、不確実性が高いプロダクト開発に対し、どのようにアプローチしていますか。
小岩井：build serviceではスラローム社の独自のフレームワークを採用しています。米国スラローム社とは、米国市場においてDXコンサル、アジャイル開発を軸に多くの実績がある企業になりますBuildチームのメンバーは2019年から今年にかけて約6か月間、シアトルにあるスラローム本社で共同開発を進めてきました。この時に出会ったフレームワークがPEMになります。
図 4. PEM (Product Engineering Method)
PEMは4つのフェーズで構成されており 最初の段階であるEngageフェーズでは、プロダクト開発の理解を目的にトレーニングやワークショップを実施し、知識レベルを上げる段階になります。
Discoverフェーズはbuild serviceの1つの特長で、CTCとお客様が密にコミュニケーションを交わしながら実現するプロダクトの発見に時間を使い、プロダクトの実現に向けた準備を行います。
次のDeliverフェーズは開発段階になりますが、ものづくりだけではなく、お客様からのフィードバックを貰いながら、スクラムのスプリントを回していきます。
最終段階のTransitionでは、最終的にお客様が自走できるように支援します。本サービスは「内製化支援」として提供しているため、お客様のチームビルディングやスキルトランスファーも実施します。
このbuild serviceのフレームワークにより、お客様が不確実なDXに確実な一歩を踏み出せるように支援しています。
図 5. build serviceの段階概要
CTCのbuild serviceの詳細は以下よりご覧いただけます。
さいごに
パネルディスカッションでは不確実なプロダクト開発において生じる課題と対策について、参考となる意見を伺うことができた。
図 16. 不確実なプロダクト開発においては「開発に進む前段階の整理・準備、体制作り」が重要
今回はありがちな課題の一部が挙げられたが、実際の現場では他にも様々な課題を抱えているだろう。
CTCは新規事業の立ち上げやDXプロジェクトの推進を阻む課題の解決に取り組まれている方との対話の機会を設け、DXの支援事例のご紹介、DXプロジェクト推進に関する相談会、Q＆Aを無償で提供している。
DXプロジェクト推進の支援を行ってきた専門家と、課題解決への第1歩を共に踏み出したい方は、下記よりCTCに相談してみてはいかがだろうか
尚、パネルディスカッションで使用した資料は、以下よりご覧いただくことができる。