https://gyazo.com/c47adb743e6bdbf434cffe56810cf217
フラット型組織におけるエンジニアリングマネージメント
フラット型組織とその目的
組織階層がフラット
固定的な上下関係がない
ざっくりいうと創業者以外皆同じ関係性
マネージャーが存在しない
リーダー的な存在は居るが固定ではない
機会がフラット
大きめの裁量
議論はフラット
マウントとる・とらないはない
各人のモチベーションを大事にする
なぜフラット型組織なのか
前提
実現したい世界観
到達するための目標・手段は明確にない
プロダクトはまだまだ未完成
時間が限られている
世界で通用する強いプロダクトをつくるため
エンジニアリングマネジメントのポイント
マネージャーではない
やってること
ルールを決めない
常にゼロベースで考える
必要があれば壊す
最高の結果を出すやり方を探す
プロダクトアウトを大事に
世界で通用するものになる進捗は0.2%であることを認識する
トライアンドエラーで積極的に出していく
クライアントの要望も参考とする
具体例
フォーカス
2ヶ月の開発スケジュール
注力するポイントをツリー状に
1週間はじめに目標（ゴール）を立てて最後まで走る
それぞれのチームのやり方があるのでルールは統一してない
エンジニアが冬休み宿題で作ってきた
気軽な発想からブラッシュアップして製品化
フィードバックの反映
すぐに最終回答するのではなく
エンジニアに一旦検討してもらい、どのように対応するかを考える
難しい（面白い）ポイント
組織のスケールに抗う
メンバーの増加
自然に身を任せるとスピードの遅いチームができる
今の開発チームはどうか？を考える
個人的な学び
課題じゃないものを課題にしない
目的がなにかを思い出す
ルールやプロセスで解決しない
今の状況での最適なやり方で課題を解き続ける
エンジニアリングマネージャーと戦略
エンジニアリングマネージャーとは
自身のチームや影響が及ぶチームのアウトプットを最大化する人
Responsibility
対チーム
対個人
なぜエンジニアリングマネージャーに戦略が必要なのか
一見良い施策を単体でやっても本当にほしい成果は得られない
退職者が増えたことで拾えない課題が眠っていたのに気づいた
リソースと採用が困難なエンジニアこそ戦略で差が出る
エンジニアは書いたコードがすべて
選択を集中でリターンを効果的に得られないといけない
戦略あってこその戦術
より具体的に戦略を理解する
そもそも戦略と戦術はどう違うのか
https://gyazo.com/73c133f682ee87a320673bead9a1c665
戦略
目的を達成するためのシナリオ
戦術
各プロジェクトを成功に導く戦い方
具体例
1. 組織戦略
戦略
Engagement, DevRel, Recrutingのサイクル・エコシステムを組織内に確立
トップレベルの人材が育つ
作戦
各チームを確立させる
戦術
課題の洗い出し
ブログでの発信
2. アプリ開発
戦略
自己組織化した姿を目指す
チーム分割、スケールさせる
作戦
準備・改革・混乱・定着の4フェーズで行う
戦術
準備期のヒアリング
ハレーションを防ぐコミュニケーション
メンタリング
実際にやってみて：失敗と対策
やってみたがなかなか簡単にできない
理解が難しい
作り方がわからない
合ってるか不明
実行が進まない、実現性がない
OKRのような目標を立てる前にワークシートをつくる
診断
基本方針
行動
やってわかったこと
1. EMにも戦略を
2. 今一番やるべきことを明確にする
3. いきなりは難しいが学べることはある
4. 戦略思考を育むシステムをエンジニア組織に
最高にモノづくりを楽しめる組織を目指して
会社それぞれの役割
運用開発に関わるチームの最適化
プロダクトの歴史
黎明期
エンジニアが企画・開発
サポートチームが誕生
成長期
デザイナーが採用
サポートチームが大きく
ディレクター職も採用
チーム内でも細分化
組織の生産性
チームが増える度に専門家はすごいと思う
エンジニア1人あたりの生産性が下がる
仮説
連続集中時間の減少
アンケート
3時間以上の連続した作業時間とれている人がほぼいなかった
差し込みタスク
問い合わせ対応
ユーザーが増えるとやることも増える
求められる品質レベルも向上
チケットや仕様の再検討
ドキュメントが不在による仕様把握の困難化
上記課題を把握しリソース調整をすすめている
パネルディスカッション
チームごとにスクラムっぽかったり、違うかったりという話がありましたが、チームごとのやり方が違うと、チーム間の移動が難しくなるような気がします。そもそもチーム間のメンバーの移動があまりないのか？移動はあるけど、何か工夫をしているのか？を聞いてみたいです。
門脇
チーム単位の移動はある
アサインもゼロベース
ある程度は流動性を担保
移動の難しさは良いストレスとしてとってもらいたい
自分もよくチームをよく変わる
慣れ方は違えどそこで自分の良さを生かしてほしい
FiNC様 戦略をチームに浸透させるために、どのような施作をされていますか？
清水
ウィークリーのMTG回数少ない問題を解決
リーダーのさじ加減だった
さりげなく機会をつくるようにpush
月曜にシェアリングしてもらう
アナログな手法だが耳にタコができるほどやる
SmartHR様でのスケジュールが差し込まれまくって時間ができなくなる問題へのアプローチもしりたいです
芹澤
2回同じことは起こさせない仕組みづくり
仕様をしっかり決めていく
漏れをなくす調整
エンジニアのモチベーションが上がる仕事と、事業上優先度が高いタスクとで、競合することはありますか？ある場合、対策はありますか？
門脇
競合することはある
優先度が高い・低い判断は？
解像度高い人が並べるが
誰も正解はわからない
直近でやらないといけないこと・やりたいこと・やってみると面白うそうな３つに分ける
エンジニアが手をあげてそこでチームをつくる
2ヶ月走ってみてどうだったかの学び・トライアンドエラーを大事に
清水
むしろ教えてほしい
割り切りでやる
本来モチベがあがるものに気づいてないパターンもある
2段階上の結果をみせる
芹澤
対策はない
入社するときに期待値コントロールはする
キラキラしたものはない
世の中の課題解決の拡大はビジネスサイドの要件
故に乖離はおきない
会社が成長して行くに連れてエンジニアが増えてチームが分かれたとありましたが、２つのチームで触っているプロダクトは同一ですよね？ その場合の開発の進め方やコンフリクトはどうなっているか気になりました。
芹澤
門脇
同じ課題を別々でやってたら学びも2倍になる
コンフリクトもキャッチアップでいいよね
しかしそろそろしんどくなってきた
他の影響もでてきた
開発スピードをあげたい
清水
横断的なテックリードを立てる
責任者をつける
分割できない場合は両方相談したりする
感情的なコンフリクト起こりがち
コミュニケーションで解決
3社様 各社定義している、エンジニアリングマネージャーの役割と責任を教えていただきたいです。 エンジニアの評価制度について、どのような仕組みかもお聞きしたいです。
門脇
自分にとっていいようなラベル（役職）をつけよう
肩書をつけるのは自由な社風
その結果エンジニアリングマネージャー的なものになった
評価者ではない
評価された覚えもない
半年間の目標結果を判定
今までどうだったかではなく、これからこういう動きになってほしいというスタイルで働いている
清水
チームのアウトプットを出すのが役割
テックリードの人やコード書く割合が少ない人も居る
評価制度
OKR
360度評価
人事のマネージャができる前にエンジニアのマネージャーをつくった
なので納得感のある評価制度に
ただし本体評価とのマージが大変だった
芹澤
モチベーション管理
1on1
2週間に1回
信頼関係を構築してくださいという目標
全社共通の評価制度があるが
エンジニアチームはそれを使ってない
フィーリング
あまりよくない
万人に向けたよい評価（答え）はない
組織や事業にとって良いエンジニアは必要だと思うのですが、 良いエンジニアにとってその会社にいる意味を作るための工夫など されてることがあれば知りたいです。
門脇
みんなプロダクトが作りたい世界観に共感して入ってきた人たち
エンジニアに限らずすべての役職で
仕事のための仕事を増やさず、本質のものに取り組めるようにする
本質じゃないものは抗う
誰かしらが火消しを行う
目先の仕事をやめて5年後の未来について話し合う
清水
組織を良くする人たちの共通
会社に居る意味を感じてくれる
製品に対しての理解・品質向上
学習意欲・アウトプット高め
合わない人は割り切ってみる
1on1したり、ネガティブな匂いには敏感になる・真面目に向き合う
ケアできないことが最終的に大きくなる
芹澤
基本個人の意見は尊重
事業に興味がある・起業したい
数字に触れる仕事を与える
パフォーマンスチューニングに興味がある
スクラム導入したい
やりたいことをやるときが一番パフォーマンス・モチベーションが上がる