スクフェスオーガナイザー川口恭伸が全国のスクフェスにズームイン！！

地域トラックの見どころを紹介しちゃいます！！！

朝から盛り上がっていきましょうね！！！

Confengineをながめながら、こう考えた。
智に働けば角が立つ。組織に棹させば流される。意地を通せば懲罰だ。とかくに人の世は住みにくい。
住みにくさが高じると、安い所へ引き越したくなる。どこへ越しても住みにくいと悟った時、体験談が生れて、笑いが出来る。
組織を作ったものは神でもなければ鬼でもない。やはり向う三軒両隣にちらちらするただの仲間である。ただの仲間が作った組織が住みにくいからとて、越す会社はあるまい。あれば人でなしの会社へ行くばかりだ。人でなしの会社は仲間が作った組織よりもなお住みにくかろう。
越す事のならぬ世が住みにくければ、住みにくい所をどれほどか、くつろげて、束の間の命を、束の間でも住みよくせねばならぬ。ここに雑談師という天職が出来て、ここに漫談師という使命が降る。あらゆるアジャイルの士は組織をのどかにし、人の心を豊かにするが故に尊とい。

Fun Done Learnが誕生してまもなく5年。

これを機に原点回帰してチームとして本質的にアジャイルであり続けることとはどういう意味なのか、そのためには何が大事なのか、そしてそれがどうFun Done Learnに繋がったのか、ふりかえります。Fun Done Learnで。

このセッションで伝えたいこと

本セッションでは、製造業にアジャイルコーチとして入社したSatoshi Haradaが、社内アジャイル勉強会コミュニティの火を燃やすために何を考え・何をしているのか、可能な限り全部お見せしようと思います。

このセッションを見た方には、社内でアジャイル勉強会コミュニティを立ち上げた実例を知っていただきます。そして、社内アジャイルコミュニティを立ち上げよう・盛り上げようと思っている方に、コミュニティ活動はFUNが大事であることを知ってもらい、一歩目を踏み出す勇気を持って帰ってもらいます。

私が社内コミュニティ活動を開始した理由

現在の会社にアジャイルコーチとして入社して4カ月になりました。
勤めている会社は、創業150年・従業員数4500人超の国内製造業です。

この会社では既にDXやアジャイルといった取り組みが進んでおり、スクラムの研修開講やプロジェクトでのアジャイル適用が行われていました。素晴らしいことです。

この素晴らしい取り組みをさらに加速させるためには何が必要だろう？
そう考えた私は、もっと”FUN”が必要で、そのための社内コミュニティ活動の楽しい"場"が必要だと感じ、行動を始めました。

・社内のアジャイルコミュニティをもっと楽しく！さらに盛り上げたい！
・有志による楽しい学びの場を作りたい！

そんな気持ちで、社内のアジャイル勉強会コミュニティを自ら立ち上げて運営を開始したのです。

しかし、順風満帆・全てがうまくいっているわけではありません。
　勉強会に誰も来ない…
　盛り上がらない…
　運営が大変…
　自分だけが運営を頑張っているのかも？
そんなふうに思うときもありました。

そんなとき私は、「コミュニティ運営は焚火に似ている」と思うことにしています。
焚火は火をつけてからだんだんと太い薪に着火させて炎を大きくしていくのですが、その様がコミュニティ運営に似ていると思うのです。

そこで私は、社内アジャイル勉強会のコミュニティでいろいろな企画を投下してきました。焚火でも薪を投入する順番はよく考える必要があります。コミュニティ運営も同じです。
その結果、少しずつではあるのですがコミュニティ参加者が増え始め、勉強会の運営も参加者が主体的に関わってくれるようになってきています。

そして忘れてはいけないのは”FUN”です。焚き火も楽しいですよね？コミュニティ活動にも楽しさは不可欠だと思うのです。

なぜこのセッションをやろうと思ったか

私の社内アジャイル勉強会コミュニティの立ち上げと運営はまだ4か月ですが、まだフレッシュな状態で私が何を考え・何をしてきたかを発表することで、同じように社内のコミュニティを盛り上げたい！と考えている人の背中を押すことができるのではないかと思いました。

