プログラマが考える良いプログラマの条件
例えば仕事が早いだとか、例えばバグを出さないだとか、例えば納期に遅れることがないだとか、例えば残業しないだとか。
いやそれ、はっきり言ってプロとしては最低条件なんじゃないの？ とか、思いつつ。
実際に良いプログラマというのは下手な企画より企画力があるものじゃなかろうか。
自分で作る能力があるからなのか、完成図の予想像が正確というかなんというか、そういう視点から問題点をプッシュできるところまで行ってようやく良いプログラマに足を踏み入れてる段階だと思います。
はっきり言って、技術力が高いのはそれ売りにしてるんだから当たり前でしかないというお話です。
まあそういう理想論を始めるとおそらく日本のプログラマの8割程度はプログラマ失格という話になってきそうな部分はありますけどね。
その8割の内でも個人的な好みでいうなら、大した状態になってないのに騒ぐプログラマとかは嫌いですねー、とか。
全然炎上してないプロジェクトで『ヤバイ』とか言ってしまうパターンですが。
それって見通しができてないだとか見積もりが狂ってるだとかそういう意味ですよね、としか言いようがない。
端的に言って、業務遂行能力に疑問を持たざるを得ない。
いやまあスケジューリングというものが実作業と切り離されてる場合って結構あるんで、なんとなく危機感を覚える瞬間というのがわからないわけでもないんですけどね。
かといってそれで騒ぎ立てるほどでもない。
漠然とした不安なんてものはどの段階でもふとした瞬間に湧くものですし。
それを突き詰めて、根拠がある不安なのならそれは確かにアラートでも投げるべきですね。
単に見積もり上の漏れとか工数だとかだけを見比べてヤバイと思う程度なら全然ヤバイ状態になってないとか思うところ。
話を戻すとすると、本格的にヤバい時にリスクを回避する提案ができるかどうか、というのが良いプログラマかどうかの境目なんじゃないかな、と。
実際設計できない業種の人に『ヤバいです』とだけ伝えても何がどうヤバいのか実感できないでしょうし。
というか元の想定に沿えない恐れが発覚した段階でコスト的な要因（例えばどれくらい期間だとか工数が足りないか）だとか対案（この機能をこういう機能に変更すればこの程度の影響度で実装できる見込みとかそういうの）を出さないといろいろ話にならないでしょ、と思うんですけどどうですかね。
まあ、残念ながらそこまでの私が考える『良いプログラマ』というのはほんの一握りしかいませんけども。
というかその辺りが上手いプログラマって作業者から管理者だとかゆくゆくは営業だとかそっちに回される場合がほとんどな気がしますけども。
正直いくら営業増やしたところで実際の処理能力が上がらないと業績って不安定になる一方な気がしなくもないんですけどねぇ……と、思わなくもない。
実際管理者以上に置くとコーディングする機会が減る≒強みが出せなくなっていく側面ってありますし。
