Hatena::ブログ(Diary)

totopon114689の日記

ページビュー
4545558844
 | 

2012-01-11

プログラマーは皆、常に秘密や嘘を抱えている

プログラマーは皆、常に秘密や嘘を抱えている。
これは間違いない。

基本的には誰にも話さないが、
(家族や友人などプログラムを知っていない人間に話しても分からない、という事もある)
プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。

秘密や嘘の傾向には幾つかのパターンがある。


1) 仕様があいまいな場合の適当なコーディング
仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。
また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか?
洗い出しているとキリがない場合もある。

仮に事前に洗い出していたとしても、
「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか?」
などといった、その先がまたあいまいになっている場合もある。

このような場合、本来であれば決裁権のある人間に相談するのがベストではあるが、
納期や現場の人間関係などの兼ね合いがあり気軽に相談できないような環境である場合
プログラマーは「自分の判断で適当にコーディング」する。

・少しでも想定外だったらシステムごと停止するような頑固な処理を入れる
・適当なエラーメッセージを出す
・自分で「こうかな?」と判断して適当に対処処理をコーディングする
・もういっその事気にしない

このようなコーディングは作った本人以外にはよく分からない、いわゆるブラックボックス化され
作った本人はそのことについては外部(自分以外の人間)に対し触れない。むしろ自身も忘れる。

ただ、これは人や内容によって受け止め方が異なる場合もある。
人や内容によっては「何勝手な事してんだよ。俺に一回相談しろよ」となる場合もあるし
「おお!そんな気回しをして対処プログラムを作ってくれていたんだね」となる場合もある。

また、細かに一つ一つ相談するにしても、相談対象の相手が
「そんな細かい事、てめーが考える事だろ?そんな事いってねーでどんどん次の機能作れや」ってなる人の場合もある。

このさじ加減も非常に難しい。

そんな微妙な判断のポイントが日常的に出現するのがプログラムだ。
「だったらもういっその事全てを適当にやった方が楽だろ?」
という結論に至るプログラマーも少なくない。



2) 進捗報告
プログラムコーディングとは、とてつもなく複雑な作業である。

完成が100%とした場合、現在どこまでコーディングが完了しているのか?までは作っている本人以外には分かりにくい場合がよくある。
(特に画面の無いバッチ処理など)

が、実は作っている本人にも現在の進捗状況がよく分かっていない場合もある。
(これは経験の浅いプログラマーに多くみられる)

そんな感じなのでチームリーダーなどから進捗報告を求められた場合、思わず
「予定通り進んでいます!80%です!」
などと適当な事を言ってしまう場合がある。

しかしフタを開けてみれば実際には全然動く状態ではなく、
作った本人を問いただしてみても的を得た返答が得られない場合がある。
当たり前である。

何せ、作っていた本人自身が進捗状況が良く分かっていなかったのだから。
そこで、漠然とした不安の中で怒られるのを先延ばしにするために進捗報告で嘘を言っただけの事である。

これは実は本人ばかりを問いただす事はできない。
こういうものなのである。


デキの良い管理者であれば、事前に細かいチェックを入れたり
全体の完成だけにラインと結果報告を引かず、節目節目で単体的な成果物の提出を要求したり、
スケジュールも実際の納期よりも少し短い期間を本人に伝えたりするものである。

繰り返すが、嘘も含め作っている本人も良く分かっていない場合もある。
経験の浅い人間に「その傾向がある」だけでありベテランでも同じようなミスや嘘をする場合はある。
何せプログラムコーディングとは、とてつもなく複雑な作業なのだから。


3) 面倒な繰り返し作業やテスト
プログラマーの仕事は頭を使ってコーディングを行うだけではない。
たいていの場合、作ったものに対するテストも仕事のうちに入る。

テスト、と一言にいってもその内容は多岐に渡り、
さっと終わるものもあれば、とんでもないパターンのテストを実施する場合もある。

例えば、同じような画面操作をひたすら1000回繰り返すテストの場合もあるし、
テスト用のデータを1000件手作業で作成する場合もある。

