skillup

技術ブログ

ドキュメント作成 プロジェクト管理

レビューについて

投稿日:2022年8月31日 更新日:

以前、コードレビューそのもののポイントについてはコードレビュー時のポイントでまとめましたが、レビュー自体の体制の注意点やそこでの気づきなど。

目的

基本ルールに則っているかどうかを見るといった初歩的な意味もありますが、人間の思考の漏れを検証するといった意味あいが強いため、多人数で行わないとそもそもの意味がない・・・と思います。

定型的なものはチェックリストを

これについてのなるべく頭を使わずに自動ではじける仕組みが大切。

  • ドキュメントの体裁→チェックリストやなるべく標準のテンプレート、標準の修正機能で防げるようにしたい
  • 規約的なものは例えば規約ツールで自動ではじくなど

このレベルで毎回指摘する、指摘事項が変わる。。。などがないようにしたい。

レビュアーの負担軽減

  • 仕様が複雑だったり、粒度が大きいものは対面でまずざっくりとレビュイーが説明をし、改善点に関しては回覧レビュー(メッセージのやり取りだけ)を行う
  • 当事者意識を持たせるために、レビュアーにノルマを付与するといいかも(一回のレビューの際に必ず何らかの指摘事項をもうけるなど・・)
  • リマインダーなどで自分の分を告知する仕組みが必要かも(Slackへの告知など)
  • 参加する際の前提知識やそもそもの仕様の共有が最も大切
  • そもそもの人間関係を壊さないような文化づくり(根本的にある信頼関係の構築)が最も大切
  • 神学論争的なものは最終決定権のある人間に決めてもらう(当人同士で争わないように)

レビューポイントについて

  • 見るポイントを各人で担当制にする(仕様的な部分、コードの設計的な部分)
  • できればファイルなどを細かく分割して、小分けにする
  • 必ずなおす、直してほしい、できたら、のようにウェートをつける
    (理想論でいえば全て直してほしいが、そのタスクがブロックになってしまい、後続タスクへの影響などをなくすため。できたら・・などは別タスクとして別途レビューをする)
  • 指摘事項で多いもののリストアップ→なるべく他のメンバーでもレビューをできるようにする、見れるようにするため
  • 余裕があればレビューの指摘事項で上がっているものの類型化など

-ドキュメント作成, プロジェクト管理

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

テスト環境のデータ作りに関して

単体テスト以降の環境ですとテストのデータを作ることがなかなか大変だと思います。マスタなどはそのままもらうこともあると思いますので、主にトランザクションデータについて。 以前もこのネタに関しては色々書い …

no image

読書感想文:世界最高水準の採用セオリー

今まで何冊か採用の本を読みまして、人の行動を予測するのは基本的には「過去の行動」に焦点をあてることがベストというのがほぼ共通項ですが、今回紹介する「世界最高水準の採用セオリー」もこの行動面接をシステマ …

no image

アジャイル開発について

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・ が、先日 …

no image

テスト分類について

一般的なテスト工程での分類や個人的に大事だと思うこと Contents1 全プロセス共通1.1 テストデータ作成バッチ1.2 ローカル、開発、ステージング、本番の分岐2 PT(プログラムテスト)、単体 …

no image

設計業務での改善点など

比較的大規模なプロジェクトの設計段階で思ったことなど。会議など頻繁に開かれると思いますが、聞いているだけだったり、各人が色々なことを喋って内容がまとまっていなかったり・・結局何をやりたいかわからなくな …

アーカイブ