アート・オブ・アジャイルデベロップメント読書会 6.3 真の顧客の参加 === ###### tags: `アートオブアジャイルデベロップメント読書会` [読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view) * [connpass募集ページ](https://agiledevs.connpass.com/event/193498/) * ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs) # 自己紹介 - ファシリ役 - - 読み上げ役 - # 参加の仕方 - マイクはいつでもONにして、話に参加して結構です。 - テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。 - 聞いているだけの方もOKです！ # ディスカッションをより豊かにするためのグランドルール [アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t2kob/atoobuaziyairulun-du-hui-hazimefalse1bu) - 参加者は毎回任意 - 今回は不参加、次回は参加をするといった気軽な感じ - 途中参加も断然OK! まずは聞くだけでも大丈夫です！ - フィードバックを恐れない - マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう - アウトプット7割：インプット3割の気持ちで臨みましょう！ - 経験の有る無しは気にしない - 自分はアジャイル非経験者だから……と気後れする必要はないです - 堂々と意見や疑問を語りましょう - ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです - 電子書籍で読んでいるとページ数ではわからないため - 話していない人が、率先してメモしましょう - このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada: - 気になる質問や同感するものには :+1: を末尾につけてください。 # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 19:30- | - | もくもくタイム（hackmd書き込み） | | | 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | | | 20:15-20:25 | 10分 | 参加者アンケート | | | 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 20:35-21:45 | 70分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | | |21:45-21:50 | 5分 | [miro](https://miro.com/welcomeonboard/DgN2fhzWfBt3jHeC1h5Clteo4TvoXmS6Hx06eM46RiQEpjkVv52ZlMeu8u2nLRJ0)を使って振り返り | | | 21:50-21:55 | 5分 | 次回開催日と読む範囲決めてクローズ | | # 下に感想などを書いていって下さい。どんな些細なことでもOKです。 # 感想など ## 目安の時間 - 1トピックにつき10分を予定しています - 盛り上がったら延長することもあります ## 疑問・参加者に聞いてみたいこと - みなさんが普段携わっているプロダクトはどれに該当しますか？ - 個人的な開発 - 社内カスタム開発:+1: - 外注カスタム開発 - 特定業種向けソフトウェア :+1::+1::+1::+1::+1: - 汎用ソフトウェア :+1: - 6.3.6 質問 にあるような外部の人たち向け(特定業種向けや汎用ソフトウェア開発に近い奴) :+1: - ※ どっちに入れていいか分からなかったので選択肢に追加しました - オンサイト顧客と真の顧客とプロダクトマネージャーとドメイン専門家の違いはなんでしょうか…？混乱してきました :heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861205523780861963) - オンサイト顧客 … P.29 チームが構築するソフトウェアを定義する…通常、プロダクトマネージャー、ドメイン専門家、インタラクションデザイナ、ビジネスアナリストがオンサイト顧客の役割を果たしている - プロダクトマネージャー … P.31 プロダクトビジョンを維持し、推進する　(別名、プロダクトオーナー) - ドメイン専門家 … P.33 対象となる分野の専門知識を備えたエキスパート - 真の顧客 … 普通の意味での顧客やエンドユーザー？ - みなさんの現場で、顧客の意見を吸い上げるためにやっていることはありますか？(上記のプロダクト種類と合わせて回答もらえると嬉しいです)　:+1::+1::+1::+1::+1::heavy_check_mark: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861220942508589066) ## 感想・気づき ### 6.3 真の顧客の参加 （著者サイトの99語まとめ) - https://www.jamesshore.com/v2/books/aoad1/real_customer_involvement - > To widen your perspective, involve real customers. The best approach depends on your market. Personal development: you are the real customer. Congratulations. Go forth and write algorithms. In-house custom development: turn your real customers into on-site customers. Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently. Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing. - > 視野を広げるために、実際のお客様を巻き込む。最適なアプローチは、市場によって異なります。:+1: 個人開発：あなたが本当のお客様です。おめでとうございます。さあ、アルゴリズムを書きましょう。 自社カスタム開発：本当のお客様をオンサイトのお客様にする。 外注開発：本当のお客様に現場のお客様になってもらう。できなければ、連絡を取り合い、頻繁に顔を合わせよう。 縦型市場(特定業種向け)と横型市場(汎用)のソフトウェア：一人の顧客に支配力を与えすぎることに注意する。プロダクトマネージャーを任命し、お客様のニーズを把握する。フィードバックを募る機会を設ける。例：カスタマーレビューボード、ベータ版のリリース、ユーザーエクスペリエンステスト。 > ベストなアプローチは、誰のためのソフトウェアを作っているかによって違ってくる:+1: - 真理だなぁ。何かのやり方を真似るだけでは上手く行かない理由を端的に表現していると思う。 ### 6.3.2 社内カスタム開発 > 視野が狭くならないようにするために、プロダクトマネージャーとオンサイト顧客は同僚からのフィードバックを集めるべきだ。 - ここの精査が難しいんだよなぁ。ステークホルダーが多い場合は委員会的なものを作って全員参加でデモして計画を議論する、というのが理想なのかな。 :+1: > この環境では、チームには複数の顧客がいる。ソフトウェアにお金を払ってくれるエグゼクティブスポンサーとソフトウェアを使うエンドユーザだ。彼らの目標は一致していないかもしれない - 意外とこれが難しいかもしれないと思っている。社内ユーザーの声が届きやすい分、いろいろとブレやすい気がしている:+1::+1: ### 6.3.4 特定業種向けソフトウェア > プロダクトの方向性を真の顧客に過度にコントロールされないよう注意する必要がある - それな×100:+1::+1: - ×100 - 真のユーザー参加というタイトルでビビったが、アジャイル開発ではユーザーをチームに巻き込んで開発しなければならないプレッシャーを感じでいたけど、実際にそうでも無いと書いてくれて正直ホッとした。 > 真の顧客をチームメンバーに入れるのではなく、フィードバックを求める機会を作ろう。重要な顧客をたくさん集めて、顧客レビュー審議会を作っている会社もある - さすがにチームメンバーに入れるのは現実的ではないから、CSと協力してユーザーヒヤリングやユーザー会で直に話を聞くっていうのが、このタイプの開発をしているチームの現実解な気がしている ### 6.3.5 汎用ソフトウェア > 真の顧客が汎用ソフトウェアの方向性をコントロールしないよう制限を設けたほうが良いだろう - 外販を視野に入れている開発で社内にもユーザーが居るので社内ユーザーの特殊要件をリジェクトすることで関係性が悪くなった経験あります。 - この問題、難しそう - 「社内ユーザーの意見を鵜呑みにしないように」という合意が伝え漏れて険悪に。。。 >社内のプロダクトマネージャが、すべての顧客のニーズに基づいて説得力のあるビジョンを作るのがよりよい選択だ。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861206998887956490) - わかる！でも、そんなお方は何処にいるの？もしくは、どうやったらそんなプロダクトマネージャーになれるのかが知りたい。:+1::+1::+1::+1::+1::heavy_check_mark: - 最近のSaaSとかもこれに当てはまる感じかな ### 6.3.6 質問 > Q. 真の顧客をチームに入れることができないときには、誰をオンサイト顧客にすればいいのでしょうか？ > A. あなたの組織はプロダクトマネージャとドメイン専門家を用意してくれるはずだ。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861218105950208010) - ドメイン専門家を用意してくれる会社にお勤めの方どれぐらいいるのか気になる。:+1::+1::heavy_check_mark: ### 6.3.8 使用上の注意 > エンドユーザーは全く新しい方法を見つけるという観点ではなく、既存の方法を改良するという観点で考える事が多い。これが、エンドユーザーは参加すべきだが、彼らに主導権を握らせるべきではないというもう1つの理由だ。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861214006529753108) - これかなり大事なのでは？エンドユーザーの意見に引きずられて本質的な対応に時間が割けなくなるケースがよくある気がする。:+1::+1::+1::+1::heavy_check_mark: - 「既存のやり方をうまくやる」を、インタビューした相手は喋りたくなりますね。なまじ、「こんなふうにできたらいい」みたいなアイデアも持ってたりして固執してしまう。「本当にやりたかったこと」に立ち戻って会話できるようにするまでが難しいことが多い。 > プロジェクトは常に説得力のあるビジョンに基づいているべきだ。 - プロダクトの方向性と異なる要望を安易に取り込むと、キメラなソフトウェアができてしまいますよね。 - こういった話を聞くと、自動車を作ったヘンリーフォードの話を思い出しますね。:+1::+1: - 『もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答えていただろう。』 ### 6.3.9 代替案 > 真の顧客の参加は役に立つが、不可欠だというわけではない。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/861210715305672736) - 顧客の声を確認することと、顧客の声に囚われすぎない事のバランスなんだろうと思う。顧客の声を聞かないで失敗することが多いから、「じゃあインタビューだ！」となるけれど、盲信しないようにしないと。:+1::+1::+1::+1::heavy_check_mark: - インタビューの結果は重要視してしまいがち。この切り分けできる優秀なプロダクトマネージャーが求められる。 - 真の顧客の参加は必須かと思っていたから、これは意外だった :+1::+1::+1::heavy_check_mark: ---- ## ミニエチュードの質問 * ミニエチュードは、このプラクティスに対して気づきを得るための質問です * 詳細はP76ページを参照してください * 以下の質問に、回答を継ぎ足していってください ### (このプラクティスを使ったことがなければ) - 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか？ - これまで経験したものとどう違うか？ - 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか？ ### (このプラクティスを使っているなら) - 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか？(気づいたことだけでいい、理由はいらない) - もし書かれているとおりに従うと、何が起こると思うか？ - このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか？(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ) - 意思決定力のあるオンサイト顧客を用意できたことがあります。チームは迷わず進むことが出来ていました。が、ある時その方の上司に呼ばれて「一担当者の意見ばかり聞かずに俺を見て仕事しろ」と言われてそれからブレにブレまくった思い出。 調整力・政治力いろいろ必要なポジションですね。:+1: