先日、友人のWebアプリケーションエンジニアとIaC（Infrastructure as Code）について話す機会がありました。 話の発端は「Terraform と CDK、どっちを採用すべきか？」というよくあるテーマだったのですが、友人からこんな強烈な一言をもらいました。

「CDK一択でしょ。だってCDK（CloudFormation）はデプロイ失敗時に自動ロールバックしてくれるけど、Terraformは作りかけで止まるでしょ？怖くて使えないよ」

なるほど、確かにその視点はあります。DBのトランザクションに慣れ親しんだエンジニアからすれば、「失敗したらAtomicに元に戻る」挙動こそが正義でしょう。

しかし、普段Terraformを触っている身からすると「うーん、それは『ロールバック』の定義や運用思想が違うだけでは？」というモヤモヤが残りました。

今回は、この「IaCにおけるロールバックと復旧戦略」について、公式ドキュメント等の情報を交えながら整理してみたいと思います。

そもそも「ロールバック」とは何を指しているのか？

友人が言っていた「ロールバック」は、主に 「デプロイ（Apply）が途中でコケた時の挙動」 を指しています。

CDK の場合

CDKは、コンパイルされると最終的に AWS CloudFormation テンプレート になり、デプロイもCFnを通じて行われます。

• 挙動
  スタックの更新中にエラーが発生すると、CFnは 「自動的に直前の正常な状態に戻そう」 とします。
• ステータス
  UPDATE_ROLLBACK_IN_PROGRESS → UPDATE_ROLLBACK_COMPLETE

これはCloudFormationの基本機能として提供されています。
スタックの更新のロールバック – AWS CloudFormation

メリット
何もしなくても「壊れた状態」で放置されることが少ないです。
「オール・オア・ナッシング」に近い挙動をするため、整合性が保たれやすい安心感があります。

デメリット
ロールバックには時間がかかります。
リソース作成に30分かかって失敗した場合、ロールバックにも同等の時間がかかることがあります。
また、ロールバック自体が失敗するUPDATE_ROLLBACK_FAILEDという状態に陥ると、手動での介入が必要になり、復旧難易度が跳ね上がります。
参考: 更新のロールバックに失敗したスタックを更新できるようにする – AWS CloudFormation

Terraform の場合

Terraformは、AWSのAPIを直接叩いてリソースを操作します。

• 挙動
  terraform apply 中にエラーが発生すると、その時点で処理が停止します。
• ステータス
  成功したリソースは作成済み、失敗したリソースは未作成（または中途半端）な状態で残ります。

Terraformには「自動ロールバック」という機能自体が存在しません。これはバグではなく仕様（思想）です。
HashiCorp Terraform: Command: apply

メリット
エラーの原因が明確で、「ここまでは成功した」という状態がStateファイルに保存されます。
コードを修正して再実行（terraform apply）すれば、差分のみを適用し直すため、復旧までの時間が圧倒的に短いです。

デメリット
「中途半端な状態」が一時的に発生するため、手動でのリカバリ（State操作やTaint）が必要になる場合があります。

なぜTerraformには自動ロールバックがないのか？

Terraform派の意見として、「自動ロールバックがないこと」は 「Fail Fast（早く失敗して早く直す）」 という設計思想に基づいています。

1. Stateの一貫性重視
   Terraformは「現在のインフラの状態」をtfstateファイルで厳密に管理します。
   勝手にロールバック（過去の状態に戻すAPIコール）を行うと、ローカルのコードと現実のリソースの乖離が複雑化するリスクがあります。 State – Terraform by HashiCorp
2. Roll Forward（前進による修復）の推奨
   インフラ変更において、失敗した場合は「元に戻す」よりも「修正して適用し直す」方が早いケースが多いです。
   Terraformは plan コマンドで事前に変更内容を詳細に確認できるため、実行時エラーは「権限不足」や「パラメータ不正」などが主であり、コードを直して再Applyすれば済むことがほとんどです。

ロールバックというバージョン切り戻し

友人の言う「デプロイ失敗時の自動復旧」ではなく、「正常にデプロイしたけどアプリが動かないから昨日の構成に戻したい」 という場合のロールバックはどうでしょうか。

• CDK (CloudFormation): Gitで以前のコードに戻し、再デプロイします。 ※ CFnの自動ロールバックはあくまで「デプロイエラー時」の挙動であり、論理的なバグまでは戻してくれません。
• Terraform: Gitで以前のコードに戻し、terraform apply します。

つまり、「正常デプロイ後の切り戻し（Revert）」に関しては、両者の手間に大きな差はありません。 どちらも「Gitを正」として、過去のコミットの状態へインフラを収束させる作業になります。

結論：どっちが良いのか？

友人の「CDKの方が優秀」という意見は、「デプロイ作業中の安全性」 に重きを置いた意見と言えます。特にアプリケーションエンジニアにとって、デプロイ失敗時に環境が散らかったままになるのは恐怖でしょう。

一方でTerraformは、「状態の透明性と制御」 に重きを置いています。「勝手に戻るより、どこで止まったか教えてくれ。俺が直すから」というスタンスです。

まとめ

• CDK (CloudFormation)
  • 特徴: 失敗時は自動で元通り（トランザクション的）。
  • 向いているケース
    インフラの詳細なステータス管理より、デプロイパイプラインの安定性を重視したい場合。ロールバック待ち時間が許容できる場合。
• Terraform
  • 特徴
    失敗時はそこでストップ（即時停止）。修正して再実行（ロールフォワード）。
  • 向いているケース
    terraform plan で事前に結果を予測し、失敗時も自分の手ですぐに復旧させたい場合。APIコールの速さを求める場合。

