えもいブログ

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

チケットを書く技術

まだまだAIトラベルは小さな組織なので、要求分析・要件検討・システム/データ設計・チケット作成のようなコード書く前工程を多くの場合、僕が受け持っています。 最近、ディレクタの方にジョインしてもらい、チケットを作成する仕事は少しずつ僕から剥がれはじめてきました。

本格的に僕がその作業から離れる前に、僕が今まで蓄積してきたチケットを書く技術をテーマに本記事を書いてみようと思います。

注1) ここでは、技術調査やリファクタリングのような、技術寄りの問題を解決するチケットの話ではなく、ビジネスサイドと新規機能開発を進めている文脈でのチケット作成の話を書きます。技術寄りのチケットを作成をするときは全く別のテクニックが要求されますが、今回はスコープから外します。

注2) タスク管理、プロジェクト管理のためのチケットを書く技術もあるのですが、こちらもスコープから外します。

注3) B to B のサービスを提供している文脈で記載しています。B to Cのサービスでは必ずしも当てはまらないことを書いているかもしれません。

この記事の内容を一言で言うと

チケットはエンジニアとのコミュニケーションを取る1手段でしかなく、チケットを書くモチベーションとなった背景と、何を達成したらそのチケットを解決したと言えるかをきちんと言語化しましょう。

というお話です。かなりあたり前の話を書いている気もしているので、そうだよね〜と思われた方にはあまり価値を提供できないかと思います。

チケットを書く目的

チケットを書いて達成したいことって、少なくともビジネスサイドから見ると、エンジニアに作ってもらいたいものを伝えるためにあるんじゃないかなと思います。

作ってもらいたいものを伝えるためには、

「結局何が作られていたら、完成と言えるか。」

を定義することに尽きます。

世の中的な言葉で言うと、受け入れ条件の定義というものかと思います。

受け入れ条件を書く前に・・・チケットを書こうと思う背景となった情報の共有を頑張る

チケットの受け入れ条件を本当に細かく書くと、ほとんどプログラミングをしているんじゃないかと錯覚するぐらい、内容を詳細に書くことができます。 その代償としてチケットを作成するための工数が沼のように消費されます。

一方で、ざっくり書きすぎると、欲しいものとズレたものが出来上がってしまったり、そもそもエンジニアが手を動かす前に終わらない質疑応答の打ち返しが発生して、お互いのストレスがすごいことになりますw

この悲しい状況を減らすために効果が大きいのは、受け入れ条件を定義して伝える前に、下記の2つを明確にして共有することです。

  1. 機能開発が必要になった背景
  2. 機能により達成されるユーザの業務/シナリオ

例(あくまで一例です。)

機能開発が必要になった背景

○○会社の〇〇さんが、○○の状況で、○○を行うという業務が存在する。
現状は、○○という作業を行っているが、明らかに非効率である。
我々のサービスはそれを解消できる余地があるため、これに取り組みたい。

機能により達成されるユーザの業務/シナリオ

1. ○○さんが○○という業務をする。
2. 今回作成する○○という機能を利用して、情報を登録する。
3. ○○という機能で作成された情報が○○というサービスに自動で連携される。

これにより、ユーザの○○の業務における非効率な作業を取り払うことができる。

できるだけ具体的に書き、誰が見ても、あーこの問題は解決してあげたほうが良いなと思える文章が書けると上出来です。

ここがきっちり書けていると、経験豊富なエンジニアがよりイケている解決案を出してくれることもあり、とても生産的な時間を過ごせることもあります。 また、多少受け入れ条件がざっくりしていても、エンジニアが察してくれます。(あまりやっちゃダメですよ。)

受け入れ条件の定義

「どうであれば、リリースしても問題ないか?」を具体的に書いていきます。

作りたい機能によってケースバイケースな部分はありますが、下記の3つが揃っていれば、ほぼ大丈夫だと思います。

  1. 画面のモック
  2. どういうときに、システムがどう振る舞うか
  3. どのようなデータが蓄積され、どのように利用されるか

もちろん、チケットを書く目的にあるように、エンジニアの人にきちんと作りたいものが伝わればそれでよいので、適切に手を抜くのも重要かとは思います。

ただし、ここを手を抜きすぎると、受け入れテストを行うときに、あれ?何を確認したら良いんだっけ。。?ってなるし、コミュニケーションの齟齬が高確率で発生するので、慎重にサボる必要があるとは思いますw

最後に

いいチケットは、チーム内のストレスの総量を減らし、機能開発のスピードをいい感じにしてくれると思います。 さらに、ビジネスサイドとエンジニアサイドの建設的な議論の土台になります。

実際のところ、チケットはあくまでもコミュニケーションの手段なので、いくらでも簡素にはできると思います。

でも、チームでプロダクトを開発する上で、とても大切な要素だと思いますので、もし何か開発がうまく回ってないなぁと思うことがあれば、見直してみると良いことがあると思います。

