  |
はてなキーワード: 仕様書とは
＞それなら、最初に大雑把に投げて、後からダメ出ししまくる方が楽じゃねーの？
その通り。
組むときは仕様書に記載されてる通りの順序で作るわけじゃない。
書かれてるものを全体として眺めて、そこからプログラムの大まかな流れを作り実装を進め、細部の仕様書記載はその部分を作りこむ時に初めて参照する。
だから、全体的なザックリ仕様を先に投げといて、後で項目仕様だとかエラー仕様だとかの詳細を追加する、で十分。
そういう進め方をして怒られるというのでもなければ、「最初に大雑把に投げて」を１度やってみたらいいと思う。
大事なのは仕様を実装者に理解しやすく・誤解なく伝えることであって、それが仕様書だけで完結するものでもないと自分は思う。
設計者である増田と、プログラムを組む実装者とは位置的に離れているのか・率直なコミュニケーションが難しいのか（オフショア等）、
だって、細かく書けば書くほど全部読まないんだもん。
画面設計書いて、そこに表示する項目と入力項目を細かく表に書いて、そこにその項目は必須入力じゃないって書いてあるのに、
受け入れテストで入力エラーが出ないとはずのところで入力エラーが出るの確認する。
ちゃんとエラーメッセージの表を作って渡してるのに、メッセージが間違ってる。
データ項目としては定義されていないが、この機能は別の項目にこういう入力をして表現するからこういう動作をしてくれって書いたと思ったけど、
仕様書通りになっているかどうかのチェックから始める必要があるのはおかしいだろ。そこは仕様書書かせるなら最低ラインじゃね？
CTC → A社の発注が 5000万で、B社に丸投げだったら、2500万くらいだろう。
A社のCTCへの見積もりは、見積単価が 120万/人月（ちょっと安いか？）で、40人月くらい。
A社の原価率を85% として、原価が 34人月。
B社の単価を 80万/人月としたら、マックスで 2720万。
多少駆け引きがあって、2400～2500万ってところが妥当では。
・ニトリは内製っぽいけど...
ニヨニヨするとか言われてたページには、こんなコメントが入ってる。
＜!-- Customize for NITORI start--＞
＜!-- Mod for Nitori End --＞
WebSphere をミドルウェアに決めたときに、カスタマイズも発注してたことは十分考えられる。
「これは仕様通りです」とかなんとか、そんなやり取りをいっぱいしたんだろうな...
・ベータ版なんて作らない
ウォーターフォールで一直線。
ニトリ社のレビューというか、受け入れ試験があったとして、そこで出されるのは
完成品、もしくシステムテストがある程度残っている本物。
リニューアルオープンが延期したのは、本当に間に合ってないだけ。
6月1日が延期したのも、ろくに動くようなものじゃなかったんじゃないか。
リニューアル後の性能問題も、何だかんだで一週間で復旧できたわけだし。
・表に出ないだけで...
ふわっとした仕様書を杓子定規に実装した、というよくあるパターンな気がする。
別ウィンドウで表示される「リニューアルオープンの遅れに関するお詫び」にまで販売サイトのヘッダ、フッタがきっちりと表示されている。
http://www.nitori-net.jp/store/ja/ec/%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B6%E6%9C%8823%E6%97%A5
この硬直さもウォーターフォールっぽい。
css がど真ん中に挿入されているのも、さもありなん。
○朝食：なし
○昼食：おにぎり二つ
○夕食：和風サラダ（豆腐、キノコ、オクラ、大根）、とんかつ、みそ汁、ご飯
○調子
うーむ、PG工程は手早くスケジュールよりも早く終わらせられたのに、PT工程はイマイチだなあ。
反省。
○ポケとる
そろそろ飽きてきた。
○みんなのポケスク
１８３種類のまま変わらず。
課金したい。
ストーリー的には、サザンドラが命の声と呼ばれる謎生物であることが明らかになったりした。
○ポケモンOR
メンツは
ゲッコウガ、ヤミラミ、ヘルガー、ダーテング、ズルズキン、バルジーナ
サンパワー晴れ熱風が外れて、負け。
こればっかりは仕方ないね。
○オリとくらやみのもり
ストーリーはちょっとよくわからないんだけど、雰囲気がかなり良い！
アクションの挙動も楽しいし、成長要素も相まって、かなり動かしてて楽しい！
どうもスーツです。
http://b.hatena.ne.jp/entry/d.hatena.ne.jp/NOV1975/20150512/p1
これのはてブと元記事見て血圧上がったので、チマチマ反論するよ。
記録を軽視するな。
業績が個人について回ったら、誰も保守しないだろ。
金を生むのかそのドキュメントレビュー。リファクタリングでいくら稼げますか？
ロボットアニメの博士みたいにな、空中から予算が湧いて出たりしないんですよ。
誤解があるみたいだから言っとくが、評価には減点も加点もある。
ただ、スケジュール前倒しで予算が浮くようなシステム作ったりしてないだろ。
何故ならばスケジュールは常にキチキチで、間に合わなきゃ減点されて当たり前だ。
そこは同情する。
見積は常に過少で、調整は過小評価され、日程だけが評価軸になりがちだ。
オマエらが椅子を滑らせて隣の同僚と１分会話して実施した内容は、キサマが風邪引くと誰にも共用されない。
コードレビューした。仕様書レビューした。まあギークが言うなら内容に間違いはないんだろう。
だが、その部分は三年前に転職した同僚がやったはずです？それじゃダメなのは判るよな？
オマエ独りで完結するプロダクトをオマエがケツもって仕事するなら文句は言わないが、違うよな？
本来は「指摘事項ゼロ」「問題がないか再精査しろ」「再精査したが無い」「一筆書け」「書いたから通せ」をやるのが正しいというのは判る。
やって欲しいのか。
ギークが不要だと思ってるレビューに、さらにチェックリストが加わったり、書類が増えたりするぞ。
正しい数字で出せ。
恐らく上から順番に怒られた上にいらん書類を書かされた上に再発防止策を延々と書いた挙句、本業であるコードを書く仕事が遅延して、さらに同じことがループするが。
政治的に正しいんじゃ無いんだよ。
そうした方が、ギークの遅延が少なくなると思うから、スーツが知恵絞ってんだ。
ギークが一度遅延したが最後、遅延が無くなるまで延々と再発防止策（しかも一度着手しているのでスケジュール見積もりについて以外でだ）書かされるぞ。
その「どんなに正しくても」は、どこの誰が担保してるんだ。
ギークの勘か？
オマエが言えよ。
言えないならその立場に無いってことだ。
「常識で考えればこうする」というのは、何時の時点の誰の判断だ。
たった30年前までメインフレーム全盛だったが、常識的に今後はオープンシステムだと断言できたか？
違うだろ。
オマエの書いたソースが間違ってて、コンピュータはソース通りに正しく動くんだよ。
バッドノウハウなのは認めるが、誰も幸せにならない正しさを貫くことはギークとしての職責の一部か？
もしそう思うならそうしろ。
責任は取られてるんだよ。
はんこの数だけな。
機械学習の重み付けと同じでな、それがスーツの出世パラメータに影響してんだよ。
記録を軽視するな。
証拠を残せ。
「なんでバグが無いのが判ってるのに単体テストするんだよ」とか言って、テスターがサボったら困るのは誰だ。
ただ、監視システムにタイムレコード追加するより、カメラ範囲内に時計を置くのがハックなんだろ？
コードスニペットは溜め込むくせに、口頭で言った内容をメールで送れないのは何故だ？
ギークなら可読性を上げろコメントを残せソースを引き継げるようにしておけ。
JavaコンパイラにC++のソース突っ込んだってエラー吐くだけだ。
まあ、見通しが悪いと思うなら、オマエが新言語作ってくれても良いんだぜ？
平岡さんが先月末で辞めた。その少し前に打ち明けられて理由を聞いたら「興味がなくなった」と短い答えを貰った。２年間働いた結果がそれだったのだけれど、辞意を伝えるといろいろ止められたが、給料をあげれば残ると言ったらあっさり引いたそうだ。
平岡さんはすごい人だった。一緒に働いた２年間、僕はすごいと思い続けた。プレゼンテーションサーバ、ロジックサーバ、データベース、経路のアライアンンスとすべてのチューニングが行え、Beanだってばんばん修正していた。ドキュメントをばんばんつくって公開していた。マネージャが聞きかじってきた新情報はすでに実装までこなし、たまーに営業が持ってくるドラフト段階のキャリア案件の実装だって仕様書とリファレンス、サンプルから作り上げていた。「絵と音がつくれないからなー、これくらいはしないとね」と笑った顔を思い出す。僕がしらないところでまだまだすごかったのだろうと想像できるくらいすごい人だった。
まずマネージャが「平岡ならこれくらいできたぞ」と怒っているのをよく見かける。営業から「平岡さんなら次の日の午前中にはもらえたんですが……」と上司にいいよる。公開サーバのチューニングだってインフラ部門担当者が２人がかりで今週今日までかかってまだ解決していない。平岡さんならもっとはやく解決できたんじゃないかな、と思っている。言わないけど。
平岡さんが入社したころはみんながすごいとおもっていたんだろう。そのうちみんなが平岡さんに「慣れて」しまう。そして平岡さんを想定して計画を考えるようになってしまったのだろう。あれほどすごい人を「最低限：平岡」という基準にしてしまったのだ。結局、烏合の衆が残った。たばになっても平岡さんには届かない。
計画を左右するほどのすごい人を、どれくらいの給料で使っていたのだろう。でも平岡さんが辞めた理由は給料の問題ではなく「興味がなくなった」のだという。本当に技術が好きな人は給料で満足を判断しないのだ、とよく見かける言葉の意味がよくわかった。
会社は平岡さんを満足させ続けなければならなかっただ。いや、満足できないくらいあたらしいものを提供し続けなければならなかったのだ。かわりに給料を出すならまだしも、その更改を願ったらあっさり彼を手放してしまった。どれほど釣り合わない値段で平岡さんを使っていたのか想像しているのだろうか。
平岡さんのように「都合のいい人」と同意の関係が構築できれば、それは幸せなのかもしれない。だけれど、もし、居る理由がなくなったらあっさり興味のある場所へと移動してしまうのだろう。無邪気に。そして平岡さんなきあとも、会社は続く。都合のよさはもうない。あれほどの計画を左右する人を手放してしまってもまだ、平岡さんを基準として考えることになれてしまった自分を理解もせずに。
元編プロが口を挟む。
版元＝上流プロジェクトマネージャ。予算と納期とざっくりRFPを書いて編プロと印刷会社にお金を回す。終盤で品質チェック（ほぼ主観）することも。
↓
編プロ＝現場PM＆SE。仕様書と画面遷移図書いて、人集めをして、使用ライセンスとかの管理して、PGの世話をして、デバグして、ビルドデプロイして、プロジェクトを締める。
↓
筆者＝PG。書く。
みたいな感じだった。うちのとこは。
あと校閲さんが外注デバッガみたいなもんなんだが、伝統的に版元がお抱えしてたりする。デバッガなんで、企画そのものとかUI画面遷移そのものにはダメ出ししてくんない。それは編プロの仕事かな。あと印刷所＆取次iOSアプリで言えばApple（iTS）みたいなプラットフォーマーなイメージ。
PGは、まず見積もりを依頼されます。この時ほとんどの場合、要求仕様書が無いか、あっても伝聞で情報が欠落もしくはエラーを起こしています。残念ながらエラー訂正機構は装備されていません。CRC、せめてパリティでも入っていればちょっとは違うかもしれません。期待出来ませんが。
ここでプロジェクトマネージャー（又は管理者・経営者等。以後PMと称する）から「最速でやった場合」「割り込みが入らない場合」「君がやった場合」or「部署内で最高ランクのPGがやった場合」「仕様変更が無い場合」という条件が付きます。
底辺PG諸君。ここでこの言葉を額面通りに受け取ってはいけません。
「【最速で】3ヶ月かかります」
と答えたらPMは【普通に】3ヶ月の工程を工程表に書き、見積書に3人月分の金額を書きます。そしてこれは後述する危険と隣り合わせとなります。
この危険を経験したPGは大抵リスクを込みで【黙って】見積もりを伝えます。
しかしPMはお見通しです。「高い」「そんなに時間がかかるわけが無い」と言い、受け付けません。何故なら実はPMの頭の中では既に「3ヶ月」なのです。PMは追い込むために見積もりの詳細を聞いてきます。
ここで素直に「リスク込み」と答えてはいけません。既にPMは前述の前提条件を述べているからです。無下に却下されます。
戦いたいPGかつPMが同じ会社であれば「後学のためにPMの詳細見積もりをお聞かせ下さい」と聞いてみるのも良いでしょう。ただし確実に印象悪化は避けられません。PMが発注元の場合は禁句です。まずキレます。そのまま発注されない事もあるでしょう。発注されなかった事を喜びましょう。
なぜキレるか。それは簡単です。「明確で論理的な理由が無いから」です。理由が無い上に実は既に予算が決まっており、それを超える事は許されません。予算を超えた見積もりはPMがさらに上層部・経営陣から怒られる事を意味するからです。理由が無いから理由をPGに考えさせているのです。PMが仕事をした気にさせるのも底辺PGの役目です。
予算を超えた見積もりはあり得ませんので、答えは「がんばります」しか残りません。しかしPMはそれすらもPGの口から言わせたいのです。でもよく考えて下さい。あなたの脳はオーバークロック出来ますか？
底辺PGが出来る事は、PMやユーザーが分からないように期間と予算を加算するくらいです。
一応、市場原理が働くため、安い方がいいに決まっています。金払いのいいユーザーや元請けってのはあんまり無いです。そして金払いの悪い所ほど後々してやられますので、最初の予算の付け方でどういう所かが大体予測出来ます。
そんなわけで、予算と期間に品質と内容は関わりがありません。もちろん企業の使命として、安くて良い品を、安くても利益を、は追求してしかるべきなのですが、日本の場合質と金額が比例するのは極一部。IT業では基本的に、安くて良い品を出来るだけ高速に、がモットーです。受注しなければ会社がやっていけないのは分かりますが、「安さ」だけしか売り物に出来ない会社は、IT会社として失格でしょう。
かくして、短納期低予算のプロジェクトが組まれるわけです。そのPMの理論からすると、高速バスで東京から新大阪へ行く方が、新幹線のぞみの指定席グリーン車で行くより高く、書留速達の郵便より普通郵便の方が値段が高い、という事になりますが。質、時間、価格の何がIT業と違うんでしょうか。
実のところ発注や作業開始は遅れている事が多く、納期に間に合わせるには発注前に作業を開始せざるを得ない場合が8割ほどです。実はここにも罠が仕掛けられています。
作業に取りかかろうとようやく出てきた仕様書を見ると、見積もり時の時と変わっていたり、追加されていたり、未だに仕様が無い場合がほとんどです。
「こんなものをこんな期間で出来やしない！」と憤慨してはいけません。なぜなら
という答えが返ってくるだけです。PMが見積もらない理由がここです。PMに見積もりを聞いてはいけない理由がここです。これは後々まで効いてきますので注意が必要です。「前提条件と違う」と反論するのは無駄です。PMはそれは忘れています。そもそも考えて発言していないので口が勝手に脊髄反射で言った事であり脳は関知していないのかもしれません。PMにとって最重要な事は「PG自身が言った事」です。そう、工程表にも議事録にも「3ヶ月」という数字のみが記載され、いわゆる「リスク」は何処にも書かれて残っていません。
PMやユーザーは絶対にリスクや前提条件を書き残しません。それがこの業界の伝統ある慣習だからです。
ここで言った言わないの不毛な戦いをしてもいいのですが、確実に査定は最低です。もしプロジェクトから外されたらそれは喜びましょう。
管理者や経営陣等からは「やる前に出来ない言うな。やってから言え」と怒られます。残念ながらこれも真に受けてはいけません。
設計、構築など作業をしている間もどんどん仕様変更・追加は流れ込みます。
PMは工程進捗を把握しているのでは無く、PGが【自ら】工程表や報告書に纏めます。遅延していれば遅延の理由も書き、挽回策があればそれも書きます。しかしPG個人が取れる挽回策などたかがしれています。と言うよりそれが分かっていれば遅延などしません。他の策は既に実行済みなので、挽回策には「残業・休日出勤」くらいしか書く事が残りません。しかしこれは現実にこれしか書く必要がありません。なぜならPMはこれ以外の挽回策は理解不能だからです。
仮に報告をしても「早すぎる。もっとやってみてから」「がんばれ」という答えが返ってくる事でしょう。
遅れを放置するPMもいますが、許容範囲はPMにもよりますがある程度遅れが見えてくるとPMから追求がやってくるようになります。
「なぜこんなになるまで報告しなかった」
そう、報告出来る時期というのは非常に限られています。多分プロジェクト工程（今の例なら3ヶ月）の中の30分くらいです。それより早いと相手にされず、それよりも遅いと怒られます。報告時期を見誤らないのもPG業の技です。
実装が難しかったり、無理難題は多々あり、その上工程が遅延しているので、相談をしに行きます。しかし、それは無駄です。
「自分で考えろ」
「やってから言ってるんじゃねぇ。やる前に言え」
他似たような答えしか返ってきません。非常に非生産的です。理不尽です。時間の無駄と考え報告・相談に行かないPGも多いとか。非生産的ですが、一応相談はしておきましょう。ただし時間は取られないように。
同僚やチーム員に相談してもいいのですが、昨今のプロジェクトは人員がスタンドアロンで動いています。したがって、隣の人やチーム員がが何をやっているのか知らない事が非常に多く、相談出来ない事も多いのです。PGにメンタル病が多いのは実は理由がここにあると自分は思っています。孤立感が半端無いのです。まぁ、元を追えば、そいういうチームを組む事、教育訓練しない事など、実は管理者・経営者が「カイゼン」や「効率向上」を題目に目の前の超短期的コスト削減だけを考えている結果なので、PGとしては何も出来る事はありません。管理者・経営者は中長期について考える必要が無いからです。なぜなら「その頃には自分は満額の退職金を貰って定年退職済み」だから。
実のところ単独の仕事をしていればいい、と言う事はあり得ません。同じプロジェクトの中からも割り込みや、他のプロジェクト・部からも割り込みは多々入ります。
始めに言ったじゃん。どうにかして。というのは無駄です。覚えてないし、「会社員なら当たり前だ」という答えが返ってくるだけです。「15分だけ」「ちょっとだけ」が頻発しますが、塵も積もればなんとやら、です。ちなみにこの件は査定・人事評価には全く影響がありません。
相談すれば「午前中はこの仕事、午後はこの仕事、定時後はこの仕事をすれば並列同時が可能だ」とあたかも新発見超名案を出したかのように返されるのが落ちです。そう、1日が24時間しかない事は忘れ去られ、PGが人間である事は忘れ去られ、思考の分断は効率を激しく低下させる事を知らないのです。
ここで断る勇気を持つのが大事ですが、職場内の雰囲気は格段に悪化します。評価は「人でなし」「自分勝手」「自分本位」「冷たい」。これらの視線に耐えられるのなら断りましょう。こちらからすれば「自分の時間を奪う方がよっぽど人でなしだ」と言い返したい気分です。
テスト工程も始まり、遅延が激しくなる上に、バグが発見されさらに遅延という状況が始まります。
ソフトウェアである以上、バグが無いプログラムなんてのはあり得ないのでバグを出す事自体は不可避です。
ところがPMは激しく怒り出します。バグの発見はPMに一報が行きPMが怒られるからです。
底辺PGはバグを出す毎にこっぴどく怒られます。中には仕様変更の事実がPGまで伝わっていないのにバグ扱いされる事も多々あります。
バグを出すと修正、テスト、再発防止策の考案などの厄介事が増えます。
再発防止策は通常「どうやったら自動的にそうならないか」を考えますが、あまりに根幹すぎるので、底辺PGの身分では権限が無く、出来る事が限られます。そしてPMが理解出来る策を考えねばなりません。結果「テストを増やす」「チェックシートを作る」とかになりがちです。しまいには「チェックシートのチェックシートを作る」などという意味不明の現象に陥ったプロジェクトを何度も見ています。
厳しく、それは厳しく怒られる上に、チームの前でさらし者にされる事、人格を否定される事も多々あるので、PGはバグを出さないように、見つけても出来るだけ極秘裏に解決しようとします。
「恐怖駆動型開発」
というもので、日本の場合ほとんどがこの開発手法をとられていると聞きます。この開発手法は書籍になっておらず、書籍としてよく売られているのはアジャイルな開発手法の本が多いです。知識として持っているのはいいと思いますが、役に立たないと思いますねぇ、恐怖駆動型開発の前には。まわりの人間も恐怖に巻き込まれないようにするため、どんどんスタンドアロン化が加速します。
その上、バグを隠すようになり、バグが出るようなテストを避けるようになるため、短期的に収束しているようにみえます。だから効果絶大と見るようです。リリースしてからが楽しみですね。
PMが空想から覚め、もう救いようが無くなった事が事実と認識出来るようになった時、ようやく、2度目の相談・報告時期が訪れます。ただし、PMの第1声は「どうしたらいい？」です。そんな事が分かっているのなら実行済みなので、黙っているしかありません。
するとPMは「何人入れれば良い？」と聞いてきます。意味が分かりません。IT業を労働集約型産業と勘違いしているのが未だに存在している事に驚きです。頭脳集約型の形態に人を入れて解決しようとはどういう脳をしているのか。一度解剖してみたいものです。多分、高校を受験する中学3年生の受験者が100人集まれば旧帝大の入試に合格すると考えているのでしょう。もしくは1Km走というのは1000人が一斉に1m踏み出せば1Km走った事と同じ記録である、と考えているのでしょう。
脳を電通で直結出来れば若干違うかもしれませんが、IT業の1＋1は2では無く、良くて1.5。ましてやこれで増えていくのは3～4人までが限界でそれ以上は人を入れても上がらないどころか、マイナスになる事が常。
PGなら他のプロジェクト、他の部、他の会社に信頼出来るエース級のPGを何人か知っているかと思います。なのでついPMに「エース級を3人」等と提案しがちです。しかしこれは叶わぬ望みです。その提案に対する答えは「そんな事出来るわけないだろ」です。そりゃそうです。予算が無いのだから。
自分の仕事があるのに、何故かこの後から来た人員を纏めるようPMから指示が出ます。PMが指示出来ないからです。破綻は間近です。いや、既に破綻しています。
プログラムが出来上がっていく以上、バグをつぶす速度以上の割合でバグを注入していく事になります。
「混乱しているプロジェクトに人を入れれば、なお混乱するだけ」
という有名な文を実感する事でしょう。なお、実感するのはPGだけであり、PMは実感出来ません。
この辺で思わぬ事態が発覚します。実は発注が遅れていた事です。
発注日以前にドキュメントがあっては監査にひっかかるため、今まで作ったドキュメントを作り直しをしなければならないという、まさに想定外の事態です。ほとんどのドキュメントには作った日付や判子が押されているはずです。それを全部作り直しするのです。納期は間際です。これも納期までに間に合わさねばなりません。
PM（重ねて書くが、プロジェクトマネージャだけでなく管理者や経営者も含む）が発狂し始めます。宛先は底辺PGです。
中には「お前を精神的に追い詰めるしか手がねーんだよ」とストレートに言ってくれるPMもいたりしますが、あまり出会った事は無いですね。
あの手この手で精神的圧迫を始めます。圧迫すれば脳がオーバークロックして作業が進むと考えているからです。残念な事に、脳の別の部位がオーバークロックしてショートしてしまいます。
こういうプロジェクトを経験し、運がいいのか実力なのか、生き残った人達がSEとなり、いずれPMとなっていきます。
不思議な事に日本では、PGが成長してSEに、SEが成長してPMに、とクラスチェンジするものだと考えられている会社が多のですが。
自分としては、座標軸のX,Y,Z軸の様にPG軸とSE軸とPM軸と全く異なるベクトルだと考えています。X軸の先にY軸Z軸があるわけでは無い、と。もちろん、軸に沿っているだけでは無く、他の軸のベクトルも併せ持つのもよいエンジニアでしょうし、ベクトルの方向を伸ばし続けるのもよいエンジニアでしょう。
ところが、クラスチェンジするものだと管理者・経営者は思っているから、給与体系もPG＜SE＜PMとなっていたりします。この時代錯誤的階級社会はどうにかならないものでしょうか。
自分はPMを否定しているわけではありません。いいPMの元でいい仕事をしたい、と思っているだけです。今までに何度かそういう良い経験をした事はあります。それは成功経験としてモチベーションを保つために必要な事なのです。
PG至上主義でもありません。分業形態として、SEやPMは必要不可欠だと思っています。ただ、PGを粗末に扱っておきながら高品質の製品を要求する風習・慣習が納得出来ないだけなのです。
542 仕様書無しさん sage 2015/01/23(金) 12:39:08.24 >>541 ちょっと違うと思う。IT疎い人はこういう説明でなるほど開発会社が悪い！となって、裁判官も多分そう思って判決出してる。 普通に運用しててビニール入るのは欠陥だが、SQLインジェクションは欠陥ではない。 俺が思うに、ローカルのディレクトリが外から見えるようになってたとか、認証掛けてるつもりがかかってなかったとかが重過失。 何故ならそれは家に鍵を掛けずドアが開いているか、ドアがないのと同じだから。 泥棒するつもりのない人でもうっかり入って来れちゃう。 それに対しSQLインジェクションは犯罪者がすること。悪意を持って行われる攻撃行為で、一般人はやらない。 家で言うと鍵のピッキングだな。 ピッキングで泥棒入ったら工務店が悪い、みたいなのが今回の判決。 ピッキングにどこまで耐えられるように作るべきか、事前に仕様で決めておく必要がある。今回はSQLインジェクション対策が仕様に入っていなかった。 仕様にないから強い鍵を付けなかったら破られた。これを重過失ってのはひどすぎ。重過失って故意に匹敵するレベルの過失だぜ。契約書の賠償上限無効にしてしまう程の。 俺の考えはこうだ。SQLインジェクションなどセキュリティ対策の実装について、 仕様に書いてあった → 重過失 仕様に一切無し →無罪または普通の過失 パスワードがadmin/passwordとか改善の提案を拒否したとか別の話も話をややこしくしているが、話のコアの部分は以上のようなことだと思う。
童貞なのに童貞だけど相手は処女がいいとか無理に決まってんじゃん無理無理無理。どう考えてもエロエロな経験豊富なお姉さんに一方的に何もしなくてもエロエロでアヘアヘにされる方がいいです。
つまり何が言いたいかって言うとHello Worldくらいしか書けないのに何故か開発プロジェクト一人チームで仕様書もないし要件も定まってない所に大変そうだから一人増やすね！！！(未経験者)とかまじ無理なんで。。
まじ童貞と処女で作るとかマジ無理なんでどうせ一人増やすならなんでもしてくれる経験豊富なお姉さんを呼んでアヘアヘにしてもらったほうが絶対捗るんで。
なぜライジングサンコーポレーションのSEってのはプログラマーに対して、仕様書に書いていない事をやらせるのか？
仕様書に記載していなかった事を作りこんでいなかったら、不具合扱いされた。
いや、書いてある事を実現出来なかったらそれは不具合と認めるよ。
「書いていない」というと「常識だろ」と言われる。あんたらの製品の常識かもしれないが、こっちには常識では無い。
ましてや、全てを底辺プログラマーのせいにして、なんとかという精神的追い詰め会議に呼び出すのはどういう事か？？？
それでも、「書いてくれ」と言い続けると、「全てを網羅出来ない」と開き直る精神がすごい。
なら「こちらも全てのエラー処理例外処理等を網羅出来ない」と言い返すのはタブーである。ここまで言うと、ライジングサンコーポレーションのエライ人達はキレる。
品質向上プロジェクトとかあるようだが、プログラマーをいびる事で品質が上がると思っていたら大間違いだ。
君たちのその開き直りを直す方が先ではないかね？
1．どこかの大学とか企業の偉い人が英単語２，３個ぐらいのビジョンを打ち立てて予算を獲得する
3．若手を集めてブレストをし，ビジョンを実現するサービスやアイデアを考えさせる
3～4を繰り返す
5．煮詰まった（行き詰まった）ところでコンセプトを作ることになる
6．企業の場合，このコンセプトを外注して作るため，仕様書・設計書等の作成が始まる．大学の場合は修論生が徹夜で作る．
7．出来上がったコンセプトを元にデモが行われ，最初に言い出した偉い人が煙に巻いたプレゼンでごまかす
1～8がだいたい1年ぐらいで，これを2，3回繰り返すと言い出しっぺの偉い人が別の英単語を思いつくので，
それを元にまた2，3年繰り返される．
結局のところ，この一連の活動はなんの礎も築いていないし，ほとんどの場合はお金を稼いだりしていない．
学術研究の予算を消化するためや，企業の研究開発費としてお金を回すためにこれが必要なこととされている．
新しいIT技術を開発するかどうかはあまり重要では無いわけだ．
そもそも，IT系の研究のアウトプットの多くは何らかのサービスになっている．
このサービスというのは実際のところやってみなければ当たるかどうか分からない．
ジョブズも言っているように，客自身が欲しい物を分かってないからだ．
必要なのはとにかくいろんなことをやってみて客に問うことが，生物系や化学系の実験にあたるわけで，
いろんなものを作って，失敗して，反省してから作り直したりしてみるしかない．
ところがこれをやろうとするといろいろ問題がある．
修論生は留年せずに卒業しないといけないし，外注するとかなりのお金と時間がかかるから，おいそれと「失敗したら作り直します」とは言えない．
結局，大学でこれを変えるには留年させてはいけないという考えを改める必要があるが，
大企業は年次で昇給したり昇進するシステムを取っており，将来のことを考えるとやっぱり留年はさせられない．
大企業が子会社へのお金の流れを変えることや昇給・昇進の方法を変えるのは労力に対して得られる物が少なすぎるためやっぱりできない．
他の分野でもそうなのだろうか．
