Redmineの親子チケットの功罪

RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。
Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。
考えたことをラフなメモ書き。

【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。
彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。
Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。

そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。
OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。

特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。
つまり、Redmineのメリットである「親子プロジェクトの階層は無限」「親子チケットの階層は無限」を上手く適用できれば、多数の組織も管理できるし、多数の作業もまとめて管理できる。

換言すれば、Redmineの「プロジェクトやチケットの階層が無限に作れる」特徴は、とても柔軟な機能なので、いろんな業務に適用しやすい。
だから、色んな人達が色んな業務にRedmineを適用しようと試している。

しかし、話を聞くと、業務がRedmineに完全にフィットしない場面もあるらしい。
どうやら、特に親子チケットの作り方に問題があるような気がしている。

【2】では、Redmineを実際に運用した場面で、親子チケットを使った時にどんな問題が噴出しているのか？
色々集めてみた。

【２－１】親子チケットにし過ぎる

個人のToDoを子チケットで登録して、親チケットにぶら下げる人がいる。
他の人には不要なチケットだ。
チケットが乱発されて、登録した本人ですら、チケットの棚卸しができなくなる。

根本問題は、チケットの粒度があまりにも細かすぎる点だと思う。
解決策としては、他人と共有すべき作業内容に限定する運用ルールを作る。

僕が最も推奨するのは、TODOレベルは、チケットにチェックリストを追記する運用に変更することだ。
なぜなら、個人のToDOレベルのタスクが全て終わったことが、その人のチケットの完了条件とみなせば、他人と進捗状況を共有しやすくなるからだ。
つまり、個人のToDOはチェックリストにすべきだ。

たとえば、Checklistsプラグインを入れてもいいかもしれない。

Checklists - Plugins - Redmine

但し、チェックリストを作ったとしても、チケットに未チェックが残っても、チケットが完了できてしまうリスクもある。
その場合は、下記のように、完了できなくなるパッチを当てればいい。

Redmine Checklists pluginで未チェックの検証を雑に行う - Qiita

あるいは、プライベートチケットを使う方法もあるだろう。
プライベート機能を使えば、他人には見えないから、ToDOチケットは邪魔にならない。
しかし、共有すべきチケットが存在すれば、埋もれてしまうリスクもある。

【２－２】親子チケットで、開始日・期日・予定工数のロールアップを止めたい

よくある例は、WF型開発の案件で、親チケットにSEが開始予定日・終了予定日・予定工数を入力した後、子チケットにPGが実績の開始日・終了日・自分で見積もった予定工数を入力すると、親チケットの開始日・期日・予定工数が消えてしまう問題だ。

Redmineの本来の仕様は、「WBS 100%ルール」であり、WBSに漏れがあってはいけないから、親チケットは子チケットの情報をロールアップする。
しかし、WBS 100%ルールは、実運用に合わないケースが多い。
結局、WF型開発も綺麗に運用できるわけではない。

SQIP2015の講演後の質問でも、この質問が最も多かった。

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

実は、対処としては、RedmineのVer３から、Redmineの設定画面で「子チケットから独立」を選択することで解決できる。
また、親チケットの予定工数と、子チケットの予定工数の合計は別カラムとして表示されるので、問題なくなった。

しかし、この運用が本当に良いかどうかは分からない。
WBS 100%ルールを止めるということは、WBS作成の基本ルールを破棄していることだから。

【２－３】未完了のチケットが残っているのに、親チケットが完了できてしまう

これは、WBS 100%ルールではありえない問題だが、Redmineの機能には実装されていない。
実は、RedmineのVer3.4で対応済みだ。

2016年11月のRedmine開発状況 | Redmine.JP Blog（Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止）

Redmineの次期バージョン3.4の見所: プログラマの思索

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

「Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止」のパッチによって、WBS 100%ルールが実現できるおかげで、親チケットのステータスを明確に判別できる。

【２－４】親子チケットでどこまで深く階層化するか？

Redmineの実運用では、ExcelのWBSのように5～10階層までブレイクダウンしたい目的が多い。
つまり、ExcelやMSProjectみたいに、WBSの深い階層をRedmineチケットで表現したい。

しかし、WBS 100%ルールを厳格に運用するとデメリットが大きくなると感じている。

普通、タスクは階層化しやすい。
しかし、障害やQAは階層化に合わない。

そして、深い階層のチケットは、チケット一覧画面では見通しが悪い。
むしろ、ガントチャートが向く。
ガントチャートならば、階層構造が綺麗に表現されるからだ。
だが、Redmineのガントチャートで編集できない弱点がある。

また、深い階層のチケットのデメリットはいくつかある。
一つは、 性能が悪くなること。
浅い階層では問題ないが、かなり深い階層とか、数千件の子チケットを持つチケットの操作のパフォーマンスが悪くなるらしい。
そのパフォーマンス改善のパッチがRedmine本家に提供されたが、Ver3.4ではリジェクトされている。

2016年12月のRedmine開発状況 | Redmine.JP Blog　（Defect #23318: 大量の子チケットを持つチケットで #lock_nested_set メソッドが遅い問題の改善）

実際、Redmineの実ソースでは、子チケットを表示する時に、select ～ for updateを使っているみたいだ。
つまり、ロックを故意にかけているので、性能が悪くなる可能性はある。

もう一つは、親子チケットを一括登録しようとすると一手間かかることだ。
実際、親チケットを採番しないと子チケットを一括インポートできない。
なぜなら、親チケットNoを採番しなければ、子チケットの親チケットNoを指定できないからだ。
すると、階層の数だけ、一括登録のインポート処理を繰り返し、その都度、親チケットNoを取得してはセットする手間が必要。
手作業で親子チケットは簡単に作れるが、MSProjectで作った５階層のWBSを一括インポートしたい需要はあるだろう。
どこかのツールで手軽に実行できないかな？

さらに、深い階層の親子チケットは、チケット保守が大変になる。
親子構造を変えにくかったりする。

また、バージョンが古いRedmineでは、WBS 100%ルールが実運用に合わないことは前に触れた。

そして、深い階層の親子チケットでは、WBS漏れを検知できるか？
要件チケットから成果物までのトレーサビリティをRedmineは実現できるのが、もう一つのRedmineのメリットだが、階層の深いチケットを作ると、WBSがどこかで漏れていたとしても、Redmine上ではすぐには分からない。
結局、CSV出力して、Excel上でWBS漏れを探した方が早いだろう。

あるいは、Lychee LACという有償プラグインを使って、Redmineの階層構造とトレーサビリティをツリー構造で図で表示する方法があるかもしれない。

プロセスフロー図をRedmineチケットで表現するアイデア～Lychee Association Chartで実現できるか: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3～Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

【２－５】チケットの棚卸しがやりにくい

