悩む人

悩む人

文系出身でエンジニアになっても出世できるの？

本記事では、こんな悩みを解決します。

ぐり主任

僕は大手IT企業にSEとして勤務していますが、今回は文系出身の方がエンジニアになることができるのか？

というテーマで話したいと思います。

まず最初に結論を言ってしまうと、文系出身でもSEになることができます！

実際に私の職場にも文系出身のエンジニアが多数いますし、プログラミングがバリバリできる文系出身のスーパー上司も実在します。

そうは言っても、文系でプログラミングの経験がないと、本当にエンジニアになれるのか？と不安になると思います。

そこで、本記事では私の経験内容も踏まえて、文系出身の方がエンジニアになる上で何が大変なのか、逆に何が強みとなりえるのかについて解説します。

文系出身でもエンジニアになれるのか？【音声】

文系出身でもエンジニアになれるのか？というテーマでラジオ配信した音声が以下となります。

文章を見るのが面倒、という方はこちらの音声をお聞きください。

エンジニアの出身学歴の割合

まず、実際に文系出身のシステムエンジニアがどのくらいの割合で実在しているのかを確認してみましょう。

下の表はIPAが2017年に、IT技術者の最終学歴（専攻）について調査した結果です。

こちらを見ると理系出身が49.4%に対し、文系出身が37.6%とそんなに大きな差がないことが確認できます。

出典：“IT人材白書2017”. 独立行政法人 情報処理推進機構 p204,図表3-5-4

このことから理系の方が割合として多いものの、文系エンジニアが実在することが判明しました。

学歴を気にしなくてよい理由

先ほどの結果から、文系出身のエンジニアが多いことが分かりました。

しかし、「エンジニアという仕事は文系よりも理系の方が適正があるのではないか？」と疑問に思うかもしれません。

しかし、学歴については以下の理由からそんなに気にする必要はないといえます。

①社会人のスタートとしては大きな差がない

文系出身の方からすると、理系出身の人はITのことがすごく詳しく感じるかもしれません。

しかし、これは若手の時ほど、知っていたか・知らないかくらいの少しの差が大きく感じてしまうこともあり、自分は文系だからできないんだと悩んでしまう人もいるため、入社したての時は苦労する人もいるかもしれません。

ですが、長い社会人生活からみたとき、学生時代の経験なんて簡単にひっくり返ります。

学生時代に少し勉強した経験があるといっても、ほとんどの人はビジネスとしての実績はゼロです。

つまり、理系出身だろうが、文系出身だろうが、大きな差はありません。

社会人になってから、どれだけ成長できるか、ということの方が重要なので、学歴はさほど問題になりません。

②社会人は年齢と実績が重視される

あらゆる企業、世間が社会人を評価する基準は、年齢と実績になります。

こんな感じになっていきます。

転職のときも、何歳でどのような実績があるのか？何ができるのか？が市場価値になります。

そのため、社会人になった後は文系出身か理系出身か、などを気にする人はいないため、社会人になってから学歴をそこまで気にする必要はありません。

（これは出身大学などが有名かどうかについても同様です。）

いくら有名な大学を出ていても社会人になってからの実績がゼロの人は評価できないためです。

文系だと苦労するかもしれないこと

ここまでで、文系か理系かはエンジニアにとって重要ではない。ということをご説明してきました。

それでは、エンジニアになる上で、何が重要なのか？という疑問が出てくると思います。

こちらについては、理系・文系に限らず、エンジニアに向いている人・そうでない人の特徴をまとめた記事を読んでみてください。

・「エンジニアに向いている人、そうでない人」（超絶頑張って、記事準備中です！）

また本記事では、文系だと苦労しそうなことについてピックアップしてお話します。

あくまで統計的な話なのですが、文系よりも理系の方が数学や物理などが得意だった人が多く、プログラミングが得意な傾向があります。

逆に文系の人はそもそものITの仕組み、プログラミングに興味が持てない、難しくて全然理解ができない。と思ってしまう人も少なくないと考えられます。

理系・文系に関わらず、IT自体に興味が持てない人はエンジニアとして仕事をしていくことが苦痛に感じてしまいます。

理系でもエンジニアには適正がない人もいるため、自分が興味を持てるのかどうかを文系・理系に関係なく考えることが重要です。

文系出身者が活躍できること

苦労するかもしれないこととは逆に、文系出身だと活躍できる可能性が高いスキルは以下となります。

エンジニアの仕事はプログラミングだけではありません。システム開発にはお客さんとのディスカッションが必須ですし、チームメンバーとのコミュニケーションも重要となります。

このようなスキルは理系の人が苦手とする分野の傾向があります。

そのため、理系の苦手な事は文系が得意な事だったりするなど、各々の得意分野での活躍が大いに期待できます。

企業としては同じような考え方の人ばかりだと成長できない。文系エンジニアは必要な人材だと言えます。

＜体験談＞私のスーパー上司が文系出身だった話

過去に私が一緒に仕事をしたスーパー上司についてお話します。

その方はとてもロジカルで無駄を嫌い、常にアンサーファースト、さらにプログラミングの知識も現場のプログラマーにアドバイスができるレベルでした。

私は、その凄腕上司はプログラミングを学生時代から身につけてきたと思っていたのですが、ある飲み会で「俺は法学部出身だよ。最初はプログラミングとか全然わからなくてめちゃくちゃ勉強したよ！笑」と文系であることが判明しました。

恥ずかしながら理系院卒の私もそこそこプログラミングができたので、自分よりもプログラミングができる人は学生時代から経験がある人なのかなぁと考えていました。

完全な偏見でした、穴があったら入りたい！

本記事でも書きましたが、学生時代の数年の経験なんて、社会人になってからのキャリアに比べたらほとんどの場合が大した事ないです。

学生時代の数年間よりも社会人としての十数年で何を習得していくかです。

結局、会社に入ってから頑張れるか、頑張りたいと思える仕事か、が重要だと思います。

まとめ

文系というのは現時点でのステータスであり、それが全てではありません。

会社に入ってSEになる事がゴールではなく、SEとして何をするか、どう成長していくか、というマインドを持って頂ければと思います。

以上！！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

SESってやばい噂を聞くけど具体的に何がやばいの？

本記事では、こんな疑問について解説します。

ぐり主任

未経験でエンジニアを目指そうとすると「SESはやめとけ！」と聞くことが多いと思います。

しかし、やばい噂は聞くもののなぜやばいのか？、どうすればSESでも後悔しないのか？について説明してくれる人はあまりいません。

そこで、今回は「SESはなぜやばいのか？具体的に何が大変なのか？」というテーマで話したいと思います。

結論から言うと、SES主体の企業はブラック企業が多いため、見極めないと後悔します！

SESでホワイト企業があるの？と疑問に思うかもしれませんが超絶ホワイト企業も存在します。

例えば、上流のエンジニア（企画、提案、技術力の高いエンジニア、コンサルなど）のSES契約は高給取りです。

しかし、これらは高い提案力・技術力を対価に高額報酬を得るビジネスモデルとなっており、そのような企業に入社する難易度も高いです。

正直、未経験でいきなりそのステージに立つことは難しいです。

しかし、スキルアップ可能な企業に勤めることができれば、あなたの市場価値を上げることで大きくキャリアアップすることができます。

そのためにもSESとは何かを理解した上で勤める企業の見極め、戦略的にキャリアを考える必要があります。

本記事では現役SEの経験を踏まえ、SESの「仕組み、実体験、キャリア戦略」について解説していきたいと思います。

SESの仕組み

SESはやめとけ！と言われる理由をお話するためには、まずSESの仕組みを理解する必要があります。

SESとは

SESとはSystem Engineering Serviceの略で、ITスキルを保有したエンジニアが委託元の仕事をサポートするサービスのことです。

分かりやすく以下の図を使って説明します。

上記のように、IT業界ではSES契約を結びチームメンバを集めてシステム開発を行うことが一般的です。

この場合、

A社のプロジェクトマネージャーが開発するシステムの仕様をお客さんと調整する。

B社のチームリーダーが確定した仕様を基に設計する。

C社のメンバは設計内容を基にプログラミング開発をする。

のようなイメージです。

※各社でどのような役割分担を行うかは契約の内容や各社の立場、状況によって変わります。

このようにSES契約とは、ITスキルが求められる作業に対し、エンジニアが一定期間働く契約となります。

（契約内容としては時間単位の精算をすることが多いです。）

SESに対する勘違い

SESは給与が低く、自由度が少ない、ひどい契約だ！と言われることが多いですが、これは発注元の会社、勤め先の会社がブラックの場合です。

逆にホワイト企業のSES契約の場合は、一ヶ月の労働時間が決まっている契約なので残業がほとんどないケースなどもあります。

同じSESでも勤め先の企業次第で働き方、仕事内容、給与などが違います。SES＝ブラックでやばい！ではなく、SESをするブラック企業がやばい！ということです。

実際に僕の体験談も含めて、具体的なSESの実態を紹介します。

SES実体験から語る6つの知識

僕の実体験を踏まえて、よく質問される６つの内容について解説していきたいと思います。

1.仕事内容

SESは仕事を選べない！と言われますが、本当なのか？

これは半分あたっています。というのも、勤める会社によって大枠の役割が決まるものの仕事の内容は配属されるプロジェクトによって変わるためです。

具体例を用いて、その仕組みについて解説します。

※プロジェクトの体制と各種役割についてパターン分けしてみました。

パターン①

このパターンの場合、C社のメンバーとしてプロジェクトに参加した場合、現場で開発を経験し、プログラミングスキルを向上することができます。

パターン②

パターン①とは異なり、このパターンの場合、、C社のメンバーはプログラムのテストや雑用をすることがメインとなり、スキルやノウハウを向上することが難しくなってしまいます。

パターン③

契約やプロジェクトによってはB社やC社にある程度の裁量があるパターンもあります。

このようにSESの仕事内容は会社の立場やプロジェクトに応じて変化します。これがガチャと呼ばれる由来です。

ぐり主任の場合

個人的につらかった時と良かった時のパターンを紹介します。

• つらかった時

自分目線でつらかった案件としてはこのような体制のときでした。B社やC社の方に作業依頼するものの作業品質が低すぎるため、RVが終わらないなど様々な問題が多発しました。

