LayerX エンジニアブログ

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

「スケールする組織か、個がワークする組織か」正反対の意見を持つエンジニア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

Go Conference Online 2022 Spring に Silver プランにて協賛します

LayerX は Go Conference Online 2022 Spring を Sliver プランにて応援させていただきます!

開催概要

Go Conference は半年に 1 回行われるプログラミング言語 Go に関するカンファレンスです。

  • 日程:2022/04/23(土) 10:00 〜 20:00
  • 会場:オンライン
  • 参加費:無料
  • イベント公式サイト:https://gocon.jp/2022spring/ja/
  • 主催:Gophers Japan

参加申込

以下のイベント申込ページよりお申込みください。

gocon.connpass.com

登壇情報

LayerX からはバクラク請求書でリードエンジニアをしているSaaS事業部の @yyoshiki41(中川佳希)が登壇します。

gocon.jp

また中川の Meety は以下です。ご興味ある方は是非お申し込みください! meety.net

スポンサードの背景

LayerX では、社内のプロジェクトの多くで Go を利用しています。

Go のテックコミュニティの裾野を拡げていくことの一助を担えればと思い、今回は Silver プランでの協賛という形で応援させていただくことにしました。

今回のようなスポンサードだけではなく、私たち自身が 会計 freee API のクライアントライブラリ freee-go をはじめとした OSS の公開もおこなっています。

他にも既存の OSS に対して適切な Issue、Pull Request の作成や SaaS.tech などテックコミュニティの運営などできる範囲でのコントリビューションを実施しています。

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

LayerX エンジニアブログには Go に関する記事が下記にまとまっております!こちらも是非ご覧ください! tech.layerx.co.jp

SaaS.tech #1を開催しました

こんにちは、CTOの松本です。最近はモノレポ構成にハマってます、アーキテクチャ設計が柔らかくなる感覚が好きです。

さて、今回は2022年3月15日にSaaS.techの第一回を開催させていただいたのでそのご報告をさせていただこうかと思います。

saas-tech.connpass.com

ちなみにアーカイブ動画はこちらに。

www.youtube.com

SaaS.techとは?

そもそもSaaS.techとはという話なのですが、本イベントはLayerXのイベントというよりも、SaaSに関わるすべてのエンジニアに向けたコミュニティイベントを目指して企画した勉強会となります。

ですので、レギュレーションとして会社紹介や採用宣伝は抑えるように設定しつつ、純粋に技術の話でワイワイできる場づくりを目指しました。個人的に、一企業で会社紹介たっぷりの構成でオンライン勉強会を開くフォーマットについてちょっと聞き手としても話し手としても疲れてしまった感覚があり、技術でワイワイできる場をSaaSカテゴリでもやりたくなった次第でした。

SaaSモデルのtoBサービスは、広く様々な会社がソフトウェアを活用しようとする上で、適切なコストでメリットを受け入れやすくするものであり、SaaSが広く普及することですべての経済活動をデジタル化することにつながると考えています。

そのうえで、SaaSモデルのプロダクト開発を進める上では、関わったことのある人ならわかる「ならでは」の課題が多々存在しています。例えばマルチテナント設計や認証認可、API連携、要件の複雑な機能へのチーム開発、品質保証、セキュリティなどなど。

この課題とそれに対する取り組みを共有し合うことで国内のSaaS全体がより成長し、メリットを享受できるユーザーが増えていくことにつながればと思いSaaSにカテゴリを絞った勉強会の開催に至りました。

知見の共有によってソフトウェア技術での躓きが減り、より成長しやすいSaaSの市場環境が生まれれば幸いです。長期で市場全体が国内、ひいては国外まで含め価値を届けられるよう、LayerXの行動指針である「徳」に紐付けて技術にフォーカスした勉強会、今後継続的に開催していきたいと考えています。

第一回はアーキテクチャ編

さて、その第一回が先日開催されたわけですが、第一回にしてはいきなり応募900名超えという巨大イベントになりました。企画した自分含め一同驚いています。当日も350名を超える方にリアルタイムに視聴していただきました。

第一回のトピックはアーキテクチャ、特にマイクロサービスか、モノリスか、という意思決定について取り扱っています。なかなか答えのない課題であり、各社の葛藤を知ることができるよい回になったように思います。

おそらく、各コンテンツについては登壇された皆様がブログを書くのではと思いますので、こちらではタイトルだけさせていただきます。 当日の資料はこちらに。

saas-tech.connpass.com

・「アプリケーションが大きくてツラい…ってこと!?」 すがわら まさのり / 株式会社 SmartHR

・「絡み合うSaaSプロダクトのマイクロサービスアーキテクチャ」 mosa / 株式会社 LayerX

・「デモつき!動かしてわかる はじめてのPact」 Satoshi Toyama / フリーランスエンジニア

・「Scalebaseがモノリスでもなくマイクロサービスでもなくモジュラモノリスを採用した理由!」 竹尾正馬 / アルプ株式会社

