ID:34211さん

【プロジェクト概要】 ・背景として、「働く誰もが主人公に」というビジョンがある。コロナ禍によりリモートワークが進んだ事を背景に、働く場所の手配、精算、社内問い合わせといった生産性の低い業務のために無駄な時間が使われており、本来やりたい仕事ができていないという問題がある。 　そこで、利用企業の従業員が、テレワークスペースの手配や、出張の手配、社内QAを自分で短時間で完結できるサービスを開発、展開している。 ・事業拡大により、扱うサービスの種類が増えサービス毎の契約フラグ処理や請求を分割する処理が必要となった ・規模 導入企業: 250社程度 従業員総数: 1万人弱 ・チーム体制 Biz 7名, Dev 6名（うち、正社員4名）, Design 2名（いずれも業務委託） ・担当役割 要件定義、設計、開発、保守 ビジネスチームと連携し仕様調整、要件すり合わせ 使用技術 ・GCP, Cloud Run, Cloud SQL, Firestore, BigQuery ・API: 　Golang, Echo ・フロント: Nuxt.js,Vue Next.js・React,Typescript, styled-components, react-query等 ・バックエンドAPIはGolang、フロントエンドはアクター別の画面を用意 ・Firebase Auth(認証) 【プロジェクトにおける成果】（降順） ## 1.UIリプレイス （Nuxt.js => Next.js） ### 課題・背景 ・初期で作られていたユーザーUIが、立ち上げ時に提供されていたサービス（テレワーク手配）しか使えない構成だった。 ・しかし、コロナ禍が落ち着いてきたことにより社内イベントや、出張手配等への需要も高まってきた一方で、これまでのUIではサービス拡張してもクロスセルが進みにくい。 ファーストビューでサービス一覧を可視化できるUIに作り変えていく事となった。 技術的な背景としては以前より、開発チーム内でVueだけではなくReactも使いたいという声があり Reactをサーバーサイドレンダリングできるよう拡張されたNext.jsを使う事になった。 ・開発は長期的に行い、2,3ヶ月ごとに1サービスをリリースしていった。 ### 取り組んだ内容 ・デザイナーと共にコンセプト決め、WFの構築 ・Nextの基盤構築（React経験者の業務委託が中心となり、その後引き継ぎ） ・要件定義ドキュメントを作成、全社レビューを受ける ・画面一覧、業務フローを作成 ・スケジュール設定 ・開発チームとして想定される要件と、ビジネス側の要求をすり合わせ、最終的な要件を作成（PMと連携） ・リーダーとして、タスクを作成し割り振り ・リモートの外部委託エンジニアとMTGを行い、フォロー ・条件指定・予約、予約一覧画面の設計、開発 ・開発チーム内で出た、ビジネス判断が要る課題の調整 ・react-queryを用いたキャッシュ適用などにより、パフォーマンス改善 ### 課題点 ・元々、最初のリプレイスを3ヶ月でリリースまで行う予定だったが、5ヶ月かかった ・最初に要件を固めていなかったため、後で必要な機能が次々と出てきた事が原因。 ・意思決定する際に、初期から他部門を巻き込んでおけば、期間を圧縮できたのでは、という反省がある ## 2.資金調達を目的としたRedashダッシュボードの構築・各KPIをトラッキングするためのSQL作成 ### 課題・背景 UIリプレイス開発を進めるため、新しく資金調達が必要。 投資家に業績をアピールしたいが、数字を可視化できる資料が、Excelなどドキュメント程度しかない。 業績がわかるよう、Redashでダッシュボードを構築したい。 ## 対応内容 　GMV,アクティブユーザー数などの各種KPIを追うためのSQLを数十個程度作成した。 ビジネス側のマネージャーから依頼された要件をもとに、 取得値やグルーピング条件等を提示・決定しSQLの作成に当たった。 チーム全体として、常にKPIの達成状況を追っていく風潮ができた。 また、実際に代表が資金調達を得るためのアピール材料としてRedashの画面を活用し、 これがVCに評価されたようで、1億円ほどの資金調達に繋げる事ができた。 ### 工夫した点 * WITH句を利用し、可読性を改善した * explain句を都度実行し、想定されているインデックスが使われているか・行数の多いレコードを繰り返し読んでいないかなどを確認するように心がけた。 * 他の業務等で作業が難しい場合は、他のメンバーにSQL作成をアサインするなどし、チーム力の底上げを図った。 ## 3.利用金額集計処理改修 ### 課題・背景 提供するサービスの種類が拡張されたことにより、サービス毎に利用金額を見せたいという要件があった。また、キャンセル料や追加請求が生じる事もありそれらの金額も合算して金額を取れるようにする必要もあった。 ## 対応内容 　ユーザー毎の月毎の利用金額を集計する処理を改修した。 * 利用額+キャンセル料+追加請求額を1回のSQL実行で取得できるようにするため、それぞれのテーブルのSELECT文をUNION句で結合した。 * サービス種類、利用月毎の集計を行うため、GROUP BY句を使用した ### 工夫した点 * DAETIME型の値はUTC, DATE型の値はJSTで登録されているため、WHERE句で日時の条件を記述する際は月初、月末利用も正しく取れるよう、型に応じてタイムゾーン変換を行なった値を月に変換するなどの工夫を行なった。 ## 4.API外部公開 ### 課題・背景 　UIで提供している、チャットをしながら施設を予約する機能を、Teams上でも提供したい。 TeamsからのAPIをアクセスするためには、一部APIを公開する必要がある。 ## 対応内容 ・Cloud RunにデプロイしているGoのアプリケーションに、外部公開用のエンドポイントを作成 ・API Gatewayを利用し、リクエストURIを集約させて公開した ・システムで提供しているOauth2サービスで認証・認可を行い、各APIのミドルウェアで該当するスコープが許可されているかのチェックを行った。 　エンドポイントを外部公開したため、Dos攻撃が発生するなどセキュリティ上の問題が発生したがCloud Armorでレートベースのリクエスト拒否を実行したり、リクエストヘッダーを検証することで不正なリクエストに対処できるようにした。 ## 5.LINEボット開発、LINE連携機能開発 　サービスのLINE公式アカウント開発及び、サービス利用者のLINE連携機能の 要件定義、機能・テーブル設計、開発、リリースまで担当。 　LINE連携の機能開発では、LINEが提供しているAPIを利用し、OAuth2の認証・認可の仕組みについて理解した。 ## 6.会話型UI開発 　エンドユーザーが、チャットボットと会話する形で 利用したい施設の条件指定を行い、合致した施設を予約できる機能の開発 会話型UIは非機能要件が複雑で、会話内容の条件分岐や画面制御がかなり難しかったがコンポーネントのスロット機能を用いたり、親から子要素にcssスタイルを適用するなどして開発をやり切る事ができた。 　デザイナーの拘りが強く、見慣れないUIが多かったが、 既存のリポジトリで使われている文法からヒントを得て公式ドキュメントを調べてみたり、 デザイナー本人に期待する動きを聞いて開発の参考にするなどの工夫をした。

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

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