はじめに 顧客との打合せでは、要件への理解不足を指摘された時にどう振る舞うかで、その後の信頼関係が大きく変わります。 この記事では、自分の理解不足を認めたくないという心理が、かえって顧客の不信感を招いてしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「チャンスを自ら潰す案件潰しPL編」 これは、大手SIerの下請けとして開発案件を受けている、岡山のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、大手SIerから受注した案件を、PL（プロジェクトリーダー）とエンジニアの数名体制で回すことが多かった。 今回参加した打合せは、クラウド上に蓄積された大量のPDFファイルに対してOCR技術を適用し、メタ情報を抽出して検索性を高めるという新規案件のキックオフだった。 打合せの中で、要件の説明が一通り行われた。 キックオフ後、顧客とA社で個別の打合せを実施した。 顧客 🙂 「さっきの打ち合わせ、A社さん的にどう思いました？」 A社PL 😐 「まだ、要件がプアーな感じで、なんとも……」 要件はすでに十分に説明されていたにもかかわらず、A社PLは言い訳し、言葉を濁した。 横で聞いていたA社エンジニアは、内心「そんなに曖昧だったか？」と首をかしげていた。 要件を理解できていないのではと感じた顧客は、あらためて丁寧に補足を始めた。 顧客 🙂 「ユーザーがやりたいことって〇〇だと思うんですよ。で、〇〇を実現するとなると……」 A社PL 😠 「私も分かってますよ！」 顧客の言葉を遮り、食い気味に返すA社PL。 要件が理解されていないと思われたことで、自分が無能だと見られていると感じたのかもしれない。 その場に、しらーとした空気が流れた。 顧客もA社エンジニアも、思わずドン引きして青ざめる。 引き気味になりながらも、顧客は会話を続けようとした。 顧客 😕 「OCRを使うとなると、どのサービスを使うかというのが課題だと思うんですが……」 A社PL 😏 「OCR、文字認識機能ですね。」 理解できていることをアピールしたいのか、顧客の言葉をそのまま復唱したり、別の言い方に言い換えたりするA社PL。 しかし内容そのものへの回答にはなっていなかった。 らちが明かないと感じた顧客は、単刀直入に核心を尋ねた。 顧客 😐 「いや、聞きたかったのは、A社さんはこのシステムのアーキテクチャとか提案できますかってことなんですよ……」 A社PL 😳 「そういうことでしたら是非当社に！」 それまでの態度が一変し、急に前向きな姿勢を見せるA社PL。 その落差の大きさに、周囲は言葉を失った。 雰囲気を察したA社エンジニアが、慌ててフォローに入る。 A社エンジニア 😅 「と、とりあえず詳細は持ち帰らせていただいて、ご提案させていただきますね。」 打合せはひとまずその場を収める形で終わったが、顧客のA社に対する印象は、決して良いものではなかった。 解説 このトラブルの根本原因は、A社PLが「要件を理解できていない」ことそのものではなく、それを指摘されたときに、理解不足を認めずに取り繕おうとしたことにあります。 「まだ要件がプアー」という発言は、顧客の説明不足を暗に示唆するもので、責任を相手に転嫁するニュアンスを含んでいます。 また、顧客の補足説明を遮って「分かっている」と主張したり、言葉を復唱・言い換えするだけで実質的な回答を避けたりする行動は、理解できていないことを隠そうとするあまり、逆に理解できていないことを露呈させてしまう典型的なパターンです。 顧客側も最初は好意的に補足していましたが、やり取りが重なるうちに「この人は本当に理解しているのか」という疑念を強めていきました。 そして最後に核心を問われた瞬間、それまでの姿勢とはうらはらに前向きな態度に切り替えたことで、それまでの言動が「その場を取り繕うためのもの」であったことを、結果的に自ら証明してしまいました。 こうした場面では、理解できていないことを素直に認め、「その点については確認させてください」と伝える方が、よほど信頼を損なわずに済みます。

