やる気がストロングZERO

やる気のストロングスタイル

年末年始にvimのコードを読んでみた

年末年始にvimのコードリーディングにトライしてみた。 読んだのはこちら github.com

僕はターミナルアプリを作った事があり描画部分でバグが出ていたのだが、ターミナルでレイアウト描画する仕組みがわかってなかったので直せなかった。

vimでもそのあたりやってるはずなので、実際にコードを読んでそのあたりの仕組みを知りたいと思っていたのがきっかけ。

読み進め方

vimをソースからデバッグbuildし、gdbデバッグ実行しつつ、対象箇所をvimで読み進めた。

僕は普段はintellijを使っているが、使い慣れていないCLionをインストールしてどうのこうのするよりも、今回はvimとctagsで読むことにした。

ターミナルに文字がレイアウトして出力される仕組み

os_unix.cのmch_write()で実行されていた。

https://github.com/vim/vim/blob/v9.0.2087/src/os_unix.c#L435

やってることは標準出力に文字列を出力しているだけであるが、出力されているのがANSIエスケープシーケンスを含んだ文字列であった。

この文字列データを受け取ったターミナル側がこのANSIエスケープシーケンスを解釈し、任意の場所に文字列を表示させたり、色を変えたりする仕組みのようだった。 こういう機構のことを初めて知った。

こんな文字列が出力されていた。

"\033[?25l\033[m1\033[18;155H\033[1m\033[38;5;17m\033[48;5;45m2\033[m\03    3[38;5;17m\033[48;5;45m \033[1;26H\033[?25hh1m\033[38;5;17m\033[48;5;45m     ㏑:11\b/1☰☰\b℅\033[18;153H:11\033[m\033[38;5;17m\033[48;5;45m \033[1;15    H\033[?25h.......

その他わかったこと

main.cにmain_loop()ってのがあって、その最下部でnormal_cmd()ってのが呼び出されてる。

https://github.com/vim/vim/blob/v9.0.2087/src/main.c#L1562

このnormal.cのnormal_cmd()の内部でキー入力を待つ部分があって、そこでキー入力を待ってる。

normalモードからiキーでinsertmodeにはいれるわけだが、入力されたキーと実行するコマンドの対応付けがされたテーブル構造がある。 nv_cmds[]という構造体の配列。

'i'キーにはnv_edit()関数が紐づいているので、iキーを押すとこれが呼び出される。

https://github.com/vim/vim/blob/v9.0.2087/src/nv_cmds.h#L217

内部にはまた無限ループ構造があって、キー入力を待ち受ける場所があって、キー入力されるとそれをターミナルに出力する、みたいなのが大きな流れだった。

リーディング中

fileから文字列を読み込んで、ターミナルに出力されるまでの処理を追っていたが正月休みが終わってしまった。

なんか構造体の範囲外のメモリ領域までつかってデータを保持してたりしてて、「これがCの世界か、、」と感動したりしてた。

https://github.com/vim/vim/blob/v9.0.2087/src/memline.c#L116

2023年活動まとめ

あっという間に2023年も終わる。 サクッと2023年の活動についてまとめる。

去年立てた目標の振り返り

「リーダー的な振る舞いも多少できるように」という目標を立てていた。

リーダー的な振る舞いってのがよくわからない。 タスクを振る、そういう管理者的なやつは苦手。

あまり「リーダー」って感じの動きは相変わらず出来てない気がする。そもそもリーダー的な振る舞いってどういう振る舞いなのかわからん。むしろ逆に個人主義に走ってる気がする。 担当しているシステムにとって有効と思いついた事はtodoやissueとして積んでも、みんな暇なわけじゃないのでなかなか処理される事はない。 やってみればサクッと終わるようなものも多いので、であれば自分がエイヤでやってしまった方がいいと思うようになって実践している。

あと、自分が知った事は余計なお世話かもだが勉強会などをして伝えていこうと行動している。自分がする話について需要があるのかどうかわからなくて、聞かされてどう思ってるのかもわからないが、たまに質問攻めみたいになるシーンがあって個人的にそういう反応があると嬉しいと思うようになった。

「リーダー的な振る舞い」について定義してなかったので負け。

子供のこと

かなりコミュニケーションがとれるようになってきて楽しくなってきた。 けっこう歩いてくれるので、子供用イベントなどしっかりしたお出かけも出来るようになって、これもこれで楽しい。

あいかわらず自分の時間はなかなか自由にとれないが、したいこともそれほどなくなってきたのでそこまで苦でなくなってきた。 たまに「一日自由時間がほしいなぁ」と思ったりするが、実際にあっても特になにも思いつかず時間を持て余すだけな気がする。

病気のこと

3月くらいに目が見えなくなる病気になって、治療して治って今もほとんど以前と変わらず生活できている。 再発あるかもって事だが今のところ再発はしてない。もう薬も飲んでおらず経過観察の状態にはいった。

健康診断でもちょいちょい引っかかるようになってきて、食事面でも自由度が下がった。

5,6千歩ほど歩くことを週5日ほどやってるが効果があるのかないのか。 それ以上運動をしようとしても時間を捻出するのが難しい。 子供がもう少し大きくなったらそういう時間もとれるようになるかもしれないが、今はまだ無理。

仕事のこと

新規システムを作り上げた。

結合試験でシリアスなバグも無く、まったく問題なくリリースまで持っていけたと思う。

既存の旧システムと同じような機能だが、ゼロから設計し直してパフォーマンスをめちゃ改善できた。メモリ使用量など半分以下にできたのでマシンリソースコストをかなり下げられて嬉しかった。

感じたのは、アーキテクチャをしっかり整えれば問題自体が発生しない。変な工夫を入れる必要もない。何もイベントが無くシステムがただ完成する。 追加発生する要望にも「シンプルにただ対応するだけ」という単純作業になる。 依存が少ないので「簡単には対応できない」みたいな事が発生しない。

自分の自信にもなったし、色々考えていたことの裏取りもできたし、それなりに評価もされていて気分がいい。 このままアーキテクト的なキャリアを進められればなぁとか思う。

タスクを振ることや、教えることについて

やはり得意ではない。 人にやってもらうのは難しい。自分でやりたいと思ってしまう。 でも一人ではできることに限りがある。 実際今回の新規システム開発でも、上司が僕の手を付けていないタスクをいい感じにメンバーに割り振ってくれてかなり助かった。 こういう動きを自分でできるようになれればもっと色々できる気がする。

自分でタスクを割り振る場合、成果物の品質が気になって自分も結構細かく意識してしまう。

なので気にしなくていいくらいの粒度に細分化して割り振るなどしていたが、 このやり方だと並列で意識しないといけない事柄が増え負荷が上がり自分がボトルネックになるので悪手っぽい。

タスク難易度を経験から判断して、進め方もなにもかも任せてしまう、って感じを目指さないといけないかも。 何か問題が発生したらそこから強引にでも軌道修正できる自信が持てないとなかなか難しそう。

転職したいと思っていない。

2年経ったがまだ転職したいと思ってない。いい職場だと思ってる。

それなりに評価してもらえている。

新規システムを滞りなく仕上げたことでそれなりに評価されている気がする。 自分の強みと業務内容がマッチしている気がするのでこのままやっていきたい。

来年の目標

「チームで何かをする」ということについてどんな手法があるのかを考えたい。 もしくは諦めて、個人主義でも必要とされるレベルを目指す。

DBのテーブル設計まわりももう少し深く関わってみたい。

mavenのbuild lifecycleについて調べた

mavenjavaをbuildしてjarを作ることをよく行っているが、どういうことが行われてbuildされているのかよく分かってなかったので調べてみた。 結構難しいと思った。分かった範囲でメモる

参考資料:

Mavenの基本勉強メモ #Java - Qiita

Maven – Introduction to the Build Lifecycle

mavenが定義している処理の流れがある

