このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

今年のデブサミ2008で、ジョエルを抑えて満足度1位を獲得したランドスケープデザイナーの石川初さん。最近のエントリが面白すぎる。 バックヤードとしての港湾 最近、Googleマップの空撮が普及して、上空からの高解像度の写真を眺める機会が増えるにつれて、建物の屋上が街のバックヤードと化していることがよくわかる。特に都心部にはほとんど「屋根の景」がない。空調の屋外機が延々と並んでいる光景は、自動販売機を後ろ側から眺めているみたいなおもむきだ。 これが、都市のスケールでは、「海岸」がでかいバックヤードになっている。高度に近代化した都市の港湾の「海側からの眺め」というのはほんとに、都市の「裏側」である。きっと、沿岸の「栄養源」から「物資の流通媒体」へと、海岸がその価値を転換させたときから、海側は巨大な荷捌き場になっちゃったのだ。 街へ出よ、驚愕せよ。 （建築学科の学生に地図を見せて『なにか変なこと

ITアーキテクトは、そのシステムがもたらす世界を雄弁に語れなくてはならない。 クライアントよりも、システムの企画者よりも、開発者よりも、魅力的に語れなくてはいけない。 システムのアーキテクチャではなく、なぜ、そのシステムが必要なのかを語れなくてはいけない。 開発の苦労ではなく、利用する楽しみを語れなくてはいけない。 アプリケーションのパフォーマンスではなく、ユーザーのビジネスにおけるパフォーマンスを語れなくてはいけない。 それができる人がITアーキテクトだ。 エンジニアにはユーザーの声を聞かせ、システムの目的を語り続けることが大事だ。 ユーザーにはエンジニアの魅力を語り、システムの目的を語り続けることが大事だ。 そう、同じことを語ればいい。どちらかに伝わらないならシステムはうまくいかないだろう。 ビジネスを意識していないシステムは少しずつ減ってきているように思う。それでも動かないシステムは

ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1（JIS X 0129-1）というのに初めて目を通しました（不勉強ですみません）。本物は、ＪISの検索ページで、「x0129」と入力するとでてきます。 で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。 ※上記ページからの直リンク 右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。 そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計／開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。 プロセス品質（JISX0160に規定されているすべてのライ

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ただの感想文です。アプリケーションの足回りの状況がかなり変わってきていることを実感しています。 足回り、というのはサーバ、CPU、メモリ、OSあたりの層です。トピックスとしては、並列・分散処理、仮想化、マルチコア、インメモリ、キャッシュという感じです。一昔前は理想論ばかりで現場で使えないという印象が強かったのですが、そんなこともなくなってきています。 一時期は潤沢なサーバリソースを前提にサーバのことは気にしないで富豪プログラミングをしなさいということが言われていました。しかし、いま足回りに起きていることは量的な変化を超えて質的な変化になっています。むしろ足回りの特性を利用したアプリケーションを構築するという考え方にしていかなくてはいけません。 たとえば1台のサーバにC

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ Processingというツールをご存知でしょうか。 公式サイト 日本のサイト　 MITで開発されたオープンソースのグラフィックツールです。 Processing is an open source programming language and environment for people who want to program images, animation, and interactions. そうなんです。面白いのはスクリプトで記述すること。ドラッグ＆ドロップもありません。ひたすらスクリプト。しかもJavaで作られていているので構文がJavaっぽくて書きやすい（例外もJavaで吐かれるので僕にとっては分かりやすいｗ）。 で、ずいぶん前のエントリ「複雑系

Inter Communication (インターコミュニケーション) 2007年 04月号 の特集は、「デザイン／アート 芸術と科学のインターフェイス」というもの。いくつか面白い記事があったのですが、抽象化がもたらすリアルみたいなことで思うことがありました。 まず、巻頭の茂木さんと山中さんの対談はそうだよねぇーの連続。山中さんはSuica自動改札機やCyclopsをデザインしたことで有名な方。 ところでヒューマノイド・ロボットを作るうえで、人間に似せていくほど不気味になってくるという「不気味の谷（Wikipedia）」という現象があります。山中さんは、これを「サイエンティストの傲慢」と切った上で次のように述べています。 彫刻を作るとき、睫毛を植えたり、髪の毛を生やしたりは普通しないですよね。なぜならば、そんなことをしないほうが美しく、よりリアルであることをアーティストたちは気がついてい

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと前ですが、森さんの「仕事の価値を高める「デザイン」と「クリエイティブ」」が面白かったです。 クリエイティブ・クラス 引用されている「クリエイティブ・クラス」は、リチャード・フロリダ氏の本で最近、注目されている概念です。HBRのページから引用すると（ピンクはダニエル・ピンクね）、 ピンクの考えるところでクリエイティブ・クラスを定義すると、「左脳思考だけでなく、右脳思考もできる人」であり、「何らかの専門性を持ちながらも、そこに埋没することなく全体観を俯瞰でき」、かつ「論理的でありながらも、美しさや遊びといった、論理では説明し切れない世界を理解できる人」ということになりましょうか。 という感じ。よく言われる理想的人材像の現代版でしょうか。そして、 ただ持っているだ

