技術者にとっても、無知の知が重要、という話は以前にも書いた。 自分が何が分かっていないか正確に把握していれば、 適宜質問したり、勉強したりできる。 自身の実力がどのくらいか正確に把握できていれば、 判断を誤まらずに済む。
過去の成功体験がアダとなって失敗した、という話をよく聞く。 過去とは状況が変わっているのに、 今でも自分が正しい判断をできると思い込み、 過去の手法を現在に適用してしまう。 過去の成功体験を過剰適用してしまっている。
自信を持つことは悪いことではないが、 ともすると自信過剰に陥る。 自分の実力をどこまで正確に評価できるかが鍵だろう。 努めて自分の短所を見るようにしなければならない。
自分の短所は見つけにくい。 ついつい長所ばかりを見てしまう。 一方、他人の短所はよく見えるもの。 ならば逆に、無理矢理にでも他人の長所を見つけよう。 そうすれば、自分が何ができていないか見えてくるだろう。
アナロジーで考えると理解しやすいのはなぜだろう？
新しい事柄を、すでに理解している事柄に対応付けると、 分かったような気になりやすいので注意が必要であるが、 どこまで類似していて、 どこが違うかはっきり意識しながら考えるのであれば、 アナロジーは素早くモノゴトの本質を見極める方法として有効である。
すでに完全に理解している事柄というのは、 頭の中にその事柄に対応する「回路」が出来上がっていて、 無意識の思考で高速に考えることができる。 一方、初めて見聞きする新しい事柄は、 当然のことながら頭の中にはなにも準備ができていないから、 無意識の思考で考えるのは難しく、 意識した思考で考えることになる。つまり非常に遅い。
ここで、もし新しい事柄の一部でも、 無意識の思考で考えることができるのなら、 つまりすでに理解している事柄と似ている点があるのなら、 その部分は無意識の思考に任せることができて、 理解を加速することができるのではないか。 おそらく、これがアナロジーで考えるということなのだろうと思う。
このように考えていると、 マービン・ミンスキーのフレーム理論が思い起こされる。 つまり知識の枠組みができている事柄についての理解が速い、 ということと似ているが、 単なる知識の整理にとどまらず、 無意識の「自動化された」思考によって、 新しい事柄への理解が加速されるのではないか。
その一方で、過剰な類推をしてしまう、 つまり無意識への「丸投げ」をしてしまうのが、 「分かったつもり」であって、 頭の中の回路がどこまで正しいのか、 つまり「どこまで類似していて、どこが違うか」を検証する必要がある、 ということなのだろう。
その検証を、意識して行ってもよいのだが、 検証を無意識の思考で行うことができれば、 さらに強力だろう。 これは、比喩のやりすぎや、論理の誤謬を「直感で」感じられる人は、 検証を実際に無意識の思考で行っているのだろうと思う。
「勤労の義務」は、 言うまでもなく日本国憲法第27条に規定されている、 日本国民の3大義務の一つであるが、 そのそろこの勤労に対する固定観念をかえていくべきなのではないか？ 来るべき共産社会へのビジョンは、 Web2.0 で初めて見えてきたわけでは決してなく、 何十年も前から様々な形で繰り返し描かれてきた。 例えば、
断絶への航海 ハヤカワ文庫 SF (586)
ジェイムズ・P・ホーガン (著), 小隅 黎
などの近未来小説などの形でも。 SF においては、StarTrek を引き合いに出すまでも無く、 未来には貨幣経済が存在しないという設定のほうが、 むしろ普通となっている。
にもかかわらず、いまだに資本主義以前の ナイーブな勤労観がはびこっているのは、 憲法に基づく洗脳教育のたまものなのだろうか？
人力検索はてな から引用:
「年収３００万の自分にとって最高に面白い仕事」か「年収１０００万の自分にとって最高に面白くない仕事」どちらかを一生しなくてはならないとしたらあなたはどちらを選びますか？その理由は？
この質問者にとっては、面白くても、面白くなくても、 仕事は仕事なのだろう。 そこにはストックという概念すら存在せず、 ただフローを得るための勤労という思い込みに囚われている。
まずバランスシートを義務教育で教えるべきなのだろうか？
それとも、貨幣経済を飛び越して Web2.0 を教えるべきなのだろうか?
先日紹介した学生さんを対象とした会社説明会
KLab(株) CTO 仙石 (KLabセキュリティ(株) CTO を兼務) と語る、
「技術者の成長にとって一番役に立つ会社」
「技術者が自ら伸びていくことができる会社」とは？
日時: 5/9(火) 13:30～15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20Ｆ)
が、おかげさまで満席につき二回目が実施されるそうです。
日時: 5/15(月) 13:30～15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20Ｆ)
会社説明会といいつつ、要は私といろんな話題についてお話しましょう、
というノリですので、私の日記 (CTO日記もよろしく) を見て、
波長が合いそうだと思ったかた、ぜひ登録をお願いします。
5/8 追記: 上記説明会は満席につき、現在は 5/30実施の説明会への登録を受付中です
弊社の面接で(私に)よく聞かれること、 面接官自身が語る面接攻略法の二回目。
面接を受けに来て、なにも質問しようとしない人がいます。 面接を受けに来た人(応募者)にとっては、 初めての会社であるわけで、 その会社については知らないことだらけなはずです。 それなのに一度も応募者の側から質問しようとしない場合は、 面接を終了する前に、 「何か質問はありませんか？」という質問をすることになります。 それでも何も質問してもらえないのは、 応募者の関心度の順に
という理由が考えられるでしょう。 (1) は、面接官が応募者に対して会社の魅力を充分に説明できなかった、 ということなので、反省すべきは応募者ではなくて面接官(つまり私)のほうですね。 なので、ここでは (2) と (3) についてのみ考えます。
まず (2) ですが、面接はせいぜい 1時間、長くても 2時間程度なわけで、 そんな短い時間でどれだけのことが分かるというのでしょう？
蛇足ですが、私がケイ・ラボラトリー (KLab の旧社名) の立ち上げに 参加するときに受けた面接 (つまり私が応募者の立場だった最後の面接) は、 話が盛り上がって話し込み、気付いたときには 6 時間が経過していました。 ここまで長いと、非常識かも知れませんね。(^^;)
分かっていないのに分かったつもりになってしまう、 これは技術者にとって致命的なことです。 どこまでも自分が分かっていないことを自覚し、 探求し続ける習慣が無ければ、スキルアップは覚束ないでしょう。
したがって面接官としては、この応募者には「伸びしろ」がもうあまりない、 つまり現状のスキル以上のものは期待しにくいと判断せざるを得ません。 現在のスキルのままで活躍して頂けると判断する場合は採用しますし、 そうでない場合は不採用となります。
一方 (3) は、技術者としては可能性があるが、コミュニケーション能力が低い、 という場合です。 もちろんコミュニケーションというのは双方向のものなので、 質問しにくい雰囲気にしてしまった 面接官の側に非がある可能性も否めないのですが、 質問しやすい環境でないと質問できないというのも困りものです。
とはいえ、技術と違ってコミュニケーション力は歳をとってからでも習得できます。 コミュニケーション能力が皆無でも、技術者としての素質があるかたには 是非入社して頂きたいですし、 実際面接時にコミュニケーション能力がゼロだった人 (面接の時、ほとんど話すことができなかった) が 入社後大活躍している例もあります。 もちろん仕事を円滑に進めるにはコミュニケーション力が高い方が いいに決まってますので、 例えば
質問力―話し上手はここがちがう
齋藤 孝 (著)
筑摩書房 ; ISBN: 4480816267 ; (2003/03)
などを読んで「質問する力」を伸ばしていって欲しいと思っています。
この時期、KLab と KLabセキュリティは 上半期 (9月～2月) の評価面談の季節です。 私は KLab の研究部門である Kラボラトリー (旧社名をとって名付けました) と、 KLabセキュリティの技術本部を担当しています。 昨日は、私の直接の部下の中で一番若い H さんの面談を行ないました。
H さんは昨年の新卒入社なので、まだまだ学ぶべきことはたくさんあるわけですが、 人一倍技術が好きなので、私としても大変期待しています。 いまは、いろんなこと (気配りとか、会社の業績とか) を気にするより、 好きなことを自由に学び、伸び伸びと育って欲しい、と思っています。
彼に話したのはこんなことです:
一点注意してほしい点をあげるとすれば、 様々な技術に関心を持つ際に、強弱のメリハリをつけることを意識する、 という点です。 WWWで公開される情報がどんどん充実していく昨今、 どのような技術でもかなり奥深いところまで WWW で手軽に入手できるように なっています。 このこと自体は素晴らしいことなのですが、 入手が手軽に可能ということが、 分かったつもりに陥るリスクを増やしているわけで、 この罠に陥らないよう注意してください。
特に関心を持った分野、たとえばベイズ理論やオートマトン理論などは、 通りいっぺんの理解にとどまらず、とことんまで勉強してやる、 くらいの意気込みで挑戦してほしいと思っています。
WWW の普及によって、広く浅く学ぶことは格段に容易になりました。 広い視野を持つことはとても大切なことなのですが、 各分野それぞれについて自身がどのくらいのレベルまで学べたか把握していないと、 ほんの表層をかすっただけで満足してしまいかねません。
だから、どんな分野でも、どんなに狭いピンポイントでもいいから 深く深く学ぶ経験が重要だと思うのです。 深く学べば学ぶほど、その深さが基準となって、 その他の分野への理解がどのレベルまで到達したか、 より正確に把握できるものでしょう。
浅くしか学んだことがなければ、その浅さがその人の限界になります。 なにを学んだとしても、自身がどのレベルまで理解できているのか、 自身が理解できていない深淵がどれだけ深いものなのか、 永遠に知ることはないでしょう。
だから、特に若いうちは、とことんまで学んでみて欲しいのです。 H さんには短期的な目標設定として、 古典的な教科書一冊を完全理解することを勧めました:
なにかひとつでいいので、半期かけてとことん学んでみてください。 ひとつの分野をどこまでも深掘りする、ということを一度でも経験した人は、 興味の対象がいろいろ移り変わっても、 分かったつもり状態に陥りにくいものです。 WWW上での学習だと、深堀する以前に興味が発散してしまうリスクがあるので、 評価が確立した古典的な教科書を一冊、完全理解に達するまで読み込む、 といった勉強方法のほうがいいかもしれません。
どんな分野の教科書でもいいと思いますが、 一例として私が学生時代に学んだ「古典的な教科書」を紹介しました:
Switching and Finite Automata Theory
Zvi Kohavi
McGraw-Hill Education ; ISBN: 0070993874 ; (1979/03/01)
27年前の本です！ 秒進分歩ともいわれる技術革新のスピードの中で、 1/4世紀以上昔の本が今でも通用するのですから、愉快じゃありませんか。
追記:
「やめるまではがんばりまっせ」から引用:
なんでかというと、結局わしは、会社のためとか、自分の給料を上げるためだけに仕事しているつもりはないからなのです。自分の実力のために、今吸収できるべきことは全て吸収し、機が熟したら、どこにでも飛び出せるようにしておこう、と思っているからです。だから、今は評価がなかろうがなんだろうが、とにかくやるべきことをバシバシこなさなきゃイカンと思っているのです。
その通りですね。 若いときは若いときしかできないことをすべきだと思うのです。 会社がどうなろうと、 スキルさえ身につければ技術者は勝ち残れるのですから。
大学4年/大学院2年の学生さんに、 どれだけこのページを読んでもらえてるか分からない (^^;) のですが、
KLab(株) CTO 仙石 (KLabセキュリティ(株) CTO を兼務) と語る、
「技術者の成長にとって一番役に立つ会社」
「技術者が自ら伸びていくことができる会社」とは？
と題する会社説明会が開催されるようです。
日時: 5/9(火) 13:30～15:00
場所: KLab(株) 本社会議室 (六本木ヒルズ森タワー 20Ｆ)
会社説明会といいつつ、 要は私といろんな話題についてお話しましょう、 というノリですので、 私の日記 (CTO日記もよろしく) を見て、 波長が合いそうだと思ったかた、 ぜひ登録をお願いします。
4/27追記: 上記説明会は満席につき、現在は 5/15実施の説明会への登録を受付中です
5/8 追記: 上記説明会は満席につき、現在は 5/30実施の説明会への登録を受付中です
向いていることを仕事にしよう。 まさに、好きこそものの上手なれ、 嫌々やってる人と、好きでやっている人とでは、どんどん差がつく。 一生のうちのかなりの時間を仕事に費やすのだから好きなことをすべき。
好きなことやっててメシが食えれば苦労はしない、という人が いるかも知れない。しかし、 かなりニッチな分野でも、トップクラスならば飯の種には困らないもの。 ベンチャーと同じ。 市場規模が小さくても、他社に負けない競争力を持っていれば 商売になる。 市場規模がいくら大きくても、他社の後追いなら 価格競争に巻き込まれてジリ貧になる。 まさに、鶏口となるも牛後となるなかれ。
その一方で、
眠る開発屋blog から引用:
ベンチャーって割と志先行になりがちだけども、 どこかでそれと距離を置かないと行き詰まるよね。 多種多様な人間を巻き込む土壌がなければバランス悪くなるもの。 ってか事業を展開させようにも志だけじゃ人が集まらない。
確かにそういう面も否定できない。 多種多様な人間を巻き込みつつ、 各人が高い志を持ち続けるには？ ベクトルが異なる志を持つ人達が、 お互いを尊重して総合力を発揮するには？
志まで雇われたいの? から引用:
会社を設立するに当っては、この志というものは欠かせない。 しかしそれは創立者や役員といった「コアメンバー」で押しとどめるべきだ。 会社は従業員に雇用契約以上のものを求めてはならないし、 従業員もまた会社に雇用契約以上のものを求めるべきではない。
...
しかし、セミナーだの訓示だので、志を植え付けるがごとくは、 会社の傲慢というものだ。それでよかった時代もあったのかも知れないが、 今や社畜という生き物は不良資産扱いだ。企業不祥事の際に 産廃扱いで捨てられるのがヲチである。
会社2.0に取りかかる前に、せめて会社1.0をリリースしませんか、みなさん。
志を押しつけ、異なるベクトルを矯正しようとするのではなく、 異なるベクトルの合力を生かす方法はないのだろうか？ 力をあわせる唯一の目標が「皆でお金持ちになろうね」(眠る開発屋blog) だけだったとしたら、あまりに悲しい。
日経ソフトウェアの大森敏行氏の記事中の注釈に、
プログラマが「プログラミングに特別な能力が必要であること」を 強調したがるのには理由がある。 現在の日本のソフトウエア業界には 「プログラミングをしない人のほうが立場が上である」というケースが 往々にして見られ， そのせいでプログラムの質が上がらないという構造的な問題があるからだ。」
というくだりがある。
確かに一理あるし、 優秀なプログラマがエキスパートとして尊敬される土壌づくりは、 優れたソフトウェアを開発するために必須の条件であろう。 しかしながら、 「プログラミングをしない人のほうが立場が上」というのは 一面的な見方ではないのか。 プログラマ兼 CTO である私としては一言いいたくなる。;-)
「プログラミングをしない人」⇒「立場が上」
なのではなくて、
「プログラミングをする人」⇒「視野が狭い人が多い」
「視野が狭い」⇒「立場が下」
に (ムリヤリな) 三段論法を適用しているだけなのではないのだろうか。 自身の視野の狭さを棚に上げておいて、 「プログラマだから立場が低い」と嘆くのはいかがなものかと思う。 もちろん、 「プログラミングに特別な能力が必要」なのではなくて、 「優れたプログラムを書くには特別な能力が必要」が正しい。 「下っ端プログラマ」と「優秀なプログラマ」を同列に扱ってはいけない。
前述した大森氏の注釈は、次のように続く:
この問題に関しては「Life is beautiful」というブログの 「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが参考になる。
さっそくこの中島聡氏のブログを 読んでみた。
ソフトウェアのアーキテクトが自らプログラムを書いたり、 下っ端のエンジニアの書いたコードをレビューするのは、 レストランのシェフが自ら料理をしたり、 下っ端の料理人の作ったスープの味見をするとの同じである。
とても適切な喩えのように思える。 しかしこの伝で行けば、
下っ端のプログラマ(料理人)がアーキテクト(シェフ)になれるかは 才能に依存するところが多分にあり、 適性がない人は、いくら努力しても永久に下っ端のまま、 一人月 30万円レベルから抜け出せない。 そういう人はさっさとプログラミング(料理)をあきらめて、 マネジメントをやったほうがいい。 マネジメントなら才能が無くても経験次第でそれなりのレベルにはなる。
というとても残酷ではあるが、 とても実状に近い類推が出てきてしまうのだが...
ちなみに中島氏のブログには
優秀なエンジニアとそうでないエンジニアの生産性は（誇張抜きで） ２０対１ぐらいである。
という話が出てくるのだが、私はもっと差があると感じている。 超優秀なプログラマと、下っ端プログラマとでは、 生産性が(誇張抜きで) 3桁違う、 というのが私の主張。 トッププログラマの 1000分の1の生産性しかない、 そもそもプログラミングに適性がない人が 無理矢理プログラマを目指そうとするから、不幸が始まる。 しかも、プログラミングは適性のない人でも時間さえかければ (かろうじて)動くプログラムが作れてしまったりするから余計タチが悪い。
これが料理であれば適性のない人は何日かけたって美味しい料理は作れないわけで、 早い段階で才能の無さを自覚して他の職を探すものだと思うが、 下っ端プログラマにはその自覚がない。 自覚が無いからプログラマへの道をあきらめめようとしない。 仕方ないので 35歳くらいで周囲が引導を渡すわけで、 これが「プログラマ35歳定年説」の正体。
ここまでの話と全然関係ないが、大森氏の記事に
BASICというプログラミング言語の文法を知ったのは確か中学生のときだし， 高校生のときにはシャープの「MZ-80K2E」というマイコンで 簡単なゲームのプログラムくらいは書いていた。
と書いてあったのが、 実はこの記事を引用しようと思った真の理由だったりする (^^;)。 私も中学一年の終わり頃 BASIC を知り、 高校生のとき MZ-80K2E でゲームを作ったりして遊んでいた。
人の上に立とう、といっても、威張りちらしたい、というわけではない。 相手より高い視点を持てるよう努力しよう、ということだ。
大局的な判断ができる人がリーダシップをとり、 局所的な判断しかできない人は、その指示に従うことになる。 上司が指示を出し、部下がそれに従う、というわけではない。 もちろん指揮命令系統が決められている場合は、 そこから逸脱するのは難しいかも知れないが、 職種が違う場合はどうだろう？
セールスがお客様の言葉を錦の御旗よろしく振りかざして マーケタへマーケティング戦略を指示し、 マーケタが製品のあるべき姿をプランナへ指示し、 プランナが製品仕様を決めて技術者に指示する。
こうした指示の連鎖は、よく見かける光景だが、 セールス、マーケタ、プランナ、技術者は、 本来は上下関係はないはずである。 なぜこのような指示する側とされる側に分かれてしまうのか。
で、上下関係をひっくり返してみようと思った。 技術者である私が、セールスやマーケタやプランナに指示を出してみる。
もちろん、いきなり指示を出そうと思っても、 何を指示すべきか分からないから、準備が必要である。
まず営業同行して、セールスの人達がお客様と何を話しているか観察。 ところがお客様の顔がいかにも興味なさそうなのに、 とうとうと自社製品の説明を立て板に水のごとく話している姿を目撃。 う～ん、素人の私にだって、こういう営業方法が 論外なことくらいは分かる。 もちろん優秀な営業マンもいるのだが、 私の目から見てもダメダメな人がいるというのは発見だった。
つぎにマーケ本部の定例ミーティングに参加してみる。 最初のうちは全貌が把握できていないのでおとなしくしているが、 すぐに我慢ができなくなった。 自社のポジションがまるで理解できていない。 弊社は大企業とは違うのだ。 弊社のロゴを見たって誰も弊社のことを思い浮かべたりはしない。 それにいま攻めようとしている市場は導入期である。 新しいカテゴリを作ろうとしているのだから 成熟期の商品と同じ攻め方でいいわけがない。 もちろん優秀なマーケタもいるのだが、 マーケティングの教科書を一読だけで分かるようなことを押さえずに、 見よう見まねの SWOT 分析などをして マーケタ気取りの人がいるというのは発見だった。
プランナは、技術者に近い。技術者と同じく「作る」職種である。 仕様を考えつつどんどんプロトタイピングして実ユーザの声を聞く、 という開発手法もあるわけで、 プランナと技術者は対等の関係になることも多い。
セールスやマーケタは、「売る」職種である。 技術者とは別人種と言ってもいいだろう。 だからといって「売る」職種が、「作る」職種よりも 立場が上というわけではない。 単に「売る」職種の方が広い視野を持ちやすく、 「作る」職種が、ともすると目先の問題に固執しがち というだけのこと。
私が好きな SF の主人公のセリフに、こういうものがある:
「わたしは、偶然の一致というのを信じない」
ガニメデの優しい巨人
ジェイムズ・P・ホーガン (著)
ある事象の直後に、本来直接は関係ないはずの別の事象が起きたら、 両者の間に、なんらかの因果関係があるはず、と考えるのが、 「偶然の一致を信じない」人のとるべき態度であるし、 この考え方は、技術者や科学者にとっての鉄則だと思う。
同じ事象を観測していても、偶然の一致を見つけ出せるか、 それとも代わり映えしない観測データと思って見過ごすかが、 大きな分かれ目になりそうだ。
プログラムの動作ログも同じ。同じログを見ていても、 そこからどれだけの内容を汲み取れるかは、 技術者の資質に大きく依存すると思うし、 スキルアップを目指すなら、自分より優れている技術者が、 そのデータから何を引き出すことができて、 自分がどうしてそれを引き出すことができなかったのか、 詳細に省みるべきだろう。
「分からない時は、『分からない』と言おう」キャンペーン中、という メールを社内ML に出してみました。
この社内ML というのは tech ML という名前なのですが、KLab の技術者だけでなく、KLab と一緒に開発を行なっていただいている協力会社の方も全員参加していて、少しでも技術に関係ありそうなネタなら何でも自由に書いてね、という ML です。もちろん私も、いろんなことを書いています。
たとえばこんな感じで:
日経ベンチャーの Web ページに、「ピックアップBOOKS」という書評のコーナーがあって、いつも参考にさせていただいているのですが、そこで「ソフトウェア開発で伸びる人、伸びない人」という本の紹介を見つけたので、反射神経的に tech ML にメールを流しました。
----- tech ML に投げたメールここから -----仙石です。 「分からない時は、『分からない』と言おう」キャンペーン中。 ソフトウェア開発で伸びる人、伸びない人 荒井玲子著 技術評論社 技評SE新書 002 2006/2 208pp 882円 http://nv-club.nikkeibp.co.jp/free/RASHINBAN/20060216/106694/ | プライドには、良いプライドと悪いプライドがある。間違ったプライドを持っ | ている人かどうかは、次の質問をすればすぐにわかる。 | | (1) 「わかりません」と言えますか？ | (2) 「難しい」と言って放棄していませんか？ | (3) 説明する機会を避けていませんか？ | | 「わかりません」と言えない人、「そんなことはわかっています」という反応 | には要注意である。プライドの高い人は、尋ねるということ自体を苦手とする | 傾向がある。 「分からない」と言えない人って、プライドが原因なんですかね？ 「分からない」と言う方がカッコイイってことに、どーして気づかないんだろ？ | ひとつの専門性を持ったら、自分の適正に応じて専門領域を広げていくことは | できる。一芸に秀でることは、他の分野の専門性を理解することに役立つ。そ | のためには、ひとつの専門領域を極めることが重要である。 これも、その通りですね。 #13265 仙石 浩明 https://www.gcd.org/sengoku/ Hiroaki Sengoku <sengoku@gcd.org>----- tech ML に投げたメールここまで -----
優秀な技術者とそうでない技術者との境界線って、「分からない」ことが分かるか否か、だけじゃないかなぁと常日頃から思っているので、手を替え品を替え「分からない」と言えることの重要性を説いているわけです。
# 4/20追記: わからないことをわからないということの重要性を
# 書いているページを見つけました。
技術者にとって一番重要なのは、「分からない」と言える能力。 太古の昔から、無知の知と呼ばれているもの。
なにが分かっていないか、分からなければ勉強のしようがない。 分かったつもりで済ませていては、いつになっても真の理解は不可能。
小学生のころ、私は答案に平気で「デタラメ」を書いていた。 デタラメを書いているという意識ではなく、 分かったつもりになって正しい答えを書いているつもりだった。 あまりに自由な発想でデタラメを書くので親が心配したほど。
ところが、中学生のころ、同級生にとても優秀な奴がいた。 彼は、一を聞けば十を理解した。 あまりに早く分かったというので、信じられずに 残りの九を説明しようとすると、先回りして答えられてしまった。
そんな彼が、「分からない」を連発する。 つまり分かった、と言うのも早いが、 分からない、と言うのもとても早かった。
そんな彼を見て、私は「分からない」と言えるのは カッコイイことなんだと思った。 なんとかして自分も、「分からない」と言えるようになりたい、 と思った。
自分が本当に理解しているのか、 それとも単に分かったつもりになっているだけなのか、 常に自省する習慣が身についたのは、 彼のおかげだと思う。