検索
特集

「第3のIT」へと変革する時代に考えておきたい「品質」との付き合い方「ソフトウエア品質向上の"変" 2015 江戸〜今、変革の時〜」リポート

2015年2月4日に行われた@IT主催セミナーより、JJUG会長鈴木氏による基調講演の模様や、弥生とYahoo!ショッピングの品質向上事例、各品質向上ツールの概要をお届けする。

PC用表示 関連情報
Share
Tweet
LINE
Hatena

 2015年2月4日、@IT主催セミナー「ソフトウエア品質向上の"変" 2015 江戸〜今、変革の時〜」が開催された。開発のスピードと品質を底上げするには、開発からテスト、リリースまで、プロセスごとではなく全体としての効率を向上させることが重要となる。本セミナーで登壇したエキスパートたちの講演から、同課題に取り組むためのヒントを探る。

基調講演〜アプリ開発からサービス開発へ移行するには?

 基調講演『提供すべきは「成果物」ではなく「サービス」今あらためて疑うべき、「スピードと品質」の本当の意味』に登壇したのは、グロースエクスパートナーズの鈴木雄介氏だ。


グロースエクスパートナーズ ビジネスソリューション事業本部 執行役員 本部長/日本Javaユーザグループ 会長/日本Springユーザ会 幹事 鈴木雄介氏

 「企業におけるITの意味は、ここ約20年で大きく変わった。ライフスタイル含めデジタル化が進む現在、企業ITはこれまでのような計算処理や事務処理の効率化(第1のIT)、管理統制の拡張(第2のIT)といった役割から、事業に付加価値を与えるサービスの開発という役割を担うようになっている」

 そんな変革を「第3のIT」と定義した鈴木氏は、一つの例にトヨタのプリウス専用スマホアプリ「TOYOTA friend」を挙げた。同アプリは、平均速度や近くのレストランの情報などを提供することで、車を単なる移動体ではなく、移動+情報提供というサービスに押し上げた。

 だが、「どういったサービスが利益に寄与するのか、どのくらいの価格設定が妥当なのかは、企業や業種ごとに試行錯誤が必要で、誰も正解が分からない」と鈴木氏は言う。しかも、迅速かつ低コストで高品質なアプリケーションを目指す従来のやり方ではなく、ITサービスを運営するという視点でアプリケーション開発を考える必要があることから、第1と第2の経験が生かせないことも課題を難しくしていると、鈴木氏は指摘する。


ITサービス運営のモデル v0.3(鈴木氏の講演資料より)

 では、“サービス”は、どのように開発、運営するべきなのか。「アプリケーション開発は、決められた仕様に従って進めていく。一方の“サービス”は、利用者のフィードバックを受けながら、臨機応変かつタイムリーに機能の追加、拡張を行う」(鈴木氏)

 ただし、フィードバックを重視し過ぎて付加機能を盛りだくさんにすると、開発の速度は落ちる。また、開発スピードを上げても数週間おきに業務部門へ業務変更を強いることになれば、“ゆがみ”が生じる。

 「プロセスの一部を高速化しても意味がない。そこで、顧客からのフィードバックを基準速度に、企画、開発、運用、業務の全プロセスで納得できるリズムを作ることを推奨したい。新機能追加のメジャーリリースは6〜12カ月ごと、定期アップデートは数カ月ごと、バグ対応など小さな対応は数日〜数週ごと、といったように、3つのリズムを並行運用することも一つの案だ」(鈴木氏)

 品質についても、鈴木氏は「プロセス全体を通じて妥当なレベルを維持し、どのタイミングでどの品質を確保するのかを考えることが大切」と言う。その上で、「開発部門と業務部門とが『第3のIT』の変革をどう吸収し、どうパートナリングしていくか考えることが成功のカギなのではないか」と述べた。

セッション1〜開発初期からテストして無駄な後処理を減らす

 セッション1『テストを変える。新しいソフトウエアテストのアプローチ』では、日本シノプシスの雨宮吉秀氏が登壇した。


