こんにちは、DMMポイントクラブグループ iOSエンジニアの中尾俊介（@noa4021J）です。

普段はDMMポイントクラブのiOS開発に従事しながら、テックリードとしてiOS開発の技術的なリードやモバイルアプリ開発のプロセス改善に取り組んでいます。

去年はDMMポイントクラブ iOSアプリのUI更新における設計について寄稿しました。

DMMポイントクラブのiOSのUI更新を支える"StatefulViewController"｜inside.dmm.com

また直近では、技術書典13にてDMMポイントクラブグループでテックブックを共著し、チームがプロダクト開発に集中するための考え方などを寄稿しています。

ぜひ興味がある方は読んでみてください。

DMM PointClub Tech Book #1：六本木一丁目のポイントクラブ

さて、今年のアドベントカレンダーでは、フルサイクルエンジニアリングを実践しているDMMポイントクラブグループのオンボーディングを整備した話をしようと思います。

フルサイクルエンジニアリングについて馴染みのない読者も想定した上で、

フルサイクルエンジニアリングとはそもそも何か
旧オンボーディングにおける課題感
新オンボーディングの設計と意図

などを中心に解説しながら、DMMポイントクラブグループのオンボーディングについてお伝えしていこうと思います。

フルサイクルエンジニアリングについて

フルサイクルエンジニアリングは、ソフトウェア開発における一連のライフサイクル … 設計、開発、テスト、デプロイ、運用、サポートの全ての責任をデベロッパーが持ち、それらの全ての作業を一貫して行うという開発モデルです。

原典はNetflix Tech blogの、Philip Fisher-Ogden氏、Greg Burrell氏、 Dianne Marsh氏による記事「Full Cycle Developers at Netflix」が概念の発祥とされています。

Full Cycle Developers at Netflix — Operate What You Build | by Netflix Technology Blog | Netflix TechBlog

記事によれば、元々Netflixではソフトウェアのライフサイクル毎に責任を専門の組織や個人の役割に区切っており、サイロ化によって開発が遅くなりうる諸問題が生まれていました。所謂コンポーネントチームのような開発体制でしょうか。

サイロ化の諸問題とは例によって、隔たれた組織間で生じる情報や知識の伝達のロスやコミュニケーションコスト、問題や依頼を専門チームに報告し実行されるまでの間にかかるリードタイムによって生じるフィードバックループの遅延、割り込みなどです。

これらの問題を解決し、アイディアが実際にプロダクトやサービスに変換されユーザーに届くまでの時間を短縮するために、フルサイクル開発という考え方が生まれています。

Netflixでフルサイクル開発が生まれるまでの詳細な背景は、原典を参照頂ければと思います。

DMMポイントクラブのフルサイクルエンジニアリング

フルサイクルエンジニアリングは、デベロッパーが自身の開発したものに対してダイレクトにフィードバックを受けることができ、障壁なく迅速にデプロイできるという、ソフトウェア開発におけるフィードバックループの高速化を享受できる反面、デベロッパーに求められる作業量と知識は大幅に増えます。

フルサイクルエンジニアリングを実践するDMMポイントクラブも例外ではありません。

DMMポイントクラブの開発について簡単に説明すると、メンバー自身が担当する開発領域以外にも新機能開発でのビジネス的な要件の調整やそれに基づいた仕様策定、データ分析、カスタマーサポート対応、QAなど全てDMMポイントクラブグループ内のデベロッパー（エンジニアとデザイナー）で閉じて行っています。

またフルサイクルエンジニアリングでは、デベロッパーの負荷が大幅に増えるという欠点を「開発を単純化・自動化するツールを作り利用すること」によって軽減できるとしており、DMMポイントクラブもグループ内で内製した効率化・自動化ツールを活用しています。

例えば、以下のようなツールです。

画像類のアセットやデータ登録、通知配信ツール
検証用アプリの自動生成または手動生成ツール
テスト対象項目の自動抽出ツール
WebViewのコンテンツブロック用のスクリプト、ホワイトリストのリモート配置によるキャンペーン配信効率化

ちなみに、これらのツールについては冒頭でも紹介した「DMM PointClub Tech Book #1」にて詳しく解説されていますので、興味がある方は是非お読み頂ければと思います。

Netflixの原典の記事にもありますが、ソフトウェアの全てのライフサイクルに責任を持つということはどれか1つのライフサイクルに集中する場合よりも頻繁に優先順位付けを行う必要がありますし、差し込みもかなりの頻度で起こります。

新機能の実装と先日リリースした昨日のデータ分析を並行して作業しているところに、本番に向けたキャンペーンの配信作業、ユーザーからの問い合わせ対応、アプリの生成依頼などが割り込むことは日常的です。

こうした目を光らせておくべき場所が多い環境の中で、チームが疲弊せず余裕を持って開発を継続しソフトウェアの全てに力を注ぎ続けていくためには、定常化している作業を自動化し人の手から離していく必要があります。この考えのもと、今日までで生まれたDMMポイントクラブのツールが先述したようなツールになります。

