アマゾンにおけるソフトウェア開発の仕事について感じたこと

英語学習 勉強会・セミナー PGのキャリアーパス

ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。

私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。

私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想（転職して感じたウォーターフォール文化とアジャイル文化の違いについて - 達人プログラマーを目指して）から大きくは変わっていないのですが、徐々に会社の文化や仕事のスタイルに慣れ、また、開発環境やツールにも習熟してくるにつれて、始めの頃の不安や戸惑いがようやく薄れて、徐々に自信や面白みに変化してきたかなという段階です。

SDEはやはりプログラミングが仕事の中心

アマゾンでもアプリケーション開発からインフラ、コンサルティングまで様々なエンジニアのポジションがあるのですが、私はソフトウェア開発技術者（Software Development Engineer、SDE）という役割で、携帯電話用のWebサイトを開発するAnywhereというチームで働いています。*1SDEとはいわゆるプログラマーのことなので、SIerで働いていた頃と違って、実際にアプリケーションのコードを自分で作成・修正するということが仕事の中心となります。

もちろん、開発環境が動かなくなってトラブルシュートに時間を取られたり、他のチームとのコミュニケーションに必要な時間もあるため、毎日すべての時間をコーディング作業に費やすということが可能なわけではありませんが、できる限りコーディングに時間をさけるようにすることが生産性の高いSDEとしては義務であり権利でもあると考えられています。前職では何か月もExcelの設計書を書いたり、パワーポイントの提案資料を考えたりという時期があり、コードを書くことも他の開発者向けのサンプル程度というプロジェクトが多くあり、プログラマーとしては欲求不満になってしまう場合が多くありました。現職では、とにかく実際にアプリケーションの機能を自分自身で実装するという仕事に堂々と集中することができ、プログラミング技術を発揮し、さらに腕を磨きたいと考えていた私にとっては大変に適合した仕事でうれしく思っています。

そういうわけもあって、SDEの採用面接では、まず何よりもプログラミングや開発の基礎力が問われます。プログラミング言語を使ったロジックの記述から、データ構造やアルゴリズムといったコンピューターサイエンスの基礎知識が問われるようです。個人的には実際の開発に必要な経験や知識はそれ以外に、開発ツール、フレームワーク、ミドルウェアを使いこなすことが重要だとは思いますが、多くの場合は面接で能力を測る基準としては基礎力を重視しているようですね。

プロジェクトの規模とペース

それから、SIerの場合と大きく異なることとして、一般に個々のチームやプロジェクトの規模が小さく*2、とにかく数週間から数か月といった早いペースで機能を連続的にリリースしていくということがあります。オープンハウスでも紹介したように、アマゾンでは、Scrumというアジャイルプロセスが標準的に多くのチームで採用されています。通常は提案や画面設計に何か月も費やすということはありませんし、プロジェクトがキックオフしたその日のうちからプロトタイプの着手に取り掛かるということが普通です。そして、数週間から数か月といった単位で様々なプロジェクトが並行して活動し、次々と機能追加をリリースしていきます。

もちろん、アマゾンでもキンドルやプライムといったビジネスモデルに大きく影響を与えるようなプロジェクトだと世界中のたくさんの開発者が参加する大規模なプロジェクトになるわけですが、個々のチームは比較的小規模なチームに分かれていますので、一つのチームの単位としては1人からせいぜい5人程度の小規模なグループで作業します。

文書化の作業はどうしても優先度が大変に低いと考えられているので、最初のうちは呼び出すAPIがわからないとか、そもそも準備されていないといったことや、リリース直前のUATの段階でUIの変更が入ったりということもあります。一般的なSI案件のように決まった設計書を念入りに準備して、その通りに作成、納品するという考え方とは当然大きく違っています。私も、Excel方眼紙などに細かく仕様を記述する方法は嫌いなのですが、APIのドキュメントやアーキテクチャ概要のドキュメントなどはもう少ししっかりしたものがあればなあと時々思うことはあります。特に、自分の英語力の問題から、口頭やラフなメールで説明されるより、フォーマルな文書が基準としてあった方が便利なのにと感じることはありますが、変化のペースがとにかく速いので、文書化はどうしても後回しになってしまう傾向があるようです。

SDEに与えられる大きな権限

個々のSDEは単にコードを記述するというだけでなく、仕様変更やリリース時期の調整などを含めてプロダクトマネージャやデザインチームに対して意見を述べることが期待されます。また、リファクタリングやツール、プロセスの改善などを積極的に工夫し、自らプロジェクトとして提案するというような活動は大いに歓迎されます。*3とにかく、手を動かすということが評価されるようですね。

それから、デプロイメントの自動化などのツールは充実しているので、SDEの権限で本番環境を含めて様々な環境にアプリケーションをリリースすることが可能です。緊急の大きな障害が発生したような場合、一般のスケジュールとは別に急きょ試験、リリーススケジュールを立て、本番へのリリースを行うといったことも発生します。もちろん、さらに大きな障害につながる恐れもあるわけで、これは、私もなかなか最初はすごく緊張したのですが、最近はようやく肝が据わってきたかなという感じです。

