■趣味プログラマが業界で生きて行くにはに関して思ったことなど．．．
趣味プログラマの定義って何でしょう？
趣味でもコードを書く人，というならわたしも当てはまりますが，書いてあることとあまりイメージが合いません．
というかうちの会社の大半の人は趣味プログラマになってそうな気がします．
新しい社員が入ったときの自己紹介で，趣味の中にプログラミングを入れない人が珍しいくらいです．
（ただし，わたしがいる事業部の話です．）
以下，うちの会社でのイメージから考えての話です．
しかしいざ現場では元趣味プログラマの独壇場となる現実があるにも関らず、実際問題、面接の場では、趣味プログラマは嫌われます。
というのは世間一般ではそんなモノなのでしょうかね？
わたしのところでは，趣味でやっている人がほとんどなので，嫌われる理由がわかりません．
うちは趣味でPerlやってる人とか歓迎です．
まず、偉い人は、コードの品質なんか気にしません。非効率で拡張性が無くて冗長でバグの温床がいっぱいあっても、仕様を満たしていれば良いコードであり、逆もしかりです。なお、ここでいう仕様は、その場の解釈によって逐次変化します。どんなに手間暇かけた素晴らしいコードであっても、あっさりボツになります。そこで腐ってはいけません。
コードの品質は重要という認識が普通なので，気にしないという会社があることが不思議なくらいですね．
もちろん，品質がいくらよくても，仕様にあっていなければ意味がないので，仕様からずれたものはどんなに素晴らしいコードでもボツにはなるでしょうけれど．
実際に，品質を気にする会社向けに，品質向上支援ツールなんてのもあるわけでして．．．
仕様がその場の解釈によって変化するのは，ちゃんと仕様書なりで確認するようにすれば防げることではないかと思いますね．
プログラマとしては，受け取った仕様に曖昧な点があれば，早めにそれをはっきりさせるよう心がけるのが一番．
変だと思っているのに黙って受け取っていては，結局自分が苦労することになってしまいます．
偉い人は、コードの品質なんか気にしていませんが、気にしているふりをしないといけないので、行数だのファンクションポイントだのコーディング規則だのといったものを持ち出してきます。その評価基準のもとでは、冗長なコードほど評価されたりしますが、やはり腐ってはいけません。
そういう偉い人がいるのであれば，色々微妙でしょうね．．．
ファンクションポイントは見積もりをとるためのもの・・・だと思っていたのですが(^^;
ただ，仕事でコードを書く場合，そのコードを自分以外の人がメンテナンスする可能性を常に考えないといけません．
特に趣味プログラマはレベルが高いことが多いので，難しい機能を利用したいと思うこともあると思います．
しかし，仕事で書いたコードは，自分がやめたら他の人がメンテナンスをしていなければならなくなります．
周りの人のレベルが低い場合，周りの人から見れば「訳のわからない汚いコード」という扱いしか受けません．
自分が理解しやすい・美しいと思うコードではなく，周囲の人が理解しやすいコードを書くように心がければ，良い評価になると思います．
また、偉い人の中には、思い出したようにコードを見て、この変数名はこの方がいいんじゃない？と明らかに筋の悪い提案をしてきたりする人もいますが、現実の社会では年上を立てることができなければ生き残れません。すかさず、そうですね流石ですと言いましょう。腐ってはいけません。
年功序列な会社なんでしょうか・・・
うちの会社の場合は，年上の人とか関係なく，普通に色々言い合っています．
というか，普段相手の年齢なんか気にしないので，お互い年上か判断できていないのでは，と思うくらいですが．．．
偉い人は、時間を気にかけているため、無駄な所で未知へのチャレンジを行うのは無駄と見られます。近代企業に置いて時間はお金と同義語です。チャレンジが許されるのはそれが必要な時のみです。趣味プログラマにとって未知へのチャレンジは動機のかなりの部分を占めるわけですが、ぐっと抑えましょう。しかし、チャレンジなんかしなくていい計画が立てられている筈なのにも関らず、チャレンジが必要な場面は案外頻繁に発生します。謎ですがそういうときは趣味プログラマの能力を最大限に活かし問題解決にあたればそれでいいです。しかし何が正しいかは前述のように解釈次第ですので、大抵の場合は後日あっさりその成果が、やらなくても良かったね、みたいにはなりますが、やはり腐ってはいけません。
チャレンジが必要ないのに，業務に無関係な無意味なチャレンジをするのは，それは無駄と見られても仕方ないでしょうね．
会社は仕事の成果に対して対価を払っているわけで，業務時間はちゃんと仕事をしましょう．
チャレンジが必要なときに，うまく問題解決すれば，それは評価される…と思います．
偉い人は設計を行います。趣味プログラマにはコードを弄りながら設計も同時にやってしまうのが常套ですが、それが通用するのはひとりで全てを行っていたからで、複数人で作業する以上は、設計は事前に済ませておかないといけません。結果、コードに落としにくい設計になったり、コードを書く段階まで穴が見過ごされたりしますが、バグを潰すのは別のフェイズですので、書き直さないといけないことがわかっていても、一応それで実装して、動きを見せてホラ上手くいかないでしょと説得を試みねばなりません。偉い人にとっては設計こそがプログラミングであり、動く所まで出来て初めてデバッグ、となるわけです。その間で発生する作業は以下略で腐っては以下略です。*1
コードに落としにくい設計になっていたり等，設計に不備がある場合や，よりよい設計を思いついた場合は，その場で指摘するべきです．
普通は歓迎されるはずです．
早い段階で設計を直せば，大幅なコスト・時間の節約になりますから．
引用元にあるようなコストを気にする偉い人に対しては，こう直さないとこのくらい余計に作業時間がかかります，と主張すれば，受け入れられると思うのですが．．．
偉い人が昔書いたコードは財産です。新たなプログラムを書き起こす時も、それを元にしなければなりません。デタラメな命名規則が使われていた場合はそれがコーディング規約となります。明らかに効率が悪い箇所を見つけても黙っておきましょう。趣味プログラマのスキルを持ってすれば素人が書いたコードに継ぎ足していくよりもゼロから書いた方が早いのは明らかですが、他の方々は既にそのコードに慣れてしまっているため、あえて変えようとする方が全体としては負担となりますので我慢しなければなりません。バグを見つけた場合は、それが潜在的なものに過ぎないのか、実際の動作にまで出てきてしまうのかが重要です。表面化しないバグは検証の余地が無いからです。表面化しないなら黙っておくしか無いです。表面化した場合は、鬼の首を取ったように騒ぎましょう。騒がないと、同じコードを元にした別プロジェクトの人が気付いてくれません。それも仕事です。
既存のシステムに手を入れる場合，動いているものは基本そのままにするべきです．
ゼロから新しくコードを書いたら，100%完璧に動作する保証があるなら良いですが，それは不可能です．
書き直したコードにもしバグがあったら，色々と大変ですから．
コードをゼロから書いた方が早い，というのも大抵は間違いです．
そもそもそんないい加減なコードに仕様書はないでしょうから，まず必要な仕様をコードから読み取って，全く同じアウトプットを出すようにしなければいけません．
これはやってみると非常に大変な作業です．
ただし，もし効率を改善できる部分があったり，表面化しないバグがあったのなら，それは適切に報告すべきことだと思います．
システムの改善を提案することができたり，今後システムに手を加えるときに，地雷を踏まずに済む可能性が高くなりますので，偉い人も喜ぶと思います．
----
わたしなりに書くとすれば，こんな感じでしょうか．．．
仕様書があるよな業務では，仕様書に書いてあるものをそのまま作る必要があります．
お客様とはそういう契約になっていて，違うものを作れば大きな問題になります．
より良くするアイディアがあったり，仕様通りに実装することが難しいことに気づいた場合は，まずお客様と交渉して仕様書を変更する必要があります．
その手順をスキップしてはいけません．
また，仕様書には，多くの場合曖昧なところや，おかしな部分があります．
そういったものに気づいた場合は，なるべく早い段階で内容を明確にして，おかしな部分を修正しましょう．
その際，必ずその修正を仕様書に反映させることが重要です．
仕様書を直さずコードだけ直すと，後で必ず問題になります．
おかしな部分が出てくるのは，仕様をまとめる人の能力のせいだったり，お客様の理解が不足していたりと色々原因がありますが，ゼロにはできないので，そういうものだと思って諦めた方が精神上良いです．
% もし，仕様を明確にすることに偉い人が非協力的な場合は，危険なので逃げた方がよいかもしれません．
コードを書くときは，自分が読みやすいコードではなく，社内の他の人が読みやすいと思うコードを書くように心がけましょう．
多少冗長な書き方だと思ったりしても，レベルを合わせることが重要です．
他の人が読めないコードばかり書いていると，トラブルが起きたときに有給中でも呼び出されるかもしれません．
お客様との契約では平日対応しなければならず，その平日に対応できる人が他にいなければ，普通はそうなります．そこで連絡が付かずにどうしようもなくなると，後々大きな問題になります．
業務中は，要求されている作業を第一に進めましょう．
さっさと仕事を終えて，定時で切り上げて，家に帰ってから趣味のプログラムをしましょう．
仕事中に趣味のプログラムをやっていると，まずいことになるかもしれません．
（ただし，能力があれば多少は大目に見てくれると思いますが，まじめにやってた方がより評価は高いでしょう）
Recent Comments