親子チケットにすると、チケットの棚卸しがやりにくそうに感じる。
最下層の子チケットを棚卸ししなければ意味がないが、どうしてもチケットが多すぎるからだ。
駄目なプロマネはRedmineのチケット一覧で頑張ろうとして、溢れたチケットに溺れてしまう。

チケット一覧で棚卸ししようとして詰まるみたい。
すると「放置されたチケット」「停滞したチケット」「乱発されたチケット」のようなアンチパターンが生まれてしまう。

個人的には、親子チケットを使わすぎず、ロードマップを使う方が良いと思う。
つまり、バージョン＝納品日、締切日として運用して、ロードマップ画面でチケットを取捨選択する運用に切り替えるわけだ。
僕がRedmineを運用して、これがアジャイル開発の本来のマネジメントなのだ、と気づいた機能の一つ。

チケット駆動開発の戦略: プログラマの思索

Redmineのロードマップ画面では、右クリックでチケット編集コンテキストメニューを出せるので、ロードマップ画面上で優先度を考えながら、チケットの属性を編集できる。

しかし、Redmineのロードマップ画面も機能不足と感じる。
ロードマップ画面で、チケットの優先順位を付ける機能がないからだ。

現状では、下記の３つしかやり方がない。
しかし、チケット枚数が増えるとロードマップ画面でも厳しくなる。

１・チケットの優先度を設定する
→なる早が増える

２・先行・後続の関連を付ける
→チケット操作が複雑。ガントチャート画面で編集できない。

３・バージョンを設定する
→チケット枚数が増えるとチケットが溢れる。本来は、チケットの並び順で優先度を付けたい。

本来は、ロードマップ画面で、チケットをD&Dして並び替えて、チケットの並び順で優先度を付けたいのだ。
このパッチは、実はRedmine本家で既に提供されている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

2016年9月のRedmine開発状況 | Redmine.JP Blog（Feature #22802: バージョン内のチケットをドラッグ＆ドロップで並べ替え）

ここで、Scrumのプロダクトバックログでは、タスクカードの並び順が作業順序である。
つまり、開発者は、バックログの一番上からタスクカードを取り出して、作業をこなしていけばいい。
開発者は優先順位について考える必要はない。

一方、プロジェクトオーナーやプロダクトオーナーは、プロダクトバックログを常に精査して、どのフィーチャの実現を優先すべきか、取捨選択して、並び順を優先順位として考えればいい。

つまり、Redmineのロードマップ画面はもっと改良できる余地がある。
Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineでは、ロードマップ画面の並び順だけでなく、チケット一覧画面の並び順も考慮すべきでは？という議論があるが、それはナンセンスだ。

チケット一覧画面は、クエリによってある特定の検索条件でチケットのリストを抽出だけの機能だ。
しかも、ソート順も検索条件の一つになっている。
そもそも、D&Dでチケットの並び順を変更する必要もない。

一方、ロードマップ画面はリリース計画で使うべき機能だ。
この画面こそが、チケットの取捨選択を行うべきRedmineの中核機能だ。
だからこそ、Redmineにもっとアジャイル開発の特徴を取り込みたいのだ。

個人的には、Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineに数多くの人が「＋１」のコメントを付けて、Redmineの機能の一つとして実現して欲しいと思う。

【３】こう考えてみると、Redmineは先進的なプロジェクト管理を行う実験場であり、機能面でも運用面でもまだまだ改善の余地はたくさんあると思う。
チケット管理には、プロジェクト管理を効率化させる可能性がまだまだ秘められていると思う。

【追記】
皆さんのツイートがとても興味深いので、メモしておく。
もっと、皆さんの経験に基づいた奥深い議論がしたい。

門屋　浩文さんのツイート: "@akipii WBS関連で親子関係についてはいつも議論になりますがプロジェクトのベースを合わせることを意識した説明、意識づけをしてます ロードマップは合わないかなと思い説明はしてません"

akipiiさんのツイート: "@MadoWindahead 個人的には、ロードマップ画面こそがRedmineの中核機能と思います。でも機能が足りない。チケット一覧画面で皆頑張ろうとしすぎ。親子チケット、親子PJの運用方法はまだまだ改善の余地がある。"

ニートン 岩崎さんのツイート: "親子チケットは罪しかないので、親子チケット作らないようにして、それに該当するのはカテゴリやマイルストーンで代用してる https://t.co/vx7eXRiBPZ"

akipiiさんのツイート: "@neeton_iwasaki Redmineの親子チケットや親子PJは、メーカーのような機能別組織にとてもマッチしてます。親チケットは設計部門が作り、製造部門が子チケットにタスクをぶら下げて、進捗管理するとか。多分、日本のSIやメーカーは親子チケットが好きなのでしょう笑"

データフローダイアグラムではプロセスは一番最後に書く

データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。
記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。

【参考１】
データフローダイアグラムの書き方

(引用開始)
プロセス，データの発生源・行き先，データの保管元・保管先全てに名前がついているにもかかわらず，データの流れにだけ名前がついていないDFDを見かけることがあります．
これらはDFDの役割を果たしていません．
DFDが表現しなければならないのは，プロセス，データの発生源・行き先，データの保管元・保管先を行き来するデータなのです．
データの流れに名前をつけないのは，DFDが最も表現しなければならないものを表現していないということです．

図6.プロセス名は最後につける
(引用終了)

(引用開始)
入出力するデータからプロセスの内容の推測が困難な場合，原因はプロセスの機能分割が適切ではないことが多々あります．
プロセスは，例え名前がなくても，入出力データからその内容を容易に推測できるものでなくてはなりません．

データの流れに名前をつける際には，「～情報」や「～データ」と言う名前をつけてはいけません．
抽象的すぎ何を表わしているのかわかりません．
図6の営業所からのデータの流れの名前が「販売実績」ではなく「営業所情報」や「販売情報」だったら，何を表わしているのかわかるでしょうか．
もし，データの流れに具体的な名前がつけられないのなら，DFDの作り方に間違いがあります．再検討しましょう．
(引用終了)

【参考２】
DFD(データフローダイヤグラム)の描き方（１） | ステキな一日

(引用開始)
仕事でDFDを書く機会が多いのだが、DFDの書き方を知らない人が多いのでここにメモしておく。
自分自身が１００％完璧に使いこなしているわけではないので、自分の理解している範囲での内容となる。

データフローダイヤグラム(DFD)は単独で成り立つものではありません。
データディクショナリーとミニ仕様書という三点セットで業務分析を行う際に使用します。
システムの概念だけを伝えるのであれば、DFD単体でも良いのかも知れませんが・・・。
(引用終了)

DFD(データフローダイヤグラム)の描き方（2） | ステキな一日

