12月5日(月)に、テスト駆動開発の第一人者であるt-wadaさんをお呼びして、社内講演イベント「組織に自動テストを書く文化を根付かせる戦略と戦術(2022冬バージョン)」を開催しました。
今回、私はこのイベントを企画し、実現にこぎつけることができました。本記事は、その経緯や感想をまとめたものです。
企画のきっかけ
t-wadaさんには、昨年と一昨年にも社内講演をしてもらっています。2年前には「エンジニアとしてこの先生きのこるために」、1年前には「質とスピード ～ソフトウェア開発の 典型的な誤解 を解く～」を題材としていました。
前回の流れは、下記の記事にて紹介されています。
これらの講演の成果もあり、社内ではエンジニア教育や内部品質に対する意識が向上していました。しかし、具体的な戦略や戦術に関しては、まだまだ課題が残っていると感じており、その解決の一環として企画しました。
・・・というのは、社内向けに用意しておいた、お行儀の良い企画書の要約です。
もっとシンプルな動機としては、単純に下記のような感じです。
- 最低でも1年に1回は、外部講師によるエンジニア向けの社内講演イベントが開催されてほしい
- 自分が講演を聞きたい。t-wadaさんに質問する機会がほしい
- 社内講演イベントに企画として関わってみるのも楽しそう
- 組織全体に対して圧倒的な影響を与えるような仕事がしたい
それらが私のモチベーションとなっていました。
講演内容
t-wadaさんには、事前の打ち合わせにて当社の実情をお伝えし、組織に自動テストを書く文化を根付かせる戦略（2022秋版）などの講演をベースにしつつ、当社向けにアレンジした準新作として講演してもらいました。
当日利用したスライドは下記のものです。
講演中のできごと
当日は、前回開催時の人数を超える350名以上の社員が出席しました。オンラインのイベントとして企画していますが、Slackの実況チャンネルを作成したうえで、講演中はそこに自由に書き込んでもらいました。t-wadaさんからも、講演の冒頭で、実況チャンネルをとにかく盛り上げるように説明がありました。
その結果、書き込みがものすごい速度で流れていきました。直近の経験に照らし合わせての感想や、講演内容の書き起こし、引用された書籍のAmazonへのリンクが瞬時に貼られ、書籍購入支援制度を利用しての購入を呼びかける書き込みなどなど。t-wadaさんにはその反応をリアルタイムに見てもらいながら、講演の内容を調整していただきました。
そのような環境のおかげか、t-wadaさんの講演は、驚くほど出席者の経験や悩みに響いていました。
オンラインだと、一緒に働いている周りの人たちが何を思っているのかがよくわかるというメリットがあります。t-wadaさんによると、こういった体験を通して、感情のうねりを作っていくということは、組織にとってとても価値があるということでした。
質疑応答
質疑応答ではSlidoを利用しました。当初の予定を30分オーバーしましたが、参加者からのすべての質問に回答してもらえました。私自身も2つの質問をしたので、その質問と回答の内容を抜粋します。
E2Eテスト自動化のSaaSを利用するときのポイントは？
Q: E2Eテスト自動化のSaaSとして、MablやAutifyなどのサービスが出てきています。それらを利用することは信頼性の高いテストの保守に寄与するのでしょうか。それとも、単にそれらを利用するだけではなく、気をつけなければならないもっと重要な点があるのでしょうか。
A: MablやAutifyは、E2Eテストの実行管理やメンテナンスを半自動化してくれるサービス。
画面から叩くE2Eテストの辛いところは、仕様変更があるときにテストケース側のメンテナンスが必要になるところ。
しかし、それらのサービスは機械学習によって、E2Eテストを自動でメンテナンスしてくれる。
E2Eテストの保守コストを下げるために外部の力を借りるイメージで捉えてほしい。
それらのサービスがあるからテストは全部それでいいかというと、そうではない。
E2Eテストはメンテナンスのコストが下がったとしても、結局のところ、遅くて不安定である。
このため、「MablやAutifyが便利なので、テストケースの作成は全部それを使えばいいや」となったら、開発のスループットが上がらない。
「E2Eテストの保守コストを下げて、浮いた時間でテストピラミッドをアイスクリームコーン型からピラミッド型にしていくことに時間を使うことができるサービス」と捉えるべき。
機能の「葬り」の秘訣は？
Q: 書籍『事業をエンジニアリングする技術者たち ― フルサイクル開発者がつくるCARTAの現場』で紹介されている事例では、保守対象のコードを減らしてアジリティを高めるための、機能の「葬り」が成功しているように思っています。機能の「葬り」は、一般的にどのような戦術（順番）で進めれば成功すると思いますか？
A: 保守対象のコードを減らす「葬り」には、さまざまなレベルがある。
事業レベルで廃止する、サービスのある機能を廃止する、デッドコードを廃止する、など。
デッドコードを廃止するのはエンジニアが（勝手に）やればいい話。
一番効果が高いのは「事業レベルで消す」だが、ビジネスレベルでの合意が必要となる。
そのサービスの事業責任者と「事業を葬れるか」という議論ができるようになっていくことが大事だが、事業レベルでの葬りは難しいシステムも多い。
このため、実際には機能レベルの葬りもやっていく。
このときに問題になるのが「事業としては利益を生んでいないが、ちょっとでもユーザーが使っている機能」の存在。
「ちょっと価値があるけどほぼ赤字」というサービス・機能は一般的にとても多い。
「大多数のユーザーは代替の機能に移行しているけれど、少数のユーザーが移行していない」という例が多い。
そういったケースでは、基本的には機能廃止予定を明示したうえで、移行を誘導、サポートしていく。
サービスの性質によっては、インセンティブを設けることができる（詫び石など）。
基本的にはその形で進めていくが、カルタホールディングスの場合は20年経っているシステムだったので、既存のコードをメンテナンスし続けることが、どれだけ新規事業のスピードの足を引っ張っているのかということが事業部長のレベルで理解できていた。このため、話が早かった。
感想
よくイベントに登壇する人が一番美味しい思いをするという話がある。イベントで人に情報をアウトプットするために、そのカテゴリの情報を言語化できるようにまとめる作業において、知識は強く定着し、結果としての技術力の向上に繋がる。
エンジニアのイベントへの登壇をどう評価に結びつけるか｜えふしん｜note
イベントに登壇する人が一番美味しい思いをするという話は、私自身もデブサミに登壇したとき1に実感しました。しかし、イベントを企画するのは、二番目に楽しいし美味しかったです。
企画書にイベントのねらいをまとめ、登壇者に最大限のパフォーマンスを発揮してもらうために打ち合わせをし、参加者にアンケートを配布して回答を確認し、当日は盛り上げ、出席後にレポートを書く（この記事もその一環です）。その過程において、登壇と同様に知識は強く定着し、結果としての技術力の向上に繋がったのではないかと思っています。
そして、社内講演企画を主導する経験は、とにかく楽しかったです。実現までにやらないといけないことは多く、通常業務の傍ら企画を進めるのは大変ではあったのですが、私の手が回らなかったり不得意なところはDeveloper Relations Grp.2をはじめとする周りの方々がサポートしてくれました。
このような研修の企画は、それを専門とするチームが担当する領域では？と思われるかもしれません。しかし、私は「開発者自身がやりたい企画を主導する」ことで得られるものがあると思います。実際に、私はものすごくモチベーションが上がっているわけですから。
来年も、社内講演企画を主導してくれる人が居るといいな！
-
「開発内・開発外との関係性を紡ぎ出し、製品開発に必要となる環境を整える」をミッションとしたチーム ↩