ID:65533さん

# システム概要 全国のBARの検索、閲覧。 # 開発規模（チーム人数 / プロジェクト人数） 2 / 15 # 機能 ### ユーザ - 店舗検索（店舗名, エリア, カテゴリーなど） - マップ検索（Googleマップ） - 店舗詳細閲覧 ### オーナー - オーナー登録 - 保有店舗登録 - 店舗情報編集・削除 ### 運営 - オーナー登録・削除承認 - 店舗登録・削除承認 - オーナー・店舗情報管理 - 運営ユーザ登録・編集・削除 - クーポン作成 # 課題 ### ユーザ - 店舗検索時の表示に時間がかかる ### オーナー - 登録から反映までのフローが時間がかかる →運営承認以降でないと掲載されない ### 運営 - オーナーが登録情報登録が不慣れなため、情報不足となる - クーポン・イベントを実施することでPVを増やしたい # 担当業務 ### ユーザ画面 - マップ検索の際の自動再検索 座標情報からDBへ問い合わせを行い再表示。 - 店舗絞り込み検索 絞り込む際に検索結果なしを避けるために検索後店舗情報から不要な選択項目を表示しないようにする。 例）全カテゴリーが12項目で検索後店舗一覧のカテゴリーが6項目の場合、ドロップダウン内に6項目だけ表示。 - API 店舗一覧情報取得。 SQLですべきこととPHPですることを切り分ける。 店舗情報が多いためSQLでは最低限の加工をして、PHPでフロント側で必要なデータ構造に形成する。 ### オーナー画面 - 登録フロー メール登録→仮パスワード発行→パスワード設定→オーナー情報登録→店舗登録 - 店舗情報登録達成度表示 店舗情報の項目で未登録項目をパーセントで可視化する。 - 登録項目の追加 追加要望の項目を追加。 ### 運営管理画面 - 運営側で管理する項目追加 オーナー情報、店舗情報の編集・削除。 - クーポン作成 オーナー側でカスタマイズ出来る用のテンプレート作成。 運営側のイベントクーポンの作成。 # 成果 ### ユーザ - SQL改善により店舗検索時の表示が早くなった ### オーナー - 登録フロー改善により、承認を事後承認とすることで一旦は掲載可能 ### 運営 - サイト活用の苦手な方の代わりに運営側が代理で行うことで店舗情報の登録が可能となり、ユーザ・オーナー双方にメリットがある - クーポン・イベントがあることでPV向上に繋がる ### 経験できたこと 店舗情報が多いので、一覧で取得する際のレスポンスが遅くならないようにSQLの最適化を行うこと。 explainを用いて適切なindexの追加、複雑な処理をSQLに任せていないかなど考えれるようになりました。 運営側営業の方やオーナー様からのフィードバックに対して随時対応する中でUI・UXを意識できるようになりました。 この機能を使用中にこの表示は必要か？や文言は正しいか？など。 # 対象サービス https://andbar.net/

# システム概要 コロナ対策も考慮して駅の混雑状況を可視化してユーザに提供する。 # 開発規模（チーム人数 / プロジェクト人数） 2 / 4 # 機能 ### ユーザ - 駅一覧 - 各駅混雑状況表示（アイコン, 文言） - 駅詳細 - 対象日付選択 - 対象駅選択 - グラフ - 折れ線グラフ：現在混雑状況 - 棒グラフ：過去実績状況 - 横線：閾値（混雑, 警告） - 時間単位ごとに表示切り替え - 10分, 30分, 60分 # システム構成 S3内にデータフォルダ（jsonファイル）とHTMLファイルを配置。 データ取得は、JavaScriptでjsonファイルを取得してデータ形成。 データ構造は5分単位と10分単位で作成されている。 →データ自体は本タスクと切り分けられているためブラックボックス。 # 課題 - 現在の状況がシンプルに可視化出来ていない # 担当業務 - 混雑状況表示 混雑状況に応じて3パターンの表示を行う - 混雑しています - やや混雑しています - 空いています - グラフ作成 グラフ全般。 過去実績表示は混雑状況に応じて色わけを行う。 時間単位（10分, 30分, 60分）ごとの表示切り替えの際に、データ取得して選択された条件でデータ形成。 - ドキュメント作成 このプロジェクトは初めから担当させて頂いたので、全体像や詳細などをドキュメントに整理。 # 成果 - 混雑状況を文言で表示することで分かりやすくする - 棒グラフの色を変えることで分かりやすくする ### 経験できたこと データ形成のロジックや対象日付に応じた表示切り替えなどでDate関数を使うなどで日付、日時を扱う経験が出来ました。 シンプルなシステム構成でもサービスとして成り立つと知れて、サービスの複雑性などに応じてシステム構成は考えることが大事だと分かりました。 ドキュメント作成の際に他のメンバーが参加する時の参入障壁がないように作成しました。誰がみてもわかる内容、認識齟齬が起こらないことを意識しました。 →データ構成、画面構成、用語説明など ### 対象サービス https://traffic.adinte.jp/linimo/index.html

# システム概要 不動産立ち合い仲介担当の方が、請求書、見積書、発注書を作成・管理する。 退去者との交渉、物件修復業務を代理で行う。 # 業務フロー 物件契約者が退去→退去立ち合い→見積書・請求書作成→退去合意→物件修復のため各業者へ発注書作成 # 開発規模（チーム人数 / プロジェクト人数） 2 / 2 # 課題 - 今まで書類を手打ちのEXCELで管理している - 対象物件の修復箇所を各自担当者の個人端末で管理している - 過去の業務の閲覧が困難 # 機能 ### ユーザ - 担当者登録・編集・削除 - 契約業者登録・編集・削除 - 物件登録・編集・削除 - 見積書作成・編集・削除 - 発注書作成・編集・削除 - 請求書作成・編集・削除 # 担当業務 - 担当者登録・編集・削除 - 契約業者登録・編集・削除 - 物件登録・編集・削除 - 見積書作成・編集・削除 - 発注書作成・編集・削除 - 請求書作成・編集・削除 - 見積書レイアウト作成 - 発注書レイアウト作成 - 請求書レイアウト作成 # 成果 - 業務をアプリ内で行うことで手打ち作業しなくて良くなった - 画像登録をクラウド上で行えるので登録業務の改善 - いつでも過去業務の閲覧できる ### 経験できたこと 初めての受託開発で初めから携われた案件です。プロジェクトマネージャーが要件定義、設計までしたものを私が実装するという流れでした。そのおかげでコードをたくさん書けました。 業務アプリなので機能は単純かつ似たような構成でしたが、共通化すべきところと差異があるところを整理することで開発の効率化を学べました。 DBの構成にも挑戦させてもらいたくさんのレビューをしてもらえたことで、正規化やデータ連携のイメージをもてるようになりました。 帳票作成に使用したJasperReportへのデータ連携に慣れるのに時間がかかりましたが、外部ツールとの連携の構造を学べました。 # 対象サービス toB向けのアプリのため掲載不可