(引用開始)
さて、DFDの描き方です。一番初めに何を描きますか？

（１）今回の対象外となるものをすべて描き出します。
これは外部要素となるものです。それは取引先だったり、外部システムだったりします。

（２）そして外部要素への入出力を描きます。（これは対象外への最終的な入出力となります。）

（３）データフロー名は必ず書くようにしてください。
プロセス名を入れたいかも知れませんがプロセス名は無くても大丈夫です。（後で入れられるし、変わるかもしれないので）

（４）今度はデータフローをよく見ていきます。
足りないデータフローがたくさんあるはずですから、図にどんどんデータフローを足していきます。
また、データフローが変換されるところや複数に分岐するところにはプロセスも足していきます。
そうやってどんどん書き足していくと、データを保管する所も見えてきますのでデータストアも書き足していきます。
そうやって、描き替えながらユーザとどんどん対話してください。
(引用終了)

DFD(データフローダイヤグラム)の描き方（3） | ステキな一日

(引用開始)
DFDを書くうえで一番重要なのがデータフローの名前の付け方です。
データフロー名の付け方によってＤＦＤの分かりやすさはかなり違ってきます。
ここが一番肝心かなめのところですから手を抜かないようにしてください。

プロセスに名前を付ける段階ではデータフローのすべてに名前が付いてなければいけません。
はじめにプロセスに名前を付けたいかもしれませんが、ぐっと我慢をしてください。
プロセスに最後に名前を付けるのは、データフローを正しく書くために必要です。
(中略)
プロセスに先に名前を付けてしまうと、DFDを書けてしまった気になって肝心のデータフローがおろそかになったり、分析が足らなかったりしますので、注意してください。
(中略)
エクセルの図形で描いてもいいのですが、それでは書き直しが面倒になってきて、かなり出来の悪いDFDしか書けないと思いますのであまりおすすめできません。
それよりは手書きの方がマシだし、それともVISIOでも良いです。　
個人的にいちばんおすすめなのが astah* professional というソフトウェアです。
(引用終了)

DFD(データフローダイヤグラム)の描き方（4） | ステキな一日

(引用開始)
DFDにセットで必要になるものがあります。それがデータディクショナリーとミニ仕様書です。

データディクショナリーには、データフローの内訳を記述します。
そして、ミニ仕様書にはプロセスの内容を記述します。DFD、データディクショナリー、ミニ仕様書が揃ってひと塊となります。
どれが欠けても中途半端です。
(中略)
しかしながら、これもまた、DFD、データディクショナリー、ミニ仕様書を行ったり来たりしながら、ブラッシュアップさせていくものです。
(引用終了)

DFD(データフローダイヤグラム)は業務システム設計でよく使うけれど、何故か描きにくい、と思う時が多かった。
缶アイコンのデータストアは書けるのだが、プロセスがイマイチしっくりこない時が多い。
上記の記事を読んで、プロセスを最初に書いてしまうので、それに引きずられて、本来のモデルが描けなくなっているのではないか、と気づいた。

「プロセスの名前は一番最後に書く」。
つまり、外部要素やデータフローをじっくり書き込んで、漏れを無くし、整合性を取った後で、最後にプロセスの名前を書けばよい。
DOAでは、データが主であり、プロセスは従の立場だから。
プロセスは最後に名前付けすることで、データの入出力やタイミングに集中して分析できるようになる。

これから気をつけようと思う。

Redmineの次期バージョン3.4の見所

@g_maedaさんのRedmine開発状況の記事を読んで、Ver3.4のリリースが楽しみになってきた。
以下、ラフなメモ書き。

【参考】
2017年1月のRedmine開発状況 | Redmine.JP Blog

2016年12月のRedmine開発状況 | Redmine.JP Blog

2016年11月のRedmine開発状況 | Redmine.JP Blog

【1】Patch #21705: 「長いテキスト」形式カスタムフィールドの「ワイド表示」オプション

Patch #21705: Option for long text custom fields to be displayed using full width - Redmine

テキストエリアのカスタムフィールドの領域を広くしてくれるオプションが付く。
たとえば、障害報告用のカスタムフィールドをたくさん作っている場合、障害原因・是正対策の内容を記載してもらう時に、現在のバージョンでは、テキストエリアの領域が狭いので、書きにくいし読みにくい。
結局、入力が億劫になる。

この改善のおかげで、障害報告チケットの見栄えも良くなり、その分、チケット更新者の動機づけも上がるだろうと思う。

【2】Feature #23265: バージョン形式カスタムフィールドのフィルタをステータスごとにグループ化

Feature #23265: Group versions by status in version custom field filter - Redmine

使い道としては、Redmineのバージョンをシステムのリリースバージョンとして扱っている場合、障害が起きたリリースバージョンとか、影響のあるリリースバージョンのような項目がステータスごとにグルーピングされる。
Redmineの運用期間が長くなるほど、バージョンも多くなってくるので、こういう細かなUI改善は、利用ユーザにとって嬉しい。

【3】Feature #23310: 「プロジェクトへ移動…」ドロップダウンの改善

Feature #23310: Improved "jump to project" drop-down - Redmine

画面右上のプロジェクトプルダウンに、インクリメンタルサーチ機能が付く。
Redmineの運用期間が長くなるほど、プロジェクト数は数百～数千に増えてしまうので、こういう細かな機能改善はありがたい。

【4】Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

WBSの階層構造を親子チケットで表現した時、現状のRedmineでは、子チケットが全て終了ステータスでなくても、親チケットは終了ステータスに変更できる。
しかし、本来のWBSの100％ルールでは、そうではない。

この機能改善では、設定画面で、WBSの100％ルールの可否を選べるようになるので、より厳密にWBSをチケットで表現できるようになる。

個人的には、WBSを親子チケットで表現した場合、親チケットが子チケットから独立させない、とか、未完了の子チケットを持つ親チケットのクローズを禁止すべき、というルールを完全に当てはめると、実運用ではやりにくくなる経験が多かった。
結局、適度に緩い運用の方がやりやすい。
この辺りの運用ノウハウは、各地のRedmineエバンジェリストの意見を聞きたいところ。

Redmineの親チケットの値に子チケットをロールアップさせない設定方法: プログラマの思索

チケット駆動の罠～複雑さはチケットの粒度に関連している: プログラマの思索

【5】個人的に欲しい機能は、「Feature #24681: シンタックスハイライトの対応言語を100以上に増やす」だ。

Feature #24681: Syntax highlighter: replace CodeRay with Rouge - Redmine

.NET開発者は普通にたくさんいるので、彼らから、C#もシンタックスハイライトに対応して欲しい、という要望は非常に多い。
しかし、現状のRedmineでは、シンタックスハイライトの対応言語にC#が対応していないという悲しい事実がある。
Redmineはチケット管理だけでなく、Wikiやリポジトリのソース差分表示などもよく使うので、早く実現して欲しいと思う。

【その他】
奈良さんがRedmine本家に、Redmine.orgの全チケットに対し、「＋１」のコメントを集計した結果を載せてくれている。
「Redmineの改善要望チケットが埋もれているためにフィードバックされていない」事実に危機感を持っていて、集計結果を掲載することで、実際に行動に移してくれた。

Redmine.org tickets vote count list - Redmine

コントリビュータのMischa The Evilがこんなコメントを残してくれている。

「私は、この拡張リストは、コミュニティの興味を見つけるための素晴らしい情報源だと思う。
そういうわけで、これらは非常に貴重な貢献だと思います。
作成して共有していただきありがとうございます。」

このフィードバックが今後のRedmineのリリース計画に活用されたら、Redmineはもっと使いやすくなるだろうと思う。

Unofficial Redmine CookingプロジェクトでRedmineカスタマイズのノウハウを皆で集めてみよう: プログラマの思索

Redmine本家未取込チケットで人気のあるチケット情報: プログラマの思索

Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる症状に対する対応方法

Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる症状が発生して、困っていた。
この対応方法について、@netazone さん、@g_maedaさんに教えてもらったのでメモ。
二人に感謝。

【参考１】
Defect #24617: Browser js/css cache remains after upgrade - Redmine

neta＠とんこつしかたべないさんのツイート: "バージョンアップ後のRedmine 3.3 の表示が崩れる、と思ったら再読み込みでなおる。 →つまりブラウザ側のキャッシュか。 Redmineのセッションクリアはやったと思うんだが、これはどうしようもないんかな"

MAEDA, Goさんのツイート: "@netazone パッチが出てます https://t.co/12AcycptT2"

neta＠とんこつしかたべないさんのツイート: "@g_maeda @akipii 件のパッチを本番反映してみました。ブラウザ履歴からバージョンアップ前に開いたチケットをいくつか開いてみましたが、発生していません。別PCで1回だけ崩れましたが、ブラウザ開きっぱの端末だったので怪しいです。明日騒ぎにならなければ効いたといえそうです"

MAEDA, Goさんのツイート: "@netazone @akipii 崩れるときはバージョンアップ前に開いたページでなくても崩れます。HTMLのソースの中で読み込んでいるCSSやJSのファイル名の後ろに ?1486805824 みたいに数字がついてればOKです。"

neta＠とんこつしかたべないさんのツイート: "@g_maeda @akipii ソース表示で確認できました。ありがとうございます。 Redmine 3.3.2で適用は以下やりました。 ・パッチ適用 ・tmp:cache:clear tmp:sessions:clear(念のため) ・Redmine再起動 https://t.co/4nbGURiyOf"

【参考２】
Redmine3.3で表示崩れする件で色々教えていただいた | UCWD-Studio - @matsuoka_UCWDjp 's Private Projects.

【状況】
Redmineを2.x→3.xにVerUpした時、ローカルPC上では全く問題なのに、サーバー上でVerUP後、画面レイアウトが崩れてしまう。
その原因がどうしても分からず、結局、リストアせざるを得なかった。
サーバー上でキャッシュクリア、クライアントでクッキーをクリアしても、再現してしまうみたい。

【原因】
@g_maedaさんに教えてもらった下記チケットによれば、VerUp時にjs/cssのキャッシュが残ってしまうのが原因みたい。

Defect #24617: Browser js/css cache remains after upgrade - Redmine

本来は、画面ソース上では、
＜script src="/redmine/javascripts/application.js?1481777729"＞＜/script＞
のように、JSやCSSにセッションIDらしき数字がURLに付加されるのに、なぜか、Ver3.3にVerUpすると、
＜script src="/redmine/javascripts/application.js"＞＜/script＞
のように表示されてしまう。

【対応方法】
Defect #24617: Browser js/css cache remains after upgrade - Redmineにあるパッチを当てればいい。

cd redmine/config/initilizers
wget http://www.redmine.org/attachments/download/17275/0001-Adds-asset_id-parameters-to-assets.patch
↓
patch -p1 < 0001-Adds-asset_id-parameters-to-assets.patch
10-patches.rb　を入力
↓
念の為にキャッシュクリア
bundle exec rake tmp:cache:clear tmp:sessions:clear
↓
Apache再起動
↓
チケット画面のソースを開くと、JSやCSSにセッションIDらしき数字がURLに付加されている

色々試してみると、下記のパターンになるみたいだ。

・Ver2.xの時は、JSやCSSにセッションIDらしき数字がURLに付加されている
　⇒問題なし

・Ver2.x→3.xへパッチを当てずにVerUpすると、JSやCSSにセッションIDらしき数字は付加されない
　⇒画面レイアウトが崩れる

・Ver2.x→3.xへパッチを当ててVerUpすると、JSやCSSにセッションIDらしき数字は付加される
　⇒問題なし

【疑問】
なぜ、こういう症状が発生したのか？
上記チケットの下記リンクを見ると、Ver4.2.7で廃止されたrails_asset_idメソッドから作ったパッチを当てると、解決できるらしい。

rails_asset_id (ActionView::Helpers::AssetTagHelper) - APIdock

さらに@marutosijpさんのコメントを読むと、Redmineのconfig/application.rbのasset pipeline がdisabledになっているのが原因みたいらしい。

Patch #13927: Reduce coupling between plugins and the "plugins/" directory - Redmine

config/application.rbの下記の箇所になる。

# Enable the asset pipeline
config.assets.enabled = false

/trunk/config/application.rb - Redmine

Railsの仕様を完全に理解していないので、調べてみる。

【追記１】
下記の意見もあるので、この症状に再現性があるかどうか分からない。

松岡　孝さんのツイート: "@akipii @g_maeda 今のところ問題を感じる挙動には遭遇してません。なお、3.x系は 2.6.xから3.1.1→3.1.3→3.2.1→3.2.3→3.3.2を経由してまして、その間も特に不具合に遭遇してないつもりです(除: 今回のUI部分)"

下記のBlogで原因と対処を詳細に記載してくれてます。

Redmine3.3で表示崩れする件で色々教えていただいた | UCWD-Studio - @matsuoka_UCWDjp 's Private Projects.

(引用開始)
これは Redmine 3.0.0 から Rails のバージョンが 4.2 へ移行した際に、CSS や JavaScript などの静的ファイルに付与されていた GET パラメータが付与されなくなったため、前バージョンの静的ファイルをブラウザ側がキャッシュとして持っていること(＝そちらが表示に利用されている)が原因のようです。
(引用終了)

