CTOと開発エンジニア、『BYARD』のアーキテクチャについて語る
こんにちは、BYARD(バイアード)です！
2022年10月に、ついに正式ローンチを迎えることができました。今まで様々なお声を寄せてくださった皆様、本当にありがとうございます！ユーザーの皆様の期待に応えていくためにも、もっとエンジニアチームはパワーアップを図っていきたいと考えています。
今回の新たなエンジニアに贈る第5弾のテーマは「アーキテクチャ」。CTOと開発メンバーであるエンジニアの対談で、アーキテクチャ選定の前提と実際の開発現場の声をお届けします。
今回の登場メンバー
BYARDのCTO。アーキテクチャの選定担当者。
開発チームメンバーで、フリーランスのエンジニア。
『BYARD』に携わること約1年。
エンジニア向けの『BYARD』で解決したい実例
ーー「アーキテクチャ」についての話を話を聞ければと思うのですが、今日はお二人ですね。
辰本：はい。私はCTOとしてずっと『BYARD』のことを考えてきていますので、ちょっと話す内容が客観性を失ってきているかもしれないという不安も持っていまして（笑）。
そこで、現場の立場で情報を補足してもらえればと、開発メンバーの鈴木さんに同席してもらうことにしました。鈴木さん、「おいおい、現実と違うぜ！」という所があれば遠慮なくツッコミをいれてください。
鈴木：了解です。
ーーまず、アーキテクチャの構成の前に『BYARD』で解決したいことについて教えてください。
辰本：すでに別の記事でもお話したので、ここでは簡単にお伝えしますね。現在、特定業務に特化したSaaSがバックオフィス向けにもたくさん出ています。これらは特定の領域については業務の効率化を推し進めているのですが、これらだけではバックオフィスの全体最適化はまだ進まないと僕らは考えています。
辰本：例えば、上の画像のように各SaaSが解決している領域は、業務が集まった大きな点だとします。しかし、その点と点には大きな隙間があり、そこを埋めるための業務は意識の外に置かれがちです。
こうした隙間を、バックオフィスの担当者は感性と努力と奉仕の心で埋めている。ここにこそ言語化されていない業務のペインが潜んでいて、ここで過剰に消費してしまっている人々のリソースを圧縮・解放したいと思っているんです。
鈴木：僕はフリーランスのエンジニアなので思うんですが、この課題感は結構ピンとこないエンジニアの方も多いかもしれません。
僕の場合はそれこそ各SaaSをバラバラに使うことで事足りていて、契約締結時に『ドキュサイン』『クラウドサイン』のような電子契約サービス、請求書のやり取りに『Misoca』のような見積・納品・請求書発行サービスを使うぐらいなんです。年末調整はクラウド会計ソフトでOKですし。
辰本：確かに。私が先ほど言ったような問題は、ある程度の規模の企業において部門を横断して行うやり取りに発生するものなので、エンジニアの方にはイメージしづらいかもしれませんね。
ーーエンジニアの方がイメージしやすい具体的な事例はありますか？
辰本：「ソフトウェア開発の資産計上」についてのやり取りはどうでしょう。ソフトウェア開発をどこまでを資産とするかを開発部と経理部ですり合わせるんですが……。
鈴木：聞いただけで大変そうですね……。
辰本：いや、本当に大変です。経理にとっては財務諸表へ影響が大きい部分なので非常に重要なんです。
ですが、経理部門が現在進行中の開発プロジェクトについての詳細を把握することは難しいですし、エンジニア側としても経理部門がどのような粒度のプロジェクトの情報を求めているかわかりにくい。経理の方から「適切な比率で出してほしい」と言われても、経理の方の提示する細目ごとにプロジェクトは組まれていないわけで「そうは作られてないんですけど……」と困ってしまうわけですよ。
鈴木：とはいえ、関知しないわけにはいかないですもんね。
辰本：そうなんです。だから、経理と自社サービスの耐用年数、機能修繕なのか新規サービスなのか、工数から金額を割り出して、大きさ次第では研究開発費にするとか、かなり綿密なやりとりをして計上しなければならなくて。きちんとやろうとするとかなり大変なんですよ。
先ほどの話にこの例をあてはめると、経費に関するデータを双方が入力して計算する会計システムはすでに存在していていて、使用されています。だけど、大変なのはその入力作業や計算ではなくて、部門間の溝を埋める「入力するデータをどうしたらよいのか」のやり取りなんです。そこに多大なリソースが割かれてしまっている。
鈴木：そのやり取りが何度も繰り返されるのはかなり大変ですよね。
ーー毎回、聞けば聞くほど見えづらいところにあるけど根深い課題だなと思います。
辰本：そうなんですよ。こういうやり取りが何度も繰り返されるのは、本当に大変で高コストだと思います。せっかく高いコストを使ってすり合わせたやり取りは、できれば再利用したいですよね。
うまくやりとりが可視化できていれば、次回はもっと楽に運用できるはずだし、既に使用している各SaaSとうまく連携できたら、さらに嬉しいですよね。きっと、初めての方がいたとしても、過去のやり取りが一覧できたら迷うこと少なくなると思っています。だから、そういうことが可能になるサービスを開発しようと考えたんです。
「少人数＆競合なし」という条件での開発コンセプト
ーー『BYARD』のアーキテクチャを選んでいくうえで、どんなことを考えていましたか？
辰本：まず1つ目の軸が、自分たちが開発すべきものに集中することです。私たちはバックオフィス業務の在り方を変えていくプロダクトを作りたいわけで、本当に必要な部分にのみ貴重なエンジニアのリソースを充てたい。
なので、当たり前ですが、世の中の優れたサービスを上手に使うことで「車輪の再発明」はしないで済むように意識しました。それから、運用の手間も極力かけない構成にすること。作るまでより、作った後の運用期間の方が長いわけです。人材獲得が難しい昨今、運用するためだけの人材を確保しなくてはならない体制にするのは現実的なやり方ではありません。
だから、私たちが考えなくてはいけない範囲を極力狭めて、少人数でも安全に運用できるようにマネージドサービスを積極的に採用する方針に決めました。
ーー2つ目の軸は？
辰本：可能な限り、キレイに早く捨てられる構造にすることです。『BYARD』が解決しようとしている領域にはベンチマークにする直接的な競合はいません。ということは、私たちの仮説通りにプロダクトの成長が進まないという可能性も高い。ならばリスクに備え、不要になった機能を思い切って切り離せるような構造にしておく必要がありますよね。
連携している各種SaaSなどについてはいざとなれば移設できるように、接続点になる部分を切り離してつくったりあえて連携させてなかったりする部分を設けています。
1年開発に関わったメンバーの実感
ーー鈴木さんは現場で『BYARD』の開発をしていて、さきほどのコンセプトに関わるところはどう感じていますか？
鈴木：運用工数はかなり削減されているなと実感があります。サーバーのリソースは何も気にしなくていいというのもありがたいです。それと、言語としてTypescriptができれば開発業務のかなりの部分までカバーできるというのも今のアーキテクチャのやりやすい部分ですね。
今までに経験してきたサービスのバックエンドはJavaやPythonなど違う言語を使っていたので。この構成であれば「Javaができないとバックエンドが書けない」「Javaでやっているからこのフレームワークを使用する」っていうことがないですから。
辰本：コンテキストのスイッチが少ないのは利点ですよね。Amplifyフレームワークのお作法を知ることは必要ではありますが(笑)
鈴木：まぁ、ある程度は仕方ないですよね。AWSやAmplifyは使ったことないという人も多いと思いますし、自分もやったことなかったので「こういう制約あるんだ」というのはやりながら気づきました。そのあたりはアーキテクチャというより学習コストの部分かな。
辰本：Amplifyの学習コストといえば、かなりキツい事故がありましたね。
ーー開発中にAmplifyで何かトラブルがあったんですか？
辰本：Amplify CLIは私たちが開発を始めた時にちょうどメジャーバージョンがVer.3でしたが、1年ぐらいのあいだにVer.10まで更新され、超ハイペースで開発が進んだんです。それで、ちょうど『BYARD』のリリースの間際にバージョンアップが重なってしまって。コードの書き方の解釈も変わってしまって不具合が大量発生したんですよ。
ーーうわぁ……。
辰本：不具合発生当初は原因が全く分からず、修正を加えていないのに、次々にデプロイが失敗していく様をみて、追い詰められたのをよく覚えています。
鈴木：ああいうタイミングってほんとに恐ろしいですよね。
辰本：ITエンジニア業界の宿命ではあるので仕方ないですが、あまり経験したくないですよね（笑）。
ーーキレイに早く捨てられる構造にするという点についてはどうですか？
鈴木：かなり意識されているなと思います。これはドメインの競合の有無に関わらず、エンジニアとしては重要なところですよね。例えば、使っていたエディタのライブラリの更新が止まって使い続けられなくなっちゃうようなことって、本当によく起きますから。
辰本：そういえばBYARD採用しているテキストエディタライブラリは鈴木さんが入ってから2回も変わってますね。
鈴木：いざというときにデータを他のプラグインでも使えるようにMarkdownで管理していたので良かったです。特定のものでしか使えない形式に依存しすぎていると、変えなきゃいけない時に身動き取れなくなってしまいますからね。
ーー今後、アーキテクチャについて重要なことは何だと考えていますか？
辰本：私たちの世界は本当にすさまじいスピードで変化していきますよね。たとえ2023年1月1日時点で最高のものができたとしても、3年後かそれよりもっと早く、もう何の役にも立たなくなってしまう可能性だってある。
そういう変化に追従していくために最も必要なものって、私はやはり可能な限り分かりやすく大きくなりすぎない範囲で「すぐに切り離して捨てられる」ことだと考えてます。
だから、「特定の要件」に依存するタイプのアーキテクチャは選ばないのはもちろん、なるべく切り替えができる構造のものを選んでいきたいですね。
そういう意味で、学習コストなど天秤にかける部分はありつつも、Amplifyをはじめとした現在のアーキテクチャを選択したのは良かったとふり返って思っています。
ーー辰本さん、鈴木さん、ありがとうございました。次回はより具体的なアーキテクチャについて、踏み込んでお話を聞かせてもらう予定です。
▼CEO・CTOのカジュアル面談ただいま受付中です。
▼『BYARD』のコミュニケーションについて語った記事もどうぞ。
▼CEO武内の連載記事『BYARD開発記』（全13回）もご覧ください。
▼現在さまざまな職種のメンバーを募集中です！
この記事が気に入ったらサポートをしてみませんか？