ソフトウェア

2021/03/02

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

今夜、ガバテックの話をZoomで聞いていた。
話は面白かったが、色々考えさられた。
考えたことをラフなメモ書き。

【参考】
経済産業省デジタル化推進マネージャーと弁護士ドットコムが語る!行政にエンジニアが関わる意義 - connpass

【1】政府行政をエンジニアが関わって、DXを推進していくのがガバテックと言えるかもしれない。
パネラーが言うように、今まさに旬のテーマ。
デジタル庁ができるし、ITエンジニアがより政治に関わっていくこともできる。

パネラーは、エンジニアリングで社会実装を変えていく、と言っていたが、話を聞いていたら、僕は「プログラマとスクラムが社会実装を変えていく」という意見を持った。

理由は2つある。

【1-1】1つ目は、プログラマが政府行政のIT化で活躍できる場がすごく多く、昔から受け継がれる問題、今まさに直面している問題に対し、プログラマしか解決できないテーマが多すぎるから。

たとえば、コロナワクチン接種管理システムの構築もそうだし、コロナ不況で失業したり、緊急事態宣言でビジネスを制限された人達に補助金を出すシステムもそう。
こういうシステムが必要とされているのに、インフラ構築できない、Webシステムを構築できない、業務要件をデータモデリングでまとめられない状況にある。
政府行政にいる人達は、ITの専門家ではないのだから、そういう技術に詳しくないのは当然だ。
だからこそ、ITエンジニアがより深く関わるチャンスがあるし、それによって、社会を変革していく道筋も生まれる。

ハンコ押印を使った各種申請、税金の支払いが楽になるだけでなく、より積極的に、ITという手段を通じて、政府を通じて世の中をより良くしていく、という活動にコミットできるわけだ。

【1-2】2つ目は、プログラマが政府行政のIT化に関わっていく場合、組織体制はスクラムに即した体制にならざるを得ない印象を持ったから。
パネラーが言うには、政府行政で、パネラーに協力してくれる人達は、事実上、プロダクトオーナーの役割を担ったり、色んな部署と調整したり、逆にパネラーのようなITエンジニアを守ってくれるような活動をしてくれたらしい。
パネラーのようなITエンジニアと政府行政の人達の間に信頼関係が構築できたことで、より深くコミットすることもできた、と。

そういう話を聞くと、まさに、そういう組織体制はスクラムで実装することになるだろう、と思う。
なぜならば、スクラムを適用すれば、スクラムの3つの役割にピッタリ当てはまるからだ。

【1-3】国民の公共サービスの利便性を提供するようなサービスを提供するケースを考えよう。
すると、そのような業務要件を考えるプロダクトオーナーが必要であり、政府行政の業務や法律に詳しい、政府行政の人達自身が担当する。
インフラを構築したり、システムを実装したり、セキュリティ対策を考える人達は、各分野のITエンジニアがチームを形成する。
そして、外部から雇い入れたスクラムマスター、または政府行政の人でファシリテーションが上手い人が、プロダクトオーナーとチームの間で調整する役割を担うだろう。
結局、そのようなプロジェクトチームをシステム毎にたくさん作り、スピード感を持って政府行政のDXを推進していくしかないだろう。

【2】しかし、政府行政のDX推進を妨害する問題は、内製開発できずにベンダーに発注してベンダーロックインになってしまうことだろう。

現状は、政府行政の中の人達が、ITプロジェクトをマネジメントする能力が不足しているし、発注者として、プロダクトオーナーの役割を果たす能力も不足している。

【2-1】本来のあるべき姿は、政府内部で公共サービスを提供するシステムは、全部自前で開発できると一番いい。
リリース後も常に保守する責任を持つし、サービス利用者の声を集めることで、次々に新たなサービスを提供して利便性を高めて、世の中をより良くしていくことができるはずだ。

そういう内製開発が政府内で実現したならば、SaaSベースの開発スタイルになるだろう。
文字通り、ソフトウェアでサービスを提供するわけだ。
理由は、「ソフトウェア・ファースト」の本に書いてある通りと全く同じ。

そして、そのシステム開発のプロセスはスクラムで行われるのが自然だ。
政府行政内の人がプロダクトオーナーを担当し、その業務要件がプロダクトバックログで表現され、サービス利用者が使いやすいように、業務フローやデザインは、ストーリーテリングのように数々の利用ストーリーを踏まえたもので作られるだろう。

【2-2】しかし、現状はギャップが大きすぎる。
パネラーも言っていたように、いきなりデジタル庁で解決するわけではないだろう。
おそらくは、デジタル庁のメンバーは発注者のプロジェクトマネージャーの立場がまず求められて、そういう仕事から現状の問題をこなしながら、今後のあるべき姿へ地道に変革していくことになるのではないか。

【3】しかし、政府行政のIT化の根本問題は、個人のプライバシーとどのように折り合いをつけるべきなのか、があると思う。

【3-1】実際、確定申告のWebシステムであれ、コロナ接触管理アプリCocoaであれ、国民全員に10万円をばらまいた補助金であれ、全て、国民1人が持つプライバシーをどのように扱えばいいのか、に苦慮している。

そもそも、中国のような監視社会であれば、個人の行動履歴、購買履歴、所得や資産情報、医療情報も全て、政府が把握できているのだから、本当に困っている人達に特定して補助金を配ることもできるし、特定した感染者を強制隔離することで、世間の人達の健康を守ることもできる。

だが、政府の公共サービスでは、個人のプライバシーが他人に悪用されるリスクや脅威がとても影響が大きいために、セキュリティ面の対応によって、機能は複雑化し、業務フローもとてもややこしくならざるを得ない。
たとえば、確定申告のeTAXは、なぜあんなに、スマホでもPCでも使いにくいのか、とみんな思っているのではないか。

しかし、過去の歴史を踏まえると、政府に個人情報を預けると何をされるか分からないという、命に関わる危険性をみんなが持っていたし、政府を信用していないから、プライバシー保護という名目で、今までこの問題を放置してきた。

コロナ感染という特別な状況が、その問題が自分たちの生活に直結するぐらい重要である、と分かってきたのではないか。

【3-2】一方、今回のコロナ不況で薄々分かったことは、我々自身も、政府の行動が信用できるならば、自分の個人情報を預けてもいい、と考えているのではないか。

