はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 ピントがずれた指摘が多いレビュアー これは、あるシステムに関する社内向けスライド資料のレビューで起きた出来事です。 上司😤：「スライドタイトルの製品名に『TM』が付いていないじゃないか。ちゃんと表記しなさい。」 部下😐：「????」 TMは「Trade Mark」の略で、商標であることを示すための記号です。 しかし、ロゴを正式なブランド表記として利用しているわけでもなく、社内向けの説明資料において単純に製品名に言及するだけであれば、TM表記が必須となるケースはほとんどありません。 もちろん、表記ルールを確認すること自体は大切です。 しかし実際のレビューでは、本質的な内容よりも些末な部分にばかり注目し、ピントがずれた指摘が繰り返されることがあります。 悪意があるわけではないだと思いますが、意味の薄い指摘への対応に時間を取られることで、本来議論すべき内容が後回しになってしまうケースは少なくありません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 Operatorの意味を知らないDevOpsエンジニア これは、DevOpsの導入支援を行っていたプロジェクトでの出来事です。 上司🤔：「運用者って英語で何て言うの？」 部下😐：「operatorです。」 上司😤：「なんか違うなー。actorにしよう!!」 部下😐：「????」 業界では一般的な英単語であるにもかかわらず、その意味を理解していない人がプロジェクトをマネジメントしているケースは少なくありません。 今回のケースでは、DevOpsプロジェクトに参画しているにもかかわらず、「Operator」という言葉の意味を理解していませんでした。 さらに厄介なのは、正しい表現を提示しても同じ間違いが繰り返されることです。 脳の仕組み的に、本人の中では独自の定義や解釈が形成してしまう方がいて、世の中で一般的に使われている意味とのズレを認識できていないケースがあるのです。 誰でも最初は知らないことがありますし、無知であること自体は何も問題ではありません。 しかし、自分の認識がずれている可能性に気付けなければ、学習や修正の機会を失ってしまいます。 実際に社会人として働いていると、「知らない人」よりも「間違って理解していることに気付いていない人」に遭遇することがあります。本人の中では筋が通っているため、自分が間違っているという感覚がありません。 そのため、正しい情報を示されても自分の解釈を優先してしまい、結果として同じ間違いを繰り返してしまうのです。 そして、そのような人が意思決定を行う立場にいると、プロジェクト全体が誤った方向に進んでしまうこともあります。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 青色申告を使わないエンジニアが意外と多い これは副業やフリーランスで働くエンジニアの確定申告の話です。 知人のエンジニア🙄:「白色申告でいいよ、青色申告は面倒くさいから」 そう言って、経費がまったく計上できない白色申告を選ぶエンジニアって意外と多いんです。 青色申告を使うだけで、数十万円単位で損をしているのです。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 SNSでのビジネスロマンス詐欺被害 これはあるベテランエンジニアがSNSを通じて知り合った外国企業に金を騙し取られた話です。 「取引相手」と思っていた相手は、実は詐欺グループでした。 最初は数千円。その後、何度か追加投資を促され、最終的には50万円を失ったそうです。 驚くべきは、そのことを話したときの彼の態度です。 エンジニアA😳:「えっ、50万円も！？」 ベテランエンジニア😳:「まあ、勉強代みたいなもんだから。」 エンジニアA😳:「変だと思わなかったんですか？」 ベテランエンジニア😳:「外国との取引なので、そういうものかと思ってた。」 エンジニアA😳:「….(リアクション薄いな。。。)」 50万円という大金を失ったにもかかわらず、怒ることも悔やむこともなく、「勉強代」という言葉で片付けているのです。 一人暮らしでお金を必要としない生活を続けていて、金銭感覚がずれてしまった例の一つと言えるかもしれません。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 借金を自慢するピエロエンジニア これはある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティと称して、ジモティーでカフェ会などを開いているそうです。 その方はカフェ会で以下のような発言をしたそうです。 40代エンジニアさん😎:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA😳:「えっ、20万円も！？」 40代エンジニアさん😏:「自己投資(人生経験)だったと思ってるよ(ドヤ～)」 エンジニアA😳:「….(何で自信満々なんだ。。。)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、小学生でも分かることですよね。 小学生でも知っていることを理解したことを自慢話のように語っているのです。 そのエンジニアの方はコミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔ってしまい、客観的な分析ができなくなっているようです。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

