環境構築は教えづらい
環境構築というのはとても面倒くさい。そもそも、イメージが全く湧かない。私がプログラミングについて何も知らないとき、つまづきに躓いたことを思い出す。一番最初にやらなければいけないくせに、面倒で頻度が少なく身につかない。
業務でelmを使ってきた。試行錯誤して、勉強してきた。なので一旦外部化して足場とするために、初心者のためのelmの同人誌を書きたいと思う。初心者との中間である期間は今だけなのだから。だから、徐々に考察に輪郭をつけていきたいと思う。
そもそも初心者のときは、プログラミングを全くわからない未知の物体Xだと考えている。そして、自分のイメージを全部間違ったものと考えて、アナロジーや比喩みたいなものを使うのを忌避する傾向にあると思っている。その結果、未知すぎて環境構築のハードルが上がって何もできなくなる。あれから慣れてきた私ですら面倒くさいと考えるようなものに、徒手空拳で挑んでいる。
未知を全て知ろうと欲張らない/全く知らないでとにかくやろうとサボらない
環境構築の問題は、いや新しいことを学ぶことの本当の課題は、いかに妥協するかだ、ということから輪郭を与えていきたい。この課題を解決するには、既知につなげることだ。方法は様々ある。「わからないけどとりあえずやって慣れる」「単語の意味を自分の言葉で予測する」「出てくる用語たちの関係・構造を分析する」
わからないけどとりあえずやって慣れる
必要なことは実際の経験である。だから、とりあえずやってみて見て学ぶ部分が必要である。でも、写経みたいなものとは一線を惹いておかねばならない。写経は、特に頭を働かせていないのに頑張っている錯覚が生まれてしまってよろしくない。最低限ある程度は意味を理解しておかなければ、簡単に人はただ写すことに慣れてしまう。ただの反復は全く無意味である。あくまで、メンタルモデルを形成することを目的にしなければ。
単語の意味を自分の言葉で予測する
単語の意味を自分の言葉で予測すること。英単語の意味だけ先に調べておいて、プログラミングの文脈ではどうなるのか？を予測する。既知につなげるための下地を塗っておくのだ。一気に塗って乾かすより、薄く塗り乾かすのを繰り返したほうが、はやくきれいに出来上がったりする。
出てくる用語たちの関係・構造を分析する
どんな専門用語も、相互の関係の上で成り立っている。それ自身で定義されうる単語は存在しない。この単語は動詞なのか？それとも主語のように働くか？そういった些細なことが大きな情報になったりする。また、ドキュメントで比喩を使われていないか探してみたり、身の回りのものでメタファーが無いか探したりする。
環境構築を説明するアプローチ
本を書くときに、どうやってメンタルモデルを形成する手助けができるだろうか？環境構築についてを説明するのは、「はいやってくれ」か「逐一細かく伝えてうんざりさせる」かどちらかになってしまいがちではないか？私が今まで読んだ少ない本やハンズオンではそうなってしまっていた。環境構築のイメージをもってもらう、という目的を押し出して説明しないといけないな。
メタに解説する、構造を明示することを意識する。「今からこれについて、こう説明しますよ〜〜」という宣言のような。それで、「環境構築についてのメンタルモデルを伝えたい」ということを伝えていく、というのを一つの軸にしようと思う。
色々な環境構築の記事に書かれていたことをこっそり引用しつつ、どうしたいかをもっと考えてみる。
ターミナルを便利にしてみよう
この記事ではターミナルを便利にすることを、「このファイルをzshrcとしてコピペしてください☆」のように扱っていたので不満だ。環境構築全体に一本筋を通した説明をしたいんだな、私は。zshとzshrcの関係について、や設定ファイルを置く位置にどういう意図があるのか。グローバルなところにしか設定ファイルを作れないものや、反対にユーザーのホームやプロジェクトのルートディレクトリに設置できるものなどがある。そういう、「プログラムがどこから設定ファイルを取得するのか」と意図の関係などを明文化していきたい。
コピペで大丈夫です
これはコピペしてはまずいんじゃないか？というような、意味の理解を必要とするものをコピペしてしまう人をよく見かけ、苦しくなる。これは業務年数関係なく、先輩でもやっている人がいる。
意味を理解しているような簡単なことについてはコピペをしてもいいだろうと思う。だけど、コピペをしてエラーが出て、「え？意味分からない、うーん」という時間が長くなってはもったいないよね。エラー文言を読めば分かるのに、みたいなものでも解決に時間がかかったりする。
逆も言えて、意味がわかっていないとちゃんとコピペできないということもある。
そもそもコピペする対象の役割がいまいちわからないことが多い。これはshellに入力する「コマンド」なのか、それとも「設定ファイル」なのか。設定ファイルに書くべきものを、間違えてshellに入力し、エラーになっちゃってわかりません、とか。
HowよりWhatの方がわかりやすい
コマンドや設定ファイルについて書いていて、一つぼんやりと思っていたことがある。それは、HowよりWhatの方がわかりやすいんだな、ということ。今まで振り返っても、設定ファイルに書き込むよりなんてコマンドを入力したほうが良いかを考えるほうが難易度が高い気がする。（もちろん対象の領域の難しさに依存するけれど。）
コマンド、それもどういう動作をするのか全くわからないものに関しては特に難易度が高いと思う。動作の意味がわからない、ということは動作の対象もわからない。対象があるかないかすらわからない。あってもどういうものを設定すればいいか。フォーマットは？Howに関しては考えることが複数あるのが問題であると言えそうだ。
設定ファイルについては、その設定名自体は何なのかわかる、ということが多い。ただ単に、いつ使われるのかわからなかったりするだけだ。
最後に、環境構築のメタファーを考えられないか試してみて終わりにしたい。環境構築の問題点は、それぞれのアプリケーションで設定ファイルの取り方が違うということ。広汎なイメージを持ちづらい。
環境構築は、素朴に道具を整備するというメタファーで考えると良いのではないか？という仮説を建てておきたい。必要な道具を買う/インストールする。道具の適切なところに、適切な情報を入れてあげる/設定ファイルを作成する。起動してあげる/適切なコマンドを叩いて、想定する状態に変化させておく。
こういう大まかなイメージを持っておくかどうかで、環境構築のやり方は変わってくるのではないか？ただ、メタファーについてはブラッシュアップの余地がある。もっと、情報を入れる必要があり、状態遷移をさせる必要がある道具について考えておく。
状態遷移については、たとえば洗濯機のスピードモード、などを想像してみたら良いだろうか。
私自身ブラックボックスで捉えてしまっている部分も大きい。だから、説明するときに適当になってしまうのだが、「ここからは理解する必要があって、ここからはブラックボックスでもさほど問題はないよ」と線引してあげるのが本とか教える側の役割かもしれない。文脈的暗黙知を明文化する。
経験として、「ここはブラックボックスでもなんとかなってるから、安心して。信じてください」と再三伝えること。 初心者がプログラミングできないのは、「私は知らないから何もわからないんじゃないか？」と、一旦仮に固定するべき知識も固定できないからに他ならない。初心者の敵は疑いである。
センスの有る人は、分からないけど自分なりの理解を固定する。その固定があるからこそ、差分がわかり、徐々に知識の解像度を広げていけるのである。その思い切り、というか、これ以上はわからないという諦めが必要である。その一旦止めるという作業がないと、サイクル的に理解することができない。理解しないと実行することができない、という考えの悪魔。やることによってわかるという分野が少なからず存在するのである。
総括
全く、答えが出たというような晴れ晴れした記事ではないけれど、徐々にアウトプットして思考を煮詰めていきたいと思い投下した。以下に、再度今までの環境構築の方針をまとめておいて、終わりとしよう。
Discussion