第3回宮原徹のプロジェクトお悩み相談

「宮原徹のプロジェクトお悩み相談」のYouTubeコンテンツ第3弾を公開しました。弊社宮原が皆様のプロジェクトでのお悩みにお答えしていきます。本ブログでも要約を公開していきますので、ぜひご覧ください。

また、皆様からのご相談も受け付けていますので、本記事下部のご案内をご覧ください。

www.youtube.com

今回のお悩み

プロジェクト終了後にプロジェクトの学びを次のプロジェクトに活かせません。文章などに残すことも難しく、残したとしても読んでもらえそうにないので、学びが属人化してしまっています。

どのようにプロジェクトの学びを次回以降のプロジェクトに活かしたら良いでしょうか？

宮原徹の回答

回答としては大きく二つに分けて、「属人化することについて」と「学びを次に活かすことについて」考えていきたいと思います。

まずは「属人化することについて」説明していきたいと思います。学びが属人化してしまうことに関してはある程度仕方ないことだと思います。それを前提として、属人化したノウハウを気軽に引き出せるコミュニケーション環境を作り、うまくノウハウやスキルを別の人にトランスファーできるようにする必要があると思います。

また、「学びを次に活かすことについて」はプロジェクトに共通する部分を抽出してテンプレート化するが重要です。それと合わせて、プロジェクトを遂行する際に、「次がある」ということをプロジェクトメンバーが意識する必要があると思います。

ここからは少し深掘りしていきたいと思います。まずは、属人化したノウハウを共有するためのコミュニケーションに関してですが、「雑談」がたくさんあることが重要だと思います。例えば、チームの定例会で報告事項の確認だけではなく、脱線して雑談するような形が良いと思っています。もし、そういった会議の中で雑談の時間を取るのが難しいようでしたら、別途雑談を目的とした時間をとって雑多な話をしても良いかと思います。ただ、「さぁ、雑談をしましょう」といってもなかなかうまくいかないので、形式張らないで誰かのノウハウを共有する時間といったような形が良いのではないかと思います。そういった中で、誰がどんなノウハウを持っているのかを見えるかすることが重要です。

また、日頃のSlackなどのコミュニケーションの中でも、他のプロジェクトのやり取りを覗いてみたり、口を挟んでみたりすることも良いでしょう。それによってプロジェクトメンバー以外のノウハウを反映することもできるようになります。さらに、プロジェクト開始時や困った時に、プロジェクトメンバー以外の人でノウハウを持っていそうな人にインタビューをするのも有効です。ただし、この場合に注意すべき点としては、アドバイスを採用するかどうかはプロジェクトの判断に委ねるべきという点です。アドバイスが採用されなかったからといって、アドバイスした側が文句をいうというようなことが無いようにしなければなりません。アドバイスした側も判断をプロジェクトに委ね、それを許容するということをルール化する必要があります。

そして、学びをどのように次に活かしていくのかという点では、「テンプレート化」するという話です。これはある特定の人だけが知っている「暗黙知」を誰でもわかる形の「形式知」に変換していくという作業です。経験で得た学びを次に繋げていくということは、実は結構難しいことなのです。経験で得た学びはケースバイケースでいつでも使えるというものではないことがほとんどです。そうなると、他の人に学んでもらうということは簡単ではありません。それが学びを活かせない理由です。

形式知化するためには、経験から得た学びを抽象化して他の人でも使えるようにする必要があります。ただし、これは非常に難しいことで、そう簡単にできることではありません。そこで、自分たちの経験を一からテンプレート化するのではなく、世の中にすでに存在する外部のメソッドや手法と言ったものをベースに、繰り返し使ってみて自分たちの改善を加えていくという、「秘伝のタレ」を作っていくような形でテンプレート化していくのが良いのではないかと思っています。

具体的なテンプレートの例としては、インフラであれば「自動化」などがわかりやすいと思います。インフラの領域では、プロセスがわかりやすく誰がやっても同じようなプロセスになります。それをIaCといったような形で自動化されてきたものがあります。また、開発とのインフラの接点という意味では、CI(継続的インテグレーション)があります。このようなところから手をつけて、自動化しながらゆくゆくはDevOpsという形に繋がっていくとっかかりとなるかと思います。

また、開発プロセスという面では今まではウォーターフォールというテンプレートがあったわけですが、アジャイルに対するニーズが徐々に高まってきています。アジャイルの中でも、スクラム開発はケースバイケースの側面が少なく、ベストプラクティスといった形になっているので、そういったものをまずはしっかりと実行していくのが良いかと思います。もちろん、スクラム開発が100%自分たちの開発にマッチするわけではないので、場合によっては部分的に取り入れていくといったアプローチでも良いと思います。

まとめとしては次のようになります。