CDK、楽しいですよね。Typescript でインフラがかけるなんて最高です。でも、学習を始めていくとある壁にぶつかりました。

ネット上の「CDKでECS構築してみた！」系の記事を参考にすると、大抵の場合 VPCもECSもRDSも全部一つの lib/my-stack.ts に処理が書かれている」のです。サンプルコードとしてはわかりやすいのですが、いざ実務でLMAP環境を作ろうとすると⋯…

• VPC は更新頻度が低いからスタックを分けたい
• RDS はステートフルだから独立させたい
• ECS はアプリケーションコードのデプロイで頻繁に更新が入るかも

とスタックを分割したくなりませんか？
でも、分割した途端に「StackA で作ったVPCのIDをどうやってStackBにわたすの？」という問題が発生します。

当記事では、現時点での私の持論である スタック間のリソース共有を紹介します。

IDではなくオブジェクトを渡す

VPC スタックとECSスタックを分けるときに、ついやってしまいがちなのが VPC IDを Props で渡す という手法です。
Terraform に慣れていると、この発想になりがちですよね。

この手法では CDK の 型安全を活かすことが出来ないので、 VPCオブジェクトそのもの を渡すのがベストだと考えています。

私の構成案：
司令塔となる エントリーポイント app がバケツリレーのようにオブジェクトを渡していくイメージです。

1. VPCStack： VPCを作る。 public readonly vpcでVPCオブジェクトを公開する
2. APP： VpcStack からVPCオブジェクトをもらい、 ECSStackに渡す
3. EcsStack： 受け取ったVPC オブジェクトを使ってクラスターを作る

実際にコードを見ていきましょう。

型安全の恩恵を受ける

VPCStack ⇒ 渡す側

ここでは this.vpcをクラスのメンバ変数として公開しておきます。

// lib/vpc-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export class VpcStack extends cdk.Stack {
  // 外部に公開するプロパティ（これが重要！）
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    this.vpc = new ec2.Vpc(this, 'LampVpc', {
      maxAzs: 2,
    });
  }
}

EcsStack ⇒ 受け取る側

ここがポイントデス。 vpcId: stringではなく、 vpc: ec2.IVpc というインターフェース型で受け取ります。

// lib/ecs-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

// Propsの定義：文字列ではなく「VPCの型」を指定する
interface EcsStackProps extends cdk.StackProps {
  vpc: ec2.IVpc;
}

export class EcsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: EcsStackProps) {
    super(scope, id, props);

    // 文字列から検索する必要なし！そのまま使える
    const cluster = new ecs.Cluster(this, 'LampCluster', {
      vpc: props.vpc, 
    });
  }
}

bin/app.ts ⇒ 繋ぐ場所

最後にエントリーポイントで紐づけます。

// bin/app.ts
import * as cdk from 'aws-cdk-lib';
import { VpcStack } from '../lib/vpc-stack';
import { EcsStack } from '../lib/ecs-stack';

const app = new cdk.App();

// 1. VPCを作る
const vpcStack = new VpcStack(app, 'VpcStack');

// 2. VPCオブジェクトをECSスタックに渡す
const ecsStack = new EcsStack(app, 'EcsStack', {
  vpc: vpcStack.vpc, // ここでバケツリレー
});

この方法の何が良いの？

この方法のメリットは2つあると思っています。
（一言で言うとプログラミング言語による抽象化です。）

1. 圧倒的な型安全性
   もし間違えてS3のオブジェクトを渡そうとすると、エディタがその場でエラーを吐いてくれます。
   「デプロイしてみたらIDが違ってコケた」という悲劇が未然に防げます
2. 記述がメチャ楽
   受け取る側で ec2.Vpc.fromLookup() のようなインポート処理を書く必要がありません。渡された瞬間から props.vpc.addInterfaceEndpoint のようにメソッドが使えます

議論したいポイント

ここまで「これが正解だ」という顔で書いてきましたが、実はこの構成には明確なデミリットもあります。それは、 スタック同士が密結合 になることです。

Cloudformation の Export/Import 機能でガッチリ紐づいてしまうため、以下のような問題が置きます。

• スタック間の参照があるため、「VPCだけを作り直したい」が出来ない

ただし、私は上記のような問題が発生したとしても、
LAMP 環境という一つのアプリケーションにおいて、VPCとECSは「運命共同体」にあたるため問題ないと考えています。

「ECSが生きているのにVPCだけ消したい」という状況は稀ではないでしょうか。そのためこの密結合はあえて受け入れるべき仕様だと割り切っています。

