masayuki5160's diary

名古屋でエンジニアしてます。

母がクモ膜下出血になって回復するまで

去年の夏、母がクモ膜下出血を発症しました。
意識を失い倒れたというようなことではないのですが、救急車で搬送しそのまま緊急手術となりました。

現在は後遺症もなく元気になり、以前と同じように生活をしています。
本記事ではそのことについてまとめておきたいと思います。

普段から健康に気を使うのはもちろんですが、不測の事態というのは起きると思います。
私の友人、知人、このブログの読者に限らず多くの方の参考になれば幸いです。

事前メモ

  • 僕は31歳、僕の母は57歳
  • 僕はソフトウェアエンジニアで医療知識はない
  • 出来事の一部の時間は正確ではありませんが、時系列はあってます
  • 話は僕からの視点で書いてます

1日目:クモ膜下出血が発症、緊急手術

6:00

  • 父から携帯に連絡が入る。
  • 母がひどい頭痛と吐き気で朝から様子がおかしいとのこと。
  • 父は仕事にどうしても行く必要があり、代わりに見て欲しいということ。

7:30

  • 実家へ到着(僕の自宅から実家へは電車を使い片道40~50分程度)
  • 父から母の様子を聞く。30分おきに計測した血圧は上が160〜200となっているものの、今は少し落ち着いて150程度になっていた。(実家には血圧計測機器があります。)
  • もちろん母は意識あり。だいぶしんどそうだが話はできる。母は座敷の居間に横になった状態。
  • 父は出社するが10時すぎには多分戻ってこれるはず、ということでしばらく僕がそばにいるということで話をする

8:00頃

  • 父が家をでる

8:30

  • また頭が痛くなってきたので、念のため母が血圧を測って欲しい、というので血圧を計測。上が150程度だった。

8:40

  • 母がトイレに行く。歩くのがしんどそうだが自分でゆっくり歩いていく。
  • トイレから戻って座敷に横になると吐き気があるらしく、洗面器を手に取る。

8:46

  • 父から電話があり、様子を伝える。
  • 父は予定していた10時ごろには戻ってこれそうになく、昼過ぎ頃になりそうだということ。
  • 母の様子を伝え、救急車を呼ぶことを伝えた。父は僕の方で母をかかりつけの病院まで送ってもらえれば、ということだったが、今の状態の母を僕が車に乗せていくこと、そして明らかに母の様子が異常なことから救急車を呼ぶべき、と僕の方で判断。

8:47

  • 119へ電話
  • 母の様子、血圧などを伝える

8:50

  • 救急車はすぐに到着
  • 隊員の方に容体を伝え母を送り出す。
  • 母は意識あり。
  • 隊員の方は容体を聞いてくも膜下出血の可能性を考えたのか、手足を動かせるかを母に問診(隊員の方の手を握れるか、腕をあげられるか、膝を起こせるか)
  • この時、隊員の方が血圧を測ると確か180程度といっていた
  • 僕は救急車には同乗せず、後から行くと伝えた

9:20

  • 車で病院に到着し待合室でまつ

9:30

  • 医師(脳外科医の先生含む)から説明を受ける(僕のみ)
  • 母はクモ膜下出血であり、緊急の手術が必要とのこと
  • 再出血をした場合は非常に危険で亡くなる方もいる、が、社会復帰する方もいるとのこと。CTを見ながら丁寧に説明頂く。
  • 手術の承諾書、輸血などの書類にサインをする。
  • 説明の後、母のいる救命センター?の所に案内される。少しだけ母と会話をし、また待合室でまつ。
  • 母が亡くなる可能性については理解したが、全く実感としてはなく、冷静に対応を進めないと、と考えていた

9:45

  • 父に電話
  • 医師からの説明、状況を伝える
  • 急がなくていいので落ち着いてこちらにきて欲しいと伝えた

11:00頃

  • 麻酔医の先生からお話を聞き、全身麻酔などについて話をされ、承諾書にサインをする
  • 母の所に案内される。"大丈夫だよ"、と僕と会話をしながら麻酔が入っていったらしく、母の意識がなくなる。

11:30頃

  • 父が病院に到着
  • 麻酔が入った状態だが母の所に案内され、これから手術に向かうとのこと
  • 東京にいる弟にも電話をして状況を説明。仕事があるだろうが、できればきて欲しい、と伝える。

12:00頃

  • ICUの待合室に案内される
  • 手術が終わるまで待機

