AWS 認定 Solution Architect - Professional に合格した

41歳で自動車免許を取ったというエントリを前回書いたけれども、実は並行して AWS の Solution Architect Professional の試験勉強をしていた。免許で長期休暇を取ったこともあり、受験のタイミングに難儀していたのだが、先日ようやく受けることができ、無事合格できた。点数はわりとギリギリだったけど、この試験は答えが明らかではない際どい問題が多いのでこんなもんかな、と。*1

AWS の試験は、AWS を理解するきっかけづくりに最適だと思う。特に Solution Architect - Associate は教本も増えてきており、一週間ほどで AWS の主要な要素が理解できるようになっているのでおすすめできる。Solution Architect - Professional は範囲が広いわりに教本らしい教本もなく、試験内容自体の難易度も高いが、こんな機能もあるんだという気付きに繋がり個人的には非常に役に立った。一点残念なのは、試験の模範解答が手に入らないところ。受験対策だから仕方ないとは思うものの、誤った理解を正す機会が得られないのは残念だ。

なお、勉強は Udemy で講義と模擬試験の英語版を購入して実施した。だいたい1万円強だったか。受験費用も模試含め 2万円ほどかかる*2ので、会社から合格後の報奨金が出なければ絶対に受験しなかったと思う。

仕事では AWS、GCP、Azure、そしてオンプレと広く薄く雑多に関わっているのだが、使ってみると、それぞれ会社のカラーが出ていて面白い。

AWS は、質実剛健というか、マイクロサービス的な提供がされていて、簡単なことでも複数のサービスを組み合わせないと実現できないため、AWS特有の広範な知識を求められる難しさがある。一方で、組み合わせれば大抵のことはできるようになっているのも事実であり、痒いところに手が届くという感覚がある。ここは不便だなと感じると、すかさず新サービスでフォローされることが多く、そういう意味でも安心感がある。

GCP は、シンプルで高品質な感じがある。3クラウドの中では一番わかりやすいし、ひとつひとつのサービスの出来が良いように感じる。一方でシンプルすぎて痒いところに手が届かない感じがある。例えば、CloudSQL と Spanner の中間がないところとか。Spanner はすごいけど、欲しいのは Amazon Aurora なんだけど的な。

Azure は、コンソールのインターフェイスはよくできている。さすがは UI の会社だけある*3。とはいえ、ひとつのサービスにいろんな機能がごちゃっと付いてきたり、サービス間の関連がわかりずらかったり、新機能にもとってつけた感があったりと。どこがとはっきり言えるわけではないのだが、やっつけ感を強く感じる。良くも悪くも Microsoft 製品っぽいというか。

まぁ、三者三様とは言っても、どのクラウドを採用するか迷っている会社があったら、個人的には AWS を押す。最安値での環境構築はできないかもしれないけど、やりたいことはだいたいできるという安心感は大きい。この機能以外はいらない、ということが確実なら GCP を使うのは全然ありだと思う。Azure は……多くを語るまい。

大企業の基幹系の仕事が多いから、いまだオンプレに触れる機会も多いけど、個人的にはもはやオンプレはリスク以外の何物でもないかな、と。好きな時にリソースを増減させられないということがいかに行動を制約するかを考えたら、一見金額が安く見えたとしてもオンプレにするという選択は難しいように思う。特にディスクについては、自由に増加可能なクラウドと事前購入が必須なオンプレでは見積り以上に差が出てくるのではと。

*1:実際、海外の対策サイトを見に行くと過去問の回答に対する意見が割れている場面をしばしば見かける。

*2:本当は 3万円以上かかるが、Associate を取得すると半額チケットが貰える

*3:というより AWS Console がわかりづらすぎなだけなんだけど

41歳にして自動車免許を取った

孔子曰く、「40歳にして惑わず」とは言うものの、40歳を超えたくらいで、そうそう人間変わらない。うんざりするほど子供っぽい（余談だが、仮面ライダージオウはやたら面白い）し、むしろ、大人にならなきゃ、という抑圧から解放され、より幼くなっているのではと思うこともある。

感覚的にはそんな感じなのだけど、一方で、せいぜい40年しか人生残っていない、という事実にも気付かずにはいられない。そんな感覚は30代にはなかった。今までは、いつかやればいいや、と思っていたのだが、もはや今やらないと一生やらないことが確定してしまうのだ。

そこで自動車免許だ。

正直、自動車免許が絶対に必要だと思ったことは一度もない。周りの話を聞くと、身分証明書として便利という声が多いのだけど、写真付きのマイナンバーカードで十分なので住基カードより前の知識で止まっているのだろう。*1

東京暮らしが人生の半分を過ぎた今、車に乗る必然性はまるでない。せいぜい、旅先で自動車乗れたら便利だろうな、と思うくらいか。とはいえ、このまま車を運転することなく死んでいくのか、と思うと怖くなってきた。車に乗る必然性はないとはいえ、子供の時はゴーカートが好きだったし、レースゲームも大好物だ。それ以上に、日本人の通過儀礼としての自動車免許を取らなかったことが、自分の幼さに繋がっているのかもしれないという思いもなくはない。

そこで関係各所と調整のうえ、なんとか２週間の休暇をもらい、６月～７月にかけて、福島の湯本自動車学校という場所に合宿免許に行ってきた。

40代で自動車免許を取る人も珍しかろうから、どんな感じだったかを簡単に書いておこう。

• 申し込みは「ローソンの運転免許」で行った。トラブルがあったとき大手の方が仲介に入ってもらいやすいかもしれない、という思いでそうしたが、申し込んで振り込みしたらすんなり終わった。資料が送られてくるので、その指示に従がえば良いだけで特に迷うようなところはなかった。
• 費用的にはAT限定免許で20万円強だった。東京で免許を取ると、合宿でなくても30万円を超えるので、地方で合宿免許というのはとても経済的。宿舎は予想外に快適だったし、飯もうまかった（お昼の弁当はかなりいまいちだが）。お風呂は宿舎含め温泉で、日帰り入浴にもあちこち行った。湯本温泉は古いせいか露天風呂が少なくてそこが残念ではあった。
• 半分は夏休み気分で行った（だから温泉地にした）のだが、休日なしの9:00～19:30でスケジュールが組まれているため、休暇感はまったくなかった（途中に空き時間はそこそこあるとはいえ）。特に仮免の見極めに落ちた辺りで、休暇の延長が必要になり、かなり焦ることになってしまった。
• AT免許では、第一段階で技能教習が最短12時間となっているが、まったくの素人が乗れるようになるには短すぎるように感じたので、数日、日程が伸びることは覚悟した方がよいと思う（MTだと15時間だが、このくらいの時間が最低ラインではなかろうか）。
• 車の運転が思っていたものとまったく違っていた。もっとシステマチックなものかと思っていたのだが、ありえないくらいメカニカルだ。ハンドルやアクセル/ブレーキの使い方もレースゲームとまったく違うので当初すごく戸惑った。
• 昨今、ブレーキとアクセルの踏み間違い事故が話題になることが多いが、この UI なら起こって当然ではと思ってしまった。ブレーキも最大限押し込むと徐行速度になって、離せば止まるとかになっていれば、そんな事故起こらないのに。ほんと、テスラがんばれ、と言いたい。
• 結局最後まで、適切な速度、安全確認の手順、車体間隔がわからなかった。ダメ出しばかりで何が正解なのか良くわからない挙げ句、教官によって言うことがぜんぜん違ったりするので、とても戸惑った。教育方針のすり合わせとかしないもんなのか？　速度に関しては、標識がないから60kmと言う教官もいたのだが、調べる限り、片側1車線なら50km、片側2車線なら60km が上限となっているそうだ*2。教科書にすら載っていないが。
• 車体の間隔に関しては実際に降車して体験するなどの講習があった方がよいのではないか。感覚だけで覚えるには時間数が短すぎるように思う。本線合流に至ってはまったく事前説明がなく、いくらなんでも無理があるだろ、という感想しかない。
• これだけ多くの人が免許持っている割に、合理的とは言い難い制度と仕組みで構成されており、世の中想像以上に適当なものだと実感した。
• 正直、取得には大変苦労した。学科試験も決して簡単なものではなく、よくこんな大変な試験を世間の大半が通過してるもんだと思った。これに合格できるなら日商簿記とか情報処理試験とか余裕で合格するはずなので、みんなもっとまじめに資格試験受けた方がよいのではないか、という気持ちになった。

本当は40歳のうちに免許を取ってしまいたかったのだが、本免学科試験は居住地でないと駄目とのことで、最終的には誕生日を過ぎた7月後半に免許発行ということになった。とはいえ、免許の有効期限は誕生日が基準となるので、結果オーライと言えなくもない。

いまだ車線変更とバックでの駐車がうまくできないなど、まだまだ初心者を脱しきれていないので、しばらくは週に一度くらいは乗ろうかな、という感じ。

*1:マイナンバーカードはコピーできる条件に制限があり、そのせいで身分証明書としての使用を拒否するお店があるのがやや面倒ではある。専用ケースに入れた状態での表面ならば、身分証明書として使えることになっているのだけど。その意味で住基カードより利便性が落ちているのは残念だ。

*2:実際には交通量などによってもっと細かい規定がある。

老害の誕生

近年ラジオをよく聞くようになっていたから、ピエール瀧の逮捕には大変驚かされた。ここ数年、ピエール瀧とリリー・フランキーが映画に出過ぎ問題がしばしば取り沙汰されていたが、こんな結末になるとは思いもよらなかった。

個人的には、逮捕されたとはいえ、麻薬で逮捕であり 20 代の頃からの常習者だったようだから、節度ある使い方をしていたわけで、役者や CM に引っ張りだこの状況で立場的にやっちゃだめだろ、とは思うものの、行為自体には特にどうも思わない。日本にもヒロポンが広く使われていた時代もあったし、ある種の宗教、音楽ジャンル、文化スタイルとは切っても切り離せないものでもある。スティーブ・ジョブズも LSD に影響を受けた人だし、ついこの間はイーロン・マスクが番組で大麻を吸っていた。もちろん、素晴らしいものであると言いたいわけでもない。アルコール依存症がそうであるように、危険度の高い嗜好品であることには変わりない。リスクある嗜好品をどこまで許容するかは国民の総意が決めることだ。日本では一律 NG という判断がなされており、そこには合理性がある。だから、逮捕されるべきではなかったなどというつもりはない。

むしろ関心は、ピエール瀧逮捕の結果、過去の出演作や音楽作品の販売・配信が一斉に停止してしまったことの方にある。ただ、一般に言われている「他人に迷惑かけたわけでもないのに配信停止は過剰反応では」という論点とは多少異なる。むしろ、ピエール瀧が連続レイプ殺人魔であったとしても、作品は切り離して扱うべきなのか、ということの方にある。

ぷらすと by Paravi という番組で、映画・音楽ジャーナリストの宇野維正氏がマイケル・ジャクソンという天才が生み出した偉大な芸術を過去のゴシップ程度で潰すべきではないという論陣を張っていたが、私も感情的にはまったく同意見だ。犯罪は犯罪、やはり憎むべきものであるが、天才の生み出したものはそれ以上の価値のある希少なものだと感じる。被害者がいるのに、彼・彼女らの感情は無視するのか、という批判がある。たしかにそうなのだが、天才の価値はそれらの犯罪行為すら過小に評価せざるを得ないくらい重要であると思いたい。

誤解を恐れずに言うならば、犯罪行為はある意味「現実の」出来事だ。下世話で、狭く、閉じた世界の一部の人々の話である。一方で、天才の為したことは、世界に広く影響力を及ぼす。犯罪はどこにでもあり、誰にでもできるが、天才の偉大な成果物は希少であり貴重だ。

人権無視の酷い発想のように思えるかもしれない。しかし、これはほんの数年前までは一般的な捉え方だった。スティーブ・ジョブズのひどい人間性も、ロマン・ポランスキーの悪行も皆知っていながら、それを許容してきたのだ。

私に限って言えば、今でも天才の為したことの方が、その犯罪行為より重要だという考えを捨てきれない。しかし、このような考え方自体が古臭いものになりつつあることはひしひしと感じる。今はまだ MeToo 運動が一過性の出来事に見えているから抵抗する人も出てくるが、時代が移っていけば「何を当たり前のことを言ってるの？」となる可能性は否定できない。

チンギスハーンが攻めてくるたびに村人全員が虐殺される時代と現代では、殺人に対する倫理的な観念が異なるように、あるいは、今ではオフィス内でタバコを吸うことが異常なことになったように、「天才性」よりも「社会規範を守ること」の方が重視される時代になりつつある。個人的にはそのことをとても寂しく感じるけれども、時代が変われば物事の捉え方、その基準も変わっていく。当時は人気があった人が、その後顧みられないこともよくある話だ。

なるほど、こうして老害は生まれるのだな（と地球最後の男的なオチ）

2018年に読んだおすすめのビジネス書５選

昨年、40歳を超えてからというもの、残りの人生どう過ごすべきか考えることが多くなった。いっそ、そのことを書くのも新年一発目としてはいいのではないか、と思ったのだが、あまりにも陰々滅々とした内容になるため、昨年読んだビジネス書の紹介をすることにしてみた。

過去の文章を読んだことがあれば、私がいかにビジネス書のことを快く思っていないか、ということがわかるかと思う。多くのビジネス書は根拠に欠け、成功譚を大きく取り上げる一方、失敗した事例は端から切り捨てられている。

しかし、その一方でいろいろなビジネス書を読むうちに、成功者がなぜそのような結論に至り、決断に至ったのか、というプロセスには意味があるのではないか、と思うようになった。経済政策も同様ではあるが、学術的結論を待つには人生は短すぎる。限られた時間の中で有効な手を打たなければならない時、何を理由に実行したのか、そこに興味を覚える。

１冊目：正垣泰彦著「サイゼリヤ　おいしいから売れているのではない　売れているのがおいしい料理だ」

サイゼリヤ おいしいから売れるのではない 売れているのがおいしい料理だ (日経ビジネス人文庫)

サイゼリヤ社長がノウハウを書いた本。冒頭から店を出したものの客は来ないわ、客同士の喧嘩が原因で火事になり店舗を消失するわ、とツカミも完璧なのだが、今のサイゼリヤになるまでに行った施策となぜそなければいけないのかという理屈が事細かに語られており、とても為になる。飲食店に限らず、この本で語られていることを自分の業種だとどうだろうかと置き換えて読むと、いろいろ気付かされることもあるのではないだろうか。

２冊目：大竹慎太郎著「起業３年目までの教科書」

起業３年目までの教科書　はじめてのキャッシュエンジン経営

起業を確実に成功させる驚きの方法が書いてある。一般にこういうのは眉唾だと思うのだけど、この本の結論にはおおいに納得させられた。結局のところ、起業を成功させたければ、情熱とコミュニケーション力だけあればよく、ビジネスモデルなんてものはビジネスの拡大期にでも考えればいいのだ、という身も蓋もない話。

３冊目：島田潤一郎著「あしたから出版」

あしたから出版社 (就職しないで生きるには21)

資産も実績も人脈も何もない著者が、情熱だけで翻訳権を得て、和田誠や高橋和枝に挿絵を頼み、出版社を立ち上げた経緯を記した本。情熱の力は何物にも勝る！

４冊目：パティ・マッコード著「NETFLIXの最強人事戦略」

NETFLIXの最強人事戦略 自由と責任の文化を築く

この本で書かれているノウハウは基本的に気が狂っているので、普通の日本企業が真似するのはやめた方がいいだろう。トヨタのかんばん方式同様に、NETFLIXの会社の仕組み、培ってきた文化に最適化されただけかもしれず、あまり一般化するような話ではないように思える。

ただ一方で、世間と常識とされている組織運営のノウハウが本当に意味のあることなのか考え直す一助にはなるように思う。最近、ホラクラシーという組織論も出てきているが、従来型の組織運営スタイルが本当に効率的なのか、問い直されるフェイズに来ているのは確かだ。

５冊目：オースティン・クレオン著「クリエイティブの授業」

クリエイティブの授業 STEAL LIKE AN ARTIST "君がつくるべきもの"をつくれるようになるために

ビジネス書というより自己啓発書に近いものだが、クリエイティブなことを始めるためのガイドとして素晴らしいと感じたので紹介したい。この本の良いところは、「100%のオリジナリティなんてない」、「まずは好きなアーティストから盗め」などアドバイスがいちいち実践的という点。「定職を持とう」「平凡に生きよう」みたいなアドバイスもある。

悩んだとき、人生に躓いたときに読み返したくなる一冊。

AWS Lambda が AppEngine になった日

11/30 の発表で、AWS Lambd が ALB のバックエンドとして使えるようになったという発表があった。

話題としては、同時に発表されたLambda の COBOL サポート（なんでや）に完全に隠れてしまったが、これはものすごく画期的なサービスだ。

前回「サーバーレス・コンピューティングの終着点」という記事を書いたが、データベース以外の部分についてはこれが実現したと言っていい内容となっている。

GCP には大昔から従量課金のアプリケーション・サーバーとして AppEngine が用意されていたが、AWS には Elastic Beanstalk という単に実行環境がプリセットされた EC2 や使い勝手が悪い API Gateway しかなかった。

今回のリリースで、AWS Lambda が ALB のバックエンドとして使えるようになったことで、Tomcat や Express にあたる部分として Lambda がその役割を担えるようになった。しかも、Lambda の起動時間の遅さを ALB のヘルスチェック機能を使うことでウォームアップ可能というおまけ付きだ。

実際、簡単なプログラムを使って確かめてみたが、ウォームアップ後であれば、1リクエストあたり 60ms で返答がある。十分なレスポンスタイムだ。しかも AppEngine とは異なり、1リクエスト15分までは待つことができる（お金はかかるが）。時間のかかる作票処理にも対応できる。

現在の Web アプリケーションは、仮想DOM を使ったクライアント部分とサービス呼び出しのAPIを分離するのが一般的となっているが、前者については S3 など完全に static なアプリとして提供し、後者については Lambda を用いて処理を行う、というのがベストプラクティスになるだろう。

残念ながら現時点では RDBMS までサーバーレスにするのは難しい（Aurora サーバーレスはあるものの、起動時間の問題で Web アプリの要件には適さない）。当面は DynamoDB のような NoSQL で、という話になるだろうが、やはり使い勝手や管理面で問題になる。リクエスト起動可能な RDBMS というのが次のホットトピックになるのではないかと思われる。

サーバーレス・コンピューティングの終着点

最近、クラウドはもはや前提となり、さらにサーバレスが当たり前に使われるようになってきている。サーバーレスという言葉が出ると、サーバーばないという話ではないよ、という話が出たものだったけれど、もはやそんな枕言葉が不要になるくらいに普及している。

クラウドで開発が変わるという話もあったが、Google が最初に提唱した PaaS 的な方法論はあまり流行らず、従来型の三層アーキテクチャ（Web-AP-DB）を実現できる IaaS+α を推し進めた Amazon の AWS が勝利を得た結果、開発手法そのものには大きな変化はなかったように思う。しかしそれも、サーバーレスの登場でフェイズが変わるかもしれない。

究極のインフラ環境というものを想像したとき、制約を無視すれば無償で無制限に資源を使えるというものだろうが、経済学が教えるように資源は有限である。その前提で考えれば、使った分だけコストがかかる、が真に実現できた状況こそ究極のインフラ環境と言えるだろう。

それがクラウドなんでは？　と思われるかもしれない。しかし、例えば、EC2 にしろ RDS にしろ、起動しているか起動していないかで決まっており、CPUやメモリなど実際のリソース使用量によって決まっているわけではない。

もちろん、スケールアップに頼るのではなくスケールアウトすれば良いわけだが、その粒度が問題となる。サーバーレスの登場で従来はサーバー単位だったものがリクエスト単位にまで分割できるようになった。

すでに「サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス」という書籍が出ているけれども、おそらくこれからのWebアプリケーションはこのような方法論がベースになるだろう。

HTML/JavaScript 層は、CDN やオブジェクトストレージにも配置できる静的リソースとして作成し、そこから API Gateway を通してREST でサーバーレスの処理を起動する。すでに静的リソースに関しては、ほとんどタダみたいな金額で公開できる。処理はサーバーレスとなり、使用した分だけ課金される、というだけでなく、スケールアウトも容易となる。現状は、DynamoDBのような NoSQL だけが使用量に応じた課金という体系となっており制約があるものの、Aurora がサーバーレス化されたように使用量での課金が可能な RDBMS が次の選択肢として出てくるだろう。

ここまで来れば、残された課題は、起動時間の遅さ（レスポンスの悪さ）だけだが、一定数の常設サーバの存在さえ許してしまえば問題ではなくなる。現時点では、サーバーレスとウォームアップの組み合わせをうまく扱う方法はないが、Kubernates の Knative が発展すれば自然にできるようになるだろう。今はサーバーレス＝AWS Lambda という風潮が強いが、Knative のように特定のプラットフォームに縛られないサーバーレス基盤が発展していき自由度も高まっていくのではと思う。

このようなシステム構成が一般的になれば、Git リポジトリと資源の制約情報を与えるだけで、すべてをよろしくやってくれる究極の DevOpts が実現できるのではないかと思うし、世の中そこに向けて急速に進んでいくと考えられる。

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス

褒めるべきか叱るべきか、それが問題だ（続）

以前、「褒めるべきか叱るべきか、それが問題だ。」というエントリを書いた。ただ、そのときにはうまく考えをまとめることができず書けなかったことがある。それは、「怒らないためには期待しなければよいのではないか」という点だ。

昨今、「アンガーマネジメント」という言葉が流行っているが、その方法論のひとつに「こうあるべきを手放す」というものがある。私自身を振り返って、なぜ自分は怒りの感情を持ってしまったのかと自己分析すると、ほとんど「期待したとおりに相手が行動しなかった」場合だったと思う。相手に対し怒りを覚えるのは、当然それ相応の期待や予測が存在するからで、そこに何らかの期待がないならば、怒る理由自体がそもそも存在しない。

だから、怒らないためには、いかに「期待を持たないか」ということが重要になる。とはいえ、一方で「期待を持たない」ということは、果たして良いことなのだろうか、という疑問もある。期待というのはある種のこだわりの表れであるし、こだわりというはその人が伝えたいことであるわけだから、重要な事柄なはずだ。自分がこだわっている事柄を相手に理解してほしいからこそ期待するのだろうし、その結果として伝わらないことに憤りを覚えることになる。

なぜ今回、2015年のエントリの続きを書こうと思ったのかと言うとPodcast 「Turing Complete FM」の30回の最後で、まさにこの話が議論されていたからだ。

Rui「思うんですけど、教えるときに厳しすぎる人が多いなというイメージがあり、自信を失わせる方向で教えるのではなく、自信を増やす方向で教えるほうがいいんじゃなかなって」

hikarium「自信を失わせるのは本当に良くない。最初にできないのは悪いことじゃないですもんね。」

Rui「できないから逆にいるわけですからね。」

hikarium「できるんだったら来なくてよいので。だから、できるようになっていこうとしている人には本当に優しく接してあげるというか。当たり前のことですけど。」

Rui「hikarium とかちょっと厳しいときもありましたよ。」

hikarium「すみませんでした。たまになんか、てか、結構言われるんですよ。hikariumはスパルタだからって、たまに言われるんですよ。」

Rui「別にそんなつもりはないんでしょう？」

hikarium「あ、いや、ちょっとスパルタっぽくしているときはあります。でも、それは意図したものです。」

Rui「じゃあ、それをやめればいいんじゃないですか。それを。」

hikarium「でも、今回は……今回もちょっと駄目でした？」

Rui「僕はhikariumを知っているから、hikariumなみに優しくしているのかな、と。」

hikarium「いや、難しいですよね。」

Rui「まぁ、でも、それは、それこそ訓練じゃないですか。教え方と言うかテクニックがあり。心構えというよりはむしろテクニックですから。」

hikarium「あーなんか、自分が教えているのは、できそうな人を教えているので。だから、ちょっと期待値を高めに投げているので。それがちょっとスパルタっぽく見えるのかなっていうのがあるかもですね。外から見ると。」

Rui「別に期待しなければいいんじゃないですか。それはなんか言い方の問題だけど。別にこれくらい教えたんだから、これくらいできるだろう、と思わなければいいんじゃないですか。」

hikarium「たしかに、それもあるかも。せっかくだからいろいろやってほしいじゃないですか。まぁ、そうですね。高い目標を立てるというよりは、少しずつできる目標を立てて、それができたらすごいっていうことを言ってあげて自己肯定感を高めてあげるのは本当に大事なことかなと思います。」

Rui「本人が目標を立ててそれを達成するのはいいですけど、別にこっちがそれを期待する必要はないですからね。これくらい教えたから、これくらいできるはずなのに、なんでできないんだ、と思っても仕方ないから。」

hikarium「なんでできないんだという思考が一番危ない。」

私も歳をとったからかもしれないけれど、今となっては Rui さんの言うことがよくわかるし、若いときには hikarium さんに近い気持ちを持っていたな、と感じる。

一般化できるものなのかはわからないけれど、年齢と共にある種の尖った部分は減ってくるものだとは思う。若い頃には自分の考えは他の人にも理解できるものだ、という誤解があるけれども、多くの経験をする中で、世の中にはいろいろな人がいて、いろいろな考えを持っていて、そして必ずしも自分の考えが正しいとも限らない、ということがだんだんとわかってくる。そして、期待をするという概念自体、実はどうでもいいことなのではないかということに気付いてくる。

結局のところ、教育の結果などというものは教えられた当人次第なのであって、教える側がどうこうできるものではない。ようは「馬を水辺に導く事はできるが馬に水を飲ませる事はできない」ということだ。教える、ということは教えられた当人に伸びる”きっかけ”を与えるに過ぎない。そういう意味で期待をすること自体、余計なことなのかもしれない。