« 2004年10月 | トップページ | 2004年12月 »

対決!日米ゲーム開発残酷物語

CNETブログの「ゲーム開発者残酷物語」を読むと、米国のゲーム開発者がいかに悲惨な状況で働いているかが分かる[参考]。聞き取り調査の結果を引用する。

回答者のほぼ6割が通常週46時間以上働くと述べている。そして、95%以上は会社でいわゆる「追い込み期間」を経験したことがあるという。また、18%以上は2カ月以上続く追い込み期間を経験し、さらに3分の1以上がその期間中に週65~80時間働いていたと回答している

…なんかヌルいんですけれど。仕事が立て込んでいても自分の労働時間を把握できている余裕はあるんだねッ…っつーかこれが時間を切り売りするリーマンの鑑なのでしょう。

お次は日本。もはや「時間」は何の意味も成さない例↓ 引用元は「ゲーム業界残酷物語」from POWERTODAY

監禁

「J社の開発室って地下にあって窓が一つも無い」とか、
「開発室のドアは外側からカギが掛けられる」とかって
昔、聞いた事あるんスけど...本当のところどうなんスかね。

本当です。でも今はカギはありません、新聞沙汰になったので。だいたいプロジェクトが大詰めになると、「寝ていない時間≒仕事している時間」になるんじゃぁないかと。アメリカン・プログラマの悲しい話は、探せばもっと悲惨なやつが出てきそうだが、↓のを聞くと同情の余地が失せる

ただし、10万ドル以上のサラリーをもらう場合もあるゲーム開発者には、同情の声ばかり集まるわけでもない。先のブログの書き込みに対して、「McDonaldや工場で一度働いて、それからエアコンもあればコーヒーも飲み放題の自分の職場と比べてみろ」という書き込みもあった

ええと、マクドナルドもプログラマもやった私から言わせてもらうと、「マクドはキツいかもしれないが、気がヘンになることはない」よっ。再びトダイの「ゲーム業界残酷物語」より

発狂

K社のゲームプログラマーの場合
仕事中(やっぱ夜中)に突然、椅子(車輪が付いてて転がるヤツ)に腹ばいになり
「見て見て!ウルトラマンだー!」
と転がりはじめたプログラマー。
仲間にもウケて大好評!。しかしなにかが違う、しつこい。
いつまでもやってるので「いい加減にしろ」と仲間が様子をみたところ見事にイっちゃってた。

