プログラマーの仕事内容は、詳細設計書の作成やプログラミング、単体テストまでが大体の仕事内容ではあります。
ただ、具体的に・・となると、現場でプログラマーとして働いたことのある人しかわかりません。
そこで！元システム開発者の私が、自身の経験談をもとにプログラマーの具体的な仕事内容をお伝えできたらと思います。
プログラマーの具体的な仕事内容
では、早速プログラマーの仕事内容を順番に解説していきますね。
扱っているシステムの概要を理解する
まずは、担当するシステムの概要や仕組みなどを知っておく必要があります。
内部資料等があるはずなので、それらを一読しプロジェクトの目的やどんなシステム開発をするのか？など把握しておきましょう。
1時間程度、資料を一読すれば大体のことはわかるかと思います。
詳細設計書の作成
さて、プログラマーとしての最初の仕事は、「詳細設計書」の作成を行います。
その詳細設計書を作成するために参考とするのが、システムエンジニアの方が書いた「基本設計書」というものです。
現場や自社内には、詳細設計書のフォーマットがありますので、書き方はそちらを参照して作成していきましょう。
第3者が見ても、わかりやすく書いてあることが前提となりますが、最初のうちはわかりやすい文章を書くためには、どうすればいいのか悩むことが多いです。
そこでアドバイスさせて頂くとすると、あなたが現場で働いていて、あの人は仕事が出来るな～と思う人が書いた設計書を参考にしてみましょう！
悩んで聞く前に、見て盗みましょう(笑)
まるごとパクるのは良くありませんが、文章の書き方などを真似ることはオッケーです！ぜひ、仕事が出来ると思った人の設計書を参考にしてみましょう！
詳細設計書のレビュー＆手直し
詳細設計書の作成が完了したら、開発チームのリーダーもしくは基本設計を担当した方とのレビューを行います。
わかりやすい文章が書かれているか？誤字脱字はないか？納品物として適切か？など、チェックを行っていきます。
レビュー者は経験がある方なので、優しい方は、ここは、こうするといいよ～とかここは、こういう書き方をしましょう！
とアドバイスを頂けるはずです。
修正個所があれば、修正をして再レビューする時間があればしますし、なければ、修正完了報告をしておしまいとなります。
アドバイスや指摘など、ここで素直に受け止められる人が、のちのち信頼を得てITエンジニアとしてステップアップしていける人です。
指摘されて、ふてくされるような態度をとると・・・良い事はありませんので、素直に受け入れましょうね。
プログラミング
作成した詳細設計書をもとに、実際にプログラミングを行います。
私が、新人時代に上司や先輩から言われたことは、
「誰が見ても、編集しやすいようわかりやすく書きなさい」
ということです。
それは、適度にコメントを入れて、どんな処理をしているのか？を付け加えたり、また、改行を入れることで、スマートで見栄えの良いプログラムソースコードにすることです。
仮に、あなたが作成したあとに、仕様変更が起きたり、あなたのプログラムソースが障害の原因となった場合、必ずしも自分が修正するとは限りません。
そういったことも考えて、誰が修正しても見やすいプログラムソースを書くよう心掛けてくださいね。
さて、ほとんどの方は、プログラミングをするとき、テキストファイルに書き込んでいくと思いますが、開発者それぞれ使いやすいテキストエディタはあるかと思います。特にこれがおすすめ！ってのはありませんが、私がよく使っていたのは、
「Terapad(テラパッド)」という無料のテキストエディタです。
もし、現場で指定ソフトがなければ、誰かに使いやすいエディタを教えてもらったりするのも良いでしょう。
コンパイル
記述したソースコードが、正しい記述をしているかチェックをします。
プログラミング言語によりけりなので、コンパイルソフトがあれば、この作業が発生します。
扱う言語によりけりで、私が当時扱っていたPL/SQLという言語は、コンパイルの作業が発生します。
私の場合は、オブジェクトブラウザーと言うソフトがありましたので、これを使ってコンパイルを行っていました。
無事にコンパイル完了なら、プログラムソースコードレビューを行います。
プログラムソースコードレビュー
開発プロジェクトのスケジュールに余裕があればですが、ソースコードのレビューを行うときもあります。
忙しいとそんな暇はないので、スルーするのがほとんどです。
経験者の場合はほとんど、レビューしません(笑)
新人プログラマーの場合は、同じ会社の先輩がソースをチェックしてくれるかもしれません。
指摘を受けたら、早速修正を行いましょう。
単体テスト計画書の作成
作成したプログラムソースコードが、正しく動作するかを検証するわけですが、その前に検証の計画を立てます。
その際に、単体テスト計画書という文書を作成するのですが、書き方についてはこちらの記事にまとめてありますので、ご参考にしてみてください。
↓単体テスト計画書の書き方を見てみる↓
システム開発時の単体テスト仕様書の書き方～ポイントは？
フォーマットは、これもプロジェクトによって用意されていますから、ルールを守って作成していきましょう！
単体テスト計画書のレビュー
単体テスト計画書の作成が完成したら、詳細設計書と同じくリーダーの方などにレビューを行ってもらいます。
検証パターンに漏れがあったり指摘を受けた場合は、素直に受け止めて修正をしましょう。
単体テストに使用するデータ作成
さて、レビューが完了したら、実際にテストを行う前に、単体テストに使用するデータを作成します。
作成したプログラムや設計書を見ながら、データパターンを考慮して作成します。
どういうデータを作ればいいのかどうかは、単体テスト計画書にパターン表みたいなものを別紙で作っておくと良いですね。
そうしておくことで、迷うことなくデータ作成の作業が行えるし、効率よく作業を行うことが出来るからです。
単体テストの実施
さて、実際にテストデータを作成し終えたら、いよいよ自分が作成したプログラムの検証を行います！
想定通りの結果になっているか自分の目で確かめ、確認を行っていきます。
テスト計画書には、想定している結果を記述していると思います。
思い通りの結果になったかどうか、その目で確認しましょう。
単体テスト結果のまとめ
最後は、テスト結果のまとめを行います。
テストを実施し画面ショットなどのエビデンスをとりながら単体テストの報告書を作ります。
※エビデンスは、証拠という意味合いを持っています。
テスト結果を何か出力ファイル等で確認する場合は、そのファイルをエクセルにそのまま貼り付けたりしてエビデンスとして残します。
やり方は、現場によって多少異なると思うので、既存の成果物などを参考にしながらまとめていきましょう。
単体テストレビュー
さて、単体検証と結果のまとめが完了しますと、それらのレビューを行います。
忙しい場合は、それをすっ飛ばして次の作業に移ることがありますが、たいがいは、リーダーさんなどとレビューを行い、漏れがないか？
このまま次の作業に進んで大丈夫か？など、確認をしながら行います。
この時、検証パターンに漏れがあったり、不足があった場合は、再度単体検証をやり直す場合もあります。
面倒ですが、この単体検証をしっかりやっておかないと、後の総合検証で障害となる可能性があります。
もし、総合検証であなたが作ったプログラムを修正することになった場合・・・とんでもない手戻りが発生するので、非常に面倒です笑
そうならないためにも、単体検証はしっかりやっておくことをおすすめしますよ！
その他雑用
これら以外にも、雑用があります＾＾；
例えば、
・内部資料の作成
・メールの返信
・システム調査
エクセルやパワーポイントで資料を作成したり、チーム内や顧客とのメール・電話のやりとりもあります
また、何かソフトウェアを使っている場合、そのソフトの機能調査をすることもあります。
単体テスト完了後
単体テストが完了し、開発がある程度完了になると、次に結合テストやシステムの総合検証といった工程に入ります。
プログラマーの方は、どういった作業の割り当てになるかは、プロジェクトによって異なりますが、データを準備したりテスト仕様書を作成したり、はたまた実際に検証を実施する作業を担当するかもしれません。
まとめ
プログラマーのイメージは、プログラミングだけしている。というものがあったかもしれません。
しかし実際には、単にプログラミングをするわけではなく、他にやることがたくさんある。ということが、おわかりになりましたでしょうか？
ほとんどプログラミングではなく、資料(設計書や計画書)の作成やテスト実施の方が仕事量としては多いです(笑)
それでもプログラマーをやる理由としては、プログラミング後、実際に動作検証をしたときに、想定通りに動いたときの達成感や充実感があるからなんですよね！
