2009年を振り返る

ひさびさにブログを書く。やっぱり2009年は会社設立という新しいチャレンジをしたという意味で、大きなターニングポイントになるのでちゃんと振り返っておきたい。

仕事とプライベートが混ざるけどもつらつらと残しておく。

1月
  • 1/7 立ち上げから運用まで関わった meet-me のインフラ面、運用面の引継ぎ資料づくり(wiki)を行ってから有給取得スタート
  • 1/16 年末から探していた家をついに決めて契約する
  • 1/17 2月頭の会社設立に向けて名刺を作り、懇親会に招いてもらい配る
  • 1/20 会社設立に必要な定款を作成し提出する
  • 1/22-29 紹介してもらったり、懇親会で出会った方々に設立する会社の紹介を行う
  • 1/31 トランスコスモス退職
2月
  • 2/2 株式会社シェイクソウル(ShakeSoul inc)設立
  • 2/3 iPhone 3G 購入 感動する
  • 2/4- 今までの人脈を使って会社紹介しに訪問する Maxで4件/日
  • 2/11 JTPA シリコンバレーカンファレンス 東京参加者による2回目ミーティング参加
  • 2/15 娘の7歳の誕生日 学生時代にバイトしていた割烹料理屋で祝う
  • 2/21 オープンソースカンファレンス参加
  • 2/25 学びing 講師のクラウドセミナーを聞く この時はじめて Amazon Web Service の存在を知る
  • 2/28 iPhone Developer Japan 懇親会に参加 数名の方々と知り合う
3月
  • 引き続き人脈のあるところに会社紹介する meet-me時代に関わりのあった CE、ウノウ、ウタゴエ にもリーチ
  • 3/15 新居に引越し 神奈川県横浜市から東京都世田谷区へ
  • 3/19-23 JTPA シリコンバレーカンファレンス 参加
    • はじめてシリコンバレーを体感する カルチャーショック、日本語圏/英語圏の差の大きさ、シリコンバレーの1つのシステムに対して驚く
    • 具体的なことは svc09++ カテゴリー にまとめている
    • シリコンバレーで働く方々とのパスも作れる VC, Google, Adobe, RockYou, etc…
  • 3/28 伊藤忠主催の Puma Family Sale へ行く RUDOLF DASSLER ものが ¥15,000 で買えてしまうことにびっくり もう、店頭で買うことはなくなった
  • シリコンバレーで見たこと感じたことを聞きたいという方々に会う 新しく紹介してもらうケースもあり人脈がじわっと広がった
4月
  • 4/2- 徐々に具体的案件に声をかけてもらうようになる 受注はなし
  • 4/3 仕事がまだ無いことをいい理由に平日ゴルフに行く 数年ぶりにもかかわらず一度も練習に行かず結局、スコアは120以上
  • 4/7 シリコンバレーで出会った方と日本で飲む
  • 4/11 伊藤忠主催の ADIDAS Sale へ行く puma の時と打って変わってまったく買いたいものがなくすぐ退場する もう行かないと決める
  • 4/13- 面識のある人の先にいる人を紹介してもらうような動きになっていく 人脈の拡大につながった
  • 4/6- 誘われてシェイクソウル第1号の案件を取り組む
    • 結果的にこの案件と同じような案件は2度とやらないことに決めた シェイクソウルが求める質と内容を満たしてないものは何かが分かったことが収穫
  • 4/17 学びing, ハートビーツと顔合わせ Amazon EC2 フルサポートパック の企画をまとめる
  • 4/21 IRI-CT と一緒に案件開拓に動く
  • 4/22 Amazon EC2 フルサポートパック リリース
  • 4/26 やっとテレビが映る 引越してから1ヶ月間テレビを見なかった
5月
  • 5/7- 具体的案件がちらほら出始める
  • 5/15 CE の社内勉強会で inside meet-me について話してくる 利用者側の情報が作っている側に伝えられてよかった
  • 5/19 Amazon EC2 のアプリケーションレベルでのスケーリングを可能にする WAKAME の説明を受けにあくしゅに平野さんと訪問する
  • 5/21 会社のWebからコンタクトしてきたある日本のVCの話しを聞きにいってみる
    • 投資を受けてうまく行かなかった場合、最後には VC 買った株を創業者が買い戻す話しを聞いてかなり幻滅した
    • シリコンバレーでの力強い VC とはスタンスも金額のボリュームも全くちがうことを実感した
  • 5/22 BPstudy に初参加 技術レベルの高い濃い話しに刺激を受ける 今後定期的に行く勉強会に位置づける