javaをbuildしてjarを作成するまでに行われる工程がある。 例えば、事前にリソースファイルを移動して、コードをコンパイルして、jarに固めて、、というような工程である。 これらの工程をmavenは定義している。

mavenで定義されている工程は以下である。

参考) Maven – Introduction to the Build Lifecycle

  • validate
  • initialize
  • generate-sources
  • process-sources
  • generate-resources
  • process-resources
  • compile
  • process-classes
  • generate-test-sources
  • process-test-sources
  • generate-test-resources
  • process-test-resources
  • test-compile
  • process-test-classes
  • test
  • prepare-package
  • package
  • pre-integration-test
  • integration-test
  • post-integration-test
  • verify
  • install
  • deploy

これらの工程1つ1つを「フェーズ」と呼ぶ

フェーズではプラグインが処理を行っている

上記の各フェーズはあくまで「こういう工程がある」とmavenが定義しているだけで、実際に何を行うかはPluginが責任を持っている。 なので、どのフェーズで具体的に何をするのかは、どのPluginを使うのかを指定する必要がある。

mavenには代表的なユースケースに関しては一通りのPlugin設定を行ったデフォルト設定というものがある。

例えば、mavenでjarを作成する場合にmavenで定義されている工程は以下で、それぞれpluginがデフォルトで指定されている。 参考) Maven – Introduction to the Build Lifecycle

フェーズ plugin:ゴール
process-resources resources:resources
compile compiler:compile
process-test-resources resources:testResources
test-compile compiler:testCompile
test surefire:test
package ejb:ejb or ejb3:ejb3 or jar:jar or par:par or rar:rar or war:war
install install:install
deploy deploy:deploy

僕らが何も明示的に設定しなければ、各フェーズではデフォルトのプラグインによって処理が実行される。 たとえば、compileフェーズに対するデフォルトプラグインmaven-compiler-pluginである。

Pluginのゴールについて

プラグインには複数の機能があったりする。 maven-compiler-pluginには以下の2つの機能がある。

参考) Apache Maven Compiler Plugin – Introduction

Pluginの持っているこれらの機能のことを「ゴール」と呼んでいる。 maven-compiler-pluginはcompileフェーズとtest-compileフェーズのデフォルトPluginとして定義されていて、それぞれcompileゴールとtestCompileゴールが指定されている。

デフォルトプラグインではなく、自分でPluginを指定、設定したい場合は「どのフェーズで、どのPluginのどのゴールを実行するのか」を指定する感じになる。

mavenで何をするか(jarやwarをpackageingするのか、cleanするのかなど)によって定義されているフェーズが異なる。

上記で説明したのはjarをパッケージしたい場合のフェーズだが、行いたいことによって定義されているフェーズやそれに紐づけられているデフォルトPluginが異なる。 例えばpomをパッケージングしたい場合のフェーズは以下。

  • package
  • install
  • deploy

未経験から中途でエンジニアになりメガベンチャーに入るまでの軌跡を振り返った

僕は未経験からエンジニアになり、今はメガベンチャーでエンジニアとして働いている。

未経験からエンジニアになるのはそれなりに難しく、願いが敵わないパターンも多くあると聞く。 そんな中、なぜ自分はエンジニアになり、メガベンチャーで働くことができるようになったのかを分析するため、未経験からエンジニアになるまでに歩んだ道のりのポイントポイントで抱えていた悩み、頑張っていたことなどを思い出し書いてみる。

今、未経験からエンジニアを目指している人がいれば参考になるかもしれない。
(時代や運の影響もあるのであくまで参考程度に)

webデザイナーブラック期(スクール、契約社員

大学新卒から4年、僕はITとはまったく異なる業種で働いていたのだが、ある理由で転職することにし、転職先職種に「WEBデザイナー」を選んだ。

時期的には2008年あたりだが、今で言う「エンジニアブーム」みたいな感じで「WEBデザイナーブーム」みたいなものがこの頃はあった(ように思っている)。

僕はPCには興味がある方だったのと、自分が「なんかカッコいい職」に就けるのに高揚感もあって踏み込んだ。あまり深くは考えてなかった気がする。

転職までの準備期間として、働きながらWEBデザイナーのスキルを教えてくれるスクールに通った。
教えてもらったのはHTML/CSSの基礎とPhotoshop, Illustratorの使い方の基礎。デザインについての授業はなかった。
カリキュラムを終えたタイミングで退職し、転職活動を始めた。

やはり未経験からはなかなか職が決まらず、約半年の無職求職期間を経て契約社員で雇ってもらうことができた。
風俗ポータルサイトの運営を行っている会社だった。

業務内容は「ポータルサイトの風俗店の情報更新作業」がメインで、付随して「バナーデザイン」「企画ページのデザインと構築」があった。

「風俗店の情報更新作業」とは日中ずっと行う必要がある作業で、常時営業から新しい女の子のプロフィールや画像が送られてきて、それをポータルサイトに反映させるといったものだ。
基本はコントロールパネルからデータ入力を行ったり、Photoshopで顔にボカシを入れる程度の作業なのでhtmlの知識もデザイン力もいらない。

「バナーデザイン」とは、ポータルサイトのバナー表示枠に表示するバナーをデザインする作業だ。
表示枠を購入した風俗店から女の子の画像と載せてほしい内容が送られてきて、いい感じにバナーデザインに落とし込む。
バナーには数種類のサイズがあるので、一つデザインを作成したら、デザインを微調整しながら各種サイズバナーを作成する。

「企画ページのデザインと構築」とは、ポータルサイトに掲載する読み物コンテンツのページデザインとHTML/CSSによる構築を行う作業である。
「〇〇店の体験特集」とか「紳士の嗜みとしての風俗特集」みたいなやつである。

企画と掲載する内容は別部署から上がってきて、それを見栄えするようにデザインし、そのページをHTMLとCSSで組み上げる。
こういうのはHTML/CSSの知識も要るし、まさにページデザインも行う必要があるので、大体はデザイン力のある先輩デザイナーがやってた。
少しだけ自分も携わった。

余談だが、風俗店への直接電話営業までさせられたりしていた。

悩んでいたこと

デザインができない

まず、僕はデザインができなかった。

僕は前述したとおり、HTML/CSSAdobeツールの使い方を学んだだけで、デザインについては素人だったのでデザイン業務は苦労した。
簡単なバナー作成の仕事にしても、頭ではカッコいいレイアウトとかイメージできているつもりだったのだが、いざ形にしてみるとクソダサデザインにしかならず、どうすればまとまった見た目になるのかまったくわからなかった。

時間をかけてもかけても全く完成に近づいていかず、冷や汗を書きながら自分でもイマイチなデザインを上司レビューに上げては直しを食らって、、をひたすら繰り返していた。そんなことを繰り返していると上司からのアタリもキツくなってきた。

残業

職場は慢性的な残業体質だった。
自分の手が遅すぎるのもあったと思うが、ほかメンバーや他の社員もずっと残っていたのでそういう風土があったと思う。
日中は主にポータルサイトの情報更新作業で時間がとられるので、定時後になって更新作業が落ち着くとやバナーデザインや企画ページデザインを行っていた。

最初は「一人前になるためなら多少のキツさは覚悟の上!」みたいなつもりでやってたが、ずっとダメ出しを食らっているような状況なので成長も感じられずただひたすら辛かった。
デザインはなかなかOKが出ないが締切もあるので、終電後家に持ち帰って3時頃までレイアウトをこねくり回したりしていた。
「そろそろ終電なんで帰ります」とよく言っていた気がする。

頑張っていたこと

特に戦略を持ってなにかを頑張っていたものはなかった。
言われた指示に従ってデザインOKをもらうことで精一杯だった。上記したように、持ち帰って作業もしていた。
ダメ出しを食らうのがわかっていてデザインを提出するときは惨めに思ったし、精神的にかなり疲弊していたが会社は休まないようにはしていた。

それでも最終的に音を上げて転職した。

実感として成長は感じることは出来なかったが、長時間労働に関する感覚は得ることが出来た。

webデザイナーマッタリ低賃金期(ECサイト管理)

転職先はECサイトの管理業務だった。

会社はペットフードの卸業を行いながらECサイト楽天・Yahooショッピング・自社EC)で販売を行っていた。
僕はYahooショッピング担当として「商品ページの作成」「時期ごとのキャンペーンページの作成」「問い合わせ対応」「メルマガ作成」「商品在庫管理と発注・入庫作業」「庭の草刈り」を行っていた。

