アルパカログ

プログラミングとマネジメントがメインです。時々エモいのも書きます。

EOF2019参加レポート

10月31日に浅草橋ヒューリックホールで開催されたエンジニアリングマネージャー(EM)のためのカンファレンスEOF(Engineering Organization Festival) 2019に参加しました。

eof.connpass.com

今回が初開催にもかかわらず、オープニングイベントではメインホールが満席になるほど盛況で、業界全体のEMへの関心の高まりが感じられました。

参加したセッションのうち学びがあったものについて、どんな内容だったかと、個人的に思ったことなどを書いていきます。

質とスピード

質とスピード / Quality and Speed - Speaker Deck

品質を犠牲にしてスピードは得られるのか?そもそも品質とは何だろう?

品質には、ユーザーから見えるものとそうでないものがある。外部品質と内部品質と言ったりする。

外部品質は信頼性、正しさなど。内部品質は保守性、可読性などのことだ。

品質が犠牲にされるとき、往々にして内部品質が犠牲にされる。そして、内部品質の中で犠牲にされるのが保守性である。

保守性は、テスト容易性、理解容易性、変更容易性の3つで構成される。

「あとでリファクタリングするから今はスピード重視で」の「あとで」は永遠に来ない。サービスが存在し続ける限りいつだってスピード重視だからだ。

また、「今はスピード重視で」と言う人に十分な時間を与えても、品質の高いコードは出てこないというのは残酷だが現実である。

技術力の高い人ほど、品質とスピードを両立してコードを書く。つまり、保守性とスピードはトレードオフではない。

エクストリームプログラミング』によると、品質を高めることでデリバリーが高速になることが多い。

『レガシーコードからの脱却』によると、コードの品質を高く保っていた「にも関わらず」速いのではない。コードの品質を高く保っていた「からこそ」速いのだ。

質とスピードはトレードオフの関係というのは大きな誤解なのだ。

短期的にはスピードアップするが、その分かれ目は思ってるよりもずっと早くやってくる。それはリリースよりも前で、1ヶ月以内なのだそうだ。

感想

技術力が高く速いエンジニアほど、コードの品質も高いというのは実感としてあったので、それが整理して説明されていたのでスッキリ腹落ちした。

社員100人規模のWebサービスにおけるエンジニアリングマネジメント

(資料見当たらず)

最初のアンケートにて、会場の聴講者はマネジメントが支配的、CTO、エンジニアもちらほらいた。

BASEにおけるエンジニアリングマネジメントの変遷を、スタートアップ初期、10~30人の組織、30人~の組織というフェーズに分け、それぞれのフェーズで起きる問題と考えるべき事柄について説明された。

えふしんさんが考えるマネジメントの役割は「どうにかこうにかなんとかしていく」というもので、全ては考える力と実現する力であるとのこと。

エンジニアリングマネジメントとテックリードの違いは、エンジニアリングは編み出す技術・工学で、テクノロジーは編み出された技術・技術と捉えているとのこと。

人を引っ張って成果を出すことが給与配分原資を生むので、人の給与を上げられる人は成果に対する配分をもらっても良い。

EMとは技術者チームを引っ張り、チームの成果と業績に貢献することで、メンバーの給与を上げる役割であり、技術者の一形態である。だから、戻りたくなったらいつでもエンジニアに戻ることもできる。

また、EMは技術者チームのリーダーであり、メンバーの味方として背中を見せていくことが求められる。PMの意思をどうワクワクする形でメンバーに落とし込むかという側面もあることから、クリエイティブ職でもある。

感想

EMがメンバーの成果に乗っかって自身の成果をアピールする形に、ちょっと申し訳なさを感じていたので、人を引っ張って成果を出す分だけ高給をもらっていいというえふしんさんの言葉は力強く感じられた。

ミクシィのマネージャーは悩んでいる

ミクシィのマネージャーは悩んでいる / mixi's manager is in trouble - Speaker Deck

マネージャーとは一般的にストレスフルなイメージだ。そして、エンジニアリング・マネージャーという言葉にはアンバランスさがある。

エンジニアリングにはオープンさ、業界全体として定着しているというイメージがあるのに対し、マネージャーには知見やプラクティスが企業の中に埋もれがちというイメージがあるからだ。

ミクシィにはEMが20名ほどいて、EMにアンケートをとってどんな悩みを抱えているか聞いてみた。

(悩みの内容はスライドを見てください)

アンケートやインタビューを通して感じたのは、意外にも独自性のある悩みは少なかったということだ。これはエンジニア特有というわけでもなさそうなので、社内外で悩みの内容や解決方法を共有する場を持っていきたい。

これからEMになる人に向けたアドバイスとして、最初はマネジメントのスコープを見極め、自分が変えられることだけにまずフォーカスし、なんとなくマネージャーがやっている仕事を減らしていこう。そうやってメンバー自身に動いてもらえるルール作りをしていくと良い。

感想

私はミクシィのEMとして酒井さんにインタビューを受けた立場だったので、同じミクシィのEMでも少しずつ考え方が違っていておもしろかった。

EMは時に、事業や戦略、人に関することを決断しなければならない岐路に立たされ、誰にも相談できないと悩んでしまうことがあります。そういうときでも他のEMにとりあえず話を聞いてもらうのがおすすめです。

チャットコミュニケーションの問題と心理的安全性の課題

チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019

Slackがダイレクトメッセージ(DM)まみれでなんとかならないか?と知人から相談を受けたので、それへの答えを発表にした。

相談を受けた会社は、DM50%、パブリックチャンネル30%、プライベートチャンネル20%というなかなかひどい有様だったそう。

