Solving people's problems: Our goals as engineers and business owners — A conversation with our new technical advisor, Part 2
* This article will be the second part of a technical advisory interview. If you haven't read the first part yet, please read it from here. 。
Today's guest: OTA System Development Co., Ltd.
Mr. Naohiro Ota, Representative Director and Engineer
Born in Sendai in 1969. After graduating from university, he joined a US telecommunications company and helped launch Japan’s first commercial internet service as a programmer.
In 1998, he became independent and worked mainly on the development of web applications.Incorporated in 2017, he established OTA System Development Co. , Ltd. His hobby is family camping.
Developing apps is half, communication is the other half.
Takasaki (representative)
Mr. Ota has written “Art & Technology” on his business card, and she is very particular about the art part as well as technology.
mr. ota
That's right. (Simultaneously) in me, there is not much of a boundary between the art part and technology part; I have an image that makes it as one.
I think that's exactly what web applications are.
Yes, it's not just a matter of understanding computers.
I think there is definitely a point of view that it’s easy to use and whether the feature will really solve your problem.
However, I don’t think that it is a good idea to make the specifications according to the specification, but something like this...I think Ota has always valued engineering while looking at each customer for 20 years.
Well... if anything, I'm aiming for a position like my doctor.
For example, if you're a doctor, instead of just prescribing your headache medication when the patient says "it hurts," you have to think naturally about what kind of prescription it takes after knowing your own long career and worrying. You need to look for one of the symptoms that is caused by them.
I think it’s the same for building systems.
I think that if we can design a system with deep knowledge of the troubles, circumstances and things that our customers have -- hopefully it'll bother us.
Building a web application is about half as much work with computers, while the other half focuses on people's work and communication.
The technical part is our area of expertise, but we’re definitely more familiar with what you do with the web app.
I’ve always been thinking about how to communicate in the context of asymmetry between expertise.
Now, on our company’s site, we have a word on the logo that says “to make together.
We want to be useful in technology as an IT expert, and if we don’t properly learn about the practical aspects of our customers’ specialties or their problems, we can’t connect them well with work with computers.
So I think it's best for us to provide technical expertise and give our customers practical expertise, so that we can make them together. It's not a way of doing things where when orders and requirements are finished there is little communication between each other.
There are many problems with system development because of communication, but I still hope that we can design a development flow for such web applications so that customers will enjoy making them together.
- Supplement: About our web application development flow
We use lean and agile methods to develop web applications on a per-month basis.
This method is characterized by the rapid repetition of small-scale development and improvement of apps while continuing to communicate with customers who are orderers.
In addition, it is easy to reflect user feedback and has the advantage of reducing the risk or development cost of pouring budgets and man-hours into features that are not required by users.the specific flow of this company service guide page or... Our web application development process Please refer to the page.
But for those of you who are the first to order an information system or a web app like this, I think it’s going to be quite difficult.
We would like to explain it without using technical terminology as much as possible, but there are things that we can't proceed with without using this word.
It's hard to see where there is no common vocabulary.
It's the same thing that you want to communicate well with each other and customers.
As an engineer and a manager, we are talking about the future.
The difficulty of communicating due to differences in expertise came up, but the AI projects I’m working on also have a distance between technology and practice.
Even if it is technically possible, it does not make sense for the customer and feels that it is not directly connected to value cannot be practiced in the case.
I’m working on an AI-powered app that can tell you what it’s possible to do across the valley, and I want to take it to a business level.
Oh, that English conversation app. Not only the AI part but also UI and illustrations by Mr. Ota. Because he is good at painting...
(As for the app Ota is currently working on, I'm going to introduce you in the first article. Here it is. ）
I thought it was also when I consulted, but Mr. Ota often uses illustrations in his explanation.
From Ota’s technical article “How to use Express.js”[1], Illustration of the flow from app startup to routing”.
Originally, there was a place where I deepened my understanding by dropping it into the illustration.
From now on, I would like to organize what I have experienced and know-how so that it can be systematically outputted and provide them with text or illustrations.
I've been a little insecure and unable to step.
Mr. Ota's technical articles are good at painting, and his breath of words is soft, so there’s an element of fluffy healing.
it was released the other day How Deep Learning Works Even in Elementary School And so on.
I'm worried that if you write too softly, you can say it, but I want to convey it firmly in my own words.
There is a story called "Yamatsukiki" that if I hadn't announced it in order not to hurt my self-esteem, I would have become a tiger.
That's great.
In the future, in our case we would like to work hard to create a communication system and improve technical capabilities that I talked about earlier.
With the help of Mr. Ota, I would like to hold a study group and release it as much as possible outside the company.
We also want to incorporate code reviews in our development of our own services.
Until now, it was speed-first, but even with a bit less tempo, it is better to review if the logic of that code is broken or instructed and written correctly when viewed objectively by third parties.
As our engineering life continues for decades to come, I think it would be a fortune if we could teach Mr. Ota how to write again with proper systemic knowledge.
Yes. I used to be taught a lot by my seniors through code reviews.
When I joined the company, it is the basis of my current professional life.
I hope that you can reorganize and convey what I have learned so far, from various people.
When you let him read the code that he wrote, I feel like abstraction is good.
The rest is... it's kind. It's a very easy code to read even for the first time.
Anyway, if you just move and think about it, that code won't be born.
I think that not only people who actually use the system, but also engineers involved in operation have been working hard on imagination and ingenuity.
I think that it is possible only by having the basics of knowledge and technology which was a system.
That's right. Any program will change its specifications someday in the years and months.
It’s hard to read these uncertainties in advance, but when a program is affected by various events and changes slightly... For example, the stones flowing down the river gradually become horny and rounded, but if it was a round rock from the beginning, then it wouldn’t be very affected.
I make it with an image close to that.
If you design a module, each part of the program in an abstract way as much as possible from the beginning, it can withstand future specification changes.
The process of abstraction is very difficult, and there's no answer.
- Column: Programming and Abstraction
What Mr. Ota is talking about is a technique called object-oriented programming.
It is a programming method that is easy to respond flexibly to changes, and abstractions are an important factor.To explain it in a story ... It may be easy to understand if you imagine an automobile factory that manufactures various cars.
Each part of all car types is different little by little, but there are many things in common.
Imagine how a light car A’s handle, an open vehicle steering wheel, a truck steering wheel, a light automobile B’s handle and a wagon steering wheel are all managed, designed, procured and manufactured individually without any cooperation.Here, let's also assume that the material was almost common.
If a specification change is included in one of those materials, the handle department of all vehicles will be subject to change, and there may also be leaks.
However, if "what is common to the steering wheel of each car type" was united in one department, it would only be necessary for that department to respond to changes.
It's a lot smarter here, and I think it will be flexible if another change happens.In this way, extracting and handling something common to each process is called an abstraction of programming.
Programming is a computer instruction manual, but it also includes something like philosophy.
It’s probably more about organizations, with some organizations making it hard for people to move and others making it easier.
In the same way, I think we can either make programming a design that only works with one thing or have flexible design.
instead
I read it in some book, but learning is the most efficient way to learn in a group. It can be a study group or team collaboration.
Originally, the way we do our work is closer to how each individual with expertise complements one another than that of technically outstanding people leading everything.
So from now on, as a team we hope to collaborate with each other and create one thing.
Thank you very much, Mr. Ota.
Thank you from now on!