タグ

2007年1月18日のブックマーク (8件)

  • 最速インターフェース研究会 :: そろそろライブドア事件について一言いっておくか

    今から1年前2006年1月16日はライブドアに強制捜査が入った日で、その日自分が何をしていたかというと社長面接を受けに行っていた。たかだか面接に大げさなもので、六木ヒルズの周辺には報道陣が詰めかけており、張り詰めた空気の中、何も知らずに六木ヒルズに突入すると、こんな状況ですいませんと茶菓子も出されずに真っ直ぐ家に帰された。全くひどい会社である。俺の面接と強制捜査とどっちが大事なのか、冷静に考えてみれば分かる話である。 (以下ノンフィクションに一部誇張を交えてお送りします) 強制捜査なんてものは言ってしまえば良くある話で、それに対して俺が面接を受けるとなると世紀に一度あるかないか惑星直列ぐらいの確率である。てっきり報道陣もそっちを取材しに来たのかと思ったらスルーである。全力スルーである。この手の事件に関するマスコミのスルー力ときたら大したもので、唯一かまってくれたのはスポニチだけだった。

  • 嫁や子供が居る人はソフトウェア開発の仕事をするなという警告

    上司様、どうか家に帰ってください。 フロアの半分以上が22時以上に残っていないでください。 見てる、私の将来も不安になります。

    嫁や子供が居る人はソフトウェア開発の仕事をするなという警告
  • その後の顛末 - ブログは死なず、ただ放置されるのみ。

    そういえば、この件は触れたくなかったような気もするが、とりあえず書いておく。 今の前のプロジェクトで見事にデスマーチを演出してくれた某社のプロジェクトマネージャーさんが、今の案件から担当を外されたそうです。 風の噂レベルの情報なので、想像するしかないのですが、その某PMさんは体育会系で「とにかくなんとかするんじゃあ」みたいな人で、仕事のやりかた(アウトプットではなく)も細かいところまで「こうしろ」と強制する方で、自分の得意技が封じられた状態で仕事をさせるという、結構最悪な方でした。紳士でしたけどね。 で、担当を外された理由を聞いてると、どーも話を聞いてると、顧客要求に対し「それはできない」を連発したからなんだそうですが、前のデスマーチ経験を生かして実際に作ることができないと見えていることを率直に具申されたから外されたのなら、寂しい話だと思いました。「やります」という担当がでてくるまでぐるぐ

    その後の顛末 - ブログは死なず、ただ放置されるのみ。
  • デスマーチの中で演じるべきは「火消し」ではなく…… / ただただし@「ただのにっき」のエンジニアいとをかし/Tech総研

    興味深い体験談を読みました。デスマーチについて考える前にデスマーチの経験を書くとその続編デスマーチについて考える(デスマーチ経験のエピローグ)です。 デスマーチ経験者がその「当時」を振り返るのは、戦争経験者が体験談を語るかのようなもので、懐かしがっているようにも感じられる面があるものの、やはりその悲惨な状況は、涙なくして読めません。同じ経験者がそれを読んだり聞いたりすると、なんだか戦友の話を聞いているような気になってしまうものですね。 さて、このkshさんはいわゆる「火消し」としてプロジェクトに投入されたわけですが、「火消し」といってもいろいろあるものです。一番ひどいのは現場に爆発物を仕掛けて一気に消火を狙うタイプで、跡地には何も残らなかったりします。一方、火の出ているところをきちんと見極めて、地道にかつ確実に火を消していくタイプの人は、多少時間はかかっても結果的によい成果を残す、よい火消

  • デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。

    その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ! ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが(幸運にも!)教えてくれても、それが議事録に書かれることはなかった。 受けたプ

    デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
  • ksh Days - デスマーチについて考える(デスマーチ経験のエピローグ)

    このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低1箇所は触ってみる。(でよく落ちる) バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら

    ksh Days - デスマーチについて考える(デスマーチ経験のエピローグ)
  • 終わらない仕事

    人は何営業日続けて終電で帰ったら会社に行きたくなくなりますか? 人は何営業日続けて会社に泊まったら仕事を投げ出したくなりますか? オプション:空気を読まずに仕事を押し付けてモチベーションダウン1.5倍。

    終わらない仕事
    L42
    L42 2007/01/18
    好きだったり、楽しかったりするなら、いくらでもOK。逆なら直ぐに限界が来るさ。
  • デスマーチの特徴

    This guide is the safest way to do a domain switch, you get all you need to change a blocked domain. What is a user flow and a user journey? There’s a macro view of a customer experience that we can analyze and partially control.

    デスマーチの特徴
    L42
    L42 2007/01/18
    もうつかれちゃったよぼく