経済学・ERP・財務会計

2022/10/02

計量政治学と計量経済学の考え方の違い

経済セミナー2022年10・11月号 通巻728号【特集】いま、政治の問題を考えるを読んでいたら、計量政治学と計量経済学の考え方の違いの記事が面白かった。
以下はラフなメモ書き。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

Pythonで微分積分や統計の基礎を理解しよう: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある: プログラマの思索

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

【1】計量政治学と計量経済学の考え方の違い

政治学の方が特定地域のこだわりがある。
たとえば、NPO法人や政治家にインタビューするために、現地言語を習得したり、その国の文化に慣れる必要がある。
経済学はそこまでこだわらない。

一方、政治学は理論と計量をそこまで区別しない。
政治学は定性データを重視するし、時事問題を重視する。
たとえば、リーマン危機、ウクライナ戦争など。
しかし、経済学では、理論と計量を区別し、過去に蓄積してきた理論を使って、計量データを用いて、政策の効果を測定したりする。
だから、経済学では、理論の人は計量の論文を読め、計量の人は理論の論文を読め、と言われるらしい。

【2】計量政治学から得られた経験則

独裁者は暴力行使の利益とコストを勘案して多様な手法で大衆を制御しようとする。
ここに独裁者のジレンマがある。
権威主義的な国の選挙は実行がすごく難しい
選挙の不正がなければ、野党や反体制の人達がのさばり、自分たちの権力を脅かそうとする。
一方、選挙で不正を実施しすぎると、本当の支持率が分からないし、どこの地域が支持率が高く、どこの地域に反体制の人達が実は多いのか、分からない。
つまり、自発的な支持が得られないので、実は権力基盤が脆い事実を国民の皆が知っている。
だから、権威主義国の独裁者は実は裸の王様。
だから、独裁者は、自分の支持率はじつは高いのだ、というシグナルを国民に知らせる必要があり、あの手この手を使っている。

また、農業主体の国は人々が散在しており、組織化しにくい。
つまり、一体化して反抗しにくい傾向があるらしい。
すなわち、都市化した国の方が、民衆が組織化しやすく、一致団結しやすいので、民主化しやすい傾向があるらしい。

この話を読んで、フランス革命は実はパリ革命だった、という話を思い出した。
なぜなら、フランスは中央集権の王権国家であり、パリに人民も富も集中していたので、パリで体制変革されると全土にその余波が行き渡っていたから。

【3】民主化はいつどのように起きるのか?

色んな国の統計データを調査すると、与党と野党の間に、権力基盤の合意がある前提があるらしい。
つまり、信憑性のあるコミットメントが存在している。
だから、クーデターや内戦のような暴力行為による政権交代は必要なくなる。
たとえば、韓国や台湾、南アフリカなどがその事例に相当するだろう。

【4】計量政治学に機械学習や深層学習を用いて得られたノウハウ

権威主義国では統計データを不正に操作しているので信頼性が低い。
だが、夜間の光量データから経済活動の活発さを見る、という手法を取ることもできる。
その場合、衛星からの画像データをCNNに食わせて、計測アルゴリズムを作り出す、というやり方も取れる。

すると試行錯誤による発見的予測アルゴリズムの成果はどうだったのか?
4つある。

1つ目は、本来のアルゴリズムは藪の中。
真の因果関係を表すアルゴリズムは不明だった。
特に、深層学習の場合は、予測できたとしても説明可能性は低い。
正しいモデルアルゴリズムにこだわるのは不毛なことがある。

2つ目は万能なアルゴリズムは存在しないこと。

3つ目は、次元の恵みを活用せよ。
説明変数の次元が増えるほど、必要なデータ量は指数関数的に増えて計算できなくなる。
つまり、次元の呪いが発生する。

そこで、次元の呪いを解決するために、予測に必要な説明変数を絞り込む変数選択、過学習を防ぐ正則化などを用いる。
しかし、予測に使える変数は全て投入して、次元の恵みを最大限活用する方法もあるのでは、と。

4つ目は、予測可能性と説明可能性のジレンマがある。
深層学習は、予測性は高いが理屈は複雑で説明しにくい。
一方、線形回帰や決定木は、予測は微妙だが説明しやすく、因果関係を明確にしやすい。
そういうトレードオフがある。
つまり、政策介入の因果関係としての効果を測定することと、機械学習による予測は完全に調和しないのだ。

僕はこのトレードオフは、実際の政策を実行する上で、ハードルが高くなるリスクがあると思う。
たとえば、財政出動や補助金をばらまく政策を実行する時に、これだけの効果を予測できます、とアナウンスすることで、国民や利害関係者を納得させたいが、その効果の因果関係を説明できなければ、本当に効果があるのかと疑問に思う人も増えて、その制作に反対する人が増えてしまい、せっかく期待していた効果が実行しても得られないリスクが出てくるからだ。

