Why did Konica Minolta promote in-house agile SaaS development? What is the role of test automation in supporting this challenge?
Konica Minolta, Inc.
MagicPod CEO Ito spoke with Konica Minolta, Inc. to learn about the key reasons behind their choice of MagicPod and how they've utilized it since its introduction.
Konica Minolta, Inc.
Driven by a management philosophy of "The Creation of New Value," Konica Minolta's core operations span the Digital Workplace, Professional Print, Industry, and Imaging Solutions businesses. For 150 years, the company has honed its imaging technologies centered on light and color. Building on this legacy, Konica Minolta is now expanding its growth in the "Measurement, Inspection, and Diagnosis" domain, leveraging its strengths in image IoT. As part of its new business development and DX initiatives, the company offers "COCOMITE," an online manual service.
KEY POINTS
- Transitioning to agile development brought challenges: an increased testing workload and the need for shorter release cycles.
- MagicPod was chosen for its low cost and user-friendly interface, empowering QA personnel to manage it independently.
- They successfully automated 62% of their regression tests, integrating with CI for regular execution in the development environment.
- This led to a reduction in testing hours (from 11 to 6) and assured quality. The resulting trust in QA also enhanced the development team's psychological safety.
- Since implementing MagicPod, COCOMITE has maintained an annual uptime of 99.99%, ensuring a consistently high level of quality.
- For large enterprises bringing SaaS development in-house, test automation is proving instrumental in boosting efficiency and maintaining team capabilities.
From left:
• Nozomi Ito, MagicPod CEO
• Yasufumi Naito, Customer Success Manager for COCOMITE, Konica Minolta
• Tomoo Yamanaka, Development Manager for COCOMITE, Konica Minolta
• Hiroshi Kimura, Test Lead for COCOMITE, Shin Nihon Systemic
• Yusei Sugawara, Service Quality Assurance Lead for COCOMITE, Konica Minolta
Mr. Yamanaka (hereafter, Yamanaka): I'm responsible for the development of COCOMITE. My role involves product planning, setting the direction for the development team, and generally overseeing the entire development process. I'm involved from the very initial planning stages right through to the quality checks at release.
Mr. Naito (hereafter, Naito): When MagicPod was first introduced, I was the Scrum Master, focused on making our development and testing processes more efficient and optimized. Now, as a Customer Success Manager, I'm dedicated to helping our clients get the most out of COCOMITE and achieve real results in their operations. This includes everything from identifying their challenges to providing support for solutions.
Mr. Kimura (hereafter, Kimura): As the Test Lead, I oversee the entire design of our QA and testing efforts. As we've adopted Agile Scrum for development, I've been involved in the whole journey with MagicPod, from initial consideration and implementation to its current operation and the broader push for test automation.
Mr. Sugawara (hereafter, Sugawara): I'm part of the quality assurance department. As the dedicated lead for COCOMITE, I oversee the product's entire quality assurance process, which includes testing performed using MagicPod.
Ito: Could you tell me a bit about COCOMITE? What kind of service is it?
Yamanaka: COCOMITE is an online manual service we launched in February 2020. Its main advantage is that it’s an all-in-one solution for creating, sharing, and managing manuals. It allows anyone to easily create procedural guides and ensure their team always has access to the latest information. We expect this to help reduce inconsistencies in work and minimize tasks that only certain individuals can perform. I'm pleased to say it's grown to tens of thousands of users, with over 200 companies using it to date. For instance, FamilyMart uses COCOMITE in all of its stores.
Ito: Was COCOMITE started as something like an internal company venture?
Yamanaka: Yes, I think that's a fair description. It was born out of our "Business Innovation Center," an internal department tasked with creating new businesses, and then commercialized from there.
Ito: Konica Minolta is primarily known for its copiers. What led you to venture into a SaaS business like COCOMITE?
Yamanaka: Our copier business has traditionally been a "recurring revenue" model, generating ongoing income from things like toner sales after the initial hardware purchase. However, with digitalization leading to a decline in paper output, we needed to cultivate new recurring revenue streams. COCOMITE was created to be one such new pillar.
Naito: Mr. Yamanaka and I both originally came from copier hardware development. In that field, the market and customer needs are generally well-defined, so development proceeds based on established requirements. In contrast, new SaaS services like COCOMITE involve a lot of "zero-to-one" creation. It demands speed and the ability to directly address customer issues by listening to their candid feedback. Our business division's slogan, "Blazing Speed," reflects this intense focus on the rapid delivery of customer value.
Yamanaka: Engaging directly with customers and refining the product based on their feedback—this close interaction and the pace of development are starkly different from our experiences developing copiers.
The Journey to Implementing MagicPod
Yamanaka: Our development team currently has five members, and we follow agile methodologies. After COCOMITE's initial release, we actually used a waterfall model for about six months. Later, various factors, including a change in vendors, led us to shift our strategy. We decided, "Let's go with Scrum," and around January 2021, we transitioned to an Agile Scrum framework.
With this shift, we aimed to shorten our release cycles. Initially, we were releasing once a month, but we found that this was too slow to respond to customer requests effectively, and the time to deliver value was too long. So, starting around 2022, we began to progressively shorten the cycle, eventually settling on a three-week rhythm: two weeks for development and one week for testing.
While we succeeded in shortening the release cycle, the workload for regression testing ballooned as we added more features. Furthermore, the handover process to the quality assurance department after development was extending our lead times, making it a real challenge to balance speed with quality assurance.
Naito: Back then, the primary challenge wasn't so much dealing with specific defects, but rather the sheer volume of testing workload. This issue really came to a head around August 2023, when we went through our second vendor change. That was when serious discussions began about needing to reduce this workload or face significant problems. This period gave us a chance to review our entire process, including our development structure and team members' workloads, and it spurred us to start seriously considering test automation.
Why We Chose MagicPod
Yamanaka: Actually, we had looked into test automation once before. We tried a tool recommended by our vendor at the time, but the cost was prohibitive, so we decided against it.
Ito: So, for all of you, was MagicPod your first real hands-on experience with a test automation tool?
Naito: That's right. For all four of us, MagicPod is the first tool we've used extensively. When we were evaluating options, MagicPod, the tool we'd tried previously, Selenium, and Playwright were all on our list.
We had two main priorities. The first was "cost." We weren't just looking at the upfront cost of the tool, but its overall return on investment. We considered hiring more people to handle the testing load, but we figured if we could automate at roughly half the personnel cost, that would be the better approach.
Our second priority was to find a tool that our QA and testing personnel could use to design and run tests independently, without needing constant support from the development team. At that stage, COCOMITE was focused on adding new features, and we couldn't afford to slow down development by pulling developers into automation support. We wanted a system where the testing team could be self-sufficient, so we looked for a tool with an intuitive UI that didn't require specialized programming knowledge.
Consequently, we first ruled out tools that required coding and then compared no-code options based on cost. MagicPod emerged as the best fit for our needs and how we planned to use it.
Ito: That's great to hear! What was your actual experience like using it?
Kimura: It was incredibly easy to create tests using its no-code interface. I found I could intuitively grasp how it worked with just a little experimentation – it just clicked. That made it extremely user-friendly. However, our tests involve a wide variety of scenarios, so we were initially concerned about whether MagicPod could truly cover all of them. During the trial period, Mr. Sugawara and other team members at the time put it through its paces, and we came away feeling confident that "this will work for us." That’s when we decided to go ahead with it.
Naito: I remember you were very responsive to our questions, and we even had meetings to discuss things. The quality of support, which helped us resolve issues quickly, was definitely a plus. But ultimately, the product itself was the deciding factor, especially its "ease of use." That was the biggest thing for us.
Sugawara: For me, too, a key factor was seeing that we could execute tests just the way we envisioned, and that our QA team could manage this themselves.
How We Use MagicPod
Kimura: We currently use MagicPod in COCOMITE's development and staging environments. In the development environment, we run tests nightly on a daily basis. In the staging environment, we use it for regression testing before each release, which happens every two weeks.
Right now, we have 68 test case scenarios, which means we've automated about 62% of our total regression testing. There are still some cases that are proving difficult to automate. For instance, mobile app testing is outside our current scope as we don't have a contract for it, and some cloud-specific scenarios are also challenging. Our current automation coverage rate excludes these harder-to-automate tests.
Ito: How much has automation improved your efficiency?
Kimura: The time we spend on regression testing, in particular, has changed dramatically. Manual testing used to take us about 11 hours. Since implementing automated testing with MagicPod, we've cut that down to about 6 hours in total. Being able to automate those repetitive tasks has made a huge difference.
Ito: How do you track and share test results?
Kimura: We primarily rely on Slack notifications. It’s become part of my daily routine now; checking the test results is one of the first things I do in the morning. Development team members are also on that Slack channel. There have even been times when a developer spotted an NG notification and fixed the issue before I had a chance to report it in our morning meeting!
Ito: That's fantastic! It really shows a strong, team-wide commitment to quality.
Moving to In-House Development: Breaking Vendor Dependency and Boosting Speed
Ito: I understand that alongside test automation, you've also been bringing more of your development in-house. For a large corporation like Konica Minolta, that strikes me as a very forward-thinking move.
Naito: Thank you. Given our company's history and development culture, moving SaaS development in-house was indeed a major undertaking. Konica Minolta's background is primarily in developing legacy hardware like multifunction printers and cameras, where waterfall-style development processes were deeply entrenched. When we started developing COCOMITE, a SaaS product, we found that many of our traditional methods weren't a good fit, and it was a constant process of trial and error.
As the product grew in scale and the demand for higher value and more advanced features increased, we needed to be able to adopt new technologies quickly. So, rather than just hiring more people, we decided to focus on "systemization" – building scalable processes – and that's what has driven our push towards in-house development.
Ito: Is this move to in-house development a company-wide directive?
Naito: No, it was more of a strategic decision specifically for the COCOMITE business, rather than a broader company policy. We weighed the risks of being entirely dependent on external vendors and decided that fostering in-house capabilities was the better path. Of course, we still collaborate with external vendors – it's not purely in-house – but they now operate as part of our team, within our development processes.
Yamanaka: We initially relied on vendors, but we eventually concluded that it would be better to build our own technical expertise and take the lead in development ourselves. So, we started recruiting internally and hiring externally to build our team and advance our in-house capabilities.
Ito: We're seeing a growing trend of large companies shifting from outsourcing to in-house development in recent years. It's a critical move for improving speed and managing risk. I feel Konica Minolta's efforts are a perfect example of this trend. Transitioning to agile SaaS development is never simple. How did you manage challenges like setting up your CI/CD environment?
Yamanaka: Actually, during the early days of COCOMITE development, we had some real setbacks that could be attributed to not having a CI/CD environment. I heard stories about how the vendor would try to merge their locally built code right before a release, only to find it didn't work. Even after release, bugs would pop up frequently, making every release a nerve-wracking experience.
Kimura: I remember those days. I’d be manually testing late into the night, and we’d run into frustrating issues like something working fine in staging but failing in production.
Yamanaka: Those failures were a learning experience. We realized that "anything we build must be in a state where it can be immediately verified." That understanding led us to make a firm commitment to properly establishing a CI/CD environment.
Ito: Learning from setbacks to improve your processes is incredibly valuable. Sharing these success stories internally, and inspiring other teams to say, "We want to do that too!" is a vital first step in driving transformation across the entire organization.
Final Thoughts
Naito: I don't think simply installing a tool and automating tasks will, by itself, lead to overall efficiency in the development process or maximize its benefits. The first crucial step is to clearly define your objective: "Why are we automating?" Then, you need to design how you want to improve your entire development process. With that framework in place, it's best to strategically evaluate and select a tool like MagicPod.
Beyond the return on investment, I feel MagicPod offers immense value as a "source of reassurance." It lessens the mental strain on testers, enabling them to approach development more positively. I hope that aspect is also considered when others are evaluating their options.
Yamanaka: Since introducing MagicPod, our quality levels have definitely improved. We've been able to maintain an annual uptime of around 99.99%. I see this as clear proof that automation is helping us ensure a stable level of quality. In terms of cost-effectiveness, MagicPod has also been more economical than hiring additional staff. So, we're certainly seeing the benefits regarding return on investment.
Kimura: For me, the main appeal of MagicPod is its "intuitive, out-of-the-box usability." Because you can create tests without coding, QA and testing personnel can get started on their own, without needing specialized expertise. Another significant advantage is that there are no limits on the number of test executions, so we can run our tests every day without any hesitation.
It's been about a year and a half since we implemented it, and checking MagicPod's test results every morning has become part of my routine. I believe that by integrating it into your daily workflow like this, you can really maximize its benefits.
Sugawara: My first impression of MagicPod – "this is a truly intuitive and easy-to-use tool" – has stayed with me. I believe that's its greatest asset and strength. And beyond its intuitiveness, I find it incredibly powerful that it offers the functionality to implement most of the tests we had envisioned.
