メトリクス分析のコツは良いIssueを見つけること

メトリクス分析のコツは良いIssueを見つけることと思う。
ラフなメモ。

【参考】
DXの本丸は「データ」にあり　「問い」からはじめるデータ分析とその活用法 - ログミーBiz

データ分析から導き出す「強い野球チーム」のつくり方　映画『マネーボール』で学ぶデータサイエンス - ログミーBiz

akipiiさんはTwitterを使っています: 「ソフトウェア工学のメトリクス分析の考え方にも適用できるので参考にする。データ分析から導き出す「強い野球チーム」のつくり方　映画『マネーボール』で学ぶデータサイエンス - ログミーBiz https://t.co/ZmCzuVEIUy」 / Twitter

akipiiさんはTwitterを使っています: 「データ駆動はイシュー駆動。良い問いが解決策を生み出す。メトリクス分析も同じだな。DXの本丸は「データ」にあり　「問い」からはじめるデータ分析とその活用法 - ログミーBiz https://t.co/XRe7ceo6u0」 / Twitter

【1】問題解決を図るときに、定量データを扱うのは有効だ。
最近は、Webログやスマホ履歴のようにビジネスの副産物として簡単にデータを集められる。
すると、溜まったデータをいかに活用するか、が大事になる。

『マネーボール』という映画では、貧乏球団が強いチームを形成するのに必要な問題は、「出塁率の最大化」だった。
そこに問いの価値がある。
選手の人間性、選手の組み合わせ、とかそんな観点の問題ではなかった。
問いを「出塁率の最大化問題だ」と立てられたら、あとは、バッター個人のデータを分析して、確率論に持ち込めばいい。

つまり、良い問い（Issue）を把握するのが大事。
良いIssueは数字で答えたくなる。

良いIssueを探るには何が必要なのか？

顧客行動の理解ならカスタマージャーニーを使う。
お客さんがその商品を購入したいと思うタイミングとか、ファンになるまでのステップごとに定量データを集めて分析する。
そうすれば、どこでユーザが離脱するのか、どこでユーザの満足度が低いのか、が浮き彫りになってくる。
これを業務システム開発に置き換えれば、一連の全体の業務フローを描いて、それぞれのステップごとに分解することになるだろう。

次はこれをどうやって定量化していくか？

KPIツリーによる指標分解を使う。
売上＝客数ｘ客単価。
顧客数を＝認知人数×購入率、みたいに分解していく。

掛け算か足し算で異なる。
掛け算では、2つの指標を独立だとみなす。
足し算はセグメントに分ける。

基本は、カスタマージャーニーマップのステップごとにKPIツリーで分解していく。
この辺りのプロセスは、ECサイトの分析であるAARRRの手法と全く同じ。

【2】ソフトウェア開発プロセスのメトリクス分析でも、同じような考え方を適用できる。

たとえば、WF型開発のPJであれば、工程ごとにゲートがある。
各ゲートに着目してQCDの観点でメトリクスを作ることはできる。

では良いIssueとは何なのか？
Issueをどうやって解決するのか？

良いIssueを見つけるのが大事。
「イシューから始めよ」の通り、質よりも量で頑張ると、生産性が非常に悪い。
大量にアウトプットを出しても、正解にたどり着くルートはせいぜいそのうち5％ぐらいしかない。
そうならば、事前に本来のIssueを絞り込んで、生産性を高めるべき。

メトリクス分析では、良いIssueを立てて、そこからKPIツリーで分解した各要素のどこにインパクトがあるのか、を見るのが大事。

Javaのenum型はシングルトンクラスみたいだ

Javaの最新版に触れてみたら、enum型にコンストラクタやメソッドを持たせることができると分かった。
ちょっとびっくりした。

(2) よしけーさんはTwitterを使っています: 「enum にメソッド持たせるのは effective Java あたりを読まないと気がつけない気がする。。 #ドメインモデルパターンに挑戦する苦労ばなし」 / Twitter

