こんにちは！LayerXの @mosa_siru (榎本) と申します。
LayerXでは、LayerX インボイスという経理の方向けのDXプロダクトを開発しています。いわゆるSaaSです。こちらの事業責任者をやっております。
今回のエントリでは
- LayerX インボイスの簡単な紹介
- 数ヶ月で爆速リリースするまでのプロセス
- インセプションデッキとチーム話
- スクラムのスタイルと開発チームのMTG
について書きます。最後まで読んでいただけたら嬉しいです！
LayerX インボイスって？
会社には、「1. 請求書を受け取り」「2. その内容をみて会計上の仕訳を行い」「3. 適切に支払う」という請求書処理プロセスがあります。これらの業務フローは各社バラバラですが、手入力でExcel、会計システム、オンラインバンキング上で何度も同じ内容を入力していたり（その分ミスも増え、チェックも多く必要です！）、各種マスタが点在していて転記作業が必要だったりと、その煩雑さから月初の残業とストレスの元になっていました。
LayerX インボイスでは、請求書を効率的に回収し、OCRや学習データを用いて請求情報と仕訳をデータ化し、加工することなく会計システムとの連携・支払データを出力する一連のプロセスを一気通貫で行うことができます。なんだか便利そうですね！
実際に多くの会社さんに導入され、「作業時間が減った」「ストレスが格段に減った」「月次の締めが早くなった」などの声をいただいております。
LayerX インボイスは2020年の秋頃にプロダクトの方向性が決まり、翌年1月にリリースするという極めて速いスケジュール感で開発されました。現在も毎週のように新機能や、新しい会計ソフトへの対応がリリースされております。どのように開発しているのか、その風景を紹介できたらと思います。
インセプションデッキ
スクラム開発の最初にチームの共通認識を揃えるインセプションデッキにて、チームで「やること」「やらないこと」を決めました。その中で「やること」のトップは 「スピード！スピード！スピード！」
動くものをいち早く作りデリバリーし、そのフィードバックを最速で反映する、そのサイクルを常に意識して開発しております。初期は1-2日で作ったプロトタイプ（または開発しないで紙芝居）をお客様に当てて反応をみる、なども繰り返していました。
ニュアンスを伝えるのが難しいですが、逆に「やらないこと」として「ちゃんとしすぎない」というのも取り入れております。エンジニアとして「ちゃんとしすぎる」のは際限がないため、事業の成功に寄与するように良いラインを模索し続けようという意図です。（ちゃんとしてます！）
エンジニアの文化
LayerXでは「Trustful Team」という行動指針があり、一言でいうと「背中を預け合う」形で開発しております。DXチームではフロント、サーバー、インフラとフルスタックに扱えるメンバーが、機能単位で一気通貫で開発しており、それが速さの源となっています。チームでわいわいしながらも、それぞれがプロ意識をもって開発するスタイルです。
ドメインに対するキャッチアップも貪欲で、SaaS経験者も経理業務経験者も乏しい中で、各位が勉強して突き進んでおります。このキャッチアップ力は、全社に共通する、LayerXの行動指針 「Be Animal」 たる所以かと思っております！
スクラムのスタイルとMTG
チームの開発スタイルを言葉でお伝えするのは難しいので、会議体を例にとって説明しようと思います。
MTGは開発時間確保と頭の切り替えのために、月曜日と金曜日に集中させるなど工夫をしています。
DDD - デモ駆動開発 (Demo Driven Development)
LayerXでは週次の全社定例で、各事業部が簡単な「デモ」をする文化があります。動くモノが正義だよね、という考えのもと、毎週プロダクトのアップデートが共有されます。動くモノを毎週見せるサイクルは程良い緊張感を生み、そして皆を鼓舞します。
チーム内でも、週の終わりにプロダクトの詳細なデモを行い、セールス含めた共通認識を作ります。 こちらのデモは「景気(進捗)が良い人」から行います。毎回の景気の良さにビビります。
タスク管理とSprint計画
ユーザーストーリーやタスクはAirtable(時々miro)で一元的に管理しています。（一時期ぐちゃぐちゃでしたが、なんとか持ち直しました。）全ての新機能に優先度が振られ、誰がみても何をすべきかわかるようになっています。数百以上のタスクが管理されています。やりたいことが無限にあります！！
Sprintは2週間単位で、その計画では優先度が高いものからピックしていきますが、あらゆる優先度を横並びに比較するのは難しいため、最近では「新機能」「機能強化」「bug」「品質」「改善(細)」「システム系」にタスクを分類しています。新機能はロードマップに従い、機能強化は優先度順に行います。
いかにお客様からの要望を一元管理し、最速で開発サイクルに回せるかが運営の妙になっています！
エンジニア朝会 ・全体夕会
エンジニアはdailyでstand up MTGをしており、簡単に昨日やったこと・今日やることを報告します。リリースの計画やQAの共有、簡単な相談も行います。
全体では夕方に集まり、セールス含めたチーム一体の全体共有や相談を行います。難しい仕様についてはここで共有します。 良いことがあったときは、ドラを鳴らします！！
気になり会
不定期で、エンジニアが「なんか気になるよね」「なんかもやもやする」ことを話す場を設けています。障害について、品質、コードの書き方、様々なトピックが話され、ネクストアクションに繋げていきます。
振り返り
月1で全体でしっかり振り返りを行います。KPT(Keep, Problem, Try)を行い、次のアクションにつなげます。
前月のProblemがKeepになっていることが多く、チームの強さを感じます！
リモートでの工夫
緊急事態宣言下はリモートがメインでした。そのときの工夫点としては、いつでも同期的コミュニケーションができるよう、Zoomで全員「つなぎっぱなし」をしておりました。
slackで「ちょっと今通話良い？」のコミュニケーションは心理的ハードルが高いので、zoomを常に立ち上げて、簡単に話しかけられるスタイルです。気軽な同期的コミュニケーションは、爆速開発には欠かせません。
全員が同じ部屋にいると大変なので、ブレイクアウトルームを使い、話し込むときは別の部屋にうつったり、作業集中したい人もうつるなどしていました。
リモートしているチームにはとてもおすすめです。ネックは電源消費がすごいこと。。
※4月現在は、出社を基本としています。企業文化を醸成し、組織力やチームワークを向上していくことを考えたときに、そういった結論になりました。一方オンラインの方が生産性が高いものは、積極的にオンラインで行っています。
まとめ
以上がDXチームのリアルな開発風景となります！ひとつひとつがかなり模索された上で今の形になっており、爆速開発を支えています。
今回は開発スタイルの話になりましたが、このブログではどしどし開発にあたっての知見を公開していきます！お楽しみに〜！！！
