正しいものを正しくつくれているか？

4. 本⽇のテーマ

5. 現実対越境

6. 経産省の「シン・ミラサポ」プロジェクトをリニューアルしたい。・ミラサポとは、助成⾦、補助⾦(合せて⽀援策)の情報提供サイト https://www.mirasapo.jp/index.html ・⽬的や資本⾦、地域などから検索することができる・主に中⼩企業、⼩規模事業者向け・プロジェクトモチベーション - 助成⾦、補助⾦の情報が必要な⼈に伝えられていないのではないか？ - ミラサポをもっと使ってもらえるようなものにしたい - スマホ向けにPUSH通知？ - アジャイル開発で⾏きたい

7. 「アジャイル開発で⾏きたい」

8. 「アジャイル開発で⾏きたい」この⾔葉から分かることが既にたくさんある・「アジャイル開発なら良い感じのプロダクトができる」はずという関係者の暗黙的な期待。・アジャイル開発がどういうものなのか、その意義とは何か、おそらく関係者間のその理解には⼤きなバラツキがある。・真正⾯から ”アジャイル開発” を推し進めたら、おそらく「スプリントの空振り」(準備不⾜で開発できるPBLが無い)か、「最終スプリントでの”コレジャナイ”」(共通認識不⾜のまま時間切れ) になるのが⽬に⾒えている。

9. アジャイル開発 = 早く(少しだけ)形にできる早く少しだけ形にできるのには9つの意義がある

10. 早く(少しだけ)形にできることの意義フィードバックに基づく調整で、⽬的に適したソフトウェアに仕⽴てられる形にすることで早めに関係者の認識を揃えられるつくるものやチームについての問題早く気付けるチームの学習効果が⾼い早く始められる結合のリスクを早めに倒せる Time to market が短いサンクコストが⼩さくできる開発チームのリズムを整えられる ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ https://www.slideshare.net/papanda/ss-79465986

11. 本当に期待と合ってる？はじめての○○ほど、丁寧な期待マネジメントが⼤事。「あなたのアジャイルと私のアジャイルは合っているか？」

12. “アジャイル開発”だけで「何をつくるべきか」が⾒えるわけではない。・フィードバックベースで「つくっているものが合っているか」は捉えられる。(でも、合わせる先のイメージが誰にもまだ無かったら？) ・想定ユーザーの問題を⾒⽴てて、その解決策としてどうあるべきかを構想する⼿段としては、直接的ではない。・つまり、仮説を⽴てて、検証し、「何をつくるべきか」を⾒⽴てる作戦が必要。・「価値探索 (仮説検証)」をプロジェクト活動に組み込む。

13. 仮説検証 + アジャイル開発 = 仮説検証型アジャイル開発この活動がなければ何をつくるべきかが関係者の勘と経験にしか依らない。開発チームもプロダクトどうあるべきという基準が持てない。

14. 価値探索想定ユーザーはどういう状況にあり、何を求めるのか？・まずこのプロジェクトの⽬的や制約について共通認識づくり → 関係者で「インセプションデッキ」づくり・プロダクトについての課題仮説、ソリューション仮説を⽴てる → 関係者で「仮説キャンバス」づくり・中⼩企業、⼩規模事業者、⽀援機関(銀⾏,商⼯会など)などユーザー候補のインタビューイをピックアップ → 関係者で「(想定)ユーザー・インタビュー」の実施 ※各タスクの詳細については書籍『カイゼン・ジャーニー』など参照を。

15. 「提案してー」でも「やってきてー」でもなく「⾃分たちで(も)やる」こと。⾃分の思いを、ビジョンを乗せるプロダクトの⼿応えを感じに⾏くところを⼈に任せてどうする。

16. ⾒えてきた状況と問題

17. ⾃分の事業や会社がどの⽀援策にあてはまるのか調べる⼿間⾃分のやりたいことや困りごとから⼈が代わりに調べて欲しい⽀援策の数が多すぎる⾃分で調べる時間無い、担当置けないタイムリーにキャッチできない網羅的に調べられない他者に相談⽀援をくみあわせて使えない場合があるので、似たようなものがあると困る。どっち使えばいいのか、判断つかない。⽀援策が遠い (分からないから、近づけない) ⽀援策にかける費⽤対効果が割に合わないネット検索 →⾃分で使える⽀援か判断できない⼿続きの煩雑さ (費⽤対効果不明) 網羅的ではなく不満⾜丸投げ出来て満⾜網羅性は諦める /相⼿に委ねる切実な問題準ずる問題代替⼿段

18. 事業⽴ち上げなど⽬的をもって助成⾦、補助⾦を調べる探せない、内容が分かりにくい、当てはまるか分からない⾃分で調べ続けるのが難しい⼈に頼る (⽀援機関、業者) 必要なもののみピンポイントで利⽤する⽀援策=難しいもの近寄らない⽀援策を⼗分に活⽤できない状況に陥るフローあてにしない事業上で必要になったら⼈を頼る業者からの営業網羅的に⽀援策を活⽤できているわけではない。相談する相⼿のやる気と⼒量次第になる。 Start End 他の選択がなくなっていく

