Slide 1

Slide 1 text

© 2022 LayerX Inc. © 2022 LayerX Inc. リリースから2年。爆速開発を支える バクラクの組織とアーキテクチャ 高際 隼 @shun_tak 株式会社LayerX バクラク事業部 AI-OCRチーム マネージャー AWS Dev Day 2022 Japan

Slide 2

Slide 2 text

© 2022 LayerX Inc. 2 本講演で話すこと ● バクラク事業について ● 文化と開発スタイル ● 開発プロセス ● 組織とアーキテクチャの変化 〜構想からこれまでの約2年〜

Slide 3

Slide 3 text

© 2022 LayerX Inc. 3 自己紹介 高際 隼 Shun Takagiwa 株式会社LayerX バクラク事業部 AI-OCRチーム マネージャー ● 2013年サイバーエージェント新卒入社。テックリードとして複数のスマートフォンゲー ムの新規開発および運用を担当。その傍ら組織運営や新卒採用にも携わる ● 2018年LayerX設立とともに参画。PMやテックリードとしてブロックチェーン事業 に携わる。バクラク事業立ち上げ後はAI-OCRを主軸にバクラクの開発に注力。現在 AI-OCRチームのマネージャーを担当 ● 好きなサービスはAWS App Runner ● 価値観 ○ 継続は力なり ○ 強みを徹底的に磨く ○ なんとかなる (きっとよくなる) ● SNS等 ○ Twitter → @shun_tak (本日の資料もこちらで共有します) ○ GitHub → shun-tak

Slide 4

Slide 4 text

© 2022 LayerX Inc. 4 会社名 株式会社LayerX(レイヤーエックス) 代表取締役 福島 良典 / 松本 勇気 創業 2018年 8月1日 従業員数 101名(2022年6月時点) 資本金 31億円 事業概要 バクラク事業、Fintech事業、PrivacyTech事業 関連会社 三井物産デジタル・アセットマネジメント (三井物産、LayerX、三井住友信託銀行、SMBC日興証券、JA三井リース、イデラキャピタルマネジメントに よる合弁会社) お取り組み実績 取得認証 情報セキュリティマネジメントシステム、JIIMA認証 一部抜粋 * 資本準備金含む  ** 全事業含む IS 747702 / ISO 27001 会社概要

Slide 5

Slide 5 text

© 2022 LayerX Inc. 5 バクラク事業 企業活動のインフラとなる法人支出 管理(BSM)SaaSを開発・提供 LayerXの提供プロダクト Fintech事業 ソフトウェアを駆使したアセットマネ ジメント・証券事業を合弁会社にて 展開 PrivacyTech事業 パーソナルデータの利活用とプライ バシー保護を両立するソリューション の提供 本日のスコープ

Slide 6

Slide 6 text

バクラク事業について

Slide 7

Slide 7 text

圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。

Slide 8

Slide 8 text

© 2022 LayerX Inc. 8 法人の支出管理の流れとよくある課題 請求書処理や経費精算は、「紙」が多く、「手作業」も多い、最もアナログな領域の一つ - 紙でのやりとりが中心で、手入力や目視でのチェックが多く、ミスも発生しやすい。 - 複数のサービス間でデータが連携されずに、確認工数が増加しやすい。 回収 稟議 承認 データ 入力 仕訳/支払 データ作成 支払 保管/税務・監査対応 会計ソフト反映 「手入力だ大変」 「記入ミスで手戻り」 「承認し忘れる」 「承認が多く大変」 「手入力が多い」 「ミス・手戻りが多い」 「仕訳作成/確認が大変」 「支払データ作成が大変」 「属人性が高い」 「データ転記が発生」 「同じ情報を何度も手入 力目視チェックが大変」 「紙で保管、共有が大変」 「税務・監査対応。過去データを出すのが大変」 現場・全社の課題 経理の課題 経理/総務の課題 「請求書が来ない」 「領収書がない」

Slide 9

Slide 9 text

© 2022 LayerX Inc. 9 手作業が多くなりがちな支出管理業務のデジタル化を一気通貫でサポート 管理部門だけでなく、現場社員からも喜ばれる圧倒的な使いやすさにこだわっているため、 ITツールが苦手な方でも安心してご利用いただけます。 現場・全社の課題を解決 経理の課題を解決 経理/総務の課題を解決 回収 稟議 承認 データ 入力 仕訳/支払 データ作成 支払 保管/税務・監査対応 会計ソフト反映 デジタル受け取り 自動受け取り スマホ ・ Slack AI OCR 自動入力 API連携 ・ 自動出力 クラウド管理 ・ 電子帳簿保存

