文化は組織構造に従う

「大規模スクラム Large-Scale Scrum」を読んでいたら、「文化は（組織）構造に従う」という文章があった。
なるほど、と思ったのでメモ。
以下、結論のないラフなメモ。

【1】「大規模スクラム Large-Scale Scrum」P.63では、「文化は（組織）構造に従う」をラーマンの組織行動の法則として紹介している。

組織は、中間管理職やマネージャの権力構造を維持するために、暗黙的に最適化されている。
その結果、組織を変えようとする試みは、職種の名称を変更するくらいで現状維持になる。
その結果、組織を変えようとする試みは、マネージャや現状維持しようとする人々から、理想主義者として非難される。
その結果、文化は構造に従う。

つまり、組織の文化を変えようとするのは愚かな試みで常に失敗する、と。
人々の行動（文化）はシステムの産物なので、システム（組織構造・組織階層）を変更すると、人々の行動が変化する、と。

【2】チームの文化、メンバーの行動、組織の文化は、所属する組織の構造の影響下にある。
逆ではない。
構造は文化に従うよりも、文化は組織構造に従う力の方が大きい。

人々の行動はシステムの産物。
システムを変更すると、人々の行動は変化する。

組織の構成要素を変更すると、人々の行動は変化する。
たとえば、ポリシー、役割、組織階層など。

【3】「文化は（組織）構造に従う」考え方は、システム思考と同じ考えだ。
システム思考では、発生する問題、人々の行動を即座に変更できないのは、悪循環を生むシステムが存在していて、その因果関係によって発生しているとみなす。
つまり、原因となる悪循環のシステムを変更するか、壊さない限り、問題は変化しないし、人々の行動は変わらない。

また、「文化は（組織）構造に従う」考え方は、行動経済学と同じ考えだ。
行動経済学では、人はインセンティブの奴隷、とみなす。
人々にインセンティブを付与することで、人々の行動を特定の方向に誘導しようとする。
たとえば、政府の財政政策や給付金、競争を取り締まる政策によって、企業や消費者、市場を特定の方向に誘導し、政策の効果を引き出そうとする。

【4】「大規模スクラム Large-Scale Scrum」はまだ読みかけなのだが、組織論の話が多い点に気づいた。

いかにマネージャを排し、フラットなチームを残してスケールさせるか？
現場で生き生きと活動しているスクラムから、いかに大規模な組織のスクラムにスケールアップするか？

そのためには、既存の組織構造に手を入れて、スクラムというチームの活動（文化）に悪影響を与えないようにする。
つまり、組織構造にスクラムの原理を反映させて、組織そのものをフラットにしてしまう。

この考えや意見は理想主義的なように思えるが、「大規模スクラム Large-Scale Scrum」を読んでいくと、あながちそうでもない気もする。

コロナ時代では、企業も人もいきなり変化する環境に放り出されて、物理的な接触を禁じられて、リモートワークを余儀なくされた。
すると、物理的にもマイクロマネジメントなプロジェクト管理は実施できなくなり、事実上、組織人ではなく、自由な一個人として労働するようになっているし、そうならざるを得ない。
コロナがなくなっても、労働環境も組織も変化してしまったのだから、もう昔のやり方に戻ることはできない。

そういう時代だからこそ、スクラムをチームベースではなく、大規模な組織ベースにスケールさせることには意義がある。
そのために、組織構造に手を加えて、人々の行動を変容させることも必要になってくるのだろう、と思う。

「ストーリーマッピングをはじめよう」本の感想～ストーリーによる企画や要件定義はSaaSと相性がいい

「ストーリーマッピングをはじめよう」本を読んで良かったのでラフなメモ。

【参考】
なぜユーザーストーリーによる要件定義にピンとこなかったのか: プログラマの思索

あなたが開発しているプロダクトにストーリーはあるか。クリフハンガーに陥らないための作戦がここにある。 - The Dragon Scroll

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart1: プログラマの思索

小説分析ツールyWriterの機能を元にストーリーの構造や考え方を解説するpart2: プログラマの思索

