私の職場のADHDのAさん（私の後輩）が辞めてから職場が明るくなった。 スムーズに仕事が回るようになって、みんなイライラしなくなった。 なぜ私がAさんがADHDかということを知ってるのかというと、Aさんが飲み会で突然カミングアウトしたからだ。 Aさん「実は自分、ADHDで…」 静まる周り。 Aさん「あ〜、一般人の方は知らないですよね。ADHDというのは…」 その後AさんはADHDについてとても詳細に説明してくれた。 しかしその場の人の反応がイマイチだったのADHDについて知らなかったからではなく、他の人が話している最中に話し始めたからという理由が大きいことに気づいていないだろう。 みんな先ほどの話が気になっていたはず。少なくとも私はそうだった。 Aさんのカミングアウトを受けて私は正直そうだろうなと思った。思い当たるフシしかなかった。 Aさんはとんでもなく視野が狭く、ありえないほどミスが多く

TechRAMEN 2024 Conferenceで発表した「すばやく実装するための戦略とテクニック2024年版」のスライドです。 https://fortee.jp/techramen-24-conf/proposal/ce8ce247-ffd3-4458-842d-ef3df3b5bf6c …

こんにちは、趣味でコーポレートエンジニアをやっていますyamashuです。 タイトルの通りかなり昔の話になるのですが、勤怠打刻の課題解決についてそういえば社外へ向かってアウトプットしていなかったなと思い、この度したためている次第です。 社外と接点が多い営業の社員が弊社での打刻の方法をたまたまお話したりして、その話を聞いた会社様から「話を聞かせてほしい」とヒアリングをいただくことも最近まで何度かありました。 そのため、もしかしたら同じ悩みに直面している方がいらっしゃるかもしれないので、1つの解決策としてやったことを書いておこうと思います。 課題 🤔 勤怠管理SaaS（弊社だとAKASHI）を使っているが、打刻（出勤、退勤）しても本人以外にはその結果が見えない、わからない。 そのため、コミュニケーションツールのSlackでも「出勤したよ〜」となにかしらの報告がチームメンバーに対して必要となる

大吉祥寺PM 2024

mimizuk @mimimizuk 災難すぎる。2,3回しか会話したことない取引先でもメンションにさんはつけずにチャットできる環境にいる身からすると、単に相手の情報リテラシー低めなだけな気がする。 あとTeamsってメンションに続けて文字打つとメンション消えなかったっけ…？改行してさんつけるのも変な感じしてやりたくないよね x.com/m4quick/status…

目次 目次 はじめに 1章 課題の認識とZuora導入の決断まで 販売管理システムの課題 何を最初にやるべきか 実情を知る 理想像を固める 何を作り、何を作らないか どのSaaSを使うか 2章 Zuora導入設計 Zuoraプロジェクトチーム体制 Zuoraを知ろう！ Zuoraプロジェクトにおいて何を開発するのか Zuoraの管理画面を使うか、それとも内製で作るか 新設機能のモック作成 食べログとのマッピング 3章 Zuora移行 データ移行 データ検証 突合バッチによる検証 データプールの副産物 最終的なシステム構成 データ切り替え 4章 Zuora運用 財務突合 Zuoraへの切り替え Zuoraでの運用開始 5章 結論 最後に はじめに こんにちは！ 食べログ開発本部飲食店システム開発部でマネージャーをしている新井です。 2018年に食べログに入社し現在は販売管理チームに所属してお

おひとり様最高という風潮がしっかり根付いてきた昨今だけど、実際におひとり様で老いて死んでいったサンプルはまだ少ないと思っている。 なぜなら、おひとり様最高という風潮は最近出てきたもので、それを謳歌している女性はまだ寿命から程遠いところにいるからだ。 ロールモデルもいないのに、何がどう「最高」なのかはわからないがとにかく今「おひとり様最高」という状態の女性は増えている。 しかし独身の女性は35歳になると少し様子が変わる。自分の縄張りがはっきりと存在していないタイプほど特に。 地方出身で一人暮らしをしていて恋人やパートナーのいない女性は職場を居場所、縄張りとするために働く。 職場で自分は必要とされている人間であることを証明するために激務も耐える。 でも、実際には男ほどは働けない。男ほど責任やプレッシャーのある仕事は出来ないし、与えられない。 だからどうでもいい瑣末なことを重要であるように誇張し

ワイ、国内では結構大きいインターネットサービスを提供する会社にいる。 この数年、一部で競プロ出身者を持て囃す傾向があるが、それは全く幻想であることを伝えよう。 ワイの会社に来た競プロ出身者(2人いる)には、システムのパフォーマンスが出てない部分を高速化してもらったり、なんやかんやで複雑化してしまった箇所を改善してもらったりなどを期待していた。(やけに抽象的なのは特定を防ぐためで、実際はもっと我々の課題は明瞭である。) その競プロ出身者は、プログラミングの腕は一見一流だと思う。高学歴で学生時代から競プロに親しみ、何色が云々だとか、いくつかのコンテストで入賞したりしていた。パズル的な問題を解くには確かに強い人材だと思う。しかし、企業で使うにはあまりにカスすぎて、「企業に出張ってきて迷惑をかけるんじゃなく、部屋にこもって競プロやってろ」と思うに至った。 まず何よりも第一に、コードの品質があまりに