(2) akipiiさんはTwitterを使っています: 「Effective Javaにenumのパターンが確かに書いてあった。enumでメソッドを定義する発想がなかった。後で読む」 / Twitter

あなたの知らないJava enumの使い方 - SEチャンネル

Effective Java 第３版 第６章enumとアノテーション - Qiita

Effective Java 3rd [Chapter 6] - enum とアノテーション - Little by little and bit by bit - マイペースにこつこつと

【Effective Java】項目３０：int 定数の代わりに enum を使用する - The King's Museum

Effective Java 第３版 「ほぼ全章」を「読みやすい日本語」で説明してみました。 - Qiita

ドメイン駆動設計に関する勉強会で、Javaのenumにメソッドを持たせられるというツイートを見た。
「Effective Java 第3版 | Joshua Bloch, 柴田 芳樹」を読んでみたら、たしかにenumに1章を割いて、詳しく説明されていた。

個人的印象としては、JavaのEnum型はシングルトンクラスみたいだ。
グローバル変数の出し入れに使える感じ。
使い道としては、業務システムのシステムコントロール定数を持たせたい時だろうか。

Effective Java 第３版 第６章enumとアノテーション - Qiitaでは、int型をEnu型で書くべき、というプラクティスは理解できる。
しかし、「拡張可能なenumをインタフェースで模倣する」プラクティスのように、通貨クラスに「＋」「-」のようなメソッドを独自で実装するという発想はなかった。
こういう考え方がドメイン駆動設計の値オブジェクトの実装に役立つのだろう。

Javaから離れていたので、最新版のAPIや文法がかなり変わっているのに気づいた。
Javaはオブジェクト指向言語だというぐらいのイメージしかなかったが、RubyやPython、JavaScriptなどの良い面をJavaも取り入れようとしている印象を受ける。
Javaにラムダ式ぐらいを取り入れるのはまだよいが、ストリームAPIは何かやりすぎな感じもした。
気づいたことはまた書く。

プロセス設計はどの範囲を指すのか？～プロマネの仕事はテーラリングにある

とある勉強会で、プロセス設計はどの範囲を指すのか、を議論した。
自分の考えをメモ。
ラフなメモ書き。

【参考】
デジタル庁が解くべき課題とITエンジニアの役割の勉強会の感想～CTOの役割とは何ですか？: プログラマの思索

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

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

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

プログラマとスクラムが社会実装を変えていく　#Findy_GovTech: プログラマの思索

マッキンゼーの報告書「2030 日本デジタル改革」が手厳しい: プログラマの思索

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

ソフトウェア・ファーストの感想: プログラマの思索

プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール: プログラマの思索

【1】プロセス設計とは何か？

「SEはプロセス設計する能力が必要」と清水吉男さんは言われていたと思う。
PJ計画時に、担当SEは担当PJでどんなプロセスが必要でどんな成果物が必要なのか、を明確にすべき。
なぜならば、システムの特徴、PJ特性に応じて、プロセスや成果物はどのPJでも微妙に異なるからだ。
それを不明確なまま進めると、じきにプロジェクトの運営がうまくいかなくなる。

イメージとしては、XDDPならばPFDというDFDを描いて、プロセスと成果物のデータフロー図を描くものと思う。

【2】プロセス設計の考え方は標準から各PJへのテーラリングが基本

では、プロセス設計とはどんな構造を持つのか？
きちんとしたSIであれば、社内に標準プロセスがあり、それを担当PJごとにテーラリングしたサブプロセスを定めることになる。
つまり、「プロセス」クラスと「サブプロセス」クラスという型が継承関係にある。

プロジェクト計画が確定すると、「サブプロセス」のインスタンセスが生成される。
PJ実行フェーズで、プロセスのインスタンスをもとに、具体的な成果物（たぶん、設計書などのExcel帳票）が作られていく。

