エンジニア・コミュニティにはオープンであってほしい

エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。

さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであるのか、それともそれは「生得的な性差によるもので自然なこと」なのかということについては、ここでは踏み込まない。ただ、事実として、現状のジェンダーバランスはめちゃめちゃ偏っている。そういう中で、女性エンジニアは、エンジニアとして参加したはずのカンファレンスで人事のひとだと思われたり、あるいは自分の専門分野に対してなぜか「教えてあげるね」という態度で話しかけられたりするという報告がいままでもなされている。エンジニアとして参加したはずのカンファレンスで、エンジニアとしてではなく、「女性」として扱われるという体験をする女性は、どうやら多いらしい（ここで「どうやら」ということばを使っているのは、ぼく自身が男性であり、すべて伝聞情報でしかないからだ。だけど、周りを見ていて「そういうこともあるだろうな」と思ってしまうのも、また事実だ）。そういう経験をしている女性がいる、という前提の中で、「女性の外見を判別して自動でいいねを押す」という発表がなされて、それが受け入れられている、というのは、どういうメッセージになるのだろうか。ぼくはやっぱりそれって「やっぱりここでは女性はエンジニアとしてではなく"女性"としてしか扱われないものなんだな」と思われてもしょうがないのではないか、と思うのだ（もちろん、そう考えないひともいるだろう）。

勘違いしてほしくないのは、ぼくは「女性の外見を判別して自動でいいねを押す」という発表が「悪いものだ」と言っているわけではない。というか、ぼく自身けっこう女性の外見の好みにすごく偏りがあるし、好み抜きにしても類型化した外見について語ることだってあるし、そういう話を、すでに友人関係で信頼関係も築けている男性、あるいは女性とすることを楽しく感じるような感性の持ち主だ。ただ、「エンジニアとしてではなく女性として扱われがちで、なおかつ周りが男性だらけ」というとても特殊な状況でそういう話がある種公的になされる、というのは、すごく排他的なメッセージになってしまうのではないかなあ、という話をしているのだ（もちろん、どんな場であろうと「別に排他的じゃないと思うけど」という意見もあるだろうけど）。

件の発表について、技術的にはすごく興味深い話だったし、もちろんその技術的な面白さは一切毀損されるものではない。「エンジニアとしてではなく女性として扱われがちで、なおかつ周りが男性だらけ」という特殊な状況が前提になければ、「これは面白い話だね！」で済む話だとぼくは思う（これまた、そう思わないひともいるだろうけれど）。だからこそ、この特殊な状況が変化してほしい、とぼくは思っている。自由に、のびのびと、技術を語りたいからこそ、エンジニア・コミュニティには女性が「ここでは男女関係なく"エンジニア"として扱わるんだ」と思えるジェンダーバランスであってほしい。そのためにも、ぼくたち「マジョリティ」がどういうメッセージを発するかということは、とても重要なことだと、ぼくは思っています（という、メッセージです）。エンジニア・コミュニティがオープンであってほしい、ぼくはそう考えています。

追記

ある種の無自覚な傲慢さについて

ぼくはもう35歳で、どうあがいても中年のおじさんであるし、子供もいる「いい大人」のくせに、毎朝きちんと起きることができない。こうやって雑文を書いたり音楽をやったりすることでなんとか自分を保ってるような「現実不適合者」だ。だからいい歳してバンド活動もやめられない。たまたまプログラミングが好きでやってるおかげでなんとか社会との接点を保って経済的にやっていくことが可能になってる。プログラミングのおかげで社会と接点を持つことができて、文章と音楽のおかげでなんとか自己と世界のチューニングを合わせることができている。そんな感覚がある。

