asoview! TECH BLOG

アソビュー株式会社のテックブログ

IntelliJのクエリフォーマットをちょこっと改善


IntelliJのクエリフォーマットをちょこっと改善

Photo by Sigmund on Unsplash

これはアソビュー Advent Calendar 2021の23日目の記事です。

バックエンド担当、ブログでは小ネタ担当の佐藤です。
今回も一息で書き切ります!

ちょっと不便だけとそのままにしてることありませんか?

IntelliJでクエリを書くようになって補完機能でかなり助けられてます。

ただそのまま使っているとちょっと個人的には好きではない書きっぷりになってしまいます。

エイリアスいらないんです。

Yes、設定で変えられます。

「Preference > Editor > Code Style > SQL」ではなく、
「Preference > Editor > General > Code Completion > SQL」にて変更可能です。

結果。

ちょっと不便だけどそのままにしがちなことってありますよね?!
今回はレビューで大きいクエリをリーディングしていたときに読みづらかったので調べてみました。

この記事をみて1人でも設定変更してハッピーになっていただけたら幸いです!


さいごに

アソビューでは現在多方面で積極採用をしていますので、興味がありましたらお気軽にご応募いただければと思います。www.wantedly.com

 

 

Shopify APIで注文のフルフィルメントを行う

これはアソビュー Advent Calendar 2021の21日目の記事です。

アソビューでバックエンドエンジニアをしている上中です。

今回は、ShopifyのAdmin API( GraphQL)を利用して、Shopifyのストアで注文された注文情報に対してフルフィルメントを行う方法についてご説明します。

フルフィルメントとは?

Shopifyにおけるフルフィルメント(Fulfillment)は、いわゆる「出荷」のことです。アソビュー!ギフトでは、一部のギフト商品について、注文をトリガーに外部のAPIを呼び出し、注文者に対して自動でギフトコードをメールで送信しています。このギフトコードのメール送信自体が「出荷」となるため、Shopify上の注文情報を出荷済みとする必要があります。

APIで注文情報から出荷IDを取得する

Shopifyの出荷はロケーション(出荷元)ごとに行います。当然のことながら、一つの注文には複数の商品が含まれることがあり、さらに商品ごとに出荷元が異なる場合があります。その場合、出荷元ごとに複数の出荷情報が必要となります(各出荷元に個別に出荷依頼を出すため)。

よってフルフィルメントを行うには、まず注文情報から未発送の出荷情報を取得する必要があります。APIで取得してみましょう。

ちなみに、PostmanはBodyの形式にGraphQLが選択できるため、QueryやVariablesでのリクエストがしやすいです。

URL:

https://<ストアのホスト名>/admin/api/2021-10/graphql.json

ヘッダ情報:

Content-Type : application/jsonX-Shopify-Access-Token : <Admin APIパスワード>

Query:

Variables:
注文IDは、対象の注文をShopifyの注文ダッシュボードで開いた際にURLに含まれる数字の羅列です。

これで以下のようなJSONが返されます。

"displayFulfillmentStatus": "UNFULFILLED",

となっている通り、まだ未出荷状態であることがわかります。

“fulfillmentOrders”の配列に、出荷元ごとの注文出荷情報が入っています。これを元にフルフィルメントを作成します。

APIでフルフィルメントを作成する

ではフルフィルメントを作成していきます。フルフィルメントは出荷元ごとに作成できます。今回は”fulfillmentOrders”が2つあることからもわかるとおり、2つの異なる出荷元の商品が同じ注文に含まれています。

早速一つをフルフィルメントしてみます。URLやヘッダは注文取得と同じなので省略します。

Query:

Variables:

これで一つ目の出荷が完了したことになります。Shopifyのダッシュボードで注文情報を見てみると、「一部出荷済み」となります。APIで見てみても、以下の通り”PARTIALLY_FULFILLED”となり、フルフィルメントを作成した注文出荷情報はfulfillmentOrdersからなくなっています。

ということで同じように残りの出荷情報もフルフィルメントしてみると、以下のように「出荷済み(displayFulfillmentStatus: FULFILLED)」となり、fulfillmentOrderは無くなります。

