エンジニアが自分の作成過程を見てもらうことで得られる学びと効果と

ただ、そのペアプロをプログラミングだけに限定するのはもったいないか、と。エンジニアがプロジェクトで関わる機能仕様の設計や開発構築での手順の作成や試験仕様の設計でもペアプログラミングの手法を使うとちょっと一人で閉じこもって仕事を続けるよりいいのでは？と。

ペアプロで文書を作成すると何が期待できるか
エンジニアが何かdeliverableを作成するという情景を思い浮かべると、誰もが、もう決まり決まったシーンしか思いつかないのではないかな、と。エンジニアが猫背になってディスプレイに顔を沈めてタイポをしているような。

ディスプレイの中はそのエンジニアの箱庭の世界だから、ディクストップに並ぶアイコンのレイアウトも、設計で使うツールも、開発設計で使うエディタも好みというバイアスが働くので百花繚乱なことになったり。

開発標準が定めれられたりしてれば、開発環境で使用するツールは共通でしょうけれど、それでも少しずつエンジニアの嗜好というか性癖が表現されるんですね。そしてそれはめったに晒されることもない。

エンジニアとしての仕事の道具を自分の関心だけで集め、評価し、使用することはやはり情報を得るという点においてやっぱり狭くなるものだと思わざる得ないです。それで満足していていいのか、と。もっと違う世界があるのだと、もっと便利な世界がまっているのだと。

そう、ペアプロでコードではない文書を作るという行為に利用されるツール、その利用方法、ツールを介した思考の表現をエンジニア同士が知ることが出来るのです。

それは先に書いた様にエンジニアが自然と自分の世界に閉じこもりがちな環境を見られるということで互いにエンジニアリングの工程を目で確認し、学ぶ機会となることが期待できるのです。

声を出して文書を書く
実は、ときどき、ペアプロ風に文書を作ることがあるんです。えっ？「そんなのあるの？どんなとき？」なのかって？

ワタシに良くありがちなのは、検証結果のまとめのたたき台を作ってもらった後、提出する体裁に仮名遣いや表現やスタイルを整えたいとき、サブディスプレイに大きくそのたたき台を映しながら、たたき台を作ってもらったメンバに横に座ってもらい、タイプする文章を声に出しながらタイプしていくケースです。

これが実にいいんですよ。

言葉の言い回しや前後のコンテキストの整合性を取るのも頭の中でやると変に混線したり、ループしてしまうことがあるんですが、タイプする言葉を声に出しながら打つと結構言葉にする時点で文章を構成しながらまるでインタプリタのように割といい感じに出てくるんです。

でね、もっといいのが頭の中で考えてそのままタイプすると言葉の言い回しや助詞の使い方や文脈のおかしなところに“気付かない”のに、声に出すだけで、いや、声に出した途端に感じが変だ、しっくりこない、おかしいぞ、って“直ぐにわかる”んですよ。

タイプする言葉を声に出すだけで。

コンテンツはたたき台に入っているのでその内容の意味も横に座ってもらっているからすぐに確認できるし、文章のリファクタリングもし易くて、マジいいんですよ。

まぁ、すべての文書でペアプロは物理的に出来ないかもしれないけれど、「ここは外せない！」というケースには絶対にやってみることをお勧めしますよ。試験仕様なんて、試験ケースの取りこぼしがあるかどうか、二人で確認しながら進められるし。