最終的にはプロジェクトマネージャーのポジションでプログラミングも実施していました。これはマネージャー失格の動きですが、僕が残業してごり押しでプロジェクトを完遂しました。

※元請け目線で、期待するパフォーマンスが出せていないB社の方とは、残念でしたが契約を継続することがありませんでした。

• よかった時

B社のリーダーがすこぶる優秀な方だったのでシステム開発に注力頂き、僕はお客さんからの無茶ぶりなどをブロックしていました。

C社のメンバーもプログラミングスキルが上達しているようでしたので、なかなか良いプロジェクトだったと思います。

仕事の内容はプロジェクトの内容、体制などに依存するため、選ぶことはできませんが、自分がやりたいこと伸ばしたい事をアピールすることで、アサインされる案件が変わってくると思います。

2.労働時間

労働時間がどのくらいなのか気になると思いますが、sesは基本的に1ヶ月あたりの労働時間が定められている契約になります。

そのため、本来であれば残業時間は少ないものとなります。

例えば、1日7.5時間×20営業日=150時間のように1ヶ月の契約時間が決まっています。

そのため、契約時間を超える作業が依頼された場合は契約時間に収まらない事を伝えた上で作業優先度を決める必要があります。

ここのコントロールができないクライアント、元請け、1次請けなどとSES契約を結んでしまうと1ヶ月の範囲内で無限に働かされる事があります。

SES契約は、クライアント、発注元がses契約の根本を理解しマネジメントできるか？が重要となります。

3.給与・年収

SES主体の企業に会社員として務める場合、給与形態は勤め先の会社に準拠します。

どんな仕事をしたとしても一定水準の給与であり、昇進しても勤め先の給与形態に準拠することになります。

そこで、以下のポイントになるのは２つです。

勤め先となる企業が元請け、1次請け、2次請け、3次請け、、、のどこに位置することが多いのか？そのポジションで社員の給与水準はどのくらい高いのか？

入社前にこの２つを見極めなければ、低賃金で給与が上がらなくなってしまう可能性があります。

逆に言えば、ある程度の給与水準が保証されている企業に勤めることができれば、収入は安定します。

4.指示命令系統

SESでありがちなトラブルである指揮命令系統の明確化については知っておいた方がよいです。

これは2次、3次、4次、5次請けなど契約数が多くなると、誰の指示で動けばよいか分からなくなってしまうことです。

チームリーダーが自分の契約先の会社ではないケースなどでは、契約先の会社ではないチームリーダーから作業指示が出る可能性がでてしまいます。

しかし、法律上は契約先の社員から作業指示を受けるべきであるため、自分は誰からの作業依頼で仕事をすれば良いのか？ということを明確にしておく必要があります。

この場合、C社の人がD社の人に指示するべきなのですが、それだと現場が回らないケースもあるため、D社への作業依頼はC社の人が認識した上でお願いする形をとります。

※打ち合わせでC社の合意のもと作業依頼、メールでC社とD社向けに作業依頼など

法律上、B社からD社は契約がないので作業依頼はできませんが、現場では、非常に曖昧になりがちでトラブルが起きないように注意が必要です。

自分がD社のポジションのときにB社から依頼された際は、C社に伝え合意したうえで作業に取り掛かる形がよいと思います。

5.勤務形態・服装・労働環境

SESの勤務形態にはいくつかのバリエーションがあることも押さえておきましょう。

また勤務形態に応じて、服装や労働環境が異なります。

①客先常駐

こちらは発注元の勤務地で仕事をするケースです。

お客さんと同じフロアで仕事をするので、お客さんとコミュニケーションを取っていけるのはメリットです。

ただし、急な作業依頼や質問などがくるというデメリットもあります。

僕もここ数年は客先常駐なので、お客さんのオフィスで仕事をしています。
※自社よりもお客さんのオフィスの方が綺麗なので、ちょっとラッキーです笑

②発注元のオフィスに常駐

発注元のオフィスで仕事をするケースです。

発注元の方が近くにいるため、指示命令系統が混乱することは少ないと思います。

またお客さんが近くにいるわけではないので、ある程度、現場のメンバーで仕事を進めていく形になります。

③自社で作業

SES契約でもリモート作業が許可されているため、自社で作業するケースもあります。

僕は数年前、パッケージ開発を自社で作業することがありましたが、とても働き方の自由度が高い印象でした。
※昼休憩のタイミング、私物のクッションやキーボードの持ち込みなど

④テレワーク

自宅から自社orお客さんの環境にリモートで接続して仕事をすることができます。

僕の場合は、自社から貸与されたPCとお客さんから貸与されたPCの2台でテレワークをしています。

客先常駐がメインでしたが、幸か不幸かコロナの影響でお客さんの環境にリモートで接続できるようになりました。

個人的にはSESでもテレワークで仕事ができる。というのは非常に魅力的かなっと考えています。

服装

SESにおける服装は勤務先のルールに準拠することになります。

エンジニア業界は割とカジュアルな恰好がOKになってきています。

最近はお客さんもカジュアル化が進んでおり、スーツでなくてもOKです。
※僕は服選びが面倒なのでスーツ着てます笑

6.技術力・スキルが上がるのか

SESで技術力やスキルが上がるのか？という疑問を持つと思いますが、実態としては、

• どんな技術力を身に着けられるかは案件次第
• スキルアップするかどうかはその人次第

といったところです。

どんな技術力を身に着けられるかは案件次第

身に着けられる技術は配属される案件次第です。

例えば、Webデザインの仕事、フロントエンドの仕事、バックエンドの仕事など色々な種類がありますが、その中でもプログラミング言語に何を利用するか？などは案件によって異なるためです。

自分が身に着けたい技術があるのであれば、○○のスキルが伸ばせる案件に入りたいです！自社の管理職に主張し続けることが重要です。

僕の場合、最新技術（AWSやSaaSなど）を利用した新規案件をやりたい！と上司に言い続けていた所、ここ数年はやりたいことをやらせてもらっています。

自分の主張が通るかどうかは運もありますが、主張しなければ始まらないので、配属後に自分がやりたいことを伝えることが大切です。

スキルアップするかどうかはその人次第

これはエンジニアに限らず共通して言えることだと思うのですが、仕事を自分から率先して取り組む、というアクションを行えるかどうかでスキルアップするかどうかが変わります。

「任された仕事を指示された通りに行うのか？」「自分なりに調査し、工夫した形で取り組むのか？」で仕事の質が変わりますし、スキルの習熟度も変わります。

エンジニアとしてのスキルが上がるかどうかは自分次第となるため、成長するにはどうしたらよいか？を常に考えることが重要です。

SESで後悔しないために必要なこと

SESの実態を伝えましたが、エンジニアという職種で幸せになるにはどうすればよいのか？と悩む方もいると思います。

そこで、SESで働くうえで後悔しないようにするためのポイントを整理しました。

会社選びが重要

会社員としてSESを行うならば、結局、勤め先がブラックかどうかを見極めることが最重要です。

なぜならば以下の条件は全て勤め先によって決まるからです。

見極めるコツとしては、事前に以下をリサーチしておく方が良いです。

これらは自分の将来も含めて企業選びを行うことが重要です。

SESが全て悪ではなく、ブラック企業に勤めない、ホワイト企業を見つけ出す！ということが重要です。

全てを満たす会社はなかなか難しい

厳しいことを言うかもしれませんが、自分の理想の会社はないと考えた方がよいです。

エンジニアとして働くうえで、自分が何を大事にしたいのか？を明確にしておく必要があります。

例えば、

• 労働時間は長くても良いから給与とスキルを上げたいのか？
• ライフワークバランスを保ちたいので、テレワークができて、労働時間を極力減らしたい。

など、人によって重要なポイントが変わってきます。

自分が仕事に何を求めるのか？エンジニアとしてどのように働きたいのか？方向性を定めたうえで勤める会社を見つけるべきです。

未経験はSES企業へ勤めるべきか？

未経験ならSESに勤めるべきだ！SES企業は勤めたくない。などの意見がありますが、僕の見解としては、以下２点です。

• 雇用形態はよりも自分がやりたいことができる企業を探すべき
• 自分が提供できる価値を踏まえた上で、会社の条件を探すべき

SESだから～というよりは、自分がやりたいことができるか、行きたい会社に自分が価値提供できるのかが重要です。

未経験でエンジニアになりたい人がやたらSESを避ける傾向があります。しかし、SESだけを避けたところで理想の開発ができるとは限りません。

正しい会社選びをしなければブラック企業に勤めることになります。またエンジニアにはSES、社内SE、自社開発など多様な働き方がありますが、どれが自分にあう働き方かは異なります。

どれが自分にあう働き方であるか、目指すべき会社を見据えつつ実力をつけていくべきです。

未経験ということは働き方を選べる立場ではないことも多いです。

未経験でエンジニア転職・就職を目指すとき、SESに限らず企業があなたを採用するメリットを考えているでしょうか？

あなたが経営者でエンジニアを雇う時、未経験者を高い給料でリモートワークで雇おうと考えますか？

未経験ということは、教育する必要があるため、即戦力にはならないケースが多いです。

その上で未経験者を雇うということは、半年～数年後に活躍できるポテンシャルを持っているかどうか？を判断した上で採否を決定しています。

プログラミングの基礎学習を終えている場合は学習コストが少ないことをアピールしているということになりますが、即戦力のアピールには不十分です。

SES企業でも元請けや2次請けの仕事を未経験で実施することは難しい場合も多いので、3次請け、4次請けとなる可能性も高いです。

自分の市場価値（スキル、できること）を踏まえた上で、どのような企業で仕事ができるか、スキルアップの戦略を立てた上で会社を選ぶことが必要です。

自分のスキルが足りないため、初回の就職時に理想のエンジニア就職・転職ができない可能性は考慮しておいた方が良いです。

経験者がSESで勤める場合の注意点

経験者のエンジニアがSES企業に勤める場合は、「現在の立場、スキルに対して待遇が適切であるか？」を確認した方がよいです。

例えば、自分が保有しているスキルと現状の待遇を書きだしてみてください。

これらを整理した際に、第三者目線で待遇が悪い、あるいは待遇の比率を変えたい（給与が下がっても労働時間を減らしたいなど）があれば転職した方がよいです。

※転職先候補からも外したほうが良いです。

