文化・メンバー・働く場所

とっかかりはこんなもの作ったら面白いんじゃないの、という思いつきみたいなところから始まりますね。

最近で言うと、社員みんな料理が好きで、肉を如何に柔らかく、美味しく焼けるか、というところから製品の発想が出てきたりしています。

この前も瀬木さんが焼いた肉を持ってきていただき、食べさせてもらったりしましたね。

少し前の機種になりますが、TR4を作った時にはオーブンの中にセンサーを入れてBluetoothでリアルタイムで肉の温度が見えるので肉は63℃で固くなるのでそれに合わせて肉を焼いてみたりとかしましたね。

初期の開発アイディアは普段の日常会話、雑談の中からの派生が多く、昨日肉焼いてみたんだよね、どういうふうに焼いたの？うまく行った？というような立ち話の中から製品のアイディアになっていったりすることが多いですね。誰から発信というようなこともなく、面白いこと、好きなことで雑談しているうちに自然と、こういうものあったら面白いんじゃない？というような形で始まります。

発売30周年になる「おんどとり」ですが、「おんどとり」ってずっと変わってないじゃん、というようなことを言われることがあります。しかし実は結構変わっていて、その時々の最新技術を組み込んだり、通信方式の変化に対応していったりとか、時代に即した開発は好まれる傾向にありますね。

あと重要なのは手離れの良いものってこともありますね。いつまでもうちのサポートが付きっきりでないと運用できないものではなくて、感覚的で分かりやすいものを作っていきたいし、目指していきたい。

説明書がなくてもわかるようなサービスが理想ですよね。

温度をネットに上げるメリットが分からなかった時代だとは思う。今となってはその利便性は一般的で活用方法も容易に想像できる世の中になっているが、そういう時代を作った一翼を担えたのではないかと思っています。

まずは製品開発部署からアプリ、クラウドも含めたサービス全体像のイメージを膨らませることが多いです。どう連携して、どうデータを流すかなどの叩き台を作り、そこからアプリ開発部署やクラウド開発部署へ相談して依頼していきます。

製品開発部署で大体の仕様ができた段階でどういう機能が必要か、どういうコマンドが必要か、製品側でどういう動作にするべきか、というようなことをアプリ側でも定義していきます。また、サービスや機能についてもアイディアがあったらどんどん提案していくし、必要不可欠な仕様や機能があれば、製品開発部署に少し無理をしても入れてもらうこともあります。

CX推進部のメンバーもそこに参加します。お客さんから貰ったフィードバックや対話してる中で感じたこととかを製品本体やアプリなどに対しても積極的に関与して話をするようにしています。そしてそれを聞いてくれる土壌はあると思います。

開発はアジャイル気味になっている様子が伺えるが、納期が伸びるとか現場負担が増えるとかあるのか？

納期が伸びてもいいって思っている訳ではないですが、実際、これは入れといた方がいいよね、ってものがあればどんなに発売日が迫っていても入れることはありますね。それによる現場負担はあるかもしれないけど、納得して貰えるようにちゃんと現場とは話をするようにしています。

強みとしては自社製品のメーカーであるということ。今、瀬木さんが言ったように例えば発売間際でも、この機能が必要となったら追加できるし、スケジュールも自分たちで調整できるし、納期に間に合わせるためとか、納得できない仕様のまま進めるとかはなく、やりたいことやれる。いいと思うものを突き詰められるので、そういう意味ではストレスは少ないのではないかと思う。

実際に納得のいかない仕事はないのか？

「おかしいかな」みたいなのがあったら、担当者と話してこうした方がいいのではないですか？とかそういったことは出来るので「変だなぁ」と思ったまま続けないといけないということはないですね。

先に確認しておいた方がいいかな、というようなことは出てくるけど、そのために時間がかかると言えば時間を貰えるし、納得できています。

今やってて楽しいことは？

体制として「これやってみたら面白いんじゃないか」ということは却下されることはなく、「やってみたらいいんじゃない？」というような環境なので、動きやすいという点が凄く面白みがあります。ただ、裁量が大きく、やりたいことをある程度受け入れてもらえる反面、面白いと思ってやっていることがちゃんと会社のためになる必要があるからプレッシャーもあります。