つまり、プロマネは担当PJの特徴、システム特性に応じて、標準プロセスをテーラリングないしカスタマイズする自由度は許されている。
ここにプロセス設計の能力が必要とされる。

プロセスプログラミングとは from akipii Oga

【3】プロセス設計の範囲は、PMO事務局とプロマネで異なる

では、プロセス設計の範囲はどこなのか？
(1)プロセス設計とは、プロセスインスタンスから標準プロセスへ抽象化する手法？
(2)プロセス設計とは、標準プロセスをプロセスインスタンスに具体的に実現する手法？
(3)プロセス設計とは、標準プロセスからサブプロセスへテーラリングする手法？

僕の考えでは、プロセス設計の範囲は、PMO事務局とプロマネで異なる。

全社横断的PMO事務局は、社内の案件に対し、標準プロセスを定めたガイドラインを定義し、その推進活動を担当する。
PMOの作業範囲は、「プロセスというクラス」の部分で標準プロセスの型をガイドラインで定義し、各案件のPMには、標準プロセスは守ってもらうことになる。
一方、プロマネには、PJ特性に応じて成果物やプロセスを取捨選択したりカスタマイズしてテーラリングする。

つまり、PMOが担当するプロセス設計の作業範囲は「プロセスというクラス」になる。
なぜならば、標準プロセスを定めたガイドラインの保守改訂はPMOの範疇だから。

一方、案件のプロマネの作業範囲は「サブプロセスというクラス」でPJのテーラリングを行ったプロセスを取捨選択ないしカスタマイズして決めて、PJ計画の活動で具体的なプロセスと成果物（たぶんExcel帳票）を確定すること（プロセスインスタンス）になる。
なぜならば、プロセスをテーラリングして詳細化する作業は、プロマネの担当だから。

【4】テーラリングはどのように評価されるのか

実際の現場では、PMOとプロマネの間で対立はある。

PMOは、ガイドラインがベースラインなので基本はPMに守ってもらうことが最優先であり、実際の案件とのギャップがあれば、それは吸い上げて真因を深掘りする作業を担当する。
テーラリングの自由度は許される範囲内でプロマネにあるから、プロマネの説明の根拠を一つずつ確認して、問いただしていく作業が必要がある。
実際は、そのテーラリングの妥当性で揉めることが多い。

たとえば、プロマネが案件の予算を申請する時、役員を含めた経営陣やPMO事務局が投資計画の内容を精査して、案件の予算確保と実行承認を決定するだろう。
その時に、会社標準のプロセスに即して投資計画を立案しますが、基本はテーラリングが必ず入る。

テーラリングの例としてはこんなものがある。

・標準では許されない工程の重複や統合、省略を許す
・標準化されていない開発方法、技術を適用する
・メトリクスの許容値を調整したり、代替メトリクスを計画する

たとえば、SAPのようなパッケージ製品の導入であれば、すでに開発プロセスがベンダ製品に埋め込まれている。
社内標準とは異なるベンダ製品のプロセスを社内の体制で実行できるか、などをPMが経営陣に説明する必要がある。

あるいは、機械学習の開発基盤を導入する案件であれば、標準化されていない開発手法を適用することになる。
開発リスクを見込んだスケジュールを作っているか、コストを見込んでいるか、をPMが経営陣に説明する必要がある。

あるいは、品質基準を変更してPJ用にテーラリングしたならば、品質基準を変更した妥当性の根拠をPMが経営陣に説明する必要がある。

プロマネが作った投資計画書やPJ計画書をレビューして、細かく精査すると、コストの妥当性、開発リスクの検討、品質基準の設定が甘い時も多い。
そういうレビューを通じて、投資計画の精度を高めるし、プロジェクト実行時の各ゲートレビューでPJの実行状況をPMOがモニタリングしてチェックすることになる。

【5】とは言え、プロセス設計とその評価プロセスの質は、SIであってもユーザ企業であっても、バラつきが多い。

