まとめ
メニューを開く-
「レビューしてください！」ドン！じゃなくて、「少し書いたんでレビューしてください！」を何度か繰り返す方が結果的に良いものができると思うなぁ。どちらにとっても精神衛生上良いと思うし。 -
例えば最初に1ブロックを書いて、方向性や粒度がイメージと合っているかをレビューする。この時内容の正誤やてにをは、はとりあえず置いておく。ついでに他のメンバーも同席していればその人達にもとっても指針を示せて尚良かなぁと。
-
大量のソースコードやドキュメントを一気に見ても良いレビューはできないと思う。集中力切れるし。
-
それにレビューアは忙しい人も多いのでまとまった時間を調整するのも大変だし、急な電話や用事で中断されたりする。 でも毎日15～30分サクッとみるだけならできるんじゃないかと。
-
書き手も早期に、完璧な正解でないにしてもそれなりに的はずれでないことが分かるのは、気持ち的に楽かと。この辺テストコードがある状態でのプログラムに似ているかも。
-
ちょくちょくレビューする場合、最後は通しでしないと、全体の整合性や矛盾をつぶしきれない。それでも着眼点はハッキリしているので楽だと思う。
-
ウォーターフォールは、完成確認までの期間にかけるコストが最大のリスク。漸近的に確認中すれば、そのリスクは下がる。ただし、ソフトウェアの場合は、動かないと本当の価値の確認にならないことに気付いた人たちがいて、動くソフトウェアで確認していくためのやりかたをアジャイルと呼んでいる。 -
ソフトウェアに限らず、作成者と受入者の間で、少しずつ確認を繰り返していくことで、一度に完成させることを目指すよりも効率的。問題は、そのコミュニケーションコスト。郵便しかなかった時代はなるべくそのコストを下げるべく、一発百中を目指した。メールによって、そのコストは大きく下がった。
-
今の時代、メールですらまだ一括処理的に思える。IT用語ならバッチ的。例えば提案の長文メールは、書く方にとって負担だし、受けた方も負担が大きい。すり合わせたら、うまく着地出来るかもしれないのに。もっとコラボレーションに向いたやり方があるはずだと考えたのが、 youRoom だった。
-
Content from Twitter
コメント