経済学のルーカス批判のように、政治学でも自己予言的なリスクがあるのかもしれない。

| | コメント (0)

2022/06/04

経済学や心理学の実験で得られた理論は再現性があるのか?~内的妥当性と外的妥当性の問題点がある

経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読んで、経済学や心理学の実験で得られた理論は再現性があるのか?という特集号が面白かった。
再現性の根本問題は、内的妥当性と外的妥当性の問題点があると思う。

経済学が理解できるようになってから、図書館から経済セミナーを借りて読む時が増えたけど、政治や経済、社会のニュースと直結しているので面白い。

ラフなメモ書き。

【1】Twitterのごく一部で話題になっていた「再現性問題」が経済セミナーの最新号に掲載されていたので斜め読みした。
「再現性問題」とは、心理学や行動経済学ですでに知られていた実験結果や通説が実は再現性がほとんどないぞ、という指摘。
プロスペクト理論の損失回避性、ナッジ政策も実は再現性がないと言う。
ナッジ政策が再現されないとなると、ナッジ政策を推進する政府の公共政策には意味がない、税金の無駄遣いということだから影響は大きい。

【2】再現性の根本問題には、内的妥当性と外的妥当性の2つの観点がある。

僕の理解では、内的妥当性とは、母集団の中のサンプルをランダムに採取したときに、どのサンプルも同じ傾向の統計データが取れて、同じ結論が出ること。
自然科学の実験であれば、これは当たり前。
しかし、心理学や経済学では、母集団の中のサンプルでは、個人の属性のばらつきが大きいので、同質な属性を持つ集団を抽出する方法が難しい。
心理学ならば個人にバイアスがかかってしまって、そもそも客観的なテストができているか疑問がある。
何度も同じようなテストをすれば、個人も学習してしまって、過去と違う結果を返すかもしれない。

一方、外的妥当性とは、ある母集団で得られた統計データの傾向や結果が、他の母集団にも適用して、同じような統計データや結果が得られること。
自然科学の実験であれば、米国であろうが日本であろうが場所に関係しないし、現代でも100年前でも同じ結果が出る。
しかし、心理学や経済学では、欧米と日本では文化や価値観が異なる部分は多いし、100年前の人間集団と現代の人間集団では価値観も行動も全く異なるから、同じ統計データが得られるとは限らない。

つまり、内的妥当性は同じ母集団の中で採取したサンプルが同質であるか、外的妥当性は異なる母集団にも同質性を適用できるか、という問題点だと思う。

【3】「内的妥当性の再現性問題」の問題点は、仮説統計検定のp値に関する論点だろう。
p値が5%の基準で、仮説を棄却したり、棄却できないと判断する場合、4.9%と5.1%ではどんな違いがあるのか?
5%前後の僅かな差が、統計的有意であるかどうか決めるのであれば、その基準はそもそも妥当なのか?
pハッキングという話につながるらしい。

この仮説統計検定が使えなくなると、心理学の実験がすごくやりにくくなるだろう。
心理学で主張した意見の根拠をどこに求めればよいのか、大きな論点になるだろう。

【4】「外的妥当性の再現性問題」の問題点は、たとえば、欧米では大量データで実験して正しいと得られた通説が、日本では通用しないのでは、という点だろう。

経済学であれ他の学問でも、欧米で得られた統計データがすごく多い。
そこで得られた知見は、欧米人という母集団で得られた統計データに過ぎず、日本人という母集団に適用して、その真理が通用するのか?
この外的妥当性が通用しないとなると、経済学の理論は使い物にならなくなる。
経済学は規範的学問であるから、こういうエビデンスがあるから時の政府はこういう経済政策を打ち出すべきだ、という指針を提供できなければ、学問としての意義がないだろう。

経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読むと、他の母集団に適用すると再現できなかったら、再現できない原因を探る方がより生産的な議論になる、という話があって、なるほどという気付きがあった。
再現できない差異要因が見つかれば、その要因をさらに分析することで、経済学の理論を補強することもできるだろう。

【5】内的妥当性、外的妥当性の話は、「データ分析の力 因果関係に迫る思考法」にも紹介されていたが理解できていなかった。
経済セミナー2022年6・7月号 通巻726号【特集】経済学と再現性問題 | 日本評論社 を読んで、やっと言わんとすることが理解できた気がする。

データ分析の課題はどこにあるのか: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

【6】こういう話を読むと、人文・社会科学の真理を追求するために、客観的な妥当性を説明できる理論的根拠をいかに作り出すか、が論点なのだろうと思う。
自然科学と違って、心理学や経済学などの人間や社会に関する学問は、学問として成り立つ正当性を説明しようと努力して四苦八苦しているんだな、といつも思う。

そして、過去の優れた哲学者は、その正当性に関する議論を自分たちの脳内だけで色々試行錯誤してきたが、現代ではITやプログラミングという技術があり、それを使えば相当の内容を深く議論できるようになった点が大きく異なる。
過去の優れた哲学者の活動そのものを我々は検証できる道具を持っている点がすごく重要だと思う。

