nop_thread さんが約1年前に追加. 約1年前に更新.
0%
説明
特定の問題を抱えているとして (たとえば「積読が溢れて部屋が狭い」など)、それを解決する手段が唯一であるかまたは採るべき手段を既に決めている場合 (たとえば「デカいシリーズを読みきって実家へ移動する」など)、どのようにチケットを作るべきか。
たとえばこの例では、
このチケット自体もバグとして「解決手段の決めてある問題をどう起票するかの規則がない」とすべきなのか、それとも「解決手段の決めてある問題の起票の規約を定める」とすべきなのか。
ソフトウェア開発のうちのソースコード管理について言えば、一般に編集によって実現される機能か目的があるのでそれを素直に起票すればよく、また起票するまでもない変更は起票なしで適用することもできる。
また、入れるべき変更が確定していてもそうでなくとも、実現される機能や修正される問題自体をタイトルにできるのでこのような混乱はない。
ただ、これをソースコード管理に限らず業務全体の管理に使おうとすると、やはり同様の問題が生じることがある。
「hogeというバグを修正する」というタイトルでバグチケット (あるいは機能チケット) を作らないことを考えると、問題そのものや新たに得たいものをタイトルに設定するのが一貫しているように思われる。
この場合、タスクの内容をチケットタイトルにするのをやめるべきということになるかもしれない。
しかし、たとえば「賃貸契約を更新する」はタスクそのもの以外の何物でもなく、これを「機能: 2022〜2024 の賃貸契約」とするのはあまり良質な命名とは思えない。
nop_thread さんは #note-3 で書きました:
しかし、たとえば「賃貸契約を更新する」はタスクそのもの以外の何物でもなく、これを「機能: 2022〜2024 の賃貸契約」とするのはあまり良質な命名とは思えない。
ソフトウェアのソースコード管理との違いを考えてみると、ひとつは時間経過と外部の状況に依存して、管理者によるアクションなしに勝手に管理対象そのものが変化したりしないという点がある。
外部の状況の変化で問題が新たに発生しても、それはあくまで「相性により問題が発生した」ということであって「管理対象の仕様と実装がいつの間にかおかしくなっていた」という話ではない。
一方たとえば賃貸契約は「アクティブな賃貸契約は1年で勝手に終了する (予定)」のような、時間に依存して内部的な性質が変化するという捉え方が日常的である。
もちろんこれを時間非依存にして「2020年〜2022年の契約は結ばれており、2022年〜2024年の契約はまだ結ばれていない」と表現することもできるが、これは日常的な見方ではない。
前者のある意味では迂遠な解釈を採用するとソースコードと似通った性質になり、 #note-3 のような違和感とともにソースコード管理と近い運用が可能になるということだろう。