デザインする人に必要な能力は？: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 発作的に、なんとなくデザイン（企画・設計）をする人に必要な能力なるものをまとめてみたくなったので実行（ようは自分の頭のなかを整理するため）。 もちろん、ここでいう「デザイン」は、ある問題を発見して解決するためのプランを考え実現させることをいう。なので、決して狭義のデザイナーのことではありません。 で、そういう意味での「デザイン」をする人にとって必要な能力をまず、ザクッと分類すると以下の4つに分けられるのではないか、と思います。 知る・感じる・疑問に思う解釈する・発想する・組み立てる具体化する・検証する・洗練させる仕事をはじめ、終わらせる どれもデザインをする上では欠かせない。 というわけで、ひとつひとつ整理していくことにします。 知る・感じる・疑問に思うスタート地点はやっぱ
戦艦大和や零戦は「システム工学」の産物：日経ビジネスオンライン
戦前の東京大学工学部船舶工学科は、航空学科と並んで人気トップの学科だった。船舶工学科の学生は3年生になると成績上位の5人ほどが当時の海軍に選抜されて海軍委託学生になる。様々な軍艦を設計し、軍事面の国際競争力を高めたのは彼らだった。 大正時代には、欧州の設計の模倣しかできなかったのに、昭和10年代には様々な艦種で独自設計の成果から高性能の軍艦が誕生し、供用されていった。 軍艦も工業製品である。優れた工業製品の裏には、優れた科学技術があるのが普通である。だから、戦艦大和を典型例とする優れた艦艇を送り出した裏には、優れた科学技術が1930年代の日本にあっただろうと想像するのが自然である。 しかし、事実は全く違うと言っていいだろう。 日本に優れた科学技術があったわけではない 私は29歳の時、東大に転職し、船の設計を中心的なテーマとする船舶工学第一講座で仕事を始めた。その頃、研究室が過去に取り組んで
まつもと直伝 プログラミングのオキテ 第20回 MVCとRuby on Rails：ITpro
Ruby on Railsをはじめとする最近のWebアプリケーション・フレームワークの多くは，MVCと呼ばれるデザイン・パターンを採用しています。今回は，このMVCパターンの「正体」について考えます。 MVCはGUIを備えたプログラムを設計する際の指針となるデザイン・パターン＊1の一つです。「モデル」（Model），「ビュー」（View），「コントローラ」（Controller）という3つの構成要素の頭文字から命名されました。多くのデザイン・パターンはプログラムの一部のみの構成を決めています。しかし，MVCはアプリケーション全体の構成を決めることが多いため，「アーキテクチャ・パターン」と呼ばれることもあります。 MVCは，元々プログラミング言語Smalltalkにおいて，ウインドウ（GUI）を持つアプリケーションを構築する際の指針として誕生しました。 MVCを発明したのは，当時，米Xero
言語としてのアーキテクチャ： ストーリー
私がプロジェクトに就いたとき、すでに顧客はシステムのバックボーンをメッセージング基盤にすることを決定しており（この種のシステムには良い決定です）、さまざまなメッセージングバックボーンのパフォーマンスとスループットを評価していました。また、このシステムで扱うデータを記述するためのシステムワイドな（システム全体を網羅する）ビジネスオブジェクトモデルを選ぶことをすでに決定していました（実のところ、この種のシステムにはあまり良い決定ではありませんが、このストーリーの落ちには重要でありません）。 したがって、私がプロジェクトに就いたとき、顧客はシステムの全詳細とすでに行ったアーキテクチャに関する決定について私に概要を説明し、簡単に言えば、そのすべてが道理にかなっているかどうかを尋ねてきました。顧客は、多数の要件を把握しており、特定のアーキテクチャ側面に関するピンポイントの決定を行う一方で、私が一貫し
スケーラビリティとユーザービリティの話
先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。 サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。 限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。 たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前
単純だが悩ましい、 情報システムの“うっかりミス”：日経ビジネスオンライン
思いもよらなかった間違いをしでかした経験は誰にでもあるだろう。なぜ間違えたかと質されても「つい、うっかり…」としか答えられない。情報システムの世界でも“うっかりミス”はある。ミスの単純さに比べ、影響が及ぶ範囲は広く、実に悩ましい。 5月から6月末にかけて、情報システムに関するうっかりミスについてずっと考えていた。「日経コンピュータ」7月15日号の特集記事、『「うっかりミス」は無くせる』のデスクをしていたからだ。デスクとは、現場の編集記者を支える役回りである。取材をして記事を書くのが編集記者だが、デスクは彼（彼女）らの書いてきた原稿を読んで修正したり、書き方を助言したりする。筆者の本業は記者であるから、本当は一人で原稿を書いていたいのだが、時にはデスクも務めることがある。 うっかりミスとは、いわゆるヒューマンエラーと言われるものである。発電所や交通機関、航空管制といった巨大システムにおいては
ザックマンフレームワーク（ざっくまんふれーむわーく）
エンタープライズ・アーキテクチャ（EA）（注1）を考えるためのフレームワークで、組織（enterprise）という複雑な構造物を体系的に記述・観測できるように、各要素の範囲や関係を分類・整理したもの。IBMのコンサルタントだったジョン・A・ザックマン（John A. Zachman）が考案したことから、この名が付いた。 EAにおけるフレームワークとは、EAを設計・構築・評価するためのガイドラインとなるもので、ここに実際の組織の構成要素をあてはめていくことで、構造の整理・分析が行える枠組みをいう。ザックマンフレームワークは、企業階層（関与者）の観点を縦軸、5W1Hの観点を横軸に取った6行6列※のマトリクスで表現される。 ※ 最終行の「実際の企業」（functional enterprise）は関与者の視点ではなく、モデルや成果物も例示されていないので、これは数に入れずに「5行6列」と解説され
ソフトウェアアーキテクチャって何なの？（前編） ― ＠IT
ソフトウェアアーキテクチャって何なの？（前編）：The Rational Edge（1/3 ページ） The Rational Edgeより：ソフトウェアアーキテクチャという比較的新しい分野について概説する。今回はシリーズの第1弾という位置付け。この分野のキーワードを説明し、優れたデザインのアーキテクチャが、導入された環境にどのように寄与するのかを探っていく。 ソフトウェアへの依存度が高まっていることに疑問の余地はない。ソフトウェアは、複雑な航空管制システムだけでなく、かなり普及した携帯電話にも絶対欠かせない要素だ。実際、eBayやAmazonといった企業など、われわれが当然のように思っている多くの技術革新は、ソフトウェアがなければ存在していなかった。金融、小売り、公営企業といった従来の組織でさえも、ソフトウェアに大きく依存しているのだ。現代においては、ソフトウェアビジネスに全く関与してい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Technical documentation