以前も、そんなことを考えていた。

計量経済学における統計上の根本問題: プログラマの思索

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

経済セミナーが面白いと思う理由は、最新のIT技術を使うことで色んな実験ができることだろう。
ITと統計学が融合している学際的な場所になっている。
プログラミングさえできれば、統計学の理論、経済学の理論は、実際に動かしながら後から理解すればいいと思う。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

| | コメント (0)

2022/05/15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/05/06

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

2022/04/26

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知=知識、暗黙知=身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか?
経験は知識よりも勝るのか?

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ!」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

| | コメント (0)

2022/04/24

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった

オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かったのでメモ。
ラフなメモ。

【参考】
オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - AFFORDD

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - 経験論文

オープンソースERPパッケージに対する派生開発手法の提案~開発プロジェクトの事例をもとに~ - スライド資料

オープンソースERPパッケージiDempiereはいつか、仕組みを習得して、ERPはこういうものですよと自分なりに理解したいと思っていた。
ネット上の情報から、普通にインストールできる。
PostgresSQLのDBの中身を見ると、テーブル数は1千個を越えるので、OSSのわりに作り込んでいるERPだと思う。

こういうOSSのERPを自社開発、受託開発したい場合、必ずカスタマイズが入る。
その時に、どんな方針でカスタマイズすべきか、という問題が出てくる。
無造作にカスタマイズしていくと、開発基盤のバージョンアップに追随できなくなるし、今後の運用保守もやりにくくなるからだ。

そこで、ERPのカスタマイズに派生開発手法であるXDDPを用いて解決してみよう、という流れは自然に理解できる。
基本方針は、カスタマイズする場合、標準機能をラッピングまたは継承する形で、独自ロジックを実装する。

上記の資料で興味深いと思った点は、OSSのERPのカスタマイズで発生する問題として、標準機能の知識習得が難しいこと、派生開発により基盤である標準の品質を損ねること、という2点があげられたことだ。
そして、その解決方法として、教育環境の整備、開発規約の整備、開発体制の強化があげられていた。

意外だなと僕が思った理由は、派生開発のプロセスやiDempiereの開発基盤のアーキテクチャに焦点が当たると思っていたからだ。
しかし、よく考えれば、プロセスや技術面よりも、技術の習得や教育の方が長期的な問題なのだ、と理解すればいいのだろう。

得られた情報や検索した情報は、社内のRedmineで一元管理して共有している点も面白い。
Redmineを組織のナレッジ資産として使っているわけだ。

今後の課題として、XDDPのトレーサビリティマトリクスを利用して技術上の課題を解決していく点があげられていた。
iDempiereはOSSとはいえERPなので、相当な機能数があるから、すべてを理解するのが難しいのだろう。
そのために、XDDPのトレーサビリティマトリクスを利用したいのだろうと思う。

| | コメント (0)

2022/04/23

Rによる計量経済学/計量政治学を読んでいる

「Rによる計量経済学/計量政治学」という書籍があったので読んでいる。
Rによる計量経済学 第2版」「Rによる計量経済分析」「Rによる計量政治学」「Stataによる計量政治学」の本だ。
門外漢なのでラフなメモ。

【1】計量経済学という学問の存在は「統計学が最強の学問である」で知ったが、計量「政治」学という学問があるとは知らなかった。
でも考えてみれば、ITと統計学を駆使して、あらゆる人文科学を自然科学の基盤の上に打ち立てようとする方向性は納得できるし、そういう事が可能になった時代なので、ちょっと才能がある人が一攫千金を求めて大量流入しているのだろうと思う。

「計量経済学」「計量政治学」という学問で最も興味があるのは、これらの学問の根本問題は何なのか、これらの学問の前提となる武器について制約条件はあるのか、という点だ。


【2】「Rによる計量経済学 第2版」を読んで、計量経済学では、最小二乗法が自然科学のようにそのまま扱えない問題があり、その問題を解決するために色んな統計理論を編み出して、経済学を分析するツールを整備している、という印象を持っている。
その内容は以前書いた。

計量経済学における統計上の根本問題: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

結局、母集団が正規分布になっているという直感を元に普通の理論は打ち立てるわけだが、現実はそうとは限らないので、色々苦労している、ということなのだろう。

様々な確率分布は正規分布のバリエーションに過ぎない: プログラマの思索

【3】「Rによる計量政治学」「Stataによる計量政治学」では、政治学を自然科学のような実証科学の基盤として打ち立てるために、計量政治学の正当性を書籍の冒頭に述べている。
この部分が非常に素晴らしいと思った。

政治学を含む社会科学では3つの問題がある。

