Rails Developers Meetup 2018 Extreme

Transcript

1. 曖昧さを受け入れて 開発していく方法 クックパッド株式会社 新規サービス開発部所属 赤松 祐希 @ukstudio
2. 自己紹介 •Rails Developers Meetup #7 で登壇 ‣https://speakerdeck.com/ukstudio/rails- developers-meetup •クックパッド株式会社に3月に転職 •プロダクトマネージャー兼エンジニアからエン ジニアへ ‣手を動かすのが中心 •新規サービスの立ち上げに参加
3. 今日のゴール
4. •新規サービスの立ち上げ時の主にエンジニアリングに フォーカスした個人的な考えをお話しします ‣ 明確な答えを提供するものではない •普段の開発の意思決定、やり方の参考になれば幸い
5. 曖昧さ
6. ソフトウェア開発では必ず曖昧さが存在する •ソフトウェア開発で事前に要件や仕様がハッキリと全部 決まっていることはまずない ‣ 曖昧さがゼロになるのは、ソフトウェアを実現した時だけ •新規サービス開発でも、ユーザーインタビューやチーム でのディスカッション、プロダクトオーナーの熟考など によって作るものが変わりがち
7. でもリリース日は? •「これぐらいの時期にはリリースしたいよね」 •「N月のこの日にユーザーテストをしよう」 •リリース日のシビアさは状況によるけど、決まってい ることが多い
8. 作るものをFixしないのか •ユーザーテスト後のふりかえりでそういう話もでた •モックを「これをリリース版とする」とか決めたり •でも変わるときは変わる
9. 事前に全部決めるのは無理
10. •考えがまとまるのを待ってるとエンジニアは暇だし、
 時間がもったいない •一度決めたとしても、他に良い案がでたなら出来る限 りそれを採用したい •開発中に別のところを先行して考えておくのも結構難 しい
11. 作りながら考える 考えながら作る ということをチームでやる
12. 曖昧さを受け入れる開発
13. •とりあえず今ある情報から開発を進める •作ってる途中に仕様が変わったら変わったで受け入れ てやっていく •結局出来る限りはやめにフィードバックをもらって、 迅速に変更・修正をやっていくしかない
14. 動作するものを素早く提供する •なにはともあれデプロイしなきゃ始まらない •クックパッドは幸いにもシュッとサーバーを立てる方 法がある ‣ Dockerイメージ作って、サーバーの定義を書いてそれを PR・マージすると出来る
15. ゼロベースでデプロイを考えると結構難しい •既に仕組みがあればいいけど、仕組みがない環境の場合にゼロから構築し なきゃいけない •Capistrano? Docker? Heroku? •チャットデプロイ •ステージング環境 •データベースの同期 •その他色々…
16. サーバーの構築は1回とは限らない •ドメインを持ったアプリケーションの構築の話 •この3ヶ月で9つのサーバーを用意した ‣ APIサーバー、管理画面の本番・検証環境 •なのでデプロイ環境を構築する技術は大事
17. マネージドサービスという選択肢 •バックエンドだったらAppSyncとかFirebaseとか •動くものを提供するまでがはやい ‣ デプロイの面倒な部分を避けることができる(と思う…) •本リリース前であればRails(もしくは他のフレームワーク)への移 行も比較的しやすい ‣ 現にAppSyncからRails(+graphql-ruby)への置き換えをやったりした
18. 結局どっちを選ぶ? •僕らはRailsを選んだ •AppSyncでは今後開発を予定している機能で制限がありそうだった •デプロイ環境が整っている、Railsに関する資産が社内に多い •ただ、今後の状況次第ではAppSyncへの移行もありえる ‣ サーバーサイドのロジックがあまりない ‣ アプリ、管理画面ともにGraphQLを実装している
19. 適切な技術を選ぶために •結局のところケースバイケース… •なんだかんだで実際に導入してみるのが一番良い •だけど現実問題、無理な部分もある ‣ 本リリース後にRails <-> マネージドの移行をしたいかというと… •幸いなことに、この業界は事例が比較的オープン ‣ 他人の経験を自分の疑似経験とすることが可能
20. 設計にかける時間 •素早く実装したいからといって、雑に設計をすること はできない •かといって過剰に設計しても時間が無駄になってし まったり、不必要な負債になってしまう
21. 最近あったこと •ユーザーテストまでに必要な機能を作らなきゃいけない ‣ オーナーの気持ち的には、テストの結果がどうあれ外すつもりは ないという機能 •「ちゃんと」実装しようとするAWSのマネージドとRailsの組 み合わせを設計する必要がある ‣ が、直近のユーザーテスト時にはライブラリを入れるだけで「十 分」だったのでそうした
22. 結果 •その機能は結局なくすことになった •仮に機能がなくならなかったら、将来的に負債になっ ていた •仮に機能を作りこんでいたら、そこにかけたコストが 無駄になっていた
23. 結局、未来は不確か •なくなるかもしれないから、雑に作った方がいいという 話ではない •将来どうなるかわからないので、その時の手持ちの情報 で必要十分なものを設計する ‣ 今回の必要十分 = ユーザーテスト時に動くもの •正解だったかどうかはその時にならないとわからない
24. 設計・実装能力とコスト •今回のケースではAWSのマネージドの知識・経験が自 分にもっとあったとしたら、設計と実装にかかるコス トはどちらも同じになった可能性はある •その場合、AWSを導入することでより良い選択をとる ことができる •つまり、自分の設計の能力や手札を増やすのが大事
25. 変更を許容する •曖昧さが大きい状況では、仕様や要件の変更が頻繁に 発生する •「素早く」だけではダメで「変更に強いアプリケー ション」を作ることができるか ‣ 別の言い方をすると開発スピードを維持し続けられるか
26. テストを書かないという選択肢は基本的にはない •実装速度がその場ははやくなるので、テストを書かな いという誘惑はすごく強い •が、テストがないことでリファクタリングや要件・仕 様変更の修正をするのが大変になる •テストケースの設計として、「このケースは考慮しな い」ということでテストを削るのはあり
27. モバイルアプリとAPI •モバイルアプリはSPAと読み替えても良い •ケースバイケースかもしれないが、ドメインモデルよりは画 面の方が変更の影響を受けやすい •モバイルとAPIでわかれることで、変更の影響が局所的になる ‣ GraphQLだとモバイル側のクエリを変更するだけということも ままある
28. 大事なのはアーキテクチャ設計 •かといって、モバイルはともかくWebアプリを全部SPAにした方がいい という話でもない •画面がそれなりに複雑で変更が発生するという状況で、SPAとして切り 出すのが適切だったと判断した •他にもフロントエンドのエンジニアがいるからといってSPAにするとい うのも悪手 ‣ チームにアーキテクチャを合わせるのではなくて、チームがアーキテク チャにあわせる
29. まとめ
30. 結局のところ •曖昧な状況下では、実装スピードと変更を受け入れることが 大事 ‣ それってソフトウェア開発ってみんなそう ‣ 技術プラクティスはゴロゴロ転がってるから、案外マインド セットが大事なのかなと思う今日この頃 •今わかっていることから、今できるベストを繰り返し続ける