社内でアジャイルを進めるにあたって、「仲間がほしい」「共通の話題で相談できる場所が欲しい」「学びを深めることができる場所が欲しい」と思ったことはありませんか？
もしまだそのような場がないという方、ぜひ自らそのような楽しい場を立ち上げましょう！

そのような一歩目を踏み出す方に勇気を持って帰ってもらえる焚火のようなセッションにしようと思います。

私達について

私達は楽天グループでラクマというフリマアプリを開発する部署に所属しているSoftware Engineerでして、主に広告や事業者向けの機能を開発しています。

ラクマは現在楽天グループが運営・開発しておりますが、前身は日本初のフリマアプリ「フリル」でして現在は3500万ダウンロードされております。

私達3人は同じチームに所属しているのですが（マネージャーを含めると4名体制です）、基本的に毎日始業から終業までをほぼモブプログラミング・モブワークをしています。（以下モブワークと総称します）

チームとしてもScrumを取り入れていて、ほぼ全てのバックログをチームで取り組んでおり究極の一個流しをチームで実現させようとしています。

毎朝Daily Scrumでその日に取り組む事を皆で話し合って決め、そこから途中こまめに休憩を挟みつつ基本1日中終業までモブワークを行っています。

これまではリモートで仕事をすることが中心だったので、Zoomを繋げっぱなしにしつつコードシェアをしながら役割を10分タイマーで交代しながらモブワークをしています。

コロナが落ち着いてきて関係で楽天では出社が増えてきておりまして、全員出社してる時は一つの場所に集まって同じ画面を見ながらワイワイモブワークをしています。

モブの皆さんと呼ばれるまで

私達は今組織の中で「モブの皆さん」と呼ばれています。

これは個人としてではなく、チームとしてモブワークを実践してきた事が周りの皆様にも認知してもらっている結果だと思っています。

ですがチームが出来た1年半ほど前はそんな事は全くなくて、発足当初はメンバーの4名中2名が入社したばかりでRails経験が浅い状態かつOJT中だったのもあってか、多くの課題を抱えていました。

• 業務の量に偏りがある
• レビュアーがいない
• さらに育成者もいない

そしてリモートワークが長引いていた関係で、メンバーの一人一人が不安を抱えながら開発をしていたという状況にもなっていました。

そんな状況を見て当時のマネージャーがモブワークを取り入れてみることを勧めてくれました。

そこからおよそ一年半、チームメンバーが減ったり、新しく増えたりなど色んな歴史を経て今に至っています。

途中チーム外の方から「分担作業の方が良くない？」というご意見をいただいてうまくチームとして方針を伝えられなかった事がありましたが、その時はマネージャーが間に入って盾となってくれて色々と関係各所との調整を行ってくれました。

試練の訪れと振り返りのきっかけ

そんな私達に大きな衝撃が走ったのは、私達にモブワークを導入して支援してくれ、チームの文化を築いてくれたマネージャーの退職が決まった時です。

当たり前の事なのですが盾となってくれていたマネージャーがいなくなった事で「これからは自分達で戦っていかないといけない」となり、改めて「私達はなんでモブワークをしているんだっけ、なんで良いと思ってるんだっけ」と考えさせられました。

そこからモブワークについて改めて調べ直し、言語化していく中で他チームから「モブワークについて教えてほしい」と言われる事が増えてきました。

自分達では何かを教えられるほどモブワークについて上達したつもりはなかったのですが、それでも通ってきた悩みや良かったことを共有することで双方で学びや発見がたくさんある事に気付けました。

これからの私達

現在絶賛トライ中なのが「目標設定とモブワーク」の問題です。

私たちも会社員ですので、目標設定とその評価というビッグイベントから逃れることはできません。

チームとしてタスクを成し遂げるのに、目標を立て評価をされるのは個人単位です。

これにどう向き合っていくのが良いのでしょうか。

今季の目標設定では「チームとして共通の目標を作ってそれを個人目標に組み込む」という新しいアプローチを試みています。

これはマネージャーと相談して、チームでのモブ活動に対して理解してもらおうと試みた一例になりますので、皆さんに紹介したいと思っています。

