SMARTCAMP Engineer Blog

スマートキャンプ株式会社(SMARTCAMP Co., Ltd.)のエンジニアブログです。業務で取り入れた新しい技術や試行錯誤を知見として共有していきます。

スクラム管理を楽にしたくてツールを内製化しはじめた話

こんにちは!スマートキャンプでエンジニアインターンをしている中田です。 昨年の11月からインターンを始め、BOXILの開発に携わっています。

BOXIL開発チームでは、毎月一度「薪入れ」と称した開発改善の日を設けています。 薪入れは、普段の業務で後回しになってしまっている箇所のリファクタリングなど、技術的な改善をしていくことを目的に実施しています。

昨年度末には、その薪入れの拡張版として、いつもより長めの12/28~12/30の3日間をかけて年末開発改善を実施しました。

年末開発改善で取り組んだ内容は以下のとおりです。

  • スクラム管理ツールの内製化
  • Cloudflareの調査
  • CoffeeScript->TypeScriptへの置き換え など

本記事では上記の年末開発改善での取り組みの中から、僕を含め入社1年未満のメンバー3人で取り組んだ、「スクラム管理ツールの内製化」での実施内容について紹介します。

スクラム管理ツールの内製化

目的

弊社の開発チームでは、開発手法としてスクラム開発を採用しています。

※ スクラムの定義や用語についてはスクラムガイドをご参照ください。

これまで弊社では、スクラムの各スプリントの稼働予定やポイント消化率などをスプレッドシートへ手動でマッピングして管理していました。(下図)

f:id:kiki_ki:20210118134902p:plain
スプリント情報管理シート(各チーム)

f:id:kiki_ki:20210118135036p:plain
各チームのスプリント情報を統合したマスタシート

※ 図のデータにはダミーを入れてます

このようなスプレッドシートを使用した管理方法には、以下のような問題点を感じていました。

  • 過去データの整理が煩雑な点
  • 分析用として過去のスプリントのポイント消化数をグラフ化しているものの、細やかな分析がしづらい点
  • Asanaでタスクと消化ポイントの管理をしているが、 スプレッドシートへポイントを別途入力しなければならない点

上記の問題点を改善するべく、新たにツールを内製化することにしました。

仕様

先述の問題点を踏まえ、内製化するツールの仕様を検討しました。

# --- ユーザー管理・設定機能 ---
## ユーザー管理
- 登録
- ログイン
- アドミン権限
- ユーザーのグルーピング
- スプリント期間の変更
## 設定
- ユーザー設定
- 名前
- 表示設定

# --- メインの表示・入力機能 ---
## スプリント
(入力)
- 予想稼働時間(手動入力 or GoogleCalendarから取得?)
- 実稼働時間(手動入力)
- 予定消化ポイント(手動入力 or Asanaから取得)
- 実消化ポイント(手動入力 or Asanaから取得)
- 稼働阻害要因(手動入力)

# --- 分析機能 --
- 各スプリントでのサマリ(実消化ポイント, 実稼働時間)
↑ を全体・チーム・個人でフィルタして表示

- グラフ化(実消化ポイントの変遷, 実稼働時間の変遷)
- 予測(稼働時間から予測する消化ポイント)

スプレッドシートでの管理・運用方法をベースに、入力の煩雑さを減らし、分析機能をリッチにしたツールを目指します。

※ 実装にあたるのがメンバー3人なので、3日間で出来ても設定・入力機能までだろうという目論見でした。分析機能などは後々補填していく想定です

実装

DB構造

まず、決定した仕様をもとにDB構造を検討しました。

f:id:kiki_ki:20210114175045p:plain
DB構造

各テーブルはそれぞれ、以下の役割を担います。

- Companies:企業の情報を持つ
- Projects:プロジェクトの情報を持つ
- Teams:チームの情報を持つ
- Users:ユーザーの情報を持つ
  - TeamUsers:Teams - Usersの中間テーブル(ユーザーの複数チームを跨いでの所属を考慮)
- Sprints:プロジェクト単位のスプリント情報を持つ
  - TeamSprintHistories:チーム単位のスプリント情報を持つ
  - UserSprintHistories:ユーザー単位のスプリント情報を持つ
アプリケーションの実装

次いで、アプリケーションの実装に入りました。

アプリケーションの技術構成は以下の通りです。SPAで開発しました。

  • フロント:Vue.js(HTTPライブラリ: Axios, UIライブラリ: Element UI, Router: Vue Router)

    • 選定理由:弊社の既存サービスで利用していることもあり、素早く実装できそうだったため。
  • APIサーバー:Golang(Framework: Gin, ORM: Gorm)

    • 選定理由:会社でも今後積極的に採用していこうとしている言語であり、個人的にも最近学習していた言語だったため。

また、以下の役割分担で開発を行いました。

  • フロントエンド:2名(設定画面の人とスプリント管理画面の人)
  • バックエンド:1名

結果

1日目はほとんど環境構築で終わり、2日目から機能の実装に入りました。

最終的な進捗は以下の通りです。

  • フロントエンド

f:id:kiki_ki:20210115123829p:plain
ログイン画面

f:id:kiki_ki:20210115123856p:plain
プロジェクト選択画面

f:id:kiki_ki:20210115122100p:plain
プロジェクトの設定画面

f:id:kiki_ki:20210115054149p:plain
スプリント管理画面

  • バックエンド
    • モデリング
    • JWTを用いた認証機能の実装
    • プロジェクト設定関連のAPIの作成

フロントエンドは 認証/プロジェクト設定/スプリント管理 周りの開発を終え、バックエンドは 認証機能/プロジェクト設定 周りのAPIの実装ができました。スプリント管理周りのAPIの作成・繋げ込みには至らず、少々物足らずな進捗となりました。

今後

まずは、今回の年末開発改善内で実装が終わらなかったスプリント周りのAPIの実装を進めていきたいです。ここまで終えると、一旦スプレッドシートでの管理と同様のことが可能になる想定です。

その後、実際にアプリケーションを運用してスプリントのデータを貯めていきつつ、機能的にリッチにしたい部分(分析周り、Asana/Google Calenderを連携して自動入力)の開発や、スプレッドシートで持ってる既存データの移行などを進めていきたいと考えています。

おわりに

今回は年末開発改善で取り組んだ「スクラム管理ツール内製化の試み」について紹介しました! 普段業務で使用していないGolangでの実装など挑戦的なこともしており、個人的にも良い経験となりました。

以前の管理方法での問題点の解決に加えて、色々と痒いところに手が届いたツールとして機能させたいので、今後もしっかり開発したいと思います!


参考

https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf