難易度は？ 効果は？ 実践して初めて分かった「ペアプログラミング」の実際

　この20年ほどの間に、「ウォーターフォール」へのアンチテーゼとして現れた、XP（エクストリーム・プログラミング）やScrumと呼ばれる「アジャイル」な開発手法が浸透してきた。中でも、近年ではXPの一部を構成する「ペアプログラミング（ペアプロ）」に対する関心が高まりを見せているようだ。ただ、ペアプロという手法があることを知ってはいても「どのように導入を進めれば良いか」「どのような効果があるのか」については、漠然としたイメージしか持っていないという人も多いのではないだろうか。今回、Yahoo! JAPANのヤフオク!カンパニーにおいて「Lean XP」の一部としてペアプロを導入した山下真一郎氏と、日本におけるテスト駆動開発（TDD）の第一人者である和田卓人氏に、自らの実践の中で感じているペアプロのメリットや、導入のポイントについて語ってもらった。

「Lean XP」の一部としてペアプロの導入に挑んだ「ヤフオク!」

和田：山下さんは、先日の「Developers Summit 2017」でも講演をされていましたが、改めてヤフオク!公式アプリの開発チームで、どういった取り組みを行ってきたのかをご紹介ください。

山下：私は、2016年9月から約2か月間、企業向けにアジャイル開発を教えているPivotal LabsでLean XPの修行をしてきました。Lean XPは、エクストリーム・プログラミング（XP）とリーンソフトウェア開発を組み合わせた開発手法です。その開発手法を半年前にヤフオク!に持ち帰り、開発現場に広めることを行っています。

和田：Lean XPは具体的にどのような開発手法なのでしょうか。また、得られた効果はいかがでしたか。

山下：Lean XPは定量分析、定性分析の結果からペルソナを作成し、そのユーザーに対してどのような価値を提供するのかを定義します。この、ユーザーに提供する価値の粒度をできる限り細かくして「ストーリー」と呼ばれる単位に落とします。Scrumでは「プロダクトバックログ」と呼ばれるようなものに近いですね。このストーリーごとの実装を、テスト駆動開発（TDD）とペアプロで繰り返していくという感じです。サイクルを細かくすることで、後工程での手戻りを最小限に抑えることができます。

　分かりやすい定量的な効果として、受け入れテストの失敗率が激減しました。導入前と比較して、約20分の1になっています。以前は、開発期限が厳密に決められている中で、スケジュールに間に合わせるために急いで開発を進めなければならない状況が多くのミスを生んでいました。現在では、統合テストの段階でバグをだすことは、ほぼなくなっています。

山下真一郎（やました・しんいちろう）氏

　ヤフー株式会社 ヤフオク!カンパニー開発本部。2011年度にYahoo! JAPANに新卒で入社し、Yahoo!メッセンジャー、Yahoo!メール、ヤフオク!などでiOS、Android両OSの開発を経験。現在はiOS版ヤフオク!アプリのプロダクトマネージャーを務め、Lean XPという開発手法を導入した高速で高品質なソフトウェア構築を行っている。

「1人より2人」「2人より3人」でスタートするのが成功の条件

和田：ヤフオク!でのペアプロ導入は、素晴らしい成功事例ですよね。Pivotal Labsが、XPのワークショップ的なことをやっているのは知っていたのですが、その成功事例がこんな身近にあったとは驚きでした。

山下：他に、ペアプロを実際のプロダクト開発に採用している企業というのはあまりないのでしょうか。

和田：ペアプロという考え方そのものはよく知られるようになりましたが、御社のように実際の製品開発に導入しているというケースはまだ少ないですね。

　大きな理由としては、ペアプロが経済性の面で誤解されているというのがあります。単純に「1つのコードを書くのに2人以上のプログラマーが携わる」という部分だけを見てしまうと、マネジメントの観点では「工数が倍になる」ように見えてしまうんです。もう一つは、食わず嫌いでしょう。未経験の手法であるために、現場としてはどうしても実践に抵抗を感じてしまうのだと思います。実際にやってみると、8割の人は良いと思ってくれるのですけれどね。

　こうした理由で、ペアプロに興味はあるけれど「入り口でつまずいてしまっている」というケースはとても多いと感じています。ちなみに、Pivotal Labsでペアプロを学ばれたのは、山下さんお一人だったのですか。

山下：いいえ。エンジニアが2名と、プロダクトマネージャーとして私が参加しました。