以上でAPIによる出荷が完了です。今回は以上になります。

「生きるに、遊びを。」をミッションに掲げる我らがアソビューでは一緒に事業をつくる仲間を絶賛募集中です。
興味がありましたらお気軽にご応募いただければと思います。

www.wantedly.com

今更ですが、Next.jsのgetStaticPropsをつかってSSG入門してみた(TypeScriptを添えて)

f:id:rnog0314:20220317151239p:plain

こちらは、アソビュー! Advent Calendar 2021の22日目の記事です。

アソビューでエンジニアをしているノグチです。昨今フロントエンド領域で何かと話題になっているSSGをNext.jsでどうやっているのか興味があり、いまさらですが入門してみたのでそれについて書きたいと思います。Next.jsの公式チュートリアルではTypescriptを使用しておらず、DBからデータを取得する例はなかったりでしたので、それらを使って書くのに少しでもお役に立てばと思います。

getStaticPropsとは

 

geStaticPropsとは、Next.jsのSSG*用のページコンポーネント内でexportする非同期関数です。この関数内にはサーバーサイドで実行される任意のコードを記述することができます。つまり、認証情報などをクライアントから見えない状態でDBや外部APIに接続してデータを取得してくることが可能になります。

 

*SSGとは: Static Site Generationの略称で、従来のClient Side Renderingではなくビルド時に静的ファイルをすべて生成してしまって、クライアントからリクエストをされたときに瞬時にページを描画できるようにできるすぐれた技術です。これにより、UXだけでなく、パフォーマンス、セキュリティの向上やSEO対策にもなると言われています。

実装してみる

1. Next.jsアプリケーションを作成し、pages/question/[id].tsx のように pages ディレクト配下に [] でファイル名を囲んで作成します。(動的ファイルにするため [] を使用)

├── pages
│ └── question
│ ├── [id].tsx

2. getStaticPaths メソッドでDBや外部APIを使って pages/question/[id] のパスの id に入るものをすべて params として取得します。(今回の例では questionIdを id にして画面を動的に切り替えるようにするため、以下のように今回はCloud FirestoreのDBに用意した questionsコレクションから questionId を取得するようにしています。)

gist.github.com

3. getStaticPaths で取得した params を getStaticProps に引数として渡し、その params の中に入っている idを条件に各 pages/question/[id] ページに必要なデータを取得します。

gist.github.com

4. getStaticProps で return した props をページコンポーネントに渡します。

gist.github.com

上記はサンプルのため簡易的に記述しましたが、基本的には上記のように getStaticPaths ➔ getStaticProps ➔ 「Reactコンポーネント」という流れでデータを渡していくので、あとはコンポーネント内で通常通り props を使用していろいろな処理を実装していきます。

感想

今回Next.jsのSSG入門をして、「SSGすごくない!?」と思ったので、これを応用してブログサイトを作ったりしてNext.jsの可能性をもっと体感してみたい思います!

アソビューではエンジニアを大募集しております!これからますます成長するサービスをモダンな技術で作っていきたい方、まずは以下のWantedlyをご覧ください!

www.wantedly.com

 
 

Autifyでリリースチェックを自動化した話

これはアソビュー Advent Calendar 2021の20日目の記事です。

「週末、なにする?そんな時は、アソビュー!」でお馴染みの遊び予約サイト「アソビュー!」のQAを担当している青柳です。

◆Autify導入の背景

私が担当しているWebチケットシステムは、日々機能追加・改修が行われています。昨年はコロナ禍を背景に、人数制限や日時指定など条件付きのチケットを開発しました。商品のバリエーションが増えてテストも膨大になったことで、品質を保ちながら効率良くテストするという課題に直面しました。

システムが複雑化していくことによって、テストの条件がどんどん増えていきますよね。たとえばマトリクスを組んだときに、数千/数万ケース数に膨れ上がっていく状況でした。
テストにかかる工数の割合がどうしても増えてしまうため、リリースサイクルも遅くなり、QAがボトルネックになってしまうこともありました。

