#june29jp

RubyWorld Conference 2017 に参加してきた

2017-11-07

RubyWorld Conference 2017

RubyWorld Conference 2017

PB010508

勤め先であるGMOペパボ株式会社が去年からスポンサーとして協力させてもらっている RubyWorld Conference というイベント。今年はスポンサーセッションでおしゃべりする担当として松江まで行ってきました。ぼくも Rubyist の端くれとしてもちろん松江には一度行ってみたいと思っていて、ようやくその願いが叶った形になります。

詳細なイベントのレポートは他に任せるとして、ここの個人サイトには参加者としての個人的なメモを書いておきます。

感想

「来年もまたきたい!」と思える、素晴らしいイベントだった。このような素敵なイベントが9年も続いているなんて、ありがたいことだなあ。2018年に開催されるはず?の次回は記念すべき第10回の開催になるとのことで、ぜひともまた参加したいところです。

松江市だけじゃなく島根県に訪れるのも初だったぼくは、ちょっとした観光も楽しめた。イベントの常連組のみなさんは非常に練度が高くて、空港から松江駅への移動方法や、松江駅周辺の地理情報、イベントの楽しみ方などなど、いろいろと教えてもらえて助かりました。

下の写真は、帰りの日に食べた割子そば。とってもおいしかった。

PB020636

交流

イベント前日夜のウェルカムパーティでは、まつもとさんに「技術顧問業、どうですか?」と質問させてもらって、いろいろと聞けてよかったです。他の人からはまず聞けないような、楽しいお話でした。

他にも直接的だったり間接的だったりでお世話になっている Rubyist のみなさんとお話する機会がたくさんあり、たっぷり2日間ほど充実した時間を過ごせました。これを書きながら思い出してみても、はーーー楽しかったという気分になれます。

宿題

みなさんの講演を見聞きしたり、お話させてもらったりする中で、いくつか宿題が見つかりました。これからの日々で自分なりの答えを探していくぞ。

あとからでも宿題を思い出せるように便利資料リンク集を置いておきます。あと、会場から撤収する間際に @koic さんと話したことがおもしろくて、しかもそのあとにバスの中で @moro さんとも似たような話になって、ぼくはあの続きをやりたいので都内でお話できたらいいなあ、と!そういうテンションになったので週明けの社内で @kenchan に雑に絡んだりしました。

感謝

RubyWorld Conference 2017 の開催に向けて尽力されたみなさん、ありがとうございました。おかげで楽しい時間を過ごすことができました。島根観光の最初のきっかけにもなりました。現地でお世話になったみなさんにも感謝したいです。楽しさがマシマシになりました。

来年も行きたいぞ〜!

このエントリーをはてなブックマークに追加

無理してがんばっている人

2017-11-06

がんばりたくてがんばっている人はそれでいいと思う。心の中で静かに「がんばってね」と応援させてもらう。たまに「がんばりたい」より「がんばらなきゃ」という雰囲気でがんばっている人や、自身の許容量をこえてがんばろうとしている人がいて、心配に感じてしまう。

ぼくが見てきた範囲では、無理してがんばっている人というのは、どこかでそのがんばりをまわりにも押し付けそうになる危うさがある。たとえそれがなんであれ、それを他者に押し付けてしまった瞬間に意味が変わってしまう。継続的にがんばるのなら、自分のコントロールできる範囲で、自分のうちに留めておけるように、無理なく自分でいられるようにがんばるのがいいと思う。

「無理してがんばっている人」を「無理して意識を高く保とうとしている人」に言い換えても同様。つまり、無理している状態がよくないんだ。みんなが無理なくがんばれる状態がいいなあ。

自分はこんなにがんばっているのに──そんなふうに心の声がこぼれてしまう瞬間がある人へ。どうか、一息ついてほしい。無理なくがんばっていきましょう。なんだったら、がんばらなくたっていい。

このエントリーをはてなブックマークに追加

書籍「初めての自動テスト」を読んだ

2017-09-24

初めての自動テスト - Webシステムのための自動テスト基礎

O’Reilly Japan - 初めての自動テスト

那須のせきさん経由でオライリー・ジャパンの高さんから送っていただきました。ありがとうございます!楽しく読んだので感想を書きます。

ざっくり、どんな内容か?

原題は The Way of the Web Tester で、内容としても「ウェブアプリケーションの自動テスト」が中心となっています。また、邦題の「初めての」に意味が込められているように、これから自動テストを導入してみたい、あるいは、導入してみたもののこれからどうやって活用していったらいいかよくわからない、といったフェーズにある人を主な対象としていることでしょう。

途中、基礎知識として HTML や CSS という要素技術や、REST という考え方の概要を説明していたり、Google Chrome の開発者ツールの使い方に紙面を割いていることからも、入門書であろうとしていることが伺えます。

文中に登場するサンプルコードは Ruby on Rails 製のウェブアプリケーションに RSpec か minitest で書いてあるものがほとんどで、第7章では Jasmine で JavaScript のテストを書いています。ただこれは筆者も「サンプルとして示しやすい言語・フレームワークを選んだだけ」と明言していて、他の言語を好んで利用している人たちを想定読者から外すものではありません。

