Changeling [reflection]
I'm a Changeling
See me change
I'm a Changeling
See me change
-- Changeling / Jim Morrison
If it's fine rain or shine I don't mind I'll take it anyway
I'm a Changeling
See me change
I'm a Changeling
See me change
-- Changeling / Jim Morrison
今日も,SEI の某アーキテクトと話す機会があったのだが,本題の話が終わった後のフリーディスカッションで「Product Line 開発を成功させる為には」という話題になり,その中で彼が放った一言が印象的だったので紹介しようと思う.
そもそも Product Line は,技術的要素よりも,組織としての取り組みや方針,マインドセットが重要となる.分かってはいても,どうしても目先のことの重要度が上がってしまうのが実状だ.
彼曰く, 組織に Product Line を適用することは,言わば "special kind of modifiablity" を取り入れるようなものであり, それには「コスト」の概念が非常に重要だと.
つまり,とびっきり素晴らしいアーキテクトであるだけではなく, とびっきり素晴らしいビジネスパーソンでなければならない.なぜそれが cost effective かを,説明できなければいけないからだ.
そして,マネージメントを説得するには,経済的概念で説明するのが良い.そもそもマネージメントに「気付いて」もらう必要があるが,彼等は「数」と「金」の価値観で判断する.
彼等が下した判断と,提案しようとしている Product Line の間で,economic impact と market impact を比較してケーススタディを行い,具体的に「長期的にはこれだけ早く安くなる」ということを示すのが一番効果的である.
もしこれでも理解されないなら,それ以上説得しても無駄だろうし,もしかしたらマネージメントの判断が正しいのかもしれない.
…と,そのような話が続いた後,ふと誰かの「的確な見積りをするのは難しいケースもあるが,説得する為にでっちあげることもアリだと思うか?」という問いに対して,彼は即座に NO と言い,こう言った.
Economic study もできないなら Product Line には関わらない方がいい.
自分の組織がやろうとしていること,あるいは自分が提案しようとしていることの経済価値ぐらいは知っておくべきだ.
うーん,御意…
たのむよ明日の朝
モーニング・コールをよろしく
君の声で目が覚めて行く
ねぼけた事はもうしないさ
モーニング・コールをよろしく
モーニング・コールをよろしく
モーニング・コールをよろしく
-- モーニング・コールを よろしく / RC サクセション
ちょっとメモ.
基本的に HDD の中身は weekly でバックアップを取っている私だが,毎回決められた同じ範囲をバックアップするなら rsync よりも unison の方が優れていると思う.これは,rsync が起動毎に対象ファイルを解釈するのに対し,unison はファイルのカタログ DB を作るので,2回目から非常に速くなるからだ.
さらに,rsync が「ミラーリング」するのに対し,unison は「シンクロナイズ」するので,2台のマシン間でファイル毎に「どちらからどちらに上書きするべきか」を判断してくれる (相互同期ができる).例えば会社のデスクトップ PC とノート PC 間でファイルを同期するのにも非常に重宝している.
unison の詳細や使い方などは他に譲るとして,Mac に数多くある「隠しファイル」を unison で除外するには,
ignore = Name ._* ignore = Name .DS_Store ignore = Name .Trash ignore = Name .Spotlight-* ignore = Name .Trashes ignore = Name .hidden ignore = Name .hotfiles.btree ignore = Name .vol ignore = Name .FBCIndex ignore = Name .FBCLockFolder ignore = Name .CFUserTextEncoding ignore = Name .localized
を "filelist_ignore-osx" とでも保存して,設定ファイル (prf) から "include filelist_ignore-osx" すれば良い.
sync 先に Mac の隠しファイルが紛れ込んでいないかどうかは
$ find . \( -name "._*" -or -name ".DS_Store" -or -name ".Trash" -or -name ".Spotlight-*" -or -name ".Trashes" -or -name ".hidden" -or -name ".hotfiles.btree" -or -name ".vol" -or -name ".FBCIndex" -or -name ".FBCLockFolder" -or -name ".CFUserTextEncoding" -or -name ".localized" \) -print
して探す.
参考にしたのはこちら.
Mac OS X Hidden Files & Directories
愛読 Blog の1つ,Hitchhiker's Guide より.
What is Software Architecture
「ソフトウェアアーキテクチャの定義」というものは世の中に無数にあり,私の開発現場でも度々議論になるし,Peace Pipe でも "Software Architecture in Practice" における定義を紹介したことがある.
Peace Pipe: ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]
それでここでは,Michael Stal 曰く
Software architecture denotes the set of artifacts and practices required to build a software system so that it achieves its implicit and explicit qualities.
It includes the systematic partitioning of the software system into appropriate subsystems and relationships as well as the guiding principles used for that purpose. The partitioning of responsibilities and interactions need to be modelled using an interrelated set of viewpoints to address the functional and non-functional qualities.
としている.
"systematic" という単語をあえて使っているのは,アドホックなものは「ソフトウェアアーキテクチャ」とは認めていないからなのだとか.その上で,ソフトウェアアーキテクチャは "both an entity and an act" としている.
さらにこのエントリーに対して投稿された「システマティックだろうがアドホックだろうが,ソフトウェアアーキテクチャとはシステムの属性である」「アーキテクトの仕事は,アーキテクチャが意図通りであり,正しい品質特性のバランスが取られていることを保証することである」というコメントも大変興味深い.
このコメントした人の
Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attribute requirements. The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).
という定義にはとても共感を覚えるし,この後の
If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.
というのは名言だと思う.
…で,前置きがずいぶん長くなったが,本来紹介したかったのはこのエントリーで Stal が言っている
You may also define it as follows:
Software architecture is taken into consideration only when it hurts.
というジョークに苦笑いしました,という話.
じゃあ言わせてもらうけど,例えばコネくりまわしたギターソロと,オープン G の開放では,どちらがカッコいいと思う?
化粧を塗りたくった女と,そうじゃない女では,どちらが可愛いと思う?
I see the storm coming
and I know that His hand is in it
If He has a place and a part for me
I believe I am ready
-- John F. Kennedy
もし神が,その時と場所を私に用意するなら,
私にはその準備ができていると,
そう信じることにしよう.
It was raining from the first
And I was dying there of thirst
So I came in here
And your long-time curse hurts
But what's worse
Is this pain in here
I can't stay in here
Ain't it clear that-
I just can't fit
Yes I believe it's time for us to quit
When we meet again
Introduced as friends
Please don't let on that you knew me when
I was hungry and it was your world
Ah, you fake just like a woman, yes you do
You make love just like a woman, yes you do
Then you ache just like a woman
But you break just like a little girl
-- Just Like a Woman / Bob Dylan
先週の San Francisco に引き続き,今週はドイツ出張でした.
週末に直接アメリカから移動した為,ドイツ入りしてから1日半ほど自由になる時間があったので,鉄道を使って少し足をのばしてみました.
フランクフルト
ヘッヒンゲン (ホーエンツォレルン城)
ミュンヘン
シュツットガルト
そして思いっきりベタですが,ドイツと言えばビールとソーセージ.
訪れた各々の都市はどこも素晴らしかったですが,鉄道で移動している最中に見た景色の美しさが忘れられません.2時間程度の移動なら,窓の外を眺めていればあっという間です.そんな景色に心を奪われながら,大好きな音楽を聴いているのが,最高の贅沢でした.
ちなみにドイツでのヘビーローテーションは,The Rolling Stones の隠れた名盤,Between the Buttons でした.Brian Jones の優しさとナイーブな一面が出たアルバムだと思います.改めて聴くと,Connection めちゃくちゃカッコいい.
どこに行っても街の人が優しかったのが印象的です.なにか困っていると (困っていなくても),英語で声をかけてくれる人が何人もいました.「南ドイツ」といっても緯度的には北海道より北に位置し,特に夜は厳しい寒さでしたが,人の暖かさばかりが心に残っています.
それにしても私の方向オンチぶりは健在です.街では,地図を見ながら歩くのが煩わしかったので,大体の方角だけ覚えてしばらく歩いてから地図で位置を確認する…みたいに探索していたのですが,地図を見る度にびっくりするようなところにいました.ある意味これだけ毎回確実にハズす (つまりハズさない) のは,我ながらすごいと思います.
最近こんなエントリーが続いていますが,異国の地で働いていると,普段の環境に対していろいろ考えさせられるものがあるので,もう1つだけ.
前エントリー は,長い時間働くことを悪としたいわけではなく,要は「長い時間働いてもいいけど結果は出せよ」ということが言いたかったりします.
例えばプロスポーツ選手が,調子が悪い時に土日を返上して練習したとして,彼等に「休日出勤している」という意識があるだろうか?
どれだけがんばって努力しようと,翌日の新聞には勝者と敗者の名前が載ります.
「足が痛かった」
「風が強かった」
「一生懸命がんばった」
などと言い訳をしても,
Who cares?
Who won?
と言われる世界です.
そしてそれは,プロとして働いて飯食ってるなら,スポーツ選手に限った話ではないと思うわけです.
というわけでこれから日本に帰ります.
「残業時間が多ければたくさん働いている」という風潮は,まったくどうしようもないと思う.
そもそもエンジニアという人種は,クリエイターであるべきで,時間とアウトプットは必ずしも比例しない.
例えるなら,エンジニアはあくまでも「小説家」であるはずなのに,「編集者」のような働き方が横行しているように思う.
時間じゃなくて結果を見ろよ,結果を.
与えられた仕事に対するアウトプットが良ければ「あの人は優秀」だとか「仕事ができる」だとか言われるのかもしれないけど,どれだけ完璧にこなしたところで,言われたことをやっているうちははっきり言って二流だと思う.
仕事で今日まで San Francisco に滞在しています.こちらは現在3日土曜の午前中.もうすぐホテルを出て,数時間後には飛行機に乗っているはずです.
…っが,なんと今夜,私が大好きな大好きな Marc Ford が,ここ San Francisco でライブをやるんです.
マーク見たかった.マーク見たかった.マーク見たかった.マーク見たかった.マー (以下略)
Alex Bosworth の Blog より,「Google が web を破壊している」という記事.
Google is destroying the web and you don't even know it
なかなかウィットに富んだ文章なので,興味のある方は目を通されると良いだろうが,内容の要点だけ意訳すると,
- 検索における Google の支配力はあまりに強く,地球上のほぼ全ての人に対して,インターネットのメインゲートとなっている
- あなたのサイトの集客率を上げたければ,Google の検索結果で上位に表示される必要があり,その為には Google の「ルール」に従う必要がある
- しかしこの SEO (検索エンジン最適化) が諸悪の根源
- Google は,あなたの運営するサイトにどんどんトラフィックを増やし,あなたが集客の為に施した努力の何百倍ものユーザーを連れてくる
- その様子を見ているうちに SEO に夢中になり,あなたの関心はサイトの内容やアイデア,純粋なユーザーコミュニティではなく,Google に好かれるかどうかになる
みたいなことが書かれている.
確かに「Google の検索結果で15位以内に入らなければ,そのサイトは存在しないのと同じ」と言われ,企業を相手にした SEO 専門のコンサル会社まであるぐらいだから,この話がそれ程大袈裟だとは思わない.なにかを検索した時に,上位に表示されるサイトは SEO に凝りに凝った無味乾燥なサイトで,検索結果の 2 - 3ページ目あたりに表示されるサイトが実は濃くておもしろい…なんていう逆転現象も,少なくとも過渡期ではあり得るかもしれない.
私は,そもそも SEO には懐疑的だし,麻薬のようなものだと思っている.
Google が本当に web を破壊しているかどうかは別として,ことインターネットの世界においては,個人的には「なるようになる」と思っている…というか,「なった姿が正解」で良いのではないだろうか.
どちらにしろ,インターネットによって破壊された国境の上に,誰かが新たな世界地図を描くのだ.