嫌われない勇気

※ベストセラーになった書籍『嫌われる勇気』からタイトルをもじっただけで、その書籍とこのエントリの内容に関連はありません

このエントリは、はてなディレクターアドベントカレンダー16日目の記事です。

advent.hatenablog.com

サブディレクターという仕事

ぼくはMackerel というプロダクトの開発チームに所属しています。これまで、2年弱アプリケーションエンジニアとして仕事をしてきましたが、今年からチームのサブディレクターに就任しました。

サブディレクターということで、厳密にはディレクターではありません。チームのメインディレクションは、ディレクターのid:Songmuに権限があります。

Mackerelチームは、はてなの中でもかなりの大所帯で、エンジニア、デザイナ、セールス、マーケティングと多用な職種の人が在籍しています。ロケーションも東京と京都、愛知(自宅からのリモート勤務)と多岐に渡っているため、ディレクター1人ですべてを差配するのは難しくなってきました。そこでぼくが、サブディレクターとしてディレクターを補佐しながら、主に自分自身も勤務する京都側のメンバーの取りまとめなどをやっています。

Mackerelの開発には乱暴に分けると2つの軸があります。チーム主導で行う継続的な開発と、他社さんとの共同開発です。前者は、我々開発チームがプロダクトの現状や市場の状況・ニーズなどから優先度を決め、自発的に開発を行っていきます。後者は、例えば先日リリースしたTwilio連携などのように、他社のサービスとのコラボレーション機能の開発で、これは連携先の企業と共同して進めることになります。

タイミングによっては、このような他社との共同開発が並行で複数動くこともあり、こういった場合ディレクターのid:Songmuと、サブディレクターのぼくとで分担して開発の舵取りをしたりします。

また、Mackerelチームでは開発手法として、スクラムを採用していますが、専任のスクラムマスターがいません。かわりに、スプリント計画に対する決定権や責任はid:Songmuが持ち、振り返りや日常のスクラム的な行事の推進はぼくが勤める、というようにスクラムマスターの役割を分担していたりもします。

そういうわけで、サブディレクターという何をやってるのか字面だけではわかりにくい職ではありますが、ぼくの仕事は、

といったところになります。あとはプロダクト開発にも直接かかわっていて、一部の機能開発でコードを書くこともしています。

仕事相手に嫌われてはいけない

こういった仕事を進めるにあたって、最近重視していることがあります。それは「嫌われない」ことを意識する、というもの。

若い頃、当時勤めていた会社の上司から、「お前はもっと人に嫌われることを怖がらないようにしないといけない」ということをよく言われました。仕事は仲良しこよしのグループではないので、馴れ合う場ではない。自分の主張すべきことはきっちり主張せねばならず、「こんなことを発言したら嫌われるのではないか」「もっと他人に対していい顔をしたい」というようなことは仕事を阻害する要因となる、といったニュアンスでしょうか。異論の余地なく正しい指導だと思います。

ただ、ぼくはこの「嫌われる」という表現にずっと違和感を持っていました。もちろん仕事で他者との衝突を必要以上に恐れてはいけないし、異なる意見をぶつけあうことで新しい発想にたどり着くことがある、というのは理解できるのですが、「嫌われて」しまってはいけないのではないか。

チームビルディングを語るうえで、最近「心理的安全」という言葉をよく目にするようになりました。

これについて詳しく書かれている『チームが機能するとはどういうことか』という書籍から定義を引用します。

心理的安全」とは関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

これは「心理的安全」が存在しないチームを想像するとわかりやすいです。メンバーのミスを強く叱責するようなことが続くと、そのメンバーが叱責を恐れてミスを報告しなくなってしまう。メンバーが、「このような質問をしたらチームメイトから自分が未熟で能力が低いと思われるのではないか」と心配して質問ができなくなる。これらは、「心理的安全」がチームに存在しないために起きる問題です。

心理的安全」が保証されているチームでは、自分が発言することによって、叱られたり、不利になったりすることを心配する必要がありません。ミスの要因や、業務に対する理解不足の表明は、チームの仕事を前進するための重要なインプットとして扱われます。

