育休中に勉強できるか新卒3年目のエンジニアが検証して得た結論
簡単に結論
- 育休中は技術の勉強はしづらいので、ビジネス書を読むのがおすすめ
- プログラミング関連の知識はそんなに忘れないので心配しなくていい
想定読者
- 育休を取りたいと思っている男性エンジニア
- 育休中に技術の勉強ができるのか気になっている人
記事の背景
- 新卒3年目の男性エンジニアが半年育休をとった
- 誕生直後から育休開始し、妻の産休が産後2ヶ月で終わってから日中は一人で育児をした
- 近くに親戚はいないので両親だけで育児した
育休でプログラミングの知識を忘れるか心配だった
メガベンチャーで新卒エンジニアとして入社してちょうど2年働いたタイミングで子供ができたので、育休を取得しました。
育休を取るにあたり以下のような心配事があったので、同じような心配事を抱えてる人の参考になればと思い記事を書くことにしました。
- プログラミングの知識を忘れてブランクができてしまうのではないか？
- 育休中に少しでも勉強してキャリア面でのマイナスを少なくすることはできるのか？
育休中は技術の勉強は難しいのでビジネス書の読書中心だった
育休中は技術の勉強はあまりできませんでした。しかし赤ちゃんが寝ている間にビジネス書を読んだりすることは出来ました。
技術の勉強ができなかった理由は以下になります。
- 技術書は読むだけでなく実際に手を動かさないと理解しづらい
- まとまった勉強時間が必要だが育児をしていると、30分以下程度の細切れの時間しか勉強できない
このような理由から技術書を読んで勉強することは出来ませんでした。
一方で赤ちゃんを膝で寝かせていて、パソコンはさわれないけど本は読めるという状況が頻繁にあったので、技術書でなくビジネス書を中心に勉強しました。
育休中は普段読まないビジネス書を読むきっかけになった
エンジニアとして仕事をしていると目の前のプロジェクトで使用している技術へのキャッチアップが必要になり、技術書しか読まない状況になりがちだと思います。
僕は普段ほとんどビジネス書を読むことができていませんでした。しかし育休中は技術書が読みづらかったので自然とビジネス書を読むきっかけを得ることができました。
エンジニアとして仕事するためには具体的な技術以外にも大切なことがたくさんあります。Googleのエンジニアが執筆したSearch Inside Yourselfの中にも書かれていました。
テクノロジー部門で業績が月並みな人から優れた人を際立たせている上位六つの能力は以下の順だ。
- 強い達成意欲と高い達成基準
- 影響を与える能力
- 抽象的思考力
- 分析能力
- 難題を引き受けるイニシアティブ
- 自信
この六つのうち、純粋に知的な能力はふたつ（抽象的思考力と分析能力）だけだ。上位のふたつを含め、残る四つは情動的な能力にほかならない。
チャディー・メン・タン,一般社団法人マインドフルリーダーシップインスティテュート. サーチ・インサイド・ユアセルフ 仕事と人生を飛躍させるグーグルのマインドフルネス実践法 (Japanese Edition) (p. 39). Kindle Edition.
つまり単純に技術力だけに勉強時間を投下するのは仕事の成果という面で見ると投資対効果がどこかで頭打ちになってしまうので、時々はビジネス書を読んでコミュニケーションやマネジメントなどについても勉強する必要があるということです。
普段技術書しか読まなかったのですが、育休をきっかけにビジネス書も読む習慣がついたのはとてもよかったと思います。
もう一度まとめると、育休中は技術の勉強をするのが難しいけど、手を動かす必要が少ないビジネス書は読めるからインプットをすることはできるという感じです。
プログラミング関連の知識はそもそも普段から忘れている
育休前は「プログラミングの知識をほとんど忘れてしまったらどうしよう」と考えていました。 しかしよく考えてみると、普段から結構忘れていて頻繁にググっているので影響が少ないと感じました。
1、2年で前に使っていた言語のことをすっかり忘れてしまってチュートリアルからやり直さなきゃいけないって状況はほぼありえないので、プログラミング関連の知識を忘れてしまうかもと言う心配は杞憂だと思いました。
結論: 1年程度の休業で知識が後退することはない
育休を取るにあたって知識面での後退やインプット量の低下を恐れていましたが杞憂でした。
- 育休中は技術の勉強はしづらいので、ビジネス書を読むのがおすすめ
- プログラミング関連の知識はそんなに忘れないので心配しなくていい
完全に経済的な観点に立つと育休を取るメリットはありませんが、妊娠出産と既に大変な苦労をして、体力的にも精神的にもHPが少なくなっている妻の負担を軽減するには育休を取るのが効果的だと感じました。
この記事が育休を考えているエンジニアの方の参考になれば幸いです！
GoFのデザインパターンが今でも有効だと感じた2つのポイントと1つの注意点
簡単に結論
デザインパターンを勉強してみて、以下のような点で有効だと感じました。
- 自分では思いつくことが難しい設計のアイデアを知ることができる
- ライブラリを自分で作る時にはデザインパターンを使用する可能性が高い
想定読者
- デザインパターンに興味があるが、ネット上で「実際役に立たない」的な意見を見て、勉強しようか悩んでる人
記事の背景
僕は新卒でエンジニアとして2年間働いて現在育休をとっています。
育休中は手を動かす時間が取れないので、具体的な技術よりも抽象的な技術を勉強したいと思い、空き時間に設計に関する知識をつけることにしました。
DDDとかクリーンアーキテクチャについて勉強した後に、「じゃあ小さい機能単位で書くようなコードはどう綺麗にすればいいんだろう？」と考えてデザインパターンを勉強することにしました。
デザインパターンが設計力向上に有効か分からなかった
しかしいざ、デザインパターンについて調べてみると、実際は役に立たないという意見がちらほらみられました。
- フレームワークでの開発が主流なのでデザインパターンを使うような場面は少ない
- デザインパターンは難しいので使うと逆に分かりにくくなる
というのが主な意見なようでした。
せっかく勉強するなら役に立つものを勉強したいと思っていたので同じように悩んでる人に向けて、実際勉強してみてどうだったのか解説します。
デザインパターンを習得するメリット
学習教材はこちらを使用して、Golangで実装しました。 実際に学習してみて感じたメリットをまとめます。
自力では発想しづらいアイデアを知れる
デザインパターンを学習することで、何をクラスにするか、何をinterfaceにして交換可能にしておくかといった新たな視点を得ることができました。そしてそれらは自力で思いつくのは難しかったと思っています。
例えば、以下のような考え方です。
- Composite Patternではファイル(もの)とディレクトリ(いれもの)を同一視する
- State Patternでは具体的な"もの"ではなく、"状態"をクラスとして考える
教えられると理解するのは難しくないのですが、全くの0から自分でこのアイデアを考えつける気はしませんでした。
こういったアイデア一度頭の中に入れておけば、それらを適応できる場面に遭遇した場合に、完全な自力でひらめくことはできないけど、パターンを適用できるという絶大なメリットがあります。
自分でライブラリを作るときに役立つ
デザインパターンの有用性に反対する意見としてよく見られるのが
「フレームワークを使って開発するのが主流なのでそんなに複雑なプログラムは書かないからデザインパターンは役に立たない」
という意見です。
しかし逆を言えば自分でフレームワークやライブラリを作成するときはデザインパターンの考え方を知っておくべきだと思います。
フレームワークを作る機会はほとんどの人にとってあまりないと思いますが、小さいライブラリを業務で書く可能性は高いと思うので、デザインパターンを知っておくことは重要だと感じました。
GoFのデザインパターンが役立ちそうにないと感じたポイント
理解が困難で複雑なパターンは現場で使えなさそう
GoFのデザインパターンの中には複雑なパターンがあり、それを現場で使うのは控えたほうが良さそうと思いました。
解説本を読みながらでも理解が難しいと感じたパターンがいくつかあったので、デザインパターンを知らない人がいきなり業務中にそれを見たら、かなり混乱します。
Template Method PatternとかBuilder Patternは初見でも分かると思いましたが、Abstract FactoryやVisitorみたいな難しいパターンを実際に使うのは、かなり慎重になったほうがいいと感じました。
デザインパターンを学習してみてのまとめ
こんな人におすすめ
- 長期的に設計力を向上させたい人
- すぐに使える！という感じではないため
- 自力で閃くことが難しいアイデアを知ることができる
- ライブラリを自分で作る可能性が高い人
- 抽象的なロジックを書く必要性がありデザインパターンが役に立つ可能性が高いから
学習に使った教材
- 増補改訂版 Java言語で学ぶデザインパターン入門
- https://github.com/monochromegane/go_design_pattern
- Golangでの実装例が載っていてとても助かりました
TDDで開発効率が上がらないと感じた3つの理由
結論
- TDDを学んで、サンプルコードを実装してみた。
- TDDは自分の開発スタイルにあっておらず、TDDによって開発効率が上がらないと感じた
- TDDが目指している効能は、テストを初めに書かなくても実現できるのでTDDを自分の開発スタイルに取り入れないことにした
記事の背景
最近、テスト駆動開発を読んでTDDについて勉強しました。
自分の開発効率や設計スキルの向上に活かせないかなと期待していたのですが、この記事で解説する理由で、自分には合わないなと感じました。
※ TDD自体や、それを使っている人を批判する意図はないです。
TDDが目指しているもの
TDD再考 (3) – TDDが解決しようとした問題は何か？ – ゆびてく
TDDが目指しているものはこちらの記事にまとまっていますが、より少なくまとめるとすると、テストを先に書くことで
- テスタブルな、いい設計のコードを書く
- 小さなステップで進むことで、開発時の心理的余裕を確保したり、開発生産性を向上させる
ことが重要な部分かと思います。
TDDは開発効率を上げないと思った理由
自分の開発スタイルの中で、TDDが目指すメリットを本当に享受することができるのかを検証するために本に書かれていたサンプル問題をGolangで実装しながら試してみました。
しかし結果としては、TDDの手法は自分には合わないということがわかりました。
理由1: テストの修正が頻繁に発生するから
設計を考えながら実装する場合、実装途中でいい設計に気づき何度も実装を修正する必要があります。TDDで開発している場合、実装が変更されるとテストコードも修正する必要が発生するので、修正コストが余計にかかってしまうと感じました。
確かにテストを先に書くことでテスタビリティが担保され、良い設計になりやすいとは思いましたが、テスタビリティ以外の理由で実装を途中変更する必要に迫られ、修正をすることが頻繁にあることに気づきました。 そのような修正が発生するたびに、少ないながらもテストコードの修正が必要になることが自分にとってはストレスになっていました。
理由2: 重要でないテストが量産されるから
TDDで開発する場合、より網羅的にテストを書くことになります。しかし一方で、バグが入る可能性がほとんどない関数などに対してもテストを書くことになり、重要でない部分に対するテストが多くなってしまう傾向にあると思いました。
テストを最後に書くようにすると、重要でない部分のテストはスキップしたり、他のテストによってテスト範囲が重なることで担保されていたりするので、テストのボリュームが少なくなります。これによってテストファイルが小さくなり、メンテナンスコストも下がると感じました。
理由3: 小さなステップで進むことはテストを使わなくてもできるから
TDDでは小さいステップを踏むことで
- 過剰な設計
- 進捗が生まれやすいため心理的余裕ができる
ことが良いなと思っていました。
しかし小さいステップを踏むことは別にテストを書かなくてもできます。
僕の場合は、
- フローチャート
- クラス図
- コメントだけで処理の流れを書く
などして、小さいステップを踏みながら全体を設計してから実装に入るようにしています。
このようにTDDでテストをわざわざ書かなくても同じようなメリットを享受できるため、わざわざTDDを使う必要はないなと感じるようになりました。
手戻りを少なくして開発効率を上げるためにやっている2つのこと
簡単に結論
- 開発効率を下げる1番の要因は手戻り
- 実装に入る前に実装方針を検討することで手戻りを少なくできる
記事の背景
先日こんな記事を読んで、自分も気をつけていることをまとめようと思ったのがきっかけです。
困っていたこと
DeNAに新卒として入社したときに研修の講師から「すぐにコードを書くな」とよく言われました。
- どんなクラス設計にするのか
- 要件に見落としているポイントはないか
を深く検討した上でコードを書き始めないとダメだという意味でした。
実際に僕も新卒入りたての頃はとにかく手を動かし始めるというアンチパターンを踏んでしまっていました。
最も開発効率を下げる要因とは何か
開発効率を最も下げる要因は、手戻りだと思っています。
これはプログラミング以外の他の業務でも言えることですが、僕は以下のようなことをよくやってしまっていました。
- 成果物が求められていたものと微妙に違っていて作り直さなくちゃいけない
- 途中までプレゼンスライドを作ったけど、なんか微妙だから1から作り直す羽目になる
- コーディングの途中で実装が汚いことに気づいて、最初から実装し直す
ビジネス書とかに結構書いてある「安心したくて、手をとりあえず動かしてしまう」というアンチパターンだと思います。
手戻りを少なくして開発効率を上げるためにやっていること
プログラミングをする上で手戻りをなくすためには以下のようなことを気をつけています。 (ここで述べているのは個人レベルでの話です。チームとか組織まで話を広げるともっとたくさん出てくるので話題の範囲を絞ります。)
フローチャート
少し大きめの機能を実装するときは必ずフローチャートを作成してから実装に取り掛かるようにしています。
これによって実装上以下のようなメリットがあります。
- 関連するシステム的な概念やビジネスロジックを簡単に整理できる
- 実装前に大まかな実装方針を検討することができる
また個人的な開発効率の範囲では余談ですが、フローチャートを作ると以下のメリットもあります。
- ドキュメントとして残せる
- コードレビュー時に実装内容を理解してもらいやすい
コメントだけで実装する
フローチャートを描いて、いざ実装！とやりたくなるんですが、この段階でもまだ実装には手をつけません。
実際にコードを書く段階になって以下のようなことに気づくからです。
- 実装しながら見落としていた詳細に気づいてフローチャートが間違っていること
- 既存の実装の制約上、やりたいことができないこと
- コードを書きながらもっといい実装があることに気づく
実装してから初めて気づくことは思ったよりもたくさんあるのですが、実際にコードを書いてしまっているとせっかく書いたコードが無駄になってしまいます。
そこで僕はコメントだけでコードの実装を考えるということをよくしています。
def calculate_amount # ここで不正チェックする # 全部終わったらメールを送信する end def send_finish_email # 完了を通知する # メールの受信拒否設定をチェックする end
このようにメソッドだけ作って中の処理をコメントで一旦書いていきます。
こうすることで、実装して初めて気づく詳細を知ることができつつ、手戻りを最小限に抑えることができるようになりました。
その他でやっていること
手戻りを最小にするためにやっていることではないですが、その他にやっていることを最後に紹介します
スニペットの保存
こちらの記事で詳しく書いていますが、何度も同じことを調べたり、よく使うコードはメモしておいた方が効率がいいのでScrapboxに保存しています。
エンジニアが自分用の小さな技術メモを残すべき理由とScrapboxの紹介
簡単に結論
- 何度も調べる手間を減らすために小さな技術メモを残すのは大事
- Scrapboxなら気軽に使えるようなUI/UXだからおすすめ
記事の背景
エンジニアとして働いていると、実際にコードを書いている時間よりも調査の時間が長いと思います。
新卒でエンジニアとして働き始めたときに、上司から「小さな技術メモを残す習慣をつけろ」と言われました。
いろんなツールを使って小さな技術メモをとってきたのですが、最終的にはScrapboxが一番しっくりきたので紹介したいと思い記事を書きました。
小さな技術メモとは
僕がこの記事で「小さな技術メモ」と言っているメモのイメージはこんな感じのメモです。
内容のジャンルとしては主に以下のようなものです。
なぜ小さな技術メモを残すがの大事なのか
働き初めの頃は小さな技術メモをあまり残す習慣がありませんでした。しかし以下のような問題が発生しました。
- 半年前くらいに同じようなエラーメッセージが出たんだけど全く思い出せない
- どこかに技術仕様のわかりやすいブログ記事があったんだけど思い出せない。
- 何回も同じようなコードを書くときに、毎回ググって5分くらいかかる
1個1個の時間は大したことないのですが、チリツモで時間が無駄になっていると感じていました。
Scrapboxに小さな技術メモを残すことで解決した
いろいろなツールを試した結果Scrapboxが一番使いやすく感じました。
Scraoboxのメリット
- フォルダの概念がないので、新しくメモを作るときに整理する必要がない
- 後からメモ同士のリンクを簡単に作って知識を整理できる
- 全体的に動作が軽いので快適に使える
このような感じで完全に自分だけのメモなので雑に書くことができます
Scrapboxを小さな技術メモに使うときに注意すること
Scrapboxはプライベートプロジェクトを作ることができます。
しかし
- 簡単にパブリックにすることもできてしまう
- あくまで個人的なメモ
なので会社の機密情報になるような情報は残さないようにしています。
インターネット上に公開されているScrapboxプロジェクトを見ているとグレーな情報が書かれていることがあるので気をつけた方がいいでしょう。
自作Alfred Workflowの紹介
小さな技術メモを残していく中で、
- ブックマーク作成
- Scrapbox内検索
が気軽にできると便利だったので自作のAlfred Workflowを作成しました。
一緒に使うと便利なのでぜひ使ってみてください。
小さな技術メモを残すのに試したツール
最後に一応試したけど、使わなかったツールを紹介します。
Github Gist
コードスニペットを残すのに使いましたが、以下の理由で要件にあいませんでした。
- 整理機能が充実していない
- ブックマークとか簡単なメモを残せない
会社のWiki
機密情報も気にせず書けるというメリットがありましたが、以下の理由で使いづらかったです。
- 技術メモはプライベートな勉強でも参照したり作成したりする。
- 転職したときに消えるのが痛い
Notion
フォルダの概念があって、整理するのが面倒に感じ使いませんでした。