DMMポイントクラブの旧オンボーディング

ここまででフルサイクルエンジニアリングとは何か、DMMポイントクラブではどう実践しているのかがお分かり頂けたら幸いです。

ここからは本題のオンボーディング整備についての話に入っていきます。

フルサイクルエンジニアリングではソフトウェアの全てのライフサイクルに責任を持つため、デベロッパーに求められる作業量と知識は膨大になるということを前節で述べました。

新メンバー受け入れにおけるオンボーディングでは、なおのことその負荷は高いです。

新メンバーが学習するべき組織知、習得すべきスキルやツールなど、開発でひとり立ちし貢献できるようになるまでに膨大な量のキャッチアップが必要になるため、新メンバーはいきなり負荷の高い状態からスタートすることになります。

もしオンボーディングが整備されていない場合、新メンバーは自分でドキュメントを漁り不明点を解決してくれる資料を見つけるか、熟知しているメンバーにコミュニケーションベースで回答をもらうかのどちらかによってキャッチアップするしかないので、より負担もリードタイムも掛かってしまいます。

フルサイクル開発において、充実したオンボーディングと手厚いサポートは必要不可欠です。

しかし、DMMポイントクラブの旧オンボーディングでは、オンボーディングが整備されていないに近い状態でした。

旧オンボーディングは、プロダクトオーナーから口頭での事業内容とプロダクト開発周りの説明がされた後、開発環境やコーディング規約について説明し、その後は日々のデイリーで不明点を拾い上げサポートする、といった流れです。

※旧オンボーディング資料の一部抜粋

旧資料では内容のほとんどは環境セットアップに関することのみで、開発プロセスに関する説明は一切ありませんでした。

フルサイクル開発でデベロッパーが責任を負うべきソフトウェアライフサイクルの中で、「開発（Develop）」のみがオンボーディングでサポートされていた状態で、それ以外は全てコミュニケーションベースでの解決に頼っていた、というのが実情になります。

新しいメンバーが最速で組織に貢献する為のロードマップを作る

旧オンボーディングは「そもそもフルサイクル開発を考慮して設計されていない」状態であり、それが課題でした。

元々旧オンボーディングはDMMポイントクラブの立ち上げ時に急造したものを使い続けてきたので、フルサイクル開発を本格的に実践するというタイミングになっていよいよガタがきたという感じです。

先述した旧オンボーディングの内容では、新メンバーがフルサイクルエンジニアリングを実践する開発組織に加わったにも関わらず、運用・サポートも含め「ソフトウェアのライフサイクル全てが自分の仕事である」という認識が生まれにくいです。

そしてそのようなメンバーが増えソフトウェアライフサイクルのどこかに偏って仕事が進められるようになると、フルサイクル開発そのものが崩壊するきっかけになってしまいます。

また、単純にキャッチアップ量が多いにも関わらず、それらがドキュメント化されず、新メンバーにロードマップとして提示できる状態を整備できていないのは、新メンバーにとっても既存メンバーにとっても負担となります。いきなり荒野に立たせてしまっているようなものです。

道なき荒野ではなく、道標付きの舗装された道路に立たせることがオンボーディングの目標です。

アイディアを素早くプロダクトに反映させるためにデベロッパーがソフトウェアの全てに責務を持ち、高速にフィードバックループを駆動させるのがフルサイクル開発の狙いであるのに、負担が増えすぎて開発が遅くなってしまっては元も子もありません。

ましてや新メンバーを受け入れのオンボーディングさえも両者共に負担になってしまっては、チームがスケールしません。

このような状態に陥ってしまうのを避け、新メンバーが素早く開発に貢献できるようになるために、充実したオンボーディングと開発に必要なスキルや知識の習得を助けるロードマップの整備がフルサイクル開発の成功の一助になると思い、新オンボーディングを整備するに至りました。

新オンボーディングの整備

フルサイクル開発を前提とした新オンボーディングを設計する上で考慮したことを述べていきます。

前節でも述べましたが、フルサイクル開発を前提とするオンボーディングで達成するべきことは以下の2つがあると思っています。

新メンバーがフルサイクル開発の全容を把握でき、ソフトウェアライフサイクルの全てを担うという認識を得ること
新メンバーが実際にフルサイクル開発を実践する際に、ドキュメント化された各作業で必要となる知識やスキルをいつでも、すぐに参照できる状態にすること

1つ目は実践しているフルサイクル開発を俯瞰することで、どこまでが責任範囲であるか、何を把握する必要があるかを明確にします。言い換えると、スコープを明らかにします。

2つ目は明確にしたスコープの中で実際に作業する際に、各ドキュメントをオンボーディング資料の中にインデックスを貼り、不明点をすぐに解消できるようにします。これによりキャッチアップの効率化と、コミュニケーションコストの軽減を図ります。

この2つを達成するために、今回のオンボーディング整備では次の3点を行いました。

「我々はどういう組織で、何を目指すのか」を明文化
フルサイクル開発のプロセスを整理し逆引き可能に
「オンボーディングクエスト」を導入

