Software Factories
パターン、モデル、フレームワーク、ツールによるアプリケーションの組み立て
著者：Jack Greenfield、Keith Short
with Steve Cook、Stuart Kent
監訳：野村 一行
監修：マイクロソフト株式会社
ISBN 4-89100-472-X
2005年12月19日発売
B5変型判／664p、定価5,040円（税込み）
ということで、やっと今月発売らしい。正月はこれを読むことになるのか。
まだアマゾンでは予約受付をしていないみたい。
「オブジェクト指向・システム開発」カテゴリーアーカイブ
業務システムの開発ドキュメント標準「DUNGEON（ダンジョン）」
業務システムの開発ドキュメント標準「DUNGEON（ダンジョン）」-ThinkIT
http://www.thinkit.co.jp/free/project/4/1/1.html
滝派の人どうぞ。
設計文書をどのような粒度でまとめるべきか参考になります。
すーん。しかし見事なぐらいに全部Excelだな。。
しかし作業標準とか考えるとアジャイルは難しいな。元々スケジュールが数年単位で引かれるプロジェクトにはアジャイルは向いてないかもしれないけど。(機敏に作る必要はないよね。)
また、プロジェクトのファシリテは、今アジャイルとして注目されてるけど、本来プロジェクトのファシリテが必要なのはアジャイルだけではないはずで、滝でも当然実施すべきだよな。
訃報：JohnVlissides死去
MF Bliki: JohnVlissides
“Gang og Four”の一人である、JohnVlissides氏が亡くなられたそうだ。ご冥福をお祈りしたい。
社内情報共有としてのＰＯＤキャスト
ITmedia エンタープライズ：ポッドキャスティングを活用するIBMの従業員
現状では社内での知識共有のためには、Notesのようなグループウェア、最近だと、Wikiや社内Blogというような形で、基本的にはテキストベースによる、暗黙知の「見える化」と共有を行う努力をしてきたけれど、ドラッカーの指摘にもあるように、現状の仕事の多くはテキスト的な知識と身体的な訓練が複合されて成り立っている。したがって、このような仕事の暗黙知（職人の技術でもいい）を共有して行くにはビデオによるPODキャスティングは有効かもしれない。
そういえば日立製作所が、熟練技術者の仕事をとにかくビデオに保存するという作業をしていると、NHKの何かの番組で見た気がする。
特に日本では、数年後から熟練労働者が極端に少なくなっていくので、技術継承を目的にPODキャスティングによる、暗黙知の集合化は必要になるかもしれない。
1mm厚と薄くて曲げられる点字ディスプレイを東大が試作
1mm厚と薄くて曲げられる点字ディスプレイを東大が試作：IT Pro
これとユビキタスコンピューティングの技術が組み合わされば、軽いデバイスでJITに必要な情報が提供できるようになるなぁ。音声だけだとノイズが大きいところや、音を出しにくいところで不自由があるだろうし。
SSE : Simple Sharing Extensions for RSS and OPML
とりあえず、Simple Sharing Extensions for RSS and OPMLリンク先まとめ
Simple Sharing Extensions for RSS and OPML Spec Ver 0.9
http://msdn.microsoft.com/xml/rss/sse/
Frequently Asked Questions for Simple Sharing Extensions (SSE)
http://msdn.microsoft.com/xml/rss/ssefaq/
RSS : Really Simple Syndication 2.0 Spec
http://blogs.law.harvard.edu/tech/rss
OPML : Outline Processor Markup Language 1.0 Spec
http://www.opml.org/spec
Ray Ozzie Blog
MS CTO Ray OzzieのBlog
http://spaces.msn.com/members/rayozzie/
このブログではSSEに関するプロジェクトの話題を扱っていくのかな？
SSEはGrooveの人材が中心になって進んでいるプロジェクトのようで、実際にはRay Ozzieも深く関わっているのではないかと思う。SSEは緩いアプリケーション間連携を取るためのXMLデータフォーマットで、相互にフィードし合うことで、アプリケーション連携を行う。
そう。Grooveのように。
カイゼン活動に参加したあるSEの日記を読んだ
カイゼン活動に参加したあるSEの日記：IT Pro
1年で成果が上がってくるって言うのはやっぱりすごいな。
朝会はやれてるけど、進捗管理はまだ上手くできていなし、振り返りの導入もまだこれから。
来年度からできてくるはずのチームではこの辺を上手くやるようにしたいなぁ。特に振り返り。
「アルゴリズム＋データ構造＝プログラム」→？
「アルゴリズム＋データ構造＝プログラム」？ 本当に？ Rogue Engineer’s Diary / やさぐれ日記(2005-11-13)
「アルゴリズム＋データ構造＝プログラム」
↓
「アルゴリズム＋データ構造＋インターフェイス＝プログラム」
と言う提案。
プログラムのスコープが単一のモジュール、数少ないプロシージャ(サブルーチン)の組み合わせによる単一ソフトウェアを実行する時代と、多数のモジュールの組み合わせによるソフトウェアシステムの時代の違いかと思う。
これも科学ではなく技術的な正しさが優先する事の一つだと思う。
東証のシステムダウン原因はオペミス。そうですか。
東証ダウンの原因はオペミス – 栗原潔のテクノロジー時評Ver2 [ITmedia オルタナティブ・ブログ]
原因はシステム構築側の富士通から、運用側の東証コンピュータシステムズへの作業指示書に間違いがあったと言うことらしいのですが、これは一方的に富士通を攻められるのかと言えば、そうでないと思います。
問題はここです。(上のブログから引用)
ここで、ちょっと気になるのは東証の運用体制で、ひょっとして運用に変更があった時はテストしないでぶっつけということなんでしょうか？要するに今回に限らず運用手順書に記載漏れがあったらかなりリスキーということですね。問題の根はそこにありそうな気がします。
おそらくベンダーから納入された状態のまま確認もしてないし、ベンダー側も作業指示書での試験をしてないと言う結果です。ベンダー側の責任ももちろんありますが、受け入れ側の仕事もお粗末だとしか言いようがありません。これは普段僕ら仕事させてもらっている公共事業者の各ご担当との間ではあり得ないことです。
２ちゃんねる情報（とは言え、いかにも内部情報通の人が書いている感じ）なんですが、欧米の証券取引所では本番と同等構成のシステムがテスト用に用意されておりいつでも並行テストできるようになっているそうです（信頼できるソースがないか調査中）。
試験環境はすごく大事ですね。複雑なシステムになるほど実記と同等の環境でのテストが欠かせませんし、運用に近い状態のテストも必要ですね。設備自体をどちらが持つかというのは難しい問題ですが、東証であれば、他取引所のシステム運用も担っているわけで、東証はただのユーザーではなく、サービスベンダーでもあるわけ(当然各証券会社に対してもそうですね)ですから、東証側で持っても良いのではないかと思います。
と言うよりもいかに東証が業者丸投げで、自分のところで責任を持っていないかと言うことでしょう。ベンダを訴訟している場合ではないと思うのですがね。