デザインをはじめて10年がたった。
はじめの5年は数人のスタートアップを2つやり、つづく5年はストアーズという会社で製品作りをした。世の中に少しでも価値のあるものを作るために、とにかく昨日の自分を超えていくことだけを目標にしてきた。振り返るほど失敗ばかりで、なんとか辻褄を合わせるくらいしかできなかった気がする。つらい。どうにもうまくいかない日々を10年続けて思うのは、もっと上手くなりたい、ということだけだ。
僕がストアーズに入社したのは2018年のことで、当時はsoiというインスタントECの製品を立ち上げながら、ECと小売とスモールビジネスについて学んでいました。それから5年たち、Coiney（対面決済のPSP事業）とSTORES.jp（ネットショップ構築）のふたつの製品を運営していた会社から、M&Aや新製品開発をとおして6つの製品を提供するまでになりました。僕は気づけばCPOという役割になりましたが、まだ、なんとか、デザインしたりコードを書いたりしています。
この記事は、これまでのストアーズでの僕の歩みと、これからのストアーズの未来についてまとめたものです。もし読まれて気になることがあればぜひランチでも行きましょう。内容については、個人による一面的なものであることにご留意ください。
入社
ストアーズは、2018年の創業時からひとつの製品ではなく複数の製品の連携が大きな価値になっていくことを企図して、CoineyとSTORES.jpというふたつの会社が合併。ふたつの製品を持つ会社としてはじまりました。そのころの僕は、フリークアウトの子会社をクローズさせて、次はなにしようかな〜とフラフラしていた時期でした。いつのまにか入社してsoiというサービスを立ち上げるも、トラクションを獲得しきれないまま継続するか新しいプロジェクトをやるかという岐路にいました。
soiの初期スケッチ
結論、soiをクローズし、CoineyとSTORES.jpをつなぐ製品としてPOSプロジェクトを立ち上げました。当時についてはこちらの記事に書いていますが、2021年にSTORES レジをリリースし、これによってネットショップ、レジ、キャッシュレス決済をつなげて利用できるようになりました。レジはその後の製品連携の中心となり、順調に進化しています。
リリース当時のLP
製品を連携・統合して、プラットフォームという作り方に移行していくために、レジの開発と並行して認証・認可の基盤（Identity Provider）を作りました。IdP が完成してから3年、開発チームの努力のすえに、ようやくすべての製品のアカウントが統合されつつあります。
プラットフォームについては、Steve YeggeのGoogle Platforms Rantという有名なブログを何度も読み返しながら考えていたことを思い出しますが、プロダクトとプラットフォームにはたしかに大きな違いがあると思います。
プロダクトからプラットフォームへ移行するには、より多くの約束と決まりごとを作っていく必要があり（例えば製品間の認証や通信はどうやるかという話から組織体制の話まで...）、そのコストは明らかに単純な製品開発よりも高いです。えぐいです。とはいえ、この投資をやりきれるのであれば、より深く広い課題に小さなチームでアプローチできるようになる実感はあります。
決まりごとのひとつにはデザインシステムもあり、レジのプロジェクトではストアーズの新しいデザインシステムも作りました。どこかで詳しく書く、といいつつ全然できなかったのですが、実はイベントで少し話したことがあるのでその時の記事を置いておきます...
事業や製品の変化が大きいと、求められるものも変わっていくので、デザインシステムもものすごく難しいなと感じています。現在はバージョン2ですが、そろそろ新しいものが必要になってきている感触があったりして...もう少し腰を据えてこのあたりを考えた方がいいとわかりつつできていない日々。toBもありtoCもあり、モバイルもタブレットもデスクトップもウェブもアプリもあるので、誰か助けてほしい...
ふたつのPMI
Coubic（現STORES 予約）
レジとかIdPとかデザインシステムとかを作っている最中の2020年8月、Bain Capitalを中心とする投資家からの資金調達と同時に、CoubicのM&Aが行われました。Coubicにデザイナーがいなかった（つまりデザインデータも存在しない...）こともあり、デザイナーのなかじ（湖中）といっしょに予約チームに入り込みました。
ワシだけオンライン...
Coubicも、CoineyやSTORES.jpと同じく2013年からある長寿デジタルプロダクトなので、積み重ねられてきた歴史に圧倒されながらも理解を進めていきました。スタートアップが死ぬ気でプロダクトを作り続けるとこうなるんだな、というのを見れたのは個人的には感動的ではありましたが、プラットフォームへの統合はまだまだこれからも続く大変な作業ではあります...
PMI初期は、これまでの地続きの機能開発に入り込みながら、投資効率をあげるために名称を STORES 予約に変えるなどのブランド統合を進めつつ、2021年の中頃から本格的に情報設計の見直しと今後のロードマップの議論に入っていきました。
用語とオブジェクトを整理したり
大通りの設計を見直したり
とはいえ、情報整理とUXのざっくりの方向性は示しつつも、予約製品についてはプロダクトマネージャーの西岡のだいちゃんが中心となって開発を進めてくれていたので僕の出番はありませんでした。
予約に関わりはじめた頃のだいちゃん
この数年で予約はものすごく進化していて、チームの努力はすごいものがあります。予約を管理する新しいカレンダーUIや、お客さんが予約する時のUI（予約フローと呼んでいます）などはなかじによるデザインですが、時間をかけてよいものが仕上がってきています。
新しい予約カレンダー
最近リリースした予約フローのフルリニューアル
Shopforce（現 STORES ブランドアプリ）
2021年の終わりにShopforceが合流し、5つの製品が存在するようになりました。元々は店舗向けのスタンプカードアプリを提供していましたが、OMOの流れでロイヤリティプログラムとCRMの機能を備えたブランド独自のスマホアプリをつくれるShopforceというサービスを展開するようになり、いまではSTORES ブランドアプリという名称でサービスを提供しています。
Shopforceには元々デザイナーがいたことと、大きめの事業者さま向けのセールス主体の導入製品だったこともあり、僕はこのPMIにはほとんど絡みませんでした。
猿田彦珈琲さまやMARKS&WEBさまなどの企業にもご利用いただいています。
山籠り
2022年の夏。バタバタとしていた時期が少し落ち着き、先のことを考えられそうな機運が高まっていました。この頃は、製品ごとに事業部があり、それぞれにPLと開発ロードマップを作っていましたが、中期的には製品を統合していこうと考えていたので、短期的な単体製品・事業の成長も実現しつつ、どこに先行投資していくべきなのかを考えはじめました。
考える...
製品が統合された先に何があるんだろうかということを考えたり、それぞれのシステムの境界線はどこか・また既存のシステムもある中でどういった開発体制がよいのかを考えたり、そもそもストアーズが「Just for Fun」というミッションを掲げて実現したい未来はなんなのかということを考えたりしていました。
戦略に頭を悩ますCTOの藤村さん
戦略というものがなんなのか正直わかりきっていない...んですが、このときに決めたのはビジョンと手順と体制でした。2年間で何を成し遂げるのか、その順序はどうなっているか、どういうチームでそれを実現するか。我々の置かれている状況を鑑みたときに、これをやるしかないだろう、というものを最小限の言葉で書きました。
部室
無限に考えていたときに、部室が欲しいとつぶやいたら
部室ができました。
製品を連携させて新しい価値を作っていくために、山に篭って考えたことをプロダクト戦略という大袈裟なタイトルのドキュメントにまとめ、事業部横断の3つのプロジェクトを立ち上げました。
1/ Kit プロジェクト
2022年の10月に、新しいプロジェクトをひとつはじめました。プロジェクト名はKitといい、長期で我々が実現したいことを少しずつ進めていくことを目論んだプロジェクトで、それは人々が持つリモコンアプリのようなものでした。
STORES 自体をもっとうまく、もっと早く作るということも進めながら、並行して、 STORES をもっと柔軟に扱えるようにするリモコンツールのような、やったほうが良いことを教えてくれるアシスタントのような、そんなスマホアプリを考えている。売上や KPI を教えてくれたり、注文や予約や問い合わせがきたら作業しやすいように整えてくれたり、繰り返しの業務は Kit におねがいして半自動化させたり、作業を起点に従業員間のコミュニケーションがうまれるような環境をつくれたり。サイトのコンテンツを更新したり、対面しているお客さんに聞かれたことを即座に調べたり、その場ですぐに決済したり。店舗や事務所、カウンターや倉庫に行かなくても、非同期的にどんな時間帯でも、かんたんな仕事はサクッと片付けられる。業務やデータをデジタル化していった先の、より柔軟な働き方を実現するもの...。
仕事をもっと理解する
小売やサービスの仕事をもっと詳しく理解するとともに、仮説を確かめていくためにいろんな方に会いにいきました。
会いにいく
たとえば、ShopifyのInboxアプリは、ECからお問い合わせのあったお客さまのカートの中身を見ることができるので、質問が来て、それをスマホで確認し、回答しながら接客することができるようになったりします。店舗の在庫が少なくなったときの倉庫や事務所とのやりとり、アルバイトのかたへの指示の出し方やマニュアルの作り方、毎晩見るサイトへのアクセスログ。工夫のなかにソフトウェアがあり、ソフトウェアによって制限もあるという事実を理解しました。それは僕らの仕事の中にもあるものです。
プロトタイプを作り、フィードバックを得る
かんたんなプロトタイプを作り、いくつかのお店に使ってもらいました。お店の状態や注文、お問い合わせを通知してくれるものを初期的なプロトタイプとして使ってもらうことで、どんな変化が起こるかを確認することにしました。
プロトタイプ
通知を起点に仕事がはじまるものと、はじまらないものがあり、また分業されていくほど全体の情報を浴びる価値が減ってくるし、スマホで行う必然性が下がることが見えてきました。この製品が価値を発揮していくには、まだまだ出せるデータが少なかったり、各製品の機能を使うためのAPIが整っていなかったりしすぎていて、想像以上に道のりが長いと感じ、結果として、このプロジェクトは一時凍結としました。LLMの進化もあり、来年あたりに再開するとめちゃくちゃ面白いものができそうな予感がしてるので楽しみです。
データ分析をちゃんとやる
リモコンアプリの実現の前に、まずはきちんとデータを統合して扱えるようにしていこうと考え、ストアーズにあるデータを統合して分析できる機能の開発を進めています。Kitの開発を引っ張ってくれたエンジニアの大久保さんに引き続き引っ張ってもらいながら、経営のレイヤーでも事業者さまを支援していくソフトウェアを実現するとともに、ビジョンの実現を目指したいなと思っています。
プラットフォームの上でのものづくり
横断的で包括的な機能を作ろうとすることで、横断的な仕組みが整備されていく... 価値を届けるために基盤が不可欠という状況を生み出すことで、プラットフォームという作り方に移行していきやすいことが、Kitプロジェクトを進めたもうひとつの理由でもあったのですが、それは確実に実行されていったように思います。このプロジェクトによって、新製品と既存製品をつながないといけないからAPIの決めができる。非同期でやりとりする仕組みがないといけないからwebhookができる。という形で、さまざまな仕組みが実現され、後続のプロジェクトでも活用され製品連携が進んでいきました。
2/ アプリテ プロジェクト
2023年の春ごろから、ネットショップ、レジ、ブランドアプリを連携させるプロジェクトをはじめました。レジプロジェクトの構想にあった、オンライン・オフラインをまたいだCRM機能の提供をついに実現するプロジェクトで、アプリとリテール（ネットショップ・レジを開発していた組織名がリテール事業部門だった）を連携させるということでアプリテというプロジェクト名をつけました。
この連携によって、実店舗とネットショップの顧客情報・購買情報が連携でき、「いつ・だれが・どこで・何を買ったのか」を一元管理できるようになりました。お客さまにアプリ上のバーコードをレジで提示してもらうと、ポイントを貯めたりランクごとの優待が受けられたりといったロイヤリティプログラムを実現できます。
元々ブランドアプリはShopifyやスマレジなどの他社製品と連携させて利用できる状態からはじまっていたものの、ストアーズの製品とも連携させて利用できるようにすることで、設定や運用も簡単になり、問い合わせ窓口の一元化やコストも抑えたサービスを提供できるようになりました。
10月には、この連携を利用した初のアプリがリリースされました。
■公式アプリ リリースのお知らせ
— harapeco (@harapeco_store) September 25, 2023
STORESアプリより「harapeco」公式アプリが完成しました。
今後、アプリならではのお得な特典や情報を配信していきます。
どうぞお楽しみに。
▼詳細https://t.co/QlxuHq8CRB pic.twitter.com/fYiAqXpvCj
このプロジェクトは、ブランドアプリ事業を見ていたこうだいさんやプロダクトマネージャーの淺田さんを中心に進めてもらい、デザインは松岡さんにぶんなげ頼りいい感じにしてもらいました。すでに多くの事業者さまが利用をはじめています。Kitプロジェクトで作ったwebhookの仕組みを使って実現していて、プラットフォームの利点を垣間見たプロジェクトでした。
3/ サーポス プロジェクト
2022年の末から、サービス事業者さま向けの予約とレジを連携させるプロジェクト（通称サーポスプロジェクト）の検討をはじめました。23年の3月頃から本格的に開発がスタートし、今年の1月にリリースしました。このプロジェクトを率いてくれただいちゃんと、今年第二のサーポスと呼ばれているプロジェクトを率いるプロダクトマネージャーの宮里さん（通称：みやっさん）の対談もこちらで読めます。
サービス業に特化したPOSレジは、予約システムと一体になっているものが数多くあるので、僕らがまだ連携していないこと自体がギャップのある状態でした。フィットネスなどの会員制ビジネスを行っている事業者さまにも数多くの声をいただいていましたし、これから美容やサロン業界の事業者さまにもご利用いただけるサービスになっていきたいということもあり、予約とレジのシームレスな連携はなくてはならない機能だと考えました。
（そしてこれが地獄のはじまり...）
事業者と店舗と従業員
予約とレジを連携させるには、事業者と店舗と従業員の概念を揃える必要がありました。僕らは個々に進化してきた製品を持っているので、ある製品は1つのアカウントがイコール事業者になっていたり、ある製品はイコール店舗になっていたり....店舗数の多い事業者さまのニーズを解決するために、アカウントをまとめる親アカウントのようなもの（本部アカウントのようなもの）が存在していたり、フランチャイズは事業者が階層化するのではという話がでてきたり…あらゆるパターンが揃っているんじゃないかという状態になっていました。
わからん
また、ネットショップと店舗をシームレスにつかえるように作っていたことで、統合するにはそのあたりの構造もむずかしくなっていました。はじめからこいつはやばいとわかっていたので、僕や藤村さんや浅田さんも加わりながら、総力戦でこの問題を解きほぐして、これからのプラットフォームを支える土台を作っていきました。アカウント作成や事業者、従業員の登録をどうにかするデザインは木倉谷くん（通称：京都の灰色キクラゲ）に奔走してもらいました。も〜〜本当に大変だった。M&Aした製品やシステムをマジで統合しきるなんてことをやっている会社はあんまりないんじゃないでしょうか。大変すぎるもん。
ただ、このプロジェクトによって、プラットフォームとしての基盤システムや、開発環境の整備、横断的な視野を持った開発メンバーが増えていったこともあり、ストアーズのプロダクト開発が一段進化したと感じています。
レジ v2.0
プロジェクトの後半には、レジアプリで予約を扱う方法を考えていました。予約システムでは、予約時にクレジットカードや回数券などで事前にお会計をしておくパターンと、来店して現地で支払うパターンがあり、レジを利用するのはこの現地払いのときではあるものの、予約の確認や管理自体もレジでできた方が使いやすいので、レジが基本ではありつつも予約機能を内包するアプリをどうすればわかりやすく実現できるのかをデザイナーのりょうこさん（氏原）とすなすな（砂田）と考えていました。
基本構造を考える
カートが複雑になってきたのでシンプルになるまで考える
情報爆発がおきて崩壊した予約詳細画面を考える（左：初期、右：最終）
最終的に出来上がったのがこちら
予約したメニューのお会計と、現地でオプションサービスや物販の購入を追加しても同時にお会計ができます。誰がどんなサービスや商品をお客さまに提供したのかを自然に記録しておくことができるようになり、従業員の貢献の可視化やサービスレベルの向上のためのデータを集めて、改善アクションを取りやすい仕組みの構築が進んできています。
正直まだまだ改善点が多い状態で、次回の予約をとったり、電話で受けた予約を変更したりするのは使いづらかったりします...。HotPepper Beautyとの自動連携機能をつくったり、その際のポイントやスマート払いの扱いをどうするかだったり...磨き込む余地はたくさんありつつ、サービス事業者さまだけでなく、小売事業者さまにも、来店予約やイベント時の受付などがスムーズにできるようにしていきいと思っています。
リリース
事業者・従業員の基盤のリリースと導入を進めながら、予約と連携したレジをついにリリースしました。もっとくわしいサーポスプロジェクトの話は、だいちゃんが記事にしてくれると思います。
レジアプリv2を申請した喜び
プ会
少し遡って2023年の4月。3つの横断プロジェクトがはじまっていくこともあり、事業部を超えて、いま考えていることや目指しているものを、プロダクト開発チームにリアルに伝えていくことが大事になると考えて、プロダクト会議（通称：プ会）をはじめました。
みやっさんに全体を仕切ってもらいながら、大体1.5ヶ月に1度くらい、年2回くらいオフラインであつまる会になっていて、その時々にビジョンや方針、体制変更の意図の共有だったり、リリースされた大きめのプロジェクトの報告だったり、LT会やワークショップをやったりしています。
デザイナーの遠藤さん（ドラえもん）に毎回作ってもらっているメインビジュアル
第一回プ会
LT会の投票はアヒルの音量だった...
普段自分が担当している製品が、これから他の製品とつながることでどのような提供価値や体験をつくるのか、どのようにつながっていくのか、何をつくる必要があるのか。抽象度も難易度も上がっていくことが予想されるものの、複数の製品の連携をストアーズの強みとしていくために、実際に開発を担う我々が、枠を超えて連携・連帯する力をつけていきたいと考えていました。
今月には9回目のプ会が開催される予定ですが、横断的な動きも増えてきている中でちょうどいい役割として機能してきているのかなと思います。
ブランド
2023年の夏頃、製品連携が進んでいく中で、ストアーズのブランドやメッセージをアップデートする必要が出てきていると感じはじめました。正直、いまだにネットショップの会社だと多くの方が思われていると思いますし、我々のPRやマーケティングやコミュニケーションデザインの拙さを実感するところではあるんですが、僕自身も得意な領域ではないこともあって、どうしていこうかなあと考えていました。
一流ブランドから学ぶ
そもそもアウトプットの量も少なかったので、Xで毎日投稿することを頑張ってみたり、写真を撮り歩いてみたり、長期的に目指すことの話をしたりしていました。
色々作ってXに投げ込む
どうにも方向性が定まらず、そもそもの伝えたいことの整理からはじめるために、すべての要素が詰まっているカンパニーデックを作り直すのがいいだろうと考えました。そこで、デザイナーの荒木こと通称盆栽や取締役のなおこさんと一緒にテキストを書いたり素材を撮影して組み立ててみたりをはじめました。
振り回される盆栽・いしばし・たっきー
商売のためのデジタルな道具
延々と考えながら、柳井正のすごさとか、いつかDrawing and Manualに依頼したいとか思いつつ、代表の佐藤からは「LifeWearに辿り着こうとするな・お前にはまだ早い」と言われ、その通りだと思ったりとか。なんかそれらしいかっこいい言葉やビジョンを考えたりしたくなることと、その実、こだわりや情熱と、ぶち当たった壁を乗り越える戦略実行の積み重ねの歴史によってでしかブランドは形成されないという真実と。実の伴わないマーケティングだけが上手い会社にはなりたくないが、現実はただマーケティングが下手なだけなので、今年はきちんと向き合いきりたいとも思っています。
頬張る盆栽クワイ
なんだかんだ動いていたら、最近ちょっとだけ方向性が見えてきたのでイケる気もしなくもない。盆栽が頑張る。
新体制へ
基盤システムが増え、製品連携が実現されていく中で、これまでの製品ごとの事業部という組織の形が作りやすさと届けやすさの面で課題になりつつあり、2023年の秋ごろから今後の戦略実行に適した組織体制についての議論がはじまりました。
製品開発とGTM
製品を連携して深く大きな課題にアプローチしていくというのは、そういった深い課題を抱えるサイズの事業者さまにも利用していただけるようになっていくという話でもあります。もちろん個人やスモールチームが安価に強力なツールを使って商売ができることも、これまで同様より良いものにしていきながら、お店が成長していく中でもストアーズを使い続けてもらえる状態になりたいと考えていました。
経営合宿で出来上がる未来（なんだろうこれ）
また、製品の作り方は横断的になっていくなかで、開発体制も事業部固定ではなく柔軟に動かしたいし、届け方も単体製品ではなくソリューションとして複数製品の提案が求められるようになってきます。プラットフォームなものづくりの方法と、GoToMarketをうまく実現していくことが求められていました。
GoToMarketを推進するための連携
結果として、2024年からはビジネス、プロダクト、テクノロジーといった、機能別組織に近い形の組織構造に変化しました。とはいえ、製品や相対する事業者さまの業種業態によって提案も異なってくることや、ラストワンマイルと呼んだりしているんですが、提案の中で既存製品では少しだけ足りないところを素早く対応していく連携をきちんと実行したいこともあり、組織構造とは別にユニットという単位でGoToMarketを進めていく仕組みを導入しました。
ユニット
ユニットは、プロダクトマネージャー、エンジニア、デザイナーなどで構成される開発単位です。開発チームは一定のシステム単位で存在しないと動きづらいものの、プロジェクトやミッションはシステムごとに分けられるものではないので、それをつなぎ、目標を達成するための集まりというイメージです。例えば、小売業界へのGTMをビジネスチームと肩を組んで進めていくというミッションを持っているユニットや、顧客データを統合する基盤を構築するというミッションを持っているユニットがあったりします。
ユニットにはオーナーがいて、全体の戦略と自ユニットのミッションを紐づけてロードマップを作り、製品開発をリードしていく役割を持っています。ユニットは有期で、戦略を遂行するに適した形へ新設・解散・所属の変更を適宜行っていく形にしています。
これはなにも関係のないカレーうどんです（つかれた）
ロードマップ
ロードマップも、各事業部と横断プロジェクトのロードマップがあったものをひとつにまとめました。
財務目標を頭に入れつつ、どんな人たちにどんなパッケージでどう販売していくのかを考え、作る順序と体制を決めれるように考えはじめてはいるものの、実際はまだ手探りを繰り返しながら中期と短期のバランスで組み替え続けるという感じで練度の足りなさを実感しています。まだまだ試行錯誤中です。
朧げなロードマップ
2030年のこと
2010 to 2040
これまでの10年は、ソフトウェア製品の提供を通してできることを増やし、特定領域の課題を解決することをやってきました。ここ数年は、その製品をつないでより深い課題を解決しながら、フロントオフィスのお店、店員、お客さんのリアルタイムに更新されるデータを様々な角度から集積して、付加価値を提供していくための基盤とデジタルな手足を増やしてきています。この計画は、今年から数年、さらに多くの新製品の追加によって進めていきますが、その先にはデータとツール、そこにバンドルされたAIによる経営・事業運営を支援していくという構想があります。
これまで・いま・これから
SaaSの導入とAIの進化によって、経営や事業運営に関する知識や活動はさらに代替可能になっていくと考えています。集められたデータから選択肢を提供することができ、経営判断を助けたり、より多くの業務は自動化されることが期待されます。そうした環境変化によって、商売をはじめたりスケールさせたりするコストが下がっていく中で、個人が持つこだわりや情熱、何かを実現したいという強い意志や哲学が、相対的に希少になっていくのだろうというのがストアーズの仮説です。つまり、意志や哲学などをふくむ包括的な概念として「 Fun 」を持っていることが重要で、そういった「 Fun 」を持つ人を支援していくことが、「 Just for Fun 」をミッションに掲げるストアーズなんだと思います。
また、ソフトウェアの原価が安くなることが予想され、これがビジネスモデルにどのような影響を与えるか、またSaaSモデルの未来はどうなるのか、という疑問も生じてきます。最終的にはレベニューシェアのようなモデルに行き着くのかもしれないし、それはまだわからないものの、いま立ち上がりはじめている変化の先を見つめつつ、足元の価値提供を最大化していくことをやっていきたいと思っています。
新しいやりかた
GitHub Copilotのナレッジベースとかを見ていると、僕らの仕事も大きく変わっていくのだろうと実感できます。人々がエンパワメントされていく先に、僕ら自身の「Just for Fun」の重要性も高まり、僕らがクリエイターとして創造的であるためには、いまよりもずっと審美眼を磨き続けなければならないのだろうと思います。熟達への道は、より厳しくなっていくのかもしれないし、もしかしたらAIとの対話が壁を越えていく助けになるのかもしれません。
スティーブ・ジョブズのインタビューをよく見返すんですが、AIとのチーミングによる創造性の拡張は、想像しているよりも強力な予感もしています。
映画「スティーブ・ジョブズ 1995～失われたインタビュー～ 」特別映像
明日のこと
僕は、仕事を楽しむこと、そして自分たちの信念に基づいて行動することが最も価値ある資源になると信じています。
Just for Funな人たちを後押しし、僕らの暮らす街が多様な商売で溢れ、誰もがこだわりや情熱をもって働き、賑わいが続くことを願って、これからもコツコツ頑張りたいと思っています。
失敗したり、壁にぶつかっても、明日の自分は今日の自分を超えてくれるはずです。
2024年3月15日
お読みいただきありがとうございました。
ここに書いたことは、僕一人では到底実現できるものではありませんでした。多くの仲間と共に実現してきたものであり、これからのストアーズも同様です。こだわりをもち、挑戦し、期待を超えていくために、良い時も悪い時も苦楽を共にできる人と働きたいと思っています。
ストアーズでは、デザイナー、プロダクトマネージャー、ソフトウェアエンジニア、マーケター、セールスなど、さまざまなポジションの採用をしています。少しでも興味をもっていただけたら、採用サイトからご応募いただいたり、僕にでも、身近なストアーズのひとにでも、お気軽にお声がけください。
最高の製品をつくり、届けていきましょう。