12:30

  • 交代で食事に行くことにする。
  • しっかり食べとかないとよくないと思いちゃんと食べる。そこまでお腹は減ってなかったがハンバーガーなら食べたいと思い、マクドナルドへ。
  • 頭が疲れていたからなのかわからないが、無性に散歩をしたくて40分以上はぷらぷら歩いていた

14:00

  • ICUの待合室に戻る
  • 父が食事にいく

14:30

  • 父が食事から戻る。病院の食堂でうどんを食べたとのこと。

15:30頃

  • 弟が病院に到着(東京から)

15:45頃

  • 手術が終わったと看護士の方がくる
  • 脳外科医の先生から説明を受け、再出血もなく無事に手術は終わったとのこと。
  • 今後はしばらくICUに入ってもらい、合併症が出ないよう注意して処置をしていくということだった。
  • 先生から、母はもう麻酔もきっているので話せると思う、と聞く

16:00頃

  • ICUで手術後の母と面会
  • おそらく全身麻酔後ということもあり、朦朧としているが僕らの呼びかけには応じることができ、手を握ると握り返してきた
  • 手足も弱々しく(麻酔のせい?)ではあるが動かせていた
  • まだ母の意識が朦朧としている状態だったこともありICUはすぐに出た

17:00頃

  • 父、僕、弟は帰宅(実家)
  • 僕は体は疲れていないものの、眠気があったり頭がひどく疲れている気がしたので自分の家に戻ってしっかり休むことにする
  • 何かあれば病院から父に連絡がある、という状態

19:00頃

  • 自宅に戻る
  • 食欲はあるのでちゃんとご飯は食べる
  • クモ膜下出血についてネットで情報をみる(この時初めてネットを使って情報収集をした。それまでは不安になるだろうと思い、あえてネットの情報に触れないようにしていた)

22:00頃

  • いつもより早く就寝

2日目:母と面会

14:30

  • ICUにいる母に面会(父、僕、弟の三人)
  • しっかり意識もあり、顔色が良い。普段通り会話ができる状態で安心する
  • 手足も問題なく動く状態。母曰く、非常に退屈だとのこと。

15:00

  • 30分ほど話をしていたが、母に徐々に疲れが見えたため帰ることにした
  • 翌日から開始する予定のリハビリについて作業療法士の方から説明を受ける

3日目:リハビリ開始

この日は父に母の面会を任せる。 また、弟は仕事があるため東京に戻る。

17:00頃

  • 父に電話をし、母の様子を聞く
  • 2時間ほど会話をし昨日より元気、ということ
  • リハビリも始まっており、父も同席した。車椅子にうつるリハビリなどをしていた。
  • 時間を持て余している様子で退屈そうだが、やはり疲れやすいみたいだ、とのこと

4日目:リハビリ継続

この日も父に面会を任せる。

17:00頃

  • 父から電話があり、母は昨日より元気な様子
  • リハビリは継続しており、1日2回ほど?しているようだとのこと
  • リハビリの様子を見ていても昨日よりも体の調子は良い(車椅子への移動も昨日よりスムーズらしい)
  • 合併症が起こる可能性があるためか引き続きICU内にはいるが少し落ち着いた場所にうつったとのこと

5日目:面会にいく

14:30

  • ICUの個室にいる母に面会
  • 元気があり普通に会話ができる
  • リハビリを数分行うのに立ち会う

6日目:父が面会にいく

  • ICUから病棟がうつる(一般病棟ではないが、ICUよりは症状が軽い?患者向け)
  • 面会時間の制限が少し軽くなる

14日目:一般病棟に移る

  • 体力は落ちているが普通の人と同じように生活はできる状態
  • リハビリはだいたい1日1時間程度?

今回のことで強く感じたのは救急車を呼ぶかどうかの判断が難しいということです。
クモ膜下出血を発症した場合、再出血をする前にはじめの処置が完了するかがまずポイント何だろうと思います。が、今回の母のような場合、意識があることもあり、救急車をよんでいいのか判断に迷っていました。特に父と母は大雑把にいうと"迷惑にならないか"ということを考え、119へ電話をすることをためらっていました。(安易に救急車を呼ばないで、というような話は最近色々なところで聞きますから、それがあってのことでしょう)

色々意見はあるとは思いますが本当にその場にいると判断が難しいのはよくわかります。
まさかクモ膜下出血だなんて誰も思っていなかったのですから。

