「超上流」のプロセス管理がプロジェクト成功の条件

http://enterprisezine.jp/article/detail/903

社内のプロセス管理だけではなく、共通フレーム2007 の話として「見積りと契約を改めて標準化する」特に「契約の変更管理プロセス」というのがとてもうれしい。

というか総じて、自社内で閉じるプロセス改善の話ではなく、「要求・要件・見積もり・契約のプロセス管理」の話がメイン。共通フレームというのはそういうところには本当に役に立ちそうだ。

swfupload で upload_url に相対パスを指定する場合の注意

http://swfupload.org/forum/generaldiscussion/1022

IEで利用した場合、コメントにある挙動とは異なり、フラッシュを配置しているHTMLページのURLに対する相対パスとして解釈される。

このため、IE,FF の両方で問題なく動かすようにするためには、ページとswfupload.swf ファイルを同じディレクトリに置くのが安全。

絶対URLで指定した方が安全、という主張もあるが、デプロイ作業のことまで含めたら出来る限り相対パスで書く方がよいだろう。ASP.NET等の力を借りれば絶対パス化することはもちろんできるが。

地道を楽しめるのは一種の才能

http://mamico.way-nifty.com/note/2008/12/post-29e6.html

地道の先に楽しみがあるかどうか、地道な作業の中にそれを見いだせるか、ってのは確かに才能なような気もする。

プログラマの三大美徳「怠惰」、までいくと少し極端だけど。

WBS 80時間ルール

http://jibun.atmarkit.co.jp/lskill01/rensai/pwhyf07/pwhyf01.html より

どこまでWBSを詳細化すればよいのだろうか。これに関して、米国のPMI（Project Management Institute）では、80時間ルールを推奨している。WBSの最下層では、その作業時間が80時間以内になるよう作業の分割を行うというルールである。

なぜ80時間かというと、これ以内の作業であれば、人間は頭の中でコントロールができるだろうという考えに基づいている。逆にいうと、これ以上の作業は人間の頭の中だけで作業を行うのは無理があるということだ。WBSを作成する際、この基準を参考にしてブレークダウンを進める必要がある。

しかも規模によっては80時間にブレークダウンできないかもしれない、と話が続く。80時間=2人週 だ。全体設計のレベルではこれぐらいの粒度にするということか。

そして2週間といえば、スクラム開発は「2週間単位のイテレーション」が目安となっている。WBSでやるべきことを分割したら、それを2週間の中でどうこなすか、という場面ではスクラムやその他XP的な開発手法を用いるとよいのではないか。

例え見込みが外れて2週間でリリースまでもっていけなかった場合、次回リリースタイミングはその2週間後ではあるが、それでも進捗率を報告して「確実に次回リリースさせる」ということはできるだろう。そしてなぜ見込みが外れたかをふりかえりを行って、原因を共有できるようにしたいなあ。

スクラムとWBSによるプロジェクト管理はそれほど相反するものではないのかもという気がしたのだった。

プログラミング言語AWK

http://uyota.asablo.jp/blog/2008/11/18/3953270 「uyota 匠の一手」での awk 紹介

1989年トッパンから出版された本の プログラミング言語AWK は名著で、私にとっては「プログラミング言語C」以上に世話になったんではないかと。perl 普及前夜には awk スクリプトを大量に使っていたものである。

どうしても使いたい機能拡張があって、gawk に自分でパッチを当てて使っていたこともあり大変懐かしい。機能拡張したのは具体的には strftime の組み込み。

awk の内部処理は、テキストを１行読むごとに毎回 yacc(bison) の構文で書かれたパーサを通るようになっていて、これはperlより遅いわけだ、とそんなことを感じた記憶がある。

ネットゲーム アーキテクチャ

SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。

ネットゲームに限らず、「クライアント側にデータを持たせつつ、クライアントを信用しない」というような構成は今後ますます重要になると思う。

ぱっと思いつく範囲では、データのかたまりに電子署名かけて定期的に検証かなあと。

もちろん重要なトランザクションの場合は毎回検証するとして。