すでにたくさんのテストコードに囲まれて暮らしているソフトウェアエンジニアなら、第1章と第8章を読んでみて、自分の中にある自動テストに対する理解や認識をあらためて整理してみるのがよさそうです。

ぼくが読みながら思い出したのは勤め先の会社でエンジニアインターンシップを実施し、そのメンターを担当したときのこと。インターン生といっしょに Rails 製のウェブアプリケーションの機能開発に取り組んだとき「テストは書いたことがないので、どうやって書いたらいいかわかりません」と相談を受けました。今月にも弊社で同様のインターンシップを実施していて、やはり学生さんは「テストを書いたことがない」という人がほとんど。インターンシップの実施報告にも部分的に書いている通り、ぼくがインターン生に相談を受けたときは以下のようなトピックについて話したと記憶しています。

  • なぜテストを書くのか?
  • どのようにテストを書くのか?
  • テストは先に書く?あとに書く?
  • REST というアーキテクチャスタイルについて
  • 継続的インテグレーションについて

この本には、ぼくがなんとなく「このへんは説明しておいた方がいいかな」と思って話していたことのほとんどが含まれています。継続的インテグレーションについては触れられていないものの、初めてテストを書こうとする人に向けたメッセージはふんだんに盛り込まれているので、次にまたインターンシップのメンターを担当するようなことがあれば、この本を手元に用意しておきたいと思いました。心強い1冊になってくれることでしょう。

ざっくり、どんな雰囲気か?

書籍アジャイルサムライのテイストが好き!という人なら楽しめること請け合い。Jonathan Rasmusson の、あの独特のなんとも言えないテイストは本作においても健在です。

読書メモ

  • 第1章
    • あらためて自動テストとはなにか、なぜか、を考えて気持ちを整理する
    • 開発を加速してくれていたはずのテストがいつの間にか足枷に… わかる、めっちゃわかる…
    • テストだって銀の弾丸じゃないよね
    • ぼくは「テスター」という役割の人とプロジェクトでごいっしょしたことないな
  • 第2章
    • いきなり Capybara で E2E テストを書いていて強い
    • サンプルコードは無駄が少なくて読みやすいですね
    • でも実際の現場ではこのサンプルコードが動くようになるまでのセットアップの方が大変そう
    • 各位、がんばっていきましょう…!
    • スモークテストという語彙を得た
  • 第4章
    • HTTP や URL の講座がはじまっておもしろい
  • 第6章
    • detestable という英単語を知った、テストしにくいってことは忌まわしい
  • 第7章
    • まるまる1章を JavaScript に使っている
    • ちゃんと MVC によって責務が明確になっているコードだからテストしやすくてよかった
    • 最後、テストコードで typo していてテストが失敗するけど、なんであの例を出したんだろ
    • 文字列リテラルの typo の話だから型付けの話ともまた違うのでは?
    • 終盤で「とにかく JavaScript 界隈は変化が激しいからがんばって」と言っている
  • 第8章
    • 逆ピラミッド、またはアイスクリームコーン
    • たまに失敗するテストは削除しちゃう、っていう割り切りはなるほど〜と思った
    • Spotify の「開発生産性向上隊」の話、めっちゃいい
  • 第9章
    • リーダブルコード的な話
    • テストコードにも治安を
  • 第11章
    • この本に「モックとスタブの違い」が書かれているのありがたい
    • 急に白髪交じりのベテランが登場してくるのおもしろい
    • 「モックの泥沼」つらそう
  • 第12章
    • テストファースト
    • 自転車の補助輪を外すようなものなんで、ある程度まで理解できたら実践しましょう
    • いくら勉強しても自転車に乗れるようにはならない、必要なのは練習だ

自動テストと私

  • まわりに「テスト大事」の人たちがいたおかげで書くようになれた
  • 2008年の札幌でかくたにさんもろさんの実演を観覧できたのが幸運すぎた
  • そこを入口にせきさんわださんの言葉を漁るようになった
    • なので今回、せきさんから連絡をもらえているのは自分にとってはすごいことなのだ
  • あとは、幸いにもテストがしっかりメンテナンスされているプロジェクトに関われてこれたので、自然に書く生活を続けられている

今でも「バグが発覚してそれを修正するとき」と「レビュアー向けに Red → Green を見せたいとき」は、ほぼ必ずテストを先に書く体になりました。自動テストに出会ってからもうすぐ10年かあ。

このスクリーンショットは、レビュアーに「ほらね」と見せるつもりでわざと CI を赤くするコミットを先にプッシュしているときの様子。

まとめ

O’Reilly Japan - 初めての自動テストをいただいたので、読んで感想を書きました。これからやる!という人に向けて手渡したい心強い1冊です。読み口も軽快で楽しく読めるところもおすすめポイントです。

このエントリーをはてなブックマークに追加

LDR終了の報を受けてフィードを整理していて思ったこと

2017-08-19

ありがとう、LDR

【重要】Live Dwango Reader/LDR Pocketサービス終了のお知らせ|LDR / LDRポケット 開発日誌

ドワンゴさんが引き取ってくれたものの、それも延命措置にしかならず、今度こそ本当に LDR とお別れすることになるっぽい。ちょっと気になって調べてみたけれど、ぼくがいつから LDR を利用しているかはわからなかった。LDR 以外のフィードリーダを常用していた時期もあってそれを突き止めるのはなかなか難しいのだけれど、このブログの2007年9月19日の記事で LDRize についてアレコレと言っているので、少なくともこのときには LDR を認知していて、身近な存在と感じていたことは間違いないだろう。2007〜2009年ごろには、フィードリーダはぼくにとって「情報収集のための必携ツール」だったのだ。

