銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

【読書まとめ32】3000万語の格差 ー 赤ちゃんの脳をつくる、親と保護者の話しかけ

こんにちは。

昨年第一子が生まれ、8ヶ月間の育休を取得して日々育児に奮闘しています。

今回は技術書からは離れ、子育て関連のこの本を読みました。

個人的になかなか衝撃的な内容も多く、子育て真っ只中の今のタイミングに読めて良かった本でした。

今後、育児中に何度も振り返れるように、特に覚えておきたいポイントに絞ってまとめます。

f:id:ysk_pro:20220402213013p:plain

ポイントのまとめ

最も重要だと思ったところ

子供の最終的な学業到達度により影響するのは、遺伝や社会経済的な状況等ではなく、生まれてから3歳の終わりまでに聞く言葉の量と質

思考や学びの基礎となる脳の神経細胞の繋がりは大部分が生後3年間に起こり、話しかけられた言葉によって脳の発達は引き起こされる

具体的にやるとよいこと

子どもの脳を育てるために保護者がするとよいことは「4つのT」

Turn In(チューン・イン)

子供が集中している対象に保護者も集中し、その対象について子供と一緒に話すこと

子供は自分が興味を感じた時だけ集中するため、子供が興味を持っていないものに無理やり集中させるのは難しい

保護者が物理的にも子供と同じ高さで話すことによって一層効果が上がる

Talk More

たくさん話すこと

特に、子供の発した言葉をふくらませることが、子供の言葉のスキルを伸ばすことを助ける(例:子供「抱っこ」→ 保護者「お父さんに抱っこして欲しいの?」)

「それ」等の代名詞は使わずに名前を使うことが、子供の語彙を増やす助けになる

Take Turns

会話のやりとりをすること

やりとりを行ったり来たりさせるために、保護者は子供が反応するまでちゃんと待つことが大切。子供が言葉を探す時間が長いと、つい保護者が言葉を先取りしてしまうが、そうするとと会話が終わりかねない

Turn Off

スマートフォン、テレビの電源を切ること

米国小児科学会は、2歳以下の子供にはテレビもテクノロジーも一切不要だと勧告している

子供の脳は、社会的な相互のやりとりがある環境でのみ学んでいく

 

※ 本書中では、Turn Off 以外を3つの T、+α の T として Turn Off を紹介していましたが、Turn Off も3つの T と同じくらい大切だと思ったので、この記事では4つの T としています

その他に気をつけるとよいこと

褒め方

その人を褒める(頭がいいね等)より、その過程を褒める(頑張ったね等)とよい

過程を褒めると、困難に直面した子供が挑戦する気になりやすい

本をたくさん読むこと

米国小児科学会が、保護者は生後すぐから子供に本を読むべきだと勧告を出している

生後数年間に保護者が本を読んだ子供は、幼稚園の段階で語彙がより豊かで、算数のスキルも高いという研究結果が複数ある

子供に何かして欲しいときの伝え方

子供に何かして欲しいとき、命令形ではなく理由も合わせて伝えると、何かをするときには理由があるのだと子供が理解する手助けとなる

ある行動の結果を考え、判断するという因果関係の学びにも繋がる

おわりに

ここまでお読みいただきありがとうございます。

人の頭の良さ(本書の中では学業到達度と言っています)は、遺伝が一番大きく影響するのかな、思っていたので、本書の内容は衝撃的でした。それとともに、子供の将来の命運の、少なくない部分を自分が握っていると思うと少しプレッシャーを感じました。

この記事に書いたことは本書に書かれていることのほんの一部なので(本書は270ページあります)、ご興味を持たれた方は是非本書を手に取ってみてください。

今日からできることとして、まずはスマホをターン・オフして、子供にチューン・インすることを意識的に増やしていきます。

 

育休関連の記事はこちらに書いていますのでご興味あれば合わせてご覧ください。

hokatool.com

エンジニア4年目の2021年振り返り

こんにちは。もう2021年が終わってしまいますね。

エンジニアになってから毎年 年末に振り返り記事を書いていおり、今年もやったことをまとめておこうと思います。

仕事の内容は詳細に書けないため、仕事以外の内容が中心です。

f:id:ysk_pro:20211230160154p:plain

アイキャッチ画像は、最近の読書している時の膝の上の状況です。かわいいが渋滞してます 😍

個人開発

趣味の個人開発に今年もじっくり取り組むことができ、新しいサービス2つリリースと、既存のサービスへの機能追加ができました 🎉

技術書えらび をリリース

楽天ブックスAmazonの両方のレビューを見ながら技術書を選べるサービスです。

どっちものレビューを見ながら選べたら便利だなーと思い、Vue.js の練習も兼ねて作ってみました。

