【ライバルに差をつける】プログラミングを行う順序【急がば回れ】

記事を書いているのは2020年3月。4月から新社会人になられる皆さま。就職おめでとうございます。新社会人の方の中には仕事で使うプログラムを初めてつくられる方も多いのではないでしょうか。

「どうやれば効率的にプログラミングできるだろう」「どういうところでライバルと差がつくのか」 「そもそも良いプログラム・悪いプログラムとはどんなものなんだ・・・」

こういった疑問に挫折および成功経験ともに豊富な現役SEがお答えします。

読者の方への前置きメッセージ

本記事はプログラミングをこれから本格的に始めるうえで「ライバルに差をつけるプログラミング方法を知りたい」と考えていらっしゃる方に向けて書いています。

この記事を読むことで、「効率的なプログラミング順序、 陥りやすいはまりパターン、良いプログラム・悪いプログラム」をイメージできるようになると思います。

学生の頃からプログラミングはしていたものの、新社会人として私が経験した激しい挫折。その後、戦力として認められるまでに私がしてしまったものすごい遠回り。プログラミングで私と同じ失敗をしてほしくない。これからプログラムを本格的にはじめる方に最短ルートでレベルアップしていただきたい。という熱い気持ちを込めて記事を執筆します。

本記事のテーマ

ライバルに差をつけるプログラミングを行う順序

1. 背景把握：どこで使われるプログラムなのか・どういうことを期待されているのかを把握する
2. 仕様確認：プログラム作成依頼者に仕様を確認する
3. 名前決定：すべての登場人物に名前をつける
4. フローチャート作成：プログラムの流れを整理する
5. 単体テスト作成：想定されるプログラム実行時の結果パターンをすべて洗い出す
6. ヘッダ作成：プログラミング開始時に一番最初にやること
7. コメントブロック作成：フローチャートに従った形でコメントブロックを作成する
8. 正常系フロー作成：プログラムが期待した通りに動いたパターンをまず作成
9. 異常系フロー作成：単体テストで洗い出した異常系の流れをすべて作成
10. 単体テスト実施：プログラミングと同じかそれ以上の時間をかける

記事の信頼性

記事を書いている私は、プログラミング歴30年ほど。
現在フリーの現役SEです。
(プログラム作成・テスト仕様書作成・結合テスト担当・プログラム仕様書作成等、プログラム作成現場の仕事経験も豊富です。)

それでは、さっそく見ていきましょう。

1. 背景把握：どこで使われるプログラムなのか・どういうことを期待されているのかを把握する

プログラム作成を依頼されたときに、プログラム作成をいきなりはじめてしまう。気持ちは非常にわかります。私自身社会人になって最初そうでした。しかしながらこの手順で作られたプログラムは必ず破綻します。

理由はいくつかあります。たとえばプログラム作成を依頼した方自身、基本的にそのプログラムを使うことで起きる結果をすべて把握しているわけではありませんし、すでにもうあるプログラムやシステムとの関係性についてすべてを理解されていないこともあり得ます。

ですので、 プログラム仕様書が無い場合・仕様書に不明点がある場合・プログラム作成の背景や利用される個所についての記載がない場合は特に、閲覧可能な資料(システムの一部のプログラムを作る場合にはシステムの基本仕様書のレベルから！)をすべて読み込んでください。自分で理解できる部分・プログラムの目的の中で想像できる部分できない部分を必ず把握しておきましょう。

プログラム作成を依頼した方は基本的に多忙です。ご自身が忙しいのであなたにプログラミングを依頼しています。「資料を読めばわかるのに」という内容を聞かれるのは正直苦痛だと思います。

お互いが気持ちよく仕事をするためには、まず自身が最善を尽くすべき、と私は考えます。

2.仕様確認：プログラム作成依頼者に仕様を確認する

前章で把握した内容をもとに、プログラム作成を依頼した方とよく話し、プログラムの仕様を確認してから作成に取り掛かりましょう。(この作業は「仕様を握る」とよく言われます。)

プログラム作成を依頼した方の話をよく聞いてみると、そもそもそのプログラム自体不要である、とかそのプログラムを利用することによって事態がより悪化する。というのもよくある話だったりします。

もちろん、いろいろ問題点を指摘しすぎて何も手を動かさないのは最悪ですが、明らかに無駄な作業を行うのもまた避けるべきです。

入社3年目からのツボ　仕事でいちばん大事なことを今から話そう [ 森 憲一 ] 価格：1540円（税込、送料無料) (2020/3/16時点)

3.名前決定：すべての登場人物に名前をつける

プログラムの中には登場人物(プログラムに関連する情報)が何人か必ず出てきます。

• 入力ファイル
• 入力フォルダ
• 出力ファイル
• 出力フォルダ
• リストファイル
• 引数

