えもいブログ

AIトラベルのCTOをしています。n=1 の事実をもとに思うがままに書きます。emotionalだったり、そうじゃなかったり。

テスト時間を短縮化し、リリースサイクルを高速化したい話

前回までは、開発組織や採用の話をしていたので、今回は気分をかえて少し技術よりの話をしてみようかと思います。

今回のお話

AITravelはビジネスに影響が大きい機能については、E2Eテストを真面目に書いています。その結果、CircleCI 上で7コンテナを利用しても、テストが完了するまでに、30分もかかるようになってしまいました。 今回はそれに我々が立ち向かっていくお話をしようかと思います。

ちなみにまだ問題は解決はしていませんが、ステップを引いて取り組んでいるのでそれのご紹介をします。

AITravelの機能開発後からリリースまでのフロー

AITravel はざっくりいうと開発者の開発完了からリリースまでに下記のフローをとっています。 ざっくりなので、厳密には違います。ただ、イメージは伝わるはず。

  1. プルリクエストをレビュアがレビューする。
  2. レビュアがアクセプトしたら、masterの差分を開発者のブランチに取り込み、ステージ環境にデプロイする。(ここでCI上で自動テストが走る)
  3. QAが受け入れテストをする。
  4. masterにマージ→リリース

大きな機能追加をたまに行うときはこのフローで十分なのですが、小さな機能改善を細かくリリースしたいときに、テストの待ち時間が多く、とてもストレスフルな状態になってしまいました。 せっかく自動なのに、毎回リリース作業で、30分ほど無為な時間があるのはちょっとつらいです。

また、WIPのプルリクエストをpushした際も自動テストがCircleCI上で実行されます。開発者による普段の開発という観点から見ても、テストの結果がわかるまでに時間がかかるために、落ちるなら早く教えてくれよ!って感じになってしまい、その観点からも精神衛生上あまりよろしくない状態になってしまいました。

初めは素晴らしい仕組みだった

我々のサービスの大きな価値の一つに、ユーザが出張の手配作業を簡単にできるようにするという点がありますが、それを担保するために様々な条件のテストが書かれています。 ユーザの環境を可能な限り再現したいため、E2Eでのテストが主流になっています。ユーザに近いレイヤでテストができるのは安心感もあり、初めはそれで良かったのです。

サービスが成長するにつれて暗雲がただよってきた

開発あるあるですが、初めは片道・往復だけであった出張の予約パターンも、複数の拠点を任意の個数追加できるような仕様の追加であったり、旅行のパッケージサービスの追加など、どんどん要件が追加され、機能が増えていきました。

そしてテストコンディションは膨れ上がっていったのです。

さてどうする

3つのステップでテスト時間を短縮化する構想を立てました

  1. ロジックのテスト、特にモデル層周りのテストを増やす。
  2. 必要最低限のE2Eテストを作り、リリースフローに入れる。
  3. 既存のE2Eテストは開発、リリースフロー上では実行させず、非同期で実行させる。

ロジックのテスト、特にモデル周りのテストを増やす

そもそもなんで、そんなにE2Eのテストケースが多いかというと、ロジックをほとんどすべてE2Eでテストしていたからでした。そのため、可能な限りロジックやモデル周りのテストでケースの爆発を抑え、E2Eは本当に最低限の掛け合わせだけ行うようにするという意思決定をしました。

そして、油断するとテストは誰しも書かなくなるので、コードを書き足してpushした際に、CI上でテストコードがカバーしていない部分のモデル周りにコードの差分が発生した場合は、テストが失敗するような仕組みを入れました。

もちろんどうしてもテストがしにくい部分というものはあるので、そこについては、指定したコメントを挟むとテストが書かれていなくてもテストが通る仕組みをつくりました。 ただし、レビューアがOKを出さない限りは、原則許容しないという運用でカバーすることにすることで乱発を抑える努力をすることにしました。

運用して2ヶ月ちょっと経つのですが、今までモデルのテストはあまり書かれなかったのですが、急に書かれるようになって効果を実感しています笑 一方、テストのチェックをスルーするためのコメントが増えてきており、おやおや?というところもあります。

まだまだな部分も多くあるのでこれからも引き続き打ち手を考えていきたいです。

必要最低限のE2Eテストを作り、リリースフローに入れる

ロジック、モデル周りのテストが増えてきたら、さじ加減が難しいですが、ざっと主要業務の機能テストするという目的でE2Eテストを薄く書いていく予定です。 必要最低限ってなんやねんという話はありますが、一旦「2条件の掛け合わせ以上のテストケースは行わない」という決めでいこうと考えています。

より具体的には、スプレッドシートで直行表を作って自動でテストコンディションを作れるようにしているので、それを使うだけな感じになります。 3条件以上の掛け合わせだと使うのが厳しいのですが、今回の上記の決めにより運良く使えそうです笑

