  |
はてなキーワード: 仕様書とは
あたし・・・実は・・・プログラマーなんだ。
ずっと、黙ってて、ごめん。・・・隠してて、ごめん。
でも、どうしても言えなかったの。
あたしがプログラマーだって知ったら、きっとみんな離れていっちゃうって思って。こわくて。
わかってる。わかってるよ。
プログラマーは初級シスアドを通った人だけがなることができる、カスタマーのプロフィットに関わるシリアスなビジネスだって。
でもね・・。
でもね、全然ちがうんだよ。
あたし、みんなが思ってるようなキレイなものじゃないんだよ。
あたしは汚れている。
あたしのキーボードは、汚れているんだよ。
プログラマーになったとき、すごく嬉しかった。知り合いのハッカーになったような気でいたの。
あたし馬鹿だから、お客様のビジネスを作るんだ！なんて、本気で思ってた。
でもね、全然違ったんだよ。
元請から言い渡された Sヨ の詳細設計仕様書は全く別のものだった。
お客様のビジネスを、まるでビル・ゲイツのように平等に助けるようなものじゃなかった。
あたしたちプログラマーに課せられた任務、・・・・それは、デバッグ だった。
そして、それを見守ること。
ねぇ知ってた？
この世界には、あるんだよ。こんな日本のど真ん中にね、平然と、あるの。
プログラマーはね、それを見守るの。
プログラマーは六本木ヒルズのホリエモンで、勝ち組の特権階級の象徴だからね、
そこにあるだけで、まるでビジネスが行われているかのような錯覚を起こさせる。
あたしの仕事は、そうやって、平等にビジネスが行われているかのように見せる暗幕みたいなものだったの。
ソフトウェアなんて、全然、救えなかったよ。
救う義務も権利も、この任務にはなかったの。
例え、その仕様がどうすれば助かるか、明確に解っていたとしても、
あたしたちは元請の命令が無いかぎり、何一つのコーディングもできない。
ただ、ただ、走って火消し屋を呼びに行くだけ。そして伝えるだけ。
でもね、この国の「火消し屋」は非常に貴重な存在。
火消し屋は稀有な存在。
夜なんかになれば、一つのフロアにどこからともなく現われるの。
たくさんのプログラマーたちが、一人の火消し屋に群がっていた。
「先生、コアを吐いている人がいます！」
「先生、表領域が苦しい人がいます！」
懸命にプログラマーたちが叫んでた。
でも火消し屋は一人。
私も声を荒げて「苦しい言い訳をするプログラマーがいます！」って叫んだの。
でも、ここでもふるいわけが始まる。
人員レベル、難度、納期。そんなものが現象と一緒くた になって命令が言い渡される。
と言ったきり、火消し屋は朝までチームのもとに来れなかったの（お客さんのところに言い訳に行った）。
その日、10秒ごとに Mantis の履歴が増えた。
「苦しい、苦しい、まだ苦しい」
「もう少しだけ待ってください、今火消し屋、来ますから・・」
何度も火消し屋のもとに走ったけど・・・。
火消し屋は、今にも心臓の止まりそうなお客さんと仕様と納期の折衝にあたっていた。
あたしは火消し屋に背中側から叫んだ。
「null チェックを入れても、まだぬるぽみたいなんです！」
「ガッ！」
コメントアウトの行数を上げた。でも駄目だった。QA からの質問は止まない。
そのバグだけじゃない。
「トイレに連れて行ってください（コンプライアンス的な意味で」
「基板が焼けたから替えてください」
「エスタロンを飲ませてください」
「ブートが走らないんですが」
「眠れません」
デバッガを走らせる。
忙しさにコードが荒くなる。
月残業時間が 400 越えたプログラマーがエレベーターに乗って外に出て行こうとする。
必死にあたしもふるい分けた。
今、一番検収ハネられる危険があるバグから、一番仕様満たしてないバグから、手を差し伸べなきゃ。
「いつになったら納品されるんだ！」と言われても。
「単価高い」と言われても。
私は頭を下げたり、ちょっと言い争ったりもしながら、
あたしはカーネルだ！と思った。
あたしは火消し屋の指示を待たずにロジックの検査をした。差分プログラミングの extends だった。
急いで火消し屋に連絡した。
「差分プログラミングの extends です。継承元のコードいじっていいですか？！」
「いや、コードを見ないとわからない、ただこっちの処置があるから、10分後に行く」
「待てません！リリースします！」
あたしは火消し屋の指示無くパッチをコミットした。バグの症状はスッと納まった。
それは駄目なことだったけど、一人のバグを救ったことに、あたしは浮かれてたの。
貧相な正義感をぶら下げて、意気揚々と自席に戻ってきたの。
自席の・・・・
でも、亡くなってた。
システムコールも呼べない人だった。
あたしは、その日、目の前の苦しいバグに夢中で、ps なんか見てなかった。
それでもね、・・・あたし、まだ、プログラマーなんだよ・・。
火消し屋は QA に「いつ何があってもおかしくない COBOLer の書かれたコードでしたから・・」と時間稼ぎの工作をしていた。
QA のテスターは「ありがとうございました」と額に青筋を浮かべてバグレポートに「仕様です」と書いて取り下げた。
そして、あたしにも「プログラマーさん、ありがとね」と言ったの。
大好きな、ソフトウェアだった。
このシステムが立ち上がる頃から知っていて、αリリースから知っていて。
「自分は寂しがり屋だから、最期は dankogai に手を握ってもらいながらホッテントリ入りしたい」と言っていた。
あたしが新人の頃から知っていて、vi のカーソル移動が苦手だったのも知っていて、
「Xenix はわしが育てた」が口癖だった。
「まぁ、・・・歳だったし、運用中にも止められないって言ってたからなー」
と火消し屋があたしの背中ごしに言った。
その記録には、波形が Full GC 後もヒープ使用量が右肩上がりとなりメモリリークするさまがしっかりと記録されていた。
高負荷だから死んだんじゃない、そこにはメモリリークで死んでくプロセスがあった。
でも、そんなこと全部まるめこんで、kill んじゃって仕方ないっていうプロセスが、そこにはあったんだ。
似たようなことはざらにあった。
何人ものプログラマーが、自社ビルの屋上の端から零れていったよ。
でも、あたし・・・プログラマーなんだ。
誰も、辞めろって言わないの。
火消し屋は鉄火場にブチ込まれただけだから、言わない。
顧客は実情がわからないから、言わない。
プログラマー同士は実情がわかってるから、言わない。
IPA はきっと、全部知ってて、それ込みで「それが10年は泥のように働けということだ」と言うかもしれないけど。
いや、言わないか。IPA は、何も言わない。きっと。
救えたかもしれないバグを、プログラマーは一番わかってる。見えてしまう。
PM の指示が適してないのも、判断が遅いのも、仕様変更履歴がのってないのも、全部わかってる。
それでも「あの時！」と、自分の行動と判断を何度も振りかえる。
その向こうにはいつも「あのとき、こうしておけば」が、くっきりと見える。
でも、救えなかった責任も、見過ごした責任もプログラマーには問われない。
プログラマーって・・ほんと、なんなんだろうね・・・。
パッチ一粒すら出せないのに、
設計一つ指示できないのに、
テストパターンに関わることなんて、一つも独立してできないのに、
テスト部門が持たされてるのはプログラマーコールだけなんだよ。
どんなに辛くてもプログラマーしか呼べないなんて。
そしてあたしたちは色んなものを抱えて、バグの前に立つ。
火消し屋が来ること、来れないこと、
できるデバッグがあること、ないこと、
色んなことを知りながら、本当の意味で世界を変えられるコーディング力もないままに、
さも救いのギークが舞い降りたかのような顔で。
IT ギョーカイが崩壊していく。
全然止められない速度で。
その日○製作所の城で、あたしは見てるんだ。
沈んでいく汎用機の命を。
----------------
元増田は本来業者が準備すべき書面を自分が作らされているのがおかしいと感じているのかもしれないが、そもそもの発端は逆だったという可能性はないかな。
官僚様の琴線に触れる文書を作ってくれないとこっちも困るから用意しとくし、ハンコだけ押して返送してー。って。
昔は請求伝票とかもそんなだった（法人会計になってから監査に怒られるのでやってないけど）。請求明細に至るまでひな形用意して、金額数量なんかだけは自分の目でチェックして、問題なかったらハンコつけばできあがりだから！てつくってやってたよ。会計のオッチャンにいちいちいちゃもんつけられると間に入った自分が困る。業者さんの心の声は「たかだか数千円の請求書になんでそんな細かいことまで指定すんださっさと払って〜」だしな。自分は地方のII級なんで、本省レベルと一緒にスンナ！といわれるのならごめんなさい。＞＜
逆に自分が初めて仕様書作った時だって、どうやったら必要な仕様が漏れなく盛り込まれててかつ複数業者が応札できるような仕様書が書けるかなんてだーれも教えてくれないのだ（現場の非行政職だから余計にそういう状況なのもあるが）。業者に見本もらったよ。
ちょっと話ずれるかもしれないけど、そういう意味ではお役人の世界って、育てなくても教えなくても常に同じクオリティで仕事ができることを求められる不思議な世界だと思う。それが効率のいい業務遂行なんだよ。自分は現場なのでそこに時間を割くならもっと別の、人に向いたサービスに力使いたい、といいように解釈することにしてる。でもどっかにしわ寄せは行ってるんだよね。お互いがんばろうや。
そのようなことは、別に日立だけじゃないが
ただ、政府や公共機関の発注の仕方や、年度予算に縛られることなどを考慮して
批判すべきだろう。
典型例）
発注側に要求仕様を定義できる人間がほとんどいなく、金銭の発生しない、官庁内部のヒアリング
から発注側要求仕様書の作成まですべて丸投げで、なにも分かっていない。
当初の納入バージョンはバグバグ、以後果てしない修正作業が続く。
こんなケースも多い。
民間企業と同じような付き合いができるのならば、ここまでぼる事はないのかなとも思う。
日本政府や公共機関をガラリと変えて、血の入れ替えを行わなければ、この問題は解決しないのではないのかなとも思う。
未だに泥がどうたらこうたら言ってるやつは
http://anond.hatelabo.jp/20080717201617
平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。
土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。
ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな？なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。
ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログで無駄な煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。
RSSリーダーの更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。
梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。
お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。
起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、
偉そうにふんぞり返ってるアホをぶちのめせるんだよ。
ジャンルがわからんので何ともいえんけど、大卒の新人とか見てると、自分の仕事こなせるようになるまで3年はかかるね。
だから1ヶ月強でそのレベルまで達しているなら、それだけでスゴいと思うけどｗ
「そっち側」というのが (広義の) Webサービス構築をひと通り自分だけでこなせるぐらいのスキルだとすると、こんな感じか？
ググったりパクったりしながらでもいいので、とにかく経験することかな？
結局一定レベルを超えると、どれもパターン化できちゃうことに気づくと思う。
増田に限らずはてブでコメントしたりしているプログラマはなぜかWEB屋とSIer（下請け含む）を混ぜて語ってるのだろうか？
どう見てもWEB屋の話であり、腐ったSIerの話ではないのに元請けが作った仕様書がとかいい加減にしてほしい。
もうこの２つの間には大きな隔たりがあるのだから職業として別物として考えた方がいい。
それを理解できない奴らは
のどちらかでしかない。
そこを理解せずごちゃ混ぜで話すから、一方では３Kだ８Kだという話になり
その一方でやりがいのある楽しいお仕事ですと言った両極端の意見が生まれてしまう。
それを誤解した人がWEB屋の夢を見てSIerに入社し、絶望してやめていく。
いま、ふとバックアップの「com」って名前のフォルダを見て、javaでwebアプリケーションとか開発してた頃を思い出し胸がキュンってなった。
あの頃comフォルダを開いて一日の業務が始まり、comフォルダを閉じて帰宅の路についた。
comフォルダをみんなで毎日つつき、開発し、comフォルダを納品して報酬をもらっていた。
あの頃はcomフォルダが全てで、comフォルダに一喜一憂し、Eclipsさえあれば一生食うにこまらないやと思っていたな。
誰も読まないUML図。ダンボール一箱分の仕様書。バグ報告すると仕様としてマニュアルに記載される、メーカー様謹製フレームワーク。
あそこにはもう戻ることはないけれど、面白かったな。
みんな元気ですか？SEは欝になってませんか？チームリーダーは残業２００時間こえてませんか？プロジェクトマネージャは３５越えて独身じゃないですか？
最下層のPGはネトゲ嵌って廃人同然で、デスク周りはフィギュアばっかじゃないですか？
また、どっかで飲みましょう。それまで、、生きろ！
友達も親も相方も 「仕事 辞めれば？」という。口を開けばため息をつき 顔色も悪く 体調も優れない。
自覚してはいるものの、でも朝になれば何を考えることもなく会社へ向い、10時間を超える労働 サービス残業 土日も返上
休日手当なんてなくてすべて代休扱い、しかもその代休が消化できる日なんて来なさそうだし、それを知ったのもつい最近。
やりたい仕事をできていたのは最初の３ヶ月くらい、それ以降は上司の小間使いのような仕事がほとんどだし
履歴書に書けるもんが得られるわけでもない。そもそも今年の頭には会社員のはずがアルバイト契約のまま（？）だし、そこらへん聞いても教えてくれない。
職場の中国人PGには普通の会話もままならないし、鬱のテスターは毎日無断遅刻／欠勤（なぜか電話するのは自分）だし
上司とリーダーは犬猿の仲で朝っぱらから怒鳴り合ってるし、間に入って話通すのも専門的なところはよくわかんないし
素人なりに考えて組んだコードも確認なしにスクリプト上書きすっから毎回レイアウト崩れるし
そもそも仕様書自体がないのにもう納品前とかなんなんだよ もう。
あのさあ、ライターだったらリード文に気の利いた文章一つ書けないでどうするよ。狭い業界の技術専門誌だけに書いて生きていくつもり？一般科学雑誌とか、もっとそういう野心はないわけ？そういうとき、古典の素養は必要だよ。
人間はプログラマだけじゃないんだけどね。それに、言ってること理解できてるのかなあ。プログラマにとってのLispや低レベル言語が、日本語を書く人にとっての古典にあたると言っているの。
それはあなたの場合でしょ。文系の人なんかだったら、古典なんて寝てても理解できるけどLispなんて一生理解できないといわれると思うよ。あなたは、自分が理解できなかったものを過度に難しいと思い込んでるだけ。
へー、あなたプレゼンしないんだ。顧客や投資家向けに気の利いたフレーズ一つ思いつかないようでどうするの？
観光が産業として大したことない、というからその点に反論したまで。俺はあなたの論点の不備を一つ一つ指摘してるだけで、自分が一貫した主張をしようとしているわけではない。
日本文学についてはそうかもな。でも、当の近代文学もろくに読んでない奴が、下敷きにだけ手出しても意味ないだろ。まずそっちが先じゃないかな。
じゃあ、ロックやポップス聴いてない奴がクラシック聴いちゃだめなわけか？そんなの勝手だろ。古典の方が近代文学より好きな人間だって沢山いるよ。俺だってそうだが。
あのね、そんな優先順位つけるまでもなく、全部できると言っているの。
あのさあ、「ジェネラリスト」の意味わかってる？いろんな分野に視野横断的に目が効く人のことを「ジェネラリスト」っていうんだよ。数学だけ勉強してれば文学も歴史も語れるっていうのかい？
足りてるわけねーだろ。仕事やりながら勉強してるような状態だよ。これが、高校でやってなきゃ偏微分とかと同レベルの理解度でしかなかったんだと思うとゾッとするね。基礎だけでも仕込まれててよかった。
自分が大学でサボってたことを自慢するなよ。普通はもっと勉強するんだよ。自分が勉強しなかったことを、「高校で教えてくれなかったせいだ！」なんて言ってたら、これだからゆとりはって言われるだけだよ。
数学系でも電子工学系でもねーもん。適当に試験前の一夜漬けで切り抜けてた。終わったら速攻忘れた。あと量子力学なんか何に使うんだよプログラマが。
使わないことは一切勉強しない人なんだ。ふーん。隣接分野から発想って出てくるもんだけどね。忠告しとくけど、俺が挙げたのは工学部のどこでも学びそうな分野だし、それから量子力学知ってると信号処理がわかりやすくなるんだけどね。まあいいや。
俺が思ってるものと比べてるんじゃない。「古典と」比べてんだよ。ちゃんと答えろ。
なんでそんなエラそうなんだ？だから、比べられないって言ってるだろう、何度も。少なくとも答えが自明に出る問題ではないし、客観的に妥当性のある調査ができるとも思えないと言っているの。
例えば、JavaとかRubyとかVBとかPHPとか、そういう種類の言語一種類しか使えないプログラマがいたらどう思う？あまり難しい仕事任せられないって思わない？
古典が読めるってことはまったく評価にならんだろ。プログラマとしては。
無論、最低限の英語力は必須だし、英語力は高ければ高いほどいいが。
最低限、Cとかアセンブラとかできるだけ低レベルに近い言語はある程度使えてほしいし、できればLispみたいな関数型言語とかOSやコンパイラの理論とか、そういうのを知識としてだけでもいいから知っておいてほしいと思うよね？
そんなの情報系の基礎教養だ。微積分学や古典を勉強するよりははるかに楽だし。
だったらどうして、古文や漢文の勉強が自分には意味ないって思うかなあ？日本語で文章を書くのは、仕事上の重要なスキルでしょ。まずその前提がよくわからない。
ビジネス定型文書くのにはもちろん、企画書や仕様書や技術書を書くのにも、古典や漢文の知識なんぞ必要ないだろ。
別に古典教育がどうなろうが観光ビジネスの改革にはならんだろうに。
日本文学についてはそうかもな。でも、当の近代文学もろくに読んでない奴が、下敷きにだけ手出しても意味ないだろ。まずそっちが先じゃないかな。
それとさー、どうしてあれを教えたらこれを教えるのやめろって話になるわけ？両方教えたらいいだけじゃないの。ただでさえゆとり教育なんだからさ。
教育を強化するなら数学優先にすべきだな。あと英語の強化かな。古典なんか最後でいいよ。
それは単なる君の不勉強でしょ。高校までで役に立つこと勉強したいんだったら高専とか工業高校に行くべきなんだし。普通高校ってのはジェネラリストを育成するところなんだからね。
それに、君はたまたま高校で習った行列計算だけで用が足りてるのかもしれないけど、行列の計算だけできても普通は何の役にも立たない。
足りてるわけねーだろ。仕事やりながら勉強してるような状態だよ。これが、高校でやってなきゃ偏微分とかと同レベルの理解度でしかなかったんだと思うとゾッとするね。基礎だけでも仕込まれててよかった。
というか、固有値やベクトル空間を理解せずにどうやって大学を卒業できたんだ？力学も振動論も微分方程式も統計学も信号処理も量子力学も、何一つ理解できないでしょ、それじゃ。
数学系でも電子工学系でもねーもん。適当に試験前の一夜漬けで切り抜けてた。終わったら速攻忘れた。あと量子力学なんか何に使うんだよプログラマが。
信号処理は真面目にやっときゃよかったなとちょっと思うね。今んとこクリティカルにそういうもんが必要になる仕事はやってないが。
俺が思ってるものと比べてるんじゃない。「古典と」比べてんだよ。ちゃんと答えろ。
http://d.hatena.ne.jp/ksh/20080401
おじさん心配なのよこれ。何が心配って、この本音を抑えれなくて新人に八つ当たりに近く（本人は愛の鞭と誤解していても）
指導に当たる君が。あのね、君が言ってることは本当に正しい。恐らく、一人でやっていけるという自負がではじめたところなのかな。
20代の青年って感じがする。私は君を否定するつもりは無いし、それどころか君には信頼すら感じる。
中学生になった息子もこれくらいしっかりした男になるよう目指して欲しいと親心に思うくらいにね。
けど、たぶんだけれど君が新人を任されたらその新人は終わるね。負のフィードバックが働いてたぶん自滅する。かわいそうなのは
君がそれに責任を感じてしまうことだ。それはなんとかして阻止したい。こんな時間に書き込んでしまうじじいだからと唾棄しないで
どうか聞いて欲しい。それが君のため（あるいは君の日記に何も考えず賛成するもっとたちのわるい連中のため）だから。
なぜ、そんなに君のことが心配なのかというとそれは
「君がやるべきものと部下が自分でやるもの」
を履き違えているかもしれないと思うからだ。言い換えれば、部下に期待するべきでないことを理解していないということである。
断定して申し訳ないが、君は今の自分を変えなくていいと強く思っているだろう。だから、君の文を使ってねちねちと説明する。
これからはグローバリゼーションの時代ですので英語を勉強する前に、ちゃんとした日本語が使えるようにしてください。
説明するのに「ここ」とか「これ」とか言わずに「仕様書p.18ページの上の図」とかちゃんと言ってください。
という文章。新人が本当に「これ」といいたいのだろうか。初めてのものを君が見たときのことをよく思い出してほしい。
「これ」以外なんといえるのか。やや反論を許すたとえだったが言いたいことは伝わると思う。「これ」は何かを教えるのは母であり、
君なのだ。はじめからそれを期待してはいけない。もし君が部下に向かって日本語が出来ないなどと言葉に出し、恥辱したら君は上司失格だ。
次に、
わからないことをわかったふりをされると超迷惑です。しばきたくなります。
これは、100%自分のせいだよ。自分がそうすることを許すだけ甘いってこと。そうじゃないと本当にやっていけない。
それを誰かに転嫁したら自分が成長しないし、外回りに行ったときに完全に失敗してしまう。これは直して欲しい。
長続きする結婚生活の秘訣でもある。
仕事は、覚えるんじゃなくて、ノートとペンを常に持ち歩いて記録してください。同じ事を２回聞かないためにはどうしたらいいか考えてください。
でも２回聞かないといけなくなったらちゃんと聞いてください。
君の言わんとするように出来たら、誰も苦労しないだろう（かすかな例外としての君を除いて）。
はじめは、新人とは萎縮するものだから何回も聞いていいと胸襟を開いたほうがいい。
その代わり、どうやったらその回数を減らせるか共に考えていくという姿勢を見せることだ。
そもそも、一回で伝えることが出来る人間がいるということも忘れないで欲しい。
君に言いたいことは以上である。君は私のことを甘い、そして抵抗勢力の最たる人間であると笑うかもしれない。
だが、私は今まで十字軍のような自分への盲信で多くの可能性をつぶしてきた同僚や上司、特に部下を見てきた。
自分はこうやれたから出来るだろうというのは間違っているし、君はそう当たることで部下を信頼していると心の中で
にやけているかもしれない。けど、それは部下じゃなくて君を信頼し崇めているだけだよ。
部下はそれを見抜いて君に心の中で反発するし、君の上司も君のふがいなさに泣くだろう。
自分に期待するのはいいけれど（その意味で君は素晴らしい人間だと思う。）、他人に自分を求め、速成するよう八つ当たりのようにけしかけるのは
何よりも君自身が一番かわいそうだと思う。君はもっとゆとりをもち、もっと自分に厳しくあるべきだ。
私は本当に君を心配している。願わくばこの日記が君の元に届くことを期待している。
そのためにははてな匿名ダイアリーのほうがいいと判断して匿名ダイアリーで日記を書いた。文が若く見えればと思い、ほかの
日記の文章を参考にした。だが、もしかしたらじじいくさいかもしれない。
その時は、若者世代に迎合するよりはそれを叱りつけたほうが人間社会には望ましいという格言を持って反論したいと思う。
君とその賛成者へ、自分を見つめてください。他人は自分の鏡です。しかることで自分を愉しませていませんか。
本当に新人が出来ない自分を肯定していると思いますか。私は君たちを見ています。
It's only love.
もしも願い一つだけ叶うなら 君の側でペアプロさせて
どんなエディタでもいいよ
Beautiful code
迷わずモニターだけを見つめている
Beautiful logic
自分のギークらしさ まだ知らないの
It's only love.
寝ても覚めてもハックばっか
夢見てばっか ぬるい涙が頬をつたう
言いたいことなんか無い
ただもう一つテスト書きたい
言いたいこと言えない
非コミュかもしれない
それでいいけど
もしも願い一つだけ叶うなら 君の側でペアプロさせて
どんなキーボードでもいいよ
Beautiful code
迷わずモニターだけ見つめている
Beantiful logic
自分のギークらしさ まだ知らないの
It's only love
どんなコードでも書いてみて
DISられたって 少し経験値上がる
仕様書なんかいらない
肝心なことが載ってない
最近調子どうだい？
家に帰れてるなら 別にいいけど
僕のバグが消えるまで帰れないなら
Beautiful code
儚く過ぎて行くスケジュールの中で
Beautiful logic
気分のムラは仕方ないね
もしも願い一つだけ叶うなら
君の側でペアプロさせて
[1] http://anond.hatelabo.jp/20080323175904
と
[2] http://d.hatena.ne.jp/ryozo18/20080324/1206301703
を読んで思ったことを書きます。
[1]の人はお子様ですね。その給料が何のために支払われているのかわかってない。
金もらって働いている自覚が全然ないんだろうな。
[2]の人は、ずばりこのことを言いたいんじゃないかなぁ、と思った。
[1]も、自分でもなさけねーなーと思ってるからこそ匿名で書いているんだろうけど、ちょっと前まで学生で年収が600万になろうかとしているくそ坊主にそんな甘っちょろいことを言われたら、どんな人でもぶちぎれると思う。
僕も同じようなこと考えたことがあるから[1]の気持ちは分かります。
ちなみに、僕のスペックは、入社3年目で年収は[1]には及ばなくもきっちり貰ってる方だと思っている中小企業のプログラマ。入社して早々に大規模プロジェクトに投入されてデスマーチの中を生き残って（？）今日に至る。
大規模プロジェクトといっても下っ端にできる仕事と行ったら仕様書通りのclassを書くくらいしかないわけで、まわりの面白そうな案件をやってる先輩がとってもうらやましかったんですよ。だから、最初の頃は[1]と同じようなことを考えていました。
でも、デスマーチの中で働いてるうちに、なんでこんなつらい思いをしなきゃならないのか、もっと楽にできないのか、とか考えだして、自分の関わっている範囲から少しずつ、品質に責任を持つようになったんですよね。
＃デスる原因はいろいろあるとは思いますが、やはりPJに関わっている個人の意識が低いことが原因の一つだと思う
また、何よりもバグを作って大変な目に遭うのは自分だけじゃなくてまわりの先輩やお客さんだということがよくよくわかってくるので、品質をあげるためにより真剣に取り組むようになりました。
そうやって少しずつプロ意識が芽生えてきたわけなんですが、おそらく[1]はまだ、そういった切羽詰まった状況に追いつめられていないんでしょうね。
学生のノリでここまできている。自分のことしか考えていない。責任感、皆無ですよね。
だいたい、2年目にして年収600万ももらってるやつが、
「自分のやりたいことができないんです。転職した方がいいですかね？」
なんて悩んでたとしても、それに本気で答えるやつなんていないですよ。自分の親ですら「好きにすれば」っていいますよ。そんなもん。
勝手にやればいいんですよ。何をぐだぐだいじいじ言ってるのかなぁ。
それから、会社では自分のやりたいことができないウボァー、といっていますが、会社はあなたの知的好奇心を満足させるために年収600万を用意しているわけではないと思うんですよ。600万で、与えたその仕事をきっちりやってくださいと言ってるんじゃないかなぁ。さらには、600万以上の仕事をしてくれるのを期待しまくっているんだと思う。
だから、自分のやりたいことを今いる会社でやりたいんなら、その＋αの部分で自分のやりたいことを実現するのが筋ってもんでしょう。
結構な金を貰っときながらあまっちょろいことを口にしている人は、自分が会社の期待に応えているのか見つめ直してみたらいいと思う。プロ意識の低いうちは何してもうまく行かないんじゃないかなーと思います。
「私、プログラミング好きだよ」と言うプログラマに、好きな言語や開発ツールを聞いて「C/C++/C#」の名前があがってくるとげんなりする。心底がっかりする。C/C++/C#は俺も大好きだし、素晴らしい曲開発環境だと思うけども、臆面も無く低レベルプログラミング言語を挙げる人のほとんどが、それ以外の低レベルプログラミング言語を知らないんだもの。それどころか、IA-32の仕様書があることすら知らないし、興味が無い。せめて4004の基本構造くらい理解してから言ってもらえませんかね。
要するに「プログラミングを理解する知識の深い私」を演出するために、いちばんてっとり早くて優等生な回答なんですよね。C/C++/C#は。あと、アセンブリ言語や、機械語もこのカテゴリに入る。
確かにUnixを記述したC言語として鉄板なことは間違いないけど、本当にプログラミングが好きならもっとたくさんの名前が挙がってもいいと思う。もっと書けよ！インテル系以外も！最近のも！「C」「アセンブラ」「MMX」「SSE」「3DNow!」のコンボはもう飽きました。
1度だけ悲しきAdaという回答が返ってきて、土下座せんばかりに感動したことがあります。あ…この方、本当にプログラミングを趣味でやってるんだ…と思ったよ。
ごめんなさい、僕、嘘をつきました。
訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。
注意：以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が本当に以下のように述べているとは限りません。
なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
Tuesday, February 19, 2008
先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。
それぞれのExcelワークブックは1つのcompound fileに収められている
つまり、Excel 97-2003ファイルはOLE coumpound documentで、それは結局、1つのファイル内にあるファイルシステムである。これは、理解するのにあと9ページはスペックを読まなくちゃならないぐらいには十分に複雑だ。そしてこれらの「スペック」は、普通我々が考えるようなスペックというよりは、Cデータ構造みたいに見える。これ全体が階層的ファイルシステムなのだ。
もしあなたが週末を、Wordドキュメントをブログにインポートしたり、あなたの個人的な財務データからExcelフォーマットのスプレッドシートを生成するような気の利いたコードを書くのに使おうと思ってこれらのドキュメントを読み始めたなら、このスペックのややこしさと長さがそんな気をあっという間に失せさせるだろう。普通のプログラマはこのOfficeバイナリファイルフォーマットについて次のような結論を下す:
この4つ全てについて、きみは間違っている。ちょっとだけ掘り下げて、これらのファイルフォーマットがどうしてこんなに信じがたいくらいに複雑なのか、なぜMicrosoftの悪いプログラミングを反映しているのではないのか、そしてそれを回避するためにあなたに何ができるか、を明らかにしよう。
理解すべき最初のことは、これらのバイナリファイルフォーマットはちょっと違ったデザインゴールを持って設計されたということだ。たとえばHTMLとは。
これらはすごく古いコンピュータで速く処理できるようにデザインされた。Excel for Windowsの初期のバージョンでは、1MBのRAM、20MHz動作の80386が Excelを快適に走らせることができるための妥当なものだった。このファイルフォーマット内には、ファイルを素早く開いたり閉じたりするための最適化が沢山仕込まれている:
これはライブラリを使うことを想定して設計されている。もしあなたがバイナリをインポートするものを1から書き上げたいと思ったら、Windows Metafile Format (何か図を描く場合) や OLE Counpound Storage みたいなものをサポートしなくてはいけなくなる。もしあなたが Windows上でやるのなら、そうしたことをたいしたことのない作業にするためのライブラリのサポートが存在する... そういったフィーチャーを使うことは(元々)マイクロソフトチームのためのショートカットだった。でもあなたが全部を自分でスクラッチから書くなら、全部の作業を自分自身でやらなくてはいけない。
オフィスはcompound documentsに対して広範囲のサポートを持っている。例えば、スプレッドシートをWord文書に埋め込んだりできる。完璧なWordファイルフォーマットのparserは、同じように、埋め込まれたスプレッドシートで何かインテリジェントなことが出来るべきだろう。
それは相互協調性(interoperability)を意識してデザインされてはいない。仮定されていたのは、WordファイルフォーマットはWordからのみ読み書きされなくてはいけない、ということで、それは当時においては十分に合理的なものだった。これは、Wordチームのプログラマがファイルフォーマットをどう変更するかについて決定を行う場合にはいつでも、彼らが気にするのは (a)何が高速か (b)Wordのコードベースにおいて最小の行数になるのは何か、だったことを意味する。SGMLやHTML-interchangeableといった標準ファイルフォーマットのようなアイデアは、最初にインターネットがドキュメントの相互交換を実現するまで現実のものにはならなかった。それはOfficeバイナリフォーマットが最初に考案されてから10年後のことだったのだ。ドキュメントを交換するのにインポーターとエクスポーターを使うことができるという仮定が常にあった。実際Wordは簡便な交換のために設計されたRTFと呼ばれるフォーマットを持っており、そのフォーマットは殆ど最初のころからあり、今も100%サポートされている。
それはアプリケーションの全ての複雑さを反映していなくてはいけない。 全部のチェックボックス、全部のフォーマッティングオプション、そして全部の、Microsoft Officeのフィーチャーは、ファイルフォーマットのどこかで叙述されていなくてはいけない。Wordのパラグラフメニューにある、"Keep With Next" と呼ばれるチェックボックス、これはパラグラフを、その後ろのパラグラフと同じページに置くのに必要な場合は、次のページに移動させるもの(?)だが、これもファイルフォーマットの中に無くてはいけない。そしてこれはつまり、あなたがWordドキュメントを正しく読み込める完璧なWordクローンを実装したいなら、そういったフィーチャーを実装しなくてはいけないということだ。Wordドキュメントをロードする競争力のあるワードプロセッサを作っているのなら、ファイルフォーマットからそのビットをロードするコードを書くのには1分しかかからないかもしれないが、ページのレイアウトアルゴリズムをそれに対応させるのに何週間もかかるかもしれない。もしあなたがそうしない場合、カスタマーがあなたのクローンでWordファイルを読み込んだら、全部のページがぐちゃぐちゃになってしまうだろう。
それはアプリケーションの歴史を反映していなくてはいけない。 このファイルフォーマットに見られる多くの複雑さは、古く、複雑で、愛されず、めったに使われないフィーチャーを反映している。それらはファイルフォーマットのなかに後方互換性のためにまだあり、そしてMicrosoftにとってその辺りのコードを残しておくことには何らコストはかからない。しかしあなたがこれらのファイルフォーマットをparseおよびwriteする一貫した完全な仕事をしたいと思うなら、Microsoftのインターンが15年前にやったのと同じことを全て、またやらなくてはいけない。要点は、何千人年の仕事が今のWordやExcelには費やされてきたのであり、これらのアプリケーションの完璧なクローンを作りたいと本当に欲するなら、あなたは何千人年を費やさなくてはならないことになる、ということだ。ファイルフォーマットは単に、アプリケーションがサポートする全てのフィーチャーの簡潔なサマリーなのだ。
手始めに、小さな例を一つ、深く見てみよう。Excelのワークシートは色々なタイプのBIFFレコードの集まったものだ。私はスペックの一番最初のBIFFを見てみたい。1904と呼ばれるレコードだ。
Excelファイルフォーマット仕様のこのレコードについての記述は非常に曖昧なものだ。そこでは単に、1904レコードが「1904日付システムが使われているかどうか」を示すレコードだ、と述べているだけだ。ああ、使えない仕様書の典型的な一例だ。あなたがExcelファイルフォーマットで何かしている開発者で、そしてファイルフォーマット仕様にこう書いてあるのを見つけたなら、あなたがMiocrosoftは何かを隠しているのだと結論付けたとしても無理はない。この情報の断片は十分な情報をあなたに与えはしない。あなたには幾ばくか外部の情報が必要で、私は今ここで、それを提供しよう。Excelワークシートには、2種類ある。日付のエポックが1900/1/1のもの(これには、Lotus 1-2-3 との互換性のために故意に入れられた閏年に関するバグがあるが、ここでそれについて述べるのは退屈すぎる)、および、1904/1/1のものだ。Excelは両方をサポートしているが、それはExcelの最初のバージョンはMac版であり、それは単に簡単だったという理由でOSのエポックを使っていて、しかしWindows版のExcelは1-2-3のファイルをインポートできなくてはならず、そしてそれは1900/1/1をエポックとして採用していたからだ。あなたが涙ぐむのも無理はない。歴史のどの時点においても、プログラマが正しいことをしなかった、という時はないのだが、しかし現実にあなたが手にしているものはこれなのだ。
1900と1904のファイルタイプは両方とも世の中には広く存在しており、それは通常、ファイルがWindowsとMacのどちらで作られたかによる。一方のタイプから他方のタイプへ黙って変換するのはIntegrity的に問題があるので、Excelはファイルタイプを変換することをしない。Excelファイルをparseするためには、あなたは両方を扱わなくてはならない。それはファイルからこのbitをロードするだけの問題ではなく、あなたが日付表示と両方のエポックを扱うparsingのコードまで書き直さなくてはいけないということを意味する。実装には何日かかかるだろうと私は思う。
実際、あなたがExcelクローンの作業をするなら、日付の扱いについて、あらゆる種類の微妙なディティールを発見することになるだろう。Excelは日付の値をいつ変換するのか? 表示の整形はどうやっているのか? なぜ1/31は今年の January 31と翻訳され、また一方で1/50はJanuary 1st, 1950と翻訳されるのか? Excelのソースコードと同じだけの量のドキュメントを書かないがぎり、振る舞いに関しての微妙なビットを全て完全に記述することはできない。
そしてこのレコードは、あなたが扱う何百もあるBIFFレコードの最初の1つに過ぎず、しかももっとも単純なものなのだ。他のレコードの殆どは、より多くのプログラマーを涙に暮れさせるぐらいには十分複雑だ。
唯一導き得る結論はこれだ。
MicrosoftがMicrosoftとOfficeのファイルフォーマットをリリースしたことは大変有用なことだが、しかしそれでOfficeファイルフォーマットをインポートしたり保存したりするのが楽になるということは全く無さそうだ。それらは狂気じみて複雑で、リッチなアプリケーションで、そしてあなたは人気のある20%の部分を実装して80%の人々を幸せにするというくらいのことしかできない。バイナリファイル仕様によってなされるのは、多く見積もっても、著しく複雑なシステムのリバースエンジニアリングにかかる時間を何分か削減するくらいだろう。
オーケー, 私はいくつか回避法を教えると約束した。良いニュースは、殆どの良く知られたアプリケーションにとって、Officeバイナリファイルフォーマットを読み書きしようと試みることは誤った決定だということだ。あなたが真剣に考えなくてはいけない代案が2つある。Officeそのものにそれをやらせるか、書き込むのが簡単なファイルフォーマットを使うかだ。
ヘビーな仕事はOfficeにやらせよう。WordとExcelは実に完全なオブジェクトモデルを持っており、COMオートメーションの手段が可能で、これであなたは何でもプログラムでやるようにできる。多くのシチュエーションでは、Office内のコードを再利用するほうがそれを実装しようとするよりも良い。ここにいくつか例がある。
この手のアプローチは、全ての種類の一般的なOfficeタイプについての、サーバ上であなたがやりたいと思うであろうアプリケーションで、うまくいくだろう。例えば:
これらのケースの全てにおいて、Officeオブジェクトにインタラクティブ動作でないことを教えてやる方法があり、だから表示をアップデートするのに煩わされたり、ユーザに入力を促す必要はない。ところで、このようなやりかたでいく場合には、gotchas(?)がいくつかあり、そしてそれはMicrosoftは公式にサポートしているものではない。だからあなたがそれを始める前にはKnowledge baseの記事を読むように。
書き込むファイルにはもっとシンプルなフォーマットを使いなさい。単にOfficeドキュメントをプログラムで生成したいなら、殆どいつでもOfficeバイナリフォーマットよりももっと良いフォーマット、WordやExcelでも問題なく開くことができるようなフォーマットが存在する。
いずれにせよ、全てのOfficeファイルを完全に読み書きできるような、文字通りのOffice競合製品を作ろうとする(その場合には、何千年もの作業があなたに予約される) のでない限り、Officeバイナリフォーマットの読み書きをするというのは、何であれあなたが解決しようとしている問題を解決するためのもっとも労働集約的な方法だ。
高専の化学っぽいところ出て、大学の化学っぽいところに編入して、
東京来て、初めての仕事でPHPで、誰に頼ればいいかもわからず、
使ってた言語？VB4とHSP2でしたが何か。
初めての仕事で学んだこと
その後もいろんな会社で
とか、けっこう酷いことをして、たくさんの人に迷惑をかけましたが、
今ではそれなりにIT土方をやっている。
…という俺から見ると、PHP初心者罵倒は、見るたびに、なんだか恥ずかしさを思い出す。
ああ、明日も仕事だし、勉強するね。うん。みんなごめんなさい。それは全部俺がやった事です。
あれです。
ごめんなさい。
これまで某社のPCをバラバラと調達していましたよ。
だけど、PC一括発注をするに当たって額が大きいので、
一次見積もりの段階（仕様なんかを考えるのに構成をいろいろ考えて見積もった）では、
わずかな差でライバル会社勝利。
これまでの某社とのやりとりを変更したくなかったので、
営業担当にこっそりと耳打ち。
結果、某社は無事PCの受注を獲得しましたとさ。
うちもこれまでよりやすくなって、手順を変えずにすんでハッピーハッピー
はて、これって民間の任意契約なら、問題ないけど、役所の発注でやるとアウトだよね。
でも、現場の担当者としては、現状うまく回ってるものを変えたくないんだよなぁ。。
人の介在できない、一発電子入札にうつってくのもしょうがないか。。。
あと、OA機器仕様書にグリーン調達基準とか、特定メーカーしか満たしていない仕様を
書き込んで、事実上機種を限定する手法もなんとかしろと
部長「やあ班長君、前のアレは客先でとても評判が良かったよ。」
班長「ありがとうございます。」
部長「ところでこれ読んだ？『優秀なナースがいるとシステムがなかなか改善されないという話』」
問題は、ナースたちが優秀であればあるほど、システム上の問題点が病院の経営側に伝わって来ないこと。ナースたちにとってみれば、システムの欠陥を指摘する・他人のミスを指摘する・ミスの原因を徹底究明する・経営陣に改善を申し出る、などは彼らの仕事ではなく…
班長「なんですか？」
部長「ソーシャルブックマークで話題で目に付いたんだけど、ウチにも当てはまるんじゃないかと思ってね。」
班長「うーん、なるほど…」
筆者は「だから病院の経営陣は、ナースの日々の活動に常に近いところにいてどんな問題を彼らが解決しなければならないのか、どんなところに余計な時間を費やしているのか観察し、積極的に手を差し伸べてシステムを改善しつづけなければならない。（略）」と結論付けている。
部長「君はウチではダントツ優秀でとても助かってるんだが、どうだろう、そういう傾向もあるんじゃないかな。」
班長「そうですね、私も何気なくやり過ごしている部分を気をつけてみます。」
部長「そうなんだ。だからこれから今までの仕様書だけでなくてね、もう少し新入社員にも参考になるノウハウも含んだドキュメンテーションにするとか、問題報告をまとめて改善提案として提出するようにお願いしたいんだ。」
班長「えっ？（それも俺がするの？）」
部長「そう、君は優秀ゆえに問題を見逃してボトルネックとなっているわけだからね。」
班長「（駄目だコイツ、早く何とかしないと。）」
ブクマがたくさんついていて、それに対するIT業界の成功者みたいな人のブログの反論の記事にはあまりブクマがつかないよね。まあ、才能のあるやつと一緒にするなと言うことかな？（挨拶）
あまりブクマがつかなかった記事なんだけども、もはや「（笑）」の意味が変わってきているところが面白かったということで紹介。
スイーツ（笑）＠マ板
http://alfalfa.livedoor.biz/archives/51170208.html
個人的にウケたところをコピペ。
4 仕様書無しさん :2007/11/09(金) 16:10:53
5 仕様書無しさん :2007/11/09(金) 16:19:09
6 仕様書無しさん :2007/11/09(金) 16:19:39
8 仕様書無しさん :2007/11/09(金) 16:43:16
納期(笑)
12 仕様書無しさん :2007/11/09(金) 17:04:23
21 仕様書無しさん :2007/11/09(金) 20:28:51
金曜日(爆笑)
23 仕様書無しさん :2007/11/09(金) 23:42:51
24 仕様書無しさん :2007/11/10(土) 00:36:21
親睦会(笑)
30 仕様書無しさん :2007/11/10(土) 11:56:57
えいやで（笑）
78 仕様書無しさん :2007/11/11(日) 20:48:21
lisp みたいだｗ
103 仕様書無しさん :2007/11/12(月) 23:54:57
「渡された仕様書を実装する・・・」
http://satoshi.blogs.com/life/2007/10/post-4.html
など、日本のソフトウェア系開発の問題点を指摘したエントリをよく目にするようになった。
何でも、上記のようないわゆる「外注」「孫請け」的な開発手法は日本の特徴なんだとか。
上記エントリの趣旨とはずれるが、ほとんどが「やはりいいものを作るには自社開発
（というより、エンジニアとプランナーとデザイナーとマーケティングとプロジェクト・マネージャーと
その他諸々の人が常に対等に議論を交わして、ひとつのものを作り上げていく）
がよし、最上」と結論付けている気がする。
これに真っ向から異論を唱えるわけではないのだが、
タイトル通り「Webプランナー（≒ディレクター≒プロジェクトマネージャー）」である立場から、
ちなみに私は、サーバから開発・運営まですべて自社社員で行っている企業と、
大事なところだけほとんど口頭で説明して、「あとはやっといて」的ないわゆる「丸投げ」でサービス
運営を行っている企業の両方を体験している。それぞれ日本人なら知らない人の方が少ない
名前の通った大手企業である。
■自社開発
○利点
・どんなときでも、プランナー（以下、P)とエンジニア（以下、E）が近くにいること。
分からないところ、納得がいかないことがあればすぐに、徹底的に話し合うことができる。
→多分これが一番重要で、もう一方には決定的に足りない部分。
・時に「戦友」と呼べるような深い仲間意識が芽生える。
関係ないが、PJにずっとかかわっているのにその人が「派遣社員」というだけでどうしても変な一線ができる。不思議なもんだ。
○欠点
・どんなときでも、PとEが近くにいること。
気分が乗らない日も、イライラしている日も。分かっているのに「俺が残っているのにあいつだけ先に帰りやがって」
と思ってしまう日も。
・相手のやっている仕事、能力をすべて理解できているわけではないから誤解が生じる
例；E→P（こんな無茶苦茶なことできるわけないだろ。これだから素人は困る・・・）
例；P→E（こんなこともできないのか。本当かな・・・ こいつが「使えない」だけなんじゃないのか）
→結局これがすべて。極論すればPはEに「頼むから俺の言ったように黙って作ってくれ【考えたのは俺だ】」と思っているし、
EはPに「何で俺がこんなもの作らなきゃいけないんだ【作るのは俺だ】」と思っている。
■丸投げ
○利点
・「開発」する人と「発注」する人が明確に分けられている。そこには何せ「お金」が挟まっているから関係性が揺るがない。
・行き違いで人間関係が変にこじれることがない。そもそも存在しないのだから当然だが。
○欠点
・いかんせん、発注する側が「そのこと」に関して詳しくない場合が多い。「何でできないのか」「これくらい簡単だろ」と
簡単に言い過ぎる。そして、同じ理由で本当にいいものができることが、ほとんど絶望的にない。
しまいには、開発元のEが「デスマーチ」や「うつ病」など深刻な状態に巻き込まれる。
で結局何が言いたかったかというと、開発でも何でも「人間」が行っている以上、そこに「人間関係」という問題が発生
してきて、それはもう本当に不可避で、うまくいくことは稀。
「それも含めてPMが管理しろよ」と言われればそれまでなんですが、それは本当に一筋縄でいくようなことじゃない、超大変なタスク。
で、その「超大変なタスク」を切り離して物事を進めている「丸投げ」スタイルも、それはそれで合理的な方法なんじゃないかな、ということです。
少なくとも、今はそう思っています。
ちなみに私のスペックは
・アイデア豊富で面白いことを考えついて、全部自分で作っちゃえるエンジニア
であることは間違いないでしょうね。そんな人が世の中に何人いるかは別ですが。
