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
Rails Developers Meetup 2018 Extreme
Search
AKAMATSU Yuki
July 14, 2018
0
3.1k
Rails Developers Meetup 2018 Extreme
AKAMATSU Yuki
July 14, 2018
Tweet
Share
More Decks by AKAMATSU Yuki
See All by AKAMATSU Yuki
今年できたチームの生産性を向上させたプラクティスの紹介 / Kaigi on Rails 2022
ukstudio
4
4.7k
Cookpad Tech Kitchen #24
ukstudio
0
680
Cookpad Summer Internship 2019 Day 1 Git
ukstudio
0
9.8k
Cookpad Summer Internship 2019 Day 1 Ruby TypeScript
ukstudio
0
9.7k
sdevtalks.org開発報告 / reporting that sdevtalks.org was launched
ukstudio
0
310
GraphQL on Rails
ukstudio
1
400
「なんでも」をしよう / 2018-12-19 s-dev talks LT
ukstudio
2
500
機能追加時における 仮説検証/s-dev-talks-01
ukstudio
0
890
Rails Developers Meetup
ukstudio
6
3.3k
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
45
6.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
How GitHub (no longer) Works
holman
311
140k
Optimizing for Happiness
mojombo
376
69k
Practical Orchestrator
shlominoach
186
10k
Side Projects
sachag
452
42k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Teambox: Starting and Learning
jrom
132
8.7k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Transcript
曖昧さを受け入れて 開発していく方法 クックパッド株式会社 新規サービス開発部所属 赤松 祐希 @ukstudio
自己紹介 •Rails Developers Meetup #7 で登壇 ‣https://speakerdeck.com/ukstudio/rails- developers-meetup •クックパッド株式会社に3月に転職 •プロダクトマネージャー兼エンジニアからエン
ジニアへ ‣手を動かすのが中心 •新規サービスの立ち上げに参加
今日のゴール
•新規サービスの立ち上げ時の主にエンジニアリングに フォーカスした個人的な考えをお話しします ‣ 明確な答えを提供するものではない •普段の開発の意思決定、やり方の参考になれば幸い
曖昧さ
ソフトウェア開発では必ず曖昧さが存在する •ソフトウェア開発で事前に要件や仕様がハッキリと全部 決まっていることはまずない ‣ 曖昧さがゼロになるのは、ソフトウェアを実現した時だけ •新規サービス開発でも、ユーザーインタビューやチーム でのディスカッション、プロダクトオーナーの熟考など によって作るものが変わりがち
でもリリース日は? •「これぐらいの時期にはリリースしたいよね」 •「N月のこの日にユーザーテストをしよう」 •リリース日のシビアさは状況によるけど、決まってい ることが多い
作るものをFixしないのか •ユーザーテスト後のふりかえりでそういう話もでた •モックを「これをリリース版とする」とか決めたり •でも変わるときは変わる
事前に全部決めるのは無理
•考えがまとまるのを待ってるとエンジニアは暇だし、 時間がもったいない •一度決めたとしても、他に良い案がでたなら出来る限 りそれを採用したい •開発中に別のところを先行して考えておくのも結構難 しい
作りながら考える 考えながら作る ということをチームでやる
曖昧さを受け入れる開発
•とりあえず今ある情報から開発を進める •作ってる途中に仕様が変わったら変わったで受け入れ てやっていく •結局出来る限りはやめにフィードバックをもらって、 迅速に変更・修正をやっていくしかない
動作するものを素早く提供する •なにはともあれデプロイしなきゃ始まらない •クックパッドは幸いにもシュッとサーバーを立てる方 法がある ‣ Dockerイメージ作って、サーバーの定義を書いてそれを PR・マージすると出来る
ゼロベースでデプロイを考えると結構難しい •既に仕組みがあればいいけど、仕組みがない環境の場合にゼロから構築し なきゃいけない •Capistrano? Docker? Heroku? •チャットデプロイ •ステージング環境 •データベースの同期 •その他色々…
サーバーの構築は1回とは限らない •ドメインを持ったアプリケーションの構築の話 •この3ヶ月で9つのサーバーを用意した ‣ APIサーバー、管理画面の本番・検証環境 •なのでデプロイ環境を構築する技術は大事
マネージドサービスという選択肢 •バックエンドだったらAppSyncとかFirebaseとか •動くものを提供するまでがはやい ‣ デプロイの面倒な部分を避けることができる(と思う…) •本リリース前であればRails(もしくは他のフレームワーク)への移 行も比較的しやすい ‣ 現にAppSyncからRails(+graphql-ruby)への置き換えをやったりした
結局どっちを選ぶ? •僕らはRailsを選んだ •AppSyncでは今後開発を予定している機能で制限がありそうだった •デプロイ環境が整っている、Railsに関する資産が社内に多い •ただ、今後の状況次第ではAppSyncへの移行もありえる ‣ サーバーサイドのロジックがあまりない ‣ アプリ、管理画面ともにGraphQLを実装している
適切な技術を選ぶために •結局のところケースバイケース… •なんだかんだで実際に導入してみるのが一番良い •だけど現実問題、無理な部分もある ‣ 本リリース後にRails <-> マネージドの移行をしたいかというと… •幸いなことに、この業界は事例が比較的オープン ‣
他人の経験を自分の疑似経験とすることが可能
設計にかける時間 •素早く実装したいからといって、雑に設計をすること はできない •かといって過剰に設計しても時間が無駄になってし まったり、不必要な負債になってしまう
最近あったこと •ユーザーテストまでに必要な機能を作らなきゃいけない ‣ オーナーの気持ち的には、テストの結果がどうあれ外すつもりは ないという機能 •「ちゃんと」実装しようとするAWSのマネージドとRailsの組 み合わせを設計する必要がある ‣ が、直近のユーザーテスト時にはライブラリを入れるだけで「十 分」だったのでそうした
結果 •その機能は結局なくすことになった •仮に機能がなくならなかったら、将来的に負債になっ ていた •仮に機能を作りこんでいたら、そこにかけたコストが 無駄になっていた
結局、未来は不確か •なくなるかもしれないから、雑に作った方がいいという 話ではない •将来どうなるかわからないので、その時の手持ちの情報 で必要十分なものを設計する ‣ 今回の必要十分 = ユーザーテスト時に動くもの •正解だったかどうかはその時にならないとわからない
設計・実装能力とコスト •今回のケースではAWSのマネージドの知識・経験が自 分にもっとあったとしたら、設計と実装にかかるコス トはどちらも同じになった可能性はある •その場合、AWSを導入することでより良い選択をとる ことができる •つまり、自分の設計の能力や手札を増やすのが大事
変更を許容する •曖昧さが大きい状況では、仕様や要件の変更が頻繁に 発生する •「素早く」だけではダメで「変更に強いアプリケー ション」を作ることができるか ‣ 別の言い方をすると開発スピードを維持し続けられるか
テストを書かないという選択肢は基本的にはない •実装速度がその場ははやくなるので、テストを書かな いという誘惑はすごく強い •が、テストがないことでリファクタリングや要件・仕 様変更の修正をするのが大変になる •テストケースの設計として、「このケースは考慮しな い」ということでテストを削るのはあり
モバイルアプリとAPI •モバイルアプリはSPAと読み替えても良い •ケースバイケースかもしれないが、ドメインモデルよりは画 面の方が変更の影響を受けやすい •モバイルとAPIでわかれることで、変更の影響が局所的になる ‣ GraphQLだとモバイル側のクエリを変更するだけということも ままある
大事なのはアーキテクチャ設計 •かといって、モバイルはともかくWebアプリを全部SPAにした方がいい という話でもない •画面がそれなりに複雑で変更が発生するという状況で、SPAとして切り 出すのが適切だったと判断した •他にもフロントエンドのエンジニアがいるからといってSPAにするとい うのも悪手 ‣ チームにアーキテクチャを合わせるのではなくて、チームがアーキテク チャにあわせる
まとめ
結局のところ •曖昧な状況下では、実装スピードと変更を受け入れることが 大事 ‣ それってソフトウェア開発ってみんなそう ‣ 技術プラクティスはゴロゴロ転がってるから、案外マインド セットが大事なのかなと思う今日この頃 •今わかっていることから、今できるベストを繰り返し続ける