時間に追われてもまずまずの出来の資料の作り方

ペアプログラミングは、二人一組がコードを書く役割と書くコードに対してプロポーズ（積極的に提案）する役割になってコードを書くプログラミング技法です。

＃かなり雑な説明ですけど

技術のギャップが強制的に徒弟関係を作れる

ペアプログラミングの良い点は、技術的に優秀なエンジニアと組むことで成長途中のエンジニアに対して（そのコードを書いている間に限り）徒弟関係が成立することです。

徒弟関係が成立する間は、積極的に優秀なエンジニアの技術移転が進む環境が作られます。成長途中のエンジニアに対し、技術的なホワイトスペースや仕様をコードに変換する思考、つまり、発想の仕方を半ば強制的にインストールすることができます。

まあ、捉え方によっては、ですけど。

徒弟関係で技術移転を図れる

でも、技術的なギャップは意識をせずに生じるものですから、なら一層のこと技術的なギャップを作り、優秀なエンジニアから成長途中のエンジニアに技術移転を図ることが組織的な技術の向上を進める上で採用しない手はないことになります。

では、コードになる前の、

「仕様案を作る際のペアプログラミングに相当する手法はないのかしら」

と思ったのです。

文書作成でも同じ効果の方法があるか

さて、あるのでしょうか。「ブレスト」はどうでしょう。イメージします。会議室に複数人が集まり、ファシリテータがホワイトボードの前に立ち、テーマについてディスカションを促します。

現実はどうでしょう。ブレストでも他の会議でも話す人は話すし、話さない人は話さない。

では「レビュー」はどうでしょう。レビューアとレビューイに分かれ、レビュー観点に沿って指摘をし、合否を決定します。

ペアプロと圧倒的に違うのはレビュー対象が事前にできていることが前提で、静的なオブジェクトに対してウォークスルーするのです。また、レビューは基準をボーダーとして合否を決め、リジェクトされれば修正の上、再レビューというプロセス設計になっているところがあります。ペアプロはその場でより良いコードに修正して行きますから時間に対する価値観が違うという見方もできます。

知っているインプットでしか仕様は作れない

以前、トラブルの説明をする必要があるにも関わらず、技術的な情報を持ち合わせていない（メンバが知っている）ときに、プロジェクタにワードを映し、メンバにはそばについてもらい、技術情報を教えてもらいながら資料を作ったことがあります。

ある意味、ペアプログラミングの手法をしつつトラブルの説明資料を作ったとみなすことができるでしょう。

その際の経験で思ったことは、インプットをもらいながら文字に変換しなければならないので「会話」をしながら文字を生成するプロセスをするのはしんどいな、ということです。

じゃあ、会話せずに文章を作ればいいじゃないかと思うかもしれませんが、何せ情報を持っていませんから会話をせざるを得ないのです。

会話をする、理解する、文字で表現する、実際に打ち込む、声に出して読み上げる、ということをリアルタイムにするわけです。

とても難しい作業で終わった後、さずがにヘタリましたがアウトプットされた資料はまずまずでしたし、出来上がりも早かったです。

この事例から、ペアプログラミングと同じように仕様を検討する資料を作る（デザインする、でもいいかも）際にも、ペアで作成する方が効果的かもしれません。