みなさん「プログラマーの作ったバグは本人の責任になる」と考えておられるような気がしますが、 私はちょっと違うのではと思います。
人間、どんなに気をつけたとしてもミスは必ずします。したがってコーディングをすれば必ずバグが潜んでいます。それはプログラマーのやる気とか心掛けとかにかかわらず、バグは出る時には出るし、出ない時には出ません。それを個人の責任にして1人だけに徹夜させて修正させるのは、果たして効率的な解決法でしょうか？
プログラマーが複数人いるのならば、バグはお互いに発見し合い、お互いに修正し合う方が、プログラマー個人がプロジェクト全体を見渡せますし、他人の良い点悪い点から学ぶことも多いのではないでしょうか。何より相互協力関係が築けて良好なチームになると思うのですが。
PL/PMの方針次第でかなり改善できると思いますよ。
余談ですが、システム開発者というのは褒められない宿命にある職業です。銀行のATMシステムを作ったとしても、正常に動いたからってそれが当たり前で、誰も「1万円引き出せた！ すごいじゃん！」とか「操作しやすい素晴らしいUIのATMだ！」とか評価してくれません。逆に、数億件処理してるうちの1件でもエラーで止まってしまうと、み○ほ銀行のように、金融庁の偉ーい人から怒られてしまいます。
おもしろくない職業だからこそ、合理的で不満のない働き方を追求したいものです。（こんな職場で、昭和時代のサラリーマンのように上司にヘコヘコへつらいながら仕事なんて出来っかーボケェーーー！！！）（心の叫び）
日本だと、こんなもんです。基本、感謝される事はありません。嫌味を言われる事は多々あります。
アメリカでも、感謝はされません。
アメリカでは、80年代には、このようにプログラマに辛く当たる現象があったかもしれません。ですが、このような事があると、プログラマーはすぐにサボタージュに入ります。サボタージュに入ったり転職者が続出して倒産するソフト会社が出ていました。バグの責任の取り方などを見直しされたのが90年代です。
バグが出たテスト方法が、テストマトリクスに入っていれば、テストをしなかったQAの責任。テストマトリクスに入っていなければ、テストマトリクスを作成したマネージャの責任。どちらにしてもプログラマーの責任ではありません。という考えがアメリカでは普通になっています。
徹夜でバグを直すこと自体あり得ないです。
そんなバッドコンディションで、一人で何時間もかかるデバッグをして、ノーミスだなんて信じられます？
私は怖くて部下にそんな指示出せません。新しいバグが埋め込まれている可能性大です。本当にどうしても明日までに直さなければならない状況なら、複数人でモブプロするなり、テスト要員を何人か待機させるなりして対応しますが。一人に任せるのは絶対有り得ない。
ただ、もし納品前日にバグが発覚していたに関わらず、報告無しで勝手に直そうとしていたなら、それについては叱責すると思います。これは絶対にやめてほしい。
「こんなものか」というご質問ですが、あなたが置かれている立場によるのではないかと思います。これは経験上、だいたい2つに分かれる気がします。
体育会系ブラック開発企業ですと、まずまともにリソースを割り当ててくれません。テスト工程も押しなべて不十分です。担当者のスキルや工数と無関係に、上司や社長から「バグなんか出すなよおめぇ！」と凄まれ、どんなに無理な日程であってもバグを出そうものなら「おらぁ！」と怒られて、無条件で徹夜。ただし朝まで頑張っていたと認められたら「うんそれでいいんだ、よしよし」と頭をなでてくれるでしょう。「ああ、徹夜で頑張ってよかった」とつい思ってしまい、なぜかチームワークが高まったかのような大きな誤解が生まれる瞬間です。
エリート系ホワイト企業の場合、テストと修正のフェーズが工程にしっかりと組み込まれているので、仮に自責であっても徹夜なんかありません。期待に沿った働きであれば、そもそも徹夜は不要だし、バグを出しても怒られることもなければ、バグを出さなくても褒めてももらえません。ただしPMの想定を大幅に超えるような不具合を出し続け、標準的なバグ収束曲線と実態がかけ離れたりすると、徹夜してでも直せとは言われなくても周囲の目がとても冷たくなります。多分、次のプロジェクトには呼ばれないかもしれません。
さてご質問のような場合、いずれにも当てはまらないようです。徹夜で修正しなければならないようなバグが想定外に発生したということは由々しき問題ですが、それは仮にあなたの担当部分で発生したものであっても、あなただけの責任ではありません。仕様や設計などの上流工程に問題があったのかもしれませんし、ピアレビューしてくれた同僚は何をしてたんだって話にもなります。それらを無視してあなただけに責任を押し付ける開発体制がおかしいとも言えます。
「誰でも初めのうちはバグが多いし、苦労が尽きないけど、歯を食いしばって続けていくうちに何とかなっていくもんだよ」というのは昭和から平成初期くらいまでの話でしょう。その時代を経験して実際何とかなったので全否定はしませんが、いまどきそんな話は通用しません。バグを出して徹夜を強いられるようなことにならないためには「食いきれないジョブは口から吐き出す」しかありません。周囲に何と言われようと早めに自分からSOSを出してみてはどうでしょう。
つらすぎる！
プログラマはこんなもの、な人もいると思います。そういう態度取られた時、私もありました。仕事する意欲なくなります。
メンバーが互いが互いで「バグ修正に時間がかかってしまったから徹夜で苦労するのは当然だ」という思いやりの姿勢がないチームだといろいろギスギスしてつらいです。
バグを出したくて出す人もほぼいないわけで、スキルが無くて仕事に投入されてしまう場合もあるでしょうから、ねぎらいとか普通の人間関係として欲しいですよね。
大抵の人は周りの人達と協力してくれる人ですが、たまに一部少数の周りの人を蹴落として自分だけがよければいいという人も中にはいます。
多くの人は思いやりがあって優しい人でありたいとは思っていても、実際の仕事が忙しかったり、相手のミスの尻拭いさせられて苦しかったりすると、その思いやりとか周りへの優しさとかの度合いが減ってきたりもします。人によって、すごい優しい人と全く優しくない人の度合いが違います。
それでも優しさや思いやりを保ちつづけて周りとよい関係性を持てる人、そういうのを心がけられる人になっていきたいと思ってます。
他の人もそうだったらいいな、と思うとしたら、自分が率先してやっていってもいいでしょうね。
自分や周りの人に非協力的な人とはなるべく距離をあけておき、自分や周りの人に協力的な度合いが高い人の近くで仕事できるように周りの環境を整えていくと、仕事がやりやすくなりますよ。
何日も休日出社してもボーナス0円査定だった『100日後に退職する47歳』のTwitter漫画を思い出しました。
いいえ。
約10年ソフトウェア開発者をしていますが徹夜で作業しないといけなかったことはないです。仲のいい友人からそのようなことを聞いたこともありません。またTwitterで「いま徹夜で作業中」というツイートがばんばん目に入ってくるということもありません（とりあえず記憶がないです）。
したがっておっしゃる状況は「普通ではない」と認識しております。
是非うちに来てください。私が優しい言葉でねぎらいますので！ただ募集をかけるのは今年度は無理で、早くても来年度になりますが(^^;。
というか、滅多なことでは徹夜はさせられませんので、その状況にはなりませんが、日常業務でバグを直していたただいたのなら、直ってよかった、お疲れ様でした、と言いますよ。
不幸な上司に当たって心中お察しします。ただそういう理不尽な経験も自分を強くする材料に出来れば、将来その上司に感謝することさえ出来るかも知れません。大変難しいことで自分で出来るかどうかはわかりませんが、私も過去には理不尽なことがさんざんありましたが、今はまあそんなことも経験だなぁ、と思えるようになりましたし、そんな理不尽なことは部下にはさせたくないなぁ、って思いますし、本当に辛かったけど、乗り越えた自分を褒めてやりたいし、まあ学ぶこともなかったことはなかったな、と思います。
多分、プログラマーじゃなくても失敗に対してそういう事ってあると思います。上司次第なだけで業界は関係ないと思います。
バグを出さないように努力して徹夜しなくても、「徹夜して頑張ってる人もいるのに」と批判されます。どちらかと言えば徹夜している方が評価されがちです。（どっちが酷いかと言うような話で「評価」というのも変ですが）
昔いた職場で、バグだらけで連日会社に泊まり込んでいるプログラマがいて聴くと一か月家に帰ってない、マスターアップが半年遅れている、バグを取れ切れる目途が立っていないという無限地獄のような状態でした。更には会社はそのプログラマが「サボらないように」後ろに人を張り付かせたりして余計なプレッシャーをかけて精神的にも追い込んでいました。明らかに技術不足で解決するわけがないのに無暗に追い込んで成長の機会も潰している。見かねて手を貸し一月ほどで収束させてリリースの目途を付けました。が後で社長が言うには「連日徹夜いたそいつ（助けてやった奴）を見習え」とまさかの叱責をうけました。似たようなことが続き面倒なので言われたら黙って徹夜するようになりました。
徹夜しないといけないような納期ギリギリまで発覚しないややこしいバグが残るというデスマーチ現場ですから、ユーザーさんもイラついて嫌な態度を取ることは十分にあり得ることです。おそらくバグも一つや二つではないと予想します。下流工程は辛いですね。
バグの内容によるんじゃないですかね。
単なるタイプミスで起きたのか、仕様を勘違いして起きたのかだけでもそのバグの意味する内容は全然違いますし、類似例を洗い出す必要性も違ってくるでしょう。
「バグ」として一緒くたに出来るような事例は多くないと思います。
どういうシチュエーションなのかにも依りますね。
プログラムの作成を依頼したのが上司なら、作成する人間の技量とかを勘案すれば、どういう種類のバグを埋め込みそうなのかはある程度想像がつくはずだし、それを未然に防ぐアドバイスをするのも、作業指示をする立場のものとしては当然なことではありますが、教育的観点からしてみれば、「バグを出せば後で苦労する」という体験をさせておくのが必要ということもあるでしょう。
まあ、徹夜しないと直せないようなバグなら指導者が一言声をかけておけば避けられたバグなのではないかと思いますけれど…
「苦労して直したのだから、優しい言葉をかけられる程度の報酬は欲しい」と思った事は自分にもあります。ただ、自分が仕込んでしまったバグを直して厳しい態度を取られ、辛いと思っているのなら、以下を一度考えてみてください。
- 設計やコーディングの前工程で適当にやっていたのが原因でバグ発生。
- バグが発覚した時点で本気出して直す。
- そしたら周囲に褒められる
これで褒められたら、褒められるために失敗をしこむ「マッチポンプ」ができますよね。バグを作って褒められるっておかしくないですか？
残念ながら指摘した人の言うとおり、事前にバグを出さないように努力するのが正しいと思います。こんな事を意識してみてはどうでしょうか？
- 資料でも仕様書でもデータでも、自分以外から何か受領したら、それに問題がないか細かく確認しましょう。
- 自分の中で不明点がないか、自分の今後の行動を具体的に想像して確認しましょう。
- メンバーとの情報共有にズレがないか意識しつつ、雑談でもいいので話しましょう。思いっきり常識レベルが違う事もあります。
きっと、優しい言葉をかけられるのは、あなたが「正しく」成長した時です。
私ならそんな理解のない組織即やめます。
開発はバグとの戦いですよ。
一つ金言をさずけるとしたら、
ヤバいやつ、組織を変えようと思ってはダメ、正解は関わるな、です。
もし、あなたが上司好みの絶世の美女だったらその上司は「バグを出すことが問題で直すのが当然」と同じセリフを吐いたでしょうか？（あなたが魅力的ではないと言っているのではありませんよ！）
おそらく違うはずです。もう少し優しい言葉がを掛けたはずです。
あなたがプログラマー以外の職についていたとして、ミスを修正したとしても、同じ上司が相手なら「ミスをしないのが当たり前」と同じような言葉をかけられると思います。
つまり、職は関係ないということです。
でも、辛い気持ちはよくわかります。私もたまにハラワタが煮えくり返ることがあります。と同時にすごく落ち込みます。「なんで上司に褒められら事を期待してるんだ」って褒めてもらえることを前提としている自分が情けなくなります。
お互い頑張りましょう！
違います。
酷い話です。
おおよそプログラミングとは関係のない人としての思いやりの問題です。
頑張った人には「お疲れ様」というのが人としての礼儀であり思いやりです。
プログラマーって、コミュニケーションが下手という印象があるのでもしかするとこれが標準？と思われたのかもしれませんが、再度はっきり言います。
違います。
日本におけるプログラマーなら、 大抵の人は「お疲れ様」と言います。
「徹夜するのが当然」という発言の意図は前後がないのでよくわかりませんが、それはただ自分を大きく見せたいだけの人間が自分なら徹夜余裕だと強調したいつまらない発言です。
本当に連日徹夜の経験をした事のある自分に言わせれば、徹夜しても品質が極端に落ちるだけで良いことなどありません。
本当に修羅場を経験した事のある人はそんな発言はしません。
バグは罪ではありません。開発初期に一定数でるもので、見つかれば直せばいいんです。それだけです。特に、凡ミスというのは、恥じることなどなく、早い段階で見つかって良かったという事です。
むしろ、バグが無いという状況は非常に危ういです。十分に動かしていないということです。
徹夜で治すかどうかは、まぁ、個人のプライド問題ですね。評価を得るためではなく、自分を納得させるためです。
バグなんかよりも深刻なのが、そもそも、作りが悪いというやつです。これは、バグ修正どころではありません。根本的に作り直しの羽目になります。これは経験が長い人でも、センスの悪い人がよくやらかす、最悪の出来事です。
いいじゃないですか、これで一つ、品質が上がったのですから。
新人プログラマー（社内でバグが酷いと問題視されている）
→納期前日にハングアップ級のバグを出す
→先輩全員協力して問題箇所の修正にあたるがコードが酷過ぎて本人以外手がつけられない。苛立つオフィス
…
新人『僕もう帰ってもいいですか？』
（この話はノンフィクションです）
思いません。ただし、それを主張するためには若干の作業と努力が必要です。
まず、「バグが多い」という言葉には２つの内容が含まれています。両方かもしれないし、片方かもしれません（この短い文章からでは判断できません）。
１つは、きちんとプログラムが動かないというもの。プログラム自体の機能不全。
もう１つは、仕様の解釈違い。
明日までに直せるものなのか、仕様の解釈について確認を上司なり先輩なり、その業務を指示している人と仕様書をもとに確認すべきでしょう。もし、仕様書が存在しないとか担当部分について仕様が明文化されていない場合には、手書きでもよいのでプログラムの処理内容を図で起こして確認すべきです。
そのうえで、バグを修正することになるわけですが、きっちり仕様書をもとに作業量を見積もり、明日までに直せるものなのか、もっと膨大な作業が発生するから「明日まで」という期限自体が無意味なのかがその場でわかるのではないでしょうか。
開発プロジェクトにおけるどういう局面でその話が出ているのかわかりませんが、進むべきゴール地点（仕様書）があやふやな状態では正しい方向に進むことは無理でしょう。「明日まで」という判断を行なった人物と、仕様書をもとに協議を行い、それが現実的かどうかを相談すべきでしょう。
仕様書を元に協議して、問題点や進むべき正しい道筋をつければ、仕事を指示している側の不安も解消されることでしょう。そのうえで、徹夜してもゴール地点まで届かないとか、効率が悪くなるといった話をすべきです。
プロジェクトの管理を行う側にも50％は原因があるわけなので、管理を行なっている側にそういう無茶なスケジュール管理では無理だという話を（仕様的な問題点をクリアした上で）すべきでしょう。
プロジェクト管理側の管理も甘く、そのうえで徹夜を強制するというのはどだい無茶な話なので（きょうび滅多に聞きません）、作業を行う側だけに責任を問われるのは無茶だという話に持っていきたいところです。
相手に「叱られている」最中という状況かもしれませんが、ここは一歩引いて客観的な立場から俯瞰して判断できないといけません。もし、相手とそういう話がしづらいと感じた場合には第三者をまじえて話をするのもよいでしょう。
労務管理の面から見て、妥当な指示ではないと考えますが、この話の前後の出来事や質問者のスキルや立場など、判断を行ううえで必要な情報がまるごと抜けているので、100％質問者に同情するという立場はとれません。
納期に対して今の状況が、本当に明日までに直さなければならない状況なのであって、明日までに直せという命令を受けたのであれば、基本的にはよほどの事情がない限りは従業員は受ける必要があります。ただしそれは正当な残業手当や深夜勤務手当が出て、翌日の勤務間インターバルを確保されるという前提のもとでなければなりません。
ただ、実際徹夜をすれば直せる分量である見込みがあるかないか、は冷静に上司と話し合う必要があると思います。絶対にできもしないことを意気込みだけで強制的にやらせるのは、ハラスメントに相当する可能性があります。
また納期に余裕があるのにも関わらずそのような命令が出るのは、ハラスメントに相当する可能性があります。ご質問者様の書くプログラムにバグが多いことの懲罰の意味で徹夜をさせてよいかどうかは微妙です。
むしろそのシーンでは徹夜を怒る方が多いと思います
ただしょうがなく徹夜になることはありますが
その人は普通にブラック人材です、IT関係なく
これは統計で見ればすぐ分かります
仕事はみんなそんなものでしょう、
「出来て当たり前」「トラブルは自分で直せ」
それで出来ないなら周りを巻き込んで何とかする。
自分が実力や運でエラくなれたら、やさしい言葉を掛ける人になりましょう。
そのバグがどういったレベルのものかはわかりませんが、バグはあるものです。
状況によりけりなので、徹夜して修正することもあるかもしれませんが、労いの言葉は欲しいですね。
バグではありませんでしたが、障害の復旧で三徹明けの夕方に上長から今日は大潮だから夜釣りに行くぞ！って言われて先輩と後輩数名と一緒に夜釣りに行ったことがあります。
釣果はまあそれなりでしたが、あり得ないくらい眠かったですね。
ちょっと質問者さんの気持ちを考えないことを言ってみますが。
バグを出すことが問題で徹夜してでも直す
この部分を細かく点数わけしたら、こうなったかも知れないな、と思います。
- バグを作った … -1：好ましくない（ただし完全に避けることはできない）
- バグを見つけた … +1：バグが利用者に実影響を与える前に取り除く機会を作った
- バグを直した … +2：バグが利用者に実影響を与える前に取り除いた、品質の高い成果物ができた
- 徹夜した … -3：品質問題を起こしやすい状況で作業をした、労務管理上の問題がある、コスト上の問題がある
トータルすると-1。「当然だ」ではないのですが、「誉めるわけにはいかない」「繰り返させてはいけない」という態度だとしたら、そうかもしれないなと。
「徹夜した」がなかったら、誉められるべきだと思います。もしバグが小さいうちに見つけられていたり、複雑なバグを生みにくい実装にできていたら。その結果、簡単に直せて、定時内にコスト影響も小さく直せていたら。ちゃんとした開発現場なら、バグ検出とバグ修正の工数と期間もある程度設定されているだろうから、そこに収まっていたら。それはもう手放しで誉められたのでは、とか。
言うだけなら簡単だし、徹夜の尽力がなかったらバグ含みで出荷されたか納期が何日もずれ込んだのにという功績はあるのだし、納得できるかというと難しいですけどね。もしその態度に意味があるとしたら、こんなところかなと考えました。
私自身は「Bugは必ず出るもの」とは考えません。
徹夜でDeBugする状況は異常です。DeBugの時間は夜間ではなく正当に確保されるべきです。そして、Bugばかり出し続ける人はプログラマには向いていないと思います。
Bugが多いとテストデータの抜けで、そのままスルーしてしまうリスクがあります。プロのプログラマの仕事は、担当する責任分野において100%完全なプログラムを書く事です。そのためのDeBugはもちろん必要でしょうが、徹夜でDeBugする状況では何かが間違っています。
仮にプログラミングの能力が無ければ、1日に20行や30行を確実に書く事です。それが許されるかどうかは別の話です。500行や1000行を量産して、その中に2つや3つバグがあるけど仕方がない……ではダメだと考えます。そういう事をして徹夜でDeBugしてるなら、その当人に責任があります。
質問者様が置かれている環境を私は知るよしもありませんが、あちこちにBugばかり書いては徹夜でDeBugしている部下がいれば、私ならキレます。「徹夜でバグを直した」事が褒められるかどうか、私には何とも言えませんが、それが当人に起因するなら「優しい言葉」などかける気は起きないでしょう。
私自身は、大学時代にプログラムを書くセンスは個人差が大きいと実感して、自分にはそのセンスが皆無だと知った訳です。ぶっちゃけ、プログラミングのセンスを持つ者は10人に1人もいないと思います。こう書くと非難されそうですが、高卒で知能レベルが達していない人はほとんどプログラマに向かないだろうと考えています。パズルをスラスラ解くようなロジカルな方面での地頭の良さが必要です。
プログラミングのセンスを持つ人は、Bugをあまり出しません。
世間一般に、コードが書ければ誰でもプログラマだと考える風潮ですが、コードが書けてもBugばかり出すようでは、向いていないのです。
他の方の回答で米国の例が示されています。私も同感です。感謝する／しないの話ではない。仕事を任されたならBugを出さない事に専念するし、プログラミングの能力が無い人には仕事が与えられません。チーム全体で成果（＝Bugゼロ）を出そうとするなら、自ずとそうなります。
日本のソフトウェア業界が、世界の同業と比較して職業として貧しいのは、生来がプログラマに向かない人を手厚く厚遇しているからだと思います。変な例えですが、小中学校で勉強が不得意な子にクラスの授業レベルを合わすのに似ています。
もう一度書きます。「Bugは必ず出るもの」と考えているのでは、日本のプログラミング業界はいつまでも貧しいままでしょう。
うーーーん。Bugに関しては「やる気とか心がけ」とかの、そういう問題ではないと思いますよ。わざわざことさらに精神論を否定する立ち位置からして不思議なんですよ。他の回答者が書かれている通り、医師や料理人が手違いしたから修正してそれでOKか？という話に精神論は無関係ですよね。プロなら最初から100点満点かせめて及第点でないとダメで、プログラミングだとBugがあれば0点ですよ。
試験や受験前に追い込みで勉強していたら、家族から優しく声をかけられた。それと同じことを期待していた、という感じでしょうか。
締め切りに間に合うかどうかの仕事だと仮定すると、そんなことを期待してするのは無理がありますね、プログラマーでなくても。たとえ声をかけられても、何も解決しないから時間の無駄です。そんなことより、的確な解決方法を探るとか、応援者を見つけて相談しながら進める状況にするとかして欲しいと思いますね、私なら。
僕は正確にはプログラマではありせんが、友人には多々いますし僕は類似商売であるウェブマーケ屋です。
プログラマだけでなく、一般不条理なことは多いですし報われないことばかりです
直して当然、徹夜当然の体質の会社なら、いくらそのことを言ったところで状況変化はありません
コロナでどうなるかは？ですが幸いにもプログラマは転職の道は多々あります。くさらず自分のやったことをきっちりエビデンスを取り、スキル向上に勤めればステップアップの道はあると思います。
どういう立ち位置にいる人が、どのような状況で言われたのかがわからないのですが…
私のこれまで働いてきたプロジェクトでは、グループの上の立ち位置になればなるほど、お疲れ様とかけてくれるような気がします。
上に行けば行くほど、様々な人が集まってプロジェクトが動いており、大概の人は頑張っていることも分かっているし、メンバだって人だから間違いがあることも分かっている。
だからこそ、間違いなどのミスにより、問題が大きくなった際、リーダーはそれに対して、様々な手を打ちつつ、その問題が解消したときは、プロジェクトをまた進めていく意味でお疲れ様という一言があると思います。
逆に同じ立ち位置の同僚とかサブリーダーあたりだと、そういう感じになるかもしれません。自分の領分をやるのは当たり前という感じになるのかなと。
なので、もし、あなた自身が優しい言葉をかけてほしいのであれば、あなた自身がプロジェクトの周囲をみて、自分の状況と周りの状況を確認してください。
そうすると周囲の人あっての自分というのが見えてくると思います。
そのように感じることができれば、あなた自身が周囲の人に的確なタイミングで優しい言葉をかけることができると思います。それは巡り巡って、あなたに帰ってくるのではと感じました。
医者だったらどうですか？
手術にミスがあって患者の容態が悪化しました。徹夜で再手術して容態が落ち着きました。そのお医者様は褒められますか？
命がかかってるので極端すぎる？
では大工さんだったらどうですか？
施工にミスがあり雨漏りが酷い。雨漏りのせいで家具が台無しに。
徹夜で雨漏りを直しました。その大工さんは褒められますか？
飲食店だったらどうですか？
調理にミスがあり味がしょっぱすぎて食べれたもんじゃない。すぐに作り直しました。この料理人は褒められますか？
プログラマの世界だけキツいわけじゃないと思いますよ？
はい。そういうものです。
なので、プログラマーは30代になってみんな潰れていきます。脳溢血で死んだり、自殺したりが当たり前の世界です。こんな仕事する奴の気が知れませんね。
現在のプログラミング言語の多くでは、What (何をやってるか) と How (どういう風にやってるか) は表現可能ですが、Why (何故そういう風にやってるか) は表現できません。
コードで表現し得ないものは、コメントで表現します。
例.
- コードだけで、並べ替えてることは分かり得るが、何故並べ替えてるかは分かり得ない。
- time.sleep(5) というコードで、5秒待ってることは分かり得るが、何故5秒待ってるかは分かり得ない。
まず次のスクリプトを見せます。
time.sleep(5)
「意味がわかりますか？」と聞きます。たぶん「5秒待つんですよね」と返ってきます。
そうしたら「違います」と答えて、このコメント付きのスクリプトを見せます。
# これは顧客から「動作が遅い」と言われたときにここを1減らし1秒減らす。1秒高速化するごとに顧客から100万円獲得できる
time.sleep(5)
その後「なんでこれがわからなかったんですか」と聞きます。
何か言われたら、相手の理論をそのまま使って反論します。
追記:
# 顧客軽視のコメントについて違和感を感じた場合: これはredditで少し話題になったブラックジョークを使った、コメントの重要性を示唆するトイコードです。そして、悪いコード/品質の良くないコードの実例・悪い初心者を装うこと・なぜコメントが必要なのかを意味しています。実際の製品では顧客に害を与えるような実装は当然すべきではないです。単にそれだけのために5秒待たせるのであれば、それは不必要な実装なので、実際の現場では絶対に使うべきではありません。この点は例としてやや不適切であると思います。なので、似たようなことをよりうまく表現できれば、そちらの方がより良いと思います。あくまで「コメントの重要性」についてスコープを絞った一例と考えていただけると幸いです。
# これは顧客から「動作が遅い」と言われたときにここを1減らし1秒減らす。1秒高速化するごとに顧客から100万円獲得できる
time.sleep(5)
この逆パターンですかね。面倒なコメントにウンザリしましたが。
自分ならこうです。
- 読めるコードが書けていないなら「そんなこと言う前に読めるコード書け」
- 読めるコードが書けているなら「せやな。でも読んで分からないときは聞くし、コメントだけ付けるPull Request投げるけどいいよね」
でいいかと。言い方は考えますし、説明はしますが。
詳しく解説します。
まず「読めるコード」であることは大前提です。コメントたくさん付けてても意味不明なコードを書く素人は論外です。ここは異論ないでしょう。
その上で「スラスラ読めるコード」かどうかはチームによります。自分と相手(後輩)、そして他の開発者が読めるかどうかです(コードが読めないプロジェクトマネージャが何言っても寝言なので無視してください)。
話を簡潔にするために自分と後輩だけにしますが、後輩はスラスラ読めるはずなので(3ヶ月後には読めないかもですが)、自分がスラスラ読めるかが重要です。
スラスラ読めれば一旦はOKです。スラスラ読めないなら本人に聞きます。そしてコードに反映します。
何度かやっていると引っかかりやすい箇所が見えてきます。もっと読みやすいコードを書く、そこに絞ってコメントをつける、規約にする、どれでもいいですが、チームで合意を取ることが重要です。
逆にコメントを消すのは基本的にやりません。i++に対して「iを1足す」のように全く意味ないコメントを書かないようには指導しますが。
実際のところ、熟練者でも見解が分かれることは少なくありません。コメントもその一つです。
また、コードをうまく書いていれば、コメントは不要であるというのは神話（広く信じられているが正しくないこと）です。
上述のように、入出力のデータ構造などは表現できるが、何を意図したのかやその結果の意味などのコンテキスト、それがどのような条件下で呼ばれるかなどはコメントでしか表現できないからです。
これをみて、2冊並行で読んでまだ途中だけど、A Philosophy ~ chap4でClassitis が批判されていて、Clean Craftsmanship 第6章で小さく優れた関数をたくさん抽出しろって言っててすでに混乱している。 https://t.co/gyyA8orvk5
— zuckey ずっきー (@zuckey_17) October 22, 2022
どちらの見解が正しいというわけではないなら必要なのは「受容」と「対話」です。だから「せやな」です。逆に一番やってはいけないのは「論破」です。
一方で完全にスキル不足にも関わらず素人判断をする人にははっきりノーと伝える必要があります。それが「そんなこと言う前に読めるコード書け」です。
安心してください。世の中には２種類の人がいます。
プログラムが書ける人と書けない人です。
あなたはプログラムが書ける人（プログラマー）です。
後は自分用のサンプルソース（逆引き事典）を作りましょう。こうしたいときにはこういうコードを使うという小さな動いたコードをメモっておくやつです。ブログなどを使うと検索が楽でいいですね。
そうすれば早く組めるようになります。
だいたい早く組めるというのは自分がかつて組んだことがあるからなんですよ。
実際に自分が使っている言語用の「逆引き事典」を買って、自習しておくといいかも知れませんね。
どの言語でも必ず「逆引き事典」はあります。ネット上で公開されているかも知れません。
そういうのを覚えていけばプログラムを書く時間は早くなりますよ。
… (もっと読む)
一度書いたソースコードを捨てて、もう一度書いてみると1週間かかったものが数日、ないしは1日以内でできるのではないでしょうか？！
答えを見て最適化するのと、一から答えを作っていくのはかかる時間が違います。また、プログラムは製造ではなく設計書を書いてるのだと言う言説があります。コードを書くスピードではなく、設計書を書くための設計に悩んでいたのかもしれません。
あと、意外と一からプログラムを作れる人はレアな人材である可能性があります。1週間かけるプレッシャーに萎える人がいるみたいなんですよね。時間をかけてでも、ちゃんとした品質のコードを自分で作り上げたのであれば、それはメンタル面では素晴らしいプログラマーだとも言えます。あとは経験を積んで、設計力を上げればスピードアップできると思います。決断力のための経験を積みましょう
まぁ思ってるかもしれませんが、気にしない事です。
だって彼は先輩なんですから、貴方と同じ位の時間で作っていたら、洒落にならないですし。
それに貴方と同じ位の頃に2〜3時間で作れていたわけではないと思いますよ。経験を数多く踏んで今の速さがあるんだと思います。
ただちょっとに気になることがあります。同期間働いてる他の方の速度はどうなのか？他の方は2〜3日で仕上げてるんだとすれば、貴方が倍時間掛かってる事になり、向いてないんじゃないかと言われかねません。
しかもその先輩プログラマー曰く、時間掛かってるのに「これはやばくない？」と言ってるわけですから、プログラムの出来も良くなかったのではないでしょうか？時間が掛かる事は百歩譲り、出来が悪いものを作るのはまずいです。求める結果を出せないプログラムなんて、あっても意味がないですからね。
冒頭では気にするなとお伝えしていますが、やっぱり気にした方がいいです。
まず仕様を正しく把握しているか、どういう動きであるべきか、ちゃんと仕様書を作ってから始めた方が良いですよ。急がば回れというやつで、一見遠回りなようで実はこれが堅実で近道だったりします。
最近の方はこれ無しに作る方が多いと聞きます。もう慣れてしっかり作れる自信が出来てからならまだしも、今はぜひ仕様書書きからスタートし、要件定義をしっかりまとめて、フローチャートをしっかり作り、この時点でバグがない事を良くシミュレーションしましょう。
慣れてないのにこれを端折ると、右往左往したプログラムを書く事になります。いわゆるバグの多いプログラムというわけです。
慣れてしまえば、この仕様書を一気に脳内でイメージでき、プログラムに落とすことができるようになるので短時間作成も可能になってくるのです。
プログラマーの心理として、「バグ」とは仕様に沿わないプログラムの挙動であり、そのような点を指摘されたならば彼・彼女らはきっと素直に間違いを認め、修正を申し出ることでしょう。
例えば単純な自動運転のプログラムを書くとして、「赤信号では止まり、発進しない」という「要求」を実現する時、「カメラの探知圏内に赤信号が認識された場合、赤信号フラグを立てる」という仕様を書き、「赤信号フラグがある場合、速度が０より上だったらアクセルをオフ、ブレーキをオンにする。速度が０以下の場合はブレーキをオンで保持し、他からもたらされるアクセルオン要求は無視する」という仕様で実現を試みたとします。
この架空の自動運転車を、一本道で、信号が一つしかないところでテストするとおそらく要求を満たすでしょう。しかし、信号が二つ見える通りでは、手前の信号以外でも止まってしまうでしょうし、歩車分離の交差点では、歩行者信号の赤でやっぱり止まってしまうかもしれません。
これは明らかに「要求」を満たさないプログラムですが、「仕様」は満たしています。
プログラマーにとって、バグとは恥ずべきものであり、完全なる自分のミスです。しかし発注者側の人はもっと広い意味でバグという言葉を使いがちで、そこが誤解の源泉なのでしょう。プログラマーとは仕様をコンピューターが理解できる形に変換するプロであって、あなたが解決したいと思っている問題や業務のプロではな
… (もっと読む)
金物屋が、「肉を切れる性能の包丁」を納品したら
顧客「指を切ってしまった、指を切れるなんて聞いていない、明らかな欠陥だ！」
って言われた時に欠陥だと認めて信頼関係を築くべきかって話ですね？
さらに言えば、
顧客「切れすぎるのがいけないんだ、つべこべ言わずに、指を切れない性能に直せ」
技術者「わかりました、指を切れない性能にします」
：
：
顧客「肉が切れないじゃないか、明らかな欠陥だ！」
って言われても？
プログラムに限った話じゃないんですけど、
なぜかプログラムの場合だけ「聞く耳を持たずに感情で意思決定してしまう顧客」が多いような気がします。
どのような立ち位置から見ているか、相手の目線で考えられるかによると思います。
通常、よりユーザーに近い立ち位置で「バグ」という言葉の範囲が拡大していく傾向にあります。
おおむね次のような感じでしょうか。
- ユーザー目線では仕様に関係なく思ったように動かなければバグです。
- エンジニア目線では仕様書に書いてなくても一般常識に照らし合わせて誤りがあればバグです。
- プログラマー目線では仕様書に書いてある通りに動作しなければバグです。
あなたはどの位置から見て「明らかなバグ」と判断したのでしょうか？
(質問のタイトルから推測するにプログラマー以外だと思っていますが。)
ある程度以上のレベルに達しているプログラマーなら、
- 仕様書に書いてなくても一般常識の範囲で必要なものは実装してくれるでしょう。
- 仕様が間違っていたり漏れていたりするなら指摘して改善案を出してくれるでしょう。
- 要件や議事録からユーザーの意図まで汲み取ってあなたに教えてくれるかもしれません。
あなたがユーザーなら
- 過不足なく要件を伝えられているでしょうか？
- 問題が出ることを伝えられたのに(費用面で)妥協しなかったでしょうか？
- 要求が膨れ上がったのに納期は元のままとしなかったでしょうか？
- 仕様のレビューでただ頷いていただけではなかったですか？
あなたがエンジニアなら
- 仕様書にちゃんと書いてありますか？
- 仕様は正しいですか？
- プログラマーから指摘されませんでしたか？
- ユーザーに
すっごく似たようなシチュエーションを体験したことがあります。
個人的には非常に興味深い学びを得ましたので回答に自分語りも含めて書きます。
あるプロジェクトに参加したときに、そこのプロジェクトは急ぎすぎて開発しバグだらけで頓挫して数年放置されていたそうですが、それを復帰させるために人が集められたときに自分がプロジェクトに参加しました。
どうも以前作った人は誰かコンサルかなにかの人が「技術力がある」「すごい人」として評価されていた会社の社長とメンバーが作ったんだけど、うまくいかなかったそうです。
コードはなかなか凄まじい酷さでした。
React/JSのプログラムだったのですが、ちょっと専門的なことを簡単に書いておくと
- Reactのstate管理でイミュータブルとミュータブルの概念が全くない人が書いたコードがどんどんコピペされていてAPIレスポンスがはやかったりおそかったりすることによって時々バグになるという恐ろしいコードがちりばめられていました。常にうまくいくならよく、常にうまくいかないのなら、それでもまだよいのですが、時々不具合を起こすというのは再現させるのが大変で原因をみつけるのも大変なので解決困難なバグになってしまったりします。
- Reactの使い方を間違っていて、その間違っていることを他の場所でなんとかしようとしているために、元の間違っているものを直すと逆にバグが出るということが頻発していました。
- アプリケーションの根幹に複数のイベントが登録できるような.NETっぽいイベントデリゲートの仕組みを独自で構築しているわりに、登録されているイベントは1つでイベントになっている意味がないコードでした、自分たちの新しいチームの人は1年かけても誰も一切そこのコードの複雑さがわからず手が出なくて放置していたのですが、私が「なんかおかしい」と思って数日かけて調べた上で、その不要なイベントデリゲートを全部削除しました。
もっとあったのですが、主に覚えているものを書きました。
Gitのコミットログに幾人かの名前が出ていまして、今はもういないプロジェクトの人たちの名前なんですが、特定のやつの名前が出てくると現在のチームのメンバーには「こいつのコードはひどいから疑ったほうがいいよ」というくらいの、幾人かのやばいコード書く人たちがみれました。
今の開発チームの人たちも、新人君みたいな人も協力会社から参加していたので、スキルもピンキリだったので、たくさんたくさん指導しながら仕事してました。私もそんなにReact得意とはいえなかったのですが、Reactを非常に素早く学び、他のメンバーのスキルを底上げしてプロジェクト復帰に力をそそいでました。
そのプロジェクトに接して半年かそこらかかりわかってきたのですが、昔の人が作ったコードであってもスキルが足りて無いメンバーの書くコードというのは、それほど「邪悪」じゃないんですよね。
そもそもスキルがないから動くか動かないかもわからないような変なミスもあるんですが、スキルがないだけで、間違ったことを書いている、ある命令を知っていればそうはかかない、みたいなことが見えてきて、それは人として素直に理解できますし、簡単にコード改善できるんですよ。
あー、この命令しらないだけだね。書き直しちゃおう。ということが簡単です。
「邪悪」なのは、スキルがあるっぽいのに、雑に、あるいは故意にプログラムをひどく書いている、という奴らがいる、ということです。
これがわかったのは個人的にはとてもよい学びでした。
「やばい奴」と目星つけた人のことなんですが、こういう人たちはスキルがない、とは到底思えないくらい非常に複雑なコードを書いていました。スキルはあるんですよね、そいつらは。そして、そのコードがあえて複雑にしてあるために、何書いているか、よほどのスキルレベルがないと解読も難しい、という状況にされていました。
その以前いた「すごい人」として評価されていて「技術力がある」という触れ込みの会社の社長とか、そこのメンバーのひとりとかは、意図して複雑怪奇なコードを書いているんじゃないかと、疑うような要素がいくつもありました。
ソースコードがぐちゃぐちゃでひどく読みにくく、命名とかだけじゃなくて、ほんとうになんでここにこんなデザインパターンみたいな馬鹿なコード書いているわけ？イベントデリゲートなんかで実装せずに単に関数呼び出ししろよ、みたいな感じだったりして、実際にイベントデリゲートを消して関数呼び出しに変えたら何かまずいことが起きるんじゃないのか、と疑いながらそういうスパゲティコードを解きほぐしていって、きれいに直ってから初めて、「なんだ単純に書いてもなんの問題もないんじゃないか」と気がつけました。
本当のところ、そういう「すごい人」が、悪意をもって他の人に読めなくするためにコード書いていたのかはわかりません。
状況証拠だけです。
こんな複雑なことを書く奴が「スキルがない」わけはない。そして、こんな複雑なことをする必要は全くなかったということがスパゲティコードをときほぐして初めてわかった、ということです。
私の推測なのですが、
コードがひどいからこそ、自分たちしかメンテナンスできないコードになるから他の人や会社に仕事を切り替えられないようにして自分たちに独占して継続して仕事をもらえる、という戦略なのかもしれない、んだなと理解しました。
いやあーーーーーーー、引き継いだ私としては、とんでもない話ですよ。
非常に苦労させられました。ある機能を追加するために大体1日とか2日くらいでできるという場面があったとしますが、そういう時でも元がひどいコードなら、それを直さないとその機能が追加できなくて、それには余分に1週間かかる、とかが普通だったりして、それゆえに仕事が遅いみたいな感じをうけて大変でした。
100画面とかは簡単に超えるようなWebシステムでしたが、最初から作り直したほうがよほどまし、と何度も感じながら苦しい場面をずっと1年以上行い、リファクタリングをしまくりました。
技術者はどんどん抜けていきますし、若い人たちからは「この現場が初めてなんですが、けっこう苦しいのですが、この現場ってほかと比べてひどい環境なんでしょうか？」とか聞かれるし、かなりよいスキルをもった人が入ってきたんですが「話が違いすぎる。ありえないぐちゃぐちゃなコードだ」と憤って1ヶ月でやめていくし、
私も外注なので、ひどかろうとなんだろうと知ったことじゃないわー。逃げ出したいなー。と思うこともあったのですが、まあ、成長の機会としてとらえてがんばってみました。
で、
私とか、あと数人のフロントエンドの人たちと、その倍いたサーバーサイドの人たちのこつこつとして丁寧な仕事によって、見事にプロジェクトはリリースされました。ちょっと問題はあったんですが、すぐに修正したりしてなんとか乗り切りました。数ヶ月で安定稼働していけました。
で、
リリース後、安定した収入を確保できたらしく、高額な開発費、つまり、開発メンバーの人件費はいらなくなったみたいだったので、自分や他の開発メンバーもどんどん契約終了になってプロジェクトは終わってしまいました。
まだやれることはあったのですが、契約終わってしまったので仕方ないか、まあ、忙しいこともなくなったし、という感じです。
私なんかは常に「誰もが改良しやすい、わかりやすいコード」を意識してコード書くので、そういう地道な仕事は「すごい人」とか「技術力がある」とかはみなされていなかった様子というか、わかってもらえなかった感じはします。
でも、個人的によかったのは
このプロジェクトで、非常にReactに精通するほど鍛えられたというか、勝手に自分で鍛えたので十分な自信がつきました。
あと世間様の評価ってめちゃくちゃあてにならねーな、ということも学びました。
なにせ、私から見たらろくでもないコードで、他の人が触れないくらい「すごく(ひどい)」コードが「技術力がある」という評価だったわけですから、笑えるというかなんというか、
「技術力がある」という評価の人たちが、こいつら二流以下じゃねーか、という感想です。
私が書く、誰もが触りやすくわかりやすく改良しやすく、機能追加しやすく、わかりやすいから不具合があってもすぐにみつかる、直しやすい、という状況を作ることが、その「技術力がある」と評される会社の技術力よりも、数倍上を行っているということは他者にはわからないかもしれませんが、自分がわかります。
もう、俺って日本で一番すごい一流の技術者なのでは？みたいに思えるわけです。(実際にはそう思うほどに厚顔無知じゃないので、まあ、そういう気持ちになるってことだけですよ)
ビジネス戦略的には仕事の継続はなくなったので、「邪悪さ」を備えておけば、もう少し仕事を継続できたかもーーー、というヨコシマな考えがよぎらなくもないですが、
そういうダークサイドに堕ちるエンジニアは到底一流とはいえないよな、と思って、そういうダークサイドには決して堕ちないで一流のよい仕事をしたいなと思って、誰もが改造しやすいわかりやすいコードを書くように心がけています。
長々書きましたが、つまり何がいいたいかというと
「わざと」悪い方向にコードを書く、それなりに「すぐれた」(と見せかける)人達はいて、コードを読めない人たちからすると、それなりに優れているようにみえるけど、
本当に物事がわかっている人がある程度時間をかけて見抜けば、そういう人たちの、悪い悪行がばれるので、やめておいたほうがいいんじゃないのかな、と思うということですかね。
「プログラマー集団と謳われている」とかいうのは、マーケティングの結果としてうまい具合に噂話で作らせているのもあり、それもビジネスとしては上手な事なんですが、本当の実力に応じた評価とか報酬体系とかってなかなか難しいもので、
受注側視点でみても、技術者の腕を見抜くのは難しいよな、と思ったりします。
という個人的な学びの多いプロジェクトでしたとさ。
追記：
下記回答も参考になるかも。また別のプロジェクトのときのお話。
仕事場でちょっと変わった方と出会えば出会うほどにネタが増えてありがたいかも。
より細かな追記。
このプロジェクトのひどい実装について、さらに思い出したので書いておきます。雑なわけわかんない内容だと思うので、上に列挙はしないようにしました。
- Reduxのアプリに1つの状態管理みたいなものと同じようなものとして、EventMgという関数を保持したオブジェクトが、全ての子コンポーネントに配布される仕組みになっていたのですが「このMgってマネージャーの略ですかねえ…」と当時のプログラマみんなよくわからないものがありました。このイベントマネージャー(?)のおかげで、特定画面のsubmitが全く別な箇所で実装されていて呼び出されていて、どこの何によって何段階上位層で関数が定義されているかさっぱりわからないことになっていました。正直、全部が同じEventMgなのか、あるいは特定のページ範囲で共通のEventMgが複数あるのかもわからない状態でした。EventMgをEventManagerに名前変更しようにも、どこまでを名前変更したら正しいのかわからないから名前も変えられないという有様。なんでこんなので改良できるのか、って思うかもしれませんが、当時の自分たちも、なんでこんなので動いているのかすらわからない、というコード郡でした。
- 行ごとに親子関係がある凝ったデザインの表があって無限スクロールまでは作られていてそれはよく出来ているなと思っていたのですが、1行あたり4つのAPIを呼び出すように作られていて、たった30行のデータを表示するために120回もAPIコールされるようになっていました。何十人か同時アクセスしたら単に1画面をみるために120x何十のAPIアクセスがあり、無限スクロールでグリグリ60,90,120とかのデータを取得したらいきなりサーバー落ちるんじゃないかとヒヤヒヤしてました。120回のものを減らして数API呼び出しに変更したり、API側も修正お願いしたりでした。
大企業にいたプログラマーほど勘違いしがちなのですが、社長兼プログラマーの創業者はあえて意図的にそのような開発をしています。
私も同じ立場であればプロダクトが本稼働するまでは同じ方法をあえて選択します。もちろん単体テストも統合テストも、CICDも、docstringも、型指定も能力的に書けますがあえてこのフェーズでは書きません。
速くて汚いコードは「負債」です。創業時は「負債」で時間を買い、事業スピードを加速させます。
すると目に見えるプロダクトが出来、ユーザーヒアリングを集める事ができ、金になる事が証明できます。あとはそれまでにかかった「負債」を投資家から調達したお金で返済します。
おそらく今あなたがいる会社はこのフェーズです。0から雇用を生み出し、革新的なプロダクトだからこそのプログラマー集団なのでしょう。ちなみにスタートアップにとっては開発<<マーケティングです。人に知って貰えばお金が手に入るし、事業の仕組みが出来上がります。
その意味で「有能なプログラマー集団」というマーケティングができているこの会社は、私から見ると全てが上手くいっているように感じます。
良くあることだと思います。
誤解を恐れず、やや皮肉を込めて言えば、私が回答者さんから受注したら「バクだらけの、ろくに動かないプログラム」を納品する自信はすごくあります。
ものすごく持ち上げていたかと思うと、わけのわからない教条的な考えにそってこき下ろす人はこの業界はとても多いですが、どういう基準にそって誰がどのように評価したのか、バグや不具合とどのように判断したのかが明快になってなければそれはただのノイズです。
わけのわからない凶暴な切れ方をする顧客や顧客候補はとても多いので、売り込みの上手い、プログラミングの会社の隠れた専門は、高い期待を裏切られたこの種の係争を上手に扱うこと、わけのわからない質の低い顧客をライバルに差し上げることです。
モンスタークライアントを抱えるリスクは甚大です。
業界では有名なモンスタークライアントだったという情報もあります。両者ともシステムと関係ないコンプライアンスの報道があります。割と根が深い組織的な問題があったのかもしれないです。
良く引き合いに出されるインターネットのミーム画像です。
請負でソフトウェアを開発するってすごく難しく、滅多に満足いくものは納品できないし、そのくせやたらと期待は高く、潜在的には需要はいくらでもあるから、営業と
… (もっと読む)
この画像を貼れと言われた気がしました。バグを0にする努力より、バグを恐れず、問題をすぐ発見し、それに機動的に対応する準備を。
甘くないと思います。
システム開発ってとても高価です。ちゃんと作るのは高いのですよね。
庭は庭師に頼まなければいけない！ってなってる人もいますけど、DIYで良くない？って思ってる人もいます。
どうしてって、会社にはコンピューターシステム以外の部分もあって、それは外注せずに社員がやってるけど、どう見たって業務システム全体の作りの緩さから言って、ITだけお金をかけても仕方がないのですよね。そりゃ会社によっては全体が引き締まってて堅固な会社もありますけど、ゆるゆるでも回ってることもあるのです。
他の部分と同程度のゆるさにするためには、同じ組織になればいいのです。無謬性より業務全体が回るかどうか、どこにバグはあってはいけないのか、有限のリソースとできそこないのプログラマーをどう使えばいいのか、そういうのは社内の人なら必死にがんばるわけです。あんまりピリピリしすぎて委縮させると何もできないので、失敗に対するケアも大事です。
なので、どこかのシステム部に入って「社内で内製の開発しません？」ということを持ち出せば、割といけるのではないかと思います。
スマホゲーでそれをやると大爆死です。今も数多にリリースされるゲームですが、これって最初の半年で開発費を回収し以後は利益を出しながら次のゲームの開発を進めるというスパンで動いているそうです。なのでスタートダッシュで躓くといつまで経っても開発費を回収できなくなります。FGOを開発したディライトワークスとセガが組んで30億円以上の開発費をかけて制作した「サクラ革命」もスタートダッシュに失敗し半年も経たずにサービス終了まで追い込まれました。バグというよりあまりにコンテンツが少ないというか、我々ユーザーが求めていたクオリティに達していなかったですね。
最近でもリリースされたは良いけれどバグや不具合でメンテが頻発したりするゲームからユーザーはどんどん離れていきます。気楽にやるのはかまわないのですが、それは他に競合が無いサービスでの話です。ライバルがひしめき合うレッドオーシャンでその姿勢でやれば、妙齢の女性にまた星が一つ消えたよとつぶやく男の子の姿をみることになりますね…_(:3 」∠)_
私の個人的なお気に入りです。
人気のトゥームレイダーゲーム「ララ・クロフト」は誰もが覚えていますよね？ララについて何か印象的なことを覚えていますか？
彼女は明らかに巨乳だったのです！（お願いですから変態呼ばわりしないでください）。
以下に要点を纏めました:
彼女の女の子らしい体型にテスト調整をしていた時、デザイナーはマウスの操作を誤ってしまい50%増の予定だったバストサイズが150%増になってしまいました。
おかしなことに、他のチームメンバーも彼の行動を見ていました。
彼がCtrl + Zをする前に、チームからは直ぐにこのままでいいという承認が得られました。
変態とは正にこのことですね。
… (もっと読む)
IBM 3278を開発中に技術者たちは、ある重大なバグに直面しました。
データをダウンロードしたり、同様の重いプロセスを実行したりすると（当時ダウンロードはかなり重い処理でした）、端末/デバイスのアクティビティインジケータが点滅し続けます。
このバグは問題と利点の両方を兼ね備えていました。
問題は、本来そのようなことが起こるはずではなかったということです。それに対して利点は、重い処理が行われているという事をユーザーに表示できるようになったことです。
このバグは今日においても身近にみることができます。
ゲームボーイで発売された最初期のRPG「魔界塔士SaGa」のラスボス「かみ」。
- HPが低くなるにつれて激化する攻撃「かみのひだりて」「フレア」
- 回数制限があるとはいえ、HP完全回復「ふっかつ」（ドラクエIIのシドーも似たような仕様で有名ですが、そちらと比べると、このかみは味方の攻撃力に対するHPの割合がケタ違いに高いため、脅威度は更に上）
設定上は全てを創造した「唯一神」とも呼ぶべき存在で、ゲームシステムでも上記のように、正攻法で戦うとかなり強いボスですが、「チェーンソー」というアイテムを使うとなんと一撃死します。
RPGをやったことのある方ならお分かりと思いますが、通常はラスボスに一撃死の攻撃が通用するなんてことはまずありません。正攻法で「強い」とされるようなボスなら猶更です。内部的なフラグで一律はじく(ボスフラグ等と言われる)事が多いのですが、この「かみ」についてはそのフラグが建っていなかったようです。
実際、次回作の「SaGa2秘宝伝説」のラスボスにはチェーンソーは効きません。
しかしながら、余程インパクトが強くてウケが良かったからなのか、当初こそバグだったこの「チェーンソーで即死」は、後に別の機種でリメイクされた時には目出度く仕様に昇格した模様。
まあ面白くてなんぼの世界ですからね。ゲーム。
プログラマーは、一番働いている人が、一番バグを出します。
何もかいていない成果を出さない人なら不具合だしません。
落ち込む時「自分はなんてだめなんだ」と混乱して思うかもしれませんが、それを「いや、自分はちゃんとできる。少し失敗しただけだ。今までやってきたんじゃないか」という気持ちに切り替えるには
もっともっと多くの成果をだして挽回する経験を積み重ねる事だと思います。
いろいろ経験しましたよ。バグで直接契約終了というのはなかったと思いますが、余計なことをいったから仕事を失ったり、変なやつがいたので争ったら仕事失ったり、下手くそなコード書くやつのを大きくリファクタリングしたからって嫉妬されて1ヶ月の私の仕事成果を全部なかったことにされたりとか。
間違ってバージョンダウンさせちゃったりもありましたね。青ざめながらも復旧を助けてもらいながらやりました。
そういう時もそうじゃない時も、できることをしようと思って仕事してます。
だから、経験をもっと積むために今の経験を、自分が起き上がるために役立てるかんじで、頑張って！
日々の鍛錬こそ、鋼のメンタルの道やで。
「この結果がおかしいんです。多分このあたりが原因だと思うんですが、良く分からないんです。見て頂けませんか？」とお願いするんです。
すると先輩が、「お、これおかしいな。バグ見つけたわ。」
と言います。すかさず
「さすが先輩です！ありがとうございます！」
と言いましょう。
要するに、あなたがバグを見つけたことを黙ってて、先輩が見つけるように誘導すればいいだけです。
こんなに上手くはいかない？（似たような回答ありますね・・・）
デプロイ前に、「こんな動作しますけど、私はバグじゃないと思います、でも後学のために教えていただけませんか？」とか何とか言って、先輩が、「見せろ、なんだこんなのバグに決まってるじゃないか」と見つけさせたところ、「さすが先輩ですね！判断力、尊敬します。」などと言って良い気分にさせます。
要は言い方です。
悪い情報も早ければ良い情報になります。
自分の失敗を報告する時にそう思っています。
悪い情報を貰って不機嫌になるその先輩は余りよくありませんね。次から悪い情報が入らなくなります。
この質問は悪い情報でも早ければ良い情報になる、それを喜ばないとどうなるかという良い例だと思います。
質問者はその先輩を反面教師として自分の役に立てると良いと思いますよ。
「一定以上調べた上で分からない」という前提で答えます。ログとかデバッガとか一通りやったということにしておきます。
- 他の人に助けを求める
- ワークアラウンドを実装する。代替実装でお茶を濁す。効率の悪い解でお茶を濁す。自分が詳しくない経路を通らない実装（グリーンレットで起こるならスレッドで諦める、Kernelの特定のシステムコールに起因するなら諦めてユーザランドで処理できないか、枯れたシステムコールだけで出来ないか考える）
- バグがある経路を通ってバグったことを検出したら代替経路を通る、両方通して結果が不一致なら云々とかやる
- コメントに「わからん」と書く。Issueへのリンクでも貼って、Issueに細かい症状と原因が分からない部分を書く
- 発生する仮説をいくつか立て、仮説を補強するような現象を観測したらログに吐く等の処理を行う
- 普段の情報網で関連するトピックを観測する
- 関連する最新トピックの本を学ぶ。基礎に戻る（動画関連のバグならcodecのしくみに立ち返る、分散処理ならば分散コンピューティングの勉強をしなおす、アルゴリズム上のバグなら関連するアルゴリズムについて勉強したりする）
- 原因に帰着するような情報が見つかったり、自分で原因を理解したらワークアラウンド等を戻して正しい修正にする
「原因が分からない」には「かなりレアな条件で発生するハードウェアレベルの問題」から「未熟故に生じるバグ」まであらゆる可能性があります。最悪、宇宙線の類で起きたものであるとすれば「知らん。core i7じゃなくてせめてまともなXeonとECCメモリ使え」で突っぱねるしかなかったりするかもしれません。
とはいえ「プログラムがバグを起こしている原因が分からない」とあるわけですから、バグは適度な頻度で発生しておりでも原因を探しても見つからない、ということなのでしょう。すると、問題を解決するのに必要な「知らないパーツ」がある可能性を疑うことになるのだと思います。
ゆっくり時間をかけられるのなら周辺分野をじっくりサーベイするのが良いと思いますが仕事ならばワークアラウンドでまず「絆創膏を貼って」おきその場をしのぎ、ただしそういう状態であることを忘れないようにする、といった手も必要かもしれません。
分野が専門的であれば人に聞くしかない、ということもあるでしょう。まだスタンダードにすらなっていない最新の暗号アルゴリズムを自前で実装してみたが動作しない、とかいうときには、そのあたりの数学が強い人と一緒にあーだこーだする必要があるかもしれません。いなければ苦労して数学勉強してリトライとか……（脱線しますが、その場合は動作しているように見えてもレビューは欲しいですねぇ……。セキュアであるかのチェックが必要なので）
ログを突っ込みまくって色々白状させて流れを見る。適宜ブレイクポイントやステップ実行をする。特別なダンプを仕込んでスナップショットを取って追い詰める。昼寝する。バグを確実に起こす条件の仮説を立ててやってみる。起きない。散歩する。別の仮説を試す。起きない。ご飯食べに行く。また別の仮説を試す。だめ。寝る。さらに別の仮説。バグ再現！仮説の条件を絞っていく。これ以上絞れないところまで来る。あとは直すだけ。
5つほど回答をみましたが、まだ、無かったので。。
バグを再現できている時点で、90％勝ってますね。1個前のリビジョンに戻して確認していって、バグがおきなくなるリビジョンを見つけたら、その次の差分が原因です。何か心当たりがあるなら、10個いっぺんに戻したりしてもいいですね.
その差分が巨大すぎて結局わからないとか、差分を読めない、おかしいはずがない。というようなときは、もっと戻っていくと良いです。どんどん戻っていって、何もなかった状態まで戻るまでのどこかの地点で、問題が見つかるでしょう。
以上のような作業を後ですることを考えながら、差分を小さい単位でコミットしておくのがコツです。
0 コメント:
コメントを投稿