・「カオナビにおけるマイクロサービスの取組と今後の展開」 @hanhan1978 / 株式会社カオナビ

どのコンテンツも、これが答えだ!というものではなく銀の弾丸が無い中で何に悩み何を追い求めたのか、その悩みの過程を知ることができる良い発表の数々で、私自身としても学びとなりました。

第二回以降の運営をお手伝いいただける企業・個人の方を募集しています

今後も安定して継続開催していく上で、どのようなコンテンツで開催するか議論したり、実際にスピーカーを出していただいたり、また配信準備や懇親会運営に向けて、運営をお手伝いいただける企業・個人の方々を募集しています。

ご興味ある方、私(@y_matsuwitter)か、@serima までDMをいただければ幸いです。

最後に

SaaS事業は、広く、また適切なコストでデジタル化を届ける意味でどんどん盛り上がっていくべきものだと考えています。SaaS.techを通じて、少しでも多くのSaaS事業が拡大していくサポートとなれれば幸いです。

MySQL 外部キー制約とインデックスに必要な知識

バクラク請求書 でリードエンジニアをしているSaaS事業部の @yyoshiki41(中川佳希)です! バクラクシリーズでは、経理向けSaaSに始まりコーポレートDXをサポートする複数プロダクトを提供しています。

サービスローンチから1年経過したこともあり、2021年12月から2022年1月は短い間に事業部として怒涛のリリースの日々でした。

サービス全体で変化はありましたが今後も変わらずプロダクト開発を通して、経理・コーポレートチームの仕事がバクラクになるようサポートしていきます!

今回の記事は、MySQL の外部キー制約とインデックスについてです。

Foreign Keys

多くの人が馴染みあると思いますが改めて整理すると、2つの役割を担っていると言えます。

  1. 複数のテーブル間でインデックスとしてデータの参照を効率的に行う(外部キー)
  2. 複数のテーブル間でデータの一貫性を保つ(外部キー制約)

上記をサンプルのテーブルを使って具体的にみていきます。

外部キーの作成とインデックス

親テーブルとその外部キーをもつ子テーブルを以下のSQLで作成してみます。

