【反省】初めて勤め先でWebサービスを開発→リリースして学んだこと

どーも、ぐるたか@guru_takaです。

先月2020年4月初旬に、KIKAGAKUというサービスの開発をほぼ1人で担当。デザインだけPMに外注してもらっています。当初はSSRでリリース予定でしたが、SSG(アーキテクチャはJAMStack)に落ち着きました。
参考 AIを無料で学べる学習サイトKIKAGAKU

勤め先で初めてのWebサービスをリリースなんですが、個人的にはめちゃくちゃ反省点が多かったです。忘れないように、また同じ過ちをしないためにも、ブログに残すことにしました。

主な反省点

  • デザインはできる限り、作り込むべきだった
  • DB設計はできる限り、作り込むべきだった
  • 積極的に相談・頼るべきだった
  • バックエンドでエラー起きたら、真っ先にログを確認すべきだった
  • MVPを意識すべきだった

1つ目:デザインはできる限り、作り込むべきだった

デザインをできる限り、作り込まなかったのは、大きな反省の1つです。悪夢でした。理由は3つあります。

  • 度重なるデザインの修正により、実装したコードの手戻りが多発
  • デザイン変更による大改修でモチベダウン
  • 当初のデザインで外注したCSSの改修コストが大きいケースあり

実装したコードの手戻りが痛すぎましたね…。また外注したコードが使えなくなるのも、辛かったですね。

実装しないとわからないデザインも多いとはいえ、XDなどでできる限り、プロトタイプを作るべきでしたプロトタイプで議論↔改修を繰り返し、最終形を決めてから、コーディングするのが、安牌です。

個人開発でもデザイン決めずに手戻り多発で苦い経験をしたことはありました。これから運用ベースの開発は、プロトタイプを作ってから、コーディングしていきます。

2つ目:DB設計はできる限り、作り込むべきだった

KIKAGAKUでのDB設計とは、ヘッドレスCMSを指しています。DB設計を軽い気持ちで実装した結果、ヘッドレスCMSが関わる改修コストが大きすぎて、発狂しそうでした(^p^)

DBもデザインとあわせて、一緒に構想を決めた方が、開発者が幸せになれると強く感じます。

DB変更による大改修はもう経験したくないので、これからはDB設計する時は、デザインと一緒に考えます。

3つ目:積極的に相談・頼るべきだった

途中から気づいたのですが、開発で本当に困って同しようもない時は、積極的に他の人に相談したり、頼るべきでした。

他の人と一緒にデバックするだけで、精神状態が良くなります。また、そこからヒントを得て解決できるケースも多々ありました。他にもより良い代替案につながることも!

弊社や社外のコミュニティは本当に優しくて、凄い助けてくれました。リリース直前にCDN設定でパニクって、弊社の代表がzoomで一緒にデバックしてくれたのは心強かったです

社外コミュニティも、技術的に困っていることを助けてくれて。前向きな気持ちになれました。

一人で抱え込んで良いことないので、皆に気軽に相談・頼るって大事です。自分が頼られたときは、周りが助けてくれたように、親身に対応しましょう。助け合い精神、大事!

4つ目:バックエンドでエラー起きたら、真っ先にログを確認すべきだった

SSRでプロトタイプをデプロイしてみた際に、サーバー周りでめちゃくちゃ詰まりました。結論からいえば、サーバー側のログをみて試行錯誤したら、無事に解決!

今思えば、サーバー周りのデバックが不慣れだったのか、自分の憶測で的はずれな仮設を立てて、確度の低いエラー対応をしていましたね…

フロントと同様に、バックエンドでエラーが起きたら、まずはログが残っている場所を確認して、エラー文や警告文を読みましょう。それをググるだけで、確度の高い解決策が出てきます。

5つ目:MVPを意識すべきだった

MVPを意識しなかったことで、遠回りの開発をしてしまいました。静的サイトでOKで良くない?となった瞬間に、開発コストが激減。スムーズにリリースできました。

今思えば、以下3つを考えるべきでしたね。

  • サービスのゴールは何なのか?
  • 1週間で作ると言われたら、何の機能を残すか?
  • 追加機能は、最初のリリースで本当に必要なのか?

個人開発でも大事な視点です。開発期間が間延びすると、モチベーションにも悪い方に影響します。だからこそ、1〜2ヶ月で短期集中で開発するのは、大事だと思っています

また不必要な機能を追加しないためにも、サービスのゴールを明確にして、「いる」 or 「いらない」の判断もハッキリさせましょう。でないと、本当はいらない機能も何となく追加することになります。

とはいえ、どこまで作れば良い?と考えると、中々思いつかないケースもあるので、「1週間」という制約を設けると、具体的にMVPをイメージできます。

これからの開発では、「1週間で作るなら、どんな機能にする?」ということを考えていきたいですね。

最後に

今回のWebサービス開発は大きな経験になりました。次はこの反省を活かして、より良いプロダクトを開発してみせます!

コメントを残す