Meeting Loglass. Hiroki Chida's Workplace: In the AI Era, Speed is Life. The Realistic Solution for Development Processes Tackled by a Small, Elite Team
"Meeting Loglass. My Workplace" is a series designed to help you understand "what kind of work this person does and what their mindset is" before you engage in casual interviews or the selection process.
By learning about the philosophy of the work, expectations for the role, and the difficulty of daily decision-making—things that aren't visible on a job description—we aim for interviews to become "a place for mutual understanding" rather than "a place for assessment.""a place for mutual understanding"
This time, we spoke with Hiroki Chida, who leads product development at Loglass.
In product development during the AI era, it is important not only to take time to carefully create good things, but also to determine how quickly you can set hypotheses, move, learn, and rebuild within changing premises.
On the other hand, it is not enough to just be fast. To achieve high results with a small number of people, the team's decision-making, development processes, use of AI agents, and the design of "how much to standardize and where to leave it to the team" are all called into question.
What Chida is facing is precisely that realistic solution.
In this article, we will ask about the product development process in the AI era, which is actually being tested and refined at the Loglass development site.
Hiroki Chida, Product Development Lead / Loglass AI IR
10 years of engineering experience. Currently serving as the Product Development Lead for "Loglass AI IR." As a playing manager who also writes code himself, he leads the entire product development of the new AI-driven business with a small, elite team of 7 people (5 engineers, 1 PdM, 1 designer).
Moving at explosive speed with minimal rules—What I am doing now as a Product Development Lead
── What role do you currently play within the team?
Chida:I am the Product Development Lead for a new business called "Loglass AI IR." However, even though I am a lead, I don't just sit firmly in a management seat; I am a playing manager who is also actively writing code.
The team is a very compact group of 7 people including myself (5 engineers, 1 PdM, 1 designer). This is because I feel firsthand that "with the advent of AI, speed is more critical than ever for new businesses."speed is more critical than ever for new businessesThe speed of change in the world is tremendous, and if you make a team too large in a new business, communication costs skyrocket, which can be fatal. That is why we do not force an increase in resources and try to operate with the minimum number of people.
Furthermore, we have also introduced in an interview with Morikawa, the head of the new business, what kind of market issues Loglass AI IR is facing and how it is trying to define a "market without correct answers." If you want to know the business-side philosophy behind the development process, please take a look at that as well.
── Is your organization one that also strictly limits rules and processes?
Chida:That's right. To maximize speed, our concept is to keep rules to a minimum. There are naturally disadvantages, such as onboarding new members becoming slightly more difficult or decision-making criteria becoming easier to waver, but the advantages of "everyone being able to grasp the big picture," "fast decision-making," and "increased ownership" are absolutely required in this day and age.
In this overwhelming sense of speed, I aim for a team where everyone acts autonomously as a player while directly connecting technology and business.
Overall Agile x Local Waterfall. A development process that masters uncertainty
── In the AI era, what kind of development process have you set up to ensure that "speed, which is life"?
Chida:We are challenging ourselves with a hybrid style that fuses the essence of both methods: "The whole is Agile, and each development unit (epic) moves in a Waterfall-like manner."
In the project management triangle, the three elements of "delivery date, resources, and scope" are in a trade-off relationship. I think there are many cases where you choose based on either a Waterfall-like way of thinking that fixes the scope, or an Agile-like way of thinking that fixes the delivery date and resources.
For the entire roadmap, we fix the delivery date and resources, and by dropping development units that don't fit while looking at priorities, we proceed in an Agile, flexible, and fastest way.
On the other hand, within individual development units that have been cut out, that is, within an epic, we try a Waterfall-like approach where we fix the scope to some extent and concentrate the necessary resources to get it done.
── Why does such a Waterfall-like approach become possible at the epic level?
Chida:The big reason is thatby incorporating AI into development, the possibility of delivering value precisely toward the set delivery date has increased dramaticallybecause of that.
There are two types of uncertainty in product development: "What to make" and "How to make it." Currently, with the support of AI, the speed of specification organization and implementation has increased overwhelmingly, making it possible to control the uncertainty of How to a significant degree.
However, no matter how much AI evolves, if the target scope remains huge, it will only waver even if fixed, and you won't be able to land on the target delivery date. That is why we follow a process of thoroughly questioning whether it is in its truly minimal form in collaboration with PdMs and designers, and then stripping down and fixing the scope to the absolute limit.
Because the 'minimal scope that has been stripped down and fixed to the limit' is combined with 'acceleration of implementation by AI,' the difficulty of meeting delivery dates is lowered, and it has become possible to make highly certain commitments at the epic level to 'deliver on time without wavering.'
Of course, in the engineering field, hearing the word 'delivery date' can be off-putting, but this is not something forced upon us from above by someone else; it is something the developers themselves decide with conviction, saying, 'With this, we can land on the timeline'.
Product development is a long-distance run, not a sprint, so having members in a state of exhaustion is absolutely unacceptable. It is important whether there is a solid sense of accomplishment when finished. As an approach to ensuring certainty without killing speed through appropriate scope control, I feel a solid response that this way of finding a balance is 'working very well so far' in our team, despite some recent ups and downs.
Differentiating between workflows and agents. How to incorporate AI into products
── It seems you have invested a considerable amount of time recently in concretizing the implementation image of 'how AI can be incorporated into actual products,' Mr. Chida.
Chida:That is correct. Rather than mere idealism, I was thoroughly organizing the design philosophy for incorporating it into products that can be used in actual work. The core that became visible there is how to separate and combine the 'non-deterministic (agent)' areas and 'deterministic (workflow)' areas in a product.
In the field of AI development, everything tends to be lumped together as an 'agent,' but to ensure reliability as a product, it is necessary to use that gradation selectively.
A system that moves according to a predefined code path is a 'workflow (deterministic),' which is suitable for routine tasks because of its high predictability and consistency. On the other hand, a system where the LLM itself dynamically decides which tool to use next is an 'agent (non-deterministic),' which can flexibly solve complex exploratory problems.
── How do you think those two should coexist within a product?
Chida:A form of complete automation where everything is left to AI is not realistic at this point. While boldly utilizing the 'non-deterministic' exploration process, which is AI's strength, within the product, we must be extremely careful when incorporating the control of 'deterministic' parts where the system should guarantee that '1+1 will absolutely be 2.'
Routine tasks that require predictability are solidified with 'defensive' workflows, and we borrow the power of 'offensive' agents for exploratory tasks that require flexible judgment. I believe that this design philosophy of selectively using this gradation (agentic workflow) is what creates product reliability.
And to determine at what granularity to extract this boundary line and incorporate it into the product, a deep understanding of 'customer business (domain knowledge)' is indispensable above all else. I am convinced that the more technology advances, the more this domain knowledge will become the greatest differentiator for engineers and PdMs.
Not being bound by stereotypes. The transformation of roles required of SWEs and PdMs in the AI era
── How will this change in technical incorporation philosophy affect the roles of engineers and PdMs in the field?
Chida:In the future, the part of an engineer's job that involves 'implementing specifications (=coding)' will become much thinner, and the part of organizing specifications and providing them as prompts will become more important.
When that happens, I think the boundaries between job titles such as engineers, PdMs, and designers will blend more flexibly. Engineers will utilize the leeway created by the automation of implementation to spill over into higher-level roles such as product requirement definition, technical requirements, and project promotion. PdMs and designers will also need to step into more technical areas, such as how to control the non-deterministic behavior of AI and incorporate it into products.
It is a part where I want to flexibly change roles according to the times and the phase of the organization without being bound by stereotypes.
In casual interviews, I want to discuss 'questions without correct answers' on a flat basis
── What would you like to talk about in casual interviews, Mr. Chida?
Chida:Rather than checking skills or backgrounds, I want this to be a 'place for mutual understanding' where we can align our philosophies on craftsmanship. It would be fantastic if we could exchange opinions flatly on themes like the ones we discussed today.
How to achieve a development process that maximizes both hit rate and 'speed' in the AI era
How to define the gradient between workflows (deterministic) and agents (non-deterministic) in AI products
In an era where technology is evolving, how should engineers and PdMs catch up on domain knowledge (IR practice)?
I will share exactly where we are now—not just the pretty parts, but the reality of our trial and error while writing code—so I would love for us to clash ideas and insights on how 'you would do it.'
── Finally, what kind of people do you want to work with?
Chida:People who aren't bound by rules or precedents and who enjoy change. We don't view the 'goals' we set for the team as rigid tools just for evaluation, but as 'communication tools for bold challenges.' As long as it is a sufficiently bold stretch goal and a path that leads to business growth, we believe we can flexibly decide the specific goals and approaches ourselves.
For engineers, someone who can think about how their technical choices connect to business growth. For PdMs and designers, someone who can design how to proactively deliver value to a user's workflow in an AI-driven product. I would be happy to create a new form of product development for the AI era together with people who can act autonomously in a small, elite team while enjoying the waves of uncertainty.
Editor's Note
What flowed consistently through Chida-san's talk was a strong sense of urgency that 'speed is life in the AI era,' combined with the excitement of enjoying that challenge.
The small, elite team structure run with minimal rules, and the hybrid development process that strips scope to the absolute limit while leveraging the benefits of AI to hit deadlines—everything is a necessary choice to maximize that speed and certainty.
At the root of the logic for determining how to incorporate AI into products without being trapped by stereotypes was a strong respect for craftsmanship, specifically 'deeply knowing the customer's domain knowledge.'
If you want to go beyond the boundaries of engineers or PdMs and take on the challenge of high-speed craftsmanship at the forefront of the rapidly changing AI era, please go take a look at Chida-san's workplace!
