From: リスキルテクノロジー 松田航
新宿本校にて、、、
IT技術者が最も恐れ、
出来ればその姿さえ見たくないもの...
それは、、、
「バグ」です
バグとは
主にプログラムの不具合によって
システムが正常に動作しない問題を言います。
バグが生まれる原因には様々です。
設計不足、
検討不足、
動作環境の問題など...
そして昔から
多くのバグの原因となっているのは、
思い込みによるバグや、
不注意によるケアレスミスなのです。
iOSでもあったケアレスミス
iPhoneやiPadの普及により、
ユーザー数が急増したApple社のiOS。
今年の2月21日、
iOS7.0.6のアップデートが発表されたときに
その問題は発覚しました。
iOS7.0.6での修正内容は
「SSLの接続に関する問題を修正」とされています。
SSLとは、
個人情報やクレジットカード番号など、
大切な情報を入力する時に
通信を暗号化して送受信する通信技術のこと。
この技術によって、
インターネット上の通信の安全性は保たれていますが
iOS7.0.6以前のバージョンでは
SSL通信が正常に行えていませんでした。
SSL通信技術は
既にメジャーとなっている技術です。
何故今さらになって、そんな不具合が起こったのでしょうか。
Apple社は
iOSがSSL通信する箇所の
プログラムソースを公開しました。
[ソースコードURL]
http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c
[ソースコード（一部抜粋）]
プログラムでは
SSL通信時にエラーが発生したら
エラー処理を行う命令にジャンプする様になっていますが...
たとえエラーが発生していなくても
エラー処理を行う命令にジャンプする様に書かれています。
※goto fail; エラー処理へのジャンプ命令が余分に書かれている
つまり、必ずSSL通信がエラーになるのです。
知らずに悪意のあるサイトに接続した場合、
クレジットカード番号やパスワード等が
解析可能な状態で通信が行われていたのです。
※現在は修正されています。
しかも、その原因となるコードはたった１行。
おそらくプログラマーが、
プログラムを作る際にコピペして作ったのでしょう。
たった１行の
ケアレスミスを犯したが為に、
「Apple史上最大のセキュリティバグ」
とまで言われるバグを生み出してしまったのです。
バグをなくす為のテストって、してないの？
もちろん、全てのシステムは
様々なテストをパスしてリリースされます。
今回のiOSの場合は、
SSL関連のテストケースが不十分、
または漏れていた可能性があります。
あるいは...
SSLならば
これまでのバージョンで
ちゃんと接続されてきた実績もあるし
大丈夫だろうさ！
...という思い込み。
こういった思い込みも
バグを生み出す大きな要因の1つです。
システム開発のテストは、
大きく分けると3つの段階を経て
システムに問題がないかをチェックします。
1.単体テスト
最初に行われるのは「単体テスト」です。
設計書を元にして、
プログラムが動作する際に
確認する必要がある項目を洗い出します。
これをテスト仕様書と言い、
プログラムが完成したら、
テスト仕様書を元にテストを行うのです。
2.結合テスト
そして次の「結合テスト」では、
別々に作成された画面や機能を組み合わせ、
システムとして連携できるかどうかを確認します。
例えば
販売管理システムの場合なら、
実際の販売管理において
想定されているシステムの流れ＝シナリオを組み
そのシナリオに則ってテストを行うのです。
3.総合テスト
単体テストや結合テストが
開発者が作った開発環境で行われるのに対し
「総合テスト」は原則的に
実際にユーザーが使用する環境で実施されます。
ユーザー環境が使用できない場合は
それと同等の環境を構築して実施するケースもあります。
総合テストは、システムテストとも呼ばれており...
・システムパフォーマンスの確認
・操作性や業務効率性に問題はないかの確認
・他のシステムとの連携確認
...等といった、
実環境におけるシステム動作・性能に関するテストが行われます。
1つのシステムが開発される際、
多くの人が集まり、多くの時間を費やしテストしますが
それでもバグが発生する可能性は大いにあるのです。
思い込みミスやケアレスミスを無くすには
思い込みが原因で発生するバグは、
「自分が作ったプログラムを、自分がテストする」
という時に発生しやすいです。
テスト仕様書を自分で作り、
そのプログラムを自分で作ると、
実際にテストする時になった際に…
ここはちゃんと
コーディングした時にチェックしたから
問題はないだろう！
そう思ってしまうんですよね。
大きなプロジェクトであれば
プログラマーとテスト担当が別なのですが、
小さなプロジェクトだと
プログラマーがテスト担当を兼ねるケースが多いです。
そして、
本来単体テストで発見されるハズのバグが
結合テストなどで発見されてしまうと、
ユーザーから不審な目で見られます。
本当にちゃんとテストしているのか？と。
思い込みをなくす為には
出来る限り別の技術者の観点も取り入れ
客観的な視点からテストするようにしましょう。
そして、ケアレスミス。
基本的な対策としては「見直し、確認する事」。
この行為に尽きます。
例えば
似ている箇所があるプログラムを
コピペして再利用する場合
ペースト先のプログラムで
正常に機能するのか、
期待した振る舞いを行うのかを、
きちんと確認する必要があります。
元のプログラムではバグが無かったとしても
別のプログラムではバグを生む可能性もあります。
プログラムを実行する際、
ステップ実行（１行ずつの処理確認）できる
開発環境で作成している場合は、
必ず1度はステップ実行することをお勧めします。
そして
これまで何度も使ったプログラムだからと言って
テストにも手を抜くことなく、動作確認を行うこと。
そうしていれば、
今回のApple社のiOSの様な不具合も
出る事はきっとなかったはずなのです。
信頼を損なわない為に
技術者ができる事
人間は完璧を求めますし、
システムは完璧を求められます。
しかし、人間は完璧ではありません。
バグが無いに越した事はありませんが、
様々な技術者のスキルを集め、
出来る限りバグのないシステムを作ること。
少なくとも
思い込みやケアレスミスは、
開発チームと本人の努力によって、防げるレベルのバグ対策です。
それは最低限のバグ対策だと言えます。
最低限のバグ対策を行った上で
更にバグを無くす為の対策を行ったとして、
それでもなお、後々になってバグが発覚した場合は...
・迅速に修正、復旧できるか
・被害を最小限に食い止められるか
・不具合の事象、原因、影響範囲を説明できるか
・再発防止策をどのように講じるか
...といったように、
誠意を持って、ユーザーの信頼を損なわない対応を行う事。
それが大切なのです。
バグはシステムだけでなく
ユーザーへの信頼までも貪るケースがある
その事を覚えておいてください。
リスキルテクノロジー
松田
PS
今回は主に
プログラム的なミスのお話しでしたが、
同じ事は設計者にも言えます。
設計者が仕様を勘違いしたり、
思い込んで設計したりすれば、
ミスを含んだ設計仕様でプログラムが作られる事になります。
また、このような
ミスを減らす為の取り組みは
IT業界に限った事ではありません。
1人1人が連携しつつ、
いかにミスを無くして
質の良い製品・サービスを提供できるか...
それはどの業界でも共通の課題なのです。
PPS
ミスが少なくするには、
ベテランエンジニアのコーディングを見る。
もっと言えば、直接教えてもらうのが、
最善です。
プロのエンジニアが教えるJavaの研修はこちら