構成は Vue.js × Rails API モードです。

ドメインを取得するときに、techbook(= 技術書)としたいところを teckbook と痛恨のタイポをしましたw(恥ずかしいけどもったいないのでそのまま使ってます..)

www.teckbook.net

HOKATOOL をリリース

現在地・住所・駅名から近い順に保育園を検索できるサービスです。

自分が保活をしていて、こんなサービスあったらいいなーと思ったものを妻と一緒に作りました。(エンジニアの妻との共同開発はこれで3つ目となり毎回楽しいです。)

僕は近隣の保育園を調べるために、区役所で保育園一覧の紙をもらって、1園ずつ Google Map で家からの距離を調べるということをやっていました。これがあればかなり楽ができると思います。

構成は Next.js × Rails API モードです。

妻が書いてくれたサービスの紹介記事がこちらです。

note.com

結構便利だと思うので、保活を控えてる方は是非是非覗いてみてください。

hokatool.com

Golf Medley の機能追加たくさん

Golf Medley は昨年リリースしたゴルフの口コミサイトです。開発の妻と僕、営業等のもう1人の3人で開発を進めています。

今年の多くの時間はこのサービスの機能追加にあてていて、多くの機能をリリースできたので紹介します。

オウンドメディアの作成

SEO 強化のためにオウンドメディアを作ろうということで、ヘッドレス CMS の Contentful を使って記事機能を作りました。

記事は営業メンバーがコツコツ書いてくれた結果40記事以上となり、かなりの流入があるので作ってよかったです。

golf-medley.com

練習場詳細ページのリニューアル

練習場詳細ページの情報を見やすくしました。

検索一覧ページのリニューアル

検索一覧ページについて改善を行い、行なったことを note にまとめました。

note.com

ゴルフ場、ゴルフレッスンの情報が加わった

元々はゴルフ練習場の口コミサイトだったのですが、ゴルフ場、ゴルフレッスンの情報を加え、ゴルフの総合口コミサイトに生まれ変わりました。

トップページのリニューアル

ゴルフ場、ゴルフレッスンの情報追加のタイミングで、トップページのリニューアルも行いました。

キャンペーンの開催

口コミ投稿で抽選5名様にゴルフボール1ダースプレゼントという初めてのキャンペーンを開催しました。

キャンペーン期間中に想定よりも多くの口コミをいただけ他ので、来年も新しいキャンペーンを実施予定です。

 

ゴルフをしている方は是非一度覗いてみてください!(口コミもいただけるとめちゃくちゃ喜びます)

golf-medley.com

仕事

Golang を書いた

前々からやりたかった Golang を仕事で書く機会を得ました。わーい

簡単な機能追加だったので 2ヶ月間程でしたが、基本的な書き方は把握できたので良かったです。

アジャイルを頑張った

チームでアジャイル開発を取り入れはじめ、定着させるために手探りで頑張りました。

知識をつけるためにいくつか本を読んでまとめ、まとめた内容を都度見返しながら進めました。

【読書まとめ25】スクラムブートキャンプ(SCRUM BOOT CAMP THE BOOK) - 銀行員からのRailsエンジニア

【読書まとめ28】アジャイルサムライ 達人開発者への道 - 銀行員からのRailsエンジニア

【読書まとめ30】いちばんやさしいアジャイル開発の教本 - 銀行員からのRailsエンジニア

小さなチームでのリーダー経験もできて有意義でした。

プライベート

子供の誕生・育休取得(8月〜来年4月)

8月に第一子が生まれ、8月から来年の4月まで約8ヶ月間育休を取得しています。

息子はとってもかわいく、息子と向き合う時間がしっかり取れる育休を取って良かったなあと思っています。(夜寝てくれないなど育児は過酷なので、育休取ってなかったらヤバかったな、、とも思ってます。)

育休を取った理由や、1ヶ月ごとの振り返りはこちらに書いています。(個人開発のところに書いた HOKATOOL のオウンドメディアです。)

hokatool.com

エヴァジョジョにハマった

ハマりました。アニメ・映画の一気見は最高でした。

おわりに

今年も個人開発を中心に色々活動できて楽しい1年でした。

来年は Golf Medley の勝負の年にする予定なので、今年以上に頑張っていきます。育児も妻と協力して頑張っていきます。

ご興味あれば、去年のブログも合わせてご覧ください。

ysk-pro.hatenablog.com

良いお年を。

 

【技術書まとめ31】現場で役立つシステム設計の原則

こんにちは。

今回は、DDD(ドメイン駆動設計)を学ぶために、勤めている会社で話題になっていた「現場で役立つシステム設計の原則」を読みました。

