PCでスマフォをUSB充電したら仕事をクビになった


まず俺の話ではなく全く関係ない人間の話なんだけど、注意喚起としてメールが回ってきた。
その話聞いてちょっと違うんじゃない?と思ったのでちょっと書いてみる。

そのクビになった技術者がいる現場では、どうやらPCにスマフォをつなげてはいけないというルールになっていたそうで、それを破ってPCのUSB端子でスマフォを充電しちゃってた。それがみつかってクビになったらしい。ルールを破ったのだからクビになっても仕方がない。それは正論。でもね、ちょっとまって。二つの観点からちょっと違うんじゃない?と思ったことがあるので順に書いてみるよ。

まず「セキュリティルール」という観点から。

セキュリティルールってのは「守る」ためにある。つまり、まっとうに働く人(社員やパートナー含め)を守り、企業の情報(=企業の資産)を守りるためにあるわけで、人間を罰するためのものじゃない。言い換えると、セキュリティルールってのは「ルールを守らせる」のが目的ではなく、被害を防ぐことが目的なわけだ。今回の件では、ルール違反は見つかったが、本来の目的は侵されていない。つまり、「被害は無かった」わけ。でも被害が発生する可能性のあるセキュリティルール上の違反が見つかった。しかも、過失はあるが、故意でルール違反を犯したわけでもない(「普段の癖でやっちゃった」らしい、それもちょっとアホすぎるけど)。それをいきなり当事者をクビにして「ハイ終わり」ってのはセキュリティ運用上どうなのかなと思った。

セキュリティルールってのは状況に応じてどんどん変更されるべきものだ。守るべき対象がどんどん変わっていくのでルールも変わっていく。さらにルール上の問題が見つかったらそれに合わせてルールを変えるか運用を変えていく。今回の件で言えば、ルール違反が発生して、それが重大な問題であると認識したのであれば、ルールを変更するか、運用を変えるべきじゃないのか?(=技術的な対策を打つ、なども含め)

ルール違反者を見つけ出し、それを切り捨てて、それでセキュリティが守られると思っているようならそれは大きな間違いだ。現状でルール違反者が発生する可能性があって、それが重大な損害の発生につながる可能性がある判断したのであれば(重大な問題が発生すると判断したからクビにしたんだよね)、次のルール違反者が出現する可能性も十分にあり、それが損害に発展する可能性も十分にある。それってまったくセキュリティリスクをケアできていないよね。

もうひとつは「雇用者(=管理者)」という観点。

損害が発生していない過失を見つけたからといってその過失者をクビにするのは雇用者としてどおなのかなとも思う。企業活動上でヒューマンエラーなんていたるところで起こっている。例えば、メンドくさくて手順通りにやらなかった、でも問題はなかった。これと今回の「PCでスマフォ充電しちゃった」問題と何が違うの?前者はお説教ですんで、後者はクビなわけ?

企業活動上、ヒューマンエラーが発見された場合には原因を明らかにして今後ヒューマンエラーが起こらないようになにかしらの「対策を打つ」というのが常識だ。そこには、ヒューマンエラーを起こした人間を罰する、というのは含まれない(別途で損害賠償という責任追及手段をとる場合はあるけど)。一般的な常識と今回の問題を照らし合わせれば、うっかり「PCのUSB端子でスマフォを充電」しちゃわないように対策を講じるか、うっかり「PCのUSB端子でスマフォを充電」しても問題ないようにするのが順当な考え方だ。逆に「PCのUSB端子でスマフォを充電」しちゃった人間をクビにするのはちょっと常識から外れている。

ってな感じで、「PCのUSB端子でスマフォを充電したらクビになっちった、テヘペロ」的なメールにとっても違和感だらけだったので書きなぐってみました。お粗末。

「バグのないプログラムを書け」はできるんじゃない?


プログラムのわからないえらい人「バグのないプログラムを書くことはできないのか?難しいかもしれないが、十分に気を付けていれば防げるのではないか?」にどう返したらいいのかわからない

http://anond.hatelabo.jp/20170214114736

バグは人のミスなんだから、理屈的には正しいような気がする