◆自動化ツールの選定

上記背景から、品質を保ちながら効率良くテストするという課題を解決するために自動化ツールの導入を検討しました。

実は1〜2年ほど前、SeleniumができるQAエンジニアの方に来ていただいて、一部自動化を推進した時期がありました。ですが、メンテナンスのところでうまく機能しなかったため、作ったものの使われなくなったまま終わってしまいました。
原因としては、現在のQA体制では自動化のためのプログラミングができるメンバーがおらず、機能が改修・追加されていく中で、コードを修正する作業が追いつかなかった。それがメンテナンスにおける課題でした。

前回の反省も踏まえつつ、自動化ツールに関するディスカッションを行なっているとき、同じチームのメンバーからAutifyを紹介してもらいました。
使いやすそうと感じたので、トライアルから始めてみたところ、使いやすいプロダクトだったので本格導入を推進していくことになりました。

◆Autify導入〜

今回対象にしたプロダクトがWebチケットなので、まずは、チケット領域のリグレッションテストをAutifyで自動化に置き換えていこうと考えました。弊社はリリースチェックシートを用意しているので、まずはそのチェック項目に沿ってAutifyでテストシナリオを作っていきました。

・・・なぜ、リリースチェックから置き換えとしたのか
弊社では機能リリース時にリリースチェックをクリアする必要があるのですが、PC / SPで実施する必要があるため、1.5〜2時間程度の作業時間が発生していました。
多いときは週に何度もリリースチェックを行っていたため、工数削減効果が高い、既にテストケースが用意されている点を考慮し、リリースチェックから自動化に置き換えていくことにしました。

リリースチェックを置き換えるところまでは良かったのですが「誰がいつまでに」という具体的なところを決めきれていないままで進めたので作業が停滞してしまった時期がありましたが、仕切り直した上でテストケースを用意し、プランを明確にしました。
プランに対して実装する担当も決めて、そのメンバーと連携して、テストケースを上から順にAutifyで作っていってもらうようにしました。

テストケースが増えていくと、何がどういうケースなのか分からなくなってきてしまうという課題も発見できたので、命名規則を設けてパッと見てすぐに分かる形にしていきました。
リリースチェックを置き換えていく中で、せっかく作った自動テストを使わないのも勿体ないので、該当するAutifyのリンクを貼っていって、一部だけでも動かせるようにしました。グループ機能も活用しました。

◆Autify導入後〜運用フェーズ

現在は、デイリーで動かすシナリオを用意して、標準的な機能に異常が起こっていないかを毎朝確認しています。あとは、リリースのタイミングでテストプランとしてまとまっているものを実行しています。
Slackと連携して結果が全て通知されるようになっているので、確認も容易であり、エラーがあればすぐに拾える状態です。

以前は開発メンバーにもQAの作業を一部手伝ってもらったりしていましたが、手動で行っていたテストの一部がAutifyに置き換わってきているので、最近はほとんど起こらなくなっています。

◆今後の展望

リリースチェック以外にも自動化できるところを推進していく、他のチームのリグレッションテストもAutifyに置き換えていって、人の手で確認する作業を極力なくしていきたいです。
弊社の場合、サイトに掲載してチケットを販売するまでの大きなシナリオもあります。その部分もAutifyに置き換えて、品質を定常的にモニタリングできる仕組みの1つとしてもAutifyを活用していきたいとか考えています。

Autify社からの事例紹介のインタビューの記事はこちらからご覧ください。
https://autify.com/ja/stories/asoview?utm_campaign=weekly-letter&utm_medium=email&_hsmi=191725596&_hsenc=p2ANqtz-9fNT5uyn6zOLDibKu4E4sYPIyraYhx3XNgIwNmT-JezeTIPcTRHXLRLjBbx5of_Nvqy8YBOJE3KVNipCqqMf0REoQ0FvAW2l0ffus2lVH-i8lBonE&utm_content=191725596&utm_source=hs_email

