プログラマーがみんな秘密や嘘を抱えているとして、プログラミングできないマネージャーはどうしたらいいんだろうかと考えた


こんな記事を読みました。

プログラマーは皆、常に秘密や嘘を抱えている(totopon114689の日記)

長い記事なので、まず中見出しに沿って要約を致します。

  • 細部仕様があいまいな企画・設計が降りてきたら、プログラマは「自分の判断で適当にコーディング」する。
  • 「進捗報告」なる儀式はあるが、本人以外にその真偽はわからないし、何かでハマる可能性もあるので正直に答えてくれたとしても精度はアテにならない。
  • バグ探しのテストは単純作業でおもしろくないので、サボったりゴマかしたりしやすい。
  • 他人の書いたコードに不具合を見つけても、めんどうくさいから指摘しない。
  • スキルアップしてから、過去に書いたコードのマズさに気がつく。そしてスルーする。
  • 特定個人にしかわからないブラックボックスなコードを残してしまう。
  • 超デキるやつが、担当箇所を終わらせてるのに忙しいふりをして他の仕事を手伝わない。
  • プログラマをマネジメントするためには、モチベーションを維持するのが最も重要。

あー、なんか私が考えていたことをそのまま整理して書いてくれたかんじです。とくに私の場合、プログラミングができないので、「ここにバグがあるよ」とか、「この方がスマートに書けるんじゃない?」とか言えないわけです。コードレビューっていうんでしたっけ、そういうの。言葉は知ってるけど、できない。

そういう私がプログラマの上司をやっているわけですが、そうなりますと、日々の生産性だとか、スキル向上だとか、そんなのはぜんぜん判断できないんですよ。だってわかんないんだから。

文系上司がプログラマを人月人時で売っているような会社ですと、書いた行数やらで評価することもあったらしいですが、そんなスパムブログみたいなプログラムを書かれてもトホホですし、結局そういうのって自分にわからないものを定量化したい、思考をサボりたいって考えから出た管理手法なんでしょうね。

そんなわけで、部下がやっていることがさっぱりわからない状態で上司をやらせていただいているわけですけれども、そうなりますと困るのはどうやって生産性を上げるのかというマネジメント手法のところです。

値入交渉が甘いんじゃないかとか、顧客分析が足りないだとか、営業的な話だったら売る方も買う方もやってたんで見当もつくし、それなりにサマになるんだろうなと思うんですが、テクニカルな指導、いわゆるティーチングにおいて何の役割も果たせないというのは「上司」という立場を成り立たせるのが極めて難しい状況であるなあと。

そうなると、見れるのはモチベーションしかないんですよね。

仕事が楽しい、数字が上がるのが楽しい、ユーザーやクライアントが喜んでくれるのが楽しい、そんな思いをどれだけ共有できるか。

あと、出口・行き先の話も大事。

こっちに向かって行ったらなんか楽しそうだぞとか、うまく行きそうだぞとか、そういう展望(ビジョン)を示さなきゃいけない。

でも、それは押しつけではダメで、納得感が絶対に要る。リーダーとして意思を示しつつも、部下の意見を受け止めて、よりよいビジョンにアップデートし続けなきゃ納得感なんて到底得られない。

けっこう難しいですなあ、これ。

こういうことを考えながら数ヶ月やっていたら、幸いなことにいまのところ部下からのウケはいいようで、毎日毎日私以上に残業をして日々企画・開発に勤しんでくれております。本当にありがたい。っていうか、そもそも「上司・部下」って関係性が嫌なんですけどね、私は。

それはあくまで適正やら役割分担でたまたまそうなってるだけで、上司は権限や給料が多い代わりに失敗やリスクを負う。部下は失敗してもいい代わりにチャレンジの機会が多い。そんなかんじがお互いにやりやすいんじゃないかなあと。いや、私の給料は部下とあんまり変わんないんですけど。

