Life is beautiful: エンジニアにも分かる「アベノミクス」
（理科系の友人が多い）Facebook の方で「アベノミクスの正体を誰か解説してくれ」という話題が盛り上がっていたので、私なりに「エンジニア向け」の解説をしてみる。まずは基礎知識から。 1. 経済学と数学・物理学との違い 経済学が相手にしているのは「人間の行動」であり、数学・物理学のように、基本的な「定理」を積み上げて現象を予測することが不可能だ。基本的には「経験則」に基づいて人々の行動を「予測」するしかない点が、学問として物理学とは大きく違う。 2. 景気にかかる「正のフィードバック」 経済学が対象とするものの一つに「景気」がある。景気の尺度には、GNP、物価、株価、失業率など色々とあるが、常に「正のフィードバック」がかかる性質を持っており、これが色々な問題を引き起こす。 「不動産価格」が一番分かりやすい例だが、不動産の価格は、より多くの人が「将来は不動産の価格が上がる」と思うとそれを先
特許庁のシステム開発が破綻した本当の理由
特許庁と東芝の新システム開発契約打ち切りについて、なぜこの開発プロジェクトが破綻したのかについて私なりの解説をしようとバックグラウンドを調べたところ、調べれば調べるほど、この問題の根底には（１）コスト意識が欠如し自分たちが「公僕」であることを忘れてしまった霞ヶ関官僚、（２）霞ヶ関から流れて来るお金にたかる IT ゼネコン、（３）そのお金の流れに対する影響力を利用して票を稼ぐ政治家、という原子力業界と全く同じような構図があることが明らかになり、ウンザリしてしまった。 破綻の原因は、ソフトウェア・アーキテクチャやプロジェクト・マネージメントにあったのではなく、「競争原理が正しく働かない社会構造」そのものにあるのだ。これではうまく行くはずがないし、たとえうまくいったとしてもやたらと高くつく。 そもそも破格だと言われた９９億円という落札価格も、私から見ればどうみても高すぎる。特許庁のシステムであれ
丸投げ「エンジニアもどき」はGitHubの夢を見るか？
Facebook のタイムラインに、Wireless Wire News に「海外で食べて行けるエンジニア、食べられないエンジニア」という記事が流れて来た。 簡単に言うと、外でも食べて行ける人は「自分で手を動かして何かできる人」です。 コーディングできる、設計できる、管理の仕組みを考えられる、コストカットした機材の調達の仕組みを考えられる、人員管理がうまい、プロジェクト管理できる、監査の仕組みやドキュメントを作れる、戦略を作って実行できる、という様な「自分で何かができる」人です。 反対に、「これは食べて行けない」という典型例。それは、日本国内の大手ベンダやユーザー企業勤務で、下請けや孫請けへの「丸投げ」しかできない「エンジニアもどき」や「SEというなんだか良くわからない仕事をやっている人」「仕事が部長や課長」という人々です。 基本的には、私が以前、「ソフトウェアの仕様書は料理のレシピに似て
パナソニック経営陣への５つの提言
日本の家電メーカーのソフトウェアの作り方や、人材の活用方法の問題点関しては、このブログでもメルマガでも何度も指摘したが、その問題を浮き彫りにするブログエントリーを見つけたので紹介する。 パナソニックを退社しました ...私の部署では、絵に描いたような昔ながらのソフトウェア開発が行われていました。 単価計算は人月とステップ数。仕様書を書く上流工程が重要で、コーディングは単純作業という価値観のもとでの開発です。当然正社員はなかなかコーディングに携わることができませんでした。 また、単純作業とみなされがちなコーディングを効率化しようとするモチベーションが少なかったのか、いくつか作業環境で疑問に思うところもありました。例えば、メモリ 1GB ぐらいの遅いマシンでビルドしている、ディスプレイが17インチ、きちんとしたソース管理がない、などです。PCスペックやディスプレイなどは入社の時期によってはそこ
「ファミレス型ソフトウェア開発」ではアップルには勝てない
私のWEB＋DB PRESS向けのコラム「Appleのビジョンと日本のハードウェアメーカーの将来」が公開されたので紹介する。私が一番強調したいのは、 他社と横並びでスペック競争をする時代は終わった。総合家電メーカーというビジネスモデルはもう成り立たない。ハードウェアは自分たちで作り，ソフトウェアの開発は外注に丸投げするのでは世界で戦えるデバイスは作れない。 という部分。 自らバリバリとソフトウェアを開発したことがないメーカーの正社員が仕様書を書き、実際の開発は子会社や関連会社に任せる上に、その子会社においても実際のコーディングは派遣社員が行うというゼネコン型ソフトウェア開発。これでは、本社から送られて来たレシピどおりにパートの人たちが料理をしているファミレスと同じだ。 一流シェフたちが腕を競う高級レストランのように、シリコンバレーのトップクラスのソフトウェア・エンジニアたちが、自ら仕様を決
オランダはどうやって自転車天国になったか
このビデオ、色々な意味で感動したので貼付けておく。 一つは「市民運動」の力。高度経済成長とともに都市を自動車に最適化しようとしていたオランダ政府に、人々がまったをかけたのだ。日本ではこれまでは「市民運動＝左翼」というレッテルを張られてしまって来たが、今回の原発事故以来、少し変わって来た様に思う。日本の未来を決めるのは、政治家でも霞ヶ関の官僚でもなく、私たち国民だという意識を持って、発言すべきときは発言すべきだとつくづく思う。 そしてもう一つは、電気と石油を使いまくる「経済成長」がかならずしも国民の幸せに繋がるとは言えないこと。その意味で、「自動車にとっては天国だが、年間４００人もの子供が自動車事故で死ぬ国」よりも、「自動車で生活するには不便だが、誰もが安全に自転車に乗れる国」を選んだオランダは、今後の日本のエネルギー政策を考える上でもとても参考になると思う。
スティーブ・ジョブズに学ぶプレゼンの秘訣
ベスト・セラー「スティーブ・ジョブズ 驚異のプレゼン」の著者で、Business Week のコラムニストでもある Carmine Gallo が書いた "10 ways to sell your ideas the Steve Jobs Way!" という資料を手に入れたので、簡単に内容を紹介する。 1. 最初は手書きで考えをまとめろ いきなりパワポの資料を作らず、まずは紙やホワイトボードなどで（訳注：neu.Notes+ でももちろんかまわない^^）、プレゼンの大まかな「流れ＝ストーリー」を作るべき。つまらないプレゼンでは、観客はすぐに飽きてしまう。語るべき「ストーリー」がないうちにパワポの資料を作っても意味がない。 2. Twitter 向きの短いフレーズを使え Twitter の「口コミ効果」に関しては、いまさら強調するまでもないが、それを最大限に活用するには、１４０字以内に収まる
可視化された Android OS アップデート問題
先日、ここでも触れた Android OS のアップデート問題。Android 端末がどのくらいの勢いで「陳腐化（OSのアップデートから見放されること、セキュリティ・パッチの配布が止まること）」するかをとても分かりやすく表現しているブログ・エントリーを見つけたので紹介する。 Android Orphans: Visualizing a Sad History of Support iPhoneの場合（上から４つ）は、新機種が発売されてから３年間は陳腐化することはない（緑色）が、Android 端末の場合、大半がすぐに陳腐化（黄色から赤）してしまっていることが良く分かる。 特に問題なのは、発売当初から１〜２世代前のバージョンを搭載した「生まれた時から陳腐化」している端末。中でも Motorola Cliq XT が最悪で、発売された時から２世代遅れており、発売後３ヶ月で３世代遅れになり、その
Microsoft vs. Novell: 証言台に立って来た
先日ここでも述べたように、今日の午後、Salt Lake Cityで開かれている Novell 対 Microsoftの裁判に証人の一人として証言台に立って来た。 詳しい話は近いうちに連載としてメルマガに書く予定だが、 簡単に言えば、私が Windows95 の一部として作った "namespace extension" という仕組みが、ある時点のベータ版のSDKでは公開されていたにも関らず、最終版のSDKからは外され、そのためにNovell（正確にはNovellが買収したWordPerfect）は多大な損害を被ったというのがNovellの言い分である。 それだけでも証人に呼ばれてもしかたがないとも思うのだが、その背後には、Microsoft社内での「Chicagoチーム対Cairoチームの次世代OSの争い」があり、そもそもその社内抗争を起こした原因を作ったのがCairoからChicago
「空気に支配される大人」にはならないで欲しい
「孫正義ソフトバンク社長が、経団連の理事会に出席し、経団連が一致して決議しようとした原発再稼働への賛成・推進に対して、反対し、執行部の姿勢を強く批判した」と報道されている（参照）。いかにも孫さんらしい行動だが、問題視すべきなのは、３００社以上の出席者からは、孫社長の意見に対する反論も同調する意見もなかったという点。 経団連を牛耳る原発推進派の企業により「満場一致で原発再稼働に賛成する」という空気が作られるなか、その「空気作り」が許せなかった孫社長が真っ向から反対したが、残りの「空気が読める、空気に支配される大人たち」は黙ってしまったのである。 この状況は、学校で「いじめ」が起こった時に、一部のいじめっ子たちにより「あの子はいじめて良い」という空気が作られた時に他の生徒が黙認してしまう（そして、結果としていじめる側に回ってしまう）状況に似ている。そんな空気の中で「こんないじめは良くないよ」と
防備を固める OS X と、無防備な Android と
Forbes の記事によると、アップルがOS X 用のアプリにウィルスやマルウェアの混入を防止する仕組み（Sandbox）を導入するらしい。そしてiOSと同じく、最終的には iTunes ストアからしかアプリをインストールできないようにするという。 反対している開発者もいるようだが、私は逆に遅すぎるぐらいだと思う。Windowsのようにアンチウィルス・ソフトウェアをインストールしないと安心して使えないパソコンなんてどう考えても時代遅れだ。マイクロソフトも同じような仕組みを Windows8 に導入するようだし、私としては大歓迎だ。 同じ理由で、Androidの最大の弱点はセキュリティにあると私は見ている。すでにAndroidアプリの数多くがウィルスに侵されているというデータもあるし（参照）、実質的に、Windowsパソコンと同じように「アンチウィルス・ソフトウェアをインストールしないと安心
TPPを「のび太とジャイアン」の関係で説明してみる
TPPに関しては、日本の輸出産業の発展のためには入るべきという賛成論と、日本の農業を守るために入るべからずという反対論の二極化で議論が進んでいる。このまま行くと、中身の議論のないままに時間切れでアメリカに押し切られる形でTPPに参加表明をする、といういつものパターンに陥りそうないやな予感がする。 TPPであれ何であれ、多国間協議に参加するのであればイニシアティブが取れるポジションを取らなければ意味がない。二国間のFTAであれば「ここは譲るけどこれは絶対に譲れない」などの交渉がまだ可能だが、TPPという多国間協議の場に単なる「one of them」として参加した場合、「多数決で決まったから」と無理難題を押しつけられても文句は言えない。 日本の外交の一番の問題は、「おひとよし」であること。あれだけの金を出しながらも国連で常任理事国になれないのは、「常任理事国の座をくれるまでは金は出さない」な
エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
Life is beautiful: WEB+DBコラム「なぜ日本のソフトウェアが世界で通用しないのか」
私がコラムを書いている「WEB+DB PRESS」の最新号が発売されたので、ここで宣伝させていただく。今回のコラムのタイトルは、「「なぜ日本のソフトウェアが世界で通用しないのか」。 ...(前略)...そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること、そして、日本のソフトウェア・エンジニアの境遇が悪すぎるということ。そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 詳しくはコラムを読んでいただくとして（宣伝だと言ったでしょう）、この問題はいまやソフトウェア業界だけにとどまる話ではないから始末が悪い。世界で一番進んでいるはずだった日本の携帯電話メーカーが、今や袋小路に追い込まれているのもこれが原因。 通信業界にはもちろん、携帯電話メーカーにもソフトウェアを自分で書ける人がいない今の日本の状況を考えれば、世界の
共著「Google Chrome OS」出版のお知らせ
先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 ２年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根本的に間
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
Python入門：デコレータとは
前から常々思っていることだが、何かについて勉強する一番効率的な方法はそれを誰かに教えること。人に教えようとすると、それなりに準備をしなければならないし、自分の頭の中を整理しなければならない。また教える過程でするどい質問をされたり間違いを指摘されて、さらに勉強を強いられることもある。 私がこの手の「入門編エントリー」を書くのは、ほとんどの場合「自分自身の理解をより深めたい」ことが一番の目的であるが、ブログの場合、教室などと違って「その道の達人」みたいな人たちがツッコミを入れてくれるケースもしばしばあるので、そのメリットは何倍にもなる。 先日のクロージャに関するエントリーなどは良い例で、「そんな用途にはmemoizeというデコレータが便利」などの指摘がいただけだけであれを書いた価値があるというもの。 そこで、今日はPythonのデコレータに関して。デコレータがPythonという言語に導入された
「富豪プログラミング」もいいけど「けちな大富豪」になるべき
Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
