44
58

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

初めてRailsでWebサービスを作る前に最低限やっておきたい12のこと

Last updated at Posted at 2018-12-13

プログラミング学び始めて、ある程度学び終わって、いざサービスを作ろうって思ったときに、「え、何からしていいの。」ってなりますよね、その気持ちすごくわかります。以前インターンの研修で一からサービスを作ったことがありましたが、当時の僕は右も左もわからなくて、がむしゃらに頑張っていた記憶があります。そこで初心者が初めてrailsでサービスを作りたいときに最低限やっておきたい12のことのメモを残しておこうと思い、記事を書くことにしました。

対象者

  • オンラインサービス等でrailsについて学習したことはあるけれども、実際に自分でサービスを作ったことがない人。
  • 「インターネットサービスってどうやって作るの??ねえ???」って人。

なお、今回にはRailsで開発することを念頭に置いて記事を書いています。
スクリーンショット 2018-12-11 23.09.46.png

設計に関して

まずは諸々、開発に入る前に考えることがあります。

1.サービスの定義

まず最初にしないといけないことは「自分がどのようなサービスを作るのか」を明確にすることです。曖昧なままにサービス作成を開始すると、「あれ、いま自分何作ってるんだっけ。。」と迷子になってしまいますし、チーム開発の場合だと共通認識が取れていないことによって、色々と面倒なことになります。最初に物事を定義しておくことは、思っている以上に重要です。サービスを定義するための方法をいくつか紹介します。

リーンキャンパスを使う

マネタイズとかもしっかりと考えたい人にはリーンキャンパスをお勧めしておきます。この表は便利なもので、順番に枠を記入していけば、ある程度サービスの骨子ができてしまいます。最強すぎる。。
スクリーンショット 2018-12-14 7.45.24.png
参考情報: https://www.slideshare.net/studytech/ss-23454300

2W1H

「リーンキャンパス??意味わからん知らねーよ!」って人はとりあえず2W1Hくらいは考えておきましょう。自分たちが何を(
=what)、誰に対して(=who)、どのように提供するのか(=how)について考えるだけでも、自分、もしくは自分たちの中でのサービスの解像度が上がり、開発がしやすくなると思います。

2.要件の定義

要件定義とは、様々な理想を現実問題に落とし込むことだと思います。
スクリーンショット 2018-12-16 11.56.59.png

理想ブレスト

「その時の感情をシェアできるサービスを作りたい!ユーザーがつぶやきを投稿して〜それに対してだれかがコメントできて〜お気に入りもできて〜それからライブ配信もできて〜」みたいなことをブレストしましょう。この段階で大事なことは、どんなにバカな意見でもとりあえず採用しちゃうことです。とりあえずアイデアをいっぱい出すことが大事ですね。

現実落とし込み

ブレストした中から、実際に要件を定義していきます。一旦最初は必要最小限の機能だけ選定するのがいいと思います。例えば上記の「その時の感情をシェアできるサービスを作りたい!ユーザーがつぶやきを投稿して〜それに対してだれかがコメントできて〜お気に入りもできて〜それからライブ配信もできて〜」とかを現実の機能に落とし込むと

  • ユーザー側
    • サインイン/ログイン機能
    • 投稿機能
    • コメント機能
    • お気に入り機能
  • アドミン側(管理者のこと)
    • ユーザー管理機能
    • 投稿管理機能
      とかになるでしょうか。ライブ配信機能に関しては、サービスに絶対に必要な機能ではないかつ相対的に実現難易度が高そうなので、初期開発からは外しました。余裕があれば後でやればいいと思います。「後からやるリスト」でも作って、そこに入れておきましょう。

3.画面設計

次に画面設計をしましょう。「topページのメイン画面にはこの写真が来て、このボタンを押したらあのページへ遷移して…」みたいなことを全部決めます。要件定義をもとに、自分たちのサービスに必要な画面を全部洗い出しましょう。この時点でモックアップと呼ばれるものを作成することをお勧めします。例えば、有名どころでいうとFigmaやCacooなどを使って、実際のサイトの画面を全部作り上げてしまいましょう。上記サービスを使えばパワポを作る時みたいな感じで、サイトのレイアウトを作成できます。サイトの全体像を図から把握することによって、自分たちのイメージが膨らみます。

スクリーンショット 2018-12-14 7.57.51.png

参考1: https://www.figma.com/
参考2: https://cacoo.com/ja/