yWriterは映画の脚本を作るためのアプリだったのではないか: プログラマの思索

【0】「ストーリーマッピングをはじめよう」本の感想は3つある。

1つ目は、ユーザーストーリーで物語を可視化できる。
システム要件を物語として構造化できる。

物語は三幕構成というロジカルな構成を持つ。
アリストテレスが古代ギリシャ悲劇を理論化して、何千年もの歴史がある。
世界中の誰もが馴染みやすい。

そもそも、人間の認知のメカニズムは、ストーリーになる。
人間は、事象を、物語を介して理解している。
たとえば、旅行、映画、体験談。
たとえば、内視鏡検査が痛かった体験談すら、ストーリーで家族に語る。

2つ目は、ストーリーはSaaSと相性が抜群に良い。
ストーリーに合わせて顧客を呼び込んで、顧客行動をWebの画面遷移のWebログで計測できる。
導線のクリフハンガーを特定できる。

ストーリーの効果をKPIで評価できる。
SaaSのKPIなら、AARRRを思い出す。

AARRRとは?サービスを成長させるための基本戦略【テンプレート付】｜ferret

つまり、購入率、CVR、成約率というKPIでストーリーの効果を評価できる。

3つ目は、課題解決に適用できる。
現状→問題→葛藤→目的達成→解決、という課題解決の流れは、古典的なストーリーの構造である、状況設定→複雑化→問題→解決と全く同じ。

課題解決には3種類のストーリーで使い分ける。
コンセプトストーリーで、新製品・新規機能をアピールする。
次に、潜在顧客に、オリジンストーリーでメッセージを伝える。
さらに、具体的な利用シーンをユセージストーリーで説明して、末永く利用してもらう。

つまり、新製品のコンセプトを打ち出してユーザを惹きつけ、顧客接点となるWebログイン画面から、物語のようなWebの導線を張ってユーザ誘導して、おとぎ話に落とし込む。
それぞれの機能は、利用シーンに合わせたストーリーで一貫した目的があり、ユーザはそれに一喜一憂して、ハラハラ・ドキドキさせられる。
そういうSaaSを目指すわけだ。

【1】ストーリーマッピングの特徴は3つある。

1つ目は、ユーザー体験を物語の各場面にプロットポイントとしてマッピングすることで、ストーリー化してしまうこと。
物語はナラティブアークと言われる。
ナレーションみたいなものだろうか。

「ストーリーマッピングをはじめよう」に出てくるストーリーには、7つのプロットポイントがあり、時系列のグラフとしてマッピングされる。
プロットポイントは、状況説明→事件や問題の発生→盛り上げ→危機→クライマックス→オチ（落とし込み）→エンディング、という流れ。
三幕構成では、状況説明→事件や問題の発生が、始まり。
→盛り上げ→危機→クライマックスが中盤。
落とし込み→エンディングが終わり、に相当する。

ストーリーの構造は、「考える技術・書く技術」に出てくるプレゼンテーションのイントロの技術「状況→複雑化→疑問→答え」と全く同じ。
一方、ストーリーはこの7つのプロットポイントを明確に意識し、観客の感情を上下させるように場面設定を論理的に組み立てなければ、興ざめしてしまう。

各プロットポイントにも特徴がある。
事件発生では、Call To Action、つまり、行動を求める声となるイベントを置く。
ユーザが後戻りできないような事件を引き起こす。

物語では、クライマックスが大事。
クリフハンガーとは、上昇途中やクライマックスで唐突に終わるストーリー。
これは避けなければならない。

halfalogueとは、盛り上がるだけで、オチのないストーリー。
クライマックスやエンディングが半分だけなのでイライラする。
これは避けなければならない。

エンディングでは、続き物をわざと残す。
別の物語につなげるために。

【2】2つ目は「ストーリーマッピングをはじめよう」では、ストーリーは3種類ある。
「コンセプト・ストーリー」「オリジン・ストーリー」「ユセージ・ストーリー」の３つ。

