  |
はてなキーワード: 仕様変更とは
http://anond.hatelabo.jp/20090519230327
とりあえず演出担当が作りたい芝居を語る。酒の席だったりする。
それを何となく脚本担当に伝えてミーティング用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽいプロットとどこかで見たような演出プランに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「大人計画を演る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自の芝居」を作る事になると脚本とか演出とか以前に完成しない。
そのペラい資料をもってミーティングを行うがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。
決まらないがとりあえず作り始めてと役者と裏方に投げられる。とりあえず公演タイトルくらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の内容になる。
稽古が始まると政治的なパワーバランスなどの都合により今まで作っていた何物かはゴミ箱に行くことに。でも「もう半分くらい作ったんだから簡単にできるハズ」等と言われる。80年代の小劇場だったハズが90年代の静かな演劇になったのに。（極端だけど劇場変更はザラ。あまり大きな問題はない）
脚本担当はまた初めと同じように内容を伺う。日を跨ぐと違うことを言うので出来るだけ素早く箇条書きにしてる。なかなかまとまらないが役者と裏方はまた何かを作り出す。何を作るかは分からないが何となく配役とか場面転換の枚数を妄想して分担表とかをつくる。裏方も仮想舞台装置を作る。
放っておくと大量の配役、大量の大道具、大量の小道具、仕様の演出、労力の割に効果があまりないような話、壮大な計画がブチ上がってくるので必死で止める。
（仕様演出は仕様見ただけで分かるような無茶な物のこと。例えば100人の登場人物から3人を合成してすべて違う登場人物が錬成されて全部に名前と設定と配役が付くとか。16万通りもある事を理解できていない）
脚本担当はこの段階で死にそうになっている。一応存在する脚本担当の締め切りが迫ってくると当然毎日徹夜して脚本を作成していくのだが、なんど書き直しても「つまらない」「ここはこういうつもりじゃなかった」「字にすると面白そうに見えないから演技プランを考えて」「（仮の）名前が気にくわないからインスピレーションが～」「やっぱこうの方がいい」「昨日いいこと思いついた」等の必殺技に返り討ちにされる。仮脚本を演出に見て貰っている場合は演出に頭を何度も下げに行く。脚本担当の締め切りはもちろん守れられない。その分のしわ寄せは役者と裏方がかぶることになる。毎日毎日両部門に目に隈を作った脚本担当が「間に合わなくて済みません」と謝っている。ただし役者も裏方も怒らない。脚本担当が遊んで遅れてる訳じゃないし。一緒に仕様固めを手伝う。演出担当は怒る。
何となくあがってきた脚本担当の脚本を眺めながら稽古する。ただし細かいことは何にも書いてない。ト書きに一言だけ書かれているならましで、ト書きの存在が伝えられていない事もザラ。その当りは必要そうな設定を裏方が洗い出して役者が全体の空気を読んだ場面設定を構築して己のインスピレーションを信じて勝手に演技する。とりあえず作った物を見せると、演出に「俺の指示と違う」等と言われることが多い。指示なんかないのに。ただしこれがそのまま使われることも良くある。
稽古が中盤に入る頃には脚本がしっかり上がって……いない。絶対。時間だけが無情にもすぎるが未だ路線が定まらない。分からないところは逐一聞きながら作る。聞かないでも作る。運が悪いと何故聞かなかったと言われる。役者はひたすらリテイクを食らう。世界観と合わないとかこのキャラだけ浮いているとか。世界観なんて脚本の1ページ辺りに描かれてる程度にしかなかったりするし。脚本のセリフが気が付くと増えている。演技プランが破られている。稽古時間が足りなくなる。各自で時間を何とかしろと言われる。もうたっぷり圧縮してる。
稽古終盤。本番に間に合わない事が確定的になってから設定をとりあえず削ってみる。最初からそれはいらないと言い続けた場所を削るが演出担当は不満顔。最初から入れなければもっと早かったのにと毎度毎度言い続けてるが変わらない。リハ期間は短くてもいいとか言い出す。それで前も本番でミスしただろうに。やっぱりあそこが気に入らないから変えてとかこの期に及んで言う。役者は本人当たりセリフ量が割とはっきりしているのでギリギリまでリテイクされる。脚本担当は脚本を必死で打ち込む。演出に「演技のバランスが悪い。調整してないのか」とか言われる。その時間はお前が削ったんだ。裏方は頻繁な小道具の差し替えをしながらミスを潰していく。何度言っても脚本の差し替えはすぐ出来ると思われている。そろそろ劇団内の恋愛はやめて欲しい。役者も脳みそが足りないので勝手にセリフを削る。劇団内の恋愛は無理矢理潰す。みんな死にそうな顔をしているが激太りもしてる。
公演して糞芝居と言われる。世間一般的にミスれば役者と裏方のせいにされて（稽古しなかったから、裏方がミスをしたからと思われている）つまらなければ脚本担当や演出担当が批判される。（世間の（俺の）面白いと思っていることを理解できていない！とか）このために軸のぶれている演出担当や脚本担当は上がってきた物が面白くないと感じると仕様変更をガンガン入れてくる。たとえ本番でミスっても内容が悪くなければ叩かれるのは自分じゃないもんね。時間と金をもって来ないのにこれをする人が時間を無駄遣いさせる。裏方は本番でミスをしたくないので仕様変更が出ないよう出ないよう事前に釘を刺しに行きたがる。
http://anond.hatelabo.jp/20090519230327
とりあえずプロジェクトマネージャが作りたいシステムを語る。酒の席だったりする。
それを何となくSEに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「Amazonを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のシステム」を作る事になるとバグとか糞とか以前に完成しない。
そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。
決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の内容になる。（十字キーでリストが動くだけレベルとかシステムを一個だけそれっぽくしてるとか）
開発が始まると政治的なパワーバランスなどの都合により今まで作っていた何物かはゴミ箱に行くことに。でも「もう半分くらい作ったんだから簡単にできるハズ」等と言われる。ウィンドウズアプリだったハズが携帯のWEBアプリになったのに。（極端だけどハード変更はザラ。あまり大きな問題はない）
SEはまた初めと同じように内容を伺う。日を跨ぐと違うことを言うので出来るだけ素早く箇条書きにしてる。なかなかまとまらないがデザイナとプログラマはまた何かを作り出す。何を作るかは分からないが何となくキャラとか背景の枚数を妄想して分担表とかをつくる。プログラマも仮想工数表を作る。
放っておくと大量のデータ、大量の画面、大量の帳票、仕様のバグ、労力の割に効果があまりないような操作、壮大な計画がブチ上がってくるので必死で止める。
（仕様バグは仕様見ただけで分かるような無茶な物のこと。例えば100個のレコードから3つを合成してすべて違うテーブルが生成されて全部に名前と効果と属性が付くとか。16万通りもある事を理解できていない）
SEはこの段階で死にそうになっている。一応存在するSEの締め切りが迫ってくると当然毎日徹夜して仕様書を作成していくのだが、なんど書き直しても「つかえない」「ここはこういうつもりじゃなかった」「字にすると便利そうに見えないから名前を考えて」「（仮の）絵が気にくわないからインスピレーションが～」「やっぱこうの方がいい」「昨日いいこと思いついた」等の必殺技に返り討ちにされる。仮絵をデザイナに描いて貰っている場合はデザイナに頭を何度も下げに行く。SEの締め切りはもちろん守れられない。その分のしわ寄せはデザイナとプログラマがかぶることになる。毎日毎日両部門に目に隈を作ったSE勢が「間に合わなくて済みません」と謝っている。ただしデザイナもプログラマも怒らない。SEが遊んで遅れてる訳じゃないし。一緒に仕様固めを手伝う。
何となくあがってきたSEの仕様を眺めながら作る。ただし細かいことは何にも書いてない。オプション画面と一言だけ書かれているならましで、オプション画面の存在が伝えられていない事もザラ。その当りは必要そうな設定項目をプログラマが洗い出してデザイナが全体の空気を読んだ画面デザインを構築して己のインスピレーションを信じて勝手にプログラミングする。とりあえず作った物を見せると「俺の指示と違う」等と言われることが多い。指示なんかないのに。ただしこれがそのまま使われることも良くある。
開発が中盤に入る頃には仕様がしっかり上がって……いない。絶対。時間だけが無情にもすぎるが未だ路線が定まらない。分からないところは逐一聞きながら作る。聞かないでも作る。運が悪いと何故聞かなかったと言われる。デザイナはひたすらリテイクを食らう。コーポレートカラーと合わないとかこのボタンだけ浮いているとか。そもそもおれ孫請けだからリリースする会社がどこか知らないし。絵の枚数が気が付くと増えている。色数指定が破られている。容量が足りなくなる。プログラムで容量を何とかしろと言われる。もうたっぷり圧縮してる。
開発終盤。締め切りに間に合わない事が確定的になってから仕様をとりあえず削ってみる。最初からそれはいらないと言い続けた場所を削るがプロジェクトマネージャは不満顔。最初から入れなければもっと早かったのにと毎度毎度言い続けてるが変わらない。デバッグ期間は短くてもいいとか言い出す。それで前もバグを出しただろうに。やっぱりあそこが気に入らないから変えてとかこの期に及んで言う。デザイナは絵１枚当たり作業時間が割とはっきりしているのでギリギリまでリテイクされる。SEはテストデータを必死で打ち込む。「レスポンスが悪い。調整してないのか」とか言われる。その時間はお前が削ったんだ。プログラマは頻繁なデータの差し替えをしながらバグを潰していく。何度言ってもデータの差し替えはすぐ出来ると思われている。そろそろセレロンはやめて欲しい。デザイナもメモリが足りないので勝手に増やしている。バグは無理矢理潰す。みんな死にそうな顔をしているが激太りもしてる。
リリース前にプロジェクトマネージャが偉そうな顔して雑誌やブログにコメント。
リリースして失敗プロジェクトと言われる。世間一般的にバグれば販売元とプログラマのせいにされて（予算を出さなかったから、プログラマがミスをしたからと思われている）つかえなければディレクタやプロジェクトマネージャが批判される。（世間の（俺の）便利だと思っていることを理解できていない！とか）このために軸のぶれているプロジェクトマネージャやディレクタは上がってきた物が便利でないと感じると仕様変更をガンガン入れてくる。たとえバグっても内容が悪くなければ叩かれるのは自分じゃないもんね。時間と金をもって来ないのにこれをする人が時間を無駄遣いさせる。プログラマはバグを出したくないので仕様変更が出ないよう出ないよう事前に釘を刺しに行きたがる。
終わった頃には人数が減っている。そして募集が掛かっているｗ
とりあえずプロデューサが作りたいゲームを語る。酒の席だったりする。
それを何となくプランナに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「ポケモンを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のゲーム」を作る事になるとバグとか糞とか以前に完成しない。
そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。
決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の内容になる。（十字キーで絵が動くだけレベルとかシステムを一個だけそれっぽくしてるとか）
開発が始まると政治的なパワーバランスなどの都合により今まで作っていた何物かはゴミ箱に行くことに。でも「もう半分くらい作ったんだから簡単にできるハズ」等と言われる。DSのARPGだったハズがPSPのSRPGになったのに。（極端だけどハード変更はザラ。あまり大きな問題はない）
プランナはまた初めと同じように内容を伺う。日を跨ぐと違うことを言うので出来るだけ素早く箇条書きにしてる。なかなかまとまらないがデザイナとプログラマはまた何かを作り出す。何を作るかは分からないが何となくキャラとか背景の枚数を妄想して分担表とかをつくる。プログラマも仮想工数表を作る。
放っておくと大量のアイテム、大量のイベント、大量のモンスター、仕様のバグ、労力の割に効果があまりないような話、壮大な計画がブチ上がってくるので必死で止める。
（仕様バグは仕様見ただけで分かるような無茶な物のこと。例えば100個の素材アイテムから3つを合成してすべて違うアイテムが錬成されて全部に名前と効果と絵が付くとか。16万通りもある事を理解できていない）
プランナはこの段階で死にそうになっている。一応存在するプランナの締め切りが迫ってくると当然毎日徹夜して仕様書を作成していくのだが、なんど書き直しても「つまらない」「ここはこういうつもりじゃなかった」「字にすると面白そうに見えないから名前を考えて」「（仮の）絵が気にくわないからインスピレーションが～」「やっぱこうの方がいい」「昨日いいこと思いついた」等の必殺技に返り討ちにされる。仮絵をデザイナに描いて貰っている場合はデザイナに頭を何度も下げに行く。プランナの締め切りはもちろん守れられない。その分のしわ寄せはデザイナとプログラマがかぶることになる。毎日毎日両部門に目に隈を作ったプランナ勢が「間に合わなくて済みません」と謝っている。ただしデザイナもプログラマも怒らない。プランナが遊んで遅れてる訳じゃないし。一緒に仕様固めを手伝う。
何となくあがってきたプランナの仕様を眺めながら作る。ただし細かいことは何にも書いてない。オプション画面と一言だけ書かれているならましで、オプション画面の存在が伝えられていない事もザラ。その当りは必要そうな設定項目をプログラマが洗い出してデザイナが全体の空気を読んだ画面デザインを構築して己のインスピレーションを信じて勝手にプログラミングする。とりあえず作った物を見せると「俺の指示と違う」等と言われることが多い。指示なんかないのに。ただしこれがそのまま使われることも良くある。
開発が中盤に入る頃には仕様がしっかり上がって……いない。絶対。時間だけが無情にもすぎるが未だ路線が定まらない。分からないところは逐一聞きながら作る。聞かないでも作る。運が悪いと何故聞かなかったと言われる。デザイナはひたすらリテイクを食らう。世界観と合わないとかこのキャラだけ浮いているとか。世界観なんて説明書の2ページ辺りに描かれてる物語程度にしかなかったりするし。絵の枚数が気が付くと増えている。色数指定が破られている。容量が足りなくなる。プログラムで容量を何とかしろと言われる。もうたっぷり圧縮してる。
開発終盤。締め切りに間に合わない事が確定的になってから仕様をとりあえず削ってみる。最初からそれはいらないと言い続けた場所を削るがプロデューサは不満顔。最初から入れなければもっと早かったのにと毎度毎度言い続けてるが変わらない。デバッグ期間は短くてもいいとか言い出す。それで前もバグを出しただろうに。やっぱりあそこが気に入らないから変えてとかこの期に及んで言う。デザイナは絵１枚当たり作業時間が割とはっきりしているのでギリギリまでリテイクされる。プランナはデータを必死で打ち込む。「戦闘バランスが悪い。調整してないのか」とか言われる。その時間はお前が削ったんだ。プログラマは頻繁なデータの差し替えをしながらバグを潰していく。何度言ってもデータの差し替えはすぐ出来ると思われている。そろそろセレロンはやめて欲しい。デザイナもメモリが足りないので勝手に増やしている。バグは無理矢理潰す。みんな死にそうな顔をしているが激太りもしてる。
発売前にプロデューサが偉そうな顔して雑誌やブログにコメント。
発売して糞ゲーと言われる。世間一般的にバグれば販売元とプログラマのせいにされて（予算を出さなかったから、プログラマがミスをしたからと思われている）つまらなければディレクタやプロデューサが批判される。（世間の（俺の）面白いと思っていることを理解できていない！とか）このために軸のぶれているプロデューサやディレクタは上がってきた物が面白くないと感じると仕様変更をガンガン入れてくる。たとえバグっても内容が悪くなければ叩かれるのは自分じゃないもんね。時間と金をもって来ないのにこれをする人が時間を無駄遣いさせる。プログラマはバグを出したくないので仕様変更が出ないよう出ないよう事前に釘を刺しに行きたがる。
終わった頃には人数が減っている。そして募集が掛かっているｗ
たくさんのコメントありがとうございます。まさかこんなにと驚いています。某氏からの反応も合ってとても嬉しいです。せっかくなのでいくらか追記してみたいと思います。
仕様バグの話はネタではありません。頻繁にあることで実際に一度や二度ではなくそれがありました。私の経験では数億通りのパターンが生まれる仕様バグでした。なんでこんな事になるのかというと、仕様を考えている人が数学が不得意だから……ではなく数字を計算する癖がないからだと思われます。どんな仕様でも数字が出てくれば相応の計算を一応するといった癖がないので平然とこのような仕様が出てくるのです。
この日記は上が悪いように書いてます。私はお察しの方も多いようにプログラマです。プログラマの悪いところももちろんいっぱいあります。都合の悪いことは直接上に言わないでプランナに押しつける、データ入力時の細かい事項をプランナに教えない。遅れたのはプランナのせいだと後になって愚痴る。デザイナが指示したとおりの仕様でデータをくれない！……とプランナに愚痴る。基本プランナさんごめんなさいなのが多いですね。デザイナはデザイナで上のチェックをせずに提出したり仕事してる振りして同人描いてたりしてます。他にも色々あるそうですが細かいことは知らないです。プランナは上からの変更を周りに伝えない資料に必要事項を書かない等など。
＞これでも採算撮れるなら仕方ないなー。
細かいことは上の人間じゃないので知りませんが、赤いのは赤いです。根拠はいろいろですが、わかりやすいのは給料遅配とか。
良作はどうなるかというと本筋の流れは大して変わりません。先にお断りさせて頂きますと私は良作の制作にほとんど関われたことがありません。本当にちょっとちょっとちょっとちょびっとした良作程度の経験でお話しします。
予算や行程にゆとりがあってもより良い物をと仕様変更はガンガン入ります。むしろ入らない作品はつまらない物になります。（某氏らが言うように普通に作っていればだいたい糞ゲーです。）というのも一番最初に上がってきた構想がそのまま「誰が聞いてももの凄く面白い！ これは売れる！」なんて事はないと思うからです。（思うというのは知らないと言うことです。そういうすごい構想を語れる人もいるのかもしれませんが）なので仕様書を作るときも実際に制作を開始してても、例えバグフィクスをしながらでもいろいろな変更が入ります。「入ります」という言い方では語弊すらあります。入れるのです。現場から積極的に変更をかけていきます。自分の納期が迫る中でも良い物を作りたいのなら自分の担当分に変更を打診します。嫌な目で見られるかもしれなくても、その人の睡眠時間がなくなろうとも、より面白くなるアイデアがあるのなら他人の担当分に変更を促します。そのアイデアが入れてみたらつまらなくて元に戻して欲しい場合は、相手が死にそうな面をしていても戻そうと言います。最初から最高の物を構想できれば必要がないことなのですが、現場も上もそろって天才なんてことはないので、以上のようにするのです。そのようにして出来たゲームが余裕で糞だったりしますが。
糞ゲーは現場からの仕様変更がない、上の言うことを聞かない下が悪いのか、下にそっぽを向かれる上が悪いのかわかりませんが下が上に何も言わなくなってしまう状態だと非常に良く起こりえると言えます。何故こうなるのかというのは普通の会社と一緒です。評価してくれない。給料が上がらない。手柄を横取りされる。売れれば俺のおかげ売れなければお前らのせい。そんなことですね。「糞ゲーだろうとバグゲーだろうと俺の給料変わらないし」のようになるんですね。これを職務放棄だと言われる方がいると思いますが、まさにその通りです。ダメダメです。
ちなみに知らないですが、上から下に何も言わないような場所は最初からダメでしょうね。そんなにトップから末端まですべての人が自己管理完璧のスーパーマンなわけないですから。なので厳しいプロデューサやディレクタは絶対必要条件です。この日記のプロデューサやディレクタは気まぐれだったり本当に適当だったりもありますが良い物を作ろうと変更をしている……と思います。問題は厳しくても他でフォローできる、もしくはその役割を担当できる人がいること、もしくはそれに耐えうる強い精神力および目標とか夢がある事じゃないかなと思っています。徹夜してる人にコーヒー買ってくるくらいのなんでもない気遣いでもいいんですけどね。あんまりやるとつけ上がりますがｗ まぁ、どれもないから辞めるんですね。
最後に私も上からの視点で書いた記事を読んでみたいです。分かって欲しいとか言っても無駄とかそういう気持ちみたいなのはどうでも良くて、ただの事実として。
非常に設計部門の立場が弱いのですよ。
なんでですかね？
資材は製品を運んでこない。なんででしょう？指示の通りに指示された場所に指示された物を運ぶのがあなた方の仕事じゃないですか？なんで設計が倉庫から品物を探して運び出して自分で梱包を解いて作業しなくちゃならないのです？
設計は設計で、審査も承認も無しに協力会社や外注に仕様を投げるんですよ。まぁ、それも偽装請負だったり多重派遣だったりするわけですが。
品質に関しては何のチェック機能も働いていないですね。
一応、職印は押されてますが、ノーチェックです。ただのスタンプラリー。今ISO9001の審査をやったら確実に剥奪間違いなしです。
作業に取りかかってからの仕様変更や間違い発見が多すぎます。そこで恥ずかしいと全く感じていないのがおかしいと思いませんか？
不思議なのは何故かデスマーチになるのが設計のみ、というのがよくわかりません。他の部分は要期が長くなる事はあれども、短くなる事は無いのに、何故か、設計・製作・試験期間だけが納期短縮を求められます。それは何故なのでしょう？例えば北海道から沖縄へ移動する時、営業が「3秒で行け」と言ったら実行が可能なのでしょうか？
最後の総合試験でテスターがテストをする前に「この仕様おかしくありませんか？」と返してくる事が多々あります。そこに至るまでの審査と承認は何をやっているのでしょう？テスターに仕様をチェックされるとは恥ずかしくありませんか？
QA（品質保証部）は設計がご機嫌取りをしないと製品受け取りませんからね。
ビジネスですよ？何で設計がご機嫌取りしなくちゃならんのです？
得体の知れないドキュメントやチェックシートが多すぎます。そんなんで品質が保てるのなら誰も苦労はしません。
受け取っても、試験は設計が行った総合試験のなぞり。意味ありますか？QA独自の試験はやらないのですか？
だいたい、QAを通って出荷したのなら、品質保証はQAに属するものだと思うのですよ。QAが保証したから出荷されたのでしょ？なのに、発送後のトラブルは、お客様の伝言ゲームと化して設計に丸投げなのは何故なのです？
開発も問題外です。
作りやすいように、設計を変えてしまい、保守・運用の事を横にらみして考えるスーパーSEが存在しません。おかげで、保守・運用が非常に大変です。トラブルシューティングは出来ない、同じ意味のデータをあちらこちらに記載しなくてはならない、しかも、何故か、10進表記だったり16進表記だったり。
開発者のぼやきにおどろきましたよ。
「そんなめんどくさい事やらせるなよ」
機械やプログラムは同じ作業を何度でも短時間で出来ますが、人間は間違うし時間かかるんですよ？あなたのそのめんどくさがりが後々の保守・運用を大変にして品質を下げている事に気が付きませんか？
こんなんで品質向上なんて出来ると思いますか？
全体として品質を上げようとする仕組みが麻痺してまわってないのに、設計の末端だけに品質の責任を負わせようとするのはおかしいと思いませんか？
設計の腰の低さにいい気になって会社全体が設計を士農工商のうち、穢多・非人のような扱いをして、品質を上げろ、とは滑稽だと思いませんか？誰が品質を上げようとするのですか？手を抜くだけですよ。
はやく気付かないと、大事故が起こりますよ。
まぁ、既に某電力会社とかで起きていますがね。そのうち人命が失われますよ？
新卒でコボラーになってもうすぐ1年になるので、とりとめなくだらだらと狭い視野で感想を書いてみる。就活の時期なので、入社前に思ってたこととの違いなんかも織り交ぜつつ。散々誰かがあちこちで同じようなことを言ってると思うけど気にしない。
開発の話。プログラミングは、かなり楽にできあがる。難しいことは全部既存のサブルーチンライブラリにお任せ。メインのロジックだけ頑張って考えれば、文系人間でもなんとかなってる。良くも悪くも、やっぱり歴史があるんだなと思う。COBOL自体は文法も分かりやすいと思う。たまにこれもっと楽にできないのもっと早くできないのって思うことはなきにしもあらずだが。
古いプログラムはごっちゃりしているのもあるが、そこまでスパゲッティなものもない。仕様変更もそれほどには苦労してない。ありがたいことに新規開発にも携われている。COBOLもまだまだ健在なんだな。上司のつぶやき→「腐っても汎用機ですからね」
もう少し大きな話。ぶっちゃけプログラミングそのものは誰でもできるレベルだと思う。それよか苦労するのは、仕様の把握とか、文書の作成とか、そのプログラムを使用する業務の知識とか。そっちの勉強の方が難しい。他業種の知識を、その他業種やってる人並みに付けることを求められてる。無理無理むずい。いやでも面白いとは思うけど。IT業界にいてこんな知識蓄えられるとは思ってなかったし。
適性の話。就活中によく目にした「文理不問」ってうたい文句、これ文系でも大丈夫だよって意味合いなんだろうけど、うちは逆にITバリバリやりたい理系は大丈夫じゃないと思う。気遣う方向変えるべき。プログラム大好き！趣味でゲーム作ったことある！時代は××（何か最先端の言語とか）だよな！って人は、うちの職場は苦痛なんじゃないだろうか。実際、私の来る前に同業他社（COBOLじゃないとこ）へ転職した人がいるそうで、動機とかが人月計算とスーツの人に似てたりもする。
勤務の話。残業は、うん。まあまあ。決して楽ではないけど、毎日終電とか徹夜ひゃっほうとか休日返上とかはない。下を見れば恵まれてる方だと思う。忙しさは会社単位でも決まるかもしれないけど、同じ会社でも部署ごとに全然違ったりするから、最終的には運だと思う。サビ残が多い少ないを左右するのは意外と上司だったりする。これも運か。
今後の話。実力を付ければ、社内で異動とか転職とかもできるだろうけど、自分はしばらくは転職なんて考えないと思う。とりあえず安定はしているし、とりあえず学ぶことはまだあるし、とりあえず大丈夫だし。そうやって数年経った頃には転職先なんてないぞ、って色んな人が言ってるけど、COBOLやってるとことか、多少の知識を蓄え中の他業種とか、まあ探せばなんとかなるんじゃないか。楽観。案外、今の会社が続けばこのまま骨埋めるかもしれない。
あまり関係ないけど、「仕事楽しい？」って聞かれたら、返答に困る。楽しくはないよ仕事だし。でも苦痛ではない。そんなとこです。終了。
横からだけど、デスマーチはちゃんとしたバスターがやってくれば、奇跡のような早さで解決していくから、怖がらなくてもいいんじゃない？その人が来たのなら。
実際デスマーチって、中間の管理職にちょっと寝ていてもらって、担当者からちゃんとヒアリングして、その問題を解決すべき真の担当者を説得し、適切に指示だしすることで
こんばんは。わたしは今日、SEとして、つまり障害を報告するプロという立場で増田に来ました。
もちろん、SEだけが障害を出すわけではありません。よく知られているようにPGもバグを出します。ディスク障害、ネットワークダウンのように、ハード屋やら電話屋もそれぞれがそれぞれの障害を出します。しかし、SEのバグは他の人たちのバグとは違います。SEがバグを出して道徳的と称賛されることはありません。それどころか、その障害が大きければ大きいほど、ひどい障害であればいっそう、顧客や上司からの批判が大きくなります。なぜ、そうなのでしょうか？
それに対する私の答えはこうです。すなわち、致命的なタイミングで障害を出す、いってみれば、悪夢を現実にすることによって、SEはシステム投資の重要さを説き、新たな光でそれを照らすことができるのです。多くの場合、開発工程のほとんどを内製化し、正確にシステム化することは事実上不可能です。だからこそ、私たちはPGを隠れた零細企業からおびき寄せ、開発拠点へと運び、一見正社員の形に置き換えるのです。しかしながら、これで障害を起こした場合には、私たちのメンバーの誰が腹を切るのかを明確にしなければなりません。メインフレーム時代に現役バリバリだった時代遅れなPMを安全ピン代わりに上司の席に着かせることは、自分を身を守るのに必要な準備のひとつなのです。
そうは言いながらも、今日も障害を報告するつもりはありません。できる限り先延ばしにします。私が人力で運用フォローをしなくて済み、この時間に帰れる日は月に2、3回しかないのですが、今日はちょうどその日に当たったようです。
真実をお話しします。本社で、かなりの上の人たちから、障害を悟られぬようように、と言われました。ばれたら、私のマイナス査定（降格）を下すと警告する人さえいました。これはもちろん、メインフレーム周りでの激しい障害のためでした。基盤担当の報告では、バックアップの上書きで１０００ファイル以上が消失し、その大部分は唯一無二の情報、つまり受注先マスタや売掛金データであったとのことです。
障害の知らせを受けた後、私は何度も自問自答しました。仲間がサーバルームでコマンドを叩き続けているときに自分だけオフィスへ来て、上司への報告書を書くことが果たして正しい行為なのか、今まで機器構成を説明する図が無くて今日初めて作られたことが悟られないか、一部のモジュールのソースと設計書が紛失しており機能を想像して丸ごと書き直さないとバグがつぶせないことをどう説明するか、と。私はもちろん、このような印象を与えたくありません。私はバイナリからの逆コンパイルには反対ですし、ヤマ勘でのプログラミングも支持しません。もちろん、先人の書いた設計書は見つかるはずもありません。
しかしながら、慎重に考慮した結果、最終的に障害を報告しませんでした。この判断の理由の一つは、実に上の立場の人が障害を報告しないようにと私にアドバイスをしたことです。おそらく、他の多くの技術者と同じように、私は上司に言われた通りのことをする傾向があるのです。「言うな」「考えるぞ」「で？」「黙ってりゃわからん」「マイクロソフトのせいにできんのか？」「お前は一言もしゃべるな」と言われると、特に役員の個室に呼び出され「警告」を受けると、それに従いたくなるし、考えたくなくなるのです。これはサラリーマンとして当然の「気質」かもしれません。技術者は普通のサラリーマンなのです。私たちは上司自身の口から出たことや、FW:が5個ほど連なったメールにしかすんなりとは従えないのです。
というわけで、私はここにやって参りました。遠く離れているより、増田に来ることを選びました。コンソールを見つめることより、PCを見つめることを選びました。皆さんに何も話さないより、話すことを選んだのです。ここで、非常に個人的なメッセージをお話しすることをお許しください。それはコードを書いているときにいつも心に留めていることなのです。紙に書いて壁に貼ろうとまで思ったことはないのですが、私の心の壁に刻まれているものなのです。それはこういうことです。
「高くて、固い壁があり、それにぶつかって壊れる卵があるとしたら、私は常に壁の側に立つ」ということです。
そうなんです。その壁がいくら正しくなく、卵が正しいとしても、私は壁サイドに立ちます。他の誰かが、何が正しく、正しくないかを決めることになるでしょう。おそらく労基署や裁判所というものが。しかし、もしどのような理由であれ、顧客の立場に立って正直に報告書を書く技術者がいたら、上司はその部下にいかなる価値を見い出せるのでしょうか？
この暗喩が何を意味するのでしょうか？いくつかの場合、それはあまりに単純で明白です。納期前倒し、瑕疵責任、仕様変更、出精値引、SLA無視は高い壁です。これらによって押しつぶされ、徹夜し、心理療法を受ける非正規の下請けたちが卵です。これがこの暗喩の一つの解釈です。
しかし、それだけではありません。もっと深い意味があります。こう考えてください。私たちは皆、多かれ少なかれ、卵なのです。私たちはそれぞれ、壊れやすい殻の中に入った個性的でかけがえのない心を持っているのです。わたしもそうですし、皆さんもそうなのです。そして、私たちは皆、程度の差こそあれ、高く、堅固な壁に直面しています。その壁の名前は「システム」です。「システム」は私たちを守る存在と思われていますが、時に自己増殖し、私たちを殺し、さらに私たちに他者を冷酷かつ効果的、組織的に殺させ始めるのです。
私が報告書を書く目的はただ一つです。個々の下請けが業務を担当したエビデンスを集め、それに責任を与えることです。報告書を書く目的は、「システム」の網の目に自分の魂がからめ捕られ、傷つけられることを防ぐために、「外注先」に対する警戒警報を鳴らし、注意を向けさせることです。私は、設計書への検印、テストの実施担当者の検印、ソースの最終更新者、リリース時の立会い責任者、打ち合わせ記録書の参加者などのエビデンスから個人を槍玉に挙げた報告書を書くことで、自分を守り、壁を守り、下請けを破壊することがSEの仕事であると心から信じています。というわけで、私たちは日々、本当に真剣にエビデンスを積み上げていくのです。
私の先輩は昨年、40代で亡くなりました。先輩はPGで、時折、SEをしていました。金融のSE だったとき、徴PGされ、中国のオフショアに送られました。先輩の隣のチームだった私は、先輩が昼食後に毎日、たくさんのお薬を飲んでいるのを見るのが日常でした。ある時、私は先輩になぜそうまでして働くのかを尋ねました。先輩の答えは、これまでデスマで散った人たちのために戦っているとのことでした。先輩は、顧客であろうが上司であろうが関係なく、残ったメンバーのために開発を続けているとのことでした。先輩が会議室でのレビュー中に焦点の合わない目を見開いたまま俯いている顔を見たとき、先輩の周りに死の影を感じたような気がしました。
先輩は亡くなりました。先輩は残りのメンバーが決して知り得ない仕様も一緒に持っていってしまいました。しかし、メインフレームの周辺に潜んでいたJCLの仕様の一部が既に転職していったメンバーの記憶に残っており、相手の迷惑を顧みずにばんばん電話で聞いています。以上のことはプロジェクト管理のことでわずかにお話しできることですが、最も重要なことの一つです。
今日、皆さんにお話ししたいことは一つだけです。私たちは、国籍、人種を超越した人間であり、個々の存在なのです。「システム」と言われる堅固な壁に直面している壊れやすい卵なのです。どこからみても、勝ち目は見えてきません。壁はあまりに高く、強固で、冷たい存在です。もし、私たちに勝利への希望がみえることがあるとしたら、私たち自身や他者の独自性やかけがえのなさを、さらに魂を互いに交わらせることで得ることのできる温かみを強く信じることから生じるものでなければならないでしょう。
このことを考えてみてください。私たちは皆、実際の、生きた精神を持っているのです。「システム」はそういったものではありません。「システム」がわれわれを食い物にすることを許してはいけません。「システム」に自己増殖を許してはなりません。「システム」が私たちをつくったのではなく、私たちが「システム」をつくったのです。
これが、私がお話ししたいすべてです。
「自宅謹慎1ヶ月」、本当にありがとうございました。一旦は闇に葬られた私の報告書が形を変えて増田の多くの人々に読まれていることはとてもうれしいことです。増田の読者の方々にお礼申し上げます。私がここに来たもっとも大きな理由は皆さんの存在です。私たちが何か意義のあることを共有できたらと願っています。今日、ここでお話しする機会を与えてくださったことに感謝します。ありがとうございました。
http://anond.hatelabo.jp/20090102095509
はてなダイヤリーでは確かtex記法はimgタグに変換される。imgタグのソースにtex記法の一部が記述されていて、画像のURIとしてcgiとそれに渡すパラメタが記述されている。よってブラウザはimgタグをみてcgiに画像を要求し、cgiは数式が記述された画像を返す。推測だけど。
しかし匿名ダイヤリーはimgタグに変換されたところでエスケープが働く。これはバグというより仕様と思われる。imgタグだろうとtex記法のものだけ通すとか判定めんどうそうだし、tex記法で思わぬ使われ方をすると危ないと判断したからかもしれない、これらも推測ではあるが。
結論としてやはりバグではなく仕様と評するほうがずっと合っていると思われる。よってはてラボに要求するならデバッグ要求ではなく仕様変更要求のほうが適しているだろう。しかしなおバグだと考えるならばもちろん好きになされるとよい。
知り合いの職場の話。
はてな社長「街で聞いて回ったら誰もウチのサイト知らなくてショックだった」
http://tsushima.2ch.net/test/read.cgi/news/1230096507/
368 名前： ネチズン(dion軍)投稿日：2008/12/24(水) 22:36:07.83 ID:UCAFa8VU
教えて系の創始、および国内ブログサービスの創始。古参はここから。
はてなキーワードも、ジャンルや話題で繋がるのに便利だったし、
キーワード経由で仲良くなったりした。
第２世代；はてなアンテナ世代
ＲＳＳなどのフィードリーダーが広まるはるか昔だったので、
まだ回線が細い時代、多サイトを巡回するにはとても便利だった。
はてなダイアリーは伸び悩み始める。
第３世代；はてなブックマーク世代
国内ソーシャルブックマークの創始。
どんなサイトでも、そこの管理人の管轄外でコメントが付けられるため、
371 名前： ネチズン(dion軍)投稿日：2008/12/24(水) 22:43:21.88 ID:UCAFa8VU
>>368
この参加した世代により、住人の雰囲気にびみょうな差がある。
第１世代には、モ板の住人が古参としてがんばっており、
↑これははてなでは珍しい、いい例。
および、馴れ合い厨が多いことがある。
これは歴史の必然で、>>368に書いたとおり「国内ブログサービスの創始」だったため、
はてなダイアリーで連帯を強めていったからだ。
自分のダイアリーのトラックバックや「はてなブックマーク」や「はてなスター」を駆使し、
ののしられ、人格批判をあび、ぼろぼろにされていく。
そうでないときも、産経や２ちゃんや安倍麻生を罵倒して集団で馴れ合っている。
373 名前： ネチズン(dion軍)投稿日：2008/12/24(水) 22:48:37.74 ID:UCAFa8VU
>>371
２ 馴れ合い厨の多さ
はてなは、本文にIDを書いただけで、相手にトラックバックされる。
繋がりを重視している設計。
だがそれが馴れ合い、オフ厨を招き、「オフ充」なる言葉まで生まれるほど、
外から見ると非常に気持ち悪い。
376 名前： ネチズン(dion軍)投稿日：2008/12/24(水) 22:55:41.48 ID:UCAFa8VU
４ つくりかけて飽きたり、中途半端なもの多すぎ
hatelabo にアクセスしてみれば、つくりかけてポン出ししちゃった
サービスの多さがわかる。
サーバートラブルは多いし、矢継ぎ早にサービス展開するならば、
たとえば、はてなダイアリーは、開始から一度も仕様変更をしていない。
「ブログモード」という、サーバー出力時の変換でブログっぽくする機能はあるが、
基本的には「一日に記事一本」の形でしか、データを管理していない。
簡単に言うと、どんなブログサービスでも 、一日に何本もエントリーを書ける。
記事一本ごとでできる。
信じられないかもしれないが、はてなでは、これができない。
一日の更新分は、すべて一本のデータで管理しなければならない。
378 名前： ネチズン(dion軍)投稿日：2008/12/24(水) 22:59:03.90 ID:UCAFa8VU
>>376
＞hatelabo にアクセスしてみれば、つくりかけてポン出ししちゃった
＞サービスの多さ
「Wii向けに、ようつべを配信。しかもニコニコぽくコメントできるよ」と
さんざんアピったにもかかわらず、
ひっそりと終焉した。
人員が足りないのか、開発力がないのか、どっちにせよ
ユーザーのことは第一に考えていないのは確実。
424 名前： ネチズン(東京都)投稿日：2008/12/24(水) 23:57:40.98 ID:5etd/jna
>>416
426 名前： ネチズン(dion軍)投稿日：2008/12/25(木) 00:02:34.81 ID:3/yxpLTn
>>424
逆だったｗ
→常に同じペースでプロジェクトが進むはず無い。下請けは客じゃない。むしろ待つのも仕事。
・戦闘バランスは全然調整されていない
・ダンジョンの仕掛けが全部作動しない
→チューニング前。当たり前。
・カジノも始めはある予定だったけど間に合わないから全部なくなった
・キャバクラの女の子にモテたいからキャバクラ風の見た目や服が増えた
・物語にもキャバクラの女の子にだけわかる内輪受けの内容が入った
何でかけないのか予想がつくけどな。縛りのある卒論と縛りもあったもんじゃないネットの書き込みならネットの書き込みの方がやりたい放題できるだろ
おまけにいついつまでに上げなくちゃならないとか自分で圧迫しているとさらにできなくなる典型例だよ。力を込めすぎるとてんで明後日の方向に向かっていく
資料や実験結果に振り回されたりとか、文脈がおかしいとか、自分で見える範囲のアラがなくならなくてイライラするんだよね
見えない部分のアラはもっとあるしさ、全部アラ取ったら「お前、何でこんな風になったの？」とかさ。もう泣きたくなるんだよね
進行中も、ページ増やしても中身が進んでなければ意味ないし、かといって尺が増えないと進んだ気にならない
増える無駄書き。前進しない原稿。気になって行う修正。繰り返される改稿。仕方ないからリセットという名の仕様変更
机に頭打ちつけたくなるよ？ 提出期限が迫ってくるとさらに不調になるよ？
ましてやそれが通らないなら卒業できないと思えてしまえば、余計に筆も乗らない。抑鬱以前に書けない条件は揃っているよ
最初から二百枚書くと決めて書くんじゃないだよ。気がついたら二百枚超過した物を二百枚にするんだよ。それが俺のジャスティス
ハードル下げて初稿は好きなように書いて後から辻褄が合うように全部整えるという裏技があるよ。ただし初稿がボロカスだと整えようのない諸刃の剣
http://anond.hatelabo.jp/20081127004409
ソフトが無いと散々な言われようのPS3。どんだけ少ないんだと思って数えてみたら、パッケージ販売されてる物が130本以上、ダウンロード配信が約40本あるんだが・・・。「少ない」とか言ってる奴って何本くらいを基準にしてるんだろう？よく比較されがちなXbox360はパッケージが200本強とダウンロード配信が100本強で約330本。PS3の2倍以上あるわけだが、つまり300本を越えれば「少ない」と言われなくなるという事か？もっとも、過去のハードで発売された物を含めて良いというのであればPS3もゲームアーカイブスの260本弱を計算に入れる必要があるしんだが。
というか、年に何十本も買うような性質の商品でもないのに130本(＋40本＋260本)のラインナップで「少ない」ってどうなんだ？その中から数本でもハマれるゲームがあれば、そのハードに対する満足度は十分に及第点に到達しそうな気がするんだが、最近は違うのか。
それと「少ない」を通り越して「欲しいソフトが無い」とわざわざ発言してる奴って上記リンク先のソフト全否定って事だよな。だとしたらその人たちは普段どんなゲーム遊んでるんだろう。
「PS3はハード仕様がコロコロ変わる」という批判も見かける。確かに見かけるんだが、実際に調べてみると、「ハードウェアの仕様を変更」したと言えるのは発売から今日に至る約2年の間に1回だけで、それも80GB版(40GBのHDD容量を追加しただけ)発売の最近だ。20GB版と60GB版は「出荷終了」なので、一度も内部の仕様は変更されることなく終息した。いくらデジタル機器に疎い一般人でもこれくらいなら把握可能だろう。「値下げ」も、実は40GBを発売する直前の一回しかしていない。
さらに言えば、DSやPSPも過去2回モデルチェンジしてるんだが、PS3の仕様変更回数を批判する人間がDSやPSPを同様に批判しているところを俺は一度も見たことが無い。Xbox360にいたっては、パッケージのラインナップが通常版(初期20GBと現行60GB)、コアシステム、アーケード、エリートの5種類と、それに加えて発売時期によって異なるHDMI端子の有無、メーカーが公表していないレベルの基盤の変更もあるので、全ての組み合わせを数えるには両手でも足りない。発売から価格もハード仕様も全く変更していないのはWiiくらいなもんだろう(メーカーが発表していないだけで実際はしているのかもしれんが)。
つまるところ、客がPS3のハード仕様を意識しなければならない点は以下の三点のみだろう。
これが、他のハードよりも「コロコロ変わる」仕様変更の回数なんだそうだ。
mikomiko77 ゲハ板で妊娠どころかGKにもボコボコにされるレベル/あとPS２と比べたら普通にコロコロ変わってるだろ 2008/12/01
え、マジ？出来れば両者の具体的な回数や変更内容を教えてくれないか？
hejihogu 増田, ゲーム, PS3 本数の話は単純な発売本数じゃなくて、「やりたくなるようなゲームが無い」につきる。もちろん個人の主観的な好みの話。 2008/11/30
うん、個人的な主観ならば仕方がない。じゃあどんなゲームが「やりたくなるゲーム」なの？というのが今回の疑問なわけ。わざわざ「無い」と発言するって事は、他のハードには「やりたくなるようなゲーム」がてんこ盛りって事だよね？純粋にそれを知りたい。
darthhisac Wiiも少ないしXBOXも少ない。ただ、それらはある程度ターゲットを絞っている。PS3はいまいちターゲットが見えてこない。広く浅くといったソフト層。ゆえに少ないと感じるのではないだろうか。 2008/11/30
上記のラインナップを見る限りでは、とても「浅く」という印象は感じないんだが・・・。
false_alarm ゲーム 面白そうな、やってみたくなるゲームは、個人的に少ない…。というか、ない。やれば面白いんだろうけれど。あと、PS2互換については批判されても仕方ないと感じる。 2008/11/30
それは単純に楽しもうという意志自体が無いって事だよね。それならば無視すればいいのにわざわざ「ソフトが無い」と発言する。その原動力は一体何だと思う？
全然DRYじゃないけど、
#include <stdio.h> #define FIZZ 3 #define BUZZ 5 int main(void){ int i; for(i=1; i<=100; i++){ if((i % FIZZ == 0) || (i % BUZZ == 0)){ if(i % FIZZ == 0) printf("Fizz"); if(i % BUZZ == 0) printf("Buzz"); printf("\n"); } else printf("%d\n", i); } return 0; }
で簡単な仕様変更には対処できるかと。
でも一度ですむものは一度ですませたいよねぇ。もうちょっと考えてみる。
大都会のシステム開発に、ぽっかりと大きな穴が開いているようだ。
東京都内で、バグの多すぎる納期間近の３６０人月のプロジェクトが七つの外注候補に緊急要請を断られた。約１時間１５分後に官公庁に運ばれてサービスインしたものの、３日後にデータベースまわりのバグで動作停止となった。
同じようなことが一昨年、奈良県でもあった。バージョンアップ中のバックエンドシステムが動作不良になり、デバッグが必要になったが、隣の大阪府も含めて１９の外注に受け入れを断られ、やはりDBのバグで動作停止なった。
背景には、全国的なプログラマ不足がある。急な開発を受け入れる余力が、ITベンダに乏しくなっているのだ。
それにしても、ITベンダがたくさんあるはずの東京で、と驚いた人も多かったのではないか。厳しい条件の中でも、なんとか開発をやり遂げる態勢をつくるにはどうすればいいのか。今回起きたことを点検し、今後のために生かさなければならない。
動作停止したプロジェクトは仕様上の曖昧な部分や契約面での不透明な箇所があった。元請けベンダの手に負えないことから、下流工程での受け入れ先を探した。
最初に連絡したのは、危険の大きい開発案件に２４時間対応するために都内に９カ所あると言われているベンチャー系開発企業の一つ、○○だ。
ところが、○○では中堅社員の過労による退職のため、７月からは週末や休日の開発要員は１人になり、急な開発の受け入れが原則としてできなくなっていた。
この日は土曜日だった。１人だけのプログラマは受け入れを断り、他の開発企業を紹介したという。紹介した企業にも「COBOLを書ける人間がいない」などの理由で次々に断られ、○○は２度目の依頼で退職者を呼び出して対応した。
ベンチャー系開発企業は最後のとりでだ。そこが役割を果たせないようでは心もとない。プログラマ不足という事情があるにしても、東京都には急な仕様変更に備える態勢づくりにさらに努力してもらいたい。
いくつもの企業で受け入れを断られた背景には、都市圏ならではの要因もある。地方と違って開発企業が多いため、ほかで受け入れてくれると考えがちなのだ。
そうした考えが、危険なプロジェクトに備えるSI業界のネットワークが必ずしも十分には機能しないことにつながる。マネージャ同士でもっと緊密に連絡を取り合うことに加え、ネットワークの中で使い勝手の良い外注先を探す司令塔のような存在をつくることも考えたい。
もう一つ大切なことは、全く別々に運用されている元請けと下請けの連携を強めることだ。元請けで開発が進まないときは、とりあえず下請けを投入する。そうした柔軟な発想が必要だ。
プログラマ不足を解消する努力はむろん大切だが、SI業界やマネージャの間で連携に知恵を絞ることはすぐにでもできる。
http://www.asahi.com/paper/editorial20081023.html#Edit1
なんか微妙にブクマされていたので、コメントを踏まえつつ調子こいてまた少し書いてみる。
TOPページの投稿数が少なく感じているのは、確かにidページへの書き込みが多くなったのは一因だと思う。
マイページの仕様変更もその傾向に一役買っているのは間違いないだろう。
ただいくらか「常連」と思われているであろうユーザーのページを見てまわると、
idページへの書き込みは減っているように思う。
新規参入が増えていることと併せて考えると、ある程度の入れ替えは起こっているのかな。
あと傾向として、多くのユーザーが乗っかるような「祭り」みたいなのがなくなった。
割と初期のころは特定ユーザーをネタにしたキーワードで盛り上がるようなことも幾らかあったように思うけど、
近頃はめっきりそういうのも見なくなった。
内輪ネタだからと言えばそれまでだけど、その内輪が割と広かったというか。
もちろん逆に内輪色が強くなったことで入りづらくなったユーザーがいたのもまた事実と思われる。
あと別の意味での「祭り」もあまり見られなくなった。所謂「荒らし」だったり「揉め事」的な話だけど。
ただ「荒らし」に関しては、一概に荒らしとは言えない部分もある。
どういうことかというと、「荒らし」の渦中にいるユーザーが必ずしも「荒らしている」意識をもっているとは限らないから。
（もちろん明らかに荒らし的な態度を取っていた場合もあったように思うけど）
結果的に「荒らし」と「認定」されてしまってる場合も多々あったように思う。
それはたまたま場に合わないエントリや発言を「常連」だったり、やや「積極的」なユーザーが批判なり意見した場合だ。
個々の例については割愛するけど、そんな「荒らし」・「揉め事」を経る度に、
徐々に「暗黙のルール」だったり、ユーザーの関係性の変化が見られたように思う。
と、ずいぶん長くなってきたから今日はこれくらいにしとこ。
ここまで書くんだったら、もっと順を追って書けば良かったなー。ま、いいや。
「どうやって話題に入ればいいか分からない」っていうコメントがあったけど、
取り合えず自分が好きなことに関するキーワードにどんどん投稿してみたらいいんじゃないですかね。
例えば実況系とか。実況系のキーワードは物事に対する共有するものが他に比べてハッキリしてる分、投稿してる人同士で共感しやすいだろうし。
あと、気になるエントリがあったら積極的にスターつけたり、リプライしたりして。
あんまり度が過ぎると敬遠される可能性があるけど。なんせ出る杭は打たれることが多い場所ですから。
ほんとだ、ググっても出てこないね。仕様変更で消えたかな。
割と使いにくいビューアーでしたよ。もしかしたら夢だったかも知れん。
mixiに何かを期待する方が間違ってると思う、そんな仕様変更は多分ないだろうな…。
ごくごく最近になってやっと「マイミク申請があるよ！」ってメッセージから「友達」って単語抜けたしな。見ず知らずの相手から来る申請まで「友達」って書かれる気持ち悪さはずっとどうにかして欲しかった。
つーか未だに人間の検索の時の画像の「有る/無し」がわざわざ選択肢として有る理由がよく分からない…あれって芸能人の画像使ってる人とか結構いたよね、確か。なんのためにあるのかな、あの選択肢は…「わざわざ画像登録するのめんどい」って人は篩に掛けられるけど、それに意味があるんだろうか？そもそもさ
著作権・肖像権の侵害に当たる写真、暴力的、卑猥な写真、その他一般の方が不快に感じる写真の掲載は禁止しています。掲載はユーザー様ご自身の責任でお願いいたします。ってあるんだし、もうこっそり運営に言っちゃえよ、「不快に感じるのを掲載してる」って。
ところでさ、今ちょっと見てたら
http://mixi.jp/help.pl?mode=item&re_id=3a
と
http://mixi.jp/edit_photo.pl
とでプロフィールに掲載できる画像の容量に相違があるんだよな…いやさ、分かってたんだけど、アレだけのユーザー数がいてまだまだmixiはぐだぐだなんだな…と少し実感した。
あたし・・・実は・・・プログラマーなんだ。
ずっと、黙ってて、ごめん。・・・隠してて、ごめん。
でも、どうしても言えなかったの。
あたしがプログラマーだって知ったら、きっとみんな離れていっちゃうって思って。こわくて。
わかってる。わかってるよ。
プログラマーは初級シスアドを通った人だけがなることができる、カスタマーのプロフィットに関わるシリアスなビジネスだって。
でもね・・。
でもね、全然ちがうんだよ。
あたし、みんなが思ってるようなキレイなものじゃないんだよ。
あたしは汚れている。
あたしのキーボードは、汚れているんだよ。
プログラマーになったとき、すごく嬉しかった。知り合いのハッカーになったような気でいたの。
あたし馬鹿だから、お客様のビジネスを作るんだ！なんて、本気で思ってた。
でもね、全然違ったんだよ。
元請から言い渡された Sヨ の詳細設計仕様書は全く別のものだった。
お客様のビジネスを、まるでビル・ゲイツのように平等に助けるようなものじゃなかった。
あたしたちプログラマーに課せられた任務、・・・・それは、デバッグ だった。
そして、それを見守ること。
ねぇ知ってた？
この世界には、あるんだよ。こんな日本のど真ん中にね、平然と、あるの。
プログラマーはね、それを見守るの。
プログラマーは六本木ヒルズのホリエモンで、勝ち組の特権階級の象徴だからね、
そこにあるだけで、まるでビジネスが行われているかのような錯覚を起こさせる。
あたしの仕事は、そうやって、平等にビジネスが行われているかのように見せる暗幕みたいなものだったの。
ソフトウェアなんて、全然、救えなかったよ。
救う義務も権利も、この任務にはなかったの。
例え、その仕様がどうすれば助かるか、明確に解っていたとしても、
あたしたちは元請の命令が無いかぎり、何一つのコーディングもできない。
ただ、ただ、走って火消し屋を呼びに行くだけ。そして伝えるだけ。
でもね、この国の「火消し屋」は非常に貴重な存在。
火消し屋は稀有な存在。
夜なんかになれば、一つのフロアにどこからともなく現われるの。
たくさんのプログラマーたちが、一人の火消し屋に群がっていた。
「先生、コアを吐いている人がいます！」
「先生、表領域が苦しい人がいます！」
懸命にプログラマーたちが叫んでた。
でも火消し屋は一人。
私も声を荒げて「苦しい言い訳をするプログラマーがいます！」って叫んだの。
でも、ここでもふるいわけが始まる。
人員レベル、難度、納期。そんなものが現象と一緒くた になって命令が言い渡される。
と言ったきり、火消し屋は朝までチームのもとに来れなかったの（お客さんのところに言い訳に行った）。
その日、10秒ごとに Mantis の履歴が増えた。
「苦しい、苦しい、まだ苦しい」
「もう少しだけ待ってください、今火消し屋、来ますから・・」
何度も火消し屋のもとに走ったけど・・・。
火消し屋は、今にも心臓の止まりそうなお客さんと仕様と納期の折衝にあたっていた。
あたしは火消し屋に背中側から叫んだ。
「null チェックを入れても、まだぬるぽみたいなんです！」
「ガッ！」
コメントアウトの行数を上げた。でも駄目だった。QA からの質問は止まない。
そのバグだけじゃない。
「トイレに連れて行ってください（コンプライアンス的な意味で」
「基板が焼けたから替えてください」
「エスタロンを飲ませてください」
「ブートが走らないんですが」
「眠れません」
デバッガを走らせる。
忙しさにコードが荒くなる。
月残業時間が 400 越えたプログラマーがエレベーターに乗って外に出て行こうとする。
必死にあたしもふるい分けた。
今、一番検収ハネられる危険があるバグから、一番仕様満たしてないバグから、手を差し伸べなきゃ。
「いつになったら納品されるんだ！」と言われても。
「単価高い」と言われても。
私は頭を下げたり、ちょっと言い争ったりもしながら、
あたしはカーネルだ！と思った。
あたしは火消し屋の指示を待たずにロジックの検査をした。差分プログラミングの extends だった。
急いで火消し屋に連絡した。
「差分プログラミングの extends です。継承元のコードいじっていいですか？！」
「いや、コードを見ないとわからない、ただこっちの処置があるから、10分後に行く」
「待てません！リリースします！」
あたしは火消し屋の指示無くパッチをコミットした。バグの症状はスッと納まった。
それは駄目なことだったけど、一人のバグを救ったことに、あたしは浮かれてたの。
貧相な正義感をぶら下げて、意気揚々と自席に戻ってきたの。
自席の・・・・
でも、亡くなってた。
システムコールも呼べない人だった。
あたしは、その日、目の前の苦しいバグに夢中で、ps なんか見てなかった。
それでもね、・・・あたし、まだ、プログラマーなんだよ・・。
火消し屋は QA に「いつ何があってもおかしくない COBOLer の書かれたコードでしたから・・」と時間稼ぎの工作をしていた。
QA のテスターは「ありがとうございました」と額に青筋を浮かべてバグレポートに「仕様です」と書いて取り下げた。
そして、あたしにも「プログラマーさん、ありがとね」と言ったの。
大好きな、ソフトウェアだった。
このシステムが立ち上がる頃から知っていて、αリリースから知っていて。
「自分は寂しがり屋だから、最期は dankogai に手を握ってもらいながらホッテントリ入りしたい」と言っていた。
あたしが新人の頃から知っていて、vi のカーソル移動が苦手だったのも知っていて、
「Xenix はわしが育てた」が口癖だった。
「まぁ、・・・歳だったし、運用中にも止められないって言ってたからなー」
と火消し屋があたしの背中ごしに言った。
その記録には、波形が Full GC 後もヒープ使用量が右肩上がりとなりメモリリークするさまがしっかりと記録されていた。
高負荷だから死んだんじゃない、そこにはメモリリークで死んでくプロセスがあった。
でも、そんなこと全部まるめこんで、kill んじゃって仕方ないっていうプロセスが、そこにはあったんだ。
似たようなことはざらにあった。
何人ものプログラマーが、自社ビルの屋上の端から零れていったよ。
でも、あたし・・・プログラマーなんだ。
誰も、辞めろって言わないの。
火消し屋は鉄火場にブチ込まれただけだから、言わない。
顧客は実情がわからないから、言わない。
プログラマー同士は実情がわかってるから、言わない。
IPA はきっと、全部知ってて、それ込みで「それが10年は泥のように働けということだ」と言うかもしれないけど。
いや、言わないか。IPA は、何も言わない。きっと。
救えたかもしれないバグを、プログラマーは一番わかってる。見えてしまう。
PM の指示が適してないのも、判断が遅いのも、仕様変更履歴がのってないのも、全部わかってる。
それでも「あの時！」と、自分の行動と判断を何度も振りかえる。
その向こうにはいつも「あのとき、こうしておけば」が、くっきりと見える。
でも、救えなかった責任も、見過ごした責任もプログラマーには問われない。
プログラマーって・・ほんと、なんなんだろうね・・・。
パッチ一粒すら出せないのに、
設計一つ指示できないのに、
テストパターンに関わることなんて、一つも独立してできないのに、
テスト部門が持たされてるのはプログラマーコールだけなんだよ。
どんなに辛くてもプログラマーしか呼べないなんて。
そしてあたしたちは色んなものを抱えて、バグの前に立つ。
火消し屋が来ること、来れないこと、
できるデバッグがあること、ないこと、
色んなことを知りながら、本当の意味で世界を変えられるコーディング力もないままに、
さも救いのギークが舞い降りたかのような顔で。
IT ギョーカイが崩壊していく。
全然止められない速度で。
その日○製作所の城で、あたしは見てるんだ。
沈んでいく汎用機の命を。
----------------
