【工数増２原因とは？】チームワークで課題解決【４例】

はじめに

個人開発とチーム開発の最大の違いは何か？それは「コミュニケーションコスト」だと思います。

プロジェクトに参画して数ヶ月、工数がかかっている箇所を観察してみると、多くが「認識のズレ」「情報の散らばり」「手動作業の繰り返し」に起因していました。

この記事では、実際に取り組んだ工数削減の施策を、失敗談も含めて記録しておきます。

工数がかかる2大原因

現場を見ていて気づいたのは、工数増大の原因は大きく2つに分類できるということです。

1. コミュニケーション不備

• 決まった内容が口頭やSlackで流れるだけ
• 新規参画者が同じ質問を何度もする
• 仕様変更の経緯が追えない

2. 自動化できていない作業

• 毎回手動でデプロイ作業
• テストを手動で実行
• 定型的なコード記述の繰り返し

どちらも「チーム全体で毎日発生する小さなロス」なので、放置すると膨大な工数になります。

実践例1: 環境構築の手順書作成

課題の発見

新しいメンバーがジョインするたびに、環境構築で半日〜1日かかっていました。しかも毎回、既存メンバーに質問が飛んでくる状態。

「前回もこの質問あったな...」と感じることが増えてきたのがきっかけです。

実施内容

まずSlackで過去の環境構築に関する質問を検索。よくある質問TOP5を洗い出しました。

よくある質問:
・Node.jsのバージョンは？ → 18.17.0
・データベースの初期データはどうする？ → seedファイル実行
・環境変数はどこに？ → .env.sampleをコピー
・ローカルのポート番号は？ → 3000(フロント)、8000(API)
・認証のテストユーザーは？ → [e-mail] / password123

これらを踏まえて、READMEに以下の構成で手順書を追記:

## 環境構築手順(初回のみ)

### 1. 必須環境
- Node.js 18.17.0 (それ以外だとビルドエラーになります)
- PostgreSQL 14.x

### 2. セットアップ
# リポジトリクローン後
npm install

# 環境変数ファイル作成
cp .env.sample .env

# データベース作成
npm run db:create
npm run db:migrate
npm run db:seed

### 3. 起動確認
npm run dev

# ブラウザで http://localhost:3000 を開く
# ログイン: [e-mail] / password123

### トラブルシューティング
Q. npm installでエラーが出る
A. Node.jsのバージョンを確認してください(18.17.0)

Q. データベース接続エラー
A. PostgreSQLが起動しているか確認 & .envのDB設定を確認

結果

• 新規参画者の環境構築時間: 1日 → 2時間に短縮
• 既存メンバーへの質問: 1人あたり5〜6回 → 0〜1回に減少

重要なのは「自分で勝手に作らなかった」ことです。まずSlackで「環境構築の手順書を整備したいんですが、過去につまづいた点あれば教えてください」と投げかけ、チームメンバーの経験を集約しました。

実践例2: Slack情報の一元化

課題の発見

「あの仕様、どこで決まったんだっけ?」という会話が頻発。Slackを遡るのに毎回10分以上かかることも。

特に、APIの認証方式やエラーハンドリングのルールなど、「プロジェクト全体で統一すべき決定事項」が口頭で決まってそのまま流れていく状況でした。

実施内容

NotionにMTG議事録テンプレートを作成し、Slackのチャンネル説明欄にリンクを固定。

【決定事項の記録ルール】
・Slackでの議論後、決まった内容はNotionの議事録ページに記載
・記載項目: 日付、参加者、決定内容、背景、却下した案

実際の議事録例:

## 2024/09/15 API認証方式の決定

### 参加者
@田中、@鈴木、@佐藤

### 決定内容
JWT認証を採用。リフレッシュトークンは7日間有効。

### 背景
- セッション管理だとサーバー負荷が心配
- 将来的にモバイルアプリも視野に入れるとJWTが適している

### 検討した他の案
- セッションベース認証 → サーバー負荷とスケーラビリティで却下
- OAuth2.0 → 現時点では過剰スペックと判断

結果

• 仕様確認の時間: 平均10分 → 1分
• 「前に決まったはず」論争: ほぼゼロに

最初は「議事録書くの面倒」という空気もありましたが、「検索1分で済むなら、5分かけて記録する価値ある」と実感してもらえてから定着しました。