【2-1】コンセプト・ストーリーとは、製品概念の物語。
Concept＝構造、全体像。
顧客が製品に感じる印象を元に、課題解決する。
新製品や新機能の開発に取り組む時に利用される。

例は、ジョブズがiPhoneを始めて紹介したプレゼン。
Slackというコミュニケーションツールを最初に紹介したプレゼン。

注意点は、平坦な展開は避ける。
物語を支える要件を見極める。

【2-2】オリジン・ストーリーとは、潜在顧客が初めて購入する物語。
Origin＝発端、起点。
製品概念を知った後で、製品を実際に使ってもらう。
よって、顧客のチャネルや顧客接点が重要になる。

目的は、新規客を獲得し、リピート客にConvertする。
顧客接点を起点にあの手この手で販促する。
物語はプロモーションかな。

マーケティング部、営業部、広報部が、オリジン・ストーリーを主体的に作る場合が多い。
つまり、技術部がメインではなく、潜在顧客をマーケティング部などがイメージして、ストーリーを作り出す。

注意点は、物語をどう終わらせるか？が大事。
物語をストーリーにマッピングできないと、クリフハンガーが発生し、せっかくの見込客が離れてしまう。
Webシステム上のユーザの導線を計測して、クリフハンガーを特定し、対策を取る。

どんなアフォーダンスをユーザに示すか？が大事。
つまり、Web画面上の手がかりをユーザに認知させること。
ストーリーの概念としては、Call To Actionが大事で、たとえば、ボタンという機能を作り込むのが大事。

【2-3】ユセージ・ストーリーとは、顧客がステップごとに製品を使っていく物語。
Usage＝利用、使い方。

プロットポイントごとにユーザの実行動がマッピングされる。
カスタマージャーニーを構造化したもの。

ユセージ・ストーリーには、長い旅もあれば短い旅もある。
大冒険型ストーリーなのか、連続ドラマ型ストーリーなのか。
物語のスケールを決めるのが大事。

Core Task（＝Item）が中心になる。

クリフハンガーを解決するストーリーがテーマになる。
物語を視覚化すると、クリフハンガーがはっきりする。

たとえば、初期のTwitterはユーザ同士がつながるだけで、その利用シーンをユーザはイメージできず、クリフハンガーが発生していた。
そこで、ツイートしてメリットが出るユセージ・ストーリーを作り、それをTwitterの導線で実現することで、現在の爆発的な利用につながった。

【2-4】3パターンのストーリーのいずれもターゲットである顧客行動をKPIで計測する。
具体的には、SaaSであれば、Webログからユーザのアクセス履歴は全て追跡できる。

目的は、ストーリーの効果を測定すること。
クリフハンガーを特定し、ストーリーとWebシステムのギャップを探し出し、Webシステムを改良していく。

これにより、購入率やCVR、成約率を向上できるし、顧客満足度を高めることもできる。

【3】3つ目は、ストーリーマッピングの技法は、経営戦略の分析・策定や行動方針にも適用できること。

「ストーリーマッピングをはじめよう」にはいくつか例がある。
ギャップ分析では、ストーリーを使って、クリフハンガーや平坦な物語と、ユーザや企業が目標にたどり着ける物語の差（ギャップ）をクリフハンガーとして視覚化する。

Webシステムや製品に対し、ユーザの行動分析にストーリーを使って、ユーザがどのように利用しているのか、クラスタリングみたいに複数のユーザの特徴を洗い出す。
それにより、製品の改良に役立てる。

要件評価では、バックエンドのシステム要件、フロントエンドのシステム要件をストーリーマッピングで視覚化し、ストーリーを評価する。

SWOT分析では、カスタマージャーニーや製品のSWOT分析をストーリーで語らせる。
ストーリーマッピングにより、物語の全体像が視覚化できる以外に、足りない所、機能していない所、可能性が眠っている所を明確にできる。

