本稿は『庭師と大工』 の抜粋と短評である。紙の本、あるいは微信読書の電子版を勧める。

『庭師と大工』の著者は、子どもの学習と発達を専門とする優れた研究者であり、心理学者であり哲学者でもある。本書の学術的な水準は高い。育児書でありながら、進化論や哲学の高さから論じる本は、やはり珍しい。

あなたは庭師か、それとも大工か

著者は、現在の中産階級に主流の、不安に駆られた育児モデル——いわゆる「しつけ」モデル——を完全に否定する。「しつけ」、英語の parenting は、1950〜60年代になってようやく形をなした言葉だ。中産階級が台頭し、伝統的な子育てが立ち行かなくなった後の流行である。このモデルは工業化生産の中でプラスの役割を果たしたかもしれないが、より複雑な未来を前にすれば、反省せざるを得ない。庭師と大工は、中国語で最良の隠喩とは限らない。大工が形を削り出すのは確かだが、中国式の庭師の傑作である「盆景」も、負けず劣らずひどい。ここでの庭師は、植物を野放図に育てることを許す者であるべきだ。「理想の」子どもなどいないというのは、多くの中国の親にとっては致命的事態だろう。子育てには二つのパラドックスがある。依存と独立、遊びと学習。どちらへ一直線に進めばいいという単純な問題ではない。

「しつけ」は出来の悪い近代の発明である

「混沌は階梯である」。子どもの混沌は人類発展の階梯だ。探索は子どもの天性であり、子どもの使命と言ってもいい。子どもに青写真を描き、枠をはめてやることが、まことに傲慢な行為だというのは、原始社会の不安定な生活環境でもそうだったし、現代と、発展の速い未来の現実でも同じだ。中国の伝統的な教育理念にある「玉は琢かざれば器を成さず」は、工業文明下の「しつけ」と意気投合し、さらにエスカレートした。この「しつけ」モデルは、学校に似た枠に沿って子どもを設計する。伝統的な教育には親子関係に基づく直感があったが、今はその直感すら教条に譲り渡している。たとえば、子どもが泣いたら抱くべきかどうか、親は直感で判断できず、育児書の指示に従う。ましてや「優秀な子」の比較競争の中の不安においてはなおさらだ。

子ども時代——人類進化の重要な戦略

著者は子ども時代の重要性を、人類の進化戦略の高さに置く。現実には、多くの親は子ども時代を、ただ避けて通れない成人準備期間としか見ていない。早く物わかりがよくなり、成績優秀で、手がかからなくなってほしいと願う。著者は進化論の観点から子ども時代の意味を分析する。これが問題の核心を捉えていると思う。この子ども時代の名誉回復は、単なる人文的配慮ではなく、認知の高さで圧倒している。「スタートラインで負けてはいけない」から始まって、一生競争し続けて生活の中で幸福になる能力を持たないか、どこかの時点で堕落して、反動的に快楽を追い求めるか、どちらかだ。

愛——進化し続けるための保障

著者は子どものへの愛を三つの層で論じる。親、祖父母、非血縁の養育者。進化論の観点から、人類が愛という形で囚人のジレンマを突破し、遺伝子の層でも文化の層でも子どもの世話の暗号を深く刻んだことを説く。愛するから世話をするのではなく、世話をするから愛するのである。私の実感では、現在の社会文化はこの伝統をある程度疎外している。「やんちゃな子」への過敏な非難が巷に満ち、子どものような完全な行為能力を持たない者に対する、予測不可能性への恐怖がある。たとえば飛行機の中で泣きわめく2歳児の母親を責める。社会全体の「しつけ」神話はこうだ。親がきちんと教育さえすれば、どんなに小さな子どもでも大人のように大人しく公共の秩序を守れる——そしてこれはまさに人間性に反している。

見ながら学ぶ

