Rails Developers Meetup 2018 Extreme

by AKAMATSU Yuki

Slide 1

Slide 1 text

曖昧さを受け入れて開発していく方法クックパッド株式会社新規サービス開発部所属赤松祐希 @ukstudio

Slide 2

Slide 2 text

自己紹介 •Rails Developers Meetup #7 で登壇 ‣https://speakerdeck.com/ukstudio/rails- developers-meetup •クックパッド株式会社に3月に転職 •プロダクトマネージャー兼エンジニアからエンジニアへ ‣手を動かすのが中心 •新規サービスの立ち上げに参加

Slide 3

Slide 3 text

今日のゴール

Slide 4

Slide 4 text

•新規サービスの立ち上げ時の主にエンジニアリングにフォーカスした個人的な考えをお話しします ‣ 明確な答えを提供するものではない •普段の開発の意思決定、やり方の参考になれば幸い

Slide 5

Slide 5 text

曖昧さ

Slide 6

Slide 6 text

ソフトウェア開発では必ず曖昧さが存在する •ソフトウェア開発で事前に要件や仕様がハッキリと全部決まっていることはまずない ‣ 曖昧さがゼロになるのは、ソフトウェアを実現した時だけ •新規サービス開発でも、ユーザーインタビューやチームでのディスカッション、プロダクトオーナーの熟考などによって作るものが変わりがち

Slide 7

Slide 7 text

でもリリース日は? •「これぐらいの時期にはリリースしたいよね」 •「N月のこの日にユーザーテストをしよう」 •リリース日のシビアさは状況によるけど、決まっていることが多い

Slide 8

Slide 8 text

作るものをFixしないのか •ユーザーテスト後のふりかえりでそういう話もでた •モックを「これをリリース版とする」とか決めたり •でも変わるときは変わる

Slide 9

Slide 9 text

事前に全部決めるのは無理

Slide 10

Slide 10 text

•考えがまとまるのを待ってるとエンジニアは暇だし、  時間がもったいない •一度決めたとしても、他に良い案がでたなら出来る限りそれを採用したい •開発中に別のところを先行して考えておくのも結構難しい

Slide 11

Slide 11 text

作りながら考える考えながら作るということをチームでやる

Slide 12

Slide 12 text

曖昧さを受け入れる開発

Slide 13

Slide 13 text

•とりあえず今ある情報から開発を進める •作ってる途中に仕様が変わったら変わったで受け入れてやっていく •結局出来る限りはやめにフィードバックをもらって、迅速に変更・修正をやっていくしかない

Slide 14

Slide 14 text

動作するものを素早く提供する •なにはともあれデプロイしなきゃ始まらない •クックパッドは幸いにもシュッとサーバーを立てる方法がある ‣ Dockerイメージ作って、サーバーの定義を書いてそれを PR・マージすると出来る

Slide 15

Slide 15 text

ゼロベースでデプロイを考えると結構難しい •既に仕組みがあればいいけど、仕組みがない環境の場合にゼロから構築しなきゃいけない •Capistrano? Docker? Heroku? •チャットデプロイ •ステージング環境 •データベースの同期 •その他色々…

Slide 16

Slide 16 text

サーバーの構築は1回とは限らない •ドメインを持ったアプリケーションの構築の話 •この3ヶ月で9つのサーバーを用意した ‣ APIサーバー、管理画面の本番・検証環境 •なのでデプロイ環境を構築する技術は大事

Slide 17

Slide 17 text

マネージドサービスという選択肢 •バックエンドだったらAppSyncとかFirebaseとか •動くものを提供するまでがはやい ‣ デプロイの面倒な部分を避けることができる(と思う…) •本リリース前であればRails(もしくは他のフレームワーク)への移行も比較的しやすい ‣ 現にAppSyncからRails(+graphql-ruby)への置き換えをやったりした

Slide 18

Slide 18 text

