チーミング試行錯誤録 (3) – チケットシステムを知識ベースの中心に据える

前回は「情報共有の拠点を作る」ということで、GitHubというWebサービスを我々「クマ組」の拠点として選択したという話をしましたが、今回はそのGitHubをどのように使って行くのかということについて書いてみたいと思います。

GitHubのメニューを見ると、以下のような機能があることが分かります。

github-menu

この中で情報共有の中心的な役割を担うのが「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タグによって分類されているものがあったりします。

issues

知識管理のグラデーション – フローからストックまで

taskでも、topicでも、チケット上で議論を行うことによってチケットシステムに知識やノウハウが蓄積されて行きます。全文検索やタグなどを利用していつでも欲しい情報を探し出す事が出来るので、これだけでもかなり有用な知識ベースではありますが、仕事の経緯を記録するというチケットの性格上、多くのノイズを含んでいたりしてそのままだと読み辛かったりします。

というわけで、ある程度汎用的な(文脈にあまり依存しない)知識を獲得出来たと感じるチケットについては、それをマークダウンの文書に清書して Gitリポジトリの中に保存することにしました。リポジトリ内にある文書は、GitHubのトップページから辿れるようにしておきます。このように、理解するための文脈をそれほど必要とせず、かつ価値の高い情報(多くは技術的なノウハウになると思いますが)を容易に参照出来るようにしておけば、後からチームに合流した人や、外部の人たちの助けになります。

Gitリポジトリに保存された文書はいわゆるストックと呼ばれる情報です。チケットシステム上で知識を生み出し、より価値の高いもの(耐用年数の長いもの)をストックとして保存する。これがクマ組の学習プロセスの中心です。

ストックと言えば、もう片方にあるのがフローです。フローは短時間で流れて行く情報で、その目的は「アクションの喚起」にあります。今やどこの組織でも使われるようになったチャットがフローの基本だというのはクマ組も同じです。チャットによるフローと、Gitリポジトリに保存されたストック文書の間に、チケットシステムを配置する、というのがクマ組の試みです。

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

flow-and-stock

チーミング試行錯誤録 (2) – 情報共有の拠点を作る

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

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

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

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

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

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

チームの名前を決める

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

kuma

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

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

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

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

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

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

teaming

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

情報共有の拠点を作る

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

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

(続く)

チーミング試行錯誤録 (1) – ピラミッド型組織にチーミングを根付かせる事は可能なのか?

というわけで始まりました。

限りなくゼロに近いスタート地点からチーミングの花を咲かせる事が出来るのかどうか、貴重な挑戦の機会を得られたので、ここに試行錯誤の記録を残して行きたいと思います。

「チーミング」とは、『チームが機能するとはどういうことか』という本で紹介されている新しい時代の協働のあり方で、今のように複雑で変化の速いマーケット(この本の中では「知識ベースの経済」と紹介されています)で生き残るために、今後ますます重要になっていくと考えられています。

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

この試みについて少し背景を説明しておきましょう。

ウチの会社は、自社開発のWebサービスを中心にした事業を展開しています。会社としての歴史はそこそこ長いものの、Webサービス企業としてはまだ新米であり、これから大きく展開して行こうと日々頑張っているところです。元々は規模の小さな会社であり、ベンチャー的なフラットな雰囲気のある会社でしたが、合併などによる社員の増加に伴い、部署ごとに様々な顔を持つ組織に変化しつつあります。

会社の規模が大きくなると必然的に起こる変化があります。ウチはまだ表題の「ピラミッド型組織」だと断言してしまえるほど固定的な組織になっているわけではありませんが、部署によってはそのような傾向が見えつつあるのは否定出来なくなってきています。この傾向はどのように現れるのでしょうか?

  1. 意思決定が上層部に集中するようになり「指示 => 実行」の構造が現れてくる。
    • チーミングの本では「実行するための組織づくり」として紹介されています。
  2. 効率を重視するあまり、小分けにしたタスクを少しでも余裕がある人に割り当てるようになる。
  3. 仕事が個別になった結果、横のつながりが弱くなり、チームが形骸化する。
  4. 一人の人間が同時並行で別々の仕事をするようになる。

このような変化は、従来型の「効率を重視した組織運営」の結果、必然的に起こるものです。というかむしろ、組織運営とは本来そのようなものであり、変化が今ほど激しくない時代の協働としては当たり前の形だったわけです。

これが時代の変化によって時代遅れになりつつあるというのがチーミング本の主張であり、「効率を重視した組織運営」に変わって新しい時代の協働のあり方として有望なのが「チーミング」だというわけです。

チーミング本では、チーミングにとってピラミッド型組織がいかに不利な環境なのかという事が繰り返し解説されています。マイクロマネジメントをやっている方は自身では案外気づけないものです。であれば、下位の人間が上位の人間に対して指摘すれば良いのでしょうが、それが出来るんだったらそもそもピラミッドになんかならないという話もあります。

