はじめに
エナーバンクは創業時よりフルリモートで始まりました。
もちろん開発もフルリモートでスタートして、約7年経ちます。
プロダクトや組織の規模によるところもありますが、企業のプロダクト開発を円滑に進めていくためには、個々人の技術力だけでなく、コミュニケーション環境も大きな要素だと感じています。
開発コミュニケーション設計に正解はないですが、フルリモート環境で開発を続けているエナーバンクの取り組みをご紹介します。
エンジニアメンバーの在籍地域
エンジニアメンバーが在籍している場所を県単位でマッピングすると、下記のようになります。
本社は東京ですが、色々な場所を生活拠点にしているメンバーが所属しています。
（会社全体がフルリモートなので、他の職種の方もいれると、北海道から九州まで、もっと色塗りできます！）
開発組織におけるコミュニケーションの位置付け
昨今、様々な便利なツールが出てきていますが、質の高いプロダクトを開発するためには、やはり人と人の円滑なコミュニケーションが最も大切なのではないかと考えています。
多くのプロダクト開発は、一人のエンジニアで全てやり切るのではなく、フロントやバックエンドで役割分担して開発速度を上げたり、実装者と異なる人がレビューを行い、質を担保することになると思います。
（創業前〜直後のプロトタイプやPoCなどは一人でやり切ることも多いかもしれませんが）
しかし、勤続年数もスキルもプロダクトの関わり方も異なるメンバーが共通のゴール（＝プロダクトや機能の開発）に向かっていく過程では、様々な疑問が出てきます。
全てをドキュメント化せよ、ということかもしれませんが、厳密性・網羅性・わかりやすさを兼ね揃えたドキュメントを整備することは難しく、コミュニケーションで解決が必要となる場面は多々あると思います。
（属人化の回避方法として自動化もあると思いますが、自動化できることは限られていると思います）
このようなときにも円滑に、タイムリーにコミュニケーションができるように、ツール整備や日々のコミュニケーション作りをしています。
また、念の為、補足すると、常にコミュニケーション（＝会話）していることが善とも思っていません。エンジニアに限らずですが、設計や実装など、自分一人で集中しないとアウトプットできないことも多くあると思います。
開発コミュニケーションを支えるツール
リモートワークでは、対面で話せない以上、ツールを介してコミュニケーションすることになります。
エナーバンクでは、新規メンバーの負担がかからないように、ツールはあまり珍しいものは使わず、業務ツールとしては標準的なものを採用しています。
- Github：コード管理
- Slack：テキスト、チャットコミュニケーション
- Teams：オンラインMTG
- Notion：ストック的な情報の共有全般、開発のカンバン管理として利用
チャットコミュニケーションはTeamsでもできますが、創業時よりSlackを使っており、蓄積された会話量やAPI連携などを考慮して、利用を継続しています。
開発のカンバン管理は、TrelloやGithubのProject機能を使ったりしていましたが、全社的な情報管理ツールがNotionに移行するのと同時に、Notionに切り替えました。
これは、BizサイドのNotion情報とのリンク性を高められること、なるべく日常的な業務ツールを増やさないことを狙いとして実施しました。
円滑なチームコミュニケーションを期待する取り組み
どれも特別珍しいことではないですが、下記の主な4つの取り組みをご紹介します。
- 疑問点を発信することの大切さを共通認識化する
- 共通情報を一元管理する
- コミュニケーションに至るためのハードルを下げる
- 隣の人が何をやっているか知れるきっかけを作る
疑問点を発信することの大切さを共通認識化する
オフラインだと、顔色などの非言語的なコミュニケーションで、「あ、この人もしかしたら困っているかも」ことが伝わるかもしれませんが、フルリモート環境で同じ方法をしても、自分の状況を伝えることも、相手側も自然と察知することもできません。
自分で調べて解決するという姿勢や行動も大事ですが、社内にドキュメントがまだ整備されていない内容など、そもそも自力では解決できないことも多々あります。
不要な探索作業や、不安や焦りを発生させないためにも、「疑問点があれば、自分から質問することが大切」ということを共通認識化しています。
また、質問することは自分の勉強不足や調査不足なのではないか？といった負目を感じてしまい、質問することに躊躇しないために、「誰でも知らないこと、わからないことがある」ということも強調しています。
共通情報を一元管理する
こちらは仕事であるあるの話です。SlackやNotionの各ページやチケットが増えてくると、情報が散財してしまいます。
メンバーが知るべき、自律的に把握できる情報は、共通化し、置き場所も一元化することで、メンバーの作業や心理的な負担を減らせます。
エナーバンクでは、「開発チームのHello World」というページを作成し、運用しています（下図）。
コンテンツとしては、下記のようなものがあります。
- メンバー紹介ページ
- 技術スタック概要
- プロダクトの基礎情報
- プロダクト環境構築情報
- ブランチ運用やコーディングルール
など
このページを読めば、社員・業務委託の新メンバーも最低限キャッチアップできるようになることを意識して、日々アップデートしています。
コミュニケーションに至るためのハードルを下げる
フルリモート環境だと、コミュニケーションするためには何かしのらツールを使うことになります。
ツールを使うには、MTG URLの発行など何かしら作業が発生すると思いますが、これが面倒だと感じてしまうと、必要なコミュニケーションが行われなくなってしまいます。
この作業をゼロにすることは難しいですが、下記のようなことで、なるべくコミュニケーションに至るためのハードルを下げています。
- 会話したいと思ったときのMTG URL発行の手間を防ぐため、固定のURLを発行
- 上記の固定URLはSlackチャンネルのリンク集に貼り、わかりやすい動線の確保
- timesチャンネルを作成し、自分のペースで発信できる環境を用意
隣の人が何をやっているか知れるきっかけを作る
1つ目のところでも書きましたが、フルリモート環境だと、自分の発信ベースでコミュニケーションが発生していきます。
このような状況だと、業務的に直接連携している人を除いて、他開発メンバーが何をやっているか？ということは自発的には起こしづらいと考えます（オフラインならまだしも、オンラインで特に要もないのに、今何やってるんですか〜？と聞くことは心理的ハードルがあると思います）。
直接業務と関係ない人が何やっているか知る必要あるのですか？という意見もあるかもしれませんが、開発コミュニケーション上、お互いを知ることは大事なことの一つ考えており、そのきっかけ作りとして下記のようなMTGを行っています。
- 週2回の社員MTG、週1回の業務委託を含めた全体MTGを実施し、担当プロダクトに依らず各自のタスクや進捗などを共有
- 全体MTGでは、2週間に1回KPT会として、業務でもプライベートでも自分なりの振り返りを報告
これらの効果として、周りの人がどんなことをやっているか？どんなスキルを持っているか？ということがわかると、疑問点が出てきたときに、あの人に聞けば良いな、とイメージしやすくなります。これは、1つ目の疑問点を発信しやすい環境作りにつながるのだと考えています。
また、Full-Stack TypeScriptとServerlessを基本の技術スタックとした複数プロダクトを開発する中（参考記事）、案件によって開発するプロダクトや連携する開発メンバーも変わります。
チームとしてお互いを知っていること、新しい組み合わせだったとしても、案件開始時の立ち上がりも早くなると感じています。
（参考記事）
まとめ
会社の立ち上げ時からエナーバンクはフルリモートで業務、開発を行ってきましたが、より良い環境となるようにツール選定やコミュニケーションの形は適宜アップデートしてきました。今実施している主要な取り組みについてご紹介しました。
冒頭にも書きましたが、コミュニケーション設計に正解はありませんので、引き続き、見直しや改善を行っていきます。
また、この記事ではフルリモートでの話にフォーカスして書きましたが、対面でのコミュニケーションの大事さも感じており、メンバー同士がオフラインで会う機会がゼロというわけではありません。
現在は社員だけですが、四半期〜半期に一度開発チームでオフラインMTGも実施しています！（写真は昨年12月の様子。MTGの後は忘年会へ）
最後に
株式会社エナーバンクでは、Full-Stack TypeScriptやサーバーレスアーキテクチャーを活用することで最小限の開発リソースで複数のプロダクトを同時開発しています。
もし事業や技術スタックに興味があるエンジニアの方がいましたら、ぜひ採用ページおよび、エンジニアの求人ページをご覧ください！
良き開発ライフを！
Discussion