LayerX エンジニアブログ

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

Designship 2022にSUPPORTERプランにて協賛します

LayerX は「Designship 2022」をSUPPORTERプランにて応援させていただきます!

Designshipとは

Designshipとは『物語の力でデザインの壁を越える』をコンセプトにした日本最大級のデザインカンファレンスです。

デジタル・グラフィック・プロダクト領域の「デザイン」は、来たるべき第四次産業革命において融合されるべきものであり、それぞれのデザイナーとしての知見は業界を超えて共有できるものが多いにも関わらず、デザインコミュニティは業界内で閉じている傾向にあります。 カンファレンス「Designship」は、そんな分断されたデザイナーたちが壁を越えて一同に会し、学び、鼓舞し合うような機会を提供し、もって国民の創造性向上に寄与することを目的として開催されます。 業界も業種も時代も年代も経験値も越えた、あらゆるデザインナレッジと物語がきける日本唯一の場所として、かけがえのない2日間をお過ごしください。

引用:https://design-ship.jp/

開催概要

  • 日程:2022年11月12日 (土)- 11月13日(日)
  • 対象者:デザイナー、デザイナー志望の方、デザインに興味のある方
  • 主催:一般社団法人デザインシップ
  • イベントサイト:https://design-ship.jp/

スポンサードの背景

LayerXでは、職種問わず、圧倒的に使いやすいプロダクトを目指し、体験にこだわってプロダクトデザインを行っています。

また、経営陣・従業員ともにデザインを必要不可欠なものと考え、様々なプロセスでデザイナーが関わっています。

詳しくはCEO福島、デザイナーの千葉の対談記事をご覧ください。 creatorzine.jp

デザイン業界の発展に貢献できればと、今回SUPPORTERプランという形で協賛させていただきます。

今後もデザインの力で、ミッションである『すべての経済活動を、デジタル化する。』を実現していきたいと考えています。

デザイン組織のご紹介

社内にデザイナーは5名在籍しており、プロダクトデザイン/マーケティングデザイン/コーポレートデザインなどの領域で活躍しています。

しかしまだまだやりたいことに対してデザイナーが足りていない状況です。(特にFintech事業部は喉から手が出るほどデザイナーを募集しています!)

デザイナー視点から見たLayerXの面白さについてはPodcastで語っています! こちらもぜひ聞いてみていただけると嬉しいです。

open.spotify.com

採用情報はこちら

open.talentio.com

オンボーディング関連のシステム作業の時間を87.5%削るまでの軌跡

この記事は、6月から始まっている #LXベッテク月間 38日目の記事です。 前日の記事は@akino_1027さんの「複数プロダクトに散らばったデータ統合に苦労した話」でした。

tech.layerx.co.jp

Oui。CTO室およびFintech事業部で色々やってる @ken5scal です。本記事はSlackの障害中に書いています。 突然ですが、皆さんは当社のイネーブル担当として入社した名村さん(執行役員)がスピーカーとして登場したエピソードを聞いていただけましたでしょうか

名村さんは「コーポレートエンジニアリング(PC、権限、アカウント付与)やオンボーディングがこの規模にしてめっちゃ仕組み化されている」と語っておられます(Podcastエピソードの14:28辺り)。

名村さんのようなレジェンドにWow/Aha体験を提供できたので、30秒ほど胸を張りたくなりますが、 当然、一朝一夕にできた成果ではありません。経営管理部(Corp)、人事、そしてCTO室が長年?積み上げて来た結果です。

本日は、そのようなオンボーディング体験を提供する今日までの軌跡を紹介したいと思います。

tech.layerx.co.jp

TL;DR

最もなれた作業者が45minかかる入社関連のシステム作業を、ステークホルダーとの適切な責任境界とモダン開発による内製化で実働時間10minまで減らしました。 個々人による品質のばらつきがなく、ログによる追跡が用意になり、作業時間の縛りがなくなります。 技術スタックは以下です。詳細な解説については Meetyをお申し込みください。

  • プラットフォーム(AWS): DynamoDB, Lambda, Step Function, ECS, EventBridge, CloudWatch Log, SES
  • 言語: Golang, 一部TypeScript, Terraform
  • CICDパイプライン: GitHub Action
  • 連携サービス: 各種社内基盤サービス

CTO室 屋台骨Engineerって何だ?!それ説明します! - 株式会社LayerXの中の人のカジュアル面談 - Meety

Phase 0 (2020/04~2020/12)