リンク はてな匿名ダイアリー 競プロ出身者の使えなさは異常 anond:20240624084844を読んで思ったこと。2番目以降は正直良くわからないが、一点目についてはわかりみしかない。うちはメガベンチャーで内製アプリ… 599 users 13 AI要約 競技プログラミング出身者の問題点について、以下のようにまとめられます。 1. 学生時代の競技プログラミングの実績を過剰にアピールする傾向がある。実務では学生時代の実績よりも、与えられたタスクを超える成果を出すことが重要。 メンテナンス性の低いコードを書く傾向がある。処理の効率性ばかりを重視し、可読性の高いコードを書くことができない。指摘しても聞く耳を持たない。 コミュニケーションに問題があり、他のメンバーを萎縮させることがある。的外れなコードレビューをしたり、関係ないリポジトリにPRを投げたりするなど、チームの空気を悪くする行動が見ら

増田、40代男性、現在非上場だけど大手企業でエンジニアやってる。 何回か転職してたり他社との話で狭い世界だけどエンジニアが居着く会社の条件が自分なりに固まった 競プロが居ない（外に出さなきゃ影響無し）とにかく見下す人多い。あと努力教で効率厨。フリーランスや部署の奥地で最低限の人間とのみ触れ合わせるようにすれば良い。 変に普通のエンジニアと絡ませるとフルボッコにして数名病む。 1人だけにしてお任せとか言わない（しない）初回だけ打合せに一緒に出て以降は自走させる人。管理職に多め。ペアプロとか関係なく2人以上のチームでの心理的安心は大きい。成果も失敗も割ろう 通知表査定しないこれは会社レベルだが、いつでも成果出せるエンジニアなんて僅かなのに3を中心に良い悪いを評価するのは無慈悲。当たり前のように下は上は結果出してないくせにと思う。上のショボい成果を時勢のせいにしたら末期 （スタートアップやベンチ

こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに レビューや会議で誰かが「詰められてる」様子、心にきますよね。自分がやられるのはもってのほかですが、周囲で発生するだけでも心がすり減ります。。 特に、何か問題が発生したときや、参加者間の誤解が解消できないときに「詰め」が生じがちです。 質問する側の、焦りや不安から「なぜ？」「どうして？」「つまり？」と質問マシーンになってしまう気持ちも理解できるのですが。 問い詰めてしまい心理的に不安全な状況に陥ると「ミスを隠そう、自分が責められないようにしよう」と回避する力が働きはじめ、結果として「正確な状況がわからない」「適切なアクションが取れない」といったチームとして重大なリスク

ミスや失敗をなくすため、ヒューマンエラーに厳罰を下すとどうなるか？ 一つの事例が、2001年に起きた旅客機のニアミス事故だ。羽田発のJAL907便と、韓国発のJAL958便が駿河湾上空でニアミスを起こしたもの。幸いにも死者は無かったものの、多数の重軽傷者が出ており、一歩間違えれば航空史上最悪の結果を招いた可能性もあった。 事故の原因は航空管制官による「便名の言い間違い」にあるとし、指示をした管制官と訓練生の2名が刑事事件に問われることになる。裁判は最高裁まで行われ、最終的には2名とも有罪となり、失職する。判決文にこうある。 そもそも、被告人両名が航空管制官として緊張感をもって、意識を集中して仕事をしていれば、起こり得なかった事態である [Wikipedia:日本航空機駿河湾上空ニアミス事故] より 芳賀繁『失敗ゼロからの脱却』は、これに異を唱える。 事故は単一の人間のミスにより発生するので

本書ではソフトウェア開発の工程で起こりがちな42の失敗事例を取り上げ、その原因と回避方法を解説しています。 特に新任リーダーやチームで開発に取り組むエンジニアにとって、絶対に避けるべきだとわかっていながら避けられない失敗や、気づいたらはまってしまっていた落とし穴など、チームの足を止める状況はできるだけ避けたいものです。もし完全には避けられないなら、被害を最小限に抑える必要があります。 紹介する失敗エピソードは、例えば下記のようなもの。それぞれのエピソードに、架空の開発現場を舞台にした4コマ漫画も収録しています。 機能がてんこ盛りで実装が間に合わない「全部入りソフトウェア」 お願いされた機能を断れない「八方美人な仕様」 ユーザーを迷わす自分ルールのUI「オレオレ表記」 行間を読ませる「文学的仕様書」 リリース版が復元できない「不完全リポジトリ」 アクションしない「聞くだけ進捗会議」 施策を打

はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2017年に始まったリプレイスプロジェクトにおいて、ZOZO がどのような意図で、どのように取り組んできたのか、読者のみなさんに有益な情報をお伝えしていければと思いますので、ご期待ください。第1回目のテーマは、「ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計」です。 目次 はじめに 目次 ZOZOTOWNリプレイスの背景、目的 背景 目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ZOZOTOWNリプレイスの歴史とアーキテクチャの変遷 アーキテクチャの変遷 2004年〜2017年：オンプレミス（リプレイス前） 2017年〜20

眠りのこごろー@日本労働撲滅協会会長 @nemuri11290 ■のんびりぼちぼち生きてるアラサーオタク■夢は地下室と屋上のある家に住むこと■暗いしうるさい奴なのでミュート推奨。その他、フォロー、フォロー解除、ブロック等ご自由にどうぞ■誤字脱字大王■無言フォロー失礼します 眠りのこごろー@日本労働撲滅協会会長 @nemuri11290 取引先の人が退職した。「仕事ができない」って言われてて、その人が担当するときは「いやーひどいね」って弊社社員達で悪口言って笑ってる(弊社のそういうとこ、嫌いよ)。所謂"ドベ"扱いの人だったんだけど、その人が退職したあと不思議なことが起きたの。残った人の中から新しいドベが出た 眠りのこごろー@日本労働撲滅協会会長 @nemuri11290 今まで、取引先はその人以外皆能力高くて社員たちも「あの人以外は優秀」って評価だったのに、その人が辞めた途端別の人を「あの人

はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく

吉谷光平 @kakikurage 読んでくださってありがとうございます。 本日更新の「今どきの若いモンは」283話でした。 続きはサイコミで読めますので是非読んでみてください！↓ twitter.com/kakikurage/sta… 吉谷光平 @kakikurage 令和のサラリーマン漫画 「今どきの若いモンは」好評配信中！ ☆最新22巻→amzn.to/3SNgigb ☆1巻→amzn.to/3wmyR3a ☆サイコミで待てば無料で連載中 →cycomi.com/title/87 ☆反町隆史主演でドラマ化！ →wowow.co.jp/drama/original… ☆石沢課長無料本 →amzn.to/3OS2or4 pic.twitter.com/52hQvIhU1G 吉谷光平 @kakikurage 石川県出身、福岡県在住の漫画家です。 ・連載中→毎週月曜サイコミにて ＃今どきの若い

Photo by ThoroughlyReviewed こんにちは。谷口です。 以前は「35歳定年説」などという言葉もありましたが、今や死語とも言えるのではないでしょうか。 最近は30代、40代となってもエンジニアとして活躍されている方はめずらしくありません。30代以降から周辺領域の仕事や未経験からエンジニアへの転職をされる方も増えてきました。 ただ、これはエンジニアに限った話ではありませんが、年齢を重ねていくと誰しも若い頃とは同じようにいかない場面も出てきます。 年齢を重ねたエンジニアの方の中には「今後もエンジニアを続けたい」と思う一方、体力や集中力、新しい知識へのアンテナが働かなくなってきたことに悩んだり、下の世代の優秀さに焦りを感じたり…とさまざまな悩みを抱えている人も多いでしょう。 実際、paiza転職でもそういったご相談を受けることがよくあります。 今回は、30代後半・40代以降

StartupStockPhotosによるPixabayからの画像 こんにちは。倉内です。 エンジニアになったころは「とにかく手を動かし続けたい」「技術力で勝負したい」という方が多いのですが、実際ある程度働いてみると技術力だけで突破していくのは結構難しいことに気づきます。 尖った技術を武器にいわゆるスペシャリストとして生きていくことができる人はそう多くはなく、paiza利用ユーザー様からも「将来自分はどうすればいいだろうか…」という悩みをいただくことがあります。 エンジニアとしての市場価値を高めるには技術を磨くこと以外に、できることの幅を広げる、サービスやプロダクトの成長にフォーカスする、エンジニア経験を生かして転職する…など他の選択肢もあることを覚えておいてもよいでしょう。 そこで今回は、技術に全振りしないエンジニアのキャリア選択について考えてみたいと思います。 技術力オンリーで生きてい

すごいエンジニアになるためのマインドセット2つ目は「あらゆる責任を引き受ける」 2つ目に田中氏が大事にしているマインドセットは、米国の起業コンサルタントであるダン・ケネディ氏の「人生のコントロールをしたかったら、責任を引き受けろ」だという。 人生にはさまざまな判断がつきもの。しかし、会社の中でも意外と判断していない人は少なくない。その理由は「責任を取りたくないから」だと指摘する。しかし、逆に言えば責任を取る意思があれば、どんなことでも自分で決められる、判断できる、自分でコントロールできることを意味する。 つまり、責任を取れる人は、判断できる人であり、指示されたこと以上のことができる。すると、どんどん仕事ができるようになり、プロアクティブに動いて仕事をこなせるようになっていく。一方、責任から逃れようとする人は、常に言われたことしかできなくなり、さらに力もつかず、言われたことすらできなくなって