巨大プロジェクトにおけるオンボーディング

by forcia_dev_pr

Slide 1

Slide 1 text

巨大プロジェクトにおけるオンボーディング  島本晃平  2021.08.10 FORCIA Meetup #3 エンジニアとして技術を「伝える」技術 

Slide 2

Slide 2 text

自己紹介 ● 島本晃平 (Kohei Shimamoto) ○ 2013年新卒入社（9年目） ● ソフトウェアエンジニア ○ 大手の旅行・福利厚生企業の開発・運用（2013年～now） ■ 大手旅行会社の巨大プロジェクトのEL（2019年～2020年） ● このプロジェクトでの経験をお話します ○ 技術教育チーム（立ち上げの2014年から2018年くらいまで) ○ 新規事業立ち上げ（2020年～now） ● 趣味 ○ サッカー（社会人新宿区1部リーグ所属） ○ 旅行（写真のドブロブニクは最高！！） 2

Slide 3

Slide 3 text

新規事業　旅行用モデルコース提供サービス Trakite 3

Slide 4

Slide 4 text

4 小豆島観光協会様の事例はこちら @trakite_pr 新規事業　旅行用モデルコース提供サービス Trakite

Slide 5

Slide 5 text

目次 ● フォルシアの「大型」案件とは ● オンボーディングの難しさ ● オンボーディングを促すアクション ● アクションの結果 ● エンジニアリーダー視点から見たフォルシア 5

Slide 6

Slide 6 text

フォルシアの「大型」案件とは 6

Slide 7

Slide 7 text

フォルシアの案件規模エンジニアの人数 7 大規模期間 1人数日 2～3人数ヵ月 4～10人 1～2年少数の案件大部分の案件

Slide 8

Slide 8 text

私がリーダーを務めた「大型」案件の規模エンジニアの人数 8 大規模期間 1人数日 2～3人数ヵ月 10人 1年私がリーダーを務めた案件 4～10人 1～2年大部分の案件少数の案件

Slide 9

Slide 9 text

私がリーダーを務めた「大型」案件の規模エンジニアの人数 9 大規模期間 1人数日 2～3人数ヵ月 10人 1年私がリーダーを務めた案件 4～10人 1～2年大部分の案件少数の案件 2人から7ヵ月かけて10人へ沢山オンボードしている

Slide 10

Slide 10 text

フォルシアの特徴エンジニアの人数 10 大規模期間 1人数日 2～3人数ヵ月 4～10人 1～2年ほぼ社員で構成大部分の案件少数の案件 10人 1年私がリーダーを務めた案件精鋭メンバーが領域ごとに分担することが多かった

Slide 11

Slide 11 text

私がリーダーを務めた「大型」案件の特徴エンジニアの人数 11 大規模期間 1人数日 2～3人数ヵ月 10人 1年私がリーダーを務めた案件 4～10人 1～2年業務委託含む構成チームでまんべんなく対応大部分の案件少数の案件ほぼ社員で構成精鋭メンバーが領域ごとに分担することが多かった SHIFT

Slide 12

Slide 12 text

オンボーディングの難しさ 12

Slide 13

Slide 13 text

オンボーディングの難しさ 13 ● パフォーマンスを発揮できる環境の構築 ● 文脈のキャッチアップ

Slide 14

Slide 14 text

パフォーマンスを発揮できる環境の構築 14 ● 心理的安全の確保 ○ チームの雰囲気にどうやって馴染むか ○ 文脈のキャッチアップが大変・案件の難易度も高い不安 ○ はじめましてのメンバーでの信頼関係の構築 ● メンバーの主体性の確保 ○ 何からやればいいのやら ○ 期待値調整 ■ 求められる役割は？案件を通して得たいものは？

Slide 15

Slide 15 text

