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

こんにちは、広報の伊藤です。
本日はエンジニアがテーマに沿ってLT（ライトニングトーク: 10分程度の発表）を行うイベント「FORCIA Meetup」の内容をお届けいたします。

FORCIA Meetup #3　エンジニアとして技術を"伝える"技術

８月10日開催のLTのテーマは「エンジニアとして技術を"伝える"技術」

夏休みシーズンに合わせてのサマーインターンの開催や、新入社員が本格的に業務に参画するこの時期だからこそ、4人のエンジニアがそれぞれ"伝える"をテーマに登壇しました。イベントの詳細はこちらをご覧ください。

本記事では「巨大プロジェクトにおけるオンボーディング」についてご紹介します。イベントの雰囲気が少しでも伝われば思いますので、ここから先は書き起こしスタイルにてお届けいたします。

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

谷井（司会）：それでは「巨大プロジェクトにおけるオンボーディング」ということで新卒入社９年目の島本さんから発表していただきたいと思います。島本さん、よろしくお願いいたします。

島本：よろしくお願いいたします！
では、「巨大プロジェクトにおけるオンボーディング」ということで発表させていただきます。よろしくお願いします。だいぶテーマが広いので期待している話と違うなぁと思う方いらっしゃいましたらぜひ質問いただければと思います。

島本晃平（シマモトコウヘイ）と申します。2013年に新卒で入社して今年で９年目になります。ソフトウェアエンジニアとして旅行会社、福利厚生企業の開発・運用を入社以来続けております。特に2019年から2020年にかけて巨大プロジェクトのエンジニアリーダーを務めさせていただきましたので、今日はそのときの経験をベースにお話いたします。

実は先ほど発表させていただいた多田（※多田のLTも近日ブログにて公開いたします）がやっている技術教育チームの立ち上げにも関わっています。あと、新規事業の立ち上げもゲリラ的に行っています。趣味はサッカーと旅行です。

今日はこちらの５点についてお話いたします。

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

そもそもフォルシアでいう「大型」って何よ？というところなんですけれども、フォルシアの案件の規模というのはだいたいエンジニアの人数が２～３人くらいまでで、期間も数か月というところが大部分を占めておりまして、それ以上の、10人ぐらいの人数だったり、１～２年っていう大規模な案件が少数あります。
私がリーダーを務めた案件も、エンジニアの数が10名で、期間も1年だったので大規模に分類されます。また、当初２名のところから10名にだんだんと加わって増えていったのでたくさんオンボードを経験しています。

あと、フォルシアの特徴なんですけれども、エンジニア少数で案件を対応するのでほぼ社員で構成されます。大型の案件でもこれまでは精鋭メンバーが領域ごとに分担して対応することが多かったんですけれども近年は業務委託の方にもお手伝いいただいたりしてチームでまんべんなく対応するという方法にチャレンジしています。

２．オンボーディングの難しさ

続いてオンボーディングの難しさなんですけれども、ざっくりこの２つに集約されるのかなぁと思っています。

一つ目はいわゆる心理的安全がしっかり確保できているか。各メンバーが主体的にちゃんと動けるような状態が確保できているかということが挙げられるかと思います。
で、もう一つがたくさんキャッチアップすることあって大変だよねということなんですけれども、開発のお作法一つにとっても規模が大きいプロジェクトですとすぐに手を動かすのが難しいよねというのがあったり、ドキュメントも大量にあったり、コミュニケーションの方法...そもそもその関係者が数十人とかになっているので誰になに聞けばいいねんとか、連絡手段もたくさんあるので、誰に連絡するときはどの手段で～みたいなそういうことをいちいち覚えるのが大変ですよね、と。

なのでオンボーディングの難しさっていうのはコミュニケーションの課題っていうところと、キャッチアップの順番をきちんと整理しないとキャッチアップ大変だよねというところに言い換えられるかなぁと思っています。

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

オンボーディングを促すアクションとしていくつかやってきた中で今日は明日から実践できる３つということに絞ってお伝えしたいと思います。
上の２つがコミュニケーション改善の内容で、下がキャッチアップを促進するためのアクションです。上はさくっといって下はちょっと個人的に具体的に話せるかなぁという想いがあるのでちょっと具体的に話せればと思います。