そうすると、丸10年くらいは LDR の存在する世界で過ごしてきたことになるので、あらためてこれはすごいことだなぁと思う。いつごろからか Twitter のタイムラインを熱心に見るようになり、フィードリーダからやや遠ざかっていた時期もあった。それから Twitter のある世界で何年か暮らし、でもやっぱりぼくは「日記を読むのが好きだ」「そしてそれは、流れてくるツイートを読むのとは確実に異なる体験だ」と思うに至り、主に「友だちやウェブ上で見かけるなんだか好きな人たちの日記をなるべく欠かさずに読む」ためのツールとしてフィードリーダを愛用してきた。

そして2017年7月、冒頭に置いた LDR 終了のお知らせが届いてしまった。

まずはとにかく、登録してあるフィードの情報を失うわけにはいかないのでエクスポートだ。ぼくらには OPML 形式があるので、特に困ることなくよく知ったデータ形式で登録フィードの一覧データを手にすることができた。

さて、むずかしいのはこのフィードのリストをどう扱うか、だ。ざっくり、3通りの未来があるだろうか。

  • (1) もうフィードリーディング生活をやめる
  • (2) 別の既存のフィードリーダに移行する
  • (3) あらたにフィードリーダを自作する

とりあえず (1) はナシだなあ。友人をひとり失うような、そんな喪失感を伴いそうなので (1) はナシにしよう。なので (2) or (3) で考えてみる。ここで、LDR を使いつつもフィードリーディングが疎かになるときのことを思い出した。それは「なんとなく LDR にアクセスしない時期」だ。だいたいのフィードリーダは「アクセスする」「起動する」が行動の起点となるので、これが習慣にならないと一気に疎遠になる。これと対比して、たとえば「はてなブックマーク - マイホットエントリー」のデイリーのお知らせメールは、メールボックスさえチェックしていれば目に触れることになるので、わりと自分の生活には定着していた。こういう形でのフィードリーディング生活を目指してみるのはどうだろうか。

その筋で考えたときに最初に思い浮かんだのは Slack の RSS Integration だった。常に開いている Slack Team がいくつかあるので、そこに自分のフィードリーディング用のチャンネルを用意し、新着フィードを流してやればよいのではないか。しかしこれだと、新着を検知するたびにチャンネルに通知されてしまうから気が散るかもなあ、というところが難点。

でも「Slack で通知を受け取って読む」というのは、今の自分の生活スタイルにあっていて悪くない案に思えた。というわけで。LDR からエクスポートした OPML ファイルを種に、1日1回の頻度で直近1日分の新着エントリを Slack に通知する雑なスクリプトをこしらえて、動かしはじめてみた。

新しい生活をはじめてから1週間ほどが経過した。おおむね快適に過ごせている。2017年のぼくは、フィードリーダに UI を求めていないということもよくわかった。新着エントリのリストさえ手に入ればいいのだ。Slack であれば、最短でも向こう1年くらいは使い続けるであろうから、受信装置としては充分だ。また、Slack から別の舟に乗り換えるときがきたとしても、通知先をちょいっと変えてやれば済むだけの話。当面はこの運用を続けてみよう。

結果を見ると、そんなにだいそれたものではないけれど (3) の「自作」を選択していた。

フィードを整理していたときのこと

1日に1回だけ実行される、100行にも満たない、雑なスクリプトを書いていたとき。デバッグのために500件ほどのフィードのエントリをだばだばとコンソールに出力して眺めていると、ずいぶんと懐しい気持ちにさせられた。

失効してしまったドメイン。アクセスすると404を返してくるブログ。すでにクローズしてしまったブログサービス。それらの URL は、そっと購読データから消してやった。これがなかなか寂しい作業で。LDR に登録してあるだけだと新着エントリが上がってこなくなるだけなので、対象サイトが生きているのか死んでいるのかは気にせずに過ごしていたのだあ。自前のスクリプトでは、アクセスできなかったら新着エントリの代わりにその旨を Slack に通知するようにした。もしこれからサイトの死に気付いてしまう瞬間があったら、そっと目を閉じて手を合わせるのだと思う。

何年も前に更新が止まってしまっているブログもたくさんあった。これらは、サイトとしては生きているので、フィードは問題なくパースできた。途中、新着かどうかを判定する処理をミスって、全エントリを延々と Slack に通知してしまったときがあって。2006〜2012年ごろに元気よく更新されていたブログのフィードが、まるできのう今日に更新されたかのようにばしばしと通知された。友人のブログの古いエントリから順に「2006年mm月dd日 ◯◯を作りました」「2007年mm月dd日 △△に参加しました」と通知が送られてくると、まるでタイムスリップしたかのような感覚を味わった。大学時代の自分は、フィードリーダでそのブログを熱心に読んでいたのだ。もうしばらく思い出さずにいた内容ばかりだったので、判定ミスでバグっているスクリプトから数秒間隔で送られてくる10年以上前のブログの「新着エントリ通知」を、ぼくは楽しく読んでしまった。「次のエントリ、はよこい!」と。