文脈のキャッチアップ 15 ● 開発のあれこれ ○ 設計・実装方針・フレームワークの使い方 ○ 顧客や業界特有のビジネスロジック ● ドキュメントのあれこれ ○ 大量のドキュメントの管理 ● コミュニケーション方法のあれこれ ○ 社内外で関係者が数十人もいる中でだれに、なにを？　 ○ 電話・JIRA・backlog・メール・MTGのいつ、どうやって？

Slide 16

Slide 16 text

オンボーディングの難しさ 16 ● パフォーマンスを発揮できる環境の構築 ○ コミュニケーションの課題 ● 文脈のキャッチアップ ○ キャッチアップの順番整備の課題

Slide 17

Slide 17 text

オンボーディングを促すアクション 17

Slide 18

Slide 18 text

オンボーディングを促すアクション 18 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫する

Slide 19

Slide 19 text

オンボーディングを促すアクション 19 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫する　キャッチアップ促進コミュニケーション改善

Slide 20

Slide 20 text

オンボーディングを促すアクション 20 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫するちょっと具体に話しますさくっと話します

Slide 21

Slide 21 text

オンボーディングを促すアクション 21 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫する

Slide 22

Slide 22 text

にぎやかす 22 コミュニケーションの量を増やすためのにぎやかな雰囲気を作る心理的安全を確保する ● 基本の挨拶・パーソナルな話をする ● チームのスタンスに合わせて煽ってにぎやかす ○ 「大変な時こそ笑って前向きに」が部のコンセプト ● PM、部長、リーダーなど偉い人程いじる ○ キャラクターを見せてもらい「壁がない」ことを周知する ● 若手や業務委託の人の発言を促し、主体者であることを求める

Slide 23

Slide 23 text

オンボーディングを促すアクション 23 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫する　

Slide 24

Slide 24 text

コミュニケーションの場を作る 24 コミュニケーションの質を高めるために目的に合わせた場を設定心理的安全の確保とキャッチアップを促進する ● キックオフMTG ● スタンドアップMTG ● スプリント振り返りMTG ● 設計・実装方針の認識合わせMTG ● MRのレビュー

Slide 25

Slide 25 text

コミュニケーションの場を作る　実施タイミング 25 コミュニケーションの質を高めるために目的に合わせた場を設定心理的安全の確保とキャッチアップを促進する ● キックオフMTG →　フェーズごと ● スタンドアップMTG →　毎日 ● スプリント振り返りMTG →　スプリントごと ● 設計・実装方針の認識合わせMTG →　1,2ヵ月に1回 ● MRのレビュー →　都度

Slide 26

Slide 26 text

コミュニケーションの場を作る　実施目的 26 コミュニケーションの質を高めるために目的に合わせた場を設定心理的安全の確保とキャッチアップを促進する ● キックオフMTG →　PJの認識合わせ ● スタンドアップMTG →　互いを知る ● スプリント振り返りMTG →　開発プロセス改善 ● 設計・実装方針の認識合わせMTG →　開発の認識合わせ ● MRのレビュー →　文脈のキャッチアップ

Slide 27

Slide 27 text

キックオフMTG　フェーズごと・PJの認識合わせ 27 ● フェーズ毎に実施 ○ 要件定義、開発、試験など ● 案件概要 / 全体のスケジュール / 開発の進め方 / プロジェクトリスクについて / チームで達成したいこと、個人で達成したいことをすり合わせる ● キックオフMTGは全社的に実施する文化がある

Slide 28

Slide 28 text

スタンドアップMTG　毎日・互いを知る 28 ● 毎日、一人当たり1分、今日やること、疑問　の共有 ○ 具体的な相談は後で ● 全体への共有 ■ 顧客状況などのPJ関連トピックの共有 ● テーマを決めておしゃべり ○ 雑談・パーソナルな話をするのも目的の一つ

Slide 29

Slide 29 text

スプリント振り返り　スプリントごと・開発プロセス改善 29 ● 今回のスプリントの状況確認(5分程度) ● プロセス改善_スプリント振り返り (20~30分) ○ KPT（Keep / Problem / Try） ● 次のスプリントでやること_バックログ棚卸し(15分) ● にぎやかしも忘れずに

