RubyのString#splitは、下記のようなおもしろ挙動を持っている
" a\nb \t c \rd ".split(' ') # => ["a", "b", "c", "d"]
これは(とうぜんのことながら)ちゃんとDocumentedである
- 1 バイトの空白文字 ' '
- 先頭と末尾の空白を除いたうえで、空白文字列で分割する。
便利なんだけど知らないでいると意図せぬバグを埋め込んでしまうかもしれないので、知っておいて損はないかもしれない(ぼくは今日知った)
RubyのString#splitは、下記のようなおもしろ挙動を持っている
" a\nb \t c \rd ".split(' ') # => ["a", "b", "c", "d"]
これは(とうぜんのことながら)ちゃんとDocumentedである
- 1 バイトの空白文字 ' '
- 先頭と末尾の空白を除いたうえで、空白文字列で分割する。
便利なんだけど知らないでいると意図せぬバグを埋め込んでしまうかもしれないので、知っておいて損はないかもしれない(ぼくは今日知った)
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。
Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする
— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019
これについてです。
結論から先にいうと、ぼくは「正しい」と思っています(ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています)。
なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplicationServiceを分けるべきなのか」について考えてみたいと思います。ControllerとApplicationServiceを分けるのは、PDSの文脈において、ControllerがPresentation(ユーザーとのインタラクションに関わる部分)のレイヤーに属すものであり、ApplicationServiceはDomainに属すものである、という理解がまずあるからだと思います。
では、なぜPDSが重要なのでしょうか。原典を引きましょう
ぼくのことばで言い換えると、
の三点が、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において」という前提に乗っかるなら、これはかなり「異端児の意見」であろうな、というのもわかるので、アンケートの答えとしては「正しい」を選ぶ、けど自分はあまりやらない。という感じになるわけでした!
以上、ぼくの意見です。みなさんの意見もぜひ聞かせてください。
まずこちらをお聞きください。つるえさんというボーカリストの方に楽曲提供をさせていただきました。ぼくは作詞・作曲・編曲・コーラス・ギター・ベース・打ち込みを担当しています。
つるえさんと知り合ったのは荻窪にあるアルカフェというアコースティックライブバーで、初めてお会いした時にその歌のうまさに衝撃を受けたのをとてもよく覚えています(この音源も、ボーカル補正なしですよ。めっちゃうまくない?)。
歌がうまい、というのには、いくつかの要素があるとぼくは思っています。まず、ピッチが正確であること。自分の歌を棚に上げて言うと、これが大前提。そこから先は個性や好みの話が関わって来て、たとえば一聴してそのひとの歌だとわかる強い個性、あるいはクセを持ったボーカル、というのがひとつあると思います。日本のポップシンガーで言うと、たとえば山崎まさよしさんとか奥田民生さんをイメージしていただくとわかりやすいのではないでしょうか。
実は、つるえさんの歌唱にはそういう「一聴してこのひとだとわかるクセや個性」はあまりありません。ただ、誤解して欲しくないのは、ここで言っているのは、アーティキュレーションのクセや発音のクセの話であって、声そのものの話ではないです。つるえさんの声は、地の声に芯があり、その芯の周りにツヤのある響きを纏わせていて、とても魅力的な個性があると感じます。そして、おそらく意図的に、歌唱法で「ここはこういう表情」「ここはこういう表情」というのを非常に幅広く、自覚的に使い分けています。アーティキュレーションや発音に、強烈な個性がないからこそ、とても幅広く表情をつけていて、変幻自在ですごい。
そして、そういうボーカリストに出会ってしまった、自分自身は歌が下手なコンポーザーが思うことと言ったらひとつしかないですよね。「このボーカリストに歌ってもらう曲を書きたいなあ」。その夢がかないました。書きました。歌ってもらっちゃいました。それが冒頭に貼った「Sounds Around (My Life)」という曲です。
このコラボレーションは、スタジオ録音などをしているわけではなく、リモートでコラボしていて、なんとボーカル録りは「iPhoneのボイスメモ」でやっていただくという荒業を見せています。このあたりにもっとリソース使えれば、もっともっとダイレクトにつるえさんの歌の素晴らしさを音源に残すことができたのですが、それができなかったことだけがとても残念です(ていうか、その録音環境でこの歌のクオリティなの、いい意味でヤバすぎませんか?大事なことだから二回言うけど補正もほとんどしてないんですよこれ)。
そんな心残りはあれど、ぼくが思うつるえさんのボーカルの「美味しいところ」のためにメロディを作り、つるえさんの声の魅力の邪魔しないように控えめな、しかし丁寧な編曲を心がけて、つるえさんの声で聴いたらとても綺麗にイメージが届くであろう歌詞を頑張って書いて、つるえさんの歌が主役になるようにミックスをしました。ソングライター、アレンジャー、DTMerとしての「このボーカリストに歌ってもらいたい」というエゴにめちゃめちゃに素直になった結果、全ての要素がつるえさんのボーカルに奉仕するようなつくりになっています。これでつるえさんの歌の魅力が伝わらなかったとしたら、それはもう完全にぼくの力不足以外のなにものでもありません。ぜひ多くの方に聴いていただきたいと思います。よろしくどうぞ。
前回の記事の続きです。
前回は、「時代が変わるとサーバーアプリケーションの役割も変わるよね。そうすると必要な要素技術も変わっていくよね」という話でした。今回は、じゃあ「サーバーアプリケーションがJSON喋るマンになって、クライアントアプリケーションとの協働でユーザー体験が実現されるようになってきた今、"ビジネスロジック"はだれが持つべきなの?」って話をしたいと思います。
さて、サーバーサイドでなんでもやる牧歌的な時代は過ぎ去り、クライアントサイドとサーバーサイドがコラボレーションしてひとつの体験を提供するようになった昨今、「そのアプリケーションの体験を成り立たせるための"ロジック"をどっちに書くのか」という問題が立ち上がってきます。わたしの私見ですが、これはなるべくならサーバーサイドで請け負ってあげるのがよいのではないでしょうか。その理由は、クライアントサイドにはクライアントサイド特有の複雑な問題を抱えているため、そのほかの問題はサーバーサイドで抱えてあげたほうが全体の複雑さが減るからです。
HTTPというのは基本的にステートレスなプロトコルです。そのため、基本的にはサーバーサイドの状態は1リクエストごとに閉じています。リクエストを受け付ける時にはまっさらな状態で、レスポンスを返すまでには様々な状態をもちそれらに対して様々な計算をして、レスポンスをかえします。このとき状態は一度破棄され(あるいはRDBなどの外部に書き出され)、次のリクエストのときにはまたまっさらの状態でそのリクエストを処理し始めます。
一方、クライアントサイドでは、ブラウザSPAアプリならばブラウザをリロードするか別のサービスに遷移するまで、メモリ上に状態を持ってしまいます。とうぜん、これはネイティブアプリでも事情は同じです。やったことのあるひとにはわかると思いますが、この状態の管理は、それだけでけっこうめんどくさいものです。
また、その「状態」から複雑な画面を構築しなければいけないというめんどくさい問題も、クライアントサイドは抱えています。画面作るのほんとに面倒で、そこにユーザーインタラクションがからむともっともっと面倒です。そういうめんどくさい問題を抱えているのに、さらに複雑なビジネスロジックまで押し付けられるのはあまりに大変ですので、困難を分割するためにも、サーバが出来る限り複雑さを引き受けてあげるのがよいのではないかと思います。
また、サーバーサイドに複雑なロジックを持っておくことで、複数のプラットフォームでのアプリ展開がやりやすくなる、という面もあります。たとえばiOSアプリもAndroidアプリもwebアプリも作る、というような場合に、クライアントサイドにビジネスロジックを持っている場合、それぞれのアプリで毎度実装する必要が出て来ますが、サーバーサイドでロジックをもってあげればサーバーサイド一回の実装ですみます。
また、クライアントサイドで一生懸命複雑なことをやったとしても、サーバーにとってリクエストは「だれから送られてきたかわからないもの」なので、結局サーバーサイドでデータの不整合が起こらないように検証はしなくてはいけません。そういった検証はまさにビジネスロジックの一部であり、クライアントサイドでビジネスロジックを持った場合、サーバーサイドでも重複したロジックを書かなければならない、というようなことは容易に起こり得ます。
しかし、これらの状況は、そのサービスが、ファーストパーティに閉じたサービスなのか、それともサードパーティに対して開かれたプラットフォームを目指すのかによって、事情が変わってきます。
ファーストパーティに閉じたサービスの場合、APIは「このアプリ専用」に作ることができます。いわゆる「顧客-供給者の関係」ですね。アプリ側の都合に合わせてAPIを作ることで、「複雑なビジネスロジック」をサーバー側が引き受けることになります。
一方で、サードパーティに開かれたプラットフォームの場合、不特定多数のクライアントに対して応答する必要があります。そのときに、サーバーサイドは、あるクライアントが解こうとしている問題に特化したAPIを提供するわけにはいきません。そんなことをしたら、クライアントの数だけAPIの種類が増えてしまいます。そのため、サードパーティに開かれたプラットフォームでは、サーバーサイド側になるべくロジックをもってあげることが難しくなります。プラットフォーム側の「ビジネスロジック」は薄くなる傾向があるでしょう。
しかしこれは、考えてみると当然のことです。というのも、プラットフォームというのは、「ぼくたちのデータや資源を使って、きみたちの問題を解決してね」というサービスなわけで、そうなってくるとどうしても問題を解く主体は、プラットフォームではなくてそのユーザーとなるでしょう。つまり、ユーザーは、ユーザーごとに異なる問題と向き合うことになるわけです。そのときに「ドメインロジック」がクライアント側にもたれるようになることは、ある意味当然となります。もちろん、このときプラットフォームにとっての「クライアント」が、webブラウザであるとは限りません。プラットフォームのユーザの選択によっては、webブラウザだけで完結するかもしれませんが、あるいはプラットフォーム利用者が自前でサーバーを立てて、そのサーバーサイドアプリケーションがプラットフォームにとってのクライアントとなるかもしれません。しかし、プラットフォーマーが持つサーバーアプリケーションは、特定の問題のための「ビジネスロジック」を持たない、ということには変わりがないでしょう。
というわけで、まとめると、
という感じになります。
前者の場合、最近だとリソース指向なAPI(いわゆるRESTfulなAPI)よりも「ユースケース指向」なAPIが増えてきていると感じます。ユースケースと1:1になるようなエンドポイントが生えてるようなAPIですね。
一方で後者の場合はユースケースはクライアントに依るので、mutationに関してはリソース指向のAPIがマッチしそうです。一方、リソースの取得についてはクライアントによってほしいデータが違うという問題があり、そのあたりにはGraphQLの恩恵がききやすいのではないか、という理解をわたしはしています。
次回書く気になれば、次回は
あたりを書けたらいいなと思います。が、もしかしたらtwitterでバーっと書いて満足してしまうかも……。
最近、2019年のwebAPIの設計まわりの問題について考えていて、問題とその周辺技術の整理を自分の頭の中でしています。 で、その内容をたぶん何回かに分けて書きますが、初回の今日はちょっと導入として浅めの部分を整理してみようと思います。
昨今、サーバーサイドの仕事はもっぱらJSONなどをしゃべることに終始して、エンドユーザーが触る画面をサーバーがレンダリングする事例は減ってきているのではないでしょうか。これはぼくが考えるに不可逆な事態で、今後もユーザーが使うインターネットにつながるデバイスは多様化していくし、それぞれがそれぞれにネイティブな環境を持ち、それらがHTTPSを喋ってインターネットとつながる、という世界はしばらく変わらないでしょう。言葉を変えれば、サーバーサイドでHTTPをしゃべるお客さんが、エンドユーザーからクライアントアプリケーションというプログラムに移行してきている、ということです。
その結果、サーバーサイドからは「複雑な画面を作る」という責務が奪われます。その結果がサーバーサイドアプリケーションになにをもたらすのかを考えてみたいと思います。
まず、Railsなどでよく使われる文脈でいう「decorator」は、昨今においてはその存在感を少しづつ失っていくでしょう(Pythonとかのデコレータとは文脈が違うので注意)。そもそも、この文脈におけるdecoratorは、「画面が要求する様々な"ちょっとした計算"」というプレゼンテーションの関心がモデル(ここでいう「モデル」というのはRailsの文脈でいうような「モデル」です)に混じってしまうことを避けるためのソリューションでした。しかし、昨今ではサーバーサイドアプリケーションがそのような複雑な画面をレンダリングすることはなく、jsonをペロッと吐けばいいだけです。そこには「画面が要求する様々な"ちょっとした計算"」は必要なく、むしろそれは画面を構築するクライアントサイドのプログラムでやってもらうべき仕事となるでしょう。
この「デコレータいらなくなったよね」という話は、牧歌的な「サーバーで全部やります」な時代が終わり、解くべき問題が変化した結果、必要な要素技術が変化していく1例として考えられるのではないでしょうか。ここで確認したかったのは、「デコレータがいらない」という話ではなく、 むしろ「問題がかわったら必要な技術が変化する」ということです。
さて、サーバーサイドからは「複雑な画面を作る」という責務が奪われたわけですが、昨今新たに出てきた新しい問題として、「じゃあサーバーとクライアントの間でどういう責務分割をするべきなの?」「サーバー側はサーバー側で昔と比べて複雑さ増してきてるよね?それをどうする?」というものがあります。次回以降、そのあたりの問題を整理しながら、どういう問題に対してどういう技術が効いてくるのかを書いていこうと思います。
まだ詳細未定ですが、予告としては、
あたりを書きたい。本当に書くのかは不明。@qsonaさんあたりとtwitterで喋ったら満足して書かない可能性もあります。
やんざむ先生のこのツイートを見て考えたことをまとめます。
UseCase がわからない...
— Yuki Anzai (@yanzm) February 15, 2019
FizzBuzz で
「3の倍数のときは fizz が返る」
「5の倍数のときは buzz が返る」
「3の倍数かつ5の倍数のときは fizzbuzz が返る」
「3の倍数でも5の倍数でもないときはそのままの数字が返る」
これは
結論を先に書くと、「これはそもそも問い自体が不適切である」(しかし強いて言えばEntity)という立場をわたしは取ります。以下、まじめにFizzBuzzを設計しながら考えてみます。
ひとまず、出発点は上にあるツイートの疑問から出発するとしましょう。
まず前提として、ぼくはユースケースを「ドメインモデル(このツイートで言うところのEntity)やインフラストラクチャのオーケストレーションをする部分」だと思っています。
たとえば、「あるボタンをクリックされたら、複数のドメインモデルを利用して生まれた結果を、データベースに保存する」というのは、複数のドメインモデルとインフラストラクチャ層にあるリポジトリを 組み合わせて 、システムのユーザーのアクションに1対1で対応する「ユースケース」を実現しています。
つまり、ユースケースというのは、
ものだ、と考えています。
さて、翻って、FizzBuzzについて考えてみましょう。まず、FizzBuzzを無理やりアプリケーション層とドメイン層に分けて考えるとしましょう。その場合、
というのは、FizzBuzzという問題領域を定式化、つまりまさにモデル化したものだと言えるでしょう。なので、これをドメインレイヤーのものであると考えるのは妥当だとすることにそれほどの無理はないでしょう。
ドメインレイヤーでこの定式化された知識をどのように分割するか、という点では、いくつかの判断がありえます。ぼくがぱっと思いついたのは以下のような感じです。
前者の発想だと、以下のような実装になります。
case class FizzBuzzNum(i: Int) { def asFizzBuzzFormat = i match { case i if i % 15 == 0 => "FizzBuzz" case i if i % 5 == 0 => "Buzz" case i if i % 3 == 0 => "Fizz" case i => i.toString } } object FizzBuzzService{ def doFizzBuzz(max: Int): Unit = { (1 to max) .map(i => FizzBuzzNum(i).asFizzBuzzFormat) .foreach(println) } }
一方で後者の発想だと以下のような実装になります。
object FizzBuzzService{ def doFizzBuzz(max: Int): Unit = { (1 to max) .map{ case i if i % 15 == 0 => "FizzBuzz" case i if i % 5 == 0 => "Buzz" case i if i % 3 == 0 => "Fizz" case i => i.toString } .foreach(println) } }
これは、どちらのほうが「良い設計」でしょうか。設計のレビューをするときに参考にすべきなのが各種設計原則です。そして、設計原則を適用した際の結果というのは、「問題がどのようなものか」に依存するのでした。このあたりの詳しい話は実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018を参照してください。
さて、FizzBuzzについて、「どの部分に今後の変更がありえて、どの部分に今後の変更がないのか」を考えてみましょう。それを考えると、実は「FizzBuzzは完成された問題であり、今後の変更はない」という答えが見えてきます(!)。そうである以上、上のふたつの設計のどちらが正しいかなんてありません。問題が十分に小さいため、どちらのコードもそれなりに可読性があるし、あとはもう趣味の問題です。好きな方にすればいいと思います。
さて、ドメインレイヤーの設計が終わったところで、ユースケースのことを考えてみましょう。ユースケースは
ものなのでした。しかし、今回の例に「複数のドメインモデルやインフラストラクチャ層のオブジェクトをオーケストレーション」する必要はあるでしょうか?「ない」というのがその答えではないでしょうか。そうなると、FizzBuzzという問題領域において、ユースケース層の役割は「無い」ということになります。プレゼンテーション層から直接このドメインサービスを叩くだけで良いでしょう。つまり、そもそもFizzBuzzを真面目に設計すると、多層からなる設計は不要というか、多層からなる設計をしようとしたら「役割のない層」が生まれてしまうという、考えてみれば当たり前のところに落ち着いてしまうわけです。
そして、ユースケース層の役割が「無い」ような問題領域を例にとって「ユースケースとはなにか?」を考えても、おそらく意味のある答えは期待できないでしょう。それを考えると、どうしても「これはそもそも問い自体が不適切である」という結論が出てきてしまうのです。
このエントリの内容を要約すると、以下のようになります。
追記:
アプリケーション全体のうち一部はユースケース層あった方がよいからユースケース層作った結果、別の部分ではなくても十分っていうかユースケース層見てみたらドメインサービス叩いてるだけ、みたいなことになることはあります
— しんぺい live at 荻窪alcafe 2/16昼 (@shinpei0213) February 15, 2019
ぼくは空気を読むのが得意な方ではない。と書き始めて思ったけれど、そもそも、おそらく「自分は空気を読むのが得意で」などと自信を持って言えるひとはそうそういないかもしれない。頭ではそうわかっているのだけれど、感情の部分で「"空気を読むのが得意で"と自信を持って言えるひとはいいなあ」なんて思ってしまっている自分もいるのだ。
だって、「自分は空気を読むのが得意で」と自信を持って言えるようなひとは、逆説的なことだけれど、なんだかむしろ「自然体」で過ごしているような気がする。「空気を読む自分」と「その空気の中にいる自分」の間に1mmのズレもなく、「空気の当事者」であることに対して違和感を感じることなく過ごせる、そんな自然体。そんな明瞭な当事者でいられる強さ。「自分は空気を読むのが得意で」とてらいなく言えてしまうひとには、そんな強さを感じ取ってしまう。
翻って自分を見てみると、なんだか空気を読む自分とその空気の中にいる自分の間に、もやもやとしたズレがあるような気がする。べつに「空気を読んでしまった結果本当の自分を殺してしまっている!」なんて思っているわけではない。むしろ本当の自分なんてものがあるのであれば、きっともっと自然体で空気を読めるのではないか。本当の自分なんてものをしっかり持っていれば、本当の自分と「場に求められる自分」の間の距離をしっかりと測ることができる。だからこそ自然に空気に順応することができるのではないか。ぼくの場合、むしろ本当の自分みたいなものがなんだかふわふわしているから、自分と場の距離感を掴みそこねて、場の空気を読もうと変な力が入りすぎて空回りしたり、逆になんだか全然空気を読めなくて無礼な感じになってしまったりしているのではないか……。
しかも、そんな自分を、まるで他人のように、ズレた位置から眺めている自分。ぜんぜん当事者な感じがしない。当事者になれないままなんだかふわふわとプログラマの定年と言われる35歳を迎えようとしています。そのあとは不惑が待っている。ふわふわとしたまま不惑を待つ。けどまあ、きっとみんな大なり小なりそんなふわふわを抱えて生活してるのではないか。ふわふわしたまま大人になったっていいじゃない。だめ?