Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話2/3

前回の続き

ちょっとしたカイゼン物語をエンジニアコミュニティに送り出す

 身の回りのちょっとしたカイゼンの話を見つけたら、次はどんな勉強会で、どんな構成で発表するか考えるだろう。でも、エンジニアコミュニティでの発表って、ちょっと敷居が高いと思われているかもしれない。

 実際、JaSST'18 Tokaiの発表スライドDevOps Days Tokyoの発表スライドを作っていているときも、エンジニアの僕は無意識にやっていることでも、人事の相方は「???」となる、エンジニアコミュニティ独特のお作法がいくつかあった。

 ここでは、人事の相方と一緒にスライドを作る中で気が付いた、エンジニアコミュニティ独特のお作法を、これからエンジニアコミュニティでの発表を目指す人向けに4つのポイントとして紹介しようと思う。

①発表の位置付け

 自分の発表が、コミュニティや今までの技術の発展の中でどういう位置付けなのかを明確にすることは、発表の意義をみんなに知ってもらう上で一番重要だ。こう書くと難しいことのように感じるかもしれないけれども、要は、「みんなXXについて課題を感じているよね?そのXXについての解決方法YYを考えて実践してみました」っていうように、自分の問題意識とアプローチを明確にするってことだ。

 ここでいう問題意識は、「アジャイルや自動化をチームに導入したいけど色々大変」とか、「自動化を進めたいけどチーム間でのコラボレーションが大変」といったような身の回りでありがちなもので最初は十分だ。いま自分が困っている課題は、実は世の中の多くの人が同じ課題感を抱えている可能性がある。その課題を実践的に解決する話は、きっとエンジニアコミュニティの他の人たちにとっても価値がある。

②発表内容のエンジニアリング的な納得感

 お作法ってほどではないけれども、「もうすでにコミュニティの中で正しいと信じられていること」から実践してみたり、発表スライドを始めてみたりするのはオススメのテクニックだ。エンジニアリングコミュニティの中では今までの歴史や積み重ねの中で、なんとなく「エンジニアリング的に正しい」と信じられていることがある。

 もし、そういう事柄があるのならば、発表スライドの一番最初にその話を紹介すると、「ああ、あの(みんなが正しいと信じてる)プラクティスを実践したのね」「ああ、あの(みんなが正しいと信じてる)手法を発展させたのね」と納得感を得られやすい。(例:いきなり「ブルドーザー」と言っても「なんじゃそりゃ」とビックリするけれども、いったんみんなの知っているFearless Changeをはさむことで、納得感が生まれるw) 

③発表内容の新しい価値とオリジナリティ

 もしあなたの発表内容が、例えば教科書に書いてある手法をその通りにやってみただけであったとしても、その実践内容や結果を発表することはコミュニティにとって大きな価値がある。どういう条件の時にうまくいくのか、いかないのか、事例として共有されると、その手法についての実践知がたまり、より深く理解するきっかけとなる。

 でも、僕個人としては、そんな事例の中にも少しオリジナルのアイデアがある方が好きかなあ(笑)。教科書的な部分て堅苦しい面があるけれど、「ブルドーザー」みたいなオリジナルのアイデアってやっぱワクワクするのよね。

④その手法はいつでも誰でも実践可能か

 もしあなたのカイゼン手法が、誰にでもどんな場合でも実践可能なものならば、多くの人がその手法を実践してみるだろう。より多くの人にとって実践可能な手法はコミュニティにとっても価値が高い。でも、カイゼン手法を誰でも実践可能なモノに落とし込むには少なからず手間がいる。

 手法の原因や結果などを構造化したり、ステップバイステップの手順を書き起こしたりすると、より多くの人が簡単に実践できるものになる。パターン化は、より定義された構造化の方法だ。また、その手法を使ってうまくいく・うまくいかないケースの条件なんかも、その手法を実践してみようとする人にとって貴重な情報だ。

「人事がDevOps研修を作っちゃった話」の上記4つのポイント

 今回の発表の中で、上記の4つのポイントをどのように作り込んでいたのかを参考までに書いてみる。

  JaSST Tokaiの場合 DevOps Daysの場合

発表の位置付け

  • 「"アジャイル"や"自動化"などの新しいプラクティスを組織に導入する」際に必要な文化的な変革の事例
    • ソフトウェア開発に置いて、特にテストの分野ではアジャイルや自動化を導入することが業界全体として急務の課題となっている
    • 上記課題に対して、技術的な解決方法はいくつか提案されているが、文化的な側面の解決方法および事例は少ない
  • DevOpsの文脈で重要な文化的な変革の1つ、研修の促進の事例
    • DevOpsの分野では、コンウェイの法則で知られるように、自動化などの技術的な側面だけでなく、文化的な変革も重要と言われている
    • 上記課題に対し、どういった研修が重要か?どういう風に研修を広めると効果的か?といった議論はほとんどされていない

発表内容のエンジニアリング的な納得感

  • 新しいプラクティスを組織に導入する手法・事例として「Fearless Change」と「変革の軌跡」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る
  • 新しいプラクティスを組織に導入する手法として「Fearless Change」を参照
  • 実践した手法・結果について、Fearless Changeをベースに振り返る

発表内容の新しい価値とオリジナリティ

  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案
  • 組織に研修を広めていく際に効果的だった行動が、フェアレスチェンジとも合致していたことを示す
  • また、フェアレスチェンジのカバーしていない部分を、オリジナルのパターン”フェアレスブルドーザー”として提案

その手法はいつでも誰でも実践可能か

  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり
  • あくまで事例の紹介であり、手法の再現性を保証するものではない
  • ただし、手法の振り返りにフェアレスチェンジをベースとして用いることで、パターンランゲージが保証する範囲での再現性を担保する
  • フェアレスブルドーザーの再現性を担保するには、別途再現性をパターンなどで担保する必要あり

 

次回に続く