そんなわけで、部下部下って書きましたけれど、社内的にはメンバーって言葉で通しています。誰も気がついてはいないであろうこだわりではありますが。リーダーって役割と、メンバーって役割を分担しているだけだよなあと。権威・権力ってストレートのテキーラなみに酔っ払いやすいものなので、自分が勘違いして暴走しないよう気をつけている次第。

一応、いまのところメンバーからのウケはよいようで、やりやすいとか仕事が速くなったと喜んでいただいてはおります。リーダーの仕事って、メンバーに対するサービス業みたいなものなので、その面では成功できているものの、一方でユーザー・クライアント・上司・その他のステークホルダーに対しても喜んでいただける結果を残さなければならないわけで、「嗚呼、中間管理職の悲哀とはこういうことなんだなあ」などと、31年余りを生きてはじめて痛感している次第です。

同じ中間管理職なら、島耕作のように赴任した先々でマドンナと夜のあれこれに浸りたいものですが、非モテ一直線のわたくしにはそんなボーナスステージもないわけで、この鬱屈した気持な何にぶつけたらいいのか。

なんか、書きはじめたときに考えていたことからモーレツにずれてきました。

結論は先に書いておいたんだけどな、なんでだろ?

ええと、このままダラダラ書いていると辿り着けそうにないんで、急ぎ足に3点まとめてみます。

プログラマのサボりは天才プログラマじゃなきゃ見抜けない

元記事で、プログラマには底辺から最上層で30倍のスキル差があると書いていますが、たぶんそれは事実でしょう。ヘタをしたら、30倍ではきかないかもしれません。

大前提として、プログラマのサボりを指摘できるのは彼と同等かそれ以上のプログラマでなければならないわけです。んで、ヘタクソが書いたプログラ、ムの具合の悪い点を片っ端から指摘しようと思ったら、さらに輪をかけて優秀じゃなきゃいかんわけですよ。

つまり、多人数の関わるプロジェクトを純粋にエンジニアリングの視点から仕切れるプログラマは、よほど賢い人でなければ無理なわけで、下手をすると、そういう人を監督者に置くんじゃなく、その人ひとりに頭からケツまで書いてもらったほうがよいかもしれません。

凡才の集団がどうやって勝つか

そんな感じでひとりの天才が圧倒的なパフォーマンスであれこれ作って話題をさらうWeb業界。われわれ凡人の立つ瀬がどこにもないように思えますが、まあ、そこは選択と集中ってやつでなんとか。

天才が30倍のリソースをもっていて、それを10のことに割り当てているとしたら、1つあたりは3じゃないですか。それなら、凡人は全力である1つを4にできるようがんばればいい。

いや、いっそのこと3とか2でも、目の醒めるような成功はできずとも、そこそこうまくいけるんじゃないでしょうか。

プログラマを自分の考えた企画を具現化させる道具としてしか考えていない人も多い。

最後に持ってきましたけど、これが最大の問題かなあと。

細部まで詰めに詰めて作り上げなきゃ、ちょっとしたアルゴリズムすら動かないわけですが、パワポやエクセルに半端な画を書いて「企画ができました!」って人種にはいますぐレミングスの如く海に飛び込んでいただきたくなる。いや、私もプログラミングとかデザインとかできないですけど。

いや、まあ大枠の舵取りって意味で企画は大事なんですが、神は細部に宿るといい習わせられるとおり、細かいことをいちいち気にしなちゃよいプロダクトなんて作れ出せません。

それには細部を作り上げるプログラマの「もっとよいものを作りたい」って気持ちを引き出すことが不可欠なわけで、ああ、なんかもう書いているうちに何が言いたいのかよくわからなくなったのでこの辺で。

なんか、とんでもなく手に余る問題な気がするんで、メンバーには私を雨除け程度にご認識いただいて、各自勝手にやる気を出して、最高のものを作っていただけるとありがたいなと思った次第。

follow us in feedly

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です