デスマーチを終わらせるには、そこに携わる人が変わらなければならないと思う。

システム開発の10年選手には、「デスマーチなんて普通でしょ？」という感覚を持つ人がいる。ここのところ自分にも、少しそんな気持ちが芽生え初めている。「デスマーチを乗り越えるのが仕事なんでしょ」みたいな。我ながらサイアクだなあ、と。

デスマーチが当たり前になると、仕様書が無いことにも、過密スケジュールにも、疑問を持たなくなる。そこの壁を超えてきた体力と精神力は、賞賛に値するかもしれない。武勇伝デンデデンデン、と言ってもいい。でも、これがデスマーチが終わらない一番の要因だと感じている。

デスマーチは、必ず滅殺することができる。その意志が大切。

以前、会社の先輩と話していて、デスマーチの原因は、日本でのソフトウェア工学の認識度の低さにある、となった。そう、大体デスマーチが起こるような現場には、アジャイル開発なんてボキャブラリは無いんだ。意志の低さは、恐ろしい。あああ。

もうひとつ精神論を言わせてもらえれば、マネージャーは手駒である開発者に対する愛情を、デベロッパ達はマネージャーに対する愛情を、もっと強く持つべき。マネージャーがいま以上にスケジュールの問題を抱えないように、今度の納期は絶対に守るんだ、とか。そういう愛が、足りない気がする。これこそ当たり前のことだと思うけど。

デスマーチは、必ずなくなる。そこにいる人の意志次第で。

続きを読む "デスマーチの終焉 [後編]"

デスマーチに引導を渡すには、何をしたら良いんだろう。

問題を解決するときに踏む手順は、いつも同じだと思う。原因を突き止めて、それを除くアイディアを出し、実践する。じゃあ、デスマーチの原因は、一体なんだろう。

• 必要工数(期間 or 人員)が、足りない。
• 開発者(デベロッパ)が、アッパラパー。
• 管理者(マネージャー)が、アッパラパー。
• 営業が、アッパラパー。
• 顧客が、アッパラパー。
• パラッパラッパー。

個人的な経験から言うと、はじめの原因、工数不足は、間接的な原因でしかないと思う。期間も人員も膨大だとしても、デスマーチは起こる。結局、ふたつ目以降の人間の問題が、大きいのだと考えている。パラッパラッパーはさておき。

続きを読む "デスマーチの終焉 [中編]"

システム開発者なら誰もが一度は経験し、のちに武勇伝のように語られるデスマーチ。あの悲惨な状況から脱する方法を、考えてみる。

そもそもデスマーチとは何なのか。

実は最初、「多くの会社が年度末になる3月は忙しい」という意味だと勘違いしていた。マーチ違い。そうではなく、日本語に訳せば「死の行進」となるのが、デスマーチ。その定義に確固たるものは無いっぽいけど、単に「忙しい」のとは違う。底なし沼にズブズブ沈んでいくような感じが、デスマーチだと思っている。

たとえば。

• 仕様は固まっていないが、リリース時期が間近なため、とりあえず「動く何か」を作らなければならない。
• 仕事量に対する工数が足りない。各人の負担が大きいので退職者が出て、残った人の仕事量が増える、という状況がループ。
• １つの問題の解決に、2つ以上の問題を解決が要求され、問題がねずみ算で増えていく。
• 非効率な方法と分かっていても、目前の納期を死守するために、その手段を用いなければならない。

これは、単に締切が近く、土日もなく働きつづけなければならない忙しさと、ワケが違う。「ここさえ耐えれば」というポジティブ思考が、通用しないから。やればやるほど、ストレスが増えるばかり。ううう。

僕は、これまでシステム開発とWeb制作の両方を扱ってきた。忙しさで言うと、短納期になりがちなWeb制作の方が、キツイもんがある。ただ、Web制作のそれはデスマーチとは違う。一方のシステム開発は、デスマーチ的要因のせいで、精神的にキツイ。