【4】「ストーリーマッピングをはじめよう」を読んで改めて思い浮かぶことは、なぜ、ストーリーが要件定義や企画フェーズで重要な役割を果たすのか？　という問題だ。

ストーリーは実はロジカルに構成できるから。
実際、ストーリーという物語形式は、アリストテレスの悲劇論の歴史から始める三幕構成というロジカルな形式で表現される。
普通の日本人が思うような起承転結みたいな浅はかな構成ではない、と思う。

プロット (物語) - Wikipedia

ストーリーは課題解決に適用できるから。
課題解決の構造は物語の構造と一致している。
現状とあるべきゴールに対し、ギャップが問題として発生し、その問題を解決する。
状況設定の後、主人公が達成すべき目的となるインサイト・イベントが発生し、苦難の旅を経て、目的を解決する。

ストーリーは顧客から要件を引き出せる。
ITに詳しくない発注側のユーザ、情報システム部門から、要件を引き出したり、要件を議論するには、ストーリーで語ると共通理解が捗る。

ストーリーはKPIで測定できる。
WebシステムのKPIはAARRRの他にもたくさんある。

要件定義されたストーリーは、プロダクトバックログ（PBL）に蓄積される。
PBLから実際のリリース計画にマッピングする時には、ユーザーストーリーマッピングの技法を使えば、時系列と優先順位の表にユーザーストーリーをマッピングできる。
よって、ユーザ体験を重視したストーリーを実現するために必要な機能要件は、ユーザーストーリーマッピングの表から、MVPとなる対象機能を抽出でき、開発チームは、スプリントの襦袢に実装していけばいい。

こういう流れを理解すると、ストーリーによる要件定義はSaaSととても相性が良い。
そして、SaaSはアジャイル開発にピッタリのシステムであり、ビジネスモデルでもある。

昨今、DXが日本企業でも流行しているが、僕は、DXとは、ソフトウェア開発のビジネスモデルを持たないレガシー企業が、既存事業をSaaSとして展開するための仕組みづくり、と理解している。
従来のようなレガシーな基幹システムの開発スタイル、要件定義の手法とは、全く違うやり方ではないか、と考える。

このストーリーによる要件定義手法については、今後も色々考えてみる。

みんなのPython勉強会#65の感想～社会変革の鍵はIT技術者にあるのかもしれない

みんなのPython勉強会#65に初参加してみて、内容がとても良かった。
自分もPythonが理解できるようになったので、その意義がすごく理解できる。
社会変革の鍵はIT技術者にあるのかもしれない、と思った。
結論のないラフなメモ書き。

【参考】
みんなのPython勉強会#65 - connpass

セミナー参加ログ》みんなのPython勉強会#65 2021/1/13(水) 19:00?21:00（オンライン開催） - acokikoy's notes

【1】Pythonのビジネス、データサイエンティストの話、LT、そしてシビテックまで、幅広いテーマでとても興味深かった。
その中で、シビテックの話がとても興味を引いた。

シビテックは、プログラマが市民の立場で、政府や公共機関に出てくる問題をITで解決すること、と理解している。
関さんは、Coder fo japanというOSSコミュニティで活動されている。
東京のコロナ感染のWebサイト構築で一躍有名になった。

都内の最新感染動向 | 東京都 新型コロナウイルス感染症対策サイト

また、台湾のIT大臣のオードリーさんがGithubにプルリクを送ったことでも注目された。

ソフトウェアの政治的影響力とは何だろうか: プログラマの思索

関さんの話によると、日本では、2011年の東日本大震災の時にシビテックに関わるプログラマが増えて注目を浴びたらしい。
さらに、昨今のコロナ感染状況の期間で、関さんのいるSlackメンバーは、約4倍以上の人数に増えた、とのこと。
つまり、社会の危機的状況が、プログラマをシビテックに関与しようというモチベーションを与えているわけだ。

では、なぜそんな状況でプログラマは、シビテックに関わろうとするのか？
理由は色々あるだろう。
たぶん、人間としての生存本能が現れるのではないだろうか。