6月
  • 6/7 meet-me メンバで豚の丸焼きバーベキューする 嫁と娘も一緒に行く 家族を meet-me のメンバに紹介したのは初めてかも よく焼けていない豚を食べてしまったようで、その夜は大変な事になる。。
  • 具体的案件の紹介を受けて、打ち合わせに出たり顔合わせしたり
  • 6/26 iPhone 3GS 発売日 Docomo を解約して、予約していたものを取りに行く 以前の iPhone 3G は嫁に渡す
  • 6/28 10年ぶりくらいに TOEIC を受けてみる 結果はひどかった。。
7月
  • 7/4 弥生会計を買って会計をつけてみる
  • 7/8 NTT時代の上司に声をかけてもらって、大学向けクラウド導入プロジェクトを促進してみることを始める
    • 大学のWebシステムに対するコンサルティングを行っている人と知り合う
  • 7/10 学びing の mixi アプリゲームの Amazon EC2 でのインフラ構築を手伝う 2つ目の案件
    • この時 boto、rsyslog とかを試せたのはのちのノウハウとして生きている
  • 7/14 Amazon EC2 3社共同セミナー開催 シリコンバレーカンファレンス参加者と懐かしの再開 参加いただきありがとうございました
  • 7/21 フリービットに日本で立ち上げるクラウドサービス企画に対するご意見伺うを求められる
    • Amazon EC2 のノウハウを持つシェイクソウルとして認知され始めたことを感じる
  • 7/22 ネットワーク系SIer に対して Amazon EC2 の説明会を実施
  • 7/24 CEに呼ばれて打ち合わせする
    • これが後の長期プロジェクト参加につながる
  • 7/28 念願でもあった はてな への対面を行う BGP の話しがメインで結局その時やっている Amazon Web Service についても紹介した
  • 7/30 Amazon EC2 の書籍の話しをもらう
8月
  • 8/4 CE に誘われたコミュニティサイトの立ち上げ案件に本格的に参加する</p>
    • シェイクソウルとしては3つ目の案件で、半常駐型の時間拘束が長い案件は断っていたが受ける</p>
      • コミュニティサイトの立ち上げはもう一度やりたかった + CEとシェイクソウルとして一緒に仕事したかったことが理由
  • 8/5 誘われて皇居1周ランニングに参加してみる まともに走るのは10年ぶりくらいだったので3km走ってギブアップ
    • シューズも買ったし、今後続けてみようと思う
  • 8/7 新卒で入社した最初の会社 NTT の研修時代の同期と会う 10年くらいの付き合いだが、自分が変わりすぎていて考え方のギャップが激しいことを自覚する 多分あの頃の自分では無くなっているだろうし、これからも戻ることは決してないと思った
  • 8/8 弟家族の家で花火を見る 品川の高層マンションというものに初めて入った
  • 学びing の案件で作業しつつ、CE のプロジェクトもハイペースで回して行く 2つ並行は初めてだったが、なんとか時間をうまく使うようにした
  • 8/24-30 弟家族の結婚式のためにハワイへ しかし、仕事が区切れずにホテルで有料無線LANを利用しながらSkypeしたり
9月
  • 9/6-8 keikubo と開発合宿 だいぶ進んだ、時間を割いてセッティングしてよかった
  • Amazon EC2 本の原稿を書く なかなか時間が捻出できずに朝5時起きした
  • CE とのプロジェクトは1システムの開発フェーズに入る チームを作って顧客とエンジニアの間に入る動きになる
  • 9/12 hbstudy#3 で BGP の話しをする
  • 9/16 35歳の誕生日
10月
  • CE とコミュニティサイトの立ち上げを継続して取り組みつつ、サービス企画を進める
  • 10/24 ハートビーツと新サービスの検証作業実施
  • 10/27 Amazon EC2 LAMP スケーラブルパックを3社でリリース RBBTODAY にのり、そこからYahooニュースにものった