Slide 30

Slide 30 text

設計・実装方針の認識合わせ会　隔月・開発の認識合わせ 30 ● チーム全体でのより深い認識合わせ ○ 日常の個々のメンバーでのやり取りよりも踏み込む ○ 設計意図の共有や方針に関する不明点の解消 ● より良い設計・実装方針の相談 ○ メンバーの知見を集結・共有して最適な設計を考える ■ モジュールの新機能の活用法検討など

Slide 31

Slide 31 text

MRのレビュー　都度・文脈のキャッチアップ 31 ● MRに対して　:thumbsup:　2つ以上でマージOKのルール ○ 全メンバーでレビューをする ○ 基本的に自分はすべてのMRをレビューしていた ● 要件を把握している人のレビュー ○ 設計・実装方針に沿っているか ● 要件を把握していない人のレビュー ○ レビューを通してキャッチアップする ■ 実装の意図がわからなければレビューコメントで質問 ■ あとからジョインした人にも可読性の高いソースへ修正

Slide 32

Slide 32 text

ドキュメントのエントリーポイントを作る 32 ● このドキュメントどこにあります？は100回聞かれる ● まずは「これ見て」で調べられる状態になる ○ 各ドキュメントの置き場へのリンク ○ 誰が何に詳しいか ○ 先方とのコミュニケーションの方法 ● 「書いてなかったよ」→「ここにあるよ。追記もよろしく」 ○ みんなが同じ所を通って整備出来る状況がつくれる ○ ドキュメント探し・コミュニケーション方法のキャッチアップを促す

Slide 33

Slide 33 text

オンボーディングを促すアクション 33 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫するコミュニケーション改善

Slide 34

Slide 34 text

オンボーディングを促すアクション 34 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫するキャッチアップ促進

Slide 35

Slide 35 text

タスクアサインの工夫 35 チームジョイン時の最初のタスクアサインの工夫 ● 自走力に合わせてゴールに向かって走れるタスクをアサイン ● こなしながらあれこれキャッチアップ出来るようにアサイン ● 責任もセットでアサイン

Slide 36

Slide 36 text

タスクアサインの工夫 36 チームジョイン時の最初のタスクアサインの工夫 ● 自走力に合わせてゴールに向かって走れるタスクをアサイン ● こなしながらあれこれキャッチアップ出来るようにアサイン ● 責任もセットでアサイン

Slide 37

Slide 37 text

タスクアサインの工夫　自走力とは 37 ● ゴール明確化力 ○ モジュール開発　⇒　Input / Output ○ 検索ページ開発　⇒　要件から仕様への落とし込み etc. ● 実行力 ○ モジュール開発　⇒　テストを書いて通す実装力 ○ 検索ページ開発　⇒　設計、対応方針、タスクの分解 etc. タスクの粒度が大きくなると実装力以外の能力が求められる

Slide 38

Slide 38 text

タスクアサインの工夫　自走力とは 38 タスクの大きさ（習得に経験が必要）小大 ● 要件面 ○ 要件から適切な仕様への落とし込み ○ 要件を実現する実装方法 ● 開発プロセス面 ○ 設計力・適切な処理の粒度 ○ 開発順序・検証項目 ● 実装面 ○ 必要機能の明確化と実現 ○ 現状のアプリの理解

Slide 39

Slide 39 text

タスクアサインの工夫　自走力のある人　 39 分割して対応順に並べる ● ゴールを明確化し、タスクを分解して、適切な順番で対応する ● 経験が少ないと難しい作業、手戻りが多くいつまでも終わらない ○ 伴走してもいきなり検索ページを作るのは難しい実装自走力がある人の大きなタスクの進め方モジュールの実装 etc.

Slide 40

Slide 40 text

