プロダクト開発に集中するための構造設計
こんにちは、BYARD(バイアード)です。
つい先日、YouTubeチャンネルにて『BYARD』の使い方を見ていただける動画を公開しました！ユーザーの方にも、開発に加わっていただく新たなメンバー候補の方にも、プロダクトの魅力をわかりやすく伝えられるように今後も発信していく予定です。
さて、今回のテーマは「プロダクト開発で大事にしていること」です。前回に引き続きCTOと開発メンバーであるエンジニアが現場の声を交えて語ります。
今回の登場メンバー
BYARDのCTO。アーキテクチャの選定担当者。
開発チームメンバーで、フリーランスのエンジニア。
『BYARD』に携わること約1年。
重要な部分の開発に集中するための環境構築
ーー"自分たちが開発すべきものに集中する"ということを重視してアーキテクチャ設計を行ったということですが、くわしく説明していただけますか？
辰本：最小限の開発チームのリソースでバックオフィスの課題を解決するプロダクトを開発するために、設計段階から大切にしているポイントは3つあります。
1つ目はマシンリソースの運用工数を削減することです。この構成図を見ていただければおわかりになると思いますが、『BYARD』ではWebサーバーやミドルウェアを自前で立てることはせず、AWSのマネージドサービスを使用しています。構成自体は珍しいものではなく、たとえばAppSyncとDynamoDBについてもサーバーレスの環境としては典型的な構成だと言えると思います。
鈴木：最近ではフルマネージドサービスの利用も珍しくないですからね。とはいえ、やはり少し前の時代と比べれば工数の差は段違いです。物理サーバーの故障対応もなく、リソースもCloudFormationで管理されているので、考えなければならないことが格段に減ったと感じています。
辰本：2つ目のポイントは開発における関心事を集約することです。現時点で開発チーム自体がコンパクトであることも勘案して、フロント・バックエンドのコード・IaC・CI/CD・ユニットテスト・E2Eテストを1つのリポジトリで管理できるようにしています。
これにより、ある部分を直したい時によく起こりがちな「リポジトリが複数に散っていて担当者でなければ該当箇所を探せない」という事態が構造上起きにくいようにしています。
鈴木：ある程度時間が経ってシステムが大きくなってくると、いつのまにかサブモジュールが増えてしまっているというのはよくあることですよね。IT業界は人材の流動性も高いから担当者がいなくなってからブラックボックス化してしまうパターンも多い気がします。わけがわからなくなってから直すのは誰しもが避けたい作業ですよね。
辰本：3つ目のポイントは外部サービスのAPI連携をすべてAppSyncのデータソースとして管理することです。これによってAppSyncの1つのエンドポイントから各データソースを指定して外部サービスと連携できるので、どこで何と繋がっているかコードをみればすぐ分かるようになっています。
鈴木：開発としてはREST APIが乱立している状態より、1箇所で集約管理する構造になっている方が「こっちでもやってたのか……」という状態になりづらい分だけ安心感はあります。しかし正直なところ、まだAPI連携を多数組み込むような段階ではないので、このあたりの効果が実感できるのはまだ先ですね。
"整理された本棚"を保てる構造
ーーいくつもの現場経験されているエンジニアとして、鈴木さんは『BYARD』のアーキテクチャのどのようなところに魅力を感じますか？
鈴木：エンジニアとしては、やはり現段階で最新のアーキテクチャ構成になっているのが良いところだと思っています。IaCでインフラを管理する仕組みがポピュラーになったのは割と最近のことで、エンジニアになりたての頃からすれば考えられませんでした。実際に体験してみるとストレスが少なく、開発に集中しやすい環境になっていると感じます。
辰本：どうしてもプロダクトのベースは設計された時の技術が土台になる分、新しいものの方が作業しやすい傾向はありますよね。逆に、ある程度年数が経過しているプロダクトでは「もっと便利なものがあるのに……」と感じながら作業を行わざるを得ないこともある。
鈴木：そのあたりはプロダクト開発の避けられない宿命ですよね、日進月歩の世界ですから。現在JavascriptのフレームワークはReactを使っていますが、新しいものとしてはSvelte.jsも出てきていますよね。Rustでフロントエンド開発を行う話も耳にした気がします。
辰本：確かに。何がスタンダードになるかはさておき、5年経ったら要素技術が大きく変わってくるのは間違いない。
鈴木：変わっていくのが当然だからこそ、僕は新しい技術を扱えるプロジェクトの方が嬉しいと思っています。たとえ慣れていて学習コストがほとんどないとしても「この技術、これからの新しいプロジェクトではもう使わないんだよな……」とどこかで思いながら業務を続けるとモチベーションがどうしても苦しくなってきてしまうんです。
ーープロダクトの土台が新しいというのはやはり大きいのですね。
鈴木：ただ、当たり前ですが、どんなシステムも時間が経つごとに複雑さ増していくものだと思うんです。新しい技術が次々に登場するので、良い物に対応して作り替える必要も出てきます。それにサービスの成長と共に新たな外部サービス連携や機能追加がされていくと、徐々に整理ができていない状態になっていってしまう部分はあると思っています。
辰本：そうですね。もちろんコーディング規約のようなルールとレビューによって大きく道を外れないようにするのはもちろんですが、都度整理していく必要もありますね。
鈴木：僕にとっては本棚のイメージなんです。
「技術関連の本はココ」「マンガはココ」って場所を決めて置いてあるんだけど、新しいものを追加するときちんと分類できていなかったり、面倒だから机の上に置いて戻さなかったりするじゃないですか。
辰本：トイレで本を読みたいから一部トイレに置いておいたりね（笑）。
鈴木：そうそう。それが常態化していって、結局いろんなところを探しにいかなきゃいけない状態になってしまう。
辰本：家の本棚ならそれでもいいですけど、一人ではなくチームでそれを触って管理していくわけですからね。しかもお客様のデータに触れる部分なわけで、そこは非常に重要です。
だからこそ仕組みづくりが大事で、「その通りにやらない方が面倒だ」という形を作ろうとしたのが、リポジトリやAppSyncによるデータソース管理なんです。もちろんAppSyncを経由せずにAPI連携をさせることもできてしまうけど、しっかりルートができているならAppSyncを経由させた方が良い。
最初の時点では学習コストもかかるし手間に感じるかもしれないけど、決まりに従う方が楽な構造を作ることで、その時の手近な場所に本を置くようなことは抑制していけるはずです。
鈴木：BYARDでは設計者がそういった管理への意識を持って仕組みを作っているところに、かなり安心感を感じています。ほぼフルマネージドなので余計なことに気を取られない分、全体最適を考えたプロダクト開発への意識を保ちやすいのもあると思っています。
2023年2月時点でのチームの体制
ーー最後に、現在の開発体制についても少し教えてください。
辰本：現在BYARDではスクラム開発を行っています。また、オフショアで開発に協力してくれているメンバーが7名(2023年2月末現在)いて、彼らとの橋渡しをするブリッジエンジニアがすべてのスクラムイベントに参加してくれています。
このあたりのくわしいチーム体制や開発プロセスについては、また次回も鈴木さんから現場の感覚を教えてもらいながらお話したいと思います。
鈴木：プロダクト開発に集中できるかどうかはチームの連携体制に大きく左右されるので、関心も高い部分だと思います。次回も現場目線でお伝えしますね。
ーーお二人ともありがとうございました。次回もよろしくお願いします！
▼CEO・CTOのカジュアル面談ただいま受付中です。
▼『BYARD』のドメインについて語った記事もどうぞ。
▼CEO武内の連載記事『BYARD開発記』（全13回）もご覧ください。
▼現在さまざまな職種のメンバーを募集中です！
この記事が気に入ったらサポートをしてみませんか？