DevLove関西#52 "自動テストの誤解とアンチパターン" に参加してきた

勉強会

DevLove関西を引っ張っている@yohhatuに、はてなに会場提供してもらえないかと相談されたので快諾しつつ、はてなからもid:shiba_yu36とid:hakobe932に発表してもらいました。

簡単に感想などをまとめます。

オープニングトーク by @yohhatu

@yohhatuさんによるDevLove関西オープニングのトーク。DevLove関西は素振りの場、ということで現場で実践する前にまずは勉強会で素振りをしておきましょうという話。DevLove関西恒例のオープニングトークのようで、1月のDevLove関西でも同様のトークが最初にありました。こういうの重要ですね。

はてなからのおしらせ by id:chris4403

僕からはmackrel.ioの紹介と、PerlだけじゃなくてScalaとgoのエンジニアも絶賛募集中ですという話と、6月の超交流会で「京都で働こう！」というトークセッションしますという紹介。
関西のエンジニアの盛り上げに協力していきたいと思います。

自動テストの誤解とアンチパターン by @kyon_mm

自動テストの誤解とアンチパターン in 楽天 Tech Talk
きょんさんによる自動テストのお話。1時間以上もテストについて熱く語れるのすごいなぁというのが率直な感想です。
「統合テスト自動化で得られる最大のメリットはテスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」と言い切っているところも小気味よかったです。

課題をテストで解決する by id:shiba_yu36

DevLove関西で「課題をテストで解決する」という発表をしました - $shibayu36->blog;
shiba_yu36による、チーム内で発生する様々な問題（crontabの設定ミスとか翻訳忘れとか）を自動テストで未然に防ぐというアプローチについての内容でした。
人ががんばってどうにかするのではなくて、仕組みでどうにかしよう、というのははてなブログチームを率いているid:onishiさんがいつも言っていることで、チーム全体にそういう共通認識が浸透していて良いなと思いました。こういう取り組みは、現場が頑張ってやっても、それをちゃんと評価してくれる人がいないと、なかなか続かないものだと思っています。

DevLove後の懇親会で感想を聞くと、人ががんばって解決してた問題をなんとか機械にチェックさせたいと思っていたもののなかなか重い腰があがらなかった／いい方法がおもいつかなかったという方が割りとたくさんいて、ちょっとした工夫で解決できることが分かってよかったと言っていました。

TDDの練習 - ScalaによるCoding Kata実践 by id:hakobe932

DevLove関西でCoding Kataの紹介をしました - はこべブログ ♨
hakobe932による、Coding KataによってTDDを練習する様子をライブコーディングでみてもらうというセッション。
ボウリングのスコアを計算するというのを、テストを書きつつ実装を埋めていってというのを繰り返していって完成させていました。
人前でコードを書くのは緊張すると思うのですが、時間内に肝の部分を説明するように進められていてすごかったです。

こちらも他の参加者の感想を聞いたところ、TDDのやり方、定義は知っているけれど、実際にどういう風にコードを書いているのかを生で見れてとてもためになったという方が多かったです。

まとめ

最後の参加者同士の対話の時間（ダイアログ）も含めて、知識、工夫、実践と自動テストについて幅広い視点でのセッションが詰まった有意義な時間でした。

現場から一歩離れたところから

DevLOVE Advent Calendar 2013 の35日目のエントリです。
昨日はkazinoupさんのエントリは、

アジャイル、スクラムなどのコミュニティで得た価値観は多いに今回の「現場」に役立ったことは間違いありません。

という点が良いなと思いました。本を読んだり、勉強会に参加したりして得た知識やノウハウを、ちゃんと仕事の場で活かせるというのは素晴らしいですね。

自己紹介

id:chris4403です。はてなで開発チームのとりまとめなどやっています。
最近はDevLove関西の方と「開発現場に伝えたい10のこと」を書かせていただきました。
ちなみに23日目のエントリを担当している@shokutoさんとは、大学のサークルの先輩後輩の関係でして、当時は自分が今のような仕事につくとは全く思っていなかったので、こういった場所でつながるのは予想外でおもしろいです。

現場でやっていきたいこと

最近の業務上のポジションは「プロデューサー」と「本部長」です。それぞれの業務内容を簡単に説明しますと、「プロデューサー」は「ディレクター」以下、「エンジニア」や「デザイナ」「企画」「編集」「サポート」で構成される「開発チーム」の数値的な成果（特に売上とか）に責任を持ち、ディレクターに対して施策やチーム運営上のアドバイスを行ったり、目標達成のために「人・金・もの」の調整を行ったり、前者に担当サービスのレポートを行ったりといった内容です。「本部長」はもう少し大きな視点で各プロデューサーからの報告を受けながら、半年、1年、3年先の開発部の方向性を考えて、開発チームへとそれを浸透させていくといった内容です。そういえば会社の求人ページのために、業務内容などをまとめないといけないのでした（締め切り過ぎてるから後で人事の方に怒られよう...）。
ざっくり言うと、楽しく仕事ができて、成果もでるような現場を作っていくことが仕事ってことですね。

そんな中、最近読んだ↓この記事は、色々と考えさせられました。
「「社員は本当に幸せかいな？」日本一の会社を目指すことをやめたナニワの町工場 終わりなき社員教育は何を目指すのか：JBpress(日本ビジネスプレス)」
記事の中で気になったところはこちらのエントリにて、引用しつつコメントを書いています。

先日、「開発現場に伝えたい10のこと」を一緒に書いた@tksmdさんと話をしたときに、私が書いた章の感想をいただきました。@tksmdさんから以下の部分についてもっと話したい！というリクエストをいただいたので、今度飲みにでも行きましょうかと言ってます。

マネージャー職の人は、よく「部下のモチベーションをコントロールしましょう」的なことを言われると思います。「タスクを割り振るときは、そのタスクの重要さをちゃんと認識してもらえるよう説明する」的な話がベストプラクティスとして挙げられるのでしょうか。このモチベーションって、本当に難しいです。部下のモチベーションの前に、自分のモチベーションをちゃんとコントロールできているか考えると、なかなか怪しい。仕事(だけではないですが)に対するやる気は、日々刻々と変わるものですし、体調にも大きく左右されます。なので、僕は「コントロール」ではなく、「把握」するように心がけています。朝出社してからの「おはよう」の声掛けはもちろんですが、仕事中やお昼休みのちょっとした雑談の中で、メンバーが今どのくらいやる気が出ているのかをなんとなく感じ取るようにしています。仕事に対して必ずしも高いモチベーションが必要である、とは個人的には考えていません。人生における仕事に対するスタンスは人それぞれですし、それに正解も不正解もありません。あくまで僕が同僚や部下にできることは、その人とは異なるものの見方や視点を提示して、判断の幅を広げてもらう、くらいだと思っています。

最近は、まさしくこの「モチベーション」という部分について、これから考えていかないといけないなと思っています。近々のモチベーションというより、半年、1年、3年といった先々のモチベーションについて。会社、サービス、チーム、個人の目標や夢がそれぞれどこかでリンクしていて、仕事が単なる仕事じゃなく、メンバーの人生の充実につながっていくようなことが何かできるといいな。

あまりうまくまとまりませんでしたが、「現場」の話は年明けの1/14のDevLove関西のイベントにてお話できればと思っていますので、関西在住の方で興味がある方はぜひご参加ください。
参加登録は↓こちらからどうぞ。
「開発現場に伝えたい10のこと」それぞれの後日談 - DevLOVE関西 | Doorkeeper

次の人へ

次は @banana_umai さんですね。よろしくお願いします！