「ロールバックがあるからCDK」ではなく、「失敗時のリカバリ戦略として、自動復帰（CDK）と即時停止（Terraform）のどちらが自分たちのチームに合っているか」で選ぶのが正解ではないでしょうか。

私は……やっぱり terraform plan で「何が起きるか完全に把握してから実行する」安心感が好きですね（笑）

AIに頼めば、ものの数秒で大量のコードが生成されます。
まるで魔法のようですが、同時にこうも思うのです。「これ、本当に動くの？」「仕様、合ってる？」と。

大量に出力されるコードの波に飲まれず、「人間が手綱を握り続ける」ために僕が実践してきた開発のTipsを書き残しておきます。

これは、2026年の自分への手紙でもあります。
「あの頃はそんな苦労をしてたんだな」と笑って読み返せますように。

機会にできることは機械に任せる（Lint / Pre-commit / Auto Format）

AIは優秀ですが、たまにインデントを崩したり、変な書き癖を出してきたりします。
生成された大量のコードを目視でレビューして「ここ、スペース空いてないよ」なんて指摘するのは、人間のやる仕事じゃありませんよね。

だからこそ、Lint と Pre-commit、そして 自動フォーマット は必須でした。

• 保存＝整形（Auto Format）
  エディタで保存した瞬間に、コードが綺麗になる設定はマスト。AIが吐き出したコードを貼り付けた瞬間、プロジェクトの規約に合わせて「シュッ」と整う快感。これがないと精神衛生が保てません。
• コミット前の門番（Pre-commit）
  Gitにコミットする前に、Linterが自動で走るように設定しました。型エラーや未使用変数は、人間が気づく前に機械に弾いてもらう。

「コードの見た目」や「単純なミス」に脳のメモリを使わない。これがAI時代を生き抜く第一歩でした。（AI開発がどうっていう話ではないがより一層重要になっている

実装指示は細かくStepByStep形式

最終的なゴールを明示したうえで、StepByStepで実装させました。

ゴールは .documents にMarkdownを配置し、その仕様書通りになるように指示をします。

## As Is

## To Be 

## Task

## Remarks

1. 〇〇を最終ゴールとします。実装方針を出して。
2. ツッコミを入れる
   • Step1の実装のセキュリティホールは？
   • タイムアウトの条件は〇〇に
3. テスト書いてもらう
4. もちろんRed
5. テストのレビュー
   • テスト問題なければ実装
   • 問題あれば2を見直す
6. テストがGreenになるような実装

この辺はガイドラインやコーディング規約などを整備すればよかったのかなぁと考えている反省点です。

テスト戦略：AIに任せる部分、僕が譲らない部分

ここが一番のキモです。
AIはコードを書くのは早いですが、「僕たちが本当に作りたいもの」を100%理解しているわけではありません。
だからテストの役割分担をこう決めました。

単体テスト（ViteTest / PHPUnit）

関数単体や小さなロジックの検証には、ViteTestやPHPUnitを使いました。
ここはAIにも手伝ってもらいやすい領域です。「この関数のテスト書いて」と言えば、エッジケースまで網羅したテストを提案してくれます。

※ 単体テストをAIに書いてもらうために、関数は限りなく小さくするような単一責任の原則でAIに実装してもらっています。ぜーんぶAIです。

Featureテスト（結合・機能テスト）は「僕」が書く

けれど、機能全体が正しく動くかを確認するFeatureテストだけは、僕自身の手で書くようにしました。
これには明確な理由が2つあります。

1. コードの理解：
   AIが書いたブラックボックスなコードも、テストを書く過程で読み解く必要があります。「どう動くべきか」を定義するのは人間です。
2. 要求仕様の達成：
   求められている「要件」を満たしているか判定できるのは、今のところまだ人間だけです。

「AIにコードを書かせるなら、人間はテスト（仕様）を書け」 これが2025年の僕の合言葉でした。
テストが通る＝仕様を満たしているという安心感があって初めて、AIのスピードを享受できるんです。

2026年の僕へ

どうですか？ 2026年の開発現場は。

AIが仕様の矛盾すら指摘して、テストまで完ぺきに書いてくれるようになっているのでしょうか。

もしそうなっていたとしても、2025年の僕は「正しく動くものを届けたい」という一心で、Linterを設定し、Featureテストを書いていたことを覚えていてください。

エンジニアとしての仕事に楽しさは残っていますか？2025年末では、だんだんと辛くなってきています。

それじゃ、また。良い開発ライフを！

炎上案件とは？

何らかの理由でとにかく燃えている案件のことです。

• シンプルな短納期（多分炎上の理由1位）
•  チーム内における重要人物のプロジェクトからの離脱
• 神様（クソ客）による土壇場での仕様変更
• イキり営業による全てできますスタイルによる契約

プロジェクトに関わるすべての人が何かしらに追われている状況になるため、関係者各位で揉め事が起こっています。
ステークホルダー > 営業 > PL > SE > プログラマー

僕が経験した炎上案件では、短納期 + 急な仕様変更（馬鹿な営業のせい） により開発と営業の間で戦争が勃発しプロジェクトが崩壊しかけた事があります。
最終的には客先への調整（謝罪） + 営業と開発の戦争に部長が仲裁する形 で終着することでギリギリのところで丸く収まりました。

しかし一度崩壊しかけたプロジェクトなのでチーム内でのいざこざは残ったまま開発を続けていくことになりストレスの掛かるプロジェクトでした。

このように炎上案件は誰も幸せになりません。

今回は炎上案件について僕の実体験を簡潔にお話したのですが、一口に炎上案件と言っても様々な理由があることを覚えていただければ幸いです。

炎上するとどんな事が起きるのか

