CTO、コード書くのやめるってよ
エンジニアの波多野(@hatamasa1988)です。
Qastというナレッジ経営クラウドを開発・運用しているany株式会社に入社してCTOやってます。
まず初めに、、、、
Qastリブランディング!!!
プロダクトのあり方、サービスのあり方を一新しました。
それと同時にCTOの立ち位置や身の振りを考えた末、出した結論をまとめたいと思います。
最近コードを書かないようにしました
理由は
「エンプラシフトへ向けてプロダクト品質を向上させる」
ためです。
また、その背景には
・大手顧客の利用拡大
・障害対応のコスト増と品質の重要性
・開発マネジメントのボトルネック化
があります。
いつかはコードを書かなくなると思ってましたが、思ったよりも早かったなという印象で、非常に寂しく思います・・・。
そこにおける自分の気分をツイートしていました。
大手顧客の利用拡大
Qastは早期から数千名で利用する大手のお客様を獲得できているため、このステージのSaaS系スタートアップではレアなことは間違い無いです。
SaaSは継続的なビジネスモデルなので、大手のお客様のチャーンはかなり痛手です。近頃話題になったOCRの会社のような状況になりかねません。。。(極端な例ではありますが)
もちろんエンプラシフトに向けて様々なヒントを得ることができるのですが、早期のスタートアップは大手顧客が獲得できた瞬間からリソースを集中する運命にあります。
また、大手顧客に対しては品質と対応も大手並みのものが必要になります。MVPで開発→バグったら直す。を繰り返しているスタートアップからしたら180°方向転換です。
今まではCTOとして開発も行っていましたが、開発に時間を割くことをやめて、大手顧客へのアンテナを巡らせる時間を創出することを始めようと思います。
障害対応のコスト増と品質の重要性
Qastを契約していただき、利用していただくお客様が増えたことで、お客様とのコミュニケーションも拡大しました。
営業やカスタマーサクセスチームは日々、お客様と商談や利活用に向けたディスカッションを繰り返しています。
そんな中でのメンテナンスや障害発生時は、お客様への報告コストも以前からは比べ物にならないくらい一気に膨らんでしまいます。
社内に誠意を持って対応する文化が浸透しているので良いことなのですが、障害事態はいただけません。。。
何より、プロダクトを気に入って使っていただいている既存のお客様に申し訳ないです。もっと不自由なくQastを使ってもらいたいという想いです。
そんな中でQAエンジニアを採用したり、外注するという話もあったのですが、今あるリソースで対応する選択をしました。
CTOがQA担当するような形になり、デリバリー前のテストケースの拡充と実施やバグ管理(時には修正)も行い、プロダクトの品質を担保するように役割を設計し直しました。
開発マネジメントのボトルネック化
結構前から感じてたことです。
マネジメント経験の方が長い自分的には開発はなるべくやらないマネジメントを意識していましたが、猫の手でも借りたいスタートアップはそうもいかないので、プレイングマネージャーとしてやってました。
最近は嬉しいことに開発スピードが格段に上り、レビューとデリバリー前の確認が追いつかなくなってきました。
6人までチームが拡大し、少し怠けるとレビューが終わらないくらい溜まります。マネジメント(開発と保守の両面)をやりながら自分も開発することは難しい量になってきています。
メンバが開発に専念し、CTOがマネジメント、デリバリーに専念するように明確にマネジメント職として切り離しました。
その他やめたこと
■コーディングに細かい口出しをする事をやめました
PRレビューは
・一般的な実装とかけ離れてなければOK。
・負債を増やさない設計であればOK。
・障害に繋がらなければOK。
くらいのレビューにしています。
実装を見すぎると時間が溶けるのと、メンバー間でコーディングは担保しあって欲しいという権限委譲のメッセージでもあります(気付いていないかもしれませんが・・・笑)
■当事者になる事をやめました
プロダクト品質を上げるためには第三者目線で俯瞰的に見る必要があるのが自論です。逼迫した時間の中で当事者(開発者)になってしまった瞬間に第三者目線は弱くなってしまうので、自分で手を動かすことは最小限に抑えています。
いろいろどうなったか
自分がやってた事を羅列しますが、今やっている事は下記のようになります。太字は注力し始めているところ。
開発を持たないだけで、以前よりもかなり余裕ができたと思います。
・顧客商談同席
・新規顧客導入の調整等
・開発ロードマップの選定
・開発の進捗管理
・機能仕様、設計
・機能、PRレビュー
・リリース前テスト
・デプロイ
・インフラ構築、運用保守
・チームマネジメント
・採用
総合的な負荷は減り、バグ、障害も格段に少なくなったイメージです。
しかし、自分がマネジメントに振り切ったことで、コードや技術の深い部分を責任を持ちながら広く浅くマネジメントしてくれる人がいなくなってしまいました。
おそらくテックリード的に「技術選定」「機能仕様、設計」を引っ張ってくれる人が必要です。
今後も新しい機能開発が続々に控えていたり、新しい技術を使って価値を創出していかないとなりません。
我こそは!と思う方はご応募お待ちしおります!
TwitterDMでも何でもOKです。メッセージください。
最後に
時が経つのは早いもので、anyに入社してから1年と少しが経ちました。
事業の立ち上げ期に1人目の社員として入社して、取締役CTOになり。
非常に貴重な経験をしております。
最近ではライバーデビューもしました。
視聴者は少なかったらしいですがww
最終的にコードを書かなくなるエンジニア生活は寂しいですが、チームにおいて役割分担は肝心です。
コードは書きたければプライベートで書けるので、開発はメンバに大部分を任せます。
個人の目標としては
「エンプラシフトへ向けてプロダクト品質を向上させる」
ことをやっていこうと思います!!
ただ、守りのみに徹するわけでは無いです。
攻撃こそ最大の防御。スタートアップのCTOとして事業加速に向けてフルスロットルでいきます。
「ナレッジ経営クラウドQast」を作っているany株式会社で取締役CTOやってます。 会社の成長過程やCTO目線のいろんな投稿を続けようと思います!誰かの役に立てればと思いますので、良かったらフォローお願いします!