そうしてあらためて「やっぱりブログはいいなあ、どんなことでも書いておくといいなあ、人々の日々は尊いなあ」と心から思い、だったら自分もブログを更新しよう!という気持ちで、今日のこの気持ちを綴ってみたのであった。

このエントリーをはてなブックマークに追加

2017年下半期の成長計画づくりワークショップ

2017-07-21

ぼくの勤め先であるGMOペパボ株式会社では1月から6月が上半期、7月から12月までが下半期という区分です。2017年も明けて「今年もがんばるか〜」と思っていたのが先日のはずなのに、気がつけば下半期が始まっていました。というかすでに7月も下旬ですね…すみませんでした。

ペパボには期ごとに運用される評価制度があって、2017年下半期が始まったので「目標設定やらなきゃ〜」「今期はどうしよっかな」「面談やりましょうか」といった声があちらこちらから聞こえてきます。期初の風物詩です。評価制度についてはすでに様々な場所で語られていて、エンジニアの評価制度について - console.blog(self);の記事に他社のものとあわせてまとめられていたのでリンクしておきます。

2017年1月にペパボの本社事業部のチーフテクニカルリードになりましたで触れた通り、ぼくは今年からひとつの事業部(当時は「本社事業部」でしたが、今では名前が変わって「SH事業部」になりました)のエンジニア組織をいい感じにするミッションを授かっていて、2回目の期初となるこの時期をどのように過ごしたものか考えていました。そして、自分を含むみんなの2017年下半期が最高のものになるようにと、表題にある「成長計画づくりワークショップ」を実施するに至ったので、その顛末を紹介したいと思います。

これまでのふりかえり

ぼくは2015年5月の入社なので、これまでに5回の期末を経験してきました。期末には、その期の評価制度の締めとなる面談があります。そこで、半年間の実績について話したり、得たものや苦労したことなどを整理し、次の半年間につなげるための時間を過ごします。「評価制度」というくらいですから、評価結果も当然あります。各自が自分の目標や実績と自己評価などをまとめた「評価資料」を作成し、面談ではそれをもとに会話を重ね、最終的な評価結果を得ます。

さて、このときにアンハッピーな事態が起こり得ます。被評価者の自己評価と評価者が出す評価にズレが生じることがあるのです。面談等の場で会話を通じて認識のズレを解消できればまだよいですが、場合によっては完全には納得できないまま評価を下されることになるでしょう。これは、被評価者にとっても評価者にとってもうれしくない事態です。

では、なぜこういった事態が発生するのでしょうか?ぼくが見聞きしたケースには、以下のような要因があったように思えます。

  • 目指すべき方向が共有できておらず、あらぬ方向に突き進んでしまった
    • 評価者が「そっちじゃないんだよなあ」と思ってしまう
  • 目指すべき方向はあっていたが、どこまで進めば充分かを共有できていなかった
    • 評価者が「もっと進んでほしかったなあ」と思ってしまう

「西に10km以上進んでほしい!」という期待に対して「北に10km」だったり「西に5km」という実績になっている、という状態です。認識のズレが原因で評価が高くならないようだと、被評価者は「せっかくがんばったのに…!」とモチベーションを下げてしまうかもしれませんよね。そんな事態は可能な限り避けたいものです。

なにを隠そう、ぼくは2015年下半期の面談に「自己評価はSです」と臨んで「じゅんくん、そういうことじゃないんだよ」と見事に散りました(?)からね…!ぼくの場合は別にモチベーションを下げることはなくて、フィードバックを受け止めて「たしかにそうだよな〜」と思えたので、よかったといえばよかったですけれども。にしても、期末じゃなくて期初に気付いていれば、もっと有意義な半年間を過ごせただろうとは思います。今にしてみれば。

じゃあ、どうすれば認識のズレによるアンハッピーな事態を回避できるのか?を考えてみましょう。ところで、認識のズレによって失敗する先述のようなケースを見たとき、ぼくは「なんかこの失敗、経験したことある気がする…」と思いました。プロダクト開発に携わっている人なら、もうピンときたかもしれません。

  • 顧客が必要としていない機能を開発してしまった
  • 顧客が望む機能ではあったが、品質が充分ではない状態でリリースしてしまった

こんな状況に、とっても似ていると感じました。耳も胸も痛いですね…!人はなぜ、よろこばれないお仕事に多大な時間を費やしてしまうのか… ウッッ!っと傷つくのはあとでゆっくりやることにして、ここは歯を食いしばって先に進みます。もしこれがプロダクト開発における問題と同種ならば、よく知られたプラクティスによって問題を回避できる可能性があるのではないか、と仮説を立ててみます。

プロダクト開発の心強いプラクティス

今回ぼくが取り入れることにしたプラクティスは、以下の2つです。

(1)によって、目指すべき方向があっているかを事前に確認できます。(2)によって「こうやるともっと先に進めるかも」という発想が促されることを期待します。どちらも、最近のプロダクト開発、ソフトウェア開発の現場ではふつうに実践されているような内容かと思います。むしろ、どうして今まで評価制度の運用には取り入れてこなかったんだろう、と思うくらいで。

成長計画づくりワークショップ

やってみました、ワークショップ。