4.DB設計

自分のサービスを作るにあたって、どんなデータが必要になるかを考えます。例えば、「ユーザーが文章を投稿をする」ようなサービスを作りたい場合、ユーザーのデータと投稿のデータが必要になります。さらに、ユーザーのデータと言っても、そのデータが何を持つのかについて考えなければいけません。名前を持つだけでいいのか、それともemailアドレスのデータを持った方がいいのか等々。このような感じで、サービスに必要となるデータテーブル(ユーザデータ)とその中身(名前とemailアドレス)について、考えるのがDB設計です。以下のようなER図と呼ばれるものを用いて、データが何を持つのかやら、データ同士の関連やらを確認することが多いです。

スクリーンショット 2018-12-14 8.06.41.png

参考: https://it-koala.com/entity-relationship-diagram-1897

5.URL設計

事前に行った画面遷移やDB設計を参考にして、URLの設計を行います。どのURLを叩けば、どのページに遷移するのかを決めます。その際にHttpメソッドは何にするか(get,post,patch,delete)、どんなパラメータ(/post/1の1の部分)を渡すかまで決めると良いかと思います。

スクリーンショット 2018-12-14 8.12.34.png

6.コントローラー設計

必要となるコントローラーとそのアクションをある程度洗い出してしまいましょう。上記過程を踏んで入れば、比較的簡単にコントローラーについては想像ができると思います。コントローラーについて決めることができたら、あらかじめ「rails g controller ControllerName」のコマンドを打っておきましょう。この作業はチーム開発をする際などには特に有効で、最初にコントローラーみんなで考えて、それら全てが作成されたプロジェクトをgithubに上げておいて、それをメンバーがpullすることによって、開発者全員での意識の統一が取れますし、コンフリクトも減らすことができます。

7.モデル設計

必要となるモデルを洗い出しましょう。すでにDB設計が終わっているのでそこまで大変な作業ではないかと思います。コントローラと同じように、全モデルで揃ったら最初に「rails g model ModelName」を打ってしまいましょう。

8.gem設計

最初の段階でどんなgemが必要になるか一定の議論をしておいて、サービス実装前にGemfileに記入してしまいましょう。その方が上記コントローラー設計の場所で触れたことと同じ理由で楽です。

実装に関して

ようやくここから実装に入っていきます。

9.タスクを明らかにする

まずはタスクを切りましょう。初期開発であれば、そこまで粒度間細かくタスクを切る必要もない気がするので「ユーザー登録機能」「ユーザーログイン機能」とかの粒度で切り分けるでいいと思います。要件定義を全て満たすような形で、サイトを作るために必要なタスクを全部ここで切り出します。

10.タスクの優先順位付け

出揃ったタスクに優先順位をつけましょう。ユーザーのサイト内での体験を考えると、「この機能がないとこの機能は作れない」という順番が決まると思うので、その順番で開発していけばいいと思います。

11.担当者を振り分ける

優先順位のついた全タスクが出揃ったら、それらを担当者に振り分けます。自分が実装したいと思った機能は積極的にタスクをもらいに行きましょう!一人開発の場合は全部自分でやることになりますが。。

12.一週間の計画を立てよう!

開発を実際に始める前に、一週間で何を終わらせるかを考えます。そして一週間後に振り返りのミーティングを設けて、進捗を確認します。このサイクルを繰り返して開発を回していくと効果的です。適当に開発をするよりかはやることをしっかりと決めて、振り返りの機会をしっかりと設けるようにした方が、作業もテキパキするようになりますし、チーム全体の課題も顕在化しやすくなります。振り返りで確認、議論することはひとまず以下の項目でいいと思います。

  • 先週の進捗
  • 次のサイクルで取り組む業務
  • 良かったこと
  • ダメだったこと
  • ダメだったところを治すためにすること
    しっかりとPDCAを回して開発に取り組んでいけば、得られる経験はさらに濃いものになります。

参考: https://boxil.jp/mag/a3641/

実装開始!

夜なべしてコードを書きましょう。Write code.
s_david-rangel-708765-unsplash.jpg

めんどくさくなったらとりあえず書き始めよう

最後に何言ってんだこいつってなると思いますが、上記プロセスがめんどくさくなったらとりあえず書き始めて、ある程度のものを作ってしまいましょう!考え続けてアウトプットを出さないことに価値はないので、とりあえず何か作ってみることが大事かと思います!

44
58
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
44
58

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?