エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話2/3
前回の続き
ちょっとしたカイゼン物語をエンジニアコミュニティに送り出す
身の回りのちょっとしたカイゼンの話を見つけたら、次はどんな勉強会で、どんな構成で発表するか考えるだろう。でも、エンジニアコミュニティでの発表って、ちょっと敷居が高いと思われているかもしれない。
実際、JaSST'18 Tokaiの発表スライドとDevOps Days Tokyoの発表スライドを作っていているときも、エンジニアの僕は無意識にやっていることでも、人事の相方は「???」となる、エンジニアコミュニティ独特のお作法がいくつかあった。
ここでは、人事の相方と一緒にスライドを作る中で気が付いた、エンジニアコミュニティ独特のお作法を、これからエンジニアコミュニティでの発表を目指す人向けに4つのポイントとして紹介しようと思う。
①発表の位置付け
自分の発表が、コミュニティや今までの技術の発展の中でどういう位置付けなのかを明確にすることは、発表の意義をみんなに知ってもらう上で一番重要だ。こう書くと難しいことのように感じるかもしれないけれども、要は、「みんなXXについて課題を感じているよね?そのXXについての解決方法YYを考えて実践してみました」っていうように、自分の問題意識とアプローチを明確にするってことだ。
ここでいう問題意識は、「アジャイルや自動化をチームに導入したいけど色々大変」とか、「自動化を進めたいけどチーム間でのコラボレーションが大変」といったような身の回りでありがちなもので最初は十分だ。いま自分が困っている課題は、実は世の中の多くの人が同じ課題感を抱えている可能性がある。その課題を実践的に解決する話は、きっとエンジニアコミュニティの他の人たちにとっても価値がある。
②発表内容のエンジニアリング的な納得感
お作法ってほどではないけれども、「もうすでにコミュニティの中で正しいと信じられていること」から実践してみたり、発表スライドを始めてみたりするのはオススメのテクニックだ。エンジニアリングコミュニティの中では今までの歴史や積み重ねの中で、なんとなく「エンジニアリング的に正しい」と信じられていることがある。
もし、そういう事柄があるのならば、発表スライドの一番最初にその話を紹介すると、「ああ、あの(みんなが正しいと信じてる)プラクティスを実践したのね」「ああ、あの(みんなが正しいと信じてる)手法を発展させたのね」と納得感を得られやすい。(例:いきなり「ブルドーザー」と言っても「なんじゃそりゃ」とビックリするけれども、いったんみんなの知っているFearless Changeをはさむことで、納得感が生まれるw)
③発表内容の新しい価値とオリジナリティ
もしあなたの発表内容が、例えば教科書に書いてある手法をその通りにやってみただけであったとしても、その実践内容や結果を発表することはコミュニティにとって大きな価値がある。どういう条件の時にうまくいくのか、いかないのか、事例として共有されると、その手法についての実践知がたまり、より深く理解するきっかけとなる。
でも、僕個人としては、そんな事例の中にも少しオリジナルのアイデアがある方が好きかなあ(笑)。教科書的な部分て堅苦しい面があるけれど、「ブルドーザー」みたいなオリジナルのアイデアってやっぱワクワクするのよね。
④その手法はいつでも誰でも実践可能か
もしあなたのカイゼン手法が、誰にでもどんな場合でも実践可能なものならば、多くの人がその手法を実践してみるだろう。より多くの人にとって実践可能な手法はコミュニティにとっても価値が高い。でも、カイゼン手法を誰でも実践可能なモノに落とし込むには少なからず手間がいる。
手法の原因や結果などを構造化したり、ステップバイステップの手順を書き起こしたりすると、より多くの人が簡単に実践できるものになる。パターン化は、より定義された構造化の方法だ。また、その手法を使ってうまくいく・うまくいかないケースの条件なんかも、その手法を実践してみようとする人にとって貴重な情報だ。
「人事がDevOps研修を作っちゃった話」の上記4つのポイント
今回の発表の中で、上記の4つのポイントをどのように作り込んでいたのかを参考までに書いてみる。
JaSST Tokaiの場合 | DevOps Daysの場合 | |
---|---|---|
発表の位置付け |
|
|
発表内容のエンジニアリング的な納得感 |
|
|
発表内容の新しい価値とオリジナリティ |
|
|
その手法はいつでも誰でも実践可能か |
|
|
次回に続く