Slide 10

Slide 10 text

© 2022 LayerX Inc. 10 バクラクシリーズラインナップ * 経費精算のSlack連携は申請内容の通知のみ 稟議・支払申請・経費精算・ワークフロー ・AIが領収書を5秒でデータ化 ・承認はチャットアプリから ・シームレスな内部統制構築 仕訳・支払処理効率化 ・AIが請求書を5秒でデータ化 ・仕訳データを自動学習、 手入力ゼロへ ・改正電子帳簿保存法に対応 ・利用料無料 ・即時追加発行 ・最大1億円決済可能 法人向けクレジットカード ・無料で始められる ・手入力ゼロで証憑管理 ・改正電子帳簿保存法に対応 帳票保存・ストレージ

Slide 11

Slide 11 text

© 2022 LayerX Inc. 11 バクラク事業の特徴 多様な顧客の多様な業務課題に取り組む ● 使いやすく、シンプルに実現する難しさ (プロダクト開発) ● 適切な提案をし、顧客の成功まで併走する難しさ (営業、オペレーション) 顧客との接点が多く、距離が近い ● 仕様案について、いつでもインタビューできる ● 商談のたびに顧客からフィードバックをいただける (嬉しい!盛り上がる!) 売上と提供価値が一致 ● 請求書の処理枚数に応じてX円、経費精算のアカウント数に応じてY円といった料金体系 ● プロダクトを磨けば磨くほど、顧客も我々も成功する (WIN-WIN) ● 営業も自信を持って活動できる

Slide 12

Slide 12 text

文化と開発スタイル

Slide 13

Slide 13 text

© 2022 LayerX Inc. 13 チャレンジを促進し、失敗を活かす組織の風土を大切に 口では「チャレンジしよう」と言っても、失敗を責める文化であったり、失敗からの学習がなされない文化の会社では、チャレンジと いう言葉自体が形骸化します。チャレンジを支える文化、失敗を活かす組織の風土こそ最も大切なLayerXの資産です。 「NoじゃなきゃGo」 「Bad News First」 「人を責めず、仕組みを疑う」 「大きな失敗を防ぐため、小さく失敗しよう」 補完 ここだけ主張しても形骸化 チャレンジの文化は、 失敗からの学習・失敗への態度 とセット 失敗からの学習・失敗への態度 参考: LayerX羅針盤

Slide 14

Slide 14 text

© 2022 LayerX Inc. 14 爆速開発 開発速度が速いとは、顧客への価値提供(アウトカム)が速いこと そのために気をつけていること ● 使われないものを作らない。作れば必ず負債になり、のちの開発速度を落とすことに ● 作るからには作るに値するものをつくる ○ 紙芝居やベータ版を素早く作り、顧客やドメインエキスパートにヒアリング ● でも、言われた通りにつくらない ○ ひたすら複雑なものができる。それは使われない ■ 複雑なものは何かおかしいという嗅覚 ○ 真のペインを解決する抽象化したものをシンプルにつくる ● 体験を磨き込む ○ 「こんなことできるの?」、「この業務もうしなくていいの?」というWow、感動体験を届ける ○ コンシューマ向けサービスで当たり前の体験をビジネスアプリケーションにも 参考: 開発速度が速い #とは

Slide 15

Slide 15 text

© 2022 LayerX Inc. 15 開発スタイル デモ駆動開発 ● 週次のスプリントレビュー (デモ) にて全員が成果物を見せ合う ● 作ったものをデモを通じて即座に試し、良し悪しを検証する ● 営業やカスタマーサクセスを含む事業部全員が参加し、次の商談にすぐ活かす 背中を預け合う開発 ● 一人ひとりが仕様策定〜開発まで一気通貫してオーナーシップを持って開発 ○ 企画待ち、デザイン待ちといったボトルネックが解消される ● 作りながら修正するのは当たり前で、そのコミュニケーションコストが減る 職種を問わず、誰もがドメインを貪欲にキャッチアップ ● SaaSも経理業務も経験者が乏しい中で、各自が勉強し、顧客ヒアリングし、突き進む ● 自分の担当施策は、「自分がやらなきゃ誰がやるんだ」という気概で取り組む ○ PdMやドメインエキスパートと密にディスカッションしつつ