【3-1】1つ目は実証的問題。
つまり、定量データを収集し「事実から真実を語らせる」。
「経済の発展は民主化を促進するか」「国民は民主党を指示しているか」など。
実証的問題では、価値判断を行わず、事実に語らせる。
だから「良いと思う」「悪いと思う」「すべきである」という感想を付け加えるときもあるが、そういう結果は出せない。

【3-2】2つ目は規範的問題。
いわゆる「べき論」。
研究者の価値判断に依存しており、規範哲学や政策議論で一般的に見られる。
「死刑は廃止すべきか」「民主主義は裁量の政治形態か」「中絶は認められるべきか」など。
価値判断というバイアスが入るために、客観性に疑問が残る。
しかし、規範的問題を実証的問題に変換することで、間接的に科学的証拠で根拠を示すことは可能らしい。

規範的問題を実証的問題に変換する仕組みはこんな感じだ。
1つは参照枠組み(frame of reference)を変える。
「今の日本は美しい国か?」という問題は規範的問題だが、「日本国民は、今の日本を美しい国と考えているか」という問題に置き換えれば、実証的問題として検証できる。
実際、世論調査を行えばいいだけの話だ。
つまり、問題のフレームを実証的問題に変換してしまえばいい。

もう1つは、規範的問題の背後にある前提条件に注目すること。
例えば「消費税を減らすべきだ」という規範的問題に対し、その背景にはいくつかの前提条件が隠れている。
つまり、「消費税を減らせば、経済を刺激して消費が伸びる」「消費が伸びれば雇用が増えて好景気になる」「好景気になれば税収が増える」という因果関係が隠れている。
これらの実証的問題に変換して、個人の価値判断なしにその真偽を検証すればいい。
つまり、「消費税を減らせば、経済を刺激して消費が伸びるのか?」「消費が伸びれば雇用が増えて好景気になるのか?」「好景気になれば税収が増えるのか?」という実証的問題に変換すればいい。

3つ目は分析的問題。
現実に起こっている事実よりも抽象度の高い命題の妥当性を検討する。
数学の証明問題に近い。

【4】「パズルを探す」というアイデアは、計量政治学だけでなく、一般の自然科学にも使えると思った。
「パズルを探す」とは、「常識的にはAなのに、Bになっている」という不思議な現象を指す。
たとえば、欧米の民主主義国では、地方選挙よりも国政選挙の投票率が高いのに、日本では逆になっている。
また、アジア各国の国家予算に占める軍事費率を時系列的に見ると、殆どの国では外圧要因によって割合が上下するのに、日本では1%以内にとどまり一定である。
それらはなぜなのか?
そういう研究が色々あるらしく、面白い。

【5】「Rによる計量政治学」「Stataによる計量政治学」では「理論と仮説」という説明がある。
内容は、実証分析を行うためにはきちんとしたリサーチデザイン(研究設計)が必要であるという主張だ。
リサーチデザインのプロセスはこんな感じ。

パズルを見つける。
パズルを説明するための複数の前提条件を使って理論を作る。
理論から作業仮説を作る。
作業仮説を検証するためのデータを集める。
データを使って作業仮説を検証し、理論の妥当性を確かめる。

理論とは「原因と結果についての一般的な記述」である。
理論を作るためには、前提条件、つまり、本当かどうか分からないがとりあえず本当と考えることをいくつか想定する必要がある。
つまり、理論とは、「複数の前提条件の束」である。
理論構築という作業は複数の「もし」という仮定、前提条件のもとに成り立つ。
だから、説得力のある前提条件を設定する能力が必要になってくる。

良い理論の条件は、4つある。
誤りの可能性があること。
観察可能な予測が多いこと。
具体的であること。
単純であること。
これらは下記のように言い換えられる。

理論はその誤りを指摘され、反証されながら修正されて頑健になること。
つまり、反証可能性が高い理論の方が良い。

観察可能な予測が多いほど、反証可能性は高い。
予測が具体的であるほど、観察可能な予測が多くなり、反証可能性が高くなる。
社会現象を単純な因果関係にまとめることで、反証可能性が高くなり、良い理論の条件を満たす。

科学的には理論と仮説に違いはない。
ほとんどの理論は、とりあえず受け入れられた仮説である。
作業仮説とは、理論を検証するために理論から引き出された、特定の変数に関する論述である。
「もしこの理論が正しければ~のはず」と記述される。
作業仮説は理論よりも具体的で、理論から引き出される観察可能な予測について述べている。

作業仮説を作る作業化とは、理論の中の変数を計量かつ観察可能なより具体的な変数に置き換えること。
作業化において大切なことは、理論で使われている説明変数と応答変数にできる限り近く、それぞれの概念を適切に測定知る変数を選ぶこと。

【6】上記の内容を読んで思うのは、政治学や経済学のような本来は規範的問題を解決する学問をいかに実証科学に近づけようと苦労しているなあ、と思う。
確か、以前読んだ哲学入門の本で、「規範的問題はザイン(存在)からザルレン(あるべき)は出て来ない、規範的問題はザルレンから出発すべきだ」という一節を読んだことがある。

