きままにものづくり

日々の気付いたことなんかを書いてます。

顧客に向き合うエンジニア組織

はじめに

こんにちは!EventHub CTOの井関です。

これは EventHub Advent Calendar 2023 の24日目の記事です。昨日はイベントプロデュースのマネジメントをしている浦田さんの プロデューサーが語る:今年やってよかったイベント でした。こちらもぜひ!!

去年は「なぜ起業したのか」というタイトルで起業にいたるまでの記事を書きましたが、今回は起業した後の経験を経てどのようなエンジニア組織を目指しているかを背景もまとめつつ文章にしました。

目指しているエンジニア組織

EventHubではエンジニア一人ひとりが顧客に向き合い、課題を理解しながらチームで協力しあって価値のあるプロダクトに改善していける組織を目指してます。

https://note.com/eventhub/n/n99c2b55842e1

このエンジニア組織像は今年のはじめに更新したバリューにある「顧客を主語に置こう」に反映されたものでもあります。会社のバリューではありますが、バリューには自分の思いも込めてありもちろんそれはエンジニア組織方針にも影響してます。どのバリューも大切にしていますが、「顧客を主語に置こう」はエンジニア組織を考える上でも大事にしているものになります。

EventHubが取り組んでいるイベント業界はコロナの影響もあり、特に変化が大きい業界です。ただ、一方でなかなかデジタル化が進まなかった領域でしたが、一気にコロナの影響でデジタル化を進めざるをえなくなった領域でもあります。

そんな変化の激しい領域だからこそエンジニア一人ひとりが顧客に向き合って本当に必要とされる機能を周りと議論して考え抜く必要があり、またそのインパクトを直に感じられる分野でもあります。

目指したきっかけ

EventHubは2016年の2月に創業しましたが、今のEventHubというプロダクトをリリースしたのは2019年になります。

前身となるプロダクトはいくつかありますが、作っては壊してを何度も繰り返して今の形になります。まだ起業したばかりの頃はプロダクトを作るということの本質を理解しきれてなく、設計・実装・コードの綺麗さにこだわっている自分がいました。

いかに綺麗に設計したとしても誰にも使われず、結果として没になりコードを捨てる悲しみは今のプロダクトに向き合う姿勢の原体験になっています。

結婚式管理サービス

本当の1番最初に作ってみようということで動き出したのは、結婚式管理サービスでした。正確にどういう経緯でそういったサービスを作ろうとなったのかは覚えてないですが、男女のマッチングサービスを作った経験がありその次のフェーズのサービスを作ってみようということで結婚式をターゲットにした記憶があります。

自分はただひたすらに作ることを考えて設計をしていましたが、代表の山本が市場調査やユーザヒアリングを重ねる内に収益性の課題が見つかりリリースする前に方針を変えることになりました。

この頃は自分の役割は「作ること!」みたいな変なこだわりを持ってしまいあまりヒアリングには同席せずに、ひたすら設計・実装をしていました。

イベント公式アプリ

結婚式管理サービスの次に挑戦することになったのが、イベント公式アプリを誰でも簡単に作成できるというものでした。名称はEventHubですがサービス内容は今のものとは異なります。

リリースされることなく日の目を見ることがない結婚式管理サービスの経験から、ヒアリング・商談にはいくつか同席するようになりました。同席を重ねていく内に作りたい要件・要望がどんどん出てきて設計・実装する時間に追われて同席する機会は徐々に減っていきました。

当時は公式アプリを作るイベントが増えていたタイミングでもあったので実際に使ってもらい良い反応をもらうことも多くありました。

一方でイベントという性質上目新しさを求められてしまい特定のイベントでないと使ってもらえなそうな機能であったり、お客さんごとに必要とされる機能に大きくバラツキがあり結果としては都度受託開発のようなスタイルとなっていました。

これでは受注できる案件にも限界が出てきてしまい、より多くのお客さんに使ってもらうサービスにしていくことに難しさを感じました。そこで、改めて自分たちがどんな事業をしたいのか、これまでのヒアリングや商談の内容を踏まえてお客さんは強く求めていものは何かを山本と話し合い、イベント公式アプリの一機能であったマッチングとコミュニケーションの部分を切り出して特化したサービスを作ることにしました。

コミュニケーションに特化したCommunityHub

参加して講演を聞いて帰るだけの体験しか提供できないイベントにしたくないので、交流が生まれるイベントにしたいという要望は多く、その要望に応えられるように開発を進めていきました。

交流周りの要望はイベントごとの違いはありますが汎用性が高いものも多く、それらの機能を優先して作っていきました。