Slide 16

Slide 16 text

© 2022 LayerX Inc. 16 開発速度と品質 スピードと品質はトレードオフではない ● スピードがあるから早く異常に気付き修正できる ● 品質が高いから、バグに追い回されることなく作るべきものに集中でき、さらにスピードが上がる いつでも成り立つ正解はない。開発の状況に応じて重心を変える ● 不確実性の高い開発初期はスピード優先 ○ 属人化しても聞けばいい ○ すぐ変わるので、過剰にドキュメントやテストを作り込まない ○ 設計やアーキテクチャ、セキュリティなど変更しにくいものはこだわる ● リリースして落ち着いたら品質や持続可能性も上乗せしていく ● 法人カードは品質や信頼性を優先して開発 DevOpsやQA (品質保証) においては、仕組み化・システム化・自動化を推進 ● terraformでAWSやDatadogのリソース管理 ● Autify (E2Eテスト自動化プラットフォーム) を導入し、E2E自動テストを構築

Slide 17

Slide 17 text

開発プロセス

Slide 18

Slide 18 text

© 2022 LayerX Inc. 18 OKR (Objectives and Key Results) 組織の目標管理にOKRを導入 (2022年4月〜) ● 事業、チーム、個人で方向性を揃え、事業として達成したい目標に全員で向かうことを目的とする ○ きれいにOKR自体を運用することが目的ではない ○ まだまだ未熟な会社・フェーズということもあり、多少のカスタマイズ・あいまいさを許容して運用 ● OKRを達成したかどうかは評価の対象外。そのプロセスを評価する AI-OCRチームのマネージャーとして1周まわしてみて、高際個人の感想 ● むずかしい…! ○ 目線を揃えるのがむずかしい ○ いい言葉を探すのがむずかしい ● 高い目標を設定することで、自然と俯瞰した視野を得られる効果 ○ これ本当に今やるべきなんだっけ ● 個人OKRに関しては組織に合わせ過ぎず、個人のWILL (やりたいこと・わがまま) を混ぜるといいかも (検証中) ○ 職務経歴書に書けるような、面接でアピールできるような大きな成果を ○ 個人の成功が事業の成功につながるように

Slide 19

Slide 19 text

© 2022 LayerX Inc. 19 スクラム開発 バクラクの開発プロセス管理にはスクラムを導入 ● プロダクトごとにスクラムチームとバックログが存在 ● 大型のプロダクト横断機能はプロジェクトチームをつくり、それ専用のバックログを立てて管理 ○ 例: 経費精算の新規開発中 → リリース後は申請チームに吸収合併 スプリントの流れ (AI-OCRチームの例) ● 2週間で1スプリント ● 毎日朝会を実施 月曜日 火曜日 水曜日 木曜日 金曜日 全社週次定例 事業部週次定例 スプリント計画 Stagingリリース QA 本番リリース レビュー会 全社週次定例 事業部週次定例 スプリント見直し Stagingリリース QA 本番リリース レビュー会 振り返り

Slide 20

Slide 20 text

組織とアーキテクチャ

Slide 21

Slide 21 text

© 2022 LayerX Inc. 21 プロダクトリリースと開発組織の拡大 およそ1年に3個のプロダクトの公開・利用開始 内部サービスも次々と増加 (認証基盤、メール受け取り、タイムスタンプ、OCR基盤、データ基盤など) 2021年 2022年 2021/01 2021/04 2021/11 2022/05 2022/08 ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 22

Slide 22 text

© 2022 LayerX Inc. 22 2年間ざっと振り返る ● 2020 (新規開発) ○ スピード!スピード!スピード! (あんま記憶ない) ● 2021 (リリース後) ○ 引き続きスピード&品質も追求 ■ 負債は借り入れ。レバレッジは効くが、利息もつくので返済タイミングに注意 ○ 法人カード検討の新規企画立ち上げ ○ 秋から機械学習チーム立ち上げ ● 2022 (運用2年目) ○ 組織が拡大 ■ バクラクCTO兼CPOの榎本(mosa)を新規に集中 ■ 各プロダクトにマネージャーとPdMを設置 ■ 事業部人事 (HRBP) を設置し、マネージャーをサポート ○ 負債の返済 ■ 急上昇するユニットテストのカバレッジ ○ Product Enabling Team立ち上げ ○ 新たな大型プロダクト横断機能の開発プロジェクト立ち上げ

