今まで何度か参加している BPstudy で Amazon EC2 について話してくれませんか。というリクエストを受けて、BPstudy#27 で話してきた。

持ち時間は90分で大学の講義並みのたっぷりな時間だった訳ですが、なんとかおさめました。

話す範囲はあまり隠すのも変だし、部分的にとどめるのもいやらしいので、素直に自分が今まで AWS を触ってきて知っていることをいろいろ出していこうと思い、対象は広範囲に、でも実践的に動く様子を示すことにしました。

機能説明の後には必ずデモを行い、時間稼ぎ＆実際を見せるようにしました。デモがこけるとすると時間が足りずに最後まできれいに行かない懸念もありましたが、とりあえず全てのデモがつまるところなく見せれたのは個人的に満足でした。

当日の様子は twitter の #bpstudy タグ で見れます。

その時のスライドは以下。

会場の質問内容や様子を見る限り、EC2 でインスタンス起動はさせてみたけどもそこまでの方が多かったのかと思えた。今回、Elastic Load Balancing, Cloud Watch, Auto Scaling など、EC2 の新機能も実践的に紹介出来たので AWS のサービスの幅広さから可能性の大きさを感じて、おもしろがってくれればいいなと思います。

実は、今回のスライドを準備する途中で新たに発見したことが2つあった。

• Auto Scaling に —load-balancers のオプションを付けるとスケールアウトさせたインスタインスを自動的に Elastic Load Balancing の分散対象に追加してくれる
• Elastic Load Balancing の分散対象のインスタンスへのヘルスチェックは、転送先となるポート番号が空いているかどうか。が、デフォルトの内容になっているようだ

今まで不明な点だったので、これは見つけられてよかった。

自分のレベルを一つ上げるのは外的要因の方が起こりやすい。というのを感じてしまった。本当は自分自身の意志で行ければいいけど、甘えが出るからな。

今後も BPstudy は時間があえば行きたい勉強会なので、技術的に濃い刺激を受けたい人は是非 BPsudy へどうぞ。お会いしましょう～

いつ読み終わったのか忘れてしまったのだけど、この日だということでレビューを書く。

兄貴に「これサイコーに面白いよっ！」と勧められた本だった。買う前にアマゾンのレビューを見るとベンチャーとしての文化や考え方が記してあることも読んでみたい部分だった。(ここで言うベンチャーは日本での、ではなくて、シリコンバレーにおけるexitを目指すバリバリのベンチャーのこと)

いつも通り、定期チェックをしにいく。引っ越後だったので、矯正歯科へ行くまでに1時間以上かかる。ちょっと行き来がつらい。

リテーナーを外しても、前ほど動かなくなったと報告したが、先生としてはもう動かなくていい時期と思っているようだ。一般に比べて歯への圧迫が大きいのだろう。

いつも通りでそのまま終了か、と思っていた時に先生から「あと2回で定期チェックも終わりになります」と言われた。リテーナーになってからあと6ヶ月で、まる2年間になるかららしい。どうやら器具を外してリテーナーにに移行したら2年間は見るとしているみたい。

その後は自分でリテーナー続けてもいいし、外しちゃってもいいし決めてください。と言われた。これはなかなか判断が難しい。今は明らかにリテーナーを外すと歯が動いてしまう。あと6ヶ月経ってもそれほど状況は変わらないだろう。

今歯が動いているのは多分2つあって、上の左の歯の間が右に比べて空いているので横方向に動こうとすることと、上の前歯間がきついので前に出ようとする。横に動いてくれるのは隙間を均一にしてくれるので良いし、上下の歯の中心線がそろう方向に動いてくれることになるのでそういう意味でも良い。でも、前に出てしまうのは絶対避けたい。そもそも前歯が出ていたのを直すために矯正を始めたのだから。

今後どう動くかは予想もできないが、リテーナー生活ももう飽きたのでいっそ自分の歯の動くがままに信じてみてもいいかもしれないと、急に寛容に考え始めた帰り道だった。

