masayuki5160's diary

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

噂のインフラ勉強会に初参加してきた

はじめに

以前から気になっていたインフラ勉強会に昨日初めて参加してきました。 僕が参加させて頂いたのは下記。

wp.infra-workshop.tech

www.slideshare.net

単純に勉強になったのもあったのですが勉強会として気づきが多く、まとめてみようと思います。 なおインフラ勉強会への参加の仕方などは運営の方(ゆたかさん)が綺麗にまとめて頂いてるのでこの記事では割愛します。

qiita.com

勉強会の雰囲気

"30分で分かる!OSの作り方"の1枠しか僕は参加してないのですが、すごくいい雰囲気だなと感じました。

発表する方もチャットから上がる質問に随時回答しつつ参加者との交流もおそらくリアルでやるより活発だったんじゃないかと思います。チャットだと質問しやすいんですかねw

下記スクショは勉強会終了後のチャット部屋の様子。 発表中もこんな感じで部屋の中で色々会話が進んでいきます。

f:id:masayuki5160:20180505121504p:plain

オンラインということで場を整えるのは大変だと思うのですがそこは運営の方が随時うまく対応頂いててすごいなと思いました。昨日は僕もそうですが初参加の方が多かったようで気にかけてくれているのを感じました、ありがとうございますmm

地方での勉強会

僕は名古屋でエンジニアをしています。 なんで?、というのは以前下記に書きましたのでよかったら合わせてどうぞw

masayuki5160.hatenablog.com

2年前くらいに書いた記事なのでざっと読み返したのですが今と思ってることそんなに変わらないですね。

さて、記事内でも以下のように勉強会について書いてます。

名古屋開催の勉強会が若干少ない。これは仕方ないのですが、最近はちょっと増えてきてるかなという印象。むしろ多すぎることもないのでいいかもしれない?

これは今も変わらず同じ印象です。東京の勉強会いきたいなといよく思ってます。

でも昨日のインフラ勉強会に参加して思ったのは、このインフラ勉強会みたいな勉強会を増やしていければ状況は変わっていくなと感じました。

  • オンラインでやってるから自宅から参加できる
  • オンラインだから地方にいても関係なく参加できる

東京にいても色々な理由で勉強会参加できないことだってあります。 でもオンラインでやってるとなると参加できるケースが増えるのではないでしょうか。

東京で働くエンジニアにとっても、地方で働くエンジニアにとっても双方にメリットがあるように思いました。

まとめ

最近改めてよく感じるんですが業界全体のスピードがまた何段階か上がってきている気がしてます。 僕自身はだからこそこの業界が好きで面白いと感じている部分でもあるのですが、一方でついていけない人もこれから相当数出てくると思います。

それはそれでよくない。 エンジニア一人でできること、やれることなんてたかが知れてるw

働き方が多様になってきて、地方で働く人も増えていく、そうなった時にこういった勉強会が多くのエンジニアを支えていくのが大事なんだろうなと思いました。 これからの勉強会はオンラインの時代ですねw

では以上です 運営の方々、本当にありがとうございました! また参加させて頂きますmm

"エンジニアリング組織論への招待"を読んだ

ずっと気になっていたのでGWを利用して読みましたので気になったこと、感じたことなどをまとめていきます。

エンジニアリングに必要な思考

書籍の冒頭からなるほどでした。

先が見えないという「不確実性」をどう扱うかを知ることができれば、「不安」は「競争力」に変わります。エンジニアリングに必要な思考は、まさにこの不確実性を力に変えるという点なのです。

僕がエンジニアとしてやっていることが本質的にはこのあたりに答えがあるんだろう、と思いました。

新しいサービス、プロダクトの開発、運用でもいいですが今まで僕がエンジニアとしてしてきたことはコードを書くだけではありません。 いわゆるPM(プロジェクトマネージャー)やPO(プロダクトオーナー)といわれる人がやるような役割をすることも状況によってはありました。

その時よく思うのが僕がやっているのはエンジニアの仕事なんだろうか、ということ。

そんなことはどうでもいいといえばいいのですが、自分がしていることを本質的に腹落ちしていることがけっこう大事だと思います。僕にとってはきっかけになる言葉でした。

ここで述べられているように「不確実性」と向き合うことがエンジニアリングだということであれば僕がしていること、してきたことはその「不確実性」と向き合うためにしていたことなんだな〜と思いました。

僕としてはすごくシンプルで腹落ちする言葉でした。

世界と日本のアジャイル開発普及率

僕自身が認定スクラムマスターなこともあってアジャイル開発の話は比較的よく知っている方だと思いますが、これは知らなくて驚きでした。

↓元ネタ www.ipa.go.jp

f:id:masayuki5160:20180502212542p:plain

日本では納品契約でITサービス業が大きなマーケットになっているためアジャイル開発が普及しないのは納得しているのですが他の国ではこんなに普及しているんだというのは知りませんでした。

この本ではスケジュール、マーケットという不安に向き合うための手段としてアジャイル開発の話を取り上げています。ウォーターフォール型(本の中では計画駆動型として表現してます)と比較しての話も非常にわかりやすく参考になりました。

が、それ以上に僕にはこのグラフが驚きでしたw

ちなみに僕が認定スクラムマスターの資格をとった話はQiitaにまとめてます。

qiita.com

まとめ

チーム、人にフォーカスを当てた本だとTeam Geekがけっこうすきでなんども読んでるのですがチーム、人、アジャイル開発にもフォーカスしつつ組織という観点からもエンジニアリングの話を伝えてくれる本はなかなかないんじゃないかと思いました。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

この本を読み返しつつ不確実性と向き合っていこうと思います。

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

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

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

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

事前メモ

  • 僕は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全般を丁寧に扱っている本はいまだにこれだけだな、というようなことになるのかと思います。

以上です。