高信頼化ソフトウェアのための開発手法ガイドブック | HATのブログ

HATのブログ

IT関係のニュースを中心に記事を掲載します。日経コンピュータで重要だと感じた記事とコメントを2010年9月1日号から書いています。
このブログは個人的なものです。ここで述べていることは私の個人的な意見に基づくものであり、私の雇用者には一切の関係はありません。

高信頼化ソフトウェアのための開発手法ガイドブック」を読みました。内容も役に立つのですが色々考えさせられたので少し紹介します。

SECBOOKS 高信頼化ソフトウェアのための開発手法ガイドブック/独立行政法人 情報処理推進機構
¥1,000
Amazon.co.jp
      ↑貼りましたが今は買えません。IPA から申し込んでください。

多数のユーザ企業、ベンダ企業が参加して作成されました。IPA(情報処理推進機構)から、PDFで無料公開 されたもの書籍版です。270ページもあり索引もついて1,000円ですから大変お買い得です。

企業なら部や課単位で買えば輪読したり勉強会をするネタになります。
(PDFなら無料ですが、製本の方が読みやすいです)

1.ガイドブックの紹介

まず、「高信頼化と品質」について、JISの品質特性から、CMMI,ISOなどを引用しながら解説します。レビュー手法8種類とテスト手法10種類(細かくは22種類)については特に詳細に解説されます。インスペクションが、ANSI/IEEE標準で定義されている厳格なレビューだという事は知りませんでした。

テスト手法については、このブログ で以前取り上げました。初級者の方にテストフェーズ全体を俯瞰してもらう事を目的に書きました。この本は具体例も入れながらに解説されていますのでわかりやすいです。

この本の最大の面白さは「障害事例から学ぶ予報活動」です。何と具体的な障害の概要と根本原因、それに再発防止策までが39事例も上がっています。障害事例だけを読んで、根本原因と解決策を考えてから読むと訓練になります。もちろん再発防止策には正解はありませんから違って当然でしょう。これをネタに勉強会をしても面白いと思います。
例えば、こういう事例が載っています。
<事例14>
開発中にテストデータを格納したメディアを紛失した
→アクセス権限設定などのセキュリティ対策を進めていた最中であり、状況が正確に把握出来ていなかった
<事例16>
退職者によるN/W不正アクセスにより社内システムのファイルを改竄され、システムが止まった
→ID、パスワードの管理不徹底、不正アクセスへの対応の甘さetc
<事例38>
利子計算プログラムに欠陥があり、顧客に送付した取引残高報告書に誤情報を記載
→原因は、利子計算が複雑なため、結果検証用のツールはユーザ(銀行)側の担当となっていたため、業者がパラメータ変更が必要な事に気付かずプログラムを保守したため。

どうでしょう?身につまされる方は多いはずです。ここに書いてある再発防止策は一例ですから各企業に合ったものを皆さんで考えるきっかけに出来ると思います。特にトップの方や経営者の方を入れたディスカッションが重要でしょう。

ここまでが約半分です。後ろはユーザ企業やベンダーが行っている品質活動事例ですから宣伝半分だと思いながら読みました。とはいえ、富士ゼロックスのHAYST(ハイスト)法の話だとか、日本ユニシスが米国で流行したフロントローディング(W字)を早くから取り入れている状況だとか参考になりました。

2.感じたこと

IPAの出す資料は、WGで中心となる企業の色が強く表れすぎる場合と、全員の意見を取り入れすぎて発散したままになっている場合があります。一般的には使いにくいと思っています。

その中でも、「高信頼化・・」は、「セキュア・プログラミング講座 」と並んで今後も参考にしたいガイドブックです。「セキュア・・」の方は技術が日進月歩ですので書籍化は無理でしょう。
http://www.ipa.go.jp/security/awareness/vendor/programmingv2/index.html

このガイドには、少し前なら企業内に閉じておくべき内容が含まれています。それをあからさまに公開して下さっているのは、この業界に少しでも貢献したい、この業界全体を良くしていきたいという気持ち以外ないと思います。

例えば富士通は、PostgreSQLの発展に大きく貢献しています。もう5年以上まえだと記憶していますが、富士通の貢献がなければPosgreがここまで広がっていないでしょう。推測ですが、Posgreへの貢献はビジネス的な考えがあったとしてもその貢献を通じて、業界全体を良くすることが結果的に早道だと気付いたのだと感じます。執筆者の中にIBMやOracleがいないのが象徴的です。

システムの構築作業はいまだに手探りの状態です。匠の技といえば聞こえが良いですが、工学に成り切れていません。強度計算や耐震計算が出来ないのに「信頼性は上中下のどれにしますか?」と言っても嘘にしかなりません。品質管理のプロセスにどれだけ工数(お金)をかけても初級SEだけで作れば、スーパーSEだけで作った「信頼性下」のシステムの品質に負けるのは明白です。

業界全体の底上げのためには、企業の垣根を取り払って経験を公開し相手を説得する中で新しい知見が生まれるのだと思います。

3.セキュリティインシデント

今日ネットで品質に関する悲惨な話 が広がっていました。

・巫女SE(17)さんが、あるWEBシステムのセキュリティ検査を請け負った
・ペネトレーションテスト(実際に侵入を試みる手法)でパスワードやクレジット情報が簡単に漏えいした
・顧客に迷惑がかかりすぎるため、独断でサービスを停止した
・専務に警察を呼ばれ、業務妨害で警察に連行された
・派遣先の社長(?)のとりなしで釈放され、継続調査することになった
・ソースを見て唖然とした
<select count(*) from ユーザー where id=入力されたid と、select count(*) from ユーザー where pw=入力されたパスワード を実行して、両方とも1以上ならログインできちゃうシステム>
<テストケースとしての是非はともかく、これなら確かに「正しいIDとパスワードでログインできる」「正しくないIDとパスワードではログインできない」「正しいIDと正しくないパスワードではログインできない」というテストに表向きは通りますね、なるほど。>
<もう侵入があったか検証するとかいうレイヤーじゃなくて、全顧客のクレジットの履歴からクレジット会社経由で洗ってもらうしかない……気がします……>
・実際にこのシステムを作った関係者からヒヤリングしようとしたところ
<「コード書いた人なら不正入国だったらしくて国外退去になったから会えないけど、テストはきちんとやったから大丈夫」(意訳)という開発元からの回答>
<「テスト実施者を呼んでください」「構いませんが日本語わからないので大丈夫ですか?」>
<プログラマー2名:片方は不正入国で国外退去、もう片方は地震のあと帰国して連絡つかず テスター:広東語しかわかりません 仕様書・テスト項目の作成者:プログラミング未経験の23歳(社長いわく「大卒だから大丈夫」) プロマネ:営業(なので技術的知識なし) 大丈夫な要素が何もない!>

この会社で再作成することになったそうです。これをリアルタイムにtwitterに流してた というのは人間として問題がありそうですし、ITに疎い方ばかりの会社だとは言え顧客に承認を取らずにシステムを止めるってのは社会人として問題はあります。
※今日5/17でtwitterアカウントを削除するそうです

このシステムは去年の11月から先週末まで約半年動いていたのです。こういう事例は他にもあるのでしょう。マンガのような話です。私はよほど信用出来るサイトでない限りクレジットカードは使わない事にしています。皆さんも気を付けて下さい。

以上