Pythonで微分積分や統計の基礎を理解しよう

みんなのPython勉強会#81 - connpassに出たら、『Pythonで微分積分の基礎を学ぼう』という講演が良かった。

みんなのPython勉強会#81 - connpass

Pythonで理解する微分積分の基礎：書籍案内｜技術評論社

Pythonで理解する微分積分の基礎 (Python × Math)の著者が話されていたのは、高校数学はPythonで理解してしまいましょう、ということ。
微積分にたどり着くまでに、三角関数、指数関数、対数とか色々出てきて、訳が分からないという学生も多い。
しかし、Pythonならば、関数をグラフで表示できて直感的に理解できるし、計算はプログラムに任せてしまえばいい。
簡単な線形微分方程式も、Pythonなら簡単に解を導いてくれる。

つまり、小難しい理論から理解するのではなく、具体例をPythonで色々プログラムを書いて試して、そこから理解した方が速い。

この話は僕も共感する。
例えば、統計学の理論は十分に揃っているのだから、Webログのようにビジネスの副産物として簡単に採取できるのだから、後はプログラムでいくらでも分析しまくればいい。
最近の心理学や経済学の動向は、コンピューティングパワー抜きではその発展の歴史を追跡できないだろうと思う。

また、こういう人文・社会科学系の理論を使って、組織論や人事制度、経営理論を試す話も最近多くなった。

直近の経済学の雑誌「経済セミナー2022年4・5月号 通巻 725号【特集】「職場」の経済学」をふと読んでみたら、あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の話があって、興味を惹いた。

あるべきリーダーシップやモチベーション向上、あるべき組織や人事制度の問題を実証的問題に変換し、アンケートを使ったランダムテストなどを使ったりして、社会科学上の問題の本質を探ろうとしている。

プログラミングという武器があれば、現場にある眼の前の個人の心理や集団の行動や意思決定にかかわる問題を統計で分析することで、本質的な変数を見出し、因果関係を見出したり、さらには予測することもできるわけだ。

そういう意味では面白い時代になったのだろうと思う。

Rによる計量経済学/計量政治学を読んでいる: プログラマの思索

戦略/組織/人事と組織の経済学シリーズを読んでいる: プログラマの思索

ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ を読んで、テストケースの切り方の練習として良い教材と思った。

【参考】
【書評】「ソフトウェアテスト技法練習帳」を読んで、体系的なテスト技法の知識を身につけよう - give IT a try

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～：書籍案内｜技術評論社

ソフトウェアテスト技法練習帳 / 梅津 正洋/竹内 亜未/伊藤 由貴/浦山 さつき/佐々木 千絵美/高橋 理/武田 春恵/根本 紀之/藤沢 耕助/真鍋 俊之/山岡 悠/吉田 直史【著】 - 紀伊國屋書店ウェブストア｜オンライン書店｜本、雑誌の通販、電子書籍ストア

(引用開始)
目次
１　同値分割法と境界値分析（温度によって表示を変えるペット用室温計；キッチンスケールの動作検証　ほか）
２　デシジョンテーブル（１杯目のビールの価格；銀行ＡＴＭの引き出し手数料　ほか）
３　状態遷移テスト（ストップウォッチの動作；スマホ決済アプリの決済処理　ほか）
４　組合せテスト（美味しい組合せ；ＢＵＧ　ＱＵＥＳＴ★冒険のはじまりの旅支度　ほか）
５　総合問題（スマートフォンの料金プランと料金計算；ＢＵＧ　ＱＵＥＳＴ★隠しアイテム探し　ほか）
(引用終了)

ソフトウェア開発でテストの重要性は誰もが知っている。
しかし、実際にテストケースの切り方をきちんと学んだ経験を持つ人は少ないのではないだろうか。
実際、テスト技法の本はプログラミング関係の本に比べて圧倒的に少ないし、現場でも、デシジョンテーブル、状態遷移テストなどをきちんと駆使して、漏れなくテストしている場面が少ない気がするからだ。

その真因は、テストケースを作るのが非常に面倒だからと思う。
業務フローやデータパターン、確認項目の個数が増えれば、その組み合わせを考えると爆発的に増えてしまう。
その時に、同値分割で代表となるパラメータの組み合わせでテストケースを作るわけだが、手動で作成するのが鬱陶しい。
組み合わせには禁則処理もあるから、パスを通過しないパターンを削除したり、含められるパターンをまとめたりするのが手動であり、自動化しにくいからだ。

