はじめに
先日「Hirameki」という小さいWebサービスをリリースしました。
このサービスを開発する前にも別のサービスを基本的には１人で開発を行っていたのですが、
現在開発が止まっている状態です。
なぜこのHiramekiというサービスはリリースできたのか。
それは別で開発していたサービスから学んだ結果を活かして開発を行ったからです。
今回はそこら辺について備忘も兼ねて簡単にまとめたいと思います。
前提条件
実際に開発を行うメンバーが1人
個人でサービスを出したい人（おのずと1人でやることになるはず）
背景
元々は動画配信サービスを企画して開発していました。
手を動かすメンバーは私を含め2人でした。
私ともう１人も業務委託で現場の仕事をやりつつもり隙間時間で開発をおこなっていました。
もう１人のメンバーにはAWSでサーバーの用意や開発環境の構築、ビルド&デプロイの自動化を行ってもらっていました。
私はフロントエンド、バックエンドの設計開発です。
バックエンドはAPIとして作り、フロントエンドはReact+TypeScriptで作っていました。
しかし、徐々にもう１人のメンバーは現場が忙しくなり時間も取れなくなってしまい。
私がAWSにも手をつけることになり..
ここから開発がスムーズに進まず、さらにはコロナの影響で打ち合わせも設定しづらくなり、モチベーションなどが低下していきました。
このような状況から学び、やり方を変えて弊社代表と小さなサービスから開発するスタイルを試行錯誤しながらやっております。
技術に欲を出さないこと
このHiramekiというサービスは基本的には1人で開発を行っています。
メンバーは2人なのですが、もう一人の方にはサービスの企画をメインに、規約やプライバシーポリシー周りの法務関連について助けてもらってます。
この中で少人数だけど、基本的にアプリ全体を作っているのが１人の場合、自社プロダクトなのでエンジニアとしてはこんな技術が最近話題だから取り込んでみたい、あの技術を学習したいから自社プロダクト開発を機に取り込んで学んでみたい。
みたいな考えが頭によぎって、色々手を出してしまうことってありませんかね？
これではスムーズに開発をするのができなくなります。
その手の技術への知見が低い状態で開発を進めていくことは、開発をしながらその技術への知見を調べながら増やすことをしていかないといけないので1人での開発を進めていく場合は調べるという行為がボトルネックになります。
調べるのが悪いというわけではなく、手慣れた技術を補足するために調べる行為は、さほどボトルネックになることないと感じており、全く知見のない状態で新しいことを調べるという行為がボトルネックになると感じております。
そのため、Hiramekiでは私がある程度の知識があるDjangoを使って足りない部分の知識についてはドキュメント等を見て調べながら開発を進めています。
それでも全くDjangoを知らない状態から比べると少し調べたら理解できるのでそこまで開発スピードを落としていないと思っています。
最初はモノリスから
フロントエンドにより担ってしまいますが、近年ではフロントエンドの技術進歩がすさまじく、様々な技術やアーキテクチャの登場しています。
しかし、これらの中から色々な技術を検討し自社プロダクトに取り込むには1人での開発においては負担になると考えています。
前章でDjangoを使っていると述べましたが、フロントエンド周りも基本的にはDjangoのテンプレートエンジンを使用しております。
今の時代はSPAでReactやVue、Angularを使用したりするかと思いますが、これも前章で述べた技術に欲を出さないことに繋がります。
ちなみにモノリスとは
つまりは、昔ながらのサーバーサイドでテンプレートエンジンを使って画面をレンダリングした結果を返して、それに対してJavaScriptで動きを加えたりするタイプの作りをしたアプリケーション構成です。
このモノリスで開発を進めていくことが、最もスピードを出せて開発や修正スピードを高めることができます。
上記のリンク先にもメリットデメリットが記載されていますが引用します。
メリット・デメリット
Monolithic Application全体としてのメリットとデメリットを記します。
メリット
- シンプルなアーキテクチャと実装ができ、特に初期開発においてスピードが早い
- アプリケーションによっては、技術領域を狭めることで、「ひとり」ないしは数人のエンジニアで開発ができることがある
- アプリケーションが小さければ、事業ドメインが変化した時、再設計の複雑さが減る
- 結合テストやシステムテストがしやすい
デメリット
主にコードが肥大化するほどにデメリットが大きくなります。
重要なページから着手して動くものを早く作る
今回のHiramekiの例で行くと下記の画面作成から実施しました。
この画面はサービスの一番重要な画面です。
この画面から着手することで、すぐに実装した機能をもう１人のメンバーにも触れてもらい使用感やモチベーションの維持などが行えました。
やはり待っている身としては実際に動く画面を早くみたいもので、参照のみのページから作るよりも実際にメインで使う画面から実装を行う方が色々モチベーションが下がらずディスカッションが行えていいなと思いました。
定期的に打ち合わせをする
以前のプロダクトを開発したときは月1で2時間ほどやってました。
このサービスでは週1で30分ほど使ってやってます。
1週間のうちに作ったものを10分ほどで共有して次の週でやることを決める。
モチベーションも維持できて、時間も短いので集中して取り組め、作ったものに対してのフィードバックもすぐもらえるのでとても良かったです。
まずは無料から
やはり会社のサービスとして成り立たせるには有料化を考えたいものであり、リリース前から戦略を考えておきたいところです。
しかし、１人で少ない時間で開発している以上そこらへんを充分に検討している時間がありません。
とりあえずは無料で良いのです。
まだ使われるかどうかもわからないプロダクトに対しての有料化を検討しているのは時間の無駄だと考えています。(今のところ)
機能は最小限に
行きなり大きく考えてしまうと、使われるかわからない機能を無駄に作ってしまうことになります。
なので、2～3個ほどで納めておくと、スピーディーに動くものを作ることができてとても良かったです。
Hiramekiではバグリストを作成して、編集できて、それを共有できる機能だけです。
あとはリーン開発のように仮説～実装～検証のサイクルを回し機能を拡充していこうと考えています。
最後に
一通り学んだことを記載しましたが、これから運用していくなかで更にここで記載した以上の新たな学びが増えていくと思います。
とにかく小さくてもサービスをリリースすることで得られたものは大きいです。
読者様の参考なるかはわかりませんが、誰かの助けになれば幸いです。
