こんにちは、商品開発部のつちだです。
昨年、少人数でチームを組み機能開発を行いましたので、その内容について書かせていただきます。

 

開発した機能について

開発した機能は、弊社がすでにお客様へ提供しているシステムの追加機能でした。
ただ、機能としては外部システムとの連携部でほぼ別アプリであったため、
構成・開発内容としては以下のような形となりました。

 

•  開発内容
  • 既存システム：連携API新規開発
  • 新規アプリケーション開発(フロントエンド)
  • 新規アプリケーション開発(バックエンド)

 

開発体制について

タイトルにもあります通り、今回の機能開発は少人数チームを組んでの開発となりました。
メンバーは3人、いずれも開発経験4年以下のメンバーで構成されています。

 

• つちだ （わたし）
  • プロジェクトリーダー
  • 外部との連絡担当
  • システム全体構成・仕様決定
  • インフラ担当
• りょっけ
  • フロントエンド担当
  • バックエンド担当
• さっきー
  • バックエンド担当
  • 既存システムへの機能追加
  • 検証リーダー

 

開発歴が短いメンバーでの構成でしたので、
技術的難題については、社内有識者の力も借りながらの開発となりました。

 

開発の進め方について

開発手法

開発手法は「スクラム方式」を取りたかったのですが、メンバーが少ないことや
そもそも開発プロジェクトがリリースを続けていくものではなかったため、
今回は「スクラム方式」を参考にした開発手法をチーム内で検討し、進めていくことにしました。

実施した内容を以下に記載します。

 

準備

開発プロジェクトが始まるまでに実施したことを説明します。

プロダクト・バックログ → やるべきことリストの作成

事前に決めておいたシステム設計を元に実現までに”やるべきことリスト”をカードとして作成しました。

カード化した”やるべきことリスト”はツールに登録していつでも確認できる状態にしておきます。

“やるべきことリスト”の粒度は少し曖昧ですが、「成果が見えるレベル」としました。

 

例えば、「○○ページのUI実装」「○○ツールの作成」といった具合です。

ただし、初期構想時作成した”やるべきことリスト”は開発を進める上で

変わって行くものであるという大前提があります。

（そもそもシステム設計自体に不備があるかもしれないからです。）

ルールの確認

準備を終え、本格的に開発に入る前にチーム内で進め方のルール確認を行いました。

 

開発期間中

開発プロジェクトが実際に走り始めてから実施したことを説明します。

スプリント

今回の開発では、スプリントを1週間と定めて実施しました。

 

ちなみに、1週間の区切りは毎週水曜日AMです。

水曜日AMにした理由は、月曜日や金曜日は祝日で休みになることが多いこと、後は気持ちの問題でした。

中だるみしがちな水曜日に一週間の目標設定をすることで、

タスクに対するモチベーションを高めようとチームで決定しました。

 

水曜日AMは最短1時間、最長で2時間の会議を設定し、以下のことを実施します。

• 1週間の振り返り
• 1週間を振り返った時の疑問点/問題点の共有
• 次の1週間のタスク共有(開発外)
• やるべきことリストより次の1週間分のカード選択（スプリント・バックログ）
• やるべきことリストの内容を実現するためのタスクの割り振り
  • タスクはツールに登録します。ここで初めて担当者が設定されます。
• (必要に応じて)やるべきことリストの見直し

タスク

水曜日の会議で各自1週間分のタスクが割り振られたら、そのタスクを各自でさらに細かく分けていきます。

今回はこれを区別をつけるために個人タスクと呼びます。

 

個人タスクはツールに登録してもいいし、登録しなくてもよいとしました。

ただし、分け方だけにはルールがあります。

それは、「個人タスクは一日以内で必ず終わる範囲で切る」ということです。

2日以上にまたがる切り方は禁止です。大きく切りすぎると進捗が把握しにくくなる、というのが理由になります。

日々の進め方

私たちは毎日以下の2つのことを行いました。

朝：実施するタスクの共有

夕方：当日の進捗報告と問題の共有

一週間の流れ

タスクが終わったら・・・