テストケースをユニットテストのプログラムで実装すれば、後は自動でビルドしてテストできるが、肝心のテストケースをすべて漏れなく洗い出すのが面倒なのだ。

また、真因の一つには、テストケースの作成技法であるデシジョンテーブル、状態遷移テストには割と細かいテクニックが隠れている点もあると思う。

ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ の良い点は、テストケースの練習帳なので、実際に頭で汗をかいて、書き下してみることができるからだ。
僕も実際にテストケースを書いてみたけれど、解答を読んで、そんな仕様を読み落としたのか、とか、そういう考え方もあるな、とか色々気づきがあった。
テストケースを我流で作っていると、割とこういう基礎的な部分を忘れている気がする。

中国人の価値観の考え方

5月連休で読んだ本のうち、中国人の価値観に関する本が良かったのでメモ。
ラフなメモ。

中国では、外界と隔離された超監視社会という「異形の未来社会」が気づかぬうちに進行している[橘玲の日々刻々] | 橘玲×ZAi ONLINE海外投資の歩き方 | ザイオンライン

日本人と中国人は、顔や体型も似ているし、漢字という似た言葉を使っているのに、お互いの価値観は全く違う。
欧米人から見れば、同じ黄色人種だし、同じ漢字を使っているのに、なぜあんなに相互理解できないのか、と思われるだろう。
日本人でさえ中国人の言動や行動が理解できているとはいえない。

上記の本を読んで理解したことは、中国人と日本人の価値観の違いは、中国人の置かれている環境は日本人とは異なるからだ、という一点に尽きると思う。
環境の違いとは、結局、人口が多すぎることだ。

政府や公共機関の管理できる範囲以上に、大人口の集落が多すぎるために、政府が下々の国民を個人レベルまで管理できないから、法治主義が浸透せず、人々の自治に任せている。
したがって、私的自治の原則により、人々は血縁関係を元に政治的秩序を作り出し、人治主義になっている。

また、中国はその国土の広さに比べて人口が多すぎるために、競争が激しくなり、対人関係に人一倍気を使う必要がある。
すると、中国では、朋友関係という人間関係を元に親密な人間関係だけの人間集団を作り出し、その人間集団の中で生きるという仕組みを古来からずっと続けている。
その仕組みは、一昔前の日本のヤクザのような関係に近い、と言ってはいけない中国の真実(新潮文庫)では言う。
実際、一昔前の中国で人気のあった日本人男優は高倉健だったという理由は、そういう雰囲気の中で最も親しく感じる面があったから、と言う。

中国人の人口が多すぎるという環境がいかに我々の想像から外れている点については、たとえば、言ってはいけない中国の真実(新潮文庫)、世界史とつなげて学ぶ 中国全史、近代中国史 (ちくま新書)では、中国と日本における集落と人口の関係図がすべての本で図表で表示されている。
下記に画像がある。

江戸川の畔（ほとり）:「近代中国史」岡本隆司著 - livedoor Blog（ブログ）

中国と日本における集落と人口の関係図では、日本では、政府＞都道府県＞市町村＞聚落まで、鋭角三角形になっているので、政府が個人レベルまで管理統制できる範囲内にある。
実際、江戸時代の幕藩体制は集約封建制と言われていたが、封建制度を元にしながら、土地と農民を個人レベルまで管理統制できていた。
その分、権力が個人レベルまで統制しているわけで、日本人は集団主義だ、日本人は組織に従順だ、という事実が、その歴史が現代日本まで続いている。

一方、中国では、政府＞省までの三角形と、都市＞聚落の台形では構造がいびつに分かれている。
この台形構造が意味することは、中国政府が個人レベルまで管理統制できていない事実を示している。
あまりにも人口が多すぎて、大都市が多すぎるがゆえに、組織の4原則で言われる「管理の統制範囲」「スパン・オブ・コントロール」が取れていないことを示しているのだろう。

すると、政府や公共機関が本来やるべき法治制度が国民全てに行き渡らず、住民同士に任せているために、私的集団が法治制度から外れて、権力の強い者に弱い人達が従ったり、そうならないように人々が集団で団結して集団の自治制度を設けるという方向にゆくのだろう。