はじめに 「経験」や「勘」に頼って仕事を進める文化は、時に思いがけない成果物を生み出してしまいます。 今回は、社内の勉強会をきっかけに、勤怠管理ソフトのデザインが思わぬ方向に進んでしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「エンジニアにデザインを任せてはいけない理由」 これは勤怠パッケージソフトを自社開発している神奈川県の中小企業での出来事。 社内の勉強会で、自社の勤怠管理ソフトのUIデザインを改善しようという話が持ち上がった。 メンバーH（若手）🙂 「せっかくなので、ペルソナを設定したデザイン設計の一連のプロセスを経験し、デザインの基礎をちゃんと学びながら進めませんか?」 勉強会リーダーI 😐 「ペルソナ設計ぃ？　なんか時間かかりそうだなそれ。」 メンバーH（若手）🙂 「UI/UXの原則も踏まえて、視認性とか操作性とか一貫性とか、意識した方がいいと思うんですけど……。」 メンバーJ 😑 「なんか難しい話してるなー。もっと感覚でパッと決めちゃえばよくない？」 メンバーH（若手）😅 「いや、一連のプロセスを理解しないとスキルの取得にならないんじゃ……。」 勉強会リーダーI 😤 「今回はいいんじゃないの」 基礎的なプロセスを「面倒くさい」と感じたリーダーとメンバーたちは、結局、明確なコンセプトを決めないまま、思い思いの感覚でHTMLファイルの編集を始めた。 メンバーJ 😊 「ボタンのアイコン、てんとう虫にしてみようよ。」 勉強会リーダーI 🙂 「こっちは星型で。バランスも良さそうだし。」 メンバーH（若手）😨 「……勤怠管理ソフトに、てんとう虫と星のアイコンですか？」 勉強会リーダーI 😊 「可愛いからいいでしょ！」 コンセプトを誰も定めていなかったため、カラーリングの意図も統一されないまま、デザインは完成してしまった。 メンバーH（若手）😱 （このアイコン、実際に使う社員は何のボタンか分かるんだろうか……。） 出来上がった勤怠ソフトは、ボタンの各種アイコンがなぜか「てんとう虫」や「星」になっており、コンセプトが不明なままカラーリングの意図も分からない、残念な仕上がりとなってしまった。 解説 問題点 HTML5が登場した頃、「デザインは理論化できるので、デザイナーでなくてもデザインができる」という意見が広まったことがあります。

はじめに 目標管理制度を初めて導入する会社では、思わぬところでつまずくことがあります。 今回は、目標設定そのものに膨大な時間がかかってしまい、肝心の業務改善に手が回らなくなってしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「目標設定に四半期の約1/4を消費する会社」 これは設立30年以上の中小SIerでの出来事。 これまで目標管理の仕組みが存在しなかったこの会社で、経営層の意気込みのもと、初めて全社員による個人目標設定が導入されることになった。 役員F 😊 「今期から、全員に個人目標を立ててもらって、上司と合意するプロセスを始めます。」 部下G 🙂 「わかりました、頑張って考えます。」 しかし、いざ目標のすり合わせが始まると、想定外の壁にぶつかった。 部下G 🙂 「今期の目標は『担当システムの保守対応をしっかり行う』にしました。」 役員F 😐 「うーん、それは行動計画であって、目標とは少し違うんじゃないかな。」 部下G 😳 「え……目標と行動計画って、違うものなんですか？」 役員F 😐 「目標というのは、その行動によって最終的に何を達成したいか、という話で……。」 部下G 🤔 「……正直、その違いがよくわからないです。」 役員が期待するレベルと、部下が設定した目標の内容には大きなギャップがあった。 そのギャップを埋めようと何度もレビューが行われるが、話は一向にかみ合わない。 役員F 😓 「評価基準がどうなっているか、把握してますか？」 部下G 😨 「いえ……そもそも何を書けば評価されるのか、誰からも聞いていません。」 上司側も評価基準を明確に説明できず、部下へ適切なフィードバックを返せない。 結果、目標のすり合わせは何度もやり直しになった。 部下G 😩 （もう3回目の書き直しだ……。） 役員F 😥 （こんなに時間がかかると思わなかった……。） 気づけば、目標設定だけで3ヶ月以上が経過していた。 役員F 😰 「……もう四半期の1/4が、目標を決めるだけで終わってしまいましたね。」 部下G 😔 「はい……実際の業務改善に使える時間が、ほとんど残っていません。」 期末になり採算レビューが行われても、何が問題でどこを改善すべきか誰も理解できていない状態だったため、多くの社員が目標未達となった。

