とことんDevOps | 日本仮想化技術のDevOps技術情報メディア

DevOpsに関連する技術情報を幅広く提供していきます。

日本仮想化技術がお届けする「とことんDevOps」では、DevOpsに関する技術情報や、日々のDevOps業務の中での検証結果、TipsなどDevOpsのお役立ち情報をお届けします。
主なテーマ: DevOps、CI/CD、コンテナ開発、IaCなど
読者登録と各種SNSのフォローもよろしくお願いいたします。

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

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

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

www.youtube.com

今回のお悩み

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

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

宮原徹の回答

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

 

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

 

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

 

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

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

 

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

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

 

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

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

 

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

  • ノウハウを必要な時に引き出せる環境づくり
  • 聞けるる、アドバイスできる雰囲気とルール
  • ノウハウを学びやすくする抽象化
  • 基本的な進め方を軸にテンプレート化
  • 既存のテンプレートを活用
  • プロセスの繰り返しでブラッシュアップ

ご案内

この「宮原徹のプロジェクト相談」では皆様からのご質問を待ちしております。匿名での質問でも、非公開での質問でも構いません。下記のリンクよりご相談ください。

匿名でのご相談

peing.net

非公開でのご相談

virtualtech.jp