学ぶことが多く、今後も定期的に見返したいと思ったので、ポイントをまとめました。 

f:id:ysk_pro:20210707081045p:plain

設計の重要性

  • どこに何が書いてあるかを分かりやすくし、修正や拡張が楽なコードを生み出すこと
  • 変更が大変なプログラムの特徴 3点。どれも関心事の詰め込みすぎが原因
    • メソッドが長い
    • クラスが大きい
    • 引数が多い

 

設計の仕方の比較

2つの設計の仕方を比較します。

どちらの設計も、関心事の分離のために 3層アーキテクチャ を使うことを前提にしています。

  • プレゼンテーション層:UIなどの外部との入出力
  • アプリケーション層:業務機能のマクロな手順
  • データソース層:データベースとの入出力

 

データクラスを使う設計

  • 従来の手続き型の設計で基本とされていた、データを格納するデータクラスと、ロジックを記述する機能クラスに分ける設計
  • データクラスは getter/setterメソッドだけを持ち、データを使った判断/加工/計算のロジックは、機能クラスに記述する
  • 3層が同じデータクラスを参照できる結果、データクラスを使うロジックが3層のどこでも書けてしまい、重複しやすくなってしまう欠点があった

f:id:ysk_pro:20210706082357p:plain

イメージ図(本書のCHAPTER3 図3-2をベースに作成)

 

ドメインモデルを使う設計

  • ドメインモデルとは、業務で扱うデータと関連する業務ロジックを集めて整理したもの
    • ドメインとは、業務アプリケーションの対象領域を指す
  • ドメインモデルを使った設計では、ドメインモデルに集めた業務ロジックを3層が利用する形になる → 業務ロジックを書く場所が明確になり、重複を防げる

f:id:ysk_pro:20210706083139p:plain

イメージ図(本書のCHAPTER3 図3-4をベースに作成)
  • 業務ロジックを記載するのはドメインモデルのみとすることで、3層の記述は簡潔で分かりやすくなる。業務アプリケーションのコードが複雑になる理由は、業務ロジックの複雑さであるため
  • ドメインモデルは画面やデータベースの都合からは独立して、純粋に業務の観点から業務ロジックを整理できる → ドメインモデルを見れば、業務全体がどういう関心事から成り立っているかを理解できるようになる

 

ドメインモデル設計の仕方

ドメインモデルを使う設計の利点を理解した後は、実際にどのように設計を行うかを学びます

  • ドメインモデルの設計は、業務で使われる具体的な用語(概念)を手がかりに進める。その用語が、データとロジックをひとかたまりとしてプログラミング単位として使えるかを検証する
  • 部分に注目し、個々の部品を作り、それを組み合わせて段階的に全体を作っていくボトムアップのアプローチを取る
  • 部分に注目するが、全体像を意識しないと間違った方向へ進む危険がある。全体を俯瞰する道具として、以下の2つがある
    • パッケージ図
      • パッケージ間の依存関係を表現する
    • 業務フロー図
      • 業務の活動を時間軸に沿って図示したもの
      • 顧客/販売部門/出荷部門などの活動の主体ごとのレーンを並べ、その間の情報のやり取りを表現する
  • これらの図で全体を俯瞰したら、重要な部分を探し、重要な部分から作っていく
  • 業務を分析し、理解するために、業務の関心事をヒト/モノ/コトの3つに分類する手法がある
    • ヒト:人の意思/判断/行動についてのデータを持ち、そのデータを使った判断/加工/計算のロジックを持つ
    • モノ:ヒトが業務を遂行するときの関心の対象。これらの属性を表現するデータと、そのデータに対して業務的にどういう判断/加工/計算をしたいかをロジックとして持つ
    • コト:基本的にヒトの意思決定や行動の結果。業務アプリケーションの基本的な関心事は、コトを記録して、コトの発生を通知すること。コトに注目すると、全体の関係整理しやすい

 

ドメインモデル設計の注意点

  • 業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうと、そのクラス名は具体的には何も説明しておらず、業務を的確に捉えられない
  • オブジェクトとテーブルを自動的にマッピングするアプローチは、どちらかの設計のアプローチの制約を受け、うまくいかないことが多い。業務ロジックはオブジェクトで、事実の記録はテーブルで行うべき
  • 表示のためのロジックと業務ロジックを混在させない
    • 例1)一定金額を超え、かつ、注文後1日以上経過した注文を画面で強調表示する場合、画面表示のロジックに if 文を書いてしまうことがあるが、これは業務ルールなのでここに書かない方が良い
    • 例2)カンマや千円単位の表示なども、ドメインオブジェクトが持つべき加工ロジックの候補。データの文字列表現は、利用者の関心事であり、そういう関心事に関わる加工や判断のロジックはできるだけドメインオブジェクトに集約した方が変更が楽で安全になる

 

