他のイベントもかけてないのですが、取り急ぎ記憶が新しいうちに…
旅行の思い出は一番最後、追記的に書いておこうかと思います。 本ブログでは感想と事実があまり切り分けられてかけていない気がするので、資料公開されているものについては参照していただけると幸いです。
イベントページ
https://www.scrumfestmikawa.org/
1日目
Agile at Tesla and SpaceX.
まずハードウェアでのアジャイルを本当に実現している点が驚きでした。 ハードウェアの場合に障壁になることはいくつもあるのですが、それらをすべてクリアして何度も作れる状況にしていることにびっくりしました。
ハードウェアでアジャイルをするために必要なもので特に重要だと私が感じたのは次の点です。 私はハードウェア周りの開発に携わっていないので通常のフローもイメージがつきにくいことがありますが、そういった背景を踏まえても衝撃的でした。
- モジュールごとに切りはなしてそれぞれのモジュールごとに専任チームを作ってどんどん作る
- 直列ではなく、パラレルに開発できるようにする
- インターフェースによるアダプタだけしっかりと決めきって、それに合わせた入出力をモジュールで実現できるようにする
- モジュール同士の結合は CI/CD で行い、１日に何度も新しいパーツが入った状態でマシンを作成する（凄すぎ）
- 開発速度がものすごく早いので、協力会社にも契約書でこのスピードでやれることを前提として契約してくださいという頼み方をする
このあたりの考え方のスピード感・品質感が違いすぎて、世界で売れるプロダクトを作ってる会社はすごく先を行っているなと感じました…
私はこれまでソフトウェアの開発ばかり目を配っていましたが、改めてテスラを始めたBigカンパニーがどれだけ早く作ることにこだわっているかを学んでいきたいなと思えました。 そういった価値観が変容したという意味で、私にとってこのKeyNoteはとても価値があり、学びがあるものでした。
去年の動画などは公開されているそうなので、気になった方はこちらもチェックして見ましょう。 https://twitter.com/kawaguti/status/1702791844177002829
懇親会
はっきり覚えてないんですが、スクラムマスターとエンジニアの仕事の話を色々していた気がする。 今、自分はエンジニアとして働いているわけですが、スクラムマスターあんまり向いてなかったんだろうなあぁというのをここでも再認識していたような気がします。 （思考がテックより過ぎて、テックリードみたいなテクノロジのマネジメント、またプロダクトを良くするプロダクトのマネジメントには興味があるものの、ほかへの興味が今は薄め）
今の仕事に対しての考え方についてもまたどこかで発表したり、ブログ記事にしたいですね。
2日目
あさイチは移動の関係で間に合いませんでした。
受託アジャイル開発でスタートダッシュに成功して見えた景色
関係性のスタートラインの違いが、その後のチームメンバーの動きやすさやモチベーション、雰囲気につながっていき良い影響を生みやすいのかも？という内容でした。
失敗から学ぶためにしっかりとふりかえりをすることは大事ですが、スタートダッシュの段階でやってしまうとチームメンバーの成功体験が生まれづらく精神的に大変になってしまいます。 その結果、心理的にも向き合いにくい状況が生まれている… という可能性は確かにあるなあと私自身の経験とも符合します。
トークが終わったあと発表されていた Koito さんにも話を伺って納得が深まった部分がありますが、関係性が深まっていない状態で失敗するリスクはかなり高い、と感じました。 まずは関係性を良くして高いモチベーションで挑んで壁にぶつかってそれを乗り越えていく、というのがもしかすると今後理想的な進め方なのかなーと思いました。
自分自身は失敗から学べることがあるので失敗することがわかったと前向きに捉えられるのですが、過去のうまく行かなかった経験と合わせるとまずもっと関係性がうまく行ってから壁にあたっていけばよかったなと反省が深いセッションで、自分自身をふりかることができ、実りの多いトークだと感じました。
スライドこちらで公開されていました。 https://speakerdeck.com/yuhkoito/shou-tuo-aziyairukai-fa-nioitesutatodatusiyunicheng-gong-sitejian-etajing-se
チームに協働の意識を芽吹かせる合宿のススメ
合宿は書籍でも紹介されている通り、やったほうが良いプラクティスの一つで、これを実際何度か行って起きた良い影響についての内容でした。
私は仕事で合宿に行ったことはないですが、子供のころスポーツチームの合宿を経験して普段と違う雰囲気で練習することで伸び伸びとでき、発見があったと感じています。 そういう意味で合宿については、仕事で入ったことがないですが、ポジティブには考えていました。
発表を聞いていて実際に合宿をするにあたって集中できることや、場所が変わることによる特別感、一緒に時間を過ごすことによる心理的な変化がメリットなのかなと思いました。 普段の会議室でやると気持ち的にも新鮮さがなく、新しいことが生まれにくいようにも思うので、やはり場所を変えることによるメリットは大きいのかなと思います。
手法としてはドラッカー風エクササイズやジョハリの窓をお酒飲みながらやる、ということでした。 ワークショップの中でしっかりと自己開示しながらこのチームや組織が何を目指していきたいのかを明らかにしていくのは、明らかに非日常ではあるのですが、日頃の活動につながっていくいい試みなのかなーと思いました。 ただ飲みながらやると忘れてしまうのでは？ ということについてはたしかに翌朝見ると忘れていることもたくさんあるそうなのですが、当日は飲みながらで付箋をしっかりと貼っていくことで記録を残しているようです（お昼休みに小泉さんに質問して聞いてきました）。一気に飲んでワーッと話してその後書くにはだめということですねｗ
他にもワークショップとして目的に合わせていくつか使っているということでしたが、ラディカルビジョンステートメントは初めて聞いたので調べてみようと思いました。 本筋とは関係ないですが、しおりを含めても事前の準備の大切さ、色んな人が参加していることを配慮することを副次的に感じさせられるトークでした。
スライドこちらで公開されていました。 https://www.docswell.com/s/Insurtech-lab/51J4X3-2023-09-16-082010
War for talent 時代の、古くて新しい仲間集めの形 ～weak ties と strong tiesの力～
採用フローを自社主導で行っていくというところで、リファラルや自社応募を増やしてもらうための戦略についての内容でした。
自社ブランディングに関してはコロナ以前から人事・採用周りの文脈で話をよく聞いていたので、このあたりに関しては再認識できたなーという感想です。 一方でタレントプールの考え方についてはとても学びがありました。
ゆるくつながっていく weak ties の考え方は初めて知りましたが、濃くつながるのとは別で新しい情報を発見するチャンスにはなりえそうだなと思いました。 発表の中ではコミュニティでの繋がりや採用のつながりに話が広がっていきましたが、薄くつながることで度々情報を共有するというか、そういった場や関係性が大事だなと改めて思いました。
War for talent、 weak ties の両方ともあまり触れたことがなかった概念だったので、時間があるときに調べていきたいです。
スライドこちらで公開されていました。 https://speakerdeck.com/sadonosake/war-for-talent-shi-dai-no-gu-kutexin-siizhong-jian-ji-menoxing-weak-ties-to-strong-tiesnoli
「製造業にクラウドエンジニアを引き寄せろ！デンソーの採用プロセス改革とその挑戦」
こちらも採用フローの改善についての話で、主題的には前のトークに似ているかなと思いました。
こちらでは小さく事例づくりを行うことが大切というのがよく響いていたように思います。 ポジションが100以上ある中で、良い方法を模索しながら今後につなげていけるように活動しているとのことでした。
更にその先にあるのが、採用した人が活躍できているかどうかというところなのですが、ここについてはまだまだ試行錯誤しているところとブースで聞きました。 確かに採用してから活躍できていたり、どれくらい残っているのか、どういう強みがあるのか…みたいな分析は大事ですが、なかなかうまく回ってるなーと自分がいくつかの会社で働いた感覚だとないので、ぜひ今後さらなる取り組みがあれば続きの話を聞いてみたい…！と思っています。
改善も結構地道なものが多く、銀の弾丸はなく自分たちの問題にしっかりと向き合って改善していくことも改めて大切だと感じました。
理想のプロダクト開発を実践するために、チームの外部環境を整えたお話
チーム開発に対する試行錯誤の苦労が聞けるトークでした。
成長しているものの次々と起こる問題のために機能開発と、遊撃軍のチームを分けてなんとかしつつプロダクト開発に集中できる環境づくりをしているとのことでした。 こうなると機能開発が花形感が出てしまうので、遊撃軍もいい感じにメンタルケアや評価方法に変更によってうまくやってきたとのことです。 確かに遊撃軍チームはとても疲れそうなので、このあたりのケアは大事ですね…。
こうなると機能開発チームは理想的な状態でワークできるので、あれこれ試してみたいけど… というときにしっかりと問題を解決するか、ブロックして試すことができる状態にするのは大事だなと思いました（自分自身もそういう環境にできればなー… と思っています）。
野中スクラムへの回帰 - 「考える」と「つくる」が共にあるチームを目指して -
良いプロダクトとはなにか、それに向けてできることはなにか、ということについて熟考されているトークでした。
発表の中で良いチームと良いプロダクトの乖離については、なんとなくいいよねと思っているものをサイド分析して本当にそうなのか？というところに迫られているように思いました。 作ることに関してはスクラムをうまく使ってできる一方で、スクラムによるロールにハマりすぎてしまう問題は確かにあるように思いました。
アジャイルソフトウェア開発宣言で最初考えられていた、ビジネスと開発の融合的な側面は、スクラムのロールによりPOと開発者という分断が起きて失われているチームもありそうかなと思いました。実際自分もPOに企画面は若干任せきりだったので反省している部分はあります。 スクラムガイドにはバックログをどう作るかについてはあまり触れられていない（スコープ外）としていますが、現実的なチームではそのプロセスは存在してるわけで、それをチームで向き合っていかないと本当にビジネスと開発のコラボレーションで更に良いものは作りにくいのかもな、と思いました。
あとはモブプロをめちゃめちゃ推しているのかが興味深かったです。 モブプロ・モブ作業についてはたしかにやったほうがいいなーとは思いますが、個人的にハマり込めるほどには体に染み込んできていないので、もっと試してみるのもありなのかなあと思いました。なんか人に「強く」「熱狂的に」伝えたいと思えるほど、自分はまだそのメリットを理解できていないように思うので…
ちょっと雑感的になりますが、スクラムその先へというところでアジャイルをベースに考えているのかなーと思いました。
アジャイルを活用したProject-Based Learning (PBL)を通じた新卒研修: マネジメント能力の育成、OJT負荷の軽減、そして実践的プログラミングスキルの習得
パネルディスカッション形式でした。
何個か思ったことはあるのですが、個人的に一番強く思ったのは新卒研修にコストをかけないとだめなんだなということです。 同時にレベルを上げていける機会は特殊で、新卒研修が最後という話もあります。その側面もあるのでベースアップという観点でとても重要です。
新卒研修してもいなくなっちゃうんですよね、という話もありますがいなくなってもいいように新卒研修をちゃんとやっておく必要があるのかなと思っています。 同じレベルの新卒研修が行われれば、その新卒研修を受けたメンバーが循環することで人がいなくなっても中途で採用して同じレベル感を維持することができます。 ここで新卒研修を手抜いている会社がいるのであれば、数年後のレベル感はまばらになり、人がやめていく一方で入ってくるのは難しくなるのではないでしょうか？
これは体感なのですが、東京近辺のメガベンチャーでは同じような減少が起きていて、複数社で巡り巡っているような印象があります。 そうした人たちが果たして新卒研修をて抜いている環境に来るかというと、難しいかと思います。 むしろそういった輪に入っても見劣りしないよう、新卒研修をちゃんとやっておく必要があるのかな…と思います。
雑感・ふりかえり
まだまだ勉強不足だなーと思ったことと、やっぱりスクラムという型にハマるのは良くないなと思いました。 なぜアジャイル？ なぜスクラム？ そういったことを考えつつ、テクノロジーもビジネスも成長できるような状況にしていく必要があるなと思います。
またこれまでのスクフェスでかなりいろいろな経験の共有やお話の中で、自分自身のインプット量や実践というアウトプットが足りないなぁと感じました。 一旦今年のスクフェスへの参加はここまでにして、今年一年でスクフェスなどで学んだ知識を改めて定着させるべく、勉強しなおす期間にしばらく当てようかと思います。
旅行記
続きで書こうと思いましたが、また別の記事で書きます。 疲れたので。