今回のセッションでは以上のような私たちのモブワークの歴史を共有いたします。何かの発見や学びに繋がったら幸いです。

鹿児島の中学生に紙飛行機ワークショップを、

鹿児島の高校生にマシュマロチャレンジを、

それぞれスクラムを知ってもらうワークを実施予定です（5月と6月に）

ワークを通して感じたこと、ホットな情報をお話しできればと思います！

Scrum Festに参加する多くの方は、複数人でチームを組んで仕事をしていると思います。
また、所属するチームの外側には様々なチームがあり、複数のチームで構成される大きな組織の一員として働いている方が多いと思います。

そういった様々な人々が関わる中で仕事をしていると発生してくるものが「悩み」です。例えばこのようなものです。

お悩み例

• なんでうちの上司はペアプロの良さを理解してくれないんだろ…
• お偉いさんと営業が勝手にお客さんと約束してきちゃったけど…どうすんのこれ？
• 会社の方針が分かりづらいし、みんなバラバラに動いてる気がするんだよなぁ…

このような状況に身を置くのはツラいものです。ツラい環境にいるのは居心地が悪く、ストレスも溜まりやすいため、いくつかの反応を行います。

• 私は関係ない、どうでもいいや、と割り切る
• 自分1人でもできそうなことをやってみる
• 自分の意見をぶつける、愚痴を言う
• どこか違う組織に移る

悩んだ時に、どんなことを考え、どんなアクションを取るかは非常に重要です。うまくいけば悩みが小さくなったり解決することができます。

しかし、落とし穴もあります。悩みを解決できる、もしくは悩みを感じなくなるような良さそうなアクションを取った結果、長期的には悩みが肥大化することがあります。肥大化が進み、悩みがモンスターに育ってしまうと周りの人も自分自身も傷つけてしまいます。

私も過去に色々やっちまった経験があります。今になってはいい経験ですが、その時は「こんちくしょー！」と思ったものです。そういった経験から、悩みとの付き合い方を学び、悩みが育っていかない体になって来ました。今は悩みとか全然なさそうと良く言われますし、Scrum Fest 札幌ではこんなセッションをやったりしています。

本セッションでは、私の元気な話は置いといて、悩んでいた過去の話、そこから学んだこと、今悩みを抱えた時にどう捉えどう考えどう行動しているか、をお話しします。皆さんがお持ちの小さな悩みがモンスター化するのを防ぎ、皆さん自身も、周りの人も少しでもハッピーになることを期待してます！

受託開発の会社で強いチームをつくりたくて、現場と一緒にコードを書くアジャイル専門組織をつくりました！が、JTCの荒波に揉まれる我々！

• 期待している形で案件が来ない！
• 支援って、ちゃんと評価されるのか？給料下がっちゃうんじゃないの？
• ３年単位で大きく変わる企業の勢力図によってトップダウンのアジャイル推進活動の雲行きが怪しく！

毎年お送りしている田舎スクラムチームの状況をお伝えします！

・大規模ウォーターフォールの受託開発のマネジメントを大阪で10数年ずっと実施していたマネージャーがアジャイルでのプロダクト開発組織を作るべく、辞令をもらいました。短期間でアジャイルを学ぶため、どのような事をどのように学んだか？その中で感じた葛藤と解決策をお話しします。

前半パートでは
新たな用語だらけで、ウォーターフォールとの文化の違いが今一つわからない中で、短期間で学習する上でのTipsをお伝えします。

中盤パートでは
「ちょっと何言っているかわかんない」というワードを使いながら、新しいことを学ぶ際にわからない事を前向きに増やしていく重要性とそのマインドセットのコツをお伝えします。

後半パートでは
学習すればするほど、先人のアジャイル先駆者やアジャイルネイティブの若い世代と比べてしまい、恥ずかしさや今までの仕事に対して後悔を感じたこと。逆に学べば学ぶほど自社内では先駆者として孤立してしまうこと
それらに対して、過去の経験をプラスに活かし、仲間と共にどのようにポジティブに乗り越えたかを説明します。

