2006年12月30日土曜日

Big Frog Bleshing Winter Tour at SuperDeluxe [music]

DSC00531.JPG
Big Frog のライブも今日で4回目.先日リリースされた ライブアルバム は,その後 iPod のヘビーローテーションになり,今日のライブは前から楽しみでしょうがなかった.

スタート時刻より15分ぐらい遅れてライブハウスに到着し,大急ぎで中に入ると,ボーカルのサトちゃんがバーでフツーに話してました…っておい.

結局,定刻より1時間弱遅れてスタート.メンバー出てきて「あー待ちくたびれたっ」と思っていたら,1曲目から Led Zeppelin の Immigrant Song (移民の歌) のカバーで一気にハイテンションへ.トンさん,ドラムキマりすぎてるよ.

いつも通り演奏はバッチリだったし,今夜は選曲も最高.来年の2月にはニューアルバムのレコーディングに入るとのことで,2007年の楽しみが1つ増えました.


あーヤバいなー,サトちゃんのことかなり好きになってるなー
目を細めて顔をくちゃくちゃにしながら声を張り上げるブッサイクな彼女の顔が,やたら愛おしく感じられた夜でしたとさ.


2006年12月28日木曜日

M1グランプリと品川 祐の優しさ [memo]

クリスマス・イブの M1グランプリの余韻にいまだに浸っていて,気付くと録画した放送を見返しています.去年は新宿ルミネに準決勝を見に行こうとまでした (整理券もらえずに結局見れず) のに,今年は決勝の放送直前まで全然チェックしていなかった.

ふと目にとまった,品川の芸人目線の M1レビューがおもしろくて,また放送を見返してしまいます.
品川庄司 品川祐blog: M1 グランプリ

M1グランプリでは、「これはベタだけど客にうけるから入れとこう」と言うのがウケないですね。ツカミはとくに恐いから、とがってないけど、とにかくウケるものを入れたいんですよね。

でも、それがいつもほどウケない。
ウケないとベタさだけが浮き彫りになる。
そこで調子を崩すんですよね。
僕らがそうでした。今年もそういうコンビがいっぱいいました。


そして同時にこの記事を読んで,あーこいつすっげーいい奴なんだなーと.
品川庄司 品川祐blog: M1グランプリ POISON GIRL BAND

POISON GIRL BANDの事を「M1で素人に負けた奴」と叩いている人がいると噂で聞きました。
--中略--
当事者の彼らは、反論する事が格好悪くてと出来ないと思うので僕が勝手に代わりに反論させてもらいます。

なんか「書かずにはいられなかった」感が伝わってくる.


それにしても島田 紳助に「4分間の漫才のうち2分半くらいでチュートリアルが満票で優勝すると確信した.世代が違って良かった.7,8歳差やったら自分の将来に不安を感じなければいけなかった」とまで言わしめたチュートリアル.当分はこれで笑えそう.



2006年12月26日火曜日

ソウルの神様 - JB [diary]

12月25日,James Brown が亡くなりました.
死ぬことなんかない人だと思ってたのに.

ジャズからファンク,ロック,ブルース,ヒップホップにいたるまで,彼がミュージックシーンに与えた影響は計りしれない.

圧倒的なエネルギーに満ち溢れ,いつだって彼の音楽を聴けばくよくよした気分なんかふっとんだものだった.

2000年のサマーソニック,JB 見たさに富士急ハイランドまで行ったら,ペットボトルを投げた客に激怒してマイクをステージに叩きつけた彼の姿は今でも鮮明に覚えている.

ファンキーにシャウトする姿が世間の印象かもしれないが,


しっとり聴かせる君も大好きだった.


最初見た時はただのオバサンパーマだと思ってたのに,その歌声を聴いて心底シビれ,ステージに立つ姿を見て理屈なしにカッコいいと思ったよ.


こんな悲しい日だから,あえてこう言って吹き飛ばそうと思う.
"I Feel Good" とね…



これからは,クリスマスが来るたびに,君のことを思い出すんだろうね.

ジェームス・ブラウン
価格
あまなつShopあまなつで見る同じレイアウトで作成


2006年12月23日土曜日

ソフトウェアアーキテクチャ 番外編 - 本質的な検討を行う為に [arch]

今回は息抜きに「番外編」として,Paul Clements の興味深いエッセイを紹介しよう.

Reference:
Essays on Software Architecture - What's the Difference Between Architecture and Design?



「『アーキテクチャ』と『設計』の違いは?」というタイトルであり,これに対する

Architecture is design, but not all design is architectural.

という言葉は,Clements の名言だと思う.


私は業務でソフトウェアの上流設計を行っているが,ついつい細かすぎることまで考えてしまい,全体のアーキテクチャ設計という観点から外れた部分に陥ってしまうことが時折ある.今週も SEI のアーキテクトと話す機会があったが,議論の中でやはり彼が "Is this architectural? (それはアーキテクチャ的に関係ある話なのか?)" と指摘をする場面があった.

特に UI 設計やユーザビリティの検討は,ユーザーの目に触れるだけあって理解しやすくまた重要である為に議論が深くなりがちだが,実はそこをどう実現するかはシステム全体の分割方針にほとんど影響を及ぼさないケースが多いのではないだろうか.


では何が "architectural" なのだろうか?

Clements 曰く

if a property of an architectural element is not visible, or discernible, to any other architectural element, that element is not architectural.
--中略--
The reason the architect didn't make it part of the architecture is that its existence or nonexistence was not material to the overall goals of the architecture.

