ID:64619さん

背景

所属している会社のWebサービスで、新しい機能としてリリースされる箇所だけは既存のVue.jsで作られているところと異なり、Svelte.jsを導入することが決まっていた。まだ実験的なコードしかなく、同時にテストがない状態からデザイナーが残しているFigmaを元にフロントエンドのWebサービスを構築した。

工夫したこと

フロントエンドでありがちなviewにビジネスロジックがこびりつく設計を極力避けた。それによりいつかSvelte.jsではない他のフレームワークに切り替えることになったとしてもすぐに対応が可能なフロントエンド構成ができたと思っている。

また、初めにあった実験的なコードのまま進めるとコードが凝集度の低いものになることが予想できたため、入社してからの3週間でコードの関係を高凝集に書き換え、同時にこの方針で開発を進めることを安心、納得してもらうためにテストを600件書いた。その後GitHub Actionsを使いCIを運用することを提案し、PRはテストが通っていないとマージできないようにバックエンドも含めてワークフローを整備した。その後、フロントエンドの拾いきれていないエラーを拾うことを目的としてエラートラッキングシステムの導入を提案し、DatadogとSentryの両者を挙げADR(Architecture Decision Record)を用意しSentry導入の意思決定まで持っていった。

現時点も継続しているプロジェクトだが、テストは半年強で2,000件を超えた。

感想

自分が担当している部分レビューも担当しているため安易なコードの進入を防いでおり、コードの堅牢性が高い。それはシステムの安定性を高めるという意味においてはよいのだが、厳しすぎるレビューはメンバーの亀裂を産むことにもなるのでうまい伝えかたをこれからは模索していかなければと、少しばかりコード以外のほうに対しての思うこともできてきた。

得た技術

• 言語
  • TypeScript
• フロントエンド
  • Svelte.js
  • Sveltekit
• その他
  • Rollup.js
  • Jest
  • Vitest
  • Docker
  • GitHub Actions
  • Sentry
• 設計思想
  • DDD
  • Clean Architecture

担当業務

• 設計
• 実装
  • フロントエンド
• テスト
• 追加設計
• 運用保守

背景

当時所属していた会社では、ストレージとしてブロックチェーンを採用していたが、チェーンのSaaSを使用せずに自分たちでホスティングしていた。そのブロックチェーンは2か月に1回程度破損するうえに、レプリカをとっていても完全には復帰できないという極めて可用性の低いものだった。そんな問題がありあるSaaSのブロックチェーンを使ったサービスを用いて既存のシステムをリプレイスした。

工夫したこと

ブロックチェーンの破損のしやすさを目の当たりにしてストレージに対する不安感が強かったため、他SaaS、ストレージに乗り換える可能性を常に視野に入れ、コードを全体的にClean Architectureに変更しストレージの責務をリポジトリに寄せることでストレージの変更がビジネスロジックに影響を与えないように変更に強いサービスを設計、実装した。

感想

当時は早く社を辞めたい事情があり完成を急いでいた。退社後仲の良かった同僚にそれが使われているかというと使われていないようだった。理由としては導入した概念が難しすぎてそれを理解して運用できる他の社員がひとりもおらず、失われた技術と化しているとのことだった。こういえば聞こえはいいが、理想の理論は達成できなくても他の人が理解できる技術の採用や、理解できる後継者の育成ができる余裕のある時間確保ができればよかったのかな。とは振り返って思う。

(ひとり体制で開発させるということは多かれ少なかれ会社もそうなることを理解してのことだとは思うが)

使用技術

• 言語
  • TypeScript
  • Java
• バックエンド
  • Express
• ストレージ
  • Amazon QLDB
• その他
  • Jest
  • Docker
• 設計思想
  • DDD
  • Clean Architecture

担当業務

• 設計
• 実装
  • バックエンド
  • インフラストラクチャ
• テスト

背景

既存システムのAPIにまったくテストが書かれていないため、テストを筆記した。件数にして2000件弱。

工夫したこと

APIのドキュメントが整っておらず、またコードもすべてがfat controllerになっており実体の把握に苦労した。ソースコードから状態を解釈し、動作できるテストを作成した。

ただし、ほとんどが結合テストのようなテストになってしまったためリファクタリングする人はテストがあっても苦労するかもしれないと思ったのは心残りである。

感想

仕様も理解していない新入社員が、手が空いているからという理由だけでテストをするというのはテストそのものの信頼性に関わるということを身をもって知った。テストは仕様を知っている人、できればコードを書いた人物自体が書くべきということを痛感した。

