microCMSの新機能開発からエンジニアの開発者体験向上まで。開発本部ってどんな組織？
人事担当の中谷祐介が、社内のさまざまなチームとそこで働くメンバーにスポットを当て、それぞれの役割や働き方について詳しくご紹介するこのシリーズ。
第2回目は、開発本部を統括するCTOの大西智也さんにお話をうかがいました。
開発本部は、言うまでもなくmicroCMSのプロダクト開発の根幹というべき部署。新機能開発だけでなく、エンジニアチームが安心してリリースできる環境整備にも取り組んでいます。
前編では、大西さんの入社経緯から、現在の開発本部の組織やメンバー、そして現状の課題に対して取り組んでいることについて聞きました。ぜひご一読ください！
先輩から声をかけられ、ヤフーから転職
――まず、大西さんがmicroCMSに入社した経緯を教えてください。
大西：
ヤフーで10年ほどエンジニアとして働いた頃、周りが転職していって、うっすら僕もそろそろ転職してもいいかなと考えていたんですよね。ちょうどそのタイミングで、先輩だった平松さん（平松亮介（現microCMSプロダクトマネージャー））に声をかけてもらったんです。「転職すると新たな人間関係を築くのが大変かも」という不安があったんですけど、「知っている先輩がいるなら安心だな」って思いましたね。
microCMS自体はもともと知っていて便利なサービスだと思っていましたし、自分の持っている力をフル活用できそうな環境があるのも決め手になりました。
――現在は、CTOという立場ですが、前職ではどういった役割を担っていましたか。
大西：
前職ではリードエンジニアとしてプロジェクトのマネジメントのタスクやスケジュール管理などはやっていましたが、役職には就いていなかったですね。
僕がmicroCMSに入社した頃は全社員で10人に満たず、エンジニアも3、4人ほどで、まだ創業者がエンジニアをマネジメントしつつ代表の仕事もしていたんです。なので、入社して1か月くらいでマネジメント領域を僕が引き継ぎ、現在に至ります。
開発本部にはエンジニア未経験者も在籍!?
――開発本部の現在のチーム構成を教えてください。
大西：
現在エンジニアが10人ほど在籍しており、大きく分けて以下の2つのチームに分かれています。
- ストリームアラインドチーム：機能を開発するチーム
- プラットフォームチーム：技術負債の返済や開発者体験等の向上やストリームアラインドへの技術的なサポートを行うチーム。特徴を考慮してフロントエンド領域とバックエンド領域に分割
フロントエンド領域
フロントエンドに関する、ストリームアラインドチームへの技術的なサポートや技術課題の解決、コードベースの管理、開発者体験の向上を行うチーム
バックエンド領域
バックエンドに関する、ストリームアラインドチームへの技術的なサポートや技術課題の解決、コードベースの管理、SREやオブザーバビリティ、開発者体験の向上を行なうチーム
僕はCTOとして開発本部全体の組織横断的なタスクを遂行しつつ、プラットフォームチームのバックエンド領域をリードしています。
――現在、在籍しているメンバーはどのような経歴やスキルを持つ人が多いでしょうか。
大西：
microCMSはフロントエンドと相性が良いサービスなので、フロントエンド領域に強みを持っているエンジニアが多いですね。シニアエンジニアもいますし、5年ぐらいの中堅どころもいます。なかには、元高校教師や、前職で不動産の営業をやっていたという、エンジニア未経験者もいますね。ホテルの住み込みのバイトで働きつつ、夜、プログラミングの勉強をしてジョブチェンジをしたという話も聞いています。いろんなバックグラウンドのエンジニアがいてみなさん得意な領域で頑張ってくれています。
品質を担保しつつ、安心してリリースするために自動化を推進中
――microCMSの開発スタイルを教えてください。
大西：
ウォーターフォールとアジャイルの良いとこ取りですね。基本的にPMがカスタマーサクセスチーム等から顧客のフィードバックを集め、それを元に新機能を考えます。PMが中心となって進めますが、エンジニアや社内からのフィードバックも受けながら仕様を考えていく文化もしっかりとあります。ある程度固まったらエンジニアにアサインされて開発、QA、リリースというスタイルでやっています。
ウォーターフォール的なスタイルはよくないと言われがちですが、それは手戻りができない文化がよくないのであって、microCMSにはそのような文化はありません。作っていくうちに微妙だなと思ったらPMと相談して調整したり、それで間に合わなければリリースを延期したりすることもあります。
大事なのはユーザーに便利なものを届けることなので、「決まっているから変えられない」ということはありませんし、より便利なものを作っていこうという共通意識があるので全く問題ないですね。
――開発業務を進める中で一部自動化を進めているそうですね。
大西：
創業者2人がエンジニアということもあり、全社的に自動化や仕組み化していく文化があります。開発ではリリースの自動化、品質担保のためのE2Eテストや外形監視などのテストの自動化、コードレビューの自動化などさまざまな自動化を進めています。
E2Eテストの部分を深掘りして話すと、一般的に、E2Eテストのテストケースはエンジニアが考えると思いますが、我々の場合は少し異なった取り組みをしています。個々のエンジニアではなく、Qaseというテストケース管理サービスを使って元エンジニアであるPMと自分が一緒にテストケースを管理しているのです。microCMSというサービスはどういう仕様を持つサービスなのか（例えば、公開ボタンを押すとコンテンツが公開される、公開権限を持っていないユーザーは公開ボタンが押せないなど）を体系的に記述して管理しているイメージを持っていただくといいかと思います。
あと、弊社では月に2日間、エンジニアがテスト自動化にフルコミットする時間として「Test Automation Days」を設けています。Qaseでは自動化されているテストケース、そうでないテストケースが一目でわかる仕組みになっているため、その時間を使って、自動化されていないテストケースを自動化していくという流れになっています。
こうしたスタイルを取っているのはE2Eテストの効率的な実装、仕様を体系的に管理するためです。ただ、例えば新しい人が入社した時に、テストケース通りにプロダクトを触ってもらい一通りの理解をしてもらいやすかったり、AIにmicroCMSというサービスを理解させやすかったりといった副次的な効果も期待しています。
また、こういった仕様の管理をエンジニアに押し付けない文化を大事にしていきたいと思っています。あくまで仕様が先にあってコードが生まれるので“コードが仕様です状態”に陥らないようにしたいんです。仕様についてエンジニアに調査依頼をしていてはスピード感も落ちますし、何よりエンジニアが疲弊してしまいます。粒度やエッジケースまで管理するのかなど議論ポイントは多々ありますが、しっかり運用していくと、メリットが多そうなので、この取り組みは継続していく予定です。
――また、現在Go移植を進めているということですが、どういった理由があるのでしょうか。
大西：
今までNode.jsでバックエンドの処理を書いていました。でも、Node.jsって型がなくて、型がないがゆえに、不具合が発生することが問題視されるようになってきたんですよね。チーム開発するにはやっぱり型がないと厳しい。じゃあ言語を変えようという話になりました。
Node.jsから型を求める場合、普通はTypeScriptにするのが一般的だと思いますが、TypeScriptは弱い静的型付けでランタイムには型がありませんし、型が欲しいのであれば、強い静的型づけの言語である言語かなということをチームで話してGo言語を採用することになりました。
Go以外にも条件に対応する言語はいくつかありますが、トレンドであることと、文法が簡単で学習コストが低いこと、誰が書いても同じような書き方になることがポイントでした。Goならパフォーマンスもいいし、文法もシンプルだし、我々が最も欲しい型もちゃんとある。ライブラリーなどのエコシステムも整っていますしね。
――現状でもある程度うまく組織が機能しているように思うのですが、その中でも大西さんが課題だと感じていることはどんなことでしょうか。
大西：
バックエンドやインフラに課題を感じています。ヘッドレスCMSはWebフロントエンドと相性がいいというサービスの特性上、どうしてもフロントエンドに比べてバックエンドやインフラに詳しい人が少ないんですよね……。なので、バックエンドやインフラがメインの新機能の提供がどうしても遅くなってしまっていますし、既存のシステムの改良にも時間がかかっているのが現状です。
そこを改善するためにバックエンドやインフラに強いエンジニアを採用したいと考えています。
前編は以上です！
前編では、大西さんの入社理由とmicroCMSの開発スタイルについてお話をうかがいましたが、後編はmicroCMSのコミュニケーションと今後採用したい人材について話していただきました。後編もおたのしみに！
カジュアル面談について
microCMSに興味を持っていただいた方向けにカジュアル面談を実施しています。以下のリンクよりお申込みください。