今日は何するんだっけ？思考をリードするチケット管理の書き方〜構造化ドキュメンテーション (4)

Posted at 2025-01-12

チケット管理システムの限界

システム開発において、GitHub issue や Backlog や redmine などのチケット管理システムは欠かせまん。チームメンバーが次に何をすれば開発が進むのか示されますし、言葉で検索して仕様を調べたり、仕様に関連するパワポやコード（Git のコミットに含まれる差分コード）を表示したりでき、開発を助けます。

しかし、チケット管理システムはチームのコミュニケーションのためのツールであるため、時系列の対話形式の表示になっており、作業を実際に進める上で必要な情報がバラバラになっています。今日、何をするかという細かいレベルまでは教えてくれません。たとえば、チケットを作ったばかりのときは全ての情報が揃っていませんし、会議やヒヤリングや議論をした後で決まるまたは分かる情報は、時系列の下のほうに表示されます。それらだけをまとめたメモが欲しくなりませんか？どうすれば、チケットのクローズに必要な情報だけに整理することができるでしょうか。プロジェクトマネジメント（PM）のスキルはチケット管理システムに置き換わりましたが、個人レベル、担当レベルで作業を管理するスキルは置き換わっていません。そのスキルをどうすればシステム化できるでしょうか。

本記事で紹介する書き方は、ただのチケット分類法ではありません。現在のチケットの詳細へダイレクトにジャンプできるのはもちろん、作業を最短距離で完了できるように優先順位をいつでも変えられることや、思考や想像力を発揮できるように適切な情報の提示ができるように考えられています。

ここでは構造化ドキュメンテーションによる整理されたチケットメモ の書き方を説明します。Visual Studio Code (VSCode) を使った構造化ドキュメンテーションの応用なので、色が付いて見やすくなりますし、折りたたむことができますし、図から関連情報にジャンプすることや、任意の場所から図の中へジャンプすることもできます。テキスト形式なので Git でバージョン管理もできます。たとえば、過去のチケットのメモも表示できますし、編集した日時を元に記憶を辿ることもできます。。

もちろん自分なりにカスタマイズして構いません。一部だけ取り入れても構いません。プログラムではないのでカスタマイズは簡単です。

チケットメモはこのような感じになります。以下で詳細を説明していきます。

今日:
    issues/123, サーバーエラーの処置:
    issues/121, 項目の追加:
スタック:
    issues/123, サーバーエラーの処置: #keyword:  #// 来週まで。api サーバー
        memo: |
            〜のページでエラー
            〜のログに詳細が書いてありそう
    issues/121, 項目の追加:
        リストの変更:
            _____
        エラー, ____:

なお、プロジェクト管理に使うガントチャートについては、有料のエクセルがあれば無料テンプレートが使えるガントチャートについて書かれたこちらの記事を参照してください。

記事中にある typrm については、構造化ドキュメンテーション (1) の特長： YAML 形式と typrm タグを使うメリットに活用方法が書かれています。

初期のチケットメモ、タイトル

チケットの ID
チケットのタイトル
タイトルのコメント（必要なら）
memo （フリーフォーマット）

スタック:
    issues/123, サーバーエラーの処置: #keyword:  #// 来週まで。api サーバー
        memo: |
            〜のページでエラー
            〜のログに詳細が書いてありそう

まずはチケットメモを書く場所を確保するために、チケットの ID とタイトルを書きます。なお、本記事ではチケットの ID として、GitHub Issues の URL の末尾を書いています。

https://github.com/__Owner__/__Project__/issues/123
    ↓
issues/123

タイトルはチケット管理システムに書かれたタイトル名をそのまま書きます。チケットのタイトル名が内容を適切に表現していなくてもそのまま書きます。なぜなら、チケット管理システムを見たときにすぐに見つけやすくなるからです。多少の違和感があっても、言葉のずれがあったとしても慣れてくるものです。ただ、チケット管理システムに書かれたタイトルを絶対に変えてはいけないというわけではありません。タイトルをコロコロ変えてしまうとチームが混乱してしまうことが問題なので、そうでなければ適当なタイミングで宣言して変えます。新規作成したすぐであればタイトルを変えても混乱は少ないです。

