monkey

## 課題 弊社では購入者のために決済方法を多数用意しているが、 各決済方法によって決済事業者に支払うべき手数料率は大きく異なる。 今回導入を行った決済方法は現在利用可能な他のものと比べて格段に手数料率が低く、 利用者が増えることで利益率の向上が見込める。 また独自の経済圏を持つ決済方法であるため、 特定の決済方法を積極的に利用したいユーザーの購入を促し、 トップラインの純増にもつながる。 ## 担当した業務 ### 要件定義 企画は弊社のプロダクトマネージャーが担当。 自分は本プロジェクトにテックリードとして参画。 本工程においては、業務フロー作成並びにシステム設計を担当した。 ### プロジェクトマネジメント 本プロジェクトではスクラム開発を採用。 自分を含めたエンジニア3名、プロジェクトオーナー1名のチームにて、 スクラムマスターの立場から指揮をとった。 ### 設計・開発 設計プロセスでは要件定義を元に、 データモデリング・クラス設計、シーケンス図作成を実施。 実装は Ruby on Rails で作成された既存の Web アプリケーションを拡張。 決済画面への新規決済方法の導線追加、 決済指示、確定、変更、キャンセルに伴う REST API 開発がメイン。 各 API の処理は自社アプリケーションで必要となる各種データの更新処理（在庫の増減や、売上操作など）や、 決済事業者との通信を行う処理を含む。 一部決済事業者とのやりとりにおいては非同期処理を行う必要もあり、 その処理に関しては Redis + Resque を利用したジョブの開発も発生した。 ### 運用・保守 運用監視を目的として Bugsnag を利用。 エラー発生を常時モニタリングし、調査・修正対応を行う。 追加した決済方法の売上をモニタリングし継続的な効果測定を実施。 分析用に用意した Bigquery 上のデータを利用して、 Redash, Looker を利用したクエリ、ダッシュボードを作成。 ## アピールポイント ### スクラム開発 前プロジェクト（EC サイトにおける新規配送サービスの提供）に引き続きスクラム開発を採用。 具体的な実施内容や、採用したことによる効果については上記プロジェクトの項を参照。 前回からの変更点としてはスプリントの長さを1週間から2週間に伸ばしたことが挙げられる。 スプリントの長さが1週間だと1回のスプリントでは終わらないストーリーが多く発生し、 ベロシティの値が安定しなかったことの反省を活かした。 この変更により本プロジェクトでは継続的に一定のベロシティを出すことができ、 チームのモチベーションアップや、リリーススケジュールの正確な予測に繋がった。 ### 設計のドキュメント化と共有 本プロジェクトで作成したデータモデリング、クラス設計、シーケンス図は UML などを使って資料化。 エンジニアメンバー3名の間で共有を兼ねたウォークスルーレビューを数回行った。 このことにより以下のような効果があった。 * 各開発担当が事前に設計を十分に理解することで、スムーズに開発に入ることができた。 * エンジニア間における認識齟齬がなくなり、手戻りはほとんど発生しなかった。 結果としてプロジェクトは遅延なくリリースに至ることができた。 ### アプリケーションの拡張性向上 本アプリケーションでは決済方法の追加を年に一度程度のペースで行っており、 高い拡張性を保つことが非常に重要な非機能要件の一つ。 これまでに追加した決済方法は、 決済事業者が用意した決済方法毎に個別のインタフェース、 エンドポイントを持つ API を利用することで実装されていた。 このため拡張性に乏しく、決済方法の追加のたびに多くの工数が発生していた。 今回新規に追加した決済方法については従来の API の利用を止め、 決済方法によらず共通のインターフェースを利用できる新しい方式を利用するよう変更。 これに伴い自社アプリケーション側も継承を使ってポリモーフィズムにクラスを設計。 今後の決済方法の追加を見越した拡張性の高い設計を行うことができた。 来年度にはさらに決済方法の追加を検討しているが、 その開発工数の見積もり結果によると工数は従来の1/3に抑えられる見通し。

