Discover companies you will love

SEUNGYEON スンヨン HWANG ファン

株式会社CoeFont / エンジニアリング埼玉県

SEUNGYEON スンヨン HWANG ファン

株式会社CoeFont / エンジニアリング

Now or Never

初めまして。🙇‍♂️ ファンと申します。 2020年2月から日本でエンジニアとして活動しています。

アメリカ留学及び営業職経験
Jul 2017 - Jan 2018

github.com

Ambition

In the future

① 最初はガリガリとコードを書くプレイアとして活躍したいです。社内で経験を積み、さまざまな機能を実装してターゲットユーザーの属性を拡大し、サービスをさらに展開していきたいです。

株式会社CoeFont1 year

エンジニアリングPresent

Aug 2023 - Present

【プロジェクト概要】「声」を表現力豊かな「フォント」として変換し、安価で誰もが簡単に利用できる音声サービスを提供【業務内容】最新の AI 音声技術を用いて、プロダクトの機能実装を推進

インフォサイエンス株式会社1 year

サーバサイドエンジニア

Mar 2022 - Jul 2023

Goaal - タスク管理および共同作業ツール
Goaal は、「タスク管理および共同作業ツール」を提供しています。このアプリケーションは、目標達成に必要なタスク管理を支援するためのツールで、大きな作業を細かく分割して実現可能性を高めます。チームメンバー間の協力と作業進捗を一目で確認できるため、作業の効率を向上させることができるサービスです。下記のリンクを参照してください。🙇‍♂️ デモンストレーション : https://www.youtube.com/watch?v=EhLCFp61wEo
Feb 2023 - Apr 2023
統合ログ管理システムのログ収集モジュール群の中のクラウドサービスに特化したクラウド連携製品の開発
【業務内容】統合ログ管理システムのログ収集モジュール群の中のクラウドサービスに特化したクラウド連携製品の開発【担当フェーズ】製品テスト全般(テストコード作成、単体テスト〜受入テスト) メンテナンス(プロファイリング·リファクタリング·クエリチューニング) トラブル·シューティングバージョンリリース【開発内容】開発・実装① 【概要】クラウドサービスの各種ログ（監査、システム）収集モジュールの開発・設計【どのような機能の開発・実装か】外部クラウドサービスのログ取得のための定期的な収集モジュールおよびバージョンアップツール 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 【メンバー数】４名（サーバサイドチーム）【役割】バックエンドエンジニア・リリース済み製品の新バージョン開発および新規連携製品の開発対象クラウドサービスの機能やログ収集方法（SDK、APIなど）の仕様調査調査内容に基づいて開発内容を決定し、設計・実装・テストを行う製品マニュアルやリリースドキュメントの作成製品サポートチームからのエスカレーション対応・クラウドサービスや製品仕様の調査再現検証、ワークアラウンド検証、原因調査【仕事を通して学んだこと】 (1) 責任感チームには実際の開発メンバーが3人しかいなかったため、自分のタスクを責任を持って最後まで遂行することが重要だと実感しました。もちろん協力を通じて助けを求めたり提供することができますが、基本的に自分の担当分野は自分が責任を持って対処する姿勢が大切だと思いました。自分に与えられたタスクを最後まで遂行したとき、チームにとって信頼できる存在になり、信頼感が生まれることも感じました。今後もこの意識を持ち続けて仕事に取り組みたいと思います。 (2) 積極性長年の経験があってもすべてを知っているわけではないため、自分が考えたより良いソリューションがある場合は積極的に提案したり、チームと共有することで互いに成長できると思いました。自分で調べたり検証した内容をチームメンバーに論理的に説明することが重要だと考えるため、常に根拠を持つことで技術的にもエンジニアとして成長し、同時にコミュニケーション能力も向上すると感じました。今後も疑問が生じたり、理解できない現象があれば、調査を行いながら、他の人を納得させるためにコミュニケーション能力を向上させることが大切だと感じました。 (3) 技術を問題解決の道具としてエンジニアとして4年目になり、開発技術自体に意味を持つよりも、それを用いて価値を実現する手段であるという認識を持つようになりました。技術的なこだわりよりも、誰かに役立つ価値を創出できるエンジニアになりたいと考えるようになりました。
Mar 2022