和田：なるほど、3名が最初に学ばれたのですね。恐らく、それが成功の一つのポイントだったと思います。

　ペアプロに限った話ではないのですが、新しいプログラミング手法をチームに導入していくときには、チームに仲間が必要です。1人で広めていくのはとても大変なんですよ。特に、導入初期には「こういう時にはどうすればいいのだろう？」「うちのチームでは、どう判断するべきか？」と迷うことが多いのですが、そのときは味方が解説本だけだと追い詰められてしまいます。

　最初に、できれば3人、ないしは2人で学び、それをチームに持ち帰って、最初は知っている人たちでデモをし、その後、新しい人にペアに入ってもらいながらローテーションすることで、徐々にできる人を増やしていくというやり方がいいと思います。エンジニアリングプロセスは、基本的にそのペアプロの中で伝えていく形になります。ペアプロを理解している人が1人だけだと、なかなかチームはついてきてくれませんね。

山下：現在、Yahoo! JAPANでは継続的にPivotal Labsに人を送って、ペアプロが可能なチームを増やしていこうとしています。ヤフオク!では同時に複数チームでXPの導入を進めようとしているのですが、TDDエンジニアが間に合わないなどの問題が起こり始めていて、こうした課題にどう対応していくべきか考えているところです。

和田：XPは、非常にスケールしづらいですね。スケールさせるためのプラクティスが、まだ確立されていません。段階的に、じわじわと広げていくことはできるけれども、パラレルに複数のチームを一気に立ち上げるようなことは難しいだろうと思います。

　それでもやろうと思うのであれば、初速を付けるために外部の経験者を何名か連れてきてチームに入ってもらうというやり方がいいように思います。根付かせる過程では、「テストはどうする」「コミットはどうする」「プルリクエストの単位はどうする」といった細かい質問に答えられる経験者がどうしても必要になりますから。

　「負けパターン」としては、本を読んで「よし、XPやるぞ！」と思い立ったものの「メンバー全員が未経験」というのが典型的なんです。その点、Yahoo! JAPANの場合、Pivotal Labsに複数で参加して学んでいるというのが良いと思いますね。

和田卓人（わだ・たくと）氏

　タワーズ・クエスト取締役社長。日本におけるテスト駆動開発（TDD）の第一人者でありスペシャリスト。学生時代からオブジェクト指向分析、設計を手がけ、2000年ごろよりXP（エクストリーム・プログラミング）に出会う。その後、現在まで10年以上にわたり、TDDのエバンジェリストとしての活動を続けている。

多くの企業でペアプロが根付かない理由――「稼働率」より大事な「生産性」の視点

山下：Yahoo! JAPANの中では、ヤフオク!以外の部門でもペアプロブースを作って実践を試みているところが出てきています。ただ、経験者がいない状態でやっているケースもあり、どうすればいいか分からないといった状況になることもあるようです。

　自分は実際にペアプロを学んでみて、本などには載っていないペアプロならではの技術が必要だと思っているのですが、それがない状態でやっていると、どうしても「チーム全体での技術の底上げ」という側面でしかペアプロを見られないのではないかと感じます。ペアプロを継続していくことで、「スループットを上げていく」とか「仕掛かりを減らす」といった側面が見えていないと、「みんな一通りできるようになったので、ペアを解体しましょう」となってしまい、根付かないんです。

和田：「技術の底上げしか見えていない」というのは面白い視点ですね。ペアプロをOJTのようなものとして見ているということでしょうか。たしかに、それだけがペアプロの目的だと捉えてしまうと「技術の底上げができたのでやめよう」という思考になってしまいますね。

　ペアプロと開発効率の関係で言うと、「100％ペア」と「100％ソロ」で比較した場合、単純な「稼働率」ではソロのほうがもちろん多いです。ただ、単位時間内にどれだけのコードが本番リリースされていくかを「生産性」と捉えると、スループットや仕掛かりの時間も考慮する形になり、結果的にペアのほうが生産性が高くなるんですね。

山下：つまり「生産性」という指標を、どういう視点で捉えるかによって変わってくるわけですね。

和田：はい。現在のアジャイル的なプログラム開発では、プロジェクトマネジメントとして我流のScrumを使い、エンジニアリングプロセスについてはXPのようなカッチリとした枠組みではなく、GitHubのようなツール主導でやるというのがよくある形なのではないかと思います。そこで問題として認識され始めているのが、コードレビューのコストやそのための仕掛かりの多さなんです。

