Holstee Manifesto

Holstee Manifestoポスターが届いたので、早速部屋に飾ってみた。

さっすがオシャレだし、書いてある内容もシンプル。

これはあなたの人生。だから、いつでも大好きなことをしていよう。
何か気に入らない点があるなら、変えればいい。
いまの仕事が気に入らないなら辞めればいい。
時間が十分にないならテレビをみるのを止めればいい。
愛する人を探さなくていい。
自分の大好きなことに夢中になっているあなたを、愛すべき人が待っていてくれます。
穿ったものの見方は止めればいい。そう、人生はシンプル。
感情は全て美しい。何かを食べるときは、最後の一口まで味わう方がいい。
考えも、腕も、心も、全て新しいコトやヒトに向けよう。
お互いの違いを許容して、僕たちは結ばれている。
出会った人には「あなたの情熱はなに？」って聞いてみよう。そして自分の夢も共有しよう。
旅はするべき。道に迷うことで自分自身を発見するのだから。
どんなチャンスも一度きり、だからチャンスを確実に掴もう。
人生とは、あなたが会う人と創り出すもの。
だから今すぐ何かを創り始めよう。
人生は短い。だから夢を生きよう、情熱を持って。

電子立国日本の自叙伝

  １０年前くらいに放送されていたNHKスペシャル「電子立国日本の自叙伝」を最近NHKオンデマンドで見る機会があったのですが、その内容が非常に面白かったのでご紹介。

  １９６０年代後半、当時コンピュータといえば、机と同じくらいのサイズが当たり前の状況。日本では「そろばん」という文化があり、世界でも珍しく卓上計算機のニーズが高く、当時の複数の日本大手電機が電卓開発にこぞって乗り出すこととなり、そして日本国内で「電卓競争」が始まる。「電卓競争」が激化する中、計算装置や半導体装置の小型化が進む。そして世界最初のLSIを搭載した小型計算機を「ビジコン」が開発する。だが、厳しい競争に耐えきれず「ビジコン」は倒産。当時「ビジコン」とLSIを共同開発していたIntelが、「ビジコン」から独占販売権と基本特許をそのまま買い取り、Intelが世界No.1の半導体企業として誕生することとなる。

  大学在学中、当時授業を教えてくれていた教授が番組の編集に協力していたことから、この番組を授業で流していたのを思い出す。世界の覇権を握るくらいのイノベーションを簡単に海外に流出させてしまう、当時の経産省を批判していたような思い出があります。Intelの覇権が現在に至っても続いていることを考えると、とんでもない確かにトンでもないことです。

 さて、最近は、原発の事故もあったため、自然エネルギーやスマートグリッドが注目されていますが、それらを実現するための最重要技術が電池・バッテリーと技術となります。一昔前は、そのほとんどが日本メーカで提供されていましたが、これがもう昔の話。今は韓国が１位で２位も中国に奪われています。日本の大手メーカは、バッテリー産業を２１世紀版「産業の米」と捉え、いち早く研究開発費を投入し、また、ハイブリット車などの需要もあったため、バッテリーでは世界のトップを走り続けていました。それが２１世紀に入ると、サムスンがメモリや液晶でやってきたやり方と同じ手法でバッテリー産業に参入してきています。つまり、日本の研究者を高額な報酬で引き抜きを行うアノ手法です。ちなみに、５年ほど働くだけで、日本での一生分の給料となるそうですから、引き抜かれた日本人を非難できないです。

 本来、バッテリー技術者の流出を止めるためには、まず、特定の研究者の給料をあげる等の優遇を行う必要があるわけですが、そんなことは日本企業では難しいのが現実のようです。ちなみにこの話は、私が勤める会社の元副社長がブログで書いていた内容です。元副社長は「日本は妬みの文化なので、このような格差を生むと会社がバッシングを受けるだろう」のようなことを書いてました。なるほど、確かに今のマスコミの報道を見る限りだと、そのように思います。

 「技術立国」だと言われている日本ですが、２つの事例を見返す限り、「技術」を簡単に手放しすぎていると思うわけです。せっかく生まれたイノベーションを上手にオペレーションできないところが日本ってことなんでしょうね。

Macbook Air を買ってみた。

Desctop PCとNotebook PC

