曖昧さを受け入れて開発していく方法クックパッド株式会社 新規サービス開発部所属赤松 祐希 @ukstudio
View Slide
自己紹介•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にするというのも悪手‣ チームにアーキテクチャを合わせるのではなくて、チームがアーキテクチャにあわせる
まとめ
結局のところ•曖昧な状況下では、実装スピードと変更を受け入れることが大事‣ それってソフトウェア開発ってみんなそう‣ 技術プラクティスはゴロゴロ転がってるから、案外マインドセットが大事なのかなと思う今日この頃•今わかっていることから、今できるベストを繰り返し続ける
ukstudio
samanthasiow
jnunemaker
tammielis
panda_program
destraynor
addyosmani
paulrobertlloyd
kevinliebholz
garrettdimon
brad_frost
moore
bcantrill