それぞれ説明していきます。

1.「我々はどういう組織で、何を目指すのか」を明文化

旧オンボーディングではプロダクトオーナーが直近の資料をもとにコミュニケーションベースで伝えられていた事業や組織周りの情報をオンボーディング資料に盛り込みました。

コミュニケーションベースではどうしても伝わりきらず抜け落ちてしまう情報は必ずあると思うので、ドキュメントに明文化しいつでも参照できるようにしています。

これらを明文化しておくことは新メンバーだけに限らず、既存メンバーにとっても受け入れ時や外部に説明する際に資料として使うことができますし、気になった時にいつでも再確認できるというメリットがあります。

またこれはプラスアルファな部分ですが、開発組織のカルチャーやメンバーの紹介、メンバーによる執筆や登壇歴を記載し開発組織の雰囲気・どういう人がいるのかを知ることができるようにしています。

特にDMMポイントクラブではリモート中心の開発体制で、別チームのメンバーとは長いこと直接的なコミュニケーションを取る機会がなかったりします。そのためチームメンバーの人となりがわかる状態にしておき雰囲気だけでも掴めるようにしています。

※一部モザイク加工しています。

2.フルサイクル開発のプロセスを整理し逆引き可能に

こちらも旧オンボーディングで整備されていなかった部分ですが、DMMポイントクラブで実践しているフルサイクル開発に関する全体像を含め、開発プロセスと開発手法について把握できるように整理しています。

1つのドキュメントに全て書いてしまうのは読む量が膨大になってしまい大きな負荷になってしまうので、負荷を分散するためにここでは全体像の概要説明にとどめ、各事項の詳細な解説はそれぞれのドキュメントを読んでもらうようにしています。

開発フローについても同様です。細かな説明は省いて、詳細な説明や手順はドキュメントに任せています。また実際の作業手順については、無理にテキストで伝えるよりもコミュニケーションベースでペアプロ的に行った方が新メンバーの心理的安全性の養成にもつながるので、そこは臨機応変に変えています。

それぞれの資料を見てわかるように、各項目に詳細に解説しているドキュメントのインデックスを貼っており、必要な時にドキュメントを参照できるようにしています。

3. 「オンボーディングクエスト」を導入

受け入れ時に新メンバーにやってもらうことやキャッチアップしてもらうこと、既存メンバー側が行う手続きなどの、オンボーディング時に必ず実施したいタスクやキャッチアップを「オンボーディングクエスト」として展開しています。

導入にあたってはmercariのOnboarding Questの事例を参考にさせていただきました。

Goals: 到達目標に書いている通り、オンボーディングクエストを導入することで達成したいこととしてはプロダクトや開発組織に関する理解を深め、スムーズに開発に参画することです。

新メンバーがスムーズに開発に加わるために、メンバーとの関係性構築やキャッチアップ、受け入れ手続きなどを、このオンボーディングクエストのクエストとしてサポートしています。中には歓迎ランチを開催してもらうクエストも用意しています。

また目標には「10営業日以内に完了すること」と記載しています。これはあくまでも目標値に過ぎず必達事項ではありませんが、それくらいの速度で新メンバーをひとり立ちさせてあげられるように、オンボーディングとサポートを充実させようという、受け入れ側の意気込みでもあります。

新オンボーディングの運用と展望

新オンボーディングを運用し始めてまだ日が浅く受け入れ人数も数えるほどですが、まだまだ改善できるなと感じることは多くあります。

オンボーディング資料自体は情報が整理できていますが、それと紐づけている詳細ドキュメントが初めて見る人でも理解できるように整理できていなかったり、そもそも準備できていない状態で、まだまだコンテンツ不足を感じています。

オンボーディングクエストでは執筆時点で20個と少し程度の量ですが、組織知のキャッチアップやコミュニケーションサポートのクエストが多く、ツールやスキルの習得を促すようなトレーニングは用意できていません。

内製しているツールについてキャッチアップできるドキュメントや、QAの設計やデータ分析周りなどフルサイクル開発の現場でこそ触れるような分野におけるトレーニングコンテンツが用意できれば、運用面の経験のないメンバーでもより素早くフルサイクル開発で活躍できるのではないかと感じています。

また、オンボーディング資料のオーナーシップも現状はリーダー層が中心となって管理している状態ですが、オンボーディングの過不足はオンボーディングを受ける新メンバーや受け入れを担当するメンターといった当事者が感じやすいので、当事者が直にオンボーディングに改善を加えられるようにオーナーシップを展開していきたいと思っています。

最後に

本記事ではフルサイクルエンジニアリングとは何か、フルサイクルエンジニアリングを実践するDMMポイントクラブグループで運用しているオンボーディングとその設計についてお話ししました。

フルサイクルエンジニアリングの理解やオンボーディング設計の一助となれば幸いです。

参考文献

サービス

技能：エンジニア

技能：デザイナー

技能：ビジネス職

技能：バックオフィス

ジャンル

その他

フルサイクルエンジニアリングを実践する開発組織のオンボーディング設計

シェア

関連する記事