LayerXのプロダクト開発:チーム・開発プロセス・技術スタック
こんにちは。LayerXのリードエンジニアの@MasashiSalvadorです。今回のブログではLayerXの事業の概要を説明した後に、実際に事業を進めていく中でどのようにプロダクト開発をしていくかを書いていきます。2020年初頭版、LayerXの開発のざっくりとした全体感という感じになるかと思います。開発の進め方、技術スタックとその選定方法とか、社内のチーム開発の様子などを紹介できればと思います。
LayerXの事業とアジャイルな開発プロセス
LayerXはブロックチェーン技術を基軸にソフトウェアを用いることで企業のDX(Digital Transformation) を推進し、共同で新しい事業を作り出そうとしています。今現在、多くのクライアント企業様とお仕事させていただいています。
各プロジェクトは
- コンサルティング
- 実証検証の前提や要件
- モノを作ることによる実証検証の実施
- 商用プロダクト開発
このような流れで進んで行くことが多いです。
実際にどのような企業様とお仕事させていただいているかというと、すでに対外的に公表させていただいているプロジェクト
LayerX、MUFGとブロックチェーンを活用した次世代金融取引サービス提供に向け協業
のように、銀行様を含めスタートアップとは比較にならないくらい大きな企業様とお付き合いをしています。LayerXのビジネスについては、弊社CEO福島のnote LayerXのビジネスを読んでみてください。
大企業とお付き合いをしているので
- ウォーターフォールでガチガチに仕様決めてから開発するんじゃないの?
- (悪い意味での)受託開発的で、仕様とか機能の決めにエンジニアが入りづらい、もしくは入れないんじゃないの?
- 実証検証で作るプロダクトって何なの?
といった疑問や、もっと細かいと話だと
- ドキュメント書く仕事が不必要に多かったりするんじゃないの?
- クラウドって自由に使えるの?
この辺りの疑問が当然湧くと思いますし、ウェブのC向けサービス開発出身の僕も正直言って初めは手探りでした。実証検証を経てプロダクトをアウトプットとして出していく中で、「ブロックチェーンの社会への応用」という新規性の高い領域で、プロジェクトをいち早く成功に導くためにアジャイルな開発プロセスを採用しています。
ガチガチのスクラムを回しているわけではないですが、スクラムのプラクティスも取り入れられる範囲で取り入れています。
LayerXのプロダクト開発:チーム体制・開発プロセス
明文化されたルールがあるわけではありませんが、対面でのコミュニケーション・意志決定と役割分担がスムースに行えるサイズのチームで開発をしています。大体のチームは
立ち上げ期
- ビジネスメンバー1名
- エンジニア1,2名
全体設計やインフラ・バックエンド・フロントエンドの基盤整備をやりつつ、実装すべき機能の優先度を決めたり、先回りで調査などをします。MVPの開発をこのサイズで行うこともあります。
チーム拡大期(その1)
- ビジネスメンバー2,3名
- エンジニア1,2名 + 3,4名
実際に良いUXを実現するUIを作ったり、そのバックエンドのAPIを開発したり、立上げ期に作り上げた土台の上にプロダクトの機能を作っていきます。他には、ブロックチェーン固有の設計上の課題を解決するための調査を行うなどします。
このようなサイズ感の事が多いです。その2、その3のフェーズももちろん存在していて、アクセルを踏んでプロダクトをグロースしていくフェーズには更に多くのエンジニアやビジネスメンバーが参加します。
もちろん、ここに書いているのは一例で、人数に関してはプロジェクトの難易度や作るもののサイズに依存しますので、全てのプロジェクトがこのメンバー構成なわけではありません。
インフラに関しては、何人かのメンバーがプロジェクト横断的に見る動きをしています。プロジェクトごとにリリースタイミングが異なるので、プロジェクトに一定時間張り付くような動きになることも多いです。
クラウドに関してはAzure, AWSを使っています。以前はGCPを用いていたプロジェクトも存在しました。クラウドは自由に使うことができますが、金融システムを商用環境にリリースするにあたり、可用性やセキュリティ面で考慮するべきことが多く存在するのでその方法を模索したり、対策をしているメンバーもいます。
仕様や機能の洗い出しに関しては、エンジニア・ビジネスメンバー・クライアント企業様と一緒に、下記プロセスを経て作っていきます
- 検証すべき項目(仮説)を揉む
- 実際にどのような機能の実装が必要かを検討する(タスク洗い出し)
- SPRINTごとに何をリリースするかを大まかに決めておく
- SPRINT開始時に工数を見積もりタスクを多くて4時間で終わるくらいの小タスクに分解し、アサインは朝会などで都度確認する
タスク管理には模造紙と付箋を使うことが多いです。理由としては
- 目線が合わせやすい
- その場でタスクを足したり、「これもうDoneだよね?」と確認がしやすい
- 視覚的に誰にタスクが偏っているか、クリティカルパスが何かがわかりやすい
特に明文化されている決まりがあるわけではないので、プロジェクトごとにTrelloやAsanaのようなツールを使うのは自由です。リモートで作業しているメンバーがいるときは、都度wherebyやgoogle meetで繋いで進捗確認などをしています。
LayerXの(現状の)技術スタック
さて、技術スタックについても簡単に紹介します。言語選択等に関しては「この言語を使え」とか「このフレームワークをガッツリ使っていこう」的な方針があるわけではありません。速く確実にリリースできるように、都度都度その時点で一番よいと考えた技術を選択するような動きをしています。
一旦、現状利用している技術セットの一例としては
バックエンド
- TypeScript, NodeJS
- MySQL
フロントエンド
- Nuxt.js + TypeScript
コントラクトエンド(Ethereumの場合)
- Solidity
- Truffle
バックエンドをGoで書き始めたプロダクトも存在し、CordaというDLTではJVM系の言語を利用しています。また、弊社のR&Dプロダクトである秘匿ブロックチェーンのzerochainはRustで実装されています。全社まとめて今使っている技術セットをワードサラダ的にまとめると
TypeScript, Node.js, Go, Java, Kotlin, Rust, MySQL, PostgreSQL, CircleCI, Github Actions, Terraform, Solidity, Vyper, Nuxt.js, Vue.js, AWS, Azure, Corda, Ethereum, Quorum, HyperLedger Fabric, Substrate, GitHub, Docker, Datadog … etc
こんな感じになります。技術選択の理由などは以前blockchain.tokyoで発表した下記プロジェクトにまとめています。また、以前はReactでフロントエンドを書いたプロジェクトもありましたが、最近はVueを選択することが多いのであえて省いています(笑)
上記スライドにあるように
- バックエンド
- フロントエンド
- コントラクトエンド
各パーツを実装する必要があるため、各メンバーがフルスタックに色々な領域を担当できるようにアサインを変えたりしています。そのため「○○さんはまだSolidityを書いたことがないから次はSolidityでコントラクトにチャレンジしてみよう」的なコミュニケーションはよく行われます。
Solidityやコントラクトの実装に詳しいメンバーに質問しながら、新しくジョインしたメンバーもすぐキャッチアップできる体制にしています。
余談ですが、EthereumのVirtual Machineにとても詳しいエンジニアは「EVM」でslackの通知が飛んでくるように設定しているので「EVMつらい」などと言うとすぐに飛んできてくれます。
LayerXエンジニアの様子
朝会の様子
slackはreactionを使いつつ楽しくやっています
勉強会の様子
毎週少なくとも2つくらい、技術・ビジネス問わず勉強会が開催されています。チームをまたいで調査している内容の共有や、新しいアルゴリズムや技術の共有をします(普通に結構勉強になります)
- 認証としての暗号プロトコル
- Cordaのハンズオン
- コンセンサスアルゴリズム勉強会
- Project Xのインフラ構成共有会
- Project Y開発におけるフロントエンドの技術スタック選定
振り返り会の様子(KPTを実施することが多いです)
LayerXプロダクト開発チームが好きな本
その他
- 勉強会登壇や海外カンファレンス登壇・参加など、外に対して情報発信するのは会社として推奨してます。ブロックチェーン界隈限らずソフトウェアエンジニアリングに関わるコミュニティ全般を盛り上げていきたいです。
- 多くのメンバーがブロックチェーンはゼロから勉強しています。ウェブの技術スタックとブロックチェーンの要素の掛け合わせでアーキテクチャを組んでいく必要があります
ここまで読んでいただきありがとうございました。お元気で。
LayerXではブロックチェーン領域に挑戦したいエンジニアを募集しています。軽くお茶して情報交換するだけでも、ブロックチェーンわからないから教えてくれという質問するだけでも何でも対応しますので、少しでも興味のある方はシュッと「話を聞きに行きたい」ボタンを教えていただけると幸いですmm
プロダクト開発エンジニア
SRE
R&Dエンジニア