2024/04/14

物理学の基本思想とは何なのか

最近、物理学の書籍を図書館からかなりの数を借りて読んでみた。
物理初心者の感想をラフなメモ書き。

【参考】
物理学を攻略するためのマップ: プログラマの思索

経済数学の直観的方法の感想: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

量子革命がコンピュータ革命を引き起こした: プログラマの思索

熱力学や電磁気学の設計思想: プログラマの思索

物理学の設計思想には、いくつかの基本的設計があると思う。

【1】1つ目は、物理学では、数式の意味を解釈することが大切であること。
その数式で、物理的現象や物理量を説明できるか?
ゼロから学ぶ相対性理論」に出てくる。

ローレンツ変換と読むがアインシュタイン方程式と呼ばないのはなぜか?
ローレンツもアインシュタインも同じ数式を導いているが、アインシュタインはエーテルなんて存在せず、速度が絶対速度ではなく2つの座標系の相対速度であることを見抜いた。
ローレンツもアインシュタインも同じ数式であるローレンツ変換を扱っているが、物理的解釈が徹底的に異なる。
そこにアインシュタインの独創性が現れている。

よくわかる電磁気学」の通り、マクスウェルの方程式でも、変位電流に気づいた経緯でも、数式の不整合だけでなく、物理的にも磁場が何らかの電流を放出しているはずだ、という考え方があった。
シュレディンガー方程式は電子が波の性質を持つという考え方があった。

いずれも単なる数式ではなく、数式が物理現象をどのように表現するのか、という観点が必要になってくる。

【2】2つ目は、細かく区切って考えるのが物理学の極意ということ。
よくわかる電磁気学」のあとがきに出てくる。
場の考え方、すなわち近接作用が物理学の基本思想だ。
つまり、近接作用を考えると、物理法則は微分形式で表現できる。
微分積分では、微小な線分、面積、体積をイメージすればいい。

微小なdr, dS, dvなどで物理現象を表現できれば、微分方程式が出てきて、微分方程式を解けば全体的な現象を表す関数や運動方程式が出てくる。
一方、「高校数学でわかるマクスウェル方程式」の通り、マクスウェル方程式は積分形式で表現した方が理解しやすい。
なぜならば、高校数学で出てくるアンペールの法則、電磁誘導の法則などは、マクスウェル方程式の積分形式と対応付けて説明しやすいから。
マクスウェル方程式の微分形式は、「高校数学でわかる相対性理論」の通り、非常に小さな空間で積分形式のマクスウェル方程式を適用すれば出てくる。

近接作用の考え方が場の量子論につながることが「よくわかる電磁気学」でも触れられている。

【3】3つ目は、解析力学を制覇すれば、物理学の諸分野を理解しやすくなるメリットがあること。

たとえば、量子力学、統計力学では解析力学の手法に慣れておくと理解しやすくなる。
よくわかる解析力学」では、最後のあとがきで、相対性理論、量子力学、統計力学に解析力学を適用したときの考え方が説明されている。
一般に、原子や分子レベルでは、古典力学では計算が煩雑になったり、より深く考えにくい。
そこで、解析力学のアプローチを使って、何らかの物理量を最小化したり不変にする前提から運動方程式や保存量を導く。

そこで、相対性理論、量子力学、統計力学に出てくる解析力学のツールが違うならば、それぞれの分野ごとに必要な解析力学のツールを説明した本があれば、解析力学に深入りせずに、本来やりたい分野の勉強に注力できるだろう。
たとえば、量子力学に必要な解析力学のツールだけ理解したいなら、「量子力学を学ぶための解析力学入門 増補第2版」が良いらしい。
ただし、実際に読んでみたら完全に専門書なので、ある程度解析力学の知識がある前提で読み進む必要があると感じた。

ここで、物理学では不変量が大切になる。
不変量は何らかの意味ある物理量を表す。
エネルギー保存則、運動量保存則もそうだ。
だから、物理学ではラグランジアンよりもハミルトニアンが重視されるのではないかと思う。