大体はルーティン作業で、仕事自体は苦労なくこなすことが出来た。

デザイン作業として、キャンペーンページやキャンペーンバナー作成が必要だったが、この会社はデザインについてこだわりがなく、適当にそれっぽくレイアウトしておけばレビューは通ったので、それほどデザイン作業で苦労することも無かった。

残業もまったくなく、まったり働くことができた。

ECサイト管理業務だけではなく、広く雑用として利用され、試供品をデパートで配ったり、アイスクリームチェーン店(オーナーの持ってる事業の一貫)の呼び込みも特に憤りなくやったりしていた。

悩んでいたこと:

低賃金

前職と違って、業務で悩むことはあまりなかったが、とにかく低賃金だった。
そもそも前職も低かったがそれ以上に。。月収15万だったので手取りで13万とかだったと思う(翌年は1万昇給した)。実家ぐらししていたのと、前職のトラウマでそれでもそれほど不満なく働いていた。
年頃だったので彼女とデートなどのイベントもあったが、一度デートに行くとその月はちょっと厳しい、、みたいな感じだった気がする。
これでは結婚もできないなぁとか思ってた。

頑張っていたこと

JS,PHP,SQLを自習した

この頃、なぜかJSやPHPSQLに興味を持って自分の時間を使って学んでいた。(毎日定時退社だったので時間はあった)
FC2レンタルサーバの無料枠を使ってJSとPHPMySQLを使ったちょっとした実験サイト(DBから取得したデータでページを出力する)みたいなものを公開してみたりしていた。
SQLを学んだので、会社の業務でもACCESSSQLを使って在庫データをいい感じに見れるようにしたりしていた。 (特に社内で展開せず自分だけで使ってニヤニヤしていた)

特に仕事に不満はなかったが、とにかく低賃金だったのと、JSやPHPをちゃんと使える環境を求めて転職先を探し転職した。 (Yahooや楽天ではJSやCSSを使うのに制限が多く、もっと色々試せる環境で仕事してみたくなった)

JS触れるwebデザイナー

転職先は、自社サービスを運用開発(正確には受託だったが自由度が高かった)していたので、自社サービスの運用開発についてのノウハウを色々体験することができた。
当時、関西で自社サービス開発を行っている会社ってそれほどなかったように思う。自分がどのようにその会社を見つけて応募したのか全く覚えていないが、何社か受けてなんとなくおもしろそうと思って入った気がする。

オフィスも広くて、和気あいあいとした空気感で、皆若かった。 エンジニアもたくさんいた。

その会社はチーム単位で一つのWEBサービスを担当しており、僕は動画コンテンツの売買サービスを担当している4人ほどのチームに入り、サイトデザインのリプレイスや、新機能のUIのデザインとHTML, CSS構築を行ったりしていた。

エンジニアとの分業を体験し、gitも初めて触った。

悩んでいたこと

デザインが苦手

この会社では求められるデザインのレベルが高かった。

僕は、前述したようにデザインはもちろん、UIについても全く素人だったので(なんで採用されたんだろう。。)ここでもやはり苦労した。
サービスデザインのリプレイスでは、WEBサービスの勘所を外しまくったデザイン案を副社長(副社長はデザイン職のTOPだった)まで上げて「こいつは駄目だ。。上長達はこれをほんとに良ししたのか?」と大事に発展させてしまった。

それ以降も、そこまで大事になることはなかったが、なかなかバシッとしたデザイン案を作ることができなかった。
デザインを作成した自分に自信がないものだから押しが弱く、そうなると皆意見を出してくれるのだが、それ故方向性が四散しデザインがまとまるまで苦労することが多かった。

デザインには自分のデザインに対する自信と、案を押し通す説得力が必要だったが、僕はそれがなかなか得られず苦労した。

頑張っていたこと

デザインについて学んだ

上記のようにデザインで本当に苦労したので、デザインについては相当学んだ。

学んでわかった事がある。
デザインにはロジック的な要素と、フィーリング的な要素がある。

ロジック的な要素に関しては書籍で学べた。
どのように要素を配置すれば人の視線を誘導できるか、ストレス無く操作してもらえるか、というようなものである。

デザインを完成させるにはコレでは足りず、ここにフィーリング的な要素が必要になる。
ロジック的な要素をしっかり盛り込んで、ユーザーが(もしくは作り手側が)目的を果たせるようにした上で、どうやって「わくわく」させるか、「高級感」を感じてもらえるか、「おっ」と思わせて気を引けるか、をデザインするのである。

こういうフィーリング的な要素はデザインの全体感やディティールのこだわりで醸し出され、まさにアイデア勝負な部分である。 できるデザイナーは、普段からデザインについて考えており、そういうネタ(ちょっとした飾りつけとか、全体テーマとか、小物とかのアイデア)をたくさん持っている。 そういう細かい、まさにプロのあしらいが、自分のデザインとの雲泥の差を産んでいた。

僕は、ロジック的な部分はある程度カバーすることが出来るようになったが、フィーリング的な部分に関しては最後まで克服することが出来なかった。

JS絡みを頑張った

そんな感じで、デザイン業務に関してはパッとしなかったが、JSが絡むページ構築は張り切っていた。 JSができるデザイナーが他にいなかったので、そこにアイデンティティを見出して頑張っていた。

とはいっても、この頃は「JSといえはjQuery」みたいな時代で、ボタンを押すと表示が開いたり閉じたりするくらいの動きをさせる程度だった。 コードも全然プロレベルではなかったと思うが、チーム内のエンジニアは単にめんどくさかったんで僕に任せて自由にさせていたんだと思う。

自分でWEBサービスとか作っていた

この会社もそれほど残業なかったので、自分の時間を使ってWEBサービスとか作っていた。

この頃は、自分のサービスを作って一発当てて不労所得ガッポガッポな話も今よりありふれていたし、自分もそれに憧れていた。 また、会社のまわりのエンジニアがそういうこと(自分でサービスを運用する)をやっていたので、それに刺激されたというもの大きいと思う。

その頃僕はWEBスクレイピングを知って面白さにハマっていたので、アダルトアフィリエイト商材をスクレイピングしてDBにデータを蓄積し、WordPressを改造してアダルト商材アフィリエイトサイトとして運用したりしていた。

また集客施策として、TwitterAPIを使って「アダルト関連のアカウントをフォローしているアカウント」を自動的に片っ端からフォロー(相互フォロー狙い)していき、そのアカウントでアダルト商品の紹介(リンク先は自分のアフィリエイトサイト)を自動的につぶやかせたりしていた。

少しはお金が入ったりもして、なかなか楽しかった。

他にも色々個人サービス開発をやったがこれのお陰で色々体験できた。

既存サービスに改修を入れるのとは違う(それはそれで難しいシーンもあるが)ゼロからコードを組む難しさを体験できた。

運用し続ける難しさも体験できた。 開発しているときはコードの隅々まで理解してるんだけど、ちょっと放置して他のサービス開発やってると見事に全部忘れている。 たまにうまく動いてない事に気がついて修正しようとするのだが、

  • コードがどこにあるか忘れている。
  • 開発環境がどうなっていたか忘れている。
  • サーバーへの入り方を忘れている、キーとパスを忘れている。
  • サーバーがどこだったか忘れている。
  • デプロイ方法忘れている。
  • 構成を忘れている。
  • とにかく全部忘れている。

ちょっと複雑な手順はもう二度と思い出せずロストテクノロジーとなってしまう。 運用に必要な手順などはすべて自動化するなりしてコードに落とし込んで置かないといけないことを学んだ。