お客さんに詰められる

受託企業における一番恐ろしいタイミングがお客様から詰められる時です。
当たり前の話ですが、身銭を切ってシステム開発を依頼されているので、全力で詰めてきます。

お客さんが詰めるときはだいたい以下の理由かと思います。

• 納期に間に合わない
• 契約時に想定していた要件を満たせていない

これらの理由で怒られるのが本当に本当にストレスでした。(契約不履行と言われたときにはゾッとします。

上長から詰められる

お客様から詰められるということは必然的に上司からも詰められます。

お客さんからの評価が悪いと次回の契約や会社の評判が下がるといった悪影響が発生する可能性が高くなるため、上司もピリピリします。

炎上は炎上を生むだけです。

メンバーから不満が出る

他方から詰められるとチーム内からも悲惨な声が聞こえてきます。

「後少しでリリースできるから一緒に頑張りましょう。」という声がけしかできません。

世知辛いです。

炎上したときには死ににいく姿勢が大事

ようやく本題です。

炎上案件に参画すると全員が「この案件から抜け出したい」と願っている事は目に見えるのですが、そういった願いは儚く散っていきます。どうにか納品することが唯一の地獄からの脱出する道です。

全員がギリギリのところで踏ん張っているタイミングでは率先して死にに行く姿勢がメンバーを勇気づけると考えています。

一度プロジェクトを崩壊させた目線から思うことが誰かがアクセルを踏んで頑張ることが誰かの活力につながることを強くお伝えしたいです。

今炎上案件に参画している人はぜひ、死にに行く姿勢を持ってほしいなと思います。（限界だったら逃げてください。本当に逃げてください。）

炎上案件は悪いことばかりではない

精神的にしんどい事が多い炎上案件ですが、悪いことばかりではありません。

サイヤ人の理論と一緒でギリギリのところで生き抜くと確実に成長します。成長するのは技術力かもしれませんし、人間力かもしれません。

とにかくあなたの何かが確実に成長します。

また、炎上案件の凄いところが普通に過ごした期間と炎上案件に関わった期間の成長の度合いに大きな差があります。

それだけ炎上案件には人を成長させるパワーがあります。

一度経験しておくのをオススメしますよ。

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”0″]

事の発端

副業案件を獲得するためにいくつかの面談を受けている際に面接官に言われた一言です。

いやぁ〜、恐ろしい。

要件次第で色が違ってくるのがシステム開発というもののハズですが、仕事という観点で見た際にPHPで作るシステムは簡単に作れるという考えを持っている人がいました。

なぜ、こうもPHPの立ち位置が低いのか僕なりに考えてみました。

（そもそも「PHPで作ればシステム開発は楽になる」という考え方事態がおかしいのですが。。

PHPが舐められている原因

駆け出しが増えすぎた

PHPの業界内の立ち位置として駆け出しエンジニアが選択するファースト言語という特色があります。
（かくいう僕も初めて選択した言語はPHPでした）

駆け出しエンジニアに選択されやすいという特色が故、ロースキルのプログラマが大量生産され、業界内での評価がガタ落ちしたのではないでしょうか。

また、2020年〜2023年の間にインフルエンサー達によるフリーランスの布教活動の波も影響していると思います。

仕事を発注する側から見た場合、経験年数が短く、「PHPできます」という人に対して不信感を抱くのも当然かもしれません。

自由にかけてしまう

PHPの特性について、コードの型を指定せずに書くことができる柔軟性があります。

これは素早くコードを記述できる利点を持つ反面、実行時にエラーが発生する可能性が高まります。
この特性は、プログラムを実行するまでエラーが検知されないため、デバッグや修正が手間取ることがあります。

この柔軟性から「動くものは簡単に作れる」というイメージが生まれ、結果として経験豊富な開発者からはPHPが好まれない傾向にあります。
一部のエンジニアは、この柔軟性が多くのインシデントやバグを引き起こす原因と見なしていることもあります。（僕の上司もPHPの言語仕様が嫌いです。笑）

特にセキュリティや安定性が求められる場面では、この特性がリスクとなることがあります。

過去にインシデントが多数報告

実際にPHPコードの柔軟性が原因でセキュリティ上の問題や重大なエラーが発生した事例が多く報告されています。

CVEデータベースを見てみてください。PHPの報告が多数上がっていますよ。

PHPに限らずインシデントの内容をチェックすると勉強にもなるので一度見に行ってみるのをオススメします〜

じゃあPHPerはどうするの？

正しいPHPを学ぶ

PHPの最新の機能や改善点を把握し、セキュアで効率的なコーディングを心掛ける必要があります。（エンジニアなら当たり前だろ！ってマサカリ飛んできそうですが笑）

かくいう僕もPHP8でリリースされたmatch式を知らなかった過去があります。しっかり学びましょう笑

また、静的型付け言語ほど厳格な型指定はできないのですが、PHPの型システムを利用したセキュアコーディングやジェネレータを使用してメモリの過消費を防ぐコーディングを意識する必要があります。

PHP以外にもスキル身に付ける

新卒が優秀になってきていることやChatGPTの登場など、PHPだけができる人は本当に不要になってきているのを肌で感じます。

そのため、以下のどちらかに裾のを広げていく必要があると思います。

• PHP + フロント(React or Vue + TS)
• PHP + インフラ

僕はフロントがあまり得意ではないのでインフラ周りを勉強中です。

fa-adnPHP以外を身につけると

PHP以外を身につけると明らかに単価がアップします。
例えば、PHP + AWS のような案件や PHP + React + TypeScript の案件に携われる可能性が出てきます。
PHPの枠を出ることによって確実に世界が広がるのでおすすめです。

PHPは素晴らしい言語だぞ

