プログラミング入門者のためのシステム影響調査方法まとめ

プログラミングを扱うITエンジニア達が日々仕事をしている「実務」において、「影響調査」という仕事は当たり前のように行われています。

そのため、「当たり前」に出来る必要があります。

もちろん、現場に出てからでないと実際の深い知識や経験は身につきませんが、少なからず現場に出ても恥ずかしくない程度のスキルは身につけておきましょう。

ここでは、その「影響調査方法」について解説していきます。

影響調査とは？

影響調査とは何かというと既にあるプログラムのコードから「修正（機能を追加したり、不具合を修正したり）」を加えた場合に

その修正が影響してしまうコード箇所（画面数や機能数）を調査すること

をいいます。例えば、

DBのusersテーブルのカラムを１つ削除する。

となれば、修正自体はちょっとした修正でも、

ユーザー登録画面、ログイン画面、マイページ、パスワード再発行、その他etc…　にまで影響する可能性があります。

そうなると

修正箇所の工数（小さい）＋テストの工数（大きい）

がかかってくるわけです。（工数とはそのお仕事にかかる「時間」のことです。）

そこを見極めて「修正するのか？しないのか？」といった判断をしていきます。

なので、影響調査とはつまり

「修正をする前」に「修正箇所」と「その修正が影響する箇所」までの「テストの工数」を「事前に把握」する

ために行うものになります。

HTML言語・CSS言語での影響調査方法の例

どの言語でも同じ事ですが、例えば、HTML言語・CSS言語の場合で下記のようなコードがあったとします。

ここでは、BootstrapというCSSフレームワーク（既にCSSが書かれたものを使って.btnなどとclass名を指定するだけでボタンのデザインにしてくれる便利なものです）を使ってボタンのデザインをしましたが、styleタグの中で.btnに対して修正をかけたとします。

いきなり「ボタンの背景色を全部変えたい」と言われたら？

例えば、いきなりマネージャーから

「サイト内のボタンの背景色、全部変えるから」

と言われたとします。

そこで、まず確認しなければならないのは

全部一括でボタンの色変えられるのかな？

ということを調査する必要がありますね。もし、ボタンにしているclass名全てにbtnがついていなくて例えばstyle属性で一個一個のボタンのスタイルを作っていた場合には（面倒臭くてstyle属性を使って直接htmlにスタイルを適用してそういったボタンもいくつか作ってしまってたなど）、手作業で１つ１つ変える必要がありますね？

もし、class属性でbtnを指定してさえいたら、

CSSの中で.btnの部分を変えてあげるだけで一気に全部色が変わってくれますからね。

なので、まずは

全部、btnのclass属性ってついていたっけ？

を調べるわけです。

目視しかない

あなた一人でサイトを運営していて開発当初から携わっていたのなら

「あー、全部ついてるついてる」

とパッと分かるかもしれませんが、時も経ってくれば「あれ？どうだったっけ？」と必ずなりますし、途中からその現場に入ったのであれば（大抵はそうですが）分かるわけがありませんね。

もし、「全部変えてくれ」と言われて「全部変えられていなかった」となれば、「バグ（本番障害）」というものになります。

「本番」とは

「実際に運用して公の場に出ているもの（要は普通にネット上のサービスのことですね）」

のことを言います。

「障害」とは

「運用している中で起こった不具合（サイトが見れないとう重度なものから、ボタンの位置がずれているといった軽微なものまで）」

のことを言います。

なので、「確実に全部変える」ということになると

ボタンというものを数十画面〜数百画面あるサイトの中から１つ１つ「目視（自分の目で確認）」で見つけ出す

とう作業が必要になります。

もしくはボタンなのであれば、inputタグかbuttonタグかaタグで作ることがほとんどなため、それぞれのタグをエディターの「全ファイル検索機能」を使って該当箇所を見つけ出す。という方法もあります。

しかし、なぜ血迷ったのか「divタグなんかでボタンが作られている（画面遷移やフォーム送信などはJavaScriptを使っている）」なんて場合も無きにしも非ずです。画面遷移ならaタグ使えばいいし、フォーム送信ならinputかbuttonタグをなぜ使わなかったんだ！？という話ではありますが、そんなコードが実際の現場にも実は数多く存在します。

結局は「確実に」全部変えられるか？は「目視」になってしまいます。（とは言っても、人間の目なので誤って見落とすことも多々あるので結局確実ではありませんが）

しかし、大抵の場合はそういったタグやclass属性で「btnがついているはず」を前提として「該当箇所がいくつあるのか」を調査します。

それで修正が漏れてしまったものに関しては「その都度直していく」という方針がほとんどの場合取られます。

修正したはいいが、、、

では、先ほどのコードに戻ってみて、.btnをstyleタグの部分で修正することにしました。

簡易的にhtml内でstyleタグを書いてcssを修正しちゃってますが、本来はちゃんとCSSファイルがあって、そこの.btnを修正しましょう。

では、修正した時に上記の場合どうなるか？というとお分かりの通り

ボタンじゃないところも色が変わってしまう

わけですね。

このまま「本番リリース」をしたら、完全に「本番障害」です。

余談ですが、

リリースとは、自分のローカル環境で修正したファイルをインターネット上に上げることをいいます。インターネット上には外部の人からは見えないけどもう１つテスト用環境として「同じサイト」がそっくりそのまま作られていることがほとんどです。

