Test Automation

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

個人の経歴2019年バージョン

講演・執筆活動

カンファレンス講演等(日本)

カンファレンス講演等(国外)

執筆関連

勉強会での発表

勉強会企画

書籍関連・インタビュー・ブログ記事など

資格

  • JSTQB Advanced Level テストアナリスト (2017)
  • JSTQB Advanced Level テストマネージャー (2015)
  • JCSQE 初級 (2014)
  • JSTQB Foundation Level (2014)
  • プロダクトオーナー(2014)

コミュニティ

ソフトウェア品質シンポジウム2019でQC七つ道具とDevOpsの経験論文の発表します

 2019年09/11(水)~13(金)に東洋大学で開催されるソフトウェア品質シンポジウムで、QC七つ道具とDevOpsの経験論文の発表をうちのチームメンバーがします。

 この経験論文は、一言で言えば

  • QC七つ道具とDevOpsをやってみた

という内容です。この経験論文の意欲的な点は、QC七つ道具という古典的なツールを持ち出すことで、

  • アジャイル開発の歴史の中でのDevOpsの位置付け
  • アジャイルからDevOpsへの変化によって品質保証の何が変わるのか
  • ソフトウェアプロセス改善の歴史の中でのDevOpsの位置付け

を紐解こうとしている、つまりDevOpsという最近の流行りのプラクティス品質というエンジニアリングの視点で考察している点です。あと、流行としての意味合いが強いDevOpsも、こういうエンジニアリングの視点でまとめたら論文になるんだよ、という一つの指針になるかもしれません。

 本番の発表では、論文に入りきらなかったスライドも入れる予定ですので、ご興味のある方は是非シンポジウムにもお越し下さいませ。

www.juse.jp

07/04(木)19時〜のRakuten Tech Meetup 2が楽しみ #rtechconf

 2019年07月04日(木)19:00〜、「データで切り拓くソフトウェア品質の未来」をテーマにミートアップを開催します!

rakuten.connpass.com

 今回のミートアップは、ソフトウェア品質、スクラム、DevOps、テスト自動化、レビューなど多岐に渡る領域のスペシャリストが「データ」を軸に議論するのが魅力なんです。以下開催概要抜粋。

ソフトウェアの品質改善の活動に、従来のQAから得られる品質のデータに加え、開発や運用から得られるデータ、またリードタイムや生産性など時間に関連するデータなど、様々なデータが活用されるようになりました。これは

  1. 継続的な開発を前提とするアジャイル開発が当たり前となり、時系列データも利用可能になったこと
  2. DevOpsが普及することで、QAだけでなく開発から運用までの一貫したデータが利用可能になったこと

が理由として挙げられます。 

 

f:id:kokotatata:20190605124648p:plain

 これらの新たに利用可能になったデータを活用し、ソフトウェアの品質のみならず、プロセスやチームの生産性、従業員の職務満足度などの改善にも取り組む企業が増えています。また、これらのデータを蓄積することで、AIによるQAの自動化などを始める企業も出てきました。

 このミートアップでは、データにもとづくソフトウェア品質改善のアカデミックなアプローチである実証的ソフトウェア工学の最新動向や、アジャイルやDevOpsなどの現場でのデータ駆動な品質改善活動の事例をご紹介します。また、ラウンドテーブルでは、これらのトピックについて参加者と一緒になった議論をします。

 前回のブログエントリで概説した通り、DevOpsを通してテストやリリース活動がソフトウェア化され、プロダクト品質だけでなくアーキテクチャとプロセスの品質の一体となった改善活動が鍵となってきています。これに加え、Value Stream Mapping上での、分析からリリースまでの一貫したデータが得られるようになり、特にスピードやリードタイムなどの生産性の改善も重要になってきました。(前回のブログエントリは以下をご参照ください。)

kokotatata.hatenablog.com

 このDevOpsでのデータを鍵とした改善活動について、業界のエキスパート達と議論します。ご興味のある方のご参加をお待ちしております!

 

DevOps時代のアーキテクチャ品質特性とプロセス品質概論

はじめに

 DevOpsという言葉は2008年に誕生した。その概念は2015年頃日本でも再注目され、これまでDevOpsに有用な技術や文化の変革について議論されてきた。このブログエントリでは、DevOpsがアーキテクチャとプロセスに与えた影響についておさらいしたのち、DevOpsに必要なアーキテクチャの品質特性とプロセス品質を一覧で示す。

DevOpsがアーキテクチャとプロセスに与えた影響

DevOpsの意義

 プロダクト開発では、要求分析からリリースまでのサイクルを回し顧客からフィードバックを素早く得ることで、プロダクトの品質を素早く継続的に向上することが重要だ。これを達成するため、「要求分析」「設計」「実装」「テスト」「リリース」などのバリューストリームマップに含まれる工程の生産性を改善し、リードタイムを短縮する手段を、DevOpsは提供する。下記の図で黄色の線で示された、要求分析からリリースまでのフローのリードタイムを改善するため、各工程の生産性を向上する。

f:id:kokotatata:20190503141031p:plain

DevOpsのバリューストリームマップとフィードバック

各工程の生産性改善のためのDevOpsの2つのアプローチ

 各工程の生産性を向上するため、DevOpsの技術的なプラクティス郡は2つの共通のアプローチをとる。それは

  1. 各工程の手作業をソフトウェア化することで、それらを素早く、正確に、安全に、繰り返し実行可能になものにする。
  2. (上記の1.の結果、)各工程のアウトプットについて、特に、問題があった場合にそれを素早く発見、修正するフィードバックループを作る。

 1.には、クラウドやInfrasutructure as Codeによるリリース作業や復旧作業のソフトウェア化、テスト自動化によるテスト実行作業のソフトウェア化などが含まれる。繰り返し実行する手順を自動実行できるようにしたり、システムの状態をコードで定義できるようにしたりすることで、各作業をソフトウェアとして管理できるようになる。

 2.には、テスト作業のソフトウェア化によって実装工程のアウトプットであるソースコードの問題を素早くフィードバックするCI/CDや、リリース作業のソフトウェア化によってリリース工程のアウトプットである本番環境の問題を素早くフィードバックするカナリヤリリースなどが含まれる。上記の図に青の線でこのフィードバックループを示す。

手作業のソフトウェア化とフィードバックループが意味するもの

 DevOpsのプラクティスによる手作業のソフトウェア化とそれによるフィードバックループは、すなわちDevOpsがシステムのアーキテクチャーと開発のプロセスに織り合わさって変化をもたらしていることを意味する。

 システムのアーキテクチャ面では、プロダクトの外部品質だけでなく、ソースコードを容易に変更したり、テストやリリース作業を容易にソフトウェア化するための内部品質の重要性が増している。テストやリリース作業を容易にソフトウェ化することが可能なように、プロダクトを設計する必要がある。

 また、ソフトウェア化するテストやリリースなどの手作業は、それそのものがソフトウェアでありプロセスでもある。そのため、それぞれの作業をについてソフトウェア面の品質特性と、プロセスの品質を組み合わせて考慮する必要がある。

 次の章から、DevOpsで特に重要なアーキテクチャの品質特性とプロセス品質を一覧する。

DevOpsのアーキテクチャ品質特性

プロダクトの変更容易性(実装作業)にまつわる品質特性

ソースコードの保守性 プロダクトのソースコードは素早くなんども変更可能か?コードの可読性や、単一責任などのクラス設計は適切か?
サービスやコンポーネントの独立性(*1) 1つのサービスやリリースなどの変更を入れる際に、他のサービスやコンポーネントにも変更を入れる必要があるか?変更の影響は限定されているか?
データの結果整合性(*2) 複数のサービス間で共有されるデータには、どの程度の整合性が求められるか?結果整合性の場合、上記の独立性は担保できるか?

テスト作業のソフトウェア化にまつわる品質特性

テスト結果の取得容易性 システムへのリクエストやアクションの結果を期待結果として定義できるか?また、その結果をシステムから容易に取得可能か?
テスト結果判定の自動化容易性 テストの期待結果をコンピュータにも理解できる形で定義可能か?またテストの合否をコンピュータが判定可能か?
テスト実行の並行性 複数のテストケースを並行して実行することは可能か?テストケースやテストデータは独立か?
テスト実行の冪等性 テストケースは繰り返し実行しても同じ結果が保証されるか?テストの事前準備や事後操作がテストデータの冪等性を担保するか?
自動テストの結果の信頼性 テストのカバレッジは十分か?テスト環境は適切か?テスト実行ごとに異なる結果を返すFlaky Testの数は最小化されていか?
自動テストのレポートとログの判断容易性 テストレポートとログから素早くテスト結果を判断できるか?テスト失敗時に素早く調査可能か?

