『素数入門』を読んだ

Project Euler をやっているうちに、数論を勉強してみたくなって、この本を買ってみた。

『素数入門』

同じ著者による続編、『数論入門』での著者自身による前書きによると、「初等・初等整数論」って位置づけらしいけど、初等整数論の初級入門者な自分にはちょうど良い。

Project Euler でも見かける関数（オイラーのφ関数とか約数関数とか）が出てくるので、Project Eulerをやったことがある人には、けっこう面白いんじゃないだろうか。あと、こちとら一応プログラマなので、すぐにプログラムを書いて確認できる環境とスキルがあるのはラッキー。

全9章の真ん中の第5章で合同式が扱われているけど、ここをちゃんと理解するのがキーだと思った。合同式がちゃんと分からないと、後の章はほぼちんぷんかんぷんになる。つうか、欲を言えばだけど、もうちょい例題と問題を多くしてほしかった（特に合同式の割り算のあたり）。

9章あたりになると、結構むずかしくなる。フェルマーテストやカーマイケル数なんかは、一回読んだだけじゃ理解できなかった。

正直、読み急いでしまって問題を解くのをけっこう省いたが、「計算しながら理解する」のがこの本の趣向の一つでもあるので、やっぱやっといた方が良い（「計算」というか証明問題が多い気がするが）。実際に、計算してみないと、やはり腹落ちしない。そういうものなのだと思う。

『列島強靭化論』を読んだ

ミッションクリティカルなシステムでは、普通は何らかの冗長構成を採って、サーバーが一台落ちたりハードディスクが一個壊れたりしても何ともないようになっている。落ちたら困る度合いに応じてお金を掛けて、一台ですむところを冗長化したりその他の安全のための工夫をしている。まあ、何てことない普通の話だと思う。

プログラマとして藤井聡教授の『列島強靭化論』を読むと、こうした冗長化などの考えを日本の国土に対して適用し、「日本」というシステムの Availability（可用性）を高めようというアイデアが見えてくる。ついこの間、自民党の国土強靭化基本法案が提出されたところなので、元ネタと思われるこれを読んでみた。

システム開発者として意訳すると、曰く、日本というシステムは言うまでもなく日本人にとってもの凄くクリティカルなのだけど、にもかかわらずアーキテクチャとして余りにも脆弱である。ここで、もちろん Single Point of Failure は東京圏なわけだけど、30年以内に直下型地震が 70%以上の確率で起きる事が既に分かっている。

異音を立て始めたハードディスクを何の冗長化もなくミッションクリティカルなシステムに使ってるようなもので、これは恐ろしい。

つうわけで、東京に集まっている経済機能、都市機能を、太平洋ベルトに入らない日本海側や九州、北海道の諸都市にも分散しようという話だけど、システム屋ならすんなり納得できるんじゃないだろうか。クリティカルなシステムに冗長性を与えようって話だから、むしろ言われる前にやっておけと。

しかも藤井教授によると、そのためのインフラ整備の公共事業がデフレ・ギャップ解消／経済成長にも役立つから一石二鳥。それに先立つ東北の復興も加えると一石三鳥という事になる。10年で200兆って事だけど、通読するとそれほど法外なお金じゃない事も分かり易く説かれている。

（藤井教授はデフレ解消をもの凄く重視しているけど、この辺りは学者によって賛否両論あるらしい。自分は藤井教授の考えに一理あると思う。まあ、新聞なんかでは単に「公共事業は悪」ってイメージだけの批判もあったようだけど、そういうのは論外。）

震災直後の1ヶ月で書き上げたとの事で、妙に臨場感があって、読むと当時の気分が蘇ってくる。

終章が面白い。もしも日本人が本書で提示された「強靭化」を日本の国土に対して施さなかった場合、この「不作為の罪」によって、どんな風に日本が終わってしまうかというストーリーが提示というか予言されている。これがもの凄くリアル。

発行から１年以上たった今、デフレ下では絶対ダメと本書で厳禁されていたはずの消費増税も肯定されてしまいそうな勢いだし、TPPも交渉参加だし、これは悪い方の予言が当たって、「30年以内に70%の確率」で日本終了のお知らせって事になっちゃうかもしれん・・・

systems thinking の本

『システム・シンキング入門 (日経文庫)』を読んだ。

====
従来のシステム開発において、何らかの原因（時間が無いとか）でストレスが増えるとテスト実行が減り、テスト実行の減少がさらにストレスを増やし（バグ対応とか）、それが悪循環を引き起こしてどんどん状況が悪化するというのがよくある。

