17年間動かざること山の如しのちんも氏と、止まれないことまぐろの如し、転職を繰り返してきた藤村新氏、真逆の生き方をしながらも、それぞれがアジャイルを追い求めてきました。

「17年と13社、それぞれのアジャイル」

俺たちはどう生きたらいいの？感を若干交えつつ、

もがき挑み足掻く者二人の生き方・価値観の核心に迫ります。

モデレーターかいはらがライトな感じでお届けします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それぞれスクラムを知ってもらうワークを実施予定です（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. 

スクラムフレームワークに沿ってイベントをこなしながらプロダクトを作る。

一般的なスクラム開発を進める中で、ふと違和感を持ったことありませんか？

「ウォーターフォール開発を短期間で分割して開発してるだけでは・・」

「ラグビーチームのような一体感を持ったイメージと何か違う・・」

私がスクラムマスターを担当した ”とあるチーム”も、上記のようにスクラムを淡々とこなしているチームでした。

プロダクトの価値やチームの成長について熱く語るようなチームになって欲しいと願い、スクラムマスターの立場から色々とチームに働きかけても変化を起こせずにいました。

そんなある日、ちょっとしたことがきっかけでチームが生まれ変わりました。

それはチーム内から起きた内発的動機付けによるものでした。

生まれ変わったチームは、優れたプロダクト体験・機能を素早く届けることにこだわり、メンバー間が相互のタスクに興味を持って助けあい、スプリントゴールを懸命に追いかけるようになりました。

振り返ると劇的な変化が起きたので、他チームでも活用できるようにいつか情報を整理したいと思っていました。

今回の発表はちょうど良い機会なので、チームを変えた内発的動機付けについて考察のうえ言語化したいと思います。

達人たちの見ている世界を覗いてみませんか

「あの人はこの問題に対してなんて答えるんだろう？」
「あの人はもしかして、あの偉人？あの概念？からこの答えに辿り着いたのだろうか？」
「あの人の頭の中身が見てみたい！！」
と思ったことはありませんか？

同じようなプラクティスや手法を用いていても、人／チームによってまったく違う結果になります。
つまり現場での成功には、形式的な方法だけでなく、それを扱う人の呼吸、思考、メンタルモデルが大きく影響しているということに他なりません。

このセッションでは達人たちが見ている世界を覗いてみる実験をします。
ある分野で研鑽を重ねる達人同士が、お互いにインタビューをすることでお互いの思考を探ります。
ただのインタビューでは見ることができないDeepな世界にDiveしてみましょう。

今回は「プロダクトマネジメントの光と闇」をテーマにDeep Diveします。

過去のDeep Dive Expertsとトークテーマ

• Deep Dive Experts - 達人が見ている世界を覗いてみよう - @Scrum Fest Osaka 2021
  • スクラムとヨリを戻した時ってどんな時でしたか？
  • 過去や未来問わず。これは一番タフクエスチョンだな... と思った問いはなんですか？
  • スクラムに合ってる人、合ってない人、がいると思っております。スクラムに合っていない人がメンバーにいると思った時、どのような対応をしておりますか？
  • 皆さん様々な発明やアイデア出しをされ、同時に様々な勉強を日々されていると思いますが、日々の勉強をアイデアに繋げるまでの過程を知りたいです
  • いつから○○を拗らせましたか？
  • 当日のMURALはこちら
• Deep Dive Experts - 達人が見ている推しの世界を覗いてみよう - @Scrum Fest Osaka 2022
  • 心の底から本当にアジャイル推してるの？
  • みなさんのオシは何ですか？
  • お互いの推しポイントをDeep Dive目に推し合って欲しい！
  • 当日のMURALはこちら

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

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

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

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

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

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

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

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

転職前まではウォーターフォール開発しかやったことが無く、「アジャイル開発ってこんな感じなのかなー」と妄想していた妄想癖な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で動作しなかった例

皆さん日々どんなメトリクスとってますか？メトリクスをとった後何してますか？

