冥冥乃志スマートフォン用の表示で見る冥冥乃志ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。この広告は、90日以上更新していないブログに表示しています。前回は、今の開発プロセスに適応する形での新しいレビュー方法について模索してみました。現在、隔週でチームレビューに取り組んでいますが、まだリズムという点でしか効果を実感できていません。大きな効果については、もう少し継続していかないと得られないようです。mao-instantlife.hatenablog.comさて、前回の最後で軽く触れましたが、レビューに関するナレッジ共有にredmineのフォーカスを使うようにしたのですが、書かれている内容が個別の指摘になっていて、チーム全体が使えるような指摘になっていません。我がチームには優秀なレビュアーがいるにも関わらず、彼らが持っている知識が伝わっていないのです。いうわけで、ナレッジの共有を活性化させるために、継続的に行うある活動を仕込んでみました。レビュアーのナレッジを共有しなければならないのか?まず単純にレビュアーがレビューだけしていれば良いということはありえません。優秀なレビュアーでも、ケースによっては当然レビュイーになります。そのレビューで指摘や観点のレベルが落ちてしまうと、チーム全体で見たときに品質面で弱点を抱えることになります。この弱点をチームでカバーするためには、優秀なレビュアーとしてチームで認知されている人の知識を個人のものではなく、チームのものにしていく必要があるのです。レビューの知識=レビュアーの勘(現状)ここで、レビューの知識について考えてみます。レビュアーが指摘をする時は、背景に技術に対する知識やプロダクトに対する知識、そしてレビューそのものに対する知識があります。前者二つについては、様々ドキュメントやコードで残っているし、チームが共通してもっている知識があるのですが、レビューそのものに対する知識については、現状「勘」の一言に集約されてしまっています。実際のところ、もうバリッバリの暗黙知なんですよね。指摘であげてくれる箇所が的確で本当に職人芸というか。SECIモデルを意識してみる暗黙知をチームの知識として活かしていくと言えば、野中郁次郎先生の「知識創造企業」を思い出される方も多いかと思います。SECIモデルを使って、レビューの勘どころの現状と、どういう仕掛けをすれば知識が共有されるか検討してみましょう。SECIモデルによれば、知識の活用によって優れた業績を上げている企業の組織的知識は、以下のようなプロセスモデルにしたがって発展しています。各プロセスはそれぞれ、暗黙知や形式知を変換するプロセスです。各プロセスの説明は以下の通りです。共同化(Socialization):共体験などによって暗黙知を獲得・伝達するプロセス表出化(Extrenalization):得られた暗黙知を共有できるように形式知に変換するプロセス連結化(Combination):形式知同士を組み合わせて新たな形式知を生み出すプロセス内面化(Internalization):新しい形式知の実践を元に新たな知識を獲得するプロセスこれらの頭文字を取ってSECIモデルと言います。このプロセスが繰り返されることで組織的な知識が発展してきます。この図を見てもわかる通り、知識が共有され、活かされるためには形(形式知化)が必要だということがわかります。見る優秀なレビュアーが何をもたらしているか?優秀なレビュアーからなされた指摘によって、レビューの後で品質が良くなったという実感が得られます。指摘は、カバレッジのように定量化できるところもあれば、各機能への機能性や保守性に関するものです。指摘そのものも品質を上げていますが、それよりも重要なことは、ここまではチームでわかっている、大丈夫だ、という信頼感かもしれません。優秀なレビュアーは、独自の観点からの指摘を通じて、この理解がチームに積み重なるように促してくれている気がします。いう信頼感って、一朝一夕に作り上げられるものではなく継続的なレビューの活動の結果得られるものだと思います。何か無名の質っぽくないですか?そこでパターンランゲージですよ予想していましたね?レビュアーの指摘に限定した話ではありますが、パターンランゲージを使って表出化と連結化を促し、蓄積されている暗黙知を活用していこう、という試みであります。何はともあれ、まずは今の勘どころのようなものを言語化しないと始まりません。言語化を通じて、パターンのフォーマットに乗るかどうか、知識として使っていけるものなのかどうかを検証していく必要があります。チームで活用することを目的としているので、パターンマイニングやパターンライティングは私のタスクではなく、チームのタスクとして取り組めるように仕掛けていく必要もあります。パターンランゲージの説明とりあえず、意外とデザインパターンを通じてパターンのフォーマットは知っててもパターンランゲージという方法論については知らないという人が多そうです。パターンランゲージとパターンの説明をした方が良さそうです。協調作業型パターンマイニングパターンのフォーマットを知って、ハイ書いて、というのはあまりにマッチョすぎますし、効率も悪いし、何より書いたものがパターンとして使えない知識だったら泣きます。闇雲にパターンを書いていくよりは、目的に沿ったマイニングを活動に組み込んでいった方が良さそうです。協調作業型パターンマイニングのワークショップの方法があったので、参考にしてみることにしました。我々は、現場から学ぶ。d.hatena.ne.jp毎週の活動(15分から30分を継続)として想定しているので、付箋や模造紙などはむしろ準備がオーバーヘッドになりそうです。上がってきたレビュー指摘などをネタにパターンの候補が出てくるような質問をして、書き留めていくことにしました。手探りなので、しばらくは事前準備のハードルが低い方法で。パターンライティングについては、すぐに必要なさそうなのでまだ計画しないことにしました。パターン候補として発散すれば良いかな、と。初回で、やってみたんですよ。パターンランゲージの説明難しいまあ、パターンランゲージというものの説明をしようとするとどうしてもそうなりがちなんですけど、パターンというのはこういうフォーマットで、ということは説明できるんですが、パターンを通じて何を目指すかを説明しようとするともやっとします。するのは良いんですけど、たまに某長嶋氏っぽくなります。無名の質がどんなものか簡単に説明できれば苦労はしないんだよ!と愚痴っても仕方ないので、パターンというフォーマットの利点と活用を提案をメインにしました。パターンランゲージについても触れましたが、パターンを出していく活動を通じてだんだん理解が進めば良いかな、というレベルです。ワークショップ難しいある程度質問をまとめてみたんですけどね、話が想定以上に発散しました。以下のようなことが原因ではなかろうかと思っています。30分はワークショップには短すぎる私自身このワークショップに参加したことがない議論のとっかかりに使った指摘があまりにも限定されていたパターンの候補になる知識自体のイメージがつかめていなかった結果、雑談っぽい進行になりましたが、得るものは大きかったと思います。実際にその場にいた人間の実感で言うと、表出化というよりも共同化のフェーズに近いです。パターン候補までは整理できていなくても、少しずつ考え方や知識を言語化していくことで、チームの中で少し知識が積み上がった実感は得ることができたかと思います。パターンになっていそうな行動というのもいくつか出てきました。正直な所、ここについては型通りに行かなくてもあまり気にしていません。経験を積み重ねていくにつれて、チームに適用したマイニング方法が確立されていくのではないかと思っています。したらマイニング方法というよりは、言語化の場作りとファシリテーションが確立されれば良いのかもしれませんし。これからともあれ初回なんで、継続してみないと何とも言えません。表出化のために想定した場が図らずも共同化になってしまいましたが、今まで話していなかったテーマで議論するのは、チーム内でも良い刺激になった実感はあります。後は、形式知のフォーマットとしてのパターンをうまく機能させられるか、ですが、これについては最初のパターンを書いてみてからになるので、先はもう少し長そうです。»プロフィールid:mao_instantlifeソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。月別アーカイブ参加グループプログラミングはてなブログをはじめよう!mao_instantlifeさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。