ぼくがかつて上司に言われた「嫌われる」という言葉の違和感は、まさにこれについての懸念です。

他人から嫌われてしまうと、周りは自分に対して率直に接してくれません。相談もされず、自分のあずかり知らぬところで物事が進んでいる、というようなよくない状況に陥ります。メンバーや、協業先企業の担当者の人たちが、常に安心して自分に報告や相談をもちかけてくれる状況が前提としてあってはじめて、自分の主張や意見をぶつけ合うことができるのだと思います。

普通に仕事をしていて、他人に対して悪意をもって接している人などいません。お互いの主張や利益に対して、前向きに一生懸命取り組んだ結果としてのすれ違いがあるだけです。そのすれ違いを解消するために、嫌われる覚悟をもって物事を進めたり、主張を退けたりするメリットなどどこにもないと思うのです。

ぼくがサブディレクターとして仕事を進めるにあたって、最近気をつけているのが、こうした心理的に安全な雰囲気作りです。

心理的安全は自分への不利益を心配する、という状況だけに限りません。新しくお付き合いがはじまった相手先企業の担当者さんと、まだお互いの人となりがわからずに気軽に接することができない、という場合も同様です。そういった場合は、可能な限りチャットツールなどを使ったり、ときには雑談を交えつつコミュニケーションをすることで、仕様についての相談や不具合の報告などをできるだけ気軽に伝え合える雰囲気づくりを作るよう心がけています。

今のところその心がけが、仕事を前進させるために有効に作用している実感を持っています。

長々とおつきあいありがとうございました。明日はCTOのid:motemenです!

会場タイプ別のライブの感想

はてなスタッフアドベントカレンダー2日目の記事です。 昨日は id:onishi さんの 好きなものについて語る難しさ でした。

今年のテーマは「好きなもの」です。

ぼくは、好きなバンドが何組かあって、1~2ヶ月に1度くらいのペースでライブに出かけます。ライブハウスに行くことが多いですが、バンドによっては実に様々な会場で公演が行われます。そこで今日は、会場のタイプ別の感想や楽しみ方について書いてみようと思います。

ライブハウス

王道という感じです。 ライブハウスは規模によって趣が異なります。数百人が入れる箱もあれば、数十人くらいのものもあります。

小さなところだと、客席がとても近く、アーティストを間近に見れますし、大きな会場だと大勢の人との一体感が楽しめます。

ライブハウスでは、公演のチケットの他にドリンク代が必要で、かつてはワンコイン(500円)だったのですが、最近はドリンク代が600円のところが多くなってきました。あらかじめプレイガイドなどで購入したチケットをもぎってもらう際にドリンク代を支払い、ドリンクチケットを受け取ります。あとは任意のタイミングでドリンクカウンターに行き、ドリンクと引き換えましょう。アルコールもあります。

ライブハウスでの鑑賞は、位置取りが重要です。前の方に行くと熱心なファンがいて、激しい演奏のバンドなどだともみくちゃになります。後ろの方はそれほどでもないので、曲によって前と後ろを行ったり来たりしたり、最初は前の方で騒いで疲れたら後ろに下がる、など様々な鑑賞の仕方があります。

ライブハウスは、なんといってもアーティストとの距離がとても近いので、好きなバンドがいれば一度は行ってみることをオススメします。

野外フェス

最近は野外フェスが人気ですね。フジロックとかサマソニとか、そういうところです。フェスの醍醐味は、いくつかあります。複数のアーティストが演奏するので、1日でたくさんのバンドの演奏を聞くことができますし、野外の開放感もあります。

だいたい会場のどこにいても、なにかしらの音楽が常に聞こえているので、太陽の下でビールを飲みながら、遠くから聞こえてくる演奏に耳を傾けるだけでも非日常感が楽しめます。

お天気が崩れるとあまりよい体験にはなりませんが、泥まみれになりながら踊ったりするのもまた醍醐味といえましょう。

屋内フェス

