Alfred力高め隊

雑記

最近、@ruedap さんが神ワークフローを作ったのを見て、これが使いたくてAlfredの1から Alfred 2に乗り換えてPowerPackにお布施した。
Font Awesomeのアイコンフォントを検索できるAlfred 2のWorkflowを作ってみた

その時点で、１日平均 15回程度の使用というお粗末なアルフレッド力だったのだけど、お布施もしたことだし、Alfred力を上げてやろうと思って、全てのアプリ切り替えをAlfred力経由でやることにして鍛えることにした。
普段はWitch に ⌘ + Tab を割り当ててて、アプリ切り替えにはそっちを使ってしまうことが多いのだけど（これはこれで便利）、気づくと⌘ + Tabを連打して次のアプリを探してしまってることが多くて、なんだかなあという感じがあったので、ここはキー一発でAlfredで切り替えられた方がカッコイイ気がする。
で、2〜3日修行した結果…アルフレッド力はちょっと高まった！ ヾ(*'ω'*)ﾉﾞ

1日平均190.6回。前と比べるとかなりの進歩である。もう、ふとしたときに⌘ + Tabを押すことがなくなった。JISキーボードからUSキーボードに乗り換えたときも思ったけど、こういった瞬時に押すキーの違いとかは、2〜3日気をつけてるとだいぶ慣れますね。（でもVimは慣れるのに1ヶ月くらいかかった。）
アプリ切り替えにAlfred使うようにしてみてもう一つ思ったのは、ホットキー押した時に瞬時に次の動作のイメージが頭のなかで明確になってないと素早い使い方が出来ない時があり、脳みその回転があまりよろしくない私は、Alfredを立ち上げたまま、何秒か、えっと。。。みたいに固まってしまう時がたまにある。というか、よくある。⌘ + Tabだとその辺、UI上に選択肢が羅列されているので、⌘ + Tabを連打してるうちに視覚的な補助が手伝って次にやることを思い出せたりする。初期状態ではレコメンド的な補助がないのがCUI同様、コマンドランチャーの欠点かなあとも思うが、しかし頭の回転が良く脳のクロック数が高い感じの人はそれだけ、コマンドランチャーを効率よく使えそうだなあと思った。アルフレッド王、すごく頭の性能良さそう。

これがアルフレッド王のアルフレッド力だ… 1日平均651.4回！！日本一なのでは……とても追いつける気がしない。というかグラフよく見ると1日3000回くらいAlfredしてる日があってヤバい。人間の手にそんなことが可能なのだろうかと思うレベルだ。

Alfred Hotkey アンケートをしてみた

というか、現在過去に渡ってTLで見かけた事のあるAlfred のHotkeyを集計した結果、今のところこうなった。

  • control + space ×5
  • option + space ×3
  • ⌘ + ; ×3
  • double control ×1
  • ⌘ + space ×1
  • ⌘ + _ ×1

※ 新しい情報が入り次第随時更新中

私は⌘ + ; なんだけど、押しやすくて他ともかぶらずかなり気に入ってる。
アンケートは引き続き募集中です。

Slimでセレクタを追加するときの書き方、及び Middleman の素晴らしさ。

Slim Ruby Middleman

よく、要素につけるidやclassを動的にしたい時とかに、Hamlだとこんな感じの書き方をする



%li{class: "item #{item.name}"}
この書き方がSlimだとダメっぽくてつまずいた。
Slimだとこんな感じの書き方になるらしい


li[class="item #{item.name}"]
こういうのもいけるっぽい。割と素のHTMLに近い感じで書けるのですね。


li class="item #{item.name}"
そして条件つけるとこうなるっぽい


li class=(if item.present? ? "#{item.name}" : 'no-item')

li class=("#{item.name}" if item.present?)
classを複数付け、かつ1つのclassにのみ条件を付加する場合はこのように入れ子にすればよいみたい。


li class="item #{if item.present? ? "#{item.name}" : 'no-item'}"

li class="item #{"#{item.name}" if item.present?}"

Slim + Middleman で静的サイト作ってみたのけど、MiddlemanはコンテンツをYamlに置いて外部化して、簡易CMSっぽいものを作るのがとても簡単で驚いている。これにより、コンテンツとテンプレートをキレイに分離できる。静的サイトなのに、工夫次第で一切類似要素をコピペせずにDRYに作れるのがとても素晴らしい。RailsのActionView::Helpers（に似たようなの ※追記参照）も使えるし、SassもHamlもCompassもCoffeeScriptもすぐに使える。middleman buildってコマンド打つだけでhtmlの静的サイト一式をガガーっと一瞬で吐き出してくれるし、書きだすサイトのリンクや画像などのアセットが相対パスなのか絶対パスなのかも設定で用意されてて、configに一行書くだけで変えられる。必要に応じてzip納品可能なサイト一式もbuildですぐに吐き出せもすれば、Herokuとかにデプロイもできるのだ。
Middlemanはまさしく常日頃からこういうの欲しいなーと思ってたそのものだった。怠けたいWebデザイナーにとってのライフチェンジングだ。
Slim も初めて書いたけど、これもシンプルで見た目キレイで良いですね。Hamlと対して違わないので、HamlやJadeに慣れた人なら、 群馬の Middleman + Slim エヴァンジェリストである @yterajima さんのこれとか読めば5分で書けるようになる。|（パイプ）を使った表記にだけ最初少し慣れなかったけど、これもよく出来ていて、視覚的にも縦棒が入ることによって階層構造がわかりやすくなるのがカッコイイ。
しかし、Middlemanもそうですけど、Sassやその周辺といい、HamlやSlimといい、Ruby周りは、全部コマンドラインが必要であるという入り口の障壁以外は、とことんデザイナーにとって優しく思いやりのある環境なのではないか？…と思ったけど、これおそらく別にデザイナーのためにってわけでもなくて、HTMLとかCSSとかを触るはめになったプログラマ達が、あまりの効率の悪さへの苦痛から、なんとかこれをアレしてやろうとアレした結果なのだろうと思った。彼らのコピペに対する憎しみが世界を良りよい場所へと変えているのだ。感動的であり、大変ありがたい。
おかげさまで、そろそろ素のHTMLとかもう書かないでも生きていけるような気がしてきたので、とてもうれしい。とてもうれしいです。

#追記
ご指摘いただきました。そうか、ActionView::Helpers そのものではなくて、それに似せて作られたヘルパーが使えるということですね。言われてみればそうだよなあ。。
今は padrino-helpers と sprockets-helpers の併用らしい。ありがとうございました！

# 追記その2
メモ程度に書いたものが思ったよりも人に読まれてしまい照れている。。ものを書くのがこんなに辛いのにどうしてメモ程度のものなら書けるんだろうか…そしてそういうものほどたまに読まれたりするのなぜなんだろう（ありがたいけど）。
そうそう、Middleman他にもいい所ありすぎて書ききれないのだけど、自分のようなプログラミング素人が、Railsほど難しくなく、普段の仕事の静的サイト作りとかの中で、比較的気軽にプログラミングっぽい気分の断片を味わえるのも、すごく良いところの一つだと思う。私はほんのちょっとしかやったことがないのでわからないのだけど、Middleman のベースである Sinatra がそもそもそういう感じなのかもしれない。
先日の初心者はRailsから入るべきでないという盛り上がった話題を思い出す。自分も素人Railsやってて確かにわけわからんこと多くて難しいし（でも半分趣味だしやってておもしろいしまあいいのではとも思ってるから辞めはしない、Rails好きだし。）、プログラミング覚えたいデザイナーやマークアッパーにもし最初の一歩として何か勧めるなら 今は Middleman かもなーって思った。普通に自分の仕事の範囲内で、無理も危険もあまりなくプログラミングのエッセンスが味わえるし、結果的に普段の仕事も楽になるんだから一石二鳥で素晴らしい。こういうの欲しかった！ってきっと思えると思う。データとビューを分割することの意義も身近な所で実感できそうだ。ViewだけならかなりRailsに近い要素あるし、Middlemanを経てRailsっていうのは良さそう。納得だ。日本語ドキュメントも @yterajima さんの尽力のおかげでかなり充実しており、そんなに困ることがなかった。
なんかそのうち、デザイナー（っていうか自分）が静的サイトのワークフローをさらに楽にこなすための Middleman のカスタムフレームワーク 的なものとかを作ってみたい気もしてきた。そのうち、そのうち。。

第25回 #p4d 参加した

Ruby on Rails

http://connpass.com/event/2907/

もう25回なのだなあ。。。すごい
前回の続き。ほにゃタルトラッカーの簡易版的なものをRailsで作ってる。お陰様で今回も実り多く、今日書かないと色々忘れそう・・・

便利Gemを入れる

better_errors

エラーの画面がかっこ良くなる
https://github.com/charliesome/better_errors

binding_of_caller

かっこ良くなったエラー画面にフォームが出て、そこからデバッグとかできる（便利〜
https://github.com/banister/binding_of_caller

group :development, :test do
  gem 'better_errors'
  gem 'binding_of_caller'
end

Iteration をどう作るか？

前回作ったthis_iterationメソッド（taskをdoneにした時の週のはじまりとstart_dateと一致するiterationと紐付ける）

app/controllers/tasks_controller.rb

def index
  @this_iteration = Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first

これだと、該当するイテレーションがない場合に例外になってしまう
.first_or_create ってやると「該当するIterationがなかったら作る」ってできるらしい
↓

def index
  @this_iteration = Iteration.where(start_date: Time.now.in_time_zone.beginning_of_week.to_date).first_or_create
Iteration、将来的に、未来1ヶ月分くらいまで必要なので、今日から数えて4週間先の分まで作ることを考える

1週間先のIterationのstart_dateはこう書ける（つまり、今日より1週間後の日が該当する週の月曜日）

i.start_date = Time.now + 1.week.in_time_zone.beginning_of_week.to_date

4週間先のIterationのstart_dateはこうなる

i.start_date = Time.now + 4.week.in_time_zone.beginning_of_week.to_date
未来のIterationまで作れるメソッドをモデルに作っておくとよい

app/models/iteration.rb

def self.for_week(w=0)
  self.where(start_date: (Time.now + w.week).in_time_zone.beginning_of_week.to_date, end_date: (Time.now + w.week).in_time_zone.end_of_week.to_date).first_or_create
end

※ここでいうself は Iteration自身

一行長くて見づらいので改行する

def self.for_week(w=0)
  self.where(start_date: (Time.now + w.week).in_time_zone.beginning_of_week.to_date)
    .where(end_date: (Time.now + w.week).in_time_zone.end_of_week.to_date)
    .first_or_create
end