## 課題 開発を担当する CtoC 向けECプラットフォームでは出品者から購入者への商品の配送が都度発生する。 出品者は配送業者と個人的に契約をして配送を行うのが基本的なフローではあるが、 我々が配送業者との契約を行ってこれをサービスとして出品者に提供すれば、手数料収入を得ることができる。 また我々は法人として大口で配送業者との契約を行うため、 個人契約した場合と比べて安い料金での提供が可能となる。 これは利用者側にとっても大きなメリットにつながる。 ## 担当した業務 ### 要件定義 企画・立案はビジネスチームが担当。 自分は本プロジェクトにテックリードとして参加。 ビジネスチームへのヒアリングを通じて要件定義、システム設計を担当。 また、配送業者の API 利用、請求データ等のファイル連携が発生するため、 対向先企業と IF 仕様の検討等を共に行った。 ### プロジェクトマネジメント 本プロジェクトではスクラム開発を採用。 自分を含めたエンジニア3名、プロジェクトオーナー1名のチームにて、 スクラムマスターの立場から指揮をとった。 ### 設計・開発 マイクロサービスアーキテクチャを採用。 追加されるサービスの根幹をなす配送システムは、 モノリスとなっている本体アプリケーションから独立したアーキテクチャとして開発。 フロントエンドは基本的に Rails の .erb テンプレートエンジンを利用。 複雑な UI の実装のために部分的に React を利用した。 バックエンドは Rails を利用。 配送データの作成、更新、参照などの API 開発が主。 各 API は連携先配送業者との通信を行う処理を含む。 一部 AWS EventBridge + SQS + shoryuken を利用したスケジューリングタスクの開発も発生した。 ### 運用・保守 運用監視を目的して Bugsnag, Datadog を利用。 継続的なバグ、パフォーマンスのモニタリングを行い、 サービス提供後の安定した稼働のための修正、改善を行なっている。 またカスタマーサービスを通じた顧客からの問い合わせにも柔軟に対応を実施している。 加えて自分が配送サービスを含むマイクロサービスアーキテクチャをオーナーとして管理しており、 Rails のバージョンアップなどの改善タスクの計画、実施までを継続的に担当している。 ## アピールポイント ### スクラム開発 自分を含めたエンジニア3名とプロジェクトオーナー1名のスクラムチームを構築。 1週間を1スプリントとしてスクラム開発を行った。 自身はチーム内でもスクラムマスターとプロジェクトオーナーの補佐の役割を果たした。 具体的な担当業務としては以下を行った。 * チケットの作成、およびストーリポイントを使った工数の見積もり * スプリント計画、デイリースクラム、スプリントレビューのファシリテート * エンジニアに対する設計・開発の補佐や助言、プロジェクトオーナーとの窓口としての対応 本プロジェクトにおいてはスプリントによる短期的なリリースサイクル、 これに加えて社内ユーザーを対象としたカナリアリリースを組み合わせることで、 効率的なフィードバックサイクルを実現することができた。 このことは開発中の手戻りや、 リリース後の不具合の発生を未然に防ぐことに大きく貢献している。 また JIRA を利用してプロダクトバックログ、スクラムボードを作成し、 各種レポート機能を活用したプロジェクト管理を行った。 進捗状況やスケジューリングの見える化が実現でき、 本プロジェクトの各ステークホルダーからも安心して案件を進めてもらえたという評価を得ることができた。 ### アプリケーションの拡張性向上 元々本ECサイトは既に1社の配送業社との連携を実現していた。 従って本プロジェクトは2社目のサービス連携となる。 加えて将来的には更に多くの配送業社との連携を予定しているため、 高い拡張性を確保することが重要な非機能要件の一つであった。 本プロジェクトでは主に以下の工夫を行うことで、 拡張性の高いアプリケーションを実現することができた。 - 配送データのモデルは Single Table Inheritance を使って作成する。 - テーブルは共通化しつつも外部連携部分など特化すべき機能は 抽象メソッドと擬似クラスの具体メソッドで実現。 - 利用する配送サービスによらず共通の API を利用できるような IF 設計を行う。 ### Ruby および Rails のバージョンアップ 配送サービスを含むマイクロサービスアーキテクチャでは、 フレームワークやライブラリのセキュリティパッチの取り込み、 アプリケーションの高速化、さらにDX 向上を目的として、 半年に一度程度の Ruby, Rails の定期的なバージョンアップを行なってきた。 これまでに実施したバージョンアップ作業では、 以下のように Ruby, Ruby on Rails のバージョンアップを行なっており、 今現在では最新のメジャーバージョンを利用することができている。 - Ruby - `2.6.5` => `2.7.2` => `2.7.6` => `3.0.4` - Rails - `6.0.2` => `6.1.3` => `6.1.6` => `7.0.8`