何事もコツコツ進めた

サービス作りはとにかくやることが多いのでなかなか進捗してないように感じるが、毎日コツコツやることで確実に進捗し、出来たときはとても嬉しいということを体験した。 何かを運用しているという状態が楽しく、次はああしよう、こうしようと少しずつ改良していく事が楽しかった。

この頃あたりから、エンジニアとして仕事をしたいと強く思うようになった。

エンジニア入門期(駆け出しエンジニア期)

普段から「エンジニアになりたい」と吹聴しながら、JS使った簡単なフロント実装やったり、たまにちょっとしたサーバーサイドの機能改修をPHP使って開発させてもらったりしていた。

そういう普段からのアピールが効いたのか、ある新規サービスをゼロから開発する企画が立ち上がったとき「じゃあデザイナー兼、エンジニア入門でやってみるか?」と開発を担当させてもらえる事になった。 その当時上司にあたるポジションのエンジニアに指導されながらの形だった。 (今思えばよくやらせてくれたよなと思う。自分の仕事もありつつ未熟なエンジニアに新規サービス作らせるとか、負担倍増どころの話じゃない気がする。。)

僕は張り切って、デザインも含めてサービス構築を頑張った。

悩んでいたこと

無限に発生してくる問題に対処しきれない

開発していると、上司エンジニアからのレビューで「この場合どうなる?」「こういうケースあるけど対応できてる?」みたいに無限に問題箇所を指摘された。 ツッコミ一つ一つが当時の僕にとって難問で解決策がなかなか浮かばず、悩んだ分だけ進捗が遅れていく。 ただでさえ「サービスを完成させる」というゴールまでの見通しもたってなくて焦っていたところにそういうツッコミが無限に入るので、非常に追い込まれていた。

出来たと思ってもこれではダメだと突きつけられる。 指摘点を潰しても「じゃあこの場合は?」とダメ出しを食らう。 開発の進捗がとまる。。そもそもどのように対応していいのかわからない。 今までアイデンティティとして持っていた「少しプログラミングできる」という自信はゼロになり、自尊心も失われてつらい日々となった。

無駄な作業をしてしまう

コレで行けるはず、、と数日ほど実装を進めていくと「あ、、これではダメだ、、」と気がついたりする。 順調に作業が進んでいると思っていたのに、今までの作業が無駄だったと判明し、スケジュールが急に厳しくなる。

そんなことを繰り返し、精神的に追い詰められてパニックに陥ったりしていた。 作っても作っても完成に向かっている感覚を感じられなくなっていた。

頑張っていたこと

がむしゃらで、特に何を頑張ったとかはなかった。 眼の前も問題にひたすら向き合っていた感じ。 向き合ってはいたが自分の中から回答が導けなかったものも多いので、頑張り方としてはあまり効率は良くなかった気がするが、他に頑張り方がわからなかった。

業務時間だけでは足りなかったので土日も作業していたし、お盆に奥さんの実家に行ったときもお義父さんの書斎を借りてずっと作業したりしていた。 (そんなに自分の時間をさいてやって、それが突然無駄な作業であったと気がついたときの精神の落ち込みようは凄かった。)

ずっと「どうやれば完成するだろう、問題に対処できるだろう」ということを考えていた気がする。

最終的には、上司エンジニアも開発に入ってくれて、ガッと完成まで持っていった気がする。自分に余裕がまったくなかったので、どういうサポートをしてもらったのかも認識できていなかった。。

そうやってサービスはリリースまで行ったが、その後は企画自体があまりうまく行かず、サイトもしばらく開発凍結みたいな状態になって、エンジニアタスクがなくなった僕はまたデザイナータスク中心な状況に戻ることになった。 この時点でもう僕はデザイナー業務を行う気力は残っていなくて、なんとかエンジニアとして仕事を続けるために転職した。

正式に職種がエンジニアになった期(駆け出せたエンジニア期)

転職先はなんとなく「受託ではなく自社開発」にこだわって探していた。

それなりに大きなところにも挑戦したが、やはり正式なエンジニアとしての経験が足りておらず苦戦していた。 今振り返ると「新規サービスを開発した」と言っても、DB設計や、ミドルウェアの構築や、AWSでのEC2払い出しとか、全部やってもらっており自分がやってたのはコード書いてただけだった。デプロイもやってもらってた気がする。。 新規サービス開発経験を必死にアピールしていたが、たしかに一人前のエンジニアとしては程遠かったように思う。

色々受けてなんとか入れてもらえたのはWindows用の業務アプリを自社開発している会社だった。

後で知ったが、採用の基準は「プログラムが好きそうかどうか」だった(のちに自分も面接官側をやらせてもらったときに知った)。 そもそも応募が少なく優秀な人は来ない。せめてプログラムが好きであれば伸びしろがある、という理屈であった。

自分でアダルトアフィリエイトサービスを開発運用していることをアピールしていたのが活きた。

余談だが求職活動の中でアダルトサービスを運用している事をアピールしたのはなかなか有効だったように思う。 書類で印象に残るのと、面接には意外にちゃんとした人(僕はパッと見ちゃんとしてそうに見える)が来るのでギャップ効果もあってハマるところにはハマるらしい。 入社してからも話のネタとしてかなりお世話になった。 もちろん、ダメなところは全くダメだと思う。

悩んでいたこと

システム開発の流れに翻弄された

この会社では、数年前から新規開発しているWindowns業務アプリがあったのだが、これが難航していた。 僕もこの開発に参加し、割り当てられた担当分をこなしていた。

この会社でのWindowsアプリ開発はモダンなWebシステム開発と比較すると利用している技術も古いものが多かった。 痒いところに手が全く届かない状況のなかで不満もありつつ、僕は与えられた担当分の開発をコツコツ進めていた。

未熟だった僕は、与えられた担当分以外については無関心だった。 自分の範囲だけ順調に開発を進めていたが、開発全体としての進捗はあまり意識していなかった。

自分も悪かったが、僕が全体を意識しない要因としては、全体進捗に触れる機会がほとんど無かった、というのもあったと思う。 そもそも当時の僕は、システム開発がどんなふうにマネジメントされて進捗していくのか知らなかったので気にならなかった。 「担当分をしっかりやってればうまくいくんだろう」くらいに思っていた。

さらに、自分は関西で、他のメンバーは関東で開発していたので余計に意識する機会が無かった。

今思えば、システム開発に関わっているメンバー全員で情報を共有し、スケジュール通りに進んでいるか、なにか問題が起きていないかなどを確認し、問題が起きているとわかった場合にはそれを潰す解決策を検討するなど、わりと頻繁に会議が必要なはずである。 そういうのがほぼ無かった。

毎週定例会議は開催されていたが形式的な内容であまり進捗どうこうの話はなかった気がする。

この開発は以前から予定完成時期をリスケリスケで来ていたのだが、既存メンバー一人の離脱(退職)を期に改めてスケジュールに不穏な空気がながれ、社長がいい加減しびれを切らしてマネジメントに乗り出してきた。

スケジュールが改めて仕切り直され、それと同時に他メンバーの担当だった部分の大部分が僕に担当替えされた。

残ったメンバーが、新卒2,3年目という戦力だったのもあり開発の進捗が良くなく比較的開発を進捗させられていた自分に大きく振られた、という形だったのかもしれない。

そうして仕切り直されたスケジュールだが「このアプリは全部で24画面あるから来年リリースするとして、1ヶ月2画面を作れ」みたいなスケジュールだった。 このスケジュールプランに僕は悩むことになった。

1画面を完成させるには、そのアプリ全体で必要になる機能の8割程を完成させる必要があり、画面単位で分割して開発を進めるのはナンセンスであることを主張したが取り入れられなかった。(もう開発に対しての信頼がなかったのかもしれない)

そもそも、以前から開発部分の担当分けを画面単位で行っており、画面単位で開発を進めるのが文化にとして根付いていたっぽい。