この章は、子どもが観察と模倣によって学ぶことを論じる。現存する教育制度はせいぜい数百年の歴史しかない。現代の中産階級の家庭の親は、学校教育に適応しただけでなく、そのセットをできるだけ早く自分の子どもに適用しようとし、より古く、自然な模倣学習には十分注意を払わない。よくある説明はミラーニューロンだが、それは怠惰で過度に単純化した説明にすぎない。子どもの模倣は非常に複雑で精緻で、大人の知覚を超えている（いつ覚えたのか分からない）。第一に、子どもの模倣は過程の模倣ではなく、大人の意図を理解しようとし、そこから因果関係を見つけ、自分の思考に取り込み、最終的には自分が関心を持つ結果を模倣する。大人が専門家らしく振る舞わないと、子どもはより多くを取捨選択する。大人が専門家らしく振る舞うと、子どもは細部をより多く模倣する。それが良いこととは限らない。模倣には社会的属性もある。子どもは自分に似た人をより模倣し、儀式的で実用性のない動作を模倣して集団に溶け込もうとする。現代の親への示唆は、中国の古語「身教は言教に勝る」がいつまでも古びないということだ。四六時中子どもに小言を言うより、自分をしっかりやって、子どもと良い相互作用をつくり、子どもが家庭や社会の活動に参加する条件を十分に整えてやるほうがいい。

聞きながら学ぶ

この章は、子どもが言語を通じてどう学ぶかを論じる。ここが人間が他の動物をはるかに超えている点だ。子どもは大人の話を聞くが、丸ごと受け入れるわけではない。大人が信頼に値するかどうかを判断する。その判断は多くの要素による。話し手が自信を持っているか、その分野の専門家か、話し手との関係はどうか。要するに、信頼の構築が必要だ。子どもは「なぜ」をよく聞くが、ほとんどの場合、本当に世界の原理を探求したいのだ。多くの場合、直接聞くほうが観察より効率的な学習法だ。たとえば、なぜ雨が降るのかを知りたいとき。子どもを適当にあしらってはいけないし、時々答えられなくても心配いらない。探求の熱意はとても高いからだ。子どもは大人の言葉遣いから偏見を抽出する。たとえば「日本人はみんな悪い」と「日本人には悪い人もいる」では効果がまったく違う。親がすべきは何かを教えようとすることではなく、良い相互作用を保ち、会話の中で良い親子関係を築き、「なぜ」によく答え、子どもにも「なぜ」をよく聞き、より多くの人と話させることだ。この問答が構成するのは本当の生活であって、作為的なものではない。子どもの感受性の高さゆえ、親は博学ぶることも公正中立ぶることもできず、すべては本音の流露しかない。

遊びながら学ぶ

遊びの効果は測りにくい。測った途端、それはもう遊びではないかもしれないからだ。人間に限らず、知能の発達した動物はみな遊びを好む。よくある遊び方に取っ組み合い遊びがある。子犬同士の噛み合い、子ども同士の身体のぶつかり合い。こうした遊びは子どもの社会的能力を高める。私の観察では、現在の中国の親の大半はこうした遊びを禁じている。子ども同士が少し身体的にぶつかると、大人が喧嘩を始めそうになる。遊びは好奇心に駆られる。子どもの遊びは科学者の実験に少し似ていて、仮説と検証、ランダムな探索がある。人間は他の動物より「ふり遊び」が得意だ。これは反事実的推論の能力で、虚構の、ある程度論理のある世界を構築する。文学作品にも同じ力がある。ふり遊びの得意な子は他人の考えをより理解できる。架空の友達を持つ子も少なくなく、それは大人をよく怯えさせる。子どもの遊びの中で、親は導くのではなく支えるべきだ。導くと子どもの探索の考えが途絶え、大人の段取り通りの退屈な模倣になる。親が積極的にできるのは、遊べるものがより多くある環境をつくることだ。ただしそれはいくら金をかけるかでは決まらない。棒切れ一本が良い玩具になることもある。実際、大人も肩書きを下ろせば、子どもの遊びに加わるのを嫌いとは限らない。