新規開発よりも、既存システムの改善

私の担当したSIer案件では、アーキテクチャの提案やビジネスプロセスモデリングといった上流工程からプロジェクトが開始するということは結構普通でした。私はアーキテクトという役割から、比較的新しいフレームワークの活用方法を考えたり、全体的なシステムのしくみを考えるといったこともありました。現在の自分の経験と立場ではそこまで大きな視点でシステムを考えるという段階ではないところもありますが、既存のバグを修正したり、リファクタリングを行ったりという作業が日々の作業の中心となっています。SOAのような大きなアーキテクチャは長い時間の間に徐々に完成させられてきたため、基本的には小さな改善をこつこつと積み重ねるというボトムアップのアプローチです。ただし、新しい技術の採用など、時には思いきった大きな変更やブレークスルーも必要だと思います。

学ぶべきツールやフレームワークなどが無数にある

アマゾンの場合は、AWSなどの公開されたツールもたくさんありますが、社内にはそれ以上にたくさんのツールやフレームワーク、活用すべきデータがあります。他のチームのソースコードは社内では基本的に公開されています。残念ながら、多くのツールは外部には非公開なので、ここではあまり詳しく書けませんが、そういう意味で、いろいろと研究のしがいがあります。

具体的にソフトウェアの改善効果が数値化されている

先日のイベントでもA-Bテスト*4という考え方について紹介したのですが、アマゾンではレスポンス時間などシステム的なことはもちろん、アクセス数や売り上げなどビジネスにつながるさまざまなメトリクスを自動計測する仕掛けが提供されています。したがって、追加した機能が効果的かどうかということがグラフとしてすぐにわかってしまう仕組みになっています。自分の作成した機能の効果がどんなものなのかがリリース直後から確かめられるのは、楽しいものがあります。

もちろん、アマゾンの社員が目指すべき最も大切な目標としてCustomer Obsession（顧客第一）というのがあるので、そういった情報はユーザーエクスペリエンスの向上に活用されます。

英語を使ったコミュニケーションの必要性

アマゾンジャパンの公用語は日本語なので、日本語が通じる人には堂々と日本語を使ってもよいのですが、外国人や海外のチームとコミュニケーションする際にはどうしても英語を使わなくてはなりません。Scrumなどの会議もすべて英語で行われています。*5

結局、私の所属するチームでは、ほぼ英語でコミュニケーションする必要があります。自分の英語力では、何とか会議の話について行って、進捗を報告するというくらいはできても、なかなか自由に自分の考え方を伝えることは簡単ではないというところがあります。やはり、この点に関しては私にとって英語圏の人に比べてものすごいハンディがあると感じざるを得ませんが、技術力などでカバーしていくしかないですね。

英語のハンディという点では多くの日本人だけでなく、中国人も同様のようなのですが、最低限メールやチャットなどで会話ができれば何とかコミュニケーションはできます。また、コードレビューもソースコードのdiffを使ってオンラインでコミュニケーションするのでまあ何とかなりますね。

ちなみに、ランチタイムは重要な英会話レッスンのチャンスだと思ってできる限り外国人の同僚と一緒に食べに行くようにしているのですが、おかげでハンバーガーや中華など脂っこい食事を食べる機会が大幅に増えました。アマゾンの目黒新オフィスでは社員食堂ができたので、今は自分の好きなメニューを選択できるようになりましたが。

まとめ

以上、最近仕事について感じたことをいくつか簡単に書いてみました。いろいろ苦労するところもありますが、自信を持って日々大いに楽しんで仕事ができているかなと思います。そういうこともあって、最近は情報をインプットして処理するという方にどうしても時間が割かれてしまい、ここのところ、ブログの更新頻度が下がっています。どこまで技術的なことを書いてよいかということはありましたが、JavaやPerlなどの一般的な言語や公開されているツールの話については、大丈夫なようですし、また余裕が出てきたら時々更新していければと思います。

*1:日本に携帯サイトの開発チームがおかれているのは、やはり世界的にみても日本の携帯電話の技術や使い方がユニークで進んでいるという事実があります。

*2:SOAに従ったソフトウェアの構造にならい、開発組織もカート、カタログ、検索、注文プロセス、運用基盤など、システムやユースケース単位ごとに独立した小さな開発チームに分かれており、全体としてチームがいくつあるのかさえ把握が困難。

*3:最初私も勘違いしていましたが、アマゾンも全然理想郷ではないので、いろいろ問題や改善点がたくさんあります。エンジニアにとっては改善点があることはモチベーションにつながるのでよいのですが。

*4:異なるバージョンを一定割合ごとに同時にリリースして、統計的に効果を確かめるテスト手法。

*5:時々裏で中国語や日本語が混じりますが。