ID:67609さん

# プロジェクト概要 電力・ガスなどのエネルギー使用量を見える化し管理するためのアプリ。 全国展開する支店などでの電気使用量・ガス使用量を手軽に確認できるようにすることで、コスト削減と省エネ意識を根付かせることを目的とする。 また、支店本部にて各支店の電力使用量・ガス使用量を視覚的に一限管理できるようにすることで、全体のエネルギー支出や改善の効果を確認できるようにすること。 # プロジェクト詳細 ・電力会社等のサイトから定期的にクローリング(selenium)で電力情報などを取得し、支店ごとにデータベースへ保存。 ・去年の実績 (時間帯 & 外気温 & エネルギー消費量) とリアルタイムで比較し、閾値をオーバーしているなら警報メールとアラートモーダルを出すことで、省エネ意識をさせる。 ・規模としては2500支店ほどの登録がある。 # チーム情報 PM：1名 開発リーダー：1名 サブリーダー：3名 サーバーサイドエンジニア：8名 インフラエンジニア：1名 計：13名 サブリーダーを担当した。 # 主な業務内容 - 先方要望に対しての機能追加実装 - 既存バグの修正 - 運用、保守対応 (バッチの実行 ) - PRレビュー # 管理画面 CSVダウンロード画面実装 【概要】 管理画面から各店舗のエネルギーデータの予測値をCSVでダウンロードできるようにする機能。 【どのような機能の開発・実装か】 非同期で動作する定期実行バッチの実装と、管理画面 CSVダウンロード画面実装を行った。 【課題・問題点】 仕様は先方と直接MTGにて仕様すり合わせを行う必要がある。 レコード数が数千件以上あるため、ダウンロードボタンを押下してからCSV生成を行う設計だとかなり待たされるため、UI的に不便である 【打ち手・使用した技術】 先方とのMTGまでに予めざっくりとしたUIワイヤーを用意し、イメージとマッチしているか擦り合わせることでスムーズに仕様を固めることができた。また事前に工数見積りを行い、スケジュール感の共有も行えた。 レコード数が数千件以上あるため、予め非同期の定期実行バッチにてCSVを生成・aws s3へ保存を行い、s3へのパスをテーブル保存することで、素早くダウンロードできるようにした。また、テストコードも実装した。DBを介したデータ保存など、関心外のものはモック化し、必要な処理のみをテストするように心掛けた。 # スマホ表示対応 (タブレット・PC用のwebアプリだったので) 【概要】 スマホでもwebアプリが表示崩れなく利用できるようにする (スマホ表示対応) 【課題・問題点】 既存のアプリはかなり昔に実装されていたため、一般的なlaravel/PHP/bladeという構成であり、かつレスポンシブ対応が考慮されていない設計だったため、そのまま実装するとスパゲティコードになる可能性が高い。 また、サーバー2人、フロント2人という編成で実装を行うことになったためタスクスケジュール管理を行う必要がある。 【打ち手・使用した技術】 別ディレクトリを切ってスマホ画面用のルーティングを用意することで既存コードに干渉することないよう設計した。Vue3を採用し、SPAにて動作するよう設計した。 なるべく密にコミュニケーション取れるように1日1回、30分ほどの進捗確認MTGを開催した。API開発以外に、Vue3のコード方針、API仕様書、画面一覧や仕様書作りも受け持ち、初めてのリード的な立ち位置だったが、納期通りスムーズに開発を行うことができた。 また、今回実装したAPIのテストコードも全て実装するようにすることで品質の担保も考慮した。

