Web2.0がうまくいかなかったワケ
TBSの深夜番組で、人狼のカスタマイズ版であるジンロリアンという番組をやっていた。 普通の人狼とはルールが違う部分があって、 ・人狼と疑わしきプレーヤーを排除するのを決定するのは視聴者のオンライン投票（生放送） ・人間の側にナイトや占い師などの役職がない。 というもので、一瞬面白いと思って見ていたが、場を盛り上げる芸人が率先して排除されていく様に、すぐにルールが成り立ってないことに気がつく。 ・役職がないので圧倒的に人間が不利。情報が非対称。 ・当事者ではない視聴者が投票するので、目立ったもん負け ・人間の側が条件をひっくり返すほどの武器を持ってない。 ・ということなので、深夜にプレーヤーが殺される意味が無い。（普通の人狼は、占い師と騎士をいち早く殺したいハズなのだが、こっちは全員人間なので誰が死んでもあんまり関係ない。最後に壇蜜が竹山を殺した理由を誤魔化していたように見えた。「なんとなく
WebにおけるMVCアーキテクチャの勃興と変遷
どんなに当たり前になった開発手法やプログラム管理方法があっても、新人さんにとってはHello worldから入って行くと思う。インターネットで、「知の高速道路」が整備されたと言っても、意外と古い話を探すのは難しい話で、MVCみたいに当たり前になってしまったことについて、何故そんなものが存在するのか？という考え方を後から肌で感じるのは難しく、そんなことを考えていたら、突然MVCについて書きたくなった。 以下、書いていくがかなりの偏見が入っている気はするので、ぜひ、歴史認識が間違ってたら僕のためにツッコんでくださいませ。 僕がMVCアーキテクチャを知ったのは、JavaのServletを勉強していた時だった。Javaはオブジェクト思考で作られている言語かつ、Webに特化した言語ではないため、クラス間のデータは、インターフェース仕様に基いて秘匿されるのと、テンプレートエンジンは別に存在していたので
言っとくけどスマホは退化でもあるからな。
確かにiPhoneという名のタッチパネルパソコンは革命的に凄い。何より高性能でゲームもできるし、ボタンを意識しなくて使えるし、いろんな機能が割と自由に使える。 でも進化には必ず退化があって、最初にiPhoneは売れないって言ってた人たちが着目していた部分は、そういう部分。そういう指摘は間違っていないと僕は思っていて、ただし、商業的にそこがネガティブファクターになるかというと、必ずしもそういうことではないというのはITの歴史でもある。 つまり、うまくいかなければ、おサイフケータイがついてないだの、絵文字がないだのが失敗要因として語られるが、それを上回るメリットがあれば、そんなの関係無かったよね、と言われるだけのこと。 スマホがもたらした負の部分は、ガラケーで普通に使えてたサービスをそのままスマホ化するとオーバースペックになってしまうこと。 これは、一画面で扱える情報量と、操作ナビゲーションが
アイコン5000円とか、Web受注（発注）価格について。
値段が高い、安いという議論は意味が無くって、 もし、受託で合理的に価格を説明する立場の人たちであれば、人日単価が内部で存在するのであれば、それがどれだけの手間がかかるのか？！どれぐらいの時間がかかるか？！で計算できるわけなのだが、極めて合理的にクライアントに伝わっていないんじゃないだろうか。 ロゴ5000円なのか20万円なのか、そこにどう違いがあるのか？！巨匠と呼ばれる特別な人を除けば、その理由は説明し、アグリーされなければ決して理解されない。巨匠は名前利用料が乗ってくるので、非論理的な価格設定でもOKなわけで。 もし発注する商品の価値が測れないのであれば、意思決定の際に、心の引っ掛かりが亡くなるので、その発注価格は０円に近づいていくのは仕方ないと思う。経営者だったら、どんなものだって、安ければ安いに越したことはないわけだから、妥当性のある理由を誰かが説明できなければ、安いほうが正義という
全収集型RSSリーダーの終焉とソーシャル化するWeb
Googleリーダー、いつまで続くのかなぁと思ってたら、今年の7月でサービスが終了だそうだ。 RSSリーダーというビジネスは、ユーザーがアクセスしなくなっても、機械はひたすらフィード単位でコンテンツを収集し続けなくてはいけないという理由で決してコスト効率は良くない。アクティブ率の低下と共に１ユーザーあたりのコストが増えていくサービスというのは他にはそんなに存在しないと思う。システム的にこれを改善する工夫はできると思うが、問題は、既にRSSリーダーはコンテンツの価値の重み付けの舞台ではなくなってるところにあるのだろう。 その中でもクローラーでWeb上のコンテンツを集め続けているGoogleのような企業だけが、こういうデータを別のところに活かせるのかなぁと思ったら、そんなことはなかったということか。 ソーシャルフィルタリング、tumblr、まとめの時代になって、情報流通が１ページ、1tweet
ブラックという言葉から逃げるな
世の中、確かに新入社員が１〜２年でほとんど辞めることを前提に大量採用して、数％生き残ればOKという会社はある。間違いなくブラック。しかし、すごくいい会社でも、新入社員が１０年後には10%も残ってない会社も沢山ある。 前者は、脱落を前提としている会社、後者は居心地は良くても、できる社員たちが勝手に巣立っていってしまう会社。 どっちが良いのかな。実態としての社員の残存率は変わらない可能性がある。うーんともしかしたら、「できる人の残存率は変わらない」が正しいのかも。 また、それとは違って、ワタミの社長にせよ、ソフトオンデマンドの社長にせよ、ブラックと言われる会社でナンバーワンになることは自分の自信に繋がるから、と、あえて厳しい世界に飛び込むヒトもいる。辞めることを前提にブラックという環境を利用する。 ブラック企業のすすめ 上の記事のコメントに面白いコメントが書いてあった。 こんなギャンブルのよう
モバイルファーストが失敗なハズはないが、今はまだ時期尚早
…ということをi-modeで成功した実績を持つ日本人なら自信を持って言える。 モバイルファーストは間違いだったのか « うめのんブログ 理屈ではFacebookが選択していたWebとのハイブリッドアプリが正解のハズだったんだけど、残念ながらスマホのスペックはそこにたどりついてない。 故にアプリでやらなきゃいけないんだけど、アプリの世界はアップルもAndroidもいろいろ問題があって、面倒くさいので大変だなぁというのがイマココ。 （アプリ名が完全一致してるのに、検索結果の一番最初に出てこないApp Storeって酷すぎる。） だからといってPCで進めるべきなのか？！というと、いや、あんたんとこのサービスがPCでユーザー集められる特性のサービスなら、とっととPCやりんさいよ！という話であって、それはそもそも機能的な意味のモバイルファーストではないじゃない。 マーケティング論としてのモバイルファ
やりがいはソートできない…非情なデータベース社会
我々が日常関わるWebサービスにせよ、企業の端末で扱われているシステムも、ほとんど必ずデータベースと組み合わせてできている。 データベースの組み合わせはとても便利なもので、集計は簡単にできるし、情報のソートは一発。何より、大量のデータを扱うことができる。 以前、あるR社出身の人に、R社が作った住宅情報の功罪という話を聞いたことがある。 この話は、本当にそうなのかは僕は知らないが、あくまでも受け売りということでエッセンスだけ理解して欲しいと思うのだが、R社が作ったのは、 ・駅から徒歩（バス）N分 ・間取り というソート可能な序列だった。これが日本の住宅相場のルールを決めた。つまり、R社としては、日本中どこでも比較可能なテンプレートを作ったことが勝利の要素だったと言う。 彼の論としては、ここにもしも「景観の良さ」というパラメータを入れていたら、日本の住宅事情は大きく変わったのではないか？！とい
プレーヤーとして戦い続けるための意志力
正月にFacebookのタイムラインに流れていたのでkindleで買って読んでみたら、想像以上に面白かった。 paperwhite買ってから、初めてマーカー機能でメモを残したくなったのでblogにもメモしておく。 勝ち続ける意志力 世界一プロ・ゲーマーの「仕事術」 (小学館101新書) [Kindle版] 少し本について紹介しておくと、著者の梅原氏は有名なプロゲーマー。2012年の段階で31歳。プロゲーマーとしては決して低い年齢ではない中で、プロとして生き残る術と挫折、葛藤が、赤裸々に書かれた、自伝であり、ジャンルとしては自己啓発本かな。 自分の好きなことを、人生の糧として貫くのがこうにも辛いものかと強く考えさせられる一冊であり、イチローのような地道な努力こそが専門職としての長いキャリアを維持するものだと改めて考えさせてくれる。 僕の中では、ほぼ同世代のイチローが世界にチャレンジしたという
責任フリーのイノベーション
昨日WBSにstores.jpが出ていた。あちゃーと思ったが、stores.jpが支持されている点と、その裏腹にある問題点は以下の２つ 昨日のWBSでちらっと言ってたのが、個人の事業主でやりにくかったところが解決されていると言ってたのですが、実はそれは商売をするにあたって負わなくてはいけない「責任」の部分がスルーできることかなと思いました。 （１）最短2分で作れるネットショップのプロセスに、特定商取引法に基づくの記載がスルーできること。そしてそこに記載されてるstore.jpの会社さんが責任を負っていること。なにせ最短ですからねw 特定商取引法に基づく記載とは、消費者保護の観点から通信販売を行う業者（個人事業主を含む）は、書かなくてはいけない条項のことで、ここに連絡先をかかなくてはいけないので、自宅で商売をしてみたい個人事業主のハードルの一つになっています。 もちろん特商法の記載は書き換え
「とにかくやってみよう」を否定する「リーンスタートアップ」まとめ４（完）
書籍「リーン・スタートアップ」に関するまとめエントリーである。本エントリーでは第３部で気になったところをピックアップしています。 本まとめページの趣旨説明はこちら 第１部はこちら 第２部はこちら ■第３部 スピードアップ 第９章 バッチサイズ バッチサイズとは一つの作業の行程のことで、モノを大量生産する時に部品を沢山つくってから次の行程に渡すか、少数の部品を必要な時に必要な量だけ生産して、次の行程に渡すか、という選択があった時に、かつては前者の方が効率的と思われていたが、実は後者の方が効率的だったという話である。 スタートアップに適用すると、構築ー計測ー学習の一連のプロセス＝バッチサイズを縮小することで、持続可能な事業の構築方法をできるかぎり短時間に学ぶのが目的となる。 この章はあんまり面白くないので、本書とは無関係なことを書いてしまうが、昔いた製造業の会社で、トヨタ系列の某社での工場生産
「とにかくやってみよう」を否定する「リーンスタートアップ」まとめ
書籍「リーン・スタートアップ 」は、文字が多くて忙しいプレーヤーの人達には読みにくい本だったんじゃないかと思う。しかし、その分書いてある事は、実例を含めてかなり詳しく書いてある。 リーンスタートアップの基本形は非常にシンプルで、ベンチャーだろうが大企業の新事業だろうが、自分たちがビジネスとしてやりたいと思ったビジョンを、細かい機能、要素に分解し、 １、各機能、成功要素を試す「必要最小限の商品」を作り、 ２、ユーザーが欲しいものとして受け入れられるかを試す。 ３、成果指標を必ず計測し、 ４、「必要最小限の商品」で実現した機能は正しくユーザーに受け入れられるかを分析する。 ５、その方向性は正しいのかを考え、そのまま突き進む（我慢する）のか、方向転換するために今までのものを捨てる（ピボット）のかを決断する。 このサイクルをスピードアップさせていくことで製品開発を進める考え方、である。 リーンスタ
ネットサービス系企業における、積み上げ型タスク管理の危険性
ネットサービスもそこそこの規模になると、後回しになっている、あっちゃこっちゃに細かい問題が積み上がってきます。 継続改善というサイクルの中で、改善していくわけですが、じゃぁこれをどのように処理していくか？という考え方の話。 一番最悪なのは、とにかく目についたものを全部直そうと言う考え方。 もはや維持フェーズに入っている事業担当の方なら、是非、どんどん直してくださいって話なんですが、多くのケースではそうではなく、未来に向かって、前に進むべきタスクが存在しているハズです。 事業の優先順位と連動せず、現場の開発者の判断で、気になったところを直していくと、必ず時間がかかります。見積もりには、判断ミスをするとか、考える時間やソースコードを検索するような時間が往々にして入ってませんからね。かつ、修正範囲が大きくなって、新しいバグの温床になることも少なくありません。 必ずスケジュールを切って、優先順位を
F's Garage：はじめてWebプログラミングをするなら PHP? Ruby?
やっぱり、PHP・・・・かな １週間暇ができたのでＷＥＢプログラミングを勉強したいと思います。 〜略〜 ・今後プログラミングしていくにあたり有用な、使える言語である ・１週間後掲示板が作れる ・以後まとまった時間がとれず、たとえば1時間単位でも積み上げていけるような基礎（土台）を 修得できる 以上が条件です。 〜略〜 という、はてなの質問が結構興味深かった。 候補としては、以下のものがあがっていた。 ・PHP ・Ruby on Rails ・cake PHP ・Python ・Ruby(CGI) ・Java 本当は途中までレスを書いてたんだけど、肝心のオススメする本がなくて書けなかった。 PHPは、オライリーのはじめてのPHP5は読んだけど、あれは他の言語経験者が読む本なので初心者向けじゃないし、僕の場合は、会社での他人のソースコードと、php.netのリファレンスが僕にとっての情報源なの
たった700円で作る、自宅や会社の侵入者検知 iPhoneアプリ
iPhoneのカメラを使って、家への侵入者を検知してくれるホームセキュリティ用のアプリ作れないのかなぁと思って探したら、あった。さすがだ。 思いつく用途は、２種類 1.家や会社への侵入者を検知したい。 カメラの映像の中で侵入者が見つかると映像を録画できたり、侵入があったことをiPhoneにプッシュで教えてくれる 2.ペットや病気の家族の様子を旅行や外出先から確認する、みまもり用途 これを実現するには、何個かのアプリの準備が必要である。 多分、このアプリが、あまりレビューサイトに紹介されてないのは、何個かアプリとデバイスが必要になるので初心者にはわかりにくいからなのだろう。しかし、MacやiPhone、Androidを何台も持て余しているF's Garage読者であれば、相当エクセレントなアプリなハズなので、できるだけシンプルに説明したいと思う。 ■１つ目 すべての中心となるMac、PC用ア
引き算のデザイン vs ごちゃごちゃしたデザイン
定期的に出る、「エレガントなデザイン」より「ごちゃごちゃしたデザイン」の方が売れるという話がある。 よく楽天市場のショップを揶揄する言葉として使われるが、最近は、eBayにもこんな話が出て、どうやら世界共通に通じることらしい。 eBay でヒドいデザインの方がコンバージョン率が高かった、という話 ただ、何故ごちゃごちゃ情報を掲載した方が売れるのか？！ということに関しては、あまり具体性がある記事を見た事が無い。 自分が思うところを書いてみたいと思うが、ある掃除機を売ると仮定して、「引き算の商品説明」と、「ごちゃごちゃしたい商品説明」考える。 ■引き算の商品説明 この方法で説明を考える時は、その商品の良さを徹底的に絞り込んで、できる限り一つのメッセージに落としたいと考える。 その結果が、例えば 「吸引力の落ちない掃除機です」 という説明にして売る。 何個かメリットがある場合は、情報に強弱をつけ
何故、エンジニアはUIのセンスがないか。
何故、エンジニアはUIのセンスがないのか、という自分にも当てはまるようなことについて書いてみる。 まずエンジニアがダメなUIを作ってしまう理由について、いくつかの仮説を立ててみる。 1.その画面を作るエンジニアは全てを知りすぎていて、もはやわからない人の気持ちがわからない説 2.エンジニアはITリテラシーは高いけど、自分ができることを人に理解できるように説明するのは下手説 3.技術的に実現する方に興味が偏って、ハナからUIの使い勝手に興味が無い説 4.国語力がない、自分が実現する文脈を表現するのはできるが、ユーザーの文脈に配慮した言葉を想像する力が無い説 5.仕様書を読まない、人の言う事を聞かない説。例えばOSが定めているユーザーインターフェースガイドラインに従わないので、UIパーツが意図した使い方をしておらず統一性に欠ける。 6.わかりやすい色や文字、レイアウトに関する知識が無い。センス
マインドスコープ株式会社を売却しました
facebookに書いたものでもう良いかなぁと思っていましたが、後から探せなくなってしまうと思うのと今までもblogに書いてきたので、今の気持ちのスナップショットとしてブログにも書いておきます。 4月末を持ってマインドスコープ株式会社を株式会社jig.jpに譲渡しました。2010年1月20日に作った会社なので、2年と数ヶ月でした。途中で合併を挟んでいるので３期目半ばということになります。 前職ペパボで、会社を辞めると上司に伝えたのが辞める１年前の2008年の年末でした。翌年の2009年に起きたtwitterの国内ブレイクの波に乗ったモバツイにコミットをすることを決めたのが起業後の2010年3月。 起業時は「人の想いを創る会社」という意味で「想創社」という名前をつけました。 その後、マインドスコープに合併設立するタイミングで、人を雇い、オフィスを借りて、という流れになりました。 その後、東日
「ぼくはこうしてプログラミングを覚えた」をどう読みましたか？
フェイスブックでエンジニアをやっていた方の面白い話があった。 「ぼくはこうしてプログラミングを覚えた」 フェイスブックのエンジニアで史上ベスト３に入るといわれるEvan Priestley氏への質問「どうやってプログラミングを覚えましたか」に対する本人からの答えです。 という話 コードの質がフェイスブックの強みであったことはないが、２００７年のフェイスブックのコードはグローバル変数とextract関数にまみれたヒドいものだった。 この「質v.s.スピード」という概念は根本的に間違っていると思う。だって素早く開発をしなくては環境、あるいは自分の環境の理解の変化にソフトウェアがついてこれず、ソフトウェアが解決すべき問題が解決できなくなり、必然的に質が落ちてしまう。逆に、質の高いソフトウェアを書かなくては、なにかある度にインフラが崩壊し、素早く開発をすることができなくなってしまう。インフラの崩壊
Webエンジニアスキルの勘所
Webのエンジニアにはどういうスキルが一番必要か？という話を考えてみた。 例えば、C言語やUnixの経験が長く、オブジェクト指向も理解していたとしたら、PHPから始まり、Rubyなどの理解は決して難しくないだろう。 では、それだけの経験で一線級のWebエンジニアとしての信頼が置けるかというと、ちょっと違うような気がする。 考え方のベースは、 「Webは、要するにテキスト処理であることが多い。だから難しい」 ほとんどの事がHTTPプロトコルを通じてテキストデータとして情報が、なんのネットワークの制約もなく流通する。つまり、HTTPヘッダを含むテキストの操作でセキュリティホールを作り、それが世界のどこから攻撃されるかわからない。 また、 同様に世界中からアクセスが集まることがありうるので、回りくどいテーブル設計をしてしまうと、あっというまに破綻してしまうこともある。 そして、 基本的にマルチア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