近年のPHPは、安全性や効率性の向上に焦点を当てて進化しています。

例えば、PHP 8や8.1のリリースでは、型付きプロパティや名前付き引数など、新機能が追加されました。
PHP8.2ではreadonly classがリリースされています。
これにより、コードの品質向上やエラーハンドリングの改善が実現しました。

そして何よりもPHPは数多くのシステム開発の実績を持っています。
2023年においてちらほら「PHPはレガシーだ」という意見が出てきていますが、今も現役に稼働しているシステムが多数あります。

過去の先輩PHPer 達が遺してくれた数多くの仕事がまだまだ残っています。そしてこれからもまだまだ増えていくでしょう。

何かと批判されがちなPHPですが、世の中に価値を届けることができる可能性に満ちた言語です。

正しい知識と幅広い知識を持ち合わせたPHPerになっていきましょう〜

エンジニア歴は短いのですが、これまでに以下の形態の会社で働いてきました。

• SES
• 受託
• 自社

そんな僕からエンジニアとして働くべき会社を解説します。笑

SES 時代

入社した経緯

まずは SES 時代です。

当時の僕は異業種からの IT 業界への転職を目指していたこともあり、IT 業界に対する知識が全くない状態でした。

そのため手当たり次第に面接を受けまくっていた記憶があります。（今考えるとかなりアホですね。笑）

当時の世界情勢的にはコロナが大流行していた時期ということもあり、求人数はかなり狭めらていた状況でした。
そのような中、転職活動を進めていくにあたり戦略として以下の対策を講じました。

• 自作のウェブアプリケーションを作る
• 資格を取得する
• 技術記事を書く

[getpost id=”606″ cat_name=”1″ date=”0″][getpost id=”590″ cat_name=”1″ date=”0″]

転職活動という大航海を戦うには心細い能力値の低い武器を揃えて旅に出ていたため、条件の悪い求人にしか出会うことが出来ませんでした。

そんな中、あるSES会社と出会い入社をしました。

• 僕の揃えた武器に対して「君は努力のできる人だと思う」と評価
• 先輩のアセットとしてシステム開発の現場に入れてもらえる

中々良い出会いが無い未経験からの転職活動だったので、このSES会社に出会えた事はとても嬉しかったです。

業務内容

本当に末端の作業員だという内容の業務をこなしました。（未経験で入社したのでそれは仕方がない）

具体的には以下のような内容です。

• テスト仕様書に沿ってテストを実施する
  • エビデンスをスクショし、 Excel に貼り付ける
• HTML で書かれているページを Excel におこす
  • 現在の画面を仕様書に残すため
  • Git 使えや。クソが。
• データ移行（DB移行）
  • これは勉強になった

良かったこと

未経験からの IT業界への初参入ということだったので、全てが学びになったという自負があります。

質問の仕方や会話の仕方など他の業界とは異なっている事を知れたのはエンジニアとしての学びでした（特に質問の仕方は何度もご指導いただきました。笑）

また、システム開発の概要を知れたのはかなり大きかったです。
多くの人がそれぞれの役割をこなし、納期や予算と戦いながらゴールに向かった進んでいく姿勢はプログラムを書くだけが仕事ではないという事を学ぶことが出来ました。

その他にも何かしらの病気を抱えている率が高いこと(生活習慣病、精神疾患)や小汚いおじさんに見える人が実はかなり稼いでいる事など業界 の知見が増えたのは人生の経験という観点からもすごく勉強になりました。

悪かったこと

悪いことを上げればキリがないのですが、特に印象深かったものを紹介します。

1. 先輩社員に意識を高く持っている人がいない（自社の先輩）
2. 商流が深すぎて末端の作業
3. 三次受けだが二次受けとして入場

特に1番の意識の高い人がいなかったという事は エンジニアとして終わっている と思います。

当時の僕もそうですが、経験のない人はその現場が IT業界 の全てだと思ってしまいます。

そのためそれがデフォルトとなってしまうため、害悪以外の何物でもありません。（当時は分からなかったのですが、今となってははっきり言えます）

技術力が低くても高い志は持つべきというのが僕の信念です。

SES をやめようと思った理由

未経験からIT業界を目指した理由である「システムを作ってみたい」という目標にたどり着くのに時間がかかってしまうと考えたため、転職しました。

未経験から拾ってもらったこの会社には恩しかないのですが、なんのために頑張っているかを考えた結果、次のステップに行く決意をしました。

今となっては当時の決断と行動は良かったと思っています。

受託会社時代

入社した経緯

当時はとにかく開発がしたいという気持ちがかなり強く、プログラムを書けるお仕事に就く事を目的に仕事を探していました。

当時のスキルセットというか僕の経歴上、なかなか僕自身が目指していた仕事に就くことは難しい状況でした。
その当時のスキルセットは以下になります。（未経験の実務経験1年に仕事があるはずがない

またスキルセットが薄い上に経歴もかなり汚れていたため、ハードルはかなり高い状況です。笑

これ以上経歴を汚さない + 目標にしていた業務内容（開発業務）の両方を達成するためには普通のやり方だと絶対上手くいかない事が目に見えていたので、派遣としてやっていこうと作戦を練りました。

派遣なら現場を転々としても履歴書には「202x年 x月 〇〇 入社」という形で書くことになるので、経歴が汚くなることを防ぐ事ができます。

また、開発業務に携わるのが難しいと判断したら次の現場に向かうのも正社員と比較して容易です。

上記の考えから以下の派遣会社に登録し、いくつかの面談を受けました。

