さて、takaがAWSを使ったサービスについてのエントリを書いてますが、AWSを使いたいから採用したわけではないですし、会社組織なので使いたかったら使えるというもんでもないわけです。場合によっては田園調布に家が建つくらいのお金が動きうる話ですので、相応の行動を起こさねばいけません。このギャグ知らないか。
すなわち、意味があるかどうかをキチンと検討し、意味があるという結論になれば、それを理解してもらうべき人に理解してもらうというステップを踏む必要があります。
今回は、そのステップの足がかりのイメージがわかない人向けに、その足がかりが提供できればと思います。誰得なのかわかんないですけど。
本当にAWSが必要なのか？意味があるのか？を検討する
当たり前といえば当たり前ですが、この問いに対して論理的・具体的に答えられる人は少ない気がします。
- コスト的側面
- 事業スピードの向上的側面
- リクルーティング的側面
- 技術研究的側面
その判断は最終決裁者のみぞ知る所だと思われるかも知れませんが、そこにつながるストーリーの妄想は誰でもできるはずです。妄想しましょう。
妄想して、ある程度のストーリーが描けたら、その妄想が現実に即しているかどうかの裏を取ります。
たとえば、「AWSを使うとコストが抑えれるお！利益増えるどだから使うべきだお！」という妄想をしたのならば、「そうである」ことを具体的なデータを以って現実的（客観的）なものにします。
妄想ポイントはあまりにもケースバイケースなので、今回はこの程度でサクっと通り過ぎます。
妄想の現実化をしたら次のステップです。
紙は大事
妄想したら、その内容を紙に書きましょう。まあ、普通に考えても、こんな話を口頭でいきなり話されても全部理解なんてできないですし、宿題にしようと思っても覚えきれるわけもありません。真剣味も伝わりません。
ぼくが20代を過ごした環境では、「手ぶらだったら会議なんてやらないほうがいい。1枚でもいいから紙もってけ」とか「会議は戦だ。そして戦は準備の段階で勝敗が決まる（←武田信玄のセリフらしいです）」といった具合に交渉ごとや打ち合わせなどの会議においては必ず紙という装備で攻守を固めることを要求されましたが、こういった経験はいろんなところでぼくを助けてくれています。感謝。
ところで、会議の内容にもよりますが、なにもない時でも5分で書ける程度の箇条書きのアジェンダでいいので持って行きましょう。たった一枚の紙が、参加者する人の目的意識を統一し、緊張感を持たせることができたりします。5分でかけるアジェンダもないなら会議をやめたらいいじゃない。
なお、ここでいう「紙」というのは資料のことで、僕にその辺のことを叩き込んだ先輩たちがそういっていたので一般的な言い方かどうかはよくわかんないです。パワポでもKeynoteでも何でもいいと思います。やっぱ何でもよくないかも。状況に応じて適切なものを選んでください。
口頭で言って通るケースもありますが、少なくともお金や時間がかかるものであれば、そういったケースはラッキーだと思うべきでしょう。
というわけで、できたものをふんだんに伏せ字などの加工したものがこちらになります。
この資料で主に訴えているのは、が「コスト効率」と「事業スピード向上」ですが、「リクルーティング」も自動的におまけで少しついてくる気がします。これはたぶん、ほとんどのAWS採用のケースにおいて同じかと思います。
これをベースに進めていきたいと思います。
紙の構成
目的を書く
まず、目的を書きましょう。この資料がなんのためのものなのかを最初に宣言しておきます。なんとなしに始めても相手はその話を聞く脳みその準備ができてないから、ほぇ？ってなって途中から聞く気が失せてしまう可能性があります。
今回の場合は要するに、
「新Webサービス「○○プロジェクト」のプラットフォームではこうこうこういう理由でこっちを使うのがいいと思うお！」
ということを伝えることが目的だったのでそんな感じのことを書きました。
「プラットフォーム」とかその辺はあいまいだったり、聞く側がなんのことやらわからない場合もあるので、その辺を考慮して適宜補足しましょう。
「システム構成」って言葉は今見るとかなりイマイチかも。。どんまい。通じればいいのです。
考慮のポイントを書く
次に考慮のポイントを書きます。
今回の場合は「Webサービスのプラットフォーム選択」がテーマなわけですから、Webのプラットフォームを選択する場合にどういった点が考慮のポイントになるかを書き連ねます。
- 安定性
- 継続性
- 柔軟性
- コスト
まあ、とにかく、このポイントも大事で、あまりシステムに詳しくない人でも「そうだよね」と思えるような説明が望ましいです。
で、今回はハウジング運用の実績があるので、それぞれのポイントに対して現状はどうなの？というところを具体例として次ページにつけ加えています。
選択肢を書く
クラウド（AWSではない）とハウジングというのがここまでに出てきましたが、「他に選択肢はないの？」と思う人は普通にいると思います。決裁者がシステムに詳しくなければ確実に思うでしょう。「この粒度だとうちが採れそうな選択肢は他にはないよなぁ。」と思いましたが、2択というのもなんなので、今回は、ハウジングとクラウドとVPSを挙げてみました。挙げときながらなんですが、VPSの特徴を挙げてみたところで「ここで外しちゃっても納得してもらえるな」と思ったので、この時点で考慮対象から除外しておきました。
ちなみにうちじゃなければ「オール自前インフラ」という選択肢も場合によってはあるでしょう。
あと、ここでの「クラウド」は当然Paasとしてのクラウドのことですが、「クラウド」は人や状況によって受け取り方が変わるものなので、必要に応じて「クラウド」という言葉の定義も確認しておいたほうがいいです。
さて、この時点でハウジングとクラウド（AWSではない）の一騎打ちになったということですね。
次ページは、このページの補足ページです。VPSやクラウドについて特徴を書いてはいるものの、「インスタンス」とかいう謎ワードも登場させていますし、人によってはやはり「なんのこっちゃ」になるので書いてみました。
前提条件を書く
ここまでで、考慮のポイントと、取りうる選択肢について記述してきました。どの選択肢が正解になるかは、そこに乗っかるサービスの特性によります。
期間限定のサービスだったら、ハウジングという選択肢はなかなか取りづらいでしょうし、そもそもクローズドで利用人数も限られるようなものであれば、今回は考慮対象外としたVPSという選択肢も最適になり得ます。実際、ミツバチワークスのHPなど、社内インフラにはVPSを利用しているものもあります。あれ、HPは違ったっけ。ちょっと覚えてない。
ということで、次に新サービスの特徴を書きました。そして、ここで「クラウドがオススメ」という結論を持ってきてます。
たぶん、こういう比較衡量系の資料のスタンダートな形は、考慮ポイントに沿ったそれぞれの選択肢のメリット・デメリットを書き連ね、最後にマトリクスにして見やすくして、場合によっては、考慮ポイントごとに比重をつけたりして、「この選択肢がベストですな」っていう感じになると思います。
が、今回は早々にVPSという選択肢を潰し、残りの「ハウジング」という選択肢のメリット・デメリットは長きにわたる運用にて共有できていたので、ちょっとしたまとめで十分な状態でした。
要は
というアプローチでよいと思ったので、そうしました。ダメなら出直すまで。
- 現時点で新サービスをスタートするにあたって、ハウジングよりクラウドのほうが適切と言えるや否や？
というアプローチでよいと思ったので、そうしました。ダメなら出直すまで。
ですので、今後はクラウドについての説明が中心になります。
クラウドの中での選択肢
いきなり「今回のプロジェクトではAWSをお勧めします。AWSとはクラウドのことです。」とかいうと、「クラウドってAWSしかないの？」と思われる確率は80%です。そもそもこの話に興味がない確率は10％です。実は隠してたけどAWS大好きな確率は10％です（ファイ風）。
ですので、他の選択肢も挙げました。が、いきなりAWSしかないという結論に一発で持ってきています。ここも、そうできる素地があるのでそうしてますが、場合によってはこうは行かない状況も多分にあると思います。
その場合は、クラウドPaasの中での絞り込みに関する説明を用意しましょう。
クラウドを選択することのリスク
最初の方で挙げた「考慮のポイント」ごとにリスクがあるかどうかを説明していきます。リスクというより、デメリットと書いたほうがいい気がしてきました。まあいいや。
ちなみに「柔軟性」を挙げてないですが、ここがクラウドのハウジングに対する最たる優位性だと思うのでデメリットとしてあげるのもなんなので弾いちゃいました。が、なんの説明もなしになくなると「あれっ？」となるので、ちゃんと挙げた上で、「デメリットは特にありません（ｷﾘｯ」とするほうがいいかもです。もしくは、DiskIOについて触れたい人はここで触れておくといいでしょう。
その後は、つらつらと各ポイントにおいて、
- リスクがあるかないか
- リスクがある場合、それは許容範囲なのか？それを補完する手段はあるのか？
などを書いていきます。
安定性や継続性については、具体例を交え「問題ないよ」と書いてありますね。うん。そう思います。
一番難しいのがコストです。「大丈夫っス！問題ないっス！」と確実性をもっていえる客観的な数字を見つけることができませんでした。
- 最大限、見積もれる範囲で見積もり、
- 最悪コストが完全にアテが外れた場合、そこからハウジングなどの他の手段に移行は可能であることを確認し
- その他の事項（為替リスクとか）についても共有し
- プラス要素として、人的リソースについてもセーブできること（Appendixでちゃらっとにしてしまいましたが）
- 何よりも、規模が大きくなってもAWSを採用し続けているサービスの存在が多数あることを説明
することで検討材料としました。
見積もりに際しては、なるべくトラフィック性質が近しいサービスが発表している数値などをベースにするのがいいと思います。
最後の計算メモは、事細かい質問があったとしても答えれるようにメモったメモです。
何を公開してもいいか考えるのがめんどくさくなったので、ほとんど潰しちゃいましたが。
まとめ
というわけで、最初4つ挙げた指標（安定性・継続性・柔軟性・コスト）のうち、
- 最初の２つはハウジングと同等
- 柔軟性は優れている
- コストはたぶん、悪くてもトントンかそこらになると見込んでいる。
- トントンなら人的リソースを考慮すればコストに関してもメリットが勝る
ということで「今回はAWSの採用が妥当である」という見解を共有しました。（っていうかそういうまとめページ作るべき）
資料のおおまかな内容については、以上です。
これ作って説明したら「ハイ！採用！」って決まるかっていったらそうじゃないことも大いにあるでしょう。が、少なくとも前に向いた話のスタートは切れると思います。要は話の土台を作ることが大事です。
大事なこと
サンプルとしてはこんなところですが、これはあくまでも一例であって、これが情報として十分というわけでもないですし、逆に多すぎるケースもあるかもしれません。話の展開のしかたも、内情を踏まえたものになっています。
ここが大事なことなんですが、ぼくは、紙は自分が言いたいことを書くのではなく、相手に知ってもらいたいことを書くのだと思っています。
- 自分が主張したいテーマの重要性
- そのテーマについて相手はどのくらいの知識があるのか？
- 判断を迫る内容なら、その判断をするために相手が何を知りたがるか？
紙じゃなくてもメールでも口頭でもなんでも、コミュニケーションというものはそういうもんだと思っています。
こんなの僕も全然できてないのでアレですが、なんでも「できるかできないか」じゃなくて、「やるかやらないか」なので、意識してやってりゃそのうちうまくなっていくもんじゃないでしょうか。寄生獣の後藤も以下略。
ちなみに上記の資料はクリエイティブ・コモンズで、とかいったら社内の人にプークスクスとか言われたので使い道があるもんならどうぞご自由にお使いください。
繰り返しますが
- 社内向け
- 口頭補足前提
- スピード超重視
対外向けかつ一発勝負の場合は、もっといろいろ考えたほうがいいと思います。
また、この資料はレイアウトとかフォントサイズとか、いろいろだらしないですが、それなりの空気感のところに出す場合などはそういうのも超大事です。例えば意味なくインデントがずれてるだけでアウトです（なぜかはまた今度）がその辺も考慮されてません。とか、言い出したらキリないのでこの辺で。
AWSについては近頃こんなスバラシイ資料がアップされたようです。参考にしましょう。
http://www.slideshare.net/kentamagawa/aws214jaws
ここまでの内容のひとつひとつの手順に難しいところはないと思いますし、慣れればかかる時間はどんどん短くなると思います。寄生ry）。
ちなみに今回の例では一番時間がかかると思っていた情報収集がスムーズにいったので、全部で半日（4時間）もかけてないと思います。ラッキー。うそです。takaがいろいろ用意してくれたから早くできました！チームプレイ！
あと、こういう資料は磨こうと思えばいくらでも磨けてしまいます。この資料も今回ブログを書くにあたって久々に見てみましたが、改善点がボロボロでてきます。「AWSのプラス面がぜんぜん印象に残らねーな」とか。
このように、ベストを目指すと終わらない性質のものですので、資料作りに時間の制約がない場合は、かける時間を決めて取り組んだほうがいいと思います。
というわけで、「偉い人にはそれがわからんのです」とか思っているような何かがある人は、ちゃんと資料用意して攻めるとこ攻めれば違う展開がまっている可能性80％です。資料のできが悪い確率10％です。上司がイケてない確率10％です（ファイ風）。一方で、大人になるとどんなに星にお願いしてもサンタさんはやってこないのです。大人ってキツイ＞＜。
このエントリの説明はゆるいですけど、たぶんおねだりのしかたを説明してくれている本はたくさん売ってるとおもいますし、「提案書 書き方」とかそういうのでぐぐるとバシッと説明してくれているものがあると思います(ググってない）ので、この辺を深堀りしてみたくなった方はぜひそうしてみてください。
もしくはミツバチワークスに入社して僕と一緒に勉強しましょう。
ではまた！