さて、そんなデスマーチに終焉は訪れるのか。(つづく)

javascript の delete 演算子の使い方を勘違いしていたっぽい。

てっきり不使用オブジェクトを削除することで、メモリを開放できるもんだとばかり思っていた。ところが、実際には undefined で上書きするだけで、メモリはまったく開放されない。結局、javascript におけるメモリ管理は、各クライアントの GC にまかせるしか無いのか。うーん。

Ajax の興隆以来、よく javascript コードを見るようになった。そこで気付くのが、多くの人が富豪的アプローチをしていること。onmouseover イベントを document に対して attachEvent しちゃうのかー、贅沢すぎー、みたいな。

今やクライアント側の性能が十分だから、あんまり気にしなくても良いのかもしれないけど、javascript で out of memory 的なことって起こるんだろうか。どこまで耐えれるのか、落ち着いたら実験してみたいなあ。

Flashオブジェクトのあるページで、URLにハッシュ値が付いている場合、Flashオブジェクトにフォーカシングすることで、ウィンドウのタイトルがハッシュ値で置き換わってしまう。この現象が確認できたのは、WinIEのみ。あやしすぎる挙動だす。

これがまた厄介な問題だったりする。

ページ内リンク(「ページの先頭に戻る」とか)で、アンカーの値がURLのハッシュ値に設定されると、その次にFlashオブジェクトを操作するだけで、タイトルが謎の文字列に変わるわけで。ブックマークしようとするユーザーが非常に困る。

で、いまのところ対処法が見つかっていませぬ。ううう。

タイトルが変わる原因が分からないので、変わったものを document.title で上書きする方法を考えた。ところが、Flashがクリックされたり、フォーカシングされたイベントで、それを実行しても、効果なし。すぐ別のタイミングで上書きされてしまう。ふざけんなー。

setInterval とかで、一定時間ごとにチェックして書き換えるとか、そういう方法しかないのかなあ。あんまやりたくないなあ…。ヘルプミー。

Yahoo!Maps のように、FlashとJavascriptを連携させて、URLのhashを書き換えていこうと思ったら、ずっこけた。悪名高きOperaで location.hash を書き換えると、勝手に画面がリロードされてしまう。なぜ。

いろいろ追っていった結果、現在のhash値と代入する値が同一の場合、リロードになるっぽい。どんな仕様ですか。しょうがないので、if文で分岐するがよろし。

function setHash(_value) {
    if(location.hash != "#" + _value) {
        location.hash = _value;
    }
}

「これはバグだ！」と思ったら、なんか Safari でも同じような動きになる。スタンダードって何だろうとか考えさせる、罪なブラウザたち。やめて欲しい。

続きを読む "location.hashの書き換えでリロードが発生"

HTMLからFlashに変数を渡すには、2通りの方法がある。ひとつはFlashVarsを使用する方法、もうひとつはSWFファイルURL指定時に、クエリーとして変数を付加する方法。

// 後者抜粋
<param name="movie" value="deftrash.swf?hoge=foo" />
<embed src="deftrash.swf?hoge=foo" ... />

前者は FlashPlayer6 以上で、後者はもっと前の世代でもOK。そんなわけで、後者の方法を使用している人も多いはず。ところが、ここで落とし穴。変数の文字列に「#」が含まれていると、Operaでは、「#」以降の文字列を渡すことができない！(FlashVarsの方法では大丈夫っぽい)

どうやらURLエンコーディングしてあげる必要があるみたい。

// JavaScript で対応する場合
<script type="text/javascript">
document.write("<param name=\"movie\" value=\"deftrash.swf?hoge=\" + escape("#foo") + "\" />");
document.write("<embed src=\"deftrash.swf?hoge=" + escape("#foo") + "\" ... />");
</script>

location.hashをFlash側に渡そうとして、コレにすごいハマった。Operaとかスゴイ嫌いだよ。ううう。