作戦はズバリ的中し、受託開発を行っている企業にプログラマーとして派遣されることが決まりました。
この受託開発企業では3ヶ月の派遣期間が終了と同時に派遣元から引き抜きという形で正社員として入社させてくれたので何だかんだ運がよかったかもしれません。（かなりブラックでしたが笑）

良かったこと

本当に信じられないくらいの様々な経験をすることができました。

• 顧客との打ち合わせ
• 要件定義
• インフラ構築
• 開発
• テスト
• 運用

経験のない人間に上記のフェーズ全てを任せるのは企業としてはどうかと思うのですが、僕個人にはメリットしかない期間でした。

この企業で大きな学びとなったのは以下2点です。

1. 各フェーズにおける苦労
2. セキュリティ
3. システムはお金を稼ぐ手段でしかない

特に3のシステムはお金を稼ぐ手段でしかないはという考えは一生の宝物だと考えています。

顧客にとって必要なものは最新の技術を使ったシステムやおしゃれなUIで仕上げられた中身のないシステムではなく今、目の前にある課題を解決するシステムが必要であるということです。

この点をあまり理解していないエンジニアは肌感として多いと感じています。

「誰のため」や「何のため」を意識していかないと自己満で業務をこなすエンジニアになってしまうので皆さんもご注意を。笑

悪かったこと

とにかく色々な案件を掛け持っていたので労働時間がかなり長かったです。（詳細は以下の記事を。笑）

[getpost id=”1204″ target=”_blank” cat_name=”1″ date=”1″]

労働時間の問題さえなければ勉強になる状態ではあったので続けたかったのが本音になります。

たくさん勉強できたので個人的には満足な期間でした。

自社開発時代

入社した経緯

受託企業では短期間で様々な経験をすることができたのですが、基礎をすっ飛ばして目の前の案件を納期までに何とか動く状態にする事を目的に開発業務を行っていました。

簡単に言うと「保守性」「拡張性」「セキュリティ強度」が低い状態のシステムを作っていました。

エンジニアとしての能力値がかなり低い状態でしたので、次の現場ではちゃんとしたシステム開発を行っている企業に入社することを目標に転職活動を行いました。

ここでいうちゃんとしたシステム開発というのは以下のことを指します。

• セキュリティ意識が強いか
• 会社内でエンジニアの人権はあるか
  →人権ないと環境が整わないのでいい加減なシステム開発になりがち
• 強強エンジニアは在籍しているか
  →知見を元に良いシステムが何なのかを考えてくれるセーフティーライン

転職活動時は受託と自社に絞って求人を探していました。

Green と 転職ドラフト, TechClips ME（テックミー）を使って本当にたくさんの求人を精査しました。

• 前回の受託企業のような詰め込み型の令和の時代にそぐわない企業を避けるため。
• どちらもエンジニア向けのサービスであり、経歴書を充実させることで企業からのオファーが来るので結構おすすめです。

結果的に転職ドラフト経由で出会った自社開発企業の面接官が以下の事を言ってくれたので転職することを決めました。

• 君はまだまだ技術力が低い
• まだまだ知るべき事はたくさんある
• 私達の会社で勉強しながら成長しないかい？

良かったこと

いいものを作るというマインドが高い人に出会えた事が何よりも得難いものでした。

いいものを作るというマインドは過程の中では正しいプログラムの書き方やシステムとしてあるべき姿を目指すことになるので、確かな技術力の向上が感じられました。
（これが当たり前と言われればそうですが…

また技術力の向上と合わせて組織の作り方 も勉強になっています。

企業自体の従業員数は2000名ほどの人数を抱えているのですが、開発部は20名弱の組織体系です。

そのため正にこれからの組織という感じで、本当に価値のあるものを届けるために色々なアプローチを試しています。
優秀な先輩たちが「これを達成したい」と目標を定めて取り組む姿は、過程も含めて勉強になっています。（エンジニアである前に人間ですからね。笑）

悪かったこと

実際のところ、自社サービスを展開しているのですが毎月赤字という状況です。

どうにかこの状況を打開するために営業と開発が肩を組みながら頑張っている状況ですが、赤字という状況は肩身を狭くします。

現在、各数値が改善してきているので近いうちに黒字になってくれるはずでしょう。（希望的観測！）

所属会社の形態によって変わること

SES を悪く言うつもりはない

上記の表で SES の評価が高くないのは、僕が所属していた SES企業 があまり良くないところだったからです。

友達が所属している SES 企業の話を聞く限り、結構条件は整っているなぁという印象があります。

• 自社プレゼン会（自分で作ってきたものがプロダクトになる可能性）
• 案件選択性
• 以外にも平均勤続年数が高い

本当にピンキリです。

エンジニアスキル

エンジニアスキルは圧倒的に自社サービスが身につきます。

自社サービスに入社してよかったことにも記載したのですが、いいものを作るというマインドはかなり大きいです。

いいものを作ったところで売上が上がるとは限らないのですが、自分たちのサービスで下手なものを作るという事は絶対にしてはいけないことです。（わざわざ負債を抱える必要はない）

いいものを作るためには技術力が必要ですから、圧倒的に自社サービスが完勝です。

ビジネススキル

ビジネススキルは圧倒的に受託開発が身につきます。

理由はお客様は神様という構図が成り立つからですあり、お客さんとの調整をミスれば炎上してしまうという恐ろしい現実が待っているからです。

受託金額が高ければ高いほど無茶な要求をしてくるというのが肌感覚としてあったり、納期もなんやかんやで短く設定してきたりします。

また、ギスギスした社内であれば社内調整も必要のため、エンジニア業務以外の時間でかなりの労力が必要です。

顧客調整と社内調整の両方の観点からビジネススキルは受託企業の完勝です。

所属会社の形態によって変わらないこと

エンジニアである限り不変なことです。

