お台場ガンダムを遠目に拝んだこともあり、タイトルが影響されてしまっていますが、まぁ気にしない。

2009年の夏は非常に忙しかった。忙しいという言葉を使うのは、パフォーマンスの低い人の良い訳になりがちなのであまり使いたくないのだけど、忙しいが一番イメージと合っているのかと思う。

2009年7月から9月にかけて何があったか、プライベートと仕事を混ぜてあげてみると、

• 7月中旬～8月下旬 : Amazon EC2 上での Web サービスのインフラ構築案件
• 7/28: はてなでBGPの話をしてきた(それ用にスライドを作った)
• 8月頭～現在 : コミュニティーエンジンからお呼びがかかって、コミュニティーサイトの立ち上げプロジェクトに参加開始
• 8月中旬 : 紹介してもらった顧客からコンタクトがあって、ヒアリング＆コンサルティングの提案書作成と提出
• 8/24-30 : 弟の結婚式参加のためハワイに一週間 完全に仕事から離れられず、ホテルでメール返したり、Skype したり
• 9/6-8 : クボケーくんと新規サービスのアイデア詰め合宿
• 9月中旬 : パートナー顧客への提案活動再開、訪問したり見積り作ったり
• 9/12 : hbstudy#3 で BGP の話をする(デモの環境つくったり)
• 9月下旬～現在 : 本書いている

こういう感じだった。

7月下旬から9月中旬くらいは自分の予測しないことが色々と起きて、平行して進んで、それぞれのリミットが少しずつずれているので1つ終わったら次に取りかかって、その間にプロジェクトやら案件やらが進行させていって、、、という感じでかなり色々なことを同時進行させていた。夏休みも体を休めるというよりかは、せっかくハワイ来たのだから予定をいかに詰め込むか。みたいなノリで終わってしまったし。今は終わったものがあるので、だいぶ気持ち的に落ち着いて、やっとちょっと先のことに取り組めるようになったので振り返るためにこのエントリーを書く気になった。

自分の予測しないことというのは、周りから突然声をかけてもらって話が舞い込んできてたようなケースなのだけど、面白いことにその内容は自分自身も望んでいるレベルだったり、やりたいことだったりしていたので、自分としては突然にビックリしつつも、ありがたくやらせてもらっている。

コミュニティーエンジンとは是非一緒に仕事をしたかったし、meet-me の立ち上げ経験を生かしてもう一度コミュニティーサイトの立ち上げをやりたかったし、Amazon EC2 の案件はやりたかったし、いつかは本は出したいと思っていたし。それらが一気に出来るようなお誘いばかりが来た。

これは不思議なことだなぁ。などと思っていたら、前に読んだ本よりこれこそが「抜擢される人脈力」なのでは？と思えた。

会社を作ったちょっと後くらいに「抜擢される人の人脈力」は読んでいて、自分のような小さい規模の会社が仕事のレベル落とすことなく上げ続けていこうとする時に、人脈力を活かしてやりたい仕事に抜擢されるシーンを作っていきたいと思っていた。

実際、会社を作った今年2月からの半年間は紹介も含め、色々な会社に会ってシェイクソウルという会社を知ってもらい、やりたいこと/やろうとしてることを話してまわった時期かと思う。

それが、今になって話した人たちからシーンにあった抜擢をされ始めているのかと思った。それだけ会社を知ってもらう人たちの数が増え、話がくるパスが多くなったことの現れだと思うし、シェイクソウルのレベルへの評価もそれなりにしてもらえていたことがあったからだと思っている。半年間はかかったが、それなりにちゃんと実ったという手応えも得られてよかったとも思っている。半年間作ってきたのは、この「抜擢される人脈力」なのだと思いたい。

今回は忙しいながらも良い状況が生まれたが、今後に対してすでに課題も感じている。