だけど未だかつて人類はこれを達成できていないという観測的事実がある、何故そうなるのかを説明することは可能だろうか

ふと思ったんだけど、この増田さんが言われた「バグのないプログラムを書け」はできるんじゃない?

ゼロにはできないけど、限りなくバグの少ないシステムは作れると思うよ。理論的にはね。

でもね、問題がある。

「バグが限りなく少ないプログラムを書く」ためには膨大なコストと時間がかかる。

システム構築ってのは必ず予算と工期が決まっている。

だから100万円でシステムをつくるのに、1000万円かけて「バグが限りなく少ないプログラム」は作れないし、1ヵ月の工期に1年もかけていられない。

100万円のシステムを1ヵ月で作るのに1000万円かけて1年もの時間を費やしていいのなら「バグが限りなく少ないプログラム」は作れるんじゃないかな。

その「プログラムのわからないエロい人」に言ってみたらいいよ。「予算と工期を最低でも10倍用意したらできるかもよ」と。加えて「それでもやるか?」と。

それでもゼロにはならないから、世の中のシステム障害ってのものが後を絶たないのだけどね。

ロリとエルフと魔法少女と自衛隊の「GATE(ゲート) 自衛隊 彼の地にて、斯く戦えり」が面白い


「GATE(ゲート) 自衛隊 彼の地にて、斯く戦えり」を一気見した。結論から言うととても面白かった。ストーリーは美少女系萌えファンタジーと戦国自衛隊を足して2で割った感じ。前者は「推して知る」ような萌えをこれでもかと詰め込んできて、もうお腹いっぱいだよママン的なものだけど、後者が非常によくできていた。原作者が陸自出身(おそらくメディックだと思われる)なのと、陸自が全面協力しているためか、細かいところがかなりリアルにできている。兵器類や用語などがかなり忠実に描かれていて、ミリ系ファンだったり自衛隊ファンであれば非常にグッとくる場面が盛りだくさんだ。それだけでも見る価値は十分ある。加えて映画「地獄の黙示禄」のパロディ場面があったり、たぶん原作者もアニメ監督もミリ系好きなんだろうなぁと非常に好感が持てた。

ただ・・・・ちょっと気になるのは・・・自衛隊が先制攻撃でバンバン人を殺してるのよね・・・・いちおう自衛隊は建前とはいえ軍隊ではなく専守防衛の組織のはずなんだけど・・・例えば、他国の内ゲバに陸自が介入して、片方を一方的に蹂躙するのはいかがなものかと。。。いくら異世界という設定だとしても政治的優位に立つという理由で大っぴらに先制攻撃していいものなのかね。ってか陸自が監修しちゃってるんだけど、これ防衛省的にOKだったのかね?っと小一時間。

ボソッ・・・youtubeで全話見れちゃうんだよね・・・

PHPerはワープアまっしぐら。PHPerの単価が月60万~とかありえない。


そもそもPHPerの単価が月60万~とかありえない。

「フリーランスエンジニアが知るべき、PHP案件のトレンド、特徴、単価相場とは」
https://freelance.potepan.com/blogs/1685.html
より引用

~前略~

フリーのエンジニアが受け取る報酬の相場は一般的にプログラマで「40~60万」、システムエンジニアで「60~80万」と言われています。もちろんスキルや時間によりますが、一般的にはPHPですと相場は月60〜高い方で90万ほどです。

~後略~

この記事についてモノ申したい。

PHPが短期開発に向いているのは正しいが、それはPHPが規模の小さいシステム開発に向いているという理由がある。1人ないし2人という小規模でチャチャっと作ってしまうようなシステム開発でPHPは非常に大きな力を発揮する。そういう小規模なシステムだけに予算自体も少ない。大きなシステムほど成功すれば大きな利益が得られるが、システム規模が小さくなれば利益も少なくなり、自ずとシステム開発予算も小さくなる。