システムの有効性を知りたい経営者、利用ユーザなどの第三者であれば、こういう仕組みがしっかりしていると、安心してシステム開発を任せられる。
たぶん、日本政府のデジタル庁が目指しているあるべき姿も、この辺りの内容に近いのでは、と推測する。
なぜならば、内製部隊を持てない場合、ベンダに委託する必要があるが、こういうプロセスの仕組みをしっかりすることで、ベンダから提供される成果物が標準化できるし、社内でもユーザ要求や仕様をまとめる能力が高まるし、最終的にベンダロックインを防いだり、プロジェクトの進行状況を適宜チェックする仕掛けができるからだ。

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

ホールディング会社の役割とIt企画・構築プロセス from akipii Oga

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク

組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンクがあったのでメモ。

【参考】
組み込みUMLでの、分析モデリングでのクラスの識別アプローチについて文献まとめ - 千里霧中

組込みソフトウェア開発と設計をちょっと調べている。
やっぱり設計手法にはUMLを使っている方が僕は理解しやすい。
それに関する書籍のリンクの記事があったので、メモしておく。

【１】組込みソフトウェア開発のためのオブジェクト指向モデリング (組込みエンジニア教科書) | SESSAME WG2

この本はとても分かりやすかった。
湯沸かしポットを題材として、実際にクラス図、状態遷移図まで落とし込んでくれている。
この本の感想は以前書いた。

組み込みソフトウェアの根本問題～対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい: プログラマの思索

【２】リアルタイムUML―オブジェクト指向による組込みシステム開発入門 (Object Oriented Selection) | ダグラス,ブルース, Douglass,Bruce Powel, 博之, 渡辺, 株式会社オージス総研

【３】リアルタイムUMLワークショップ | ブルース・ダグラス, 鈴木 尚志

持っているけど理解できていない。

【４】組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発 (OOP Foundations) | 博之, 渡辺, 和人, 堀松, 政彦, 渡辺, 和記, 渡守武

古本屋で見たことがある。
今度読んで見る。

【５】UML動的モデルによる組み込み開発―分析・設計・実装・テスト | 政彦, 渡辺, 哲史, 石田, 康二, 浅利, 周作, 飯田, 修二, 山本 | Amazon

今度読んで見る。

【６】オブジェクトデザイン (Object Oriented SELECTION) | レベッカ・ワーフスブラック, アラン・マクキーン, 株式会社オージス総研 藤井 拓, 株式会社オージス総研 藤井 拓, 辻 博靖, 井藤 晶子, 山口 雅之, 林 直樹

オブジェクト指向設計のうち、責任の割当に注力して書かれている。

【７】実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 | クレーグ・ラーマン, 依田 智夫, 今野 睦, 依田 光江

僕は第１版、第２版を読んだ。
第１版では「オブジェクト指向設計の肝はコラボレーション図（協調図）です」という一節がすごく心に響いた。
クラスへ責務を割り当てるときに、UML2.0ならコミュニケーション図を書いて、責務が集中しないように疎結合にしたり、関連する責務は集めて凝集度を高くする、などのアドバイスがあった。

「完全独習 統計学入門」は良い本らしい

ある勉強会で、「完全独習 統計学入門」は統計学の初心者に良い本だ、と勧められた。
「t検定の原理を理解して使いこなせれば、統計学の免許皆伝だ」と言われるらしい。

【参考】
統計学挫折者にオススメという「完全独習 統計学入門」を読んでみた | ゆとって生きたい。

統計学をはじめて学ぶ方におすすめ：完全独習 統計学入門: 教育機関向けソフトウェア　アカデミック・ソフト・プラス

(引用開始)
▽本書は、
●統計学を初めて学ぶ人
●統計学を改めて学び直したいという人
●何度も挫折して、いまだに身についてない(と感じている)人
●今まさに落ちこぼれつつある人
に向けた、統計学の超入門書です。