この勝負、日本の勝ち~(つД`)でも涙が止まらないのはなぜ?

--

| | コメント (0) | トラックバック (0)

すくなくともハリーポッターより面白い「ダレン・シャン」

…と嫁さんが強力に勧める一冊目「奇怪なサーカス」を読了。一言で言うと「すっげぇオモロイ!」

二言以上で言うと、「百戦錬磨のワシがまったく先が読めない」「たった1時間で読み終わるが、文字通り呼吸を忘れて没入できる」…などと陳腐な表現で誉めておこう。

これから読む人のためにこれが何の話なのかは一切紹介しない。読もうとする人は調べるなかれ。amazonレビューも不可。他の紹介文を読んじゃったらもったいない。

予備知識なしでいきなり没入するのが、ファンタジーの正しい入り方。読中はステーブン・キングのある小説と、ウィリアム・シェイクスピアのある戯曲を思い出した。

気に入った部分を引用したいが、ネタバレになってしまうのでやめとく。とにかくこいつはオモシロイ。これといい、「デルトラ・クエスト」といい、近頃の小中学生は幸せモノだねッ

--

| | コメント (0) | トラックバック (1)

いまそこにある2007年問題

プロジェクトが火を噴いている。まぁ、いつものことだとうそぶく自分が情けない。理由は「非現実的な納期」「見積もり不備」「仕様不在」… と、このテの仕事をしている面々には茶飯事なのだが、今回はそれらを押しのけて「2007年問題」が突出する模様。

2007年問題とは、一般に団塊の世代の一斉退職による人材・ノウハウの逸散のことを指す。狭義だとメインフレーマーな人・COBOLerな人の退出によるレガシーシステムのメンテ問題だし、広義ならプロジェクトマネジメントノウハウの流出とも位置付けられる。これを深刻に受け止める人もいれば、むしろ好機とみなす人もいる。日コン11/1号に詳しい。

いまココにある「2007年問題」はそんな上っ面なやつじゃなく、もっと切実なやつ。つまりこうだ。団塊世代は「いけいけどんどん」、即ち作ってナンボ、動かしてナンボの世界だった。止めるのは悪であり、動かすためのいかなる手段も正当化された。よく分からない定数(群)、サブシステムを跳躍するGOTO文、だれも理由をいえないオリジナルインクルード文。

こんがらがって書いた当人も読めないようなコードを「スパゲッティ・コード」と呼ぶが、スパゲッティならまだマシ。スパゲッティなら、まだ皿にのっている。皿からはみ出てテーブルから落ちそうな血まみれ「スプラッタ・コード」となっている。もちろん、誰も読めない(し、メンテも不可能)。

しかし、システムは動きさえすれば善なのであり、動いているコードは触るなという鉄則がある

その結果、ブラックボックスと化したシステムは、「よく分からないけれど動いてるからいいや」状態で放置。動かすために裏でごにょごにょ手入れしたことは、ドキュメント化されないまま、みんなの記憶の中に放置→やった本人すら忘れている。いや下手に「ワシがやった」などと手を挙げようもンなら、ドキュメント化せよという至上命令が降ってくる。ここは口をつぐんで放置プレイ。

レガシーシステムには、多かれ多かれ「記録に残していない修正」がたっぷりと入っている。こうした「裏でごにょごにょ入れた仕様」を前提とした修正・バージョンアップが繰りかえされる。

…そしてある日、「レガシーシステムを更改せよ」という命令が下される。オープン系? いいねぇ、MDAでやってみる? かっくいー

プロジェクトの俎上に乗る「現行のスペック」には「バックドアから入った仕様」が漏れている罠に誰も気づかない。ゲームだと隠れキャラを出さなくてもクリアできるが、この隠れキャラは突然必然出現する。しかもどこにも書いてないし、「あンとき何かイロイロ入れたなぁ」としみじみと思い出されるのみ。

「記録より、記憶に残るプレイをしたい」という名言を吐いたのは新庄剛志。団塊オヤヂたちよ、「あの頃は大変だった」と遠い目をしているヒマがあれば、記憶よりも記録を残しておけ、たのむ。

--

| | コメント (8) | トラックバック (0)

怒号と罵声が飛び交っていても、まだデスマじゃない

夕方になって朝から一度も座っていない(*1)ことに気づいたとしても、まだデスマじゃない

ごはんを食べそびれても、まだデスマじゃない、たとえ3回食べそびれても、まだ

眠った≒意識が跳んだかもしれないが、まだデスマじゃない

会議の連続でトイレにすらいかせてもらえず、おしっこがまんプレイ状態(*2)になっても、まだデスマじゃない

「今日は何日だっけ?」ではなく、「今日は何曜日だっけ?」ではなく、「いま8時? 夜の8時?」 という会話を交わしてても、まだデスマじゃない

机の下にダンボール敷いて寝てても、まだデスマじゃない。ダンボールそのものがが汗臭くなってても、まだデスマじゃない

勤労感謝の日に仕事していても、まだデスマじゃない。まだ仕事があることに感謝しているから、口が裂けてもデスマというまい

「死者の行進」「死の行進」というならば、行進しているもの皆、ゾンビー化しているはず。血走り目はウツロ、髪はボウボウ、腐臭・体臭をまき散らしながら、「ほえぇ」(cv:CCさくら)と呻きながら、それでも何か仕事のようなものをしている状態が、デスマーチなのだから

がんばれ、オレ

もっとがんばれ

こんな時間にブログを更新しているようなら、まだデスマじゃない、もう寝ます

--

*1 便座を含む

*2 ♂♀入り乱れてのおしっこがまんプレイなので、ある意味笑えるし、別な意味で萌える。缶詰状態の会議室でモジモジする♀を目端でチェックするのは腐れオヤヂの楽しみの一つ。ただし自分もモジモジしながらだけどな(w

| | コメント (4) | トラックバック (0)

日本沈没

小松左京の傑作。これと「くだんのはは」は自信をもってオススメできる。

日本沈没」は、これまでに3回読んでいる。学生のとき初読、阪神淡路大震災の後に2回目、そして先ほど3回目を読了。読む度に、この国の繁栄は"かさぶたのような土地"の上に築かれていることがよく分かる。

かつてはパニック長編として読んでいた。30年前に書かれたものであるにもかかわらず、古びていないことに驚く。もちろん「やさぐれ」「ヒッピー」「ゲバ棒」といった風俗ネタは古式ゆかしいが、マグニチュード8.5の激震が東京を襲うディテールは見てきたように生々しい

しかし今回は、「日本とは何か?」「日本人とは何か?」と考えながら読まされるハメになった。日本という国土を喪っても日本・日本人はありえるか?という問い。地震学者、田所博士の口を借りて、著者はこう結論づけている。

日本人は、人間だけが日本人というわけではありません。日本人というものは…この四つの島、この自然、この山や川、この森や草や生き物、町や村や、先人の住み残した遺跡と一体なんです。日本人と、富士山や、日本アルプスや、利根川や、足摺岬は、同じものなんです。このデリケートな自然が…島が…破壊され、消えうせてしまえば…もう、日本人というものはなくなるのです…

言葉や文化といった「日本的なもの」がつきまとう。「日本が沈む」ことが明らかになり、船舶・航空による大移動が始まるわけだが、行った先でどうなるのか? 移民先でも「日本人」を続けるのか、続けられるのか?

「私たちは、ある国に住むのではない。ある国語に住むのだ。祖国とは、国語だ。それ以外の何ものでもない」という言葉がある。仏の哲学者シオランの言葉だ。まるでこれに相対するかのごとく、著者はある「老人」にこう言わせている。

生きのびたとしても、子孫は…苦労するじゃろうな…日本人であり続けようとしても、日本人であることをやめようとしても、これから先は、どちらにしても、日本の中だけでは、どうにもならない。外から規定される問題になるわけじゃからな…。"日本"というものを、いっそ無くしてしまえたら…日本人から日本を無くして、ただの人間にすることができたら、かえって問題は簡単じゃが、そうはいかんからな…。文化や言語は歴史的な"業"じゃからな…

大混乱の中でかなりの「日本人」が逃げ出し、日本が沈むところでこの物語は終わる。延々と読み続けてきた読者はそこで瞠目するはずだ。なぜなら、そこに「第一部・完」と書いてあるからだ。著者は第二部として「日本漂流」、つまり世界各地で生きのびる日本を喪った日本人たちの物語を書こうとしていたからだ。(ネタバレ注意、反転で表示)

--

| | コメント (2) | トラックバック (1)

PM magazineレビュー(辛口)

第1号を読んだ。がっかりした。ここには納期(いわゆる発売日)を守れなかったクレームがついているが、この記事では品質(いわゆる記事の内容)について書く。

まずレベル。目線が低い。日経○○といったオヤジ向け提灯雑誌よりも低い。IT業界向けの雑誌のつもりなら、RUPやナレッジをキーワードにするのは読者に失礼というもの。知ってるってばッ。プログラマやSEからPMを目指す人なら、UMLを用いたプロジェクトスコープ管理[例]や、XPをPMに適用するネタ[例]が新しいだろう…っつーか誰も試してないだろうな。ペアプロの「プロ」はもちろん programming だけど、project management に読み替えた「ペアプロジェクトマネジメント」なんて、これから流行りそうだな。やることは昔の徒弟制度の焼き直しだけれど、コトバとして目新しいから→[証拠] 2004/11/16現在でgoogleで1件のみ

次にターゲット。この雑誌を買ってもらうターゲットは「IT業界でPMな人、あるいは目指す人」のようだが、記事がターゲットに向いていない。PMIジャパンでは有名どころが書いているが、その記事がお粗末。「プロジェクトマネジメントとは何か」や「なぜプロジェクトが失敗するのか?」なんて、この雑誌わざわざ買う人なら、さんざん悩んでネットや書籍を渉猟しているよッ。シンクタンクが書いたような賢しいベキ論なんて読みたくもないナリ。同じ制約条件(TOC)のネタなら「デスマーチが起きる理由 - 3つの指標」を参考にしてみればいかが? 「テストを通っていないコードは、全て在庫である」とか「プロジェクトに人を手当てしても、企業のコストは変わらない」など、同じリクツなのに目からウロコになるだろう。「ザ・ゴール」よりも短いし(w

最後に。情報メディアにお金を出す理由はただ一つ、「その媒体でしか手に入らないから」に尽きる。上にあげたリンクは無料だが、この雑誌は1,680円必要だ。確かに興味深い記事もあった。たとえば「あなたはPMになりたいですか」や、「ソフト開発のムダとり」などは参考になった…が、立ち読みできたなら、買うまでもない情報ナリ… じゃぁどうして買ったのかって? amazonで買ったからなんだよおおぉぉoooo

…案の定というか、amazonのPM magazine 第1号にも似たような評が並んでる…

--

| | コメント (0) | トラックバック (0)

障害者をテーマにした絵本について、嫁と話し合ったこと

3歳の息子への試み。聴覚障害をテーマにした絵本「ぼくのだいじなあおいふね」を読み聞かせた。「耳が不自由」についてよく理解できなかったらしい。次に「さっちゃんのまほうのて」を読み聞かせる

幼稚園児のさっちゃんの左手は、生まれつき指がありません。それでも、さっちゃんはとても元気です。ある出来事が起きるまでは…

おままごと遊びで初めて「おかあさんの役」をしようとしたとき、友達が叫びます「指のないお母さんなんて変だよ」その時の彼女の哀しみ、怒り…うちに帰ってお母さんに聞きます「どうして さちこの手には指がないの? 小学生になったら指が生えてくるの?」

おかあさんは静かに答えます。

「いいえ、さちこの指は大きくなってもずっとそのままよ」

。。゜(゜´Д`゜)゜。ウァァァァン

