自力で生きる方法を探すために、ITで仕組みを作る基礎を発信するブログ。

AIで今後自分の仕事はどうなる？｜AI時代に作業者のままでは危ない理由

「AI で仕事がなくなる」「いや、AI を使えば生産性が上がるから大丈夫」。この 2 つの極論の間で、現場のエンジニアは止まりやすくなっています。脅威論を読んでも具体的に何をすればよいか分からず、楽観論を読んでも自分の業務にどう当てはめてよいか分からない。SES として客先で働いている方も、プロパーとして社内システムを担当している方も、運用保守やインフラの現場にいる方も、同じ位置で立ち止まっています。この記事はその停止を解くための入口記事です。結論から先に書いておくと、危ないのは AI そのものではなく ...

n8nでAI自動化するとAPI課金が膨らむ理由：構造と用途別の月額試算

n8nを使って「Gmail分類を自動化したい」「ニュース要約を毎時回したい」と組み始めたところ、月末に届いた OpenAI や Anthropic の請求額を見て初めて「思っていた金額と桁が違う」と気付く。そんな経験をしている個人エンジニアや小規模事業者は少なくありません。n8n 自体の月額は数千円で済んでいるのに、AI API 側だけが数万円単位に跳ね上がっている、というケースが特に多く起きています。ここで多くの方が混乱するのは、n8n の execution 課金と AI API の従量課金が「同じ ...

ChatGPT月額・APIとローカルLLM、何が違うのか：AIの使い方は3種類ある

ChatGPT Plusに入っているのに、n8nからAIを呼ぼうとしたらAPIキーを求められて止まった。この時点で、多くの人は「自分の設定が悪い」と考えます。しかし、そこで詰まっている原因は設定ミスではありません。ChatGPTのサブスク、OpenAI API、ローカルLLMは、そもそも使う場所も料金の仕組みも違う別物です。ここを混同したままAI自動化に進むと、月額課金しているのに自動化で使えない、API課金がどこで発生しているかわからない、ローカルLLMなら無料で代替できると勘違いする、という順番 ...

AIで速くなるエンジニア・遅くなるエンジニア｜作業種別ごとの効率差

「AI を使うエンジニアと使わないエンジニアでは、本当に生産性に差が出るのか」という問いは、現場でも発注側でも繰り返し議論されています。SNS では「AI で 10 倍速くなった」という声がある一方、Microsoft Research が示した 55% 短縮や、METR 研究が示した熟練者で 19% 遅くなったという結果が並列で流通しており、読み解き方を間違えると判断を誤ります。本記事は、作業種別ごとの効率差マトリクスを軸に、定量データ・逆効果になる条件・受託発注側の解釈指南までを一気通貫で整理します ...

退場意思を出してもみ消された話と、それを防ぐために必要だったこと

以前参画していた現場での話です。手術と入院を伴う治療が必要になり、医師から現場作業を止めるよう指示されました。現場に多少の不満はありましたが、離脱を申し出た直接の理由はそこではありません。治療と入院を優先しなければならなくなったからです。プロジェクト離脱の意思は文面で伝えました。ですが、間に入っていたエージェントは目先の利益だけを優先し、離脱の確定を有耶無耶にしたまま引き延ばし続けました。返信は来ませんでした。その一方で、現場では何事もなかったように次月のタスクが振られ続けました。こちらは入院の日程が迫 ...

そもそもIT業界のエージェントとはなにか？｜人材紹介・派遣・SES営業の違い

IT業界で「エージェント」という言葉を使うとき、その中身を正確に理解している人は少ないです。現場に入っているエンジニアも、案件を持ってくるエージェント側の営業も、実態として契約形態の違いをきちんと把握していないケースがほとんどです。その無理解が、法的に負う必要のない責任をエンジニアに背負わせ、現場から離脱できない状況を生み出しています。この記事では、契約形態の違いを整理しながら、なぜその構造が生まれるのかを明確にしていきます。 IT業界で「エージェント」と呼ばれている相手は一種類ではない IT業界で「エー ...

エージェントが曖昧にしがちな責任分界の話

SES案件に参画するとき、担当範囲や指揮命令系統をエージェントから明確に伝えられた経験がある人は少ないと思います。それはエージェントが怠けているからではありません。責任分界を確認することが、エージェントの業務に最初から含まれていないからです。エージェントの業務は、希望条件のヒアリングから始まり、案件とのマッチング、契約締結、定期連絡で終わります。現場に入った後、担当範囲がどこまでか、指揮命令は誰が持つか、問題が起きたときの責任はどこにあるか、これらを確認して伝える業務はどこにも存在しません。その結果、 ...

