こんにちは、開発推進グループ iOSエンジニアの山崎です。
2019/10/31、EOF2019(Engineering Organization Festival 2019)に参加してきました。
EOF2019とは主にマネジメントをテーマとした勉強会です。
「エンジニアリング組織をもっとオープンに」をビジョンに、エンジニアリング・マネージメントとすべてのソフトウェア開発者のためのカンファレンス『EOF2019』を開催させていただくことになりました。
Team / Communication チームやコミュニケーションの手法、組織設計、プロセスなど通信不確実性をどのように乗り越えてきたのか。そこでの気づきや発見などを共有。 Developer eXperience 開発者体験(DX)を向上させるために、制度・仕組み・技術を使ってどのように開発者が生産性を発揮できる環境を作ってきたか。 Architecture / Technology アーキテクチャ/技術によって、組織構造を変えたり、ボトルネックを解消できたこと。コンウェイの法則、あるいはその失敗体験談など。 Design / Product プロダクトマネジメント/デザインのプロセスを通じて、事業の目的不確実性を乗り越えた話、あるいはそこでの失敗体験など。 https://eof2019.peatix.com/
純粋な技術でなくマネジメントをテーマにした勉強会というのも珍しいと思ったのが参加した動機です。
チームをどのように組織化し、どのように運営するか----
それもまた一つの「技術」であり、日々学んだり研鑽していく対象であるという認識は、今まであまりありませんでした。そのため、このような勉強会が催されているという事実自体、自分にとっては新鮮に感じました。
また、マネージャーの物の見方を知る事で、マネージャーがエンジニアをどう見ているかが分かり、エンジニアとしての振る舞いを見直すきっかけにもなりました。ぜひ、来年もあるなら参加してみたいと思えるカンファレンスでした。
以下、登壇者の方々のセッションを聞き感じた内容、自分にとって刺さった事などを共有します。
以下に紹介しているのは二つのセッションだけですので、それ以外は、登壇者の方々のアップロードされた資料をご覧ください。
EOF2019 公式 セッションリスト https://eof-github.github.io/eof2019/sessions.html
1. 「ミクシィのマネージャは悩んでいる (酒井篤さん 株式会社ミクシィ)」
酒井氏がミクシィ社でチームのマネジメントを担当する上で、考えたり行ってきた事をまとめたセッションでした。
資料： https://speakerdeck.com/_atsushisakai/mixis-manager-is-in-trouble
マネジメントのノウハウは埋もれがち
プログラミングそのものであるとか、セキュリティ・通信などといったノウハウは比較的広く共有されているのですが、マネジメントのノウハウは属人化し埋もれがちとなっています。そういったノウハウをどう学んだらいいのか、酒井氏は悩んできたとの事でした。
ただそうしたノウハウを学ぶ方法がないわけではないと思います。そういったテーマの書籍もたくさんあります。
例えば当社アイリッジには「アイリッジ図書」なる蔵書があり自由に読むことができるのですが、そこにも下記の３冊をはじめいくつかの蔵書がありました。まずはこの辺りの名著を読むことから初めても良いかもしれません。
- なぜ、あなたがリーダーなのか？（ロバート・ゴーフィー、ガレス・ジョーンズ著、アーサー・D・リトル訳、英治出版、2007）
- 交渉は創造である ハーバードビジネススクール特別講義（マイケル・ウィーラー著、土方奈美訳、2014）
- 人月の神話（フレデリック・P・ブルックス Jr、丸善出版、2014）
柔軟なエンジニアアサイン文化「ミクシィキャリアチャレンジ」
ミクシィ社には、エンジニアが上司への報告なしに、社内の任意のプロジェクトに従事したいと立候補する「ミクシィキャリアチャレンジ」制度があるとの事です。
エンジニアにとっては好評との事ですが、マネージャーの視点では、 「エンジニアがやりたくない仕事から逃げる逃げ道になっているのではないか？」 「自分のマネジメントに何か問題があったから嫌になったのではないか？」 など悩みの尽きない制度とおっしゃっていました。
完璧なマネジメントなど出来ないし、メンバーが退職したり異動したりするのは、完全に避ける事はできません。そのため、過度に自分の責任と捉えないのが良い、というのが酒井氏のたどり着いた認識だそうです。
何かあると全ては自分の責任と考えがちな人（自分を含め）は、社会に一定数いると思います。そうした人が下手にマネージャーになると、病んでしまいそうだな、と思いました。
酒井氏のように、自分のマネジメントの振り返り・改善は日々謙虚に行いつつも、その上で起きてしまったメンバー離脱などは気にしないとの姿勢がメンタルヘルス的に重要だと思います。
問題があるメンバーへの対処法
組織のメンバー（エンジニア）の中で、特に問題があると思われるタイプの人にどう対処すべきか？ というお話でした。
活力がない（ように見える）メンバー
積極的に動かないメンバーに対しては、とりあえず喫緊に対処しなければならない課題の解決などをお願いしつつ、様子を見たり1on1ミーティングなどを行っていくと良い、との事でした。
私事ながら、私は話し方や表情に感情がほとんど篭っていなかったり、そもそも口数がさほど多くない人間です。そのため、周りから「やる気がない人間」と見なされる事があります（そのせいで、中学校の体育の評価が２になってしまった事もあり）。もちろん、実際にはやる気があるにも関わらず……。
「活力がない人」とマネージャーから勘違いされないためにも、分からない事や懸念点は積極的に質問していく、会議・ミーティングなどで発言をする、学んだ事を外部に発信する（この記事のように）など、具体的な行動を自分から積極的に起こす事が重要ではないか？ と感じました。
ブリリアントジャーク (Brilliant jerk)
ブリリアントジャークとは、エンジニアとして有能ではあるものの、同僚などに対し攻撃的・過激な発言を行う人のことを言います。 （参考 http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html）
この種の人については、その言葉の表面上の過激な部分は真に受けず、「この言葉にはなにか本質的な課題があるかもしれない」と興味を持つ事が重要と酒井さんはおっしゃっていました。
私個人としては、率直な発言を交わし合い、議論を行う事で、価値のあるものが生まれるという考え方を持っています。そのため、その過程で若干攻撃的に聞こえる事を言ったり言われたりしても、それほど気にしないタイプです。別に、そういった発言は個人の人格攻撃を意味するものではない、という考えが根底にあるからです。
しかしそうした建設的な議論を行う人と、単に攻撃的な発言をして満足したいだけの人を、どうやって見分けるのでしょうか？
大きな違いは、そうした発言を行う動機が、周りの同僚や組織に良い影響をもたらす事を願っての事か、それとも単に攻撃的な発言をして自分を強く見せたいだけか、という点ではないかと考えます。
動機が純粋である限り、若干言葉尻が攻撃的でもいずれは認められていくでしょうし、上手な言葉の使い方を身につけられると思います。逆に動機が不純であるならば、いくら取り繕ってもいずれは化けの皮が剥がれるのでは？ と思います。
メンバーの仕事スタイル・価値観を知る
マネージャーとして上手くやるには、メンバーがどんな風に仕事をするのか、どういった価値観・個性を持っているかを知る事が重要との事でした。
ということは、将来マネージャーになりたいと思うエンジニアは、まだマネージャーになっていない内から、周りの同僚の事に興味を持った方が良いなと思いました。「自分の仕事とは関係ないからいいや」という態度では、いざマネージャーになった時に他のメンバーの事を上手く把握する事ができないと思います。
個人的に、将来マネージャーになりたいと思っているため、今のうちから気をつけようと思いました。
得た知見をすぐ実践に活かす
こちらはマネージャーに限らず、エンジニアを含めたありとあらゆる職種の方がすべき事だと思います。「勉強会に行くのが趣味」「本を読むのが趣味」で、実際の行動は何も改善なし、という状態にならないよう気をつけようと思いました。
2. 「学習する組織の作り方（古川陽介さん 株式会社リクルートテクノロジーズ）」
組織の人員がなぜ学習をしなければならないか、そしてどうすれば学習する組織の仕組みづくりができるかに関するセッションでした。
資料： https://speakerdeck.com/yosuke_furukawa/xue-xi-suruzu-zhi-falsezuo-rifang
「息を吸うように学習するモチベーション」
近年、ウェブアプリケーションのUIが非常にリッチになっており、かなり神経を使っているとのことでした。またそもそもウェブアプリとなるとUIだけではなく、パフォーマンス、セキュリティ、ネットワークなど多方面に気を配らなければなりません。フロントエンドだけでこれだけの知識量が必要になってしまいます。
この状態を人を雇うことで（マンパワーで）解決しきるのは不可能なため、組織にもともといる人たちが「息を吸うように」学習を続けることで乗り切る事が必要だ、と古川さんはおっしゃっていました。
「人を雇う事で解決するのは不可能」というのは、後から考えるとすんなりとは飲み込めなかったのですが、おそらく採用したい知識を持った人がなかなか見つからない、見つかっても条件面で折り合わない、採用コストがいちいちかかりすぎる、という事でしょうか。
そもそも将来の日本では、人口減少と少子高齢化により、生産年齢人口が激減していく事が予想されています。 https://www5.cao.go.jp/keizai-shimon/kaigi/special/future/sentaku/s3_1_1.html
マンパワーで無理やりねじ伏せるという、旧態然としたやり方が通用しなくなるのは当然だと思います。今の時代は、全ての人が自主的に新しい事を学び、絶えず自分自身を革新し続けなければいけない時代と言えるかもしれません。
ただ働きながら毎日学習も続けるのは、なかなか簡単な事ではないと思います。
今はスマホやネットを使えば、いつでも教育リソースにアクセス出来ます。また他の人が学んだ内容が、書籍という形態ではもちろんのこと、ネット上の記事としてまとまっており、多種多様な知見を簡単に得ることできます。
この事を利用して、何十分かスキマ時間があったらすかさず学習し、少し暇ができたらその知識を実際に業務に活かしてみるなど、生活・仕事のサイクルに合わせて学習と実践を行えるようしていく事が重要でないか、と思いました。
「共有ビジョン」
いくら勉強をして技術力をあげても、それがビジネス上の課題を解決するものでなかったら意味がありません。学習が無駄にならないためにも、「価値のある事を正しいやり方で実現する」というビジョンに貢献できる事、という意識づけをメンバー間に行っていく事が重要とおっしゃっていました。
確かに勉強するのがやたらにマニアックな方向だったり見当はずれではもったいないです。 「果たして今学習している方向性が合っているだろうか？」 「うまい学習の素材はないだろうか？」 という事を他の人に聞いたり、あるいは学習の成果をフィードバックして皆に見てもらうなどが必要ではないかと感じました。
社内勉強会による学習促進
学習した事を定期的にアウトプットしなければならなくないとすると、自動的にインプットも毎日行わなければいけなくなります。
古川さんはこの事に着目し、多種多様なテーマの社内勉強会・発表会・コンテストを企画し、アウトプットとインプットのサイクルを回すという流れを作る事に成功しました。
- 例：
- R-ISUCON（リクルート いい感じにスピードアップコンテスト リクルート社内課題の解決を行う）
- スピードハッカソン（実際のWebページをフロントエンドだけでどこまで高速化できるか競う）
- PIGICON（Programming and Intelligence: Greatest Improvement CONtest Akinatorのようなアプリを作り応答性能と学習精度を競う）
アウトプットというと一見他人のためのようですが（事実他人のためでもありますが）、自分にとっても学習が促進されるというメリットがあるようです。
まとめ
メンバーが自ら進んで学ぶようになってほしい！ とはよくある希望だと思いますが、それに対する具体的な方法論、しかも実践で効果を証明されたやり方というのをきちんと聞いたことはなかったため、大変参考になったセッションでした。