リリース作業のソフトウェア化にまつわる品質特性

サービスやコンポーネントの独立性

(*1)と同じ

複数バージョンの共存性 本番環境などで、複数のバージョンが共存可能か?バージョン間でI/Fなどの互換性はあるか?
リリース・リカバリ手順の冪等性(*2) リリース手順は繰り返し実行しても同じ結果を保証するか?
インフラの廃棄可能性(*3) 既存のインフラを廃棄しても、同じものを再現可能か?
リリース影響の制御容易性 リリースの影響をフィーチャーやユーザーセグメントなどの単位で制御可能か? リリースの影響範囲を段階的に制御可能か?
リリースやリカバリ結果の判断容易性(*4) リリースの合否の判断は容易に可能か? 判断に必要なシステムログやアプリケーションログは容易に取得可能か?

システムの復旧や運用作業にまつわる品質特性

システムの耐障害許容性 単一のシステムの障害が、他のシステムに影響を及ぼしたり、新たな障害を引き起こしたりしないか?
リリース・リカバリ手順の冪等性(*2) (*2)と同じ
インフラの廃棄可能性(*3) (*3)と同じ
システムのスケーラビリティ  アプリケーションやデータベースは独立性が担保されており、容易にスケールアウトすることが可能か?
リリースやリカバリ結果の判断容易性(*4)  (*4)と同じ
エラーログの判断容易性 エラーログから障害は素早く検知可能か?影響調査や原因調査を素早く行うのに対し、妥当なログが得られるか?

DevOpsのプロセス品質

実装工程の品質

ソースコード品質 実装工程の成果物であるソースコードの、コード行数、複雑度、コピペコードの割合などの技術的負債の量
実装工程で作り込まれた不具合数 実装工程で作り込まれた不具合数(テスト工程、リリース工程で発見した不具合数と市場に流出した不具合の総数)

テスト工程の品質

自動テストの品質 テスト工程の成果物である自動テストの、テストケース数、カバレッジ、実行頻度およびFlaky Testの割合
自動テストの所要時間 テスト準備、実行、およびテスト結果の調査にかかる時間
テスト工程での不具合発見率 不具合の総数に対する、テスト工程で見つかった不具合の割合
テスト工程での不具合修正時間 実装とテストの工程やチームをまたぐ、テストによる不具合の発見から修正、再テストによる修正確認までの時間

リリース工程の品質

リリースの品質 リリース工程の成果物である自動リリースの、デプロイ頻度、リリース成功率および失敗時の影響制御割合
リリースの所要時間  リリース準備、リリース作業、および事後確認にかかる時間
リリース工程での不具合発見率 不具合の総数に対する、カナリヤリリースで見つかった不具合の割合
リリース工程での不具合修正時間 実装、テストとリリースの工程やチームをまたぐ、リリースによる不具合の発見から修正、再テストによる修正確認および再リリースまでの時間
障害復旧時間 開発と運用チームをまたぐ、障害発生から検知、調査と不具合の修正やホットフィックスのリリースまでの、障害発生からリカバリするまでの時間
運用・保守作業時間 インフラチームとDBチームなど、複数のチームをまたぐ運用・保守の作業時間

 まとめ

 DevOpsがアーキテクチャとプロセスに与えた影響を概説し、DevOpsで重要なアーキテクチャの品質特性を工程・作業ごとに一覧で示した。DevOpsのプラクティスを通して生産性を改善するには、これらのアーキテクチャの品質特性とプロセス品質を考慮し、アーキテクチャとプロセス両面から改善活動を行うことが重要だ。

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

前回の続き

