不確実なプロダクト開発に、確実な１歩を！

Transcript

1. 不確実なプロダクト開発に、確実な⼀歩を！
2. © build service Speaker 2 有⾺ 正⼈ Masato ARIMA UX Design / UI Design / Service Design Project Design / Workshop Design / Facilitator Experience Designer ⼩岩井 裕 Hiroshi KOIWAI Agile / Scrum / DevOps / Consulting Solution Owner 東海 連 Ren TOKAI UX Design / UI Design / Service Design Project Design / Workshop Design / Facilitator HCD-Net認定 ⼈間中⼼設計専⾨家 Experience Designer モデレーター
3. © build service Opening Talk 3 正解のないDXへの取り組みに、どのようにアプローチすべきか？ 本セッションが取り扱うDXテーマ プロダクト開発・新規事業開発 ＝ 不確実性が⾼い やってみないとわからない • 実現できるのか？ • ユーザーに受け⼊れられるか？ • 継続できるのか？ 変化しつづける環境 • ディスラプターの登場 • 競合他社の動向 • ユーザーの変化
4. © build service プロダクト開発に対するbuild serviceのアプローチ 4 北⽶市場にてDXコンサル/アジャイル開発を軸に成果を上げているSlalom社のメソッド(Product Engineering Method)を採⽤。 Opening Talk
5. © build service プロダクト開発に対するbuild serviceのアプローチ 5 北⽶市場にてDXコンサル/アジャイル開発を軸に成果を上げているSlalom社のメソッド(Product Engineering Method)を採⽤。 Opening Talk “企画ではなく、Discover” クライアントとともに 実現するプロダクトを発⾒する 実現のための しっかりとした準備をする “製造ではなく、Deliver” 市場へ投⼊し、 ビジネスを成⽴させることを⽬的に 開発を実⾏する “運⽤ではなく、 Transition” クライアント主体で ⾃⾛することが⽬的
6. © build service プロダクト開発がつまづくポイント 6 リサーチ 企画 開発 市場投下 フィードバック 企画が うまく進まない アジャイル開発が うまく進まない フィードバックが 反映されない/できない 開発をスタートできない 市場投下の計画不⾜ 体制が作れない フェーズごとに直⾯する課題についてディスカッションします。 Agenda
7. © build service 7 リサーチ 企画 開発 市場投下 フィードバック 企画が うまく進まない アジャイル開発が うまく進まない フィードバックが 反映されない/できない 開発をスタートできない 市場投下の計画不⾜ 体制が作れない プロダクト開発を推進できるチーム/メンバーがいない… Issue # 1
8. © build service 体制が作れない 8 よくある課題 KEY ACTION プロダクト開発に向き合う ü 共同トレーニングやワークショップの開催 ü 調査、分析、現状把握の共有 ü プロダクトコンセプトやビジョンの共有 ü 初期の事業計画 KEY FACTOR プロダクト開発に必要な機能と要素 ü プロダクトオーナー /チーム ü 早めにビジネスチームとエンジニアチームが⼀緒に動く ü アサインするメンバーは稼働100%が前提 オーナーが不在 もしくは兼務をしている.. Issue # 1 社内の合意形成が 出来ていない..
9. © build service 体制が作れない 9 Issue # 1 まずは、専任プロダクトオーナー/チームのアサイン。 KEY POINT 価値観共有 知識レベルを合わせて 価値観を共有 当事者意識 当事者意識を持つ メンバーを選定 専任チーム “専任の”プロダクト 開発チームを作る
10. © build service 体制が作れない 10 プロダクト オーナーがいればいいのか？ Issue # 1 あるプロジェクトで外部パートナーのデザイナーが感じた課題 要件が提供/整理されるのを待っていないか？ ü 要求と⽬的から、画⾯・機能要件を検討出来たほうが良い ü 結局そのスプリントの効果測定はビジネス成果 ü 必要な情報や視界の共有はされているか？ ü 個⼈の⾃律ではなく、ロール(チーム)の⾃律を促しているか？ デザイナーとエンジニアに溝はないか？ ü プロセスとルールなど「共創環境」は整っているか？ ü MTGや細かい確認や詰めのコミュニケーションは？ ü 最終的にはフロントエンドとデザインが機能的に 統合された体制（早い段階での協働）が理想？
11. © build service 体制が作れない 11 Issue # 1 境界線は不要。誰もがプロダクト オーナーの意識を。 プロダクト(開発チームにおける)デザイナーとは、 魂は成果に Committed to outcomes not only 魂を細部に宿す⼈ 実現する⼀⼈ Design the UI system not only 画⾯をデザインする⼈ 伴⾛者 Run with you not only 第３者視点 ・・ ＋ ＋
12. © build service Issue # 12 リサーチ 企画 開発 市場投下 フィードバック 企画が うまく進まない アジャイル開発が うまく進まない フィードバックが 反映されない/できない 開発をスタートできない 市場投下の計画不⾜ アイデアはあるが、、、どれも実現しない… 体制が作れない 2
13. © build service 企画がうまく進まない 13 よくある課題 KEY ACTION 要件定義ではなく「仮説検証」 ü インタビュー ü 顧客体験の把握 ü プロトタイプ活⽤ ü ユーザストーリー ü FS /アーキテクト KEY FACTOR 仮説検証をやらない、やれない理由 ü プロダクトビジョン／コンセプトが曖昧 ü プロダクトが⼤きすぎる、機能が多すぎる ü 最重要な機能がわからない （優先順位がつけられない） ü ペルソナが不明確 ターゲットや 提供価値が曖昧.. Issue # 2 構想が壮⼤すぎる.. 調査/分析に時間が かかりすぎている..
14. © build service 企画がうまく進まない 14 Issue # 2 KEY POINT 企画段階では仮説検証を軸に進めましょう！ UX ユーザー体験を設計 MVP 最低限必要な機能を定義 プロトタイプ アイデアの提⽰
15. © build service 企画がうまく進まない 15 そもそも仮説を⽴てるためには？ Issue # 2 あるプロジェクトで外部パートナーのデザイナーが感じた課題 あとはUXデザインを考えれば…。 ü この技術で、この社会課題を…というよくあるケース。 ü 「その」ユーザーに届けたい価値は？ ü なぜ「変わる（利⽤される）」と考えているのか？ ü 同じ⾔葉でも個々によって解釈に齟齬がでないようにするには 現場の⽅が⾮合理的に考えていないか？ ü この企業のやる強みは？（その規模感の企業がやる強みは） ü 既存事業・部⾨との⼲渉は？ ü 急な共創を強いていないか？ ü 急な変化を強いていないか？
16. © build service 企画がうまく進まない 16 Issue # 2 出発点とは・・ 仮説⽴てには「出発点」が重要。 誰に？ Target Actor not ユーザー / 権限 なにを？ Target Action not 機能 / モノ / 感情 .. なぜ？ Target “Our” Work/Life not 社会課題・組織課題・作 業 ..
17. © build service 体制が作れない Issue # 17 リサーチ 企画 開発 市場投下 フィードバック 企画が うまく進まない アジャイル開発が うまく進まない フィードバックが 反映されない/できない 開発をスタートできない 市場投下の計画不⾜ 3 アジャイルに実⾏する重要性はわかっているけど…
18. © build service アジャイル開発がうまく進まない 18 よくある課題 Issue # 3 パフォーマンスが悪い.. 改善が進まない.. スケールできない.. KEY FACTOR アジャイル/スクラム開発に必要となるエンジニア機能 ü UXデザイン ü ソフトウェアアーキテクト ü クラウドアーキテクト ü 品質/テスト ü CI/CDオートメーション ü フロントエンド開発 ü バックエンド開発
19. © build service アジャイル開発がうまく進まない 19 Issue # 3 KEY POINT チームとして提供出来る機能を確認、アップデートする。 プロセス プロセスを重視 チーム機能 チームとして各機能を 提供できる状態 振り返り 振り返りと改善
20. © build service 不確実なプロダクト開発に、確実な⼀歩を！ 20 開発(Development)の前段階の 基礎的な準備をクイックに整え、 関わるメンバーが共感できる状態に！ 体制 ü まずは、専任プロダクトオーナー/チームのアサイン。 ü 境界線は不要。誰もがオーナーの意識を。 企画 ü 企画段階では仮説検証を軸に進めましょう！ ü 仮説⽴てには「出発点」が重要。 アジャイル開発 ü チームとして提供出来る機能を確認、アップデートする。 体 制 企 画 アジャイル開発
21. © build service build serviceのアプローチ 21 スペシャリストによる専任チームがクライアントと共創し、Discover フェーズを実⾏する。
22. © build service 22 • プロダクト開発＝未来を作りたい！ • もっと多くの⽅と話をしたい！ • build serviceも成⻑させたい！ 相談会の参加やbuild serviceについて 詳しい情報はこちらから https://www.ctc-g.co.jp/solutions/build/ 無料オンライン相談会を開催
23. 免責事項 本資料は、その内容、機能等について細⼼の注意を払っておりますが、内容が正確であるかどうか、最新のものであるかどうか、 安全なものであるか等について保証するものではなく、何らの責任を負うものではありません。 本資料に掲載した情報の訂正、修正、追加、中断、削除等をいつでも⾏なうことができるものとします。 また、本資料のご利⽤により、万⼀、ご利⽤者様に何らかの不都合や損害が発⽣したとしても、何らの責任を負うものではありません。