スキルアップ

本当にあった?エンジニアの怖い話「自分で作ったファイルを忘れるマン」

  • POST
はじめに 脳科学的に見ても、記憶力には個人差があり、物事を覚えておくのが苦手な人は一定数存在すると言われています。 実際、自分が作ったファイルの場所がわからなくなり、人に聞いてしまうという方も少なくありません。 本記事では、作業報告書の提出をめぐって起きた、ある岡山のシステム会社のPLとエンジニアのやり取りを紹介します。 「自分で作ったファイルを忘れるマン」 これは岡山のとあるシステム会社での出来事。 社員数数十名規模のこの会社では、複数の顧客のシステム保守・開発プロジェクトが同時に進行しており、PLも複数のプロジェクトを兼任するのが当たり前の環境だった。 このPLは、兼任するメンバーの作業時間を集計し、毎月作業報告書として顧客に提出する責務を負っていた。 しかし本業が多忙で、報告書作成の作業がいつも後回しになっていた。 見かねた部下のエンジニアAが、報告書作成を手伝うと申し出た。 エンジニアA 🙂 「PLの作業時間を教えてください。代わりに記載しておきますよ。」 PL 😑 「うーん、複数プロジェクト兼任してるから一概に言えないんだよね……。」 PLは言葉を濁し、結局時間を教えなかった。 それでもエンジニアAは食い下がらず、歩み寄った提案をする。 エンジニアA 🙂 「では、自分以外のメンバーの時間は私がまとめます。PLは自分の分だけ書いてもらえますか?」 PL 😐 「あ、うん、わかった。」 そう答えたものの、それ以降もPLは自分の作業時間を記載せず、報告書のPL欄だけが空欄のまま数ヶ月放置される状態が続いた。 数ヶ月後、PLが突然エンジニアAに連絡してきた。 PL 😐 「作業報告書ってどこに置いてる?」 エンジニアA 🙂 「PLがいつも置いてるファイルサーバにありますよ。」 PL 😐 「いや、そうじゃなくて。顧客に提出したファイルがどこにあるか知りたいんだけど。」 エンジニアAは一瞬戸惑った。 報告書の提出はPLの役目であり、提出していれば自分の送信メールボックスに残っているはずだ。 そもそもPL自身が作業時間を記載していないため報告書自体が完成しておらず、提出できるはずがなかったのである。 エンジニアA 🤔 「……そもそも報告書、PLの作業時間欄が空欄のままなので、まだ完成していないと思うんですが。」 PL 😳 「……。」 エンジニアA 😳 「もしかして、提出していないんじゃないですか?」 指摘を受けたPLは一瞬呆然とした。 PL 😳 「……。」 そのまま謝罪や礼を口にすることもなく、PLは無言でその場を去っていった。 解説 今回のPLは、自分が報告書を完成させていない事実を認識できておらず、代わりに提出先を他人に尋ねるという矛盾した行動に出てしまいました。 このような相手には、相手が記憶していないという前提で会話をすすめると有効です。 例えば、打合せ前に「前回の打合せでは〇〇という状況でしたが~」のように会話に前回の情報を付与することで、認識違いがでにくくなります。 おわりに 記憶力の低さそのものは個人の特性であり、責められるべきものではありません。 しかし、それを理由に自分の役割を放棄してしまうようでは本末転倒です。

本当にあった?エンジニアの怖い話「エンジニアにデザインを任せてはいけない理由」

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

本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」

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

本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」

  • POST
