少し前の記事(「プログラミング未経験者がWEBエンジニアになるためにやるべきこと」)の元になったプログラミング初心者の二人が、それぞれ無事Railsのチュートリアルまで終わらせていざ自分のサービスを作りたい！ってなった時に、さて何から手をつけたらいいんやろう？という同じ悩みにぶつかって同じようなアドバイスをしてたので、またその内容をまとめてみました。

初心者に限らず、小規模WEBアプリを作る時にこういうことをしとくといいかなっていう個人的な手法みたいなのをざっくり書いていきます。

SPONSERD LINK

前提

一般的なシステム開発は下記のフローで進んでいきます。

  1. 要件定義
  2. 設計
  3. 開発
  4. テスト
  5. リリース

ウォーターフォールはこれを1回流して完成、アジャイルはこれを小さく切ってぐるぐる回すというイメージですが、「初めての個人アプリを最初にリリースするまで」という状況では、一番困るのは2の設計の部分だと思います。

要件定義はサービスのネタを考えて「こういうの作ろう！」ってなった時点である程度できてると思います。（「誰の」「どんな問題を」「どうやって解決するか」が決まってればとりあえずOKです）

チュートリアルに沿ってコードを書いていくのと、何もないところから書くべきコードをイメージしていくのには結構な隔たりがあると思うので、そこの部分を埋めるために設計すべきことみたいなのを書いていきます。

1. ワイヤーフレームを描く

いつも最初におすすめしてるのは、作りたいサービスのワイヤーフレームを描いてみることです。

手描きのめっちゃラフなやつでいいので、トップページには何があって、どのリンクを押すとどんなページに移って、そこには何があってみたいな、サービスのイメージ図を描いてしまいます。

「こういうサービスを作ろう」というぼんやりのイメージがあっても、いざワイヤーを描いてみると、「あれ、よく考えたらこういう画面必要やな」とか「ここでこれを出すためには事前にこれやっとかんとあかんよな」みたいな穴がどんどん見つかります。

このワイヤーの時点で「これならサービスとして成立しそう」という画面の一覧を描いてしまえると、開発を進めるにつれてどんどん不整合が見つかって何回も作りなおすみたいなリスクが減らせます。（最初にそういうのを経験しとくのも悪くないかもしれませんが・・・）

2. 各ページのURLを決める

ワイヤーフレームが描けたら、次はそれぞれのページにどんなURLでアクセスするかを決めます。

ドメインはあとでもいいので、「トップページは”/”」「ログインは”/users/sign_in”」みたいなサイト内パスで大丈夫です。

強いこだわりがない限りは、チュートリアルとか他の有名サービスとかを見ながら似たようなURLをつけておくのが無難です。

実際に開発を進めていくにあたってこのURLはどこかで決めないといけないのですが、RailsやCakePHPなどのフレームワークは「こういうURLにした方が作りやすい」とか「このURLやと色々ごにょごにょする必要がある」みたいなのがあって悩ましいところもいっぱい出てくると思うので、不安な場合はわかる人に相談しながら決めた方がいいです。

「こういう場合はこういうURLにすると美しい」みたいな議論も色んなパターンで色んな発想があるんですが、興味あったらぐぐってみてください。「rails url 設計」とか。

（あんまりURL設計について体系的にまとまってる記事は見当たらなかったのでいいのがあったら教えてほしいです）

3. DB設計を決める

WEBサービスを作る場合、かなりの確率でデータベースを利用すると思います。そこでどんなデータをどんなテーブルにどうやって格納するかというのを決める必要があります。

これも手書きでもメモ帳でもGoogleのスプレッドシートでも何でもいいので、テーブル名、カラム名と型（文字列なのか数字なのかとか）をまとめます。

  • テーブル名
    • カラム名:型

の形式で書いておくと、後で作る時に楽です。

例えばこんな感じ

  • users
    • id:integer
    • name:string
    • birthday:datetime
  • posts
    • id:integer
    • user_id:integer
    • title:string
    • body:text

4. もっかいワイヤーを見直す

ここまでできたら最初に作ったワイヤーフレームを見直してみます。

ワイヤーに出てくる要素全て、2のURLと3で作ったDBのカラムだけで表現できるかというのが主なチェックポイントになります。

「この部分はこのテーブルからこういうSQL叩けば取れるな」っていうところまでイメージできないと、作りながらどこかしら（主にワイヤーかDB設計のどちらかを）見直す必要が出てきます。

5. タスクを切り出す

ワイヤー・URL・DB設計の3点セットが揃ったらいよいよ開発に入るんですが、その前にやるべきことをリストアップしておくとスムーズに開発を進めることができます。

「トップページ作成」「ログイン機能作成」など、ざっくりした機能単位で切っていけばいいと思います。最初はページ単位になることが多いです。

タスク管理ツールは色々ありますが、PivotalTrackerやTrelloあたりが使いやすくておすすめです。とりあえずページ単位でタスクを作って、開発を進める中で「これもやっときたいけどちょっと後にしよっかな」みたいなのはどんどんチケットとして追加していきます。

まとめ

以上5つのステップをクリアしたら、あとはひたすら作るだけです。

Railsで作るなら rails new でまっさらなプロジェクトを作って、 git init して最初の状態をコミットしてしまいましょう。

リポジトリはとりあえずBitbucketなら無料でプライベートリポジトリが使えるのでpushしてしまいましょう。

git環境が整ったら5で作ったタスクを上から作っていきましょう。

この1〜5の流れは、個人でも仕事でも、小規模でも大規模でも、新規開発でも機能追加でも基本は変わりません。コミュニケーションする相手や人数、プロジェクトの規模によってちょっとずつ必要なクオリティが違ったり使うツールが変わったりするぐらいです。

設計のゴールは、「この辺にこういうコードを書いたら実現できそうやな」というイメージをして、「あとはイメージをコードに落とすだけの状態」にすることだと思ってます。

なのでスラスラとコードが書けるなら手書きのラフすら飛ばしてしまってもいいですし、逆に自分以外がコードを書くなら自分のイメージが他人に伝わるように話したりドキュメントに書き出したりする必要があります。

あと可能であれば、1〜5それぞれのステップで先輩エンジニアにレビューしてもらうとより確実です。特に4の段階で、ワイヤー・URL・DB設計の3点セットを見てもらって、そこがOKなら少なくとも設計としては十分だと思います。

ということで、少しでも参考になれば幸いです。