19. 「⾃分たちが使えるかどうかが分からない」・助成⾦、補助⾦の内容がそもそも難しい。・条件が複雑で、⾃分たちのやりたいこと、状況に合っているのか判断ができない。・ゆえに⾃分たちだけで探そう、調べきろうとすると⼿間が⼤きい。・専⾨家を頼りたいが、専⾨家も得意な所しか知らない(網羅的ではない)。・いつの間にか募集が公開されている、いつの間にか募集が終わっている。・実はミラサポの(検索⾯での)評価は良い。⽀援策の内容が読み解けない。切実な課題

20. 新しい価値仮説「⾃分で頑張って探す」以外の⼿段を提供する <プラットフォームが探してくれる> - ⾃分のパーソナルな状態 (創業、2年⽬、収益状況etc) を踏まえて、適したタイミング(年度替わり、募集開始締切etc)に、適した情報を届けてくれる = 例えばリコメンド的機能 <他⼈が探してくれる> - 同じ地域、同じ境遇の⼈がよく参照している情報は、⾃分にも必要な情報かもしれない = 例えばランキング的機能「探さない」というアプローチ

21. ソリューションの⽅向性は⾒えた。さあ、プロダクトづくりへ。最初に提供する範囲のMVPを定めて実現のためのプロダクトバックログを準備

22. 現実対越境

23. 2つの問題 ① プロダクトの「全体感⽋如」問題 ② データの境界は「組織の境界」問題

24. プロダクトの「全体感⽋如」問題・開発対象は3アプリ。「シン・ミラサポ」本体、そこからの導線先である、⽀援策検索をする「制度ナビ」また同じく、事例検索をする「事例ナビ」・この3アプリの担当分担、スケジュール的不整合により、ユーザーの統⼀的な体験設計が出来ない状況が不可避に。例えば、 - 会員属性登録をそれぞれのアプリで重複して⾏う必要がある - アプリ間の遷移をなめらかにできない。遷移前の⼊⼒条件が次に⽣きない。ユーザーの体験がアプリで分断される

25. データの境界は「組織の境界」問題・そもそも⽀援策の条件が複雑で、⽂章が国語的に難しい → 表現の改善、条件の明⽰化があらゆるカイゼンの前提と⾔える・ところが、データの更新のためには各主管省庁、⾃治体への問合せが必要であり(そもそも詳細情報の⽂書化にバラツキがある) 内容を整えるのは、スケジュール的に到底不可能であった。⽀援策のデータ的更新が全く容易ではない

26. タイムマシンで遡って⾔えば ① プロダクトの「全体感⽋如」問題 ② データの境界は「組織の境界」問題・3アプリ横断的にマネージするプロダクトマネージャーの設置が必要・3アプリチーム間のコミュニケーションデザインが開始時点で必要こうした視点が「単⼀アプリの開発×3プロジェクト分」という始め⽅をすると誰からも指摘が出来ず、後々での適応ができない (分割の弊害)。理想的なソリューションは何かとか、アジャイル開発とか、以前の問題。・制約を悲観的に捉える(気合でどうにかできる問題ではないという共通理解を持つ) ・そもそも⽀援策制作のガイドライン整備から始める (メンテ⽅法を含めて)

27. ただし、これらは結果論でしかない。「これまでこうしてきた」という他意なき現状維持の⼤モーメンタム (それはつまり国家レベルのだ) に臨むには、関係者全員探索的になる。「⼀体何がどうなっているの？」「どこまで出来るの？」「誰が決められるの？」 Photo credit: Ömer Ünlü on Visualhunt / CC BY

28. 正論が通じないから⽌めるでも終わるでもなく「⾏動で⽰す」が真のファーストなのではないか。⾏動したら「結果」が⽣まれる。その結果は、すべての⼈に残された宿題となる。

29. 2つの問題を解決するのは体制・時間的に困難。プロジェクトとして限定公開のユーザー検証期間に MVP(Minimum Viable Product)を間に合わせるように舵切り。 (つまりプロダクトとしてはまだローンチさせない判断)

30. プロダクトはユーザーの夢を⾒るか？・機能的には「探さないアプローチ」も実装できず。・これでプロジェクトを終えてしまって良いのか？・本当に、次年度に⽀援策データの更新はできるのか？ユーザーの体験は統合できるのか？ 3ヶ⽉でMVPをアジャイル開発プロダクトはアウトプットされたが… Photo credit: mxmstryo on VisualHunt / CC BY

31. 現実対越境

32. ⾃分たちだけで越境できないのなら、ユーザーを巻き込み、ユーザーによる越境を。

33. 3アプリ合同のユーザーテスト実施・⾃分たちの出来てなさ加減を体感する。・「何となく問題がある」という認識では次の越境に繋がらない。 →体感したことを⾔語化し、関係者の共通認識にする。・そして、次年度にプロダクトバックログを残す。ユーザーのリアルな反応を全員で受け⽌める

34. 現実対越境まとめ・「何をつくるべきか」を⾒⽴てるには価値探索(仮説検証)が必要。 (「アジャイル開発=即、良い感じのプロダクト創造」ではない) ・固定的な役割分担や組織の境界が理想的なプロダクトづくりを阻む。・プロジェクト的限界を、プロダクトの限界にしない。・ユーザーの⼒で、⾃分たち⾃⾝を越境させる。・⾏動ファーストで結果(宿題|希望)を残す。(「段階のデザイン」)