実践例3: デプロイの自動化

課題の発見

ステージング環境へのデプロイが完全手動。毎回30分かかり、手順ミスでロールバックも月1回は発生していました。

手動デプロイの手順(Before):
1. ローカルでビルド
2. サーバーにSSH接続
3. gitでpull
4. npm install実行
5. DBマイグレーション実行
6. プロセス再起動
7. 動作確認

実施内容

GitHub Actionsでステージング環境への自動デプロイを構築。

まずチームMTGで「自動化したい作業ランキング」をみんなで出し合いました。

投票結果:
1位: デプロイ作業(5票)
2位: テスト実行(3票)
3位: コードフォーマット(2票)

デプロイが1位だったので、まずここから着手。

実装したGitHub Actionsの構成:

name: Deploy to Staging

on:
  push:
    branches:
      - develop

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18.17.0'
      
      - name: Install dependencies
        run: npm ci
      
      - name: Run tests
        run: npm test
      
      - name: Build
        run: npm run build
      
      - name: Deploy to staging
        run: |
          # SSH経由でデプロイスクリプト実行
          # (実際のコマンドは省略)
      
      - name: Notify Slack
        # デプロイ完了をSlackに通知

結果

• デプロイ時間: 30分 → 5分(自動)
• デプロイミス: 月1回 → ゼロ
• 手動作業からの解放: チーム全体で月20時間削減

ポイントは「いきなり本番環境から始めなかった」ことです。まずステージング環境で試して、1ヶ月運用してから本番環境にも適用しました。

実践例4: コードレビュー観点の明文化

課題の発見

レビュー指摘が人によってバラバラ。「前回はスルーされたのに今回は指摘された」という状況が発生していました。

特に新規参画者は「何に気をつけてコード書けばいいかわからない」状態。

実施内容

過去3ヶ月のPRレビューコメントを集計し、頻出する指摘TOP10をリスト化。

頻出レビュー指摘:
1. マジックナンバーの使用(15回)
2. エラーハンドリング不足(12回)
3. 関数名が不明瞭(10回)
4. コメント不足(8回)
5. ネストが深い(7回)
...

これを元に「レビュー観点チェックリスト」をPRテンプレートに追加:

## レビュー前セルフチェック

- [ ] マジックナンバーを定数化したか
- [ ] エラーハンドリングを実装したか
- [ ] 関数名は処理内容を表現しているか
- [ ] 複雑な処理にコメントをつけたか
- [ ] ネストは3階層以内か

## 動作確認

- [ ] 正常系の動作確認
- [ ] エラー時の動作確認
- [ ] 既存機能への影響確認

結果

• レビュー指摘の往復: 平均3回 → 1.5回
• 新規参画者のPRマージまでの時間: 平均3日 → 1.5日

チーム全員で「どういう観点を大事にするか」を話し合ったことで、暗黙知が形式知になりました。

改善活動で大切にしていること

1. 一人で勝手にやらない

最初にやりがちなのが「良かれと思って一人で改善して、使われない」パターン。

必ずチームに相談してから動くようにしています。

悪い例:
「デプロイ自動化しました!使ってください!」
→ 誰も使い方わからず放置

良い例:
「デプロイ作業、毎回30分かかってるので自動化したいです。
 まずステージング環境で試してみて、使いやすければ展開でOKですか?」
→ チーム合意の上で進められる

2. 小さく始める

完璧を目指して大規模に始めると、挫折します。

「ドキュメント整備」なら、まずREADMEの環境構築だけ。
「自動化」なら、まずステージング環境のデプロイだけ。

小さい成功体験を積み重ねることで、チーム全体の改善文化が育ちます。

3. 数字で効果を測る

「なんとなく良くなった」ではなく、数字で示す。

• 環境構築時間: 1日→2時間
• レビュー往復: 3回→1.5回
• デプロイ時間: 30分→5分

数字があると、次の改善提案もしやすくなります。

まとめ

チーム開発での工数削減は、技術力だけでは達成できません。

• 「何が課題か」を観察する力
• 「チームに提案する」コミュニケーション力
• 「小さく試す」実行力

この3つがあれば、どんな現場でも改善は進められると感じています。

「工数を削減するには?」という観点で現場を見てみると、意外と改善できることは多いです。

この記事が、同じようにチーム開発で試行錯誤している方の参考になれば幸いです。