つまり、Ver2.x→3.xではcssなどで大きなUI変更があったために、前バージョンのキャッシュが残ったために画面レイアウトが崩れた。
一方、Ver3.3.1→3.3.2では、大きなUI変更がなかったために、前バージョンのキャッシュが残っていたとしても、画面レイアウトが崩れることはなかった、と推測される。

【追記２】
クライアント側では、ブラウザのスーパーリロードで対応できるらしい。

ブラウザの super reload でゆけそうな気がする。職場の Redmine も 2.x から 3.x 系に移行して更に 3.x で数回更新しているが毎回 super reload するよう案内してる。 - akabekobeko のコメント / はてなブックマーク

君は3つのリロードを知っているか？ - os0x.blog
(引用開始)
ブラウザによっては、スーパーリロードという機能を備えています。IEの場合Ctrl+F5(Ctrl+更新ボタン)、Firefoxの場合Ctrl+F5(Shift+更新ボタン)、Chromeの場合Shift+更新ボタン(Ctrl+Shift+R)などでスーパーリロードを呼び出すことができます。
(中略)
リロードは大元のHTMLを受け取ったら、そのページ内のリソースについてレスポンスヘッダを確認しに行っています。その結果304 Not Modifiedが帰ってきて、実際にはキャッシュを使っています。
対してスーパーリロードはキャッシュに関係なく、すべてのリソースを取得しなおしています。
(引用終了)

【追記３】Redmineを2.6から3.3にアップデートした - Qiita
(引用開始)
無事起動を確認できた…のだが、どうも一部の表示がおかしい
タブやボタンなどが重なっていたり２重になっていたりする
ん～レスポンシブルデザインでスマホで見れるようになったのが個人的に嬉しくてアップデートしたのだけれど…
デフォルトテーマにしても同様の様子、またCSS見てみるか
データは全然問題なかったので一安心

追記：
chromeだと崩れてedgeだと正しく表示された
メインPCのchromeのみで崩れるようなので、調べてみた所、chromeのキャッシュクリアで治った
(引用終了)

2.6→3.3へのVerUpなので、今回と同じ症状（タブやボタンの配置が崩れる）が出ている。
Chromeのスーパーリロード処理を実行して直った、と思われる。
Edgeで画面レイアウトが崩れなかった理由は、今までEdgeを使っておらず、初めて使用したので、古いバージョンのCSSやJSのキャッシュがなかったためと思われる。

【追記４】
まとめ記事がある。

QA #301: Redmine 2.x→3.xへVerUpした時に画面レイアウトが崩れる場合がある - Unofficial Redmine Cooking - redmine.tokyo

【追記5】
Ver3.4にパッチが取り込まれたので安心した。

第53回IT勉強宴会「深層学習の概要とドメインモデル」の感想

第53回IT勉強宴会で、能見さんの「深層学習の概要とドメインモデル」を聞いてきた。
すごくワクワクして、面白かった。
自分は初心者なので、理解できたことをラフなメモ書き。
間違っていたら後で直す。

【参考】
深層学習の概要とドメインモデル＜第53回IT勉強宴会＞ : ATND

深層学習の概要とドメインモデル＜第53回IT勉強宴会＞ | ＩＴ勉強宴会blog

Deep learningの概要とドメインモデルの変遷 from Taiga Nomi

【1】昔流行したニューラルネットワーク理論と深層学習の深い関係

僕の一世代上の人たちから見ると、ニューラルネットワークがすごく流行して冬の時代になったのを知っているので、理論は既に知っているが、本当に使い物になるのか、という思いがあるみたい。

単純パーセプトロンで、０または１に分類するのは、回帰直線による相関分析。
でも、そのままでは当然解けない問題もある。

多層パーセプトロンにすれば、非線形な問題は活性化関数を用いて線形分離できるように変換すればいい。
シグモイド関数が有名だし、それ以外にも色々ある。

多層パーセプトロンのボトルネックは、学習コストを最小化する関数を求める時、真の極小解ではない極小解に落ち込んでしまって、そこから脱出できなくなる点。
誤差逆伝播法で、勾配を少しずつ計算して、誤差をフィードバックして、鞍点にはまらないように学習していく。

でも、過学習の問題も出てくる。
この辺りは、人間が、スポーツや勉強をあるパターンだけで進んでいくと頭打ちになり、いくら努力してもそれ以上伸びない、という症状によく似ている。
他にも、教師あり学習とか、強化学習は子供の躾、ペットの躾に似ているとか、すごくアナロジーしやすい。

そういう時代を過ぎて、2012年に深層学習が画像認識の精度を大きく上げるブレイクスルーが起きて、深層学習が流行し始めた。

講演で最も興味深かった点の一つは、「なぜ、学習の構造はDeep（深層）なのか」。
「なぜディープラーニングが、これほど世の中の多くの問題にうまく適用（特に認識）できるのか？」
「Linの仮説」というものが説明しようとしているが、その理由は、まだ理論として結果は出せていないらしい。

深層学習は 世界をどのように変えられるのか - IBISML

能見さんの「直観的な理解：対象の階層的な構造をうまく取り込めるから」という話を聞くと、人が物事や現象を理解しようとする時、ツリー構造で概念を分解して理解しようとする方法と上手くマッチしているから、と理解している。
たぶん、深層学習の仕組みは、人間の脳の仕組み、人間が物事を考える仕組みの本質に触れているからこそ、プログラムで実装してその威力を発揮できているのだろうと推測する。

【2】深層学習はどこまで知性に近づいているのか

深層学習はニューラルネットワークをプログラムで実現しているので、まさに人の脳の神経回路のシミューレションに近い。
では、深層学習はどこまで人間の知性に近づいているのか？

話を聞く限り、2017年始め時点では、画像認識などの分野で人よりも認識の精度は高いが、全ての分野で置き換えられているわけではない。
まだ知性まで追いついていない。

渡部幸三さんが質問したように、深層学習が画像認識の処理をした後で、「美しさとは何か」という問いに対して、その特徴量、その評価基準が知りたい。
しかし、現時点の深層学習のフレームワークでは、中間パーセプトロンの中身はいちおうトレースできるが、「美しさ」の特徴が何であるか、明示しているわけではない。
深層学習の処理結果として、入力した画像を犬か、猫か、ゴッホの作品なのか、とフィルタリングしているだけ。

深層学習による画像処理において、ある風景写真をゴッホ風にアレンジする、というシミュレーションした絵があって面白かった。
ちょうど、昔のセピア風、プリクラ風の写真の加工に似ている。
では、ゴッホの絵の美しさの特徴は何なのか、と抽象的な概念で言い表して欲しいが、それは明確ではない。