結局どっちを選ぶ? •僕らはRailsを選んだ •AppSyncでは今後開発を予定している機能で制限がありそうだった •デプロイ環境が整っている、Railsに関する資産が社内に多い •ただ、今後の状況次第ではAppSyncへの移行もありえる ‣ サーバーサイドのロジックがあまりない ‣ アプリ、管理画面ともにGraphQLを実装している

Slide 19

Slide 19 text

適切な技術を選ぶために •結局のところケースバイケース… •なんだかんだで実際に導入してみるのが一番良い •だけど現実問題、無理な部分もある ‣ 本リリース後にRails <-> マネージドの移行をしたいかというと… •幸いなことに、この業界は事例が比較的オープン ‣ 他人の経験を自分の疑似経験とすることが可能

Slide 20

Slide 20 text

設計にかける時間 •素早く実装したいからといって、雑に設計をすることはできない •かといって過剰に設計しても時間が無駄になってしまったり、不必要な負債になってしまう

Slide 21

Slide 21 text

最近あったこと •ユーザーテストまでに必要な機能を作らなきゃいけない ‣ オーナーの気持ち的には、テストの結果がどうあれ外すつもりはないという機能 •「ちゃんと」実装しようとするAWSのマネージドとRailsの組み合わせを設計する必要がある ‣ が、直近のユーザーテスト時にはライブラリを入れるだけで「十分」だったのでそうした

Slide 22

Slide 22 text

結果 •その機能は結局なくすことになった •仮に機能がなくならなかったら、将来的に負債になっていた •仮に機能を作りこんでいたら、そこにかけたコストが無駄になっていた

Slide 23

Slide 23 text

結局、未来は不確か •なくなるかもしれないから、雑に作った方がいいという話ではない •将来どうなるかわからないので、その時の手持ちの情報で必要十分なものを設計する ‣ 今回の必要十分 = ユーザーテスト時に動くもの •正解だったかどうかはその時にならないとわからない

Slide 24

Slide 24 text

設計・実装能力とコスト •今回のケースではAWSのマネージドの知識・経験が自分にもっとあったとしたら、設計と実装にかかるコストはどちらも同じになった可能性はある •その場合、AWSを導入することでより良い選択をとることができる •つまり、自分の設計の能力や手札を増やすのが大事

Slide 25

Slide 25 text

変更を許容する •曖昧さが大きい状況では、仕様や要件の変更が頻繁に発生する •「素早く」だけではダメで「変更に強いアプリケーション」を作ることができるか ‣ 別の言い方をすると開発スピードを維持し続けられるか

Slide 26

Slide 26 text

テストを書かないという選択肢は基本的にはない •実装速度がその場ははやくなるので、テストを書かないという誘惑はすごく強い •が、テストがないことでリファクタリングや要件・仕様変更の修正をするのが大変になる •テストケースの設計として、「このケースは考慮しない」ということでテストを削るのはあり

Slide 27

Slide 27 text

モバイルアプリとAPI •モバイルアプリはSPAと読み替えても良い •ケースバイケースかもしれないが、ドメインモデルよりは画面の方が変更の影響を受けやすい •モバイルとAPIでわかれることで、変更の影響が局所的になる ‣ GraphQLだとモバイル側のクエリを変更するだけということもままある

Slide 28

Slide 28 text

大事なのはアーキテクチャ設計 •かといって、モバイルはともかくWebアプリを全部SPAにした方がいいという話でもない •画面がそれなりに複雑で変更が発生するという状況で、SPAとして切り出すのが適切だったと判断した •他にもフロントエンドのエンジニアがいるからといってSPAにするというのも悪手 ‣ チームにアーキテクチャを合わせるのではなくて、チームがアーキテクチャにあわせる

Slide 29

Slide 29 text

まとめ

Slide 30

Slide 30 text

結局のところ •曖昧な状況下では、実装スピードと変更を受け入れることが大事 ‣ それってソフトウェア開発ってみんなそう ‣ 技術プラクティスはゴロゴロ転がってるから、案外マインドセットが大事なのかなと思う今日この頃 •今わかっていることから、今できるベストを繰り返し続ける