はじめに

未経験でディープロ(旧：DIVE INTO CODE)に入校し、4ヶ月の受講の集大成としてオリジナルアプリケーションを作成しました。
名前は「デリレコ」と言います。
前職（お惣菜の商品開発）の経験を元にした、お惣菜の商談記録が管理できるアプリケーションです。

アプリケーション：https://protected-coast-48892.herokuapp.com
GitHub：https://github.com/MayuKishimoto/deli_reco.git

なぜ「デリレコ」を作ったのか

結論：商品の商談記録を管理するのが大変だったから！

前職の時にはこんな悩みがありました。

1. 商品数が多い問題
一事業所で、月に100アイテム以上の開発案件がありました。

2. 過去の商談記録を探すのが大変問題
商談情報は、商談日ごとに以下のようなエクセルファイルで作られていました。
過去の商談記録は、このファイルを一つずつ開いて探さなければいけませんでした。

3. 営業からのフィードバック手段がバラバラ問題
商談のフィードバックが、メール、チャット、電話などバラバラだったため、重要な情報を見逃してしまうリスクがありました。

以上のことから、「商品ごとに商談記録が管理できるツールがあれば…！」と思い、「デリレコ」を作成しました。

「デリレコ」の使い方

流れは以下の通りです。

ログイン
商品の新規開発依頼をする（営業）
開発依頼を承認する（管理者）
商談情報を登録する（開発）
商談結果を登録する（営業）
4,5のやり取りを繰り返す
商品情報を確定する（営業）

1. ログイン

部署や権限により、表示される項目が異なります。

営業：商品の開発依頼、商談結果の登録ができます。
開発：商談情報の登録ができます。
管理者：商品の開発依頼の承認ができます。

2. 商品の新規開発依頼をする（営業）

「営業用ゲストログイン」よりログインします。

「新規開発依頼ボタン」より、商品の開発依頼をします。

開発依頼が登録されると、管理者権限を持つユーザーに通知メールが送られます。

3. 開発依頼を承認する（管理者）

次は「管理者用ゲストログイン」にてログインします。
営業から送られてきた開発依頼の中身を確認します。

依頼内容に問題がない場合は、画面下部の「開発担当者」よりこの商品を担当する開発のメンバーを選択し「申請状況」を「承認」に変更します。
「更新」ボタンを押すと、アサインされた開発メンバーに通知メールが送られます。
また、商品情報は「開発依頼一覧」から「商品情報一覧」に移動します。

依頼内容に問題がある場合は、「申請状況」を「差戻」に変更し、差戻理由を記載して更新すると、依頼元の営業に通知メールが送られます。

4. 商談情報を登録する（開発）

「開発用ゲストログイン」にてログインします。
たくさんの商品情報から自分の担当商品を検索することができます。

商品の「詳細」画面を開くと、先ほどの営業からの依頼が上部に記載されています。

「商談情報登録」フォームより、次回の商談に必要な情報を登録します。

登録した情報がフォームの右側に表示され、営業に商談情報が登録された通知メールが送られます。
この情報を元に、営業は商談をします。

5. 商談結果を登録する（営業）

商談が終わったら、営業は商談結果を入力します。
登録したら、開発に商談結果が登録された通知メールが送られます。

6. 4,5のやり取りを繰り返す

【開発】前回の商談結果を元に修正した内容を入力。

【営業】商談結果を入力。

7. 商品情報を確定する（営業）

商品の情報が確定したら、画面上部の「ステータス」部分より「確定」を選択します。

商品情報が確定になると、商品情報の入力フォームなどが非表示になります。

結論：「デリレコ」を使うと…

1. 商品数が多い問題
→ 検索機能でサクッと検索！

2. 過去の商談記録を探すのが大変問題
→ 商品の中に商談情報が蓄積されているので、過去の記録が一目瞭然！

3. 営業からのフィードバック手段がバラバラ問題
→ やり取りのフローが一元化されている＆メール通知機能で情報を取りこぼさない！

「デリレコ」の作成について

かかった日数

工程	日数
要件定義	12日
バックエンド	10日
フロントエンド	5日
テスト	3日
デプロイ	3日
合計	33日

こだわった && 大変だったポイント

1. 商品情報の中に商談記録を表示させたこと

商品情報の中に商談情報を蓄積するために、ルーティングのネストを三層構造にしました。

config/routes.rb

resources :products do
  resources :negotiations do
    resources :results
  end
end

ER図

商談情報と商談結果の登録フォームを作るのに、コントローラのどこでNegotiationとResultのインスタンスを生成すれば良いのかに苦戦しました。

また、各フォームがパーシャルで入れ子になっていたので、取得した値を渡すための変数の設定が大変でした。都度変数の中身を確認しながら実装することで、商品情報→商談情報→商談結果の表現をすることができました。

「商品情報の中に商談情報を蓄積する機能」はこのアプリケーションの肝だったので、実現することができてよかったです。MVC構造の再確認にもなり、とても勉強になりました。

2. 商品のステータスによって表示させる一覧を分けたこと

商品のステータスの状態により表示させるページや内容を変えたかったので、namespaceでURL、コントローラ、ビューを分けました。

app/models/product.rb

enum status: { 申請: 1, 承認: 2, 差戻: 3 }

config/routes.rb

namespace :request do
  resources :products
end

resources :products

未承認(ステータス：申請 or 差戻)の商品のルーティング

Prefix	Verb	URI Pattern	Controller#Action
request_products	GET	/request/products(.:format)	request/products#index
request_products	POST	/request/products(.:format)	request/products#create
new_request_product	GET	/request/products/new(.:format)	request/products#new
edit_request_product	GET	/request/products/:id/edit(.:format)	request/products#edit
request_product	GET	/request/products/:id(.:format)	request/products#show
request_product	PATCH	/request/products/:id(.:format)	request/products#update
request_product	PUT	/request/products/:id(.:format)	request/products#update
request_product	DELETE	/request/products/:id(.:format)	request/products#destroy

承認済み(ステータス：承認)の商品のルーティング

Prefix	Verb	URI Pattern	Controller#Action
products	GET	/products(.:format)	products#index
products	POST	/products(.:format)	products#create
new_product	GET	/products/new(.:format)	products#new
edit_product	GET	/products/:id/edit(.:format)	products#edit
product	GET	/products/:id(.:format)	products#show
product	PATCH	/products/:id(.:format)	products#update
product	PUT	/products/:id(.:format)	products#update
product	DELETE	/products/:id(.:format)	products#destroy

コントローラでのアクションの書き分けが難しかったです。
また、未承認の商品のlink_toやform_withのパスの指定に苦労しました。

おわりに

要件定義からデプロイまで自分の手で一通りアプリケーションを作ってみて、今までスクールで学んできた点と点がこう繋がるのか！という発見がたくさんありました。
全てを自分でやっているからこそ直面する問題もあり、とても良い経験になりました。

引き続き学習を続けてスキルアップしていきたいと思っております。
最後までお読みいただきありがとうございました！