逆に他社で活用できるスキルを自分が保有していない場合は転職をすることで待遇が悪くなるリスクもあるため、注意が必要です。

SESから年収を上げる方法【キャリア戦略】

SESからの年収を上げる戦略は大きく３パターンだと思います。

キャリアアップ転職

SESエンジニアからキャリアを上げる最もスタンダードな戦略は転職です。

エンジニアから転職する場合、いくつかのパターンがあります。

• エンジニアの経験を活かして、エンジニアとして待遇の良い企業に転職する
• エンジニアの経験を活かして、業種を変える（コンサルになる等）
• エンジニアの経験を活かして、発注側の企業のIT部門に転職する

自分のエンジニアの経験を活かせば上記のようなキャリアアップを目指すことができます。

逆に言えば、何も考えずにエンジニア経験を積むだけでは転職先で求められるスキルが身につかないため、キャリアアップ戦略を意識することは重要です。

フリーランス

SESエンジニアで個人でシステム開発をするスキルが身についた人ならフリーランスになることも選択肢の１つではあります。

フリーランスになると会社員の時よりも給与が高くなる傾向があります。

※額面だけで会社員の頃の2～3倍はもらえるイメージ

ただし、会社員にはボーナスや福利厚生がありますが、フリーランスになると失うものもあるため、目先の給与だけでなく長期的に見て得になるか考えてから実施した方がよいです。

いきなりフリーランスになることはリスクが高いため、フリーランスを見据えた働き方、副業などで実績を作ってからフリーランスになることをおすすめします。

※フリーで発注していただける顧客とのコネクションがあれば、ある程度は安心できます。

副業

年収を上げる方法として個人的には一番おすすめの選択が副業です。なぜなら副業は本業の恩恵を受けつつ、年収を上げることができるからです。

副業をスタートする場合に注意したいのが、本業で蓄えた資金の許容範囲内で副業を開始することです。

僕の知り合いにもせどりなどの物販をいきなり大規模に開始して在庫不良で困り果てている人がいました。

ビジネスの基本はスモールスタートで、自分に合っているかも含めて軌道に乗ってきたら規模を大きくしていくことがおすすめです。

なお、エンジニアの副業としておすすめなのはプログラミング、Web制作、ブログあたりです。

SESはやめとけ！についてのまとめ

本記事ではSESはやめとけ！と言われる理由について、以下を解説してきました。

最近はプログラミング学習が流行っていますが、楽をして稼げるほど甘い業界ではありません。

プログラミングスキルは再現性も高く、学習コストに対する給与のコスパが高いのは事実ですが、業界をしっかり把握したうえで、エンジニアへの一歩を踏み出してほしいと思います。

以上です！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

Google Apps Scriptは便利って聞いたけど、何から始めればよいのだろう？

本記事では、こんな悩みを解決します。

ぐり主任

GASの学習を行いたいと考えても、何から始めればよいのか分からない。ということがあると思います。

実際に僕もGASでアプリを開発したいと思ったものの、何から始めればよいか分かりませんでした。

そこで、GASを勉強するためにGoogle検索したところ、とあるサイトを発見！たった1時間でGASアプリ開発ができてしまいました。

当時、感動のあまり以下のようなツイートをしています笑

タカハシさん（@ntakahashi0505 ）のこの記事は素晴らしいですね
GoogleAppsScriptの知識がほぼ0から1時間たらずでAPIの時限呼び出しができてすごく楽しいです#プログラミング#GoogleAppsScript

【保存版】初心者向け実務で使えるGoogle Apps Script完全マニュアル https://t.co/8pjN7Gycoj

— ぐり主任@サラリーマンエンジニア (@gurishunin) January 2, 2021

これをきっかけにブログの執筆者であるタカハシ（高橋宣成）さんの書籍「詳解! GoogleAppsScript完全入門[第2版]」を購入し、GASを使ったアプリ開発を行うようになりました。

本記事では、実際にGASアプリ開発した経験を踏まえて「詳解! GoogleAppsScript完全入門[第2版]」の書評をしていきたいと思います。

実際に僕が書籍を読みながら開発したアプリは以下の記事で紹介しています。

記事の本編に入る前に簡単な自己紹介です。

僕はシステム開発が本業でプログラミング経験あり、Google Apps Scriptについては初心者という状態からブログと書籍で勉強しましたが、プログラミング未経験者こそ本書を利用した勉強がおすすめです。

プログラミング経験者目線で、その理由なども解説していきたいと思います。

本との出会い（購入した経緯）

冒頭でもお話しましたが、簡単に書籍を購入した経緯についてお話します。

※読み飛ばしていただいても問題ないです。

Google Apps Scriptを始めた理由

僕は本業でシステムエンジニアをしているのですが、年次が上がった現在はマネージャーのポジションとなっていました。

そのため、「プログラミングをする」ポジションから「プログラミングをする人を管理する」ポジションになってきており、自分が手を動かす機会が減ってきていました。

しかし、僕自身はプログラミング自体が好きだったし、流行している言語を学んだり、自分でアプリを作りたいと考えていました。

プライベートで何かプログラミングで遊んだり、アプリを作ったりできないかと調べていたときに、とあるyoutubeで「GASだと動作環境などが無料で簡単に様々なことが実現できる！」ということが分かったので、やってみたいと思ったのがGAS学習のきっかけとなります。

書籍購入を決めた理由

GASを勉強したいと思って、googleで検索してみたところ、タカハシさんの以下のページを見つけました。

【保存版】初心者向け実務で使えるGoogle Apps Script完全マニュアル

こちらのページはとても丁寧で初心者がGASを始める手順などがE-learningのような形式で実践できるものでした。

GAS初心者の僕だけでなく、プログラミング未経験でも簡単にアプリ実装ができるような手順を示してくれています。

このような経験からGASを１から学ぶならタカハシさんのコンテンツを利用したいと思い、タカハシさんが執筆しているGASの入門書を購入することを決めました。

本の内容

前作からの変更箇所

「詳解! GoogleAppsScript完全入門[第2版]」は2017年12月に発売された「詳解！Google Apps Script完全入門」を最新化した内容となります。

IT業界で3年も経過すると、GASにも多数のアップデートがあり情報が古くなってしまうのですが、2020年12月に最新版として発売されました。

※個人的にはGAS学習を始めたタイミングと被っていてラッキーでした(*^^*)

アップデートによる大きな変更としては、V8ランタイムで使用できるようになった新構文にも対応していることです。

V8ランタイムはGoogleが開発したJavaScriptエンジンで、いくつかJavaScriptの便利な構文をGASで利用できるようになった。というイメージです。

記載内容

具体的な内容は本書を実際に購入して読んで頂きたいのですが、以下のような目次となっています。

構成としては、

のようなイメージで、基礎的な知識、実践的な知識を体系的に網羅しているところが特徴です。

実は購入前に本屋さんに行って、GAS本を色々読んでみたのですが、GAS本の中で本書が最も情報量が多く、体系的・網羅的に整理されていると思いました。

書籍の特徴

続いて、僕が感じた詳解! GoogleAppsScript完全入門[第2版]の特徴（メリット、デメリット）を解説していきたいと思います。

メリット

僕が感じたメリットは以下です。

学習の手順が分かる

プログラミング学習で割と良くあるのですが、GASを１から学ぶ際にどのような手順で何を学べばよいか分からないと思います。

しかし、この書籍の１章から順番に学習していけば、GASの知識を体系的に習得することができます。

本書には以下のような工夫があるので、学習時の理解を深めることができます。

個人的には「本を読みながら、サンプルコードを実行して自分で遊んでみる」のような学習の進め方がおすすめです。

余談ですが、僕は他のプログラミングの経験があったので、

3～4を繰り返しながらアプリを完成させる。のような進め方で学習を進めてました。

GASの知りたい事の大半がこの１冊調べられる

本書は583ページにわたりGASについて解説しており、初心者から上級者までGASについて学習するには十分なボリュームです。

技術本の中には初心者向けにあえて内容を少なく簡単に説明している書籍があったりしますが、しっかり学習したいのであれば初めから情報量が多い書籍を購入するべきです。

「こういう時はどうしたらよいのだろう？」のような悩みが出てきても、一通りのことは本を読めば解決できます。

GASの知識を体系的にインプットできる

本書はGASの知識が体系的に整理されているため、読者が「そんな便利なことができるのを知らなかった」のようなことを未然に防ぐことができます。

知っていれば簡単だったのに知らないから遠回りをしていた。ということはシステム開発の現場でも発生します。

例えば、ライブラリを知っていれば１行でできることを知らなかったので、100行くらいプログラミングで自作しました！ということが発生します。

ライブラリを使えば品質をそれなりに担保されているところを自作してしまったため、試験が必要になってしまう。という悲しいことが割とあります。

目的がライブラリを使わずに実力をつけること。であれば問題ないのですが、大抵の場合は遠回りになってしまいます。

IT業界は知識を知っているかどうかだけで差がつくことが多いため、現在GASをつまみ食いしている人はこの本で体系的な知識を習得するとさらなる飛躍につながると思います。

デメリット（注意点）

正直、この本はここがダメだ！みたいなデメリットは思いつかないのですが、技術書として一般的なデメリットは購入時に注意しておく必要があります。

出版時から情報が古くなること

これは全ての技術本に共通するのですが、最新情報と差分が生まれるケースがあります。

GASはGoogleの提供するプラットフォームで動作する都合上、常にアップデートされます。

そのため、本を執筆している間、あるいは出版後に変更された内容は差分が出てしまいます。

しかし、この点についてはタカハシさんのブログで新IDEで書籍を読み進める注意点をまとめており、書籍とブログを組み合わせることで最新のバージョンに対応できるようになっています！（控えめに言って神対応です）

新IDEでGAS本第2版を読み進めるときの注意点

技術本は常に最新情報が更新されてしまうため、購入する際は出版日が新しいものがおすすめとなるのですが、ブログなどの媒体で最新情報を発信して頂けるのはとてもありがたいです。

今後、書籍×ブログでの対応が難しいアップデートが入った場合は書籍の第３版が出版される形になるかと思いますが、現状は問題なく学習できています。

デメリットを書いていたのに、総合的にみると他の書籍にはないメリットをご紹介する形になってしまいました笑

他のサービスを組み合わせた事例はカバーしきれないこと