　DXでのリスキリングの必要性が謳われている昨今、リスキリング対象のミドル層が、これから、新規ビジネス創出やアジャイルに取り組む際にヒントになれば幸いです。

＜前半パート(短時間で学習するTips)の事例＞
・本を読み、勉強会資料を作り、勉強会実施を繰り返して机上で学ぶ（「アジャイル/本」の検索ワードでトップとなる）
・アジャイル先駆者との過去時点のDiffを取る
・コミュニティが怖かったところから、３ヵ月で150本コミュニティの参加ブログを書くに至った変化

＜中盤パート(学習のマインドセット)＞
・「ちょっと何言っているかわからない」を重視した学習方法（「完全に理解した」⇒「ちょっと何言っているかわからない」を素早く繰り返す)
・Majorityならではのアジャイルの入り方 (EarlyAdopterと違ってMajorityは効果の確実性を気にする)
・仮説検証型の学習方法

＜後半パート (ミドルとしての乗り越え方)＞
・会社生活、折り返してから始めたアジャイルと20年間の意味
・仲間と乗り越える
・仕事だから(外発的動機)とやりたい(内発的動機)をマッチできるのはミドルの特権
・これから始めるミドル層へのエール

（本セッションでは組織の変化よりお個人の変化に着目しての説明となります。実際にどんな風に組織が変化したかは興味があれば参考資料を確認ください)

私が開発者としてコードレビューをするのは「コードは自分のもの」という意識があるからです。その意識は自分の所属チームだけにおさまりません。別チームがメインで変更を行うコードにも及びます。

今回のセッションではこのモチベーションとそれに伴う行動に至った私の体験談をお伝えします。

私は Rakuten Rakuma の開発組織に所属しております。 Rakuten Rakuma は開発メンバーだけでも大規模な組織であり、複数のチームがいくつかのアプリケーションを開発、メンテナンスしています。 Rakuten Rakuma に join した当時、まだ組織の開発スタイルがよくわからないので、とりあえず、組織内の主要な repository を watch することにしました。 Rakuten Rakuma に join する前に所属していた組織では、「pull request は open されたら自分の手を止めてでもレビューするのが当たり前」というような環境にいた事もあり、 join したてでわからないなりにもレビューをしてみようと思ったのです。このようなきっかけで組織横断でコードレビューをしてみると、だんだんと以下のような気持ちを持つようになりました。

• ユーザーに影響するような変更がプロダクトに入るのかどうかを知りたい
• 将来、自分が関わるかもしれないからどのような変更が入るのか知っておきたい

こういったことを経てどうやら私には「コードは自分のもの」、別の言い方で言えば、オーナーシップという意識が芽生えてきたように思います。

「コードは自分のもの」という意識でコードレビューを行っていくと、コードの変更を自分ごととして考えるようになるので、より真剣にコードレビューをするのは想像に難くないと思います。そして、他のチームのコードが気になって仕方がなくなってきます。そういった経緯で今日も元気に組織横断コードレビューを行っております。

一人の開発者のプロダクト開発への取り組み方を、楽しんでみてください。

G.O.O.D.テストとは何か？そして、なぜそれが誰にとっても大切なのか？

テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか？コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか？もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか？

もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

• G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。（Give）
• O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。（Observe）
• O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く（Open）
• D：エンドユーザーに対する安全性（例えば、プライバシー、セキュリティ、機密性）など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。（Determine）

特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか？

システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

G.O.O.D.のテストをしていますか？それともただのテストですか？

鳥取県に縁のある人あつまれ！

The biggest challenge for organizations is adapting fast enough before smaller, nimble competitors take their market. Creating an outcome-driven organization is about aligning every aspect of the business toward achieving the outcomes that matter. It requires a shift in mindset, processes, and culture. Gabrielle Benefield, with her vast experience in guiding organizations through Outcome Delivery for the enterprise, will delve into the essential principles and practices necessary to drive successful outcomes. 

プロダクト開発ではやりたいことは常にやれることより多いとはよく言ったもので、そのような状態下でも「今やること」は常に判断し続ける必要があります。そういった状況下で、私たちのチームはスクラムで進めていますがなぜスクラムでやり続けているのかリアルな状況をお話しします。さらに、今現在向き合っている課題とその課題をどのように乗り越えようとしているのかについてもお話しする予定です。