　アジャイル的なプロセスを取り入れたことでコードは速く書けるようになった。しかし、そのレビューに、今まで以上に時間がかかってしまうという状況です。レビューがベテランにしかできないものだった場合、本来、良いコードを書けるはずのベテランがレビューに忙殺され、さらにボトルネックにもなってしまうわけです。この、積み上がっていく仕掛かりのレビューやプルリクエストの多さを何とかしないといけないという問題意識の中で、ペアプログラミングのようなプラクティスが再評価されているのではないかと思います。

山下：たしかに、ペアプロ導入後にコードレビューの質が格段に上がったことは実感しています。私たちの場合は、ペアプロがリアルタイムなコードレビューになるので、プルリクエストなしでプロダクションに出すようにしたおかげで、スピードも大きく向上しました。

和田：ペアプロから得られる効果としては、そこが最大の魅力でしょうね。この「レビュー」のコストに対する問題意識は以前からありました。例えば、新人のプログラマーに機能を1つアサインして書いてもらうとしますよね。で、レビューをしようとしたら、そもそもの部分から間違っていてどうしようもないと。

山下：……つらいですね（笑）。

和田：そうなると完全な手戻りになってしまうので、それを避けるために「もっと前に相談してくれ」とお願いをする。つまり「こういうことをやろうと思っている」ということを生煮え（WIP：Work in Progress）の状態でもいいので、書いて出してくれということになります。そうすると、今度は「レビュー頻度が増える」んですね。

　この環境で作業をしているチームは、コードを書く時間よりも、レビューをしている時間のほうが長くなってしまいがちです。それなら、掛かる時間としては「ペアプロ」とあまり変わらないんじゃないかという考えも出てきます。

　ペアプロでは、コードを書いている段階で常時レビューが行われている形になるので、プロダクションにコードが出ていくスピードは上がります。結果として、「コーディングの人数は倍かかるけれども、スループット量で見れば、ペアプロのほうが"生産的"だ」と捉えることもできるわけです。

山下：ペアプロがうまく回れば、品質は上がり、レビューと手戻りの時間は劇的に減らせるわけですから、メリットは大きいですよね。

和田：もっとも、オンラインコードレビューにも良い部分はあるんです。プルリクエストを通じて「履歴」を残せるというのはその一つです。GitHubのようなツールでは、リリースに至る意思決定の過程をURLの形でたどっていける点が良いと思っています。これによって、ソフトウェア開発の現場は大きく進歩しましたので、残していきたい部分です。

山下：たしかに「履歴」は必要ですね。ただ以前、バグが混入し障害が起きたときは、いつ誰が作り込んでしまったのかが追えるよう「プルリクエストを出して、履歴を残してくれ」とお願いしたことがあったのですが、エンジニアからは「ペアプロで全員がペアをローテーションしながらコードを書いており、常にコードはリファクタリングされているので履歴を残すことに意味がないのではないか」と言われてしまいました。

和田：なるほど。では、ちょっと視点を変えましょう。ペアプロにおいて「履歴を残す」というのは、いわゆる「バグの犯人捜し」のためではないんです。

　ペアプロをやってもらうと、一定数「面白いけれど、達成感がない」と感じる人がいます。理由としては、複数人でコードを書くので「ここは自分が書いた」と言える部分がなくなるためなのですが、これはつまり「ペアプロでは、障害の責任を個人に問うことができない」ということです。

　ペアプロを導入すると、プルリクエストを出す絶対的な必要性はなくなる一方で、プロマネの立場としては「履歴をたどれる」ようにしておきたいのでプルリクエストを出してほしい。となると、プルリクエストを「証拠を残す」ためではなくて、「品質の見える化」の母体になるものと捉えてもらえるようにもっていくのがいいと思います。プルリクエストを作ることで、生産性が上がり、楽になり、楽しいと感じてもらえる仕組み作りが必要ということです。

山下：具体的には、どういった仕組みが有効なのでしょう。

和田：いろんな方法が考えられると思います。例えば、ペアでもソロでも、ブランチがマスターに下りてくるまでには、通常2～3日の時間がかかります。その間、本番でそのコードが本当に動くかどうかが確認できないというのはあまり健全な状態ではありません。その打開策として、CIをプルリクエスト単位で回すようにして、結果をプルリクエスト上で確認できるようにするというのは良いやり方だと思います。プルリクエストの実体はブランチなので、プッシュしたらすぐCIが走り、より本番に近いステージング環境のようなところでテストが動き、問題がないことが確認できるような仕組みですね。

