どうもしんざきです。今仕事が割と追い込みで、久々に軽いデスマに片足を突っ込んでおり、連絡待ち時間と現実逃避にこの記事を書いています。

夜景がいつもより綺麗に見えてくるとそろそろヤバいかなって思いますよね。

 

ということで、すいません、ちょっと細かい話をさせてください。

皆さん、自分の成果物に対して、「特に意味があると思えない細かいダメ出し」を上司にされた経験ってありますか？

 

言うまでもなく、報連相というものは色んな意味で重要であって、成果物のレビューというものの重要性もそれに準じます。

何かを作った時は、自分ひとりの責任にしない為にも、それをレビューしてもらわなくてはなりません。レビューしてもらうことによって、そのレビューを行った人にも責任を分担してもらう。

これ、仕事の上で凄く重要な考え方です。

 

ただ、職場環境とか仕事の環境というものは当然人それぞれでして、このレビューの際の動き方というのも職場によって全く変わります。

何をレビューするか、誰がレビューするか、どの工程でレビューするか、どういう形式でレビューするか。千差万別です。

 

ただ、千差万別の中でも共通する経験というものはあるもので。

結構ちょくちょく聞く話として、「それ、なんか意味があるの？」という細かいダメ出しを上司から受けた、という事案、あちこちで観測するんですよ。

 

例えば、発表資料の語尾やちょっとした単語の使い方にダメ出しをされた、とか。文字の大きさや色みたいなくだらないところで延々修正する羽目になった、とか。

特にコード規約に定められてもいないのに、メソッドの命名やファンクションの書き方についてやたら詰められた、とか。

 

「なんとなくダメ」みたいな回答の存在しないダメ出しよりはなんぼかマシかも知れないですが、それでも、「なんでそんな細かいとこにこだわるんだ？」という疑問を抱えながら成果物の修正をしないといけない経験って、かなり辛いですよね。

 

この事案に共通する要素って、基底に存在するのは「上司と部下間のディスコミニュケーション」なんですが、その内容を精査すると、大筋二つの原因に集約されます。

・そもそも成果物の目的が共有されているか、目的に沿ったダメ出しになっているか

・ダメ出しの基準は明確になっているか、その基準は開示されているか、基準が「個人の感覚」になっていないか

 

この「細かいダメ出しに対する不満」って物凄く印象に残るものなんで、基本的にはこれ、上司の側が、上司の責任で防止するべきものだと思うんですよ。

「しょうもない細かいダメ出し」と部下に思わせた時点で、負け。

少なくとも私はそう思います。

 

価値を生まないダメ出しは単にチームの足を引っ張るだけの行為

上記二つの補足に入る前にまず切断しておかないといけないんですが、世の中確かにしょうもない人ってのは存在していまして、

「なんか言わないと仕事をしてないような気がするので無理やりダメ出しをひねり出している」上司っていうの、信じられないかも知れないですが本当にいるんですよ。

為にするダメ出し、意味も価値も本当に存在しないダメ出しですね。これやってしまう人は本当にダメだなーと思います。

 

私は、今どちらかというと管理側の人間で、レビューをされるよりはレビューをする側に回る方が多いんですが、確かに、「レビューを素通しする」って上司としても若干ながら勇気がいる行為ではあるんですよ。

ちゃんと見てないんじゃないかと思われそう、とか。

意見を言えないのが能力不足と思われないか、とか。

 

ただ、それは徹頭徹尾上司の側の個人的な事情でして、ただそれを避けるだけの為に部下に余計な工数を押し付けるべきではない、ということは間違いありません。

価値を生まないダメ出しは単にチームの足を引っ張るだけの行為です。

 

一つ確実に言えることは、「「細かい指摘事項を無理やり探そうとしている」時点で、そのレビュアーは成果物の本質を理解出来ていないのが周囲からは丸わかりなので、それを周囲に喧伝するくらいなら勇気をもって素通しするべき」ということです。

細かいことしか目につかないんでしょう？大丈夫ですよ、その成果物。

ノーコメントで承認しましょう。死にゃしません。

 

「細かいダメ出しだなあ」と部下に受け取られたときは、何が問題か