とのことである.
つまり,その要素が他の要素から認識可能ではなく,その相互作用が存在しない場合は,「細かすぎること」と言って良いのかもしれない.例えばデータの構造やそのアクセス方法は,システムが要求する機能や品質を満たすように設計することがまず重要であり,それがリストだろうが配列だろうが構わないということだ.


…などということをグダグダ言いつつも,結局は「ケースバイケース」である,と述べられている点が非常に興味深い.

The fact is, no scale or scope or measure or line divides what is architectural and what is not. One person's architecture may be another person's implementation and vice versa.
--中略--
If structure is important to achieve your system's goals, that structure is architectural.
--中略--
But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.


では,アーキテクトはどこまでシステムを分割すれば十分なのだろうか?
David Parnas (現在のオブジェクト指向の基となったモジュール設計の基本コンセプトを提唱した,ソフトウェアエンジニアリングのパイオニア) はかつて

a module is "small enough" when, in the face of a change, it would be just as easy to recode it as it would be to alter it.
(変更に直面した場合に,変更することが,新たにコードを書くことよりも簡単であれば十分詳細である)

と述べたことがある.

1つの目安として,
- システムの全体的な特性が定量的に示され,記述されている
- 実装担当者に対して,設計内容を共通に理解し,忠実にコードに落とすことができるレベルの制約が定義されている
- 設計に対する意思決定が明確に説明可能である
の3点を持って,「上流アーキテクチャ設計」から「実装レベルの詳細設計」に移れると考えれば良いのではないだろうか.


本エッセイはとてもおもしろいので,興味がある方はぜひ全文を読まれると良いだろう.


ソフトウェアアーキテクチャ その3 - 表現方法のコンセプト [arch]

今回はソフトウェアアーキテクチャの「表現方法」について.

Reference:
Documenting Software Architectures: Views and Beyond,
by Clements, et al. Addison-Wesley 2003

--> Part I

タイトル通り,アーキテクチャのドキュメント記述方法に関する本で,SEI の Product Line Systems Program の成果物の1つとして出版された.Product Line とは,SEI の代表的貢献として有名な CMM (Capability Maturity Model) に比べれば後発だが,最近注目されているソフトウェア開発の新しいアプローチの1つであり,本シリーズでもいずれ取り上げる予定.

本書には,Appendix に ECS Software のアーキテクチャ仕様書がそのまま例として載っており,私もアーキテクチャ仕様書を記述する際に大いに参考にしている.

但し,本書には関わっている著者が多く,全体的に若干繁雑な内容になっていることは否めない.最初から最後まで読了するというよりは,必要に応じて適切な内容を参照するカタログ代わりに利用すると良いかもしれない.

こちらがその和訳本.
多くの技術書がそうであるように,この和訳書も日本語が非常に奇怪だ.特に本書はその傾向が顕著で,例えば linked list (リンクリスト) が「結合した一覧表」などと訳されている.特に本書に関しては,極力オリジナルを読まれることを強くお勧めする.


ソフトウェアを表現する時に覚えておきたいのが,"View" "Viewtype" "Pattern" という概念だ.簡単に言ってしまうと,
- View は絵
- Viewtype はある視点からの絵
- Pattern は見慣れた絵
ということになる.

以下,詳細に説明してみよう.


前回 解説した定義によると,ソフトウェアアーキテクチャ は "structure(s)" ということだったが,"view" とはこの structure の描写である.無形で複雑なソフトウェアを捉えるには,様々な角度から表現される必要があり,この1つ1つが view である.一般的にアーキテクチャドキュメントは, view の集合 (とその相互作用の説明) で構成される.

例えば外科医,内科医,整形外科医は全て人体の構造 (structure) について異なる見方を持っているし,一部の組織に注目する眼科医もいれば,振る舞いについて観察する精神科医もいる.実体 (structure) における必要な個所を,様々な視点から可視化させるという点においては,ソフトウェアでも同じことである.

同じような例えを,本書は鳥の翼を用いて行っている.羽,骨格,血液,筋肉といった様々な view について,

これらの view のどれが翼の「アーキテクチャ」か.
いずれでもない.

これらの view のどれから翼の「アーキテクチャ」が持たらされるのか.
全てからである.

(ちなみにこのコンセプトから本書の表紙が鳥の翼になっている)


Viewtype とはシステムを捉える視点であり,具体的には "Module viewtype (静的観点)" "Component and Connector viewtype (動的観点)" "Allocation viewtype (物理的観点)" という3つに大きく分類される.基本的に view はこのどれかの viewtype にカテゴライズされる.

Module viewtype は,クラス,関数,インターフェースなどを扱い,責務を実装するコードの単位を示す.表現する関係は,is-part-of,depends-on,is-a のいずれかである.コードの青写真として使われ,モジュールは実装チームに割り当てられる.プロジェクトマネージメントや計画,プランニングを検討する際にも有効だ.

C&C viewtype は,プロセス,シーケンス,データフローなどを扱い,システムの動的な振る舞いを示す.通信メカニズムや,可用性,パフォーマンス,セキュリティ,信頼性などの分析に有効だ.

Allocation viewtype は,デバイス,ネットワーク,人員などを扱い,ソフトウェアが非ソフトウェアにどう割り当てられるかを示す.具体的に「非ソフトウェア」とは,主にハードウェアの場合が多いが,人やコスト,ソースコードのディレクトリツリーなども対象になる.


パフォーマンス性を可視化させたいなら C&C view,再利用性を可視化させたいなら Module view といった具合に,アーキテクトは適切な view を切り出して,ステークホルダーが興味を持つ structure を表現しなければならない.2つの view が混在していたり,視点が曖昧なままのドキュメントを多く見かけるが,これでは的確にソフトウェアを表現できないだろう.