様々なイベントで使ってもらいましたが実際に使ってもらう中で、交流機能に特化するのは良いがイベントを開催するためには他のツールも導入する必要があり管理が煩雑になってしまうという声を多くもらうようになりました。

そういった声を聞くようになり周辺機能も作り込もうとなり、今のEventHubを作ることに決めました。

CommunityHubをベースとして作り直したEventHub

CommunityHubの交流機能をベースにしつつも他のツールを導入しなくてもイベントを開催できるミニマムな機能をヒアリングしながら機能を追加していったのが今のEventHubになります。

目指した組織

イベント公式アプリ→CommunityHub→EventHubと遷移を辿る中で徐々にお客さんに使われる感覚を得ることができましたが、それはやはりチームでお客さんの課題に向き合って解決策を考え抜いた時間があったからです。

顧客に向き合うというのはただ要望された機能を作り出すということではないです。お客さんの本当の課題がなんなのかをエンジニア一人ひとりが深く考えて、使い勝手・拡張性・メンテナンス性を考慮して周りと協力しながら進めていくことになります。

実現したい組織にするためにはまだ多くのやることがあります。共感していただける方は是非一緒に作っていきましょう!

最後に

次の25日目の記事は、弊社代表の山本です!! お楽しみに!

EventHubでは、シリーズAの資金調達を受けて採用活動を強化しています! 興味がある方は是非ご応募ください🙌

https://jobs.eventhub.co.jp/

なぜ起業したのか

こんにちは!EventHubで開発責任者をしている井関と申します。

これはEventHub  Advent Calendar 2022の24日目の記事です。昨日はAmi Iwasakiさんの 🇯🇲Reggae Singer🇯🇲がイベントプロデューサーになるまででした。こちらもぜひ!

私は2016年2月に代表の山本とEventHubを創業したんですが、今までに「なぜ起業したんですか?」と色々なところで聞かれました。採用面接や、社内の飲み会であったりといたるところで話した記憶はあるんですが、口頭でその場で話して終わりということが多くしっかりと伝えたことはなかったと思い文章にまとめることにしました。

起業しようと考えた理由

自分自身が起業をしたいと思ったきっかけは自身の可能性をもっと広げたいという利己的なものからでした。今まで生きていた中で自分自身が大きく変化・成長ができたという根本のきっかけは全て人との出会いでした。自身の可能性を広げるためにもっとそういった出会いを作りたいと漠然と考えてました。

しかし、、、自分自身は初対面の人と話をしたり距離を詰めるのが苦手な性格です。。。

そんな自分を変えようと頑張ってカンファレンスなどの懇親会に参加しようとしてみますが、、、誰にも話しかけることができずに中途半端にケータリングを食べただけで終わるなんてことがよくありました。。。

大きな変化、成長をしたくて人と会ってみたいけど、どうも初対面の人と距離を詰めるのが苦手。。。そんな自分をサポートするようなものを作りたい。そういった自分のための何かを作りたいというのが原動力でした。

起業にいたるまで

上でも書いていることですが、自分自身は人との出会いで大きく変化した体験がいくつもあります。

昨年、起業にいたるまでの3つの出会いという記事を書きました。この中でも3つの出会いはどれも偶然の要素が強いものになります。特に現在の創業者である山本との出会いは、他2つの出会いがなければ実現しなかったものになります。

出会いを通した自分自身の変化

私はもとはとても安定志向な人間でした。公務員の父親に育てられたことも影響してますが、リスクを取ることを避けていました。中学を卒業して高専に入学しましたが、その理由も手に職をつけて大企業に就職して安定したいという気持ちからでした。あの頃の自分が大学院在学中に起業するなんて未来は1ミリも想像できなかったと思います。

そんな自分を変えたのは、当時Pitapatで代表をしていた合田さんとの出会いがきっかけです。合田さんの起業にいたるまでのエピソードを聞いて、面白そうと思いPitapatでのアルバイトに応募してみました。Pitapatでは新規のサービス開発に携わらせてもらい、サービスを作り上げる楽しさと、チームで取り組むことの楽しさに気づきました。

Pitapatでの経験を通して自分自身でもサービスをゼロから作り上げてみたいと思い、Givery主催のハッカソンに参加し、tentalkというチャットサービスを作成しました。ハッカソンという名称でしたが開発期間は2週間近くあり、当時よくあった1泊2日などの短期のものと比較すると多くの時間があるためよりチーム開発に近い経験ができました。

今は全く更新されてないですが、当時のサービスのFacebookページは今も残っています。