# プロジェクト概要 ライブ配信 & メルマガ配信で、配信者と読者との交流を行うことができるアプリ。 伝えたい人（クリエイター）から知りたい人（読者・視聴者）への届ける手段の多様化のためメルマガ+ライブ配信で、クリエイターとメルマガ会員に新たな交流手段を提供する。 web / android / iosにてサービスを提供する。 # チーム情報 PM : 1名 iOSエンジニア : 1名 Androidエンジニア : 1名 サーバーサイドエンジニア : 2名 フロントエンドエンジニア : 1名 インフラエンジニア : 1名 デザイン：1名 QA : 2名 計 : 10名 フロントエンドエンジニアを担当した。 # メンテナンス機能 【概要】 リリース時のQAテストや障害発生時に、サービスの利用を停止させるためのメンテナンス機能。 運用管理者が管理画面から任意にメンテナンススケジュール・メンテナンス対象デバイスを設定できる。 【どのような機能の開発・実装か】 メンテナンス設定時はIP制限を掛け、IP許可されてないユーザーはメンテナンス中の旨が記載された画面を表示させる。 担当したのは管理画面からメンテナンスが設定できるページの実装と、メンテナンス期間中にユーザーに表示するページの実装。 【課題・問題点】 「他社からの引き継ぎ案件であること & 初めてAngular / typescript での実装 & 社内にAngularについて相談できるエンジニアがいない」という状況であったため、早急に技術キャッチアップと既存コードの把握が要求された。また、メンテナンス中かどうかは認証APIのレスポンスによって判定する必要があり、サーバー側のAPIが実装されるまでの間何もできない状態が発生してしまう。 【打ち手・使用した技術】 引き継ぎ時のことも考え、Notionにキャッチアップに使用した参考記事をまとめ、また個人で練習用に作成したAngularアプリのGithubリンクを掲載することでドキュメントを残すようにした。 また、APIの繋ぎこみができるようになるまでの間は、docker & express & nodeにてAPIモックサーバーをdockerにて構築することで、繋ぎこみ時はコードを1行変更するだけで完了できるように準備した。 # ギフト機能 (課金機能) 【概要】 配信者がライブ配信中に、視聴者がギフトアニメーションとともに投げ銭できる機能。 【どのような機能の開発・実装か】 ・ギフトポイントチャージ機能 (視聴者) ・ギフト送付機能 (視聴者) ・ポイント管理機能 (配信者) ・ポイント管理機能 (運用管理者) 【課題・問題点】 視聴画面にギフトアニメーションを表示する際、同時に投げ銭が行われた場合の仕様が複雑で、最新情報を整理する必要があった。 また、既存コードのスタイルをかなり修正する必要があり、cssの設計を見直す必要があった。 【打ち手・使用した技術】 同時に投げ銭が行われた場合の仕様はPMから情報が共有されるたびにNotionにまとめ、開発者との認識合わせができるようにした。 ギフトアニメーション表示には、表示状態・イベントを管理できるようngx-lottieを選定した。 また、特定のページのスタイルをITCSS-RSCSSガイドラインに則り実装し直した。 課金機能自体はサーバー側でstripeを用いて実装しており、APIのレスポンス経由でstripeの課金画面へアクセスするようにした。 画面の仕様についてはfigmaにコメントを入れ適宜確認を行うことでUIの齟齬がないよう心がけた。 # 同時視聴者数の表示 【概要】 ライブ配信中に、何名の視聴者がいるかリアルタイム表示する機能 【どのような機能の開発・実装か】 サーバー側でどのユーザーがどの配信にアクセスしたかを管理し、aws dynamo dbに保存。 web socketサーバーを立てて、dynamo dbからリアルタイム視聴者数を取得し、フロント側で表示する実装。 【課題・問題点】 既存コードにはwebsocketサーバーとの接続を行う機能がなかったのでライブラリを選定する必要があった。 また、インフラおよびサーバー側が完了するまで動作が確認できないため、仮繋ぎこみのためのwebsocketモックサーバーを用意する必要があった。 【打ち手・使用した技術】 Angularは基本的にRxjsにてAPIと通信を行うため、実装しやすいようrxjs/webSocketライブラリを選定した。 また、docker & express & node でwebsocketモックサーバーを立てて仮繋ぎこみを行い、インフラ・サーバー側が完了し次第すぐに繋ぎこめるようすることで、スムーズな開発を行うことができた。

# プロジェクト概要 通話機能、資料共有機能や会議の議事録機能など、ビジネスシーンで活躍する機能を実装し、商談・ミーティングをオンライン化させることで移動時間＆コストを削減し、コミュニケーションをより円滑にさせるシステム。 (既存アプリをlaravel/PHPへフルリニューアルする案件) # チーム情報 PM：1名 インフラ：1名 サーバーサイドエンジニア：3名 フロントエンドエンジニア：2名 サーバーサイドエンジニアを担当した。 # リアルタイム通信機能 (新機能追加) 【概要】 ・ログインユーザーのオンライン・オフラインや位置情報などの保持・更新機能。(gatherアプリのようなイメージです) ・ユーザー間のチャット送受信機能 【課題・問題点】 ローカル・デプロイ環境で使用できるsocketサーバーを構築する必要がある。 【打ち手・使用した技術】 ローカルにnode / express / typescript / docker / nginx にてwebsocketサーバーを構築。nginxにてリバースプロキシでHTTPS通信を行うようにした。socket.ioがよく使用されることが多いようだが、より応答性が高いWebSocketのwsライブラリを使用した。インフラチームと協力してCD環境をCircleCIにて用意し、AWSのEC2インスタンス上にwebsocketサーバー環境を構築した。 socket接続のリクエストが来た際に接続情報とuserIdを共に保存しておき、特定のユーザーにsocket通信でメッセージを送信する機能や、自身を除く接続者全てに送信する機能、ステータス更新機能などを実装。wsでは標準でロングポーリング機能がないため、定期的にping/pongで疎通確認も行った。 # Office (word, ptp, excel等)ドキュメントのPDF・JPG変換APIの実装 【概要】 移設元に生PHP (フレームワーク不使用)にてOfficeドキュメントのPDF・JPG変換が実装してあり、それをlaravelへ移設する。画像はフロント側でプレビュー用に用いる。 【課題・問題点】 ・既存コードはPHPのみで実装されており、ソースコードから仕様を読み解いてlaravelへ落とし込む必要がある。既存システム同様の振る舞いを行えるように実装しなければならない。 ・laravelのライブラリでOfficeドキュメントを画像やPDFへ変換するものは提供されていないため、サードパーティのライブラリを使用する必要がある。 【打ち手・使用した技術】 Officeドキュメントを画像に変換する必要があるためlibreofficeをシェルスクリプトで実行してPDF変換後、ImageMagicでjpg変換しS3へ保存するAPIを実装した。 処理の流れとしては「Officeアップロード -> libreofficeでPDF変換 -> ImageMagicでJPG変換 -> S3保存」。 シェルの標準出力・エラー出力をログファイルへ残すようにすることで、運用中に発生したエラー調査にも対応できるようにした。 # 資料のURLからスクリーンショット画像を生成し保存する機能 【概要】 移設元に生PHP (フレームワーク不使用)にてにて同様の実装してあり、それをlaravelへ移設する。 【課題・問題点】 ・ソースコードから仕様を読み解いてlaravelへ落とし込む必要がある。 ・laravelのライブラリでは実現不可能なため、外部ライブラリを使用する必要がある。 【打ち手・使用した技術】 Headless Chromeを導入し、シェルスクリプトを介してコマンドを実行・画像生成・S3へ保存・URLをテーブルへ保存する機能を実装。 # その他 - お知らせ通知機能を実装 (フロント)。チャットルーム新規作成時に招待された人に通知する。Nuxt.jsにて実装。 - PTPファイルダウンロード機能の実装 (サーバー・フロント)。S3に保存してるPTPファイルをダウンロードできる機能。Vue.js (2系) にて実装

# プロジェクト概要 既存のコーポレートサイトのフルリニューアルおよびCMSの開発案件。 問い合わせ流入数を増やすこと・求人データ・企業データ・問い合わせデータをsalesforce上で管理できるシステム構成に改修することが目的。 ユーザーは求人検索・閲覧・求人応募・キャリア相談を行うことができる 管理者はCMSからの記事投稿およびsalesforceから求人情報等を投稿することができる # チーム情報 PM：1名 リードエンジニア：1名 サーバーサイドエンジニア：3名 インフラ：1名 デザイン：1名 リードエンジニアを担当した。 # コード方針 【概要】 基本的なコード方針をNotionにまとめて記載。 【課題・問題点】 初めてのコード方針作成なので、他案件のリードの先輩方の意見を参考に作成する必要がある。 ポテンシャルで入ったエンジニアにも実装しやすくわかりやすいコードにする必要がある。 【打ち手・使用した技術】 ・リポジトリパターン ・PSR-2 ・命名規則について ・Model → Repository →（UseCase・Service）→ Controller → ViewModelの構造で開発 ・発行クエリの確認、実行計画(explain)の確認を指示 ・ログ出力について # テーブル設計 【概要】 salesforceに保存されているデータをlaravelアプリのDBに取り込むためのテーブルを設計 【課題・問題点】 salesforce側のテーブルと照らし合わせ、データ取り込み時に齟齬が起こらないよう考慮する必要がある。 salsesforce側には10万件ほどのデータが存在する。 【打ち手・使用した技術】 ・計15テーブルほどを設計 ・検索性能向上のために正規化を行い中間テーブルも設計 ・想定レコード数を考慮し、index付加も検討。=> カーディナリティを調査し、文字列検索等があったが、付与してもあまり意味をなさないと考えたので、indexの付与は行わなかった。 # PRレビュー 【概要】 入社1ヶ月・4ヶ月の新人のPRのレビュー。 【課題・問題点】 新人エンジニアがコード方針に則って実装できるようにさせる必要がある。 【打ち手・使用した技術】 ・クラス・メソッドの責務や適切な変数名の付け方、ログの入れどころ、デバッグ方法等を指導 ・ figmaデザインをしっかり確認させ、どのような値を返せばフロントが実装しやすくなるかなども指導 ・仕様確認に対しての意識を高めるために、〜は確認したか？などの仕様についての指摘も行なった ・適宜通話にて、ペアプロ的な感じでここはこう書けばよりよくなるなどの指導も行なった ・密にコミュニケーションを取り、困ったらすぐに相談しやすいような環境作りを意識した # 検索機能周りの実装 【概要】 求人情報を検索する機能。業界、職種、募集中かどうかなどの検索パラメータがある。 【課題・問題点】 ・想定データ量が10万件なので、念のため速度面を確認する必要がある。 【打ち手・使用した技術】 仮データを10万件入れておき、検索実行時のクエリの実行計画の確認。keyが意図したものになっているか、サブクエリの発行がされていないかなどを確認した。 # salesforceデータ取り込みバッチの実装 【概要】 salesforce側で提供しているAPIを用いてデータを取得。laravel側のテーブルに、取り込んだデータを定期的に保存するバッチの実装。 【課題・問題点】 想定データ量が10万件なので、なるべくまとめてupsertできるようにする必要がある。 salesforce側で管理者がカラムを追加してしまった場合、laravel側のテーブルと齟齬が発生してしまうため検知して処理を止めるハンドリングを行う必要がある。 【打ち手・使用した技術】 salesforce API 1回で取得できるデータ数は1000件がMAXなので、まずデータの総量を取得しループ回数を算出。重複したデータがテーブルに保存されないようバルクインサートにて保存。 実行前には、salesforce側のカラムとlaravel側のテーブルのカラムの一致確認を行い、一致していなければExceptionを投げて実行できないようハンドリングした。 また、CMSで確認できるよう、wordpress側のテーブルにも同様のデータを保存するようにした。

# プロジェクト概要 飲食店やイベントスペース等の空きスペースを瞬時にコワーキング化できるアプリ。アイドルタイムを収益化できる。今は手動でマッチングの許可を行なっているので、googleカレンダーから情報を取得して自動マッチング許可できるようにすることがゴール。(引き継ぎ案件) # チーム情報 PM：1名 サーバーサイドエンジニア：2名 ネイティブアプリエンジニア：1名 サーバーサイドエンジニアを担当。 # Googleカレンダー連携APIの実装 【概要】 利用者が空きスペースを予約する際、そのスペースの予約状況をGoogleカレンダーから情報を取得して確認・予約できるようにするための連携機能。 【課題・問題点】 OAuth2.0を使用した連携方法での設計・実装を行なっていたが、iOS/Android (React native)のgoogle api用ライブラリの仕様上で問題があり当初の設計では実現不可能であることが発覚した。 Googleカレンダー連携をOath 2.0にて連携するためには、webブラウザを介して認可コードを取得する必要があるが、現状ネイティブアプリのサービスしか展開していないためOath 2.0での連携ができない。 ネイティブアプリのwebビューにて認可コードの取得はgoogleの規定にて禁止されていた。 【打ち手・使用した技術】 空きスペース管理者にこちらで作成したサービスアカウントのidをgoogleカレンダーの連携先に追加してもらうことで、サーバー側でイベントの取得・挿入・更新を行うようにした。 一手間かかってしまうことになるが、この方法でしか実現方法がなかった。 CloudFunctions / TypescriptにてAPIを実装した。連携情報はfirestoreへ保存。 # Googleカレンダー連携解除APIの実装 【概要】 firesotreにて連携済みかどうかのflagを管理しているので、それをfalseにする 【課題・問題点】 ・先々の予定に予約が入っている場合は解除できないようにする必要がある。 ・ユーザーが手動でgoogleカレンダーからidを削除することも考えられる 【打ち手・使用した技術】 最後のイベントの日時を取得して、予約が入っているため削除できないことを伝えるメッセージを返すよう実装。 手動で解除していた場合に、システム側の処理が進まないように既に解除済みであることを伝えるメッセージを出すよう提案・実装。

