Company Profile

  • Company Name: Jimoty, Inc.
  • Start of Usage: March 2016
  • People Using: CTO Tomoyuki Suzuki, Engineer Toshihiro Miyake

The feelings of users as first priority

This time we visited Jimoty, Inc., operating company of the free-of-charge bulletin board for giving away or buying and selling secondhand goods, "Jimoty". Made as a mechanism with which problems arising from our everyday lives could be solved between local residents, goods including houses, unused furniture and baby goods are exchanged.

Jimoty's development team continues with their work, increasing improvement speed to understand and solve any issues users have.

Commemorative photo at the entrance of Jimoty

Two things kept in mind to consider user's feelings

― What methods do you take to consider user's feelings as first priority?

Mr.Suzuki:We think about user's feelings in various aspects, but largely speaking, there are two approaches.

One is to properly take account of user's feedback, and the other is to implement minimums quickly, release it and ask users for evaluation.

Properly take account of user's feedback

Mr.Suzuki: We really value the feedback from users. We sincerely accept feedback like reviews for apps or voices received at the customer service, and work on improving features and operating rules.

Mr.Miyake: We look through and consider every single inquiry for our services.

Mr.Suzuki: As we look into the inquiries and reviews, it is not always necessarily directly related to the functions of our service.

For example, there were cases where we requested revision on posts because it did not follow the terms established by us. We received some dissatisfaction about that. When we think about what issues there were from this, many issues to improve come into mind, such as the rules for posting not being informed enough, the revision request mail being hard to understand, and reconsidering the flow for revision requests.

Mr. Suzuki with a smile

Mr.Miyake: The posts are displayed newest to oldest, but since the date the post was originally posted was used after revision requests were approved, there was an issue that revised posts were lost among newer posts when they were re-posted. After this issue was found, we made modifications so they were posted with the date of approval.

Mr.Suzuki: Issues like this can be found by properly taking account of users' feedback.

― Is there something you do to be sensitive to users' feedback?

Mr.Suzuki: The reviews for the application version are set to appear on the application team's Slack channel. Also, at the time we were focusing on improving the browser side, we set up a form on it so that users could submit their feedback easily.

Engineers tend to focus too much on just making the features. However, we think it's important to always keep thinking if the feature you are developing is really something users will value.

You can't be sure that the idea you thought up will solve the issue, so it is crucial to always go back and think about what is the essential issue being addressed.

What's most important may be to imagine how many people are facing that issue.

Mr.Miyake: When I try to start something, there are times that I find explaining it troublesome, because we cherish explanations like what issues there are and what kind of feedback and numbers there are (laughs).

Yes, it takes some effort, but I think it is good that way. Make clear what issue there is, what the numbers show, and why we're going to do it.

It's really nice that we get to do anything as long as we can explain it.

Mr.Miake, neatly explaining

Implementing minimums quickly and asking users for evaluation

Mr.Suzuki: We think up our features this way, but in all, how glorious we may think it is, we have no idea how it will be until it's released.

That "glorious feature" of ours may not be used at all.

We think it's important how fast we can implement minimums and release it. After all, making it, sending it out to the public and asking for evaluation gets us to the right answer fastest.

We do a KPT meeting once a week in Jimoty's development team, and how to speed up implementations is often discussed there too. Everyone regularly thinks about how to cut things small, so talks about such themes are very active.

Mr.Miyake: No matter how much effort we put in a feature, it usually doesn't get used too much, and there are even times that no one uses it. If that's the case, we think we can meet the needs of users better by releasing 3 smaller functions and explore possibilities more broadly.

Talking about speeding up implementations, the legibility of codes are very important. When the rules for writing are not standardized, everyone writing codes in their own style, and that's happening all over the place, development takes more time than it should, and denies fast implementations.

KPT meeting

Mr.Suzuki: Wasn't it Mr.Miyake who suggested introducing SideCI?

Mr.Miyake: Yes, I think that was me, at the KPT.

As you know, there are preferences in writing styles of Ruby. There are anti-patterns in Rails as well.

What's important in team development is not writing the codes, but rather reading them. I explained that we can speed up development by keeping the codes legible at the KPT, and had SideCI introduced.

Mr.Suzuki: We use the approach "try it small" in SideCI too.

Mr.Miyake: Actually, we stopped using SideCI once, after we introduced it. There were too many comments made.

At the current state, we are using it like this: consider which coding rules to apply, actually apply the ones that seem good, and if anyone has a opinion about it they can feel free to say it anytime. We discuss the opinions by opening an issue on GitHub.

We are not setting a fixed rule, we change it depending on the situation. The rules we use now might be different in the future. We think and try to continue with our improvements.

Mr.Suzuki: When the actual usage began to start, things changed a lot for the better. The places where there were many writing styles became unified, and we started to be able to write ruby and rails codes as one team. In the future, we plan to fix the cases where the useful functions provided by rails is not put to use, and implement features more simply, with less codes.


At Jimoty, it seemed that they thoroughly consider the users' points of view, always thinking about users, whether deciding implementations or looking back at their work.

This was a interview where we could see that Jimoty, having good reputations such as the interactions being smooth and quickly and being very useful, construct their pleasant community by being very thorough with these points.

Commemorative photo at the entrance of Jimoty

At the time of this interview, SideCI was our product name and was used in these interviews. As of June 13th, 2018, we have changed our product name to Sider and updated the product name in the past interviews accordingly.

Try Sider for free

Free 14-day trial for private repositories, and forever free for open source.
Sign up now, no credit card required!