はてなブックマーク

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の情報ですが、１つでも実例と具体的な数字や意見があると議論の仕方が変わると思うので、１つの事例としてエンジニアの採用担当の人やエンジニアの人の転職など、何かの機会の参考にしてもらいたいです！ 退職ツイートをした 対象のツイー

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日目の記事になります。 経験の場や成長をするための「環境の重要性」 今までの経験を振り返って考えると、様々な会社を経験しましたが、１つの会社に居るだけではとても経験できなかったと思うことがたくさんあったと感じました。 同じことを繰り返すだけの毎日やチャレンジしない毎日を過ごせば楽かもしれませんが技術的な成長は止まってしまうと感じます。技術的な成長を望むのであれば、同じ会社であっても、定期的に違う環境にへのチャレンジが必要なのだと思います。 また、会社によって得られるものが違うため、環

はじめに の参加記事になります。 個別の技術ではなく、エンジニアの成長のステップで読むと良い本の紹介 エンジニアとして成長していくときに、個々の技術を深く理解し使いこなしていくことは必要ですが、個々の技術を選ぶときにもどんな成長ステップがあるかを理解することも重要です。 実装をするという範囲をエンジニアの中心なのはありますが、実装以外の部分を理解するとその技術が最大限に活きるのかを理解するには周辺についても理解していく必要があります。そこで、実装を始める前の構造のパターン、実装を進めるエンジニアの環境などを知ることで、もっと効率的な開発が出来るようになるのかを理解していきたいけると良いと考えています。 この記事では私が経験した中でより良いWebシステムを作るという観点に立ったときに、広く理解しておくと良いと感じた本を紹介します。 これからエンジニアリングでどのような勉強をすればよいかを考え

こちらの記事は エンジニア採用 Advent Calendar 2021 の15日目の記事になります！ 最近は技術広報の推進もしていまして、カケハシのアドベントカレンダーもやっております。 過去に自分の面接官としての気持ちから、候補者へ期待することをQiitaで書いていました。 見たいエンジニアの職務経歴書の書き方 エンジニアが転職する時に考えることを採用面接官をしてる立場から書いてみた 今回は面接官として自分が行っていることをお伝えすることで、エンジニアの面接官としての準備の参考にして頂いたり、候補者の体験(Candidate Experience)向上に少しでも繋がればと思います。 ここに書かれている内容は会社として全体で行っていることというよりは、自分としてカスタマイズしている部分も多くあります。面接官次第では違った進め方がされることもあることをご了承ください。 面接官としての経歴

今回の目的 今回はモナドの厳密なルールより、なぜ使うのか？どう使えるのか？を簡単なところを数学表現なしでまとめてみるのが目的です。 まだまだモナドを完全に完全理解した！ とはいい難いのですが、現在までの理解を書いてみたいとおもいます。 関数型プログラミングに関する熱い話はこちらの記事が参考になります！ 関数型言語のウソとホント 関数型を考える上での前提 - プログラミングの作用と副作用 プログラミングの入力と出力は関数の引数と戻り値がメインです。 「作用」とは、その引数に対しての戻り値のことです。 Webアプリケーションサーバでの作用の考え方 HttpのリクエストのデータをHttpのレスポンスデータに変換する処理に過ぎません。 Scalaで表現するとこんな関数定義です。 val func : HttpRequest => HttpResponse Scalaでは => は関数の定義を示しま

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前置き 某上場Web系の企業で中途社員のサーバーサイドエンジニアの書類選考や採用面接官などをしています。途中に転職もしましたが面接などの採用に関わり始めてから５年経ちました。 以前に面接についてはこちらの記事を書きました。 エンジニアを面接するときに面接官が本当に知りたいこと 書類選考もしていて、欲しい情報が足りない。本当の実力はもっとあるのでは？と思うこともあり、今回は採用側の立場から、もっと見たい職務経歴書の書き方について書こうと思います。 全てのパターンに当てはまることはなく、主に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? この記事を書くにあたっての動機 モブプロがどういうものか、詳しい導入事例などは他の方々が色々発表してくれています。 技術なきマネジメントの衰退とその対策 [モブプログラミングという働き方] (https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number-devlove) 「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という講演をしてきた #CEDEC2018 しかしモブプロをガッツリ導入した話が多いので、既存チームの

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

