掛算の順序と学習指導要領

あいかわらず掛算の順序の話がもりあがってるようなのだけど、コーディングルールの話なんだから計算の定義の話をしても徒労だよなと思いながら見ていた。
で、ちょっと教育指導要領解説を見てみたのでまとめる。

学習指導要領解説の記述

「【算数編】小学校学習指導要領（平成29年告示）解説」では次のようになっています。順序は表現のときの問題で、計算では交換則を使っていいとなっています。

被乗数と乗数の順序は、「一つ分の大きさの幾つ分かに当たる大きさを求める」という日常生活などの問題の場面を式で表現する場合に大切にすべきことである。一方、乗法の計算の結果を求める場合には、交換法則を必要に応じて活用し、被乗数と乗数を逆にして計算してもよい。

このPDFの115ページ。
https://www.mext.go.jp/content/20211102-mxt_kyoiku02-100002607_04.pdf

ここからたどれます。
小学校学習指導要領解説：文部科学省

表現としての掛算式

数式というのは、左から計算するとか×を先に計算するとかの構文規則をもった言語です。「+より×を先に計算する」というのは乗算の性質ではなく乗算をあらわした式という言語の性質です。そして、言語であるからには人が読み書きするものなので、意図したとおりに伝わるかというのが大事になります。

指導要領解説には次のような文章があります。

「乗法の式から場面や問題をつくるような活動も，乗法についての理解を深め，式を用いる能力を伸ばすために大切」であり、式から場面をつくる際には「被乗数と乗数の順序が，この場面の表現 において本質的な役割を果たしている」ということです。
場面の表現としての式では順序が大切ということですね。

ルールでの順序はどちらでもいい

指導要領解説には「（一つ分の大きさ）×（幾つ分）＝（幾つ 分かに当たる大きさ）」のように「一つ分の大きさ」が先に書いてありますが、文部科学省に問い合わせた人によると、これは例であって逆でもいいとのことです。
「表す順序を日本と逆にする言語圏があることに留意する」と書かれていることからも、「一つ分の大きさ」が先というルールに固執してるわけではないことがわかります。

ところで「リレーで4 x 100mと書くじゃないか」というのが頻出反論としてありますが、国際大会に合わせているように思います。つまりこれは順序が固定の例と言えます。

同じ処理に複数の表記があるなら統一したほうがいい

プログラミングのコーディングルールは、同じ実装に複数の表現があるからこそ必要になるわけですね。スペースをいくつ入れてもいいから「字下げのスペースは4つ」のようなルールがあるわけです。
「add.list("foo")ではなくlist.add("foo")と書く」なんてコーディングルールはないですね。これはコーディングルールではなく文法です。

掛算も交換則でどちらを先に書いてもいいからこそ、コーディングルールがあったほうが解釈しやすくなるわけですね。分数で分母を上に書くか下に書くかという議論は出てこないわけです。
そして、字下げルールがスペース4つでもスペース8つでもいいように、ルールとしては一つ分の大きさでも幾つ分でもどちらが先でも構いません。

ただ、ある部分では4タブ、ある部分では8タブと混在するのがよくないように、掛け算で場面を表現するときもひとつの文章、ひとつのチームなどまとまった単位では順序を統一したほうが解釈しやすくなります。

気にしないけど統一されている

掛算の順序なんて日頃は気にしないのになんで学校でだけ気にするんだ、という話もあったけど、これは気にしなくても統一されてるからということもできます。
文化というのは、十分に浸透していれば気にする必要がなくなりますね。

「ポイント5倍キャンペーン」で画像検索すると、掛け算記号があるものはほぼすべて「x5」となっています。ひとつだけ「5x」がありました。増やしたいものが前、増やす倍数が後ろという習慣があらわれていると思います。

関係ないけど、広告がはさまってるように見えるな。広告じゃないです。

で、一方で、GPUなどの計算が2倍3倍に速くなったときのオフィシャルでの表記は2xとか3xとかになっていて、英語圏では逆ということがわかります。