PHP案件は予算200万以下という案件が圧倒的に多い(比べてJava案件は億規模がゴロゴロある)。これに原価60%だと計算すると120万になる。これがエンジニアに支払われる金額となる。予算200万の規模だと工数は延べ2~3人月ぐらいが良いところだろう。工数がかかりすぎだと思うだろうか?これに要件定義や設計期間、運用テストなども含まれていると仮定すると、妥当な数値だ。単純に120万を3で割っても一人当たり40万だ。上流工程で月40万とかはありえないので、マネジメントをする上流SEだけ月60万と計算すると、コーダーに支払われるのは一人当たり30万となる。この計算、発注者と受注者の間にウワマエを刎ねるハイエナ会社(管理費、口座貸費用などの名目でウワマエを刎ねる)が一切いないことを前提に話している(つまり商流が1段)。ハイエナがいればそれだけ技術者に流れる金も少なくなる。

次にPHPは比較的に習得が容易だ(PHPフレームワークなども含め)。つまりPHPerはたくさんいる。技術者がたくさんいれば相場は自ずと下がる。さらに高度な技術者は単価の低いPHP案件など受けない(Java案件などの単価の高い案件にいく)から、PHP案件しか受けられない技術レベルの低い(=単価を安くせざろうえない)技術者しかいない。結果、案件争奪戦はダンピング合戦となり、PHPer=低単価が決定される。結果、高いレベルの技術者は余計にPHPからはなれていく。ここ7~8年ぐらいこの負の連鎖が続いた。これがPHPerのエンジニアリングサービス(技術者派遣)の実情だ。ぶっちゃけて、Javaなら月60万から、PHPなら月30万から、と買い手と売り手の双方で価格相場が形成されている。PHPerがこれを超えて単価を勝ち取るにはPHPコーディング以外の付加価値が必要となる。

ではそもそもPHPで予算規模の大きなシステムはあるのか?あるにはある。しかし全体からすればごくごくわずかで、しかも首都圏に限られる。もちろんそこには高レベルの技術者が集まってくる(Javaでバリバリ稼いでいるけど、PHPが好き、などの場違いな高段者)。あなたはそこで彼らと肩を並べる自信はあるだろうか?

ではなぜPHP案件で予算規模の大きなシステム開発案件がないのか?それは大手システム開発会社が関わっているからだ。大きな予算がついているということは失敗が許されない。つまりリスクをちゃんとヘッジしてくれる大手システム会社にまず話が持ち込まれる。そういう大手はよっぽどのことがない限りPHPなど絶対に使わない。かならずJavaが提案される。

さらに、エンジニアリングサービスにも地域格差というものがある。関西(主に大阪)は首都圏(主に東京)に比べて単価が80~70%と思っていい。東京での単価60万が大阪なら48万に、東京での単価40万は大阪だと32万になる。「SEなら東京にいけ」というのはこういうところからも来ている(そもそも案件数が首都圏は関西の2倍以上あるというのが主な理由ではある)。

つまり、金を稼ぎたいなら、PHPではなくJavaをやれ、というのが結論だ。というか常識と言っても過言ではない。

冒頭サイトで

PHPの場合はなにしろ開発需要が大きく、求人案件数も多いため、フリーランスの皆さんも多くの案件から自分に合ったものを選ぶことができます。

とあるが、この文章の後ろには「単価(給料)を選ばなければ」という一文が隠れていることを声を大にして言いたい。PHPの仕事は腐るほどあるのだ。だが誰が見てもワープアまっしぐら。あるていど会社組織の体を成している組織(社員を抱えていて食わせていかなければならない組織)では、その単価の安さから受けることができない(受けたら赤字確定だから)。したがってPHP案件は常時人不足。そこが辛うじて現在の単価を維持しているカラクリだ。

このままだと、PHPがあまりにも悲しいのでPHPの優れている点もあげていく。
(技術的に、ではなく、ビジネスとして、という観点から)

