工場長のブログ

日々思ったことを書いてます。

ソリューションアーキテクトという仕事について

ex-mixi Advent Calander 2017の12/12分のポストです。みんなエモいことを書いているのでわたしもエモいことを書くことにします。

 

ちなみに今日はわたしの結婚記念日で、嫁とはmixiで出会いました(物理/社内)。

 

で、テーマはソリューションアーキテクト(以下、SAと略します)という仕事について。もっとみんなにSAって何なのかというのを知ってもらいたいなと思ってます。SAってめっちゃ面白いよ!ってのを叫びたいのです。なお、本ポストではわたしがAWSでSAをやっていたときの話をしますが、あくまで経験や「わたしはこうやっていた」という話であって、AWSを代表する見解ではないことをご理解ください。

 

mixiには2010/2から2012/7までの約2.5年在籍していて、ずっと広告関連のアプリケーション開発をやっていました。自分のなかではものすごく体感時間長かったんですが、振り返ってみるととても短いですね。で、わたしはその後AWS、Hortonworks、SORACOMと会社は変わりながらですが、ずっとSAをやってます。

 

一緒に仕事したことあるひとから見ると、恐らくセールスエンジニアとか、場合によってはエバンジェリストのような仕事に見えてると思っていて、それはそれで合っています。が、実はそれだけではないので、そのあたりをみなさんにぜひ知ってもらいたいな、と。とてもおもしろい仕事なので、エンジニアのキャリアパスのひとつとして広まったら嬉しいなと思っています。

 

何をやる仕事なの?

 

AWSは馴染みが深い人が多いと思うので、そのときの話を例に話をすすめていきます。AWSのSAが何をする人かというと、お客さんのビジネスを成功させるため/困り事を解決するために、AWSを「うまく」つかってもらう、そのためにあらゆる技術サポートを提供するというのがお仕事です。

 

AWSを使うのがはじめてのひとが相手であれば「AWSで構築する○○(例えばWeb)アプリケーションのよくある構成」みたいなのを説明します。やりたいことはあるんだけどアプリケーションの設計がぼんやりしているお客さんに対しては、ホワイトボードを使ってアーキテクティングをしたりします。設計まで固まってきているお客さんであれば、その設計をもとにレビューをしたりベターなアーキテクチャを目指したディスカッションをしたりします。

 

MySQLの性能が出なくて困っているのであれば、問題がどこにあるのかを突き止めるためのサポートをしつつ、見えてきた問題に対してAWS的にそれをうまく解決するための方法を提案します。もちろん、アプリケーションやクエリの問題だったということがわかるということもよくあります。

 

ここらへんがSAの面白いところなんですが「あー、それはアプリケーションの話なんでそちらで解決してくださいね」みたいな話にはしないんです。アプリケーションの作りやクエリの中身、クエリの投げ方みたいなところまで突っ込んで議論をして、どうすれば問題が解決するのかというのがわかるまでしっかりDeep Diveします。問題の根本原因を見つけて、お客さんと共通の認識を持ち、それに対するアクションを作っていきます。もちろん、いきなり根本解決できればベストなんですが、動いているアプリケーションをいきなりドラスティックに変えることができないということもよくある話です。まずは暫定的にインスタンスサイズのアップだったりリードレプリカの追加、ストレージのIOをより速いものにしたりという対処をしつつ、アプリケーションの改修のディスカッションなんかをしたりします。

 

他にも、必要な性能や機能を満たせるかどうかの検証のためにアプリケーションを書いたり、関連するオープンソースソフトウェアのソースコードや、プロトコルRFCをがっつり読んだりなんてこともします。場合によっては、お客さんの利用料や利用傾向を見て「それ、アプリケーションをこういうふうに直したらもっと安いインスタンスタイプでも全然まわりますよ」なんて提案することもあります。

 

Do the right things的といいますか、お客さんのアプリケーションがより安定的に運用できるようになることであれば、正しいと信じられること/共感を得られることであればJust do itな感じであります。

 

なんでこんなことをするんでしょうか?それは「サステイナブルにプラットフォーム(例えばAWS)を使ってもらう」ということがとても大事だからです。AWSのようなサービスは売り切り型ではなくストック型のビジネスなので、一瞬の売上の高さをあげることよりも、長く使ってもらうことにより、高さだけでなく長さを掛けた面積を最大化することが重要です。

 

ニワトリタマゴな話なんですが、こういうビジネスであるからこそ、SAは技術者として全力でお客さんのヘルプができるというところがあるのです。理論的には、助ければ助けるだけお客さんのアプリケーションやビジネスは安定して、結果としてより長く、スケーラブルに使ってもらえるようになるので。

 

(いちお、誤解のないように補足をすると、AWSは有償のコンサルティングサービスも提供していて、様々なお客さんが、それぞれ必要とする形に合わせた最適なサポートを提供できるようになっています。)

 