また,「アーキテクチャドキュメント」というとレイヤ構造図や依存関係図ばかり見る気がするが,むしろソフトウェアアーキテクチャを本質的に表現するのは動的分析図だと個人的には思っている.


Pattern (style と呼ばれることもある) とは,要素と関係のタイプの使用法に対し,一連の制約をつけ,要素と関係のタイプを特殊化したものである.分かりやすく言うと,それぞれの viewtype でシステムをまたいで頻繁に登場するような表現を抽出し,一般化したものが pattern である (「デザインパターン」もこの1種と言える).

それぞれの viewtype における pattern の例を挙げておくと,

Module viewtype:
- Decomposition (分割)
- Uses (依存関係)
- Layered (レイヤ)
- Class, generalization (クラス,汎化)
など.

C&C viewtype:
- Data Flow (Pipe-filter など)
- Call-and-return (Client-server など)
- Interacting processes (Event system など)
- Data-oriented repository (Blackboard など)
- Hierarchical (Tiers など)
など.

Allocation viewtype:
- Deployment (配置)
- Implementation (ファイルシステム)
- Work Assignment (作業割り当て)
など.


ところで "view" の概念には他にも様々なコンセプトがある.Philippe Kruchten が1995年に提唱した 4+1 (Four Plus One) view model の考え方はあまりにも有名で,今日では RUP (Rational Unified Process) の概念的な基礎として定着している.
- Logical (論理) view
- Process (プロセス) view
- Development (配置) view
- Physical (物理) view
(+1 の Use case view は,上記4つの全てにまたがる)
http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/

この 4+1 view model と,本書の上記 view との対応は,第11章で解説されている.他にも11章には,UML や Siemens Four View などといった概念と本書の概念の対応が解説されているので,興味のある方は目を通すと良いかもしれない.


最後にもう1度,ソフトウェアを表現したものを見る時,見せる時は,「どの視点からソフトウェアを捉え,どの view を切り出しているか」を明確にすることが非常に重要であることを,繰り返し強調しておきたい.


2006年12月19日火曜日

サムスンの研究 [ce]

日本に根付くグローバル企業研究会
価格

サムスンを見て日本企業は何を学ぶべきか
快進撃を続けるサムスンについて内外からの多面的な解体書と言えます。観察軸も歴史的背景から技術面、人...
あまなつShopあまなつで見る同じレイアウトで作成

前回の「2015年のサムスン」に引き続き,サムスンのことをもっと知ってみようと手に取った本.内容的にはこちらの方がお勧めかもしれない.

本書は,サムスン内部の人間による基調講演などの証言や,専門家によるレポートを集めたもので,様々な角度からこの企業を見て取ることができる.

「LCD 戦略」や「TV 技術」など個人的に興味深かった内容はいくつもあったが,やはり圧巻は1993年から李 健熙会長が「家族以外は全て変えよう」とのメッセージと共に着手した経営改革だ.自ら世界中を飛び回り,68日間かけて1800人のサムスン幹部に新経営の内容を話したという.その内容は,A4用紙8500枚に記録されているそうだ.同じ年,携帯電話のあまりに高い不良率に激怒した彼は,15万台の在庫全てを回収し,その携帯電話の山に火をつけたという話も残されている (っていうかやりすぎだろ…).

全体を通してやはりつくづく感じるのは,この企業は非常に中長期的な戦略を持っているということである.目先のことばかりにとらわれて迷走しているメーカーとの差は開く一方だろう.


2006年12月17日日曜日

2015年のサムスン [ce]

成 和鏞
価格

サムスンブランドの未来
サムスンの過去と現在、そして未来の姿について書かれた一冊。次期総帥として内定している2005年現在...
あまなつShopあまなつで見る同じレイアウトで作成

日本では (特にエンドユーザーレベルでは) 極端に過小評価されている感があるが,サムスンというのは,とんでもない技術力と生産力を兼ね備え,確固たるブランド価値を築きあげつつある企業だ.ソニーや松下が血眼になって達成しようとしている営業利益率10%を軽々と超え,時価総額でソニーの2倍に達し,純利益でインテルを上回り,世界シェア1位の製品は20ほどもあると言われている.

例えばサムスンは,「その気になれば Apple とまともに対抗できる」数少ない家電メーカーの1つではないだろうか.国内の家電メーカーは,狭い日本でつまらない競い合いをしている場合ではなく,いかにこの巨人に立ち向かっていくか真剣に検討するべきなのかもしれない.


本書は,2015年という未来のサムスンについての予測が示されている.
そしてその未来図には,ソニーを吸収し,現会長・李 健熙の一人息子である李 在鎔が後継者になるとされている.

この激動の世の中で10年後を予想することはほぼ不可能に近く,それは筆者も認めているところだが,サムスンに対する綿密なリサーチを,あえて「10年後を予想すること」としてまとめあげたという点ではおもしろいアプローチかもしれない.

但し,本書は若い頃から経営の英才教育を受けてきた李 在鎔というプリンスが,同族経営企業の後継者になる過程においてサムスンを紐解くというもので,例えが良いかどうか分からないが「やくざ一家の世襲の舞台裏」についてのフィクションを読んでいるような気分に陥ることもあり,私にとってはむしろ「物語」として楽しんだ書籍だったように思う.


ところで日本でカリスマ経営者というと,例えば本田 宗一郎,井深 大,Steve Jobs,Bill Gates などは良く語られ,「李 健熙」という名前は始めて聞く方も多いだろうが,本書を読んでいて随所に感じられるのが李 健熙の絶大なカリスマ性だ.

いくつか興味深かった彼の言葉を紹介すると,