本日の清算 : チェック料 ￥5,000

ある大企業の人事担当者と話した時にちょっとした笑い話を聞いた。

毎年大量に採用する新入社員の研修は泊まり込みで、男女の宿泊施設は別にしているのだが、まぁ若いということもあって女子の部屋に男子が行ってxxxするみたいなことは毎年起こるらしい。

新人育成の担当者としては、そういうことは起こってはいけないっ！ということで、部屋を見回って見つけた場合は鬼のような形相で引きはがして、女子を帰した後に裸の状態の男子を説教するらしい。

そんなことしなきゃいけないんだねぇ～。とおもしろおかしく聞いた訳だが、その後にそれを自分がやらなきゃいけない立場だったとしたらやれるんだろうか。。と思った。

そんな振る舞い方が自分にできるかなぁ。と考えたらそれは無理だなと思った。そんな状態の男子に正座させてまともに怒る前にその姿を見て笑ってしまう気がした。いや、絶対そんな状況は面白すぎるので笑ってしまうだろう。無理無理。

確かに、新人育成担当としての振る舞い方としては正しいとその会社の中では思われるだろうし、現にそれが仕事になっている。でもそれは本当に自分のやりたいことではないはず。じゃあ、それは何のためになるんだろう？

確かなのは、少なくとも自分のためではない仕事があるということ。会社としての振る舞い方をするために自分を抑えて演技する。

それができるとしたら、素の自分を殺して演技することになるんだろう。そう考えると、仕事のやり方として「自分のやりたいことをやる」の真反対は「自分を抑えて演技する」になると思えた。

いま、会社を作って「やりたいことをやって生活していく」実験をしている自分にとっては「演技する」必要がない。それは、やる/やらないの判断の一つに「自分のやりたいことかどうか」があるから。

サラリーマンを辞めて、一番思ったのはこの「素直な判断」ができていると、余計なストレスがかからない健康的な仕事の仕方ができる。ということ。

この実感が得られたことは、自分の働くという認識を大きく変化させて、確信にできたという意味で、すごく大きい。

ただ、「やりたいことをやる」のは楽ではない。判断の基準が全て自分になるので、自分の責任が全てになる。逆に演技は振る舞い方のお手本があったり、演技できているかどうかは最終判断が他人だったりするので責任がない。特に、大企業はリスクを負わないようにする性質があるので、そもそも大きなリスクは仕事としてない。

大企業に勤めることがステイタスだった時代は、「演技すること=仕事すること」だったのだと思う。現にNTTをいた頃を思い返すと年功序列や組織間など環境に制限があるので、常に演技しなきゃいけない状態だったかと思う。

今はやりたいことが仕事としてやれる環境が確かにある。今というより、本来仕事をするということは「やりたいことをやる」が基本だった、と言ってしまっていいと思う。

日々、演技することに一生懸命になっているとしたら、それをやめて、本当に自分のやりたいことはどんなことだろうと考えを巡らす時間を作ることをした方がより健康的だし、発展的になれる。自分が組織に埋没していると思う人は是非やっていいと思う。

一つの話から、そんなことを考えてしまった。その他にも、そもそも新人だから、新入社員だから何かを与えなきゃという発想すら必要なくてよいではないか。ということとかも思っていたのだけど、それはそれとして別の機会に書いてみることにする。

Amazon EBS の特徴はマウントしたボリュームに対するスナップショットが取れることだろう。boto を使って簡単にバックアップ環境を以前に作業したメモを残しておく。

boto は python のライブラリで、Amazon EC2 のインスタンス上から AWS の API を操作できる。boto の機能は多種であるが、今回は EBS の API を操作して、毎日1回スナップショットをとって5世代分保存する設定をしてみる。

• botoのページ: http://code.google.com/p/boto/
• 参考にしたURL
  • http://2606-36j.blogspot.com/2009/03/amazon-ebs-snapshot.html
  • http://emutyworks.com/?Amazon%20EC2%2FEBS%E3%81%AESnapshot%E3%82%92%E5%AE%9A%E6%9C%9F%E7%9A%84%E3%81%AB%E5%8F%96%E3%82%8B