GASの書籍であるため、GAS×TwitterやGAS×Line APIなどの具体的なサービスの組み合わせ事例などは本書には記載されていません。

※GASと他のサービスの組み合わせを記載していたら何ページあっても足りないですからね。

本書にはGASで外部APIを呼び出す方法や、取り扱いの基本的な内容は記載されているので問題ないのですが、他のサービスとGASを組み合わせたことが全て本書でカバーできている訳ではないことは認識しておいた方がよいです。

ちなみに僕がGAS×Line APIでアプリを作ったときは以下のような形で開発を進めました。

GAS×Lineのアプリを開発したいのであれば、Line APIの別書籍を購入して、２つの書籍の知識を組み合わせるのがよいです。

エンジニアは自分がやりたいこと、作りたいものを実現するために必要な知識が何か？を確認した上で、書籍の選定、知識の習得をすることが重要です。

参考としてGASとLine APIを連携するための初期設定についてまとめた記事を紹介します。

購入してみた感想

僕は何か目的を達成する手段として、プログラミングに取り組むことが多いのですが、このような学習方法だと知識のつまみ食い状態となってしまいます。

本書を購入したことで

などを経験できたので、知識が体系的にまとまっている書籍の価値は高いと感じました。

すべてのページを読破し、知識を習得しきった訳ではないのですが、必要なとき必要な情報が得られる本書を重宝しています。

購入をおすすめしたい人

僕は以下のような方には購入をおすすめします。

購入をおすすめしたい人

今まで説明したように、本書は初心者にとってガイドラインになるため、購入をおすすめします。また、体系的に整理されているため、現在独学で勉強している人も購入する価値があると思います。

状況次第で購入した方がよい人

以下の方は状況次第で購入した方がよいと思います。

すでに第１版を購入している人

すでに第１版を購入している方は、V8ランタイムなどの新しい要素に対する知識次第かと思います。

今回の第２版はアップデートの内容で第１版から大幅に変更・修正が入っている形になるため、個人的には購入して損はないのですが、第１版を保有している方はすでにGASのベース知識をつけていると思いますので、最優先で購入する必要はないかと思います。

Googleのアップデートの変更点（V8ランタイムなど）についてしっかり勉強しておきたい人は購入をおすすめします。

すでにGASの知識が充実している人

GASを使って様々なサービスを開発したり、本を出版したりできるレベルの方は進んで購入する必要はありません。

ただし、技術者として自分の知識を体系化して整理したい。と思っている方は本書を読むことで経験を棚卸できる良い機会になります。

また技術者としてタカハシさんのように知識をアウトプット（書籍出版）したい人は参考になるため、内容だけでなく、知識の整理の仕方などを勉強する意味で購入するという選択があります。

まとめ

GASを学習する上で、「詳解! GoogleAppsScript完全入門[第2版]」をご紹介しました。

GASの学習をしたい方は是非手に取っていただきたい書籍です。

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

手順を画面キャプチャしながら説明しているので、Lineチャットボットに興味がある初心者の方向けの記事となります。

今回の取り組みは僕がダイエット記録アプリを作る2ステップのうち、ステップ②となります。

1からLineチャットボットを作る前回記事はこちらとなります。

記事の本編に入る前に簡単な自己紹介です。

はじめに

僕の本業はSEでシステム開発やプログラミング経験はあるものの、GASやLineチャットボットの開発は今回が初めてでした。

前回作成したLineボットをベースに今回の追加開発は30分くらいの時間で作れました。

慣れている人ならばもっと早いと思いますし、未経験なら僕以上に時間がかかるかも。といった感じです。

なお、GASのプログラミングは以下の書籍を参考書としたり、ネットで検索しながら実装しました。

今回実装する設計

今回実装する設計図は以下となります。

前回の開発で「Lineで入力したメッセージをGASのプログラムでそのまま回答するチャットボット」は開発済ですので、「受け取ったメッセージをスプレッドシートへ書き込む」という部分を開発します。

開発を行うためには以下の手順となります。

それでは手順を解説していきます。

①Lineで受け取ったメッセージをチェック

前回の記事でLineAPIから受け取ったメッセージをそのまま回答する部分を開発しました。

※前回の記事はこちら

if分を使って、受け取ったメッセージが数字かどうかをチェックし、フラグで判定します。

チェック結果がNGの場合は”数値を入力してください。”という返答用のメッセージを設定します。

 command
//入力チェック
if(!isNaN(userMessage)){
chFlg = 1;
}else{
resMessage = “数値を入力してください。”;
}

②チェック結果がOKならスプレッドシートへ書込み

チェック結果がOKであれば、受け取った数値をスプレッドシートへ書き込みを行います。

チェック結果がNGの場合は、書込みを行いません。

 command
//入力チェックOKの場合、スプレッドシートへ内容を記録
if(chFlg != 0){
//記録
wSheet.getRange(nRow, 1).setValue(today);
wSheet.getRange(nRow, 2).setValue(userMessage);
//応答メッセージをセット
resMessage = “記録しました！”;
}

さきほどのチェックがOKの場合のみ実行する形となります。

OKの場合は”記録しました！”という返答用のメッセージを設定します。

③結果を通知

前回の開発では、受け取ったメッセージをそのまま返却していましたが、今回は作成したメッセージをセットします。

 command
UrlFetchApp.fetch(url, {
‘headers’: {
‘Content-Type’: ‘application/json; charset=UTF-8’,
‘Authorization’: ‘Bearer ‘ + ACCESS_TOKEN,
},
‘method’: ‘post’,
‘payload’: JSON.stringify({
‘replyToken’: replyToken,
‘messages’: [{
‘type’: ‘text’,
‘text’: resMessage,
//’text’: userMessage,　前回のメッセージ
}],
}),
});

今回の追加実装の内容

今回の開発したソースコードを参考として載せておきます。

少し雑な部分もあるため、あくまで参考として頂ければ幸いです。

※ブログだとソースのインデントが左寄せになってしまっています。。。

 command
// LINE developersのメッセージ送受信設定に記載のアクセストークン
const ACCESS_TOKEN = ‘アクセストークン’;
function doPost(e) {
// WebHookで受信した応答用Token
var replyToken = JSON.parse(e.postData.contents).events[0].replyToken;
// ユーザーのメッセージを取得
var userMessage = JSON.parse(e.postData.contents).events[0].message.text;
// 応答メッセージ用のAPI URL
var url = ‘https://api.line.me/v2/bot/message/reply’;
//応答メッセージ
var resMessage;
//入力チェック結果
var chFlg = 0;
//記録先シート
const ss = SpreadsheetApp.getActiveSpreadsheet();
const wSheet = ss.getSheetByName(‘weight’);
//最新行を取得
const lastRow = wSheet.getLastRow();
var nRow= lastRow+1;
//本日日付を取得
var date = new Date();
var today = Utilities.formatDate( date, ‘Asia/Tokyo’, ‘yyyy/MM/dd hh:mm:ss’);
//入力チェック
if(!isNaN(userMessage)){
chFlg = 1;
}else{
resMessage = “数値を入力してください。”;
}
//入力チェックOKの場合、スプレッドシートへ内容を記録
if(chFlg != 0){
//記録
wSheet.getRange(nRow, 1).setValue(today);
wSheet.getRange(nRow, 2).setValue(userMessage);
//応答メッセージをセット
resMessage = “記録しました！”;
}
UrlFetchApp.fetch(url, {
‘headers’: {
‘Content-Type’: ‘application/json; charset=UTF-8’,
‘Authorization’: ‘Bearer ‘ + ACCESS_TOKEN,
},
‘method’: ‘post’,
‘payload’: JSON.stringify({
‘replyToken’: replyToken,
‘messages’: [{
‘type’: ‘text’,
‘text’: resMessage,
//’text’: userMessage,
}],
}),
});
return ContentService.createTextOutput(JSON.stringify({‘content’: ‘post ok’})).setMimeType(ContentService.MimeType.JSON);
}

実行結果

実行結果のイメージは以下のような形です。

Line入力画面

以下のように正しく応答ができたことを確認しました。

・「テスト」と入力した場合、入力チェックにより、数値を入力してください。

・「81.6」と入力した場合、入力チェックOKとなり記録したことを通知。

スプレッドシートへの書込み結果

さきほどの結果をスプレッドシートで確認したところ、実行前から１行追加されていることを確認しました。

まとめ

GASとLineAPIにスプレッドシートへの連携を追加しました。

これは当初思っていたよりも簡単だったので、今後もgas、スプレッドシートなどを活用したアプリ作っていきたいと思います。

引き続きプログラミングで遊んでいきたいと思います！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

手順を画面キャプチャしながら説明しているので、Lineチャットボットに興味がある初心者の方向けの記事となります。

今回の取り組みは僕がダイエット記録アプリを作る2ステップのうち、ステップ①となります。

記事の本編に入る前に簡単な自己紹介です。

はじめに

僕の本業はSEでシステム開発やプログラミング経験はあるものの、GASやLineチャットボットの開発は今回が初めてでした。

僕のスペックで今回の開発は１時間くらいかかった形です。

慣れている人ならばもっと早いと思いますし、未経験なら僕以上に時間がかかるかも。といった感じです。

なお、GASのプログラミングは以下の書籍を参考書としたり、ネットで検索しながら実装しました。

こちらの書籍を僕がおすすめする理由については以下の記事で解説しています。

今回実装する設計

今回実装するGASを利用したLineチャットボットの設計図です。

Lineで入力したメッセージをGASのプログラムでそのまま回答するチャットボットを開発します。

開発を行うためには以下の手順となります。

それでは手順を解説していきます。

①Google Apps Scriptの準備

まずはGoogleアカウントでGoogleドライブへログインして下さい。

スプレッドシートの作成

ログインしたら以下のように「Googleスプレッドシート」から「空白のスプレッドシート」を選択します。

スクリプトエディタの編集

スプレッドシートを開くとエクセルのシートのようなものが表示されます。

ここで「ツール」タブから「スクリプトエディタ」を選択します。

GASでのプログラミング準備完了！

スクリプトエディタを選択するとプログラミングを書くエディタが表示されます。

ここのスペースにGoogle Apps Scriptでプログラミングを作成していきます。

これでGASによるプログラミングの準備ができました！

②Line開発アカウントの取得

続いて、今回利用するLineチャットボットの開発アカウントを作成します。

