新卒で入社した会社を退職しました。
先日の7月3日が、新卒入社した大阪の某ITベンチャー企業の最終出社日でした。
2017年の9月より内定者アルバイトにて開発に携わらせていただくようになり、翌年2018年の4月に入社しておよそ3年弱の間、同社初めての新卒エンジニアとしてお世話になっていましたが、7月末で退職となります。（現在有給消化中）
私自身の就活についても含めて、せっかくですので少し書いてみようと思います。
自己紹介
現職について
大阪でとある分野で有名な某ITベンチャー企業です。 一つ代表的なサービスを主軸に、そのサービスと同じ分野関連するサービスを幅広く展開しています。
現職との出会い
翌年に専門学校の卒業を控えた2017年、学生の間からずっと就活で失敗しないようにと考えて行動をしていた私は、 積極的に就活イベントに参加し、そこで知り合った良さそうなITベンチャー系を志して就活していました。
ですが、自分の実力等色々足りておらず、行動開始は早かったのにも関わらず就活はことごとく惨敗してしまっていました。（約15敗）
そんな中、2017年のPHPカンファレンスに学生スタッフとして参加した際の懇親会の席にて、 偶然同席になったエンジニアのNさんと出会ってお互いにPHPでDDDを実践してるという共通点があり意気投合し、「うちの会社はどう？」と冗談半分で声をかけていただきました。
後日、そのNさんの会社のHPを見た際に感じた雰囲気や制度、その他全体的に私が就職先の必須条件として考えていた内容のすべてを満たしていたことと、 懇親会で話したNさんと一緒に仕事をしてみたいと感じていたため、面接を受けることにしました。
早速応募し、手応えしかなくて逆に心配になるような1次面接を受け、その後2次面接という名のランチ会に呼ばれてその場で内定通知書をいただきました。
こんなにすぐ内定を頂けるなんて、ご縁というのは本当にあるんだなぁと思ったことを覚えています。
内定者アルバイト
当時、学校でDDD+Laravelでチーム開発をしていたり、別のIT企業のアルバイトにてDDDを使った開発をしていました。 そういったことが相まって、内定者アルバイトに入ってすぐに携わることなった管理システムのDDDについても、早い段階で大まかなシステムの構成等は比較的早く理解できてDDDというものの強力さを感じることが出来ました。
一方、管理システムのフロントまわりはvue/vuexで作られており、こちらの方は一切の知見がなかっため課長やNさんに概念自体の理解をする時点からフォローをしていただきつつ開発をして行きました。
その後、管理システム周りのタスクをやっているうちに入社の季節となりました。
入社後のビジネス研修
入社した後の新卒研修では、会社として新卒を取り始めた初年度ということもあってか 実際の内定者アルバイトで感じていた社内の雰囲気とは全くそぐわないような、
いわゆる悪名高い、大声出して挨拶したり、目標を大声で言ったり、大声で暗記したことを発表するタイプの研修合宿に行かされました。（一応今年で最後だったらしく、来年からはもうないそうです。）
めちゃくちゃビビってたんですが、行った結果としては この年齢になってあんなに大声出す機会も無いので新鮮だったのと、
心の中で講師の方が言ってることに関して「それは一理ある」「いやそれはないやろ」「それさっき言ったのと矛盾してるやん」とツッコミつつ聞いてたので洗脳されることもなく、逆に楽しめました。
実際行きたくなかったし、行く前に危惧していた通りの内容でしたが、終わった後は「まぁ、一生に一度ぐらいは経験してもよかったかもな」とか思っちゃったので、ああいう研修は良く出来てるなぁと思います。
一番のメリットは、研修を受けると時間が経っても同じ研修受けた人と研修の話をネタにして盛り上がれるので、 研修内容を真に受けないスタンスで行くのはアリかもしれないです。
そういった新卒共通のビジネス研修が一ヶ月ほどして終わって、開発部に配属になりました。
開発部配属後
組織として開発部というものが発足したばかりだったことと、これまでのアルバイト中でも 「やまごんは新卒ではあるけど、もう実質中途みたいなものだからｗ」と冗談まじりで言われていた通り、本当に新卒PG用の研修やOJTなどは特にないまま案件にアサインされて開発に戻っていきました。 （元々中途向けのエンジニア研修用なども特になく、やりながらわからない箇所は聞きつつ覚えるスタイルでした）
それからは、比較的モダンで長く育てているDDDで作られた管理システムから、作ったらほぼそれきりのバッチ処理が多い社内システム、PHP5.3で作られたレガシーなものまで、色々な規模感のプロジェクトに携わらせて頂けました。
特に社内システムについては、これまで学んできたDDDなどの汎用性の高いものプログラムではなくシンプルかつ処理に特化したものをスピード感を求められた状態で作るといったものだったので、非常に良い経験になったと思います。
開発部という組織としては、上長の方々が積極的に組織の改革などをしようというスタンスで居ていただけたので、 長年の社内のコミュニケーションツールがChatworkのみだった状態から開発課等のITリテラシーの高いチームではSlackを使うようにしたり、esaなどのサービスの導入検討、 当たり前かもしれませんが、古い技術などには囚われず新しい技術の導入を推奨するなどをしていただけました。 また、他のエンジニアの皆さんも、私のような新卒の意見でも真摯に聞いていただけたので非常に居心地は良かったです。
開発部に対してやったこと
そんな私が入社し、一部まだレガシーな状態が残っていた開発部に対しておこなったことですが、 アルバイトで入社した当時は、gitを使ってPRでレビューをする文化はあっても、approvedの機能などを使っていない状態だったので、使ってレビューするようにエンジニアの方々に働きがけをしたり、
入社後もPRでのWIPの使い方、gitのコミットのprefixなどのgit周りのお作法についてもどういった所が良いのかなどを社内ドキュメントとしてまとめて共有し、最近ではその作法に沿って使ってもらえる人が増えてきていた状態でした。
また、社内には外部の勉強会に参加する方や、技術記事の共有等を社内でする方がほぼいなかったので、社内でもそういった文化ができてほしいと思い、
私自身が積極的にそういった勉強会に参加してその結果を共有したり、情報収集をして良いと思った技術記事などを社内にシェアするようにしていました。
また、Slackを導入する際にSlack経験があるエンジニアがほぼ居なかったので、僅かなSlack経験者の方と、Slackで分報を使うルールを作ったり、積極的に治安の良いemojiを登録してリアクションに使うことでChatworkとの違い（リアクションだけで簡易なコミュニケーションが取れる）などをやってみせつつ利便性を上げ、Slackの導入の滑り出しをサポートしたりしていました。
他にも、入社した2018年の10月頃、来年週者予定の未経験の新卒エンジニアの子がインターンに来ることになった際に、 どういった事をやるのか決まっていなかったりしたので積極的に研修や教育の進め方についてのアイデアを出したり、 未経験エンジニア向けのPHPのアルゴリズムテストを少し作ってみたり、gitの研修的な講義や、GUIしか居ない中サーバー上でgitを使う時に苦労しないようにCUIでgitを使えるように教えたり、実際に業務に入ってからのフォローなど、
私自身が新卒という立場ではありましたが、次年度の新卒に対して色々やったり（やらせてもらったり）していました。
転職の理由
一番の理由は、転職する時期が来たと思っていたタイミングで、自分の仕事に対する考え方と合っていて魅力的だと思っていた会社とご縁があったことにほかならないと思います。
実際、現在の会社は働く先としてはプラマイで考えるとマイナスはあれど一応プラスが上回るような感じだったので、今回のご縁がなければもう少し現在の会社にいることになっていたと思います。
会社自体のマイナスに感じていた部分についてざっくり言ってしまうと、企業のやっていることや社長について不透明に感じる部分が多くあり、いくら開発部として上長や自分が頑張って良くなっていったとしても 組織の上は変えられないという事を感じてきたというのも理由の一つとしてありました。
詳しくは下手なトラブルを避けたくないので飲み会などに誘っていただくか、直接DM等で質問していただければある程度は答えます。（多分）
転職のきっかけ
転職のきっかけですが、入社のきっかけともなっていた憧れの対象でもあったエンジニアのNさんが、私の入社から半年後にやめてしまったことや、その後に憧れの対象として定めた先輩方が次々と転職していってしまい、 一緒のチームで開発して色々な議論等をして勉強させてもらっていた先輩が今年の1月時点で転職すると聞いた時に
「ついに自分も転職の時期が来たんだな」と思ったことです。
そしてその先輩が転職する先の会社が偶然前々から自分が知っていて気になっていた企業でもあり、現在の会社に対して思っている不満点も解消でき、よりよい環境で成長が望めそうだなと先輩から話を聞いて思いました。
そこで、その先輩に頼み込んで取り次いでもらうようにお願いをして面接を受けさせていただくこととなり、結果として非常に運良く縁あって内定をいただく事ができました。
やはり、自分自身が漠然と憧れる事ができるようなエンジニアの方々と一緒に開発したり、周りのエンジニアからも刺激を受けつつ与えつつといった環境が羨ましく感じていたこともあり、ドキドキもしていますが非常に楽しみです。
これから
8月1日入社になりますので、約一ヶ月有給消化タイムです。 できるだけ有意義に勉強などをしていきたいとも思いますが、ここまで長い休みはめったに無いので存分に楽しみたい気持ちもあってせめぎ合っています。
土日は用事で埋まってきていますが、平日は基本的には時間がありますので気軽に飲みに誘って頂けると非常にうれしいです。
新しい会社では実際に顔を合わせて開発するのを推奨している風土ではあると聞いていますが、コロナ禍が収まるまでは在宅継続と聞いているので果たして新天地のオフィスに出社できるのはいつになることやら・・・
転職エントリに関しては転職して落ち着いてから気が向いた時に書こうとおもいます。
おまけ
これまで機会がなかったので公開したことがなかったのですが、 こういった記事を書く時は必須だと思ったのでAmazonの干し芋リストおいておきます。
https://www.amazon.jp/hz/wishlist/ls/ETC5HEKC7DJP?ref_=wl_share
Mix Leap Joint #26 - U30限定 LT会 ~勉強会の第一歩を踏み出そう~個人レポ
お久しぶりです、約2年ぶりに意識が高まってきたためブログをしたためます。
私が普段よく参加させてもらっているYahoo大阪のMix Leapにて、U30限定のこちらのイベントが開催されました。
非常に意識どころか向上心から何から高い方々ばかりで思わず高いハードルをくぐりそうになりましたが、なんとか頑張らねばという使命感も生まれたので簡易的にですがタイムテーブル順に感想等をまとめようと思います。
書いてて半分行ったぐらいから疲れてきてふわふわした感想しかないけどご容赦
「Mix Leap Joint について」& 乾杯
私の学生時代からの友人の44氏による今回のイベントの説明＆挨拶でした。 今回LTの登壇者として参加しなかったのは、普段登壇しない人がするという名目があったそうです。
余談ですが、自分がダイエットに成功し彼が幸せ太りしたことで、体重の差が2～3kgしかなくなっていることが判明し、 なんとも言えない気持ちになりました。
自分がゴリゴリに痩せたのは間違いないけどやっぱ筋肉つけたい 筋トレは最強のソリューションだしな
「枠に囚われないインプット」
内容
石山 怜生（株式会社Gemcook）
勉強会でもたまに名前を聞くGemcookの新卒の方の発表でした。 タイトルの 枠に囚われないインプット というのは、先輩や上司が言う「やってみたら？」という内容に対して取り込むことで、様々なメリットがあったそうです。 具体的には石山さんはフロントエンドエンジニアであるもののAWSの勉強をして資格をとったり、デザインの勉強をしたことで、 「AWSの資格持ってるし、手伝ってもらおうか」といわれるようになったり 「デザインの勉強してるならこの部分のデザインお願い」といったように仕事を頼まれるハードルが下がり、仕事の幅が広がったそうです。 また、勉強をしたことで興味の幅が広がり、勉強会などでも学んだ知識で話が盛り上がり、コミュニケーションの幅も広がり今まで見たことがなかった世界も知れたとのことです。
一つのことを極めるのも大事だけど、いろいろなことに手を出すと結果的に自分の力になる
感想
GWが重なったからとはいえ、未経験でAWSのソリューションアーキテクトに受かるのはすごいとしか言いようがなかった・・・ ただ、話を聞いてて自分が基本情報や応用情報を受けたときに友人と問題を出し合ったり、居残って勉強していたりしたのを思い出したのでそういうモチベーションが上がる事があれば可能なのかなとも思いました。
とりあえず自分もAWSのSAAを勉強しようと思います。
スキルアップを宣言して人生が変わった話
内容
西村 爽 （株式会社Gemcook）
同じGemcookの方の話で、まとめると自分追い込み駆動勉強的な話でした。
AWSの話題があってもわからない、知識を有ることを証明して先輩に認められたいという思いからAWS SAAを受けることを勢いで宣言したそうです。
勉強したことを毎日ツイートして習慣化して学んでいき、取得できたことでバックエンド側の人とも話せるようになったそうです。 今年中に・三ヶ月中に○○をやります！と宣言して自分を追い込んですることが大事
感想
確かに自分自身の中で「やらなきゃいけないこと」にするだけでモチベーションややらざる終えない気持ちになってできるというのはわかる（今ブログ書いているのもそういう気持ち） でも追い込むのは周りの環境が落ち着いてないとだめだし、そこに注力できる環境があるのが大事だよなーーーとかいう言い訳が生えそうになってしまう そこをどうにかしなきゃなぁと思いました
新卒一年目時代の軌跡と今
内容
角田 拓己（フリュー株式会社）
業務以外でのスキルアップ方法についての話 コミュニティを立ち上げて運営することで、いろいろな人から知識を吸収できて、繋がりもできる
登壇駆動勉強・登壇することだけ決めて、発表するために勉強する→色々なメリット メリット - 勉強する時間を強制的に取ることができる - 登壇後の会話が生まれる - 間違いがあったらしてきしてくれたり、別解を教えてもらえる - 人に言わないと、自分の方法が最善と勘違いしちゃうので、いろいろな人から意見を貰う必要がある
デメリット - 発表が迫ると切羽詰まることがある（前日に資料を作る）
感想
登壇してる人って基本的に登壇駆動○○やってる気がする、どうしてみんなそんなに自分を追い込むんだ・・・
まぁエンジニアの美徳に怠惰ってあるので、つまりはそういうことなんだろう
新卒で立ち上げたばかりの支社に配属希望した話
内容
廖 子揚 （freee株式会社）
関西支社に志望した理由 初の死者開発拠点だから成長のチャンスが多い 立ち上げのフェーズを自分で決めれる 急成長を実感できる
slackのtimesチャンネルなどもつかって リモートワーク力をアップ
- 対面と変わらないコミュニケーションの量を維持
- レビュアーが意識して丁寧にかく
- そのPRを達成したい目的
- 変更の意図
- 確認してほしい場所
インプットの時間の確保 朝の時間をインプットの時間としてブロック インプットしたのをチーム内で勉強会を開催 開発計画はインプットの時間を確保した状態でする
幅広く技術を知る
- バックエンド以外のフロント、インフラの知識をインプット
- 相乗効果
- 未知のものに対する抵抗と偏見がなくなる
- 0からプロダクトを作れるようになる
感想
リモートワークの難しさとともに、最近はそこまで実際に会わなくてもなんとかできるようになってきている（技術・仕組み的に）んだなぁと思いました
また、懇親会でもお話させてもらいました。 大阪拠点の軌道も乗ってきて、大阪チームだけでなにかのプロダクトをしようとしているだったり、リモートワークで気をつけること、同じFreeeの方で関西のGoコミュニティの発起人？の方がいたのでGoの言語仕様の魅力とかも聞いたりしました。
「スキルアップを感じる２つの瞬間 挑戦と教育」
内容
斉藤 洸紀（株式会社はてな）
テーマがスキルアップなので、一年を振り返って自分が成長したときの２つのキーワード 挑戦と教育
挑戦
- 新しいことにチャレンジ
- 難しいことにチャレンジ
- 他の人がやりたくないこともチャレンジ
- 他の人が持っていないスキルを得れる
最近の挑戦
- 転職
- やったことなかったAndroidをやることになった
挑戦は連鎖する
感想
何事も挑戦で、どんな分野の挑戦であっても、結果的に自分の力になるんだなと
学ぶことは大事だ・・・
「社会人からのスキルアップ戦略」
内容
榎原 聖太（サイボウズ株式会社）
感想
ただ失敗するのではなく、失敗をデザインすることが大事だそう
「知識0、経験0、学歴0から這い上がってきた道のり」
内容
橋本 尭明（株式会社エイチームライフスタイル）
「好きこそものの上手なれ」
感想
スライドだけでもいいのでみんな見てほしい
もうなんか時間がないとか言い訳する逃げ場をなくされてしまった めっちゃくちゃすごすぎた ここまで技術のことを好きに思えてやっている人がいるんだから、世の中技術だけじゃ勝負なんかしたら勝てないよなぁっていう思い なにか別の武器も持たねば
この技術を手にいれたらこれができるかも、とワクワクしてスキルアップのモチベーションが湧くらしいけど、 それが今技術じゃなくてダイエットを気に筋トレ方面に思考が逝ってしまっているので、 筋トレモチベーションが高いです。
更に最近アニメとかゲームをやる受動的娯楽の生活から、会社の部活でスポーツしたりサバゲー行ったりとか私生活をアクティブな方向に充実させる方向にシフトして楽しくなってきているので、 どうにも技術の方が疎かになり勝ちになってしまっている・・・つら・・・スクワットしょ・・・
「1年でモダンなフロントエンドに追いついた話」
内容
www.slideshare.net
自分で勉強しないと取り残される。 やったことないことはとりあえずQiitaへ書きまくり、とにかく使った技術をアウトプットしておく 生地を加工とすると自ずと勉強することになる
ESLintの rulesを読むのが良い
感想
やったこととか、使ったことをアウトプットするのは大事としても そもそもなにかしらやらなきゃ・・・
「社内でActive Book Dialogueをやっている話」
内容
佐藤 哲朗（ヤフー株式会社）
常に学び続ける必要がある - 技術の流行り廃り - チームも変わる - 使う道具も変わる
担当の章が前後に依存してる場合 →依存関係がないのしかわからない
ABD の人数 初めての場合 6人ぐらい？ 少ないと読む量が増える
感想
Active Book Dialogueという読み方は初めて知ったけどいいなぁと思った参考にしてみたい
でも参考にしても会をできるほどモチベーション高そうな人がいない
「大規模リファクタという名の作り直しをした話」
内容
松井 真子（ヤフー株式会社）
エンジニアとして一番スキルアップを実感した出来事
何が良くなかったか 全体を俯瞰するの応力がなかった →そのタイミングでは最善でもゴールが見えていなかったので変な方向に →業務外で勉強をしていなかった
自分たちの方針を決めるまで相談をしつつした
作り直しをしてみて - 知識の必要さを身にしみていっぱい本を読んだ
先輩に実装のチェックだけじゃなく、こうしたほうがいいんじゃないかという提案ができるようになった
感想
開発をスタートする前に全体のゴールを俯瞰して確認しておくことは本当に大事だよなぁと ○○をやらなきゃいけない→ △△とXXだと△△って方法でいいですかね？ だと聞かれた側も、条件無いで最善は教えてくれるけど、 全体を通してそれが本当に最善かはわかっていないまま答えることになる。 だからまず根本的に何が大事で、どうなるのがゴールなのかを明確にした上で、それのアプローチの仕方をどうするか決める必要がある と、最近業務でレビューとかを受けて学んできた気がする。
業務外で勉強するのはエンジニアにとって死活問題
全体的な感想
いろいろな話を聞いてモチベーションがあがりつつも、勉強しなきゃいけないというプレッシャーすごすぎてなんとも・・・
とりあえずこの一年でダイエットはかなり頑張って改善できてきた（継続中）ので、今度は私生活方面の充実（娯楽という意味ではない）を主軸にAWSのSAAの勉強や、ついに業務でサーバーサイドKotlinに触れられる可能性が大いに高いので頑張ろうと思います。
※なにか記事内に問題等あれば対応いたしますので、Twitterなどにご連絡等よろしくお願いいたします。
【WIP】これまで関わったDDDについて振り返る
この記事はITC Advent Calendar(2) 16日目の記事です
はじめに
2017年5月当時にアルバイトしていた会社で、初めて新規案件をDDDを用いて上司と共に設計とPHPでの開発を行い、
それがきっかけでPHPでDDDで社内システムを開発している葬儀系ベンチャーに内定&現在進行系でインターンでそのシステムを開発中、
また、学校で行っているチーム開発でもDDDを用いて開発しているので、DDDの本質というより、各々のプロジェクトで行われているDDDで良かった点など書いていきたいと思います。
①アルバイト・初めてのDDDと社内システム
プロジェクト仕様
- Laravel 5.4
- PHP 7.0
- 開発期間 2017年5月〜2017年9月
- 某受託メインのIT企業の社内システムの設計と開発
- 社内でしか使われない、業務で使っているあるものを管理するシステム
2017年5月頃に当時の上司から社内システムを新規で開発したいという事で、上司をドメインエキスパートとして設計段階から取り掛かることになりました。
ユビキタス言語などの洗い出しやドメインモデル図作成から始まりましたが、
初めて知ったDDD自体を勉強しながら、更に0ベースからの開発だったため、何度も上司と打ち合わせを重ねてドメインを洗練された形へ何度も変更させつつ設計していきました。
上司の方はDDDのプロフェッショナルではないものの、何度かDDDの開発経験があったため過去の実装方法などを元に、Laravel且つPHPで実装する場合について煮詰めながらコーディングへと進みました。
このプロジェクトでのEntityは、LaravelのEloquentでsaveされた時に付与されるサロゲートキーをEntityのIDとして使うため、
OnMemory上で作成した段階ではIDが存在せず、Repositoryでsaveした時に永続化した上でIdが付与されるという実装方法を取っていました。
（EntityはOnMemory上でも一意でいなければ行けないので、実際はよろしくない設計らしい）
②学校・チーム開発でのWebサービス
プロジェクト仕様
- Laravel 5.4
- PHP 7.0
- 開発期間 2017年8月〜2018年2月終了予定
- 学校の作品展を目指して作成している
- チーム内にDDD経験者は2名(自分を含めて) 全員で勉強しながら進める予定
- 現在(2017/12/16時点)も開発中(やること山積み)
私の学校では2年生から、後期授業でチームで開発をする授業が始まります。（システム開発演習）
今回の開発では長期開発や継続で運営するようなものを作るわけではないものの、チームのリーダーもアルバイトでDDDをやった経験があり挑戦してみたいと言っていました。
また、自分としても更にDDDを勉強していきたいと思っていたので、学生最後となる今回のチーム開発でDDDに挑戦することとなりました。
③内定インターン・新社内向けWebシステム
プロジェクト仕様
- Silex
- PHP 7.0以上
- Vue.js + Vuex
- 開発期間(Join) 2017年9月〜2018年3月終了予定？
- 自社サービスの社内向けWebシステムのリニューアル
- 現在(2017/12/16時点)も開発中(新機能追加と機能修正)
2017年7月15日に行われたPHPカンファレンスの懇親会にて、偶然近くにいたエンジニアの方とお話することとなり、その方の会社でもDDDでPHPを使って開発しているとのことで意気投合しました。
その際に就職についてもお声をかけて頂き、その後なんやかんやでその会社に内定を頂いて現在インターンとして、そのDDDのプロジェクトにJoinして働かせて頂いています。
その結果初めて実際の業務で使われ続けるために開発されているDDDのプロジェクトを見たので、テンションが上がりました。
大きく違う点としては、システムの規模がやはりとても大きいことと、フォルダ分け含め共通部分などが非常に細分化やコンポーネント化されていて、ぱっと見ややこしいものの一度理解すれば更新や修正などが楽なようにできていて、流石だなぁと感じました。
一般的？にDDDのプロジェクトのディレクトリ構造的としては、レイヤードアーキテクチャとしてよく言われている以下のタイプがあります。
- プレゼンテーション層
- アプリケーション層
- ドメイン層
- インフラストラクチャー層
そして、このプロジェクトでも名前が少し違うもののやはり、大まかには同じようなディレクトリ構造となっていました。
詳しい内容などまた気が向いた時にかきます。
