「正しいものを正しくつくる」を探索し続けてきた10年とこれからの10年

「正しいものを正しくつくる」を 探索し続けてきた10年とこれからの10年 ギルドワークス 中村 洋(@yohhatu) https://unsplash.com/photos/TSgwbumanuE

目次 ✔ 自己紹介やら ✔ DevLOVEへの感謝 ✔ 「正しいものを正しくつくる」へのこれまでの旅路 ✔ 「正しいものを正しくつくる」へのこれからの旅路

目次 ✔ 自己紹介やら ✔ DevLOVEへの感謝 ✔ 「正しいものを正しくつくる」へのこれまでの旅路 ✔ 「正しいものを正しくつくる」へのこれからの旅路

自己紹介 ・中村 洋(よう) ・ギルドワークス ・現場コーチ/アジャイルコーチ ・認定スクラムマスター ・DevLOVE関西 ・@yohhatu http://about.me/yohhatu

• http://about.me/yohhatu

ギルドワークス ✔ 仮説検証型のサービス企画や開発、現場改 善する現場コーチなどでクライアントの事業 を推進する ✔ ミッションは「正しいものを正しくつく る」、価値は「越境」 ✔ 全国各地のエンジニア、デザイナーと組 み、適時適チームを実現している

バックグラウンド https://unsplash.com/photos/Xnv7O4jBAEQ

これまでのキャリア 1：2次受けの開発会社 2：(派遣的な)開発会社 3：割と堅調な開発会社 4：(元)海岸沿いのSIer 5：国産ブラウザを作っている会社 6：フリーランス 7：ギルドワークス←イマココ

肩書き的なもの 1：プログラマ 2：システムエンジニア(SE) 3：チームリーダー 4：スクラムマスター 5：アジャイルコーチ 6：現場コーチ←イマココ

現場コーチとは？ https://visualhunt.com/f/photo/6320530955/0096f62955/

ミッション 「正しいものを正しくつくる」 現場を増やす

関わった現場 27社 https://visualhunt.com/photo/8648/

関わったチーム 54チーム https://visualhunt.com/photo/35879/

https://guildworks.jp/works/

いろいろなコーチの道具 変化することへの壁 やり方への壁 メトリクス 課題を小さく砕く 自分達のカタを比較する 因果関係図 星取表 お披露目会 チームでの活動 仮説キャンバス 事業状況の分析 事業合宿 インセプションデッキ カンバン 期待をすり合わせる お互いの仕事を観る 役割の壁 https://speakerdeck.com/yohhatu/asiyairukarutiyakazu-zhi-nigen-fu-kumatefalsetiao-zhan?slide=52

アジャイルコーチ。社内と社外の違いって？ (月刊ギルドワークス2019年6月) https://guildworks.doorkeeper.jp/events/92800

目次 ✔ 自己紹介やら ✔ DevLOVEへの感謝 ✔ 「正しいものを正しくつくる」へのこれまでの旅路 ✔ 「正しいものを正しくつくる」へのこれからの旅路

DevLOVEへの感謝 https://unsplash.com/photos/AoqgGAqrLpU

DevLOVEへの感謝 ✔ DevLOVEがなければ今の自分はない ✔ きっとDevLOVE関西もなかった ✔ きっとギルドワークスもやってなかった ✔ きっと現場コーチもやってなかった

DevLOVE関西のこと https://unsplash.com/photos/AoqgGAqrLpU

DevLOVE関西 ✔ 2009年9月26日が最初 ✔ 「関西ではDevLOVEなどの勉強会やイベントが無い」→ 「場が無いならば作るまで」が発端

DevLOVE関西 ✔ 開催回数：181回 ✔ コミュニティ参加人数：2300人 ✔ のべ参加者：だいたい5500人 ✔ のべ話し手：だいたい400人

DevLOVE関西 ✔ 発表すると知識の整理になり、フィードバックを得られる ✔ 会社以外の場が見つかる ✔ 色々な人とのつながりができる

目次 ✔ 自己紹介やら ✔ DevLOVEへの感謝 ✔ 「正しいものを正しくつくる」へのこれまでの旅路 ✔ 「正しいものを正しくつくる」へのこれからの旅路

「正しいものを正しくつくる」へのこれまでの旅路 https://visualhunt.com/f/photo/3393567616/

