チームビルディングWebアプリの企画からプロトタイプ検証まで

現在、オンラインでのチームビルディングを支援するWebアプリケーションサービス「We’re Fake – 偽りのチーム・ビルディング（仮）」を開発中です。

本記事では、サービスの開発の過程で経験した企画からプロトタイプ開発、そしてプロトタイプを使った仮説検証について、プロダクトオーナーの目線でまとめます。

10月3日〜10月20日　テーマの探索

10月、私たちのチームはこれから何をするか、自分たちでテーマを考えることから始めました。

メンバー個々の期待をヒアリングし、ラボや会社からの期待も考慮して、チームのミッションをチームで決めました。

開発メンバーはWebアプリケーション開発を経験してスキル習得することを目指して、プロダクトのプロトタイプ開発を優先する。並行して、想定ユーザーの課題の仮説、及び開発するプロダクトが提供する価値の仮説を立てて、検証を計画・実施する。このように、チームのミッションとプロジェクトの進め方について、開発メンバー、プロダクトオーナー、ステークホルダー（ラボの室長）で認識を共有しました。

テーマの探索を始めました。

ミッションを達成するために、Webアプリケーションを開発してユーザーに提供する価値を仮説検証できることが重要です。しかし、テーマは真っ新な状態で、想定するユーザー状況やビジョン、前提となる技術のいずれも制約がありません。

テーマ探索のためにとったアクションは、個人で調査して、思いつき次第アイデアを挙げるというものです。各自が自身の興味に沿ってアイデアを出し、意見交換会を毎日開催しました。意見交換会では、他の人の意見に乗っかってアイデアを発展させることで、フワッとした思いつきから想定ユーザー課題に結びつけたソリューションのアイデアに育てることを狙いました。

このような調査と意見交換会を5日間実施した後、いくつかのアイデアについて仮設キャンバスを作成しました。

そのうちの一つが、チームビルディングをテーマにした仮説キャンバスでした。ちょうど自チームのパフォーマンスを向上しようと考えていたメンバーが、チームビルディングのワークの準備が大変だったと経験して、これを課題に設定するところから考えたものです。

仮説キャンバスについてはこちらの記事をご覧ください。

関連記事<strong>仮説キャンバスを利用して、調査・アイデア発想を効果的に行う方法</strong>

2023.06.29

チームビルディングをテーマにしたこの仮説キャンバスは、チームのミッションに合っているテーマだと思いました。ラボでは、アジャイル開発をしているチームに協力してもらえるので、仮説検証の計画・実施がしやすそうです。また、Webアプリケーションの開発を通じて、フロントエンドの開発技術やUI/UXデザインの経験を積むことができそうです。何より、チームビルディングというテーマはチームメンバー一同が親しみやすいものでした。

以上の理由から、チームビルディングをテーマにプロダクト開発をすることに決定しました。

しかし、最初の仮説キャンバスのままでは、まだ「実現手段」すなわち開発するプロダクトの形態を認識共有することができません。そのため、仮説キャンバスをアップデートしていきました。

• 「目的」はこのチームのミッションを置こう。
• チームビルディングというテーマだけど、まずは発足から間もないチーム向けに、ドラッカー風エクササイズのワークを提供することを考えて、「ビジョン」や「状況」を置こう。
• 最初の仮説キャンバスは、ワークを準備するのが大変という「顕在課題」からスタートしたけれど、なぜ大変になるのかを考えよう。準備するのにただ手間がかかるから時短したいというだけでは、仮説検証する題材として弱い。オンラインでワークするという状況だと、ワークの効果を上げるために会話を弾ませようと準備に工夫が必要だから大変という「潜在課題」の仮説を立てよう。
• 「潜在課題」を解決した状態を「提案価値」に置こう。もはや「手間をかけない」という価値仮説は検証したいポイントではないな。「評価指標」は「提案価値」に合わせて再設定しよう。
• ビジネス観点の項目については、ミッションのスコープ外と整理して捨象しよう。