• 抜擢されるシーンが今後も継続的に生み出せるのか
• 抜擢は結局受け身なので、自分の望んだタイミングで行うにはどうしたらいいのか
  • 今回のように色々集中しすぎると1つ1つのパフォーマンスの質がどうしても悪くなってしまうから
• 抜擢されるかどうかは結局確率論になるので、パスを増やし続ける努力は必要になる
• 最終的にはランニング的な売り上げを得られるモデルにしたいが、スポット的な抜擢からどうやって移行していけるのか

これらは本にきれいに書いてあったことではないので、模索しつつ進めて行くことになるだろう。

しかし、2009年夏は今までにない1ステップ上のフィールドに立った過ごし方が出来た。来年の夏はもう1ステップ上がれるだろうか、どのような過ごし方になるだろうか。自分のちょっとした未来に対して楽しみになってきた。

hbstudy#3で話した時にデモした、Amazon EC2 上で BGP peer を張る環境の作り方をメモしておく。

構成情報

環境は以下、

• EC2 の instance は CentOS5.0(Final)
• Quagga(旧Zebra)を使う

構成は以下、

• instance 2つを立ち上げる
• Quagga 上で zebra, bgpd を起動
• AWS 内の private network 内部で BGP peering

instance 1 側の設定内容

interface ip address : 10.254.202.228
AS65001
広報するprefix: 10.1.0.0/16、10.11.0.0./16、10.111.0.0/16

instance 2 側の設定内容

interface ip address : 10.209.162.213
AS65002
広報するprefix: 10.2.0.0/16

BGP的な設定内容

2つのinstance の interface ip address が異なるネットワークになるので、EBGP multihop を設定
route-map を使って Local Preference、MED、Community を付けてみる

確認内容

peerが張れているか
広報されている経路情報が route-map で指定しているものかどうか

構築

CentOS だと yum で quagga がインストールできるので、簡単にすませる。

最近、仕事でお世話になっているコミュニティーエンジンの ringo さんと打ち合わせの帰り道での会話。

• d_sea : プロジェクトマネージャ(PM)って、今までの経験上、「この人すばらしいPMだ！！」って思った人は一人もいないんですよね～
• ringo : 僕もそうだなぁ。。。
• d_sea : そう言えば、これができれば PM としてOKという明確なものがないですね。スケジュール管理だけではないし、会議に出ていれば良い訳でもない。実は PM って、イメージだけの言葉なのかも。。。
• ringo : それはおもしろい！！PM という仕事の実体は実はないかも。

こんなことを話した訳だけど、ちょっと振り返っても実はかなり的を得ている気がしている。

ここ3年くらい前から確信していることとして、「平均的なスキルを持った人が20人いたとしてもできないことがあって、スペシャルな一人がそれをできてしまう世界が確かにある」ということ。

これは特にネットのサービス作りで顕著な気がしていて、スキルの高い最小人数ですごいパフォーマンスで作り上げるのが一番早いという結果が出ている。あまり日本では表に出ない事実かもしれないけど、結果を残せているサービスには必ずそういうスペシャルな人がいるはず。

そういう現実がある一方、この PM とか PL とか言う響きは複数人で行う際に前提とされる象徴的な言葉かと思っている。

PMとかPLだから偉い。みたいな印象が結構強くって、あとのメンバはそれに従う歩兵みたいな感じがする。本当は偉いとかはプロジェクトを取り組む際に全然意味をなさない項目なのだけど、妙にその印象が強くついてしまう現実はあるかと思う。

その偉い PM が実は何ができれば良いのかの定義がなかったことに気づけたのはすごく面白かった。

もう少し考えると、集団主義的な発想で解決する時に PM がコミットすべき TODO が実は決まってないということは、人の数はそれなりにいるが機能してない人が出やすくって、しかもそれが偉いと思われやすい PM だったりするのはかなりのクリティカルポイントだと思う。

