Questions and feedbacks
Ruby は 3×3 というパフォーマンス向上のゴールに向かっている最中ですが、Ruby on Railsというフレームワークの作者として、今後のRubyにどういう機能改善や機能向上を期待していますか?
Like(0)
What do you think about GraphQL? Do you think it should be supported by Rails?
Like(2)
割愛されたservice meshについて知りたいです！
ありがとうございます！ service mesh自体はご存知と思いますが( 参考 https://deeeet.com/writing/2018/05/22/service-mesh/ )、 サービス数が増えた時にどうしてもサービス間の依存関係が複雑になってしまいました。
例えば、 あるサービスに負荷が集中して非同期キューがつまったので、非同期ワーカーの数を増やしたら他サービスの負荷が上がった。 あるサービスのエラーが急に出るようになって原因を調べていったら、全然別の場所に原因があった。 などということもざらにあります。
現在の課題感としては、 - 障害の局所化やサービスのレジリエンスを高める仕組み - 分散トレーシング をまずどうにかしたい、と思っているところです。
Like(0)
「機能追加時にちょっとだけ手間を余計に掛けてついでに負債を返す」か、「機能をとりあえず追加して負債を返却日に返す」の判断はどのようにされてらっしゃいますか？
負債の粒度にもよりますが、本当にサクッと直せるものであれば、開発をしながらついでに直すことはあります。
より大きいものについては、機能追加をするためにその負債を返済してからでないと開発が難しいと判断した場合は、その負債の返済も含めてプロジェクトとして進めます。
それ以外の場合は、負債返済日にまとめて直すという場合が多いです。
Like(1)
「使われてないページを削除」した話がありましたが、「本当に使われていない」というエビデンスはどのように取ってどのようにテストしたんでしょうか？
リクエストログとドメイン知識の組み合わせです。 基本的には直近3ヶ月でリクエストがないページは、使われてない、あるいはなくしたとしても問題がないとみなし、そのうえで、サービス開発当初からいて各ページの歴史的背景を知っているメンバーがいるので、その人による確認も行って、消しても問題ないと判断しました。
Like(0)
ここまで2つは会場でお答えしました。
Like(0)
シートに書き出した後に優先度って何を基準に決めていますか？
チームとしてやるべきタスクと個人的にやりたいタスクがあります。
チームとしてやるべきタスクについては、どれくらい早く対応すべきか（今日やった方がいいのか、次回以降でもいいのか）や、チームとして生産性が下がっている度合いといったところで判断しています。
個人的にやりたいタスクについては重要度を自己申告しています。
両者のバランスをどう取るかは難しいですが、「いい具合に」バランスを取りながらやっています。
Like(0)
今の現場では技術的負債を感じているものの、開発要件や問い合わせ対応が多くまず時間が取れない状況です。こういった外部要件をブロックする工夫は何かありますか?
問い合わせ対応については、エンジニアの中で週単位で持ち回りで受け付ける当番を決めて運用しています。 当番がわからない範囲のことについては、わかるメンバーに流します。 10人くらいで回しているので、自分の担当以外の週はあまりブロックされずに済みます。
また開発依頼などが来た場合も、それがプロダクトチームの中で優先度が高くないと判断した場合、プロダクトチームはこういうプロジェクトをこういう優先度で進めているので、今はできないですと正直に伝えます。幸いなことに、弊社ではセールスチームやCSチームの開発に対する理解が深いので、説明すると理解してもらえることが多いです。
Like(0)
チームはどのような単位で分けましたか？ また、どのチームに誰を割り当てるかはどのように決めましたか？
これは！1hくらい話せます！ｗ 基本はOKRを造れるような、目的別チームですね。うちのアプリだと、ライフログ、コンテンツ、KPIグロース、のようにいくつかサービスのKPIや目的で切っていました
Like(0)
KPI として納得度を測ったとのことでしたが、これは具体的にはアンケートをとったということでしょうか？
質問ありがとうございます！ アンケートはとらなかったです！納得度、アンケートとれたらよりよいかもしれません。アナログに対話してまだ懸念ありそうなかたをその時はみつけては会話してました。
Like(0)
聞き逃してたらすみません 何人規模ぐらいのプロジェクトでしょうか？
質問ありがとうございます〜 30名ちょいで、開発が25弱くらいでした。
Like(0)
「情報の流れを設計する」ときにビジネスサイドは巻き込みましたか？ 巻き込んだ場合、工夫したポイントを教えてください 巻き込みました！ 質問ありがとうございます！
ポイントは、相手のメリットに合わせて説明することでしょうか。PMならエンジニアへの説明コストが下がるとか。どっちが最後に決めるかは事前に決めておくのもポイントかもしれません。巻き込まない、ってのは良くないんですが、関係者増えると決定が大変なのはありますよね。
Like(0)
発表資料をブログに公開しましたぞ！ https://kakakakakku.hatenablog.com/entry/2018/12/08/165731
Like(1)
フロントエンド側のi18nはどのように対応されているか、知見があればお聞きしたいです。
(たとえばRails側とi18nのファイルを共有してるか、しているとしたらどのようにしているか、等)
Like(0)
「機能追加時にちょっとだけ手間を余計に掛けてついでに負債を返す」か、「機能をとりあえず追加して負債を返却日に返す」の判断はどのようにされてらっしゃいますか？
Like(1)
逆にレールから外れていないがために、新しく入った人がよく理解せずに使ってしまう、ということになりそうなんですが、そのあたりは大丈夫でしたか。
現状は人の移動が発生していないので問題は発生していないのですが、課題の一つですね。 github の README.md から辿れるドキュメントに Rails の拡張方針というドキュメントは用意していて、そこで把握してくれることを期待している感じです。
Like(0)
シートに書き出した後に優先度って何を基準に決めていますか？
Like(2)
発表の主題とはあまり関係ない話ですみません
「使われてないページを削除」した話がありましたが、「本当に使われていない」というエビデンスはどのように取ってどのようにテストしたんでしょうか？
Like(0)
今の現場では技術的負債を感じているものの、開発要件や問い合わせ対応が多くまず時間が取れない状況です。こういった外部要件をブロックする工夫は何かありますか?
Like(3)
「情報の流れを設計する」ときにビジネスサイドは巻き込みましたか？ 巻き込んだ場合、工夫したポイントを教えてください
Like(0)
チームはどのような単位で分けましたか？ また、どのチームに誰を割り当てるかはどのように決めましたか？
Like(0)
KPI として納得度を測ったとのことでしたが、これは具体的にはアンケートをとったということでしょうか？
Like(1)
聞き逃してたらすみません 何人規模ぐらいのプロジェクトでしょうか？
（後で写真がふんわり映りましたが）
Like(0)
逆にレールから外れていないがために、新しく入った人がよく理解せずに使ってしまう、ということになりそうなんですが、そのあたりは大丈夫でしたか。
Like(0)
Copyright © 2018 Yoshiyuki Hirano
Ruby on Rails という名前以外に、別の名称の候補はありましたか? あったら教えて下さい
Like(0)