採用に失敗した時の「博愛主義」は危険ーAmazon堀内氏が語る技術者採用とクラウド活用法

SHARE:

多くのスタートアップにとって技術者の採用は頭の痛い課題なのではないだろうか。創業期はサービス開発の中心的存在になりうる人材が必要だし、大きくヒットしたときには、開発体制を急拡大しなければ成長に追いつかない。

堀内康弘氏は企業向けのウェブシステムや動画共有サイト「FlipClip」の開発に携わり、2009年にgumiへ入社。ここでのCTOキャリアを経て、現在はAmazonのエバンジェリストとしてクラウドの重要性を人々に伝えている。

堀内氏がMOVIDA SCHOOLで語った、技術者を採用する方法とクラウドの活用事例をいくつかのヒントにまとめた。

IMG_0747

技術者採用にイベントとブログを活用する

知名度を上げるのは技術者採用に役に立つ。例えば技術ブログのようなものを立ち上げて情報を発信し続ける。情報のOutputの量を増やせば、それに応じてInputの量が増えることに繋がる。勉強会の開催も効果的だ。最近では人材系の会社などが場所を貸してくれたり、イベントの開催が楽になったりしているので、どこかのイベントに参加して探すより、自分たちで開催した方が効果的。

また技術者というのは開発言語でコミュニティがあるので、そこの有名人を引っ張ってきて一緒に働きたいなと思わせる方法もある。

採用に失敗した場合の「博愛主義」は危険

採用したけれど、技術的に問題があって先行きが難しいという場合の対応方法。やはり全員が幸せになって欲しいという博愛主義のような考えから、何らかの役割を与えようとしても、それはやはり難しい。

働いている人とそうでない人のバランスが悪くなり、結局全員が不幸になってしまう。こういう場合は厳しい判断が求められる。

最小の技術者体制は二人で

サービスを作るために技術者はできれば二人用意した方がいい。サービスは365日回さなければならないので、一人だとモチベーションの問題が出てきてしまう。あと技術レベルも重要だけど、システム自体を自動化させ、その人が辞めても動くようにしておくプロセスを考えておくべき。

サービスのコアを作って開発の効率化を考える

サービスをスクラッチで開発するとやはり大変。横展開するときにいちいちゼロから作っていたのでは効率が悪い。やはりある程度サービスのコアを作っておいて、誰でも追加できるような仕組みを用意しておくべき。例えばAmazonではサービスが細かくコンポーネントに分かれて、それぞれに開発チームが存在する。

リソースはプログラマブルに用意する時代

従来サーバーリソースはハードウェアの調達をはじめ、何週間もかかって用意するものだった。AmazonはそれをAPI経由で用意できるようにした。リソースの調達時間は大きく変わり、時間単位で使えるようになった結果、スピード感のあるビジネスにも対応できるようになった。

急成長に追いつかないバックアップをどうするか

ちょっと前にカリフォルニアで大学を卒業したての若者が、ソーシャルゲームのスタートアップを首になったという話題があった。スタートアップというのは大手と違い、急成長した時に対応できるだけのリソースや体制が整っていない場合が多い。

この会社もやはりそうで、開発環境と本番環境が曖昧だった。運用も雑なまま、彼を稼ぎ頭のプロジェクトにアサインしてしまう。結果、彼は大きく稼いでいたソーシャルゲームのユーザーデータベースをすっかり消してしまい、大きな売上を飛ばしてしまった。

さて、これは誰が悪いのだろうか。あえていうなら環境が悪かった。

データベースのバックアップは非常に大事なことだが、リソースの少ないスタートアップにおいては開発にリソースを取られ、後まわしになりがち。成長にオペレーションが追いつかないのであれば、既存の仕組みに任せるべき。例えばAmazon RDSを使えば自動で毎日バックアップをしてくれ、任意の時点での復元ができる。こういう仕組みを使っていたら、バックアップシステムの構築に時間をとられることもなかったし、彼も首にはならなかった。

Pinterestの事例ープログラムで自動化されるリソース管理

PinterestはAWS(AmazonWebService)を使う前、トラフィックのピークポイントに合わせてサーバーリソースを用意していた。クラウドに移行すると時間単位でリソースの増減が可能になるので、無駄に支払っていたコストがなくなり、安くなる。

注目すべきはPInterestには専属のインフラエンジニアがいないということ。二人のエンジニアがリソース管理のプログラムを書いて全て自動化してこれを実現している。

Netflixの事例ー「いかに落ちない」ではなく「いかに早く復帰させる」か

米国で夜間ネットトラフィックの三割を占める、とも言われるサービスがビデオ視聴のNetflix。これは全てAWSで動いている。冗長構成が巧くサービスが落ちない。

興味深いのは、彼らはいかにして「落とさないか」ではなく、「落ちてからいかに早く復旧するか」という視点を持っていることだ。「Chaos Monkey」というプログラムがあり、これが定期的にサーバーインスタンスの一部を落としている。それでも問題なく動くことをテストをしているのだ。

従来、サーバーリソースは発注から稼働まで数カ月を要するものだった。クラウドではコマンドひとつで追加ができる。こういう環境の変化が起こっている今、考え方を大きく変えるべきだ。

Coineyの事例ースタートアップが高難易度のセキュリティ認証を取得できた理由

クレジットカード情報を扱うサービスには高い情報セキュリティが求められる。これをスタートアップが運用するのは至難の業だ。国際的なセキュリティ認証のひとつにPCIDSSというものがある。200ほどのチェック項目をパスしなければならず、少人数のスタートアップには手が届かない内容だ。

国内のモバイルペイメントを変えようというスタートアップのCoineyはこれを取得した。Amazonでは既にインフラ部分としてこの認証を受けている。つまり、彼らはアプリケーション層だけ、この認証をパスすればよかった。両方の認証を受けようとするとハードルが高い。

アンデルセンの事例ー変わるデータ解析の考え方

データ解析の考え方が変わってきている。砂漠の中から砂金を見つけるために、これまでは砂金がありそうな場所を特定して、そこを集中的に探すというアプローチだった。クラウド時代は違う。全ての砂を一粒一粒調べることができる。

パンのアンデルセンというお店がある。ここは原価計算のプログラムを一日一回バッチ処理で回してシミュレーションをやっていた。しかしこのバッチ、一度回すのに4時間かかる。しかもいつも成功するとは限らなかった。

そこで、クラウドを使って一時的にサーバーのCPUリソースを増やして処理する方法を選択した。結果、4時間かかっていた処理が20分で終わるようになった。

 

Members

BRIDGEの会員制度「Members」に登録いただくと無料で会員限定の記事が毎月10本までお読みいただけます。また、有料の「Members Plus」の方は記事が全て読めるほか、BRIDGE HOT 100などのコンテンツや会員限定のオンラインイベントにご参加いただけます。
無料で登録する