がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

お仕事と趣味の違いとかアマチュアとプロとの乖離とか

まぁ色々思うところ多々あるわけなのですが。ある意味好都合なことに
http://d.hatena.ne.jp/ytqwerty/20070228/p1
こちらに「趣味プログラマが業界で生きて行くには」というエントリがありまして、ちとコメントの形で書いて見たいかなぁと。


幸い http://d.hatena.ne.jp/ytqwerty/20070302#p1

本当は叱って欲しいの

とか

こないだのエントリは、私を含む他の特技と社会性の無い学生気分の抜けないダメダメな趣味プログラマが、悪いのは社会性の無い自分だとはわかっていても認めるのも癪だし認めた所でなんにもならないので、どういう考え方をすれば責任転嫁しつつ前向きに周囲のことも考えられるか、という……。

とか

とりあえず、今年の目標のひとつである、被ブックマーク数で最大の記事を更新する、

とかあるので。気軽にいってみましょうw

好きこそものの上手なれとは言いますが、ことプログラミングの世界においては、その実力は圧倒的に趣味プログラマのほうが、底辺から並にかけてのプロなんかよりも遥かに上と断言できます。もしあなたが、自分の実力は現場で通用するのかと悩めるプログラムが趣味の高校生であれば、断言してあげましょう。通用し過ぎます。まあ、底辺から並にかけての、と断りを入れましたが、上のほうは見ちゃいけませんということで。

初手から微妙ではありますが。上下の判定基準が「どこにあるか」次第かとは思います。
とはいえ「底辺から並にかけての、と断りを入れましたが、上のほうは見ちゃいけませんということで。」ってあたりで色々と見えているものもあるのでしょう。
ってかぶっちゃけ「並以下のさらりまんな技術者もどきのスキル」については………考えると胃が痛くなるので略w

しかしいざ現場では元趣味プログラマの独壇場となる現実があるにも関らず、実際問題、面接の場では、趣味プログラマは嫌われます。
そして、当人にとっては、なんで嫌われるのかがまるでわからなかったり納得できなかったりするわけです。この辺が噛み合わないとお互い不幸です。

これは、正直おおむねYesかと。ただ、多分、私と書かれている方とでは、観点がまるで違うような気がするのですが。

まず、偉い人は、コードの品質なんか気にしません。非効率で拡張性が無くて冗長でバグの温床がいっぱいあっても、仕様を満たしていれば良いコードであり、逆もしかりです。なお、ここでいう仕様は、その場の解釈によって逐次変化します。どんなに手間暇かけた素晴らしいコードであっても、あっさりボツになります。そこで腐ってはいけません。

これはある意味非常に重要です。ここでのポイントは「仕様を満たしていれば良いコード」です。
ビジネスにおいて「発注者の意図を汲む」のは最低限当然のことなのですが。趣味プロで鳴らしてしまっている方々の場合「自分の思いつきで"自分がよりよいと思われる"仕様に勝手に変更を行う」などの、いわゆる「発注者の意向を無視した」行動をとりがちなのが、割合によく見かける、大きなトラブルの原因だと思います。
次点は「コードの品質とはなんぞや」という話になるのですが。
ちなみに「どんなに手間暇かけた素晴らしいコードであっても」ですが。手間暇かけたようなコードは大抵使えません*1 :-P

偉い人は、コードの品質なんか気にしていませんが、気にしているふりをしないといけないので、行数だのファンクションポイントだのコーディング規則だのといったものを持ち出してきます。その評価基準のもとでは、冗長なコードほど評価されたりしますが、やはり腐ってはいけません。

限りなく微妙ですね。ファンクションポイントは見積もり上のものなので、あんまり考慮しなくてよいでしょう。
行数は………悪しき慣習ですええ。行数とか持ち出されたら、とっとと「逃げ出す準備」しましょう :-P
コーディング規約は諸刃。必要な部分は多々あるのですが。ポイントは「なぜこの規約が出来たのか、の背景がちゃんと語れるか否か」。単純に「可視性を高めるためにみんなで似たようなルールにする」っていうのは、こと業務に限っては「きわめて重要」です。郷に入らば…って言葉もあるでしょ?

また、偉い人の中には、思い出したようにコードを見て、この変数名はこの方がいいんじゃない?と明らかに筋の悪い提案をしてきたりする人もいますが、現実の社会では年上を立てることができなければ生き残れません。すかさず、そうですね流石ですと言いましょう。腐ってはいけません。

踏んでしまえw
まぁとりあえず「理由」くらいは聞き出しましょう。
その上で。技術的に「問題が無ければ」、社の流儀に従いましょう。ただしそれが「社のコーディング規約とは違う発言」だった場合には、速やかに質問をします「コーディング規約と異なるように思われるのですがどんなもんでしょうか?」

偉い人は、時間を気にかけているため、無駄な所で未知へのチャレンジを行うのは無駄と見られます。近代企業に置いて時間はお金と同義語です。チャレンジが許されるのはそれが必要な時のみです。