欧米生まれの現代奴隷商、それがSESの正体

現場で何かがおかしいと感じているなら、それは気のせいではありません。指示が噛み合わない、誰も決めない、問題を上げても何も変わらない。その感覚の正体は、あなたのスキル不足でも、現場の運の悪さでもありません。商流の深さが生み出す構造的な必然です。 SESという業態は、人を何層にも転売することで成立しています。商流が深くなるほど、現場の実態は上に届かなくなり、責任は拡散し、負荷だけが末端の実務者に落ちてきます。そしてその末端とは、現場で唯一「現実」を知っているあなたのことです。この記事では、深い商流がどのよう ...

SESエンジニアが案件参画前に確認しないと危険な項目

現場に入ってから「こんなはずではなかった」と気づいても、すでに遅いことがあります。契約は締結済み、常駐は始まっている。そこから条件を変えようとすれば、相手も体制も、すでに「あなたがいる前提」で動いています。エージェントは案件を紹介します。しかし、「あなたがその案件に合っているか」「その現場が安全か」を判断するのは、最終的にあなた自身です。エージェントが持ってくる情報だけで判断すると、入場後に取り返しのつかない状態になることがあります。あなたはこれまで、参画前に何を確認してきましたか。「なんとなく合いそ ...

SESの現場で手が止まったら読む話。外から整理するという選択肢

10年ぶりにSESの現場に入って、最初に感じたのは違和感でした。チームとして機能しているように見えるのに、メンバーが完全な他人として動いている。協業が生まれない。ベテランがほとんどいない。そして必ず、追い詰められているメンバーとそうでないメンバーに分かれている。この違和感の正体を考え続けたとき、一つのことが見えてきました。現場で手が止まっているエンジニアには、共通したメカニズムがあります。現場の問題でも、本人の能力の問題でもなく、SES現場という構造そのものが、エンジニアを一人で追い詰めるように機能して ...

SES現場のシェル問題を一段上から俯瞰すると見えてくること【40代】

前回のPART-Ⅲでは、現場が「動いているのに前に進まない」5つの構造的な理由を整理しました。今回はその中で最も具体的な形として表れやすい問題を取り上げます。設計書はある、仕様もある、担当者もいる。それでも作業が進まない。SES現場でよく見るこの状態の正体を、実体験をもとに整理します。 ShellはJavaやPythonのようなアプリケーション開発言語とは位置づけが異なります。サーバー上でのバッチ処理、ログ整理、定期実行、ファイル操作——インフラエンジニアであれば、業務の中で自然に使いこなしているはずの技 ...

40代SESで「動いているのに前に進まない」5つの構造的理由

PART-Ⅰ・Ⅱで書いたのは、「考えることをやめた状態」がどう生まれるかという話でした。今回はその続きになります。現場で止まっているエンジニアを外から見ていると、あるパターンが繰り返し出てきます。スキルが足りないわけではありません。経験が浅いわけでもありません。むしろ10年・20年と現場を渡り歩いてきた人間が、ある時点から「動いているのに前に進まない」状態に入っています。厄介なのは、止まっているのが個人だけではないことです。気づくとプロジェクト全体が謎の停滞に入っています。全員が動いています。会議も進んで ...

【40代】SESで考えることをやめたエンジニアの実情 | PART-ⅠI

前回の記事では、40代SESエンジニアが現場で止まる理由は、年齢や最新技術不足ではなく、Shell、Linux運用、設計読解、ログ切り分けの弱さにあると整理しました。今回はその続きです。現場で詰まらない人が最低限持っている土台と、今の自分が危険な状態かを見分ける基準を、実務に直結する形で整理します。読み終えたときに、自分が次に埋めるべき穴が見えるように進めます。現場で詰まらないために最低限必要な土台現場で止まる人と、短時間で状況を整理できる人の差は、知識量より順番です。サービスが動いているのか、どこ ...

【40代】SESで考えることをやめたエンジニアの実情 | PART-Ⅰ

