はじめに
個人的にプログラミングを学ぶ方も増え仕事に活用したい、あるいはすでに活用している方もいるのではないかと思います。
さらに組織の生産性を上げるために作ったプログラムを使ってもらう機会も出てくるでしょう。ただ、個人で使うあるいは小さなプログラムでは意識しなくても良かったことが、規模が大きくなったり複数人で使うと問題になることが出てきます。
これは1960年台に叫ばれた「ソフトウェア危機」の小規模版とも言えるかもしれません。
そこで特に開発現場の経験のない方に向けて考慮すべきことを書いてみることにしました。使われ方によって考慮することが変わってくるので、単純な場合から順に書いていきます。
自分で作って自分で使う場合
ここでは
- 自分が作って自分が使う
- 実行、出力結果が自分にしか影響を与えない
場合について書きます。
この場合は書きたいプログラムを書いて、使いたい時に使って構いません。ただ、次に書いたバージョン管理システムは利用することを強くオススメします。
バージョン管理システム
プログラムをしていると特に不具合が発生した時に、いつ、どこを変更したか知りたくなったり、ある時点に戻したい（結果的に、いつでも戻せるという安心感が得られることが大きい）ということが出てきます。そういうニーズを満たしてくれるのがバージョン管理システムというものです。
バージョン管理システムとしてgit、そのホスティングサービスとしてGitHub(https://github.com/) を使うと良いでしょう。GitHubで公開すると配布も容易になります。（それぞれの使い方などはその他のサイトなどに譲ります）
プログラムをするのに別のシステムの使い方を学ぶというのは手間だと感じると思いますが、使い始めるとこれ無しではやっていけなくなるほどです。
gitのコマンドは多くの種類がありますが、この段階では
- status
- clone
- add
- commit
- push
が使えれば構わないと思います。
また前述した機能的なメリットの他に、GitHubではどれだけ活動しているかが可視化(俗に草を生やすと言われます)されるので、自分のポートフォリオとしても活用することができます。
後述する中で、バージョン管理以外の目的でもGitHubを活用しますので、アカウントを作成しておきましょう。
注意点として保有できるGitHubの無料アカウントは一つまでです。一方で、一つのGitHubアカウントに複数のメールアドレスを紐づけることは可能です。
自分で作って少数の他人に使ってもらう場合
良い出来のものであれば、他の人に「使わせて欲しい」と言われることも出てくるでしょう。ここでは
- 自分が作って少数の他人が使う
- 実行、出力結果がその人にしか影響を与えない
場合について書きます。
こうなると「使い方が良くわからない」、「上手く動かない」、「こうだったら良いのに」といった質問や要望が上がってきて、自分一人では生じなかった問題や手間、少々不便だったけど我慢して済ませていたことがそうもいかない場合も出てきます。
ドキュメント
導入や使用方法などのマニュアルを用意して、「使い方が良くわからない」という類の質問は、そちらを参照してもらえば済むようにしておくと説明の手間が省けます。
ドキュメントにもGitHubが活用できます。プロジェクトの最上位フォルダにREADME.mdというファイルを作成してMarkdown形式で記述しておきましょう。プロダクトとセットで配置すればGitHub上で確認することができます。
保守
他の人に使ってもらうと「上手く動かない」、「こうだったら良いのに」という不具合や要望が上がってくることは避けられないことです。（それだけに他者に使ってもらう判断やタイミングはある程度、安定してからにすると良いでしょう）
他の仕事も抱えているはずですので理想的なのは、不具合を発見したり要望のある本人が修正できるようにしておくことです。そのためにもGitHubで公開しておくと便利です。
その際には次のバグトラッキングも同時に行うようにすることが望ましいです。
バグトラッキング
バグトラッキング（不具合追跡）としてはバグトラッキングシステムという専用のものもありますが、GitHubのIssue機能で間に合うかと思います。
不具合だけではなく意見、要望なども一緒にIssue管理して重複した問い合わせを防ぎましょう。
Issue機能を使うことでGitHubの他の機能（特にPull Requests(PR)）と連動させることもできて便利です。
データのバックアップ（小規模版）
プログラムの不具合などでデータが壊れてしまう場合を考慮して、単純なコピーで構わないので必ずバックアップをとっておきましょう。
Googleスプレッドシートなどでは自動的に過去データを保持してくれますが、実行直前のデータである保証はないため実行前にバックアップを取るようにしておきましょう。
多くの人に影響を与える場合
ここでは
- 自分、あるいは複数人で作って多くの人が使う
- 実行、出力結果が多くの人に影響を与える
というような組織的に業務で使い、影響を与えるような場合について書きます。
こうなってくると良いことよりも、事故などの悪い状況を想定しなくてはいけません。工数削減のためだったのに、事故ってしまいそれを修正するために削減予定の数倍の工数を費やすとなったら胃痛では済まないでしょう。
そのため事故が起こらないようにする、あるいは起こってしまってもリカバリーできるようにして業務への影響を最小限にすることが重要です。
作らなくても済まないか検討する
腰を折るようですが、自前で作らなければ開発、テストや保守の工数をゼロにすることができます。最近は無料のサービスやライブラリも多数ありますので大抵のニーズに合うものが見つかるでしょう。
個人で使う分には既存のものが使える状況であっても自分の成長のため、あるいはニーズを100%満たすために自作する選択も良いことだと思いますが、複数人が関わる場合は開発コストや事故時の復旧コストを算出して天秤にかけるようにしましょう。
テスト環境
この規模では開発中の確認を本番環境で行うのは怖くなってきます。業務がストップしてしまったり、データが壊れたりして復旧できなくなってしまう可能性があります。
そのためテストは別の環境を用意して行うのが望ましいです。ここでいう「環境」は本番とは違うマシン（物理でも仮想でも）上にできるだけ同じ状態を構築したもののことです。個人情報などの関係でデータのコピーができない場合は、フォーマットが同じダミーデータを作成して対応しましょう。
蛇足ですが実際の開発現場では三つ以上の環境を使い分けていることが多いかと思います。
データのバックアップ（大規模版）
バックアップに関しては前述しましたが、複数人が影響を受ける場合はさらに慎重に進める必要があります。また、次で言及する「ロールバック」のためにも必要です。
以下の手順で基本的に問題ないかと思います。
- 作業予定の告知をする（バックアップに時間がかかる場合は、次の手順で影響を受ける人がいるため）
- データをロックする（バックアップ中にデータを変更されないようにするため）
- バックアップを取る
- データのロックを解除する
- 作業終了の告知をする
実行してみるまで何があるか分からないので、必ずバックアップをとりましょう。
ロールバック
不具合が生じた際に、元の状態に巻き戻すことです。プログラムやデータなど全てを実行前の状態に戻します。
このロールバックをするためにも前述のバックアップが必須になります。
また不具合の発生時に落ち着いて作業できるよう、作業手順書も用意しておきたいです。ロールバックに失敗すると目も当てられないので、「順番にコピペして実行するだけ」「二人で確認しながら進める」のように間違いが起こらないような工夫をしましょう。
回帰テスト
バグを修正したら新たなバグを作り込んでしまう、あるいは以前に出た不具合が再燃してしまうということがあります。そのため何かしらの変更をした場合は、その変更に対するテストに加えて以前のテストも実施することが望ましいです。
これを回帰テスト（あるいはリグレッションテストなど）と言います。「それって修正が増えるに従ってテストが増えていくってこと？」と思った方、その通りです！二、三個ならともかく数が増えると手でやるのは大変なので自動化と組み合わせて考えることになります。
回帰テストに限らず各種テストはそれだけで本があるくらい高度な活動になります。完璧にやるのは困難かもしれませんが、本来であれば必要なものだと心得ておきましょう。
おわりに
他にもCI/CDのような大きなことから、小さなことまで（それ以外に法令遵守、企業ガバナンス、セキュリティなどなど）やった方が良いことがあると思いますが、「エンジニア職でない方がプログラミングを学んで業務を効率化する」という規模ではなくなってしまうので、このくらいに留めます。
これからプログラミングスキルを業務で活用したいと思っている方の参考になれば幸いです。