従業員数推移

当時はまだブロックチェーンに関するコンサル事業をやっていたのですが、2020/04にはコンサル事業での学びを反映し、自組織のプロダクト模索がはじまっていました。 今で言うバクラク、Privacy Tech、不動産小口化による証券ですが、当時はまだプロダクトの影も形もなく、大まかに長期・中期・短期での施策を検討していた時期になります。 自分自身も当時はCloudSign APを叩くClientを作ったりしてあーでもないこーでもないと頭を捻っていた記憶があります。

同時にISMSを2021/08に認定を受ける目標を建てるなど、ガバナンス強化もはじめていました。 詳しくは以前かいた「ISMSもとったし、エンジニアだけどITガバナンス主導してきた話をする」というブログを参照きたいのですが、この時にはすでに、クラウドネイティブな環境でのゼロトラスト・アーキテクチャを全体のシステム方針が据え、 それに伴うIDaaS, UEM/MDM, EDR, DLP, SIEMをシュッと導入し、Terraform化したAWSのOrganizationをGithub Actionで用意していました。

ISMSもとったし、エンジニアだけどITガバナンス主導してきた話をする - LayerX エンジニアブログ

ただ、オンボという観点では、そもそも人の出入りもかなり少なく、特に仕組みらしい仕組みはありませんでした。

Phase 1 (2021/01~2021/08)

Pahse1: 従業員数

そんなこんなで、2021/01にバクラク請求書(旧LayerX Invoice)がローンチします。 この時点ではアクセルを踏むことを決定していたと記憶していますが、実際にエンジンの回転数があがってきたのは、2021/04月です。

導入企業数

導入企業数もですが、事業をスケールするために全職種の採用が累乗的な増え方をしています。やばいですねー。 そのイキフンを定例や週次定例から嗅ぎ取り、入社に関する手順書とエクセルシートをガッとつくりました。 ついでに、いわゆるゼロタッチキッティングもこのタイミングでやりました。

この段階ではCTO室における手順のみで、実際の内定や労務に関する調整はアドホックにおこなっている段階でした。 それが2021/07~2021/08に過去にない増加率によりやや危機を迎えます。 アドホックだったので端末の用意などに無理が生じてきたのです。

特にISMSが運用に乗る間近であり、情報の機密性も品質管理する意味で、特定の構成を満たす端末(≒当社管理の端末)での業務を今までになく強化する必要があった時期でした。 業務開始時に端末がないということは論外であり、したがってアドホックではなく、内定者とのコミュニケーションを担当するHR、お財布と労務を管理する経営管理、システムを管理するCTO室が連携を開始するタイミングでした。

Phase 2 (2021/09 ~2021/12)

Phase 2: 従業員数

そうして、できたのが次の入社フローです。当時のHR、経営管理、CTO室でざっくりこんな感じだよね、と話つくりました。2021/09のことです。

入社フローver1

しかし、HRや経営管理においても増員があり、すぐに緩い連携が難しくなりました。 過去にいた方から業務を委譲された新しいメンバーが暗黙的な前提を知ることはできず、以前のような問題が再び浮上してきます。 そのため、新メンバーが来てもある程度、責任範囲や状態を把握できるよう言語化と責任分界を行いました。

入社フローver2

さて、CTO室としての作業は自分1人でも回るレベルでした。しかし、1人あたりの作業量はなかなか多くちょっと悲鳴をあげていました。

当時の悲鳴
右のスクロールバーに注目...

なお、結構多くのサービスがIDaaSからSCIMプロビジョニングされていたと思いますが、入社のフローは組織の状況によって変わるものです。 その状況に適合しやすいようにルールやロジックを組むだけでなく、変化を後続のメンバーが追跡できる形で透明性を持った実装をせねばなりません。 ここで人海戦術を獲ることもできましたが、それは LayerXのBet Technologyではありません 。 是が非にも内製化をすると決めたタイミングです。

が、採用は悠長に待ってくれません。グラフの通り、年度末が近づくにつれ増員数の加速度が高まっていきました。 当時、私はFintech事業部側でファンド運用における自動化のPoCも担当していたので、そちらも合わせると自動化の前にいよいよ破綻する予感が高まってきました。 そこで泣きついたか、見かねた石黒さんが進言してくれたか覚えていませんが(すみません...)、業務委託の募集を開始しました。

Phase 3(2022/01~2021/06)

さて試される大地Phase3です。やばい増加率です。