2016年のXP祭りで、牛尾さんがお話されていた内容の中でとても印象に残っていることがあります。（当時の資料が見つけられないので、記憶違いでしたら申し訳ないのですが）

それは、『大人になるというと、日本では「我慢する」というようなニュアンスが強いけど、アメリカでは「自分が幸せになれる行動をする」こと』というお話です。この考えを私はとても気に入っています。

自分にとっての幸せとは何か、ということを考えたときに、大事なことの1つとして「他人が考えた幸せではなく、自分の考えが持てること」があるのではないかと思っています。1人1人の人生は異なるので、何が幸せかも異なるはずで、それを決められるのは自分である、というような考えです。モティベーション理論でいうところの「外発的動機づけ」と「内発的動機づけ」の違いに近い話かもしれません。

このような「自分で決めたり、自分に合ったものを選んだりすることの大切さ」を表現するために、私は過去に以下のようなテーマの話をしてきました。

• 自己調整学習
• フロー理論
• 意思決定理論

たとえば、「自己調整学習」のテーマでは、「学びにおいて、自分に合ったものを自分で発見していくことが重要」という話をしました。

私がこれまで扱ってきた内容は「学び」に関するものでしたが、今回はPTMFというメンタルヘルスに関する内容をご紹介したいです。

誤解の無いようにしたいのですが、私はメンタルヘルスに詳しいわけでもありませんし、PTMFについても豊富な知識があるわけではありません。

ただ、PTMFの方法論は、自分を知ったり、自分の中の大切なことについて気付いたりするためのやり方として役立つものだと感じました。

もちろん、これで全てが解決するようなものではないと思いますが、1つの考え方として紹介させて頂きたいです。

PTMFは「パワー・脅威・意味のフレームワーク」（the Power Threat Meaning Framework）です。あるものごとが自分にとってどのような「パワー」「脅威」「意味」があるのかを自分の物語として考えます。

同じものごとであっても、人によって与える影響は異なります。同じ症状であっても人によってそこに行き着く過程は異なります。フレームワークを通じてこうした違いが生まれる自分の物語を掘り下げていきます。

では、実際にはどんなものになるのでしょうか？

このセッションでは、PTMFとはどんなものなのか簡単にご紹介しつつ、実際に私が自分の物語を考えてみて、その内容をお話したり、そうしたアクティビティを通じて感じたことなどをお話したいと考えています。

受託会社で複数チーム（案件）のアカウントマネージャーを務めています。

自分がエンジニアとして関わっている案件はともかく、現場には入っていない案件でもお客様がスクラムチームを組んでされるケースが増えてきました。

スクラムやアジャイルの経験の薄い社員が多く、社内でも積極的に指向する状態でない中、半期に一度の顧客満足度調査では社内でも人前で発言するのがけして得意ではないエンジニアがいるチームに対して「スクラムに積極に関わってくれないメンバーがいる（改善してほしい）」等のお客様からの声を繰り返しいただくことがあります。

また、逆に自社チーム側の進め方としてスクラムを取り入れたいと方法論を相談してくるメンバーもいます。

自身が関わっていない案件から聞こえてくるスクラムやアジャイルに関する疑問や悩み、取り組みなどをお伝えし、皆様からもぜひご意見等をいただきたいです。

あなたのチームでは、ふりかえり(レトロスペクティブ)のファシリテーションや事前準備を誰がおこなっていますか?

• ファシリテーションはスクラムマスターの仕事だから
• ふりかえりはスクラムマスターにとって丁度良い介入タイミングだから
• チームにまかせてもうまくいくかわからないから

様々な理由でスクラムマスターが担っているケースが多いかもしれません。

私たちのチームでもスクラムマスターである私が長いこと担当してきました。
しかし今年から3チームを並行して見なければならない状況になり、毎週3チーム分のふりかえり準備を一人でするのは現実的ではなくなってきました。