以降、毎月の進捗定例(月イチで社長に報告する必要があった)で、なぜスケジュール通りに進捗していないのかを説明するあたりで悩んでストレスだった。

頑張っていたこと

どうあるべきなのかを追い求めた。

上記のようにスケジュールに苦しんでいたが、他にも色々苦しんでいた。

その中の一つは既存コードの構造である。 画面単位で担当を分けて開発を進めてきた影響だと思うが、実装の多くはViewとビジネスロジックが密結合した状態だった。 複数の画面で共通して必要な機能(例えばDBから特定のデータを取得する機能とか)が単独の機能としては存在しておらず、各画面と密結合した形でそれぞれに独自に実装されていた。 そのため、新しい画面を実装するときにこの機能が使いたくても微妙な画面構成の違いによりコードを使い回せなかった。 他にもストアドプロシージャの多用や、グローバルに存在するイベントハンドラを介したイベントドリブンな全体設計に苦戦していた。

そうやって色々悩んでいたのだが「じゃあどいういうものだったら自分は悩まずに済んだのか」に強く興味を持つようになり、DDDやクリーンアーキテクチャにのめり込み始めた。 他にもプロジェクトを失敗させない為にやるべきことは何なのか考えるようになった。 学んだアーキテクチャや開発手法は個人開発で取り入れて検証などを行い、搾取選択して自分なりの考えを固め始めた。 (以下を書いたのは最近だが、この時期から考え始めていたことである。) https://yaruki-strong-zero.hatenablog.jp/entry/development_priority

この頃は、これらの考え方について自信が無くまだ個人開発で検証していた程度だった。 しかし後々これらの考え方は実業務で実践する機会があり、それらでの実績も得て、今ではそれなりに有効な考え方であると自信を持てている。

自分で必要と思うことは行動していた

デザイナーの頃は受け身的に仕事をしていることが多かった気がするが、この頃から仕事自体をある部分は楽しみ始めて、自分から色々動くようになってきた。 根底のところでデザイン作業は好みではなく、エンジニア仕事は好きだったんだと思う。 実装を進めるに当たって仕様に不明点があれば、それを明らかにするのに自分的に最適に思える手段を提案しつつ相談などするようになった。 今までこんな動きはしていなかったと思う。

使っている技術について表面的な利用方法だけではなく、一つ深い動作原理の部分の理解に努めるようになった。 この時は開発環境はWindowsだったのだが、Windows周りの技術の理解には苦戦することが多かった。 なかなか良い感じに体系的にまとまっている情報がなかった。Microsoftのサイトでさえ、日本語訳が変だったり、リンクが切れていたり、良さげなページを見つけても続きがなかったり。。(英語で探せばあったのかもだが、この頃は日本語しか読む気がなかった。。) Windowsについての理解が進まない鬱憤をLinuxに向けたりしていた。そうして次第に「やっぱLinux上で動くものを開発したいな。。」と思うようになっていった。

そんなことをしていたら、業務上での評価はそこそこ得られていたので嬉しかった。(スケジュールの件で社長評価はイマイチだった気がするが。。)

そんな感じで頑張ってはいたが、社長がマネジメントに入ってきてからの要求スケジュールはどうやっても守ることはできないので、そうなると当然評価されないし、その状態が長く続くのは避けたいと考え転職先を探すことにした。

エンジニアの深淵に触れた期

相変わらず、なんとなく自社開発やってる会社で転職先を探した。

今回の会社選びでは以前よりも少し手応えがあった。 以前はぜんぜんだめだったけど、今回は面接もなかなか手応えがあって、最終的に2つの会社から同時に内定をもらった。 ちなみに、この時も個人開発アダルトアフィリエイトサービスに関してはアピールしており、そこそこ効果があったように思う。 アダルト抜きにしても「自分でなにか開発して運用している」っていう事をしている人は意外に少ないらしい。

どちらの会社にするか色々悩んだけど最終的には給与で決めた。

この会社で自分は課金周りのシステムを担当する事になった。 契約更新のバッチ処理が回って、更新分の請求をかける。 基本機能は上記のバッチ処理なのだが、付随した機能がてんこ盛りで全体を把握するのがかなり難しかった(というか、できなかった)。 このシステムはruby on railsで組まれていた。ここで始めてRubyに関わることになった。

また、後半は並行して新規システムの作成に関わることになった。 新規開発ではアーキテクチャから任せてくれていい経験になった。 なぜか最終的にリリースあたりの記憶が薄いのだが、なんか深夜に酷く緊張しながら切り替え作業を行った記憶あるし、このブログでも「やり切った」と書いていたのでやり切ったのだと思う。 後述するが、とにかく締め切りがシビアな重い差し込みタスクがしょっちゅう発生する職場環境だったので、常に脳に負荷がかかっており記憶が飛んだのかもしれない。

悩んでいたこと

短納期・高品質を求められるタスクが多かった

担当した請求システムはバグが存在していたりして不安定で、不定期に内外要因で請求バッチ処理が失敗していた。 失敗しても自動リカバリがないので復旧作業を行う必要があった。 失敗の原因は様々で既知のものばかりでは無いため、復旧には原因調査と復旧プラン構築が必要で、さらにこれをごく限られた時間内でやりきる必要があった。 失敗が発覚するのは請求バッチ処理が回ったタイミングであり、これを迫っている請求期限までに復旧させないといけないからだ。

そして、原因調査・復旧プラン構築以外にも以下のような重いタスクがある。

[請求金額の算出]
請求金額に修正を入れる場合にはあたりまえだが金額を間違えられないのだが、正しい請求金額の算出も難しい。 オプションがあったり、特別値引きがあったりするのだが、みな料金体系を隅々まで把握してるわけじゃないし、わかりやすい一覧表みたいなものもない。 正しい料金計算仕様は実装から読み解くしかないが、コード自体もなかなか素直に読める構造ではなくこれも難しい。 実装がバグっている可能性もあるので、これも100%信じるわけには行かない。

[復旧プランのレビュー]
金額に関わるので上長を含めて原因調査内容・復旧プランのレビューを行う必要がある。 このレビュー準備に時間がかかる。 現場レベルでは常からコンテクストが共有されているので状況は伝わりやすいが、上長や他の関係者に説明するとなると、前提知識の共有から行う必要があるのだ。 もともと期限がシビアな上にレビュー準備にも時間がかかるので、さらに作業・調査に使える時間は少なくなる。 また、上長の予定は基本埋まっているため予定を抑えるのも難しかったりする。

[復旧プランの失敗対応]
復旧プランを建て付けレビューを通して、いざ実施してもそれが失敗するパターンもままあった。 精神的に焦っているのに加えて、コード・データ構造が複雑なので実装や挙動を誤認識し、考慮できていなかったデータ状態が原因でテーブルが不整合を起こし失敗する。 そうなると、【復旧プラン構築 -> レビュー準備 -> レビュー -> 実施】のサイクルを再度まわさなければならない。

こういった割と重めの差し込みタスクが高頻度で発生していのだが、このタスクは脳を強制的フル回転・過度集中状態を強いてくる。 一時期これが常態化していた頃、もはやこの刺激がないと集中力を発揮できなくなるという症状を発症していた。 奇跡的に凪のような期間になるとなにもやる気が起きないのだ。バーンアウトだと思う。

そしてこれはあくまで差し込みタスクで通常タスクではない。 差し込みタスクを疲弊してこなした後は、残されたわずかな時間で通常タスクに取り組むことになる。 「先週は通常タスクに全く着手できなかったなぁ、、」みたいな感じが多かった。

会社の評価基準に自分の業務内容があってない

会社は新機能とか、新しい取り組みにチャレンジしたとか、そういうのをプラス評価とし、既存機能の保守作業はいくらやってもそれでプラス評価になることはない、というスタンスだった。

そして自分は(というか、自分が所属しているチームは)上記の通り、多くの時間で差し込み保守業務を行っていて、プラス評価につながるタスクに取り組める時間が少なかった。

バッチ処理が失敗したとき、放置するわけには行かないので対応に追われることになるのだが「でもこれ評価に繋がらないんだよな。。」と頭によぎって虚しくなったりしていた。(実際、こういう業務には関わらないメンバーもいた)

じゃあ僕は評価されてなかったのかと言えばそうでもなく、実際にはそれなりに評価されていたと思う。 たぶん直上の上長はそういった保守業務の難易度と重要度を理解してくれていたけど、さらに上に報告する際にそれが評価に繋がらない、ってことだったんだと思う。

だから評価用の作文をめちゃめちゃレビューしてくれて、時間をかけて練り上げていた。 ありがたい話ではあるが、ただでさえやること多くて時間ないのに、ここにも時間つかわなくてはならないのにも不満が募った。

「結局評価されてるのでいいじゃん」という考え方もあるかもだが、会社の掲げる評価基準に沿おうとすると「重い保守業務は他メンバーにまかせて自分はなるべく評価タスクをこなす」が最善手になるが、それって倫理的にどうなの?っていうジレンマがつらかったのと、保守業務が難易度高く高負荷でも、それをチームの頼れるメンバーと共に一眼となって乗り越えていっている状況をそれなりに誇っていたのに、評価につながらないとなると虚しく思えて辛かったのだと思う。

仕様がわからず、コードからも読み取れず、動かしてみることもできない

上記もしたように、差込トラブル時に必要になる詳細な仕様はシステムから読み取るしか無いが(あとは、前任者からの数点の資料や口伝があるが概要レベルで詳細な情報はない)その読み取りにずっと苦戦していた。

まず、コードリーディングによって理解するのが難しかった。

処理の流れは主にActiveRecodeのフックによって構築されていた。 処理Aによってテーブルα,βのデータが書き換えられたとき、それぞれのテーブル更新に設定されたフックで処理B,Cが動き出すのだ。

なので、処理Aと処理B,Cにぱっと見コード的な繋がりはない。 すべてのフックの登録状況と内容を把握していないと、次にどの処理が実行されるのかがわからない。 テーブル更新処理が入るたび、そこにフックが存在しないか、存在すればそれがなにか処理を実行しているか、その処理でさらにテーブル更新が入っていればそこにフックは存在しないか、、という感じなので非常につらかった。

実際、これが原因で障害復帰プランがよく失敗していた。想定していなかった思わぬ処理が動き出すのだ。

そんな感じなので、コードリーディングによって処理の流れをすべて理解し仕様を把握する、というのは難しかった。

リーディングが難しい場合、実際に動きを見て理解する、という手段があるが、これも難しかった。

このシステムはデータ、外部システムと密結合していたので、それらを正しい状態に整備しないと動かすことが出来ない。 そしてデータ・外部システムの正しい状態は、処理を理解できていないと用意できない。

例えば、バッチ処理には複数の種類の処理がある。新規請求や更新請求やキャンセルによる契約終了など。 これらはメソッドで処理が分けられてるんじゃなくて、突っ込まれるデータがどういう形なのかによって処理が分岐していた。 どういうデータだったらどの処理に入るのかを理解しないとデータを用意できない。

そして処理の一部は外部のシステムで実行されていた。 その外部システムとの連携仕様を理解していないと、正常な形で処理を動かすことができない。

そんな感じで、挙動を理解できないから動かしたい、でも動かすには挙動の理解が必要、というデッドロック状態になっていた。

そして、この複雑な状況に腰を据えてじっくりと取り組む時間的余裕もなかった。

頑張っていたこと

引き続き、どうあるべきかを追い求めて、部分的に実践もしていた。

前職同様、アーキテクチャについて引き続き考えつづけていた。

今回のシステムでイベントドリブンな構成が採用されていたが、イベントドリブンには相性があるのではないかと考えていた。 UIにおいてよくイベントドリブンな構成がとられているし、こちらは相性が良いのかもしれない。 この請求バッチ処理システムにおいては相性が良くないと思った。

一つ一つの処理がそれ単体で完結しているならイベントドリブンでもいいかもしれない。 例えばテーブルにデータが登録された際にフックでログを吐くなど。 これは「ログを吐く」で処理が完結しており、テーブルにデータを登録した処理とは直接何の関係もない。見逃されても問題ない。 しかし、フックで行われる処理も含めて一つの処理、となるとフック処理も確実に把握する必要があるのに、コード的に繋がっているように見えないのは弊害が大きいと考えるようになった。

クリーンアーキテクチャやDDDについても前職に引き続いて学んでいた。

特にレイヤーを意識する事の大事さをこの会社で身をもって体験することができた。 DBや外部システムとの結合部に注意する。依存性逆転の法則に感銘を受けた。 ここが曖昧になって密結合するとシステムがDBや外部システムに食い込んで、簡単には動かせない、ポータビリティの低いシステムになることを学んだ。

テスト駆動など、ロジックをテスタブルにすることにも心血を注いでいた。 すべては置き換えられないがせめて新規追加する部分に関してはテスタブルになることを意識して実装した。 これ以上苦しい状態にならないように気をつけていた。

評価システムや組織について考えていた

上記した、評価と業務のコンフリクトについてなぜ起こるのか、どうあればいいのか考えていた。 正しいのかどうかわからんが以下のようなことを思っていた。

評価とは、組織が行いたいことを実現させるため、社員をそちらに向かわせるための手法だと思った。 だから、会社としては新規な取り組みを行って、常に新しいことに挑戦して可能性を広げていこうとしていたのだと思う。

そこに保守業務は含まれていなかったわけだが、よく考えるとそれはそうかと思った。 経営層からは現場レベルの詳細な課題など見えないのだ。 請求バッチ処理が失敗して疲弊しながら復旧させて「今月も問題なく請求完了しました」と言っても「そらそうだろ。。」って感じだったのだろう思う。

実際はどうだったかと言えば、結果から言うと数人を専任で保守につけておかないと運用が出来ない状態だった。 しかも、起こった事象に対して早急に分析・対策・実施を行わなくてはならないので、誰でもできるというわけではない。そこそこ臨機応変さが求められるし、胆力も必要になる。これが滞ればそれなりにインパクトのある事象に発展したハズだし、実際上長からも危機感もった対応を迫られていたわけなので重要度としては高かったと僕は認識している。 そんな感じで現場レベルでは重要な業務だったが、それが経営レイヤーからは見えていなかったと考えられる。 (本当に重要でなかったなら、僕らもこんなことしたくなかったので喜んで別の業務をしていたはずである。)

じゃあ、これを上に伝えるのは誰が行うべきだったのか? もちろん現場の僕らが声を上げるのは必要として、こういう組織設計はもう少し上のレイヤーの仕事だと僕は考えた。

保守業務の実態(システムが不安定で保守コストがかかっていることと、これが失われたときに起こりうる事)を知った上で不要であるならば、システムを切り捨てるなりなんなりしてこの工数を別のものに向けるなどすべきだったと思う。

最終的に僕はそこに不満を持ってやめたわけなので、組織運用としては失敗していたのかなと考えた。 そこまで認識した上で、それで会社を去る人は不要、と割り切っているというのも戦略としてはありえるかもと思ったが、誠実ではないなと思った。

新規のシステムを開発した。設計からやれたので今まで学んだベストプラクティスを詰め込んだ

技術面に関するリードを行うポジションで新規システムの開発に関わる機会があった。 ここまでにも書いていたような自分なりのベストプラクティス(仮説)をここぞとばかりにすべて込めてみた。 それらはすべてうまくいった。自信につながった。

そんな感じで3年ほど頑張っていたが、色々疲弊して転職活動し始めた。 何にそんなに疲弊していたのかもうあまり覚えていない。軽く絶望していた気がする。 最終出社日にも緊急対応作業を行っていたのは覚えている。。

メガベンチャーエンジニア期(現在)