読み聞かせにならないorz
それでもなんとか最後まで読んだ。息子はとまどっていた

- - - - - - - - - - - - - -

問題はここから。息子が寝付いた後、ジト目で見ていた嫁が口を開いた

「おかしいよ、これ」

   『なにが?』

続きを読む "障害者をテーマにした絵本について、嫁と話し合ったこと"

| | コメント (2) | トラックバック (0)

実践プロジェクトマネジメント――危機を乗り越える25の決断

3回読んだ。でかいプロジェクトのPMにとってはガイドラインとして最適(ただしメインフレーム更改・統合の超大型ITプロジェクトに限る)。言っていることはいちいち納得できるが、いかんせん古いので、香ばしいスメルも楽しめる一冊。

経験不足のPMがプロジェクトを任された時、何をどうしていいか途方に暮れる。あるいは何するかは分かっていても、力点が分からないため、やっぱり途方に暮れる。「とりあえず」引き受けて火傷したPMはたくさんいる。巨大プロジェクトだと発注側の命運すら左右する。まさに死活問題。

そんな新米PMに朗報なのがこの本。「決断する25の瞬間」と銘打っているが、ポイントは25以上ぎっしりと詰まっている。プロジェクトのどのタイミングで何をするべきなのか、というプロジェクトマネジメントの肝(きも)が分かる。

