カイゼンを実践するマインドソフトウェア品質を高めるには(2)

情報システム開発を取り巻く状況は複雑化の一途を辿っている。高品質な成果物を効率良く開発するには、“それなりのアプローチ”が求められ、また品質の確認を行うためのテスト作業を、開発工程の中にあらかじめ組み込んで、致命的な失敗を回避する策を講じておかなくてはいけない。牧歌的な時代は終わった。われわれはつねに失敗ソフトウェアの作成に荷担する危険性を担っているのだ。

» 2006年11月22日 12時00分 公開
[小井土亨,日科技連 SPCステアリング委員会委員]

1 最近のシステム開発を取り巻く状況

1.1 情報システムの役割の変化

 多くのビジネス分野において、情報システムは、単なる業務処理の効率化ツールから、ビジネスを提供するための基盤としての役割を担うように変化してきています。銀行、証券、保険業界はビジネスの成り立ちとして情報システムがビジネスの基盤となっているのは当然ですが、このようなビジネスドメイン以外でも、情報システムは、生産から加工そして販売までの一貫した商品のトレーサビリティの要求、インターネット電話、宅配便の配送状況、バスの運行状況のリアルタイム配信、大学講義の休講状況など、日常の生活を行ううえでの必須インフラとして比重を高くしています。

1.2 情報システムへの新たな脅威

 情報システムの役割の変化と適用領域の拡大によって、いままでは存在しなかった以下のようなさまざまな脅威が発生しています。

(1)誤操作による多額の損害

 株の売買やネット販売などでは、1人のオペレータの販売額のうっかり入力ミスによって、会社の存在自体を左右するような多額の損害が発生しています。

(2)悪意のある攻撃

 情報システムの社会に対する比重が高くなったことによって、情報システムやそのインフラであるネットワークシステムは、テロや愉快犯の攻撃対象になっています。ウイルスやワームによるさまざまな情報の流出は、後を絶ちません。

(3)悪意のある利用

 電子メールでの詐欺やクレジットカード番号や銀行口座IDの盗用による預金の引き出しや商品の購入なども、多発しています。また、悪意を持ったシステム運用者による、情報の持ち出しや転売が日々発生しています。

1.3 情報システムへの期待

 以上のような状況によって、情報システムに対する期待は、さまざまな側面で高くなっています。日本版SOX法(金融商品取引法)でも、ITの利用が盛り込まれており、特に操作や業務処理のモニタリングなどは情報システムへの必須要件となりつつあります。

2 システム開発から見た状況の変化

2.1 情報システムの複雑さの増大

 以前のシステム開発においては、入力画面、帳票出力や保存情報などに代表される機能要件だけに注目して開発が進められました。しかし、情報システムを取り巻く状況の変化により、セキュリティなどの一般的な非機能要求や、さらには悪意ある攻撃があってもシステムやサービスを安定して提供するなどの要件を考慮して開発を進める必要が出てきています。これらの要件を考慮することは、システムの複雑さを増大させることを意味しています。結果として、システム開発の難しさも増大しています。また、問題の中には、システムだけではなくミドルウェアやハードウェアなどに対して、総合的に対応する必要のあるものが少なくありません。このような状況が問題をさらに複雑にしています。

2.2 ビジネスとシステム開発のベクトルのずれ

 このように情報システムをインフラとしたビジネスを取り巻く状況は、問題や攻撃への対応や新しい機能の追加など、多くの変化を要求します。システム開発の初期段階で決定した方針は、時間の経過によって発生したさまざまな要因に対処するために変更したビジネスの方針とベクトルのずれが生じます。このずれを是正するためには、システム開発の進め方を変える必要があります。しかし、多くのシステム開発プロジェクトでは、現状の業務の効率化だけを目的としたシステム開発の契約形態や手法や体制を維持しようとしているため、最終的にユーザーにとって有効性の低いシステムを提供することになります。さらに、開発組織や管理体制も、変化をさせないことや変化を最低限にすることだけを目的に構築されているため、この問題を大きくしています。結局、このずれが結果として、ビジネスの足を引っ張る情報システムという結果を生んでいるわけです。

 一部の管理者は、ずれが発生するのは、先を予測できない開発者の言い訳であるといういい方をします。しかし、成功するビジネスは新しいアイデアを実現することが必要になることを考えれば、この意見は、開発者に予言者になることを要求していることは明白です。

3 システム開発に求められるもの

3.1 ビジネスに追随するためのシステム開発の準備

 ビジネスに追随するシステムとは、一度開発したら後は不具合の修正だけというシステムではなく、さまざまな側面の要求に対応する、進化を続けるシステムです。実際、Web上でサービスを提供しているいくつかのシステムの中には、サービスを開始して1年以上経過しても、βバージョンと表示しているものがあります。これらのシステムの多くは、常に新しいサービスの追加を行っており、それを継続することの決意表明として、このような表示を行っています。

 このようなシステムを開発の側面から見た場合、良い設計に基づくシステムであることが必須条件となります。それは、良い設計を実現することで以下のようなシステム特性を実現することができるからです。

(1)正確性

 仕様を正しく満たしている。

(2)理解性

 設計結果が読みやすく理解しやすいこと。

(3)一貫性(統一性)

 設計上の個々の概念が首尾一貫して、ぶれがない。

(4)変更容易性

 機能強化などに伴う変更が容易であること。

(5)頑健性

 誤った使い方に対して、システムが適切に対処できること。システムの一部のバグが全体に波及しないこと。

(6)移植性

 いろいろなハードウェア、ソフトウェア環境へ容易に移植できること。

