プログラマの思索

Redmineのようなチケット管理システムは「作業の構成管理」という機能を提供しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【1】2000年頃に「達人プログラマー」という黒本を買った。
当時は一流のプログラマになるためのバイブル本だった。

その中の一節に「ソースコード管理システムは、ソースのUnDo機能を提供するシステムである」という文言があり、すごく印象に残った時があった。

実際のプログラミングでは、自分の思考内容をソースコードに表すが、最初から一番良いソースが書けるわけではない。
試行錯誤しながら、ロジックを切り貼りしたり、分割したり、いじくったりする。
すると、その履歴を残したくなる。
途中で、テキストエディタでUndoやRedoするように、ソースコードも過去に遡ったり、途中のソースに戻りたくなるからだ。

つまり、ソースコード管理システムは「プロジェクトレベルでのタイムマシンというべき一つの巨大なUnDoキー」なのだ。

特に、昨今は、GitHubやGitを使っていると、masterとは別に、ブランチ上で新しい機能を実験しやすくなった。
また、たくさんのブランチを派生させても、あるタイミングでマージするためにプルリクエストを送ればいい。

【2】チケット管理システムがないプロジェクトで、作業管理を見ていると、作業の履歴やUnDo、ReDoが欲しくなる時がある。
ISO9001のQMSの運用を行なっている現場で、そんな状況を見た時がある。

ISO9001の品質管理マネジメントシステムでは、全ての作業は記録として残さなければならない。
普通は、作業依頼書のようなExcel帳票に、作業発生から作業終了までの履歴を記録する。

しかし、普通は作業依頼書だけでは話は終わらない。
Excel帳票としては、作業依頼書と、仕様変更の設計書やリリース手順書のような作業手順書とペアが必要になる。
実際の細かな仕様、詳細なリリース手順は、作業依頼書には書ききれないからだ。

それら2個のExcel帳票を、作業状況ごとに管理する必要があるが、これが結構面倒だ。
普通は、作業中のステータスで滞留しがちで、なかなか終了しにくい。
依頼する人と作業する人は別々なので、作業連携がすごく悪いからだ。
今、どの作業ステータスにあるのか、最新状態が反映できていない。

この問題の原因は、作業のステータス管理ができていない点にある。
それは、Excelの作業依頼書には判子欄があるが、それはRedmineのチケットのステータスと同じだ。
Redmineでやれば、すぐに解決できる。

また、Excel帳票の版管理で、依頼する人と作業する人が混乱する場合もある。

依頼する人は設計書を用意するが、割り込みの要望や考慮漏れで設計書を書き直したりする。
すると、どの設計書が最新版なのか、作業する人は混乱しがち。

この問題の原因は、設計書の版管理、つまり設計書のバージョン管理ができていない点にある。
結局、Excelの設計書もSVNやGitでバージョン管理すべき対象なのだ。

Excel帳票で作業依頼書と設計書をやり取りしているISO9001の運用では、プロジェクト数が増えるほど、混乱しがちになる。

【3】そんな状況を見ると、Redmineのようなチケット管理システムは、設計書のバージョン管理と同じように、作業のバージョン管理を提供しているように思える。

設計書のバージョン管理が必要な理由は、設計書の最新版がどれなのか、を明確にする必要があるからだ。
リポジトリを見れば、タグ付けされた設計書が作業対象だ。
設計書の履歴は、リポジトリのリビジョン履歴を見ればいい。

同様に、作業依頼がチケットとして発行されれば、チケットのログに全ての作業履歴が記録される。
作業中に課題が発生したり、設計者と実装手段を議論したり、間違った実装を障害として把握して直したり、色々あるだろう。
そういう履歴があるからこそ、作業依頼書の内容に記載された「作業」は、過去にいつでもさかのぼれる。

つまり、チケットは「作業内容のタイムマシン」だ。
「昔にさかのぼって、どんな作業が行われたのか、を追跡できる」点がチケット管理システムの最大のメリットだ。
これは「トレーサビリティ」という機能を提供している。

チケット管理システムが持つトレーサビリティは、本番稼動後の派生開発や障害修正で、大きな威力を発揮する。
本番稼動中の汚いソースコードには、過去の障害修正によるパッチの意図がある。
その変更の意図を無視して、ソースを勝手に弄ってはいけない。

また、プログラマは派遣契約で出入りが激しい。
3年前に書いたプログラマがいなくなれば、そのソースコードは、どんな意図で書かれたのか、その仕様はどういう経緯で決まったのか、誰も分からなくなる。
しかし、チケットにその作業履歴が残っていれば、その作業履歴に紐付くソースの変更履歴を辿ることで、パッチの意図を把握することができる。

ソフトウェア構成管理は、ソースコードのバージョン管理だけでは足りない。
作業の構成管理というべきチケット管理システムも必要だ。

IT化されていないISO9001のQMSで、作業依頼書と設計書という2種類のExcel帳票が運用上必要であるという事実は、ISO9001の背後にある構成管理には、成果物のバージョン管理と作業の履歴管理という2種類の構成管理が必要なのだ、という思想が背後にあるように思う。

【追記】以前、岡本さんから、「Gitポケットリファレンス新版」を頂きました。
構成管理の仕組みを理解する上で、Gitが分かれば、過去のバージョン管理ツールも分かるだろうし、チケット管理システムの必要性も見えてくるのではないか。
「Gitポケットリファレンス新版」は、Gitを知る上でとても読みやすい本でお勧めです。