(1)「これ以上何かを削ったら、統計学にならない」という、最小限の道具立て(ツール)と簡単さで書かれた「超入門書」

(2)確率の知識はほとんど使わない。微分積分もシグマも全く使わない。使う数学は、中学の数学(ルートと1次不等式)までだから、高校数学がわからなくても(忘れてしまっていても)大丈夫

(3)毎講に穴埋め式の簡単な練習問題がついているので、独習に最適

(4)第1部では初歩の初歩からスタートしながらも、「検定」や「区間推定」という統計学の最重要のゴールに最短時間で到達することを目指す

(5)第2部では、第1部の内容に厚みをつけ、統計学での免許皆伝でともいえるt分布を使った小標本の検定・区間推定に最も効率的にたどりつく。基本が理解できれば、相当なところまで理解できる

(6)標準偏差の意味が「体でわかる」よう、簡単な計算問題や具体例で徹底的に解説する

(7)株や投資信託などへの投資のリスクを、統計学から理解して金融商品にも強くなってもらう

▽本書は、「これ以上何かを削ったら、統計学にならない」というギリギリの道具立てと簡単さで書かれた「超入門書」です。

本書は2部構成となっています。第1部では初歩の初歩からスタートしながらも、「検定」や「区間推定」という統計学の最重要項目のゴールに最短時間で到達することを目指します。

▽「統計学」を効率よく、1ステップずつ理解するために、本書のスタンスは以下のようになっています。

●本書では、標準偏差(S.D.)を最も重要視する
●本書では「確率」をほとんど扱わない
●「95パーセント予言的中区間」を用いて説明
●数学記号も数学公式もほとんど使わない(出てくるのは中学数学だけ)
●穴埋め式の簡単な練習問題で独習できる
(引用終了)

「完全独習 統計学入門」がお勧めの本と言われる理由は3つあるらしい。
一つ目は、中学生の数学レベルなので、微積分を知らなくても計算できる。
2つ目は、t検定で出てくる「区間推定」や「信頼区間」などを詳しく解説してくれていること。
3つ目は、穴埋め式の練習問題が豊富なこと。これが一番重要らしい。

先生曰く、統計学を習得するときには3段階ある。
最初は、統計学の概念を理解する。
次に、数多くの例を実際に手を動かして計算して習得する。
最後に、実践の場で統計学を使ってみる。

しかし、統計学を習得しようとする人を見ると、概念を理解するために理論的な本を読んで挫折したり分かった気になったりしている。
実際に具体例で手を動かしていないから使えない。

あるいは、いきなり実践の場で必要になったので、とにかく現場で使いまくるが、基礎が分かっていないので、正しくない結果を出したり、導かれた結果から結局何が言えるのか説明できない。

つまり、いずれも、実際に手を動かして計算して、統計学のコツを掴むのが重要ですよ、と言われた。

そんなわけで、この本をじっくり読んでみたいと思う。

戦前の日本人の気質はまだ成熟していない青年期と同じだった

【1】「日本人の行動パターン」に書かれた一節が一番心に残った。
アメリカ人は戦前の日本人をこういうふうに分析していたんだな。

日本人は青年期の未熟さの性質を持つ。
ころころ変化する態度、人に応じて異なる感情表現、幻想に陥る現象はパーソナリティ形成が成熟していないことを表す。
社会構造が変化すると、それに対応して素早く変わる日本人は、青年期の発達段階に特有のもの。
日本人の集団はノイローゼにかかっている。集団的神経症、強迫観念に囚われている。

【2】僕が学生の頃は、日本文化論がすごく流行っていた気がする。
日本が経済大国と呼ばれていた時、なぜ日本は小さな島国にすぎないのに、そこまで成長できたのか？
それに答えるために、数多くの論説があった。
割と多かったのは、日本特殊論。
日本人は特殊な気質を持つ、特殊な文化を持つ、という論説が多かった気がする。

