PHPエンジニアの参画初月にやること｜現場で信頼される進め方

PHPエンジニアの参画初月は、開発環境と本番までの流れをつかみ、コードと業務の地図を作り、小さな変更を本番まで通すところまでを目標にします。最初の1か月で成果として求められるのは、大きな機能を作ることより、この人に既存のコードを任せて大丈夫だと発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、PHPエンジニアならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境とコードの全体像をつかむ

最初に読むもの

PHPの現場は、同じLaravelでも構成や決まりごとが現場ごとに違います。次の順で目を通すと、全体像をつかみやすくなります。

1. READMEと環境構築の手順：Dockerなどの開発環境、必要な設定、動かし方。手順どおりに動かなければ、その食い違いを記録する
2. ルーティングとディレクトリの構成：主要な画面やAPIがどこにあり、処理をどの層に置く決まりになっているか
3. マイグレーションとテーブルの定義：データの持ち方、主要なテーブルの関係、外部キーや制約の有無
4. 直近のプルリクエストと、その中のやり取り：コードの書き方、レビューで指摘される点、テストの書き方
5. デプロイの手順と本番の構成：誰がどう本番に出すのか、本番と開発環境で何が違うか
6. PHPとフレームワークの版、依存ライブラリ：サポート中の版か、更新の計画があるか

読みながら、「決まりごとはこうなっているが、コードは違いそう」という点を書き留めておきます。この段階では結論を出さず、仮説としてためておきます。

壊してはいけない処理を先に聞く

決済、在庫、ポイント、会員情報の扱いなど、間違えると取り返しのつかない処理は、最初の週にリーダーや社員に聞いておきます。あわせて、本番のデータベースに触れてよい範囲、本番サーバーに入る決まり、個人情報の扱いも確かめます。守秘義務の範囲は秘密保持契約で確認することも参考になります。

関係者と短く話す

リーダー、よく一緒に作業する社員、業務の担当者と、それぞれ短い時間で話す機会をもらいます。聞くことは次の3つに絞ると、相手の負担になりません。

• 今いちばん困っていること、直したいところ
• 触るときに気をつけてほしい箇所
• 最初の1〜2か月で自分に期待すること

同じ質問を何人かにすると、人によって見方が違う点がはっきりします。この違いが、コードの危ない箇所や、仕様が人の頭の中にしかない部分の手がかりになります。

2週目：小さな変更を本番まで通す

最初の変更は小さく選ぶ

2週目には、小さな不具合の修正や、影響の限られた機能の変更を一つ引き受けます。目的は、ブランチを切ってからレビューを経て本番に出るまでの流れを、自分の手で一度通すことです。大きな機能より、軽微でも本番まで出る変更のほうが、信頼の材料になります。

現場の書き方に合わせる

最初の変更では、現場のコード規約、テストの書き方、コミットの粒度に合わせます。自分の好みの書き方や、前の現場の決まりを持ち込まないことが大切です。レビューで指摘を受けたら、理由を聞いて次から合わせます。

報告の形を合わせる

リーダーに、どの頻度でどの粒度の報告がほしいかを確かめ、初回の報告を出します。PHPの改修では、「何を変えたか」より「何に影響するか」「何を確かめたか」を先に書くと読まれやすくなります。リモート中心の案件での報告の工夫はPHPエンジニアのリモートの記事でも触れています。稼働の記録は初日から付け、報告の形は稼働報告書の書き方をご覧ください。

3〜4週目：地図を仕上げ、次の範囲に合意する

コードと業務の地図をまとめる

1〜2週目で集めた情報をもとに、自分用の地図をまとめます。中身は次のとおりです。

• 主要な処理の場所と、処理の流れ
• 壊してはいけない処理と、その周りで気をつける点
• テストの有無と、テストが薄い箇所
• 遅そうな処理（一覧、集計、外部APIの呼び出し）の見立て
• 仕様が資料になく、人に確かめる必要がある点

この地図は、発注側に見せるためのものでもあります。「ここは直す前にテストを足したい」「この処理はSQLの数が多そうだ」のように、気づいた点を事実と見立てに分けて共有すると、2か月目以降の相談がしやすくなります。

やや大きな変更を一つ担う

流れを一度通せたら、少し大きな機能の変更や、影響範囲の広い修正を一つ引き受けます。影響範囲の調べ方、テストの足し方、段階的な出し方を、ここで示します。安全に変える手順はPHPの案件で求められるスキルで整理しています。

次の1〜2か月の範囲を合意する

月末には、リーダーと次の1〜2か月で担う範囲を言葉で確かめます。機能の開発が中心か、改修が中心か、テストや性能の改善を含むか、版の更新に関わるかを確かめておくと、2か月目以降の食い違いを防げます。

案件の型によって初月の重心は変わる

同じPHPの案件でも、型によって初月に力を入れる場所が違います。

自社サービスの開発

短い周期でリリースを重ねる現場では、流れを早くつかみ、2週目から機能の一部を担えることが期待されます。コードの読解に時間をかけすぎるより、小さな変更を早く出し、レビューのやり取りの中で現場の書き方を覚える進め方が合います。

既存システムの改修・版の更新

古いコードを直す案件では、地図づくりに時間をかける価値があります。テストのない箇所、仕様が人の頭の中にしかない箇所、サポートの終わった依存ライブラリを初月に洗い出し、「どこから手を付けるか」の案を月末に出せることを目指します。初月から大きく書き換えないことが大切です。

業務システム・EC

業務の決まりごとが仕様の中心になる案件では、コードより先に業務の担当者と話す時間を取ります。注文、在庫、請求といった業務の流れを言葉で確かめ、コードのどこがその流れに当たるかを結び付けていきます。

受託のWebサイト・CMS

納期の決まった制作の案件では、初月のうちに成果物の範囲、修正の扱い、検収の方法を確かめることが中心になります。作る速さも求められるため、環境と流れを最初の数日で整え、早めに作り始めます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは作業範囲が広がったときの記事、PHPエンジニアがつまずきやすい場面はPHPエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 自分の環境でアプリケーションが動き、本番までの流れを一度通せたか
• コードと業務の地図を、分かったことと分からないことに分けて共有できたか
• 壊してはいけない処理と、本番に触れる決まりを把握しているか
• 報告の形がリーダーの求めるものと合っているか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。年代によって期待される役割の違いはPHPエンジニアは40代・50代でもフリーランスで働けるかで扱っています。

よくある質問

環境構築の手順が古く、手順どおりに動きません。どうすればよいですか？

動かなかった点と、自分で試した対処を記録しながら進め、早めにリーダーに相談します。手順の古さは、ほかの人にも起きている可能性が高く、直した内容をREADMEに反映すると、最初の貢献として受け止めてもらいやすくなります。一人で何日も抱え込まないことが大切です。

参画してすぐに大きな機能を任されたら、どうすればよいですか？

引き受けつつ、影響範囲を調べる時間と、テストを足す時間を見積もりに含めて伝えます。分からない点は仮説として示し、確かめる相手と期限を決めておくと、進め方に納得してもらいやすくなります。初月は、見積もりに不確かな部分が多いことを、先に伝えておくのが安全です。

前任者の引き継ぎ資料がほとんどありません。何から始めればよいですか？

ルーティングとマイグレーション、直近のプルリクエストから読み始め、主要な処理の場所を自分で地図にするのが近道です。そのうえで、リーダーと業務の担当者に、困っていることと気をつけてほしい箇所を聞いてください。引き継ぎがない状態そのものも、地図の一部として共有しておくとよいでしょう。自分が契約を終えるときの引き継ぎは契約終了時の引き継ぎの進め方が参考になります。