SAの仕事をするなかでよく、お客さんからのTechnical Credibility(技術的信頼度)を得るのがとても大事だよねという話が出てきます。みなさんも、あまりよくしらない人にデータベースの選択やプログラミング言語の選択について相談しませんよね?SAは、お客さんからこういった相談をしてもらえるように、(言葉選びが難しいですが)尊敬されるエンジニアであることが必要です。さらにこの信頼度パラメータが高くなってくると「新しい○○という感じの事業を考えてるんだけど、どんな感じに作ったらいいすかね?」なんて相談を受けて「いいっすね!ちょっとホワイトボード使ってディスカッションしますかー」なんていう隠しイベントが発生する確率が上がってきます。

 

この信頼度パラメータをあげるためには、常に最新の技術事情にキャッチアップをしているのはもちろん大事なんですが、それとともに得意な専門分野を持っていることがとても大事です。わたしの場合mixiで広告配信をやっていたので「ハイトラフィックウェブアプリケーション、アドテク、Hadoop」みたいなキーワードが経験の主戦場で、AWSではゲームやアドテク関連の事業をしているお客さんたちを担当していました。

 

こういうのをアメリカの会社っぽくいうとArea Of Depth(AOD)と呼んだりします。AODにおいてはお客さんに対してリアクティブにアドバイスをするだけじゃなくって「あー、これってきっとこの辺りで困ってますよね?ですよね?そこはこういうパターンの実装をするのがベストプラクティスなんですよー(ドヤ」みたいな感じやっていくことが期待されます。

 

このAODを獲得できたのはまさにmixiのときの経験のおかげで、とても感謝してます。2010〜2012当時のmixiはとてもウェブのトラフィックが多くて、そこに対して安定的に広告を配信するアプリケーションを書いていたというのがすごくいい経験になりました。特に在籍期間の後半では「このゲームはあなたのマイミクの○○さんもプレイしてるよ!」みたいな、いまは当たり前になったソーシャル広告の開発をやってました。これって、広告(1ページにいくつも表示される)ごとにソーシャルグラフを始めとする、mixiの様々な箇所からデータを取ってくる必要がありました。コード的な依存関係を最小化し、かつ負荷的にもできるだけ影響を切り離しつつ、いかに高頻度でデータを取得できるか、みたいなことに毎日頭を悩ませてました。あとは、配信した広告をどれだけ早くレポート出せるかみたいなことにも毎日頭を抱えてました。コンソールに流れるmap reduceの進捗状況を「成功してくれ〜。落ちないでくれ〜。これ落ちたらレポート間に合わないんだよ〜。営業に殺されるよ〜。」と祈りながらよく眺めてました。こんな経験があったからこそ、「あるある」なハマりどころやツボをしっかり自分のこととして語り、負荷の高いウェブアプリケーションにおけるアーキテクティングのアドバイスみたいなことができるようになったのかなと。

 

と、なんか昔語りになっちゃいましたが、こういった経験や知識をもとにお客さんとガチでアプリケーションアーキテクチャのディスカッションをするというのがSAのしごとです。ゲームやアドテクの業界のお客さんは普段から○○千QPS、○○万QPSをさばいているひとたちなので、ガチです。

 

最後になんでSAになったのか、ソフトウェアエンジニアからジョブチェンジしてどうだったのかという点にも触れておきたいなと。やっぱり、はじめてSAになる瞬間はとても悩みました。「コード書けなくなってもいいのか?」みたいなことをすごく悩んで、ウジウジ悩んで、嫁に怒られて泣いたりしてました。最終的にはあんまりロジカルな理由はなくて、転職に対してサポーティブだった嫁のPushと「Amazonで働ける」というミーハーな動機で転職しました。

 

で、コードを書かなくなったかというとぜんぜんそんなことはありません。ガチなエンジニアや、ガチなビジネスのプレイヤーを相手にするということは、提案しているプロダクトやサービスについてお客さんと同じ目線で証明を提供することが必要です。それが場合によっては性能を実証のためのコードであったり、アプリケーションのプロトタイプだったりします。

 

サービスやプロダクトを開発するソフトウェアエンジニアとの違いとしては、お客さんの必要なものを汲み取りながら少ない時間で検証コードを書いて動かして見せて理解をしてもらうというサイクルを回すことが多いので、スプリンターのようにコードを書くことが求められることが多いです。(まあこれは好き嫌いあると思いますが)

 

と、つらつらと書いてしまいましたが、これがSAのしごとです。一文にまとめるなら、お客さんのビジネスややりたいことをよしなに(いい意味でいってる)、クイックに汲み取りつつ、それを成功させるために必要な「あらゆる」技術的サポートをするよ、という感じでしょうか。

 

いまはSORACOMというIoTのための通信プラットフォームを提供している会社でSAをやっています。これまではクラウドとかビッグデータ関連の技術をメインに触っていましたが、IoTでは「物理」とか「無線」とか、わたしにとって未知の世界が多くて四苦八苦してますw

 

SAワークとしては、プロトタイピングする対象がソフトウェアだけじゃなくてデバイスなんかも入ってきて、総合格闘技感あって最高です。楽しくやってます。(35才過ぎて、初めて真面目にシリアルとかUARTとか勉強したw)