経済数学の直観的方法 マクロ経済学編」では、経済学の目的は「リソースを最適化する(経済政策や戦略により全体費用を最小化する)」ことにあるのでラグランジアンを多用する。
一方、物理学の目的は「物理量を一定に保つ運動や保存則を見つける」ことなのでハミルトニアンを多用する、と説明があったが、まさにその通りと思う。

解析力学では、物理量を最小にするのがラグランジアン、物理量を不変にするのがハミルトニアンと考える。
しかし、解析力学は難しいと感じる。
解析力学が難しい理由は2つあると思う。
1つは、ラグランジアンやハミルトニアンが導出する方程式や数式の物理的意味を理解しづらいこと。
L=T-U、H=T+Uにはこういう物理的意味があるとどの本でも詳しく説明してくれるが、どうしても天下り的な説明になりがちで、初心者は納得しづらい。

最小作用の原理はどこからくるか? - 物理Tipsにも書いているように、「最小になるようなもんを探したらこれになる」と結局理解するしかないと思う。

もう1つは、たとえば、説明をオイラー・ラグランジュ方程式のように、座標をq、1次微分をqドットのように表現しているので、数式そのものが扱いづらいこと。
オイラー・ラグランジュ方程式は3次元座標x,y,zの微分方程式だから、本来は3つの方程式を書き出さないといけない。
しかし、似たような形の微分方程式を3回書き下すのは面倒だから、頭の偉い人が、x,y,zはq1,q2,q3で書いてしまって、まとめてqにしてしまいましょう、と考えた、とみなせばいい。
そんな説明が「ゼロから学ぶ解析力学」に書かれていて納得した。

個人的には、「ゼロから学ぶ解析力学」が解析力学の取っ掛かりの理解に役立った。
理由は、解析力学のラグランジアンやハミルトニアンがきれいに書かれた公式になる以前に、泥臭い数式や計算を見せて説明してくれているから。

たとえば、「ゼロから学ぶ解析力学」では、最後のあとがきに、ゼロから学ぶという条件のもとにレギュレーション(執筆ルール)を筆者に課した。
一般座標q_iを書かずに普通の座標x,y,zで書ける所まで微分方程式や計算をすべて書いたり、「∂L/∂θドット」とは書かずに「∂L/∂v_θ」と書くなどしている。

実際、オイラー・ラグランジュ方程式も、一般座標qや∂L/∂qドットではなく、3次元座標x,y,zと∂L/∂v_x,∂L/∂v_y,∂L/∂v_zで3つの方程式をすべて書き出してくれている。
それら3つの方程式は略記号により、1つの方程式で最終的にはきれいに書かれるわけなので、こういう泥臭い理解が最初は必要なのだろうと思う。

【4】物理学で理解した内容はまとめておこうと思う。

| | コメント (0)

2024/03/31

「スクラムの拡張による組織づくり」のScrum@Scaleの感想

スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」をざっくり読んだ。
ラフな感想をメモ。

【参考】
大規模スクラムはLeSSとSAFeのどちらが良いのか: プログラマの思索

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

プロダクトマネジメントの感想~プロダクトオーナーはもっとチームの外のユーザに寄り添うべき: プログラマの思索

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

文化は組織構造に従う: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

【1】Scrum@Scaleというアジャイル開発の大規模開発プロセスがどんな内容であるのか、に興味があった。
詳細は「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」に書かれているのであえて記載する必要はないと思う。

むしろ、既存のLeSSやSAFeと比較して何が異なるのか、が重要だろうと思う。

LeSSは1人のプロダクトオーナー、1つのプロダクトバックログから成るので、1個の製品を複数チームで開発するスタイルみたいなイメージを持っている。
たぶん、この形のスクラムが一番スケールしやすいと思う。
一方、プロダクトオーナーに負荷がかかりやすい弱点があるから、エリアプロダクトオーナーを設けたり、プロダクトオーナーを支援する人やチームを別途作るケースが多いように思う。

