ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。

ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。

ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交えながらジェネラリストとしてソフトウェア開発に貢献する方法をお話します。

心理的安全性という言葉、皆様は聞いたことありますか？

心理的安全性が重要だ・心理的安全性がチームには必要だ・心理的安全性を実現しなければいけない、という意見は最近良く見聞きするようになりました。

あなたが所属するチームで、メンバーに「心理的安全性は重要だと思う？」と聞けば、恐らく殆どの場合「当然。心理的安全性は重要だし、私たちのチームでも心理的安全性を実現していく必要があるよ！」という声が帰ってくると思います。

しかし、そのように答えてくれる人の頭の中にある「心理的安全性」は、果たしてあなたの考える心理的安全性と同義でしょうか？心理的安全性という言葉がキャッチー（かつ、流行っている）こともあり、言葉が先行して肝心の目的を見失ってしまっているケースも散見します。

心理的安全性は、チームに属するすべての人にとって率直で安全だと思える心理状況を作り出せれば強力なツールとなり得ますが、いびつな形で運用されると逆効果にもなり得るのです。

このセッションでは心理的安全性の基礎についておさらいをし、その上で陥りやすい間違った心理的安全性の認識や運用についてご紹介します。

そして、そのような間違った心理的安全性に対してどのようなリカバリーの手を打つことができるかも一緒に考えてみましょう。

開催年月 開催地 チャンピオン
2022年6月 大阪 yattom
2022年5月 新潟 yattom
2022年1月 お茶の水 yattom

F1のFはFeedbackのFです。
アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
ポイントの投票は回答者自身と、聴講者によっておこなわれます。
高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
最多ポイントを獲得した人はF1仙台グランプリの勝者となり、1年間、その栄誉が讃えられます。

お題と回答の例その1
お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか？」
回答1「上司にベロシティについての理解を問うてみてはどうでしょうか？」
回答2「ベロシティは顧客価値につながる指標なんでしょうか？」
回答3「デプロイメント頻度は計測できていますか？」

お題と回答の例その2
お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
回答1「テストをサボるとその足枷がどんどん重くなるのでは？」
回答2「一度テストをまったくしないで進めてみてはどうでしょうか？」
回答3「プロダクトオーナーを説得する役割の人はいないのですか？」

出演者の情報です。
実況：ながせ（miholovesq）
解説：もりや（yudmo）
ドライバー（回答者）：よた（yota）、てやまぐ（teyamagu）、やっとむ（yattom）、かっちゃん（katzchang）
その他のドライバーにはこれから声をかけます。
出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します！

今回ついにローカルドライバーとして半谷さん(bangucs)がひとっ走りしてくれることになりました！！！

お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
https://forms.gle/oFih3o1mk6P8gTGK8

エンジニアとしてアジャイルなものづくりをし続けるためには、それを実現するだけのスキルが必要です。

そのスキルのひとつは"技術スキル"であり、私自身の弱さとなっている部分であり、向き合わなければいけないものでした。

あなたはどんな理由で、アジャイルを探求したり、スクラムを実践したり、コミュニティで学びを深めたりしていますか？

アジャイルの考え方が好きだったり、自分たちの開発に悩みを抱えていたり、より良い価値をユーザに届けたかったり、その理由は人それぞれだと思います。

私がアジャイルに興味を持ったのは、本質を突き詰めていくような考え方に深く共感し、自分たちもそんな風にものづくりをしたい、と思ったのがきっかけです。

思想を持ちながら、書籍、コミュニティ、カンファレンスでその理解を深めていくことで、本質的に価値を届けていくことはできる、と思いながら新天地へ足を踏み入れた私は、しかし思うように動けませんでした。

一方そこには、アジャイルのことはよく知らない、と言いながら自分なんかよりもよっぽどアジャイルな人たちがいました。

実践する前にアジャイルの思想を知り、頭の中で理想の世界が膨らみ続けていた私が、いざ実践となった時に突きつけられた「自分の弱み」の話をします。

