概要と結論

背景: Excelでの「静的な資料（ストック）」と「動的なタスク（フロー）」の混在により、情報の迷子や定例会議の肥大化が深刻化。
解決策: 新規ツール（Jira等）の予算・稟議コストを回避し、既存のGitLab Issueへタスク管理を完全移行。Scoped Labelsを用いた状態定義により、進捗をリアルタイムに可視化。
結論: 運用を「Working以外（停滞・完了確認）」のフォローに特化させた結果、定例会議の報告時間を大幅に削減し、本来議論すべき課題解決に集中できる環境を実現。（※現在検討段階。後日追記予定）

1. はじめに：なぜ「Jira」ではなく「GitLab」なのか

タスク管理の脱Excelを検討する際、真っ先に候補に挙がるのはJiraかもしれません。しかし、現場には高い壁があります。

予算の壁: 新規ライセンス費用の確保。
稟議の壁: 開発部門以外でのツール導入に対する社内承認の手間。
導入速度の壁: 環境構築やアカウント管理の調整。

そこで、すでに社内でリポジトリ管理として運用されていたGitLabに白羽の矢を立てました。Office 365（Planner等）も候補に挙げて検討しましたが、エンジニアにとって最も馴染みがあり、追加コストゼロで即座に始められるGitLab Issueこそが、今回の「業務改善」の最適解と考えました。

2. 背景：Excel管理で直面した2つの本質的課題

Excelでの管理は長年の慣習でしたが、気づけば以下のような場面が日常になっていました。

「あのタスク、誰が担当だっけ？」——担当者が明記されていたはずのセルが空白のまま、後から発覚する。
「あの件、どう決まったんだっけ？」——会議で口頭決定したことがExcelに反映されておらず、翌週また同じ議論が始まる。
「期限、来週だったよね？」——セルに日付は書いてあるが、自動でアラートが来るわけでもなく、気づいたら過ぎていた。
「えーと、このタスクどこまで進んでたっけ……」——定例でタスクを確認する際、経緯や今後の方向性がExcelに書ききれておらず、担当者も上長も状況を思い出すところから始まる。

これらは個人の注意力の問題ではなく、ツールの構造的な限界でした。突き詰めると、以下の2点に集約されます。

① ストック情報とフロー情報の混在

Excelファイルの中に、性質の異なる情報が混ざり合うことで情報の鮮度が失われていました。

ストック（静的）情報: 仕様、基本構成、過去の議事録など。
フロー（動的）情報: 日々変化するタスク、進捗状況、期限、未解決の課題。

これらが一つのブックに混在し、「最新の状況」が埋もれて判別不能になっていました。

② タスク管理ツールとしての機能的限界

表計算ソフトを無理にタスク管理に転用した結果、以下の運用不備が発生していました。

視認性の欠如: 担当者や期限がセルに埋もれ、アサインの偏りや期限漏れが防げない。
結論の揮発: タスクをクローズしても「最終的にどう決まったか」のログが残らず、後から振り返る際に再調査が必要になる。
プロセスのブラックボックス化: セルの外（口頭やチャット）で行われた議論の背景が見えない。

3. 改善策：GitLab Issueへの役割分担と設計

Excelを捨てるのではなく、「資料（ストック）」はExcel/Wikiへ、「タスク（フロー）」はGitLab Issueへと役割を明確に分離しました。

① ラベルによる「状態」の排他管理（Scoped Labels）

GitLabの :: を使ったラベルを活用し、一つのIssueに複数の状態が混在しないように設計。

ラベル名	状態の定義
`workflow::backlog`	準備完了: やることは確定。あとは着手を待つだけ。
`workflow::working`	着手中: 現在リソースを割いているタスク。
`workflow::blocking`	課題あり: 外部要因や技術課題で手が止まっている（要フォロー）。
`workflow::reviewing`	完了確認: 作業終了。上長やチームの確認待ち。

ポイント: ラベルなしの「Open」は「未整理のメモ」とし、週次定例会議で精査したものだけを backlog へ昇格させることで、タスクの質を担保。

※Scoped Labelsの自動排他制御はEnterprise Edition (EE)の機能です。CE環境では、同一スコープのラベルを手動で貼り替えるルール運用で代替しています。

② 業務性質の分類（Typeラベル）

type::request（外部からの依頼・差し込み）
type::improvement（自発的な改善）
type::maintenance（保守・定常業務）

4. 運用：定例会議を「例外管理」の場へ変える

Issue Boardイメージはこのような状態になります。

ステータス更新（各自・リアルタイム）

自分のステータス変更は、気づいた瞬間に本人がラベルを貼り替えます。特に「止まった（blocking）」ら即座に可視化し、非同期での助け合いを促します。

定例会議のアジェンダ（チーム・同期）

Issue Board（カンバン）を投影し、「Working以外」を徹底マークします。

reviewing のクローズ: 全員で最終確認し、その場でClose（結論を確定）。
blocking の救済: なぜ止まっているかを確認し、ボトルネックを排除。
backlog / Open の整理: 次に着手するタスクの優先順位を決定。

※順調な working は、ボード上で動いていることが見えれば、あえて報告・議論はしません。

5. おわりに

本記事を執筆している時点では、この運用設計はまだチームへの提案段階です。

高価なツールを導入する前に、今ある資産（GitLab）を「再定義」するだけで、Excel管理から解放される第一歩は踏み出せます。設計を言語化するプロセス自体が、「自分たちの定例会議が何のために存在するのか」を問い直す機会にもなりました。

同じ課題を感じているチームの参考になれば幸いです。提案・運用の結果は、後日このセクションに追記します。