読者です 読者をやめる 読者になる 読者になる

Test Automation

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

IT勉強会からの越境 #devlove

 このエントリーはDevLOVE Advent Calendar 2014の1月10日の記事として執筆しています。 

執筆のモチベーション:

 昨年度の私のJaSSTSQiPでの事例発表が「IT勉強会からの出口」「IT勉強会からの越境」として取り上げられていた事を受けて、それをテーマに記事を書いてみようと思いました。

 あまり「越境している」という自覚はなかったのですが、上記で取り上げられているのを読み、あぁ自分はIT勉強会から越境していたんだなと気付きまして。越境をテーマにしているこちらのAdvent Calendarに

  • IT勉強会との関わり
  • 何故IT勉強会から越境したのか?
  • 越境して気付いた事
  • 越境を阻むものを乗り越える

について、Fearless Change のパターンを参考にしつつ書きます。

 

Fearless Change

 自分の社内勉強会の活動やIT勉強会からの越境は『Fearless Change』のパターンの文脈で考えてみるとすごく伝えやすいと思います。


楽天ブックス: FEARLESS CHANGE - アジャイルに効くアイデアを組織に広めるための48の - マリリン・マンズ - 462108786X : 本

 

 昨年度のデブサミで監訳の川口さんのご協力のもと著者のサインを集めてからこの本を読み込みました。何かを変えたいと思ったエバンジェリストが組織や社会にその活動を広めていくためのヒントが詰まっている本です。そのヒントも「何か食べながら」「便乗」など結構身近な方法が多く、スラッと簡単に読める本です。

 

IT勉強会との関わり

 自分とIT勉強会との初めての深い関わりは社内で「テックトーク CIスペシャル」という勉強会を企画してからです。この頃はテスト自動化に苦しんでいる時期で、ただ漠然と仲間を増やしたいという気持ちで企画しました。昨年私の周囲では「ぼっち」という言葉が流行したりしましたが、面白いのは社内勉強会は「ぼっち」をつなぐ役目を果たしている面がある事です。

 エンジニアとして自分の仕事の価値を考えた時に、現場で例えば「テスト自動化したい」「キレイなコードを書きたい」「運用設計を開発にフィードバックしたい」といった想いを抱く事があると思います。難しい点はそういった想いを持ったエンジニアは現場では最初少数派である事が少なくない事。特に上に挙げたようなテーマは「クラウド」や「ビックデータ」などと違って、わざわざそれについて組織として特別力を入れようという話にまでなかなかいかないのが難しいところでして。でも、各部署に一人や二人そういったところに悩んでいたり取り組んでいたりするエンジニアがいたりします。

 そういった「部署内ぼっち」をつなげる役目を社内勉強会は一つ担ってるのかなあと感じます。Fearless Changeのパターンで言うと

  • 勉強会(25)
  • 体験談の共有(32)

ですね。

 またIT勉強会にも似たような側面があるのかなあと思います。例えば社内にアジャイルを導入したい、でも自分は社内では少数派、といった場合に社外の同じような経験や悩みを抱えている人と共有するだけでも色々と楽になる事があります。

 

何故IT勉強会から越境したのか?

 もともと自分の中には「越境しよう」というモチベーションはありませんでした。ただ漠然と「エンジニアなら技術で仕事して特許取ったり論文書いたりするのが当たり前でしょ」という考えがあります。なので、いつも仕事をしながら目の前の技術を見て「これはLTネタになるかも」「これは特許がとれるかも」とか「これは論文になるかも」とか、業務とは別の軸での着地点を考えています。

 JaSSTやSQiPなどの発表についても、2年間続けて構築してきた自動テストプラットフォームについて"なんとなく"論文になるんじゃないかと思ってまとめてみたというのがホントのところです。。(ホントは経験論文にしたかったのだけどまとめるまでの時間の都合で事例発表になっていますが 笑)

 もちろんビジネスとしての出口の「成果」やサービスとしての出口の「リリース」も重要です。それと同じくらいエンジニアリングとしての出口の「特許や論文」も大事だと思っていて、そのバランスがうまくとれている会社や仕事はステキだなあと思っています。

 

越境して気付いた事

 そんな曖昧なモチベーションで越境してたのですが、越境してみて実際に色々な気づきがありました。

① 客観的なデータと論理構成に基づく発表

 テスト自動化について仮説を立て、色々な施策を実行しその結果をデータ分析に基づいて客観的に考察したSQiPの発表は、テスト自動化や継続的インテグレーションの導入について決断を下す責任ある役割を担っている方達に特に刺さっていたという話を後から何度か聞きました。

 業界の有識者が集まるシンポジウムという事で客観的なデータ分析と論理構成に特に注力してまとめたのですが、結果的にそういった立場の方達が判断をする際のリフェレンスにして下さっていたり、「あの発表から勇気をもらった」と直接コメントを頂いたりしました。

 IT勉強会の発表では感情に訴えかけるような発表もしばしば重要です。Fearless Changeを一緒に行う現場レベルの仲間を探す時には効果を発揮するし、実際僕自身もそういった発表に救われた事が何度もあります。一方で感情を抜きにした論理的な発表は、少し年配の方や責任ある立場の方に対して

  • 達人を味方に(14)
  • 経営層の支持者(28)
  • 身近な支援者(35)

