こんにちは 👋
Exercismをこう改善したらどうかというアイデアを提案したときに、誰かがこの記事へ案内してきたということはありませんか？
私たちのチームがそのアイデアを検討する時間を割く前に、まずこの記事を読んで、そのアイデアが以前にも考えられたことがあるのではないか、どんな落とし穴があるのかを考えてみてほしいと考えています。
そうした検討事項や起こりうる落とし穴を提案に加え、なぜそのアイデアがすでに実装されていないのかを考えることで、より早く、より前向きな返答を得られる可能性が高くなります。
「チェスタトンの柵」とは何でしょうか？
チェスタトンの柵は、作家G・K・チェスタトンの1929年の著書『The Thing』の一節に着想を得た考え方です。
ジョン・F・ケネディが引用したことで広く知られるようになりました。
これがその元の引用です。
There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road.
The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.”
To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."
チェスタトンの柵が言わんとしているのは、何かがそこにある理由を理解していないなら、おそらくそれがなぜ取り除かれるべきなのかも理解していない、ということです。
同じように、何かがそこにない理由を理解していないなら、おそらくそれがなぜ省かれているのかも理解していないということです。
覚えておくとよいシンプルなルールがあります。「その柵がそもそもなぜ立てられたのかを知るまでは、柵を取り除いてはいけない」
この考え方はExercismにどう関係するのでしょうか？
Exercismでは幸いなことに、常にたくさんの人がコミュニティに参加し、考えやアイデアを投稿してくれます。
そうしたアイデアの多くは新しく、革新的で、わくわくさせてくれ、私たちの思考を解き放ってくれます。
ですから、アイデアや提案があれば、ぜひ歓迎します！
しかし、それ以上によくあるのは、これまで何度も議論されてきたアイデアが投稿されるケースです。
そうしたアイデアに返答し、決定を再検討したり再び正当化したりするのは、私たちのチームにとって非常に大きな負担になります。
この記事は、その時間とエネルギーを守るためのものです。
Exercismは、何千人もの非常に才能ある人たちによって設計され、作り上げられ、構築されてきました。
とても意図的に作られたプロダクトです。物事があるのはそこにあるよう設計されているからであり、物事が省かれているのは省かれるよう設計されているからです。
Exercismのほぼすべては、何度も何度も議論され、検討され、作り直されてきました。
ですから、アイデアを投稿する前に、自分自身に問いかけてみてください。私たちはすでにそれを検討したことがあるのではないか、そしてなぜ提案とは違うやり方でやってきたのか、と。
そして思い出してください。自分のアイデアが明白に思えるほど、これまで何度も議論され検討されてきた可能性が高いのです。ですから提示するときは、起こりうる注意点や落とし穴を添えて提示してください。
「なぜ単に……しないのか」と言いたくなったら、それはほぼ間違いなくこのカテゴリーに当てはまります。
投稿することを恐れる必要は決してありません。ただ、その前にしっかりと考え抜いてください！
例はありますか？
よくある不満は、生徒がテストに通らないコードをメンターに提出してしまうことです。
同じくらいよくある提案が、「提出する前にCLIで自動的にテストを実行すればいいのでは？」というものです。
素晴らしいアイデアに思えます。CLIがコマンドを呼び出してテストを実行し、テストが壊れていれば生徒に提出させなければよいのです。
ではまず、「コマンドを呼び出してテストを実行する」とはどういうことでしょうか。
それは、Exercismにある52の言語それぞれについて、テストを実行して結果を確認できるスクリプトを書くということです。
少し手間はかかりますが、できないことはありません。
しかし、それはそのスクリプトがWindows、MacOSX、Linuxのあらゆるバージョン・構成で動くように書くということでもあります。それは膨大な（もしかすると際限のない）作業です。
「なぜ_あらゆる_構成で動かさなければならないのか？」と尋ねるかもしれませんね。
それは、このスクリプトを実行できないと、その人がExercismを使うのを積極的に妨げることになるからです。
つまり、このスクリプトは決して失敗してはいけないということでもあります。
何らかの理由でスクリプトが動かなければ、生徒は完全に足止めされてしまいます。
そうした52*3*n個のスクリプトのどれか1つのバグで、そのOSでは生徒がそのトラックを使えなくなります。
それをどうテストしますか？
できません。
でも、--skip-testsフラグを追加すればいいのでは、と言うかもしれません。
それは良い提案ですが、元の地点に戻ってしまいます。つまり、人はいつでも好きなときにテストを飛ばせる、ということです。
ただし今度は、壊れたテストが提出される可能性がわずかに下がるため、メンターはその前提が薄くなり、テストが壊れているときの驚きや混乱が大きくなります。
「でも、一般的にはそうはならないでしょう」と反論するかもしれません。確かに、テストの実行に0.5秒しかかからない言語ではそのとおりです。
しかし、テストの実行に20秒かかる言語では、提出するために余分に20秒待たされるのは生徒にとって非常にもどかしく、最終テストを飛ばすことが当たり前になってしまうでしょう。
この会話がどこに落ち着くかはともかく、ここには一見したよりもずっと多くの複雑さが関わっていることは明らかです。考えるべき技術的な課題があり、検討すべきワークフローの問題があり、そしてトラックごとの違いがあまりに大きいため、あるトラックでは素早く簡単なことが別のトラックでは苦痛になる、という現実があります。
ですから、「なぜ提出前にテストを実行しないのか」と提案するのではなく、こんな問いを立ててみましょう。「なぜ人はテストに通らない解答を投稿してしまうのか？」
そうすると、話が面白くなってきます。
一般的な答えは、行き詰まっているか混乱しているからです。
そして助けが必要なのです。
つまり、通らないテストを提出することは、その生徒が_助けを必要としている_という、メンターにとって非常に重要な手がかりになるのです。
確かに、メンターがそのコードが「正しい」かどうかをすぐには判断できないのはもどかしいです。しかし、コードをダウンロードして実行すれば確認でき（ほとんどのメンターは自明でない解答ではそうしています）、正しいかどうかを100%の確信をもって判断できます。
そして、行き詰まって助けを必要としている生徒は、さらに行き詰まってさらなる助けを必要とするのではなく、修正をより早く見つけて提案できるメンターのもとにたどり着けるのです。
注：私たちは実はこれをサーバー側でテストを実行することで解決しつつあります。大規模で費用のかかる取り組みですが、生徒の体験を改善し、そして何よりメンターの時間とエネルギーを節約するために、取り組む価値のあるものです。
ほかに何かありますか？
3つあります。
-
こちらのSecond Order Thinkingの記事は良い読み物です。「その柵がそもそもなぜ立てられたのかを知るまでは、柵を取り除いてはいけない」という引用はこの投稿によるものです。
- G・K・チェスタトンの『The Thing』はこちらで読めます。https://archive.org/details/G.K.ChestertonTheThing。
- あなたのアイデアは本当に新しく素晴らしいものかもしれません。提案することを恐れたり恥ずかしく思ったりしないでください！
