はじめに：バラバラだった私たちの「日常」
多くのエンジニア組織において、開発、運用、SRE、あるいは社内SEといった役割が分断され、それぞれのチームが独自のツールと独自の文化で動いていることは珍しくありません。私たちがかつていた環境も、まさにそのような「サイロ化」の典型でした。
「誰が何をしているのかが見えない」「あの作業は誰の担当なのか」「なぜあのチームばかり忙しいのか」。こうした疑問が飛び交う会議室。業務領域が広がるにつれ、チーム間の連携は希薄になり、情報の非対称性は限界に達していました。そして、その不透明さは、エンジニアにとって最もモチベーションを削ぐ「人事評価の不公平感」へと直結していたのです。
本記事では、私たちがどのようにしてタスクを見える化し、バラバラだったチームを一つの有機的な組織へと変貌させたのか。そして、その過程でいかにしてエンジニアが納得できる、客観的で公平な評価制度を構築したのか、その軌跡を共有します。
「見えない」が招く組織の疲弊
かつての私たちのチームでは、タスク管理が属人化していました。あるチームはJiraを使い、あるチームはExcelで管理し、またあるチームは個人の付箋でタスクを管理していました。
この状況がもたらす弊害は深刻でした。
第一に、ボトルネックの所在が不明確であること。SREがインフラの改善に追われている横で、開発チームがリリーススケジュールを詰め込んでいる。互いの状況が見えないため、「なぜ協力してくれないのか」という不信感が募ります。
第二に、貢献の可視化が困難であること。エンジニアリングの価値は、往々にして「トラブルを未然に防いだこと」や「コードの保守性を高めたこと」といった、目に見えにくい部分に宿ります。しかし、可視化の仕組みがないと、どうしても「派手な新機能を作った人」だけが評価されがちです。これが、地道な改善を支えるメンバーの離職を招く原因となっていました。
タスクの「共通言語化」への挑戦
変革の第一歩は、ツールの統一ではなく「タスクの共通言語化」でした。私たちは、業務を「プロジェクト」「運用保守」「技術負債の解消」「自己研鑽」の4つのカテゴリーに分類し、すべてのタスクを一つのカンバンボードで管理することに決めました。
ここでのポイントは、単にツールを揃えることではなく、「工数と価値の定義」を全チームで合意することでした。
例えば、突発的な障害対応であっても、それは単なる「作業」ではなく、「システムの信頼性を守るための投資」として記録を残す。技術負債の解消も、将来のコスト削減という観点から、新機能開発と同等の優先度でタスク化する。
この取り組みにより、チームメンバーは「自分の作業が組織のどの目標に紐付いているのか」を意識するようになりました。バラバラだったチームが、同じボードを見ながら、「今、組織全体の優先順位はどこにあるのか」を議論できるようになったのです。
見える化がもたらした「心理的安全性」の向上
タスクが可視化されると、驚くべき変化が起こりました。それは、「助け合い」の自発的な発生です。
あるチームが急なトラブル対応で手一杯なとき、別のチームのメンバーが「このタスクなら自分が巻き取れるかもしれない」と手を挙げるようになったのです。これは、タスクが可視化され、負荷状況が誰の目にも明らかになったことで、「誰が困っているか」が可視化された結果です。
心理的安全性の向上には、透明性が欠かせません。「あの人は何もしていない」という無根拠な疑念が消え、「あの人は今、これだけの負荷を抱えて戦っている」というリスペクトに変わる。この文化の変化こそが、組織を強くする最大の武器となりました。
人事評価の公平性をどう実現したか
多くのエンジニアが抱える「評価への不満」。これを解消するために、私たちは「タスクの可視化データ」を評価の補助材料として活用する仕組みを導入しました。
従来の評価は、マネージャーの主観や、期末の面談でのアピール力に左右されがちでした。しかし、私たちは以下のプロセスを導入しました。
1. **タスクの分類と重み付け**: 各タスクに「難易度」と「組織へのインパクト」をタグ付けする。
2. **振り返り（Retrospective）の定着**: 2週間ごとのスプリント終了時に、完了したタスクだけでなく「なぜそのタスクが重要だったのか」をチームで言語化する。
3. **客観的エビデンスの活用**: 評価面談では、ツール上に蓄積されたタスクの履歴を元に、「どのような課題を、どのような技術的アプローチで解決したか」を時系列で確認する。
これにより、地味なインフラ改善や、トラブルの未然防止といった「見えにくい貢献」が、明確なデータとして上長に伝わるようになりました。「やって当たり前」と思われていた運用業務が、実はビジネスの安定稼働にどれほど寄与しているかが可視化されたことで、メンバーの評価に対する納得感は劇的に向上しました。
技術と人間系、両面からのアプローチ
もちろん、すべてが順調に進んだわけではありません。ツールへの入力負荷を嫌うメンバーもいましたし、最初は「監視されているようで嫌だ」という反発もありました。
これを乗り越えるために意識したのは、「ツールはメンバーを管理するためのものではなく、メンバーの価値を証明するためのものである」というメッセージを徹底することでした。
マネージャー自身が、メンバーのタスクを「監視」するのではなく、ボードを見て「このタスクは大変だったね、どうサポートすればいい？」と問いかける姿勢を見せること。この信頼関係の構築こそが、可視化を成功させる鍵です。
おわりに：一つのチームとして、次なるステージへ
現在、私たちの組織は、かつてのバラバラなチームの集合体ではありません。インフラ、開発、運用という壁を越え、一つの目標に向かって自律的に動く「ワンチーム」へと進化しました。
タスクの可視化は、単なる効率化の手段ではありません。それは、エンジニア一人ひとりの営みを尊重し、その貢献を正当に評価するための「誠実さの証明」です。
もし、あなたの組織が「誰が何をしているか分からない」「評価が不透明でモチベーションが上がらない」という悩みを抱えているなら、まずは小さな一歩から「タスクを一つに集めること」を始めてみてください。そこから見える景色は、確実に変わります。
エンジニアリングの価値を最大化し、誰もが誇りを持って働ける組織を作る。そのための道のりは平坦ではありませんが、得られる成果は、エンジニアとして働く私たちにとって何物にも代えがたい財産になるはずです。
コメント