ここまででプログラミングの基礎を学んだあなたは、プログラムとはどういうものかを何となく理解していることと思います。
最初に購入したテキストのすべてを理解している必要はありませんが、数値を１～１００まで合計するプログラムを書いてみたり、引数で渡された文字列をログに出力したりして、プログラムの動きとコードの書き方を学んできました。
ここからは、実際に現場でプログラムを書く際に必要となるスキルや考え方をお伝えしていきます。
はじめに、実際の仕事の進め方です。
渡された設計書に従ってコードを書くだけだと思ったら大間違いです。実際、コードを書くだけだと思って働いている人は、何年経ってもほとんど成長しません。使える関数が少し増えるぐらいの変化しか見られない人もいます。
それに対して、ここで書くような手順で仕事を丁寧にこなしている人は、どんどん成長していきます。
超スピードで品質の高いコードを仕上げ、おまけに設計の漏れも指摘してどんどん評価を上げていきます。そのままより成長につながるキャリアを築き、夢を叶えるのも早いです。
あなたも変に楽をせず、この手順に従って仕事をする癖を付けましょう。
その方が、結果的には楽をする働き方を手に入れられます。
プログラマーとして求められる役割の範囲
あなたが現場にプログラマーとして参画する場合、最初にSEから作成する機能の概要説明を受けます。そして、詳細設計書と呼ばれる設計図を渡されて、この設計図通りに作ってくださいとお願いされます。
ただし、設計図があるからと安心するのは禁物です。
この設計図は家具の組み立て説明書のように、そのまま作れば良いというものではありません。
詳細設計書は、人が読んで理解できるようにシステムの処理の流れが書かれています。つまり、そのままではプログラムにはなりません。
あなたが、この詳細設計書をシステムが理解できるプログラムに翻訳する必要があります。
そして、翻訳した後には「正しく動作することを保証する」必要もあります。書いたコードをテストし、実際に詳細設計書通りに機能していることを確認して完了です。
成長速度が一気に加速する仕事の進め方
それでは、プログラマーとして成長速度が一気に加速する仕事の進め方をご説明していきます。
どのステップについても詳しくはまた別の記事で説明しますので、ここでは手順だけ理解しておいてください。
Step1. 詳細設計書を詳しく理解する
初めに、詳細設計書の内容を理解することです。
これは当然だと思う方も多いと思いますが、実際の現場でこのステップを丁寧に出来ている人は少ないのが現実です。
「こんなことを聞いたらバカだと思われるから聞かないでおこう」と考えて、大事な確認を怠った結果、プログラムが仕上がった後にすべてを作り直しになる人もたくさんいます。
「よく分からないことを書いてあるけれども、きっとこういう意味だろう」と勝手に解釈した結果、重大なバグとなって経営陣が謝罪することになる場合もあります。
ここで大事なことは、「設計者と自分の頭を合わせる」ことです。用語の意味や想定している状況や前提を丁寧にすり合わせて、以下に齟齬をなくせるかがポイントです。
Step2. フローチャートを作成する
多くの人は、ここでもうプログラムを書き始めます。エディターを開いて、int xxx = …などと書いていくことになるのですが、これが最もやってはいけない誤りの一つです。
ここで、SEとして働くうえで大切な原則を一つお伝えします。
「考えるステップと、行動するステップを、明確に切り分ける」です。
ここでいきなりコーディングし始める人は、考えながら作業をしています。考えるステップと行動するステップを切り分けられていません。だから考えが足りなかった際にコードを書き直すことになったり、途中で設計書に誤りがあると気づいた際に、大きく手戻りする必要が出てきたりします。
それに対して、成長するプログラマーは、まだエディターは開きません。
Excelでも専用ツールでも何でもいいですが、フローチャートを書き始めます。「どのようにコードを書けば、このプログラムを仕上げられるか」を先に考えます。だからコードを書く前に設計書の誤りにも気づけますし、フローチャートを上司にレビューしてもらえば、自分の考えが正しいことを確認することもできます（Step1の再確認にもつながるということです）。
成果物：フローチャート（プログラム仕様書）
Step3. テスト仕様書を作成する
フローチャートを仕上げたら、次はコーディングかと言えば、そうではありません。コードを書き始める前に、単体テスト仕様書を作成します。
先ほどもお伝えした通り、プログラマーは自分が作成したコードが正しく動くことを保証しなければなりません。そのためには、コードをテストして詳細設計書通りに動くことを確認するテストをする必要があります。
単体テスト仕様書とは、このテストで確認する項目を一覧にしたものです。
コードを書く前に単体テスト仕様書を作成する理由は、コードありきでのテストになるのを避けるためです。
たとえば、コードを書き終えてからテストをしようとする場合。
コードのここに複雑な箇所があるから、この点を重点的にテストしようと考えて確認項目を書き出してしまいます。確かに複雑な箇所を重点的にテストすることは大切なことですが、このやり方には「コードが詳細設計書通りに作成されている」という暗黙の前提があります。
それに対してフローチャートをもとに単体テスト仕様書を先に作成していれば、コードをどう書いたとしても、テストで確認することは明確です。フローチャートが正しく仕上がっていれば、詳細設計書通りにコードが書けたかどうかを正確にテストできる方法になります。
そのため、成長するプログラマーはコーディングを開始する前に単体テスト仕様書を作成します。
そして、上司にレビューしてもらってOKが出て初めてコーディングを開始します。
成果物：単体テスト仕様書
Step4. プログラムを作成する
フローチャートと単体テスト仕様書が完成して初めて、コーディングの開始です。
と言っても、コーディングを開始するときにはもうほとんど完成しています。
フローチャートをそのままコードに翻訳すれば完成です。実は、プログラマーの仕事はコードを書き始める前までにほとんど終わっているということです。
逆の言い方をすれば、フローチャートがあるのにコードを書けないのであれば、フローチャートが荒すぎるということになります。
フローチャートは、詳細設計書とプログラムの間をつなぐために作成する資料です。最も粒度の細かいフローチャートは、プログラミング言語で書いていることが日本語で記述されているものです。そのためコーディングは、I have a pen.を、私はペンを持っています。に翻訳するぐらい簡単な作業になります。
エディターを開いてコードを書き始める段階で、すでにあなたの仕事の９０％は完成しています。
このことを覚えておきましょう。
成果物：プログラム
Step5. テストをする
コードが出来上がったら完成というわけではありません。
最初にお伝えした通り、コードが詳細設計書通りに動くことを保証する必要があります。
コードが出来上がったら、単体テスト仕様書に従ってテストをしていきます。
実際は、テストし始める前に、書き上げたコードをもとに単体テスト仕様書を少し修正する時間を取ります。
フローチャートや単体テスト仕様書をいくら用意していても、実際にコードを書き始めたら少し修正が入ったり、思いもよらない分岐が挟まったりして、元の形から変わってしまうことは多々あります。
その場合、通常はフローチャートや単体テスト仕様書に戻って作業を再開するのですが、急いでいると忘れてしまうこともあります。
そのため、ここで一息入れて、単体テスト仕様書に戻るタイミングを作ります。
そして、単体テスト仕様書を修正し終えたらテスト開始です。
単体テスト仕様書には簡単なプログラムでも、数十～数百のテストケースがあります。それらを一つずつ丁寧にテストしていき、想定の結果になっているかを確認していきます。
また、実際の現場ではテストした際の証跡を取るようにと言われることも多いです。
テストケースのNoとそのテストをした時の画面キャプチャやデータの状態を１つずつExcelなどに貼り付けて、どうやってテストしたのか、何を確認したのか、本当に確認ができているのかを第三者が再確認できるようにテストしていきます。
そして、ここも大切なことですが、テスト中にバグが見つかった場合は、それまでテストしてOKだったものもやり直しになる可能性があります。
当然ですが、バグが見つかって修正したときに、修正したことで動きに影響が出た場所は、すべてテストやり直しです。最後にすべてのテストケースがOKとなって初めて、テスト完了となります。
そのため、テストをやる順番やテストデータの用意の仕方は、テスト効率を高めるためには重要なポイントになります。どうすれば品質を下げずにテストのスピードを上げられるか、事前に作成を練る癖をつけることも大切ですね。
成果物：テスト結果、エビデンス（証跡）
このステップで働く人が早く成長できる理由
このステップを見て、自分が今までのプロジェクトで経験してきた順番とは異なると感じた場合は、この手順に沿って一から学び直すことをお勧めします。
それは、このステップで働く人が早く成長できるのには理由があるからです。
たとえば、あなたがとあるプログラムの作成を依頼されたとしましょう。
SEから詳細設計書を渡され、説明を受け、いざ作業開始となって一生懸命プログラムを完成させます。なんとか完成させたプログラムを上司にレビュー依頼したところ、「ここの分岐が足りない」と指摘を受けました。
そして、その後も何度も似たような指摘を受け、修正を重ねてやっとの思いで完了となった頃には、予定の倍近い時間がかかっていたとします。
このとき、あなたは次のコーディングに向けて何をどう修正しますか？
いきなりコードを書き始めて仕上げた場合、分岐の足りなさを指摘された理由が何か分かりますか？
そもそも分岐の存在に気付いていなかったのか、気づいていたがコードに書き漏れたのか。
でもテストでその分岐のケースを確かめていないということは、本当に分岐の存在に気付いていたのか。最終的には分岐を無視してもよいという勝手な判断をしたのかと疑われる始末です。
それに対して、この手順で仕事を進めた場合は、フローチャートにその分岐がなければ、そもそも存在に気付いていなかったことが明確になります。フローチャートにあるのにコードになければ、書き漏れたと言えるかもしれません。
このように、明確な手順があれば、あなたが次何を変更すればより良くなれるのかがはっきりします。
これが、成長速度が一気に上がる理由です。
実際、私が以前関わっていたチームでも、いつまで経っても自己流で仕事をしていた人は３年経っても全然プログラミング力が上がりませんでした。いつまでも同じ指摘をされていますし、たった半年新入社員にすぐに抜かれていきました。
それだけ、この手順には強力な成長力があります。
まとめ
早く成長するためには、素直になることが一番です。
ただコードを書くだけなのに、ここまでやるのは面倒だと思って手を抜けば、それだけあなたの成長は遅くなります。
また、プロジェクトによってはフローチャートや単体テスト仕様書を作成しないというところもあるかもしれません。
もしそのようなプロジェクトに関わることになったとしても、あなただけはこの手順で仕事をしましょう。それによって人より時間がかかることになるかというと、正直それほど変わりません。むしろ早くなる場合もあるぐらいです。
それは、実際どの手順でもやっていることは変わらないからです。ただそこに明確な順番を用意し、失敗しにくいように作業を進めていくことで、結果うまくいく確率を上げようとしているのがこの手順だからです。
そして、慣れてきたら少しずつ手を抜いても大丈夫です。
フローチャートの粒度を少し荒くしたり、もう簡単なプログラムであれば書かなくなったり。
その際でも、フローチャートを考えてからコードを書き始めるという順番は変わりませんから、ただ資料を書かなくなった分だけ早くなります。
慣れれば、ほかの人の半分以下の時間で仕上げられるようにもなるでしょう。この手順は、それぐらい生産性が高まる方法です。マネしない理由はありません。
この手順で考えることに慣れて、ぜひどんどん成長して先輩を追い抜いていってください！
次は、あなたはどのような基準で評価されるのかを見ていきましょう。
