I've coded 100,000 pages in 10 years, but... The role of a coder can't be measured in numbers.

This happened before I joined the company, so I don't know the details, but I believe that Coding Factory (hereafter referred to as CF) has been counting the number of pages and projects it has produced since it first started its service, and publishing them on CF News and its website. But why did you start publishing the number of pages and projects in the first place?

One of the reasons is that CF often works behind the scenes, so we couldn't publicly announce the projects we were involved in, saying "We did this site!" But we want to give our customers a sense of security. When we thought about it, we thought that it would be a good idea to publish the number of pages and the number of projects as a quantitative indicator, and that was the initial trigger.

In fact, as we continued to count the numbers, the increasing number of pages and cases became important numbers that represented the achievements of our work. Looking at the CF website, we saw that it reached 10,000 pages in May 2009, and there was a lot of cheering in the department at that time, and we all had a party to celebrate the journey of 1 year and 6 months since the launch of CF. However, even though we reached a new milestone of 100,000 pages last month, we still don't feel that excited...

CMS was originally a service offered by CF, but coding was still the main focus. In recent years, however, we have begun to handle upstream consultations that go beyond the framework of CMS and JS implementation that accompanies coding. As we have been able to build relationships with customers and expand the scope of our involvement, our unit prices have also increased. As a result, we have become able to do sales that involves repeat customers understanding each other's situations and complementing each other's shortcomings.

We do well with clients who are willing to work with us on each and every project. Clients who are not simply outsourced and think, "We're the ones who are asking you to do the work," tend to be repeat customers.

As a production team, I think it's best to create something while consulting with each other. In the past, there was a submission set, and I think there was a situation where we couldn't do it unless the customer had all the data prepared properly in advance. However, the customer couldn't prepare the submission set properly before coding, and the site was in a flurry. At that time, there were many members who couldn't do it without the set, and the customer couldn't put it all out... I think there was a peak when it wasn't going well.

Things started to change when large-scale projects started to run in parallel. With large-scale projects, it's natural to communicate with the client about any omissions each time, so I think I felt that production became more stable in the process. From there, they grew to think, "It would be great if we could complete it within the deadline while communicating with the client." The peak of the difficult period was around 2013, and over the past three years, it feels like the method of producing while naturally communicating with the client has taken root. I think a big part of it is that the coders have come to understand that this works better.

Clients are also sensitive to the changes in web production, and in the past few years, a major selling point has been the way the coder in charge interacts directly with the client. By talking directly to an expert coder, the project can be carried out smoothly, and the quality improves as a result.

The quality of the site itself improves by being able to communicate with the coder about the overall coding specification design, responsive design, CMS construction, difficult JS, etc. Also, for projects with a large number of pages, even if the client cannot prepare all the instructions, the coder can ask questions and give them shape.

By listening closely to the honest feelings of our customers who outsource because they don't have time, we are now able to produce work of reasonable quality and meet the deadline, even in cases where the customer cannot prepare specifications, and we have been able to reduce the amount of work that would normally be required. I feel that more and more customers are finding value in communicating with such experts.

Even from the production side, it is becoming more and more difficult to create content on the web these days without direct communication.
For example, when you look at the design submitted by the client in a traditional waterfall development, you are left with questions like, "How does this work?" If there is a search box, you may have questions like, "What are the search specifications?" If you add a CMS, you may have questions like, "How many results should be displayed?", or, "What should open when you press a social media button?" There are many parts where the specifications can no longer be determined in detail at the design stage.

So, before the design, we are seeing an increase in agile development-like methods, where coders talk with customers, create mockups, have them try out the feel, and refine the specifications while making adjustments. We reach out to customers, listen to their stories as they waver between the countless correct answers, offer advice, sort out what can and can't be done, and propose a suitable compromise. As web development has become more complex, this is the natural way of interacting. There is also an aspect of customers changing, realizing, "So this is what I can ask for from a CF."

Certainly, until a few years ago, we were only given the technical aspects of coding for a project and delivered the product, but that relationship and distance has changed. I get the impression that we are more deeply involved in projects. Some of our clients are companies that are mainly directed by directors, so they cannot cover the technical aspects in-house. When a designer designs, they imagine, "I want to make it like this and make it move like this," but sometimes they don't know, "Can I actually code it? Can I do it?"

So, they say, "To realize this design, we need this movement. But I want to ask a coder if they can do that in the first place. But we don't have one in-house," or "We'll do the planning and design, but we want to leave the coding and front-end work to the professionals." More and more companies are doing this, and division of labor is becoming the norm.

Because we know the source code behind the scenes, we can present options such as "If you do this, it will be like this" or "If you do this, you can also do this" and let the customer decide. On the production side, in order to create something to a certain extent within a limited budget and construction period, we would like to extend several options to the customer to see what they want and then just let them choose. To that end, we would like to get closer to the customer, create together with them, and offer advice.

In reality, even if we wait for the specifications to arrive, they may never arrive, or even if they arrive, they may be uncertain or not finalized. In that case, even if we keep the schedule down, things won't go as planned. In order to stabilize the work of the coders, we have to step forward and show them the path to "this is it" and steadily finalize the specifications.

It's important to "suggest many ways to get the project to a conclusion," and I sometimes wonder if the number of pages we made is not that important. With limited time and resources, we communicate carefully with the client to find the right line and give it shape. I think clients want someone who values quality.

I think it's because people have realized that we can do it and that we are willing to do it, but the repeat rate for CF has increased sharply in the past two years. Until a while ago, there were overwhelmingly more new customers, but last year the number of repeat customers far exceeded the number of new customers.

This is because the number of customers who are willing to work with us on projects has increased. I think this is a sign that we are becoming more deeply involved in projects and our relationship has changed from that of an "outsourced company" to that of a "partner."

I get the impression that clients are more grateful for projects that have had ups and downs but are finally delivered and released, rather than projects that went well. Clients are anxious during the production period, but they are grateful when the project is over. It's like they're looking forward to working with the people who overcame the crisis together again. I think something is born from that.

I've already realized this in a few projects, but I want to work in a way that allows us to become partners while we're creating something. Rather than a relationship where we just know the name of the person in charge at the ordering company, as we hold repeated meetings, we can develop a relationship where the customer becomes familiar with the members of CF and calls them by their nicknames.

I say we have a "sense of comradeship," but the sense of trust is born from maintaining a certain level of quality and meeting deadlines in tough projects. I would like to use that as a foundation to build a relationship that allows us to get involved more broadly and deeply.

Just as the area required for CF has changed from coding to front-end, I would like to be able to interact with customers as a company called Monosus while focusing on CF. Monosus has many teams, not just coding, but also design, operations, etc. That's what I imagined "I want to be like this!" ever since I became a salesperson. I feel like that's coming true now.

Up until now, most of the work was done by CF alone, but I think we are now in the process of establishing a system where we can work with other departments, such as those who can handle upstream tasks like defining requirements and writing wires, and the design team, to complete projects as "Monosus." I hope that we will see more and more work like this, and I also think it would be good for CF to function as a liaison office for this.

Just as the area has shifted from coding to the front-end, I feel that the Cloud CF department has also become a company that can cooperate with other departments and interact with customers as a company called Monosus.

Right now, we are working on a production system that combines agile development and waterfall methods, where we decide on specifications together with the customer and work on the UI together. This is a first for CF, and I'm really looking forward to seeing how it develops in the future.

If we get more projects like this, I'm sure work will become even more enjoyable, so I'm excited to see future changes at CF and Monosas.