至極当然ですね。コストって単語の有無は、アマチュアとプロとを切り分ける重要なラインの一つです。
コスト意識がまったくないのであれば、少なくとも「職業として」プログラミングをするのは控えたほうがお互いのためです。

趣味プログラマにとって未知へのチャレンジは動機のかなりの部分を占めるわけですが、ぐっと抑えましょう。

微妙にはずれ。正解は「チャレンジしたければ上が納得するようななにか(include'詭弁')を用意しましょう。
別に抑える必要は、必ずしもありません。

しかし、チャレンジなんかしなくていい計画が立てられている筈なのにも関らず、チャレンジが必要な場面は案外頻繁に発生します。謎ですがそういうときは趣味プログラマの能力を最大限に活かし問題解決にあたればそれでいいです。しかし何が正しいかは前述のように解釈次第ですので、大抵の場合は後日あっさりその成果が、やらなくても良かったね、みたいにはなりますが、やはり腐ってはいけません。

これも微妙にはずれ。
「やらなくても良かったね」と言わせないような、レポートとか成果物とかあげるです。

偉い人は設計を行います。趣味プログラマにはコードを弄りながら設計も同時にやってしまうのが常套ですが、それが通用するのはひとりで全てを行っていたからで、複数人で作業する以上は、設計は事前に済ませておかないといけません。結果、コードに落としにくい設計になったり、コードを書く段階まで穴が見過ごされたりしますが、バグを潰すのは別のフェイズですので、書き直さないといけないことがわかっていても、一応それで実装して、動きを見せてホラ上手くいかないでしょと説得を試みねばなりません。偉い人にとっては設計こそがプログラミングであり、動く所まで出来て初めてデバッグ、となるわけです。その間で発生する作業は以下略で腐っては以下略です。

「それが通用するのはひとりで全てを行っていたからで、複数人で作業する以上」という観点はとても重要。常に他人が介在するのはビジネスの基本以前の問題。テストに出るからね > 寺子屋の面々
ただ「コードに落としにくい設計になったり」に関しては上だろうが斜めだろうが切り込んだほうがいいし、「コードを書く段階まで穴が見過ごされたり」しちゃいかんです。
このあたりはXPとかをきちんと実行すると色々と以下略。

偉い人が昔書いたコードは財産です。新たなプログラムを書き起こす時も、それを元にしなければなりません。デタラメな命名規則が使われていた場合はそれがコーディング規約となります。

ある程度Yes。「特に問題がないのであれば」可能な限り「その会社さんの流儀に併せた」コードを書くのはとても重要です。
「芸人に 下手もうまいも なかりけり 行く先々の 水にあわねば」


ただ

明らかに効率が悪い箇所を見つけても黙っておきましょう。

これは微妙。というか「居心地のよい会社にいたい」のであれば、とっとと指摘しましょう。それで不遇な扱いされるような会社ならとっととスピンアウトしたほうが、お互いのためってもんです。

趣味プログラマのスキルを持ってすれば素人が書いたコードに継ぎ足していくよりもゼロから書いた方が早いのは明らかですが、他の方々は既にそのコードに慣れてしまっているため、あえて変えようとする方が全体としては負担となりますので我慢しなければなりません。

リファクタって単語を調べてみましょう。

バグを見つけた場合は、それが潜在的なものに過ぎないのか、実際の動作にまで出てきてしまうのかが重要です。表面化しないバグは検証の余地が無いからです。表面化しないなら黙っておくしか無いです。

ここで「こんな懸念が…」と、ある程度話のわかる人に一言発言しておくだけで、後々の布石になります*2

表面化した場合は、鬼の首を取ったように騒ぎましょう。騒がないと、同じコードを元にした別プロジェクトの人が気付いてくれません。それも仕事です。

これは状況によりけりだけど、騒ぎ方間違えると逆に「自分の首をとられる」ので要注意w
この辺のやり取りっていうか駆け引きの能力はまぁ個人の好み次第なのでしょうが。私の場合「悪意が無いように見える質問を重ねる」のが好きですw
あと重要なポイントが一つ。「犯人探しはしない」こと。あんまりにも明らかに「問題のある特定少数」が見つかったら別だけど。


で、まとめ。
趣味プロで嫌われる…というか自分自身痛い目にあってていやなのは、おおむね

  • ビジネスという観点が脳みそから抜けている
  • 他人というものを意識していない

の2点。
で、下手に指摘をすると腐る(苦笑


もっと正面からがっぷりとよっつに組み合ったりぶつかったりして「お互いにとってよい落としどころ」を探してもよいんじゃないかと思うんですがどんなもんなんでしょうか?
かくして私は「職人の居場所*3」作りに奔走するわけなのですがw

*1:ちょっと噛み砕いて補足。コーディングは「できるだけしない」のがベスト。でも0ってわけにはいかないから「必要最低限なコード」を書くのが鉄則です。なので、考察段階で練られたものはよいのですが、コーディング段階で「じっくりと時間をかけて書き上げた」ものは、大抵が冗長だったりむやみに小細工に走ってみたりと、あまり評価できないことが多いです。

*2:なんの布石なのかは省略w

*3:格子組、っていう会社作ってます