練習しながら学ぶ

この章は主に学齢期の子どもと学校教育を論じる。学齢という概念は学校教育に基づくが、子どもの心理発達には確かにそうした変化の層がある。探索型の学習が主から習得型の学習が主へと移行し、成人生活の基礎を築く。習得型の学習には練習が必要で、脳神経の再構築であり、技能を無意識の状態に変える過程だ。別の角度から見れば、これも一種の退化である。現在の学校教育は工業化生産とともに生まれたもので、人間の常態ではない。それ以前の教育は徒弟制の教育であり、このモデルは今でも一部の領域で主導的な役割を果たしている。スポーツや音楽の学習のように。学校教育が育てるのは「学校に通うのが上手い人」だ。一斉授業という形式は、子どもに高い集中力を要求する。そしてその能力は、古今の現実の中で、必ずしも有利な能力ではない。しかしアメリカの現代教育体系は、長時間集中できない子どもをますます注意欠陥多動性障害と定義する。中国も同じ傾向だ。集中力という特性のスペクトル上で、各子どもの位置は違う。それは進化の多様性にすぎない。著者は、学校がさまざまな子どもに適応すべきだと主張し、子どもに薬を飲ませるべきではないと言う。進化の観点では、思春期は人間が成人へ向かう過程であり、人の動機の仕組みと制御の仕組みに関わる。思春期の子どもは同年代の評価に影響されやすく、冷静な大人には不可解に思える報酬をより重んじる。現代の子どもは思春期の到来が早まったが、徒弟制の中で育った子どもほど本当の仕事の経験を持たず、自分の行動を制御して本当に意味のある成果を出すことができない。子どもが科学者を職業にしたいと思っても、実際に科学者と一緒に働けるのは二十代になってからだ。学校教育も家庭教育も、庭師モデルであるべきだが、現実はむしろ大工モデルが多い。

テクノロジーと子どもの未来

あなたの子どもは情報時代の先住民で、あなた自身は移民にすぎない。うちの子がろくに話せないのにiPadを器用に操作するのを見て、私は著者の判断に深く同意した。現代の親のテクノロジーへの恐怖は新しい恐怖ではない。ソクラテスは、文字を書くという当時の新テクノロジーに深い懸念を表明した。そしてその懸念は現実になった。我々は口承ではなく文字による継承に、より依存するようになった。しかし人類の文化は滅びず、むしろ大いに栄えた。テクノロジーが次の世代をどこへ連れて行くのか、唯一確かな答えは「分からない」しかない。子どものすべてを制御し、未来の人生を段取りするなど、なんとおかしなことか。青少年は新しい文化の中で育ち、過去と同じ対人関係の難問に直面する。いや、それ以上だ。ネット上の見知らぬ他人の悪意に向き合う必要がある。この避けがたく滑り込んでいく未来こそ、この世代の運命だ。親としてできるのは制御ではなく、かといって「自然に任せる」でもなく、過去と未来をつなぐ橋になることだ。子どもは伝統の中で育ち、栄養を吸収し、また自らの革新を持つ。我々は子どもと一緒に本を読み続けられるが、電子機器と隔絶することも絶対にできない。この世界の本当の姿がそうだからだ。ここまで書いて、少し感傷的になる。結局は長江の後浪が前浪を押し、前浪は砂浜で死ぬ。世代には世代の責任があり、世代には世代の哀しみと愁いがある。

子どもを育てる意味