長年、デスクトップPCを継続して愛用していました。やはり性能に対するコストパフォーマンスがノートPCは悪かったというのが最大の理由です。わざわざ、外に持ち出してまでパソコンなんて触ることないし、外出中はほとんど電車に乗っているか、歩いているかなので、スマートフォン程度のサイズで十分だという理由で。

さらに言うと、スターバックスで襟を立てたOLさんがノートPCで、さも誇らしげにタイピングしている姿を見た日には、「かっこいい思ってるのか、この薄っぺらい人間が！」と心の中で毒づいています。

やっぱ男だったら、PCはWindows、エディタは秀丸、メーラーはBecky。そんな男を満足できるのは、最高の実行性能を計測するCPU、マザーボードのスロットを埋め尽くす大容量メモリ、無尽蔵のディスク容量を搭載した男気溢れるデスクトップPCだと確信していたのです。

そうは言っても、近年のノートPCの価格破壊ぶりには、大きく興味を抱いていたのは事実。さらにディスクにSSDを搭載した製品が出回ってきているこの１、２年、浮気心がくすぶり続けられます。そんな、neutralな気分でいた先月、最新型の「Macbook Air」が発売されました。最新型のIntel CoreシリーズCPUと、128GのSSDを標準搭載。さらに驚かせたのは、88,000円～という驚きの価格。その時の私は「スティーブ・ジョブスになら抱かれても...」と心が倒錯し、Macbook Airの購買欲にとりつかれたという次第であります。

見かけだけじゃないMacbook Airの実力

Macbook Airが届いたその日、私は一心不乱にセットアップ作業を進めようと思ったのですが、そこはApple、やはりさすがだなと感心しました。通常Windows PCを買ったら、ネットワーク接続等から、「ダサい」ソフトウェアのアンインストール作業までの地味な作業を延々とやることにある。

Macの場合、電源をつけてからの始まりがまるで映画のような演出で、さらにインストール作用も最小限になってました。これがコンシューマ市場で圧倒的に支持される理由なのだと、改めて感心したしたのです。