実際、現在の政府の公共サービスは全て申請主義なので、サービスを受けたければ、自分たちからたくさんの書類を集めて、大量の文書を書いて、提出後は長く待たないといけない。
本当に困っている人達に、給付金を直接渡すべきなのに、政府から困っている人達を特定できないから届けることもできない。
よって、失業者が溢れたり、犯罪者や自殺者も増えたりして、社会自体が重苦しく、不便なものになっていく。

だからこそ、そうならないように、例えば、本当に困っている人達に給付金を配ったり、あるいは、コロナワクチンを接種すべき人達を政府自身が特定すべきだし、それらを一括管理できるようにすべきだろう。

【3-3】他方、プライバシー保護のグレーゾーンや法律のグレーゾーンに積極的にリスクを取って関わっていくことで、新しいビジネスを生み出すことの重要性も分かってきたのではないか。

たとえば、テスラは電気自動車を単に提供するだけでなく、販売した電気自動車の走行ログをもとに自動運転技術をより強化させている。
また、走行ログというビッグデータをもとに、自動車損害保険ビジネスに乗り出す、とか、Uberのような配達ビジネスに自動運転をミックスしたビジネスも生まれるだろう。

アップルも、アップルウォッチを提供することで、個人の健康情報を収集することで、ヘルステックという新たなビジネスを生み出そうとしている。
個人の健康情報のログをもとに、医療サービスや保険サービスの新たなビジネスが生まれるし、健康に関わるスポーツビジネスも生まれるかもしれない。

【3-4】つまり、個人情報の保護がグレーゾーンであっても、それに関するビジネスにソフトウェアが決定的に重要な役割を果たし、大きく社会を変えている状況では、この流れに乗り遅れると、もはや国自体が衰退するしか無い。
実際、コロナ感染の社会状況において、日本の大臣は、日本はデジタル敗戦だ、という発言もした。
すなわち、日本はソフトウェアでビジネスを変革するだけでなく、ソフトウェアで公共サービスや社会を変革していくことすらも、他国から大きく遅れてしまった。

米国は、多くのベンチャー企業などが法律のグレーゾーンをものともせずに、ソフトウェアで新たなビジネスを生み出した。
中国は、一党独裁の統制社会を維持するために、ソフトウェアを上手く利用して、インターネット規制やネット検閲、監視カメラなどによる監視体制などを利用してきた。
もちろん、BATのようなIT大企業も生み出しているが。

EUもプライバシー保護や民主主義を掲げてGPDRとか色々作ってきているが、結局、米国や中国のソフトウェアビジネスやソフトウェアの変革の波から乗り遅れているのではないか。

【3-5】そんなことを考えると、プライバシーはもちろん重要だが、各種申請や税金支払、補助金受け渡しのような公共サービスの利便性を求めたり、コロナ感染のように公共性を重視すべき場面では、ある程度のプライバシーは政府に委ねる方向性に今後進んでいくような気がしている。

| | コメント (0)

2021/02/15

TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか

TeamsとSlack、Zoomの違いについて、たまたま同一の日にツイートを見かけた。
TeamsとSlack、Zoomの違いは組織文化の違いを助長しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【参考】
akipiiさんはTwitterを使っています 「TeamsとSlackの組織文化の違いが面白い。」 / Twitter

Dai Fujihara | ノーコードテスト自動化SaaS「mabl」 | アジャイルコーチさんはTwitterを使っています 「最近、Teams使うお客さんに出会うことが増えてきたけどSlackなら「やっほー」で済むのがTeamsだと「お世話になっております」になるのが面白い / Slack 対 Teams…スラックの成功がマイクロソフトのおかげというのは「見当違いで、馬鹿げている」 https://t.co/3Ds3uHAlei https://t.co/fWDPik2D1H」 / Twitter

akipiiさんはTwitterを使っています 「TeamsとSlackを使う組織文化の違いは、色んな所で話題になるね。個人的にはTeamsを使うのに慣れて割と便利だと思っていて、逆にGoogleChatやSlackは機能が限定されすぎていて痒い機能がなくて、使いにくく感じる。」 / Twitter

沢渡あまね新刊 #業務改善の問題地図 #ここアジャ #職場の科学さんはTwitterを使っています 「申し訳ないが(私の使い方に問題あるのかもしれないが)、Teamsは組織外との人たちとのコラボレーションまだまだしにくい。特に、私のように複数の組織に属する人間の場合、「顔」を切り替える必要があるのだがそれが出来ない(?)。『役割切替』機能欲しい。パラレルキャリアへの対応、プリーズ。」 / Twitter

コミュニティ活動では、SlackとZoomを一般に使っている。
オンラインの勉強会、打合せ、イベントは、今までの経験ではZoomだけだった。
Slackも、コミュニティの時系列チャットみたいに使っている。

特に、Zoomは日々Updateしている感じで、ブレイクアウトルームやいろんな機能が使えるようになっているので、使っていて楽しい。
音声もクリアだし、利用しているだけなら支障はない。

一方、Teamsは会社の業務で使うのが一般的。
Office365を採用している企業であれば、Teamsがそのまま付属してくるので、そこから使ってくるのではないか。
Teamsの使い心地は割と良い。

チャットはSlackみたいに普通にできるし、Zoomみたいにテレビ会議も普通にできるし、Sharepointもバンドルされているので、Excelやパワポも普通に開いて保存もできる。
OutlookもTeamsの一機能になっているので、予定表でカレンダーを見れるし、Plannerも使えば、タスクかんばんみたいなタスク管理もできる。
一昔前のMicrosoft製品のように、ゴチャゴチャした感じではなく、今風なUIなので便利だと思っている。

しかし、Teamsのせいなのかどうか分からないが、@daipresentsさんの指摘の通り、Teamsではチャットに敬語を使う。
業務で使っているせいかもしれないが、そういう組織文化が出てくるのかもしれない。

また、@amane_sawatariさんの指摘通り、Teamsでは組織というグループ管理が強固なので、グループ外の人は入れない。
会社の業務のように、内部統制やIT全般統制、情報セキュリティを厳しく管理する場合はそういう使い方が必要なのかもしれないが、縦割り文化を助長している面もある。

ツールの機能の違いが組織文化を助長しているのかもしれないし、逆に、組織文化が、組織に合った機能を持つツールを選択しているのかもしれない。
いくら優れているツールであっても、ツールの利用者が使いこなせなければ意味がないから。

| | コメント (0)

2020/11/21

マインドマップをFreeplaneに乗り換えた