さらにリアルなのがウレシイ。PMBOKの無味乾燥な「知識体系」ではない。現場でのギリギリの決断や、「買うか作るか見捨てるか」といった生々しい選択方法が、著者の経験を元に惜しげもなく開陳されている。

ただし、この本の事例は古い…っつーか特殊ナリ。銀行の統廃合でじゃんじゃんバリバリPMしてる人なら、読むまでもない「常識」ばかり。その「常識」が普通のプロジェクトに通用するかどうかには疑問符をつけておく。

さらに、構造化設計マンセーなところ、クラスタリングすることで「性能を買う」といった発想が一切ないところ、「PMを取り替えればよい」といった、そもそも誰のための本なのかを忘れた発言は芳しいスメルを放っている。

「超大型プロジェクトをマネジメントするためには高度なスキルを要する」←この一文はあっちこっちで強調されている。「高度な」スキルを有する団塊世代からすると、イマドキのPMは頼りない←というホンネが透けて見える…が、「高度な」スキルとは何なのかといった能書きは無い。分かる、わかるよ、だって説明できないんだよもん。ぶっちゃけ正体をバラすと、

    ・超大型プロジェクトの見積もりスキル
    ・超大型プロジェクトのマスタプラン策定スキル
    ・超大型プロジェクトのリスクマネジメントスキル
    …などなど

