2009年7月14日火曜日

会社でレビューについて話し合い

先日、ソフトウェア・インスペクション・ワークショップ 2009に参加したのですが、資料がUpされていました。

ソフトウェアインスペクション/コードレビューを成功させる方法(前編)
ソフトウェアインスペクション/コードレビューを成功させる方法(後編)
当日行なった技法や観点など

また、このワークショップとは別ですが、研究のためにコードレビュー オンライン ハンズオンの協力者を募集しているようです。

当日は、何かを学んで来た...という感覚はあまり得られなかったのですが、考えてみるいいきっかけになりました。
んで、このセミナーの後に、会社のメンバーと共にレビューについて考えてみよう! という機会を設けて、今日は第二回をやってきました。

レビューの目的って、知識や技術の差(属人性)を埋めるため というのも1つの大きな目的だと思うのですが、その目的からも分かるように、プロジェクト規模や、携わる人間の数/お互いのレベルの認識度 によって変わります。
ヌーラボ@東京は、社員数も片手ぐらいだし、現在新卒採用の人はいない という状態なので、このメンバーでやるとしたら、どんなものがいいのだろう? という話を今日はしてきました。

みんなの意見も聞きつつの感想としては、小規模なメンバーだからこそ抱える不安/心配があるよなーと。

小規模案件 = 携わる人が少ない(1人の時もある)
だと...
ある特定の人のみしか仕様を知らないって事も当然増える。
案件の立ち上がりの時期はペアプロを...という話をした人もそこそこいたんですが、それって結構、同じ知識(要件や今の状態)を共有してる前提で、気軽に相談し合える人が欲しいって事なんだろーなって思いました。

「気軽に相談出来る人」というのが語弊があるかもしれないけど...
同じプロジェクトにいる人ならば、損益はお互い共通しているのでまぁいいんですが、違うプロジェクトにいる人の場合、
"すいませんが、相談のって下さい.."
"いいよ (...でもその分、自分の仕事は残業かな..)"
なんて感じがすると、気を使いますよね。

ワークショップでは、相談乗ってあげる、レビューをしてあげる 事についても、評価を設けるべきだ という話がでてきてはいましたが...作業を日毎に割り当ててスケジュールたてている時点で、なんかもぅ違う。
レビュー選任者を作って、"その人の仕事の30%はレビュー時間に割くように決める" とかも大規模なプロジェクトではありかな。
んが、5人程度のメンバーならば、もっと違う取り組みができるはず。。

まぁ、そんな事を考えていたら、以前、旦那と一緒に仕事してた時はやりやすかったなぁー。と思い出した。

なぜかって...
お互いの得意/不得意を把握してたし、気軽にタスクを交換できる(してもいい相手だと知っている)、こんな事で困ってさぁーって雑談できる時間も多かった。

その結果...

「ここの部分は引き受けるから、変わりにここの部分やってよー」
とか、
「コレには興味あるよなー。んじゃ、このタスク私の方で持つから、調査してみてよ。んで結果教えて!」
とかやってた。

2人で分担できるようになると、「あそこのプロジェクト大変やから、1日徹夜で手伝ったるか!」なんて事も1人の時よりしやすくなった気もする。

周りからも、たとえ一緒にやっていない仕様であっても...2人のどちらかに聞けば分かるんじゃない? と多分思われていたと思う。

なんか、少人数でやっていく会社にとってみても、いい方向性突いてたんじゃないかって気もするな。
• • •