はじめに 目標管理制度を初めて導入する会社では、思わぬところでつまずくことがあります。 今回は、目標設定そのものに膨大な時間がかかってしまい、肝心の業務改善に手が回らなくなってしまった職場のトラブルを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 「目標設定に四半期の約1/4を消費する会社」 これは設立30年以上の中小SIerでの出来事。 これまで目標管理の仕組みが存在しなかったこの会社で、経営層の意気込みのもと、初めて全社員による個人目標設定が導入されることになった。 現場を統括する課長Hが自身のチームの目標を作成し、役員Fへの説明の場に持ち込んだ。 課長H 🙂 「今期のチーム目標は『担当システムの保守品質を向上させる』としました。」 役員F 😐 「そんな目標じゃ、ぬるい。もっと危機感を持って考えろ。」 課長H 😳 「危機感……ですか。具体的にはどのあたりを……」 役員F 😠 「そんなことまで俺が説明しなきゃいけないのか!お前がチームの責任者だろう!!」 課長Hは何が悪かったのか具体的な説明を得られないまま、感情論だけで目標を突き返された。 しかし部下への説明の場では、役員から言われたことを何とか自分の言葉に変換しようとする。 課長H 😓 (役員は「危機感」とか「ぬるい」って言ってたな……つまり、もっと厳しくすればいいのか?) 課長H 🙂 「みんな、今期の目標だけど、もっと危機感を持って厳しめに設定しよう。」 部下G 🤔 「危機感、というのは具体的にどういう……」 課長H 😅 「いや、そこはお前らで考えてくれ。とにかく緩い目標はダメだって話だから。」 部下Gたちは意図のつかめないまま、とりあえず数値を厳しくした目標を作り直し、再び課長Hを経由して役員Fへ持ち込む。 課長H 🙂 「危機感を持たせた目標に修正しました。」 役員F 😡 「なんだこれ、数字だけ厳しくすればいいってもんじゃないだろ!!本質を考えろと言ったはずだ!!」 課長H 😨 「す、すみません……」 課長Hはまた役員から罵声を浴びるが、「本質」という言葉の意味も具体的にはつかめないまま部下の元へ戻る。 課長H 😰 「役員から、本質を考えろって言われたんだ。もう一度、本質的に考え直してくれ。」 部下G 😔 「本質……というのは、前回の『危機感』とは違う話ですか?」 課長H 😩 「いや……それは……とにかく、もっと深く考えてくれ。」 部下Gたちは、前回の指摘との関係もわからないまま、また目標を修正する。 このやり取りが何度も繰り返され、目標は一向に固まらなかった。 部下G 😩 (もう4回目の書き直しだ……何を直せばいいのか、誰にもわかっていない。) 課長H 😥 (役員が何を言いたいのか、自分にも正直よくわかっていない……。) 気づけば、目標設定だけで3ヶ月以上が経過していた。

岡山のSierのキャリアの特徴

  • POST
はじめに 岡山でエンジニアとしてキャリアを積む場合、どのようなスキルセットが求められるのか、どのような経営スタイルの企業が多いのかを把握しておくことは重要です。 この記事では、岡山のSierにおけるキャリア形成の特徴と、企業の経営方針について解説します。 岡山のSierのキャリア 新人研修の内容はだいたいどこの企業も同じ 新人研修の内容は首都圏でも岡山の企業でもだいたいどこも同じ内容で、社会人マナー、エンジニアの基礎、JAVA、SQL、アルゴリズムなどの学習が一般的です。 また、FSA(富士通系ソフトウェア業グループ)に加入している場合は、FSAに加入している企業が合同で研修することになるので、全く同じ研修を受けることになります。 業務時間外に社内勉強会を実施しているケースがある 求職者に社内勉強会を実施していることをPRしている企業は結構あるのですが、多くの場合、社内勉強会は無給です。 また、業務時間外にも関わらず社内勉強会へ参加を強要されるケースもあるので、社内勉強会の実施を過剰にPRしている企業には注意したほうがいいでしょう。 読書感想文の提出 会社から推薦された書籍について、感想文の提出を強要されるケースがあるようです。 書籍を推薦するだけならいいのですが、読書と感想文を強制されるとプライベートの時間を拘束されることになるので、従業員側としてはデメリットですよね。 推薦図書などの教育制度がないか確認し、感想文の提出のありなしがないか掘り下げて質問してみるといいでしょう。 昇格試験は面接や論文の提出が一般的 役職を上げるための昇格試験は、面接や論文の提出が一般的です。 ここは首都圏の企業と大きな違いはありません。 スペシャリストより、ゼネラリストが求められる PE-Bankというフリーランスエンジニアのエージェントさんから伺った話なのですが、 地方の企業では、特定の分野に特化したスペシャリストよりオールラウンダータイプのゼネラリストになることを求められるそうです。 つまり、複数のプログラミング言語が使えたり、アプリケーションとインフラストラクチャ両方に知見があるというタイプのエンジニアが重宝されやすいということになります。 地方だと案件数や使用する技術の種類は少ないですが、エンジニアの数も少ないので、一人のエンジニアを色々な案件で使い回すので、何でも屋タイプのエンジニアが多くなったり、 プロジェクトマネージャーがプロジェクトの必要なスキルを理解しておらず、とりあえずゼネラリストを必要するケースが多いのが要因だと思われます。 地方でスペシャリストを目指す場合、自身の希望する技術を使ったプロジェクトにアサインされるように、自身のスキルを社内やクライアントにPRするようにしたほうがいいでしょう。 基本的には固定顧客との関りが中心 システムエンジニアというと、取引先が多様な業界のため、様々なプロジェクトにアサインされるイメージもありますが、 基本的には同じクライアントのプロジェクトにアサインされることになるので、人によりますが、基本的には固定顧客としか関わりがなく、 特定の業界の知識に特化した知識が身につくケースが多いです。 ダイバーシティ・多様性 女性採用は少ない 人口が少なく、業界的にも女性に不人気の業界なので、女性の採用人数は少ないです。 新卒で女性採用0人の年も珍しくないようです。 必然的に女性の管理職の方も少ないです。 これも業界あるあるですが、技術系の女性社員と、総務部系の女性社員の方はキャラクターが結構違ったりするので、 確執が生まれたり、微妙な人間関係になることもあるんですよね。 同性の同僚と良好な関係を築きたいと考えている方は、女性の採用人数が多い会社に入社したほうが趣味趣向が同じ方を見つけやすいので、孤立するリスクを削減できるかもしれません。 発達障害の方への理解度や対応方針は未整備 ある小学校では小学1年生の10人に1人が発達障害だったというデータもあるように、 発達障害を持たれている方は意外に多いということが認知されつつあると思います。 自分自身が発達障害を持っているかもしれないし、発達障害を持っている方と仕事をする場合もあると思います。 特にSierの場合、プログラミングなど論理的思考力が必要なタスクが多いため、発達障害者の方がタスクを期限内に遂行することは困難な場合があります。 発達障害の疑惑があった場合に周りの従業員でフォロー体制を敷いたり、軽作業を割り当てる、障害者雇用に関する助成金を活用するなどの対応が企業には必要な対応なります。 ただ、岡山では中小企業が多い関係で、発達障害への理解度は低く、総務部に相談しても、問題を先送りにされて、特に対応して貰えないそうです。 また、周りの社員も発達障害を持つ人がいるという認識が薄いため、仕事ができない社員に対して、笑ったり、不満を言うだけになってしまうようです。 岡山のSierの経営方針 トップダウンの企業が多い 岡山の企業に務めている方に聞くと、トップダウンの企業が多いという意見をよく聞きます。 一族経営の企業もあり、経営者の意向が強く反映されやすいのが、岡山の企業の特徴のようです。 入社前に経営者の考えが、自分にフィットしているか確認しましょう。 転職事情 同業他社への転職を渋る文化がある 県内のSierは同じ組合などに加入していることあり、お互いに良好な関係を築こうという風潮があるため、同業他社からの引き抜きは基本的にご法度とされているそうです。 そのため、退職前に転職活動をすると、引き抜きの疑いがかかるのを嫌って採用を渋るケースもあるようです。 転職が活発なIT業界の中で、転職に否定的な風土があるのは、岡山ならではの特徴と言えますね。 とはいえ、同業他社への転職ができないケースという訳ではなく、退職前に転職活動をして採用されている人もいるようなので、すごく曖昧な風潮のようです。 岡山では、トラブルを避ける意味でも前職の会社に転職先の企業名を伝えるのはやめたほうがいいでしょう。 中途採用は少ない 地方だと人口が少ないので、中途採用者0名という年も珍しくないようです。 まとめ 岡山のSierでキャリアを積む際の主なポイントをまとめます。 新人研修の内容は首都圏とほぼ同様(社会人マナー・Java・SQL等) ゼネラリスト志向が求められることが多く、スペシャリストを目指す場合は自己PRが重要 同一クライアントのプロジェクトにアサインされ続けることで、特定業界への深い知識が身につく トップダウン・一族経営の企業も多く、経営者との相性確認が重要 同業他社転職は慣例的に敬遠される文化がある 中途採用の枠は少ない スペシャリストとしてのキャリアを希望する場合は、入社前にキャリアパスについて明確に確認しておくことをおすすめします。

岡山のSEのための技術力向上ガイド2025

  • POST
はじめに 岡山でシステムエンジニアとして働く上で、技術力の維持・向上は重要な課題です。 地方では首都圏と比べて最新技術に触れる機会が少なかったり、技術コミュニティの規模が小さかったりと、スキルアップの環境面で不利な点もあります。 しかし、現代ではオンラインリソースの充実により、場所に関係なく技術力を高めることが可能になっています。 この記事では、岡山で働くSEが技術力を向上させるための実践的な方法を紹介します。 オンライン学習リソースの活用 プログラミング学習プラットフォーム 場所を問わず学習できるオンラインプラットフォームを活用しましょう。 Udemy 世界最大級のオンライン学習プラットフォームです。 セール時には90%オフで購入できることも多く、コストパフォーマンスに優れています。 特にAWS、Azure、React、Pythonなど実務で使える技術の講座が充実しています。 https://www.udemy.com/ Coursera / edX 大学レベルの本格的なコンピュータサイエンスを学べるプラットフォームです。 スタンフォード大学やMITなどの有名大学の講座を無料で受講できます。 英語が中心ですが、字幕付きの講座も多いです。 https://www.coursera.org/ https://www.edx.org/ Progate / paiza 日本語でプログラミングの基礎を学べるサービスです。 初心者の方や新しい言語を学ぶ際の入り口として最適です。 https://prog-8.com/ https://paiza.jp/ 技術書の読書 技術書典 同人誌形式で最新技術の書籍が手に入ります。 オンライン開催もあるため、岡山からでも参加可能です。 実務に即した知識が得られる良書が多く揃っています。 https://techbookfest.org/ O’Reilly Learning IT技術書の出版社O’Reillyの電子書籍読み放題サービスです。 月額49ドルで膨大な技術書にアクセスできます。 英語が読めるエンジニアには非常にお得なサービスです。 https://www.oreilly.com/ Kindle Unlimited 月額980円で対象の技術書が読み放題です。 入門書からある程度実践的な内容まで幅広くカバーされています。 岡山のエンジニアコミュニティへの参加 地域のコミュニティ活動に参加することで、同じ地域のエンジニアとの交流や情報交換ができます。 岡山エンジニア座談会 岡山のエンジニアが集まる定期的な勉強会です。 技術トークや情報交換の場として活用できます。 https://okayama-engineer.connpass.com/ 岡山WEBクリエイターズ Web制作やデザインに関する勉強会を定期的に開催しています。 フロントエンド技術やUI/UXに興味がある方におすすめです。 https://www.okaweb.jp/ GDG 岡山 Google技術を中心としたコミュニティです。 Google I/O Extendedなどのイベントを開催しています。 TechGuild Azureやクラウド技術に関するハンズオンセミナーを開催しています。 実践的なスキルを学べる機会です。 岡山.rb / 岡山.go など プログラミング言語ごとのコミュニティも存在します。 connpassやDoorkeeperで検索すると見つかります。