はてなブックマーク

はじめに​​ 入社して半年が経ちました。オンボーディング時の話はこちら。 転職活動中に、面接で合宿の話をしてもらったことを思い出します。 マネージャーが合宿で撮った集合写真を見せながら、「エンジニア同士でわいわいやってます！」みたいな感じでざっくりと。 なにをわいわいするんだろうと当時は思いましたが、そういう文化があることだけ伝わりました。 そんな自分が実際に合宿に参加してみた感想を書きます。 NEの文化、会社でやる合宿に興味がある人は読んでみてください。 合宿をやる文化、そのやり方も文化 この合宿より以前、一度だけ経験した会社の合宿というものを思い出してみます。 （NE開発部合宿の話だけ読みたい人は次へ） 新卒入社した会社では2泊３日の寺合宿がありました。合宿は作務と研修を織り交ぜながら行われました。朝と夜は座禅を組み精進料理をいただきます。もちろん魚や肉は食べませんが、味噌かすは視認で

はじめに こんにちは！あっという間に秋が終わり、クリスマスソングが流れる季節がきましたね。 今回は、どうやら多くの人が苦しんでいると聞くレガシーシステムと向き合う話です。 弊チームでは先日、15年来のレガシーシステムを、バグ0でリプレイス&新機能の追加リリースを実施することに成功しました！既存機能の改修ではなく、既存を大きく作り替えつつI/Oも変えるというものだったので、新しい検証方法やリリース手法を組み合わせてリスクを最小限に抑える方法をとりました。 今回は、その予期せぬトラブルを未然に防ぐことができた「安全に倒し切ったリリース」についてお話します。他のプロダクトでも応用可能な方法なので、システム刷新を検討している方の参考になれば幸いです！ なぜ安全に倒し切りたいか 私たちが今回触ったのは、前述の通り15年前から存在する、プロダクトの中でも最もレガシーに類される場所です。以前からパフォー

こんにちは〜！ NE株式会社のはやしまき（@_mkmk884）です🦒 DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。 特に弊社が開発しているネクストエンジンは多くの他サービスとも連携しているため、ネクストエンジン内の仕様変更だけでなく、外部連携サービスの仕様変更もあります。 当時の仕様的にはDRY原則に沿っていたものが、時間とともに保守性を損ない、結果的にDRYではなくなり仕様変更に耐えなくなったケースについて、今回は書いていこうと思います！ DRY原則とは DRY原則（Don't repeat yourself）とは、ソフトウェアの構成や構築手法についての原則の一つで、同じ意味や機能を持つ情報を複数の場所に重複して置くことをなるべく避けるべきとする考え方です

NE株でJavaを書いている谷口(@taniguhey)です。 弊社では、EC一元管理システムである「ネクストエンジン」以外にもいくつかサービスを展開しており、2024年1月にβ版をリリースした「encer mall」（エンサーモール）という仕入れと卸のマーケットプレイスがあります。 8月1日にこれらの2つのサービスを連携するアプリ「encer mall連携 for 卸会員」をリリースしましたので、この記事は「encer mall連携 for 卸会員」（以下、連携アプリ）の開発の裏側を語る記事になります。 大きな泥団子から抜け出すための軽量DDD 軽量DDDを持ち込むにあたって気をつけたこと について書いていきます。 あえて軽量DDDを採用した話 ここでいう軽量DDDとは、ドメイン駆動設計における"戦術的設計"と呼ばれる部分のことです。 ドメイン駆動設計は"戦略的設計"の部分も併せて行うこ

はじめに 早いもので未経験からエンジニアにジョブチェンして約2年が経ち、先日カンファレンス初登壇の機会をいただきました。今回はその時のことについて、なぜ登壇したいと思ったのか、まわりから受けたサポートなどについてお話ししたいと思います。 大吉祥寺.pmとは 吉祥寺.pmとは? 「吉祥寺.pm」は、当初Perlのイベントとして始まりましたが、次第に参加者の多様性が広がり、プログラミング言語や、データベース、設計方法論、キャリア、勉強会開催方法など、Perlに限らず、「それぞれが発表したいことを自由に発表できる場」に変わっていきました。発表枠は毎回必ず全て埋まり、常に新しい人が参加し続け、毎回全く違う発表が行われる、数あるテック系勉強会の中でもユニークなイベントになっていると言えます。 大吉祥寺.pmとは? 通常は、平日の夜に開催される吉祥寺.pmの拡大版として、大吉祥寺.pmは土曜日の終日開

こんにちは、NE会社に勤めますきんじょう(@o0h_)がお送りします。 突然ですが、皆さんは「権限委譲」やっていますか？[1] 「権限委譲」というのが大げさであれば、「自分の持っていた仕事を他の人に任せる」くらいの感覚で、読み替えてみても良いかも知れません。 いかがでしょう？ 業務負荷の集中を避けたり、後進の育成を目的として取り組んでいる人も多そうにも思います。 ただ、実際にやってみると「意外に難しい」とも感じる場面があるのではないでしょうか。 あるいは、「やりたいけどやれていない」という難しさもあるかも知れません。 私はマネージャー業に就いてから、あるいは自分より「若手」の多い職場に所属したことで、色々な場面で「仕事を預ける・任せる・委譲する」という経験をしてきました。 また、上司などの他の人から「仕事を受け取る」側の立場になったことも、もちろんあります。 そんな実践の中で、自分なりに気

