見出し画像

MVPリリースに向けて２ヶ月間取り組んだ内容の振り返り

りょーた ❖ DESIGN engineer

こんにちは。2023年1月より株式会社ニュートラルでデザインエンジニアをしております、りょーたです。

この度、Musubite（読み方：むすびて）というサービスをMVPでリリースしました👏👏👏
一旦の区切りとして、ジョインしてからの約２ヶ月を振り返りをしたいと思います。

役割

私は1人目デザイナー＆1人目フロントエンドエンジニアとして、以下を担当していました。

  • モックやグラフィックの作成

  • フロントエンド開発全般

前職はSIerでフロントエンドエンジニアをしており、フロントエンドの開発に関する知識は自走できるレベルだと思っていますが、デザインに関しては、完全に独学で、アウトプットする機会もそれほど多くなかったので懸念点ではありました。

Musubiteを利用して下さった方は、ぜひフィードバックを頂けたら泣いて喜びます😂よろしくお願いいたします！


振り返り① ポジティブな変更か判断する

約２ヶ月という期間でしたが、たくさんの仕様やUIの変更がありました。
そんな中で、変更には、ポジティブなものとネガティブなものがあると感じました。

ポジティブな変更とネガティブな変更の違いは、サービスの軸に沿った変更であるかどうかと私は定義しています。

ポジティブな変更の場合、自分たちが掲げるサービスのミッション、バリューを利用者の皆様に伝えられることになると思います。
一方で、ネガティブな変更の場合、実現したい価値提供と関係の薄いものであり、ユーザーの体験価値の向上に繋がらないだけでなく、ネガティブな影響を与えるリスクさえあると考えます。

今回のケースでは、変更するかどうかを議論するに至る要因は、大半がユーザーインタビューによるフィードバックでした（ヒアリングにご協力いただいた皆様、ありがとうございました！🙇‍♂️）
そのフィードバックをもとに、社内メンバーでたくさん議論を重ねたのですが、私の中でどの意見が重要なのかがわからなくなった時がありました。

そこで、改めて、ペルソナや共感マップを考え直し、ペインやゲインについて話し合う時間を設けました。
そうすることによって、Musubiteで体現したいバリュー、届けたいユーザー、ペルソナが望む未来の姿を共通認識として持てるようになり、「この意見はサービスにとって重要であり変更すべきである」かどうかをより集中して議論できたと感じます。


振り返り② ベストプラクティスに固執しない

これは、賛否両論ある内容かなと思うのですが、率直に思ったことを書きます。
今回モックを作るにあたって、Figmaを利用したのですが、モックを作り始めた当初は、

  • デザイントークンを定義

  • primary, secondary, tertiaryカラーを決定

  • カラーコントラストがa11yで問題ないかチェック、微調整

  • UIコンポーネントを一通り作成

  • featureのコンポーネントを作成

  • ページを作成

といった作業をしたのですが、仕様変更やUIのフィードバックの中で、各所を都度修正する時間を確保できなくなりました。そのため、途中から

  • 変更しなさそうな部分のみコンポーネント化する

  • デザイントークンは開発で利用しているUIフレームワークの定義を正とし、figmaの方を継続的に管理しない

という方針に変え、時間を節約する方向に変えました。

この決定は、応急処置に過ぎず、今後開発メンバーやデザインのメンバーが増えた時にどうするか、コンポーネント化していないことによるデザインの揺らぎをどう担保するのか、といったことを将来考えないといけません。

ただ、とはいえ、自分の実力的に管理を十分にできない今、いたずらに時間をかけてしまう方がサービス全体へのインパクトが大きいと考えました。

タスクに対して、最良の方法で課題解決を行うのは当然の姿勢ですが、同時にリスクヘッジを行う習慣をつけていかないと、と思いました。

完全に余談ですが、以前にプロジェクトにテストを導入するかどうかという記事を読んだときに、

テストコードを書くことによるスピードと品質はトレードオフでなく、あなた（および開発メンバー）の実力不足です

と書いているのを見て、すごく腑に落ちました。
本当にその通りですよね😇

振り返り③ 不確定要素は早めに対策を行う

今回フロントエンドの開発でも、初めて経験がありました。
いくつか例をお話しすると

  • Next.jsの経験はあったのですが、ほとんどSSGで利用していたので、SSRを使った経験が乏しかった

  • Amplifyをがっつり利用した経験がなかった

  • 正式なプロダクトでSNS認証を初めて使った

  • SSRでGTMを初めて使った

などが挙げられます。

↓詰まっている様子

タスクのバッファーを取りづらい今のフェーズにおいて、「経験はあまりないけど調べてみたら似たような実装あったから大丈夫」は全く信頼できなくなりました（今では自分で禁句にしてますw）

そのため、不確定要素が少しでもあるタスクに関しては、スプリントの最初に持っていき、後になるにつれ、実装イメージが完全についているもの、全く同じ経験があるもの、他のメンバーに触れるものだけにするようにしています。

今の対策でも、おそらく計画通りにいかないことはあるかと思いますが、少しでもリスクを減らして進めていけたらと思います。他に「こういった工夫してるよ」といったアドバイスがありましたらご教授ください🙇‍♂️


最後に

約２ヶ月間、新しいことへの挑戦をたくさん経験できて、とてもよかったです。
アーリーステージのスタートアップでの経験や、デザインとフロントエンドの２領域を実務で行ってみた感想など、お話しできることはたくさんあると思うので、ご興味をお持ちになった方はぜひ気軽にお話ししましょう！


いいなと思ったら応援しよう！

この記事が参加している募集

#振り返りnote

95,204件