で、 まあ、話を戻して（？）バンド活動をずっと続けているわけだけれど、そのバンドメンバーのひとりにタダくんという男がいる。ぼくは彼のことをバンドメンバーとしてもとても信頼してるんだけど、それ以上に文学部の友人としても信頼している。というのも、彼はぼくと同じくらい、ともするとぼく以上に、「ある種の無自覚な傲慢さ」を撒き散らかす人間に対する激しい憎悪を持っているようにぼくの目からは見えるからだ。彼の「ある種の無自覚な傲慢さ」に対するアンテナはぼくにはとても高性能に見える。それは、ぼくにとっては、とても信頼すべき部分なのだ。もちろん、それはあくまでぼくが捉えた彼の姿であって、実際には彼はそんなに激しい憎悪をもってなんかいないのかもしれない。それはわからない。だってぼくは彼じゃないから。それでも、すくなくとも「ぼくにとっての」彼はそういう人物だし、それはぼくにとってはとても好ましいことに感じる。ぼくにとってはそれで彼を好きになるのに十分だ。

ところでさきほどぼくは「ある種の無自覚な傲慢さ」と言ったけれど、その内実について話したい。ほんとうならばもっと解像度の高い言葉をつかうべきだと思う。けれど、それをうまくぼくは説明できない。だからその代わりに例を挙げたいと思う。

たとえば「自分は自己表現が好きで」と言えてしまう「シンガーソングライター」。たとえば「感動を届けたい」と言ってしまえる「詩人」。ぼくはこういう人たちをほんとうに醜悪だと感じてしまう。いや、おまえだってバンド活動やめられない「シンガーソングライター」じゃねえか、と言われればその通りなのだけれど、言い訳をさせてください。ぼくはあまり「自己」を表現したいとか「感動をを届けたい」みたいなことはなくて、「表現そのもの」のほうにむしろ興味があったりして、あの、その、えーと、たいへんにめんどくさくなってきたので強い汚い言葉を使ってしまいますね。

要するに、「自己表現」な人を見ると、てめーには（というかふつう人間には）「表現に値する自己」なんてたいそうなもんはないし、てめーは「感動を届けたい」とか言ってるけど、感動するかどうかはこっちが決めるんだよ黙ってろこのタコすけ、みたいな気持ちになるわけです。で、こういう罵詈雑言が、もちろん歌ってる自分にも向かう。けど、すごい欠陥と欠損を抱えたまま生きてるせいで、音楽とか文章を書くことがやめられないんです、ごめんなさい、みたいな逡巡が自分にはある……。

あるいは、別の例。「どうして自分のことを理解してくれないんだ」という怒りを他人にぶつけてしまうようなひとにも、ぼくはとても醜悪な傲慢さを感じてしまう。というか、どうして自分のことを理解してくれるのが当然だと思っているのですか？そこに「自分には表現に値する価値のある自己がある！！」っていう自己表現さんと同じ傲慢さを感じ取ってしまうのだ、ぼくは。

もちろん、じゃあおまえがいま書いてるその自分語りはなんなんだよ、それは「自己表現」さんとなにが違うんだよ、と言われると「すみません…….」となってしまうのだけれど、冒頭にも言ったようにぼくはどうしても文章を書くことと音楽がやめられなくて、それはどちらかというとぼくの欠陥や欠落であって、そんなに褒められたものではない、とも思っているわけだ。一方で、たまになんかの偶然で、ぼくの欠落や欠陥を埋めるためのものが誰かの欠陥や欠落と深いところでひょいとつながっちゃうことがあって、もし偶然にそういうことがあるなら、こういう行為にも積極的な意味を見出せるかもしれない、という気持ちはあるにはある。いつもその点ですごく気持ちが引き裂かれている

だからたぶんぼくが激しく憎むのは、むしろ「無自覚さ」の部分なのだろう。その無邪気さがとても許せないのだ。こうして言語化してみるとなおのことこれはぼく側の欠陥であって、「自己表現」さんが悪いわけではない。けど、良い悪いと好き嫌いはまったく独立な軸として存在するわけで、そういう理由により、やはり「自己表現」さんは悪くないけどぼくはその無自覚さ（すくなくともぼくにそのように映る部分）に激しく嫌悪感を感じるのだ。