自分の経験上、Enterprise SI の SE をやっていた時に必ず PM とか PL を立てて案件を取り組んでいたのだけど、最もパフォーマンスが悪かった(案件に対して直接的に推進する力になれていない)人は PM だったりする記憶がよみがえって、つじつまがあった。

別に集団主義を否定している訳でもなんでもなくて、ネットの世界で新しいアプローチをしようとした場合にはムダとかパフォーマンスをしないとかはいらないことなのは明らかなこと。そこで集団主義で複数名で解決する手法をとるにせよ、ちゃんと自分の役割や TODO くらいは明確化してないと、どうにでもなってしまう危険性を元々はらんでいるということを分かっておいた方が良いと思った。その原因が偉いと思われて気を良くしている PM の機能不全だったりするとプロジェクトとしては本当に不幸な自体になる。

今回は今思う自分なりの確信になったのだけど、今後自分が本当にすばらしいPMだ！！と思える方に出会えたら、この確信はまた変わるんだろう。

その前に仕事のやり方が全く変わって、オンライン上でそれぞれが流動的に関わり合いながら、完全にフラットな体制でプロジェクトを取り組むことが当たり前な世の中になっているかもしれない。

自分としてはそうなってくれる方が面白いし、実際その兆候は現れていると思っている。

ハートビーツさん主催で行われているインフラエンジニアのための勉強会 hbstudy の3回目で、BGP の話をしてきた。

私が1つ目のネタで、2つ目のネタはTOMOYO Linuxの紹介で、NTT-DATA 沼口さんだった。

タイトルは「BGPのお話」。思いっきりネットワークのみの世界の話なのと、BGP自身なじみがないと思ったので、どの程度伝わったのかはよく分からずとも、とりあえず概要から運用的な話までしてきた。

勉強会中の会場の様子は twitter で結構流れたので、そちらでも結構反応が分かる。

このスライドは以下。

質問では経路乗っ取りについてが結構多かった。統一されたシステマチックな仕組みがあるようなイメージを持っていたようだったが、「インターネット運用は性善説に基づいている」ことがもう少し説明できれば良かったかな。

デモでは Amazon EC2 上で instance 2つに Quagga 入れて bgpd 動かして peer 張るところまで見せたが、これだけだとルーティングしていることにはならないので、instance 7つくらいで AS path 長を持たせた構成を作ってみたら実践的になるかと思うので、やってみようと思う。

EC2 上での 構築と動作させてみたことについては別エントリーでこのブログでまとめることにする。

実際BGP運用をしていたのは4年以上前だから、自分の記憶が頼りだった部分もあるのだが、それなりに覚えていたし、考え方の概要は忘れていなかったことが自覚できたのは自分なりの収穫。経験したこととかを振り返ることもできたし、スライドとしてはBGPを概要からまとめられたそれなりな資料が作れたので良い蓄積ができた。

まだまだ BGP 設計とか体制作りのコンサルティングはできる感触を得られた。

勉強会には初参加の人たちも増えているようで、3回目にして hbstudy の認知が広まってきている感じがした。

今後勉強会で聞いてみたいネタとしては、

• Apaceh にすごく詳しい人</p>
  • 特に proxy とか、proxy_loadbalancer に詳しい人とか、運用ノウハウに長けている人
• MySQL にすごく詳しい人
  • tips 満載な人
• モニタリングツールとか設定内容
• たくさんのサーバの設定内容を同期させるツールとか、tips とか

かな。基本的にみんな使っているけど、あまり自信を持って動かせていないような気がするポイントかな。(自分自身がそうだったりする。。。)

hbstudy はインフラをちゃんと学ぶ場としてはおそらく他になく貴重だから、今後も濃く良い交流が生まれる勉強会であってほしいかな。

ということで、インフラを学びたい人は hbstudy へ一度ご参加ください。

今年3月のJTPAシリコンバレーカンファレンスで知り合った id:keikubo と夏合宿してきました。

