Build@MercariTrainingProgram2024で学んだ「translation」
0. この記事について
0.0 この記事で書くこと
私は、Build@Mercari2024というプログラムに参加しています。この記事は、その学習期間中に最も重要な学びであった"translation"について書きました。要約すると、「他者(人間やコンピュータ・本やweb上の記事)の言葉と自分の言葉との"translation"を繰り返す中で学びが生まれ、理解が深まり、自分の視点が移動していく過程がある」ということです。
0.1 対象読者
この記事は、このプログラムに参加する前の過去の自分へ向けて書きました。今回一緒に学んだ参加者のみなさん、お世話になったメンターのみなさん、Build@MercariTraningProgramに興味がある方が読むことを想定しています。
以下より過去の自分への言葉遣いとなるため、「常体」の文章になります。
0.2 "translation"とは？
まず、"translation"を辞書で引いてみる。
1. the process of changing something that is written or spoken into another language
2. a text or word that has been changed from one language into another
3. the process of changing something into a different form
ついでに "language"も調べてみる。
1. the system of communication in speech and writing that is used by people of a particular country or area
2. the use by humans of a system of sounds and words to communicate
3. a particular style of speaking or writing
4. a way of expressing ideas and feelings using movements, symbols and sound
5. a system of symbols and rules that is used to operate a computer
私が "language" に "tranlation" を行うと「言葉」となる。Build@Mercari2024には海外在住の方々も多く参加していた。そして、日本全国から年齢・性別・学歴など関係なく多様な人生を歩んできた多くの方が参加していた。1. の意味は、日本語と英語や方言の違いがあることを指し、2. の意味はチームミーティングなどで使った「言葉」を指す。人によってslackに書く文章のスタイルが異なり、それらに対して多様なスタンプを押してリアクションしていたのは3. や4. の意味が表すところだろう。そして、GoやPython,TypeScript, commandやdockerfileなどを記述する際に5. が意味する「言葉」もたくさん使った。
私は上記の文章において、『"language"＝「言葉」』とは書かなかった。
『"language" → 複数の意味 → Build@Mercariでの具体例 → 「言葉」』
のように一つの流れを経て、"language"と「言葉」をつなげた。これは最初に辞書で引いた "translation" が意味する「ある言葉を別の言葉へと変形するプロセス」の一例だろう。
1. 未知の知識をどのように学ぶか？
1.0 慣れない開発
「Build@Mercari」とは、これまでさまざまな事情でチャンスが巡ってこなかった方、特にSTEM分野（Science, Technology, Engineering, Mathematics）・IT分野におけるマイノリティである女性やLGBT+コミュニティの方を対象に、トレーニングとインターンシップのオンラインプログラムです。
参加者の多くが、Goを書くのが初めてだったり、PythonでAPIを開発するのが初めてだったり、DockerやGit/GitHubを使ったりするのが初めてだった。自分もGoで開発するのは初めてだったし、dockerについて学ぶのも初めてだった。
1.1 学習方法の不安
コーディング経験があまりないので、自分で考えても調べて書いてもあんまり進められなくて、レクチャーの録画を見て、スライドや他の人のコードをとりあえずコピペして前に進めている感じなのですが、このまま進めてもよくわからないというか闇雲に頑張って完成（という名の他人のコピペ？）で良いのか不安です。
とりあえずこのペースでSTEPを前に進めていくと段々分かってくるのか、焦らず課題の前半のSTEPにじっくり時間をかけてでもばっちりにするのかどういうイメージで進めていくのが良いんでしょうか。。？
複数の参加者は上記のような学習方法で学んでいることを心配をしていたみたいだ。2週間という限られた期間で、ゼロから環境構築やCUI操作, Git/GitHub, Go/PythonでのAPI開発, Docker/フロント開発などをすべて理解するのは難しい(と自分は思う)。どこかで理解を断念し、前に進まないといけないのだろうか。
1.2 模倣が有効なとき
これはある程度正しいと思う。例えば数学の学習。抽象的であり、精緻な論理で紡がれる思考プロセスは、ある程度時間をかけて学習したあとに漸く体得され、その意味を深く理解する。
教育の逆説は、教育から受益する人間は、自分がどのような利益を得ているのかを、教育がある程度進行するまで、場合によっては教育課程が終了するまで、言うことができないということにあります。
先へ進んだ後に分かることもある。しかし、ただの模倣だけ(コピペ)だと先へ進んだときに困ることもある。真似をすることは学ぶ方法の一つであり、それは「ある状態へ近づくため」という目的の下で有効だと思う。以下のような返信をした。
「答えが先(コピペ)で説明はあと」という問題の解決法が続くと、「知的負債」が積み重なる可能性があります。(参考記事)
高校までの教育環境では「体系的に整理された正解(と仮固定されている仮説)を説明してもらいながらインプット」することが多く、このような教育環境で学んできた方々の多くがこの問題解決の手法(思考プロセス)に依っているように思います。(これは教育環境と、受験競争という時間を含む様々な制約がある環境からアフォードされた学習プロセスの結果であり、学習者側に落ち度はなく、環境や構造の問題だと思います。)
自分も以前はそうでした(今もそうかもしれません)。この思考プロセスから抜け出す方法は、「一つひとつの知識をつなげて自分の学びを構築していく」ことだと思います。「知的負債」を返済する方法は、「説明可能/再現可能にすること」だからです。一つひとつ説明/再現可能にしながら答えに辿り着くのです。
例えば、山の頂上にいく方法は、「登山」だけではなく「ヘリコプターを使う」なども考えられます。「答えが先で説明はあと」や「ChatGPTにコードを書いてもらう」というのは、「ヘリコプターを使う」のと似ています。目的地には早く辿り着けますが、その代償として高山病になる危険があります。ヘリコプターを使ったことでその標高に身体が慣れる時間がなかったからです。身体がしんどいと、山頂からの美しい光景どころではなく、すぐ下山することになります。それにヘリコプターやChatGPTなどの道具がなくなった時、その人は山頂や目的地にたどり着くことができなくなります。知的負債が積もり重なって破産したとき、路頭にまようのです。では、「理解する」とはどういうことでしょうか？この記事から引用します。
「ソフトウェアエンジニアリングとは、ある規則を未知の事例に応用する知的技能である。 (中略) 自身が身につけた規則が応用可能かどうかを確認したい場合、実際に試すのが良い。例えば、あるプログラミング言語について理解したかどうか判断したい場合、まだ解決したことがない課題をそのプログラミング言語で解決してみる。未知の課題に応用できれば、理解しているという認識で問題ない。逆に応用することができないまま、理解したと勘違いした場合、未知の課題に対して手も足も出なくなる。」
つまり、学んだ(自分で見つけた)規則を他の事例に応用できるようになったとき初めて理解したと言えそうです。ならば、どのように学習するのがいいのでしょうか？同じ記事から引用します。
「応用できるレベルにまで規則を理解する方法は、技術力の熟練度によって違うことは認識しておかなければならない。ある人は、ドキュメントを読むだけで規則を理解できる。ある人は、コードを読むだけで規則を理解できる。ある人は、何回もコードを模倣することで規則を導き出す。ある人は、その規則の仕組みの裏側を理解することで理解できる。ある人は、トライアンドエラーを何回も繰り返すことで理解できる。ある人は、自然界で類似しているコンセプトと認識を重ねることで理解できる。ある人は、抽象化と具体化を行き来することで理解できる。多種多様な方法が存在する。」
公式ドキュメントを参照するだけが学習法ではありません。人それぞれ理解度や人生の中で得てきた「言葉」が異なるので、時には厳密ではなくても「適切な比喩」が理解を助けることがあります。また、他人のプログラムを模倣することも学習法の一つです。上記の記事に、「理解」について一つ付言するなら、学びは自分で構築していくものだと思います。スティーブ・ジョブズのConecting Dotsは人生における学び(点)同士をつなげていましたが、私は、このConecting Dotsという考え方は知識同士の接続にも応用できると考えています。拙文より引用。
「私の頭の中で「理解する」という行為は、「自分の脳内に点を打ち、その点同士をつなげたり組み合わせたり構造化して、外界の理解対象を自分の脳内構造の一部にする」行為であり、それを「メンタルモデルを構築すること」と表現しています。学習の過程で、点を増やすだけでなく、点同士のつながりや構造を再構築することもありえます。理解の深さは、点の凝集密度の高さを指し、応用可能であるとは、構造をしっかりと把握して他の点集合にも適用できる状態を指すのだと考えています。」
最後に。理解には時間がかかります。世界一流エンジニアの思考法という本にも書かれていました。すごく優秀なエンジニアの方でも複雑なものを理解するためには時間を要するそうです。彼ら彼女らは、時間を積み重ねて多くの知識を習得してきたから、複雑なことも難なく理解して行っているように見えるだけで、そこに至るまでには一定の登山過程があるようです。一つひとつの理解に時間をかけて、応用可能な状態にまで規則を理解していくと、それぞれの標高に身体が慣れていき、山頂からの美しい景色を自分の目で見ることができるのではないかと思います。
メンターさんも「自分のペースで」「このトレーニングは学習がメイン」とおっしゃっているので、「急がば回れ」で他の学生と比較することなく、ご自身の理解に集中されるのがいいのではないかと思います(自分はそうしています)。ただし、2週間という時間の制限があります。この制限への対処は、自分の学習時間を可能な限り確保することと、Googleの15分ルール が役立つと思います。
追伸：
私は現在、レストランで料理を作っています。最近、「美味しい」を疑うようになりました。未知の味にたくさん出会うからです。「美味しい」という感覚は「今までの食事歴」から形作られています。実家の味が恋しくなるのも、過去にたくさん食べてその味に慣れているからでしょう。しかし、新しいことを学ぶためには未知の領域に立ち入る必要があります。"La gastronomie ne cesse d'évoluer"(美食は常に進化しづけるものである)という言葉がありますが、テクノロジー分野も同様に日進月歩進化しています。Mercariで働かれているメンターの皆さんのように、社会に何か影響するものをつくれるエンジニアを目指すには、ある規則を他のケースへも応用可能な状態にまで理解しながら、学ぶのがいいのかなと思ったりしています。
つまり、『「未知を既知と結びつけたり、ある規則を見つけたり」して、「それらを説明できる状態にしたり、再現や応用ができる状態にする」』ための模倣という学習は有効だと思う。
上記の返信は長文だが、これは「自分の考える学習観」を「相手の言葉」へ"translate"する上で必要な言葉の変換過程だと思う。
⚠️(2章は自分用のメモなので、お急ぎの方は読み飛ばしてください。理解が深まり次第、修正加筆します。)
2. 知識の"translation"
Build@Mercari Training Program
https://github.com/oz1042/mercari-build-training/
「(自分の)普通は(相手へ)不通である」という拙語を元に、既知だった部分も含めて可能な限りわかりやすい説明に努める。一方、初めて学んだことは誤った記述をしている場合がある。コメントにてご指摘いただけると幸いである。
2.0 CUIに慣れる
WordやExcel, PowerPointなどは使ったことがあるかもしれない。それらのデータはファイルに保存される。他にも、画像ファイルやテキストファイルなどいろんな種類のファイルがある。.pngや.jpg, .txtなどファイルの後ろについているものを拡張子という。
複数のファイルをまとめて入れることができるものをディレクトリ(フォルダ)という。ディレクトリの中にディレクトリを入れることもできる。例えば、スポーツディレクトリ(sports)の中に野球ディレクトリ(baseball)をつくり、その中に大谷翔平選手の写真(OtaniShohei)を入れる。これをGUI (Graphical User Interface)で行うには、マウスを使ってディレクトやファイルを移動させればいい。一方、CUI(Character User Interface)で扱うにはパス(path)という表現方法を用いる。上の例のパスは、「sports/baseball/OtaniShohei.png」である。
ちなみに、なんでbaseBallやFootBallみたいに微妙にディレクトリ名が違うか気になった人は、
一番下に添付した記事「命名規則についてまとめてみた」も読んでほしい。
✅ ディレクトリとファイルの違いを説明できるか？
✅ コマンド(CUI)でディレクトリやファイルを作成・削除ができるか？
✅ コマンド(CUI)でディレクトリの移動やファイル検索を行えるか？
✅ rootディレクトリとhomeディレクトリを説明できるか？
✅ 絶対パスと相対パスの違いを説明できるか？それらを使って実際にディレ
クトリを移動できるか？
2.1 Git/GitHub
STEP1: Git
初めて触れる道具を扱えるようになるには、「その使い方を知ること」と「実際にその道具を使ってみる」ことが大事。
Git/GitHubについては、本・Web記事・動画などたくさんの解説コンテンツが存在する。自分の状態(確保できる学習時間/使えるお金/得意な学習法)に合わせて選ぶとよさそう。
- 本：情報の信憑性が高い(誤った記述が少ない)。知識が整理されている。
一方で、読むのに時間がかかったり、お金がかかったりする。
- Web記事：無料だが、間違った記述もある。知識が断片的に存在する。
一方で、ピンポイントで最新の情報にすぐアクセスできる。
検索にはコツが必要。(画像検索とか検索ワード選びとか大事)
- 動画：視覚的にもわかりやすい。一方で、視聴に時間がかかる。
- Qiita / Zenn
プログラミング関連記事がたくさんある。
- Google 画像検索
なかなかよさそうな記事が見つからない場合は、画像から探してみる。
- SpeakerDeck / slideshare
スライドが共有されているサービス。イメージと流れが工夫されている。
- medium
英語で書かれた記事が多い。英語でも検索してみる。
- YouTube
解説動画がないか探してみる。
- 調べている途中で知った単語で調べ直す。
(例えば、Gitの生みの親はLinus Torvaldsさんだけど、日本人の濱野純さん
も多大な貢献をされたことを知ったら、彼のスライドを検索してみたり。)
- 引用されている記事や本も読んでみる。
- 各テック企業の技術ブログや研修資料なども参考になる。
この記事の以下では、誰でもすぐにアクセスできるWebコンテンツ(記事とスライド)を中心に添付する。
一つ目の記事は、Gitの導入や設定(SSHなど)の参考になる。サル先生のGit入門はReferenceにも載っているコンテンツで、参加者からもわかりやすいと評判だった。二つ目の記事は私の拙文記事。中級者向け。ただ、ここまで理解すると、「2.0 CUIに慣れる」で触れたファイルシステムの知識とつながると思う。最後のやつは、Git公式ドキュメント。特に、GitHubの導入のところでよくわからなかったり、つまづいたらメンターやできている他の参加者に質問するといい。ただ聞きすぎるのもよくない。自分で考える時間も必要だ。
参考：Google人工知能チームの「15分ルール」
✅ Git/GitHubとは何か、使うメリットなどとともに簡単に説明できるか？
✅ working tree(directory), staging area(index), local repository, remote repositoryなどを図で説明できるか？
✅ その際、git init, git clone, git add, git commit, git remote add origin, git pushなどのコマンドをどの過程(流れ)で使うか説明できるか？
✅ branchやmerge, PR(Pull Request)について意味と操作を調べたか？
✅ git status, git ls-files, git logなどのコマンドや、それらのオプションを調
べたか？(例えば、git push -u origin mainの"-u"の意味は説明できるか？)
✅ 上記を自在に使えるようにするためにたくさん手を動かして失敗したか？
✅ 余裕があれば、コンフリクトやforkの意味、git rebaseなども調べる。
実際の開発でどう使われているかも調べる(この後のSTEPで実践する。)
📚 フォークした後に本家の変更を取り込む方法
2.2 環境構築(Go/Python)
調べつつ、分からなかったらすぐに聞く。ここが最初の難関。余裕があれば、それぞれ何をしているのか意味を理解できるようにする。
✅ Pathを通すとは？(「2.0 CUIに慣れる」で触れたあの「パス(path)」)
export/sourceコマンドや.zshrc, .bashrc/.bash_profileを説明できるか？
✅ (Python) uvicorn main:app --reload --port 9000は何をしている？
仮想環境/requirements.txtとは何か？どう使うか？
✅ (Go) go run app/main.go は何をしている？(app/main.goもパス(path))
go.modファイルとは何か？go mod tidyのコマンドの意味は？
Reference：［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】
💬 ここまで来ると「パス(Path)」という概念は応用可能になっているはず。
2.3 Develop API with JSON
STEP3: 出品APIを作る 環境構築に続き第二の難関。まずは概念理解から。たくさん調べたり、質問する中で自分が既に持っている知識や言葉と結びつける("translate"する)とよさそう。私はC言語を学んでいるから、Goの文法をCと比較しながら理解した。初めて触れる概念は比喩/アナロジーを用いて仮説を立てて、実際に調べ尽くしたりプログラムを書いたり、質問することで検証した。
インターネットについて(IPアドレス/ポート番号)
https://lecture.ecc.u-tokyo.ac.jp/~cai/IP.pdf
HTTP入門
Web API 入門
RESTful API 入門
JSONは2つの構造を基にしています。名前/値のペアの集まりです。
様々な言語で、これはオブジェクト、レコード、構造体、ディクショナリ、ハッシュテーブル、キーのあるリスト、連想配列として実現されています。
値の順序付きリスト。ほとんどの言語で、これは配列として実現されています。
JSONについて調べたら、Pythonで実装するならディクショナリ(辞書)型+リスト、Goで実装するなら構造体+スライスを使うといいかも、と検討がつく？
curl.1 the man page
✅ -X, --url, -d(--data), -F(--form)等のオプションはどんな意味を持つか？
(-Fを調べたときに出てくる"MIME multipart"はGoのドキュメントを読む
ときに役立つから調べてメモしておくといいかも。)
Goとechoの勉強 (初めてだけど挑戦したい！)
A Tour of Go
✅ Goで関数を書けるか？構造体の定義はどう書くか？
✅ packageとは何か？import文の書き方と標準ライブラリを調べたか？
使えるか(コーディングできるか)？
✅ その他、defer, slice, map, interfaceなども説明できるか？
↑ (Reference: http://tenn.in/go)
echo > docs > Quick Start
【golang】echoを使ってさくっとAPIを作成する話
[Golang]EchoのMiddlewareを実装する
Go言語初学者がエラーに立ち向かう方法
✅ echoとは何か？middleware, routingとは？
✅ Contextインターフェース, Echo型が持つメソッドを知っているか？
✅ ハッシュ化とは何か？ハッシュの種類は？
-> gitのcommitにもハッシュが使われている。
✅ port (ポート番号) とは何か？
✅ localhost, 127.0.0.1 は何を意味するか？
✅ HTTPリクエストメソッド (GET, POST...)にはどんなものがあるか？
✅ HTTPステータスコード (1XX, 2XX, 3XX, 4XX, 5XX)はそれぞれどんな意味を持つか？
✅ log levelとは何か？
🤨 (難)CORSとは何か？ -> CORS とは何ですか?
実装が難しいときは、模倣する学習法も有効。ただし「自分の言葉で説明できるか？」「他のケース/課題に応用できるか？」で理解しているかをチェックする。
2.4 Develop API with SQLite3
2.3 ではJSONファイルにデータを保存していたが、2.4ではデータベースにデータを保存する。その際、SQLite3というRDBMS（Relational Database Management System / データベース管理システム)を使う。また新しいツールが出てきた。
SQLite入門
Command Line Shell For SQLite
✅ JSONファイルではなくデータベース(SQLite)にデータを保存する利点は何か？
✅ 正規化とは何か？
2.5 Docker
3つ目のスライド資料に「Understand build context」というキーワードが出てくるが、本当にその通りだ。dockerfileを書くときには"Path(パス)"を意識して書こう。
2.6 CI
STEP6: CIを使ってDocker imageをBuildする
昨今では、ソフトウェア開発におけるさまざまな工程を自動化するような技術の開発や普及が進んでいる。その1つに、CI（Continuous Integration、継続的インテグレーション）やCD（Continuous Delivery、継続的デリバリー）と呼ばれるものがある。CIはソフトウェアのビルドやテストを自動化して頻繁に実行することでソフトウェアの品質向上や開発効率化を目指す手法で、CDはCIに加えてリリースやデプロイまでも自動化する手法だ。
(中略)
GitHub Actionsは、ほかのCI/CDツールと同様、リポジトリに対するプッシュやプルリクエストといった操作、もしくは指定した時刻になるといったイベントをトリガーとして、あらかじめ定義しておいた処理を実行する機能だ。
3. コミュニケーションの"translation"
3.0 一緒に仮説を検証する
5人ほどで作業通話をしていた際、1人(Aさん)がエラーの質問をした。私はその解決の筋道が見えていたので、他のメンバー(Bさん)が出した解決策の仮説より、自分の仮説をゴリ押しした。結果的にAさんのエラーは解決されたが、Bさんの学習機会が失われた。このことを反省し、メンターさんに質問した。
時間があるなら、みんなが出したエラー解決のアイデアを一度書き出して、一つひとつ実行してみる。そうすることで、場にいるみんながいろんな試行とその結果を知ることができる。そして、場にいる参加者それぞれに学びが生まれる。
時間を要するが、エラーについて一緒に調べたり、問題について一緒に考えたりすることは、自分の学びにもなる。
私の信じるところでは、知的創造というのは決して自分、つまり私の頭の中にあるアイデアを外へ表出していく行為ではありません。そうではなく、根本的に対話的な行為だと思っています。つまり、他者との対話、コミュニケーションの中から生じるものなのです。ここで言う他者とは、具体的な友人でも、教師でも、編集者でもいいですし、研究会や学会で出会った論争相手でもいいでしょう。場合によっては、それはすでにこの世にいない思想家や実践者、ときには預言者であっても構いません。いずれにしても、何らかの自分でない他者との実際の、あるいは想像上の対話が、知的想像には必要なのです。
3.1 PR(Pull Request)レビューで視点を獲得する
相手のコードをPRのコメントやソースコード内のコメントを参考に読み解く。違う書き方やロジックがあると、その違いが学びになる。自分と相手のコードの相違点や類似点を知ることで、自分の書いたコードが輪郭をもつ。自分の現在の視点や知識が浮き彫りになり、相手の視点を獲得するために検索したり質問したりする。相手の視点にも立つことができたとき、また一つ学びが増えている。
相手の視点へ移動するという"translation"もまた学びをもたらす。
3.2 相手の言葉を使う
情報科学を学んでいる学生(A)と「Pythonから学び始めたらオブジェクト指向はあたりまえの概念だけど、Cからはじめたらその価値がわかる。」という話をしていた。この話を「プログラミングを始めたばかりのもう一人の場の共有者(B)」に伝える際、「オブジェクト指向」という言葉は通じない。彼女(B)は微分方程式の話を雑談中にしていたので、数学が得意なのだろうと推測。「私たちは『積分』を学校教育で学んであたりまえの概念として知っているが、昔の人たちは土地の測量のためにその概念を生み出した。Pythonは比較的新しい言語だから『オブジェクト指向』があたりまえとして存在するけど、Cは昔からある言語だからそうではない。」このように説明すると、彼女にも話の流れが通じる。「オブジェクト指向」自体を説明しなくても、例えを使うことで相手が知っている言葉を用いて、話の内容構造を伝えることができる。
これは一事例だが「相手がもつ言葉」で伝える"translation"は、様々な場面で役に立つと思う。適切な比喩は理解を助ける。
3.3 スタンプや画像を使う
よく言われることだが、オンライン上でのテキストコミュニケーションは感情や意図が伝わりにくい。チャットツールやPRでスタンプや画像を使用するとテキストだけでは伝わない情報も伝えることができる。特に、チャットツールにおいて誰かが投稿したメッセージにスタンプのリアクションをするのは大切だと感じた。スタンプを駆使していた参加者には親しみやすさを感じた。
感情や意図の"traslation"も重要だ。
3.4 学び方は人それぞれ違う
「ソフトウェアエンジニアリング」が意味する「ある規則を未知の事例へ応用する知的技能」を習得することができれば、模倣することやAIに質問することも素晴らしい学習方法だ。もちろん、他者に質問するのもいい。Web上の情報より人間が持っている情報の方が多いと言われるくらいだ。一方、1人で黙々と調べたり考えたりする学習法も同様に素晴らしい。人それぞれ得意な学び方があり、今回のBuildプログラムはどんな学習方法も歓迎していた。むしろ、自分自身の学習スタイルについて再考したくらいだ。
質問に答えるときは相手の学習スタイルに合わせてヒントや問いかけの形を"translate"することも大事だ。
4. 感謝と今後
4.1 感謝
このような学びが得られたのは、Build@MercariTraining2024の運営とメンターのみなさん、そして一緒に学んだ方々のおかげです。ありがとうございました 😊！！！
4.2 今後すること
・Goをマスターしたい。
・残りの課題(Extra2, STEP7,8)に取り組む(2weeks)。
・もう一周やってみる(2weeks)。
・食材の栄養素を叩けるAPIと外食・自炊で摂取した栄養素の可視化と偏バランスアラート機能を持ったアプリを開発したい。
・関連書籍を読む/Udemy動画を視聴する。
Appendix. このせわしない時代に自分のペースで学ぶということ
🔍 「ピアジェ 構成主義」
時間を決めて取り組むことは大切だ。時間を決めないと人間は永遠にだらける。しかし、他者と進度を比較して自分の進捗が遅いことに焦り、理解を疎かにしたまま前へ進むことは、かえってその後の歩みを遅くする。
問題を作った人には、答えが分かっている。必ず答えがあると保証された問題を解くのは、そこに見えている頂上へ向かって、ガイド付きの登山道をハイキングするようなものだよ。数学の真理は、道なき道の果てに、誰にも知られずそっと潜んでいる。しかもその場所は頂上とは限らない。切り立った崖の岩間かもしれないし、谷底かもしれない。
ここでもう一つ，注意しておきたい事がある．譬えば，友人がある事柄---スポーツでも教科でも趣味でも何でも構わない---を一年で物にした，としよう．その同じものに対して，諸君が二年三年を費やして，漸く理解出来たとしても，それは何の恥でも無ければ，引け目を感じる必要など一切無いのである．それは，諸君がその友人に対して，努力を半分しかしなかったか，或いは頭の回転が半分程度であったか，という唯それだけの事である．然し，友人達が易々と処理していくものを，横目に睨みながら何の努力もせずに逃げ出したとしたら，少々問題は変わってくる．
二つの大きな相違は，前者は努力や能力の差が，「凡そ半分」或いは「三分の一」と言う"数値"で示されるのに対して，後者は「彼らは途轍もなく偉い」といった感情的な言葉でしか評価出来ない点である．
要するに，十年掛かろうと二十年掛かろうと，何時の日か，それを理解出来ればそれで好いのであって，人生は"早熟だけが高得点"になるような時間制のゲームではないのである．兎にも角にも挑戦し，それを物にさえすれば，如何なる秀才相手にも決して怖じ気づく必要はない．彼が一日で処理し得る問題に，一年掛がりになったとしても，「彼は僕より365倍は賢いな」と言っておけば好いのである．こうして，数的な評価が出来れば，譬えそれが，千倍万倍違おうと同じ土俵の上での勝負になる．それは，やがて百倍に落ち十倍となり，あっと言う間に諸君も互角の水準にまで達するであろう．
それが「経験」というものである．「経験」と「参加」は全く違う．それは，「経験不足」「経験豊か」「経験がものを言う」などの言葉の代わりに，「参加」を当て嵌めてみれば，直ぐ解るだろう．主体的に取り組まないものが「参加」なのである．諸君が，学校でどれほど試験を受けようと，それが積極的なものでなければ，決して「経験」にならず，唯の参加で終ってしまうだろう．後ろ向きの態度で，あらゆるものから逃げ腰になり，決して真正面から挑戦しないのであれば，如何なる現実も「経験」には成り得ない．
一方，その時どれほど出来なくても，一直線にそれに挑めば，次はもっと巧くいくだろう．一点でも取れば，百倍頑張れば百点である．仮に，他の人が二十歳で出来る問題が，六十歳まで掛かったとしても，高々三倍遅れただけではないか．それが嫌さに逃げ出してしまえば，正に「無限の差」になってしまう．あらゆる事を"経験"する---傍観者としての参加ではない---権利が諸君にはある．失敗する権利がある．大いに恥をかき，砂を噛み涙を流す権利を諸君は有している．安手の議論に惑わされて，「やれ権利だやれ義務だ」と踊らされる事なかれ．本来「青年の権利」とはこういう意味である．歯を食いしばって，「この次はもっと上手くいくさ！」と言える事，それこそが若者の特権なのである．
一般的に普通1分で歩く距離を
3分4分かけて歩いてく人がいる
1歩踏み出すたびにその意味を考える
ちゃんと確認してからじゃなきゃ
進めなくて遅くなる
何も考えない日々は
いくら積もろうが星の瞬きほど
哲学を探るんじゃない
置き去りの真理から何か見出せ
いずれあたしも死んでいく
死に方はきっと選べない
ならば生き方を選びましょう
前例がないような奇抜なのを
……
🔍 自律調整学習
応募時は全然合格するとは思っていなかった。合格をいただき、仲間と学ばせていただいて、今こんな景色が見えているよと、過去の自分へ伝えたい。
この記事が気に入ったらサポートをしてみませんか？