## 課題 自社開発を行っている EC サイト、キュレーションメディアの開発環境は従来 Vagrant を利用して構築されていたが、 仮想環境として利用している Virtual box が当時 M1 Mac 上で利用できない状態となっていた。 自社ではエンジニアに対して Macbook が貸与されているが、 Intel 製 chip を搭載した PC が販売終了となったため開発が行うことができなくなってしまった。 本プロジェクトでは開発環境を Docker を利用して再構築した。 （なお、このプロジェクトは自社の20%ルールの時間を使って、普段の業務外の事業として行った。） ## 担当した業務 ### 設計・開発 #### EC サイト開発環境 Ruby on Rails 並びに PHP を利用したアプリケーション実行コンテナ用 Dockerfile の作成。 docker-compose を利用した開発環境の構築。 DB は AWS 上の EC2 に構築されたデータベースサーバを利用した。 開発環境は以下のアーキテクチャで構成される。 * Web コンテナ（nginx） * アプリケーション（Ruby on Rails x1, PHP x1） * KVS（memcached x1, Redis x1） * DB（SQL Server, MySQL 複数、ローカル上の Docker ではなく、AWS 上の EC2 で構築されたサーバに接続。） * ジョブ実行環境（Sidekiq x1, Resque Worker x1） * CI 環境（Rails & Spring） 構成図: https://app.diagrams.net/#G1kyZVM8lEyJ02bj_xRf-vleEPQZrAklIY #### キュレーションメディア開発環境 Ruby on Rails を利用したアプリケーション実行コンテナ用 Dockerfile の作成。 docker-compose を利用した開発環境の構築。 開発環境は以下のアーキテクチャで構成される。 * Web & アプリケーション（Ruby on Rails） * KVS（Redis） * DB（MySQL） * ジョブ実行環境（Sidekiq） * CI 環境（Rails & Spring） * Openapi Doc（swagger） 構成図: https://app.diagrams.net/#G1kyZVM8lEyJ02bj_xRf-vleEPQZrAklIY#%7B%22pageId%22%3A%226QkmSOy3IhCpPY6xAvwi%22%7D

## 課題 弊社で運用している Web アプリケーションは基本的には Rails で実装されているが、 開発当社に採用されていた PHP で実装されているコードが一部残っている。 PHP 実装が残る部分はダブルメンテが必要であることや、 そもそもコードの可読性が低く、保守性の低下を招いてしまっている。 本プロジェクトでは PHP 実装の廃止と Rails 移行の一環として、 購入者向けページの一部のマイグレーションを実施した。 ## 担当した業務 ### 設計 現存する PHP 実装をリバースエンジニアリングしてドキュメント化。 移行が必要な機能の洗い出しを行った。 ### 開発 移行先のアプリケーションは Ruby on Rails で実装。 フロントエンドは基本的に Rails の .erb テンプレートエンジンを利用。 動的な UI の実装のために部分的に JavaScript を利用。 バックエンド側は Rails を利用した API の実装。 本プロジェクトで担当した画面は参照系の機能のみ有するページ。 参照するデータは DB と Solr を利用した検索サーバから取得。 またレガシーコードでは不要なデータアクセスが行われている箇所があったため、 パフォーマンスのチューニングを実施。 改善結果は New Relic の APM と、 Google lighthouse の SEO チェックを確認して評価。 ### テスト レガシーな PHP の実装では自動テストがなかったため移行後の Rails 実装では RSpec を作成。 System Spec, Request Spec, Model Spec を作成した。 ## アピールポイント ### 仕様書のリバースエンジニアリング 現存しているコードは仕様書が存在しておらず、 仕様を把握するのが非常に難しい状態になっていた。 今回の対応ではソースコードを解析し、 仕様を改めて書き起こして社内 wiki 内にドキュメントを展開した。 これによりエンジニアの調査コストの削減ができ、 またビジネスチームも簡単に仕様を把握することが可能となった。 ### パフォーマンスの改善 ログの確認や New Relic を利用した解析を行なった結果、 検索サーバーへ繰り返しアクセスしている箇所が処理のボトルネックとなっていることがわかった。 今回の場合では取得するフィールドの再検討や、 facet を利用した検索サーバー側での集計処理を利用することで、 大幅にリクエスト回数を削減することができた。 結果として平均レスポンス時間を半分程度まで削減することができた。

## 課題 弊社では Zendesk を利用したカスタマーサービス業務の効率化を図っている。 問い合わせフォームからの投稿を API により Zendesk 側に連携、 以降の顧客とのやり取りを Zendesk にて行なっている。 本業務の効率化のため Zendesk アプリを利用し、 EC サイト側のデータベースに保存されている取引・商品・会員情報の参照、 一部情報の作成、更新、削除等を行えるようにする。 ## 担当した業務 ### 開発 Zendesk にデプロイするクライアントアプリケーションは、 ネイティブ部分は ZAF (Zendesk Application Framework) を利用。 画面の実装自体は React + Redux + Redux saga で実現。 EC サイト（サーバサード）側にはデータの参照・作成・更新・削除の API の実装を行なった。