知人のSEからヘルプ要請が入り、久しぶりに3層システムのリニューアル案件にSESとして参画してきました。メンバーの中心は30代から40代で、エンドユーザーは誰もが名前を知るプライム上場企業です。関係部署も多く、PMO、業務チーム、運用チーム、アプリ開発、システム基盤、AP基盤と、一見すると体制はかなり整っているように見えました。私がこうしたプロジェクトに最後に入ったのは、もう10年ほど前です。久しぶりの参画ということもあり、今の現場はどこまで役割分担が整理されているのか、その実態を見てみたい気持ちがあり ...

【Shell-Tips】シェル中断処理「Trap」を実装する。

システム運用中に「Ctrl+C」で処理を止めたり、予期せぬエラーでスクリプトが中断することは珍しくありません。こうした中断時に、ログ出力や後処理を安全に実行するために使われるのが「trap」コマンドです。trapを使えば、終了シグナルを検知して任意の処理を呼び出すことができ、ファイル削除やログ記録などを確実に行えます。本記事では、trapの基本構文と実践的な使い方を最短で理解できるように整理します。 Trapとは何かシェルスクリプトを動かしていると、途中で強制終了して「中途半端な状態」で止まることが ...

開発支援ツール集｜開発を支える環境と自動化の仕組みを整理する

開発の現場では、効率と安定性を両立させるために多様なツールが使われています。コードを書くことだけが「開発」ではなく、その前後にある環境構築・管理・自動化の仕組みまでを含めて設計できるかが、生産性を左右します。このカテゴリでは、エディタやリポジトリ管理、APIテスト、ワークフロー自動化など、日々の開発作業を支える実践的なツールを体系的に整理しています。単なる便利機能の紹介ではなく、現場で「なぜそのツールを選ぶのか」という判断基準を軸に、環境整備から自動化までの全体像を見渡せる構成としています。開発を ...

【システム設計・構成管理】システム開発を支える設計ドキュメント！

システム開発では、要件定義から運用設計までの各工程で「設計ドキュメント」が欠かせません。これらは単なる資料ではなく、チーム全体の共通認識を作り、品質と再現性を支える重要な基盤です。このカテゴリでは、上流工程から下流工程までの設計ドキュメントを体系的に整理し、実務に直結する理解を身につけられる構成としています。設計書を“書くため”ではなく、“活かすため”の視点で、現場で役立つ知識をまとめました。要件定義書の目的と最新の手法を学ぶ要件定義書は、システム開発における最上流工程であり、「何を実現するか」を明 ...

【Javaの基礎知識】文法から現場実装まで体系的に身につける

Javaは、最も安定した開発言語として長年にわたり多くのシステムで採用されています。このシリーズでは、学習の流れを「基礎編」と「実践編」に分け、初学者でも段階的にスキルを習得できる構成としています。基礎編では、文法・構文・条件分岐・例外処理・クラス設計など、あらゆるプログラムの土台を徹底的に解説。実践編では、ServletやJDBC、JavaFX、Spring Bootを活用し、Web・DB・GUI開発を通じて現場で使える実装力を養います。 Javaの思想を理解し、構築から運用まで一貫して使える確か ...

【Shellの基礎知識】構文理解から自動化までを一気に習得する完全ロードマップ

Shellスクリプトは、Linux環境における自動化の中核を担う存在です。単なるコマンドの羅列ではなく、システム全体を意図的に制御する「仕組み」を作り出すための言語でもあります。本ページでは、Shellの基礎構文から実務で通用する自動化スクリプトの設計までを体系的に整理しています。基礎編では、条件分岐・ループ・関数などを通じて“理解して使える”構文力を養い、実践編では、RHEL系Linuxを土台にサーバー構築や監視、障害通知といった現場業務を自動化するスクリプト設計を学びます。単なる作業効率化にと ...

【Shellの基礎知識】設計から運用まで自動化の仕組みを解説｜RHEL系Linux対応

実践編では、基礎構文の理解を前提に、実際の業務を効率化するシェルスクリプトをテーマ別に解説します。単なるコマンド習得ではなく、「どのような設計思想でスクリプトを組むか」「どこまで自動化できるか」に焦点を当てています。サーバー構築・運用・保守を通じて“生きたShell”の使い方を体得できます。基本共通｜スクリプト設計の基礎構造を固める実践的なシェルスクリプトを組むうえで鍵となるのは、「再利用性」と「保守性」を両立させる設計です。本セクションでは、ログ出力やテンプレート化、共通関数など、現場で活用さ ...

1 2 3 … 13 Next »