なぜ、美しさの特徴を知りたいのか？
やはり、人間なので、その結果に至る道筋、ロジック、原因が知りたい。
もしそれが完全に判明したとしたら、プラトンのイデア論を立証できることになる気がする。
つまり、美しさの本質はこれこれです、と明確に言えるならば、全ての人の心にはそれが宿っているので、お互いに理解し合えるのだ、というロジックで言いたい。
最終的には哲学の性善説に行き着く気がするが、現時点の深層学習はそこまで人間の心理の本質まで迫っているわけではない。

現在、深層学習をベースとした人工知能の研究は、アメリカと中国で相当激しく進んでいるらしい。
また、東京での人工知能や機械学習の勉強会は、すぐに定員いっぱいになるぐらい人気があるらしい。
今はブームが始まったばかりで、深層学習のどのフレームワークが生き延びて集約されるのか、分からない状態なので、面白いみたい。

「推計学のすすめ」「経済数学の直観的方法～確率統計編」の感想

『推計学のすすめ』と『経済数学の直観的方法』の確率統計編がとても素晴らしくて、すごくはまった。
以下、ロジカルでないラフなメモ書き。
間違っていたら後で直す。

【参考】佐藤信、1968、『推計学のすすめ』 - しょうもないことかきました

直観でわかる統計学 - 講義のページにようこそ

『経済数学の直観的方法　確率・統計編』（その1）　長沼伸一郎著 - ケスケラの読書と旅の日記

『経済数学の直観的方法　確率・統計編』（その２）　長沼伸一郎著 - ケスケラの読書と旅の日記

Amazon.co.jp： 経済数学の直観的方法 確率・統計編 (ブルーバックス)の Nogisuさんのレビュー

【1】統計的仮説検定は正直わかりにくい。
なぜ、わざわざ、主張したい仮説を否定した仮説を立てた後、統計処理を行って否定した仮説を棄却して、主張したい仮説が正しい、というロジックを使うのか。

その理由は、統計的仮説検定は「確率的背理法」の考え方に基づいているから。
つまり、仮で立てた仮説が5％未満でしか確率的に起こり得ない、ということは、ほとんど起こらないだろうから、仮で立てた仮説は成立せず、元々の仮説が正しい、というロジックの流れ。
すなわち、完全な背理法ではなく、95％の確率の正しさで背理法を使った考え方、と思った方がいい。

『推計学のすすめ』には、この考え方による統計的仮説検定の事例をたくさんあげて、いろんな統計分布を使った話が載せられていて、とても分かりやすい。

正規分布、ｔ分布、F分布、χ＾2分布などをどんな場面で使って、どんな意図で用いるのか、という事例が分かりやすい。
上記Blogの感想に全く同意だが、1960年代に書かれた本なので、その事例に出てくる現象が時代的に古いように感じるのもすごく良い。

(引用開始)
この本はすごい。
1968年に出てるというのがもっとすごい。
筆者の佐藤さん、国税庁醸造試験所に長年勤めていたというのも、ギネスで働きながらスチューデントの筆名で論文出してたゴセットと似ていてかっこよい。
（中略）
推測統計の発想の根本を、懇切丁寧な解説と、豊富な例示とで示してくれるとてもありがたい本。
（中略）
t検定とかF検定とかχ2検定とか、Z標準化とか、なんとなく知ったかぶりでスルーしたけど、結局何なの？どれをいつ使うの？おいしいの？などの疑問がこの本でたいてい氷解する。
推測統計やるなら絶対にまずはじめの一冊。そのあと小難しい本に入っても、混乱したらこの本に戻るといいと思う。とにかく手元に1冊あるとよい。
さすがに60年代の本だけあって、例や言葉遣いが古いがそれがなおさらよい。
(引用終了)

【2】一般に、確率統計はすごく分かりにくい。
サイコロやコインの確率が、なぜそんなに奥深いのか？

【2-1】統計学を生み出したガウスの本来の思想は、確率論ではなく、誤差論だった。
「バラつき＝トレンド＋ボラリティ」という考え方があり、ボラリティは正規分布の形になる。

では、どうして現実の物事は正規分布に従うのか？
「経済数学の直観的方法～確率統計編」によれば、正規分布のイメージはパチンコと同じ。
つまり、パチンコに無数の球を落とすと、パチンコ台の下に積もった球は正規分布の形をなすイメージ。
これがボラティリティに相当する。

しかし、この正規分布の曲線が「exp^(x^(-2))」であるために、その微分・積分が高校数学では扱えないので、多くの人がトラウマになっている、ということらしい。
つまり、パチンコ台に有限個の球を落とすと2項分布になるが、その極限が正規分布の曲線になるという計算は、高校生では解けない。
すなわち、確率分布の計算が複雑怪奇になっていて、とても分かりにくいのは、そこに理由があるのかもしれない。

【2-2】しかし、すべての物事が正規分布に従うという理論はやはり腑に落ちにくい。
たとえば、人の学力は正規分布に落ち着く、というのは本当に正しいのか？
真面目にコツコツ勉強しても間違って暗記した人、要領よく勉強して高得点な人、そんないろんな選択を正規分布は飲み込んでいるのか？

「経済数学の直観的方法～確率統計編」によれば、その答えは、中心極限定理が解決してくれる。
実際は、色んなパターンの確率分布の曲線が発生するが、それら様々な確率分布を全て合成して極限に持っていくと、中心極限定理によって、その結果が正規分布になる、と。
つまり、中心極限定理は、二項分布の極限が正規分布になる、というだけでなく、様々な確率分布が合成されて極限に持っていくと正規分布になる、と主張している。（言いすぎかも）

中心極限定理のメリットは、心理学・経済学・社会学のような分野に適用して、それら予測に使えるからだ。
たとえば、株式市場では、政治状況や人々の心理状況などのパラメータに起因するたくさんの確率分布があるが、全て合成して極限に持っていくと、正規分布に落ち着くので、逆に扱いやすくなる。
つまり、株式市場のパラメータがたくさんあったとしても、逆に全ての確率分布を合成するほど、正規分布に近づくので、正規分布の特徴さえ分かれば、株価を予測できるようになる。

【2-3】株式市場への貢献としては、オプション価格の計算に使われたブラック・ショールズ理論がある。
このブラック・ショールズ方程式はとても難しく、経済学部の学生もつまずくものらしい。

ブラック・ショールズ方程式の背後には、ウィーナー過程という考え方がある。
株価のバラつきは理論物理のブラウン運動に似ている。
ブラウン運動では、時間が経つとボラティリティが増大する。
そのボラティリティは時間の平方根に比例する、つまり、「ボラティリティは√ｔに比例して拡大する」という法則があり、これがウィーナー過程と呼ばれる。

