## プロジェクトの概要
食品工場などの多品種少量生産の工場の生産の進捗を管理するために、工場にセンサを設置し、データを取得・分析し工場の生産管理のDXひいては生産の改善につなげることがプロダクトの目的。
## 担当した業務
### ダッシュボードの実装
開発環境はAmplifyでのサーバーレス開発。フロントはTypescript+React。
#### 大変だった実装
ガントチャートの実装
d3.jsを使ってガントチャートを実装した。d3.jsはもともとガントチャート特化のライブラリではないこと、ズーム機能やポップアップなど様々なオプション機能の実装、さらにはデザイン性の向上のために、かなりゴリゴリにsvgをいじって実装した。
また、d3はデータ点数が増えると描画が重くなるパフォーマンス劣化の問題が出てくる。
そこで、どこにボトルネックがあるか調査したのち、
1. 低性能なデバイスで描画してもパフォーマンスが気にならないDOM数の上限を測定し、バックエンドから返ってくるデータ点数がその測定したDOM点数より多ければ、その量に比例してフロントでデータを結合して（グラフの見え方が損なわれない程度に）DOM点数を減らした。
またIoTデータの特質上、どうしてもデータ点数が多くなってしまうため、バックエンド側でもパフォーマンス問題が発生した。そこで、
2. n+1クエリ問題が起きていたので、呼び出し回数を減らせるようにカラムを追加した。
3. Lambdaのキャパシティが小さかったので、所要時間を計測しながら、所要時間が効果的に短縮される必要最小限のキャパシティを設定した。
その結果、グラフの描画にかかる時間は最大で1/10ほどまで改善した。
### 要件定義〜設計
コーディング業務だけでなく、要件定義から設計というより上流工程も担当した。
具体的には顧客からのヒアリング等をもとに、実装予定の新機能についてどのようなユースケースが存在し、どのような見せ方/UXにするのが効果的かをPMやチームメンバーと議論し、それをアプリケーションの設計に落とし込んだ。
具体的には、生産の進捗をよりグラフィカルに顧客に見せたい狙いがあった。そこで、それまでに得た顧客からの意見を参考にしつつ、
1. 複数の製品（または工程の）進捗を見せるにはガントチャートの形式がふさわしいと考え、採用
2. 顧客が製品軸と工程軸の2つの軸で進捗を確認したいユースケースがあると想定し、画面上で簡単にこれらを切り替えられるように
3. 顧客が社内でガントチャートを共有するユースケースがあると想定し、期間などの検索条件をURLクエリにして、リンクだけで簡単に共有できるように
などを策定した。
### CSとの兼ね合い
エンジニアとしての開発業務に加えて、CS(カスタマーサービス)業務にも従事し、既存顧客の工場に実際に足を運んだり、担当者の方へ定期的にヒアリングを行いサービス改善・顧客理解に努めた。エンジニア兼CSは当時社内でもほとんどいなかったが、CSを行うエンジニアの側面では、顧客がソフトウェアを使用する上で発生した技術的な問題への対応が技術的な知見をもとに迅速にできること、開発に携わるCSの側面では、顧客からの声を開発計画に実際に落とし込む、もしくはその提案ができるというメリットを発見し、積極的に取り組んでいた。
前者の例としては、顧客との定期ヒアリングの際に報告を受けたサービスの不具合・バグについて、それがそもそもバグなのかそれとも開発の想定上正しいのか、バグである場合、復旧におおよそどれくらいの時間がかかりそうかをすぐに顧客側に伝えることができた。後者の例は実際に顧客がどのようにサービスを利用し、またどのような潜在的欲求を持っているかを考え、PM等と議論し開発計画に対策を盛り込んだりした。具体的にはダッシュボード画面での検索機能に関する改善など。
### 開発体制に関する提案
開発体制に関しての提案を行いそれが採用された。
具体的には、技術的負債が溜まってきている場合、それを解消するためだけの曜日をアジャイルに組み込んだ。
また、中規模な新機能開発と顧客からの要望等の軽微な修正がある中で、git管理が単一のdevelopブランチでのgit-flowで運用されていたために、軽微な修正の商用環境への反映が遅くなってしまっている問題があったため、git-flowでdevelopブランチを複数走らせる方針への提案を行い、採用された。またその後の運用も担当した。
## 役割
### チームリーダー / サブリーダー
少人数ではあるものの、5,6人の開発チームのリーダーやサブリーダーを何回か努めた（アジャイルの期間で何度か交代）。
ビジネスサイドとのやりとりや、全社会議での開発チームの進捗の共有、チームメンバーへの定期的な進捗確認やタスク管理などを行った。