Life is beautiful: エンジニアにも分かる「アベノミクス」
（理科系の友人が多い）Facebook の方で「アベノミクスの正体を誰か解説してくれ」という話題が盛り上がっていたので、私なりに「エンジニア向け」の解説をしてみる。まずは基礎知識から。 1. 経済学と数学・物理学との違い 経済学が相手にしているのは「人間の行動」であり、数学・物理学のように、基本的な「定理」を積み上げて現象を予測することが不可能だ。基本的には「経験則」に基づいて人々の行動を「予測」するしかない点が、学問として物理学とは大きく違う。 2. 景気にかかる「正のフィードバック」 経済学が対象とするものの一つに「景気」がある。景気の尺度には、GNP、物価、株価、失業率など色々とあるが、常に「正のフィードバック」がかかる性質を持っており、これが色々な問題を引き起こす。 「不動産価格」が一番分かりやすい例だが、不動産の価格は、より多くの人が「将来は不動産の価格が上がる」と思うとそれを先
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
Life is beautiful: 起業の時に意識すべき「会社の存在理由」
今週末は、たまっていた資料を一気に読破。読み過ぎでいささか食傷ぎみだが、その中に出て来たフレーズで最も気に入ったものはこれ。 Disney's core purpose is to make people happy - not to build theme parks and make cartoons. これは、"Building Your Company's Vision (Collins and Porras, Harvard Business Review, September 1996)"の一節だが、筆者が伝えようとしていることは、ディズニーという企業の存在理由は「人々を幸せにする」ことにあり、テーマパークやアニメを作るなどの活動は、その目的を達成するための手段でしかない、ということ。「利益を上げて株主の利益を最大化すること」すら目的ではなく手段である。 少し前に、「君の夢は」
Javascriptの「this」は日本語の「僕」みたいなものだ、と言ってみるテスト
先日のエントリーで、Javascriptのthisについてブツブツと言ってみたところ、なかなか良いトラックバックが返って来たので紹介。 setInterval(this.callback, 33)がうまく動かない理由 コメント欄でも少し会話を続けたのだが、こんな「ゆるい」コミュニケーションがとても心地良い今日このごろ。 ◇ ◇ ◇ ちなみに、thisの説明をするときに、「Javascriptのthisは日本語の「僕」みたいなもの」と言ってみるのはどうだろう。 太郎「僕はPerlが好き」 // この「僕」は、 次郎「僕はやっぱりPHPだよ」 // この「僕」とも違うし 太郎「三郎だったら『僕は絶対Ruby』と言うに決まってるよ」 // この「僕」とも違う ただし気をつけなければいけないのは、太郎が次郎に向かって、 「三郎に会ったら『僕に電話して』って伝えといて」
Life is beautiful: ソフトウェアの資産計上に関する素朴な疑問
会計の勉強をしはじめてから、今まで見過ごして来たようなことが気になるようになった私だが、最近一番気になったのが、日経エレの８月１３日号に書かれていた、Aplixの７６億円の特別損失の計上の件（参照）。要約すると、過去２年の間「ある顧客が買う予定」と言う名目で（経費としては報告せずに）資産として計上してきたソフトウェア資産を、「やっぱりすぐには売り上げにはつながらなそうだから」と一気に特別損失として計上した、というニュースである。 建物や原料のようにはっきりと形のあるものを資産として計上することは会計上もっともなことだが、自社で開発したソフトウェアやパテントのようなものを資産として計上することには非常に大きな危険がともなう。Aplixのケースのように社内で開発したソフトウェアが将来売り上げに繋がらないということはしばしばあるわけで、そんなにあやういものを資産計上されてしまっては、投資家はどの
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
Life is beautiful: 本質的でないものを徹底的に排除すると美しくなる（「アップルのデザインの秘密」より）
アップルの作る製品のデザインがなぜあれほどにすばらしいかを熱く語った文章を発見。一番気に入った部分を引用してみる。 "The businessman wants to create something for everyone, which leads to products that are middle of the road," says Brunner. "It becomes about consensus, and that's why you rarely see the spark of genius." "Critical to Apple's success in design is the way Jobs brought focus and discipline to the product teams," Norman says. "[Jobs] had a s
JavaFX Script 入門、とりあえず言語仕様に目を通してみた
CNetでも報道された通り、Sunが独自のスクリプト言語JavaFX Scriptを発表した。テクノロジーの優劣だけで決まるものではないので、この試みがうまく行くかどうかは何とも予測しがたいが、とりあえず言語仕様が公開されたので目を通してみた。 私なりに興味深いと思った点は以下の５つ（ただし、私なりの拡大解釈が多少入っている可能性もあるので要注意）。 １．宣言型のUIをサポートしていること 宣言型大好き人間の私としては、この方向性は大賛成（ちなみに、UJMLも宣言型のUI言語^^）。"押してね！"というラベルがついたボタンを表示するには、こう書けば良い。 Frame { content: Button { text: "押してね！" action: operation() { System.out.println("押してくれて、ありがとう"); } } visible: true } ２
プロトタイプを重視するカルチャー
最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル（相当する良い日本語がないが、あえて選ぶなら「筋」－詳しくは「プリンシプルのない日本」参照）を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 １．UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 ２．本当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱
Life is beautiful: エンジニアとしての満足感をどこに感じるか
先日の「IE3.0の１０才の誕生日のエントリー」で、私が「エンジニア冥利に尽きる」という言葉を使ったことに対して、「ビジネスマン冥利にはつきそうだけど。エンジニア冥利な要素ってどのへんなんだろう？」という質問をいただいた。 本質をついたするどい質問なので、どう答えようか悩んでいたのだが、良い例を思いついた。何年か前のイチローへのインタビューである。細かな言葉までは覚えていないが、こんな感じであった。 アナウンサー：イチローさん、今日は５打数４安打の大当たりでしたね。 イチロー：はい、でも試合には負けてしまいましたから。 アナウンサー：これで今年も２００本安打確実ですね。 イチロー：２００本は単なる通過点ですから。 アナウンサー：特に３回の二塁打の打球はするどかったですね。 イチロー：はあ、でも得点には結びつかなかったのが残念です。あそこは犠牲フライでも良いから１点ほしかった。 アナウンサー
Life is beautiful: Edward Tufteに学ぶプレゼンのスキル
「スティーブ・ジョブスに学ぶプレゼンのスキル」は、このブログの人気エントリーの一つだが、ことプレゼンに関して私が師と仰ぐのはEdward Tufteである。日本ではあまり名が売れていないようだが、米国では「データのプレゼン技法」に関しては第一人者で、本も何冊も書いているし、全米各地でセミナーも行なっている。 私自身も、一日セミナーに参加したことがあるが、膨大な量の実例を集めて、それぞれのどこが優れているか、どこがダメなのかを的確に分かりやすく説明してくれるTufteは、まさに「プレゼンの神」であった。彼からは色々なことを教わったが、特に心に残り、今でも常に実戦しようと心がけていることは、 ・文字に頼らず、図を効果的に使うこと ・一度に見せる情報量を絞ること ・意味を持った色使いをすること の三つである。特に最後の「色も情報を運ぶことができる」という点は、それまで意識したことがなかっただけに
対称性の大切さをトイレットペーパーに学ぶ
以前にも書いたことがあると思うが、私は「商品の『能書き』を読むこと」が妙に好きである。コーンフレークを食べながらついついそのパッケージに書いてある文字を隅から隅まで読んでしまったり、お風呂につかりながら入浴剤の成分を確認したり、という毎日を送っている私だが、色々と発見もあるし勉強にもなる。 先日も、宿泊先の旅館のトイレにおいてあったトイレットペーパーの『能書き』を読んでいたのだが、あまりにもツッコミどころが多いので、感動して写真を撮ってきた（トイレの中で「ピロリーン」という音を立てていたのは私である）。 何と言っても「対称性」が思いっきり壊れている点がすごい。何かを箇条書きにしたり、アイコンやボタンを並べたり、APIを決める際には、対称性を強く意識することが大切であることは周知のことであるが（「ノンデザイナーズ・デザインブック」に丁寧に説明してある）、この『能書き』は絶好の反面教師だ。 ま
ユーザー参加型コンテンツビジネスのまとめ
最近CGM（Consumer Generated Media）関連の質問をされることが多いので、一度頭の中にあるものを整理する意味でも、箇条書きにしておく。 従来のWeb1.0的なコンテンツビジネスと比べた時の利点 ・常に新鮮なコンテンツをコストをかけずに提供できる点 ・バイラルマーケティング効果（コンテンツを作ったユーザーが他の人に宣伝してくれる） ・根本的にコミュニケーションツールであること（人がオンラインになるのは、他の人と繋がるため） ・ユーザーの数が増えれば増えるほどサービスの価値が上がる点 ・長く使えば使うほど、そのユーザー自身の財産が形成され、サービスから離れにくくなる点 意識しておくべき点 ・自社コンテンツを持っていない企業が新規参入できる点 ・ユーザーは予想もしない使い方をすることがあること ・コミュニティの作られ方しだいでサービスの質が大きく左右されること ・積極的に参
Life is beautiful: Windows95と地上の星
Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell（デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス）の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、９５年中にリリースすることはできない」 深刻な問題である。既に当初の予定より１年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ
本当に生活の一部になると言及されなくなる
会社にいるときは主にパソコンの前で仕事をしているのに、家に帰ってもついつい、すぐにパソコンに向かってしまう私だが、そんな私に投げかける妻の言葉が、少しづつ変化している。 結婚当時 「ねえ、パソコンばかりいじってないで、私の言うことも聞いてよ」 数年前 「ねえ、インターネットばかりしてないで、私の言うことも聞いてよ」 最近 「ねえ、ブログばかり書いてないで、私の言うことも聞いてよ」 妻には申し訳ないが、これは大変興味深い現象である。確かに最近はブログを書いているケースが多いのだが、ブログを書くにはパソコンもインターネットも必要なのだ。それなのになぜ、もう「パソコンをいじっている」とか、「インターネットをする」と言わなくなって来たのだろう。 私はこれこそ、パソコンやインターネットが、特別なものではなくなり、テレビや電話と同じく我々の生活の一部になった証拠だと思っている。例えば、日曜の朝のこんな
Life is beautiful: SEはメニューのないレストランのウェイターか？
一昨日書いた「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーに対して沢山の人からフィードバックをいただいた。このように情報を発信すると、逆により多くの情報が集まり自分にとっても勉強になる、というフィードバックプロセスがあるからブログは楽しくて仕方がない。 フィードバックの中に「これでSE不要論も再燃か？」などという過激なコメントから、自分自身がSEという立場の方からのものすごく真面目なフィードバックまでが集まったので、これを機会に、ここに私なりに「SE」という職業をどう解釈しているか書いてみようと思う。もちろん、私自身がSEという職業を経験したことがあるわけでなないので、間違っているかも知れないが、その場合は遠慮なく指摘していただきたい。 私の理解では、SEという職業はレストランに例えればウェイターである。それも、メニューから料理を選んでもらう通常のレストランとは異なり、「
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