Phase3: 従業員数推移

幸い、2022/01~2022/06限定で委託をお願いできました。委託先はDXER株式会社様です。マジ感謝。 DXER様にいつもの作業をお願いしつつ(あわせて一部Zapier化してもらったり)、その間に内製化を進め、4月あたりから徐々にデプロイしました。 結論から言うと、この結果、45minの作業が10minまで削減されました。

喜びの舞

本当は技術的な詳細を書きたいのですが、もう十分な長さのブログ(そして遅い時間)になっているので概略のみを記載します(いつか書きます)。 あるいはMeetyより申込みをお願いいたします。

  • プラットフォーム(AWS): DynamoDB, Lambda, Step Function, ECS, EventBridge, CloudWatch Log, SES
  • 言語: Golang, 一部TypeScript, Terraform
  • CICDパイプライン: GitHub Action
  • 連携サービス: 各種社内基盤サービス

StepFunction

すべて愚直にAPIを叩かず、プランを上げることでの自動化もしております。 例えば、NotionおよびGitHubについては、CFO・CTOに相談し、メリットを共有したうえでエンプラ化を果たしています。

また、上記の環境は完全にdev, prdで完全にわかれています。社内基盤サービス(例: Slack)も含めです。 そのため、ローカルで使うAPIを発行できる、しくっても日々の業務に影響を及ばさないなど、安心・安全に開発できる体験も用意しています。

この内製化によるメリットは単純な作業量削減以外にも次の様なものがあります。

  • 既存の作業の延長上のメリット

    • 再現性が強まる
    • エビデンスの取得がより用意になる
    • プログラム側に問題があっても、マニュアル作業と互換性がある
  • 新しいメリット

    • 作業可能な時間の縛りがなくなった
    • 労働市場の少ない言語(日本語)への依存を減らせる
    • 人間が得意なことに集中できる
    • 今まで最大公約数的に対応せざるをえなかったことが、よりuser Centricにする余地が生まれる

今後の課題と締めに

山積みです。まだ、手作業もありますし、そもそもAWS Step Functionにこなれていません。恐らくStep FunctionはCDK化したほうが良いでしょうし、 入社管理シートはまだスプレッドシートです。実施された各ステップの通知もよりわかりやすくできるはずですし、成果物の検査をOPAにしたいです。

これらの課題を一言でいうと、よりBet Technologyできるということです。 つまり、1) ステークホルダー(HR、経営管理、メンター)と確認し解決可能な方法を見つけ、フロー(型)にそろえ、スケールさせるよう実装するということです。 その実装をCTO室では、モダン開発によって実現しています。

是非、こういったアプローチに興味がある方は、Meetyなどでお声がけいただけると嬉しいです

meety.net

複数プロダクトに散らばったデータ統合に苦労した話

この記事は、6月から始まっている #LXベッテク月間 38日目の記事です。 前回の記事は、かじさん(@kajicrypto)の「CSの生産性を定義する - CS1人あたりARRシミュレーション - 」でした。

こんにちは、LayerX バクラク事業部 OCRチームの秋野(@akino_1027)と申します!先日、SaaS Tech#4にて「マルチプロダクト×非構造化データ×機械学習を支えるデータ信頼性」というテーマで登壇させていただきました。

speakerdeck.com

登壇ではユーザーの課題からAI-OCR周りのデータ管理まで網羅的にお話しさせていただきました。この記事では時間の都合で割愛させていただいた「複数プロダクトの書類データ統合」についてフォーカスを当てて話していきます。(スライドだと下記↓)

背景

バクラクOCRでは請求書などの書類データをインプットとして、支払金額等の項目を読み取って出力しています。読み取り精度を向上させるために書類データ(インプット)と読み取りデータ(アウトプット)をペアで管理する必要がありました。

書類データは、そのままで概ね問題ないのですが、項目ごとの読み取りデータは工夫が必要でした。 一見、ユーザー入力値がそのまま使えるように思えるかもしれません。しかし「書類に記載されている値」を正確に紐付けたいので、独自に用意する必要がありました。そこで、OCRデータ基盤を開発しました。

下記のスライドがOCRデータ基盤を簡略化したものです。下記の図の「正解データ」が書類に記載されている読み取りデータを表しています。

上記の図でもわかるように、各プロダクトから書類データに何らかの形でアクセスする必要がありました。

ここから本題

