pr

　＠IT情報マネジメント編集部主催の『ソフトウェアテスト・ミーティング2009〜品質とコストを両立 “やる気”を引き出すテストアプローチ〜』が、2009年9月17日に東京・秋葉原UDXで開催された。

　日常生活やビジネスにITシステムが深く浸透している近年、システムの稼働を支えるソフトウェアには、ますます高い品質が求められている。加えて、ビジネスの世界では、年々激化する市場競争に昨今の不況も重なり、開発のスピード向上、コスト削減という要件も重視されるようになった。この、品質、スピード、コストという3要件を満たすためには、方法論やツールだけではなく、プロジェクトを円滑に遂行する開発体制や、開発者のスキルなどもポイントとなる。そこで本イベントは“人”にフォーカスし、3要件の実現に向けた開発体制の在り方などを紹介した。

　当日は、テスト技術力の向上を啓蒙しているソフトウェアテストシンポジウム「JaSST （Japan Symposium on Software Testing）」の面々による座談会も実施した。「テストツールの導入以前に、テスト設計・分析のスキルを身に付けておくべき」「ツールが想定している開発プロセスと、自社の開発プロセスを比較して、使いやすい実装形態を考慮すべき」など、テストツールを使いこなすための数々のヒントが飛び出し、200人を超す受講者らも熱心に聞き入っていた。以下では、このほかの2つの講演を紹介する。

イベントレポート インデックス

『“めげない、めげさせない”チームマネジメント〜情工哀史にならないために〜 』‐ デバッグ工学研究所

『ツールを活用した高い品質および開発生産性の実現 』　 ‐ マイクロソフト

基調講演 『“めげない、めげさせない”チームマネジメント 〜情工哀史にならないために〜 』

　基調講演ではデバッグ工学研究所の松尾谷徹氏が登壇し、ソフトウェアテストの課題と、開発現場の職場環境を改善するポイントについて講演を行った。

　松尾谷氏は現在のテスト技法について、「近年のシステムの複雑化、大規模化の流れに追い付いてない」という。1990年代前半まで、単一のベンダがOSからデータベース、ハードウェアまで、システムを構成する全製品を手掛けるスタイルが一般的だったが、1990年代後半から、異なるベンダ製品を統合して1つのシステムを構築するスタイルに変わった。これを受けて、「従来のように、各製品単独で起こり得る不具合を防止するための仕様ベース、リスクベースのテストだけではなく、各製品をつないだときに起こり得るリスクを想定した“構成ベース”のテストも行うべきだ」（松尾谷氏）という。

デバッグ工学研究所 代表 松尾谷 徹氏

　具体的には、システムが機能を実行するための情報処理シナリオが複数の製品にまたがっている場合、処理がシナリオ通りに進むことを試す「順序ベースのテスト」、各製品の機能を組み合わせた際、狙い通りに機能するか、パフォーマンスが出るかを調べる「機能／非機能のテスト」、さまざまな組み合わせパターンによって引き起こされる不具合を抽出する「無限の組み合わせによるテスト」などが必要だという。

　「現在のテスト技法は、1978年に米国で発刊されたグレンフォード・J・マイヤーズ（Glenford J. Myers）の著作『ソフトウェア・テストの技法』（グレンフォード・J・マイヤーズ＝著／松尾正信＝訳／近代科学社／1980年刊）がベースになっている。つまり基本は30年以上も変わっていない。飛躍的に進歩したシステムに合わせて、テスト技法の発展も考えるべきだ」（松尾谷氏）

　一方で、松尾谷氏は日本のIT業界の現状について、「日本では新3Kなどと呼ばれているが、世界的にはIT技術者はクリエイティブな職業と認知されている。これは職種そのものではなく、日本の職場環境に問題があるはずだ」と指摘した。

　そうした見解に基づき、松尾谷氏が代表を務めるデバッグ工学研究所では、プロジェクトチームにおける自己の在り方や、パートナーとの関係性についてアンケートを取る「パートナー満足度調査」を2001年から継続的に実施してきたという。その結果、自己実現、自分への評価、リーダーとの関係性、メンバーとのコミュニケーション、プロジェクトの進め方の5項目が労働意欲に大きな影響を与えていることが分かった。

