こんにちは。システムソリューション営業本部の吾妻です。


アジャイル開発手法の1つとして紹介されることが多い「ペアプログラミング」をご存じでしょうか？
「ペア」で「プログラミング」するという単語のイメージから、工数が倍になるので効率が悪くなる？とか、「プログラミング」だからソースコードを書く時だけしか使えない？…といった先入観があり、実案件で導入することに抵抗感をお持ちの方は少なくないかもしれません。

今回、とあるお客様へのシステム開発案件で、ペアプログラミング導入に向いていそうな環境・メンバーが揃ったこと、コロナウイルスの流行によって、在宅勤務が継続していることの2点から、試験的に「遠隔ペアプログラミング」を導入して、システム開発を実施してみました。

その時の様子について、「やってみた」レベルで簡単にご紹介します。

手法・ツール

ペアプログラミング

ペアプログラミングとは、コードを記述する「ドライバー」と、ドライバーに指示を出す「ナビゲーター」の2人が1組となって1つのソフトウェアを開発する手法です。

もともとは、同じ机に2人並んで、1台のモニタ・マウスを共有する手法でしたが、リモートでの作業に適したツールを利用することで、地理的に同じ場所にいなくても
施することができるようになっています。

ペアプログラミングする理由

なぜペアプログラミングを導入して、わざわざ2人1組で作業すべきか？というと、
一般に(＝Power Appsでない、通常のシステム開発では)、以下のような効果を得るためだと良く言われています。

• 新しい技術を身につけることができる
  　→ペアプログラミングを行う2人の開発者が、全く同じスキルを持っているということはないので、共同作業を通して、自分達のスキル領域を広げることができます。特に企業において実践する上では、チーム内の習熟度の高いメンバーから、新人や新規にプロジェクトに参画したばかりのメンバーへのスキトラ（スキルトランスファー）のために行われることが多いため、この要素が重要になってくると思います

• チームワークを向上させることができる
  　→ペアプログラミングでは、頻繁にコミュニケーションをとりながら作業を進めるため、チームの一体感を生むことができます

• 言語化しにくい知識を共有することができる
  　→特に新人教育や、プロジェクトに新規に参加したメンバーへの情報共有において重要だと思いますが、ソースコードであれば、アルゴリズムや関数の使い分け(とその理由)、開発環境であればツールの使い分けやコマンドやオプション、ドキュメントであれば業界・案件・特定のお客様に特有の用語など、使っている本人からすれば当たり前で一つ一つ文書に起こすまでもないと思っているような言葉・行動でも、業務上重要なものがあったり、他メンバーはそれらに気付かずにいたり、といった状況が生じることがあります。こうした不文律を、従来のような打合せやドキュメントで共有しようとすると、それだけで大きなコストが掛かってしまいますが、ペアプログラミングを活用することで、より円滑に情報連携することが可能です

• 緊張感を持たせることができる
  　→お互いに相手から常に見られていることで、集中して開発を行うことができる環境を作ることができます

• 属人化を防ぐことができる
  　→従来のように機能ごとに分担して開発を行うと、担当外の実装内容や仕様は分からない、全体を把握しているのは特定の(すごくできる)メンバーのみ、といった状況に陥りがちですが、ペアプログラミングを導入することで、特定の箇所について知っている開発者が少なくとも2人ずつ以上はいるため、将来追加開発や保守が生じた場合に「対応できるメンバーが1人しかいない」というような状況になるのを防ぐことができます

• コードレビューの時間をなくす／減らすことができる
  　→ペアプログラミング自体が、常に実装とレビューを繰り返している状態なので、後の手順として独立したコードレビューの工程を設けることなく、迅速にデプロイすることができます。また、ソースコードに現れないドライバーの意図を常にナビゲーターが確認できること、実装とレビューの間に時間が空かず記憶が鮮明なことから、コードレビュー自体の効率も上がります

• 複数の視点からソースコードを見ることができる
  　→typo等のケアレスミスを探したり、より良い表現がないか考えたりといった、ドライバー自身は視野が狭まってしまっている状態を、ナビゲータがサポートする状況に向いています

ペアプログラミングを導入した理由のうち、Power Appsに特有のものについては、後程ご紹介します。

Power Apps

今回の案件では、Power Appsによるアプリ実装がメインでした。
（Power Apps についての連載記事は、 こちら からご覧ください）