映画を見ていても,ただストーリーだけを把握するのではなく,監督がなぜあのようなアングルで撮ったのか,その場面での俳優の演技が適切なものだったのか,セリフはどうなのか,監督の意図は何なのだろうかということを考えながら見よう.

そうでなければ映画を見たことにはならない.

テレビ番組を5回以上見てもその裏面をのぞこうとしない人間は経営者とは言えない.

地下鉄に乗っていてもその運行原理が理解できなかったら,「乗る」のではなく「乗せられている」のだ

など,探究心に溢れる一面を見せている.

また多忙の身ながら毎月20冊前後の本を読了し,定期的に見る雑誌は50種類に至るという博学で,口数は少ないが話してみると,話題が豊富であるばかりでなく,奇想天外な事例や論理展開に驚かされるという.

例えばインタビューで「どんなタイプの社員が一番嫌いか」という問いに対して,自作の寓話を語って答えるという粋なところを見せている.

寓話をひとつ紹介しましょうか.
オオカミが出たといつも嘘をついていた羊飼いの少年の話を,皆さんご存じでしょう.ところがこの少年が最後にあの世に行きました.閻魔大王がなぜ嘘ばかりついていたのかと聞きました.そうしたら,少年は「退屈で,退屈でたまりませんでした.わかってください」と弁解しました.おまけに「僕の友人は,僕よりもはるかに嘘つきなのに,わまりの人たちは知らずにいます」とまで言ったのです.

つまり彼は「嘘」「弁解」「過ちを認めないこと」「人を陥れようとすること」を最も嫌い,「社員として成功しようと思ったら,この4種類のどのタイプに当てはまってもいけない」ということだ.

「無能力,無信条」タイプよりも「卑怯者」を嫌い,

全員仕事ができるわけではない.
うまく走れない人は歩け.

但し,ちゃんと走っている人に足を引っかけるようなことをしてはならない.

と強調したという.


2006年12月15日金曜日

デジタル・テレビの新たな挑戦 [ce]

先日,日経エレクトロニクスが主催する「デジタル・テレビの新たな挑戦」というセミナーに参加してきた.

プレゼンターは以下の通り:

- デジタル家電をネットにつなぐ - プラットフォームからの取組み
 松下電器: 戸倉 毅氏

- ネットワーク時代のテレビ用アプリケーションのアーキテクチャ
 UI Evolution: 中島 聡氏

- 「Yahoo! Everywhere構想」とデジタル・ホーム・エンジン
 Yahoo Japan: 坂東 浩之氏

- IPTVの時代のネットとデジタル家電
 Cisco Systems: 山崎 年正氏

- 互換DRMをうたうCoralとMarlinの役割とは
 Intertrust Technologies: Jack Lacy 氏

- Bringing innovation to Television
 Google: Vincent Dureau 氏


詳細はこちら.
http://techon.nikkeibp.co.jp/seminar/061212.html


Google の "Head of TV Technology" の Dureau 氏や,Life is beautiful で日本の alpha blogger としてお馴染の中島氏のプレゼンが聞けるということで,非常に楽しみにしていた.

丸1日のセッションで,細かく報告するにはボリュームが膨大なことと,内容にどこまで公共性があるか分からないので,以下は私の所感を中心に記述したいと思う.


まずプレゼンターを見ると,デジタルテレビの動向に敏感な日経エレが「ぜひ話を聞いてみたい」と集めた講演者の中で,家電メーカーが松下だけというのが象徴的だ.「ブロードバンドがテレビ/デジタル家電を変える」という副題ではあるものの,テレビのセミナーで Yahoo や Google, Cisco が呼ばれるところが今日の時代を表わしているのかもしれない (そういう意味では,確かに松下は Tナビや Viera LINK でネットワークに対する積極性,また HD-PLC のようなインフラに対するアプローチや UniPhier のようなプラットフォームに対する取り組みを見せている).

また複数の方が,まるで口裏を合わせたかのように「テレビでブラウザを見ることには意味が無い」との見解を示していたのも印象的で,いかに「テレビとしてのネットワークをユーザーに提供するか」という点が今後ポイントになってくるのだろう.

「家にある家電をネットワークで繋ぎ,サーバー側の UI をテレビで表示する」ということについて強調し,そのデモを行っていた方がいた.こうすることにより,デバイス毎に応じた操作が実現できる上に将来機器に対しても対応可能というものだが,実はこれは昔からある概念で,例えば IEEE1394 (i.LINK,もしくは FireWire) の AVC ではとっくに標準化されている (EIA-775 OSD 伝送・Command Path Through).当時はデバイス間の歩調も合わなかったが,ようやくこのような仕組みが一般家庭にも到来するのかもしれないと胸を踊らせたくなる一方で,「このようなセミナーでこれほどの方が,まだこんなことを説明しなくてはいけないのか」という歯痒さを感じた.


この手の講演では,その内容だけでなく講演者のプレゼンテクニックにも非常に注目する私であるが,中島さんの 「色に情報を運ばせるテクニック」 は確かに説得力があったし,彼や Dureau 氏はスライドにほとんど文字を書かず,あくまで「スピーカーに注目させる」というスタイルで聴衆を魅きつけていたように思う.

Lacy 氏は,スライドは文字だらけだったが,スピーキングに関してはピカ一だった.話し方にメリハリがあり,"ah..." とか"um..." などという言葉はほとんど聞かれなかった (日本語でも,話し始める前に「えー」とか「あのー」と言わずにスピーチすることは非常に難しい).

逆に口調にまったく起伏がなく,アイコンタクトもほとんど行わずに自分の PC を見ながらボソボソと話し,こちらが眠くなってしまうようなプレゼンターもいた.