Slide 23

Slide 23 text

© 2022 LayerX Inc. 23 立ち上げ初期 (2020年 夏〜秋頃) ● 事業責任者、CEO、エンジニア、事業開発、人事など9人で立ち上げ ● SaaSと業務のデジタル化をキーワードに、全員で手分けして100社を超える企業にヒアリングを実施 ● インセプション・デッキを策定 ● 1年後のゴール、逆算した中間目標と具体的なアクションプランを策定 ● 開発!営業!開発!ヒアリング!開発! 我々はなぜここにいるのか 「コロナ禍による非対面の拡大」「SaaS拡大 」「規制緩和」(銀行法 や電帳法)「労働人口低下」 という外部環境の中で、 LayerXが実際に大企業と向き合ってきた経験や知見と、 ソフトウェア文化 (UXのこだわり、継続的改善、機能絞り込みな ど) の強みを活かすことで、 企業内の業務をデジタル化し、ワンストップな業務フローを実現す ることで、単純作業や反復作業をなくし日本の生産性を向上させ るため。 やる やらない スピード!スピード!スピード! PMF前に拡大しない(広告マーケ) 泥臭くカスタマーサクセスを追求 顧客の悪口を言わない、情報を出さない 使われるものを作る 自己満足な開発をしない KPIを科学的に分析 中にこもらない(顧客の声を聞く) 全員カスタマーサクセス 軸のないピボットをしない 少数精鋭 遠慮しない、チームに垣根をつくらない

Slide 24

Slide 24 text

© 2022 LayerX Inc. 24 新規開発中 (〜2020.12) 組織 ● エンジニアからセールスまで全員で一つの事業部 ● 11月まで毎日全員が顔を合わせ、商談や開発の共有 ○ 12月から週次に移行 事業部

Slide 25

Slide 25 text

© 2022 LayerX Inc. 25 新規開発中 (〜2020.12) アーキテクチャ ● フロントエンド: Typescript+Nuxt, サーバーサイド: Go+MySQL, API: REST ○ 立ち上げチームが手慣れた技術を活用し、スピードを優先 ● マネージドサービスをフル活用する等ベストプラクティスを踏襲し、プロダクト開発に集中 ○ 当初からIaC (Infrastructure as Code) を実践 ■ 再現性・自動化・レビューしやすさを担保 ○ ネットワーク制御、アクセスポリシー管理、鍵管理、ファイアウォール等によるアプリケーションの多層防御を実践 ■ 請求書を扱う性質上、セキュリティは重点対応。後から変更しくいこともあり、初期から丁寧に設計

Slide 26

Slide 26 text

© 2022 LayerX Inc. 26 バクラク請求書リリース (2021.1) 組織 ● 事業開発部・プロダクト部に分かれる ○ 事業開発部: 誰にどう売るかを考え、実行し、顧客のサクセスを実現するチーム ○ プロダクト部: 顧客の真のニーズを理解し、何をいつ作るかを考え、実行するチーム ● 兼務も多数 ○ 全員QA 事業部 事業開発部 プロダクト部 (8名) バクラク 請求書 (4) Domain Expert / QA (1) DevOps (1) AI-OCR (1) Design (1) ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 27

Slide 27 text

© 2022 LayerX Inc. 27 バクラク請求書リリース (2021.1) アーキテクチャ ● 新規開発中は1つのAPIサーバーですべてを処理していた ● UX改善と負荷分散を目的に、重たい処理を非同期処理に分離 ● サーバーサイドはAPIサーバー、ジョブワーカーの2サービスが起動 参考: LayerXインボイスのAI-OCRを支える非同期処理アーキテクチャ / AWS Dev Day Online Japan 2021 APIサーバー メッセージキュー ジョブワーカー

Slide 28

Slide 28 text

© 2022 LayerX Inc. 28 バクラク申請リリース (2021.4) 組織 ● プロダクトバックログも開発担当者も分かれ始めるが、兼務も多数 ○ バクラク請求書チームにPdM (兼エンジニア) が誕生 ● 認証基盤や管理画面はみんなでお世話する バクラク 申請 (2) Domain Expert / QA (1) DevOps (1) AI-OCR (2) Design (1) バクラク 請求書 (2) 事業部 事業開発部 プロダクト部 (9名) ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 29