　「これまでの調査で、5項目の満足度が低い職場ほど生産性が低いという傾向が確認できている。そしてこれらは自己実現、自己評価といった内因的な要素と、他者とのかかわりという外因的な要素に大別できる。すなわち“めげない力”と“めげさせない環境”が、ソフトウェアの品質や開発効率を大きく左右するといえるだろう」（松尾谷氏）

　松尾谷氏はこのように述べ、それぞれに対する方策を紹介した。まず「めげさせない環境」を作るためには、「プロジェクトチームのチームワーク作りが必要だ」という。その参考資料として、心理学者のB・W・タックマン（B. W. Tuckman）が提唱した「チーム形成の5段階モデル」を紹介した。

　これによると、チームの形成から解散までのライフサイクルは、各メンバーが互いの役割を模索する「形成期」、各自の役割をめぐって対立が起きる「騒乱期」、行動規範が確立する「規範期」、チームの目的達成に向けて全エネルギーが注がれる「実行期」、さまざまな原因でチームの有効性が損なわれる「散会期」の5段階で推移するという。

　「日本ではプロジェクトチームを形成する際、メンバーを集めて、すぐ業務を行わせるケースが一般的だ。しかし、各人の役割や関係性を整えないまま業務を始めると、頑張る人ほど仕事が増えて疲弊したり、役割をめぐって対立が起きたり、自分の仕事に集中するばかりに孤立したりといったストレスフルな環境になる。つまり、日本の多くのプロジェクトは、騒乱期から脱出できないまま開発作業を続けている」（松尾谷氏）

　ちなみに、かつて米国ピープルソフト（現オラクル）では、チームビルディングを担う人材をチーム内に設定し、ホームパーティを開くなどして結束を高めることが通例になっていたという。日本国内でも1泊2日程度の合宿を行っている事例がある。松尾谷氏は「工数を削りコストをかけてでも、良好な対人関係を作る準備を行うべきだ」と強調する。

　一方、「めげない力」をはぐくむためには、「自分で自分の商品価値を上げる意欲が大切だ」という。日本のIT企業は新人教育にはコストを掛けるが、入社3年目以降はOJTに移行するケースが多い。加えて、企業と社員の雇用関係が弱体化し、転職が当たり前となった現在、1社当たりの在籍期間が短期化し、OJTが機能していない例も多いためだ。

　「つまり、スキルアップは会社には依存できないということだ。自己責任でスキルを磨く――特に、知識を学ぶだけではなく、状況に応じて最適な方法論を選び、実践できる力、関係者に説明する力を会得することが大切だ。そうした力が良好なチームワーク作りにもつながっていく。逆に、会社への依存心を断ち切らない限り、“新3K”などと呼ばれているような“安価で付加価値の低いサービス提供者”の立場に甘んじるしかない」（松尾谷氏）

　松尾谷氏は、ソフトウェアの開発品質を高める原動力は、「1人1人が自立したエンジニアになることだ」と力説。高め合える仲間を作り、自己責任でスキルアップしていく姿勢があれば、「日本のIT技術者も、他国と同様にクリエイティブな職業として認知されるはずだ」と締めくくった。

マイクロソフト 『ツールを活用した高い品質および開発生産性の実現 』

　マイクロソフトのセッションでは近藤和彦氏が登壇し、チーム開発を支援する製品群「Microsoft Visual Studio Team System 2008」（以下、VSTS）シリーズのうち、ソースコード管理機能などを持つサーバ製品、「Team Foundation Server」（以下、TFS）を使った、ソフトウェア開発の品質、効率向上の方策を紹介した。

　近藤氏は冒頭で、短納期化、低コスト化、品質向上の要求が強まっているソフトウェア開発の現状を指摘し、「この問題を解決するためには、開発メンバーの相互理解やスキルアップ、有効な開発手法やテスト技法、それを支援するテクノロジー、これらを三位一体でとらえ、3つの要素をバランスよく高めていく姿勢が大切だ」として、TFSの段階的な活用を提案した。

マイクロソフト株式会社 デベロッパー＆プラットフォーム統括本部 開発ツール製品部 エグゼクティブ プロダクト マネージャ 近藤 和彦氏

　TFSはソースコードの変更管理、各スタッフの作業項目管理、プロジェクト管理、レポーティング、自動ビルドなどの機能を持つ。これらを現在の開発プロセスや開発者のスキルなどに応じて段階的に取り入れることで、「1歩先を行くソースコード管理を実現し、ソフトウェアの品質向上、開発作業の効率化に向けて、着実に開発プロセスの高度化が狙える」という。