山下：今、ヤフオク!のチームでは、過去10回分のユニットテストの結果をモニタリングできるようにしています。エンジニアの作業単位であるストーリーの粒度は10分程度の作業量で完了するたびにCIを走らせているので、頻繁にテストが動いています。これによって「手戻り」は非常に少なくなっています。

和田：あと、プルリクエストを出すことで、そのブランチのカバレッジがどのくらい変化したかとか、コードの複雑性がどう変わったとか、その変更がアプリそのものの品質にどの程度の影響を与えたのかを可視化して通知するような仕組みを組み込めると、プルリクエストを作ることに、よりポジティブな意義を感じてもらえるようになるのではないでしょうか。

「ペアプロにどうしてもなじめない」メンバーにどう対応すべきか

山下：ペアプロの導入当初に苦労した点として、ペアプロになじめない人をどうするかという問題がありました。Pivotal Labsは、XPに共感し集まってきた人ばかりの環境だったので、そこではペアプロをやることに特に問題を感じていなかったのですが、いざヤフオク!に持ち帰って広げていこうとしたところ、どうしてもなじめないという人が出てきてしまったんです。

和田：たしかにペアプロについては、そういう話はよくあります。

山下：今、ヤフオク!のソースコードは、ペアプロで書かれたコードしかプロダクションに入れないというルールにしています。そのためなじめない人たちにも、「ルールだから」ということで、ペアプロをしていただいている状況です。こうした場合の良い解決策はあるのでしょうか。

和田：ペアプロが「合う」「合わない」というのは、プログラマーの個性の問題なんです。自分が作業をしている様子を他の人に見られることで必要以上に緊張してしまう人はいます。チームにペアプロを導入しようとする場合、なじめない人というのは、だいたい1～2割出てきてしまうということがデータとしても知られているんですよ。

山下：うちでも、だいたいそのくらいの割合でしたね。その場合、どのように対応するのが良いのでしょう。

和田：うーん。基本的に、ペアで書いたものしかプロダクションに入れないというルールなのであれば、チームから抜けてもらったほうがいいと思います。

山下：なるほど。

和田：ペアプロは、XPの中でも一番過激なプラクティスです。教育的な意味でも、品質向上の面でも、うまくはまれば効果は高いのですけれど、その分、副作用も出てきがちです。

　アジャイルの文脈では、よく「バスに乗る」とか「バスから降りる」という言い方をします。同じバスに乗っていても、酔いやすい人と平気な人がいますよね。もし、バスの運行スタイルやルートが決まっているのであれば、それに合わずに酔ってしまう人が無理して乗り続けていても良いことはないです。何より本人がつらいでしょう。

　これは、あくまで「個性」の話で「スキル」とはまったく関係のない問題であること、このチームは特殊なプロセスで開発を行っていることを本人にも十分に理解してもらったうえで、ソロで実力を発揮できる場に移ってもらうというのがベストだと思います。

山下：そのあたりは仕方のないことと、お互いに納得するしかないのですね。

和田：ペアプロとの相性という意味では、コードを書くことに達成感を求めるタイプの人も自分には合わないと感じることがありますね。ペアプロでは交代やローテーションをしながら書くことで、ここのコードは俺が書いたという部分がなくなってしまうんです。それは、裏を返すとコードの属人性を回避でき、多くの人がその内容を知っている状態にできるというメリットなのですが、先ほど少し触れたように、中にはペアプロは、面白いけれど達成感がないと感じてしまう人もいます。

山下：そういうケースもあるのですね。

和田：実際、ペアプロを試してみようというとき、最初から全員がやる気まんまんというチームは少ないですね。約半数の人は、興味はあるものの、これまでにない作業形態になるので、ちょっと拒否反応を示します。で、実際にやってみるとそれが食わず嫌いであったことが分かり、やってみたら良かったと感じてくれる。でも、どうしても合わないという人が、最終的に2割くらい残ってしまうんです。

ペアプロの実践で見えてきた「さまざまな課題」と解決のヒント

和田：ペアプロの導入に対して、他にメンバーからは、どんな感想や意見が出ましたか。

山下：今、週1回振り返りをやっていまして、その中でいろいろ出てきていますね。意外だったのは「休憩が取りづらい」というものです。