Dureau 氏が Google という企業の特性について,こんなことを言っていたのが印象に残っている.

世間は Google がミステリーに包まれていると思い,どんなプランを練っているのかと語りたがる.

Google の最大のミステリーはミステリーが無いこと,
そして Google の最大のプランはプランが無いことなんですよ.

我々は,3ヶ月先のことは考えるけど,3年先のことは考えないんです.



話をデジタルテレビに戻そう.

私は「インターネットの世界が体験した (している) 変革が,家電の世界にもいずれ到来する」と何度かこの Blog で述べてきた.

ことテレビにおいては,必ず1家に1台,それもリビングの中心に存在し,またお年寄りから子供まで,男女問わず幅広く受け入れられなければいけない.ユーザーエクスペリエンスを追及するには,モノ作り冥利に尽きる,これほど魅力的な製品があるだろうか.

「放送と通信の融合」という言葉は既に使い古された感がある.そんな議論をしているぐらいだったら,できれば自らの手でテレビに変革を持たらしたいものだ.


2006年12月14日木曜日

ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]

今回は,「そもそもソフトウェアアーキテクチャって何?」という話.その定義を中心に見ていきたいと思う.

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

--> Chapter 2

価格

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

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


こちらがその和訳本.



ではまず「ソフトウェアアーキテクチャ」について,SEI (ソフトウェアに関する最も権威のある研究機関の1つ) の定義から見てみよう.
How Do You Define Software Architecture?

Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.

これによるとソフトウェアアーキテクチャは,間違えばプロジェクトを失敗に陥れかねない,設計の「意思決定」の集合である,としている.

またこの他にも,SEI は世の中に無数にある「ソフトウェアアーキテクチャの定義」の一覧を掲載している.
Published Software Architecture Definitions

しかしここで採用したいのは,冒頭で紹介した書籍による定義である.

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

ソフトウェアアーキテクチャは,システムの "structure or structures" (構造) であり,それは "elements" (要素),"the externally-visible properties of those elements" (可視化された要素の特性),"the relationships among them" (要素間の関係) から成り立つとしている.

順番に見ていこう.

Structure(s) (構造) とはソフトウェアの実体であり,コード,プロセス,スレッドなど,様々な形態が存在するだろう.

Elements (要素) はシステムを構成する部品である.例えば静的観点で見ればクラスやファイル,動的観点で見ればデータフローやコントロール,物理的観点で見ればプロセッサやネットワークなどが挙げられる.

"The externally visible properties of those elements" ということは,まず要素が properties,つまり要求されているパフォーマンスや変更容易性などの特性を持つことを示している.要素に特性を割り当てるというのは,設計の真髄だ.さらにアーキテクチャはそれを可視化させるものであるということだ.

"The relationships among them" ということは,要素はインターフェースをもって互いに関係を持つことを示している.


加えてこの定義から読み取りたいことがいくつかある.

まず,この定義は相互作用に関係しない要素の情報を明確に除外している.つまりアーキテクチャは,システムの最も重要な抽象概念であり,使い方,使われ方,関係の仕方,あるいは相互作用に影響を与えない詳細部分を省略したものである.

さらにこの定義は,システムが複数の構造で構成されること,そしてソフトウェアを備えた全ての計算システムに,ソフトウェアアーキテクチャが存在することを意味している.システムがそれ自身で単一の要素になるような単純なケースでもやはりアーキテクチャであり,全てのドキュメントやソースコードが消え去り,実行バイナリコードだけが残ったとしてもそこにはアーキテクチャが存在する.つまりアーキテクチャは,その記述や定義とは独立して存在できるのである.

そして別の要素の視点から,振る舞いが観測可能,あるいは識別可能である限り,各要素の振る舞いはアーキテクチャの一部であることを意味している.このような振る舞いは,要素が他の要素と相互作用することを可能にするので,明らかにアーキテクチャの一部である.

またこの定義は,システムのアーキテクチャが良いか悪いかということには何も触れていないところにも注目したい.


なぜソフトウェアアーキテクチャがそこまで重要なのだろうか? それはソフトウェアアーキテクチャが開発において重要な役割りを持つからだ.本書は,以下の点で作用するとしている.

1. Communication among stakeholders
(利害関係者とのコミュニケーション)
ソフトウェアアーキテクチャは,利害関係者との相互理解,交渉,コンセンサス,コミュニケーション手段として利用できる.アーキテクチャの分析は,このコミュニケーションのレベルに依存し,また同時にそのレベルを高めることもできる.

2. Early design decisions
(初期の設計方針確立)
ソフトウェアアーキテクチャは,システムに関する最も初期の設計方針を明示したものである.

具体的には,アーキテクチャは,
- 実装上の制約を定義する
- 組織構造を決定する
- システムの品質特性を促進もしくは抑制する
- システムの品質を予見する
- 変更の考察及び管理を容易にする
- 段階的なプロトタイピングを促進する
- より正確なコスト・スケジュール見積りを可能にする

3. Transferable abstraction of a system
(システムの転用可能な抽象概念)
ソフトウェアアーキテクチャは,システムがどのような構造になっていて,その要素がどのように連携するのかを表現する,比較的小さな,知的に理解可能なモデルで構成される.

このモデルはシステム間で転用可能であり,特に同様の品質特性と機能要求を示す他のシステムに適用できるので,大規模な再利用を促進する.

具体的には,
- プロダクトラインは共通のアーキテクチャを共有する
- システムを,外部で開発された大規模な要素を使って構築可能とする
- 設計の選択肢を制限することができる
- テンプレートに基く開発を可能にする
- トレーニングの基礎として活用できる


