This is an English translation of the original Japanese article.
In recent years, we at teamLab have often given the impression of being artsy, but digital solutions resolving client requests and issues account for half our business. Our development has spanned a broad range of diverse sectors, including finance, EC, sports, and IoT. We have been providing the means to solve a wide variety of issues straddling different sectors for clients in many different industries. We have implemented various initiatives to solve issues and have been working to create an environment in which our engineers are able to fully commit themselves to solving problems.
Issues and challenges of doing business with a broad range of industries
We offer solutions to problems that clients face in a broad range of industries. Extensive knowledge is required for solving the various problems presented by clients. Applying this acquired knowledge to problems that arise in other industries makes it possible to search for and offer an even better means of resolving issues. In addition, we are always working on new projects and continuing to demand improvements in our problem-solving means. To provide a better problem-solving means, we believe that a cursory approach does not work, and we take several initiatives. This article presents some prominent examples.
We are not constrained by customary procedures, but continually incorporating new things
Utilization of a library not only improves project development efficiency and quality, but is also an effective means for concentrating on resolving the issue. teamLab actively makes use of new libraries. Because we are always working on new projects, we are able to work on testing concurrently with development and strive to improve projects.
Jetpack Compose
It is no overstatement to say that app screens have only increased in complexity in recent years. Declarative UI, which has been proposed in the Web industry, is one solution to that. At teamLab, we have also taken notice of Jetpack Compose, which has brought declarative UI to Android. We have been discussing it internally since it was in the Alpha version and have incorporated it into projects.
Flutter
Flutter, which uses one code for apps on multiple platforms and implements direct GPU rendering so UI differences hardly occur, has contributed to reducing development costs and improving development speed at teamLab as well. Because its features are production-ready and not just for prototyping, there have been more and more cases where it has been adopted, including our own apps.
Kotlin Multiplatform Mobile (KMM)
Logic uniformity among platforms is an issue in creating robust apps. The adoption of KMM has allowed us to coordinate minor logic differences and reduce reworking. We hold study sessions both in-house and open to the public, and take the initiative to keep up-to-date on Kotlin’s new language features as we search for even better KMM implementation methods.
Jetpack and AAC
We have actively employed Jetpack, which provides a variety of libraries for concisely writing complex Android-specific code. In addition to utilizing the de facto standard ViewModel and DI using Dagger Hilt, we also pay attention to Alpha-version libraries in development, and gather and validate information so that we are able to build optimized apps more concisely and adopt this technology in our development.
Our efforts go beyond individual projects
We pursue development and strive to resolve issues as we share knowledge among projects.
Here are some of our specific efforts.
New initiatives are advanced by the entire company
We previously had more than 20 projects operating with Jenkins on-premises, but almost all of these were switched over all at once to CircleCl within two weeks from contract initiation.
Before that, we researched differences in repository configuration, differences in how deliverables should be saved, and other problems with adoption, and created templates and documentation. When the switchover was made, team members who had completed the switch offered support for other projects and shared their knowledge throughout the company. This enabled the switchover to be completed quickly.
We are currently sharing new knowledge about CircleCI throughout the company as well as preparing and deploying templates with each update so as to maintain quality throughout our organization.
Regular condition checks of our services and development structure
With projects having a long operational life, updating libraries and tracking new technologies may be insufficient.
At teamLab, we define a state in which technological and quality standards are met for creating an even better service as a good condition and measure the condition of our projects. Checklists are used in conducting interviews to organize tasks for being in better condition and creating an environment in which we are able to continually strive to enhance quality.
Template repository for sharing design and implementation patterns
By conducting interviews to learn about problems faced in multiple projects, issues that arise as projects grow and operations continue, as well as patterns in implementation and design necessary during launch come into view to some extent.
teamLab uses Github’s Template Repository to share static analyses, CI/CD configuration files, DI implementation patterns, and other code snippets and boilerplates. The use of this feature prompts continuing discussion and updating of architecture and design patterns in order to incorporate new technologies.
Moving beyond roles to confront the essence of the problem
An approach to work that only performs assigned tasks is unable to create better services that could exceed the public’s expectations.
At teamLab, to create better services, engineers are involved, as team members, along with catalysts and designers, beginning prior to proposal and requirement definition. The majority of our in-house designers create designs, so designers and engineers discuss these things as they deal with smartphones together and cooperate to improve projects.
Also, transcending areas of specialization, tasks are shared between app and back-end engineers, who determine requirements and features as they recognize issues with the project from a perspective transcending individual areas of specialization and also make an effort to advance development.
Precisely because the team is a flat organizational structure, we hold discussions in a manner that extends beyond specific roles using a common language of “solve the problem,” and we are able to work together on problem-solving.
Transcending boundaries between projects and specializations
At teamLab, there are no work duty divisions. As a result, there is no fixation on the duties of only an engineer, and our personnel are able to amply demonstrate any skills that they possess and want to put to use in any areas that they are interested in.
The case presented here is just one such initiative. We are also searching for a system that will not constrain our team members to their project or area specialization, but enable them to commit themselves as we aim to be an organization that creates even better services.
We are working to establish an environment where all our engineer team members are able to go beyond any boundaries in order to do their utmost to resolve issues so that they will be able to provide even better services together with designers and catalysts as they make use of the knowledge and perspectives they maintain as engineers.
teamLab works and career information
- Works
- Career blog
- Job information
About the authors
teamLab Smartphone Team
The team designs and develops apps for smart devices. Development has spanned a broad range of diverse sectors, including finance, EC, sports, and IoT. Knowledge is closely shared among teams so that we may make use of frequently-emerging new technologies.