使用技術

• 言語
  • TypeScript
• その他
  • Docker

担当業務

• テスト
  • 単体テスト
  • 結合テスト
  • E2Eテスト

背景

（以下で述べられるWiki記法とは、当時所属していた会社独自のものであり、いわゆるMarkdownなどとは異なります）

アナリストたちが自社のサービスで分析した内容を顧客に届けるにあたり、独自のWiki記法を使い文章の装飾をしていたが、そのシステムにはプレビューの機能すらなく非常に使いにくいとアナリストたちから改善を挙げられていたため、それをWYSIWYGでできるように、フロントエンドもバックエンドも、ストレージは保持したまま刷新した。

工夫したこと

フロントエンドにもClean Architectureを積極的に意識して実装した結果、ファイル構成からデータの構成がとても美しくなった。また開発もエンジニアだけでなくアナリストをドメインマスターとして交えてアジャイルの開発方式を採用し、単体、結合、E2Eとあらゆるテストを提供できた。

既存のシステム（アナリストが使用している社内サービスではなく、顧客が利用するサービスのこと）、ストレージ自体の改修はできなかったため、正規化もされていないストレージにデータを格納する部分に苦心した。だがClean Architectureを採用したことでストレージの構成による不都合をすべてリポジトリ層に封じ込め、このWebサービス内においてはあたかもキレイなストレージを触っているかのような構成にすることに成功した。

感想

私が思う限りドメインマスター（エンジニアではない専門知識がある人）は便利なものを作って欲しいとは思う一方、そこまで開発に対し協力的ではないのだが、このプロジェクトではうまく巻き込めたと思う。今後もドメインマスターが明確に存在するようなプロジェクトをするのであればこの経験を活かして積極的にプロジェクトに巻き込む、または巻き込むことを許容する社風を築いていけたらと思った。また、このときドメインマスターにいわれた「私たちは何がもっとも正解に近いのかはわからない。だが、これは正解ではないことはわかる」という言葉が個人的に刺さっている。ある程度なんでも作れるようになった今、いかにしてユーザーが使いやすいものを提供できるかが今後の課題だと思った。

使用技術

• 言語
  • TypeScript
  • Go
• フロントエンド
  • React.js (クラスベース)
  • Redux
• バックエンド
  • Gin
• ストレージ
  • MySQL
• その他
  • Webpack
  • Jest
  • Docker
• 設計思想
  • DDD
  • Clean Architecture

担当業務

• 設計
• 実装
  • フロントエンド
  • バックエンド
• テスト
  • 単体テスト
  • 結合テスト
  • E2Eテスト
• 運用保守

背景

当時所属していた会社は毎月のように新入社員がおり、いわゆる人事、総務は新入社員のためにGMailのアカウント、MoneyForwardのアカウントなど各種アカウントを手動で作らなければならない作業があった。特定のアカウントを作成し忘れたり、アカウント名を打ち間違えるといったヒューマンエラーも発生しており、これらを一括して作れるようなSlackのBotを作成した。

工夫したこと

エンジニア以外の全社員もSlackを使用している会社だったのでインターフェイスとしてSlack Botを採用した。Slack Botに作成のコマンドを投げることで一括でアカウント作成ができるようにした。また、データの保存先としてはRDBMSなどを考えたが、記入後にも社員情報が変更されることが想定できたため、人事、総務の方々が変更のためにわざわざ特殊な言語(SQL)を覚える必要がないように。という観点からGoogle Spreadsheetにした。実際入力間違いや、同名の人の衝突回避のためだったり、通称のほうがよいという新入社員がいくらかいたようで更新の需要はあったようでGoogle Spreadsheetを採用した利点はあった。

個人的にはじめて本格的にClean Architectureを採用したプロジェクトだった。このプロジェクトの段階ではClean Architectureの利点を感じることはできなかったがここで形だけでも守りファイル構成を勉強できたのはのちに活きたと思っている。

感想

新しいことが多く非常に疲弊した。Go, DDD, Clean Architectureと学ぶことが多く当時は理解せずそれっぽいことだけ形を守っていたため、終始これでいいのかと悩みながらレビュー（される側）に苦慮したりもした。現在DDD, Clean Architectureにそれなりに明るいつもりなのはこのプロジェクトを経たからであるが、このプロジェクト自体は辛い経験だった。

使用技術

• 言語
  • Go
  • GAS