そんな背景があり、各プロダクトから書類データをImportする機構の設計と実装を任されました。最初は他のタスクと同じ方法で進めていったのですが、かなり苦労しました。理由としては、問題自体も複雑で選択肢も多くある中で単独でガッと進めてしまったことかなと思います。

当然、設計がある程度進んだ段階でチームメンバーに共有するなどの工夫はしていたのですが、今回の場合は問題が複雑なため、頻繁にメンバーに相談するべきでした。そのコミュニケーションが不足していたために、「設計をする」→「実際に手を動かす」→「めちゃめちゃ辛いことに気がつく」というサイクルを繰り返してしまいました。

もちろん、ある程度は仕方ない部分もあると思いますが手戻りがかなり発生してしまったので、もう少し進め方を工夫するべきだったと反省しています。

以降では、試行錯誤した流れを実装候補と共に見ていきたいと思います。実装候補は主に下記の3つでした。

  • 各プロダクトのPrivate APIを利用する
  • AWS Database Migration Serviceを使ってデータを同期させる
  • バッチを使って定期的にOCRデータ基盤のDBにImportする →最終的に採用した案

それぞれ見ていきたいと思います。

案1:各プロダクトのPrivate APIを利用する

すでに実行環境が存在するため、インフラのリソースを新たに作成する必要がなかったり、ロジックを使い回すことができるなどのメリットがありました。しかし下記のような懸念点があり、断念しました。

  • プロダクトで使っているものなので、内部的に使用したくない(間違ってもOCRデータ基盤の都合でユーザー側に影響を与えてはいけない)
  • すでに存在するAPIのロジックを使用すると依存性が高まり、バグが起きやすくなってしまう
  • プロダクトごとにロジックを書く必要があり、実装・メンテナンス工数が高くなる

特にプロダクトごとにロジックを書かなければいけないので、管理コストが高くなってしまうのが辛いので別の方法を考えました。

案2:AWS Database Migration Serviceを使ってデータを同期させる

aws.amazon.com

AWSのDMSを使うことで、他のデータベースの一部を継続的に同期させることができます。実際に触ってみたのですが、複雑な設定等もなかったのでシュッと導入できそうでした。

しかし今回の場合、OCRデータ基盤はWebAPPなのでローカルで開発を進める必要がありました。AWS DMSはクラウド上のDBを同期させるサービスなので、ローカルのDBを同期させることができないという理由から断念しました。

案3:バッチを使って定期的にOCRデータ基盤のDBにImportする

バッチ上で各プロダクトのDBにアクセスして整形してOCRデータ基盤のDBにInsertしていく形です。こうすることでロジックの管理も容易にできますし、バッチのロジックに各プロダクトの複雑性を吸収させることで、OCRデータ基盤のDBをプロダクトの影響を受けることなく、定義することが可能になります。

もちろん既存のコードを使いまわすことができないなどのデメリットはありますがメリットの方が大きいと感じて、この案を採用しました。

試行錯誤と、その学び

このプロジェクトを通じて技術的な学びもよりも「複雑性が高い問題に対するアプローチ方法」を学べたことの方が大きいと感じました。問題が単純な場合は、複数人で分担することによってマネジメントコストが高まってしまうことを避けるために1人(or 少人数)でガッと進めたほうが効率的かもしれません。しかし今回のような複雑性が高く、選択肢も複数存在する問題の場合はチームで頻繁にフィードバックをもらう方が効率的だと感じました。例えば

  • 選択肢などの「叩き」だけを作ってチームで話してみる
  • 設計の全体像が決まったタイミングでチーム内で共通してフィードバックをもらう
  • 定期的に「気になり」を聞いてみる(もちろん、時間が取られない工夫をした上で)

このような工夫を凝らすことで、ある程度実装が進んだ後に手戻りが発生するようなことは避けられると思います。

バクラクシリーズの体験の良さの源泉のひとつに、「なめらかなプロダクト間連携」が挙げられると思います。それらを実現するために、その裏には複雑性が高い問題がまだまだ数多く転がっていると感じています。次の機会には、今回の学びを活かして、ユーザに価値を爆速で届けられるようにしていきたいと思います。

最後に

現在採用を進めており、LayerXに興味がある方はカジュアルにご応募いただけますと幸いです!

open.talentio.com

筆者のMeetyも公開しています。ざっくばらんにお話しましょう!

meety.net

LocalStackを用いてローカル開発のシークレット管理をセキュアにする

