ぼくは決して完璧主義では無い、と断言できます。
エニアグラムのタイプ7：熱中する人というタイプからも分かるように、人からも「楽観的」と言われます。
実際に、1つの物を完璧に仕上げるよりも6割5分の出来でいったん評価を受けたほうが良いと思っていますし、今ある物を完璧に仕上げるよりも、新しい物を取り入れていくことのほうが好きですね。
全部をやっていないと気が済まない、と言う人がいることは理解していますが、自分がそうする気には、とてもじゃないけどなれません。
そんなぼくでも気にしているのが、今回のエントリーのタイトルである「神は細部に宿る。悪魔も細部に宿る。」です。
なので部下からよく言われるのが、「そんないい加減で大丈夫？」であり「細かくて、うざっ！」なのです。
神は細部に宿る。悪魔も細部に宿る。
この舵取りの判断基準ははっきりとは言えないのですが、「なんか、ココ危なそう」っていうにおいがするかどうか、なんですよね。
例えば、テストを終えリリース前のレビューを受けにあがってくるプログラムでも、いつもの手慣れたものだから大丈夫、みたいな空気感が漂っている場合があります。
でも、こんなところが結構クサイ。
バグや考慮漏れがある場合が多いんですよね。
そういう「いぶかしい」個所については、いろいろな目線でチェックを掛けるようにします。
このときに大事なのが、その部下が持っていない目線を意識すること。
同じ目線で評価しても、細部の悪魔は身を隠したままです。
別の目線で評価することで、仕様の思い込みや使われ方の考慮不足など、その悪魔の尻尾を掴むことができます。
「神は細部に宿る」は、やはりフロントエンドの部分で気をつけることが多いですね。
それは、ユーザーが直接触るところで、多くの目線に晒されるからです。
1ピクセルのずれや、細かいメッセージの表現、色味やテキストボックスの幅や画面レイアウト全体のバランスなど、プログラマが意識しないところを気をつけてあげるようにしています。
おなじ画面でも、ボタンやテキストボックスがぴったり揃っていると、美しく見えますからね。
そういう気をつけ方をするようになってから、納品後のユーザーの評価が自分たちが思っている以上に高いことが過去に何度もありました。
機能的には何も違いが無いのですが、見た目って結構大事なんですよね。
まとめ
気をつけなければならないのは、その指示の仕方です。
ぼくが気にするのはあくまで結果であり、そのやり方までは口を出さないことです。
手取り足取り指示をしてしまうと、部下の成長を邪魔してしまいます。
上司のやるべきことは、どれだけ明確に部下にゴールを示すことができるかだと思います。
細部のツッコミで有効なのは「なんで？」という問いかけです。
「なんでこういうプログラムの組み方なの？」「なんでこのテストケースなの？」「なんでこの配置なの？」って言う問いかけをすると、部下の頭の中が開店し始めます。
その答えが「仕様書にそう書いてあったから」とか「特に理由はありません」っていう返事が返ってくると、「いぶかしい」と判断してもおかしくないです。