11月
  • 国内ベンダに Amazon Web Service の利用者としてのコメント伺いに呼ばれたりする
  • 11/14 putico(休みの日に集まってそれぞれ思い思いのコーディングをする、Google Waveで進捗とか成果とかを報告する会)#1 自宅で実施
  • 11/16 元インテルジャパン CEO 新岡さんと出会う
  • 11/18 PACNET の陸揚げパーティーに呼ばれる 5年ぶりくらいに岡田さんとお話する 懐かしかった シリコンバレーでの人脈の接点が作れた
  • 11/20 BPstudy#27 で Amazon Web Service について話す
  • 11/25 mixi アプリを Amazon EC2 構築する案件をスタート
12月
  • 12/3 ポスモを初めて体験する CE の所属チームで実施
  • 12/8 学びing の取り計らいで、Amazon Web Service の方に出会う
  • 12/12 putico#2 を自宅で実施 ひさびさに自宅で大人数で家族も交え食事をした 楽しかったなぁ
  • 12/21-25 mixi アプリ用 Amazon EC2 構築を駆け込みで実施 時間の捻出が難しかったが午前中を活用
  • 12/23 初めて会社の年賀状をデザインして印刷会社に発注する
  • 12/25 JETRO にコンタクトしてみる
  • 12/28 CE にて仕事納め なんとなくスタッフの一員になれている気がする
  • 12/30 家族で叙々苑に行く 1年間のねぎらいを込めて
  • 12/31 資料を作りが残っていたので、この宿題をやりながら+twitter の #kouhaku タグを見ながら過ごす
    • それだけでは面白くないものが、twitter を使うとこんなにも楽しくなるのは新しい実感だった

まとめると、

  • どうなることかと思った会社は人脈の拡大と会社の紹介を続けてきた結果、ひとまずな規模(だいたい100万/月ちょっと)の売上を上げれるようになった
  • 案件の対応は実質3本平行に取り組むくらいが、Maxであることが体験的に分かった
  • 理想的には案件は1つの状態+不定期に1つのパターンが一番安定して時間が作れる
  • 詰め込みすぎて時間の捻出が難しいことを経験した
  • プライベートで何かを楽しむ時間は少なかったが、それぞれいいリフレッシュになった
  • Amazon Web Service をいろいろ触ってみたことが結果として、サービスを企画してリリースしたり、勉強会でしゃべったり、案件になって売上になったり、本を書いたりできてよかった
  • 会社を作ったときにやりたいと思っていたことが一通りできてしまった
    • やりたい分野(SIerが好むようなEnterprise案件は行わず、ネットサービスに近いところ)、やりたいレベル(単純な作業実施ではなく、コンセプトの抽出、設計、運用、コスト含めた総合的なスキルが求められる)の条件が揃った案件を取ること
    • 稀少性の高い技術スキルを体得すること 今年は Amazon Web Service が該当した
    • CE と一緒に仕事をすること
    • コミュニティサイトの立ち上げをもう一度やること 1回だけではノウハウと言えないので、2回やってみた共通項をノウハウにしたかった
    • 勉強会のスピーカーをすること
    • 本を書くこと
  • 嫁と娘が一年中元気な姿を見せてくれて、それが自分のエネルギーになっていたのがとてもありがたかった
  • 来年に向けて大きな動き出しと決断ができたこと 来年に邁進すべき目標が明確になった

というところだろう。

色々あったし、新しい経験もあったけども、自分なりに積極的に動いてみたことは良い結果になっていると思う。逆に意志が薄く少しでも他人の意図に流されてしまうと、良い結果にはならないことを経験した。

全般的には新しい出会いと経験が多くてとても楽しい1年だった。

2010年はひとつ大きなチャレンジをしようとしているので、その手前のステップとしては2009年にやれたことは十分だったと思う。

2010年に何をチャレンジするかについては、状況が固まったらこのブログで報告したいと思う。

</div>

「超」整理法

ringoさんに「超整理法の極意は新しいもの順なんですよ」と教えてもらったけど、いまいちピンと来ていなくて、読んで理解してみようと思って読んだ。

「超」整理法―情報検索と発想の新システム (中公新書)

</div>
</div>

内容は1つの主張を従来色々な人達が主張してきた整理法を批判して、多角的に主張を成立させようとしている本。