いくら、実証データで規範的問題を解こうとしても、人文科学では、時代と地域に依存する真理しか見いだせないと思う。
そういう数多くの困難な状況の中で、何とか規範的問題を実証的問題に変換して、ITと統計学を駆使して実証科学ぽく真理を見出そうとしているのだろう、と思っている。

実際、統計処理によって因果関係を真理として見出す技術も直近30年くらいで出てきているようなので、そういう技術を使って、計量なんとかという学問をどんどん生み出しているのだろうと思う。

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

| | コメント (0)

戦略/組織/人事と組織の経済学シリーズを読んでいる

「戦略/組織/人事と組織の経済学」という書籍があったので読んでいる。
戦略の経済学組織の経済学人事と組織の経済学・実践編という3冊の本だ。
リンクをメモ。

どの本も枕にできるくらい分厚い。
中身も濃い。
専門外の分野なので、サラッと読んで理解できる部分だけつまみ食いしている。

僕は、戦略論や組織論を経済学の理論で分析しようとする流れが好きだ。
理由は2つある。

1つは、経済学という人文科学の中でも最も自然科学に近く、理論に基づいて仮説検証して実証科学に近づけようとする姿勢に共感できるから。
もう一つは、経済学の理論や武器を導入することで、大量の実データに基づいて、プログラミングと統計分析を駆使することで、有益な結果を得やすいこと。
特に、R言語やPythonなどの統計処理、あるいは機械学習や深層学習モデルを適用できるので、色んな可能性を秘めていること。
特にプログラマであれば、すでにAPIやライブラリは揃っているので、実データさえあれば、こういう本の理論に従って、新たな知見を生み出すこともできる。

面白い世の中だなと思う。

組織論の背後には経済学の概念があるという仮説: プログラマの思索

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

統計学の考え方に関する感想: プログラマの思索

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

ビジネスの基本戦略には規模の経済があるのではないか: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

Pythonデータ分析試験、Python基礎エンジニア試験に合格した感想~Pythonの機械学習や深層学習が目指すのは因果推論ではないか: プログラマの思索


| | コメント (0)

2022/04/13

事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき

ドメイン駆動設計勉強会に参加してみて、事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべきという指摘になるほどと思えたのでメモ。
ラフなメモ。

【参考】
【ドメイン駆動設計勉強会】事業活動を理解して設計しよう! - connpass

増田さんの講演がすごく分かりやすかった。
問題意識は、事業活動をどのようにモデル化していくか?
事業活動をシステム化する時に、どこに注力すればいいのか?

まず、自社と外部の事業活動は、ピクト図で商品やお金の流れをシーケンス図のように表して、モデルにする。
自社の内部プロセスは、ポーターのバリューチェーンを使って、主活動と支援活動に分類する。

ドメイン駆動設計のアプローチでは、バリューチェーンの主活動や支援活動をサブドメインに分割する。
すると、基本は、主活動は企業価値を生み出すコアドメイン、支援活動は管理業務等の支援ドメイン、汎用ドメインになる。

ビジネスロジックの複雑度や差別化の重要度の観点では、コアドメインが重要であり、支援ドメイン、汎用ドメインの順になる。
一般に、汎用ドメインや支援ドメインの品質は当たり前品質で十分であり、コアドメインの品質は魅力的品質まで高める必要がある。

増田さんの講演でもっとも興味を引いた発言は、増田さんの経験では、事業活動のシステム化では、他社との差別化につながるコアドメインよりも、他社と差別化しなくて良い支援ドメインや汎用ドメインに注力すべき場合が多かった、という内容だった。
なぜならば、他社と同じような業務では、汎用ドメインや支援ドメインで構築すれば安く仕上がるし、その分野の人材も市場から確保しやすいからだ。
そもそもそういう分野では差別化せず、市販のサービスやパッケージをそのまま流用すればいい。

また、自社の弱点として実は、支援活動の業務があるケースが多いらしい。
すると、支援活動のシステム化に注力した方が投資効果が大きいらしい。
なぜなら、支援活動にある総務・財務・人事などの部門の業務は既存のパッケージ製品が多数あるからだ。

一方、本来の自社で価値を生み出すコアドメインは、独自のシステムになるから、コストをかけて当たり前品質以上の魅力的品質まで作り込むべきだ、という流れだと理解した。

一般に、支援活動にある総務・財務・人事などの部門の業務はどこの会社でも似たような内容であり、財務報告も法律で決められた書式で報告する必要があるから、できるだけ汎用ドメインで構築した方が運用が楽だし、コストもかからない。

むしろ、コストを掛けるべき部分はコアドメインであるから、汎用・支援ドメインにはコストを掛けずにメリハリを付けた方がいい。
そんな内容だと理解した。

