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冊である.


2006年12月6日水曜日

戸越銀座 ら〜麺 きむら [diary]

もともとは「きむら家 (@家)」という,いわゆる家系の店だったが,去年の9月に「ら〜麺 きむら」としてリニューアルオープンした.

リニューアルしてから,きむら家時代の限定メニューだった魚介スープのラーメンをメインに据えた模様.というか,そっちをメインにしたから家系の屋号を外したのかな?

ちなみに家系の定義はいろいろあるが,私は独特のコクがある醤油豚骨とストレート太麺で,「○○家」という名前であれば家系と呼んでいる.
家系ラーメン - Wikipedia


濃厚でコクのあるスープに太麺がよくマッチする.そしてここはとにかくチャーシューが絶品なんです.

これがその看板メニューの「魚ら〜めん」
夜限定のかぶりつき炙りとろチャーシュー (これヤバイ) をトッピングしています.
DSC00495.JPG


昔の家系醤油豚骨も「豚ら〜めん」として残ってます.

場所は中原街道沿い,星薬科大学前.以前紹介した えにし から歩いてすぐなので,遠方の方はお腹を空かせて2軒はしごするのもいいかも?


2006年12月4日月曜日

ソフトウェアアーキテクチャ その1 - ソフトウェアの現状 [arch]

ここ最近,ソフトウェアアーキテクチャについて深く携わる機会がある.経緯や素性についてあまり詳しいことは書けないが,内容については Blog で公開しても良いとの許可を関係者に頂いたので,これから何回かに渡り情報を共有したいと思う.

Blog に書くからには定期的に更新していきたいと思うし,ご意見やご指摘等,幅広くコメントを頂けるとありがたい.


具体的な内容は次回以降に譲るとして,まずは少し概念的なところから始めてみよう.

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

--> Chapter 1

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

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

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



本書は,ソフトウェアにおいて少なくとも3つのデザインレベルが定義できるとしている.

1. アーキテクチャ
焦点はシステム全体の相互作用であり,扱う要素はソフトウェアモジュール.

2. ソースコード
焦点はアルゴリズムやデータ構造であり,扱う要素はプログラミング言語の基本構成物 (数字,キャラクタ,ポインタ等).

3. 実行コード (executable)
焦点はメモリマップ,データレイアウト,コールスタック,レジスタ配置等であり,扱う要素はハードウェアがサポートするビットパターン.

この「ソフトウェアアーキテクチャ」とは急に湧いて出てきたものではない,むしろ先人達が,より良いソフトウェアの解釈方法,及びより大規模かつ複雑なソフトウェアの構築方法を探求した結果の,長年に渡る自然的な設計概念の進化である.


ではよく「ソフトウェアエンジニア」とか「ソフトウェア工学 」という言葉を聞くが,そもそも「エンジニアリング (工学)」とは何だろうか?

本書では長々と議論がされているが,私なりに一言で要約してしまうと「専門家や職人がいなくても,一般人を問題解決可能とさせる知識または手法」といった所だろうか.

さらに本書ではエンジニアリングの進化の過程をモデル化しており,"Craft" "Commercial" "Professional Engineering" という3つのレベルを定義すると共に (つまりエンジニアリングは2段階の進化を経て成熟する),その最終形の Professional Engineering には

- Educated professional
- Analysis and theory
- Progress relies on science
- Educated professional class
- Enabling new applications through analysis
- Market segmentation by product variety

が存在する,としている.

ならばソフトウェアに目を向けた時,「ソフトウェアエンジニアリング」は "Professional Engineering" の域に達しているだろうか? 10年前に書かれた本書の中の答えは「否」であり,コンパイラ,アルゴリズムややデータ構造など,ソフトウェアのほんの一部分だけが Professional Engineering をかすめているとしている.

時は経ち2006年の今日,確かにデザイン言語 (UML 等) やデザインツール (Rational Rose 等) が確立され,多くの設計手法 (MDA,AOP 等) も提唱されている.だが実際の開発現場ではデスマーチが繰り返され,ソフトウェアを定義するドキュメントも読み手によって捉え方が異なってしまうような「線と箱」で書かれ,勘に頼った設計を行っていないだろうか.

今日でも,ソフトウェア開発コストの6割以上はメンテナンスに使われ,開発者の時間の過半数が既存システムのソースコードやドキュメントの理解に費やされるという統計が出ている.この現状を考えると,まだまだソフトウェアが工学として発展する余地はありそうだ.システムが小さかった頃は設計を介在させない「力ずく」のプログラミングも通用しただろうが,ソフトウェアが巨大になった今日ではそうはいかない.

それでは要件を正しく分析し,重要なシステム特性を実現し,コストを抑え,ソフトウェアに論理性を持たらすにはどうすれば良いだろうか?

次回から少しずつ紐解いていきたいと思う.

今回は,本書のこの一文を引用して終わりとしよう ("that" とは "Professional Engineering" を指している).

Though we have not yet matured to that state, it is an achievable goal.


2006年12月1日金曜日

It's Christmas Time Again - Stax Soul Christmas [music]

さて,いよいよ12月.

日本でクリスマスというと12月24日,25日の2日間だけのように思うが,アメリカでは Thanksgiving が終わればもうクリスマス.12月は毎日がクリスマスなのだ.

毎年12月はずっとこのアルバムを聴いている.このエントリー でも取りあげた Stax レーベルのミュージシャンが奏でるクリスマスソング集.

もちろん私にとっては究極のオムニバス盤だが,歯が浮くようなチャラチャラしたクリスマスソングに飽き飽きのあなたにぜひオススメの1枚.