「生きるに、遊びを。」をミッションに掲げる我らがアソビューでは一緒に事業をつくる仲間を絶賛募集中です。
興味がありましたらお気軽にご応募いただければと思います。
https://www.wantedly.com/companies/www-asoview-co/projects

TypeScriptのジェネリクスに入門してみた

 

こちらは、アソビュー! Advent Calendar 2021の18日目の記事です。

こんにちは、アソビュー!でエンジニアをしている島田です
そろそろクリスマスがやって来ますが、大切な人に渡すプレゼントはお決まりでしょうか!?私は、2歳になる子供に滑り台付きのジャングルジムを上げようと思い品切れになる前に購入したのですが、いざ届くと早く上げたくなり上げてしまいました😅

さて、今回はTypeScriptのジェネリクスについて学んだので備忘も兼ねて紹介できればと思います。
弊社では週に一度のペースでフロントエンドに関わる人が集まって勉強会のようなことを行なっています。そこでTypeScriptのジェネリクスの話題となったのですが、私自身よく分かっていないなと思ったので調べてみました。

はじめに

ジェネリクスはTypeScriptだけに限った機能ではありません。あらかじめ特定の型に定義せず、曖昧な状態のままで定義することができます。
そして利用時点で型指定を行い、特定の型に確定します。このように利用されるまでは型定義が曖昧で様々な型で利用されることから「総称型」とも呼ばれます。

ジェネリクスは利用法が色々あるみたいなので、学んでいきたいと思います。

メソッドでの利用

以下のコードは取得したデータをjson形式に変換してから返却するfetchAPIのラップ関数です。
getUserはfetcherを利用して取得したユーザー情報を利用元に返却します。

 

上記のコードだと返却値の型はPromise<any>という型になりTypeScriptの型チェックの恩恵を受けられません。

ここで、使用するのがジェネリクスです。

 

ジェネリクスを使用することでany型を返却しなくても良くなりました。
さらに、ジェネリクスを用いることでgetUserだけに依存することなく、その他のデータ取得関数からも利用可能な汎用的なfetchAPIのラップ関数として定義することができます。

上記の例は戻り値だけでしたが、引数にもジェネリクスを使用することができます。

複数の引数を持つ関数での利用

複数の引数を持つ関数に個別のジェネクスを定義することもできます。

インターフェースでの利用

インターフェースにもジェネリクスを利用できます。

インターフェースを継承したジェネリクスでの利用

ジェネリクスはどの型も使用することができますが、内部のプロパティまで理解してくれるわけではありません。例えば、以下のコードのようにarglengthを使いたいとした場合エラーとなります。

 

なぜなら、全ての型に特定のプロパティが存在するとは限らないためです。これを解決するためにTypeScript側に特定のプロパティが存在することを確定させる制約をかけることができます。

 

上記のように記述することでインターフェースのプロパティを持っているジェネリクスを定義することができます。ちなみに、インターフェースを継承しただけなので length というプロパティを持っていれば他のプロパティも渡すことができます。

まとめ

ジェネリクスを学んでみて以下のような場面で有効に使えるなと思いました。

  • コンパイル時型チェックの恩恵を捨てるようなコード(any型、あるいは型キャストの使用)
  • 型だけ違う実装の大量生産(再利用したい時)

ジェネリクスをこれから学ぼうとしている方に少しでも参考になれば幸いです。

最後に

アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています!ご興味がありましたらお気軽にご応募いただければと思います!

アソビュー株式会社の募集 採用・求人情報 - Wantedly

アソビュー株式会社の新卒・中途・インターンの募集が45件あります。気軽に面談して話を聞いてみよう。職種や採用形態からあなたにあった募集を見つけることができます。募集では「どんなことをやるのか」はもちろん、「なぜやるのか」「どうやるのか」や実…

www.wantedly.com

 
 

10年間のSEOの経験から考えるスペシャリストのキャリア

f:id:m_nishimoto:20220331184140j:plain

アソビュー! Advent Calendar 2021の17日目の記事です。