「にぎやかす」っていうのは単純にコミュニケーションの量を増やすためににぎやかな雰囲気を作ろうよといういわゆる心理的安全をつくるためにコミュニケーションの量を増やしていきましょうというやつですね。特に自分が大事だなと思っているのは、偉い人ほどがんがんいじっていけっていうところ。みんなの前でいじることでキャラクターを見せてもらったりして、偉い人なんだけど壁がないよねっていうことをみんなの前で伝えて、周知して、偉い人でもコミュニケーションとりやすいような状況が作れるとすごいいいなと思っています。

二つ目の「コミュニケーションの場を作る」ということなんですけれども、こちらはコミュニケーションの質を高めるために目的に合わせた場を設定しましょうというところで、我々のチームではだいたいこの５つの場を設けてました。それぞれの場の実施タイミングでいうとこんな感じで、毎日やるものもあったり、数か月に１度のものもあったりと色々やってました。

それぞれ目的としてこんなものを設定して、認識合わせ系だったりとか、開発のキャッチアップ大変だよねっていう話があったんですけれども、そこらへんをきっちり改善していきましょうみたいなところとか、目的に設定していました。それぞれについてブレークダウンしたスライドは用意しているんですが、ちょっと時間の関係もあるので興味のある方いらっしゃいましたら後ほど見ていただくか、ご質問いただければと思います。

いまの「にぎやかす」、「コミュニケーションの場を作る」というのがコミュニケーションの改善のアクションでした。

続いてキャッチアップ促進のアクションです。
これはチームジョイン時の最初のタスクアサイン時の工夫にさらにしぼっているんですけれども、そのメンバーの自走力に合わせてゴールに向かって走れるタスクをアサインするということと、こなしながらあれこれキャッチアップできるようにアサインしていきましょうということと、責任もセットでアサインしましょうということです。
一つ目で言うと、そもそも自走力って何ですか？っていうところは「ゴール明確化力」と「実行力」と表現してみました。例えばモジュール開発みたいな単純な、小さな開発であれば、インプットとアウトプットを定義してそのテストを通す実装すれば良いだけだよねという風になると思うんですけど、検索ページの開発みたいなかなりばっくりしてくると、そもそもただ実装するだけ、実装する能力があるだけでは足りなくて、要件から仕様に落とし込むことができるだったりとか、設計して対応方針も立ててタスクを分解して、正しい順番で開発して、ミスがあった場合きちんとリカバリしてというような、そういった能力が求められるかなぁと思います。

この自走力をもう少し言い換えると、要件面できちんとキャッチアップができていますよねということだったり、開発プロセス面でこういうことをちゃんと知ってるよねというところ。特にこの開発プロセス面というのが本を読んだりとか、競プロ（競技プログラミング）とかで実装力を磨くだけだとなかなかキャッチアップできない、経験ベースでキャッチアップしていくものかなぁと思っていて、結構重要だと思っています。実装面で言うと、ちゃんと必要な機能を明確化してそれを実装することだったり、現状のアプリをきちんと理解して、現状のアプリにそった実装ができるみたいなところなのかと思います。
上の能力があればあるほど、大きなタスクでも対応できるよねと思っています。

自走力のある人のタスクの進め方ってたぶんこんな感じかなぁと思っていて、ゴールを...ばっくりしたタスクに対してもきちんとゴールを明確化して、タスクを分解して、適切な順番で対応する。その分割したひとつのタスクがモジュールの実装だったりするのかなぁと思うんですけど、なかなか経験が少ないとその作業は難しいなぁと思っていて、いざやってみても手戻りが多かったりしてマージリクエストのレビューをするんだけれども、レビューをして対応してもらって、またレビューをして対応してもらってとなかなかクローズできないということがあるあるかなぁと思います。大きいタスクを渡して伴走していくっていうかたちでも大きすぎるタスクをいきなりやるのはかなり難しいかなぁと思っています。

なので、タスクの渡し方を工夫するというのはこんな感じで、経験が豊富な人へはまるっと渡して、分割からお任せして、コミュニケーションとりながらやればそんな問題ないよねと思うんですけど、経験がこれからだよねという人に関しては小さく分割して明確なゴールがわかる状態にして、それを順番に渡していって、フォローして、少しずつアサインするタスクを大きくしてゴール明確化力を養っていければなぁと思っています。

で、こなしながらあれこれキャッチアップできるようにアサインというのは、先ほどの自走力の内容ですね。キャッチアップの順番があると思っていて、下から順にキャッチアップしていくのが効率がいいよねと思っていまして、で、アサインするときに、三つ目の実装面というここのキャッチアップを促進できるようなアサインができるといいなぁと思っていて、特に現状のアプリの理解というところですね。どこで、何か実装されているとか、どういう意図で実装されているとか、そういうところをタスクをこなしながらキャッチアップできていくと非常にスムーズにジョインできるかなぁと思っています。

こちらが実際にアサインしたタスクの例なんですけれども、これはJIRAのチケットにこういう概要と参考というかたちでタスクを記載してアサインしたものです。課題とかゴールとか対応方針を具体化して、手を動かせるような状態にして、これをやれば成功体験ができるみたいなそういう状態にします。かつ、このチケットのなかにいくつかリンクを貼ってるんですけれども、それはGitLabのソースのリンクなんですけども、具体的にどこにどの実装があってねというところだったり、この実装を参考にしてねとか、この実装の経緯はこうなんですよとか、あとはその周辺にこういう実装があってここもついでに見ておくといいよみたいな、そういうものも一緒に渡すことで手を動かしながらアプリのキャッチアップができるかなぁと思っています。

次、責任もセットせアサインというところで、アサインするときに「このタスクをゴールまで持っていく責任は貴方にあります。」と明確に伝えてアサインします。若手だったり、外部の業務委託の方であろうとプロではあるので、きちんと信頼して任せますよというメッセージを伝えます。で、そのゴールに持ってくまでの責任をもつということなので、絶対に徹夜してでも土日仕事してでも間に合わせろということではなくて、ヘルプを求めたりだとかしても良いのですけどきちんと期限内で完遂しましょうねということですね。

なのでそのヘルプあげても良いと言っているけれども、期限直前でヘルプあげてももう間に合わないよね、そういうアクションはだめだよねということを伝えます。あと、任せて放置ではなくて、ゴール明確化して自走できる状態を作るというところまではちゃんと手伝いますし、適度に声かけてちゃんと走れているかっていうのをウォッチします。そういうような責任もセットでアサインしていました。これはチーム内で心理的安全がきちんと確保できていないと結構厳しい...責任もセットで押し付けられたみたいに思われてしまったりして上手くいかないケースがあると思うので、にぎやかしとかきちんとしていることが前提になるアクションかなぁと思います

ということで、オンボーディングを促すアクションとしてコミュニケーション面とキャッチアップ面で３つご紹介いたしました。

４．アクションの結果

これらのアクションの結果といって良いか分からないんですけども、我々のチームでは毎日100～200コミットの爆速な開発を実現していました。
「大変なのにいつも明るくて前向きで良いチーム」だよねという評価を社内で得ていましたし、他チームから移籍してくれたメンバーが何人かいるんですけど絶賛の声をいただています。またこれはアサインが良かったからとかそういうことだけではないと思うんですけど、メンバーがみなさんすごく成長して、いまでも他のプロジェクトでバリバリ活躍しています。

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

最後にフォルシアの宣伝になるんですけども、エンジニアリーダーを務めた私の視点から見たフォルシアということで、エンジニアのメンバーはみなさん前向きですし、責任感・学習意欲があって、かつコミュニケーションの質が非常に高いので一緒に仕事をしていてストレスも少ないですし、とても楽しいです。

PMは仕様の番人としてめちゃくちゃ信頼がおけるすごい人が務めてくれていたりして、かといって仕様が絶対だという感じでもなくてエンジニアとも対等な関係でコミュニケーションをとれるので非常に仕事がしやすいです。

営業のかたは、営業とエンジニアの対立というのが外では聞いたりするんですけれどもそういうことがなく、顧客と対等な関係を築くという、フォルシアはそういうスタンスで仕事をしてるって谷井からも最初に話（会社概要のご紹介にて：こちらをご参考いただければと思います）があったと思うんですけど、そういう状況を築くっていうのはなかなかタフな交渉が必要だったりしてそういう交渉を請け負ってくれる頼れる仲間です。