じゃあ対策としてどうしたらいいんだろう、と考えてはいますが僕としての結論はまだ出ていません。 ちなみに僕が119へ電話する、と決めた時、もちろん後で"この程度で119へ電話しないで欲しい"と言われる可能性はあるな、と思っていました。それでも僕が119へ電話をしたのは、

  • 母が危険な状態なのかどうかを僕だけでは判断しきれなかった
  • 救急隊の方に怒られたら素直に謝罪しよう、と思っていた

この2点につきます。
僕にとっては1点目が最悪のケースに繋がる可能性が高く、何とか対処したいというわけです。それならば、僕が謝罪するだけで済むならいくらでもしようと考え119へ電話をしました。

そして結果的にはこの時の判断がよかったのかもしれません。

以上です。
普段こういった記事は書かないのですが、こういった情報があまりネット上になく、どなたかの参考になることもあるだろうと思い、まとめることにしました。普段から健康に気をつけるのは当然ですが、不測の事態は起こるものだと思います。その時にどういった対応がいいのか、その後どういったことがおきていくのかなどの参考になればと思います。

TDDをはじめてみたら気づきが多くて驚いている

興味を持ったきっかけ

そもそものきっかけは転職活動時に受けたある企業からテストコードを書くことを採用試験時に要求されたことでした。 それまでテストコードをちゃんと書いたこともなかった僕は採用試験に向けてxUnit系のツールの使い方を覚えるのもあれだな、と思い、今から思えば非常に雑に書いたコードを提出しました。 もちろんその結果、採用は見送りw

その後、他の企業での採用が決まったわけですが、どうしてもその時のテストコードを書く試験が気になっていました。 なんでテストコードを採用試験で書かせたんだろう、ということですね。

それからなんやかんや自分で調べてTDDにたどり着き、というのが始めるまでの僕のきっかけでした。

興味を持ってから

それからやったことは例えば以下。

qiita.com

qiita.com

この辺は自分で本を読みながら試行錯誤していた時です。(今でもだいぶ試行錯誤してますがw) そしてそのあと、和田さんのセミナーに参加しました。

event.shoeisha.jp

自腹で名古屋から参加ということでちょっと海外行くくらいお金かかったんですが、このセミナーに参加してやっとTDDの入り口に立てた気がしたのはほんとです。 特によかったのは、

  • 和田さん、安井さんから直接話を聞ける
  • セミナーの大半を占める実習時間の中でわからない点は和田さん、安井さんからのアドバイスをすぐもらえる
  • 強制的にTDDする時間になる

というあたりでしょうか。 あまり頻繁にやっているセミナーではないのでほんとたまたま参加できてよかったです。

現場でTDD

セミナーを受けてから一番感じたのはTDDは座学でゴニョゴニョするよりは現場で実践を繰り返すのが一番良さそうだ、ということでした。 それは例えば以下資料でもいわれていて、自分の思ってることがそんなずれてなさそうだな〜という確認にもなった。

習うより慣れさせろ、と14ページあたりで記述があるがほんとそうだな、と思った。

そしてちょうどタイムリーに勤め先でTDDを始めることになった。(タイミング良すぎw) でも経験者もいないってことでたまたまセミナーを受けてきたての僕がまずはTDDの紹介をすることになった。 内容としては、

  • TDDの概念ざっくり10min
  • decodeでの和田さんのライブコーディングを一緒に見る 40min
  • セミナーで和田さん、安井さんから聞いてきた内容のシェア 10min

で1時間ほど。 時間をみてもらえるとわかるが、和田さんのライブコーディングを一緒に見る時間をだいぶ多くとった。 ここで僕がTDDを実演してもいいわけだけど、それよりは和田さんがやってる方が説得力あるからな〜というのと(このタイミングでは、何を言うかより誰が言うか、の方が大事だよな〜と感じた)、擬似的にTDDを一緒にやっている体感が得られそうだったから。

FizzBuzz問題のTDDライブコーディングは20分頃からで、その辺りから一緒に動画をみた。 僕が和田さん、安井さんのセミナーで2人がペアプロでTDDをしてくれる様子をみたときも自分の今までの考えがぶっ壊されるくらい衝撃を受けたわけだが、それが参加してくれている人にもおきているような様子があった。

その後は、実際に一部の開発でTDDをしてみたりTDDの練習問題をモブプロで言語別にチームを別れて取り組んでみたりしている。

TDDを通しての気づき

まだ始まったばかりだし、僕自身のTDDやテストコードを書いてきた経験値が少ないのもあってあれだが、例えばこんな気づきがある。

  • ある程度複雑な処理でもテストコードがあるから手戻り少なく開発を進められることがある
  • 途中でTDDじゃなくなってきそうな時もあるが、少なくともサイクルを意識してるのでリファクタリングをマメにする
  • TDDはいい手法だけどそこにとらわれすぎるのもよくない
  • オブジェクト指向についての理解がしっかりあるとよりTDDがいいサイクルでまわりそう
  • 自分がオブジェクト指向を理解仕切れてなさそうなことに気づいたw

と、タイトル倒れの気づきリストで書き出してみてビックリだがこのままにしとくw 個人的には最後の項目が大きくて、大学でもわけのわからないオブジェクト指向の講義を受けたしエンジニアとしてもいくらかコードを書いてきたのにまだ理解が曖昧だったんだ、という気づきはほんとによかった。

この気づきは実はほんとについ最近のもの。そこで以下本を読んだ。

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座

アジャイル時代のオブジェクト脳のつくり方 Rubyで学ぶ究極の基礎講座

アジャイル時代のオブジェクト脳のつくり方 Rubyで学ぶ究極の基礎講座

  • 作者: 長瀬嘉秀,小林慎治,大崎瑶,まつもとゆきひろ
  • 出版社/メーカー: 翔泳社
  • 発売日: 2017/06/29
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

後者の本にはTDDに関して記述があります。 この本でTDDについて本格的に学ぶのはオススメしませんがオブジェクト指向とTDDについてやさしめに話が進んでいくのでそこは素晴らしい本だと思っています。 前者の本はJavaの本で後者の本の元になった本のようで内容がそっくりですがRubyに慣れていない僕にとってはちょうどいい練習問題が参考になりました。

そんなこんなでオブジェクト指向という考えがTDDには欠かせないんだな、と気づき、改めて手元にあるこの本を読んだらなるほどでした。

実践テスト駆動開発 (Object Oriented SELECTION)

実践テスト駆動開発 (Object Oriented SELECTION)

まだ全部読みきれてないのであれですがサブタイトルにも、 テストに導かれてオブジェクト指向ソフトウェアを育てる 、とある。 色々納得がいき、自分に今足りないものに気づけました。

TDD練習問題

ちなみに和田さんと安井さんのセミナーでやった練習問題が公開されています(安井さんありがとうございますmm) 正月明けにもう一度自分で取り組んでみたのが下記です。

github.com

順番逆ですが問題はこれです。

gistc906216ab1fdf68a133ba0fbade1a395

お題3までしか解いてないですがはじめて解いた時とだいぶ内容が変わって自分で驚きました。

おわり

以上です。 今年は引き続きTDDに取り組みつつテストコードを書く経験値を増やしていこうと思います。

"継続的インテグレーション入門"をもう一度読んだ

継続的インテグレーション入門

新品価格
¥3,456から
(2017/9/15 07:53時点)

4、5年前に読んだ際には理解仕切れない部分が多く、改めて読み直してみました。
この本自体は入門という位置付けにあり、初版が2009年ということもあるのでその辺りを考慮しながら読み必要があるケースもあるが総じてCIについてこれから学ぼうとする人々にとってこれ以上ない本なんですね、やっと理解できました。オススメしている方が多いのも頷ける。

オススメな読者

たとえば以下のような方にはこの本をオススメできると思います。

  • CIについてとりあえず全容を知りたい、学び始めたいと考えている方
  • すでにCI環境が整った職場で働いているが実はよく理解仕切れていない方
  • 試行錯誤して自動ビルド環境までは整えたがそこから進めない方(もう一度トライするきっかけになるかも?)
  • ソフトウェアの品質を高めたいと考えている方

僕の場合は3つ目の"自動ビルド環境までは・・・"のに当てはまりますね。
iOS、Androidアプリの自動ビルド環境を整えることがプロジェクトに良い影響があると思い導入はしたものの、それ以上は取り組めませんでした。引き続き環境を整えていくことが品質向上にも繋がるとは知りつつもなかなか進まず、心残りだったのが再度この本"継続的インテグレーション入門"を読んだ理由です。

この本で学べないこと

  • 詳細な環境構築、手順
  • Jenkinsについて
  • ユニットテストに関する詳細

などです。
他にもあるかと思いますが、本書ではCIに関する全容を扱っておりより突っ込んだ内容については別の書籍を参考にするよう書かれています。
最近はJenkinsであったりSelenium、そしてユニットテスト関連の書籍も数多く出てますのでむしろちょうどいいように思います。
他の書籍をよく読んではいないのですが、この"継続的インテグレーション入門"で書かれていることが陳腐化しているということはなく、むしろCI全般を丁寧に扱っている本はいまだにこれだけだな、というようなことになるのかと思います。

以上です。

"起業のファイナンス"を読んだ

起業のファイナンス増補改訂版

新品価格
¥2,484から
(2017/8/6 20:31時点)

ちょうど知りたかったことがまとまっていた非常に読みやすい本でしたのでご紹介。

おすすめする読者

こんな方には気づきがあっていい本だと思います。

  • ベンチャー企業で働く方
  • これからベンチャーで働こうかと考えている人
  • ベンチャーに興味がある人

おそらくファイナンス周りの専門の方には易しい内容なのでしょうか? この辺りは専門外なのでさっぱりですが、一部の章は僕にとっては若干難解でした。

事前知識としておそらく株に関する知識があると読みやすいだろうと思います。 (平易な文章で書いてあるので株についてあまり知らなくても読み進めることはできますが感覚的にわかりづらいかもしれません。)

また、これからベンチャー企業で働く、ベンチャー企業に興味がある、という方にもおすすめですね。 とはいえ、興味があるから、とって読むボリュームの本ではないかもしれませんが、気づきのある本ですので何かのきっかけにもなるはずです。

どんなことが書いてあるのか?

なかなか言いにくいのですが、ざっくりいうとベンチャーの生態系について書かれている、というのが個人的な印象です。 もちろんベンチャーのファイナンスについて書かれているのですが、それを語るのにベンチャー企業に関係する様々な話題を取り扱っています。 一つ一つが著者の経験に基づいているようで非常に説得力があります。 これからも何度か読み直すことになるだろう本だなと思います。

以下記事でもおすすめしましたが、逆説のスタートアップ思考もベンチャー界隈の話が書かれていますが、こちらよりファイナンスよりの内容が濃い本、というというとわかりやすいかもしれません。

masayuki5160.hatenablog.com

エンジニアとはいえこういったお金周りのお話は知っておいて損はないと思っています。 ましてベンチャー企業のようなリスキーな環境を選んで働くのであれば尚更その方がいいのではないでしょうか。 すでにチャレンジしている方も、これからチャレンジしようかと考えている方にもおすすめできる素晴らしい本だと思います。

以上です。

プログラミング言語の実装を深く知りたいエンジニアにおすすめ、"Rubyで作るRuby"を読んだ

RubyでつくるRuby ゼロから学びなおすプログラミング言語入門

新品価格
¥2,592から
(2017/5/21 20:17時点)

読みました、非常にいい本でした。

個人的に読むのをおすすめする人

特に以下のような方におすすめです。

  • 今までインタプリタ等について学んだことがあるが途中(構文解析あたり)で挫折した人
  • とりあえずプログラミングができるようになったけど、もうそろそろ一皮向けたいな、という人
  • Rubyに興味のある人

インタプリタ等について学ぼうとする人は多くいると思います。 世に出てる言語処理系の本の大半は構文解析についてまず解説が始まると思うんですが、これがなかなか読み辛く、一冊読み終えずにドロップしているのではないでしょうか。かくいう僕もなんどもチャレンジしているものの、しっかり読み終えた本は少ないのが正直なところです。 一方で本書は非常に読みやすく今まで挫折した人にも激しくおすすめできます。

こんな本にもっと早く出会いたかった。

本書をおすすめする理由についてざらっと

おすすめできる理由を羅列するとこんなところ。

  • Rubyコミッタの方が書いた本であり、言語処理系の書籍の中では出版が新しい
  • イラスト付きで理解が進みやすい
  • 構文解析について理解するのは大事だが、本書ではそこを最小限にとどめつつ、インタプリタの実装について全体像を伝えることに注力している
  • ページ数が少なく、なんとか理解できる気がしてくるw(130ページほど)
  • 全体的に文章が読みやすい(これは完全に主観、ですが、言語処理系の本はアカデミックな雰囲気のものも多く、それと比較すると非常に読みやすい)
  • 本書のタイトル通り実装がC or C++でないからプログラム読みやすい

特にすごいと思ったのは、インタプリタの実装の全体をまず読者に伝えようとしているアプローチをとっている点です。構文解析の大切さを説きつつも筆者は下記のように本書の中で述べています。

この本の裏のテーマは、すでにRubyや他言語のプログラミングを知っている方に、「インタプリタの実装」というのはそんなに難しいものではない、ということを伝えることでした

こういうアプローチの言語処理系の本は多分初めてなんじゃないのかな、と思います。

というわけで以上です。Ruby使いもそうでない方も、ぜひ一度手にとってはどうでしょうか、では〜。