今回の転職活動は大手中心に応募した。 大手であればそれなりの職場環境だろうから失敗は少ないと考えた。 年齢的にも転職は最後(むしろもうタイムリミットが過ぎている)と思っていたので失敗はできないと思っていた。

大手中心の転職活動の手応えはそこそこ良かった。 コーディング試験はパスできたし二次面接まではスムーズにいけることが多かった。技術的な質疑にもそれなりに答えられたと思う。 このあたりは、前職でおこなった新規開発の経験がかなり活きたと思う(大手を受けるときはさすがにアダルトアフィリエイトサービスの事は言及しなかった)。 しかし、内定には一歩届かず二次面接でのお祈りが数社つづいた。 やはり、エンジニアとしてのセンスもあるわけではなく経験も少ない自分が大手に入るなど不可能だったのだ、と諦めかけていたころ、あるメガベンチャーから内定がでた。なにが決めてになったのかと問うと「人柄だ」と言われた。

担当することになったシステムはJava(Spring)で組まれていた。Rubyの自由な書き方に疲弊していた僕には、それは輝いているように感じた。

さすが大手は色々と環境が整っていた。 技術面では、PaaSやk8s基盤などの社内プラットフォームが存在していたし、CI/CDやテストコードがちゃんと存在していた。 また、システムがマイクロサービス化していて、担当システムの責任範囲がコンパクトだった。 これは人員と資金があるから実現できているように思う。 前職ではコストの兼ね合いで、ほんの数人で巨大な責任範囲のシステムを担当せねばならず掌握できていなかったし、(主にバグによる発生した事象の復旧対応で)周辺環境を整えるための時間的リソースも捻出できていなかった。

組織面でとくに驚いたのが「課題をエスカレーションするとちゃんと検討され、そして課題が取り除かれる」事だった。 いままで「課題はエスカレーションしても基本取り除かれない。調査タスクなど仕事が増えるだけ」という経験を多くしてきたので本当に感動した。 やはり、大きな会社にはそうあれるだけの理由があるのだ、と思った。

こうして、僕は未経験からメガベンチャーで働くエンジニアになれた。今は社会人生活のなかで一番よい状態で働けていると思う。

まとめ

いろいろな会社を渡り歩いてきたが、最後に振り返ってどの行動が良かったのかを自画自賛で考察してみる。

まず、その時その時でそれなりに投げ出さず頑張ってた。毎朝どん底の気分で出社していた事もあったが、すぐには逃げ出さず常にどうすればこの状況を打破できるのかを考えていた。 結局はその会社では解消しなかった事も多かったが、次の会社でその経験がすごく役に立ったりもした。

そして、頑張ってもうまく行かない状況が長期で続くと、見切りをつけていた。 デザインに関しては「好きじゃないな、プログラミングの方が好きだな」と見切りをつけたし、業務上の悩みも、自己努力したり上長に掛け合っても効果が見えないなとなったら会社を変えていた。 実際のところ、悩みの少なくない部分は環境によるものだと思う。 あまり他責にしすぎても良くないが、権限もないただの社員が社内環境に与えられる影響などしれている(自分にとってはつらくても、他の人にとっては良い環境であるという可能性もある)。 それならある程度で見切りをつけて、合う環境に自分を移していくというのも悪い戦略ではないと思った。 実際、転職で正式にエンジニアになれた。転職しなければいつまでもWebデザイナーをやっていたと思う。

ダメ元でチャレンジしたのも良かった。 正直、自分がメガベンチャーの水準に達しているとは思っていなかったが、最後の転職になるだろうことから記念受験的に有名所に応募したのがこの結果に結びついた。

最後に、これが一番大きいと思っているが、僕にはエンジニア適正があった。 ロジックを考えるのが好きだった。 エンジニアに付きものである自己学習にも苦もなく取り組めている。 好きなので頑張れている。

あと、運もよかった。 以上です。

育児中ITエンジニア状況覚書

当方ITエンジニア。子供ができてどう生活が変わったのかを書く。

自分は8年ほどエンジニアをやっていて、5年目で子供が生まれた。
事前に噂で聞いていた通り、自分の時間が以前に比べて全くとれなくなり、長らく悩んだりしていたが今はなんとなく落ち着いているタイミングなので振り返って状況を書き残してみる。

時間確保がめちゃめちゃシビアになった

子供が生まれると自分の時間はほとんど持てなくなる。
自分は遅くエンジニアになったのもあって日々自己学習でインプットを行い、ムラはあるが週一ペースでブログへのアウトプットも行っていた。
そういったものがほとんどできなくなった。
子供が生まれたとき6ヶ月の育休をもらって奥さんの実家に一緒にお世話になっていたときに合間に、DDDやクリーンアーキテクチャを学んだのが、まとまった範囲で時間を注げた最後のトピックである。(育休もらっていればさすがに余裕があった。多分仕事の悩みがないのが大きかった)

日々なにかしらインプットすることで達成感を得ていて、もはやそれがないと落ち着かなくなるような状態になっていた。依存症になっていたように思う。
だから、勉強の時間が思い通りにとれないとモヤモヤして不機嫌になってしまう傾向があった(今もある)。

余暇の時間を諦めて、空き時間をすべて学習に割り当ててみたこともあったがダメだった。
それはそれで精神的に余裕がなくなってしまった。

現在の生活スケジュール

最終的に落ち着いているスケジュールは以下の感じ。

平日:仕事後は何も勉強しない。気分がのれば本を読むくらい。
休日:午前は子供の相手。13:00からのお昼寝の2時間は勉強。夕飯まで子供の相手をして、夕飯と風呂と寝かしつけ準備をし、20:30にベッドに行くのでそれからカフェとかにでかけて1時間30分ほど勉強や作業(お出かけイベントがあった場合は変則スケジュールになる)

以前あった趣味(ブレイクダンス・映画・呑み・漫画・アニメ)はなにもできなくなって、今は平日の何もしない時間にゲームをするくらい。

今はこれで精神的にも落ち着いている。

こうなるにも色々とあった。たぶん仕事が順調でそれほど深刻な悩みをもってないというのもあると思う。
仕事がうまくいってなければ「もっと学ばなければ」と焦っていたと思う。
子供ができるまでに、なんとか一人前のエンジニアとしてのベースラインを超える事ができていたようだ。

発生事象

以下に、育児があることによって発生した事象について書く。

自分のペースで勉強できない

勉強って気分によって「やりたいとき」と「やりたくないとき」がある。
今までなら、気分が乗らなければゲームでもして、気分が乗ってきたら学習する、みたいな事が可能だったが、今は13:00から気分が乗ろうが乗らなかろうが、15:00過ぎになれば自分時間は終了である。

仕事が切りの良いところまでできない

今までだったら仕事していて小さめの解決しなければならない問題に当たったとき、ちょっと残業したりして解消させてから仕事を終えることができた。
今は関係なく19:00には仕事を終えて育児参加せねばならない。ずっと気になって頭にのこってしまう。気分が切り替わらない。

友人への連絡無精が加速する

もともと連絡無精だったがさらに加速してLineの未読が500を超えたりする。
ゆっくり見る時間が確保できない事や、一度やり取りを始めると時間を要求されるため避けるようになってしまった。(学習・趣味を優先させてしまうため)

なにが自分のストレスを下げるのかに敏感になった

育児も仕事もストレスが蓄積する。意識的にストレスを下げる行動をとるように意識するようになった。
自分の場合は空き時間にダラダラしてしまうと「貴重な自由時間に何もしなかった。。」って後悔してストレスになってしまう。
極端な例では簡単な作業チックな仕事や、解決せねばならない仕事の課題に時間を使って解消させることで、翌週の業務の負荷を減らすことで進捗を感じてストレスを下げる行動もとったりしていた。