UPWARD株式会社1 year

バックエンドエンジニア

Mar 2021 - Mar 2022

BtoBのSalestechプロダクトを開発「個人の位置情報とGISシステムを組み合わせたクラウド型の営業支援ツール」
【業務内容】 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の仕様を理解しないと開発できなかったので、他の人が何の目的で開発しているのかをよく理解し、分からないことがあれば積極的に質問するようにしました。また、個人ではなくチームとして仕事を進める文化だったので、スプリント終了後には必ず振り返りを行って問題のあった部分をお互いに話し合い、改善するために次のアクションを決めました。【仕事で大変だったこと】大変だったことは、実際にリリースされているサービスを開発するということで、常に顧客に与える影響を考えて開発しなければならないということでした。最初に経験した開発環境は、リリース前の業務系システムだったので最初には大変だと思いました。既存のサービスを改善していくことも大事ですが、顧客の立場では細かい変更もディグレとして感じられるため、開発と同時にビジネスサイドのバランスを取ることも重要だと感じました。また顧客の問い合わせからのトラブルシューティングも難しかったです。クラウド上のログを調べて原因を特定するには仕様についての理解も必要だったので、最初は仕様の理解のためにアプリを生活で直接使いながら仕様を理解するように努力しました。
Mar 2021 - Feb 2022

株式会社ホープス1 year

バックエンドエンジニア

Feb 2020 - Feb 2021