分かりやすくタイトルを変えたいときは、# の右にコメントで補足します。

さらに、typrm の #keyword: タグを書いておくと、typrm でチケットの ID やタイトルを検索するときの精度が上がります。

おそらく最初は少ししか書かないので、内容を構造化なくても良いでしょう。なんでも書いてよいことを表す memo などの抽象的な名前のフィールドを作り、その行末に | を書くことで、そのフィールドの中は YAML の書式のエラーが出ないように気をつけなくても、自由に書けます。

チケット（まだクローズしていないチケット）は、スタック: の子フィールドに集めます。

依頼内容、状況、（開始手順）、作業内容

依頼内容
状況
（開始手順）
作業内容

スタック:
    __TicketID__, __Title__:  #// __Comment__
        依頼内容:
            ____
        状況:
            ____
        （開始手順）, 対応, テスト:
            ____
        __Working1__:
        __Working2__:
        __State__）__Working3__:

チケットを少ない労力で完了させるためには、ゴールを見失わないことです。資料を読んでいったら関係ないけど気になることが書いてあって読んでしまう。そんなことばかりしていたら、いつまでたっても作業は終わりません。もちろん寄り道することで新たな発見をすることもあるでしょうが、それはゴールを意識して時間配分を考えた上で行いましょう。

依頼内容

まずは、依頼内容のフィールドを作り、そこへ依頼内容に関するメモを集めます。たとえば、資料への URL やその概要です。それ以外は、後で説明する状況フィールドや作業内容フィールドになど移動します。

スタック:
    issues/123, サーバーエラーの処置: #keyword:  #// 来週まで。api サーバー
        依頼内容:
            〜のページでエラー
            #ref: http://example.com/specifications/s301_pages.pdf#pagge=3
        memo: |
            〜のログに詳細が書いてありそう

依頼内容とそれ以外に分類する目的は目的と手段を間違えないようにするためです。たとえば、依頼内容を完了させるために、勉強が必要だと考えたとしましょう。しかし、その勉強は依頼内容ではありません。検索するだけで済んだり、経験者や AI に聞くだけで済むのであれば、勉強する必要はありません。別の方法を選んでもよいのです。これらの違いを明確にすることで、チケットをクローズするまでの最短距離を適宜選べるようになります。

目的と手段は相対的な関係です。依頼内容（自分の目的）を変えるには、少なくとも依頼内容（依頼者にとっての手段）の変更に依頼者と合意する必要があります。意識を高く持って「依頼内容をこのように変更したほうが絶対に良い」と考えたとしても、依頼は依頼者ひとりだけの考えではなく、社内の関係部署や顧客や期間や予算との調整で決まったことの可能性があります。そうでない可能性もありますが、どちらかを確認するためにも話をして合意する必要があります。変更してはダメというわけではなく、合意する必要があるということです。

💡 上位の SE が作業を依頼するとき**「あとはやるだけだから簡単だろ。」**と言いますが、もちろんそんなことはありません。上位 SE（笑）にとっては、上記のように大変だと思ってらっしゃるでしょうが、伝言ゲームが上手いだけです。ドメインのプロは顧客であり実作業のプロは作業者です。作業者は、難解なシステムを操作したり有識者を見つけて相談したりして、解決に結びつくまでの現実的な道筋を立てています。やるだけの状況では全くありません。

状況

依頼内容はだいたいざっくりとしています。ユーザーが何をしたいのか、何の目的や背景があるのか、具体的にどういう手順をしたいのか、実現可能なのかなどは書いてないことがあります。修正依頼であれば、いつ、どの顧客で何を対象に発生しているのか、どういう手順を実施したときにエラーが発生するのか、エラーメッセージはどう表示されているのか、詳細なエラーログにはどう記録されているのか、それらがチケットに書いてないことがよくあります。

状況を改めて依頼者に聞いたり、状況を自分で調べたりしたら、分かったことを状況のフィールドに書いていきます。電話によるカスタマーセンターの最初の仕事は主にここになりますね。書くことで「調べる」作業に関する思考を脳から解放することができ、いくつかの状況を**「統合する」ことができたら、適切な作業内容が決まります**。

スタック:
    issues/123, サーバーエラーの処置: #keyword:  #// 来週まで。api サーバー
        依頼内容:
        状況:
            頻度:
                8:00ごろに多発
        ログを見る:

💡 多くの場合、状況が書けるまでには時間がかかるので、後で説明する作業内容のフィールドに調査するという作業内容を書くことがよくあります。

💡 状況がきわめて具体的かつシンプルな場合は、すぐに作業内容が分かるでしょうから、状況のフィールドは省略できます。

作業内容の明示

作業内容は、状況を踏まえた上で適切な作業内容を決めます。 AIに状況を話して、ざっくりとどうすればいいかを聞くのも新しい発見があって良いでしょう。

作業内容を決めたら作業内容を明示しなくても作業はできますが、作業内容を明示しないと頭を使っている割にはまた状況把握していたなど気づかないうちに同じことを何度も繰り返しているだけだったりすることがあります。依頼内容や状況を見てしまうと、この大変な状況を何とかしなければならないと考えて、作業内容が脳の一時記憶から追い出されてしまうからです。そうならないためにも、ひとことでも作業内容を書いておくことをお勧めします。

こうしてチケットメモを整理すると、作業内容に集中でき、迷うことなく少ない労力でチケットを完了させられます。

後で詳しく説明しますが、依頼内容の最初のサンプルにある __Working1__, __Working2__ と書いてある部分は、「作業内容」とは書かず、具体的な作業内容を書きます。

スタック:
    issues/123, サーバーエラーの処置: #keyword:  #// 来週まで。api サーバー
        依頼内容:
            〜のページでエラー
            #ref: http://example.com/specifications/s301_pages.pdf#pagge=3
        状況:
            ログ: |
                Connecting 10.34.164.21 ...
                [error] Connection refused 10.34.164.21
            頻度:
                8:00ごろに多発
        （開始手順）, 対応, テスト:
            (app@example.com):
                sudo systemctl start  example-api
            (@local):  #search: VSCode debug
                code  ~/example-api
                F5 キー
        どこに接続しにいっているか調べる:
            memo: |
                nslookup
        トラフィック量を調べる:
        ネットワークの設定を変える:
        済）顧客影響が無いか調べる:  #// 問題なし
            #ref: http://app.example.com/ >> 〜 のページ

（開始手順）の明示こそ効率化のカギ

「開始手順」は最も効果を実感できる項目ですので、ぜひ書いてみてください。これを発見したからこそ記事にしたぐらいです。

それだけに、開始手順だけは目立つように（）で囲みます。開始手順を探すときに見つけやすくするためです。また、親のフィールドに書かれた開始手順から始めることもよくあります。そのときも （）が書いてあると見つけやすくなります。

開始手順には、次の日などに改めて始めから行うときや、何か環境の調子が悪いときに再起動して始めからやり直すときの作業を書きます。たとえば、

〜のチケットを開いて内容を確認すること
〜のフォルダーのプロジェクトを開いて起動すること
問題の再現手順

などについて具体的に書きます。具体的に書く方法については、アジャイルに手順書を書くための 13のルール〜構造化ドキュメンテーション(2) を参照してください。

よくエンジニアは朝は気分が乗らないとか夕方から本気出すとかふざけたことを言いますが、要は開始手順を思い出すことが億劫で暇になって何かしたくなるまでただ待っているだけです。何も考えなくても開始手順に書いてあることをそのまま手を動かすことで、問題がある状況がそこに現れます。それを見たら反射的に対応手段を思いついて能力を誇示したくなる思いで、作業を始めることでしょう。