先日の情動回路で登場されていた河本さんに興味を持ち「哲学、脳を揺さぶる オートポイエーシスの練習問題」を読んでいます。いくつか面白いトピックスがあったので備忘録の意味も含めて書いておきます。 カフカの小説「審判」に掟の門という短い寓話が出てきます。Googleしてみると出てきますが良さそうなものをあげておきます。3分で読み終わるので、ぜひ読んでみてください。 掟　の　門 非常に複雑な読後感を覚えます。いくつかのブログの書かれている感想を読むと「勇気をもって門に入るべし。それを妨げるのは自分の気持ち。無目的な遅延に意味はない」といういった論調が多いようです。確かに農夫は自ら待つことを選択しているように見えるのです。 門番を問いただすことに意味があるだろうか 河本さんは「門番を問いただすことに意味があるだろうか」という投げかけをしています。仮に農夫が「どうして門が続くことを知っているのか？」

音速の壁を破ったことで知られるチャック・イェーガー。彼は第二次世界大戦でのエースパイロットとしても知られています。イェーガーは、いかにしてドッグファイトに勝つのかという問いにこう答えています。 旋回のことすら考えるな。ただ頭か身体を旋回し、飛行機をついて来させるだけだ。狙いを定めたら、その位置に弾丸を放て。 あぁニュータイプ。さて、本題。イェーガーの格言です。 You do what you can for as long as you can, and when you finally can't, you do the next best thing. You back up but you don't give up. 意味としては「まずは、できる限りのことをやりなさい。それでもだめになったら、その次にできる限りのことをするのです。バックアップしなさい。でも、ギブアップしてはならない

アプリケーションを構築するために考える基本的な要素は3つだと思います。それがファンクショナリティ、ユーザビリティ、スケーラビリティです。 1.ファンクショナリティ（機能性）：アプリケーションが提供すべき機能そのもの 2.ユーザビリティ（使える性※）：アプリケーションの機能を、ユーザーが使えるようにする 3.スケーラビリティ（調整可能性）：ユーザービリティを低減させること無く、適切な数のユーザーに提供する ※ユーザービリティを「使いやすさ」と訳すと「ユーザビリティ＝使いやすさ」なんて誤訳をいつまで放置するのか？と言われてしまうので。 この3つは同時に実現されるべきものです。機能が良くても使えなくは意味がない。使えても提供できなくては意味がない。提供もできて使えても機能がヘボでは意味がない。 これがけっこう難しい。アプリケーションというと1.ファンクショナリティというのに目が行きがちで2、3を

この1年ぐらいはSOAのアイデアを、どうにかしてアプリケーション開発に利用できないかと考えています。まだまだアイデア段階なのですが、ちょいちょい書いていきます。 マルチレイヤーでは統合が重要 Javaに限らずアプリケーションというのは複数の層によって開発するというのが一般的です。MVCモデルのようなプレゼンテーション層とパーシステンス層の分離が有名ですが、間にファサード層、ビジネスロジック層など挟み込むというのも良く行われています。 アプリケーションをモノシリックな仕組みで作ってしまうと複雑性が増し柔軟性が失われてしまいます。そこで、層ごとに分離することでシンプルさを保つことようにします。層ごとには責務や役割を明確にされ、それ応じたエンジニアが開発を行います。 層を分離するからには層を統合しなくてはなりません。層をいかに統合するのかというのは、層を分離することよりも重要です。 メッセージ

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ つらつらと。 思い返せば、日立ソフトの河村さんにお誘いいただき講演させていただいたのが昨年。その後、コンテンツ委員（コミュニティ関連の講演者手配とか内容検討をする秘密結社）にもお呼びいただいてアーキテクチャゾーンの担当に。それなのになぜか開発テクノロジーゾーン（mixi、Google、Shibuya）とかマーケティングゾーン（棚橋さん）とかにも関わりつつ、結局、自分も講演しつつ。 一番うれしかったのはNTTデータの橋爪さんに「Shibuyaイベント面白かった！」と言っていただいたこと。 Shibuyaの皆こそ、一番テクノロジーに対してピュアに向き合っているし、すごく運用に気を使っているし、お金ことも身近に感じているわけです。エンジニアとしてクリエイティビティにもっと

