冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

費用対効果の高いレビューを模索する(ナレッジ共有のための仕込み編)

前回は、今の開発プロセスに適応する形での新しいレビュー方法について模索してみました。現在、隔週でチームレビューに取り組んでいますが、まだリズムという点でしか効果を実感できていません。より大きな効果については、もう少し継続していかないと得られないようです。

mao-instantlife.hatenablog.com

さて、前回の最後で軽く触れましたが、レビューに関するナレッジ共有にredmineのフォーカスを使うようにしたのですが、書かれている内容が個別の指摘になっていて、チーム全体が使えるような指摘になっていません。せっかく、我がチームには優秀なレビュアーがいるにも関わらず、彼らが持っている知識が伝わっていないのです。非常にもったいない。

というわけで、ナレッジの共有を活性化させるために、継続的に行うある活動を仕込んでみました。

何故レビュアーのナレッジを共有しなければならないのか?

まず単純にレビュアーがレビューだけしていれば良いということはありえません。優秀なレビュアーでも、ケースによっては当然レビュイーになります。そのレビューで指摘や観点のレベルが落ちてしまうと、チーム全体で見たときに品質面で弱点を抱えることになります。この弱点をチームでカバーするためには、優秀なレビュアーとしてチームで認知されている人の知識を個人のものではなく、チームのものにしていく必要があるのです。

レビューの知識=レビュアーの勘(現状)

ここで、レビューの知識について考えてみます。レビュアーが指摘をする時は、背景に技術に対する知識やプロダクトに対する知識、そしてレビューそのものに対する知識があります。前者二つについては、様々ドキュメントやコードで残っているし、チームが共通してもっている知識があるのですが、レビューそのものに対する知識については、現状「勘」の一言に集約されてしまっています。

実際のところ、もうバリッバリの暗黙知なんですよね。指摘であげてくれる箇所が的確で本当に職人芸というか。

SECIモデルを意識してみる

暗黙知をチームの知識として活かしていくと言えば、野中郁次郎先生の「知識創造企業」を思い出される方も多いかと思います。SECIモデルを使って、レビューの勘どころの現状と、どういう仕掛けをすれば知識が共有されるか検討してみましょう。SECIモデルによれば、知識の活用によって優れた業績を上げている企業の組織的知識は、以下のようなプロセスモデルにしたがって発展しています。

f:id:mao_instantlife:20150616145035p:plain

各プロセスはそれぞれ、暗黙知形式知を変換するプロセスです。各プロセスの説明は以下の通りです。

  • 共同化(Socialization):共体験などによって暗黙知を獲得・伝達するプロセス
  • 表出化(Extrenalization):得られた暗黙知を共有できるように形式知に変換するプロセス
  • 連結化(Combination):形式知同士を組み合わせて新たな形式知を生み出すプロセス
  • 内面化(Internalization):新しい形式知の実践を元に新たな知識を獲得するプロセス

これらの頭文字を取ってSECIモデルと言います。このプロセスが繰り返されることで組織的な知識が発展してきます。この図を見てもわかる通り、知識が共有され、活かされるためには形(形式知化)が必要だということがわかります。表出化と連結化を促していけば良さそうです。

知識創造企業

知識創造企業

優秀なレビュアーが何をもたらしているか?

優秀なレビュアーからなされた指摘によって、レビューの後で品質が良くなったという実感が得られます。指摘は、カバレッジのように定量化できるところもあれば、各機能への機能性や保守性に関するものです。指摘そのものも品質を上げていますが、それよりも重要なことは、ここまではチームでわかっている、大丈夫だ、という信頼感かもしれません。優秀なレビュアーは、独自の観点からの指摘を通じて、この理解がチームに積み重なるように促してくれている気がします。

こういう信頼感って、一朝一夕に作り上げられるものではなく継続的なレビューの活動の結果得られるものだと思います。もやっとしてますね。何か無名の質っぽくないですか?

そこでパターンランゲージですよ

予想していましたね?

