『関数型プログラミングに目覚めた！』のレビュー（Day-1）について

なぜこれを書いているか

『関数型プログラミングに目覚めた！』のレビュー（Day-1）

という記事がMay 09, 2015、QiitaにUpされました。

この本については、邪な連中が多く、私もずいぶん不愉快かつ理不尽な思いをしてきましたので、この文責を伴わない「捨てアカウント」のレビュアが表明する前提の真実性を性善説をもってナイーブに信用することも当然難しいです。Qiitaにおいて、こういうことはこれまで何度も繰り返されてきました。特にこの記事に引用されている　@camloeba　というこの辺の輩のTweetをわざわざひっぱってきているあたり、ああまたやっているのか、と思わないこともありません。

実際、このレビューが着目する論旨は、私が、直近の記事、
『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間 』の著者として、『数学ガール』の著者である結城 浩氏に申し上げます。本書のたいせつな潜在的読者の読書機会を奪わないでください。

の冒頭の章で、（嘘を書いているのでない限り）とAmazonレビューで嘘を書かないこと、それが技術的議論のための最低限の要件であると批判した、レビューの着目点と同一です。
たとえば、Amazonレビューの

タダでも読む必要のない（というより読むべきではない）書籍
本書の技術的内容は質的にも量的にもその7割が「0から9までの数をすべて足すコードを書け」ということに尽きています。

とりもなおさず関数型プログラミングの説明を本書のようにJavaScriptでしようとすることが最初から不適切な選択であることを示しています。

と、この記事の、

「0〜9までの数をすべて足すコードを書け」について
このテーマはDay3の終わりまでほぼ200ページ（つまり本書の半分）を占めています。
素人としては深入りを避けたいと思いますが、そうだとすればそもそもJavaScript選んじゃったのが関数プログラミングへの無理解を象徴的に示すものなのだということになるような気がします。）

とか、まったく同じことを書いています。

@camloebaのごくごく最近のツイートを全面的に援用して、

素人としては深入りを避けたいと思いますが、そうだとすればそもそもJavaScript選んじゃったのが関数プログラミングへの無理解を象徴的に示すものなのだということになるような気がします。）

などと、「大学生の教育用に検討した本の書評」ではなく「筆者の選択眼と、無理解」をいきなり批判するあたり、ああまたか、という印象を後押しします。

今後Day2、Day3のレビューもされるそうですから、この着目点の類似性、同一性は今後さらに明らかになってくるでしょうし、この記事を書いている人の背景説明の真実性もより検証しやすくなるとは思います。

しかし、本当である可能性ももちろんあり、そうであるならば、プログラミング教育の対象として本書に関心を持ちながら購入いただいたことに感謝いたします。このように、性善説により感謝するという行為自体もしがたい状況、実際にそう感謝すれば、嘲笑を伴う裏切り行為が繰り返されたことを許しがたく思います。

この人物の背景説明を信用するにしても、しないにしても、以下、事実のみを著者として論評します。
いちいち反応するな、という意見もあるでしょうが、著者自身による記録として有用であるはずです。
この人物が書いているように、

否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています

という同じレベルの話です。
その否定的評価にせよ理由が間違っている、もしくはそのような誤解を招いたことの説明は著者として可能であるからです。

もちろん、先入観のない読者の誤解を招いたのであれば、そえは、書き手の責任であるのは言うまでもありません。

Amazonレビューで同じ論旨のものを見た「前回」よりも、あからさまな「嘘」は書いていないことは、まずまず評価できます。

Day1については無料公開しているのだから、リンクを貼れば良いと思う

このレビュー記事は現行、本書Day1のみですが、ほんとうによくわからないのは、当ブログで無料公開していることはご存知でしょうから、まずは閲覧者の知性と感性を尊重して、信用して、現物を見せれば良いのに、と思います。
Day1はたいして長い章ではありません。

なんでこういうことを書くかというと、

続くかどうか

本書で最もreadableなDay1ですら、改めて読み返したところひどく疲れてしまいました。Day2について、すぐに続きを書くことは難しいでしょう。

