スタメン開発チーム 2020年の振り返りと来年の展望

スタメンの松谷(@uuushiro)です。2020年3月末にスタメンのCTOに就任し、約9ヶ月ほどが経ちました。色々と変化の大きかったスタメン開発チームの2020年を、私の目線で振り返ります。そして期待も込めて来年の展望を共有したいと思います!

どんな2020年だったか

事業について

TUNAG

まず、創業事業である TUNAG はリリースして今年で4年目でした。TUNAG は、2017年~2019年までは、「エンゲージメント経営プラットフォーム」として必要な一連の機能を揃えてきました。プロダクトの機能がカバーできる範囲を増やすことに注力してきたこともあり、その一つひとつの機能に関しては、価値提供ができる最小限のものでした。

2020年は、これまで揃えてきた主要な機能の価値・体験を引き上げるような改善や、新機能の追加においてもリリース時点のプロダクトの作り込みレベルを上げることができるようになってきたことで、開発組織として提供できる機能価値が大きくなってきたと感じています(もちろん改善余地は沢山です)。特に、フロントエンドエンジニア・ネイティブアプリエンジニアは、スキルアップと組織化により TUNAG のユーザー体験を向上させることに非常に大きな貢献をしてくれました。

また、TUNAG のメイン機能である、自社に合わせた社内制度を運用できる機能だけでなく、チャット機能やワークフロー機能といった通常業務を行う上で必須のツールを多くのユーザー様に使っていただくようになった年でもあったので、TUNAG へのアクセス数も負荷の特性も変化してきました。開発チームとしてもユーザー様の業務を止めてしまうことがないように、不具合が無いか、ストレスのない応答速度かなど「当たり前品質」を追求する意識が大きく高まっていきました。そして、エンタープライズ企業様の導入において、これまで経験したことのない規模のユーザー数の利用シーンを想定した負荷対策、及びセキュリティ対応を実施し、今後 TUNAG の導入を検討していただける企業様の幅も大きく広がりました。これらのシステムの信頼性向上の取り組みには、インフラチームがプロダクト開発全体をリードしてくれました。

一方で、プロダクトの作り込みレベルの向上と比例して、機能の複雑度も上がってきました。リリース当初は想像もしていなかったようなプロダクトの進化が何度も発生したので、その変化になんとか合わせてきた分の負債が無視できなくなってきています。その結果、アプリケーションコードが複雑になり、それが結果として不具合やサーバー負荷につながることが予測しづらいということも多々ありました。こちらについては、来年時間を確保し、リファクタリング及び、自動テストの拡充を進めていく予定です。

また、TUNAG事業において TERAS という組織診断ツールの提供を開始し、TUNAG と別のシステムとして0から構築しました。TUNAG本体とはアーキテクチャが異なり、SPA(React)とAPIサーバ(Rails)で作られ、サーバーもコンテナを利用したり、デプロイも Blue Green Deployment を利用したりなど、スタメンの近い将来の技術スタックの検証も兼ねて構築しました(TERASのアーキテクチャ)。ここで得られた知見の一部を来年TUNAG本体に適用することで、システムの安定性・開発・運用効率向上などを獲得していきたいと考えています。

FANTS

そして今年は新規事業 FANTS をスタートしました。必要な機能が TUNAG と近いので、ソースコードの転用ができた箇所は多かったのですが、ライブ配信機能、課金機能、サロン管理機能、集客機能などオンラインファンコミュニティサービス固有の機能開発を多く行いました。特に課金機能に関しては、システムがお金を扱う初めての事例だったこともあり(クレカ情報は保持していません)、今までにない緊張感の中で開発になりました。二重決済や誤課金、そして決済プラットフォーム側とFANTS側でデータの不整合が発生しないような仕組みをしっかりと時間を掛けて(冷や汗をかきながら)構築した甲斐があったと思っています。責任重大な仕事だったと思いますが、FANTSチームが責任持ってやりきってくれたおかげで、今は FANTS の事業理念達成に向けた多くの機能をスピーディにリリース出来ています。

その他取り組みについて

2020年の、プロダクトロードマップ以外の取り組みについて、特に印象に残っている4つを紹介します。

アラート管理改善