アップデート後の仮説キャンバスによって、チームがプロダクトの形態についてアイデアを出すことができるようになりました。

次は「提案価値」を提供できるような、「楽しく盛り上がる」「没入する」ワークにする「実現手段」を考えます。私たちは「クレイジー８」という手法でアイデアラッシュを実施しました。

まずは問いをチームで共有しました。「わたしたちは、どうしたら、ドラッカー風エクササイズを楽しく盛り上がるワークにできるんだろう？」という問いに対して、各自が1分以内にアイデアを１つ出す、これを8回繰り返しました。

こうして生まれたアイデアを、「盛り上がる効果」「実現容易性」の２軸で評価しました。そして最終的には、「AIにツッコミどころ満載の履歴書を作成させ、本人に訂正してもらいながら紹介してもらう」というアイデアから考えていくことにしました。

「提案価値」の「楽しく盛り上がる」については、生成AIで架空の履歴書を作成する方針としました。さらに、もう一つの「提案価値」である「没入する」ワークにするために、世界観とストーリーを被せることを考えました。架空の履歴書を作成するという体験に似合うように、映画「ミッション：インポッシブル」を参考に、スパイチームに入隊するという世界観・ストーリーを採用することにしました。

＜振り返り＞

何もないところからプロダクトの企画のアイデアを出しても、チーム全体で「よし、やろう！」という勢いが生まれるアイデアは出てこなかった。出てきたアイデアの種を意見交換によって発展させ、検証する価値のありそうなユーザー課題の仮説を立てることはできたように思うが、空想上のユーザー課題に得心するのが難しかった。

最終的にチームビルディングというテーマに決まったが、チームメンバーがユーザー課題を考えやすいテーマ設定ができて良かった。ビジネスを見据えて、市場にできるユーザー課題を探すならば、このテーマ設定の段階でユーザー理解をもっと深める必要があろうが、今回のチームのミッションは開発を優先したので、妥当な進め方だったと思う。

テーマをチームビルディングと決めた後は、開発メンバーがプロダクトのワクワクするコンセプトを考えてくれた。ユーザー課題と問いがあれば、その先をチームで進めることはできるので、最初の大方針を示すことがプロダクトオーナーの最も大事な仕事なのだろう。

10月23日〜10月27日　ユーザーストーリー作成

テーマとコンセプトが決まったので、次は開発するWebアプリケーションのプロダクトゴールを定めて、プロダクトバックログを作りました。

プロダクトゴールは、仮説キャンバスの「提案価値」をもとに立てました。すなわち、「楽しく盛り上がる」と「没入する」という価値を提供できる状態をゴールにしました。

プロダクトバックログを作る準備として、ユーザーストーリーがあると良いです。チームでユーザー体験を想像しながら、機能や画面を考えて、ユーザーストーリーを作りました。これによって、これから開発するプロダクトのイメージを共有できるようになりました。また、仮説検証に使うプロトタイプとして開発するスコープを考える時も、ユーザーストーリーを参照することで、チームでイメージを共有しやすくなりました。

ユーザーストーリーをもとに、プロダクトオーナーはプロダクトバックログアイテムを作成しました。また、開発メンバーは採用するプログラム言語やクラウドのアーキテクチャ、世界観を表現するためのUIデザインについて話し合い、方針を立てました。

このように開発を始める準備をしながら、検証したい仮説に必要なプロトタイプのスコープを定めました。プロトタイプで検証したい仮説は、以下の２つです。

仮説１：自己紹介の文章を元に、AIでコンテンツを生成すると、周囲はより自己紹介に興味を持ち、会話が弾むようになる

仮説２：スパイ映画のような非日常のシチュエーションでロールプレイすると、場の緊張が解れて発言しやすくなる

この仮説を検証するために、プロトタイプとして以下の機能と画面を準備する方針としました。

• ワークを説明する画面（世界観の受容を検証すべく、この画面にのみスタイルを適用）
• ドラッカー風エクササイズの質問への回答入力フォームと提出ボタン
• ドラッカー風エクササイズの質問への回答を生成AIに入力し、架空のプロフィールを受け取るAPI
• APIで受け取った架空のプロフィールをテキスト表示する画面

この後、スプリント１で上記の画面と機能を備えたプロトタイプを開発し、スプリント２でプロトタイプ検証することを目指しました。

＜振り返り＞

ユーザーストーリーの作成や、技術・UIデザインの方針検討は、開発メンバー主体で進めてくれたので、プロダクトオーナーとしては非常に助かった。開発メンバーがユーザー価値を探索する作業を行えると、プロダクト開発チームとしてやっていけそうな自信が湧いてきた。

今回は想定ユーザーの理解を深める活動をスキップし、プロトタイプの開発を優先している。そのため、仮説キャンバスの中の検証したい仮説、検証しない仮説に自覚的であるよう意識した。お陰で、プロトタイプのスコープがブレずにチームメンバーに伝えることができた。

プロダクトゴールは、直近の検証に向けたゴールを立てることはできたが、その先まで考えることができなかった。２ヶ月先までのリリースプランニングがないとチームが不安になるとスクラムマスターから指摘を受けるものの、私にはせいぜい次の２週間程度のスパンしか見通すことができなかった。チームが向かう方向を自転車操業で探索している状況であった。今回のチームのミッションが、チームの成長を主眼としているのではあるが、一方でプロダクトについてもベストを尽くさないとワクワク活動することもできないと考えていて、チームとプロダクトの両方のビジョンメイキングをするのは私のキャパシティを超えていた。

10月30日〜11月10日　プロトタイプ開発とユーザー状況観察

スプリント１ではプロトタイプの開発を実施しました。

仮説１：自己紹介の文章を元に、AIでコンテンツを生成すると、周囲はより自己紹介に興味を持ち、会話が弾むようになる

この仮説１を検証するために、会話が弾みそうな架空プロフィールをAIで生成できないか試行しました。結果的に、ドラッカー風エクササイズをアレンジした4つの質問に対するユーザー回答をインプットにして、openaiのAPIで架空のプロフィールを作成するAPIを開発しました。

仮説２：スパイ映画のような非日常のシチュエーションでロールプレイすると、場の緊張が解れて発言しやすくなる

この仮説２を検証するために、ユーザーが世界観に没頭できそうなUIデザインを作りました。ワーク説明用の一画面にスコープを絞ってスタイルを当てて、デザインを実装しました。

プロトタイプ開発と並行して、ユーザー理解を深めるために、ドラッカー風エクササイズを実施する様子を観察することにしました。

ラボではMiroを使って共同作業をすることが多いので、この時は私がMiroでワーク用のボードやワーク進行を用意し、ご厚意で集まってくれたラボ内の協力者4名でワークを実施する様子を観察しました。

観察の結果、仮説キャンバスで立てていたユーザー課題が現れないということが分かりました。観察前から薄々感じてはいたのですが、協力に手を挙げてくださった4名の方は非常にスキルが高く、オンラインのワークであっても上手にコミュニケーションをとっていました。具体的には、相槌を打つ、冗談めかして話す、Miroのリアクション機能やステッカー機能で相互に話を引き出す、といった行動を自然ととっていました。

今回は想定ユーザーの課題こそ観察できなかったものの、スキルの高い協力者のワークを観察したことで、効果的なワークを提供するためのソリューション仮説を新たに立てることができました。当時、観察の結果と考察を以下のようにまとめました。

ターゲットとしたユーザー状況である、チームビルディングのワークを実施している様子を観察した。
現状の手段である、Miroで用意したドラッカー風エクササイズのワークスペースで情報共有し、ビデオ会議ツール（Gather）で顔出しせずに会話するという方法のワークを実施した。