こういうOSSコミュニティは、IT技術者にとって、とてもメリットがある場だ。
理由は、自分とは違うバックグラウンドを持つ技術者と関係ができて、技術力もアップするし、視野も広がる。
講演では、東京のコロナ感染のWebサイトでは、色盲の人に優しいアクセシビリティを考えるべき、というプルリクもあって、非常に勉強になった、とのこと。

【2】講演後の質疑応答で気になったのは、シビテックが欧米と日本でどのような特徴の違いがあるのか、という話。

関さんによると、欧米人は自分の意見を持って自己主張する。
政府はこういう政策を取るべき、こういう行動を取るべき、とか。
一方、日本人は、自己主張しない代わりに、応援するタイプが多い。
良い政策があれば、それを後押しするように活動する。
言い換えれば、日本人はリーダーシップがなく、受け身の人が多いのだろう。

また、米国では行政府の人はリボルビングドア（回転ドア）なので、OSSコミュニティの人の中に、行政府に所属して働いた経験を持つ人が多い。
すると、行政の事情に詳しいので、行政のニーズをよく知っていたり、行政の人間関係や法律上の壁などの事情をよく知っている。
ゆえに、シビテックではそういう人たちと組むことで、より効果の出せるIT技術による解決策を提示できる。

一方、日本では、OSSコミュニティに行政に関係する人が少ないので、行政と連携しにくい。
プログラマもそういう行政の裏事情を知らないので、連携しづらい面がある。
しかし、東京の副都知事にヤフー経験者の人が入ったおかげで、東京ではシビテックが盛んになってきた、と。

また、行政はITに詳しくないので、ITに詳しい技術者やOSSコミュニティと関わりたいニーズはある。
特に最近は、デジタル庁を設立する話も出たし、農林水産省や経済産業省もIT技術者を募集する広告を見かけるようになってきた。
こういう危機的な状況だからこそ、IT技術者が求められているのだろう。

社会変革の鍵の一つに、IT技術者も含まれている。

【3】そういう講演を聞きながら、今のコロナ感染対策が難しい理由も素人ながら何となく想像できるようになってきた。
その理由は、コロナ感染という問題が影響する範囲が広すぎて、数多くの分野の専門家を集結させて、一貫した方針を打ち出す必要があるのに、どれが正解か分からないので対策を取るのが難しいからだろう。

たとえば、コロナ感染の新規感染者を予測し、政策に合わせてその精度を次々に手早く変更していくには、西浦先生のような疫学の専門家が必要だし、感染などの医療に詳しい医学者が必要。
しかし、彼らだけで問題を解決できるわけではない。

たとえば、ロックダウンにより経済的に困っている人たちへ給付する政策を実行して、人々にどういうインセンティブを持たせれば効果が上がるか、という行動経済学とか、財政出動とその効果を測定するには、マクロ経済学とか、そういう経済学の専門家も必要。
そして、そういう経済政策や医療政策を実行するための正統性を確保するために、新しい法律を整備する法律家も必要。

たとえば、コロナ感染者が増加している状況で、コロナ感染者をスマホで追跡・隔離したり、検査した情報をクラウドの基盤に蓄積したり、刻一刻と変わる情報をWebサイトで収集・公開したり、各人に適切な給付金を配布するための一連の仕組みをWebシステムで構築したりするには、専門のIT技術者が多数必要になる。

つまり、それぞれの分野で一流の人を集めて、彼らを的確にアサインし、振ってくる問題をさばいていくことが求められる。
そういうことを実施する時、トップが全ての分野に精通して理解できるのは難しいだろう。
トップは全ての分野に精通した専門家ではないのだから。

では、そういうチームを編成して、問題を一つずつ解決していくことを成し遂げるには、何が必要なのだろう？？
専門家でもないリーダーには、どんなスキルが求められるのだろうか？
どんなリーダーシップを発揮したら、問題となる状況を解決できるのだろうか？

何故ファシリテーションが流行しているのか？: プログラマの思索

管理職に求められる能力はPM理論そのものではなかったのか

