skillup

技術ブログ

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

レビューについて

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

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

目的

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

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

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

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

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

レビュアーの負担軽減

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

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

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

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

執筆者:


comment

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

関連記事

no image

障害報告などでの伝える情報の視点

障害の重要度(後続タスクにブロックがあるかいなか)、調査原因(仕様不理解、設計考慮もれ、ケアレスミス)、影響度(画面単位などで) 障害が起こっているデータ(あるいはスクショなどで伝えられるか) 再現プ …

no image

タスク管理・情報管理で必要なこと

いままでもタスク管理などでいろいろかいてきましたが、今のプロジェクトで思っていることなどを箇条書きで。 Contents1 情報のもれ、ダブり2 完了地点の明確化3 ストック型とフロー型の情報のまとめ …

no image

カバレッジの計測

テストがどの程度徹底されているかを見る指標としてはカバレッジが代表的だと思います。 PHPUnitなどでもこれらはだせるのですが、codecovなどのサービスをつかうとPRごとなどさらに細かい視点でコ …

no image

プロジェクトマネジメントについて

以前、主に座学で勉強したことをベースにプロジェクトマネジメントについて で書いたのですが、ここ2年ぐらい比較的大きめのプロジェクトを色々と経験させてもらったのでそこで得たことなどを。 Contents …

no image

KPT法について

プロジェクトを進めていく上では、いいこと、悪いこと様々あるかと思いますが、 よかったものは続け(Keep)、 問題点に関しては直視し(Problem)、 改善を試みる(Try) のが良いかと思います。 …

アーカイブ