こんにちは！ GMOクリエイターズネットワークで技術責任者として働いている、ぼいらーです。 今年（2023年）4月にエンジニア１人目として入社してある程度たったので、入社してからやったこと・感じたことを中心にふりかえってみたいと思います。
GMOクリエイターズネットワークとしてはブログやテックブログを持っていないので、グループ会社であるGMOペパボのテックブログの場所をお借りしています！
入社のきっかけ
ペパボの某人事の方から当時のTwitterにてDMをいただきそこから話がはじまりました。 私は過去にGMOペパボで働いていた経験があり、そのつながりでお声掛けいただきました。
開発チームはGMOインターネットグループ内外の方々に開発を手伝っていただいている状況で、正社員としてはエンジニアだけでなく、プロダクトマネージャー、デザイナーなどの職種の方が１人もいませんでした。
社内のプロダクト開発チーム１人目として立ち上げから携わる事ができるという点が、かなりの大変さも感じつつ、面白そうだなと感じました。
また、いろいろとお話をお聞きするなかで、運営しているフリーナンスというサービスのビジョンに引かれた点や、FaaS構想を発表しており、面白い取り組みをしていた事もあり、入社を決めました。
入社してからやったこと・感じたこと
現状把握
何はともあれ現状を把握を実施し、どこから手を付けていくかを考える必要があります。 まずは開発関連のドキュメントを探してみたり（最新のものがなかった）、開発環境を立ち上げてみたり、細かいプルリクを送ってみたり、Google Cloud上でサービスが動いているので、コンソールの中をのぞいてみたり、開発をリードされている方にアーキテクチャを聞いてみたり、自分でもサービスを使ってみたり。などなどしてキャッチアップを進めていきました。
その中で、技術スタック、開発体制、インフラ刷新プロジェクトについて少し触れたいと思います。
技術スタック
Google Cloudが使われており、GCE、Cloud Run、Cloud SQL for MySQLなどが主に使われています。 言語としては、バックエンドはGo（Revel）、PHP（CakePHP）がメインで使われており、フロントエンドは、TypeScript、JavaScript、Vue.js、Reactなどが採用されていました。 特徴的な部分としては、GCEの中でDockerを動かしている構成がベースとなっていました。
技術スタックやサービスのアーキテクチャに関しては別途、公開予定の記事で詳しく紹介させていただきます！
開発体制とチーム構成
開発体制としては冒頭でお話した通り、私が入社するまでは正社員としてエンジニアだけでなく、プロダクトマネージャーやデザイナーも１人もおりませんでした。 開発チームとしてはGMOインターネットグループの方々に開発をお願いしている部分と、業務委託の方々にお願いしている部分の２つに分かれていました。 そしてGMOクリエイターズネットワーク側としてはフリーナンスを立ち上げた事業責任者の方が主に開発面をみていました。 そこに私がジョインしたという形になります。
また、仕様の議論やタスク管理はGitHubのIssueやProjectsで管理されていました。
インフラ刷新プロジェクト
私が入社する以前から取り組みがされていた、インフラ刷新のプロジェクトが存在していました。 GCEベースで構築されていたメインのサービスを、Cloud Runに移行するというものです。
半年以上時間をかけていた大きめのプロジェクトであり、移行方法についていろいろと工夫がありましたので、これに関しても別途、公開予定の記事について詳しく紹介させていただきます！
開発チームのコミュニケーションとドキュメントの整理
現状把握をしていく中で、まずは開発者が動きやすくするために以下を整理する必要があるなと感じました。
- 開発チームのSlackチャンネル整理
- 開発チーム内でのNotionの導入
- 開発の共有Googleドライブ
開発チームのSlackのチャンネル整理
開発者が技術について話すチャンネルが存在しておらず、技術面の込み入った話がしにくい状況でした。 また、開発体制として、GMOインターネットグループの方々に開発を依頼している部分と、業務委託の方々に開発を依頼している部分の２つがあり、それぞれ入っているチャンネルがバラバラで、社内の部門の方々からエンジニアに問い合わせを行う時も問い合わせ先がわからず迷っているケースがありました。 また、エンジニアによって入っているチャンネルや入っていないチャンネルがありました。
この状況の解決のため、エンジニアが技術的な会話や雑談ができるチャンネルを作成したり、社内の部門の方々と主にやりとりするチャンネルを整理し一本化したり、ひととおりエンジニアに入っていただきたいチャンネル一覧を作成し、開発に関わる人全員が入るようにしました。
開発チーム内でのNotionの導入
情報の集約先としてのドキュメントツールがなく、Slackを検索したり、Googleドライブの中身を検索して仕様を探したりしている状況でした。 全社的なドキュメントの集約先もなかったので理想は全社に導入したいところですが、まずは小さく開発チーム内で導入を始めることを決めました。
Notionを使い始めるにあたっては、
- チームメンバーの紹介ページ
- システム概要
- 議事録
- 手順書
- サービス仕様
などなど、よくある構成だとは思いますが情報の置き場を作成しました。 情報の置き場を最初に整理しておくことで、他の開発メンバーの方々もじわじわと使い始めてくださり、嬉しかったです。
システムの概要図や各サービスがどういった依存関係になっているかなどを表した図がなく、自分の理解を深めるためにもヒアリングしたり、コードを読んだり、Google Cloudのコンソールをみたりして、Notionにまとめつつ、こつこつとキャッチアップを進めていったのはいい思い出です。
開発の共有Googleドライブ
開発チームとして利用する、Googleドライブの共有ドライブが存在しておらず不便だったため作成しました。 その際には、READMEを書いて、後から来た方がどういう形で使えばよいかわかりやすいようにしました。 また、外部とのやり取りした技術資料がどこにあるかわからずSlackを検索して見つける必要があったので、そういった資料があればまずは共有ドライブに資料を入れたり、SlackでExcelファイルが共有された際にはすぐに共有ドライブにアップロードして、原本がどこにあるかわからなくなる問題をなくすように務めました。
ただ、Excelの機能を駆使したものを共有フォルダにアップしてしまうと、それを開いたタイミグで動かなくなるケースがあり、苦渋の決断でzipで固めてアップしたケースもありました。 （幸いにも、一度更新したら記録としてしか保持する用途がないファイルだったため、この運用で事なきをえました）
SQLを書ける方々が多い
Redashが導入されており、ビジネスやマーケティング、CSなどエンジニア職以外の方々がSQLを書いてデータ抽出をしていた事に驚きました。 複雑なSQLはエンジニアが作成することもありますが、基本的には独力で作成できますし、複雑なものを渡したとしても細かい修正はできる状態になっていました。 理由としては、フリーナンスを立ち上げた事業責任者の方がSQL講習会を定期的に開き、SQLの基礎知識だけでなく、サービスのどのようなデータがどのテーブルに格納されているかなどの知見を共有していたため、これが可能になっていました。
迅速にデータ分析ができて業務に生かせる点は弊社の大きな強みだと思っています。
優先順位・優先順位・優先順位。まずは採用
いろいろとキャッチアップや情報収集をしつつ、どこから手をつけていくのがよいかなと考えていたときのことです。 正社員のエンジニア１人目ということもあり、やることを上げていくとキリがありませんので、優先順位をつけて高いものからやっていく事しかできません。 幸いにも、普段の開発業務に関してはすでにいらっしゃる方々で回っていたため、基本的にはお任せして、自分にしか出来なさそうな採用に注力するのが良かろうと考えました。
まずは募集要項を作成する必要があると考え、エンジニア関連の募集要項の作成、そして、プロダクトマネージャー、デザイナの募集要項も作成しました。 プロダクトマネージャー、デザイナに関しては専門外だったので、ペパボの有識者の方々にレビューをいただき、募集要項を完成させました。 作成するに当たっては採用競合となりそうなベンチャーの採用ページもかなり参考にさせていただきました。 このときは四六時中、各社の募集要項を見ていたので、周りからは変な目で見られていたかもしれません笑
そしてTalentioが採用のツールとして使われていたので、その整備を行いました。 作成した採用情報のページはこちらです！
今はあまりTalentioを触らなくなってしまってだいぶ忘れたのですが、募集要項や、採用ページ周りに関しては当時は社内で一番詳しかったと思います！
この時の後悔としては、全体的にしっかり考えすぎてスピード感が足りなかったと反省しています。 募集要項を多少雑でもいいから早く完成させて、採用ページよりも採用媒体などの利用にもっと力を入れれば、より早く採用を開始できる状態になったのかなと思います。
プロダクトの仕様決めの部分についての模索
当初はプロダクトの仕様についての議論はGitHubのIssueで議論されており、この時の課題が２つありました。
- 議論された結果、仕様が結局どうなったかわかりにくい
- 開発チームと限られたメンバーしかGitHubを使っておらず、開発チーム外の方々に仕様の共有がしにくい
そこで、Notionにプロダクトの仕様を書いて、そこで話した内容をもとにIssue化して開発していく方式にしました。 まずは、PRD（Product Requirements Document）のひな形をソフトウェア・ファーストという書籍に記載されていたものをベースに作り、それをもとに何回かPRDを私が書いてその仕様をもとに実際に開発する方と議論をし、議論した結果をPRDに再度反映していく形にしました。 NotionはGitHubのIssueとは違い、特定の部分に対してコメントが入れられるため、仕様の議論がやりやすくなりました。 また、決まった仕様を開発チーム外の関係する方々に共有するときも、Notionのページをシェアするだけでまとまっているため、仕様の共有もコスパよくできました。
一方でそこまで大きくない機能追加に関しては、PRDを毎回書くのはオーバースペックだなとも感じており、今では「なぜやるのか？」「やること」だけ書いて終わらせることが多いです。 また、ユーザや社内の方からの問い合わせ対応から細かいバグが発覚し、修正するケースにおいては、Notionを作るよりもSlackベースでいただいた内容をIssue化して対応を終わらせています。 どこまでをNotionで管理して、どこからをIssueとして管理するかは自分の中でまだスタイルが決まっておらず、引き続き模索していきたいと思います。
なにはともあれ、オブザーバビリティ！
技術的な改善を進めていくにあたって、何から手を付けていくのがいいかと考えていたのですが、まずはサービスがどういう状態なのかを効率よく把握できるようにすることが一番重要であると考えました。 ログ、メトリクス、トレースの３つをさくっと把握できてなおかつ、サービスが正常に動いていることを定義、監視できれば、障害や不具合が発生した時にも迅速な対応ができるようになりますし、不具合が顕在化する前に対処できるケースが多くなると思いました。 現状のサービスにおいてはこの部分が弱く、効率的に運営できていない部分がありました。
具体的にはDataDogを採用し導入を進めています。 Google CloudのCloud Monitoringを使う方向性も考えましたが、少人数で最低限のオブザーバビリティを担保する状況を構築するにあたって、DataDogの方が任せられる部分が多そうで効率よく構築できるのではないか、今後のDataDogの機能追加や進化に期待するところもあり、DataDogにしました。
しばらくは私１人で導入を進めていましたが別のタスクも進めながらの進行だったため、なかなか思うように進みませんでした。 一方で、他の方々も優先的に作業を行う必要があるタスクを抱えており、なかなか余裕がない状況でした。 そんな中、少し前からペパボから助っ人に来てくれたエンジニアの そめやポチ@kesompochyさん がゴリゴリ進めてくださっていて一気に進みました。 めちゃくちゃありがたいです！この場を借りて改めてお礼申し上げます！
今振り返ると、いろいろとやるにあたってDataDogの導入をまず進めていく事を決めたのは、とてもよい決断でした。もっと使いこなしていきたいですし、今後も今以上に活用を進めていきたいと思っています。 昨今のエンジニア採用難もありますし、DataDogを始めさまざまなツールを積極的にまずは試す。そして良いものは多少コストを掛けてでも導入していく。 そういった思想の下、少人数でもなるべく効率的に開発を回していける体制を作っていきたいです！！
ミッションの作成と共有
ある程度社内やプロダクトの状況が見えてきたところで自分なりにミッションを考えて関係者や社内の方々にシェアしました。
「技術」「プロダクト」「仕組み」の力でフリーナンス、GMOクリエイターズネットワークをスケールさせる
というミッションを定義しました。時期感としては半年〜１年くらい先までを想定して作ったつもりです。 もう少し細かい内容としては以下になります。
- 技術: サービス開始から５年が経過しているため、技術的に改善が出来そうな部分が多くあり、まずは足回りを整えて効率よく開発ができるようにする体制の構築
- プロダクト: フリーナンスというToC向けのプロダクトと、社内向けの業務システムという２軸があり、まずは社内向けの業務改善に注力し、その後ToC向けのプロダクトの改善に注力する
- 仕組み: プロダクトや組織をスケールさせるためには筋の良い仕組み化、振り返りが必要
技術面に関しては、技術改善系タスクを推進するチーム（ここまで書いてきたように、DataDogの導入や、インフラ刷新のプロジェクトなど）、新規機能開発・運用系タスクを推進するチームの２つにわけて開発を回しています。 ２つのチームに分けることで、タスクを割り振る時も混乱が少なくなりますし、開発チームとしてそれぞれに注力する割合をチームの人数比で表せられるようになり、管理が非常にシンプルになります。現状はおおむね半々くらいの注力度合いです。
プロダクトに関してですが、社内向けの業務が一般的なWebサービスと比べると複雑であると認識しています。 複雑な業務である事に加えて、いわゆる社内の管理画面上でもろもろの業務を回していたり、Redashからデータを抽出してスプレッドシートに落とし込んでそこで業務を回していたり、サービスで送信しているメールとは別でユーザとやりとりしていたり、Slackのワークフローが使われていたりと、さまざまなものが使われています。 この部分に関しては、業務をちゃんと理解した上で、頻繁に変わりゆくもの・変わらないものを見極めて管理画面に機能として落とし込んでいくことが重要だと考えています。 何でもかんでも管理画面の内部に実装してしまうと、逆に業務に変更が入った場合にエンジニアが修正する必要が出てきてしまうため、改善に時間がかかってしまうためです。
仕組みに関しては、まずは開発内外のやりとりや情報連携をスムーズにできる形で整えていきたいと思っています。 まずはそこから初めて、会社全体として良い影響を与えることができたらなという思いです。
まとめ
入社してから今までやったことを中心につらつらと書いてみました。
正社員のプロダクト開発系人材１人目として、プロダクトや会社のためであればできることは何でもやろうという気持ちで入社しましたが、思っていた以上に大変な日々でした。 入社した今年（2023年）の4月からこのブログを書いたタイミングで８ヶ月が経過していますが、遠い昔の出来事のように感じています。 一方で、やったことない事が経験できたり、開発チームとして少しずつですが良い方向に向かっていけている事を実感できており、それが純粋に嬉しいです。
これからもいろいろありそうではありますが、ひとまずはプロダクトや会社をより良くするために楽しみながらやっていきたいと思います！
GMOクリエイターズネットワークで一緒に働いてくださる仲間を募集しています！！
いろいろと整えてやっていこうとはしていますが、正直なところプロダクト開発組織としてはまだまだこれからですし、仕組みとして整っていない部分や、技術的な改善ポイントも多く存在しています。 しかし逆に考えると、整ってない部分が多いからこそゼロベースで考えて、仕組みを作り上げることができる余地が大きいと考えています。
整った環境での開発はもちろん楽しいですが、整っていない環境を整え、そしてさらにスケールさせていく。サービスももちろん、成長させていく。 これができるのが今のフェーズでの弊社の一番の魅力だと考えています。
そんな未来を、私たちと一緒に作っていきませんか？
もし少しでもご興味を持たれた方々や、単純にどんな状況だったか詳しく聞いてみたい。世間話したい。という方々がいらっしゃいましたら、私の個人のSNSでも構いませんし、カジュアル面談からでも構いませんので、気軽にエントリーしていただけたらと思います！！
今現在は以下の２職種を積極募集中です！！