結局、日本と中国の環境要因の差がお互いの気質や価値観の違いを生み出し、現在に至るまでお互いに根本から理解し合えない原因を生み出しているのだろう。

中国の国土を見ると、黄河や揚子江のような大河が東西に流れて、温暖な気候に恵まれて、大量の人口を養える肥沃な土地であるために、逆に人口が多すぎて競争が激しく、政府が管理統制できない社会的環境がつい現在まで続いていたのだろう、と思う。

こういう観点から中国史を改めて読み直すと、歴史上の史実は実は単純に理解できるのかもしれない。

小説活動にプルリクエスト駆動が必要になってきた

小説活動にプルリクエスト駆動が必要になってきた記事を見つけたのでメモ。

【参考】
Pull Request駆動で小説を開発する

GitHub上に構築した小説執筆環境について

akipiiさんはTwitterを使っています: 「コミット履歴を整理するためにプルリクエストを使う発想。面白い。Pull Request駆動で小説を開発する https://t.co/EJ5fHkyr1O」 / Twitter

【1】まず、なぜ、小説家にGitHubが必要なのか。
理由は以前書いた。

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること

【2】次に、なぜ、小説家にプルリクエスト駆動が必要なのか。

小説家がGitHubのプルリクエストを使うメリットは2つある。
1つ目は、GitHubのコミット履歴が意味ある情報のみに集約できること。
2つ目は、ブランチが小説の各シーンのToDo管理に適用できること。

【2-1】1つ目は、小説というテキストをどんどんコミットしていくと、途中のToDoや作業中の成果物も全てmasterに反映されてしまう。
すると、小説が完成版に至るまでの作業履歴に、途中の作業履歴や思いついたアイデアの破棄などの雑多な情報が不純物として混じってしまって、最終成果物の品質を維持しにくくなる問題点がある。

本来は、1日では完成しきれなかった原稿、思いついたアイデアを試したがやっぱり捨てた原稿は、本流のmasterから分離して一時的に退避しておきたい。
つまり、未完成の原稿、思いついたアイデアの原稿は、トピックブランチで管理すべきなのだ。

そうすれば、本流のmasterには完成されたシーンの原稿だけが取り込まれることになるので、常に最新版の原稿の品質を維持することができる。
コミット履歴という情報を整理したい、という意見は、こういう意図があるのだろう。

【2-2】2つ目は、トピックブランチで、作業中の原稿や思いついたアイデアの実験を管理したいことにつながる。
トピックブランチは、作業中の原稿であり、実験で途中経過の原稿である。
つまり、トピックブランチは、小説のワンシーンに当たる各シーンのタスク管理を行っているわけだ。

トピックブランチのコミット履歴に作業中の状況を記載すれば、チケット管理ツールのチケットの作業履歴に相当する運用になっている。
GitHubならば、トピックブランチを派生する時にIssueを発行できるから、Issueで作業のステータスや重要度、作業履歴をリポジトリとは別に管理できる利点がある。

プルリクエストを行うことの意義は、トピックブランチで作業途中の成果物を管理すること以外に、チケット管理で作業状況のステータスや重要度を管理することもあるわけだ。

【3】Pull Request駆動で小説を開発する記事に知的刺激を受けた理由は、過去の偉大な哲学者や思想家は、GitHubのような優れた開発環境を知らなかったが故に、本来の創作活動の潜在力に一定の限界があったのだろうな、と思ったからだ。

akipiiさんはTwitterを使っています: 「@MadoWindahead 過去の偉大な哲学者ですら、プログラミングを知らなかった、というフレーズが強烈でした」 / Twitter

加速！#DevSumi #devsumiB pic.twitter.com/d8nFXH4bjc

— 門屋浩文＠redmineエバンジェリストの会主宰 (@MadoWindahead) February 15, 2019

門屋浩文＠redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii エンジニアの知的生産という本を書いた人のセッションでした」 / Twitter

門屋浩文＠redmineエバンジェリストの会主宰さんはTwitterを使っています: 「@akipii まだ、なさそう https://t.co/PO5I82pmft 参照してください」 / Twitter

デブサミ2019【15-B-1】エンジニアの知的生産術 ビフォー・アフター #devsumiB - Togetter

過去の偉大な哲学者や思想家に比べて、現代の知的生産者は、ワープロやPCという単純にオンラインで物書きできるツールがあるメリットだけでなく、GitHubのような優れた構成管理ツールを使いこなすことで、ちょっとしたアイデアの実験をトピックブランチで自由に試して、その中で高品質で完成したものだけをプルリクエストでマージして、高品質な成果物を生み出す仕組みを習得できる。
つまり、知的生産活動の難易度はたった50年前の人達よりも、はるかに楽になってきている。

GitHubが生まれるつい20年前までは、Wordで原稿を書けたとしても、途中の原稿はコピー新規で履歴管理したり、複雑なフォルダ管理でやるしかなく、相当面倒だった。
しかし、今の時代はそんなアホな成果物の管理をする必要もない。

そして、今後の成果物はGitHubで管理しやすいように、できるだけテキストで書いていくべきだ。
そうすれば、GitHubで成果物の履歴管理ができるだけでなく、思いついたアイデアの実験をトピックブランチで別で管理して、その作業状況も一括管理できるメリットがある。

そういう仕組みを上手く使いこなした方が絶対に良いに決まっている。

超高速開発でアジャイル開発を実現する話に違和感がある

超高速開発をやってます、これでアジャイル開発を実現しています、という話を聞いて違和感があった。
その違和感が何なのか、考えてみた。

違和感を感じた理由は3つある。
1つ目は、超高速開発ツールを使って短納期で少ない工数で開発できることをアピールしているのは違うでしょ、と思うから。
話を聞いてみると、要件定義さえ固めれば、後は設計を開発基盤に落とし込んで、超高速開発ツールという開発基盤を使えば、即座に動くアプリが作れる。
だから、顧客の現場でSEが常駐して、要件をヒヤリングして固めて、作った機能のユーザテストを定期的に行っています、と言っている。
大きな目で見ればアジャイル開発と言えるのかもしれないが、現場でユーザにヒヤリングしながら要件定義を固めること、そして、超高速開発ツールで短納期に開発するのがアジャイル開発と言えるのか、正直疑問に思った。

2つ目は、最近のアジャイル開発の風潮では、アジャイルコーチがきちんと指導したチームでアジャイル開発を回しているのでなければ、アジャイル開発とは言いにくい状況があることだ。
一般に、認定スクラムマスター、認定プロダクトオーナーなどの資格を持ち、スクラムの知識を熟知した技術者がチームを形成しているか、そういう資格を持ったアジャイルコーチが開発チームを指導しているか、を見なければ、アジャイル開発を実践しているか判断できないと思う。

他方、そういう認定資格を持っていない技術者やチームでアジャイル開発をやっています、と普通のソフトウェア企業が公開していたら、見知らぬ技術者は、この会社はアジャイル開発をやっているんだ、と勘違いして入社して、そのギャップに幻滅するのではないか。

昨今の風潮では、アジャイル開発と言えばスクラム一色なので、スクラムの認定資格を持っていない人がアジャイル開発をやっていると言う時、特に公的な場で表現するのは信憑性があるのかな、と疑問に思ってしまう時がある。
他方、スクラムはアジャイルコーチという職業を生み出し、認定資格によって、運用する人たちの資質や品質を担保する仕組みを整備したのはビジネス的に上手いな、と思う。

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

3つ目は、超高速開発ツールを使っていると言いながら、データモデリングの技法を重視していない状況だったからだ。
単純に画面と帳票を設計して、それを超高速開発ツールの基盤に載せて、アプリを作っているだけだった。

一般に、超高速開発を標榜する人たちはデータモデリングの技術を背景にして、超高速開発ツールを自分たちで作り込んでいる。
彼らは、業務プロセスをデータモデルやDFDできちんと設計しているから、RDBさえ固めれば、後は画面と帳票のパターンを組み合わせて作るだけ、という方針でやっている。
しかし、超高速開発でアジャイル開発をやっています、という人たちの話を聞くと、確かに業務フローは書くけれど、データモデルが十分に考えられているとは見えなかった。
後で手直しできるから、と割と安易に作っているようにも見えた。

ちょっとそんな現場を見る機会があったので、超高速開発でアジャイル開発を実現しています、という話には気を付けた方がいいな、と思った。