SAFeはアジャイル開発の官僚的組織、官僚的プロセスに近いイメージを持っている。
3つのレベルを持ち、開発チーム、リーダー層、経営層でそれぞれ役割分担したアジャイル開発を進めるイメージ。
大規模なシステム開発では、組織やプロセスを整備する必要があるから、SAFeのような仕組みは必要になるだろうと思う。
一方、RUPのようにテーラリングが必要なので、戦略的にカスタマイズを実施しないと難しいだろうと思う。

Scrum@Scaleは、スクラムチームのスケールだけでなく、プロダクトオーナーもスケールも実現する。
つまり、最低限の官僚的組織は持つが、開発チームだけでなくプロダクトオーナーも複数あり、協調動作するスクラムチームごとにプロダクトバックログを持つから、複数のプロダクトバックログを扱うように動く。
この点が他の大規模スクラムと違って、より柔軟な仕組みを持っているように思った。
EATやSoSのような組織を見ると、複数の開発チームやプロダクトオーナーが協調動作するように役割分担しているのに気づく。
レポートラインも最低限の官僚的組織としてうまく整備されている印象を持った。

【2】チャットサービスの開発現場で組織構造が変遷される内容がとても興味深い。
ChatWorkの開発現場だと思うが、最初はUI/UXのチームが重視され、途中で統合認証のような共通基盤の開発チームが入ってきて、最後は統合認証基盤チームは退出し、データマイグレーションなどのTeamsだけが残る。
つまり、チャットツールのビジネス発展に応じて、開発する機能が変わるので、それに応じた開発組織が必要になる。
そうした開発チームはチャットツールという製品の開発フェーズに応じて、新規に入ったり、退出したりして入れ替わる。
そういう組織の入れ替えを意識的に行っているのが味噌と思う。

また、こういう組織の入れ替えは、逆コンウェイ戦略の良い事例になっている。
なぜならば、製品の開発フェーズに応じて、重視される機能やアーキテクチャが変わるので、それに応じた組織を当てはめるべきであり、そういう組織を入れ替えるべきだ、という考え方になるからだ。

では、一般のユーザ企業の基幹系システム開発でも、こういうやり方は通用するだろうか?
たとえば、基幹系システム開発でも、機能追加やリプレース、法規制対応などにより、システムのフェーズは変わる。
基幹系システム開発でアジャイル開発を実践できているならば、Scrum@Scaleのような大規模開発も取り入れることはできるだろう。
つまり、基幹系システムのフェーズごとに開発チームを入れ替えて、逆コンウェイ戦略を実現することは不可能ではない。

しかし、一般の基幹系システム開発では、WF型開発が主流であり、アーキテクチャもインフラ層、データベース層、アプリ層などのように分割されて、それに応じた開発チームから成り立つ組織が多いと思う。
だから、Scrum@Scaleのように開発チームを頻繁に入れ替えるような逆コンウェイ戦略を実現するのは難しい状況が多いのではないか。

また、基幹系システム開発でスクラムを実践できていても、複数のプロダクトバックログを協調動作するように運用するのは、マネジメント上やはり難易度が高いと思う。

【3】「スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する」は日本の現場の事例もあって良い本と思う。
LeSSやSAFeとの違いについてはもう少し考えてみたいと思う。

LeSSは「大規模スクラム Large-Scale Scrum」の本がお勧め。
SAFeは「SAFe 4.5のエッセンス」の本がお勧め。

「More Effective Agile ソフトウェアリーダーになるための28の道標」では、SAFeが推奨されていたので参考にしている。

| | コメント (0)

2024/03/12

astahにタイミング図がサポートされた

astahにタイミング図がサポートされたのでメモ。

【参考】
astah* 9.2リリースノート | astah

タイミング図 | astah* 機能ガイド

plantumlでタイミング図が描けるらしい: プログラマの思索

astahとPlantUMLを行き来できるastah* PlantUML Pluginが面白い: プログラマの思索

astah* Mermaid Pluginが公開された: プログラマの思索

Timing図

わかりやすくUMLタイミング図とは

【PlantUMLの使い方】PlantUMLでタイミングチャートを作成する - システムとモデリング