なので「テスト環境」と「本番環境」というものがほとんどの現場では存在します。現場によってはテスト環境が２つあるものもあります。なので、本番へリリースする事を本番リリースといいます。

上記コードの場合、ボタンじゃないところも色が変わってしまうので、影響箇所の１つになります。

そういった箇所を見つけ出して「そこの箇所はまた別の修正が必要」ということになります。

これが、１ファイルならいいんですが、何百画面、何百ファイルもあるサイトで何十箇所もあった場合、それぞれ直さなければいけないので

class属性btnのCSSをいじるだけで一括で簡単には変えられない

その分、工数がかかる

ことを意味します。そして、それをあなたは「このくらい時間がかかりそう」とマネージャーへ報告する必要があるのです。

CSSを修正した場合の影響調査方法のまとめ

まとめると

・ボタンの色を全部変えたい

・ボタンはclass属性btnがついている前提で修正することにする

・CSSで.btnに対して背景色を変更する

・ということは、class属性btnがついている箇所（影響箇所）をエディターの全ファイル検索機能で洗い出す

・その中に本来修正で変わってしまうと不味い部分がないかチェックする（これはもう目視しかない）

・影響箇所は最終的に全て「テスト」を行って、仕様通り（要求通り）になっているかをチェックする

という流れになります。

テストに関しては、CSSなど見た目の部分は目視しかありませんが、バックエンド部分は「自動テストツール」といったものを使って自動でテストを行うものを大抵は導入していることがほとんどです。（JavaScriptもテストツールはありますが、きちんと導入している現場は今の所少ないです）

なので、影響箇所調査とは

修正する内容が影響してしまう箇所を洗い出すために必要で、最終的にテストでチェックしていく際にも大事なもの

ということですね。

ちなみにCSSファイルも複数あって、それぞれに.btnがある。なんて場合もあるので、その場合はそれぞれのファイルを修正する必要があるため、その分工数がかかる（発生する）ということになります。

DB変更での影響調査方法

DB（データベース）のテーブルに「カラムを新たに追加する・削除する・カラム名を変更する」といった場合にも、影響範囲の調査をします。

例えば、usersテーブルのzipカラム（郵便番号を入れておくカラムだとします）を削除するといった場合には、zipカラムが使われている箇所全部に影響しますね？なので、まずzipカラムを使用している箇所を全ファイル検索します。

上記のように「zip」で検索すれば、例えば「SELECT文を使っている箇所zipカラムを指定しているなー」ということがわかりますね。

なので、ここは修正対象になります。

さらにその後にはzipカラムから取得したデータを使って色々処理していたり、それを画面に表示している箇所もあるでしょうから、その辺りもコードを目で追っていって見つけ出す必要があります。

そこも「影響範囲」ですね。

また、INSERT文でもzipを指定してデータを挿入しているはずですから、そのあたりももちろん影響範囲に入ってきて修正対象になります。

ちなみにこういった処理はまずもって「関数」や「オブジェクトのメソッド」としてまとめられています。

フレームワーク部でやったように大抵の現場ではFWを使っていますので、「MVC」の中の「モデル」の１つとして大抵まとめられています。

FuelPHPを使ってやりましたが、usersモデルといったものがあって、その中にDBへのSELECTやINSERTといった色々なメソッドがありましたね。

それをコントローラーの色々な箇所や色々な画面で呼び出していました。

なので、そのモデルのメソッドを修正するということは、そのメソッドが使われている箇所全てが影響範囲となります。

影響範囲なわけなので、「全てテストして修正後もきちんと問題がないか確認する必要がある」ということになります。

ちょっとした修正で済むと思っていたものが、芋づる式に「こっちも修正しなきゃいけない。そうするとさらにこっちも修正しなきゃいけなくて。さらにそうするとー」となる可能性もあります。

そうならないために日頃の開発の段階で「後々で修正した時に修正箇所が極力するなくて済む設計」というものを意識しておく必要があります。

バージョンアップによる影響調査方法

例えばマネージャーから「PHPのバージョンアップをしたい」ということで今使っている「PHP5.6」から「PHP7」にバージョンを上げるとしましょう。

こういったように「何か機能を追加する」とか「機能を変える」といったものでない場合もあるわけです。

バージョンを上げる際に今使っている関数が廃止されている可能性があります。

なので、まずはPHP言語の公式サイトを確認して「何が廃止されたのか？」「どのあたりが変わったのか？」を調べるところから始まります。

他にも先にバージョンアップして詰まった点などを記事にしてくれている先駆者の人たちもいますので、ブログなんかをググるわけですね。

その廃止された関数を使っているか？

仕様が変わった関数を使っているか？

１つ１つ全ファイル検索をしてチェックしていき、その箇所を書き換える必要が出てきます。

まとめ

このようにマネージャーなどの要求に対して、

どこを修正すればいいのか？

その修正をする事によって他も修正しなければいけない箇所はないか？

その修正にかかる工数はどの程度か？

その修正によって影響する画面はどこか？

その修正によってかかるテストの工数は？

を洗い出していくのが影響調査というものになります。

ちなみにテストには「リグレッションテスト（回帰テスト）」という「プログラムを変更した際に、その変更によって予想外の影響が現れていないかどうか」を確認するテストもあります。結局全部の画面をテストするということですね。

大規模なシステムや金融系や業務システムなど「バグが許されない」という現場では必ず行いますが、WEB系はその辺りが緩いので「時間があったらやる（＝大抵時間はないのでやらない）」「重大な決済など料金の部分だけやる」といった事がほとんどです。