(7)効率性

 実行効率、資源効率ともに十分実用に適応していること。悪い設計のシステムは、変更に時間と膨大なコストが必要になってしまう、あるいは、一部の修正が全体に影響するなどの問題が発生してしまうことになります。最悪、機能を追加する場合、変更する工数より作り直しの工数の方が少ないといったことになってしまいます。

3.2 テスト容易性の重要性

 高い品質を維持した状態で進化を続けるためには、良い設計を実現する必要があるという説明をしました。しかし、ここで大きな問題があります。機能拡張を行う前の良い設計が、機能拡張後も良い設計であるとは限らないということです。従って、良い設計を維持するためには、設計の改善を繰り返すことが必要となります。

 システム内部の設計を変更しても、外部に提供しているサービスには影響がないことをテストで証明し、品質の劣化が発生していないことに注意を払う必要があります。従って、進化を続けるためには、常に多くのテストを行う必要があります。そこで有効な手段としては、テストの自動化があります。テストを自動化することで、人的工数を下げることができます。しかし、テストを自動化することは、一朝一夕に実現できるわけではありません。テストを自動化するためには、設計段階からテストすることを前提にして開発を行うことが重要です。また、すべてのテストを自動化することを目的にすると挫折してしまうので、自動テストできる範囲を広げることを目的にすべきです。

 実は、自動テストを設計の早い段階から考慮し、実装の開始と同時に自動テストを作成することで、多くの設計上のメリットを得ることができます。

 良いテストには以下のような条件が要求されます。

(1)テスト目的が明確である

 何をテストするか明確である。その目的も明確で、さらに1つである。

(2)テストの判定が正しい

 テストの成功、失敗が正しく判断されている。

(3)テストを独立して実行することができる

 テストがほかのテストに依存することなく、独立している。

(4)繰り返し実行することができる

 何度でも繰り返して、テストを実行することができる。

(5)テストを実行しても、状態が変化しない

 テストを実行し、成功した場合でも失敗した場合でも、テストを実行する前と後で何も変わらない。

 これらの条件を満足するテスト対象は、以下のような良い設計の条件を満足することになります。

(1)テスト対象が1つの機能を実現している

 明確な機能だけを提供する。

(2)結果を提供する

 外部に対して、処理結果を判断できるような何らかの方法を提供する。

(3)独立度が高い

 テスト対象がほかの部分への依存度が低い。

(4)特定の環境への依存度が低い

 特定のファイルやデータベース構造などに対する依存度が低い。

 このような条件を満たして、高凝集と低結合のバランスの取れたシステムが実現されます。さらに、テストは目的を表したもので、実装は実現方法であり、この2つの視点でシステムを明確にすることは、要求から実装までの関連を明確にすることになります。このことは、システムを変更するときに、変更を行うべき部分を明確にすることや変更が影響する範囲を確定することに、有効に作用します。

 システムを高い品質に保ち、その品質を維持したまま、さまざまな機能拡張を繰り返すシステムに対して、テスト容易性を指針とすることは大変有効です。それは、良いテストが良い設計を証明することや、品質を維持したまま設計を改善するための重要な武器になるからです。

3.3 自動テストを支援するためのツール

 最近、多くの開発言語ごとに、テストフレームワークが提供されています。これらの多くは、オープンソースのフリーソフトとして提供されており、利用することができます。これらのツールを利用する場合、ネット上に公開されている、既存の利用者情報が役立ちます。また、多くの書籍も出版されています。

 最近、脚光を浴びているDIコンテナでは、独立性の高いコンポーネントの開発と、そのコンポーネントの組み立てを分離することで、コンポーネント単体のテストやコンポーネントの関連テストを容易に実現することができ、自動テストの範囲を広げることができます。一部の開発者は、DIコンテナをテストコンテナと呼んでいます。

3.4 ディペンダビリティを確保するためには

 ディペンダビリティを確保するためには、システム自体が良い設計を基に良い実装を持ったシステムであり、変更容易性やテスト容易性などの良い特性を持っていることが必須です。しかし、現在開発されているシステムで、良い設計を十分に実現されているものは決して多くないと思います。さらに、十分な自動テストを持ち、テストも重要なシステム資産としてメンテナンスされているシステムはさらに少ないと思います。システムが、ディペンダビリティを確保し続けるためには、新たに生まれる脅威に対して常に対応し続けることが求められます。

 変化を受け入れることは、場当たり的な開発とは、まったく異なります。常に、設計やテストにコストを払い、顧客のビジネス価値を上げるという方針を最優先に情報システムを提供することなのです。

 システムを、さまざまな視点から十分な品質を確保し、システムを進化させながら、その品質を確保し続けるためには、変化に対して常に前向きに向かい合う、「カイゼンを実践するマインド」が開発者にも要求されていると考えます。


◎ 本記事は日本科学技術連盟(日科技連)発行の「クオリティワン」で掲載した内容を日科技連了承の下、再編集の上再掲載しています(編集部)。


筆者プロフィール

小井土 亨(こいど とおる)

株式会社OSK

R&D本部 技術支援部 システム開発技術課

シニアアプリケーションスペシャリスト・情報処理学会ソフトウェア工学研究会パターンワーキンググループ テストパターン リーダー

  • 日本XPユーザグループ 運営スタッフ
  • INETA Japan 運営委員
  • Microsoft MVP(Most Valuable Professional)for Visual Developer - Solutions Architect
  • 日科技連SPCステアリング委員会委員

専門・研究分野、関心のある分野:

  • ソフトウェアパターン
  • アジャイル・ソフトウェア開発


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