クネビンフレームワークとステークホルダの期待値コントロール
9/14更新 9/11にScrum Masters Night!でこのブログをネタにディスカッションさせていただいたので、その内容を踏まえて全体的に改訂
はじめに
ソフトウェア開発が扱うのはクネビンフレームワークの煩雑系（Complicated）と複雑系（Complex）で、アジャイルは複雑系に向くという話をよく聞くが、個人的には煩雑系もアジャイルでやればいいのでは？と思っていた。
しかし最近、ステークホルダの期待値コントロールという観点で考えると複雑系にアジャイルを導入するより、煩雑系にアジャイルを導入する方が骨が折れるということに気づいたので、記事に残しておく。*1
スクラムの成果のステークホルダへの見え方
クネビンフレームワークの煩雑系と複雑系を雑に言い換えると、煩雑系は（どうやるかはさておき）やればできる領域、複雑系はやってみないとわからない領域と言い換えられると思っている。
アジャイルだと開始時点で「いつまでに、何を」は約束できず、やりながら徐々に見積の精度を高めていくので、例えば半年とか一年とか、ステークホルダが気にするタイミングでのアウトプットとしては、「（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積」ということになる。
スクラムを導入する際には、あるタイムボックスで見たときのスクラムの成果が「（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積」になることをステークホルダに説明し、納得してもらう必要がある。ではこの情報が、複雑系のステークホルダと煩雑系のステークホルダの目にどのように映るかを考えてみる。
複雑系のステークホルダの場合
スクラムを一定期間実践すると得られる成果（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積が複雑系のステークホルダの目にどう映るかというと、これは価値ある情報として映るものと思われる。なぜならやってみないとわからない領域について、継続するにせよ撤退するにせよ、半年後には何らかのジャッジができるようになるからだ。なので複雑系の場合、ステークホルダへの説明は割とすんなりいくものと思われる。
煩雑系のステークホルダの場合
次に煩雑系の場合を考える。複雑系のステークホルダには価値があった（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積が、煩雑系のステークホルダにとって同じように価値を持つかというと、そうではないと思う。
なぜなら煩雑系のステークホルダは、煩雑系のプロダクトはやればできることはわかっているので、あとはいつ完成するかだけが知りたいと思っているからだ。
（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積は、ともすれば未完成の機能と、開発初期には出てこなかったのに今更出てきたスケジュールに見えてしまい、いつ完成するのかを気にしているステークホルダからすると、期待外れと思えてしまうのだ。
煩雑系にスクラムを導入するためにはどうすればよいか
上記で説明した通り、一定期間後の成果物という観点だけでステークホルダと話をすると、スクラムを導入するメリットがステークホルダには伝わらないので、スクラムを導入する側としては、スクラムの導入により、従来型の開発プロセスと何が変わるかをステークホルダに説明し、納得してもらう必要がある。例えばスクラム導入によるステークホルダのメリットには以下がある。
- 開発後期でも追加要望を出すことができる
- 紙の進捗資料ではなく動くモノとして進捗を確認できる
おわりに
本記事では、複雑系にアジャイルを導入するより、煩雑系にアジャイルを導入する方が骨が折れる理由として、煩雑系のステークホルダにとっては、スクラムの成果である「（優先順位が高い順に実装した）いくつかの動く機能と今よりも精度のいい見積」の価値が感じづらいこと、そのような場合にスクラムを導入するためには、ステークホルダにどんな説明をする必要があるかを述べた。
TDDワイワイ会その32参加レポート
はじめに
3/1にTDD+モブプログラミングでワイワイする会 その32に参加してきた。 スクラムマスターとして案件に参画することが多いが、XPの開発プラクティスの実践経験に乏しく困ることがあったので、手を動かして実感を掴みたいと思ったのが参加の動機。 この記事では「イベントの流れ」、「モブプロについての学び」、「TDDについての学び」の３項目で、イベントをふりかえる。
イベントの流れ
- 最初にイベント全体の説明があった。
当日の様子（@miholovesqのTwitterから拝借） - この日の参加者は12名だったので、4人チームを3つ作った。得意な言語でチーム分けするのかと思っていたが、そういうわけではなかった。
- チームごとに別れてから改めて自己紹介をして、今回使う言語と誰のノートPCを使うかを決めた。
- 次に使用する言語の選択。メンバの得意な言語はRubyとJavaだったが、みんなが知らない言語の方がモブプロ の力を体感できるということで、使用する言語にはあえてPythonを選んだ。（テストフレームワークはpytest）
- 最後にコーディングの題材をcyber-dojoから選んだ。
- 最後にイベント全体をふりかえって、片付けをして、イベントは終了となった。
モブプロ についての学び
- 楽しい
- スキル面で不安があって、実際足を引っ張ってしまう場面もあったが、モブプロだとフォローしてもらいつつ進めることができるので、いたたまれない想いはしなかった。それよりも「楽しい」の気持ちの方がずっと大きい。
- TDDワイワイ会は「テストが落ちると思って落ちた時」「テストが通ると思って通った時」はワーと拍手をすることになっていて、これも大いに場作りに貢献していた。
- 逆に「テストが通ると思って落ちた時」はみんないっせいにガタッ！となってエラー原因の特定に努めた。この一体感。これはこれで楽しかった。
- ドライバーはYouTuberのように声を出しながら手を動かすのが大事
- 可能なら椅子は人数分＋１つ用意するとよい
- 人数分だと毎回ほかのメンバとの入れ替わりが発生してしまうため）
- 可能ならノートPCは人数分＋１つ用意するとよい
- 他の人のPC触るのはけっこう心理的なハードルが高いことに気づいた。あと時間が経つとロックがかかってしまう。。。いちいち解除してもらうのもリズムを崩してしまう。
- リモートでモブプロするときはVS CodeのLiveShare機能がけっこういい感じというのをメンバに教えていただいたので、今度使ってみたい
- TDDワイワイ会のページにも貼ってあるMob Programming Startup Manualがモブプロの資料としてとても参考になった。
TDDについての学び
- 事前にt_wadaさんのFizzBuzzを題材にしたTDDのライブコーディングの動画を見て「歩幅の調節」を知識として知ってはいたが、実感がなかったので、そこを体感できたのはとても良かった。今回は初対面のメンバでモブプロしたので丁寧にやったが、業務にTDDを取り入れて慣れてしまえば、基本は明白な実装を前提として実装を進めて良いのかなと思った。
- すぐに実装イメージが合わないような難しい題材を扱う際、ホワイトボードを使った設計とTDDでの設計を、どうバランス取りながら進めるかというのは、難しい問題だと感じた。ここは経験を積んでバランス感覚を養うしかない気はするので、またTDDワイワイ会に参加して、"筋トレ"させてほしいと思った。
さいごに
イベント運営が大変な社会の状況の中、対策を講じた上でイベントを開催してくださった運営の皆様に感謝します。またぜひ参加したいと思います。
スクラム初心者お悩み相談参加レポート
はじめに
1/28(火)にアジャイルチームを支える会主催の「スクラム初心者お悩み相談」に参加した。（募集サイト）
悩み相談は、参加者の持ち寄ったスクラムの悩み事について、標準５分〜最大２０分で対話するという形式だった。
参加者は８名だった。冒頭のアンケートでスクラム実践前の悩みを抱える３名、スクラム実践中の中身を抱える５名でグループに分かれた。そこへ各２名の相談員の方に参加いただき、計５名のグループと７名のグループで対話をした。
私はスクラム実践前の悩みを抱えるグループに参加した。対話の時間はおよそ１時間で、この間に５個くらいのトピックについて対話をした。
いずれの悩みも共感せざるを得ない悩みで、相談員の方のコメントもとても参考になった。
ここではその中から、私が一番聴きたかった、QAチームとの連携に関する悩み相談と相談結果を共有する。
悩み
上記のポストイットを説明する際に、口頭で説明した内容を補足すると、悩みは以下の通り。
- 初めてのスクラムチーム立ち上げに際し、従来のQAチームとどう連携するか？
相談結果
参加者の方、相談員の方と対話させていただき、自分の中では悩みは解消した。（とりあえず次の一歩を踏み出せそうという感触を持てた。）
対話した内容と、それを受けて考えたことをまとめると以下の通り。
- 従来のQAチームが何をしているのかを理解することは次の一歩を踏み出すために大事なので、資料を展開してもらうなり、対話をする必要がある。
- QAチームのメンバ（例えばモチベーションの高い若手など）を自分たちの案件にステークホルダの位置付けでアサインしてもらい、一緒に品質保証に向けた取り組みを進めるのは効果的。（その後スクラム案件が拡大することを見越すと、試験項目の内容を見てもらったり、完了の定義を一緒に検討するのも良さそう。）
- QAチームと話す際は、ウォーターフォール案件かスクラム案件かという観点で話す必要はない。「お客様に価値を早く提供するためには、どう連携できるか？」という観点で話をした方が良い。
- 早い段階で成果物を見せてもらうというのは、QAチームにとっても嫌な話ではない。最後の最後に品質の低い成果物を持ってこられて打つ手なし、となるよりは、早い段階で品質の低い成果物を見て早めにその旨をフィードバックをする営みをしたほうがお互いによい。こういった営みをする時、実はQAチーム側としては対応稼働は従来から増えない。それに対してスクラムチーム側は、QAチーム用の環境を構築してメンテする必要があるので、対応稼働は増えるので、そこはスクラムチームが頑張る。
- このあたりも実践しないとわからない知見だと思う。教えていただけて大変有難かった。
悩み以外の対話内容
上記の悩みに関連して、調査する中で気になったことを２点伺ってみた。
スクラム案件が増えた際にQAチームがボトルネックになる懸念ついて
- QAチームがスクラムチームに寄り添う（≒各スクラム案件に担当者をアサインしてサポートする）事例は素晴らしいと思うが、スクラム案件が増えると、QAチーム側がボトルネックになるというリスクはある？
海外事例について
- アジャイル関連の書籍を見ると、基本的にはスクラムチームがリリースの判断をすべきとある。「スクラムチームでリリースの判断ができる」というのは、海外だと元々QAを専門としていたメンバが開発チームの一員となっていて、品質保証に人一倍の責任を持っているから成り立っているのではないか？と仮説を立てたのだが、海外事例などご存知か？
- その側面もあるかもしれないが、大切なのはその場合でもリリース判断しているのは、QAの専門家ではなく、スクラムチームだということ。
- 質問の背景として、日本の開発現場だと、チームにQAの専門家がいるのではなく、QAの組織が別にあり、そこがリリース判断に関与するので、日本の開発現場って、海外に比べて品質保証の意識が薄いのでは？という仮説を持っている。（この仮説が全くもって違うかもしれない。） そうした時に、品質保証について意識の薄いスクラムチームが「アジャイルだとクオリティゲートは設けず、チームでリリース判断するんですよー。それが普通ですよー。」みたいな形で上位層を言いくるめてリリースして、結果として故障が出て、上位層が「アジャイル駄目じゃん」みたいになってしまわないかという懸念があったので聞いてみた。 「アジャイルになってQAチームの役割は変われど、QAチーム自体はなくならないと思う。」とおっしゃっていた相談員の方もおり、自分もそんな気がした。
- その側面もあるかもしれないが、大切なのはその場合でもリリース判断しているのは、QAの専門家ではなく、スクラムチームだということ。
おわりに
品質保証という難しい悩みについて、相談会でここまで色々な学びを得られるとは思っていなかったので、本当に有難かった。悩み相談にのってくださった相談員、参加者の皆様、ありがとうございました。
アジャイルマインド・インストレーション体験セミナー参加レポート
有償ワークショップのダイジェスト版を無料で体験できる太っ腹なセミナーが開催されるということで、1月24日にグラーツ社主催のアジャイルマインド・インストレーション体験セミナーに参加してきた。（募集サイト）
このセミナーは13:30-16:30の半日のセミナーで、前半講演、後半ワークショップという構成だった。
参加者は15名くらいで、3〜4人のグループを4つ作ってワークショップに臨んだ。
参加者の属性は、SM経験者が半分くらい、PO, Dev経験者が数名、スクラム未経験者が2名くらい。
講演とワークショップの内容は以下の通り。
講演「アジャイルコーチと辿る価値と原則」（30分）
- アジャイルソフトウェア開発宣言の4つの価値と12の原則、スクラムガイドの理論・価値基準・チームの紹介と、スクラムにおけるマネージャの役割の説明がメイン。
- スクラムにおける"確約"を『スポーツ選手が「必ず勝ちます！」と試合前に宣言するようなイメージ』と説明していて、すごくいい説明だと思った。パクろう。
- マネージャの説明はエッセンシャルスクラムとLeSSからの引用が多かった。マネージャとチーム間の権限委譲については、エッセンシャルスクラムに掲載の以下の表を参照しながら話すとスムーズとのこと。
Appeloによる7段階の権限レベルとその実例 （エッセンシャル スクラムより） - 組織にアジャイルを広める際には書籍「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」がとても参考になるとのことだった。読もう。
- あと、昨年 技術書展で頒布された「アジャイルコーチからのアドバイス」についての言及もあった。読もう。500円だし。
ワークショップ「スクラム・ペルソナ・ロールプレイ」（120分）
受講者がセミナ申し込み時のアンケートに記載した「アジャイル・スクラムの困りごと」から各グループ１つテーマをピックアップし、そのテーマについてPO/SM/Devの視点で「問題への向き合い方」「対処」「予防」をディスカッションするというワークショップ。
「ペルソナ」とある通り、架空のスクラムチームのペルソナを用意して、そのチームが受講者の挙げた「アジャイル・スクラムの困りごと」に遭遇した場合にどう対処すべきかをディスカッションする。
ワークショップに当たって決まっていることはスクラムチームのペルソナのみで、スクラムチームが作るプロダクトのカテゴリやスクラムチームのロケーションといった細かい点については言及がなく、グループで仮定を置いてよいということで、以下の２点から丁度よく抽象化されているという印象を持った。
各グループの取り組む「困りごと」が、他のグループと被らないように決めたら、まず自分たちが取り上げた「困りごと」について30分ディスカッションし、PO/SM/Devの視点で「問題への向き合い方」「対処」「予防」をポストイットに書き出して、模造紙に貼る。模造紙は以下のような構造になる。
PO SM Dev どう向き合うか どう対処するか どう予防するか 次に隣のグループに移って、隣のチームが取り上げた「困りごと」について、20分ディスカッションする。（２回目以降は、前のグループが貼ったポストイットが残っているので、まずはそれを参照して、共感したらシールを貼った。）これを４チーム分繰り返した。
今回選出された４つのディスカッションテーマと最終的な模像時の状態は以下の通り。
テーマ：個別最適の考え方が強く、全体最適の考え方を持ってチームが行動できていない 
テーマ：品質とスピードをトレードオフの関係で捉えてしまう 
テーマ：SMがアジャイルもスクラムもよくわかっていない 
テーマ：ビジネスサイドは日本、開発チームは海外子会社という環境で、効果的にスクラムを浸透させる方法が知りたい - なお「どう向き合うか」には、基本的にアジャイルの価値や原則、スクラムの理論や価値基準から選んだワードを記載する。（その他でもOK。）以下はワード選びのために配布いただいた資料。
アジャイルやスクラムの価値・原則が載っている資料
感想
- スクラムのセミナーというと、ともすれば自己組織化の話やフレームワーク（ロール・イベント・成果物）の話が中心で、アジャイルの価値や原則、スクラムの理論や価値基準の説明はさらっと流してしまうこともあると思うが、このセミナーはアジャイルの価値や原則、スクラムの理論や価値基準について、受講生にしっかり考えさせるプログラムになっていて、とても勉強になった。
- また普段はスクラムチームにおける自身のロールを前提として価値や原則を考えがちだが、このロールプレイは一回そこをクリアして、PO/SM/Devそれぞれの視点から、価値や原則に基づき、具体的なアクションを追求できるという点も勉強になった。
- ぜひ組織に持って帰ってほしいということだったので、折を見て自社でもロールプレイをやってみたいと思う。（KPTの結果、なかなかTryに取り上げられない重めのProblemがあった場合には、このロールプレイのテーマに取り上げると、アジャイルやスクラムの価値や原則と照らし合わせて、フラットなディスカッションができて良さそう、という印象を持った。）
スクラム関連書籍の簡単な書評とオレオレ読書術の紹介
８月はスクラム関連の書籍を３冊読んだ。
この記事ではそれぞれの簡単な書評と、３冊を読みながら編み出したオレオレ読書術を紹介したい。
簡単な書評
エッセンシャル スクラム
- スクラムガイドには載っていないスクラム開発の具体的なノウハウが載っている書籍
- スクラムガイドが将棋のルールについて述べた本だとするなら、この本は将棋の定石について述べた本というイメージ
- この書籍を初めて手に取ったのはAgileJapan2019に設置してあった旅するアジャイル本箱だった。当時は計画会議の具体的な進め方（１部制？２部制？）や見積の単位（ストーリーポイント？時間？）について、人に説明できるほどの理解がなくて困っていたので、旅するアジャイル本箱の書籍を読みまくったのだが、そのあたりの具体的なノウハウが載っているのは、この書籍だけだったように思う。
- スクラムマスターなど、スクラムを推進するような立場の人は手元に置いておいて損はないと思う。私はスクラム関連の書籍で一番のおすすめは？と聞かれたら、この本を挙げる。
スクラム現場ガイド
- ３冊の中だと一番おすすめしない
- 各章の構成が、冒頭でよくある失敗事例を紹介し、その後失敗を回避するための教訓を紹介する構成になっているのだが、この失敗事例に出てくる登場人物が毎回違うので、まずそこを理解しなければいけないのがだるい。読書の量に対する学びが少なく、コスパが悪いと感じた。
- 取り上げられている教訓も、他の書籍で述べられているものが多い印象だった。「28 章アウトソースとオフショア」、「30章 契約の記述」あたりのトピックは初見だったので勉強になった。
- この書籍を読むよりは、カイゼン・ジャーニーを読んだ方がいいと思った。スクラムのノウハウを、江島さん主人公の物語形式で学ぶことができて、一貫性もあって、感情移入もできるため。
アジャイルコーチング
- スクラムマスターやアジャイルコーチの立場の人は、読んでおくと良いと思った。私はコーチングの経験がほとんどないままスクラムマスターになったため、自身がアンチパターンに当たるコーチングをしていないか若干の不安があったが、この書籍を読む限りそういったことはなさそうだと思え、自信に繋がった。
- ただスクラムの経験、コーチングの経験の両方を有している人であれば、それほど目新しいトピックはないはずなので、読まなくても良いかと思った。
オレオレ読書術
簡単に言うと、電子書籍をスマホの音声読み上げで聞きつつ読書するという読書術。
昔から音声読み上げ機能を使った勉強はしていたが、今回はその音声読み上げ機能を、読書の補助ツールとしてがっつり使ったという感じ。
ちなみに音声読み上げ機能を使った勉強方法についてはこちらで詳しく述べました。
必要なもの
スマートフォンだけでもいいが、個人的には電子書籍リーダーがあった方が、以下の点が良い
- スマートフォンのKindleアプリより電子書籍リーダーの方がハイライトしやすい（端末が大きい&慣れている）
- スマートフォンのKindleアプリの方は音声読み上げ機能が勝手にページ送りしてくれるが、電子書籍リーダーの方は（当たり前だが）ページ送りしてくれず、ボタン押してページ送りする必要があるので、少しだけ寝落ち防止になる気がする笑
メリット
- ただ読むより集中できるので、書籍を早く読むことができる
具体的にどれくらいの速さで書籍を読むことができるか定量的に示したかったので、アジャイルコーチングの各章を読むのにかかった時間を計測してみた。
- 1章 23分
- 2章 17分
- 3章 24分
- 4章 20分
- 5章 24分
- 6章 18分
- 7章 25分
- 8章 15分
- 9章 18分
- 10章 21分
- 11章 24分
- 12章 16分
- 13章 18分
- 14章 15分
ということで、4時間38分（278分）で物理の本だと236ページの書籍を読み切れたらしい。
個人的な感覚だが、書籍一冊をこの時間で読み切れるのってだいぶ早い気がするので、今後もこのオレオレ読書術を使って、スクラム関係中心に様々な書籍を読みたいと思う。
第25回 Scrum Masters Night!参加レポート
はじめに
第25回 Scrum Masters Night!に参加してきたので、簡単にレポートします。初参加でしたが、めちゃめちゃ勉強になった&楽しかったです。
イベントの流れ
まず参加者は、事前に考えてきたディスカッションテーマを紙に書きました。次にディスカッションテーマを集めて投票し、テーマを９つに絞りました。その後は話したいテーマ毎に席に分かれて、途中参加・途中退席OKの形式でディスカッションを１時間行いました。（こういったディスカッション形式をオープンスペーステクノロジー（OST）というそうです。）
取り組んだディスカッションテーマ
私は、希望した「スクラムチームの状態を可視化するためのメトリクスと、その取り方」というテーマが９つのテーマの１つに選んでいただけたので、このテーマについてディスカッションしました。人数の増減ありつつ、５〜１０名くらいの方でディスカッションしました。ディスカッションテーマ記載用紙は以下のような感じです。
メトリクスについての６つの学び
みんなが見ているメトリクス、見てないメトリクス
- ベロシティはみんな見ていた。ストーリーポイントで見る方、時間見積で見る方、両方見る方と様々でしたが、みんなベロシティは見ているということでした。見る観点としては、予実の乖離、スプリント毎のブレなど。
- サイクルタイムはみんな見ていなかった。これは少し意外だった。収集&評価が面倒という声があり、そうですよねぇと思った。
目標あってこそのメトリクス
私がこのディスカッションテーマを選んだ背景としては、「外部のステークホルダにスクラムチームの（改善の）状態を数値として見せるためにはどうすればいいか？」というのが念頭にあったので、最初はその方向で話をしていました。ですが参加者の方の「メトリクスを取る際は、今のスクラムチームの目標がないと、意味のあるメトリクスは取れないと思う。それなしでメトリクスを取っても、メトリクスに踊らされることになりかねない。」というコメントにはッとさせられました。その方は具体的に以下のように目標に対するメトリクスを設定して、目標を達成できたらメトリクスは捨てていたそうです。
- 目標：スクラムイベントを極力減らして、価値を届ける時間に回したい
- メトリクス：スクラムイベントにかかる時間を計測
- 目標：使われる機能だけを作りたい（＋メンテしたい？）
- メトリクス：ロギング機能を仕込んでログから各機能の使用率を算出
自己組織化のメトリクス
- この話題になってディスカッションがカオスになった。自己組織化おそるべし笑
- ちょっと違うけど、クロスファンクショナルのメトリクスとしてはスキルマップが有効という話になった。
品質のメトリクス
- これが品質のメトリクスだ！というのはなくて、むしろスクラムには動く成果物があるのだから、それをスプリントレビューでしっかり見るのが第一、という話になった。
- 周りがウォーターフォールでリリース時に承認スタンプラリーやっている環境でも、スプリントレビューでお客様がOKを出してくれているのであれば、リリース承認時のスタンプラリーをスキップできる、という整理をしているスクラムチームもあるとのことだった。
メトリクスの取り方
「メトリクスを手動で取るのは辛くなってやらなくなるからアンチパターン、メトリクスを取るなら自動で取れる仕組みを入れよ！」みたいな話を聞いたことがあったので、その辺りを聞いてみたところ、皆さんその辺りにこだわりはないようでした。特に目標に沿ったメトリクスを取得するという文脈でいうと、チームの目標にぴったり合ったメトリクスが自動で取れることなんてそうそうないから、最初は全然手動でやるという話だった。それで目標が達成できた段階で、もう不要だとねといって捨てるメトリクスもあるし、継続的に必要なら自動化を考えればいいということだった。
カラーコードドット
チームの状態を可視化する方法のひとつとしてカラーコードドットというものもあるよ、と教えてもらったので、こちらについても調べてみようと思います。
ディスカッション時に作成した模造紙は以下のような感じです。
おわりに
ただただ学びしかないイベントでした。主催者の皆さま、参加者の皆さまありがとうございました。今日の学びをうまく消化して、明日からの業務に役立てたいと思います。
Design Research Tokyo: Season 1 Episode 6参加レポート
[6/22 追記]
- 雰囲気がわかるよう、Design Research TokyoのTwitterに載っていた写真を追加
- 登壇者の方の資料・ブログへのリンクを追加
6/17に六本木のDMMで開催されたDesign Research Tokyo: Season 1 Episode 6に事業会社枠で参加したので、簡単にレポートする。 今回の勉強会は、参加者同士のワークショップあり、「リサーチチームの組織力」がテーマのトークあり、たっぷり時間をとったQAタイムありと盛りだくさんでとても楽しかった。
ワーク
「私」「自分の所属する部署」「顧客と接点のある部署」およびその繋がりを簡単に図示して、近くの席の人と共有した。私のグループは事業会社の人が多かった。経営者の方もいた。
トーク
リサーチチームの組織力（DMM） 伊藤さん
- UXリサーチャー
- 2009年頃 UXとの出会い
- 産業技術大学院大学人間中心デザイン履修証明取得
- どんどんサービス作る会社ならリサーチが必要になるだろうと思って2017年にジョインした
リサーチの組織
- 専門組織はない、なくなった。
- どうやってリサーチの業務をやっているのか？
- 個別に来た話をきっかけにやっている。
- もともとUX部があったけど、なくなって、メンバーはちりぢりに。
- ただ逆にUXリサーチが認知されやすくなった
- UXリサーチ相談の例
- 競輪のUXリサーチに行った。その場でかけてみて、チームで使いやすい、使いにくいの評価をした。これは良かった。
リサーチチームの組織力（メルペイ） 松薗さん
- 資料：メルペイ リサーチチームの組織力
- ブログ：リサーチチームの組織力
- 登壇時点で資料公開されてたので、特にメモは取らなかった。
リサーチチームの組織力（LIFULL） 小川さん
- 資料：リサーチチームの組織力 評価からデザインリサーチヘ
- ブログ：リサーチチームの組織力
- 人間中心デザイン受講
- UXリサーチではなく、組織横断で定性評価をメインにやっている。
- 以下の通り、下流工程から徐々に上流工程に食い込んでいっている
- 運用前の評価：操作性を評価 使えるかの評価
- 設計・開発の評価：仕様を評価 伝わるかの評価
- 要件定義の評価：コンセプトを評価 魅力的かの評価
- 人がデータベース化してしまって、スケールしないところが問題点
- メルペイの松薗さんの話と共通するところ多い
- これから試したいことは、プロジェクトチームに「すこしできる人・すこしわかる人」を増やすこと
ディスカッション
- ３名の方のトークを聞いて、グループでディスカッションした。トークの中で以下の話題はスピーカーの中で共通するところあって、印象に残ったという話をした。
- 組織にこだわらずUXリサーチを（勝手に？うまいこと？）やって、社内で信頼を得る
- 「成果物の検証」工程からUXリサーチとしてチームに協力して、徐々に信頼を得て上流工程にも入り込む
- 人が少なくてスケールできない点に課題感を持っている
- 私は、下流工程から始めて徐々に上流工程に行くという話と、３名中２名の方が産業技術大学院大学の人間中心デザインを受講したという話が印象に残った。産技大の授業いいのかな。受講したいな。
- あとディスカッションの中で「肩書大事」って話をした。私はそれまで肩書を自由に決められちゃったら、肩書の意味がなくなるのでは？と思っていたが、従来の肩書に加えて、自分が名乗りたい肩書を設定することで覚悟を決めたり、情報を集めやすくするのは大事かもな、と考え直した。よく考えると、肩書以前の部署の名前についても、その部署の現在の姿（AsIs）というより、その部署のなりたい姿（ToBe）を表している、ということはざらにある気もするし。（今の私の所属組織がそうだとは言う訳ではない）なので、肩書だってある程度自由度持たせてもいいのかもなと思った。
