ウェブ時代 5つの定理
- 作者: 梅田望夫
- 出版社/メーカー: 文藝春秋
- 発売日: 2008/03/01
- メディア: 単行本(ソフトカバー)
- 購入: 29人 クリック: 4,693回
- この商品を含むブログ (429件) を見る
梅田望夫によって集められたシリコンバレーの賢者達による金言集+解説で構成されている。
良い点としては英語/日本語の言葉の違いもあって、なかなかこういった言葉を集中的に浴びる機会はないと思うけど、効率的に成功者/実績者が語る金言に触れることが出来る。また、こういう言葉が日常的に飛び交っているシリコンバレーの雰囲気も同時に感じ取ることが出来る。
自分としては今まで実践しながら掴んできた仕事をする上でのポイントとかポリシーみたいなものが合致して、うれしかったなぁ。確かに集められた言葉はネットの世界で成功してきた人たちの実践に裏付けられたものなので、そういう意味ではこの本は実践書としても十分活用できる。
合致した文章と考えをまとめるといかのような感じ
- チームワークに根本にはお互いの尊敬と共通の目標の認識があること p83
-
やっぱり複数名で何かをやる時には目標を認識してもらうこと
レベルの高いチームを作るにはお互いのスキルに対する劣等感を越えたスペシャルパートナーの意識がないと上下が生まれてパフォーマンスが下がる - チームの理想のサイズはランチテーブルを囲める程度(最大6~8名) p98
- 10名以上になると意見の収集が困難になる
- マネジメント重視でなく行動重視 p100
- 口だけ、指示だけの人が多すぎる。結局は何かしらアウトプットしなくては何も進まない
- ライン(筋肉)とスタッフ(頭脳)を分けない p102
- 一番早いのは考えた人がその場で手を動かして作ることだと思う
- ソフトウエアにはまだ可能性はある p158
- ハードウエアは競争が働き均一化されるが、ソフトウエアは強烈なインパクトを生み出せる可能性がある唯一のジャンルだと思う。
- 普通の会社になろうとも思わない p186
- 会社のポリシーを明確にすれば上場しても市場の論理に振り回されずに済むのではないか。また、そのポリシーは明確にしてもよいのだということ。
- 重要なのはタイムマネジメント p202
- 情報を得ることは簡単になった以上、時間をどう使うかでアウトプットされるタイミングが全く変わってくる
- 自発的/能動的に仕事に取り組む p203
- 自分で考えて自分で動くことが高いレベルでの仕事のし方だと思う。それぞれの動きが有機的に結びついて会社の求心力になることが理想
- 会社は質問によって運営している p208
- それぞれが考えて動く際のヒントは全て決めるのではなく、どうすればいいか?を社員に質問してしまうこと。共有するレベルを会社の課題/問題点にまでレベルを上げてしまうこと。
この本全体に一貫して通じるシリコンバレーの世界へ誘われているような気もして。あー、やっぱり自分の目指す方向性は確かにここにあるのだなぁなどと思う。
同時にシリコンバレーは速さの中でチャレンジする歴史があってこのような実践に行き着いていることを考えると、日本でも素直にこのカルチャーを実践しても良いと思うし、それはすでに可能な環境になっていると思う。J
</div>スティーブ・ジョブズ 神の交渉力
珍しく本屋でついでに買ってしまった本。ジョブズが何で人々を魅了するのか。そのヒントみたいなのが少しでも見えたらいいなぁと思いつつあまり期待しなかったけど、
スティーブ・ジョブズ神の交渉力―この「やり口」には逆らえない! (リュウ・ブックスアステ新書 48)
- 作者: 竹内一正
- 出版社/メーカー: 経済界
- 発売日: 2008/05
- メディア: 新書
- クリック: 50回
- この商品を含むブログ (105件) を見る
掴ませられちゃったなぁという感じ。amazon のレビューも後から気付いたけど、同じ感想だなぁ。まったくレベルが低い。
スティーブ・ジョブズがいかに常識外れで、汚い手段もとって、信念を曲げずに成功を収めてきたのかということを非常に誇張しながらエピソードを紹介している。ワイドショー的な文章という感じ。このすごいでしょ/ひどいでしょ感を出すための誇張ぷりに失笑してしまう。
タイトルに交渉力とついているが、ただ交渉によって契約したとかのエピソードが紹介されているだけで、なぜ交渉力があるのかは全く解説されていない。
最後の方は有名なジョブズのスタンフォード大学での卒業スピーチの引用をしているけど、訳も正確ではないし紹介しているだけだし。それならスピーチ全文を読んだ方がためになるし。
筆者はアップルにもいた人みたいだけど、ベンチャー中にいればこの程度のことならジョブズでなくてもスタッフレベルでも経営陣でも起こす人はいるし、それが起きたところでベンチャーなのだから別に。。と自分は思うし。大事なのはそういうバタバタもありながらも人を魅了したり、熱狂的なスタッフと一緒にやれているかどうかだと思うので、そのツボみたいなのが分かってないとどうでもよくなってしまうよなぁ。
読んでみて、「結局で何?」と思うだけの何も知的情報を得られない本。リアルの本屋に行ってついで買い時にはもうちょっと中身読んでからにしなきゃな。
</div>不思議な体験 電話とメール
今日仕事でなんとも不思議な体験をした。
通常、電話とメールは基本的には機能的特長が違うので、同時に使うことはないと思うのだが。。。以下、今日の電話のやり取り。
- S社: こちらS社のAと申します。今から xxxxx@xxx.com へメールを送りたいのですが間違いありませんでしょうか?
- 私: ?。。はい。アドレスあってます。
- S社: では、これからメールを2通お送りいたしますので、受信の確認をお願いいたします。
-
私: ?。。今からですか、、はぁ。。 # すでに理解不能状態
# メーラにて受信処理、メール受信される - 私: あっ、メール届きました。
-
S社: それでは2通目を送らせていただきます。# この後若干の説明
ありがとうございました。失礼します。
その場でなんかおかしいなと思ったのは、このやり取りだったら電話要らないじゃんということ。
- メールアドレスは情報として向こうに伝わっているのでこちらに確認を求めることではない
- メールが届くかどうかを確認したい時は送ってみればいい、宛先不明なら error メールが返ってくるので
- メールサーバまで届いているかも不安だったら BCC に自分のアドレスでも入れておけばいい
- 電話で話したことはメール本文に書いてあるので、話さなくてもいい
いまどきメール送受信の信頼性を疑う必要はない。それを電話で補完する必要もないと思うし、、、今回のをもっと簡潔にやってみるなら、
「今メール送りますからね~」
「はいはい~、今来ました。」
「確かに届きましたね~ 良かった良かった」
ね。あほらしい。。。電話とメールを同時に使うことはやっぱりない。
このムダをフロー化しているこの会社はちょっと観点が狂ってしまっているのだろう。
仕事上、ほとんどのコミュニケーションはメールで完結できると思ってるし、逆に電話は緊急性が高くない限り不確実で無駄な部分が多いと思うのでほとんど使わない。ムダはなくしたいと常に思っているので、異常に気になった今日の出来事。
LEVI’S 501XX 1955年モデル
大学の時から履いていたジーンズは一応ビンテージモデルの走りだったりして10年間はきつぶしたらさすがに穴があいてしまった。さすがにこれでは会社には履いていけないし、新しく生ジーンズを買った。
やはり Levi’s 501XX でいくでしょう。501XX もモデルがいくつかあって履いた感じ一番スタンダードな形の1955年モデルにしてみる。
買ったところはここ。定価の¥1,000引きくらいかな。サイズは縮んだ後のサイズを参考にゆったり履きたかったから33インチ。
さて、まずはノリを落とすために水洗いしなくては。また、10年くらいかけて楽しめるといいなぁ。
飲み with K&I
KとI は新卒で入った最初の会社の同期。一番最初の泊り込みの研修の同じクラスで、その後配属先もバラバラで一度も一緒に仕事はしたことはないが、今だにつながっている社会人として長い友達。
最初に出会ったのが1999年4月だからもう9年以上が経っているんだなぁ。その間彼らは辞めずに異動も経験しつつ本社へ(Kは北海道から東京へ)、こちらは3.5年で辞めて3回転職、5社目か。
だいぶそれぞれ経験してきたことは違うと思うのだけど、話始めると自然とあのころのノリのまましゃべれてしまう。
人を通してフラッシュバックできるのは、自分を振り返るられるポイントづくりになる。
みんな結婚して、子どもが出来てで確実に環境は変わっているのに、面白いもんだ。
また、会おう!!今度は家族ぐるみで。
TIME_WAIT を早めに消す on CentOS
異常にwebの表示が遅くなった時の原因が TIME_WAIT の大量発生だった。PHP だと生じやすいなぁ。
CentOS 4.5 finall にて TIME_WAIT を短くするための方法。
-
状況</p>
- web と DB を別サーバでネットワーク経由のデータやりとり
- DB サーバ側は TIME_WAIT ほとんどなし
- web(phpで作ったもの) にて TIME_WAIT 多めに残る それでも 150セッションくらいか
- 確認
# netstat -an | grep -i time_
(状況確認)
# netstat -an | grep -i time_ | wc
(行数として確認)
- 作業
# cd /proc/sys/net/ipv4/
# more tcp_tw_recycle
# echo ‘1’ > tcp_tw_recycle
特に再起動などいらず即反映される。
重めなページを読み込ませつつ
# netstat -an | grep -i time_ | wc
を定期的に見れば数が減っていく速度が速いことが分かる。
Google Developer Day 2008 report
Googleの人たちに直接触れたことがなかったので、登録していってきた。目的はプレゼンテーションの中身と言うよりかはそれを話している人たちがどんなものなのか。の方が興味があったりして。
3セッションほど聴けた。最後のエンジニアの日常の紹介では正に梅田望夫の本と同じ内容が紹介されていた。それ以外の部分で気になった点は、
-
カルチャーを重んじる</p>
- 人の邪魔をしないとか新しい人を受け入れる など
-
情報を共有することを徹底する
- グローバルにやっているのでリアルなコミュニケーションより基本メーリングリストベースなのだろう
-
リフレッシュする
- 結構日本人的には休むことに関してネガティブな感覚が根強いので、リフレッシュベタだと思う
-
完全にボトムアップ型
- プロジェクト参加も自分で手をあげて参加するそうな
- 大企業に多い 言われてやる型 では成り立たない。逆に言えば言うだけの人はいらないと言うことだろう
080610 Google Developer Day 2008 @パシフィコ横浜
KML
Mano Marks
# 最初質問 KML使ったことある人 聞く
# 話してほしいこと聞く
KML とは (http://code.google.com/intl/ja/apis/kml)
- Google Earth のために最初開発された位置情報などの静的ファイル形式
- Google Earth API として
- Google Earth 以外も連携可能になった
-
チェックしてみてください
- http://code.google.com/intl/ja/
- もうすぐ日本語化される
Google Earth を見せながらデモ
- Google Earth 上で Place Mark 追加
-
Google Earth 上でコピーして KMLファイルがテキストに貼れる
-
mark のスタイルとサイズ、高度、座標軸の指定など可能</p>
-
記述方法は HTML タグのように
, のように囲む
-
記述方法は HTML タグのように
-
mark のスタイルとサイズ、高度、座標軸の指定など可能</p>
Google Maps 上でも Place Mark がつけれる デモ
- ある場所にマークをつける
- ファイルに保存すると Google Earth で見れる
-
KML ファイルはローカルではなくリンクによってファイル指定が可能
- Google Maps 上のマークをコピーしてテキストエディタでペーストするとコードが貼れる
- 逆に KML として Google Earth にペースト可能
Google Earth にてデモ2
- tokyo の年度ごとの人口変動を見せる
-
3D 上で各区市 の人口が高さで表示されている
- 増加したところ赤、減少 青 出表示
- 動画再生のように 1955年から2015年予測を変動させた Community が作ってくれたKMLファイルらしい
-
記述
を必ず決める タイムスライダーを見せるため </li> </ul> QA その1
- Q1 紀元前も可能?
- A1 TimeSpan は紀元前も可能
- Q2 Event も制御できますか
- A2 時間を制御している
- Q3 高さのマイナス 海の中とか扱うためにマイナスの値が使えるか
- A3 マイナスの値は取り扱いは出来ない KMLでは定義可能、Google Earth では出来ない
Google Maps と Google Earth を統合したもののデモ
-
Maps API に1行追加することで Earth API と連携できる</p>
- # code.google.com からたどれるようだ
- 4つの Google Earth の画面をブラウザ上で操作できる
# うまく Google Earth 表示できず
Google Earth デモ3
- Places のチェックボックスをはずす
- サーバとの通信を削減できる
- デート相手を探す情報を表示させる
-
している ローカルからでなくサーバへの問い合わせ? </li> </ul> QA その2
- Q1 古い地図データは持ってこれるのか?
- A1 ある時点での地図データを使っている ユーザが地図データをオーバーレイすることは可能
- Q2 Google Earth API でも KML でもマーカー作れるけど どっちがいいの?
- A2 データ量が多い場合(マーカーの数が多い)は静的ファイルで格納したほうがいいKMLかXML、情報が少ない場合はダイナミックでもいい Earth API
Google Maps API for Flash
加藤定幸
Google Maps API for Flash
- Flash 上で Google Maps を表示させる
- 080515 にリリース すでに開発してくれているユーザいる
作成手順
-
ビルド環境の準備 Adbe SDK でもいいしフリーでもいい</p>
- swf ファイルの生成
- ActionScript ソースファイルを作成
-
Maps API Key の取得
- API Key は AJAX用のキーがそのまま使える
作成手順 詳細
- Interface Library が必要 最新版推奨 verison1.4
記述方法
- パッケージをimport する必要あり
-
インベントリーリスナー
- 座標情報、maptype などを定義
- Mapクラスを拡張
- MXML ファイルを作成 => コンパイル swf ファイル生成 => サーバにアップする
制御
- イベント 4種類あり
-
コントロール 4種類あり # Google Maps と同じイメージ
- ControlBaseを拡張することでカスタマイズ可能
- オーバーレイ 4種あり
- Poloyline:線をかく、Polygon:塗りつぶし
- 画像表示可
デモ いろいろなアプリケーション紹介
- マーカー位置をドラッグアンドドロップ移動させる
- 移動後の拡大縮小時に地図の中央にマーカーが来るように制御
-
ユーザ作成 飛行機操作
- 飛行機が飛んでいるようなもの 3Dマウス?操作 ゲームコントローラーみたいなもの
- プライオリティに応じてマーカーの表示非表示が可能 ズームすると現れるマーカーがある
- マーカーをクリックしたときに Flicker から画像を引っ張って表示する
まとめ MapsからいくつかAPIがあるので比較
- Flash 版 視覚効果生かしたい
- Ajax 版 普通のwebサイトに埋め込むとき JavaScriptが得意な場合
- Static 版 静的なコンテンツが取得できればいい場合
最後に
- 日本のFlash製作能力はおそらく世界一
- ノウハウを生かしてアプリ作ってください
- 開発チームは日本発のアプリケーション期待されている
- 公開するときは英語のページも作ってください
- http://code.google.com/intl/ja/ 見てね
QA
- Q1 携帯は?
- A1 Flash Lite 対応していない 今後も多分なし 互換性維持するのが難しい
- Q2 Javascript と Flash パフォーマンスどっちがいい?
- A2 評価したことない 前なら Flash だけどブラウザも向上しているのでよく分からない
- Q3 オフラインだと使える Javascprit だとだめだけど、KML みたいに出来るか?
- A3 Flash 版同じようにサーバ通信が発生しない ローカルファイルのアクセスはサポートしてない
- Q4 Airアプリは?
- A4 強い要望ある どうするかは未定
- Q5 Ajax 版で出来て Flash版で出来ないことは
- A5 Flash版ばかりやってたのでよく分からない。。
- Q6 カスタムアイコン 影つけられる?
- A6 やればできるけど、どうなっているか分からない
ソフトウエアエンジニアの日常
藤島さん
Googleのカルチャー
- カルチャーを重視している会社
- すべてを明瞭に
- 出来るだけすべての情報を共有する
- 意思決定は命令ではなく社員の総意に基づいて判断する
- エピソード: 会社の移転先を決めるときに 社員の住んでいるところをみて移転先を決めた 合理的に決める
- 他人の仕事がしやすいように
- 20%の時間を使ってグループ横断活動で支援
- メンター: 新しいエンジニアについてヘルプする
- 個人攻撃は起こらない
- 自ら始める
- 問題があれば 自ら直す
- 完璧になるのを待つのではなく試してみる
- 結果には柔軟かつ迅速に対処する
- 今使えるものを使って目標を実現する
- 安く効率的に実現する方法を考える
- ex.) 非効率な作業を見つけたらツールを作る
- 周囲の人を楽しませる
- 地味な仕事、泥臭い作業にも光を当てる
- 世界を変えられることを忘れない
ソフトウエア開発
- 世界に20カ国以上に50箇所オフィスある
- すべてのオフィスは対等 自分の近くのオフィスに参加する
-
コミュニケーション 1箇所のオフィスで完結するものなし
- wiki、チャット あらゆるものを使う
-
アイデアがひらめいたら 20% プロジェクトとして開始する ボトムアップ
- 認められたらメインプロジェクトになる
- 少人数 変更も柔軟にできる
-
ソフトウエアエンジニアが開発のすべてに携わる
- アイデアから運用保守まで すべてのエンジニアがかかっている
- 必要な文書を作る、不要なものは作らない
- 百文書は1デモにしかず # まず作って説明する
コーディング
- 言語 C++、Java, Python, Javascript
- 読みやすいコード スタイルは全社で統一 スタイルにあったコードをかけるか社内認定がある
- 1つのソースツリーを全世界で共通
採用活動
-
開発以外の重要な例外 採用活動への協力</p>
- 社風に会うか お互い Happly になるか
- 一緒に働きたいと思うか
- 結構エネルギーと時間を使っている
業績評価
- 一緒に仕事した人の業績評価する 四半期ごとに目標の設定と評価している
- メリット 目立つだけでなく重要な地味なものも評価される
- 社員間の信頼関係が前提
遊び
- 遊びと仕事は両立する
- チームでリフレッシュ
スピーカーの例 紹介
- 入社動機 優秀な中でやってみたい
- 優秀だけでなく人間的魅力ある人が多い
- 意見に対して誰が言ったかではなく、正論か通りやすい
- 動きが早い すぐ世界に出て行く どんどん改善されていく
- エンジニアが 尊重/信頼されている
- 良いソフトウエア開発のために泥臭いこともやる
1日の過ごし方紹介
- 10:00 メール USはまだ起きているかも
- 11:00 コードレビュー
- 12:00 昼飯
- 13:00 コーティングに没頭
- 16:00 tech talk を聞く 他のプロジェクト、技術話題聞く
- 17:00 メールチェック後、コーディング
- 18:00 夕食
- 19:00 三度、コーディング
心がけていること
- 分かりやすいコードを書く
-
他人のコードを尊重する
- 必要ならリファクタリング
-
正確かつ簡潔なコミュニケーションをする
- 文化が異なる、英語を使っている
-
仕事以外も目に向ける
- TechTalk(他プロジェクトの紹介、技術紹介など) などに参加する
- 良き仲間と思われているかどうか
- ボトムアップの会社なので指示待ち、承認待ちをしていては進まない
QA
- Q1 意思決定の承認フローは?
- A1 プロセス、承認を固める文化ではない
- Q2 20%プロジェクトからメインサービスになるにはどうなっていく?
- A2 やっている人たちの熱意 デモの力の入れよう いろんな人に話す。最終的にはマネージャの承認を得る
- Q3 テスト環境は?
-
A3 詳しくは言えないが自分のテスト環境は自分が作る
- 自分が直したことで解消されたことを証明する 担当チームへレビューする
iPhone3G 7/11発売
あー、今年中って12月くらいかと思ってたけどこんなに早いとは。。。
7/11に出るのね。
機種変してまだ3ヶ月くらいなのに。。。でも iPhone なら Docomo から乗り換えても全然OK。imodeメールはなんとかなるでしょ。Softbank で新規で iPhone 買って後から番号移してって出来ればベストだけど。どうかな。
USで発売した後にちょっと触らせてもらったけど、あの感動は忘れられない。最近電子機器類をいじって感動したのは iPhone くらいだと思う。それくらい User Interface がすばらしくって気持ちよくって。
3G、無線LAN、フルブラウザ、iPodと携帯単体としてみてもここまで機能を持っていて魅力的。
あーやっぱり買ってしまいそうだ。。。もち16GBでブラック(もう決めてる)。いや、もう買ってしまう。
飲み with Fさん
Fさんとは最初の転職先でなぜか紹介を通じて知り合った方。それ以来なにかと自分の転機(転職)に会ったりして都度応援してもらったり、たまにメールいただいたりな方。
前回会った時は前職に入る時なので、2006年3月くらいかな。結局思惑外れて2007年2月から今のところだからその事も伝えていなかったりして、、、自分の頭の中で急にタイムスリップしてあのころの感覚が戻ってきた。
確かにあのころは鼻息荒くって自分で何かやってやるんだ!!って気持ちで転職したよなぁ。それ自体にウソはなくって確かにいろいろやってみたけど、10ヶ月で次の転職をしているので客観的に見れば短すぎかもしれない。
振り返ってみればあのころいろいろやってみた後にある意味の見切りをして、新しいフィールドに移ったのは良かったと思う。あのタイミングで辞めてなければ今のプロジェクトには出会えなかった訳で、それはすごく幸運だったし、実際やってみてとても面白い経験をしたと思う。
時々しか会えない方と話すと自分のそれまでやってきたことを客観的に振り返ったり、今やっていることの意義を整理できたり出来るので、すごくいい場だと思った。もう少ししたら今やってきていることも何がしかのまとめが出来る時期になりつつあるかと思うので、その時に自分で何が言えるのかが楽しみ。
また、お会いしましょう > Fさん