まず、最高にハイな状態で2017年下半期の終わりを向かえた自分のことを想像し、すべての項目でS評価の自己評価を記入した評価資料を作成します。社内で2回に渡ってこのワークショップをやってみたところ、参加者のみなさんは15〜20分くらいで書けていて、素晴らしいな〜と思いました。イメージをつかんでもらうためのサンプルとして、ぼくの2017年下半期の評価資料をつくって持っていったのですが、ぼくは書き上がるまでに40分くらいかかりました。ぼくだけズルしてごめんね。サンプルとしてわかりやすいものにしたかったので、みなさんよりじっくり取り組ませてもらいました。

みんなの分が出揃ってきたら、それを参加者のみんなでいっしょに見てレビューをします。ワークショップの中では、このレビューのことを「MOD」と呼ぶことにして、みなさんには「じゃあMODをお願いします!」のように呼び掛けました。MODはもちろん、ペパボの企業理念であるもっとおもしろくできるの略です。すんばらしい未来の姿を描くためのワークショップなので、ネガティブなフィードバックよりもポジティブなフィードバックがたくさん出るようにと願いを込めて「みんなでMODしましょう〜」と声をかけていました。

誰かが「こんな成果が出すことができた!」と下半期の実績を語れば「しかも、それをテックブログに書いていてめっちゃよかったよね」と誰かがMODします。「PHP 7.2 へのアップグレードが完了しました」「あれは対応が早かったね、リリースされてから1週間以内でキャッチアップできていてすごかった」や「◯◯をプロダクションに導入できました」「それを見て入社してきた人もいましたよね〜」なんてやりとりもありました。まあ素敵!

ワークショップをやってみて

なんにせよ初の試みなので不安もありましたが、参加者のみんながしっかり乗っかってきてくれて、とっても楽しい時間になりました。「半年後の最高の俺たち」の姿を見ることができたので、なんだか誇らしい気持ちにもなれます。各自、自分の口から「こうなっていました」をみんなの前で表明したことで、もうやるしかないぞ〜という気持ちになってくれたんじゃないかなぁと思います。

「2017年下半期の評価資料」という中間成果物にはけっこうなエネルギーがあって、うちの事業部のエンジニアたちがつくってくれた資料は、他の事業部のエンジニアたちの目にも留まって「え!なにこれ!めっちゃいいことが書いてある」という反応につながりました。そうして、けんちゃんくんさんが CTL を務めるお隣の事業部でも同様のワークショップを開催させてもらうことができました。

2回ともおおいに盛り上がったので、まだまだ改善の余地はあるでしょうが、悪くないワークショップができたと感じています。今日もうちの事業部では、みんなで見た未来を現実のものにしてくれそうな勢いある行動を見かけましたよ。やったね!

まとめ

  • 2017年下半期が始まったので、最高の半年間にするためにワークショップを開催してみました
  • このワークショップは、もともとあった評価制度をさらによいものにすべくプロダクト開発のプラクティスを取り入れた内容になっています
  • 参加者みんなで盛り上がって楽しい未来を見てから現在に戻ってくるので、みんなが元気になるのもうれしいです
  • これまでの目標設定は「各個人のもの」か「当人と上長のもの」に留まりがちでしたが、これがチームで共有されてフィードバックしあえるようになるよさもあります

みなさんの現場で成長の加速のために工夫していることなどあれば、ぜひぜひ教えてほしいです。ぼくたちももっともっと成長していきたいので、よさそうなものはどんどん取り入れて自分たちを変えていきたいです。

もしこのエントリを最後まで読んでくれたペパボの人がいたら、ぜひ社内でも共有してください。「自分も成長したいとは思っているけれど、下半期をどんなふうに過ごしたら成長につながるかはまだわかっていない…」そんな人がいたら、そう思えた今が好機です。いつでも話しかけてきてください。もちろん、エンジニアに限らず。きっと力になれると思います。

それでは、2017年の後半戦も楽しんでいきましょう〜!

このエントリーをはてなブックマークに追加

これからチーム開発に立ち向かう花ざかりの君たちへ

2017-06-29

2017年度新卒研修がはじまりました! - ペパボテックブログ

上記エントリにあるように、今年の4月に入社してくれたフレッシュ・フレッシュ・フレーッシュな若者たち、社内では「新卒7期生」と呼ばれているみんなの研修の日々が続いています。毎日、彼ら彼女らががんばる姿を見ることができて、刺激的で楽しい最近を過ごしてきました。どうも @june29 です。

今は職種別の研修期間に突入していまして、エンジニア研修の座学もはじまりました。この座学は、ペパボの仲間たちがかわるがわる教壇に立ち、7期生に知っておいてほしい内容をおおいに語る時間になっています。下記は、座学講師を募集するインターネット掲示板の様子です。

ぼくも、ペパボに入社した2015年、その翌年の2016年と、こうした新卒生たちと交流する機会には積極的に関わってきました。自分とは違う世代の人たちと話していると気付くことが多いですからね。少しでもお近付きになりたいといつも思っています。

今年も「俺がやるぜ〜!」という気持ちはありつつ、うちの事業部にいる「自分がおもしろ人間であることをあまりアッピールせずにいるズルい人たち(?)」にこそどんどん前に出てほしいという想いがあったりして、座学の枠が少しずつ埋まっていく様子を一歩引いた位置から眺めていました。そんな、ある日。