開始手順は、やがて対応内容とテスト手順に変わる

フィールド名が「（開始手順）, 対応, テスト」になっているように、対応とテストが開始手順と同じフィールドに書かれていますが、これは作業が進むにつれて開始手順を更新していった結果、最終的にこのフィールドは依頼内容にどのように対応したかの説明、および、依頼内容に関するテストの実施手順になるからです。

💡 もし、それらの手順の一部が別の資料にまとめてあるのであれば、チケットメモにはその資料へのリンクを書きます。まとめられた資料には汎用的なことしか書かれていない場合、具体的な部分をチケットメモに但し書きします。

チケットメモはクローズしても残しておきましょう。邪魔に感じるなら別のファイルに移動してでも、とにかく残しておきましょう。時系列のエピソードは記憶しやすいと言われており、ふと過去の作業を思い出して詳細を知りたくなったときのために、完了日でソートして並べておいたり検索できるようにしておきましょう。テキストファイルを何万行と書いたところでディスクが圧迫されるなんてことは全然ないので、残しておきましょう。

作業内容の階層構造

作業内容については「作業内容」とは書きません。なぜなら、チケットメモの階層構造は主に作業内容の階層構造であるからです。チケット（のタイトル）は大きいくくりでの（親の）作業内容です。

💡 チケットより大きいくくりはマイルストーンや、リリースの作業などの親チケットがあります。

💡 ガントチャートのタスクや WBS も同様に階層構造を持っています。チケット、作業内容、タスク、WBS にはそれぞれ違う意味を持っているかもしれませんが、その違いを意識したところでメリットはありません。

作業内容は、チケットの作業内容を分割統治法や動的計画法などで階層化した小チケットになることもあります。その場合、作業内容の子フィールドに作業内容を書くこともできます。孫要素も同様です。

このような階層構造を持つものをに対しては、VSCode などのエディターの折り畳み機能と親和性を高くしておけば、一度チケットを全て折りたたんで、フォルダーを開くように作業内容を見つけることができます。作業内容について「作業内容」と書かないのはそのためです。

階層が深くなるとメモが扱いにくくなるので、深くなってきたら、浅いところに新しいチケットメモを移動します。そして、深い場所から浅い場所に移動したしたフィールドへのリンクを書いておきます。こうすれば、意味的な階層構造と物理的な階層構造を厳密に一致させなくても、フォルダーを開くように見つけることができ、大して問題にはなりません。

💡 意味的な階層構造と物理的な階層構造を厳密に一致させなくても、最初のフィールドにフィールド名だけを書いた全体の階層構造を正しく書けば正しい階層構造を見せることができます。それは図で表現されることもあります。それ以外のフィールドの階層構造については、一致した階層構造であることよりも、参照頻度の高いフィールドを浅い位置に配置して、すぐに見つかるようにすることのほうが有用です。

💡 5階層以上は禁止だから機械的に 5階層目を浅いところに新しいチケットメモに移動するのはやめてください。親子関係が疎になっているレベルで分けます。

済）などの状態マークと作業一覧

完了した作業内容には、済）のマークを行頭に付けます。こうすることで、折りたたんだときに進捗状況を一覧することができます。

済）以外に、待ち）、候補）、ボツ）などを書くのも良いでしょう。ちなみに、「待ち」は関係者からの返答待ちで、よく使います。「ボツ」を残しておくことで車輪の再発明を防ぎます。

済）
待ち）
候補）
ボツ）

チケットの状況や完了させて分かったことの概略を同じ行のコメントに書くと、折りたたんだときでもそれらを見ることができます。たとえば、効果なし、〜を修正、〜機能のみ実装、アラート件数〜件、などです。

トラフィック量を調べる:
ネットワークの設定を変える:
済）顧客影響が無いか調べる: #// 問題なし

