See all those languages up there? We translate Global Voices stories to make the world's citizen media available to everyone.

Learn more about Lingua Translation  »

Japan's IT Exodus: A Personal Perspective (Part 2)

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

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” [jp] (転職して感じたウォーターフォール文化とアジャイル文化の違いについて). For background on why Asai decided to quit his previous job, see Part 1 of this series.

Bookshelf photo by Flickr user Roo Reynolds

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.


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 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.


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:


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.


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:


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.)


In bookmark comments, responses to the post were positive:



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



Wow, sounds like so much fun!

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


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

And kingyodojo, 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 on the first article in this series.


Join the conversation

Authors, please log in »


  • All comments are reviewed by a moderator. Do not submit your comment more than once or it may be identified as spam.
  • Please treat others with respect. Comments containing hate speech, obscenity, and personal attacks will not be approved.

Receive great stories from around the world directly in your inbox.

Sign up to receive the best of Global Voices
Email Frequency

No thanks, show me the site