ただ、もし組織の基盤となる共通のVPCを作る場合は、ライフサイクルが異なるため、疎結合なID渡しにするのが正解なのかもしれません。

皆さんの構成おしてほしいっす。

正直に告白します。僕はこれまで、なんとなくログを出していました。
「エラーが起きたら怖いから、とりあえず try-catch してログに残しておこう」
「ないよりはマシだろう」

でも、いざ本番で障害が起きたとき、そのログは僕を助けてくれませんでした。
深夜のアラート対応で、システムエラーが発生しました とだけ書かれたログを前に途方に暮れた経験、皆さんにもありませんか？

今回は、そんな「なんとなくログ」を卒業し、トラブルシューティングや分析に本当に役立つ「使えるログ」を設計するために学んだことをまとめました。

ログの目的を再定義する

そもそも、なぜログを書くのでしょうか？ チームで決まっているからではなく、エンジニアとして以下の3つの目的を意識する必要があります。

1. トラブルシューティング（Why & Where?）
   • 「なぜ落ちたのか」「どこで落ちたのか」を特定し、バグを再現・修正するため。
2. 可観測性・分析（Observability）
   • 「この機能、どれくらい使われてる？」「処理に何秒かかってる？」といったシステムの健康状態やユーザー行動を知るため。
3. 監査・セキュリティ（Security）
   • 「いつ、誰が、重要なデータを変更したか」の証跡を残すため。

これらを意識すると、「とりあえず出力」ではなく「目的に合わせて出力」する必要があることに気づきます。

構造化ログってなんや

ログ設計を学ぶと必ず出てくるのが「構造化ログ（Structured Logging）」です。

構造化ログとは「ログを人間への手紙ではなく、機械へのデータとして扱う」ということです。

非構造化ログ

従来のテキスト形式のログです。

// 人間には読めるけど、機械（検索）には辛い
Log::error("User 123 failed to login from 192.168.0.1");

これだと、「ユーザーID 123 のエラーだけ集計したい」と思ったときに、正規表現で頑張って文字列解析をしなければなりません。
ログの文言が少し変わっただけで検索できなくなるので、運用が非常に辛くなります。

構造化ログ

ログをJSONなどの形式で出力します。

// メッセージとデータを分ける
Log::error("Login failed", [
    "user_id" => 123,
    "ip_address" => "192.168.0.1",
    "event" => "auth_error"
]);

これが出力されると、以下のようなJSONになります。

{
  "level": "ERROR",
  "message": "Login failed",
  "context": {
    "user_id": 123,
    "ip_address": "192.168.0.1",
    "event": "auth_error"
  },
  "datetime": "2024-01-07T12:00:00+09:00"
}

こうしておけば、DatadogやCloudWatch Logsなどのログ管理ツールで context.user_id = 123 のようにクエリ一発で検索・集計ができます。

現代のWeb開発では、ログは「読むもの」ではなく「検索・集計するもの」です。
構造化ログはマストと言えます。

ログ設計の実践

では、実際にコードを書くときに何を意識すべきでしょうか。

やるべきこと

コンテキスト（文脈）を含める

「エラーです」だけでは無意味です。
「その時何が起きていたか」の情報を連想配列（Context）として渡しましょう。

何が起こったかを把握するためにも 5W1H を意識するといいかもですね。

• 誰が？ (User ID)
• 何を？ (Input Data)
• どこで？ (Request URL, IP Address)

トレースID (Trace ID / Request ID) を通す

これが今回一番の学びでした。
「1回のリクエスト」に対して、ユニークなID（Trace ID）を割り当て、それを全てのログに含めます。

// 理想的なログ出力
{
    "message": "DB error",
    "request_id": "a0eebc99-9c0b...",  // これ
    "user_id": 101
}

これがあれば、マイクロサービスや非同期処理でログがバラバラになっても、IDで検索して「一連の処理の流れ」を追うことができます。

Laravelなどでは、ミドルウェアで自動的にIDを発行し、Log::shareContext() 等を使って全ログに自動付与する設定を入れておくと、コードを書くときに意識しなくて済むので最高です。

ログレベルを適切に使い分ける

チーム内の基準に従いましょう。ない場合は基準を決めておきましょう。

下記は一例です。

• ERROR: 即時対応が必要（深夜でも電話がかかってくるレベル）。
• WARN: 異常だがシステムは稼働継続可能（後で要確認）。
• INFO: 正常系イベント（KPI分析や動作確認用）。
• DEBUG: 開発時のデバッグ用（本番では出さない）。

アンチパターン

機密情報の出力