Line Developerのページへアクセス

以下のページからアカウント作成をしていきます。

・Line Developerのページ

まず、ページにアクセスして右上の「ログイン」を押します。

Line Developerアカウントの作成

続いて、アカウントの作成を行います。

僕の場合はすでにLineアカウントを持っていたので、そちらでログインしたところ、以下の入力を求められました。

Line Channelの作成

アカウントが作成できたら、続いてchannelを作成します。

このchannelは後から追加・削除できるので、今回のAPI実行用に作成してみましょう！

Line Channelのアクセストークンの発行

channelが作れたら、Lineのボットへのアクセスを許可するための長期トークンを発行しましょう！

このトークンをプログラムに設定することでLineとGoogleの連携ができるようになります。

これでLineと連携するためのトークンが発行できました。

③Google Apps Scriptによるプログラミング

今回のプログラムは以下のような簡単なプログラムです。

そこまで難しくないため、初心者の方でも簡単に作れる内容となります。

実際のプログラム

今回のプログラムソースを参考として以下に公開します。

※アクセストークンは先ほど発行したものを張り付けてください。

 shortcode
// LINE developersのメッセージ送受信設定に記載のアクセストークン
const ACCESS_TOKEN = ‘アクセストークン’;
function doPost(e) {
// WebHookで受信した応答用Token
var replyToken = JSON.parse(e.postData.contents).events[0].replyToken;
// ユーザーのメッセージを取得
var userMessage = JSON.parse(e.postData.contents).events[0].message.text;
// 応答メッセージ用のAPI URL
var url = ‘https://api.line.me/v2/bot/message/reply’;
UrlFetchApp.fetch(url, {
‘headers’: {
‘Content-Type’: ‘application/json; charset=UTF-8’,
‘Authorization’: ‘Bearer ‘ + ACCESS_TOKEN,
},
‘method’: ‘post’,
‘payload’: JSON.stringify({
‘replyToken’: replyToken,
‘messages’: [{
‘type’: ‘text’,
‘text’: userMessage,
}],
}),
});
return ContentService.createTextOutput(JSON.stringify({‘content’: ‘post ok’})).setMimeType(ContentService.MimeType.JSON);
}

④作成したプログラム（API）のデプロイ・設定

プログラムを書き終わったら、APIをデプロイします。

デプロイとは、作ったプログラムを常に動かせる状態にする形です。（いちいち実行ボタンを押さなくても動くようになります）

今回の場合、デプロイをしないとプログラムはただのテキストですが、デプロイすることでLineのチャットがくるたびにプログラムが動くようになります。

デプロイボタンを押す

作成したプログラムの右上から「新しいデプロイ」を選択します。

ウェブアプリとしてデプロイ

設定からウェブアプリを選択します。

デプロイする公開範囲を設定

今回の公開範囲としては、アクセス可能なユーザを全員、実行ユーザを自分で設定しデプロイボタンを押します。

今回の公開範囲はLineからアクセス可能なように全員としますが、基本自分しか利用しないアプリとなります。

アクセス権限の承認

デプロイボタンを押すとアクセスを承認する設定が必要になります。

アクセス承認を押しましょう。

以下のメッセージが出て驚く方もいらっしゃると思いますが、問題ありません。

これは「僕が作ったプログラムはGoogleで確認が取れていません！」という警告文です。

「今回作成したプログラムがGoogleドライブへアクセスしようとしているけど、大丈夫ですか？」と聞かれているので、「問題ない」と設定をしていきます。

左下の「詳細」を選択します。

「安全ではないページ」（僕が作ったプログラムのページ）を選択します。

プログラムがアクセスを求めているので、許可設定をします。

デプロイ完了

アクセス許可が完了すると、デプロイが完了して以下のページが表示されます。

ここで表示されているURLをLineに設定する必要があるのでコピーしておきましょう。

⑤LineチャンネルでAPIの呼び出し設定

GASのプログラムをデプロイしたら、LineのチャンネルからGASを呼び出す設定を行います。

Webhook設定

Webhock設定に先ほどコピーしたGASのウェブアプリURLを張り付けて、更新ボタンを押してください。

応答設定の変更

Webhockの設定が終わったら応答設定を行います。

この設定で、Lineチャットでメッセージを受け取ったら、GASへ連携して応答メッセージを返却する設定にできます。

以上で設定完了です！

実行結果

作成したチャットボットをLineの友達追加します。

あとは適当な文字を入力してみてください。入力したメッセージをそのまま返答します。

今回は、チャットされたメッセージをそのまま応答していますが、GAS側で応答メッセージを変更することで様々なチャットボットを開発できます。

まとめ

GASとLineAPI初心者の僕でも簡単に実装できました。

僕が特に感動したのは以下です。

引き続きプログラミングで遊んでいきたいと思います！

【エンジニアのスキルアップ】Udemyのお得なクーポン

最後に、少しだけ宣伝です。

私はUdemyでエンジニアとしてスキルアップするための講師をしています。

以下のページにお得なクーポンページを設置しているので、ご興味がある方は覗いてみてください。

Udemyでエンジニアのスキルアップ！【お得なクーポン】

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

ぐり主任

ぐり主任

・・・GASでアプリを作ってダイエット記録を効率化しよう！

本記事では、コロナで太ってきた筆者がGASとLineを使ってダイエット記録アプリを制作した流れを解説します。

・・・痩せたかどうかは別です(‘ω’)

記事の本編に入る前に簡単な自己紹介です。

システム開発は本業ですが、Google Apps ScriptやLineを利用したプログラミング経験がなかったため、今回の取り組みでチャレンジした！という形です。

実際に仕事でやっているよりは簡易的ですが、要件定義～運用までのシステム開発の流れに合わせて紹介していきます。

アプリ開発の背景と目的

ダイエット実施の背景

冒頭でもお話しましたが、コロナによって体重が5kgほど増えました。

見た目としては、完全にお腹が出ている状態です。

そこで、ダイエットをするために体重を記録することから始めよう！と考えました。

※食事制限や運動など、ダイエット自体の取り組みは並行して実施しています。

アプリ開発しようと思った理由

毎日体重を記録するなんて余裕！と思っていた時期が僕にもありましたが、

この流れが面倒になってきました。

楽になる方法を調べたところ、最近の体重計は測定した情報（体重、体脂肪率など）を自動でスマホへ連携し、管理できることが分かりました。

↓最近の体重計はこんなやつです。

※僕の家の体重計は旧型で、搭載機能は「体重を記録する！」という１機能のみ

新しく体重計を購入して、「諸々のデータを管理する方が良い」というのは分かっていたのですが、せっかくデータを収集するなら自分でデータを管理したいし、何ならアプリみたいなの作ってみたい！と思いました。

特に、以下の思いが強かったです。

そんなわけで、Google Apps ScriptとLineのMessage APIを使ったプログラミングで簡単なアプリを作ってみようと思いました。

（ぶっちゃけ自己満足に近いですね笑）

目標

そんなわけで、以下の目標をたててアプリを開発することにしました。

体重を減らすこと！というのが目的ではあるのですが、今回のプログラミング・開発では効率化＆知識習得がメインの目的です。

なお、僕が利用したおすすめの参考書を以下の記事で解説しています。

【要件定義】アプリの要件

今回のアプリの要件は以下です。

業務フローの改善

要件定義工程では現状の業務フローと改善後の業務フローを整理します。

業務フロー①　体重の記録を行う

業務フロー①は体重を測定して記録をするという業務フローです。

今回の開発では、劇的な業務フローの改善はできませんが、入力項目を少なくする！という改善をしたいと思います。

業務フロー②　記録内容を可視化する

業務フロー②は記録した体重をグラフ化する部分です。

僕がもともと使っていたアプリだと体重の増減をグラフ化（日/月単位）するだけでした。また、アプリで管理している項目しかグラフ化できませんでした。

そこで、今回のプログラミングで、BMIや体重（日、週、月単位）を管理し、平均〇kg体重が増減している。などもグラフ化できるようにしたいと考えています。

今回のプログラミング開発による業務的なメリットは、基礎情報を自分で管理できるようになることだと考えています。

利用環境

今回の開発で利用する環境は以下です。

スマホ以外は無料で用意できる環境になります。

【基本設計】アプリの全体設計

今回の基本設計は以下のような図になります。

本業では①～⑥までの処理をどのような方式・APIで実現するか？なども記載するのですが、今回は規模も小さく、既存APIを利用するので、このレベルでも十分かな。と考えています。

【製造・試験】アプリの実装

実装のステップは大きく分けて２ステップに分けました。

STEP1　メッセージに対して返事をするLine ボット作成

GASとLineAPIを利用するのは初めてだったので、STEP1ではLineのメッセージを受け取ったら、返事を返すLineのチャットボットを作成します。

イメージとしては、以下の部分を実装します。

一気に開発しても不具合が発生した際にエラーの原因特定が難しいため、部分的に実装しながら進めます。

STEP1の実装についての詳細は以下の記事をご参照ください。

STEP2　Google Spread Sheetへの追記機能の追加

STEP1が開発できたので、STEP2の部分を追加開発します。

機能としては以下を追加

【補足】例外処理などの対応について

今回のアプリは以下の理由から異常系やエラー処理などは簡易的なものとしました。

GASやLineの実行制約を上回るほど、APIをコールしたり、高負荷となるアプリではないので、そこまで問題ないと考えています。

実際の動作確認時もシステムエラーのパターンは問題なさそうでした。

【運用】実際に使ってみた

個人的には満足のいく出来栄えです。

Lineの入力画面

体重計に乗った後、すぐにチャットすることで簡単に記録できたことが通知されます。

Googleスプレッドシートの記載

Lineでチャットした内容はスプレッドシートに記載されます。

簡単に記録できるようになりました！

アプリ制作の感想

今回のアプリ制作でGoogle Apps Scriptの使い方（基礎）とLine Message APIの使い方（基礎）を学ぶことができました。

GASやLineAPIなどはプログラミングをがっつり触っていない人でも簡単に始められる要素が多いので、おすすめできます。

そんな感じで当初の目標は達成できました！あとは痩せるだけですね笑

【エンジニアのスキルアップ】Udemyのお得なクーポン

最後に、少しだけ宣伝です。

私はUdemyでエンジニアとしてスキルアップするための講師をしています。