おわりに

ここまで読んでいただきありがとうございます。

これまで DDD(ドメイン駆動設計)の本を何冊か読んできましたが、個人的には本書が一番理解しやすかったです。本書をとっかかりにして、関連書籍を読んでいき、実践することで DDD への理解を深めていこうと思います。

本書の中では、図を多く使って丁寧に説明されていて理解しやすかったので、ご興味ある方は是非読んでみてください。 

 

【読書まとめ30】いちばんやさしいアジャイル開発の教本

勤務している会社でアジャイル開発を取り入れはじめ、開発・ビジネスサイドのメンバー合同で「いちばんやさしいアジャイル開発の教本」の輪読会を行いました。

学びが多く、これからアジャイル開発を実践していく中で、都度振り返れるようポイントをまとめました。

f:id:ysk_pro:20210611082845p:plain

なぜアジャイル開発が必要とされるのか

従来型の開発手法であるウォーターフォールの課題を整理し、その上でなぜアジャイルなのかを学びます

ウォーターフォールとは

一言で説明すると

開発をいくつかの工程に分けて順番に取り組んでいく手法

 

メリット

工程が明確に分かれているので、進捗確認、役割分担がしやすい

 

ソフトウェア開発の難しさ

開発したけど使われない問題

ソフトウェアの6割の機能は使われていないという調査結果がある

なぜそんなことが起こるのかというと、利用者が欲しいと思っているものが本当に必要かどうかは、利用してみるまでわからない

 

不確実性が高い

特にプロジェクト初期ほど不確実性が高く、見積もりから大きくブレやすい

プロジェクト初期では、見積もりの0.25倍〜4番の振れ幅があるとされている

 

ウォーターフォールの課題

  • 手戻りができない。ただ、実際にソフトウェアを触ってみないとわからないこともあるので、要件を最初に全て決めることは現実的ではない → 本当に必要なものからかけ離れたものが作り込まれてしまうリスクがある

  • 前工程で遅延が発生した場合に、後工程で辻褄あわせのために期間が圧縮されることがある。前述のように序盤の工程ほど不確実性は大きい → テストなどの工程が削減され、品質の低いソフトウェアになるリスクがある

 

ウォーターフォールアジャイル開発の違い

  • ウォーターフォール:各工程での成果物を完成品とみなし、後工程での手戻りが発生しないようになっている。各工程は1度ずつのみ行う
  • アジャイル開発:一定の期間(スプリント)ごとに動くソフトウェアが作られ、次のスプリントではそのソフトウェアから得られた気づき・フィードバックをもとに要件レベルから見直しが行われる。 スプリントの数だけ各工程を繰り返す

アジャイル開発だと少しずつ動くものを作るので、細かくフィードバックを受けることができ、本当に必要なものを作れる可能性が上がる

 

アジャイル開発の原則・コンセプト

アジャイル開発について理解するために、原則・コンセプトをまとめます

主な原則

  • 継続的かつ短い間隔でのリリース
  • ビジネスサイドと開発者の協働
  • 対話の重視
  • 絶え間のないカイゼン
  • ふりかえり
  • 動くソフトウェアの重視
  • 要求の変更はたとえ開発の後期であっても歓迎する

 

3つのコアコンセプト

  • チームアジャイル開発における機能するチームは、自己組織化されており、職能横断型なチーム
    • 自己組織化:自分たちで物事を決めて自律的に動けること
    • 職能横断型:複数の専門性を保有し、ソフトウェアを完成させる能力を有していること
  • インクリメンタル少しずつ作る
  • イテレーティブ反復的に作る。反復的に作ることで、経験・得られた学びに基づき次の開発ができる

 

具体的な手法・カイゼン

職場で実際に使えそうな手法や、カイゼンの例をまとめました

カイゼン」は、改善とは区別されています

  • カイゼン今あるものをより良いものしていくという、前向きで積極的な活動を意味する
  • 改善:発生している問題を取り除くという、カイゼンに比べると若干後向きなニュアンス

プロジェクト開始時に有効な手法

プロジェクト、プロダクト作りを始めるにあたり、目的や前提を把握することやチームメンバーへの理解を深めることは、状況に応じた判断を自分たちで行うための第一歩。このような共通理解を深める3つの方法がある

  • インセプションデッキ:プロジェクト、プロダクトレベルで目的や目標、前提や制約を理解する
  • ドラッガー風エクササイズ:チームメンバーレベルで考え方や得意なことを理解する
  • ワーキングアグリーメント:チーム活動レベルで協働のためのルールを理解する。何か問題が起きる都度、ルールの追加、変更を検討する

 

