ID:34211さん

・機械工場内の業務システム運用・保守。 ・システムの概要は、 機械製造の計画書作成=>上長らによる計画書承認=>機械製造実施=>計画者が結果を報告=>上長が内容を承認 ・計画書には製造な必要な部品や時間、場所などの情報を登録する。 ・当業務システムでは機械やその運搬用の船舶を紐づけて管理する。 【プロジェクトにおける成果】 ①Git導入 ・参画当初、Gitによるソースコード管理が行われていなかった。そのためにリリースに大幅に時間を要していたり、以前のバージョンに戻すことができないなどの問題があった。そこでPMに働きかけ、プロジェクトにGitを導入する作業を行った。その結果、作業効率が向上した。 ②パッケージ管理ツールの導入 ・参画当初、パッケージ管理ツールも運用されていなかった。このため、ライブラリが更新されたりした際には再びインストーラからダウンロードするなどといった作業が行われており、かなり時間効率が低かった。 そこで、PHPのパッケージ管理ツールであるComposerを導入するようチーム内で提案し、実際にプロジェクトに導入することができた。 ③機械の検索機能改修 参画当初、検索機能が以下のような理由で使いにくかった。 A)メインのデータに紐付く情報（機械に使われている部品や、積まれている船の情報など）による検索、表示ができない B)メインのデータに紐付く情報の詳細ページへの遷移がしにくい そこで、プロジェクト管理者から上記の問題を踏まえより使いやすくして欲しいという依頼を受け、 機械に紐づく情報を検索条件、取得項目に追加する作業を行なった。 それまで、バックエンド側の検索処理を実装した事が無かったためSQL文の記述が難しく感じたが、 テーブルの主キーや複合キーについて学習した上で 内部結合や外部結合を用いて紐づく情報を取得する処理を書くことができた。 この作業がきっかけで、SELECT、WHERE句、JOIN句等を理解する事ができ、他の検索、更新処理も実装できるようになった。

【プロジェクト概要】 ・電力会社が電気料金請求や領収発行、及び社内で保管するための帳票を出力する機能の開発 ・Shellスクリプトによるバッチ処理内でJavaを実行し、データ取得・処理を行ってcsvファイルを出力する処理の改修を行なった。 ・本番データの不具合対応やパッチ当て 【プロジェクトにおける成果】 ①作業内容の説明能力 ・本番環境に上げる前に、 　自分が修正した設計書、コードで実施した単体、結合試験の結果をもとに 　やや年配のリリース判定者に説明するといった流れをとっていたため、 　試験仕様を考えながら修正に過不足がないか意識する習慣がついた。 　人を納得させる仕様や話し方を考える姿勢を持てたことが良い経験になった。 ②設計書に基づいた開発 　設計書ベースで動くプロジェクトだったため、 設計や仕様を考えてから実装に取り組む姿勢を身に付けた。 設計書や課題に関係のない修正を無断では行わないこと、客観的な仕様書に基づいて実装を行うスタンスを身に付けた。 　