ウィーナー過程は正直分かりにくいが、ブラウン運動でボラティリティが増大する原因は、時間というよりもジグザグ回数が増えることと同じ。
この発想を株式市場に生かすと、株価のボラティリティ（バラつき）は株取引回数が時間と共に増えることであり、それが時間の平方根に比例する。

つまり、ボラティリティが大きいほど、株価は高くなる確率になるので、その時に売れば儲かる。
金利差や価格差を利用して売買して利鞘を稼ぐ裁定取引、いわゆるサヤ取りがこれに相当する。
また、株や国債は長期で保持した方が儲かる、という理由も、ここにあるのかもしれない。

【3】上記のAmazon感想にこんな感想があって、すごく同意した。

(引用開始)
私はいわゆる理系出身で、工業用のセンサ開発に関わっている。
私の働く業界では、本書でいう「ボラティリティ」を最小に抑え込み、「トレンド」を除去することで、品質を一定に管理することに腐心している。
このため、ボラティリティから何等かの「益」を得るという発想を持っていない。
この発想そのものが目から鱗の驚きであった。
(引用終了)

【3-1】製造業の品質管理では、完成品のバラつきを一定の範囲内に閉じ込めるように、厳しくチェックして出荷する。
つまり、たとえば、あるボトルネック工程で部品の歩溜まりが低い、と言った問題点は改善策を用いて解決して、「トレンド」となるバラつきを取り除く。
また、たとえば、全数検査でなく一部しか検査できないために観測できない誤差といった、「ボラリティリティ」のバラつきは最小限に押さえ込む。
たぶん、管理図の手法を使っているのだろう。
それによって、一般消費者は、品質が安定した大量製品を安価に買うことができる。

【3-2】一方、株売買、原油の先物取引のような金融取引では、ハイリスク・ハイリターンなので、ボラティリティが大きいほど、儲けが大きくなる。
なぜなら、ファイナンスの世界では、リターン＝期待値、リスク＝バラつき（偏差）という関係があるからだ。
つまり、ハイリスクで成功すればハイリターンが得られる。

昨今なら、トランプ現象のおかげで、株売買で儲けた人もいるのではないか。
つまり、「ボラティリティから利益を得る」という発想があるのだ。

ブラック・ショールズ方程式では、金融商品のボラティリティを数学的に求めて、金融商品のオプション価格としてあらかじめ算出することに成功した。
そのおかげで、金融取引市場が成立したわけだ。
その背景には、ウィーナー過程の考え方、つまり、「ボラティリティが√ｔに比例して拡大する」という考え方がある。

【3-3】この辺りの話はイマイチ分かりにくいが、以前、簿記1級を受講していた時、先生からこんな話を聞いたことがある。
本来の株式市場では、100株1000万円のような株を買いたい場合は、普通は手持ちのお金がなければ買えない。
しかし、ノーベル経済学賞を取った偉い学者（ブラックさん？）のおかげで、株式市場に、ある一定の入場料を支払えば、「株を将来買う権利」「株を将来売る権利」という形で、株の売買に入場できるようになった、と。
つまり、株式市場で金融取引を行うための入場料が、ブラック・ショールズ方程式で求められるオプション価格なわけだ。

そのおかげで、株式市場にもっと大量の人が簡単に入場できるようになり、株の売買がより一層活発になる、というメリットが生まれる。
日本政府がNISAなどを導入して、株式市場を活発化させたい、という意図はそんな所にも関連しているのだろうと思う。
株価が上がれば、NISAなどに投資した人にもお金が行き渡り、日本人の収入向上に役立つから、という流れなのだろう。

最終的には、企業はランダムな世界でも物事の連動性に注目して適切に意思決定することにより、ボラリティリティから利益を得ることが可能という事実から、企業は恒常的に利益を上げ続けることができる、という流れ。
この発想の類推から、マクロ経済学における経済成長理論につながるのだろう。

【4】こういう確率統計の理論の本を色々漁ってみると、チケット駆動開発の時と同じような匂いを感じる時がある。

【4-1】たとえば、従来の統計学では、計算力不足のために、大量データがあっても簡単に計算することができなかった。
昔は、数学的理論で確からしさは保証されているのに、コンピューティングパワーが不足していたから、その理論を使った実地検証がしづらかったわけだ。

しかし、今は、強力なコンピューティングパワーが安価で誰でも手に入るようになったので、統計学の理論をバックにプログラミングを縦横無尽に使って、文系理系を問わず、従来の自然・工学分野だけでなく、心理・社会・経済のような分野に適用して、色んな知見が得られるようになってきた。
たとえば、「ワーク・ルールズ」の本のように、Googleが自社の人事施策に統計理論を使っているように。

つまり、自然科学や工学で使われている従来の理論に対し、その適用分野を心理・社会・経済へ変えることで、別の新たな知見を見出だせる。
たとえば、理論の使い道をちょっと変えるだけで「ボラティリティを押さえ込む」のではなく「ボラティリティから利益を引き出す」という発想が生まれるわけだ。

【4-2】最近の人工知能も、その流れに似ている。
深層学習の背景にあるパーセプトロン、ニューロン、確率降下法という考え方は既に1960年代頃から理論として構築されていた。
だが、当時はコンピューティングパワーが不足していて、そもそも意味ある計算を実現できなかった。
しかし、今は違う。

その気になれば、PythonやR、AIのOSSのフレームワークを使えば、プログラムでいくらでも計算して、応用できる。
つまり、昔の数学や物理の理論を知らなくても、プログラミングできるならば、実際にプログラムで計算実行させて、意味ある応用結果を導ける。
その計算の後に、そのプログラムの背後にある諸理論を勉強しなおせば、実際の具体例をたくさん知っているのだから、理解しやすくなるだろう。
抽象的な理論ばかり勉強しても、その理論を武器に実際に使えなければ無意味だから。

今の時代は、数学や物理の理論からトップダウン的に勉強するのではなく、まずはプログラムを書いて動かして、たくさんの具体例を経験した後で理論を勉強し直す、と言うボトムアップ的な勉強方法の方が向いている気がする。
そんな流れがあるから、日本の小学生もプログラミングに慣れましょう、という方向に傾いているのかもしれない。

経済数学の直観的方法の感想

『経済数学の直観的方法』のマクロ経済学編、確率統計編がとても素晴らしくて、すごくはまった。
下記の感想記事もとてもすばらしい。
以下、ロジカルでないラフなメモ書き。
あやふやな理解で間違っているかもしれないが、その場合は後で直す。

【参考】
『経済数学の直観的方法』　長沼伸一郎著 - ケスケラの読書と旅の日記

『経済数学の直観的方法　確率・統計編』（その1）　長沼伸一郎著 - ケスケラの読書と旅の日記

『経済数学の直観的方法　確率・統計編』（その２）　長沼伸一郎著 - ケスケラの読書と旅の日記