社外発表をしてみて

 前々回前回と「エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出すまで」の話を書いた。このシリーズ最終回の今回は、エンジニアコミュニティ発表未経験の人事の相方が、実際に発表してみた後の振り返りについて書く。今回は、DevOps Days Tokyoのワークショップで体験してきた「Fun! Done! Learn!」で振り返りをした。Fun! Done! Learn!は楽しく振り返りやろうぜ!ってことだと思います(多分)。

Fun! Done! Learn!

 1時間ほどのFun! Done! Learn!の結果出てきた振り返りアイテムは

  • ①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)
  • ②結果として色々いいことが!(Fun! and Done!) 
  • ③発表内容の工夫(Learn! and Done!)

の3つに大きく分類できた。赤い付箋が人事の相方から出たもので、黄色い付箋が僕から出たものだ。

f:id:kokotatata:20190422105840p:plain

  ここでは、人事の相方がエンジニアコミュニティでの発表で得たものや気付いたものをカテゴリごとに紹介していく。

①今までのカイゼン活動を誇れるようになった(Fun!, Learn! and Done!)

 JaSSTやDevOps Daysで発表する前は、エンジニアコミュニティ発表未経験の人事の相方は、

  • 人前で話すことじゃないと思っていたのに…
  • こんなの参考になると思ってなかったのに

と考えていた。

 だが、実際に発表してみたら、

  • 感動された
  • 勇気をもらったって言われた

というフィードバックを、発表を聞いた人たちから得ることができた。

 そういったフィードバックから、

  • 努力した事例→人の参考になる、影響を与える
  • けっこうすごいことやってたって気付いた
  • 自分が勇気をあげられると気付いた!
  • 参加だけより発表した方が楽しい

という気づきがあり、

  • やってきたことを誇れるようになった
  • 自信がついた

という効果が本人にあったようだ。

②結果として色々いいことが!(Fun! and Done!) 

 エンジニアコミュニティでの発表により、フィードバック以外にも色々嬉しいことがあったようだ。

  • Slideshareにアップロードした。3000 views
  • ツイッターフォロワーふえた
  • 知り合いふえた

のように、発表がきっかけでコミュニティで新しい人との繋がりを持つきっかけになったみたいだ。

 また、

  • Agile Japan実行委員にさそわれた

なんていう、次の機会に繋がるものもあり、

  • 人前で話すのがさらに好きになった

みたいだ。

③発表内容の工夫(Learn! and Done!)

 前回解説したエンジニアコミュニティでの発表の工夫についての振り返りも出た。

  • 伝えたいメッセージを意識して話した→間、強弱が自然とできた
  • 悩んでる人を想定して話した
  • 具体的事例を盛り込んだことでよく伝わった
  • 写真とか図とかSNSの投稿とか具体的な感じ
  • コンウェイの法則を見せることで問題が明確に
  • Fealess Changeとからめて説明してよく伝わった
  • Fealess Change(あるもの)→ブルドーザー(オリジナル)の流れがよかった

 エンジニコミュニティでの発表の工夫は最初はちょっと敷居が高く感じるが、実際に色々と工夫してみことで学びがあるみたいだ。

おまけ:Fun! Done!Learn!について思ったこと

 今回、Fun!Done!Learn!を振り返りの手法として使ってみて、「自分たちのやっていることを肯定的に捉え、チームや個人のマインドセットや行動のいいところを探し出すのに効果的な方法」だなと思った。

 「エンジニアコミュニティでの発表」を「Done!」することが、「参加だけより発表した方が楽しい」や「やってきたことを誇れる」などチームや個人の「Fun!」や、「努力した事例→人の参考になる、影響を与える」などのLearnに繋がっていることが振り返りからわかった。

 今回この振り返りは発表の後に行ったため、「Done!」→「Fun!, Learn!」の向きの影響が多かったが、スライドの準備段階や発表の練習段階では、「Fun!→Done!」や「Learn!→Done!」向きの影響が増えるかもしれない。

 ともあれ、「Fun!」「Done!」「Learn!」の3つの要素が織りなすサイクルが、チームの健康状態をよくするんだなってことを感じた。

まとめ

 この3回のブログエントリでは、人事の相方のちょっとしたカイゼンの話を見つけて世の中に送り出した話を書いた。気づいていないだけで現場のちょっとしたカイゼンの物語はあなたの現場にもきっとあるはずだ。エンジニアコミュニティでの発表をまだ経験したことない人も、是非挑戦してみて欲しいと思う。