哲学的に言えば、子どもを育てる意味を定義することはできない。子どもができる前と後のあなたは、まったく同一人物ではないからだ。多様な価値観はディンクスの考えを尊重するが、自分が持たなかったものが価値ないふりを決してしてはいけない。社会発展の観点では、現在の社会の運営の仕方は親子関係を傷つけている。親の仕事と子どもにはほとんど関係がない。社会は子どもの養育に報いない。子どもは大人の競争の負担になる。かつての顔見知りの社会では、共同体の成員がみな子どもに親切だった。冷たく独立的な都市生活では、そうしたものはもう存在しない。あるのは、子どもが早く成熟して見えることを求める圧力だけだ。ネット上の「やんちゃな子」への容赦ない打ち殺しも、発端は一部の親の「大きな赤ん坊」のような振る舞いだが、社会全体の子どもへのある種の差別を反映してもいる。顔見知りの社会が避けがたく解体した後、政府と社会が子育ての責任を負わなければならない。子育てにせよ老人の扶養にせよ、社会全体が考え直す必要がある。赤裸々な経済的利益の衡量の外に、考慮すべき問題はないのか。

親になるとは、一連の矛盾の中で均衡を探す芸術である

良い育児書は断定的な答えを出せない。この本の結論もそうだ。それが真相だからだ。毎日、私は子どもに硬軟さまざまな要求をする。他の人を妨害したからかもしれないし、単にこうするほうが彼にとって良いと思うからかもしれない。しかし毎日、その要求が妥当か、必須か、自分が一人合点しているだけではないかと疑う。「どうやって」「どのように」で始まる育児書は数千、数万とある。それらはたいてい断定的に方法をくれる。しかし、自分を省みる限り、子どもの前で断定的ではいられない。どんな専制的な親も、子どもがいつの日か独り立ちすることを望むと認める。しかし幼い子どもには確かに親の助けが要る。この依存と成長・独立の矛盾は永遠で、万能の解決策はない。私の実感では、子どもは磁器ではない。親の一、二度の誤りで粉々になったりしない。恐ろしいのは親の断定だ。これがきっと君のためになる——反省のないことが、すべての悲劇の起源である。この本のような良い育児書は、あなたの反省に思考の起点を与える。しかし読み終えて、すべてはようやく始まる。

しかし、ソフトウェアはやはり科学技術の範疇に属するものであり、デバッグもまた技術的な仕事であるべきだ。「デバッグの法則」（Debugging Rules!）は、デバッグ技術を扱った珍しい書物である。九つの普遍的な原則は、ソフトウェアとハードウェアの開発・保守に当てはまるだけでなく、日常生活にさえ応用できる。この本を見つけるのにも少し苦労したが、幸いなことに図霊コミュニティには正規の電子書籍 が売られていた。

正直に言えば、著者が挙げる例の多くはハードウェア寄りで、理解するのにやや隔たりを感じる。しかし九つの原則は実に実用的で、私の以前の開発・デバッグの経験の中でも無意識にいくつかはまとめていたかもしれない。それでもこの本を読むと、武術の心法を手に入れたような感覚がある。読んだ後、以下で九つの原則をもう一度たどり、理解を深める。

1 システムを理解する

これは最も重要な原則である。バグを分析するには、当然システムがどのように動作するかを理解する必要がある。そのためには基本原理をいくつか学び、身につける必要があり、具体的なクラスライブラリ、ツール、技術については関連するドキュメントを真剣に読む必要がある。私が公式ドキュメントを真剣に読む習慣を身につけたのはここ数年のことである。検索エンジンの発達によって、我々は google 指向プログラミングの習慣を身につけてしまった。問題に直面すると、いつも一気に解決しようとする。結果として多くの回り道をすることになる。道標を見る時間を惜しむからだ。本書は特に「一字一句」マニュアルを読むことを強調しており、これは浮ついた人間への頭からの一撃である。システムを理解せずにデバッグを始めることと、原理を理解せずにコードを書くことは一脈相通じるもので、俗に「偶然指向プログラミング」と呼ばれる。

2 失敗を再現する