「週末、なにする?そんな時は、アソビュー!」でお馴染みの遊び予約サイト「アソビュー!」のSEOを担当している西本です。

アソビューは今年で創業10周年を迎え、現在お得なキャンペーンを開催しています。下記ページからご確認頂き、お得にお出かけを楽しんで頂けたらと思います。

www.asoview.com

実は偶然にも今年は僕がSEOに本格的に関わりだしてから10年の年でもあります。そこで今回はこの10年を振返って自分がどのような経験を積み、どう成長してきたのかをまとめたいと思います。SEO業界で無名な僕の自分語りに誰が興味があるのだろう、とは思いつつも、年末でもあるのでキャリアを考える誰かの参考になれば幸いです。

■はじめに

僕のキャリアに対する考え方は、尊敬するインサイトフォース山口さんの書籍「マーケティングの仕事と年収のリアル」を参考にしています。こちらの書籍はマーケターのキャリアについて書かれたものですが、ITエンジニアのキャリアを考える際にも参考になると思うのでお勧めです。詳しくはこちらの記事を参照ください

書籍の中で特定領域のスペシャリストに達した人のキャリアには次の3つの選択肢があると示されています。
・より高レベルのスペシャリストになる
・複数領域のスペシャリストになる
・マネジメントにキャリアをシフトする

ちなみに僕はマネジメントの適性が全く無いことを自覚しているので、スペシャリストとして生きて行こうと考えています。また、1つの領域を100点目指して深堀していくよりも、80点の強みを複数掛合せる方が性にあっているため、そのようなキャリアを志向しています。

この10年間一貫してSEOを自分の仕事にしてきましたが、適度に環境を変えることで、特異な強みが身についているのでは、と考えています。

■ITエンジニア→システムに強いSEOコンサル

元々僕は学生時代からプログラミングをしており、その流れで最初のキャリアはITエンジニアになりました。その後約10年ITエンジニアを経験しましたが、2社目の会社でどうやっても勝てる気がしない凄腕エンジニアの方々に圧倒され技術力で生きていくのを諦め、マネジメント側に方向転換したものの担当したプロジェクトを炎上させたりでうまくいかず、ITエンジニアとしての限界を感じていました。

そんな時に偶然SEOを知り、自分の仕事の成果が明確に数字として現れることに面白味を感じ、「なにこれ、スゲー面白い!」とのめり込んでいきました。ITエンジニアとしてのキャリアに頭打ちを感じていたこともあり、本格的にSEOを学ぶために転職しました。

転職したのはコンサルをメインにするSEO会社でした。ここで偉大な諸先輩方にSEOのイロハを教えて頂きました。元ITエンジニアでシステム開発の知見があるため、大規模サイトのSEO案件を多く担当させて頂きました。現在の僕の得意分野である、大規模サイトのテクニカルSEOのベースはここで作られました。

■システムに強いSEOコンサル→システムに強いインハウスSEO

SEOコンサルの仕事はとても楽しく業務は多忙だったものの充実していました。ただ、コンサルあるあるですが、自分が提案した施策を自分で推進してみたくなり、元々事業会社での仕事に興味があったこともあり、インハウスの立場でSEOを担当出来る事業会社に転職しました。

転職したのは大手人材系の事業会社でしたが、転職して3年ぐらいは辛い日々が続きました。コンサル→インハウスの転職で在りがちな悩みですが、大企業の事業会社でどうすれば組織を動かし自分の施策が推進出来るかが分からず苦しみました。また、それまでビジネススキルを意識したことが無く鍛えていなかったため、優秀な先輩方の仕事に全く付いていけませんでした。

ただ、システム開発の知見があるため、エンジニアの方とは会話がしやすかったように思います。起案した施策の実装が難しい場合は開発工数が抑えられるように要件を調整したりなど、施策が実現しやすいよう考慮していました。ここでも元ITエンジニアの経験が活きました。

■システムに強いインハウスSEO→データとシステムに強いインハウスSEO

3年ぐらい経ちようやく事業会社での仕事の進め方が多少理解でき、表彰されるぐらいの成果も出せるようになりました。

