No Job Descriptions in Japanese Game Developers

In general, Japanese companies don’t define job descriptions clearly. This often makes a mismatch surrounding new graduates and lets them quit their companies. For example, a new graduate, whose major is software engineering, especially GPU computing, had gotten a job in a famous IT company in Japan. But, his responsibility was to maintain a main frame written in COBOL. He could not put up with such a job and quit his company. If his company explained the job description at the interview, he didn’t join the company. You can read many stories like this in Japanese blog, Twitter and so on.

Many Japanese companies show unclear job description like the following;


  • Strong passion.
  • A positive attitude.


  • Take responsibility for everything.
  • Work as a member of us.
  • Curve out the future.

In fact, Japanese game developers are the same. I’ve talked about this with the top executives of some companies. Their thought is the next.

“If the company defines the job descriptions clearly, it makes the employees lack flexibility. They do only what is written in the description. Defining nothing makes the employees flexible. A game development is complex and sometimes in difficult troubles, but if we keep the employee flexible, they volunteer to solve the trouble.”

“Defining nothing make employees flexible”… It doesn’t make a sense for me, but I’ve heard the phrase from over 10 people. Perhaps it is Japanese common understanding and old Japanese virtue. However, I can’t believe the virtue is still alive. I’m sure defining nothing makes some employees irresponsible. I know there are some flexible employees, but they work instead of irresponsible employees. For example;

  • Requirements for game designers aren’t defined, so many designers can’t write script code and operate level design tools. Some of them think their specialty is speaking ideas and criticize other ideas. Well, does who write game script code and operate level design tools? It’s an engineer or a 3D artist!
  • UI/UX designer is not defined in many companies. This causes the same problem as above. Today, UI/UX is designed on tools like Flash. Some designers can use the tools to implement their UI/UX ideas, but others can’t. To make up for this shortage, some engineers have to act as Flash operator. Some 2D artists really don’t think operating the tools to design is not their responsibility.
  • In the above example, you can replace any words with other jobs’. (e.g. Animator is not defined, so engineers have to create Animation State Machine data and maintain it…)
  • Some companies don’t define which job should manage the development process. So nobody learn about it and nobody do that. Some people (e.g. engineers) volunteer a process manager with working overtime, or an amateur manages a process and compel overwork. But, their salary won’t be raised. I said the companies don’t define a process manager. It means that the companies don’t define its worth.
  • Engineer is one of unclear job. Japanese developers tend to mix an engineer with a game scripter. Almost all of them don’t define what a game scripter is. Therefore, the developers hire an engineer who passed a technical interview and C++ exam, to request them to write game script code like Lua, C# and JavaScript to support their game designers.

It’s chaos… I think there are two big problems.

One of them is low productivity. The development style like the above is not acceptable to rapid iterative development. In the style, the relationship of plural employees are required in an iteration. It’s really slow and a cause of working overtime. If an employee acquires the appropriate skills and knowledge, he/she can go over an iteration himself/herself, but he/she isn’t motivated and don’t know what skill he/she should learn.

It’s second problem: No information about a job means no motivation and no direction to acquire new skills. Whether a employee learn something depends on his/her personal motivation.

For example, let me say that you thought a procedural technology was very important. You had paid for Houdini yourself, had been learning for a long time in your private time and finally acquired it. I think you’re an amazing developer, but officially just a hobbyist who likes Houdini. The company might not applaud you and raise your salary.

In another case, a 2D/UI artist started to learn Maya. She thought she should have had to acquire something new skill, but Maya was not appropriate. Because the company needed more UX designers. If she wanted to learn 3D, it was no problem, but she didn’t. However, there was no direction. So anybody can’t recommend that she started something else.

I wrote about unclear job descriptions in Japanese game developers. I think it’s a fatal problem. Some people think that a life time employment system in Japan makes them write unclear job descriptions. But, I don’t think so. It’s just corner-cutting. The developers can add more details to job descriptions. It isn’t difficult, I believe.

This entry was posted in Game development, Japan. Bookmark the permalink.

2 Responses to No Job Descriptions in Japanese Game Developers

  1. DhyvD says:

    It is a fatal problem, but it is also a side effect of the shift currently happening in video games, where by on the one hand, they are plenty of tools, but on the other hand, they are few environments which foster talent, as opposed to skill.

    Companies which want to produce games consistently should focus on both, with many skilled persons and a few talented “directors”, but they do not do this, since they are more accustomed to less complex working systems. There is a fatal lack of imagination and transparency, based on a lack of detailed awareness.

    In other words, they do not see it as fatal, because they see result being produced, and they just think that if it works, it must be okay… by the time that they do realize a problem, it will already be too late, but then, the opportunity is to build a different type of company, which has much more awareness of the details of the tools and thus the skills needed.

    As for talent, a “process manager” is a type of “director”, and I use the word director in analogy to both making a movie (a Hollywood Director) and being on the Board of Directors of a project (being able to hire people and influence the budget, or prevent the budget from being changed by being the sole overseer of responsibility for the duration of the project).

    In the past, flexibility was indeed a key skill, as there was no real competition and the work-flow as much simpler, but nowadays, even for a one man team, understanding process matters a lot to prevent drifting and make good use of time.

    Well, I fully agree with you… and I think that makers of tools have some of the blame, because they sell tools but they do not follow up to help companies boast about how they are used. Also, I maybe it is worse when companies put specific requirements which are copied from elsewhere, but are not in line with what a company actually requires.

    For example, they may as for C++ skills, but you actually end up working with JAVA.

    They just copied “C++ skills” from another website, because the person from HR (human resources, hiring and advertising jobs) did not want to talk to the persons in development.

    In that case, it seems like everyone knows what they are doing, from the outside, but when you get inside, it is a big mess, so you may quit or you may just lose faith in the organization, “quit mentally” even if you continue to come to work. That seems to happen more in bigger American companies.

  2. Pingback: Leading to some improvement in Japanese developers | A Game Programer in Japan

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s