Amazonアソシエイト・プログラムの参加者です。昨日は瀬宮新さんの「始まらなかったアジャイルを一人でもう一度始めようとした話」でした。去年のDevLOVEアドベントカレンダーでは「仕事とプライベートがウェットってブラックなの?」でその年のDevLOVEブログで最も読まれた記事、に選ばれましたので、今年も頑張って書こうと思います。先日、第9回RxTStudyで、チームにおけるgitの失敗事例と、その改善までのお話をさせていただきました。(そのときのスライド)僕たちのチームでは、結成当初からgitを使ってソースコードのバージョン管理を行っています。導入当初はメンバー全員がほぼgitを扱うのが初めて、という状態で、幾度と無くトラブルにも見舞われました。運用を安定化させるために、チームではいろいろな試みがなされました。様々なGUIツールを試したり、ブランチ戦略を検討したり。そのような中で、最も効果が高かったのは、『入門Git』などを読んで「正しい知識を身につける」ということでした。僕はRxTStudyでの講演を、「ツールを使いこなすには、まずは正しい知識をきちんと学ぼう」という結論で締めくくりました。講演後、ある方から質問をいただきました。「正しい知識、というキーワードがお話の中で何度も出てきましたが、正しさの定義とはどのようにお考えですか?」なるほど。これは辛辣な質問です。僕は「正しさの定義」はそれぞれのチームや現場によって異なると考えています。この時にいただいた質問でも、そのような主旨の事を回答しましたが、それをもう少し具体的に書いてみよう、というのがこのエントリのテーマです。「gitの使い方」というような場合における「正しさ」の定義は簡単です。そのツールの仕様が、正しさの前提だからです。チームでコードレビューなどをする場合における「正しさ」はどうでしょう。「正しいソースコード」などと言われても実に曖昧で、正解などないような気がします。僕はこういう曖昧なものに正解を求める必要があった場合、「チームメンバー全員が合意する」という事を軸に考えます。コードレビューにおける「正しさ」は、最終的にチームメンバー全員が「それで良い」と判断すれば、それが「正しいコードである」とみなします。ペアプログラミングでのプログラマ同士の議論、あるいはチーム全体でのレビュー。いった、度重なる議論を経て、僕たちが書いたソースコードは最終的にプロダクトとして世に放たれます。チーム全員の合意を「正しさ」の定義に据えるのが、最もわかりやすい考え方ではないでしょうか。■「チームメンバーの合意」が間違っていることもある・・・しかしこの考え方には危うさがあります。ここである架空の現場を想像してみましょう。彼らは仕様書をExcelで書いており、それを以下のように管理していました。・認証システム設計書_20131208.xls・最新版_認証システム設計書.xls・最新版_認証システム設計書_bkup.xlsチーム全員が合意の上で、彼らはこのような管理をしているわけですが、これは本当に「正しい」と言えるでしょうか?現場における正しさの定義には、「チームメンバーの合意」に、もう一つ付け加える必要がありそうです。■正しさとは、「チームメンバーが合意」しており「困っていないこと」メンバーが合意した方法や考え方であっても、チームとしてその運用が困難であったり、なにか問題がある場合、それは正しいとは言えないでしょう。さきほどの設計書の例で言えば、メンバーの合意があっても、結局本当の最新版はどれか、という問題が生じてしまうのであれば、それは正しいとはいえません。チームにおける「正しさ」とは、チームメンバーが合意しており、その運用において解決すべき問題が無い状態が望ましいです。いう正しさの定義は、チームの成熟度によって当然変化します。今まで問題とされていなかったような事柄が、チームの成長にしたがって問題として顕在化することもあります。その場合はチームが成長して「正しさの定義」に変化があったということですから、その問題と向き合って新しい「正しさ」を見つければよいだけのことです。僕たちは個人ではなく、チームで仕事をしています。あるならば、その中で生じるいろいろな事柄はチームとして定義されるべきです。僕からは以上になります。明日は@shinyorkeさんです。【29日目】「現場における正しさとは」いろふインスタンスの最大数を探る。(9)自己紹介daiksy2012年2月から京都でお仕事。時々勉強会に出没したり、Twitterでバカなことをつぶやいたり、どこかで真面目なコラムを書いたりしています。つぶやきを覗きみたい方は「@daiksy」へどうぞ。