【プロジェクト】プロジェクト管理ツールのチケットは汚してなんぼ
はじめに
対象
- プロジェクトに知見が溜まらなくてお困りの方。
前提条件
プロジェクト管理ツールの種類は豊富で用語が統一されていないため、Redmineの用語で記事を展開します。
ログを全く出力しない困ったシステム
ITエンジニアであれば一度はエラーログの催促や、障害調査時のログ取得を行ったことがあるのではないでしょうか。逆に全くログを出力せず、何が起きているかすら分からないシステムでは、デバッグ用のログを仕込むところから作業しますよね。
ところが世の中には全くログを出力せず、作業の詳細一切不明のシステムが存在します。
人です。
途中参画したプロジェクトでは、機能改修やバグ修正などの業務が発生します。そこで重要になるのが開発者が作業チケットに出力する作業ログです。通常、プルリクエストやGitの履歴からチケットを特定し、どんな作業を行ったのかを確認しに行きます。
真っ白です。
Gitの履歴やソースコードにも理由が書かれていません。というかコミットが汚すぎる上、コミットメッセージにはチケットのタイトルと同じ情報しかありません。
虚無です。
しかもプログラムと違って、後からロガーを設定できません。
終わりです。
作業ログから知れること
Redmineのチケットからは実に様々な情報を知ることができます。
例えばチケットが作成されてから、ステータスが進行中にされるまでの期間。やりたいけれど放置されていたリファクタリングのチケットなのか。何度も開始日が調整されていたヤバいチケットなのか。早急に取り掛かる必要のあるチケットだったのか。温度感が分かります。
障害調査で似たような事例を検索して行き着いたとき、説明や追記に手順が書かれていれば参考にすることができます。当時の担当者が懸念事項を残していて、案の定その通りになったことも。既に調査済の内容であれば、工数を大幅に短縮できます。
機能改修を行う前の事前調査では、一見不要と思しきことも書かれていると助かります。なぜ今の実装やクラス設計にしたのか。そこに至るまでの判断過程で何が決め手になったのか。この開発者はどのような考え方をするのか。自分の修正方針だと問題があると分かることも。
当時のプロジェクトの状況はどうだったのか。変にステータス変更の間が空いていないか。Gitの履歴ではどうか。メンバー全体の業務経験や、仕事の進め方はどうだったか。
残ってさえいれば、様々な作業ログがデバッグを楽にしてくれます。
残ってさえいれば……！
作業ログを読む習慣がないのは危険信号
作業ログを読まないということは、開発であればログを見ないということです。そして作業ログから知れる多くの知見を活用しないということでもあります。非常にもったいないです。
そしてより深刻なのは、読む必要性を感じないということは、書く必要性も感じないということです。多くの過去の作業がブラックボックスと化し、その解体に予想以上のコストを投入しなければなりません。結果として組織全体の生産性を、長期的に損ねることになります。
メンバー間で発生する情報格差も深刻です。同じ作業をしても、得る情報の量が桁違いですから。チケット読解力の高い方と低い方では、まず前提知識が揃いません。議論でもぶつかりやすく、そこまでいかないにしても前提条件を揃えるのに説明コストがかかります。
このようにチケットに書かない・読まない行動は、組織としての学習能力を失わせる危うさをはらんでいます。
チケットは汚してなんぼ
綺麗でなくてもいいです。というか最初から完璧に書こうとすると、気負いすぎて書けないと思います。いい感じに書く方法は後から付いてきますので、とにかく作業した内容を書き残しましょう。
あなたが業務時間内に、何を調べ、何を考え、どうコードに落とし込んだのか。それを知るのは今まさに対応している担当者であるところの、"あなた"しかいないのです。
企業で事業を行っている以上、同じプロジェクトの開始から終了まで、全く同じメンバー構成などありえません。新しく参画したメンバーが当時の状況を知る術は限られています。AIに必要なデータを入力するにしても、肝心の情報に抜けが多ければ結果もまた然りでしょう。
結局、何も残っていない真っ白な状況が最もキツいです。
いい感じに書く方法は後から付いてくる
最初から「どの情報が残すべき情報か」なんて分かる開発者はいません。分からないうちは全部書いていきましょう。助けたり助けられたりする経験を積むことで、次第に分かってくるものです。
そのうちノイズになる情報や、後の開発者の助けになる情報が分かってきます。もしも先輩のITエンジニアの中にシゴデキな方がいらっしゃるのであれば、真似してみるのもいい経験になります。
強いて上げるなら、
- エラーメッセージやエラーログは、後から検索しやすいようにテキストで貼り付ける。
- 障害調査は実行したこと・日時・手順を軽くまとめておく。
- 何らかの意思決定が行われた場合、日時・場所・メンバー・内容を記録する。
- 設計方針・実装方針は、参考にした記事のタイトルとリンクを控えておく。
などでしょうか。
細かく上げていくとキリがないですが、要するに「チームのメンバーと未来の自分が助かるように配慮した文章」が書ければいいんだと思います。
おわりに
チケットやプルリクエストに積極的に情報を残している方は、後先を考えられるITエンジニアの鏡だと尊敬しています。彼らの洗練された書き方はこれからも見習っていきたいです。
Discussion