私たちのチームでは、よく「ふりかえり」という形で、仕事の進めかたに関する改善をしています。「ふりかえり」については以前に記事を書きました。
一般的な「ふりかえり」では、チーム内での良かったことや悪かったことをメンバーで共有するものですが、私たちは時に、特定の個人の働きかただけに焦点をあてた「ふりかえり」もしています。
それは、弟子や中途採用の方への教育や指導をするための「ふりかえり」です。個人の働きかたについて、メンターがレビューするような形になります。そこで私たちは、その「ふりかえり」の一種のことを「ワークレビュー」と呼ぶことにしました。
この記事では、ナレッジワーカーにとっての仕事の進めかたを伝えていくための「ワークレビュー」という手法について書きました。
You!! / Subharnab目次
マニュアル化できない仕事が求められる社会に
私たちソニックガーデンでは、ソフトウェア開発を主な事業としています。自社のソフトウェアを企画して開発することもありますし、お客さまのソフトウェアを「納品のない受託開発」という形で開発することもあります。
ソフトウェア開発の仕事において、何度も同じことを繰り返すような仕事は殆どありません。本来ソフトウェアには同じものを大量生産することがないからです。ソフトウェア開発のような設計（デザイン）の仕事をする人のことをナレッジワーカーと呼ぶのです。
ドラッカーの提唱した「ナレッジワーカー（知識労働者）」とは、ざっくりとまとめてしまえばマニュアル化できない仕事をする人たちのことです。ホワイトカラーやデスクワークだからといってナレッジワーカーであるとは限りません。繰り返しの労務を提供する労働者とは異なり、ナレッジワーカーには、常に新しい価値を創造していくことが求められます。
ナレッジワーカーの仕事とは、誰かの難しい問題を解決する仕事や、ゼロからイチを生み出すような仕事があてはまります。こうしたマニュアル化することが難しい仕事の重要性は益々増してきており、一方でマニュアル化できる仕事は機械やコンピュータに置き換わっていっています。
これからの社会に求められる人材は、ナレッジワーカーになっていくでしょう。それが知識社会です。
ナレッジワーカーの生産性をどう改善していくか
マニュアル化できない仕事をするナレッジワーカーはどうやったら育つのでしょうか。ある程度マニュアル化された仕事であれば、研修などを通じて、その習熟を目指せば良いかもしれません。しかし同じことを繰り返す訳ではない仕事の場合、シミュレーションをすることや過去のケーススタディを通じて学ぶことは出来るかもしれませんが、練習通りの本番が来ることはありません。
この世に二つと同じプロジェクトはありません。与えられた状況も、共に取り組む仲間も、扱うことのできる技術も、同じということはないですね。ナレッジワーカーなら誰もが、常に新しい取り組みをしている訳です。
ナレッジワーカーにとっては、学習することも仕事の一部と言えます。
そう考えると、マニュアル化できない仕事をするナレッジワーカーの働きかたというのは、美術のような芸術に似ているように思います。デザイナーやアーティストはどうやって上達していくのか、以前にデザイナーの方に聞いたことがあります。やはり、ある程度の知識は必要ですが、それ以上はやってみるしかない、ということでした。その技能の経験を積むしかない訳です。
ただし、闇雲に経験を積んだとしても上達するのに時間はかかります。よほどの天才でなければ、その正しさや上手さのようなものについては、自分自身を客観的には判断できません。先ほどのデザイナーの方に、続けて教育についてはどうするのかを聞いたところ、やらせてみてから指摘をする、ということでした。つまりレビューです。
仕事の進めかたも同じで、まずはやってみることが一番大事で、その結果について自分よりも正しさや上手さをしっている人からのフィードバックをもらうことが次に大事なことになります。そもそも、ナレッジワーカーの仕事には正解はないため、上達するにはレビューを繰り返すしかありません。
「ワークレビュー」の進めかた
ナレッジワーカーが仕事を効率的に上達するために必要なのは、熟練者による仕事の仕方のレビューです。それを「ワークレビュー」と呼んで実践するのですが、中身は「ふりかえり」に近いです。（ちなみに「ワークレビュー」という言葉は私の造語なので、特にやり方に正しいも正しくないもありません。）
「ふりかえり」では、KPTというフォーマットで、Keep,Problem,Tryという３つに分けて、それまでのインターバルで良かったこと（K）と悪かったこと（P）を出して、そこから次に試すこと（T）を出すというもので、「ワークレビュー」も基本的には同じスタイルですが、KPTの前に「やったこと」の共有をすることが多いです。
進行としては、KPTのKとPを、レビューされる側（レビューイ）がまず一人で出します。出揃った段階で、レビューする側（レビューア）と共に内容の確認をしていきます。レビューアは、そこで出た自省の内容について、理由を問いていきます。一つ一つの判断には理由があり、その結果としてKとPがある訳です。その理由を聞くことで、レビューアの考え方とのズレを確認していき、改善できるところを探り、一緒にTryを考えます。
そのレビューの中で、熟練者であるレビューアが「自分だったらこう判断する」ということを伝えていくことで、その背景にある哲学や理念、価値観といったものを伝えていくのです。大事なことは小手先のテクニックよりも考え方です。
「ワークレビュー」を実践する際の４つのポイント
「ワークレビュー」を実践する中で、一般的なKPTのポイントに加えて、以下の点を意識しておくと良いでしょう。
レビューアは我が身に返ることを恐れずに指摘する
レビューアにしてみると、自分が出来ていないことであっても、そのことは棚に上げて、理想とする仕事の進め方との違いについて鋭く突っ込まねばなりません。そうでなければ、レビューの意味がないからです。自分で指摘していて耳が痛い場合、それはレビューアにとっても成長のチャンスでもある訳です。
個別の案件に関する話はせず、個人にフォーカスする
案件ごとの「ふりかえり」はチームで実施するべきです。そこでは、チーム全体でKeep/Problem/Tryを考えて共有していくことが重要になりますが、個人の「ワークレビュー」の場合、個別の案件に関する話は不要です。あくまで個人の仕事の仕方についてレビューするのです。
レビューイにとって指摘は人格否定でないことを理解する
「ワークレビュー」では、特定の個人がする仕事の仕方について指摘をしていきます。そうすると、ともすれば個人攻撃をしているようにも映るかもしれませんが、そうではありません。指摘するのは、その人ではなく、仕事の仕方です。そこをお互いに理解しあっている必要があります。
「なぜなぜ」を追求するのでなく「そもそも」から考える
ナレッジワーカーの生産性は沢山の時間を働いたところで圧倒的な効果は出ません。知識労働において圧倒的な効果を出すためには、やらないことを決めることが大事です。そのためには、課題に対して「なぜなぜ」を繰り返しても答えは出ません。「そもそも」の目的を考えることが大事で、そこからショートカットするアイデアが出ることがあります。
ワークレビューで会社のカルチャーが伝わっていく
「ワークレビュー」とは、ナレッジワーカーの仕事の仕方を改善するためのプラクティスです。マニュアル化できない仕事を上達していくために、実際に自分でやってみて、その結果を元に熟練者からのフィードバックをもらうことで成長することが出来ます。
自分で経験してみることで、成功も失敗も自分ごととして捉えることが出来、現実に体験した文脈に沿った形での教訓を得ることができます。経験の伴う教訓こそが、もっとも効果的なフィードバックになります。沢山のフィードバックを得るためにも、失敗しても良いので思い切ってやってみることが大事なんです。
私たちソニックガーデンでは、途中からジョインしたプログラマや弟子に対して「ワークレビュー」をしていくことで、会社が大事にしていることやその背景にある会社のカルチャーが共有されていく効果を感じています。会社内において、規則（ルール）を明文化することで社員を縛るよりも、ワークレビューを通じて、良識（コモンセンス）を共有することで社員を育てるという感覚を大事にしています。
その会社に新しく入る人にとって会社のカルチャーが浸透していくことが、その会社の一員になっていくように思います。会社と社員の関係は、仕事を与えることや給料を出すことも意味がありますが、それよりも同じカルチャーで働くことの方が重要な気がしています。そのために「ワークレビュー」は効果を発揮します。
「ワークレビュー」は採用の際にも使えます。本人が自らの仕事を改善する意思を持っているかどうかを確認するために、ワークレビューを実施することがあります。これまでの仕事のやり方に固執したり、変化を嫌う人はワークレビューを嫌がります。そういう人はその先も成長する見込みは薄いため採用できません。
「ワークレビュー」は、定期的に繰り返し行います。最初のうちは週に１度はすべきです。そして、「ワークレビュー」は、入社直後だけするものかというとそうではありません。改善とはどこまでいっても改善することが出来ます。思考停止にならず、常に改善していくことで成長を続けることが出来るのだとしたら、そのプラクティスに終わりはありません。
ナレッジワーカーとして成長を続けたいのであれば、ワークレビューも続けていくと良いでしょう。
プログラミングの腕を上げるために効果的なのは、熟練者によるコードレビューを受けることだ。一人きりでコードを書き続けるよりも、早く上達する筈。やってみてからフィードバックをもらうことが教訓に繋がる。であれば同様に、仕事の進め方もレビューを受けた方が成長できる。それがワークレビュー。
— Yoshihito Kuranuki / 倉貫義人 (@kuranuki) October 9, 2013