韓国コスメ専門ECサイト
デモンストレーション : https://www.youtube.com/watch?v=CcBkQrkF9ig ReadMe : https://github.com/SeungyeonHwang/ec_loen_project/blob/main/README.md 「どうせやることなら楽しくやる方ががいいんじゃないか」という思いで自分の価値観や考えを反映させたECサイトを作りました。このアプリケーションはコスパの良い韓国コスメが若い女性に流行っている状況を認識して主に若い女性をターゲットした、各種オンラインストアと連携して実が高い韓国製品を出前で注文できるサービスです。 Amazon,Qoo10などのECサイトをイメージして作りました。開発をする際にに工夫したのはターゲットユーザーはとどんなコンセプトで作ろうかでした。いくら良いサイトを作っても、それを利用してくれるユーザーがいないと無駄だと思ったからです。そいった点をしっかり決めてから、設計をして開発に着手しました。 💻 アプリケーション内で使用している技術一覧 - フレームワーク : Ruby on Rails(5.2.4) - 使用している言語等 : Ruby(2.7.2), JavaScript(+Jquery), Ajax, Bootstrap, CSS, HTML - インフラ : Heroku - データベース : Postgresql - 開発ツール : GitHub, SourceTree - 画像ストレージ : AWS-S3 ⬛️ 　開発をする際にに工夫したところターゲットユーザーはどんなコンセプトで作ろうかでした。いくら良いサイトを作っても、それを利用してくれるユーザーがいないと無駄だと思ったからです。そいった点をしっかり決めてから、設計をして開発に着手しました。 ⬛️ 　開発作業を行う際に大変だったところ必要な機能が増えてしまってデータベースに項目を追加したり削除しなければならない状況が非常に多く発生するということでした。それによってプロジェクト全体の工数が増えてしまった経験があります。このように最初に設計したものと違いが発生してこの違いを減らすための設計とその違いを早めに把握する能力が重要だと実感しました。 ⬛️ 　今回の個人開発を通してよかったところ WEBサービスを作りたい気持ちでRailsを最初から独学で勉強してある程度の機能を備えたWEBアプリを2ヶ月で作ることができましたので他の言語でも頑張って勉強して必要な部分を勉強していけば学習には問題ないという自信感を得ることができました。そしてこれからの開発業務にも必要な知識や情報を吸収して行こうと思うようになりました。
Oct 2020 - Dec 2020
受発注システムのスクラッチ開発
【業務内容】オフィス家具メーカーI社の受発注システム開発【担当フェーズ】 - 新規開発全般（サーバサイド）　(アジャイル/スクラム) - 新メンバーのフォロー【開発内容】開発・実装① 【概要】テストのためのダミーデータの準備および自動テストコードの作成【どのような機能の開発・実装か】「H2」という内蔵DBを使う形で、正常系、異常系に分けてそれぞれのAPIの動作を確認しました。プロダクトに想定以外の事象がないかを確認するための実装です。【課題・問題点】パターン漏れやテストケースが難解で見る側がわかりにくい問題がありました。【打ち手・使用した技術】テストシナリオを設計してチームに共有してフィードバックを頂いた後に実装して漏れがないようにしました。特にテストパターンの作り方について周りの先輩エンジニアに質問したりして身につけるように努力しました。また、何の目的でテストするのかどのようなポイントをテストしたいのかを見る側も分かりやすいように設計しました。開発・実装② 【概要】検索APIの設計、実装【どのような機能の開発・実装か】家具の発注状態を検索するためのAPIで各種配送状態、決済状態等、物流全般の情報が含まれます。【課題・問題点】仕様を完全に理解せずに開発して手戻りが頻繁に発生し、約束した納期に間に合わない問題が発生【打ち手・使用した技術】仕様に対する理解不足を解消するため、物流プロセスに関する書籍を読みながら勉強する手戻りを減らすために作業前にやることを先に洗い出して作業を進む（レビューをいただく）。開発遅延の原因を解るように「なぜなぜ分析」を行う。【開発環境】 Java | Groovy | SQL | Micronaut | Spock | Git ＆ GitLab | Docker | PostgreSQL 【メンバー数】４名（発注チーム）【役割】プログラマー主なタスクとしてはプロダクトオーダー（PO）からの仕様説明を徹底的に聞いて仕様どおりにAPIの内部ロジックを実装、またはビジネスロジックの自動テストのためのテストコードを作成する役割でした。【仕事を通して学んだこと】 (1) 課題を見つけ、解決のためのプロセスを選択し、新しい価値を生み出すこと。日々やることはスプリントプラニング段階で詳細化しておくため、かなり明確ですが、私が担当した教務以外にもDBでの無駄なSQLが乱立して性能が低下されたり、ジャンクインサートの速度の問題点を見つけて、その単位を1000行ずつ読み取る形に変えたりしてアプリケーションの性能に貢献できるようにしました。この過程で公式ドキュメンタリーを参照して解決するように努力しました。(OpenCSV、Micronautなど) それらを読み込んでからコードを書き始めましたが、分からないところが沢山ありましたので日本語、韓国語、英語を問わずグーグルで調べながらコードを書きました。 (Qiita、stackoverflowなど) 自力で解決できそうにない問題である場合もすぐに諦めることではなく、開発リーダーやシニアエンジニアに質問し、工数を減らすことと共にアプリケーションのクォリティを上げることに貢献できるようにしました。 (2) 日々、スキルを伸ばす努力毎日必要な部分を自習しておりますので、個人的に技術的な疑問や提案があれば共有して皆が見られることができた方が良いと思い、プロジェクトマネージャに提案しました。結果的にスラックのチャンネルが作られて全ての開発メンバーが必要な内容を質問したり回答したりすることができるようになりました。【仕事で大変だったこと】開発作業を行う際に大変だったところは、開発側と設計側の認識のずれに伴い、仕様が大きく変わったり、影響を及ぼす範囲が広くなって工数が増えてしまったりしたことでした。また、実際に開発を始めないとどれくらい時間がかかるのかそれを開発に着手する前に把握するのが難しかったのですごく勉強になりました。下記の解決方法をTryとして実行していきたいと思います。過去の作業時間を振り返って逆算して所要時間を出す。全体会議や無駄話で時間が延びる時があるので少しのバッファを追加する。タスクを詳細化する際に全員と話しをすることで見積もりに甘いところを見つける可能性が高めること。
Feb 2020 - Dec 2020