これで、並列7コンテナで30分にはならないであろう。

既存のE2Eテストは開発、リリースフロー上では実行させず、非同期で実行させる

既存のテストを捨てるのはやはりもったいないのと、この防御壁があったため大きな事故なく今まで開発出来てきたのは紛れもない事実なので、うまく資産として使っていこうと思いました。

そのためただただ捨てるという手は取らずに有効活用していくことにしようと考えています。具体的には、本番環境に新しい機能がリリースされたことを検知し、別の環境でマスタのブランチをもとにサービスを自動でデプロイ→既存のE2Eテストを実行するという仕組みを構築します。

もちろんこのテストが実行されるまでに機能のリリースは完了してしまうので、ここでバグが見つかると辛いのですが、検知できるという意味では非常に意味があると考えています。

リリースまでの時間の短縮化とのバランスをとる形の対応と捉えています。

最後に

論理的に漏れダブりのないテストを行っていくのも大事と思いながらも、現実世界で限られた時間ですばやくユーザに価値を提供するためには、ラインを見極めながら今回みたいな対応を進めていくことが大切だなと考えています。これで開発スピードがより上がって欲しい。。!

ちなみに、実際のモデルのカバレッジチェックを用いたテストの仕組みはyokomotodさんに作っていただきました。ざっくりとした構想を伝えただけでサクッと作ってくださったので、大変助かりました。

この場を借りてお礼をお伝えしたいと思います!ありがとうございます。

AITravelのエンジニア採用を支えるであろう採用基準

先日正社員0のエンジニアチームの組織づくりという記事を書いたところ、意外と多くの人に見ていただけました。

ありがたいなぁと、しみじみとしていたのですが、あれ?よくよく考えたらこれで万が一たくさんの方がエントリーくださったら、僕たちの採用基準が不明瞭であることがバレてしまう。。ということに気が付き、不明瞭な部分を言語化するプロジェクトを発足することにしました。

もちろん面接と評価は過去何回もしていて、業務経歴を具体的に伺ったり、1人で小規模なウェブアプリがサクッと作り切れるか?とか、いろんな観点から根堀葉掘り聞いていたりはしたのですが、きちんとラインを引いていたわけではなかった。というのが正直なところです。

ここでは、こんな感じの人とAIトラベルは一緒に働きたいよーそして、それをこうやって見極めていくよーということを書こうと思います。

もし我々の会社にエントリーくださる場合はご参考くだされば嬉しいです。(社員・業務委託、どちらの業務形態でもウェルカムです!)

今後変わるかもしれませんが、その点はお許しください。。

つまり、現状はソフトウェアエンジニア採用について、ふんわり運用からもうちょっと方向性を定めて運用を固めていこうと試行錯誤している状況なのです。

AITravelで一緒に働きたいソフトウェアエンジニア像

精神が成熟している1人前のソフトウェアエンジニア

一緒に働きたいソフトウェアエンジニア像の背景

精神が成熟していることについて

僕たちはフルリモートでソフトウェア開発を行っています。 そのため、基本的には自分を自分で律し、自分のリズムで着実に仕事を進めていただく必要があります。

そして、基本的に非同期でコミュニケーションをおこなっていくため、画面の向こうにいる人のことを常に思いやりながら、仕事が最速で進むようなコミュニケーションを組み立てることができることが非常に重要だと考えています。

そういうスキルを持つことを「精神が成熟している」という言葉に込めています。

1人前について

これも、我々の働き方からの制約による影響を受けている部分が多いのですが、リモートでソフトウェアエンジニアを1から育てるのは、現状は全く我々の組織でできるイメージがつかず、ある程度経験がある方を募集せざるを得ないと考え、このようなメッセージをおいています。

なお、1人前と言っても、とてつもなく高いレベルを求めているわけではなく、ソフトウェアのバグがあったときに、問題の切り分けを行いながら、ミドルウェアのソースコードも読みながら、きちんとソースコードを追いかけ、問題に対応することができるぐらいのレベル感を想定しています。

見極めかた

成熟していることをどう見るつもりか?

やばい。やり方わからん。。というのが正直なところです。僕もCEOも採用基準として書いたものの別に精神成熟していないし。

(落ち着いているほうだと信じたいのですが。)

現状は、ベタですが、面談で我々とオンライン or 対面で会話をして、仕事のやり方などを聞きつつ、一緒に働けそうか判断するしかなさそうだと考えています。

特に副業の場合、平日夜なのか?朝やるのか?土日はどれぐらい割く?みたいな自分の行動パターンのイメージがないと、お互いおそらくしんどくなりそうですので。

