【ものレボTech座談会】ビジョンから逆算したSaaS開発を語る
ファシリテーターCPO川田（以下、CPO川田）：お集まりいただき、ありがとうございます。第一回目は「我々がテクノロジーでつくりたい世界とは」について語り合いました。第一回目の対談の内容を見ていただくと、今回の内容がよりスッと入ってくると思うので、よかったら第一回目の「我々がテクノロジーでつくりたい世界とは」を見ていただくとすごい嬉しいです。
今回は、抽象度が高かった前回と比べ、具体度を高くしゃべりたいと思います。お題は「テクノロジ―でつくりたい世界から逆算した現在を語る」。今何やってんの、現場はどうなってんのみたいなことを会話できればと思います。
未来から逆算した1stステージである現在のSaaS開発とは
CPO川田：技術的なところをしゃべる前に、経営目線でCEO細井さんのから未来から逆算した現在我々がやっていることはどんな意味があるのか語っていただけますか。
CEO細井：はい。現在我々は工場の製造現場で使う（工場業務の）管理ツールをSaaSで提供しています。
なぜ工場の製造現場で使うツールを提供しているのか。未来で我々のサービスは、工場をデジタルでつなぐことによって、製造業のインフラを目指しております。そのためには（製造に関する）データを集めていくことがポイントになります。そのデータがどこに眠っているのかというと、製造の価値を生むところ、つまり製造現場に眠っているのです。なので、製造現場の管理をするツールを提供しています。
次になぜSaaSで提供しているか。データを集めるには、同じ物差しで測ったデータでないと意味がない。最終的に工場をつないで社会的なインフラまで昇華していく中で、同じ物差しでデータを取って、しかもそのデータは、ちゃんと製造業が価値を生み出す製造現場で生成されたデータであるというところ目指し、我々は現在工場の製造現場で使えるサービスをSaaSという形で提供しています。
CPO川田：ありがとうございます。その同じ物差しっていう状態をつくるのはかなり重要なところですよね。2ndステージに進むための1stステージを現在やっている中で、どの工場でも同じ物差し、同じ標準化方法が入っていることでシームレスに（工場を）つなげられる前提になってくると思います。
さて、物差しっていう言葉で頭出しがされましたけど、2ndステージに進むための1stステージである現在。我々テクノロジーの現場では、実際どんなことを日々しているのか、古澤さんの方に現在を語っていただけるといいな。2ndステージに進むための1stステージである現在。我々は今、現場で何をしていますか？
PM古澤：（工場業務の）標準化を行うために色んなお客さんに（サービスを）使っていただき、要望を吸い上げ、吸い上げた内容に対して、こういう風に実装すればみんなにとっていいんじゃないかっていうのを日々考えながら実装しています。ちょうど今はUI/UXの見直しを中心にやっています。
CPO川田：なるほどですね。その中で、苦労されるようなこともありますか？
PM古澤：要望同士が衝突するときが苦労します。どういう風に調整するとか、どういうオプションにしようとか、オプションで回避できるものなのかとか、そういったところに対して苦労します。
CPO川田：要望の衝突っていうのは、具体的に言うとどういったものになりますか？
PM古澤：検索機能で例えると、A社さんは検索条件を前に使っていた状態に保持して欲しいとか、B社さんは毎回（検索条件を）クリアしてほしいとか、そういったことです。
CPO川田：なるほど。A社さんとB社さんとC社さんと、同じ機能に対する改修要望があるが要望されていることが（各社）違っている場合はどうするんだとか、あるいは一社からの要望であったとしても、「いやいや、こういうふうに要望してくるお客さん絶対いるやろ」とか我々の想像とお客さんの要望が衝突してしまうという場合も似たような問題に発展してくるかなと思いますね。
森松さん、例えばそういった要望の衝突等が起きてしまった場合、なんらかの解決策をもって結論に至り、その結論に対して開発をし、具現化すると。こうしないといけないと思うんですが、どういった解決方法があるんでしょう？
CTO森松：そうですね。解決方法は多岐にわたるので一概にこの解決方法がいいとか言えないと思うんですが、我々SaaSという全社に使ってもらえる共通基盤をつくっているので、（対応が）漏れちゃダメっていうのはちゃんと頭に置くべきでしょうね。全社に幸せになってもらうっていうこと。たしかに全部が全部幸せにはできないですが、ただ不幸になる会社を出してはダメ。
じゃあ、どこまでアプローチをしたらいいのかを考えることがビジネスの（基本的な）考えになるんじゃないかな。テックの話というか要件の話なので、こういう考えをもとにアプローチしていくと思います。
CPO川田：なるほど。SaaSとしてどういうものを作って、どういう人を幸せにしていくかっていうのをぶれないようにしないといけない。けれど、それを変に推し進めすぎたことによって、不幸な人間をつくらないようなちょうどいいところを作っていかなければいけないと。
要望がコンフリクトした場合には、モード実装みたいなものも存在しますね、モードを切り替えるとか、○○モードで使える契約オプションを設定してあげるとか。
そういうところは森松さんが言ったみたいなテクノロジーサイドだけで収まらない話になってくるわけですね。（テクノロジーサイドだけで）収まらない全社的な取り組みでお客さんを幸せにしていくっていう傾向が特に強いっていうのがSaaS開発のおもしろいところなのかもしれないですね！
2ndステージのプラットフォーム化に向けた1stステージのSaaSが超えるべき壁
CPO川田：1stステージを現在やっていますが、1stステージがうまくいかないと2ndステージにはなかなか行けないわけですよ。1stステージから2ndステージに進むにあたって、越えなければいけないハードルだったりとか、ぶち当たる壁みたいな象徴的なものが実際出てくると思います。
そこで、これ越えないと2ndステージいけませんよって考えているものって細井さんは経営的にあったりしますか？
CEO細井：我々がこえなければいけない一番大きな壁はPMF（=プロダクト･マーケット･フィット）の壁だと思っています。
我々のサービスをローンチしてお金を払ってくれるお客さんが一定数ついてもその数字（お客様数）が（最初は）伸びないんですよね。その伸びない理由っていうのが、（ローンチしたサービスの）機能的には60点とっているけれども、お客さんは70～80点期待している。もっというと、マーケットは70～80点の期待で我々のところ来たてみたら、アーリーアダプターは使うけれども大半の人は使わないみたいな。60点から（マーケットの期待に応えられる）70～80点まで持っていくというところがかなり苦労したと。
例えば象徴的な、技術面での話。我々のサービスのメインの画面というのが、いわゆる動的なガントチャートの画面になっているんですね。要は製造現場がそこで一元的に見える化されているような管理画面になっているんですけど、そこの画面は非常に情報量が多く、かつリアルタイム性を求められていて、その結果アニメーションなどの動きであったりとか、インタラクションも直感操作でできたりと、いろんな機能が盛り込まれているんです。
我々がターゲットしている市場のお客さんの業務量に対して、（サービス側の画面で）管理できる情報量（キャパシティ）っていうのが余りにも少なくて、お客さんはこれだけ管理したいのに、それだけのデータ突っ込んだら画面が重たくなってひどい場合にはブラウザが落ちるみたいなことがありました。
それは、ここにいる古澤さんとかテックチームの皆さんの努力によってある程度改善することができ、なんとかPMFの7,80点のぎりぎりのところにたどり着いたというのが象徴的です。
CPO川田：なるほどですね。60点70点が一応その運用に乗りますよっていう点数付近になってくると思いますが、そこに至るまで（情報の）マネジメントできる必要量をクリアできるまでに苦労したというところですよね。
古澤さん、実際のぶち当たった技術的な壁とそれをどう解決したのかというところを、少し具体度を上げて、技術的にご説明いただけますか？
PM古澤：はい。ガントチャートのところは相当技術的な壁にぶち当たりました。ガントチャートというものは普段オンラインでフリーで落ちているものとか、有料のものとかあるんですけども、データ量がそんなに多く表示されるものになっていないので、我々はフルスクラッチで多くのデータを扱えるようにものをつくっていました。
やっぱり多くのデータを扱うといっても限界があるわけで、一度限界を迎えてしまいました。そこで、技術的にこれを当てたらいいというよりも、コツコツと一か所一か所無駄な部分を削ぎ落して、どんどん対応しながら実装してきました。
CPO川田：全体的に解決するような最適な石はなかったけれども、地道に見つけていって、それを潰していく過程でなんとかその点数までたどり着いたという感じですかね。
今回の件に関しては、ガントチャートっていうフルスクラッチするなら計算の複雑なものに対し、大量のデータをフロントエンドで計算させるのは結構しんどかったところもあるかもしれないですよね。
そういった、大量のデータを扱う描画をする、可視化表示するみたいなところってどのサービスでもぶち当たってくる壁になってくるし、お客さんが増えてくれば必ず出てくる問題だとは思います。
その大量データのアプローチに関して森松さん何かこういった経験が今後生かされていくかもしれないなみたいな点はありますか？もしくは、大量データを扱う時にはこういったことに注意していけば、そもそも壁にぶち当たらないで済むよみたいな魔法の言葉があったらすごい嬉しいです。
CTO森松：前回の話で言った概念モデリングの話になりますね。大量データをそもそも扱うって、それをどうやってシステムに負荷がないように見せるかっていうのが最初の設計。大量データを扱うっていうのはシステムの命題であり当たり前のことで、それはやらなきゃいけないですよ。なので、どう見せるかという設計の問題だけだと思います。
テック側とビジネス側がちゃんと協力してこれだけのスペックでここまで保証して、ここまで動作させるというのをちゃんと相談しながらやるっていうところ。多分今までそれを後付けしてきたから苦労していると思うんですけど、最初からちゃんとやればという話かなと思いますね。
CPO川田：なるほどですね。「最初からやっとけよ！」っていうことを言ってますよ、古澤さん(笑)
PM古澤：そうですね(笑)。ただ、SaaSっていうところで最初想定していたところよりもはるかに大きくなっているという問題が顕著になっているというのが要因かなと思います。
CPO川田：そうですよね。だからしょうがないじゃないかと(笑)
一同：(笑)
CPO川田：でもまあ、そういうものですよね。想定位置自体が時間の経過に応じて、変わっていくあるいは伸びていく。これもSaaSの特長なので、想定位置に対して当てこんだ設計じゃなかったことによって、想定位置が変化したときに「しんどくなってきたな、さてリニューアル考えましょう」とかみたいなということはよくあるかもしれないですね。
大量データを扱うというところはシステムの命題でもあるので、森松さんからパワーキーワード（=概念モデリング）が出てきたんですよね。たしかにそうですよね。大量の人間では扱いきれないデータをシステムで自動で扱うからこそ、システムには意味があるのであって、その大量っていうところがフェーズに合わせて変わってきたっていう象徴的な出来事かなと思います。
常に進化し続けるSaaS開発の裏側
CPO川田：じゃあ大量データを扱えるようにするため、我々は何もしないかというと実際に何かしているんですね。大量データがもともとの想定よりも、もっと大量に扱えるとかそこに合わせてUXの調整をしたりとかというプロジェクトをやっています。その名前を、すごいセンス満点の名前で、NEOって呼んでいるんですよ。センス高いですよね～(笑)。
一同：NEO(笑)。
CPO川田：NEOプロジェクトとかって言っているわけですよ。大量データを扱えるとか、UXをもっと上げるとか、2ndステージに進むための森松さんが言っている概念モデリングからやり直すとかの一連の流れをNEOって呼んでいます。じゃあ1stステージを進化させるNEO化っていう中身がどうなっているのかをしゃべりましょう。
森松さんは最近ジョインしているので、逆に森松さんからみたNEOっていう取り組みはどう見えているのかのからしゃべってもらいましょうかね。
CTO森松：名前がふさわしくないと思っているんです(笑)
一同：(笑)
CTO森松：NEOという名前の安定化バージョンをつくろうとしているっていう理解しかないです(笑)。
CPO川田：終わった！短っ！(笑)
一応NEOって言っているのは、今不安定なところを安定化させるための取り組みで、NEOっていうとあまりに大きな進化がありそうだから、NEOっていう言葉は森松さんとしては好かん！と。
CTO森松：うんうん。
CPO川田：そのNEOっていう名前はさておき、新しいステージへ行くための新しい一連の取り組みのことを簡易的にNEOって呼んでいるわけですね。細井さん、NEOっていうことができると、我々ってどこに進むことができるんですかね。
CEO細井：そうですね。さっきのPMFっていう領域に入るための壁をやっとギリギリのリソースで乗り越えたので（システムが）ぐちゃぐちゃになってます。そこには何のモデリングもなく後付け後追いで、古澤さんの想定していたものをはるかにこえてくるお客さんもいたり、色々見えてきた。
さらに見えてきたのは、システムの中身だけでなく、お客さんから見たときの求められているUXってどこにあるのか。現状のサービスっていうのは我々がお客さんの立場に立って仮説を立てて、「こんなのあったらどうですか？」を検証してきたけれども、その検証が一周まわって、お客さんからのフィードバックを真摯に受け止めることによって、こういう風な刷新されたUXが使いやすい、お客さんが自分の力でオンボーディングできるようになるんではないか、というのを検証していくのがNEOと思っています。
CPO川田：これまでは、我々の想像したものとか少しもらったお言葉みたいなところでシステムを作ってきた。
作ってきた結果、実際に喜んでいただけるお客さんも増えてので、そこから集まってきた生のマーケットの声みたいなものに合わせていこうとすると、一旦マーケットの声をいただくために仮投入していった1stバージョンみたいなもののほころびが実際に可視化されてきた。そのほころびを直していくことによって、実際にマーケット（の要求）にぴったりあったものだったりとか、（マーケット）規模に合うようなものだったりとか、そういったものに対応していくのがNEO。
NEO自体は技術的には使っているものはあまり変わらないですよね。中を色々調整していく形になっていくと思います。一応ヘッドレスで。ヘッドレスというのはアプリケーションそのものをバックエンドとフロントエンドの一体型でつくっていくのではなくて、バックエンドにAPI群を用意して、フロントエンドのアプリケーションなんですけど、こいつで機能を網羅していますよという状態をヘッドレスアーキテクチャと言ったりします。このヘッドレスで組んでいる裏側、バックエンドのところを調整してくっていうところにウエイトが強かったりします。
常に進化し続けるSaaSのバージョン名の付け方
CPO川田：一方で、NEOよりもっとかっこいい名前がついているやつがあるんですよ。古澤さんからNEOよりもっとかっこいい次のやつ、名前発表してもらってもいいですかね？
PM古澤：新NEOって言います(笑)。
CPO川田：どうですか、森松さん。新NEOっていう名前に違和感はないですよね？
CTO森松：これがNEOでいいじゃないかなと思います(笑)。バージョンの名前のつけ方が意味わからないのは、しょうがないと思っています(笑)
CPO川田：我々も自覚はしてるんですよ(笑)。新NEOってやばいよねって(笑)
PM古澤：我々、スタートアップですので”新しい”という言葉が好きなんですよね(笑)
CPO川田：”新しい”加えちゃったみたいなね。次のプロジェクトはNew新NEOとかになるんですかね(笑)
CEO細井：そもそも現行バージョンも”新生”って呼んでますからね(笑)。
CPO川田：新生(笑)。新ついてますからね(笑)
CTO森松：古いものがないイメージですね。
CPO川田：あ、いいこと言ったじゃないですか！我々には古いものが一つもない。すべてが新なのである。
名前の付け方、ぶっちゃけ苦労してまして、最初に新をつけちゃったから、さらに新しいものどうすんだみたいな話がでてきて、最新のプロジェクトは新NEOって呼んでるんですね。新NEOになると、NEOって呼んでるものよりもフロントエンドの解決施策の色が強くなってくるわけですよ。
2つ先のバージョンを見据えながらの開発
CPO川田：新NEOはバックエンド自体も、それこそバージョン3みたいなことも含まれますし、フロントエンド自体もきれいにSPA化されて、マルチデバイスで運用できるようになってきて、どこで何で使っていいですよという利便性もかなり上がってくると思うんですけどね。
古澤さん、それってお客さんにとってどう変わってくるんですか？
PM古澤：そうですね。今まで積み上げてきたPMFというところに対し、我々が最も提供したい形のUI/UXっていうのが新NEOになってきますね。
CPO川田：UI/UXが特に今よりもっと使いやすいものていうとちょっと平たいですね。細井さん、なにかいい言葉ないですかね？
CEO細井：そうですね。私たちの価値観で説明すると、使いやすいだけでなく、そこにワクワクする気持ち（を付加）。
例えば、新しいiPhoneを買った時、箱を開けるところからUXが作りこまれていて、起動しセットアップしてずっとワクワクしていると思うんですけど、我々のサービスを買われるお客さんにも業務アプリといって単純に機能だけ網羅しているんじゃなくて、「俺たちの職場がDXによって変わっていくんだ！」みたいなワクワク感を、はじめてログインしセットアップして運用に乗っけていくという過程全体で提供できるようにするのが、我々として使いやすさだけではなく提供したい価値になります。
CPO川田：なるほど。すいすい使えるよとか、誰でも使えるよとか、ヘルプが充実しているよとかだけではなくて、毎日使っていること自体が業務の楽しさみたいな感情的な領域まで（の体験を）我々が考えているのが新NEOになりますってことですね。
フロントエンドはそういう感じになりますし、バックエンドはバージョン3なAPIっていうものが企画されています。
そこに関しては主に森松さんの方で進めて構想していったりするんですけど、それが出来上がることによって、何が変わってくるんですかね？森松さん。
CTO森松：それが前回言っていた概念モデリングをやり直そうねっていうやつですね。要するに、これからいろいろ機能がバージョンアップされていく中でほんとに変化の強い仕組みになっていくというのがバージョン3だと思っています。
CPO川田：具体的にいうと変化に強いっていうのは、どういう変化が訪れたときにどういうふうに解決する話ですか？
CTO森松：一つの機能がガチっとカプセル化されているイメージですね。昔からJavaのコーディングとかオブジェクト指向とかでカプセル化していった方が変化に強くなるっていうのがありますけど、ビジネスのモデリングをちゃんとカプセル化してガチっと固めてしまおうと。
実際組み上げる時、ここ外してここつけるみたいなレゴブロックみたいなやり方ができるようになるというのがマイクロサービス的な考え方ですが、それがきちっとできるようにモデルを変えてしまおうというのが概念モデリングっていうことですね。
CPO川田：前回から見ていただいている方、何度か概念モデリングが出てきて「なんだそれ？」と思っていたと思いますが、レゴブロックのことらしいです(笑)。
概念モデリングをすることによって、システムをあたかもレゴブロックかのようにいとも簡単に組み替えたりとか修正したりできるようにすると。
そういうふうに組換えがきくようになって、ちょっとこれまずいなっていう場所から簡単に取り外しがだったりができることによって、システムを健康体に保つことができる。
治療だったり拡張のしくみをもともと最初から計画し物理的に実現しておくことが概念モデリングになっていて、V3ではそれができるようになる。そうすると、拡張も回収もメンテナンスも非常にやりやすくなってくるので、エンジニアとしてもすごく働きやすいというか、わかりやすいシステムに対して美しいソースコードを提供していくことができるようになるわけですよ。
古澤さん、実際こういうようなエンジニアの仕事体系になっていくっていう描写をいただけると、これを見ている方がV3でジョインした時に、我々はこういうような仕事ができるんだとイメージしやすくなるかなと思うんですけど、どうでしょう？
PM古澤：そうですね。人によって違いがあると思うんですけど、私は画面から機能を把握していったりとかするんです。そのときにモデルとの対比が分かりやすくなっていくんじゃないかっていう。
なにかを直しますっていったときには、綺麗に整地されたソースコードになっているので、ここを直せばいいんだなというのがさらっと分かるようになるとか、ここからの影響範囲がある程度限られてきて、ここなおしたから他も直さなあかんとかが見えたりとか、そういうふうになっていくんじゃないかなと思います。
CPO川田：たしかに画面で描写されているアプリケーションって裏側のデータモデリングが概念的に頭の中でなかなかリンクしにくいような設計がされていると理解するのも大変です。理解しにくいからミスが起きるっていうことで、画面に描画されているものとモデリングされているものがぴったり合っているっていうのは結構重要だったりしますよね。
あとは綺麗になることによって、カプセル化っていう話もありましたけど、ある一定のプログラミング仕事が別のところに大きな影響を与えてしまうリスクもかなり小さくしていけるので、安心してプログラミングしていける傾向は強くなるでしょうね。
ものレボテックチームから読者へのメッセージ
CPO川田：さて、今回は現在を語るっていうことで、できるだけ技術の現場とか技術者として何を考えているのか、それをビジネスサイドはどのように観察しているのかを話してきました。
最後に、森松さんと古澤さんからこれを見ていただいている方に対して、「こういった技術施策を進めているので、こういう目的を持った人たちは、ぜひこの環境に来ていただくといいですよ」ということを言っていただいてもよろしいですか？じゃあ古澤さんから。
PM古澤：いろいろな経験を通してエンジニアをやっている方にとって、今後の（新しい）自分のスタンダードとなる仕組みを作っていくことになると思うので、ある程度の経験を積んでいるエンジニアにとっても自分のステップアップができるんじゃないかっていうのが一つ。
もう一つは技術とは離れますけど、ビジネス的なインパクトをどんどん実装していくことができるので、技術とビジネスが近い所にあることに対して楽しいと思える方々には有意義な時間を過ごせるんじゃないかなと思います。ぜひ一緒にやりましょう！
CPO川田：前回もこのような〆の言葉をお願いしましたけど、「え、これ毎回やるの？」という顔をしている森松さん、毎回やっていきましょうね(笑)
森松さんからどうでしょうか？
CTO森松：一番目の質問で考えてたことを今盛り込んで、もりもりで答えても大丈夫ですか？(笑)
CPO川田：そりゃ、森松さんなのでもりもりでお願いしますよ～。
CTO森松：1stと2ndのステージにおいて、技術サイドはほぼ関係ないと思っていて、サプライチェーン（2ndステージプラットフォーム）と個社最適（1stステージSaaS）って分離できると思っているんですよ。そもそも個社最適を理解して、データ集めてサプライチェーンで最適化するっていうビジネスのフローに沿っているだけで、技術的にもビジネス的にも別に分離して、どっちから始めるっていうのもありえると思っているんですね。
1stと2ndで何が分かれているかといえば、一番根本的な問題は組織にあると思っていて、組織が出来上がるか出来上がらないかで一機に二つ（の事業開発が）できるかできないということだと思っているんですよ。
今、組織自体は過渡期にあって僕が入って来ましたが、組織が成り立っているかというと全然成り立っていないんですね。まず、何が成り立ってないかというと全員がフルスタックで働いちゃっているっていうところが成り立っていない。川田さんだけフロントエンドやってますけど(笑)。
ほかの人たちはフルスタックで働いている。これって技術者サイド)にもあんまり気持ちがよくなくて、1技術者が1役割を全うするというのが、集中できるし、連携もしやすいんですよね。僕は今まさに年内にそういう組織に変えていこうと思っていて、フルスタックからちゃんとバックエンドチーム、フロントエンドチーム、QC/QAチーム、インフラチームとどんどん分業をして、役割を人に一つ割り当てていく。その役割はその時は一つだけだけれども、アジャイル方式でやってふさわしい人にはどんどん役割を変更できる体制にもっていこうと思っています。
技術側の組織の成長が急務で、むしろそっち側を僕がメインにこれから発展していきますので、技術者の方にとっては、気持ちのいいような環境に当然のごとく整えていきます。それが技術の発展にもつながっていくと思いますので、大事なことだと思っています。
だから、ベンチャーでありがちのめちゃめちゃ詰め込められるというようなことも今の段階ではちょっとあるんですが、これからどんどん変わっていくし、気持ちいいところで気持ちいい働き方、環境で、なおかつ知識も自分に身につけられる環境をつくっていきますので、これからものレボはすごく開発環境、開発チームもよくなっていきます。
みなさんぜひ入ってください！
CPO川田：もりもりでしたね！(笑)。ありがとうございました！
一同：ありがとうございました！
CPO川田：ここのメンバーと直接話してみたい方はJob Boardからイベント情報をチェック！イベントがなくてもカジュアル面談のご応募もお待ちしています！
この記事が気に入ったらサポートをしてみませんか？