たぶん、一般に、支援活動の業務は汎用のERPで導入した方が良いのだろう。
今ならば、汎用的なSaaSを導入すればいいのだろうと思う。

普通は、コアドメインに当たる主活動のモデル化に注力したくなるが、むしろ、支援・汎用ドメインに当たる支援活動のモデル化の方に企業の問題がある場合が多く、投資効果が大きいという経験談が面白かった。

| | コメント (0)

2022/01/01

ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること

ITの地殻変動はどこで起きているのかを2022年現在で考えてみる。
ラフなメモ書き。
特に後半は、ロジックが飛んでいるが、自分のアイデアを書き残すことに重点を置く。

【過去の記事】
ITの地殻変動はどこで起きているのか?~2006年: プログラマの思索

ITの地殻変動はどこで起きているのか?~SeasarとRuby、そしてPF: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか・2009年: プログラマの思索

ITの地殻変動はどこで起きているか?~Agile2.0をサポートするチケット駆動開発: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感: プログラマの思索

ITの地殻変動はどこで起きているのか~アーキテクチャ設計技術にクラウドが必須になった時代: プログラマの思索

ITの地殻変動はどこに起きているのか~ソフトウェアの複雑さをどのようにして手なづけるか?: プログラマの思索

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ: プログラマの思索

【1】コロナ時代でのソフトウェア事業の問題点

ソフトウェア開発やソフトウェア事業を中核としたIT事業は、2000年頃から大幅に広がり、コロナ時代に入るまでに、GAFAに代表されるように全てのビジネスの中核となった。
ソフトウェアこそが今は、すべての事業の中核システムにある。
コロナ時代になって、対面での営業、対面での人間関係が厳しく制限されて、全ての人間関係がオンライン上で実行せざるを得ない環境に追い込まれて、ソフトウェアはビジネスだけでなく、人々の生活インフラの中核にまで覆い尽くした。

従来の製造業、小売業などの従来型のビジネスモデルは、ソフトウェアを基盤とした事業モデルに大きく変革を強いられた。
それは、業務を単にIT化するだけではない。
単なる業務のペーパーレス化、情報の一元管理が目的なら、コスト削減が目的であり、それはERPというパッケージ製品の導入と同じだ。

では、どんな変革を強いられたのか?
それは、ソフトウェアで作られたシステムを基盤として、企業が提供する価値とそれを購入して消費する顧客をつなげるバリューチェーン全てをシステムで一元管理することだ。
今風に言えば、それはプラットフォームビジネスであり、DXであり、SoEとも呼ばれるのだろう。

全てのバリューチェーンをシステムで一元管理できるとどんなメリットが出てくるのか?
それは、製造業の生産プロセス、小売業の販売プロセス、在庫プロセスという企業内部の情報を一元管理できるだけでなく、販売した顧客の購買履歴や活動履歴をも一元管理することで、顧客関係性を強化でき、顧客の声を生産プロセスや販売プロセスにフィードバックすることで、自社の業務プロセスを改善できるチャンスが増えることだろう。
しかも、アジャイル開発を適用できれば、1ヶ月間というスプリントよりももっと短いサイクルで業務を改善する仕組みさえ作れる。

このDXというソフトウェア基盤にはクラウドというスケールしやすいインフラがあり、MLやDLのようなAI基盤を使って、顧客が望むものを分析し提示することすらできる。
DXを構成する開発基盤や技術が一通り揃ってきたからこそ、すべての事業をソフトウェアで丸呑みして完全に実現できるようになってきた。

事業を一度ソフトウェアで実装してしまえば、アジャイル開発プロセスに従って、いつでも方針の変更が容易になるし、顧客の情報をより簡単に入手できて分析できるから、ビジネスのKPIに適用して、ビジネスそのものの診断ツールにも使える。

しかし、製造業も小売業もその他の業界の事業も全てソフトウェアで実装してしまえばいいだろうが、実際にはその転換は従来のビジネスモデルを構築した企業ほど難しい。
なぜ、ソフトウェア事業へのビジネスモデルの転換は難しいのか?

【2】DXとは「逆コンウェイ戦略を適用する」組織論である

ソフトウェア事業へのビジネスモデルの転換は難しい理由は、ソフトウェア事業に向いた組織を作るのが難しいからだろう。
チャンドラーは、組織構造は経営戦略に従う、と言った。
つまり、ソフトウェア事業に向いた組織構造を構築する必要がある。

一方、コンウェイは、ソフトウェアは組織構造に従う、と言った。
複雑な多重階層構造を持つ組織は、ソフトウェアをより複雑化させる。
人月の法則の通り、ソフトウェアの本質は複雑性にあり、ソフトウェアの複雑性を飼いならすのは非常に難しい。
つまり、ソフトウェア事業に向いた組織構造を作ろうとするが、従来の組織に単にソフトウェア開発を担当させるだけでは上手く行かない。