和田：ペアプロは体力を使いますからね。

山下：私がPivotal Labsでペアプロを学んだときには、昼休憩の他に午前と午後それぞれ3セットずつ卓球をやっていました。なので、そのやり方をそのまま持ってこようと思い、Yahoo! JAPANにも卓球台を置いたんです。

和田：それはすごい。

山下：ただ、Yahoo! JAPANは会社として、お昼に休憩をとる文化なので、勤務時間に卓球しているところを見られると他の社員から遊んでいると思われそうという理由で、あまり休憩できないという意見がありました。ただ、ペアプロでお昼以外に休憩をとらないと、かなりしんどい状態になってしまうので、そのあたりは休憩を取るよう声がけを行っています。

和田：遊んでいるように見られるというのは、ペアプロに限らず、新しいプラクティスを取り入れるときの一番の問題ですね。例えば、Slackなどのチャットツールはその最たるもので「チャットしているのを部長に見られると『遊んでいる！』と文句を言われる」という話はよく聞きます。そういうセリフで、エンジニアの草の根の取り組みがつぶされてしまうという例は山ほどあるんです。それを打破するためにも、マネジメントや経営の立場にいる人の理解を得るのが大事です。

山下：その他にはペアプロに携わるメンバーの人事的な評価をどうしていくべきかという課題もあります。Yahoo! JAPANの評価基準として「個人として、いかにチームに貢献したか」という軸があるんですが、ペアプロをやっていると、個人として目標を達成する時間がなかなか作れないというのが現実です。この場合、企業として個人を評価する基準がペアプロに合っていないということになるので、今後はそのあたりについても考えていく必要があるだろうと思っています。

和田：「会社としての評価」の部分で、既存のものとフィットしないというのは難しい問題ですね。ここについては、ペアプロに携わる人の評価はチームで合意し、均一化するといったようなラディカルなやり方しかないような気もします。一方で、Yahoo! JAPANでは、ペアプロを全社的に広げていく取り組みを続けていらっしゃるというお話しでしたが、経営層に対しては、どのような形で説得されたのですか。

山下：私たちのチームへの導入で、リードタイムが非常に短くなったことと、アプリの品質が高まったということを実証できたのが大きいですね。アプリに障害が出てしまうと、手戻りも発生しますし、再発を防止するための取り組みなどで実装よりも格段にコストが掛かってしまうという問題が現実にありました。それを解決するための方策として、ペアプロやTDDを実践しているLean XPを導入し、アプリの品質を上げたいということを訴えてきました。

和田：ここでの「品質」は「不具合の少なさ」という意味ですよね。XPのような手法は、実はiOSやAndroidのネイティブアプリの開発に取り入れやすいんです。

　もし、Webアプリなら、不具合が発生したとしても、直してデプロイしてしまえばそれで基本的には解決していまいます。Webアプリでは、不具合が発生して、それが発見されて修正されるまでのスピードが速いことも「品質の高さ」になります。

　一方、ネイティブアプリの場合、製品に不具合があった場合には、修正した後でユーザーにアップデートしてもらうしかありません。不具合が発生することで、ユーザーからの評価も下がり、その後のビジネスに悪影響を与えるリスクも高まります。ネイティブアプリは、「はじめから不具合を出さないように開発する」ことが「品質の高さ」にとって重要という点で、従来のソフトウェア開発に近いと言えるかもしれません。

山下：iOSアプリの場合、発生した不具合を直したら、再びストアの審査を受けなければリリースできないというのも大きいですね。私たちの場合、サービスの規模がどんどん大きくなっていることで、手作業で行うテストに膨大な工数がかかるようになっていました。すべてをまともにやろうとすると、どう見積もっても10か月以上は掛かります。だからといって、テストを主要な機能のみに絞れば、それによって不具合を見逃す可能性も高まります。その現実的な解決策として、「ペアプロ」と「テスト駆動」で品質を上げたいと考えていることを訴えてきました。それを、経営層も認めてくれているのではないかと思います。

和田：それは「テストを書く時間がない」とボヤくよりも、より説得しやすい理論付けだと思いますね。新しい開発手法の導入にあたって、他の企業でも参考にできるのではないでしょうか。

エキスパートが語るペアプロの「楽しさ」

和田：「ペアプロ」を実践してみて、現場のプログラマーが感じられる一番の「楽しさ」とは、どういったものとお考えでしょうか。