この記事は、6月から始まっている #LXベッテク月間 33日目の記事です。 前日の記事はtaikyyさんの「LayerXのQAは顧客に届ける価値を最大化したい」でした。

note.com

ちょりす。CTO室およびFintech事業部で色々やってる @ken5scal です。 本日はアプリ開発をローカルで行うためのSecrets管理のTipsを一部、書きたいと思います。

ぱっとアプリを書いて、さくっとコンテナイメージをビルドし、しゅっとAWS上にデリバリしたいことがありませんか? 当社では、そういった場合にAWS App Runnerを活用することがあります。 PoCなど初期段階のものをインフラレイヤーのことを意識したくないときに重宝しています。 しかし、AWSのロードマップにもある通り、ECSでできるようなVauleサービスであるAWS.Secrets Managerとの連携ができません。 とても残念なことです。

External Configuration/Secret Sources · Issue #6 · aws/apprunner-roadmap · GitHub

つまり、アプリ起動時にAWS Secrets Managerを読み込む処理を書かなければなりません。 AWS App Runnerだけでなく、Lambdaもそうですね。

ローカル上からAWS Secrets Managerを読み込みたい場合は、何かしらの方法でローカルにAWSのアクセスキーやセッショントークンを保持しておく必要があります。 開発用のIAM UserのAccess Keyを用意したり、あるいはAWS SSOなどを通して一時的なアクセストークンを取得することが考えられます。 ただ、前者はローテーションが面倒くさいし、後者は有効期限切れに伴う更新が面倒くさいです。 こういった面倒臭さから逃れるには、そもそもローカル開発で実際のAWS Secrets Managerを叩かない方向に進みたいところです。 CTO室やFintech事業部では、localstackのdocker imageを使うことで、ローカル上の疑似AWS Secrets Mangerを構成しています。

  • docker-compose.yml
version: '3'
services:
    image: localstack/localstack:latest
    platform: linux/x86_64
    environment:
      - SERVICES=sqs,s3,dynamodb,lambda,secretsmanager,logs # 使いたいAWSサービスカンマ区切りで設定する
      - DEFAULT_REGION=ap-northeast-1 # リージョンを設定
      - DATA_DIR=/tmp/localstack/data # データ保存するディレクトリ
      - USER=root
    volumes:
      - ~/dev/localstack:/tmp/localstack # ローカルディレクトリをデータ保存ディレクトリへマウント
    ports:
      - 4566:4566 # サービスへのアクセスポートは4566
      - 4567-4584:4567-4584
  • Makefile
serve-local-app: clean-local-db
    @docker-compose up -d
    @sleep 5
    @source local.env \
    && export AWS_ACCESS_KEY_ID=tekito \
            AWS_SECRET_ACCESS_KEY=tekito \
            AWS_SESSION_TOKEN=tekito \
            AWS_DEFAULT_REGION=ap-northeast-1 \
    && aws --endpoint-url=http://localhost:4566 secretsmanager create-secret \
        --name "app/local/AppSecrets" \
        --secret-string '{"CLIENT_SECRET":"'"$${CLIENT_SECRET}"'","SECRET_C": "'"$${SOME_SECRET}"'","BOT_TOKEN": "'"$${BOT_TOKEN}"'"}'
    @export ENV=$(ENV) && air -c air.toml

実際にlocalstack内のsecrets managerに入れたい各種Secretについては、.gitignore対象にした local.env に設定しております。こう書くとlocal.envが危なく聞こえますが、当社はdevとprd環境を完全に分離しています。 それはAWSアカウントだけでなく、普段使うIdPであったりSlackであったりGoogle Workspaceにも開発的思想を持ち込みdev環境を用意しています。これらのサービスは従量課金であるため、そこまでユーザーが増えない開発環境はお財布にも優しく、それ故に導入が容易です。

あまり、こういった開発の裏情報はでてこないので、是非、このブログの読者の中で別の知見を持つ方がいたら教えてください。Twitter DMでもいいですし、下記の通りMeetyもやっております。

meety.net

読み取り精度100%が不可能と認め、失敗に備えユーザー体験を磨き込む話

どうも!バクラクでOCRの開発を担当する高際 @shun_tak です!

バクラクでは「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。」というプロダクトビジョンを掲げて開発しています。

バクラクビジョン

note.com

そんなバクラクでは文書のデータ化を支援するため、文書の読み取り機能=OCR機能を提供しています。これにより、多様なレイアウト・大量の文書も瞬時にデータ化することができます。