あとは、バグが含まれたプログラミングコードをお渡しして、オンラインで会話を重ねながら、バグの原因を見つけてもらうようなタスクを準備しようと考えています。(できるかどうかは僕の体力と精神力次第でやらないかもしれません。)

その課題を通じ、コミュニケーションをしつつ、仕様として何を想定していて、そのコードは一体何を満たそうとしているかをきちんと捉えながら、問題解決できるよう我々を導いていただけるかを見ていこうかなぁと考えています。

1人前エンジニアであるかをどう見るつもりか?

これも正直よくわからん。。

知りたいことは、「独力である程度なんとか開発を進めていけるか」なので、経験とかスキルセットをGitHubなどでふんわり判断したうえで、上記のようなバグ探しタスクに加え、簡単なホワイトボードコーディングをいくつかやるイメージでいます。(こちらも僕の体力と精神力次第です。個人的にはやっていきたいのですが、過去の経験上、準備と面接が大変なので、ちょっと想像しただけでもリソースが少ない僕たちには結構辛い。。)

業務経験について

業務経験だけで見るのは良くないと思いつつ、これぐらいは欲しいと言う目安を書いておきます。(あくまでもイメージです。)

  • 下記のいずれかを満たしていること
    • 1年以上のRuby on Railsを用いた開発経験
    • 5年以上のウェブアプリケーション開発経験
  • 下記は必須
    • Gitを用いた開発経験
    • アジャイル開発またはそれに準ずる開発プロセスによる実務経験

ホワイトボードコーディングについて

我々はスタートアップによくある Ruby on Rails + React という構成なので、それにちなんだタスクを鋭意準備しておりますが、言語で変に一緒に働くエンジニアの方の選択肢を削りたくはないとも思っているので、候補者の技術スタックに合わせた課題も準備したいと考えています。

以上です。まだゆるゆるなのですが、このあたりもこれからしっかり決めていきたいなという思いを込めて書いてみました。

いつもの大切なやつ

  • AITravelはフルリモートで働けるRuby on Rails/React エンジニアを募集しています。興味のある方はこちらから!

正社員0のエンジニアチームの組織づくり

サマリ

  • 正社員0で業務委託のみの10人程度の小さな開発チームは結構安定していい感じに運営できるみたい。
  • チームが小さい間は現実的な選択肢としてありえる。

前置き

これから、僕がCTOをやっているAIトラベルという会社で、うまいことエンジニアチームを回せるようになってきたぜ!みたいなことを書くのですが、決して僕個人のエンジニアのキャリアの中でエンジニア組織をうまく回せてきたわけではありません。

いくつかの開発組織を経験して、直接僕が原因であったわけではない(と信じたい)ですが、開発チームがうまく機能しておらず、どんどん人が減っていく状態をエンジニアの立場から見てきました。そして自分に力がなく、それを改善することは出来なかった苦い思い出もあります。

そういう悲しい経験も踏まえて、エンジニアチームをどう運営していけば、小さいチームでも着実にプロダクトを育てていけるのかをいろいろ考えてきたので、少しでも参考になる部分が読んでいただけた人に共有できると嬉しいです。

そしてもっと良い方法があれば切実に教えてほしいです。

強い組織ってなんなんだろう

ビジョンに紐づくエンジニア集団に対する幻想

昔はエンジニアの採用担当として、常にビジョンに共感するソフトウェアエンジニアを探し続けていました。そして、技術力が高いソフトウェアエンジニアを求め続けました。 ただ、そんなエンジニアには出会えませんでした。(もちろんいないことは証明できないのですが。。)

そもそも考えてみると、メルカリのように、資金が潤沢でビジョンやプロダクトの方向が定まっているような会社で取るべき選択であって、資金が潤沢でなく、事業がピボットするような会社がそれを取るのはいささか無理があるやりかたなのかもと思います。

小さな組織における強い組織とは

僕たちは小さい開発組織(ソフトウェアエンジニアが10人程度)ではあるのですが、サービスにお金を払ってくださる大きなクライアントがおり、サービスを絶対に潰すことができません。でも、そんなお金がたくさんあるわけでもなく、外から見れば、他の会社に比べて魅力的なのかも正直なところ自信がありません。(いい会社なんですけどね。。)

そのような状態でもソフトウェアエンジニアを確保しつつ、プロダクトをきっちり育てていける盤石な状態を作ることが我々がめざす強い組織なのではないかという結論に至りました。

AIトラベルのアプローチ

いろいろ諦めました。

諦めたこと

  • フルタイムのソフトウェアエンジニアを採用することに固執することを諦めた
  • 稼働時間をきっちりトラッキングすること

諦めなかったこと(これからも諦めたくないこと)

  • ソフトウェア仕様とタスクの優先度付け
  • 自動テスト
  • 開発者の人数をちゃんと増やしていくこと

フルタイムのソフトウェアエンジニアを採用することに固執することを諦めた

