「プログラマーとは」というキーワードで検索してみても、具体的な内容が書かれていない事が多いようです。
ITブームでプログラマー不足だから就職しやすいとか、手に職が就くとか、フリーになったら高収入が期待できるとか、メリット中心の記事が多く、プログラマーになったらどんな風に働くのか、具体的なイメージがしずらいのではないでしょうか。
この記事では、プログラマーになったらどんな風に仕事をこなしていくのかについて、現場視点で解説したいと思います。
プログラマーとは
プログラマーは、「決められた仕様を実現するためのプログラムを、指定された条件のもとで開発」するという職業です。
決められた仕様とは、お客様と合意したソフトウェアの機能や振る舞い（動作）を意味します。
また、指定された条件下とは、
- QCD（ソフトウェア品質、開発費用、開発期間、納期）
- プログラミング言語（Java、C#、Python、Ruby、PHPなど）
- 動作環境（パソコン、サーバ、スマートフォン、タブレット、組み込み機器など）
- プログラムの開発環境（Eclips、VisualStudio、UNITY、UNREAL、Android Studioなど）
- 外部リソースとの連携（データベース、通信方式、データフォーマットなど）
- プログラミングのルール（フレームワーク、コーディングルールなど）
などが該当します。
また、他人と関わらず一人でコツコツと仕事をするようなイメージもありますが、決してそんなことはありません。
開発する内容にもよりますが、複数のプログラマーがチームとして、お互いにコミニュケーションを取りながら進める事の方が多いです。
案件とプロジェクト
プログラマーの具体的な話をする前に、２つだけ覚えて頂きたいキーワードがあります。
１つは案件、１つはプロジェクトです。
案件とは、お客様から発注して頂いた「ひとまとまりの仕事」のことで、「開発案件」とか「受注案件」という言い方をします。
プロジェクトとは、その案件を担当するために一時的に作られた組織、またはその仕事そのものを指します。
規模にもよりますが、通常は１つの案件に対して１つのプロジェクトが立ち上がり、プロジェクトマネージャーを筆頭に、プロジェクトリーダー、システムエンジニア、プログラマーの他、営業担当や事務処理担当、テスト担当など、必要に応じて様々な役割を持つ人員が投入されます。
規模が小さければ、役割は兼任する形で進められます。
プロジェクトの進め方とプログラマの作業範囲
プロジェクトの組織はピラミッド型になっており、複数の工程（＝フェーズ）で構成されています。
開発方法として昔からあるウォーターフォール型（最初に制作物の仕様を決めて、必要なフェーズを設定し、１つづつ確認しながら開発を進めている手法）とアジャイル型（設計～製造を１つのサイクルとし、これを何度も繰り返しながら、最小限の機能から段階的に仕上げていく手法）の2通りの方法がありますが、ここでは一般的によく使われているウォーターフォール型を前提に解説します。
次の図がプロジェクトのフェーズで、要件定義～納品までが業務の流れになります。
お客様との契約によっては、開発物の納品後においても、お客様が滞りなく使っていただくためのフォロー作業であったり、納品後に発覚したバグの修正、或いは機能追加や機能変更などの保守作業が発生しますが、ここでは割愛しています。
プロジェクトの規模やプロジェクトの方針によっては、例えば基本設計と詳細設計が合体していたり、総合テストが省略されている場合があり、またプログラマーの作業範囲についても、詳細設計もプログラマーの範囲とするケースや、応援で基本設計や結合以降のテスト、納品に携わることもあります。
とはいえ、多くの場合は赤字の部分がプログラマーの業務範囲と考えて良いでしょう。
実際の仕事の進め方
多くの場合、複数のプロジェクトが同時並行で進められています。
入社後の一通りの研修（会社によって数日～数カ月）を終えると、何らかのプロジェクトに参加することになります。
ここでは、プログラマーがどんな仕事をこなしているかについて、順を追ってご紹介しましょう。
プロジェクトで最初にすること
まず、そのプロジェクトを担当するSE（システムエンジニア）、あるいは会社の先輩からプロジェクトの概要と、仕事の進め方（ルール）についてレクチャーを受けます。
次に、プロジェクトの作業スケジュールとWBS（Work Breakdown Structure=作業分解図）、そして自分が担当する部分の設計書（詳細設計）が渡され、詳細な説明を受ける事になります。
プロジェクトによっては、事前にこれらの資料を渡されて、一通り目を通してから詳細な説明を受ける場合もありますが、いずれにせよ自分が開発する内容と納期については、ここでしっかり把握し、合意することになります。
合意したら、必ず納期は守らなければなりません。
特に火のついたプロジェクトに参加した際は、残業は当たり前で終電まで仕事を行い、場合によっては徹夜する羽目になることも珍しくありません。
ブラックな会社だと、「残業は君の生産性が低いから」とか「スキルアップのための勉強だから」などと言って、残業代を削られることも多々あります。
昔は大手企業にもそういう風潮がありましたが、今ではコンプライアンスが重視されるため、さすがにそれは無くなりました。
でも、中小のソフトウェアハウスの中にはブラック企業も数多く含まれていますので、入社時にはよ～くチェックしておきましょう。
仕事が始まったら（1日の作業）
それでは、プログラマーの1日のルーチンについて解説します。
但し、あくまでも一例であることはご了承下さい。
プロジェクトの規模やプロジェクトリーダーの考え方、開発する業種や会社の風土によっても異なりますので、一般的な話として捉えて頂ければと思います。
朝夕の進捗会議
プロジェクトの方針によりますが、多くの場合は朝、夕方、もしくは両方に進捗会議なるものを行います。
「進捗」とは、仕事の進み具合のことを言います。
朝は「朝会」、夕方は「夕会」とも呼ばれますが、15分～30分くらいの短い会議で、そこで各自の進捗や発生した問題がメンバーに共有されます。
「朝会」「夕会」を通して、プロジェクトのQCD（品質、納期、コスト）の妨げになる要因をいち早く見つけ、解決するためのものです。
分からない事や誰かに手伝ってもらいたい事などを相談する場でもあるので、プロジェクトの規模が大きいほど重要視されます。
プログラミング
進捗会議が終わると、各自自分の担当する部分のプログラミング（＝コーディング）を行います。
この部分はモニタに向かってコツコツとコードを書いていくので、地道な作業となります。
プログラミング経験が浅く、プロジェクトにも人員的に余裕がある場合は、ペアプログラミングという方法を行う事もあります。
ペアプログラミングとは、2人で１つのプログラムを書いていく方法です。
先輩やベテランが書いたプログラムに直接触れることで、プログラミングのスキルが上がるというメリットがありますが、実際の現場でペアプログラミングを行うケースはごく稀です。
単体テスト
自分が作ったプログラムが意図した通りに動作するかどうかをテストする作業が単体テストです。
単体テストはプログラムの中身を知っている事が前提のテストで、全ての分岐文（if文）を通るようなテストデータや、判定条件を意識したテストデータを入力して、エラーが無いか、正しく動作するかを確認します。
通常はテスト内容と期待される結果を一覧にまとめた「テスト項目書」又は「テスト項目書兼成績書」と呼ばれるものを用意し、テストした結果を○×で記載していきます。
単体テストで見つけられなかったバグは「単体テスト漏れ」と呼ばれ、SEが担当する結合テストで発覚することになるため、プログラマーの力量が問われます。
とはいえ、コーディングに比べて単体テストは地味で面倒な作業であるため、「コーディングは好きだがテストは嫌い」というプログラマーが大多数です。
コードレビュー
ある程度の規模（数十人～数百人）になると、作成したプログラムについて、プロジェクトのメンバーからコードレビュー（ソースコードに抜けや漏れはないか、設計書通りに記載されているか、コーディングルールに沿っているかなどのチェック）を受けることがあります。
全てのプログラムをレビューするケースもありますが、重要なプログラムのみとか、新人プログラマーもしくは品質に問題がある（単体テスト漏れが多い）プログラマーに限定して実施する事もよく行われます。
バグ修正
単体テストで見つかったバグは他人の目にさらされる前に修正することになるので、自分一人の世界で完結します。
しかし、SEが行う結合テストで見つかったバグは、「バグ修正指示」として、プログラムを書いたプログラマー本人に連絡が来ます。
プログラマーは１つのプロジェクトが完全に終了するのを待たずに、次のプロジェクトに投入されます。
プログラマーが作成したプログラムをSEがテストしている間、プログラマーは待ち状態になります。
ただ待っているだけだとプロジェクトの採算が悪化するだけなので、通常は仕事の空きを作らないように、別作業もしくは別プロジェクトに投入され、掛け持ちで作業すること強いられます。
バグ修正は最優先ですが、別プロジェクトにも納期があるため、両方の作業がいっぺんに来るとパニックになります。
こういうことは多々起こり得るため、単体テストでしっかりバグをつぶしておくことが、プログラマーとしての地位を高め、人から信頼され、且つ後々のフェーズで楽に（バグで作業の横やりが入らないように）仕事を進めるためのポイントと言えるでしょう。
入社後の研修について
入社後に研修があるかどうかについては、気になるところでしょう。
これについては、会社によって様々です。
私が所属する会社では、3カ月～半年は新人研修としてカリキュラムが組まれます。
その後、配属されても半年～年間ほどOJT（On The Job Training）で仕事を覚えていきます。
数十人規模の会社になると、そこまで新人教育する余力はない場合が多いので、派遣先の研修に参加させてもらうような場合もあります。
まとめ
いかがでしたでしょうか。
あくまでも一例ですが、プログラマーの仕事がどんなものか、イメージして頂けたでしょうか。
プログラマーは一人で完結することはほとんどなく、チームの一員としてチームメンバーと関わりながら仕事を進めていきます。
朝と夕方の進捗会議だけでなく、要所要所で担当SEと打合せしたり、時には顧客と直接話をすることもあります。
プログラマーと言えどもコミニュケーション力は大切なスキルなのです。
そして、コーディングの後はテストという地味で面倒な作業が必ず発生し、またプログラム開発と並行してバグ修正にも対応しなければならないなど、作業の調整力も必要となってきます。
この辺のことはあまり書かれていなかったので、今回記事にしてみました。
プログラマーを目指す方にとっての参考になれば幸いです。