というわけで、ぼくの好き嫌いの話、ぼくの価値観の表明でした。とてもいい大人とは思えませんね。まあしかし、こればかりはしょうがない……

モンキーパッチよりも古式ゆかしいpatchのほうが良いシーンがあるという話

労働の現場においては、gemにオレオレパッチを当てたい、ということがまれにあります（あ、いい忘れてましたがこれからRubyの話をします）。もちろん、オレオレパッチは基本的には避けるべきものですが、そうも言っていられない深遠なる事情というのが、労働においてはある……。労働にはいろいろあります……。

さて、オレオレパッチの是非については一旦おいておいて、gemにオレオレパッチを当てたいとき、オープンクラスを利用してモンキーパッチを当てることが一般的には多いのではないでしょうか（繰り返しになりますがここではオレオレパッチの是非は問いません）。Railsを利用している場合、config/initializers以下にモンキーパッチのためのファイルを入れて、Rails起動時にgemの挙動を拡張、あるいは変更する、というような手段が多くの場合取られるのではないかと思います。

しかし、Railsを利用している労働の現場において、先日、Railsのbootstrap前、というかRackサーバーの読み込み前にgemにパッチを当てたい、という状況が発生しました。当然、Railsのbootstrap前なので、config/initializersの読み込みを待つわけにはいきません。

苦肉の策として、モンキーパッチを諦め、bundle install のあとに古式ゆかしいpatchコマンドを利用してライブラリ自体を実際に書き換えてしまうという暴力スクリプトを書いて物事を解決したのですが、その暴力の中で気づいたことがあります。それが、タイトルにもある、「モンキーパッチよりも古式ゆかしいpatchのほうが良いシーンがある」ということでした。

モンキーパッチの場合、パッチ対象のライブラリのバージョンが上がった場合などに、モンキーパッチの作者の意図しない挙動を引き起こすことがあります。別の言い方をすると、パッチ対象ライブラリのバージョンが上がった場合は内部が変わっていることがありうるため、本来はモンキーパッチ側も新しいバージョンに追従してメンテナンスしていく必要がある（たまたまモンキーパッチ側は書き換えなくてもうまく動く、という可能性は充分にある）わけですが、実際にライブラリの更新とモンキーパッチの更新の足並みを揃えるのは結構たいへんです。

一方、patchを当てるスクリプトの場合、パッチ対象となるライブラリのファイルパスをなんらかの形で埋め込んでおく必要があります。bundlerによってインストールされたgemは、バージョンごとに一意なファイルパスを持つし、仮に同じパスにインストールされたライブラリであっても、バージョンが代わりパッチ対象のファイルが書き換わっていたらpatchコマンドでのパッチに失敗します。これがなにを意味するかというと、patchコマンドによるパッチは、モンキーパッチと異なり、特定のバージョンのライブラリのみに対するパッチとして機能する、ということです。これは、そもそも危険なオレオレパッチの影響範囲を絞るという点でモンキーパッチよりも優れている部分があると言えるのではないでしょうか。

常にモンキーパッチよりもpatchコマンドによるパッチのほうが優れている、と主張する気はありませんが、「このversionのときだけパッチを当てたいなあ」みたいなときには、古式ゆかしいpatchコマンドによるパッチを検討してみるのも、ありなのではないか、というお話でした。逆にいうと、対象ライブラリのバージョンが上がっていってもこのパッチは当て続けたいんや！！みたいな場合はモンキーパッチのほうが有利かもしれません（が、それってかなり地獄への道を歩んでいる感じがする）。

危険なオレオレパッチは捨てやすい方法を選んだほうがいい場合がある、という話だと言い換えてもよいかもしれませんね。

webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前

twitterに書いたやつ再掲+加筆。

Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではないと思っています。ただ、Repository な責務でないものにRepositoryという名前をつけるのがあまり好きではない、という話です。