最初の出会いであるPitapatでの経験がなければ自分自身でサービスを作ってみようと思いにならず、Givery主催のハッカソンに参加することはなかったです。Givery主催のハッカソンでtentalkというサービスを作った経験がなければ、ゼロからサービスを作るワクワク感や自信が身につくことはなかったです。

もしこれら2つの経験がなく山本と出会っていても起業することはなかったです。

山本との出会い

山本との出会いのきっかけになるTechCrunchへの参加は、Giveryのハッカソンで出会った山根さんにTechCrunch主催のハッカソンに誘ってもらったことから始まります。

このハッカソンは1泊2日でサービスを作り上げる形式のものでした。当時の自分は短期で一気に作り上げるスタイルが肌に合わずこういった短期のハッカソンを苦手にしていました。ただ、少し食わず嫌いなところもあったのと、Giveryでお世話になった山根さんからのお誘いだったので挑戦してみました。

慣れないAndroidでの開発でしたが、山根さんともうひとり一緒に参加した人と協力してサービスを作り上げることで入賞することができました。(当時のレポートは下の記事にまとまってます)

Mashup Awards ブログ 【ハッカソンレポート@TechCrunch】TechCrunch Tokyo Hackathon 2014〜全作品紹介〜 #MA10

ハッカソンで入賞することができたお陰でTechCrunch Tokyo2014への招待券とLTをする権利をもらうことができました。当時はTechCrunchというメディアサイトは知っていましたがイベントがあることは知らなかったので、この入賞がなかったらこのイベントに参加することはなかったと思います。そして、TechCrunch Tokyo2014で出会った人の紹介で山本と出会うことになります。

Givery主催のハッカソンに参加したことで山根さんと出会い、山根さんに誘われてTechCrunch主催のハッカソンに参加し、そしてTechCrunch Tokyo2014で出会った人の紹介で山本と出会うことになります。

初めに山本と出会った時は共通の知人もほぼいない状態だったので、上の綱渡りのようなつながりがなければそもそも物理的に会うこともなかったかもしれないです。

自分の考えを変えるような出会いと、いくつもの偶然を重ねて山本と出会ったことでEventHubを創業することになりました。

やりたいこと

あの時、山本と出会ってなかったら確実に今のEventHubはありません。

これは起業したあとの内容にはなってしまいますが、EventHubを創業したことで本当に多くの体験や経験・成長をすることができました。

もしあの時苦手なことに挑戦することを避けてTechCrunchのハッカソンに行ってなかったら、恥ずかしがって行動を起こしていなかったら。そんな些細な行動の変化で現在の自分は大きく変わっていたと思います。

そんなことを考えていたら、自分自身はもっと多くの可能性を逃していたかもしれない、もっと大きな変化をできたのかもしれない。今まで自分を変えてきた出会いは偶発的な要素が強かったです。そうした出会いを偶然ではなく必然にしたい。

偶発的な出会いを必然にしたい。

これが自分がEventHubで実現したいことであり、会社のミッションに込めた思いになります。

実はこの考えは起業をしてからある程度の時間が経ってから固まった思いになります。起業のきっかけは上で書いたとおりですが、それをどうやってお金にするのかが分からず色々なサービスに取り組んでいました。ただ、どれもしっくりくることができず売上もほとんどありませんでした。

自分たちがやりたいことを改めて考えて、それを実現するようなサービスを作ろうということで今のEventHubが出来ました。会社のミッションの基本となる部分もこの時に考えたものになります。

どう実現するか

いきなり山本と出会っていたら自分は起業していたかと考えると答えはNOだなと思います。

その前段となるPitapat、tentalkでの経験があったからこそ自分自身で起業する楽しさと勇気を持てたことが大きいです。

単に人がつながるだけでは不十分なため、プロフィール情報をいつでも閲覧できるようにした人を中心としたマッチングサービスを提供するだけでは偶発的な出会いを必然にするのは難しいと考えています。

ただ、どうすれば実現できるのかはまだまだ模索しているところです。是非、興味がある方は一緒に探していきましょう!

最後に

次の25日目の記事は、話にも出てきた弊社代表の山本です!! お楽しみに!

EventHubでは、シリーズAの資金調達を受けて採用活動を強化しています! 興味がある方は是非ご応募ください🙌

jobs.eventhub.co.jp

prtimes.jp

起業にいたるまでの3つの出会い

これはEventHub  Advent Calendar 2021の12日目の記事です。昨日はYuto HaraさんのAccelerate EventHubでした。こちらもぜひ!

株式会社EventHubの開発責任者の井関です!