確か、E.H.ノーマンの本だったか、ある一節があった。
戦前の日本人の言動を見ると、ある時は激しやすいが、別の時は穏やか。
ある時は頑固なのに、別の時は一瞬にして豹変して環境に順応する。

その原因は、日本人が置かれた社会や政治構造に由来するのでは、という指摘だった。
一言で言えば、日本社会は階級制度であり、日本人はその社会順序を乱さないように、あらゆるところから統制を受けている、と。

「日本人の行動パターン」の一節を読むと、それにぴったりな気がした。
明治から昭和にかけて、日本人が急激に近代化できた理由は、たぶん日本人は未成熟な青年期の人間が多かったのだろう。

そして、2022年の現代日本は平均年齢が49歳なので中高年世代が最も多いから、青年期ではなく老年期に入っているのでは、と思ったりする。

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする

「大人の学びパターン・ランゲージ」はリスキリングの参考になると思った。
IPAの同じWebページにある「学び続けている実践者の方からお話を伺いました。」というインタビュー記事もとても良い。
読んでみて、自分の中で色々考えるものがあった。
ラフなメモ。
間違っていたら後で直す。

【参考】
大人の学びパターン・ランゲージ（略称まなパタ）：IPA 独立行政法人 情報処理推進機構

変革への道：IPA 独立行政法人 情報処理推進機構

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

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

【1】社会人になって「学ぶ」とはどんな意義や問題点があるのだろうか？

日本人なら大学へ入る18歳までは受験勉強という公式な体制の元で勉強させられる。
学びとは何なのか？という基本的な問いを考える作業は、この期間は無意味だ。
むしろ、希望大学に入学することが自己目的化している人ほど、受験競争の勝者になる。

一方、社会人になると、急激に能力を伸ばす人と、停滞する人の2種類に差別化される。
案件に揉まれて技術やマネジメントの経験を身に着けて、どんどん昇格して、社会的地位が上る人もいれば、職を転々としながらも何も変わらない人もいるし、同じ企業の中でずっと何も変わらずに仕事している人もいる。
人はそれぞれの目的を持って生きているように仕向けられる。

そういう状況の中で、現代という時代では、20代で身につけた知識や技術がすぐに陳腐化するリスクに常につきまとまれている。
特に、IT技術を身に着けても、それは10年後には当たり前になり、差別化できる要因ではなくなる。

すると、30代、40代、50代と年齢を経るごとに、自分が活躍できるステージをどんどん変えていく必要性が出てくる。
単純な専門的知識で差別化するよりも、チームや組織、企業を回すようなマネジメント、経営への領域へ移す人達も多い。
人との関わりという部分で差別化しようとする。

しかし、20年経てば1世代変わるので、人も社会も価値観が変わり、人間関係をコントロールするマネジメントスタイルも急激に変わる。
昨今では、米国でのマネジメントの最新知識、たとえば、心理的安全性、ファシリテーション、ティール組織、などいろいろな手法を身に着けなければ、今の社会で自分の存在意義を見つけるのは難しいのではないか。

【2】ビジネスで結果を出そうとする時、知識と経験の2つの両輪が必要になる。

自分の数少ない経験では、知識を経験に変わるタイミング、経験が知識に変わるタイミングを自分なりにつかんでおくことが重要と思う。
なぜならば、知識だけ脳みそにたくさんあっても使いこなせなければ現場では無意味だからだ。
経験をいくら積んでも、その経験を自分なりに解釈して抽象化した知識に変換して、他人に説明できなければ、現場では無意味だからだ。

知識を実際の現場で使おうとする時、他人から教わった知識、本から得た知識は、自分の現場の問題が発生する環境とギャップがある。
環境がもたらす制約条件を考慮しながら、問題を解決する方向へ知識を利用する。
その知識が問題をうまく解決するときに使えたタイミングで、その知識の有効性とその知識が使える範囲を自分なりに理解できる。
この時が知識が経験に落とし込めたタイミングだ。
このタイミングはすごく重要で、そのタイミングを意識しなければ、何事もなく通過してしまって、自分の腹に落とし込めたものにならない。
その知識には、自分にとって再現性がなくなるからだ。