などが、代表的な例です。これらに名前がついている場合にはそれを。ついていない場合には自分で名前をつけてまとめておきます。これを早い段階で行うことで自身、プログラム作成を依頼した方ともに混乱することがなくなり、プログラミング効率が圧倒的にあがります。

4.フローチャート作成：プログラムの流れを整理する

家を建てるときは必ず設計書を作成します。プログラムも同じです。ただ、家と違ってプログラムは「プログラムを作る人と設計書を作成する人が 基本的に同じ」です。

手順書なしにプログラムを作るのは、実は熟練者になればある程度可能ではありますが、設計図なしに家を建てるのと同じ難易度だと思ってください。

設計図はフローチャートではなくても必ずしも構いませんが、会社など組織で特に決められたフォーマットのものが無い場合にはやはりフローチャートが汎用的でおススメです。

5.単体テスト作成：想定されるプログラム実行時の結果パターンをすべて洗い出す

単体テスト作成のタイミングは意見がわかれるところかもしれませんが、私はこのタイミングがいいと考えています。

なぜかというと、プログラミング中に実行結果が意図したものであるか確認するときに非常に便利だから。フローチャートのほかに単体テスト書があると、プログラミング中考える事が大幅に減ります。

プログラミングなど集中した作業時、他のことで頭を使うと大幅に効率が下がります。

それを避けるためにも、あらかじめ考えることをまとめておき必要な時に参照できる様にしておくのは他でも利用できる汎用的な手法です。

6. ヘッダ作成：プログラミング開始時に一番最初にやること

これもサボりたくなるところなのはわかります。が必ずプログラム作成開始のタイミングでヘッダを書いてください。これは絶対です。このタイミングでヘッダを書かないと永遠に書かれない可能性が高いです。あとから「このプログラムどんなものだったっけ？いつ作られたものだったっけ？誰が作ったものだったっけ？いつ更新されたものだったけ？」となり、メンテナンスを行うときにヘッダを書く時の数倍、下手すると数百倍の苦労をすることになります。

繰り返します。 必ずプログラム作成開始のタイミングでヘッダを書いてください。

7. コメントブロック作成：フローチャートに従った形でコメントブロックを作成する

フローチャートの中には プログラム中の処理をあらわす長方形のブロックが何個かあります。これごとにコメントブロックを作成すれば基本的にOKです。プログラム作成の初期段階でコメントブロックを書いておくことで、具体的なプログラムコードを書いている最中に「私はいまどこの部分をつくっているんだっけ・・・？」となることがなくなります。

以前の章でも記載しておりますので、繰り返しになりますが、あらかじめ考えることをまとめておき、必要な時に参照できる様にしておくのは他でも利用できる汎用的な手法です。

8. 正常系フロー作成：プログラムが期待した通りに動いたパターンをまず作成

これも意見がわかれるところかもしれませんが、私は正常系を作りきるのがいいと考えています。

正常系だけでも作り切れば、プログラミング中に一つの目的を達成したことになります。これによって精神的な余裕ができるはずです。

精神的な余裕は非常に大きいです。余裕ができることで普段は気づかないポイントを見つけることができる場合もあります。見つけた情報を関係者に共有・連携することで大きく評価をあげることができるでしょう。逆に余裕がない場合に普段ではありえない様なミスが発生します。

ミスをすると怒られます。基本楽しくプログラミングをしたいものです。

9. 異常系フロー作成：単体テストで洗い出した異常系の流れをすべて作成

ここまでくれば完成はもうすぐ。戻り値などの関係で異常系に流すときに思った通り行かないときに、頭を悩ますことがある程度です。

個人的には、こういう「どうすれば思った通りに動く様になるか」を考える時間が好きです。が、プログラミングを始めたての頃は「思った通りに動かない。どうしよう。」となるのが普通でしょう。

ここでも「まあ正常系はできてるからな」と思えば、精神的な余裕になるかもしれません。

10. 単体テスト実施：プログラミングと同じかそれ以上の時間をかける

テスト環境の準備を含めると単体テストは思ったより時間がかかるものです。 プログラム作成を依頼した方から「～までにプログラムをつくってほしい」と言われた期限までに単体テストまで終わっている必要がありますが、半分以上の時間を単体テスト用にまわしましょう。

こうすることで、遅くともプログラミング自体が期間までの半分を超えそうであれば、そこで SOS をあげられます。

期限直前に「プログラム完成できません」とプログラム作成を依頼した方が言われたら卒倒してしまうかもしれませんが、期限まであと半分あればなんとかリカバリーできる案が出てくることもあり得ます。

みんながハッピーになる様にやっていきたいですよね。それでは、皆様にとってよきプログラミング生活を！

というわけで以上です。
質問はTwitterからお受けします。お気軽にどうぞ。
» くらやす＠子どもIT教育スペシャリスト (@kurayasukigyou) | Twitter