はじめに
今回新しく参加した案件で、設計が終了するまでの余裕があったため
ソース・プロジェクトの管理環境構築を担当することになりました。
別チームで使用していたredmine・GitLabを導入しましたが、
同じ社内でもプロジェクトごとにルールが異なっていたことから、
Redmine・GitLabを初めて使用する方向けに機能概要から思ったことまでまとめました。
機能概要
Redmine
プロジェクトに関するあらゆる情報を管理可能。
イメージとしてはExcelでのスケジュール管理+Todo等のタスク管理+情報Wikiの統合管理ツール。
CSVから項目を選び一括タスク登録できるため、Excelデータを加工→取り込みで移行できる。
ブラウザを使用しで上記の閲覧・絞り込み・分析が完結できるため作業効率化・PCの負荷軽減が可能。
ガントチャートを使用すると、各タスクの進捗別グラフが確認できます。
GitLab
gitのコミットログ・現在のリポジトリ状況を確認可能。
レビュー実施・差分確認・ブランチ確認等のソースに関するあらゆるチェックが可能。
ソース差分に行単位でコメントをつけられるため、「この行がおかしい」等の指摘がすごく楽にできます。
Sourcetree等のツールはコミット単位の確認をする際に便利ですが、
GitLabの場合ブラウザで複数ページを開くこともできるため、プロジェクトの俯瞰に便利です。
Redmine + GitLab
Redmine側でソース以外の情報管理、GitLabを使用することでソースの状況管理を実現しています。
今回使用はしていませんが、GitLabのプッシュ履歴をRedmineに反映するプラグイン(※1)も存在します。
GitLabのコミット履歴からチケットに1クリックでアクセスできるので便利ですが、
結局ステータスを変えたい場合、Redmineで各項目を手動で変更する必要があったため導入しませんでした。
※1：GitLabのExternal issue trackerを有効にし、GitLabからRedmineの関連チケットにリンクが張られるようにする
導入してみて思ったこと
メリット
・情報が集約できるので、Redmineを確認するように意識付けるだけで
「環境構築」「案件の仕様理解・ドキュメント配置」「個別タスク把握・進捗管理」まで完結できます。
・ブラウザで完結できるため複数ウィンドウを探す手間をなくし、PCの負荷を軽減します。
・両ツールとも自社サーバーで管理可能なことから、Webサービス利用が難しい際にも導入しやすい。
デメリット
・情報が多くなればなるほど初期の情報登録が大変になるので、あくまで大人数向けであること。
→初期人数が少ないが後に追加人員等が見込まれるタイプのプロジェクトであれば、
早く作れば早く作るほどチーム全員でメンテできるため便利になっていく(Redmine)
・レガシーな環境であればあるほど「Excelじゃダメなんですか？」が発動する
→ガントチャート(進捗の棒グラフ)を使用しての進捗管理は全員が入力しないとあまり意味をなさず、
参加者が少ないほどRedmineを使用するメリットが薄くなる。(Redmine)
・構築が少しめんどくさいため、セキュリティと天秤にかける必要がある。
→一番楽に構築するとしてもDocker知識は必要になるので、1から導入する場合少し面倒。
JIRA・Excel・GitHubのように環境構築なしで利用できるツールがあるため、
各管理ツールの比較記事等を確認し(※2-1,2)プロジェクトに合ったものを採用する必要がある。
※2-1：グッと時間を削減できるオススメのプロジェクト管理ツール７選
※2-2：GitLabに触ってみて、GitHubと比較した
課題と改善点
問題1：そもそも最初に使ってもらうことに苦労する
最初に自分がRedmineを使用したチームでは「まず案件に入ったらRedmineを見て開発を開始してね」
というルーティンが確立されていましたが、初めて導入したプロジェクトでは誘導に苦労しました。
改善案1：案件に新規で入るメンバーが困ったら見られるような場所にする
→「～書類の最新はここに入る」「ブランチ名等開発ルールはこれ」「ツール配置はサーバーのここ」等の
入場してから探して分かった情報を一括でwikiに纏めました。以降入ってきた方には
Redmineを確認してもらうことで情報の一貫性をもたせるメリットを付加しながら
Redmineの利用度を上げることができました。
改善案2：タスクを作成するフェーズを絞り最小構成の導入にする
→そもそも完全初期から参加していない限り、管理ツールの作成は余裕があるメンバーが実施することになり
ツール運用可能になったときはどこかのフェーズの中盤ということも珍しくないと思います。
その際「Redmineのタスク振り分けを行ったので、開発からでいいので入力をしてほしい」等
共有していくことによりチームメンバーへの意識付けをしていくことが重要かと思います。
問題2：進捗率の粒度が大きすぎたため、ガントチャートがいまいち機能していなかった
ガントチャートの機能では、開始日・終了日間を進捗率でグラフ表示することで遅延状況を確認できます。
(別途折れ線グラフで遅延も視覚化できるため人数の多いPJであれば便利)
進捗率はチケットごとにステータスに紐付く形で設定が可能ですが、
現在のRedmineが「作業開始(10%)→作業終了(80%)→レビュー中(90%)→完了(100%)」の設定だったため
％が飛びすぎてあまり実用性がありませんでした。
改善案：既存Rの進捗粒度が想定と異なる場合、別に建てることを検討する(設定が共有されてしまうため)
→Redmineの初期設定時に進捗率とステータスを紐付けて設定することが可能です(※3)。
部署等を跨ぐと設定基準等が異なるため(今回はこのパターンでした)、別のRedmineを作成することを
検討したり、製造・単体テスト・レビュー等チケットを細かくする方法も必要であれば実施します。
チケット増の場合管理工数が増えてしまうので、知識もつくことからRedmineの複製がおすすめです。
その他
・チームメンバーのレベルが高い+人数が少ない場合、GitHubでIssue管理(※4)が便利。
進捗の数値等がなくてもコミュニケーションでほぼ完結できるので、コンパクトにチーム管理可能です。
個人で整理した情報を書けるので、コミュニケーションレベルが低い現場でも採用理由にはなるかも。
・Excelを複数開いてスケジュールを見る、進捗についてはスケジュールでなく作業実績のExcelに入っている
複数のウィンドウから目標の資料を探す…みたいなことがなくなるので、
案件参加時に「プロジェクト管理ツールは何を使いますか？」と聞いてみるのがありかもしれません。
カレンダー・タスク管理だけでも作るだけで利便性はかなり高くなります！
・Redmineはwikiとタスクの％、GitLabは行単位でのレビューコメントが個人的にはすごく便利…と思いつつ
GitHubを調べたら同様のことができるらしい。セキュリティルールから判断しても良さそう。
・使っている限りはタスクを作る→消化の流れ自体がウォーターフォール向けなので、
アジャイル等の方式で使えるような物もどこかで使う機会を作りたい。
※4：開発者のタスク管理をGitHubで行ったらうまくいった話
まとめ
・管理ツールは導入序盤にパワーが必要になるが、メンバー追加適応・情報の一元化・負荷軽減とメリットが多い
・構築しなくても使用できるWebプラットフォームも存在するため、ルールに合ったものを選択する