上記の状況において、ユーザーは以下３点の課題を抱えていると仮説を立てた。
しかし、行動観察の結果、課題仮説１〜３はいずれも棄却された。

課題仮説１：聴く側が他メンバーの自己紹介に興味を持てず、相互理解の効果が低い。
検証結果１：聴く側が他メンバーの自己紹介に興味を持っていた。フリートークで質問し合っていた。
考察１：メンバーの回答が尖っていたから興味を持てたのではないか。回答が印象的だった。

課題仮説２：話す側が本心から自身のことを話しきることができず、相互理解の効果が低い。
検証結果２：話す側が質問への回答だけでなく、自身のバックグラウンドまで含めて紹介していた。
考察２：ドラッカー風エクササイズの質問に回答すると、自然とそうなるのかもしれない。

課題仮説３：オンラインだと場が緊張して、リアクションが返ってこず、コミュニケーションが取りづらい。
検証結果３：オンラインでもリアクションを返していて、話しやすそうだった。
考察３：ビデオ会議で相槌を音声で返していたのは4名中2名。Miroの機能でのリアクションの方が全参加者の抵抗が少なかったと思われる。

総評

今回の協力者の４人が、特にコミュニケーションに積極的である特性を有していたと思われる。
そのため、課題仮説は棄却されたが、棄却された理由を分析することで、効果的なワークにするためのソリューション仮説を発見することができた。
課題仮説の検証については、別の協力者を募って再度実施したい。

ソリューション仮説１：オンラインだと、トピックのコンセンサスを形成するのが難しいから、自己紹介を深ぼる会話のきっかけを作る。

ソリューション仮説２：オンラインだと発言することに警戒心があるから、警戒心を解くために挨拶を挟んだり笑いを取ったりする。

ソリューション仮説３：オンラインだとメインスピーカーの邪魔にならないように発言を遠慮するから、発言しなくてもリアクションを示せるようにする。

ソリューション仮説４：メンバーによっては無難な回答しか出なくて、名前とキャラクターを結びつけて記憶しづらいから、イメージや愛称をつけて印象に残す。

以上

上記のまとめを踏まえて、仮説キャンバスをアップデートしました。

• 「代替手段と不満」を、観察したようにMiroを使ったワークと置こう。Miroでも緊張を解くことができたけれど、参加者の力量に依存している。だから課題を持っているであろうユーザーの「状況」として、形成されて間もないチームというペルソナを設定しよう。
• ソリューション仮説1,2,4は、このプロダクトで想定しているMVPで実現できそうだから、「提案価値」に入れよう。ソリューション仮説3は、複数ユーザーの同期処理が必要そうだから、MVP以降のフェーズで検討したい。
• 「顕在課題」はもともと、ワークを準備するのが大変というワーク主催者目線のものだったけれど、「提案価値」はワーク参加者の課題に関するものになっている。仮説の整合性を取って検証できるようにするため、「顕在課題」や「潜在課題」もワーク参加者の目線で仮説を立て直し、次のスプリントで検証しよう。

＜振り返り＞

ユーザー行動観察については、本来ならばユーザー状況の仮説をしっかり検討した上で、検証に適した協力者を選定することで学びを多く得られるのだろう。ワークのフレームについても、自分で作るのではなく、他のチームがどのようなフレームでドラッカー風エクササイズをしているか調査する方が効率的にユーザー理解ができたかもしれない。

一方、急ごしらえでの行動観察とはいえ、そこから得られる気づきや学びは多かったと思う。チームビルディングのワークに慣れている協力者の工夫、例えば自分を表現するアイコン画像をMiroに貼ることで自分を覚えてもらえるようにするなど、暗黙知であったユーザー課題と解決策について偶発的に知ることは、行動観察でなければ不可能だっただろう。

観察は開発メンバー含めてチーム全員で実施したが、事前に検証対象の仮説や観察ポイントを整理して共有した。結果として、観察の気づきをチームで数多く挙げることができたし、考察をしやすかったように思う。

11月13日〜11月27日　プロトタイプ検証