と「主観」をもってこのDay1レビューは締められているわけですが、他の否定的レビューもそうなのですが、それは本当に、あなたは潜在的読者のためになる、この人物も言うように、

否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています

と思って書いているのか？と疑義があるからです。

最終的に「何かを得られるか」「役に立ったか」そうではないか、というのは読者自身が決めることです。レビュアの主観ではありません。

あなたは、残念ながらひどく疲れてしまったのかもしれないが、本書Day1は公開後、SNSでは、関数型プログラミングの魅力に初めて触れられた、本が出たら買う、と価値を認められた読者が非常に多かった、それ故に、出版社でも企画がすんなり通ったという実績があります。

実際にその試みは現在よりもまだずいぶんマシな状況であった、Day1をはじめて公開した直後のSNSの反応では成功しており、それは今現在も公開されているのだから、それを読んだ後、はたして関数型プログラミングの概要と魅力がつかめるか、つかめないかは、読者が一読した判断です。

こんなレビューはまったく必要もない、ってことになります。

Day1の存在意義

Day1は、フックです。

まとめ
Day1に出てくる「問題の論理」「論理操作」「論理構造」といったキーターム（らしきもの）の内実はさっぱりわかりません。特にどれも「論理」という語を含んでいる辺りが問題で、いったいこの3つに何か共通する要素としての「論理」なる何事かがあるのでしょうか？

そのような「論理」なるものの説明が与えられないままに、「問題の論理」「論理操作」「論理構造」といった表現を並べられても、関数プログラミングを関数プログラミングよりも不明瞭な何事かで説明しようという無益な試みになるしかない、というのがDay1についての率直な感想です。

「論理」についてもDay2で説明します。

これも、例のAmazonレビューでは

本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって（技術的意義はもとより）そもそも意味をなさないナンセンスですし、

と異口同音にこっぴどく否定されているわけですが、Day2でちゃんと説明しています。

別のところでも批判的に論じている、今後数日以内にUPする予定の記事でも書くのですが、読者が一番知りたいのは、
WHATではありません。
言葉の定義がはっきりしないと抵抗があって読み進められない、と感じる読者はむしろ少数派であり、
大多数の入門者が求めるのは、
WHY Functional Programmingです。

Day１で、WHATは書かないという判断の結果は、読者が無料公開記事を読んでわかるか、わからないか、で是非が問われることです。

[0,1,2,…,9]はダサいか？

何度も繰り返されるコード例[0,1,2,3,4,5,6,7,8,9].reduce(plus)のダサさは本書にとって本質的なものではありません。

「ダサさは本書にとって本質的なものではない」
のではなくて、
Day1では、Day2で導入するrange関数へ据え置きながら、
段階をわけて書いたにすぎません。

「ダサさは本書にとって本質的なものではない」
という物言いには悪意が見えます。

ただ、容易に予想できる反応でもあるので、最初に「配列として与えられたデータ[13, 5, -6, 34, 9, -17, 8, 21, 7]の和を求めるコードを書け」というような例にしておけばよかったのに、とは思います。

当然の疑問が生じ、当然の疑問について取り組む。
「容易に予想できる反応」があるということは、
それだけすべての読者が、内容に追随できている、ということに他なりません。

いつも言うのですが、誰に何のために説明しているのですか？

読者の容易に予想出来る反応によって、著者が「バカにされないため」に、わざわざ先回りして、別の例題にして、誰の得になるんでしょうか？

フロー（チャート）に対する批判

これは命令型に慣れた人からは不適切な藁人形論法に見えるでしょう。

だから、誰に何のために説明しているのですか？
「命令型に慣れた人からは不適切な藁人形論法」と、論戦をはっているわけではありません。

そのフローチャートを見てそれが0〜9までの数を足せ、という問題の正しい解になっていることを確信できる人間は殆どいない、という主張がなされています(p. 9)。そのことに異論はありません。

異論がない、解説としての機能が満たされている、ということです。
宣言型の対比こそが「第一義」であって、「命令型に慣れた人からは不適切な藁人形論法」とかどうでもいいわけです。

（あと、そもそもの問題としてJavaScriptで「フローは不要」なんて不可能事そのものなんではという疑問はさておき。5）
もっとも単純な例を挙げれば、JavaScriptでコードを並べる順番や位置を迂闊に変えるとマズいことが色々と起きますよね（たとえば前方参照だのシャドウイングだの）。そしてそれはJavaScriptが実行される際の制御フローそのものから生じている問題です。 ↩

これについては、Day3で、
もしJavaScriptが遅延評価言語であったならば（意訳）という節でしっかりと説明しています。
この疑問が出るってことは、そこまできちんと読んでいない証拠です。

「問題の論理」？

p. 12で初出のこの「問題の論理」というタームはその後に繰り返し出てきます。が、その意味するところは良くわかりません。既出の関数型コードは「単純に問題の論理そのものをコードへまる写しているだけ」＆「そしてそれがクールなコードを書く唯一の方法だ」ということなのですが、それは「0〜9までの数をすべて足せ」という要求をそのままコードで表現すればいいのだ（そこにはループや途中の計算結果の受け渡しなんか出てこない）＆そうしたコードのみがクールなんだ、ということのようです。

繰り返しますが、このDay１フックが語るところは、出版前の「わかりやすい」というフィードバックより、おそらくほとんどの読者には伝わっていると観察します。

フックの部分で、WHYの部分で、言葉の定義の意味がわからない、WHATに延々という論者の批判については、こちらこそ疑義があり、ここは改善余地がある、とは同意しません。

しかし、たとえば「与えられた配列sをソートせよ」という問題を与えられたらどうするんでしょうか。

それは別の、次の話です。
概要、フックで、WHYで、
すべての詳細要素を網羅するのは原理的に不可能です。

逆に、すべての詳細要素を網羅するのは、
概要でもフックでもWHYでもありません。

とすると、「神の目」はどうやら役立たずだということになるでしょう。

ずいぶんこの記事を読み進めてきましたが、もうだいたい感じがつかめてきました。
概要部分で、詳細が網羅されない、WHYの部分でWHATがないとないものねだりをする、原理的に両立しない要素をもって、辛辣なものいいで全否定をしたいだけですね。

「大学生への教育目的で教材として検討している人間」の関心ある評価の仕方ではありません。

このレビュー記事の前提、

私は社会科学分野を専門にしていますが、教育的理由を含む様々な理由から学部1年生から2年生向けの基礎教育で関数プログラミングの基礎を教えることを考えています（計算機科学の専門家ではありませんからできることは限られていますが）。私自身の能力的限界から使用する言語はHasekllかOCamlになると思いますが、そもそもの関数プログラミングについて1年生に教える際に適切な教材に関心を持っています。つい最近（2015年4月）刊行された岡部健『関数型プログラミングに目覚めた！ IQ145の女子高生の先輩から受けた特訓5日間』も、そうした関心を以って購読しました。

というのも、おそらく虚偽です。

なぜこれを書いているか

しかし、否定的評価にせよその理由を記録しておくことは、一定の社会的効用を有しうるのではないかと思ってこれを書いています。

というのも嘘でしょう。

直近の記事で、自分のレビューがまた参照されたものだから、「嘘」でない形でまた仕返ししたかったというところでしょう。

「関数という論理操作」？

「炊飯器(米と水) = 炊きたてのご飯」という関係が「論理操作の関係」なんだそうです。「関数というものは作用して変化させる、という論理操作」なんだとか (p. 19)。正直なところ私はもう既について行きかねているのですが7、しかし、重大な問題がここには潜んでいるように思います。
まず、炊飯器が米と水をご飯に変化させるのは「因果的作用」です。更に、米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます。他に例として挙げられているのが家の改造（Before After）であるところからして、著者のいう「作用して変化させる」が因果的な作用による物理的変化のそれであるということは一貫しており、そこでは、outputが得られた時にはinputは消滅しています。
しかしながら、ということは、これが関数プログラミングでいう「関数」に対応するものではないことは明らかです。x = 1; y = foo(x);はxにfooを作用させてoutputであるyを得ていますが、xはfooによってもちろん消滅したり変化したりはしません（もし変化してしまうならばそのfooは副作用を持っており、関数プログラミングが基本的構成要素とするところの意味での「関数」にはなりません）。
このことは、著者の「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています。関数プログラミングでいう「関数」は数学的意味での関数、つまり、「写像 f:A→B」であって、あくまでも始域 A の元と終域 B の元との 対応関係 のことであり、そこには（始域の元が終域の元に「なる」というような）「変化」などというものはありません。