PHPはJavaに比べて圧倒的に「安く」作れる。PHPはあらゆるコストがJavaに比べてとても低いのだ。つまり同規模のシステムであれば、Javaに比べPHPのほうが1/10の金額で作れる。これは予算が限られている顧客にとって最大のメリットとなる。したがって、我々のような極小規模のインディペンデント会社が、技術者を売るのではなく、システム開発の全体像から提案して受託開発の受注を狙う場合は、PHPで提案することにより顧客に刺さる可能性が飛躍的に高まる。さらにインフラ周りや改修などの運用コストも低く抑えられるので提案力が出てくる。つまり、起業するとかフリーランスでシステム開発受託を狙う場合、大手と差別化をはかるという意味でPHPは大きな武器となる。逆に、前述に戻るが、末端技術者としてPHP案件に従事するというのであれば、経済的にジリ貧以外のなにものでもない。ワープアまっしぐらだ。「それでもPHPが好き」というのであれば別だが・・・

三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみた


三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみたのでその内容を書いてみる。まだワンタイムパスワードの申し込みをしていない方は参考にしてほしい。

三菱東京UFJ銀行のワンタイムパスワードについてサポートに電話してみた

スマフォアプリでワンタイムパスワードを生成する方法と、ジャパンネットバンクや三井住友銀行のようなパスワード発行機(カード型)を使う方法の二種類選べる。

スマフォアプリでは、1口座しかワンタイムパスワードを生成できない。たとえば、UFJで個人口座と事業口座を持っている場合、スマフォアプリではどちらか一方の口座しかワンタイムパスワードを生成できない。一つの端末でどちらか一方の口座しかワンタイムパスワードを生成できない。

アプリで初回登録時(※初回のみ必要で一回設定すればよく、ワンタイムパスワードの生成のたびに必要ではない)に設定用番号なる番号が必要で、その番号の取得は、毎日8:00~21:00、1日3回までと制限されている(※つまり、無理やり1端末で複数口座を運用する方法の障害となる)

一度申し込んだ後にカードからアプリ、もしくは逆にアプリからカードへの変更が可能である。

カードからアプリへ切り替える場合は即日だが、アプリからカードへ切り替える場合は郵送期間も含めて10日前後かかる。

アプリの場合はインストールしたアプリから、カードを申し込む場合はネットから申し込んでほしい。

IT系でよく使う「経営者」「マネージャ」「ディレクタ」「プロデューサ」というチョット意味不明な役職を「戦争」に例えて説明する


説明をスタートする前に、戦争において「戦術」と「戦略」の違いをご存じだろうか?とりあえずウィキペディアの「戦術と戦略」ご覧いただきたい。

以下「ウィキペディア – 戦術 – 戦術と戦略」項より抜粋

戦略と戦術を明確に区分分けする事は出来ないが、概念上は区分されるべきものである。戦略は戦役全体での勝利を収める為に指導する術策であり、[32]戦術は戦場において実際に敵に勝利するために戦闘部隊を指揮統制する術策である。つまり戦略は大局的な観点から目標設定の整合性や他方面の状況などを調整した巨視的な術策であって、戦略上の都合によって採りうる戦術に制約が生じることはありうる。
戦略と戦術の類似点をいくつか挙げることは出来る。両者ともに目標達成の手段という共通の性質を持ち、また戦略・戦術は共に一般的な理論であると同時に特殊的な術である。初心者はしばしば戦略を理論、戦術を実践として誤解するが、双方とも理論と術を併せ持っている。加えて情勢判断に基づいた戦力準備・戦力運用・教育訓練が三位一体となって目標達成を追求するという基本的な枠組みも類似している。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)144項より]
戦略と戦術の異なる点も挙げることが出来る。それは戦略と戦術が上下関係に属していることと関係して、考慮すべき問題の大小、配慮すべき時間の長短、視野の広狭などが決定的に異なっている点である。また戦略家・戦術家の思考様式の差異であり、戦術家としての役割を担う下級指揮官は一定の条件下で与えられた任務を達成するために判断すればよいが、戦略を担う高級指揮官は下級指揮官に任務を与える場合に必要な戦力を与えなければならず、また常に全体的な状況を把握して指導することが重要である。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)145項より]
また戦略・戦術の概念は近代以降に精緻化が進み、戦略は国家戦略、軍事戦略、作戦戦略に構造化されている。[* 防衛大学校・防衛学研究会編『軍事学入門』(かや書房、2000年)141項](戦略を参照)また作戦的な性格と戦闘的な性格から戦術を作戦術と戦術に区分する場合もある。