自分の周りをみていても、優秀なソフトウェアエンジニアなんてほとんど知り合いづてで転職しているので、転職市場に出てくることはケースとして少ないでしょうし、いきなり自分たちのプロダクトに惚れさせるのは結構無理があります。

(ビジネス側の人は惚れさせることができるプロダクトだと思うのですが)

でも優秀なエンジニアが欲しいとなると、副業でもなんでもいいから手伝ってもらえる人を探すのが現実的という結論に落ち着きました。 そして、そういう人たちの数を増やしていき、開発組織を安定させていく方向に倒しています。

ちなみに、AITravel はもともとはCEO 1人で開発していたソフトウェアでした。

そういう組織なので、ソフトウェアエンジニアはフルリモートOKにしていますし、今後も変えないでいこうと考えています。 現状もオンラインでのミーティングもほぼなく、Slack, チケット, プルリクによる非同期なやり取りで、ほぼ完結させています。

もちろん、それによる面倒さもリスクもあるのですが、少なくとも現状我々の文化にはあっているようで、大きな事故なく回っています。 取締役3人のうち、CEO, CTO がエンジニアであり、ソフトウェアの要件のコントロールをしているというところも結構大きいのかも。。?と思っています。

稼働時間をきっちりトラッキングすることを諦めた

そもそも、一人前のソフトウェアエンジニアが、そんなに作業をサボるのであろうか?というのがこの諦めの始まりでした。 WIPのプルリクをみれば、だいたいどれくらい進んでいるかはまぁ見えるし、ざっくりしたスケジュール感と確度だけ教えてもらえれば、経営的にはそんなに困らなかったのです。

なので、「稼働時間」のトラッキングををやめ、自己申告の時間報酬分を払う、そのかわり成果はしっかり見て、単価と見合うか定期的にウォッチしていく方針に振りました。

ソフトウェア仕様とタスクの優先度付けは諦めなかった

エンジニアの方に自由に働いてもらうために、細かい話でいうとソースコードのコンフリクトが起きにくい順番で開発を行えるようにする調整や、大きい話でいうとビジネスインパクトに対する機能の優先づけは、僕がやることになりました。

今後は、細かいところはどんどん経験値の高い業務委託の方に順次権限委譲していきたいと思っています。

自動テストは諦めなかった

いろんなレベル感の人がソースコードを触るため、テストが無いとやってられないということで、ここはちゃんとしてます。(実は、E2Eテストが30分かかるというとんでもない状況になっていて、これを解決していく話も今後書こうと思います)

今は追加でモデルのテストを書かないとそもそもCIが落ちるという仕組みを作って更に重要なビジネスロジックに絡む自動テストを強化する運用を進めています。

開発者の人数をちゃんと増やしていくことは諦めなかった

我々は明確に強く優秀なエンジニアを取りに積極的に取りに行くことを諦めました。(もちろん来ていただきたいのですが、、待ってます!) なので、きっちり組織の人数を増やして戦っていく必要があります。

ただ、現状は何故か優秀なエンジニアが結構いる組織になっています。運と縁に恵まれているのでしょうか。

このやり方で上手くいっているところ

お手伝いいただいているエンジニアの方と長く一緒にお仕事できているところです。

結局ソフトウェアの設計の知識は人に貯まるので、どういう関係性であったとしても、長期間働いていただけることがサービスの成長に重要であると考えていたので、とても感謝しています。

僕たちのやり方が、少なくとも今いるエンジニアの方にとってはマッチしているやり方なのかなぁと考えています。

おかげでそんなに急ピッチで人を増やす必要もなく、こんな小さな会社なのに開発組織として非常に安定しています。

うまくいっていないところ

改善ポイントはたくさんあれど、現状は想像以上にうまくいっていると思います。 強いて言えば、仕様やプロジェクトマネージメントのようなコントロールが全てCTOである僕になっていて、そこがボトルネックになりそうなところです。

今は、技術的なところとビジネス的なところをふわっと僕が決めて、場合によっては画面設計・データベース設計などもしてしまっているのですが、このペースでエンジニアを増やすとおそらく来年半ばにはパンクしていることが目に見えるので、こっちの職種もなんとかしないと。。というのが今の課題です。

最後に

個人的には、ビジョンで一致団結したチームみたいなものも好きなのですが、こういうやり方も一定ありだなと最近はすごく思っています。

いろいろ諦めを入れつつも、ソフトウェアエンジニアの方々がより働きやすく、その結果プロダクトが成長し大きく利益が出せるようになればいいなぁと願っているし、そうなるようにしていきたいと考えています。そして、その結果をチームに還元できる組織にしていきたいです。

大切なやつ

  • AITravelはフルリモートで働けるRuby on Rails/React エンジニアを募集しています。興味のある方はこちらから!