この違いは「りんご4つ」「4 apples」という母語の語順に由来してるんじゃないかな。

出題や採点、教育姿勢の問題との混同

たとえば「りんごが5つ載った皿が4枚ある場合にりんごがいくつになるか計算せよ」という問題があるときに「4x5=20」と書いて「順序が違うからバツ～」ってされると「設問は『計算せよ』となってるじゃないか」となるわけですね。 式を書かせるための設問を小学二年生に理解できるように作るのは結構難しいんじゃないかと思いますが、採点基準は設問に含めるべきではないかと思います。
あと、「テストは教えたことの確認なんだから教えたとおりに書くべき」みたいなのは、それはそれで何を教え何を答えさせるべきかということから逃げていて教育姿勢としてよくないですね。

2024/4/9追記 数学者や物理学者の話

数学者や物理学者が実務で使ってないという話が出ますが、数学者や物理学者も、式を書くときになんなりかのルールで順序を決めたり、同じ分野では標準的な記述順序があったりするんじゃないでしょうか。 たとえばxについての多項式ではれば、xは項の最後に書くような文化がありますね。足し算についても次数が高いものを先に書きます。
人に見せる式としてxについての多項式 ax ^ 2 + bx + c を x ^ 2 a+xb+c とは書かないんじゃないでしょうか。
x ^ 2 y + x y ^ 2 = 0 という方程式も、xを求める方程式であれば y x ^ 2 + y ^ 2 x = 0 と書くし、yを求める方程式であれば x y ^ 2 + x ^ 2 y = 0 と書くんじゃないかと。そして、この場合に、掛算の順序はその式が何についての方程式なのかを表すのに重要、のような話になるんじゃないでしょうか。
可換な演算の記述順、結構気にしてるように思います。
ところで、tex記法がきかないのでy ^ 2 xがy ^ (2x)なのか(y ^ 2)xなのか見辛くなってますが、xについての方程式のルールに従えば読みときやすくなりますね。tex記法どうやるんだ。 [tex : y x²+y² x=0] でいいはずだけど。

2024/4/10追記 学習指導要領解説であることについて

コメントを見ると、学習指導要領解説だから読む気なくす、法的拘束力はない、のようなものがあります。けど、文部科学省が学習指導要領の関連文書として告示しているものはそんなに軽い位置づけではないと思います。また、実作業者がだれであろうが、文部科学省として作成・公表しています。

改訂の際の通知に次のような記述があります。
https://www.mext.go.jp/content/1384661_1_1.pdf

法的拘束力のある決定には時間やコストがかかるので、行政を円滑的に運営するため、法的拘束力はないけど強い強制力のある文書を出すことがあります。わかりやすいところだと行政指導がありますね。
「【通達の意味・種類・法的性質（国民・企業・裁判所への法的拘束力）】 | 企業法務 | 東京・埼玉の理系弁護士」 https://www.mc-law.jp/kigyohomu/21524/

学習指導要領には「何を学ばせるか」が既定されていますが、それだけでは実際に教育の実務を行うことができません。なので「どのように学ばせるか」を学習指導要領解説として出しているのだと思います。どのように学ばせるかは臨機応変に対応できるほうがいいので軽い文書として学習指導要領解説を出していると考えれます。このように、指針を法的拘束力のある文書で規定して、運用を法的拘束力のないガイドラインなどで告示するということはよく見かけます。
上記の通知を見ると「学習指導要領解説を活用して、教職員が学習指導要領についての理解を深められるよう周知・徹底を図ること」のような記述があって、結構強い位置づけであることがわかります。

そもそも、掛算の順序がどのようなものかという議論をするべきで、法的拘束力があるとかないとかはあまり本質的ではないと思います。そして、掛算の順序を文部科学省としてどのようなものと考えているかが、学習指導要領解説に表されているので、この議論では重要な文書だと考えます。