主張は至ってシンプル。「自己で利用する情報は時間軸で並べる」というもの。

  • 整理法と言いつつ分類することは一切しない
  • 資料として足されたものはファイルにまとめて棚の一番右(もしくは左)に加える
  • 棚から参照するために出された資料は元の位置に戻さず、また一番新しい場所(棚の端)に並べる
  • 新しい場所の反対側にたまった動かない資料は利用する価値のない資料とみなせるので、捨てられる

非常にわかりやすい。

「整理」という言葉を聞くとどうしても分類しようとしたり、見た目をきれいにしようと(これは「整頓」だと本書で指摘してる)したりするが、情報を利用する上では効果的ではないことがわかる。

この本を読んでから、同じように本棚を使って利用した順にファイルを並べてみるようにした。確かに今取り掛かっているものはよく参照するので、新しい側にあるから探しやすい。名刺も分類せずに、もらった順にファイルに入れることにした。と言っても、名刺の検索は Evernote に読み込ませて行うのですでにファイルを参照することはほとんどないのだけど。

注意点としてはあくまでこの整理法は個人としての利用にとどめるべきで、集団でやってしまうと参照頻度がばらばらになるので成り立たない。

あとは、この本が書かれたのは1993年。PCを使った整理法も紹介しているが、ネットもなくアプリケーションも限定的な時代なので、だいぶ古い。現代では Google もあり、Evernote や Remember The Milk のような複数の端末でも同じ情報を同期できる仕組みもあるので、もっと発展的なツールを活用した方がいいだろう。

分類する必要がないだけでも整理に対する重たい印象が軽くなった。という意味でよいノウハウを1つ得られた本。

</div>

組織の1/10に自分は残れているかをイメージしてみることを薦める

別に誰のためという訳ではないが、自分の確信を持ったことについてメモしておく。

仕事をする上でどういう人材になりたいか。というようなことを考えることはあると思う。就職活動や転職のとき、最近ではご丁寧にNHKが企業の人事を招いて就職活動ぽいことをする番組があったりして、誰が欲しい人材か。みたいなままごとをしている。

誰しもお金を稼ぐ立場にいれば働けるよう必要な人材と思われたい。という気持ちはあるだろう。

この「必要な人材」とはどうなっている人のことだろうと自分なりに考えて出した答えは、単純明快「必要な人材と思われる人になっていること」だった。

ちょっとこれには解説がいるので説明してみる。

例えば100名くらいの会社があるとしてあなたは属している。会社全体がイメージしづらい時は自分の所属している部署を思い浮かべてみる。

あるとき突然、この組織を半分の人数にする必要が出たとする。今までの仕事内容は維持しなくてはいけない。で、人選して半分にしてみる。さて、その半分の中にあなたはいるだろうか?ん~、入ってそうだな。では、半分ではなくて1/3にする場合はどうだろうか?なんとか入っていそうだ。では、1/4にする場合はどうだろうか?ちょっと厳しいと思うかもしれない。この範囲をどんどん狭くしていって、1/10に入れていればかなりコアな人材になっている人だと思う。

で、結局何が言いたいかというと、この残った人材に入るようになっていれば良いということ。入るためには小手先のテクニックや表面的な振る舞いは意味をなくして、その組織で何を行っているかにフォーカスされる。実際自分が人選する側に立った時には容易に想像出来るけども、とられる側視点でどうしても細々したことにこだわってしまう。

結局、組織で必要かどうかというのは俯瞰して必要な人材と思われるよう振る舞い、スキル、人間性などが総合評価されて判断されるはず。それぞれの割合は均一である必要はなく、技術スキルが飛び抜けて高い人は絶対残る人になるだろう。

この視点は経営者そのものだけど、すごく単純明快だ。

なので、テレビで人事担当者が「熱意が伝わることが大事です」などと言ったりしているが、熱意だけでは残れないのは明らか。組織から見た時の必要な人材のイメージができていないからそういう精神主義的な発言をしているだけに過ぎない。

実際、今は1/10に残っていなくても、1/10に入っていそうな人がメージ出来たらその人のスキルに追いつくように目標にすればいい。で、実力をチェックする時は自分の組織を1/10にして入っていればOK。

人を急激に減らすとかは実際ベンチャーくらいしかないかもしれないけど、大企業で埋没してしまっている人にとって大企業病に染まらないうちにイメージしてみると、自分のスキルアップへの目標が作りやすいのではないかと思う。