済んだ作業内容は下に移動させてまとめると良いでしょう。こうしてまとめておくと、済）のマークを書かなくても完了したことが分かりますが、済）を書いたほうが置き場所を気をつける必要がなくなり扱いやすくなります。

絵文字を使った進捗管理

自分で書いた依頼内容の文章が多くなった場合、すべきことが埋もれて、どこにあるのか分かりにくくなり、やるべきことが漏れてしまうことがあります。

たとえば、

issues/132, トラフィック量を表示する機能の開発:
    依頼内容:
        実験用サーバーAにリクエストした結果を表Aの最終行に表示する。

という依頼内容の文章には、2つのチェックポイントが存在しますが、まずは、それぞれの依頼内容をフィールドに分けた場合を見てみましょう。

issues/132, トラフィック量を表示する機能の開発:
    依頼内容:
        リクエスト先は、実験用サーバーA:
        結果の表示先は、表Aの最終行:

表現できたと思うかもしれませんが、2つのチェックポイントの間の関係性が分かりにくくなっています。「結果」がリクエストのレスポンスなのか他の結果なのかはっきりしなくなってしまいました。

また、フィールドに分けると文章を作り直さなければならなくなります。チェックする対象が主語になるように、文章の構成を大きく変えなければならなくなり、大変な労力を使います。

依頼内容の文章を変えないで複数のチェックポイントを管理するには、目立つ絵文字を使います。

issues/132, トラフィック量を表示する機能の開発:
    依頼内容:
        実験用🔥サーバーAにリクエストした結果を表Aの最終行🔥に表示する

確認が済んだら、済んだことを示す絵文字に置き換えます。もちろん、片方だけ済んだ状態も表現できます。

済）トラフィック量を調べる:
    実験用✅サーバーAにリクエストした結果を表Aの最終行✅に表示する

絵文字の種類をカスタマイズしても構いませんが、凡例を書かなくても絵文字だけで意味が分かる絵文字にしてください。クローズしていないチェックポイントにはテンションが上がる絵文字を選び、クローズしたチェックポイントには安心するような賞賛されるような絵文字を選べば、感情が乗ってきて気分から作業効率が良くなります。

エラーの対処

作業の途中でエラーや問題が発生し、作業を進めることができなくなることが頻繁にあります。そのときは、作業内容を中断してエラーを解決するか、一時的に無視して別の作業内容を先にするか、有識者に相談することになります。見なかったことにしたとしても、責任者を説得したとしても、気合を入れたとしても、作業を進めることはできません。

エラーが発生したらすぐにエラーのフィールドを新規に作ってエラーの存在を明示します。対象となる作業内容の中に（インデントして）作ってもいいですが、エラーは割り込み的に追加される作業なので、基本は同じ深さの隣に並べて、エラーの対処に集中できるようにします。

スタック:
    issues/121, 項目の追加:
        リストの変更:
            _____
        エラー, ____:    #// リストの変更で発生したエラー
            ログ: |
                _____
                _____
            __Working1__:
                _____

ログの一部のコピー

ログは非常に役に立ちます。ログの中には役に立たない内容のほうが圧倒的に多いですが、その中の一部が証拠になるぐらい非常に役にたつことも圧倒的に多いです。

作業内容（またはエラーのチケット）の子フィールドに「ログ」のフィールドを新しく作り、そこへログの内容の一部やエラーメッセージをコピペします。ログの内容は YAML 形式ではないことがほとんどなので、ログ: | のように | を書きます。 エラーのフィールドを作ると同時にログのフィールドとコロンと | まで一気に書いてしまっていいほどログは役に立ちます。

スタック:
    issues/123, サーバーエラーの処置:
        ログ: |
            _____
            _____
        状況:
            _____

