NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'13 Kansai

実験的アプローチによる現場改善
(細谷 泰夫 氏)

改善とはやってよくなるという意味だが、実際にはやってみないとわからない。従って、改善は現状に対する変化と言える。変化は現状の「なんとか保たれているバランス」を崩す可能性がある。従って、変化を起こそうとすることに対して恐れがある。その恐れを乗り越える必要がある。
「恐れ」への典型的な対処は組織的な合意プロセスを踏むことだが、適用までの投資が大きく、そのため撤退が難しくなる(撤退する決断をためらってしまう)。
また、新手法を適用する場合、自分たちのコンテキストに合わせる必要があるが、実践をしなければどのように適用すればよいのかわからない。現状ではパイロットプロジェクトで未経験の手法を適用しながら自分たちのコンテキストに合わせ、良い結果を出さなければならない。
このような新手法適用時のジレンマを解決する手段として、実験的アプローチを提案する。
実験的アプローチでは3つの原則を大切にしている。

• 「改善のスコープをきわめて小さくする」
• 「実践の結果を素早く得る」
• 「結果を評価して、軌道修正する」

この原則により、上手く言っていれば継続、改善点があれば変更する。効果が割に合わないと判断すれば素早く取りやめる事もでき、新手法適用のリスクを低減できる。また取りやめた場合でも、置かれているコンテキストとその課題と手法の関係性を実践結果から学習することができる。
実験的アプローチには6つの活動がある。

• 情報収集・調査
• 課題の発見
• 課題と手段のマッチング
• 手段の試行
• 手段の実践
• 結果の評価

手段についての情報を、ターゲットを絞らずに収集することで選択肢を増やし、反復的な活動を利用して課題を発見し、課題と手段のマッチングにより特定の対象に絞り込んで調査を行い試行・実践を行う。反復活動のふりかえりの際に手段の効果や改善点について話し合うと効果的である。
上記実験的アプローチについて、原因結果グラフを単体テストに活用した事例とDSL(Domain-Specific Language：ドメイン固有言語)を用いたコード生成の事例を紹介。反復の中で試行を繰り返し、短期間に素早く効果を得る。
事例がうまくいくのは、そのコンテキストに適合した方法になっているが、その必然性を認知しているとは限らない。実験的アプローチは実践を通じてその効果を経験し、コンテキストとのすり合わせを繰り返しながらそのコンテキストに対して必然性のある改善を進めていく手法と言える。

開発手法の開発へと繋がる現場改善の歩み
～自律オブジェクト指向（AOO）開発の裏側～
(岩橋 正実 氏)

手法適用効果から紹介。残存不具合のトレンドを見ると、2009年度には設計やプログラム検証、システム試験において残存不具合が発見されていたが、2012年度には上流不具合検出率が98.7%にまで向上した。工数推移としては、要求仕様に課題があったことから要求分析の工数が増えている。
現場の課題が見えているだろうか？先にゴールが見えないと課題が見つからない。ゴールを達成するために課題を見つけ出して解決する。また、改善に対する障壁には「組織の壁」や「新技術導入の壁」など様々あるが、改善障壁に対し目的や効果の見える化、自主研究とオープン化などの回避ポイントを押さえる。
改善のためにツールや手法を適用しても、適用のみでは現場の課題は解決しない。手法を取り入れることで自分たちの組織の課題にどのように効くのか考え、使い方を技術として蓄える。課題発生源を特定して課題を発生させない方法を構築し、課題解決が進んだら隣の組織に適用するなど一般化させて手法の確立を進める。更に手法をオープンにすることで更なる技術革新に繋がる。また、現場改善のポイントとして、手法導入によりフロントローディングを極め、課題解決型のプロセス定義と形式化を行う。人によるソフトウェア開発作業のバラツキが発生することでテストによる品質確保が困難になる。不具合の発生源を特定し、不具合の作りこみ本質要因を特定、課題を定義する。その課題を解決する仕事のやりかた(手法)を定義し、手法を安定化させるアーキテクチャと課題解決を形式的に実行できるプロセスを定義する。形式化したプロセスを安定化させるためにプロセスをシステム化させる。
開発のバラツキをなくし、課題を再発させない目的指向開発技法を開発した。
エース(Autonomic architecture base embedded software development technique)は組み込みソフトウェアのオープンな開発手法である。
課題発生源を特定して、課題を発生させないアーキテクチャを定義し、課題解決に必要なフレームを文書様式として形式化する。
要求の発生源を特定して要求の目的を定義する。開発側が「こうしたら良い」と思う程度で入れた要求もあり、それがコストを圧迫することもある。要求の価値を見極めることで、仕様の価値が判断でき対応優先度が決まる。仕様の安定化と高品質化により生産性改善と市場要求の対応レスポンスの向上による売上増加に繋がる。
目的指向により、クラス設計を行い、機能競合や例外競合を解決させる。
仕様を安定させることでツール化など実行タスクの最適化が行える。プロセスの標準定義ができ、コア資産を形成できる。
このように、目的を持って継続して改善し続ける。目的を定義して、本質を見極めることが大事。目的達成の価値を判断する。作業目的でタスクを階層的に分類整理してプロセスを定義する。そして各開発工程の作業目的の定義により、最適化を実現する。また、ドメイン非依存のプロセス定義とドメインの分類整理によるカテゴリ単位のプロセス定義を実施する。そのうえで、情報をオープンにして、より良い開発を目指す。