だから、皆がよ~く知っているスキルと同じなんだよね。「超大型」という形容詞が付くだけで。ン年前のマジックワード「オブジェクト指向」と同じ香りがする。

一方、「超大型」プロジェクトは、そうでないプロジェクトと全く違うことも確かナリ。金が莫大だとか、期間がかかるというよりも、端的に言うと、人柱が必要なプロジェクト。人月ではなく一本二本で数える」。一発勝負、失敗は許されない。うまくいってもいかなくてもニュースになるプロジェクト。PMはたいてい、「親分肌だが、根はマジメで小心者」が指名される。そのため、ストレスに文字通り潰されてしまう人もいる。そのへんのシャレにならない話は日コンでは書けないだろうが、直接お話を伺ったら面白いだろうなぁ…

その極意は、やっぱり実践で斬ったり貼ったりすることで身につけるしかない。激しく同感した部分を引用するが、痛い目に遭ったことが無い人ならスルーしてしまうだろう。例えば次の一文。

大きな既存システムがある場合、画面
・帳票を見ても既存機能の継承はできない。ましてユーザーから見えない機能は把握できず、理解の遠く及ばない状態が発生してしまう。大規模プロジェクトの既存機能継承は既存システムからの継承が大半であり、この作業を怠ると、プロジェクトは最初からやり直しになる危険性がある。ユーザーからの要求のみで新システムの仕様を確定させた場合は、既存機能の大半は継承されていないと認識すべきである
(下線は私)

ええ、ええ、もちろん知ってたよ。でも今は身にしみて理解してマス、痛いほど。やっぱ本を読むだけではあきまへんな