日本シノプシス 営業本部 コベリティグループ シニアマネージャ 雨宮吉秀氏

 「より良いソフトウエアをより早く出すには、テストを変えるべきだ」。そう述べた雨宮氏は、「ソフトウエア開発では、歩行をさえぎるように手すりがあって上れない階段のような、あり得ないミスが残されたまま最終段階に入ることもある」とし、それをなくす良い方法は、「開発しているそばからテストしてバグをつぶすことだ」と強調した。

 「Coverity」シリーズは、ソースコードをエミュレートして品質チェックする静的解析ツールだ。コーディング規約をチェックする手法よりも誤検出や重要ではないバグの検出がなく、深刻度の高いバグを検証できる。

 同製品では、並列解析で数百万行のコードでも短時間で処理できる他、プロシージャ間解析でスタックの深さに制限なくアプリケーション全体に対して関数の呼び出しを追跡し、確実に問題を洗い出すことも可能だ。また、不具合のあるコードのパスは分岐全てがハイライトされ、どのようなエラーかも表示されるので、効率的に修正作業ができる。

 この他、直前のコード変更にフォーカスしてテストすべき個所を確実にテストできるようなテスト作成支援機能や、実行結果を解析してテスト不要な個所を見極め、短時間でもミスの少ないテストができる実行支援機能も提供している。

 「Coverity無料トライアルでは、クラウド版とオンサイトトライアル版がある。自社コードの状況を知るためにも、ぜひ一度触ってみてもらいたい」(雨宮氏)

セッション2〜画像認識技術で画面表示を解析するテスト自動化ツール

 セッション2『GUIベースのテスト自動化ツールeggPlantのご紹介』では、サンフューチャーの森安正彦氏がTestPlant社のテスト自動化ツール「eggPlant」を紹介した。


サンフューチャー テクニカル・ディレクター 森安正彦氏

 eggPlantは、テスト自動化ツールの「eggPlant Functional」(以下、ePF)、複数のePFでのテスト同時実行やスケジューラーでの自動実行などを管理する「eggPlant Manager」、VNC(Virtual Network Computing)サーバーの「eggPlant eggOn」、ePFをHPのテスト管理ソフトウエア「HP Quality Center」に組み込むための「eggIntegration」、デバイス管理ツールの「eggCloud」、そして全てがパッケージされた「eggBox」をラインアップする。

 ePFは、画像認識技術を使って画面の色やアイコン、文字列などを認識し、ユーザー操作を再現するテストツールだ。「OKボタンをクリックする」とテストスクリプトで設定したら、画面上からOKボタンを探して認識してくれる。フレームワーク固有のプロパティ名とひも付けながらテストスクリプトを記載するといった作業は不要になる。

 Webブラウザーごとのアイコン表示の差も、イメージライブラリでまとめて管理する。これにより、異なるWebブラウザーやOSでもテストスクリプトを書き直すことなく再利用できる。この他、テスト対象機へコンポーネントをインストールしたり、テストのためにアプリケーションを改変したり、モバイルOSをJailbreakしたりするなども不要だ。

 「ePFは、画像認識技術を取り入れることでテストの事前作業を大幅に減らす。その結果、リリースサイクルの短縮やコスト削減に貢献する。最小限の手間とコストで効果的なテストが行えるのは、大きな強みだ」(森安氏)

セッション3〜仮想化技術をテストで生かすHPの新製品群

 セッション3「Performance Lifecycle Virutalization〜HPが提唱する性能テストソリューション〜」に登壇した日本ヒューレット・パッカード(HP)の小宮山晃氏は、HPの性能テストツールの歴史を振り返りながら、実環境に近いテストを支援する最新ポートフォリオを紹介した。