とある。このことを簡単にするために、ここでは、戦場という現場で行う術を「戦術」、戦場以外で行う術を「戦略」と定義する。厳密には違うかもしれないが概ね間違ってはいないはずだ。

まずは「経営者」から説明していく。

経営者の役割はとは戦争をする(つまりプロジェクトを行う)に当たって「どうなれば勝利なのか」「どうなると敗北なのか」「戦うことによって何を得るのか」を定義することだ。つまり目的を明確に定義することに尽きる。目的を達成するための手段や方法を考えるのは経営者の仕事ではない。経営者は戦略も戦術も定義してはならない。その役割は他者に任せなければならない。

次に「プロデューサ」について。

プロデューサの役割は、経営者が定義した目的を達成するための「戦略」を練ることだ。戦略の中でも「勝つための戦略」という攻撃的(オフェンシブ)な戦略を考える役割を担っている。したがって、プロデューサはリスクを恐れず打って出て、戦うことにより得られる目的を最大化することを考える。従って正面突破が難しいようなのであれば奇抜な策を提案することもあるし、十中八九勝てて、だれがやっても最大の効果が得られる勝ち戦ならばプロデューサの出番は少ないだろう。プロデューサはその役割の性質上目立つ。どのような職種においてもプロデューサが派手に見えるのはそのためだ。

「マネージャ」について説明する。

マネージャはプロジェクトを進めるにおいて、また戦う組織を維持運営する場合においてもっとも重要な役割を担う。マネージャもプロデューサと同じく「戦略」を練ることを役割としている。しかしプロデューサとは視点が違い「負けない戦略」という防衛的(ディフェンシブ)な戦略を考案するのがマネージャの最も重量な役割だ。戦争においても仕事上のプロジェクトにおいても、勝てなくても負けなければよいのだ。現実での戦いというのはゲームのように勝ち負けだけのゼロサムゲームではない。勝てないとわかっていても戦わなければならないことが往々にしてある。その時に「負けない戦略」が非常に重要になってくる。逆に、いくら勝てそうな相手だからといっても、どんな不測の事態が起こらないとも限らない。相手の戦力や戦略、戦術の予測を見誤っている可能性もある。それらのリスクをあらかじめ予見して、もしもの時を考え、被害を最小限に抑える方策をあらかじめ立てて置き、必要とあらば躊躇なく防衛的な戦略を発動させるのがマネージャの仕事だ。つまり、自組織を永続させることがマネージャの最も重要な役割と言い換えてもいい(戦って勝ったとしても自身がボロボロで再起不能ではそれは負けたに等しい)。さらに加えると「マネージャ」の重要なもう一つの役割として、戦線を維持して戦力を常に最高の状態に保つための兵站(ロジスティクス)を整備することも「マネージャ」の大きな役割だ。なお、現在のアメリカ軍では軍事作戦費用の50%以上をロジスティクスに費やしている。「マネージャ」はそれだけ重要な役割を担っている。

そして最後に「ディレクタ」だ。

もちろんディレクタは戦術を担当する。経営者が戦闘(仕事上で言えばプロジェクト)の目的を定義し、それに沿った戦略をプロデューサとマネージャが立案、準備をする。その戦略を受けて戦場で最も効果的に、かつ効率的に結果を出すために指揮を取る。つまり、戦場において、与えられた人的、物的資源(リソース)を最大限有効活用して戦略を具体化して目的を達成させるのがディレクタの役割だ。

なお、筆者の個人的主観だが、第二次世界大戦の日本軍には「マネージャ」職が欠落していたように思う。逆に「プロデューサ」と「ディレクタ」職は非常に優秀な人間が多かった(ロジスティクスが互角であった場合、総合すると日本軍は勝っていたそうだ)。つまり、勝つための戦略は立てられるが、物量に勝る相手に対して「負けない戦い」ができず自身がボロボロとなり再起不能となった。それを顧みず戦いを続けた結果が第二次世界大戦の結果につながったと思っている。もし当時の日本軍に優秀な「マネージャ」職が存在していて、「プロデューサ」と「ディレクタ」と同等かそれ以上の発言力があったとしたら、いまの歴史は大きく変わっていたはずだ。