はじめに こんにちは。 そろそろ初心者を名乗るのが許されなくなってきた2年目エンジニアです。 前回のテーマはジョブチェン前後に考えていたことでしたが、今回はいちエンジニアとして最近考えるようになったことについて書きたいと思います。 前回の記事はこちら↓ 最近の変化として、なんか色々考えて書くようになったぞ、という自覚があります。 何事もはじめは真似るところから、とよく言いますが、私もエンジニア1年目はひたすら文法覚えゲーでした。とにかく「動くものを書くこと」に必死で、設計とか可読性とか考える余裕も興味もなく、必要性もあまり理解していませんでした。 そんな新米エンジニアも、社内外の勉強会に影響されたり、先輩に初めてのPHPカンファレンス参加へ背中を押してもらったりする中で、良いコードとは、みたいなものを少しずつ考えるようになりました。 というわけでここでは、本当に少しずつではありますが、以前

みなさんこんにちはー！あすみ(@asumikam)です✨夏楽しんでますかー🌞 夏といえば・・・夏休みですね。 大量の休みと共に、大量の宿題と戦ったあの夏・・・あの頃は辛かったですが、今思うと、懐かしい気持ちと「学生」たるイベントに羨ましくなります（...よね？） その中で「課題図書」というものがありました。お薦めの本リストから本を選んで読書感想文書くやつ。 夏休み、図書館に行って自分に合いそうな本を選んだ記憶があります。 ・・・あれ・・・やりたいッ！また、やりたいッ！！(...ですよね？？) ということでー！！NEのエンジニアに「お薦めの課題図書」を聞いてきました🫡 お願いしてその日中に10冊集まりました！素敵👏 そこに、自分のお薦めを3冊追加して、13選を紹介したいと思います！ 「夏休み」気分を味わうために、新しい本に出会ってみるのはいかがでしょうか？✨ 「技術部門」「デザイン部門

はじめに こんにちは！ NE開発ブログリレーもいよいよ大詰めとなって参りました。 本日28日目は、さくらいがお送りします。 以前Qiitaでも書きましたが、私は弊社でも異例となるカスタマーサクセス部→未経験で開発部のジョブチェンを経まして、現在エンジニア2年目に入りたてのヒヨッコです。 今回は、そんな私だから言える「CS時代に開発部に抱えていた不満」、そしてそれが「異動してどう変わったか」を、弊社先輩エンジニアの目を恐れず赤裸々にお話ししたいと思います。 CSと共に仕事をするエンジニアはもちろん、エンジニアの考えてることが分からん！というCSにとっても、この記事が一助となれば幸いです。 なぜエンジニアになったか Q, さくらいさんは、なぜエンジニアになったんですか？ A, 開発部に不満があるのに、何もできない自分が悔しかったからです。 ジョブチェン後、社内外問わず何度もいただいた質問です。

こんにちは、NE株式会社で働いておりますきんじょう(@o0h_)がお送りします。 連続で失礼します！！！という気持ちで、また投稿してみます。(明日からは再び違うメンバーが登場します💪) Intro さて、NE株式会社では今期よりEngineering Managerに挑戦！という人材が、数名現れています。とても嬉しいです。 EMって、何をするか・どうやればいいのか分かりにくいと思うのですよね。かくいう私も、元EMが自分のチームに居てくれた事でかなり助けられましたが、任命された時は「なにこれ〜どうすればいいの〜」と思いながら、何とか自分が出来ることを増やしたり試したりしながらの日々でした。 そんな体験から、「新しく挑戦して見る人には、なにか手助けを出来ると良いな！ 」という気持ちがあります。 そこで、「私に予算をください」と掛け合って、「新任EMに読んでもらいたい書籍リスト」を選定し、物理

こんにちは、NE株式会社で働いておりますきんじょう(@o0h_)がお送りします。昨日は「Tech」でしたが、今日はVPoEの帽子で「Idea」やっていきたいと思います。 それでは宜しくお願いします。 NE社では長い間、個々人で目標を設定する→上長と合意を取る→半期ごとに評価、という流れを採用しています。 2022年度の下半期については、社内のITエンジニア職に関する「どういう目標を設定し、どういう所を評価するか」を私が主導して設計しました。 もう少しだけ正確に記述するなら、全社共通の人事評価についての大枠は人事部門から通達があったので、それを自分たちの職種領域において、どのように肉付けするか？という部分を扱った次第です。 こういう風にしたいなーという方針を打ち出し、私の上長に当たる技術領域管掌執行役員に合意と調整を求めながら進めました。 色々と考えたり、工夫をしたり、願いを込めたりした部分

みなさん、勉強会やってますか〜！ こんにちは〜！お昼時の天気の良さが気持ちいい季節になりましたね🌞 あすみ(@asumikam)です！ みなさんは勉強会やってますか？ 今日は、社内で企画した勉強会について書いていきたいとおもいます🖋 勉強会＋実践会をするに至るまで 私が所属しているPJではスクラムという開発手法を用いて日々開発をしています。 そのスクラムのイベントの中に「スプリントレトロスペクティブ」、つまりふりかえりをやっているのですが、何回もやっていくうちに「メンバー間の技術力の差」に関してのお悩みが目立っているな〜と感じ始めました。 「設計に関して、言われればわかるのだが自分で一から書くのは難しいかも・・・。」 DDDをベースとした設計方針で開発をしており、基本的な設計概念は共有されています。もちろん個人でDDDの本も読むこともしています。ただ、いざコードに落とし込む時にどこに何

こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい