Profile (Work History)
ちびはむ
Web Application Developer
Basic Information
Where does the name Chibiham come from?
Saying 'Chibiham-chan' very fast sounds like 'Chiba-chan' (maybe?)
Date of Birth
August 20, 1993
Location
Yokohama, Kanagawa, Japan
Contact
Please reach out via the contact form.
Summary
After graduating from university in 2016, I joined a major system integrator and worked on web application development, gaining broad experience from PoC and requirements definition through maintenance and operations, across front-end, back-end, and infrastructure.
In 2021, I joined a web company and worked on developing and operating SaaS applications — integrating payment features, designing and building APIs, and building and operating infrastructure as a full-stack engineer.I became independent in 2023. Drawing on my experience in enterprise application development and BtoBtoC SaaS development, I now work as a freelance engineer.
I design and develop with a focus on maximizing application agility to improve user experience, and I keep learning every day to become a better engineer.
Strengths
My strongest domain is application architecture. Its core, however, is not encyclopedic knowledge of individual tech stacks — it is structuring complex situations, weighing trade-offs, and making the call. I can own the whole arc: framing the problem correctly, turning the structure into a design, breaking through when things get stuck, and leaving the decisions behind as shared knowledge.
Structuring Tangled Specs and Discussions
I untangle chaotic requirements and stalled discussions, and articulate them in a form everyone can agree on. This is where teams have relied on me the most. I continuously examine what a 'specification' even is, and publish my thinking.
- → Related articles: The Nature of 'Specification': Understanding Software through Requirements, Contract, and Implementation
- → Related articles: Skepticism on Specification-Driven Development
Architecture Design and Trade-off Decisions
When there is no single right answer, I make the options' costs and benefits explicit — based on requirements, team context, and operational constraints — and commit to a decision. This is grounded in my article series systematizing the evolution of AuthN/AuthZ architecture, and in hands-on experience integrating payments and designing SaaS APIs at a product company.
- → Related articles: Evolution of AuthN/AuthZ Architecture (1): From Monolith to Identity Provider
Breaking Through Hard Problems
I dig into mysterious failures and performance issues across layers, from front-end to infrastructure. My persistence shows not only in design, but especially in demystifying 'it doesn't work, it's slow, it makes no sense'.
Turning Knowledge into Systems
I capture design decisions and tacit knowledge as documents, ADRs, and knowledge bases to reduce a team's cognitive load. I treat 'having to align every time' as debt, and resolve it structurally.
- → Related articles: Cognitive Technical Debt: If Teams Keep 'Aligning Every Time,' That's Debt
How I Work Best
I deliver the most value in exploration, design, and turnaround phases. Rather than grinding through large volumes of routine implementation against a frozen spec, I thrive where 'what to build' and 'how to position it' are still ambiguous.
Main Tech Stack
TypeScript / React / Next.js / Nest.js / Ruby on Rails / Java (Spring Boot) / AWS / GCP / Terraform / Docker / PostgreSQL / MySQL / Redis
For detailed per-project experience, feel free to ask via the contact form.