この説明では仕事上のプロジェクトの役職を戦争に例えて説明してみた。「戦争とビジネスは全く違う」と反論される方もおられるだろう。しかし、現在主流のプロジェクトマネジメントの源流は、戦争大国アメリカでの戦争理論からきている。また、完全な戦争論であるランチェスターの法則を取り入れた企業が結果を残しているのは、戦争とビジネスが非常に似通った行為であることを如実に示している。

いかがであっただろうか?身近なプロジェクトに照らし合わせるとこの説明は非常にしっくりくるはずだ。そして、うまく回っているプロジェクト、成功したプロジェクトをみると、この役割がぴったり当てはまっていることが多いのではないかと思う。

2015年4月から始まったWiMAX2の3日間3GB制限にかかるとここまで速度が落ちた。のご報告


表題の件、手元のWiMAX2が速度制限に陥ったのでご報告。
ここまで下がる。

同一場所、同一サーバに対して同一アプリで計測したところ、下り速度は約96%、上りは82%の割合で速度がカットされる。もともと計測地点(自宅)はWiMAXの電波がよく入るところなので、差が顕著なのかもしれないけど。

ここまで速度が下がるとYoutubeがカクカクでまともに再生できない。
家で固定回線(時々お出かけ回線)として鎮座してるんだけど、
まぁ速度制限が来た段階で次の更新はないわな。
普通に固定回線にするよ。

ランサーズの「タスク」で仕事を依頼するとクソな成果品を拒否できない事がある


先日、ちょっとした文章作成をランサーズで依頼した。

ランサーズってしってる?ずいぶん前から有名なんだけど、ネット上で仕事を発注して見ず知らずの人間に仕事をしてもらうサービスだ。すべてのやり取りはランサーズサイト内で行われる。もともとWEBサイト作成やロゴデザインなんかが有名で、近年になって、少額で簡単な仕事を「タスク」という形で頼めるようになった。1仕事10円とか50円とかで仕事してもらえる。今回はその「タスク」ってやつでちょっと長めの文章作成を作成してください、●件募集ね、って依頼してみたわけ。

依頼した件数を書いちゃうとバレバレになりそうだから書かないけど、そんなに多い数じゃない。実はこの「依頼数」ってのがミソだった。

仕事を依頼して数日したら、さっそく文章がいくつか上がってきたわけ。それみたら、まークソなんだわ。こっちの指示はガン無視だし、意味わからん文体でそもそも日本語になっていない。到底そのままじゃ使えない。しかも1件とかそんなんじゃない。全部クソ!!こら全部拒否だわ、と思った。そしたら拒否できねーでやんのッ!!

「依頼数の30%を超える拒否はできません」

おいッ!!
ってことは、3件依頼したとしたら1件も拒否できねぇってことじゃん!!

ここまで書いたら正直に言います。
俺が依頼した数は3件です。
クソが3件きました。
はい拒否できません。
1件も受け取り拒否できません。

ちーん・・・・・・

全額無駄になりました・・・

_ノ乙(、ン、)_

まぁね、最初にランサーズの仕組みをちゃんと読んで無かった(事前調査もしなかった)俺が悪いですよ、ええ、俺が悪いんです。でもね、仕事を依頼した側としては、仕様に沿っていない、仕様ガン無視で作られた成果は受け入れできないもんでしょ、フツー。それを「依頼数の30%を超える拒否はできません」という理由で強制的に納品させるのはちょっとヒドイよ。これって、依頼主の意図を無視して書いちゃったモン勝ちってことじゃん。

っということで・・・・対策としては・・・・

「クソが来る事を見越して1件当たりの単価をクソ安くして数を稼ぐ」

しかないのですよ。そう

「下手な鉄砲数撃ちゃ当たる」

戦法ですね。