この原則はバグを再現することの重要性と方法を説く。バグは必ずある特定の条件下で発生する。その特定の条件を丹念に突き止めれば、半分は成功したも同然である。私のハードウェア保守の経験から言えば、バグを発見した人がその過程全体を詳細に記録できれば、非常に役立つ。多くのバグは発生条件が厳しく、だからプログラマの口癖の一つが「私のところでは問題ないです」なのである。こうしたバグに対しては、まずシミュレーションの方法を見つけるのがよい。たとえばソフトウェアの動作や相互作用の速度を上げる、ストレステストを行うなどである。次に、ソフトウェア内部に詳細で合理的なバグ記録の仕組みを持ち、内部から再現条件を見つけやすくする。

3 考えず、見る

この原則は観測の重要性を強調する。空想するよりも現実に向き合うことが大切である。言語は思考に影響する。だからバグに遭遇したときの口癖は「ちょっと見てみます」であるべきで、「たぶん〜が原因だと思います」ではない。我々はあらゆる手段を尽くしてバグの細部をはっきりと見るべきであり、成熟したプログラムにはデバッグ用の基盤が備わっているべきである。私の経験から言えば、少なくともログは不可欠である。初級のプログラマはブレークポイントだけに頼ってデバッグする習慣があるが、問題はブレークポイント自体がプログラムの実行フローを変えてしまうことである（特にマルチスレッドの場合）。もちろん推測も依然として有用で、観測の範囲を絞り込む助けになる。あるいは少なくとも観測の優先順位を決めるのに役立ち、そこで経験が生きる。しかしどうであれ、経験は観測に代わりえない。

4 分割統治

二分探索法は探索の時間計算量を線形から対数に変えられる。これはプログラム中の探索アルゴリズムだけでなく、デバッグ時の方法論でもある。システムにこの意識があれば、鍵となるのはシステムをどう分割するかであり、ここで原則1に戻る。少なくともブレークポイントでデバッグするとき、バグの位置を見つけるのに二分法が使えるし、ログを挿入するときにもこの原則を応用できる。さらに本書ではバグ同士が互いに影響し合う現象にも触れている。私はむしろバグのシーソー現象と言ってもよいとさえ思う。解決の道は一つも見逃さないことである。バグをデバッグしているうちにコードの品質があまりに悪いことに気づき、リファクタリングが必要になることもある。そうでなければ砂の上に高台は築けない。効果的なリファクタリングを経て、バグが自然に発見され解消されることさえある。

5 一度に一箇所だけ変える

この原則は実験科学における対照の原則に似ている。一度に一つの変数だけを考察し、正常な状況と異常な状況を比較し、いかなるテスト条件の差異も見落としてはいけない。前の条ではバグを一つも見逃さないと言ったが、一つずつ片付ける必要もある。リファクタリングの際も、理解していないコードをやたらにいじらないよう注意すべきである。多くのコードの危険性は、一箇所を触ると全体に響くことにある。これがバグ修正時の最大のリスクだと思う。しばしば一つのバグを消すと同時にいくつかのバグを増やすことになる。やはり原則1に戻り、システムを理解することである。とはいえ、先人が書いたコードを理解するのは容易ではないこともある。これはまた、コードを書くときに徳を積むべきことを我々に示している。コードはコンパイラのためにあるのではなく、後に我々のコードを保守する人のためにあるのだ。

6 監査証跡を残す

この原則は記録の重要性と方法を説く。医者が診察するのと同じで、適切な質問をし、具体的で有効な答えを出す必要がある。私の経験では、バグのデバッグを始めると、人はすっかり深みにはまって抜け出せなくなることがある。記録を取ることで、思考の泥沼から自分を引き離し、デバッグの計画と方法を絶えず修正できる。専用のシステムソフトウェアでは、ソフトウェアの利用者に、バグの発生状況を有効な言葉で記録する方法を訓練する必要がある。記録がなければ、デバッグする側は適切な質問で利用者の記憶を呼び覚まさねばならない。また、深夜に解決できないバグは一眠りする必要があると思う。拡散思考が自動的に働き、たいてい朝には解決している。

7 プラグを確認する