とはいえ、これは「好き嫌い」の問題なので、「このプロジェクトではそういう名前なんだよ」というのがチーム内で合意が取れてればそれはそれで、とも思います。ただ誤解は産みやすいからそこんとこコミュニケーションしっかりとりたいですね。

ちなみに、じゃあぼくがそれをなんて名前にするかですが、ぼくはよく「Gateway」という名前を使います。サーバーはフロントのSPAと異なるシステムなので、その境界をまたいだ処理を行う窓口だよ、という意味でのGateway。

以上がtwitterでしゃべったことです。以下は補足です。

いま扱ってるものが（たとえば）SessionStorageに保存しているものなのかネットワーク越しにあるシステムに保存されているものなのかを意識したくない、だからRepositoryという名前を使うんだ、という話もあると思うのですが、多くの場合APIサーバーは「たんにデータの出し入れ」じゃなくて、たとえば参照系のAPIなら集計をしたり、更新系のAPIなら複雑なロジックを実行したあとになにかを保存したり、それどころか別のシステムを呼び出して結果として誰かに通知が飛んだりなどが行われるかと思います。それと同等のことをローカルでできるでしょうか？もしできないとしたら、ネットワーク越しにあるシステムの呼び出しとローカルのストレージの読み書きを意識しない、なんてこと意味があるのでしょうか？また、仮にローカルでもおなじこと（集計やら複雑なロジックを伴ったデータの更新）ができるとして、その場合それって「Repository」なのでしょうか。Repositoryと言うには賢すぎる気がしますね。

もちろん、APIが完全にリソース志向で、ロジックはほとんどローカルにあります、みたいなアプリケーションなのであれば、そのAPIのwrapperをRepositoryとして扱うことが可能でしょう。たとえばあまりユーザー同士のインタラクションがなくて、クラウドは単なるデータ置き場である、みたいなアプリケーションの場合とかは、そういうやり方が適するかもしれません。また、ユーザごとの設定値のようなものについては、たしかにローカルに保存しているのかネットワーク越しのシステムに保存しているのかは意識したくないかもしれませんね。こういったものについては、自信をもってRepositoryとすればいいと思います。

そう考えると、もしかするとひとつのSPAの中で、このAPI呼び出しはGatewayという名前、あのAPI呼び出しはRepositoryという名前、ということが起こるかもしれません。これは良いことでしょうか悪いことでしょうか。ぼくは「良いこと」だと思います。一貫性がない？　けどそもそも、実装（それがローカル保存なのかネットワーク越しのシステム保存なのか）を意識したくないから、意識しなくていい名前をつけよう、という話だったはずです。そう考えると、「別のシステムに対する処理の移譲（その別のシステムがどこにあるかは意識しない）」についてはGateway、「データの保存と読み込み」についてはRepositoryを使う、というのはかなり筋が良いようにぼくには思えます。

というわけで、「webフロントエンドからwebAPIを呼び出すのをwrapするアレの名前」について考えてみました。みなさんのご意見もぜひ聞かせてください。

知識問題と思考問題

最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。

もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。

ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。

一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、設計原則などは役にたつが、それは「検算」的な部分で役に立つ感じで、問題とがっぷり四つに組んで頭に汗をかいて設計しなければならないように感じる。

これがマイクロサービシーズになってくると、どのようなマイクロサービスにどのような責務を負わせ、どのように分割するのかがかなり思考問題寄りで、サービス間の連携についてはけっこう知識問題に寄っているように思えるのがおもしろいところだ。

そんな視点で眺めてみると、去年ぼくがbuildersconで話した開発現場で役立たせるための設計原則とパターンという発表は、設計原則やパターンは、このように活用すると思考問題を解く際の武器にできるよ、という話をしているというように理解ができそうだ。一方、今年のbuilderscon に応募している（たのむ！採択されてくれ！）、Ruby (off|with) the Railsという発表は、かなり知識問題よりの領域を扱っていると思う。まあこの記事で言いたかったのはそういう予告です……。

