わたくし、esa社のエンジニア越川（@ppworks）が、12/09（土）にTECH PLAY SHIBUYAで開催された「Rails Developers Meetup 2017」で登壇し、「作らない技術」というタイトルでお話させていただきました。
イベント/2017/12/09/Rails Developers Meetup 2017/作らない技術 - esa-pages.io
> Rails Developers Meetup 2017 とはRails Developers Meetup 2017 とは
第一線で活躍する開発者・導入企業から、RubyやRailsに関する
発想・アプローチ・成功体験・失敗体験を学ぶ、非営利勉強会です。2017年の最後を締め括る、超拡大版でお送りします。
今年の5月から継続的に開催されている Rails Developers Meetup の拡大版でした。(2018年からは、年に1〜2回、少々規模を大きくした形でのMeetupを、定期開催に代わって、開催できればと思っております。とのこと)
> 頂いたフィードバック頂いたフィードバック
頂いたフィードバックを公開してよろしいとのことでしたので、一つ一つお答えさせて頂きます！(\( ⁰⊖⁰)/)
作らない技術、感動しました。WEBサービスを作る思想みたいなのも伝わって良かったです。
ありがとうございます。WEBサービスの開発思想の話が伝わって良かったです。
怖くてサービスをリリースできなかった自分としては、すごくよかった話でした。
私はRailsに出会ってからWEBサービスを自分でリリースしてもいいんだということを学びました。Railsに感謝です。
作らないことに対する一貫した姿勢が非常に学びがあった。一貫した思想のもとで作られたサービス開発の楽しさを少しだけ感じられた。
私の発表がお役に立てて嬉しいです。サービス開発の楽しさが伝わって良かったです。
ぼくも「このサービスが私の人生を変えた」と言われるようなサービス開発に携わっていきたいなあと思っているので、非常に共感した内容でした。ありがとうございました(bow)
自分の関わったWEBサービスが誰かの親に立てることは本当に嬉しいです。共感して頂けて幸いです。
まず作る、合わなかったら revert というフットワークの軽さが esa 社の空気感だなぁ、好きだなぁ。と思いました。
pplogとesaでは多少特性が違うのですが、今回の発表の中で出てきた例ですと、pplogはユーザー規模が小さいのと、こういった開発者側の実験をユーザーが暖かく受け止めてくれやすいというサービスという特性もあります。
作り過ぎた失敗がここ最近にあったので、とても心にしみ入る発表で良かったです
私も過去に作りすぎたり、作り込んだゆえの失敗をしてきたので、今回発表させて頂いたようなスタンスに変わってきました。サービスの特性やフェーズによって、適用範囲が変わってくるかと思いますが、参考になれば嬉しいです。
エモくて（褒めてます）最高に良かったです。
エモ枠という自覚があったので、良かったです。
とても共感できました。特に最後の方の、作る過程が楽しければそれに価値を見出してもいいけど、作ったものが良くなければ価値はないというような話で、後者は当然といえば当然なのですが、前段の過程を認めてこそ後者に素直に向き合えるのかなと思い、非常に考えさせられました。
そうですね、頂いたコメントにより自分の中でも自然とそうしたバランスを取っていると気付かされました。特に自分の中でpplogというサービス自体が自分のエンジニアとしてのモチベーションを保つためのサービスという節がありますね。
作ってrevertする部分については、作るのが速いから成り立っていたり、チームが小さいから合意形成が楽みたいなのとか、もう少し色んな前提の説明があると、素早くトライアンドエラーの数を打っているんだなというのがわかりやすかったかも。
また、Templateやマルチログインなど個々の対策について、もう少し技術的に掘り下げて聞きたかった。
スピード感に関して、Railsだからこそ成り立つプロトタイプ開発の速さと、小さなチームであることによる意思決定の速さはあります。今後も大切にしていきたいです。
合意形成に関しては、コンセプトをしっかりを固めて作っているサービスなので、リリースの判断する際に立ち返る明確な基準があるのは良いなと実感してます。コードを書く際にもRailsにはRailsらしさという答えがあるので、実装方針の合意形成しやすいと感じてます。
Temaplate機能の実装に関しては、テーブル設計をしだした段階で、これは記事と同じだと思い、UIを想像した際にも記事とほぼ同じとなりました。つまりかなり早い段階で一度最初の設計でのブランチを捨ててます。ユーザーに新たな機能の説明をしたくないと思い、特定のカテゴリの記事という設計に落ち着きました。
マルチログインも同じようにスライドで紹介したように、既存ユーザーを統合する機能を途中まで作って、捨てました。
いずれも本当に核となる部分が1日で作れるかどうかは判断の分かれ目かなと思います。細かな技術的なお話は機会があればお話したいと思います。
アプリケーションの世界観について考える思考プロセスがとても参考になりました。ありがとうございました。
世界観のあるアプリケーションが好きなメンバーが集っているからこそ、こういった思考プロセスになるのかもしれません。お役に立てて嬉しいです。
リリースをやめたり、リリース後にリバートするとき、チームでどういう相談や判断があったのか知れるとうれしかったです。
作らない技術は、（おそらくですが）ペーパープロトタイピングなどで作る前に仮設を検証したりするものなのかなーと思いました。今回の越川さんの発表は、通常？であればペーパープロトタイミピングでやるようなことを、Railsで手早く作って動くプロトタイプでの検証するといろんなことが、ちゃんとわかるということなのかなーと思いました。それって作る速度が重要になってくる（遅い場合は手書きで作るとかなるのかなー）と思うので、どうして早く作れるのか、考えてることや工夫などをお聞きしたいなーと思いました。
リリース後の取りやめに関しては、Slack上でメンションを飛ばして急遽話し合ったり、GitHub で Revert の Pull Request を立てて、そのコメント欄で協議することがあります。判断軸の一つの例として、そのサービス自体がその機能がある事自体を「嫌がらないか？泣いちゃわない？」というのがあります。
ペーパープロトタイミピングに関しては、機能によっては有用な場合もありますし利用することもありますが、今回の発表で上げたpplogの例では、リリースしてみてしばらく使ってみたら分かったものというのと、リリースしてみてrevertするまでが一つの芸みたいな物がありました。（後者はpplogというサービスの特性があるからこそ出来ることですね）
早く作るときのコツは、スライドで紹介致しました『小さく賭けろ』に影響を受けてます。いかに最小限のコストで最大限の価値を提供するかを考え抜くという感じです。
皆さま、たくさんのフィードバックありがとうございます。今後もサービス開発がんばっていきたいです。
> 今後の登壇予定今後の登壇予定
さて、最後に今後 esa 社が登壇する予定のイベントを紹介します 
- 2017.12.12 Bootstrap Night! vol.2
- 2017.12.14 Ruby biz グランプリ 2017 表彰式
今週2つのイベントに参加しますので、お会い出来ましたら、よろしくお願いします(\( ⁰⊖⁰)/)