日本ヒューレット・パッカード HPソフトウェア事業統括 ITマネジメントプリセールス本部 テクニカルコンサルティング部 シニアコンサルタント 小宮山晃氏

 HPは、1994年に負荷テストツール「LoadRunner」を提供開始、2006年にはエンタープライズ向けの負荷テストツール「Performance Center」を、2014年にはWebとモバイルに特化したSaaS型テストツール「StormRunner Load」を提供してきた。最近はライセンス体系もシンプルになり、より利用しやすくなっている。例えば、従来LoadRunnerではControllerライセンスとVU(Virtual User)数ライセンスが必要だったが、新ライセンス体系では前者が不要になる。

 そして現在、HPでは新ポートフォリオ「Performance Lifecycle Virtualization」(以下、PLV)を展開している。クラウドやモバイルの実環境をテスト環境でシミュレーションする手法として、仮想化技術を採用する同ソリューションでは、ユーザー、サービス、ネットワーク、データの4要素を基軸に実環境に近いテスト環境の再現を支援する。例えば、実ユーザーの操作の再現、外部サービスの応答時間のシミュレーション、ネットワーク品質のシミュレーション、実データや応答のシミュレーションによるアプリケーション検証などだ。

 小宮山氏は、これらを組み合わせることで、「クラウド上で完結するテスト構成や社内環境と組み合わせるハイブリッド型構成、CI(継続的インテグレーション)ツールを連携させるDevOpsインテグレーション構成など、6つのテスト構成を構築できる」と説明。どの構成でも、PLVで対応可能であることを強調した。

セッション4〜本番データを安全にテストデータへ変換してテスト品質を担保

 セッション4『本番データが安全・高品質なテストデータになる。テストデータ生成ツール「テストエース」のご紹介』では、システムエグゼの大谷内淳氏が本番データをテストデータとして安全に利用できる「テストエース」を紹介した。


システムエグゼ 営業本部 営業企画統括 大谷内淳氏

 「テスト用データは、テストの後工程になるほど、より本番らしいデータが大量に必要になる。だが、対象システムの取り扱うデータによっては本番データをそのまま使うことはできない」。そう述べた大谷内氏は、現状はゼロからテストデータを作成するか、本番データを一部マスキングして利用するかだが、前者は時間や工数が掛かり、後者は情報漏えいリスクが残るなどの問題があると指摘する。

 「テストエース」は、本番データ上の個人情報や会計情報などの機密情報を秘匿化し、本番データの品質そのままに安全なテストデータを作成する。マスキング方法は、名前や住所など31カテゴリの疑似データリストを使って変換する「疑似データ変換」と、独自の変換ルールを作成する「ユーザー定義関数」を用意。データベースの参照時の整合性も維持したまま変換されるので、ほぼ本番環境に近い状況をシミュレーションできる。もちろん、データをゼロから作成する機能も搭載する。

 「テストデータの品質は、テスト自体の品質を決める。高品質なテスト環境を構築するためにも、ぜひテストデータの作成の重要性をあらためて見直してほしい」(大谷内氏)。

事例講演〜弥生が品質にこだわりテスト駆動開発を採用した理由

 事例講演『弥生から新しい弥生へ〜弥生品質への取り組みをご紹介〜』では、弥生の橋本武志氏が製品の品質に対するこだわりや取り組みを紹介した。


弥生 開発本部 システム開発部 シニアプロジェクトマネジャー 橋本武志氏

 中小企業や個人事業主を対象とする「弥生シリーズ」で約60%のシェアを誇る弥生が、製品開発で重視することの一つに“品質”がある。「過去に『弥生会計』で障害が発生し、店頭パッケージの総入れ替えや改修、DVDの再発送などで約5000万円の費用が掛かった」と明かす橋本氏は、「品質は利用者にとっても提供者側にとっても重要であると痛感した」と話した。

 そんな弥生では、上流フェーズからテスト駆動開発(TDD)を採用し、テストと品質の両面をチェックするクオリティエンジニアを配置して品質の維持を図っている。「上流工程からTDDを実践することで、テストできない仕様を作らないようにしている。そして、各プロジェクトにクオリティエンジニアを置くことで、ゴールを守りながら品質向上を極めることを可能にした」と、橋本氏は説明する。

 この取り組みによって、下流工程で問題が発生して手戻りが生じることが減り、結果的に開発スピードの向上にもつながった。

 「弥生は、バグがなく設計書通りに品質が保たれていることと、製品操作の容易性を実現していることが両立できないと、製品をリリースしない」。橋本氏は、方針を徹底することで顧客に安心を与え、信頼関係を着実に築いてきた弥生だからこそのこだわりを熱く語った。