ペアプログラミングとPower Appsの親和性

今回の案件では、Power Appsのもつ以下のような特徴から、ペアプログラミングを導入しようと考えました。

• ユーザーインタフェースをグラフィカルに編集できる
  　→開発経験の少ない人でも、ドライバーとして編集しやすく、ナビゲーターとして指示を出しやすい

• Power Appsでアプリを「作成」する際は、複数人で同時編集を行うことができない
  　→複数人でアプリのデザインや関数を編集するためには、適宜作成者のアプリをコピーして、別のアプリとして開く必要がある
  　→『コマンドを叩かずにGitHubでバージョン管理をする』でスクリーンショットを紹介したような、「名前を付けて保存」によるバックアップが増殖することになりがち
  　→アプリを保存する際に記録される「バージョン」の概念はあるが、バージョン間の差分が取れないため、バージョン管理を行うのが困難

• 作成したアプリを「発行」してしまえば、作成している人以外も「再生（実行）」することができる
  　→頻繁に「保存」・「発行」して、作成者以外もアプリの挙動を常に確認できるようにしておく
  　→テストの自動化が難しいため、通常の開発では自動テストで済ませるような単体テストを作成者以外が追っかけ実行する

プロジェクトの概要

メンバー

今回のプロジェクトで、Power Appsでの実装に関係するメンバーは以下の3人でした。
一般に、ペアプログラミングではペア間のスキル差があまり大きくない方が、作業が円滑に進み、効果が高いと言われていますが、
今回は、他の部署から異動してきたばかりのYさんの教育を兼ねていることから、若干のスキル差がある状況で開始しました。

進め方

メンバー間での画面共有・意思疎通には、Teamsを利用しました。
各々の自宅の通信環境では、本社ほどの通信速度が出ない傾向がありますが、ほぼ遅延なくやり取りできていました。
ただ、時々（定例会のタイミングなどに限って！）不安定になったこともあったため、複数のツールを速やかに切り替えられる環境を準備しておくとよかったかもしれません。

所感

今回、ペアプログラミングを実施してもらったのが1組だけで、定量的な評価が難しいので、感想を寄せてもらいました。
概ね肯定的な反応だったと感じました。

ペアプログラミングをやってもらった（私の）感想

当初ペアプログラミングを導入することにした際に考えていたことに加えて、以下のような点から今回ペアプログラミングを導入してよかったと考えます。

• 今回、Power Appsアプリを実装する場所がお客様テナントになったため、単なるソースコードレビューとしての役割だけでなく、意図しない修正を「本番環境」へ加えてしまうことがないようにするための、作業レビューとしての役割も果たせていた

• 複数人で同時編集が行えず、また、関数の記述場所が「深い」ため、従来のPower Apps案件では、属人化が激しく、保守作業が困難だったがペアプログラミングを行ったことで、内容や意図を実装時点から共有できているので保守性が向上した

やってみた（メンバーの）感想

• 普段よりも「見られること」を意識しているため、読みやすいコードを書けた

• 割り込みタスクが発生した際、ナビゲーターに対応してもらうことで思考が中断されずに済んだ

• こそあど言葉で指示してしまい、聞き直しが発生する場面があった

• 画面を共有しながらのビデオチャットなので、目線や指差しでの指示ができないので工夫の余地がある
  　→ツールでの対処が可能かもしれない（VS CodeのLive Shareのように、カーソルを共有する等）

• 一方的な発話が多かった

• 新人教育に勧めたいと思った

まとめ

本記事では、実案件での遠隔ペアプログラミングの活用について簡単にご紹介しました。

コード品質の観点では、読みやすいコード実装・分かりやすい操作を心掛けることが、
本番環境での監査の観点では、緊張感を持って、本番環境での誤操作を防げることが、
知識共有の観点では、よくあるロジックや暗黙知をスムーズに共有できることが、ペアプログラミングの大きなメリットだと実感できました。

開発内容や、その時々のチームメンバーの組み合わせ、ペア間のスキル差に応じて、
向き不向きもあるかと思いますので、まずは一度、実践してみてはいかがでしょうか?

今後も、開発業務の効率化のために、様々な試行を行っていこうと考えています。

---

このブログで参照されている、Microsoft、Windows、Teams、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
このブログで参照されている、GitHubは、米国およびその他の国におけるGitHub Inc.の商標または登録商標です。