👨‍🎨

デザイナーからみた爆速開発

こんにちは、LayerXでデザインを担当しています森です。今回は、爆速と呼ばれるDX事業部での開発の様子をお話ししたいと思います。

デザインをしない

以前に @yyoshiki41 がお話ししたように、開発チームは横断的で、エンジニアはフロントエンド、バックエンドを問わず、機能単位で担当し開発しています。その中で私も、フロントエンド、主に表示まわりの開発に関わっています。
LayerX インボイスの技術スタック〜分野横断で開発するためのSchema Driven Development〜 - LayerX エンジニアブログ
DX事業部の @yyoshiki41 です。 今回は、 今年1月にリリースしたLayerX インボイス のアプリケーション開発についてです。 インフラ構成については、昨日の LayerX インボイスのインフラアーキテクチャ で紹介されています。 LayerX インボイス は、主に経理業務を行う方を対象ユーザーにした SaaS プロダクトです。 サービス内で以下の業務を行うことがメインになっています。 請求書の受領 請求書から仕訳を行う オンラインバンキングに取り込むためのデータを出力する 会計ソフトに仕訳データを連携する また上記の他にも マスタデータ(例えば、仕訳データの入力に使う取引先や部門、税区分など)の管理や会計ソフトへの連携 源泉税の支払管理 請求書の社内での確認 などを行う機能が実装されています。 エンジニアの普段の業務としては、馴染みのないものがほとんどですね、、 前置きが長くなりましたが、経理業務や会計からは少し離れ、本題のアプリケーション開発の話に移っていきます。 チームの特徴としてはフロントエンド開発だけを行うメンバーはおらず、 バックエンドエンジニアがフロントエンド開発を行う UIデザイナーもフロントエンド開発を行う という体制で開発をしています。 担当の領域を明確化するのではなく、機能単位で実装者をアサインして進めており、 プロダクトが立ち上げ期においては(必要な機能数が多いこともあり)非常にワークしていると思います。 プロジェクト初期に、サービス立ち上げを行った経験値を持つエンジニアが揃っていたこともうまくハマった点でもあります。 Frontend Backend に限らず、Backend Ops などをきれいに線引くことは難しく、 両者を行き来できるとコミュニケーションコストや機能提供スピードの面でもメリットを享受出来ると考えています。 現在は、PCブラウザでのみサービス提供をしており、 Nuxt + TypeScript で、SPA という見慣れた構成かと思います。 Cloudfront + S3 での静的配信を行う形を取っています。 バックエンドは、Go がメインで使われています。 使っているライブラリなどは下記です。 選択の理由としては、以下のような理由が挙げられます。 まず薄く入れれるもの PR / Fork してメンテして運用出来るもの 静的型付けでコーディング出来るもの Goプログラムと外部とのデータ I/O の変換(marshalling/unmarshalling)部分を自動化出来る(e.g.
事業責任者の @mosa_siru が、「デザインプロセスを挟まない開発」と呼んでいますが、仕様が相談された後、詳細なワイヤーや画面デザインを待つことなく開発が進んでいきます。機能が実装された後、デザイナーがレイアウトの調整や、少し手間のかかる表示まわりの実装を行っていきます。
デザインをしない、は言い過ぎですが、SketchやFigmaを使う代わりに、IDEを使ってデザインと実装を同時に進めているような感じです。このスタイルが爆速を生む理由の一つだと思っています。
実際、チームに参加してから起こした画面イメージは2〜3枚程度で、共有目的というよりは、自分用に方向性の確認程度に作った程度です。

Nuxt+Bootstrap

フロントエンドはNuxt+Bootstrapで作られています。
BootstrapなどのUIフレームワークを使った開発は、スピードが出しやすく、手軽に機能検証もしやすいので、プロダクトの立ち上げには相性のいいものだと思います。
エンジニアの手によってBootstrapで実装された後、レイアウトやスタイルの調整、カスタマイズが必要なコンポーネントなどに手を入れて行っていきます。
最初は手を入れるところが多かったですが、型ができてきて使いまわせる様になると、個別に調整することも少なくなり、スタイルのリファクタや、コンポーネントへの切り出しなどを徐々にやったりしています。
ここ数年はネイティブ開発のみで、重めのSPA開発は初めてでしたが、Nuxtは馴染みやすく使い勝手のよいものでした。
コンポーネント単位に、テンプレート、スクリプト、スタイルが一つにまとまっているのは見通しがよく、値やステータスなど、表示に必要なものは大体そこにあるので開発がしやすいです。
v-bindなども表示を制御しやすく、enumをclass名にしておいて、ステータスに応じてスタイルを変えるなど、ちょっと楽しいです。eventのハンドリングも楽ですね。
また、コンポーネントの切り出しもしやすく、例えば、CSSで色やサイズを変更したいグラフィックパーツなどは、SVGをコンポーネント化しておくと便利でした。

快適な開発環境

開発はエンジニアと同様に、サーバーサイドも含め、開発環境をlocalに用意して行っています。
一見、非エンジニアには敷居が高そうですが、ストレスを感じることはなく、むしろこの環境でなければ彼らについていくスピードは出せていないと思います。
実際にlocalで動かすと、コンポーネントが複数あるため、ターミナルが常時9~10枚開いている状態で管理が大変そうですが、リポジトリを最新にして、用意されたコマンドを叩くことで問題なく動かすことができます。
また、機能毎に開発、マージされていくので、バックエンド/フロントエンド、権限基盤/プロダクトなどの進捗差分による混乱などがなく、コード以外で動かない理由を探す時間は少ないです。
そして、localで動くものは、dev/stg/prd環境でも問題なく動きます。認証まわりも整備されていて、リモート開発でもVPNを通すことなく、SSOによる認証でdev/stg環境に快適につなぐことができました。
非エンジニアが開発に関わる場合、実際に動く物とは別の環境(モックなど)で行うことが多く、不自由なことが多かったですが、実際に動く、管理コストの低い開発環境はとてもありがたいです。

プルリクを止めない

リポジトリを見ると、マージ待ちになっているようなプルリクはなく、どんどんマージされていきます。
localでじっくりブランチを温めていると、大量の差分が降ってきて、思わぬコンフリクトに泣くことになるので笑、私も頻繁にプッシュしていっています。
今でこそ躊躇しませんが、チームに参加当初は、プルリクを出すのに慎重になっていたこともありました。しかし、プルリクを止めるなという話しを聞いてからはどんどんマージしていっています。
「プルリクを止めてはいけない」by @yyoshiki41
一見、勢いでガンガン行けととられそうですが、@mosa_siru の言う「背中を預け合う」スタイル、お互いに信頼し、信頼には責任をもって応える文化をよく表した言葉だと思います。

全員で走る

爆速なんて言うと、優秀な人のマンパワーに頼っているだけだと思われる方もいるかもしれません。
そういった側面もありますが、特定の人だけでなく、PMもエンジニアもQAもCSもSalesもBackofficeも、顧客とプロダクトに向かい合い、最良の結果を生み出せるバランスを見極めながら、走り続けている結果なのだと思います。
そして、みんな楽しそうです。
私は、何をするかと同じくらい、誰とするかも大切だと思っています。LayerXに入った理由のほとんどは、そこにあります。
そんな、楽しそうに爆速で走る人たちに興味がわきませんか?是非、下記のリンクからご連絡ください!