1の,「アーキテクチャの分析は,このコミュニケーションのレベルに依存し,また同時にそのレベルを高めることもできる」との本書の記述に驚いた方もいるだろうが,実際に企業で開発を行っているとこれは事実だと感じるし,ソフトウェアアーキテクチャの専門書にも組織論やマネージメント,ステークホルダーとの関係の話が多く登場する.これこそが,ソフトウェアが「工学」になりきれていない証拠なのかもしれない.


ついでに「アーキテクトの役割」についても触れておこう.SEI はこのように定義している.
What are the Duties, Skills, etc. of a Chief Software Architect?
要約すると,アーキテクトの役割は
- システムの明確化,要求の実現,上流設計
- 担当者の技術支援
- 設計と文書化の引率,アーキテクチャ評価
- マネージメントに対する報告
- テクニカルリーダーシップ
などであり,それに伴いアーキテクトに求められる資質は,
- 最新技術,動向の理解
- 詳細を理解しつつも,全体像を見る眼力
- 経験
- 情報科学,OS,ハード等,多岐に渡る知識
- 設計と品質の,トレードオフまで含めた理解
- 技術面,ビジネス面におけるビジョン,先見性
- コミュニケーションスキル (writing + speaking)
- コーチングスキル
などということだ.


今回述べたかったことは以上だが,最後に今回の本書第2章の範囲の中で,もう2点ほどピックアップしておこう.

1つは「建築とソフトウェアシステムの比喩はすぐに破綻する」と記述されている点について.「アーキテクチャ」の本来の意味は「建築」であり,一般的にもソフトウェアアーキテクチャと建物のアーキテクチャは良く比較される.確かに実現しようとしている成果物のキーコンセプトを表すものであるという点,要求を具現化することを促進し利害関係者とのコミュニケーションツールとして利用できる点,小さい部品からより大きい部品を作り出しその集合でシステムを構築する点などは類似しているが,ソフトウェアはそもそも無形であること,建築には時として「芸術」という動機が伴うこと,建築設計に動的概念が無いこと,長い歴史に基き建築の方が工学として成熟しておりずっと標準化が進んでいること,そして完成品に対するリファクタリングの概念や部品交換及び複製の容易さ,さらに評価方法が致命的に違うことなどを忘れてはならない.

もう1つは "System Architecture versus Software Architecture" という Rick Kazman のコラムの補足.「エンタープライズアーキテクチャ」(ビジネス構造もしくはビジネス構造間の結合を描写し,企業の実体間における情報の流れやアクティビティを説明する) や,「システムアーキテクチャ」(完全なシステムの要素もしくは要素間の相互作用,及びそれらのシステムゴールにおける貢献を描写し,ハードウェアとソフトウェアの要素を定義する.但しそれらの基礎構造まで言及することはない) など,「アーキテクチャ」という言葉は開発における様々な分野に使われることがある.これら各アーキテクチャの分離や範囲,包含関係は,対象とするドメインやスコープ,視点などによって異なることを覚えておきたい.


2006年12月12日火曜日

原了郭の黒七味 [diary]

DSC00502
私が無類の「辛いもの好き」ということで,わざわざ同僚が会社の食堂用に持ってきてくれました.

私は始めて聞いたんだけど,「京都,原了郭の黒七味」と言えば結構有名なようだ.関東では,新宿の伊勢丹で買える模様.

うーん,案外洋食にも合うかもな.


2006年12月10日日曜日

君になら…なにができる? [diary]

ぼくには君の目を醒ますことはできない。
君になら、君の目を醒ますことができるんだ。

ぼくには君の傷を治せない。
君になら、君の傷を治せるんだ。

-- John Lennon


一昨日,12月8日,John Lennon の命日であり,太平洋戦争の開戦日.

この日だけ平和を祈ってどうする.


2006年12月8日金曜日

コミュニケーションにおいて,してはいけない10の禁止事項 [memo]

昨日のエントリーでは,John Rosemond の「家族力」という本について親の立場でレビューを書いたが,子育てについてのこの本の中で一際印象に残っているのが「しつけとはリーダーシップであり,しつけで一番重要なこと - つまりよいリーダーになるためにもっとも重要な特性 - は,コミュニケーション能力である」と言及している点だった.

Peace Pipe: 家族力 - 「いい親」が子どもをダメにする [memo]

「しつけはリーダーシップ」という言葉に,非常に感銘を受けた.
私は会社ではリーダー的立場にあり,それなりにリーダーシップやコーチング手法を体得しようとしてきた.またこの Blog でも,「エンジニアにとって,技術力よりさらに重要なのはコミュニケーション能力である」と何度も述べてきた.それが,子育てでも同じだと著者は言うのだ.
--中略--
大部分の親たちが使う「ミルクトースト・スピーチ」ではなく,優れたリーダーたちが使う「アルファ・スピーチ」を使うべきだとしている.これに関する詳細は,別途「リーダーシップ」という観点で,次回の記事にしたいと思う.


そこで本エントリーでは,この「アルファ・スピーチ」について内容を紹介してみたい.

「ミルクトースト・スピーチ」が,いつも言いよどみ,口ごもり,ぶつぶつ言い,意気地の無さをさらすものであるのに対して,優れたリーダーたちが使う「アルファ・スピーチ」は直感的で簡潔な表現法であり,いいわけや脅し,約束などの手段は使わないものだとしている.

- 直接的とは,要点を押さえ想像に任せる部分をなくすこと
- 簡潔とは,5つの言葉で伝えられることに20もの言葉を使わないこと

これを踏まえて Rosemond は,コミュニケーションにおける「10の禁止事項」を挙げている.

