前回は「情報共有の拠点を作る」ということで、GitHubというWebサービスを我々「クマ組」の拠点として選択したという話をしましたが、今回はそのGitHubをどのように使って行くのかということについて書いてみたいと思います。
GitHubのメニューを見ると、以下のような機能があることが分かります。
この中で情報共有の中心的な役割を担うのが「Issues」です。
知識ベースとしてのチケットシステム
Issues のようなシステムは一般的に「BTS（Bug Tracking System／バグ管理システム）」と呼ばれたりします。ソフトウェア開発には欠かせないツールで、プログラムの不具合を報告したり、それらの対応状況を共有したりするために利用します。「Bug Tracking System」とあるように、最初はバグ管理のためのシステムでしたが、次第にプログラムの変更に関する事であれば何でも登録して管理するようになり、登録の単位はバグではなく「Ticket（チケット）」とか「Issue」などと呼ばれるようになりました。プログラムの変更をチケットの発行によって進めるという事で「チケット駆動開発」などと呼ばれたりすることもあります。
チケットは「アクションを要求するもの」として機能します。つまり、チケットシステムというのは簡単に言えば組織のためのタスク管理システムです。なので、プログラムの変更に関わることだけでなく、そのプロジェクトに関係するありとあらゆるタスクを管理しても別に問題は無いわけです。
クマ組では、このチケットシステムをタスク管理のためだけでなく、更に拡張して共有知識を生み出す場として使えないか実験してみることにしました。
具体的には、タスクだけでなく議論したい話題や気になっている事などもどんどん Issues に登録して行きます。これらのチケットは「完了」ステータスがないという意味でタスクではありません。でも、チケットとして（議論という）アクションを要求します。
このままだと「未完（Open）」チケットの中にタスク以外のものが紛れてしまいますが、これを解決するのが GitHub Issues に用意されている「Labels」という機能です。これはいわゆるタグ機能で、チケットにラベルを付けて分類する事が出来ます。クマ組では、現時点で以下のようなラベルを作ってチケットを分類しています。
task– 日々のタスク。milestone– チームのミッションを達成するために必要なプロジェクト。タスクをグルーピングするもの。topic– 議論したい話題。book– チームメンバーが読むべき課題図書。nayami– 困っているけどすぐに解決できなそうな事。
GitHub Issues を汎用的な知識ベースとして理由できる最大の理由はこのタグ機能の存在だと言っても過言ではありません。タグによって色々な情報を一カ所で管理することが出来るようになりますし、一つのチケットに複数のタグを付けられるのも重要です。例えば、上の例で言うと、milestoneタグの付いたチケットには同時にtaskタグも付けていずれの文脈でも見れるようにしたり、topicチケットの一部には課題図書を表すbookタグによって分類されているものがあったりします。
知識管理のグラデーション – フローからストックまで
taskでも、topicでも、チケット上で議論を行うことによってチケットシステムに知識やノウハウが蓄積されて行きます。全文検索やタグなどを利用していつでも欲しい情報を探し出す事が出来るので、これだけでもかなり有用な知識ベースではありますが、仕事の経緯を記録するというチケットの性格上、多くのノイズを含んでいたりしてそのままだと読み辛かったりします。
というわけで、ある程度汎用的な（文脈にあまり依存しない）知識を獲得出来たと感じるチケットについては、それをマークダウンの文書に清書して Gitリポジトリの中に保存することにしました。リポジトリ内にある文書は、GitHubのトップページから辿れるようにしておきます。このように、理解するための文脈をそれほど必要とせず、かつ価値の高い情報（多くは技術的なノウハウになると思いますが）を容易に参照出来るようにしておけば、後からチームに合流した人や、外部の人たちの助けになります。
Gitリポジトリに保存された文書はいわゆるストックと呼ばれる情報です。チケットシステム上で知識を生み出し、より価値の高いもの（耐用年数の長いもの）をストックとして保存する。これがクマ組の学習プロセスの中心です。
ストックと言えば、もう片方にあるのがフローです。フローは短時間で流れて行く情報で、その目的は「アクションの喚起」にあります。今やどこの組織でも使われるようになったチャットがフローの基本だというのはクマ組も同じです。チャットによるフローと、Gitリポジトリに保存されたストック文書の間に、チケットシステムを配置する、というのがクマ組の試みです。
このように考えるとチケットシステムがフローとストックの間に入って両者を補完することが分かります。チャットはアクションを喚起するものですが、議論の記録は流れて行ってしまいストックにはならないのが基本的な性質です。検索して過去の議論を探す事は出来ますがノイズが多いので役に立つ状況は限られます。逆に言えば、ノイズが許容されるのがフローのメリットです。チケットシステムは「アクションを要求する」というフローの性質を備えつつも、より構造化された、比較的ストックに近い情報を蓄積することの出来る仕組みです。
ゆびてく 