スプリント２では、スプリント１で完成したプロトタイプをもとに仮説検証を実施することと、当初想定のMVPを実装することを目指しました。

MVPの実装については、開発メンバーが工夫しながら順調に進めてくれて、ほぼ現在公開中のものと同等の機能・デザインを完成させることができました。そのため、仮説検証もMVPを用いて実施することができました。

MVPで出力した架空プロフィールのイメージ

架空プロフィールの画面右下が、私が実際に回答した文章で、その他はAIが生成したテキストと画像です。

このMVPで仮説を検証するにあたって、仮説キャンバスをもとに、検証対象の仮説を絞りました。オンラインのワークの緊張感を和らげる効果の仮説については、MVPのアイデンティティではなさそうだ、などと考えた結果、検証対象の顕在課題を決定しました。

顕在課題：無難な回答しか集まらなくて、印象に残らない

この顕在課題の背景について、さらに仮説を重ねていきました。2人で会話するという手法をとることで、考えを深めることができました。

• 仮説キャンバスを見ると、無難な回答しか出せないという課題の原因である潜在課題は「癖のある自己紹介をして受け入れられないのが怖い」だと仮定しているが、恐怖が原因ではないのでは？自分でMVPをもとに自己紹介を話してみたけれど、架空プロフィールを訂正しながら、さらに質問への回答について背景を話そうとしても、とっさに話せない、思い付かない。
• 分かる。自分の回答を素読みするだけになりがち。自分の場合は、とりあえず周りに合わせておこう、という考えになる。ドラッカー風エクササイズの質問という「問われたこと」に対して回答を話せれば十分だろうと思う。
• なるほどねえ。しかし、自己紹介を聴く側の人は、話す側の人に対して、なるべく自己開示してほしいと期待しているだろう。質問に対する回答の素読みだけでは、話す側の人に対する理解が表層的なものにとどまる。
• そうですね。一方、話す側は、問われたこと以外に話す必要性を感じていない気がする。それ以上のことを話すことを期待されていると考えていないというか。
• 逆に考えて、聴く側の立場で自己紹介が印象に残るのは、どんなときだろうか？ワーク終了後に「◯◯さんといえば△△」と言えるようになるには？
• 例えば、自分が質問をしたことへの回答については印象に残る。あとは、その人にしかない何かがあると「◯◯さんといえば△△」と言えるようになりそう。
• 聴く側の質問を引き出せるかはワークの構成によりそうで、並列可能なテーマであるけれど、MVPの効果を見るという点では、その人にしかない何かが引き出せるかを検証したい。

会話による考察を通じて、仮説をアップデートしました。

潜在課題：守りの姿勢、様子見のためその人らしさが出てこない

提案価値：偽プロフィールを訂正することで、本当の自分の情報をつい話してしまうから、印象に残る自己紹介ができる

提案価値仮説では「本当の自分の情報をつい話してしまう」と書いていますが、それが聴く側の印象に残るには、話す側の「その人らしさ」が話されることを期待しています。架空プロフィールを訂正する過程で「その人らしさ」を引き出せるかを、仮説検証の指標として設定することにしました。

「趣味・特技」は魔法を使えることと書いてあるけれど、実は使えません。本当は社交ダンスが得意です。ワルツとか踊れます。【変わった特技・経歴】

プロフェッショナリズムは魅力あふれるパフォーマンスっていうのは、あながち間違いではないですね。得意なのは文章を作ることです。昔、小学生の作文を添削指導する仕事をしていたので、厳しくチェックできます。【体験・エピソード】

ー

ITインフラの知識は神業級、と言いたいところですが、実際の職務歴は3年で、製品コンフィグとかシェルスクリプトに関連するSIの仕事をしていました。IPAのNW、SC、DB資格を持っているので、エンタープライズのシステムの基本は分かります。【体験・エピソード】

