シリコンバレー式超ライフハック

著者:デイブ・アプスリー
訳:栗原百代
出版社:ダイヤモンド社

 

この本を読んで行動に移そうと思ったこと

第14章 感謝

  • 寝る前にその日感謝できることを3つ思い浮かべる
  • 良い方のストーリーを自分で選ぶ
    • 人にいやなことをされたとき、「きっと相手にはそれなりの事情があってそのようなことをしたのだ」ということにする
    • 嫌なヤツにさえ感謝と同情の気持ちを抱く

第13章

  • Macbookのディスプレイの輝度を夜間は暖かい色(赤色光)になるよう設定する
  • 夜は部屋の明るさを赤色光にする

第12章

  • 朝起きたら瞑想する
    • まずは5分間やることから始める

第5章

次の射精までの日数=(年齢 ー 7)÷ 4

  • 射精の回数を減らす
  • 30日間以内までであれば少ないほど良い

 

ウは宇宙ヤバイのウ!〔新版〕

著者:宮澤伊織
出版社:ハヤカワ文庫

非数値ヌル香の皮肉っぷりや、そしてそれを受け流したりつっこんだりする久遠空々梨のやりとりが面白い。
たくさんのSF作品やそれ以外の作品のパロディ・オマージュがふんだんに使われているが、元ネタを知らなくても十分に楽しめた。
真面目くさって読むものではない。ぼーっと、ただただ楽しむために読むSF小説である。
TVアニメ化に期待したい(宮澤伊織別著「裏世界ピクニック」はTVアニメ化されているようなのでそれは見よう)。

僕たちはなぜ暇だと感じるのか、退屈とどう関わってきたのか『暇と退屈の倫理学』

某ウイルスの影響による外出自粛ムードが薄れてきてから実感としてだいぶ経つが、自粛期間中は「暇だ」「退屈している」と感じることが多かったのではないだろうか。

その影響もあるのか、「2022年 東大・京大で1番読まれた本」と目立つように帯に書かれている。

だから、暇と退屈が今までよりも身近に感じられる最近ならではの本かと思いきやそうではない。

この本の初版が発行されたのは2011年10月なので、もう10年以上読まれている良著であることがわかる。

そしてかなり哲学的な内容で難しい。しかし、「自分の疑問と向き合おう、自分で考えようという気持ちさえ持っていれば、最後まできちんと読み通せる」と著者が言う通り私のような哲学素人でも十分に読み進められるものになっていた。

これは著者が今までの人生の中で違和感を感じていた「何か」の答えを見つけるために書かれた本である。その「何か」とはなんなのかを考えながら読み進めていくことで良い体験が得られる本だと感じる。

暇や退屈に関連するもののひとつに「時間」があるだろう。

「バイト〇〇時までなのに暇だなー」「〇〇時まで家にいないといけないけど、退屈だ」というシチュエーションは想像できると思う。

「時間」は暇と退屈に深くかかわりがありそうだ。

我々の世界では、すべての生物が同じ時間と同じ空間を生きていると考えている。

しかし、この当たり前の事実をユクスキュルという理論生物学者は疑ったのだと著者はいう。

すべての生物がその中に置かれているような単一の世界など実は存在しない。すべての生物は別々の時間と空間を生きている!

この概念をユクスキュルは「環世界」と呼ぶ。

例にとった生物は「ダニ」である。ダニは哺乳類や人間の血を吸うが、その吸血のプロセスがユクスキュルの言う「環世界」を説明するうえで非常にわかりやすいものになっている。

ダニは哺乳類などから発する「酪酸」というにおいだけをシグナルにして、それが知覚されると吸血する獲物に飛び込んでいく。「この獲物は体が小さいな」だとか「これは人間だな」だとかは考えていない。

それまで飲まず食わずただじっと待っている。それがダニの「環世界」である。

どれだけ待てるのかわからないが、ユクスキュルいわく、とある研究所で18年間絶食しているダニが生きたまま保存されていたという。

そんなに長いあいだ、ひたすら酪酸のにおいを待つことは、人間にとっては驚きである。だが、ダニにとってそれが当然のことなのだとしたら?というのもダニは人間とはまったく異なる環世界を生きているのだ。ダニにとっては18年間など大した長さではないのだとしたら?

つまり、私たちとダニや他の生物とでは「時間」が異なっているのではないか、ということである・・・!

もしそうなのであれば、いったい「時間」とはなんなのであろうか。

詳細はぜひ本書を手にとって確かめてもらいたいが、価値観が新しく塗り変えられる1冊になること間違いなしである。

 

『プログラマー脳』認知科学でプログラミングはもっと楽しくなる!

すべてのプログラマーに読んでもらいたい本だ。

経験の浅いプログラマー、ベテランプログラマー、そしてもっと言うとプログラマーでなくても得られるものが多い本であると思う。

認知科学に基づく」と聞くと難しい内容が書かれていると思ってしまうが、そんなことはない。認知科学とはどんなものなのかを紐解きながら読み進められるのでわかりやすく楽しい本になっている。

この本にはコードを「書く」ときのテクニックが書いてあるだけでなく「読む」ことにもフォーカスを当てている。

プログラマーはどうしてもコードを書くことに重きを置きがち(どうしたら良いコードが書けるか、効率の良いコードが書けるか)だが、もっとコードを読む訓練が必要であると著者はいう。

それは、プログラマーの仕事はコードを書いている時間よりも読んでいる時間の方が多いからだ。

自分に当てはめて考えてみると確かにそうだ。まあ僕はプログラマーを名乗れるほどコーディングをしていないからというだけなのだけれど・・・。

この本を読めば読むほどコードを読む、書くテクニックを知って、コードと対峙したくなってくるだろう。

 

  • 複雑なコードを読む時の認知的負荷を軽減するテクニック
    • すべての変数を丸で囲む
    • 類似した変数を線でつなぐ
    • すべてのメソッドや関数を丸で囲む
    • メソッド/関数呼び出しをその定義場所と線でつなぐ
    • クラスのインスタンスをすべて丸で囲む
    • クラス定義とそのインスタンスの間に線を引く
  • 普通の文章でもコードを読むときにも適用できる文書理解の戦略
    • 活性化:関連する事柄を積極的に考え、過去の知識を活性化させる
    • 監視:文章の理解度を把握し続ける
    • 重要性の判断:文章のどの部分んが最も関連性が高いかを判断する
    • 推論:文章にはっきりと書かれていない事実を補完する
    • 可視化:読んだ文章の内容を図解して理解を深める
    • 自問自答:その文章について、質問を作り、それに答える
    • 要約:文章の短い要約を作成する

 

名前 説明 悪い名前の例
ルールを逸した大文字の利用

識別子の名前では、大文字は適切に
利用しなければならない

pagecounter
アンダースコアの連続 識別子の名前にアンダースコアを
連続して使うべきではない
page__counter
辞書に載っている単語の利用 識別子は意味のわかる単語のみを利用して、
省略形はそのほうが完全表記よりも
一般的な場合にのみ使用する
pag_counter
単語数 識別子は2単語から4単語以内で構成すべきである
page_counter_
converted_and_
normalized_value
多すぎる単語 識別子には5単語以上を使うべきではない
page_counter_converted_and_normalized_value
短すぎる識別子 識別子は8文字未満であってはならない。
ただし、c、d、e、g、i、in、inOut、
j、k、m、n、o、out、t、x、y、zは利用してよい
P、page
列挙型識別子の宣言の順番 何か特別な理由がない限り、列挙型の名前は
アルファベット順に宣言されるべきである
CardValue = {ACE, EIGHT, FIVE, FOUR, JACK, KING...}
前後のアンダースコア 識別子名の先頭や末尾に
アンダースコアをつけてはならない
__page_counter_
識別子への型情報の追加 識別子の名前にハンガリアン記法などを用いて
型情報を追加してはならない
int_page_counter
長すぎる識別子 可能なら長い識別子名は避ける
paga_counter_converted_and_normalized_value
ルールを逸した命名 識別子は、一般的ではない方法で
大文字と小文字を組み合わせてはならない
Page_counter
数字を表す識別子名 識別子は、数字を表す単語だけで構成してはならない FIFTY

 

 

名前

説明 悪い名前の例
ルールを逸した大文字の利用 識別子の名前では、大文字は適切に利用しなければならない pagecounter
アンダースコアの連続 識別子の名前にアンダースコアを連続して使うべきではない page__counter
辞書に載っている単語の利用 識別子は意味のわかる単語のみを利用して、省略形はそのほうが完全表記よりも一般的な場合にのみ使用する pag_counter
単語数 識別子は2単語から4単語以内で構成すべきである page_counter_converted_and_normalized_value
多すぎる単語 識別子には5単語以上を使うべきではない page_counter_converted_and_normalized_value
短すぎる識別子 識別子は8文字未満であってはならない。ただし、c、d、e、g、i、in、inOut、j、k、m、n、o、out、t、x、y、zは利用してよい P、page
列挙型識別子の宣言の順番 何か特別な理由がない限り、列挙型の名前はアルファベット順に宣言されるべきである CardValue = {ACE, EIGHT, FIVE, FOUR, JACK, KING...}
前後のアンダースコア 識別子名の先頭や末尾にアンダースコアをつけてはならない __page_counter_
識別子への型情報の追加 識別子の名前にハンガリアン記法などを用いて型情報を追加してはならない int_page_counter
長すぎる識別子 可能なら長い識別子名は避ける paga_counter_converted_and_normalized_value
ルールを逸した命名 識別子は、一般的ではない方法で大文字と小文字を組み合わせてはならない Page_counter
数字を表す識別子名 識別子は、数字を表す単語だけで構成してはならない FIFTY

 

イギリスのオープン大学の准上級講師であるサイモン・バトラー(Simon Butler)が作成した変数名で発生する問題の一覧

名前 説明 悪い名前の例
ルールを逸した大文字の利用 識別子の名前では、大文字は適切に利用しなければならない pagecounter
アンダースコアの連続 識別子の名前にアンダースコアを連続して使うべきではない page__counter
辞書に載っている単語の利用 識別子は意味のわかる単語のみを利用して、
省略形はそのほうが完全表記よりも一般的な場合にのみ使用する
pag_counter
単語数 識別子は2単語から4単語以内で構成すべきである page_counter_converted_
and_normalized_value
多すぎる単語 識別子には5単語以上を使うべきではない page_counter_converted_
and_normalized_value
短すぎる識別子 識別子は8文字未満であってはならない。
ただし、c、d、e、g、i、in、inOut、
j、k、m、n、o、out、t、x、y、zは利用してよい
P、page
列挙型識別子の宣言の順番 何か特別な理由がない限り、
列挙型の名前はアルファベット順に宣言されるべきである
CardValue = {ACE,
EIGHT, FIVE, FOUR,
JACK, KING...}
前後のアンダースコア 識別子名の先頭や末尾にアンダースコアをつけてはならない __page_counter_
識別子への型情報の追加 識別子の名前にハンガリアン記法などを用いて
型情報を追加してはならない
int_page_counter
長すぎる識別子 可能なら長い識別子名は避ける paga_counter_converted_
and_normalized_value
ルールを逸した命名 識別子は、一般的ではない方法で
大文字と小文字を組み合わせてはならない
Page_counter
数字を表す識別子名 識別子は、数字を表す単語だけで構成してはならない FIFTY

 

 

文法的に一貫した命名を大切にする考え方と、コードベースを通して一貫した命名であることを大切にする考え方がある。

前者はチャンク化を助け、後者は名前を処理する際に認知的負荷を下げる。

 

スネークケースかキャメルケースか

プログラマーと非プログラマー合わせて135人が参加した研究で、被験者はまず「リストをテーブルに拡張する(Extends a list to a table)」といった変数の役割を説明する文章を見せられ、4つの選択肢から、その文章を表す変数名として適したものを選ぶように指示された。

選択肢としては、extendListAsTable, expandAliasTable, expandAliasTitle, expandAliasTableなど。

結果、プログラマーと非プログラマーの両方において、キャメルケースを使う方が、より適切なものを選択する確率が高いことが示されている。

キャメルケースで書かれた識別子の方が、正しい選択肢を選ぶ確率が51.5%高いことがわかった。ただし、キャメルケースを使うと精度は高くなるが答えを出す速度が遅くなっていた。

→キャメルケースの変数は、スネークケースで書かれた変数よりも覚えやすい一方、スネークケースの方が変数を認識するまでにかかる時間は短くなる。

 

フェイテルソン氏による、よりよい変数名のための3ステップのモデル

  • 名前に含めるべき概念を選択する
  • それらの核概念を表す単語を選ぶ
  • それらの単語を使って命名を行う

 

ワシントン州立大学の教授であるアルナウドヴァが定義した言語的アンチパターン

  • メソッド名に書かれた以上の働きをするメソッド
  • 実際の働き以上のことをするかのごときメソッド名
  • メソッド名に書かれたのと真逆のことをするメソッド
  • 実際に格納されているよりも多くのものが含まれているかのごとき識別子名
  • 実際に格納されているよりも含まれているものが少ないかのごとき識別子名
  • 実際に格納されているものと真逆な識別子名

専門知識の呪い(curse of expertise)

何かのスキルを習得するとそれを習得するまでにどれだけ時間を要したのか、どれだけ大変だったのかを忘れてしまう呪い。

経験豊富なプログラマーが新人プログラマーのトレーニングを効果的に行えなくなる理由のひとつ。

学ぶ側は教える側が思っているほど(これも勘違いなことが多いけど)簡単ではないと感じていることを教える側が認識してあげるべきである。

 

心理学的フレームワーク「新ピアジェ主義」

幼児の発達の4つの段階に注目した発達心理学ピアジェの研究を基にしたもの。

 

段階      振る舞い
感覚運動期 計画や戦略は立てることができず、ただ感覚に基づいて動くことしかできない 0〜2歳
前操作期 仮説や計画を立て始めるが、それを確実に思考に生かすことはできない 2〜7歳
具体的操作期 眼に見える具体的なものについては仮説を立てられるようになるが、一般的な結論を出すのはまだ難しい 7〜11歳
形式的操作期 形式的な推論をすることができるようになる 11歳以上

この新ピアジェ主義のモデルをプログラミングに適用するとこうなる

段階      特徴 プログラマーの行動
感覚運動期 計画や戦略は立てることができず、ただ感覚に基づいて動くことしかできない プログラムの実行について、まったく正しくない理解しか持たない。この段階では、プログラマーはプログラムを正しく読み、追いかけることはできない
前操作期 仮説や計画を立て始めるが、それを確実に思考に生かすことはできない トレース表を作成するななどして、複数行のコードの結果を手作業で確実に予測することができるようになる。前操作期のプログラマーは、コード全体ではなく、一部のコードについてどんな処理をしているかを推測することが多い
具体的操作期 眼に見える具体的なものについては仮説を立てられるようになるが、一般的な結論を出すのはまだ難しい 前操作期的な帰納的アプローチではなく、コードそのものを読んで、演繹的にコードについて理由づけを行うことができる
形式的操作期 形式的な推論をすることができるようになる 論理的で一貫性のある、体型的な推論ができる。形式的操作的な推論には自分の行動を振り返ることも含まれ、これはデバッグには不可欠である

 

新人研修時はプログラミングに関する活動を1つに限定する

活動 新人教育時の活用方法
探索 コードベースを見渡して、その全体像を把握する
検索 特定のインターフェースを実装しているクラスを探す
転写 新人に作業の具体的な手順について明確な計画を与える
理解 特定のメソッドを自然言語で要約するなど、コードの内容を理解する
増強 既存クラスへの機能追加(計画の作成も含む)

 

コードの中のどこが最も重要であるかを新人に伝える

新人研修で最も重要なのは、新人自身が現在どの程度の理解度にいるのかを把握し続けること。
→定期的に振り返りの作業をすることを伝える

 

【AWS勉強】AWS Lambda実践ガイド第2版

 

 

購入した経緯

業務でLambdaを使った開発作業に携わることが多く、API GatewayやSQS・DynamoDBと連携して動作するシステムの構築をした際もモヤモヤしたままの状態だったので、1からしっかり勉強しようと購入。

手を動かしたこと

1〜3章まではLambdaで開発する上で必要な操作方法などの基礎的な知識が記載された部分だったので、「うんうん、そうだよね」といった感じでさらっと流し読みした。

4章からは実際にプライベートのAWSアカウントを使用して、ハンズオンを実施した。

  • Cloud9でのLambda開発
    • sam initで基本のSAMプロジェクトの作成
    • ビルド・デプロイ
      • SAMでデプロイしたリソースはマネコンで変更しないこと
        • マネコンで変更しても、再度デプロイしたときにCloudFormationで作り直されるので、template.yamlを変更してデプロイする
    • ローカル環境でLambdaをテストする
    • S3バケットのイベントを扱う方法や、S3を操作する方法
      • S3バケットのイベントの設定
      • S3バケットのイベントと操作
      • ライブラリを必要とするLambda関数
  • ユーザー登録した人だけが、登録ユーザー専用コンテンツをダウンロードできるシステムの構築
    • API GatewayとLambda関数を組み合わせてHTTPプロトコルからLambda関数を呼び出す構成
    • API Gatewayを呼び出すHTMLフォームを作り、静的ウェブサイトホスティングを有効にしたバケットに配置する
    • HTMLフォームから受け取ったデータをDynamoDBに書き込む処理
    • Lambda関数内に署名付きURLを発行する処理を実装し、コンテンツをダウンロードする期間を制限する
    • SESを使い、署名付きURLを含む文面のメールを送信する仕組みを作る

ハマったところ

DynamoDBテーブルの属性更新「update_item()」メソッドに設定する引数が理解できてなかったがそれなりにわかるようになった。(boto3のドキュメントでは「???」となっていた)

# テーブルに入っている値にプラス1して返す関数
def next_seq(table, tablename):
    response = table.update_item(
        Key={
            'tablename' : tablename
        },
        UpdateExpression="set seq = seq + :val",
        ExpressionAttributeValues= {
            ':val' : 1
        },
        ReturnValues='UPDATED_NEW'
    )
  return response['Attributes']['seq']

Key

対象となる項目を特定するキー。

「tablename属性がtablename変数に入っている値であるものを対象とする」という意味になる。

UpdateExpression

更新式

seq属性をseq属性の値に「:valというパラメータの値」を足したものを設定する、という意味になる。

パラメータの名称は「:」で始まる。:valというパラメータは次のExpressionAttributeValuesで指定する。

ExpressionAttributeValues

UpdateExpressionの式で使用するパラメータ。

':val' : 1

「:val」というパラメータに「1」を設定するという意味になる。すなわち、

set seq = seq + 1

という意味になりseqの属性値が「1増える」という挙動になる。

ReturnValues

戻り値にどのような値を返すかを指定する。

先ほどのコードでは「'UPDATED_NEW'」を指定しているので、「更新したあとの新しい値」が戻り値として返される。

【ReturnValuesの取り得る値】

'NONE':値を返さない

'ALL_OLD':追加・更新・削除されたすべての「元の値」を返す

'UPDATED_OLD':更新した「元の値」を返す

'ALL_NEW':追加・更新したすべての「新しい値」を返す

'UPDATED_NEW':更新したすべての「新しい値」を返す

 

1回目としてざっとハンズオンしてみたので、2周目では同じようなシステムを自分で応用してやってみたい。

 

『世界「倒産」図鑑 波乱万丈25社でわかる失敗の理由』失敗から学ぶ厳選された倒産ストーリー!?

今日のビジネス本は「いかにして成功できたか」というような成功体験からなるものがほとんどであるが、この本はその逆をゆく失敗を集めたものである。

企業において最悪の失敗である「倒産」だが、著者である荒木氏は企業の成功事例よりも失敗事例から学ぶことの方が示唆深いと言う。
「売上増は七難隠す」という言葉があるように、売り上げが上がっているときには、失敗の要因につながるものがあっても全て水面下で隠れてしまうのだ。
それはやがて大きくなって水面上に現れる。
だから私たちは成功や成長しているときほど先人たちの失敗事例を通じて、その「水面下に潜む課題」について考える必要があるのだ。
だからこそ本書を読む意義がある。

荒木氏は、現在フライヤーというベンチャー企業や自身が創業した学びデザインという会社の経営に携わる傍ら、ビジネススクールの教壇に立ち、社会人学生と「経営戦略」という領域についての議論を重ねている人物である。
セオリーを教える立場でありながら、経営の現場ではそのセオリーの実践がいかに難しいかを感じている毎日だそう。

この本はそんな荒木氏が、私たちにとって親しみやすい企業を中心に、時代や業界、地域にもできるだけ多様性が出るように選定した25社の倒産ストーリーである。

それぞれ倒産した事例について「どういう企業だったのか」「なぜ倒産したのか」「どこで間違えたのか」「私たちは何を学ぶべきなのか」という項目に分かれていて私たちの普段の生活の中でも活用できる学びがある。

例えば「千代田生命保険」は私たちもついつい陥ってしまう思考で倒産してしまった歴史ある生命保険会社であった。

1904年に創業した千代田生命保険はこの年に勃発した日露戦争の戦死者に対してきっちり保険料を支払ったことで日本において生命保険を不可欠なものにした。

その後も幅広いネットワークを築き1930年にはトップ5で5割以上のシェアを占める生命保険になったのだ。
しかし、業界が徐々に過当競争になり存在感を落とし続けていた千代田生命保険は、「営業のドン」と呼ばれていたカリスマ的存在の神崎安太郎氏を社長に任命する。
この神崎氏による「高利率・高配当の商品を通じた積極的営業攻勢と、ハイリスク・ハイリターンの投融資先開拓」でいったんは生保内での順位を上げ、8大生保という大手カテゴリーのくくりに入ることに成功したもののその当時、世の中はバブル、それは一気に崩壊したのだった。

かつて大手だったにもかかわらず、今や中堅生保という立ち位置に甘んじ、さらにトップとの差が開いていく、ということに対する焦りと屈辱。
そして、目の前にはややリスクが高いけれど、競合が着手しておらずニーズのある攻め口があります。
「これをやれば一発逆転ができるかもしれない」と感じさせるバブル特有の空気も作用し、他社よりも少しでも先んじて意思決定を進めたい、という気持ちが芽生えたのでしょう。

このような状況になると、人間は「見たいものを見る」という状況になります。
「株価が下がるかもしれない」「貸し倒れになるかも知れない」という可能性は目に入らず、プラスシナリオの情報ばかりが目に入り、その思考は一層強化されていきます。

三者から見たら無謀に思えても本人からしてみれば合理的だと思い込んでしまうことはとてもよくあることだと思う。
こういう状態になってしまうと第三者からの意見を取り入れることは難しく、独りよがりの考え方になってしまうのだ。
自分の人生は自分で決めるものであるが、ときには千代田生命保険が陥った失敗をしないように、自分以外の新しいものの見方を取り入れたうえで、自分の考え方とバランスをとっていくことが重要ではないだろうか。

他にも魅力的な倒産ストーリーはたくさんある。
僕たちZ世代の記憶にも新しいピンク色のうさぎのCMで有名な英会話の「NOVA」はマネジメントが大雑把で規律が効かずに倒産したし、きっと幼少期に一度は行ったであろう「トイザらス」は、eコマース事業に出遅れ、アマゾンに任せてしまって倒産した。

かわいらしいイラストでの説明もあって、経営についてド素人な僕ののような人でも読みやすいように工夫がされている。
タイトルに「図鑑」とあるだけあってボリュームはあるが、倒産の仕方のジャンル分けもされているのでそれも気にならない。
仕事やプライベートでうまくいっているときにこそ、本棚から取り出してふと読み返したい一冊である。

『ハウ・トゥー:バカバカしくて役に立たない暮らしの科学』

本を選ぶときには「この本はどんな知識を得られるだろうか」とか、「この知識は身につけておいた方が良さそうだな」と、だいたいそんなことを考えると思う。
だから自分の役に立ちそうな本を普通は探す。
だけど、今回紹介する本は残念ながら誰の役にも立ちそうにない。

もちろんそれは僕にとっても例外じゃなく、少なくとも暮らしを「便利にする」ような役立つ情報は書いていない。
タイトルにある通りバカバカしくて思わず笑ってしまうようなアイデアが次から次へと出てくる。
だから世界観を広げていきたい20~30代の若者におススメできるかもしれない。

では何が書かれてあるかというと、私たちの生活にあるさまざまなやり方(ハウ・トゥー)に対して、科学を使ったちょっと変わったアイデアだ。

この本では、ありふれたものごとに対処する変わった方法を探り、そんな方法を実際にやってみたらどうなるかを見ていく。
そうした方法がなぜうまく行くのか、あるいは、うまく行かないのかを突き止めるのは楽しく、ためになるだろうし、ときには驚くような展開が待っているだろう。
ある方法がうまくないとき、なぜその方法がうまくないのかをきっちり突き止めることで、あなたは多くを学ぶことができる。
―――そうすることで、もっといい方法を思いつくヒントが見つかることもある。

例えば、13章に「鬼ごっこをするには」という章がある。
ごっこをするのにやり方もクソもないんだけれど、ここではわざわざウサイン・ボルト(世界最速の短距離走者)とヒシャム・エルゲルージ(1マイル競争の世界記録保持者)が出した世界記録を使って2人が鬼ごっこをしたらどうなるかを計算したり、マラソンのチャンピオンに追いつかれないようにするために好きなだけ早く走ることができるマジック・スクーターに乗って、鬼があきらめるまで世界中を回りつづけることができる……なんてことが書かれている。
うん、見事なアイデアだ。

この本すごいところは、そんなことを聞いてどうするんだというような質問にその道の専門家が真面目に答えてくれていることだ。
特に第5章の「緊急着陸するには」が印象的だった。
そこではテストパイロット兼宇宙飛行士のクリス・ハドフィールド大佐が著者の面白い質問にたくさん答えているので、一つだけ抜粋してみる。

質問:私と友人が一緒に、それぞれ同じような小型飛行機に乗って、サメがうじゃうじゃいる海の上を飛んでいたとします。
私のほうは飛行機の燃料が切れそうになってしまいましたが、パラシュートを持っています。
友人は私の隣を飛んでいます。
私は自分の飛行機から抜け出して友人の飛行機に乗り込み、しかも私の飛行機を着陸させられるでしょうか?

答:あなたの飛行機がコックピット開放型の複葉機なら、たぶんできるでしょう。
飛行機の制御装置をオートパイロットに設定し、友人にできるだけ近づいてもらい、コックピットから抜け出して翼の上に乗り、手を伸ばして相手の飛行機の翼をつかみ、相手のコックピットのなかに乗り込みます。
コックピット開放型でなければならないのは、風防や扉に対処する必要をなくすためで、複葉機でなければならないのは、支柱を手でつかむためです。
もしもあなたが自分の飛行機から飛び出して、パラシュートのおかげで浮かんでいるあいだに友人にうまくつかんでもらおうと期待するなら、あなたはたぶんサメのランチになるだろうと、私は思います。

こんなシチュエーションは今後生きているうちでまず巡り合わないだろう。
だから何の役にも立たない。
そこにこの本の醍醐味があると思う。
バカバカしいと思いながらもページを繰る手が止まらない……。
読み進めるほどワクワクするような、謎の期待感を味わうことができるだろう。

人生には試してみないとわからないことがたくさんある。
食わず嫌いではもったいない。
明王エジソンはこう言っている。
「私は失敗したことがない。ただ、1万通りのうまく行かない方法を見つけただけだ」

あれ?やっぱり、この本も役に立ちそうだなあ。