私達について

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これからの私達

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

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

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

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

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

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

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

スクラム開発うまくいってますか？

うまくいってるチームの話を社内外で聞くと、スクラムガイドの基本的ご作法を大事にしているチームが多いという印象があります。基本を大事しつつ、スプリントを通じて得た学びから少しずつチームのオリジナルを加えている。

つまり守破離って大事ですよねと。

”スクラム　アンチパターン”で検索して出てくる記事でも、「スクラムガイドに背くと痛い目を見るぞ！」と散々警鐘が鳴らされています。

そんななか、様々な事情が重なって私が担当するチームではスクラムアンチパータンを踏みまくる状況に陥りました。

例えば・・・

• エンジニアが3人未満のチーム構成
• 全員が他の開発業務を掛け持ち
• スプリントバックログが常に終わらない
• 不完全なインクリメントでスプリントレビュー
• デイリースクラムをやめる  ...etc

なぜ安直なアンチパターンを踏みまくったのか。

起きた事象に対して、スクラムマスターの私は何を考え、行動したのか。

アンチパターンを踏みまくった結果、このチームやプロダクトはどうなってしまったのか。

スクラムアンチパターンを踏みまくったときの話をしようか。

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

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

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

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

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

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

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

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.のテストをしていますか？それともただのテストですか？

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

アジャイルやScrumでチームを回していると本当にうまく回っているのか不安になるものです。

私どものチームも同様で、チームの状況を可視化するため色々検討してみましたがうまくいきませんでした。

FourKeysも計測していますが、どうすれば数値が上がっていくのかわからないまま。

最近知ったSPACE（達成感(satisfaction)、パフォーマンス(performance)、活動(activity)、コミュニケーション(communication)、効率性(efficiency)）という考え方を導入し、私達のチームでは多面的にチームの状況を可視化しようと試みているところです。

その意義と成果をほぼリアルタイムでご紹介できればと思います。

また、SPACE自体は具体的にどの指標を計測するかまでは指示していないため私達がどの項目を選択したのかもお伝えします。

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

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

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

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

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

前職で15年程働き、その間プロジェクトマネージャーやスクラムマスターとして多くのプロジェクトに従事してきた。

その中で、アジャイルやスクラムについて新人研修をはじめ色々な所で説明するような機会もあたえてもらえました。

その経験を生かしSIerから自分たちのプロダクトを作ることに携わってみたいと今までの製造業から金融業へ転職。

しかし、転職した先では内製化も進めたいとのことだったが開発の主導権をベンダーが担当しており自部署のメンバーは開発経験ほぼなし。

また、部署内ではほかの仕事としてイントラ業務/保守・運用業務も担っており開発に十分に集中できるような状況ではなかった。

もちろんアジャイル開発の経験なんてほとんどない状態。

さらに、コロナ真っ只中に転職したことでコミュニケーションも取りにくい。

そんな中、3年経ち少しずつ内製化もできるようになりプロジェクトマネージャーとしてもサービスをいくつかリリースしてある程度価値がだせるようになってきた今、いままでアジャイルを通じて学び・実践してきたエッセンスをどのように新しい環境に適用してきたのかをお伝えします。

いままではうまくいっていたはずなのに、新しい環境やプロジェクトでうまくいっていない人に少しでも良いきっかけになるような何かを伝えられればと思います。

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

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

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

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

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

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

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

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

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

だが、情熱はある。

本セッションでは、プロダクトマネジメントのコーチをしている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で動作しなかった例

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

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

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

このセッションでは、従来のウォーターフォールを中心とした計画駆動型の考えをそのままスクラムに当てはめてしまうという私も何度か経験のある状況について、どうすれば本来のアジャイルな開発(価値駆動型)へ変えられたのか、私自身がこれまで学んできたことや今時点の考え・実践してることをお話しします。

『アジャイルな見積りと計画づくり』という書籍は、「見積りと計画づくりがアジャイルでないのに、プロジェクトがアジャイルであるということはありえない」というイントロダクションから始まりますが、要するにそんなことをお伝えしたいです。

• 何を作るかではなく、どんな価値を顧客に届けるのかから始める
• 期待値を合わせる
  • スクラムは単にアウトプットを求める上では効率が悪く、効果を高める手法であること
  • 意思決定とリスク評価
  • プロダクトビジョン、ロードマップとプロダクトゴール
• アジャイルな計画の立て方

同じように「どうする」と悩まれている方の少しでも参考になれば幸いです。

私が所属しているSIerでのシステム開発は、ウォーターフォールを中心とする従来の計画駆動型の開発がまだまだ多い状況です。ただ近年はアジャイル型の手法（主にスクラム）で開発しているプロジェクトも徐々に多くなってきています。

一方、「スクラムで開発します。」と言われてプロジェクトが開始したものの、その時にはすでにステークホルダーとアウトプットが詳細まで合意されている（例えば、機能一覧や画面一覧といったドキュメントが存在し、それらを全て作り切ることを約束している）上に、リリース日も決まっていることも少なくありません。

計画駆動型開発とは、事前の計画に重点を置き、後のフェーズではその計画に従ってプロジェクトを実行し、進捗を管理していくウォーターフォールを含む開発方法論（PMBOKでは「予測型」と記載されていますが、計画駆動型と同義とされている）のことです。

もちろんアジャイルでは計画を立てないわけではなく、ケント・ベックはXPのことを「計画立案駆動」と言ったらしいですが、スクラムもXPと同様に計画を状況に合わせて見直し続けていく計画立案駆動型の開発だと考えます。

リリース日とそのスコープが決められているため、様々な問題/歪みがチームに起こります

例）

• プロダクトのアウトカムよりも効率的にアウトプットすることが求められる
• チームとしての成長は後ろ回しにされてしまう（そしてその時は中々こない）
• 厳しく進捗管理されているので、スプリントの中で当初想定した量のアウトプットが出せなければ稼働を上げての対応や要員の追加で疲弊していくチーム
• スプリントレビューにステークホルダーを呼んでも、興味の大半はリリース日が守れるかどうかで、よりよいプロダクトにするためのフィードバックはほとんど得られない

計画駆動型の開発そのものや、計画駆動型の開発にアジャイルで一般的に使われるプラクティスを取り入れること、段階的に機能を開発するイテレーション開発を否定するつもりはありません。

ただし、スクラムを計画駆動型で行われているソフトウェア開発にそのまま当てはめて、それをアジャイルやスクラムと言い切ってしまうことは問題だと感じています。

2001年スノーバードに軽量級プロセスの提唱者として集まった17名が、共通する信念として記したアジャイルマニフェストは、こんなに不自由で息苦しい開発のことを指していたのでしょうか。

是非当日は自分も同じように悩んでいるといった声や、私はこう取り組んでいるよという知恵や経験を教えてください。

皆さんと前向きにワイワイとお話し出来ればと思います。

スクラムの「開発者たち」のなかには、デザイナーも含まれていると理解しています。デザイナーがスクラムチームに入ることになぜ意義があると感じているか、そのうえでどんな悩みがあるか、これまでの数々の悩みと実験の変遷をお話したいと思います。

わたしは技術職からキャリアをスタートし、フロントエンジニアからUIデザイナー、新規事業開発チーム、当時所属していた会社内のアジャイル推進者を経て、現在はプロダクトデザイナーという職能でスクラムチームの一員として働いています。

職能は違えど「デザイン」という活動をしてきたと思っています。

アジャイルの世界を知り、RSGTやスクフェスでセッションをきくたび「これはプロダクトづくりの話をしている、デザイナーにも関係がある」という想いが強くなりました。

一方、スクラムとデザインの相性は悪いのではないかと耳にしたり「なんでスクラムチームにデザイナーが？」と言われることも。

チーム外からのアジャイル支援の経験を経て転職し、プロダクトデザイナーとして新しいチームに入ったことで、何故そういう意見がでるのか、新たな経験や考えが増え、悩みも変わり続けています。

スクラムチームの中の人として「デザイン」にこだわり続け、悩み続けるいちデザイナーの話が、デザインや職能理解のきっかけになると嬉しいです。

私はアジャイルには20年ほど前から取り組んでおり、アジャイルコーチとして10年ほど活動しています。
10年前から、自分が大切にしていることはそれほど大きく変わっていませんが、もたらすこと、考えていること、やっていることは変わってきています。

そんなアジャイルコーチについて最近特に「アジャイルコーチってどんなことをするの？」と聞かれることが何度かありました。

理由の1つにアジャイルコーチと名乗る人が10年前と比較して増えたこともあるでしょう。また必要に応じて、いろいろな組織が外部の力を適切に借りる選択をすることが増えたかもしれません。その一方、1つのチームや組織が複数のアジャイルコーチの振る舞いを見たり、比べたりする機会を持つことはそこまで多くないかと思います。

私は、アジャイルコーチとしての経験が長い人ほど、その経験に応じて引き出しがあり、それぞれのアジャイルコーチとしての考えや特徴が強く出てくるように思います。

アジャイルコーチの力を借りる時には、そのアジャイルコーチがどのような価値をもたらすのか、どんな考えをしているのか、なにを得意としているのかを知ることが、より良い結果を引き出すポイントの1つです。

このセッションでは、私がアジャイルコーチとしてもたらそうとしているのか？何を考えて、どんなことをしているのか？という"アジャイルコーチの1つの類型、中村洋の場合"をお話します。

自律的なチームになってほしい！という思いはマネージャーなら常に持っている共通の思いかと思います。が、難易度が高いとか納期が近いとかの仕事のプレッシャーからついつい自分がプレイングとして入ってみたり、過度にチームに指示をしたりで自律的なチームにならない原因を自分からつくっていることもあるのではないでしょうか。

unFIXとはそんな課題にフィットするかもしれない組織やチームのデザインのツールです。自律的な組織に見られるパタンをいくつか抽出したもので、「ベース」と呼ばれる母体に「クルー」と呼ばれる役割を持つチームが垂直水平（あるいはナナメ）に配置していくもので、なおかつ共通のテーブルでディスカッションできるくらいの分かりやすさやとっつきやすさも備えています。

今、私のチームではunFIXをつかって2チームいるセクションの体制を見直し、unFIXが定義するところの各クルーの役割に基づいて動いていく形で活動し始めています。

いわゆるマネージャーの役割は「ガバナンスクルー」であり、チームの役割は「バリューストリームクルー」と呼ばれています。このあたりは提唱者がヨーガン・アペロ氏ということもあり、少数のマネージャーがいわゆるガバナンス的なマネジメントを担い、他についてはチームがセルフマネジメントしていくという思想も入っているように感じられるところがあり、いい意味で「マネージャーとチームの間に線を引く」ことがしやすくなる性質があると感じています。

私のチームではこのあたりをどうやったか、私のチームがどうなったかをお話しできればと思います。

令和４年９月に発売された一冊の書籍「ゾンビスクラムサバイバルガイド〜健全なスクラムへの道〜」皆さんはもう読みましたか？

私はこの本を読んで多くのことに気付かされました。これは、今自分が置かれている環境じゃないか。気付かぬうちに、「ゾンビスクラム」になっていたとは。。。読み進めるにつれて、グサグサと突き刺さる内容。

• 縦割りのサイロ思考。ビジネスとITの分断。チーム内も役割で分断
  • ステークホルダーのニーズを知らない
• 「私たちにふりかえりなんていらないです」
  • 継続的に改善しない
• 与えられたタスクだけをこなす姿勢。当事者意識が欠如
  • 自己組織化をしない

読み終えた頃には、できていないことの後悔を通り越して、ガイドを参考に一刻でも早く何とかしたいと焦りました。もっと早くこの一冊に出会っていれば。

このセッションでは、私がスクラムマスターとして、開発メンバとして、経験/目の当たりにしてきた「ゾンビスクラム」に陥るパターンや予兆とそれらを生み出していた根本原因について、アンチパターンとともに紹介いたします。特に以下ポイントにフォーカスしていきます。

• 私たちが陥っていた症状と原因
• スクラムの本来の「目的」と私たちの誤解
• 私たちの「健全なスクラム」への道
• 銀の弾丸などない！？直ぐには治せないゾンビスクラムとの付き合い方

同じ悩みを抱える方々のご参考になれば幸いです。

ここ数年、開発者としてスクラムを実践しながら、いくつかのスタートアップの開発にPL、PMとして参画してきました。

走り出しのスタートアップでは体制が未成熟で、開発プロセスと呼べるような整備されたものは存在していない状態も多いです。なので「まずはスクラムを導入して土台を整えよう！」と考えます。

しかし、開発リソースをはじめとした特有の制約が多く、ガイド通りにスクラムを導入するのはなかなか難しい・・・。

そうであればと、

• 「開発を回していく上で今本当に必要なことは何か？」
• 「何が原因でトラブルが起きて、開発の弊害となっているのか？」

という軸で必要なプロセスを考えてみます。

すると、見えてきた課題の対策に、スクラムのあのイベントや定番のプラクティスがピタリとハマって、結果的に「部分的なスクラムの導入」みたいになってきたではありませんか・・・！

そんなことを繰り返していくうちに、

• 現状の開発プロセスに不足している「機能」は何か
• スクラムのイベントやプラクティスでそれを補う「機能」を持っているのは何か

と考える型のようなものができてきました。

「そんなのスクラムとは呼べない！」と言われるかもな〜と思いましたが、結局やりたいことは開発をうまく回して価値を届けられるプロダクトを作ること。

それを実現するためのヒントがたくさん詰まったスクラムから学び、実践したことを事例を含めながらご紹介します。

スタートアップの開発から得られた知見だけどこれって「スクラムやりたいけど制約があって難しい」という課題を抱える環境なら役に立つのでは・・・？と思ったので、いろんな開発現場の参考になれば嬉しいです！

みなさんは、ベンチャーキャピタル(VC)と聞いてどんなイメージを持ちますか？

おそらく、名前は聞いたことがあっても実態がピンとくる方は少ないのではないでしょうか。
そんなVCがスクラムを支援しているなんて、全く想像がつかないですよね。

私が働いているVCは、投資先の事業を現場レベルで支援する専門チームを持っています。
国内VC界隈ではそれだけでも珍しいのですが、弊社ではそのオプションの中にスクラム支援が入っています。

初期メンバーが単独で開発を行うようなシード期はわかりませんが、シリーズA前後で人数が増えチーム開発をするタイミングでスクラムがよく採用されます。

構造上、プログレッシブに変化する開発現場なので、以下のような事象が起こりやすくなっています。

• 自分がやった方が早い、名ばかりマネージャ問題
• 感じて動けない人は「向いていない」、言語化しない(ハイコンテキスト)文化
• チーム取りまとめを任されるが求められるのは実働のプレイングマネージャ
• 見積もりがコミットメントに、マイクロウォーターフォールで開発が疲弊
• 創業期の技術的負債解消のためのリプレイスをもう数年続けている、開発の内部が見えない
• 気がつけばビジネスと開発が分断……

スタートアップの立場からすると、T2D3の成長曲線を狙う中で常に事業や会社の環境は目まぐるしく変わります。

そんな時に有効なのはアジャイルコーチなどのサポーティブな役割ですが、スタートアップは一般に資金が限られているため、アジャイルコーチを雇えないことが多いです(もっとも、ニーズとして顕在化していないことも少なくないのですが)。

上記は開発の例ですが、スタートアップが成長する中で現場が直面する様々な事象に対して、カイゼンを外部から支援するために我々のチームは存在しているのです。

本セッションでは、そんなベンチャーキャピタルでのスクラム支援業務を紹介すると共に、複数スタートアップに携わって気づいたスクラムのDos and Don'tsをご紹介できればと思います。

※本プロポーザルはScrum Developers Night! in Tokyoの参加者の皆様によって壁打ちいただきました。ありがとうございました！

スクラムを始めてからずっとスプリントゴールを達成し続けている人はいないはず。
きっと一度はスプリントゴール達成できなかったことがあるのではないでしょうか？