以下のページにお得なクーポンページを設置しているので、ご興味がある方は覗いてみてください。

Udemyでエンジニアのスキルアップ！【お得なクーポン】

以上！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

エンジニアについて知りたい！

本記事では、こんな疑問を解決します。

ぐり主任

「エンジニアとは何か？」というテーマで話したいと思います。

最近はAIなどのキーワードが流行っており、IT系人材、エンジニアが不足していると言われています。

しかし、エンジニアと言われても、どんな仕事をしているのか、いまいちピンとこないと思います。

実際に僕も家族や友人に自分の仕事を説明するときはすごく簡単に以下のような説明をしています。

「Amazonや楽天とか買い物できるサイトがあるでしょ。そこでクレジットカードを使えるよね。みんながクレジットカードをインターネットで使えるような仕組みを作っているよ」

この記事を見ているあなたはもう少し詳しくエンジニアとは何かを知りたいと思いますので、僕の経験を交えながら「エンジニアとは何か？どんな仕事をしているのか？どうすればなれるのか？」あたりを解説します。

エンジニアとは？

あなたはエンジニアと言ってどんなイメージをされていますか？

「プログラミングをして、システムを開発している人」

こんなイメージを持っているのではないでしょうか。

近年では、IT系の技術者のことをエンジニアと表現することが一般的になっているので、そのイメージは正しいです。

ただ、プログラミングやシステムって結局どうやって開発しているのか分からないと思いますので、分かりやすく解説していきます。

エンジニアの仕事内容

エンジニアの仕事の内容は大きく以下のステップで実施します。

分かりやすくアプリを友人に作ってあげる例で説明します。

具体例はあくまでイメージなので、お客さんが企業であったり、複数人のチームでシステムを作ることもあったりしますが、エンジニアの仕事の流れは概ねこんな感じです。

エンジニアの種類

エンジニアの仕事のイメージはご説明しましたが、エンジニアにはどの技術に特化するのかで呼び名が変わります。

スポーツで分かりやすくイメージして頂くとプロ野球選手でもピッチャーやキャッチャーのように各ポジションが分かれている感じです。

エンジニアといっても得意分野が様々なので、○○エンジニアのような呼び名で仕事の内容が少し変わってきます。

最近では○○エンジニアの種類が多いため、代表的なエンジニアの種類とその内容について解説します。

システムエンジニア（SE)

SEという言葉はよく聞くと思います。一般にエンジニアと言われるとシステムエンジニアを示すケースが多いです。

先ほどの仕事内容で解説した①②③のようなお客さんと接しながら実際にシステムを開発することが主な仕事となります。

※職場や役割によっては、「お客さんとのやりとりが主流」「システムの設計が主流」など同じシステムエンジニアでも仕事の主軸が異なることはあります。

プログラマー

あなたの想像通り、プログラマーの仕事はプログラミングでシステムを開発することになります。

システムエンジニアから受け取った設計書を基にプログラミングでシステムを開発する。

またプログラマーにも得意なプログラミング言語が人によって異なります。

“c言語”、”java”、”python”など

、今まで開発したことがあるシステムが”金融系のシステム”、”製造系のシステム”など得意領域も異なります。

個人的にはjavaが書ければ、他の言語もできると思いますが、プログラマーは自分が得意な言語を用いてシステム開発をしていくことが主流となっています。

Webエンジニア

WebエンジニアはシステムエンジニアのWebサイト特化版でWebサイトに特化したプログラミングを仕事とします。

ショッピングサイト（Amazon・楽天のようなサイト）や企業のホームページを開発するのが主な仕事のイメージです。

Webエンジニアの仕事はフロントとバックエンドの2つがあります。

Webエンジニアはシステムエンジニアとプログラマーのどちらの要素も含まれますが、プログラミングに特化した人など得意分野で差別化しているケースもあります。

インフラエンジニア

インフラエンジニアはシステムエンジニアのインフラ特化版で、サーバやNW（ネットワーク）などの構築を得意分野としています。

たくさんの人がWebサイトにアクセスしても、サーバへ接続ができるようにシステムのインフラ周りを設計することを仕事にしています。

Webサイトやアプリケーションは必ずサーバ上に開発されます。

そのため、システム開発には、どのようなサーバを構築するべきか、NW（ネットワーク）をどのように構築するべきかを考える人が必要となります。

インフラエンジニアはどのようなシステムに対しても利用できるインフラの技術であるため、特定の業務に依存しない技術を保有しています。

最近ではAWS(アマゾン ウェブサービス)などのサービスで簡単にサーバ構築ができるようになったため、AWSでどのようなサーバを構築するべきか、などを検討し、実際に構築できる人が求められている傾向があります。

その他のエンジニア

Webエンジニアやインフラエンジニアの説明でも記載したようにシステムエンジニアのスキルをどこかの領域に特化したエンジニアはたくさんあります。

そのため、本記事でまとめきることが難しいのですが、最近ではAI、データ分析、マーケティングなどに特化したエンジニアの需要も高まっています。

このあたりの分野は技術進歩に伴い新しく出てきたエンジニアです。

今後も新技術を活かしたエンジニアの需要が高まることは予想がつきますので、自分がどのようなエンジニアを目指すのか、については、自分のやりたいことを主軸に考えることをおすすめします。

エンジニアの年収・給料は高い？

エンジニアの年収は高いのか？低いのか？という疑問があると思います。

結論から先に言うと、エンジニアの平均年収は日本人の平均年収よりも高いです。

実際に大手IT企業勤務の僕の年収を公開した記事（エンジニアの年収は低い？【現役SEが年収を公開】）があるので、気になる人は読んで頂けると嬉しいです。

エンジニアの働き方

「エンジニアの働き方・労働時間はどんな感じなのか？」と聞かれたら、正直なところ「部署や職種による」という回答になります。

お客さんの無茶ぶりに対応しなければいけないエンジニアはブラックと言われる傾向が高いです。

このように、お客さん、プロジェクトリーダー次第では残業の量が多くなる場合もあります。

その一方で、技術知識に詳しいお客さんやプロジェクトリーダーが有能な場合はある程度、残業をコントロールできます。

社内システムの開発を専門にしている場合などは、このパターンに当てはまりますので、結論「部署や職種による」となります。

実際に僕のエンジニアとしてブラックだった時期、ホワイトだった時期についての体験談を書いた記事（エンジニアはブラック？【現役SEが実態を告白】）も興味があれば読んでもらえると嬉しいです。

エンジニアの適正

どのような人がエンジニアという職種に適正があるのか？について、お話します。

結論から言うと以下に当てはまる人は適正が高いと思います。

※あくまで僕の意見です。

以上のような要素のいずれかに当てはまる人は適正が高いと思います。

ちなみに僕は新卒入社した時点では「コミュニケーションスキル」が圧倒的に低かったです。正直な話、相手の気持ちを考えることが苦手でした。

それでも今の仕事を続けていくことで、「この発言をしたら相手がどう思うか？」を考える癖がついて、苦手を克服できました。

現時点でエンジニアに適正があるかどうかの確認はもちろん重要ですが、エンジニアの仕事が好きかどうか？が一番のポイントだと思います。

なお、エンジニアは理系の方が向いている、文系は向いていないのような話を聞いたり、相談されますが、学歴は全く関係ありません。

確かに理系の方がエンジニアの適正が高い人が多い傾向はありますが、文系出身でもすごいエンジニアはたくさんいます。

実際にプログラミングをバリバリできる僕の上司が、実は文系出身でした。という体験談（文系でもエンジニアになれるのか？【後悔しない選択をしよう】）もあります。

自分がやりたいかどうか？がポイントなので、やりたいなら適正あり、やりたくないなら適正なし、と考えた方がよいです。

エンジニアのなり方

エンジニアになるにはどうしたらよいのか？についてですが、まずどんなエンジニアになりたいのか？を整理する必要があります。

本記事でも説明した通り、仕事の内容によって様々なエンジニアが必要になります。

そのため、自分がどんな仕事がしたいのか？を整理して、だから○○エンジニアになりたい！というのを決めましょう。

どんなエンジニアになりたいか整理する

どのようなエンジニアになりたいかについては、以下のようなポイントを整理すると見えてくると思います。

やりたいことがまとまらないなら、就職・転職エージェントに相談するのもありだと思います。

エンジニアとして就職・転職する

なりたいエンジニア像が定まったら、就職・転職によってエンジニアを目指すことができると思います。

就職・転職のエージェントに相談することで、あなたに適した企業をおすすめしてもらうことができます。

「フリーランスになりたい」という人もエンジニアで就職してから独立する流れの方がリスクが低くいため、まずは企業に勤めることが個人的にはおすすめです。

今の職業からエンジニアで独立したいという方は副業で実績を積んでからフリーランスになることをおすすめします。

副業でエンジニアになる

現職をすぐに辞める気はないけど、収入をアップさせたい。という方はエンジニアを副業として実施することで月収をアップさせることがおすすめです。

ランサーズやクラウドワークスなどクラウドソーシングには副業で対応可能なレベルの案件がいくつかあります。（在宅で可能な案件も多いです。）

最初は単金が安かったり、時間がかかったりするとは思いますが、納期を守り、しっかりと品質を担保することで実績を積むことができます。

実績を積むことでお客さんの中での評判が良くなり、高単価の仕事を依頼されることも多くなります。（必然的に時給が高くなります）

これは、個人で努力するほど収入が上がるので、やりがいがあると思います。

とはいえ、スムーズに副業を開始して実績を積み重ねることは容易ではありませんので、相応の努力が必要であることはご理解いただきたいです。

エンジニアになるためにプログラミングスキルを習得する

僕は、転職や副業でエンジニアになるために、事前にプログラミングスキルを習得しておくことをおすすめします。

理由としては大きく以下2つです。

僕の場合は、学生の頃にプログラミングを学ぶ機会があり、システム開発のイメージがなんとなくできていたので、就職してからエンジニアになったことを後悔したことはありませんでした。

その一方で、就職してから「こんなはずじゃなかった」と言って転職した同期が一定数いたので、あなたには後悔しない選択をしてほしいと思います。

まとめ

本記事は以上です！！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

炎上プロジェクトはツライって聞くけど、どう対処すればよい？

本記事では、こんな悩みを解決します。

ぐり主任

炎上プロジェクトとは何か？どのように対処するべきか？

