00:04
こんにちは、10Xfmです。
10Xfmは、10Xの社員が緩く話すポッドキャストです。
今回は、いつもの雰囲気と変わりまして、
ゲストにお越しいただいています。
今回のゲストは、株式会社スマートHR、
代表取締役、CEOのセリザー・マサトです。
セリザーさん、よろしくお願いします。
どうぞよろしくお願いします。
じゃあ、はじめに、簡単に自己紹介をお願いできますか。
はい、今ご紹介に預かりました、
株式会社スマートHRの、
CEOをしております、セリザワと申します。
私、経歴といたしましては、
2016年の2月に、
この会社に中途の形で入社しておりまして、
当時は、一エンジニアとして、
この会社に入りました。
当時、僕が入った頃はですね、
スマートHRというサービスが、
正式にローンチされて、
まだ2、3ヶ月ぐらいのフェーズでして、
機能も今より全然少なくてですね、
これからみんなで作っていくぞ、
というフェーズだったんですけど、
その時に、エンジニアとして、
ずっと機能開発というところに
携わってきておりました。
その後は、VPOEになり、CTOとなりですね、
昨年の12月までは、
CTOとして、プロダクトを開発するチームを
牽引するようなことをしており、
今年の1月に、
前任の宮田さんからですね、
代表取締役、CEOを交代いたしまして、
現職に就いております。
どうぞよろしくお願いいたします。
はい、今日はよろしくお願いします。
今日、今回ゲストに来ていただいた背景なんですけども、
今、TENXの我々の事業である
Staylerが、まさに
プラットフォーム化といったものを
目指しておりまして、
まさにそのスマートHRが
2018年頃から
プラットフォーム構想というものを
進めておりまして、
その先行者である、セリザーさんに
今回、私、CTOの石川が
話を聞かせていただくという形で
この企画をさせていただきました。
よろしくお願いします。
はい、お声掛けいただきまして
どうもありがとうございます。
今日、話を聞けるのはめちゃめちゃ楽しい。
まず簡単に
スマートHRのプラットフォームの近況について
お話を聞かせていただければと思うんですけども、
今年の7月ですかね、
まさにスマートHRプラスベータを
公開したりだと思いまして、
これがまさに
スマートHRの
プラットフォーム上で
アプリを公開できるというものだと思うんですけども、
そこに至るまでの経緯といいますか、
その事業的な意図みたいなことを
簡単にご紹介いただけますか。
はい、もちろんです。
どっちの順番から話しますかね。
リリースから遡っていくか、
昔から今に至るまで
どっちの方が面白そうですか。
そうですね。
それでいくと、最初に
03:01
これをやるぞって
意思決定するにあたって、
一番達成したかったところというか、
何を目指してこの計画をスタートして
というところから始まると
そうですね。
じゃあ最初から話しましょうか。
これ僕がバババッと
喋っちゃって大丈夫ですか、ここから。
ぜひお願いします。
あ、了解です。
じゃあかなり昔に遡ったところから
始めようかなと思うんですけど、
もともとさっき僕自己紹介で
2016年に入社したって言ったんですけど、
最初にスマートHRというサービスを知ったのが、
今はなくなっちゃったんですけど、
テッククランチ東京のスタートアップバトルの
2015年のところで
スマートHRがそこで優勝したんですけど、
そこを現場で見てたんですよね。
それで三宅さんがやっていた
ピッチを聞いたときに、
このサービスすごくいいなって思ったんですよね。
エンジニアだったんで
何がいいかと思ったかというと、
当時からロームの課題を解決する
というところをやっていたんですけど、
正直ロームってそんなに
僕、一エンジニアだったんで
馴染みなくて分からなかったんですけど、
そんな僕が魅力に感じた点が、
従業員のデータが
たまるところだなって思ったんですよね。
やっぱりこの時代において
データを整備して蓄積していくって
すごく強みになるじゃないですか。
今の21世紀のビジネスにおいて
データは石油だとか言われたりしますけど、
Googleとかは
コーポレートミッションに
世界中のデータを整理しみたいのがあるぐらい、
データを整理するってことが
すごく大切なんですけど、
スマートHRっていうサービスを通すと、
スマートHRで業務を
回していくだけで、
自然と従業員のデータが、
かつ従業員の体系だったデータが
蓄積されていくし、
かつそれがですね、
アップデートされ続けるっていう点が
いいなって思ったんですよ。
社会保険の手続きに関係していますので、
役所に提出する
書類を作るんですよね。
例えば、引っ越ししましたとか、
苗字が変わりましたとか、
新しく家族ができましたみたいな時に、
必ずスマートHRのデータが
更新されると。
更新が漏れるってことがあんまりないんですよね。
部署が移動したら
スマートHRが更新されるし。
なので、常に最新の
従業員のデータが
溜まり続けるっていうのは、
これはなかなかすごいんじゃないかと
思ったんですよね。
かつ、SaaSとして展開していくと
スマートHRが色んな企業のデータを握れると。
ここに一番興味を持ちましたと。
僕はその時に
そこの拡大に
携わりたいなっていうのと同時に、
いつかこれを一般公開して
プラットフォームみたいにしたいなっていうのを
思ったんですよ。
それが2015年ぐらい
そのぐらいの時って
そのちょっと前ぐらいのトレンドなんですけど
APIをとにかく公開して
色んなサービスを
マッシュアップしていこうみたいなブーンが
昔あったんですけど
その流れを受けて
データをオープンにしていくことの価値も
すごく感じていて
06:01
もし仮にスマートHRという会社が
日本の働く人のデータを
整備しきって、それをオープンにしたら
日本の社会は変わるんじゃないかな
って思ったんですよね。
それをしたいなと思って
そのまま入社しましたっていうのが始まりなんですよ。
ちょっと話を戻すと
実は僕の頭の中には
入社した当初からずっと
これをやりたいと思っていたんですね。
未だに思っております。
っていうのが始まりです。
入社してすぐにそれができたかというと
もちろんそんなことはなくて
リリースしたてだったので
あの機能も足りない、この機能も足りないという状態だったので
とにかくコアな機能を作っていくことの方が
集中していたんですが
その中でも当時かなり
自由な感じだったので
僕どうしてもAPIを作って公開したいんですよね
って言ったら
三宅さんとか共同創業者の内藤さんとか
いいじゃん、いいじゃんみたいな感じで
全部任せてくれたんですよ。
そこから自分でAPIの設計とか
仕様書とかそういうのを考えて
2、3ヶ月くらいで公開したんですよね。
そしたらやっぱり反響があって
いろんなバックオフィスの
SaaSの方々から連携したり
こういった声が上がって
連携を始めたというのが
今考えるとそれがプラットフォーム化というか
そういうのが第一歩だったんじゃないかなと思います。
ちょっとこのままいくと
永遠に喋りそうなので一旦止めて
泣かせてもらえれば
いただこうかなと思うんですけど
ちなみにそのAPIを公開するにあたって
いいよってことになったと思うんですけど
その時にこのAPIを通じて
具体的に何を達成したいみたいなところって
狙いってあったんですか?
当時はですね
なかったですね
ただもう本当に
今だったらそんな考えられないですけど
エンジニアのエゴみたいな感じで
APIがあった方がかっこよくない
みたいな感じはちょっとあったんですよ。
いろいろ連携できるだろうし
やっぱりその
RPAみたいなのもあるんですけど
ちゃんとインターフェース
JSONのインターフェースがあって
開発者が
Web APIを経由して
スマートHRを操作できるってすごく
魅力的なんじゃないかなと思っていて
むしろ無いのすごく
もったいないしダサいなと思っただけですかね
その先に広がる
数コーナーのビジネスとか
全く考えておらず
とにかく作りたいみたいな感じが
許可された
思い出があります
すごい当時のIKEAを
感じさせれるようなエピソードですね
本当に初期
シードキーならではのスピード感
と意思決定ができます
ちなみに公開して
早速反響があって
そこから少しずつ軌道修正
されたのかなと思うんですけど
その先を実際にお話があって
何か案件に繋がったりとか
しましたか
データ連携みたいなものは
定期的にお声掛け
いただいて
拒むものでもないのでやりましょうやりましょう
いろんなサースの方々と
繋がっていくんですけど
そこからアプリストアみたいな
09:01
構想になるまではかなり
年月がかかるんですよね
というのも
やっぱり
事業を伸ばしていかないといけない
ただこういう
プラットフォームみたいな
サービス連携だったり
アプリストアみたいなのは
売上に直接何か大きく関わるかというと
それが軸になることは
なくてですね
やっぱり
サースと連携できて良さそうですよ
便利そうだなとか
やっぱりそういうちょっとした
差分をつく
強みをつくるぐらいな感じなんですよね
なのでやっぱり
リソースとしてもそこを磨き込むこと
になかなか避けなかった
というのがしばらく続きます
なるほど
ちなみにいろんなサースと連携される
という時に
基本的には公開のAPIを持っていて
それを使っていただく
そうです
僕たちが追加にするとかはなくて
基本的にはこういう仕様で公開していますので
自由に使ってくださいというスタンスで
なるほど
連携先が増えるからといって
特にコストはかかるわけではない
そうです
なるほど
そこのAPIを公開して
しばらく経ってから
次のステップというのは
どういう形になりましたか
次のステップが
ちょっと間を説明すると
とはいえ僕は
アプリストアを作りたくて入社していたので
たまに言ってたんですよね
作りたいですねみたいな
すごくいいきっかけになったのが
倉橋さんが
入社された時の話で
倉橋さんが
2017年ぐらいに
入社してくださっているんですけど
面接の時から言ってたんですよ
実はこういう構想をしていって
アプリストアをいつか作っていかなきゃ
倉橋さんは面接だったので
面白いですねみたいなことを
言ってたんですけどいざ入社してみたら
面接の時言ってた
今やるのは早すぎるんですよね
みたいな感じで
ちょっと待ってくれみたいな感じになったんですよ
構想としては面白いけど
これこれこういう理由で
今は時期早消です
ちゃんと説明してくれたんですよ
当時言ってたのが
ああいうのっていうのはやっぱり
何かしらの顧客基盤なのか
何かそういうのがあった上で
初めて成り立つものなので
そっちは先に優先して
強くしていきたいっていうのを
言ってくださったんですよね
具体的には一つの目標としては
例えばARRが
〇〇ぐらいにいった時には
強硬な基盤があるから
それは乗ってくださるサードパーティーにとっても
魅力的だし
プラットフォーマーとして
スタートできるじゃないかっていう
マイルストーンを置いたんですよ
なのでちょっと
僕もすごく納得したので
じゃあそこを達成するまで待ちましょうか
って言ってたのがしばらく続くんですよ
そこから
いよいよじゃないかみたいなのが
ちょうど今から
12:01
1年半か2年前ぐらいですかね
にいよいよこれ
事業化してもいいんじゃないみたいなタイミングで
まずはどういう事業展開が
できそうかっていうのを考えるために
事業企画的な人を
採用したのが始まりですかね
はい
なるほど
事業企画的な人が入ってきて
なるほど
ちなみに
そうですね
じゃあそこまで
その段階ではまだ
セリザさんとしては
どういった形で
その
プラットフォームの価値が
広がっていくかっていうのは
そこまで明確に描けていたわけではなくて
そのCOOの
倉橋さんが入ってくることによって
徐々にその価値が
価値というか
価値が大きくなっていく
道筋が見えてきたという形なんですかね
そうですね
割とエンジニア目線の
こういうのあったらいいよねみたいなところから
きちんとビジネスモデルと
連結をして
言ううちにネットワーク効果
なんですよねアプリストアみたいな
ものの一番の強みっていうのは
そういうのを目的に
ちゃんとやっていきましょうっていう
ところとリンクしたみたいな
瞬間でしたね
なるほど
なるほどありがとうございます
ちなみにそこの
実現に当たって
アプリストアを
やっていこうというタイミングが
来てから
それが2019年ぐらいですかね
それぐらいだと思います
それぐらいのタイミングで
ちょうどプラットフォーム構想
というのを対外的にも
発信するようになるという形ですかね
そうですねちょっと正確に覚えてないんですけど
そういう事業責任者
的な人が来るより
前に発信はちょこちょこしてた
とは思いますね
いつかやるじゃろうみたいな感じで
なるほど
その時点では
僕が事前に調べたところによりますと
2018年の
Smart HR Next
というイベントで
ありましたねありましたね
あの頃はですね
まだ何もそんな細かいことは
考えてなかったと思います
なるほどなるほど
そこで事業成長の柱の
一つとしてプラットフォーム構想を
やりますっていうのを
発表されていて
実際に動いていくまでに
1年ぐらいあったというような感じなんですかね
ですねはい
ちなみにその1年間
あまり動かない状態で
時が経っていったと
思うんですけど
今事後的に捉えてみた時に
この1年間って
もっと早く巻き戻すことってできたと思いますか
15:01
いやでも
なんだかんだ適切な期間だったんじゃないかな
とは思いますかね
まぁさっきなんかARR
みたいなマイルストーン必死に立ってたんですけど
結局それも
目安でしかなくて
あんまり
結局最終的には守られてなかったんですけど
ただやっぱり
基盤をちゃんと太くしてから
っていう考えはすごくプラットフォームビジネス
する上で重要だなと思っていて
なんでこのプラットフォームに乗るのか
みたいなところの
確からしさというか
納得感みたいなのがやっぱり薄いと思うんですよね
なので
コアな事業をちゃんと成長させて
強みを作った上で
これ実はプラットフォームになるんですよ
みたいな展開のさせ方をできたっていうのは
良かったし
適切なタイミングだったと思うし
理想細分としても
すごく良かったんじゃないかなと思います
なるほど
その基盤を強固にするっていうのは
使ってくださるお客様の数が多い
そうですね
何よりも顧客基盤ですかね
僕たちのプラットフォームの場合
やっぱり顧客基盤が
一番物を言うと思っているので
お客さんの数
データの数
が一番伸ばしたかったところですね
なるほど
そこの
1年間の間で
システム的にも
進化はされてきたのかなとは思ってまして
そこの
プラットフォームを目指していく上で
技術的に
当たってきた課題とか
何かありましたか
技術的な観点の話は
またちょっと別口でして
今話したのって
割とビジネス的な観点での
時系列なんですけど
技術的な観点だとまた別のことが
並行して起こっていて
1つ
僕も過去の
動画で何回か喋ってるんですけど
結構早い段階から
将来的にこういう風に
プラットフォーム展開したいよねみたいなのを
見越した内部のアーキテクチャに
変えてるんですよね
それが
実際今もそっくりそのまま
プラットフォームに使われていたので
当時の狙い通りみたいになってるんですけど
何かというと
社内の
スマートHRというサービスで
新しく機能を作る時に
それを本体から切り出して作る
みたいな作り方をしてたんですけど
マイクロサービスと言うとちょっと
違うんですけどニュアンスとしては
例えば年末調整みたいな
機能を作りたいとなった時に
モノリシックに
スマートHRでそのまま作っていくことも
できたんですけど
それは
肥大化するんじゃないかと
という課題感から始まり
じゃあ分離させようみたいな
分離させるんだったら今APIあるし
こういう風に2つのサービスが
おしゃべりすれば
全然実現できるんじゃない
じゃあその認証はこういう風にしよう
こういう風にしとけば将来的に
これそのままサードパーティーに公開できるんじゃない
18:01
みたいな発想で仕込んでいったのが
2017年ぐらいなんですよ実は
なので社内で
当時いろんな
ことがあったんですよ
肥大化を防ぎたいっていうのもあるし
プラットフォームを貸したいみたいなのもあったんですけど
貸していきたいみたいな
課題から後付けして
これプラットフォームもいけんじゃないみたいな
発想に
正当化していったみたいなのが
正しいニュアンスかもしれないんですけど
そういう風に実は2017年ぐらいから
仕込みを始まってましたね
じゃあある種この技術的な
イシューの解決が
切り口としては
始まっていて
それが最終的にはビジネス
新しいビジネスの展開を迎えるときも
アセットが
活用できたっていうような形ですかね
そうですね
めちゃくちゃ後付けで正当化している感もあるんですけど
実際
起こっていることはそんなところですね
で
壮大なドックフーディングをしていたというか
この数年間
実際連携している社内の
アプリケーションの数が
十数個ぐらいあるんですよ
スマートHR
いろんな機能があるんですけど
実は本体が持っている機能ってそんなになくて
いろんな機能が
いろんなアプリケーションで動いていて
それがAPIを経由して
スマートHRのデータベースと連携している
みたいな感じなんですよね
なので
もしスマートHRを使っている方が
聞いてくださっている人の中にいたら
URLみたいなのを
注意して見ていただくと
面白いかなと思うんですけど
スマートHRを使っているとURLが
ドメインの部分が変わるんですよね
どっかのタイミングで
それはアプリケーションが切り替わっている
タイミングなんですけど
意外と十数個のアプリを
行ったり来たりしているんですよ
なるほど
ということは
フロントエンドのアプリケーションからしては
分かれているみたいな感じですか?
分かれています 完全に独立しているんですよね
ちょっと
開発に踏み込んだ話をすると
内部的にはそれらを別のチームで
作っているんですよ
1アプリケーション1チームみたいな感じで
本当に
サードパーティーの人たちが
これを作ったらみたいな感じを
想定できるような感じで
組織的にも構成されていて
結果的に
それが
かなり後付けかもしれないですけど
有名なコンウェイの放送と
プロダクトと組織が一致していくみたいな
あれにも
沿う形になり
すごい良い感じになっていったんですよね
スケーラビリティが担保されるし
一つ一つのチームと
プロダクトが小さく保たれるし
かつそれが最終的には
プラットフォーム事業にも
伸びていくみたいな感じで
すごい
コンボが決まった
めちゃくちゃ美しい
話ですね
21:01
今考えると
そんな感じです
すごいですね
プラットフォームを
作っていく上で
まさにビジネス的な
要求がどういうところで
顕在化していくか
とかプラットフォームが
実際どういうニーズに
跡を当てていくかっていうのって
かなり難しいというか
プラットフォームである以上
後から軌道修正するのも
難しかったりっていう
課題があるなと
自分がプラットフォームを作っていて感じるんですけど
そういった問題に対しても
内部で盛大な
工夫をしていることによって
対処できているっていうのは
すごい美しい形だなと思いました
投資する価値がきちんと
当時からあったっていうところは
あると思います
プラットフォームビジネスってさっきも言った通り
ネットワーク効果を作るみたいなところが
主目的になりがちで
計測がすごく難しいんですよね
ROIが測りにくいというか
どれだけネットワーク効果あるの?
測るのすごく難しいですし
定量的に
そういう
それが分かりにくいけど
実際内部的にもこれぐらいのメリットが出るし
みたいなのがあると
着手しやすいだろうなと思うんですね
なるほど
これを推進していくにあたって
経営チームでも結構
いろいろ議論されたかなとは思うんですけど
どこまで
確からしさを
議論しつくす感じなんですかね
ある種
一定まで議論したら
どこかで誰かが強くスタンスを取る
っていう形になるのかなとは思うんですけど
当時はどんな感じでしたか
じゃあちょっとマイクロサービスっぽい
風にしましょうかみたいなところからですか
経営判断としては
その時は特に何もなかったですね
エンジニアチームとして
やりたいという判断になったし
やればいいんじゃない
ぐらいの感じでしたね
特にそれで何かが大きく
遅延するみたいなところも正直なかった
んですよね当時のスピード
観測的にも
まあ上手く考えるとすごい重大なアーキテクチャの
意思決定しているような気がするんですけど
当時はあんまりなかったんですよ
正直その経営会議に図るみたいな
のがなくてですね
もう勝手に現場で
よしみたいな僕も当時
VPOEかなってやっていて
全然これはいいはずだみたいな感じで
意思決定してましたし
当時の
してはそんぐらいの感じでした
なるほど
それはある種あれなんですかね
そういう
経営に影響を与えるようなトレードオフを
発生させずにこれを推進できた
っていう風にも
捉えることができる
あると思います
僕また当時の資料を
拝見してるんですけども
このスライドは
スマートHRの開発現場
24:01
最新事情っていうのを
2018年7月に
公開されてまして
マイクロサービスを始めましたっていう
懐かしいですね
これはいはい
覚えてますよね
レイリッドデベロッパーズミートアップですね
懐かしいですね
その当時に
抜本的な見直しと
要望の多様化っていう
2つが左右に並んでいて
どちらも設立に
やってほしいっていう
やってほしいが社内に爆発してるみたいな
スライドが途中に
入ってたんですけど
そういう状況もありながら
このアーキテクチャの
移行も段階的に進めてきたっていうのは
すごい
すごいなって思いましたね
そうですね
確かに今考えると
時系列的には
ちょっと後付けだったかもしれないですね
もしかしたら
これより前に
こういうビジネス的な
ニーズを作ってくれ
っていうのが
来る前ぐらいから
マイクロサービス始めてたんで
結果的にそこに乗れたみたいなところはある
そんなに
見越してなかったです
マイクロサービス第一歩目を
組み込んだ時に
まさかこんなにいろんなことが解決できるとは
みたいなのを
やってくうちにびっくりしたみたいなのが
正しいニュアンスかもしれないですね
この流れに弊社も乗りたいです
はい
ちょっと
それを支える組織的な話も
聞きたいなと
思ってまして
まさにその
プラットフォームを開発するチームと
そのアプリケーションを開発するチーム
というのが今もあって
アプリケーションを開発するチームが
十数個と
先ほどおっしゃっていたと思うんですけども
その別れ始めた
タイミングっていうのはまさに
2017年、2018年ぐらい
ですね
ちょうど開発者の数が十数人になってきて
いわゆるピザの法則とか
あるじゃないですか
あそこにぶち当たっていって
なんかこううまく
スクラムも回せなくなってきたよね
っていうのがあったんで
アプリケーションを分けたし
チームを分けましょうかっていうタイミングでしたね
うーん
なるほどなるほど
そこにあたって
移行していくときに
苦労したポイントとかってありました?
あ、でも結構
ありましたね
過渡期だったんですけど
複数チーム化される
それまで一つのチームで
みんながこう
情報共有とかそんな苦労せず
やってて
VPOEだったんですけど
平和だなと思ってたんですが
チーム分けるといろんなことが起きるんですよね
やっぱ最初に
27:00
顕在化するのが
あっちのチームでやってること分かんない
みたいな感じなんですよ
なんかもう一気に分かんなくなったよね
とか今あんな開発してるんだ
みたいな風になるんですけど
これ僕も
確かにちょっと危機感を感じてたんですよね
情報共有って難しいな
みたいな思ってたんですけど
今考えるとなんですけど
結構その情報を
全て知りたいということに対して
こだわりが強すぎた
というか
ちょっと潔癖じゃないですけど
なんで俺はこの情報
知らなかったんだみたいな
敏感になりすぎていたんじゃないかな
みたいなのは正直あって
今となっては
十数個チームがあるんで
全てを知ることなんてそもそもできないんですよね
なんか
将来のスケーラビリティというか
スケールしていくことを
想定すると
ある程度許容していくしかなかったんだな
っていうのはありますね
情報が分かんなくなっていく
ただその
チームが初めて別れて
これからこうなっていくぞみたいな
過渡期においてはすごく過敏になってしまうので
自分自身
含めてどう付き合っていくか
っていうところはすごく苦労したのを覚えてますね
なるほどなるほど
その情報を
より多く知りたい
っていうところに対して
諦めをつけるしかないとは
思うんですけど
それに当たって
情報量を落とすに当たって
何を残して
何を諦めるみたいなところって
線引きとかありましたか
明確な線引きはなかったんですけど
これは知らなくても
別に
害ないよねというか
知っても何もできないよね
みたいな情報っていうのは
経験則的にみんなで学んでいく
みたいなところですかね
全エンジニアが集まる
定例みたいな
今もやってるんですけど
そういうのをちゃんと設けて
必要な情報はそこでシェアしましょう
みたいな機会をまずは場を作って
そういうのを繰り返していくと
ちゃんと必要な情報はこの定例に出れば
キャッチできるんだな
みたいなところが分かってくるし
受信する側はそうですし
発信する側も
発信しておこうみたいなことが
学んでいけるんですよね
それがチームに文化として根付くことで
信頼もできるし
安心もできるみたいな
そういうのを時間をかけて
調整していくみたいな感じ
ある種その場作り
例えばいろんな部があったとして
部あたりに何分という時間があって
その部とかが
外に対して示すべきことを
示していくことが
部にとってもいいしみんなにとってもいい
そういうのが徐々に
調整されていく感じなんですかね
そうですね
特にルールとかこういうのは絶対共有してください
みたいなルールは明文化していないと思うんですけど
ちょっと僕
30:01
シティを離れて結構立つんで
今どうなってるかちょっと把握できてないんですけど
やっぱルールで縛るというよりかは
そういうカルチャーを作っていく
みたいなのに当時は
こだわっていましたね
なるほど
ありがとうございます
ちなみに
ちょっと話変わるんですけど
今プラットフォームチームとアプリケーションチーム
という
立て付けになる分類が
できるかなと思ってまして
そこにおける
なんていうんですかね
連携のプロトコルみたいな
やつって決まってますか
っていうのが
もともとAPIがあってそれを使って連携する
という形ではあると思うんですけど
例えばこのAPIにこういう
機能がないとかこういうフィールドが足りないから
この機能が実装できない
みたいなものが
発生した時に
そのチーム間でどういうコミュニケーションを
持ってその解決に
動くみたいなものって
カルチャーとして決まっているものとかって
あったりしますか
結構ケースバイケース
な気がします
APIだけを
作るAPIを作る専属のチームって
なくて
APIは僕らが
スマートHR本体って呼んでるんですけど
本体の開発している
チームが
一緒に見るみたいな
感覚だったんですよ今までって
なんでアプリケーションを
作るような人たちが
僕たちがプラスアプリって呼んでるんですけど
プラスアプリを作るような人たちが
こんなAPI足りないですってなった時に
簡易的なちょっとした
アトリビュート足すぐらいだったら
クルリ繋げていいですよみたいなコミュニケーションになるし
新しくエンドポイント増やしたいとか
そういう感じになると
ちょっと一回話し合って
誰がどう作っていくか決めましょうかみたいな
風になるっていう
スタンスですね
なるほどなるほど
そういうコミュニケーションの中でも結局
スマートHR本体の
本体のほうが
オーナーシップを持っている
開発チームがあって
そこの人たちが
合意できるというか
受け入れ可能な形で
最終的には合意が取られる
という形なんですかね
ですねはい
なるほど
理解できましたありがとうございます
まさに我々の
プラットフォームっていう中でも
そこのチームの分割を
進めてきているんですけども
やっぱり本体として
分割当初は
機能が足りないということを
大々にしてありそうだなと思っていて
そこに対して
とはいえ
そのアプリケーション側のチームが
やみくもに開発していくと
それはそれで
本体に対するオーナーシップ
というかガバナンスが
聞き切らなくなってしまうことも
あるのかなとは思ってまして
そこら辺のところが
気を付けなきゃいけないポイントなのかな
というふうに認識しました
33:01
ちょっと今のところ
踏み込んで話すとすごく難しいんですよ
これって
僕たち最初にパブリックに公開する
APIを作ったのが入口だったので
パブリックAPIというのがずっと
存在していたんですよね
当初は無邪気だったので
パブリックAPIを育てていけば
あらゆるアプリが作れるんじゃないか
みたいな発想をやっていたんですけど
最初にぶち当たるのが
これちょっと一般公開するの怖くない?
みたいなものに来るんですよ
それは何かというと
情報としての機密性が
高いんじゃないか
そういうのがあったりとか
あとより多いのが
スマートデジタル本体でも
その機能ってまだ活発に
開発されていて
広報互換性のない
変更が入る可能性が高い
カラム削除されるとか
そもそもリレーション変わる
なった時に
これAPIで一般公開しちゃってると
ちょっと怖いよねみたいなのがあったりします
なので
何が起こるかというと
パブリックじゃないプライベートなAPIが
出始めるんですよね
結果としてプライベートなAPIが
めちゃくちゃ育っていくんですよ
その次に何が起こるかというと
なんなら
レストから外れるような
エンドポイント欲しいみたいな
アプリケーションが出始めてきて
次に
プライベートAPIをみんなで共有して使ったんですけど
社内で
次にアプリケーション個別のエンドポイントができたりするんですよね
すごい
カオスになってきていて
ちょっとそのツケが回ってきつつあるんですけど
ぶっちゃけプライベートで
やる分にはそんなに
影響ってないんですけど
今このプラットフォーム
みたいなところを大々的に公開し始めて
サードパーティーベンダーを
開発するときに
プライベートのAPI
サードパーティーに公開するんだというか
そういうところがついに
ここと向き合うときが
きたかみたいな
感じで
やっぱりAPIってそこら辺が一番
難しいですし
インターフェース設計の醍醐味だなみたいな感じは
思いますかね
なるほどなるほど
確かにそうですよね
我々もその
パートナーと連携する
みたいなときがあって
プライベートよりもパブリックよりは
変更しやすいけど
本当に自社だけのプライベートよりは
変更しづらいみたいな
感じになっていて
そこの進化の仕方みたいなやつ
すごい気をつけなきゃいけないな
本当はまさしくそんな感じですね
これがAPIを
提供していくことの
難しさですよね
確かに
さっきその話を聞いていて
APIがパブリックな
素朴な状態から始まって
いろんな種類が増えていって
ある種生物の種の
爆発みたいな感じになって
それで最終的に
プラットフォームとして収束していく
フェージングが
36:01
興味深いです
ありがとうございます
結構
いろいろ聞かせていただいたかな
と思いまして
時間も結構
経ってきたので
そろそろ締めに
入ろうかなと思いますが
最後に
今
我々
10Xがまさに
2018年
ぐらいのスマートHRと
同じぐらいの
フェーズかなと思いまして
これからまさにアーキテクチャを
徐々に移行していくぞだったりとか
プラットフォーム化に向けて
いろいろなアセットを作っていくぞ
という段階かなと思っていまして
最後に聞きたいこととしては
今
当時に戻れたとして
これは先にやっておけばよかったな
みたいなことが
もしあれば聞きたいなと思いますが
何かありますかね
難しいですね
もうちょっと
相反すること
今から2つ言うんですけど
APIを公開していても
それはそれで面白かったんじゃないかな
という時はありますかね
エンドポイント増えるとできることが増えるんで
乗ってくる連携
の可能性が単純に広がるじゃないですか
そういうのは
もうちょっと早くからやってても
よかったんじゃないかなと思う
一方で
本当に2016年に
APIを作って公開している通り
早かったせいで
APIを意識するんですよね
この辺を入れると
APIの広報互換どうやって保つんだっけ
みたいな議論が
要所要所で起こるんですよ
ここでやっぱり
足枷になる時とかもあったりして
そこのバランスが
非常に難しく
正解がないので
今戻って何をやり直せるかっていうのは
非常に難しい判断なんですけど
もうちょっと
APIと
真摯に向き合うような
人たちがいてもよかったのかな
さっきも言った通り
スマートHR本体の開発の片手間で
APIを
片手間って言ったら非常に申し訳ないですけど
メインストリームではないんですよね
APIの開発っていうのが
みんなが必要に応じて
APIを回収していくみたいな感じだったんですけど
もうちょっと
APIってこうだよねみたいなポリシーを作った上で
育てていくみたいなことが
できたらよかったかもしれないな
っていうのは
知れないですね
なるほどありがとうございます
そうですね我々も
この
両立の
どこのバランスを取っていくのかっていうのを
自覚的に選択していきながら
進んでいきたいなと思いました
ポリシーが
すごく重要だと思います
僕も2016年に作った後
正直作って
よかったよかったみたいな感じで
そっからまたメインストリーム開発に戻っちゃったんで
39:01
そっからオーナー不在の状態が
すごく長く続くんですよね
ただやっぱりAPIって一回作って
使われ始めるとそっからはもう
成長し続ける
ものなので
止められないんですよね基本的には
なので
そういったAPIの特性を踏まえて
ポリシーなのかオーナーなのか
そういうのを明確にしておくと
一つ安心だし道を
踏み外さなくて済むのかな
っていう気はしています
なるほどありがとうございます
いやー今回
非常に勉強させて
いただいて
今後の授業に
活かしていきたいなと思いました
何参考になるのか
僕の
頭の中にあるプラットフォームと
APIの3分の1ぐらいしか
話せなかった感じがあるので
もし
機会があればまた
お話はできるんですけど
おー
またぜひ
機会でも聞かせてください
ありがとうございます
そろそろお時間も迫ってきた
というところで
締めに入りたいと思います
今回
プラットフォームを
まさに始めたTENXと
プラットフォームをこれからまさに
本格化させていく
スマート1Rさんのお話を
聞かせていただいたという形になります
最後にもし
セルダーさんの方から
告知したい事項があればぜひお願いします
はい
僕らが告知したいことは
唯一
採用です
どこの方でも申し訳ないですけど
今はここまで
お話ししてきた通り
プラットフォームがついに事業化して
今は推進し始めているんですよ
今年の8月についに
ベータ版をプレス
出すようなことができたんですけど
もっともっとこれを広めていきたい
と思っています
パブリックなAPIを
もっと増やしていくというのもそうなんですけど
もっと
JSONのWeb APIに限らず
いろんなインターフェースって
考えれると思うんですけど
何がサードパーティーに乗ってうれしいのか
どういうインターフェースがあると
より深い連携ができていくのか
というのを考えながら
APIをすごいスピードで
成長させていくことを
しようと思っていて
かなり設計難易度の高いような
ところの
ものが増えてきているんですよね
かつプラットフォームなので
例えば今後課金基盤を回収したりとか
認証基盤を回収したり
みたいなものもあると思うんですけど
そういった基盤に関わるところの
開発案件というのが
増えてくると思っています
なのでスマーティーチャルって今までは
どちらかというと
技術業務に関わるものを
DXしていくような機能を
メインに開発していたんですけど
それもやりつつ
インターフェースみたいなところも
基盤を作っていくみたいなところも
42:01
始まっておりますので
ぜひそういったところに興味のある
エンジニアの方がおりましたら
ご応募いただけるとすごく助かるなと思っておりますので
ぜひよろしくお願いします
スマートHRに興味のある方
これからすごい機会が広がっていくと思うので
ぜひ検討いただければなと思います
TENXの方は
まだまだ未熟なフェーズなんですけど
そっちの方も
もし興味がある方がいたら
ぜひよろしくお願いします
では今日はそんなところで
以上で終わろうと思います
セレナさん今日お時間いただき
どうもありがとうございました
こちらこそどうもありがとうございました