Slide 29 text

© 2022 LayerX Inc. 29 アーキテクチャ ● バクラク請求書から認証基盤を分離 ○ モノリスも検討されたが、組織もプロダクトも拡大することを見据え、分割した構成に ■ めちゃくちゃ悩み抜いて決めた (参考: 絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ) ● バクラク申請 ○ APIにGraphQLを採用 ○ メインのDBはMySQL採用だが、柔軟な申請フォームに対応するためAmazon DynamoDBも併用 バクラク申請リリース (2021.4) バクラク請求書 認証基盤 バクラク申請

Slide 30

Slide 30 text

© 2022 LayerX Inc. 30 バクラク電子帳簿保存リリース (2021.11) 組織 ● 各プロダクト2〜3名で開発してる ● 兼務もたくさん ● バクラク請求書にはPdMがいるものの、バクラク申請、バクラク電子帳簿保存のPMは兼務 バクラク 申請 (2) QA (2) DevOps (1) AI-OCR (4) Design (2) バクラク 請求書 (3) 事業部 事業開発部 プロダクト部 (17名) バクラク 電子帳簿 保存 (2) Domain Expert (1) ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 31

Slide 31 text

© 2022 LayerX Inc. 31 バクラク電子帳簿保存リリース (2021.11) アーキテクチャ ● バクラク請求書に含まれていたOCR機能を分離 ● 認証・OCR以外にも複数の内部サービスが立ち上がる ○ タイムスタンプ (電子帳簿保存法の要件) ○ データ基盤 バクラク請求書 バクラク申請 OCR実行 Before バクラク請求書 バクラク申請 After OCR バクラク 電子帳簿保存 OCR実行

Slide 32

Slide 32 text

© 2022 LayerX Inc. 32 バクラク経費精算リリース (2022.5) 組織 ● 兼務がだいぶ減った! ● 各プロダクトにPM, PdMが誕生 ○ 以前はある種みんなで決めていたが、顧客も増えチームも大きくなり、情報や戦略を集約することに ● マネージャーが誕生 ○ 3月まではバクラクCTO兼CPOの榎本(mosa)がプロダクト部ほぼ全員を評価 ○ 4月からQA、DevOps、AI-OCRのエンジニア評価を各マネージャーに移譲 ● 事業部人事(HRBP)が併走し、マネージャーをサポート ○ 参考: プロダクトチームの HRBP として、なめらかに情報を行き来させる価値に気付いた話 バクラク 申請・経費精 算 (5) QA (3) DevOps (3) AI-OCR (7) Design (3) バクラク 請求書 (4) プロダクト部 (34名) バクラク 電子帳簿 保存 (3) Domain Expert (2) 新規企画 (4) ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 33

Slide 33 text

© 2022 LayerX Inc. 33 バクラク経費精算リリース (2022.5) アーキテクチャ ● 各プロダクトのサーバーサイドは以下3サービスで1セットが基本に ○ APIサーバー … インターネットに公開 ○ 内部APIサーバー … Amazon Virtual Private Cloud (Amazon VPC) の内部にアクセスを限定 ○ ジョブワーカー … 非同期処理を実行 ● ソフトウェア面のアーキテクチャ改善に注力 ○ ドメインの切り出し ○ ユニットテスト周りの仕組みを改善 ○ ユニットテストのカバレッジ拡大 ○ 実行時間の長さや冪等性の有無など、非同期タスクを性質に応じて適切に管理

Slide 34

Slide 34 text

© 2022 LayerX Inc. 34 バクラクビジネスカードリリース (2022.8) 組織 ● 7月から申請・経費精算チームにもマネージャーを設置、エンジニア評価を移譲 ○ マネージャーがいないチームも、PdMやTechLeadと各メンバーで1on1を実施 ○ バクラク請求書は9月からマネージャー設置、エンジニア評価を移譲 ● オンボーディングもスムーズに ● 組織は拡大したものの、異動によりDevOpsが減るなど歪みあり バクラク 申請・経費精 算 (5) QA (4) DevOps (2) AI-OCR (7) Design (3) バクラク 請求書 (4) プロダクト部 (35名) バクラク 電子帳簿 保存 (2) Domain Expert (2) バクラク ビジネスカー ド (6) ※人数は業務委託やインターンも含む概算人数です (兼務も多いため)