詳細な情報が書かれたログは、テキスト形式であることがほとんどです。標準形式が規格で決まっているシステムログや JSON もテキスト形式です。 Web アプリケーションであれば、サーバー内にログがあります。ローカルアプリケーションであれば、内部ファイルにログがあり、関連するシステムの情報と共にサーバーに送信されることがあります。エラーメッセージの近くに詳細を表示するボタンがあるかもしれません。

💡 ユーザーに表示するエラーは一般にシンプルになっていて、大した情報はありません。なぜなら、エラーが出るとシステムの印象が悪くなることや、原因の説明が情報漏洩に繋がることがあるためです。エラー報告をするときはどんなエラーが表示されるかを示す必要がありますが、解決するための情報はエラーコードぐらいしかありません。

ログの内容は機械的に出力されたものなので、表記ゆれが少なく、検索がヒットしやすい性質があります。なので、ログに含まれるメッセージで検索すれば、期待した結果が表示されやすいです。検索は、チケット管理システムやネットや grep や typrm などでできます。オープンソフトであれば、ネットを検索したり AI に聞いたりできます。

💡 ログには、顧客情報や秘密カギや API キーなど外部に漏洩してはならないものが含まれているかもしれません。ネットで検索するときは注意してください。また、チケットメモ自体の取り扱いにも注意してください。

ログの内容を読んで何の問題なのか分かってきたら、エラーの概要をエラーのフィールドに追記します。たとえば エラー, 〇〇データベース接続エラー: のように書きます。

スタック:
    issues/121, 項目の追加:
        リストの変更:
            _____
        エラー, 〇〇データベース接続エラー:
            ログ: | #focus: ____  #ref: ____
                _____

#focus: タグを書いておけば、ログの中の特に注目すべき場所を簡単に強調表示できます。ログは（一部を抽出したログでさえ）それを見るたびに読むことになりがちで非効率なので、このキーワードさえ見れば内容を思い出せるようなキーワードを簡単に強調表示できるようにしておきます。詳しくはアジャイルなノートの書き方入門〜構造化ドキュメンテーションの #focus: タグの説明を参照してください。

#ref: タグにログの全体を表示できる場所の中の特定の場所へのリンクを書いておくと、その周辺のログを見たくなったときに、すぐ探しに行けます。探すときは、ログのフィールドに書かれた内容の一部を、膨大なログの中から検索するときのキーワードとして使うことができます。

CLI であれば、入力したコマンドもログのフィールドに貼り付けるとよいでしょう。コマンドの中に状況が書かれていることがよくありますし、コマンドを少し変えて実行してみることも簡単になります。

ログと状況のフィールドは分けてください。事実を示す証拠（ログ）と解釈を間違えないようにするためです。

作業内容のソート

チケットを少ない労力で完了させるためには、優先順位を考えることが重要です。作業内容の候補を列挙したら、完了できる可能性が高そうな作業内容を優先的に行うことです。

ただ、このように優先順位を決めるための作業を追加したほうがいいとは限らず、そんな作業を追加するぐらいなら、すぐやってみるほうが早いのかもしれません。

優先順位が高い作業内容は上に移動します。依存関係があるときや後で行う作業は下に移動します。チケットの内容によっては下ではなく子（深いインデント）に作業内容を移動したほうが分かりやすいかもしれません。

分類ラベルと now ダイレクトリンク

作業内容の数が多くなったときは、作業内容を分類します。もし、作業内容に親子関係があれば子のフィールドに移動することで分類することができますが、あまり子のフィールドに入れると一覧性が損なわれます。

子のフィールドに入れずにフィールドを「分類」するときは、#↓ __Category__ のようなラベルを書きます。これで、同じレベル（インデントの深さ）のフィールドをグループ化して分類できるようになります。

チケットメモでよく使われる分類のカテゴリーは、次のとおりです。

#↓ now
#↓ 参考
#↓ スタック
#↓ 作業候補
#↓ 完了

また、現在の作業へのダイレクトリンクを張っておくと、どんなに複雑なチケットでも瞬時に最新状況が書かれた場所にジャンプできるようになります。たとえば、#keyword: issues/121 now と書きます。