レビュアーの指摘に限定した話ではありますが、パターンランゲージを使って表出化と連結化を促し、蓄積されている暗黙知を活用していこう、という試みであります。

というわけで計画

何はともあれ、まずは今の勘どころのようなものを言語化しないと始まりません。言語化を通じて、パターンのフォーマットに乗るかどうか、知識として使っていけるものなのかどうかを検証していく必要があります。

また、チームで活用することを目的としているので、パターンマイニングやパターンライティングは私のタスクではなく、チームのタスクとして取り組めるように仕掛けていく必要もあります。

パターンランゲージの説明

とりあえず、意外とデザインパターンを通じてパターンのフォーマットは知っててもパターンランゲージという方法論については知らないという人が多そうです。まずはパターンランゲージとパターンの説明をした方が良さそうです。

協調作業型パターンマイニング

パターンのフォーマットを知って、ハイ書いて、というのはあまりにマッチョすぎますし、効率も悪いし、何より書いたものがパターンとして使えない知識だったら泣きます。闇雲にパターンを書いていくよりは、目的に沿ったマイニングを活動に組み込んでいった方が良さそうです。

協調作業型パターンマイニングのワークショップの方法があったので、参考にしてみることにしました。

http://www.washi.cs.waseda.ac.jp/wp-content/uploads/2013/07/wws2010_washizaki.pdf

d.hatena.ne.jp

毎週の活動(15分から30分を継続)として想定しているので、付箋や模造紙などはむしろ準備がオーバーヘッドになりそうです。上がってきたレビュー指摘などをネタにパターンの候補が出てくるような質問をして、書き留めていくことにしました。手探りなので、しばらくは事前準備のハードルが低い方法で。

で、パターンライティングについては、すぐに必要なさそうなのでまだ計画しないことにしました。まずは、パターン候補として発散すれば良いかな、と。

とりあえず初回

で、やってみたんですよ。

パターンランゲージの説明難しい

まあ、パターンランゲージというものの説明をしようとするとどうしてもそうなりがちなんですけど、パターンというのはこういうフォーマットで、ということは説明できるんですが、パターンを通じて何を目指すかを説明しようとするともやっとします。もやっとするのは良いんですけど、たまに某長嶋氏っぽくなります。無名の質がどんなものか簡単に説明できれば苦労はしないんだよ!と愚痴っても仕方ないので、パターンというフォーマットの利点と活用を提案をメインにしました。

パターンランゲージについても触れましたが、パターンを出していく活動を通じてだんだん理解が進めば良いかな、というレベルです。

ワークショップ難しい

ある程度質問をまとめてみたんですけどね、話が想定以上に発散しました。おそらく以下のようなことが原因ではなかろうかと思っています。

  • 30分はワークショップには短すぎる
  • 私自身このワークショップに参加したことがない
  • 議論のとっかかりに使った指摘があまりにも限定されていた
  • パターンの候補になる知識自体のイメージがつかめていなかった

結果、雑談っぽい進行になりましたが、得るものは大きかったと思います。実際にその場にいた人間の実感で言うと、表出化というよりも共同化のフェーズに近いです。パターン候補までは整理できていなくても、少しずつ考え方や知識を言語化していくことで、チームの中で少し知識が積み上がった実感は得ることができたかと思います。また、パターンになっていそうな行動というのもいくつか出てきました。

正直な所、ここについては型通りに行かなくてもあまり気にしていません。経験を積み重ねていくにつれて、チームに適用したマイニング方法が確立されていくのではないかと思っています。もしかしたらマイニング方法というよりは、言語化の場作りとファシリテーションが確立されれば良いのかもしれませんし。

これから

ともあれ初回なんで、継続してみないと何とも言えません。表出化のために想定した場が図らずも共同化になってしまいましたが、今まで話していなかったテーマで議論するのは、チーム内でも良い刺激になった実感はあります。後は、形式知のフォーマットとしてのパターンをうまく機能させられるか、ですが、これについては最初のパターンを書いてみてからになるので、先はもう少し長そうです。