1人からでも複数人開発にスライドしやすい環境維持のススメ

はじめに

これは ドリコム Advent Calendar 2019 の1日目です。

自己紹介

どうも、DRIP エンジニアの小川です。
DRIP は Drecom Invention Project の略称で、ドリコムが発明を産み続けるためのプロジェクトです。
今年は AR とトークンエコノミーをメイン領域として活動しています。 DRIP 実はここ1年で DRIP は微増し、私にとっては以前よりも多い人数で1つのプロダクトを開発するようになりました。
1人で開発を続けるような環境が長かった私にとって複数のエンジニアで同じプロダクトを開発する経験は少なく、去年や今年は色々と試行錯誤しました。
そんな中「こういう意識で立ち回れば新しくジョインしてくれるエンジニアさんの負担が少なくなるのでは？」という開発手段をいくつか見出したので、今回はその知見を共有していこうと思います。

新しいメンバーに行う理想の案内

  1. README を見てもらう
  2. issues を見てもらう
口頭での説明や補足は必要と思いますが、この2ステップでコード書き始められたら最高だと思ってます。
なので、ここを目指します。

README を充実させ続ける

まず見てもらう場所として README を案内できるレベルには内容を充実させておきたいです。
  • プロダクト説明に必要な資料へのリンク集
  • 開発環境
  • CLI コマンド集
  • 準備
  • サーバー起動
  • テスト
  • Linter
  • etc…
  • ファイルツリーサンプル
  • コード記述ルール
  • MR の出し方
  • 私の参加してるプロダクトは GitLab を利用しているため PR ではなく MR(Merge Request)
「させ続ける」と書いたのは、開発をしていくなかでルールが生まれたり変更したりなどはありえるので、その度に README も編集する文化を作っておく事が大事だからです。
なので README そのものを大きくしすぎるとメンテしづらくなるため、詳細な説明を書かなきゃいけなくなったら別の場所に書き、README にはリンクまでに止めておきます。

例

# react-hogehoge-components

React 製のほげほげなコンポーネント群

# 開発

## 環境

- nodejs
- 12.10.0
- yarn
- 1.19.1

### mac