しかもこのような内容を、ひたすら一ヶ月間繰り返す場合もある。

コーディングよりは頭は使わなくても良いが(ほぼ単純作業の場合が多い)、はっきり言って考えただけでうんざりする。

この落差も、他業界にはなかなか見られない光景であると思う。
とてつもなく頭を使う一カ月間と、とてつもなく単調な作業の一ヶ月間・・・

このような単調作業を繰り返していると、たまにミスも起こす。

例えば
Aというボタンを押した後に
Bという選択肢からβを選択し、
その後Cというボタンを押す。
というテストケースがあった場合、間違って最後にDというボタンを押してしまう場合がある。

間違いに気付いた際、本来であれば一度戻ってAボタンを押すところからやりなおせば良いのだが、
「Dというボタンは実は、内部的には100件のデータを書き換える処理が入っており、Aからやり直すには、その100件を全て手作業で元にもどしてからテストをしないと意味が無い。」
という場合がある。(決して誇張では無い。よくある事だ。)

そのような場合、はっきり言ってとても面倒くさい。
やる気がいっきに削がれる。
思わず声に出して「うああああーーーー」とか言っちゃう。

ただ、このテストは既に似たような事を既にテスト済みで、ほんの少しだけパターンを変えてのテストだった場合。

そんなとき、とっても真面目では無い人(ほとんどの人が該当するだろう)は、
「テスト完了」にマルをして終わらせるだろう。
鋼鉄の意志でも持った人物でもない限りは。



4) 他人の担当箇所だからいいや
例えば自分の担当範囲であるコーディングをしていた際に、何かの拍子で別の担当者がコーディングしているソースを見るがある。

ふと目についたバグ。明らかにバグ

でもそれを作った担当者は自分が嫌いな奴だった。
もしくは良く知らない奴だった。

こんな時、たいていのプログラマーは無視する。
「まー、そいつの責任だからね」

その後、そのバグがシステム全体を停止させるに至り、
データリカバリーにチーム全員が徹夜を余儀なくさせる事を、彼はまだ知らない。



5) 後から気づく
作っていた当時は気づかなかったが、その後コーディングを終えてから気づくようなケースもある。

プログラマーはふと思い出すのである。
「あれ?あの時のあのコーディングって、よく考えたらマズくね?」

もしくは、数か月後にでも、自分自身の知識量が経験によって増えた時に
「あーあんときのコーディング方法は間違ってたなー。あのままじゃバグるなー」


まだ開発段階のものであればすぐに治してしまえば良いだけの事であるが、
既に納品を終えて稼働しているシステムだったりすると、そんな簡単な話ではなくなる。
ましてや、システムのソースを更新する際にサーバ再起動が発生するようなシステムであった場合は、なおさらである。

自分自身がサーバ管理者になっていれば、夜中に誰にもバレないようにコッソリ修正してしまう事もできるかもしれないが、
そのような立場では無い場合・・・
サーバのソースを入れ替えるには、リーダーに相談して、営業が客先に説明して・・・
客先の業務を数時間ストップして・・・
考えるだけでも胃が痛くなる。

そんなとき、たいていのプログラマーがとる行動は
「忘れよう。」



6) 誰も知らないかもしれない仕様
大きなシステムになればなるほど、仕様はより複雑になっていく。
担当者も、開発当初からの担当者が変更になっていたりすると、もう訳が分からなくなる。
担当者がいたとしても、開発したのが数年前だったりすると細かい箇所については、誰も覚えていなかったりする。
なんてシステムは日常茶飯事である。

このようなシステムの改修を行う場合、プログラマーは過去のプログラムとの壮絶な戦いを繰り広げる事を余儀なくされる。
作った人間もいない、仕様が明確に分かる人間もいない、資料も無い
となれば、頼れるのはシステムを動かしているソース、ただ一つである。

なんでこんな所でこんな事やってんだ?
なんでこんな所にこんな物があるんだ?

とめどない疑問と解決の繰り返しである。とてつもないストレスがかかる。