【プロジェクト概要】 ・GCPのCloud Runでコンテナに分散したサービスを展開 ・テレワークスペース・施設・出張宿泊先を企業向けに手配するサービスの開発 ・エンドユーザーが施設を利用するために使用するための機能開発 ・社内ユーザーが施設手配及びリソース管理を行うための機能開発 ・事業拡大により、扱うサービスの種類が増えサービス毎の契約フラグ処理や請求を分割する処理が必要となった ・バックエンドAPIはGolang、フロントエンドはアクター別の画面を用意 ・認証処理はFirebase Auth 【プロジェクトにおける成果】 1. 会話型UI開発 　エンドユーザーが、チャットボットと会話する形で 利用したい施設の条件指定を行い、合致した施設を予約できる機能の開発 会話型UIは非機能要件が複雑で、会話内容の条件分岐や画面制御がかなり難しかったがコンポーネントのスロット機能を用いたり、親から子要素にcssスタイルを適用するなどして開発をやり切る事ができた。 　デザイナーの拘りが強く、見慣れないUIが多かったが、 既存のリポジトリで使われている文法からヒントを得て公式ドキュメントを調べてみたり、 デザイナー本人に期待する動きを聞いて開発の参考にするなどの工夫をした。 2. LINEボット開発、LINE連携機能開発 　サービスのLINE公式アカウント開発及び、サービス利用者のLINE連携機能の 要件定義、機能・テーブル設計、開発、リリースまで担当。 　要件決めから担当するのは初めての経験だったが、ビジネス側と調整を行なった上で要件定義を行う事ができた。テーブル設計では外部キーや照合順序についての理解するきっかけとなった。 　新規のAPIエンドポイントを複数個追加する開発を行い、ログ出力時のエラーレベルや、BigQueryへの分析用データ保存についてなどの知識を経験として身につけた。 　LINE連携の機能開発では、LINEが提供しているAPIを利用し、OAuth2の認証・認可の仕組みについて理解した。 　LINE通知を受け取る設定をしているユーザーに対しては施設の予約完了時にメッセージを送信する機能も追加し、タッチポイントを増やす事ができた。 3. API外部公開 　施設を予約するために内部利用していたAPIと同じ機能を提供するAPIを作成し、 外部公開する作業を行った。 　必要なAPIが扱うデータに応じてマイクロサービスの各エンドポイントに分散していたため、API Gatewayを利用することでリクエストURIを集約させた。 　外部向けにAPI仕様書を作成し、利用先の企業に提供した。 　システムで提供しているOauth2サービスで認証・認可を行い、各APIのミドルウェアで該当するスコープが許可されているかのチェックを行った。 　Input/Outputを外部向けに簡略化し、内部システムで返却している不要な情報はレスポンスから切り捨てるように工夫をした。 　エンドポイントを外部公開したため、Dos攻撃が発生するなどセキュリティ上の問題が発生したがCloud Armorでレートベースのリクエスト拒否を実行したり、リクエストヘッダーを検証することで不正なリクエストに対処できるようにした。 4. 利用金額集計処理改修 　ユーザー毎の月毎の利用金額を集計する処理を改修した。 提供するサービスに出張手配も追加されたことにより、サービス毎に利用金額を見せたいという要件があった。また、キャンセル料や追加請求が生じる事もありそれらの金額も合算して金額を取れるようにする必要もあった。 ### 工夫した点 * 利用額+キャンセル料+追加請求額を1回のSQL実行で取得できるようにするため、それぞれのテーブルのSELECT文をUNION句で結合した。 * サービス種類、利用月毎の集計を行うため、GROUP BY句を使用した * DAETIME型の値はUTC, DATE型の値はJSTで登録されているため、WHERE句で日時の条件を記述する際は月初、月末利用も正しく取れるよう、型に応じてタイムゾーン変換を行なった値を月に変換するなどの工夫を行なった。 5. 資金調達を目的としたRedashダッシュボードの構築・各KPIをトラッキングするためのSQL作成 　GMV,アクティブユーザー数などの各種KPIを追うためのSQLを数十個程度作成した。 ビジネス側のマネージャーから依頼された要件をもとに、 取得値やグルーピング条件等を提示・決定しSQLの作成に当たった。 チーム全体として、常にKPIの達成状況を追っていく風潮ができた。 また、実際に代表が資金調達を得るためのアピール材料としてRedashの画面を活用し、 これがVCに評価されたようで、1億円ほどの資金調達に繋げる事ができた。 ### 工夫した点 * WITH句を利用し、可読性を改善した * explain句を都度実行し、想定されているインデックスが使われているか・行数の多いレコードを繰り返し読んでいないかなどを確認するように心がけた。 * 他の業務等で作業が難しい場合は、他のメンバーにSQL作成をアサインするなどし、チーム力の底上げを図った。