PG専任の場合
プログラミング（コーディング）が主な業務の場合のガイドです。設計書を読んで実装し、コードレビューで学ぶサイクルが日々の仕事になります。
この役割の特徴
PG（プログラマー）専任とは、設計書を受け取ってコーディングを進める役割です。
- 設計書を読んで実装する：自分で設計を考えるのではなく、与えられた要件・設計に基づいてコードを書く
- コーディングと単体テストが主な業務：実装と「自分が書いたコードの動作確認」に時間を使う
- コードレビューを受ける機会が多い：先輩から指摘をもらうことで、スキルアップの機会がある
よくある1日の流れ
毎日の活動パターンを図で見てみましょう。
flowchart LR
A[9:00
朝会] --> B[9:30
実装作業]
B --> C[12:00
昼休み]
C --> D[13:00
実装作業]
D --> E[15:00
レビュー対応]
E --> F[17:00
進捗報告]
F --> G[18:00
退勤]
朝は進捗確認、午前中に集中して実装、午後はレビュー対応と進捗報告が主な活動です。以下はより詳しいタイムスケジュール例です。
| 時間 | 活動 | 詳細 |
|---|---|---|
| 9:00 | 朝会 | 今日の予定を共有、困っていることがあれば相談 |
| 9:30 | 実装作業 | 設計書を確認しながらコーディング |
| 10:30 | 動作確認 | 作った機能の動作確認、単体テスト |
| 12:00 | 昼休み | ─ |
| 13:00 | 実装作業 | 午前の続き、または別タスク |
| 15:00 | レビュー対応 | PRへの指摘対応、または他の人のPRを読む |
| 16:00 | 質問・相談 | 詰まったことを先輩に確認 |
| 17:00 | 進捗報告 | 今日の成果と明日の予定を報告 |
| 17:30 | 翌日の準備 | 明日やることを整理、メモを残す |
| 18:00 | 退勤 | ─ |
ポイント
「実装→動作確認→実装→動作確認」のサイクルを細かく回すことで、問題を早期発見できます。
最初の1ヶ月で覚えること
第1週：環境に慣れる
最初の1週間は、開発環境や基本的なツール操作に慣れることが目標です。
| やること | 完了の目安 |
|---|---|
| 開発環境構築 | ローカルでアプリが動く |
| Gitの基本操作 | clone、commit、push、PRが作れる |
| コーディング規約の確認 | 規約ドキュメントを一読 |
| 既存コードを読む | 主要なクラスの役割を把握 |
第2週：小さなタスクをこなす
環境構築が済んだら、簡単なバグ修正や小さな機能でコーディングの流れをつかみます。
| やること | 完了の目安 |
|---|---|
| 簡単なバグ修正 | 1件完了してレビュー通過 |
| 単体テストを書く | テストコードを1つ書いてみる |
| レビュー指摘の対応 | 指摘内容を理解して修正 |
第3〜4週：実装力をつける
簡単なタスクで流れが分かったら、少し複雑な機能に取り組み始めます。
| やること | 完了の目安 |
|---|---|
| 小さな機能追加 | 設計書を読んで実装完了 |
| デバッグの実践 | デバッガを使ってバグを特定できる |
| コードレビューへの慣れ | 指摘を「学び」として受け止められる |
1ヶ月後の目標状態
1ヶ月を通じて、以下の4つの能力を身につけることを目指します。
flowchart TB
A[1ヶ月後の目標] --> B[設計書を読んで実装できる]
A --> C[分からないことを質問できる]
A --> D[レビュー指摘に対応できる]
A --> E[Gitの基本操作ができる]
この経験で身につくスキル
PG専任での経験を通じて、以下のスキルが身につきます。
技術スキル
| スキル | 説明 |
|---|---|
| コーディング力 | 設計を読み解き、動くコードに落とし込む力 |
| デバッグ力 | 問題の原因を特定し、修正する力 |
| テスト力 | 自分のコードが正しく動くことを確認する力 |
| コードリーディング力 | 既存コードを読んで理解する力 |
| ツール活用力 | IDE、Git、デバッガなど開発ツールを使いこなす力 |
ビジネススキル
| スキル | 説明 |
|---|---|
| 正確性 | 仕様通りに実装する力 |
| 報告力 | 進捗や課題を適切に伝える力 |
| 受容力 | フィードバックを素直に受け止める力 |
目指せる人材像
PG専任としてスキルを磨いていくと、その後のキャリアパスはいくつかあります。
flowchart TB
A[PG専任からのキャリア] --> B[シニアプログラマー]
A --> C[テックリード]
A --> D[設計者・SE]
A --> E[スペシャリスト]
B --> B1[後輩の指導ができる]
C --> C1[技術的な方針を決められる]
D --> D1[設計から実装まで担当]
E --> E1[特定技術の専門家]
次の表は、各キャリアパスの目安期間と説明です。
| 人材像 | 説明 | 目安期間 |
|---|---|---|
| 一人前のPG | 一人で機能を実装できる | 1〜2年 |
| シニアPG | 後輩指導、難しい実装を担当 | 3〜5年 |
| テックリード | 技術選定やアーキテクチャ判断 | 5年〜 |
成長を感じられるポイント
あなたが成長しているかは、以下のチェックリストで自己評価できます。各時期で「できるようになったこと」を意識することで、モチベーションにつながります。
3ヶ月後
- [ ] 簡単なタスクを一人で完了できるようになる
- [ ] レビュー指摘が減ってくる
- [ ] デバッグで原因を見つけられるようになる
6ヶ月後
- [ ] 設計書を読んでスムーズに実装できる
- [ ] 他の人のPRをレビューして意見を言える
- [ ] 「この実装ならこう書く」という自分のスタイルができる
1年後
- [ ] 機能単位で任せてもらえる
- [ ] 新人に教えられることがある
- [ ] 技術的な議論に参加できる
成長のサイン
「以前は分からなかったコードが読めるようになった」「レビュー指摘の意図が分かるようになった」と感じたら、確実に成長しています。
本編で特に重要な章
このカリキュラムの他の章のなかで、PG専任として特に参考になるものを挙げます。
| 章 | 重要度 | 理由 |
|---|---|---|
| コードを読む基礎 | ★★★ | 日常業務で必須 |
| デバッグの基本 | ★★★ | 問題解決に必須 |
| 実装の進め方 | ★★★ | 効率的な実装のために |
| Step8: コードレビューの受け方 | ★★★ | 品質向上と成長のために |
| 設計書・仕様書の読み方 | ★★☆ | 正しく実装するために |
追加で学ぶと良いこと
PG専任としてのキャリアを深掘りするために、追加で学習すると良いテーマがあります。優先度に分けて紹介します。
優先度：高
| 内容 | 説明 | 学習方法 |
|---|---|---|
| リーダブルコード | 読みやすいコードの書き方 | 書籍「リーダブルコード」 |
| ユニットテスト | 自動テストの書き方 | 言語別のテストフレームワーク |
| デザインパターン入門 | よく使うパターン | ステップアップガイド |
優先度：中
| 内容 | 説明 | 学習方法 |
|---|---|---|
| リファクタリング | コードの改善方法 | 書籍「リファクタリング」 |
| SOLID原則 | 設計の基本原則 | ステップアップガイド |
| コードレビューの仕方 | レビューする側の観点 | 実践で学ぶ |
よくある悩みと対処法
PG専任として働く中で、多くの新人が同じような悩みにぶつかります。各悩みに対する対処法を、アコーディオンで確認できます。
「設計書の意図が分からない」
- まず自分なりに解釈してみる：わからないまま質問するより、一度は自分で考察する
- 「〇〇という理解で合っていますか？」と確認：曖昧な質問ではなく、自分の理解を示しながら質問する
- 遠慮せず質問する：30分以上迷ったら、相談するタイミング。先輩はそれを想定しています
「コードレビューが怖い」
- 指摘は「コード」へのフィードバック：あなたの人格や能力を否定しているわけではありません
- 学びの機会と捉える：「これで成長できる」というマインドセットを持つ
- 同じ指摘を繰り返さないようメモする：指摘内容をメモして、次回から同じミスを避ける習慣をつける
「自分のコードに自信がない」
- 最初は当然のこと：全員がこの段階を経て成長しています
- 先輩のコードを参考にする：良いコード例を意識的に学んで、自分のスタイルを形作る
- レビューを通じて改善する：指摘を受けるたびに少しずつ改善していく。1年後には大きな差になります
「進捗が遅い気がする」
- 最初は遅くて正常です：環境整備、既存コード理解に時間がかかるのは当然
- 小さな改善を積み重ねる：「前より良くなった」を意識する。一度に完璧を目指さない
- 先輩に相談する：効率的な進め方のコツを教えてもらう。プロのやり方を学ぶことで、スピードが大きく改善します
成長のためのアドバイス
PG専任として1年間で大きく成長するための、実践的なアドバイスを紹介します。
コードを読む時間を作る
コーディング以上に「読む」ことが重要です。
- 先輩のコードを読んで学ぶ：設計や実装パターンの「プロのやり方」を体で覚える
- オープンソースのコードを読む：業界標準の実装パターンに触れる
- 良いコードのパターンを吸収する：「なぜこう書くのか」を意識的に分析する
小さな改善を積み重ねる
最初から完璧を目指す必要はありません。
- 「前より良くなった」を意識する：昨日の自分と今日の自分を比較して、成長を実感する
- 一度に完璧を目指さない：「今月はテストコードを書く習慣をつける」というように、1つずつ改善する
- フィードバックを活かす：レビュー指摘を次のコード作成に反映させる。その繰り返しが成長につながります
技術的な興味を持つ
仕事として与えられたコードを書くだけではなく、技術への好奇心を持つことが長期的な成長につながります。
- 「なぜこう書くのか」を考える：表面的に理解するのではなく、背景にある考え方を学ぶ
- 新しい技術に触れてみる：仕事の延長で、新しいライブラリやツール、言語機能を試す
- 勉強会や技術記事を読む：業界動向や最新のベストプラクティスに目を向ける。同期と情報交換する場にもなります