まとめ

表現の問題なのだから、計算の性質の話ばっかりしても収束しないわけですね。
そして、表現のために規則が必要かという話には正しい答えなどはないので、正しい正しくないの話をしてもしょうがないです。適切かどうかではないかと。
たぶん、掛算順序が盛り上がったあとに改訂されていて、学習指導要領解説はよくまとまってると思うので、議論する際は目を通す方がいいと思います。

※追記2024-4-11 なぜ混乱するのかという話も書きました

これからの算数科教育はどうあるべきか

JavaのDIコンテナは言語機能の補完でありinjectはimport

というブログを書こうとしたら、すでにあった。
Dependency Injectionでやりたいことはモジュールimport - きしだのHatena

依存性の注入って要するにimportなので。

まず、DIコンテナを実装してみるとどういうものかがわかりやすくなります。
このときの結論はこんな感じ。

DIコンテナというのは、Javaのリフレクションやバイトコード操作、ThreadLocalといった、あまり美しくない部分を覆い隠してきれいなコードでアプリケーションを構築するための仕組み
作って理解するDIコンテナ - きしだのHatena

言語機能の補完なので、他の言語で同様に便利とは限らないわけですね。
わかりやすい例として、DIコンテナの現実的に便利なのはAOPを利用した宣言的トランザクションやログです。これはAspectJのように言語機能としてAOPが用意されていれば不要になります。

あと、これらのブログで書いてないこととしては、DIでのクラス設計というのはオブジェクト指向は関係ないってことですね。
クラス分けを恣意的に行えるので、単に作業性の問題です。

たとえば次のようなコントローラクラスがあるとします。

@Path("/home")
@RestController
public class HomeController {
  @Path("/hello")
  public String hello() {
    return "hello";
  }
  @Path("/info")
  public String info() {
    return "test app";
  }
}

このようなクラスでメソッドが多くなったときなどに、次のように2つのクラスに分割することは簡単です。

@Path("/")
@RestController
public class HelloController {
  @Path("/home/hello")
  public String hello() {
    return "hello";
  }
}

@Path("/")
@RestController
public class InfoController {
  @Path("/home/info")
  public String info() {
    return "test app";
  }
}

逆に、コードの整理でメソッドが少なくなったり、必要と思ったらそれほどメソッドは必要なかったりで、メソッドが少なすぎる複数のクラスを統合することもあります。

単にどのメソッドをひとつのファイルにまとめておくと便利かという観点でクラスを定義することになりますね。グループ分けの問題であり線引きの問題です。

これがたとえば、ListのメソッドをMapにもっていくとか、ArrayListとLinkedListを統合しようとかいったことは簡単ではありません。そもそもとして「やろうとしたらできるかもしれないけどやるべきじゃないんでは？」となりますね。

ということで、DIでのインスタンスメソッドはAOPなどいろいろ仕込みたいときにstaticだと難しいので仕組み的にインスタンスメソッドを利用しているだけだし、そうするとimportが行えないので@Injectしている、というふうに考えるほうが利用しやすくなると思います。

時代がstaticおじさんに追いついてきた(追記あり)

この文章みてください。

オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……

「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年の架空の開発現場での登場人物の話です。
高慢と偏見（1）隣は何をする人ぞ：Press Enter■：エンジニアライフ

この発言に主人公たちは眉をひそめるのですが、今みると全く当たり前のことを言っているように思います。カプセル化は理解してほしい気はしますが。

そしてstaticを勧める。

「staticを使えばインスタンス宣言などしなくてもいいんだよ。どっちが楽か分かるだろ？ いちいちインスタンス宣言するなんておかしいよ」

「staticおじさん」という言葉があります。この物語に出てくる三浦マネージャーのような人をさして、staticだけではなく技術についていけていないことを揶揄するように使われます。

けど、ここでのコードは研修のサンプルコードの話で、例えばフィボナッチを次のように書いてた感じに思います。

public class Fib {
  public static void main(String[] args) {
    Fib f = new Fib();
    System.out.println(f.calc(5));
  }

  int calc(int n) {
    if (n <= 1) return n;
    return calc(n - 1) + calc(n - 2);
  }
}

calcをstaticにしてしまえば「インスタンス宣言」などしなくていいです。Fibのオブジェクトの必要性はないですね。

public class Fib {
  public static void main(String[] args) {
    System.out.println(calc(5));
  }

  static int calc(int n) {
    if (n <= 1) return n;
    return calc(n - 1) + calc(n - 2);
  }
}

Javaのstaticはクラスをネームスペースとして使う機能で、クラスを拡張版packageとして使う機能といえます。importも使えますね。

この時期、なぜかstaticではなく「インスタンス宣言」したほうがいいという風潮でした。「プロJava」の書評にも「著者が static 好きすぎ」と書かれてたりするので意味なくstaticを忌避する風潮は残ってるようですが。

この後も

「私の経験から言うとコードレビューはデバッグに非常に有効にもかかわらず、このプロジェクトでは月に1回も実施されていないようなので、ここらでビシッと引き締めたいね」

とコードレビューを勧めると

「ここのメンバーはコードレビューが必要なレベルではありません。全員が自分が書くコードの意味を理解しているし、それを実装する能力も十分です。また、それぞれ所属する会社としての文化も違うわけですし……」

と、主人公陣営から反論が来たりしています。
高慢と偏見（2）使徒襲来：Press Enter■：エンジニアライフ

2010年はGitHubもまだ会社ができたばかりで、プルリクエストによるコードレビューは知られておらず、紙ベースでみんなで集まってレビューしていますが、コードレビューについては今では常識になったことを言っています。
そのあとも、変なコード分割をするなとか、割とまっとうなことを言ってるはずですが、主人公たちからは受け入れられません。

GCやバージョン管理システムを知らなかったり、方向性はいいけどツールに疎いという感じではありますが。あと態度が悪い。
けど、主人公たちも「今までやってたから」「良いと言われてるから」くらいしか理由を説明できないにも関わらず、三浦マネージャ不在のときに一気にコードを進めて既成事実化したり、あまりよくない。 主人公たちが「staticだからダメ」「オブジェクト指向じゃないからダメ」という「オブジェクト指向おじさん」になってるようにも見えますね。主人公は女性のようだけど。

「staticおじさん」三浦マネージャの、staticに関する話の元ネタはこれなのかもしれない。

「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう

実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ

この内容も用語の使い方が甘い部分はあるものの、そこまで間違ってないように見える。

ようやく、オブジェクト指向だからよい、オブジェクト指向じゃないからよくない、というような空気が薄れて、時代がstaticおじさんに追いついてきた感じがある。

追記

三浦マネージャも主人公側も変なことを言ってる部分があってどっちもどっちなのに、三浦マネージャのいい部分、主人公側の悪い部分だけとりあげて、オブジェクト推進派への嫌悪感が表れているという指摘があったのだけど、まあ「static好きすぎ」という書評への嫌悪感が表れてしまってますね・・・

「プロになるJava」で例えばこんな感じで、サンプルで出てくるメソッドなどは、インスタンスが必要なければstaticメソッドとして定義しています。

public class Sample {
  public static void main(String[] args) {
    foo();
  }
  static void foo() {
    System.out.println("Hello");
  }
}

これ別に、Java 21に入った試用機能でmainを簡潔に書くとこう書けるんですね。staticかどうかはJavaコマンドの都合であって本質的ではない。

public class Sample {
  void main() {
    foo();
  }
  void foo() {
    System.out.println("Hello");
  }
}

既存の機能の範囲でも、無用にインスタンスを作って無理矢理インスタンスメソッドにしているサンプルをよくみかけます。

public class Sample {
  public static void main(String[] args) {
    Sample s = new Sample();
    s.foo();
  }
  void foo() {
    System.out.println("Hello");
  }
}

シングルトンにすると、フィールドもグローバル変数化するのでstaticと問題は変わらなくなるし、DIコンテナ使った場合もコンテナはグローバル変数置き場なので同様です。
そうやって、単に「staticロンダリング」のようなことをして実質はstaticのようなコードを書きつつ「staticじゃないからヨシ」みたいなことしてるんではと思ってたところにstaticおじさんの話題が出てきたので勢いで書いてしまったらこうなった。

オブジェクト指向入門 第2版: 原則・コンセプト

ジョギングを始めた。700mほど。

そういえば、去年から雑なジョギングを始めている。
バスが間に合わなそうで走ったときに、ちょっと走れなすぎてヤバいなと思ったので、走るという行為をたまにやっとこうと思ったのがきっかけ。 その程度のモチベーションなので、何キロも走ったりとかせず、家のまわりのブロックを一周するくらいにした。

そうすると、距離にして700m弱で、準備をして部屋からでて走って戻っても10分かからない。
テキパキやれば5分ちょいくらい。
数キロ走ろうとして30分とかかかってしまうと走るタイミングを考えてしまうけど、5分で終わるとなると思いついたときに走ってくればいいのでやりやすい。ぼくでもできる。
やはり、継続したいことは5分で終わるようにするべき。

ということで週に1-2回くらい思い出したように走ってる。
やらないよりはマシという程度に健康になった気がする。やらないよりはマシなのでいいのだ。

[Ademe] コンプレッションウェア セット メンズ

報道ヘリがうるさくて救助の邪魔になるという話はどう広まったのか

報道ヘリがうるさくて救助の邪魔になるという話はどう広まったのか、というのを調べてみていたのでメモ

そもそもとして「報道ヘリがうるさくて救助の邪魔になる」ということなんてあるのか、という話は、1995年1月17日の阪神淡路大震災にさかのぼる。
震災後6日後に収録されたと言われる1月27日放送の「パペポTV」で上岡龍太郎が次のような発言をしていた。

取材陣のヘリコプターがあの被災地の上を飛び回るでしょう。あの爆音のために、生き埋めになってる人に外からどんなに声かけても、その人たちの声が爆音のために聞こえない

救助の邪魔になるという話 以外にも、被災者から「自分が見せ物にされている」というような苦情もあったようだ。救助ヘリの邪魔になる高度を飛ぶようなこともあったらしい。

これは実際に問題だったようで、その後1997年に日本民間放送連盟から「航空取材ガイドライン」が出されて、報道ヘリがある程度の高度を保つようになっている。
よりよい放送のために | 一般社団法人 日本民間放送連盟

なので、現在ではマスコミのヘリはそこまで邪魔になるような高度を飛んでないはず。

にもかかわらず、いまネットでそういう話が流れるのは、2016年に上記の番組がYouTubeにあげられて、その書き起こしがネットに広がったというのが影響していそう。
もちろんそこには航空取材ガイドラインの話は出てこないので、「今でも邪魔な報道ヘリの飛ばし方をしている」というような印象をもって広まった。

それがいまだにTwitterで語り継がれてる、というそういう状況だと思われる。

※ 追記 2024/1/6 長崎県の轟峡遊歩道での件が「反例」として貼られてるけど、ガイドラインで報道ヘリの基準高度が600-700m以上くらいに決まってるものの(具体的な数字は見当たらず)、標高200mということで報道ヘリとの距離が平地より近くなったんじゃなかろうか。 あと、ドローンは電波がそれほど届かないので操縦者が直下まで出向かなければならず、災害時に飛ばすのには向いてないですね。

今年おもしろかったマンガ2023

今年読んで面白かったマンガをまとめておきます。

葬送のフリーレン

アニメがヒットしてるフリーレン、最近やってた黄金郷編がめちゃよかった。

葬送のフリーレン

転生してハイエルフになりましたが、スローライフは120年で飽きました