【1】『経済数学の直観的方法』を読むと、現代経済学が、現代数学や現代物理学並みに難解になっている事実が良く分かる。
ミクロ経済学では、消費者の消費行動、企業の購買活動を最小化する・最大化するという文言が多いけれど、それを精緻に理論化するには、解析力学が必要なわけだ。

物理学では、解析力学で使う変数XとXドットは、位置と速度、速度と加速度のように事前に決まる場合が多い。
一方、経済学では、解析力学の前提となる変数がうまく当てはまる場合は少ない。

昔に見つけられたモデルは、消費と消費の変化率から最適成長経路を導出するラムゼイ・モデル。
それ以外の経済モデルはなかなか見当たらなかった。

しかし、著者によれば、ルーカスの合理的期待形成仮説によって、経済事象とその事象を変化させる要素の二つのペアを解析力学の変数とみなすことで、動学的均衡理論が生まれた、というストーリー。
そして、リアルオプションという経済理論が作られて、ノーベル経済学賞を取った。

たとえば、マクロ経済学では、失業率とインフレ率は負の相関であるというフィリップス曲線の理論が出てくるけれど、その理論がそもそも成り立たない場合が現状でよく見られる。

その理由は、インフレを皆がすでに織り込み済みで行動するから、期待通りの経済政策の効果が出ない、というストーリーみたい。
そこで、インフレ率とインフレ変化率の二つを解析力学の変数とみなすことで、経済政策の効果を最大化するようにシミュレーションできるというストーリーなのだろう。

だから、最近の日銀は、国民が織り込み済みの行動を取らないように、故意にサプライズと称した経済政策を次々に打ち出すわけだ。
よって、中央銀行のインフレターゲット政策では、動学的均衡理論が必須のスキルであるということなのだろう。

【1-1】ここで、動学的均衡理論が現代経済学の寵児となった理由は、この理論によって、論文が大量生産されるようになったからだ、と著者は言う。

つまり、ルーカスの合理的期待形成仮説によれば、経済法則は経済事象のパラメータだけでなく、その事象を変化させる要素も考慮しなければならない。
そこで、経済事象のパラメータとそのパラメータを変化させる要素（つまりパラメータの微分）の二つのペアを解析力学の変数とみなすことで、数多くの経済現象の理論をモデル化できるわけだ。
その最たる例が、インフレ期待理論であり、中央銀行がデフレ対策としてその理論を駆使しているわけだ。

但し、著者は、このような優れた理論の価値は認めているが、これによって論文が大量生産される事象については皮肉っぽく言っているように聞こえる。
理論を生み出した超一流の天才と、その理論を拝借して論文を大量生産する一般の学者の違いはそこなんだよ、と。

【2】そんな流れを読むと、文系だから経済学部に行く、という考えは浅はかであり、理論物理学のスキルをマスターしておかないと、そういう最新の経済学に追いつけなくなっているわけだ。
経済学の知識は公務員になるなら必須知識みたいだが、最新の経済学を研究するには、さらに理論物理学のスキルまで必要となると、正直大変なのだろう、と推測する。

物理学のラグランジュアンやハミルトニアンもイメージしにくいが、その概念を経済学で置き換えた場合、どのように考えることができるか？

物理では、ラグランジュアンは最小作用の原理を実現するための概念、ハミルトニアンはエネルギーやポテンシャルみたいな保存則を満たすような概念イメージ。
経済学では、ラグランジュアンは経済政策の成果の最大化やコストの最小化に用いる概念、ハミルトニアンは総資産かGDPみたいなイメージかな。

そう思うと、現代経済学は、既に知られている数学や物理学の理論を片っ端から適用しまくって、その中から上手くいった結果だけを見せているだけなので、そんな背景を知らない理系・文系の人にとっては、本当にチンプンカンプンなのだろうと思う。

以上は自分のもやもやしたアイデアを書いただけなので、もう少し精緻化していく。

最尤推定法とベイズ推定法の違いの記事のリンク

「従来の推定法とベイズ推定法の違い」の記事がとても分かりやすいのでリンクしておく。
以下はラフなメモ書き。

【参考】
従来の推定法とベイズ推定法の違い | Sunny side up!

心理学者のためのベイズ統計入門

ベイズ統計が最近流行っているらしい。
高校時代に、条件付き確率の計算として習ったが、それ以上の知識もなく、今までイマイチどこがすごいのかわかりにくかった。
また、従来の統計的推定では、故意に、主張したい仮説の逆の主張を前提にして、それを統計的処理で棄却する、というやり方を取るが、慣れないとこのロジックそのものが分かりにくい。
「統計的推定は、確率的背理法である」という言葉をどこかで拾って、ああなるほど、とようやく理解した覚えがある。

上記の記事は直観的で分かりやすい。

従来の最尤推定法では、真値が一つであると仮定して、サンプルを増やしたり回数を増やせば、その誤差は小さくなり平均値である真値に近づくはずだ、という考え方。
一方、ベイズ推定では、真値を確率分布としてとらえて、サンプルを増やしたり回数を増やすごとに、真値の分布を最新化していく、という考え方。

(引用開始)
信頼区間(confidence interval)と信用区間(credible interval)の違いは、ベイズ主義と頻度主義の考え方の違いを顕著に示しているといえます。

頻度主義では真値は一つと考えるので、「信頼区間の中に95%の確率で真値がある」という言い方は間違いになります。確率的に変動するのはデータのほうなので、「何度も同じサンプルサイズのデータを取ると、真値が95%の確率で信頼区間内に入る」という意味になります。

一方、信用区間はベイズ主義に基づくもので、仮に真の値を考えると「95%の確率でその範囲に真値がある」という解釈になります。
(引用終了)

ベイズ統計が使いやすい分野はたとえば、計量経済学があるだろうと思う。
何らかの経済政策の効果を測定する時に、最小のコストで最大のメリットを得るには、どんな方法でどれだけ予算を投入すべきか、という発想に使いたいから。
つまり、ある前提条件を仮で置いて、その投資対効果を求める時に使うのだろうと推測する。

たとえば、子供向け政策、高齢者向け政策、公共事業の政策の投資対効果の測定・評価など。
今流行りのベーシックインカム、少子高齢化の政策も同様だろう。
東京五輪のように、昨今は経済政策では投資対効果やコスト削減がうるさいので、こういう手法が必要とされるのかな、と思ったりする。

上記の記事では、従来の心理学の実験には統計的推定が使われていたが、ベイズ推定を使うのも可能性があるよ、と話されている。
確かに、ある前提条件を仮で置いて、ベイズ推定でどんどん仮説の精度を高めていく方法は、経済学でなくても心理学でも有効だろうと思う。

この辺りの考え方も整理していく。