いろんな痛みを伴ったので正直言語化するのもちょっと辛いですが、アジャイルであり続けるために頑張ります！！

「アジャイルチームで品質を作りこむ」
色々やり方があると思いますが、今回は私たちのチームで実施している方法を紹介します。

ポイントはソフトウェアを"作る前”と”作った後”にあります。私たちのチームでは作る前に「リファインメント」、作った後に「受け入れ」（独自イベント）を実施し、認識を合わせることで、1つひとつのPBIの抜け漏れを少なくしています。

### リファインメント

言わずとしれたリファインメント。このイベントにはDEV、PO、QAが参加し、以下のような項目についてスプリント開始前に話します。

• PBIのゴール
• 設計方針
• テストの方針＋影響範囲

POはPBIの意義、開発からは設計方針、QAは必要最小限なテスト、ソフトウェアアーキテクチャー上の影響範囲などについて話しながらPBIの輪郭をハッキリさせていきます。

### 受け入れ

私たちのチームでは独自のイベントとして開発のテスト終了後、受け入れというイベントを実施しています。こちらもリファインメントと同様にDEV、PO、QAが参加しています。
POは出来上がったものに関して問題ないか、開発は実装時に変更したところ、困ったところ、テスト結果について、QAは実装時の変更による影響、追加で必要なテストはないか、を認識合わせしていきます。

お気づきでしょうか？
DEV、PO、QAはアジャイルテスティングの文脈ではスリーアミーゴスと呼ばれています。
良く見ると「実装」がスリーアミーゴスでサンドされています。
自分は心の中でスリーアミーゴスサンドと呼んでいますが、今までチームメンバーに話したことはありません。墓場まで持っていくつもりでしたが、第2の故郷の仙台でお話したいと思います。

• スリーアミーゴス
• 実装
• スリーアミーゴス

このスリーアミーゴスサンドにより、以下のことを防ぐことができます。

• 作ってみたら変なモノができていた（修正）
• テストが足りていない（追加）
• お互いに期待値に達していなくてイライラする

スリーアミーゴスサンドぜひお試しを！