また、下手に修正を入れて、万が一システムが動かない状態になってしまうと自分の責任になってしまう。
「でもこのソース訳がわからん。」


しかし、修正を繰り返しているうちに
「以前はうまく動いていたけれども、ある修正を入れた事によって一部の機能が消えてしまった」
なんて事があったりする。

しかも、その機能を復元させようとすると、今度は自分が今回入れた修正がうまく動かなくなってしまう。
なんて、もう訳のわからない状態にすら陥ったりする事がある。

そこでプログラマーが気付いた。
でもこの機能、実は隠れ機能みたいな感じだし、ひょっとしたら誰も気づいていないのかもしれない・・・

そして、そっと封印する。


もしバレたら
「あーすみません、その機能、隠れ機能みたいな感じだし気づきませんでした」
って言おう。
分かりづらい機能だし、ちゃんと謝るし、きっと納得してくれるよね。


バレずに、そのまま自分が別の案件や現場に移動するまで逃げ切れれば
万事解決なのである。




番外) 極端に有能なプログラマー
これは上記までの嘘のパターンとは少々訳が違うパターンだ。

また、このような事が実際にできるプログラマーも私の知る限り、かなり少ない。
だが、まれにいる。

納期よりもかなり早い段階で実際には完成しているにも関わらず、
納期ギリギリになるまで「まだできていません」と発言するのだ。

この業界では能力が上と下の人間では、納品物完成までに30倍のスピード落差があると言われている。

つまり、とんでもない早さで、とんでもない効率的なコーディングができる人間が世の中にはいる。
これは一概には経験とは比例しておらず、若年プログラマーにも存在している。
もはや生まれもったものなのであろう。

管理者からしたら生唾ものの、とんでもなくたまらない人材であろう。
そして、能力の高い人間もそれは自覚している。

だから自己防衛をするのである。

仕事量の多い開発現場においては、早く自分の担当分を完了させた人間には
別の人間の作業を割り振る。

これには例外は無い。
まわりが残業まみれの状況で
「キミ、早く担当分が終わっているから早く帰っていいよ」
と言ってくれる管理者などまずいない。

管理者の立場からすれば当然であろう。

このような状況で割り振られる新たな作業とは、
出来の悪いプログラマーの手伝い(いわゆる「ケツ拭き」である。)であったり、難解な機能の実装を振られる場合が多い。

仮に、その作業を終えたとしても、待っているのは安息では無い。次のケツ拭きである。


30倍の効率格差を持ちながら、給料は大して変わらない。
ケツ拭きとは言え、担当する機能が増えればその分責任の範囲も広くなってしまう。

そのような作業を割り振られた有能な人間はどう思うだろう。
簡単な話である。
自分の担当分だけキチンとこなしたら、後は「終わっていない事」にするのだ。

あとは適当に回りにあわせて、ほどほどに残業し、
まわりにも「大変だよねー」とホラを吹いておけば、仕事面でも人間関係においてもバッチリである。

ただし、この嘘は
「自分の担当分を確実にスピーディーに終わらせる事の出来る人間」
であるという前提がつく。

そのため、仮に管理者や同僚であるあなたが気付いたとしても決して咎めてはならない。
稀であり貴重であり有能である人材なためである。



最後に

と、プログラマー以外の人がここまで読んだなら、こう思うだろう。
「おいふざけんなよ。社会人だろ?ちゃんと責任持って仕事しろよ」


また、プログラムを知らない名ばかりSEや、低能管理者・管理をするだけの自称ディレクター()などは
こう思うかもしれない。
「なるほど。では管理を徹底し、そのような秘密や嘘のないキチンとした体制を作ろう」

断言しよう。
本人達を縛るだけではプログラマーの秘密や嘘は決してなくならない。

どんなに進捗報告をマメにさせても、どんなにコードレビューを徹底させようとも
大した意味をなさないであろう。
いや、むしろ悪化するはずだ。