年末のカウントダウンなど、冬場に開催されるフェスは屋内が多いです。幕張メッセなどの大きな施設が会場になります。

屋内フェスは、野外と違って天候の不安がありません。冬場でも、コートをクロークに預けて軽装で鑑賞できます。一方で、ステージがそれぞれ独立した建物の中に設置されることになるので、野外フェスのようにどこからともなく音楽が聞こえる、という雰囲気ではなく、いくつかのライブハウスが一箇所に集中していて、それをめぐる、という雰囲気になります。

夏の野外フェスなどはやはり暑さで過酷だったりもするので、過ごしやすさはダントツで屋内フェスのほうがよいですね。その分開放感は野外に劣ります。

多目的大規模ホール

大阪城ホールや東京ドーム、武道館などがこのタイプに入るでしょうか。何千人、何万人もの人が一箇所に入るような大きなホールでのライブです。

アリーナに入れれば楽しいのでしょうが、席によってはアーティストが豆粒くらいの大きさでしか見えず、公演のほとんどを会場の巨大ディスプレイ越しに観る感じになります。

ちなみにぼくは大きなホールのアリーナのチケットが取れたことがないので、だいたい後ろの方の席からの鑑賞しか経験がありません。あまり好きな形式ではないです。

コンサートホール

こちらは音楽専門のホール。クラシックなどが演奏されるところです。ロックバンドのアコースティックライブ、みたいな企画でこういった会場が用いられることもあります。

1人ずつ座席が割り当てられるので、落ち着いてゆったりと鑑賞できます。一方で、激しい演奏で体を揺らしたり隣の人と肩がぶつかりあったり踊ったり、といった鑑賞はできません。

好きな曲をじっくり、ゆったりと聞けるので純粋に音楽が楽しめる環境です。

ビルボードライブ

先日はじめて行きました。カテゴリに分類するとどう呼称するのでしょう。

レストランで、お酒や食事をいただきながら演奏を楽しむ形式です。

ぼくが行った公演は、アーティストもステージ上でお酒を飲みながら演奏していました。MCの時間も長めに取られていて、客席とのかけあいも多く、これまでで最もアーティストとの距離が近いと感じました。

野外フェスの魅力もそうなのですが、ぼくはお酒を飲みながら演奏を聞くのがとても好きなので、最高の公演でした。

以上が、ぼくがこれまで経験した会場のタイプ別の感想です。これからはじめてライブというものに行ってみる、という人の参考にでもなれば嬉しいです。

明日は id:minesweeper96 さんです。

新しいMacbook ProのTouch BarにIntelliJで常にファンクションキーを表示する方法

新しいMacbook Proには、新しくTouch Barが導入されている。 普段はここに、ボリュームや画面輝度のスライダなどアプリケーションに応じていろいろなショートカットキーが表示されるが、キーボードのfnキーを押すとここがファンクションキーの列になる。

IntelliJ IDEAを使っていると、変数名の変更でShift + F6 とか、ファンクションキーを多用する。 そこで、いちいちfnキーを押すのは手間なので、特定のアプリケーション利用時は常にTouch Barにファンクションキーが表示されていてほしい。

設定は以下のとおり。

[システム環境設定]-[キーボード]で、その中のショートカットタグを選択。 この中の「ファンクションキー」という項目にアプリケーションを追加すると、そのアプリケーション利用時はTouch Barが常時ファンクションキーになる。

f:id:daiksy:20161123171602p:plain

これでいつもどおりIntelliJを便利に使える!

エンジニア立ち居振舞い: ミスを個人のせいにしない

お題「エンジニア立ち居振舞い」

エンジニアという仕事にミスはつきものである。

あってはならないことだけど、自分が障害の原因を作り込んでしまったり、データベースに対するオペレーションをミスってデータが消えてしまったり、そういうミスをしたことがないエンジニアはたぶんいないだろう。

個人の書いたコードや、オペレーションが起因で発生したエラーは、当然個人の責任になってしまうのだが、それを過度に責めるのはよくない。 ミスが続いて、萎縮してしまうことにより、柔軟な発想が失われたり、さらなるミスを誘発してしまうからだ。