'`,、 ( ´∀`) '`,、

--
実践プロジェクトマネジメント――危機を乗り越える25の決断(岡村正司)

L

| | コメント (4) | トラックバック (2)

なゆき、3さいです

息子の幼稚園の参観で耳にして、めまいがした。この「なゆき」ちゃん、どんなお母さんかと目で探すと → ごく普通の、でも上品そうなママ


まさか「秋子さんですか?」と聞くわけにもいくまい。さりげなく「いい名前ですね、前に降るなんですか」と尋ねると、


   『ははは、まさか』


とのお返事…

続きを読む "なゆき、3さいです"

| | コメント (0) | トラックバック (0)

最近のデスマ

この道はいつかきた道~ ああ~そうだよ怨嗟の呻きが聴こえるぅ~ …っつーわけで最近のデスマ情景。昔と違うところをピックアップしてみたぞ

○仕様書のファイルの拡張子が.jpg

「?」と開けてみると、ホワイトボードに描いた打ち合わせメモをデジカメで撮った画像。これをカラプリで焼いて「仕様書」と称する。ドキュメント化しているヒマが無いのは分かるが、せめてファイル名に日付を入れてくれ

○議事録のファイルの拡張子が .mp3

「?」と開けてみると、会議を録音したもの。これがホントの議事「」。誰が何を言ったのかは克明に記録されているが、必要な情報を得るためには全部聞かなければならないorz

○電話会議からFORMAへ

オンコールといえば電話だったが、今じゃテレビ電話。そういや自宅からテレビ電話できるプログラマは、ぜんぜん職場に顔を出さなくなった。ネット越しの粗い画像でもデスマの空気は伝わるらしい。マシン・ルームは、かつてコーダーの魔窟だったが、今ではテスターだけ

○食玩神社

チョコエッグなど食玩が山のようにある。PCの上、デスクの上、キーボードの上(に接着してある)。作業に縛り付けられているため、出られない、休めない→ストレス暴食が食玩に向けられるとスゴいこと。大人買いではなく、暴君のように買う。MS-09R リックドムだけを鬼集している猛者の机はドム神社と呼ばれている。

○コメント日記

javadoc 生成の際、コメント文の中身をチェックするようになったため、「ここまで書いた」などとコメントで日記をつけたり、「△△のバカ、うんこ」と落書きする輩がいなくなった。コードを読む楽しみが減ったというより無くなった

…という状況だが、「おしっこやうんこにいく時間がまだある」ことと、「殴り合いのケンカがまだ始まっていない」ことから、デスマではないですな、まだ。

--

| | コメント (3) | トラックバック (1)

ぼくのだいじなあおいふね(ディック・ブルーナ)

そういや障害者をテーマにした絵本ってあるのかな… と図書館へ。今回は「ぼくのだいじなあおいふね」を読み聞かせ。ディック・ブルーナの描いた男の子が目じるし。

このベンという5才の子、よく見ると耳から線が伸びている。線は腰の補聴器につながっている。聴覚障害というやつで、通いのせんせいから「くちびるを読む」ことを習っているところだ。その最初のコトバがあおいふね

この「あおいふね」のところでたっぷり間をとってゆっくり発音する。さらに「パパの口を見てごらん」と発音するときの口の動きを注目させながら読み聞かせ、というより読み見せる。

次に発音せずに口の動きで「あおいふね」と言ってみたり、「口の動きだけで何をいっているのかを当てる」遊びをしてみる。

もちろん3才のわが子には「耳が不自由」という概念そのものを理解できるはずもない。絵と唇を交互に見ながら読んでもらうという、変わった体験をしただけ。

後にスゴい絵本があることを知る。「さっちゃんのまほうのて」だ。amazonレビュー読んでグッと涙をこらえる…

涙腺が弱いことは自負しとりますよ、ええ。もちろん読んでみるつもり。以下自分メモ。いくつかを読み聞かせしようかと。

「わたしの妹は、耳がきこえません」(ピーターソン)偕成社
「わたしたちの トビアス」偕成社
「どこがちがう マリア」(セルピーターセン)偕成社

--

| | コメント (0) | トラックバック (0)

スコープを可視化する

一般に、WBSやビジネスプロセスのチャート化により、スコープを洗い出すことは可能。その際たいせつなことは、

「スコープとそうでないものの境界線をものすごくはっきり持つ」ということです。詳細度ではないです。ここまでがスコープ、という範囲が重要だと思います。詳細度は段階的に詳細化すれば良い、ということです

nicknickさんの「スコープをみているだけでうまくいく」より引用。UMLのユースケース図と同じ考え方ナリ。「ゆーすけーすずって何?」という方、百聞一見、これとかこれを見るとイメージが湧くだろう。

はじめてユースケース図に触れたとき衝撃を受けたのが、この「外枠」。枠の中がシステムで実現するべきことで、枠の外側はシステムの外。ユースケース図を書くとき、この外枠を最初に書き、次に枠内にシステムの名前を書く

システムの外からシステムに関わるものを「アクター」と呼ぶ。アクターは、「経理係長」というロールとなる場合が多いが、「顧客管理レガシーシステム」といったシステムでもOK。アクターは、システムの中の業務「ユースケース」と線で結ばれる。線が外枠と交差している→そこにインタフェースが発生している。

実はこの枠、省略しても良いのだが、意識してこの枠を書くようにしている。お客さまに説明するときも「さりげなく」使っている。UMLに疎いお客さまでも「システムの外/内」の概念を直感的に知ってもらえる。

さらに、さりげなく「外/内」を切り分けて説明することで、お客さまの脳に刷り込みできることがウレシイ。「この業務は外からデータを持ってきてやるんですよね~」とか言いながら、「データを持ってくる主体」をアクターにしてしまう。

このユースケースはシステムでやるのか/システムの外なのかがハッキリする。システムの外の業務はユースケース図に書かない←鉄則

  そのシステムで実現する業務

  そのシステムに関わる主体

これを一枚化したものがユースケース図。従って、「スコープ」という語を聞くとユースケース図の外枠を連想する。PMにとってUMLは強力なツールだと思う。

--

| | コメント (0) | トラックバック (1)

« 2004年10月 | トップページ | 2004年12月 »