奈良高専セッション
「元気なら組み込みシステム技術者の養成のご紹介」
(土井 滋貴 氏)

「元気なら組み込みシステム技術者の養成」事業および修了企業コミュニティ「GENETコミュニティ」の紹介。
最近の流れとして、Androidやクラウドを取り上げている。また、３Dプリンティングを含めた新しいものづくりに取り組んでいる。

午後のセッションは2つのプログラムが並行していたため、筆者が聴講したセッションについて概要を記す。ユーザ中心設計セッションでは、UCDに関する基本的な知識と活用方法を学ぶことができた。ツール活用セッションの2つの事例発表は、課題をきちんと捉えた上で適切なツールを選択し活用した上で成果を出した様が非常にわかりやすく参考になった。

ユーザ中心設計セッション
「ソフトウェア開発におけるUCD手法の活用」
(渡辺 英範 氏)

UCD(User-Centered Design)の手法の解説と、UCD手法をソフトウェア開発にどのように活かしていくべきかについての渡辺氏による個人考察について話された。
UCDは一般的にはHCD(Human-Centered Design)と呼ばれる。京セラでは「HumanよりもUserのほうがふさわしい」としてUCDと称している。
規格としては、以前はISO13407が適用されていたが、最近はISO9241-210が適用される。商品そのものの使いやすさだけではなく、ユーザが商品に興味を持つところから商品が回収されるまでのすべての体験において満足させることを目指している。例えばマニュアルが複数冊あるとして、マニュアルの色を変えることで電話サポートの際に(「青のマニュアルを御覧ください」といったように)どのマニュアルを見ればよいか伝えやすくなる。そのように商品そのものだけでなく周りの物事にも着目する。
UCDで大切なことは、適切なプロセス・コアメンバーのいるチーム・手法である。しかしながらUCDの手法やUX(User eXperience：ユーザ体験)をデザインするために必要なスキルはとても多く、すべてを取得するのは相当難しい。よって先人の知見を活用するとよい。学会で発表される学際的な取り組みや、セミナーやシンポジウムで発表される先行企業の取り組みなどを活用するとよい。
UCDのポイントは、デザインと評価を繰り返すことである。Think-Make-Checkのサイクルを回すことになるが、これはどこから始めても良い。考えているだけでは説得力が無いため、まずは作って評価してもらうことが重要。早い段階で確認し、ユーザビリティの問題に対する解決をとる。早い時期に短期間でプロトタイプを作成する。プロトタイプにはお金と時間はかけないこと。ラフなペーパープロトタイプで構わない。

ツール活用セッション
「ソフトウェアの品質向上に資する、開発・運用現場の情報管理」
(赤羽根 州晴 氏)

ITS(Issue Tracking System)導入による現場改善の事例を紹介。
現場の背景として、派生開発が多く、開発運用人数もコミット数もコードの変更追加もかなり多い。複雑なシステムとなり全体を把握する人は皆無である。そのような状況では過去の経緯や履歴の記録が必要だが、それらは各人のローカルPCやメールボックスに保管された状態となっていた。台帳共有についても後日理解することができない状態になっていた。従って障害件数も日常的に多かった。オープンな情報管理の必要性を感じ、そのための専用システムの必要性も感じるようになった。
専用システムを導入することで、全システムの各工程で生じた情報群が、①意味ある連鎖、参照構造を保持し、②関連ファイル、コード、設計書、メールと共に格納され、③検索や抽出が手軽にできる感覚を実現できたら、結果として業務システムに関係する全員が幸せになれる。
そこで、上記3つの課題に対する施策として、Redmineの導入を行った。
チケットという規格化された容器に入れ、ITSに格納することで、投入・連鎖・検索がしやすくなる。各種資産とシステム・業務を連鎖することで(部門、プロジェクトを横断する申請書などの)処理スループットが向上する。すべての事案に対して恒久的な一意のIDを付与することで、あらゆるドキュメントにIDが記載され、ITSの外部に向かって連鎖が拡大する。ITSが情報の中心となり、すべての情報がつながり始めた。
結果として、日常的なシステム障害から解放され、残業も減り定時後や週末のオフィス風景が変わった。

「リスク駆動開発で、SPIN初実践とその成功
　～チームソフトウェアプロセスとふりかえり～」
(徳 隆宏 氏/山内 美絵子 氏)