ウチの場合は、部署によってはチームがうまく機能しているところもあり、あくまでも局所的な問題ではあるのですが、チーミングを立ち上げる場としてあえて難しい場所を選んで試行錯誤してみようというのが、このプロジェクトの趣旨です。カッチカチのピラミッドの中で挑戦するより遥かに障害は少ないかもしれませんが、「指示 => 実行」構造から脱却したいと考えている方々の参考になればと思い、うまく行った事・行かなかった事も含めて、その試行錯誤の記録を赤裸々に記録して行ければと思っています。

チーミング試行錯誤録 (2) – 情報共有の拠点を作る

組織やチームの話を追いかけると、プログラミングは基礎教養なんだって話に辿り着いてしまう件

まさにそんな感じの話がInfoQで紹介されていた。

自律的なチームを「管理」するという矛盾にどう立ち向かうか

シュレーディンガーの猫
シュレーディンガーの猫

組織とはそもそもピラミッド(階層構造)なのだということを、筆者の中で今流行りのハーバート・サイモン先生は主張して目出度くノーベル賞を獲得したのだが、時代は変わってチーミングの本では、そのピラミッド型組織が親の仇のように扱われていた。

21世紀になって、それまではどちらかと言えば個人の才能に頼っていたイノベーションという難題に、組織として取り組む企業が出現し始め、それに成功した企業が高い競争力を持つようになったため、チーミングやらボトムアップ組織のようなものが脚光を浴びるようになったというのがその背景だ。

しかし、組織とはそもそもピラミッドなのである。その中では、上位の人間の役目は下位の人間を「コントロール」して成果を出す事だと信じる人間が圧倒的なマジョリティを占めるだろう。

このような環境の中で、自律的に考えて動くチームを組織の中心に据えるというのは、相当な難題である事は想像に難くない。

この「自律的なチームを組織の中でどう育てるか?」という、一見矛盾するかのように思える問題を、量子力学の「シュレーディンガーの猫」に喩えて解説したのが、Instagram で技術責任者を務める James Everingham 氏だ。

観測という行為自体が観測対象に影響を与えてしまうという「観察者効果」のメタファーは、自律的なチームを管理するという矛盾(難題)をうまく表現していると思う。管理者は常に、自分が介入する事でチームの自律性(シュレーディンガーの猫)を殺してしまう可能性があることに注意を払う必要がある。

Everingham氏が提案する、量子力学的チームマネジメントの5つの法則はこちら。

  1. 成功のパターンを出来るだけ沢山想定すること。
  2. 観察者効果を常に意識すること。
  3. 箱を開ける(観測する)タイミングを心得ること。
  4. 自律性を壊さずにチームに良い影響を与える方法を心得ること。
    • 背中を見せる
    • 共感による動機付け
    • インセンティブ
    • 連帯感
  5. チームが正しい方向に向かっているか、外部からのフィードバックに常に気を配ること。

この新しいマネジメント手法のエッセンスは、当該記事の最後の言葉に集約出来るかもしれない。

By not suggesting a destination, we all ended up somewhere extraordinary — a place I didn’t even know we were going.

「あえて行き先を押し付けない事で、想像もしなかったような、すごいところに到達できる。」

適応 2.0: 職能分割型組織は何故生き残れないのか?

色んな役割の人たちが、力を合わせてより大きな意思決定を行う。

経済学から心理学、そして認知科学からコンピュータ科学まで、あらゆる分野の知見を総動員して組織とその経営について論じ、1978年にノーベル経済学賞を受賞したハーバート・サイモン氏は、組織の存在意義をそのように説明した。

古典的な経済学において人間は完璧な存在だった。あらゆる場面で常に最良の意思決定を行う。しかしサイモン氏は、現実の人間はそのような合理性を想定するにはあまりに非力過ぎるため、その非力さを前提に経済活動を分析した方が良いのではないかと考えた。

これが彼の代名詞的な発見とされている「限定合理性」と呼ばれる考え方だ。

マーケットが要求する難しくて大きな意思決定を、小さな意思決定に分割して組織の各部署に分担させる。分割された意思決定に必要となる知識は少なくて済むために、「非力な」個人でも比較的合理的に判断が行えるようになる。

人間はそのようにして、マーケットと呼ばれる環境に適応して行く。

組織は、すべての重要な意思決定が中央においてなされる、高度に集権化した構造のものではない。高度に集権化された方法で機能している組織は、再び、手続的合理性の枠をこえ、階層的な権限の使用から得られる多くの利点を失うことになる。現実世界の組織は、それとはまったく違った動きを示すのである。