自分がよくやるのは、うまくいかない時には現象的な物理的な根本に立ち返って、そもそも熱はどう伝わるのかとか、この物質はこういう特性だからこうすればうまくいくとか、そういうアプローチをします。

アプリケーションではそもそもできるのかをまず調べて出来そうだったら挑戦するし、出来ない時は、ハードウェア側の仕様をちょっと変えるとうまく行くんじゃないかとかハードウェアの開発者と相談しながら解決したりします。

ハードウェアで出来ないことをクラウドやアプリで処理してもらえないかなど一緒に話をして、じゃあアプリの方でなんとか処理してみるよ、とかそうやって解決することがありますね。プロダクト、アプリ、クラウドの開発は連携しながらコミュニケーションとりながらやることが伝統的なやり方ですね。

Bluetoothに初めて対応した時はハードウェア的にはかなりチャレンジだったと思うけど、アプリとの通信方式とか技術的困難なところも相談しながらやってました。

2016年頃、当時のBluetoothやAndroidなんかは進化途中で相性で繋がるとか繋がらないとか、まことしやかに言われていて苦労した記憶がありますね。ほんとに初めてのことなのでうまくいかない時はハードウェアがおかしいのかアプリの処理がおかしいのか分からなくて、アプリの人とずっと付きっきりで実装しては検証して、うまく繋がる、繋がらないというのをやっていましたね。

製品開発メンバーはある程度決まっていて、それほど大人数でやっている訳ではないので、メンバー内の全員が何かしらに絡むことが多いですね。得意不得意、専門分野などそれぞれあり、適正によって割り振られることが多いですね。

固定されたメンバーだけで製品開発は進むのか？

現在の社員の中では固定されているのが現状です。ただ、排除している訳ではなく、一緒に考えたいとかそういう人がいれば一緒にやっていきたいと考えています。

新しく入ってきた仲間が製品開発に携わるのは難しそうに感じるが？

新しく入ってきた人たちには割と声をかけて巻き込むようにはしています。その人の適正など判断しながら力になってもらえそうなことで参加してもらうようにしています。

私も入社当時、新しく発売する製品のデバックから入り、デバックしつつ、関係する機器の使い方を覚えたりして、徐々に機器の中の回路とかも見るようになり、関連のソフトを覚えたり、そうしていく中でいろいろな案件を任されるようになりました。

いいところは、あまり停滞することがないところ。ただ、社内共有や資料を残すとかは後回しになりがちで、最近いろいろ改善の試みはしていますが、課題な部分かなと思います。

いいところはやはり裁量が大きくて動けるところ。改善したいところは層が薄いところ。人員を確保して、第三者レビューをもっと多くの人にしてもらい、よりクオリティを上げていける環境にしたいです。

今の体制というか、会社の考え方の部分になりますが、去年、抱えているプロジェクトでプレッシャーを感じていた時に経営者が「やってみようよ、別に成功ばっかり追わなくていいじゃん」と言ってくれました。これが助かったというかホッとして、みんな成功を追い求めたいとか、当然失敗したくないというのは当たり前だと思うけど、そこをあまり恐れる必要ないんだと。
それより積極的にチャレンジして進めていくことを評価してくれる会社なんだと。その辺が会社のいいところかなと思います。

うちで作ってるものは業務的な分野で使われると思うんですが、仕事で使っている中でも面白いと思ってもらえたりとか、うまく考えられてるなぁとか、そういうものでありたいですね。

最近、化粧箱のリニューアルをしていて、コストをかけて今よりいいものにしようとしているが、その理由は愛着を持ってもらいたいから。実際にお客さんの中には「おんどとり」のことを「おんどとり君」と呼ぶことが社内の通例になっているようなところもあり、とても愛着を持ってもらっている。これが本当に嬉しくて、今後も愛着を持って使ってもらえるような製品を作っていきたいです。

愛着を持ってもらうためにも、使いやすい製品を目指して行きたいですね。

あとは製品だけでなく、アプリやクラウド、弊社が提供しているAPIなども少しずつ進化していて、総合的なサービスの質を向上させていくことも大切だと思っています。