Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
とある自社開発の苦楽の軌跡/Trajectory of a Certain In-house ...
Search
果物リン
May 19, 2021
Technology
280
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
とある自社開発の苦楽の軌跡/Trajectory of a Certain In-house Development Effort
株式会社スタディストのTeachme Bizがたどってきた歴史をほってみた
果物リン
May 19, 2021
More Decks by 果物リン
See All by 果物リン
ADDF - ループエンジニアリングするフレームワークを作ったら/I Didn't Set Out to Build Loop Engineering, But ADDF Did
fruitriin
0
120
AIに与える人間らしさを(略)したら600ページの同人誌になった/I kept thinking about making AI more human, more, more, more... wait, when did this become a 600-page doujinshi?
fruitriin
0
130
記憶を高速で思い出す全文検索パフォーマンス・チューニング テクニック/How to make your AI recall, quickly
fruitriin
0
100
入社半年で作った"社内でも使える"ツール集/Everything I Built on the Side in Half a Year
fruitriin
0
110
embodied記憶の依代 聖杯問答/ Vessel of Memory: The Grail Dialogue #embodied_llm
fruitriin
2
190
ClaudeCodeと遠くへいくためのパーミッションルール/Stop Checking, Start Trusting: Claude Code Permission Rules
fruitriin
0
74
Claude Codeと物忘れ / Invitation talk about context - Why Claude Code forget?
fruitriin
0
99
Claude Codeと2つの巻き戻し戦略 / Two Rewind Strategies with Claude Code
fruitriin
0
250
Electron+Vue+Swift=真のデスクトップアプリ / How to create "Really" desktop app using Electron
fruitriin
0
140
Other Decks in Technology
See All in Technology
Devsumi 2026 Summer 人もAIも使える共通基盤を事業の加速装置にする~デザインシステム運用に学ぶ組織レバレッジ~ 渡辺 凌央
legalontechnologies
PRO
1
240
凡エンジニアがこの先生きのこるためには。〜TypeScript完全に理解したい〜
alchemy1115
2
310
DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例
ysknsid25
2
670
公式ドキュメントの歩き方etc
coco_se
1
120
企業でAWS Organizationsを動かすための組織設計の考え方
nrinetcom
PRO
1
110
タスクの複雑さでモデルを選ぶ ── Thompson Samplingで動かす“トークン/コスト最適化
satohy0323
0
570
ヘルスケア領域における AI 活用と その安全性担保のための取り組み (Leveraging AI in Healthcare and Our Efforts to Ensure Its Safety) - Google I/O Extended Tokyo 2026, July 11, 2026
zettaittenani
0
430
実践!既存 Project への AI-Driven Development 適用〜 一ヶ月で Project 唯一のフロントエンドエンジニアを作り出せ〜
lycorptech_jp
PRO
0
230
OPENLOGI Company Profile for engineer
hr01
1
74k
Oracle Exadata Database Service on Cloud@Customer X11M (ExaDB-C@C) サービス概要
oracle4engineer
PRO
2
8.4k
Amplify Gen2でbackend.tsにCDKを定義する/しない事によるCDKの挙動の違いとユースケース
smt7174
1
420
AI時代の闇と光
tatsuya1970
0
110
Featured
See All Featured
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
340
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
260
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
340
The agentic SEO stack - context over prompts
schlessera
0
850
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
34
2.8k
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
260
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
1.1k
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
420
Transcript
とある自社開発の苦楽の軌跡 リポジトリ考古学 株式会社スタディスト 果物リン@FruitRiin
自己紹介@FruitRiin • Vueが好きでVueとRails書いてる • スタディストの中でHansoku Cloudというサービスの開発中 • 個人開発もする ◦ TLのないTwitterクライアント
◦ オンラインイベント用のサービス
自社サービス開発のスタディスト 受託開発のゆめみ どんな話が面白いだろうか
自社サービスならではの 出来事とか?
リポジトリ考古学 してみよう! PR8684個+コミットログいっぱいみました
引用元 スタディスト会社案内
引用元 スタディスト会社案内
引用元 スタディスト会社案内 本日はこちら
2011年~2012年 Teachmeは始まった Teachme Bizじゃなかった
最初のコミットが2012年1月 どうもある程度動きそうな気配のある Railsのコードがまるごとコミットされる
初期のDBは(おそらく) SQLite3 でもS3もつかってた。 こっちはモダン!
Heroku GitとGitHubが並行してたっぽい
2014年4月 本番・StagingDBがMySQLに移行 EC2移行も2012年~2016年の間に行われたらしいのでこの時期?
2016年9月頃からGitHubのPRが使われ始める
2017年11月 UIリニューアル開始! Vue 2.5でSPAアプリケーションに!
2018年11月 UIリニューアルのMaster反映 ここでAPIがV1とV2分かれる
インタビュー UIリニューアルについて UIリニューアルは元々フロントエンドの改修だけで、 APIはほとんどv1で済むでしょぐらいの認識だったので、す ぐ終わる見積もりだった プロジェクトを進めるに連れ、ネイティブアプリに特化した貧弱な v1 API じゃ対応ができない箇所が出てきて、そ の都度 v2
API を新規に作る方針にした 気づいたらほぼ全ての API に v2 が生まれてた 新UIが要求するAPIがやたらリッチで、既存資産の流用が全然出来ずに継ぎ足しで新規コードを足していったの で、検証フェーズに入って膨大なバグが出たのが一番大変だった印象
作ってみたけど使われなかった機能を捨てることも… そういうこともあります。
フロントエンドのツールチェイン更新 2020年 • E2Eテストのはじまり • Prettierを既存コードに少しずつ適用する • Storybook 6以降 2021年
• TS化
インタビュー フロントエンドのツールチェイン 元々こだわりがあったわけでなく、その領域をリードしてた人が退職してしまい、組織内でそこが手つかずの状態 になってしまっていたのがきっかけ 「誰かがやらなきゃならない」っていうオーナーシップと、「ここ頑張れば周りと差別化できる」っていう生存戦略が 半々ぐらい 開発環境、CI/CD周りはステークホルダ(プロダクトや会社) の方針に左右されずに自分のペースで無限に改善 できるとこが好きで今も続けてる
インフラ周りの更新 2018年 • CircleCI • NewRelic, CloudWatch, Stackdriver • fluentd,
Elasticsearch, Kibana • Ansible + Serverspec + Packer + AWS Code Build • EC2からECSへ
2020年 新規機能のマイクロサービス化 チームメンバーが増えたことで開発速度の低下を懸念して行われたもの
2020年末Kubernetes移行 開発環境と本番環境が同じコンテナを使うので OSライブラリのパッケージ差分が生まれづらい!
インタビュー 今はモダンになったインフラや運用のことを教えて Deploy自動化されている インフラもほぼコード化されていて、 PRベースで仕事が進められる コンテナで、開発環境〜本番環境での OSライブラリのパッケージ差分が生まれづらい チームでInfraをさわれる とかでしょうか! (マイクロサービス含めて)本番環境フルサーバーレスなのはすごく珍しいかもしれないです。
今ではめちゃくちゃモダンに!
自社開発は泥臭く始まっても ちゃんとなんとかなる
必要なときに必要なものを 身に付けていくのが大事…なのかな?