このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
ITを本当の意味でサービスにするとは、どういうことでしょうか。それはヒトの作業を代替することではなくて、ヒトを支援すること。そして、IT自身は透明になっていくのです。 デブサミ2009の講演「【12-C-1】不確実時代のアーキテクチャを予言する」向けにプレミーティングをしていて、非常に面白い話を聞きました。 ホテルオークラで情報システム担当をしていた石原 直さんは成田の発着情報のオンライン化に尽力された人(その後は芝パークホテルの社長、会長。現在はNPO法人旅行電子取引推進機構理事長)。 じゃ、オンライン化されて入手した発着状況をどう使うのか? 普通のホテルならロビーのインフォメーションパネルに情報を流しますと。そして、自由に宿泊客がみれるようにする。 でも、オークラは宿泊客から情報を隠してしまう。そして、しかるべき時に取り出せるようにする。つまり、宿泊客にサービスする瞬間に、従業員が入手
今年のデブサミ2008で、ジョエルを抑えて満足度1位を獲得したランドスケープデザイナーの石川初さん。最近のエントリが面白すぎる。 バックヤードとしての港湾 最近、Googleマップの空撮が普及して、上空からの高解像度の写真を眺める機会が増えるにつれて、建物の屋上が街のバックヤードと化していることがよくわかる。特に都心部にはほとんど「屋根の景」がない。空調の屋外機が延々と並んでいる光景は、自動販売機を後ろ側から眺めているみたいなおもむきだ。 これが、都市のスケールでは、「海岸」がでかいバックヤードになっている。高度に近代化した都市の港湾の「海側からの眺め」というのはほんとに、都市の「裏側」である。きっと、沿岸の「栄養源」から「物資の流通媒体」へと、海岸がその価値を転換させたときから、海側は巨大な荷捌き場になっちゃったのだ。 街へ出よ、驚愕せよ。 (建築学科の学生に地図を見せて『なにか変なこと
これは言っておかねばなるまい。ひがさんのCTCと夜の決闘より。 生産性を向上させるということを主目的としてフレームワークが作られたのは、基本的(もちろん例外はあるけど)にRails以降のフレームワークです。 Railsは、Struts、Spring、Hibernateへのアンチテーゼとして登場しています。裏を返せば、Struts、Spring、Hibernateを組み合わせても生産性は出ないということです。 生産性という言葉をどう取るかによりますが、確かにSpringはコードを短く書くためのフレームワークではありません。 そもそも生産性を上げるためには、アプリケーションの部位毎に個別最適化していき、それらを統合するというのが正しい戦略です。これは規模にかかわりませんし、Seasarを使おうが、Springを使おうが同じ事です。 Seasarは最適化をうまく行っているフレームワークです。ただ
石川さんのところに行ったときに「テクノロジーは世界をインターフェースする」という話を聞いたのですが、その元ネタがこれ、「Designing World-realm Experiences:The Absence of World "Users"(世界経験のデザイン_"世界"に"ユーザー"はいない)」。 書かれたのはリビングワールドの西村佳哲(にしむら・よしあき)さん(参考記事:リビングワールド:世界を感じるものづくり)。様々なデザイン活動でも知られていますし、最近では自分の仕事をつくるという本でも有名です。 で、西村さんが1999年に書いた文章。かなりシビレます。長い抜粋。 デザインとは、インターフェイスすることであって、インターフェイスをつくることではありません。私たちは、他の人々や生きている世界と接したいのであって、コンピュータなどの情報機器や、インターフェイスデザインと接したいわけで
梅田さんによるサバティカル前、最後の本「ウェブ時代 5つの定理 この言葉が未来を切り開く!」。僕も金言マニアですが、梅田さんも同じ趣味なんだと知って、妙に納得しました。言葉からは勇気をもらえますよね。 さて、この本の副題にもなっていますが、やはり make the world a better place という言葉が好きですね。 尊大と言われも、やっぱり、そこを見ていないといけない。梅田さんが理系的な発想として 原発から微細加工部品まで、何かの製品やシステムを見たら、それがどういうメカニズムでつくられているか、どうやって動くものかを理解し、それを自分ならどうつくるかを考える。そういうふうにいつも頭を働かせているのです。 と書いていますが、実際には、製品やシステムだけでなくて世界そのものに対して「どうやって動くのか?」と考えています。そういう発想を持つ人たちがどうやって生きているのか。 個
「僕はITアーキテクトです」と名乗るのが、昔は恥ずかしかったものです。ですが、ある時期から吹っ切れていました。やはり僕の原点なんだなと思って。 そのものではなく環境を見る 大体において、「そのもの」が悪いってことはないのです。日経SYSTEMSのコラムに書いたものを引用します。 「間違えたのはITエンジニアだから悪いのはITエンジニアである」ということから一歩進んで,「なぜITエンジニアが間違えなくてはならなかったのか」と考えるわけである。そのためには,プログラミングという作業全体を俯瞰し,その前後左右に何があるのかを見る ITエンジニアを取り囲む環境の中に,バグを誘引する要素がある 書き方がバラバラな仕様書,複雑で理解しにくいアプリケーション・フレームワーク,ドキュメントが無いライブラリ群,使いこなせないIDE(統合開発環境),など。いずれも,バグを引き起こす原因になることは説明するま
最近、やたらと議事録やコンセプトブックなどを書いています(その結果、ブログの文字量が減ってしまうのが僕の情けないところ)。本当は議事録を書くコツを書きたいところですが、まとまっていないのでだらだらと。 議事録の宿命は全発言を書くわけではない、ということです。だから議事録を書くのは簡単ではありません。聞き上手だけでも書き上手だけでもだめ。まとめることが求められます。まとめるということは書き手の意図が含まれるわけです。 では、書き手はどのように議事録を記述していくのか。そのプロセスには分析、構築、表現という3つがあると思っています。 分析:会議の編集構造を理解する 議事録を書くのがうまい人は「議論している場の編集構造」と「議事録の構造」をきちんと使い分ける人です。ミーティングそのものをアジェンダを決めて構造的に進めることは重要ですが、そんなにきれいに話は進みません。その場だけが持つ話の構造
最近、組織関連の本を読んでいます。1つ、大きな特徴を上げるとインターネット後におきた極端な分権型組織ブームの影響を受けていることです。多くの論調は、イノベーションや創造性のためには分権型の組織が向いているというものです。これの反対が中央集権型組織。両者を比べてみましょう。 ■中央集権型組織(ツリー型) 特徴: ・コミュニケーションパスを固定化して、流量を少なくする ・プロセスを明示する ・上意下達 メリット: ・処理効率が非常に高まる ・メンバースキルのブレが安定する ・作業負荷が増えても耐えられる デメリット: ・変化に弱い。一度、固定化したものを容易には代えられない ・プロセスそのものの非効率性が修正されにくい ・参加意識が弱い。歯車化 ■分権型組織(ネットワーク型、フラット型) 特徴: ・全員がフラットで、コミュニケーションパスがたくさんある ・適宜、
製造業における品質というのは、多くの場合は生産工程におけるブレのことをいいます。Wikipediaにによるとシックスシグマとは、次のようなもの。 6σの状態とは、ある製品組立工程の品質特性値が正規分布に従うと仮定するならば、6σの外に出る確率は、100万分の3.4である。すなわち、ある工程では100万個製品を組み立てて3.4個のばらつき(不良品)が生じる。「100万回作業を実施しても不良品の発生率を3.4回に抑える」ことへのスローガンとしてシックス・シグマという言葉は使われ、定着していった。 システムでの生産とはランタイム ではシステムでいう生産工程はどこのことでしょうか?ふつうは実装と思われがちですよね。でも、製造業における生産とは「同じ作業を繰り返し行うこと」という前提があります。だからこそ、そこで不良品が出る割合を抑えようと考えるのです。では、システムでいう生産工程とはどこか。それ
Facebookの認知度は上がってきていると思います。2007年5月にFacebook Platformを発表して以降は「次世代のソーシャルOS」というラベルが貼られ、その動向が注目されています。10月24日にはMicrosoftが2億4000万ドルを出資し、評価額は150億ドル(1.7兆)に跳ね上がりました。また、11月2日に発表されたGoogleのオープンソーシャルに対しては当然のように参加を表明していません。 Facebook Platformとは Facebook Platformはサードパーティの開発者がFacebook上の情報を利用してアプリケーションを開発できる仕組みです。それだけならデータベース型ですが、加えて開発したアプリケーションはFacebookに登録することが可能です。Facebookユーザーはアプリケーションの一覧から欲しいアプリケーションをクリックするだけで自
Web2.0 Expoでベスト講演をあげるとすればチームラボの猪子さんによる「インターフェースデザインのイノベーション(テクノロジーとデザインの境界線があいまいなもの)」です。これはヤバイ。 以下、サマリ。 サーチやマッチングというテクノロジーがあるおかげで、Webにある情報はサイト内外の情報を動的に再編集して構成されるようになった。だから、そのリンク構造も動的。当然、サイトマップやきれいな階層構造なんて存在しない。 サイトの構造が動的なんだから、インターフェースも当然、動的だよね。逆にインターフェースが構造の動的さを引き出して魅力を出さなきゃいけない。 テクノロジー(構造)とインターフェースは切り離して考えることなんてできない。一体なんだよ。 いえーい!も、マイナビバイトも、SAGOOLも、Laboo!も、そうやって作った。 これって「インターフェースの革新の本流」。すごい西洋的。iPa
ITアーキテクトは、そのシステムがもたらす世界を雄弁に語れなくてはならない。 クライアントよりも、システムの企画者よりも、開発者よりも、魅力的に語れなくてはいけない。 システムのアーキテクチャではなく、なぜ、そのシステムが必要なのかを語れなくてはいけない。 開発の苦労ではなく、利用する楽しみを語れなくてはいけない。 アプリケーションのパフォーマンスではなく、ユーザーのビジネスにおけるパフォーマンスを語れなくてはいけない。 それができる人がITアーキテクトだ。 エンジニアにはユーザーの声を聞かせ、システムの目的を語り続けることが大事だ。 ユーザーにはエンジニアの魅力を語り、システムの目的を語り続けることが大事だ。 そう、同じことを語ればいい。どちらかに伝わらないならシステムはうまくいかないだろう。 ビジネスを意識していないシステムは少しずつ減ってきているように思う。それでも動かないシステムは
CULTIVATEは、建築家の小嶋一浩氏と赤松佳珠子氏が率いる「CAt(シーアンドエイトウキョウ)」が手掛けている3プロジェクトの紹介を通して、「耕す(cultivate)ように建築する」というテーマを紐解くもの。 <耕す>という言葉は<開発>という言葉と対比されます。マスタプラントと計画があり完成図に向けてひた走るのが<開発>。それに対して、長い時間をかけ、自然と向き合い、ミクロ的に考えていくのが<耕す>Webからのインタビューも面白いです。 さて、本の中の一節。 ”建築は<もの>ではなく<出来事>である”(※) ターゲットは、<もの>ではなくて<出来事>である。空間の中には、様々なファクターが流れている。そうした流れ=フルイドを方向付ける(ダイレクションする)ことが、建築を設計するということではないか、と私たちは考え始めている。 ※元ネタはヴトゲンシュタインの”世界は<事態>の総和であ
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 思想と態度は明確に違います。 思想とは(主に個人によって)事前的に明示されるものです。態度とは(主に集団によって)行動から事後的に明示されるものです。時間が経ってから現状分析して、態度を思想のように言う人がいますが非常にむかつきます。 Web2.0の本質は態度です。口コミでも、ロングテールでも、集団知でも、ましてやSNSでも、Blogでもありません。 目的や役割と態度は明確に違います。 同じ態度であれば様々な行動を取ることができます。そこには役割も目的もありません。ただ態度だけがある。 目的や役割の中でしか行動できない人には態度で行動している人のことが理解できません。「なぜ、そんなにいつも違うことをするの?」と。 態度は見ることはできません。 態度はいくつかの行動によ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く