【エンジニア】ベンチャーでゼロから
プロダクトを創る！
こんにちは。VISLITE 開発チームのリーダーを務める笹渕です。
今回は、2年ほど担当している自社プロダクトについて、リニューアルも含めたプロジェクトの1つの区切りが付いたため、振り返って開発部の事業開発/プロダクト開発への関わりをご紹介できればと思っております。
ビジネス志向/プロダクト志向のエンジニアの皆様に、少しでも魅力を感じていただけましたら幸いです。
- [笹渕について]自己紹介
- [プロダクトについて]要件定義のドキュメント管理を行えるプロダクト
- 事業企画から参画し、プロダクトの計画を考える
- 実際に採用したアーキテクチャ
- 開発の中で生じた課題
- 開発を振り返って
- 最後に
自己紹介
採用サイトということもありますので、実際にプロジェクトのお話をする前に簡単に自己紹介をさせていただきます。
▼ 専攻
工学（学士）、ARやロボット研究（修士）▼ 職歴
- ベンチャー系のアプリ開発企業（4年）
ネイティブアプリ・WEBアプリ開発や運用/保守 - Diezon（6年目）
WEBアプリ開発や運用/保守、開発部門役員
▼ 志向
どちらかというと技術よりサービス志向▼ エンジニアとして大事にしていること
最初の1歩も大事だけれども、既存のものを汲み取り推し進めることも大事▼ 趣味
散歩、ランニング、ジム、漫画ということで、ざっくり言うと技術は好きなのですが、技術を使ってお客様に使っていただけるサービスを創ることに関われたらと思って、事業系の会社でキャリアを歩んでいるエンジニアです。
要件定義のドキュメント管理を行えるプロダクト
では本題に移りたいと思いますが、まず初めに、今回構築したプロダクトをご説明いたします。
今回開発したプロダクトは、「手戻り0（ゼロ）の要件定義を」実現するドキュメント管理ツール「VISLITE（ビズライト）」になります。
VISLITEはシステムの要件定義時に利用することを想定していますが、このプロダクトで解決したい課題は大きく二つあります。
一つ目は、システムの構築では膨大なドキュメントが分岐し、散在するという課題です。
私も経験したことがありますが、ローカルアプリで管理されるドキュメントは、複数人で編集を進める際に分岐が発生したり、最新版の所在が分からなくなったりすることも多く、プロジェクトを進める上で混乱を生じる原因にもなります。
二つ目は、各個人がオリジナル性を持たせたフォーマットで作成したドキュメントが更新されないという課題です。
パワポやエクセルは便利ですが、自由度が高いため、作成者によってフォーマットや管理方法が変わってきてしまいます。
フォーマットや管理方法が変わると、どこにどの情報があるか、またどんなフォーマットでどこに配置すれば良いかが分かり辛く、ドキュメントの間違いに気づいてもメンバーが更新し辛くなります。
また、フォーマットがバラバラだと、他の類似案件で使い回ししづらいという課題も生じます。
VISLITEでは、UIが共通化されたWEBアプリ上で一程度のフォーマット制約に則ってドキュメント作成/管理できるようにすることで、上述の課題を解消することを目指しています。
事業企画から参画し、プロダクトの計画を考える
今回のプロダクト構築にあたっては、笹渕は事業企画フェイズから参画しました。
小さい会社なのでロールは細分化されていませんが、メインの事業責任者とUIの責任者と共に、開発側のリーダーとして参画しました。
（ちなみに、当社では本事業のみならず、事業企画の場には必ずエンジニアが参加します。）
サービスをどうするべきかという話にももちろん参加しますが、開発側のメンバーとして重要になるのは、技術選定/アーキテクチャ設計です。
プロダクトに限らずビジネス全体を見ながら考えていきます。
技術選定/アーキテクチャ設計にあたって、具体的に考慮したのは以下のような点です。
①ビジネス要求を満たす
- ビジネス利用を想定した、利用頻度の高いツールとして、素早い操作感を実現する
- ワードとパワポとエクセルのような特性の異なるツールの併存を想定する
- SaaS提供のため、同一システム内でアクセスできるスペース（組織）を制限し、さらに各ツールに対してもアクセス権限の設定を行える
- 今後の拡張性やリニューアル時の移行性をどの程度担保するか
新規サービスには限りませんが、初期フェーズではいかに早く/限られた予算の中でサービスをリリースするかも重要なため、上記のすべてを完璧に考慮するというよりは、バランスを取って、 後からビジネスとの齟齬が生まれないようにすることを重視して検討しました。
②チームに親和性のある技術であること
- 在籍メンバーのスキルセットと親和性を持ち、できるだけ社内メンバーで完結できる技術構成であること
- 組織が成長していくために、得るべき技術構成であること
Diezonは小さい組織ということもあり、プロダクトメンバーが固定されるのではなく、プロダクトを横断してアサインされます。
そのため、組織全体の技術の親和性や今後の方向性も考慮しました。
③開発効率性/拡張性/保守性
- ビジネスの拡張時にメンバーが増えた場合にも、できるだけ小さな工数でキャッチアップできること
- 構築後に機能の追加がしやすいこと
- 効率的に保守が行えること
ベンチャー企業は体力（資本）が小さいこともあり、効率的な開発/運用ができなければ、プロダクトを良いものに仕上げ、お客様に使ってもらえるようになる前に力尽きてしまいます。そのため、プロトタイプ、ベータ版、正式リリース、機能拡張と、 各ステージを効率的に進めていくことも重要なマターと認識しています。
実際に採用したアーキテクチャ
上記の観点から、実際に技術選定を行った結果、以下のような構成に決定しました。
▼ フロントエンド
- • 言語：React × TypeScript
- • フレームワーク：Next.js
- • クライアントライブラリ × 状態管理：Apollo Client
▼ バックエンド
- • 言語： PHP
- • フレームワーク：Laravel
- • API: GraphQL by Lighthouse
また、後から参画するメンバーのキャッチアップ工数も考慮し、ドキュメントとしても管理しやすいGraphQLを導入することとしました。
GraphQLでAPI定義を管理することを徹底することで、フロントエンドエンジニアやQAチームがAPIを把握しやすいようにしました。
▼ インフラ
- • AWS Fargate × RDS × ElastiCache × S3 etc.
そこでAWS Fargateを用いたコンテナでのデプロイを行うことにし、デプロイ時に常に最新の状態を保てるとともに、ミドルウェアなどのインフラ環境の変化に対してもコンテナ単位で容易に管理できるように考えました。
開発の中で生じた課題
ここまで技術選定/アーキテクチャ設計において考慮してきたことを記載しましたが、記載した内容に関しては、概ね意図した通りに機能したと言えると思います。
しかし、実際にプロジェクトが明けてみると、強く考慮しなかった点で課題が生じた部分もありました。
その部分に関しても、少し記載できればと思います。
生じた課題①：フロントエンドのコンポーネント管理
プロジェクト当初は、フロントエンドのコーディングは、マークアップコーダーがHTML/CSSで作成したものをエンジニアがReactに組み込むというプロセスをとっていました。
しかしながら、フロントエンド（UI）の変更が行われる中で、デザイナー→コーダー→エンジニアの連携において、コンポーネントの単位や属性に対する認識の差異が生じると、コードの共通化において不備が発生し、大きな修正工数を要しました。
これらの課題を検知できたのはほぼフロントコーディングが終わった段階だったため、方針転換には時間を要しましたが、その後の開発効率性も考慮し、起動修正しました。
具体的にはデザインシステムであるStoryBook を導入し、Storybook でコンポーネントとしてどのような単位や属性が存在するのか、メンバーでイメージを明確に共有することで連携をスムーズにさせました。
生じた課題②：各ツールの管理不足
先にも述べましたが、今回のプロダクトには、様々なタイプ（機能/操作感）のツールが併存します。
工程を考慮した際には、プロダクトの共通機能を早くに仕上げ、各ツールの固有の機能は手分けをして実装していくことを検討し、各ツールの要求の詳細確認を後手に回しました。
しかし、実際に手分けをしてツールの要求を詰めていったところ、想定より要求が多く、フロントエンドの開発におけるリソースや進行管理に課題を抱えるようになりました。
パートナーの応援もいただき対処しましたが、ライブラリの選定からやり直すなど、スケジュールに大きく影響する結果となってしまいました。
現在でも、ドキュメント含め満足な管理に至っていない部分もあり、プロダクト根幹のツール機能の開発にスピード感が出ない課題は抱えています。
今回のプロダクトは、ツールがメインとなるプロダクトであるため、初期の頃からツールがコア機能であるという意識をより強く持てれば、もう少しスムーズな進行ができたのではと反省している部分もあります。
開発を振り返って
小人数で工数が限られる中で、その後の開発効率を担保するためにも、技術選定/アーキテクチャ設計は重要です。
今回のプロジェクトでは、大きな部分は意図通りに実現できましたが、やはり意図が薄かった部分には課題が生じました。
知識や経験に基づいて認識ができていなかった部分もありますが、ツール機能に関してはフロント側でなんとでもなると、自分のミッションとするスコープ（視野）から漏れてしまったのが主な原因かと思います。
特に新規のサービス開発においては、自分の想定を超える要求が存在することも踏まえ、プロダクトのコアを意識しながら、プロジェクトを進めることが重要だと改めて感じました。
最後に
Diezon開発部では、ビジネスの成長に寄与できるよう技術を使いたいと思っています。
その目的に対しては、新しい技術を採用することもあれば、あえて枯れた技術を採用することもあります。そうしてビジネスを踏まえた技術を選んでいかなければ、少なくともベンチャー企業の限られたリソースの中で、
お客様（クライアント/ユーザー）にも価値を提供できないと思っています。
特に新しいプロダクトの開発においては課題もたくさん生じますが、その課題を解決することで組織としても新しい力を得られます。
こうした意識をメンバーで共有して課題に取り組めれば、Diezonのミッションである「サービスや製品の開発を通じた新しい価値の創造」を実現し続けられる組織になると思っています。
Diezon開発部のエンジニアとして働くことに少しでも興味を持っていただいた方は、まずはカジュアル面談へのエントリーをお待ちしています！
カジュアルにお話する機会を通して、詳しい業務内容や働き方、会社の雰囲気などをより感じていただければと思います！
