チームでレビューをしていると、なぜかレビューの日だけぐったり疲れてしまう。そんな経験、ありませんか。
私自身、チームリーダーとしてレビュー業務を担当してきましたが、正直「レビューが一番消耗する仕事だ」と感じることが何度もありました。コードを書くよりも、テストをするよりも、なぜかレビューが一番しんどい。
今日は、そんな仕様書レビューの疲れの正体と、少しでもラクにするための対策を、私の経験談を交えながらお伝えしていきます。
【結論】仕様書レビューに疲れるのは、あなたのせいではありません
仕様書レビューに疲れるのは、あなたの経験やスキルが足りないからではありません。
前提知識の共有不足、観点の不安、表記ゆれの指摘、大量の分量、伝え方への配慮、差分の見えにくさ、再レビューの繰り返し…
こうした要因がいくつも重なることで、レビューという作業そのものが消耗しやすい構造になっているんです。
まずは原因を知ることから始めてみましょう。
私もチームリーダーとして仕様書のレビューを何度もしてきましたが、レビューをするたびに疲れてしまうことがありました。
レビューがうまくいかない自分に腹が立ち、うまくできないのは自分のせいだと思ったこともありました。
しかし、レビューに疲れない方法、そして疲れるよりも楽にする方法を、レビューを通して学びました。そのことについて共有したいと思います。
そもそもレビューする機能の前提知識があまりない
私もよく感じることですが、レビューする機能の前提知識があまりないと、レビューする観点もつかめず、しっかりとレビューをすることができません。
「機能についてわからないから、適当にレビューしよう….」
レビューする機能について、前提知識がないとそもそもレビューをする意味もないです。品質の向上も見込めません。
まずはレビューする前に、機能の前提知識などを担当者とすり合わせることが必要です。
テキストでのやり取りだと限界もあるし、やり取りに時間がかかるので、会話しながら前提条件などをすり合わせるといいでしょう。
特に私はチームリーダーをしていましたが、ミーティングの合間にレビューしたりするので、時間があまり取れませんでした。そのため、時間がないときは担当者を呼んで会話しながらレビューをしていることもありました。
レビュー観点が網羅できているのか不安になる
私もよく感じることですが、「この機能のレビューは足りているのか」「漏れている観点はないか」と不安になることがあります。
設計書や単体テストのレビューにおいて、実装やテストを実施する前までにある程度レビューができていれば、後々直す必要もありません。ましてやレビューが漏れていたりすると、リリース後に問題が発覚することもあるでしょう。
そうなった場合、リリース後にお客様からお問い合わせをいただいたり、対応が後手後手になってしまったりするので、レビュー観点の網羅・漏れをなくすことが必要です。
まずは、レビューするときに自分の中でルールを持ちましょう。
例えば、私ならこんな感じで自分のルールを決めてレビューしています。
例えば、値を保存する処理をレビューするときは、次の3つの観点で必ずチェックするようにしています。
1つ目は正常系です。
任意の有効な値が入力されたときに、想定どおりの処理が行われるかを確認します。ここは比較的イメージしやすい観点でしょう。
2つ目は準正常系です。
0、NULL、空文字、マイナス値、境界値(100の境界値は99・100・101です)などを指します。
エラーとまではいかないものの、扱いを誤るとバグにつながりやすい値なので、これらの観点が漏れていないかを重点的に見るようにしています。私の経験上、指摘が漏れやすいのはだいたいこの準正常系です。
3つ目は異常系です。
想定外の異常な値が入力された場合に、システムとしてどう振る舞うかを確認します。
このように観点をあらかじめ型として持っておくと、担当者と前提知識をすり合わせる際にも「正常系はここ、準正常系はここまで考えていますか」といった形で会話がしやすくなります。
感覚に頼らず、自分なりのチェックリストを持っておくこと。これが、レビュー観点への不安を減らす一番の近道だと感じています。
表記揺れや誤字脱字の指摘が面倒
仕様書の中身とは関係のない、表記揺れや誤字脱字の指摘が地味に疲れるという方も多いのではないでしょうか？
本質的な設計の話をしたいのに、
「ここは全角と半角が混ざっています」
「この用語、別のページでは違う書き方になっています」
といった指摘に時間を取られてしまう。私も過去に、1つの仕様書で表記揺れの指摘だけで疲れてしまったことがありました。
こうした指摘は重要ではあるものの、人間がやるには割に合わない作業だと感じます。
表記揺れがある時は、指摘する際は「表記確認」のように事前に文言を決めておき、表記揺れの指摘に時間をかけないようにしておきましょう。
一度に大量の仕様書をレビューに出されて集中力がもたない
私もチームリーダーをしていたとき、担当者から「まとめて見てほしい」と大量の仕様書を渡され、正直後半は集中力が切れてしまっていたと感じることがありました。
理想を言えば、機能単位・区切りのいいタイミングで小分けにレビューを依頼してもらう方が、指摘の精度は上がるでしょう。
依頼する側とされる側で、レビューの出し方についてもすり合わせておくといいかもしれません。
レビューするコメントのニュアンスに気を使う
指摘の中身そのものよりも、伝え方に神経を使ってしまう。
これも仕様書レビューが疲れる大きな理由の一つだと思います。
きつい言い方になっていないか、担当者のモチベーションを下げていないか。
私も過去に、指摘コメントを何度も書き直してから送ったことが何度もあります。
技術的な指摘は明確に出したい一方で、人間関係への配慮も欠かせないです。このバランスを取り続けるのは、想像以上に神経を使う作業です。
指摘の際は「事実」と「提案」を分けて書く、語尾をやわらかくする、といった自分なりのテンプレートを持っておくと、毎回ゼロから言葉を選ぶ負担が減るはずです。
私がチームリーダーをしていたときは、テキストだけだと冷たい印象を与えてしまうので、先に会話してから指摘する、または指摘した後に「こういう意図で指摘した」というように、意図が伝わるように会話を挟むことで、チームメンバーにもより理解を深めてもらうことを意識しました。
仕様書の変更履歴や差分が分からない
前回レビューした箇所から、どこがどう変わったのかがわからない。これもレビューが地味にしんどくなる理由の一つでしょう。
差分が明確になっていないと、結局全体を読み直すことになり、二度手間になってしまいます。
私も、変更履歴が書かれていない仕様書を渡されて、前のバージョンと突き合わせながら差分を探した経験があります。
変更履歴欄を用意してもらう、もしくはバージョン管理ツールで差分を可視化してもらうよう、事前にルール化しておくと、レビューの負担はかなり軽くなるはずです。
私の経験談でいうと下記のようなルールを事前に決めておくといいと思います。
追加する場合は、赤字で記載する。
削除する場合は、取り消し線を引いて薄いグレー文字にする。
修正する場合は、青色やピンク文字にする。
一度の指摘で直らず、何度も再レビューが発生する
指摘したはずなのに、修正版を見るとまた同じような指摘をすることになる。
こうした再レビューの繰り返しに疲れてしまうこともあるでしょう。
私も、3回、4回と同じ観点の指摘を繰り返した経験があります。
指摘した側としては「前にも言ったのに」という気持ちになりますし、修正する側も「また指摘された」と疲弊してしまう。悪循環になりやすいポイントです。
指摘した内容が正しく伝わっているか、修正後に簡単な認識合わせの時間を取ることで、再レビューの回数を減らせるはずです。
文章だけでのやり取りに頼りすぎず、必要なところは会話で補うのがポイントだと思います。
まとめ
仕様書レビューが疲れるのは、決してあなたのスキルが足りないからではありません。
前提知識のすり合わせ不足、レビュー観点への不安、表記揺れの指摘、大量の分量、伝え方への配慮、差分の見えにくさ、そして再レビューの繰り返し。
こうした要因が積み重なって、レビューという作業を消耗させているのです。
まずは今日から、担当者との前提知識のすり合わせを一言増やしてみる。それだけでも、次のレビューの疲れ方は変わってくるはずです。
コメント