信頼性を第一に求められるプロダクトに対し、「早期にリスクを撲滅できるか」「デバッグ時間を短縮できるか」という2つの課題に取り組んだ事例を紹介。
状態遷移とスレッド数の多さと複雑な構造に対する検証に着目し、モデル検査ツールSPIN(Simple Promela Interpreter)を導入した。
実施者はSPINをはじめて学ぶことになったが、SPINによりマルチスレッドの確認が可能となり楽しめたそうだ。SPIN導入における課題としては、SPINを用いるとどこまでもモデルを作りこむことができてしまう(検査数が爆発する)点である。そのため、予め不具合を想定してその不具合に絞り込んだ箇所に重点を置いて作りこむという策をとった。
SPIN導入はプロジェクトの見積もりの段階では計画に入っていなかった。SPIN導入に踏み切った背景として予め徳氏が試用しており大体の見積もりが可能であった事がある。そういったプラクティスの「素振り」が計画変更リスクに向き合うために 重要である。
結果としてコストや期間の超過もなく成功し、SPIN導入により見積もり時より浮いた時間が生じたことでふりかえりの時間もとれた。
しかしながら、SPINも銀の弾丸ではない。今回はうまくいったが、使いこなせずうまくいかないこともある。重要なことは継続的にリスク管理を行い成功し続けることである。

並行して行われたセッションは残念ながら聴講できなかったが、SNSの投稿やふりかえりセッションでの聴講者の声により興味深い内容であったという雰囲気が伝わった。

• 事例発表１ - テスト自動化セッション
• 事例発表2 - テスト実践セッション

テスト自動化セッションではTABOK（Test Automation Body Of Knowledge：テスト自動化知識体系）の紹介および自動化に対する誤解と自動化の導入ポイントをコント形式で楽しく解説し、その後、組み込みシステムに対する自動化環境構築の事例発表につなげており、聴講者にわかりやすく伝わった様子が伺えた。
テスト実践セッションでは、テスト設計コンテストを通じて学んだことを現場に活用した事例と、テスト管理ツールの自作事例についての発表があった。より現場に近い発表が行われた様子で、後のふりかえり企画のグループトークや情報交換会において、興味を持ったという声を多く聴いている。

夕方からは、"「聞いてみよう、共有しよう、広げよう！」JaSST Kansai Cafe/Clinic"と称して、ふりかえりおよび情報交換会が行われた。

夕方のふりかえりセッションでは、まず参加者に「ふりかえり/もっと聞きたい！」カードに、当日のセッションの感想や「やってみよう！」という内容を記載していただき、5人1組のグループに分かれてお互いに共有し、意見交換が行われた。
午後のセッションが2つに分かれていたこともあり、聴講できなかったセッションについても情報を得ることができたことは嬉しかった。
次に、先述のように、「もっと聞きたい！ボード」に貼られた付箋の中から代表2件について、講演者やゲスト回答者による回答が行われた。

Q1：

(改善を)諦めないココロを身につけるにはどうすればよいか？

A1：

「目的意識を持つことが1番。最終ゴールとして自分はどうしたいのか？そうなったらどんなに楽か？というイメージを持つこと。最終ゴールが華やかであれば諦めたくなくなる。」
「目的を達成する前に次の目的を定め、段階的に成長させる。」
「いろいろ試したい、楽しみたい、という気持ちが大事」
「制約はそのときどきあり、その時点で変えられないこともある。諦めず気長にそれでもしつこく(1週間に1度くらい)言い続ける。徐々に変えていく。」

Q2：

欠陥の分析が上手にできず類似バグが頻発している。プロジェクト内にたまったノウハウを開発にフィードバックできていない。

A2：

「欠陥が溜まってから分析していないか？欠陥が見つかった時点で溜めずにチーム内で共有するほうがよい。その際、きちんと分析しきることを目指さない。「今コレが要注意！」という欠陥トレンドを見せる。」
「課題をきちんと把握すること。類似バグが頻発していることが判っているなら分析はできているのではないか？ノウハウとは本当にノウハウなのか？など。」
「大事なことは「勿体無い、また欠陥を出しちゃったな。」という「勿体無い気持ち」をチームで共有し、「また」とは何かを考えること。」

致し方ないことだが時間が限られていたことで更に「もっと聞きたい！」状態のままになってしまった。しかしこれが後の情報交換会の活性化に繋がったと思う。
情報交換会では、講演者およびゲストごとにテーブルが設けられ、参加者がテーブルを巡り講演者に質問や悩み相談を行う場となった。また、参加者同士の意見交換も活発に行われていた。飲み物と軽食が用意されていたが、話に夢中になっている人のほうが多く見受けられた。
こうして話も尽きず盛況のうちに時間となり、シンポジウムが終了した。

今回のシンポジウムは至るところに趣向が凝らされており、現場の改善についてじっくり考え、語り合い、一日とても楽しく過ごすことができた。
一方で、もう少しテストに関する情報が欲しいという声もいくつか聴いた。テストに特化した改善について、今後より多く事例発表がでてくることを期待しているし、筆者自身もまた、今回のシンポジウムで得た情報や知見をテストの業務に上手く適用して発表できるような活動を行いたいと思っている。