小嶋陽介といいます。2024年12月にアダコテックに入社し、AdaInspector Cloud(以下ADIC)というクラウドSaaS製品のフロントエンド開発に携わっています。
元々はReact Nativeを使ったモバイルアプリ開発を中心に携わってきました。その背景もあり、ユーザーがストレスなくソフトウェアを使ってくれることに興味・関心があり、自分なりにデザインやユーザー体験の提案もしてきました。
私自身、外観検査や製造業といった分野に関して経験や背景知識等は何も知らずに参画させていただきましたが、面談等でデザインやユーザー体験に課題感があるということを事前に伺っており、前述した自分のタイプ、そしてある意味こういった事業分野の経験のなさが逆に活かせるのではないかと思い参画しました。
やっぱ難しい
入社してから実際にADICを触らせていただきましたが、思っていた以上にユーザー導線が煩雑でした。ADICは、異常検知のための学習モデルを作成する学習環境ですが、そのメインであるモデル作成の導線が複雑で画面に出てくる用語も難しく、覚えるのに数週間かかりました。実際カスタマーサポートの方の顧客への説明負荷も大きいもので課題として社内に上がっていたようでした。元々、YouTubeやAmazon、iOS、最近だとChatGPTなどなど、説明など不要で小中学生でも使いこなせるような素晴らしいソフトウェアにばかり触れてきた私にとって、ADICの導線は必要以上に複雑でこのまま運用保守を続けることに大きな課題を感じていました。同時に、紙に「こうした方がよくない？」といったスケッチを密かに始めていました。
デザイン改修プロジェクト
この思いはメンバーも同じだったようで、入社して2,3ヶ月経ったところで同じフロントエンド開発をしていた方をProduct Ownerに据え、「オンボレスなUI/UX」を目的としたデザイン改修プロジェクトが立ち上がりました。私と同じタイミングで業務委託として参画されたフロントエンドエンジニアの方もチームに参画し、3人体制でのフロントエンド刷新開発になります。
ただ、キックオフしたのはいいものの課題が二つありました。一つ目が、この画面ではこういう情報を見せて、こういう動作できる様にするといったソフトウェアの全体像が明確に定まっていない状態であること。二つ目が、業務委託のデザイナーの方が在籍されていましたが、当製品の他にもデザインの案件がありフルタイムで関わることができない時間的な制約があったことです。
ただ、この頃になると私がADICの製品の仕様に関してはある程度把握ができていて、前述した通りスケッチしながら自分なりのADICの設計をなんとなく描いていたことから、私がデザインをやらせていただけないか？とチームに申し出ました。「まあいけるんじゃないか」くらいの気持ちでしたが、幸いにもそういった挑戦心を受け入れてくださるチームで、その場ですぐに承認いただきました。
デザイン未経験のフロントエンド開発者がデザインをやるのか？
そう思われると思います。ただ、私自身プログラミングを始めた頃から個人でものを作るということを絶えず続けてきており、「こうしたら分かりやすいのではないか」「こう作った方がユーザーは楽に使えるのではないか」といった具合で使い人の心理を考え実際に自分で作ることが好きでした。実際にそれが使う人に刺さった時はとても嬉しいものです。個人の趣味で何か設計するのと会社という組織で何か設計するのでは勝手が違うと考える方もいると思いますが、どちらにも共通して応用できることがありました。それが「盗む」ということです。
個人開発では、自分の作りたい機能や要件を決めたら、それをどう画面上で見せユーザーに使ってもらうか、DribbbleといったデザイナーのポートフォリオサイトやDiscord、Slackといった有名なアプリ、競合アプリ等のデザインやアニメーションの手法を盗んで、紙にイメージを草案して開発するというやり方を癖にしていました。
今回のチーム開発では、まず顧客はどこに使い勝手の難しさを感じているのか、事情をよく知っているチームメンバーと議論を重ね要件を整理し、その解決手法のヒントを外観検査アプリとは全く関係ないYouTubeやGoogle Drive、Airbnbといったアプリケーションから得ていきました。そして「この導線は使える」というのを見つけたら、紙に大枠のデザインとユーザー導線を草案しチームメンバーに見せました。最後に、開発チームで共有するためにFigmaの使い方を一から覚え、デザインしチームに共有します。
最終的に10数ページで構成されていたアプリはモーダル等を駆使しながら2ページにまとまりました。あえて既存のデザインなどは無視してデザインしてきましたが、メンバーからはよさげな「斬新だ」と反応をいただき、そのまま開発に進みます。
開発着手
ADIC全体のデザインが大体まとまったところで、いよいよフロントエンドの開発着手です。既存のフロントエンドリポジトリはTypeScript, React, Next.js, Material UIといった技術構成です。新しいバージョンアプリもこれらを継承するのですが、どのライブラリも結構古いバージョンのものが使われていたので、そのアップデート作業を業務委託の方がこなしてくれました。また、Reduxで管理されていたAPIレスポンスのキャッシュ機構をSWR、Orvalを使ったものにしたこと、AppRouterの導入など、技術面でも改革をしました。
開発している最中で、デザイン変更の提案がメンバーからあったりと柔軟に対応してきました。また、実際に作ったものを開発部メンバーや事業開発部の方にデモで見せて、助言をもらい修正する、ということを繰り返してきて半年ほど粘り強く開発し、ようやく世に送り出せる段階になりました。技術的な面でテスト機構がまだ不十分であったり、Reduxによる状態管理がまだ残っていたりと、リファクタリングが必要な箇所はまだありますが今後はそれらに向き合いながら、ユーザーの声を拾いより使いやすいものにしていく必要があります。
振り返ってみて思うこと
「フロントエンドエンジニア兼デザイナー」という特殊な役割を担ったのかもしれませんが、人員の限られた環境で、スピード感をもってこれからものを出荷していこうという段階であればこのやり方は悪くないと考えています。事業開発部を含め、メンバーと議論しユーザーの課題感などを傾聴し要件を整理した上で、世にある参考材料をうまく当てはめながら作っていくことが大事です。デザインシステム、アプリの統一感やデザインの運用性といった細かい部分で考慮すべき部分はありますが、そういった部分は出荷した後に調整をしていけばいいと考えています。
また、昨今はAIエージェントの成長スピードが早く、次々と興味深いツールアプリが世に出てきています。エンジニアであると、ソフトウェアの仕様や構成を理解している人は多いでしょうから、背景知識や文脈などをAIに食わせて指示をだし全部AIにデザインしてもらって、足りない部分を指示者が帳尻を合わせていきながらデザインと実装を走りながらやっていく方法もあります。
方法論はさまざまですが、説明書いらずの簡単に使えるアプリを作るためにも、チーム全員がユーザー体験にこだわる必要があるでしょう。今回だと、最初のデザイン段階で提案したもので、今回のようなフロントエンドの改修だけでは実現できず妥協した機能がありました。根本的に使いやすい製品を目指すためにも、バックエンドや機械学習周りのコアロジックなど、ポジションに拘らず皆が改善意識をもち、小さい単位の改修プロジェクトを繰り返し少しづつ変えていくことが重要だと考えます。