今回、まずインストールしたのが仮想化ソフトウェアParallels(http://www.parallels.com/jp/)。そしてその仮想環境上で、Windows 7、Linux ubontsu、Crhome OS、Andoroidmulatorを矢継ぎ早にセットアップしていき、最終的にWindows 7にMSDNをインストールでセットアップ完了しました。

ここまでで感じたことが、仮想環境上のWindows 7の性能が快適過ぎることです。Windows 7なのに起動時間が全然違う。そのため、我が家のWindows デスクトップPCが全く登場しなくなりました。「何故ここまで？」と思い立ったので、簡単なプログラムを作成し、MacbookとデスクトップPCで実際に比較してみましたのですが、意外にも実行速度はあまり変わりません。なるほど、この快適な性能を実現しているのは、SSDによる高速なディスクアクセス性能が影響してるのでしょう。見た目だけじゃない、最も基本的な機能である「速さ」を低コストで実現できるのは、OSから自社研究している高い技術力、世界屈指の部品調達力、ユーザ視点の設計思想がAppleに存在するという証明でしょう。

Mac OS Lion のインタフェースへのこだわり
もともと、MicrosoftはMS-DOSを背景としたCUIの上に、GUIを乗っけているという思想であるため、すべての操作をキーボードで行えるように設計されています。対極的にAppleはマウス等のGUIを中心としたインターフェースを重点的に設計しています。それが今では、それがマルチタッチという新しいインタフェースに活用されているということだと思います。（このワタクシ、徹底的にマウスを使用せずに、変態的なまでにショートカットキーを操るWindowsユーザなんです。やはりキーボード操作位はなんとかならんのかと思いました。。）

そんなWindowsで育った肉食系な私ですが、最新のMac OS Lionのマルチタッチの出来映えは秀逸に感じられました。３本指スワイプによるアプリの切り替え、Safariでの２本指スワイプによる「戻る・進む」（履歴の移動）は非常に直感的で操作しやすいです。Google Chrome は、今後Lionへの完全対応に向け、従来３本指スワイプだった「戻る」のジェスチャーを、２本指に変えると発表していました(http://headlines.yahoo.co.jp/hl?a=20110729-00000023-mycomj-sci)。３本指スワイプの恩恵を受けた私にとって、Chromeの仕様変更を応援しています。

また、OSバージョンアップにより縦方向の２本指スワイプによるスクロール方向が上下逆転したそうです。iPhone, iPad等のインタフェースを共通化が目的とのこと。iPhoneを使用している私にとってはありがたい話ですが、Macbookを継続利用している人にとってはたまったものじゃないと思うのです。しかし、そんな仕様変更を（設定もなしに）大胆に実行してしまうのがAppleらしいというとこでしょうか。Appleのインタフェースへの異常なまでのこだわりに感心と驚きを感じた次第です。

革新と互換性のトレードオフ
スティーブ・ジョブスは「革新にとって互換性は最大の障害である」と言っていたとか。私もソフトウェアを設計・開発するにあたり、この言葉をよく思い出します。長年使用してもらっているお客がいる限り、互換性は重要視されますが、そこだけにこだわると革新的で本当に「欲しい」と思えるものは決して出来上がりません。モノを作る際に「互換性」だけを重視すると、開発者は「どうあるべき」かも考えず、創造することを辞退します。これはモノ作りを生業とする人間にとってサボタージュに値する。こんな低いモチベーションでは、よいモノは決して出来ない。
　「何かと似ているものを作った場合、使う人は互換性に文句を言うが、創造性に溢れ、全くの革新的なものであれば、互換性について文句を言う人はいない」が私の持論です。人間新しいものを作ったようで、実は何かに似ていることが多いし、既存のものをちょっと変えたようなものはやはり互換性を使う人は言ってくると思う。

だが、互換性がどうのこうの言われたときこそ、さらにゼロベースで本質を捉え直し、もっともっと創造的で革新的に考えて、初めて創造性のある作品に仕上げる必要があると私は思います。Macbook Airが出来上がるまでに、様々な開発者の思いやドラマがあったのであろうと思いながら触ると、それは感慨深く感じられ、一つの仕様変更さえ愛らしく思うものです。

----
PS：天王洲のスターバックスでコーヒーを飲みながら、Macbook Airで「創造性」を語る今の私は、薄っぺらい人間だと自認しようと思う訳で。

プログラマー飲み会

お世話になった協力会社のメンバーを送別する飲み会に参加してきた。飲み会の会場は京急蒲田の商店街の真ん中にあり、３００円均一の料理、発泡酒の生ビール、不自由そうにメニューを繰り返す中国系スタッフと、デフレな世の中をまざまざと感じるお店でした。

さて、今回送別した方は私が尊敬するプログラマです。ズバ抜けてコーディング技術が高く、さらにJavaの知識も深く広い。彼の書いたコードはとてもシンプルで分かりやすく無駄がない。インテリジェンスとモノ作りに対する愛情がコードからにじみ出ている。

宴もたけなわになり、そのスーパープログラマが飲み会の最後にスピーチし始めたのだが、酔いも手伝って内容が非常に熱かった。

「ソフトウェアエンジニアとは労働者ではなくアーティストだ」

「製品を作っているのではなく、作品を作っている気持ちが必要だ」

飲み会の席でこんな言葉を語れるプログラマに出会えることは非常に稀な経験だ。

日本のソフトウェア産業はクラウドという時代を迎え、大きく変わりつつある。企業は自前で「作る」ことをせずに、世界中で使われている優れたサービスを「使う」時代となった。そんなクラウドの時代では、Google, Microsoft, IBMのトップベンダー、そして世界中の新興企業との競争相手となり、より「使われる」サービスを提供した企業が勝ち残る。 このまま今の日本のITゼネコンベンダーが、旧態依然と過ごしていけば間違いなくビジネスを縮小させていくだろう。

まさに今までの日本のソフトウェア業界は江戸末期。多重請負構造という封建制度。日本語の壁という鎖国制度。

今後は日本古来の請負ビジネスが縮小し、中小ソフトハウスの倒産が発生する。出来ないプログラマは自然淘汰されていく。（ましてやプログラムを読めないシステムエンジニアっていう部類は真っ先に淘汰されると思う。）「使われる作品」を提供できるエンジニアでなければ、この世界は生き残れない時代になってしまった。

「作品」を提供できるプログラマーはあの飲み会の中で何人くらい出てくるのだろうか？

我々は良い「作品」を作らないと、１０年たって発泡酒も飲めなくなってるかもしれない。

人に上下なし。工程にも上下なし。

「超上流」という言葉が一昔前流行していた。多分データさんが普及させている考えだと思われる。設計作業等を「上流」と呼ぶ傾向があり、さも「製造工程」（プログラミング）が「下流」であるかのような言い方である。この「上流」、「下流」の言い回しが日本のソフトウェア業界をダメにしている。

ある社内会議に参加していた時に、開発品質について議論となった。その社内会議では、様々な製品を担当するプロジェクトリーダー級の担当者が品質状況を報告し、重要な情報はその場で横展開するという場となっている。

最近は上級幹部も参加しており、あたかも、公開処刑の場のように幹部は担当者に指摘を浴びせる。公開処刑のやり方変わってきて、最近の主流はトヨタ流のなぜなぜ分析だ。「コーディング誤り」、「設計考慮漏れ」等に障害を分類し、どの「工程」で失敗かを議論するやり方。

ただ、この分析であまりにも「ソースコード」が見えてこない。プロセス改善はいいことだが、本当に本質的な改善なのか疑問に感じる。コードが一度も資料として出てこないのに、設計書の書き方や、レビューチェックシートを追加するとか、訳の分からない議論をして満足している。調理をあまりしないコック長が、食材そっちのけで、レシピの書き方を改善してても、そんなレストランにお客さんを来ないと思うのだが。

これはまさに「上流」であるプロジェクトリーダが「下流」のソースコードを理解できないまま、プロジェクトが運営されていることの象徴であると考えるわけで。日本のソフトウェアがダメになっているのはまさにこういう文化だと思う。つーか「上流」、「下流」っていう、この言葉自体をなくさないといけない。

誰がコーディングに工程を持ち込んだ？

　本当に使い勝手の良い製品には、説明はいらないはずである。つまり、マニュアルなんて必要なく使えるものがユーザビリティが高い製品と言える。カタログも必要ない。使って見れば勝手に流行る。それは、とても魅力のある製品であり、そこに説明が必要ないから。

　本当に作りやすい構造には、設計書なぞいらない。それ自体の構造が最適化されているため、改修もしやすく、構造自体が作り手にさらなる創造を与えるから。

　本当に美しいコードには、他に何も必要としない。それ自体が全てを語る。

　コードを書くとは、知性、感性、創造の活動と考える。本当のプログラマーのコーディングとは、設計、製造、テストという工程というものは存在しない。ただ感じ、考え、書いて、確かめるという、単純な創作活動だ。誰がコーディングに工程を持ち込んだ？

　ソフトウェア開発において品質専門組織というのが存在する会社があると思うが、そんな組織になんの価値がある？本当にお客さんに評判の料理を出すレストランでは、多分レシピの書き方にこだわっているレストランがあるとは思えない。素材、技術、調理法に重点をおいて、調理人が切磋琢磨しているはずで、マネージング力だけでおいしい料理が出来上がるとは思えない。日々の調理技術を磨き、湧きたつアイディアを何度も試作し、試行錯誤した結果、本当においしい料理ができあがるはずだ。そして本当の有能なマネージャはそうした思考試作を数多く経験した人間ではないか？

デザインパターン

デザインパターンはとは、書籍「オブジェクト指向における再利用のためのデザインパターン」において、所謂GoFと呼ばれる先人たちが、ソフトウェアに導入にしたオブジェクト指向におけるプログラム設計のパターンです。

これらのデザインパターンを使用してクラス設計することで、開発チーム内の用語統一化が進み、意思統一が図りやすくなります。

GoFのデザインパターンでは、23のデザインパターンが用意されています。

生成に関するパターン

• Singletonパターン
• FactoryMethodパターン
• AbstractFactoryパターン
• Builderパターン
• Prototype パターン

構造に関するパターン

• Adapterパターン
• Bridgeパターン
• Compositeパターン
• Decoratorパターン
• Facadeパターン
• Flyweightパターン
• Proxyパターン

振る舞いに関するパターン

• ChainOfResponsibilityパターン
• Commandパターン
• Interpreterパターン
• Iteratorパターン
• Mediatorパターン
• Mementoパターン
• Observerパターン
• Stateパターン
• Strategyパターン
• TemplateMethod パターン
• Visitorパターン

Singletonパターン

Singletonパターン(シングルトン)を使用する場合、そのクラスのインスタンスが1つしか生成されないことを保証することができます。

Singletonパターンでは、様々なクラスから呼び出しが可能となります。

ただし、ステートフルに実装してしまうと、グローバル変数のように、プログラムの依存性が煩雑化し、構造が悪化するケースがあります。

安易にシングルトン化することは、非常に危険な行為ですので、十分に考慮する必要があります。

実装例

• コンストラクタはprivateで定義する。
• staticで、かつprivateで自分のインスタンスをもつ。
• staticメソッドでgetInstance()メソッドを定義する。

---


public class MySingleton {
private static final MySingleton singleton = new MySingleton();
private MySingleton(){}
public static MySingleton getInstance(){
return singleton;
}
}


---

誤った実装例

以前、以下のような中途半端なSingletonを見たことがあります。

---


public class MySingleton {
private static MySingleton singleton;
private MySingleton(){}
public static MySingleton getInstance(){
if(singleton == null){
singleton = new MySingleton();
}
return singleton;
}
}


---

上記の実装を行った場合、getInstance()が非同期呼び出しに対応できていません。

そのため、getInstance()をsynchronizedする必要が出てきます。もし、synchronizedした場合、呼び出し単位で同期をとるため、性能への影響が発生します。

ハーバード白熱教室

マイケル・サンデルさんの東京大学での講義がNHKでやってるのを見ました。

以前も海外バージョンで放送されているのを見た覚えがありましたが、今回の講義は、日本を取り巻く具体的問題を取り上げているため、非常に面白い。

「正義」を以下の３つの考えを元に議論を進めていた。

• イギリス功利主義哲学者ベンサムの「最大多数の最大幸福」
• ドイツ哲学者カントの「人間の尊厳に価値をおく」
• 古代ギリシャ哲学者アリストテレスの「美徳と共通善をたたえ育むこと」

３人の船員と１人の給仕「リチャード・パーカー」が救命ボートに乗り、気分が悪くなった若い給仕を殺して、その肉を食べて生き延びたという事例から、議論を行い、道徳観を浮かび上がらせている。

そして原爆と謝罪。コミュニティに対する考え。非常に楽しくテレビを見れたわけです。

インパール作戦―最初からデスマーチ―

野中郁次郎さんの講演を聴く機会があったのですが、いくつかの深い話を聞けて感心したわけです。まさに賢人と言っても、過言ではないと思います。そんなきっかけから、以前買った「失敗の本質」を読み直したわけです。この日本的な組織作りに関して、いかにも野中さんらしさのある、非常に鋭い考察がされている。

さて、私がこのまえまで進めていたプロジェクトが10月に完了し、やっと一息つける状態になったわけですが、乗り越えてみたものの様々な反省点がある。何と言っても、プロジェクト当初からデスマーチ化することを予想し得るほどの、超短納期なプロジェクト計画に無理があった。本来は、納期というものは大概プロジェクトを担当する人間が、本来計画するもの。ただし、今回は部門の長が先に納期を決めてしまった。

たしかに、最近の市場の要求の早さから、納期をより短くしたいという経営者の考えは分かるが、とは言っても無理は禁物である。やはり、その中で様々な構造の問題を抱えたままの出荷となり、今後のメンテナンスでそれらを改善するしかない。

さて、今回のプロジェクト計画における、意思決定プロセスがいかにもインパール作戦の牟田口司令官の意思決定と類似していたことが、非常に関心深かった。様々な参謀が「司令官が言ったことだし。しょうがない」という空気を読んで、作戦を下していくという雰囲気も、似ているに違いない。そして、そんな無茶な目標に対して、帰納的計画を設定し、そして兵隊をデスマーチに送り込む。

誰が牟田口司令官を止めることができる？

それは、彼の直近の部下が死ぬ気になって止めること。

帰納的計画ではなく演繹的計画のもとに、精神論ではなく論理的な考えのもとに、机上ではなく現場主義で。そんな覚悟のある人が、牟田口司令官を止めることができるのでしょう。