ID:71857さん

# プロジェクト概要 インターネット広告の入稿システムで使用しているJavaのフレームワークであるSpringBootのバージョンがEOLになったので、メジャーバージョンの更新を行った。 # チーム情報 - チームリーダー: 1名 - メンバーEng: 4名 # どのような機能の開発・実装か インターネット広告の入稿システムで使用しているJavaのフレームワークであるSpringBootのバージョンがEOLになっていたので、セキュリティ観点でアップデートが必要になったため、プロジェクトとしてアップデート対応を行いました。 メジャーバージョンの更新だったのでフレームワークの仕様が大きく変わり、Deprecatedになったコードの確認やバージョン更新による既存挙動の変更が無いかをユニットテスト・結合テストで自動的に確認しつつ、手動での確認も行い、リリースを行った。 リリース後はバージョン更新によるバグで事故は発生することも無く、運用を続けることが出来ました。 # 使用技術 - バックエンド - Java(SpringBoot) - インフラ - k8s (自社のオンプレ)

# プロジェクト概要 インターネット広告の入稿システムにて、広告を見せるターゲットの属性を新しく作りたいとの要望がPMからあり、設計・実装をエンジニアとして担当しました。 # チーム情報 - チームリーダー: 1名 - メンバーEng: 4名 # どのような機能の開発・実装か インターネット広告の入稿システムにて、広告を見せるターゲットの属性を新しく作りたいとの要望がPMからあり、新しいターゲットの情報を広告の入稿システム -> 審査システム -> 配信システムに追加する事になりました。 自分は入稿システムを担当することになり、まずは現状のターゲットの仕様確認や、ターゲットの属性を新規追加する事で現状のビジネスロジックに不備を発生させる事がないかの調査から入りました。 調査を進めていくと、既存のターゲットにただ属性を追加するだけだと審査・配信に送るデータの整合性が取れなくなる可能性がありそうだったので、広告を審査するチーム・広告を配信するチームと担当PMを交えて、要件定義や設計をすり合わせしつつ、広告の入稿システムにターゲット情報の実装を行いました。 実装・テストが完了し、リリースを行ったところ、事故等は発生することもなく、問題なく運用を続ける事が出来ました。 # 使用技術 - バックエンド - Java(SpringBoot) - インフラ - k8s (自社のオンプレ)