特に、ソフトウェア開発は、規模の経済が適用しづらく、少数精鋭の優秀な人材の開発チームで実行する方が成功しやすい。
だから、従来の製造業や小売業のように、大規模な設備、大量の人員を用意していても、ソフトウェア開発には向かない。
人月の法則の通り失敗しやすい。

そこで、コンウェイの法則の逆張りを考えて、逆コンウェイ戦略を取ってみてはどうか、という話になる。
つまり、ソフトウェア開発は少人数の開発チームの方が適しているなら、システムの構造に従って、開発チームを構成し直して、そこから組織を作ればいいのでは、となる。
たぶん、今、ScrumがIT企業だけでなく、製造業や小売業など他の業界にも適用されて浸透しようとしているのは、そういう理由があるのではないか。

たぶん、そういう動きは一部の企業に過ぎないだろうが、ソフトウェア事業が中核になれば、従来型の企業もそういう流れに傾いていくのだろうと思う。

DXとは組織論である: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【3】今後の課題は、ソフトウェア事業におけるエージェンシー問題を解決すること

他方、会社という大きな集合体の中で、ソフトウェア事業を委託する人と、ソフトウェア事業を実行するの間には、利益が相反する緊張関係があると思う。

株主や経営者、生産プロセスや販売プロセスに従事する事業部門の人達は、プリンシパル(=委託者)になる。
彼らはソフトウェアやITに詳しくはないので、専門技術を持つエンジニアに、事業のソフトウェア化を実現するために、事業システムの構築を依頼する。

一方、エンジニアは、プリンシパルのために代理で活動する代理人をエージェント(=受託者)になる。
彼らは、ITの専門家として、プリンシパルの目標や要望を聞き出し、彼らの期待を実現する為に働く。
彼らは、事業のソフトウェア化を実装するために、業務システムだったり、Webシステムだったり、スマホアプリだったり、機械学習基盤だったり、クラウド基盤だったり、いろんなソフトウェア基盤を構築してリリースする。

しかし、経営学で習ったプリンシパル=エージェント理論では、エージェントがプリンシパルにとって望ましい行動を行わないというエージェンシー問題が必ず発生する。
一般に、エージェンシー問題が生じる要因として、「プリンシパルとエージェントの利害の不一致」と「情報の非対称性」の2点がある。

組織運営支援|マーサージャパン

ソフトウェア事業でも、委託する人達はシステムのことが分からないので、結局は、委託者であるSIの言いなりになってベンダロックインされやすい。
製造業や小売業などの発注者も、システムのことは分からない、システム開発をコントロールする難しさは体験済みなので、一括請負契約を結ぶことでシステム開発リスクをSIに全て押し付けようとするが、どうやってもベンダロックインされやすい。
その理由は以前書いた。

一括請負契約はソフトウェア開発にやっぱり向いていない: プログラマの思索

【4】ソフトウェア事業におけるエージェンシー問題を解決するための組織構造とは何か?

従来型の生産プロセスや販売プロセスを持った事業をおなっている会社が、ソフトウェア事業を中核に据えようとする場合、下記のようなイメージで、ホールディングスの持株会社を作り、親会社と事業子会社とシステム子会社がそれぞれ役割分担と制御構造を持つ必要があると考える。

親会社(ホールディングス会社)の役割は、企業グループの全体戦略を策定することだ。
その全体戦略に従って、個別の事業の戦略を策定し、その事業に必要なIT戦略、つまりシステム投資の計画を策定する。

事業子会社は、親会社が策定した事業戦略に従って、その事業に合った業務プロセスを構築し、その業務を実行する。
事業を支える業務には、業務システムが使われるため、自分達の事業に合った業務システムの要求や要件をシステム子会社に提出したり、一緒にIT計画を策定することになる。
事業子会社の成績は、事業のROIで測定されるので、事業のROIを親会社に毎年報告することになる。

システム子会社は、親会社が策定したIT戦略に従って、個別の事業を支援する業務システムを構築し、保守していく。
彼らは、事業子会社の事業戦略に従って、いつまでにリリースする必要があるのか、どれだけの開発予算が必要になるのか、をシステム計画としてまとめて、システム計画を事業子会社と親会社に承認してもらってから、実行に移すことになる。
つまり、システム子会社の主な仕事は、事業を支える業務システム構築とその保守になる。

ここで重要な点は、事業は外部環境や市場の変化によってどんどん変わるので、事業を支える業務システムは一定期間しか使われないという前提で、リプレースする期間と計画を事前に策定する必要がある点だ。
たぶん、減価償却が5年間という制約条件とか、外部環境の変化で事業の寿命は5年とか、そういう単位で、業務システムは定期的に破棄されて、新規に再構築されるように計画しておく。
そうすれば、事業小会社の事業では、たとえば5年おきに新しい業務システムに支えられるので、その時代の最新技術が使えたり、その時代の要件に合ったシステムを使えるようになる。

