完全リモートでの開発チームの回し方

はじめまして、yusukeです。

株式会社リリーとして受託開発やオフショアを使ったラボ開発、開発体制の内製化支援等させて頂いています。開発がメインですが最近はエンジニア採用支援などもしています。

チーム内には国内、海外のエンジニア(ブリッジエンジニア含む)がいますが全員フルリモートでの業務になります。

本記事では弊社での完全リモート下でのチーム開発について書かせて頂きます。

新型コロナウイルスの影響で以前はリモートではなかったけど現在ではリモートになったチームも多いと思います。リモートに慣れていない方に少しでも参考になればと思います。

プロジェクトの進め方

以下の流れで進めていきます。

  1. 仕様決め
  2. 技術選定
  3. メンバーアサイン
  4. タスク作成(プロジェクト管理)
  5. スクラム、アジャイルでスプリント回してく

1.仕様決め

仕様決めのMTGはZOOM or Google Meetです。

クライアントが仕様、機能についての資料を用意してくれていれば、それを共有いただいて話を進めていきます。

資料がない場合は解決したい課題、サービスとして提供したい価値について話し合いながら必要な画面、画面ごとの機能にドキュメントとして落とし込んでいきます。

2.技術選定

技術スタックは以下から選択することが多いです。

ざっと例を上げてみます。

デザイン

  • ほぼFigma一択

(クライアントが既にデザインを持っている場合はそれに従う)

インフラ

  • AWS
  • GCP
  • Firebase

基本的に開発はDockerを使うのでイメージを使ってデプロイ出来るものを選びます

サーバーサイド

  • FastAPI
  • Django REST framework
  • Laravel

フロントエンド

  • TypeScript
  • JavaScript
  • Nuxt.js
  • Next.js

大体UIライブラリを採用します。Vuetifyとか

3.メンバーアサイン

  • エンジニア
    • 国内フリーランス
    • ベトナムオフショア
  • デザイナー
    • 国内フリーランス

大体以前一緒にお仕事させて頂いた方にお願いすることが多いです。もしくは知り合い経由でご紹介頂く感じです。

メンバーをアサインする際に気をつけていることとしてはフルコミットを要求しないことです。正直優秀なエンジニアにフルコミットしてもらうのはとても難しいと思います。そういう方はいろんなところで引っ張りだこですから。

なので20h/週とかでも全然OKです。

4.タスク作成(プロジェクト管理)

プロジェクトの管理にはGithub Projectsを使います。

以下の流れでISSUEを作成します。

  1. ISSUE作成(To do)
  2. ラベルを貼る
  3. 優先度順に並び替える

ISSUE作成

以下ISSUEに記載する内容

  • Figmaのリンク(UI実装の場合)
    • ボタンを押した時挙動などは大体Figmaを見ればわかるようにしておく
  • 処理の流れ、実装方針
  • 必要であれば導入するライブラリ情報など
    • そもそもライブラリの選定が必要な場合はそれ自体を別ISSUEにする

ラベルを貼る

  • ISSUEサイズ
    • S、M、L
  • フロント、サーバーサイド、インフラの内どのISSUEか
    • front、api、infra
  • 必要に応じてISSUEタイプ
    • bug、refactoring、UTest…
  • 着手可能な状態ならanyoneラベルを貼る
    • anyoneラベルを貼っていないISSUEは着手してはいけない
    • 着手可能だが誰でもいいわけではない場合はanyoneラベルは貼らずに対応するメンバーをアサインしておく

優先度順に並び替える

この状態を作れたらメンバーは「To do」の一番上にあるISSUEから自分をアサインして「In progress」に移動させます。これで誰がどのISSUEを着手しているのかが可視化できます。

ISSUEが完了したら「Done」に移動させてまた「To do」の一番上にあるISSUEを取って。。。この繰り返しです。(実際はPRをマージしたら自動で「Done」になるように設定したりしてます。)

次はスプリントとしてメンバーがどのように稼働していくかを説明します。

開発におけるリモートワーク

基本的に始業、終業時間は決まってないです。予め決めてあるコミット可能な稼働量で好きな時間に働く感じでOKです。規則正しく働く人もいれば本当に毎日バラバラだったり色々ですね。

稼働開始する時に稼働開始の宣言みたいなものも不要です。稼働終了するときにその日やった業務をSlackで共有して終了の流れです。その際に担当しているISSUEが終わってPRが出せる状態ならレビュー依頼しておきます。

引き継ぎのコツ

ISSUEが完了していなかった場合でもDraftでPRを必ず出すようにしています。DraftでPRを出しておくことで次の稼働まで時間が空いてしまう場合に他の人に引き継ぐことができます。

このDraftで出したPRを他の人が引き継ぐのはそれなりの頻度で起こっています。それでも問題なくワークしているのは以下の点に気をつけているからだと思っています。

  • 誰が見ても実装内容がわかるようなISSUEを作成する

    • Figmaのリンクなど必要な情報を詰め込む
  • 可能な限りISSUEの粒度を小さくする

    • 実装のスコープが狭ければ比較的コード量も少なくレビューもし易い

こんな感じで日々の業務をこなしていきます。

コミュニケーションは文字ベース

基本的なコミュニケーションはSlackによるテキストがメインです。場合によっては直接話したいケースもあります。仕様確認とか、もっとこうした方がよくない?とか。

その場合は基本的にSlackのハドルを使ってコミュニケーションを取ります。(場合によってはZoom、Google Meet)といった感じでコミュニケーション、生存確認はほぼほぼSlackです。

参加者の多いMTG、イベント系はZoom、Google Meetを繋ぎながらmiroを使います。

スクラム、アジャイルでスプリントを回していく

ここではスクラム、アジャイルについて詳しくは書きませんが、これまで書いてきたデイリーの開発からスクラムイベント(レトロスペクティブとか)をスプリントとしてひたすら回していく。それだけです。

最後に、ツールのご紹介

最後にリモートワークを助けてくれるツールをまとめて終わりにします。

少しでも参考になれば嬉しいです。

ツール

  • Github
    • タスク管理、プロジェクト管理
    • wikiを使って一部ドキュメントとしても
  • Figma
    • UI/UXはここを見ればOK
  • Slack
    • 主なコミュニケーションはここ
  • Zoom、Google Meet
    • 複数人でのコミュニケーション
      • イベント系とか
  • miro
    • レトロスペクティブで使ったり
    • ホワイトボード的に使う
この記事をシェア

関連記事


副業・フリーランス

プログラミング

デザイン

インタビュー

お金

採用・組織

転職

イベントレポート