「正しいものを正しくつくる」とは？ ✔ 正しさは絶対ではないし、その時に変わる ✔ その時、その状況におけるあり方を探求する姿勢 ✔ 今日は自分の体験を「正しいものを正しくつくる」と いう観点で見たときの考察

「正しいものを正しくつくる」の旅路 ✔ 旅路1：間違ったものを正しくつくる ✔ 旅路2：正しいものを正しくつくる ✔ 旅路3：間違ったものを間違った方法でつくる ✔ 旅路4：正しいものを正しくつくる

旅路1：間違ったものを正しくつくる https://unsplash.com/photos/P7FVbBHVqZs

旅路1：間違ったものを正しくつくる ✔ 出来事：つくったけど使われなかった ✔ 理由：利用者のことを理解していなかった ✔ 学び：つくる前に利用者のことを理解する活動をする https://unsplash.com/photos/P7FVbBHVqZs

旅路1：間違ったものを正しくつくる ✔ 利用者のことを理解していなかった ✔ 利用者が仕事をしている場所、環境を見なかった ✔ 仕様書などデジタルな情報だけをインプットにした ✔ 利用者の状況がわかっていれば別のものにした(と思う) https://unsplash.com/photos/P7FVbBHVqZs https://unsplash.com/photos/IClZBVw5W5A

• https://unsplash.com/photos/IClZBVw5W5A

旅路1：間違ったものを正しくつくる ✔ つくる前に利用者のことを理解する活動をする ✔ どんな道具をどのように、どれくらい使っているか？ ✔ 作業環境、周囲の状況はどのようなものか？ ✔ 行動観察、ユーザーインタビュー、Job To Be Done https://unsplash.com/photos/P7FVbBHVqZs

旅路2：正しいものを正しくつくる https://unsplash.com/photos/vbxyFxlgpjM

旅路2：正しいものを正しくつくる ✔ 出来事：フィードバックをステークホルダー(決裁者)と利 用者から得るようにした ✔ 理由：それぞれ関心事が違っていた ✔ 学び：複数の関係者の関心事を整理し、期待マネジメント を行う https://unsplash.com/photos/vbxyFxlgpjM https://unsplash.com/photos/vbxyFxlgpjM

旅路2：正しいものを正しくつくる ✔ フィードバックをステークホルダー(決裁者)と利用者から 得るようにした ✔ 毎週のデモの場に決裁者と利用者の両方を招いた ✔ 両者のフィードバックでバックログをUpdate ✔ 立場によって関心事が違う https://unsplash.com/photos/vbxyFxlgpjM

旅路2：正しいものを正しくつくる ✔ 複数の関係者の関心事を整理し、期待マネジメントを行う ✔ 立場、文脈や組織体制などで関心事は違う ✔ いずれかに偏るとうまく進まなくなることもある ✔ 立場によって関心事が違う ✔ 関心事を整理する ✔ インセプションデッキ(ご近所さん) ✔ ステークホルダーマッピング https://unsplash.com/photos/vbxyFxlgpjM

旅路3：間違ったものを間違った方法でつくる https://unsplash.com/photos/sxQz2VfoFBE

旅路3：間違ったものを間違った方法でつくる ✔ 出来事：つくったサービスが使われず、チームも疲弊 ✔ 理由：不確実性をマネジメントできなかった ✔ 学び：小さく分割することで、素早く確認しながら少しず つ進む https://unsplash.com/photos/sxQz2VfoFBE

旅路3：間違ったものを間違った方法でつくる ✔ つくったサービスが使われず、チームも疲弊 ✔ 誰の課題を解決するためのものか？ ✔ これからつくるものでその課題は解決できそうか？ ✔ なぜその時期にリリースするのか？ ✔ 大事にすることはなにか？ https://unsplash.com/photos/sxQz2VfoFBE

旅路3：間違ったものを間違った方法でつくる ✔ 小さく分割することで、素早く確認しながら少しずつ進む ✔ 仮説検証を小さくする(課題、ソリューション) ✔ つくるものも小さく少しずつ積み上げていく ✔ Whyは見失わないようにする ✔ 仮説キャンバス、検証キャンバス インセプションデッキ https://unsplash.com/photos/sxQz2VfoFBE

