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

「正しいものを 正しくつくれているか？」 プロダクトづくりにおける真の問題は何か 経産省プロジェクトでのアジャイル開発 Ichitani Toshihiro Toshihiro Ichitani All Rights Reserved. 市⾕聡啓

市⾕ 聡啓 Ichitani Toshihiro (My KeyWord) 越境 正しいものを正しくつくる 仮説検証型アジャイル開発 Toshihiro Ichitani All Rights Reserved.

Profile https://ichitani.com/ Toshihiro Ichitani All Rights Reserved.

• https://ichitani.com/

本⽇のテーマ

現 実 対 越 境

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

• https://www.mirasapo.jp/index.html

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

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

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

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

• https://www.slideshare.net/papanda/ss-79465986

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

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

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

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

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

⾒えてきた状況と問題

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

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

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

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

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

現 実 対 越 境

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

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

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

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

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

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

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

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

現 実 対 越 境

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

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

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

Toshihiro Ichitani All Rights Reserved.

『正しいものを正しくつくる』 プロダクトをつくるとはどういうことか、あるいはアジャイルその先へ 2019年6⽉中旬予定 Amazonで予約開始 https://www.amazon.co.jp/gp/product/4802511191 Toshihiro Ichitani All Rights Reserved.

• https://www.amazon.co.jp/gp/product/4802511191