LayerX エンジニアブログ

LayerX の エンジニアブログです。

GitHub Actions から、ECS でのワンショットタスクを実行する

この記事は、6月から始まっている #LXベッテク月間 6日目の記事です。
昨日は talos さんの 「そろそろあの課題着手しなきゃ!」チームに日々蓄積されるIssueを、Notionで簡単にプロジェクト化〜TODO管理する方法 でした 🐬


バクラク請求書でリードエンジニアをしている @yyoshiki41(中川佳希)です!
最近たどり着いた git で差分があるか確認するコマンドは、git diff --exit-code --quiet です。

バクラクシリーズでは先月(2022年5月)、経費精算をリリースしました! 今後も更にコーポレート業務全体のデジタル化をサポートしていきます。

この記事では GitHub Actions から ECS でのワンショットタスクを実行する仕組みを紹介します。

処理の流れ

このあたりは先駆者となるツールも複数ありますが、Actions 上で実現したいことは大まかに以下です。

  1. コンテナの Build, レジストリーへのPush
  2. Task Definitions の作成
  3. ecs run task の実行
  4. タスクが完了するまで待つ
  5. 完了後のログ(CloudWatch Logs)をひろう

※ ECS スタックの作成や、Actions 側で設定必要なIAM(task 実行や CloudWatch Logs のログ取得)は割愛 🙏

そして最後に、一連をまとめた Composite Action を紹介します。

1. コンテナの Build, レジストリーへのPush

docker 公式でサポートされている GitHub Actions があるため、それを利用するだけです。

ビルド時間の短縮に欠かせない cache についても buildx 側で、GitHub Actions cache をサポート(experimental)しており、レジストリでキャッシュする場合同様に複雑な箇所は特にありません。

buildx で、GitHub Actions cache を使う場合の例

      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2
      -
        name: Build and push
        uses: docker/build-push-action@v3
        with:
          context: .
          push: true
          tags: user/app:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

2. Task Definitions の定義

コンテナの設定とワンショットで実行するタスク定義を行います。

aws-actions/amazon-ecs-render-task-definition で、ローカルの task-definition.json ファイルを上書きします。

    - name: Render Amazon ECS task definition
      id: render-web-container
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: task-definition.json
        container-name: web
        image: amazon/amazon-ecs-sample:latest
        environment-variables: "LOG_LEVEL=info"

3. ecs run task の実行

普段ならここで aws-actions/amazon-ecs-deploy-task-definition を利用するところですが、今回実現したいのは「コンテナのサービスイン => タスク終了 => ログをひろう」という一連のサイクルであるため、AWS が用意する API 叩いて実行する必要があります。

$ aws ecs run-task \
    --region {{ region }} \
    --launch-type {{ launch-type }} \
    --cluster {{ cluster }} \
    --network-configuration 'awsvpcConfiguration={{ vpc_configuration }}' \
    --task-definition {{ family:revision }} \
    --overrides '{"containerOverrides": [{"name": {{ container-name}}, "command": {{ command }} }]}'

最後の --overrideds の部分では、実行時に動的に変えたいコマンドオプションをわたしています。

4. タスクが完了するまで待つ

AWS CLI では、wait オプションが用意されています。(6秒ごとにヘルスチェックをおこない、完了までポーリング)

$ aws ecs wait tasks-stopped \
    --cluster {{ cluster }} \
    --tasks {{ task_arn }}

5. 完了後のログ(CloudWatch Logs)をひろう

AWS CLI で実行したタスクIDのログを取得する方法でこなれたものがないため、ecs-cli を用います。

$ ecs-cli logs --timestamps \
    --cluster {{ cluster }} \
    --task-id {{ task_id }} \
    --task-def {{ family }}:{{ revision }}

ちなみに、AWS CLI で該当のロググループから取得する場合はこちら。(--since でタイムスタンプでのフィルタ)

$ aws logs tail /ecs/your-log-group-name --since=10m

Composite Action にまとめる

github.com

今回、複数レポジトリから使用したいこともあり、一連処理をまとめた Composite Action にしました。(内部の動きは上で紹介したとおりです)

