米国のスタートアップやビッグテックといえば高給取りやワークライフバランスとセットにしてレイオフについて語られることが多い。レイオフする側についてはあまり出回らないので、米国のスタートアップで働く開発チームのマネジャーの立場から書いてみたいと思う。 まず、レイオフにも種類がある。大きく分けて組織改編に伴うものと、個人のパフォーマンスないしは行動規定違反によるものがある。今回は個人のパフォーマンス起因のレイオフについて書く。 個人のパフォーマンスによるレイオフの場合、通常は事前に何度かフィードバックがマネジャーからある。ビッグテックの場合はPIPという再トレーニングプログラムがあるが、昔いたテックカンパニーでは自分の周りでPIPを受けている人を見かけたことがなく、その後は中堅 - 小規模なスタートアップにしか勤めたことがないので、詳しくない。 ともかく、フィードバックの後に改善が見られない場合

こんにちは、最強のチームを作るためにスラムダンクを読んでいるグラです。 2ヶ月前に25歳を迎え、デザイナーとしてミドルなのかジュニアなのか曖昧な狭間で日々生きています。 ここ3ヶ月間ぐらい、会社の案件獲得のためにコンサル営業に入っているんですが、コンサル営業ってビジネスやデザインの理解から、フロントコミュニケーションにドメイン知識まで、求められるスキルセットが多くて毎日忙しくしてます。 なんでコンサル営業までやろうと思ったかというと、デザイナーって「赤ちゃん」が多いと思ったからなんですよね。 それも含めて、今から本題の話ができればと思います。 ※ この記事では主観的な表現がとても多く書かれていますが、あくまで個人の感想と見解になります。 デザインに依存するデザイナー達赤ちゃんって何かについて説明したいんですけど、デザイナーってものづくり的で職人的な側面が強いし、想像以上にビジネスのことを知

When I joined Facebook we didn’t have managers. When we are deep in the feedback period of the performance cycle we may imagine such a world as a utopia but I assure you we are wrong. I would have benefitted immensely from more management. That period of my career holds my greatest professional regrets. And when I finally was assigned a manager years later that person didn’t have any more experien

TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって

仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた 「プロジェクトマネジメントの基本が全部わかる本」を執筆し、ご自身もプロジェクトマネージャーやプロダクトマネージャーとして23年経験を積んできた橋本将功さん。 橋本さんは、セミナーや著書でプロジェクトマネジメントについての知見を発信されていますが、今回 Agend であえてお聞きするのは「専門のプロジェクトマネージャーがいないグダグダになっている職場で、どう仕事を回していくか」。 「うちの会社は仕事を回すのが下手」と感じている方にこそ読んでいただければと思います。

はじめに 入社したてホヤホヤ、24新卒エンジニアのふっちーです。新卒として、社内にフレッシュな風をお届けすることを生業としています。 2023年の10月から、サポーターズで内定者アルバイトとして受け入れていただいていました。この記事は、内定者アルバイトの最終日にサポーターズで過ごした半年の振り返りとして、社内のブログに投稿した記事になります。入社前に気づくことができてよかった学びが沢山あったので、もしよければご覧ください！ サポーターズでのお仕事 内定者アルバイトではサポーターズのTech Studio（エンジニアチーム）に配属となりました。 初めて直接お会いする日、私が見つけやすいようにオフィスでサンマのぬいぐるみを振り回してくれていたOJT担当が強く目に焼きついています。 サポーターズで大事に飼育されているサンマ 具体的な仕事の内容については、私が週2勤務であるため大がかりなタスクに携

こんにちは、unnameの代表取締役の宮脇啓輔です。 普段から重要だなと感じたことや、自分なりに思考したものを伝えようとXで投稿しているのですが、その中でも反響が大きかった投稿をさらに肉付けして発信しようという試みで記事化しております。 「頭の回転が速い」とは「累積思考量が多い」ことだと思います。「過去に似たようなテーマについて考えたことがある」から、すぐに自分の意見が出てくるし、回転が速く見える。考えたことがないと、その場で思考してしまい、遅く見える。そういうことだと思っています。… — 宮脇 啓輔 / 積極採用中 / unname (@keisuke_unname) March 21, 2024 この投稿がかなりいい反響をいただいたということもあり、投稿をベースに、もう少し肉付けして解説してみます。 「頭の回転が速い」の正体はなんなのか「頭の回転が速い」と見える人は、実際は「累積思考量

こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。

英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効／無効状態の確認」や「検証に成功した場合の身元の保証（アクセストークンの発行等）」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお

ひとり会社を経営してこの4月から第6期になる。期間として次の12月で創業5年になる。先日、その5年近くの経営の中での失敗からのふりかえりについて書いたところ、多くの人たちに読んでいただいたので嬉しい。 この記事で引用した次の経理の書籍についても多くの人たちが読んでくれているようにみえる。それ自体は素直に嬉しいものの、約4年前の記事であるため、当時の私が起業に関して無知だったり、よくわかっていなかった内容もいくつかある。そこで現時点でのアップデートを含め、いま私が起業するならこうした方がよかったと、自身の経験からわかったことを整理してみる。 起業時に夢も希望もない私自身、先にあげた過去の記事を読み返していて、よい大人がひどい理由で会社を辞めたものだと思う。一方で世の中には既存の社会構造や組織に馴染めない人もいる。自分で会社を経営することは自己責任ではあるが、社会に対して馴染めないなにかを少し

『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に

最近「ああ、これ前職でも前々職でもやったことあるなぁ」という仕事があった。データエンジニア(やその関連職種)として働き始めて約5年、3社でフルタイムとして働いてきて「このスキルは業界や組織規模が変わってもデータエンジニアとしてスキルを求められることが多いな」と感じたものをまとめてみることにした。棚卸し的な意味はあるが、特に転職用などではないです。 前提 どこでも必要とされたスキル データマネジメントに関する概要レベルの知識と実行力 セキュリティや法令に関する知識 事業ドメインに関する興味関心 他職種とのコミュニケーション能力 コスト管理 / コスト削減のスキル ソフトウェアエンジニアとしてのスキル DataOpsやアラートのハンドリング能力 分析用のSQLを書く力 古いテーブルやデータパイプラインを置き換えていくスキルや胆力 あるとやりやすいスキル 関連部署の動きを何となく把握しておく力

TypeScript の型システムを活用して、本番のアプリケーションにおける実用的な問題を解決することを目指しています。Effect-TS は、以下のような特徴を備えています。 並行性（concurrency）：Fiber ベースの並行モデルにより、高いスケーラビリティと低レイテンシを実現 コンポーザビリティ（composability）：小さく再利用可能なパーツを組み合わせることで、メンテナンス性、可読性、柔軟性の高いソフトウェアを構築する リソースの安全な管理（resource-safety）：処理が失敗したとしても、安全にリソースを開放する 型安全性（type-safety）：TypeScript の型システムを活用した型推論と型安全性に焦点を当てている エラー処理（error handling）：構造化された信頼性の高い方法でエラーを処理する 非同期性（asynchronicity

「何を言うか？」「どう言うか？」「いつ言うか？」 こういった悩みを抱えているビジネスパーソンは多いのではないだろうか。 メンバーとの1on1でどこまでフィードバックすべきか悩むマネージャー。 クライアントへの報告会でどこまで細かく話すべきか悩むコンサルタント。 事業部門への報告会でどこまで細かく話すべきか悩むITエンジニア。 我々が「何を言うか？」「どう言うか？」「いつ言うか？」に悩んでしまうとき、 以下の観点が混ざってしまっているように思う。 ＜相手のShouldとWant＞ 相手が知らなくていいこと、興味のないことを伝えようとすると空回りをしてしまう。 相手が知るべきこと（Should） 相手が知るべきでないこと（Not Should） 相手が知りたいこと（Want） 相手が知りたくないこと（Not Want） 「相手」の4観点を組み合わせると「相手は興味を持っていないけど、立場上知っ

