AIに関するアドバイスや教材のほとんどは、より良いアウトプットを高速で得るための方法を教えています。しかし、AIを単なる生産性向上ツールとして扱うことは本質を見失っているとして、イギリスのエディンバラ・ネピア大学で創造教育学教授を務めるサム・イリングワース氏が、本当に重要なAIリテラシーについて解説しました。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
AIについては「どうやってAIを使うのか？」「どうすればより高速なアウトプットが得られるのか？」といった点ばかりが注目されがちです。しかしイリングワース氏は、「そもそもAIを使うべきなのか？」「AIを使うことで何が失われるのか？」という点だと指摘しています。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
イリングワース氏はAIとどのように効果的かつ倫理的に関わるべきかを探求するコミュニティ・Slow AIを運営しています。現在のAI開発は、人々がより速く動いて思考を減らし、AIの出力をデフォルトのものとして受け入れることを前提としていますが、イリングワース氏は「批判的AIリテラシー」を磨いてこの流れに抵抗することを推奨しています。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
一部のAI擁護派はAI反対派について、19世紀イギリスで労働者階級が織機を破壊したラッダイト運動になぞらえて批判しています。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
これに対しイリングワース氏は、ラッダイト運動は進歩そのものに抵抗したのではなく、自動化による職人技の消滅や搾取といった社会的損失から自らの生活を守ろうとしたのだと指摘。ラッダイト運動に参加した人々はテクノロジーそのものを拒絶したのではなく、「無批判なテクノロジーの導入」を批判したのであり、批判的なAIリテラシーはこの識別力を取り戻すことにつながるとしています。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
すでにAIによる意思決定は雇用・医療・教育・司法といった分野に影響を与えていますが、これらの分野で使われるAIシステムを批判的に評価する枠組みがなければ、人間側にも限界がわからないアルゴリズムに重要な判断を委ねることになってしまいます。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
イリングワース氏は、「結局のところ批判的AIリテラシーとは、プロンプトを習得したりワークフローを最適化したりすることではありません。AIを使うべき時と、絶対にAIへ手を出すべきではない時を見極めることなのです」と述べました。
AIについて考えるべきは「AIをどう使うか？」ではなく「AIを使うべき場面かどうか」という点だとの主張 - GIGAZINE
⇧ これまで何度も繰り返されてきたと思うのだが、「業務」の棚卸が必要ということですかな。
我輩のブログでも、度々、繰り返してきたのですが、
- 全てAIに任すことのできる業務
- AIと人の協業が必要な業務
- 全て人でないと実現できない業務
といった「業務」の洗い出し、分類が完了して初めて「AI」を導入するかどうかの議論に入れる気はしますがね...
最終的に、「社会課題」を解決する際に「AI」の導入が効果的であるのならば、「AI」を導入すれば良い気はしますが...
勿論、「AI」を導入することにより発生するであろう「トレードオフ」に関する「情報」はドキュメント化して、全ての「ステークホルダー」で認識共有できる状態にしておく必要はあると思いますが...
まぁ、何某かの「課題解決」に役立つのであれば、「AI」の導入はやぶさかではないと感じてしまうのは、「エンジニア」という職業病なのだろうか...
全ての「エンジニア」に当てはまるのかは分からないのだが、楽したいのよ...
とりあえず、
プログラマの三大美徳
プログラミング言語「Perl」開発者のラリー・ウォールによれば、プログラマの三大美徳とは「Laziness」「Impatience」「Hubris」である。様々な解釈がなされているがラリーの著書「プログラミングPerl」の第2版では次の通りに解説されている。
- 怠惰（Laziness）:自身、そして他者の労力を削減するための労力を惜しまない。再利用性の高いコードを書き、ドキュメントを残し他者からの質疑応答の無駄を省く
- 短気（Impatience）：コンピュータシステムの怠惰さに怒り、これに対し事前に予測もしくは予測していたように振舞う
- 傲慢（Hubris）：他者が苦言を述べる事が出来ない程の高品質のプログラミングと、それを維持しようとする心
⇧ 上記の「プログラマの三大美徳」にあるように、「認識共有」の「コスト」を減らすために、理解に苦しむことの無い「ドキュメント化」を習慣付けることが大事ということでしょうかね...
結局のところ、人は1人で生きているわけでは無いので、他者と円滑に協業するためには、他者のことを考慮する心持ちが不可欠な気はするのですよね...
まぁ、全てを「自給自足」で生活するというのであれば、ご自由にしてくださいとしか言えませんが...
全体設計の理想と現場の乖離。設計のメンテナンスがされていないので...
最近、
を読み始めたのですが、著者の方がブログを公開してくれており、
⇧ 上記によりますと、土台となる「テクノロジーアーキテクチャ（TA：Technology Architecutre）」に関して、最も「変化」の「頻度」が高くなるというこの模様。
で、実際の「ソフトウェア開発」の現場において、「環境構築」が「自動化」されていないような場合に、「構築手順」を元に「インフラレイヤー」部分の「構築」を進める必要が出てくるのだが、往々にして「メンテナンス」されていないことあるあるですと...
つまり、「構築手順」も「設計」の内の1つだと思うのだが、「設計」が「メンテナンス」されていないことによる「負債」を解消しなければ、「開発」の「スタートライン」にも立てないわけなのだが、「負債」の解消は評価されないのよね...
全くもって「モチベーション」は上がらず、「ストレス」が蓄積されていくだけの不毛な作業なのよね...
というわけで、「設計」の「メンテナンス」が重要と言う話でした。
つまり、「設計」の「情報」が「信頼できる唯一の情報源（SSOT：Single Source of Truth）」になっていない状況というのは、所謂、「設計」の「メンテナンス」を放置された状態かどうかを判断するにも認知的負荷がかかり、必要な「情報」を集めるにも工数がかかりますと。
故に、「設計」の「メンテナンス」を放置しているなという心当たりのある方は、今日から、
- 設計のメンテナンスの対応ができない場合
- メモ（TODO）を残して、どこまでが情報として活きているのかが分かるようにしておき、後進の方が困らないように配慮しよう
- 設計のメンテナンスの対応ができる場合
- 後進の方が困らないように情報の変更対応とレビューを実施し、あるべき姿を保つようにしよう
を実践する習慣を持って欲しいものです...
いやはや、「カオス」な状態の「設計」を丸投げされて苦労した体験をしたことが1度でもあれば、「メンテナンス」して後進の方が困らないようにしようという行動を取ろうという気に自然となるように思うのだが...
今日も今日とて、前任者が放置した「負債」の解消に時間が費やされるのであった...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
