誰かが作った何か業務を効率化するツールがあったとして、そのツールを作った人は既にいません。そんな中でほんの少しだけそのツールの使い方を変えたいという時に、作った人がいないから何が何だかわからない、ということをよく聞きます。
元々自分がいなくなっても後の人がきちんと運用し続けることができるようにわかりやすく作っておくのが大事と言われますが、その「わかりやすく」の基準も一人一人バラバラで曖昧なものです。ある共通したプログラムの常識と呼ばれる方法で作るとすれば初めの作成の時点で実はそのルールに則って作るというのが結構大変で時間とお金がかかってしまう場合もあります。そんなことで、後々分かりやすいように作ったとしてもそれはその作った人の基準でのわかりやすさにしかなりません。
その作った人がその現場から離れる時に引き継ぎをするということもありますが、実際にはそれを作成するだけのスキルを残すというのが引き継ぎであって、そのための時間は事実上ないでしょう。
そのようなことを考えると、なにか変えたい時は、そのツールを分析するのではなく、業務からどんな動きにすればいいかを0から作った方が早いケースの方が多いと思っています。
でも多いとはいえ、大規模になれば大規模になるほどそうではないケースも結構あると思うので、改造の方法とはどんなやり方があるかを書いてみたいと思います。
改造の種類
改造の種類というのはたくさんあります。
単純には機能の追加、変更、削除。管理するデータの追加、変更、削除です。
構造的にかなり大変なのは管理するデータの追加です。
これは大元のデータベース構造にメスを入れるので、Excelでいえばある列の間に一つ新たな列が追加されることになるので、列番号がひとつずつずれてしまうということになります。そして、操作画面もその新しくなったデータを扱うための項目もしくは画面そのものを作り直すことになります。 たった1項目でも追加する場合は、本当に改造でするのかそれともゼロから作った方が早いのか検討した方が良いです。
比較的簡単なのは、入力画面においてクラスを指定したら、名前のコンボボックスにそのクラスの生徒の一覧が表示されるというものです。 このような仕組みは、今ある仕組みの機能に後付けでも付けることが容易な仕組みです。
改造の進め方
改造するときはいきなり改造してはいけません。どこをどのように改造するか以前にもっと大事なことがあります。
いつ改造したものを運用し始めるかです。
その仕組みにはデータが紐ついています。改造すると思って始めた時までのデータはその仕組みに入っていますが、そこから改造したものを使い始めるまでの間のデータはどんどん蓄積されてしまいます。これをどうするか考えてから始めましょう。
切り替えるタイミングは一気にしなければなりません。そのタイミングで一回、その仕組みを作った作業を止める必要もあります。 そして改造した仕組みに最新のデータをどのように持ってくるかを考えておかなければなりません。このプランを考えるのが、改造するときに最優先事項だと考えます。もちろんいつリリースするかによって、いろいろな関係するところにあらかじめ通知しておかなければなりません。
そして、実際の仕組みの中身でどのように変更するかを考えていきます。
これももちろんですが、改造する時に、実際に動いている「本番環境」を直接改造しないでください。改造途中で仕組みが不完全動作になっているタイミングで実際の操作をされてしまったら、実際にその仕事ができなくなるだけではなく、中に格納されているデータがぐちゃぐちゃになってしまう可能性もあります。「本番環境」をコピーしたもので改造し、リリースの時に「本番環境」にコピーします。
リリースの前に必ずしなければいけないことがあります。どんな小さな確実に動作すると思われる改造でも動作チェックが必要です。
退行試験
動作チェックは、新しく追加した機能や変更した機能がきちんと動作するかをチェックするだけではなく今まで動いている機能もチェックする必要があります。これを退行試験（レグレッションテスト）と呼びます。どこまでやるかは作業コスト次第なのですが、基本はその改造をしたことで関係のありそうなところは全てチェックします。規模の大きな改造になるのであれば、その仕組みを初めて作った時と同じチェックする項目をチェックする必要があります。
実は改造で一番めんどうくさいのは、前任者の作ったものを解析することではなく、この退行試験です。退行試験をしない機能があるのであれば、その根拠はなんなのかきちんと説明できなければなりません。そこまですべてのプログラムを網羅して解析しておく必要があり、少しでも影響がありそうなところがあればそれは全て試験することになります。
試験をする前はどのような項目をどのような形でチェックしどのような結果が出ればOKにするというテスト項目一覧表を作って実施します。
効率化ツールの重要度によって考える
今ある仕組みを改造していくのはこのような流れが本来は必要です。
しかし、それをちょっとした改造ごとに行うのであれば、実際に自分のしなければいけない業務に手が回らなくなるでしょう。ここまでやるべきかどうかは個々の判断になりますが、例えばVBAも使っていないExcelの仕組みがあって、入力規則だけを追加した場合はここまでチェックするのは大げさだと思いますし、VBAのプロシージャが50以上使われているような場合で大元のデータに一項目追加するといった場合は全ての機能をチェックする必要が出てくるかと思います。ここはその効率化ツールの価値とシンプルさによってケースバイケースで対応方法を変えていきましょう。
コメント