Chapter 02

プログラムを作る前に

nobuhito
nobuhito
2022.03.06に更新

プログラムはなんのために導入するのだろう

プログラムを作る前に、まず初めに情報システム部にとって「プログラムはなんのために導入するのだろう」ということを考えてみます。

情報システム部には日々色々な要望が上がってくるでしょう。また、もしかしたら情報システム部からいろいろ提案することもあるでしょう。

それらの課題を解決するのが、「プログラムを導入」こととなります(もちろんプログラムを導入せずに解決できる課題もあります)。
新しくプログラムを導入する場合は「新しくプログラムを作る」「プログラムを購入する」という 2 つの選択肢がありますが、どちらにも費用が発生します。

情報システム部を含むバックエンド側の業務は直接お金を産みません。ですが、直接お金を産むフロント側の要望やこちらからの提案を通して間接的にお金を産むことはできます。

大事なことは、要望や提案を適切な方法で解決し、会社全体の利益につなげていくことです。
そう考えるとプログラムを作ったり購入するという業務は、会社の利益になる(ならなければいけない)ということになります。

プログラムを作るということはどういうことだろう

次に「プログラムを作ると言うことはどういうことだろう」というところを考えてみます。

まず「プロムラムを作る」と「コードを書く」ということは、似ているようですが対象範囲が違います。

モノを作るとは、なんらかの完成品が出来上がるということです。完成品は完成しているから完成品なので、完成品を完成品と呼ぶからには完成したという基準が必要となります。
そう考えると、その完成度を測るためには設計図が必要となり、設計図どおりに作られていると納得できればそれは完成したと呼べようになります。
プログラムにとって設計図は仕様書であり、設計図通りに作られているかどうかを測る行為がテストとなるわけです。

簡単なプログラムであれば仕様書がなくても作り始めることは可能ですが、何らかの要望があって作り始めるのであれば仕様書はあったほうが良いでしょう。「作るほうが要望を理解できているか」という目安にもなりますし、完成のイメージについて依頼側との認識合わせにもなります。

そしてその仕様書に合わせて作る実際のプログラムコードについてですが、案件の内容だったり規模だったり作成側のスキルだったりで相当変わってしまうのが現実です。ですが、現代的なプログラム作法を覚えることで、完成品の動作についてはそれほど差が出るものではなくなってきています。

誰が作成しても完成品を一定のレベルに保つための有効な方法が、コードのレビューとテストになります。ですが、そのレビューやテストのためには仕様書が必要となるところは理解しておきましょう。逆に仕様書がないと何が正しいのかわからなくなるため、本人以外はレビューやテストが出来ないということになってしまいます。
レビューしてもらうということは、自分では気づかなかったバグの発見だけではなくもっと良いコードの書き方の学習にもなります。レビューはコードだけではなく仕様書レベルでも有用で、コードを書き始める前にもっと良い処理方法が分かるとコードを書いてからの後戻りが少なくて済むようになります。

このようにプログラムを作るには、コードを書く以外にたくさんの作業が発生します。そしてその作業はコードを書くよりも大変なことも多いのです。