そこで悩みながらもメンバーに相談してみたところ、意外とすんなり引き受けてもらうことができ、今ではメンバーだけで問題なく（むしろ私より上手に？！）ファシリテーションや事前準備をこなしてくれています。

そして、そこから3チームそれぞれのチーム文化が生まれたり、チーム運営に積極的になるメンバーや、ファシリテーションの奥深さに興味を持つメンバーが出てきたりと、私自身も想定していなかった良い変化が現れるようになったのです。

ただ実は、今回すんなり受け入れてもらえた背景には、

• スプリントプランニングや朝会のファシリテーションをすでに段階的にメンバーに移譲していて、メンバーからの抵抗が少ないこと
• スクラムマスターがいなくても回るチームが理想なので、いつかふりかえりについても移譲したいと度々メンバーに伝えていたこと

などがあり、持ち回り制を成功させるにあたってのキーポイントが事前にいくつか存在していたように思います。
またスクラムマスターとしては「メンバーを信じて任せる勇気があるのかどうか」も試された一件でした。

そこで本セッションでは、ふりかえりを持ち回りにしようと思った背景や、うまくチームに移譲していくためのキーポイント、実際に起こった変化などについて詳しくお話することで、私が得た学びを皆さんに共有できればと思います。

現所属会社に転職後（半年前）、すぐにプロダクトチームの立ち上げを任していただくことになりました。

決まっていたのは「こんな感じのものを作る」ということと、メンバー二人だけ。

持っていたのは「やるんだったら最初から全力でアジャイル開発に取り組んで最速でアプリリリースをしたい」という情熱だけ。

転職前まではウォーターフォール開発しかやったことが無く、「アジャイル開発ってこんな感じなのかなー」と妄想していた妄想癖なPMが、実際にスクラムを通じてプロダクトを社内リリースまでこぎ着けたお話をしたいと思います。

「なかなか人集まらないねー…」

「そうかー、めちゃくちゃウォーターフォール脳だったわー」

「なんだか楽しそうですね？」

3か月が準備、その後3か月のスクラムの話ですが、それでも自分自身にとってはとても濃い半年でした。

このお話は、決して成功体験や高次元な概念やシステム、プロセスの説明ではなく、ただ単にイチ開発者がスクラムに触れて、これから成功したいと思う、失敗だらけのお話です。

だが、情熱はある。

背景

スクラムマスターという肩書を持って働いていた私。
4~5年経って気がついたのはスクラムマスターとはなにか？
価値を言語化できないまま、なんとなく過ごしていた事実だった。
組織にたいしてどう振る舞うべきなのか？答えられる自信はなかった。

なんとなく時間を過ごしてしまう環境に疑問を持った私は迷った。
全社的にスクラムが導入され、アジャイルなマインドがあるメンバーがいる環境。
ちゃんと専任となるスクラムマスターが認められた環境がある環境。
そんな環境で自分の中のスクラムマスターの価値を、自分の言葉で言えるようになりたい。
打席に立ちたいと思って転職を決意した。

しかし、入社して頑張り始めた時、チームから返ってきたのは入社前には想像もしていなかった反応だった。

メンバーから、
「スクラムマスターって必要ないよね？」 と聞かれているような質問だったり、
「スクラムマスターがいない現場になんて行きたくない！って言う人なんているの？どうなればそう思えるようになるの？」
といった、スクラムマスターの存在意義を問う、気軽で率直な疑問がほどんどだった。

本当に困った。私はこの環境で望まれていないかもしれない。
そう思って苦しみながら足掻いて足掻いていたら、天が強い仲間を送ってくれた。

それから毎日のように、一緒に泣いたり笑ったりしながら作り出した変化を発表してみようと思います。

この発表の目的や理由

実際にチームや組織を良くしたいと思って奮闘した時の、つらみや苦しみ
その中で気をつけたこと、上手く行った時の感動などを共有することで、
これからチャレンジしたり、今ちょうど同じようなチャレンジをする人の参考になったり、勇気が持てる様なことが伝えれたらいいな。
なんでもいいから、役に立てばいいなと思って発表しようと思いました。

