Tuesday, January 30, 2007

ルールを破る勇気 - Edward Yourdon [memo]

ソフトウェア開発手法の先駆者の1人として知られ,今日ではよく語られる「デスマーチ」という概念を定義した Edward Yourdon が来日している.

今日,JaSSTソフトウェアテストシンポジウム で講演も行ったようだが,昨日はとある企業を訪ずれていたようで,彼の Blog で日本のエンジニアに対する印象が語られている.

The Yourdon Report: Blogging Japan

First impressions, from conversations with a few software engineers and managers, and a day-long visit to one large high-tech company: Japanese software developers probably work longer and harder than their American counterparts, but they are still frequently regarded as "second-class citizens" by their hardware-oriented peers and managers. Because they work so long and so hard, the nearly universal complaint that I've heard is that they have little or no time to study, to read new books, to learn about new developments in the field, or just to think about what they're doing.

あるハイテク大企業を丸1日訪れ,ソフトウェアエンジニアやマネージャーと会話を交した第一印象はこうだ.日本のソフトウェア開発者は,おそらくアメリカの同業者よりも長時間熱心に働いているにも関わらず,ハード屋やマネージャーからは「脇役」として扱われている.さらに,あまりに長時間絶えまなく働きすぎているせいで,本を読んだり新しい技術領域を学んだりする時間,さらにはそもそも自分が何をやっているか考える時間が無い,という愚痴が普遍的に蔓延しているように思う.(要約・意訳)

確かに「日本人はワーカホリック」という話はよく聞くが,では日本の企業 (特にソフトウェア業界) がアメリカに比べてそれだけ生産性があるかどうかは,疑問が残るところだ.


さらに興味深いのはこの一文.

Apparently, the most provocative thing I've said so far to the Japanese software folks is that if they want to survive and succeed with a "death-march" software project, they'll need to be willing to break whatever administrative/bureaucratic rules are slowing them down.

私が日本のエンジニアに話した中でおそらく最も刺激的だったのは,「もしデスマーチプロジェクトの中で生き延びて成功したいなら,無駄と思われる管理的かつ官僚的なルールを破ること」というものだ (要約・意訳)

奇しくも 先日レビューした,天外 伺朗 (土井 利忠 元ソニー上席常務) の「マネジメント革命」に,まったく同じことが書かれていた.つまり,「成果主義」などの合理的なマネージメントにより,エンジニアは失敗を恐れてルールを破れなくなってしまい,斬新なアイデアが生まれにくくなり,意味のない仕事をする時間が増えてしまった,ということだ.

例えマネージャーがどれだけ優秀でも,開発のことは現場の人間が一番良く分かっている場合がある.「上に言われたこと」に素直に従っていたり,問題意識を持っていてもまず「上を説得して承認を得てから」などとまどろっこしいことをするのではなく,自分の責任において命令を無視し,正しいと思うことを遂行する勇気が必要なのだろう.


うん,よく分かった.
私も明日から胸を張って遅刻することにしよう…って違うか...

エドワード・ヨードン
価格

他人事ではない !
本書で言う「デスマーチ」とは、主にソフトウェア開発を対象として「開発者に過度の負担を掛けながら破綻...
あまなつShopあまなつで見る同じレイアウトで作成


Monday, January 29, 2007

伊勢神宮 [diary]

人多すぎ…
DSC00555


Sunday, January 28, 2007

ソフトウェアアーキテクチャ その8 - フライトシミュレーションケーススタディ [arch]

前回は "Pattern" の観点から適当なケーススタディを紹介したが,今回はこれまで7回に渡って紹介してきた様々なコンセプトを総合的にレビューするのに適したケーススタディを紹介する.

Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003

--> Chapter 8

価格