..

関数プログラミングでいう「関数」は数学的意味での関数、つまり、「写像 f:A→B」

そのとおりです。
本書は、数学的意味での関数について説明してます。
http://en.wikipedia.org/wiki/Function_(mathematics)

という、図にしても、Function_(mathematics)という極めて一般的な英語版（日本語版）Wikipediaの数学的な関数の概念図をそのまま踏襲しています。

上記概念図、あるいは、INPUT、OUTPUT、関数の入力出力という言葉自体が
時間の概念を感じさせるもので、実際に私はBeforeAfterと書いています。

これは、数学の論理として、正確なものいいではないのは百も承知です。

著者の「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています

事実と異なります。
英語版（日本語版）Wikipedia
http://en.wikipedia.org/wiki/Function_(mathematics)
の数学的な関数の概念図による説明が、イメージが、食い違っている、
と批判するのは「可能」でしょう。
この図も「変化」を感じさせます。

しかし、こんな「揚げ足取り」をしていたらキリがないんですね。
我々は物理世界の住人であり、我々の理解はそもそも抽象的な世界を土台としません。
抽象的概念を理解するには、まず時間が流れる物理世界のアナロジーとしてはじめるしか方法はないんですよ。

概説するところに、そういう理解の一連の作業がすでに終わっているもの（たとば貴方や同類）
が、いやその説明の仕方は正確ではない、と指摘するのは極めて愚かです。

概念導入説明について、概念導入後の読者の脳内時間を超越した揚げ足取りの文句を並べているだけです。

xにfooを作用させてoutputであるyを得ていますが

「作用させて」
「得ている」
これは【動詞】です。対応関係は対応関係であって、
作用、得るという【動詞】、つまり人間という主体が介入する余地はありません。
作用も、得るも何もないのです。ただの関係なのだから。
数学の世界には時間の流れなど存在しないので、本来【動詞】が介入する余地など一ミリもないのですが、こういう言葉遣いをするしか方法はないですよね？
「作用させて」
「得ている」
こういう言葉遣いをするあなたも厳密にいえば、
あなたの「関数」のイメージが、関数プログラミングでの「関数」と食い違っていることを示しています。

いや！その「作用」も「得る」も時間の流れ、時間の前後の話ではなくて、
論理的な話なんだ！

そうですね。ならば、

本書も引用しているこのWikipediaの関数（数学）の概念図にしたって同じことです。

INPUTもOUTPUTも時間の前後の話ではないので、
別にINPUTが消えてなくなることはない。

「炊飯器(米と水) = 炊きたてのご飯」

にしても同じこと。

それは論理的な関係としてある。時間を超越して、きちんと双方存在する。

「因果的な作用」ってなんですか？

「因果」をいったいどういう意味で使っていますか？

「因果的な作用」と「物理的作用」の双方の言葉の関係はどうなっていますか？

「因果的な作用による物理的変化」、って一体どういうことですか？
「因果的な作用【によらない】物理的変化」、なんてものはこの世に存在するんですか？
そんなものは存在しない。

「物理的変化」とはひとつの例外もなく、すべて、
「因果的な作用」によるものです。

なんで、こういう不注意な言葉遣いをするのですか？
それはあなたが、その辺りをきちんと考えたこともないからです。

「炊飯器(米と水) = 炊きたてのご飯」

これは因果として正しい。これは時間の流れを超越した、因果として正しい表現です。

米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます

間違いです。

「因果的に作用させると」っていう言葉遣いについて、この人自身、その意味を理解しているとはとても思えませんが、とにかく、とりあえず間違いです。