というテーマで話したいと思います。

私は数年前、何度か炎上プロジェクトに携わったことがあり、毎日終電、休日出勤、月の残業100時間超などを過去に経験したことがあります。

最近は働き方改革、不払い残業の撲滅など、法令遵守の徹底がなされ、炎上プロジェクトでも労働者を守る動きが増えていますが、炎上プロジェクトは会社の中でも散見されます。

そこで、私の経験内容も踏まえて、炎上プロジェクトとは何か？炎上プロジェクトに参加してしまったとき、どのように対処するべきか？について説明します。

炎上プロジェクトとは何か？

炎上プロジェクトとは「当初計画を実施できないにもかかわらず、適切な対策が実施できていないプロジェクト」です。

これは計画通りに上手くいかないのに、無理やりプロジェクトを推進するため、以下のような事象が発生します。

これら以外にも様々な問題が多発しますが、一言で「問題だらけの超やばいプロジェクト」とも言えます。

炎上プロジェクトはどのくらいやばいのか？（具体例）

「超やばい」だけではイメージできないと思いますので、具体例を説明します。

例えば、「5人で6ヶ月の期間で実施する計画のプロジェクト」があったとします。

しかし、8人で6ヶ月の作業量が必要であることが後から分かりました。

この時点で、5人から8人へ作業者を増やさなければならないのですが、対策が実施されない場合、炎上プロジェクトになる可能性が高いです。

このように炎上プロジェクトとは、問題が発生しても対策ができていないため、長時間労働などが多発してしまいます。

繰り返しになりますが、とにかくヤバい状態です。

炎上プロジェクトが起きる原因

私は炎上プロジェクトが発生する最大の原因はプロジェクトマネージャーの能力だと考えています。

なぜならば、プロジェクトが炎上する要素は以下のようなものがありますが、これらはプロジェクトマネージャー（PM）がコントロールするべき要素だからです。

※企業によっては、プロジェクト責任者（PMの上司）の責任となります。

プロジェクトマネージャーが問題を早期発見・解決できない場合、炎上プロジェクトになりがちです。

逆にプロジェクトマネージャーが優秀な場合、問題が発生してもプロジェクトを軌道修正できるため、炎上プロジェクトにはならない傾向があります。

炎上プロジェクトに参加するメリットとデメリット【体験談】

僕は実際に１～２年目のときに炎上プロジェクトを体験したことがあります。

今振り返ってみると、炎上プロジェクトはすごくつらいものでしたが、その分成長のチャンスもありました。

そこで、炎上プロジェクトに参加するメリットとデメリットをお話します。

炎上プロジェクトに参加するメリット

僕が炎上プロジェクトに参加して感じたメリットは以下です。

炎上プロジェクトに参加するデメリット

僕が炎上プロジェクトに参加して感じたデメリットは以下です。

以上が、僕が炎上プロジェクトに参加して感じたメリット・デメリットです。

正直な感想としては「振り返ると、すごく成長することができて良い経験だったが、もうやりたくない。」といった感じです。

炎上プロジェクトは身体・精神を壊される前に逃げるべき！

僕の経験から炎上プロジェクトのメリット・デメリットをお話しましたが、メリットよりもデメリットの方が大きいと感じる人も多いと思います。

特に炎上プロジェクトに参加している人で責任感が強い人はメリット・デメリットなど関係なく、プロジェクトを上手くやらなければならない！と病んでしまうこともしばしばあります。

実際に僕の参加していた炎上プロジェクトでも5～10名の人が離任されていました。

このようなことを踏まえると、僕は「炎上プロジェクトに参加して、つらいと思ったら逃げるべき！」だと思います。

なぜなら自分の人生よりも優先するべきことはないからです。

せっかく仕事ができるようになって出世しても身体を壊してしまって、一生病気で悩み続けることになってしまうのは本末転倒だと思います。

賛否両論あるかもしれませんが、私は豊かな人生を送るためにお金を稼いでいる（仕事をしている）と考えています。

※仕事が好きな人も身体を壊すと仕事ができなくなってしまいます

そこで、僕が考える炎上プロジェクトから逃げる方法について紹介します。

詳しく説明していきます。

上司と相談する

これはシンプルな手段になります。

ただし、「つらいです。辞めたいです。」と言ったところで、「何がつらいんだ？もっと頑張ってみないか？」と言われるケースもあります。

上司を説得するためのコツとしては以下のポイントを抑えることが良いです。

大抵の上司はあなたがいきなりプロジェクトを抜けられると困るため、代替案を相談してくると思います。

あなた：プロジェクトマネージャーがダメダメだから炎上してつらい、やめたい

上司：イケてるプロジェクトマネージャーに変えるから続けてくれ

このような代替案が魅力的ならば、もう少し続けてみるのも手だと思います。

しかし、期待する回答が得られないならば「転職も考えている」という発言をしてもよいと思います。

本気でつらいことを伝えて、それでもダメなら下の対策を実施しましょう。

産業医を経由して上司を説得する／休職する

会社が抱えている産業医に相談する方法や休職する方法があります。

産業医と面談を行う

産業医には会社の人事部などからアポイントを取ることができると思います。

産業医面談を行って、実際に長時間労働・精神的な苦痛について診断してもらえれば、上司も動かざるを得ない状況となります。

また産業医面談で短時間労働の診断が出た場合、残業は禁止になります。

炎上プロジェクトでの長時間労働や上司に対する強硬手段として実施することはできると思います。

休職する

産業医に限らず、医師の診断を受けた上で休職することはできます。

診断書を受領した上で、上司に対し「しばらく休ませてください」と伝えることでプロジェクトを休むことができます。

また、復帰した後、別のプロジェクトに配置される可能性も高いです。

医者の診断に苦手意識がある人は次の対策を見てください。

組合を経由してプロジェクトを離任する

日本の法律では従業員数が10人以上の企業は労働組合を創設する義務があります。

※なければ法律違反

そのため、大抵の方は労働組合に対するアポイントを取ることができるはずです。

労働組合は社員の健康を守るための組織です。

あなたが炎上プロジェクトで仕事をすることが身体的・精神的につらいのであれば、会社にはそれを是正する義務があります。

この義務を行使してもらうために組合へ連絡を取り、自分の身を守ってもらうことができます。

組合を利用するのもなんだか、、という方は次の対策を見てください。

社内の異動制度を利用する

炎上プロジェクトから脱出する手っ取り早い方法は所属部署を辞めることです。

これは勤めている企業によるのですが、私の会社には社内の異動制度というものがあります。

※ない方は申し訳ないのですが、次の最終手段を検討してください。

私の会社では半期に１回、各部署が社内に人材募集をかけるため、そちらに応募して面談を行うというものです。

こちらの面談に合格した人は、数か月後にめでたく別の部署へ異動することができます。（異動前の部署は止めることができない）

このように部署を異動することで、炎上プロジェクトから逃げることができます。

ただし、募集から異動するまでに即時性がないため、つらい時にすぐに実行する手段としてはおすすめできません。

ここまでくると最終手段について検討いただきたいです。

転職／独立する

これはあなたがツライときに最初に思いつく対策かもしれません。

実際に僕の同期も会社がつらくて転職していった人が数多くいます。

※あまり後悔している人はいませんでした。

終身雇用制と呼ばれていた昔と違い、同じ会社で出世することが全てだった時代から変化しています。

今の時代は市場価値を高め、どの企業でもやっていける実力をつけることが重要になります。

そのため、炎上プロジェクトを経験した上で、自分は何がやりたいのか？どうなりたいのか？を改めて整理した上で転職／独立することはありだと思います。

まとめ

本記事のまとめは以下となります。

【エンジニアのスキルアップ】Udemyのお得なクーポン

最後に、少しだけ宣伝です。

私はUdemyでエンジニアとしてスキルアップするための講師をしています。

以下のページにお得なクーポンページを設置しているので、ご興味がある方は覗いてみてください。

Udemyでエンジニアのスキルアップ！【お得なクーポン】

本記事は以上です！！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

IT業界に興味がある！手始めに資格を取りたいけど、どんな資格があるか分からない。

本記事では、こんな疑問を解決します。

ぐり主任

初心者がIT業界で働くために資格取得は必須なのか？

というテーマで話したいと思います。

まず最初に結論を言ってしまうと、資格は必須ではありませんが、あった方が良いです。

実際に私の職場にも仕事ができるが資格を保有していない人もいるため、資格の取得は必須ではありません。

しかし、必須ではないものの資格を保有することで就職や転職で有利になるケースが多いです。

そこで、僕の体験談を踏まえて、資格取得のメリットとおすすめの資格についてご説明します。

初心者が資格を取得するメリット

僕は、IT業界の初心者が資格を取得する3つあると考えています。

①IT業界の知識を網羅的に習得できる

資格を取得を目標とする事で、IT業界に必要な知識を体系立てて学ぶことができます。

普段の仕事では、その時に必要な知識のみを調べれば良いため、知識のつまみ食いとなってしまう事が多いです。

そのため、スーパーエンジニアも自分の得意分野ではない領域については、超基本的な内容ですら知らない。という事があります。

実際にjavaのスペシャリストの人でもネットワークの基礎知識を知らない人は山ほどいます。

このような事例はよくあることで、エンジニアの知識は専門分野に対し、特化して深くなりがちです。

その点、資格を取得するためには、知識を網羅的に勉強する必要があるため、知識の偏りなどが少なくて初心者の勉強に役立ちます。

②自分の得意・興味の分野が分かる

資格取得のための勉強をしていく過程で、IT業界でも特に興味がある分野、適性があるのかを見極める事ができます。

正直、ITというのは自分で触ってみてこそ面白い事がたくさんあるため、座学のみで適正を測ることを難しいです。

しかし、全然興味がないのかどうか？については資格取得の勉強の過程でわかると思います。

資格の勉強をしていく過程で、自分はプログラミングが好きなのか？ITを使ったマーケティングが好きなのか？の自己分析ができます。

③就職・転職で有利

資格を保有する事で、スキル・知識を保有する証明ができます。

これだけでも転職や就職に有利になる部分はありますが、取得までのプロセスがアピールポイントになります。

「資格を取得するために苦労した事」、「スキルが上達した事」などの努力した過程を実績として、採用担当者にアピールできます。

