品質と水準

[-]部下のことを顧みない管理職の話 | Books&Apps
http://blog.tinect.jp/?p=24644
先日、この記事を読んだ。
読んだ時は「そうかもなぁ〜」程度に楽しく、興味深く読んだ程度。

今日、ふと思ったことがある。
こういう経験がないと、「ある水準以上のものを作ろうという感情が沸かないのではないか？」ということ。
もう少し正確に言うと、「ある水準」がわからないから、「なんとなく持っている自分の水準が低いことに気付いていないのではないか？」ということ。

水準を持っていない人がいる

なぜ冒頭の記事のような経験がないと「ある水準」がわからないかというと、「水準を教えてもらっていないから」。
水準を教えるということは「ここまでこうなったものだぞ」と言葉で教えることではない。

例えば、ある仕事を頼まれ何かを作ったとする。
それは期待していた水準の80%かもしれないが、上司によっては「それでよし」としてしまう。
作った人からすると「それでよし」と言われたので「これでいい」ということになる。
しかし、実際には会社や上司から見た場合の「期待値の80%の品質」である。
ひどいのはこれが代々続くと、80%の80%となり…と急激に質が落ちていくこと。
この話は今回の話題ではないので省略するが、後輩の育成を疎かにすると…ということである。

水準を知った経験

自分の場合は何度もやり直した経験がある。
たぶん、一番繰り返しやり直したのはドキュメント類。
主に文章が多いけど、説明用の図だったり、設計書の例だったり、いろいろ。

「このドキュメントでお金もらうの？お金払う立場だったらこれにお金払う？」なんてことはよく言われたし、
「もういいよ、明日までに描き直すから」なんて言われたこともある。
これを言われたのは夜中の0時を過ぎていて、その日に説明しなければならない資料。
そう言われても「はい、そうですか」なんて帰れないし、どの程度の品質が望まれているかわからないから、そのまま修正して早朝の4時か5時までかかって描き直した覚えがある。
このときは描き直すことで使える品質になったらしく、その資料を使った。
こういう経験があると品質の水準を得ることができる。

あるときは「ここまで丁寧にやったの？」と十分水準を満たしたドキュメントを書いた。
こういうタイミングで「やっと書けるようになってきたか」と実感したものだ。
ある程度の水準を満たしている資料の場合は理解してもらいやすく、その後、質問されることがなかったり、対応しなくて済むので楽だった。

水準を伝えた

GW前後にちょっとしたシステム(というほどでもないが)の作り方を教えた。
とりあえず動くようになったものの、品質としてはとてもひどいものだった。
しかし、そのときはスキルの都合もあり、とりあえず動くことが目標だったからこれはこれでよし。
だけど、水準に満たなさすぎていることが気持ち悪く、関係者に「今のままでは品質が低すぎるし、本人のスキルも伸びないからフォローアップが必要」と伝えた。
結果的に「ソースコードレビューして欲しい」と本人に言われたからレビューして、現状の品質と感じたことを伝えた。
具体的に伝えたことは、

• 動くところまで作ったのはよくやった。
• ただし、プログラミングのスキルは新人なら許せる程度。
• 今回、リファクタリングしてみせた状態でもまだ品質がいいとは言えない。
• リファクタリング後の状態が初めから書けていたらまぁまぁ。

ということ。
冒頭の記事のようにきつくは言わなかったけど、どれくらいの品質であるかをきちんと伝えてあげないと伸びようがない。
闇雲に何かするのはつらいし、始める気にさえなれない。

また声をかけてくれればいくらでも教えるけど、繰り返すということをあまり目にしないから、もう来ないんじゃないかなぁ〜。

まとめ

水準はなるべく早いうちに知っておいた方いい。
歳をとると「自分はできる」と勘違いしやすくなるから。

今後も気になったことは伝えていくけど、無反応な人が多いのが不思議。
あと、代々80%の品質だとしたら…も、気になっていることのひとつ。