NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

ペアプログラミングを用いたオンボーディング

f:id:s2-iwasaki:20211215191603j:plain

本記事はNRIネットコム Advent Calendar 2021 20日目の記事です。
💑 19日目 ▶▶ 本記事 ▶▶ 21日目 ⌨️

こんにちは、岩崎です!「NRIネットコム Advent Calendar 2021」の20日目の記事を書かせて頂くことになりました。現在私は10年にわたって運用され続け、今も多くの方にご利用頂いているモバイルアプリをゼロベースで作り直すリプレイスプロジェクトに参画しています。そのプロジェクトでは、新規参画者のオンボーディングの方法としてペアプログラミングを用いています。今回は、ペアプログラミングを導入してみてプロジェクトの品質や生産性にどのような効果があったのか、その辺りのことを共有できればと思います。

リプレイスプロジェクトの概要

ご自身のプロジェクトとの違いを考慮できるように、まずはリプレイスプロジェクトの概要について整理しておきたいと思います。プロジェクト全体ではもっと大規模・多様になってきますが、アプリ開発チームとしては概ね以下のようになります。

チーム構成

モバイルアプリ開発は以下のような3チーム構成で行い、基本的に他のチームに影響しないことは自分たちのチームで意思決定しながら進めます。ちなみに私はAndroidチームです。

  • Androidチーム: Androidアプリ開発を行う。ピーク時8人程度。
  • iOSチーム: iOSアプリ開発を行う。ピーク時9人程度。
  • KMMチーム: Kotlin Multiplatform MobileでOS共通のビジネスロジックの開発を行う。ピーク時4人程度。
開発期間と要員計画

要件定義・設計・開発・テストと分けた場合に、およそ1年ほどの開発期間があり、そのなかで計画に沿って段階的に各チームの開発者を増やしていきました。

採用したアーキテクチャ

少し難しい用語が続くので最初にまとめておくと、ちゃんと設計思想を整備して、それに基づくクラス設計を行い、ユニットテストもバリバリ書いていたという感じです(以下、読み飛ばしてもOKです)。

全体像としてはKMMを中核としたネイティブアプリ開発で、プレゼン層の実装をAndroid, iOSそれぞれで行い、モデル層の実装をKMMでワンソースにしています。プレゼン層のアーキテクチャは、基本的には各プラットフォームが推奨するものをベースに多少カスタムしたアーキテクチャになっています。Androidだと、MVVM + LiveData + Data Binding + Coroutine みたいなイメージです。モデル層のアーキテクチャは、Clean Architectureをベースにしたものになっています。ビュー層以外の実装にはすべてユニットテストを書いていて、開発スタイルとしてはTDDを採用しています。

プロジェクトの最重要事項

いわゆるQuality(品質)、Cost(コスト)、Delivery(納期)でいうと、Qualityを最重要として考えています。リプレイスプロジェクトの発端が現行アプリの品質低下に伴うリリースサイクルの鈍化、保守コストの増大であるためです。

なぜペアプログラミングなのか

ペアプログラミングとは、コーダーと指示役が二人一組となって同じ課題の実装を一緒に行うという開発スタイルのことです。リプレイスプロジェクトでは、プロジェクトとして新規参画者の立ち上げに対してペアプログラミングを導入することになりましたが、実施するに当たって個人的な目標も含めて大事にしたことは次の3つです。

1. 参画者と既存メンバーのコミュニケーションを促進する

やはり、まずは参画者の方にチームに慣れてもらって、なにか課題や確認したいことが発生したときに気軽に負担なくチームに聞ける土壌を作りたいという思いがありました。

2. 参画者をいち早く自立的に活躍してもらえるようにする

リプレイスプロジェクトでは、チームマネジメントの方法やプロジェクトの文化的にも、いち開発メンバーと言えどもある程度主体的にタスクの組み立てや進捗管理を行い、必要に応じて他チームとのコミュニケーションを取りながらタスクを進めていく必要があります。そのため、参画者はドキュメントに記載された対応フローや仕様書の読み込み、あるいは過去のチャットのやりとりや既存メンバーに確認したりして、進め方や相談の仕方を吸収していく状況が想定できます。これは参画者が実装に集中できるようになるまでに時間を要す可能性があり、もう少しスムーズに立ち上がれるようにしたいという思いがありました。

3. 新規参画によってアプリケーションの品質を低下させない

ここで言うアプリケーションの品質とは、言い換えればどれだけ一貫した考え方で作られているかということです。現実的には、開発者リソースは常に流動的であり、開発担当者が変わるたびにそれまで無かった新しい考え方が戦略性無く混入していき、アプリの複雑性が増大して保守性が低下するというのはよくあることだと思います。 リプレイスプロジェクトとしては、採用している設計思想、アーキテクチャを新規参画者の方にしっかりと理解してもらうことで、そうした状況を避けたいという思いがありました。

どのようにペアプログラミングを行ったか