技術力があり、所属先で価値を出せていること

上記が達成できている人はどの現場に行こうがどの形態で働こうが最強のエンジニアです。

所属会社の形態に関わらず大切にしないといけないこと

会社の形態によって特徴が違うのですが、学ぶべき点はどの形態の会社に行っても必ずあります。

そのため、1エンジニアとして最大限学ぶためにはプロジェクトの中心にいることが大切になってきます。

• テックリード
• スクラムマスター
• 上流担当

「自社サービスで末端の作業員をやっています！」という人よりも「SES で俺がプロジェクト回しているぜ」っていう人の方が圧倒的に市場価値は高いです。

どの形態で働こうがこの考えは大切にするべきです。

最後に

どの形態の会社で働くにせよ、自身の技術力を向上させ、プロジェクトで中心的な役割を果たすことを大事にしてください。

自分自身が何を考え、何を大事にするかで選択は変わってくると思います。

経験を通して学び、スキルを向上させ、満足の行くキャリアを歩めるように祈っています。お互いに頑張りましょう。

お互いに少しづつ慣れてきたこともあり、新入社員の本音を聞くことが出来たのですが「フリーランスも視野に入れています」という言葉を聞いてしまいました。。

そんな出来事のお話です。

新入社員の経歴

当記事では新入社員の身バレ防止の為、あまり詳細なことを記述できないのですが、大体以下のような経歴です。

• 実務経験なし
• 大学は情報系の学部ではない
• ポートフォリオとして自己アプリは見せてくれた

上記のような状態でした。

フリーランスという違和感

前提として僕はフリーランスになることに対して否定するつもりは一切ありません。

僕も実力があればフリーランスとして活動したいなーくらいの気持ちは持っています。(経費に多少の憧れが…笑)

むしろ、今後どうなるか見えない業界でもあるからこそ、稼げるうちに稼いでおくべきという考えもあります。

では、何故今回の「新入社員のフリーランスも視野に入れています」という発言に違和感を感じたかというと、

その実力でフリーランスになるのは厳しいぞ

というのが率直な意見です。

Gitの操作や小規模システムを構築する知見もない(サーバーとは何なのか、DBって？)レベルの20代が何を夢見ているのかと失礼ながら思ってしまったのですよ。

その気持の中には「俺はこれまでにこんだけ苦労してきたんだ」という嫉妬や妬みの感情も入っています。

現実問題、エンジニアってボコボコにされて痛みを伴いながら成長していく方のほうが多いじゃないですか。
（それが正かどうかは置いといて炎上プロジェクトの経験やレガシーな環境での開発経験は良い意味でも悪い意味でもエンジニアの素養や知見を育ててくれると考えています。

僕自身、令和ではあまり見ない稼働300時間の受託企業で働いていた経験があるので、実力がないフリーランスに対してあまり良い印象は持つことが出来ません。

ただし、夢ある若者に対してクソみたいな感情を持ってしまったのは1社会人として良くないなぁと反省しています。

[getpost title=”受託” id=”1204″ cat_name=”1″ date=”0″]

会社が受け入れた以上責任を持たなければ

一通り思っていたことを吐き出せたので、これからはあるべき姿について語らせてもらいます。

今回の一連の内容について悪い感情もあったのですが、1社会人として学ぶべきものもありました。

それは、会社側としては事業の拡大を目的に即戦力ではないとわかっていながらも雇っているので、受け入れた会社は責任を持って教育していかなければならないということです。

新入社員の方は経験を目的に、会社は事業の拡大を目的にという両者の利益が合致したからこそ同じ現場で働いているのでお互いがお互いに責任を果たす必要があるなと考えています。

自分が採用の判断を下していないのに何で自分が面倒な思いをしなければいけないのかと思ってた時期もありましたが、採用判断は自分の上司が判断したことなので従うしかないのです。悔しかったら偉くなるしかないのです。会社員は世知辛いです。。

今回の事案に関しては会社員としての責任を放棄する寸前だったので、上記の事柄について気づけてよかったです。

駆け出しエンジニアが嫌われている理由がわかった

学びはあったものの、今回の事案についてはやはりモヤモヤが残る一件でした。

コロナが始まった頃に駆け出しエンジニアブームがあり、Twitter上ではそれをよく思わないベテランの方々がいました。

当時は夢を見て頑張っている人に対して何故こんなにも怒っているのだろうと思っていたのですが、当事者となってあの怒りの正体が分かりました。笑

まー、実力がないとボコボコにされる業界なので全てのエンジニアが自分の望みを叶えれるよう努力していくしかないですね。。。

皆さん頑張りましょう。

タスクの早めの提出

割り振られたタスクに対して、早めに提出しレビューを依頼することを心がけることが出来た。

私は割り振られたタスクに対して時間をかけすぎてしまう節があるので、とりあえず動くものを作って早めにレビューを貰うことを狙っての行動です。

レビュワーの時間を奪ってしまうのではないかという考えもあったのですが、一人で抱えてしまうよりも他の人の意見を頂いて次のタスクに取り掛かる方がチーム全体への貢献ができるのではないかと思っています。

チームの方から怒られる前に一人前のものを納品できるよう早めに成長したいところですね。

新人さん

基本的に私の所属チームの方はリモートの際にミーティング以外の時間に雑談をする文化がないです。（前の現場ではちょっとした雑談をする文化があっただけなので、一般的な話は知りません。）

僕も参画して1ヶ月ほどですが、疎外感を感じる時が多々あります。

そういう思いがあったので、リモート時には5分程度ではありますが、ビデオ通話を用いて顔を合わせちょっとした安心をお互いに持てるよう心がけています。

