歩いたら休め

なんでこんな模様をしているのですか?

【本】仕様化やレビューについて勉強しています

最近、2つ理由からレビューの仕方や、仕様化のプロセスについて勉強しています。

  1. 自分自身がプログラムを書いている間、ドメイン知識が足りず、手が止まっている時間や周囲に確認することが多い。
  2. (半ば非公式に)分析用のRプログラムのコードをレビューするようになったが、「どうすればお互い勉強できるレビューができるか」に困っている。

1つ目について話すと、私はWEBマーケッター向けの社内ツールを作成しているのですが、 マーケッター側の企画者のまとめた「仕様」を理解できておらず、 「全データを使うめちゃめちゃ時間がかかるので、ここのチェック変えても大丈夫ですか? あ、変えちゃダメなんですね。…じゃあなんとか別の方法を考えてみます」 みたいな細かい手戻りも多いように感じています。

2つ目は、分析者(いわゆるデータサイエンティストと呼ばれるような立場)の人のコードをレビューするようになったということ。 分析者は、コードを書くことが専門ではないため、定期分析用のコードが必要以上に煩雑で扱いづらいものになってしまっていました。 そのため、先輩からの引き継ぎやモデルの改良に異様に時間がかかってしまっていました(と傍から感じていました)。

開発ではレビューが行われていたものの、 分析サイドでは「自分のやった分析を、一生自分で面倒見なければならない」みたいな風潮になってしまっていて、 分析者の立場では「優秀な人ががんばればがんばるほど自由に動けなくなる」という闇のスパイラルに入る傾向にあったように思います。

また、「レビュー=品質の悪いコードを外に出さないためのチェック」という役割が強くなってしまっているように感じていて、 「この機能を実現するのにAPIとして機能を切り出す場合と切り出さない場合の2つ選択肢があるんだけど、 どっちが総合的に楽なんだっけ?」と悩むような場合に、 相談とかレビューというか、そういう役割のものが欲しいと思っていたこともあります。

チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。 · GitHub

というわけで、こちらの記事で紹介されている本2冊を読んでみています。どちらの本も、上のような悩みにフィットするものだったので、 もうちょっとうまく開発フローを回せるようになったら文章でまとめてみようと思います。

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

ピアレビュー

ピアレビュー