はじめに
「AI時代「考える力」をどう鍛える？具体抽象トレーニング」という勉強会に参加してきました！
そこで感じたことや気づいたことがあるので書きたいと思います。
気づき
マジックミラー効果
マジックミラー効果とは、抽象側からは具体側が見えるが、具体側からは抽象側が見えないという状態を表す比喩のことです。
三平方の定理から斜辺の長さを求めることができても、
⭕️ $a^2 + b^2 = c^2 \rightarrow 3^2 + 4^2 = 5^2$
長さから三平方の定理を導くことはできません。
❌ $3^2 + 4^2 = 5^2 \rightarrow a^2 + b^2 = c^2$
マジックミラー効果を知ったあと、過去のことを振り返ってみるとマジックミラーになっている状況がいくつかありました。
塾バイトでのマジックミラー効果
塾バイトでは、抽象側が校舎長、具体側がバイトです。
抽象側からは塾全体でどんな仕事があって、どんなトラブルが起こりうるか、どんな仕事の割り振りが効率的かが見えています。
バイト側は目の前の仕事を完了させることしか知りません。
ある一人のアルバイトがシフト提出をし忘れて全体のシフト確定が遅れたり、講師間でシフト交代のやり取りをしてしまったせいで校舎長が把握できず、すれ違いが起きたりしていました。
エンジニアの長期インターンでのマジックミラー効果
長期インターンでは、抽象側がチームリーダー、具体側がインターンの私です。
自分では合っていると確信していた方針だったので確認せず進めたが実際には間違っていたため、あとからrevertしなくてはならなくなり、手戻りが発生しました。
具体側しか見えてなかったとしても、この構造を意識しているだけで報連相とか何かしらの対策はできると思いました。
SIerの下請け
SIerは多重下請け構造といって、受注したものを作るために下請けに仕事を振ります。その下請けはさらに下請けに仕事を振り、3次、4次と続くことになります。
その場合、3, 4次の意見は元請けに届かないことが多いようです。つまり末端の下請けはクリエイティビティを発揮しづらいコードを書くだけの仕事になります。
私は、創造性とかよりもコードを書くこと自体に興味ややりがいを感じているのでそれが悪いとは思いませんが、AI（もしくは他の会社）に取って代わられやすいとは思いました。なぜなら、元請けがやろうとしていることを達成するための手段でしかないからです。
なので、設計などの抽象度が高い部分に関しても学習していきたいと思っています。
また、「システム開発におけるAIツールや言語」、「OSI基本参照モデルにおけるL7」、「クリーンアーキテクチャにおけるdriver」など置き換わりやすい具体の部分は「置き換わりやすい」と認識した上で学習なり開発なりを進めるべきだと感じました。
例えばClaude, Codexの使い方、TypeScript, Pythonの言語仕様などに時間を割いたとしてもそれらのツールが使われなくなれば無駄になるからです。
アウトプットの重要性
この勉強会ではアウトプットする機会がたくさんありました。ワークごとにシェアする時間が設けられていたり、スピーカーの方の言葉を復唱する流れがあったりと。
実際に、そこでシェアした内容や復習した内容は不思議なことに、あとからでも思い出せるくらい頭に残っています。中学、高校での社会の授業は何も覚えていません。当時でも思い出せなかったと思います。これは今振り返ってみればアウトプットがない、インプットだけの授業だったからでした。
毎度のことですが、改めてアウトプットの重要性を感じました。
おわりに
いろいろと感じることが多く、うまくまとまっていないですが、とにかく抽象度の高い部分を意識的に学んでいくこと、マジックミラーの向こう側の存在を知覚することが大切だと思っています。