これを図示したものが、Kent BeckのTDD本 から引用した｢The "no time for testing" death spiral｣という図。（図の矢印線は因果関係を表していて、線上に置かれた丸は原因側のプラスが結果側のマイナスとして作用する事を示している。）

この図は、システム･シンキングで言うところの「因果ループ図」で（Beck の本では "influence diagram" と書かれていたが）、マイナス方向に作用する丸印が偶数個ある事から、「拡張フィードバック・ループ」という事になる。このタイプのループは変化が一方向に進んでいくタイプで、調子が良い時は好循環になり右肩上がりで状況がよくなるが、逆に悪いことが起こるとどんどん悪循環にはまるというもの。

このタイプと別に「バランス・フィードバック・ループ」というものもあり、これはマイナスの因果関係が奇数個のもので、系の中のギャップを縮めて安定させる効果があるという。

テスト駆動開発を導入すると、ストレス増加が必ずしもテスト実行の減少を引き起こさないし、逆に積極的にテストを増やすように対処する事で、以下のように Stress → RunTest の因果関係をプラスにしてバランス・フィードバック・ループに転換できるということになる。最初に TDD を読んだときは意識していなかったが、こうやってテスト駆動開発をシステム･シンキングの言葉で捉えなおす事もできて面白い。（まあ実際の開発現場では、ストレス増加の結果としてテストの「実行」は減らないとしても、テスト品質や網羅率が下がったりするから、上の図はちょっと理想化しすぎている感があるが。）

====
因果ループの他に、メンタルモデルというのも紹介されている。本書によれば、個々の出来事の層、出来事のパターンの層、パターン間の構造の層というシステムを構成する3層の更に下に、暗黙のうちに前提とされているメンタルモデルの層があるとされている。これも開発者なら（特にいろんな企業や業界のシステム開発を渡り歩いている）、ピンと来るものがあるんじゃないだろうか。

昔、Yourdon が著作『デスマーチ』で、デスマーチ属性は個々のプロジェクトじゃなくて組織の属性だという事を看破したけど、つまりそういうことなんだと思う。なんとなく組織の人間に共有されているシステム開発のイメージとか価値観だとか、そういった組織内部の人間には自覚しにくいメンタルモデルが、何度もデスマーチを繰り返すベースになっているという事もあるように見える。

====
短めの新書だけど、他にもシステム開発者にとって考えさせされる事があって面白い本。特に開発プロセスやプロジェクトの運営に興味がある開発者にお勧め。

マクロ経済学入門

IT技術者がたずさわるたいていの仕事は、社会制度や慣習の一部をITに置き換えたり、あるいはその隙間にITをはめ込んでいく作業だけど、その社会を動かしている原理は主に「経済」だと常識的に言えるだろう。

だからIT技術者は、社会の仕組みについての知識（我々の業界で言う業務ドメインの知識）はもちろんの事、社会の力学としての経済学についても基礎的な教養として嗜んでいるべきという事になるはず。

というわけで、やや遅い気もするが経済学の勉強を始めた。で、当初の想定では適当な問題集でも解きながら、足りない情報はネットで集めるつもりだったものの、やってみるとネットには意外と良い資料が無い。そこで、入門レベルのものを探しに本屋に行き、日経文庫の中谷 巌著『マクロ経済学入門 (日経文庫)』というのを買って読んでみた。これがかなり良い。

GDPや三面等価の原則について、「何となく分かる気もするけど自信はない」といったレベルから入って、IS-LM曲線、マンデル・フレミング・モデル、AD-AS曲線、フィリップス曲線などについて、かなりスカっと納得した気分になれる。

著者がどういう人なのか良く知らないけど、もともと教えるのが上手いのか、それとも実際に教えてきた経験からツボを熟知しているのか、「だいぶ前のページに出てきたアレ、何だっけ？」といった、ちょっと理解がぼやけて始めた頃に、ちょうど良いタイミングで重要事項が繰り返される。対面して理解度を測りながらレクチャーを進めているような気配りがある。

まあ内容的に入門の入門だから、分かった気になれてしまうってのもあるだろう。それに簡単とは言っても、もう後一回は読んで、さらに問題集も解いて脳に定着させないと、すぐに忘れてしまうだろうし。やっぱ、ちゃんとマイルストーン設定して勉強しないとだめだ。

ちなみに、Amazonで調べてみたら、同著者の入門書で『入門マクロ経済学
』というのもあった。これはもう少し踏み込んだ本格的な「入門書」らしい。あと同じ新書のシリーズのミクロ経済学入門も買ってきて既に読了したが、これもなかなか良かった。また今度書こうと思う。