# プロジェクト概要 Engとして、オフィスに設置した水槽の温度確認・調整と冷凍餌の給餌を人の手を借りずに自動的に運用が行えるように、水槽に繋ぐハードウェアの組み込みと、ハードウェアと通信して記録・指示を行うサーバーの構築・運用を担当しました。 # チーム情報 - テックリーダー: 1名 - メンバーEng: 1名 (自分) # どのような機能の開発・実装か 所属したスタートアップ企業にて、「オフィスに設置した水槽を自動的に管理を行えるようにしたい」を実現させるために0からデバイスやサーバー、インフラの設計・構築・実装を主に1人で行いました ## PJ発足直後 まず水槽を自動的に管理するためには、どういった情報が必要・その情報を取得/表示するためにはどのようにするべきかの設計を行いました。 水槽で管理したい情報として、何が必要か水槽の専門家に相談したところ、水温と水槽内の状況を確認出来る映像/静止画が求められるとの事でした。 そこで、水温と水槽内の状況写真を保存出来るようにAPIサーバーとして、学習コストが少なく、APIサーバーとして必要な機能を低コストで立ち上げる事が出来るRailsで、AWSへのデプロイをなるべく早く実現させるためにElaticBeansTalkを利用して構築を行いました。 また、水槽に設置するデバイスとしては、水槽横にあっても違和感のないサイズ感で、様々なデバイスとUSB通信が行え、Wi-Fi接続が可能なRaspberryPiを採用し、組み込みソフトウェアとしてはRaspberryPiや他ライブラリが多数提供されているPythonを選択しました。 実装・構築・運用を行うまでをなるべく早くしたいとの事でしたので、全体で約二ヶ月程かけて完成させました。 今までの経験でハードウェア/組み込みを行ったことが無かったのですが、0ベースで学習を行いつつ設計・実装を行い、プロトタイプとして運用していくところまで持っていく事が出来ました。 ## PJ発足後の運用 実際に水槽にデバイスを取り付け、運用していく中で以下の問題が発生していました - 水槽から出てくる塩入り水蒸気でデバイスが故障してしまう - ネットワークの不調や故障によりデバイスがデータを送らなくなり、水温・写真データが送られてこなくても開発者が気づかない - 水槽内の水温が生物に適さない温度になっていても、アラート等がないため担当者が気づかない 上記の問題毎に以下のような対応策を取っていきました ### 水槽から出てくる塩入り水蒸気でデバイスが故障してしまう 水槽横に取り付けたデバイスが、数週間経つと動作不良を起こすことが何回かあったので、不具合を起こしたデバイスの基盤を確認すると、表面に塩が浮かんでいました。 対応策としては、デバイスの基盤が外気に晒されないように3Dプリンターでケースを作成し、取り付けることにしました。 ### ネットワークの不調や故障によりデバイスがデータを送らなくなり、水温・写真データが送られてこなくても開発者が気づかない ネットワークの不調や故障によりデバイスがデータを送らなくなり、水温・写真データが送られていない事を開発者が気づかずに、数日のデータが欠損している事がありました。 対応方法としては、ネットワークの不調等で一時的にデバイスが接続出来ていない場合には、APIのPOSTが何度か失敗した時にプロセスをキルし、RaspberryPiのsystemctlにてOS毎再起動を行うように設定を行った。 また、デバイスの故障等で再起動でも送ることが出来ない場合、サーバー側で水温・写真データが何回か送られてきていない事をキャッチし、Slack/LINEでの通知と緊急性が高い事もあるのでPagerDutyにてオンコールをかけるようにサーバー側の改修を行いました。 この対応により、ネットワーク不調の場合にはデバイスが自力で復旧する事が出来るようになり、それ以外の原因でデバイスが故障してデータが送れなくなった際にも、開発者が故障していることをすぐにキャッチし、デバイスの復旧を即座に行うことが出来るようになりました。 ### 水槽内の水温が生物に適さない温度になっていても、アラート等がないため担当者が気づかない 水槽に生息する生態に適した水温ラインを上下に超えた場合に、担当者が即座に気づき反応する必要があります。そこで、水槽毎に適温水温を設定できるようにDBにTableを追加し、設定した適温のプラスマイナス1℃した場合には、担当者に電話出来るようにPagerDutyによるオンコールを設定/LINEで通知するようにサーバー側の改修を行いました。 この対応により、水温が適温より離れてしまうことで発生する生態系の死滅や環境の大きな変化を事前に防ぐ事が出来て、水槽を用いた研究実験でも想定する環境を維持し続ける事が出来るようになり、多くの企業との共同実験を成功に導く事が出来ました。 ## アクアリム専門の大企業とのコラボでのToBデバイスの構築 アクアリウムを専門としている大企業から、大規模水槽を管理出来るように会社で作り上げたサービスとコラボしたいとの連絡を頂いたので、既存のシステムに「RaspberryPiに接続しているArduinoに命令を送れるように、PubSubを追加/RaspberryPiで接続済のArduinoに命令を送れるように追加」といった改修を加えました。 元々のシステムとしては、Arduino (Serial通信)=> RaspberyPi (HTTPS)=> APIサーバーの一方通行でのデータ送信だけで行っておりました。しかし、このPJでは「RaspberryPiに接続している冷凍餌やり機・クーラー・ヒーターに命令を送って操作したい」という要求があったので、今までと逆の通信経路を確保する必要がありました。 RaspberryPiで命令を受け取れる & サーバーからの命令をスルーしないように取りこぼすことのない通信経路を用意する必要があったので、APIサーバーとRaspberryPiでAWS IoTを用いたPubSubを構築し、メッセージの受け取りを確認した際に従来通りの通信経路でメッセージ受領確認したとのAPIを叩くようにしました。 上記対応で、サーバーから送った命令をRaspberryPiで受け取り、各種Arduinoに命令操作を送れるようになりました。 # 使用技術 - バックエンド - Rails - 組み込み (デバイス) - RaspberryPi - 組み込み (システム) - Python/Arduino - インフラ - AWS - オンコール - PagerDuty