目的は二人で思案中のサービスについてさらに具体化させるため。今までメールでのやり取りだけでイメージは作ってきたが、システムのアーキテクチャだけでなく悩みどころのポイントもあったので、ちょうどいいタイミングだった。合宿の提案はクボケーくんから以前にあって、必ずやりたいと思っていたこともある。

そんな自分だったのだが、合宿の直前に仕事がかなりクリティカルな状態になってしまい、考えとか議題をまとめるような準備はほとんどできなかった。しかも、逃げ切ったつもりが逃げ切れなくて、仕事の電話が何度も鳴ってしまい、本当に申し訳なかった。。。

合宿の様子をざっと紹介。

合宿に使ったのは、川崎グランドホテル。宿泊＋会議室利用のパックがあり、東京よりも全然安い。

一番小さい会議室を予約してもらったのだけど、二人には十分すぎる広さ。

なんか面接が始まるような感じの机とイスの配置。。

ホワイトボードが2つあるのがうれしい。1つは紙に印刷できるやつ。

電源タップ、HUB、無線LANターミナル、LANケーブルがそろっていて、ネットやPC向けの設備的には何も持って行かずに大丈夫でした。

ネット環境は会議室では有線と無線。宿泊部屋では有線のみ。が提供されていた。

宿泊の設備は古く、昔ながらのビジネスホテルという感じ。ここら辺は期待しては行けないし、しょうがないところ。

これは最後の夕飯で、豪勢かつおいしかった！

最後の夜はビールやらつまみやら買ってきて、飲みつつ話しつつな感じで過ごしました。

こんな感じで、、

ビールだらけw

実はこういうサービス生み出すような合宿は始めてで、どのくらい進められるのか全く未知だったけど、形になりそうなところまで見えたのは大きな収穫だった。合宿効果すごい。これは癖になりそうw

ただ、何も持ってないと何も進めない訳で、おそらく二人のサービスへのイメージとか今までメールで話し合ったことがベースにあったから考えられたし、何しろ二人のパフォーマンスのレベルも良かったことが大きいと思う。

しかし、このタイミングで合宿が持てたのは本当に良かった。宿泊先を調べたり予約もしてくれたクボケーくんに感謝！！

確実に大事にしたいプロジェクトになっているし、次のマイルストーンに向けて今後はもう少し自分のパフォーマンスをあげて望んで行きたいと思っている。

今年の夏休みは弟の結婚式に参加するためにハワイで丸々1週間すごした。嫁と娘も一緒に家族で初海外の初ハワイだった。

気づいたことをメモ

• 日本語が通じる場所と通じない場所があった
• 英語をしゃべっても通じないことが多かった。カタカナ英語のほうがいいのかな？
• ファミリー向けホテルの多く立ち並ぶエリアは空港からタクシーで30分くらい。高層な建物ばかりで、ゴミゴミしている
• リゾート地はさらにタクシーで20分くらい東側の高級エリアで、ビーチの規模はそれほど大きくないが低層な建物が多く静か
• 少し内陸に行くと土地が余っている田舎町になる
• ハワイのアロハシャツのサイズは大きい。たくさん食べてアロハ着れるくらい大きくなれよ。ということらしい
• 思ったよりも町が整備されていて、建物も多い。もっと自然があるかと思ったけど、予想よりもゴミゴミしていた。

思い出に写真をいくつか。

とりあえず、家族で海外旅行しても娘は大丈夫な年になったなぁ。いろんな国に家族でいくのも良い気がしてきた。

スポーツ選手がこの本を読んで試合に臨んだら結構良い結果が得られた。というような話を聞いて買ってみた。

2回目となる BPstudy に参加してきました。先月は出れずに2ヶ月ぶり。

第一部

第一部の資料は http://beproud.jp/bpstudy/?p=33 から入手できます。

• プログラミング開発の作るそのものが変わる
• クラウド上で集約
• 作るというよりかはカスタマイズ部分の対応がフォーカスされるはず
• PaaS 上で開発することを想定している
• スケーリングするストレージ = キーバリューストレージ