• フロントエンド
  • Slack (入力受付と結果表示に使用)
• ストレージ
  • Google SpreadSheet
• 設計思想
  • DDD
  • Clean Architecture

担当業務

• 設計
• 実装
  • バックエンド
• 運用保守

背景

色々な企業のWebページに公開されているデータを収集している部署があったが、収集自体は手作業だった。たとえばある会社が毎月10日にIRをサイト上で公開しているとした場合、毎月08日くらいから毎日アクセスし更新があれば取得、記入といかにもアナログな手法で更新していた。当然ながら人力での更新の検査は非効率であったのでこれを自動化するためにWebサービスを作成した。

工夫したこと

更新の検査だけではなく、更新時に差分があれば差分を文章、スクリーンショットを撮って可視化したり、PDF等のファイルのダウンロードまでするように設計し実際にそのサイトに見に行く必要がないくらいまで自動化した。

全工程をひとりで担当した。今後の担当者が学習、設計、運用するコストができるだけ少なくなるようにUniversal JavaScriptを設計思想に採用した。当時はClean Architectureを完全に理解していなかったため、不完全な状態での再現だったがそれでもそれなりに綺麗な構造はできたと思う。自分ひとりで運用していたが、この業務の後も退社するまで継続して運用しており、他業務に当たっている最中に作業の手を止めてこちらの不具合改善をしなければいけない事態は起こらなかった。

最終的に1日で60000件超のクローリングを行う程度まで活用されていたようで、その割には問題がなく運用しやすい設計の賜物となったと思っている。

また、ひとつ前の統計情報を入力するサービスの、統計情報を入力するページにおいて新規データ取得を知れるように連携した。

感想

誰も頼ることなくすべて自分で完遂したプロジェクトとなった。ビジネスサイドの助力もなくただ「あんなこといいな」レベルの要望からWebサービス企画、開発、運用までよく達成できたと思う。また、指定された開発期間（4か月）を1か月前倒しで運用開始し、その後退社するまでひとりで（他の仕事を並行しながら）開発、運用を成し遂げたというのは今でも自画自賛したい。

使用技術

• 言語
  • TypeScript
• バックエンド
  • Express
• フロントエンド
  • React.js (クラスベース)
  • Redux
• ストレージ
  • MySQL
• その他
  • Webpack
  • Docker

担当業務

• 設計
• 実装
  • バックエンド
  • フロントエンド
  • インフラストラクチャ
• 追加設計
• 運用保守

背景

様々な企業のWebページに公開されているデータ（たとえば地域別出店店舗数など）を収集し、自社のサービスでグラフとして表示している部署があった。だがこの作業はあまり自動化されておらず、データを反映させるためにはExcelでデータ入力をし、マクロを使いCSVに変換したうえでそれを検証環境(Staging)に反映し、グラフが正常に表示されているかどうかを確認してから反映していた。検証環境で初めて自分たちが入力している内容に誤りがあるかどうかがわかるという、非常に面倒な手はずをしていたうえに、データ入力に誤りがあれば再度CSV反映からやり直しとなるという非常に効率の悪いことをしていた。

そこでデータ入力からグラフ確認、その上で問題がなければ本番環境(Production)まで一気通貫で反映するというWebサービスを作成した。

工夫したこと

初めてJavaScriptとAltJSとしてCoffeeScriptを勉強した。以降CoffeeScriptを使うことはなくなるがNode.jsの出会いとも重なりフロントエンドの学習、NoSQLなど新しい学びが多かった。

当時のVue.jsは1.x.xだったため、現在のVue.jsに適用できるような知識があるわけではないが、それまでバックエンドしかしていなかった自分にとっては衝撃的な出会いであり、フロントエンドへの入口となった。

感想

2019年にこのWebサービスの再現をしてみようと試みたところ、2週間で大体似たようなものができた。当時それなりに頑張って試行錯誤し現在の糧になっている着実に技術力が自分に身についていると実感できたことは嬉しかったが、当時の技術力ってその程度だったのかという気分にも同時になった。

使用技術

• 言語
  • CoffeeScript
• バックエンド
  • Express
  • Mongoose
• フロントエンド
  • Vue.js (ただし1.x.x系)
  • SpreadSheetのようなライブラリ (名前忘れました。有料)
• ストレージ
  • NoSQL (MongoDB)
  • MySQL
• その他
  • Gulp
  • Docker

担当業務

• 実装
  • バックエンド
  • フロントエンド
• 追加設計
• 運用保守