パスワード、アクセストークン、クレジットカード番号、個人情報（PII）をログに出してはいけません。

ログファイル自体が漏洩したときのリスクが甚大です。平文なのでね。

「とりあえずcatchしてログ」による握りつぶし

一番やりがちなやつです。

try {
    $user->save();
} catch (Exception $e) {
    // 最悪なパターン：エラーが起きた事実だけログして、処理を続行してしまう
    Log::error("Error happened"); 
}

これだと、データ不整合が起きているのにシステムが動き続け、後で原因不明のバグになります。
対処できないエラーはログに出すだけでなく、適切に例外を再スローするか、エラーレスポンスを返す必要があります。

ログ運用

「ログをどこに出すか」も重要です。

DockerやKubernetesなどのコンテナ環境では、「標準出力（stdout/stderr）に吐く」のが定石です（The 12-Factor Appの思想）。

アプリは標準出力にJSONを流すだけ。あとはFluentdやDatadog Agentがそれを拾って、S3やログ管理基盤に転送する。アプリは「ログの保存場所」に関知しない設計にするのがモダンな運用です。

5. ログローテート

最後に、地味だけど大事な「お掃除」の話です。 もしファイルにログを出力する場合、書き続けるといつかディスクが溢れます。数GBのテキストファイルを開こうとしてエディタが固まった経験、ありますよね？
（いつぞやに対応したEC2のアラート対応で、15GBのログファイルがサーバーを圧迫していた事件がありました。）

• ローテート（Rotation）： 日次やサイズ指定でファイルを分割する（例: app.log -> app.log.2024-01-07）。
• 保持期間（Retention）： 「14日経過したら削除する」といったルールを決める。

PHP（Monolog）なら RotatingFileHandler を使うことで簡単に実装できますし、Linuxの logrotate コマンドで管理することもあります。

「ディスクフルでサーバーダウン」は一番悲しい障害なので、リリース前に必ず確認しましょう。

おわりに

ログ設計を見直すことは、「未来の自分やチームメイトへの思いやり」です。

障害発生時、適切なログ（構造化され、Trace IDがあり、必要な情報が詰まっているログ）があれば数分で解決できる問題が、ログがないために数日かかることもあります。

「何かあったときに、このログを見て原因がわかるか？」 「一年後の自分がこのログを見て感謝するか？」

そう自問しながら、明日からの Log::info() を書いていきたいと思います。

炎上案件とは？

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

• シンプルな短納期（多分炎上の理由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になっていきましょう〜

チームに所属するインターン生から1つの相談がありました。

「やんやんさん、プログラムが動きません。。。」

最初は「実行エラーだろう、エラー文言に何が書いてあるのか読めよ」と思っていたのですが、エラーの内容を読むと事態は思ったよりも深刻であることに気づきます。

原因はiCloud

原因はプログラムの配置場所がiCloudで管理しているDesktopに置いていることでした。

Gitで管理しているソースコードがiCloudとの同期が取れておらず、ファイルの増減がありプログラムが正常に動作しないという問題です。

Git（リモートリポジトリからのpull, ブランチの切り替え等）で管理しているはずのソースコードが裏ではiCloudでも管理されていたという間抜けな話でした。

みなさんもご注意を。。。。

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

• 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 で俺がプロジェクト回しているぜ」っていう人の方が圧倒的に市場価値は高いです。

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

最後に

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

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

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

「Software Design (ソフトウェアデザイン) 2023年6月号 [雑誌]」という雑誌に出会ったので、SOLID原則を学習中です。これを機に3流プログラマーに慣れたらいいなぁと。

前回の学習内容はこちら

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

まずはInterfaceから

PHPにおけるInterface（インターフェース）は、クラスが実装するべきメソッドのシグネチャ（メソッド名、引数、戻り値の型）を定義するための機能です。

Interfaceは抽象的なクラスであり、実際の実装を持ちません。
(じゃあいらんやん…って思っちゃいますよね)

なぜ必要なのかというと、
クラスはInterfaceを実装することで、そのInterfaceで定義されたメソッドを必ず実装しなければならないからです。

例えば、ユーザーにメッセージを送信する場面を考えて下さい。

どの様なメッセンジャーを使うにしても必ず「メッセージを生成する機能」と「メッセージを送信する機能」の2つが必要になるはずです。

ここではメールで送信する場合(メールクラス)とLineで送信する場合(Lineクラス)を想定してみます。

interfaceを以下のように定義することで、実装したクラスはinterfaceの内容を必ず実装しなければいけません。

interface Message {
    public function createMesseage();
    public function sendMessage();
}

