ペアプロと共話とPing-Pongとフロー状態

フラットな関係でのペアプロの会話のヒントに

Published in

時を超えたプログラミングの道

Oct 13, 2021

ペアプロの会話の風景には、固定時間でドライバーとナビゲーターがスワップ、指導コーチングのようなペアプロなど、いろんなタイプがあります。が、私の好きなペアプロは、２人がフラットな関係になって、Ping-Pong(あるいはナチュラルスワップ)でドライバーとナビゲーターが頻繁に入れ替わりつつ、会話スタイルが「共話」になって、ペアが無我夢中のフロー状態で問題に取り組んでいる状態です。

本日は改めて、「Ping-Pong」「共話」を使ってペアプロの振る舞いを再考します。

Ping−Pong（ナチュラルスワップ）

Ping−Pongは、ドライバーとナビゲーターの交代を細かな開発ステップで行うものです。例えば、

Aさんがテスト１を小さく書く
Bさんがテスト１を満たす最小限の実装する
Aさんがリファクタリングする
Bさんがテスト2を小さく書く
Aさんがテスト2を満たす最小限の実装する
Bさんがリファクタリングする
etc…

Ping-Pong（ナチュラルスワップ）は、テスト駆動開発のステップやリファクタリングのベイビーステップと相性がよいので、組み合わせて活用することになります。

また、上のスイッチ＆ステップの仕事を終わらせることができない障害物に出会うことが普通です。その障害物を乗り越えるように細かくスイッチ＆ステップの修正を加えていきます。例えば、

Red−Green-Refactorの中の実装で[明白な実装:TDD]のつもりが想定どおりGreenにならなかった場合、一度[戻って:TDD]、[仮実装を経て本実装へ:TDD]で再チャレンジする。
Refactoring中に想定どおりGreenにならなかったら、一旦Green状態に[戻って:TDD]再度チャレンジする。
最初に選んたテストの実装が難しく解くことができないとわかれば、より[はじめのテスト:TDD][一歩を示すテスト:TDD]に近しいテストを選び直す、あるいはテストを分解し[小さなテスト:TDD]で再チャレンジする。
テストNの本実装の際に、理解しづらい・修正しずらいコードになっていると分かれば、テストNをPendにしてGreen状態に[戻し:TDD]理解しやすい・修正しやすいコードにリファクタリングしてから、再び本実装に再チャレンジする。（あるいは、[仮実装]で一旦Greenにしてリファクタリングしてから[本実装]に再チャレンジする）
テストコードを追加しづらいと分かれば、テストコードを追加する前に、テストコードを追加しやすいようにテストコードをリファクタリングしてから、テストコードを追加する
実装の修正すると大量のテストが落ちてしまう[Fragile Test:xUnit Test Patterns テストの不吉な臭い]とわかれば、いったんGreen状態に戻って、先にテストコードとプロダクションコードの依存関係がもっと疎にして[Fragile Test]問題を解消するリファクタリングしてから、再び実装に再チャレンジする
先に進めないとわかれば来た道を[戻り]、ゴール達成のための別ルートを試す
ドライバーの手が止まってしまって、言葉だけの伝達が難しいなら、詰まっているところだけナビはちょろっと拾ってあげて、すぐにキーボードを引き渡す。
ドライバーが一人書きすぎていると思った場合 or 全くなんて書けばいいかまったく思いつかない場合、キーボードをちょろっと引き渡してヒントをもらってからキーボードを譲ってもらって続きを書く
etc…

共話

共話とは，「ひとつの発話を必ずしもひとりの話し手が完結させるのでなく，話し手と聞き手の二人で作っていくという考え方にもとづいた」（水谷, 1993：6）話し方です。２人で共話を紡ぎ出すパターンとしては、相づちや笑いなど共感を示すもの、会話文を２人で共同作業で完成させるもの、助け舟のような会話のアシストなどバリエーションがあります。

共話については次も参考にしてください。

https://kansai-u.repo.nii.ac.jp/?action=repository_action_common_download&item_id=10843&item_no=1&attribute_id=19&file_no=1#:~:text=%E3%80%8C%E5%85%B1%E8%A9%B1%E3%80%8D%E3%81%A8%E3%81%AF%E3%80%81,%E3%81%A6%E3%81%84%E3%81%8F%E3%82%82%E3%81%AE%E3%82%92%E3%81%95%E3%81%99%E3%80%82

https://www.eaje.eu/pdfdownload/pdfdownload.php?index=240-245&filename=30_Happyo14_Tadokoro.pdf&p=bordeaux

http://www.lc.osakafu-u.ac.jp/staff/nishio/sozai/JASS23rd%20sim.pdf

ペアプロでのPing-Pong＆共話の組み合わせ

私個人の見解ですが、ペアでのPing-Pong、テスト駆動開発、リファクタリングのステップと「共話」の会話スタイルは非常に相性がよいと考えています。

ソフトウェア開発の問題設定＆問題解決は複数の選択の中からトレードオフ判断をしながら選択し続けることの連続です。また、不確実性の伴った問題は１人で解くには難しいことが普通です。この意思決定を、特定の一人の断定的な話法＆実装で無理に推し通すのではなく、複数の多様な意見をモザイク状に織り交ぜながらものづくりをすすめるが有利に働きます。その際の具体的な進め方として、Ping-Pongのようなドライバーとナビゲーターの頻繁なスイッチのリズム、あるいは共話のような会話のリズムがヒントになります。

頻繁なスイッチ−共話が続けば、文字通り無我夢中で１人の我が消えていきペアが全面に立ち現れペアで１つのフロー状態に入ってきます（もうちょっと正確に表現するならTDDのコンテキストでは、ペアだけでなくコンピューターも共話に参加しており、２人と１台のマシンが１つになってのフロー状態に入る。）。

ペア＋１マシンのが一体となったフロー状態に入れば一人では解くのが難しい−時間がかかる問題も解けるようになってきます。

普段のペアプロを振り返る際に、開発のベイビーステップとドライバーとナビゲーターのスイッチのタイミング、２人の会話のフローを振り返ってみて、修正してみてはいかがでしょうか？２人の間でスキル差がある場合も、はじめはナチュラルなペアのスイッチ＆共話関係ではないかもしれませんが、繰り返すことで２人＋１マシンのリズムが合うように工夫を続け相互のリスペクト＆信頼を深めていくことになります。

スキル差を埋める目的のペアプロは次も参考にしてください。

知識差−スキル差を埋めるためのペアプロ＋αのコツ(1)

ペアプロを始めてみたものの、熟練者と初心者の間で知識差−スキル差が大きくうまくいかない時のコツ

twop.agile.esm.co.jp

知識差−スキル差を埋めるためのペアプロ＋αのコツ(2)

ペアプロを始めてみたものの、熟練者と初心者の間で知識差-スキル差が大きくうまくいかない時のコツ