東京理科大発(理科大VC出資)ベンチャーShinonome(https://shinonome.io/)を学生創業してから、はや６年。

現在では、全国の大学と提携をして大学生にIT実践教育の仕組みを提供できるようになり、500名以上のエンジニア・デザイナーを教育・輩出しています。

しかし、創業期は...

「金がないので、寸胴で炊き出し？！」「20時間/312日、開発体制！？」

ソフトウェアとの出会いから、学生起業、今に至るまで赤裸々なストーリーをお話しします。 

• 今日は本を読むぞと決めたけど、結局ゲームをやってしまった

• 体重を減らさないといけないのだが、ついつい夜中にカップ焼きそばを食べてしまった

• 貯金をしたいのに、欲しいものがあると思わず買ってしまう

このような冷静に考えるとやらないほうが良いことを、思わずやってしまった経験はないでしょうか？私はあります。こうした経験をすると、自分の意志の弱さを感じて、嫌になったりもします。

行動経済学などの文脈で、「意思決定理論」という考えがあります。私が知っている範囲では、「意思決定理論」において重要なのは、いかに目的に対して合理的な決定ができるか、であって、たとえば、確率的により高いものを選んだり、認知バイアスの影響を減らした決定をできるか、といったことかなと思っています。

例として、サイコロで1の目が連続で出続けた後に再び1が出る可能性を低く見積もる「ギャンブラーの誤謬」であったり、得することよりも損をすることを回避した意思決定をしてしまう「プロスペクト理論」などが挙げられます。こうしたバイアスの影響を認識した上で、何回1が出た後でもサイコロの1は次も1/6の確率で出るのだと捉えて合理的な選択が出来ることが重要なわけです。

このような合理性を求める意思決定理論から考えれば、冒頭に挙げたような非合理的な行動は愚の骨頂とも言えるような振る舞いだと感じてしまうのですが、一方で、「なぜ人間はそんな行動をやりたくなってしまうのだろうか」という疑問も湧くのです。本当に必要がないのなら、進化の過程でそういう感情が滅びても良いのではないでしょうか。

こうした非合理的な行動を説明する理論として「双曲割引」という考えがあります。

私は、この考えを学んで、非合理的な行動にも実は意味があるのだなと感じました。もちろん非合理的な行動を合理的な行動に変えていくことも必要ではありますが、ある程度非合理的な行動をすることも必要なのだと分かりました。にんげんだもの、です。

このセッションでは、前半でこのような意思決定理論を学んで私が考えたことをお話させてもらった後に、後半では私の話を聞いてどう感じたかを参加者の方同士で話し合ってもらうことを考えています。

私が何か正解や答えのようなものをお伝えできるわけではないので、あなたの普段の意思決定をふりかえってみたり、参加者同士で非合理な意思決定の必要性について話合ってみたりすることで、何かの気付きや学びに繋がっていくことを期待しています。

私は筑波大学の情報系の学生です。３年生の春から、enPiTを通してアジャイル、スクラムを学んでいます。

３年生の秋に、新しくチームを組み開発を始めることになりました。ここで珍しかったのが、そのチームのチームメイトは全員スクラムを知らなかったということです。

そんなチームで、私がスクラムマスターとなり、スクラムをはじめました。その過程から「スクラムのはじめかた」を紐解いていきたいと思います。

当初講演予定のRyuzee不在につきプレゼンター変更でお届けします

講演者の代打として、miholovesqによるryuzeeのモノマネパワポカラオケ（コーラス：haradakiro）でお送りします。
いつの日か本物の「スプリントプランニング Deep Dive」が聴けることを期待しつつ……、それでは聴いてください。
Attractor Inc.で、新曲「スプリントプランニング Deep Dive」

★★★Deep Diveシリーズ第2弾!!★★★ (シリーズなのか)

前回のプロダクトバックログ（https://slide.meguro.ryuzee.com/slides/107）に引き続き、今回はスプリントプランニングのすべてを完全解説!!

スクラムにおいて、スプリントの開始時にまず行うのがスプリントプランニングです。従来型のプロジェクトにおける失敗理由の多くが出だしで躓いたせいだと考えると、スプリントの最初のイベントであるスプリントプランニングも重要であることがわかります。

ここで計画づくりに失敗してしまうと、インクリメントを届けられず、スプリントレビューは針の上のむしろになり、スプリントゴールも達成できなくなってしまいます。

一方でスクラムガイドを見ると、扱うべき3つのトピックは明記されているものの、具体的なやり方や手順は書かれていません。結果的にスクラムの価値基準や原則にそぐわないことをしてしまっている例も散見します。

以下の項目のいくつかは、一般的に望ましくないとされています。どれが望ましくないものか考えてみてください。

• (a) 選択したプロダクトバックログアイテムのうち、必達のものを完成させることをスプリントゴールにする
• (b) 選択したプロダクトバックログアイテムの担当者を決めて、その人がそのアイテムの作業計画をたてる
• (c) できるかぎりReadyなプロダクトバックログを用意するのが望ましいが、必要ならスプリントプランニングで、選択予定のプロダクトバックログアイテムの中身を見直したり再見積もりする
• (d) ステークホルダーと約束した期日があるので、完成できる気がしないプロダクトバックログアイテムもとりあえずスプリントに入れる
• (e) スプリントプランニングの前に、先にタスクに分解しておく

もちろんスクラムガイドを解釈して、どのように進めるかは、スクラムチームごとに試行錯誤していけばよいのですが、とはいえ体系的に知識を押さえておけば（SCRUM BOOT CAMP THE BOOKも是非読んでみてください）、陥りがちな罠は避けられます。

本セッションでは、スプリントプランニングをうまく行うための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

なお、望ましくないものは、(c)以外のすべてです。

スクラムガイド2020年版において「完成の定義」のアイデンティティが明確になりましたが、活用イメージがついていない方もいらっしゃるのではないでしょうか。

そういった方々に向けて、誰しも親しみのある「料理」を題材に、完成の定義（Definition of Done）の理解を助けるワークショップを作りました。

スクラムチームにおける役割や職種、スクラムの経験年数に関係なく、どんな方でも参加いただけると思います。みんなでワイワイ楽しみましょう！

※基本的にオンラインで進行しますが、希望が多ければ、オンサイトでの同時進行も行うかもしれません。→ 直前のご案内で申し訳ありません。こちらのセッションは「オンサイト開催」となりました。

概要

私たちは、これまで外側の世界に対してなにか働きかけをしなければいけない、と考えて改善を行ってきました。

しかし、本当に私たちが向かうべきは外側ではなく内側だったのです！！

本講演は、NVC（非暴力コミュニケーション）、ザ・メンタルモデルの知見から、主にスクラムマスターの内側の世界（感情、ニーズ、痛み）に目を向けます。

生命的な進化を遂げる組織の人間関係において必要とされるのは、表面的なコミュニケーションテクニックではなく、他者に対する理解や共感です。そして、更に重要となるのが、コミュニケーションを行う自分自身に対する理解や共感、つまり自己理解 です。

これまでアジャイルに20年間向き合ってきて到達したいきいきとしたチームの結論が、自己理解に基づく個人の変容です。

チェンジ・エージェントたるスクラムマスター自身が、自分自身に対しての共感・理解をすることが、チームの生命構造を生み出す最短距離ではないかという仮説をご紹介した後、自己共感・自己理解についての概要、なぜチームの生命構造を生み出すのに自己理解が必要なのかの説明した後、実際に自己理解を体験するためのワークを行います。

本講演の最後に、引き続き自己理解・自己共感を行っていく上でのポイントをお伝えします。

自分が所属するUnipos株式会社では、「感情報酬を社会基盤に」というミッションを掲げてUniposというソフトウェアを開発しています。

1年半前、自分はみんながもっと楽しく開発できるように、従来型の開発プロセスを変えようとトップの人に直談判を試みます。

自分が変革をはじめる最初の一人でした。
初学者でしたが書籍から学び、知識は万全。きっとなんとかすると前のめりでした。

ところが、憧れた会社や書籍のようにうまくいきませんでした。
そこにはシンデレラストーリーがあるのではなく、ただただ現実的な問題ばかりがありました。
その問題の乗り越え方は書籍には載っていません。
自分で悩み考え、取り組んでみて学習する必要があります。
形式知ばかりを学び、「最初の一歩」を実践したことのなかった自分は見事に頭でっかちになっていました。
頭ごなしに知識を押し付けたところで、とうとう組織の支援を受けることはできませんでした。

初学者が組織の変革をはじめる最初の一人になる場合、経験したことがないため乗り越えられないような問題が出てくることがあります。
そう考えると、むしろ最初は組織から協力を引き出せないほうが、自然なのではないでしょうか。
では、初学者が組織の変革をはじめるべきではないのでしょうか？自分はそんなことはないと思います。

最初の一人が躓いたとき、その後の歩みを止めないためにできることは何でしょうか。

このセッションでは、組織を変革する最初の一歩の道のりをふりかえり、自分が学んできたことをご紹介します。
なにぶん昔のことなので、思い出せないところもありますが、書籍には載っていないような自分の実践から学んだお話をご提供できれば幸いです。

すべてがフィードバック、なんでもフィードバック - Feedback is Life

フィードバックは、会社の中のコミュニケーションだけでなく、家族間、学校内、などなど、コミュニケーションがあるところには、かならずあることです。リーダーからメンバーへフィードバックする機会もあります。トレーナーとして、受講者にアドバイスするのもフィードバックなら、受講者からトレーナーが学ぶのもフィードバックです。立場と関係なく、自分が感じたり考えたりしたことを共有し、相手からも教えてほしいというのも、またフィードバックの話です。

しかしいざ学ぼうと思って探してみても「上司が部下に言うことを聞かせるため」系の本しかありませんでした。そのときに、ワインバーグ先生の『What Did You Say? The Art of Giving and Receiving Feedback』に出会いました。ワインバーグ先生ならきっといいことが書いてあるに違いない！と考えて、英語の本に取り組むため仲間を集め、定期的な読書会形式で進めることにしました。

そして1年4ヶ月の読書会を経て、私たちはこんなふうに理解できました。

• すべてがフィードバック、なんでもフィードバック。
• テクニックとしてではなく、人の心の働きに立ち戻り何が起きているのか分析する話です。
• フィードバックとは、しようと思ってするわけではなく、すべてがフィードバックです。またフィードバックは受け手の話ではなく、与え手を表現することです。そしてフィードバックは一方通行のコミュニケーションではなく、複雑な相互の継続的プロセスです。
• フィードバックでは自分自身を大事にすることが大切です。
• フィードバックは適切に、客観的に、わかりやすくすれば伝わると思ったら、大間違いです。
• 「フィードバックください！」とよく言ったり言われたりしますが、実は……

みんなでこうした理解に到達できたのは、単に英文を読み解いてというだけではなく、文意について意見交換をしたり、自分の体験にもとづいた捉え方を話し合ったり、ふりかえりをしたりしたおかげです。そこでこの読書会の体験と書籍の内容をセッションで共有したいと思います。

本の内容と読書会の体験について、読書会メンバーが対談・パネルセッションでわいわいします。実際の読書会の場面を切り取るような内容も、話せるかもしれません。

ぜひ、楽しい時間を皆さんと分かち合いましょう！

Metrics on employee happiness, theoretical value, and work not done are just plain dumb. I will reveal the metrics that you need. That mean something. And that get results. Join us as we discover THE BEST AGILE METRICS!

私は、悩んでいました。

アジャイルコーチを名乗っているのですが、コーチングができているかわからないんです。
もちろん学んでいますし、超優秀なコーチから継続的にコーチングも受けています。
でも、現場で行っているコーチングが、コーチングになっているかどうかの判断がつかないのです。

まわりを見ると、第一線でキラキラと輝くアジャイルコーチたちが活躍をしています。
そして、自分はいつも、悩んでいました。

そんなある日、コーチングセッションでコーチから提案を受けました。
「小さなことでもいいので、現場で日々やっていることを書いて共有して！！」

当初は、1ヶ月で20個、現場でやってみたことを書いてみる予定でした。
やってみると、1週間で50個を超えました。
今は、3週間で100個を超えました。

「デイリーミーティングでは大きな声で挨拶する」のような、簡単なものもあります
気づかず繰り返しでやっているものもあります。
中には、やってみて、傷つくような失敗になったものもあります。
思いがけずに、素敵な結果に結びついたものもあります。

もしかすると、僕がやりたいことは
こういったことが積み重なった先にある、小さく始めるアジャイルコーチの提案なのではないか、と思い始めています。

発表では、私が日々現場でやってきたことを抜粋して紹介します。
また、繰り返し現れたものや関係性があるものなど、パターンの抽出にも手をつけてみようと思います。

それら、発表の中で紹介した中から、気に入ったものや使えそうなものを持ち帰っていただいて、
明日から、皆さんの現場で、小さくな所からでもアジャイルコーチを始めてもらえれば嬉しいです！！
そして、また、コミュニティの中で結果を共有できる日を楽しみにしています！！

あなたのチームのインセプションデッキは役に立ってますか？

インセプションデッキは、書籍「アジャイルサムライ」の中で紹介されたツールです。

"プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキ"

インセプションデッキは10個の質問で構成されていて、質問に答えていくことでプロジェクト開始前に確認しておくべきことが明らかになるツールです。これだけ聞くと簡単そうに聞こえますが、実際に現場でインセプションデッキを作成して活用するまでにはさまざまなお悩みポイントにぶつかります。

「デッキ作成にどれくらい時間を確保すればよいの？」  
「デッキ作成するときは具体的にどう進めたらよいの？」  
「デッキを作ったのはいいけれどそのあとどうしたらいいの？」

本セッションでは、インセプションデッキの紹介からこれらの現場で実践する際のお悩みポイントを解決する方法までお話します。

また、インセプションデッキは作成したデッキ以上にチームの関係性をつくることに価値があります。ただデッキを作成するだけでなく、チームの関係性をつくるためのインセプションデッキについてお話してみます。

"You better bring it!

Oh, it's already been broughten!"

The purpose of cheerleading is to support and encourage their team to achieve peak performance - they give the team the extra oomph to carry them over the goal line! The cheerleaders not only support and celebrate the wins, they also encourage the team when they need to push through their trials and tribulations. Cheerleaders build the hype of the team fans by creating infectious energy, just imagine your stakeholders hyped up because of your awesome team!

In this session we will take lessons from professional cheerleading and apply them in an agile team context.

We will cover the 3 pillars of agile cheerleading - chants, dances, and symbols and explore the fundamentals and benefits of an agile cheer so that you can super-charge your teams.

BE! AGILE! BE! BE AGILE!

振り返りはどんな頻度で、どのように実施されていますか？

私のチーム（複数プロダクトを持つ部署内のQAチーム）では、以下の課題がありました。

• チームメイトはそれぞれの担当領域があり、業務上関わりが少ない。
• さらにフルリモート化ということで、そもそも話す機会も少ない。

そんな時、チームメイトが「月次で振り返り会をやりませんか？」と提案してくれました。

この会がとっても楽しいので、他の方にもぜひ知っていただきたいと思い、体験コーナーをご用意します。

「初対面の人たちが集まってうまくいくのか？」ですって？ご心配なく！

• 業務上関わりが少ない
• 話す機会も少ない

という中で運用を開始しています。まさに、セッションに参加する私たちと似た状況ですね。

ワークショップを通して、スクラムイベント外での振り返りのメリットを実感していただくことを目指します。

そのまま自チームで実施してみるのもよし、カスタマイズして行うのもよし。チーム内外との相互理解、コミュニケーション強化のためのアクションのきっかけになる、チャッカマンのようなセッションを目指します！

This session is a twinkle in my eye! I have drafted an outline but haven't completed it yet, so it is very much a work in process. I usually write the abstract last, so this is a change for me. Essentially it's about how an agile coach needs to practice the fine art of ZFG. This session is mostly about the "why". For example, I review how fear is the "mind killer" and how fear prevents many coaches from speaking truth to power. As another example, I review "clean bias" and how a coach should not only be explicit about bias, but also also understand what their biases are so that they can provide objective feedback. In contrast, I also cover how ZFG does not mean "I don't care" and I distinguish between the two. My goal in this session is to help coaches understand the philosophy of ZFG and how it is a critical skill to embrace in order to be a truly effective agile coach.

スウォーミングとは、ソフトウェア開発の文脈では 1 つの問題やタスクを皆で群がって解決するという意味合いになります。私が所属しているスクラムチームでは、最も優先順位が高いタスクを最速で完了させることを目的にスウォーミングを実施しています。

スウォーミングの手段の1つにモブプログラミングがあります。私たちのチームも結成当初は、フロー効率最大化のためモブプログラミングで1つのタスクに群がっていました。しかし、開発が進みタスクの不確実性が下がってくると、開発メンバーは「フロー効率重視の開発スタイルを維持したままリソース効率を高めていきたい」と考えるようになりました。

そこで、Swarming: One-Piece Continuous Flow** のキャプテンの仕組みを参考に、ソロプログラミングを主とした開発でもフロー効率が下がらない方法を編み出し、チームに適用しました。私たちはこの仕組みをキャプテン制度と名付けて運用しています。

本セッションでは、スクラムチームで実践しているスウォーミングの紹介、キャプテン制度の策定の背景、得られた効果についてお話ししたいと思います。また、私自身スクラムマスターとエンジニアを兼務している立場であるため、スクラムマスター、エンジニアそれぞれの立場で、キャプテン制度を運用してみた所感についても共有させていただきたいと思います。