オーバーエンジニアリングは悪口じゃないか（笑）業務経験があるので、チーム内で保険ビジネスを検討するときにはリードします。【何らかのNo.1】

ー

皆さまチームのヒーローたちのビジョンを実現するために、クリエイティブに仕事したいと思います。実際、仕事をする上では、自分なりの仕事の意義を見出してワクワクすることが、力を発揮するために大事だと考えています。【パーソナリティ】

ー

チームにアクションプランを提案、することはプロダクトオーナーとしてなるべく控えようと考えています。ビジョンを描き、方針を示すことをリードしながら、ビジョンを形にする部分は開発メンバーにお願いします。【何らかのNo.1】

ー

これまでノーコードツールを使った実験的な開発はしていましたが、本格的なアプリケーション開発の実務経験はありません。技術調査や実装について私も知りたいですので、説明のご協力をお願いします。【体験・エピソード】

ー

架空プロフィールを訂正しながら、「その人らしさ」を話すことができるか、自分で試してみました。確かに、生成された架空プロフィール次第では話しやすい部分もありましたが、普段そこまで自己開示しない人から「その人らしさ」を引き出せるかというと、まだ難しいように見えました。

では実際はどうなのか、検証する計画を立てて実施しました。

計画においては、「検証キャンバス」を活用することで、検証する仮説、検証の指標、方法などを考え、チームで共有しました。指標は「比較」で計測すると判断しやすいというアドバイスを受け、ホワイトボードツールであるMiroを使ったワークと今回のMVPを使ったワークを比較するという方法を取り、「その人らしさ」が発言された回数を比較する方針としました。

検証の結果は以下の通りです。

＜振り返り＞ 

出来上がったMVPを使ってみる段階、検証の計画を立てる段階、それぞれで新たな気づきがあり、仮説キャンバスが随時アップデートされた。当初の提案価値の仮説は「盛り上がる」「没入する」であったが、スプリント２では「自分の情報をつい話してしまう」になっている。

仮説とモノづくりを並行して実施することで、相互に気づきを得られるような開発は、探索的な学習の効果は大きかったように思う。一方、学びを積み上げている実感が薄く、成功体験として捉えづらいものでもある。そのため、チームで振り返りを実施して、活動によって得られた学びや経験を確認することが重要だろうと、今振り返るとそう考える。

開発中はつい忘れがちなのだけれど、開発しながら自分達で使ってみて、UXを確認することが重要だと気づいた。最終的に提供するUXこそが成果なので、常にUXを意識してプロダクトバックログをメンテナンスするのが本来は必要なのだろうが、実践するのは難しいと感じた。そのバックログの変更が重要だと自分及びチームが納得するには、できるならば仮説検証した方が良いが、その検証にも時間がかかるので、まずは当初決めたMVPを完成させようと方針転換を躊躇してしまった。

11月28日〜11月30日　仮説のアップデート

MVPを使った検証では、聴く人の印象に残るような「その人らしさ」を引き出すのが難しいと分かりました。この後、MVP検証を分析して、仮説キャンバスをアップデートしていきます。

まずは、検証キャンバスの下半分、「検証して何を学んだか」を整理しました。

検証結果（事実）
質問への回答から深掘りして「その人らしさ」を話した回数は、Miroを使ったワークでは3人の平均が1.67回/人、MVPを使ったワークでは3人の平均が0.67回/人であった。

検証から学んだこと
提案価値の仮説「偽プロフィールを訂正することで、本当の自分の情報をつい話してしまうから、印象に残る自己紹介ができる」はおそらく違っているようだった。

ドラッカー風エクササイズの質問への回答の文章の長さは、どちらのワークでも短かかったが、口頭で話すときに「その人らしさ」を補足するかは話者次第であり、MVPが補足を促している様子は観察できなかった。

次にやること
仮説キャンバスの見直しとアップデート。検証を実施して観察したことをもとに、仮説キャンバスを見返して仮説の正誤を判定し、仮説をアップデートする。