CREATE TABLE `parents` (
  `id` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;

作成されたテーブル定義の結果は以下です。 比較してみると上の children テーブルのCREATE文は簡略化して書いたもので、MySQLが自動でインデックスキー(KEY parent_id)を作成してくれている事がわかります。

mysql> SHOW CREATE TABLE children\G;
*************************** 1. row ***************************
       Table: children
Create Table: CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  KEY `parent_id` (`parent_id`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

上では簡略化した書き方をしましたが、外部キー作成の構文は以下で表現されます。

[CONSTRAINT [symbol]] FOREIGN KEY
    [index_name] (index_col_name, ...)
    REFERENCES tbl_name (index_col_name,...)
    [ON DELETE reference_option]
    [ON UPDATE reference_option]

reference_option:
    RESTRICT | CASCADE | SET NULL | NO ACTION

マルチカラムインデックスの場合は?

では、マルチカラムインデックスを持つテーブルでの挙動もみてみます。

CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  `revision` int NOT NULL,  
  KEY (`parent_id`, `revision`),
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;

先に Composite Key として使用するインデックスカラムとして、外部キーとなるカラムを使用しておけば、特に自動でのインデックス作成は行われません

mysql> SHOW CREATE TABLE children\G;
*************************** 1. row ***************************
       Table: children
Create Table: CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  KEY `parent_id` (`parent_id`,`revision`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

逆に、先に外部キー以外のカラムを指定していると、外部キーの単独のインデックスが自動で作成されます。

CREATE TABLE `children` (
  `id` int NOT NULL,
  `parent_id` int NOT NULL,
  `revision` int NOT NULL,  
  KEY (`revision`, `parent_id`),
  FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB;
CREATE TABLE `children` (
  `id` int(11) NOT NULL,
  `parent_id` int(11) NOT NULL,
  `revision` int(11) NOT NULL,
  KEY `revision` (`revision`,`parent_id`),
  KEY `parent_id` (`parent_id`),
  CONSTRAINT `children_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parents` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

今回の外部キーの話とは逸れますが、マルチカラムインデックスは内部でカラム値を定義順に連結して作成した値を持っていることが分かります。(効率的なキーの設計をしておけば、追加でのインデックス作成が不要になる。)

外部キー制約

MySQLでは ON DELETE, ON UPDATE の後ろにオプション(RESTRICT | CASCADE | SET NULL | NO ACTION)をつけて表現でき、参照元の親テーブルが削除された場合にどのようにデータの一貫性を保つかを指定できます。 デフォルトでは制約違反のデータ操作は拒否されます。

Cannot add or update a child row: a foreign key constraint fails

例えば ON DELETE CASCADE を指定すれば、親テーブルのレコードが削除された場合に、子テーブルで参照元としているレコードも自動で削除されます。(各オプションの挙動については、他の記事に譲ります。)

外部キー制約とインデックスまとめ

最初に書きましたが、外部キーの重要な役割にデータの一貫性を保つことがあります。
親テーブルのレコードが削除された場合などに、子テーブルのデータをチェックして制約を満たすかを確認する必要があります。その参照を高速に処理するためにインデックスが用いられます。ユーザーがインデックス作成を明示的に定義しない場合には、MySQL側で自動で作成が行われます。
ユーザーにとっても、複数テーブルにまたがるデータを参照する際に効率的なクエリのために、このインデックスを効率的に使うことを意識しておく必要はあります。
今回は普段あまり意識されない内部的な動きを整理してみる記事となりました。

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

open.talentio.com

open.talentio.com

open.talentio.com

「バクラク」ロゴの制作過程で生まれた言葉

※こちらは「LayerX Advent Calendar」58日目の記事です。

こんにちは、SaaS事業部でデザインを担当しています森です。
先日お知らせした通り、弊社SaaSプロダクトシリーズの名前を「バクラク」にリニューアルいたしました。

bakuraku.jp

リブランディングの経緯は、SaaS事業部のビジネスサイドの責任者@makiのエントリーを読んでいただくとして、今日はそれに伴うロゴ制作についてのお話しです。

note.com

バクラク

コーポレートミッションの策定をお手伝いいただいた、PARK 田村さんに提案いただいたリニューアル案の中から「バクラク(この時点では表記方法は未定)」に決まりました。

チームでの軽いネタだしから、シリーズ表記をカタカナ、プロダクト表記を漢字(請求書、申請、電子帳簿保存)でいくことになります。

漢字(爆楽)だと、字面の複雑さ重そうな雰囲気、他社さんとの被りが気になり、アルファベット(Bakuraku)だと語感の持つ面白みを感じにくい。また、プロダクト名はわかりやすさを重視して、漢字にすることは概ね決まっていたので、組み合わせ的にもカタカナを選びました。

ロゴの制作の場合、何かしらとっかかりになる物を探すのですが、「バクラク」に感じていた特徴は

  • 濁点はじまり
  • 韻を踏むような「ク」が生むリズム感

の二つ。最初にイメージしたのは、楽譜の上で等間隔に並ぶ音符や、ステップシーケンサーのマス目のように等間隔に並ぶ直線でした。

f:id:hiroakimori:20211221091146p:plain

この方向で試作していきます。

f:id:hiroakimori:20211221085545p:plain

少し単調ですね。濁点の扱いに悩みつつ、可読性や文字の特徴を強めていきます。

f:id:hiroakimori:20211221085554p:plain

おおよその着地が見えてきました。社内のフィードバックをもらいながら、ボリュームや可読性を調整していきます。

f:id:hiroakimori:20211221085602p:plain

フィードバックから生まれた言葉

直線を軸に作っていたので、いくつか可読性についてのフィードバックをもらい、調整を繰り返していました。その中で、「ハタラクに見える」というフィードバックをもらいます。

「バクラク」というカナ表記は、濁点と一画の違いだけで、私たちが向かい合う「ハタラク(働く)」という事と似通っていたのです。
その瞬間、可読性の問題が一転します。

f:id:hiroakimori:20211221085612p:plain

ハタラクをバクラクに

「圧倒的に使いやすいプロダクトを届け、ワクワクする働き方を。」  

企業活動を支えるコーポレート業務は、ミスができない難しい業務。 そんな業務に「楽しい!」と言ってもらえるくらいの体験を届ける。 UXへの圧倒的こだわりと、深い顧客理解で業務プロセスを滑らかにし、toCサービスの体験をtoBにも これらの体験を組織的なオペレーションであらゆる企業に届ける。 LayerXの提供する体験が、toBの世界で当たり前と言われる水準になるように。

note.com

弊社SaaS事業部には、事業部ミッションがあります。「バクラク」という名前を選んだのは「難しい業務を楽にしたい」という姿勢の現れです。 そして、ロゴへのフィードバックをきっかけに、それを濃縮したような言葉を見つけることができました。

f:id:hiroakimori:20211221085525p:plain

この言葉に行きついたのは運が良かったと思います。
そもそも、この視点が抜け落ちていた中、フィードバックによって気づくことができました。 そのフィードバックも、可読性の問題とだけ捉えていたら、濁点の位置を変更するなどして「ハタラク」と結びつけることはできなかったと思います。

そして、その過程は弊社っぽいと思っています。

弊社のプロダクト開発の特徴として、まず動く物を作り、フィードバックを通してより良くしていくというものがあります。フィードバックも社内だけではなく、お客様や有識者の方々にご協力いただいています。

セールス、CS、開発、コーポレートを問わず、より近いところで意見を聞き、それをプロダクトに生かしていく。そんな社風から生まれた言葉だったように思います。

「ハタラクをバクラクに」

この言葉を体現する道のりは、まだまだこれからです。
もっと沢山の人に、より良い価値を提供していくには、まだまだ仲間が足りません!
開発、ビジネス全方位で絶賛募集中ですので、下記よりご連絡ください!!

LayerX 採用情報

LayerX Company Deck

open.talentio.com