ところで、知識問題を解くための武器とも思考問題を解くための武器だったら、なんだか思考問題を解くための武器のほうが「ありがたがられ」そうな気がするけど、これらに優劣はない、とぼくは思っている。思考問題を解くための武器は錆びつくのが遅いけど、一方で「すぐに役立てる」のが難しい。知識問題を解くための武器はすぐに陳腐化するけど、明日からすぐに役立てやすい。これらは優劣ではなく、性質の違いだ。

自分が問題に向き合ってる時に、いま知識問題に向かい合っているのか思考問題に向き合っているのかは少し意識してみると、自分がいま向き合うべき問題なのかを考えられたりとか、「知識問題だけど知識が足りないから、すぐ使えるやつを仕入れてこよーっと」みたいなムーブができたりとかできて良いかもしれない。いや、しかしこれは「知識問題だとわかるためには知識が必要」という問題があるか？

あー、でも、少なくとも、ジュニアエンジニアが知識問題に戸惑ってたらシュッと知識をインストールしてあげる、思考問題に戸惑ってたら本人の気づきをナビゲートしてあげる、みたいなことはできそうですよね。知識問題と思考問題という視点はけっこう便利であるなあと思います。

なんかとりとめない話になっちゃったけどブログだからいいよね。

rubyのString#splitのおもしろ挙動

RubyのString#splitは、下記のようなおもしろ挙動を持っている

"  a\nb \t c   \rd  ".split(' ') # => ["a", "b", "c", "d"]

これは（とうぜんのことながら）ちゃんとDocumentedである

docs.ruby-lang.org

1 バイトの空白文字 ' '
先頭と末尾の空白を除いたうえで、空白文字列で分割する。

便利なんだけど知らないでいると意図せぬバグを埋め込んでしまうかもしれないので、知っておいて損はないかもしれない（ぼくは今日知った）

RailsのControllerにApplicationService相当のロジックを書くのはありなしや？

誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。

これについてです。

結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。

なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplicationServiceを分けるべきなのか」について考えてみたいと思います。ControllerとApplicationServiceを分けるのは、PDSの文脈において、ControllerがPresentation（ユーザーとのインタラクションに関わる部分）のレイヤーに属すものであり、ApplicationServiceはDomainに属すものである、という理解がまずあるからだと思います。

では、なぜPDSが重要なのでしょうか。原典を引きましょう

  • プレゼンテーションロジックとドメインロジックが分かれていると、理解しやすい
  • 同じ基本プログラムを、重複コードなしに、複数のプレゼンテーションに対応させることができる
  • ユーザーインターフェイスはテストがしにくいため、それを分離することにより、テスト可能なロジック部分に集中できる
  • スクリプト用のAPIやサービスとして外部化するためのAPIを楽に追加できる（選択可能なプレゼンテーション部分で見かける）
  • プレゼンテーション部分のコードは、ドメイン部分のコードと違ったスキルと知識が必要

Martin Fowler's Bliki (ja)より

ぼくのことばで言い換えると、

  • プレゼンテーションはテストしにくいから、ドメインに分けておくとテストがしやすくなる
  • 責務が明確に分離されてわかりやすくなる
  • 他のプレゼンテーションレイヤーに差し替えが可能（Railsの例で言えば、ApplicationServiceに分離しておけば、たとえばTaskからも呼べる）

の三点が、PresentationとDomainを分離する際の嬉しいポイントです。ここで、RailsにおいてControllerにApplicationServiceを書いたときにどれだけこの問題が顕在化するかについて考えてみます。

まずは「プレゼンテーションはテストしにくいから、ドメインに分けておくとテストがしやすくなる」についてです。これ実はRails使ってるとあんま問題じゃなくて、というのもRailsってControllerのテストめっちゃふつうにしやすいじゃないですか。だからこれはあんまり問題にならないと思っています。