アプリケーションのアラート通知の整理をしました。整理する前は、一日あたりの通知数が多いため、通知に対する集中力が削がれ重要なアラートを見逃しやすくなっていました。その結果、不具合・障害対応の初動の遅れや漏れが発生してしまう可能性が高くなっていました。この問題を私たちは「オオカミ少年アラート」と呼び、問題解決のために「システム思考」のフレームワークを活用しました(システム思考でアラート運用に関する問題を考える)。これにより、アラートの責任範囲及びアクションが明確化し、新しいメンバーも迷わずに監視をすることができるようになったと思います。そして、半年経った今も新しいエラーに対して反応が早くなったと実感しています。ただ最近は、たまにあの「少年」が遊びにきている気がしないでもないので、また問題になる前に継続的に見直していきたいと思います。

開発環境改善

TUNAG の開発環境において、Railsのアセットコンパイルが遅い問題があったのですが、JavascriptなどのAssetの配信の仕組みを、RailsとWebpackで分離させたことで、sprocketsの無駄なコンパイルを排除し、待ち時間を大きく減らすことができました。またフロントエンド開発において、Webpackが提供するHot Module Replacement (HMR)についても適用することができるようになり、今後開発者体験も向上していきそうです。来年以降、フロントエンド開発はますます加速していくのでこの改善は非常にありがたいです。 一方で課題に感じるのは、ずっと同じ環境で開発していると緩やかに遅くなっていく開発環境に対して鈍感になってしまうということ。そして、RailsとWebpackが依存し合っている仕組みだと、両方の技術を理解していないと問題提起しにくいという難しさも感じました。しかし「開発環境が遅い」という事象に対しては、誰でも多少ストレスを感じるはずです。そこに慣れるのではなくプログラマーの三大美徳の一つ、「短気」なマインドを持ち、目の前の開発環境の怠慢さに怒りを感じ、問題を提起し、解決に導くことは非常に重要です。そういったエンジニアがどれだけ組織にいるか?という指標は中長期的にプロダクト部としてのアウトプット量を大きく左右します。大きなことを成し遂げる上で、斧を研ぐことがどれだけ大事なのか。開発環境を1%でも良くすることが、今後人数が増えていく開発組織においてどれだけ大事なのか。ということをチームカルチャーとして浸透させていき、来年はエンジニア全員が「短気」になっていければと思います。

APIドキュメンテーション標準化

APIドキュメンテーション標準化がされる以前は、APIドキュメントは社内wikiに蓄積されていましたが、機能が増えてきたことによってドキュメントの数も増えて管理が難しくなったり、 フォーマットが明確でないので書く人によってばらつきがあるという問題がありました。そこでAPIを提供する側・使う側の両方の立場のエンジニアが協力して、ツールの選定、運用方法の確立及び浸透を推進してくれました。既存資産であるRSpecというテストフレームワークをそのまま活かすことで実装者にほぼ負担のない形で導入でき、Swagger UIをホスティングすることで簡単にドキュメントにアクセスできようにしてくれました。そして、運用する中で出てきた課題も適宜解決してくれました。

このプロジェクトは、技術領域やチームを横断する良い例だったと思います。ドキュメントのズレをいちいち手動で修正するのがめんどくさいと、プログラマーの三大美徳の一つ「怠惰」なマインドで課題に向き合ってくれたおかげだと思います。このような、技術領域やチーム領域の間を埋めるエンジニア、越境するエンジニアといった存在は事業を推進する上で非常に重要になってくるので、今後も働きかけをフォローしていきたいと思います。

失敗から学ぶ取り組み

スタメンのプロダクト部には「失敗に向き合う」というバリューが定められています。2020年も不具合や障害など失敗をしてきましたが、今年を振り返ると組織全体で失敗に向き合う姿勢のレベルが一段上がったなと感じています。ただ失敗を反省するだけでなく、個々人の原因追求・再発防止・未然防止の質が高まり、同じ失敗をしないよう改善できるようになってきていると感じています。障害振り返り会での議論も活発になってきて、本音でオープンに原因を追求し、組織全体が失敗から学ぶカルチャーが浸透してきているなと感じています。

2021年にやること

私個人として、組織全体として2021年を実行したいことは2点です。

  • 技術戦略を描き実行する
  • 全体最適・基準決めに注力していく

技術戦略を描き実行する

