Leading article
Keep the product's history present in the next technical decision
I first understood the importance of historical context while maintaining a program that still served users after its original specification had been superseded. The newer document was easier to find, but it did not explain the behaviour the existing users depended on. Replacing the implementation would have been simpler than reconstructing the decision. That would also have risked answering a different question without telling anyone. I began to see technical maintenance as the preservation of an intelligible relationship between a system and the work it was meant to support.
I completed a degree in information engineering at Takemori Institute in March 1994 and joined Hoshinari Systems the following month. I worked in an eight-person development team, with no direct reports or independent expenditure authority. My assignments included application maintenance, test preparation and tracing how a reported error moved between components. By March 2001 the company employed 310 people and reported JPY4.8 billion annual revenue. Those are employer figures. My early contribution was learning to make a problem reproducible and leave an account that another developer could use without depending on my memory.
I joined Nerumori Assurance as systems manager in April 2001, reporting to the head of insurance applications. By March 2008 I led twenty-eight employees through three direct reports and had JPY620 million annual authority. The insurer then employed 1,900 people across twenty-six offices, with JPY71 billion gross written premium for that financial year. Working on policy systems made time part of the engineering problem. A definition that correctly described a newly offered product could be the wrong reference for an earlier contract. I learnt to bring the responsible product owner into the discussion before a technical simplification became an operating assumption.
The head of product platforms appointment began in April 2008. By March 2015 I led sixty-four employees through four reports, with JPY2.1 billion annual authority, reporting to the engineering director. Nerumori had thirty-four offices and 2,700 employees, with JPY112 billion annual gross written premium. My remit concerned the foundations used by product and policy applications. I became more careful about separating a common technical service from a common business rule. Sharing infrastructure could be useful even when different products properly retained different definitions, histories or approval arrangements.
I became engineering director in April 2015 and reported to the CTO. By March 2020 I led 116 employees through five reports, with JPY5.2 billion annual authority. The insurer had forty-one offices, 3,500 employees and JPY153 billion gross written premium for the financial year. I worked across replacement programmes, existing platforms and the engineering capacity needed to serve both. This period changed how I presented investment choices. The cost of keeping an older engine responsible belonged beside the proposed benefits of its successor, rather than in a separate maintenance account that made the replacement appear cheaper than the transition actually was.
My CTO appointment followed in April 2020. I now report to Hiroto Senakawa, the CIO, and lead 155 employees through five direct reports, with thirty-eight contractors counted separately. My FY2026–27 JPY7.8 billion authority comprises JPY4.9 billion engineering platforms and JPY2.9 billion maintenance. Nerumori's March 2026 scale is forty-seven offices, 4,200 employees and 2.6 million in-force contracts. Its JPY184 billion gross written premium is company context, not a technology revenue account or a measure of the money I control.
Several recent choices show the boundaries I try to preserve. We corrected historical document references against an approved edition map, without claiming that engineering had determined legal coverage. We reduced the duration of a defined actuarial replay while making the additional compute charge explicit, without suggesting that processing speed improved the underlying assumptions. I recommended an eighteen-month bridge for an older product engine because an unfinished successor could not responsibly be treated as an available service. In each case the useful result included something the technology decision did not establish.
I also want a technical release to be described in its proper sequence. A platform can support a product configuration before the insurer has approved that product for use. A capacity exercise can show how an intake service behaves under a specified load without proving that claims will be assessed or settled at the same rate. These distinctions are practical. They identify the next accountable decision and prevent one team's evidence from becoming a wider claim that nobody has examined. I expect my own presentations to make those limits visible.
I have no director appointment. Board presentations in my executive role have given me experience of explaining engineering investment, but they do not confer the responsibilities of a director. I would consider twenty-two annual days for a first external role after employer approval and a relationship review. My preparation would extend beyond technology to the organisation's economics, customers, governance and obligations. I would bring experience of systems that must serve commitments made across many years, and the discipline to contribute through oversight rather than manage another executive team's work.