MIJSシリコンバレーツアーに参加してきました

Avatar
dstn


開発部の佐々木です。

先月、MIJS製品技術強化委員会のイベントでシリコンバレーに行き、シリコンバレーの企業とそこで活躍する日本人のエンジニアを訪問しました。

訪問した企業は、Box、IP Infusion、Runway、Treasure Data、Zendeskで、エンジニアはTwitter、Facebookで活躍されている日本人エンジニアの方にお会いしてきました。
MIJSの参加メンバーはエンジニア中心のツアーということで、主に、開発手法や組織のあり方、デプロイ、テストの考え方など、エンジニアリングにまつわるディスカッションをしてきました。

今回の記事ではいくつかのトピックで私が印象に残ったものについて紹介したいと思います。

開発チームについて


エンジニアやプロダクトマネージャーなど、一つのプロダクトを作り上げていくにはいろいろな立場の人達、チームが協調し合って進めていくことが大事ですが、それぞれの立場における役割がとても明確になっている印象を受けました。

プロダクトマネージャーは自分が担当する製品、機能について定義する立場で、ユースケースを完全に把握している必要があり、そのために、製品、機能についてとことん考えて、ユーザからのフィードバックを得るためにユーザーコミュニティに参加したり、時にはユーザに直接訪問することもあるとのことです。

エンジニアリングチームにおいては、一つの製品、サービスの中で機能ごとにチーム分けされていて(例えばフロントエンドチーム、Analyticsチーム、Adsチーム、決済チームなど)、それぞれに専門性を明確にして開発を行っているのが印象的でした。

また、製品、サービスのリリース後に発生するバグ対応やメンテナンスについては、エンジニアリングチームとは別に「サステイニングチーム」という専門のチームで対応するという企業もいて、弊社でもそのような体制を組んでいるので共感できました。

開発プロセスについて


Webサービス系の企業ではアジャイルを採用しているところが多かったです。

アジャイルの中でも特にスクラムをベースに実践していて、

1~2週間でスプリントをプランニングして、
毎日決まった時間にスタンドアップミーティングを行い、
スプリントごとにバックロググルーミングを行い次のスプリントのためにバックログ内の項目に優先順位付けとスコープを調整し、
最後にレトロスペクティブ(振り返り会)を開催してうまくいったこと/改善するところなどを話し合う

というようなプロセスを踏んでるところがありました。

一方で、組み込み系の会社では「 戦略的にウォーターフォールを採用している」ところもありました。
Webサービス系の場合は、デプロイしたサービスに何か問題が発生した場合、デプロイ先をすぐに前の状態に戻すという対応が可能ですが、組み込み系は、すでに多数のユーザの環境に入っている場合があり、Webサービスのようにすぐにパッチを提供したり元に戻すということが困難なため、ウォーターフォールを採用していることには納得感がありました。

アジャイル、ウォーターフォール両者の特徴をしっかり理解した上で、自分達が提供するサービス、製品開発に適した手法を採用することが大事だと感じました。

ドキュメントについて


プロダクトマネージャーや、エンジニアリングチームなどそれぞれの役割でドキュメントを作成しているところが多かったです。
例えば、プロダクトマネージャーの場合、製品、機能を定義するPRD(Product Requirement Document)を作成し、他のプロダクトマネージャー、エンジニアリングチームなどにシェアすることで、自分の考えを伝える手段としてだけでなく、フィードバックをもらう手段としても活用していました。

また、エンジニアリングチームでは、開発前に「 デザインDoc」という1~2ページのドキュメントを作成し、このドキュメントに課題、解決手段、ゴール、スケジュールなどを記述して、関係する人にレビューしてもらうということを実践しているところがありました。

あと印象深かったのが、ある企業の方で、社内の運用周りのノウハウなど、「 自分しかしらないことは積極的にドキュメント化するようにしている」とコメントしていたことでした。
会社や組織が小さい時は、自分だけが知ってて他人が知らなくてもそんなに困るケースはない、むしろドキュメント化するコストに対しての効果が小さいように思いますが、規模が大きくなるにつれて、ナレッジ共有や意思伝達手段としてのドキュメントは有効なツールだと再認識しました。

デプロイについて


Webサービス系の企業では、自動デプロイにChefやPuppetを使っているけど、それだけじゃなく作り込みもかなりしているとのことでした。

また、デプロイの頻度は、大きなプロジェクトは週に1回、小さなプロジェクトは1日に数回、いきなりプロダクションにデプロイするのではなく、ステージングや最新のマスターなどでモニターしてからプロダクションにデプロイ、その際、対象のユーザを絞って(例えば全ユーザの5%)、そこで問題が発生しないことを確認したら、徐々に公開するユーザを増やしていく(いわゆる炭鉱のカナリア)ということをやっているとのことでした。

私自身、パッケージ開発を専門でやってきたので、このあたりは本やWebで読んだ程度の知識しかなくあまり議論できませんでしたが、Webサービス系企業のツアー参加者は共感するところも多く活発に意見交換をしていました。

テスト・QAについて


テストに関しては、エンジニアはユニットテストを書いて、テストが通ればコミットokとなり、コードレビューも通ってコミットすると自動テストが走るという仕組みを導入している企業がありました。

ユニットテストと自動化については弊社でもだいぶ前から実践していて、プロダクトコードをメンテナンスしていくためにはユニットテストとその自動化は非常に大事なことだと考えているので、とても共感できました。
また、効果的なテストの書き方や、コードの品質に対してアドバイスをする専門チームを立ち上げている企業もあり、一個人ではなく組織でのテストの品質向上への取り組みは興味深かったです。

QAに関しては自社でQAチームを持ってるところもあればオフショアしているところもあり、いずれもマニュアルテストを行っているとのことでした。
弊社のQAチームの工数を考えると、一日数回のデプロイがよく実現できているなと思いましたが、Webサービスの場合、パッケージとは違って問題が発生したら前の状態に戻せるという特徴から、マニュアルテストの範囲を絞っているのではと思いました。

また、シリコンバレーの企業はグローバルに展開するのが当たり前で、国際化を専門で行うチームがいて、国際化チームが各チーム(エンジニアリング、クリエイティブ、QAなど)と連携して、国際化しやすいコーディングや、アイコンのデザイン、国際化の観点でのQAなど各所にアドバイスをして、根本から製品、サービスの国際化を行っているというところもありました。

最後に


私はエンジニアなので、日本のエンジニアとシリコンバレーのエンジニアとの違いはなにかというのが一番知りたかったところですが、個々のエンジニアの違いというよりも エンジニアとして働く環境が大きく違うと感じました。

例えば、iOSアプリを開発するときに同僚に元AppleでiOSそのものを開発してた人がいたり、アニュアル、クォーターごとにエンジニアのゴールがあってそれを達成するためのプランが明確になってたり、情報の流通が速かったり(日本だと翻訳されて記事になるまでが遅い)、エンジニアとして働くための環境がとても充実していると感じました。

一方で自身の結果がでなければ即日解雇もあり得るというドラスティックな側面もありますが、エンジニアを一生の生業として覚悟を決められる人にとってはやりがいのある環境だと思いました。

IMG_0302

コメント

ログインしてコメントを残してください。

Powered by Zendesk