1つの決定は、多くの事実前提と選択基準によって影響されるから、これらの決定前提のうちの一部が上司によって規定されるからといって、それが完全な集権化を意味するものではない。組織は、決定を分散させることによって、市場と同様、情報の需要を局所化し最少化することができる。実際の事柄は、組織内のそのための技能と情報がもっともよく集まったところでまず決められ、次にそれを「集合点」に伝達し、もって特定問題に関するすべての事実を統合する、そしてこれらを踏まえて1つの決定が下される。われわれは1つの決定を、それぞれが特定のタスクをもちかつローカルな情報源に依存しているサブルーチンを備えた、大規模なコンピュータ・プログラムを実行することによって造り出された生産物、と考えることができる。いかなる1個人あるいは1集団も、その決定にかかわるすべての面で専門家である必要は、まったくないのである。

このようにして企業組織は、市場と同様、巨大かつ分散化されたコンピュータなのであって、その意思決定過程は実質上分権化しているのである。

システムの科学

意思決定に関わる「情報の需要を局所化し最少化する」ための仕組みが、役割の分担であり、仕事の専門分化である。それが20世紀のマーケットを生き延びるための「適応」の技術だった。そして、職能分割型組織は、21世紀になった今でも主流を占めている(少なくとも日本では)。

職能という考え方は、役割、あるいは専門というものが安定しているという前提に立っている。

例として、ソフトウェア開発会社について考えてみよう。そこにはプログラマーや営業、マーケターといったような、役割ごとの部署があるはずだ。このように組織が職能で分割されている場合、例えば、プログラマーという一つの役割に期待されるものが、かなり限定されていることに気がつく。

プログラマーはプログラムを書くが、どのようなプログラムを書くのかは別の人が決定出来るはずだと、職能分割型組織は考える。設計をする人と、それをプログラムという形に落とし込む人。そのように分担すれば、人はそれぞれの役割に集中出来るはずであると。そして、プログラマーはプログラマーである限り(その部署に居続ける限り)、その役割が変化することはない。

しかし、多くの人が認識する通り、21世紀になってこの「固定化された役割」という前提はとっくに崩れている。

それまで当たり前だと思われていた役割の境界はいとも簡単に融解して、それまでには存在しなかった専門領域が次から次へと出現するようになった。

ソフトウェア開発における DevOps ムーブメントも、その流れを象徴的に示すものだ。DevOpsは、Dev と Ops という異なる役割の間にあった分断を乗り越えて手を携えなければ、変化の速い環境に「適応」出来ないという問題意識である。

あるいは、先端的な機能横断型組織において、役割がオーバーラップしてしまうという現象も起きている。

これらの現象は全て、今まで境界だと思っていたものが境界で無くなることが原因で起きている。専門分野が増えるというよりも、個人に要求される役割が変化しているのである。

このような状況にあって、多くの組織が職能分割の構造から脱却出来ないのは何故なのだろうか?

それは、人間の考え方や行動様式が、所属する組織の構造に支配されてしまうからだと筆者は考える。人間は本質的には不自由な存在だ。職能分割型組織に長く所属していれば、その構造がその人にとっては現実になる。役割の境界が変わって行くことに気づく事は難しくなるだろう。だから、現在の変化に対して役割を変化させるというよりも、役割を超えた連携をしようという発想にならざるを得ない。

この問題に対処するのに、今のところ最も有効なのはおそらく「チーミング」という考え方だろう。

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

この本で、チームは以下のような機能を提供するものとして紹介されている。

  • 目標を共有する場
  • 学習の場
  • 自由に発言できる場(心理的安全)
  • 境界を乗り越える場

Googleで行われたチームワークに関する調査、「Project Aristotle」で指摘されていたように、上の項目の中で「心理的安全」は、チーミングにとって最も重要な考え方になっている。

職能分割型組織、チーミングの本では「ピラミッド型組織」として紹介されているが、そういった組織が何故駄目なのかと言えば、構造的にも、あるいは心理的安全という見地からも、今の状況に適応するためにはあまりにも不自由過ぎるからだ。

従来的な「プログラマー」の部署で働いている彼は、ひょっとしたらプログラマーという役割に留まらず、それまでは想像もしなかったような役割で企業に貢献出来たかもしれない。組織の変革者となる可能性は誰にでもあるのに、職能分割型組織はその可能性をことごとく潰してしまう。

チームというのは各人の役割をダイナミックに変えて行く仕組みだ。

チームがその仕組みを遺憾なく発揮するためには、チームに与える裁量を出来るだけ大きくする必要がある。その裁量によってチームは試行錯誤し、各メンバーの役割は状況に応じて柔軟に変わり、仕事のやり方それ自体も改善され、より状況に合ったアウトプットを生み出せるようになる。このような環境において、「指示 => 実行」というモデルで管理していた従来型のマネジャーの役割は大きく変わる事になる。そのような役割の変遷を表したのが、John Cutler氏の以下の表だ。

The Evolving Product Manager Role
The Evolving Product Manager Role

果たして、ピラミッド型組織のマネジャーがこのような変遷を遂げる事が出来るのだろうか? おそらくこれがチーミングの中で最も難しいチャレンジになるのではないかと筆者は予想する。