といったパターンが期待出来るという事が気づきとしてありました。

 

② 襟を正して参加するようなシンポジウムは意外と効果がある

  襟を正して参加するようなシンポジウムの効果は意外と大きいなという事も感じました。

 私の周囲では何がテスト自動化の正解なのかよく分からずみんな手探りであれこれと試しながら成果を出したり失敗したりというのが実情として多いです。で、①でも触れたように、ある層の方達がテスト自動化の成功事例として参照して下さっていたのですね。ソフトウェア品質の有識者が集まるシンポジウムでの発表、しかも賞を頂いたという事が

  • 外部のお墨付き(12)

を得て、テスト自動化の正解パターンの一つとして周囲に認知された背景にあるのかなあと感じます。

 

③ 振り返りと有識者のフィードバック大切

 有識者に見て頂く発表としてまとめる事で、自分達の仕事や成果を俯瞰して振り返る時間を持つ事が出来ました。そういった時間から、例えば「あの時自分たちはAというアプローチで問題を解いたけど、実はBやCといった解き方もあった」など、日常の業務の中からはなかなか得られない気づきを得る事が出来ます。

 また外部の有識者と話す事で、自分たちにとっては当たり前だった"変化"が一般的にはそうではなく、じゃあ何で自分たちのケースではうまくいったのだろうとコンテキストの違いや、ちょっとした工夫の効果について深く考えてみるきっかけとなった事もありました。

 普段の業務から考えるとちょっと特別な

  • ふりかえりの時間(5)
  • 達人のレビュー(31)

を得る事で、日常の仕事の中からはなかなか見つけ出す事の出来ない気づきを得るきっかけになると感じます。

④ Fearless Changeはパターンの積み重ね

 発表を作るにあたってたくさんの専門書を読んだり社外のエキスパートの方達と議論をする中で、エンジニアリングの世界には正解パターンがある事も多いという事を感じました。自分の業務の中に閉じこもっているとなかなか気付かないのですが、業務で出くわす様々な問題や悩みは、もうすでに誰かが解いている事も多いのですよね。

 この2年の中でかなりの数のソフトウェアテストや品質の研究論文を2年の中で読み、また自分でもトライしてみました。その経験の中で、何がもうすでに解かれている問題なのか?それらの問題はどのようなアプローチで解かれているのか?何がまだ解かれていない問題なのか?を自分の中でかなり整理出来てきたのかなあと思います。引き出しの中の正解パターンの数がこの2年で100倍〜1000倍に増えている 笑。

 もちろん、過去の研究や正解パターンを完全に否定する事で起きるイノベーションがある事も重々承知しています。一方で、大きな問題を分解し

  • 種をまく(22)
  • 適切な時期(23)
  • ちょうど十分(34)

といった小さな正解パターン

  • ステップバイステップ(3)

積み上げていくだけでも解ける事がたくさんある、そしてその積み重ねがFearless Changeそのものなんだなあと思います。

 

最後に:越境を阻むものを乗り越える

 ボキャブラリーや文化、考え方の違いが越境を阻む事も少なくないですよね。IT勉強会とシンポジウムや研究会はそういった違いが敷居の高さを作ってるように感じる事があります。ですが、その壁はきっとエンジニア個人の努力で乗り越えられる。

 例えば「アジャイル」と「品質保証」はお互い相容れないと考えられていた時期というのがあったように思います。それぞれが出て来た文脈が違うので一見すると全然異なる事を主張しているのではとギョッとする事があるのかもしれません。でも「継続的デリバリー」と「ソフトウェア品質知識体系ガイド」は、サービスやソフトウェアの品質を継続的に改善して行こうという目的は一緒です。また、たくさんのエンジニアがそれぞれの分野の『越境』をくりかえしてきたため、そこで主張されている方法論についてほとんど矛盾を感じません。

 先日、ソフトウェア開発について「テスト」も「レビュー」も「XP」についても造詣の深いエキスパートの方に「色々な分野でご活躍されてますがご専門は何ですか?」と質問しました。その方の答えは「特に1つの分野に限定して専門を考えた事はない。どんな分野のエキスパートともディスカッションをすると興味深い知見が得られるし、そのためにどんな分野についても議論出来るように勉強している」というものでした。

 目的さえ同じならば、ボキャブラリーや文化、考え方の違いは個々のエンジニアの努力次第で乗り越えられるんだなあ、越境を繰り返すエンジニアによって技術の進歩は支えられていると実感させて下さる、偉大な先輩の言葉でした。

 IT勉強会からの越境に壁を感じたとしても

  • 怖れは無用(46)

です。IT勉強会から越境して様々な分野のエキスパートと出会い、議論する事で、もしかしたらあなたの新しいキャリアが始まるかもしれません。

次の人へ

明日のDevLove Adventcalendar 2014の記事執筆は岡山さをりさんです。

おまけ

1月15日に「自社内で開く「カフェ・ソフトウェアクオリティ」勉強会」というテーマでソフトウェア品質の勉強会を楽天タワー2号館で開催します。ご興味のある方の参加をお待ちしております。


1月15日 カフェ・ソフトウェアクオリティ第24回勉強会(東京都)