2020年を振り返ると、事業の要求に応えながら多くの開発でプロダクトの成長を支え、進化させてくることができました。 一方で私自身、開発組織における「技術戦略」について言語化・発信が足りなかったなという反省があります。「技術戦略」というものは、事業上の要望に120%応えつつ、プロダクトの品質、改善スピード、低コスト実現、採用力、育成力...など事業戦略を加速させる強みとして、開発組織・アーキテクチャ・カルチャーをどの時間軸で達成したいのか、そのために限られたリソースをどう配分したらよいのか、ということを示したものだと考えていますが、それに取り組む動きが弱かったと感じています。「やるべきリスト」は常に目の前にありますがこれは戦略ではないです。事業を牽引するスタメンならではの「技術戦略」の描き筋があるはずで、今後はより具体的に考え、言語化し、発信していきます。そこで必要になってくることは、目に見える課題だけではなく、まだ目に見えないより重要な課題を発見しアプローチすることです。何かをやったことのコストとリターンは見えますが、「見えていない」「やっていない」ことによる機会損失はそれ以上に重く捉えるべきと思っています。見逃しているチャンスが無いように今一度システム・組織・未来の事業の姿を考えて、引き続きプロダクト部のビジョンである「プロダクトで事業を牽引する」の実現を追求していきます。

全体最適・基準決めに注力していく

2020年は、バックエンド領域に関しては私も中心となって技術的な意思決定をしてきましたが、その他フロントエンドやネイティブアプリ領域に関しては、技術選定やその実行タイミングは各技術領域のチームごとに意思決定をお任せしてきました。2021年も同じく、信頼してお願いしていきたい一方で、意思決定のフォローや全体最適となるようにバランスをとることはCTOとしての重要な責任です。今後、人・チーム・事業・技術領域が増える中で、技術的意思決定の基準・価値観を揃えることは重要になってきます。 正直、TUNAG は自分でも全体の技術を把握しきれない規模に成長しているのですが、例えば、プロダクト開発を一時的に止めてでも投資すべき技術的な意思決定の判断を迫られた時に「分かりません」じゃ話になりませんし、理解して投資が必要と判断できれば、事業責任者に説明して納得してもらえるように働きかける責任がCTOにはあります。実際、私が全ての領域を理解し判断していくことは難しいですが、問題提起や議論のファシリテートをしながら、各意思決定をオープンに残し、エンジニアチーム全体でベストな意思決定に導くフォローはできるはずです。考えてみれば当たり前なのですが、自社のシステムを十分に理解していないことによって起こる機会損失は、最新技術のトレンドや他社の事例知らない以上に大きいと捉えています。なので2021年は全体最適のリードができるように、自分の技術領域を増やす方向でインプットし、まずはシステムの理解を深めていきたいと思います。

また、事業を複数展開し組織化が進む中で、同じような課題や意思決定が増えてくるはずです。組織内での車輪の再発明を防ぎ、組織化していくからこその強みを生かしていくために、横展開することを想定した設計や基盤の整備、及びナレッジの水平展開が可能な情報共有・展開の仕組みも考えてきます。

そして、社内のエンジニア全体へこれらのメッセージを定期的に発信できるように、月一くらいでCTO通信的なものを始めてみようと思います。


振り返ってみると、2020年は組織や技術の変化が沢山ありました。まだ書き足りないですが、ここで終わりにします。年始に良いスタートダッシュが切れるように、年末は来年のイメージを膨らませながらしっかりリフレッシュをします!

皆さん1年間お疲れさまでした!

最後に

株式会社スタメンは、2020年12月15日をもちまして東京証券取引所マザーズへ新規上場いたしました。これまで支えてくださった方々への感謝の気持ちと、またここからリスタートし、次の高い山を目指してより一層プロダクト開発に励んでいきたいという思いです。

来年は、既存システムのアーキテクチャを事業成長の方向に合わせて大きく変えていくアーキテクトや、大規模なシステムの運用やソフトウェア開発をリードするエンジニアなど、幅広く仲間を見つけていきたいと思っています。B2Bの TUNAG だけでなく、オンラインファンサロン事業 FANTS も展開しており、今後も多角的に事業を展開していきたいと思っているので、TUNAG や FANTS に興味を持ってくれた方も、そうでない方も一緒に作っていくエンジニアを募集しています!興味を持ってくれた方は、Wantedlyで応募いただければと思います!技術・会社・事業についてもっと詳しく聞いてみたい方は、松谷(@uuushiro)まで気軽にDMいただければ喜んで返事します!というわけでここまで読んでいただきありがとうございました。