Engineerの体制 ・ 運営方針
カイテクのエンジニア責任者の岩本です 。
カイテクでは高速にリリースすることができています。実測してみたところ、2024年5月の機能のリリース回数は37回でした。当時は短時間勤務の業務委託の方たちがメインでフルタイム換算すると3.5人月程度でした。
（なお私は別の新規システム開発のため未カウント）
お客様から不具合を報告された際にも、場合によっては当日中に修正完了の連絡をすることができています。利用者様からはカイテクは改善が早いと声をいただくことも良くあります。下記はその抜粋です。
「見ましたよ！あの機能いいですね！とても便利です」
「カイテクさんは、いつも本当にすぐに新しい便利な機能を増やしていてすごいですよね」
それなりに高パフォーマンスだと自負していますが、次のような体制・運営方針ですすめています。
カイテクでは仕様調整・設計・実装・テストができる自走可能なエンジニアのみでチームを構成しています。そのうえでうまく開発を進めるための仕組みを作っています。
フルスタックエンジニアのみで構成
エンジニアを自走が可能なフルスタックエンジニアのみで構成しています。フロント・バックエンド・インフラ含め全て一人で対応できるため、一つのチケットを一人で担当することができ、やりたいことベースでチケットを切ることができるようになり、チケット毎に関心事を分離できます。チケット間の依存が少なくなるため、スケジュール調整などもほぼ不要になり、さらに事前にAPIの形をFIXする必要は無いですし、開発中にWebAPIの形式を変えようと思っても一人で変更を完結することができます。フットワークが軽くなる分、より良いものができあがりますし開発スピードも上がります。
問題は自走が可能なフルスタックエンジニアの採用が難しい点です。この点はまさに問題ですが、少しずつチームは拡大できています。
ドキュメントを極力書かない
最新の仕様を整理し続けるようなドキュメンテーションは行いません。毎日何回もリリースする環境だと、ドキュメントのメンテナンスコストが大きくなりすぎるためです。もちろん、チケットにどのような開発をするかは書きますし、分かりづらい箇所を整理したドキュメントは残します。代わりに、ソースコードをドキュメントとしています。
そのためには、ソースコードを見れば処理内容を簡単に理解できる必要があるため、コードレビューを大事にしています。たとえ正しく動いても分かりづらいコードはレビューで指摘し、修正したりコメントで補足したりすることで、可読性を高い状態に維持しています。ソースコードを正とすることで、コードとドキュメントが乖離することもありません。過去にこの方針で10年近く開発を行ってきましたが、うまく回っていた経験から問題ないと判断しています。
チケットに納期を設けない
チケット単位でエンジニアが独立して開発しているため、スケジュールを引くことにあまり意味がありません。そのため、エンジニアを信頼してベストエフォートで開発を進める体制を取っています。
一方で投資家やお客様に期限を約束をするような類のものはスケジュールを引くことはありますが、本当に必要なものだけなので、10件に1件もありません。
チケット単位でリリースする
チケット単位でリリースを行うことで下記の２つのメリットがあります。
トラブル発生時に原因の特定および影響範囲が明確
他のEngと調整が不要になるので、コミュニケーションコストを無くせる
一方でリリース毎に社内への連絡をしたり、CIを回したりする時間はかかりますが、上記で得られるメリットに比べれば圧倒的に小さいデメリットと考えています。
エラー監視・テクサポはEng全員で行う
エラーが発生するとSlackに通知が来るようになっています。基本的に勤務中の方は常にSlackを監視していて、エラーが発生した場合にはすぐに対応します。大抵のエラーは直近リリースしたものの不具合であることが多いので、原因となったリリースをした方に対応してもらうことが多いです。ここでチケット単位でリリースしているメリットが活かされます。
一方で、直近のリリースに関係のないエラー通知やテクサポの場合は、見た人が調査・対応を開始します。自分の開発がその分遅れてしまいますが、チケットに対して納期を切っていないので、リスケを行う必要もありません。
非同期で活躍できる環境を作る
カイテクではフルタイムではない勤務の方が人数が多く、過去には地球の裏側から勤務してくれていた方などもいて、勤務時間帯が大きく異なります。そのため非同期で開発ができる体制を整えています。
懇親と相談を目的に定例会を週3回行っています。だいたい30分~60分ですが、業務委託の方たちは参加は必須ではなく、参加可能なタイミングで出てもらうようにしています。月曜日は夕方、水曜日は昼、金曜日は朝というタイミングで開催しています。このいずれかの時間帯に出てもらうことで、相談がするタイミングを設けています。
QAはおらず、各Engがテストを行っていますが、テストが足りているかどうかもソースコードレビューの対象としています。ソースコードレビューはかなり厚めに行っていて、2名からのapproveをもらう必要があります。
また、リリース前に開発物の動画を撮ってPdMにSlackで共有し、外部仕様に問題がないことを確認してもらい、問題なければリリースOKとしています。
まとめ
これらは自走が可能なフルスタックエンジニアだけで構成したチームが必要に応じて作ってきた仕組みです。したがって記載した内容が全てのチームに当てはまるわけではないと考えていますが、現在の我々のチームではこのやり方がベストだと信じています。
今後組織が拡大していく中で体制や進め方を再考する必要が出る可能性はありますが、できるだけ現在の考え方で進めたいと考えています。
ここで紹介したような働き方をしたいメンバーを募集しています。興味を持っていただける方がいれば是非下記のページから応募をお願い致します。