問題はどちらかというと、「上司の側としてはきちんと必要なダメ出しを行っているつもりなのに、その重要さ、価値が部下に共有されていない、ないし価値判断が上司・部下間で食い違っている」というケースです。

私自身は、「細かいダメ出し」と部下に受け取られたケースの内、半分くらいはこちらのケースがあると思っています。

 

もう一回、上で挙げた二つの原因を引っ張ってきましょう。

・そもそも成果物の目的が共有されているか、目的に沿ったダメ出しになっているか

・ダメ出しの基準は明確になっているか、その基準は開示されているか、基準が「個人の感覚」になっていないか

 

まず重要なのが、「その成果物がなんの為のものなのか、ということがきちんと共有されていない、認識されていない」ということがないかどうか、という話です。

 

当たり前の話ですが、成果物に求められる品質基準は、その成果物の用途によって変わります。

重要な客先のプレゼンに使う発表資料と、チーム内の情報共有にしか使われない資料では、表現に求められるクオリティも、データに必要とされる精密性も全く異なります。

似たような話で、客先に納入するパッケージへのコミットと、1回データを整形することに使われるだけのマクロでは、意識しないといけない点も異なるでしょう。

 

上記は極端な例ですが、まず重要なのは、「必要なクオリティは用途によって変わる」という認識と、「その成果物の用途」それ自体をきちんとレビュアー・被レビュアー間で一致させておくこと、だと思うんです。

 

いや、当たり前の話だと思う人もいると思うんですが、仕事してると案外ここで発生するディスコミュニケーションが目につくことってあるんですよ。

「目的の明示なく作らされた成果物に、説明もなくダメ出しされる」って相当にひどい状況ですよね。何で！何で最初にゴールを共有しないの！！！！って思うんですけどね。

 

次に基準の話になります。

これも当たり前の話なんですが、何故ダメ出しが発生するかというと、それが何らかの基準に達していないから、そのギャップを埋める為です。

この基準は、コーディング規約のように明確なものかも知れないですし、そうでないかも知れません。

 

ダメ出しをする側としてまず自問しないといけないのが、「「ここはダメなんじゃないか」と感じた、その理由を明確に言語化出来るかどうか」です。

言語化出来るなら、それを共有することが出来ます。

共有出来る基準であれば、それが妥当かどうかは誰の目にも明らかになりますし、むしろ共有出来ること自体が基準の妥当さを保証することにもなるでしょう。

 

一方で、「言葉として説明出来ないような基準」はそもそも妥当なのか、という話があります。

それは徹頭徹尾「なんとなく」なのではないか、自分の中だけの感覚に過ぎないのではないか、という話ですよね。

「自分の感覚」だけに頼って他人の仕事のクオリティを図ることがどれだけストレスを発生させることか、自明な話なわけでして、「そもそもきちんと基準を言語化出来ない」と気づいた時点で、そのダメ出しは避けるべきなのです。

 

つまり、レビュアー側としては、

・資料自体の目的がきちんと共有されているかを確認すること

・ダメ出しの基準を言語化して、出来ればダメ出しの際にそれを併記すること

・基準を言語化出来ないダメ出しはそもそも妥当でない可能性を考えること

の三点が、割と重要な義務になるのではないかなーと。そう考えるわけなのです。

 

しんざき自身は、勿論レビューをしてダメ出しをする機会もしばしばあるのですが、それが何故ダメなのか、どんな目的、どんな基準の為にダメなのかは、時間の許す限りきちんと説明するようにはしています。

結構気を遣うんですよね、これも。

 

繰り返しになりますが、例えそれが「必要なダメ出し」であったとしても、「特に意味がない細かいダメ出し」だと思わせてしまった時点で、それはレビュアー側の負けだと考えます。

適切なダメ出しで、適切なモチベーション管理を心がけたいと考える次第なのです。

 

「納得出来ない細かいダメ出し」に苦しむ社会人が一人でも減ることを祈るばかりです。

 

今日書きたいことはそれくらいです。

 

 

 

 

【プロフィール】

著者名：しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ：不倒城

(Photo:ivyhouse.jesse)