さらに（Time.now + w.week）で同じ事書いてる！DRYじゃないヽ(`Д´)ﾉので、変数にまとめるか

def self.for_week(w=0)
  time = Time.now + w.week
  self.where(start_date: time.in_time_zone.beginning_of_week.to_date
    .where(end_date: time.in_time_zone.beginning_of_week.to_date)
    .first_or_create
end

そして、controllerの@this_iteration メソッドでこの for_week を使う
app/controllers/tasks_controller.rb

  @this_iteration = Iteration.for_week

console で for_week が動くかどうかためしてみる

現状存在するIterationの数を確認
irb(main):003:0> Iteration.count
   (0.2ms)  SELECT COUNT(*) FROM "iterations" 
=> 2
Iteration.for_week(1) （つまり来週のIteration）
irb(main):004:0> Iteration.for_week(1)
  Iteration Load (0.1ms)  SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-22' AND "iterations"."end_date" = '2013-07-28' LIMIT 1
   (0.1ms)  begin transaction
  SQL (0.5ms)  INSERT INTO "iterations" ("created_at", "end_date", "start_date", "updated_at") VALUES (?, ?, ?, ?)  [["created_at", Thu, 18 Jul 2013 17:41:03 UTC +00:00], ["end_date", Sun, 28 Jul 2013], ["start_date", Mon, 22 Jul 2013], ["updated_at", Thu, 18 Jul 2013 17:41:03 UTC +00:00]]
   (0.6ms)  commit transaction
=> #<Iteration id: 5, start_date: "2013-07-22", end_date: "2013-07-28", created_at: "2013-07-18 17:41:03", updated_at: "2013-07-18 17:41:03">

07/22〜07/28 まで -> このIterationはなかったので新しく作られてINSERTされた

Iteration.for_week(2) （つまり再来週のIteration）
irb(main):005:0> Iteration.for_week(2)
  Iteration Load (0.2ms)  SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-29' AND "iterations"."end_date" = '2013-08-04' LIMIT 1
   (0.1ms)  begin transaction
  SQL (0.5ms)  INSERT INTO "iterations" ("created_at", "end_date", "start_date", "updated_at") VALUES (?, ?, ?, ?)  [["created_at", Thu, 18 Jul 2013 17:41:37 UTC +00:00], ["end_date", Sun, 04 Aug 2013], ["start_date", Mon, 29 Jul 2013], ["updated_at", Thu, 18 Jul 2013 17:41:37 UTC +00:00]]
   (6.7ms)  commit transaction
=> #<Iteration id: 6, start_date: "2013-07-29", end_date: "2013-08-04", created_at: "2013-07-18 17:41:37", updated_at: "2013-07-18 17:41:37">

07/29〜8/4 まで -> このIterationもなかったので新しく作られてINSERTされた

Iteration.for_week(0) （じゃ、今週は？）
irb(main):006:0> Iteration.for_week(0)
  Iteration Load (0.2ms)  SELECT "iterations".* FROM "iterations" WHERE "iterations"."start_date" = '2013-07-15' AND "iterations"."end_date" = '2013-07-21' LIMIT 1
=> #<Iteration id: 4, start_date: "2013-07-15", end_date: "2013-07-21", created_at: "2013-07-18 11:25:37", updated_at: "2013-07-18 11:25:37">

07/15〜07/21 まで このIterationはすでにあったので、INSERTされない

ここでIterationの数を再確認
irb(main):007:0> Iteration.count
   (0.2ms)  SELECT COUNT(*) FROM "iterations" 
=> 4

最初2つでその後2つ作られたので合計4つ。あってる

そんなわけで、for_week で、該当するIterationがなかった場合は新規に作れ、かつ未来の分まで作れることが確認できた。

sandbox
rails c --sandbox

ってやると、ここでやったものはDBに残らないので、素振りに最適

exit

rails c、抜けるときはexit （ずっと control + d 使ってた）

Heroku にpushする前に、assets:precompile しないとassetsの変更が反映されない問題

Sassのimportの仕方が悪い

今まで
applicaiton.css にこう書いて

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require basic
*/

basic.sass で 各Sassファイルを順番にimportしてた

@charset "utf-8"

@import compass/reset
@import compass/utilities
@import compass/css3
@import font-awesome
@import font-awesome-ie7

@import variables
@import mixin
@import style

これを application.css.sass にして普通にimportすれば、require とかなくてもいけるらしい
application.css.sass

@charset "utf-8"

@import compass/reset
@import compass/utilities
@import compass/css3
@import font-awesome
@import font-awesome-ie7

@import variables
@import mixin
@import style
  • ほんで、今まで使ってた application.css と basic.sass は削除
  • そして public/assets 配下のファイルを全削除
  • .gitignore に public/assets を追加

これでpublic/assets なしでもSassをちゃんと順番に読むようになったので解決したっぽい

感想とか

  • 今回は久しぶりにP4Dにいらした @ppworks さんにとてもわかりやすく教えていただいて、ありがとうございました m(__)m
  • DRY、同じ事繰り返して書いちゃった時にこれアカンと思う感覚が大事なのだなあ。
  • modelにメソッド書くと色々汎用的に使えてステキなのだな。（なんでもviewでやろうとしてしまうのをやめたい。。
  • また教えてもらうばかりになってしまった・・・Sassの話とかは全然できず、すいません。。途中で時間を区切った方が良さそう。
  • エラー画面がかっこ良くなって、さらにデバッグもできるようになって感激だ！
  • 焼きそばナポリ味は粉チーズかけるとうまい。
  • GitHubの鍵のトラブルに見舞われたが、いつの間にか鍵のファイルの中身が消えてしまってたので、鍵を同じ名前で作りなおしたら解決した。鍵こわい。

7月7日ってことで、iOS 7 のこと

design iPhone

珍しく文章を書く意欲が出る期間に突入してる感じがしているので、色々書く練習も兼ねて軽いことでも書くようにしていこうかなあと思う。
で、奇しくも7月7日ってことで、ちょっと話題の旬は過ぎたけど、iOS 7 のこと。自分で触ったことはない。色んな意味で気になりすぎてデベロッパー課金しようかなあと思ったけどしてない。触ったこともないのに評価を下すべきではないので、アレはイケてるとかイケてないとかそういうことを言うつもりはないのだが、触ったことがなくてデベロッパー登録してないからこそ、NDAとか気にしないで色々言えるというメリット（？ もありそうってことで、今気になってることを書いておこうと思う。後にそれを自分で読んでどう思うのかなあっていうのも気になる。

iOS 7 ってアレでしょ？


（映画 『アバター』 より）
スクリーンの中に深度のある擬似空間とレイヤー構造を作った、ってことでこれどういう世界観なのかなあと考えて、思い浮かべたのがコレ。映画とかでよく見る、空中にタッチインターフェイスのついた複数のスクリーンを映し出し、ひょいひょいのひょいと指先で操作できるアレ。
iOS 7 ではこの世界をiPhoneの筐体のスクリーンの向こう側に作り出した。今は技術的な限界で筐体の中でしか実現できないけど、いずれこの世界観は筐体の中を飛び出して、実世界空間の中でこのOSの操作が実現できるはず。空間の中に現れる平面スクリーンなので、そのレイヤー自体に奥行きがある表現を加えるのはおかしい、だからそのレイヤーの中身は徹底してz軸を排除したフラットUI。
っていう邪推が正しいのかどうかわからないけど、自分的にはそう考えた時にあの落とし込みに対して納得が行った。

デザイナーズマンションみたいな感じ

iOS 7 のグラフィック表現は、モダニズム的なミニマルな表現に寄っている。立体空間に例えるならモダンなデザイナーズマンションのような感じに似てる。アレね、アレも住んだことないから知らないけど、まあおそらくイイカンジに住むの難しいんですよ。もうオシャレで教養のある人しかうまく住めない。似合う家具は限られる。いつも掃除してないといけない。モノ置き過ぎても台無し。シンプルだから懐が深いかというとそうでもなくて、逆にあの手のミニマリズムはすごく制約が厳しいし、シンプルで計算されているがゆえに空間の中でそれが主役のような存在感を発揮する。自らのオシャレの成立のために周囲の全てが存在するような、わりとそういう緊張感のある振る舞いを周囲に強いる感じの性質がある。逆に言えば、その空間に置いたら空間ごと台無しにしかねないものが世の中にたくさんあり、台無しビリティが非常に高い。
OSは色んなアプリを包括するプラットフォームなので、主役はどっちかというとサードパーティのアプリやコンテンツという認識でいるのだけど、アレで行くとOSのデザインが、アプリやコンテンツのデザインにかなり影響を与えそうで、それが吉と出るのか凶と出るのかわからない。みんながみんな、オシャレなデザイナーズマンションに住むことを好まないように、どのアプリもああいう感じのデザインになるというのはちょっと考えにくいのだけど、デザイナーズマンションに仏壇置いたら変なように、あのUIと違和感なく共存できるアプリやコンテンツが割と多くはなさそうな感じが気になる。

メタファーは古いものへの歩み寄り

iOS 7 の発表をタイムライン越しに見てて、何人かの人が「自分の親には勧めにくくなった」と言ってたのが印象的だった。ミニマルな表現は割とどんな分野でも受け手に深いレベルの理解を強いる。
行き過ぎたスキューモが無意味だよねっていうのは共感する。これまでのiOSの、「え、それ、そこ皮テクスチャじゃなくてもよくね？」みたいなのはすごくあるんだけど、今までのリアルでの習慣をなぞって、似たような見た目をスクリーンの中で再現する（紙に似た使い方をするものには、紙に似た表現を使うとか、押すべきところにはボタンっぽい凹凸を施すみたいなの）というアプローチは、やはりそれなりの効果があり、iPhoneがここまで多くの人に使われた一因にはなってたのだろうなと思う。
スキューモフィズムや各種のメタファーが醸成するアナロジーは、深く理解していないユーザーに対する思いやりであり歩み寄りだ。今まで慣れ親しんだアレと同じようにすれば、「とりあえず使える」。対象に対する本質的な理解や、慣れ親しみがなくても、とりあえず今までの経験をなぞればいいようになっている。
電子メール、電子書籍、電子マネー…どれもスキューモ的なネーミングだと思う。初めて新しい手段に接する人に対しては、今までの習慣をメタファーにして表現することでしか、うまい説明ができない。そして未だに、それらの表現が幅をきかせてる。（新しい概念が新しい言葉として広く定着したのはググるとか、ツイートするとかぐらいしか思いつくものがない。あ、マイミクとかもそうかな。）電子メールも従来の手紙とはだいぶできることが異なるし、電子書籍、電子マネーもそうだ。これらの古くさい呼び方、表現が新しい概念の新しい可能性を阻害している一面があることも否めないけれども、結局そういった表現が、今の時代に新しい概念を「広める」には一番効率がいいってことで、今の現状があるのだろう。

そういう時代なのかもしれない

そんなわけで、今までに見聞きした情報の範囲内で本音を言うと、「理念はわかるけれど、ちょっと早くないっすかね・・・？」っていうのが正直な感想になってしまう。いや、Disってるわけではなくて、逆にむしろそういう感想しか持てなかった自分自身が割と残念で老害感あってかなしい。
一方で、タッチインターフェイスはもう導入〜普及フェーズを過ぎて、これからはそれを日常の中に当たり前に存在するものとして発展させていく時期だという見解がしかるところにあって、だからもう変なメタファーいらんだろっていうことになって、回りまわって結果的にわーいフラットUI、フラットUIみたいな流れになってるんだろうねえっていうのも理解はできる。いずれにしても、Windowsしかり、Google、Androidしかり、この時期に色んな所から似たようなアプローチが出てくるというのは、深い意味がありそうだ。プラットフォーマーではないいち小作農としては、うだうだ言ってないでこの流れにどううまいこと乗ってくか、しかないよなあ。
そもそも、iPhoneが出た時も割と初期に入手したのだけども、その時も「自分は好きだしスゴイと思うけど、これ普及すんのかねえ？」っていう感想だったので、自分のこの手の感覚はまるで信用出来ない。
いやー、どうなるのかねえ。とりあえず iOS 7 がとても気になってしまう今日このごろです。

# 追記 1
パルスのファルシのルシがパージでコクーン…？？？とか CUI（黒い画面）が怖い…とかも、アナロジー不足による親しみ辛さという点では似たような感じがある事例かも、と思った。
# 追記 2
TwitterやGoogleが新しい動詞を生んだのに対し、Facebookはあれだけ普及してるにもかかわらず（だからこそ？）、言葉の表現に関しては割と保守的な感じを受けるのがなんか面白いと思った。

他人の「制約」を知るのは結構面白い

design

エンジニアが作るネットサービスのアイデアがしょぼいワケ【連載:えふしん】 - エンジニアtype
これ読んだのをきっかけに思った、というか、えふしんさんの書いてらっしゃることとはだいぶズレる内容なので、結局あんまり関係ないんだけど。
エンジニアさんだけではなくて、営業さんとかお客さんとかでもみんなそうなんだけど、自分と違う職域の人と一緒に何かを作っていると、やっぱりそれぞれの立場に応じた発想の「制約」があることに気づく。で、その他人の発想の「制約」を知るという作業が、自分は結構好き。
発想の制約というのは基本、何か理由がないと生まれないわけで、よくよく話を聞いて考えてみると非常に理にかなっていてよくできた必然であることも多い。例えば、エンジニアさんがあまり良い反応をしないようなシステム的に嫌な負荷がかかるUIや仕様は、よくよく考えると人間（ユーザー）にとっても実はあまりメリットがない体験である事も多くて、エンジニアさん達の考え方を受けて考えなおすと、より良いもの（ユーザーもうれしいし、システム的にもイケてるもの）になったりすることがたびたびあって、そういうのはすごく面白い。自分もまたデザイナー特有の発想の制約（一般化は好きじゃないけど・・・）に囚われながら何かを考えたりするんだけど、それが全く違う考え方をする人の制約を取り入れることで、自分の発想にはない、より良い「必然」に辿り着ける可能性があるなあと思う。そういうのが、自分と違う職域の人と何かを作る面白さだと思う。
もちろん、他人の発想の制約について知るときには、相手の考えに対してそれは「なぜ？」と思ったらその都度突っ込んで聞くようにしないといけないし、相手が、なぜ、どういう目的で、どういう背景で、どういう思想や習慣で、そう考えているのかということを自分にも理解できるように説明してくれるのが前提になる（他のイケてるサービスがこうしてるから、誰々がこう言ってたから…とかじゃなくてね）。
もちろん単純に、目的に対して邪魔になっていて無理してでも取っ払った方がよいような制約もあるし、この制約がちゃんと目的に対して意味を持ちうるものなのかどうか？「必然」に化けるかどうか？ イケてる「制約」を見定める選球眼みたいなのを磨くのが重要なのだろう。
自由度高すぎるゲームとかが必ずしも面白くないように、制約が全くない世界もまたつまらない。「制約」を「必然」に変えるような感じの作業ができた時は結構うれしい。

# （追記）
で、もちろんのこと自分が何かする時も、その理由を他の人にもわかるようにちゃんと説明しないといけない。その作業をすると、自分の中でなんとなくやってる感じのことが減って、色々整理されて筋道が立つし、それを受けてもっと良いアイデアが他の人にもらえることもあってとても良い。