デイリースクラムカイゼン

  • 進捗遅れがあるにも関わらず「問題ありません」発言が目立ってきたら、「困っていること」から「モヤモヤと違和感を感じていること」に変えてみると良い。メンバーが問題を共有するハードルを下げることができる
  • ファイブフィンガーで進捗状況を発言しやすくできる。スプリントゴールの達成度合いは5本の指で表現するといくつぐらいか、と数字の大きさで表明してもらうと、問題ありませんと発言していたメンバーも数字の理由を聞くことで状況を発言しやすくなる
  • 個人レベルの失敗を共有することは、チームで成果を出すための成長と前進のきっかけ。デイリースクラムで共有される問題は、他のメンバーが同じ失敗をしないための学びのきっかけであることを強調するためにも、マネージャーなどから積極的に行っていく

 

振り返りのカイゼン

  • 暗くなるようの反省会のようになってしまったら、良いことをさらに良くするための振り返り方法を試してみる
  • 「YWT」やったこと(Y)、わかったこと(W)、次にやること(Y)を意味し、わかったことという気づきをベースに、次にやることを明確にできる。気付いた学びを次に活かすという流れが成長を促進する
  • 「Fun! Done! Learn!」楽しかったこと(Fun!)、やったこと(Done!)、学んだこと(Learn!)を意味し、これら3つの円を重ね合わせて、実施したことがやっただけなのか、楽しさも同居していたのか、さらには学びもあったのかを振り返る。振り返りながら楽しさをイメージするため、記憶に残りやすい成功体験の学びになる
  • KPTカイゼン策に、YWTは気づきに、Fun! Done! Learn! は楽しかった学びに関心のフォーカスが当たる。3種類の振り返りを定期的に変えたり、状況によって使い分けることで形骸化を打破できる
  • こぼれ球を拾う、手こずっているメンバーを手伝うなどの動きはチームワークを発揮するために重要だが、フィードバックがなければ継続する気力がなくなっていく。チームワークを支える行動にフィードバックを与えるには、感謝を見える化するプラクティスが有効KPTに感謝という軸を加え、Tryを決めた後に最後にチームメンバーへの感謝を示すアクティビティをすると良い。チーム内に互いを尊重し称え合う文化も醸成されていく

 

プロセスのカイゼン

  • プロセスの無駄を見える化するためには、バリューストリームマッピングが有効。開発が始まってからユーザーに届くまでのプロセスを全て洗い出すことで、待ち時間が多いところや、手戻りが発生しやすい箇所が見つけられる

 

その他覚えておきたいこと

  • DX(デジタルトランスフォーメーション)とは、ITを道具として活用するだけでなく、ITによりビジネスや生活を変革させていくこと。これまでのITとビジネスの関係は、もともと人間が行なっていたことをITで置き換えることだが、DXが実現するのはITを前提とした新しいプロセスやビジネス
    • 例:音楽ストリーミングサービス
  • 仮説を検証するための、価値を提供できる実用的で最小限のプロダクトのことをMVP(Minimum Viable Product、Viable: 実行可能な)という
  • モブプロなどの1人でできることを全員でやったら時間が無駄なのではないか?への回答
    • 隙間時間があって時間を無駄にしていることを懸念するよりも、価値が早く顧客の手に届く流れの効率を大切にしている人がフル稼働することよりも、開発された成果物を重視している。リリースすることで顧客が利用可能になり、使われて初めて価値が生まれる
  • プロダクトバックログの開発可能チェックリスト
    • スプリント内で開発着手できる具体的な情報がある
    • 顧客に価値がある根拠や仮説がある
    • 優先順位で並べ替えられている
    • スプリントで開発可能な大きさに分解されている
    • 見積もられている
    • テスト可能な受け入れ条件がある

 

おわりに

ここまでお読みいただきありがとうございます。

本書の中では図がたくさん使われており、アジャイル開発の考え方がとても理解しやすかったの、ご興味ある方は是非読んでみてください。

 

以下の関連記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

【読書まとめ29】学びを結果に変えるアウトプット大全

久々に技術書以外も読みたいな、と思い「学びを結果に変えるアウトプット大全」を読みました。
 
この本に書かれていた次のことがいいなと思いました。
勉強/読書前に何を学びたいかを自分に問いかけると良い。その内容に注意が向くようになり、関連する情報が出た時に集中力が高まる。

(読む前)この本で学びたいこと

① アウトプットの効果
② 今日から始められるアウトプットの仕方
 
アウトプットするのが良いというのはなんとなく体感としてありましたが、具体的にどんな良いことがあるのか知りたかったです。
また、息をするようにアウトプットができるタイプではないので、気軽に今日から始めれられるアウトプットの方法が知りたいと思いました。 
 

