はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? キャリアの参考になれば嬉しいです この記事は私のキャリアの遍歴の紹介です 自分は様々なエンジニアのキャリアを経験してきました。 人よりも転職の回数も多いかと思います。 今回の転職活動を機に自分のキャリアをふりかえり、今回転職した会社に決めた理由を記事としてまとめたいと思いました。 自由にキャリアを選ぶこと、広く選ぶこと、エンジニアのキャリアを歩まれる人の参考に少しでもなれば嬉しく思います。 この記事は前職を辞めた記事のアンサーソング この記事は前職をやめた記事のアンサーソングです。 それなりに沢山の人に見て頂いたみたいで、入社の記事もQ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 会社を辞めることにしたのですが、そのタイミングで退職ツイートをしました。その反応と感想を書いてみました。 現職のときには、エンジニアの採用担当として退職ツイートの当事者の体験に興味を持っていたのですが、今回は自分が当事者になる数少ない機会だったので、当事者が分かる情報や感情などをお伝えできればと思っています。 N=1の情報ですが、1つでも実例と具体的な数字や意見があると議論の仕方が変わると思うので、1つの事例としてエンジニアの採用担当の人やエンジニアの人の転職など、何かの機会の参考にしてもらいたいです! 退職ツイートをした 対象のツイー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は Engineering Manager Advent Calendar 2023 の21日目の記事になります! EMは何する人なのか? 問題 定期的に話題になる内容で、最近も少し話題になったように思います。 色々な意見があり、人によって「コードを書くべき」「コードを書く必要がない」など、全く違う意見もあります。 場面によってやることが変わるのは確かです。 その時にどのような役割を担っているか次第だと考えました。 この記事ではEMの開発への関わり方としてどんなパターンがあるのかを考えてみました。 理解するにはマネジメントをもっ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は「エンジニア転職」のアドベントカレンダー13日目の記事になります。 むしろ、この記事の内容がきっかけになってこのアドベントカレンダーを作ったと言っても過言ではないです。 次に何をやるかは決まっていないですが、何かの仕事はするので転職というタイトルにしました。 この記事はエンジニアの転職の事例紹介という文脈を借りた、お気持ち表明の記事です。 この記事の概要と結論 昨日、現職の最終出社日を迎えました。 現職の所属は今年いっぱいで、今日からは有給消化中になります。 現職はチャレンジしがいがある、面白い会社でした。 日本の医療課題を大

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は「エンジニア転職」のアドベントカレンダー10日目の記事になります。 経験の場や成長をするための「環境の重要性」 今までの経験を振り返って考えると、様々な会社を経験しましたが、1つの会社に居るだけではとても経験できなかったと思うことがたくさんあったと感じました。 同じことを繰り返すだけの毎日やチャレンジしない毎日を過ごせば楽かもしれませんが技術的な成長は止まってしまうと感じます。技術的な成長を望むのであれば、同じ会社であっても、定期的に違う環境にへのチャレンジが必要なのだと思います。 また、会社によって得られるものが違うため、環

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらの記事は エンジニア採用 Advent Calendar 2021 の15日目の記事になります! 最近は技術広報の推進もしていまして、カケハシのアドベントカレンダーもやっております。 過去に自分の面接官としての気持ちから、候補者へ期待することをQiitaで書いていました。 見たいエンジニアの職務経歴書の書き方 エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた 今回は面接官として自分が行っていることをお伝えすることで、エンジニアの面接官としての準備の参考にして頂いたり、候補者の体験(Candidate Exp

同じ関数を適応することが出来ます。 文脈にかかわらず、関心のみに対して関数を作ると、あらゆるStringの値を操作したい時に関数を適応することが出来ます。 これがFutureの場合はどのようになるでしょうか? Future[String] すでにわかっていると思いますが、同じです。 非同期処理であっても結果を取得する瞬間と中身の値を操作するものが綺麗に分解されているために、全く同じ関数で利用することが出来ます。 文脈制御の実装こそがモナド 文脈と関心 文脈処理と関心処理の分解されています。 ここで文脈制御しているオブジェクトこそがモナドです。 ListはmapメソッドやflatMapメソッドの実装がされており、Listのイニシャライザなどがモナド則に従って実装されています。Optionなどもそうです。 そして、このあらゆる文脈を結合して利用できるようにルール化されて、文脈制御の実装が入って

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから5年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは?と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから5年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは?と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主にWeb系の中でもそれなりに大きな会社の中で見てきた

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 序文 このエントリーは Engineering Manager AdventCalendar 2018 の 11日目の記事になります。 筆者とエンジニアリングマネジメントの関わり 現在、サーバサイドエンジニアのエンジニアリングマネージャという肩書きでエンジニアリングマネージャをしています。 現職ではエンジニアリングマネージャはピープルマネジメント中心とした役職です。 前職でもエンジニアのマネジメントするポジションで、技術に関する部分のプロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントなどの全ての責任を持っており、チー

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書いた動機 なんとなくエンジニアの面接官が求めている情報と面接者の提供する情報にズレを感じることがあるなーと思っているので書こうかなと。 自己PRが上手くなくて損してしまうのはエンジニアとしては本分では無いかなと思うので、そのあたりがうまくない人はしっかり準備が出来たらいいなと。 あなた誰? 某Web系上場会社に勤務するエンジニアです。 基本は現場で働いていますが、採用面接などは人事と一緒に現場エンジニアの一人として出たりします。 採用面接歴は2年以上。 注意事項 現在の会社の立ち位置から見た場合での限定した方向から見た場合の

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書くにあたっての動機 モブプロがどういうものか、詳しい導入事例などは他の方々が色々発表してくれています。 技術なきマネジメントの衰退とその対策 [モブプログラミングという働き方] (https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number-devlove) 「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という講演をしてきた #CEDEC2018 しかしモブプロをガッツリ導入した話が多いので、既存チームの

システムを作る時は限られたリソースがあります。 その中で出来ることを定義するにはこの4つの相関関係をしっかり意識しながら判断をしなければなりません。 スコープ(機能数) コスト (リソース) 品質 スケジュール この4つについてはアジャイルサムライの本でも荒ぶる四天王として紹介されています。 どれか一つを固定すれば、どれかが犠牲になります。 どこかを重視すれば、全てをこなすことは出来ません。 沢山の機能、高い品質、早いスケジュールで作ろうと思えば、沢山のエンジニアを集め一気に作るしかなくなります。 その場合はコストが掛かるのは明らかです。 コストを抑えて、スケジュールを早くしたいと考えれば品質が悪くなるか、沢山の機能は作ることはできず、本当に必要な機能を作ることしか出来ません。 品質が犠牲になる場合は、正常に動くことだけでなく、変更に弱かったり、無駄にシステムサーバ費が掛かったり、レスポン

KPTとは チームメンバ全員を集めた振り返りの作業です。 1週間〜4週間に1回行います。自分のところでは変化も大きく、改善スピードをあげたいため1週間に1回行っています。 KPTはアジャイル開発の中でもいちばん重要なプラクティスだと私は考えています。 なぜなら改善活動の問題をチームメンバ全員から吸い上げるための重要な機会だからです。 K(Keep) よかったこと いい出来事 P (Problem) 問題、課題 障害になっていること 認識を合わせたいこと T (Try) やること、やりたいと思ってること 技術的チャレンジなど の3つをポストイットに記述して上げます。 なんとなくにならないKPTは Problemには何らかの対処や共通認識が絶対に必要です。 いくつもProblemが出てくると、重要だけど大変な問題を適当に決めて、そのKPTの会が終わってしまうことがあります。 これは絶対に駄目で

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アジャイル開発が流行る中で、一番初めに流行りが来た手法です。 最近ではすっかりスクラムの方が流行っていますが、スクラムよりも組織論のよりも開発チームに近いので、最初に導入したり、考え方を理解するのには向いているかもしれません。 基本的にアジャイル開発なので、スクラムの手法の中にも似たようなものも多くあります。 原則 4つの価値 コミュニケーション 単純さ フィードバック 勇気 の4つに最大の価値を置く。 これは他のことに価値が無いということではないので 選択を迫られたときにどちらがこの価値基準に近いのか? ミーティングなどで小さなリスク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニアの次のステップへの勉強法 ↑ こちらの記事に色々はてブコメント頂いてありがとうございます! 自分にとってこんなにはてブもらうの初めてで、足りなかった部分を書こうと考えたのでこの記事にしました。 ちなみに私が選んだ道はこちらになります。 つまりスペシャリストの道は若干外れたかなと思っています。 どんなプログラミング言語が来ても大抵書けそうかなって ある程度オブジェクト指向系の言語を覚えると、思ったものを大抵書けると思います。 その周辺言語は似ているので、どんな言語が来てもある程度キャッチアップして書ける自信になります。 でも、ソ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的

スクラムマスタとマネージャー まだスクラムをやったことがない人はスクラムマスタがマネージャのようなものかと思うこともあるかもしれません。 たまにスクラムマスタと名乗りながらマネージャの動きをしている誤解している人も居ました。 そこで、スクラムマスタとマネージャの違いに観点をおいて、書いてみようと思います。 プロジェクトマネージャ プロジェクトマネージャとは何をする人でしょうか? タスクを振り分ける人。では、ありません。これはミッションでは無いです。 エンジニア上がりのマネージャでマネジメントの勉強をしない人は、これしか出来ない人がいますが、これはマネジメントの仕事の一部でしか無いです。 エンジニアとマネジメントの知識はまるで違います。 エンジニアが新しいプログラミング言語、フレームワーク、ライブラリを学ぶように マネージャも新しい手法、チーム管理、人を動かす観点を学ばなければなりません。

ふと自分がベテランエンジニア(おっさん)になってしまった、、、と感じたので書いてみる。 Javaとか普通に使われてると思うし、makeもC系だと普通だとおもうし、メッチャ偏見を入れて書いていることをご了承ください (笑) バージョン管理ツール 新人 Gitしかやったこと無い SVN聞いたことあります CVS?CSVじゃなくて? おっさん SVNやCVSって言うのがあってだな VSSって知ってるか? ファイルサーバで上書きされることとかあったよー サーバインスタンス 新人 ポチポチ (AWS、GCP、さくらVPS) Herokuでいいっすか? GAEでいいっすか? おっさん 納品まで時間が掛かるから、早めにスペック確定して発注しないと サーバルーム行ってくる ソコのおいてあるのが開発用サーバだから電源消しちゃダメだよ プログラミング言語 新人 PythonとScalaなら触ってました Swi

使ったことあるものは"◯" プロジェクト利用経験があるものには"☆"を付けてます。 特に評価という感じではなく、プロジェクトやチームにフィットしたものを選んでもらえたらと思います。 プロジェクト管理ツール Redmine ☆ pluginを色々追加することが出来る カンバンのフォントが小さくて、タスクが一度にたくさん見れる カレンダーなども連携してスケジュールも同時に見れる ガントチャートにも表示できる そろそろ時代を感じる スプリント方式で使うとバックログ画面は若干使いづらい JIRA ◯ プロジェクトでは使ったことない、古いバージョンで少し触ったことがあるだけです。 大きなプロジェクト用なのが分かる感じで階層化が凄い 権限管理などもしっかりしている エピックバーンダウンという機能が凄く使ってみたいのだけど、触ったバージョンが古かったみたいで無かった(秀逸っぽいきがする) 入力項目が多く

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? エンジニアの転職メモ を読んで、刺激を受けたので書いてみました。 非常に共感しました! 自分的にちょっと気になるところ+αを書こうかなと。 書かれたことは会社的な方針ではなく、個人としての観点です。 自分誰よ とある企業で採用の一次面接に呼ばれたりする現場のエンジニアです。 Javaエンジニアです。Scalaもたまに書いてました。 転職回数は片手では足りないくらいの回数をしています。 最近はエンジニアマネジメントの比重が多く、ほとんどコード書いてないです。 コードは書いていませんがレビューや調査では読んだりします。 アーキテクチャ、フレ

JavaもJava8でstream処理やラムダ、Optionalの型などが追加されモダンなプログラミングが幾つか書けるような機構が適応されてきました。 しかし、Javaで書くプログラマーはモダンな実装する文化は浸透しているのでしょうか? 今回はモダンな実装の仕方として、「Immutable Programming」と「nullの扱いについて」について書いてみようと思います。 前提 Webアプリケーションサーバを実装する時を想定しています。 もちろんネイティブの実装のときにも適応される部分が多いです。 Java8の書き方で説明します。 Immutable Programming(イミュータブルプログラミング)とは 凄く簡単に説明すると、変数に再代入しないということです。 全てfinalを付けてプログラミングするようなものですね。 まだ、やったことがない人はそんなことが出来るのか?ということを

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今日はスクラム開発の中の役割のプロダクトオーナーについて語ってみようと思います。 プロダクトオーナーはマネージャではありません。 スケジュールも考えますが、製品の品質として 必要な機能や重要な機能を定義すること 不要な機能や利用頻度の低い機能を開発させないこと が重要なミッションです。 一番やってはいけないのはどの機能も重要という結論です。 これはどれも重要ではないと言っているのと同じです。 必ず開発する機能は1から順番に優先順をつけることが必要です。 これがなかなか難しく、かなり情報が必要で、判断と決断を何度も迫られる作業です。 開発

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術の話ではないので若干Qiitaに書くような記事では無いような気がしますが、QiitaのAdvent Calendarなので書いてしまいます。 経歴概要 専門学校卒 転職回数6回 出向型下請けSIerからWeb系?へ Javaエンジニア アーキテクチャを決めるリードエンジニア経験 全くコードを書かないエンジニアマネージャ経験 エンジニア採用の面接官 現在36歳 転職について思うこと 一般の人より若干転職回数が多いと思うので、そこから思ったことを書いてみたいと思います。 まず、エンジニアとして技術が好きでそれをやっていきたいのか、安定し

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アジャイル開発での何度も行われるプロダクトリリース アジャイル開発は早いサイクルが回っているチームでは1週間のうちに何度もリリースを行います。 リリースを何度も行うメリットは 開発中も常に動く状態のアプリケーションが確認できること 壊れたときにすぐに気がつけること 変更箇所を他の人もすぐ取り込むことが出来ること マネージャや顧客に対して常に進捗をデモという形で見せれること 他にも色々 このようなものがあります。 そもそもビッグバンリリースはテストも大変ですし、問題が起こったときに、どの箇所に問題があるかを調査する範囲を調べることが大変で

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 技術的負債とどうやって戦うか - Qiita こちらを読んで、思ったことを書いてみようと思いました。 記事についての感想 ほとんど同意です! 凄くまとまっていて読みやすかったです。 ここに書くのは引用記事の別視点での自分の解釈になります。 技術的負債はいつ生まれるか? 残念ながらアプリケーションのコードを書いた瞬間に技術的負債は生まれます。 どんなに綺麗に書いても、レビューをしても消えることはない闇です。 つまり技術的負債は生み出さないようにするものではなく、コントロールするべきものなのです。 そして、引用元タイトルでは戦う!となってい

Next Javaな言語とかと比べてみてCeylonの立ち位置を比べてみる。 #近しい立場の言語 Kotlin (コトリン) たぶんCeylonと一番近そうな立ち位置なのが Kotlin かなーと思う。 マイナーっぽさとか、書き味とか。 といってもScala寄り。 ただこちらはバージョンM3と言うことでメジャーバージョンになってないですね。 バックに居る会社はIDEAで有名なJetBrainなのでしっかりしてそうです。 Xtend (エクステンド) で次に近いのが Xtend 。 Ceylonの前にこれが出たときも自分はピコーン!ってなりました。 Javaに超近かったので。好みかも!って。 ただ近過ぎてメリットが薄い印象でした。 ラムダ式も 「|」の記号なので流行の言語の矢印っぽい方が良かった、、。 ということでドキュメントを少し読んだだけで触らず、、。 良くも悪くもJava + α って