Why are Japanese companies losing their programming talent [1]? There are no lack of discussions on the topic [2], but far fewer first-person perspectives. Blogger/programmer Ryo Asai [3] (@ryoasai74 [4]) and his blog “Becoming a Master Programmer” provide one. After working for seven years at a Japanese IT company in the system integration sector [5], Asai recently decided to apply for a position at Amazon Japan, and got the job [6].

In this article, I'll be translating a blog post by Asai titled “What I noticed about the differences between Waterfall and Agile programming approaches after changing jobs [7]” [jp] (転職して感じたウォーターフォール文化とアジャイル文化の違いについて). For background on why Asai decided to quit his previous job, see Part 1 [6] of this series.

A Global workplace

Asai begins the post with a run-down of the challenges he's faced so far at his new workplace:

やはり、自分としては、外資系の会社で英語でのコミュニケーションが必要となるということが、最も気がかりなことでした。実際、初日の歓迎ランチはいきなり名前もわからない多くの外国人に囲まれる状況でしたし、電話会議を使って中国やアメリカのチームと一緒に行う日々の進捗ミーティングも英語で行われています。自分としては、特に、リスニングが 苦手ということもあり、いまだに完全に会話についていくのが困難なところはありますが、同僚やマネージャーもみんなすごく親切に教えてくれるので安心しました。私は新しい環境に慣れるのに結構時間がかかる方なので、まだまだ完全に新しい職場の文化に適応するというところまではいかないのですが、徐々に仕事のやり方を覚えて、チームの一員として頼られる存在となれるよう努力していきたいですね。

What caused me the most anxiety, working at a foreign company, was having to communicate in English. On the welcome lunch on the first day, suddenly being surrounded by a bunch of foreigners whose names I didn’t even know, then having daily meetings via conference calls, also in English, with teams in China and America. My English listening skills aren’t that great, so it’s pretty hard for me to follow a conversation in English completely, but my coworkers and managers were all really kind in explaining things to me, and that reassured me. I’m someone who takes quite a lot of time to adjust to a new environment, and I’m not yet fully adapted to my new workplace, but slowly I’m learning how things work, and really putting a lot of effort to adjust and become one of the team.

ということで、実はまだ新しい会社の文化を完全に理解したという段階ではないのですが、それでも以前私が働いていたSI業界の文化とアジャイルな考え方が尊重されるグローバル企業とでは、やはり大きな違いがあるなということは、実際にはっきりと感じられますね。

Although I’m not yet at the stage where I can say that I’ve fully grasped the culture of the new company, I’m already sensing very keenly the sharp differences between the culture of my previous job, in the SI (system integration) industry, and the culture of my current job, a global corporation which follows an agile approach.

An agile workplace

This agile approach [9] to software development also required some adjustment:

まず、第一に大きく違うと思ったのは、会社の売上や利益に直接つながる、ビジネスの中心に近いところに開発チームが置かれていて、当然プログラマーはプロダクトオーナーなどビジネス担当の人と密接にやり取りをしながら開発を進めるというところがありますね。ビジネス担当の人とプログラマーが同じ部屋で作業をするということはもちろん、たとえば「この項目を外すとプログラムはすごくシンプルになるし、顧客にとっても画面がすっきりしてメリットがあると思いますが。」といったような提案をプログラマーからすると、あっさり認められて翌月のリリースに変更を反映するといったことが日常に行われています。

The first thing that I noticed was really different is that the development team is positioned very close to the heart of the business that directly influences the company’s sales and profits. This naturally means that developers are in close communication with those in charge of business such as the product managers. The business people and programmers are in the same room, and from the point of view of the programmer, this means that every day, proposals to, for example, delete a field to make the code simpler and user interface cleaner are quickly approved and incorporated into next month’s release.

少しでも使いやすいシステムの開発に貢献することで、売上に貢献するのだというモチベーションも湧きます。ウォーターフォールが中心のSI業界のやり方だと、項目の追加はまだしも削除などと言うことを提案しても、稟議書などを上げて何階層にもわたった承認が必要で、何週間、何か月も待つといったことは普通だと思います。そのような状況があるので、PGの側でもよいアイデアがあっても、わざわざ提案しようという気にはならないし、逆に、仕様書に書かれていることのみを実装して、余程の問題がない限りそれ以上のことはやらないという傾向が強くなってしまうところがあると思います。

Knowing that even your small contribution to making the system more easy-to-use will lead to increased sales is a big motivator. In the SI (System Integration) industry, with its focus on the waterfall model of development, just adding or removing a field requires writing up an official request and getting approval from various levels of management, and typically takes weeks if not months to finalize. What tends to happen as a result, I find, is that even if a programmer has a good idea, they won’t go the trouble of actually proposing it, and instead simply implement exactly what’s written in the specs, unless there’s some kind of major problem.

