2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
矢澤:お一人ずつ詳しく聞かせていただきましたが、さっそくプロダクト開発についておうかがいしたいなと思います。
今日、プロダクションの裏側ってどうなってるのかなとか、失敗したこととかうまくいったこととか、こだわりとか、そういったところをおうかがいしたいなと思っていました。
でも、せっかくなので、これまでやってきて、最初のゼロイチのところで失敗したことや、こうしたらよかったというところをお聞きしたいなと思いました。なにか思い付くことはあったりしますか? 内藤さんからおうかがいしてもいいですか?
内藤:さっき少しお話したんですけど、いくつかピボットをしてまして。そのとき何がまずかったかというと、自分たちの作りたいものを作っていたり、できるものを作っていたところが、けっこうまずかったなと。やっぱり使っていただけるユーザーありきで考えないと売れるものは作れないなということは、実感としてあります。
矢澤:ちなみに、最初は何を作られてたんですか?
内藤:最初は、ユーザーとなるエンジニアやデザイナーがサインアップして、いろんな質問に答えるとその人のスキルが可視化される、というようなサービスを考えてました。マネタイズも考えてはいたんですけど、けっこう時間がかかるような方法だったので、あんまりうまくいかないと感じました。
あとは「スキルを可視化するのはどうやればいいんだろう?」「そもそもユーザーがなんでスキルを登録するんだろう?」とか、ユーザーが求めるポイントがぜんぜん詰められてなかったので、ピボットした感じです。
矢澤:なるほど。ユーザーが好きなものを作るというか、ユーザーありきでSmartHRさんはできていると思うんですが、そうすると、UI/UXであったりとか、カスタマーの声を聞くとかはけっこうこだわられたりしてますか?
内藤:課題に注力しようというところは、こだわってますね。例えば、新しい機能を開発するにあたっても、自分たちの思いつきではなく、ユーザーの困りごとに対応するものを優先させています。ユーザーの声をそのまま受け入れるわけではないですけど「その裏側にある課題は何だろう?」ということを必ず考えるようにしています。
矢澤:なるほど。ありがとうございます。丹さん、いかがでしょう?
丹:うちはONEの前に決済サービスをやってたんですが、そこは失敗した部分がありました。裏側が、自分たちが作ったものじゃなくて、クレジットからの決済を、他社のサービス上に乗せてたんですね。だからコアなところが自分たちでコントロールできなくて、ビジネス上進まないことが起きた。
あとは、すごいシンプルにしすぎたんです。誰でも使えて、すぐ誰でもクレジットカード決済できる世界観だったので、不正が多すぎた。「グローバルで見ても、おまえら一番不正が多いよ」みたいなことを決済プラットフォームに言われた(笑)。
そういうのもあって、サービスはクローズしたんですけど。
矢澤:そのサービスは、ローンチしてから何ヶ月ぐらい実際に稼働されてたんですか?
丹:10ヶ月ぐらいです。
矢澤:なるほど。クローズしようと決めた要因は、やっぱり不正が多かったというか、そもそもの作り込みの……?
丹:そうですね。そこと、自分たちでコントロールできないところが多いという2点です。
矢澤:なるほど。いま振り返ったら、自社でそういったものをすべてやればよかったと思います?
丹:決済を自分たちで作るのは、けっこう大変だと思うので……。
矢澤:けっこう厳しいですよね。顧客情報をどう持つかとか。
丹:そうですね。セキュリティも難しいと思うので、事業領域を変えてよかったかなと思います。
矢澤:なるほど、なるほど。そのときは、エンジニアは何人ぐらいでした?
丹:そのときは僕だけでしたね。
矢澤:あ、なるほど(笑)。じゃあ、自分で全部そういうことを決めなきゃいけなかったというつらさはあったんですか?
丹:そうですね。
矢澤:ありがとうございます。横塚さん、どうですか?
横塚:4月の頭にβ版を出したんですが、そこでユーザーとのギャップがありました。開発途中でもユーザーにヒアリングすることは大事だなと、改めて痛感しました。その次の6月23日に本製品をリリースしたんですが、そっちは作りながらコアユーザーとなるような方たちに触ってもらいつつやってきましたね。
技術的な部分でいうと、プロトタイプ時点では裏側のDBまわりをGraph DBとか、ちょっとチャレンジングなことをやってたんですね。プロトタイプだからこそ挑戦できたし、してよかったなと思ってるんですけど、本製品ではわりとスタンダードな作りに変えていった、ということはありますね。
矢澤:なるほど。エンジニアの方はけっこう好奇心旺盛な方が多いですよね。新しいの試してみたくなっちゃう、ってイメージあります(笑)。
横塚:「プロトタイプだからいいかな」みたいな。
矢澤:なるほど(笑)。
矢澤:それこそSmartHRさんなんかは、けっこう新しい技術を取り入れたりしているんですか?
内藤:うちはわりと枯れた技術が多いですね。
矢澤:そうなんですね。
内藤:以前ピボットしたときは、そのときの流行ってる技術を使おうということは、一応やってました。
矢澤:ちなみに、なぜ枯れた技術になったんですか?
内藤:たまたまですね。時間がなかったので、枯れている技術や使い慣れてるものを使おうということでやってました。
矢澤:なるほど。実際、そうですよね。新しい技術だと、問題があったりとか課題があったりということもありますし。あんまりそれについてのドキュメントが落ちてなかったり、ナレッジがたまってない。
内藤:そうですね。いま、コアプロダクト以外にも新規のプロダクトを考えていて、そっちにはわりとチャレンジングな技術を採用しています。
矢澤:なるほど、そこは分けてるんですね。岡さん、いかがでしょうか?
岡: Quantstampもまだ1年ぐらいしか経ってない会社なので、まだとくに大きな失敗はしてないです。チャレンジングな点といえば、ブロックチェーン界隈では良くあるのですが、我々もICOを行ったので、ICOに投資してくださった方の期待値のコントロールがすごく難しいです。
岡:ICOを行って、会社ごと消えてしまったケースも多かったり、詐欺まがいなことが多かったりするので、どれだけ自分たちががんばっててプロダクトの開発をしてても、トークンホルダーから見ると「なにも出てないじゃないか」「いつリリースされるのか?」とかよく聞かれたりします。。
ブロックチェーン業界自体もすごく速いスピードで動いているので、本当に我々のサービスに対するニーズがあるかということも、常に確かめながらやっている感じです。
あとは、プロジェクトも、いまはEthereumを中心にやっていますが、ベースレイヤーにどうしても頼ってしまってるところがあります。Ethereumは今まだ取引が遅かったりするんです。それが解決しないと、今後一般企業、大企業が導入したりすることはたぶんないと思います。
自分たちが開発しているわけではないから、そこの基礎的な技術にどうしても左右されてしまいます。そこが将来的に速くなったり、良くなるだろうということにベットしてる感じです。
矢澤:よく見えないリスクってありますよね。
岡:そうですね。我々としては、なかなか対応しづらいところもあります。
矢澤:ありがとうございます。先ほど内藤さんとか横塚さんとかが言ってた「ユーザーに寄り添った」というところが少し気になったんですけど、ユーザーの声を聞くことをすごく重要視されたというところで、次のテーマにもいきたいんですが。
CTOって名乗ってるようなエンジニアの方とかだと、CEOとのコミュニケーションがうまくいかなかったり、「ユーザーがこれほしがってるよ」ってCEOから聞いても、あまり納得いかなかったり。
プロダクト開発において、ユーザーの視点を入れることの難しさを感じられる方もいらっしゃるのかなって思ったんですけど、そういうことはあんまりなかったんですか?
例えば、CEOとのコミュニケーションだったり。ユーザーの声は、CEOを通さなくてもたぶん聞く機会はたくさんあるとは思うんですけど、そういったところをどうプロダクトに反映させたり、チームでコミュニケーションを取りながら進めていくのかなというところが、すごく気になります。内藤さん、どうですかね?
内藤:そうですね。CEOとのコミュニケーションは、もともと友人ということもあるので、そんなに問題ないです。ユーザーの声の取り入れ方については、サービスリリース前とリリース後でけっこう変わったなと思いますね。
リリース前はユーザーがいないので、誰がターゲットになるかもわかんないんです。なので、想定ユーザーを仮定して、それにマッチする人に話を聞きにいくみたいな感じでした。
リリース後は行動しやすくなって、ユーザーとなっていただいた方たちの声をひたすら聞く。日々サポートチームがユーザーからの要望を受け入れるので、それを収集したり、あとは、営業チームが新規顧客の声を聞いてきたりするので、そこを集めて精査していますね。
意識しているところとしては「単一のお客さんが言ってることじゃないよね?」「これ、普遍的な課題だよね?」ということを意識していることですね。
矢澤:ちなみに、そういうユーザーから上がってきた声を活かす際の優先順位の付け方、どこからやるかということは、どうしてますか?
内藤:そこは常に悩みの種ですね。さっきもあったように、普遍的な課題であるかどうかということと、あとはサービスに合うかどうか、SmartHRが解決すべき課題なのかは意識しています。
ただ、後者の、サービスが解決すべき課題なのかどうかというところもなかなか難しくて、サービスの領域を拡張すべきなのかという議論も常にあります。
矢澤:なるほど。そこは、内藤さんが指揮をとって決めたりするんですか?
内藤:わりと民主主義的というか、議論を大切にするカルチャーがあるので、リーダー陣が集まって定期的に議論しています。
矢澤:ありがとうございます。じゃあ、丹さん、先ほど「UI/UXにすごいこだわってる」とおっしゃってましたが。
丹:そうですね。普通、ユーザーインタビューみたいなものをよくやると思うんですけど、うちはまったくやってないんです。プロダクトをリリースする前の仮説とかは、自分たちで立てて、あとは1回出してみないとわかんないって感じで、プロダクト作りしてます。
矢澤:なるほど。じゃあ、ご自身で使いやすいかどうかが、判断基準になるということですか?
丹:そうですね。あとは、例えば今回のONEのプロダクトだと、お金をもらいたい人のほうが多いだろうということは感覚的にわかるので、そこを刺しにいった感じですね。
矢澤:なるほど。ただ、実際のカスタマーは、どういう感じですか? 若い世代とかですか?
丹:そうですね。あ、でも、20代、30代も多いです。40代ぐらいもいます。
矢澤:そうすると、ペルソナを決めきった、っていう感じでもないんですか?
丹:でもないですね。まあ、学生さん、主婦の方には刺さるとは思ってました。
矢澤:ありがとうございます。横塚さん、どうですか?
横塚:CEOとのコミュニケーションギャップは、まったくないです。ユーザーの声を信じることを一番大切にしているので。CEOが保険業界出身ということもあるので、業界の知識はメンバー全員にインプットする機会を設けてます。
矢澤:あ、ちゃんとそういうのを設けてるんですね。
横塚:エンジニアも業界の知識をインプットするようにしてます。
矢澤:へぇ!
横塚:それ以降の仮説については、わりと役職問わずに、民主主義的なかたちです。
矢澤:民主主義で(笑)。
横塚:はい。
矢澤:もめるケースはとくにない?
横塚:……そうですね、はい!
矢澤:わかりました、ありがとうございます(笑)。岡さんの場合だと、ユーザーはB to Bになるんですかね?
岡:そうですね。いまのところはどちらかといえば、実際にDAppsとか、ブロックチェーンプロジェクトをされている会社さんとのやりとりが多いです。
矢澤:なるほど。直接やりとりしてると、けっこうカスタマーの声は、しっかりディープに聞ける機会が多いんじゃないですか。
岡:いまはまさに、お客さまのフィードバックを使って、今後どのうようなプロジェクトだったりサービスが必要なのかを考えている最中です。
いままでは、監査サービスを中心にやってきたのですけど、例えば、スマコンをデプロイした後のモニタリングも、お客さまとの対話によって生まれたアイデアです。しっかりとサービスを提供しながら、次に開発していくものも常に考えながらやってます。
矢澤:なるほど。カスタマーって、アメリカとか、国によってけっこう違う部分もあるかなと思うんですが。
岡:そうですね。世界中にクライアントさんがいるので、日本の企業さんだったり、あとアジアだといま韓国とかがすごく盛んなんですが、やりとりとかは本当に国によって、プロジェクトによってもぜんぜん違うので、対応の仕方であったり、難しさ、文化的なものもあるのかな、というふうには思っています。
矢澤:ありがとうございます。時間が押してきちゃってるんですが、最後に1点私がぜひ聞きたいことがありまして。
エンジニアの採用方法について、みなさんがどういうふうにエンジニアを採用しているのか、採用活動をされているのかを、おうかがいしたいです。なにが良いか悪いかというより、どういう活動をされてるのかを、岡さんから聞いていってもいいですか?
岡:そうですね。いま日本には2人しかいないので、積極的に募集中なんですけど、正直なところ、採用まで手が回ってないんです。もともとブロックチェーンをやってるエンジニアも本当に少ないし、優秀な人はすでに自分のプロジェクトをやってるケースが多いので、わりと苦戦してます。
他の国では、紹介だったり、最初はブロックチェーンの知識がなくても優秀な人がいれば採用して、彼のポジションを作るという方針で、やっております。
矢澤:それはアメリカの?
岡:世界中で。本当に「『この人優秀だな』って思ったら採用しろ」というふうに言われてます。
矢澤:なるほど。いくら金額が高かったとしても?(笑)。
岡:まあ、そこは(笑)、相談しながらですけど。
矢澤:なるほど(笑)。
岡:ポジションに人を合わせるというよりは、まず採用してから考えよう、というふうにやってます。
矢澤:人を大事にされてるんですね。ありがとうございます。横塚さん、どうですか?
横塚:うちも、いまエンジニアの採用が課題です。こないだなんか、メンバー全員に「エンジニアの知り合いを全員リストアップしてくれ」ってお願いしました。
矢澤:みんなにリストアップさせたんですね(笑)。
横塚:社を挙げて、全員でリクルーティングしにいく方針ですね。採用も、繰り返しになってしまうんですけど、優秀な人がいれば、いまのポジションに当てはめるというより、その方に合ったキャリアプランだったりキャリアパスを用意していくかたちで考えています。
矢澤:ありがとうございます。じゃあ、丹さん。
丹:うちは僕と東大の1年生の子の2人しかいないんです。まだ採用をガッツリやるフェーズじゃないと思っているので、採用する気はいまのところあんまりないです。これからそういう機会もあると思うんですけど、そのときはリファラルで紹介ベースでいい人を採っていこうかな、とは思ってます。
矢澤:ありがとうございます。じゃあ、内藤さん。ここはもうすごく気合い入ってる感じですよね。
内藤:そうですね。上半期はぜんぜん人が採れてなかったんですが、下半期は徐々にうまくいくようになってきました。何をやったかというと、会社の情報をオープンにアピールしたんです。
うちの会社はそもそもオープンな社風ですし、それがカルチャーになってるので、それを外に向けてアピールした結果、応募が増えてきたという流れです。
それまで、採用イベントをやったり、カンファレンスにスポンサーとして参加したり、いろいろジャブをうってきたうえで会社の内情を公開して、ようやく応募がくるようになりました。
矢澤:そうすると、オープンにすることは、意外に重要。
内藤:やっぱり知ってもらわないといけないなという感じはあります。
矢澤:SmartHRさんの採用ページを見ると、エンジニアが楽しそうに働いてる感じが伝わるんですよね。
内藤:エンジニアはけっこう楽しくやってますね。向上心の高い方、学習意欲の高い方が多いので、内部でお互い刺激し合ってることもありますね。
矢澤:なるほど。育成というか、エンジニアが勉強会を自分でやる機会とかもあったりするんですか?
内藤:いまのところは即戦力の方がほとんどで、育成はこれからの課題です。ただ、最近ようやく育成枠も少しずつ採りだしたので、どうやって育成やマネジメントしていこうかというところをいま考えています。
矢澤:ありがとうございます。もっと聞きたいことがたくさんあってしょうがないんですが、お時間になりましたので、セッションをクローズしたいと思います。みなさん、大きな拍手でお送りください。ありがとうございました。
(会場拍手)
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
PR | 2024.12.04
攻撃者はVPNを狙っている ゼロトラストならランサムウェア攻撃を防げる理由と仕組み
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術