因果とは？

もとは仏教用語です。知っている人も多いと思いますが。

仏教とはもちろん宗教であり、宗教とは哲学です。とくに仏教は哲学です。
だから、私はさんざん哲学のことを説明しているわけですが、
この人のようにこうやって無自覚に「因果」という言葉を不用意に使う人がほとんどで、
その結果、この人のように自分でおかしなことを言っていることに気がつけない。
哲学は重要なのです。

そして、念の為ですが、フックのDay1ではそんな深淵なことを語るのは本末転倒なので、書いていません。書いているのはDay2以降です。

因果という仏教用語は、より詳しく調べると、
因果性
http://ja.wikipedia.org/wiki/%E5%9B%A0%E6%9E%9C%E6%80%A7
というWikipediaの項目があります。
英語で言うと、causalityです。
http://en.wikipedia.org/wiki/Causality

この項目をみると、「アリストテレス」やら「デカルト」やら、
まさに本書で詳しく、すくなくとも詳しく勉強してもらう導入として書いた哲学者の名前がでてきます。

現代でもっとも、定義が進んでいるのは、もちろん物理学であり、

因果律
となります。

因果律の定義は時間の定義とも密接に関係している。また、「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

これがまさに、本書の核心部分としてあります。

「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

「時間」「因果」「人間の主観」、まさに私は著書でそういうことを書いたわけですが、
「関数型プログラミングと関係ない」と理解を拒む先入観が強く固定観念に縛られている人があとをたちません。

めがねをかけるんだ
レビューポエム “関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間” を読んで

などでは、

親密さが増すにつれ、サクラさんの言動が少しずつおかしくなってきます。
アラン・ケイやスティーブ・ジョブズを引き合いに出すくらいはまだ良かったのですが、プラトンのイデアとか汎神論、精神世界と物質世界、大日如来の真言（マントラ）、果てはスピノザの神とか言い始めたときには、ほんとマジ超ヤバいと思いました。
ここまで来ると完璧に宗教の勧誘です。

と、浅い理解しかできない人が多いです。

私は、哲学の重要性の説明からはじめ、そのような浅い理解はしてはいけない、と本書で注意しながら、解説をすすめたのですが、そもそも私の話なんてまともに聞くつもりのない人は、そんな「注意」なんて気にもしません。案の定の結果です。愚かなだなあって思いますが。

よろしいですか？まさに、今あなたが「因果」なる言葉を不用意に使ったのが証拠です。
それは重要な概念なのです。関数型プログラミングの関数という超基本的な要素を理解するにあたっても。
そうやって、それなりに知的なツッコミを入れようとすればするほど、そのへんが露呈してくる。
そして、自身のいい加減な言葉遣い、処理しないと本来先には進めない重要な根底な概念を何も理解していないことに気づく。

物理学における因果律においては、

米と水に炊飯器を因果的に作用させると、米と水はご飯に変化し、もとの米と水はなくなってしまいます

というのはもちろん間違いです。

時間軸において、別の時間に
米と水
炊きたてのご飯
は両方存在します。なくなりません。

別の時間に存在する！そんなわけのわからない話をしているのではない？？
じゃあ「因果的」なんて言葉を使わなければ宜しい。
でも使わないと話できないでしょ？そういうことです。
わけのわからない話こそが本質であり、そこは本来避けて通れない議論なのです。

「時間」や「因果」はそれを認識する人間の主観によっても左右される。いずれにせよ、我々の感覚における「時間」に相当する性質を一部でも持つものを時間として定義し、そうして定義された時間の下で因果と因果律の概念は定義される。

「時間」と「精神」の関係、
それにあなたが実際に、
「写像 f:A→B」数学的な関数と、
「物理的変化のそれ」
が異なると言っているように、

「精神」
「論理」
「物質」
と考えないと、「因果」なんてもんは語れるはずもないのですよ。

因果は仏教用語であり、大日如来の真言（マントラ）の話が出てきて当たり前でしょう？
そしてその仏教用語の因果と、西洋哲学のスピノザの神は、等価の話なんで、
話して当たり前でしょう？