マインドマップFreeMindからFreeplaneに乗り換えた。

Japanese - Freeplane - free mind mapping and knowledge management software

FreeMind Ver0.9が使いやすくなっている: プログラマの思索

FreeMindの応用的な使い方: プログラマの思索

【再考】GanttProjectとFreeMindとJude: プログラマの思索

FreePaneの方がGUIが充実していて、VerUpの頻度も多い。
アイコンも多いので、自由に発想しやすい。

僕にとって、マインドマップはなくてはならないツール。
アウトラインプロセッサの代わりに、アイデアを発散して構造化する時に使っている。
こういうツールがないと、文章は書きにくいと感じる。

最近感じるのは、知的労働者にとって、PC上のアプリの操作の慣れ次第で生産性が大きく違うこと。
道具が思考を促進する。
思考と道具は表裏一体。

この考え方は、モデリングツールでも同じ。
また、IntelliJのようなプログラミング開発ツールでも同じ。

この辺りで考えたことも記録しておく。

| | コメント (0)

2020/07/07

ソフトウェアの政治的影響力とは何だろうか

今年になって、台湾の天才IT大臣の記事をチラホラ見かける。
ソフトウェアの政治的影響力を上手に使いこなしているな、と感じたのでメモ。
ラフなメモ書き。

【参考1】
「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に