このように、定期的にシステムはリプレースすべきだ、と親会社も事業子会社もシステム子会社も事前にIT戦略に埋め込んでおけば、時代の変化にあった事業に対応できるはずだ。

さらに、上記のような三者の組織構造があれば、システム子会社は親会社や事業子会社に定期的に報告する義務が生じることで規制をかけられるし、システム構築の目的が親会社や事業子会社の要件に合うように考えさせられるので、システム子会社が暴走するリスクも小さくなるだろうと思う。

【5】事業を支えるシステムの企画は誰が責任を持つのか?

一般の日本企業では、メーカーであれ、ユーザ企業であれ、SI企業であれ、予算駆動だから、システムが必要になったら、その企画フェーズが必要で予算取りの根拠を作らねばならない。
では、その企画フェーズを担当する最終責任者はいったい誰なのか?

ソフトウェアPJの企画フェーズの責任者は誰なのか?: プログラマの思索

本来は、システムの企画フェーズでは、親会社や事業子会社が主導権を持って、事業に必要なシステムの要求や要件を企画すべきである。
なぜなら、彼らが使いたいシステムなのだから。

しかし、僕の経験でもそうだが、ITやシステム開発を経験していない人達がシステム企画を担当すると、割と揉める。
いろんな要求や要件は出てくるが、その時代に合ったIT技術を組み合わせて、品質・コスト・スケジュールのトレードオフに落とし込む作業が難しいのだ。
結局、システム子会社を持たない発注者は、SIやITコンサルに丸投げして、だめなシステムを計画してしまいがちになる。

システム子会社を持っていても、彼らがソフトウェア開発部隊を持っていなかったり、クラウドやAIなどの新技術に関するソフトウェア開発の経験がなければ、SIベンダに丸投げするリスクがある。
結局、企業グループの中核にシステム子会社を持ち、彼らが一通りの技術力を常に研鑽しておかなければならないのだ。

だから、システム子会社の開発者が企画プロセスに入り込んで、彼らが主導権を握る場合が多い。
そして、親会社・事業子会社のユーザと、システム子会社の開発者の間で、対立関係が発生する時もある。
AsIsはユーザが詳しいが、ToBeはユーザでは作りにくい。
開発者がToBeを作ることが多いが、ユーザが果たして納得してくれるのか?

こういう問題にどう対処するか?
たとえば、匠メソッドの匠モデルではこたつモデルを持ち出す。
ユーザ・開発者・営業担当者がいきなりToBeモデルを作る。
事業側も開発側も同じゴールを目指すべきという思想で対応するからだ。

たとえば、Scrumでは、プロダクトオーナー1人が企画プロセスを担当するだろう。
プロダクトオーナーがいるおかげで、開発チームは彼を頼りにしてシステム開発に専念できるはず。

Scrumではどのプロセスを誰が担当するのかが明確ではないかと思う。
企画:ProductOwener
開発:Team
プロセス全体の守護神:ScrumMaster
という仮説も成り立つ。

それから、システムはリリースしておしまいではない。
システム投資の予算を立てて投資するのだから、投資対効果もIT計画に盛り込んで、リリース後に半年後、1年後に実際にROIが予定通りなのか検証したい。
そうしなければ、次のリプレースに活かせないからだ。
また、システム投資のROIを測定する作業をシステム子会社に課すことで、彼らにROIの意識付けもできるようになる。

システムの投資対効果(ROI)を検証するプロセスはどんな構造になるのか?

GoalやToBeでは、システム構築の目的にROI向上(工数削減、経費削減、売上向上)があるはず。
たとえば、システム化することで、手作業から自動化されて工数が削減される。
ペーパーレス化されて、経費が大幅に削減される。
システム化されて、新規顧客に利用してもらって、売上拡大を図る。
そんな内容がROIになるだろう。

稼働後に検証しなければ、一連のPDCAが回らない。
投資対効果=ToBe-AsIs で測定することになる。

企画プロセスでToBeを定めているので、リリース後に実際に、工数や経費、顧客数と売上を測定して、その差分を見ればいい。
もちろん、リリースが遅れると、その分、投資対効果が得られる期間が先延ばしになるので、メリットが薄くなる。
システム構築のコストが増えれば、もちろん投資対効果は薄れるし、使いづらいUIだったり、処理が遅かったり、まともに動かないシステムだったら、投資対効果はゼロかマイナスになってしまうだろう。

【6】こういうホールディングス会社、3社の企業構造をもたせれば、ソフトウェア事業におけるエージェンシー問題をかなり和らげて、エージェントであるシステム子会社が暴走したり、システム構築の目的を忘れてしまうリスクを減らせるのではないだろうか?

逆に言えば、IT計画策定やROI測定などの仕組みを課さないと、事業を支える業務システムを構築できないのではないだろうか。

| | コメント (0)

より以前の記事一覧