定期的に見かけるSAPを入れても碌なことがないみたいなやつ。現場の人や中間管理職の感想としては全く正しいが、本当にERPがゴミならば（主にグローバル大企業で）これだけ普及しているわけもないわけで、なにかしら使う側に問題があるのかもしれません。 マジレスするとSAPというかERPは給料の高い人の生産性を上げるもので、給料の安い人の使い勝手とか優先度低いし、末端にたくさんのデータの入力を要求するから。別になんの矛盾もない。 https://t.co/F2J5TdeWXw — (っ╹◡╹c) (@Heehoo_kun) March 21, 2024 私が新卒入社した会社でも当時のメインフレームをSAPに置き換えるみたいな話があって、コスト削減で大変な工場でそんなものは入れられないみたいな議論があったのは覚えています。その時のラインマネージャーの一人が、「ERPは給料が安い人を大量に使って給料が高

本イベントでは、人事・労務担当者がおさえておくべき2024年の法改正の概要とその裏側を読み解いていきました。カゴメ株式会社 常務執行役員／カゴメアクシス株式会社 代表取締役社長 兼 経営管理部長の有沢正人氏とKKM法律事務所代表の倉重公太朗氏が登壇し、法改正の裏側や今後の人事課題について議論が交わされました。本記事では、カゴメで実施されているジョブ型雇用についてお話しされた内容をお届けします。 カゴメ・有沢正人氏が語る、雇用や働き方の変化 倉重公太朗氏（以下、倉重）：ではここからは対談コーナーということで、カゴメの有沢さんに来ていただいております。（有沢さんは）大人気ですけど。 有沢正人氏（以下、有沢）：いやいや。 倉重：自己紹介をお願いしてもいいでしょうか。 有沢：よろしくお願いします。私は今のカゴメが4社目で、もともとは銀行員でした。銀行では公的資金をいただき国有化されまして、みなさん

3ヵ月~半年くらいで普通の社員と遜色ない人もいる。数年やっても向いてないんじゃないかというくらいできない人もいる。少しずつ着実に成長している人もいる。 新人教育を1〜2年10人くらいやっているのだが、いったい何が違うんだろうとずっと思い続けてきて、ようやく自分なりにまとまってきたので書いておく。 前提新人とはプログラミング経験年数2年以下くらいのWebエンジニアの初心者を想定している（自称初心者ではない） 今勤めている会社では大学生インターンや未経験のような新人を積極的にとってきた。自分はお節介を焼くのが趣味であり、勝手に教えてたら（知識をひけらかしてたら）思ったよりも成長してくれる人が何人かいたし、逆もまた然り。 最近はAWS業務やrailsを書きつつ新人の育成が仕事になっている。 僕自身は所々で教えてくれる人はいたものの、ちゃんと「教育」をされたことがないのでよくわらないし、コーチング

自分が会社員だった時の転職活動、必ずしも毎回全部できていたわけではないけど、一応こういうステップを意識していたなぁ、というノウハウのシェア。 ①1度に1社だけを受ける。エージェントではなくリファラルで紹介者を見つける。2社以上を同時に受けるのはちょっと大変かなと考えていた。 ②紹介者に社内の課題を聞いて、イシュー度（本当に解く価値があるか？）やCan（自分のスキルや経歴に合う領域か？）とのマッチングを確認する。 ③カジュアル面談やリファラル食事会で社内課題やカルチャーをヒアリングする。なるべく違う立場のメンバーに来てもらって、見え方や意見のズレを探り、正確な状況を把握する。必要に応じて事前にNDAを締結する。 ④外部事例をリサーチしてその会社にマッチする解決案を考え、提案資料にまとめて送る。入社後に期待される動きの1つを先に実施し、③の参加者が投下した時間コストはこの成果物でお返しとする。

きっかけは本当に偶然だったが、自身がOrganizerを務めているShinjuku.rbを再開できることになった。 ご縁があり、Shinjuku.rbを再開できることになりました。わいわいしましょー！ Shinjuku.rb #90 再開プレDrink Up! https://t.co/qgNL5tB5Ld #shinjukurb— とれびー (Hiroaki Ninomiya) (@treby006) February 29, 2024 3/28に開催した再開プレDrink Upの場で、即興であるが自分の考えや今後の話をしてきた。 端的にまとめると今後のコミュニティ運営をハマちゃん(@hama8383)や南谷さん(@yuki3738)を旗振り役とした新体制に移行したい旨と、同時に現在のOrganizerであるたださん(@tdakak)と私は今後サポーターに回りたい意思を表明した。 コミュ