はじめに 休日は業務から離れて自分の時間を過ごすものだと考えている人は多いのではないでしょうか。 しかし、プロジェクトの進行に追われるあまり、部下や後輩の私生活にまで踏み込んでしまう管理職も存在します。 今回は中四国のシステム開発現場で実際にあった、顧客向け報告資料の作成を口実に後輩の自宅へ押しかけ、汗をかきながら作業を進めるPLの傍らで、当の後輩がプロジェクトとは無関係の自社メンバーを招いて麻雀に興じていたという話を紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「休日に部下の家で仕事するプロジェクトリーダー」 これは中四国のあるシステム開発会社での出来事。 このプロジェクトは、複数の協力会社が入り交じる中規模の案件で、リリース直前ということもあり、現場全体に慢性的な余裕のなさが漂っていた。 PLは、要領の悪さで社内でも有名な人物で、進捗管理や資料作成をいつもぎりぎりまで溜め込んでしまう癖があった。 後輩のDさんは、ノリの軽さで周囲から「ちゃらお」と呼ばれるタイプで、久しぶりの休日に自宅でゆっくりくつろいでいた。 すると、スマートフォンにPLからの着信が入る。 Dさん 😌 「はい、Dっす。」 PL 😐 「明日、顧客向けの報告資料を作らないといけなくてさ。今日中に仕上げたいんだよね。」 PL 😊 「いや、Dが作ったドキュメントとかプログラムのこと、分からないところがあったらすぐ聞きたいから、そっち行っていい？」 Dさん 😆 「家っすか？別にいいっすよー、散らかってますけど。」 PL 😊 「うん、近くまで来てるんだ。」 すでに移動を始めていたPLは、そのままDさんの自宅に到着する。 本来であれば会社の設備で行うべき作業を、部下の自宅の私的な空間で、しかも休日にこなす状況を、PL自身が作り出していたのである。 PLはノートPCを広げ、資料作成に取りかかった。 PL 😅 「あー、この処理どうなってたっけ……。ちょっと聞いていい？」 Dさん 😐 「ああ、それはこういう処理っすよ。」 質問に答えながらも、Dさんは何をするでもなく手持ち無沙汰になっていた。 すると、ちょうどそこへ別のプロジェクトで一緒だった他社のメンバーから連絡が入る。 自社メンバー 📱 「暇してるなら麻雀しない？」 Dさん 😆 「お、いいっすね！ちょっとうちに来てくださいよ。」 Dさんは自分の家であることをいいことに、プロジェクトとは無関係の自社メンバーたちを呼び寄せ、ノリノリでリビングの隅に雀卓を用意して麻雀を始めてしまった。 牌をかき混ぜる音と談笑が響く隣で、PLはエアコンの効きが悪い部屋の中、額に汗をにじませながら黙々と資料作成を続けていた。 Dさん 😆 「お、リーチ！」 自社メンバー 😂 「まじかよ、また負けた。」 数時間後、ようやく資料が仕上がったところで、PLは疲れた様子で切り出した。 PL 😮‍💨 「なんとか終わったよ……。じゃあ、また明日会社でよろしく。」 Dさん 😆 「お疲れさまっす！気をつけて帰ってくださいねー。」 解説 百歩譲って休日に作業をすること自体は仕方ないとしても、事前に「この部分についてメモをまとめておいてほしい」と後輩に指示しておけば、わざわざ部下の自宅にいく必要はなかったはずです。

はじめに 大手企業の案件を地方の下請け企業が受注する「ニアショア開発」は、コストメリットの大きい発注形態として広く活用されています。 しかし、その内側では、社内の都合によって工数が実態とかけ離れた形で見積もられているケースも存在します。 今回は岡山のとある下請けIT企業で実際にあった、見積もり水増しにまつわる話を紹介します。 「工数を2週間にしろ」と言われた若手エンジニア これは、大手SIerである富士通の案件を受注している、岡山のとある下請けIT企業での出来事。 ある日、若手エンジニアが新規案件の見積もりを行っていた。 若手エンジニア 🙂 「この作業は設定ファイルを修正するだけだから、1日あれば十分だな。動作確認とバッファを含めて3人日で見積もっておこう。」 若手エンジニア 😅 （これでもだいぶ多めに見てるけど……。） すると、隣の席で作業をしていたベテラン社員がその見積もりに気づく。 ベテラン社員 😏 「おいおい、それじゃ工数が少なすぎるよ。2週間は取らないと。」 若手エンジニア 😳 「え！？　実際の作業時間ってそれくらいですよね？」 若手エンジニア 😰 （3人日でもだいぶとりすぎのつもりだったのに……。） ベテラン社員 😏 「それじゃうちの利益にならないから。」（ヘラヘラしながら鼻で笑う） 若手エンジニア 😞 「わかりました……。」 納得はいかないまま、若手エンジニアは2週間分の工数で見積もりを作成することになった。 その後、この見積もりはそのまま顧客へ提出され、無事に発注を受けた。 若手エンジニアは指示された通りに、2週間かけて作業を進め、完了後に顧客への作業報告を行った。 顧客 🤨 「ん？　この作業って設定ファイルを変更するだけで、コード修正は入ってないですよね？　なんで2週間もかかったんですか？」 若手エンジニア 😨 「えっと、それは……。」（ちらっとベテラン社員の方を見る） ベテラン社員 😶 （ぷいっとそっぽを向いて知らん顔） 若手エンジニア 😱 （だんまりかよ！） 結局、顧客への説明はすべて若手エンジニア一人が背負うことになり、水増しを指示したベテラン社員は素知らぬ顔で自分の作業に戻っていった。 解説 今回のケースのように、実際の作業量とかけ離れた工数を見積もりに乗せる背景には、下請け企業側の「利益確保」という社内事情が存在します。

はじめに 社内のレクリエーションや地域行事への参加は、本来自由参加であるべきものです。 しかし、参加が実質的に強制され、さらに費用まで自己負担させられるとなると、話は変わってきます。 今回は岡山の企業で実際にあった、うらじゃ祭りの盆踊りにまつわる出来事を紹介します。 「うらじゃ祭りの光と闇」 これは岡山のとあるシステム開発会社での出来事。 従業員数百名規模のSier企業で、この会社では毎年夏、岡山の風物詩である「うらじゃ祭り」の盆踊りに、会社として団体で参加するのが恒例行事となっていた。 表向きは「地域交流」「社内の親睦」を目的としたレクリエーション活動であり、就業規則上も参加は任意とされていた。 ある年、入社1年目の新人達に集合がかけられた。 先輩B 😐 「新人はうらじゃに参加してもらいます。練習は今週土曜にやります。参加者は各自準備お願いします。」 新人A 🙂 「任意参加なんですよね？正直、うらじゃ自体あまり興味ないんですけど……。」 先輩B 😠 「は？やってみたら面白さがわかるから！やってもないのに興味ないとか言うな。」 新人A 😨 「す、すみません……。」 先輩B 😊 「もちろん参加は任意だよ。まあ、みんな出てるけどね。」 新人A 🤔 「（貴重な休日が……。）」 練習が始まった当日。 先輩B 😊 「Aくん、衣装まだ持ってないよね？購買部で買っといて。」 新人A 😳 「え、これ自分で買うんですか……？」 先輩B 😐 「そうそう、みんな自費で用意してるよ。1万円くらいかな。」 Aは驚いたが、周りの先輩たちも当然のように自分の衣装を用意している様子を見て、それ以上何も言えなかった。 練習は連日、休日に行われた。 新人A 😩 （今日も練習か……休日出勤もつかないし。） 先輩C 😅 「まあ毎年恒例だからね。うちの部は昔から皆勤で出てるし。」 新人A 😶 「皆勤……ですか。」 祭り本番当日。 猛暑の中、嫌な顔で衣装を着て踊る新人たちの姿を、会社の先輩達が観覧席から満足げに眺めていた。 先輩B 😄 「うらじゃって素敵やん。」 解説 制度上「任意参加」とされているイベントであっても、実際には職場の空気や上司の視線によって、事実上の強制力が生まれてしまうことは珍しくありません。 こうした状況は、個々の発言や指示自体には明確な強制の言葉が含まれていないため、後から「強制ではなかった」と説明されてしまいがちです。 しかし、実質的な参加率や、断った場合の周囲の反応を見れば、その職場における「任意」という言葉の実態が見えてきます。 うらじゃ祭り自体は、岡山を代表する素晴らしい伝統文化であり、地域を盛り上げる魅力的な催しです。 だからこそ、その価値観や参加意欲を職場の空気で他人に押し付けるのではなく、一人ひとりの意思を尊重した形で継承していってほしいものです。 価値観は人それぞれであり、興味を持てない人がいることも自然なことだと理解した上で、本当に楽しみたい人たちの手によって、この伝統が気持ちよく次の世代へ受け継がれていくことを願います。

はじめに 新社屋が完成した際、なぜか社内にシャワールームが設置されていた、という話を耳にすることがあります。 福利厚生の一環かと思いきや、その設置理由や利用実態を聞くと、首をかしげてしまうケースも少なくありません。 今回は中四国のある企業で実際にあった、新社屋のシャワールームにまつわる話を紹介します。 シャワールームの正体 この企業では、新社屋の建設にあわせてオフィス内にシャワールームが設けられました。 一般的な社員向けの福利厚生施設であれば納得もできますが、設置の経緯を聞くと事情は少し異なります。 このシャワールームは、すでに経営の一線から退いている経営者一族の要望によって作られたものでした。 引退後、畑仕事に精を出していた会長が、作業でかいた汗をその場で流せるようにという理由で、会社の新社屋にシャワールームを設置することになったといいます。 投資対効果への疑問 制度上は従業員も利用できることになっているそうですが、実際に使っている社員はほとんど見当たらないとのことです。 考えてみれば当然で、一般的なシステムエンジニアが、オフィスで汗を流すほどの作業をする機会はまずありません。 結果として、設置されたシャワールームは、ほぼ誰にも使われないまま社内の一角を占めることになりました。 新社屋にシャワールームを設置するとなれば、給排水設備の工事や、専用スペースの確保など、決して小さくない投資が必要になります。 会社の資金は本来、事業の成長や従業員の労働環境の改善のために使われるべきものです。 経営に関わる立場の人間が、私的な目的のために会社の予算を投じることが許容されてしまう体質は、同族経営やオーナー企業においてしばしば見られる問題の一つといえます。 まとめ 会社員として働く以上、こうした組織のしがらみや、経営陣の意向に振り回される場面から完全に逃れることは難しいものです。 そうした環境に悩まされ続けるのであれば、独立してフリーランスとして働くという選択肢を検討してみるのも一つの手です。 会社の資金の使い方や組織の体質に一喜一憂することなく、自分自身の裁量で仕事を選べる働き方も、キャリアの可能性として視野に入れておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

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

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 確定申告には「青色申告」と「白色申告」の2種類がある 副業やフリーランスで働くエンジニアが所得を申告する際、確定申告には大きく「青色申告」と「白色申告」の2種類があります。 青色申告: 事前の申請と帳簿付けの手間はかかるものの、最大65万円の控除など税制上の優遇が受けられる 白色申告: 事前申請が不要で手続きは簡単だが、節税効果はほとんどない このように、手間をかけてでも節税するか、簡単さを優先するかで選択が分かれる制度になっています。 節税に無頓着なエンジニアと、脱税に近い行為をするエンジニアの二極化 フリーランスや副業のエンジニアの確定申告事情を見ていると、極端に2つのタイプに分かれることが多いようです。 節税できる制度があるのに面倒くさがって使わない、税金に無頓着なタイプ 逆に節税を意識しすぎて、私物まで経費にしてしまう、脱税に近い行為をするタイプ どちらも褒められる話ではないですが、実際によく見かける事例です。 青色申告を使わないエンジニアが意外と多い これはフリーランスで働くエンジニアの確定申告の話です。 無頓着エンジニアB🙄:「確定申告はExcelを使って白色申告でやってる。」 エンジニアA😳:「え、青色申告の方が節税になりますよ。」 無頓着エンジニアB🙄:「白色申告でいいよ、青色申告は面倒くさいから」 節税対策ができない白色申告を選ぶエンジニアって意外と多いんです。 エンジニアは技術に興味はあるけど、金融とか資産形成に全く興味がないって人も珍しくないんですよね。 冷蔵庫などの私物も経費にする脱税エンジニアもいる 一方で、割合としては少ないですが節税を意識しすぎて、脱税に近い行為をしているエンジニアもいます。 脱税エンジニアC😏:「自宅の冷蔵庫、経費で買ったよ。仕事の合間に飲むもの入れてるから」 エンジニアA😳:「え、それ完全に私物じゃないですか…」 脱税エンジニアC😏:「業務に関係あるから大丈夫でしょ(笑)」 エンジニアA😨:「（それ、脱税に近いのでは…）」 業務との関連性が薄い私物まで経費として計上してしまうのは、節税ではなく脱税に近い行為です。 また、意図的でなくても、スーツや化粧品などを仕事で使うものだからという理由で、経費計上してしまっている方も結構います。 フリーランスって税理士を介さず、独学で確定申告している方が多いので、こういった間違った申告が行われることは多々あるそうです。 金額が小さければ、税務署もいちいち調査しないと思いますが、税務調査が入れば、追徴課税や罰則の対象になる可能性もあります、法に抵触するような脱税は辞めておいた方がいいでしょうね。 確定申告を楽にするおすすめ会計ソフト 青色申告のハードルとなる帳簿付けも、会計ソフトを使えば大幅に楽になります。 フリーランスや副業エンジニアに人気の会計ソフトには、以下のようなものがあります。 freee: 銀行口座やクレジットカードとの連携が強く、簿記知識がなくても使いやすい マネーフォワード クラウド確定申告: 家計簿アプリでも有名なマネーフォワードが提供、他サービスとの連携が豊富 弥生会計（やよいの青色申告 オンライン）: 老舗の会計ソフトで、サポート体制が充実している いずれも銀行やクレジットカードの取引を自動で取り込み、青色申告に必要な帳簿や決算書を自動作成してくれるため、独学でも大きな負担なく青色申告を続けられます。 おわりに 白色申告か青色申告かは、最終的にはその人の価値観や手間のかけ方次第ではありますが、できれば節税につながる青色申告をおすすめしたいところです。 帳簿付けの手間も、freee、マネーフォワード クラウド確定申告、弥生会計といった会計ソフトを使えば大幅に軽減できるので、ぜひ活用してみてください。 一方で、経費の範囲を都合よく解釈してしまうと、それは節税ではなく脱税に近づいてしまいます。 脱税は当然おすすめできません。 正しい知識に基づいて申告することを心がけたいですね。

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

はじめに 社会人になれば、皆が知識も精神も自立した大人になっているというイメージを持つ人は多いのではないでしょうか？ しかし、現実には、知識も精神も未成熟な方もいて、先輩や上司が皆、頼りになる大人とは限りません。 立場が上だからといって、常に正しいわけではないのです。むしろ、周囲の意見に流されず、自分のキャリアを主体的に考える姿勢が重要です。 本記事が、盲目的に周りの人の意見を受け入れるのではなく、自分のキャリアを自分で判断するきっかけになれば幸いです。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 借金を自慢するピエロエンジニア これは岡山県のある40代のエンジニアの方の友人との金銭トラブルの話です。 ご本人はコミュニティと称して、ジモティーでカフェ会などを開いているそうです。 その方はカフェ会で以下のような発言をしたそうです。 40代エンジニアさん😎:「友人が困っているから20万円貸したけど返ってこなかったことあるよ(キリッ)」 エンジニアA😳:「えっ、20万円も！？」 40代エンジニアさん😏:「自己投資(人生経験)だったと思ってるよ(ドヤ～)」 エンジニアA😳:「….(何で自信満々なんだ。。。)」 40代エンジニアさん😎:「コミュニティ運営してると色々あるからね(キリッ)」 エンジニアA😳:「….(コミュニティってカフェ会開いてるだけだろ、ピエロだな。。。)」 大金を人に貸すのはよくない、お金を返さないような人は友人ではない、という小学生でも分かることを理解できてないのに何故か自慢話のように語っているのです。 コミュニティと称してやっていることもハッカソンやアイデアソンなどではなく、 小規模なカフェ会やボードゲーム会で学生さんでもできるような大したことではなく、年齢に相応しい行動とは思えないですが、主催して人を集めている自分に酔ってしまい、客観的な分析ができなくなっているようです。 本当の友達を知ることのないまま大人になり、周りに担ぎ上げられたピエロのような社会人も世の中にはいるようです。 解説 大金を貸して返ってこないという失敗を「自己投資」と称し、反省すべき出来事を武勇伝のように語ってしまう金銭感覚の麻痺が問題です。 そもそも、お金を貸すような相手は本当の友人とは言えません。 ただ、社会人になっても友人と呼べる存在がいない人は、実は少なくありません。 そうした世間とのズレを出さないためにも、スポーツサークルなどのコミュニティに参加し、様々な人と交流を持つことをおすすめします。 おわりに 失敗を自慢話にすり替えてしまう姿勢は、周囲からの信頼を失うだけでなく、社会人としての金銭感覚そのものを鈍らせます。 自分のお金の使い道には常に責任を持ち、いい加減な社会人にならないよう日頃から意識しておきましょう。 関連記事 地方エンジニアにおすすめのフリーランスエージェント

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