shine-Notes

ゆるふわ思考ダンプ

冒険の書 AI時代のアンラーニング を読み、学びの過程に思いを馳せる

ITエンジニア本大賞2024(https://www.shoeisha.co.jp/campaign/award/vote)にノミネートされていたのを切っ掛けに、「冒険の書 AI時代のアンラーニング」を読んだので、読書ノートを残す。面白くも色々考えてしまう本だった。

bookplus.nikkei.com

サマリ

  • 歴史を紐解けば、学校教育や能力評価など教育において当たり前だと思っているものは、時代性に依るもので普遍真理的なものではない。
  • 申し子とも言えるAIの発展を考えれば、メリトクラシーはナンセンス。問いを立てて、楽しいと思ったことを学ぶべき。問いは普遍。

書籍について

一言で言えば、「アンラーニング」のための問いを読者に起こさせるための、著者からのメッセージ本だ。ジャンル的には自己啓発書だが、「学び」とくに最初は「学校教育」にフォーカスして、どういった歴史で現状に行き着いたものなのかを紐解いて進めていくところは人文学的で楽しい。ホッブズフーコー、ロック、ルソーなど、過去の思想家たちが主人公(著者)と対話する物語形式で喋り始める。自分は学生時代の専攻が人文系なので「言ってた言ってた」みたいな楽しさも有るのだが、一貫して章ごとの「なんで学校ってあるんだ?」「なぜ子どもと大人は区別されるんだ?」「そもそもなぜ学ぶんだ?」などの問いに紐づける形で引用されていくので、各人の事を知らなくても理解しやすい。

何より素晴らしいなと思うのは、本書の冒険と姿勢そのものが、「問いを立てて探求していくことが重要」という著者の帰結そのものの実践になっているところ。もちろん著者は自分の考え方も主張する(時には「本当にそうだろうか」と思うものもある)。けれど巻末に添えられたインデックスは各章の「〜すべき、〜しよう」ではなく「なぜ**は**なのか?」が並んでいて、一貫性を感じる。

取り上げきれないが、自分が印象に残った内容は以下のあたり。

なぜ学校の勉強は楽しくないのか?

  • いつのまに私達は教育サービスのお客さんになっている。
  • そもそも「ある程度の人数を教室に集めて教育する」という手法そのものが200年前の工場の分業システム由来のもの
  • 社会の仕組みに合わせて能力を身につけるための場所にした結果、学校はパノプティコンのようになってしまった。

後述の通り自分も学校現場には少しだけ縁があるので、頷くところも多かった。

メリトクラシーのなにが問題なのか?

  • 能力主義(メリトクラシー)の害悪。能力(才能)が有るから良い成果が出た、というのは結果論。「特定の能力を高めれば良い結果が出るだろう」という部分は信仰でしかない。
  • 基礎→応用という捉え方も結果論でしかない。むしろ応用→基礎だろう。
  • AIはメリトクラシーの申し子で、人間が特定の「能力」を伸ばしても

このあたりの内容はITエンジニアと相性が良い話題だと思う。たとえばCS基礎の薄い若手に実装スキルを習得してほしいとき、言語の教科書的なものを1から積み上げるアプローチよりも、なにか決まったトイプロブレムを解決するものを作ることをお題にして、作りながら調べたり、作り終わってから基礎に戻ってもらうほうが結局吸収が早かった、みたいな現象を自分も何度も観測している。

少し個人的な感想

そんな感じで面白く読めたのだが、実際のところ読みながら、自分の体験や、そこから来る問いに思いを馳せることも多かった。これこそが題名に有る「アンラーニング」の意図する所だとは思う。せっかくなので思ったことをチラシの裏までに書いておく。

教壇から問いを投げることの難しさ

自分は教職者として勤務したことはないが、教育実習で高校現代文の授業をやったことがある(要ははペーパーだ)。指導教員にも言われ挑戦したけれど、実習中に結局体得しきれなかったのは、「生徒に問いを投げる」という技術だった。

自分が教える側になり、その後テストを作り問いてもらう立場を想像してほしい。一番楽なのは「用意した質問と回答をセットで生徒に伝えてしまう」授業だ。ただ、これだと生徒は授業に関心を向けないし、自分で用意した質問以外の応用的な問いに答える能力は身につかない。そこで有効なのが「問いを投げて考えさせる」というプロセスになる。だが、これを授業で実際にやると、多人数を相手に、予想外の回答から話題の舵を取る必要がある。これが結構難しい。結局実習では、学生から面白い回答があってもうまく掘り下げられず、自分の用意したレールに強引に乗せて進めた記憶がある。このあたり、現役の先生も皆できているかと言うと、実は皆できているわけでもなかったりする(そもそも暗記系の科目だと、一方的に喋るだけの授業とかも多い)。ただ当時見学させていただいた先輩教員の中で、驚くほど問いかけの展開が上手いベテラン先生も居たことは鮮烈に覚えている。なので技術とその気があればできることでは有るのだろう。

本書では現在の学校教育に対する批評も多く、読みながら「学校教育のどこがダメなんだろう」という事を自分はずっと考えていた。その中でこの時の記憶を思い出しながら、1つ「そもそも現代の学校教育の授業スタイルだと『問いを投げる』事にインセンティブが働きにくいのかも」と思ったりした。教員も感覚としては「問いを投げる」ことの重要性は理解しているのだが、それこそ基礎→応用の積み上げで能力開発をしていく前提のカリキュラムと授業では、ここに時間を割くことができない。結果として授業は「聞くだけのもの」になる。まさに本書で批判しているような「学校教育」がそれだ。

色々と考えたあとで自分自身を省みたとき、確かに今でも学んだことが活きたり学び続けられている分野の殆どは(「学校の授業」ではなく)本書で言うような「自分が夢中になって勝手に学んだ」ものだけだったので、さもありなんという感想を持ったのだった。

おそらくソフトウェアアーキテクトではない人間が「ソフトウェアアーキテクチャの基礎」を読んだ感想

という訳で、読書ノートである。書籍の紹介と自分のチラ裏ポエムを兼用する形でポストしていく。

www.oreilly.co.jp

サマリ

書籍の感想

3部24章。読んでいる途中で「これは本当に基礎なのか?」と思いつつ、読み終わってから「いや、確かに基礎だ」と思い直した。この場合の基礎というのは「簡単」「入門」からは少し遠い単語ベクトルであって、「実務を抽象化して理解し実践するための前提知識全部」という感じ。

「ソフトウェアアーキテクチャ」自体の定義が難しいことは本書でも語られている。その上で本書はⅢ部構成をとって、第Ⅰ部でソフトウェアアーキテクチャを考える上でのメタ的な基礎、第Ⅱ部では実際に存在するソフトウェアアーキテクチャのスタイル、第Ⅲ部ではソフトウェアアーキテクチャをソフトウェアアーキテクトとして決めていくためのテクニックが紹介されている。

当たり前だが「ソフトウェアアーキテクト」というロールは「ソフトウェアアーキテクチャの基礎」とは切っても切り離せない。本書は勿論ソフトウェアアーキテクトに対するガイドとしても書かれている。

面白かったポイント

いったん個人的な感想ポエムは後半に追いやり、読書ノート的に面白かったポイントを書き記していく。だいぶ絞ったが多くなってしまった。ここに書かれている内容に少しでも「お?」となるなら本書を読む価値はあるだろう。

  • (22.1)ソフトウェアアーキテクトの役割は、開発者のためのちょうどいい箱(制約の境界)を作ることである。
  • (1.2.1)アーキテクトに期待されている役割において重要なのは「ガイドする」ことだ。チームの技術的な選択を「指定」するのではなく「ガイド」しなければならない。

本当にそう。指定するだけでなくガイドする役割がないと形にならない。

  • (1.4)ソフトウェアアーキテクチャトレードオフが全てだ。そして「どうやって」よりも「なぜ」のほうが重要だ。
  • (19.3)ADR(Architechture Decision Records)を使ってアーキテクチャ決定の経緯(「なぜ」)を記録する。
  • (21.2.2)プレゼンテーションにおけるアンチパターン、蜂の巣にされた死体
  • (21.2.3)インフォデッキとプレゼンテーションは異なる。

ドキュメント系。最近「なぜ」を示すためのインフォデッキを意識的に作る事が増えたのだが、実際に効果を感じている。

  • (4.0)ドメインの機能に直接関連しないが満たさなければいけないアーキテクチャ特性(-ity)を見つけるのもソフトウェアアーキテクトの仕事。非機能要件とも呼ばれる。
  • (5.1)アーキテクチャ特性はドメインの関心ごとから導き出し、何が最も重要なのかを見極める必要がある。
  • (4.1.3)アーキテクチャ特性とはチームでユニークなものになりうる。「イタリアでつながる?」という問いかけの繰り返しからイタリア性(Italiality)というアーキテクチャ特性が筆者のチームには生まれたことが有る。

いわゆる非機能要件は暗黙的かつ優先度を付けるしか無いもの。わかる。

  • (3.2.5.3)動的なコナーセンスを静的なコナーセンスへリファクタしよう。静的なコナーセンスは解析ツールで改善できる。
  • (8.2.1)レイヤードアーキテクチャは、アーキテクチャの技術による最上位分割の例。ドメインによる分割が最上位になる場合もある。
  • (9.2.4)分散アーキテクチャを採用した時に忘れてはいけないこと。ネットワークは安全…ではない。

ノウハウ系。わかる。PaaSを組み合わせたようなアーキテクチャを組むようになってからネットワークを意識することが増えた。

  • (23.2.3)アーキテクトと開発者の会話。「〜すべきです」ではなく「〜はどうでした?」で主導権を渡す。
  • (2.5)アーキテクトが現場感を持ち続けるためのテクニック。プロダクションレベルのPoCコードを書く、技術的負債やアーキテクチャに関わるユーザーストーリーを引き受ける、バグ修正を引き受ける
  • (23.3)開発チームを軌道に乗せるためのテクニックの1つは、開発者が招集されたMTGに変わりに出席すること。

ソフトスキル系。わかる。それ故にソフトウェアアーキテクトは実装する機会が減っていく…

これは本当にそう。個人的には哲学とかの人文系と一緒で、コンテキストが無いと何故そうなったのかが理解しづらかったりする。

より個人的な感想

近年の自分はざっくり、小さなB2BプロダクトのPdMっぽい仕事をやっている。といいつつ何でもやるのでMVPを作ることも有るし「今回の構成ならDBはPaaSに任せるか、いやそもそもRDB要らないかな?」みたいな判断はやることがある。

そんな感じなのだが、実は自覚的にソフトウェアアーキテクチャを選択してきたことは少ない気がする。ある程度チーム内で実績のあるカタ(型)を基本にして「次はこれやってみるか」で時折新しいものに手を伸ばすことが多かった。なんならパッケージ製品をやっていた頃は、最初からある程度パッケージ側でアーキテクチャが決まっていて、表面化している非機能要件だけを拾ってすり合わせするような仕事も多かった。実はそういう現場も世の中には結構あるのではないかと思っている。

ソフトウェアアーキテクチャの選択に大して常に自覚的でいられるか

最近は幸い「顧客にこの機能を使ってもらうために、ここをこうして非同期にしたい」みたいな議論をすることが増えたので、本書の内容は自分が何を意識すべきなのか、を再認識できた。いっぽうで思い返してみればアーキテクチャの選択そのものは今までのキャリアでも何度も有った訳で、今までその選択に自覚的でなかったのかもしれない、というのも本書を読んだ気付きだった。

MLflow+Airflowでざっくり実験管理の仕組みを作り、Docker-composeでまとめる

サマリ

  • MLDP(後述)を読んだ流れでMLOps系のライブラリが気になり、手始めにMLflowを動かすことにした
  • どうせなので、データ取得からモデル訓練、評価までの一連を全部動かせる仕組みをDocker-composeにまとめることにした
  • 特異性が有ることをやった訳でもないが、それなりに勉強になったので記録を残す。
続きを読む

Rust(Rocket+Diesel)でsqliteのテーブルにCRUDするだけのAPIサーバを作る

サマリ

  • Rustへの習熟がてら、フレームワーク(Rocket)を使って簡単なAPIサーバを書いた
  • 自分の普段使わない言語(Rust)で、自分の親しんでいるエリア(Webフレームワーク)を書いてみるのも勉強になる
続きを読む

Vue.jsでCloud NLPにPOSTするだけの画面を作り、Firebase Hostingに載せる

サマリ

  • Vue.js入門のため、APIへのPOSTを行う簡単な画面を作った
  • ズブの素人スタートの速習だが、色々と学ぶところがあり面白かった
続きを読む