(読んだ後)この本で学べたこと

① アウトプットの効果

学んだことが定着しやすくなる
脳はインプットしてもその情報を何度も使わないとすぐ忘れてしまう。脳に入力された情報は海馬に2~4週間の間、仮保存される。海馬への仮保存中にその情報が何度も使われると、脳はその情報を重要と判断して側頭葉の長期記憶に移動する。目安として2週間で3回以上アウトプットすると、長期記憶として残りやすくなる
参考書を読むだけで問題集を解かなかったり、技術書を読むだけで実際に手を動かさないとすぐ忘れてしまうという体感と一致し、納得感がありました。
ただ、1度アウトプットすれば良いものでもなく、2週間に3回以上必要というのは思っていたよりも多く、意識してアウトプットしなければ到達できなさそうだな、と思いました。
 

② 今日から始められるアウトプットの仕方

日記を書く

日記は手軽なアウトプットトレーニング。ポジティブ、楽しい出来事を中心に書くことで、日常から楽しいことを発見する能力が高まる。1日10分間日記を書くと幸せになるという研究結果もある

過去日記を書いていた時期はあるのですがやめてしまっていたので、この本を読んで再開してみました。
特に何もないような日でも日記を書くと毎日楽しいことがあると実感でき、この本の通りポジティブになれている気がします。
 
会社で続けている技術書の輪読会を継続する
人に教えることを前提に勉強するだけで記憶力がアップする。教えることで、自分の理解度や不十分な点が明確に見えてくる
 
説明することによって記憶に残りやすくなる。なぜなら、説明することによって意味記憶からエピソード記憶に変換されるため
意味記憶apple=りんごのように関連性の薄い組み合わせ。記憶に残りにくい
エピソード記憶:過去にあった出来事や体験、ストーリーとしての記憶。記憶に残りやすい
会社のメンバー数人で、技術書を1章ずつ順番に説明する輪読会を1年くらい続けています。説明したり議論したりすることで理解が深まったり、記憶に残りやすくなる実感があったので納得感がありました。
 
本を読んだらブログに残す
本を読んでも気づきを書き留めないと自己成長につながらない。現実を変えるためには行動を変える必要があるため、TODOリストを作成すると良い
これまでは特にいいなと思った本・技術書のみをブログに残していましたが、基本ブログを書く前提で読もうと思います。
この本を読んだ上での僕のTODOは、「② 今日から始められるアウトプットの仕方」の3つと「読書前に学びたいことを決めるこの読書法」の計4つを継続し、習慣にすることです。
 

その他覚えておきたいことのメモ

  • 理想的な費やす時間の比は インプット:アウトプット = 3:7
  • 文章を速く書く方法
    • 時間を決めて書く:締め切りを決めることで集中して一気に書くことができる
    • 先に構成を決める
  • ぼーっとしてる状態がひらめきやすい。ぼーっとしている時、脳内では通常の活動時の15倍ものエネルギーが消費されている。空いた時間はスマホで埋めるのではなく、意識的に何も考えない時間を取ると良い

 

おわりに

ここまでお読みいただきありがとうございます。

これまで何となく本を読んで何となくメモを残したりすることが多かったですが、この本を読んで「明確な目的を持って本を読み、行動を変えるための読書法」に切り替えるきっかけが得られたと思います。

ここに書いたこと以外にも多くの内容が詰まっており、刺さる部分は人によって違うと思うので気になった方は是非読んでみてください。

学びを結果に変えるアウトプット大全

学びを結果に変えるアウトプット大全

 

 

【読書まとめ28】アジャイルサムライ 達人開発者への道

勤務している会社のPJでアジャイル開発を取り入れはじめました。

ただ雰囲気でやっている部分も多く、より効果的にアジャイルを活用するため、まずは体系的に学びたいと思いこの本を読みました。

これから実践していく際にこの本に立ち返りやすいよう、ポイントをまとめました。

f:id:ysk_pro:20210228104556p:plain

 

プロジェクト全般

  • ソフトウェア開発の3つの真実
    • プロジェクトの開始時点に全ての要求を集めることはできない
    • 集めたところで、要求はどれも必ずといっていいほど変わる
    • やるべきことはいつでも、与えられた時間と資金よりも多い
  • ソフトウェアの64%の機能は、ほとんどあるいは全く使われていない。このことからも、本当に重要なことだけに集中すべき
  • アジャイル開発の原則として、ビジネス側の人と開発者は、プロジェクトを通じて日々一緒に働かなければいけない

