おいぬま日報(不定期)

@ [work] 徹夜だわっしょい

土日出たくないので今日は徹夜。昨日も帰ったの2:30とかだったし、今週と来週は山場だなぁ...

@ [fswiki] FSWikiFarm

期待age。何か貢献したいところですが*1、どうにもこうにも仕事がねぇ...とりあえず生暖かい目で見守ります。

@ [linux] Sylpheed-0.9.1

メールの送受信がちっと重くなったような気がする。まぁストレスが溜まるほどではないんですが。いやーでも素晴しいソフトです、これ。Outlook Expressばりの機能があるし、操作は簡単だし。これがなかったらLinuxでメールの読み書きできなかったかも*1。

@ [java] SableCC

その名のとおり、コンパイラコンパイラ。JavaCCがお蔵入り(?)したので、こっちを使ってみるのも良いかも。日本語での解説もありました。

@ 会社のメールサーバ

20:30ぐらいに社長から「会社のメール鯖がおかしいので明日こっちに来てみてくれないか?」という電話がかかってきました。

絶対に行きたくなかった

ので、とりあえず家からsshしてみる(いいのかそれ)。でも見た感じ普通に配送出来てるし、問題なさそうなんですけど...どこかの小人さんが直してくれたのかな

@ [gdd07jp] Google Developer Day (Tokyo)に行ってきました

すっかり申し込んでいることを忘れていて、なんかそれらしいメールが来ていることに気付いたのが前日の昼。で、なんとか回りの人の許可をえて午後からラストのレセプションパーティまで参加してきました。というわけで参加したセッションの感想というかまとめをここに書き留めておきます。

@ [gdd07jp] Google Maps API Introduction

最初にGoogle Maps APIを使っている面白いサイトの紹介をして、地図をズームしたりするAPIの基本中の基本からマーカを出したり消したりぐらいまでを、実演を伴いながら丁寧に説明してくれました。簡単に箇条書きにすると以下のような感じ。

• apikeyがなぜ必要なのか？→そのapikeyを取得したサイトからどのぐらいのトラフィックが来ているかを知りたいため(現状一日に50万PV以上のアクセスがある場合は要相談ということらしい)
• versionのvには 2 のようなメジャー番号だけでなく2.8という指定も可能で、2.xの安定版を使いたいということもできる
• 地図の表示
• EventListenerの説明
• マーカを出したり消したりする方法
• マーカの画像を変える方法
• Geocoding

Introductionというだけあって、GMapsほとんど知らない自分でも知っていたことばっかりなのでちょっと物足りなかったですが、達人レベルになればだいぶギミックの利いたアプリケーションを作れるなぁと思いました。

そうそう、Google Maps APIの日本語のGoogle groupがあるよ、ということだったので探してみたら見付かりました。けっこう活発にやりとりがあるようです。

@ [gdd07jp] Google Desktop Gadgets

「2007年はGadgetの年」というぐらいガジェット気運が高まっているということで、Google Gadgetsでできることを広く浅く紹介してくれたセッションでした。

Gadgetを作成するメリットとして

• 何百万人ものユーザにリーチできる
• ユーザのデスクトップにプッシュ型の配信が可能
• Gadgetからサイトへの誘導ができる

などがあり、さらにGoogle Gadgetは

• リッチなUI
• チェスゲームなどの双方向なコミュニケーションも可能

を謳います。Googleのエンジニアの一人がWiiが大人気で売り切れ続出なので、オンラインストアでWiiが販売されていたら通知するGadgetを作成して5個ぐらい買った、というエピソードもあるそうです。

実際のGadgetの中身は

• 拡張子.gg(zip圧縮)
• XML(main.xml, options.xml)
• JavaScript(main.js, ...)
• マニフェストファイル
• strings(国際化用テキストファイル)

から構成されます。驚いたのは、GUIで部品をポコポコ張り付けてこれらのファイルを生成してくれるVisual Designer(VisualStudioみたいなやつ)があること。IDEまで用意してくれるとは相当本気なんだなぁと思いました。

より一歩進んだところでは

• Communication API - Gtalkのフレームワークを使って友達との双方向なやりとりができる
• Query API - Google Desktopのインデックスを使ってデスクトップのデータを検索できる
• Event API - ユーザがやっていることをイベントで通知してくれる(メーラでメール読んでるとか、ブラウザでWeb見てるとか)

などのAPIが用意されているようで、XMLとJavaScriptだけでホント簡単にリッチなガジェットが作れるんだなあというのがよくわかりました。

で、最後に以下のような質疑応答が流れて終了でした。個人的にはMacにもLinuxにも対応してくれるとすごく嬉しいなと思いました。Write Once, Run Anyware!!ということで。

• WindowsのネイティブなAPIは呼べるのか？→呼べます。(おお!!)
• Mac OSやLinuxへの対応は？→すいませんわかりません。(駄目じゃん...)

@ [gdd07jp] Software Engineer in Google

一番最後、実はこれが一番聞きたかったセッションで「Googleのエンジニアってこんな感じです」という非技術的な特別セッションでした。鵜飼さんはDebianなどのオープンソースで有名なあの鵜飼さんです。Googleにはちょうど1年前ぐらいに入社したのだとか。