それから、チームのサイズが小さくて、業務担当の人とプログラマーが直接会話できる距離にあるため、作成する文書は非常に少ないというところがあります。これはもちろんチームによると思いますが、開発後に説明のためWikiに情報を書くということはあっても実装前にWordやExcelの文書を作成するということはめったにないですし、作業時間の大半はEmacs、Vim、Eclipseといったツールを立ち上げてのコーディング、単体テストの 作業が中心となります。以前は自分自身がコードを書くといった作業にあてられる時間は、全体のプロジェクトの中ではせいぜい10%程度でしたので、そこは 大きな違いだと感じています。逆に言うと、自分の英語力のなさから、口頭で英語で説明を受けても理解しにくいというところがあり、時としてきちんと書かれた仕様書が恋しくなる時もあるわけですが、そこは文化の違いですね。

Teams [at Amazon] are also small, with people in charge of operations close enough to programmers to interact closely with them, resulting in far less documentation. While this may of course vary from team to team, I’ve found that while wikis are used to document code post-development, there are very few cases of people producing Word or Excel documents prior to implementation — most of our time is spent coding and unit testing in tools such as Emacs, Vim and Eclipse. At my previous job, I probably spent at most 10% of my time on the project actually writing code, so this was a really big change for me. On the other hand, my English isn’t very good, so even when people would try to explain things to me, I often had trouble understanding. This made me sometimes long for clearly-written specifications, but I guess this is a cultural difference.

A dynamic workplace

The business model at Amazon is also different to his previous workplace:

さらに、B2Cでどんどん新しい機能をリリースしていくという環境では、システム全体を何年もかけて作り直すという機会はほとんどありません。むしろ、細かい機能改善やバグフィックスを行うというプレッシャーが常にあり、その中で空き時間を見つけてリファクタリングを繰り返すという方向になります。

To add to this, my new workplace follows the Business-to-Consumer (B2C) model in which new functions are constantly being released, so even over a span of many years, there are hardly any opportunities to rebuild the entire system. Quite the contrary, there is constant pressure to incrementally improve functionality and fix bugs, and the refactoring is done within any free time that can be found.

そういう意味では、SIerのように新システムの開発をゼロから行うという機会はめったにありません。だから、常に最新の言語やフレームワークでなくては嫌な人には向いていないかもしれません。一方、SIerの場合は自分のシステムを維持管理するという機会は少ないのですから、むしろ、最新の最良の開発手法を取り込めばすごく面白い仕事ができるのに、実際には古いフレームワークを使い続けているケースが多いというのは残念なことですね。

In that sense, there are virtually no opportunities [at Amazon] to build a system from the ground up, as a System Integrator (SIer) does. So it might not be the right kind of work for someone who wants to always work with the latest languages and frameworks. On the other hand, system integrators don’t have many opportunities to maintain and administer their own systems, so although their work could be really interesting if they were able to adopt the latest and best development techniques, in reality most end up stuck continuously working with old frameworks.

Asai's earlier blog entry discussed the so-called “retirement age” of 35 imposed on programmers in Japan. But Amazon has no such retirement age:

なお、気にしていた自分の年齢ですが、やはり、グローバルな会社では35歳定年などということは全くないですね。今の会社の場合は全くの新卒というよりも、ある程度経験を積んだ人を中心に採用しているようなので、プログラマーとして自分くらいの年齢でも結構普通みたいです。実際、おじさんというレベルを超えて、そろそろ孫がいても不思議でない、おじいさんという感じの年齢の現役プログラマーもたくさん活躍しています。もちろん、年齢というよりはスキルによってポジションが決まるので、年齢が下の人がより上級のプログラマーということも普通にあり得ます。（おじさんと書きましたが、もちろん、グローバルには女性のプログラマーもたくさんいます。）

One thing I was worried when I started my new job was my age, but I’ve found that at a global corporation, there’s no retirement at age 35. At my new job, they seem to focus on hiring people who have some degree of experience over fresh graduates, so for a programmer, my age is nothing out of the ordinary. In fact, there are a lot of very active programmers here who are much older, almost like old men — you could imagine some of them might even have grandchildren. Of course, positions are filled based on skills not age, so there are also lots of younger programmers in higher-ranking jobs. (I wrote “old men”, but of course there are also many women programmers at global corporations.)

Feedback

In bookmark comments, responses to the post were positive:

megascus [10]:

改善ができるというのは素晴らしい。

It's amazing that they can continuously improve [the systems] like that.

mongolianpunch [11]:

楽しそうだなー

Wow, sounds like so much fun!

For those who were already thinking of changing jobs, the post was a useful reference point. allargand [12] writes:

グローバル企業への転職を検討しているところだったので、非常に参考になりました。

I was just looking into switching jobs to work at a global corporation, so this was extremely useful.

And kingyodojo [13], perhaps hinting at a trend:

読んだら今の仕事を続けていていいのか疑問を持った。

Now that I've read this, I wonder if I should keep working at my current job.

For more on Asai's perspective on Japan's IT industry, see also a comment he posted [14] on the first article in this series.