(2) akipiiさんはTwitterを使っています 「時代の変化は速いよね。「マジで胸アツ」台湾の天才IT大臣、東京都の新型コロナ対策サイトの修正に自ら参加し話題に https://t.co/drVTKoZz74」 / Twitter

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (1/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (2/4) 〈dot.〉|AERA dot. (アエラドット)

新型コロナ“神対応”連発で支持率爆上げの台湾 IQ180の38歳天才大臣の対策に世界が注目 (3/4) 〈dot.〉|AERA dot. (アエラドット)

(引用開始)
タン氏にインタビューした経験がある前出の近藤さんは、こう話す。
「両親の職業がジャーナリストということもあり、彼女は『情報』が人々にどのような影響を与えるかをとても理解しています。
また、現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている。
入閣した時に『公僕の中の公僕になる』と宣言したとおり、特定団体の利益のために動くのではなく、テクノロジーを駆使して台湾の人々と行政院をつなぐ“パイプ”になっています」
(引用終了)

akipiiさんはTwitterを使っています 「ITによる可視化で政治的対立を消化させる道具にする発想が素晴らしいと思った。Redmineにも通じる。「むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」新型コロナ“神対応”連発で支持率爆上げの台湾IQ180の38歳天才大臣の対策に世界が注目 AERA dot. https://t.co/GORTP5vWb4」 / Twitter

【参考2】
台湾の天才IT担当大臣オードリー・タンに訊く、新型コロナウイルスの先にある未来の国家とは - Engadget 日本版

akipiiさんはTwitterを使っています 「ソフトウェアの政治力を良く知り尽くして活躍されてる事例。参考になる。” 台湾の天才IT担当大臣オードリー・タンに訊く https://t.co/zxSe7tNwVZ」 / Twitter

こーじさんはTwitterを使っています 「>その一方でパニック買いなど、噂による行動は防ぐ必要があります。そこに対しては、インフォデミック(≒情報の氾濫)より面白いユーモアを発信するという対策に取り組みました。 これ凄い面白い取り組みだな」 / Twitter

akipiiさんはTwitterを使っています 「@saba1024 台湾のIT担当大臣は、人々がシステムやSNSを使うと、どんな行動に走るのか、それを遠くまで見通して意思決定している点が凄いです。ソフトウェアの開発力だけでなく、その政治的影響力、行動経済学の知見、社会心理学の知見を知り尽くしてる、そんな気がします」 / Twitter

こーじさんはTwitterを使っています 「@akipii まさに仰るとおりですね! 時代が人を作るのか、人が時代を作るのかというのはよく言われる話題では有りますが、この方は間違いなくこの時代に必要とされる方ですね。」 / Twitter

台湾の天才IT担当大臣の振る舞いをツイッター上で眺める限り、ソフトウェアの調達方法や影響力の行使の仕方をよく理解しているな、と思う。
たとえば、コロナ感染症サイトへのプルリク、マスク在庫サイトの構築方法、記者会見をすべてオンライン化などがすぐに思い浮かぶ。

彼女のやり方で参考になる点はいくつかある。
1つ目は、ソフトウェアの開発はベンダー委託ではなく、オープンソース開発者のコミュニティを使って、アジャイルに開発していること。
公的なソフトウェアの開発は、官公庁の内部調整やベンダーへの委託によるリスク回避など、数多くの組織的な壁がボトルネックになりがちだ。
しかし、本来、公的なソフトウェアは国民全てがその利益を享受できるものだし、その重要性は高いのだから、いち早くリリースして、漸進的にVerUpしながら開発していくべきだ。
しかも、ソフトウェアは請負契約で作ったら終わりではなく、SaaSと同じく、運用しながらどんどん改善していく開発スタイルなので、ベンダーへの一括委託は元々なじまない。
現在のソフトウェア開発の技術革新の場所は、ベンダーではなく、オープンソースコミュニティに移っているのだから、彼らの力を利用して、国民すべての利益にかなうようなソフトウェアを作るべきだろう。
彼女の言動や行動した結果を見ると、ソフトウェア開発の特徴をよく理解しているように思える。

2つ目は、情報を発信すると人々がどのように影響を受けて、どんな行動に移るのか、という事を彼女はよく考えて理解しているように思えることだ。
「現役の閣僚でありながらも特定の政治的立場に立つのではなく、むしろ意見の対立をIT技術で可視化して、解決につなげることを考えている」という記事の言葉から想像すると、行動経済学の知見をよく知っているのではないか、と思う。

実際、コロナ感染が流行している時期にマスクの情報を何の仕掛けもなく公表するとどうなるのか?
本来マスクが必要な人に情報を知らせるにはどうすればよいのか?

皆が混乱している時に、その情報をIT技術で見える化することで、真実を共有し、そこから各人のあるべき行動を促す。
IT技術は本来、そういう問題解決に使うべきものであるはずだ。

そして、単に、マスク在庫のシステムをアジャイルに作るだけではない。
彼女や他の大臣が率先して、その規範を示していることも大事だ。

「例えば、支給マスクの色がランダムで、ピンクが当たった男子生徒が登校拒否になっているという声が届きましたが、その翌日には閣僚の男性陣によるピンクマスク着用のキャンペーンが始まりました。」という記事の通り、大臣自らが率先して見せれば、他の人も自然にその行動変容を受け入れてくれる。

「組織文化は組織のトップが作り出すもの。組織のトップはもっと汗をかくべき」と、とある先生から組織論の授業で習った。
僕が理解するには、人がたくさん集まっても、単なる集団であり、何かの目的を成し遂げるための組織にはなりえない。
トップがリーダーシップを発揮して、共通目的を語り、メンバーの貢献意欲を引き出し、コミュニケーションを活性化して初めて、集団は組織に変わり、人々の行動を変容させる。
また、社会や組織の中にいる人達は、社会的地位が低かったり、経済力がなかったり、政治力がないために、他の力の強い人達の影響を受けやすい面がある。
だからこそ、規範となるべき人があるべき姿や目的を語ることで、人々の意欲を引き出し、人々の行動を変容させる。
つまり、社会に流通する価値観や規範は、そのトップのリーダーシップから生まれるものだ。

そして、昨今の環境では、SNSを使えば、簡単に周知させやすい。
人の気持ちを盛り上げて、意欲を引き出すような言動をリツイートさせることで、人々に行動を変えさせる事が以前よりも格段に簡単に、かつ、その影響力が大きくなった。
その分、この使い方も難しい。
行動経済学が考えているように、人は合理的な存在ではなく、時代や環境に依存したバイアスを持って価値判断を下し、経済効果を生み出す。
そういう考え方を利用する方法もあるだろう。

| | コメント (0)

2020/06/11

DevOpsがアジャイル開発を促進する

今となっては古い2015年の記事を読んで、もう時代は変わったのだという認識をメモ。

クラウド専業SIerは従来のSIerとどこが違うのか? 夏サミ2015 - Publickey

社内サーバゼロ、フリーアドレス、メールをやめてSlack。クラウド専業SIerが模索するクラウド時代の働き方 夏サミ2015 - Publickey

クラウド専業SIerが語る、クラウド時代のエンジニアに必要な3つのスキル 夏サミ2015 - Publickey

技術のトレンドとしては、いかに作らずに、既にあるサービスやオープンソース、クラウドを組合せてローンチできるか。
プロジェクト管理のトレンドとしては、優秀な人員の調達能力やリソース配分能力よりも、クラウドの技術やサービスを知り尽くす技術者が少人数で速くローンチできるか。

AWSサービスも少しずつ勉強しているが、毎年数多くの新サービスがどんどん出てくるので、それらを組み合わせるとどんなメリットが出てくるのか、を研究していく必要がある。
枯れた技術を優先して流用して開発するスタイルはもう古い。

オープンソースとクラウドが当たり前の時代では、開発もインフラ構築も1人の開発者が対応できるし、よりアジャイルに開発できる。
技術がプロセスや組織をどんどん変化させていく。
昔に、こうあるべきだ、という理想のプロセスや組織論は、今はもう現実になっていて、いかにそれを使うか、さらなる未来はあるのか、という思考に向かっている。

| | コメント (0)

2020/06/09

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンク

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンクがあったのでメモ。

【参考】
AWS-CloudDesignPattern

Azure-CloudDesignPattern

デザイン パターンから見た AWS と Azure | Microsoft Virtual Academy ? 専門家が提供する e ラーニング コース ? | Channel 9

クラウドごとの違いはどこにあるのか?
AWSとAzureは、本質的にどこが違うのか? どこに気をつければいいのか?
AWSは細かい部分までエンジニアがパラメータを微調整する必要があるイメージだが、Azureはどうなのか?


| | コメント (0)

2020/05/08

Ruby技術者認定試験の感想

Ruby技術者認定試験Silver・Goldに合格したので感想をメモ。
Ruby初級者なので、間違っていたら後で直す。

【参考】
Ruby技術者認定試験

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

Ruby技術者認定試験(Silver && Gold)合格体験記 | Avintonジャパン株式会社

ruby gold 2.1 - Qiita

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

新人プログラマがRuby技術者認定試験(Gold 2.1)に1ヶ月半以内で合格する勉強法 - IT女子ブログ

Ruby初心者だけどRuby Association Certified Ruby Programmer Silverを取得した! - suusan2号の戯れ

Ruby技術者認定試験 Goldを受験しました - ZENET Tech Blog

【1】Ruby技術者認定試験Silver・Goldは、とても良い試験だったと思う。

Rubyの文法やライブラリを一通り知っておく為に勉強せざるを得ない環境にできること、そして、初級者はSilver、中級者はGold、というように、レベルも上手く設定されているからだ。
特にGoldは、メタプログラミングの知識や経験がないと合格は難しい。
Ruby経験者、Rails経験者であっても、一夜漬けでは合格できないだろうと思う。

【2】試験対策は、Ruby技術者認定試験にあるオンラインの模擬試験を100点が取れるまで解くこと、推奨の書籍3冊を読み込むことだった。

オンラインの模擬試験はたぶん、Ruby実務経験があっても試験慣れてしていないと取りこぼすかな、と思う。
間違えた問題は、ミスした原因を分析して、理解できていないのか、分かっているのに勘違いしたのか、でふるい分けて、Webや書籍で調べて納得するまで腹落ちさせることが大事。

【3】お勧めの書籍は5冊ある。
「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」
「メタプログラミングRuby第2版」
「Rubyのしくみ Ruby Under a Microscope」
「改訂2版 Ruby逆引きハンドブック」
「Effective Ruby」

【3-1】「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」に記載の模擬試験は必ず解いておくべき。本試験でも割と同じ問題が出るときもある。

【3-2】「メタプログラミングRuby第2版」はとても良かった。
Rubyにあって、Javaにはない特徴がメタプログラミングにあると思う。
Rubyの面白さはここにあると思う。
Javaの経験に引きずられていたので、サンプルを写経してようやく、ダック・タイピングのイメージがつかめてきた。

たとえば、io.print という処理では、ioはFileオブジェクトかもしれないしIOオブジェクトかもしれないし、printはインスタンスメソッドではなくインスタンス変数かもしれない。
つまり、的確にオブジェクトを定義すれば、ポリモルフィズムが背後で上手く動作して、たった一つの表現で複数パターンの処理を実現できる。
さらに、Rubyは読みやすさを重視しているので、処理がそのまま英文であるかのように読める。
特に、内部DSLをRubyで表現する時はそうだ。

「メタプログラミングRuby第2版」の良かった点は2つある。
まず、Railsの仕組みを紹介してくれていること。

たとえば、ActiveRecord::Baseでは、インスタンスメソッドが300個以上、クラスメソッドが500個以上も含まれている巨大なクラスだ。
著者が言う通り、Javaプログラマならば、こんな設計は狂っている、スパゲティコードだ、と最初は思うだろう。
しかし、むしろRailsでは読みやすく変更しやすい設計になっているのだ。
つまり、著者の言う通り、設計技法は絶対的なものではなく、設計技法は使用言語によって変わる。

その他に、ActiveSupport::Concernは進化的設計から生まれたし、alias_method_chainは廃止されてprependが使われる設計に変わった。
つまり、最初は問題解決のためのシンプルなコードを書いて、その後、ゴーストメソッド多用に対するパフォーマンス改善やalias_method_chain多用に対するスパゲティコード対策などのために、どんどんフレームワーク設計そのものを変えていった。
すなわち、Rubyのやり方は、最初から正しい設計を行うよりも、後から機能改善やパフォーマンスを改善していく進化的設計、つまりアジャイル開発がとても向いている。
その理由は、Rubyが徹底したオブジェクト指向言語でありメタプログラミングしやすい特徴を持つので、とても柔軟性の高い言語だからだろう。

【3-3】「メタプログラミングRuby第2版」の付録「よくあるイディオム」は、Ruby初級者が暗記すべきテクニックと思う。
参照したいので、イディオムを載せておく。

O’Reilly Japan - メタプログラミングRuby 第2版

アラウンドエイリアス(Around Alias)
ブランクスレート(Blank Slate)
クラス拡張(Class Extension)
クラスインスタンス変数(Class Instance Variable)
クラスマクロ(Class Macro)
クリーンルーム(Clean Room)
コードプロセッサ(Code Processor)
コンテキスト探査機(Context Probe)
あとで評価(Deferred Evaluation)
動的ディスパッチ(Dynamic Dispatch)
動的メソッド(Dynamic Method)
動的プロキシ(Dynamic Proxy)
フラットスコープ(Flat Scope)
ゴーストメソッド(Ghost Method)
フックメソッド(Hook Method)
カーネルメソッド(Kernel Method)
遅延インスタンス変数(Lazy Instance Variable)
ミミックメソッド(Mimic Method)
モンキーパッチ(Monkeypatch)
ネームスペース(Namespace)
nilガード(Nil Guard)
オブジェクト拡張(Object Extension)
オープンクラス(Open Class)
Prependラッパー(Prepended Wrapper)
Refinements(Refinements)
Refinementsラッパー(Refinements Wrapper)
サンドボックス(Sandbox)
スコープゲート(Scope Gate)
自己yield(Self Yield)
共有スコープ(Shared Scope)
特異メソッド(Singleton Method)
コード文字列(String of Code)
SymbolのProc変換(Symbol To Proc)

メタプログラミングRubyの感想: プログラマの思索

【3-4】「改訂2版 Ruby逆引きハンドブック」は、Rubyのライブラリを一通り説明してくれているので、APIを調べたい時に便利。

特に、RubyでもJavaでも、どんなプログラミング言語でも、配列Array、連想配列Hash、文字Stringのメソッドは最低限必ず覚えておくべき。
なぜなら、配列やハッシュ、文字を自由自在に操れないと、自分がやりたいことを実現する手間が多くなりすぎて、イライラするから。
もちろん、それ以外にもファイル処理、Web操作、クラス設計なども必要。

Java経験者から見ると、RubyはArrayやHashのライブラリが非常に多いし、便利な使い方が多いように思う。
Rubyはブロックが使いやすいので、ArrayやHashの各要素に何らかの処理を一括操作したい時に、1つのメソッドで1行で書ける場合が多い。
VBやJavaならば数行もまどろっこしく書いてしまう部分が簡単に書けるのは素晴らしい。
但し、たとえば、mapとcollect、selectとfind_all、injectとreduce、findとdetectなどのように、異音同義語が多い点は注意。

「改訂2版 Ruby逆引きハンドブック」は今も愛用している。

Ruby初心者が間違いそうなこと: プログラマの思索

SmalltalkとLispから来たメソッドmap と collect、reduce と inject: プログラマの思索

【3-5】「Effective Ruby」はRubyらしい書き方の解説本。
最初はRubyらしい書き方が分からず、VBやJavaみたいな書き方になってしまっていた。
その原因は、Rubyのライブラリを幅広く深く知っていないこともあったが、Ruby独特の考え方や書き方が分かっていなかったからと思う。

僕は、下記が参考になった。

項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目12 さまざまな等値の違いを理解しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目24 リソースはブロックとensureで管理しよう
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう
項目47 ループ内ではオブジェクトリテラルを避けよう

全てのイディオムを掲載しておく。

Effective Ruby(長尾高弘 arton PeterJ.Jones)|翔泳社の本

第1章 Rubyに身体を慣らす
項目1 Rubyは何を真と考えているかを正確に理解しよう
項目2 オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目3 Rubyの暗号めいたPerl風機能を避けよう
項目4 定数がミュータブルなことに注意しよう
項目5 実行時の警告に注意しよう

第2章 クラス、オブジェクト、モジュール
項目6 Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目7 superのふるまいがひと通りではないことに注意しよう
項目8 サブクラスを初期化するときにはsuperを呼び出そう
項目9 Rubyの最悪に紛らわしい構文に注意しよう
項目10 構造化データの表現にはHashではなくStructを使おう
項目11 モジュールにコードをネストして名前空間を作ろう
項目12 さまざまな等値の違いを理解しよう
項目13 ""<=>""とComparableモジュールで比較を実装しよう
項目14 protectedメソッドを使ってプライベートな状態を共有しよう
項目15 クラス変数よりもクラスインスタンス変数を使うようにしよう

第3章 コレクション
項目16 コレクションを書き換える前に引数として渡すコレクションのコピーを作っておこう
項目17 nil、スカラーオブジェクトを配列に変換するには、Arrayメソッドを使おう
項目18 要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19 reduceを使ってコレクションを畳み込む方法を身に付けよう
項目20 ハッシュのデフォルト値を利用することを検討しよう
項目21 コレクションクラスからの継承よりも委譲を使うようにしよう。

第4章 例外
項目22 raiseにはただの文字列ではなくカスタム例外を渡そう
項目23 できる限りもっとも対象の狭い例外を処理するようにしよう
項目24 リソースはブロックとensureで管理しよう
項目25 ensure節は最後まで実行して抜けるように作ろう
項目26 retryでは回数の上限を設け、頻度を変化させ、オーディットトレイルを残そう
項目27 スコープから飛び出したいときにはraiseではなくthrowを使おう

第5章 メタプログラミング
項目28 モジュール、クラスフックを使いこなそう
項目29 クラスフックからはsuperを呼び出そう
項目30 method_missingではなくdefine_methodを使うようにしよう
項目31 evalのさまざまなバリアントの間の違いを把握しよう
項目32 モンキーパッチの代わりとなるものを検討しよう
項目33 エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34 Procの項数の違いに対応できるようにすることを検討しよう
項目35 モジュールのprependを使うときには慎重に考えよう

第6章 テスト
項目36 MiniTest単体テストに慣れよう
項目37 MiniTest仕様テストに慣れよう
項目38 モックオブジェクトで決定論をシミュレートしよう
項目39 効果的なテストを追求しよう

第7章 ツールとライブラリ
項目40 Rubyドキュメントの扱い方を覚えよう
項目41 irbの高度な機能を使えるようになろう
項目42 Bundlerでgemの依存関係を管理しよう
項目43 依存gemのバージョンの上限を指定しよう

第8章 メモリ管理とパフォーマンス
項目44 Rubyのガベージコレクタの動作に慣れよう
項目45 Finalizerでリソースリークを防ぐセーフティネットを作ろう
項目46 Rubyプロファイリングツールを使おう
項目47 ループ内ではオブジェクトリテラルを避けよう
項目48 コストの高い計算をメモ化することを検討しよう

Effective Rubyを読んだので感想を書いてく - WEB SALADの記事も参考になる。

【3-6】「Rubyのしくみ Ruby Under a Microscope」はRubyのインタプリタYARVの仕組みを解説しているディープな本。
普通はこの本のレベルまで理解する必要はないと思うけれど、僕はRubyの定数探索のアルゴリズムと特異メソッドがどうしても腹落ちできなかったが、この本で何となくイメージできた。

たとえば、Rubyのメソッド探索は継承チェーン上に1本でたどる一方、定数探索は最初にレキシカルスコープで検索してから次に継承チェーンをたどる。
よって、定数検索の方がやや複雑だし、ソースを上から読み込むので、そんな挙動になるのかという発見もあった。

たとえば、Rubyのオブジェクトの特異メソッドやクラス本体のクラスメソッドは、特異クラスという別のクラスに存在する。
よって、特異メソッドやクラスメソッドが存在する場所は別のクラス、特異クラスにあるので、特異クラス系列の継承ツリーが別途存在する。

なお、「メタプログラミングRuby第2版」にも特異クラスの絵が掲載されていて詳しく説明してくれているのだが、通常のクラス系列の継承ツリーと、特異クラス系列の継承ツリーを混ぜ込んだ絵で記載しているので、僕には分かりづらかった。
一方、「Rubyのしくみ Ruby Under a Microscope」では、メモリ上にRubyのオブジェクトがどのように配置されるのか、絵が書かれているので、僕には理解しやすかった。

結局、プログラミング言語を理解するには、メモリ上に変数やオブジェクト、配列、ハッシュがどのように配置されるのか、を自分の頭でイメージできなければならないから。

下記の章がお勧めと思う。
Rubyがメモリ上にどのように展開してくれているのかをイメージしやすくなる。

第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング

Rubyの定数のお話 | media.growth-and.com

Rubyの定数探索の個人的な謎に迫る - Qiita

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

【4】Rubyを実際に実務に使う場合は、事実上、Railsをマスターすべきだと思うので、Redmineのソース解読もしながらちょっとずつやっている。

Javaや.NETのWebシステムの開発経験からRailsを見ると、Web開発でまどろっこしい共通処理やWeb特有の処理をRubyのメタプログラミングで上手く隠蔽して、コーディングルールを強制することで数行で書けるようにしている部分はすごいな、と改めて思う。

僕がRailsですごいなと思う点は、特に、JavaScriptとの相性が良い点だ。
Railsが生まれた当初から、prototype.jsやJQueryとの連携はスムーズだったし、JavaScriptを駆使することでWebのUIを豊かにしてくれた。
最近のRailsは、JSライブラリの発展とともに、VueやReactとも親和性が高い。
つまり、クライアントサイドのUI改善も取り込めるので、JavaやPHPなどの他の言語よりもRailsの優位性は高いような気がする。

【5】Rubyを勉強している時の僕の脳みそは、錆びついた機械時計に油を挿しながら、回転させようとしている感覚だった。
こういうことをRubyで実現したいんだ、要件や設計は分かっているのになぜすぐに書けないのか、という苛立ちを感じながらRubyのライブラリを覚えて、動きに慣れようとしていた。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索にある「プログラミングができない羊」みたいな地点から登っている感じだった。

でも、初めてのプログラミング言語を習得するには、どんな手順を踏めば良いのか、どういう点に注意すれば習得速度を上げられるか、という感覚はつかめてきた。
今は次のプログラミング言語としてPythonを習得しようとしているが、Rubyの習得経験や、RubyとPythonは考え方が似ているメリットもあって、割と楽に習得できそうな感じ。

結局、プログラミング言語が分かったという感覚になるには、自分の脳みそがコンパイラになりきって、メモリ上に変数やクラスがどのようにロードされて値が変わっていくのか、イメージできる必要がある。

こんな経験は誰でも知っているのだろうが、20代の若い年齢なら簡単であっても、40・50代と年齢を取るごとに、新しいプログラミング言語の習得はどんどん難しくなる。
しかも、プログラミング言語の隆盛は10年おきに移り変わるから、そのたびに以前の言語を捨てながら新しい言語に慣れていかないといけない。
たとえば、FortranやCobolからC/C++/VB、そしてJavaやC#、さらにRubyやPHP、そしてPythonやR、へどんどん変わってきている。
JavaもKotlinで書くのが普通になってきているようだし。

そんな事を考えると、アジャイル開発は常識だ: プログラマの思索にも書いた通りだったのを思い出す。

(引用開始)
ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。
(引用終了)

最終的には何かアプリが作れればいいな、と思っている。

| | コメント (0)

2020/04/30

PyCharmやVSCodeでjupyter notebookを使用する方法

Pythonの開発環境では、Pycharmが使いやすい。
デバッグやリファクタリング、色やキー操作の細かな設定が優れている。

しかし、PycharmのCommunity版では、ipynbファイルは素のJsonファイルで表示されてしまって使いにくい。
調べてみたら、下記のやり方で、Pycharmからjupyter notebookを起動してブラウザ上で表示できるようになる。

PyCharmでjupyter notebookを使用する方法(Windows10) - Qiita

一方、VSCodeでjupyter notebookを使用するには、Pythonエクステンションを入れるだけ。
ブラウザ上のでjupyter notebookではなく、VSCode上でipynbファイルが自動変換されて表示されるので便利。

VS Code でPython,Jupyter を動かす - Qiita

jupyter notebookを使いたい場合、PycharmCommunityよりもVSCodeが手に馴染んでいい感じ。

| | コメント (0)

2020/04/29

「ゼロから作るDeep Learning」を読み始める

「ゼロから作るDeep Learning」を読み始めた。
一気に7章まで読んだ。
理論とPythonの実コードを行ったり来たりする説明がとても素晴らしい。
思いつきをメモ。

【参考】
ゼロから作るDeep Learningのメモまとめ - Qiita

ゼロから作るDeep Learningで素人がつまずいたことメモ: まとめ - Qiita

以前から、機械学習やら深層学習に関する本は斜め読みで乱読してきた。
また、統計検定やQC検定の資格勉強を通じて、実際に使う統計理論と、メーカーによる品質管理の事例のイメージは分かっていた。
だから、理論の部分はだいたいイメージできていた。
でも肝心のソースが今まで分からなかったので、ブラックボックスみたいなイメージだった。

PythonもNumpy・Pandas・MatPlotlibもある程度慣れたおかげで、Pythonのソースコードを読みながら、なるほど、こんなアルゴリズムで作っているのか、割とベタベタにプログラムを書いているんだな、とか、色々気づきがあった。
Githubのソースコードを実際に動かした後で、本の文章の行間に書かれている内容を想像するのが楽しい。

oreilly-japan/deep-learning-from-scratch: 『ゼロから作る Deep Learning』(O'Reilly Japan, 2016)

Githubのソースを動かす時は、下記を参考にした。

Jenga 妄想の大気開放  オライリーの『ゼロから作るDeep Learning」でMNISTデータセットが読み込み出来ない件(Windows10上で動作するeclipseにて)

まだまだ分かってないけれど、いくつか気づきはある。

0か1を返す関数の引数にNumpyデータを渡した時、そのままでは計算できないが、Numpyのトリックを当てはめて解決する。つまり、np.arrayの要素に不等号演算を渡し、np.int型を返すようにする。
この部分は上手いなと思った。

パーセプトロンの合成は行列の積と同値なので、Numpyライブラリが有効に使える。
よって、行列の成分が膨大な個数であっても演算の個数自体はそれほど増えるわけではない。

実際のPythonの計算式では、かなり大きな数同士で四則演算する場合にオーバーフローの問題が出やすいとか
無限大に近い数値が出てしまう時がある。
そこで、あるMax値を付与したり、微小値を式に付与したりする場合がある。

ディープラーニングのような学習プログラムは、学習効率をいかに上げるか、という観点で損失関数をバロメーターにしてその精度を評価する。
これは丁度、小中高校生の学習でも、少ない学習時間でいかに暗記できたり、理解できるか、という観点にもつながる。
つまり、コンピュータの学習も人間の学習も、そのアルゴリズムは同じように思える。
多分そのように思える理由は、深層学習がそもそも人間の脳をパーセプトロンで表現してコンピュータ上でシミュレーションできるようにしたのだから、トートロジーなのかもしれない。

教師あり学習は、今のようなビッグデータと言われる時代では、非常に有効なのだろう。
SaaSで自動的に収集できるログデータ、電気自動車や家電製品から集まるデータなど、現代ではビジネスの副産物としていくらでもデータを集められるので、そのデータを使えば、いくらでも機械学習や深層学習エンジンに食わせることはできる。

強化学習の考え方を深層学習エンジンで実装するアイデアは面白いと思った。
強化学習はエージェントに報酬を与えることで、試行錯誤させながら学習させて賢くさせる。

この考え方は、組織人事理論にある「期待理論」の考え方に似ている。
期待理論では、動機付けの強さは「報酬への期待x報酬への魅力」「期待x誘意性」で決まると考える。
よって、期待理論を実際の組織に当てはめた場合、利益分配制度のような変動給与制、業績連動制度、成果主義人事制度を構築することで、社員の動機を誘発し、誘導させる。
なお、昨今の人事制度構築でも期待理論は非常に有効な考え方と言われている。

つまり、強化学習の考え方は、従来の組織人事理論の期待理論の考え方を適用し、実際にPythonプログラムで実装したに過ぎないように思える。
この考え方を発展させれば、機械学習や深層学習の学習効率を上げたいと研究したいならば、組織人事の理論を片っ端からPythonで実装して、比較すればいいだろう。

もう少し理解できたらまとめてみる。


| | コメント (0)

2020/04/24

教育における読み書きというアナログの重要性の記事のリンク

教育における読み書きというアナログの重要性の記事をリンク。
オンライン教育に関する主張のないラフなメモ書き。

【参考】
「ノートが取れない」中学生。日本の子どもたちの読解力はなぜ落ちたのか。新井紀子さんインタビュー | Business Insider Japan

読解力不足をどうとらえるか~新井紀子さんの答えをまとめる~: 風にふかれて

一人に一台、タブレットPCを配りますか?(その2) | ICT for Development .JP

オンライン授業でもアナログ感あるデザインで「考えること」を促す|Yoshikazu TATENO | たってー|note

【1】2020年4月時点では、日本の小中高学校はほとんどが休校状態なので、ほとんどの子供は勉強すらしていないだろう。
自ら目標を立てて、自ら題材を探して知識やスキルを身に着けていく、という作業は、大人でも難しいのだから、ましてや普通の子供ができるようには思えない。
そもそも、それができる子供であれば、学校という仕組みがなくても、自立していけるだろう。
とはいえ、昨今ではそういう能力が早い段階から期待されているけれど。

しかも、学校だけでなく対面の学習塾も閉まっているので、オフラインで先生から教えを請うこともできない。
公立図書館、大規模書店も閉まっているので、紙の書籍すら手に入らない。
結局、オンライン教育に頼るしかないけれど、色んな理由でおそらく日本の環境では敷居が高いのだろうと思う。
PCやWifi環境というIT基盤だけでなく、子供の適正に見合った教育方法とか、色々試行錯誤する問題があるだろうと推測する。

響いた言葉を引用しておく。

【2】「読む」「書く」はプログラミング同様に不自然な行為
(引用開始)
4 新井さんの著書を読むと、むしろ読解力を上げるには、板書をするなど「書く」行為をさせること、つまり「昭和的」な教育の方が効果が上がった実例が書かれています。ICT教育を進めて、読解力が上がるとは思えないのですが、どうでしょうか?

①「書く」行為は、そもそも人間にとって不自然な動作であると認識してほしい。「読む」「書く」はプログラミング同様に不自然な行為ですから、その時代と環境と要請に従って、カリキュラムを構築して確実に身に付けなければならない。
②けれども、私たち大人は、自分が子供だった時代に、読み書きを「自然に」身に付けた思い込んでいます。ですから、自分たちの子供の世代も、放っておけば、「それくらい」はできるだろうと信じています。でも、自転車もただ乗れるようになるわけではないのと同じように、字を書くというのは相当に集中力とトレーニングが必要なのです。
(引用終了)

「「読む」「書く」はプログラミング同様に不自然な行為」という指摘は同意する。
学習や勉強は割とアナログ作業が多い、という気はしていたから。
だから、アナログ作業であるがゆえに、それに適した訓練は必要だろう。

ただし、学習は割とアナログ作業が多いという現状は2つの側面があると考える。
学習という作業は、読む・聞く・書く・話す、など五感を使った動作が多いので、身体で覚えるべき部分が多いという点。
一方、日本では高校入試や大学入試がペーパーテストなので、問題を読んで答案に書く、という試験そのものに対応した技術が必要である、という点。

読む・聞く・書く・話すを使った学習を訓練する時、前者と後者のどちらに比重をおく方が効果的なのか、という疑問はある。
個人的には、後者のペーパーテストの為の訓練は不要と思うが、結果的にそれに適合しすぎた人達を生んでいる事象も多いのだろう。

また、プログラミングも不自然な行為、という指摘は同様に思う。
新しいプログラミング言語を覚えて習得していく時、今までとは違った頭の使い方を要求させられる。
AWSやアジャイル開発など新しい技術を習得していく時も同様。

周囲を見ていても、プログラミングの習得が早い人とそうでない人には、雲泥の差があると実感する。
「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索の通り、プログラミング能力は、読み書き以上に、その人の向き不向きが現れやすいのかな、と思う。
プログラマの能力や生産性は10~100倍以上の差が出る、という点は、そういう所に原因があるのかもしれない。

【3】タブレット教育、アクティブ・ラーニングは高度な能力を必要とする

(引用開始)
6 一人一台タブレット政策。小学校からのタブレット導入については、どうでしょうか。

①これは、もう終わりだな、と。特に小学生は絶対タブレットは良くないと私は確信しています。
②先進的に導入した私立学校や家庭で既に弊害が出ています。小学校からタブレットドリルで学ぶと、紙や長文にはもう戻れないのです。意外なことですけど、検索すら自分ではできない生徒が出てくる。学びが常に“消費的”になるのでしょう。けれども、大学や社会で求められる学びは“生産的”な学びなので、タブレットドリルで育った子は立ち直れないほど挫折してしまう。
③タブレット導入で今まで7時間かかっていた授業が2時間で終わり、残りは深く考える授業に当てるというような授業は、麹町中学校のようなある意味「特殊な環境」の学校だけでできることだと思います。それが本当に地方でもできるのかも検証せずに、タブレットという言葉が一人歩きしています。
④しかもローマ字入力ができるのは、小学校5,6年生なので、それまでキーボードは使えません。その間、一体何をやるのでしょう。
(引用終了)

(引用開始)
②日本の公教育以外で格差をなくす平和的な方法はないと思っています。
ちなみに、アクティブ・ラーニングは格差を広げてしまいます。それは戦後最初のアメリカ主導の学習指導要領である、ディーイ式の「生活単元学習」の失敗で明らかになっています。
③小学生のうちは比較的ワイワイやっていますが、中学生になると、出来る子が言ったことに他の子は追随します。だから、授業を全てディスカッションでやることは、現場を見ていない人の寝言に過ぎない。
(引用終了)

昨今流行しているタブレット教育、アクティブ・ラーニング教育を批判する理由が参考になる。
著者の方はおそらく、現場経験が豊富で、数多くの失敗事例も見ているのだろう。

現状では感染症の流行が終わらない限り、オフライン教育は無理でオンライン教育にシフトせざるを得ないだろう。
しかし、そういう指摘の元で、今後のオンライン教育を考えると、子供の成熟度に見合ったオンライン教育の方法を見つけないと、教育を受けられなかった世代や就職できなかった世代を大量に生み出してしまう事になる。
今後、試行錯誤しながらオンライン教育の可能性を探っているしかないのだろう。

残念なことに、日本では、教育現場が最もIT技術が遅れた場所であり、知識だけでなく環境も揃っていないので、数多くのハードルが高いのかもしれない。

【3】オンライン教育の手法は、実は、以前からMOOCなど反転教育の概念で知られていた。
具体的には、自宅でオンラインで講義を受けた後、学校で対面で先生に質疑応答して疑問点を解決していく、というやり方。

サルマン・カーン「ビデオによる教育の再発明」 - YouTube

『世界はひとつの教室』技術、教育、そして世界は動く - HONZ

教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索

知的誠実さの大切さ~Moodleが持つ教育のイノベーションの可能性: プログラマの思索

サルマン・カーンのYoutubeの説明を見た時に、講義の動画配信、子どもたちのテスト結果の採点・集計・分析・フィードバック・理解度確認などのシステム基盤などITを駆使しながらも、「技術を使って、本来の教育をヒューマナイズする(humaizeする)」という彼の言葉がすごく引っかかった。
IT技術を使うことで人的関係を効率化させて、人的介入を減らすのではなく、逆に、コミュニケーションや対面のやり取りの密度や濃度を上げていくのだ、という意見が半常識的に感じたからだ。

おそらく、こういう取り組みも現場で試行錯誤しながら、時間をかけてあるべき姿を探っていくしかないのだろう。

| | コメント (0)

より以前の記事一覧