この話は、スティーブ・ジョブスのスタンフォード大学でのスピーチのように、今まで行ってきた点と点が結びついて線になってつながっていくように、今まで転職を繰り返して、色々な会社組織に属していた時の経験がつながったような内容かと思う。

BPstudy#27 で「Amazon Web Service にまつわるいろいろ」を話してきました

今まで何度か参加している 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を目指すバリバリのベンチャーのこと)

ハッカーと画家 コンピュータ時代の創造者たち

</div>
</div>

実際、シリコンバレーでexitに成功した人の話を聞く機会はほとんどない。さらにそれがノウハウというか発想や考え方にレベルまでまとめて述べられているものは、なおさらない。日本では成り立たない話でもあるので、入って来にくい状況も背景にはある。

この本は実際にexitを経験した筆者が語るプログラミング、言語、ベンチャーとしての振る舞い、Webサービスの運用、exitの経験など、筆者の生きた経験談であり、そこからつかんだ思想やノウハウを語ったもの。タイトルの「ハッカーと画家」は、複数あるうちの1つの章の題名なので、この本全体の内容を現してはいない。もっと広範囲でもっと汎用的にな内容になっている。

ベンチャーとしての具体的振る舞いやそこからつかんだノウハウを知りたかった自分にとっては興味のない章もあったけど、そこは飛ばして読んでしまえばいい。

逆に興味をそそられる内容には非常に大事なエッセンスが詰まっていて、何度もその部分を読み返すほどの衝撃があった。本当に面白い。

読み飛ばす部分も引いたとしてもこの本は価値が高いと思う。その価値は稀少性があるし、ベンチャーとしての普遍的な思想がしっかり示されている。

「なぜベンチャー企業は小さくなくてはならないんだろう。なぜ起業は大きくなると必然的にベンチャー企業でなくなるんだろう。そして、なぜそういう新興企業は新しい技術の開発に取り組むんだろう。」こんな文章があって答えを筆者なりに解説している。

これぞベンチャーだよな。とホッとする。嬉しくなる。ますます確信になる。

あまり日本では書かれないような部分として、大企業を徹底的に比較して批判しているところ。人のスキル、技術力、文化、組織構造、多岐にわたって比較している。これは痛快だし、本当に面白い。詳細な分析にもなっているので、納得感も高い。

付箋紙をはった部分は本当にたくさんあって紹介しきれないけれども、何かしらとんがった仕事の振る舞いを模索している方には最適な本だと思う。

この本が出版されたのは2005年。実は結構時間がたっている。すでにシリコンバレーでは常識的なことなのだろう。

こんな本が日本人から出ることはあるのだろうか。いや、当分ないかもしれないと思いつつ、自分のこれからの振る舞いの教科書としてこの本は位置づけられた。

</div>

いつも通りの定期チェック+あと2回と言われた

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

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

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

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

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

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

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

仕事で演技すること/演技せずに生きること

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon EBS と boto を使って自動バックアップ環境を構築する

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

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

構築手順

1. boto インストール

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

「自分が何ものか」をもっと語っていい

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

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

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

個人が見えない
事情の説明が多く、その人自身が何を実践して、何をつかんできたかが分からなかった
チャレンジしていない
チャレンジングなことをしているのに小さな視点で難しいですね。みたいな結論になっていた。もっと大きな夢を実現しようといているのに、その夢に邁進する意義があまり見えていないようだった
組織を主体にしている
組織は個人の集まりなのに、組織に主体があるような言い回しをして人としての主体性がぼやけていた
客観的視点の説明が多い
事例の説明だけはどうでもいい。その上でその人が何をしたのかが大事なはず
優等生過ぎる発言
良く言えば無難、悪く言えば何も生み出せない
日本inside
ワールドワイドな視点が薄い。海の向こう側で起きていることにもっと焦っていいはずなのに、事情が自分の身に受け入れられていない
Open への信頼が足りない
Open になることを未だに信頼し切っていない

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

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

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

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

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

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

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

Amazon CloudFront スループットを測ってみた

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回ほど測定

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

```bash dsea-MacBook:~ hironobu$ curl -o /dev/null -w time_total http://hironobu-bucket.s3.amazonaws.com/test/Office2004-1154UpdateJA.dmg