Posts

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

  • POST
はじめに 「経験」や「勘」に頼って仕事を進める文化は、時に思いがけない成果物を生み出してしまいます。 今回は、社内の勉強会をきっかけに、勤怠管理ソフトのデザインが思わぬ方向に進んでしまった職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「エンジニアにデザインを任せてはいけない理由」 これは勤怠パッケージソフトを自社開発している神奈川県の中小企業での出来事。 社内の勉強会で、自社の勤怠管理ソフトのUIデザインを改善しようという話が持ち上がった。 メンバーH(若手)🙂 「せっかくなので、ペルソナを設定したデザイン設計の一連のプロセスを経験し、デザインの基礎をちゃんと学びながら進めませんか?」 勉強会リーダーI 😐 「ペルソナ設計ぃ? なんか時間かかりそうだなそれ。」 メンバーH(若手)🙂 「UI/UXの原則も踏まえて、視認性とか操作性とか一貫性とか、意識した方がいいと思うんですけど……。」 メンバーJ 😑 「なんか難しい話してるなー。もっと感覚でパッと決めちゃえばよくない?」 メンバーH(若手)😅 「いや、一連のプロセスを理解しないとスキルの取得にならないんじゃ……。」 勉強会リーダーI 😤 「今回はいいんじゃないの」 基礎的なプロセスを「面倒くさい」と感じたリーダーとメンバーたちは、結局、明確なコンセプトを決めないまま、思い思いの感覚でHTMLファイルの編集を始めた。 メンバーJ 😊 「ボタンのアイコン、てんとう虫にしてみようよ。」 勉強会リーダーI 🙂 「こっちは星型で。バランスも良さそうだし。」 メンバーH(若手)😨 「……勤怠管理ソフトに、てんとう虫と星のアイコンですか?」 勉強会リーダーI 😊 「可愛いからいいでしょ!」 コンセプトを誰も定めていなかったため、カラーリングの意図も統一されないまま、デザインは完成してしまった。 メンバーH(若手)😱 (このアイコン、実際に使う社員は何のボタンか分かるんだろうか……。) 出来上がった勤怠ソフトは、ボタンの各種アイコンがなぜか「てんとう虫」や「星」になっており、コンセプトが不明なままカラーリングの意図も分からない、残念な仕上がりとなってしまった。

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

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

本当にあった?エンジニアの怖い話「自分が言ったことを5分で忘れる理不尽上司」

  • POST
はじめに 仕事では「言われたことをそのまま実行したのに怒られる」という理不尽な出来事が起こることがあります。 この記事では、曖昧な指示や、認識の違い、記憶違いによる職場のトラブルを紹介します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 「自分が言ったことを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上で大規模な計算処理を実行していたらしい。

ギークスジョブの評判、口コミまとめ。地方在住者におすすめできるか徹底解説

  • POST
はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスギークスジョブについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 ギークスジョブとは ギークスジョブは、ITフリーランスエンジニア向けの案件紹介エージェントサービスです。 運営はギークス株式会社です。 ギークスジョブは最大手のレバテックフリーランスにつぐ、大手のエージェントで、多数の案件数やサポート体制を特徴としています。 高単価・長期案件を中心に、Web/業務系/インフラなど幅広い技術領域の案件を取り扱っています。 専任コンサルタントがキャリア相談、案件提案、単価交渉、参画後フォローまで一貫してサポートする点が特徴です。 特に実務経験2年以上のエンジニア向けの案件が多く、エンド直請けや大手企業案件も豊富です。 ギークスジョブ公式サイト .btn-wrapper { max-width: 600px; margin: 0 auto; padding: 20px 0; } .pink-btn { display: block; width: 90%; background: linear-gradient(#ff77bb, #ff4fa0); color: #fff; padding: 18px 0; border-radius: 8px; text-decoration: none; font-weight: bold; font-size: 18px; text-align: center; box-sizing: border-box; box-shadow: 0 4px 0 #d6458a, 0 6px 12px rgba(0,0,0,0.2); transition: all 0.2s ease; } .pink-btn:active { transform: translateY(3px); box-shadow: 0 1px 0 #d6458a, 0 3px 6px rgba(0,0,0,0.

本当にあった?エンジニアの怖い話「目標設定に四半期の約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たちは、前回の指摘との関係もわからないまま、また目標を修正する。

岡山県がシステム開発に向かない4つの理由

  • POST
はじめに 物事には地域ごとの向き不向きがある、というのはよく言われる話です。 例えば「立ち食いそば」は東京や大阪では駅前の当たり前の光景ですが、地方に行くとほとんど見かけなくなります。 これは単純な人口密度の差だけでなく、都市部特有のせっかちな気質や、通勤・移動の合間に短時間で済ませたいという生活スタイルが背景にあると言われています。 「少しでも早く」「立ったままでも構わない」という都市部の価値観があってはじめて成立する業態であり、時間にゆとりのある地方では同じ理屈が働きにくいわけです。 需要密度やビジネスの成立条件だけでなく、その土地の生活スタイルや文化と合っているかどうかが大きく関係していると言われています。 サッカーの世界でも同様の話があります。 中国は巨額のチャイナマネーを投じて自国リーグの強化を図りましたが、結果として世界トップレベルへの成長には至っていません。 理由の一つとして挙げられるのが、他人を信頼しない・組織のために動く協調性が根付いていないといった国民性が、パスをつないで連携するヨーロッパ型のサッカースタイルと相性が悪かった、という指摘です。 お金をいくら投じても、その土地の文化や気質と合わなければ、望んだ方向には育たないという典型例と言えるかもしれません。 これはシステム開発という仕事にも、同じことが言えるのではないかと思っています。 岡山で長年システム開発に携わっていると、「この土地はシステム開発とあまり相性が良くないのでは」と感じる場面がたびたびあります。 感覚論だけで語ると単なる愚痴になってしまうので、この記事ではできるだけ具体的な事実やデータを示しながら、岡山県とシステム開発の相性について考察してみます。 結論を急ぐ記事ではありません。最後まで読んでいただいたうえで、読者自身がどう感じるかを考えていただければと思います。 1. 図書館のIT関連キュレーションの弱さ 岡山県立図書館は、蔵書数・貸出数ともに全国トップクラスの実績を誇る図書館です。 実際に「都道府県立図書館 貸出冊数」で検索すると、岡山県立図書館は毎年上位にランクインしています。 一方で、IT関連書籍、特にAWS関連の技術書に絞って蔵書を確認すると、2026年時点で該当する蔵書は0冊でした。 他県の県立図書館では、地方であってもAWSやクラウド関連の書籍が一定数揃っているケースが多く、これは岡山県立図書館に限った傾向のように見えます。 読書文化自体は根付いている土地であるにもかかわらず、技術書という観点では選書が薄い。 これは図書館側の選書方針の問題という側面もありますが、裏を返せば「IT関連書籍を求める利用者の声がそれだけ少ない」ということでもあります。 岡山のIT従事者に読書習慣を持つ人が少ない、という仮説を補強する材料の一つと言えそうです。 2. ソフトウェア投資を嫌う文化 岡山のSier(システム開発会社)であっても、勤怠管理や会計処理にソフトウェアを導入せず、Excelで運用しているケースを何度も見てきました。 本業がシステム開発である企業自体が、自社の業務効率化にはソフトウェアへの投資を渋る、という状況です。 この傾向は企業だけでなく、個人のフリーランスエンジニアにも見られます。 クラウド会計ソフトを月額契約で使い続けるのではなく、確定申告の時期だけサブスクを契約してデータをエクスポートし、申告が終わるとすぐに解約するというやり方をしている人が少なくありません。 月額1,000円前後のコストを惜しむかどうかという話ではなく、「継続的にソフトウェアへお金を払う」という発想自体への抵抗感が強いように感じます。 システム開発を生業としながら、ソフトウェアへの投資に消極的というのは、なかなか皮肉な構図です。 3. 合理化・標準化を嫌い、型破りな人材を好む文化 システム開発の本質は、業務を合理化・標準化し、再現性を持たせることにあります。 その観点で見ると、岡山県民性そのものが合理化と相性が良くない側面を持っているように感じます。 例えば以下のような点です。 県内主要道路の渋滞の多さ(合理的な交通導線が整備されているとは言い難い) ウィンカーを出さずに車線変更・右左折をするドライバーが多い(ルールより経験則優先) 「とんかつラーメン」のような、効率よりも奇をてらった方向性のご当地グルメが好まれる いずれも一つ一つは些細な事象ですが、共通しているのは「ルールに則って合理化する」よりも「その場のノリ・ルーズさ」を許容する県民性です。 システム開発は良くも悪くも「決めたルール通りに動く」ことが前提の仕事なので、この県民性とは根本的に相性が悪いのかもしれません。 この傾向は、採用や評価の場面にも表れています。 会社によりますが、ルール通りに堅実に仕事を進める人材よりも、斬新なアイデアを出す型破りな人材の方が評価されやすい空気があります。 実際に岡山のシステム会社の経営者の中には、「うちの社員は色がある」ということを、むしろ自慢げに語る方もいます。 「色がある」こと自体は個性として悪いことではありませんが、システム開発という「決めたルール通りに正確に動く」ことが前提の仕事において、型破りであることを評価軸にしてしまうと、品質や再現性が犠牲になりやすいという側面もあります。 合理化を嫌う県民性と、型破りな人材を好む採用・評価の傾向は、根っこの部分でつながっているのかもしれません。 4. 第三次産業の弱さ 岡山県は製造業(第二次産業)の比率が比較的高い一方、情報通信業を含む第三次産業の集積は他の政令指定都市エリアと比べると弱いことがたびたび指摘されています。 システム開発企業やIT人材の絶対数が少なければ、当然コミュニティも育ちにくく、勉強会やカンファレンスの開催数、技術情報の流通量にも影響してきます。 「エンジニアが少ないから情報が集まらない」のか、「情報が集まらないからエンジニアが育たない・定着しない」のか、因果関係は一概には言えません。 ただ、いずれにしても第三次産業、特にIT分野の集積の薄さが、システム開発という仕事にとって向かい風になっているのは間違いなさそうです。 おわりに ここまで4つの観点から、岡山県とシステム開発の相性について考察してきました。 技術書へのアクセスのしやすさ ソフトウェアへの投資意欲 合理化・標準化を嫌い、型破りな人材を好む文化 第三次産業(IT)の集積度 いずれも「岡山だから絶対にダメ」と断言できるものではなく、あくまで傾向や仮説の域を出ません。 一方で、複数の観点から似たような傾向が見えてくるという事実は、それなりに示唆的ではないかと思います。 皆さんは、この4つの理由をどう捉えるでしょうか。 「たしかに」と感じる部分もあれば、「自分の周りは違う」と感じる部分もあるかもしれません。 もし岡山でシステム開発の仕事をしている方、あるいはこれから岡山でのキャリアを考えている方がいれば、ぜひ自分の経験と照らし合わせて考えてみてください。

PE-Bankの評判、口コミまとめ。地方在住者におすすめできるか徹底解説

  • POST
はじめに この記事では、フリーランスITエンジニア向け案件紹介サービスPE-BANKについて解説します。 岡山県など地方在住者におすすめできるかも含めて、メリット・デメリットを整理しました。 PE-BANKとは PE-BANKは、ITエンジニア専門の案件紹介サービスです。 1989年創業の老舗で、エンジニア主体の共同受注モデルを採用しています。 共同受注モデルなので、契約内容に透明性があり、マージン率が公開されているため、良心的なフリーランスエージェントと言われています。 運営会社: 「株式会社PE-BANK」 PE-BANKの運営会社は株式会社PE-BANKです。 同社は、フリーランスITエンジニア向けの共同受注事業を中心に展開する企業で、1989年創業の実績ある会社です。 項目 内容 会社名 株式会社PE-BANK 設立 1989年 所在地 東京都港区高輪2-15-8 グレイスビル泉岳寺前 事業内容 ITエンジニア共同受注事業 上場 非上場 長年にわたりエンジニア主体のビジネスモデルを継続しており、全国に拠点を展開している点が特徴です。 PE-BANKの特徴 項目 内容 対応エリア 全国(主要都市に拠点あり) リモート案件 一部あり(常駐案件が中心) 案件数 非公開(全国で常時多数) 平均月単価 60万〜80万円前後 消費税表記 税抜き表示が基本 マージン率 公開制(参画期間が長いとその分マージン率が下がる仕組み、10~15%前後) 福利厚生 共済会制度あり(保険・税務サポート等) 特徴 高還元率とマージン公開の透明性が強み PE-BANKは、1989年創業の老舗フリーランスエージェントです。 エンジニア主体の「共同受注」モデルを採用し、報酬還元率の高さと透明性を重視しています。

中小企業ではスキルアップができない理由

  • POST
はじめに 「なぜ中小企業ではスキルが伸びないのか」—— 転職や異動を経験した人なら、この疑問を感じたことがあるかもしれません。 大企業と比べて研修制度が整っていない、という指摘はよくあります。しかしそれだけではなく、組織文化や個人の習慣レベルに深い根本原因が存在します。 表面的な「研修がない」「予算がない」という理由の背後には、目標設定能力の欠如、学習に対する姿勢の問題、そして日常的な生活習慣まで、複合的な要因が絡み合っています。これらは一朝一夕には解決できず、組織全体の文化として根付いているケースがほとんどです。 本記事では、実際の現場で起きた事例をもとに、中小企業でスキルアップが進まないの理由を解説します。 本記事は、個人や企業を誹謗中傷することを目的としたものではなく、以下を目的としています。 企業からは都合の良い情報しか発信されないことが多いため、求職者が一方的な情報に惑わされないようバランスを取る 仕事の中で起こりうる想定外な出来事や、理不尽な出来事をあらかじめ知り、対処や心構えの一助としていただく 業界に対して不満はあるが、立場上声を上げにくい現場の方々に代わって、内情を吐露することでガス抜きの場とする 実体験をもとに、なかなか表に出てこない業界の実情をお伝えし、学生やエンジニア、マネージャーの皆様の今後のキャリア選択に役立てていただければ幸いです。 1. 目標設定と達成プロセスが機能しない 中小企業だとメンバーの論理的思考力や語彙力に長けた社員が少ないため、目標設定自体ができないケースが多々あります。 以下の例では、目標設定メソッドにマンダラチャートを採用しましたが、社員のスキルの低さから、目標設定ができずに終わってしまったようです。 本当にあった?エンジニアの怖い話「マンダラチャートで目標すら立てられない会社のPDCA」 —— 論理的思考力の弱さから目標設定そのものが機能しなかった事例 目標を立てる能力が弱い組織では、スキル向上の仕組みそのものが成立しません。 論理的思考力がなければ「何を・いつまでに・どうやって」という構造で考えられないため、計画は絵に描いた餅になります。 目標を設定すること自体にもスキルが必要で、適切な目標設定をできない組織にいる限り、成長は難しいのではないかと思います。 目標設定に時間がかかり過ぎる 本当にあった?エンジニアの怖い話「目標設定に四半期の約1/4を消費する会社」 —— 目標設定の仕組みが整っておらず、議論だけで大量の時間を消費した事例 目標設定のノウハウが組織に蓄積されていないと、毎回ゼロから議論を始めることになり、肝心の実行期間そのものが削られてしまいます。 さらに厄介なのは、「時間をかけた=真剣に取り組んだ」という誤った達成感で終わってしまい、プロセス自体の非効率さが問題として認識されにくい点です。 目標設定に時間がかかること自体は個人の努力不足ではなく、仕組みが整っていない組織のサインであり、そうした環境ではスキルアップに使うべき時間がそもそも確保できません。 自分本位の考えを重視し、教科書通りの学習をしない 本当にあった?エンジニアの怖い話「勤怠ソフトのボタンをてんとう虫にする会社」 「経験」や「勘」に頼って仕事を進める文化では、教科書的な手法が「理屈っぽい」「現場をわかっていない」と軽視されがちです。 しかしこの文化のもとでは正しい方法論を学ぶ動機自体が生まれず、再現性のあるスキルが身につきません。 感覚的な判断は個人の経験に強く依存するため、他のメンバーへの知識移転もできず、組織として学習が積み上がっていかないのです。 技術への興味が薄く、知識が広がらない 事例 これは、複数の物理サーバーを管理するプロジェクトの事例です。 あるプロジェクトで、複数のサーバーに対して同時にコマンドを実行できるSSHクライアント「Rlogin」を選定・採用しました。 このRloginを使うことで、同じ作業を各サーバーに個別に実施する手間が大幅に削減でき、ヒューマンエラーのリスクも低減できます。 導入した担当者は事前に動作検証を行い、Rloginがプロジェクトの要件にも合致していることを確認した上での採用でした。 ところが、このツールをプロジェクトで展開しようとしたとき、ベテラン社員から思わぬ反発を受けました。 「Teraterm以外のツールは聞いたことがない。有名なツールではない。」 という理由だけで、「基礎を無視したやり方だ」「なぜ実績のあるツールを使わないのか」と担当者に対して批判的な意見が述べられました。 ツールの選定基準として本来評価すべきは、プロジェクトとの適合性のはずです。 しかし実際には、「自分が知っているかどうか」が唯一の判断基準になっていました。 結果として、このツールの採用は見送られ、効率の悪い従来の手作業が継続されました。 理由 ツールの知名度や自分の馴染みで技術を評価する文化が存在すると、合理的な判断ができなくなります。 この姿勢の根本には、技術への好奇心の欠如があります。 「知らないものは怖い」「今のやり方で困っていない」という意識が強いと、新しい技術や手法を積極的に学ぼうとする動機が生まれません。その結果、知識が特定の範囲に固定されたまま広がらず、技術の進化に取り残されていきます。 また、このような文化では新しい提案をした人が「基礎がわかっていない」と逆に批判されるため、若手エンジニアの学習意欲を削ぐ効果もあります。 知識を広げようとする行動がリスクになる組織では、現状維持が最も合理的な選択になってしまいます。 2. 学習を阻害する生活習慣 事例 これは、特定の1社ではなく、複数の中小企業で共通して見られた傾向をまとめた事例です。 スキルアップには継続的な努力が必要です。しかし、日常の生活習慣がその継続を根本から阻害しているケースが少なくありません。 具体的には、 業務後にパチンコや競馬などのギャンブルを日課にしている 喫煙の頻度が非常に高く、就業中も離席が多い 飲酒量が多く、翌朝に疲労が残った状態で出勤する スマートフォンのSNSやゲームに長時間費やしている といった習慣を持つ人が、複数の中小企業の現場で一定数見られました。

東京に上京しても最新技術を習得できるとは限らない

  • POST
はじめに エンジニアのキャリアを考えるとき、「東京に行けばもっと最新技術に触れられる」「地方にいては技術力が遅れてしまう」と考える方は多いのではないでしょうか。 確かに東京には多くのIT企業が集中しており、案件数も豊富で最新技術が採用されやすい環境があります。 しかし、東京に上京したからといって、必ずしも最新技術を習得できるわけではありません。 この記事では、東京と地方のエンジニア環境を比較しながら、上京を検討しているエンジニアが知っておくべき現実について解説します。 東京のメリット 案件数・技術スタックの多様性 東京にはIT企業が数多く存在し、案件数も地方と比べてはるかに多く、プロジェクトで採用される技術スタックも比較的新しいものが採用される傾向があります。 最新のクラウド技術やモダンなフロントエンドフレームワーク、AIを活用したシステム開発など、先進的な取り組みをしている企業も多く存在します。 東京のデメリット 案件数が多い分、「案件ガチャ」がある 日本国内の企業のほとんどは中小企業です。案件数が多いがゆえに、以下のようなケースにアサインされるリスクも存在します。 マイナーな技術を採用したプロジェクト: 需要が限定的で、転職市場での汎用性が低い技術を使い続けることになる システム開発と関連性が低い作業: 運用監視や単純なデータ入力など、エンジニアとしての成長につながりにくい業務 レガシーシステムの保守: 最新技術とはかけ離れた古いシステムの維持管理 人間関係の課題: プロジェクトのステークホルダーとのコミュニケーションがうまくいかなかったり、メンバーの技術スキルが低く、レビューやサポートに想定以上の工数を取られる いわゆる 「案件ガチャ」 と呼ばれる状況があり、良い案件に当たればスキルアップのチャンスになりますが、そうでない場合のリスクも無視できません。 上京してもスキルアップできる保証はなく、運次第という側面があるのが現実です。 地方のメリット 使用技術の汎用性 地方で仕事をする場合でも、技術スタック自体は必ずしも時代遅れではありません。 マイナーな技術ではなく、業界で広く使われているメジャーな技術を用いた開発が多いため、習得したスキルが汎用的に活かせるケースが少なくありません。 昔からあるJava、C#など需要の高いプログラミング言語 AWS、Azureなど広く普及しているクラウドサービス SQL Serverやpostgrresqlなど標準的なデータベース 取引先は都市部の企業 地方に拠点を置いていても、実際の取引先はほぼ東京・大阪などの都市部の企業になることが多いです。 地方に就職したからといって、仕事内容が大きく変わるわけではありません。 リモートワークやオンライン会議の普及により、物理的な距離のハンデはかつてより小さくなっています。 生活コストが安い 地方と東京では生活コストに大きな差があります。 項目 東京 地方(岡山など) 家賃(1K) 8〜12万円 4〜6万円 駐車場代 2〜5万円 3,000〜5,000円 物価全般 高い 比較的安い 年間で50万円以上の差が出ることも珍しくありません。

AIツール向けタスク管理ツール「Beads」入門

  • POST
はじめに この記事では、 AIコーディングエージェント向けのタスク管理ツール「Beads (bd)」を紹介します。 Claude Codeなどのエージェントにタスクを記憶させ、セッションをまたいだ作業管理を可能にするツールです。 beadsとは AIエージェントが使用することを前提に作られたタスク管理ツールです。 bdコマンドというCLIを使ってタスク管理ができます。 CLIでタスクを操作できることから、Claude Codeなどのバイブコーティングツールを使用する開発者から高評価を得ています。 GitHub - gastownhall/beads: Beads - A memory upgrade for your coding agent GitHub Issueなどとの違い プロジェクトのタスク管理というとGitHub Issueが古くから使われていますが、GitHub Issueとbeadsのメカニズムの違いや、beadsを使うメリットは以下の通りです。 依存関係の設定ができる このタスクを完了しないと次のタスクを実行できない、といった複雑な依存関係の設定が可能です。 DBとJSONLでタスク管理 DBファイルとjsonlファイルの2つを用いてタスクを管理します。 DBファイル上でタスクのステータス、優先度、説明などが記録されています。 軽量な内部DBにクエリを実行することで、エージェントは必要な情報のみを参照でき、コンテキストの肥大化を防げます。 DBへの変更はjsonlファイルにも同期され、人間にも読みやすい形式で表示されるため、Gitなどのバージョン管理ソフトで差分を確認できます。 ローカルのDBファイルを用いるので、クラウドを使わずオフラインでも動作します。 コマンドラインから操作できるので、AIエージェントからも操作が可能です。 エージェントにセッションをまたいだ情報を記憶させるrememberコマンドなど、エージェント向けの機能があります。 初回セットアップ # Windowsにbeadsをインストール irm https://raw.githubusercontent.com/gastownhall/beads/main/install.ps1 | iex ## 環境変数 Pathに以下のPathを設定 >> ==> bd installed to C:\Users\pocke\AppData\Local\Programs\bd\bd.