新規参画があったときに、最初の2週間を既存メンバーとのペアプログラミング期間として導入しました。期間中は毎日既存メンバーを入れ替えて実施することで、すべての既存メンバーとペアプログラミングを行うことを目標としていました。1日の間の3時間程度を使ってペアプログラミングをしていた感じです。

基本的には参画者の方がコーダーになって、既存メンバーが指示役となり実施していました。コーダーの人は自分のタスクの内容と現在の状態を共有し、指示役の人がアーキテクチャの考え方を教えつつ一緒にコーディングをするという形です。また、指示役の人は実装だけでなくチケット管理の方法や仕様確認の行い方など業務面の進め方も同時に教えていました。

テレワーク中心の働き方なので、ペアプログラミングもすべてリモートで行いました。コーダーの人が画面共有し、指示役の人がペイント機能を使いながら実装内容などを教えていた感じです。

ペアプログラミングを行って実際どうだったか

チームビルド・品質・生産性という3つの視点で、ペアプログラミングを行った結果や思ったことをつらつら振り返ってみたいと思います。

参画者の不安が軽減

ペアプログラミングに対するフィードバックを各参画者の方にヒアリングしていたところ、やはり最初にプロジェクトの概要や進め方、実装の考え方をマンツーマンで教えてもらえるというのは安心感が大きかったようです。そのため、参画者の方が気持ちよく働ける環境づくりに寄与したと思っています。

コミュニケーションに対する心理的負担の軽減

自分が一体どんな人たちと働いているのか分からないようなチームでは、何か課題が発生したときに気軽にチームに聞いてみるということが行いにくいと考えられます。ペアプログラミングにおける、マンツーマンで話し合いながら一緒に課題を解決するという時間は、参画者が既存メンバーの人となりを理解する機会を与え、チームに対してコミュニケーションが取りやすくなります。実際、アプリ開発チームの多くのメンバーが一週間に100以上のメッセージを投稿しています(この数値自体はなんの目安にもならないかもしれないですが…)。

コミュニケーションが取りやすくなると、課題を一人で抱えてしまい問題を大きくしてしまうことが無くなります。また、知っている人がいるかもしれないからとりあえず聞いてみようというマインドになっていき、課題解決の速度が向上することでチーム全体のパフォーマンスが上がったと思います。

アーキテクチャに対する理解度の底上げ

新規参画者の方が既存メンバーから教えてもらうことでアーキテクチャに対する理解を深めると同時に、既存メンバーはアーキテクチャの考え方を正確に伝えられる必要があります。誰かに何かを教えるためには、自分自身がそれについて深く理解している必要があるため、ペアプログラミングを通して既存メンバーのアーキテクチャに対する理解度も向上したと思っています。

レビューコストの低減

リプレイスプロジェクトでは、すべてのソースコードが2人以上のコードレビューで承認された後にdevelopブランチにマージされます。開発期間中に作成されたPRの数は優に2,000を超えていることから、コードレビューにかかる時間はちりつもで大きなコストになると考えられます。

ペアプログラミングを導入して一番効果を実感するところは、コードレビューの際にアーキテクチャに沿った実装になっていないことに対する指摘が少ないことです。これは個人的な経験に基づきますが、ペアプログラミングを行っていないプロジェクトのコードレビューでは、まずアーキテクチャに沿った実装に直してねという指摘の後に、そこからロジック不備を確認するというようなコストのかかるレビューになることが多いです。

また、新規参画者のコードも含めて常に一貫した考え方のコードが上がってくるため、レビューも行いやすく見るべきポイントがはっきりしていて、レビュー速度の向上にも寄与したと思っています。

立ち上げコストの増加

新規参画者とのペアプログラミング中、既存メンバーは基本的には自分のタスクを進める時間がありません。そのため、この期間のチームとしてのアウトプットは当然減ってしまいます。およそ2週間(およそ10人日)分のコストが参画者の立ち上げにかかることになりますが、うまく立ち上がらなかったときのリスクも含めて、プロジェクトとして受け入れられる必要があります。

まとめ

個人的には、今回のリプレイスプロジェクトにおいては、ペアプログラミングの導入はとても効果的でうまくいったと思っています。モブプログラミングという3人以上で行うものもありますが、導入実績のある別プロジェクトでのお話を聞いていると、どうしても会話のウェイトができる人に偏ってしまうという問題があると伺い、リプレイスプロジェクトで大事にしたことを鑑みてもペアプログラミングが最適だったと思います。

一方でチームメンバーのキャラクターやプロジェクトの文化、進め方などによっては、ペアプログラミングが効果的でない場合もあると思います。今回は上記のようなプロジェクトの前提、やり方、チームメンバーのもともとの素養があって成り立ったものだと思っていますが、ご自身のプロジェクトへペアプログラミングの導入を考える際の参考になれば幸いです。

こんどはもう少し技術的なことも書いてみたいと思います。

f:id:s2-iwasaki:20210701145411j:plain

執筆者岩崎 聖夜

モバイルアプリ開発者です。AWSでデータ分析基盤を作ったりもしています。

NRIネットコム Advent Calendar 2021
💑 19日目 ▶▶ 本記事 ▶▶ 21日目 ⌨️