資格を取得した事で自分に自信を持つ事もできますし、就職や転職のために資格を取得する事は有意義であると思います。

IT業界の資格の種類と未経験・初心者へのおすすめ

IT業界の資格は大きく以下の２つに分類されます。

未経験・初心者は何の資格を取得するべきか？

初心者向けに僕がおすすめする資格は国家試験の「ITパスポート」、もしくは「基本情報処理」のいずれかです。

理由は、どちらの資格もIT業界の知識を体系的に浅く広く学ぶことができるからです。

資格を取得するメリットでお話したように、初心者は「ITとはどんなものか？」を理解し、習得するところがスタートとなります。

ITパスポート

「ITパスポート」はエンジニアならば知っていて当然の知識が問われる試験で、合格率は平均50%ほどです。

就職・転職に関してはそこまで資格の優位性はありませんが、「ITに関して全くの初心者」という方の入門としてはちょうどよい資格だと思います。

転職にあまり有利には働かないものの、IT業界を目指すなら知っておくべき内容が勉強できます。

基本情報処理技術者試験

「基本情報」は「ITパスポート」のワンランク上の試験で、合格率は平均23％ほどです。

ITエンジニアとして保有するべきスタートラインと呼ばれるような資格になります。

新卒・第二新卒・未経験者がこの資格を持っていれば、ITに関してポテンシャルがあるといったところでしょうか。

実際に僕の勤めている会社では、入社1～2年目で「基本情報」を取得することが推奨されています。

資格取得時の注意点

資格を取得を目指す時の注意点は資格を取得する事だけを目的にするのか？それとも知識の習得を目的にするのか？です。

一刻も早く転職がしたい人、資格が欲しい人以外は知識の習得を主軸にした方が良いと思います。

これはTOEICなどの試験にも共通して言えるのですが、「TOEICで点数を取るための勉強」と「英語力の向上」を目的とした勉強は厳密には異なります。

注意したいのは、資格を取得したとしても知識を全て習得しているとは限らないという事です。

資格は合格点を達成すれば取得することができます。

そのため、資格保有者は資格を持つ実力を示せますが、「資格保有＝仕事ができる」ではありません。

資格を取った事で、仕事を貰えたりするなど、チャンスを引き寄せることはできるので、そのチャンスを活かせるかは自分次第です。

つまり、資格を取得した後、チャンスを活かせるか、方が重要だと思います。

資格を取得してよかったこと＜体験談＞

僕は20代前半の時期にスキルアップを兼ねて資格取得のための勉強をしていました。

今振り返るとあの時に資格をとってよかったと思うことがいくつかあります。

このように資格を取得することは、仕事でもプラスに働くことが多いです。

未経験者・初心者の方でIT業界に興味がある、キャリアを積みたいと考えている方は、是非、資格の取得を頑張ってみてください。

以上！！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.

悩む人

悩む人

ブラックって具体的にどのくらいブラックなの？

本記事では、こんな悩みを解決します。

ぐり主任

エンジニアはブラックなのか？というテーマで話したいと思います。

まず最初に結論を言ってしまうと、エンジニアは労働時間がブラックになりがちです！

実際に現役SEの僕も残業が月80時間を超えることがしばしばあります。

そうは言っても、同じ会社に残業が月10時間未満の人がいるので、SEの全員が全員ブラックという訳ではありません。

そこで、私の経験内容も踏まえて、SEがなぜブラックと言われるのか？具体的に何がブラックなのか？について解説します。

エンジニアがブラックと言われる理由

まず、あなたはどんな仕事がブラックだと思いますか？

一般的に「ブラックな仕事」と聞いて、以下のキーワードを思いつくと思います。

このキーワードのうち、エンジニアがブラックと言われる理由は「仕事量が多く、労働時間が長い」ことが理由です。特にユーザ向けのSEは労働時間が長く、残業が多いことからブラックと言われる傾向があります。

また平日の残業でも仕事が終わらず、休日出勤・サービス残業を行うことになってしまうケースもしばしばみられる業界です。

そのため、エンジニアはブラックだ！やめとけ！と言われています。

エンジニアはどのくらいブラックなのか？

具体的にどのくらいブラックなのか？ホワイトな要素はあるのか？について、僕の体験談を基にご説明します。

僕が一番ブラックだったときの生活

社会人生活で最もブラックだった時は、社会人二年目で炎上プロジェクトに所属していたときです。

基本的に平日は仕事のみで、寝るために家に帰るような生活でした。

休日は完全週休2日制だけど、月に1～2回の出社、出勤しなくても1日中休んでいたら夜になっていました。

何より、辛かったこととしては、ゴールの見えないマラソンを全力で走り続けなければいけない。ということです。

これは精神的につらいもので、周囲のメンバーでもメンタルをやられてしまう方が少なからず出ていました。

ちなみに当時の生活は以下のような感じです。

僕の場合は、炎上プロジェクトが会社的に大きな問題となり、優秀な人材がヘルプで大量に追加。

結果的に苦しい生活は1～2年で済みました。

あの生活が一生続くとなったら間違いなく転職していた気がします。

休日のお休みがあった分、もっと働いているブラックな人がいるかもしれませんが、当時の僕のレベルでも適正な労働時間を大きく超えていることから働きすぎであったと思います。

僕が一番ホワイトだったときの生活

こんな僕ですが、実はホワイトな時期も経験しています。

これはシステム開発の案件が無事完了し、保守・運用をしながら次の提案活動を行う時期でした。

システムの問題はほとんど発生しなかったため残業時間も月に10～20時間くらいで、さらに月に1～2日は提案活動に向けた研修に参加することもできました。

生活にゆとりがあったので、この時期に資格の取得や自己研鑽が捗った記憶があります。

ちなみに当時の生活は以下のような感じです。

ブラック企業との付き合い方【働き方改革で改善傾向】

僕の実体験は、同じ会社、同じ部署の話なので、ブラックかどうかの最大の違いは「炎上プロジェクトだったかどうか」です。

炎上プロジェクトになるかどうかは、プロジェクトの責任者、担当者が有能かどうか？などによって大きく変わるため、自分の力だけで炎上プロジェクトを回避することは難しいです。

実際に世の中には規模はともかく炎上プロジェクトが数多くあります。

そのため、多くのエンジニアは残業することを強いられることになります。

その時に、自分がどのように対応するべきか、自分をどう守るか、が重要となります。

ブラックな仕事から自分を守る方法

実際に僕がブラックな勤務を強いられていた時に、以下の考え方を持つことで、精神的にやられてしまうことを回避できました。

①今の自分の仕事で自分がレベルアップしている実感があった。

炎上プロジェクトに入っていた時、僕は若手でしたが、業務の内容は先輩社員の仕事を無茶ぶりされていました。

先輩がやるはずだったタスクを先輩も忙しく、できる人がいないため誰かがやらなきゃいけない状況でした。

若手の自分が4～5年先輩の仕事をやることは全く経験がないため、失敗したり、時間がかかったり、とても苦労しました。

その代わり、単純な社会人としての経験値は2倍以上のスピードで得ることができました。

一か月前できなかったことが、今ならできる！という状態が毎月繰り返されていたので、自己成長を大きく感じることができていました。

これは労働時間が長すぎてツライこともあったけど頑張れた一番の理由だと思います。

②残業代をそこそこ貰えていた

これは単純な理由で、働いた分だけ残業代をもらえていたので、給料が高かったです。

僕が大手IT企業に勤めていたということもありますが、残業時間が増えることで若手にしては結構な額をもらっていました。

金額でいうと、残業代は1時間2000円くらいで、80時間働くと額面で16万増える感じでした。

若手なのに額面で30～40万くらいはもらえていました。

当時の自分としては、労働の対価としては十分な額をもらえていると思っていたので、お金に関してのストレスはありませんでした。

その一方で、残業代が全てサービス残業扱いになっていたとしたら不満になっていたと思うので、やはり会社自体の規模などは重要かなと思います。

③人間関係が良好だった

労働時間がブラックであったものの僕がいた職場の人間関係は良好でした。

チーム全員が終電で帰宅することもざらにありましたが、「今日も終電までお疲れさまでした！」のように挨拶して帰る。そんな生活が嫌いではありませんでした笑

職場環境によっては上司からいじめられたり、顧客から無理を言われたりする。など様々なストレスによってメンタルがやられてしまうケースがありますが、僕の職場では人間関係が良好であったため、みんなで頑張っている！という感じでした。

逆に仲間がいない状態で長時間労働をするとなると、かなりメンタルにくるので、耐えられなかった可能性があります。

これに関しては配属された部署、担当する案件などに依存する部分が大きく、かなりの運ゲー感が否めないため、エンジニア＝ブラックとはいえませんが、注意が必要な要素ではあります。

④つらくなったらやめてもよいと思っていた

正直な話、身体を壊したり、メンタルがやられるくらいなら会社を辞めてもよいと思っていました。

大手IT企業に勤め続けるメリットよりも、身体やメンタルを壊して人生ぶち壊しになるデメリットの方が明らかに大きいからです。

人生で何のために働くのか？を考えたときに、「今の仕事が好きだから」と答えられるならたくさん働くこと自体は良いと思います。

しかし、身体を壊してしまうほど仕事をやりすぎるのは優先順位を間違えているのではないかと考えています

健康に人生を生きていく、その上で仕事だったりプライベートが成り立つ。

これが原則なので、若手だろうが何だろうが身体やメンタルが壊れそうなら会社を辞めようと思っていました。

今思うと、この考え方のおかげで会社を辞めずに炎上プロジェクトを乗り越えた、というのは笑い話かもしれません。

働き方改革による影響

近年は働き方改革の推進により、多くの企業が残業時間、総労働時間、不払い残業の撲滅などに注力しています。

その影響は大きく、私の会社でも残業時間が多い場合は問題提起されるようになり、労働時間が長い社員がいた場合、上司も責任を問われる時代になってきました。

そのため、会社全体として、労働時間をチェックし、是正しようという動きがあります。

世の中的には労働時間に関してホワイトにしよう、という大きな動きがみられます。

中小企業についても、大手の動きに追従する形になるので、段々と改善されつつあると思います。

まとめ

今回はエンジニアという職種がブラックなのか？について、僕の体験談も含めてお伝えしました。

以上！！

Copyright © 2026 ぐり主任の研究ブログ All Rights Reserved.