【勉強会参加記録】エンジニアリング組織論 LT大会
参加イベント
参加目的
食べログにおけるデータサイエンス組織の立ち上げ by 株式会社カカクコム 宮島 弘行様
自己紹介
- データサイエンスチーム マネージャー 兼 企画推進チーム プロデューサー
データサイエンス組織について
組織立ち上げの背景
組織のミッション
- 食べログのデータだからこそ実現可能な体験
- 利益向上への貢献(組織のプレゼンス向上)
組織内のRole定義
機械学習エンジニア
- 機械学習のモデル開発
- データがサービスへ安定的に適用されるのかまでを見る
データエンジニア
- 機械学習モデルを開発するためのインフラ整備がメイン
プロジェクトマネージャー
- 機械学習モデルをサービスに適用するためのPJTをリードし、リリースに責任を負う
人員体制強化について
人員体制の変遷
早期人員確保において工夫したこと
- 兼務人材の確保で実施したこと
- 社内での情報発信
- 社内からDevOpsエンジニア2名と出会った
- 社内での情報発信
- 業務委託人材の確保で実施したこと
- データサイエンスに強い人材紹介会社にひたすらコンタクト
- 最初はスキル要件となかなかマッチしない
- 粘り強くインプットすることでマッチする人材がきた
難航中の機械学習エンジニア採用で工夫していること
機械学習用の開発環境
機械学習案件の開発プロセスについて
- モデル開発
- オフライン評価
- 定量評価
- 定性評価
- A/Bテスト
- テスト成功の定義をちゃんとする
- 簡易的なデータ連携でのロジック適用
- 本リリース
- A/Bテストを踏まえたロジック改善
感想
業務委託人材の確保手法は機械学習エンジニアに限った話ではもちろんない。
自分も業務委託で人材確保をする際、やはり最初からフィットする人材が来ることはほぼ無い。
何度も何度も営業の方と綿密に、こちらが求めているスキルセットを伝えることが重要だと感じる。
当然、求める人材の定義をしっかり固めておくことが必要になる。
大規模データプロダクトでの0->1から1->100開発に向けたチームビルディング by 株式会社リクルート 鹿島 隆雄様
自己紹介
- 趣味はキャンプ
- 極寒の中でも眠れるキャンプ！
大規模データプロダクト
- Airメイト
- 飲食店向けに提供しているシステム
- 会計や予約、注文、人材費の計算や、売上予測をしてくれる
チーム拡大期の混乱にどう向かったか
ここ半年の開発実績
- 54案件
- 34リリース
- いいペースだと感じる。最初は苦労したけど結構うまくいっているので、これを機に言語化。
0->1フェーズから1->100フェーズの移行期に起きたこと
人数を増やす！
- 理想
- 速度アップ＝人数に比例して生産量アップ
- 現実
- 慢性的なスケジュール遅れ
- リリース直前にマージ不能なPR
- 人数が増えるとよしなにでは進まない！
新規参画者の障壁
- スキルの差
- 認識の差
- 暗黙のルール
仕組み化・ルール化
- 再利用・汎化のための技術基盤（仕組み）を作る
- スキルの差を埋めて拡大再生産
- 時を告げるのではなく、時計を作るのだ
仕組み・ルール化はシンプルに設計
- 複雑な仕組み・ルールはコストが高い
- シンプルな仕組み・ルールにするとコストが低い
大規模データ集計基盤の汎用化
案件開発の共通認識作り
- 案件には1人のPMと1つのSlackチャンネル・仕様ページ
- 小さな単位で意思決定できる疎結合さ
リリース手順
- 開発者は火木の午前にmasterマージ
- QAチームは火木の午後にスルーテスト
- リリース手順も疎結合に
ルール化をあきらめる
- 全員が理解するイメージがわかないものはあきらめる
- APIの設計ルール
- 諦めたものはどうするか
- ルール化しないものは人間の柔軟性に頼る
- コミュニケーションで解決できればよし！
- 会話が起こりやすい雰囲気づくりが大事
- 朝会・チーム内LTなど
- ルール化しないものは人間の柔軟性に頼る
チーム設計のおもしろさ
- 自分の生産性を1.2倍UPするより、みんなの生産性を1.2倍UPしたほうが、チームの生産性は何倍にも上がる
マイクロサービスのアンチパターン
感想
仕組み・ルール・組織を疎結合にすることのメリットがよくわかった。エモい。
自分の生産性を1.2倍UPするより、みんなの生産性を1.2倍UPしたほうが、チームの生産性は何倍にも上がる
コストを割いてチームづくりを最大の理由だと感じる。来期のチームづくりの指標にしたい。
ギルドマスターはEMに向いている説 by シェルフィー株式会社 鈴木 大介様
自己紹介
- スタートアップにてプロダクト開発チームでエンジニアリングマネージャーを名乗ることを許された
ギルドとエンジニアチームの類似点
- 同じ世界観を共有している
- 個人で目的は様々
- 目的・ビジョンなどでメンバーが集まる
ギルドマスターとEMの類似点
- 目的とコンセプトの設定
- メンバーの目的と組織の目的のバランス調整
- 採用・モチベーションの維持
- メンバーの関係性の調整
- 組織内のトラブルの対応
- 対外関係との調整・トラブルの対応
- 権限周りの委譲
ギルドマスターとEMの違い
- ギルドマスターは人事評価をしない
- ギルドマスターは報酬を得ないし与えない
- ギルドカジュアルにメンバーの移動が起きるし、ギルマスは別に目的の達成に責任は持たない
まとめ
- 採用面談のアイスブレイクでギルマス経験の有無を聞いてみるのもありなのでは？
- ゲームがうまい人は仕事ができる！？
感想
もしかして…ギルドマスターとエンジニアリングマネージャーって同じなのか！？
- 作者: 小山ゆうじろう,イーピャオ
- 出版社/メーカー: 集英社
- 発売日: 2015/02/04
- メディア: コミック
- この商品を含むブログ (12件) を見る
機能別組織でプロダクトにコミットするエンジニアチームを作ってきた話 by 株式会社エバーセンス 西山 修様
自己紹介
- 開発部 部長
- ベンチャー専用エンジニア
- とにかく0->1をいっぱいやってきた
会社紹介
- 家族を幸せにすることで、笑顔あふれる社会を作る
- エバーセンスのみんながご機嫌に活き活きと人生を楽しむ
代表サービス
- 妊婦さん向けアプリ ninaru(ニナル)
- 赤ちゃんとママへのメッセージが毎日届く
- プロダクトは多数あります
機能別組織とは？
- 開発部/事業部/営業部/管理部と、機能別に組織がわかれている
取り組み① : 企画フェーズからエンジニアも参加
- プランナー「エンジニアの言ってることがよくわかんない！」
- エンジニア「この企画、ほんとにやる意味あるの？」
- ということが起きないように気を遣う
- しかし絶対にプランナーとエンジニアの溝は生まれる
- 溝が深まれば深まるほどプロダクトは弱まる
- 距離が開かないように組織で調整する
- 企画が始まったフェーズからエンジニアも参画し、早い段階から擦り合わせていく
- たとえ結論が同じ企画だったとしても、経緯を知っていれば、納得度・理解度が高い
取り組み② : ●●エンジニアという肩書きがない
- iOSエンジニアとかサーバーサイドエンジニアとかインフラエンジニアとか言わない
- 全部エンジニア
- スキルマップを用意し、みんなで回してやっていく
- チームが担当プロダクトの全責任を持つ。アプリ〜インフラまで
- 良いプロダクトを作るために、エンジニアはあらゆる引き出しから最適解を導き出そう！
- 重要なのは育てること
- 最初から全部やれる人は、現実としてあんまりいない
- 色々やってみたい人にはとにかくやらせる機会を増やし、やれることを増やしてもらう
取り組み③ : テクニカルグループが開発者を支援
- 技術的な支援
- 共有システムの管理
- セキュリティの支援
- プロダクト開発チームが集中して開発に向き合えるように環境を整える
感想
エンジニアが企画に寄り添って早い段階から擦り合わせていくことについて
早い段階から寄り添っても、溝はやはり生まれがちではあるなというのが実感としてある
コミュニケーションの頻度・内容が鍵を握るのだと感じる
フルスタックのエンジニアを育成するためのローテ制度は素晴らしいと思うが
現実としてプロジェクトが繁忙だと、ローテもままならない。
チーム全体が余裕を常に持てるよう、プロジェクトを進めていくことが重要なのかなと感じた
