インフォサイエンス株式会社 / サーバサイドエンジニア
統合ログ管理システムのログ収集モジュール群の中のクラウドサービスに特化したクラウド連携製品の開発
【業務内容】 統合ログ管理システムのログ収集モジュール群の中のクラウドサービスに特化したクラウド連携製品の開発 【担当フェーズ】 製品テスト全般(テストコード作成、単体テスト〜受入テスト) メンテナンス(プロファイリング·リファクタリング·クエリチューニング) トラブル·シューティング バージョンリリース 【開発内容】 開発・実装① 【概要】 クラウドサービスの各種ログ(監査、システム)収集モジュールの開発・設計 【どのような機能の開発・実装か】 外部クラウドサービスのログ取得のための定期的な収集モジュールおよびバージョンアップツール Microsoft Azure/Microsoft 365 (Azure SDK for Java/Microsoft Graph API) SalesForce (SOQL) 【課題・問題点】 製品の特性上、各クラウドサービスのログ取得API以外の処理が重複し、コードの重複が発生、開発工数が増加 大量のログを扱うため、DB処理がボトルネックとなり、パフォーマンスが大幅に低下 【打ち手・使用した技術】 ログ取得以外の部分(ユーザー認証情報、バリデーションなど)をMaven Repositoryに共通ライブラリとしてアップロードし、開発工数削減とコード重複解消 Visual VMなどのプロファイリングツールを使用して、ボトルネックになる処理を特定。非効率的なデータ格納をバッチ単位で処理するように変更し、無意味なクエリの乱立や繰り返しをラムダ式、バッチインサートなどでバッチ単位に分けて処理するようにリファクタリング 開発・実装② 【概要】 バージョンアップのためのフレームワーク開発 【どのような機能の開発・実装か】 SaaSサービスではなく、オンプレミス環境のパッケージ製品であったため、バージョンアップを個別に行う必要があった 【課題・問題点】 修正事項が発生するたびに、各バージョンでのバージョンアップが正常に行われるかどうかをチェックする必要があり、検証にかかる工数が増加 【打ち手・使用した技術】 順次処理するためのフレームワークを開発 1.0 -> 3.0でバージョンアップをする場合、以前は1.0 -> 3.0、2.0 -> 3.0をすべて検証しなければならなかったが、1.0 -> 2.0 -> 3.0で順次バージョンアップを行うように修正したため、テストを1回だけすればよいという利点が生まれ、検証の工数を大幅に下げることができました。 【開発環境】 マルチスレッドプログラミング | 低レイヤファイルI/O技術 | 文字列探索、加工技術 | JUnitテスト、CI(継続的インテグレーション) | REST-API、JSON | OAuth | TCP/UDP | TLS、HTTP(S) | Jenkins Java | Kotlin Linux | Windows | VM Slack | RedMine | Git 【メンバー数】 4名(サーバサイドチーム) 【役割】バックエンドエンジニア ・ リリース済み製品の新バージョン開発および新規連携製品の開発 対象クラウドサービスの機能やログ収集方法(SDK、APIなど)の仕様調査 調査内容に基づいて開発内容を決定し、設計・実装・テストを行う 製品マニュアルやリリースドキュメントの作成 製品サポートチームからのエスカレーション対応 ・ クラウドサービスや製品仕様の調査 再現検証、ワークアラウンド検証、原因調査 【仕事を通して学んだこと】 (1) 責任感 チームには実際の開発メンバーが3人しかいなかったため、自分のタスクを責任を持って最後まで遂行することが重要だと実感しました。もちろん協力を通じて助けを求めたり提供することができますが、基本的に自分の担当分野は自分が責任を持って対処する姿勢が大切だと思いました。自分に与えられたタスクを最後まで遂行したとき、チームにとって信頼できる存在になり、信頼感が生まれることも感じました。今後もこの意識を持ち続けて仕事に取り組みたいと思います。 (2) 積極性 長年の経験があってもすべてを知っているわけではないため、自分が考えたより良いソリューションがある場合は積極的に提案したり、チームと共有することで互いに成長できると思いました。自分で調べたり検証した内容をチームメンバーに論理的に説明することが重要だと考えるため、常に根拠を持つことで技術的にもエンジニアとして成長し、同時にコミュニケーション能力も向上すると感じました。今後も疑問が生じたり、理解できない現象があれば、調査を行いながら、他の人を納得させるためにコミュニケーション能力を向上させることが大切だと感じました。 (3) 技術を問題解決の道具として エンジニアとして4年目になり、開発技術自体に意味を持つよりも、それを用いて価値を実現する手段であるという認識を持つようになりました。技術的なこだわりよりも、誰かに役立つ価値を創出できるエンジニアになりたいと考えるようになりました。