フリーレンはエルフを主軸にしたマンガではあるけど、基本的にはフェルンの物語なので、人間の時間軸で話が進みます。
一方で「転生してハイエルフ」はエルフの時間軸で話が進むので、宿屋の女の子が、次に会う時には大きくなっているということが当然のようにあります。
エルフのように生きるのがどんなことかということを書こうとしてる感じ。

転生してハイエルフになりましたが、スローライフは120年で飽きました -Highelf with a long life-

ヘルモード

貧しい農村に生まれて召喚スキルを使ってちょっとずつ認められていくという話。
召喚獣がかわいい。
最初のちょっとしたエピソードもぜんぶ伏線になっていて、そういうことだったのかとなっていくのがいいです。

ヘルモード ~やり込み好きのゲーマーは廃設定の異世界で無双する~ はじまりの召喚士

落ちこぼれ国を出る

貴族の家を追い出されるけど、付与術で無双していくという追放もの。
追放した貴族が没落していくざまぁものでもあるのだけど、その没落しかたが他にない感じでおもしろい。
ニーナがかわいい。

落ちこぼれ国を出る ~実は世界で4人目の付与術師だった件について~

宇宙軍士官、冒険者になる

宇宙船が事故にあって地球型の惑星に不時着して冒険者になるという話。
かなり面白いのだけど、原作に追いついているようで、続きが出るのか心配。

航宙軍士官、冒険者になる

片喰と黄金

イギリスの貧しい農家の女の子とその従者がアメリカにわたってゴールドラッシュに沸く西部を目指すという話。
なんかがんばったらどうにかなる感じがいい。

片喰と黄金

正反対な君と僕

ラブコメ。
だけどドタバタしてるだけじゃなくてみんないろいろ考えていてよい。
登場人物みんないい人。

正反対な君と僕

今年買ってよかったもの2023

今年買ってよかったものまとめ

フライパン

テフロンのはがれたフライパンを惰性で使い続けていたのだけど、餃子やいてもはがれないし、タマゴを炒めるとくっつきまくりで気になっていた。
で、インターネッツぽちぽちやってるときに、なんとなく買ったら、やっぱり新しいフライパンはよかった。
オリーブオイルとニンニクと塩だけのパスタがおいしすぎてよく作っている。

和平フレイズ マーブルコート フライパン 26cm ブラック IH・ガス対応 マーブル・イグネイト RB-1907

電子レンジ

もらいものの電子レンジをずっと使ってたのが壊れたので買いなおし。
あっためれればいいので、一番やすいのを買った。
そしたら、キッチンタイマー機能があって、便利につかっている。
アナログのキッチンタイマーはあるのだけど、1分や2分は計りにくくて、電子レンジのタイマーを使うとちゃんと計れるので、紅茶を煎れるときの時間をちゃんと調節できるようになっておいしく紅茶が飲めている。
ただ、扉をあけると電源が入る仕様なのだけど、1秒弱ほどのラグがあって、そのラグの間にボタン操作するとフリーズして電源抜き差ししないと復帰しないというバグがあって「SHARPの開発りょく～」とか思ったりしている。

シャープ 電子レンジ 18L ホワイト系SHARP RE-TM18-W

Positive Grid Spark GO

ちいさいギターアンプ。
アンプもってなくてマルチエフェクタからPC用のオーディオインタフェースにつないでヘッドフォンで聞くというのをやってたのだけど、音を出したい、けどあまり音量も出したくないというので買ってみた。
スマホと接続していろいろエフェクトを調節できる。小さい割に出力が5Wなのでそれなりに大きい音も出るけど、小さい音がきれいに出るのがいいところだと思う。
ざつに机の上に置けるサイズなので、適当にギターをつないで弾いたりしてる。便利。

Positive Grid ギターアンプ 小さくてスマートなポータブルアンプ ヘッドホン出力可能 Bluetooth 5.0対応 スピーカーにもなる Spark GO