また私たちのチームの活動を通して、他のチームの方から、より良い活動など教えて頂いたり議論出来るようになれたら嬉しいと思っています。

登壇者について

• 兼平裕美　しがないまよいぶた
• 笹尾納勇仁 : 本発表のサポート役

サポート役は本当にサポートのみとなる予定です。
視聴者からご要望があれば質問にはどちらの立場からでも回答可能となる予定です。

本セッションでは、プロダクトマネジメントのコーチをしているMoriyuyaがChatGPTを用いて、自然言語を加工する構造を構築し、人には認知負荷の点で困難な多方面の仮説立案と検証を素早く行い、プロダクトに関する幅広い領域を明らかにしてプロダクト開発を高速にする方法を紹介します。

また「話題になっているからChatGPTを使ってみたけど、うまく使えなくて、使わなくなってしまった」という状況の理解を通して、新しい道具との関わり方を示します。

----

下記は、任意のユーザーに起きる問題の構造を出力するプロンプトの1つ*です。GPT4で動作し、ChatGPT PlusやBing**で試してみることができます。

ある当事者にとって重要な変数1を達成するための行動は、別の重要な変数2を達成するための行動と同時には実行できないとき、葛藤が生じます。この葛藤をジレンマといいます。

下記は人がジレンマ状態に陥った状況を明らかにし、解決するためのフレームワークです。深刻な状況下にあるロールモデルとして質問に対して典型的な回答をひとつずつしてください。

ロールモデル=新人プロダクトマネージャー
ロールモデルが困っている問題状況=プロダクト開発のストレスやコミュニケーションの不和がチームの士気を低下させ、プロダクトの質と開発速度が停滞している

A.困っている状況でロールモデルが仕方がなくしている典型的な行動を3つ推測し、それらの行動が現実に発生している可能性を0-100で評価し、最も評価の高い結果を選択してください
B.上記の、仕方がなくしている行動によって、ロールモデルが満たそうとしている重要な要望を3つあげ、3つからロールモデルにとっての価値を0-100で評価し、最も高い結果を選択してください
C.仕方がなくしている行動の一方で、ロールモデルが本当に取るべきだと考えている行動を3つあげ、効果の観点で0-100で評価し、最も高い結果を選択してください
D.ロールモデルにとって取るべきだと考えている行動によって、どのような重要な要望を満たそうとしているかを3つあげ、3つからロールモデルにとっての価値を0-100で評価し、最も高い結果を選択してください
E.上記のBとDの要望が両立すると、ロールモデルにとってどのような理想の状態が得られると考えているかを3つ推測し、0-100で評価し、もっともロールモデルとして理想に近いものを選び、必要があれば理想の表現としてふさわしいものに修正してください
F.上記のAとCの行動を同時にできずにロールモデルはジレンマの状況に陥っています。仕方が無く取っている行動と、本当は取るべきだと考えている行動が同時に実行できない原因を3つ推測し、0-100で評価し、その中から最も長期にわたって頻繁に生じる原因を選択してください
G.上記のAの行動をとった結果に引き起こされる、Dの要望の実現を最も長期にわたって脅かすことになる結果を3つ推測し、0-100で評価し、最も評価の高い結果を選択してください
H.一方で、本当は取るべきだと考えているCの行動によって引き起こされる、Bの要望の実現を最も長期にわたって脅かすことになる結果を3つ推測し、0-100で評価し、最も評価の高い結果を選択してください

補足
要望とは「健康である」や「スキルが高い」といった人が欲している状態をあらわした表現である。
行動とは、要望を実現するために行われる「ランニングをする」「本を買う」といった人の動きが伴った表現である。

 

これは自然言語で構築されていますが、一つ一つが認知負荷の高い質問となっています。回答を別のプロンプトで成形させると、次の文章になります。

これは「新人プロダクトマネージャー」にとって、「プロダクト開発のストレスやコミュニケーションの問題がチームの士気を低下させ、プロダクトの質と開発速度が停滞している」という問題を表現したものです。

私たちのゴールである「チームが高い士気と連携でプロジェクトを円滑に進める」の実現のためには、「プロジェクトの完了を確実にする」必要があります。そのためには「チームメンバーにマイクロマネジメントを行う」必要があります。

