Fusic Biz Live タガタメのシステムか？by Hirosawa

タガタメのシステムか？ ～顧客の声を聴くファシリテーション術～ 事業推進部門 コンサルタント 広沢 拓也 Hirosawa Takuya

Presenter 事業推進部門 コンサルタント 広沢 拓也 Hirosawa Takuya Work at Fusic新卒入社 9年目の夏。 開発未経験でエンジニアとして入社後、 4年ほどを経て、PMへロールチェンジ。 営業・PM・要件定義・仕様設計を始め、 社内外のファシリテーター業務を担当。 Hobby 「多趣味なサッカーバカ」 サッカー観るならどこへでも。 Fusic軽音学部 部長

Story 新規事業を創出するうえで、システム開発はつきものの時代。 自社で開発体制が取れない場合は システム開発会社と組んで、プロジェクトを進めていく なんてケースは多々あると思います。 そのプロジェクトによって出来上がったシステム（サービス）は 思い描いた通りに出来上がったでしょうか？ あなたが”伝えたかったこと”は伝わったでしょうか？ 今日は、プロジェクトに少しでも多くの “納得感”を生むための工夫をお伝え出来たらと思います。

Chapter.1 要件よりもヒアリングすべきもの。 Message Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。

Chapter.1 要件よりもヒアリングすべきもの。

Chapter.1 要件よりもヒアリングすべきもの。 システム開発において、ヒアリング（要件定義）は 全工程の中でも最も重要と言ってもいいフェーズ。 発注側がすること ○○な世界を実現したいので… △△ができるものを作りたいです。 ・システム化したい要件、要望を伝える。 開発側がすること △△ができるものですね。 わかりました。 お見積りしますね。 ・システム化したい要件、要望をヒアリングする。 そのヒアリング、要件だけ確認されてませんか？

Chapter.1 要件よりもヒアリングすべきもの。 システム開発のヒアリングにおいて大事なことは “ 要件 “ではなく、「なぜ？必要なのか？」という ” 理由 ” だと思っています。

Chapter.1 要件よりもヒアリングすべきもの。 ヒアリングで確認すべきは要件ではなく、「なぜ？」 ①要件だけでは、発注側の意図を汲み取れない ②仕様齟齬は、「開発会社の思い込み」によって生まれる ③「何を作りたいのか？」ではなく、「なぜ？作りたいのか？」 どうやって、「なぜ？」を聞き出すのか？ Next Chapter ➡

Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。

Chapter.2 ワークショップと言ったりもします ファシリテーションの思想を用いて、会議をデザインしよう。 ファシリテーションを用いた要件定義 会議やミーティングを円滑に進める手法の1つ 参加メンバーの発言を促して 意見を整理し 議論を広げ 結論を導き 合意を取る。 参加者全員で 納得できる結論を形成する場

ファシリテーション風景

Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 通常の会議と異なるところ・特徴 ファシリテーター以外は 全員が参加者 ゴールと工程が準備された会議 最低でも3時間が目安 考える時間と 発言のタイミングが 区切られている 付箋などを使って 言葉を可視化しながら行う 声の大きさに関わらず 意見・発言を平等に拾える

Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 「なぜ？」を拾える、ファシリテーションサイクル ブレスト（付箋への書き出し） 1テーマ3分を目安に 書き出すケースが多いです ひとりずつ黙々と！ 貼り出しながら グルーピングを行うとgood! ココで、なぜ？そう考えたのか？ を拾うことが出来る 議論（付箋への質疑） 共有（付箋を貼りだす） 貼り出しながら、みんなの意見も確認 貼り出しながら、みんなの意見も確認 それぞれ、時間を区切ってサイクルを回す

Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 ファシリテーションに込められている想い ・会議のゴールを決めて、たどり着くためのプロセスを予め準備しておくこと ・考える時間と話す時間を分けること ・議論において、声の大きさや発言の数は関係がないこと 参加者全員がこの想いを理解していること

Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 ファシリテーションに込められた想いをみんなが理解していれば 普段の1時間の会議だって、ただ聞いてるだけの会議にはならないはず。 「今日のゴールはこれだから… 決めるためにはこんな流れが必要で…」 「ここはみんなで意見を出したいから 付箋に書き出してみようかな…」 と、ちょっとの工夫で会議をデザインするだけで 景色はずいぶんと変わってくるはずです。 Next Chapter ➡

Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。

Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。 とはいえ、どれだけうまくプロジェクトを進めたとしても その事業が成功するかどうかは別の話。 でも、たとえ失敗したとしても 「この方向性で行こう！！」とみんなで”納得”して出した結論なら、 きっと悔いはないはず。 それに、「なぜ、その方向性で行こうと決めたのか？」が可視化され みんなが”認識”していれば、軌道修正だってスムーズだと思うのです。

Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。 ファシリテーションが生む”認識”と”納得感” ファシリテーションの中で行われる、意見（言葉）の可視化は プロジェクトが進む中で起こりがちな “方向性のズレ”を認知できるようになります。 誰のためのシステムを作っているのか？を見失わない

Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。 ファシリテーションが生む”認識”と”納得感” 今ではオンラインツールも充実しており “可視化を保存する”ことも、とても容易な時代になっています。

Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。 ファシリテーションが生む”認識”と”納得感” 同じ方向を見据えるひとつのチームであるために、 ファシリテーションの思想を通して チームメンバー全員がプロジェクトの目的を”認識”し チームメンバー全員で”納得”できる システム開発ができたらいいなと、取り組んでいます。

Chapter.1 要件よりもヒアリングすべきもの。 Message Chapter.2 ファシリテーションの思想を用いて、会議をデザインしよう。 Chapter.3 プロジェクトの命運を分けるのは、みんなの納得感。

タガタメのシステムか？ ～顧客の声を聴くファシリテーション術～ Thank you !!