スタートアップ技術顧問は技術を見ない - メンテモエンジニアリング

こちらの記事は三部作です

その1：とあるスタートアップが最初のフルタイムエンジニア採用を決意するまで
番外編：スタートアップ技術顧問は技術を見ない <= 現在の記事
その2：とあるスタートアップが最初のフルタイムエンジニア採用のために準備したこと
その3：とあるスタートアップが Twitter Spaces からフルタイムエンジニアを採用した話
番外編：メンテモに転職した話

タイトルは嘘です。(必要なときに)見ます。最近は通知を送る方法*1について考えられる設計のパターンをいくつか例示した上で、今ならどれを選択しどんな感じで実装していったらいいかについて議論したりしました。

初めまして、@tagomorisです。今年の6月からメンテモで技術顧問をしています。技術的な専門としてはデータ処理基盤からWebサービス一般・ITインフラまでですが、メンテモの技術顧問では技術領域を特定せず、ありとあらゆる事についてソフトウェアエンジニアの観点から相談に乗る、という形で毎週1回、2時間ミーティングするのが基本の形です。他にも要望に応じて様々なことをやっています*2。

このエントリでは自分がメンテモにどう関わっているのか、普段何をしているのかをざっくりと紹介してみよう、それによってメンテモの紹介もいっしょにさせてもらおうと思います。

メンテモの技術顧問でやっていること

メンテモは若月さん(@Qrymy)という創業者が自分でコードを書いて経営をしている会社です。このため技術と技術者がかかわるあらゆることが一人に集中しています。

自分の役割は彼の疑問や相談をなんでも聞いて、そこに過去の経験や自分の知識から参考になる情報・選択肢を返すということです。そこには技術的な内容はもちろん、採用・評価・組織といった技術部門の非エンジニアリング領域の話も、あるいは必要があればエンジニアリングにあまり関係のない話までなんでも相談に乗っています。もちろん若月さん自身でなんでもできる人ですが、そこに他人の視点を加えて視界を広げるということがメインの役割かなと思っています。

メンテモの技術顧問で気をつけていること

それであれこれ相談に乗るときに、単に知識だけを返すということはあまり無く、もちろん自分なりの意見がある程度含まれることとなりますが、特にメンテモの文脈で会話をしているときは以下の3点に気をつけて話をするようにしています。

とにかくスピード

スタートアップ企業にとにかく大事なのはスピードだ、というのが自分の考えです。求められているものを実装するにも、求められていると思っていたものが実はそう重要ではなかったことを知るためにも、とにかくサービスの実装と改善のサイクルを早く回す必要があります。じっくり考える必要のある事柄ももちろんありますが、それでもほとんどの場合においてはスピードが最優先です。

これは単純に思えてなかなか徹底が難しい話で、うっかりすると「これを素早く実行するためには何をしたらいいか」を考えだして時間が経ってしまう、みたいなことにもなりかねません。またエンジニアリングをやっているとどうしても安全に・高信頼の・後々まで使えるようなものを作る方向に頭が動きがちなところがあります*3。

技術顧問を始めるときに若月さんと話をしていると性格的に慎重な方向に思考が向きがちなところを感じたので、自分はメンテモの文脈で話しているときは強く意識してスピード最優先の方向に思考を振っています。

維持に手をかけない

スタートアップ企業一般にどうしても人数が限られていて、やりたいことが何でもできるわけではない、ということがあります。ましてメンテモは現在はサービス開発にフルタイムで働けるのが一人だけという状況で、ひとつひとつの作業に費せる時間は長くありません。

こういう状況で作った何かの仕組みが、例えば維持するのに毎日ひと作業しないといけないということになると、これは致命的です。新しいことをやる余力がどんどん削られて、開発スピードも低下しますし、関わっている人間のメンタリティにもよくありません。

ということで、何かを考えるときには可能な限り、人手がかからない方向に倒すようにしています。また日常的に負荷がかかっている作業などはできるだけ早めに対処し、後々に楽ができるようにアドバイスをしたりもします。

今必要な回答以外にも色々な選択肢はある

基本的には上述のような方針で相談に乗るのですが、この方針だけで回答を返さないようにし、実際の会話の中では「今のメンテモには必要ないが、こういうケースやこういうやりかたもある」という話を可能な限り紹介するようにしています。これはもちろん時間がかかるし、今のメンテモへの即効性という意味では優先度が低いことかもしれませんが、絶対に必要だと思っています。

メンテモというサービスには長く続き、大きく発展してほしいと思っています。そうなれば創業者の若月さんは長く会社を率いることになり、今のメンテモとは全く異なるステージ・規模・人数・組織形態のチームとサービスを経験することになります。そうなったときに必要なのは今のメンテモとは全く異なる方法と思考になるでしょう。そのときに、今このときからの時間をかけた様々なインプットは絶対に必要となるでしょう。

もちろん短期的にも、問題に対して様々な選択肢をリストアップすること、その中からきちんと理由をつけてひとつを選ぶことを繰り返すことはエンジニアリング・ビジネスの両面で非常によい訓練になると思っています。

実際の話

ふわっとした話だけしてもなんなので、実際にあったやりとりをふたつ紹介して具体性を上げてみましょう。

実例1：「開発体制をどうすればいいか?」

技術顧問をはじめて初日に相談されたのがこれでした。まだほとんど人数もいないので体制も何もないのでは、ともちろん思ったのですが、確認してみるとチームをどう作ったらいいのか聞きたいという話です。

が、それは何のために? という質問を何度か繰り返すと見えてきた問題は、実際には開発体制の問題ではありませんでした。開発フローの中で手詰まりや他の人の作業・確認待ちが発生することが多かったり、あるいは開発時にブランチが大きくなりすぎてレビューやリリース前の確認作業に手間がかかりすぎたりといったことが日常的に発生していて、これを解決するためには開発体制をどうにかしなければと考えていた、というのが実情でした。

これは実際には開発体制ではなく開発タスクの粒度コントロールやリリースのサイズ、デプロイタイミングなどの問題だと思われました。開発時のタスク粒度が大きすぎるのがブランチの肥大化を、開発用のメインブランチとリリース用のブランチの乖離も大きくなっておりリリースの低頻度化を招いていたという状況です。

自分からのアドバイスは要約すると、とにかく今の体制で可能な限りスピードを上げるべきで、そのためにはまずpull-requestのサイズを小さくしてレビュー負荷を下げると同時にマージまでの時間を可能な限り短縮すること、同時に開発用メインブランチとリリースブランチの差分をほぼゼロにするところから始めるようアドバイスしました。こうすることでサービスに対する要望が出てから改善がリリースできるまでのリードタイムをできるだけ短縮し、それによってサービス改善のサイクルを高速に回すことができるようになります。バグやミスを含んだリリースによるサービスへの影響が心配なところですが、そもそもユーザー数が非常に少ない現段階ではサービス改善速度向上による利益のほうがはるかに大きいはずです。

またこの方向性を長期にわたって手間少なく維持するための手段として、デプロイ頻度を可視化するというアドバイスもしました。デプロイが実行された回数をGitHubのAPIから取得するなどして、それを週に一度Slackにポストする、という簡単な仕組みです。これだけで毎週どういうペースで開発が進められているかが手間をかけずに把握できます。

なおこのとき、いわゆるKPIを設定するのはどうかと質問されました。例えば「週に5回以上デプロイすること」などといったことです。これには自分は強く反対しました。デプロイ頻度は有効な指標にはなりますが、これを目的にしてしまうと簡単にモラルハザードが起きます。大きな機能追加や障害対応、あるいはビジネス上の理由でデプロイ回数が少なくなることは普通で、こういったときに有害なKPIが存在すると、デプロイ回数をクリアするためだけに雑な実装の、あるいは必要な確認を怠ったデプロイが実行されかねません。このようなことも考える必要があるので、KPIの設定にはいくら慎重になってもよいと言えるでしょう。

こののち上記の提案を実施した結果、今ではリリースブランチの乖離もなく、最近ではデプロイ/リリース頻度も目に見えて向上してきました。

実例2：「ドキュメントはどう整備すればいい?」

もうひとつの実例はドキュメント整備についてで、これはチームの拡大を考えはじめた比較的最近の話です。メンテモはスタートアップの(おそらく)ほとんどのケースと同じく、サービス開発に関するドキュメントが非常に弱い状態です。これはサービス開発に関わっているのがオリジナルの開発者を含め数人という状況ではごく当然で、むしろ不要なドキュメント整備のコストを払っていないという意味では正しいとすら言えます。

とはいえ、新しく人が増える見込みがあるのにドキュメント皆無という状況は理想的ではありません。入ってくる人にある程度の調査能力・自己解決能力を求めるにしても、そのとっかかりがどこかにまとめて書かれているだけで必要な時間は大幅に短縮できます。また知っていないと調べようがない情報などもあります。

このケースでは、まずほとんど空白だったメンテモのGitリポジトリにREADMEとしてある程度の情報をまとめておくようアドバイスし、具体的な項目のリストも作りました。Gitリポジトリは開発に関係する人なら誰もが見るもので、かつ非エンジニアリング部門の人はほとんど見ないため予備知識がある人のことだけを想定して書くことができます。コードとも近いので、必要に応じて実装をチェックしながら参照もできます。現在のメンテモのメインリポジトリのREADMEには以下のような内容が、各項目についてごく短く書かれています*4。

実行環境・デプロイ
- 実行環境
- データ保存
- デプロイ
インフラ
- 開発環境
- モニタリング・運用
- レポートページ
- モニタリング
- 障害報告
- メトリクス
- ログ
- 障害対応
開発関連
- 手元の環境
- サービス実行手順
- タスクの確認方法
- Pull Request の検索方法

これでも足りない部分はあるでしょうが、現状では整備に時間をかけすぎない(サービス開発に時間を使う)という方針です。

またこの時のアドバイスのもうひとつの内容として「新しく入った人に、タスクのひとつとして、ドキュメントの追加をしてもらうよう運用する」ということがあります。当然ですが開発に参加した人には知らないことが数多くあります。あれこれ調べたり人に聞いたりすることでしょう。このときドキュメントに欠けている部分については新人にドキュメントを更新してもらい、質問を受けた人が更新されたドキュメントを確認するようにします。

これはドキュメントに足りない部分が最もよく分かるのは新しい人だということ、質問に回答した内容が新しい人に正しく伝わっているかの確認にもなるということから、いろんな場所で有用なアイデアだと思います*5。