もう一方で、ゴールの実現のためには「チームの士気を向上させる」も合わせて満たす必要があります。そのためには「効果的なコミュニケーションスキルを身につける」という行動をする必要があります。

「プロジェクトの完了を確実にする」と「チームの士気を向上させる」の2つのニーズを同時に満たすことによって「チームが高い士気と連携でプロジェクトを円滑に進める」を実現できますが、行動である「チームメンバーにマイクロマネジメントを行う」と「効果的なコミュニケーションスキルを身につける」は、「リーダーシップスキルの不足」のために同時には実行ができません。

そのため「新人プロダクトマネージャー」にとって困難な状況が引き起こされています。具体的には「新人プロダクトマネージャーがコントロールを失う感覚」や「チームメンバーのモチベーション低下」といった問題が引き起こされています。

さて、この回答自体はそれほど目を見張る内容ではありません。ここで重要なことは「ロールモデル」と「困った状況」という2つを入力するだけで、様々な情報が引き出され、加工され、そして疲れることなく生成できるということです。

プロンプトエンジニアリングという生成AIに入力する文字列を工夫するテクニックが脚光を浴びています。これには大きく分けて2種類あるでしょう。ひとつは「step by step」のような推論の精度を上げるものです。もう一つはほしい回答そのものをデザインすることです。

前者の「回答の精度向上」は時間が解決してくれるでしょう。しかし、後者の欲しい回答そのものをデザインすることは、価値のデザインです。使う人が的確に設計する必要があります。

冒頭のプロンプトは、元々はプロダクト開発をしていく上でユーザーを取りまく問題構造と因果関係を言語化するために私が人力で用いていた方法がベースです。効果的ではありますが、プロダクト開発のチームにとっては認知負荷が高く、実践できるものではありませんでした。学習負担の大きなツールを学ぶことが目的ではなく、よりよいアウトカムをユーザーに届けることが目的ですから実践できなくても当然です。それが、ChatGPTであれば文句も言わずに淡々とこなすのです。

さて、プロダクト開発の状況の話をしましょう。

新製品開発であっても、そのほとんどはよく知られた要素を追加したり、知られた要素の組み合わせで、本当に新しい要素は限られています。

また、私たちはそれまでに培った知識や経験を元にプロダクト開発を進めます。ところが、人類の知識は幅広く、既存の知識のうちごく一部分にしか利用していません。知識を学習しようにも、適切な学習対象を探したり、実際に学習するためには時間がかかるといったコストがかかります。そのため人類の知識全体に対して、仕事で用いる知識量は極めて限られた状態がつづきます。50年前に誰かが解決した問題を今日も私たちは知らずに解いているのです。

大規模言語モデルはGPT4になって精度が高まりました。もちろん、まだまだなところもあります。大阪駅の美味しい居酒屋だったり、人の名前を聞いても多くが見当外れな回答を返します。しかし、十分な量かつ安定した情報であり、回答が収束することにはある程度の正確性と精度の回答を返すようになりました。

これまでをまとめると次になります。
・効果があるが、人の認知負荷の観点から実行できない方法がある
・新製品開発では、すでに知られた要素が多くを占め、新しい要素は一部分である
・製品開発に利用できる人類の知識のうち、新製品開発の担当者が利用する知識はごく僅かであり、人が学習できる量は限られている
・十分な量かつ安定した情報に対してGPT4は高い精度で回答する

これらの性質を利用する方法が今回のセッションでお話しする内容です。その結果のひとつが冒頭のプロンプトになります。

本セッションでは、これまでよりも高速に仮説検証を行い、学習し、問題を特定し、現実からのフィードバックを得てサービスを展開するために、GPT4を自然言語ファクトリーとして活用する方法を紹介します。

* Bingではプロンプトが複雑になると回答が拒否されるため、ここではどなたでも試せるようにBingで動作するライト版を掲載しています。
** Bingでは何回か回答させると「複雑すぎるから答えられない」と回答を拒否されるようになります。その時は時間を空けてお使いください。

Bingでも動作した例

Bingで動作しなかった例