管理職に求められる能力の記事を読んでいたら、三隅二不二のPM理論そのものではないか、と感じた。
ラフなメモ書き。
浅い考えなので後で直す。

【参考】
管理職に求められるものとは─新世代リーダーへの条件─（前編）【ONE JAPAN CONFERENCE 2020レポート：PEOPLE④】｜ONE JAPAN｜note

(3) akipiiさんはTwitterを使っています 「これって、昔のPM理論そのままじゃないか！管理職の職能は不変なんだなと思った。“管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。” 管理職に求められるものとは─新世代リーダーへの条件─（前編）【ONE JAPAN CONFERENCE 2020レポート：】https://t.co/XFNjuiTutr」 / Twitter

【1】（引用開始）
基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。パフォーマンスとは、部門の業績を管理することで、メンテナンスはそのために多様なメンバーをマネジメントすることです。

しかし、管理職は組織の中間点にいるので、この2つに加えてダイバーシティや働き方改革、DX（デジタル・トランスフォーメーション）などあらゆる組織の問題が、すべて管理職にしわ寄せが来てしまっています。

さらに経営層からは、新規事業や新しい価値を作ってくれとオーダーされたり、現有の戦力の中で、多様な部下の強みを引き出して、なるべく早く革新的な成果を、しかもリモートで出してくれと命じられています。
（引用終了）

「基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンス」ということは、まさにPM理論そのままだなと思う。
成果を求めるパフォーマンス（P）と、チームビルディングなどのメンテナンス（M）の２つ。

PM理論 ? リーダーシップインサイト

PM理論by三隅二不二 | EARTHSHIP CONSULTING

PM理論とは ～理論から理解するリーダーシップとその変遷～｜人材育成・社員研修｜ラーニングエージェンシー

【2】そう言えば、PM理論は別名、パパママ理論とも呼ばれるらしい。
「業績：目標達成機能」（Performance)はパパ、「維持：集団維持機能」（Maintenance)はママに相当するように覚えると理解しやすかった。

（引用開始）
当時はまだまだ男が稼いで奥さんが家を守るという雰囲気の世の中だったので、このPM理論はパパ・ママ理論とも呼ばれ、厳しく子どもを育てるお父さんと、子どもの気持ちに寄り添うお母さんのイメージをあてて、このPM理論を説明していた。
（引用終了）

【研究ノート１】リーダーシップ理論（その１）「PM理論」｜鈴木康宏｜note

【3】「管理職に求められる能力はPM理論そのもの」という意見から気づいたことは3つある。

1つ目は、リーダーシップには成果（P）を求められること。
「採用基準」本に「リーダーシップとは成果を求めること」というフレーズがあったが、たぶんそのことを指しているのだろう。
問題解決のためには、リーダーシップを発揮して、周囲を巻き込みながら、あるべきゴールへ到達するルートをとにかく進んでたどり着く。
まずはそういうスキルがなければ、話にならない。

2つ目は、ファシリテーション能力が10年以上前から重視されている理由は、メンテナンス機能の特徴の一つであること、そして、リーダーシップを補完する機能であるためだろう。
管理職に成り立てのマネージャは、部下に仕事を回すよりも自分でやった方が速いので、どうしてもマイクロマネジメントになりがち。
そういう時に、プロジェクトファシリテーションのようなスキルがあると、結果を出すチームを形成できるようになる。
スクラムマスターという役割も、メンテナンス機能を重視しているのではないか、と思う。

3つ目は、上記の記事では、管理職には新規事業を提案することまで求められてはいない、と記載されていたが、優秀な中間管理職ほど、新しい事業アイデアを実現したくてウズウズしている。
誰だって、上から言われた仕事をそのままやるのがモチベーションではない。
自分で実現したいアイデアや夢があって、それが会社の方向性と一致していれば、やる気も上がるし、そうなるように仕向けたいと思うからこそ、職務や権限を利用して動く。