　その第1段階が「ソースコード管理の確実化、効率化」だ。TFSはソースコードをチェックインするたびに、ファイルやフォルダ、変更日時、変更を行った開発者など、修正に関する情報をひとまとめにして記録する変更セット機能を持つ。タスクやバグ表といった関連データにも自動的にリンクを張るため、「いつ、誰が、どんな目的で修正したのか」を詳細に把握できるほか、 「一度残された記録は変更・削除できないため、コンプライアンス対策としても有効だ」という。

　また、正式に記録を残すことなく、一時的にソースコードファイルをTFSに保存できるシェルブ機能も用意。これにより、サブグループ間でソースコードレビューをする際など、「チェックインせずにソースコードを共有したい」というニーズにも応えたという。

　第2段階は「自動化機能の活用」で、これには2つの機能がある。1つはチェックイン・ポリシー機能だ。多くの企業では、ソースコードをリポジトリにチェックインする際、開発ポリシーを徹底させるために、「コード分析を行ったか」「単体テストを行ったか」といったチェック項目を用意し、確認してからチェックインするというルールを定めている。ただ、繁忙期にはこのチェックがなおざりになりがちなことも多い。しかし、この機能を使えば、「あらかじめ設定した開発ポリシーを自動的にチェックして、ポリシーを満たしていない場合、チェックインを阻止するとともに、その理由をエラーメッセージとして表示する。これにより確実に品質を確保できる」（近藤氏）という。

　もう1つはTFSの目玉ともいえる自動ビルド機能だ。近藤氏はこの機能について、「エクストリーム・プログラミングの1プラクティスとして注目されている、“継続的インテグレーション”をサポートするものだ」と解説する。

　「従来、コードの統合作業は開発工程の後半にまとめて行うのが一般的だった。しかし、統合を後で行うほど問題の原因究明が困難になるほか、コンポーネントの依存関係により思わぬ不具合が生じる場合もある。だが、開発の初期段階から小刻みに、繰り返し統合作業とテストを行う継続的インテグレーションなら、前回のチェックイン時との期間が短いため、エラー原因を容易に究明できる。その点、TFSの自動ビルド機能は、ソースコードをチェックインするたびに、あるいは設定した時間に、単体テスト、コード分析をしたうえでビルドを自動的に行う。つまり、TFSがこの手法を実現することで、開発の品質、効率向上を大きく後押しする形だ」（近藤氏）

　そしてTFS活用の第3段階は「プロジェクト管理への活用」だ。TSFは管理者用の作業項目管理機能を持ち、1つの管理画面から各メンバーへのタスク指示や、バグ修正依頼など、さまざまな作業指示を出せる。また、管理者がメンバー全員の作業内容を一覧できる一方で、各メンバーがTFSにアクセスすると、全作業項目の中から自分が担当している作業項目を検索できる。すなわち「メンバー全員にプロジェクトが“見える化”される」（近藤氏）。

　さらに、TFSに格納されたデータを基に、任意の時点のプロジェクトの進ちょく状況を分析、グラフなどを使って可視化するレポーティング機能もある。これにより「管理者がチームメンバーに状況を聞いて回り、Excelなどで管理するといった手間が省けるうえ、正確な情報をリアルタイムでつかめるようになる」（近藤氏）という。使い慣れたインターフェイスでこの機能を利用できるよう、Microsoft Office ProjectやExcelとTFSを連携できることもポイントだ。

　近藤氏は、「導入効果を最大化するためには、まず自社の開発プロセスを把握し、それに合わせてツールの機能を活用することが大切。それとともに、積極的に有効なプラクティスを取り入れ、メンバーを教育し、プロセスを高度化させる姿勢も重要だ。その点、TFSでは継続的インテグレーションを、VSTSなら近年注目されているテスト駆動開発を支援する機能も備えている。ぜひこれらの製品を使って、自社のペースで、着実に開発体制のステップアップを狙ってほしい」とまとめた。

スポンサーリンク

マイクロソフト 富士通ソフトウェアテクノロジーズ

［ ▲ 記事の最初に戻る ］

提供：マイクロソフト株式会社
株式会社富士通ソフトウェアテクノロジーズ
企画：アイティメディア 営業企画
制作：＠IT情報マネジメント 編集部
掲載内容有効期限：2009年10月31日