UMLのタイミング図を使う機会は正直ほとんどないし、経験もない。
感覚的には、シーケンス図を横型にしたイメージを持っている。
ただ、ハードウェア設計者ならタイミング図をよく使うと聞いているので、どんな状況でどのように使うのか、調べてみたいと思う。

1つの事象を複数のダイアグラムで書いてみることで、色んな観点で気づきが得られると思うし、特有の考え方や見方に慣れるメリットもあると思う。

| | コメント (0)

2024/03/03

ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる

ソフトウェア工学の根本問題は何なのだろうか?
僕は、ソフトウェアをいかに部品化して疎結合な構造とし、お互いの相互作用でいかに協調動作する仕組みを作るか、だと思う。
以下、直感的な思考を書き記しておく。

ソフトウェアの歴史をたどれば、構造化プログラミングからオブジェクト指向プログラミングへ発展した経緯を見ると、ソフトウェアの構造とソフトウェアを開発する仕組みをいかに透明化し、コントロールしやすくするか、に力点をおいているように思える。

@sakaba37さんから言われてはっと気づいたことは、ソフトウェアは密結合になりやすいこと。
トランザクションスクリプトのように、ちょっとしたロジックの処理を何も考えずに実装すると、密結合なプログラムになり、スパゲッティになりやすい。

そして、ソフトウェアを開発するプロセスも、ソフトウェアを開発する組織も、ソフトウェア構造を反映してしまうために、密結合なプロセス、密結合な組織になりやすい。

今、クラウドを基盤としたマイクロサービス設計が色々試されている。
マイクロサービス設計では、処理層とデータ層をまとめた一つのサービスを独立した単位とし、それらを協調動作する仕組みを作ろうとする。

しかし、今までのソフトウェアの歴史から類推すると、いかにソフトウェアを疎結合な構造にするか、いかにソフトウェアを管理するプロセスを透明化しコントロールしやすくするか、という根本問題から離れられていないように思える。

実際、マイクロサービスが独立した単位であっても、複数のサービスが協調動作させる仕組みをいかに安定して作るか、API設計や補償トランザクションなど、色々試行錯誤している。
ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を読めば、マイクロサービスをいかに安定して設計するか、を試行錯誤していることが分かる。

また、全てのマイクロサービスを横断して管理する仕組みとしてサービスメッシュという概念が導入されているが、それもサービスの耐障害性や可用性を担保するための監視サービス群のようなものだ。
ちょうど、Ciscoのネットワーク機器からなるネットワーク構造をSDN化したときに、データ層とコントロール層に分けて、APIを使ってコントロールしようとする仕組みと同じように思える。

他方、ソフトウェア開発の組織も今はスクラムをベースとしたアイデアに基づき、少人数のスクラムチームで開発するのが、特にマイクロサービス開発では相性がいい。
マイクロサービスでは、データ層も処理層も持つので、開発チームが必要なソフトウェア部品を全てコントロールできるからだ。
また、マイクロサービス同士のやり取りは、スクラムチームが協調動作する仕組みに置き換えられる。
実際、スクラムチームでは、プロダクトバックログというインプットとインクリメントとして付加価値を順次リリースするアウトプットが契約になるが、その中のプロセスは部外者は口出しできない。

つまり、スクラムチームは、まるで1つのソフトウェア部品のように中身はブラックボックス化されており、インプットとアウトプットというインターフェイスが保証されている仕組みと思っていい。
すなわち、スクラムチームという開発組織も、疎結合なソフトウェア部品と同様にみなせる。

そんなことを考えると、僕はクラウドやマイクロサービス設計の経験がないけれど、今までのソフトウェア開発の歴史を踏まえた根本問題から、マイクロサービス設計やその開発プロセスでは、過去の根本問題をどのように解決しようとしているのか、という観点で考えていた。
そして、その考え方から類推されるボトルネックは、昔の技術から現代のアーキテクチャに変わったとしても、症状として現れる事象が変わっただけであって、その本質は変わっていないはずだと思っている。


