THE INTEL TRINITY : インテル 世界で最も重要な会社の産業史
年末の休みに一気に読み切った一冊。
去年読んだ本の中では、いままで知らなかった事を教えてもらった点で一番面白かった本となった。
原題は、Intel 創始者達の集団的 組織の指導を現している。
邦題は、Intel を中心とした、シリコンバレーと、世界の半導体産業の歴史を現している。
いずれの面からにしろ、Intel に対して抱く不可思議な情熱が以下の一言に尽きるのだと言う事を驚きとともに納得してしまった。
それは、HPやIBMが無くしてしまったものを、まだ、Intel は持っている（十字架なのか？存在理由なのか？）という事なのだろう。
TRINITY
二人の創始者と、三番目（社員番号は４番目）の社員をこう呼んでいる。
Gordon Moore
Andy Grove
グローブ が、創始者ではなかった事もしらなかったのだが、ノイス に関しては全く知識がなく、ボケる前に知る事ができて、良かった。。
この三人の人間性と名声と才能が織りなす人間関係により、どれほどの歴史が変わったのだろうと、読みながら呆れる。
本文にも書いてあるのだけれど、確かに、シリコンバレーの企業の話で、創業時からのメンバーが、三人体制で、うまくいったというのは聞いた事はあまりない。このケースも決して仲良しというわけではなかったようだ。
本文にこう記されている
”うがった見方かもしれないが、インテル・コーポレーションの最大の成功要因はその圧倒的な競争力や革新性ではなく、同社が恥部として長年隠し通してきたことかもしれない。すなわち、創業者のうち二人の反りが合わずアンディ・グローブがボブ・ノイスを嫌っていたという事実だ。"
しかし、グローブが単純に、嫌っていたのではないだろうという事も、再三、指摘されている。このあたりは、本書を最後まで読み進めば、人間の矛盾に満ちた態度が垣間みえて感慨深い。
いずれにしろ、Intel の前身となる、フェアチャイルドの失敗からTRINITYは育っていきIntel を存在させる事になったのだろうと思わせる。
それにしても、こんな絶妙の組み合わせで、世界を変えるなんて、まったくもって、現実は想像を超えて面白いものだと吐息をついてしまった。
産業史
ソフトウェアの方は、こんな本で少しは知ってた。
肝心のシリコン（半導体）に関してはまったく知らなかった。
ここには、ソフトウェアと半導体の、近くて遠い物語がダイナミックに描かれている。
これは、いま、クラウドなんぞという、まるでソフトウェアだけで世界を創れるような風潮のなかで、何をもっていまがあり、そして、それは変わってはいないということに気ずくきっかけになるんじゃないだろうか。
そして、この歴史は、本当に面白い！！
Intel は、そう、失敗ばかりしている！！
技術だけでは、乗り越えられなかったであろう、数々の出来事が記されていく。
半導体メモリーから、CPUへの転換にもたついたこと。
中途半端な態度のせいで、技術者に逃げられたばかりか、コンペチタに技術的に
先をいかれてしまったこと。
資金が常に足りなくなっていたこと。
それらを、経営者の決断や幸運などを掴みながら世界の中心として、進み続けていく。
政治との関わりや、Microsoft , Apple などとの交差の綾なども読んでいて、もしも？と思わせることばかりだった。
日本の半導体産業との闘いや、そもそもの、ノイスと日本の関係などは、その後の韓国や中国にも繋がっていく普遍の歴史のように既視感が繰り返される。
それにしても、おおきな産業史の流れのなかで、Intel のTRINITY の個人的な判断、とくに、ノイスのせいで、というか、おかげでというか、その後の Intel vs AMD の確執, APPLEのJobs などが影響を受けていたなんて夢にも思わなかった。
歴史に影響を与える個人の人間性というものに想いを馳せるケースが多いのも、シリコンバレーの特質なのかもしれない。
おわりに
半導体の技術者の集団であり、地頭のとんでもなく良い集団があつまり、率いた組織。
しかも、経営の神様の一人が率いていたトップの企業。
しかし、それを支えたのは、成功の連続ではなく、失敗の連続。失敗を、とんでもないスピードで認め突き詰め、その上で、できるスピードではなく、必要な速さで決断と対策を成し遂げる力だった。
いまの Intel には、感じる事はあまりない。
けれど、まだ、その力は眠っているのだろうか？
ムーアの法則を、諦めないのであれば、大方の想像をはるかに超えた、技術と経営が再現される事が必要なんだろうと思う。
本文にある、2013年まで CEO を務めたオッテリーニの言葉はいつまでも続くのだろうか？
"ムーアの法則を潰した男として歴史に名をとどめたいと思うものは、ハイテク業界には一人もいない。私だってごめんだ"
2015年のまとめ
いまさら感満載ですが、ようやく、年も越えた感が沁みてきたので振り返ります。
私生活のこと
何と言っても、身内の病気が大きかった。
おかげで、精神科系のことにかなり詳しくなりました。
心療内科は、内科だから精神の病は、通ってもダメなのよね。
薬で治ることはないんだけど、使わないのも、難しいんだよなぁ。
行動療法のカウンセリングで、乗り越えられたけど誰にでも効くわけじゃない。
......
このあたりの話は、いつか別のところで書こうと思う。
精神も肉体で支えられているので、社会と合わなくなることは普通にある。
肉体は、欠損だったり動作遅延だったり目に見えることが多いので認知しやすい。
精神の方は、目に見えないのと、理解しがたいので、なかなか飲み込めない。
昔から、わりと、その辺は飲み込める方だったのだが、そのあたりの感覚がかなり拡大した気がする。これは、これから年齢による、知能、体力が衰えて「おかしく」なっていく自分にとっては、贈り物に近い経験だったと思っている。
「過去の経験が今の自分を創り上げている。自分が生きている以上、しなければ良かった経験はないんだと思う。それは、今の自分を否定することになってしまうから。」
という考えは、いまもってかわらないなぁ。
仕事のこと
組織
組織を運営するのは難しい。正解は無いと思ってしまっているので尚更でもある。
まぁ、なので、全てはより良くなるための試行錯誤であると割り切るしかないのかと。
組織については、幾つかの方針を明確に立てて実行した。以下、忘れないように幾つかを書き留めておく。
- 管理職の世代交代
若返りを促進する。これが出来ないと未来はないからね。やらしてみて、ダメだと思ったら短期間でも交代する。再起用もする。 - 変化を評価する
成功しても、失敗しても、変化しなければ評価はしない。重要なのは過去を否定すること。 - 流動化する
組織と人が固定化してしまっているので、箱も人も、どんどん動かす。これによって、批判していた相手の仕事を、自分がしなきゃならなくなったりする。やめていく人、出ていく人も、当然、引き止めない。 - 入り口から出口までの「つながり」をつくる
組織というのは、ひとつながりのパイプのようなもので、その中をインプットとアウトプットが連鎖しながら、価値を生み出していくものなんだろうと思う。
ただ、時がたつとそれは分断され、自分の範囲のインプットとアウトプットしか見えなくなる。それでは、ことがうまく回らないように、邪魔し続ける。結果的に、最小単位の組織をまたいだ動きが必要となる。 - 悩むのをやめさせない
頼まれたことを何も考えずに果たす。問題がおきたら、ともかく、落ち着かせて終わらせる。それで「良し」とする組織の力は断固として承認しない。本来はどうあるべきか、何を望むのか、どうなりたいのかのギャップと悩み続ける組織の状態を維持するようにしむける。
技術
システムの基盤といわれている領域を預かった。
この領域では、パブリッククラウドの提供者が一番進んでいるのは周知の事実。
問題は、そこの技術は自分には公開されないし、自由に使うことはできないってこと。
不自由さをのめば、利用することはできるし、それも必要な選択肢だと理解してる。
まぁ、折角なので、やれるとこまではやってみようと思い、目指せ、「datacenter as a computer」で、コツコツはじめた。
この部分は、また、別の機会にどこかで書くか、話せればいいなとおもう。
いくつか、キーワードを書き留めておく。
- デバイスベンダーと付き合う
残念ながら、いわゆる、メーカから最先端のものは手に入らない。また、SIerからも同様。最先端、つまり、キャズムを超えるものは、ユーザの覚悟からしか選択できないのだしね。 - 製造業から流通業のノウハウが基本
結局、物流が全てだと思う。数々の素晴らしい分散技術のソフトウェアも、霞のうえで動いてるわけではないので。ここが一番難しく、そして、一番差別化できるところ。なぜなら、理解できる人が殆どいないという事実があるから。 - Rack Scaleに変わる
サーバを並べるという形が崩れて久しいけれど、いよいよ、Rack 単位にHWは変わって行くと思う。その先の 部屋単位というのは、まだ先だと思うけれど。準備はしておかないと予想が当たった時には間に合わないからなぁ。
SDSとか、Container、NVRAM、orchestration などなど、いろいろあるけど、それらは実装して運用すれば良いだけの話。
けれども、そこでは、技術だけでない問題にぶち当たる。
そこを解決するのは、「何のためにやるのか？だから何はやらないのか」の決断。
決断の範囲がどこまで広く深くできるか次第だろうと思う。
で、今年は？
興味のある人もいないとはおもうけど、書きたい気持ちはあるんだぉ。。。
必要悪なストレージ
ストレージは、悩みの種だ。
ともかく、トラブルが起きると生命を削られる。なにより解決策が、サービスの停止を伴うものが多くたまらない。
アプライアンスは、保守性や他のインフラの費用と比べると、ネットワークを除けば、価格性能比は最悪だ。
OSS HDFS は、NFS 使ったりしなければ、No Posix のデータストレージとして使えるとおもっている。 data center を借りて、ある程度の規模で運用している、情報処理部門のユーザ部門なら、自前で運用できるとも思う。
メーカに責任を全て押し付けて、絶対治せみたいな文化から、OSS への文化的な壁は乗り越えないとダメだけど。
なんでも、置けるわけではないが、ここへ置く事で、システム全体としては救われていくストレージ領域は、おおい。
ただし、Hadoop と呼ばれる処理系に関しては、一般的なユーザ部門が、自前で運用が持続可能なのか疑問がある。たとえ、サポートベンダーをつけたとしても、現時点ではハードルが高いと感じている。
ただ、SIer や、請負ベンダーに、運用含めた持続性を頼ると、アプライアンスメーカから、そちらへの工数費用が移行するだけで、本質的には何も変わらないことになる。
その問題に関しては、まだ、自分なりの答えは出てないし、現在進行形で、試行錯誤なのだけど、ボンヤリと、カタチは見える気がしている。
蜃気楼じゃないと良いんだけどなぁ。
少なくとも、プロパーがやれば良い、とか、クラウドサービスにすれば良い、というような、局所的な解決策ではないのは、確かだと確信に近いものは産まれている。
OSS は、スタートアップが有効活用しているのが、目立つし、Web系で多様なソフトを使い、作り、モデルを実証している様が喧伝されている。
アッサリ目を眩まされて、目移りしたり、手を出さないとと、思う周りの人が増えて、それは、ナカナカ愉快だなぁと眺めていたりする。
メーカの持ってくるパンフレットばかり見てるよりは、はるかにましだと思う。
自分の仕事が、スタートアップ達と違う点は、持続性をどーやって維持するか、維持する為のリスクをどこでとるか？ なのだろうと、つくづく思う。
同じモデルも、あてはまるけど、真似しても上手くいかない。
こういう真実は、一般的すぎて、何時も、何かを始める時には、都合よく忘れてしまうものだ。
CentOS 6.6 で、Haswell 使ったら、Oracle JDK 7が、まともに動かなかったでござる
結論からいうと、以下のBugに当たっていた。。。
https://access.redhat.com/solutions/1386323
Hadoop の HDP を動かしていたのだけれど、全く、動かなくなる訳ではなく、
通信不能で、Kill や、Fail するものだから、マジ理由がわからずに困った。
これ、はまると思うなぁ。。
みなさん、気をつけましょう。。
企業の壁とエンジニアの知識の共有と老人の消え方
厳密に言わなくても、企業内のシステムに関しては、投資と効果で成り立つ倫理がある。
競合だの、守秘義務だの、大切な、だけども、多分、原始時代までいかなくとも、
人と人でないものの戦いには不利であろうと思われる色々な生存規則。
たまたま、Hadoop をきっかけにして、Open Source に近いところに、
再度、出かけていって、何の役にも立たない年寄りでも、
水先案内になれればと、へろへろな案内をしてきたのだけれども。
あと、わずかになってきて、ふと思う。
随分と、勿体ない事をしているんじゃないかって。
いわゆる、Web系というか、ゲームやら広告やらの、あぶく銭系のドメインと違い、
僕のいる世界は、
競争のために隠蔽するのが良いという世界。
汚染を防ぐ事と、化学反応を起こす事は、別物だと思うのだけれど、
混ぜるな危険な世界観でできあがっている。。
置き土産に、何かしら、種をまこうかなぁ。
アップルシードほどでは、ないにしろ、化学反応は、必要だ。
老人が、媒体になるのは、もうそろそろ、限界だろう。。
Kibana 4 beta2 を Docker で動かしてみる -- boot2docker
Docker Image の作成。
DockerFile とかを、適当に作って置いたので、これを使っている。
https://github.com/guutara/dockfile-kibana4
まずは、boot2dockerを起動する。
MBA20120331:dockerfile-elasticsearch4 guutara$ boot2docker start Waiting for VM and Docker daemon to start... .....................ooooooooooooooooooooooooo Started. Writing /Users/guutara/.boot2docker/certs/boot2docker-vm/ca.pem Writing /Users/guutara/.boot2docker/certs/boot2docker-vm/cert.pem Writing /Users/guutara/.boot2docker/certs/boot2docker-vm/key.pem To connect the Docker client to the Docker daemon, please set: export DOCKER_HOST=tcp://192.168.59.103:2376 export DOCKER_CERT_PATH=/Users/guutara/.boot2docker/certs/boot2docker-vm export DOCKER_TLS_VERIFY=1 MBA20120331:dockerfile-elasticsearch4 guutara$ export DOCKER_HOST=tcp://192.168.59.103:2376 MBA20120331:dockerfile-elasticsearch4 guutara$ export DOCKER_CERT_PATH=/Users/guutara/.boot2docker/certs/boot2docker-vm MBA20120331:dockerfile-elasticsearch4 guutara$ export DOCKER_TLS_VERIFY=1 MBA20120331:dockerfile-elasticsearch4 guutara$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Dockerfile のあるディレクトリで行う。
MBA20120331:dockerfile-kibana4 guutara$ docker build -t guutara/kibana4-b2 . Sending build context to Docker daemon 58.88 kB Sending build context to Docker daemon Step 0 : FROM dockerfile/java:oracle-java7 ---> a643f54fef40 Step 1 : RUN cd /tmp && wget https://download.elasticsearch.org/kibana/kibana/kibana-4.0.0-BETA2.tar.gz && tar xvzf kibana-4.0.0-BETA2.tar.gz && rm -f kibana-4.0.0-BETA2tar.gz && mv /tmp/kibana-4.0.0-BETA2 /kibana ---> Running in a3afe2be6e1d. . . Step 3 : ENTRYPOINT /kibana/bin/kibana ---> Running in 89b1f0b0f6ea ---> ea2d1c42aceb Removing intermediate container 89b1f0b0f6ea Step 4 : EXPOSE 5601 ---> Running in f163b3dd6a71 ---> 1f22d4daead2 Removing intermediate container f163b3dd6a71 Successfully built 1f22d4daead2 MBA20120331:dockerfile-kibana4 guutara$ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE guutara/kibana4-b2 latest 1f22d4daead2 21 minutes ago 768.1 MB guutara/elasticsearch 1.4.0 cffbdbd80f9c 12 days ago 755.9 MB guutara/elasticsearch 1.3.2 e1b42108cc83 5 weeks ago 755.5 MB dockerfile/java oracle-java7 a643f54fef40 5 weeks ago 722 MB chung/centos7-up latest 3a22ebba07c7 9 weeks ago 288.3 MB centos centos7 70214e5d0a90 11 weeks ago 224 MB
これで、Imageは、作成完了。
Container の作成から起動確認
先に、elasticsearch を起動しておく。
MBA20120331:dockerfile-elasticsearch4 guutara$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES MBA20120331:dockerfile-elasticsearch4 guutara$ docker run -d -p 9200:9200 -p 9300:9300 -name el1.4-up guutara/elasticsearch:1.4.0 Warning: '-name' is deprecated, it will be replaced by '--name' soon. See usage. 3338665c2dfb431de5f51889436958e0954e5ed3f37277e5d1f19dadaa95a561 MBA20120331:dockerfile-elasticsearch4 guutara$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3338665c2dfb guutara/elasticsearch:1.4.0 "/elasticsearch/bin/ 8 seconds ago Up 7 seconds 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp el1.4-up
次に、kibana4 を起動する。
MBA20120331:dockerfile-kibana4 guutara$ docker run -d -p 5601:5601 --name kibana4 guutara/kibana4-b2 -e http://192.168.59.103:9200 0311e15a934e95b4e66dd40fec82d7bfc6a7a639b377f2ac9b188f203f522c57 MBA20120331:dockerfile-kibana4 guutara$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0311e15a934e guutara/kibana4-b2:latest "/kibana/bin/kibana 13 seconds ago Up 11 seconds 0.0.0.0:5601->5601/tcp kibana4 90f62a351e15 guutara/elasticsearch:1.4.0 "/elasticsearch/bin/ 26 minutes ago Up 26 minutes 0.0.0.0:9200->9200/tcp, 0.0.0.0:9300->9300/tcp el1.4-up
"-e" で、elasticsearch の動作している、URIを指定する。この場合、先ほど起動したURIとポートを指定した。
ブラウザで、確認すると、以下のように表示されたので、動作完了。
まとめ
kibana4を、作ったので、公開してみた。こっちは、色々、使えそうだ。