続いて、「責務が明確に分離されてわかりやすくなる」です。これについてはちょっと丁寧に見ていきましょう。おそらく、RailsでControllerとApplicationServiceを分離すると、Controllerの各メソッドは「1,2行書いておしまい」というメソッドになるでしょう（そうじゃなかったらちゃんと分離できてないと思ったほうがよさそう）。こうなると、「Controllerいる？」って感じになってきますよね。これが静的型付け言語の場合で、しかもVannila DIだったりCakePatternしてる場合なんかは、Controller部分でDIしてたりするので、Controllerに責務が残りますよね。あと、MVVMで作ってるGUIアプリケーションの場合、ローカルステートの管理などがVMの責務として残ります。けど、Railsの場合、ApplicationServiceをControllerから切り出すとそこに責務ってほとんど残んないんですよね……。あるとしたら認証とかかな。けどこれもControllerのテスト対象メソッドでやるんじゃなくて普通はレイヤスーパータイプとかでやってますよね。というわけで、なんか特殊なHTTPの言葉の部分触ってるとかそういうのがないのであれば（あーセッション周りとかはなにかしらあるかもですね）（しかしセッションって本来Infrastructureだよな〜）、「RailsにおいてはApplicationService相当のロジックをControllerに書くとする！」ってするのは十分にメイクがセンスするし、パルスのファルシのルシがパージでコクーンなのではないかとぼくは思います。

最後に、「他のプレゼンテーションレイヤーに差し替えが可能（Railsの例で言えば、ApplicationServiceに分離しておけば、たとえばTaskからも呼べる）」についてです。ここについては実はControllerにApplicationService相当のコードを書いてしまうと問題が顕在化します。TaskからApplicationServiceを呼び出すのはとても簡単ですが、TaskからControllerを呼び出すのは簡単ではありません。しかし、ちょっと立ち止まって考えてみると、ほんとうにそんな柔軟さはRailsアプリに必要なのでしょうか？？？今まで、「あー、TaskからController呼び出せたら最高なのにな〜」って思ったこと、あります？　ぼくはほとんどないです。そのために新たな層を導入して複雑さを引き受けるの、コストがペイするのでしょうか？パルスのファルシのルシがパージでコクーンなのでしょうか？

しかし、じつは、ここがぼくの「趣味」の部分で、ぼくはこれのためにApplicationServiceを分離してんですね。なぜか。そうすることで、たとえばテストの、しかも「前提データ」を用意するときに嬉しいことが起こります。Rails文化ではなぜか（なぜかと言ってしまおう）FactoryBotが人気で、FactoryBotを利用して前提データ（たとえば、ログイン可能なユーザーアカウントとかね）を作るプラクティスが横行していますが、ぼくは以前から、なぜここでみんな（たとえば）「UserSignupApplicationService」を作ってそれを呼び出すだけにしないんだろう、と不思議に思っています。適切にApplicationServiceが書かれていれば、UserSignupApplicationServiceを呼び出すだけで前提データは作れるはずです。FactoryBotを利用して前提データを作る場合、「サインアップ」の仕様が変わると「UserSignupApplicationService」と、「サインアップ済みユーザー」を作り出すFactoryBotを使った部分両方のメンテが必要になってきます。一方、FactoryBotではなくてApplicationServiceを利用すれば、ApplicationServiceのメンテのみで済みます。なぜ「テスト済みの、前提データを作れる部品」があるのに、FactoryBotを使う必要があるのでしょうか？

という観点に立つと、意外とApplicationServiceを分離することには価値がありそうですが、世の中的にはFacyoryBotが主流だし、「Railsにおいて」という前提に乗っかるなら、これはかなり「異端児の意見」であろうな、というのもわかるので、アンケートの答えとしては「正しい」を選ぶ、けど自分はあまりやらない。という感じになるわけでした！

以上、ぼくの意見です。みなさんの意見もぜひ聞かせてください。