以下、瞬時に読み取られる様子

youtu.be

OCRで読み取ってデータ入力されるだけでも使いやすいプロダクトになっているかなと思いますが、この記事ではさらに一歩踏み込んで、「圧倒的に」使いやすくするための工夫の一端をお見せしたいと思います。

前提:請求書OCRで解きたい問題

請求書OCRは、経理に届く支払請求書を読み取ってデータ化します。データ化したい項目は、「いつまでに、だれに、いくら支払うか」等です。

請求書ファイルであるPDFや画像データをインプットとし、読み取った結果を構造化してアウトプットし、顧客の業務画面にてサジェストしてあげます。

例えば以下のような請求書をアップロードするとします

サンプル請求書画像

この場合、読み取り結果は以下のようになります

  • いつまでに:2020年10月31日
  • だれに:スーパー株式会社
  • いくら支払うか:55,000

工夫その1:読み取り箇所がパッと見でわかる

アップロードしたファイルのうち、読み取りに利用した箇所がハイライト表示されます。読み取り間違えがあっても気付きやすいです。

読み取り箇所がハイライトされる

工夫その2:なるべく手入力を減らすサジェスト機能

読み取るべき金額が間違えていた場合、いちいちタイピングしなくて済むよう第2候補以降の金額もプルダウンから選択できるようになっています。もちろん自由な金額も設定できます。

金額の候補をサジェストする機能

取引先名についても同様に、第2候補以降がプルダウンから選択できます。

取引先名の候補をサジェストする機能

おわりに

本記事ではOCR機能による読み取りが失敗した場合に備えて、ユーザー体験を損ねない、むしろもっと使いやすくするための工夫を紹介しました!

今回紹介した以外にもたくさんの便利機能、使いやすくする工夫がたくさんあります。

まだまだ磨き込みの余地はあり、新機能も爆速で追加されているため、むしろ余地がどんどん増えています!ということで採用は引き続き強化しておりますので、LayerXやバクラクに興味がある方はカジュアルにご応募ください!

open.talentio.com

open.talentio.com

筆者のMeetyでもカジュアル面談を募集しています!ぜひお気軽に!

meety.net

バクラク自体の導入に興味がある方は以下からお問い合わせください!

bakuraku.jp

Be Animalな縦とBet Technologyな横の組織づくり、これからのLayerX開発チームの目指すところ

こんにちは。CTOの松本です。ここしばらくケトジェニックな減量に取り組んでいます。好きな食べ物は鯖水煮缶です。

今回は、先日発表されたsuguruさん入社について、長期で成長し続けることを目指した今後の組織の形の考え方、特に縦と横の意識についてお話させてください。

内容についてはsuguruさん、mosaさんとのPodcastでもお話しておりますのでもしよければこちらもどうぞ。

open.spotify.com

縦と横の意識

開発組織に関わらず、様々な会社で「個々の専門領域・事業領域・プロダクト領域に閉じるチーム」と「横断的なチーム」という2軸の整理を議論することがあるかと思います。開発組織で言えば、例えば一つのプロダクトやシステムを管轄するチームと、インフラ等横軸で全体をサポートするチームがありえます。

また、直近ではこれを更に細分化し、ストリームアラインドチーム、イネーブリングチーム、プラットフォームチーム、コンプリケイテッド・サブシステムチームの4分類に分けるTeam Topologies的な考え方の登場などもあり、この組織設計がホットトピックな印象を持っています。

Team Topologiesについては書籍や監訳者のRyuzeeさんのブログを参照いただけるとより言いたいところが理解いただけるかもしれません。

www.ryuzee.com

特に今回着目するのはイネーブルメントチームとプラットフォームチームという横断的な支援組織のあり方となります。また、プロダクト開発のみに閉じるのではなく、より広く、会社としてどういったアーキテクチャがあるべきかが重要と考えています。

この前提のもと、組織構造についてTeam Topologiesやその他様々な組織のあり方を下敷きにしつつLayerX流にどのように考えていくか、今回のsuguruさんの入社に合わせて議論してきました。

個々の領域に閉じたチームを縦、横断的なチームを横とした時、この2つのタイプそれぞれに求められる責務・能力は大きく異なります。

縦と横

不確実性を最短で突破する縦の開発

縦、つまり個別の事業やプロダクトなどの部門では手数の多さ、スピードを重視した取り組みをこれまで進めてきました。「爆速開発」を謳う通り、とにかくリリースまでのスピードを高め、スピードによって品質を高めるというような考え方で開発を進めています。

