カテゴリー: チーミング試行錯誤録

前回は「情報共有の拠点を作る」ということで、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リポジトリに保存されたストック文書の間に、チケットシステムを配置する、というのがクマ組の試みです。

このように考えるとチケットシステムがフローとストックの間に入って両者を補完することが分かります。チャットはアクションを喚起するものですが、議論の記録は流れて行ってしまいストックにはならないのが基本的な性質です。検索して過去の議論を探す事は出来ますがノイズが多いので役に立つ状況は限られます。逆に言えば、ノイズが許容されるのがフローのメリットです。チケットシステムは「アクションを要求する」というフローの性質を備えつつも、より構造化された、比較的ストックに近い情報を蓄積することの出来る仕組みです。

さてチーミングを始めようということで、新しいチームに集まった人間が自分も含めてたったの二人だと知ったとき、私は目の前が真っ暗になるのを堪えながら、心の中で何かがこみ上げてくるのを感じました。

前回紹介したように、多くの人が複数の仕事に従事するようになった結果、新しいチームに専念できる人間がその二人しかいなかったのです。

チームに緩やかな境界を設定する

しかし、無い袖は振れないという事では仕方がありません。段階的にチームビルディングしていくことを考え、チームに緩やかな境界を設定する事にしました。

まず、チームに専念出来る人を「構成員」、たまに作業に関わる人を「準構成員」としました。その他は、ミーティングに参加自由の「オブザーバー」というものを設定して、これらを緩やかなチームの境界とします。

• 構成員（専任）
• 準構成員（作業に関わる人）
• オブザーバー（ミーティングに参加する人）

チームの名前を決める

チームの構成を決めたら、次はチームの名前を考えます。元々、手薄だったインフラ周りの仕事を担当するために結成されたチームだったので「インフラチーム」で良いんじゃないかという声もありましたが、チーミングの考え方からいって「機能」を名前にするのは出来るだけ避けたいと断固主張し、何か良い名前はないかと皆で思案した結果、ある構成員のアイコンが「リ○ックマ」だったという安直な理由で「クマ組」という名前に決まりました。

チーミングの本を購入する

そもそも私以外のメンバーは「チーミング」という言葉を聞くのも初めてです。まずは方向性を共有するために、教科書となる本を買って皆で少しずつ読んで行く事にしました。

『チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ』

この本の内容を簡単に説明すると、

「成功している組織やプロジェクトを調べるとどうも共通点があって、それは「チーミング」と名付けた方が良いのでは（と勝手に著者が思ってる）、という本」

という感じになります。沢山の事例が出てくるという事もあるのでしょうけど、内容が若干散漫なので、もうちょっとまとめてくれないかな？ という気もしないではありません。というわけで、下のようなマインドマップを作って随時更新するようにします。

今回のプロジェクトで最初の課題だと考えているのは「学習の場」の部分です。前回説明したように、組織がピラミッド化していくにつれて、エンジニア間の横のつながりが薄くなってしまい、知識の交換が行われる機会がかなり少なくなっていました。こうなってしまうと、学習や成長は個人の責任になってしまい、組織で働く意味がなくなってしまいます。そこで横のつながりを復活させて再び知識の共有が行われるようにしよう、というのが我々の最初の目標になります。

情報共有の拠点を作る

というわけで、まずは情報共有の拠点を作るというのが、我々がチーミングを始めるに当たっての第一歩になりました。

情報共有の拠点としては、GitHubというサービスを選択してみました。ここに一つのリポジトリを作って情報共有の拠点とします。GitHubは本来プログラマーが協働するためのプラットフォームですが、この環境を利用してプログラマーが協働するのと同じような方法でチームの知識を開発して行く事にします。

（続く）