特に、日本の組織では、名君と言われる経営トップは必ず、優秀な中間管理職をブレーンとして持ち、自由に采配が振れるように配慮してくれるものだろう。
たとえば、幕末から明治維新の頃は、薩長の下級武士がそういうトップに引き立てられて、彼らが原動力となって時代を変えていったように。
たぶん、日本は、経営トップが独裁的に振る舞うような欧米・中国のやり方ではなく、中間層のリーダーがリーダーシップを発揮するような、そういう組織文化なのだろう、と思う。

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

Pythonデータ分析試験、Python基礎エンジニア試験に無事に合格できた。
感想をラフなメモ。

【参考】
Pythonデータ分析試験 | 一般社団法人Pythonエンジニア育成推進協会

Python基礎試験 | 一般社団法人Pythonエンジニア育成推進協会

【1】Python基礎エンジニア試験は簡単だったが、Pythonデータ分析試験は難しかった。

Python基礎エンジニア試験は、RubyやJavaを知っていれば、それら言語のライブラリを比較しながら理解すれば良かった。
Pythonは確かに書きやすい。
Rubyのように異音同義語のようなAPIはないし、文法も簡素だし、Tabのインデントだけでプログラミングできるので、手に馴染む。

しかし、Pythonデータ分析試験では、Numpy・Pandas・MatplotLib・sklearnの割とたくさんのAPIを覚える必要があるし、統計学や線形代数の数学の知識、分類・回帰・次元削減・クラスタリングなどの機械学習の知識も必要になるので、Python以外の知識習得に手間取った。
統計検定2級、G検定も取得していたので、それらの知識に慣れているから1ヶ月で十分だろう、と思ったが、実際は2ヶ月以上習得にかかった。
まだまだ、Pythonのセンスが足りないので勉強すべきと分かった。

なお、Python基礎エンジニア試験の教科書「Pythonチュートリアル 第3版」、Pythonデータ分析試験の教科書「Pythonによるあたらしいデータ分析の教科書」は持っておいた方がいい。
このAPIはどうだったけ？と振り返る時に、辞書代わりになる。

【2】Python基礎エンジニア試験、Pythonデータ分析試験で良かったのは、Web上の模擬問題が充実していること。

PRIME STUDY（プライム・スタディ） ? Python試験とPHP試験の無料模擬試験サイト

G検定、Python、Rubyの模擬テスト | DIVE INTO EXAM

上記のWeb問題を5～10回転ぐらいやって100％得点できてから受験したので、そんなに緊張感はなかった。
特に、PRIME STUDYの問題の方が確かに難しかったけれど、出題内容は「Pythonによるあたらしいデータ分析の教科書」と全く同じなので、理解に役立った。

【3】Pythonデータ分析試験、Python基礎エンジニア試験を良かったことは、3つある。

【3-1】プログラミングはブロックを組み立てる感覚が大切、と改めて感じたこと。

Python 初心者だから、Numpy、Pandas、Matplotlib、sklearnのAPIでつまづいてるけど、機械学習は面白い。
教師ありデータなら、train_test_splitして、機械学習のモデルにfitで学習させて、scoreで評価し、最後にpredictで予測する。
実際は、そういうデータの前処理に大量のロジックを組み込むわけだが。

すると、1行でもロジックというブロックが崩れると、プログラムは意図通りに動かなくなる。
ちょうど、積み木の途中で1個のブロックが崩れると、全てが崩れてしまうみたいな感じ。
プログラミングはとても繊細な作業。

プログラミングが書けるかどうかは、そういうセンスに依存する所も大きいと思う。

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

【3-2】プログラミングは書くだけでなく、開発環境も大事、と改めて感じたこと。

Pythonが良いのは、Anacondaで一通りのライブラリが揃い、ライブラリのバージョンごとに依存した開発環境を別々に保持できること。
一方、RubyならGemのバージョン依存にすごく手間取るし、Ruby初心者はRailsの環境構築ですぐにつまずいてしまう悲しさがあると思う。

