機能実装会にペアプロ・モブプロを導入してみた！
こんにちは、バックエンドコースのakinoriです。先日（2023/3/28）にバックエンドコースのLeadingチームで機能実装会が開催されました。
Leadingチームはコース修了メンバーのみが参加できるチームで、「プロジェクトを、テクノロジーを、コミュニティをリードする」をビジョンに、コース・個人の枠を超えて挑戦しています。
さて、サークル・コミュニティは、どのように知見を継承するのか、という問題に立ち向かうタイミングがあるかと思います。今回のイベントを開催するにあたって行ったヒアリングでも、先輩・後輩の垣根を越える知見の継承への要望の声がありました。
そこで特定の機能のAPIを実装する「機能実装会」にペアプロ・モブプロを取り入れて、全員で知見を共有することに取り組みました。
当日はレクリエーション実施後に、チーム（4名×3チーム）に分かれて、ペアプロ・モブプロしながら機能を実装、最後に振り返りを実施するという流れです。約4時間という長時間のイベントでしたが無事に開催できました。
今回の記事では、機能実装会、ペアプロ・モブプロ、効果と改善点について紹介します。この記事を通して、ペアプロ・モブプロへの示唆、機能実装会・ハッカソンに向けた心構え・準備を提示します。
機能実装会
なぜ機能実装会を開催したのか？
コース修了後のメンバーは、案件やインターンの開発で自分のスキルを実践しつつ、更なる学習を深めます。
一方で、活動の形式はオンラインがデフォルトであるということもあり、案件内で学んだ知見を共有する場がまだまだ少ない状況です。設計や実装におけるベストプラクティスを共有する場を増やすために、よりテクニカル面に着目できる機能実装会を提案しました。
他にもGPT-APIを活用したハッカソン、ミニハッカソン、AWSアーキテクト会などの案がありましたが、アンケートで「機能実装会」の開催が決まりました。当初は「GPT-APIを活用したハッカソン」になるかなと準備をしていたのですが、蓋を開けてみればあまり人気がなかったので、アンケートは大切であると改めて感じました。
機能実装会の流れ
機能実装会は、Python製WEBフレームワークのDjangoで、提示された仕様書に沿ってAPIを実装します。
ハッカソンではビジネス上のアイデアを創出したり高難易度の技術に挑戦することに価値が一般的には認められるでしょう。一方で機能実装会は知見の共有に価値があり、ペアプロ・モブプロの導入を想定した際に、後者がより魅力的であると考えました。
今回の機能実装会では、全員がPythonを学習しているバックエンドコース修了者ということで、Pythonの仮想環境を用いて開発していただくことになりました。コース修了直後の方も参加していることから、Dockerは採用しませんでしたが、将来的にはDockerも導入したいと考えています。
またPython製のフレームワークはFlaskなどありますが、同じくバックエンドコース所属のメンバーは全員がDjangoを学んでいることからDjangoになりました。APIを開発するということで、Django REST framworkをライブラリとして指定しました。
仕様書には、プロフィール機能とツイート・リツイート・引用リツイート・リプライの機能の実装が必要であると記載されています。
Alpha社は次世代のコミュニティツールのビジネスプランを練っており、ビジネスプランの実現のために開発チームを探しています。
写真共有サービスや社会人層向けに人気のあるブログサービスを運営するAlpha社は、日常の出来事を投稿する若者に人気なサービスを超える新SNSサービスのリリースを考えています。
新SNSサービスには少なくとも、プロフィール機能とツイート・リツイート・引用リツイート・リプライの機能が必要であると考えています。
また各機能毎のエンドポイントの定義も簡単に示しています。エンドポイントでは、URL、HTTPメソッド（GET, POST, PATCH, DELETE）、クエリパラメータ、リクエストボディ、レスポンスボディを記載しています。
機能実装会においては、コース学習では学ばないDjango REST framworkに慣れてもらうことに加えて、設計を検討してもらうという狙いがあります。今回の内容では2つの論点があります。
まずプロフィール機能では、年齢が誕生日から計算できるということに気付いて年齢をDBに格納しない実装にするかが分かれ道になるでしょう。
次にツイート・リツイート・引用リツイート・リプライ機能では、テーブル定義が重要なポイントになります。継承するのか、それとも各々独立させるのかが分かれ道でしょうか。
いずれも絶対的な正解は提供できません。例えば前者は、一般的には誕生日から計算するのが王道ですが、年齢の計算がボトルネックになり得るサービスかもしれません。そのような場合に、定期実行で年齢計算を処理するのか、あるいはデータベースへのクエリが新たな切り口となりえるでしょう。
ペアプロ・モブプロ
ペアプロ・モブプロとは？
まずペアプロは「ペアプログラミング」の略称で、2人のエンジニアが連携して開発に取り組む手法を指します。
片方が「ドライバー」としてコーディングを担当して、もう片方が「ナビゲーター」としてドライバーのコーディングをレビュー・サポートします。モブプロは「モブプログラミング」の略称で、ペアプロが二人に対して複数人での実施になります。
なぜペアプロ・モブプロを導入したのか？
ペアプロ・モブプロ自体は私も体験したことがあり、非常に価値があるものだと感じていましたが、当初は導入の方針ではありませんでした。しかし勝負ではなく知見の共有が目的である機能実装会の特長が最も活かされるのはペアプロ・モブプロだと考えました。
PlayGroundには優秀な先輩・同期・後輩が沢山おり、彼ら/彼女らの書いたソースコードを見るだけでとても勉強になるのですが、オフラインで隣でコーディングしている時だからこそ見つかる新発見があります。
そういったオフラインでの新発見をいかにしてオンラインで再現するのかが肝になるので振り返って見たところ、経験上画面共有している時だと気付きました。画面共有していれば、ツール、ショートカット、リサーチ方法、コーディング手法など様々な発見があります。
しかし単に全員が画面共有しても画面を見ていなければ意味がありません。そこでペアプロ・モブプロの導入に価値を見出していました。
ハッカソンは勝負である関係上、どうしても時間に追われてしまうため新発見という趣旨が見失われてしまいます。機能実装会とペアプロ・モブプロは素晴らしい相乗効果をもっていると考えました。
ペアプロ・モブプロの流れ
今回は各チームが4名で構成されているため、チーム内に班を作ってペアプロする形式でも構わないし、全員でモブプロして頂いても構わないというルールでした。
ただし、1ターム30分間でそれぞれがタイピストとナビゲーターを経験できるようにすること、チーム内に班を設置する場合は定期的に班を入れ替えるようにという制限を作りました。
注意していたこと
今回のイベントを通して注意していたことをまとめます。
レクリエーション
最初から機能実装会を開始すると話しづらいと思われましたので、「お絵描き伝言ゲーム」でレクリエーションを実施しました。私はチーム決定のためにゲームに参加できなかったので、少し残念です。
再設計の必要性
機能実装会で配布された仕様書が不十分であるので再設計に取り組むことを推奨し、設計の正しさを検証しつつ、再設計のディスカッションを通じて他者の思考プロセスを学ぶ機会となるようにしました。
機能の準備
当初はサインアップ機能、ログイン・ログアウト機能などをゼロから実装してもらう方針でしたが、これらの機能は主宰者側で準備することにしました。というのも、これらの機能は一般的に王道の方法が存在しており、インターネットで調査すれば実装できてしまうため、ディスカッションが生まれず、作業になってしまうと考えたからです。
ペアプロ・モブプロの効果
ペアプロ・モブプロに参加してくれたメンバーにアンケートでフィードバックをお願いし、以下のような結果になりました。
なお各評価項目はこちらの記事を参考に定めさせていただきました。https://techblog.yahoo.co.jp/entry/2021083030177162/
業務効率は、複数人で作業を進める関係上マイナスになるかなと思っていたのですが、予想外の結果となりました。複数人で課題に取り組むことで手戻りが少なかったり、より知見のあるメンバーが積極的に指示を出すことが出来ていたのかもしれません。
メンバーの育成という観点でも、プロジェクトの初期段階でペアプロ・モブプロの導入はメリットがありそうです。
またペアプロ・モブプロでプレッシャーやコミュニケーション面でストレスを感じる方もいるようなので、どのようにしてストレスを緩和し潤滑なコミュニケーションを図るかがキーポイントになります。今回は、レクリエーション後に実施していますが、開発体験が向上にはチームの親密度を上げる必要があるので、今後はレクリエーションにより一層尽力していきたいと思います。
他方で、充実さや一体感を高く評価している方が多く、開発にペアプロ・モブプロを組み込むことで、プロジェクトの体験が向上することを示唆できます。
KPT
今回のイベントにはKPTを導入しています。KPTとは、プロジェクトの改善を目指す「ふりかえり」のフレームワークで、Keep「続けるべきこと」・Problem「問題」・Try「次にトライすること」の3要素から構成されています。
KPTはホワイトボードと付箋を用いて進めます。ホワイトボードに、Keep/Problem/Tryのセクションを作り、それぞれに対応するコンテンツを付箋に書いて貼り付けていきます。
バックエンドコースではKPTの導入を積極的に実施しており、一定の期間ごとに運営全体で運営活動をふりかえっています。自由に誰でも発言ができ、他者に対して思っていることを整理して書くことができます。例え優先度が低く話題にならなくても、担当者は付箋を見つけて思案することができます。
そんなメリットのあるKPTを今回もFigJamで導入しました。皆さん、FigJamをご存じでしょうか？とてもパワフルなツールです！https://www.figma.com/ja/figjam/
さて、KPTでは沢山の意見を出してもらえました。全て貴重な意見ですが、抜粋して紹介いたします。
Keep
- 他の人の実装を見ることが出来た点が良かった。自分では気付けない考えを取り入れられた。
- 他の人の使用しているツールを知ることができた。
- ユーザー登録等実装してあったので、スムーズに実装できた。
- 分からない用語を直ぐに聞くことができた。
- Liveshareや画面共有でどこを実装しているのかの話についていけた。
- 打ち解けて機能などについて話せた。
狙いであった暗黙知の共有・思考プロセスの共有ができていて良かったです。画面共有やLiveShareで全員が同じ論点を共有できるのは強みの一つになるようです。またオンラインだからこそすぐに質問できる環境というのは重要ですね。
Problem
- 一つの機能完成前にチーム編成を変更してしまうと、コンテキストの共有に手間がかかってしまう。
- DRF(Django REST framework)の説明が多くなってしまった。
- 最初に決めたやり方が上手くいっていないと感じた段階でアプローチを変える必要があったかもしれない。
- 進捗が少なく効果が薄かったかもしれない。
- ローカルのPythonがすぐ使えず時間がかかった。
- ナビゲーターとドライバーを時間制で回せなかった。
- Git/GitHub、JWT、DRFに関する知識不足を感じた。
知識不足とアプローチ方法に課題を抱えていたようです。今回は事前にDRF勉強会等をしていませんでしたが、ハッカソンや機能実装会を今後実施する場合は、DRFについての勉強会を開催した方が良いかもしれません。またコースとしても修了後のフォローに向き合う必要を感じました。
Try
- 一つの機能完成後にチーム編成を変更する方がスムーズかもしれない。
- 成果を気にせず、もっとじっくりと説明したり考えたりしていることを共有することを意識したい。
- 前提知識を備えて取り組んだ方がやりやすい。
- コミュニティで求められている知識を事前に学習していく。
- POSTMANの使い方を学習したい。
- ハッカソン形式に慣れたい。
時間に余裕がないイベントでは急成長できる一方で、成果へのプレッシャーから深い思考が疎かになってしまいがちです。ハッカソンへの姿勢、機能の優先順位の設定の仕方など難しい話題ですが、きちんと整備していきたい事項だと感じました。
またコミュニティで今求められているスキルを明確化する必要を強く感じ、成長後に備えたスキルセットは何か、それに対してコースがどう立ち向かうべきかもっと深く考えなければならないと思われました。
最後に
ペアプロ・モブプロは開発において充実さとチームとしての一体感を高めると考えられます。そしてその効果を引き出すために、交流を通じてチームの親密度を高めつつ、チーム全員が一定のスキルを備える環境を整備する必要がありそうです。
Leadingチームのビジョンは「プロジェクトを、テクノロジーを、コミュニティをリードする」です。今回のイベントを通じて、参加してくださったメンバーが機能実装会、ペアプロ・モブプロ、KPTを実践しリードする機会になれば幸甚です。
引き続き挑戦します。