あとは顧客との関わり方ですね。パートナーという言葉またできてきましたけれども、ただの下請けではなくて、パートナーとしてプロジェクトオーナーであるお客さんと対面できるので、お客さんのパッションとかも感じることができてそういうところがすごく面白いかなぁと思います。

以上で話を終わります。ありがとうございました！

質疑応答タイム

谷井（司会）：ありがとうございました。僕自身も島本さんがリーダーをやってくださったプロジェクトに参加させていただいて...３ヵ月？...４ヵ月？くらい開発にはいっておりましたがそのときも感じたやりやすさみたいなものをがすごく言語化されていて、あぁそういうことだったのかと色々腑に落ちた瞬間でした。ありがとうございます。

髙橋（別LT登壇者）：おにぎりの図すごくわかりやすかったですね！
自分から質問いいですか。責任のアサインという話があったと思うんですけど、丸投げじゃないよってことで声掛けとかしていくってことだったと思うんですがけど、声掛けのタイミングって難しいなって思っていて、どこまで任せてどこから手を出すべきかって割と悩むところなんですけど、その基準とか心がけていることってあったりしますか？

島本：結構感覚的なところに頼るのが多いんですけれども、具体的基準で言うと、タスクをアサインするときにどういう風にテストしてタスクのゴールを明確化しますか？みたいなところとかを確認して、「完成基準」をきちんと認識合わせをするというところ。まずそこの完成基準の認識があっていれば早めにマージリクエスト出してね、で、それをウォッチするとか。だいたい１日で終わるだろうなと思っていてそれがまだ出て来なかったらどうですか？って声かけるくらいで、その完成基準があいまいだなぁと思ったらさらにそのタスクを分解していったりをして、小さな完成基準に対してのアクションがちゃんとできているかなといったところで、だいたいこれくらいのタイミングでできるよねっていうところを推測して声掛けるみたいな感じですね。

髙橋：完成基準の共有っていうのが根底にあって、そこがまずあっていなかったらそこからさらに小さくしていってみたいな...

島本：そうですね。そこがあやふやなままスタートしていくと絶対にコケるということがわかっているので。

髙橋：そうですね。

島本：なかなかでもそこでいきなり明確化が難しい場合は、いったん走ってもらって、ちょっと走って上手くいかないということを感じてもらって、どうですか？って聞いてみるとか。そこらへんは雰囲気で人に応じてやってるような感じですかね。

髙橋：なるほど。ありがとうございます。

島本：ありがとうございます。

谷井：自分は飛ばされたスライドが大変気にはなっておりますが...

髙橋：後ほどconnpassにあがるんですよね。

島本：あげれると思ってたので後ほど是非みていただければと思います。

谷井：ありがとうございます。それでは時間も良いお時間になってきましたのでいったんイベントとしては閉めてしまおうかなと思います。この後もしばらくは部屋を開けておきますので、何か聞き逃したよってことがあれば後からこっそりでも聞いていただければと対応しますので是非お願いいたします。島本さん、本日はありがとうございました！

おわりに

今回のLTはエンジニアからのお話でありつつ、どんな業界・業種のかたにも非常に相通ずるものだったのではないでしょうか。チームを率いるリーダーにとっても、そのリーダーがどんな想いでチームを引っ張っていっているのかを知るという意味でチームメンバーにとっても、大切な要素が詰まったLTだったと感じています。
今回のテーマ「エンジニアとして技術を"伝える"技術」でお話しさせていただいた他のLTについてもブログにてご紹介させていただきますので楽しみにしていてください！

次回イベント告知

次回のフォルシア主催イベントはRust言語についてのLT会、Shinjuku.rsです。
Shinjuku.rsでは、Rustを商用利用した話、Rustでこんなものを開発した、Rustの面白い仕様を紹介したい、Rustにcontributeしたなど、Rustに関連する内容ならなんでもWelcomeです。

8月31日（火）Shinjuku.rs #17

ぜひ上記リンクよりご参加のお申込みをお待ちしております。