縦で求められるパワーは、最速で不確実性を最小化するための、不確実な環境での意思決定力と考えています。事業がスケールするための解を発見するための不確実性最小化エンジンが縦のチームといえます。

こうした縦のメンバーが爆速を維持するには、意思決定の高速化と自律・独立した開発のためのコミュニケーションの最小化が必要です。強い個性・スキルを持った個人がそれぞれ自分の意思の元で進み続けることで爆速開発が成立していると感じます。

事業CPO・CTOであるmosaの強さはここにあり、直近の自分の取り組みの多くはmosa始めとした強い個人が悩み無く目の前の不確実性高い課題に取り組む環境づくりでした。

強い個人が自律的にコラボレーションしていくには、自律的に走っても大枠の方向性がずれないような戦略・優先度の整理、開発以外の領域の仕組み化やマネジメントコストの低減などが求められます。個々の開発力を最大化するための最善のバックアップ、得意に集中する環境を作ることが結果としてスピードと品質を高い次元で成立させる土壌となります。

全体を高める横の開発、xOps

それに対して横、つまり全体を下支えする取り組みも組織がスケールし、一人ひとりのパフォーマンスをより高めるために欠かすことができません。具体的な取り組みでいうと、開発者体験を高め開発のスループットを高めるDevOpsや全社で利用する社内ツールやセキュリティなど含めた効率化で生産性を下支えするCorporate Ops、営業生産性を仕組みで高めるSalesOpsなどがあります。

例として、すでにLayerXや三井物産デジタルアセットマネジメントでは様々な取り組みが実施されています。例えば社員の急増やトライアル入社など柔軟な入退社を支えるために、AWS StepFunctionなどを活用しながらアカウントのセットアップを自動化する取り組みがCorpOps領域で行われています。また、アセットマネジメント業界の物件運用効率化に向けて業務効率化ツールを開発するなど、Opsの改善には皆さんが想像される以上に初期の段階から取り組んできました。

これらxOpsの取り組みは企業内の全ての領域に存在します。日々の業務改善から得られた知見を、誰もが使える形へソフトウェアを通じて提供し続ける仕組みがあることが組織や事業の拡大でも安定したパフォーマンスを提供していくことに取って重要です。

ソフトウェアは関わる人々へ同じ水準のアウトプットを、ミス無く提供しますが、様々な業務プロセスに対してxOpsとして取り組むことは業務上のミスを無くすよいガードレールともなります。よいガードレールは、失敗しうる施策への挑戦を促します。一定のガードを用意することで、何か新しいことに挑戦する場合も安心して取り組むことができるようになります。

例えばわかりやすい事例がCanary ReleaseやFeature Toggleでしょう。サービスリリースにあたって、機能の公開・非公開を簡易制御できることは、もしマイナスな機能を提供した場合にも即座に切り戻しができ、失敗に対する安心・安全を提供します。

縦と横のサイクル

失敗できるということは新しい知見の発見を促す重要な要素です。常に成功確度高いものだけしか取り組めないという組織は、段々と局所解に陥り、成長速度の低下にもつながっていきます。LayerXではBe Animalという行動指針がありますが、積極的に挑戦し新たな道を見つける行動を、同じく行動指針の一つであるBet Technology、つまり技術で支えるのがxOpsであり、横の開発組織です。

xOps的な資産は積み上げ型の資産であり、一度構築されればその組織全体のオペレーショナル・エクセレンスが向上し、また安全性を高め安心して失敗しやすい組織を作り上げます。私が経営上最も重視するAgilityも、この取り組みの先にあるものと思います。

結果として、一人ひとりがよい方法論を学び、活用し、そして様々な挑戦ができ、より人が成長する組織となると私は考えています。人が育つ組織こそ長期間成長する組織、そのために技術を駆使して支えていく、そのための横の活動がLayerXの未来に対する重要な投資になる、そう信じています。今後suguruさんと共に、こうした横軸での生産性向上を取り組み、よりスケールする、より人が育つLayerXを作っていきたい次第です。

最後に

LayerXはまだまだ小さなスタートアップですが、今の時点から「縦で不確実性を最速で突破」し「横で全体のオペレーショナル・エクセレンスを高める」ことの双方に投資をし続けることが、長期間より多くの経済活動をデジタル化することにつながることと考えています。