上記の様に定義することで、メールクラスとLineクラスは必ず同じメソッドがある事が担保されます。(クラスは同じ振る舞いを持つことが保証されます)

仮にSlackでメッセージを送信したい場合、Slackクラスに同じメソッドを実装するだけで済むため拡張性が高くなりますよね。あら、わかりやすい。笑
(既存のクラス(メールクラス、Lineクラス)に影響なく実装できる)

class Mail implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

class Line implements Message {
    public function createMessage() {
        //処理    
    }

    public function sendMessage() {
        //処理   
    }
}

interface Message {
    public function createMessage() {}
    public function sendMessage() {}
}

いよいよ依存性反転の原則

一旦、呼び出し元の観点を持ってみましょう。

interfaceを実装することで、呼び出し元のコードはinterfaceに対して依存し、具体的な実装クラスに対して依存しないためコードの結合が低くなります(疎結合。。。)

先程のコードで考えると呼び出し元はメールクラスを呼び出しているつもりでもinterfaceを経由しているのが実態です。

Interfaceを使用することで、クラス間の依存関係を抽象化し、実装にではなくインターフェースに依存するようにすることができます。

• 呼び出し元の見ているところがinterfaceになる
• interfaceは定義する場所
• interfaceを継承したクラスは必ず同じメソッドある
• 結果、呼び出し元と実装クラスはinterfaceに依存している

これにより、依存性反転原則が達成されます。

ちゃんちゃん。

タスクの早めの提出

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

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

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

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

新人さん

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

僕も参画して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″]

先に結論なんですけど、リーダブルコードは当たり前の事が書いてあります。

ただその当たり前の事が出来ていないと感じたのですぐに実践できることを備忘録として残したいと思います。

プログラマーとして

forのネスト

ループがネストしている場合はインデックスを分かりやすく定義してあげる。

以下のコードではループする変数の接頭辞をインデックスの接頭辞に着けることで、インデックスの使用を楽に出来る！！
※めちゃくちゃ便利！わかりやすい！
※ループをネストしないコードをかければ一番良いかもねぇ

$users = array(
    //複数要素
);

$entry_point = array(
    //複数要素
);

for($u_i=0;$i<count($users);$u_i<$users){
    for($e_i=0;$e_i<count($entry_point);$e_i<$entry_point){
        //処理
    }
}

視覚的に優しく

縦に並べる

DB::table('ex_stores')->insert([
            [
                'store_id' 　　　　　　　　　　　　=> '123456',
                'logo_path' 　　　　　　　　　　=> 'demo_cafe.png',
                'big_category' 　　　　=> '食べ物',
                'small_category' => 'カフェ',
                'tag1' 　　　　　　　　　　　　　　　　　　　　=> 'ゆったり',
                'tag2' 　　　　　　　　　　　　　　　　　　　　=> 'まったり',
                'tag3' 　　　　　　　　　　　　　　　　　　　　=> '潮風に揺られながら',
                'top_url' 　　　　　　　　　　　　　　=> 'main',
            ]
]);

コメント

コードに指摘を入れる場合

自分が書いたにしろ他人が書いたにしろ、何かを感じた場合は下記のようにコメント残したいです。

特にGitのコメントに使えそう。

コメントの基本原則として以下を抑えておきたい。

クラスやメソッドはひと目で分かるように

クラスやメソッド内での処理がすぐに理解できるように、処理内容をコメントする。

パターンとしては以下がある。

• 実例をコメント
  • • XXXを○○○して△△△という形式に変更
• 処理をブロックごとに分けてコメントする
  • • 大きいメソッドなどは適切なタイミングでコメント

問題になりそうな箇所は先に明示する

※かなり大事な気がするので例を書きます。

仮にインサート関数とデリート関数を定義してインサート関数の前にデリート関数を実行させる処理を行いたいとする。

class DB{
public function insert($data){
DB::delete();   
}

public function delete(){

}

}

インサート関数の中でデリート関数を呼び出しているのですが、仮にデリート関数で複雑な処理を行っており処理自体が10秒かかるとしたらインサート処理自体が10秒以上かかってしまうことになります。

上記の場合、詳細を知らないメンバーがデリート関数を呼び出してしまうと想定外の結果となってしまう危険性があるため、以下のようなコメントを残す必要があります。

class DB{
public function insert($data){
DB::delete();   
}

//注意：実行時間10秒以上
public function delete(){

}

}

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

同じ様な働き方や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に精通していないなどが挙げられるのですが、問題となっている原因を変えることができないまま退職することになりました。

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

最後に伝えたいこと

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

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

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