さっきのエントリもそうだけど、今更だけど、私はスルー力が足りない気がする。
社内で新サービスの企画をしている際や、デザインをしている際なども、良くも悪くも、人のすることにかなり細かい所まで口を出してしまう。
あまりこの性格を直すつもりはないのだが、せめて、自分が口を出された時は最後までそれに付き合いたいと思ってる。
カテゴリー: Private
「マウスオーバーでリンク先のサムネイルを表示」 は導入してほしくない
ずっと以前から定期的に取り上げられている話題ですが、同種のサービスの提供側としては非常に悩ましい、というか心苦しい話題です。
http://d.hatena.ne.jp/kanose/20080403/mouseoverthumbnail
http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/kanose/20080403/mouseoverthumbnail
はてなのコミュニティのように IT リテラシが比較的高く、かつ進んでウェブ上での情報収集を日々されているような方々にとっては、余計に邪魔に感じることがあるのではないかと思いますし、私もその気持ちは （個人によって程度の差はあると思いますが） 分かります。
ただ、一方で、適用範囲を制限する等された上で、ここまでなら邪魔にならないだろうという個人の判断で、サイトのアクセントとして楽しんで利用されている方もいるので、、、なかなか提供の中止とまでは思い切れない。特に女性の方々のサイトでは、非常に可愛い使い方をされているケースがよくありますし、全ての使い方が否定されるべきとは私自身思っていません。
なので、提供側でも色々と改善策を模索していますが （Snap Shots とかはよりセマンティックな方向へ進化させようと頑張っていますね）、読む側と読まれる側が話し合って、個別のケースとして一番良い形を模索していく、というのも一つの解決策になるのではないかと思います。（上記のエントリがそのきっかけになるかもしれないですね。）
ハートレイルズはこのサービスで収入を得ているわけではないので、改善策を模索する一方で、後は成り行きに任せるというスタンスです。利用を過度に促すこともなければ、利用の中止を促すこともないと思います。
＜追記＞
表示を無効にされたい方は下記のページで無効にできますので、どうぞご利用ください。
（無効にするボタンを押したあと、リロードする必要のある場合があります。）
http://glance.heartrails.com/switch.html
また、チラ見機能の適用サイトの運営者様に向けて、ON/OFF を制御するボタンの提供もしていますので、詳しくは Glance のトップページをご覧ください。
ネット権
ここの部分を何とかしないと、ニコニコ動画のようなイノベイティブな新規参入が今後より起こりづらくなる気がする。
LifeHack
実のところ、私はいわゆる LifeHack とか、仕事術とかいうものに全く興味がない。仕事を効率的に進めるノウハウは確かに存在するし、そういうものを否定しているわけではないが、アレが良いコレが良いと移り気に試しては自分にフィットするものを探し続けるのは、度が過ぎると無意味、というか時間の無駄だと思う。
開発者に求められるのは、極論すればスピードとクオリティだけだと考えて良い。そして、これらの向上に LifeHack が寄与できる割合はかなり小さいと思う。思考方法や経験、経験、経験こそが上達への最善の近道なので、自分の納得できる環境を一通り整えたら、後はものづくりに没頭する方が良い。
http://www.milkstand.net/fsgarage/archives/001188.html
http://b.hatena.ne.jp/entry/http://anond.hatelabo.jp/20080308103530
http://d.hatena.ne.jp/core/20080309/1205074455
何というか、結局のところ、本当に身に付くということは、目に見えないものなのだ。ツールが、とか、資格が、とか、TOEIC の点数が、とか、全て価値のあるものではあるけれど、それらはあくまで手段なので、目的にしてはいけない。特に、若いうちは本質的なことを経験、吸収していくのに最適な時期なので、上辺のことばかりに気を取られるのは人生の損失と言っても大げさではないと思う。
とはいえ、私はかなり極端に自己流を貫いている方なので、信用ならないかもしれないが。一応、自分が快適に感じられる程度の開発環境は整えた方が良いよ、と付け加えておく。
PS.
今日会社で、モチベーションを UP させる薬があると面白い、みたいな話になった。
開発者用バイアグラみたいなやつ。既にあるのかもしれないけど。
仕事人間
面白いので kwout してみる。
ZEROBASE さんはベンチャーではないとのことだから良いのだろうが、ベンチャーの社長がこういう発言をすると採用活動に影響が出る気がする。DQN 企業と紙一重というか。
いずれにせよ、まだ産まれたばかりの企業は何かあればあっけなく死ぬ。また、特にベンチャーには多いと思うが、予めこのタイミングまでに成功できなければ解散する、と決めている企業にとっては、時間はある意味で命よりも大切なものだ。大げさに言えば、バカンスを取る、という行為は、会社の寿命のロウソクに自ら息を吹きかけるのに等しい。（それでロウソクの火が消えるかどうかは分からないが。）
ハートレイルズは、仕事人間しか雇わない、とまでは言わないが、仕事をしていない時間の意味を正しく認識できる人、その積み重ねによって生じた結果を素直に受け止められる人、そういう人でないと雇えないと思う。
ウェブ業界以外からのスタート
私は昔、全世界で社員ウン万人のそこそこ大きな規模の会社で働いていて、C、C++、Java あたりを主に、（一部ウェブアプリもあったけど） スタンドアロンなソフトウェアの開発に携わっていた。開発プロセスもウォータフォールからアジャイル、RUP 等々、様々なプロジェクトを通じて、一通り実践してきたように思う。
また、担当は GUI や API の設計や開発であることが多かった。直接ユーザーの目に触れる部分の担当が多かったため、実際のユーザーを交えて詳細なユーザビリティテストを実施したり、ユーザーの前でプレゼンすることも比較的多かった気がする。
結局、若干の違いはあれど、昔してきたこと、開発プロセスやデザインプロセス、ものの考え方等は、今もそのまま役に立っている。（ものづくりとは直接関係ないけど、英語なんかも外資系に入ってなければやらなかっただろう。）
何が言いたいのかというと、大企業 （や大学） でソフトウェアの研究開発をしているような人が、もっとウェブ業界に入ってきたら良いのに、ということだ。特に、Getting Real みたいに当たり前のことを当たり前に書いている本を読んで羨ましいと感じる人は、ウェブ業界向けな気がする。相当フラストレーションが溜まっていると思うので、ぜひそれを （できればハートレイルズで） 爆発させてほしい。
私は大企業とベンチャー企業、大規模ソフトウェアと軽量なウェブサービス、両方経験してきたので良くも悪くもその違いが見える。違いが見えた上で、それらの本質には大差ないことが分かる。だから、今はウェブのことはあまり良く知らない、という場合でも、優れたソフトウェア開発者なら技術的な障壁はほとんどないので、どんどん （例えホリデープログラミングでも） ウェブ業界に参加してきてほしい。
少し話が脱線するが、ハートレイルズが特に採用したい人材は、上記のような生粋の開発者とフリーランサー、および、自発的なウェブ系ニートだ。逆に、毎日言われたことだけを淡々とこなすのが好きな人は、ハートレイルズには全く合わないと思う。
、、、とはいえ、参加してきてほしい、採用したい、とこんなブログで言っていても何も始まらないのは分かってる。結局、ハートレイルズ自身がもっと大きくなってサクセスストーリーを描くことが、ウェブ業界をより盛り上げることにつながると思うので、まずはそれを目指して地道に頑張りたい。
焦燥感
ものづくりは戦場
ブレインストーミングに批判が禁物なのは定石。だけど、それを詳細な仕様の落とし込みや開発プロセスにまで持ち込むのは間違いで、単なる馴れ合いだと思う。
前職では、アメリカ人と、ドイツ人と、インド人と、中国人と、日本の同僚と、批判し、批判され、時には感情的なしこりすら残りかねないほどの議論を繰り返してきた。まあ、単に若くて感情的になりやすかったというのはあると思うけど （今も多分に感情的なところはあると思うけど）、そういった議論を延々と繰り返していくうちに、まず、批判されることに慣れ、批判することに慣れ、そうした議論と感情を区別する術が身に付いてくる。良いものをみんなで作り上げることが唯一の目的であって、別に人格を批判してるわけじゃない。私が絶対正しいんだと言うつもりもない。そして、私だけでなくみんながそう思ってる。
ものづくりでは、それを任された責任者が最終的な判断をするべき。でもそれは、批判を受け入れ、積極的な議論を通じて良いものを作ろうとするプロセスを放棄することとは全く違う。責任者が受け入れるかどうかはともかく、少なくともおかしいと思った部分に関してはいくらでも指摘すべきだし、また、責任者にはその指摘をきちんと考える義務がある。
私もまだまだダメだなと反省する部分がたくさんあるけど、これからも、できるだけ批判することを恐れず、そして、批判されることを恐れない姿勢でいたい。
サービスをデザインする際の心掛け
ハートレイルズのサービスでもまだまだ実践できていないものがありますが、以下に私的なデザインの心掛けを列挙します。私にダメ出しを食らわないためのリストでもあるので、私にダメ出しを食らうかもしれない立場にいる方々は参考にしてください。（すげー偉そうですが、実際は全く偉くありません。）
（１） 平易で分かりやすい文章
平易で分かりやすく、できるだけ短い文章を心掛けます。平易さのチェックでは、辞書はもちろん、Google や Yahoo 等の検索エンジンで、その言い回しがどのくらい使用されているか等も参考にします。昨今のゲームが説明書を読まなくても気軽に遊べるように、web サービスも気軽に利用できるのが一番です。ダラダラと長く、難解な説明を前面に押し出したサービスなど私は利用したくありません。
機能上、やむを得ず長い説明を必要とするものもあるかもしれませんが、まず、そうした機能はそもそも必要ないか、あるいは、機能の見せ方に問題があるのではないかと疑ってかかるべきです。そうした熟慮を経てなお必要なものに関しては、例えば、上級者用のオプションとして限定的なユーザーにのみ見せる等、何らかの工夫を施すことを検討します。
（２） 機能の単純化 （複雑化の回避）
まず、そのサービスのコアが何かということを徹底的に固め、コアの充実に集中します。機能は一旦追加するとその削除が容易ではないため、機能の追加に関しては慎重に検討します。また、機能を追加する際には他の機能との関係、重要度を考慮し、適切な場所に追加します。こうした重み付けを行わずに複数の機能を並列に扱うことは、ユーザーの混乱の元となる可能性があり、場合によっては愚の骨頂です。
なお、実装すべき機能の取捨選択に関しては、コアに深く関連する機能以外は全て他のサービスとの連携に委ねても良い、くらいの心積りでいた方が無難です。とりわけウチのようなベンチャー企業では、何もかも自社開発しようとすると破綻します。livedoor が Gmail を採用したのは個人的には良い例だと思いますが、より良い代替手段が既に存在している場合、コアの範疇にない機能を一から開発するのは全くお勧めできません。
（３） 画面遷移、入力項目の適正化
必要のない画面遷移、入力項目は極力排除します。入力項目が多岐に渡る場合はできるだけ必須項目を減らし、また、入力補完等のユーザビリティに配慮します。
（４） 標準への準拠
独自性を持ち込まなくても解決できることに独自性を持ち込むのは、一部の例外を除いてユーザーの混乱の元にしかなりません。スタンドアロンな GUI のデザインでも同様ですが、なるべく標準の UI コンポーネントを組み合わせてサービスを構築すべきです。ユーザーが蓄積してきた経験をスムーズに適用できる UI になっているかどうか、ユーザビリティテスト等を通じて定期的に検証していく必要があります。
（５） 最速のレスポンス
レスポンスが遅いことは、そのサービスが利用されない致命的な要因になります。
（６） 広がりの重視
ブログパーツや API 等、広がりを加速させ得るものに関しては予め準備しておきます。特に、きちんとした API を定義し各機能を独立、疎結合させることは、仮にその API を公開しなくても様々な面から有用に働きます。
以上、他にもたくさんあるのですが、書くのが面倒になってきたので今日はここまで。気が向いたら後日加筆修正するかもしれません。
スピードが全て
様々な分野の偉い人達が言っているけど、本当にそう思う。
時間をかければ良いものができるのは当たり前。
いかに短い期間で達成できるかが全て。
言葉として理解するのは簡単だけど、実践できる人は少ない。
全速力で走り続けないと直ちに機能不全に陥るようなウチの会社ですら、
まだその危機意識が、実践力が足りないと感じる。
多分、いくつかの例外もあるだろうけど、モノ作りの世界では、
いつまで経ってもこの危機意識と実践力に欠けた個人、集団は、
何事も成さぬまま、曖昧なままグズグズと消えていくのだと思う。
自戒を込めて。もっと速くならないと。