弊社は起業してから数年間は数名という規模だったのでアドベントカレンダーを埋めれる規模になったんだと思うと感慨深いです。

さて、今回はそんな自分が起業にいたるまでの3つの出会いを思い出しながらまとめていきます。

Pitapat

ひとつめの出会いはPitapatとの出会いです。

当時は大学生で右も左も分からない状態でしたが、Engineer Meetupというイベントで代表の合田さんと出会い、アルバイトとして働かせてもらいました。

Pitapatでは新規サービスの開発に関わらせてもらいましたが、サービスを作り上げる楽しさと、チームで取り組むことの楽しさに気づきました。


tentalk

tentalkは、Givery主催のハッカソンで集まった有志どうしで作ったサービスの名前です。

Pitapatでサービス開発の楽しさに気づきましたが、自分自身で作ってみたいという思いからハッカソンに参加しました。

tentalkの開発を通してゼロからサービスを作る大変さや難しさと同時に、サービスをリリースするワクワク感や楽しさを知ることができました。


TechCrunch

3つ目はEventHubの共同創業者の山本と出会うきっかけになったTechCrunchへの参加です。

はじめはTechCrunchが開催するハッカソンに参加しました。こちらで入賞したことでTechCrunch Tokyo 2014でLTに参加することができました。

イベント終了後に参加した人同士で飲むことになり、この時のつながりで山本と起業することになります。


EventHub創業のきっかけ

自分自身は人見知りな性格で初対面の人と距離をつめることに苦手意識がありました。ただ、振り返ってみると自分の考えを広げたり、新しい領域に挑戦してみようと思えたりと自分自身の可能性を広げるきっかけには常に誰かとの出会いがありました。

そんな体験・機会をもっと増やしたいという思いからEventHubというサービスを作りました。

まだまだやりたいことはあり、どんどん組織も拡大していくフェーズなので興味を持った方は是非カジュアルに話しましょう!

meety.net


次の記事はTamogamiさんです😆

SRM581Div1Easy

問題

N個のコンテナとM個の監視カメラを考える。監視カメラは連続したL個のコンテナを監視できる。コンテナが空の場合は"-"となり、何か入っている場合は"X"となる。カメラの位置は分からないが、カメラが監視している空でないコンテナの数は与えられる。
この時のコンテナの状態を求めよ。
ただし、コンテナの状態は必ず監視されている場合は"+"、監視されている可能性がある場合は"?"、監視されていない場合は"-"で表す。

解法

各コンテナを監視していないと仮定した時の与えられた条件を満たすかを確認することで、そのコンテナが"+"、つまり、必ず監視されているかどうかを判別できる。
必ず監視されているとは言い切れない場合は、そのコンテナを監視することができるかを調べる。これは、先ほどと逆で監視されていると仮定した時に条件を満たすかを調べればよい。

計算量

 O(N^2)
mapの挿入コストは無視している。

コード

SRM582Div1Easy

問題

N人の戦士が与えられ、それぞれの戦士の強さはs[i]である。また、M種類の強さes[j]を持つec[j]匹のモンスターも与えられる。戦士は自身より強さの小さいモンスターを討伐できる。戦士は一匹のモンスターを倒すと疲労度が1増える。すべてのモンスターを討伐する時のN人の戦士の中の最大の疲労度の最小値を求めよ。すべてのモンスターを討伐できない場合は-1を返す。

解法

最大の疲労度に対して二分探索を行う。最大の疲労度を固定することで、モンスターを討伐できるかの判定が可能になる。

計算量

 O(NM log V)
N: 戦士の数
M: モンスターの種類
V: モンスターの数

コード

SRM583Div1Easy

問題

N個の街がひとつの輪となるようにつながっている。各街からは電車が出ており、それぞれの電車は最大range[i]個の街を移動できる。startからendまで行くのに必要な電車に乗る回数の最小値を求めよ。

解法

最短路問題に帰着できる。
ダイクストラで解いているが、コストは1ずつしか増えないのでpriority_queueの代わりにqueueを使用している。

計算量

 O(N)

コード

SRM584Div1Easy

問題

ある国にはN人の国民がおり、それぞれ貯金を持っている。この国のルールとして貯金額の差がdより大きい人同士では友達になることはできない。
友人関係を示す情報とdが与えられた時、国民間での貯金額の最大値を求めよ。有限値でない場合は-1を返す。

解法

最短路問題に帰着できる。
最短路の中での最大値にdをかけ合わせることで答えが求まる。
ワーシャルフロイドを用いているので計算量は O(N^3)だが他のアルゴリズムを用いることで、計算量の削減ができる。

計算量

 O(N^3)

コード