| | コメント (0)

2024/02/12

アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか

進化的アーキテクチャ」の本を読み直していたら、アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないかと気づいた。
ラフなメモ書き。

【1】以前に「進化的アーキテクチャ」の本を読んでいたが、その時はこの本の中身がさっぱり分からなかった。
マイクロサービス設計をコンポーネント分割、モジュール分割のように組み立てたい意図は分かるが、その設計方法や中身が雲のように意味不明だった。

そして、とある勉強会で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を輪読していた。
この本はマイクロサービス設計の解説なのだが、その中に、アーキテクチャ量子、適応度関数という考え方が出てくる。

アーキテクチャ量子は、これ以上分割できないソフトウェアコンポーネント、みたいなイメージを持っている。
適応度関数は、アーキテクチャを診断するメトリクス、みたいなイメージを持っている。
しかし、ふわふわした抽象的概念であり、すぐに理解しづらい。

なぜ、アーキテクチャ量子、適応度関数のような概念がマイクロサービス設計で必要なのか?

【2】アーキテクチャ量子とは、高度な機能的凝集を持つ独立してデプロイ可能なコンポーネントと定義されている。
なぜ、わざわざ量子みたいな言葉を使う必要があるのか?

進化的アーキテクチャ」では、量子力学のアプローチを使って、モジュール性を説明しようとしている。
物理学では、自然界には4つの力、強い力、弱い力、電磁気力、重力がある。
この概念を流用して、アーキテクチャ量子の言葉の意図は、原子核のような小さな量子では、物理学が言う強い力が働いてバラすことができないこと、つまり、ソフトウェアのコードは組み立て部品のように再利用できる単位に分解できないことを意味しているのだろう。

すなわち、アーキテクチャ量子は再利用可能なソフトウェアコンポーネント、ソフトウェアモジュールの比喩として使っている。

なぜ、わざわざアーキテクチャ量子という新しい言葉を使う必要があるのか?

マイクロサービスはソフトウェアアーキテクチャも含めたレベルでソフトウェアの再利用を目指そうとしている。
つまり、アーキテクチャ量子の考え方を使って、従来からのソフトウェア工学の根本問題、ソフトウェアを再利用できる単位にどのように再構築するか、を考えようとしているのだろう。

アーキテクチャとは、ソフトウェアの中で最も不変な部分に相当するが、ソフトウェアの歴史ではアーキテクチャの範囲がどんどん変わってきている。
再利用の単位が、構造化プログラミング、オブジェクト指向、そしてマイクロサービスへ変遷してきている。
そういう歴史的経緯を踏まえて、アーキテクチャ量子という言葉を新たに用いて、現代風に理解しようとしているのだろう。

【3】アーキテクチャ量子に加えて、適応度関数とは、アーキテクチャが継続的に変化あるいは進化することでどれだけ目的の達成に近づいているか、を計算するための目的関数と定義されている。
なぜ、メトリクスと言わずに、わざわざ適応度関数のような言葉を使うのか?

物理学のアプローチでは、自然界の現象だけでなく、経済や人間の事象に対しても、数式で表現できるはずだ、という設計思想がずっとある。
アーキテクチャ量子のように、ソフトウェアコンポーネントに物理的アプローチを用いたならば、同様に再利用できる単位は何らかの数式で表現できるはずだろう。

その時に、アーキテクチャ量子の診断結果を計測するメトリクスを適応度関数と呼んでいるのではないだろうか。

進化的アーキテクチャ」では適応関数の事例がなくて、抽象的な説明ばかりでイメージづらいが、「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」では、適応度関数の具体例が掲載されていて、それでようやく理解できた。

適応度関数は、ユニットテストレベルならばカバレッジや静的コード解析が目標範囲内にあるか評価することに相当するし、統合テストレベルならば、パフォーマンスの計測やAPIテストで目標範囲内にあるか評価することに相当する。
E2Eテストレベルならば、UATで使われる正常業務パターンのスモークテストケース、ビジネス要件やマーケティング要件を評価するメトリクスがあるだろう。

つまり、適応度関数はアーキテクチャが正常であるかを診断するメトリクスとして用いられる。

留意点は、適応度関数はケースバイケースとして色々実現されることだろう。
適応度関数は唯一の正解はなく、システムのアーキテクチャごとに設計されて実装される。
だから、GQMのように、メトリクスが使われる目的や意図が重要になってくる。

【4】アーキテクチャ量子に加えて、適応度関数のような概念を新規に作り出した意図には、物理学アプローチを用いて、マイクロサービス設計のような現代風アーキテクチャを理論化して整理したいことがあるのだろう。

再利用できる単位は、構造化プログラミングでは関数レベルだが、オブジェクト指向プログラミングでは、データと処理がカプセル化されたクラスレベルになった。
今では、マイクロサービスでは、処理を行うサービスとデータを保持するデータベースを一体化したドメインレベルで再利用しようとしている。
つまり、新しい酒は新しい革袋に入れるように、マイクロサービス設計には新しい概念を使うべき、という主張なのだろう。

すなわち、ソフトウェア工学に物理的アプローチを適用したい意図があり、それの一つの例が、アーキテクチャ量子や適応度関数になるのだろう。

そんなことを考えると、「進化的アーキテクチャ」「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」の著者は、量子力学などに詳しい物理学の専門家をバックグラウンドに持つソフトウェアアーキテクトなのだろうと推測する。

【5】物理学的なアプローチを自然科学のような自然現象だけでなく、経済現象やソフトウェア工学に適用しようという事例は20世紀後半からよく見られる。
物理学で量子力学や相対性理論が完成した後、物理学が解決すべき問題はかなりなくなってきたという話は昔から聞いていた。
だから、成功の歴史がある物理学のアプローチを使って、自然現象以外の問題に適用して、仕組みをモデル化し、問題を解決しようとする方向性はよく見られる。

たとえば、とある勉強会で、トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を聞いた。

Xユーザーのakipiiさん: 「トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を勉強会で聞いた。NNを物理で理解するのは面白いな。Unification of Symmetries Inside Neural Networks: Transformer, Feedforward and Neural ODE https://t.co/ooUEm9bLk1」 / X

この論文では、ニューラルネットワークの背後にゲージ対称性のような仕組みがあるのではと議論しているらしい。
この議論の中で、ある人が話されていた発言がすごく心に刺さった。

「人間が作り出したニューラルネットワークは人間が理解不能な状況になっている。
ニューラルネットワークで起きている座標的なもの、力学的なものを自然界に適用した物理学を使って、ニューラルネットワークの中を研究対象できるのではないか、と思える。
物理学者はこういうものが好き。物理学者は数学を作り出す。」

「ブラック・ショールズ方程式も物理学者が見つけた経済モデル。
自然ではないものに物理学的な思想、物理学的アプローチを適用したものだった。」

今のニューラルネットワークや大規模言語モデルでは、その原理や仕組みはまだ誰も分かっていないまま、Pythonで作られたNNやLLMのライブラリをいかに使って問題解決していくか、みたいなところに走っている気がして、違和感をずっと感じていた。
でも、今までの物理学の知見を使って、NNやLLMの原理を理解しようとする発想は面白いなと思う。

たとえば、経済現象でも、ブラック・ショールズ方程式のような経済学の理論も物理学者がブラウン運動の考え方を使っている。
このブラック・ショールズ方程式により、株式証券の無リスク・ポートフォリオが計算されて、現代の金融取引が成り立っているわけだ。

このように、今までに成功した歴史があり、たくさんの道具やツールが揃っている物理の手法を使うことで、経済現象やニューラルネットワークの仕組みを理解しようとしている。
物理学では現象を数式で説明するので、コンピュータに乗りやすいし、応用がききやすい。

その一連の流れに、ソフト工学に物理的アプローチを適用してみよう、という発想もあろうのだろう、と思っている。
そして、その物理的アプローチはわりと成功する可能性が高いのでは、と思ったりしている。

| | コメント (0)

«マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか