【読書感想ブログ】心理的安全性のつくりかた
参考図書
心理的安全性のつくりかた 「心理的柔軟性」が困難を乗り越えるチームに変える | 石井遼介 | ビジネス・経済 | Kindleストア | Amazon
心理的安全性とは？
心理的安全性とは
チームに対して自分の意見や質問等を気兼ねなく言えて、それを言っても非難や罰を受けたりしない環境のこと
ハーバード大学のエイミー･C･エドモンドソン教授により提唱された概念で、Google の「効果的なチームはどのようなチームか？」という調査の中で『心理的安全性の高いチームが良い生産性を出していた』という結果を報告し、一躍有名になりました。
エドモンドソン教授は心理的安全性が高いかどうかの指標を出すために「心理的安全性を計測する７つの質問」を発表しています。しかし、日本でこの計測を行うと、米国との文化の違いにより質問の解釈にブレが生じ、うまく計測できないという事態になりました。
そこで、著者の所属している会社で、エドモンドソン教授の心理的安全性を踏襲しつつ、日本で心理的安全性を高めていくためにはどうすればいいかを研究し、最終的に、以下の4つの因子が重要であることを突き止めました。
日本版心理的安全性4つの因子
- ①話しやすさ ・・・ 「何を言っても大丈夫」→ 率直に意見できるチーム
- ②助け合い・・・「困ったときはお互い様の精神」→ 問題に対してチーム一丸となって対処できるチーム
- ③挑戦・・・「とりあえずやってみよう！」→ 挑戦に失敗しても改善点を探し、繰り返し挑戦できるチーム
- ④新奇歓迎・・・「異能、どんとこい！！」→ 個々人の個性が活かせているチーム
では、これらの因子を自分のチームで高めていくにはどのようにすればいいのでしょうか？この書籍では「行動分析」によってそれらを高めるアプローチを紹介しています。
行動分析
行動分析とは、『ある行動には「きっかけ」があり、行動の後には「みかえり」がある。「みかえり」によって、次の行動がきまる」』という理論から来ていて、行動を分析する場合にこの
「きっかけ」→「行動」→「みかえり」→「(次の)行動」
というフレームワークに当てはめることで、なぜその行動をとった(とる)のかを分析する手法のことです。
例えば、「ラーメン屋でご飯を食べる」という「行動」は、「お腹がすく」という「きっかけ」があり、ご飯を食べるという行動の後には「お腹が満たされる」や「おいしいと思う」などの見返りがあります。そうするとまた、お腹がすいたらまたこのラーメンを食べに来ようという気持ちが生まれ、同じ行動をとるようになります。
この行動分析を使って 先ほどの因子を分析してみましょう
「①話しやすさ」の行動分析
「①話しやすさ」を向上させる行動は主に「会話する」や「報告する」ことです。
例えば、部下から報告を受けたときに、その報告の質が悪かった場合、怒ったりしていませんか？
「君の報告はわからん、もっとわかりやすく説明してくれ」なんて言ってすぐに部下が対応できるのであれば、言われる前にしていますよね。なのでその指摘はあまりに意味がありません。
もっと言うと、怒ることで次から報告してくれなくなる可能性もあります。質も悪い上に報告もなくなってしまったのであれば本末転倒ですよね。
そういう場合は「報告する」という行動は維持しつつ、内容の質を上げていくことが重要です。
なので、まずは報告してくれたことに対してしっかり「報告してくれてありがとう」と伝えましょう。それが部下への「みかえり」となり次からも報告してくれるようになります。
その上で、報告内容について不十分な点があるのであれば、丁寧に相手に誠意をもって伝えていくことが重要です。
このように、話しやすさを向上させるためには「この人には話しかけても大丈夫なんだな」という気持ちを相手に抱かせるような対応が必要となります。
「②助け合い」の行動分析
「②助け合い」を向上させるための行動は「相談する」や「相談に乗る」等です。
基本部下は上司に対して話しかけることは気が引けますので、上司からシンプルに部下に対して「困っていることある？」等の声掛けをすることが重要です。
そして困っていることを吐露された場合、高圧的にならずに、同じ立場になって問題に取り組み解決しようとすることが重要です。
そうしないと「相談したけど、怒られた。今度からは相談しないようにしよう」と思われてしまいます。
このように、「②助け合い」を向上させるためには「相談するきっかけを作り」→「一緒に悩み」→「相談してよかったと相手に思ってもらう」ことが重要です。
「③挑戦」の行動分析
多くの組織では「挑戦する」ことは日常的なことではないので、挑戦する「きっかけ」を作るように心がけましょう。
おそらくこれは、ひとりできるものではなくチーム全体に理解を求めて、それこそ挑戦していくことになると思います。
ここでは挑戦するためのアイデアを一部紹介します。
例えば、グーグルでは、20%ルールというものを導入しています。「仕事に使う時間を分割して、少なくともその20％を、すぐに見返りを得られる見込みはなくても、将来大きなチャンスになるかもしれないプロジェクトの探索や取り組みに使う」というルールです。これはマネージャーレベルの人に進言しないと実現できないかもしれませんね。
また、「何か改善することはないか？」というふうに広く意見を募ると意見が出なかったりします。範囲を限定して意見を募ってみるのも一つです。「顧客の不平・不満、悩みや課題といった『顧客の負』を探し、それをなんとかできないかを考える」といったことを実践してみてもよいでしょう。
もう一つは「挑戦することを歓迎するよう進言する」ことです。例えば「これまでは正解があり、言われた仕事を淡々とこなしているだけでも問題がなかった時代ですが、これからは正解のない時代、挑戦無くして仕事はできません」といった話を交えながら、チームの同意を得れるように努力しましょう。
最後のアイデアは、何か手法だったりツールだったりを2週間ほど試してみて、取り入れたり、修正していったりを繰り返してみましょう。「試してよい」「自分たちに合わせて修正してよい」という雰囲気をつくるところから始めると、挑戦するハードルが下がり、よいサイクルが生まれるかもしれません。
書籍にも書いてありますが、こういうチーム全体の変革を必要とすることは難易度が上がります。ただ、難易度が高いからと言ってリーダー・マネージャーが変えてくれるまで待つのではなく、「自分が心理的安全性をこのチームに導入するんだ！」という強い気持ちをもって活動することが心理的安全性を向上する上で重要なファクターとなりますので、頑張ってください。
「④新奇歓迎」の行動分析
新奇歓迎とは個人の個性やその人らしさを大事にするということです。
とある研究結果でオペレーションセンターの新入社員を以下の3つのグループに分けました。
①個人のアイデンティティを重視する研修
②会社のアイデンティティを重視する研修
③例年通りの研修
それぞれのグループの顧客満足度を調査したところ。①のグループが33%も高いという結果がでたそうです。
研究結果のまとめには「ありのままの自分を認め、受け入れてくれる他者と関係を築くことで情報共有と協力しあう傾向が高まり、結果として生産性が上がる」と報告されていました。
では、自チームに新奇歓迎を起すためにはどうすればいいでしょうか？
それは「率直に個性を発揮することを促す」ことです。「このチームでぜひ自分自身の強みを発揮してほしい、チームメンバーの感情や仕事への敬意は忘れず、けれどもあなたらしく働いてほしい」といったことを伝えることが「きっかけ」となります。
うまくいかなくても「強味を発揮しようとしてくれてありがとう」と感謝を伝えることで「みかえり」となり行動の継続を促すことができます。
また、その人の個性を見抜き、その人の個性に合った仕事に最適に配置することをしてみてください。
心理的柔軟なリーダーシップ
また、この書籍には「心理的柔軟なリーダーシップ」という新たな考え方を提案されていました。
心理的柔軟なリーダーシップとはチームや個々人に合わせて臨機応変にリーダーシップの形を変えながら柔軟に舵取りをしていくリーダーシップのことです。
「今までがこうだったんだから、今もこうしなければならない」とか「この目標を達成するためにはこうするしかない」といった凝り固まった考えで進めるのではなく、チームを見て今できる最適解を探しつつゴールに向かうことができるリーダーシップのあり方を提案されています。
心理的柔軟なリーダーシップを行うには以下の3つの柔軟性が必要です。
①必要な困難に直面し変えられないものを受け入れる
②大切なことへ向かい変えられるものに取り組む
③マインドフルに見分ける
これらを少し詳細に見ていきましょう
①必要な困難に直面し変えられないものを受け入れる
「必要な困難」とは「否定的な思考や感情」のことです。
人は世界を色メガネで見ています。思い込みも多分に含まれているでしょう。ある人と意見が対立した時、「俺の意見が正しいのに」と相手を非難してしまいがちですが、相手を非難することは心理的安全性を下げる要因となってしまいます。心理的柔軟性において、考え自体が正しいかどうか、考え自体が真実かどうかは あまり重視しません。心理的柔軟性において重要なのは 今この状況で役に立つかどうか です。「役に立つ」とは「未来を予測でき、未来に(ポジティブな)影響を与えることができること」です。つまりは、
「チーム全体が納得のいく形でゴールに進められる」時が「役に立つ」ということです。
イヤなことがあった時、あなたはその感情をコントロールしようとするでしょう。メンバーを問い詰めたり、進捗を細かく報告するように求めたり、別のことを考えたりするかもしれません。これはイヤな気持ちを受け入れずにコントロールしていることになります。
イヤな気持ちをコントロールに集中してしまうと、それに労力をつかってしまい、本来のゴールにたどり着けない恐れがあります。
イヤな気持ちをコントロールすることは役に立たないばかりか、逆にコントロールすることこそが問題を作り出してしまいます。
「人生には苦痛があることがノーマル」だということを心底受け入れ、理解することが大事です
バグが出ても「このタイミングでよかった」「後工程で見つからなくてよかった」等 よい側面から見ること で、人にあたることなく問題に対処できるようになるでしょう。
②大切なことへ向かい変えられるものに取り組む
個人であれ組織であれ、行動を続けていくうえでビジョンの明確化は重要です。
我々は何のために今の仕事をやっているのか？どこに向かって進んでいるのか？進んだ先にある未来は？
そういうことをチーム内で共有しておかないと人はすぐに「やらされている」という気持ちを持ちます。
「やらされている」という仕事からはイノベーションは起こらず企業競争力は低下してしまいます。
そういう意味でも「チームが大切にしていること」と「私が大切にしていること」は明確にしておくべきです。
「私が大切にしていること」は仕事に限らず、心の底から大切だと思えることを自由に選択することが重要です。
また、大切なことは一つじゃなくてもよいです。
そして、大切なことが明確になった後は、大切なことに向かって着実に一歩一歩進むようにしましょう。
歩みを進めていくうちに困難が立ちはだかるときもあるでしょう。
その際に「失敗するんじゃないか」「恥をかくのではないか」とネガティブな考えが浮かんでくるかもしれません。
これは「柔軟性①」で扱った「困難な考え」そのものです。「困難な考え」はコントロールせずに受け入れ
着実に大切なことに向かって行動するようにしましょう。
③マインドフルに見分ける
マインドフルの意味をネットで調べてみると「〔人が周囲のことなどに〕気を配る、意識している」と出てきます。
この書籍でも「心理的安全性をチームに導入するためには、チームの反応を重視して柔軟に行動、やり方を変えていくことが重要」とあります。
要は、チームに気を配り、チームを意識して、決して独りよがりにならず、大切なことへ向かうことを行動を常に考えながら推し進めていくことが重要です。
そのためには、今この瞬間を「意識できているか」が重要です。今、この瞬間、我々は大切なことへ向かう行動ができているだろうか？
そういった気持ちを常に持っておきましょう。
過去、未来を疎かにしてよいという話ではありません。もちろん過去の失敗から学ぶことも重要ですし、ある程度未来を予測して行動しなければなりません。
とはいえ、過去・未来に縛られ大切なことへ向かう行動が疎かになってしまっては本末転倒です。
また、自分が今まで作り上げてきた自分像に縛られ、大切なことから離れるような行動をとることはやめましょう。
今の自分を客観視して、今の自分は大切なことに向かっていけているのだろうか？
ということを「意識」しましょう。
まとめ
この書籍に書いてあることって、すごく当たり前のことなんだなと思いました。
例えば、
人とちゃんと話をしよう。
人を卑下するようなことはせず、ポジティブな側面を観よう。
挑戦している人を馬鹿にせず、応援しよう。
多様性を受け入れ、協力していこう。
これってどれも当たり前のことなんですけど、仕事になると途端にできなくなってしまったりします。
私はQAチームのメンバーなので「開発はバグばかりだして、スケジュールも遅らせる。遅らせた分のしわ寄せは我々がとる羽目になる」
といった人をターゲットにした問題提起が頻発しているような気がします。
開発もチーム・組織の一員であり、開発チームもわざとそのように行動しているわけではないので、きっと「きっかけ」「みかえり」から
悪循環が生まれているのだろうなぁと思っています。
この書籍には、この「きっかけ」「みかえり」の行動変容のさせ方や、心理的安全性をチームに導入するためのアイデアについても
言及されているので、興味のある方はお手に取ってみてみることをお勧めします。
Rust で Ruby の拡張を書くことができるらしい
私は Windows 使いなので Windows を使って Rust で Ruby を拡張したい。 最近（といっても半年前）rubygem が Rustで書けるようになったらしいので書いていきたい。
Ruby をインストール
ここから +DevKit のインストーラーを使ってインストール
RubyInstaller2でMinGWも入れます。
MinGW版Rustをインストール
こちらを参考に MinGW版Rustをインストール
PATH / PKG_CONFIG_PATH / XDG_DATA_DIRS は DevKit内のMInGWのパスを指定します
pacman のインストールは clang のパッケージまでやりました。
pacman -Syuu pacman -S mingw-w64-x86_64-toolchain base-devel msys2-devel pacman -S mingw-w64-x86_64-clang mingw-w64-x86_64-llvm mingw-w64-x86_64-clang-tools-extra
Ruby拡張を書く
上記を参考に作成します。
gem は rb_sys と rake-compiler をインストールしておきましょう
gem install rb_sys gem install rake-compiler
bundle gem の行は 写経すると動かないので bundle gem rust_uuid --mit --ext としましょう。
まとめ
Ruby は YJIT も Rust で書き直されていて、 Rust と Rust の親和性はどんどん高まっていますね。 Matz は コアはずっとC言語だろうと言われていますが、 エコシステム(特にC拡張部分) は Rust でどんどん置き換わっていくかもしれませんね。
トレイトオブジェクトを返す関数の作成
Boxでくくって、dyn キーワードをつけるのがミソ
trait Animal { fn cry(&self); } struct Dog {} impl Animal for Dog { fn cry(&self) { println!("ワン"); } } struct Cat {} impl Animal for Cat { fn cry(&self) { println!("にゃん"); } } fn new_animal(animal: &str) -> Box<dyn Animal> { if animal == "Dog" { Box::new(Dog{}) } else { Box::new(Cat{}) } } fn main() { let animal = new_animal("Dog"); animal.cry(); }
関数からの戻り値のオーバーヘッドが気になったので調べてみた
モチベ
Rust では以下のようなコードはコンパイルでエラーになります。
fn func1() -> &'static String { &String::from("test") } fn main() { println!("{}", func1()); }
↓コンパイル結果
error[E0515]: cannot return reference to temporary value
--> src\main.rs:2:5
|
2 | &String::from("test")
| ^--------------------
| ||
| |temporary value created here
| returns a reference to data owned by the current function
エラーの通り、関数内で作成した値の参照を返すことは基本的にできません。 なので、値を返したければ、値そのものを返すようにしないといけません。
fn func1() -> String { String::from("test") } fn main() { println!("{}", func1()); }
↓実行結果
test
ただ、値を返すとなるとコピーのオーバーヘッドが気になるところですよね。 ネットでも同じようなことを気にされている方がいらっしゃいました。
Function returning a String, does it copy the value? - help - The Rust Programming Language Forum
回答者の方は、「値返しの場合はCopyやcloneは発生せずMoveが発生するだけだから、そこまで気にするオーバーヘッドは発生しないから気にしなくていいよ」 という回答をされていますが、とはいえMoveが発生するということは新しくメモリを確保してそこに移動するってことなので、ある程度はパフォーマンスの低下が発生するのでは？と思ったのでした。
調査
簡単なタプルを作って、関数の戻り値のアドレスがどう変化するのかを見てみました。
#[derive(Debug)] struct MyStruct(i32, Vec<i32>, i32); fn dump(title: &str, x: &MyStruct) { println!("{}", title); println!(" x : {:p}", &(x)); println!(" x.0 : {:p}", &(x.0)); println!(" x.1 : {:p}", &(x.1)); println!(" x.1[0] : {:p}", &(x.1[0])); println!(" x.2 : {:p}", &(x.2)); println!(); } fn func1() -> MyStruct { let x = MyStruct(2, vec![1], 4); dump("in func1()", &x); x } fn main() { let mut x = MyStruct(1, vec![2], 3); dump("first x", &x); x = func1(); dump("second x", &x); }
結果↓↓↓
first x x : 0x64f7bf278 x.0 : 0x64f7bf498 x.1 : 0x64f7bf480 x.1[0] : 0x12a4c1591f0 x.2 : 0x64f7bf49c in func1() x : 0x64f7bf218 x.0 : 0x64f7bf4d0 x.1 : 0x64f7bf4b8 x.1[0] : 0x12a4c159210 x.2 : 0x64f7bf4d4 second x x : 0x64f7bf278 x.0 : 0x64f7bf498 x.1 : 0x64f7bf480 x.1[0] : 0x12a4c159210 x.2 : 0x64f7bf49c
結果から分かることは、
- 関数から戻り値は別の場所にムーブされている
- 構造体内のベクタ変数の実態はムーブされず、ベクタ変数への参照のみがムーブされている
推察
ここから察するに、『関数からの戻り値はシャローコピーのみが発生している』ということですかね。 ディープコピーじゃないからパフォーマンス的にもそんなに気にすることじゃなくて メモリ的にも優しいよって話なのかもですね。
ベクタ型内の要素をループ内で借用してループの外で使う場合はベクタ変数を借用してループを回そう
今回のソースコード
struct A { val: i32, } fn main() { let mut a_list: Vec<A> = vec![]; for i in 1..10 { a_list.push(A { val: i }); } let mut inner_elem = &A { val: 0 }; for a in a_list { match a.val { 3 => inner_elem = &a, _ => {} } } println!("{}", inner_elem.val); }
上記のようにベクタ型変数の要素をループの中で借用してループのスコープの外の変数に束縛するとコンパイルエラーが発生します。
|
16 | 3 => inner_elem = &a,
| ^^ borrowed value does not live long enough
...
20 | }
| - `a` dropped here while still borrowed
21 |
22 | println!("{}", inner_elem.val);
| -------------- borrow later used here
こういう場合は、ループを回すおおもとのベクタ変数を借用して回すと解決します。
struct A { val: i32, } fn main() { let mut a_list: Vec<A> = vec![]; for i in 1..10 { a_list.push(A { val: i }); } let mut inner_elem = &A { val: 0 }; for a in &a_list { // ^ ここの & が無いとコンパイルエラーが発生する。 match a.val { 3 => inner_elem = &a, _ => {} } } println!("{}", inner_elem.val); }
【読書感想ブログ】ラブカは静かに弓を持つ【ネタバレあり】
ラブカは静かに弓を持つ | 安壇 美緒 |本 | 通販 | Amazon
以前紹介させて頂いた「5A73」同様、こちらも千原ジュニアYouTubeのチャンネルでカモシダせぶんさんが紹介されていた書籍です。
JASRACとヤマハ音楽教室が裁判で争っているのはご存じでしょうか？(私は知りませんでした)
ヤマハ音楽教室の講師が生徒に教える場合に演奏することは公衆の面前での演奏に該当するため音楽教室側は著作権料をJASRACに支払わなければならない。ということらしいです。私としては、トンデモな難癖な気持ちもありますが、現状最高裁まで判断が持ち越されているぐらいには意見が分かれているようです。これでJASRAC側が勝ってしまったら色々なところに波及しそうな気がしますね。できればヤマハ音楽教室側に勝ってもらいたい気持ちがありますが、著作権料を徴収することで生活できている人たちもいることを考えると複雑な気分ですね。
ということで、そんなJASRACとヤマハ音楽教室の抗争を題材にした話（もちろん名前は変えてあります）なのですが、主人公はJASRACの社員。上司に命令されて音楽教室に生徒として潜入して講師が無断で音楽を演奏してる証拠を集めるように言われます。要は潜入調査（スパイ）ですね。スパイものってなんか惹かれるものがないですか？007であったり、SPYxFAMIRYだったり。(SPYxFAMIRYは違うかｗ)
なんしか、私は、ばれるの？ばれないの？どうなっちゃうの～っ！？ってドキドキしながら次の展開を読むことができるので気になって一気に読んじゃいます。
主人公はチェロの生徒として2年間潜入するわけですが、講師の人もいい人で、同じ講師に教えてもらっている生徒の人たちとも飲み会で仲良くなっていきます。その中で、教室に通うことが楽しくなっていってしまう主人公は、自分がこの人たちを騙しているんだという罪悪感と戦いながら、毎回レッスンではボールペン型のボイスレコーダーにレッスンの内容を記録して上司に提出することになります。
こういう二面性を持ったまま生きることってなかなかに辛いことだと思うんですよね。私ならすぐに心がすり減ってしまいそうになります。人間って基本正直者な生き物だと思うんですよね。嘘をつくぞ！と気合を入れないと嘘は付けない。ましてや、好意を持っている人に嘘をつき続けないといけないとなると正気ではやってられないんじゃないか？と思います。
主人公がレッスンに通い始めて数ヶ月経ったある日、音楽教室内で発表会をすることになり、その曲を決めることになります。主人公は自分では決めれないので、講師の人に選曲をお願いするのですが、選ばれた曲が昔の映画『戦慄きのラブカ』の劇伴として使われていた曲。映画『戦慄きのラブカ』はスパイ映画らしく、今の主人公ともかぶるところがあるというのがにくい演出ですよね！！
また、この作者のクセなのか、心の描写が特徴的な部分がいくつかあって、例えば、主人公はチェロにちょっとしたトラウマがあって、チェロを見ると動機が激しくなってしまうのですが、その描写が「心臓が耳の横までせり上がって来たかのように、ボン！ と音が大きく弾けた」という表現になっていて、心臓の鼓動を表す表現に「ボン！」という表現はなかなか使わないなぁと思ったのが印象的でした。この小説内でも度々「ボン！」は使われていて、単純に作者が好きなだけなのか？とも思っていますが。。。
それ以外にも、美人社員が序盤に言い寄ってきて不思議に思っていたのですが、後半でまさかの絡みがあって「そうきたか～！！」という感じでした。あまり、ネタバレを言うのもアレかと思うので、どういう展開になったかは皆さんで読んで確かめてみてもらえればと思います。
まとめ
やはり、本好き芸人のカモシダせぶんさんがオススメされる小説なだけあって、序盤から楽しめる作品でした。人を騙すことと人間の信頼関係について思いを張るとともに、人間は基本的には正義感も持っていて、誰も騙したいから騙しているわけではないのだろうなぁということを思ったりしました。できるだけ嘘をつかない人生でありたいものですね。
【読書感想ブログ】ショートショート実験室
ショートショート実験室 | 田丸雅智 |本 | 通販 | Amazon
「ショートショート実験室」というからには短編集なのだということはわかるけど、「実験室」とはどういう意味なんだろう？作者の実験的な技法なりを用いた短編集なのだろうか？そういう興味本位からこの本を手に取りました。最初の物語は「二酸化炭素バスターズ」。ある男性が朝散歩に出てみると、大きな掃除機のようなものを背負って何やら吸い込んでいる男性と出会う。掃除機の男性に話を聞くと地球温暖化対策の一環で大気中の二酸化炭素を吸っているのだと言う。いくつかの問答の後、散歩中の男性も二酸化炭素バスターズに入りたいというのだが。。。
１、２編読んでなるほど環境問題を取り上げて風刺を利かせたファンタジー小説であり、こういう風に環境問題に取り組んでみたらどうだろうか？という実験も兼ねているのだろうなと思い至りました。なかなかこういった発想で物語を夢想したことがなかったので、面白い切り口だなぁと思いながら読み進めることができました。
あとがきを読んで知ったのですが、作者の田丸雅智さんは現代のショートショートを代表する作家さんらしく、多くの短編作品を世に出されている方のようです。Amazon にも多くの書籍が販売されていました。
また、noteでショートショートが書けるカードゲームなんかも発売されているようです。
いろいろチャレンジングなことをされている方で、興味深い人だなぁと思いました。
話を「ショートショート実験室」に戻しましょう。全短編にはちゃんとオチがあって、そのオチが「ははぁ、なるほどなぁ」と思うものもあれば「ん？これはどういう意味だ？」というものもあり、短編を読んでから次の短編を読む間に少し時間を設けて「うーん」と考えてしまうこともありました。例えば、「砂モデル」という短編がありまして、砂がパーツのプラモデルが駄菓子屋で販売されていて少年がそれを購入し一生懸命組み立てた後、できたと思って寝て起きたら砂になってなくなっていて、おばあちゃんに聞いてみると、波にさらわれてしまったんだねと言われてしまいます。少年はなぜかその儚さに魅了されて何度も砂モデルを買っては組み立て、買っては組み立てしていたが、少年の心はいつぞやからか砂モデルからは離れていき、少年は大人になる。大人になったある日、その少年は物置の奥からまだ組み立てていなかった砂モデルを発見する。久々に組み立ててみるかと箱を開けると、パーツは一つも見当たらない。あるのは波にまかれて舞い上がる黄色い砂だけであった。。。そういう話なんですが、皆さんはオチの部分をどういう解釈をされますか？私は地球温暖化によって海水の水位が高くなってしまって当時の砂浜だったところが海水に満たされるまでに水位が上がってきてしまって組み立てる前に波にさらわれてしまった。というオチに思えました。こういうオチなのかな？と考えるのもこの本の面白いところかもしれませんね。皆さんも、ショートショート実験室を読んでオチを楽しむとともに、環境問題についても考えてみてはどうでしょうか？
最近本を読むようになって、僕は短編集が性に合っているのかなぁという気がします。寝る前に数ページ読んで、眠くなったら寝る。そういう本の読み方をしているので短編集はそのサイクルにちょうど合うからなんでしょうね。今後も田丸雅智さんのショートショートは読んでみようと思います。それではまた。
