エンジニア界隈では実務をこなしながらチームを育てる手法としてペアプログラミングというものがあるが、この手法はエンジニアとデザイナーが協業する際にも取り入れる価値があるのではないかと思う。
内容としては、1人が実装しながら常に何を考えているか発話するドライバーを担当し、もう1人はナビゲーターとなって実装者に対しリアルタイムでレビューや質問を行い、最終的な成果物を生み出す。
この手法のよいところは、リアルタイムで発話したりフィードバックを得ることで、メンバー間で知識を共有できることと、常にレビューをされている状態のためコードの品質が担保されるだけでなく、実装後の認識のずれがなくなる、といったことが挙げられる。
これらのうち最後に挙げた「認識のずれ」は、デザイナー×エンジニアのように他業種と協業する際にも発生しやすい問題だ。モーションの調整やブラウザ幅の可変時の見え方などでよく生じる。この問題に対するアプローチはいくつかある。
例えば、手描きのラフを共有する方法。デザイナーの負荷が軽く、なんとなくのイメージが伝わるため大きなずれは生じにくい。また、より具体的な画面イメージをデザインツールでつくってしまう方法もある。デザイナーの負荷はかなり高くなるものの、細部までの再現性は上がる。
しかしこれらの手法には1つ問題点がある。どんなに頑張ってイメージを作ったとしても、その指示を読み取るエンジニアが認識を誤ってしまえば、デザイナーの意図とは違った実装をしてしまうという問題だ。なのでそういった問題が発生しないように、イメージを共有するだけでなく、お互いが納得いくまで議論して実装する必要があると思う。
例えばある案件のモーション調整では、デザイナーと一緒に１つの画面を見てリアルタイムでフィードバックを得ながらの実装を行ったが、ほぼ1日で完成系までもっていくことができ、その後大きく調整が入ることはなかったと思う。可変時の挙動についても同様だ。このときに手戻りが少なかった理由としては至極単純で、ナビゲーターが正しい道を示し、細かくフィードバックすることでドライバーが誤った方向にハンドルを切るリスクを抑え、最短の道を進むことができたからだ。これもある意味ペアプログラミングといえるだろう。
ペアプログラミングの内容については上述した通りではあるが、エンジニアとデザイナーでする際は、エンジニアの実装を待つ時間が発生するのでリアルアイムの必要はない。しかし、1つの画面を見ながら細かく認識をすり合わせて進めていくこの手法は認識のずれが発生しづらいだけでなく、相手がどのようなことを考えているのかを知るよい機会になる。
たまに、私に依頼したらいい感じに調整してくれる、と言っていただくことがあるが、それは、これまで協業した経験から「たぶんこのときはこうしてほしいんだな」と推測できるからだ。この手法は皆がそうなる手助けをしてくれるだろう。
また、2人で1つのことをするので作業が遅くなるように感じるかもしれないが、認識にずれがあった場合に再調整の時間がかかることを考えるとむしろ効率的であるとも思う。
テキストやイメージだけではどうしても伝わりきらないことは往々にしてある。そういう時は相手（ときにはチーム全体）と一緒に1つの画面を見て議論しながら実装するようにしたい。