今年のエンジニア研修の船頭役を務めている @asuforce@shimoju_ から「6月29日の枠が空いていまして」とお声がけいただき、この枠にふさわしいハンドルネームを持つ者は @june29 をおいて他にないだろうということで、ありがたくお引き受けしました。ふたりが与えてくれたテーマは「チーム開発」です。この瞬間から、ぼくがこれまでの10年間ほどの経験を思い出し、チーム開発について自身の考えをまとめあげていく時間がはじまったのでした。

3章から成る構成にしたものの、今日伝えたかったことは「チームについて」がほとんどでした。このあとに続くたくさんの座学の中で、ソフトウェア開発については、他の講師のみなさんが素晴らしい教えを示してくれるでしょうから、ぼくはそちらに任せることにしました。

花ざかりの君たちへ。これから過ごす日々に、楽しいチームと楽しいソフトウェア開発がありますように。応援しています!ソフトウェアエンジニアの定年退職まで残り1年となったぼくからは以上になります。

このエントリーをはてなブックマークに追加

「自分の側にあって、相手の側にないもの」を正しく伝えること

2017-04-24

自分が日々のコミュニケーションの中で「これを重要視しているな〜」と気付いたものがあったので、整理のために書きます。ここでは「情報をやりとりする」タイプのコミュニケーションを扱います。

そもそもコミュニケーションとは、異質な2つのものをつなぐためのものです。もし、あなたとぼくが完全に等しい存在であったとしたら、そこにコミュニケーションは必要ありません。我が家はなかよし夫婦だとは思いますが、奥さんとぼくは異なる存在であり、性格も価値観も所属も経験してきたことも違うので、その差分を楽しむために日々コミュニケーションを取っています。はい。

「相手と自分は違うものである」という前提が、とっても大事。そう考えると、誰かとコミュニケーションを取るときには「自分の側にあって、相手の側にないもの」を正しく伝えることが重要であるということがわかってきます。

お仕事でのやりとりを想像してみても、そうですよね。ぼくはソフトウェアエンジニアなので、他の職種の人とやりとりするときには「ソフトウェアエンジニアリング」の観点から他のみなさんに情報提供することを心がけています。

また、スケジュールの相談についても同様です。ときに、恐らく相手を思いやる気持ちによって、作業をお願いする側が「そんなに急がないので、今やっている作業が終わってからでよいです」と言ったりします。それに対して引き受ける側が「すぐ終わるんで、今からシュッとやっちゃいますね」と返したとしましょう。

  • 「そんなに急がないので」はけっこう曖昧なので、より詳細な情報を伝えられるとよさそう
    • たとえば「今日中に終われば最高、今日で終わらなそうな場合はいつ終わるか知りたい、今月中に終わらないようなら相談したい」くらいの情報があると判断に役立つ
  • 「今やっている作業が終わってからでよい」は、自分より相手の側の事情に立ち入っているので、確度の高い言及はむつかしそう
    • このやりとりでは結局、引き受ける側が「すぐにやっちゃった方がいい」と判断している

お願いする側がどれだけがんばったとしても、引き受ける側の都合を100%理解して引き受ける側の代わりに判断することはできませんからね、そこに力を注ぐよりは、自身が持っている情報を適切に示して引き受ける側が判断しやすい状況に近付けるのが得策でしょう。ポイントは「相手を思いやること」と「自分が持っている情報を正しく伝えること」は両立できるということです。前者だけを考慮しようとして「なんだか忙しそうに見えるし、今日中はむつかしそうだから、今週中でお願いしてみようかな…」と想像することはできますが、どこまでいっても想像することしかできません。それならば、しっかり後者をこなしていくのが、誠実なコミュニケーションだとぼくは思います。

こういったやりとりは実際にちょくちょく見かけるので、それぞれの現場でコミュニケーションを改善できないか?を考えてみるのもよいのではないでしょうか。

(関連) 「わたしメッセージ」へ、そして「わたしたちメッセージ」へ。

以前に「わたしメッセージ」という考え方について書いたことがありました。これもコミュニケーションにまつわる話で、簡単にいうと「主語を “わたし” にしましょう」というものです。実は、主語を “わたし” にしてやりとりしていると、自然と自分側の情報を相手に伝えていくことになるので、あわせて紹介しておきました。

このエントリーをはてなブックマークに追加

「第2回エンジニアリングマネージャー勉強会」でトークしてきた

2017-02-21

ペパボの本社事業部のチーフテクニカルリードになりましたに書いた通り、2017年1月から社の事業部のひとつのチーフテクニカルリード(通称: CTL)を任せてもらっていて、今年はエンジニアリングマネージメントについての考えも深めていきたいと思っています。なにかを学ぶときに発表の機会を持つのは常套手段ですから、今回のイベントが GMO Yours で開催されると知った瞬間に「トークしたいです」と手を挙げました。

第2回 エンジニアリングマネージャー勉強会 - connpass

以下、トークで使った資料です。

資料だけ見てもよくわからないでしょうから、このエントリでいくらか補っておきます。

大切にしてほしい3つのこと