一方、色んな経験をして来た後で、本を読んで気づいたり、コミュニティや大学で色んな人と議論して気づいたりするタイミングがある。
たとえば、初めての案件で初めての役職で仕事して試行錯誤したり、デスマーチ案件で日々苦しめられたり、ルーチンワークに追われて何も考えないまま過ごしたりした後で、なぜこんな状況を自分で解決できないのか、という疑問や問題意識を強烈に持つ。
自分の能力の限界を知り、自分で環境を変える要因をつかみたいと思う。
そんなときに、本や動画、ネット、他人との会話という数多くのチャネルを通して、知識やフレーズに触れたときに、ぴーんと来る時がある。
この時の知識が、経験から知識を抽出して、自分なりに理解できたタイミングだ。
このタイミングは重要で、自分でそのタイミングを意識しなければ、経験は単なる時間的浪費にすぎない。
いくら年齢を取ったとしても、同じ時間という量は質が大きく異なる。

知識と経験を行ったり来たりするタイミングを自分なりに意識して習得することが必要であると最近感じている。

【3】知識と経験を行ったり来たりするタイミングやその活動は、たぶんSECIモデルで表現されるだろうと思う。

知識を経験に変えるタイミングは、形式知から暗黙知に変換する活動に一致し、それは「内面化」に相当すると思う。
経験を知識に変えるタイミングは、暗黙知から形式知へ変換する活動に一致し、それは「表出化」に相当すると思う

つまり、内面化や表出化のタイミングを自分なりにいつも意識して、その瞬間を忘れないようにすること。
そうすれば、以前の自分からなにか一つ殻を破れた、という感覚が得られると思う。

SECIモデルの状態遷移図 from akipii Oga

そのためには、表面的な知識を色々自分なりに考えて、どういう問題ならうまく適用できるのか、どんな制約条件を考慮すべきか、実はあまり効果がないのでは、と試行錯誤して考える必要がある。
その作業は、形式知同士を組み合わせて新たな形式知を得る「連結化」という作業が必要になるのではないか。

また、案件でたくさんの経験を得たとしても、その経験から何が問題だったのか、何が足りなかったのか、どんな環境要因があったのか、試行錯誤して考える必要がある。
その作業は、暗黙知の内容を整理して暗黙知のレベルを高める「共同化」という作業が必要になるのではないか。

【4】知識と経験を行ったり来たりする作業は意識的にやる必要があると思う。
特にビジネスマンになれば、いろんな場面で初めての問題に遭遇し、常に問題解決や再発防止を迫られる。
そんな状況で何らかの成果を出すには、常に知識と経験を行ったり来たりする技術を持つ必要があると思う。

以前「実践した後に勉強するのがエンジニアの本来の道」というツイートを読んで、ソフトウェア開発はまず実践して経験した後で知識を習得するのが一番の近道、という内容を思い出した。
実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

また、ビジネス経験を積んだ後でMBAを取得する話をよく聞くが、たぶん、一度経験した内容を知識として再構築する必要性を感じているのだろうと思う。
「あるMBAコースの人（元銀行員で支店次長）が僕にこう言っていた。MBAっていうのは、サラリーマンが20年間で覚えることを圧縮して教えるものだと。マネジメントのエッセンスを短期的に学ぶことで管理職、役員レベルの視点を持つことを目的にするということなのかもしれない。」という内容は心に残った。

企業経営アドバイザー - hmiyau ページ！

MBA | 猫好きのブログ

まなパタにはそのヒントが隠れているような気がする。

パターン言語の構造と事例 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

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

経済セミナー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と統計学が融合している学際的な場所になっている。
プログラミングさえできれば、統計学の理論、経済学の理論は、実際に動かしながら後から理解すればいいと思う。

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