KPTとは チームメンバ全員を集めた振り返りの作業です。 １週間〜4週間に１回行います。自分のところでは変化も大きく、改善スピードをあげたいため１週間に１回行っています。 KPTはアジャイル開発の中でもいちばん重要なプラクティスだと私は考えています。 なぜなら改善活動の問題をチームメンバ全員から吸い上げるための重要な機会だからです。 K(Keep) よかったこと いい出来事 P (Problem) 問題、課題 障害になっていること 認識を合わせたいこと T (Try) やること、やりたいと思ってること 技術的チャレンジなど の３つをポストイットに記述して上げます。 なんとなくにならない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? アジャイル開発が流行る中で、一番初めに流行りが来た手法です。 最近ではすっかりスクラムの方が流行っていますが、スクラムよりも組織論のよりも開発チームに近いので、最初に導入したり、考え方を理解するのには向いているかもしれません。 基本的にアジャイル開発なので、スクラムの手法の中にも似たようなものも多くあります。 原則 ４つの価値 コミュニケーション 単純さ フィードバック 勇気 の４つに最大の価値を置く。 これは他のことに価値が無いということではないので 選択を迫られたときにどちらがこの価値基準に近いのか？ ミーティングなどで小さなリスク

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? 今日はスクラム開発の中の役割のプロダクトオーナーについて語ってみようと思います。 プロダクトオーナーはマネージャではありません。 スケジュールも考えますが、製品の品質として 必要な機能や重要な機能を定義すること 不要な機能や利用頻度の低い機能を開発させないこと が重要なミッションです。 一番やってはいけないのはどの機能も重要という結論です。 これはどれも重要ではないと言っているのと同じです。 必ず開発する機能は１から順番に優先順をつけることが必要です。 これがなかなか難しく、かなり情報が必要で、判断と決断を何度も迫られる作業です。 開発

技術の話ではないので若干Qiitaに書くような記事では無いような気がしますが、QiitaのAdvent Calendarなので書いてしまいます。 経歴概要 専門学校卒 転職回数６回 出向型下請けSIerからWeb系？へ Javaエンジニア アーキテクチャを決めるリードエンジニア経験 全くコードを書かないエンジニアマネージャ経験 エンジニア採用の面接官 現在36歳 転職について思うこと 一般の人より若干転職回数が多いと思うので、そこから思ったことを書いてみたいと思います。 まず、エンジニアとして技術が好きでそれをやっていきたいのか、安定した生活がしたくて、そのために技術を使っていきたいのかという人生の価値観の前提で大きく目指す会社の方向性が違います。 技術が好きでそれを伸ばしたいと考えるならばWeb系 安定した生活ならばSI系 の方が概ねあっていると言えると思います。(もちろん例外の会社もあ

アジャイル開発での何度も行われるプロダクトリリース アジャイル開発は早いサイクルが回っているチームでは１週間のうちに何度もリリースを行います。 リリースを何度も行うメリットは 開発中も常に動く状態のアプリケーションが確認できること 壊れたときにすぐに気がつけること 変更箇所を他の人もすぐ取り込むことが出来ること マネージャや顧客に対して常に進捗をデモという形で見せれること 他にも色々 このようなものがあります。 そもそもビッグバンリリースはテストも大変ですし、問題が起こったときに、どの箇所に問題があるかを調査する範囲を調べることが大変です。 バグの修正に掛かる時間の大半を占めるのがバグの調査時間になります。 半日以上かかって調査ししたバグが、１行のコード修正で終わってしまうこともよくあります。 細かくリリースをすることで、壊れた場合にそのコミットの変更の中におかしなところがあったと気がつく

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