山下：一番大きいのは、「自分の技術力が上がっていることがすぐに実感できる」ところですね。便利なショートカットや、自分の思いつかなかった実装方法、本には載っていないようなトラブルシューティングの方法などを、ペアになった相手から「その場」で教えてもらえるというのは、とても刺激になります。

　あと、ペア同士で互いに刺激し合うことで向上心が高まり、技術に関する勉強を以前にも増してやるようになったという人が増えました。さらに、手戻りが減って、バグを出す確率も下がったことで、メンバーに「自信がついた」ようにも感じています。これは、本当に喜ばしいことだと思っています。

和田：私が感じるペアプロの一番の楽しさは、いろいろな課題が「シンプル」になることです。1人で考えているときには「複雑」と思えた問題に、2人で解決にあたっているうち、非常に「簡素」な形で答えが出ることがあります。これには、驚きを伴う楽しさがありますね。ペアプロには課題をシンプルにする力があるんです。

　もう一つの醍醐味は、ものを作っていく際の「過程」を見ることができるという点です。思考しながらものを作り上げるというのは、複数の選択肢の中からどれかを選び出し、最終的に1つに収束させていく作業です。私は、その「過程」こそが、エンジニアリングスキルの本質に近いと思っています。普通、1人でものを作っているときには、そうした過程を客観的に見られないのですが、ペアプロだと常にそれを見ることができます。

　コミットされたコードというのはあくまでも「結果」で、コミットとコミットとの間には、そこに至る思考や作業の過程があります。細かい例だと「コードを上から書いたのか、下から書いたのか」といった書き順は、作業時の思考を表すものですが、それは最終的なコードや本からは分かりません。それを知るためには、ライブコーディングを見たり、ペアプロをやったりするしか方法がないんです。また、スキル差があるペアであれば、ベテランプログラマーが、ある問題に対して、どういう思考過程をたどって、どのくらいの時間で解決に至るのかといったことを目の前で見て、学ぶことができます。これは、ペアプロならではの面白さです。

山下：たしかに、リファクタリング前のソースコードを見られるというのは、いい刺激になりますよね。

和田：リファクタリングの工程は、粘土をこねて試行錯誤しながら最終的な形を作っていく作業に近いですよね。そのこね回す過程で、エンジニアとしての腕やプログラミングの腕が振るわれるんです。

　Gitというのは、私は「恥ずかしがり屋」のためのバージョン管理システムだと思っていて、コードを書く過程を最終的に改ざんし、きれいに仕上がったものだけを残しておくということができてしまうんです。それは「途中で試行錯誤した過程を残しておくのは恥ずかしい」という人の心理に合ったシステムだということもできるのですが、私としてはその「試行錯誤の過程」にこそ、本質的な何かがあるだろうと思っています。

　……まぁ、受け入れられない人にとっては、「試行錯誤を見られてしまう」ことこそがペアプロの嫌なところでもあるんですけれどね。

「無理をし過ぎず」「とにかく試しにやってみる」のがペアプロ導入の第一歩

山下：これからペアプロの導入を考えているという人に向けて、何かアドバイスをいただけますでしょうか。

和田：私から言えるのは、無理をし過ぎるなということでしょうか。ペアプロを実践すると「とても楽しい」と同時に「すごく疲れる」という経験することになります。いきなり何時間もできるというものでは決してありません。ペアプロは、XPの中でも特にアクの強いプラクティスです。ある意味「劇薬」なので、ぜひ用量用法を守ってください。

　お勧めは、最初は「1日1時間」とか、「不具合修正のときだけ」とか、「水曜午前だけ」とかいった形で、メリハリを作って導入してみることです。教育効果は間違いなく高いので、チームに新しい人が入ってきたら、他のメンバー全員とローテーションでペアプロをやってみるというところから始めるのも良いと思います。

山下：私からは、とにかく試しにやってみようですね。ペアプロには、実際にやってみて、初めて見えてくる「良さ」と「悪さ」があります。その上で、どのような形で導入するのが自分たちのチームにとってベストかを考えてみるのがいいのではないでしょうか。

和田：「食わず嫌い」が一番もったいないですよね。はじめてみれば、多くの人は良いと感じてくれると思います。

　（「Yahoo! JAPAN Tech Blog」Yahoo! JAPANから、最新の技術情報を発信しています。併せてご覧ください）

---

著：高橋美津
写真：小倉亜沙子