その頃所属していたSEOチーム内にデータサイエンティストの方がいて、一緒に仕事をする機会がありました。その方からBigQueryとRedashの存在を教えてもらい衝撃を受けました。これを使えば、それまでExcelで管理をして更新に毎回時間がかかっていたモニタリングを、全て自動化し数値もグラフで可視化出来ると思い付きました。それからプライベートの時間を全て使いGCPでのデータ分析基盤の構築を学んでいきました。「なにこれ、スゲー面白い!」とデータエンジニアリングにのめり込んでいきました。

それから2年ほど経ち、自分が目指していたモニタリングの仕組みがある程度形になってきました。大手事業会社での仕事も5年が経ち、次はスタートアップで仕事がしてみたいと現職であるアソビューに転職しました。

■データとシステムに強いインハウスSEO→???

アソビューでインハウスSEO担当として仕事をする今の僕には以下3点の強みがあります。
・戦略策定、分析、課題特定、実装、効果検証までの一連のSEO業務遂行
・要件定義、設計、実装、テスト、運用までの一連のシステム開発経験
・データ分析基盤(GCP)×モニタリングダッシュボード(Redash)の構築

SEOという柱となる明確な強みがあり、それを補強する形でシステム開発とデータ分析のスキルが掛け合わされ、それなりの希少性が作れているのでは、と思います。前述した通り、僕は複数の専門領域を掛合せるキャリアを志向しているため、これからも未経験の領域に手を出し、その中から「なにこれ、スゲー面白い!」と思える何かを見つけのめり込み、また新たな自分の強みとして加えていければと考えています。

■さいごに

「生きるに、遊びを。」をミッションに掲げる我らがアソビューでは一緒に事業をつくる仲間を絶賛募集中です。

www.wantedly.com

とにかくエンジニアのリソースが足りずとても困っています。助けてください。

スパゲッティ化して改修困難になったプロダクトをフルスクラッチでリニューアルした話


これはアソビュー Advent Calendar 2021の16日目の記事です。

アソビューCPOの横峯です。

弊社アソビューではアソビュー!そとあそびアソビュー!ギフトというC向けのサービスの他にB向けのサービスもいくつか展開しております。

その一つラフティングやダイビング、陶芸教室などの体験アクティビティと呼ばれる事業者様に使って頂いてるウラカタというプロダクトがあります。

既存のコードをすべて捨てて今年の11月にリニューアルした話です。

📕歴史と経緯

初期のウラカタは株式会社そとあそびで僕が一人で開発してたプロダクトでした。2014年から開始して2年ほど僕以外コミットしてる人がいません。マンションベンチャーで新規プロジェクトだったので最初はもちろんPMFできるかわからない状態です。

という言い訳を元にとてもコードの品質が高いものとは言えない状態でした。とにかく使っていただきたい、使えるものを出したいという思いのもと短期的なスピードを圧倒的に優先し開発していたためテストコードも少なくレビュー体制もありませんでした(一人なのでそりゃそうなのですが...)

その状態で進めていたおかげか多くの方に使っていただけるサービスに成長していき、2016年に会社が株式会社アカツキとMAをすることになりました。※当時の記事プレス

このあと一気に事業を成長させるべく、開発にも大幅に投資します。

多くのエンジニアの方に参画頂いたのですが、コードは読みづらく機能も複雑だったため、改修の難易度がどんどんあがっていきます。

徐々に細かいバグが増え、そのバグを修正してもどこか違う箇所でバグが起きるような状態。この頃には様々なアクティビティ業界の方と話をできる状態になっていたので、市場のニーズは多く理解できてきているが、運用のためのタスクが積み上がってるため、描いたようなプロダクトの成長ができない状態になっていました

開発してる側もつらく、その原因を作った自覚のある僕もつらい状態が続きましたが、それでもその後2年ほど改善を続けプロダクトは成長していきました。が、今度は事業観点で縮小が決定。開発も最小限にしてしばらくバグの改修のみを細く続ける状態でした。

🔨作り直し決定