このような秘密や嘘が発生する一番の理由は、たいていの場合、その現場の体制にある。
プログラマーが隠し事をする一番のモチベーション
ストレスであり
・窮屈な環境であり
・疎遠な人間関係
なのである。


何度も繰り返すが、プログラムとはとてつもなく複雑な作業であり、
とてつもなくストレスを抱える作業なのである。
そのストレスに輪をかけてしまっては、本人達のパフォーマンスは低下の一途をたどるであろう。


最も効果的な方法はストレスを最小にするのである。
また、一人で仕事をしているような錯覚は持たないように最善の注意を払うべきである。

プログラマー同士のコミュニケーションが増えれば、秘密は自然に暴露されるだろうし、
そもそも秘密と化す前に、互いで解決策を模索するようになる。

また、解決策を模索できるだけの環境と時間も彼らには与える必要がある。


無理な納期や予算での仕事・プログラマーと同じ目線でリーダーシップのとれる人物のいない環境。
このような環境では秘密や嘘はひたすらに増えてしまう。
改善を目指すのであれば、この逆を行う必要がある。

ぼうSIやぼうSIや 2013/05/23 22:29 いいこと言うね
短い納期なくならねぇかなー

raisingheart0326raisingheart0326 2013/05/23 23:01 ひとつもあてはまらない事がない、
列挙されたケースは全部存在しますね。

kagehienskagehiens 2013/05/24 01:42 他の人の作りこんだバグについては本人に言うようにしています。言わないとみんなが不幸になるので。ご存じの通り、基本当人から感謝はされず、それどころか恨まれます。でも信念でやってます。他については全くおっしゃる通りww

646646 2013/05/24 05:11 でもやっぱり的を得るって誤用だと思うんだよね

555555 2013/05/24 09:21 共感!

匿名匿名 2013/05/24 10:03 だめプログラマーあるある

現在は管理者現在は管理者 2013/05/24 10:55 若い頃はこの通りでした。
納得です。

うりんうりん 2013/05/24 12:22 共感出来ます!けど、それを当たり前にしたくないですね!

1) 仕様があいまいな場合の適当なコーディング
「適当」ではなく「最善」だと自分が納得できるようにしよう。

2) 進捗報告
曖昧さを見越した管理をしよう。

3) 面倒な繰り返し作業やテスト
というのはコンピュータの得意分野なので自動化しよう。

4) 他人の担当箇所だからいいや
素直に当人に伝えよう。

5) 後から気づく
こればかりは仕方ないかも。

6) 誰も知らないかもしれない仕様
ドキュメントに残そう。

と、思いました。ぶっちゃけ感がいいですね。

岩嵜岩嵜 2013/05/24 12:22 個人でWEBサイトの作成をしています。
面白い記事ですね。
ニヤッとしてしまいました…。

tikaorihtikaorih 2013/05/24 12:53 番外) に、もう1タイプいたなぁ。
仕事を早く終わらせるまでは一緒。
で、「俺の責任は果たしたからこのプロジェクト終わるまではもう何もしないよ。ボランティアじゃないしね」ってデスマの中毎日定時で帰っていた強者。(#^.^#)

とおりすがりとおりすがり 2013/05/24 13:00 プログラマーの話じゃなくて、これはダメな人の話ですね

kaedekaede 2013/05/24 13:08 すごく、共感しました。
こういう事例が分かる方が周りに多くいて
気軽に話せる環境が欲しいです。。。
仕様がない案件をただ押しつけて帰る上司が
憎くてしかたない←
社内にひとり残ってひたすら打ち込み作業が苦痛。。。
いつのまにか手抜きになって、怒られることも多々…
職柄仕方ないのかなぁ…っと諦め

HiroHiro 2013/05/24 13:09 >プログラムとはとてつもなく複雑な作業であり、とてつもなくストレスを抱える作業なのである。
これ、大きな間違い。共感するプログラマは転職した方が良い。

とおりすがり2とおりすがり2 2013/05/24 16:02 この日記を読んだあとこの人の他の日記もみたらよっぽどひどい目にあってる感じがした。

hamahama 2013/05/24 17:03 >これ、大きな間違い。共感するプログラマは転職した方が良い。

プログラマは論理や理屈を扱う職業なので、「大きな間違い」だけ言ってその具体的根拠を言わない人は絶対的にプログラマには向かない。
日頃、キチンとした仕事をしているプログラマなら、根拠もなしに何か批判を書いていい気になるなんてことはない。
「大きな間違い」だけの発言に共感するプログラマは転職した方が良い。

かめかめ 2013/05/24 18:42 当てはまると思って読みすすめていた。改める必要も感じずに。

通りすがりのディレクター通りすがりのディレクター 2013/05/24 20:12 依頼する側の立場から見ても、あるあるある!!とニヤっとしてしまいました。基本私はSEPGに対してはやさしさと思いやりとレッドブルを持って接しています。

通りすがり3通りすがり3 2013/05/24 20:17 自分だけの正論かざして周りに打診しようとしない。自分がだめなだけじゃなくて周りにも無自覚に迷惑かけるタイプ。こういう人がいると職場の雰囲気悪くなって不機嫌になる。
PGなら何でも改善して必要なものは自分で作ればいいじゃん。

堕落者堕落者 2013/05/24 20:38 つ 車輪の再発明

binderbinder 2013/05/24 22:30 6を経験したことがあります。当時は逃げ切りました・・・。

ほげほげ 2013/05/25 02:07 ちょっと気になったので

>1) 仕様があいまいな場合の適当なコーディング
>「適当」ではなく「最善」だと自分が納得できるようにしよう。
そんな工数どこにあるの?

>2) 進捗報告
>曖昧さを見越した管理をしよう。
そんな工数どこにあるの?

>3) 面倒な繰り返し作業やテスト
>というのはコンピュータの得意分野なので自動化しよう。
「エビデンスを提出してください」

>4) 他人の担当箇所だからいいや
>素直に当人に伝えよう。
伝えられた当人は素直になってくれません。

>6) 誰も知らないかもしれない仕様
>ドキュメントに残そう。
そんな工数どこにあるの?

ちゃんとやると赤出るからどこかで抜かないとどうしようもないねん

ガジェット通信編集部ガジェット通信編集部 2013/05/29 21:19 はじめまして。ガジェット通信というウェブニュース媒体編集部です。
totopon114689様のブログ記事を弊社媒体に寄稿という形で転載させていただきたくご連絡申し上げました。
お手数ですがメールにて一度ご連絡いただけますでしょうか。

なお、弊社媒体のURLはhttp://getnews.jp/ になります。ご検討のほど何卒よろしくお願い申し上げます。

のんきのんき 2013/06/04 05:49 exciteニュースからきました。
小生 勤務医ですが、職種が違っても似たようなもんだな、と感じました。疾患により
標準的な治療プロトコルはあるわけですが、細かいところは個人の好みで、さらに夜間など
問題が起きた場合、当直医がそれぞれのスタイルで介入し、看護師さんからの意見やクレームもあったり
すると、結局、ぐちゃぐちゃのコーディングみたいな……。
で、わけわからん主治医のかわりに他の人がケツ拭きを…てなことに。
ま、そういうヒドイのはめったにないですけど。
でも今いる環境で前向きにやっていかねばならないわけだし、がんばりましょう

無能無能 2013/06/04 11:44 改善したいけど改善しようとすると余計なタスク増えるし、うまくいかなければマイナス評価だけになるしでやる気なんて出ないね。
職場では常に無能でありたい。

sonksonk 2013/06/12 12:18 面白いなぁー。あるあるすぎてww
本当の問題は、プログラマ個人にあるわけじゃなくて、
プロジェクト全体の問題ですよね。
こんなので問題が発生したときに、プロジェクト全体の問題を棚上げして、
個人を責めるようなチームがあるから困る

ff 2014/06/05 14:01 さすがに30倍もは速くないけど、
出来てるのに「出来てません」はよくある。
浮いた時間で趣味のプログラミングw

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

 |