弊社には大切にしてほしい3つのことというものがあります。社内のみなさんは当然知っているでしょうし、噂によると採用面接のときにも「これ知っている?」と話題に挙がることが多いそうなので、これから弊社を受けようと思っている人もチェックしておくとよいでしょう。

  • みんなと仲良くすること
  • ファンを増やすこと
  • アウトプットすること

さて、この3つを試しに読み上げてみると、どんな感想を抱くでしょうか?ぼくは「けっこうふつうだな」と、入社直前にはそんなふうに思っていました。どれも「あなたは大切にしていますか?」と聞かれたら「ええっと… はい、大切にしていると思います」と答えてしまいそうな内容に思いました。

これ実は、社のエンジニアにとっては半年ごとの「評価」にも大きく関わっている話で、この3つが評価の軸にもなるんですね。この3つそれぞれについて「あなたはこの半年間、どれくらいできていましたか?」と問われることになるので、自身の評価資料を作成するにあたって、多かれ少なかれ向き合うことになる3ヶ条です。

今でもはっきりと覚えている、ぼくが入社してから初となる期末の評価面談のこと。ぼくは「みんなと仲良くすること」の自己評価を、最高評価の「S」として面談に臨んだのでした。面談相手を担当してくれたのは @hsbt さんと @kenchan くんさんです。

さて、ここでぼくの面談の数日後のチーフエンジニアの日報の一部を見てみましょう。

面談、みんなと仲良くする、アウトプットするという部分について同じことを色んな人にひたすら繰り返し説明しているので書いておこうと思う。

みんなと仲良くするという項目で違うチームとコミュニケーションをとって開発したので評価A,Sですという人が多々いるけど、専門職であるエンジニアにとって、それは業務を遂行する上では当たり前であり「仕事をしていました」と同義なので、それらが優れた実績である、とは評価することはできない。

ではどういうことが優れているのか、というのは等級にも影響するものの、大別すればコミュニケーションをとる範囲が等級で求められているものに比べて事業部、会社を超えているなど範囲が広いであったり、コミュニケーションの創発が自らの活動によって引き起こされたものであったりする、というような場合に優れている、と評価可能と考えている。

つまり、「自らが何をした、何を実現した」ということが引き金となって、コミュニケーションを取れるようになった、コミュニケーションが高いレベルで取れるようになった、という事実を主張した上で、この何をした、ということが優れた実績なのだ、という主張が初めて可能となる。

ウエーイ、視座が低かったワイのことが書いてあるぞ〜〜〜。まさにこれと同じような話を面談のときに言ってもらえて、たしかにそうだよなぁ、ワイはちょっと捉え方が狭かったよなぁ、と痛感し、面談の直後に自己評価を下げたのでした。

この体験を経てぼくは、大切にしてほしい3つのことと出会い直すことになりました。なんとなく日々を過ごして、期の終わりにただ受動的に評価を受けとるのではなく、もっとかっこいい自分になるためには日々をどっちの方向に変えていったらいいかを、この3ヶ条とにらめっこしながら真剣に考えるようになりました。そうして、件の面談があった次の期から自身の活動範囲を拡げて「本社事業部エンジニアの会」というものを発足し、それからいくらか経って本社事業部のチーフテクニカルリードになり…。あの面談を経て考え方をスイッチできたことが、今のぼくの日々につながっていたのですねぇ。

というわけで、弊社においては「大切にしてほしい3つのこと」を各自が解釈して自分の日々に還元していくことは、とっても大事です。ただ、ぼくは自分ひとりではその道を見つけられず、より視座の高い人たちとの会話によってようやく気付くことができました。

こういった指針が明文化されているのは、とても心強いことです。この指針に従って行動していけば、社内で多くの人に喜ばれる可能性が高いわけですからね。漠然と「いいエンジニアになれ!」と言われる場合に比べて、考えるためのヒントが散りばめられているのはありがたいことだと思います。加えて、それを各自が自分の文脈に落とし込んで解釈することも大事です。指針があって、解釈がある。そうして初めて、各自が自身の行動を変え始めることができると思います。

ぼくは本社事業部のチーフテクニカルリードなので、本社事業部のエンジニアのみなさんが、各自が思い描く「もっとかっこいい明日の自分」になるために、これらの指針をヒントにしながらどんなことに取り組んでいったらいいか、いっしょに考えていきたいです。もちろん CTO やチーフエンジニアが日々の中で発しているメッセージの中にエッセンスはふんだんに含まれているわけですが、本社事業部に属している分、よりみなさんに近い立場で、隣でいっしょに考えられるような存在でありたいと思います。

最近、社の Slack に上の画像のような3つの Emoji を追加しておきました。社内の誰かが「これは、高いレベルでみんなと仲良くしているなあ!」と思ったら「み」の Emoji Reaction をつけますし、他2つについても同様です。こうして「なるほど、こういう行動・活動がかっこいいのだな!」という具体例が広く可視化されれば、エンジニア各位、ひいては社内の全員が、もっとかっこいい自分になるための道を見つけやすくなるだろうと思います。きっと、そうなるであろうことを願って、今日もぽちぽちと Emoji Reaction をつけていきます。

これは Rebuild: 174: One Thousand Custom Emojis (sotarok) でメルカリさんの Slack 文化の話を聴いて速でパクりました。