ミスがつきものの職業であるからこそ、ミスに寛容になろうとすることで、品質を向上できることがある。

ミスを個人のせいにしないという状況は、責任を分散できる体制を作ることで実現できる。

コードは必ず第三者がレビューする、危険な操作は必ずペアで実施する、などだ。

こうすることで、個人ではなく、チームにフォーカスすることができ、万が一ミスがあってもそれはチーム全体で共有される。 チームでミスが共有されれば、「個人の努力」などの曖昧なものではなく、具体的な回避策が検討されやすくなる。

そうした結果、チームの成果物全体の品質も向上する。

ミスがおきて、個人を責める気持ちになったとしたら、それはそうなってしまっているチームの体制に問題があるということだと思うので改善していこう。

はてなインターンの振り返りをYWTを使ってやってみた

今年は、はてなインターンの実行委員長という仕事をしている。

hatenacorp.jp

8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。

developer.hatenastaff.com

まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。

振り返り手法としてのKPTとYWT

ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。

KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。

K, P, Tの3つのカテゴリについてを議論する順番も決まっていて、Keepからはじめるのがセオリーだと言われている。誰だって問題点より良かった点について語り合う方が気分がいい。振り返りは、単に問題点や悪かったところにのみフォーカスするのではなく、あくまでチーム全体のその期間の仕事を考えるのが大切だ。なので最初はKeepについて深掘りをすることで、チームの成功にスポットをあててモチベーションを高めるのが重要なのだ。

Mackerelチームでは先日、少し長い期間を経て開発された大きな機能がリリースされた。そこで、2週間のスプリントの振り返りとは別に、その機能の開発にスポットをあてた振り返りをしようということになった。最初はいつもどおりKPTを使ってやろうと思っていたのだが、チームメイトの id:a-know さんからYWTをやってみないかと提案があった。

KPTは、スプリントなどの継続的に実施する振り返りに向いた手法ではあるが、長い期間についてスポット的な振り返りをやる場合は、YWTの方が効果が高いのだという。チームで試したところ、たしかに効果が高いという実感があったので、インターンの振り返りにもこのYWTを採用してみることにした。

YWTは、やったこと(Y)、わかったこと(W)、次にやること(T)というフレームに当てはめて議論をしていく。期間が長いと、振り返りのときにはいろいろ忘れてしまっているので、KeepやProblemよりもこちらの枠組みで考えたほうが、たしかに思い出しやすい気がした。

インターン振り返りでのYWTのやりかた

今年のインターンは4月から準備をはじめ、半年の長期間に渡るプロジェクトだった。途中で気づいたことなどは、随時Issue化して記録しているのだが、これはこれで長い期間かけて記録されていくので、数も多く粒度はバラバラである。まずは全体として、少し大きな視点で振り返りをしたいと思ったので、その観点でもYWTは最適だったと思う。

本来はホワイトボードに付箋などを貼ってやるのが正しいやり方だと思うが、今回はメンバーが京都と東京にわかれていて、テレビ会議での振り返り会となったので、少し工夫をする必要があった。

f:id:daiksy:20161030144358p:plain

まず、このような表をGoogleスプレッドシートに用意する。

Googleスプレッドシートは、ログインしている人の編集状態がリアルタイムで反映されるため、リモート参加している人がそれぞれここにアクセスすることで、スプレッドシートがホワイトボードと付箋の役割となる。会議として確保した時間は1時間。

ファシリテーター(ぼく)は、Googleハングアウトでこのスプレッドシートを画面共有しながらファシリテーションしていく。

まず、最初の15分間でメンバーにYとWを順に書いていってもらう。ちょうど付箋にどんどん書き出してホワイトボードに貼っていくようなフェーズだ。スプレッドシートにidの列があるのは、記入する行がかち合わないように、まずid列に名前を書いてもらって行をロックしてからゆっくり内容を書いてもらうようにという工夫である。

