情報通信業（IT受託・SES・Web制作・SaaS） のペイン集約（note発信から）
最終更新: 2026-05-09 情報源: note.com の情報通信業関連記事 業界カテゴリ: G. 情報通信業（日本標準産業分類）
概要
- 集めた記事数: 約30件（WebSearchで30件以上の候補を発掘し、うち本文をWebFetchで取得・引用したのは28件）
- 主な発信者層:
- 受託開発／Web制作会社の経営者（社長・代表）
- SES企業の経営者・執行役員・営業責任者
- 現役エンジニア（PM／PL／SE／SRE／インフラ）
- SES現場で働く（または辞めた）エンジニア
- フリーランスエンジニア・Webデザイナー
- SaaSスタートアップ創業者・CEO
- 情シス・社内SE（顧客側）
- 採用コンサル・人材エージェント（IT特化）
- 記事の主な発信時期: 2020〜2026年（多重下請け／生成AIの影響／2026年下請法改正など、近年の論点を含む）
ペインカテゴリ1: 多重下請け構造・中抜き
Pain 1.1: 多重下請けでエンジニア手取りが半額以下に削られる
- 誰が困っているか: 末端のSESエンジニア（3次〜5次請け）、若手エンジニア
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「エンジニアに支払われるべき報酬が途中で削られ、適正な給与が届かない『中抜き』の構造」「『元請け → 一次請け → 二次請け → 三次請け…』といった多重下請け構造」で「本来の単価の半分以下しか届かない」
- 出典: 日本のIT業界はなぜ「中抜き地獄」なのか？——SESと多重下請け構造の真実 by GO KONISHI 小西剛
- 業界用語/文脈: 多重下請け＝発注元 → 元請け → 一次／二次／三次… と複数の中間業者を介す構造。「準委任契約」（業務委託の一種で、結果ではなく労務提供に責任を持つ契約）を取ることで労働者派遣法を回避できるため、SESで多重下請けが温床化している。
Pain 1.2: 1人月80万でも下請けに出す段階で20万円ピンハネ
- 誰が困っているか: 3次請け以下のSESエンジニア
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 「1人月100万円でエンジニアを貸し出してもその2次請けは1人月80万円で3次請けの企業から人を貸してもらい20万円中抜きします」「正社員として3次請け企業に雇われていながら実態は派遣です」
- 出典: IT業界の闇。多重下請け構造 by いとたい（IT業界9年経験のエンジニア・組込系）
- 業界用語/文脈: SES＝System Engineering Service。エンジニアを客先に常駐させて時間単位で作業を提供する契約形態。
Pain 1.3: 中抜き率は平均37.7%、エンジニア還元率はおよそ60%にとどまる
- 誰が困っているか: SES現場エンジニア
- 頻度: ★5
- 痛みの強度: ★4
- 引用: マージン率は「平均約37.7%で、エンジニアへの還元率は約60%程度」「4次請け～5次請けのような下層企業では、エンジニア1人月あたり50～70万円の単価が相場」
- 出典: SES業界の闇６つ by SES業界の闇ラジオ
- 業界用語/文脈: 「還元率」＝SES企業がクライアントから受け取る単価のうち、エンジニアの給与に回る割合。70%超を「高還元SES」、80%超は業界トップクラスと呼ばれる。
Pain 1.4: 多重下請けでは品質低下が起きやすく、現場のスキル不足者が紛れ込む
- 誰が困っているか: 元請けSIerのPM、大規模システムの発注元
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「プロジェクトメンバーの誰がどこの会社の人なのかパッと見ではよくわからない」「スキルや職業倫理が想定以上に低いメンバーが紛れ込みやすく、大規模システム開発の舵取りをいっそう難しく」する
- 出典: なぜSIerは下請会社から人をかき集めないとソフトウェア開発できないのか？ by gami（エンジニア、元富士通SE）
- 業界用語/文脈: SIer＝System Integrator。100人以上の大規模ウォーターフォール開発を完遂後解散する構造のため、自社採用ではまかなえず下請けで増減させる必然があるとされる。
Pain 1.5: 単価非開示が常態化、エンジニアは自分の値段を知らされない
- 誰が困っているか: SES現場エンジニア
- 頻度: ★4
- 痛みの強度: ★3
- 引用: 「SES契約は派遣社員とは異なり、企業には契約単価や還元率をエンジニアに開示する法的義務がありません」「自分の契約単価を知ったエンジニアから『もっと給料を上げてほしい』と交渉されるなど、企業側が給与交渉で不利になる事態も避けたい」
- 出典: SESの単価を教えてくれないのはなぜ？その理由と対処法を解説 by SES業界の闇ラジオ
- 業界用語/文脈: 派遣契約はマージン率の開示が労働者派遣法で義務付けられているが、準委任のSESには同様の規定がない。
Pain 1.6: 下請け根性に染まると判断停止、人生をギャンブル化させる
- 誰が困っているか: 中堅エンジニア・受託開発会社の社員
- 頻度: ★3
- 痛みの強度: ★4
- 引用: 「ＩＴ業界は多重下請け構造で成立している企業が多く、どこもかしこもプライム（ユーザーと直接契約すること）で仕事が取ってこれているわけではありません」／「『判断停止』『思考停止』によって、責任能力のない他人に人生を預けるギャンブル的な仕事方法が常態化」
- 出典: 下請け根性からの脱却 by Takashi Suda / かんた（IT業界50件以上の問題プロジェクト解決経験者）
- 業界用語/文脈: 「プライム」＝発注元と直接契約する元請けポジション。下請け側はプライムの指示で契約外作業を受けやすい。
ペインカテゴリ2: SES／客先常駐の働き方
Pain 2.1: 常駐ガチャ／嘘の経歴／コードを書かせてもらえない
- 誰が困っているか: 未経験〜微経験でSESに入ったエンジニア
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「営業が勝手に『ここね！』といってきて面談がはじまります」「全くやったことのない言語の案件に面談へ行ったり」「案件によってバラバラだったり、コードを書かせてもらえない」「『あれ、俺ってどこの会社の人間なんだっけ』となりえます」
- 出典: 【3ヶ月で退職】ヤバイ！SESの闇について暴露します！ by 南だいすけ（3ヶ月でSES退職）
- 業界用語/文脈: 「常駐ガチャ」＝配属先の良し悪しが運に左右される様。「経歴詐称」＝営業がスキルシート（職務経歴書）を盛って提出させる慣習。
Pain 2.2: 家電量販店派遣・経歴詐称の強要・ロースキル塩漬け
- 誰が困っているか: 未経験者を採用する側（SES経営）と、騙されて入社した未経験エンジニア
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「IT職」と謳いながら実態は接客販売、「多くが家電量販店や携帯ショップに立つ」状況／未経験者に「Java開発経験3年」などの虚偽職務経歴書を作成させる／テスターや運用監視のみで「3年、4年と続くと『開発できない人』と烙印」
- 出典: 現場から見て未経験SESの「闇」「やめとけ」は結構正しい by 中山健（セルバ／セルバコンサルティング代表）
- 業界用語/文脈: 「塩漬け」＝同じ単価・現場で長く据え置かれる状態。テスター／運用監視中心の現場にいると開発スキルが身につかない。
Pain 2.3: デスマーチ・破った参考書のコピーで研修・待機中の給与カット
- 誰が困っているか: SES現場エンジニア、新卒・若手
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「デスマーチ（過重残業）に巻き込まれるケースもあり、深夜残業や休日出勤が常態化」「未経験で入社した新人に月給15万円程度しか支払わない」「無料のプログラミング学習サイトをやらせるだけ」「破った参考書のコピーを渡すだけ」「待機を理由に給与を減額したり、極端な場合ゼロにする悪質なケース」
- 出典: SES業界の闇６つ by SES業界の闇ラジオ
- 業界用語/文脈: 「待機」＝次の案件が決まらない期間。基本給60%程度に減額、または「待機中ゼロ」の特約がある悪質ケースも。「デスマーチ」＝death march、無理な納期・要求で長時間労働が続く状態。
Pain 2.4: 5年いても昇給数千円、30代でも年収300万円台
- 誰が困っているか: SES在籍エンジニア
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「中間に入る企業ごとにマージン（手数料）が差し引かれるため、下位のSES企業に支払われる金額はエンドユーザーが支払う金額の一部に過ぎません」／「5年間で昇給は数千円程度だった」「このままだと30代でも年収300万円台では…」「待機中のエンジニアに基本給の60%程度しか支給しないケースが一般的」
- 出典: SES業界で「給料が上がらない」理由と仕組み、収入アップの方法 by SES業界の闇ラジオ
- 業界用語/文脈: SES企業の給与は契約単価×還元率で決まりやすく、案件単価の上限と中抜きが構造的天井になる。
Pain 2.5: 一人常駐の孤立感、3ヶ月〜1年ごとに人間関係リセット
- 誰が困っているか: SES現場エンジニア（特に1人で常駐する人）
- 頻度: ★5
- 痛みの強度: ★4
- 引用: SES／客先常駐の最も難しい点は「自分のキャリアをコントロールできない——次の配属がどこになるか分からない、学ぶ技術を選べない、3ヶ月〜1年で人間関係がリセットされる」こと／「BP（ビジネスパートナー）」扱いで「正社員より下に見られる」
- 出典: 新卒で客先常駐のエンジニアをしていた当時辛かったこと by うさまるまる（元客先常駐SE）
- 業界用語/文脈: 「BP」＝Business Partner、客先側から見た外部委託メンバーの呼称。プロパー社員（その会社の正社員）より一段下の扱いになることがある。
Pain 2.6: SESのハラスメント／契約上の問題／副業収入没収
- 誰が困っているか: SES現場エンジニア
- 頻度: ★3
- 痛みの強度: ★5
- 引用: 「客先の上司から毎日罵声を浴びせられ鬱になった」「派遣先社員から理不尽な雑用ばかり押し付けられた」「セクハラ被害を訴えた社員に対し『派遣命令を乱発し従わないと解雇を通告』」「副業で得た収入を会社に没収」「残業代未払いが慢性化して労基署から是正勧告を受けたSES企業」
- 出典: SES業界の闇６つ by SES業界の闇ラジオ
- 業界用語/文脈: 偽装請負＝形式は準委任・請負だが、実態は派遣として指揮命令を受けている状態。SES業界では構造的に発生しやすい。
ペインカテゴリ3: 受託開発会社の経営
Pain 3.1: 顧客ガチャ／無限修正ループ／集客難
- 誰が困っているか: 受託開発会社の経営者
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「受託開発と調べると、Googleのサジェストで『つらい』と出てきますよね」「結論から言うと、本当です」／要件への認識齟齬：「『最初に言っていたじゃないか』『○○みたいなアプリを作れって言ったよな？』」／集客「単純に難しい」、商談獲得単価「10万円程度になってしまいます」／「一定規模のサービスとなるとバグは数百個程度は出るのが常」「現場が疲弊するケースも多い」
- 出典: 受託開発はつらいって本当？開発会社の社長が解説してみた。 by 受託社長（現役受託会社経営者）
- 業界用語/文脈: 「顧客ガチャ」＝発注主の質に当たり外れがあること。受託は契約後の仕様変更を断りにくく、追加見積も通りにくい構造。
Pain 3.2: 不確実性の責任が個人に集中、月残業300時間
- 誰が困っているか: 受託開発のエンジニア／PM／経営者
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「月残業300時間という極端な働き方を経験したこともあります」「仕様変更による差し戻し、スケジュールと現場のギャップ、顧客からの無茶な要求」「不確実性に対する責任が、特定の個人に集中していたから」「不確実性の吸収係になることで疲弊していきます」「不確定な未来の責任を背負わされる職種になっていました」
- 出典: 受託開発はつらい? by Sasamori（セルプロモート株式会社 執行役員、エンジニア歴20年）
- 業界用語/文脈: 受託開発の請負契約は完成責任が受注側にあり、要件変更や見積誤りのリスクが現場のPM・エンジニアに集中する。
Pain 3.3: 営業リードタイムが長く、稼働率100%でないと売上が立たない
- 誰が困っているか: 受託開発会社の経営者・営業
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「初回提案からクロージングまで長いもので1年かかる案件もあります」「成長するには『人を増やす』しかありません。売上規模が『社員数』に強く依存」／「制作とか開発で『常に稼働率100％じゃないと目標売上に届かない』っていう状況が続くと、やっぱり精神的にしんどい」
- 出典: 受託開発から始めたスタートアップのリアル by 株式会社Digeon／みんな受託やめてプロダクト作ろうとするけど、ほぼ失敗する理由とその抜け道 by ninoya 古越（デジタルマーケティング会社経営12年）
- 業界用語/文脈: 労働集約型ビジネス＝売上が人月（マンマンス）に強く依存する構造。仕掛中案件が多いと採用→育成→アサインのサイクルが回りきらず、機会損失が常態化する。
Pain 3.4: 創業者の人脈に依存した営業、後継者になると案件が枯れる
- 誰が困っているか: 受託開発会社の二代目経営者・経営継承担当
- 頻度: ★3
- 痛みの強度: ★5
- 引用: 「それはHが築いてきた『交流関係』という見えない資産に支えられた再現性の低いものでした」「Hが抜けたことにより、Hの影響力が徐々に弱まっていき、案件不足が問題となるようなってきました」「このままいくとやばいなーという状況でした。それもあり社員の採用も1年以上ストップしていました」
- 出典: 割とヤバめな状況から受託開発会社を盛り返した話 | 効果的だった営業手法の紹介 by obata（株式会社mofmof経営者）
- 業界用語/文脈: 受託会社の多くは創業者や特定キーパーソンの人脈に営業が依存しており、属人化を解消する仕組みがないと事業継承で破綻しやすい。
Pain 3.5: SIer営業はコアコンピタンスがなく「何が売れるか分からない」
- 誰が困っているか: 受託SIer／開発会社の営業（含む兼業の元エンジニア）
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「強く売り込める商品であるコアコンピタンスがあるわけでもなく」「業界で有名な得意分野も無い」と「何が売れるのかが分かりません」／コンペで「盛り上がり、担当者OKが出たにも関わらず先方稟議などで最後に覆る」ときの衝撃は「失恋に等しい」もの
- 出典: 開発営業はツライよ、というお話 by 久松剛（エンジニアリングマネージメント社長）
- 業界用語/文脈: 受託SIerは差別化材料が薄く、価格と人月、過去実績で比較されやすい。失注時の心理的ダメージが大きい。
Pain 3.6: 開発が忙しいと営業フォローが後回し、対応速度も提案品質も担当者次第
- 誰が困っているか: 受託開発会社（営業とエンジニアを兼務）
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「紹介、人脈、担当者の記憶、Excel、個別メールに依存」「開発が忙しくなると、フォローメールは後回しになります。打ち合わせメモは個人の手元に残り、温度感や次回アクションが共有されません」「対応スピードも提案品質も担当者次第」
- 出典: 受託開発の営業が失敗する理由とは？エンジニア営業兼務から抜け出し、案件化を仕組み化する方法 by 株式会社HIKE
- 業界用語/文脈: 案件管理（リード→商談→受注）が個人のExcel／個別メールにとどまり、CRMとして仕組み化されていない受託会社が多い。
Pain 3.7: 「受託っぽい」＝意思決定の自由度がなく、思考停止のリスク
- 誰が困っているか: 受託会社所属のエンジニア（自社プロダクト志向）
- 頻度: ★3
- 痛みの強度: ★3
- 引用: 「自分の選択がしにくい。お客様の判断に依存する」／「言われたことだけをやる人になったらつまらない」／短期プロジェクト中心で「サービスの成長過程を見守る経験の喪失」
- 出典: 「受託っぽい」というネガティブワードをもう少し分解したい by えふしん（BASE技術マネジメント担当）
- 業界用語/文脈: 「受託っぽい」はエンジニア界隈で「指示通りに作るだけ」というネガティブなニュアンスを帯びがち。
Pain 3.8: ITベンダーの受託市場が生成AIで崩壊中、人月モデルの終焉
- 誰が困っているか: 受託開発会社の経営者・エンジニア
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「人月単価モデルは、生成AIの普及によって完全に過去のものになりつつある」「『AIで自社開発するから発注減らすよ』とクライアントが言うケースが増加」「1～2人のエンジニアで従来の10人規模のプロジェクトを完遂する事例が急増」「コードを書くだけのエンジニアの需要が80%減」
- 出典: ITベンダー受託開発市場が生成AIにより絶賛崩壊中 by 風鳥冴達
- 業界用語/文脈: 「人月単価」＝1人のエンジニアが1ヶ月作業する単位（〜80万円程度）。AIによる生産性向上で、従来のエンジニア人月をベースにした見積モデルが揺らいでいる。
Pain 3.9: 受託をやめてプロダクトを作ろうとして99%が失敗する
- 誰が困っているか: 受託からプロダクト企業への転換を試みる経営者
- 頻度: ★3
- 痛みの強度: ★5
- 引用: 「脱受託＝プロダクト開発と思ってると、99％失敗します」（受託ビジネスに存在する「構造的な2つの弱点」への無理解が原因）／「受託が忙しくて結局そっちが優先される」「『作りたいんだよね〜』くらいで『具体的な目的がない』」「あったらいいな〜レベルの機能では、人は動きません」
- 出典: みんな受託やめてプロダクト作ろうとするけど、ほぼ失敗する理由とその抜け道 by ninoya 古越／なぜ受託会社(またはフリーランス)は自社開発を継続できないのか by kuniaki suzuki（Coderless株式会社）
- 業界用語/文脈: 受託で稼ぐ仕組みとプロダクトで稼ぐ仕組みは別物（営業手法・キャッシュサイクル・PMF獲得期間）。受託の余剰時間でプロダクトを作るアプローチは大半が頓挫する。
ペインカテゴリ4: Web制作会社の経営
Pain 4.1: デザイナーの求人倍率10.4倍、採用・育成・離職コスト全部高い
- 誰が困っているか: Web制作会社の経営者
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「Webデザイナーの求人倍率は10.4倍」「採用コスト高い。育成コスト高い。離職リスク高い。」「新規の取り引きには、ほぼコンペになります」「企業のビジネス課題解決に長けた競合の参入」（マーケティング企業やSaaSベンチャーの異業種参入）／「NoCodeはプロが正しく取り入れることで生産性を何倍にも高める」
- 出典: 「Web制作会社がなくなるってホント？」Web制作会社を14年間経営した筆者が現状と未来を検証してみた。 by 和田へい（株式会社GoodBe代表、14年間Web制作会社経営）
- 業界用語/文脈: Web制作業界は中級以上の人材が極端に不足。新規取引はコンペが基本、価格圧力が強い買い手市場。
Pain 4.2: 生産性が低く2徹3徹が前提、長時間労働が構造化
- 誰が困っているか: Web制作会社の経営者・現場社員
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「ウェブ制作業は情報サービス産業でも生産性が低く、製造業と違ってオートクチュール制作も多く、オートメーション化できる範囲も狭い」「2徹3徹が当たり前の過去の営業利益を超える事は至難の業」「長期労働が構造的に必然化している業務」「専門職が満たされない環境では現場の維持ができない。＝離職＝組織スペックの低下」
- 出典: Web制作会社における生産性を考える by らぼ（数百人規模Web制作会社所属、広告代理店系グループ子会社のウェブエンジニア）
- 業界用語/文脈: 「2徹3徹」＝2日〜3日連続の徹夜。受託オートクチュール（一品もの）が中心のため、テンプレ化やSaaS化で生産性を上げにくい。
Pain 4.3: 「ノーコードで安く」「ホームページなんて5万円」で値下げ圧力
- 誰が困っているか: Web制作会社・フリーランスデザイナー
- 頻度: ★5
- 痛みの強度: ★4
- 引用: クライアントのリテラシー強化で単価が下がる傾向、「最近はノーコードでぱっと作れるんでしょ？予算無いからノーコードでお願い」／「『5万円で作れるもの』と『50万円～200万円かけるもの』の違いが曖昧」「同業者による安売り」「やっている中身」「関わる人数」「背負う責任の範囲」がまったく異なるのに、同じ「ホームページ制作」という言葉で括られている／「表面の見栄えを整えるだけ」のレベルの仕事は、AI活用により自動化される危険性が高い
- 出典: Web制作 単価が下がる関連記事まとめ など複数／「ホームページなんて5万円で作れますよ」は本当にお得なのか by 米本デザイン
- 業界用語/文脈: 「ノーコード」＝STUDIO、Wix、Webflowなどコードを書かずにサイト構築できるツール。月額590円〜の独自ドメイン公開も可能で、Web制作の最低価格帯を下げている。
Pain 4.4: 「作って終わり問題」――サイトは綺麗だが予約が増えない
- 誰が困っているか: Web制作会社の経営者、納品されたクライアント
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 「技術的には対応できるようになったけど、クライアントの本当の課題解決にはなっていないのかもしれません」（フラッシュコネクト代表 佐藤）／「昨年リニューアルしていただいたサイトはとても素敵なんですが、予約が思うように増えないんです」（旅館の女将）／「『作って終わり問題』——これが多くの制作会社の経営者が異口同音に話す、業界の"リアルな悩み"です」
- 出典: 「作って終わり問題」は卒業できる～地方の小さなWeb制作会社の「技術力」を価値に変える方法～ by ふくマッチ／福島民報社
- 業界用語/文脈: 制作後のSEO・運用・マーケに関与せず納品で終わる慣習が、クライアントのROI低下と制作会社のリテンション低下を同時に招いている。
Pain 4.5: クライアント側の負担が大きい／分業による「営業→デザイナー→エンジニア」たらい回し
- 誰が困っているか: Web制作の発注側企業（クライアント）
- 頻度: ★4
- 痛みの強度: ★3
- 引用: 「『文章や写真はそちらでご用意ください』というスタンスの制作会社が多い」「担当者が細分化されていると…営業に聞いてくれ、デザイナーに直接相談してください」「『手離れをよくしたい』『納品後の保守はなるべく引き受けたくない』という会社が多い」
- 出典: 私が思う、優れたWeb制作会社の5つの共通点 by 佐野彰彦（2社経営するデザイナー）
- 業界用語/文脈: コンテンツ準備（テキスト・写真）が発注側丸投げの構造。修正対応が部門間でたらい回しになる構造。
Pain 4.6: 見積取得まで1週間、予算外なら別社探しでまた1週間
- 誰が困っているか: Web制作の発注側経営者
- 頻度: ★4
- 痛みの強度: ★3
- 引用: 「問い合わせを送る→返信待ち→ヒアリング→打ち合わせ→見積書回答で優に1週間が経過」「出てきた見積金額が予算と合わなければ、また別の会社を探して同じ工程を繰り返さなければならない」「結果として経営者や担当者の貴重な時間が何十時間も奪われていく。これは明らかな『機会損失』」
- 出典: Web制作の待ち時間をゼロに。オンライン完結で見積もりが可能なメリット by ヒロ@広告代理店 / CEO
- 業界用語/文脈: Web制作見積はカスタム見積が主流で、要件ヒアリング→見積→承認のリードタイムが長い。
Pain 4.7: フリーランスが未払いに遭遇、契約書も実質意味がない
- 誰が困っているか: フリーランスデザイナー・Web制作のフリーランス
- 頻度: ★3
- 痛みの強度: ★4
- 引用: 「お支払いが2ヶ月以上経っても無い事はざらにあり」「催促する事で遅れてお支払い頂く事も多いです」「未払いになる相手にはそれも無意味なのではと今回の経験で感じました」
- 出典: 未払いに対応する方法を実体験から考える by カズシフジイ（フリーランスデザイナー、10年以上の活動経験）
- 業界用語/文脈: 中小クライアントとの取引では入金遅延が日常化しやすい。下請法（2026年1月1日に「中小受託取引適正化法（取適法）」へ改称）が改正されたが、零細制作会社・フリーランスへの実効力は限定的との指摘。
ペインカテゴリ5: SaaS事業者の経営
Pain 5.1: SaaSは「成功は再現性低い・失敗は再現性高い」
- 誰が困っているか: SaaSスタートアップ創業者・経営者
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 「失敗の数がかなり多くありました」「成功に再現性はあまりないけれど、失敗はものすごく再現性が高い」／顧客課題の解像度不足、プロダクト完成前の検証欠如、MVP/MSP概念の誤解
- 出典: SaaSスタートアップ企業を経営をしていて大失敗した10のことを振り返ってみる by Shin（SmartMeeting前代表、現在はフリーランスでSaaS立ち上げ支援）
- 業界用語/文脈: 「MVP」＝Minimum Viable Product、最小限の機能で市場検証するためのプロダクト。「PMF」＝Product Market Fit、市場に受け入れられた状態。
Pain 5.2: 「売ってはいけない顧客」が利益を削る、固定費は重く積み上がる
- 誰が困っているか: SaaS企業の経営者・CFO
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「売上は伸びている。でも、利益が思ったより残らない」「売ってはいけない顧客に売ってしまっていることが利益圧迫の主因」／手間がかかる顧客は「プロダクト理解が浅く」「問い合わせ頻度が高く」、カスタマイズを要求される／SaaSは「人件費・サポート・インフラ等が固定費化しやすい」
- 出典: 「売ってはいけない顧客」が利益を削る──SaaS企業の原価率と販管費率を改善する3つの視点 by xxx（SaaS経営戦略アドバイザー）
- 業界用語/文脈: SaaSは「ARR（年間経常収益）」を伸ばす一方、CS（カスタマーサクセス）コストが固定費化しやすく、低単価×高サポート顧客が利益を削る構造。
Pain 5.3: SaaSの解約率（チャーン）は成長の天井を決める、平均22%は危機水準
- 誰が困っているか: SaaS事業者・PdM・CS担当
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「PMF達成は解約率10%以下が目安、PMF未達セグメントは20%チャーンまで許容」「Zuora調査ではSaaS平均チャーン率は22%」「成長は解約率10%以下でしか持続不可能」
- 出典: ami.SaaS：解約率は成長の上限を決める by tr.sakuma など複数記事の総合
- 業界用語/文脈: 「チャーンレート」＝解約率。月次5%は年率約46%相当。新規獲得を続けても解約が多ければ純増しない。
Pain 5.4: エンタープライズMVPが「最小公倍数」or「最大公約数」で誰のためでもなくなる
- 誰が困っているか: エンタープライズ向けSaaSの起業家・PdM
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「『この機能は、○○さんには必要ない』というのをそぎ落とした結果、誰のMVPでもなくなる」「『この機能は、○○さんには必要』というのを入れ込んだ結果、誰のMVPでもなくなる」（営業vs開発の対立、SIer出身チームほど機能過多に陥りがち）
- 出典: エンタープライズ向けサービスのMVPはこうして失敗する。 by 大平裕介（Leaner CEO）
- 業界用語/文脈: エンタープライズ向けSaaSは大口顧客の個別要求に応じてカスタマイズ要望が来やすく、MVPの定義が崩れやすい。
Pain 5.5: 顧客個別カスタマイズ＝意図的に技術的負債を背負わされる
- 誰が困っているか: SaaS事業のエンジニア／CTO／PdM
- 頻度: ★4
- 痛みの強度: ★5
- 引用: 特定顧客向けの機能をプロダクトに追加することは、「意図的に大きな技術的負債を抱えること」を意味し、非エンジニアが想像する以上の負荷をもたらす／「技術的負債は、現実の借金と同じく元本があり、利息が積み上がり、指数関数的に増える」
- 出典: #199 受託開発からプロダクト開発への移行 ～技術的負債との向き合い方～ by こへい（上場企業EM）
- 業界用語/文脈: 「技術的負債」＝後から修正・改善が必要となる短期的な実装の積み上げ。SaaSではマルチテナント設計を維持できなくなる。
ペインカテゴリ6: 要件定義／プロジェクトマネジメント
Pain 6.1: 要件定義しんどい、ふわっとした要望で1日エクセルお絵描き
- 誰が困っているか: 受託エンジニア・PM
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 「要求元が作る資料がかなりふわっとしていて何を作ってほしいのかわからない」「要求元自身も実際に何がほしいか明確でないことがあります」「要件定義がたいして進まず1日が終わった日なんかには、実質の成果はエクセルでちょっとお絵描きしたくらい」「日々葛藤と自己嫌悪が止まないのが要件定義フェーズです」「正直エンジニアなんだから開発だけさせてくれよ」
- 出典: 要件定義しんどいし、正直な気持ちを書く by ponzu（フリーランスエンジニア）
- 業界用語/文脈: 「要件定義」＝何を作るか合意するフェーズ。受託の最大の難関で、ここで認識齟齬を残すと開発フェーズで全部跳ね返ってくる。
Pain 6.2: 要件定義は「誰も出来ない」が真実、ユーザー自身が何を欲しいか言えない
- 誰が困っているか: 受託SIer／システムコンサル
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「ユーザーであっても実装したい要件を明確に語れないこと」（発生確率5%程度のエッジケース対応が組織内で身体知化しており、ルール化・言語化されていない）／「詳細設計フェーズで現状調査に時間を取られ、スケジュールは崩壊」
- 出典: 要件定義を誰も出来ないという不都合な真実 by goza（独立系システムコンサル、元SIer）
- 業界用語/文脈: 「エッジケース」＝めったに発生しないが対応必須の業務パターン。日本企業は属人化した暗黙知が多く、要件として表に出ない。
Pain 6.3: 情シス目線でも要件定義は不可能、システム刷新は7〜14年に1回で経験ゼロリセット
- 誰が困っているか: 情シス／社内SE／受託SIer
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「システム刷新のタイミングはだいたい７年から１４年くらい」であり、実担当者にとって一生に１～２回の経験／「部外者は、基本的に部外者でしかありません」「うわべだけの現状把握」／「完璧な要件定義など諦めて、むしろ漏れや変更に覚悟を決めて備えたほうが良い」
- 出典: なぜ要件定義はろくな事にならないのか？〜情シス目線のプロジェクトマネージメントTips#08 by keita（情シスのおっさん）
- 業界用語/文脈: 「情シス」＝情報システム部門。基幹系刷新は7〜14年に1回程度のため、社内に経験者がほぼいない状態でPJを始めることが多い。
Pain 6.4: PMが炎上対応で寝落ち、報告中に倒れる
- 誰が困っているか: 受託SIerのPM／PMO
- 頻度: ★3
- 痛みの強度: ★5
- 引用: 「クライアントへ報告しながら寝落ちしてしまった」ほどの寝不足／「クライアントとマネジメントからの矢のように鋭い『どうするのか？』の問いの連続」で常時対応を考えている状態
- 出典: 地獄の炎上プロジェクトでPMはどう振舞うべきか？ by 柴田秀夫（株式会社ARAKADO代表、PMP®）
- 業界用語/文脈: 「炎上」＝プロジェクトが大幅遅延・コスト超過・品質崩壊などの危機的状態に陥ること。
Pain 6.5: 上流の見積甘さが時間差で炎上に繋がる、現場の違和感が報告されない
- 誰が困っているか: 元請けSIerのPM・アーキテクト
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「競争力のある価格が提示された」「営業的にこれ以上の見積もりは通らない」（無理な工数）／「詳細は後で詰めればよい」「この要件で本当に良かったんだっけ？」（要件合意欠如）／「問題を問題として認識する力が弱く、対応が後手に回る」（マネジメント不備）／「最終的にはなんとかなるだろう」「正常化バイアス」（リスク認識甘さ）
- 出典: なぜ僕たちのプロジェクトは炎上するのか？ by ヤマダ（元請SIerのPM・アーキテクト、業界歴25年）
- 業界用語/文脈: 「正常化バイアス」＝危険信号を「いつものこと」として軽視する心理。受託では上流の判断ミスが下流で時間差で表出する。
Pain 6.6: 営業（売上）vs 開発（資産）の対立、機能要望リストを見るのが怖い
- 誰が困っているか: PM／PdM、開発組織
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 営業時代「なんでこれまで慣れてきた画面を変えるんだ」「開発部隊は要望に沿った開発をしてくれない」／開発時代「営業部隊の要望に沿った開発ばかりで必要な負債解消もできない」（機能要望リストを見るのが怖くなる心理）／対立の本質は「それぞれが重視するものが『PL（売上/利益）』と『BS（資産）』で違う」
- 出典: なぜ営業組織と開発組織の仲は悪くなるのか？を考えて体制構築したらBizDevの重要さがわかった話 by 井原真吾（リクルート→Graffer経営者）
- 業界用語/文脈: 営業はPL（売上）、開発はBS（プロダクト資産）を見ているため、機能要求と技術的負債の優先度で衝突しやすい。
ペインカテゴリ7: フリーランスエンジニア／フリーランス独立
Pain 7.1: フリーランスは経験を切り売りするだけで成長機会が消える
- 誰が困っているか: フリーランスエンジニア（特に若手）
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 「あの期間は『経験を切り売りしていた』という感覚が強い」「業務委託として開発」と書いても「何をどこまで任されていたのかが見えません」「外部の人間に組織のコア部分を任せることはほとんどない」「気づいたら5年前のスキルセットのまま停滞」
- 出典: 僕がフリーランスを続けなかった構造的な理由 by すてぃお（株式会社adding代表取締役、元スタートアップCTO）
- 業界用語/文脈: フリーランスは失敗リスクある仕事が振られにくく、マネジメント経験が積めない。社会資本（評判・実績）も蓄積されにくい。
Pain 7.2: 自走できない未経験フリーランスが急増、1〜3ヶ月で案件終了
- 誰が困っているか: 採用側企業、エージェント
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「自分一人ではプログラミング上の問題解決をできない（自走できない）フリーランスエンジニアが多数見受けられます」（実装で詰まると「MENTAを利用」して外部支援を求め、1～3ヶ月で案件終了）／「週3日などの稼働」で「フルリモート必須」「MTG以外はフレックス」と設定されるが、実際のアウトプットが合意内容に達しない事例が頻発
- 出典: 駆け出しエンジニアブーム時の未経験・微経験フリーランスのその後と、エージェントの異変 by 久松剛
- 業界用語/文脈: 「駆け出しエンジニア」＝未経験〜経験半年程度のエンジニア。SNSで「フリーランスで月収50万」を喧伝するインフルエンサーが多く、実態とのギャップが拡大している。
Pain 7.3: 営業力ゼロで案件が取れない、紹介・人脈・エージェント頼み
- 誰が困っているか: フリーランスエンジニア
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 多くのエンジニアは営業経験がないため、案件獲得に苦労する。営業の王道は紹介で、良い働きをしていれば知り合いから仕事の紹介が来るはずで、来ない場合は活躍が足りないか人脈が足りていない／病気・案件ギャップで収入ゼロになるリスク
- 出典: フリーランスエンジニアの案件獲得：営業で成功するための戦略と実践ガイド など複数の総合
- 業界用語/文脈: フリーランスITエージェント（レバテックフリーランス、ITプロパートナーズ等）が案件供給の中心。エージェント経由は手数料10〜25%相当が引かれる。
ペインカテゴリ8: IT人材採用・組織
Pain 8.1: ITエンジニア採用は無理ゲー化、トヨタやホンダまで参入してきた
- 誰が困っているか: 受託・SES・自社開発の経営者・採用担当
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「プレイヤーの増加を意味しており、それにより、採用競争が激化しています」（かつてIT企業やスタートアップに限定されていたエンジニア採用が、トヨタやホンダなどの大手企業に拡大）「デジタル人材は1日20件以上をスカウトを受信しており、必然的に転職候補者・求職者の選択肢が増えてきている」「採用手法の多様化に伴い、新手法の導入が増えている」
- 出典: エンジニア採用が無理ゲー化している件 ～エンジニア採用が難しい3つの理由～ by 田中ひさし（株式会社トラックレコード、HR業界15年）
- 業界用語/文脈: 「ダイレクトリクルーティング」＝エージェントを介さず候補者へ直接スカウトする採用手法。媒体が複数化し、運用コストが増大。
Pain 8.2: 中堅エンジニアが市場から消滅、外資コンサルとフリーランスに流出
- 誰が困っているか: 中小〜中堅のIT企業の採用担当・経営者
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「2019年までは中堅エンジニア採用については、その採用手法が明暗を分けていた…2021年については中小企業シャッター街商店街をどう盛り上げるかみたいな話になっている」（流出先は外資系コンサル、GAFA、Seed期スタートアップ、フリーランス、起業）
- 出典: 採用市場に中堅エンジニアがほぼ居ない／どこに行ったのか目撃情報を集めてみた by 久松剛
- 業界用語/文脈: 「シャッター商店街」＝シャッターが閉まった寂れた商店街の比喩。中堅エンジニア採用市場で母集団そのものが枯渇している。
Pain 8.3: 2030年に45万人不足、優秀な人ほど他社にも10倍声がかかる
- 誰が困っているか: IT企業全般の採用責任者
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「2018年時点で22万人が不足し、2030年には約45万人に不足が拡大する」「一流のプログラマーは普通のプログラマーと比べて10倍の生産性をもつ」「面白い仕事ができる環境が提供できなければ、採用に至らないケースが往々にしてある」
- 出典: なぜ現代のITエンジニア採用は難しいのか？ by gami（PLAID所属エンジニア）
- 業界用語/文脈: 経産省委託調査による不足予測。生産性10倍格差は「The Mythical Man-Month」以来の経験則。単なる高給与では決め手にならない。
ペインカテゴリ9: システム保守・運用・SRE
Pain 9.1: PHP5など10年前のEOL環境を保守、新技術に触れず塩漬け
- 誰が困っているか: 運用保守担当エンジニア
- 頻度: ★5
- 痛みの強度: ★4
- 引用: 「PHP7系の公式なセキュリティサポートは2022年に切れている」状況でも、PHP5など「メジャーバージョンが10年近く前に切れている」システムの保守を担当／「日々降ってくる業務に押されるがままに、時間が取れなかった」「品質やセキュリティに若干の懸念を感じたとしても、組織の中での優先順位が低い場合改善にリソースは当てられにくい」「新しい技術概念を導入することはない」「経験がその会社独自になりやすく」
- 出典: エンジニアにとって運用保守が辛い理由 by rio_dev（SWE/Webプログラマー）
- 業界用語/文脈: 「EOL」＝End of Life。サポート終了したフレームワーク／言語を使い続けるとセキュリティリスクが上昇するが、改修予算がつきにくい。
Pain 9.2: 24時間アラートで深夜起き、定型業務に追われ改善できない
- 誰が困っているか: 運用保守担当エンジニア・SRE
- 頻度: ★5
- 痛みの強度: ★5
- 引用: 「深夜の障害アラートで飛び起き、原因究明に何時間も費やしている」「深夜だろうが休日だろうが、アラートが鳴れば即対応」「ログを何十GBも読み解き、ネットワーク図とにらめっこし」「定型的な運用業務に追われ、本来やりたい改善活動に手が回らない」「特定のベテランに障害対応が集中している」
- 出典: 【現役SEが語る】AIが運用保守を変える！残業地獄からの脱却術 by 業務効率化サポータ@SE
- 業界用語/文脈: 「SRE」＝Site Reliability Engineer。サービスの信頼性確保が役割。24時間365日のオンコール（電話当番）が必要な現場が多い。
Pain 9.3: 社内SEの保守運用は評価されない、報告するのは障害だけ
- 誰が困っているか: 社内SE／情シス
- 頻度: ★4
- 痛みの強度: ★4
- 引用: 「開発業務は新しいシステムを作ることでどこかキラキラした感じがあります。対して保守・運用は現行のシステムを見るので泥臭い感じ」「周囲の人からするとよくわからない業務内容ですが、保守運用業務をこなしている人間からするとかなり大変な仕事です」「人を減らしても回るかもしれませんが、リスクは莫大なものになることを知りません」「保守運用業務で報告しないといけないことと言えばただ一つ。障害報告です」
- 出典: 社内SEの保守・運用業務の立場は特に弱いと感じる話 by ウィッチゃん（事務職→社内SE→エンジニア）
- 業界用語/文脈: 「動いて当たり前、止まれば責任」と言われる保守運用は、コスト削減対象になりやすく、評価指標も「障害ゼロ」のマイナス採点になりがち。
Pain 9.4: 月400時間、9時出社→翌日9時→さらに18時までコード
- 誰が困っているか: 受託・SES現場のエンジニア（過去〜現在）
- 頻度: ★3
- 痛みの強度: ★5
- 引用: 「9時に出社して翌日の9時まで寝ないでプログラミングして、さらに寝ないで18時までコードを書く」（月労働時間400時間超）／「社員がそこらじゅうに転がっている」状態での24時間シフト勤務、ビジネスホテルを借りてシャワーを共有／「天国ではなく地獄」
- 出典: 地獄のプログラマー(IT業界の黒歴史を語ろうと思う) by George@ITエンジニア（業界26年）
- 業界用語/文脈: 2010年代以前のデスマーチの記憶。労基規制と働き方改革で改善傾向だが、納期直前の長時間労働は依然として残っている。
抽出ペイン総括
カテゴリ別ペイン分布
| カテゴリ | ペイン数 | 強度の高いペイン |
|---|---|---|
| 1. 多重下請け構造・中抜き | 6 | 中抜きで手取り半額、中堅が単価非開示 |
| 2. SES／客先常駐の働き方 | 6 | 常駐ガチャ、塩漬け、年収300万円台、孤立 |
| 3. 受託開発会社の経営 | 9 | 顧客ガチャ、稼働率100%プレッシャー、生成AI崩壊 |
| 4. Web制作会社の経営 | 7 | 求人倍率10.4倍、ノーコード値下げ、作って終わり |
| 5. SaaS事業者の経営 | 5 | チャーン、売ってはいけない顧客、技術的負債 |
| 6. 要件定義／PM | 6 | 要件定義しんどい、炎上、寝落ち |
| 7. フリーランス | 3 | 経験切り売り、案件取れない |
| 8. IT人材採用・組織 | 3 | 採用無理ゲー、中堅消滅、2030年45万人不足 |
| 9. システム保守・運用 | 4 | EOL塩漬け、深夜オンコール、評価されない |
特に頻出するキーワード
- 「中抜き」「多重下請け」「常駐ガチャ」：SES業界の構造的ペインの定番
- 「単価」「還元率」「マージン」：給与・報酬関連の不透明性
- 「炎上」「デスマーチ」「稼働率100%」：受託の労働強度
- 「顧客ガチャ」「ふわっとした要望」「仕様変更」：要件定義の困難さ
- 「ノーコード」「生成AI」「コモディティ化」：技術代替による単価圧力（特にWeb制作）
- 「採用無理ゲー」「求人倍率10.4倍」「中堅エンジニアがいない」：人材市場の枯渇
- 「作って終わり」「離脱」「成果」：Web制作・SaaS共通のリテンション課題
- 「チャーン」「PMF」「売ってはいけない顧客」：SaaS固有
SES／受託開発／Web制作／SaaSのペインの違い
| 業態 | 痛みの中心 | 経営者の主訴 | 現場の主訴 |
|---|---|---|---|
| SES | 構造的搾取（中抜き）、配属先の運頼み | 中堅エンジニアが採用できず流出、案件回せない | 単価非開示、塩漬け、孤立、年収頭打ち |
| 受託開発 | 不確実性の責任が現場に集中、稼働率100%前提 | 営業属人化、生成AIで人月単価モデル崩壊、プロダクト転換は99%失敗 | 顧客ガチャ、無限修正、要件定義しんどい、炎上 |
| Web制作 | 価格コモディティ化、AI／ノーコードに侵食 | 求人倍率10.4倍、生産性低、コンペで値下げ、作って終わりでクライアント離脱 | 2徹3徹、見積→修正→請求の手間、未払い対応 |
| SaaS | チャーン管理、顧客選別、プロダクト品質 | 売上は伸びるが利益残らず、平均22%チャーン、PMFが見つからない | 個社カスタマイズで技術的負債、CSが固定費化 |
業界横断で共通するペインと、IT業界に固有のペイン
業界横断的ペイン:
- 採用難（特に中堅以上）／離職リスク
- 営業の属人化／案件パイプラインの可視化不足
- 顧客との認識齟齬・修正対応・未払い
- 経営者と現場の感情・優先度のズレ
IT業界に固有のペイン:
- 多重下請け構造（〜5次請け）と中抜き慣行：他業界より段数が多い
- 準委任契約（SES）の偽装請負リスク：IT特有の契約形態問題
- 客先常駐＋常駐ガチャ：人月販売モデル特有の働き方
- 要件定義の本質的な困難さ：他業界の業務知識を理解しないとシステム化できない
- 技術的負債（テックデット）：ソフトウェア固有の概念、放置で指数関数的に悪化
- チャーン経営（SaaS）：サブスクモデル特有のKPI管理
- 生成AIによる人月モデル破壊：2024〜2026年の最新かつ最大級の構造変化
- ノーコード／ローコードによるWeb制作の価格崩壊
元記事リスト（参照URL）
SES／多重下請け／中抜き関連
- 日本のIT業界はなぜ「中抜き地獄」なのか？——SESと多重下請け構造の真実 - GO KONISHI 小西剛
- IT業界の闇。多重下請け構造 - いとたい
- SES業界の闇６つ - SES業界の闇ラジオ
- SESはやめとけと言われる業界の問題点 - SES業界の闇ラジオ
- SES業界で「給料が上がらない」理由と仕組み、収入アップの方法 - SES業界の闇ラジオ
- SESの単価を教えてくれないのはなぜ？その理由と対処法を解説 - SES業界の闇ラジオ
- 現場から見て未経験SESの「闇」「やめとけ」は結構正しい - 中山健（セルバ／セルバコンサルティング代表）
- 【3ヶ月で退職】ヤバイ！SESの闇について暴露します！ - 南だいすけ
- 新卒で客先常駐のエンジニアをしていた当時辛かったこと - うさまるまる
- なぜSIerは下請会社から人をかき集めないとソフトウェア開発できないのか？ - gami（元富士通SE）
- 下請け根性からの脱却 - Takashi Suda / かんた
受託開発／PM／要件定義
- 受託開発はつらいって本当？開発会社の社長が解説してみた。 - 受託社長
- 受託開発はつらい? - Sasamori（セルプロモート 執行役員）
- 受託開発から始めたスタートアップのリアル - 株式会社Digeon
- 割とヤバめな状況から受託開発会社を盛り返した話 - obata（株式会社mofmof）
- 開発営業はツライよ、というお話 - 久松剛
- 受託開発の営業が失敗する理由とは？ - 株式会社HIKE
- 「受託っぽい」というネガティブワードをもう少し分解したい - えふしん（BASE）
- ITベンダー受託開発市場が生成AIにより絶賛崩壊中 - 風鳥冴達
- みんな受託やめてプロダクト作ろうとするけど、ほぼ失敗する理由とその抜け道 - ninoya 古越
- なぜ受託会社(またはフリーランス)は自社開発を継続できないのか - kuniaki suzuki（Coderless）
- 要件定義しんどいし、正直な気持ちを書く - ponzu
- 要件定義を誰も出来ないという不都合な真実 - goza
- なぜ要件定義はろくな事にならないのか？ - keita（情シスのおっさん）
- 地獄の炎上プロジェクトでPMはどう振舞うべきか？ - 柴田秀夫（ARAKADO代表、PMP®）
- なぜ僕たちのプロジェクトは炎上するのか？ - ヤマダ（元請SIer）
- なぜ営業組織と開発組織の仲は悪くなるのか？を考えて体制構築したらBizDevの重要さがわかった話 - 井原真吾（Graffer経営者）
Web制作会社・フリーランスデザイナー
- 「Web制作会社がなくなるってホント？」 - 和田へい（GoodBe代表、14年経営）
- Web制作会社における生産性を考える - らぼ
- 私が思う、優れたWeb制作会社の5つの共通点 - 佐野彰彦
- 「作って終わり問題」は卒業できる - ふくマッチ／福島民報社
- Web制作の待ち時間をゼロに - ヒロ@広告代理店 / CEO
- 「ホームページなんて5万円で作れますよ」は本当にお得なのか - 米本デザイン
- デザインの制作単価が上がった10のきっかけ - 川端康介
- 未払いに対応する方法を実体験から考える - カズシフジイ
SaaS経営
- SaaSスタートアップ企業を経営をしていて大失敗した10のことを振り返ってみる - Shin（SmartMeeting前代表）
- 「売ってはいけない顧客」が利益を削る──SaaS企業の原価率と販管費率を改善する3つの視点 - xxx
- エンタープライズ向けサービスのMVPはこうして失敗する。 - 大平裕介（Leaner CEO）
- ami.SaaS：解約率は成長の上限を決める - tr.sakuma
- #199 受託開発からプロダクト開発への移行 ～技術的負債との向き合い方～ - こへい（上場企業EM）
フリーランス・採用・運用保守
- 僕がフリーランスを続けなかった構造的な理由 - すてぃお（adding代表、元CTO）
- 駆け出しエンジニアブーム時の未経験・微経験フリーランスのその後と、エージェントの異変 - 久松剛
- フリーランスエンジニアの案件獲得：営業で成功するための戦略と実践ガイド - SES業界向けサービス Project Hub
- エンジニア採用が無理ゲー化している件 - 田中ひさし（トラックレコード）
- 採用市場に中堅エンジニアがほぼ居ない／どこに行ったのか目撃情報を集めてみた - 久松剛
- なぜ現代のITエンジニア採用は難しいのか？ - gami
- エンジニアにとって運用保守が辛い理由 - rio_dev
- 【現役SEが語る】AIが運用保守を変える！残業地獄からの脱却術 - 業務効率化サポータ@SE
- 社内SEの保守・運用業務の立場は特に弱いと感じる話 - ウィッチゃん
- 地獄のプログラマー(IT業界の黒歴史を語ろうと思う) - George@ITエンジニア（業界26年）