プロジェクト開始時

  • チームメンバーが誰もいないところで合意したことを前提にすると、プロジェクトはダメになる。プロジェクトの開始時点で関係者の認識が揃っていないのは当然なので、プロジェクト開始前に関係者全員でプロジェクトについて話し合うべき。そんな時にインセプションデッキが有効
  • インセプションデッキについて
    • プロジェクトを開始する前に聞いておかなければならない10個の質問で構成されている
    • プロジェクトを核心まで煮詰めて抽出した共通理解を、開発チームだけでなくプロジェクト関係者全員へ手軽に伝えるためのツール
    • 仕事場の壁に貼り出しておき、何を作ろうとしているのか、そしてそれはなぜなのかを時々眺めて思い出すとよい
    • プロジェクトの真のゴールは、よくよく話し合い、議論を重ねて理解を深めることでしか浮かび上がってこない
    • プロジェクトの基本的な考え方やスコープ、存在意義が変化してしまったら、全員でもう一度インセプションデッキを見直して、チームの向いている先と、プロジェクトへの理解が揃っていることを確認すべき

プロジェクト運営

  • 良いユーザーストーリーの6つの要素(英語の頭文字をとって INVEST と呼ばれる)
    • 独立している(Independent):ストーリーが互いに独立していると、必要に応じてスコープを柔軟に調整しやすい
    • 交渉の余地がある(Negotiable):予算などに応じて実現方法を選択することができる
    • 価値がある(Valuable):顧客が対価を払っていいと思えるもの
    • 見積もれる(Estimatable)
    • テストできる(Testable):完了の基準が明確になる
  • ユーザーストーリーのテンプレート
    • 〈ユーザーの種類〉として、〈達成したいゴール〉をしたい。なぜなら〈理由〉だからだ
    • テンプレートを使うことで、誰が、何を、なぜ、という重要な疑問を明確にできる
  • ベロシティはチームとしての生産性を計測する。個人の生産性を測るのは良くない。個人の生産性を測ると、協調しようとか知見を共有しようという気持ちがなくなり、各人が何としても自分自身の生産性を確保しようと躍起になってしまう
  • プロジェクトの完了時期の見通しを立てるにはバーンダウンチャートが便利。ただ、バーンダウンチャートだと途中でのストーリー追加がわかりづらいので、途中でのストーリー追加をわかりやすくしたければバーンアップチャートが便利

開発関連

  • アジャイルプログラマが当然のように実践していること
    • テストをたくさん書く。設計のためにテストを活用することも多い
    • プロジェクトの進行中にも、アーキテクチャの設計と改善に継続的にり組む
    • コードベースをいつでもリリースできる状態にしておく
  • バグを見つけたら、修正する前にバグが原因で失敗するユニットテストを書く。こうすることで、同じバグが2度と現れないことを保証できる
  • TDD(テスト駆動開発):以下の短いサイクルを繰り返しながら少しずつソフトウェアを設計していく手法
    • レッド:必要なコードが既にあると考えて、失敗するユニットテストを書く。設計についてしっかり考え、コードの意図をテストで示す
    • グリーン:とにかくテストに成功するコードを書く

おわりに

ここまでお読みいただきありがとうございます。

本書は翻訳本に関わらず読みやすく、アジャイル開発の考え方を理解するのに最適だと思ったので、ご興味ある方は是非読んでみてください。

 本書で学んだことを、明日から1つずつ業務で実践していこうと思います。

以下の記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

 

エンジニア3年目の2020年振り返り

こんにちは。2020年ももう終わってしまいますね。
気づけば、エンジニアになって2年半が経っていました。

去年と一昨年も年末に振り返り記事を書いているので、今年もやってきたことをまとめておこうと思います。

去年の記事:エンジニア2年目の2019年振り返り - 銀行員からのRailsエンジニア
一昨年の記事:エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り - 銀行員からのRailsエンジニア

仕事のことはあまり詳細に書けないので、主に仕事以外でやってきたことを書いていきます。

f:id:ysk_pro:20201231081124p:plain

振り返り記事なので、アイキャッチは振り返ってるうちの猫です。かわいい 😻

個人開発

2つサービスをリリースできました 🎉

楽々ゴルフ

移動時間で絞り込めるゴルフ場検索サービスです。

今年のお正月(約1年前)に、妻と2人で作りました。

「既存のゴルフ場検索サービスでは、自宅からの車での移動時間で絞り込めない」という僕の思っていた課題を解決できて嬉しかったです。

フロントエンドにはReactを初めて使いましたが、妻に手取り足取り教えてもらったのでだいぶ理解できるようになりました。

バックエンドはAWS Lambda(言語はRuby)、API Gateway、DynamoDBでサーバレスの構成にしてみました。

ysk-pro.hatenablog.com