タスクアサインの工夫　タスクの粒度・渡し方 40 自走力・経験豊富これからスプリントタスクの分解から丸っとお任せ小さく分解　明確なゴール順番に渡す飲み込み易くフォロー少しずつ大きくしながらゴール明確化力を養う

Slide 41

Slide 41 text

タスクアサインの工夫 41 チームジョイン時の最初のタスクアサインの工夫 ● 自走力に合わせてゴールに向かって走れるタスクをアサイン ● こなしながらあれこれキャッチアップ出来るようにアサイン ● 責任もセットでアサイン

Slide 42

Slide 42 text

タスクアサインの工夫　キャッチアップの順番 42 ● 要件面 ○ 要件から適切な仕様への落とし込み ○ 要件を実現する実装方法 ● 開発プロセス面 ○ 設計力・適切な処理の粒度 ○ 開発順序・検証項目 ● 実装面　★ここを促進させるアサイン ○ 必要機能の明確化と実現 ○ 現状のアプリの理解キャッチアップ順

Slide 43

Slide 43 text

タスクアサインの工夫　タスク例 43 ● 課題・ゴール ● 対応方針を具体化して手を動かせるようにし成功体験を作る ● ソース上の対応箇所 ● 参考実装・実装の経緯なども伝えて手を動かしながらアプリのキャッチアップを促進

Slide 44

Slide 44 text

タスクアサインの工夫 44 チームジョイン時の最初のタスクアサインの工夫 ● 自走力に合わせてゴールに向かって走れるタスクをアサイン ● こなしながらあれこれキャッチアップ出来るようにアサイン ● 責任もセットでアサイン

Slide 45

Slide 45 text

タスクアサインの工夫　責任もセットでアサイン 45 ● 「このタスクをゴールまで持ってく責任は貴方にあります。」とアサイン ○ プロとして信頼して任せるというメッセージ ■ ヘルプを求めても良いが期限内の完遂に責任を課す ■ 期限直前でヘルプを上げても間に合わない ● 任せて放置ではない ○ ゴールを明確化し自走出来る状況を作るまでは手伝う ○ 適度に声をかけて走れているか確認 ■ 自走できる状況を都度作り直す ● ※心理的安全を確保しているから取れるアクションであることに注意

Slide 46

Slide 46 text

オンボーディングを促すアクション 46 明日から実践出来る3つ ● にぎやかす ● コミュニケーションの場を作る ● タスクアサインを工夫するキャッチアップ促進コミュニケーション改善

Slide 47

Slide 47 text

アクションの結果（？） 47

Slide 48

Slide 48 text

アクションの結果（？） 48 ● 100～200コミット/日　の爆速開発 ● 「大変なのにいつも明るく前向きで良いチーム」 ○ と評価されその年の社内No.1プロジェクトに選ばれる ● 他チームから移籍してきてくれたメンバーからの絶賛の声 ○ 「チームにめちゃくちゃスムーズにジョイン出来ました」 ○ 「こんなにみんながレビューしてくれるチームはないです」 ● メンバーの成長（もちろん個人の能力によるものが大きい） ○ 外部メンバーが運用フェーズの要に ○ 当時新卒1年目のエンジニアが次フェーズで中心メンバーに

Slide 49

Slide 49 text

エンジニアリーダー視点から見たフォルシア 49

Slide 50

Slide 50 text

エンジニアリーダー視点から見たフォルシア 50 ● エンジニア ○ 前向きさ・責任感・学習意欲があり、コミュニケーションの質が高い ● PM ○ 仕様の番人として絶大な信頼がおける ○ エンジニアとも対等な関係で丁寧なコミュニケーションがとれる ● 営業 ○ エンジニアとの対立がない ○ 顧客と対等な立場を築くためのタフな交渉を請け負う頼れる仲間 ● 顧客との関わり方 ○ パートナーとしてプロジェクトオーナーと対面出来る面白さ

Slide 51

Slide 51 text

EOF