次に、仮説キャンバスを見直しました。仮説キャンバスの中でも見直しやすそうな、提案価値について最初に考察しました。

提案価値①：偽プロフィールを訂正することで、本当の自分の情報をつい話してしまうから、印象に残る自己紹介ができる。
訂正するだけで自然と話が深掘れるわけではなかった。

提案価値②：ワーク自体にエンタメ性が合って、最初からリラックスした雰囲気で話せる。
この価値仮説は実現していそうに見えた。Miroを使ったワークに比べ、MVPを用いたワークは厳格さが薄れて柔らかい雰囲気だった。

提案価値③：AIがナンセンスなプロフィールを作ってくれるから、滑ることを恐れず癖の強い自己紹介が書ける。
これについては検証できていない。MVPを使ったワークでも、癖の強い自己紹介は出てこなかった。

続いて、仮説キャンバスの顕在課題について見直しました。

顕在課題①：（話す側が）守りの姿勢・様子見のためその人らしさが出てこない。
話す人自身が課題だと考えているわけではなさそう。しかし、チームビルディングを効果的に行う上では課題となりそうに見える。話す人がドラッカー風エクササイズの目的を理解していないのか？理解していたら「その人らしさ」を出すことはできるのか？

顕在課題②：（聴く側が）無難な回答しか集まらなくて印象に残らない。
印象に残らないことが本当に課題なのだろうか？聞く側はドラッカー風エクササイズの回答を聞いて、どう頼るか、どう助けるか、どう一緒に仕事をするかを考えられれば良いのではないか？

顕在課題③：（聴く側が）緊張感があって相槌や冗談が言えない。（話す側が）リアクションがなくて話しづらい。
真面目にワークを行いたい人は、課題だと考えていないかもしれない。ここまでワークを観察してきて、場の緊張がほぐれて盛り上がっている方がワークに前向きになっているように見えるが、ワークの目的に対しては間接的な要素だろう。

最後に、仮説キャンバスの潜在課題について見直しました。

潜在課題①：発言して目立ってしまい、気まずい空気になるのが怖い。
潜在課題②：癖のある自己紹介をして受け入れられないのが怖い。
怖がっているようすはなかったが、それでも「その人らしさ」は出なかった。これは、そこまで話す必要性を感じていないことが原因のようにも考えられる。

そもそも、ドラッカー風エクササイズのワークを、普段の自己紹介の延長で捉えていると、人によっては「良かれと思って」自己開示のブレーキを踏んでいるのかもしれない。

「目的に応じた情報に限定して開示した方が良い」「自分の主張は控えめであるべきだ」「聴く側の共感が見込めないような個人的な情報は開示する意味がない」と考えるのも不自然ではない。

ここまで仮説を見直してきて、次の疑問が浮かびました。ドラッカー風エクササイズのワークの趣旨や目的について、私たち自身もあまり理解しておらず、ワークのプロセスやゴールの理想像を想定できていなかったのではないかということです。

私自身も恥ずかしながら、原典を辿れてはいませんでした。そこで、Jonathan Rasmussonのブログをチームで読み合わせし、理解し直すことにしました。

こちらのドラッカー風エクササイズの紹介ブログを読んで、ドラッカー風エクササイズのプロセスとゴールを下記のように理解しました。

プロセス：質問への回答を紹介することで、メンバー一人ひとりが自己PRをする。特に、チームに対してどう貢献するかについて、メンバーとチームで認識を合わせる。

ゴール：チームとメンバーの良い協力のやり方を話し合えるようになる。

そして、このプロセスの中の「自己PR」というのが、何だか外国っぽいという面白い意見がチームから出ました。

Jonathanのブログで紹介されている質問への回答例を見ると、自分の強みや働き方について、自分の意志を強く持って主張しているように見えたのです。確かに、プロジェクト内の自分のポジションを主張している様子は、ジョブ型雇用の慣習がある外国っぽいと思いました。