Software Architecture in Practice (Sei Series in Software En
ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必...
あまなつShopあまなつで見る同じレイアウトで作成
アーキテクトのバイブルとされる本.SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている.

タイトルの "in Practice" (実践における) が示す通り,様々なケーススタディを交えつつ,非常に具体性のある内容になっている.


こちらがその和訳本.



これはフライトシミュレーションのケーススタディであり,非常に興味深いシステムである.

このシステムでは特に「統合容易性」の実現を重視しており,structural model を採用することによりいかに様々な問題を解決したか,具体的にはシステムのサブストラクチャにおける単純化と共通化,データ (および制御) を演算処理から分離する方針,モジュールタイプの最小化,システム全体に及ぶ調停を少なくする方針,設計の透過性の実現などが語られている.

しかしこのケーススタディから読み取りたいのは,その1つ1つの細かい実現方法ではなく,むしろ全体としてアーキテクチャがいかにシステムに作用し,どんな役割りを持っているか,である.

これまでに解説してきた様々なキーコンセプトを頭に入れつつ内容を読めば,
- ステークホルダーからの要件を明確にして分析すること
- 品質特性の重要性とトレードオフの概念
- structure を理解することの強み
- アーキテクトの役割り
などを再確認できるはずだ.

つまりゴールを確立し,それを実現する為のアーキテクチャ選択という「意思決定」が,どのように行われているかに注目したい.


ところで本章 Figure 8.4 は,"surrogate" と "event handler" が逆になっている誤植があるので,その点だけ付け加えておく.

この「ソフトウェアアーキテクチャ」シリーズもここで一段落つけ,次回から新しいフェーズに入って行くことにしよう.


ソフトウェアアーキテクチャ その7 - パターンの実際 [arch]

我々が問題を解決する際,まったく新しいソリューションを発明することは稀であり,過去の類似した問題の解決方法 (またはそのエッセンス) を再利用することが多いだろう.これは "problem-solution pairs" と呼ばれ,建築や経済などの分野でも有名な概念である.

Pattern は「過去に実証された知識の再利用を可能にする」と述べたが,つまりこれは "problem-solution pairs" を抽象化・体系化し,共通の特徴を抽出したものが pattern であるからに他ならない.

では実践における pattern を見る為に,今回はいくつかのケーススタディを紹介したいと思う.

Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996

--> Chapter 3

ソフトウェアアーキテクチャを最初に定義した本.

1996年発行と内容は少し古く,今日の開発に実践できる内容は少ないが,ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる.

エンジニアとして「自分の引き出しを増やす」という意味では,ぜひ手元に置いておきたい1冊だ.


Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003

--> Chapter 6
価格

Software Architecture in Practice (Sei Series in Software En
ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必...
あまなつShopあまなつで見る同じレイアウトで作成
アーキテクトのバイブルとされる本.SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている.

タイトルの "in Practice" (実践における) が示す通り,様々なケーススタディを交えつつ,非常に具体性のある内容になっている.


こちらがその和訳本.



"Software Architecture: Perspectives on an Emerging Discipline" の第3章には,合計7つのケーススタディが紹介されている.1つ目は,同じ問題に対して異なるアプローチがそれぞれどう作用するかという例 (3.1章),2つ目は,専門性の高い領域における pattern 活用の例 (3.2章),3つ目は可動式ロボットにおける様々な pattern の比較 (3.3章),4つ目はクルーズ制御システムにおける process-control の適用方法 (3.4章),そして残りの3つはシステムに複数の pattern が混在する例 (3.5章) である.

ここでは可動式ロボットにおける様々な pattern (3.3章) を見てみることにしよう.

本書では,このロボットに対して Control Loop, Layers, Implicit Invocation, Blackboard という4つの pattern を用いた解決方法を比較している."Layers" は一般的には module viewtype を指す言葉であり (本書が発行された1996年には "viewtype" という概念が無かった),今日では C&C における階層構造は "N-tiers" と呼ばれる為,以下ではそのように記述する.

このロボットに要求されているのは,

Req 1. 環境の変化に応じた動作ができること
Req 2. 不完全もしくは信頼できない情報においても動作すること
Req 3. 電源の減衰や蒸気などの問題で破綻しないこと
Req 4. 開発中の実験や構成の変更に柔軟に対応できること

とされているが,本書の情報だけでは詳細検討に不十分であり (応答測定も示されておらず,そもそもどんなロボットなのかが分からない) 最適な解を導くことができない.視点を明確にする為に,ここでは「障害者用の自動操縦車椅子」のようなもの,つまりそれなりに複雑で,availability が最も重要であり,performance や modifiability が次の優先事項になるようなシステムと仮定した上で,それぞれの pattern を比較することにする.

- Control Loop
Availability の観点で active/passive redundancy, removable from service などの tactics が検討に値する.その他も考慮の余地があるが,control loop の最大の特徴である simplicity を害してしまう.

品質特性としては,availability と simplicity を促進し,adjustability, decomposability, performance などを抑制すると思われる.

このことから Req 1には不利であり,Req 2も trial-and-error で検証が必要なこと,また performance の tactics を適用しにくいことから不利である.Req 3は redundancy が適用でき冗長性を実現できることから有利であり,removable from service も考慮できる.Req 4に関しては,メジャーコンポーネントは代替可能であるが,それらにマイナーチェンジがしにくい点から,どちらとも言えないだろう.

結論として,複雑なロボットシステムには最適と言えず,また simplicity が最大の特徴であるがゆえに tactics を適用しにくいというジレンマがある.

- N-tiers
責務の明確なアサインが可能であり,コンポーネントの整理がしやすい.抽象化の概念も明確になる.

Availability の観点で voting,また modifiability の観点で hide information, use an intermediary などの tactics が適用可能と思われる.Availability と modifiability を促進するが,modifiability は他方で抑制もされるだろう.Performance, flexibility, customizability なども抑制されそうだ.

データと制御を完全に分離できない点から,Req 1には不利である.階層構造の抽象概念は Req 2には有利だが,Req 3の為に performance を促進しようとすると階層をショートカットする手段が必要となり,それが Req 4に不利に働いてしまう.

結論として,システムが複雑であればあるほど現実性が無くなってくる.Modifiability と performance のトレードオフが難しい.

- Implicit Invocation
Event-oriented のアプローチ.

Availability の観点で,exception, active redundancy, transactions, process monitor など,modifiability の観点で semantic coherence, runtime registration, component replacement など,performance の観点で,manage event rate, introduce concurrency, scheduling policy など,様々な tactics が検討に値する.

Availability, performance, re-configurability, flexibility, sustainability, reusability などを促進し,testability, portability, simplicity などを抑制する.

アクションの明確な分離が可能で,並行性も導入しやすいことから Req 1には非常に有利である.スケジューリングポリシーによるイベントレートの管理も可能だろう.Req 2に関しては,一時的な依存関係をタスク間で定義することや exception などでカバーできるかもしれない.Req 3は,exception, wiretapping, monitors が performance と availability を考慮し,また冗長性も容易に実現可能である.Req 4に関しても,インクリメンタルな開発を容易とし,component replacement や semantic coherence などが適用可能である.

結論として,ロボットシステム,特に複雑なものには非常にマッチし,とても強力に作用すると思われる.

- Blackboard
Data-oriented のアプローチ.情報集中型のシステム.

Availability の観点で exception, voting, transactions, process monitor など,modifiability の観点で,runtime registration, component replacement など,performance の観点で introduce concurrency, increase available resources など,testability の観点で record/playback などの tactics が適用可能と思われる.

Availability, modifiability, testability, flexibility, adaptability などが促進され,simplicity が抑制される.Performance もある程度ダメージを受ける可能性がある.

Req 1については共有データで情報交換可能だが,データの流れを強制してしまいかねない.Req 2と3については有利であるが,Req 3を考えるとデータが集中した時のリソース問題が心配になってくる.Req 4は並行性をサポートしており,component replacement も検討の余地があることから有利と言って良いだろう.

結論としては,どんなロボットシステムでもある程度応用可能であるが,複雑なシステムでは特に performance の観点で Implicit Invocation に及ばないと考える.

以上のことから,Implicit Invocation がこの中では最適だと思われるが,以前も述べた通りシステムがたった1つの pattern から構成されることはほとんど無い.

例えばこのロボットであれば Implicit Invocation をベースに,システムに秩序性をもたらす為に Explicit Invocation を平行導入し,そのデータ管理には Repository を採用する,などと考えて行くことになるだろう.


2つ目のケーススタディは,"Software Architecture in Practice" 第6章の航空交通制御システム.ここではその紹介だけに留めておく.

これはかつて実際にアメリカの FAA (Federal Aviation Administration) に対して計画されていたシステムである.

このシステムは「1990年代の計算機におけるチャレンジを全て集めた」とまで言われた.数百万行に及ぶソフトウェアは,何百ものコンピュータに配布され,複雑な分散システムとして実現される必要がある.人命に関わる航空交通システムという性格上,安全性の確保は絶対条件になる.リアルタイム性が高く求められ,タイミングも非常にシビアだ.莫大な資金が投入され,同時に規模も莫大になる.そして技術に非常に長けたエンドユーザー (航空交通システム管理者) を満足させなければいけない.

特にアーキテクチャ的には,availability と performance という,完全に矛盾する2つの品質特性が,両者とも高く求められる点が非常に興味深い.

本書にはこのプロジェクトの全貌とその設計が,様々な view を用いて詳しく語られており,かなり読み応えがある.いくつもの pattern を駆使しながら,いかにこの複雑な要件を解決しているかは,ぜひ本書を手にとって確かめて頂きたい.


Saturday, January 27, 2007

Google が Testing Blog を開始,その名も "Testing on the Toilet" [memo]

Slashdot 経由.Google が Testing Blog を開始した.
Google Testing Blog: Introducing "Testing on the Toilet"
Slashdot - Google Releases 'Testing on the Toilet'

テストに関するノウハウや tips などを紹介し,さらにそのエントリーは,プリントアウトしてトイレの壁に貼っておけるように PDF でダウンロード可能にするとのこと.それで "Testing on the Toilet" とはタチの悪い冗談だ…と思ったら,驚くことに Google 社内のトイレには,本当にテストに関するネタがベタベタと貼ってあるらしく,読者がオフィスで同じことをやり,テストの普及,啓蒙をすることを,本気で勧めているようだ.

ネーミングセンスは置いといたとしても,テストの重要性と情熱を少しでも世界に広めようとするこの Blog のコンセプトは,最高に素晴らしい.


一般的にソフトウェアにおいて「テスト」が軽視されがちなのは事実であり,また非常に残念でもある.

ところが,ソフトの重要性を分かっている会社には「テストエンジニア」という肩書きが存在する.彼等は開発エンジニアになれなかった人間ではなく,あえてテスティングを選んだ人間で,高い専門性と技術力を持ち,開発エンジニアと同等の地位が認められている.

例えば Microsoft には開発エンジニアとほぼ同数のテストエンジニアがいると聞くし,Apple で QuickTime 2.0 - 5.0 までのチーフアーキテクトはテストエンジニア出身なのだとか.


松本人志 第1回監督作品 大日本人 [memo]

松本人志 第1回監督作品 大日本人

「監督からのメッセージ」より.

今も昔もこれからも、僕のつくるものは誰にも毒されてないです。



「制作発表記者会見全文」より.

うーん…観た人が判断するものでいいと思うんですけどね。
僕の近所のビデオ屋さんでは、時代劇コーナーに「志村けんのバカ殿」が置いてあったんですけど (笑)、これはもう分かんないですよね。

(どんなジャンルの映画,と聞かれて)


僕のやりたいことは結構いっぱい詰まったなっていう感じはしてるんですけど。

(コンセプトやストーリーなどを教えて下さい,と聞かれて)


たけしさんの場合は、僕は「テレビのたけしさん」と「映画のたけしさん」っていうのは、何か別の感じで見てるんですけど。うーん、僕は「テレビの自分」の延長上かなと思います。

(北野監督を抜けそうですか,と聞かれて)



オリジナリティがないものに興味がないんで。
おそらく誰も観たことがない映画になっていると思います。


HHK に Mac 専用モデル [mac]

キターーーーッ!! と思ったら Lite2…orz
Happy Hacking Keyboard Lite2にMac専用モデル--英語配列とかな無刻印 - CNET Japan

HHK2 と HHK Lite2 はまったく別物なんですよねぇ.

参考:
Peace Pipe: Mac 環境構築 番外編 - ヒューマンインターフェースにもこだわりたい [mac]


Friday, January 26, 2007

マネジメント革命 [memo]

天外 伺朗
価格

人を管理する側になったら是非一読あれ
人間や組織は不合理である。だから合理的な判断で経営すると失敗する。成果主義はあからさまに外発的報酬...
あまなつShopあまなつで見る同じレイアウトで作成

著者の本名は土井 利忠.元ソニーの上席常務であり,NEWS,CD,AIBO などを開発してきたスーパーハッカーでもある.著者は昨年,42年のソニー生活に終止符を打ったが,あとがきには「本書は,いわばその卒業論文に相当する」と書かれている.

その内容は,従来の一般常識とは真向から対立するものであり,「今後100年間は通用する,新しい経営学として世に問う」としている.

本書は,現在人々が信じている企業経営や組織マネージメントの常識は,致命的な間違いを犯していると主張する.つまりそれらは「人間が合理的である」という間違った前提のものに成り立っているが,そもそも人間や組織は不合理であり,成果主義を始めとする近年の合理的かつ精密な経営学は企業を破綻に導きかねないということだ.

そしてソニーの創業者である井深 大と入社以来身近に接してきた著者が,そのマネージメントスタイルを徹底的に分析し,自分の経験や様々な学説のみならず,脳科学や深層心理学までをも駆使して,組織マネージメントを体系化している.

いわゆる「マネージメントテクニック」が書かれた本ではない.
むしろ著者に言わせれば,「マネージメントはテクニックではない」ということだ.

特に後半はスピリチュアルな内容が多く,一体何についての本なのか忘れそうになってしまうが,全体を通して従来の手法や方法論がまったく無視してきた,人間の本質や深層心理に関する視点に基いて記述されており,目から鱗の内容も多いだろう.

個人的には,「マネージメントとはなにか」というよりも,「人間とはなにか」について,深く考えさせられた一冊.


Thursday, January 25, 2007

しながわ翁 [diary]

DSC00547
会社のビルが品川に移転して,私の職場も先週そちらに引っ越しました.

「しながわ翁」という,有名なそば屋が近くにあると聞いたので,「引っ越しそばを食べに行こう!」とさっそく移転初日に行ってみたところ定休日…ということで,本日再チャレンジしてきました.

少し調べてみると,なんでも伝説の蕎麦職人,高橋 邦弘という人のもとで修行した高野 幸久という人が開いた店で,蕎麦の丸抜きを店内の石臼で挽き,手打ちしているのだとか.

そばもコシが強くておいしかったけど,ポタージュのようにとろとろした濃厚な蕎麦湯が最高でした.

翁達磨 達磨グループ しながわ 翁


若い頃は蕎麦なんてこれっぽっちもうまいと思わなかったし,特に蕎麦湯なんてまーったく意味が分からなかった.一般的に歳を取ると,舌の味覚を感じる能力は低下していくと言われているそうだけど,蕎麦にしろ牡蠣にしろ,大人になってから本当に美味いと感じるようになったものは多いように思う.

さらにネットを少し徘徊してみると,蕎麦焼酎を蕎麦湯で割って飲むのがオツなのだとか.今度やってみよ.


coComment の Firefox 拡張と Google Calendar の競合 [memo]

ここ数日,Firefox で Google Calendar のイベントが表示されなくなっている.正確には,最初にページをロードする時は表示されていて,前/次の期間に移動すると表示されなくなる.イベントの編集もできない.WinXP,Mac,NetBSD 全ての環境で再現する.

なにか Firefox の拡張 (エクステンション) が悪さをしているのかと調べてみると,coComment を無効にしたところで症状が再現しなくなった.


ん? なにか似たような話を聞いたことがある…と思ったら,clmemo@aka さんが報告してくれていた,coComment と Google Reader の競合に似ている.
clmemo@aka: coComment の Firefox 拡張と Google Reader の競合
clmemo@aka: coComment と Google Reader の競合問題、修正される
Google Reader との競合を修正した時の副作用かな?

この時と同じように,ひとまず coComment の自動モードをオフにすると回避できる.

一応,coComment 側にはバグ報告しときました.


【2007/01/26 追記】
さっそく修正されました.
http://www.cocomment.com/forum/viewtopic.php?pid=2650#p2650


Sunday, January 21, 2007

MacWorld 2007 [ce]

前回の CES のエントリー からすぐに,同じ週に開催された MacWorld 2007 のことを書こうと思っていたのに,既に1週間が過ぎてしまった.

遅ればせながら私もようやく Jobs の基調講演を見たのだが,iPhone という衝撃的な製品の発表はもちろん,その魅力を巧みな言葉で明快に伝えた,いつも以上に冴え渡る Jobs のプレゼンは素晴らしかった.スクリーンが切り変わらなくなるという突然のトラブルに対して瞬時に場を繋ぐあたりも,印象的だった.

既にネット上には様々なレビューが出ているので,以下,個人的なまとめを兼ねてその中からいくつかを紹介する.


まずは Steve Jobs の基調講演.
Apple - QuickTime - Macworld 2007 Keynote (要QuickTime)
PodCast でも公開されているので,Video iPod をお持ちの方にはこちらがおすすめだ.
iTunes へのリンク

Engadget の記事がその内容に詳しく,会場の熱狂ぶりもよく伝えている.
Macworld 2007:スティーブ・ジョブズ キーノート - Engadget Japanese


私がいつもプレゼンテーションの情報収集をしている Presentation Zen でも今回の基調講演を取り上げていた.Jobs のプレゼンテクニックを解説することも多いこのサイトだが,今回に関してはゲストスピーカーとして来ていた Cingular の Stan Sigman のスピーチがいかにひどいかを語り,"a wonderful textbook example of what not to do" (悪いお手本の題材としては最適) としている.
Presentation Zen: Steve Jobs at Macworld: "We come from different worlds"

こちらでは,「Steve Jobs はなぜ説得力があるのか」について海外の記事を分かりやすく要約している.個人的につけ加えたいのは,「彼のユーモアのセンス」だ.
maclalalaweblog: Steve Jobs はなぜ説得力があるのか


内容については,Apple TV にも個人的には非常に興味があるが,やはり iPhone の発表に尽きる.歴史的かつ革命的な製品と言って良いだろう.

「我々の孫は『iPhone が発表された時はどこにいたの?』と聞くだろう」などと書いている記事まである.
Steve Jobs is trying to make history here - Personal Tech - Times Online


毎年 CES と Macworld は同時期に開催されるが,今年は完全に重なった.その両者を比較する記事も毎年良く目にするが,今年は Macworld が完全に CES を食ってしまったというのが私を含めて共通の見解のようだ.
キャズムを超えろ! - 全世界の家電メーカーが力を合わせてもApple1社に勝てなかった日
どこよりも「家電メーカー」として面白かったApple−−CES&Macworld総括:ITpro
Life is beautiful: CES vs. MacWorld

というより,今回の発表に絶対的な自信を持つ Jobs が意図的にぶつけてきたという見方が正しいのかもしれない.
maclalalaweblog: 天才ジョブズ(iGenius)


それにしても「全世界の家電メーカーが力を合わせても Apple 1社に勝てなかった日」とは良く言ったものだ.その通りだったのだから,笑うしかない.

私もエンジニアとして製品を世に出す立場にあるが,「歴史を変えるようなモノ作りをしているか?」「できそうなものしか作ろうとしていないか?」もう1度自分に問いかけてみようと思う.


Sunday, January 14, 2007

著作権侵害に対抗するならコンテンツをマーケットに - Bob Iger at CES 2007 [ce]

毎年この時期は,CES (Consumer Electronics Show・世界最大の家電展示会) の内容を楽しみにしている.今年もラスベガスで 1月8日から11日まで開催され,web にはたくさんの記事が出ているが,やはり気になるのは各注目企業のトップによる基調講演だ.

今年も,気になるスピーチをいくつかチェックしてレビューしようと思ったが,Google,Yahoo,Sony などが講演した去年に比べて,今年はそれほど興味のあるものがなかった.Microsoft の Bill Gates の基調講演も「(来年現役引退予定なので) これが最後のプレゼンか?」という噂で話題は呼んだが,内容については特に目新しいことが無かったようで,チェックする気にはなれなかった.

というわけで注目してみたのが,Walt Disney の CEO,Bob Iger の講演だ.考えてみれば CES でメディアの重鎮がプレゼンするというのは,コンテンツとソフト・ハードが表裏一体になった今の時代を表わしている気がする.メディアという意味では CBS の Leslie Moonves も講演していたが,Pixar を買収して Steve Jobs が取締役になった Disney の方がポジションとしておもしろいかな,と.

映像は見つけることができなかったが,音声はここで聞けた.
CES 2007 Keynote: Disney CEO Robert Iger

特に興味を持ったのは,03:55 あたりからの彼の言葉.

And getting the balance right between convenience and pricing is a challenge that is facing all of us who create and distribute content in this digital world, especially where piracy is concerned. And from my perspective, the best way to combat piracy is to bring content to market on a well-timed and well-priced basis.

(特に著作権侵害が危惧される場面において,便利さと価格のバランスを取ることは,デジタル世界においてコンテンツを制作,配給する者全員が直面している課題である.私の意見では,著作権侵害に対抗する最も有効な手段は,最適なタイミングと価格で,コンテンツを市場に投入することだ.)


要は,違法コピーなどの著作権侵害を懸念して規制を設けるのではなく,安い値段で気軽にみんなが見れるようにしちゃいなよ,ってことだ.いやオッサン,よく言った!


それにしても,私はディズニーランドには 特別な思い入れ があるだけに,"Disney is a brand like no other" などと言いながら企業としてのポジションで Disney を淡々と語るそのスピーチには,少なからず複雑な心境だった.


参考:
Peace Pipe: CES 2006の基調講演とプレゼンテクニック [ce]


ソフトウェアアーキテクチャ その6 - パターンとその解釈方法 [arch]

'Pattern' の定義については,'View' や 'Viewtype' といった概念も含めて,第3回 参照.

Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996

--> Chapter 2

ソフトウェアアーキテクチャを最初に定義した本.

1996年発行と内容は少し古く,今日の開発に実践できる内容は少ないが,ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる.

エンジニアとして「自分の引き出しを増やす」という意味では,ぜひ手元に置いておきたい1冊だ.



第3回で述べた通り,pattern は,要素と要素間の関係,またそれらの組み合わせに関する制約を定義し, 過去に実証された知識の再利用を可能にするものだ.一般的に現実社会のシステムは,複数の pattern の組み合わせで構成されていると考えて良いだろう.

同じく第3回で,「アーキテクチャドキュメントというとレイヤ構造図や依存関係図ばかり見る気がするが,むしろソフトウェアアーキテクチャを本質的に表現するのは動的分析図である」と述べたが,つまりこれは C&C viewtype の pattern ということになる.代表的な pattern の一覧は,
http://softarchpract.atw.hu/ch05lev1sec9.html
の Figure 5.14 が見やすくまとまっている.

各 pattern の詳細については本書第2章か,第3回で紹介した Documenting Software Architectures (和訳版は こちら) の 第3・4章を参照頂くとして,以下ではそれよりもう1歩踏み込んでみたいと思う.


実は現状, pattern の標準的かつ完全な説明というものは,世に存在しない.つまり今日のソフトウェア工学は,システムの structure (構造・実体) を,その潜在的な理念や用途まで含めて体系化するに至っていないのである.

実体がドキュメント化された時に,その内容を体系化して粒度を合わせ,詳細を詰めながら何が重要かを見つけ出し,要求に沿っているかどうかを考察するのは,読み手に委ねられてしまっていることがほとんどだ.

こんな状況の中, なんらかのシステムやドキュメントで pattern に直面した時,あるいは自分が pattern を記述しようとしている時に,頭に置いておきたいのが以下の6点である.

これらは pattern を解釈し分析する際のフレームワークとして機能し,その用途を導いてくれる.


(1) 表現の view と視点
(perspective and view of the representation)

その pattern は「どの視点でものを話しているのか」ということ.

本書の pattern の説明でも視点は明確に伝わっておらず, 「はい,これが client-server ですよ」で終わりだ.

そもそも,GoF にしろ,Bushman にしろ,Shaw や Garlan にしろ,SEI にしろ,様々な研究者や団体が提唱している手法や方法論は,互いに矛盾していることも少なくない.なぜなら,語っている粒度がバラバラであり,そして視点が明確にされていないからである.


(2) 位相的配置
(topological arrangement)

何度も何度も目にするのは何なのか,ということ.
同じものが,何度も何度も登場してくるのは,すなわちそれが pattern であるからだ.

もちろんこの時でも,(1) の view が明確ではないと役には立たない.


(3) 要素とその関係
(elements and relations)

要素とその関係は,structureの基礎である.
視点 (1) が分からなければ,要素とその関係も分からないだろう.


(4) Pattern の意味付け (セマンティック)
(semantics of the pattern)

使用する際のルールが何なのか.
用途のルールを知らなければ,何の理解にもなり得ない.


(5) Pattern によって促進される品質特性
(qualities promoted by the pattern)


(6) Pattern によって抑制される品質特性
(qualities inhibited by the pattern)


この中でキーとなるのは (4) である.
(1) - (3) が分からなければ,その使い方 (4) は分からない.そして (4) が分かれば,(5) と (6) も分かるのだ.

これで始めて「知識の再利用」が可能になる.

促進するべき品質特性まで分かっていれば,「候補となる structure」が自ずと頭に浮かぶはずである.

現実の設計で pattern を見つけた時は,それが再利用できるように,どう (1) - (6) を記述するか,あるいは本の中で pattern を見たら,それをどう (1) - (6) の観点から落とし込んで現場で使えるようにするか,という点が非常に重要なポイントなのである.

ちなみにこれは,tactics には当てはまらない.なぜなら tactics は structural ではないからである (実体というよりも,むしろ実体に適用する戦略的なものである).


以上の概念は,現在どの書籍にも書かれていない.先日,SEI の某アーキテクトが「あまりに重要な概念であるにも関わらず,あまりに疎かにされている」と嘆きながら話してくれたものである.そろそろウンザリしてきたので,彼が現在執筆中の書籍で明確にしようとしているとのことだ.

彼の言葉を借りれば

"feed me for a day" or "feed me for a lifetime,"
I'd choose "feed me for a lifetime."

とのこと (英語の表現で,"feed me for a day" とは魚を与えること,"feed me for a lifetime" とは釣り方を教えることを例えて指す).

つまり,今回の reference である本書における「1つ1つの pattern の説明」や,その他書籍に書いてあることはもちろん重要だが,それは "feed me for a day" であり,アーキテクトが styleや pattern,もしくはどんな構造的要素 (structural elements) でもそれを見た時に (1) - (6) の観点で考えることこそ本質的な考え方であり,一生モノの "feed me for a lifetime" ということである.


Thursday, January 11, 2007

Apple TV の何がすごいって [ce]

そりゃやっぱり,リモコンでしょう.
http://www.apple.com/jp/appletv/specs.html

家電メーカーのリモコン はこんなにボタンがいっぱい…


企業の人間性,という概念 [diary]

先日,とある小さな会社を運営する友人と飲みに行った.

よく「うちの会社は5年は遅れている」なんていう話を聞くけど,実は「あえて5年遅らせることの美学」があるんじゃないか

とか

技術者が文系の頭で考えることが大事なんじゃないか

みたいな,いろいろ興味深い話をした気がするんだけど,なんせかなり酔っぱらっていたのであまり覚えてません…

前者は「今日の技術躍進はとても激しいけど,それについてこれる企業ばかりじゃないから,そこに注目すべき市場があるんじゃないか」とか,後者は「技術では何でもできて技術はボトルネックにならないことの方が多いから,結局はアイデアが勝負で,それは文系の頭から出てくる.でも実現するのは理系の技術だから,理系の技術者が文系の頭も持つことが大切」とか,確かそんな話だったかな…


明確に覚えてるのは,最後に彼が

結局は人間性だよね

と言っていたこと.

彼曰く「ソニーは長けた人間性で勝負したい企業なんじゃないの? サンヨーはあえてその逆を狙ってておもしろいけど」と.

よく「エンジニアは,直接を話をすることができないユーザーと,製品を通してコミュニケートしているわけで,ユーザーは技術なんかよりも製品に乗った世界観とかコンセプトに共感を覚える」みたいなことを言うけど,「人間性」という言葉は新鮮だった.


Peace Pipe 満1歳 [blogger]

この Blog も1周年を迎えることができました.

みなさんのコメントやトラックバック,Page View が本当に励みになります.

あいかわらず書く内容もてんでバラバラの駄文・散文ですが,今後ともよろしくお願いします.


Google が「働きやすい企業」トップ [memo]

ITmedia より.
ITmedia News:Google、Fortune誌の「働きやすい企業」トップに

1日に1300通もの履歴書が送られてくるとか.

Slashdot でも盛り上がってます.
Slashdot: Google Tops 100 Best Places To Work


Monday, January 8, 2007

平和なんて1日あれば - 長野時計店のコピー [memo]

嫁さんが,長野時計店のコピーが非常に感動的だと教えてくれたので,さっそく覗いてみた.
長野時計店のコピーが凄すぎる:じだらく-マーケティングが語りたいけど語れない人のブログ

特に印象的だったのは最初のコピー.

ひとりがすると1時間かかることを、

ふたりでやれば30分で終わる。

ひとりがすると1ヶ月かかることを、

30人でやれば1日で終わる。

人類が何千年かけても

まだできないこと

みんなでやれば

1日で終わるかもしれない。

もう、平和なんて、

1日あればできるはず。


時に、チカラを。
宝石 時計 長野


…John Lennon の歌詞みたいじゃないか!


ソフトウェアアーキテクチャ 番外編 - QAW [arch]

今回の番外編は,Quality Attribute Workshop (QAW) というものの紹介.

Reference:
Quality Attribute Workshops (QAWs), Third Edition
by M. Barbacci, R. Ellison, A. Lattanze, J. Stafford, C. Weinstock, W. Wood
Technical Report CMU/SEI-2003-TR-016: Software Engineering Institute, 2003



ここまでで品質特性がいかに重要かを再三述べてきたが,実際に品質特性を正しく定義することは非常に難しい.

QAW とは,関係するステークホルダーを全て集めて,丸一日かけてプロジェクトの品質特性を,品質特性シナリオまで含めて定義してしまおうというイベントで,

1. QAW Presentation and Introductions
2. Business/Mission Presentation
3. Architecture Plan Presentation
4. Identification Architectural Drivers
5. Scenario Brainstorming
6. Scenario Consolidation
7. Scenario Prioritization
8. Scenario Refinement

というステップで構成されている.

実際の開発現場では,様々なステークホルダーがそれぞれの思惑の中で勝手な主張をして,仕様が二転三転するケースが少なからずあるが,QAW は話が発散せずに建設的な議論を行う工夫が散りばめられている.

特にアーキテクチャ決定要因の議論に入る前に休憩を設けて参加者同士が話をするように意図的にしていたり,優先順位設定を投票制にしている点などはなかなか興味深い.


どのような方法を取るにせよ,開発の初期段階でシステムの品質特性を認識し,そのシナリオ定義と優先順位設定を行い,全てのステークホルダーがそれを確認した上で合意することは,設計を進める上で非常に有益なことだ.

本ドキュメントはとても読みやすい英語で書かれている.参考にできる要素も多いと思うので,興味がある方はぜひ一度目を通してみると良いだろう.


ソフトウェアアーキテクチャ その5 - 品質特性の実現手法 [arch]

前回,アーキテクチャ決定要因の中でもとりわけ品質特性と6つの要素から成る品質特性シナリオによる分析がいかに重要かを述べたが,今回は品質特性の実現手法について書いてみたいと思う.

Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003

--> Chapter 5

価格

Software Architecture in Practice (Sei Series in Software En
ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必...
あまなつShopあまなつで見る同じレイアウトで作成
アーキテクトのバイブルとされる本.SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている.

タイトルの "in Practice" (実践における) が示す通り,様々なケーススタディを交えつつ,非常に具体性のある内容になっている.


こちらがその和訳本.



アーキテクチャ決定要因を分析し,優先順位もつけたとしよう.ではここから具体的に特定の品質特性を実現するにはどうすれば良いのだろうか.

本書ではこの実現手法を "tactics" と呼び,その集合を "architectural strategy" と呼んでいる.

Tactics 1つ1つは特に新しい概念ではなく,実際の開発でよく見かける設計方針を体系的に整理し,特定の品質特性に紐付けたものだ.

例えば availability (可用性) の実現には,fault detection (障害検出),fault recovery (障害復帰),fault prevention (障害防止) といった要素があり,それぞれの tactics は,

Fault detection
 - Ping/echo
 - Heartbeat
 - Exception

Fault recovery
 - Voting
 - Active redundancy
 - Passive redundancy
 - Spare
 - Shadow
 - State resynchronization
 - Checkpoint/rollback

Fault prevention
 - Removal from service
 - Transactions
 - Process monitor

 となる.

これを見ても分かるように,ping を飛ばしたり,ハートビートやエクセプションを使ったり,あらかじめシステムに冗長性 (redundancy) を持たせたり (ハードディスクをミラーリングするとか) などは特に珍しい話ではないだろう.

他の品質特性も含めて各 tactics の詳細については,本書の5章,もしくは以下を参照頂きたい.特に各セクションの最後には各品質特性に属する tactics が分かりやすくまとめられている.

Availability Tactics
 → Figure 5.3. Summary of availability tactics
Modifiability Tactics
 → Figure 5.5. Summary of modifiability tactics
Performance Tactics
 → Figure 5.7. Summary of performance tactics
Security Tactics
 → Figure 5.9. Summary of security tactics
Testability Tactics
 → Figure 5.11. Summary of testability tactics
Usability Tactics
 → Figure 5.13. Summary of usability tactics


実際の開発においては,まず architectural pattern を先に決め,それから要件に応じて tactics を適用しながら pattern を洗練させていくやり方もあるだろうし,先に採用する tactics を決め,そこから pattern に落とし込んでいくやり方もあるだろう.個人的な経験では,制約から pattern が見えてくる場合が多く,そこから複数の pattern を組み合わせながら tactics を適用していくアプローチが多いように思う.


前回「全ての方針決定はトレードオフを伴う」と述べた.
例えば問題領域の関係を疎にすることが先決であると判断し,architectural pattern として "client-server" を採用したとしよう.

Pattern は特定の品質特性を促進し,特定の品質特性を抑制する.client-server を採用したことにより,スケーラビリティを上げた一方で,performance,security,availability などは低下してしまった.これが問題かどうかは要件分析結果次第だが,このシステムは availability のプライオリティが高かったと仮定して,それを促進する為に availability tactics の適用を検討する.

ここでもトレードオフはあり,例えば ping/echo を採用すれば performance をさらに下げるだろうし,voting は testability を下げるだろうし,spare では満たしたい availability には不十分かもしれない.

…といった具合にバランスを取りながら1つ1つの方針を決定していき,いかにシステム全体として品質を高めていくか,ということがトレードオフの概念だ.要件分析と優先順位設定を注意深く実施し,ビジネスケースをアーキテクチャにマッピングしていくことがなにより重要なことである.


こういった設計の具体的な手順についてもいずれ本シリーズで扱いたいと思うが,最近よく思うことは,正しい見積りを行う為にはアーキテクチャを予見することが不可欠であり,しかもそのアーキテクチャは担当者に可視化されていなければいけないということだ.

それを怠ると,どこまでやれば終わりか担当者に見えず,特に開発の初中期段階でグループリーダーレベルが不安になり,二言目には「人が足りない」「終わらない」という言葉が出るようになる.これはグループリーダーの能力が低いと言うよりは,アーキテクトの責任によるところが大きいのかもしれない.