この原則は、いわゆる「初歩的なミス」について述べている。母が「パソコンのスピーカーから音が出ない」と言ってきたら、まず電源が入っているかを聞く、という類である。あるいは main 関数を mian 関数と書いてしまうとか。一度、ブレークポイントを置いてデバッグしてもブレークポイントで止まらず、後で分かったのは、似たコードが二箇所あり、ブレークポイントを間違った場所に置いていたことだった。シナリオと経験に照らして、そのシナリオでよくある初歩的なミスを犯していないか自問すれば、多くの場合すぐに効果が出る。多くの電気機器の取扱説明書の故障 FAQ でも、プラグの確認が強調されている。初歩的なミスが「初歩的」なのは難度であって、頻度ではない。

8 新しい視点を得る

この原則は助けを求めることと交流について述べている。ここで重要なのは、他者の視点によって自分の思考の固定観念を打ち破ることである。だから相手には現象だけを詳細に説明し、自分の推測は言わないほうがよい。相手の判断を汚染してしまうからだ。プログラマにとって、このときの google 指向プログラミングの力は驚異的である。おそらく九割の問題は、実際に質問する必要はなく、適切な検索語を見つけて検索すればよい。中国のプログラマにとって、英語で検索することは必須の技能である。もちろん、見つけたものを本当に理解することも非常に重要で、薬を見たらすぐ飲む、ではいけない。もし google で本当に検索できなければ、あなたのレベルが少し高い証拠である。そのときは stackoverflow などのコミュニティで質問すればよい。

9 バグを修正しなければ、バグは依然として存在する

この原則は、甘い期待を抱くな、バグが一瞬顔を出しただけだからといってダチョウ政策を取るな、ということを述べている。来るべきものは必ず来る。報いがないのではない、時が来ていないだけである。もちろん実際の状況は複雑でありうる。ソフトウェア工学はもともと時間・コスト・品質の妥協の産物である。しかし、たとえ一部のバグを見逃すとしても、それによって生じうる結果を分析し、十分な防御機構を築くべきである。だから多くのソフトウェア認証体系にはソフトウェア安全水準の規格がある。ここにはバグの再現と一を聞いて十を知るという問題も関わる。本当にバグの原因を見つけ、有効な修正手段を提供したことを確認し、同様の問題をすべて洗い出す必要がある。たとえばメモリリークを一つ修正したら、そうしたリークを引き起こすすべてのコードを修正しなければならない。

附記：デバッグしやすいコードの書き方

デバッグの原則から逆に見ると、ソフトウェアの構築自体にも大いに役立つ。何しろデバッグは穴を塞ぐだけのものであり、書かれるコードのバグが少ないほうがよく、デバッグのときに便利なように手段を多く用意しておくのがよい。ここでも個人の経験を簡単にまとめておく。不断の改善が必要かもしれない。

1. プログラムにはログの仕組みを備えるべきで、プログラムの debug 版ではデバッグ情報を出力しやすくする。release 版であっても、ソフトウェアに問題が発生したとき（たとえば C# で例外が投げられたとき）の詳細な状況を記録すべきである；
2. 人間が読むのに適したコードを書くべきである。そうでなければ後の保守をする人が読んでも分からない。どうデバッグせよというのか。どう書くかは『コードコンプリート』に最も詳しく書かれている。各種の慣習的な書き方のほかに、相手の身になって考えることも重要だと思う；
3. 各種のクラスライブラリやツールを使うときは、できるだけ原理を理解し、公式ドキュメントを丹念に読む。たとえばメモリリークをどう防ぐか、マルチスレッドの状況にどう対処するかを詳しく説明しているクラスライブラリもある。よく見てから使えば、禍根を植えることが少なくなる。少なくともデバッグのときに蠅のように当てもなく原因を推測する必要はなくなる；
4. テストしやすいコードを書く。そうすればデバッグのときに問題を切り離しやすく、二分法も使いやすい。この点は TDD の実践が比較的十分に論じており、私自身も強化する必要がある。