木田さんが入江開発室の #ひとりごと に投じた一石。

やっぱり、サービスを早くリリースすることはすごく大切だけど、設計を適当にして動けば良いみたいなアプリケーションを作るのは良くないな。
あと、設計やテストを犠牲にすると実装が速くなるかというとそうでもない

このコメントを皮切りに、開発着手前にチームで決めておくべきことは何か？最初に作っておくべきドキュメント、設計書は何か？という議論が熱く交わされました🔥

プライベートでの開発だと早く世の中にサービスを出したい想いが先行するあまり、動くプロダクトが優先され、システム設計がおざなりになりがち。

（先日リリースしたnyanも設計の考慮不足により一部ユーザーが猫の世界から現実に戻ってこれなくなってしまったので、自戒も込めて）本記事では私がこの議論で学んだことをまとめます😸

※ こちらはあくまで私の見解、まとめです。
※「もっとこうしたほうがいいよ！」などあればコメント求む。

そもそも、何のために設計書を書くのか？

オンラインサロンの特性も加味し、私は３つの目的があると思いました。

✅設計変更のコストが低くなる、結果、品質も良くなる
✅開発スピードが上がる
✅新しいメンバーが途中からでもjoinしやすい

✅設計変更のコストが低くなる、結果、品質も良くなる

プロダクトを作り始めてから設計を見直した場合、最悪だと一から作り直す羽目になってしまいます。

そうではなく、机上でシステム設計をチームで意識合わせすることで開発の手戻りをなくすことが出来ます👍

仮にチームにシステムアーキテクトがいないケースでも、入江開発室にはエンジニア力の高いメンバーも多いので、その人たちからレビューをもらえばOK。プロダクトを作り始める前であれば、システム構成の変更なんて容易に済みます。

✅開発スピードが上がる

設計書があればあとは作るのみです。チーム全員の意識も合っているため設計に悩むこともありません。仮にシステム設計を全くせず見知らぬ人と１つのプロダクトを作るとなってもそりゃ無理ですよね。

✅新しいメンバーが途中からでもjoinしやすい

入江開発室には日々メンバーが加入し、開発中のプロジェクトに途中で参画することが多々あります。その際、設計書は仕様理解の手助けとなり、スムーズに開発に加わることができます🤝

設計書は人の為。

オンラインサロンではそういうボランティア精神も大事だなぁと思います。

具体的に何を作るのか

あらゆる種類の設計書を漏れ無くかけばいいのかというとそうではありません。私たちの目的はあくまでサービスリリース。ドキュメントの執筆ありません。チームで話し合い必要最低限のドキュメントを作るのです。

これは正解がないので、議論の中に出てきたドキュメントのうちどのプロジェクトでも必須だろうなぁと思うものをあげておきます⬇️

✍️システム概要図
✍️画面遷移図（どんな画面があるのか、どう遷移するのか？）
✍️機能一覧（どんな機能を作るのか？）
✍️ER図（どのようなデータ構造か？）

それぞれのドキュメントの書き方は各自ネットでググっていただければ。

なお、入江開発室では以下のようなフローで開発が進むことが多いのですが、ドキュメントを作成するタイミングは「3.画面・仕様設計」ですかね

＜入江開発室での開発の進め方例＞
1. 内容の企画
2. スキルマップ作成
3. 画面・仕様設計
4. githubリポジトリ用意
5. 最初のPJをリードエンジニアがプッシュ（Laravel、Railsなど）
6. Dockerなどで環境構築
7. ER図作成
8. 開発
9. ドメイン取得・サーバー設定

とはいえ、作ってみないと分からないこともある

「開発前に設計書を書こう」という話をしてきましたが、とはいえいざ作ってみたら上手くいかないってこともあると思います。

また、開発期間が短いことに越したことはない。設計をじっくりしてたら誰かが似たようなサービスを世に出しちゃったでは悲しいですよね😹

そのトレードオフの勘所は難しそうですが、たくさんプロダクト作ってみて経験を積んでいけばいいかなぁと思っております。

最後に

nyanはとてもスピード感を持って開発できたことは素晴らしかったです。が設計工程は少し階段飛ばしになってしまいました。今は休憩期間、リファクタリングがてら改めて設計書描いてみようかなと思います🐈

nyanを開発、リリースしてなかったら今回の議論にこれほど自分ごとになれていませんでした。プロダクトを作ってみて学ぶことは多い。

だからみんな、とりあえず今日も手を動かそう。