「まずはやってみよう」の大切さに気づけた話
はじめまして、丸井グループでエポスアプリ担当をしている新井です！
現在所属しているプロジェクトでは、「企画/分析」を主に担うBizSquadに所属しています。
POのザキさんに「アドベントカレンダーやってみない？」とお誘いを受けたので、今回記事を書かせていただきました。
この記事では、今のプロジェクトに参加して最初に感じたモヤモヤと、モヤモヤを解消するためにトライしてきたことをまとめました。
私が所属するプロジェクトについて
まず前提として、私が所属するプロジェクトではアジャイルを用いています。
ただ私以外のメンバー含めてこれまでウォーターフォールしかやったことない為、このプロジェクトではアジャイル経験のあるMutureメンバー伴走のもと進行しています。
プロジェクトキックオフの際、Mutureメンバーから「このプロジェクトはこうやって進めるよ」という勉強会をいただきました。
一部抜粋ですがご紹介させていただきます。
🐣 このPJは「デュアルトラックアジャイル」の手法を用いています
「ディスカバリー」と「デリバリー」の2つのトラックを用意し、それぞれのトラックにおいてアジャイルな価値探索もしくはアジャイル開発を行うことで、双方向的に学びを増やしていくことを目指している。
🐣 「ディスカバリー」は、アジャイルな仮説探索を行っていくTrack。
仮説を立て、検証を行い、コンセプトを立証することが出来たものを「確からしいアイデア」としてDelivery Trackへ連携する。仮説の立て方に画一的な手法は存在しないが、定性/定量さまざまな事実情報を元に、分析を通じて行うことでインサイトを見つけ出していく。
これを聞いた時の率直な感想としては「なんだか難しそうなプロジェクトだなぁ」でした(笑)
他にも
・概念はなんとなく理解したつもりだけど、具体的にどうやって進行するんだろう？
・仮説ってどうやって立てればいいんだろう？
・ディスカバリーの中で、BizSquadが担う役割はなんだろう？
と、具体的に自分がどうやって動いていくかのイメージが沸かずモヤモヤを抱えていました。
「まずはやってみよう」でトライしたこと
生粋の体育会系である私は「やってみてから考えよう」タイプなので、感じたモヤモヤについて、やりながら答えをさがしてみることにしました。
私が具体的にやった３つのことを、以降で書かせていただきます
１）ディスカバリーの全体像を自分の言葉で整理する
ビジネス書や有識者のまとめ記事を読んでなんとなく理解したつもりでも、いざ誰かに説明するとなった時、自分の言葉で話せないってことありませんか？（私はとてもあります）
今回のプロジェクトでもMutureメンバーから知識はいただく一方で、そんなモヤモヤを感じていました。
なので「ディスカバリー」がどのような流れで価値探索するのかを自分なりに言語化・整理しました。
💡 言葉の定義って、とっても大事！
この整理をする中で「課題と問題を同じように捉えちゃうと危険だよ」「仮説も課題仮説とソリューション仮説があるよ」といったアドバイスをもらったので、言葉の定義も合わせて整理するようにしました。
例えば「仮説」だったら
課題仮説：あるべき姿に近づける為の仮説（例：あるべき姿を実現する為には●●をする必要なのではないか？）
ソリューション仮説：課題を解決するための打ち手仮説（例：●●の課題を解決する為には▲▲な機能が必要なのでは？）
２）仮説を一覧化してどれから検証するか決める
このプロジェクトでは毎週月曜日にスプリントレビューを実施しています。
🐣 スプリントレビューとは？
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。 スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
プロジェクト序盤は、スプリントレビューで出た意見を基に「こんな仮説がありそうだから検証していこう」と話していました。
一方スプリントがどんどん回り、仮説の量が増えてきた際「その仮説って今やる必要あるんだっけ？もっと他に優先度高いものあるんじゃない？」と全体感を把握した上での取捨選択が出来ていないことに気づきました。
そこで、ディスカバリーバックログを作成し、スプリントレビューで出たものや日々の対話の中で出た仮説を一覧化するようにしました。
３）検証した仮説は得られた学びとセットでアーカイブする
検証する仮説が決まったら、BizSquadは定量で検証を進めていきます。
これまでの私だったら、思いつくデータをとりあえず出してみるという行動をしていました。（出した結果、「・・・でこの数字で何がいいたいんだっけ？」と沼ることがあった）
検証の進め方についても、Mutureメンバーからのアドバイスをもらい、全体像を表す事実データを踏まえて確かそうな仮説から始めていくという意識を心がけました。
事実データとあわせて検証したことで得られた示唆を、メンバー全員が閲覧できるnotionにアーカイブするようにしました。
トライしたことでわかったこと・気づけたこと
仮説探索に関するわかったことに加えて、プロジェクト進行に関して気づけたことをまとめさせていただきました。
仮説探索に関するわかったこと
💡課題仮説を検証した先に、ソリューション仮説がある
たまにある「▲▲な機能を作った方がいいのでは」と、いきなりソリューションの話をするのはNGだなぁと改めて理解できた。
どんな課題を解決したいのかの要求を整理することがまずは大事だなと感じた。
💡課題仮説を生成するには、正しく問題を捉える必要がある
問題というネガティブな状況に対して、あるべき姿に近づける為の仮説が「課題仮説」という関係性を知ったことで、問題を正しく捉えないと課題仮説の精度も変わることに気づいた。
ただ、なんでもかんでも現状の数字を出すのではなく「●●な課題仮説があるかもしれないから、××の現状を把握しよう」と、常になぜやるのかの思考は大事。
プロジェクト進行に関して気づけたこと
💪 暗黙知をそのままにしない大切さ
社歴が長かったり、以前から一緒に仕事をしているメンバーだと「言わなくてもわかるでしょ」の暗黙知がありますが、それをあえて議論することで実はすり合ってなかったということに気づけた。
💪わからないからこそ、仮説をどんどん検証して知を蓄積する
立てた仮説が外れることは全然ありました(笑)
ただ、大切なのは「仮説を検証してどんな学びが得られたか」だと感じた。 もし仮説が外れても「この仮説は違ったみたい、だったらこの仮説はどうなんだろう？」と、めげずに仮説探求というバッターボックスに立ちたいと思った。
もしかしたらすでに誰かが気づいていて、ビジネス書やまとめ記事を見ればわかったことかもしれません。
ただ、自分でやってみてわかったこと・気づいたことは「自分のものになった感」があり、これからの糧にもなりそうだなと感じました。
最後に
ここまでなんだか偉そうに書いてきましたが、自分がここまで出来たのも、自由にやらせてくれるPOザキさん・意見を遠慮なくくれるチームメンバー・全面的なサポートをしてくれるMutureメンバーのおかげです。
周りの人への感謝を忘れずに、来年も頑張っていきたいと思います！！
長文&拙い文章でしたが、読んでいただきありがとうございました(/・ω・)/
この記事が気に入ったらサポートをしてみませんか？