2023/10/31に行われた明日の開発カンファレンスに参加してきました。 PHPカンファレンスでのチラシで知り、1週間前に会社のSlackでもアナウンスがあったので、せっかくだから行くか〜となり有給を取っていきました！

ﾋﾟｵ! pic.twitter.com/37HBpl2JFK
— あすみ (@asumikam) 2023年10月31日

セッションの感想

開発組織を立て直すための技術

「どうやってCTOのスキルを身に付けたか」な話を、実体験を元に話していたセッションでした。

自分はCTOになりたいとかそういうのは全くないのですが、自分の目線で見てても「これは自分もやらないとな」と思うことがたくさんあり、とてもタメになりました。

例えば、btoさんはセッション内で、アンガーマネジメントができていなかったことを内省して5〜6年かけて軌道修正させていった、のような話をされていました。自分もわりとアンガーマネジメントできておらず、気を遣ってないと周りをｼｭﾝとさせてしまうことが多いので（だいぶよくなったがまだまだダメ）、もう少しちゃんとやっていかないとな〜〜〜という気持ちになりました。

あとは、最後締めに「計画的偶発性理論」の話をされていました。「個人のキャリアの8割は偶発的な出来事で決まる、計画的に偶発的なことを起こせばキャリアにプラスになる」のようなものらしいです。これ知らなかったのですが、めっちょ良いな！！！となりました。思えば、この半期の合同勉強会なども、カンファレンスやイベントに参加してなかったらなかったし、フッ軽でいることは大事だな〜と再認識しました。これからもアクティブ性高めていくぞ〜〜💪と嬉しい気持ちになりました。

開発生産性の可視化・改善はじめました

生産性の可視化自体はしていたが数字を見るだけだったので、そこを改善すべく、アクションをした、のような話でした。全体の数字を見てもどこをやるべきかわからない -> 個人やチーム単位にして計測をしてみた結果、見えてくるものがあったのだそうです。

また、可視化した結果、「PRのリードタイムが長い」という話だったので、そこからペアプロ・モブプロを導入した、という話があり、自分達もそれ悩んで同じことしていたので共感していました！

qiita.com

セッション中で紹介されていた記事が良かったのでここにも貼っておきます！

Tech Lead の役割とチームとは何かをもう一度考えてみる

「テックリードの選び方をどうしていたか、出てきた課題」を経験ベースでされていたセッションでした。

印象的だったのは、「組織の歪み」の部分の話で、よくない歪み「TL:1人でやった方が早い」「TL:自分の考えに従え」「メンバー:TLを認められない」「メンバー:TLさん決めてください」の4つの紹介の話でした。自分はTLじゃないのでメンバー目線のものの「TLさん決めてください」は気をつけないといけないな......と思いました。

「TLだからなんでもやってくれるでしょ、頼りきっちゃお」じゃなくて、自分でも考えるをやめちゃいけないな、と自戒しました。でも、技術選定などは自分で素案を考えて「どうかな？」をしてるので、良い動きだ💪（自画自賛）組織全体でそんな感じになっていきたいですわね〜

あとは、「育成目的で誰かをTLにする」という話は衝撃を受けました！「マジで力の強いもの」がなれる存在だと思っていたので...（もちろん素養はあるだろうが）視野が広がりました。

失敗から学ぶ、建設的な横断組織の作り方

自らが経験した「横断組織の失敗」を包み隠さず話してくださったセッションでした！

まだ横断組織にいなかった頃、横断組織なチームに相談しに行った結果、「正しいが、コミュニケーションとしてはとても辛い感じで、その結果ちょっとしたことが相談しにくい状況になっていた」という話をされていました。これは横断組織だけじゃなくて普段のコミュニケーションでも全然あることなので、「気をつけなきゃ、、」となりました（気をつける側😱

また、自分がマネージャーになった時になんでもできるスーパーマンを目指そうとして逆にボトルネックになってしまった、という話もされていました。

これは自分も今までの経験でめちゃくちゃ自覚あり、「全部自分でやろうとする」みたいなムーブをかましていた時期もありました...。自分がやったほうが早い、という感覚の時と、誰かに頼むのが申し訳ない、という気持ちの両方。でも今は同じように「ダメだな」と感じたので適宜に誰かに委譲するのをできるだけやっています。というか委譲できるのも能力の1つですよね。うまく言語化して適切なものをアウトプットしてもらう的な。

SREチームビルドと開発組織との関わり、そしてPlatform Engineeringへの取り組み

オンプレ時代からクラウドというのが当たり前になってきて、「インフラはインフラ、アプリはアプリ」の境目が難しくなっている（例えば、k8sなどの抽象化した技術になると、だれかコンテナ管理する？だれがマニフェスト書くの？的な）ので、インフラエンジニアのつらみ解消のためSREというポジションを作った、そこからさらにPlatform Engineeringにしていくまでの過程のお話でした。

アプリケーションの見るところ、SREの見るところ、それぞれ境目が曖昧になってきて、良いことではあるが、認知負荷が高まってきて、今は「Platform Engineering」という選択をしている、とのことです。なるほど...！！

今までの歴史？っぽいスライドと喋りがめちゃくちゃ「なるほどな〜〜」という感じで面白かったです。自分はどちらかというとゴリゴリオンプレ時代を経験してないエンジニアなので、こういうお話が聞けるのめちゃくちゃ嬉しい...

この前のSRE Nextでも情報が整理されていて分かり易い発表をされていたので、発表がめちゃくちゃ上手で素敵だ、、と思いました。素敵だ.........

↓この前のやつを貼っておきます...！

speakerdeck.com