また、PyCharmという開発環境がとても良い。
コード補完できて、デバッグもできるので、プログラミングにストレスがない。
一方、コンソール画面で対話形式でPythonをプログラミングできるよ、ブラウザ上でJupytorNotebookでグラフも書けるよ、と言われても、やっぱりコード補完できないのは辛い。

僕は、IntelliJの有償ライセンスを購入したので、JupytorNotebook上でもコード補完もデバッグもできて、ああ、こういう風に動いてるのか、とか、初心者レベルからの気づきがあった。
プログラミング初心者はこういうつまらないレベルでつまずいて、先に行けなくなるから。

DockerやAnsibleの考え方もそこに通じているのではないか、と思う。

【3-3】Pythonを通じて、最先端の技術に簡単にたどり着けること。

線形代数や微積分、統計学の数学の知識は、それがなくても、Pythonを書きながら慣れていけばいい。
Numpyのブロードキャストやユニバーサルファンクションに慣れれば、自然に線形代数は理解できるはず。
統計量の計算、データの前処理となる分散正規化、ヒストグラムで表示する前処理となる層化抽出法、などは、PandasやMatplotLib、sklearnに慣れれば、理解できるはず。
sklearnのSGDライブラリを使いこなせれば、微積分の考え方も分かるはず。
もちろん、「ゼロから始めるディープラーニング」のサンプルプログラムを動かしながら慣れていけば、ディープラーニングだけでなく、微分における極小値や最小値の違い、鞍点のイメージも理解できるはず。

つまり、Pythonの機械学習ライブラリを使いこなせるようになれば、自然に、統計学・線形代数・微積分の知識も身につくはずだ。
紙と鉛筆で計算することも大事だが、プログラミングでは、要は動かしてナンボの世界だから。

そして、今のIT技術の最先端に一度到達できれば、他の分野でも、初心者レベルから今の自分のレベルまでに到達するにはどれくらいの道のりが必要なのか、そこから先にはどんな課題が控えているのか、を想像できるようになる。
そうすれば、すごく楽しくなる。

おかげで、Pythonの機械学習や深層学習の本が読めるようになってきたので、乱読できるのがすごく楽しい。
まずは「Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎」から読み始めていて、今頃になって、そういう意味だったのか、とか色々気づきがあった。

【4】Pythonの機械学習や深層学習ライブラリを覚えた後で、やりたいことは、目の前の問題事象に対し、原因とその予測を見つける因果推論ではないか。

100件以上のデータがあれば、分類モデルや回帰モデルで簡単にモデルを試せて、やりたい問題が解けるのに感激した。
最終的にやりたいのは、目の前の問題やイベントに対して、誰も見つけなかった因果関係の発掘だよな、と思う。

Python でプログラムを書ければ、誰でも新しい因果関係を発見して、経験則と言う法則を作り出せる。
たとえば、行動経済学や公共経済学であれば、こういう政策を政府が提示した場合、国民の消費活動や企業の生産活動はどう予測されるか、などの問題も、スマホやWebで収集した大量データをクラウド上に集めて、機械学習や深層学習のエンジンでモデルを学習させれば、その結果を予測することもできる。
つまり、回帰分析のように、予測したい目的変数に対し、有意な説明変数を見つけることで、単に相関関係を見つけるだけででなく、AならばBとなる、といった因果推論まで提示できるはず。

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

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

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

社会現象や人間の心理に対し、こういう因果推論を経験則、法則として数多く見出すことができれば、それらは一つの規範を示す。
つまり、哲学の言う、ザイン（である・存在）ではなく、ゾルレン（かくあるべし・規範）を学問として提示できるはず。
最終的には、全ての文系学問の出てくる諸問題は、統計確率論を基盤としたPythonの機械学習や深層学習で実装されたモデルから導かれる規範を樹形図のように整理するだけで、自然科学の中の一つの学問分野に収斂されるのではないだろうか。

こういう技術が直近10年で当たり前になったのもすごいし、こういう技術を知らずに、今までの知識や技術に固執するのも一つのリスクだな、と思う。