hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

和田卓人さん(t-wadaさん)をお招きし、「質とスピード」の社内講演会を開催しました

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

経緯

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

 

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

和田さんの講演会をアナウンスした時の盛り上がり

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

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

 

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

speakerdeck.com

 

ハイライト

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

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

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

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

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

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

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

質疑応答

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

講演会を終えて

講演後に実施したアンケート結果がこちら!

 

Q1. 講演内容についての満足度を教えてください。

大変満足が97.7%と、参加者みんなに響いた講演会となりました!


Q2. 今回の講演内容は業務に活かせそうですか?

業務に活かせそうだと感じた人が97.5%!開発の現場に変化が表れると嬉しいです。

Q3. 業務に活かしたい、活かせそうだと思ったポイントを教えてください。(一部抜粋)

技術力をつけないとスピードも質も上がらないし、今あるスキルだけで勝負していてもじわじわとスピードも質も下がっていく危機感を強く感じて、新しいスキルを身につける取り組みが必要だなと思いました。この資料は何回も見たことがあったのですが、実際にお話を聞くと心への響き具合が全然違いました。

 

保守性(質)は、将来の誰かのための道徳的な考えではなく、近い未来のおこる損得勘定であるというところは特にささりました。

 

初期の命題である「品質とスピード」は置いておいて、新卒を抱えるチームとしてどうしていくべきかの方針が見えたように感じる。

 

「質とスピードはトレードオフではない」ということが分かり、要件定義する際の考え方を変えられる気がしました。

 

トレードオフという言葉を盾に妥協してたかもしれないなーという気付きがあったので、今後は一歩踏み込んで本当にそのトレードオフは妥当なのか?ということを自分に問いかけてみようと思いました。

 

まとめ

当日の盛り上がり、アンケート結果からも、和田さんをお招きしてよかった!と思いました。この社内講演会で得たものが、プロダクト開発の中で活かされていくのも楽しみです。