ちょっと古めの情報ですが、ITアーキテクト Vol.9（2007年1月24日発売）の「トップ・アーキテクトの履歴書」にてキャリアをご紹介いただきました。両開きで半分が写真です。 題名の 行動が縁を呼び、縁が未来を変える は、写真の上に書かれたコピー。1時間程度のお話をサマリした結果として出していただいた言葉でしょう。うん、今の僕を良く表している言葉だと思います。すごい気に入りました。 内容自体も、この言葉に即して淡々とキャリアを追っていただきました。いまの僕の働き方（仕事）を説明する一番良い資料ではないでしょうか。ご一読いただければ幸いです。 行動すれば必ず変化が訪れます。それを縁と呼ぶか、運命と呼ぶか、宿命と呼ぶか。あるいは必然や偶然。どれにしても起こってしまった行動は変えられず、後は訪れたソレを受け入れるかどうかだけです。 そして、その評価は時間が過ぎてみないとわかりません。歴史は未来

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 昨年開催された「Mash up Award」の第２回が開催されます。前回はSun × RECRUITという冠がありましたが、それを取ったのは17社を超える企業の協賛があるから。前回以上の様々なWebAPIを利用することができるようになっています。詳しくは以下のURLへ。2007年3月12日 17:59必着で参加するべし。 http://jp.sun.com/mashupaward/ http://bic.recruit.co.jp/mashupaward/ さて、このコンテストですが大きなチャンスなのです。首謀者ふじーさんも書かれていますが、 日ごろ開発者自身になかなか光があたらない状況のなか、入賞された方のなかには、「いきなり仕事の依頼がたくさん来た」とか「取材を

ひがさんのエントリ「規約ベースのフレームワークのほうが覚えることが増える? 」を読んでいて、ふとした気づき。 暗黙的な規約は直感的ではない 結論から言えば、僕は"暗黙的な規約（Tacit Convention）"ではなく"形式的な設定（Articulable Configuration）"が重要だと思っています。ちなみに、Tacit Knowledgeは暗黙知でArticulable Knowledgeは形式知のこと。 なぜなら"暗黙的な規約"は、ある意味で直感的ではないからです。 人間が情報に反応するためには、情報が何らかの形で形式化されていなくてはいけません。 たとえば何かの操作を方法を学ぶ場合を考えてみます。説明書というのは操作方法を形式化したものです。しかし、直感的ではない。それは操作対象そのものに触るわけではなく、絵などで遠まわしに説明されているからです。 一方、説明書なん

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ SOAがなぜ流行らないか いまさらSOAかよ、という感じかもしれないですが。SOAがなぜ流行らないか、ということには分かりやすい理由があります（この場合のSOAというのは「インターフェース・ネットワーク（＝サービス）指向のアーキテクチャ」という広義な意味を示します。WebServiceｓとか、製品はどうでもよいです）。 荒地に種を蒔いても収穫はありません。ちゃんと荒地を耕して畑にしてから種を蒔かないといけない。しかも、一気に耕すことはできないから、耕しやすいところを見つけて一歩一歩やっていく。たぶん小学生でも理解できる。 SOAも同じこと。SOAが求められるビジネス（＝マーケット）がないのにSOAは売れません。今やるべきことは、製品を作ることではなくマーケットを耕す

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 追記2：Groovyのサンプルをまたもや修正。矢野さんにコメントいただいたとおりです。 追記1：Groovyのサンプルにウソがありました。ごめんなさい。eachやinjectはListの拡張なので、[1..5]のRangeでは使えません。eachするとRangeそのものが取れちゃいます。ちゃんと試さずに書いちゃいました。ちなみにデモは[1,2,3,4,5]とやってのでうまくいきました。 ブログもアップできず本当に情けない…。さて、昨日の第2回丸山先生レクチャーシリーズ で「混ぜるな危険！？　JavaとLLをマッシュアップせよ」というタイトルで講演させていただきました。資料はこちらからダウンロードできます。 Java業界でもJSR223を機会にLLに対する取り組みが盛り

arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ ちょっと心をいれかえてブログをなるべく書くようにします。はい。 昨日、稚北つながりでGoogle（東京＋本社）の人々と夕飯。中の人と色々話すことができました。やっぱGoogleはすごいなぁと。 技術力がウリです エンタープライズ業界で「うちは技術力がウリです」なんていう会社に会うことがあるのですが、Googleなんかを知ってしまうと「うーん」と。なんか世界が狭いなぁと感じます。たしかに国内のSIerやベンダーの平均点と比べて「技術力が高い」っていうのは事実だとしても、それは井の中。 Googleをちゃんと競争相手として考えられるのかというのは大きな分岐点だと思います。それに「国内のSIerやベンダー」だってトップレベルのエンジニアはやっぱりすごい。「組織としての技