構築手順

1. boto インストール

• pythonで動作するのでインストール

あるパネルディスカッションを聞いた時にどうも面白くないと思った。話している人たちは知識も豊富で、それなりな地位の人たちらしいが、どの人が話す中身にも興味をそそられない。

話しているテーマは決して古くなく、先端的でチャレンジングであるのだが、なぜ自分がそこまではっきり思ったのか、もう少し具体的に理由を明確にしたいと思った。

少し考えてみていくつか理由を見つけてみた。

個人が見えない

事情の説明が多く、その人自身が何を実践して、何をつかんできたかが分からなかった

チャレンジしていない

チャレンジングなことをしているのに小さな視点で難しいですね。みたいな結論になっていた。もっと大きな夢を実現しようといているのに、その夢に邁進する意義があまり見えていないようだった

組織を主体にしている

組織は個人の集まりなのに、組織に主体があるような言い回しをして人としての主体性がぼやけていた

客観的視点の説明が多い

事例の説明だけはどうでもいい。その上でその人が何をしたのかが大事なはず

優等生過ぎる発言

良く言えば無難、悪く言えば何も生み出せない

日本inside

ワールドワイドな視点が薄い。海の向こう側で起きていることにもっと焦っていいはずなのに、事情が自分の身に受け入れられていない

Open への信頼が足りない

Open になることを未だに信頼し切っていない

これらの理由から、自分が何を求めているのかもう少し考えてみた。

人の話を聞く時に気にしていたのは、「その人自身がどんな経験をして、それを通じてどんな考え方を主張するか。」だけかと思う。

その人自身にフォーカスすることが重要で、地位や組織というのはほとんど意味がなくなる。結局組織と言っても人の集まりなのだから、その人が何を思うかに依存すると割り切っている。

客観性を持つのはある程度重要だが、情報の収集は Google がやってくれるので、状況報告だけを話すというのは全く価値がなくなるし、それに時間を割くのは全くのナンセンスだと思っている。

昔は自分も学生時代には優等生発言をまねて振る舞うことが良しとされていたので、昔であればその発言を聞けたかもしれない。でも、時代は変わり考え方も大きく変わった今思うのは、その人自身の経験、主張がちゃんと伝えられることだけで良いと思っている。

自分の考え方は大きく変わった。自分の会社をやるようになってますますこの主体性へのフォーカスと実績主義の傾向は強まっていると自覚する。

何をしてきたか、何を生み出せるのか。はっきり自分を語ることを当たり前のようにしたい。

Amazon EC2系の記事を書く際にちゃんと動く内容を示さないといけないと思い、実際動作させながら確認していった。その中でも Amazon CloudFront のスループット測定はデータとしてちゃんと取れたので、導入効果が分かりやすかった。

実際どれくらいパフォーマンスに差が出るのか、ファイルのダウンロードのスループット結果は以下。

• ダウンロードに使ったファイルは “Office2004-1154UpdateJA.dmg” で 9.8MB ほどのファイル
• Amazon S3 上の “test” bucket 上にファイルを保存
• “test” bucket を CloudFront に適用させる
• 割り当てられたダウンロード可能なサーバのそれぞれの FQDN は以下
  • オリジンサーバ : hironobu-bucket.s3.amazonaws.com</p>
    • Region: Us-East なので、日本からだと太平洋を渡って、アメリカをwestからeastまで横断する経路になるはず
  • キャッシュサーバ : dql6mokzq0d1p.cloudfront.net
  • オリジンは ****.s3.amazonaws.com, キャッシュサーバは ****.cloudfront.net という名前になるのが特徴
• Mac からそれぞれのサーバの URL に対して curl コマンドでダウンロードする
• 3回ほど測定

オリジンサーバからのダウンロード

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

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だ！！と思える方に出会えたら、この確信はまた変わるんだろう。

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

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