こんにちは、技術本部Sansan Engineering Unitの岩佐です。
2021年の4月に新卒入社し、Webエンジニアとして、クラウド名刺管理サービスのSansanの開発を行っています。
今回は11月5日に開催された弊社の技術カンファレンス『Sansan Builders Stage 2021』から2つのセッションをピックアップしてご紹介したい思います！
まずはこちらのセッションから！
新卒2年目のチームリーダーとBill One開発
「新卒2年目のチームリーダーとBill One開発」というタイトルで、Bill One Engineering Groupの山邊が発表しました。
「Bill One」は、様々な方法・形式で届く請求書をオンラインで受け取れる、クラウド請求書受領サービスで、昨年の5月にローンチしたサービスです。その中でチームリーダーの役割を担う山邊が、新卒二年目の視点からみるBill One開発の現場について紹介しました。Bill Oneのサービス詳細についてはこちらをご覧ください。
Bill One - 請求書受領から、月次決算を加速する
Bill One Engineering Groupの組織について
Bill One Engineering Groupには2021年10月現在、27名のエンジニアが所属しており、5名程度のチームに分かれて開発を行っています。それぞれの要件に対してチームが編成され、要件が完了すると次の要件に向けてチームが再構成されるそうです。
そして各チームには3種類のロールを持つ人が存在し、それぞれ次のように紹介しています。
- PjM：プロジェクトマネージャー
- プロジェクトの進捗管理やメンバーのメンタリング、成長補助を行うロール
- ミニPdM：ミニプロダクトマネージャー
- チームごとに設定される、プロダクトの使用や要件を決定するロール
- TM：テクニカルマネージャー
- コードの品質を担保し、チームの技術力向上のために一役買うロール
これらのロールは新卒や経験関係なく誰でも立候補でき、誰でも挑戦することができる仕組みになっています。現に私と同期の新卒1年目のエンジニアが、PjMのロールで活躍しているそうです！
このように新卒1年目であっても、様々なロールに対してチャレンジできることは、エンジニアとしてとてもやりがいのあることだと私は思います。
コミュニケーション
Bill Oneは現在、関西支店や東京本社をはじめとする、拠点を跨いだ開発が行われています。また、ローンチされた昨年の5月はちょうど1回目の緊急事態宣言下であり、ほぼフルリーモートの環境下で開発が進められたそうです。そのような開発環境でメンバー間のコミュニケーションロスを削減しようと、「Teamflow」などのバーチャルオフィスツールを導入するなど様々な試みがされていました。
また山邊は、このセッションの中で、「雑談を増やす」ことについても言及しました。
私自身も経験があることですが、オンラインでの開発環境では、対面と比べてメンバーに気軽に質問するハードルが高くなりますよね。
定例などで、ある一定の情報共有や質問はできますが、すぐ聞きたいのになかなか聞けないという状況になりがちです。山邊はこの聞けるけど聞かない状態がロスタイムであるとし、定例の時間とは別に「意図的な雑談」の時間を設けたそうです。
この意図的な雑談の時間を設けることで、自然と雑談をする文化が芽生え、その中で質問し課題を解決しようとする人が増えたと述べています。
リリース
Bill Oneのリリースは週に2回、昼の時間に行われています。リリースの実施者は開発メンバーがまだ少人数の頃は”よしなに”できていましたが、人数が増えることでその仕組みが機能しなくなってしまう課題が出てきたようです。現在ではPjMや有志で考え、当番制を試すフェーズとなり、今後も議論を重ね改善していくということでした。そのほかにもBill Oneでは、ドキュメント整理やリファクタなどの優先度の低いタスクを行う「ローンチDay」や、定期的にパッケージのバージョンアップを行いレガシー化を防ぐ「バージョンアップDay」などのイベントが月に1回実施されるそうです。
最後に、テクニカルマネージャー、プロジェクトマネージャー、BillOneとしての今後の成長について述べ、本セッションの結びとなりました。
以上、「新卒2年目のチームリーダーとBill One開発」の紹介でした。
山邊の発表資料は Speaker Deck にて公開されていますので、ぜひご覧ください。
Sansan Engineering Unitとの違い
このセッションを聞いて改めて、私の所属するSansan Engineering Unitとの違いを実感しました。Sansan Engineering UnitでもBill One同様6名前後のチームが構成されていますが、チームごとのミニPdMのようなロールは存在せず、それぞれの機能を担当する複数名のPdMが1つの組織に集まっています。この組織体制の違いは、組織の規模やプロダクトのフェーズによって生まれてくるものだと考えます。
Sansanの開発組織は現在100名を超えるメンバーが所属する組織となりました。また開発プロセスも「量より質」に向き合うプロセスへと変化しています。このようなフェーズにおいてPdMがビジネス側との連携を強化するためにも、またPdM間の共有を確実に行うためにも、現在の組織体制になっているのだと思います。
Sansanプロダクト組織については、杉原が「Sansanプロダクト組織の規模とプロセスの変化」発表しております。興味のある方はこちらもあわせてご覧ください。
続いて紹介するセッションはこちら！
Eight Webフロントエンドの開発者体験（DX）向上のための取り組み
Eight Engineering Unit Eight Career Devグループの鳥山は、「Eight Webフロントエンドの開発者体験（DX）向上のための取り組み」というタイトルで発表しました。
Eightは、「名刺でつながる、ビジネスのためのSNS」というコンセプトの、個人向け名刺アプリです。個人向けサービスだけでなく、ダイレクトリクルーティングサービス「Eight Career Design」をはじめとする、企業向けのサービスも展開しています。Eightについて詳しく知りたい方はこちらをご覧ください。
Eight - 名刺でつながる、ビジネスのためのSNS
開発者体験（DX）とは
鳥山は、はじめに自身が向き合う「開発者体験の向上」について解説しました。
開発者体験とは、「開発にまつわるすべての行為を通じた開発者の体験（DX:Developer eXperience）」を指し、このDXの向上とは「快適に開発を行うことができる環境の整備」であるといえ、徐々に進めていくために重要な5つのポイントについて紹介しました。
- 議論できる場を作る
- 思い立ったらすぐに議論ができる場を設け、チームで向き合い合意形成を行うことが重要
- 徐々に進められる技術選定を行う
- 作業を細かく分割できる技術選定をすることで、空いている小さな時間でも作業を行うことができる
- 完璧を求めない
- 徐々に進めていくことを念頭において、あらかた方針が決まったタイミングで動き出す
- 後戻りしないようにする
- 積み上げた努力が無駄にならないように、自動化やドキュメントの整備を適宜行い、後戻りを防ぐ
- 積極的にアウトプットしていく
- 企業・個人の技術ブランディングや採用貢献につながり、DX向上への作業に対するモチベーションが向上する
EightのWebフロントエンド開発体制
Eightのフロントエンド開発チームはドメインごとに分けられています。しかしフロントエンドの改善はチームを横断して行われているそうです。
チームを横断するそれらのやりとりはSlackの専用チャンネルで行い、タスクの管理をGitHub Projectsのカンバンボードを利用しています。
個人的に印象的だったのは、エンジニアの「こうだったらいいな」な願いを書くWishカラムを用意し、カンバンボードに書くハードルを下げるようにしている点です。
このように、議論できる場を作り、発言のハードルを下げる取り組みがなされています。
DX向上のための取り組み
鳥山はEightのフロントエンド開発チームで実際に行われた、DX向上のための取り組みを紹介しました。コードの自動形成の導入
EightのWebフロントエンド開発ではコードの自動整形ツールのPrettierを導入しています。導入することで統一されたコードスタイルであることを担保でき、可読性の向上や余分なコード差分を減らすことができます。この取り組みでは、CIなどでフォーマットのチェックを自動化したり、メンバーへの周知やドキュメントの整備を適宜行って、4つめのポイントである「後戻りしない」ようにしたそうです。
TypeScriptの導入
可読性やテストの実施など、コードの品質を高めるために、Eightのフロントエンド開発ではTypeScriptを導入しています。TypeScriptはJavaScriptとの相互運用性があり、部分的な改修が可能なため、2つめのポイントである「徐々に進められる技術選定」が実現できると言います。
コンポーネントライブラリの作成
EightではフロントエンドのフレームワークにReactを採用していますが、そのコンポーネントの実装・デザインにばらつきがあったと言います。そこでコンポーネントライブラリなどの、デザインシステムを構築し、デザインの一貫性と開発の生産性を担保する仕組みを取り入れました。
この取り組みでは、ライブラリの完成度を最初から求めないなど、3つめのポイントである「完璧を求めない」ことが重要になるとそうです。
これらのDX向上のための取り組みを行った結果、 組織に次のような変化が起こったと述べ、本セッションを結んでいます。
- コミュニケーションが増え、DXに向き合うメンバーが増えた
- 作業工数が少しずつ確保できるように
- 開発のスピードが上がり、その後の開発が快適に
以上「Eight Webフロントエンドの開発者体験（DX）向上のための取り組み」の紹介でした。
鳥山の発表資料は Speaker Deck にて公開されています。
Sansan Engineering Unitでの取り組みは?
このセッションを受け、私の所属するSansan Engineering UnitではどのようなDX向上のための取り組みが行われているか、考えてみました。SansanとEightでは、技術スタックが異なるため使用するツールは変わりますが、Sansanでも「コードの自動形成の導入」は行われおり、ある一定のコードスタイルが担保されています。
また私の所属するチームでは週に1時間、チームメンバーで決めた内容の勉強を行う時間を設けており、これもDX向上のための取り組みの1つだと思います。チーム内で1つのテーマについての共通認識を作ることで、認識の齟齬を防ぎ、ドキュメントやコードのレビューなど、円滑に進めることができています！
Sansanのエンジニアが働く環境や技術スタックなど、Sansanのエンジニアリングについて興味を持った方は、ぜひこちらのサイトもご覧ください。
jp.corp-sansan.com
まとめ
本記事では、Sansan Builders Stage 2021 で発表されたセッションの中から、Bill OneとEightというプロダクトに向き合っている2人のセッションをピックアップしてご紹介しました。どちらのセッションも、それぞれのプロダクトのフェーズで、開発を円滑に進めるための取り組みが述べられていて、私自身とても勉強になりました！
Sansan Builders Stage 2021では今回紹介したセッションの他にも、魅力的な発表が多数ありました。そちらのレポートも本ブログで随時公開していくので、ぜひご覧ください！
第1弾
buildersbox.corp-sansan.com
第2弾
buildersbox.corp-sansan.com
