学びの整理 vol.01(Sansan社、Ubie社)
学びを整理するため、少しずつ投稿していきます。
今回は4記事ですが、あと30記事ほど残っています。
※ここ最近、参考になる記事がかなり増え、ひとつひとつに対して細かく整理していくよりも、一旦ざっくり学びのあった内容を引用することにしました。
技術だけでなく、物事の考え方、思考の深さ、志向性、スピード感、キャッチアップ方法、普段の働き方など、学びの多い4記事です。
※重要性を再認識した内容も整理してます。
デザインで事業の成長をけん引する。Sansanのプロダクトデザイン組織の魅力とは
毎週木曜日にはSansanに入社したばかりの人にプロダクトを使ってもらい、ユーザーがどのような点で困るのかなどを確認し、改善につなげる試みも行っています。
プロダクトの情報設計を行う段階では、そもそも絵がないですし、どのようなものを作るのかも定まっていないわけですよ。その段階から、デザイナーと一緒にディスカッションして方針を決めていきたいので、言語化のスキルが高いことは必須です。プロダクトデザイナーとプロダクトマネジャーの担当領域が徐々に重なっていくようなキャリアを、Sansanでは歩めます。
ユーザー思考が強い人であれば「このWebサイトは西場さんが今そうしたようにGoogle検索から来るユーザーが多いので、検索の流れも含めてこのようにデザインします」などと返してきます。
顕在化している顧客のニーズを解決するだけではなく働き方の未来を作るようなソフトウエアを提供したいと、日々の挑戦をくり返しています。
エンジニアからプロダクトマネージャーへのキャリア転換で役立った考え方と本
Running Lean にも書いてありますが、新規事業をやるには以下の３つのタイプを持つメンバーがいるといいそうです。
・ハスラー（事業家）：新事業の世界観を語ってビジネスを設計し、情熱で周囲を巻き込み人間関係を維持、市場を理解して営業もこなし、ビジネスを伸ばす役割を担う
・ハッカー（技術者）：様々な領域の技術に精通してプロダクトを作り、プロダクトを改善し続ける
・デザイナー（顧客体験）：顧客を深く理解し、デジタルサービスの使い勝手の良さや、クリエイティブを通じたプロダクトの世界観を表現し、顧客が体感する顧客体験を担う
【Sansan Tech Talk】インボイス管理サービス「Bill One」の技術的挑戦 〜グローバル展開と開発の複雑性〜
国によってはGDPRに加えてさらに厳しい国内法があるため、対応が本当に大変です。高額な罰金が科される可能性があるため、保守的な判断をせざるを得ないこともあります。現地のアドバイザーと協議しながら進める必要がありますし、そこでの判断がビジネスに与える影響は大きいです。ただ、それも含めてグローバルで事業を展開する際のチャレンジなのかもしれません。
実際にタイ向けに作っている特有の機能があります。タイでは西暦に加えて仏暦も使用されるため、システムで日付を読み取る際に西暦か仏暦かを適切に判断する必要がありました。
私もSGDCの採用プロセスに関わっていますが、レベルの高い人材が増えているのを感じます。その影響でチームの規模も拡大していますね。東南アジア市場向けの開発が加速していきそうだなと思っています。また、プロダクトマネジメントの観点から見ても、非常に刺激的な展開になりそうですね。
ASTとしてパースして書き換えられるktcodeshift*1というツールを作っています。 jscodeshiftというJavaScript向けのツールがありますが、それのKotlin版のようなイメージです。Bill Oneの開発で扱う大量のKotlinコードに対して、大規模な変更を一括で効率的に適用可能です。これにより、手作業での時間を大幅に削減し、リファクタリングの躊躇をなくせます。
スピードというスタートアップ最大の武器をフルに活かすためにUbieがやっていること
- 自分が入社した直後の2月に見つかった事業機会を重要イシューと捉え、推進中の事業の優先度が変更されました。次の週には予備調査を開始し、3月には色々なチームとリソースを調整して新しいチームが組織されました。（ちなみに、今自分がいるチームです）
- 大規模なリソースが必要となる事業の立ち上げで、一旦そのあたりはパンクしたら考えようというスタンスで、最速でサービスをリリース。サービスを提供しながら改善を回していくようなアプローチをとっていた。
などなど。会社全体の意思決定からチーム内の活動に至るまで、スピードが重視されていると感じます。
スピードと引き換えにリスクを取る覚悟
スピードを重視するということは代わりに何かを犠牲にするということです。Ubieでは「スピードを優先するために一定のリスクを取る」ということがカルチャーとして深く浸透していると感じました。
たとえば施策を打つ時に
「これを実行するとこんなリスクがあるよね」
ということを自分が話題に出したことがありました。
その時のチームでの会話はこんな感じ
「それって発生したら最悪どうなる？」
「そのリスクをヘッジしてリリースタイミングを後ろにずらすと、その期間学びが得られないけどどっちを取るべきだろう？」
「どうやったらそのリスクを回避しつつ最速で実行に移せるだろうね？」
「規模をこのくらいに絞ったらリスク抑えつつ早くリリースできそうだね」
「じゃ、明日にはリリースできるかな！」
物事を前に最速で進めることが偉いという価値観のもと、どうやったら最低限リスクヘッジしつつ実現できるだろうということが常に会話されています。
以上です。
学びの整理 vol.02~03も記載いたします。