複数言語でのバックエンド開発経験あり。
クリーンアーキテクチャを始めとした設計方針や、DDD等のビジネスロジックのモデリング技術を意識して開発を行っている。
マイクロサービスに挑戦したこともありk8s上にデプロイしてサービスを運用したこともある。
基本的なインフラ知識もあり、研究室のシステムの保守を行ったり、過去は自宅にサーバーを構築して外部に公開していたこともある。

DDDやクリーンアーキテクチャを意識した開発。
gRPCを用いたマイクロサービスの開発経験もあり。

Webバックエンド

筑波大学生向け時間割アプリ。有志で集まりチームで開発・運用されています。
自分はバックエンドの開発とAndroidの開発を担当しています。

![twinte-sc1](//images.ctfassets.net/27i46hewzrkc/64cbmfK6ZWWiCdxri0gvCW/0ed317a79073fb3d90a98217819279aa/pixel4-1__1_.png)

# Twin:teのバージョン遷移
Twin:teは過去に何度か大型アップデートを行っており、そのたびに大きく構成が変わっています。

- v1：初期バージョンで自分は開発に参加していませんでした
- v2：フロントにVue(2.x)・バックエンドにnode.js/express
- v3（現在）：フロントにVue(3.x)・バックエンドにnode.js/express/gRPCマイクロサービス

# 現在のバックエンド
v3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。
基本的にフロントエンドが得意なメンバーにも開発ができるように言語はTypescriptを使用していますが、一部はgoで動いています。
サービス間はgRPCで通信しており、フロントエンドとはapi-gatewayというサービスを介してhttpsで通信しています。
全てのサービスはlinodeのk8s上で動作しており、CI/CDはGitHubActionで整備されています。

# マイクロサービスを選んだ理由
v2までは一つのバックエンドサービスがすべての機能を実装する一般的なものでした。
しかしv3では機能毎に細かくサービスを分割して協調して動作するマイクロサービスとなっています。
マイクロサービスに切り替えた理由として以下が挙げられます。

## 新サービス実装の心理的負担を減らす
Twin:teは筑波大学生が便利に使えるサービスを開発したいというメンバーが集っています。
よって新しいサービスや機能は思いついたらすぐ実装して公開できる仕組みが必要だと考えました。
仮に全バックエンドが一つのサービスで成り立っていた場合、まず全体のコードの把握が必要になります。また、得意としない言語やフレームワークの場合学習コストがかかります。
こういった新機能を開発したいという気持ちを削いでしまう要因をできるだけ減らすために、また各々が挑戦したいことを既存のコードで制限したくないという思いもありました。マイクロサービスであれば使いたい言語でgRPCが利用できればそれ以外の制約はありません。

## コード把握のコスト削減
v1から始まったTwin:teのサービスは大きくなり、時間割以外の機能も多く実装するようになりました。例えばTwin:teはユーザーから寄付金を募っており決済の実装も行っています。
このようにメイン機能ではない性質の異なる機能を一つのバックエンドとして開発する必要がで出てきました。これにより特に新メンバーがコードを把握することが難しくなりました。
例えば特定の機能を修正したい場合に全体のコードをある程度把握する必要がありますが、サービスレベルで完全に分割されていれば対象サービスを把握するだけで修正ができます。

## コードの流動性
各々が異なる言語・異なる設計でサービスを開発すると将来的に技術的な負債になりえます。しかし、負債になったら新しく書き直すくらいの流動性があるべきだと思っています。
Twin:teは学生によって構成されるためメンバーに流動性もあります。そのため一つのコードベースを長期的に保持することは難しいのです。
マイクロサービスなら小さい単位から新しく書き直すことが可能になります。

# Androidアプリ
Twin:teはチームの規模の観点から、フロントエンドはweb技術で統一しています。
そのためiOS/AndroidアプリのメインUIはWebViewになっています。
ただし、通知機能やウィジェット機能はネイティブで実装する必要があります。

Twin:te AndroidアプリはKotlinで書かれています。
Android12でウィジェット周りのAPIがアップデートされたため利用できないか模索している段階です。

# chrome拡張
大学が使用している学習支援システムManabaで提供される授業の課題情報をGoogleCalendarに転送する拡張機能です。UIはReactで書かれています。

Twin:te

![sos](//images.ctfassets.net/27i46hewzrkc/1KfYf1UPM6Pau0nhZIXHhv/749b188dc9caaad7aade94d024d9b663/_____________2019-12-08_031604.png)

筑波大学学園祭実行委員が企画者との連絡を取るためのシステムを開発・運用しました。
もともと紙で行っていた業務をデジタル化し、業務を効率化することを目的としています。

学園祭に出展したい団体の代表者は本システムに登録後、
実行委員会側が発行するアンケートに答えながら手続きを進めていきます。

次のような機能があります

- ユーザーごとの権限管理（個人情報の可視性のコントロール
- GoogleFormのような直感的な操作でアンケートを作成する機能
- 委員会側の調整結果（場所の割り振りなど）を一括で公開できる機能

質問の回答に応じて別の質問が変化する機能や、調整結果を一括配布する機能が好評でした。
また、前年度まで紙で配布していた調整結果をシステム上で配布できるようになり、大量の紙を印刷する必要がなくなりました。
さらに企画の情報も収集し、来場者向けにGoogleMapライクなWebアプリとして公開しました。

筑波大学学園祭実行委員で企画者との連絡を取るためのシステム

雙峰祭オンラインシステム

みんなで同じ曲を聞きながらチャット！音楽で新しいコミュニケーションを。（サービス終了しました）

![myuu-sc1](//images.ctfassets.net/27i46hewzrkc/4lH84lJudBVJknEMyX3xYv/37a0ba85825350be64f6558d5d72e0a8/image.png)

フロント・バックともにすべて自分で開発しました。
SpotifyのAPIを活用してユーザーの再生状況を自動で同期、チャットルームで好きな曲を流すことが出来ます。

みんなで同じ曲を聞きながらチャット！

Myuu

インターン・アルバイトとして1年間「pixiv FACTORY」のフロント・バックエンド開発を行いました。

# きっかけ
もともとPixivが提供する多くのサービスを利用しており興味がありました。
さらに様々なクリエイターを支えるプラットフォームでもあるので、自分の理念と重なる部分が多かったことも挙げられます。
また、今回お世話になったFACTORYは非常に凝ったグッズ編集画面をWebで実装しており、
編集画面などの複雑なUIを組むことが好きな自分には非常に魅力的でした。

# やったこと
1年を通して新機能の開発やCM向けの管理ツールの開発を行いました。
予め決まったユーザー向けの機能の実装を始め、
日々遂行されるCM業務の中で不便な点などをヒアリングしてそれを改善する機能の実装などを行いました。

一番苦労した点はドメイン知識の不足と、長期運用からくる巨大なコードベースの把握でした。
FACTORYは様々なグッズ製造に対応しておりそれぞれの製造に関する知識や、
様々な工場や印刷所とのやり取り方法を把握する必要がありました。
また長期運用により古い技術と現在の技術が共存しており、ロジックそのものも巨大で把握に時間がかかりました。既に存在するコードを効率よく把握する能力が鍛えられたと思います。

# 感想
クリエイターとの距離がとても近い現場で、仕事をしていて充実が得られました。
また、長期運用からくる新旧の技術の共存方法など、
息の長いサービスならではの技術的な工夫が非常に勉強になりました。

ありがとうございました。

アルバイト / あなたのアイデアをカタチに「pixiv FACTORY」 フロント・バックエンド開発

Pixiv Inc.

JUCEとWebAudioAPIでDTM用のサブスピーカーシステムを構築した話です

Works

#Webバックエンド

Twin:te

雙峰祭オンラインシステム

Myuu

Pixiv Inc.

JUCEとWebAudioAPIでロスレス音源をReal Time Streaming