AIトラベルでは、ソフトウェアエンジニアだけでなく、素敵なチケットを書いてプロダクトの開発を加速させることができるプロダクトオーナも募集していますので、ぜひご連絡ください。

AIトラベルのプロダクトを作る際に大切にしたい4つの考え方

AIトラベルの開発チームは、今まで主に業務委託のエンジニアの方にタスクを切り出す形で開発を進めてきました。

そんな中で着実にビジネスやプロダクトが大きくなってきて、プロダクトに関わる人も増えているので、開発チームの組織化を本格的に進めていくフェーズに入ってきたのではないかと感じ始めてきました。

開発チームの組織化するに先立ち、僕たちが何を大切であると捉え、プロダクトの開発を進めてきたのかを言語化することで、その価値観をともに進化させていける開発チームにしていきたいと考えています。

そういう背景から進めてきた言語化作業ですが、ある程度言葉になってきました。

こういう考えをアップデートしていく過程を残しておくこと自体に、根拠はないけど何らかの価値があるかもと感じ、あえて情報をオープンにしてみるのも良いかと思い、ブログとして書いてみました。

すでにお手伝い頂いているメンバーからすると、特に何かが変わることはないと思いますが、僕たちがどういうことを考えながら色々な意思決定をしていることを知っていただければ嬉しいなと思っています。


1. ユーザへの価値提供のスピードを最大にする。

プロダクトを正しく作ること、正しい手続きを踏んで世に提供されることはもちろん大切です。 ただし、常にプロダクトを通じたユーザへの価値提供スピードを最も重要な観点として我々は扱います。

2. 本質的な価値を見極める。

プロダクトに関する全ての要望に応えることはしません。裏にある本質的な課題は何なのか、そこに普遍性はあるのか、その課題を解決することが本質的にプロダクトの価値向上につながるのかをシビアに我々は判断します。

3. 反脆い(はんもろい)システムを構築する。

外的環境は高速に変わり続け、システムは壊れ続けます。壊れないシステムを作ることより、壊れても問題が最小化されるシステムを作ることを我々は目指します。

4. 複数の観点から考える。

システムにおける観点・原理原則は万能なわけでなく、時にぶつかり合い、文脈に大きく依存します。そのため、注意深く文脈を把握した上で、複数の観点から選択肢を吟味し、総合的な判断を我々は下します。


僕は実のところ、大切にしている考え方であっても、組織内外の状態に応じて柔軟に形を変えてゆくべきものだと考えています。

※ もちろん考えをぶらさずにいることも同じぐらい重要だと思っています。ただ、考え方が柔軟である方が変化があってワクワクするんじゃないかな。

仮に組織で大切にする考えが変化していくとしても、組織を適切にコントロールしていくためには、今の考え方がいったいどうであり、どういうスピードでアップデートしていくのかを可能な限り正確に捉える必要がありそうです。

そのなかで、僕が主体的に現状に合った、ときにはストレッチするための考え方・文化を醸成する努力をすべきなのかなと考えています。

まだまだAIトラベルは走り出したばかりで、様々なところが発展途上ですので、こういった開発の文化なども一緒に考えていけるメンバーも募集しています!


あまり目立ちたくないという性格ゆえに、TwitterもAIトラベルのCTOになってからアカウントを取り直しコソコソやっているのですが、もしよければフォローしていただければ嬉しいです。

場所にとらわれない開発チームづくり

AIトラベルの開発チームは、フロントエンドエンジニア/バックエンドエンジニア/ディレクタすべてフルリモートで仕事をしています。

※ インフラまわりはCTO/CEOが現状は対応しています。

僕がAITravelにJoinしてから1年ぐらい経ちます。 今までは業務委託の方がメインで傭兵の集まり的な形で、開発を進めていたのですが、プロダクトも大きくなり、お客様も増えてきたので、チーム化を少しづつ進めています。

今日は、ほとんどのメンバーがフルリモートで働く開発チームのマネジメントの大変さと、それでもフルリモートの開発メンバーによるチームビルディングをこれからも続けていきたいという想いをブログに書いてみようと思いました。

場所と時間に決して依存しない。だけども、チームとして機能している。そういう組織を本気で作っていこうとしています。

(正直、完全にはなかなか難しいとは思っているのですが、可能な限りそうしたいと考えいています。)

ぶっちゃけフルリモートのメンバーをマネジメントするのは大変

顔が見えないんだから当たり前ですよね。。

ちょっと相談したい、少しお願いする仕事の内容の方向性が変わったというときでも、わざわざ文字に落としてSlackに流したり、その都度オンラインミーティングを設定するのは地味に時間的なコストがかかります。

もちろん、今一緒に働いている方々は、行間を読んで仕事をしてくださっているので、とても助かっているのですが、それでも文字を利用した非同期コミュニケーションには限界というものがあります。