# プロジェクト概要 歯科医院では現状ローカルのレセコンにて管理しており、6年周期のリース契約で運用している医院が多い。 クラウド型レセコンSaaSサービスにすれば、月額制で解約ができさらに安い。 業界として遅れているため参入する価値がある。また、クラウド型レセコン大手のアプリはUI的にあまり良くないので改善したものを提供すればチャンスがある。 # チーム情報 PM：2名 リードエンジニア：1名 サーバーサイドエンジニア：8名 フロントエンドエンジニア：4名 デザイン：1名 リードエンジニアを担当した。 # 要件定義・必要なドキュメント作成 【概要】 大手のクラウド型レセコンアプリを参考に、以下を作成した。 - 機能一覧 - サイトマップからワイヤーを作成 - 予約 -> 受付 -> 診察 -> 会計の流れの業務フロー図 【課題・問題点】 ・ドメイン知識からキャッチアップしていく必要がある。 【打ち手・使用した技術】 他社レセコンを参考にワイヤー・機能一覧を作成した。運用管理画面のワイヤーは想像で作成。 ワイヤーはレビューをしっかり行い、かつキャッチアップしたドメイン知識はNotionに残すようにした。 機能が不明な点は質問リストにまとめ、後日医療従事者とのMTGで確認できるようにした。 メイン機能のカテゴリとしては、「スケジュール管理、診察管理、問診票管理、スタッフ管理、会計管理」である。 # コード方針作成、環境構築、テーブル設計 【概要】 プロジェクトを新規スタートするにあたり、実装するために必要な環境を準備する。 【課題・問題点】 ・コード方針は新人でも実装しやすいようにする必要がある。 ・テーブル設計は、drawioで作る場合だとメンテナンス・管理が面倒になってくる ・APIドキュメントを用意できるようにする必要がある 【打ち手・使用した技術】 - 環境構築 dockerで作成。APIドキュメント作成用にprismサーバーを立ててswagger-uiを用意した。 また、S3へのファイル保存もあるためminioも使用。ER図を自動生成するためにschemaspyコンテナも用意した。また、CI環境をCircleCIで用意し、自動テストを行うようにした。また、pintを導入しコードフォーマットも自動化した。 - コード方針 社内でよく使われているパターンにした。以前経験した案件のものを採用 また、resourcesクラスを用いたModel → Repository →（UseCase・Service）→ Controller → Resourcesの構造で開発を取り入れた - テーブル設計 ドメイン知識が足りていない状態だったので、他社アプリの情報や調べた知識からテーブルを想像・設計した。どういう意図でテーブル・カラムを追加したかなどのコメントも残すようにした。 # APIドキュメント作成 【概要】 APIを開発するにあたり、リクエスト・レスポンスの定義書を用意。 アサインされたエンジニアへ開発タスクを依頼しやすくする。 【課題・問題点】 ・ステータスコードを決める必要がある ・フロントエンド開発者が困らないよう、レスポンスの基本型を決めておく必要がある 【打ち手・使用した技術】 laravel-openapiだとAPIスキーマを定義するタイミングが実装フェーズになるデメリットがあるのでstoplight studioを用いてOpenAPIを記述した。 ステータスコードの詳細や、レスポンスの基本型はNotionに記載した。 # その他 - PRレビュー、新人教育 - タスク指示出し