エンジニアが人事のちょっとしたカイゼンの話を見つけて世の中に送り出しちゃった話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をベースに振り返る

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

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

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

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

 

次回に続く

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

モチベーション

 先日DevOps Days Tokyoというイベントで「人事がDevOps研修を作っちゃった話〜恐れ知らずのブルドーザー改革〜」という内容で、人事の担当者と共同発表した。これは、DevOps研修を作るにあたって壁となるコンウェイの法則を乗り越えるため、様々な部署のたくさんのエンジニアをブルドーザーのように巻き込んだ、という人事視点のちょっとしたカイゼン物語エンジニアの技術コミュニティで発表したものだ。

www.slideshare.net

 このブログエントリーでは、この発表が作られるまでのエンジニア視点のアナザストーリーを書いてみようと思う。ここに書く話が、まだエンジニアコミュニティで発表したことがないけど迷っている人や、身の回りのちょっといい話をどうやって育てていこうか悩んでいる人にとって、次のステップに進むためのヒントになったらいいなと思う。

身の回りのちょっとしたカイゼン物語を見つける

人事の相方をエンジニアコミュニティでの発表に誘ったら

 今回、ノリノリで発表してくれた人事担当の相方だけど、エンジニアコミュニティでの発表を最初に誘った時は、実はものスゴく後ろ向きの反応だった。「私はエンジニアじゃなくて人事だし、私のやってることなんて大したことないからエンジニアに話してもつまらない」と。(←これ、JaSST' 18 TokaiやDevOps Daysでのブルドーザー発表を見た人にとっては信じられない話かもだけどもw)

スゴイ研究者や偉いエンジニアじゃなくたって…

 「エンジニアコミュニティの発表ってスゴイ研究者や偉いエンジニアがするもの」って漠然と思っている人って多いよね。たしかに、スゴいエンジニアの、例えば5年後のエンジニアリングに変革をもたらすような話は面白い。AIを活用することで既存のQAの形を劇的に変えるようなイノベーションの話なんかは、僕も大好きだ。

 でも、「自分はスゴイ研究者や偉いエンジニアじゃないから」って理由で、エンジニアコミュニティでの発表をためらう必要はない。世の中のエンジニアコミュニティが一歩でも前に進む内容なら、実績とか立場とか関係なくどんどん世の中に発信した方が、コミュニティにとっても自分にとっても価値が生まれる

現場のちょっとしたカイゼンの話は特に価値がある

 特に現場のちょっとしたカイゼンの話は、多くの人から共感を得られるし、聞いてくれた人に課題解決のヒントをもたらすことがある。僕の中では、この人事視点の物語がたくさんのエンジニアたちからの共感を得られるって確信があった。エンジニアと人事という立場や手法の違いはあれど、チームをよりよくするためのカイゼンをアジャイルに回していくっていう本質は同じだからだ。

 だから、発表することに対してあまり自信がなかった人事の相方を一生懸命説得した。「この人事視点の話をJaSSTで話すことで、アジャイルやテスト自動化で苦労してるたくさんのエンジニアたちが、自分たちのカイゼン活動を見つめ直して新しい解決のアプローチを考えるきっかけになる」って。そうしたら、「なんか騙されている気がするけど…w」と言いながら、一緒に発表することを承諾してくれた。

色んな現場に色んなちょっとしたカイゼンの話が埋もれている

 今回、僕は人事視点のちょっとしたカイゼンをたまたま見つけたのだけれども、色んな現場にまだまだたくさんのちょっとしたカイゼンが埋もれていると思う。それは、もしかしたらあなたのチームにあるかもしれないし、あなたの隣のチームにあるかもしれないし、今あなた自身がやっているカイゼンかもしれない。そういう「ちょっといい話」を見つけるのってすごく大事だと思う。「でもこれはそんな大した話じゃないし」なんて尻込みせず、「世の中のエンジニアリングがちょっとよくなるかも」と、そんなちょっとしたカイゼンの話がどんどんエンジニアコミュニティで公表されたらいいなあ。

 

次回に続く

f:id:kokotatata:20190418091458p:plain