はじめに
2018年11月27日(火)、タイトルのイベントに参加してきました!
『エンジニアリング組織論への招待』の著者である広木大地さんと、
Japan Node.js Association 代表理事を務める古川陽介さんによるトークセッションイベントです。
1ヶ月くらい前に『エンジニアリング組織論への招待』を読んで感動したので、
広木大地さんのお話を聴きたいなぁと参加してきました。
詳細はこちら。
#エンジニアリング組織論 hashtag on Twitter
メモと感想
話に聞き入ってしまってメモが取れなかった部分も多いです。
グッと来たところを中心に、メモ書きと感想を残しておきます。
足りない部分はTwitterのハッシュタグや他の方のブログを見ていただけると幸いです。
オープニングから主催企業の紹介へ
株式会社LOB CEO 竹林史貴さん
同年代かぁ…。
ベクトルが違うけど、同年代で活躍している人を見ると良い刺激をもらえる。
当たり前なんだけど淀みなく想い(自社のミッションやバリューなど)を伝えられるのはスゴイ。
株式会社BizteX CTO 袖山剛さん
RPA（ロボットによる業務自動化：Robotics Process Automation）。
主に事務作業の分野に導入することで定型的、反復的な業務を自動化する事。
これのクラウド版を提供している会社。
マネジメントの手法として、以下を重視しているのが興味深い。
個人の利と会社の利を合わせる
隔週の1on1ですり合わせをしている。
評価に関係ない。
能力発揮という観点で考えると非常に良い考えだと思いました。真似したい。
ただ上手くいくのかは気になるので、
実際に働いている人の感想を聞いてみたい。心理的安全性の担保。
失敗を許容して仮説と実行を速度を上げて試していくため。
"何のため"にやるのか?
これを重要視している。
目的の景色合わせは非常に重要だと思う。
続いてトークセッション
自己紹介で気になった点をメモ
広木さん。
日本野望の会。
Greeから始まった、勉強会から始まった野望を語る会wエンジニアリング組織論への招待は執筆に2年間かかった!
会場でマネジメントをやられているのは半分ぐらい。
CEO、CTOなど経営層はいない。
まずは初期採用から
中原伶さん
やはりリファラル採用が多い。
全社員を2チームに分けてリファラル採用の競争をしていた。
これは社員がミッションをよく理解しているからできていた。
カルチャー大事。広木さん
よく相談される。
エンジニアを一人も連れてこれない経営者に出資してもしょうがないw
まぁ確かにw
ITに疎い経営者はエンジニアのカンにさわる喋り方をしてしまう場合がある。
採用するとき、リファラ採用できる人をきちんと採用する。古川さん。
現場が広報や人事と連携して動いている。
どんなエンジニアが欲しいかは現場が知っている。エンジニアを巻き込みづらいとかないか?
本業ではないので…。カルチャーとして採用も自分達でやっていくエンジニアを採用している。
またエンジニアも採用に関わる事が自分たちにメリットになるとわかっている。
そう考えない人はメンタリングしていく。
チーム開発について
LOGさん
WFっぽい感じだとおっしゃってました。
Biztexさん
袖山さん
ひとつのプロダクトを作るので、
それをまとめるためにプロダクトオーナーを置いている。
20人規模でも意見が食い違うことがあるので。古川さん
事業側にPMがいて、エンジニアがそれを汲み取って開発している。
目標設計や評価制度
広木さん
評価制度は給料などを決めるためではなく、
個々人が成長しやすくするため。
目標がある方が成長しやすい。目標はそこに向かって頑張るため。
目標はストレッチ目標だと頑張れる。
だって、そっちの方がおもしろいじゃん。
良い悪いではない。
簡単に達成できる目標はつまらない、というだけ。あー前職のMBOは給料に響くから達成できる目標を決めろ、だったなぁ。
たしかにやる気と面白さはなかった。
まさにこれか。イノベーションを求めるならやはり目標と評価制度は分けて考えた方がいいのか。
古川さん
will can mast sheet
やりたいこと、できること、やらなきゃいけないこと。
willとmastを結びつけるとwin win。スキルと定性の評価。
ストレッチな目標がwillに結びつく。
課外活動の評価
会社としての評価はどうすれば?
古川さん
広報として扱う。
マネジメント層を通して評価する。
これ会社名を出してるの前提だなぁ…。広木さん
できないところはできる内容でやればいいのでは?
この話だけ話題に上がるのはこれを特別扱いしすぎなのでは?課外活動ばかりやっている人は?
本業に影響がある。ちゃんとメンタリングすればいいだけだよね?
評価する際に%評価しないといけないのでは?
ちゃんと評価すれば良いのでは?
不確実性があることに対しては失敗も前向きに評価するべきでは?
EMとは?
エンジニアリングのマネージメントをする人。
つまり事業を成功させるためにエンジニアをマネジメントする人。
EMに向いている人はどんな人?
- 広木さん
たんぽぽは刺身にたんぽぽを乗せる仕事をなくすw
イケてるエンジニアがマネジメントもやるようになって、
面白さや楽しさを伝えていけると良い。
親とマネジャーを勘違いしている。
単なる役割があるだけ。
組織の目標達成のために、マネジメントをしているだけ。
現場の見方も変えていく事は大人になる事だろうと。
確かに。
自分の考えだけで物を見てしまうと歪んだ見方になるよなぁ。
懇親会と質疑応答
いろいろと時間が押したので、
懇親会しつつ質疑応答することに。
立食形式だったのもあって他の方の質問のメモはできませんでした。
そちらもTwitterか他の方のブログを参考にしていただけると幸いです。
そして自分も質問させていただきました。
質問の内容がかなりふわっとしている自覚はあったので申し訳ないと思いつつ、
またとない機会なので以下のような質問をさせていただきました。
- 4人くらいの会社で役職としてマネージャーがいない。
仕方なく最古参のエンジニアがEMをイヤイヤやっているのでどうにかしたい。
解決のためになにか良い方法があれば知見をいただきたい。
回答としてはEM.FMを聞いてとのことw
確かにw
EM . FM #EMFM • A podcast on Anchor
他にも、以下のようなお話をいただきました。
マネジメントが嫌な人にはやらせない方がいいと思う。
マネジメントの仕事はたくさんあるので、
分解して嫌な部分を分担したらどうか?
権限を移譲するなど。
その人のマネジメントとはなんなのか?を紐解いた方が良い。
4人しかいないので、会話した方が良いと思う。
よく俺は開発だけやっていたいという人がいる。
でも言われた仕様は嫌だから、仕様も決めたいという。
全部じゃんw
そういう人の言う開発ってなんだろうね?
こういった回答をいただきました。
ずっとマネージャーは必要だから、
自分がマネジメントをやった方が良いと思っていました。
ですが、マネージャーという役割に固執する必要はないなと気づかせていただきました。
単純にいま最古参のエンジニアがやっている作業を分解して、
嫌な事や不得意な事は自分がやるよ、手伝うよって言うだけで良いのかなと。
会社組織がもっと大きければ役職や役割も必要かもしれないですが、
いまは4人(自分いれて5人)なので役割に固執しないで、
みんなでやるくらいのゆるい感じの方が回りそうです。
曖昧で答えづらい質問に答えていただきましたが、
どうもありがとございました!
おわりに
イベントを通して非常に刺激的で興味深い内容でした!
広木さんをはじめ実際にEMをやられている方々のお話は大変貴重でした。
また、登壇されている方も唯一解はなさそうで、
テーマに対してもっと話したい、意見を聴きたいという姿勢が見えました。
自分の身の回りだけでなくいろんな場所で話を聞くのが重要なのだと実感。
特に人間や組織相手になると必ずいろんな問題が発生するので、
悩みながらも対応していくしかないんだろうなぁと。
マネジメント系の勉強会もっと行きたいなぁ。
最後に余談。
こうしてアウトプットするならメディア枠で申し込めばよかったかなぁと思いつつ。
気兼ねなく書けるのはメリットだけど、
メディア枠として宣伝されるのもメリットがあると思う。
たくさんの人に読んでほしいと思える、自信があるアウトプットを目指していきたい。
あと実は『エンジニアリング組織論への招待』の感想記事、まだ書けていない。
よかった!刺さった!というところが多すぎて、
うまくまとめられない感じ。
もう一回読みなおして、年内にアウトプットする。
そんな感じで、素晴らしい対談イベントでした!
広木大地さん、古川陽介さん、運営の方、参加者の皆さん、お疲れ様でした!