タスク実行後に、PR に対してコメントを残す例

      - name: Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ./infra/migrations/task-definition.json
          container-name: payer-stg-db-migration
          image: image-uri

      - name: Run ECS task
        id: run-task
        uses: yyoshiki41/ecs-run-task-action@v0.0.5
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          task-definition-family: dev-migration
          cluster: dev
          subnets: '["subnet-**"]'
          security-groups: '["sg-***"]'
          container-name: migration
          command: '["up"]'

      - name: Create PR Comment
        run: |
          gh pr comment ${{ github.event.pull_request.number }} --body "<details><summary>Logs</summary>

          \`\`\`
          ${{ steps.run-task.outputs.logs }}
          \`\`\`
          </details>"

GitHub Actions で出来ることが増えいていて嬉しい限りです。今後も CI/CD やデイリージョブを GitHub Actions に載せていきたいと思います!

LayerX ではエンジニア採用をオープンしています。カジュアルに話をする機会などもありますのでお待ちしております!

open.talentio.com

プロダクトチームの HRBP として、なめらかに情報を行き来させる価値に気付いた話

6 月から始まっている #LXベッテク月間 4 日目担当の @serima です。

前回の記事は @shun_tak による MIRU2022 (第25回 画像の認識・理解シンポジウム) にゴールドスポンサーとして参加しますという記事でした! 当日 MIRU2022 へ参加される方、是非ブースにお立ち寄りください。

今回は、LayerX の行動指針のひとつである Bet Technology に絡め、「エンジニアリングバックグラウンドのある私が、HRBP として動くことで感じるメリット」について筆を執りたいと思います。

HRBP の説明についてはエムスリー株式会社の CTO 山崎さんが書かれたこちらの記事が分かりやすいので引用させていただきます。

HRBPとはHuman Resource Business Partnerの略称で企業における人事機能の1つです。 人事機能の中でも特に事業部門の経営者や責任者のパートナーとして事業成長を人と組織の面からサポートする役割を担います。つまり、HRBPは、事業成長のために経営者や事業責任者に伴走し、事業成長のための問題解決を経営者や事業責任者とともに推進することが主要なミッションとなります。

現時点で LayerX では HRBP としてのミッションを明確に定義をしているわけではありませんが、私自身も概ね上記に沿った動きを意識しています。

LayerX における HR チームの立ち位置

LayerX には事業部門として、バクラク事業、Fintech 事業、PrivacyTech 事業の 3 事業が存在しています。

HR チームは人事広報部に内包されており、全社の共通部門として位置しています。

HR メンバーそれぞれの紹介は以下 note に詳細にまとまっていますのでぜひご覧ください。(HR メンバーは現時点で 5 名ですが、7 月から新たな仲間を迎えることになり今からワクワクしています!)

note.com

最近はバクラク事業部以外も採用活動が活発になってきたこともあり、HR メンバーそれぞれが事業部とタッグを組んで採用活動に邁進しています。

バクラク事業部の HRBP について

今回は、私の役割の説明にフォーカスするため バクラク事業部と HR チームの関係性について概略を示します。

この図でいうところの、Product 部門の HRBP(Human Resource Business Partner) の役割を担っています。(ちなみに補記しておくと、HRBP 以外の HR メンバーも事業部とは頻繁にコミュニケーションを取っています。)

Product 部門の HR/HRBP としては現在、主に以下のような活動をしています。

  • マネジメントミーティング
    • CTO 松本、事業部 CTO/CPO 榎本との人事組織面のアラインメント
    • アサイン・組織コンディションの共有
  • プロダクト部門(主に SWE/PdM/Designer)の採用
    • スカウト、カジュアル面談、書類選考、1次面接など選考プロセス全般(新卒・中途問わず)
    • プロダクトチームとの採用定例の実施
  • プロダクト部門のメンバーが活躍し続けられるような支援
    • Manager <> Member 等の 1on1 への同席
    • 事業部全体の定例ミーティングへの参加
    • 必要に応じての個別 1on1 実施
  • Tech PR 活動の支援
    • 技術イベントへの登壇サポート
    • 技術カンファレンスへのスポンサード

こうした活動を通じ社外はもちろん、社内でも多くのレイヤーの一次情報にアクセスする機会を持つことで、それぞれの現場でどのような課題が発生しているのかを比較的早期にキャッチすることができていると感じています。

これらの一次情報をもとに解釈・整理したうえで、それぞれに対してフィードバックをしていくことで組織の健全化に貢献できるような活動を行っています。 (もちろん私も完璧ではないので、私自身もフィードバックをもらいながら前進しています)

「EM と HR は地続き」を実感している話

以前、EM と HR は地続きだったという note を公開しましたが、HRBP 的な活動を通じてさらに確信を強めました。

HRBP としての地の利を活かすことで、以下 3 点が実現可能になりました。

  • 開発の現場へディープダイブし、組織内の一次情報を得ること
  • 多くの採用候補者の方と初回接点を持ち、採用マーケットの一次情報を得ること
  • 採用候補者との初回接点から(入社頂いた場合の)入社後の活躍まで、一気通貫で接点を持てること

そして、これらで得た一次情報をもとに以下のようなアクションが取れるようになりました。

  • HR としての第三者視点を活かし、組織内にフィードバックを行えること
  • 採用候補者の Will に対して「社内に点在する機会」を早期に候補者に伝えられること

事業・組織ともに動きが早い LayerX では、積極的に一次情報を取りに行く姿勢が求められます。しかし、一次情報を得るだけで満足してしまっては意味がありません。

一次情報を「いい感じに」料理し、「いい感じに」情報を伝える必要があります。

実はこういった場面に数多く遭遇するのですが、まさにこの「よしなに力」を発揮するときにエンジニアリングマネージャーとしての経験が活きていると感じています。

EM 的な活動と HR 的な活動をあえて分断せず、なめらかに情報を行き来させること。思った以上に価値があるのかもしれないなと感じており、このポジションの魅力をより一層感じているところです。

そして、これらは事業部の方々の協力で成り立っています。日々の皆さんのサポートに感謝しています!この場を借りてお伝えします!引き続きよろしくおねがいします!

採用・採用・採用!

「HR に ex-EM/VPoE をアサインする意思決定をすること自体が Bet Technology な組織である」こと、入社前から薄々感じていたことではありますが、今なら胸を張って言えます!

HR チームとしては最近ポジションをオープンした HR オペレーションスペシャリスト へのご応募を心からお待ちしています!一緒に Bet Technology していきましょう。

open.talentio.com

あわせてエンジニアリングマネージャーも絶賛募集中です!エンジニアリングマネージャーと HRBP はタッグを組んでこそ双方が価値を発揮しやすいと感じています。Trustful Team やっていきましょう!

open.talentio.com

そして、このような組織でハタラクことに少しでも興味を持ったソフトウェアエンジニア/プロダクトマネージャー/デザイナーの方、ポジション問わず、まずは Meety 経由でお話しましょう!

meety.net

MIRU2022 (第25回 画像の認識・理解シンポジウム) にゴールドスポンサーとして参加します

LayerXは、2022年7月25日から開催される MIRU2022 (第25回 画像の認識・理解シンポジウム) にゴールドスポンサーとして参加することになりましたので、本ブログにて報告いたします!

展示ブースも設置するので、参加される方はぜひお立ち寄りください!

開催概要

画像の認識・理解シンポジウム(MIRU)は、コンピュータビジョン、パターン認識およびその周辺技術に関する国内最大規模の会議で、研究者・技術者・次世代を担う学生などの多種多様な方々が参加されます。

新型コロナウイルス流行の影響で2020年、2021年はオンライン開催となりましたが、2022年はオンライン+現地(姫路)でのハイブリット開催だそうです!

スポンサー参加の背景

LayerXではOCRネイティブなプロダクトの開発をしています。法人支出管理SaaSとして非常に好評いただいている「バクラク請求書」や、今なら利用料半年間無料キャンペーン中の「バクラク経費精算」など4つのプロダクト群からなるバクラクシリーズの開発をしております。

これらの製品を通じてお客様に「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を」提供すべく、画像認識や自然言語処理、情報推薦といった技術を積極的に活用し、研究開発に取り組んでいます。

アカデミアやOSSコントリビューターの成果から恩恵を受けるだけでなく、コミュニティに貢献できればと思い、今回はゴールドスポンサーとして参加することになりました。

今後も LayerX の行動指針である「Bet Technology」と「徳」の観点から、アカデミアや技術コミュニティへの貢献を継続していきたいと考えています。

LayerXブースでは、弊社製品「バクラクシリーズ」においてどんな問題を解こうとしているか、技術的な課題、応用事例等について展示する予定です。また、LayerXからはAI-OCRチームのソフトウェアエンジニアや機械学習エンジニアが現地参加する予定です。参加者の皆様にお会いするのを楽しみにしております。ぜひお立ち寄りください!

Appendix

LayerXおよびバクラクで扱う問題

展示ブースにて詳しく解説いたしますが、本ブログでも簡単に紹介いたします。また、以下の記事もぜひご覧ください。

LayerXがML(機械学習)やデータを活用して解決したい課題|Shun Takagiwa|note

note.com

OCR

バクラクのOCRは、さまざまなレイアウトの文書を受け取り、製品ごとに必要な項目を読み取ってデータ化します。

例えば「バクラク請求書」では、主に請求書ファイルを入力とし、いつまでに、だれに、いくら、もし支払方法が銀行振込なら口座情報は何かといった情報を読み取って出力します。

かなり多様なレイアウトの請求書が入力され、文字認識を実行し、項目ラベルを推定するというのは結構難しい問題だったりします。

製品のUX向上

一般に機械学習の精度が100%となることはありません。精度を高めるべく日々取り組んでいますが、どうしても間違えた結果を返してしまうこともあります。そんな場合でもお客様の業務が煩雑にならないよう、体験・UXの向上に取り組んでいます。

例えば、OCRの読み取り結果に誤りがありお客様が修正するとき、情報推薦技術等を用いて他の入力候補を推薦するようにしています。これにより、キーボード入力を極力減らし、せめてマウス操作だけで完結するようしています。

これら以外にも様々な問題の解決に取り組んでいますが、LayerXでは次々と新製品をリリースしており、将来に渡って様々な問題に取り組んでいきます。

採用情報

LayerXでは画像認識に限らず、自然言語処理、情報推薦、データサイエンスなど様々な専門性をもった方々を大募集しております。解きたい課題が山積みです。

現場のエンジニアだけでなく、経営陣・CEOも本気でやりますと宣言しており、非常に取り組みやすい環境かと思います。

LayerX、ML(機械学習)を本気でやりますという話|福島良典 | LayerX|note

note.com

以下URLは中途採用の求人となっておりますが、学生インターン、新卒採用を希望する方もこちらからお申し込みください。

【SaaS事業】機械学習エンジニア / 株式会社LayerX

open.talentio.com

いきなり応募はちょっと…という方はこちらからカジュアル面談も受け付けております。ぜひお気軽にお申し込みください!

LayerXのAI-OCRについて話します!

meety.net

TrustfulなチームであるためのBet Technology

皆様こんにちは、CTOの松本です。再びLayerXブログ連載企画 #LXベッテク月間がスタートしました。その一環として筆を執らせていただいています。

今回は具体的な技術の話ではなく、LayerXの行動指針に関する解説を兼ねて、Bet TechnologyとTrustful Teamについて書かせてください。特にBet Technologyは開発に携わらない職種の方からはどう向き合えばよいのだろうかと感じられることも多いため、TechnologyのLayerXにおける位置づけを理解する意味でも本記事を読んでいただけると幸いです。

Trustful Team

LayerXの組織文化にTrustful Teamは強く影響を与えています。自分を信頼してほしい、ではなく、他者を信頼し支援するという外向きのベクトルで組織を作っていくためにこの行動指針が重要な合言葉として使われています。

ところで、Trustful Teamとは

各自がプロフェッショナルとして、時にはシビアな判断も含め、実行するチームを目指す。そのためにも、おたがいを信頼し、透明性のあるコミュニケーションを徹底しよう。

と補足されています。仲間を信頼し行動を促すための情報や仕組みを徹底的に用意することで、一人ひとりが自律的に、かつ同じ方角を向いて進めるようにするということを目指しています。

このコンセプトはスタートアップがより素早く顧客価値を探し行動する上で重要な組織の特性を支えるものとなります。多くの場合、スタートアップではこれまでにないイシューやプロダクトに取り組む必要があります。そうすると、未知の課題により多くの答えを見つける必要があるため、チームを構成する一人ひとりが課題を見つけ解決していこうという姿勢が重要なのです。

徹底したトップダウンではなく、ボトムアップな活動を支える事が重要となります。そのために最も重要なことが仲間への信頼と支援であり、Trustful Teamはこれを体現する行動指針となっています。もちろん簡単なことではなく、そのために採用や情報整理などを徹底しています。特に情報の透明性への徹底ぶりはほか企業から来られた方に毎度驚かれるポイントでもあります。

Bet Technology

一方、Bet Technologyと聞くと、特に開発以外の方からすると、ある種遠い価値観というか冷たい・機械的なものと言う印象を持たれる方もいらっしゃるかもしれません。

Bet Technologyとは

技術にBetすることは、より良い未来にBetすることだと私たちは考える。判断に迷ったときは、⻑期的には技術が勝つと信じ、技術に賭ける選択をしよう。

とあります。

一つには、より豊かに、そして多様な人が活躍できる社会を作っていくのは新しい技術であるという背景があります。これはとてもわかり易いものですね。インターネットの誕生やスマートフォンと言った新しい技術の登場が私達の生活を大きく変えてきたことは明らかですし、コロナ禍の中でも新たな働き方で様々な人を支えてきたのも技術の力です。

それ故に、LayerXではOCRや業務を変えうる新たなアルゴリズムの開発を目指して機械学習組織を非常に重視しています。OCRに関わるチームはすでに社内で最大の開発組織となっています。先端の技術を追求し、ユーザーにとってのよりよいUXを作っていくことは、「すべての経済活動を、デジタル化する」というミッションにとって必須のものです。

note.com

一方で、それだけでなくソフトウェア技術を始めとした技術を信頼し、徹底的に活用しようというスタンスも含まれるのがBet Technologyとなります。

ソフトウェアを徹底的に使い仕組み化することは、これまで発見した知識をミスのない仕組みに乗せ、スケールさせていくことそのものであると言えます。

もう少し解像度を上げてみましょう。ソフトウェアによる仕組み化とは

  1. 課題・仮説の発見
  2. 課題解決、どうにか答えを見つける
  3. ソリューション化:解決方法を誰でも使えるよう分析し言語化する
  4. ソフトウェア化:解決方法をソフトウェアで実装する・SaaSを活用する

の繰り返しだと考えています。このサイクルを回していくことで、日々様々な領域が仕組み化されていきます。

さらに仕組みは、一旦作って終わりではなく、更に日々の発見を加えて改善することもできます。改善は一度加えられれば、そのソフトウェアを利用するすべての人に提供されていき、結果としてオペレーショナル・エクセレンスを高めていくことになります。

TrustするためにTechnologyで道具を作る

Trustful TeamとBet Technology

つまり、ソフトウェアを徹底的に活用することで、人の業務を型に落とし込み、そして誰でも使えるようにし、そしてミス無く運用される領域を増やしていくのです。信頼しなくて良い領域を増やすことでより信頼しやすくする、Zero Trust的な考え方ですね。

一度道具になってしまえば、誰もが同じようにパフォーマンスを向上させ、そしてお互いのミスを確認する必要が減っていきます。

信頼が損なわれるタイミングというのは、相手が約束を違える時だと考えています。仕事に対してアウトプットが不安定・属人的な場合、品質を疑い、それを確認せねばなりません。

Technologyで道具を増やしていくことは、疑う部分を減らし、一人ひとりを信頼することに繋がると考えています。

そうした発想で、例えば社内の権限管理をInfrastructure as Codeで定義していこうといった取り組みや、SalesOpsのようなSaaSを活用した営業活動の型化などが生まれていくことになります。

そしてより仲間をTrustしやすい環境が出来上がると、一人ひとりがさらに多くの仮説や課題を発見し解決する余地が生まれていきます。これがさらなる仕組み化を生み出し、日々のオペレーショナル・エクセレンス向上につながっていきます。

Trustful TeamとBet Technologyは両輪であり、この2つが回ることで相乗効果を生み出し、顧客により素早くより良い体験をお届けできる素地を作るのです。

経営の根幹にソフトウェアを

そういった背景もあり、LayerXではソフトウェア的な意思決定もできるだけ経営というレベルでも議論される事ができるようCTOとして取り組んでいます。まだまだやりたいこと、やるべきことは山積しております。

コーポレート領域に目をやれば、よりセキュリティ的なインシデントを減らし効率よく運用される社内ITの構築はまだまだ道半ばですし、プロダクトも営業組織もまだまだ始まったばかりということで仕組み化の足りない領域が多々あります。また、日々新しい発見があり、更に新たなプロダクトも登場するため、日々未知との遭遇といった感じです。

というわけでお決まりの文句になってしましますが全方位で採用中です。少しでもLayerXや、その社内の仕組みにご興味ある方、一度お話させてください。

jobs.layerx.co.jp

もしカジュアルにお話したいという方いらっしゃればmeetyまでお願いします。

meety.net

「スケールする組織か、個がワークする組織か」正反対の意見を持つエンジニア2人が示した方向性

普段、喧々諤々に議論を交わすメンバーが改めて膝を突き合わせたらどうなるのか?──そんなきっかけから始まった、今回のPodcast「LayerX NOW!」。スピーカーは、LayerXの開発組織を牽引する松本勇気と榎本悠介。聞き手はLayerX取締役の手嶋浩己。

実は、前職では同僚だったという松本と榎本。現在は松本がFinTech事業とPrivacyTech事業、榎本がSaaS事業部をみています。「本気でぶつかれる仲」として社内でも有名な2人が“正反対”ながらも議論し続けているLayerXエンジニア組織の理想の形はどんなものなのか?本音を明かしました。

※この記事は[Podcast#47 「正しいプロダクトを作る」LayerXのエンジニア組織について【ゲスト:手嶋×松本×榎本】]の内容を再構成しています。

anchor.fm

LayerXのエンジニア組織は各事業バラバラに見えるけれど…?

手嶋:まず、LayerXのプロダクト組織をどう見ているかを聞かせてもらえますか?

松本:ちょうど1年前に榎本さんとPodcastで話したときにも飛び出していた「爆速開発」がキーワードになると思っています。LayerXでは複数事業を各プロダクトチームが別会社のような勢いで各々集中して取り組んでいるところです。一見バラバラに思えますが、より手数を増やして「正しいプロダクトを作ろう」という思想が各チームで共通しています。なので、Podcastで話していた当時より「爆速開発」を強化していく姿勢がありますね。

手嶋:榎本さんはLayerXの創業メンバーで、ずっとプロダクトをリードしてきた立場です。意識していることなどは?

榎本:プロダクトにこだわれるエンジニアを揃えようとしているところでしょうか。どうすればお客様に喜んでもらえるのか、いいプロダクトを作れるのか、課題を解決できるのか。技術力はもちろん、ドメイン知識やお客様の声を実際に聞いて、職能にとらわれず自分の幅を広げられる組織を推進しています。それができるマインドを持つメンバーも集まっていますね。

先ほど松本さんが話していた「正しいプロダクトを作る」は、本当に的を得た表現です。使われないものを作らないことを念頭に置きつつ、お客様の裏ニーズまで考えながら早くアウトカムを出せるように意識して運営しています。

手嶋:「使われないものは作らない」といった言葉が飛び出しましたが、それを実践するには難しさもあると思います。そのあたりはどうですか?

榎本:LayerXではプロダクト開発にお客様へのヒアリングを積極的に取り入れています。ありがたいことに、すごく共感できる要望をたくさんいただいているんです。しかし、それをすべて聞き入れるのは難しいので、優先度をつけて取り組むべき内容を選んでいます。

お客様はHowのプロではありません。だから、要望にある業務フロー以外のアプローチのほうが課題を根本的に解決できたりする。僕らはいただいた要望を一度抽象化し、集約して、まとめて解決できる機能を考案・開発します。そのためにはお客様の業務フローを徹底的に理解し、ドメイン知識を得た上で踏み込んでいくことになります。これをPMやエンジニアでもできる組織にしたくて、頑張っているところです。

www.slideshare.net

手嶋:LayerX用語でいうところの「裏ニーズを把握する」ですね。松本さんはどうですか?

松本:「使いやすいもの」と「動くもの」は、実は違うんですよね。そして「動くもの」で止まっているプロダクトはけっこう多い。バクラクチームでは「どうすればもっと使いやすくなるのか」を徹底的に考え、アウトプットに反映しています。「神は細部に宿る」と言いますが、今まではtoCサービスで意識されていたものがtoBサービスでも行われているところが特徴です。

「個人に依存しない組織」or「卓越した個人がワークする組織」

手嶋:松本さんも榎本さんも、独立する部門のなかでそれぞれCTOという役割を担っています。松本さんの場合、CTOとして組織全体を理解しようと動いている印象ですが、だからこそ気にしていることはありますか?

松本:僕の仕事の1つは、バランスをとることだと思っています。例えば、CEOである福島さんは今どこにフォーカスすべきなのか、SaaS事業部のCTOである榎本さんの力を活かすためにはどんな体制が必要なのか…。みんなが目の前の仕事に集中できるように、僕は中長期的につまずきそうなところを伝えています。

本音を言いますと、バリバリと現場で働きたい気持ちがあります。ですが、僕はチームを信頼しています。みんなが正しい方向へ向かうために考えごとができるようにサポートしたほうが、僕のバリューを発揮できる。ここは、CTOとして強く意識しているところですね。

手嶋:お2人は近い考えがあるようでけっこう意見が違っていたりします。松本さんはプロダクト組織をスケールさせるために、個人に依存させない考え方がある。一方で榎本さんは少数精鋭なチームで、卓越した個人がチームワークで解決する組織を目指す考え方です。そういった考えを戦わせながら、時には統合させながらLayerXのプロダクト組織は進んでいる印象があります。榎本さんは、このあたりどうですか?

榎本:僕は理想が強く、責任感ある個人が裁量を持って働くことができ、そして背中を預け合えるチームが理想だと思っています。とはいえ、このやり方はフェーズを意識する必要性もあると思っています。立ち上げ期は少人数がベストでも、スケールするなかでは要望やトラブルへの対応が積み重なり、負債も出てくる。必ずしも少人数の組織で動き続けることが健全というわけではありません。

なので、プロダクト組織は少人数で築いたほうがいいと思いますが、成熟したプロダクトに関しては必ずしもその方法がベストだとは考えていないんです。スーパーマンみたいな人を採用できたら実現できる可能性はありますけれど。シニアなエンジニアばかり集めるより、カルチャーがしっかりマッチした若手が活躍できる組織のほうがいいのかもしれないと、松本さんと話していて感じます。そういった濃淡がある組織もいいなぁと思いつつ、やはりスーパーマンみたいな人と一緒に仕事したい気持ちもあり…揺れ動いています。

手嶋:松本さんはどうですか?個人で力を入れるところと、組織としてスケールするところで、今後どうしていこうとしていますか?

松本組織のスケールと、個人の力で開発を進めていくことに矛盾を感じていません。どちらかと言うと、一人ひとりが楽しく仕事ができる状態を作れるかどうかがスケールさせるうえで大事だと思っていますね。榎本さんをはじめとしたスーパーエンジニアがタスクと向き合えるよう、それ以外のことをいかに避けられる状態を作れるかが今後のチャレンジですね。もちろん、そういった場作りと、実際にパフォーマンスを出せる人を採用することに多少の濃淡はありますけれど。

手嶋さんが話しているとおり、僕と榎本さんは社内で一番意見がぶつかる仲です。そのなかでバランスをとりながら体制づくりを進めていくのがちょうどいい塩梅かなと思っているので、今後も意図してバチバチしていきます!

手嶋:補足すると、一応みんな仲がいいんです。初めてお2人の議論に立ち会ったときは少し緊張しましたけれど!LayerXは組織のあり方を青臭く議論し続けていることを伝えたかったのです。

LayerXで追求するのは「業務ごと消し去る」抜本的変化

手嶋:LayerXでは「体験」という言葉がよく使われています。意図的にこの言葉を使っている背景も知りたいです。

榎本:僕らはSaaSを提供しています。つまり、業務に密着したプロダクトを開発しているんです。いかにその業務をスムーズに・思い通りに・今までにないやり方に変えられるかが肝となります。効率化だけでなく、その業務ごと消し去ってしまうほどの抜本的な変化をもたらして「今までは何だったのか」と思われるようなものを提供したいと思っています。

そういえば以前、バクラクを導入した方から「毎月すごく憂鬱だった請求書処理が、バクラクを入れてから楽しみになった」と言っていただけたことがありまして、それがすごく嬉しかったです。

手嶋:それはすごい!業務フローを変えたことで印象に残ったエピソードは他にありますか?

榎本:2022年5月に「バクラク経費精算」をリリースしました。このサービスのこだわりポイントは「申請者がどれだけ楽をできるか」。経理担当者にもヒアリングしたところ「二重で同じ申請が来ないかに気を張ってチェックしている」「月を跨いだ申請に困っている」という声が多かった。そういった業務自体を意識からなくしたかったのです。

そこで意識していたのは「OCRがあることを前提にプロダクト設計する」でした。

今までの経費精算サービスは、書類を一枚ごとアップロードして、支払先や料金、期日を入力していくフローでした。バクラク経費精算ではOCRがあることで、一枚ごとアップロードする必要すらなくしました。さらに一度アップロードすればOCRが書類内容を読み込み、必要項目を自動で入力してくれる。そんな様子がわかるデモを社内で見せると好評で「これだ」と手応えを感じました。

bakuraku.jp

ソフトウェア活用を前提にした経営スタイル

手嶋:LayerXは「奇を衒う」というより、原理原則に忠実に組織運営してますよね。テックカンパニーとして今後目指したいアイディアはありますか?

松本:ソフトウェアを前提にした経営スタイルが僕自身の中でもしっくりし始めています。なので今後は榎本さんが先ほど話していたように「OCRがあればこんな体験になる」を前提に開発を進め、経営していくことになります。そのうえで、みんなが武器にしてきたスキルや経営知識を活かしたらどんな会社になるのか。そんな発想でジャンプアップした組織を作ることが大事だと思っています。

僕が意識すべきは、メンバーのコアを再認識しながら経営していくこと。今後はメンバーがツールを通じて、より自律的に意思決定できるケースをたくさん作っていきたいです。

例えばNotionやZoomで情報をまとめたり残したりして、LayerXのスタイルをインストールするなど。ツール活用は、ソフトウェア経営時代ですごく重要な意味があります。それが自然に、組織づくりのコーディネートにつながっていくわけですから。

note.com

手嶋:榎本さんからまた違う角度の考えはありますか?

榎本:技術を当たり前に、空気のように扱える会社が素敵ですよね。松本さんが話していたように、SaaSやツールを日々の改善に活かし、そのために機械学習やAIなどの選択肢が社内に浸透している。そんな視点が「当たり前」のように社内で浸透している姿が理想です。

技術とはツール活用だけでなく、再現性も欠かせません。意思決定時はデータやダッシュボードを見て、再現性を持って判断していく。そのためには技術や数値が空気のように社内に浸透しているような環境が健全に作用することが大事だと思っています。

LayerXのエンジニア採用で「注目しているポイント」

手嶋:お2人に話してもらったような考えを、新しく入社する人たちへどうやって浸透させているんでしょうか?

松本:前提として、採用はとても丁寧に行っています。CHROである石黒さんが中心となり、「正しい人に応募してもらう」「適切な人が適切なポジションに応募してもらえるように丁寧な発信をする」と、面接でも一人ひとりが妥協することなく仲間集めに徹底できています。

そのなかで、オンボーディングでも課題にぶつかるたびに「LayerXらしさとは?」と仕組みを見直しています。榎本さんがよく言っている「エアプをするな」の言葉も刺さっていますね。先ほどの「裏ニーズ」もあり、きちんとお客様を見てコミュニケーションを促していくやり方を各チームで実践できているところを見ると、採用や文化づくりはうまく進んでいると感じています。

手嶋:技術力の高くカルチャーフィットする人を仲間にするため、どこを重視しているのですか?

榎本:技術力にフォーカスしすぎるとLayerXでのカルチャーにはあまりフィットしなかったりします。そのため、おもに以下の内容も見ていますね。

  • 何をモチベーションにしているのか
  • どんなことにワクワクするのか
  • 何をもって成功を感じるのか
  • こだわったが失敗してしまったエピソードを話してくれるかどうか

手嶋:最近ではVP of EngineeringやEngineering Manager(EM)の募集も続いていますよね?

松本:正直、なぜEMが必要なのかをチーム内で議論している最中です。僕としては、エンジニアのパフォーマンスを最大化するために必要なピースだと捉えています。なぜなら、目の前の開発に打ち込み続けながら、組織運営もしていかなければならないから。スーパーエンジニアたちが最高のプロダクトを作る環境を整えることに対して、興味や面白さを感じるEMを求めています!そういった方がいれば、バクラクは数倍面白いプロダクトになります。

手嶋:今一番EMを求めているのは榎本さんだと思います。何かひと言あれば。

榎本:一言だけ、「助けてください」

僕としても、同じ船に乗って最高のプロダクトを作る組織を一緒に築いていきたいです。これまでのキャリアでも面白い環境下で組織やチーム作りをしてきましたが、今が一番楽しくて速くて、お客様に寄り添えるチームができていると思っています。そんなチームでさらにプロダクト展開していくわけなので、どんな要件のEMが必要なのかはまだまだ話し合っているところ。(まだ整っていないところが多いため)カオスも含めて楽しめる方がいいかもしれませんね。一緒にいいプロダクト・組織をつくっていきたいです!

手嶋:実は松本さんと榎本さんが2人一緒に話すことは珍しく、経営会議でもシリアスに激論しているところも伝えられて、今日はよかったと思います。松本さん、榎本さん、ありがとうございました。

松本榎本:ありがとうございました!

LayerXではミッション達成に向け一緒に働く仲間を募集しています!

jobs.layerx.co.jp

SaaS.tech #3 で登壇しAmazon Cognitoでシュッと認証基盤を作る話をしました

こんにちは、眠れる銭をActivateしたい武市@tacke_jpです。

先日のSaaS.tech #3で、三井物産デジタル・アセットマネジメント(※)で認証基盤としてCognitoを導入した経緯やその実装についてお話させて頂きました。

※LayerXが出資しており複数メンバーが出向しているJVです。

www.youtube.com

speakerdeck.com

当日はLive配信で100人ほどの方にご覧頂きました。ありがとうございました。

登壇内容

少しだけ登壇内容を紹介します。

三井物産デジタル・アセットマネジメントでは社内向けのWebアプリケーションが複数存在しており、それぞれの認証情報を統一して管理したいという要望がありました。各Webアプリごとにpasswordを払い出して保存する方式だと、社内から「パスワード忘れたので再発行してください!」という依頼に毎回対応するのが面倒くさいですよね... これは避けたい。

三井物産デジタル・アセットマネジメントではMicrosoftのAzure ADを従業員のID基盤として採用しているので、外部のSaaSを契約する際はできるだけAzure ADへのSSOを設定してアカウント管理コストを下げています。であれば自前開発のWebアプリでも同様にしたい...!

また現状社内で使っているWebアプリケーションを将来的にパートナー企業にも開放し、メールでのコミュニケーションを代替したいという要望もありました。

というわけで、Amazon CognitoをID基盤として据えて弊社のAzure ADやパートナー企業のID基盤と連携することで、アカウント管理の手間を省けてかつ利用ユーザーの体験もよい仕組みを作りました。

このように既存のサービスのアカウント連携によりpassword管理フリーなWebアプリの認証をシュッと実現したいシチュエーションは結構ありそうかなと思うので、良ければ参考にしてみてください。

最後に

三井物産デジタル・アセットマネジメントでは不動産アセットマネジメント業務のDXを強力に推し進めているのと、個人向けに証券を販売すべく今急ピッチでプロダクトの開発・立ち上げを行っております。ご興味がありましたら、是非以下のFintech事業部のポジションにご応募ください!

open.talentio.com

社内業務も(バク)ラクに ーZoom背景作成をバクラクにしたハナシー

この記事は、【2022 春 LayerX Advent Calendar(概念) 】30日目の記事です。前回はインサイドセールスチームのMJさんの記事でした。

note.com

こんにちは、SaaS事業部でデザインを担当しています森です。

SaaS事業部では経理業務をバクラクにするサービスを提供していますが、今回は社内業務を少しラクにしたお話です。

bakuraku.jp

みなさん様々なツールや仕組みで業務を効率化されていると思いますが、画像作成などのデザイン作業はなかなか人の手から離れていないのではないでしょうか?

当社でも、名前入りのZoomの背景の作成などが、社員が急増しているなかで地味に手間になってきています。

制作はFigmaを使っていて、名前を入れて画像を書き出すだけですが、地味に手間なのとデザイナー以外がその作業をする場合、そのためのライセンスが余分に必要だったりと、問題があるので自動化することにしました。

f:id:hiroakimori:20220411143451p:plain
温かみのあるFigmaでの作業

仕組みを作る上で考えていたことは以下の4つです。

  • コードを書きたくない
  • サーバーを建てたくない
  • インターフェースを作りたくない
  • メンテナンスは誰でもできる

コードを書きたくない

書きたくないです。

画像に任意のテキストを合成して生成することは難しくはないのですが、書かないですませたい。なぜって、

  • どこで動かす?
  • 何で書く?
  • リポジトリは?
  • デプロイは?
  • 誰が管理?

考えたくないですね…

当社mosa_siruの言葉を借りると「作ったものは必ず負債になる」ので、より負債の軽いものにしたかったです。

www.slideshare.net

サーバーを建てたくない

建てたくないです。

  • どこで…(以下略)

考えたくないですね…

インターフェースを作りたくない

作りたくないです。

  • どこで…(以下略)

インターフェースは極力ない方がいいと思う派です。
特定の場所(URLとか)を用意して、使い方を覚えてもらう。それも、毎日使わない機能に… 全然、行動のコストとして見合ってないように思います。

メンテナンスは誰でもできる

コードを書いたり、サーバーを用意したりすれば、それを理解できる人しか管理できなくなります。
開発メンバーが使うツールならいいかもしれませんが、開発以外のメンバーには敷居が高いですよね。

ではどうやって画像を生成するか?

コードを書かないで画像生成する方法を探します。

上記のように制作にはFigmaを使っていたのでFigmaAPIを考えましたが、読み出し系のものしかないので早々に却下。

https://www.figma.com/developers/api

検索をさまよっているうちに、APITemplate.io というサービスを見つけます。

apitemplate.io

レイアウトのテンプレートに、画像とテキストを流し込んで広告画像を量産する、ような用途向けのサービスでしたが、GUIを使ってレイアウトのテンプレートを作成でき、日本語を含むGoogle Fontが使えたりもして機能的に十分でした。

f:id:hiroakimori:20220411143720p:plain
テキストや画像にキーが設定されるので、API経由で差し替えて画像やPDFを生成できます。

インターフェースは?

バグ報告や機能要望の発言にスタンプを付けるとAirtableに起票されたり、情報の取り出し口など、日頃からSlackを使った自動化を行っていることもあり、ほぼSlackだろうと考えていました。

f:id:hiroakimori:20220411145657p:plain
情報の取り出し口

Slackをつかうメリットは、

  • 日常的に使っている
  • 誰かが使っている様子が見えるのでマネできる
  • トラブルや間違った使い方を見かけたら助言しやすい

などがあげられます。

当社プロダクトの「バクラク申請」でも、Slackで申請を承認できる機能は、承認が爆速で進むと評価をいただいており、日頃から使いなれたツールをインターフェースとする事の良さがあらわれています。

prtimes.jp

Slack + APITemplate + Google Drive + zapier

機能の目処はつきました。
Slackを起点として、APITemplateで画像生成、それをGoogle Driveに保存。それらをzapierで繋ぐことにします。

f:id:hiroakimori:20220411143902p:plain
zapierのレシピ

  • Slackの特定チャンネルに、コマンド、氏名、ふりがなの3行で投稿される
  • 氏名、ふりがなをAPITemplateに渡して画像を生成
  • 生成した画像のファイル名に、氏名や日付をつけて、Google Driveに保存
  • 保存された画像のダウンロードURLをSlackで通知
  • APITemplateから生成した画像を消去

使うとこんな感じに画像URLが返信されてきます

f:id:hiroakimori:20220411145003p:plain

生成された画像

f:id:hiroakimori:20220411145932p:plain

これで、手間だった作業がラクになりました。

余談

実は公開してから、コマンドを受け付けるチャンネルを変更していて、旧チャンネルでコマンドが呼ばれた場合、変更の案内を返信するようにしています。これはSlackならではな感じがしますね。

f:id:hiroakimori:20220411145025p:plain

余談2

予想はしていましたがハックする人がでてきました。これはこれで楽しい。

f:id:hiroakimori:20220411145044p:plain

もっとバクラクに

今回は社内業務をラクにするお話しでした。

冒頭でもご紹介したように、当社SaaS事業部では経理業務をラクに、バクラクにするサービスを提供しています。 世の中の業務をもっとバクラクにするために、仲間を絶賛募集中です。是非ご連絡ください!

LayerX 採用情報

LayerX Company Deck

open.talentio.com