人数が増えてきて、エンジニアの方々とのやり取りだけで僕の一日の仕事が終わってしまうような恐ろしいことも起こりました。

また、お願いする問題の背景にある想いや(ときには色々なゴタゴタ)、作業の優先度も伝わりにくいです。

また、別の問題として、エンジニアの評価するという観点でも、フルリモートはエンジニアが直接頑張っている姿を見ることができないわけですし、GitHub上でアウトプットと、Slack上でのコミュニケーションのみでの評価がメインになってしまうので、本当にシビアに評価することになっていると思います。

色々試したり検討してみたものの、本質的にコミュニケーションが楽にはなりませんでした。

例えば、最近良く聞くネットワーク越しにディスプレイ上でずっとオンラインで接続するという形もありかなと思ったのですが、それはそれで、働くタイミングの自由を奪っているので、そうしたくもないよなと思い、そういう手もとっていません。

働く時間と場所の自由を担保させながら、コミュニケーションコストを下げるのは、なかなか難しいなぁというのが、今までやってきた中での感覚でした。

開発メンバー全員がフルリモートという組織の形は限界かもなと思う瞬間も正直ありました。

経営メンバーや営業メンバーなどのいろんなステークホルダーからやりたいこと聞いて、データの設計や機能設計などを行い、エンジニアに作業をお願いするところが、どうしても属人的なり、かつ、コミュニケーションが多く発生するので、それを全部請け負っていたCTOの私に仕事が集中して、業務が回らなくなりそうに何度もなりました。

結局、このあたりのなんとも形容し難いスキルセットをもつ人をなんとか採用しようと考えたのですが、そもそもこの職種は何なのかはっきりせず、困っていました。 世の中ではディレクタとでも言うのでしょうか。ときにはデータの論理設計とかをすることを考えると、その名前も不適切な気がします。

転機

偶然に、そのなんとも形容し難いところをいい感じにできる元エンジニアの方にjoinいただき、エンジニアチーム内に小さなフルリモートチームを作ることができるようになりました。このようなフルリモートチームをいくつも作っていけば組織がまだまだスケールする可能性を感じていて、これからがとても楽しみです。

ただ、なんでも丸投げできるわけではないのは皆様のご想像の通りで、下記の2つの変数を注意深く調整する必要があります。

  • どれくらいの粒度の仕事か
  • どれくらいのペースで依頼するか

ここの調整がとても難しいなと思っていますが、現状は少しずつ仕事を移譲しつつ、進めているのが現状です。

当然この新しくJoin頂いた元エンジニアの方も、フルリモートです。(初回の面談以外に対面でお会いしたことがないですw)

どこまで大きなフルリモートのエンジニア組織を作れるかチャレンジしていきたい

リモートワークというと、なんだか自由で、いい感じに聞こえますが、仕事をする側/お願いする側どちらにも辛いポイントがたくさんあると思っています。 もちろん仕組みやツールによって、フルリモートの障壁がどんどん下がっているとは思いますが、コミュニケーションの効率性、情報の伝達の精度など、失うものはたくさんあります。

ときに、会社にフルタイムで出社していただけるメンバーを置いてしまいたい。という誘惑に引っ張られるのですが、 現状リモートワークや自由に働けるかけがえのないメリットをとっているのだから、リモートワークのデメリットは甘んじて受け入れています。

ちなみに出社してくださるなら、それはそれで超ウェルカムです!やりたいのは働く場所を自由にしたいので、会社に来たい気持ちを否定することはないですw

もちろん、1年後に全く別なことを言っている可能性は否定できないですが、可能な限り今の文化を残していきたいなと思っています。

我々の会社はCEO/CTOがともにエンジニアなのですが、我々も働く場所は自由であったほうが生産性が高いと実感もしているので、このまま会社が成長しても今のフルリモート文化はなくしたくないなと、個人的には思っています笑

(やはり自宅の開発環境ほど最高なものはない笑)

また、能力が高い人が、場所にとらわれず、ガンガンアウトプットでき、それをきちっと評価できる組織ってちょっと面白いよなと思っています。 僕の観察下だけの話なので、本当のところはわかりませんが、なんやかんやで、10人-20人のサイズ以上の開発チームで、ほとんどの開発メンバーがフルリモートな会社って聞いたことないよなと思っています。

ちなみに、今のAIトラベルでは、いろんな場所からメンバーにフルリモートで働いて頂いています。 日本の中では、京都や熊本、海外では、ドイツやバンクーバーなど様々です。そういったさまざまな場所で働いている方と時差を気にせず働けるのは、本当に不思議だなと日々思っています。

まだまだ、小さく弱い開発組織ですが、これからも色々試しながら、我々の文化に合ったプロフェッショナルチームの形を見つけていきたいと画策しています。

AIトラベルでは、場所にとらわれないチーム作りを手伝ってくださるディレクター、エンジニア、テスタを募集しています。

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

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

今回のお話

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 エンジニアを募集しています。興味のある方はこちらから!