業務に影響が出ない範囲で続けていければいいなと。

技術面

truthy/falsy

厳格な真偽値を学ぶことになる。

これまではプログラムが「1」と「True」は正として扱うと考えていた。

そんな中で以下のコードが通らず驚いた。

$nonStrictBool = 1; //実際にはpreg_match()の戻り値
assertTrue($nonStrictBool);

//false

※最終的には(bool)$nonStrictBoolという形で判定を行うことで対処。

これまでPHPを扱っていく中で、このデータがの破損があった場合にシステムに大きな侵害が出るという予想がたった時だけ厳格な判定を行ってきた。

そもそもの話、全て厳格に扱えばいいだけの話なのでこれからは厳格に扱っていこうと思う。

PHP 型の比較表 ¶

array系関数を学ぶ

これまでの人生、配列をforeachで回して加工処理を実行していました。

残念ながらPHPには便利な関数が充実しており、簡単に処理できることを知ってしまった。

[getpost id=”1312″ cat_name=”1″ date=”0″]

この記事はジュニアエンジニアやミドルエンジニアを想定している記事です。

同じ様な働き方やIT業界の働きづらさに怯えている方の参考になれば幸いです。

前提

所属先の簡単な概要です。

厳しい社内リソースと案件数だったため、高稼働の状態でした。

またタイトルで受託企業と謳っているのですが、元々は紙を扱った業種の会社だった為、古い体制が残り続けている会社となっています。
そのため、システムを構築する期間を度外視した案件のとり方をしてきた結果が悲惨な状態を作り上げていきました。

なぜ300時間を耐えたのか

結果的に退職することになったのですが、まずは何故300時間の働き方を耐えてきたのかをお伝えしたいと思います。

一般的に「1日8時間×月20日+残業(5〜20h)=180〜200h」の働き方が普通だと思います。

そんな普通の働き方と比較して過酷な300時間の働き方を10ヶ月間も耐えたかというと自分の技術を伸ばしたいという目標があったからです。

前職はエンジニアの人手不足、社内の技術ストックもない状態でしたので自分自身で目の前の案件を乗り切るしか方法がありませんでした。

そのような状況下で働き続けたので肉体と精神を削って確かな技術を得ることができました。
前職に入社するまでは、末端作業員レベルだったものが炎上案件を複数こなしたことで、1エンジニアとして市場に出れるレベルになったと思います。

まだまだ足りない技術のほうが圧倒的に多いのですが、エンジニアとして名乗れるラインには立つことができたので目標達成です。

300時間働いて良かったこと

1→10までやらせて貰えた

要件定義からテストまでの工程を自分が主軸となって経験できたのが何より得難いものでした。

各工程を経験したことによって、どのくらいの期間でどのレベルまで仕上げるのかが少し想像することができるようになりました。
小規模案件が多かったのでまだレベルは低いのですが、工程ごとに躓きやすい部分や作業者の負担について考える良い経験をもらいました。

また、1→10の中で特に経験できて良かったことを挙げます。

• 要件定義

本当に必要な機能なのかを含めて顧客が求めているものは何なのか、顧客が求めているものは予算と納期にマッチしているものなのかを考え、話すことができました。
※ITについて知識が浅い顧客も中には存在していたので、技術可否や機能の不必要の判断を見誤ると案件が火を吹きます。(1つの案件で火吹いちゃいました。)

• 設計

システム設計から始まり、外部設計,内部設計,DB設計などたくさんのことを考慮して、全体設計を考えていきました。
設計って経験が必要ですね。。。

• 技術選定

何を使ってシステムを構築するのか、ある機能を実装するために必要なパッケージの導入など。

受託先企業の内部を見ることができた

エンジニアならゲロを吐きそうになるデータの持ち方をしている企業さんやエンジニアなら何でも叶えてくれるという考え方を持った人に出会いました。

世間ではDXやIT化の推進などが叫ばれていますが、それらを達成するためには時間が必要なことを実感できました。

技術に対するお金の考え方が身についた

1エンジニアが個人単位で売れるものは技術ですが、会社単位で見るとお金になっているのは作り上げたシステムがもたらすITによる恩恵です。

受託企業では「複数の言語を書くことができます！」といった技術よりも、ITによる恩恵が重要だと思います。

何ができるかよりも何を達成することができるのか。

ただし、エンジニアである以上、技術にこだわる必要は絶対にあるはずです。

お金と技術が必ずしも比例していくわけではないので、ここは引き続き悩み続けていきたいですね。

300時間働いてダメだったこと

体に異変

特に感じていたのが以下の2つです。

• 体重-7キロ
• 些細なことでカッとなる

300時間働くということは何かを削る必要が出てきます。
自分の場合は「睡眠」と「食事」でした。

フルリモートということもあり1日1食、6時間睡眠がデフォルトとなっていました。

その結果、上記の異変が体に起きてしまいました。

得た経験が多かった反面、体への負担もかなり多かったと思います。笑

社内を変えることができなかった

退社する時には僕を含めて4名のチームでした。(先輩エンジニアも300時間)

月300時間働くということは人数に見合わない案件数や納期の短さ、部長がITに精通していないなどが挙げられるのですが、問題となっている原因を変えることができないまま退職することになりました。

解決できなかった問題を社内に残る人たちに押し付ける事は辛いもんですね。。

最後に伝えたいこと

目標があり、その目標を達成できる仕事ができるのであれば無茶な働き方をするべきだと思います。
技術がほしい、お金がほしいなど目標がある方であれば多少の無茶をしてでもご自身の目標を掴み取ってほしいものです。

反対に目標がない(楽できれば良い)、目標に沿わない仕事しかできないのであれば、僕のような無茶な働き方はしないで欲しいです。