原文は「子どもとコミュニケーションするときに,してはいけない10の禁止事項」であり,以下の例文も原文のまま子供に対する言い回しを引用したが,社会生活に置き換えてみても (もちろんそのまま「子供に対する接し方」と捉えても) 非常に参考になるのではないだろうか.

1. 質問の形で指示を出す
(そうすると,ほかに選択肢がないのに,選択肢があるように錯覚させてしまう)
× 「そろそろ寝る時間だからおもちゃを片づけたら?」
○ 「もう寝る時間よ.おもちゃを片づけて部屋をきれいにしなさい」

2. 要望を具体的な言葉を使わずに告げる
(あいまいな表現は,受け止め方次第で変わってしまう)
× 「お店のなかではいい子でいてね」
○ 「お店に入ったら,お母さんの隣を歩きなさい.そしてお母さんがいいとい言わない限り,品物にさわってはだめよ」

3. 一度にたくさんの指示を出す
× 「今日は,部屋の掃除とゴミ出し,犬のエサやり,子ども部屋の片づけ,そしてこの箱を屋根裏に運ぶのを手伝ってちょうだい」
○ 「今日まずやってほしいことは,あなたの部屋の掃除よ.それが終わったら教えて.次の仕事を言うから」

4. 「いっしょに〜しよう」という言い方をする
(これも受け身的で権威のないコミュニケーションの1つ)
× 「いっしょにテーブル・セッティングをしましょう.いいわね?」
○ 「さあ,テーブル・セッティングの時間よ」

5. 指示のあとに理由や説明をつけくわえる
(最後に理由をつけくわえると,関心が指示そのものよりも理由に向かいやすく,口ごたえしやすくなる)
× 「もうブランコは終わりよ.家に帰る時間だからね」
○ 「もう家に帰る時間よ.ブランコを降りて,行きましょう」

6. 言いくるめる形で指示を出す
× 「いいことがあるのよ! 今日の晩ご飯はごちそうなんだから! さあ,お友だちにさよなら言って,どんなごちそうか見に帰りましょう」
○ 「夕飯の時間よ.お友だちにさよなら言って家に入りなさい」

7. 期限を切らずに指示を出す
× 「今日時間があったら芝刈りをしてちょうだい」
○ 「今日芝刈りをしてちょうだい.6時に帰ってくるから,それまでにすませておいてね」

8. 要望の形で指示を出す
× 「口を開けたまま食べ物をかむのはやめてほしいんだけど」
○ 「口を開けたまま食べものをかむのはやめなさい」

9. イライラしながら指示を出す
× 「口を開けたまま食べ物をかむなって何度言えばわかるの?」
○ 「口を開けたまま食べものをかむのはやめなさい」

10. 脅しの形で指示を出す
× 「口を開けたまま食べ物をかむのはやめなさい.できないなら唇を縫いつけてストローで食べさせるわよ」
○ 「口を開けたまま食べものをかむのはやめなさい」


どうだろう.例えば「休日出勤をちらつかせて納期を守らせようとするリーダー」や,「担当者に指示を出すことを遠慮しているリーダー」など,あなたのまわりにはいないだろうか?

「言葉」は非常に大切だ.
明確な指示をすることの重要性は,子供に対しても,自分の部下やチームメンバーに対しても,本質的には同じだと感じた次第である (もちろんメンバーを子供扱いするということではなく,相手によって尊重するべき人間性のレベルは様々だとは思うが).


価格
あまなつShopあまなつで見る同じレイアウトで作成



2006年12月7日木曜日

家族力 - 「いい親」が子どもをダメにする [memo]

価格
あまなつShopあまなつで見る同じレイアウトで作成


良書に出会った.
John Rosemond (10冊を超える子育てに関する執筆が全てベストセラーになっている家族心理学者) による本書は,5つの「子育ての基本原則」から構成されている.

基本原則その1: 子ども第一ではなく家族第一
- 何が一番かをはっきりさせる

基本原則その2: しつけに必要なのは,罰ではなくコミュニケーション
- 信頼関係を結ぶことではなくリーダーシップ

基本原則その3: 子育てとは人を大切にする心を育てること
- 自尊心を育てることではない

基本原則その4: 大切なのは礼儀を教えること
- 技術を習得させることではない

基本原則その5: 大切なのは責任感を育てること
- よい成績を取らせることではない


読んでみて心にしみるほど実感したのは,子育てとは,子供を育てることではなく,大人を育てること (大人に育てあげること) である,ということ.

共感した内容は非常に多かったのだが,その中でも特に印象が強かった部分をいくつか紹介してみようと思う.


まず著者は,子育ては夫婦の強い絆があってこそ上手くいくもので,夫と妻の繋りは親子の繋りよりも強くなければならないと説く.

子育ての専門家たちは,家族の本当の意味をほとんど理解していません.家族とは,(理想的には) 強い絆で結ばれた夫婦を中心に形成される社会的な単位です.

現代の子どもたちは,夫と妻という関係を放棄し,父親と母親になりきって子どもに尽くす両親のおかげで,結婚とは何かということを学ぶ機会を失っています.

子供に関心を持ち,子供と深く関わり,子供の為に何かしてやる親ほど良い親だというのは,現代風の間違った考え方なのだ,と.


子どもはつねに,親が選んだ道よりも,自分で選んだ道で,より大きな成功をとげるのです.

この一言は胸に響いた.
私の親は比較的子に期待をかけるタイプだったが,私が子供の頃から思っていたこと,そして親になって改めて自分に言い聞かせることは,親に子の人生を決める権利なんて,これっぽっちも無いということだ.