親密さが増すにつれ、サクラさんの言動が少しずつおかしくなってきます。
アラン・ケイやスティーブ・ジョブズを引き合いに出すくらいはまだ良かったのですが、プラトンのイデアとか汎神論、精神世界と物質世界、大日如来の真言（マントラ）、果てはスピノザの神とか言い始めたときには、ほんとマジ超ヤバいと思いました。
ここまで来ると完璧に宗教の勧誘です。

私は逆に、結構懇切丁寧に、そのへん解説したつもりなんですが、それを
「超やばい」
「宗教の勧誘」

Amazonレビューでは、

本書の過半を占める、その意味が定義されたり説明されることの決してない著者の独自の「論理」や「計算」という語の用法とそれに基づいた大量の思弁は、おそらく殆どの読者にとって（技術的意義はもとより）そもそも意味をなさないナンセンスですし、たとえばp.238以降展開されるような哲学者や自由意志論への言及は単純に思想史上の問題としても誤解に基づいたものに過ぎません（そのついでにアラン・ケイやガリレオやデカルトを気取られたりするとどういう顔をして読めばいいのかもわかりませんが）。

あるいは、

著者本人ですら、自らの書こうとしている内容を理解していないのでしょう。
蒙昧主義的で曖昧な言葉で不理解を誤魔化そうとするため、結果としてとても他人が読める文章にはなっていません。
このため、間違いを指摘しようにもこの駄文を理解するのが面倒で、まともな人なら黙殺するということになります。
何も知らない初心者や、自分に理解できないものを有り難がる愚かな人が、煙に巻かれて本書の内容を信じないことを祈ります。
こんなオカルトが出版まで至ってしまったとは、編集者や出版社の罪は深いなと思います。

オカルトだの、書いていますが、
とりあえず、そういう人たちは今後も「因果」なる言葉を、説明的に使用する資格などないのだし、
自分で自分が使っている言葉のことを何も理解していないという自覚と謙虚さがほしいところです。

ソクラテスの「無知の知」で注意申し上げたのですがね。
先入観が強いって、知的に罪であると痛感する次第です。

「『まとまり』は美しい単一の論理構造」？

関数型プログラミングの要素「集合」の概念導入をしたにすぎません。

またこの人物は、概念導入説明について、概念導入後の読者の脳内時間を超越した揚げ足取りの文句を並べているだけです。

知らない人に、ある考えを提示することと、
すでに知っている人に、詳細知識を共有することは、
まるで方法論が異なるのですよ。

WHAT　WHATで羅列するのが読みたいのであれば、関数型プログラミング用語集でも自分で書けば良い。

こんな、また同じようQiitaでステアカウントをこさえて、手の混んだ嘘設定までして、本書を毀損することに労力を費やすよりかは、よほど世のため人のためとなるでしょう。
今後同じことを繰り返してもすぐバレると理解してください。
しょうもないことを繰り返すのはいい加減にしたらどうか？

案の定、この章も、

みたいな関数プログラミングのイディオムみたいなものも曰く「ダサい」コードとなってしまうのであって、およそ関数プログラミングをどうやって遂行したものか途方に暮れるしかありません。

と辛辣な煽り文句で終わっています。要するににこれがしたいだけだろうと。

続くかどうか

どうぞご自由に。しかし、Day2、Day３の批判ネタは、どうせ、
Amazonレビューで嘘を書かないこと、それが技術的議論のための最低限の要件であるで「嘘」だと言われたAmazonレビューの内容の焼き直しでしょう。

何度も何度もQiitaの捨てアカウントこさえて、こんなくだらない事を繰り返している労力があるのならば、本当に自分で気に入る「OCaml」本を書けば良いと思いますし、少なくともWHAT　WHATの気に入る記事書けば良いと思う。

関数型プログラミング用語集で、命令型、オブジェクト指向とのパラダイムの違いが体感できる読者入るとは思えないし、感動する人も居ないと思います。初心者の方々には間違いなく役立たないし、本書が提供している価値も創出できないとは思いますが。