どこまでも奥が深いエンジニア採用。意外と見落としがちなActionとは？｜Ayumi Houta
みなさん、こんにちは。ポテンシャライトの寳田（ほうた）です🙋♀️ 先日このようなnoteを書いてみました。 「いや、エンジニア採用ってやること盛り沢山すぎない？」 これまでのエンジニア採用経験で培った知見（ノウハウ）を時系列に記載した「エンジニア採用の教科書」を書き終えた所感です。 「結局どこまでやり切れば良いんでしょう？」 難題だらけのエンジニア採用ですが、各社課題も異なるため、このようなご相談いただくケースも多いです。 今回はそんなエンジニア採用を ・どんなステップで進めていくと良いのか ・どんな施策があるのか ・どこまでやり切ればよさそうか など施策についてまとめてみることにします✏️ ※あくまで本noteではポテンシャライトが日々採用のご支援をさせていただく中で感じた内容を元に書いておりますので一視点として参考程度にしていただけますと嬉しいです。 それでは、はじめます！ 1.
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c7728c664ddd298cabc00615869a23f196ad5f90/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F2022-220117111455-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
デザイナーとエンジニアを巻き込んだワークフローの改善｜鈴木慎吾 / TSUMIKI INC.
「エンジニアリングに興味があるデザイナー、デザインに興味があるエンジニア Advent Calendar」20日目の記事です。 今年の５月から、社内でクライアントワークのチームから自社事業のチームに異動し、映画・ドラマ・アニメのレビューサービスのFilmarksで有料会員機能のPMを担当しています。 以前はUIデザインやアプリ開発、あるいはその中間的な仕事としてプロトタイプ開発やディレクションなどを経験してきました。 PM業の傍ら、社内のデザイナーとエンジニアの受け渡し部分の改善に取り組みました。その検討過程について紹介します。 要件定義・UIデザイン・開発間のワークフロー改善もともとFilmarks内ではディレクターがGoogleスライドなどで要件資料とGithub Issueをつくり、 デザイナーがSketchでUIをつくりZeplinで書き出したURLをエンジニアに受け渡し、エンジニ
エンジニアがデザイナーといい仕事ができるために頑張ったこと｜seya
この記事は下記の記事に触発されて、逆方向の「エンジニアの自分がどういうモチベーションでどうデザインの勉強をしていったか」というのを語ってみよう！という内容となっております。 あと最近よく「なんでデザインし始めたの？」「どうやって勉強してるの？」という質問をいただく機会が増えてきたので、それへのアンサーともなればなと思います。 なぜデザインを勉強し始めたのか結論から言うと必要に駆られて勉強し始めました。 前職はスタートアップに勤めていたのですが、当時作り始めていた新規サービスに携わっている人はエンジニア2名 + デザイナー1名という少数のチームでした。 ただデザイナーともう一人のエンジニアは他のプロジェクトにかかりきり…なので一時期この新規サービスの開発は私だけという状況でした。 そこで困ったのがデザインがないこと。大まかなワイヤーフレームは握っていましたが、デザインがないのでフロントの仕事
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを本気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。
新卒一年目のときには全く見えていなかった、エンジニアが技術以外で大切にしたい 3 つのポイント - Speee DEVELOPER BLOG
概要 こんにちは Speee エンジニアの中嶋（@nyamadorim）です。 これまで社内の Wiki に、仕事の内容に関する振り返り記事を年単位で書いてきました。これらの記事を改めて振り返ると、個別具体の技術的なこと（例: オブジェクト指向設計）より、仕事や対人コミュニケーションの仕方のほうが収穫が多く、仕事で成果を出す上ではこうした学びこそ大切にする必要があると思いました。 この記事では、新卒 5 年目の私が、仕事の仕方や対人コミュニケーションにおいて学んだことを 3 つに絞って紹介したいと思います。これから紹介するものは、具体的なプラクティスというより、感じてきたことベースでつらつらと書いているのであしからずご了承ください。 対象読者 過去の自分に向けて これから入ってくる新卒エンジニアに向けて ジュニアエンジニアに向けて 新卒当時の筆者のスペック 17 新卒でイエウールの開発チー
ドキュメントが更新されない問題 - Konifar's ZATSU
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
2021 年度新卒エンジニア研修について | MEDLEY Developer Portal
2021-10-122021 年度新卒エンジニア研修についてこんにちは。医療介護求人サイト「ジョブメドレー」の開発を担当しているエンジニアの山田です。 今年の新卒エンジニア研修において、メンターを担当しました。 メドレーでは 2019 年度から新卒採用を行なっており、今年 2021 年度は 5 名の新卒がエンジニアとして入社しました。 例年と同じく 4 月から 9 月にかけて、約 5 ヶ月間の新卒エンジニア研修を実施しましたので、その取り組みを、研修受講者である新卒からの声も交えてご紹介します。 新卒研修の概要今年の新卒研修の最終ゴールは、「メドレーのエンジニアとして、Our Essentials(※) を体現し、顧客へ価値提供できるようになるための基礎を身につけ、経験を得ること」として掲げました。 ※) メドレーの行動原則 メドレーの新卒エンジニア研修では、技術を身につけることだけではな
プログラマの抱いている名前についての誤謬
パトリック・ミッケンジー（Patrick McKenzie）さんのブログ・エントリ、 “Falsehoods Programmers Believe About Names” の日本語訳です。翻訳の公開を快諾してくださったミッケンジーさんに感謝します。 公開: 2012-02-22 Posted on June 17, 2010 by Patrick きょう、ジョン・グレアム゠カミング（John Graham-Cumming）が、正しくない文字が含まれているといって彼のラスト・ネームを受け付けないコンピュータ・システムへの不満の記事を書いていた。もちろん彼の名前に「正しくない」ところなどない。当人の申し出たものが当人を識別するものとしては相応しいのであって、定義からして名前とはそういうものである。このことにジョンは当然ながらいらだったし、そうなるのもきわめて正当なことだ。定義からすれば事実
[フロントエンド] うわっ…Componentの凝集度、低すぎ？ - Qiita
[追記 2021/4/26] Storybookを導入して凝集度を向上させる記事を書きました。 0. はじめに 有名OSSのコミッターから、コピペで動かすマンまで、彼らは等しくプログラマと呼ばれます。10xプログラマという言葉があるように、同じプログラマでもその生産性には天地ほどの開きがあります。 プログラマの生産性は、1968年のSackmanらの研究以来、ソフトウェア工学でも熱い研究テーマの一つですが、未だにプログラマの生産性を測る指標は確立されていません。 一方、広木大地氏は自著「エンジニアリング組織論への招待」で、エンジニアリングを不確実性を削減する行為と定義しました。プログラミング能力を測る重要な尺度として、モジュールの凝集度があります。高い凝集度で設計しコーディングされたモジュールは、見通しがよく、再利用可能で、バグが少ない…つまり不確実性が少ない状態と言えるでしょう。 システ
![[フロントエンド] うわっ…Componentの凝集度、低すぎ？ - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/b1fb1663f9c42a396db97571055b22a8887df2bb/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUUzJTgzJTk1JUUzJTgzJUFEJUUzJTgzJUIzJUUzJTgzJTg4JUUzJTgyJUE4JUUzJTgzJUIzJUUzJTgzJTg5JTVEJTIwJUUzJTgxJTg2JUUzJTgyJThGJUUzJTgxJUEzJUUyJTgwJUE2Q29tcG9uZW50JUUzJTgxJUFFJUU1JTg3JTlEJUU5JTlCJTg2JUU1JUJBJUE2JUUzJTgwJTgxJUU0JUJEJThFJUUzJTgxJTk5JUUzJTgxJThFJUVGJUJDJTlGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1jOGY3Y2RiNjMzMDEyZjBhNzQ5N2QwZmZjOWNjNDhhNQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBha2kyMDImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTJjNjBhMzNhZGYzMmE4NzAwNmU5NWY3YjYxZWJmOGE2%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D946faf220f1f913fef4c68b6624214c8)
Appleを追い出されNeXTを立ち上げたスティーブ・ジョブズを間近に見ていたエンジニアたちの証言
1985年にAppleを追放されたスティーブ・ジョブズ氏が創業した「NeXT」は教育用・ビジネス用のワークステーションのメーカーで、1996年にAppleに買収され、ジョブズ氏がAppleに返り咲くきっかけとなりました。NeXTが開発したオブジェクト指向型OS「NeXTSTEP」はその後のmacOSやiOSの基盤となっています。さまざまな質問に対して専門家が回答する質疑応答サイト「Quora」に投稿された「NeXTのエンジニアはどんな感じで働いていたのでしょうか？ジョブズ氏は普段から従業員と交流していたのでしょうか？」という質問に対して、当時を知るエンジニアたちが回答しています。 What was it like to be a software engineer at NeXT? Did workers interact with Steve Jobs? - Quora https://
メンタルが弱いエンジニアが安心して開発するために気をつけていること - SMARTCAMP Engineer Blog
スマートキャンプで業務委託でエンジニアをしている佐藤です。BOXILの開発を1年3ヶ月前から、沖縄からフルリモートでやっています。 皆さんは、毎日楽しくお仕事できていますか？ エンジニアという職業は労働時間やストレスが多く、IT業界は他の業界と比べて精神疾患にかかりやすいと言われています。 私はもともと自己否定ばかりしてしまう思考の癖があることに加えて、7年前に起業に失敗してメンタルを壊してしまったことをいまだに引きずっていて、日々悩みながら生活をしています。 スマートキャンプは、過労とは無縁で、メンバー間のサポートもよく、これ以上ないくらい私に合った職場です。それでも自分の心の問題で不安になったり、絶望感に襲われたりすることがあります。今回はそうなるたびに書き綴ったメモを、開発中にネガティブな気持ちにならないための技術としてまとめようと思います。 メンタルが強くないエンジニアはこんな気持
『ほぼ週刊キーボードニュース』配信者・ぺかそ＆びあっこの偏愛「自作キーボードは小さなエンジニアリング体験」 - エンジニアtype | 転職type
仕事にとことん没頭する人生もいいけれど、職場の外にも「夢中」がある人生は、もっといい。「偏愛」がエンジニアの仕事や人生に与えてくれるメリットについて、実践者たちに聞いてみた！ パーツを選び、自身で組み立てながら自分好みのキーボードを作る「自作キーボード」。光らせたり、色を変えたりといった見た目の楽しさはもちろん、キーの位置や数を使いやすいように調整するなど機能面の充実も図れることから、今、クリエーティブ業界で働く人を中心に「自作キーボード熱」が高まっている。 今回お話を伺ったのは、自作キーボード作者のぺかそさん（回路設計エンジニア）、びあっこさん（プログラマー）。本業の傍ら、自作キーボードの設計に励みながら毎週日曜日にYouTubeチャンネルにて『ほぼ週刊キーボードニュース』を配信しているお二人に、自作キーボードへの愛を聞いた。 回路設計エンジニア ぺかそさん（@Pekaso） 重くて（物
BASEのチーム開発における設計レビューの取り組み - BASEプロダクトチームブログ
Service Dev所属、サーバサイドエンジニアの宮村です。 現在私は、Service Devのチームに所属し、ネットショップ作成サービス「BASE」及びショッピングアプリ「BASE」の機能開発を担当しています。 BASEでは最近、機能開発の際に設計レビューを行うようにしています。その取り組みについて紹介したいと思います。 開発チームについて BASEの開発チームは、メンバーが増えるに従って専門化する形でチームを分割してきました。 現在、サービスの機能開発を主に担当しているService Dev Sectionは、バックエンドが担当領域を分担して2Group、フロントエンド、ネイティブアプリを担当するそれぞれ1Groupの計4つのGroupから成り、Service Devのエンジニアはいずれかのチームに所属する形となっています。 （組織図について興味を持たれた方は、こちらの会社説明資料を
Chatworkテックリードが“今”の自分に集中してきた理由。Scala×DDDに出会い、サービス改善に生かすまで - Findy Engineer Lab
自分が気づいてなかった資質を、探して、磨く 劣等感に消耗するより、目的志向で考える オープンソースコミュニティへの参画 ドメイン駆動設計とScalaが「点」となる ドメイン駆動設計との出会いと成果 遅延評価的学習法でScalaを習得 Scalaを使ってDDDを実践するスタイルを確立した 実験的に導入して結果が出れば業務での普及も進む 積み上げてきたScalaとDDDの開発スタイル Scalaコミュニティとともに 新しい挑戦で新しい「点」ができ、そして「線」につながる 「いずれどこかで点がつながって実を結ぶだろう」 過去も未来も思い切って手放し、今の自分に集中する こんにちは、Chatworkでテックリードをしている、かとじゅん（@j5ik2o）です。 今年（2020年）で48歳になりましたが、技術に前向きになったというか、本気を出したのは37歳ごろでした。遅いな……（笑）。まぁ、遅い早いが
運用技術者組織の設計と運用 / Design and operation of operational engineer organization
第12回 インターネットと運用技術シンポジウム（IOTS 2019）～運用管理する人”も”報われるシステムの構築を考える～ にて招待講演を行った際の資料です。 概要: https://www.iot.ipsj.or.jp/symposium/iots2019/ プログラム: https://www.iot.ipsj.or.jp/symposium/iots2019-program/
Builderscon Tokyo 2019 で「ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ」というタイトルで登壇してきました #builderscon - assertInstanceOf('Engineer', $a_suenami)
タイトルの通り、登壇してきました。 イベントページはこちらです。 builderscon.io 今回僕はスタッフとしても関わらせていただいたのですが、そちらのレポートは別の記事にしようかと思っており、とりあえず登壇内容に関する話だけしようと思います。 発表資料 資料はこちらです。 2019/09/04 13:26 追記 かとじゅんさんから指摘をもらったのでメモしておきます。 @a_suenami ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャのこのページの前に「DDDのスマートUIアンチパターン」もSoEの目的に合わせて使えばデザインパターンになるという話入れてほしい。https://t.co/qGQmdOs3C2— かとじゅん@MHW復帰勢 (@j5ik2o) September 3, 2019 SoE向けとしては、レイヤーを迂回する話より、スマートUIの話の方が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
監視とは何か ～監視エンジニアのスキルと成長～
Rails for backend of fresh EC platform "Cookpad Mart"
