さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。
- Twitter での定期的な採用告知
- 自分への Slack DM の禁止
- 自分への返信はスレッド禁止（好み問題）
- 可能な限り即決断する
- 自分だけでは決断できない場合はいつまでに判断する旨を伝える
- Slack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話する
- エンジニアの上下関係の削除
- プライベートに対しては口を出さない
- 相談されない限り提案はしない
- サーバエンジニアはクラウドインフラも担当する
- 外注に依存している部分を減らす
- 内製化する
- 負債返済を評価する
- 隔週で個別面談の導入
- 本業 50% / 負債返済 50%
- ビジネス仲良し
- エージェントに出す採用文言を 1 から書き直す
- メンテを必要とする作業はリハーサルを少なくとも１回は行う
- メンテを必要とする作業は必ず作業手順書を作る
- メンテを必要とする作業はリハまでは作業準備者、本番は作業担当者でそれぞれ別の人が担当する
- ドキュメント駆動開発
- ドキュメントレビューの重視
- コスト削減の重視
- 我慢や不便が発生するコスト削減の禁止
- 毎月のコストの共有
- 非技術者と積極的に雑談すること
- 採用の見える化
- タスクの見える化
- チームに共有していない作業の禁止
- チームミーティングの見える化
- 負債返済はサービスが続く限り終わらないという意識をもたせる
- 気になることがあったらすぐにマネージャーに相談する
- 不要な打ち合わせの禁止
- R&D チームの設立
- OSS やテックブログでのアピールは行わない
- 自動化の導入
- 負荷試験の推奨
- E2E 試験の導入
- 採用はカルチャーフィット重視
- 中長期的なプランも引く
- 優秀な外注をアドバイザーとして引っ張ってくる
- レビューはレビューイーに対してわかりやすくする
- 判断をするときはメンバーの意見を優先する
- レビューでコメントする際は相手に遠慮しない
- コードは会社の資産の意識を徹底させる
- 評価制度整備に向けたアドバイス
- 信頼できるエンジニアを副業としてお手伝いとして入ってもらう
ちまちま追記していきます。
気をつけている事
ビジネス視点で判断する
コストダウンやサービス継続性、組織としての強さなどを優先しています。それぞれのメンバーが育つことも重要ですが、とにかくサービスが優先です。
自分が部外者であることを周知する
お金で雇われている部外者であることをメンバーに常に意識させています。さらに自分が一番リスクを背負っていない事は何度も伝えています。
お金で雇われているからこそ、対価に見合う成果を出していく必要があるのであって、パッションなどで行動しているわけではないことを伝えてあります。
具体的な成果
実際の成果を書いていきます。
クラウドインフラの完全内製化
リソースが十分ではなく、クラウドインフラをその分野に強い企業におまかせしていましたが、リソースが増えたこともあり、無事社内で完結できるようになりました。
構築、運用、監視、ログすべてを外部の企業が構築していたものから別物へ変更していっています。コストを払って安定性を優先する！という方針で新規で構築し直していっています。より最適化を行っています。
新しい構成ではサーバの台数を減らしつつ、より使いやすくより安定性があり、解析もしやすい構成になっていっています。社内メンバーが積極的に改善に向けて手を動かすようになり、効率は社外にお願いしていたときよりも、とても良くなりました。これだけでも内製化してよかったです。
また、コストダウン気軽に検討できるようになったのも大きいです。毎月クラウドにかかっている費用をマネージャに全体で共有してもらうようにして、コスト意識を持ってもらっています。
とは言え、変に切り詰めるのではなく技術によってコストを削減するという方針を取っています。必要あればコストは払っていきます。
今まで外部の強い企業に頼り切っていましたが、独り立ちできたのは大変良い結果だと思います。実際、コストも大幅に削減できました。
Twitter 経由での採用
採用も担当していますが、ありがたいことに自分の Twitter のつぶやきをみて応募してきていただいた方が入社してくれました。
「時雨堂が入ってるなら変な技術を採用したりはしないだろうと思った」という話を偉い人たちとの面談でもしていただいたそうで、ありがたい限りです。
入社していただいた方と面談した際には「色々オープンすぎて、今までどうやって仕事していたか忘れるくらい楽しいです」という感想をいただきました。
大幅なコスト削減
外部の企業が行っていた無駄な仕組みをすべて排除しました。それらをより便利で効率の良い仕組みへと切り替えました。障害はなくなり、コストも大幅に下がり、運用も楽になりました。
継続してコスト削減を行い 1/3 程度まで減らしています。
Go への切り替え
C# からGo へ既存実装を置き換えていっています。これはお手伝いする際に経営メンバーから要望として頂いていたので積極的に置き換え始めています。すでに一部は Go に置き換え始めています。
E2E テスト導入
通常の Go のテストとは別に Python で書かれた E2E テストを CI で走らせています。単体と E2E があることで安心して開発が進められるようになりました。
カバレッジツールの導入
Go への切り替えに伴いカバレッジツールを導入しています。他の人が「足りてないテストを気軽にかける」という状況が作れるようになりました。
偉い人にもはっきり皆の前で意見を言う
これは自分がもともとそんなタイプなだけですが … 。サービス自体のトップ（つまりサービス責任者）でも言いたいことがある場合は、皆の前（Slack 公開チャネル)で意見を言うようにしてます。
偉い人とのやり取りは隠蔽されがちなので、避けています。
オープン議論
できるだけオープンな議論を心がけるようにしてもらっています。一人でコソコソやるとかではなく、自分はこうやろうとしているがどうか、というのを皆に共有していくという方針をとています。
議論の見える化と言うやつです。
サーバエンジニアはクラウドインフラも担当
インフラの設計、構築、改善をやってるとサーバ開発するときに良い影響が多いのと、より柔軟性を出すためです。
内製化をすすめる
アドバイスや検証は外注してもよいですが、構築や開発は可能な限り内製化しています。自分たちで作り上げているという感覚は重要です。
また任せっきりだと負債に気付けなくなるということもあります。
負債返済を評価する
負債返済はマイナスをゼロに近づけるので評価しづらいですが、負債返済を評価すると伝えました。負債返済が罰ゲームにならないようにしました。
ビジネス仲良し
仕事中はどんなに仲悪くても仲良くやってもらうことをお願いしました。
採用の見える化
面談相手に許可をもらい自分が採用時の面談する場合は他のメンバーが見えるようにしました。（配信しています）
チームミーティングの見える化
自分とメンバーがやっているミーティングを誰もが見れるようにしました。（配信しています）
隔週で個別ミーティングの導入
まずはお互い初対面ということで色々話をしたいということで、お願いしました。個別ミーティングはかならずマネージャーに見てもらうようにしました。（配信しています）
現時点ではもう行っていません。チームミーティングだけです。そもそも個別ミーティングは信頼作りの場であって、それ以上は不要だと思っています。
可能な限り即決断する
エンジニアからの「これこうしたいんですが」にたいして「いいね、やろう」でミーティング後すぐに行動できるようにしています。
負債返済の判断は早ければ早いほどいいと思っています。
採用はカルチャーフィット重視
技術者の採用の最初の面談を事業責任者、プロダクトオーナ、マネージャにお願いしました。技術的観点は一切見ず、人間的に合うかどうかを見てもらうようにしました。
今の所技術的な判断は自分と R&D チームのトップで見るようにしています。今後は現場のメンバーに見てもらうようにしていく予定です。
メンテを必要とする作業はリハまでは作業準備者、本番は作業担当者でそれぞれ別の人が担当する
メンテに向けてリハをやることで、漏れなどを確認していくのですがそこまでは準備担当者の仕事で、本番は別の人が準備担当者が準備した資料を見ながら作業をしていきます。準備担当者は本番は見守るだけです。
これ、準備がしっかりしていないとうまく行かない仕組みなので、とてもいいです。スピード感が失われるって思うかもしれませんが、メンテを必要とする作業で失敗したほうがはるかにスピード感が失われます。
急がば回れです。
本業 50% / 負債返済 50%
本業というのはサービスに対しての機能追加や改善です。負債返済はマイナスをゼロに近づける作業です。ただこの負債返済は継続的にやってこそ意味があるんですよね。なので、基本的には負債返済を積極的にやるようにと 50% のリソースは負債返済に割り当てるようにしています。
ただ、もちろん本業が忙しくなった場合は本業 100% になるときもあります。ただし、落ち着いたらかならず負債返済に戻れるようにしています。
R&D チームの設立
経営陣のやりたいことを実現する R&D チームを設立しました。クライアント、サーバ、インフラ、研究などなど何でも対応できるメンバーはここに放り込まれます。
毎月のコストの共有
クラウドインフラの費用を毎月どのくらい使っているか、なにか削減できるところはないかを検討するようにしています。
お金＝技術者は関係ないというわけではく、低いコストで最高のパフォーマンスを出していくのが重要と考えています。
OSS やテックブログでのアピールは現時点で行わない
技術がよくわかってない人ほどこれやりがちですが、実はこれって技術者の負担すごいんですよね。もちろん技術アピールは大事だとは思いますが、まずは本業に注力すべきと判断しました。
OSS の公開は思った以上に放置しがちになりやすいですし、テックブログは強制的に担当をつけると、どうでもいい記事が増えていきます。それよりは良いサービスを提供し続けるほうが良いと判断しました。
またテックブログって人に依存するのであまり良くないと思っています。
中長期的なプランも引く
お手伝いに入って直近 1 ヶ月、3 ヶ月、6 ヶ月、1 年という感じで 1 年後の負債返済プランまで引いて共有済みです。
開発者が長期的なイメージを持つのはとても大事だと考えています。
ちまちま追記していきます。
自社とお手伝い先は全く別です。興味がある人は時雨堂を支えるマネージメントをどうぞ。