例え親の期待に沿えない道を選んだとして,それが親を悲しませる結果になったとしても,最終的には子が自分で納得できる幸せを見つけることが親にとっても一番幸せなはずなのだ (それを親に死ぬまで分かってもらえないとしても).少なくとも私は,これまでに何度も経験してきた (そしておそらくこれからも経験するであろう)「親の期待に沿えない道」を選択した時に,半ば無理矢理自分にこう言い聞かせてきたように思う.

ちなみに著者は,この話の流れで「子供たちは放課後の稽古ごとや塾通いを必要としていない」とした上で,習いごとは週に1度までとして夕食は毎晩家族全員で食べること,夏休み中の習いごとは禁止すること,と提案している.家庭内にくつろいだ雰囲気があればあるほど育児上の問題は起こりにくい,子育てのトラブルの大部分はストレスから生じる,とのことだ.

そして「保育所はセカンド・ベスト」と述べ,「家庭での育児は保育所での育児に勝っている」としている.新鮮だったのは,「金銭的なことは,夫婦で共働きをする理由にならない」と言及していたことだ.共働きをしても,世帯にかかる課税率の上昇,保育費,医療費,被服費,交通費,そして食費の増加 (共働きの家庭では外食の機会が多くなる) により,実は妻の収入のほとんどが消えているという調査結果が出ているそうだ.


よい母親は支配的である.

子どもが自分でトイレに行けるようになり,道路に出てはいけないことがわかるようになると,昔の母親たちは,できるだけ子どもに手を貸さないようにしたものです.

子育てがうまくいかないのは,お子さんがあなたを恐れていないからです.

では父親は?

子育てに積極的にかかわる父親をもつ子どもたちは,より自信にあふれ,積極的で自律的な傾向があります.

家庭は子供が最初に経験する社会であり,親がどのような社会を築くかは非常に重要だ.著者は,親子の間では「けじめ」が非常に大切だとして,例えば「親と子が1つのベッドで寝ることは害だ」と言っている.また,物で釣るような言い方 (「これを残さず食べたらアイスクリームをあげるよ」など) とか,脅すような言い方 (「片付けないとこのおもちゃ捨ててしまうよ」など) もするべきではない,と.この辺りは非常に耳が痛い.


さらにしつけに対する著者の考えは,目から鱗が落ちるようだった.

しつけのうまい親は,子どもを思いどおりにしようとはしません.そんなことはできないと知っているからです.彼らがコントロールしようとするのは,自分たちにできることだけ.つまり,子どもとの関係だけコントロールしようとするのです.

しつけのテクニックなんていうものは存在しないということ.

現代の親たちは,しつけは技術であると考えており,実験用のラットを水や飲み物で誘い,仕切り板を押し開ける動作を教えこむのと同じだと考えています.

そう,子供は実験用のラットでもなければ,犬や猫でもないのだ.子供をコントロールしようとしてはいけないし (それは私が親に一番されたくなかったことではないか),そもそもそんなことはできないし,またする権利もない.

さらに極めつけは,この部分.

しつけとはリーダーシップであり,しつけで一番重要なこと - つまりよいリーダーになるためにもっとも重要な特性 - は,コミュニケーション能力です.

今の時代に見られるもう1つの不幸は,子どもの友だちになろうとする親が増えていることです.子育てはリーダーシップだとわかっている親なら,リーダーは自分が率いる者と友達になれないことぐらいは知っているはずです.友情とリーダーシップは両立しないからです.

「しつけはリーダーシップ」という言葉に,非常に感銘を受けた.
私は会社ではリーダー的立場にあり,それなりにリーダーシップやコーチング手法を体得しようとしてきた.またこの Blog でも,「エンジニアにとって,技術力よりさらに重要なのはコミュニケーション能力である」と何度も述べてきた.それが,子育てでも同じだと著者は言うのだ.

そしてコミュニケーションのやり方として,

「さあ,おもちゃを片づけましょう.いいわね?」
このような卑屈な態度は,子どもに「指示を出している」のではなく,子どもに「頼んでいる」のです.

大部分の親たちが使う「ミルクトースト・スピーチ」ではなく,優れたリーダーたちが使う「アルファ・スピーチ」を使うべきだとしている.これに関する詳細は,別途「リーダーシップ」という観点で,次回の記事にしたいと思う.


「コミュニケーションが大切」とする著者が,それでも子供に罰を与える必要がある時は,

約束を破った子どもに2度と同じことをさせたくないのなら,子どもが約束を破ったときに,厳しすぎるほどの罰を与えるべきです.子どもを手の甲でおそるおそるたたくタイプの親は,ずっと手の甲でたたき続けることになります.

とのこと.

念の為に補足しておくと,もちろんこれは子供を虐待するということではない.例えば決められた範囲を越えて自転車を乗った子供に対して,自転車を1日取りあげるのではなく,最低1ヶ月,つまり子供が十分すぎるほど不自由さを味わう必要があるということだ.



私は,親になって本当に良かったと思っている.子供を育てている以上に,私自身が子供に育てられている感覚を毎日感じているからだ.親は子供と一緒に成長できるものだということを,身を持って実感している.だが,著者に言わせればそんなものは甘い考えなのかもしれない.冒頭でも述べたこと,忘れないように,もう1度胸に刻んでおこう.子育てとは,大人を育てるものだということを.今日や明日を考えてするものではなく,20年,25年先を見据えて行うものだということを.

この本は,親としていろいろ考えさせられただけではなく,自分の親が私に対して行った子育てについても深く考える機会となった.

そういう意味では,子育てを経験している親,これから親になろうとしている方にはもとより,まだ親元を離れていない若者にもぜひ勧めたい1冊である.