炎上も悪くないものですが、ご自身で考えて決定して行動していってほしいです。

条件

言語：PHP、JS、SQL(MySQL)、Bootstrap
ソース管理：Git(GitHub)
インフラ：AWS←上司がやってくれた
業界歴：1年と1ヶ月
納品物：予約システム

案件の状況

納期：1ヶ月半
開発チーム：2人
実施したこと：インフラ構築以外の全て

良かったこと

インフラ以外を全て経験できた

お客さんとの打ち合わせから入り要件定義、設計、開発、テストまでを体験できた事。
すべての工程を自分が主軸となって進めていけたのは大きな経験でした。

要件定義や設計などの上流工程の名前は知っていたものの、やってみて初めて大変さが分かりました。

• どのように進めていくのか(工数管理)
• 要件のすり合わせ
• 設計

納期は守れた

稼働時間はエグいことになったけど(炎上)、期限通りに納品できました。

実力ないと時間でカバーするしかないので、早く実力付けないといけませんね。

反省点

ドキュメントは残しておくべき

今回の案件では納品物が、モックと完成したシステムの2つという中々ふざけた内容の案件となっていました。
(僕の中では仕様書や設計書を納品するのが当たり前と思っていたので衝撃でした…。
納期が短く工数も足りていないという事で、作成したドキュメントは自分しか分からない内容となっていました。)

開発の途中でお客さんや担当営業者からデザイン変更や機能追加などが度々起こってしまい、仕様変更の度に要件とは違うことを証明することが出来なかったです。

要件定義が終了した時点でドキュメントを残しておくべきでした。

IT全般の知識必要

お客さんとの均衡の際にITの幅広い一般常識が必要でした。

• 要件を満たすためにはどういう機能が必要なのか(不必要なのか)
• セキュリティは問題ないか
• 一般的なWebシステムとの比較

お客さんから「これは出来るの？」と聞かれた際に「〇〇は✗✗なので△△です。」というような目的に沿った説明をすることが出来ませんでした。

経験が少ないとかは関係なく、Web屋を名乗っている以上プロとしての知見を持たなければいけませんねぇ。
ただ、自分の中で確信が持てないことに対しては「調査した上でお返事致します。」と出来る事を前提に話を進めなかった事は良かったポイントです。

設計は激むず

設計はやっぱり難しい。あんなの経験ないと無理だよ。

• DB設計
• クラス設計　等

最適なデザインパターンや他人のコードなどから学ぶしかないなというのが率直な反省です。

先は長いなぁ。

大事なのはデータ

上司からのコードレビューからデータ保護のバリデーションが1つだけ抜けている部分がありました。

Webアプリケーションではデザインや実行速度など大切なことは沢山あるのですが、何よりもデータが一番の核だと考えます。

核となるデータに穴があったのが結構ショックでした。(見つけてくれた上司には感謝)

データ保護は大切に。。。

総括

色々苦しい事は有りましたが、リリースまでをやらせてくれたことに感謝します。
沢山学べました。

リリース後は溜まっていくデータを見るだけでとても嬉しい気持ちになれました。
またその反面、事故が起きていないかと怖い気持ちにもなってしまいました。

良いことも悪いことも経験できた案件よ。ありがとう。

プログラミングを勉強した当初、HTMLとCSSは勉強する必要がないという記事を見かけたこともあり、HTMLとCSSの勉強をおろそかにしたままPHPやSQLの言語習得を目指しました。

しかし、お仕事の話や就職活動の話の中で最低限のサイトを構築できるくらいのHTMLとCSSは身に着けるほうが良いという話も頂いたのでHTMLとCSSに自信を持って扱える様にしたいと考えました。

HTMLとCSSは浅いようで広い

「浅いようで広い！」というのが勉強を初めて一番感じたことです。

HTMLとCSSはプログラミング言語ではないから習得は簡単とよく耳にしていたのですが、いざ自分でコードを書いていくと、コード量が半端じゃないくらい多いことに気づきました。

確かにPHPやJavaScriptのようにプログラミング言語ではなく、ロジックを考える手間が少ないので簡単だと言う意見も分からない気もしないが、

• ユーザビリティ
• レスポンシブ対応
• ユーザーに飽きさせない為に画面に動きを付ける
• SEO対策

など考えることがたくさんあることが分かりました。

また、ECサイトなどの商品の購入などが発生するサイトを構築する場合などはボタン一つとっても、
購買意欲が高まる色など、心理学といったIT技術以外の学問も応用するなど工夫しないと行けないこともある。

このように考えると、プログラミング言語ほど難しくはないが幅広い知識が必要になってくるのがHTMLとCSSだと思う。

結局の所、HTMLとCSSはバカにしたらいかん。
絶対HTMLとCSSをバカにしたらいかん。

プログラミング言語はサイトやアプリに機能を持たすだけであって、見た目を作ってくれる訳ではありません。

「IT技術をエンジニア以外の人にわかりやすく伝えているのがHTMLとCSS（見た目を作ってくれているから）」
普通の人にでもIT技術を使ってもらえるようにしているのがHTMLとCSSの大きな役割の様な気がします。

※IT技術が浸透していない企業では、HTMLとCSSでWeb画面を作るだけで凄く褒めてくれます。普通の人の目線だとHTMLとCSSも立派なIT技術に該当します。

もちろん、エンジニアの方にこの話をしたら笑われる気がしますが、僕はHTMLとCSSがWeb系のIT技術の土台の1つだと思っています。

だから
HTMLとCSSはバカにしたらいかん。と思っています。

ちなみにここまでHTMLとCSSを褒めてきたのですが、PHPのコードを書いているときが一番楽しいです。。。