15分終わったら、Yから順番にファシリテーターが深掘りをしていく。記入者に詳細をヒアリングしつつ、メンバーで議論していく。Yが終わったら次はWについてだ。

最後に、さらに10分時間をとって各自にTも記入してもらう。YとWを深掘りしている中でTとすべきことが明らかになっていた場合は、議論の途中でファシリテーターがTをすでに記入してある。

そして記入が終わったTも深掘りすれば、一連の振り返りは終了である。

感想

KPTはKとPという枠組みの関係で、"良かったこと"と"悪かったこと"という2軸に考えが集中することになる。一方でYやWは、良し悪しというよりも事実ベースで考えを深めていくので、より幅広い意見が出やすいと感じる。この違いが、継続的な振り返りと、長期的なスポットの振り返りとでそれぞれマッチしているように思う。

さきほども書いたが、長い期間のプロジェクトでは振り返りのタイミングでは多くのことを忘れていたり、当初の熱気が冷めてしまっていたりする。そのときに、KeepやProblemについて考えてもあまり熱のこもった議論にはなりにくい。一方で、"やったこと"と"わかったこと"という枠組みは、そもそもこの長い期間で自分たちは何をしたんだっけ、というところから振り返ることになるので、やっているうちに徐々にプロジェクトの様子を思い出していくことができる。さらに時間が経って熱気が冷めていることが、むしろ自分たちの考えに客観性をもたらしてくれていて、それが効果的に働く。

半年に1回とか、長期プロジェクトの最後の振り返りなどに効果を発揮する手法であるというのを実感した。

Scala関西Summit2016にスタッフ参加しました

summit.scala-kansai.org

10月8日に開催されたScala関西Summit2016に、去年に引き続きスタッフとして参加していました。

当日の発表資料などはこちらにまとめています。

http://b.hatena.ne.jp/daiksy/search?q=scala_ks

BackLog で管理しているタスク一覧を見ると、最古の課題が2016年2月21日とあるので、どうやら2月から8ヶ月くらいかけて準備をしていたようです。

今年はとてもバランス良くセッションが集まり、初心者から上級者まで楽しめる幅広いイベントになったと自負しています。セッションは公募しているので、我々がなにかをしたというより運の要素が強いのですが、このあたりは委員長のきのこさんのひきの強さを感じます。

去年も同じことを書きましたが、Scala関西Summitは委員長のきのこさんの、イベントの終着点に対するとても強いイメージがあり、我々スタッフはそのイメージに引っ張ってもらいながら形にしていったという印象があります。個性の強い優秀なスタッフたちをまとめ上げながら、これほどのイベントをやり遂げるのは流石だな、と思います。

今年、特筆すべき点としては、学生スタッフが非常にたくさん参加してくれた、ということです。 こういったコミュニティはどうしてもある程度メンバーが固定化しがちですが、若い人たちが興味をもって手伝ってくれることで、Scalaコミュニティの裾野がさらに拡がっていければいいな、と思います。

ぼくはこのあと、イベントレポートを雑誌に執筆し、その後ScalaMatsuriのスタッフとして来年の2月にむけてコミットしていこうと思っています。

ScalaMatsuri 2017|日本最大級の Scala のカンファレンス

来年のScalaMatsuri、そしておそらく開催されるであろう、来年のScala関西Summitもよろしくお願いします。

iPhoneが新しくなってPokémon Go Plusがペアリングできなくなったら

iPhone6からiPhone7 Plusになり、iTunesフルバックアップから移行したところ、Pokémon Go Plusがペアリングしなくなる現象に見舞われた。

 

解決したので手順を書いておく。

 

www.pokemon.jp

 

ここに書いてある、Pokémon Go Plus側の操作で一旦接続をリセットすると、新しいiPhoneでもペアリングされるようになった。

 

具体的な操作としては、Pokémon Go Plusのボタンを5秒押す。すると青く点灯するので、その状態で再度ボタンを5秒押す。本体の点灯が白くなったら成功。

 

その後再度ペアリングを実行すればよい。