# プロジェクト概要 所属している会社の自社ソフトである会計ソフトにて、発生した明細を登録したルールを元に自動処理する機能に対して、会計業務の消込を行う際に発生する差額調整を自動で行えるように拡張対応を行いました。 # チーム情報 - テックリーダー: 1名 - メンバーEng: 4名 - PM: 1名 - UI/UX: 1名 - QA: 1名 ## PJに関わったメンバー - Eng(フルスタック): 2名 - PM: 1名 - UI/UX: 1名 - QA: 1名 # どのような機能の開発・実装か 所属している会社の自社ソフトである会計ソフトにて、発生した明細を登録したルールを元に自動処理する機能が存在しています。 既存機能としては、明細に対して登録した勘定科目での複式簿記で記入したり、口座への振替に変更したり、明細自体を無視したり等の単純登録系は備わっておりました。 会計業務の消込を行う際に発生する差額分の勘定科目はある程度固定化されているのだが、こういった登録ルールでは補完が出来ておりませんでした。 そこで、会計業務の消込を行う際に発生する差額調整を自動で行えるように、登録ルールに差額調整のルール機能の拡張対応を行いました。 Engとしては主に以下の業務を行いました。 - PMの要望書を元に、DesignDocの作成 - 現状のコード/ビジネスロジックの確認 - テーブル設計 - API設計 - リリース前に行う大量データのConvertTaskの設計 - DBとAPIの実装 - 移行Taskの実装と本番想定環境での負荷検証 - 本番リリース作業 # 工夫した点や取り組み 1. 当初PMが考えていた追加機能の改修範囲が工数として2年以上かかりそうな膨大な量になっていたため、即座に改修機能をユーザーに提供するためにPJ全体を1st/2nd/3rdと三分割し、1stリリースでユーザーのペインをひとまず解消出来るように調整した 2. 登録ルールを保存するTableに今回の機能用のColumnを追加する案が当初出ていたのだが、1つのTableに膨大なColumnを用意してしまうと運用・保守の面で大きなコストになってしまう事が予見されたため、なるべく機能の要素ごとにTableを事細かく分けるように設計を行った 3. 既存のビジネスロジックの挙動や今回実装する追加機能の挙動がチーム全体でも把握している人があまりいなかったので、実装を行いつつKibelaにて誰にでも分かるようなドキュメントを作成していった # 使用技術 - バックエンド - Rails - フロントエンド - React - TypeScript - インフラ - AWS

# プロジェクト概要 所属している会社の自社ソフトである会計ソフトにて、発生した明細を登録するルールがどのぐらい使用されているかの使用率とルールの内容をそのまま利用しているかの一致率を表示する追加改修を行った。 # チーム情報 - テックリーダー: 1名 - メンバーEng: 4名 - PM: 1名 - UI/UX: 1名 - QA: 1名 ## PJに関わったメンバー - Eng(フルスタック): 1名 - PM: 1名 - UI/UX: 1名 - QA: 1名 # どのような機能の開発・実装か 所属している会社の自社ソフトである会計ソフトにて、発生した明細を登録したルールを元に自動処理する機能が存在しています。 登録ルールは登録ルール一覧画面での新規作成も行う事が出来るのだが、明細の登録処理を行った際に登録した内容を元に登録ルールを自動的に登録するようになっており、ユーザーにとって不要な登録ルールが大量に作成されてしまう事があった。 不要な登録ルールが大量に作成されてしまう事で、明細の登録処理を行う際に必要のない登録ルールが当たってしまい、ユーザーにとってノイズな情報になってしまい、登録ルールの価値が下がってしまう恐れがあった。 そこで、不要な登録ルールを認知・削除するための施策の初めとして、保存されている登録ルールがどのぐらい使用されているかの使用率と当たったルールの内容を変更せずに処理しているかの一致率を登録ルール一覧に表示する追加改修を行った。 Engとしては主に以下の業務を行いました。 - PMの要望書を元に、DesignDocの作成 - 現状のコード/ビジネスロジックの確認 - テーブル設計 - API設計 - リリース前に行う大量データのConvertTaskの設計 - 仕様面での他チームとの相談MTGの設定・すり合わせ - DBとAPIの実装 - 移行Taskの実装と本番想定環境での負荷検証 - 本番リリース作業 # 工夫した点や取り組み 1. 既存の登録ルールのTableに使用率・一致率のColumnを追加する必要があった。本番環境のDBのTableにRecordが100万単位存在し、移行Taskをそのまま実行した場合にDBへの負荷がどのぐらい発生するのかと処理完了までにどのぐらい時間がかかるのか未知数だったので、本番想定のIntegration環境で移行Taskを実行し、処理にかかる時間と負荷を事前に検証し、移行Taskを実行することが問題ない事を確認した。 2. APIの実装を行う際に、改修対象のコードがレガシーコードが多数存在していたので、今後の開発効率の向上のために、改修範囲のリファクタリングを行えるようにPMと相談し、機能改修の実装を行いつつリファクタリングを行うようにした。 3. PJの改修範囲で、チームの担当範囲外の仕様に影響を与えてしまう事が発覚した際に、この仕様面がPJのブロッカーになってしまう恐れがあったため、直ぐ様関係チームとのすり合わせMTGを設定し、仕様面の改修の方向性を定めた。 # 使用技術 - バックエンド - Rails - フロントエンド - React - TypeScript - インフラ - AWS