特別講演〜Yahoo!ショッピングのシステム改善事例

 最後の特別講演『「Yahoo!ショッピング」が推進するサービス改善の事例』では、ヤフーの平田源鐘氏が登壇した。


ヤフー ショッピングカンパニープロダクション本部 本部長/テクニカルディレクター 平田源鐘氏

 プラットフォーム開発責任者を13年ほど勤め、2013年にeコマースサービス開発責任者となった平田氏。それからは「新しい領域で苦労の連続だった」という。

 2013年にYahoo!ショッピングでは「eコマース革命」として、「買い物に関わる摩擦係数をゼロにしよう」というプロジェクトを開始。具体的には、月額出展料や売上へのロイヤリティを全部無料にするなどの取り組みだ。その結果、店舗数は2万から12万に成長し、商品数は7000万だったのが1億4000万に増えたという。

 だが、平田氏がeコマースサービス開発責任者となったばかりの時点でのシステムは10年間刷新もせずに使い続けられており、知っている人も少ないシステムだった。またテストについても、eコマースはフロントエンドとバックエンド、ミドルウエアが蜜連携しているので、たとえ一部の改修であってもテストは全システムに及び、改修コストが掛かる。それにもかかわらず、「自動化もされていないような状態だった」と平田氏は振り返る。

 そこで、平田氏は「システムの変更」「マインドの変更」「作り方の変更」という3つの作戦を実践。「システムの変更」では、フロントエンドやバックエンドのプラットフォームを切り離して疎連携にし、APIを経由することで各コンポーネントで改修、開発できるようにした。「マインドの変更」では、開発現場と業務部門とで課題を共有し、開発現場がただ与えられたタスクをこなすのではなく、ビジネスとしての発想を取り入れた開発ができるような土壌に変えた。そして「作り方の変更」では、「便利な機能を提供する」という発想ではなく「使いやすいツールを提供する」という発想でシステムを作り込むようにした。

 「開発したシステムについては、品質テストの実行結果をユーザーに受け入れてもらえるか、課題が解決できているかをきちんと検証することが重要」と、平田氏は言う。「品質テストで終わらせるのではなく、ユーザー確認まで含めてテストと考えている。後は、うまくいったら飲み会でプロジェクトメンバーの労をねぎらうことも大切だ」。そう平田氏は付け加え、講演を終えた。

これからの「品質」との付き合い方

 市場環境変化が速い近年、ニーズの変化に迅速・柔軟に応えることが求められているソフトウエア/サービスの開発現場では、従来の考え方を変える必要性が求められていると感じている読者は少なくないだろう。本セミナーに参加した聴講者からも、開発現場の課題を解決する手掛かりを得ようという熱気が感じ取られた。

 基調講演にあった通り「第3のIT」へと変革する時代において「品質」をどう捉え、どのように向上させるのか――事例講演や特別講演で語られた、変革を行った開発現場の話を踏まえ、各ベンダーが提供する品質向上ツールを選定し、より良い活用方法を模索することが、これからの「品質」との付き合い方を考え直すきっかけとなるはずだ。

 @ITでは、今後もソフトウエア/サービスの「品質」について読者に有益となる情報を追い掛けていきたい。

Copyright © ITmedia, Inc. All Rights Reserved.

[an error occurred while processing this directive]
ページトップに戻る