Golf Medley

ゴルフ練習場の口コミサイトです 🏌️‍♂️

「楽々ゴルフを見たのですがこんなもの一緒に作らないですか」というTwitterDMをいただいたのがきっかけで生まれたサービスです。楽々ゴルフを作って公開したことで、このサービスに繋がりました。

現在はゴルフ練習場の口コミ機能のみですが、ゆくゆくはゴルフにまつわる総合サイトにするため、様々な機能を検討・実装中です。これまで僕はサービスを作って終わりというのが多く、継続的に開発している個人開発のサービスは初めてなので、少しずつ良いものにしていきたいです。

開発は妻と僕、機能の検討やデータ入力等は声をかけていただいた方が行う、3人チームで進めています。

技術的にはフロントエンドにNext.js、Typescript、認証にAuth0(JWTトークン認証)、バックエンドにRailsという構成で、Rails以外ほとんど触ったことのない個人的に攻めた構成にしました。

元々フロントエンドはReact SPAで作り始めたのですが、SNSシェアされた時に展開される情報を動的に変えられないことが辛く、SSRができるNext.jsに切り替えました。ページごとにSSR, SSGを切り替えられたり、SSGでも(ほぼ)動的なサイトを実現できたりとNext.jsが便利すぎて驚きました。

golf-medley.com

AtCoder

2019年にハマった競技プログラミングを継続していました。
今年の前半は、ほぼ毎週オンラインでのコンテストに出場していました。

基礎的なアルゴリズムは習得できたと思います。

念願だった水色になってからレートが停滞して、徐々にやらなくなってしまいました。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

CTF

CTFとはセキュリティ系のコンテストで、Web、暗号化、ネットワーク幅広い分野が対象です。詳細を知りたい方はこちらがとてもわかりやすいです。
CTF(Capture The Flag)とは?概要から基本ルール、メリットデメリットまで徹底解説

AtCoderと入れ替わりで始めてみました。

主にWeb分野の過去問に取り組んでおり、SQLインジェクションなどで攻撃するのが楽しいですw(そういう問題なので攻撃OKです)

デザインパターンの勉強

2019年から始めたデザインパターンの勉強を継続していました

Rubyによるデザインパターン を読んで、紹介されている16のパターンを1パターンずつオリジナルのサンプルコードと共にブログにまとめました

かなり時間がかかりましたが、デザインパターンをざっくり理解することができ、コードの良し悪しが少しずつ分かるようになった気がします。
まとめた自分のブログを見ながらコードを書くことが多くなりました。

ysk-pro.hatenablog.com

仕事

APIを一から作ってパフォーマンスの問題に苦しんだり、スクラム難しいなーてなったり、Kubernetesを触ったり、大きめの障害を起こしてヘコんだり、新しいサービスの技術選定・設計をし始めたりしてました。

現職で2年半以上経ちましたが、メンバーに恵まれているのと、次々に初めて経験する難しい課題が現れるので全く飽きずに楽しめています。

おまけ(プライベート編)

3月からフルリモートになり家の環境整えました

よくあるデスク環境紹介ブログを書いてみました。

ysk-pro.hatenablog.com

広い家に引越して、猫を飼い始めました

リモートワークになり、会社の近くに住む意味がなくなったので、広くて猫飼育可の物件に引っ越して猫を飼い始めました。
めっちゃかわいいです...!

ジムは解約し、家トレを毎日継続してます

コロナの影響でジムに行きづらくなったので、家でトレーニングできる環境を整えました。

ジムは2日に1回行く程度でしたが、家だとすぐに取りかかれるのが楽で毎日筋トレをする習慣がつきました。

マンガをたくさん読みました

リモートワークになって自由な時間が増えたのもあり、マンガをたくさん読みました。

技術書もそうですが、妻と2人で読めば実質半額でお得です。

僕が今年読み始めたマンガでの個人的なTOP3は、1位:ワールドトリガー、2位:七つの大罪、3位:呪術廻戦 です。

(今Amazonで調べてたらワールドトリガーが2021/1/11まで1巻〜9巻 Kindle版無料で読めるらしいすごい)

妻とゴルフレッスン通い始め、夫婦でゴルフ旅行に何度か行きました

夫婦でゴルフ旅行という、ゴルフを始めた頃の夢が叶いました。最高です。

おわりに

ここまで読んでいただきありがとうございます。

今年も色々取り組めていい年でした。

来年は Golf Medley を成長させつつ、興味の赴くままに新しいことに色々チャレンジする1年にしたいです。

ご興味あれば、去年・一昨年のブログも合わせてご覧ください。

ysk-pro.hatenablog.com 

ysk-pro.hatenablog.com

良いお年を!