2018年頃、僕が事業責任者をやることになったタイミングでプロダクトのロードマップを描きなおし、前回の反省を踏まえた上で0から作り直すことを決定しました。

同時にビジネスモデルも変更し、継続的に成長しながらプロダクトをあるべき姿に変えていく構想をスタートしました。

といっても開発体制はほぼなかったので、まずはその構築から。

以前関わってくれていた方を中心にチームを再結成し、前回の反省を踏まえ品質にはこだわりをもってやろうと再スタート。

まず機能の整理からはじめました。

ユーザーストーリーマッピングを全員必読にし、実際に全員ですり合わせました。※これを実施したのはコロナ前なのでリアルボード

現行バージョンは細かい機能がかなり多かったため、すべての機能の使用率を調査し、ミニマムのスコープを定義しました。

今回のリニューアルは今後の中長期的な成長を支える基盤になるもののため品質をとにかく優先しよう。その認識をチームで共通のものにするためインセプションデッキを行い明文化しました。

期日、機能より品質、セキュリティが大事であることを明確に定義。

これがあったことで、そのあと議論になったときに立ち返る場所になったと思います。ユーザーストーリーマッピングもインセプションデッキもよく使われてるツールだと思いますが、改めてその価値を実感しました。

実際、開発を開始してからしばらくするとコロナが本格化して事業としては大打撃を受けたり、会社もMAを実施することになり親会社が変わったりと環境は目まぐるしく変わっていましたが、ウラカタの開発だけはスタンスを変更せず最初に誓った志を保って開発を続けていました。

その結果開発を開始してから2年以上たつ今でも細かいバグもほとんどなく、新しい価値を提供するために多くのリソースを避けていると思いますし、以前のように既存のコードを読み続けてよくわからなくなってるところをドキドキしながら改修するようなことはなく、開発に関わってくれる方のストレスも少ない状態が保てているのではと思ってます。そのため結果的には今後の事業成長のスピードを最大化できる状態が作れていると思っています。

🌈今後

ウラカタは体験アクティビティ事業者の方々の業務を効率化し、集客に貢献できるプロダクトだと思っています。

僕自身、この業界に関わりはじめて知りましたが、体験アクティビティ事業者の方々はほんとにたくさんの業務を少人数でやられています。

朝、新しい予約の確認をして予約申し込み頂いてる方とメールでやりとりをしたあと、ツアーのための準備、実際にツアーを催行してお客様を見送ったあと、翌日の準備、その間も予約申込は続くためその対応を一件一件行っていく。繁忙期は早朝から深夜までは当たり前。多くの事業者様がこれを毎日行っていることを知りました。

ほんとはやりたいけど、できてないこともたくさんあると聞きます。少しでも業務を効率化し、予約を増やすことができれば、お客様との時間や、ツアー自体をどう良くしていくかに時間を使っていただけるのではないか。そんな思いを持って日々開発を続けています。

弊社はミッションとして「生きるに、遊びを。」を掲げています。身をおいてるからこそ、日々遊びが進化し多様化してることを実感をもって感じています。どれだけ多様化してもそれぞれの良さや楽しさがあります。その中で選択され続けるためにも業界全体がサステナブルでより良い状態へ向かっていけるようにしていく必要があると思っています。

僕自身、たくさんの体験アクティビティ事業者の方々とお会いしましたが、みなさん強い思いを持たれていたり、そのアクティビティが大好きだったり目を輝かせて自身の仕事や体験について語ってくれることがとても印象的です。

僕個人のミッションとして「楽しく生きる人を増やす」を掲げています。今ウラカタを通してたくさんの事業者の方々をサポートすることはまさに楽しく仕事する方を増やすことに直結してると感じてますし、多くの方の楽しい体験の時間を下支えしている実感があります。

この波はまだまだ大きくできるし、もっともっと大きくなって世の中の楽しい時間が増えればいいなと思ってます!


そんなミッションに興味もってくれた方も、遊びのSaaSに興味もってくれた方も全方位で仲間を大募集しております!楽しく質にこだわりをもって一緒に開発しましょう!