暇そうな人から学ぶ仕事上の護身術

ワークスタイル

» 2011/01/13

　あけましておめでとうございます。昨年は比較的真っ当な生活を送れたような気がします。今年はどんな仕事が待っているのでしょうか。さて、今年も新年早々、15キロほどほど歩いてまいりました。これをやると、1年終わったなという気になれ、残りの364日は気楽に頑張っていける気がします。新年のイベントとコラムのネタ、どちらの方が長続きするでしょうか。どちらもできるだけ頑張っていきたいと思いますので、よろしくお願いいたします。　

●いろいろ仕事しつつ定時で帰るために

　コラムのTwitter欄でこのようなコメントを拝見しました。バランス良く仕事をこなすタイプの方が定時に帰るって難しいですよね。私の場合、定時で帰ることだけを考えると、

• 得意な分野の仕事を得るために、自助努力はあくまで得意な仕事に関してのみ行う
• 前回のコラムのように、苦手な仕事が来た際は、工数を多めに見ておく。サポートに回る可能性が高い場合は、さらに多めに工数を見る
• サポートに回る可能性が高い場合は、できるだけその人の状態を把握しておく

といった対策を取ります。ここ2年ぐらいの短い経験上では、雑談による情報収集や技術的なフォローを早い段階で入れておくと、その人の状態、仕事内容が容易に把握できるため、何かあった際に比較的早い対応ができます。基本的には「何かが起こる前提で、どれだけバッファを積んでおけるか？ どれだけ迅速に対処できる状況を作るか？」ということに尽きます。PMが考慮してくれればよいのですが、その辺はお察しください。

　基本的には、これだけやっていればある程度のことは対処できます。これ以上は必要ないだろうと考えていた時期が私にはありました。ある日、十分なバッファを作って安心していたところ、PM「余裕そうなので、期日を短くしますね」と、何故かバッファをすべて消すどころか若干の進ちょく遅れ扱いにされてしまいました。「遅れそうならまた戻しますから」。その言葉を信じた結果、その翌週この事件は起きたのでした……。

●暇そうな人の観察記録

　このような状況でものんびり過ごしているように見える（ほぼ間違いなくそうなのですが、本人ではないので「見える」と記述します）のに、定時で帰る人ってどこの会社にも1人はいるのではないでしょうか。今までは嫌な気分しかしなかったのですが、ある日、今の状況を打破するカギがこの人から得られるのではないかと思い、観察してみました。

・実際その人は暇なのか？

　端から忙しくは見えないという人が私以外にもいたので、忙しくはないでしょう。ただ、進ちょく上はなぜか忙しそうで、何度か作業を引き取ったりしていました。それでも進ちょくが追いつかなく残業命令が出ると、突然進ちょくが上がり、やはり定時少し過ぎで帰る。忙しい時もそうでない時も、ある程度忙しいように見える、そのうえ定時で帰るのです。

・忙しい時に早く帰れるのはなぜか？

　これは観察してみたらすぐに分かりました。簡単に言うと、進ちょく報告がうまい（せこい？）のです。その時は週ごとに進ちょく報告がありましたが、過度な進ちょく遅れにならないよう進ちょくはぼかしてゼロまたは低めに見せて報告されていました。例えば、進ちょく報告日の翌日までにタスクA、B、Cが完了している予定とします。この時に実際はタスクA、Bが完了し、Cの途中まで進んでいるにも関わらず、Cが未着手として報告されていました。結果として、その人のC以降のタスクは別の人（この時は私）に移管され、そのミーティングは終わりました。

　このミーティングの前、タスクCの着手中成果物が進ちょく前日に全員が閲覧可能な場所に上がっていたのを私は見つけてしまっていたんです。「そこまでするならせめて簡単には分からないようにしてくれ……ある意味この中途半端さが一番ストレスになる……」と思いつつ、PMがいかに無関心なのかよく分かった瞬間でもありました。

●暇そうな人から学ぶ仕事上の護身術

　私が出会ったようなPM相手に安心して作業をするにはどうすればいいのか。進ちょく偽装してまで早くは帰りたくないですし、かといって正直に進め過ぎるとバッファを削られたうえにトラブルが降ってくる。両者の葛藤になると思いきや、意外とすぐに自分なりの答えは出ました。それは、「品質を極端に上げること」でした。

　現在の環境では短納期であったり、進ちょく遅れの状態の仕事に参加することが多く、品質を気遣う時間が少なかったと思います。もともと作業速度を上げて余った時間で見直しするタイプでしたので、ある程度の作業精度を犠牲にすれば高めの生産性が出せます。急がなければならない仕事を続けた結果、品質は自然と後回しになり、余った時間があっても他のタスクが遅れていて手伝うことになっていました。これが、トラブルが発生した時の残業を招いていた気がします。

　品質を上げることのメリットは周知の事実と思います。一番大きいのは、後続工程の作業量が減ることですね。進ちょく偽装がタスクの分子を変化させるのに対して、品質を上げることはタスクの分母を減らすといったところでしょうか。3日かかるタスクでも、トラブルの芽がほぼ摘み終わっていれば2日で終わるでしょう。ても、そのタスクが未着手ならば進ちょくは0％、嘘は言っていませんｗ 書いていて思ったのですが、「本来あるべき姿」ですよね。

　品質を上げるために、前プロジェクトでコーディングの方法を変えました。それまではコーディング、動作確認で完了していたものをラフスケッチ（画面定義をベースにまずざっと作る）、清書（設計書を細かく見て判定文を中心に追加、修正）、動作確認、最後に設計書を見つつコメント付与のチェックと最終確認をするためにソースレビューをするようにしています。ここまでやれば、バグ率はそれまでの5％くらいまでに減ります。「テスト計画でバグの想定数を出しているから少ないと困る」と言われたこともありますが、決められた工数より少なく完了させる上で高い品質を目指すことに何か問題はあるのでしょうか。

●今こそ品質を上げる時

　今まで、スピード重視で成果を上げようと躍起になっていたような気がします。いつの間にか何かに追われるような状況になり、ストレスにもなっていたとも思います。作業を早く終わらせても「見積もりが甘いから早く終わった。もっと割り当てる工数を減らそう」とされてしまう今こそ、品質重視の立ち回りが大事な気がします。

　この前は関数「（」の開始位置や引数の「，」の開始位置すら揃えようとしていましたが、さすがにやり過ぎな気がしましたので自重しています。ただ、前の会社で「こうした方が見やすい」と見せられた時のチョットした感動は今でも覚えています。最近はIDEのフォーマッタなどである形に自動的に直してくれるので、勝手にやってくれるもの程度にしか認識されないのが残念ですね。

　ここまで長くなってしまいましたが、いかがでしたでしょうか。新年を迎えるにあたり、今年の抱負を考えるうえで、何か参考になれば幸いです。