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