00:02
LayerXのポッドキャスト、LayerX NOW!ですが、
今日はいつものホストのYMOSさんではなくて、
番外編としてLayerXインボイスというプロダクトを今、弊社で開発していて、
その開発の裏側みたいなのを話せたらなと思います。
LayerXインボイスNOW!と題して、
LayerXインボイスの開発メンバーで、
プロダクトとチームについて話していければと思います。
はじめに自己紹介ですが、
LayerXインボイスでテックリードを担当している
エンジニアの中川佳樹です。
そして今日は、エンジニアでもあって、
プロダクトマネージャーも兼任している
花村さんと一緒に収録できて、
していければと思います。
では、最初にまず花村さんから
自己紹介お願いできればと思います。
はい、今紹介いただきました花村です。
よろしくお願いします。
お願いします。
はい、自己紹介としましては、
大企業から無職までキャリア的には経験しておりまして、
最初はITコンサル兼SIみたいな会社にいて、
そこから大きい製造業とか、
業務、40年ぐらい前からやってるホストコンピューターを
全部入れ替えて、業務改革もするみたいなプロジェクトで、
4年ぐらいずっと引消しをやってたみたいな、
ファーストキャリアですね。
ウェブ業界では珍しいかもしれないです。
そこから、
データ分析の道に行ったりだとか、
あとは監査法人でですね、ブロックチェーンの仮想通貨の
データ分析をするソフトウェアを作って、
監査法人の中でソフトウェアのチームを立ち上げる
みたいなことをやったりとか、
あと起業してブロックチェーンのモニタリングのサースを作ったり、
その後、フリーランスでフラフラしてるところに
レイアクスが声をかけてもらって入社したというところですね。
インボイスでは、プロジェクトマネージャーから開発、
あとカスタマーサクセスのところとかも顔を出したりしながら、
結構マルチにいろいろやってるような感じですね。
そうですね、花村さんは最初は割とガップリブロックチェーンの
去年とかプロジェクトガップリ参加してましたよね。
そうですね。
もう2年くらい、2017年の6月くらいからブロックチェーンをやっていたので、
レイアクスのブロックチェーンやる気満々で入ってきた感じです。
なるほど、なるほど。
今はラボではなくTX事業部って形でやってるって形ですもんね。
そうですね。
花村さんはプライベートでもブログとかを割と書いてるじゃないですか。
はい。
あそこらへんっていつもいつ書いてるんですか?
すげえ気になってたんですよね。
いや、土日とかですね。
03:01
割と書いてる内容はブロックチェーンのこともあれば、
TXとかそういうのも関連していることもあって、すげえ多岐にわたってますね。
そうですね、趣味に関連すること。
それがいつもすげえ。
というか何かいつの間に書いてるんだかちょっと気になってます。
読む度に。
ありがとうございます。
でもTXに関することは結構業務上で学んだこととか、
そういったのを言語化することが多いですね。
すごい印象的なのは、やっぱ去年TX事業部みたいなのが始まったときに、
やっぱ2Cのメンバーが非常に多かった。
そのときに花村さんが、
業務システムとか機関システムってこういうふうに動いてるみたいなのを
スライドで作ってくれて、
チームとエンジニア陣に話してくれたというか、
ちゃんと資料を作って教えてくれたみたいなことがあって、
それがすごい最初印象に残ってて、
2Cのプロダクトの考え方と全然違うんだみたいな、
SOEとSORってこういうふうに変わるんだみたいなのが
すごい実体験とともにわかったのが印象的でした。
そう言っていただけると嬉しいですね。
聞いてる方向けに話をすると、
60枚くらいのスライドで、
2Bと2Cこう違うよみたいな話をしたんですよね。
過去の炎上の経験とか、
こういうことしたら失敗するよみたいなこととかを
ワーッと書いて、
あとホストコンピューターの入れ替え方みたいな話とかも
書いていただいて、
なかなかこうどういうステークホルダーがいてとか、
どういうふうにこう機関システム感がつながるかとかって
いうのが全然イメージできてなかった。
チーム全体としてイメージなかった段階だったんで、
そこはなんか一番印象に残ってる。
去年とかだとありますね。
良かったです。
吉木さん2Cでずっとやられてきたんですよね。
そうですね。
私は大学の時から一応
AdTechとかの会社にはインターンとかではあったんですけども、
がっつり2Cの会社がメインで、
フリーランス、私も花宮さんと同じでフリーランス経験してたんですけど、
その時も結構知り合いずれてくる
2Cのサービスだったりを
担当するのが多かったので、今回こういう
LXインボイスみたいなすごいがっつり業務の中に入って
使われるアプリケーションを作るっていうのは
初めてだったので、結構すごい新鮮でしたね。
最初はやっぱり。
こういうふうに全く業務わかってないけど、このまま開発進められるんだろうか
みたいな不安は常にありましたね。
開発初期の頃は。
Webエンジニアってやっぱ2Cが結構これまで
花形みたいなところがあったじゃないですか。
そうですね。
そこから2Bに移ってきて、
逆に地味ではあるし、業費的には。
あとは考え方も結構違うと思うんですけど、
その辺どう目線って変わりました?
06:00
そうですね。
ドメイン知識自分で入れていくしかないっていうのは
僕は感じましたね。
チーム内に元経理のメンバーとかがいるので、
そういう人に聞いて、
こういうふうにこの業務回してるとか、
なんでこの業務必要なんだっけみたいな話を
すごい初歩的なことから最初学んでいったのが
あるかなと思いますね。
花村さんは、
前出演職とかは監査とかの会社にいたりもしたと思うんですけど、
そういうのって最初ってどういうふうに
ドメイン知識のキャッチアップみたいなのは
始まるんですか?
確かにそうですね。
監査やったことなかったけど、
監査の仕事をしたりしましたからね。
最初はオンボーディング的なのが会社であって、
みたいな形なんですかね?
2週間くらいEラーニングみたいなのがあったけど、
でもそれも法律を丸暗記しろみたいな
そういう話だったので。
なんですかね、
でも予定みたいなのが結構あって、
監査と目的って
悪さをさせないことなんですよね。
紛失させないためにどこを見たらいいのかみたいなポイントが
アサーションとかって言うんですけど、
そういうのが結構整理はされてて、
要はそこの要点だけ抑えて、
あとは会計士の現場の人に話を聞きまくって、
それで自分なりに整理するみたいなことをやってたら、
大体、
僕は会計士試験を受けても浮かんないですけど、
なんとなく会計士の方がそれなりに話をすることができるようになったって感じはありますね。
すごいですね。
監査とかってやっぱり法律と向かい合わなきゃいけないじゃないですか。
そこら辺はもう、
Googleというか調べることっていうのはどういう形で調べてたんですか?最初って。
社内のドキュメントとかですか?
社内のドキュメントなんですけど、面白かったのは、
第三者委員会報告書っていう、
悪さを不正したら、
50ページぐらいの文章で出てきたりとかするんですよね。
それの不正会計の事例をたくさん調べて頭に入れとくと、
こういう悪さの仕方あるよね、ここリスクだよね、みたいなことは、
結構勘につくようになったんですよね。
なるほど。
セキュリティを学ぶのって、ハッキングのやり方とかを勉強するみたいな話じゃないですか。
縦と方向があったら、
方向側というか攻撃側を少し学ぶと見えてくる場所があるという感じですね。
そうですね。
監査とかそういう経験もやってきて、
今のE-Voiceに繋がることってあったりしますか?
プロダクトの開発の経験としては。
09:03
直接はあんまりないんですかね。
開発経験っていう意味だとあんまりないですけど、
会計知識は基本的には繋がるのと、
あとは何ですかね、
業務を全体でフローとして見れるみたいなところって、
結構監査に限らず、コンサルとかSRやってた時の知見はすごい役に立ってる気がしますね。
やっぱりそうですね、このReact E-Voiceも開発していて、
請求書の業務ってどこから始まるんだっけ、
みたいなことから整理していかないと。
最終的に会計ソフトに入るところまで作っていくみたいなことを、
整理していくっていうのはすごい大事だなって、
開発してきて思いますよね。
そうですね。請求書も経理の方が受け取るパターンと、
現場の方が受け取って経理の方に渡すパターンと、
あとは経理の方が受け取るけど現場の方に承認するパターンと、
いろいろ業務フローって会社によってバラバラじゃないですか。
そうですよね。
みたいな話を考えて、
じゃあそこをプロダクトでSaaSとして、
カスタマイズは基本しないじゃないですか、私たち。
そうですね。
しないけれども、
汎用的にいろんなところに入れられるように対応していく。
とはいえ何でもできすぎるとそれはそれで
UXが悪くなっちゃうので、そこのバランス取りながらみたいなのは、
やっぱりいろんな業務フローとかいろんなステックホルダーが
どういうふうに作業してるんだろうみたいなことを
イメージするってすごい大事かなって思います。
そうですね。SaaSとそれ以外を少しだけ整理すると、
花村さんは新卒で入った会社のSIとかっていうのは
割とカスタマイズされた機関システムみたいなものが多かったっていうイメージですかね。
すでにあるものって言うか、それとも作るものですかね。
作るものですね。
作るものは、
そうですね、ERPとかも使ってはいるんですけれども、
基本超大企業で業務がものすごい複雑なんですよね。
かつ、あんまりありものを入れるのを良しとしないみたいな会社ではあったので、
スクロッチで結構作ってましたね。
そこはSaaSとは正反対の考え方というか、持ち方ですよね。
両面あると思うんですよね。
よくシステムに業務を合わせろとか、そういうのは言うじゃないですか。
それはそれで一つ正しいんですけど、
でも一方でベストプラクティス業務のやり方みたいなものってあるはずなので、
じゃあそれを全部捨ててシステムに合わせろっていうのも、
それはそれで何か違う気はしてて。
難しいなって思いますね。
12:04
とはいえ、始まったばかりの会社だったりとか、
そこまで人数的な規模が大きくない会社で、
いきなりスクラッチのシステムを作っていくっていう体力はなかなかないので、
そこら辺はSaaSとかがうまく浸透していければいい会社かなっていうのはすごい思いますよね。
めちゃくちゃ思いますね。
それこそ売上10億ない会社の方とかで、
じゃあ内製のエンジニアを10人取ろうとかって絶対無理じゃないですか。
そうですね。
それをスクラッチで作っていこうっていう形にはならないですもんね。
そうですね。
でも10人のエンジニアが常に改善しているSaaSを入れることは月額数万円でできるっていうのは、
ソフトウェアの民主化としてはすごい良いものだよなとは思いますね。
やっぱり今は私も花村さんもインボイスを開発していて、
SaaSって形で開発してるとカスタマイズというか、
どこまでこしゃこしゃの事情というか要望を叶えていくかっていうのは、
毎回今でも難しいところですよね。
本当に難しいですね。
全部に対応はできないので。
そこら辺、花村さんがプロダクトマネージャーになる前から、
始まった当初からかなりセールスのトライアルとかも入っていったり、
あとはカスタマーサクセスもやって、
ずっと今までやってきて、
どういう風な思考というか、
最初これ厳しいなみたいな要望をもらった時の初手というか、
そういう風に落としていくのは型みたいなのが決まってきたりしたんですか?
すごいざっくりな質問ですけど。
そうですね。
作れるのが一番ですけど、
作らないで何とかする方法とかっていうのはやっぱり考えますよね。
なるほど。
かなり花村さんはサンプル数を取るというか、
数を取ることは意識的にやってるのかなと思いますね。
一社だけというよりかは何社かちゃんと事情を聞いて、
それを満たせる複数社を一つの使用というか機能として実現できるのを
意識してるのかなとかっていうのは横で見ながら思ってたりするんですけど。
それはそう言ってもらうと嬉しいですね。
結構こういう動きは心がけてるので。
でも割とみんなそう、
結構みんな言われたものそのまま作らない人が多い気がしますけどね。
確かにそうかもしれないですね。
もちろんこう、
やっぱり普段使ってる人が接してる業務というか、
こういうふうにやらなきゃいけないんだみたいな、
ある程度ちょっとは固定化してる考えみたいなのもあったりすると思うんですけど、
こういうふうに解決できないかっていう提案とかは確かにやったりはありますもんね。
ありますね。
そうですね。
なかなかそれがフィットするかどうかは難しいところではあるんですけど、
15:03
結構意識的にそのまんまで作り続けていくと、
確かにプロダクトの発端みたいなことがやっぱり来るかなという気がするので、
大事ですよね、そこは。
ありますね。
セールスの方とかもなんかすごいなと思うのは、
ITでこういうツールを使うのに慣れてる方とかは、
ユーザー、お客様の方からこういうことできないかって言われて、
他のサースを組み合わせたらできますよとか、
Zapierを組み合わせてAPI連携したらうまいこといけるみたいなこととかを、
なんか普通に提案とかしてくれたりとかするので、
なんかそういうのができない方って、
作ってください、作れ作れっていうふうにエンジニアにすぐ言うと思うんですけど、
ある種みんなエンジニア的そういう思ってるので、
よしないんやってくれるなっていう気がしますね。
そうですね、結構問題解決の方法が、
さっきも花村さんおっしゃってましたけど、
作らないというか実装だけで解決しないっていうのは、
なんか意識的に取り組めてるイメージが少しありますね。
あとはそうですね、
最近のこうプロダクトマネージャーとして始めてみて、
結構こう優先度とか、
何かしらこうタスクで困ってることはあったりするんですか、
花村さんの中で。
いや優先度は常に難しいですよね。
何から作っていくかってことですね。
そうですね。
いやちょっと2Cがそんな分かんないんですけど、
2Bってユーザー数が2Cほど多くないから、
データがパパッと取れないんですよね。
だから何ですかね、
2Bって多かったイメージあるけど、
実はめちゃくちゃエモいなっていう気はしますよね。
エモさですか。
エモさが。
どこら辺ですかそのエモさっていうのは。
いやなんかこれ作って、
本当に使われるかどうかっていうのは、
分からないじゃないですか。
そうですね。
使われる機能かどうかってことですよね。
ユーザー数が1万人とかいったら、
ぽんと出して、
それでデータ取って、
取り下げるみたいなこととかもできる気はするんですけど、
なんか我々まだ1万社とかいないので、
だからユーザーに普通にヒアリングして、
こういう機能あったらどうですかとか、
こういう画面とかだったらどうですかみたいなモックみたいな話をして、
数もそんなめちゃくちゃ聞けるわけではないので機能もあるし、
18:01
だからそういうところから反応を伺って、
でその反応を見て、
じゃあこうしたらやっぱり良さそうだとか、
これはちょっとやってみて出してみて、
汎用的にいろんなところにやってみようみたいなっていうのが、
なんかすごいエモいというか、
本当個人の感覚みたいなところにも委ねられてるなっていう気はしますよね。
そうですね、サンプル数で確か1万人とか1万社が使ってもらえるっていう形ではまだないので、
難しいですよねそこは。
難しいですね。
2Cの考え方としては、
フェイルファスト&スモールみたいな形で一座を小さく作って出して、
少ないユーザーでもいいから使ってもらって、
失敗したら失敗したらそこから直していくとか、
そういうのが割とイメージがつきやすいですけど、
いきなり2Bのサースで、いきなり業務で、
試験的に作ったんで使ってみてくださいっていうのも、
なかなかお願いしづらいというか、
それを客社とか専者の人にいきなりお願いするのは、
かなり勇気がいる判断になります。
そこはやっぱり変わりますね。
そうですね、微妙なのが、
いけ、その、
失敗したけど一社で成功しちゃったとかがあると、
すごい怖いですね。
そっちでうまくいくパターンも怖いですね。
取り下げられないんですよね。
確かにそうですね。
また別件にはなるかもしれないですけど、
一度出した機能を簡単に下げるってことが、
業務に組み込まれていると、
その会社にとってすごいクリティカルになる可能性があったりするので、
そこも多少、
慎重な判断が必要な箇所でありますよね。
間違いないですね。
今はあれですね、
3ヶ月とかはこの辺のテーマをちゃんとやっていこうって、
作りたいものっていうのは、
要は実現したい業務フローだなっていう風に、
自分の中で頭の整理がついてきたので、
例えばこういう、
業務フローを想定した機能、
それを実現するための機能を作って、
後から振り返ったときに、
そういう業務をやっているユーザーに、
業務の中で使われたかっていうところを、
自己指標としてきちんと見ていく。
1個乗ったら結構他のところにも横転はできやすいので、
そうなると価値なんだろうなと思って、
エモいながらにテーマは設定して、
業務フローを作って、
それを実現して、
実現したい業務フローを言語化してやってっていうので、
優先度とかつけていってますね。
結構、
花村さんがロードマップというか、
プロダクトのマーケティングのマップとかを作ってもらったときに、
21:01
やっぱり、
IT業界とかウェブ業界にずっといると全然知らない、
原価が必要な売り店だったりとか製造業だったりとか、
あとはその会社の規模ってどれくらいなんだっけとか、
見る指標が今まで自分の視点になかったものだったので、
そこがすっきりしたというか、
イメージとしてチームで持てるようになったのが、
ロードマップをもらったときに、
一番印象に残っていることだったりしますね。
あそこもあんまり、
ネットにどういう記事があるとかっていう話でもなかったりするんですけど、
結構、本とかで調べて自分で作っていった感じなんですよ。
はい。
いや、もう本にも載ってないので、
ユーザーに説明するしかないですね。
今までセールスの方とかが撮ってくれた議事録とか、
録画とかそういうのを見ながら作っていくって形ですよね。
そうですね。
録画したり、録画見たりとか、
あとは普通に同席させてもらったりとか、
そうですね。去年とかだったら、
今はフルリモートに近い形ですけど、
去年とかだったら直接ユーザーのところに行って、
いろいろ聞いていたから、
その辺の貯金もあったのかもしれないですね。
やっぱり去年とかは、
プロダクトをやっと動くものができたみたいなところだったので、
割と自分たちの近くにいる会社で、
IT業界とかWeb業界の会社さんが多かったですけど、
もう今年入ってからというか、
そこはもう何ていうか、
全く接点のない会社とかが増えてきたので、
やっぱり最初は戸惑うというか、
業務どういう形でやっているのか、
あんまり想像がついていなかったですけど、
やっと見えてきた感じはちょっとあります。
そうですね。
またどんどんいろんな業界に踏み込んでいくので、
また新しいマーケットで、
新しい体験をしていくんだろうなという気はしますね。
また、
話というか、
うかがいする企業の規模とか人数が変わると、
また全然違う視点というか、
必要な機能みたいなのが出てくるというのはありそうですね。
ありますよね。
どうですか、逆にテックリードをやられてみて。
そうですね。
去年から開発を始めて、
自分として変わったことはあまりないかなと思っていて、
割とエンジニアも結構、
仕様の段階から入っていく人が多いじゃないですか、
今のチームだと。
そうですね。
タスク管理ツールに1行2行だけ書いてあって、
吉谷に作るみたいな。
自分でどういうふうに業務が当てはまるシステムというか、
機能を作っていくかみたいなのを、
各エンジニアが考えながら作っている箇所があったりするので、
24:00
あまり自律的なチームだなというのはすごく感じるので、
そこまで意識することはないかなと。
コードレビューとか、
本当にエンジニア視点のことに関しては、
もう少し時間とか使っていきたいなというのは、
少し思っていたりしますね。
基本的というか、
初歩的なあれしかないですけど、
一番メインかなと思いますね。
これから多分チームがどんどん拡大していくと思うんですけど、
コードレビューとかして、
チームスケールするように、
エンジニアの
なんですかね、
エンジニアの働く環境というか、
インフラみたいに整えていくみたいな、
そういったところですかね。
そうですね。
さっきも言ったんですけど、
エンジニアが仕様を考えたりする面が大きかったりするので、
ドメイン知識というか、
どういうふうに業務が動いているかという改造道、
みんなの改造道をどうやって上げていくかみたいなのは、
割と重要かなというのは思っていますね。
そこはもう、
テックリードとかそういうことは全く関係なくて、
どんなことなんだろうなというイメージはありますね。
確かに。
どうやって上げたらいいんでしょうね、こういう。
そうですね。私も花守さんも、
プロダクト始まった段階からいるから、
最初に何で始めた人がつまずくかみたいなことが、
少し自分事としてわからなくなっているところはありますよね。
そうですね。
慣れてきてしまうとそうなってしまうので、
最初に入ってきた人のフィードバックというか、
ここ改造道が全然高くならないというか、
そういうところはキャッチアップして、
拾っていかないといけないんだろうなというのは感じますね。
そうですね。
うまいことそういうフィードバックで答えていって、
慣れじきをできるみたいなのはやっていきたいですね。
すごい話を戻しますけど、
花守さんは最初に入った時から、
ある程度経理の業務の改造道ってあったりしたんですか?
いや、ないですよ。
なかったですね。
始まった当初の改造道でいくと、
花守さん監査とかもやっていたからわかるんだろうな、
みたいなチームの、
よくわかんない期待感というか、
全く改造道高くないからそういうアレになっていましたけど、
普通の経理の業務の改造道って全然また違う話ですね。
別ですね。
なんか謎の期待みたいなのはあったんで頑張ったんですけど、
全然なかったので、
唯一あるとしたら個人事業主で、
自分で仕分け切ってたので、
そういうのはあったかもしれないですね。
そろそろ、
27:00
今、ザックバラにすごい
プロダクトが出てきて、
自己紹介の話をしてきたんですが、
一旦ここを前編として、
レイアエキスインボイスになるって形の番外編を、
ここで前編終了としたいと思うんですが、
レイアエキスインボイスの採用も絶賛募集中なので、
興味のある方は、
何かしらサース興味あるとか、
エンジニアリング興味ある、会計興味ある、
経理業務とか、
応募していただけるといいなと思います。
では、一度前編をここで終了したいと思います。
花村さん、ありがとうございました。
ありがとうございました。
