UXデザインのコンサルティングではよく品質優先度マッピングというものを行います。これは開発プロジェクトの上流工程において、実装を検討している機能をリストアップし、そのひとつひとつについて想定する利用者の割合や利用頻度の観点からグルーピングし、実装の優先度を決める作業です。 これを行う目的は、UIをできるだけシンプルに保つことにあります。ユーザーが求める機能をすべて盛り込むと、当然UIは複雑になり、誰にとっても使いにくいものになります。また蓋然性のバランスが取れていない要件はプログラムを複雑にし、バグが増える原因になります。 UIデザインにおけるパレートの法則（結果の大部分は全体の一部によって生み出される）は、「ユーザーの80%は全機能の20%しか使わない」というものです。その20%に注力し他の優先度を下げることで、製品の利便性は向上するはずです。 Core, Important, Nice

現在のインターネットの基本をなしているIPv4というプロトコルには、広く知られた大きな欠点がある。パケットのアドレスフィールドの幅が32ビットなので、ネットワークに接続可能なホスト数の上限が2³²（約43億）になってしまっているのだ。その欠点を修正するために、1990年代後半にIPv6という新たなプロトコルが設計されたのだけど、いまだにインターネットではIPv6は少数派で、主流ではいまだにIPv4が使われている。 1990年代当時は、IPv6は規格を策定すれば比較的すぐに普及するはずで、それによってインターネットが抱えているアドレス枯渇の問題が解決されるという雰囲気だったように思う。1998年にタイムトラベルして、20年たってもまだIPv4を置き換えることに成功していないと当時の人のIPv6推進者たちに教えたら、多分すごくびっくりされるだろう。一体どうしてこんなに普及が遅れてしまったのだろ

できる犬さんMarkdownエディタを一人で作りながらフリーランスをしています。今月(11月)の売上は18万円を超えました。順調に伸びていて嬉しい。毎日楽しいです。 個人開発はスピードが全てです。残業代もがんばった賞も出ないからです。一人何役もこなさないといけないので、作業のスイッチングコストが常につきまといます。設計してコードを書いてユーザサポートをしてマーケティングして・・。ましてや本業などがあると、プロジェクト単位で脳を切り替える必要もあります。 プロになってから約8年、常に本業と並行して何かしらの個人開発を続けて来ました。そして、このスイッチングコストをどうすれば最小限に抑えられるかという課題と向き合ってきました。自分で言うのも何ですがかなり速いと思います。例えば、先日ユーザさんから機能要望を受けたのですが、書き込みを見て２時間で対応してリリースしました。そしたらユーザさんが「速す

Takuya Digital crafts(man|dog). Love photography. Always making otherwise sleeping. born in 1984. この記事は前回のつづきで、「Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application」という本を紹介する。 著者は37signals社という、BasecampやRuby on Railsを開発した有名な会社。 無料で日本語訳版が読めるのでぜひ。 前回は次のような教訓について紹介した： 自分が欲しいと思ったものを作れ 「より少ない」ことは良いこと 機能要望は忘れろ 引き続き同著にて個人的に重要だと思った気付きを紹介していく。 ※引用項は、特に断りのない限り同著からのものとする。 リーダーを追

Takuya Digital crafts(man|dog). Love photography. Always making otherwise sleeping. born in 1984. 今回は「Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application」という本を紹介したい。 これは2011年に発売された、ウェブアプリを成功させるための方法論の本。 37signals社という、BasecampやRuby on Railsを開発した有名な会社が書いた。 5年前の本とはいえ、技術依存の話はほとんど無いので現在でも充分すぎるほど通用する内容。 この本を読んで、特に共感したり大事だと思った箇所を紹介する。 ※引用項は、特に断りのない限り同著からのものとする。 タダで手に入る 残念な