メトリクスを使ってチームや自分の行動を変える時、とりあえず計測するだけして、放置されていることってありませんか？
なんならメトリクスを取ること自体が目的化しちゃって本来の目的が横に置かれていることありませんか？
私はあります！

コーチングなんていう、人にあれやこれや気づいてもらう事をしていても、油断をすると手段が目的化してしまうことがあります。
今回はそんな経験から、どうやってそこに気づいていくか？そしてどうやってメトリクスと付き合っていけばいいかについてお話しようと思います。

ウォーターフォールモデルでの約7年間の開発プロジェクト経験を持ち、今は新潟でセールスやビジネスデザインの仕事をしており開発から遠ざかってしまった私ですがスクラムフェス新潟で皆さんのセッションや、会話を通じて刺さりに刺さる刺激をいただきました。
それは開発を行っていた当時や、開発を離れた今も共通的に大切だと感じて心がけていることであったり、うまく実践できていないこと、そんな様々な刺激を。
本セッションではその刺激を整理し、感じたことの一部をお伝えしていきたいと思います。

• 改めて感じた、「発信がコミュニケーションの起点であり、発信が変化を生み出す」

プロジェクトを進めるうえで共通的に大切だと再認識したのは「自分の考えたことや、感じたことを伝える、発信をする」ということ。自分の考えを伝えていけば、相手の考えや感情を引き出し知ることができる。私が体験した成功プロジェクトでは、プロジェクトにかかわるメンバ間でしっかり発信を行い意見を出し合っていたと思います。
それは、あるべき姿に関する意見だったり、現状に対する課題だったり、解決策だったり、感想だったり、いろいろな意見があると思いますが、すべて変化を生み出すきっかけになるものだったと思います。

• 発信が与える変化はよいものだけではない「想像力の大切さ」

与える変化もポジティブなものもあればネガティブなものもあります。
そのため、「何のために？」という意見を提示したいと感じた理由・目的、「誰のために？」という伝えたい相手や範囲を意識することが大切になります。受け手への配慮や、尊敬が必要で、自分が見えている範囲・自身の常識の範囲を超えて想像力を働かせ考えを伝えていくことが大切なのだと思います。
成功するプロジェクトではそれぞれの役割は当然大切なのですがメンバの皆さんが相手への思いやりや、役割を超えた目線をもって取り組んでいると思います。

• 発信の大切さを開発プロジェクトに活かす

上述したことを感じ、自身が改めて開発プロジェクトにかかわるようになったら大切にしたいと感じたことをお伝えします。
アジャイル、ウォーターフォールいずれのモデルで開発を行う場合においても、それぞれの良さを取り込むことでより良いプロジェクトになるのではないかといいうことです。
アジャイルは短期のスパンで実現したい要望、目的を最小限必要な単位から実装していくため、目的を実現していくためスピード感を持ちつつ、うまく要望を拾いながら進められる仕組みだと思います。
ウォーターフォールは柔軟性はないものの、一度決めた道筋を丁寧に進めていくということでは、堅実にプロジェクトを進めていくことができます。ヒントがそこにはあると思います。
例えばウォーターフォールモデルではドキュメントをたくさん作成します。これは工程ごとに担当者が変わるため後工程にその情報をしっかり伝えていくためのものです。要はコミュニケーションの手段としてドキュメントを作っていく必要があるのです。
アジャイルではコミュニケーションの手段を実際に動くプログラムやツールで代用して効率化を図りますが、特に重要な事項は今後も情報を風化させないためにもドキュメントを作る大切さを知り、作るべきドキュメントの取捨選択を行っていくとよいのではないでしょうか。このようにウォーターフォールモデルの場合によってはデメリットともとれる特徴を、捉え方を変えることでプロジェクトを安定させるための要素にしてはどうかと思います。

当日はこういった刺激を整理してその一部をプロジェクトマネジメントに大切なこととしてお伝えしていきたいと思います。