├── .gitignore ├── LICENSE └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | ## Core latex/pdflatex auxiliary files: 2 | *.aux 3 | *.lof 4 | *.log 5 | *.lot 6 | *.fls 7 | *.out 8 | *.toc 9 | *.fmt 10 | *.fot 11 | *.cb 12 | *.cb2 13 | .*.lb 14 | 15 | ## Intermediate documents: 16 | *.dvi 17 | *.xdv 18 | *-converted-to.* 19 | # these rules might exclude image files for figures etc. 20 | # *.ps 21 | # *.eps 22 | # *.pdf 23 | 24 | ## Generated if empty string is given at "Please type another file name for output:" 25 | .pdf 26 | 27 | ## Bibliography auxiliary files (bibtex/biblatex/biber): 28 | *.bbl 29 | *.bbl-SAVE-ERROR 30 | *.bcf 31 | *.blg 32 | *-blx.aux 33 | *-blx.bib 34 | *.run.xml 35 | 36 | ## Build tool auxiliary files: 37 | *.fdb_latexmk 38 | *.synctex 39 | *.synctex(busy) 40 | *.synctex.gz 41 | *.synctex.gz(busy) 42 | *.pdfsync 43 | *.rubbercache 44 | rubber.cache 45 | 46 | ## Build tool directories for auxiliary files 47 | # latexrun 48 | latex.out/ 49 | 50 | ## Auxiliary and intermediate files from other packages: 51 | # algorithms 52 | *.alg 53 | *.loa 54 | 55 | # achemso 56 | acs-*.bib 57 | 58 | # amsthm 59 | *.thm 60 | 61 | # beamer 62 | *.nav 63 | *.pre 64 | *.snm 65 | *.vrb 66 | 67 | # changes 68 | *.soc 69 | 70 | # comment 71 | *.cut 72 | 73 | # cprotect 74 | *.cpt 75 | 76 | # elsarticle (documentclass of Elsevier journals) 77 | *.spl 78 | 79 | # endnotes 80 | *.ent 81 | 82 | # fixme 83 | *.lox 84 | 85 | # feynmf/feynmp 86 | *.mf 87 | *.mp 88 | *.t[1-9] 89 | *.t[1-9][0-9] 90 | *.tfm 91 | 92 | #(r)(e)ledmac/(r)(e)ledpar 93 | *.end 94 | *.?end 95 | *.[1-9] 96 | *.[1-9][0-9] 97 | *.[1-9][0-9][0-9] 98 | *.[1-9]R 99 | *.[1-9][0-9]R 100 | *.[1-9][0-9][0-9]R 101 | *.eledsec[1-9] 102 | *.eledsec[1-9]R 103 | *.eledsec[1-9][0-9] 104 | *.eledsec[1-9][0-9]R 105 | *.eledsec[1-9][0-9][0-9] 106 | *.eledsec[1-9][0-9][0-9]R 107 | 108 | # glossaries 109 | *.acn 110 | *.acr 111 | *.glg 112 | *.glo 113 | *.gls 114 | *.glsdefs 115 | *.lzo 116 | *.lzs 117 | *.slg 118 | *.slo 119 | *.sls 120 | 121 | # uncomment this for glossaries-extra (will ignore makeindex's style files!) 122 | # *.ist 123 | 124 | # gnuplot 125 | *.gnuplot 126 | *.table 127 | 128 | # gnuplottex 129 | *-gnuplottex-* 130 | 131 | # gregoriotex 132 | *.gaux 133 | *.glog 134 | *.gtex 135 | 136 | # htlatex 137 | *.4ct 138 | *.4tc 139 | *.idv 140 | *.lg 141 | *.trc 142 | *.xref 143 | 144 | # hypdoc 145 | *.hd 146 | 147 | # hyperref 148 | *.brf 149 | 150 | # knitr 151 | *-concordance.tex 152 | # TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files 153 | # *.tikz 154 | *-tikzDictionary 155 | 156 | # listings 157 | *.lol 158 | 159 | # luatexja-ruby 160 | *.ltjruby 161 | 162 | # makeidx 163 | *.idx 164 | *.ilg 165 | *.ind 166 | 167 | # minitoc 168 | *.maf 169 | *.mlf 170 | *.mlt 171 | *.mtc[0-9]* 172 | *.slf[0-9]* 173 | *.slt[0-9]* 174 | *.stc[0-9]* 175 | 176 | # minted 177 | _minted* 178 | *.pyg 179 | 180 | # morewrites 181 | *.mw 182 | 183 | # newpax 184 | *.newpax 185 | 186 | # nomencl 187 | *.nlg 188 | *.nlo 189 | *.nls 190 | 191 | # pax 192 | *.pax 193 | 194 | # pdfpcnotes 195 | *.pdfpc 196 | 197 | # sagetex 198 | *.sagetex.sage 199 | *.sagetex.py 200 | *.sagetex.scmd 201 | 202 | # scrwfile 203 | *.wrt 204 | 205 | # svg 206 | svg-inkscape/ 207 | 208 | # sympy 209 | *.sout 210 | *.sympy 211 | sympy-plots-for-*.tex/ 212 | 213 | # pdfcomment 214 | *.upa 215 | *.upb 216 | 217 | # pythontex 218 | *.pytxcode 219 | pythontex-files-*/ 220 | 221 | # tcolorbox 222 | *.listing 223 | 224 | # thmtools 225 | *.loe 226 | 227 | # TikZ & PGF 228 | *.dpth 229 | *.md5 230 | *.auxlock 231 | 232 | # titletoc 233 | *.ptc 234 | 235 | # todonotes 236 | *.tdo 237 | 238 | # vhistory 239 | *.hst 240 | *.ver 241 | 242 | # easy-todo 243 | *.lod 244 | 245 | # xcolor 246 | *.xcp 247 | 248 | # xmpincl 249 | *.xmpi 250 | 251 | # xindy 252 | *.xdy 253 | 254 | # xypic precompiled matrices and outlines 255 | *.xyc 256 | *.xyd 257 | 258 | # endfloat 259 | *.ttt 260 | *.fff 261 | 262 | # Latexian 263 | TSWLatexianTemp* 264 | 265 | ## Editors: 266 | # WinEdt 267 | *.bak 268 | *.sav 269 | 270 | # Texpad 271 | .texpadtmp 272 | 273 | # LyX 274 | *.lyx~ 275 | 276 | # Kile 277 | *.backup 278 | 279 | # gummi 280 | .*.swp 281 | 282 | # KBibTeX 283 | *~[0-9]* 284 | 285 | # TeXnicCenter 286 | *.tps 287 | 288 | # auto folder when using emacs and auctex 289 | ./auto/* 290 | *.el 291 | 292 | # expex forward references with \gathertags 293 | *-tags.tex 294 | 295 | # standalone packages 296 | *.sta 297 | 298 | # Makeindex log files 299 | *.lpz 300 | 301 | # xwatermark package 302 | *.xwm 303 | 304 | # REVTeX puts footnotes in the bibliography by default, unless the nofootinbib 305 | # option is specified. Footnotes are the stored in a file with suffix Notes.bib. 306 | # Uncomment the next line to have this generated file ignored. 307 | #*Notes.bib 308 | 309 | .idea/ -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Creative Commons Legal Code 2 | 3 | CC0 1.0 Universal 4 | 5 | CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE 6 | LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN 7 | ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS 8 | INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES 9 | REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS 10 | PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM 11 | THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED 12 | HEREUNDER. 13 | 14 | Statement of Purpose 15 | 16 | The laws of most jurisdictions throughout the world automatically confer 17 | exclusive Copyright and Related Rights (defined below) upon the creator 18 | and subsequent owner(s) (each and all, an "owner") of an original work of 19 | authorship and/or a database (each, a "Work"). 20 | 21 | Certain owners wish to permanently relinquish those rights to a Work for 22 | the purpose of contributing to a commons of creative, cultural and 23 | scientific works ("Commons") that the public can reliably and without fear 24 | of later claims of infringement build upon, modify, incorporate in other 25 | works, reuse and redistribute as freely as possible in any form whatsoever 26 | and for any purposes, including without limitation commercial purposes. 27 | These owners may contribute to the Commons to promote the ideal of a free 28 | culture and the further production of creative, cultural and scientific 29 | works, or to gain reputation or greater distribution for their Work in 30 | part through the use and efforts of others. 31 | 32 | For these and/or other purposes and motivations, and without any 33 | expectation of additional consideration or compensation, the person 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she 35 | is an owner of Copyright and Related Rights in the Work, voluntarily 36 | elects to apply CC0 to the Work and publicly distribute the Work under its 37 | terms, with knowledge of his or her Copyright and Related Rights in the 38 | Work and the meaning and intended legal effect of CC0 on those rights. 39 | 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be 41 | protected by copyright and related or neighboring rights ("Copyright and 42 | Related Rights"). Copyright and Related Rights include, but are not 43 | limited to, the following: 44 | 45 | i. the right to reproduce, adapt, distribute, perform, display, 46 | communicate, and translate a Work; 47 | ii. moral rights retained by the original author(s) and/or performer(s); 48 | iii. publicity and privacy rights pertaining to a person's image or 49 | likeness depicted in a Work; 50 | iv. rights protecting against unfair competition in regards to a Work, 51 | subject to the limitations in paragraph 4(a), below; 52 | v. rights protecting the extraction, dissemination, use and reuse of data 53 | in a Work; 54 | vi. database rights (such as those arising under Directive 96/9/EC of the 55 | European Parliament and of the Council of 11 March 1996 on the legal 56 | protection of databases, and under any national implementation 57 | thereof, including any amended or successor version of such 58 | directive); and 59 | vii. other similar, equivalent or corresponding rights throughout the 60 | world based on applicable law or treaty, and any national 61 | implementations thereof. 62 | 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention 64 | of, applicable law, Affirmer hereby overtly, fully, permanently, 65 | irrevocably and unconditionally waives, abandons, and surrenders all of 66 | Affirmer's Copyright and Related Rights and associated claims and causes 67 | of action, whether now known or unknown (including existing as well as 68 | future claims and causes of action), in the Work (i) in all territories 69 | worldwide, (ii) for the maximum duration provided by applicable law or 70 | treaty (including future time extensions), (iii) in any current or future 71 | medium and for any number of copies, and (iv) for any purpose whatsoever, 72 | including without limitation commercial, advertising or promotional 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each 74 | member of the public at large and to the detriment of Affirmer's heirs and 75 | successors, fully intending that such Waiver shall not be subject to 76 | revocation, rescission, cancellation, termination, or any other legal or 77 | equitable action to disrupt the quiet enjoyment of the Work by the public 78 | as contemplated by Affirmer's express Statement of Purpose. 79 | 80 | 3. Public License Fallback. Should any part of the Waiver for any reason 81 | be judged legally invalid or ineffective under applicable law, then the 82 | Waiver shall be preserved to the maximum extent permitted taking into 83 | account Affirmer's express Statement of Purpose. In addition, to the 84 | extent the Waiver is so judged Affirmer hereby grants to each affected 85 | person a royalty-free, non transferable, non sublicensable, non exclusive, 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the 88 | maximum duration provided by applicable law or treaty (including future 89 | time extensions), (iii) in any current or future medium and for any number 90 | of copies, and (iv) for any purpose whatsoever, including without 91 | limitation commercial, advertising or promotional purposes (the 92 | "License"). The License shall be deemed effective as of the date CC0 was 93 | applied by Affirmer to the Work. Should any part of the License for any 94 | reason be judged legally invalid or ineffective under applicable law, such 95 | partial invalidity or ineffectiveness shall not invalidate the remainder 96 | of the License, and in such case Affirmer hereby affirms that he or she 97 | will not (i) exercise any of his or her remaining Copyright and Related 98 | Rights in the Work or (ii) assert any associated claims and causes of 99 | action with respect to the Work, in either case contrary to Affirmer's 100 | express Statement of Purpose. 101 | 102 | 4. Limitations and Disclaimers. 103 | 104 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 105 | surrendered, licensed or otherwise affected by this document. 106 | b. Affirmer offers the Work as-is and makes no representations or 107 | warranties of any kind concerning the Work, express, implied, 108 | statutory or otherwise, including without limitation warranties of 109 | title, merchantability, fitness for a particular purpose, non 110 | infringement, or the absence of latent or other defects, accuracy, or 111 | the present or absence of errors, whether or not discoverable, all to 112 | the greatest extent permissible under applicable law. 113 | c. Affirmer disclaims responsibility for clearing rights of other persons 114 | that may apply to the Work or any use thereof, including without 115 | limitation any person's Copyright and Related Rights in the Work. 116 | Further, Affirmer disclaims responsibility for obtaining any necessary 117 | consents, permissions or other rights required for any use of the 118 | Work. 119 | d. Affirmer understands and acknowledges that Creative Commons is not a 120 | party to this document and has no duty or obligation with respect to 121 | this CC0 or use of the Work. 122 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## 本ガイドラインの公開にあたって 2 | 3 | 　本ガイドラインは、株式会社ユーザベース スピーダ事業における開発組織が作成したガイドラインを基に、ペアプログラミングに関する知見をまとめたものです。本ガイドラインに記載されている内容は、**ペアプログラミングの一例であり、これだけが唯一の正解ではありません。ペアプログラミングは、チームやプロジェクトの状況、メンバーのスキルなどに応じて、様々な形で行うことができます**。本ガイドラインが、ペアプログラミングの導入や改善を検討されている皆様にとって、有益な情報となることを心より願っております。 4 | 5 | 　本ガイドラインの作成にあたり、数多くの書籍やWeb上の記事等から多大なるインスピレーションを受けました。XPや、ペアプログラミングに取り組み、情報を発信してくれた全ての先達へ、深く感謝の意を表します。 6 | 7 | #### 参考文献 8 | 9 | * ローリー ウィリアムズ, ロバート ケスラー(2003). ペアプログラミング エンジニアとしての指南書(テクノロジックアート訳). ピアソン・エデュケーション 10 | * Kent Beck(2000). XPエクストリーム・プログラミング入門(長瀬 嘉秀, 飯塚 麻理香, 永田 渉 訳). ピアソン・エデュケーション 11 | * Kent Beck(2005).XPエクストリーム・プログラミング入門 第2版: 変化を受け入れる(長瀬 嘉秀, テクノロジックアート 訳).ピアソン・エデュケーション 12 | * Kent Beck,Cynthia Andres(2015). エクストリームプログラミング(角 征典 訳).オーム社 13 | * Ken Auer, Roy Miller(2002). XPエクストリーム・プログラミング 適用編: ビジネスで勝つためのXP(平鍋 健児 翻). ピアソン・エデュケーション 14 | * James Shore, Shane Warden(2009). アート・オブ・アジャイル デベロップメント(木下 史彦, 平鍋 健児, 笹井 崇司 訳). オライリー・ジャパン 15 | 16 | # よりよきペアプロのためのガイドライン 17 | 18 | ## はじめに 19 | 20 | 　ペアプロでは主に、作業をする「ドライバー」と作業を客観的に見てフィードバックする「ナビゲーター」の2つの役割がある。ただし、ドライバーとナビゲーターの役割が固定される状況は好ましくなく、ドライバーとナビゲーターが頻繁に入れ替わるのが良い。 21 | 　本ガイドラインでは、このようにテンポよく作業を進めていき、最終的にはコードが2人の手によってレビューされ続け、あたかもひとりのプログラマーがコードを実装しているような状態を目標としている。お互いの良さを掛け合わせ、お互いの苦手な部分を補完し合うことで、相乗効果を生み出し1+1が3になるかのような成果を生み出せる。このガイドラインはその理想に近づくことを手助けするものである。 22 | 23 | 　ガイドラインの構成は「オフライン編」「オンライン編」に分かれているが、「オフライン編」にはオン・オフ関係なくペアプロを行う上で大切な内容が書かれている。そのためまずは「オフライン編」を読み、そのあと「オンライン編」を読んでオンライン特有の知見を得るのがよいだろう。また【キャッチアップ】で始まる項目には、NJ(New Joiner \- 新入社員・新メンバー) がペアプロを通してキャッチアップしていく際に意識すべきことが書かれている。NJ・受け入れ側の既存メンバー両方に参考にしてもらいたい。 24 | 25 | # \-オフライン編- 26 | 27 | ## マインド 28 | 29 | ### 一緒にゴールを目指す 30 | 31 | 　ペアの2人があたかも1人のプログラマーとして振る舞うためには、同じゴールを共有することが重要である。そのために、作業を始めるときはまずペアの間で共通の認識を持てていることを確認することが大切だ。 32 | 　一緒にゴールを目指し、あたかも1人のプログラマーとして振る舞う事が理想であるため、「相手が教えてくれなかった」「相手がゴールを最初に伝えてくれなかった」「相手が聞いてくれなかった」というマインドになってしまうのは良い状況・状態とは言えない。このマインドは「一緒」の状態ではなく「自分 対 相手」の思考になっていると言える。よって「相手が教えてくれなかったら自ら聞く（相手が忘れているのであればペア側が助ける）」「もしかしたら聞きづらいかもしれないので確認の問いかけをする」等の思考にそれぞれがなれる事を目指す。 33 | 34 | 　 35 | 36 | ### 先生と生徒にならない 37 | 38 | 　片方がずっとドライバーを行い、片方がずっと教え続ける「先生と生徒」のような関係性になっていないだろうか？ペア間の関係が「先生と生徒」という関係になっている場合、基本的に「先生」を上限としたアウトプットしか出なくなってしまう。生徒から先生に質問する事はあったとしても、生徒が先生に疑義を伝えたり、訂正を促すという行動は起こりづらい。 39 | 　ペアプロはお互いの知識や強みをかけ合わせることで最大限の成果を出す事を目指すため、その状況を阻害する「先生と生徒」という関係にならないように注意する必要がある。 40 | 41 | ### 【キャッチアップ】先生と生徒になることもある 42 | 43 | 　NJと既存メンバーを比べたときの知識差は大きい。お互いにその事実を受け入れること。よりよいペアプロのためには先生と生徒の関係にならないことが重要だが、成長していく過程として先生と生徒になることを一時的に受け入れるのも重要だ。 44 | 45 | ### 【キャッチアップ】既存メンバーがNJから質問を引き出す 46 | 47 | 　キャッチアップ時のペアプロは質問が特に有効だ。なぜなら、「わからないことがわかる」からだ。既存メンバーはNJから質問を引き出して、NJがわからないことを明らかにする助けをしよう。そして同じ目線に立ち、NJの質問を受け入れよう。NJの質問により既存メンバーは新たな気付きを得ることができるかもしれない。 48 | 　NJは「自分への説明の時間で開発が止まってしまうこと」にハードルを感じるかもしれない。ここで質問せず疑問を放置するより、質問をして理解したほうが長期的な開発スピードは加速するということを既存メンバーはNJに認識してもらう必要がある。 49 | 　 50 | 51 | ### 流れを止めない 52 | 53 | 　ペアプロは中断に強い。なぜならペアの片方が離脱したり他のメンバーから質問を受けた場合でも残ったもう片方が作業を続けられるからだ。ペアプロ中に話しかけられても、2人とも話し続ける必要はない。1 人が話してもう 1 人は作業を続け、着手中のストーリーを進めるよう意識しよう。 54 | 55 | 56 | ## コミュニケーション 57 | 58 | ### 考えている事を口に出す 59 | 60 | 　自分が思っている以上に自分が考えている事は相手には伝わらない・伝わっていないものだ。しかしペアプロというのは2人のプログラマーがあたかも1人のプログラマーとして振る舞える状態を目指しているため、自身の考えを伝える事は非常に重要な要素である。そのため自分が今考えている事をそのまま口に出してみよう。その結果もう1人がより良いアイディアをさらに出してくれるかも知れないし、間違いがあった場合は指摘をしてくれるはずだ。 61 | 　口に出すことには他にも良い点がある。口に出すことで自分自身の考えを整理したり、口に出す中で新たな発見を得やすくなるという点だ。例えば、プログラムの内容を人形に向かって説明する過程で新たな気付きを得やすくする「ラバーダッキング」や「ラバーダック・タイピング」と呼ばれるテクニックがある。また、コーチングは基本的に相手に話をさせる、考えさせる質問を投げかけることで同様の効果を狙う一面がある。 62 | 63 | 　あまりまとまっていない考えを口に出すのは勇気がいるかもしれない。「変な事を言って相手からの評価が不当に下がってしまわないか」とも考えるかもしれない。それでも、せっかくの学ぶ機会を逃してしまうのはもったいないし、チームの進捗を上げるためにも勇気を持って口に出すほうがよい。 64 | 65 | ### 考えている事を聞いてみる 66 | 67 | 　ときには「相手が自分の考えを話してくれない」と感じる場面もあるだろう。だが、相手は集中しすぎて自分の考えを共有する事を忘れているだけかもしれない。もしくは上記で述べたように「きちんと考えをまとめてから口に出さないといけない」と勘違いしているかもしれない。なので「今どうしようと考えてますか？」「何かわからなくて詰まってます？」というような問いかけをしてみよう。あくまで一緒に課題を解決する・価値を作り出すペアとしてアクションを起こしてみよう。 68 | 69 | ### 【キャッチアップ】 ペースを合わせる 70 | 71 | 　既存メンバーは悪気なくいつものペースでペアプロを進めてしまう。ついNJの理解が追いつかないペースで進んでしまうこともあるかもしれない。そのときは、NJは遠慮せず、思考が追いついていないことを表明しよう。既存メンバーもペア作業を始めるタイミングで「質問があれば遠慮なく止めてください」「ここまで理解できていますか？」など、ペースを合わせるためのコミュニケーションを心がけよう。 72 | 73 | 74 | ### 指示をしない、されたと思わない 75 | 76 | 　指示をする、されるというのは「先生と生徒」で述べた懸念される状況と同じ環境を作りやすい。よって、指示をするようなコミュニケーションは避けたほうがよい。細かいニュアンスの違いではあるが、指示ではなく提案するようなコミュニケーションを意識することでこの懸念される状況を回避しやすくなるだろう。 77 | 　同時に発言を受ける側も「指示をされた or 指示をされている」と受け取らない意識を持つ必要がある。 78 | 79 | ### 相手のタイピングを待つ 80 | 81 | 　人によって考えるスピード、タイピングのスピードは違うという事を認識すること。 82 | 　仮にA、B、Cというステップ（この場合、ABCがそろって初めて1つの意味になるとする）があった場合に自分はA \-\> B \-\> Cの順番でタイピングするが、相手によってはB \-\> C \-\> Aの順番でタイピングをしようと考えているかもしれない。その場合にBをタイピングし始めた時に「Aを書かないとダメだよ」というコミュニケーションは控える方が望ましい。相手のリズムや思考を邪魔してしまう可能性があるからだ。議論・提案・指摘等は、一旦相手のタイピングが一区切りしてから行うことでお互いがスムーズに気持ちよくペアプロを進めることが出来るようになるだろう。 83 | 　ただし、明らかな間違いの場合（例えばアサートファーストを忘れていた）等の場合は早めに指摘する方が良いだろう。 84 | 85 | 86 | ## ドライバーとナビゲーター 87 | 88 | ### キーボードを取り合う 89 | 90 | 　究極的にはタイピングをする人が数秒おきに交互に入れ替わるのが理想だ。この状態はまさに2人のプログラマーが1人のプログラマーかのように振る舞えている可能性が高い。 91 | 　数秒おきというのはお互いの認識共有の具合と技術レベルがかなり高くなければ実現するのは難しいだろう。なので、まずは2〜3分を目安としてタイピングをする人が入れ替わるように意識しよう。この感覚を掴むにはピンポンプログラミングが適している。片方がまずテストケースを書き、書き終わったらタイピングをする人を入れ替えてテストをパスさせる。パスさせたらそのまま次のテストを書き、今度はまたタイピングする人を入れ替えてテストパスさせるといった形だ。 92 | 　その他では相手のプログラミングを指摘するタイミングで、都度指を指したり口で説明をしながらキーボード（タイピング）を取るというものだ。相手に指摘した内容をそのままタイピングしてもらうのは間違っていないし、それによって相手の成長を促す事は可能だろう。しかし一方がタイピングし続けるというのもペアプロによって本来得たい効果を減少させる。そのため、指摘したタイミングでキーボードを取ってみて「こうするんだよ」と見せてあげる。 93 | 94 | ### わからないからこそドライバーになる 95 | 96 | 　自分がやったことがない、知らない作業をする場合は積極的にドライバーになるべきだ。わからない状態でナビゲーターとして傍観するよりも、実際にタイピングしながら進める事で自分自身が本当に理解できていない部分をクリアにする事ができるし、タイピングをすることで理解が深まる速度も上がるだろう。 97 | 98 | ### ディスプレイを指差す 99 | 100 | 　ペアプロ中に相手に何かを伝える場合、ディスプレイを指差してみよう。言葉だけでは伝わりにくくても指を指せばソースコード上のどの部分について話をしようとしているのか明白だ。言葉だけでなく身体も使ったコミュニケーションを取ることで問題解決のスピードは速くなるだろう。 101 | 102 | ### 【キャッチアップ】交代のタイミングを決める 103 | 104 | 　NJはドライバーとナビゲーターを交代するということに不慣れだ。「このテストを書き終わるまで」などの短いゴールを決めてキーボードを譲ったり取ったりする練習をしていく。たとえば「ここまでドライバーをやらせてほしい」「ここからドライバーお願いします」と宣言するのも1つの手だ。ただ、自然にキーボードを取り合えるまでのトレーニングであるということは忘れてはいけない。 105 | 106 | ## ペアチェンジと休憩 107 | 108 | ### ペアチェンジ 109 | 110 | 　3人以上のチームの中でペアプロを行っている場合、チーム内で一日に何回もペアを変えるのが望ましい。 111 | 　ペアの組み合わせを変えていくことで、特定のペアの中だけに閉じてしまう知識をチーム全員に伝播させるのだ。 112 | 　 113 | 114 | ### 定期的に休憩をとる 115 | 116 | 　ペアプロは、集中力やコミュニケーション力を普段以上に発揮する必要があるため、疲労を感じやすい。そのため定期的（目安として60〜90分ごと）に休憩をとってリフレッシュをし、メリハリをつけることが大事だ。 117 | 　休憩のタイミングは、必ずしもペアチェンジのタイミングと合わせる必要はなく、本当に休憩が必要なタイミングで休憩を取るのが良い。 118 | 119 | ### コントローラブル 120 | 121 | 　人は基本的にアンコントローラブルな状況下においてストレスを感じやすい。よって自分達が望むタイミングで休憩を取れるよう心がけよう。休憩を取るまでの目安は60〜90分だが、これはあくまで目安であり、それぞれの体調や集中力の持続具合によって柔軟に変えていくのが良い。また、思うように進まなかったり意見の相違が続く場合は一旦思考をクリアにするためにも休憩を挟むと良いだろう。考え続けるよりもリフレッシュした後の方が良いアイディアが出ることも少なくない。休憩のタイミングを調整することで、チームの抱えている問題を解決できるかも知れない。 122 | 123 | ### ペアチェンジの頻度 124 | 125 | 　ペアチェンジは、60〜90分毎に頻繁に実施するパターンと、1日に2回まで実施するパターンがある。 126 | 　頻繁に実施するパターンのメリットは、各ペア内で知識が閉じる時間を可能な限り短くし、チーム内における知識の循環を促す効果が期待できる。逆に1日に2回のパターン（午前の作業終了時と午後の半ば頃にペアチェンジを行う）においては頻繁なコンテキストスイッチによりキャッチアップに時間がかかり作業の進捗に影響を与える可能性を低くするメリットがある。 127 | 　チームの状況、メンバーのスキルレベルやドメイン知識量に応じて使い分けるのが良い。 128 | 129 | ### タイマーに縛られない 130 | 131 | 　タイマーを使って時間管理をするとアンコントローラブルな状況を生みやすく、どうしてもキリが良いタイミングまでやりたいという気持ちを強制的に押さえさせてしまう。よって理想的にはタイマーを使わない状態にするのが望ましい。キリの良いタイミングを細かく作れるような作業の進め方（TDDのサイクルを短くする等）を身につけよう。結果的にその方が作業全体として柔軟性が高まるはずだ。 132 | 133 | ### 【キャッチアップ】機械的に時間を決めて休憩をとる 134 | 135 | 　ペアプロは集中力を要するので定期的な休憩が必要であり、慣れていないNJの疲労は慣れたメンバーより大きい。慣れたメンバーはつい着手中のタスクのキリのいいところまで進めたくなってしまうが、そこは我慢して、タイマーなどを使って定期的に休憩をとろう。 136 | 137 | ## 調査やスパイク 138 | 139 | ### 長めに時間を取る 140 | 141 | 　ペアチェンジを行ってもスピードを保てる理由は、常にソースコードやテストケース等のアウトプットがあるからだ。ペアの片方が交代しても「このテストをパスさせれば良いんだな」「このテストを書けば良いんだな」というのがわかりやすい。ただし、何かしらの調査やスパイク作業を行っている場合は別だ。調査や試行錯誤をしているため、ソースコードは一行も書いていないかもしれないし、とりあえず書いてみたという程度のソースコードしかないかもしれない。その状態だとそのペアのアウトプットはお互いの頭の中にしかない事が多い。こういう状態で頻繁にペアチェンジを行うと、新しく来たペアに対してそれまでの過程を細かく説明しなければ先に進めない状態になりやすい（例えば「〇〇を試してたけどダメで、△△も試したけど十分ではなかった。✕✕を今から試そうと思うけれどまだそれが良いのかわからない」等） 142 | 　そのためスパイクやR\&Dといった作業ではペアチェンジの間隔を長めに設定し、ある程度のアウトプットが出る時間を確保しよう。ある程度のアウトプットが出ればペアをチェンジして新しい目線を入れる事でより良いスパイク作業が出来るだろう。また、新しい目線を入れたい場合はペアチェンジではなく複数人で進めるモブプログラミングにチャレンジするのも良いだろう。 143 | 144 | ### 調査の仕方を知る 145 | 146 | 　調査を行う際に個々で調べものをするのも手段の一つだが、基本的には一緒に調査をやるのが良い。ペアプロで相手から教えてもらえるスキルとして代表的なのは当然ながら純粋なプログラミングスキルだが、一方でプログラミングスキルと同じくらい相手から教えてもらえる重要なスキルとして調査方法が挙げられる。 147 | 　優秀なプログラマーというのは純粋なプログラミングスキルと同じくらい調査スキルやデバッグスキルも優れている。そしてプログラミングというのは試行錯誤の連続であり、それらのスキルは当然ながら非常に重要だ。 148 | 　ペア間でスキル差を感じている時こそ、相手の調査方法やデバッグの方法を観察し、身につける意識を持とう。そして、調査やデバッグの意図を相手に教えてもらおう。これはペアプロだからこそ得られる絶好の機会だ。 149 | 150 | ## ストーリーへのサインアップ 151 | 152 | ### ペアプロかモブプロか 153 | 154 | 　通常、2人ずつのペアを作り作業するが、時と場合によってはモブプロを行うべきだ。新規の開発で詳細な設計が必要な場合や、不確定な事項が多い調査などは、チーム全員が一堂に会しておこなったほうが効率がよい場合がある。 155 | 　チームメンバーの数が3人や5人など奇数になることもある。2人以上のペアを必ず作らないといけないという先入観にとらわれず、状況に応じて1人作業かモブプロかを選択しよう。今までのストーリーと実装が近く、認識のズレが発生しにくいストーリーや、簡単な調査などは1人作業に適している。 156 | 　固定観念にとらわれず常にチームにとっていま何が最善かを考えて選択しよう。 157 | 158 | ### 【キャッチアップ】複雑でないストーリーで固定する 159 | 160 | 　NJがペアプロを学ぶということに集中できるよう、ストーリーの中身は複雑すぎないものがよい。仮に新規実装から始めるとわからないことが多すぎるので、まず一部のコードを変更するだけでよい追加実装などから始めるなどがよいだろう。 161 | 　また頻繁なコンテキストスイッチもNJにとっては混乱を生む。NJ の担当は同じストーリーで固定し、ペアプロに集中できるようにしよう。 162 | 　NJとペアを組むときは「前の人と言ってることが違ったら教えてください」と伝え、実際にその事象が発生した場合は前の人を呼んで話すのが良い。NJはそのようなことを指摘するのにも心理的ハードルがあるため、既存メンバーがサポートすべきだ。 163 | 164 | ### 【キャッチアップ】 モブプロ \< ペアプロ 165 | 166 | 　ペアプロに不慣れなNJにとってモブプロは情報が多く、キャッチアップしているのに精一杯で観察者になってしまいがちだ。3人以上でのモブプロはせずに2人でのペアプロを徹底するのがよい。2人で行うことになるペアプロは、主体的に考える機会を増やしやすい。 167 | 168 | ### 【キャッチアップ】業務中に一人で作業・調査する時間を設ける 169 | 170 | 　NJは今までと異なる状況もあり必然的にいろんな新しいモノ(技術/概念/考え方)などに触れることになる。その中で疑問に思い深く調べたい(知りたい)こともある。これを自分で明らかにする時間があれば、ペアプロ中では感じられなかった自分の成長を感じる機会になるだろう。 171 | 　例えば一日のうち夕方に15分くらい考えを整理する時間を設けるといったことは有効に作用する場合がある。 172 | 173 | ## 環境 174 | 175 | ### 小さいホワイトボード 176 | 177 | 　コミュニケーションをより円滑にするために小さなホワイトボードを用意しよう。テキストより会話、会話より対話、対話より対話とホワイトボードの組み合わせがよりコミュニケーションの濃度が上がる。A3サイズほどのホワイトボードを置いておき、図や簡易なクラス図等を書きながら議論をしよう。視覚的な情報も含めたコミュニケーションをすることで飛躍的に強度の高い意思疎通を図ることができるようになる。 178 | 　ホワイトボードに書いた情報であればスマホで写真を撮って保存したり、コピー機でコピーして手元に置いておくのも簡単だ。 179 | 180 | ### 大きいホワイトボード 181 | 182 | 　大きなホワイトボードを使ってチームの状況を「見える化」しよう。ストーリーの進捗状況を表したカンバンにしたり、チーム内での課題・ふりかえりで出たアクションを貼ったり、全員に伝えたい or 残しておきたい重要な図を書いたり様々な情報を大きなホワイトボードに書き出そう。 183 | 　大事なことは「目線を動かせばチームにとって大事な情報がパッと目に入る」状況を作り出すことで、その目的のための最適なオフラインツールは大きなホワイトボードだ。だからこそ、この大きなホワイトボードは作業しているチームのすぐそばに置いておこう。 184 | 185 | ### 背中合わせの配置 186 | 187 | 　チームの座席の配置もコミュニケーションを円滑にする上で非常に重要だ。ディスプレイやモニター越しにチームメイトが座っている状態だと現在画面に表示されているエラー画面を見せるにもひと手間かかるはずだ。相手にぐるっと周ってきてもらったり、ディスプレイを180度回したり、ノートPCを持って相手の所にいったり、というような事が必要になってしまう。 188 | 　コミュニケーションを円滑にし、活発にするためには「コミュニケーションしやすい状況をつくる」という考えが非常に重要だ。だからこそ同じチームは背中合わせの状態で座るようにしよう。椅子を回転させればすぐに質問できるし、もう一方のペアの画面も見やすいだろう。背中合わせのメンバー全員が椅子を回転させて向かい合えば即席のMTGもすぐに可能だ。 189 | 190 | ### エチケット 191 | 192 | 　ペアプロではペアチェンジを頻繁に行う。実施する環境にもよるが、同じキーボードや机・椅子を様々な人が交代して使うことになる。よって他の人が不快に感じることがないように作業する机を綺麗に保つ事は重要だ。誰しもが汚い場所よりも綺麗な場所で仕事をしたいと思うだろう。食べかすやゴミなどが机の上に散乱したままにならないように気をつけよう。これも1つのリスペクトとも言えるはずだ。 193 | 194 | ### ペアプロしやすい机 195 | 196 | 　ペアプロでは2人が同じ画面を見ることになる。なのでそれぞれが座る場所の間にキャビネットや机の大きな足などがあると無駄にスペースを空けなければならなくなり自然なコミュニケーションの妨げになってしまう。もし机の下にキャビネット等がある場合は別の場所に移す事を検討しよう。 197 | 198 | ### ディスプレイ 199 | 200 | 　大きなサイズのディスプレイを用意しよう。ものすごく大きなディスプレイ1つ（例えば40インチ以上）でやるのも良いが、30インチ前後のディスプレイ2つの方がより快適に作業が出来るだろう。多くの情報をペア間で見える状態にしておき、お互いがディスプレイを指さしながら議論が出来れば生産性は向上するはずだ。 201 | 　1 台の PC を 2 人で使うこともあれば、お互いが別々の PC を持ち寄って作業する場合もあるだろう。別々の PC を使う場合でも、それぞれの PC に外部ディスプレイをつなぎ、2人の間に並べて置くことで、お互いに相手の画面が見られるようにするべきだ。それぞれが別々の画面を見てペアプロをするというのはペアプロの効果を最大限発揮できないだろう。 202 | 203 | ### キーボードとマウス 204 | 205 | 　1 台の PC を 2 人で使う場合は、キーボードとマウスはそれぞれ2つ用意しよう。1つであったとしても当然作業は可能だが、物理的にキーボードを取ってドライバーを交代するというのは心理的障壁が高い。自然な形でドライバーになれるようにキーボードとマウスはそれぞれの手元に置いておくのが望ましい。 206 | 207 | ## \-オンライン編- 208 | 209 | ## コミュニケーション 210 | 211 | ### 会話の量を増やす 212 | 213 | 　オンラインではその場にパートナーがいないため、身振り手振りやその場の空気感などの非言語コミュニケーションによって伝わる情報量がオフラインよりも少なくなる。オフラインであればうなずきで応えるような場面でも声に出して相槌を打つなど、会話を通して互いの情報を伝え合おう。 214 | 215 | ### マイクを取りにいく 216 | 217 | 　声がかぶることを過剰に恐れて、相手の発言や沈黙が訪れるタイミングを待つのはやめよう。キーボードを取りにいくのと同じように、マイクも積極的に取りにいく。相手の発言は傾聴しつつも、その場にいる全員がオーナーシップを持って発言し、議論や作業をリードしていこう。 218 | 219 | ### 不意に沈黙する時間をつくらない 220 | 221 | 　オンラインでは何かを理解できずに混乱していたり、静かに考えていたりしている状況が相手に伝わりづらい。沈黙によって何かを伝えたり、沈黙から何かを察したりするのではなく、言葉によって互いの考えや景色を伝え、引き出し合おう。もし静かに考えたいときは、合意をとって明示的に沈黙の時間をつくると良いだろう。 222 | 223 | ### 遠慮せずに話しかける 224 | 225 | 　他のペアやチームと話をするときに、必要以上に様子を伺ってタイミングを見計らう必要はない。オンラインでは他の会話空間の状況がわかりにくいため、勇気と信頼を持ってまずは声をかけてみよう。きっと快く対応してくれるだろう。 226 | 227 | ### Face To Face 228 | 229 | 　オンラインであっても相手の顔や動作を注意深く観察しよう。声の調子、表情、しぐさ、態度などから得られる情報量は、文字や言葉だけよりも圧倒的に多く、円滑なコミュニケーションを助けてくれる。 230 | 231 | ## オフラインのような作業空間 232 | 233 | ### カメラを ON にする 234 | 235 | 　ペアプロ中や ミーティング中は、みんながお互いの顔を見ながら話せるように常にカメラを ON にしよう。ただし、中には「自分の顔を見続けるのが苦手だ」という人もいる。その場合は使用しているビデオチャットツールにセルフビューを非表示にする機能があるか調べてみよう。 236 | 237 | ### 視界を共有する 238 | 239 | 　ペアプロは、パートナーと同じ関心事、すなわち同じコードに向き合い続けることによって、足りない視点を補い合えるという価値を我々に提供してくれる。リモートペアプロツールを使用すると、ペアの二人がそれぞれ別のコードを書くことが可能になるが、だからといって二人の関心が別の方向を向いていては、ペアプロのよさを享受できない。ナビゲーターが、ドライバーが今まさに書いているコード以外の何かに気づくことはあっても、そこに手を入れるのは二人で一緒に行うべきだ。テキストチャットの文面を考える際も、画面共有機能で自分のローカルマシンを相手に見せて一緒に考えよう。またリモートペアプロツールのカーソルフォロー機能を使うと、オフラインで画面を指さして「ここの部分が…」と話すのに似た体験を得られる。パートナーと視界を共有するためにやれそうなことは積極的に試してみよう。 240 | 241 | ### 周りの声が自然と耳に入るようにする 242 | 243 | 　オフィスでの仕事中、なんとなく聞こえる周囲の会話から「あのペアが苦戦してそうだから声をかけてみよう」「あの人はデータ設計の話をリードしていたから今度困ったら相談してみよう」と考えた経験はないだろうか？自然に耳に入る周囲の会話は、実は多くの情報を与えてくれている。オンラインペアプロでもその利点を活かせるよう、使用しているツールに「パートナー以外の会話も聞こえるようにする機能」があるなら積極的に利用しよう(たとえば Gather.Town のバブル機能などがそれにあたる)。また、3 人チームで 2 人と 1 人に分かれて作業する際は 3 人とも同じビデオチャットスペースに入るようにすると、オフラインで同席しているかのようにスムーズな質問や共有が可能になる。ただし「他のペアの声が聞こえると自分の作業に集中できない」という人もいるので、都度相談してチームにとって最もよい選択肢を選ぼう。 244 | 245 | ### さっと可視化して伝える 246 | 247 | 　オフラインだと眼の前のディスプレイを指さしながら話すような場面でも、オンラインだと口頭でのコミュニケーションが中心になるため、少し前に話していたことが流れてしまい今の議題が分からなくなってしまうことがある。その結果、議論の前提を見失ったり少しずつ会話が噛み合わなくなったりするため、議論が空中戦になりやすい。それを防ぐため、積極的に頭の中を視覚化しよう。オフラインの時にホワイトボードに手を伸ばす気軽さで、オンラインホワイトボードツールに図を書いたりスプレッドシートに表を書いたりしよう。付箋に書いて整理するだけでも、お互いの考えはずっと伝わりやすくなる。 248 | 249 | ### 【キャッチアップ】NJがホストする 250 | 251 | 　リモートペアプロツールを使ったペアプロではホストとゲストという立場が生まれる。ツールによってはホスト側にしか許可されていない操作などがあり、 ホストのほうが心理的ハードルが低くキーボードを取りやすいので、より主体的にペアプロができる。NJがホストするということは、ホストするための環境構築も必要になり、キャッチアップを兼ねて行うことができるため理解が進みやすい。 252 | 253 | ## 環境を整える 254 | 255 | ### 通話品質を確保する 256 | 257 | 　オンラインでの会話において通話品質は重要だ。ノートパソコンに付属しているマイクとスピーカーをそのまま使用すると、スピーカーから出た相手の声をマイクが拾って二重に聞こえてしまったり、話者の声に周囲の雑音が混じってノイズだらけの音声になってしまうことが多い。こういった事態を防ぎ円滑なコミュニケーションを実現するために、ヘッドセットやマイク付きイヤホンを利用しよう。具体的には「単一指向性 (話者の音声を拾いやすく、別方向からの音を拾いにくい)」のマイクを選ぶとよい。 258 | 　 259 | 260 | ### 通信環境を整備する 261 | 262 | 　これまで触れてきた通り、オンラインでのスムーズなペアプロには Face To Face のコミュニケーションが重要だ。そのため、通信環境は常時カメラ ON でビデオチャットをすることに耐えられるレベルが望ましい。 263 | 264 | ### 身体への負担を考慮する 265 | 266 | 　オンラインでは ミーティングのための場所移動などもないため、長時間座りっぱなしで PC に向かうことになりがちだ。椅子や机、モニターやキーボードの位置・設定などを調整し、少しでも身体への負担を軽減できるようにしよう。 267 | 268 | ### 他者への配慮を忘れない 269 | 270 | 　本項「環境を整える」で書いた話は、どれもオンラインでのよりよいペアプロのために重要だ。だが、人はそれぞれ違った環境で生活していることを忘れてはならない。可能な範囲で理想を追求しつつも、さまざまな事情があってそれができない人にもきちんと配慮しよう。間違っても理想の環境を用意できない仲間を責めたりしてはならない。 271 | 272 | ## 余白をもたせる 273 | 274 | ### 休憩中に個人タスクをやらない 275 | 276 | 　オンラインの場合、チームで休憩を取っていても個人で作業を継続することが容易にできてしまう。休憩時間中はストレッチをしたり、目を閉じたりして頭と身体を休めることに集中することが大切だ。個人でタスクにとりかかりたいときは、チームの作業時間の中で「少し個人の時間をください」と声かけをして、時間を確保しよう。 277 | 278 | ### 雑談をする 279 | 280 | 　雑談は心理的安全性を高めるための最初の一歩になる。作業のみに集中してしまいがちなオンラインだからこそ、ランチやコーヒーブレイク、ペアプロ中のちょっとした合間などで意識的に雑談をしよう。 281 | 282 | ### 小さな喜びを分かち合う 283 | 284 | 　オンラインでは、オフラインと比較してコミュニケーションの量が少なく、業務上必要なやりとり(情報共有や課題解決に向けた相談、指摘など)に閉じてしまう傾向がある。しかし人の脳は、成功や喜びに焦点を当てることで効率的、創造的に働く。テストをパスした時、議論が前に進んだ時、失敗によって何かを学んだ時など、小さな成果でも相手が隣にいるかのように気軽に祝福し、自分たち自身で成功を認め、喜びを共感し合おう。 --------------------------------------------------------------------------------