Slide 35

Slide 35 text

© 2022 LayerX Inc. 35 バクラクビジネスカードリリース (2022.8) アーキテクチャ ● 決済サービスということで品質にはかなり注意して開発 ○ AWS Solution Architectの皆様ありがとうございました! ● 既存のプロダクト開発におけるノウハウを活用しつつ、ソフトウェア面で新たな挑戦も ○ MySQL 5.7 → 8.0 ○ TypeScript+Nuxt → TypeScript+React

Slide 36

Slide 36 text

© 2022 LayerX Inc. 36 Product Enablingチーム誕生 (2022.9) 開発チームの生産性を向上するProduct Enablingチームが発足 ● より生産性高く、爆速に開発できるアーキテクチャへと改善 ○ プロダクトカットからドメインカットなマイクロサービスへ ○ Monorepo移行 ○ 公開APIはGraphQL, 内部APIはgRPC ○ 各プロダクトへの導入支援 ● 安心して挑戦できる場をつくる ○ Enablingチームが「どう作るか」に集中し、プロダクト開発チームの生産性を高めていく ■ プロダクト開発チームが「何を作るか」に集中し、顧客と向き合えるように 参考: 名村卓を迎えたLayerXがイネーブルメント専門チームを設立。プロダクト開発を最適化するアクションとは?

Slide 37

Slide 37 text

© 2022 LayerX Inc. 37 振り返ると 個の力で突破する組織からチームで達成する組織へ ● 少数精鋭でコミュニケーションコストを減らしつつ高速に立ち上げしてきた ● 立ち上げ後は権限移譲して自律分散型の組織を構成 顧客ありきのアーキテクチャ ● 顧客への価値提供(アウトカム)を速くすることを優先してきた ○ 枯れた技術を活用し、「どう作るか」よりも「何を作るか」にフォーカスしてきた ○ 変更のむずかしいデータ設計、セキュリティ、アーキテクチャは最初から丁寧に開発 ● 新規立ち上げのたびに一つずつ新しい技術を取り入れ、より速く、より高品質に ○ GraphQL、React、gRPC、etc. ○ (それも大事だが) 技術的好奇心だけで導入せず、何の課題を解決するかにこだわる ■ 例: HTTPレスポンスにいろんなデータを必要十分に埋め込むのがキツイ→GraphQL

Slide 38

Slide 38 text

© 2022 LayerX Inc. 38 これから プロダクトを横断するプロジェクトの成功 ● まずは現在取り組む横断プロジェクトに注力 ● プロダクトごとにバックログが分かれているが、自律分散型の組織を保つのがだいじ ○ 課題を無視してとりあえずNexusやLeSSを導入という話にはならない ○ より生産性が高く、顧客への価値提供が速い方法を追求 新規プロダクト立ち上げの再現性を生み出す ● スーパーマンに依存するのではなく、誰もがスーパーマンとして活躍できる仕組みづくり ○ 「どう作るか」ではなく「何を作るか」に集中 ● 価値提供(アウトカム)に集中 ○ 使われないものを作らない・言われたとおりに作らない・体験を徹底的に磨き込む 長時間より長期間 ● 良い事業は仕事してて楽しい反面、ついハードワークになりがち。体力には個人差があり、必ず限界がある ● バクラクは3年5年でゴールがあるような事業ではなく、持続的に顧客に価値を届ける必要 ● 持続可能なチームをつくる。不健全な状況を発見し、改善する仕組みづくりを実行中

Slide 39

Slide 39 text

まとめ

Slide 40

Slide 40 text

© 2022 LayerX Inc. 40 まとめ 圧倒的に使いやすいプロダクトで顧客の課題を解決し、わくわくする働き方を提供するため、 プロダクトも組織も変化してきました。 それでも日々いただく要望は増え続け、すぐにお応えできないこともあり心苦しいばかりです…。 今後もプロダクトや組織に投資し、価値提供をもっともっと速め、良い体験を届けていくため、 皆さんの力が必要です! 一緒に最高のプロダクトと体験をつくり、ハタラクをバクラクにしていくメンバーを募集しています! (ソフトウェアエンジニア、機械学習エンジニア、QA、MLOps、SRE、EM、PMなどなど全方位募集中) LayerX 採用情報 https://jobs.layerx.co.jp ご清聴ありがとうございました!