#keyword: __TicketID__ now

スタック:
    __TicketID__, __Title__:
        #↓ now
        __WorkingC__:
            memo: |
                ____
                ____
    
    
            #↓ 参考
            ____:  #search: ____
                #snip:
                ____
            ____:
            #keyword: __TicketID__ now
        #↓ スタック
        __WorkingD__:
        __WorkingE__:
        #↓ 作業候補
        __WorkingF__:
        #↓ 完了
        済）__WorkingB__:
        済）__WorkingA__:

#↓ now 以下には、現在作業中の作業内容を配置します。

#↓ 参考 には、現在の作業をする上で参考になる情報へのリンクを貼り付けます。作業内容ではありません。参考は親のフィールドの参考が参考になることもあります。

必要なら、#snip: タグを書いて、リンク先の内容のコピーを貼り付けます。 #snip: タグは、引用先の内容のほうが原本であることを示します。 #snip: タグが無ければ、ここで自分で書いたものであることを示します。作業が完了したときに消すかどうかを判断するときに役立ちます。

#keyword: __TicketID__ now タグはチケットの中の現在の作業内容へのダイレクトリンクです。ここに書かれたキーワードで検索すれば、ここにすぐにジャンプできます。あとで説明する今日のチケット一覧からここへジャンプすることがよくあります。

#↓ スタック には、後でする作業内容を配置します。作業中に、しなくてはいけない別のことを思いついたときにすぐに、ここにメモできるようになります。どこにメモしておこうか迷うことが無くなります。

#↓ 作業候補 には、優先度が低い作業内容を配置します。スタックの一種です。次の作業内容を決めるときに迷うことを少なくします。完成までに時間がかかるけど効率化につながるようなことはよくここに書かれますが、効率化につながることは時間配分を考えて消化していきましょう。

#↓ 完了 には、完了した作業内容を配置します。後で見直すときのために残しておきます。

今日のチケット一覧

いくつかあるチケットメモのうち、今日 1日にすべきチケットのタイトルを集めて明示しておくと、作業にメリハリが付きます。 今日1日の時間配分を考えられるようにもなります。また、会議や割り込みが発生したときでも、現在のチケットを切り替えることが簡単にできるようになります。そのためにも、今日のチケット一覧は、ファイルの先頭または末尾に配置します。

今日だけでなく明日にまわすチケットを配置する場所を用意してもよいでしょう。

今日:
    issues/123, サーバーエラーの処置:
    issues/121, 項目の追加:
        エラー, 〇〇データベース接続エラー:  #search: issues/121 now

    issues/109, 項目の削除:
明日:
スタック:
    issues/123, サーバーエラーの処置:
        ____

現在のチケットの下に空行を入れると、小さな割り込みが入ったとしても、元の現在のチケットにすぐ戻れるようになります。 今、何しようとしてたっけ？、とド忘れしたときでもすぐに戻れるようになります。上記のサンプルでは、issues/121 が現在の作業です。ちなみに、作業内容の中でも、現在の作業の下に空行を入れると、そこに続きを書こうという気持ちになり、作業が進みます。

現在のチケットの子フィールドに現在の作業内容の概要を書いておくと、今日のチケットの一覧が分かりやすくなり、どれを始めるか決めやすくなります。

#search: __TicketID__ now タグを書いておくと、より正確な位置にある now ダイレクトリンクにジャンプできるようになります。

最後に

いかがでしたか。いきなり全ての書き方をするのは難しいので、紹介した効果のうち欲しい効果についてだけ少しずつ使うようにしてもらえればと思います。

あらゆる作業は細かくしていくほど簡単になるので、作業内容を書きながらそれを細かくする編集のスピードを上げることこそが作業のスピードの向上につながります。そして、早く解決したらゆっくり休みましょう。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

今日は何するんだっけ？思考をリードするチケット管理の書き方 〜 構造化ドキュメンテーション (4)