業務システムのユーザビリティ: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 世間では、ユーザビリティといえば、プロダクトのUIやWebサイトに関連した話題ばかりが取り上げられます。しかし、ユーザビリティを改善することで最も効果が得られやすく、かつ、実はユーザビリティの改善のための作業を行いやすいのが、業務システムの分野だろうと僕は感じています。 ユーザビリティの改善によって、 システムの利用効率を上げる利用のわかりにくさや利用の仕方の誤認を要因とする誤操作や誤入力を減らすエンドユーザーが利用時に不満を感じるところを削減してシステム利用に対する精神的負担を軽減する などが実現できれば、業務全体の効率や、システムを用いて行う情報の入力率を高めて、開発するシステムに期待する効果をあげやすくなると思います。ほかの場面ではその拡大使用を懐疑的な目で見ていいの
その仕事に何が求められているかを明確にするためのスキルと方法: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 いろんな現場でいえることだと思いますが、なにか新しい仕事(プロジェクト)をはじめる際には、その仕事には何が求められているかをきちんと明示しておくことが大事だと思います。 ひとことでいえば要件定義です。 ただ、要件定義とひとことで名詞でいってしまうと、なぜそれが必要なのかが見えなくなります。機械的に要件定義と呼ばれているものを満たそうとする。要件定義をするにはそれなりに理由があるのですが、その理由のことなどは頭の片隅でも考えないまま、ただ要件定義と呼ばれる作業を機械的にこなすだけになったりします。それではダメです。 では、要件定義をする理由とはなんなのか？ 1つには、多くの仕事がほかの大きな仕事の一部だったりするからです。 B2Bの業務委託型のビジネスから消費財の製造・販売ま
「Joel on Software」の筆者が語る“人を幸せにする”ソフト開発のポイント：ITpro
2008年2月13日，ソフトウエア開発者向けイベント「Developers Summit 2008」（主催：翔泳社）が始まり，米Fog Creek SoftwareのCEOであるJoel Spolsky氏（写真1）がセッションに登壇した。Spolsky氏は，ソフトウエア開発についての諸問題を皮肉とユーモアたっぷりに論じた書籍およびブログ，「Joel on Software」で有名。セッションも著書と同じく皮肉とユーモアに満ちたものになった。 セッションのテーマは「素晴らしいソフトウェアを作るということ」。機能的に優れた製品を作っても，市場で優位に立てないというよくある現象を分析し，万人に愛されるソフトウエアを作る方法を探るという流れでセッションは進んだ。 セッションの冒頭でSpolsky氏は，いきなりサッカー選手David Beckhamとその同僚Landon Donovan（どちらもLo
何が起こっているのかわからない状態を脱するための9つの工程: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 仕事でなにかしら問題やもめごとがあるようなんだけど、ただ正確には何が起こっているのかわからないときには、たとえば、こんなことをやってみるといいでしょう。 まずは目の前の状況を整理する自分の立場を考える関係者が誰なのかを把握する目の前には見えていない情報を集める集めた情報を整理して、何が根本的な問題であり、それに紐づくサブ的問題にはどんなものがあるかを階層化して、問題の構造をみえるようにするしかるべき判断あるいは問題解決のプラン作成を行う判断もしくはプランを実行する問題が解決されたか、あるいは解決されそうかを確認するダメならどこに障害が残っているのかを確認し、プランを修正しそれを実行する 勘がいい人ならこのリストを見て気づいたかもしれませんが、ようするに、何をやればいいといっ
デザインへの理解を深める: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 「Webデザインへの理解を深める」からインスパイアされて。 デザインとは、どうつくるかではなく、どう使われるかを考えることだと思います。 どうつくるか（ものからの視点）以上に、どう使われるか（ユーザーからの視点）を考えることを重視するからこそ「みんなで手を動かしながら考える」ことが必要で、そのプロセス自体をデザインしなくちゃいけないのだと思います。 どうつくるかは、デザインにとっては二義的です。 どう使われるかを考えぬいたうえで、使える状態を実現するために必要になる問題です。 もちろん、どうつくるかを考えることは大切なことだけど、デザインの第一義的な問題ではありません。 デザインするということは、制作することとは違うというのが前提です。 制作会社は必ずしもデザイン会社ではあ
iPhone/iPod touchと自転車のデザインの違い: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 これは「道具」と「方法」という視点からデザイン（というもの）を考えようとしている立場からすると、考えさせられるものがありますね。 いま、われわれが持っている道具とか方法というのも、結局、個々人がというより、われわれに至る生き物がずっと習慣化してきて、その中で蓄積されてきたものだと思います。ですから、いまここにあるものを、われわれは自分が所有しているかのように錯覚するけれども、それは所有というのではなく、単に受け継いでいるということなのですね。 松岡正剛さんと茂木健一郎さんによる対談集『脳と日本人』のなかの茂木さんの言葉です。 松岡さんの『千夜千冊』から千回くらい繰り返す習慣にしないと脳が更新されないという話から、そもそも個人的な蓄積ではどうすることもできない進化過程での蓄積
一見縁遠きものたちの間に脈絡を付ける: DESIGN IT! w/LOVE
僕って書いてみないとわからない人なので書いてみるよ。 まずは松岡正剛さんと茂木健一郎さんの対談集『脳と日本人』から松岡さんの発言を引用。 遠くを感じることが近さを強化していくんです。ニュートンのリンゴと星の関係のようにね。 これに対して「一見縁遠きものたちの間に脈絡を付けるということですね」と茂木さん。まさにこれは松岡さんのいう編集という方法の成せる業ですね。 また、この話は茂木さんのクオリアもここに重なってくるし、茂木さん自身「5年ぐらいほぼ毎日、日記をつけつづけています」というクオリア日記の意味も「脈絡を付ける」試みとして読むことができます。 ニュートンがリンゴと星という無関係なものの「脈絡を付ける」ことで偉大な発見をしたように、発見にはこの遠くのものと近くのもののあいだにいかに「脈絡を付ける」かということが欠かせないのだと思っています。このブログが時折、日本の歴史に言及しているのもそ
企画設計＝デザインとは: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 結局のところ、企画設計＝デザインとは、 与えられた問題あるいは自ら発見した問題を明確に定義しその問題を下位問題に分解し要素間の関係性を把握することで解決するべき問題全体を理解した上でさらには下位問題の各要素について理解を深めるためのデータ収集を行うことで下位問題のそれぞれに解決案を見つけつつ個々の解決案を最終的に統合する解決のコンセプトを探りそのコンセプトが見つかったら今度は実現に向けた素材や技術の検討や実現性の検討やコンセプトの検証のためのプロトタイピングとユーザーによるデザイン評価を行うことで最終的な設計案＝解決を導き出す という一連のプロセスにほかなりません。 まっ、これが創造性の基盤となるプロセスです。 もちろん、これがあれば「創造的な仕事」ができるようになるわけじ
企画設計＝デザインには学べば覚えられるやり方がある: DESIGN IT! w/LOVE
企画のやり方は単に本を読んだりして学ぶだけでなく、体感的なワークショップみたいな形式で学んでもらわないとダメなのかもしれないなって今日思いました。 保存されるべきものは、モノではない。むしろそのやり方であり、企画を立てる方法であり、出くわす問題に応じて再びやり直すことを可能にさせる柔軟な経験値である。 企画設計にかぎらず何でもそうなんだと思いますけど、身体にやり方が染み込んでないといざというときに対処できないと思うんですよね。 何かの拍子にあやまって海や川などに落ちてしまっても泳ぎ方が身についていれば溺れずに済みます。リストランテでの食事の際にパスタのサルサポマドーロが白いシャツに飛んでしまっても炭酸でたたくと染みがとれやすいことを知ってればそんなに慌てずに済むし帰ってすぐに家で洗濯すれば落ちます。運わるく悪い人たちにつかまって後ろ手に縛られても縄抜けの方法を知ってれば脱出できます。 企画
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
初めて来た人がすぐに使えるはてなにしたい : 2007-11-06 - jkondoの日記
毎日毎日はてなのサービスを使っていると、どこの部分が使いにくいのかがだんだん分かりにくくなります。たとえば「適当にブログを探していてたまたまふらっとはてなに立ち寄った人」の気持ちになって、そこからはてなダイアリーを使ってみようと思うまでを想像するのは実はかなり困難です。 しかし毎日新たに登録して利用を開始する人の多くはそうした初心者であり、こうした方に迷わずにはてなを使い始めて欲しいと思います。そのために誰でも使いやすいインターフェースにしなくてはいけないと考え、昨年末からユーザービリティテストを開始しました。ユーザビリティテストとは、一般の方にパソコンを操作してはてなを使ってもらい、その様子を見せてもらうテストです。 一般の方と言っても、すぐに適当な人を見つけてくるのは大変なので、まずは社員旅行の時に社員の家族の皆さんに順番にいろいろな操作を行ってもらうところから始めました。それからは、
[CSS]高さの異なるカラムを揃えるスタイルシート | コリス
Columnas 100% altas Columnas 100% altasのエントリーでは、下記のデモのように高さの異なるdivで組んだカラムの高さを揃えるスタイルシートを紹介しています。 sample:高さがばらばらのdiv sample:高さが揃ったdiv スタイルシートは、各divに対して「padding-bottom」と「margin-bottom」に同じ数値をプラス値とマイナス値で指定を行い高さを揃え、それらのdiv要素を包んだdivで「overflow:hidden;」を指定します。 詳しくは、最小限にしたサンプルを作成したので参照ください。 高さの異なるカラムを揃えるスタイルシートのサンプル 下記の「32768px」って、何か特別な意味があるのでしょうか。
ユーザー行動を構造的に分析するための5つのワークモデル: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 ひさびさに人間中心設計（Human Centered Design＝HCD）に関する話題を。 ここで書くのは、ユーザー調査から得られたユーザーの行動を構造的に分析するために用いる、5つのワークモデルについて。このワークモデリングの手法はContextual Designで用いられているものです。 ペルソナ／シナリオ法の使われ方に問題あり？で、なんで急にこんな話を書こうかと思ったかというと、世の中のペルソナ／シナリオ法の使われ方に疑問をもったからです。 前に「ユーザー行動シナリオは最初のデザイン」というエントリーで「ペルソナ／シナリオ法の肝は、実はペルソナのほうじゃなくてシナリオのほう」だと書きました。 しかし、世の中ではどうも「ペルソナ」という言葉のほうばかりが先走ってしま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
