Developers Summit 2016 "What is a software development environment that improves productivity and quality that supports team development?"

Mr. Takeshi Kaneshiro, Core Technology Solution Business Unit, NTT Advanced Technology Corporation (NTT-AT), gave a lecture titled "How did SIers adopt GitHub Enterprise?"

Mr. Kinjo seems to be working on improving the company's development culture in addition to his main job. This time, we did not talk about the effects of implementing GitHub Enterprise, but rather about the path to implementation, which will be helpful to companies that are yet to implement GitHub Enterprise. NTT-AT is currently implementing GitHub Enterprise in some areas, and full-scale implementation is still in the future, but the most important point when implementing it is "Enthusiasm is important!" It's not about logic, it's about enthusiasm! That's what I was told.
What has happened in the past year is that GitHub Japan was established and Macnica networks became the sole distributor in Japan, and as a result, support in Japanese is now available. They also mentioned that being compliant with Japanese business customs was very important. This means that up until now, only dollar-denominated payments could be made with credit cards, but now it is now possible to pay in Japanese yen, and it is now also possible to pay by invoice.

Within NTT-AT, Mr. Kaneshiro has been saying "GitHub is good" for more than 5 years, and as a result of Mr. Kaneshiro coincidentally attending a meeting attended by Macnica networks employees, where he spoke more passionately about the benefits of GitHub Enterprise to the company's system staff than the Macnica networks employees, the company began considering implementing As a result, the company decided to begin considering the implementation of GitHub Enterprise.

When I started considering it, I was asked to explain the cost-effectiveness. This is a question that is asked uniformly in many companies, but it seems that he felt it was a difficult problem. Since the transition to development on GitHub Enterprise is equivalent to a paradigm shift, I thought that the effects of inexperienced people cannot be accurately derived from existing experiences. It is also difficult to predict and quantify collaboration and innovation among developers in advance. From the standpoint of developers who use GitHub Enterprise, it is possible to have the expectation that ``this kind of good thing will happen'' when using GitHub Enterprise in business, but from the side that decides to introduce it (the side that has decision-making authority), usually Since they are not involved in development, they may have never heard of the pull request feature invented by GitHub, or they may not know git in the first place. The most important thing that Mr. Kinjo conveyed during his explanation was the enthusiasm of the engineers who will actually use the system after installation.

There were three walls that stood in the way of introduction. The first was that the company-wide internal system was linked mainly with SVN (Subversion), so it was difficult to migrate to git. The second is to get people to understand GitHub. The third is to proceed with the introduction of GitHub Enterprise, the on-premises version of GitHub. We broke through these barriers one by one with our in-house collaborators. Here is an excerpt of what Mr. Kinjo talked about git, GitHub, and GitHub Enterprise at the internal meeting.

In addition, he summarized the positive impact that GitHub Enterprise will have on the company in three ways.

The first is the transformation of the development process. Even if agile development and spiral development are popular, it is difficult to get out of waterfall development for a long time. By introducing GitHub Enterprise, it becomes easier to support any development style. In addition, it will be an environment where the development process can be changed sequentially from the project that can be changed. The second is reforming the company culture. Waterfall development with cooperating companies may lead to code becoming a black Box. Since it is not possible to determine for what reason the code has accumulated, we cannot repair or improve it ourselves, and we end up asking our partner companies again. In that case, there will be a problem that engineers cannot be nurtured in-house. For that reason, I hope that in the future we will not leave things up to subcontractors, but rather create a culture in which we take responsibility for our own code. The third is a paradigm shift. We believe that the introduction of GitHub Enterprise is not about improving the efficiency of the current development style, but changing the current culture and development style itself is one of the effects.

Lastly, I would like to give some advice to those who are in charge of development and those who are in a position to decide on the introduction. What I would like to say to developers is that it is natural that they do not understand before introducing GitHub Enterprise because their roles within the company are different. In the first place, it's almost the same as cross-cultural communication, so instead of complaining that you don't understand how to appeal, try talking about how you can introduce GitHub Enterprise through trial and error. What I would like to talk to people who decide to introduce is to ask employees who are familiar with technology in the company, "What is GitHub?" I want you I'm sure you'll open your eyes and talk to me. Even at NTT-AT, there are several people who touched GitHub Enterprise for the first time in the company, but within half a year they are in a state of "I can't go back" or "I don't want to go back". GitHub is already widespread, not at the stage of being popular among developers. However, he concluded his lecture by stating that he still had the impression that managers and others in the position of deciding to introduce it had not yet understood it.