[nodenv](https://github.com/nodenv/nodenv#homebrew-on-macos)の導入を推奨します。

## コマンド

### 準備

yarn install --pure-lockfile

### 起動

yarn storybook

## コンポーネント

### 階層

{PROJECT_ROOT}/
┃
┗ src/
┗ components/
┗ {COMPONENT_NAME}
┣ index.tsx
┣ {COMPONENT_NAME}.test.tsx
┗ {COMPONENT_NAME}.stories.tsx

## Linter

### ESLint

yarn lint:es

エンジニアが自分1人でもタスクを明示しておく

エンジニアさんが「で、何すればいいですか？」となった時、やるべき事が明示されていないと口頭で説明していかなければなりません。
でもチケットや issues にタスクが列挙されていたら、それをやってもらう事ができます。
優先度が付与されていたらなお良しです。
さらに以下のようなメリットが考えられます。

自分の考えをまとめられる

言葉にしたり、文字に起こしたりする行為はそれだけで認知を深めるので、自分がやろうとしているタスクが本当に正しいのかどうかを己の中で反芻し、より良いタスクに昇華できる可能性があります。
これはエンジニアが1人だけの場合であってもメリットになるので、多少時間はかかっても積極的に書いていくべきです。

今誰が何をしてるのかがわかる

担当しているタスクへのアサインを自分にしておいてもらう開発スタイルを自分やチームに浸透させれば、今誰が何をしているのか一目瞭然になります。
なので「同じタスクを複数人で取り掛かっていた」みたいな悲劇に遭遇しにくくなります。

全体の進捗がわかる

最初に出したタスク量に対して今どれだけのタスクを完了させたかが見えるため、全体の進捗が掴めるようになります。
これは自分だけでなく、非エンジニアを含めたチームメンバー全員に対する効能となるので、スケジュールが引かれている開発だとそれに対して順調なのかどうかを周知しやすくなります。

タスクはできる限り細かく分解する

さて、タスクを洗い出しました。登録しました。優先度もつけました。
本当にそれだけで良いでしょうか？
例えば rails new したばかりの環境に対して 「ユーザーは自身のプロフィールを確認できる」 というタスクがあったとします。
さて、このタスクでは一体何をすれば良いでしょうか？
  • テストが走る環境にする
  • model 層の adapter を決めて導入する
  • User model を定義してテストを書く
  • ユーザー登録するための API POST /users を作成してテストを書く
  • ユーザーのログイン/ログアウト機構を定義してテストを書く
  • ログインするための API POST /login を作成してテストを書く
  • POST /users POST /login はログインしていたらエラーにする、テストも書く
  • ログインユーザー情報を返す API GET /users/@me を作成してテストを書く
  • GET /users/@me はログインしていなかったらエラーにする、テストも書く
例えばこのような手順で実装しようとします。
であるなら、これら全てを別々のタスクにするか、あるいは「ユーザーは自身のプロフィールを確認できる」タスクの中に TODO として定義します。
このタスク分解により、以下のようなメリットが考えられます。

進捗が更にわかりやすくなる

例えば担当するタスクが大きくて2〜3日かかるようなものだった場合、初日は周りのメンバーにとって「◯◯さんは進捗なし」という見方をされてしまうかもしれません。
実際には内部で進捗していても、それを可視化できていなければ説得力が少し弱まるし、明示していなければ周りのメンバーが検知してくれません。
1日に複数個こなせそうなレベルまでタスクが分解できていれば、「今日はこれをやった」「明日はこれをやる」という説明がしやすいし、振り返りもしやすいです。
そしてタスク取る -> タスク完了 -> タスク取るが早いスパンで実施されるため、モチベーションの維持もしやすいはずです。

コードレビューがしやすくなる

タスクが十分に小さくなっているという事は手を入れるべきコード量も少なくなるので、MR にて提出されるコードの変更量も少なくなっているはずです。
コードの変更量が少ないという事はレビューすべきコード量が減るため、レビュー速度が上がります。
レビュー速度があがるとレビューする人される人のキャッチボール回数が増えるので、短期間でより良いコードへの変貌を期待できそうです。
この効能はレビュワーをやってみればより強く感じるかと。

新たに見つかった問題はノールックでタスク化する

さて、日々これらのタスクをこなしていると時々、別の問題が見つかったりします。
例えばそれは考慮漏れであったり、新たな仕様の差し込みであったり。
その時、担当しているタスクに関連する問題だった場合、そのタスクの中で解決しようとしがちです。
でも本当にそれで良いのでしょうか？
新たに浮上したタスクは切り出して、別途優先度を付けていくべきだと私は考えています。
せっかく細かくしたタスクが結果的に膨らんでしまうので、今まで書いてきたメリットが薄くなっていってしまうからです。 「でも、せっかくタスク減らすために頑張ってるのに新たなタスクを増やしたくないよ。」 わかります。
しかしそれは決して悪い事だと思っていません。
私はこういう思考で取り組んでいます。 現実と理想の図その1 プロダクトには理想の状態があり、現在の状態があります。
理想と現在のギャップを埋めるためにはどうすれば良いのか？の「どう」がタスクだと定義しましょう。
全てのタスクをこなせば理想の状態になりますが、「その時点で見えてるタスク」と「その時点では見えないタスク」が存在します。
見えないタスクはそもそも何をすれば良いのかわからないため具体的に手をつけられるのは見えてるタスクだけとなり、見えてるタスクだけをこなせば「到達可能な状態」になります。
到達可能な状態は現在よりも良いですが、理想ではありません。
理想の状態にしようと思ったら見えないタスクの解決は避けて通れません。
しかし、「その時点では見えないタスク」は怖いです。
何が怖いか。
数も大きさも把握できないのでいつ終わるのか誰にも全く検討がつかないからです。
でも、その片鱗を掴む事はできます。
見えてるタスクをこなした先に発見する「新たに浮上したタスク」がそれです。
「新たに浮上したタスク」とは、「その時点では見えないタスク」が認識可能になった、見えるようになったタスクと言えるでしょう。
見えないタスクは大きさを把握できませんが、それでも1つずつ発見してこなしていけば全体は小さくなっていくはず。
なので例えば新たに浮上したタスクを2つ明示すると、見えないタスクは確実に2つ減ります。
すなわち理想の状態に2歩近づくわけです。 現実と理想の図その2 「1つのタスクをこなしているうちに2つのタスクを見つけた。」
は、登録しているタスク数は増えているので1歩進んで2歩下がっている気がしますが、実際には「1歩進んでさらに2歩進めるチャンスを得た」とも言えるわけです。
なので新たな問題が見つかった時は前向きにタスク化し、その時担当しているタスクの素早い消化に専念するよう心がけています。

まとめ

  • README を充実させる
  • エンジニアが自分1人でもタスクを明示する
  • タスクはできる限り細かく分解する
  • 新たに見つかった問題はノールックでタスク化する
参加した時に1人であろうと複数人であろうと、上記を心がけておくと複数人開発へスライドしやすくなります。
というわけで DRIP では共に働いてくれるメンバーを募集中です！

さいごに

明日は Smith さんの記事です。

関連記事