Google App Engine での DB 利用

• クラウドのストレージは join ができないことを前提してつくる
• 複数のトランザクションを補償するのが弱いのでアプリレベルで1つに詰め込む方がいい
• アプリケーション非同期処理
• いろんなコンポーネントを組み合わせてアプリケーションが成り立つ

demo

• simplemodeler というコマンド
• src が選べる
• scalar でオブジェクトモデルを自動生成
• Google App Engine 上で反映を確認
  • Java で作ってあげる
• CSV をインポートできる機能があるらしい
• class から仕様書が自動生成してくれるらしい HTMLで
  • 詳細が class 図 属性を示す
  • 状態遷移表も表として自動生成してくれる
  • program書くことだけで終わらせたい

第2部 edge2.cc

• クラウドコンピューティングでの開発を考える
• # PaaS 上での話のようだ
• 通信プロトコルも統一できていない
• エラーの頻度が高いはず
• 遅延発生する 返ってこないことも
• トランザクションモデルが異なる RDBが使えない ACID特性があてにできない
• 制約があるからモデル駆動開発 既存のweb開発とは異なる抽象もでる
• Enterprise Integration Patterns 本あるよ
• Apache Camel フレームワーク
• クラウドと非同期メッセージング
• 厳密な ACID特性を当てにしないサービス設計を採用するというサービス仕様を考えるとか
• Google Developer Day で出店した TwitterRecommender
  • 自分がフォローしている人をフォローしている人を知る
• モバイルwebアプリは HTML5+Sync+Offline で
  • Safari HTML5 オフライン機能を使用しモバイルクライアントとして offline 対応web アプリケーション対応
  • Android Gears
• iPhone のネイティブアプリ実装版
  • CoverFlow の UI を利用
  • SQLite をローカルに持って動作させる
  • サンプルコードをいじって作った 2h くらいで終了
  • O/R Mapper は便利
  • XML は SAX Parser でガリガリ書く必要あり

懇親会で話したこと聞いたこと

• シリコンバレーでみてきた会社文化の違い
• JTPAシリコンバレーカンファレンスは一度は参加すべし
  • 昨年と同じならば11月頭に申込開始 要チェック！http://www.jtpa.org/
• internal と external の文化的違いについて
  • internal を10年前からの企業依存の高いSI業界の旧文化スタイルと言ってしまってもいいかも
• 深海は個人の力の最大化を試みる実験を株式会社シェイクソウルでしています # 最近この話を飲みの席で良くするかも
• fujisaki_hb さんが子持ちでしかも3人もいた # おっとビックリ！
• 結局深夜2時まで恵比寿 # 終電以降ひさびさ
• そこからハートビーツの方々と相乗りタクシー # 安くすんだ、ありがとうございました！

やはり技術的に刺激になるな。知らない情報があったし。徐々に参加者の方々と面識ができ始めている気がするので、エンジニア同士のいいネットワーキング作りにしたい。

技術的に尖っている場の方が充実度の高さや刺激の多さが多い気がしてきている、今日この頃。

いつもどおりに3ヶ月ぶりにチェックされに行く。

相変わらずリテーナーを数時間外していると歯が動くので、食事の時以外はずっとしている。以前に比べればあまり動かなくなっていると思うけれども、夜間使用だけというのはまだまだだろう落武自分の感覚を信じて使い続けている。

先生が見る分には問題ないようで、「夜間使用だけですよね？」と毎回聞くのだが、ずっとしていると答えるとちょっと不思議そうにしながらも「長く付けている分には問題ないので、」という感じで会話が終わる。そのパターンが続いている。

今頃新しく何かをかえるというよりかはなるべく現状維持で行って欲しいというところなのだろう。こちらももう一度器具をつけるのはゴメンだし、リテーナーをつける分には今までやってきたことなので問題無し。

本日の精算：チェック料 ￥5,000