Feb 21, 2023
開発成果物のレビュープロセスがしんどい。
ユーザーを多く抱える成熟期のサービスを開発している。BtoBのサービスであり、販路や会社間の関係性などふまえてステークホルダーが多かったり、ユーザーにしてもサービス購入者と利用者が異なるなど、複雑な事情を抱える。多くのユーザーやステークホルダーに受け入れられる変更を加えるには、気にしないといけないことがたくさんある。そのため十分な品質を得るためには、ユーザーやステークホルダーについて深いナレッジを持つ製品企画やカスタマーサポートといった有識者の協力が必要になる。開発チームによる成果物を、有識者がレビューするプロセスをとっている。このレビューのプロセスが、レビュイーとレビュアーの両者にとってしんどいものとなっており、コストもかかるしスピードも落としてしまっている。
レビューによって問題は見つけられているので、その効果は得られている。しかしレビューされる方は手戻りや追加作業が生まれるのでしんどいし、レビューする方も労力をかけてたくさん指摘を出しており、やはりしんどい。長く取り組みは続けているがなかなかレビュー指摘が減らない状況だ。本来はレビューを続けていれば、指摘は減ってくるだろうと考えていたが、そうなっていない。レビューする方は「いい加減学んでくれ」と思っているだろう。レビューされる方もサボっているわけではない。個人の資質の問題ではなく、組織的なナレッジマネジメントの問題である。
組織的なナレッジマネジメントの問題であればSECIモデルで考えることができそうだ。 成果物のレビューは関係者で知識を持ち寄り価値を生み出す作業だ。これは連結化に当たる。 製品企画やカスタマーサポートは、普段の業務からユーザーと接し、ユーザーが求めるものの理解を深めている。これは内面化に当たる。 共同化と表出化はそれに当たるプロセスや取り組みがない。 つまり、SECIモデルによる知識創造のサイクルには分断が起こっている。 レビューを重ねても指摘が無くならない原因は、組織的な知識創造が機能していないことにある。 個人レベルではユーザー理解が進んでいるが、組織レベルでは学習が機能していないため、開発チームと有識者との間で知識のギャップが拡がっていく。このギャップの大きさがレビューのしんどさに現れる。 共同化や表出化の過程がないため、開発チームはレビューにより得た暗黙知を形式知に変換できない。そのためにレビューを受けて得た知見を他の場面で応用できず、レビュー指摘が減らない。
これまでも「開発者もユーザーと話した方がいいのでは？」「有識者を交えて勉強会をした方がいいのでは？」みたいな課題は直感的に持っていたが、SECIモデルを通して考えてみることで、それは共同化や表出化を促す取り組みなのだと理解できた。 共同化や表出化を促す取り組みが必要であると考えてみると、他にもやってみたい施策の案は出てくる。 手始めに、ユーザーが持つ価値観や業務を、製品企画から開発チームに実例付きで紹介してもらう取り組みを始めてみた。