よくある助言で「少しでも趣味など気が晴れる事に時間を使うようにしましょう」(自分の場合はエンジニア勉強がそれに当たっているのかもしれないが)というのがあるが自分には合わなかった。
趣味的な楽しみを作ってしまうと、例えば面白いドラマを見つけるとか、それに時間を使いたくなってしまう。
可処分時間がそもそも少ないので、大きく時間を食う趣味が入ってくると「あれができない、これができない」の不満が発生しストレスになってしまうのだ。

できるだけ楽しみを持たず淡々と日々をこなす事が良い精神状態をキープするという結論になっている。

時間があってもそれほど有意義に使えてないことに気がついた

2週間ほど入院し、子供に関わらない生活を2週間ほど送ったことがある。
喉から手がでるほど欲しかった自由時間がたっぷり得られたが(病室とはいえ)いうほど満足度は高くなかった。
持て余す時間が増えるだけで、結局勉学とか趣味とか、有効に使う時間はそれほど変わらんかもしれない。ダラダラする時間が増えるだけに思えた。

自分が独り身だったとして結意義に時間が使える気がしなかった。 独り身で楽しむには才能がいるように思う。以前の自分を振り返るに、自分はその才能はなさそうだった。

「仕事を休みたい」という気持ちが一切なくなった

今まで業務が立て込んだりしてストレスが溜まってくると「休みたい!!」という気持ちが溢れてきていた。
しかし今は仕事が休みだからといって育児に休みはない。ダラダラもできず、子供の相手をせねばならない。

我が子との触れ合いはもちろん幸せな時間ではあるが8時間とか付き合うと流石に疲労する。
仕事とどちらが、というのは比較できないが、仕事の日と休みの日の落差があまりなくなった為、休日に対する渇望のようなものはさっぱりなくなった。
たぶん休みがなくなって週休0日になってもやっていける気がする。

対外的にキレイに言うと「子供のために仕事も頑張れる」だが、実質は「仕事休んでも別に楽ではないのでどっちでもいい」みたいな感覚に近い気がする。
仕事すると仕事が進むので、個人的には半分仕事、半分育児だとバランスが良さそう。

子供は生活に変化をくれる

子供はかわいいし面白い。希望だなと実感している。
病院に行くと他人の子供でもいるだけで気持ちが明るくなる。存在するだけで陽である。

人生の後半戦、本来自分の体験する刺激は能動的に取りに行かねばどんどん少なくなっていく。
子供がいると自動的に日々いろんな刺激が得られる。日々が同じことの繰り返しにならない。どんどん生活が変化する。
これってもしかしたらかなり助けられているのかもと思った。
自分は保守的でルーティーンを好むので、子供がいなければあっという間に人生の終わりまで走り切ってしまう気がした。

時間あたりのパフォーマンスをめちゃめちゃ意識するようになった

仕事でもタイミング同じく、なかなか自分でコードだけ書いていればいい立場じゃなくなりだらだらコードを書いてられなくなったので、短時間でバシっと完了まで持っていく剛腕が身についた気がする。

子供の存在によりかなりスパルタ強制的に「大人」にされてしまう、大人養成ギブス

子供がいると、自分を律せねばならないことばかりである。
子供にテレビやお菓子の制限を課すため、自分も駄菓子も好きに食べられないし、テレビも見られない。
わがまま言えないし、我が子に対して常に器が大きな大人でいることを求められる。

いままで体は大人でも精神的には子供だったので「俺だって好きにやりたいよ!」という気持ちが抑えきれずにいたが、三年経ってようやく少し大人になれ始めたようだ。。

かなりスパルタなので脱落してしまう人もいるだろうなと思ったりする。自分も気を抜くといつ脱落してしまわないか不安になる。

これから

上記のように、かなり生活が変わった。ストレスも多い、つらいと思うことも多い。
間違いなく今までの人生で一番難易度の高い部分をプレイしている感覚がある。
それでもやはり子供が居る生活は良いと思える。人生スコープレベルでなんか生きる意味みたいなものをもらえている気がする。(ストックホルム症候群である可能性も十分あるが個人的にはここを追求する意味はない)
色々つらいことも一緒に存在するが、しょうがないかなと思う(つらさもない方がいいけど)

今までも、気持ちの浮き沈みや生活パターンはどんどん変化してきた。
今は比較的安定したが、これもいつまで続くかわからない。

変わったら変わったで、また安定するポイントを探っていきたいと思う。

「プロになるためのSpring入門」読んだ。めちゃよかった。

「プロになるためのSpring入門」読んだ。めちゃよかった。

Springのお作法を覚えた後に読むととても良い

自分は現在SpringBootを使った業務に携わっている。
Javaと共に関わり始めて1年と8ヶ月ほど。

当時のSpringBoot関連で思っていた事は以下のような事だった。

  • なんでアノテーションを書いただけで機能が使えるのかよくわからん
  • 自分が悩んでいる部分がSpringBootの機能なのか、Javaの機能なのか?
  • JavaEEってなんなのか?
  • サーブレットってなんなのか?
  • SpringFrameworkってのもあるらしく、、SpringBootとの関係は?

SpringBootの書き方はなんとなくわかるけど、それ以外がわからん。なんで動くのかわからん。という状態だった。
でもこういった疑問に適した情報は少ない気がした(調べるために必要な知識量に達していない状態だったのかも)。

自分は裏側の仕組みが知りたくて、公式ドキュメントを頭から呼んだり、SpringFrameworkのコードを追ったり、JavaEEについて調べたりをしばらくやって苦しんでいたが、この本があればもう少しスムーズに理解できた気もする。

機能と構造をセットで説明してくれているので裏側がイメージできるようになる

Springではアノテーションを書くだけで機能が追加される。
そんな感じで使うだけなら簡単だけど、個人的には気持ち悪かった。どうやってそれが実現されているかイメージできないと使いこなせない。
この本ではProxyについて説明されていて、このイメージが出来ていないと、例えば自分でnewしたオブジェクトでアノテーションが効かないのを認識できないか、できてもなぜ効かないのか理解できないと思う。

この書籍は機能とそれを実現する構造とをセットで説明してくれている。
公式ドキュメントを読めば全て書いてあるのかもしれないが、公式ドキュメントは文章量もすごいし、とっつきやすいとは言えないと思うのでまずこの書籍を読んでから挑むと良いように思った。

Springに関する書籍はいくつか読んだが、どれも初めてSpringを使う+αくらいの人を対象としているイメージで、サンプルアプリケーションを対象に機能説明が主な感じだった気がする。(このアノテーションをつけるとこれが実現できますよ、みたいな。). これはこれで最初のステップにはすごくわかりやすいと思うのだが、それ以降のステップの書籍が今まで無かったのではないかなーと思った。

SpringBoot @Retryableでリトライがかからない事象にハマった

SpringBoot @Retryableでリトライがかからない事象にハマって時間を消費したので共有

結論

@Retryableアノテーションを付けていても、内部呼び出しだとリトライされない。

以下のような構成で、functionAを外部から叩かれた時、functionBはリトライがかかる想定だったがリトライされなかった。

public void functionA() {
    this.functionB();
}

@Retryable
private void functionB() {
    throw new Exception("例外発生")
}

リトライしたければ外から叩かれるメソッドにアノテーションを付ける必要がある。

以下のコードだと想定通りにリトライされる。

@Retryable
public void functionA() {
    this.functionB();
}

private void functionB() {
    throw new Exception("例外発生")
}

理由

SpringではDIでインスタンス生成を管理できるが、DIで生成されるインスタンスはSpringの機能で一枚ラップされている。
このラッパーによって、アスペクト思考的な機能が提供されている。
@Retryableもその一つで、ラッパーを通してメソッドが呼び出された時、例外をラッパー側でチェックしていて、必要があれば再度実行してくれる仕組みになっていると思われる。

なので、インスタンス内部間のメソッド呼び出しではラッパーが例外を検知できないので、リトライが効かない、という状況になっていたのだと思われる。

アノテーションって付けたら動作すると思ってしまうけど、うまく行かない時のデバッグに時間かかりがち。