2022年6月7日に、テスト駆動開発者の和田卓人さんをお招きし、社内講演会をオンラインで開催しました！

経緯

弊社では、2022年3月にテクノロジー部門のマニフェストとバリューができました。CTO 藤村が「和田さんの「質とスピード」のお話はテックバリューにも通じるところがあるのでは？」と思い、和田さんのお話をみんなに聞いてもらおうとお招きすることになりました。

結論：めっちゃ盛り上がりました

事前アナウンスでも盛り上がったのですが、当日はもっと盛り上がりました！

和田さんのアドバイスを受けて、講演会専用のSlackチャンネルを作成したのですが、講演当日の投稿数は1,223！リアクション数は1,540でした！月に一度開催される全社レビュー会での投稿数が数百なので、桁違いの盛り上がりです。同時視聴数も200人を超え、エンジニアだけでなく、色んな職種のメンバーが参加しました。

お話いただいたのはこちらの内容を元にしたものでした。

speakerdeck.com

ハイライト

全体的に大盛りあがりだったのですが、特に盛り上がった箇所をご紹介します。

みんな大好き和田さんの自己紹介

きゃー twada さんの表記ゆれだ〜〜〜
表記揺れで盛り上がる人たちいいなあ
twadaさんのおかげで表記揺れに気をつけるようになりました
記号やめろわかる（twitter: @ffu_）
まずはTwitterとGitHubでID取れるか確認してからアカウントつくります

保守性を犠牲にした現場からの中継に過去の経験が思い出される

あとからやるは、あとからやらず、大きなリニューアルをしようになるは世の常
「今作ってるものが動くか動かないかよくわからない」
// なぜか消すと動かなくなるのでコメントする
大域変数書き換えによる黒ひげ危機一発ゲームだ
祈り駆動開発だ
経験上祈りは届かないことが多い
※heyでは祈り駆動開発はしていません

内部品質への投資の損益分岐点で同意の嵐

1ヶ月！
わかる気はする＞1ヶ月以内
1ヶ月以内だとしたらやらない理由はあまりなくなるな
めっちゃわかる（1ヶ月くらいで後悔期間がくる）
やった未来と、やらなかった未来を比べたいよね
1ヶ月わかる、むしろ先週積んだコミットのコミットコメントに助けられることもある
結局、リリース後に手を入れないといけなくなって、ああ…. 読むのしんどい、テストめんどいってなる。

質疑応答

講演会の最後に質疑応答の時間を設けました。その中の一部をご紹介します。

Q. アジャイル開発をしていると、常にリリース可能でイテレーションを回しやすい要件を探り、いわゆる「自分達に実現可能な範囲」での開発に終始してしまいます。これを続けていると技術的なチャレンジの機会が能動的に得られず、技術向上が難しいと感じています。どのようなアプローチを取るといいでしょうか？

A. 組織構造、アーキテクチャで解決していかないといけない問題だと思っています。
技術的な多様性を保たずに手持ちの技術でベストな対応をしてしまうと、じわじわと技術全体が袋小路に入ってしまいます。

これはマイクロサービスが議論されるようになった背景でもあります。ひとつの技術基盤の中で、スピードを保ちつつ、技術的チャレンジをするのは互いに足を引っ張ってしまう。施策のスピード感だけじゃなく、技術的な意味での多様性もコントラストをつけたいから、とサービスを分けていくようになりました。

組織構造やアーキテクチャを工夫することで、実験的な要素や攻めの要素が多いところを分けしつつ、破綻なく同居できるようにする舵取りが求められます。例えば、全体のタスクの中の2割は開発チームが選んで技術負債の解消、新しい技術の調査などにあてるなど、開発チームが自由にやることを選ぶというやり方で、研究開発とイテレーション開発を両立する方法があります。

Q. 環境変化に対応するための新技術調査や技術的多様性の確保について、個人の努力に頼るのではなく組織として向き合うにはどうあるのがいいのでしょうか？

A. 学びを組織の中に組み込んでいかないと、結局詰んでしまう。これも組織構造やアーキテクチャの話に繋がりますが、学びを目的にするチームや組織、スプリントなど、学びに振ってしまう。成果ではなく、学び自身に評価を与える、学びを目的にする。

組織全体に波及させるのであれば、エンジニアがいつまでに何を作っただけでなく、どういった学びを組織に還元したか、内部品質の中でも後々効いてくるものに投資をしたか、例えばリファクタリングしたかなど、最終的には人事評価に還元されないとプロ意識や熱意に頼ることになってしまいます。