SEUNGYEON スンヨン HWANG ファン

Goaal は、「タスク管理および共同作業ツール」を提供しています。このアプリケーションは、目標達成に必要なタスク管理を支援するためのツールで、大きな作業を細かく分割して実現可能性を高めます。チームメンバー間の協力と作業進捗を一目で確認できるため、作業の効率を向上させることができるサービスです。 下記のリンクを参照してください。🙇‍♂️ デモンストレーション : https://www.youtube.com/watch?v=EhLCFp61wEo

【業務内容】 BtoBのSalestechプロダクトを開発「個人の位置情報とGISシステムを組み合わせたクラウド型の営業支援ツール」 【担当フェーズ】 事業拡大による新規開発全般（サーバサイド）　(アジャイル/スクラム) メンテナンス（性能改善·リファクタリング） トラブル·シューティング システム運用監視(Azure) バージョンリリース 【開発内容】 開発・実装① 【概要】 バッチ処理の開発・設計 【どのような機能の開発・実装か】 外部CRM情報との情報同期のための定期インポート処理 SalesForce (SOQL) Microsoft Dynamics365 (Web API) 【課題・問題点】 バッチ処理のレコード差分を得るためにインポート処理で臨時テーブルを準備して比較しましたが、読み書きの頻度が高くなるとDBのストレージパーセントが増加し、結果負荷が増加やアプリが重くなるなどの問題が発生。(postgresSQLの仕様上、デッドチュープル発生) 【打ち手・使用した技術】 Redisを導入し、差分比較をRedis上で行い（SDIFF）、結果値だけをDBに保存するように改善(メモリが消えた場合も動くように実装) 優先度の低いオブジェクトのバッチ処理を2つの部分に分けてそれぞれ違う頻度でインポートされるようにバッチ処理を再設計 開発・実装② 【概要】 検索のAPIの性能低下 【どのような機能の開発・実装か】 CRMに登録された取引先、リード、商談などのレコードがバッチ処理を通じてDBに保存された状態で、このレコードを各種条件で検索するできる機能 【課題・問題点】 ほとんどのエンドユーザーは大企業であるため、検索対象のレコード数が多くなり、検索APIの応答速度が遅くなったりエラーが発生したりする問題発生 【打ち手・使用した技術】 既存の検索APIの性能改善のためにElastic Searchを導入 既存のSQLクエリをElastic Search特有のクエリに変更（must、should、termなど） RDB → Logstash → Elastic Searchの自動データ投入の仕組み 【開発環境】 Kotlin | SpringBoot | PostgreSQL | SalseForce / Microsoft API | GraphQL | Docker | OAuth | Azure | Redis | Elastic Search | Jira | Teams, Slack, Google Meet | Git 【メンバー数】 ４名（サーバサイドチーム） 【役割】バックエンドエンジニア 主なタスクとしては自社サービスであるBtoBのSalestechプロダクトを開発·運用する役割でした。 既存サービスのマルチプラットフォーム化やAPIの設計・開発を行い、 サービス改善のためのソリューションを提案しました。 また、サービスが支障なく運営されるよう性能改善やクラウド上のDB負荷の増加などを監視しました。 【仕事を通して学んだこと】 (1) 自主性 自社サービスの開発は発注元がないため、サービスの改善や課題について自主的に考えて行動することが求められる環境でした。単純に言われたことを開発するのではなく、自ら課題を見つけ、提案することが多かったです。 その過程でProduct Ownerと先輩エンジニアを説得したり設計について説明したりすることが多かったです。 以上の経験より、自分の考えを論理的に説明する能力を身につけることができました。 (2) コミュニケーション能力 業務は設計から実装、テストまで全てを行いましたが、時には自力で解決できない問題もありました。この時は問題を解決するために他のベテランエンジニアを巻き込んだり有識者に質問したりして問題を解決しました。 また、お互いの認識違いによる手戻りが発生しないように積極的にコミュニケーションをとるように努力しました。 (3) チーム意識 少人数の開発チームだったので自分のタスクも重要ですが、他のエンジニアがどんな作業をしてどんな問題を解決したいのかにも興味を持つようにしました。 当時開発したプロダクトはSalesForceの仕様を理解しないと開発できなかったので、他の人が何の目的で開発しているのかをよく理解し、分からないことがあれば積極的に質問するようにしました。 また、個人ではなくチームとして仕事を進める文化だったので、スプリント終了後には必ず振り返りを行って問題のあった部分をお互いに話し合い、改善するために次のアクションを決めました。 【仕事で大変だったこと】 大変だったことは、実際にリリースされているサービスを開発するということで、常に顧客に与える影響を考えて開発しなければならないということでした。 最初に経験した開発環境は、リリース前の業務系システムだったので最初には大変だと思いました。 既存のサービスを改善していくことも大事ですが、顧客の立場では細かい変更もディグレとして感じられるため、開発と同時にビジネスサイドのバランスを取ることも重要だと感じました。 また顧客の問い合わせからのトラブルシューティングも難しかったです。 クラウド上のログを調べて原因を特定するには仕様についての理解も必要だったので、最初は仕様の理解のためにアプリを生活で直接使いながら仕様を理解するように努力しました。