ここまでの考察を踏まえて、うまくいったように見えたスプリント１の行動観察の際のドラッカー風エクササイズの回答を改めて確認しました。すると、Jonathanのブログの例と比較して、以下の観点で自己PRが弱いように見えました。

• 自身の強み、自身の貢献について、具体性が伴っていない。
• 自身の強み、自身の貢献について、主張が控えめである。
• チームに求める支援について、自身の弱みを開示できていない。

ワークに慣れた人を集め、緊張感がほぐれた雰囲気であっても、なお自己PRについては難しいのではないか、という仮説が立ちました。

自分達のチームでも改めてドラッカー風エクササイズを実践してみましたが、感想戦では「強み、貢献は回答に自信がない」「どのくらい自分のことを話すかは、前の人の自己紹介を参考にしている」という感想が出ました。やはり、自信を持って自己PRすることに難しさがありそうです。また、「初対面で、自分が話すのを待ってる間は人の紹介はあまり耳に入らない」という気づきもありました。

自分で自己PRをするのが難しいなら、他メンバーからの質問を募って、それに回答する形式のワークにすれば良いのでは？と考え、再度チームでワークを実施してみました。しかし、これはこれで、質問する側の負担が大きく、満足のいくワークにはなりませんでした。感想戦では、「質問が思いつかない（特に新人に対して）」「上手な質問をせねばならぬというプレッシャーがかかる」といった感想が出ました。

一方、チームからメンバーへの期待を伝えるという行為に対しては、良い面も見えました。期待を伝えた側の感想は、「特別な体験ではなかった。土日を挟んだら忘れていそう」というネガティブなものでしたが、一方で期待を聞いたメンバー側の感想は、「身の振り方を決められて良い」「想定外の期待があると嬉しい、知見を広げる機会になる」というポジティブなものがありました。

ここまでの考察をまとめて、仮説キャンバスを以下のようにアップデートしました。ここから、スプリント開始前と同様に、問いを立てて、デザインシンキングの手法でアイデアを新たに探していこうとしています。

ビジョン
本気でチームメンバー個々の強みをチームで共有し、「俺たちはドリームチームだぜ」という結束感を持てる。

状況
ドラッカー風エクササイズで自身の強みを共有する。（発足されてまもないチーム、には限定しない）

傾向
自己紹介がスピーチっぽくなっている。
みんなの一通りのスピーチを聞いた後にディスカッションで深掘る。
ドラッカー風エクササイズの質問への回答の文章だけだと、具体性が伴わずあっさりしている。

課題
（聴く側）
メンバーへのやってほしいことや助けてほしいことなどの期待感がわからず、質問できない。
特に自分の専門外の領域だと、「へえ」で終わってしまう。
良い質問をせねばならぬというプレッシャーがある。
（話す側）
自己分析しきれていなくて、自己開示する情報を思いつけない

提案価値
ワークの実施後に、各メンバーのチーム内での役割について、お互いの期待を共有できている。

＜振り返り＞

検証の結果、仮説が間違っていたと分かった後、仮説をアップデートするというフェーズまで経験できたのは良かった。仮説を立てて検証するという活動を通じて、自分の理解が不足していた点が明らかになり、次の方針を見出すための視界が開けるような感覚であった。

今回は、ドラッカー風エクササイズそのものについて、理解が不足していたことが明らかになった。それからチームで学習し、実践することで、連鎖的に発見があり、仮説をアップデートしていくことができた。

一方、探索のプロセスにおいては、思いついては調べて試す、という場当たり的なアクションを繰り返しており、２週間のスプリント内の計画をバックログ化することすらできなかった。そのためか、アイデア創出や仮説アップデートを、POとである私がほとんど単独で実施することになっていた。開発メンバーも巻き込んで探索活動を実施できるように体制をカイゼンすべきであると理解はしているが、そのカイゼンの具体的な方法については未だにノーアイデアである。当ラボ内の探索メインのチームから工夫をヒアリングする等、カイゼンに向けて考えていこうと思う。