はじめに 目標設定の手法として有名な「マンダラチャート」。 用紙を9つのマスに分け、中心に書いた目標から具体的なアクションを展開していく、大谷翔平選手も用いたことで知られるメソッドです。 しかし、この手法を導入しても、組織の土台次第では機能しないことがあります。今回はそんな職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「マンダラチャートで目標すら立てられない会社のPDCA」 これは神奈川県の社員数300名規模のIT系中小企業での出来事。 その年、チームの目標設定に「マンダラチャート」を導入することになった。 発案したのはチームリーダーC自身だった。 リーダーC 🙂 「今期からマンダラチャート使って、みんなでチーム目標立てていこうと思うんだよね。」 メンバーD 🙂 「大谷選手が使ってたやつですね！やってみましょう。」 期待に胸を膨らませて始まった打ち合わせだったが、いざマスを埋める段階になると空気が変わっていく。 リーダーC 🙂 「じゃあ中心のマスに、今期のチーム目標書いてみて。えーと……『スキルを上げる』とかでいいんじゃない？」 メンバーE 🙂 「私は『もっと頑張る』でいいと思います。」 メンバーD 🤔 「あの、もう少し具体的に、何をどれくらい、という形にした方がよくないですか？せっかくリーダーが導入してくれた手法なので、ちゃんと活かしましょう。」 リーダーC 😅 「うーん……『スキルをたくさん上げる』とかでいいと思うけどな……。」 メンバーE 😑 「細かく決めなくても、なんとなく伝わればよくないですか？」 具体的な数値や行動に落とし込もうとしても、抽象的な言葉しか出てこない。 メンバーDは何度か具体化を提案したが、発案者であるはずのリーダーCも、メンバーEも取り合わず、打ち合わせの時間は限られているまま時間だけが過ぎていく。 リーダーC 😓 「……とりあえず今日はこのままで進めとこうか。」 具体的な目標が定まらないまま、打ち合わせは終了となった。 その後も、 誰が何を担当するか どの周期で振り返りをするか 進捗が遅れたときの修正方法 といった基本的な仕組みは決められないまま、なんとなく計画だけが独り歩きしていった。メンバーDは「せめて振り返りの日程だけでも決めましょう」と何度か声をあげたが、発案者のリーダーCからもメンバーEからも明確な返答はなかった。 メンバーD 😮‍💨 「言い出しっぺのリーダーが一番動いてくれないと、この仕組みは回らないと思うんですが……。」 リーダーC 😐 「まあまあ、そのうち何とかなるって。」 数ヶ月後。

はじめに 社会人になれば、会社という組織はきちんとルールに則って運営されているというイメージを持つ人は多いのではないでしょうか？ しかし現実には、社内の意思決定プロセスが曖昧なまま放置され、従業員が振り回されてしまう会社も存在します。 立場が上だから、総務だからといって、必ずしも合理的な対応をしてくれるとは限らないのです。 本記事が、会社という組織を過信せず、自分の権利や手続きについて主体的に確認する姿勢を持つきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 社員寮の退寮手続きだけで2ヶ月以上かかるトンデモ会社 通勤時間短縮のための退寮相談 これは、とある神奈川県のSES会社での話です。 この会社では従業員に対して、会社近隣のアパートを社員寮として提供していました。 ある新人社員Aさんは、社内勤務から客先常駐に配属が変わったことで、社員寮からの通勤に時間がかかり過ぎるようになり、退寮を検討します。 就業規則や寮規則には退寮に関する規定がなかったため、退寮が可能かどうか、可能な場合はどのような手順を踏めばよいかを直属の上司に確認しました。 すると、上司からはこんな反応が返ってきます。 上司😕：「会社の方針として、若手が社員寮を出るのはあまり良く思われていないんだよね……」 はっきりした理由は語られず、曖昧な物言いでしたが、話によると、過去には女性社員が「ユニットバスが嫌だ」という理由で退寮を申し込んだものの、否認された前例もあったそうです。 その後、上司から 上司:「取り敢えず、総務部に確認のメール送信して」 新人A😐: 「分かりました。」 指示を受けたAは、退寮を検討している理由と、手続きが可能かどうかを総務部・上司・課長宛にすぐにメールで送信しました。 新人A😳:「通勤時間短縮のために退寮を検討してます、退寮できるかどうか確認したいです📨」 噛み合わないコミュニケーション ところが、何故か総務部は新人Aに返信せず、上司と、課長にのみメール返信しました。 総務からの指摘を受けた上司は新人Aに以下のように指摘しました。 上司😠：「なんでメールを総務部に送ったんだ。」 新人A😳 ：「え、先ほどメールを送信するように指示を受けたので。。。」 上司😠：「今送るとは思わなかった。」 新人A😳 ：(いつだったらいいんだよ) Aさんとしては、上司から総務に確認するよう指示されたため、すぐに送信しただけです。 内容的に何時送信しても特に問題ないような内容ですが、何故か上司から𠮟責をうけ、さらにいつ送信すればよかったのかは最後まで明かされませんでした。 また、総務部からの返信内容は一切新人Ａには共有されず、どうも会社側が何かひた隠ししているような状態でした。 その後、会社が月末に実施ている帰社報告会で、課長・上司と対面で話し合いの上、方針を決定することになりました。 これにより退寮は1ヶ月先延ばしになりました。 帰社報告のドタキャン ところが、帰社報告の日に課長も上司も欠席していることに気づきます。 新人A😐: 「課長も上司もいないな。。。」 社内の別の社員Bに聞いて回ったところ、以下のように教えてくれました。 新人A😐: 「課長と上司って今日出社してます?」 社員B😅：「上司さんは業務都合で休み、課長はプライベートの都合でお休みだって。」 新人A😐: 「。。。」 新人Ａに連絡がなく、ドタキャンされてしまったため、帰社報告では方針を決められず、さらに1ヶ月ほど時間が過ぎていきました。 社内で見えてきた「本音」 社内やインターネットで似たような事例を調べてみると、社会人経験の浅い新人が退寮すると金銭面でのトラブルを起こすリスクがあることから、総務部が寮に留めておきたがる、という噂があるそうでした。 一方で、新人でも実家からの一人暮らしに切り替えた社員は特に総務から指摘がなかったことから、上記は表向きの理由は本音は以下の理由だと推測しました。 住宅手当を支給するより、社員寮を維持する方が会社にとって節税効果が高い 退寮時期が中途半端だと、不動産会社への賃料を余分に支払う必要が生じる そこで新人Aは、退寮時期や、移住先の物件の賃料は会社の希望に合わせられること、通勤経路が短くなれば通勤手当の支給額も減り会社側にもメリットがあることを提案してみることを検討しました。 「それはお前が考えることではない」 後日、現場で上司と直接話す機会がありました。 新人A🙂: 「退寮時期と賃料などの条件をご提示していただければ会社の条件に合わせます。また、通勤手当が少なくなるので会社にもメリットがあります。」 上司😑：「社員寮を出ると、普通のアパートよりお金がかかる」 言われなくても分かるようなことを、執拗に念押しされます。

はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この記事では、曖昧な指示や、認識の違い、記憶違いによる職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「自分が言ったことを5分で忘れる理不尽上司」 これは関東のとあるシステム開発会社での出来事。 複数のプロジェクトが同時に動くオフィスでは、サーバー構築やシステム開発、データ分析などの業務が日常的に行われていた。 社員たちはそれぞれの案件を抱え、部署やプロジェクトの垣根を越えて協力する場面も多かった。 ある日、オフィスレイアウト変更に伴い、別プロジェクトの上司Bが、別フロアに異動となり、デスクを移動することになった。 部下Aは自分の担当業務を進めている最中、突然電話を受ける。 上司B 😐 「これからデスクを移動するから、私の机の上にある物を全部机から片付けてまとめておいて。」 部下A 🙂 「わかりました。」 上司Bの机に目をやると、デスクトップ型PCが設置されていたからだ。 念のため確認した方がいいと考えた部下Aは、再度連絡を入れた。 部下A 🤔 「机の上にデスクトップPCがありますが、これも片付けてよろしいでしょうか？」 上司B 😐 「いいよ。全部片付けておいて。」 部下A 😊 「承知しました。」 確認も取れたため、部下Aは安心して片付けを始めた。 書類、文房具、小物類を整理し、段ボールにまとめる。 最後にPCへ手を伸ばす。 するとPCの電源ランプが点灯していることに気付いた。 部下A 🤔 「あれ、電源が入っているな。」 しかし、机から移動するには電源を切るしかない。 しかも先ほど「PCも片付けてよい」と明確に許可を得ている。 デスクから下すにためには、当然電源も切る必要がある。 そう判断した部下Aは、通常の手順でシャットダウンを実施し、PCを片付けた。 数分後。 オフィスの空気が突然変わった。 上司B 😠 「誰だ！！PCの電源を切ったのは！！」 周囲の社員たちが驚いて顔を上げる。 部下A 😳 「私です。片付けるよう指示をいただいたので……。」 上司B 😡 「勝手に人のPCの電源を切ったらだめだろ！！」 部下A 😨 「???」 どうやら上司BはPC上で大規模な計算処理を実行していたらしい。 その処理は長時間かかる作業で、電源を切られたことで途中で停止してしまったのだ。 部下A 😰 （いや、だから確認したんだけど……。） しかし上司Bの怒りは収まらなかった。