あ・・・だからランサーズって悪い意味での価格破壊の急先鋒なんだね・・・

Googleが定義する「みんなが素晴らしい管理者と認める8つの行動(オキシゲン・エイト)」


WIRED VOL. 7に面白いことかいてあった。

天下のGoogleが「良き上司(=良き管理者)」を従業員にインタービューしながら分析したんだそうだ。
その結果が以下のもの。

  • 1.良い指導者でること
  • 2.細かい事まで口出ししないこと
  • 3.従業員の幸せに関心があると態度で示すこと
  • 4.生産的で結果志向であること
  • 5.チームの話に耳を傾けること
  • 6.従業員のキャリア開発を支援すること
  • 7.明確なビジョンをもっていること
  • 8.最低限の専門的技術をもつこと

ちなみに「8.最低限の専門的技術をもつこと」が項目のなかで一番重要視されていなかったそうだ。つまり管理者としてふさわしい人間は、「仕事」に向き合う事よりも、「仕事をする人間(=部下という人間)」に向き合う事が重要だということ。言いかえれば、「仕事」を大切にするのではなく、「仕事をする部下という人間」を大切にすることが一番重要である、ということだ。Googleで「オキシゲン・エイト」と呼ばれる評価基準は、実際にGoogleの人事体制を決定する評価基準として使われているそうだ。

あなたが所属している組織、もしくはあなたの会社の組織体制ではどうだろうか?

プログラマ名言(迷言)集


動いている間は触るな。



クラッシュは忘れた頃にやってくる。



バグじゃありません。仕様です。



担当者は既に退社しました。



夜明けよ来ないでくれ!!



画面は青かった。



「自分はやればできるんだ」という奴は無能。



我作る、故にバグ有り。



ゴールしても決して振り返ることはできない。なぜならまた新しい仕様変更が目の前に突きつけられるからだ。



それはゴールではない。新しいデスマーチの始まりなのだ。



1匹のバクを見つけたら30匹のバグがいると思え。



バグが見つからない時は、探していない所にバグがいる。



テストデータ“だけ”は常に正常に動く。



ソース死すとも、バグは死なず。



神経質な者には幸運は来ない。



バグはデバッグモードで起こっているんじゃない!客先リアルデータで起こっているんだ!



バグったな!デバッグモードでもばぐったことないのに!



予定は未定であり、決定では無い。仕様もまた然り。



営業の、SEによる、プログラマの為のデスマーチ。



死んだプログラマだけが良いプログラマだ。



PGは許可なく辞めることを許されない!



リリースする前に会社が終わっちまうぞ、アホ!



クソまじめに努力するこたぁない!神様に任せりゃケツに奇跡を突っ込んでくれる!



開発の効率はやる気に比例する。



やる気は契約延長期間に反比例する。



並みのプログラマは処理を最適化する。

卓越のプログラマは職場を最適化する。

至高のプログラマは企業を最適化する。

究極のプログラマは市場を最適化する。

神なるプログラマは世界を最適化する。



会社を動かしてるのは「金」と「時間」と「気分」です。



ぼくそんなこと言ってないのに営業が・・・営業がぁ~



製品の仕様は予告無く変更される場合があります。



お前の実績は俺のもの 俺のバグはお前のもの。



1日ってなんで24時間しかないんですか?



仕様書には人格が反映され、プログラムには知能が反映される。



自分のバグは過小評価。他人のバグは過大評価。



自分のは「仕様」。他人のは「不具合」。



プログラムは思った通りには動かない。作った通りに動くのだ。



ウイルスに感染したんじゃない、Windows自体がウイルスなんだ!



三日経てば他人のコード。



「明日納品なのに仕様変更の依頼が来てますよ?」

「見なかったことにしよう。」



「進捗って奴は、最初のうちはうまく運ばないものでな」

「時間がたつと?」

「だいたいは、もっとひどくなる」



今のうちに帰っとけ。

今のうちに食っとけ。

今のうちに寝とけ。

今のうちに逃げとけ。



古PGや、池に飛び込む、鬱患者。





・・・・ソース BY にちゃんねる