1週間経たないうちに自分に割り振られたタスクが完了した場合でも、

新しいタスクを割り振ることは基本的にはしません。

メンバーの所持しているタスクを確認し、カバー出来る内容があれば、それに取り組みます。

全員で水曜日に決めた”やるべきことリスト”の内容を完遂出来るようにするためです。

このタスクの調整についても夕方のＭＴＧで行いました。

コードレビュー

コード管理はGitを利用しました。

最初はコンフリクトを防ぐためにコードのプッシュ報告(テキストベース)を行っていましたが、

せっかく報告するなら利用しない手はないと思い、コードレビューを開始しました。

 

ツールに「気づいた人」「対応者」「状況」「ファイル名」「行数」「内容」「コメント」を記録し

チームメンバー全員で相互に確認することで、”見られる”ことを意識したコーディングにつながったと思います。

 

気を付けたこと

全体進捗を意識する

すでに出来上がったシステムとは違い、
リリース後の利用状況を確認したりすることが出来なかったため、
１週間の振り返りでは「どこまで出来ているのか」という部分を意識しました。

設定した”やるべきことリスト”が達成できなかったら・・・

1週間のうちにやると決めた内容が終わらなかった場合、「なぜ達成出来なかったのか」を意識しました。

カードが多すぎたのか、緊急の用事が多かったのか、問題点が出てきたのか・・・

理由は様々ですが、振り返りを行いました。

メンバーのスキル把握

一人一人得意なこと、苦手なことがあると思います。

それを全員が意識した上で、タスクの割り振りを行いました。

 

開発の進め方の見直し

今回と同じメンバー構成で開発を行ったのは2回目で、

実は1回目の時も同じような方法をとっていました。

 

しかし、前回は個人に割り振った後のタスクの切り方、報告の仕方を任意にしていたことで、

週間の進捗状態が上手く把握出来ず、開発プロジェクト全体の進捗へ影響を与えるという問題が起きていました。

 

2回目となる今回は、上述の問題の解消策として

「個人タスクは一日以内で必ず終わる範囲で切る」というルールと

朝の作業報告は「タスク＞個人タスク」のカテゴリで報告するというルールをチームで決め、実行しました。

 

最初はタスクの切り方が細かくなり手間に感じる部分もありましたが、

徹底して行うことで問題が解消したことはもちろん、報告されるタスクの粒度が落ちることで

エンジニア間の技術共有やカバーのしやすさの向上、コードをプッシュする際のコメント記載内容の詳細化へつながりました。

 

本家スクラムでも開発サイクル自体の見直しを行うフェーズがありますが、そのフェーズの大切さを実感した瞬間でした。

 

今後の課題について

開発プロジェクトに納期はつきものです。今回の開発も例外ではなく、納期が定められていました。

納期が定められているということはリリースまでに

完了出来るプロダクトバックログの数も決まっているということになります。

それをふまえて考えたとき、個人的に課題であると感じた部分はプロダクトバックの重みづけでした。

 

今回は新規機能のリリースでしたので「やるべきことリスト」という形で

要件を満たすために必要な項目に絞り、最低限必要な項目以外を「保留」に設定しました。

 

しかし、今後運用を続けて行くと

それぞれのプロダクトバックログに細かく優先度をつけて選択していく必要が出てきます。

今回の開発方法ではその観点が抜けていたため、バージョンアップの開発プロジェクトでは

その点について細かく考えていきたいです。

 

最後に・・・

今回は少人数でチームを組んで開発に取り組んだ内容を書かせていただきました。

正直、まだまだな部分が多いと思います。

 

ですが、「目標に向けてチームで取り組み、リリースまで走ることが出来たこと」

「チーム内で進め方を共有、共に試行錯誤することが出来たこと」

そういった経験は今後につながるものがあると感じています。

 

今回の経験をもとに、今後もさらなるブラッシュアップを続け

精力的に開発に取り組んでいきたいと思います。

 

 

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆

現場サポートは、エンジニアの募集を行っております。
興味をもっていただいた方は、ぜひこちらもご覧ください(^^)/
https://recruit.genbasupport.com/career/

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