DMで連絡してしまうことにはいろいろな弊害がある。指揮系統の逸脱による業務負荷の偏り、社内政治が横行するなどだ。

それでは、なぜ人はDMで連絡してしまうのだろうか?

心理的安全性はプライドによって簡単に損なわれる。プライドとはすなわち、「無知、無能、邪魔、否定的と思われたくない」ということだ。

発言を他人から評価されるパブリックチャンネルでは無知、無能、邪魔、否定的と思われる可能性があり、結果的にDMが使われるようになる。

自分に自信がある人、プライドを捨てられる人、周りからの勝手な評価を無視できる人だけがパブリックチャンネルに投稿できるというわけだ。

プライベートチャンネルやDMを禁止しても、LINEやFacebookなどの他のメッセンジャーアプリに迂回され、情報漏洩リスクが増えるので事態はより悪化するだけだ。

だから、どうやってパブリックチャンネルに誘導するかを考えなければならない。

実は最近、コミュニケーションに対しては、利害調整や人に対する働きかけであると考える人と、課題解決や第三者に対する情報発信であると考える人の2通りいることに気付いた。

多知能理論によると、知能は8つに分けられ、そのうちコミュニケーションに関わりがありそうなものに、言語的知能と対人的知能がある。

プログラマーは一般的に言語的知能が高いとされ、営業やマーケターなどは対人的知能が高いとされる。

人は問題を解決するとき、自分の得意な知能を使おうとするため、DMを使って連絡してしまうという問題が起こる。

また、パブリックチャンネルは人にストレスを与えるという問題もある。電車の中で、人と人が喋るのはOKで、電話で喋られるのがストレスなのは、電話は一方の会話しか聞き取れないため推測しなければならず、脳に負荷がかかるためらしい。

パブリックチャンネルは人の貴重な認知リソースを奪うが、DMはそれがない。未読が溜まること自体がストレスに感じる人もいる。

これは、情報を無視するというのがコストだからである。情報を無視するというのは、2000年前後のインターネットに関わってた人は普通にできるが、そうでない人はできないのではないかと睨んでいる。2000年と言えば、ADSL、ブログ、2chなどの時代だ。

だから、入るパブリックチャンネルは限定した方が良いし、投稿や入退室にはルールを作ると良い。例えば、チャンネルを退室するのは自分の認知リソースの限界だからで、あなたのことが嫌いだからではないですよ、と明記しておくなどだ。

感想

以前ところてんさんのインタビュー記事を読んだことがあり、今回の発表はとても楽しみにしていたし、発表を聞いて期待を超える学びと発見がありました。

私自身は、今回発表にあったコミュニケーションの問題はSlackだけにとどまらないと思っていて、現実世界のFace to Faceのコミュニケーションにおいても同じように発生しうると思っています。

それは例えば、対人的知能の不足によって、知らず知らずのうちに自分の発言で相手を傷つけてしまうといったものです。ただこれは一筋縄ではいかない問題で、ここには多知能理論における知能だけでなく、もっと根本的な、それこそ最近よく聞かれるような発達障害などの問題も深く関わってくるのではないかと思っています。

思ってはいるものの、あまりに手がかりがなさすぎて今はただ呆然と立ち尽くしている状態です。もし何かオススメの本などあれば教えてください。

EM Meetup

EM Meetup は事前の宣言通り、絶対に外せないイベントということで17時~の回に参加しました。

EM Meetup はざっくり言うと、参加者から話したいテーマを募集して各テーブルに振り分け、残りの参加者は自分が話したいテーマのテーブルに集まって議論し、各テーブルごと1分程度にまとめて発表します。この手法はOST(Open Space Technology)というそうです。

私が参加したテーブルは「EMをやってて良かったこと」で、参加者はテーマを挙げた方と私の2人でした(笑)

察しの良い方は気付いたかもしれません...そう、「EMをやってて良かったこと」を話したいということは、裏を返せばEMをやってて良かったと思えないからだということに...!(笑)

テーマを挙げたAさんとの会話。

Aさん「なんかあります?w」

私「ん〜〜つらかったことならいっぱいあるんですけどねぇw」

Aさん「ですよねw 実は自分も最近つらいので良い話聞きたいなと思って」

私「自分もなんですよねw」

そんな感じで意気投合。良かったことよりもつらかったことから掘っていくことに。できたホワイトボードが下記です。

まとめると、

  • 配下のメンバーが賞をとったり認められると嬉しい
  • フィードバックの結果、明らかに成長が見えると嬉しい
  • 自分の下した決断が良い結果につながったときは嬉しい

という、自分の行動の結果がポジティブだと嬉しいということを確認しました。

また、これはAさんに教えていただいたのですが、メンバーにフィードバックする際はSBIというフレームワークを用いると、感情的にならずに物事を客観的に伝えられて良いということです。

  • Situation: どんな状況で
  • Behavior: どんな振る舞いをして
  • Impact: どんな影響を与えたか

EMって役割として部下に感謝の意を伝えまくるのに、自分は上からも下からもあまり感謝されないよね、とか、メンバー側からしたら面と向かってそういうこと言うの恥ずかしいから仕方ないよね、とか、感謝されるとモチベーションになるのに、中間管理職のつらいところっすね、とか、社内にEMの定義がないのがそもそもっすよね、みたいな生身のEMって感じの話ができたのでとても満足でした。

いいなぁ自分も話したかったなぁという方に朗報ですが、EM Meetup は connpass で不定期に募集されるのでぜひ参加してみてください。

engineering-manager-meetup.connpass.com


イベントを企画してくださった方、運営してくださった方、スポンサーの皆様、とても良いイベントをありがとうございました。

EMという役割の認知を広め、知見を共有し、業界全体が働きやすくなっていくことを嬉しく思います。