旅路4：正しいものを正しくつくる https://unsplash.com/photos/hRwrvvZHk70

旅路4：正しいものを正しくつくる ✔ 出来事：現場と一緒に課題解決できるか検証した ✔ 理由：「使ってください」だけでは進まなかった ✔ 学び：ドッグフィーディングと利用者のOutcomeに フォーカスした活動 https://unsplash.com/photos/hRwrvvZHk70

旅路4：正しいものを正しくつくる ✔ 現場と一緒に課題解決できるか検証した ✔ 提供して終わりではなく課題解決しているか？までを目 的にした(インセプションデッキにも書いた) ✔ チームメンバーそれぞれが利用者と一緒になって進めた https://unsplash.com/photos/hRwrvvZHk70

旅路4：正しいものを正しくつくる ✔ ドッグフィーディングと利用者のOutcomeにフォーカス した活動 ✔ 利用者として使ってみることで(作り手とは)違う姿が見 えてくる ✔ Outcome > Output(後述) https://unsplash.com/photos/hRwrvvZHk70

目次 ✔ 自己紹介やら ✔ DevLOVEへの感謝 ✔ 「正しいものを正しくつくる」へのこれまでの旅路 ✔ 「正しいものを正しくつくる」へのこれからの旅路

「正しいものを正しくつくる」へのこれからの旅路 https://unsplash.com/photos/uGP̲6CAD-14 https://unsplash.com/photos/RiReCZqe-As

「正しいものを正しくつくる」へのこれからの旅路 ✔ OutputではなくOutcomeに着目する ✔ もっとユーザーのことを知り、わかったことを受け入れる ✔ ありたい姿を探し続ける

OutputではなくOutcomeに着目する https://unsplash.com/photos/uGP̲6CAD-14

OutputではなくOutcomeに着目する ✔ システム開発の場合… ✔ Output ＝ 作った機能 ✔ Outcome ＝ 利用者がどう変わったか？課題が解決し たか？幸せになったか？ ✔ Outcome > Output https://unsplash.com/photos/uGP̲6CAD-14

OutputではなくOutcomeに着目する ✔ 何時間働いたか？いくつの機能を出したか？よりも利用者 がどう幸せになったか？にフォーカスする ✔ Outcomeに着目すると「コードを書く」ことも手段の 1つに過ぎない https://unsplash.com/photos/uGP̲6CAD-14

OutputではなくOutcomeに着目する ✔ ビジネスのOutcomeと利用者のOutcomeのバランス ✔ 売上やユーザー数、利用者の行動変容 ✔ 両方をモニタリングする必要がある https://unsplash.com/photos/uGP̲6CAD-14

もっとユーザーのことを知り、 わかったことを受け入れる https://unsplash.com/photos/6awfTPLGaCE

もっとユーザーのことを知り、わかったことを受け入れる ✔ エスノグラフィ、ユーザーインタビュー、ユーザーテス ト…利用者のことを知るやり方はいくらでもある ✔ エンジニアも一緒にチームでみんなで行う ✔ 言語化が難しいニュアンスを共通認識としてチームが 持つことでプロダクトが磨かれる https://unsplash.com/photos/6awfTPLGaCE

もっとユーザーのことを知り、わかったことを受け入れる ✔ モブプログラミングのようにみんなでユーザーのことを知 るモブワークを行う ✔ そのために必要な時間をとる ✔ コードを書いている時間だけ、Outputだけを評価の対 象にしない https://unsplash.com/photos/6awfTPLGaCE

もっとユーザーのことを知り、わかったことを受け入れる ✔ 知ったことを受け入れる勇気 ✔ 仮説に固執しない ✔ 一方自分達の意思も大事 ✔ わかったことと向き合い学びを積み上げていく https://unsplash.com/photos/6awfTPLGaCE

ありたい姿を探し続ける https://unsplash.com/photos/̲StWB2OcZ0U

ありたい姿を探し続ける ✔ 「正しいものを正しくつくる」唯一の方法などない ✔ 探し続けること ✔ プラクティスをなぞることでもない https://unsplash.com/photos/̲StWB2OcZ0U https://unsplash.com/photos/6awfTPLGaCE

「正しいものを正しくつくる」旅路を歩み続ける https://unsplash.com/photos/3y7fe̲I--WU