ユーザーのフィードバックをどうサービスに反映させるべきか？（12の指針） | POP*POP
何かサービスをつくったときにはなるべくユーザーの声に耳を傾けたいものです。しかしながら闇雲にユーザーの声を取り入れているとわけがわからなくなってしまいます。 そこで今回はTara Huntさんのブログから「ユーザーのフィードバックをサービスに反映させるときの12の指針」をご紹介します。Taraさんは画像認識ベンチャーのRiyaにもかかわっていらっしゃったようですね。 どういったフィードバックを反映させるべきで、どういったものは反映させるべきではないのでしょうか。サービスの開発をされている方にはかなり参考になるのでは・・・では以下よりどうぞ。 上級者ユーザーの意見は聞くべきだが、（あまり）反映すべきではない。 上級者のためにサービスを設計すると普通の人が使えなくなります。そして普通のユーザーの方が上級者ユーザーよりずっと多いことを知るべきです。 普通のユーザーは何が欲しいのか教えてくれない。
最悪の事故が起こるまで人は何をしていたのか
飛行船墜落や原発事故、ビル倒壊など50あまりの事例を紹介。誰がどのように引き起こしたか、食い止めたか、人的要因とメカニズムをドキュメンタリータッチで描く。 もちろん、大惨事を引き起こした事故の「情報」だけなら、失敗知識データベース[参照]を見ればよい。本書とほぼ同じネタは得られる。しかし、著者が現場を見、生き残った関係者にインタビューしてたどり着いた「知見」や「生きた教訓」は、本書から掘り起こすべし。 「そんな大惨事を起こすような巨大システムに関わってないよ」という人には、もっと身近なやつをどうぞ → 「なぜAT車のアクセルとブレーキの踏み間違いが起きるのか?」あるいは「飛行機事故から生還するため、乗ったら最初に確認すること」は、立ち読みでもいいので押さえておこう（後者は目からウロコだった）。 システム開発屋であるわたしの場合とは、比較しようがない。わたしが携わるシステムが止まっても、新聞
いまさら聞けない 形式手法入門（1/3） ― ＠IT
IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第50回は、イタリア発のRTOS「BeRTOS」を紹介する。
「科目履修管理」のレファレンスモデルが登場 - 設計者の発言
教育関係者に朗報である。四年制大学向けの履修管理システムの基本設計情報「ＣＯＮＣＥＰＴＷＡＲＥ／科目履修管理」が、この夏に公開される。同時期に出版する本（システム設計の練習用問題集みたいなもの）で扱われている業務要件にもとづく連動企画である。３年前に書いた「上流工程入門」では、基本設計書の一部を図版として示すだけだったが、今回は無償のモデリングツール「ＸＥＡＤ」で閲覧・編集できる設計コンテンツとして誰でもダウンロードできるようになる。大進歩である。 システムの規模としては、テーブル数２０、機能単位数４０程度と小さめだ。「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」のテーブル数８０、機能単位数２７０と比べると、その小ささがよくわかる。しかも、「財務管理」は簿記の知識がない人にはチンプンカンプンだろうが、「科目履修管理」は業務としてわかりやすい（かといって単純すぎるわけではない）。 その本には「科目履修
分裂勘違い君劇場 - エンジニアがUIデザインしたがる本当の理由
ハイライトピックアップ Web2.0を引き起こしているのと同じ時代の潮流が、エンジニアの地位の低下を引き起し、エンジニアがUIデザインをしたがる動機を創り出している。 Googleは、「エンジニアの会社」という皮をかぶった「企画・マーケティング・デザイン」の会社である。 エンジニアよりデザイン能力の低いダメデザイナーがうじゃうじゃでてくる構造。 優秀な人ならデザインスキルがなくてもいいデザインができるのは幻想。現実には、デザインスキルの差は容易には超えられない壁。 デザイナーに必要な技術的知識とエンジニアの技術的知識は別物なので、エンジニアの技術力はデザインをする上でそれほど強みにならない。したがって、技術力とデザイン力を兼ね備えた優秀なデザイナーはエンジニアとデザイナーのハイブリッドではない。 一人の人間がUIのデザインと実装を両方やると二兎を追うものになってUIの質が低下する。二兎を追
分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由
それから、これは個人的な意見ですが、プログラマはコンピューターの扱いになれているから、そうでない人が使うためのインタフェースを設計することができない、みたいな話をときどき耳にしますが、僕はそれに懐疑的です。インタフェースをうまく設計できない人というのはプログラマに限った話じゃない。それは「プログラマは営業ができない」と乱暴にまとめてしまうのと同じようなこと。 たぶん、プログラムができるかできないかということと、インタフェースをうまく設計できるかできないかというのはあんまり相関がないように思います。むしろコンピュータの世界では、プログラマは頭のなかで思い描いたインタフェースを実現する手段を最も良く知っている部類の人で、インタフェースを作るセンスさえ持ち得れば、それ作るのにもっとも適した人たちなんじゃないかと思います。 知り合いの会社では、半期ごとだかクオーターごとだかに、その期に、もっとも優
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