またその中で多くの人を育てることが重要です。よい経営人材、専門人材が育つことは、一つの事業を作る以上に大きなインパクトを広くもたらしうるものだと考えています。このための横の取り組みへの投資を惜しまずやっていきたい次第です。

DevOpsやCorpOpsなど様々な領域で現在採用を進めており、LayerXの今後に興味がある方ぜひカジュアルにご応募いただけますと幸いです。

open.talentio.com

open.talentio.com

また、今後人を育てる、という意味では新卒採用も強化していきます。まだまだ学生の皆さんには認知の無い会社ですが、より人を育てる、というところで興味がある方ぜひお話しましょう。

open.talentio.com

open.talentio.com

こうした取り組みについて話を聞きたいという方、ぜひmeetyでもお待ちしております。

meety.net

meety.net

セキュリティ・キャンプのオフィシャルメンバーになった話

この記事は、6月から始まっている #LXベッテク月間 27日目の記事です。 前日の記事はmakiさんの「ファネルを科学する。コホートを駆使して事業解像度を高める「シン・ザ・モデル」」でした。

note.com

はじめに

どうも、デジタル化したすべての経済活動をレジリエントにしたい、LayerXの @ken5scal です。 LayerXのCTO室に務める傍ら、Fintech事業部で三井物産デジタル・アセットマネジメントでファンドの運用業務デジタル化するチームに所属しています。

今回は前者におけるセキュリティ・コミュニティへの貢献についてお話します。

後者の取り組みについては、別のメンバーが書いているブログをご参照ください。

Fintech事業部の全力のBet Technologyの様子をお見せします - LayerX エンジニアブログ

本題

当社は積極的にコミュニティ活動のスポンサリングをしております。 直近でいいますと、Go Conference 2022 Spring や技育プロジェクトがあります。

技育プロジェクトのイベントである技術博 2022への参加ブログエントリにもあるとおり、中長期的なエンジニアの育成は当社の行動指針「徳」や「Bet Technology」に沿った活動になります。この活動の場は当社の事業活動に直接関連するような(例: Goコミュニティ)技術に限りません。

お客様と関わるユーザーからデータを預かる以上、それは事業価値であると同時に事業リスクです。このリスクを適切に管理することは当社の事業上の義務であり、したがってセキュリティ・リスクに関わる活動も、中長期的エンジニアの育成の対象になるわけです。

セキュリティ・キャンプは情報セキュリティについて本格的に学ぶ意欲のある学生・生徒を選抜し、数日間の講義を提供する、非常に意義深い実績のあるIPA様の事業です。そういった点に共感し、@ken5scal 自身も直近数年のセキュリティ・キャンプでは個人スポンサリングをしています。 (ちなみに私も2019の全国大会でゼロトラストに関する講義をさせていただきました)

一方、自分が所属しがちなWebプロダクト開発に比重のよる小規模なスタートアップだと、事業活動に直接的な接点を見出しにくい領域のカリキュラムでありました。Webセキュリティにしても、そう、いままでは。

今年のWebセキュリティクラスをご覧ください。

「モダンな開発環境のセキュリティおよびCI/CDパイプラインのセキュア化」、「ソフトウェアサプライチェーンセキュリティのこれから」、「Policy as Code入門」といったモダンなプロダクト開発に関わる要素のセキュリティ講義が満載です! 講師陣はメルカリさん、Ubieさん、GMOペパボさんなどのまさにプロダクト開発組織の方々です。

見よ

当社はこれら講師陣の皆様がいらっしゃる企業に負けず劣らず、日々プロダクトをリリースしており、同時にそれを支えるソフトウェアエコシステムに頼らせていただいています。 そういった意味で、当社の価値を支えると同時にエコシステムに還元する必要があります。それが、今回、当社が本活動へ参加することを決定した理由です。

2022年8月10日に行われる企業紹介イベントでは、以下内容をお話させて頂く予定です。

  • PrivacyTech事業部の中村よりプライバシー保護技術について
  • 私からはCTO室の取り組みのご紹介

もし、本ブログをお読みになられているセキュリティ・キャンプ参加者の方がいらっしゃれば、是非、現地で声をかけてくれると嬉しいです。

Meetyやってるよ

当社のセキュリティ関連の取組については、まだ他にも沢山あります。 深い話など興味があれば、ぜひMeetyなどでご連絡ください。

meety.net

もちろん積極的に採用も行っています。コチラもぜひ。

open.talentio.com