あまり明示的に「マネジメント!」という言葉を持ちながら今のポジションでお仕事しているわけではないのですが、広義にはこういったこともエンジニアリングマネージメントの範疇なのかな〜と思い、こんなお話をさせてもらいました。

このエントリーをはてなブックマークに追加

イベント「東京工業大学CBECエンジニアリングデザインコンペティション」に参加してきた

2017-02-18

東京工業大学 CBEC エンジニアリングデザインコンペティション 2017

こちらのウェブサイトにも記載されている通り、弊社ペパボも協賛させていただいておりまして、また、ぼくはコンペティションの審査員として参加してきました。自分が審査員だなんて恐縮〜というのが正直なところですが、このような光栄な機会はそうそうないだろうとも思って、お引き受けいたしました。審査員席と書かれた席は最前列に用意されており、おかげで、全13チームのプレゼンテーションをたっぷりと堪能することができました。

審査結果の発表後にはマイクもまわってきて… そこでも述べさせてもらったことをここにも書いておきます。とにかく、どのチームのプレゼンテーションもおもしろく刺激的で、感心しっぱなしでした。

ひとつには、「ユーザの声を聞くこと」がしっかりと実践されているのを感じたこと。エンジニアリングデザインプロジェクトの特任講師を担当されている @kdmsnr さんからお話を聞かせてもらったところ、これはプロセスに組み込まれているとのことでした。最初は「えー、そんなのできるかなあ」という反応の学生さんも多いそうですが、一度経験してしまえばできるようになるのだそうで。こうして、学生時代に「問題発見と問題解決」のプロセスを体験した若い世代が社会に出ていく未来を想像すると、世の中のものづくりをきっとよい方向に変えてくれるだろうと期待せずにはいられません。

もうひとつには、ハードウェアとソフトウェアをうまく組み合わせたプロダクトが多かったのも印象的でした。協賛に 株式会社ウフルさんや DMM.make AKIBA さんが名を連ねているところを見ても、そういった流れがあることは間違いないでしょう。そしてそれが、2017年の学生さんたちからすれば「ふつう」のことなのだろうとも思って、頼もしく感じました。

どちらの要素も「ぼくの大学生時代との比較」という意味で新鮮なわけです。ぼくが大学にいた時期と言えば、もろに「Web 2.0」の潮流のさなかにいて、思い返してみると「個人でなにかソフトウェアを作り上げて世に出せる」そのことに大きな価値を感じていた時代だったと思います。それが今や、ソフトウェアだけじゃなくてハードウェアの自作もグッと安価に気軽にこなせるようになり、ただ作るだけではなく、真に必要とされるものを作ろうとするフェーズに移行していると感じます。この10年足らずの間に、ものづくりをとりまく環境は、どんどん変わっていっているのだと感じずにはいられませんでした。

最後は、おまけとして弊社の協賛企業ブースの写真を紹介します。

ぼくらはいつも採用目的。ふたりの距離つなぐ採用活動。

この写真はくろくんのインスタグラムから。たくさんの学生さんたちと交流できて、とっても楽しかったです。弊社も、もっともっと学生さんたちとの接点を増やして、学生さんたちに喜んでもらえるような取り組みをたくさんやっていきたいなあ。

このエントリーをはてなブックマークに追加

イベント「エンジニアとして、地方ではたらく。」に参加してきた

2017-02-14

【増枠!】エンジニアとして、地方ではたらく。 - connpass

先日も「LOCAL Community Summit 2017 に参加してきた」というエントリを書きまして、ここのところたまたま「地方とソフトウェアエンジニア」というテーマで考えさせられる機会が続いています。弊社は東京と福岡という2つの場所にオフィスがあるし、ぼくは北海道出身だし、ということで、ぼんやりとでも考えることがあるテーマではありますね。

同じ期間に在籍してきたわけではないけれど、同じ釧路高専の出身者として交流が続いている後輩の @frkout くんが立派にトークしていて、自分のことじゃないのにうれしくなりました。卒業から10年以上が経った最近、母校によってもたらされるつながりにじんわりと感謝の気持ちを感じることが多々あります。登壇ついでにうちのオフィスも見学してもらって、ちょっとの時間だけどゆっくりお話できてうれしかったです。またこっちに寄る機会があれば気軽に声をかけてほしいな〜。

弊社からは @pyama86 さんが登壇しました。急に決まった代打での登壇だったけれど、そこはさすがの @pyama86 さんでしたね、場を魅了する姿には感心してしまいます。同僚とはいえ別オフィスの勤務となると、実はゆっくり話したことがなかったりするので、こういった機会にちょっとでも話せるのはうれしいなあ。弊社の福岡メンバーズにお話を聞かせてもらうたびに「福岡に遊びにいきたい」と思わされるので、今年はなんとか理由をつけて福岡オフィスにご挨拶に行きたいと思っています。

Misoca@toyoshi さんに久しぶりにお会いできたのもうれしかったです。事業も順調そうで、ご活躍されていて素晴らしい。お互いに近況報告できてよかったです。愛知方面に遠征に行くときには、どうぞよろしくお願いします。

平日の夜、お仕事を一段落させてからオフィスビルの階段を降りていって、ふらっとこういうイベントに参加できて俺得でした!みなさん、お疲れさまでした〜。

このエントリーをはてなブックマークに追加

もっと古いエントリへ