//ohina.work/categories/%E9%96%A2%E6%9D%B1/ Recent content in 関東 on 地方SEナビ Hugo -- gohugo.io ja-jp Mon, 03 Aug 2026 12:00:00 +0900 //ohina.work/post/real_engineer_ladybug_icon/ Mon, 03 Aug 2026 12:00:00 +0900 //ohina.work/post/real_engineer_ladybug_icon/ はじめに 「経験」や「勘」に頼って仕事を進める文化は、時に思いがけない成果物を生み出してしまいます。 今回は、社内の勉強会をきっかけに、勤怠管理ソフトのデザインが思わぬ方向に進んでしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「エンジニアにデザインを任せてはいけない理由」 これは勤怠パッケージソフトを自社開発している神奈川県の中小企業での出来事。 社内の勉強会で、自社の勤怠管理ソフトのUIデザインを改善しようという話が持ち上がった。 メンバーH（若手）🙂 「せっかくなので、ペルソナを設定したデザイン設計の一連のプロセスを経験し、デザインの基礎をちゃんと学びながら進めませんか?」 勉強会リーダーI 😐 「ペルソナ設計ぃ？　なんか時間かかりそうだなそれ。」 メンバーH（若手）🙂 「UI/UXの原則も踏まえて、視認性とか操作性とか一貫性とか、意識した方がいいと思うんですけど……。」 メンバーJ 😑 「なんか難しい話してるなー。もっと感覚でパッと決めちゃえばよくない？」 メンバーH（若手）😅 「いや、一連のプロセスを理解しないとスキルの取得にならないんじゃ……。」 勉強会リーダーI 😤 「今回はいいんじゃないの」 基礎的なプロセスを「面倒くさい」と感じたリーダーとメンバーたちは、結局、明確なコンセプトを決めないまま、思い思いの感覚でHTMLファイルの編集を始めた。 メンバーJ 😊 「ボタンのアイコン、てんとう虫にしてみようよ。」 勉強会リーダーI 🙂 「こっちは星型で。バランスも良さそうだし。」 メンバーH（若手）😨 「……勤怠管理ソフトに、てんとう虫と星のアイコンですか？」 勉強会リーダーI 😊 「可愛いからいいでしょ！」 コンセプトを誰も定めていなかったため、カラーリングの意図も統一されないまま、デザインは完成してしまった。 メンバーH（若手）😱 （このアイコン、実際に使う社員は何のボタンか分かるんだろうか……。） 出来上がった勤怠ソフトは、ボタンの各種アイコンがなぜか「てんとう虫」や「星」になっており、コンセプトが不明なままカラーリングの意図も分からない、残念な仕上がりとなってしまった。 解説 問題点 HTML5が登場した頃、「デザインは理論化できるので、デザイナーでなくてもデザインができる」という意見が広まったことがあります。 //ohina.work/post/real_engineer_mandala_chart/ Mon, 03 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_mandala_chart/ はじめに 目標設定の手法として有名な「マンダラチャート」。 用紙を9つのマスに分け、中心に書いた目標から具体的なアクションを展開していく、大谷翔平選手も用いたことで知られるメソッドです。 しかし、この手法を導入しても、組織の土台次第では機能しないことがあります。今回はそんな職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「マンダラチャートで目標すら立てられない会社のPDCA」 これは神奈川県の社員数300名規模のIT系中小企業での出来事。 その年、チームの目標設定に「マンダラチャート」を導入することになった。 発案したのはチームリーダーC自身だった。 リーダーC 🙂 「今期からマンダラチャート使って、みんなでチーム目標立てていこうと思うんだよね。」 メンバーD 🙂 「大谷選手が使ってたやつですね！やってみましょう。」 期待に胸を膨らませて始まった打ち合わせだったが、いざマスを埋める段階になると空気が変わっていく。 リーダーC 🙂 「じゃあ中心のマスに、今期のチーム目標書いてみて。えーと……『スキルを上げる』とかでいいんじゃない？」 メンバーE 🙂 「私は『もっと頑張る』でいいと思います。」 メンバーD 🤔 「あの、もう少し具体的に、何をどれくらい、という形にした方がよくないですか？せっかくリーダーが導入してくれた手法なので、ちゃんと活かしましょう。」 リーダーC 😅 「うーん……『スキルをたくさん上げる』とかでいいと思うけどな……。」 メンバーE 😑 「細かく決めなくても、なんとなく伝わればよくないですか？」 具体的な数値や行動に落とし込もうとしても、抽象的な言葉しか出てこない。 メンバーDは何度か具体化を提案したが、発案者であるはずのリーダーCも、メンバーEも取り合わず、打ち合わせの時間は限られているまま時間だけが過ぎていく。 リーダーC 😓 「……とりあえず今日はこのままで進めとこうか。」 具体的な目標が定まらないまま、打ち合わせは終了となった。 その後も、 誰が何を担当するか どの周期で振り返りをするか 進捗が遅れたときの修正方法 といった基本的な仕組みは決められないまま、なんとなく計画だけが独り歩きしていった。 メンバーDは「せめて振り返りの日程だけでも決めましょう」と何度か声をあげたが、誰からも明確な返答はなかった。 メンバーD 😮‍💨 「言い出しっぺのリーダーが一番動いてくれないと、この仕組みは回らないと思うんですが……。」 リーダーC 😐 「まあまあ、そのうち何とかなるって。」 数ヶ月後。 //ohina.work/post/real_engineer_unreasonable_boss/ Sun, 02 Aug 2026 10:00:00 +0900 //ohina.work/post/real_engineer_unreasonable_boss/ はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この記事では、曖昧な指示や、認識の違い、記憶違いによる職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「自分が言ったことを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の怒りは収まらなかった。 //ohina.work/post/real_engineer_vocabulary_lacking_pm/ Sat, 01 Aug 2026 14:00:00 +0900 //ohina.work/post/real_engineer_vocabulary_lacking_pm/ はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 語彙力なさすぎPM TMの意味が分かっていないレビュアー これは、神奈川県のとあるシステム会社で社内向けスライド資料のレビューで起きた出来事です。 PM😤：「スライドタイトルの製品名の『TM』が付いていないじゃないか。ちゃんと表記しなさい。」 部下😐：「????」 TMは「Trade Mark」の略で、製品名、ロゴが自社の商標であることを示すための記号です。 Nintendo DSなどNintendoの製品にも末尾にTMとついているとことがあると思います。 しかし、ロゴを正式なブランド表記として利用しているわけでもなく、社内向けの説明資料において単純に製品名に言及するだけであれば、TM表記が必須となるケースはほとんどありません。 実際、新聞記事の見出しなどでもついていないことがほとんどです。 悪意があるわけではないと思いますが、リテラシーが低く過ぎる人がレビューイとして参画していると、本質的な内容よりも些末な部分にばかり注目し、ピントがずれた指摘が繰り返されることがあります。 SaaS、PaaS、IaaSを知らないクラウド案件のPM これは、東京都内にある業界屈指の大手企業のN社のクラウド案件に参画していたPMとのやり取りです。 あるミーティングで、クラウド構成の話題になった。 エンジニア 🙂 「このシステムは〇〇をSaaS、□□をPaaS、△△をIaaSとして採用しています。」 PM 😐 「SaaS、PaaS、IaaS……ソレ、ナニ？」 エンジニア 😳 「え、クラウドの提供形態の分類です。SaaSはソフトウェア、PaaSはミドルウェア、IaaSはインフラを提供するサービスですね。」 クラウド案件に参画しているPMが、基本用語であるSaaS/IaaSを知らないという事実に、メンバーは驚きを隠せなかった。 BIOS = Vaio S これは、東京都内にある業界屈指の大手企業のN社のPMとのやり取りです。 パソコンの初期設定に関する話題になった際のことである。 PM 🤔 「バイオエスの設定は、もう終わっていますか？」 エンジニア 😶 「……Vaio Sですか?、使ってるのLifebookですけど。。。」 PM 😐 「バイオエスです!!」 部下Aは一瞬、何のことか理解できなかった。 しばらく考えて、ようやく気づく。 エンジニア 😨 （まさか、BIOSのことか……？） 実はこのPM、4文字以上の英単語をアルファベット読みしてしまう癖があるようです。 他にもMosquitto (モスキート)のことをモスキューティーティーオーと呼んだりしていたそうです。 解説 業界内ではメンバーからの回答に対して、ある程度回答ができる人物がPMをするべきとされていますが、相当優秀な人でないとそんなことはできないため、現場ではそうではない人物がPMをやっていることは多いです。 そのため、周りがフォローをする必要があるのですが、PMという立場にたったことでふんぞり返ってしまい、周囲を混乱させ、周りがフォローする気を失せさせてしまうPMもいるのが実態です。 おわりに あまりにもリテラシーが低いPMの下にいるとレビューでもピントのずれた指摘を受けることが多く、自身の成長には繋がりません。