- AWSは7年間使ってきましたので、基本的な使い方にはまず問題ないかと思います。
- 言語ではJavaScriptの扱いが現時点では一番慣れています。そのほかElixir, Scala, Ruby, PHPもそれなりに扱えます。
- WebフロントエンドはReact.jsに慣れています。
- Web API開発が最も得意です。
開発時期は明記していません。
NetFrontなどの組み込み向けWebブラウザの開発を中心にさまざまなソフトウェアやサービスを開発している会社です。 SI案件も扱っております。
いろいろな案件で共通で使えるBaaSシステムの開発に途中からジョインしました。 データの保存や通知・メールなど基本的な機能を簡単に利用できるようにするためのシステムです。 テナントの管理や階層権限などの機能も備えていました。 かなりきれいに構築・実装されていたこともあり、私自身は基本的に勉強させていただくことがほとんどでした。 珍しい点としては開発メンバーは自分以外のPRをすべてレビューするというルールがありました。
- DB: MongoDB
- 言語: Scala
- Webフレームワーク: Play Framework
- アプリケーションアーキテクチャ: MVC
- インフラ: AWS
- Amazon EC2 + Auto Scaling
- Amazon S3
- Amazon CloudFront
- Amazon SQS
- Amazon SNS
- Amazon SES
- AWS STS
- 決済機能: Stripe
- CI: オンプレのJenkins
- テスト: ユニットテストと機能テスト
- スクラム開発(具体的な名前を覚えていません...)
- Redmineによるチケットベースの開発
- チーム人数: 5-6人
- リーダー: 1
- メンバー: 4-5 (自分はここ)
入社して間もないこともあり、Web FrameworkやRESTに関する知識を一から詰め込んでいきました。 覚えなければならないことが非常に多く、それを覚えることやチームの動きについていくことで精一杯でした。 幸いリーダーの方が非常に優秀な方であり、タスク分割を細かくしたりやコーディングをする上で気にしなければならない細かい箇所なども叩き込んでいただきました。 レビュアーの負担を減らすことが如何にチームの生産性を上げるかなどを学ぶ良い機会となりました。
中規模の動画配信システムのリプレース案件に途中からジョインしました。 もともとは半年で完了する計画の案件でしたが、最終的には2年以上を費やす結果となりました。 リクエスト数はおそらくピークで一日100万PV、通常時は20-30万PVでした。 わかりやすい貢献としては「Nginxによるキャッシュサーバーの実装」と「AWSの月額費用を100万から40万に削減」です。
- DB: PostgreSQL
- 言語: PHP (5.5 or 5.6)
- Webフレームワーク: サイト側はなし、管理画面はYii PHP Framework
- アプリケーションアーキテクチャ: なし
- インフラ: AWS
- Amazon EC2
- Amazon RDS
- メールはオンプレサーバー
- キャッシュサーバーはNginx
- 動画配信はオンプレサーバーとSilverlight
- フロントエンド: jQuery
- 決済機能: (忘れてしまいました...)
- CI: なし
- テスト: なし
- Redmineによるチケットベースの開発
- チーム人数: 最大50人
- 外注チーム: 20-30人ほど
- マネージメント: 5人ほど
- インフラをマネージメントする人やアプリケーションのマネージメントをする人、全体をマネージメントする人など各階層にマネージャがいました。
- 基本的には開発メンバーとして開発をしていました。
- 一時期はインフラチームのマネージメントを任されましたが、最終的には力不足により結局は開発メンバーとして開発をしました。
正直に言えば、自分自身はエンジニアとしての知識や経験が不足していたこともあり、この案件で劇的な貢献はできませんでした。 自身に対して課せられた作業に関してはそれなりに期限を守って完遂させたとは考えておりますが、全体としては作業が遅れに遅れていたので視野の狭い状態で作業をしていたと思います。 キャッシュサーバーの構築やバッチ処理の処理時間の改善、インフラの無駄な部分を整理することによる月額費用の改善などはそんな中でも全体を助けることに貢献できたと思います。 バッチ処理の処理時間の改善は大学時代に数値計算の研究をしていたこともあり、時間計算量を改善することで対処しました。処理方法をO(n^2)からO(nlogn)に改善しました。
ドアの開閉センサーを取り付けて、それによってトイレの利用状況を可視化するアプリケーションを開発しました。 開閉センサーの状態を通知するクライアント側は他社様のご担当だったため、サーバーとWebアプリケーションの開発をしました。
- 内製PaaS + BaaSシステムを利用
- PaaSシステムの概要
- DB部分: BaaS
- 言語: Elixir
- Webフレームワーク: Phoenix Frameworkライクの独自フレームワークをクライアントに提供
- インフラ: Amazon EC2 + Auto Scaling
- 分散合意アルゴリズム: Raft
- CIの機能も提供
- BaaSシステムは上記のもの
- PaaSシステムの概要
- 言語: Elixir
- アプリケーションアーキテクチャ: MVC
- フロントエンド: jQuery
- テスト: ユニットテストと機能テスト
- Redmineによるチケットベースの開発
- チーム人数: 2人
- リーダー: 1
- メンバー: 1 (自分はこちらです)
フロントエンドに関する知識が非常に乏しかったため、その辺に関しては実装面で非常に苦労しました。 またCORSなどに関しても当時は知らなかったため、jQueryによるajax処理がうまくできるようになるまでとにかく調査したり、先輩に尋ねたりしてなんとか解決をしていきました。 サーバーサイドの実装に関しては今までの経験もあり、それなりに思った通りに実装できるようにはなっていました。
EPUBのアプリケーションで利用する検索サービスを開発しました。 Elasticsearchを社内でも本格的に利用するのが初めてだったため、 ドキュメントだけでなく理論の部分も調査しました。 ハイライト検索をするためのElasticsearchのプラグインの開発もしました。
- 内製PaaS + BaaSシステムを利用
- 言語: Elixir
- アプリケーションアーキテクチャ: MVC
- DB: Elasticsearch
- インフラ: Amazon EC2
- テスト: ユニットテストと機能テスト
- Redmineによるチケットベースの開発
- チーム人数: 3人(途中から2人)
- リーダー: 1 (後に自分がリーダーとなりました)
- メンバー: 2 (=> 1)
Elasticsearchの特性を理解することには非常に時間を費やしました。 パーティションやプライマリー・セカンダリーなどのデータベースの概念などを初めて学びました。 また分散データベースにおけるクオラムやスプリットブレインなどの概念も初めて学び、RDBと比べて分散データベースが抱える根本的な問題などを知る機会となりました。 途中から開発リーダーになった段階で、チケットベース(Redmine)の開発におけるタスク分割やマネージャー陣への状況報告において、ガントチャートをきちんと構築する必要性なども学びました。
気圧ビーコンを用いて作業者の高さを検知して、危険状況を察知するシステムの開発をしました。 モバイルアプリは社内の別の方が担当されたので、サーバー側の開発をしました。 工事現場で実際に測定できるかどうかの調査などもしました。
- DB: Azure Cosmos DB (ローカルはMongoDB)
- 言語: JavaScript, Node.js
- Webフレームワーク: Express
- アプリケーションアーキテクチャ: MVC
- インフラ: Azure
- WebApps
- WebJobs
- ActiveDirectory
- フロントエンド: React.js, Redux
- その他利用技術
- JSON Schema
- チーム人数: 3人
- 役割: 開発メンバー
Webアプリケーション全体を一人で開発しました。 初めてReactとReduxを導入したこともあり、フロントエンドの実装に関して多くを知る機会となりました。 コードの責務分けなどの知識がこのころにはなかったため、あまり読みやすいコードにはなっていませんでした。 しかし、Reduxを強引に導入したことによりテストのしやすさに関しては実装をしてみて実感できました。
Azureに関しては現在も詳しく把握はできていませんが、WebAppsなどのPaaSシステムを使う判断を早々にしたことにより納期を間に合わせることができました。(開発者としてはもっと調査して詳しくなる機会を失っているので現在ではおしいことをしたように感じます。)
モバイルアプリとの連携に関しては設計段階できちんと仕様の準備をしたので、繋ぎこみは問題なくできました。 仕様はSwagger(Open API)を使って作成しました。
デジタルサイネージサービスの機能追加や保守作業に途中からジョインしました。
- DB: PostgreSQL (ローカルはSQLite)
- 言語: Ruby
- Webフレームワーク: Ruby on Rails
- アプリケーションアーキテクチャ: MVC
- インフラ: IIJ GIO
- フロントエンド: Dojo Toolkit
- CI: なし
- テスト: メンテナンスされていない状態が放置(知識不足・予算不足のため私も修正できませんでした)
- チーム人数: 2人
- 役割: 開発メンバー
本格的にRailsに触れる良い機会となりました。ただしバージョンは古いものであったため、2020/07/21現在においては古い知識になると思います。 Capistranoによるデプロイなども経験しています。
インフラ面においては現在ではあまり使われていないとは思いますが、Linux-HAや仮想IPなどを駆使したDBクラスターの構築がされており、 そういった技術があるということを知る良い機会となりました。
ファイル共有システムとしてRedmineサービスの提供とKibanaによるログの可視化をするシステムを開発しました。
- Redmineの機能追加をソースの変更を含め実施
- 言語: Ruby
- Webフレームワーク: Ruby on Rails
- インフラ: AWS
- Amazon EC2
- Amazon S3
- Amazon CloudFormation
- AWS CodeCommit
- 利用状況の可視化: Logstash + Elasticsearch + Kibana
- CI: なし
- テスト: なし
- チーム人数: 2人
- マネージャー: 1
- 開発メンバー: 1
本格的にCloudFormationを使用したIaCを実施しました。初めは手動でインフラの構築をして、現在の状況からCloudFormationのテンプレートを作成する手法をとりました。 この経験により、VPCやネットワークのルーティングなどAWSの基礎的な部分をよりよく知る機会となりました。
アプリケーションの開発においてはRedmineのPluginの作成やコード本体の修正などをして、OSSのコードを読む良い機会となりました。
ElasticsearchとKibanaによるRedmineの操作ログの可視化をして、ダッシュボードの作成も実施しました。
カメラや心拍計などで取得した生体情報をミラーディスプレイ上で可視化するシステムを開発しました。 センサーを用いたデータの取得・アップロード部分は社内の別の方々が開発しています。 データの蓄積をするサーバーの実装を担当しました。 データを可視化するWebアプリケーションに関しては外注でした。そちらに関してはレビューと一部マネジメントだけ実施しました。
- 前述のPaaS,BaaSをオンプレ環境のDocker上で動かすようにさまざまな修正をPaaS,BaaSに対して実施
- 言語: Elixir
- アプリケーションアーキテクチャ: MVC
- インフラ: オンプレ
- CI: なし
- テスト: ユニットテスト
- チーム人数: 10名
- 役割: データ蓄積サーバーの開発リーダー
内製のBaaS, PaaSシステムをDocker上で動かすためにシステムの起動時の初期設定を拡張するような変更をコミットしました。
またDockerイメージを構築する上で、シェルのアタッチなどをして如何にイメージの構築を効率化していくかなども学びました。
データ蓄積サーバーのAPI仕様をSwagger(Open API)で作成して提供したことにより、データ送信側との連携は比較的うまくいったと思います。 ただデータの可視化をするフロントエンド側(外注)との連携は、自身のマネージメントの実力が足りず結果としては自分のマネージャーに力を借りることとなりました。 データ蓄積サーバーは納期までに完成させたのですが、フロントエンド側の完成に至らず、こちらに関しても全体をみる視点が欠けていたと思われます。
開発時期は明記していません。
キャンセル料が発生する宿泊権利を他の人と売買するWebサービスを運営している会社です。
細かい作業なども多いため、主だった内容だけ記載します。 またさりげない貢献内容として、AWSの月額利用料を20万から15万に削減した実績があります。
- APIサービス、Webアプリケーションサービス、管理サービス、バッチ処理サービス、DBサービス
- アプリケーションアーキテクチャ: MVC (一部はレイヤードアーキテクチャを導入)
- インフラ: AWS
- AWS ECS Fargate
- Amazon EC2
- Amazon RDS
- ドメイン・CDN: Cloudflare
- フロントエンド: React.js、Redux
- 利用している外部サービス
- Algolia
- Stripe
- Google Hotel ADs
- Google Analytics
- Amplitude
- ...(サポート関連も含めると多岐にわたる)
SEO対策のためページの表示スピードを速くする必要があり、SSRを導入しました。 当時はビルド周りの設定にあまり明るくなく、Next.jsなどを導入できないと思ってしまい、 自前でのSSR実装となりました。 その後フロントエンドに詳しいメンバーの調査でNext.jsを導入できると判明したため、 現在はNext.jsが使われています。 目的を達成できたこと自体は当時はうれしかったのですが、 エンジニアとしてはもっと調査・勉強しておけばよかったという反省もあります。
Web API内で処理をするには時間のかかる処理があったため、Workerを導入しました。 Amazon SNSにジョブを投入し、Workerがポーリングしてジョブを実行するようにしました。 今にして思えばもう少しManaged Serviceを利用できるか検討して良さそうに思いました。
- インフラ: AWS
- AWS ECS Fargate
- Amazon S
- 言語: JavaScript, Node.js
- CI: なし
- テスト: なし
Webサービスのグローバル化に伴い、多言語対応や様々な通貨の対応などの実装を進めました。 その中でも通貨の換算や海外への送金などについての実装を主に担当しました。
- 通貨の換算処理
- 為替に関する情報はOpen Exchange Ratesから取得
- ユーザーに通貨の設定を用意してその通貨に応じて宿泊プランの料金を表示
- に必要な換算元通貨をうまくまとめてOpen Exchange RatesへのAPIリクエストをなるべく一度にすませる
- ユーザーが購入ページで見ている値段と実際の購入処理時の為替の値が変わってしまって買ったときに1円の誤差が出てしまう問題への対処法
- 凝った実装をする余裕がスケジュール的になかったので、ユーザーへの注意文言で対処しました。
- 送金サービス: Payoneer
- 海外にある個人の口座にも送金する必要が出てきて、Stripeの縛りにより送金ができないことが判明
- いろいろなサービスを調べて、最終的にはPayoneerで思った通りのシステムを構築できました。
- 実はその前にTransferwiseでできそうだったので実装を進めていたら、最後の最後でヨーロッパの法人しか使えませんと言われてしまい実装を破棄しました。
- もともと送金周りのコードはテストがやりにくい箇所に書いてあったので、それを裏側のAPIサーバー側に移してテストで保護できるような工夫もしました。
アプリケーション全体をリファクタリングする余裕が出てきた時期があり、リファクタリングするにあたって今までちゃんとテストできていなかった部分をテストすることになりました。 購入・送金周りの処理は問題がないようにしっかりテストしたいということからE2Eテストの導入が決定し、実装や環境構築を担当しました。
- TestCafe, Cypress, Puppeteerの3つを調査し、テストを書く上でもっとも読みやすくモダンな書き方ができるTestCafeを採用しました。
- Dockerfileを2つビルドしてからテストを実施する必要があったため、ECRとCircleCIの連携をする必要があった。
- GitHub Actionsを使えないかいろいろ調査をしましたが、ECRのDockerイメージを使ったコンテナの起動ができなかったため断念しました。
- 今にして思うのはAWS Codebuildを利用しても良かったかと考えています。ただし実現できるかどうかは未調査です。
- コンテナのビルドやテストに時間がかかるため、ステージングにデプロイするためのブランチに対してだけE2Eテストを実施するようにしました。
Cansell社として新たなサービスの開発をしています。 管理画面側の実装を担当しています。
- AWS Amplify
- Cognito
- AppSync
- API Gateway
- Lambda
- DynamoDB
- Aurora Serverless
- CloudFormation
- S3
- CloudFront
- 決済機能: Stripe
- 管理画面: React
- モバイルアプリ: React Native
Amplifyが自分たちのユースケースに合っているのかを判断するための調査に非常に時間をかけました。 また最終的にはカスタマイズしていけばなんとか構築できそうと判断しましたが、実際はユニットテストを実施する環境の構築に手間がかかりすぎるため、 現在はユニットテストの環境を構築できていません。 このことが開発のスピードを遅らせているように日々感じておりますが、リリース日を優先してほしいという要望があるため、改善できておりません。
しかし、現状のインフラやアプリケーションの構造はある程度Amplifyの規定に則った形で実現できているため ステージング環境やパフォーマンステスト環境の構築は今後簡単にできるような状態までは持っていけました。
雑多にやっていることを上げておく。後ほど整理する
開発は5人
- Rails Upgrade 5.1 => 5.2
- ArgoCDによるカナリアリリースも実施
- CoffeeScriptからTypeScriptへの移行
- 第一ステップとしてJestの導入をしてTypeScriptのテストを書くようにした
- Sentryのエラー整理
- 無視して良いものは無視
- 他のチームの管轄なら任せるように設定を変える、通達する
- ホワイトリスト設定(をしたい)
- その他まだまだいろいろあるはず
- SRE的な動き
- エラーの対応を徹底する
- 無視して良いものは徹底的に無視
- 自動化できるものは対応を自動化
- 頻度が多くないし、修正コストが小さくないものは手動対応でいくが必ずランブックを残す
- エラーの対応を徹底する