• 京大修士過程卒業
• HP 日本研究所勤務(10年ぐらい)
• (趣味で)京大マイコンクラブ
• (趣味で)Debian JP Project
• 日本Linux協会

という簡単な自己紹介から始まり、以下のようになぜGoogleに入ったのかというところを説明してくれました。

• Googleの大規模なインフラに直接触れる
• 世の中にインパクトを与えることができる
• 優秀なエンジニアと一緒に仕事ができる

Googleに入ってからの最初の3ヶ月は、本社のMountain Viewで

• Lecture
• BBQ
• Engineer Tour
• Google Dance

などを堪能したそうです(なんか楽しそう...)

でで、肝心のSoftware Engineerの仕事としては

• アイデア出し
• デザイン(設計)
• コーディング
• テスト
• (リリース後の)改良

などソフトウェア開発のほぼ全部を網羅しているそうです。まぁうちの会社もそうなんですが、、自社サービスをやっている会社っていうのはあんまり上流工程とかの区切りがないので、必然的に全部やるのが当り前になっているのかなと思いました。

Google社内にはたくさんのプロジェクトがあって

• ボトムアップ(ディレクターがあれやれこれやれとかいわない)
• 2-6名の小人数構成
• 基本的に全ての工程を行う
• イノベーション重視
• オープンなコミュニケーション - IM(Gmailのチャット), ML, Wiki, Docs & Spread Sheets(ドキュメントは最近これで書くことが多いらしい), Snippets(毎週の進捗確認)

というのが特徴だそうです。このプロジェクトは

1. アイデア
2. Design Doc(設計)
3. コーディング
4. レビュー
5. デモ
6. Betaとして公開
7. Google Productになる

というサイクルで遂行されていくそうです。Design Docというのは文字どおり設計書で、コードを見てもわかりにくい全体の概要や構成、テストパターンなどをここで明らかにするそうです。

• 言語: C++(コアなところ)、Java、Python、Sawzall(Google独自言語。MapReduce用らしい)、JavaScript、ActionScript(Flash)
• 単一のリポジトリ(エンジニアは社内の全てのコードが見れる!)

という感じで、開発方針としては

• 自分達で作る(必要なOSS使う)
• パフォーマンス重視。より良いアルゴリズムを模索する。計測してから最適化する(まず測れ)
• スケーラビリティ。並列化
• 信頼性。ハードはすぐ壊れる(MTBF3年)ので、障害監視と自動的な障害復旧を徹底
• テスト重要

となっているそうです。

社内での情報共有はどういう風にやっているかというと

• データベース: Project, Idea, Bug
• 進捗管理: Snippets, Blog
• ドキュメント: Design Doc, Wiki, Docs & Spread Sheets
• ソース管理: Perforce改良版
• コミュニケーション: IM, ML, Video会議
• 一つの部屋に2-4人のエンジニア
• Tech Talk(勉強会)

だそうです。

さらにさらに、気になるエンジニアの評価制度はというと

• 四半期ごとに目標を立ててそれに対する成果を見る
• 上司ではなく、一緒に仕事をしている同僚が評価→日々の働きっぷりが評価されるので、評価面談のプレゼンがうまくてもいい評価はつかない
• 自分が携わりたいプロジェクトを見つけて、自主的に仕事をする→問題意識を持ってやらないと遊んでいて何もしてないように見えちゃうよ

ということで、噂には聞いていましたが非常にフラットな組織なんだなぁと思いました。あと、ぺーぺーのエンジニアより、ハイレベルでより上級な(偉い)エンジニアの方がコードを書いている量が多いのだとか。それって普通だったら逆ですよね。

最後に質問タイム。「製品やサービスの企画が固まったら、どのぐらい売れそうかという予測を立てたりすると思うが、そういうのはどうやってるの？」という興味深い質問があったのですが、「売れるかどうかは考えない。それが面白いか、たくさんの人に使ってもらえそうかをまず考える」とのことでした。やっぱり純粋なユーザの使い勝手とか面白さを優先しているんですね。

で、ひとつどうしても気になったことがあったので僕も勇気を出して質問してみました。内容は「自分の働きぶりを評価するのが上司ではなく同僚だったり、自分から率先して仕事を探したりするような組織の中で、上司の役割ってなんでしょう？そもそも上司っていう存在自体あるんですか？」。返ってきたのは「上司はこういうプロジェクトがあるよ、とかそういう道標を示してくれる存在」だそうです。いやー、なんとも理想的な組織というか、こういうところがGoogleの強さの源泉なのだなぁと思いました。こういう会社で働ける人が純粋に羨ましかったです。

@ [book] 「残業ゼロ」の仕事力

「ノー残業デー」「がんばるタイム」で有名なトリンプ元社長の残業をゼロにするための方法を書いた本。

「残業は悪」と言い切り、残業してまで業績を伸ばそうとするのはルール違反だと言い放つけっこう過激な本ですが、確かに「遅くまで残っている＝偉い」みたいな空気が日本のオフィスにはあると思います。「残業は悪」と本気で思わなければこういった環境では確かに残業は減らせないと感じました。ノー残業デーをいかに浸透させていくか、残業を減らすための業務の効率化の方法など(頑張れば5倍は効率化が可能だそうな！)、残業を減らしたいと思う人にとっては非常に有用な本だと思います。もしくは残業をしょうがなくやっている人にも意識改革を与えてくれるので有用です。