ソフトウェア品質シンポジウム（SQiPシンポジウム）2011。
当ブログは「ソフトウェアの品質を学びまくる」と銘打ちながら、SQiPシンポに一度も参加したことがない、まったく学びまくっていないという状態でしたが、ようやく参加することができました。
まだ論文や発表資料が一般公開されていないので、事前の発表概要の内容から大きく逸脱しない程度に、その様子をお伝えしようと思います。
当ブログは「ソフトウェアの品質を学びまくる」と銘打ちながら、SQiPシンポに一度も参加したことがない、まったく学びまくっていないという状態でしたが、ようやく参加することができました。
まだ論文や発表資料が一般公開されていないので、事前の発表概要の内容から大きく逸脱しない程度に、その様子をお伝えしようと思います。
ソフトウェア品質シンポジウムとは？
公式サイトを見ると、こうあります。
| ソフトウェア品質シンポジウムは、ソフトウェア品質に関わる全ての方々が一堂に会し、現場で役立つ実践的な技術や経験、ノウハウ、研究成果を発表し意見交換を行う場です。 |
この「現場で役立つ」というのがポイントで、あまり衒学的な発表はありません。現場で実際にやってみたこと、そこから導いたことの発表なので、「これはうちでもできるかも？」と期待させてくれるようなものがたくさん。
ただ発表時間が短いので、「ここに苦労した」とか「これをやったけど全然うまくいかなかった、やらない方がいい」というネガティブ方向の話があまりないのは、少しだけ物足りないです。
ただ発表時間が短いので、「ここに苦労した」とか「これをやったけど全然うまくいかなかった、やらない方がいい」というネガティブ方向の話があまりないのは、少しだけ物足りないです。
1日目の構成は、初めにオープニングと基調講演。次にブースが分かれて複数のセッションがあり、その後にSIG（Special Interest Group）があって、最後に情報交換会でした。
セッションの時間帯は大きく2つのスロット、4つの会場に分かれています。うちB会場のテーマは「派生開発」と「レビュー」。C会場のテーマは「組織プロセス改善」と「定量的データの分析」。わたしはこのうち、「派生開発」と「定量的分析」をメインに聞くことにしました。
セッションの時間帯は大きく2つのスロット、4つの会場に分かれています。うちB会場のテーマは「派生開発」と「レビュー」。C会場のテーマは「組織プロセス改善」と「定量的データの分析」。わたしはこのうち、「派生開発」と「定量的分析」をメインに聞くことにしました。
なお、今年から本シンポジウムは、PDUの対象となりました！これはPMP資格を維持しなければいけない方には大きな朗報。2日間フルで参加すれば、12.25ポイントのPDUを稼ぐことができます。3年間で60ポイントなので、これはデカイ。
派生開発
「派生開発」では3つのセッションがありました。どれも、XDDPをベースにしたもの。XDDPは「eXtreme Derivative Development Process」の略で、株式会社 システムクリエイツの清水吉男さんが提唱されている、派生開発における開発方法論です。
実はこのセッションの会場には、清水さんご自身がいらして、コメントもいただきました。
曰く、派生開発は多種多様であり、清水さんの本でもすべて網羅できているわけではない。XDDPをどう使うとうまくいくのか、どんどん研究してもらうと嬉しいとのことでした。今回の発表を職場に持ち帰り、うまく適用してみたいものですね。
B1-1：XDDPによるデグレード防止効果の検証とその効果を高めるための方法
株式会社 山武の関野浩之さんによる発表。XDDPを適用するうえで、熟練者と非熟練者の差をどう埋めるか、という課題への取り組みです。
その答えの1つが、過去のノウハウの集積であるチェックリスト。
「チェックリスト」という言葉を聞くだけで拒否反応を示す人も多いでしょう。プロジェクトに特有な要素を排除するために抽象化し過ぎた項目、多くが「対象外」項目となる一覧・・・。
チェックリストが必要とは分かっていても、適用せよと言われると一気にしょんぼりしてしまうあの逆高揚感。関野さんの言葉がそれを象徴していました。
「チェックリスト」という言葉を聞くだけで拒否反応を示す人も多いでしょう。プロジェクトに特有な要素を排除するために抽象化し過ぎた項目、多くが「対象外」項目となる一覧・・・。
チェックリストが必要とは分かっていても、適用せよと言われると一気にしょんぼりしてしまうあの逆高揚感。関野さんの言葉がそれを象徴していました。
| 「チェックリストは資産だと、もう一度信じてみる」 |
ものすごく、心に響きました！
チェックリストの悩みとして、項目が肥大化すること、そのせいで対象となるチェック項目を効率的に探し出せないことがあります。
チェック項目を体系化するために、多くの組織では項目を、いくつかのカテゴリーに分けているでしょう。が、それではうまく行っていない。何故か。
それは「機能」を軸にカテゴリーを決めているからではないか。派生開発では「何をどう変更したか」がポイントなのだから、その「何をどう変更」したかを軸にするのかが正しいのではないか。
チェック項目を体系化するために、多くの組織では項目を、いくつかのカテゴリーに分けているでしょう。が、それではうまく行っていない。何故か。
それは「機能」を軸にカテゴリーを決めているからではないか。派生開発では「何をどう変更したか」がポイントなのだから、その「何をどう変更」したかを軸にするのかが正しいのではないか。
変更の内容を一般化したものを「変更特性」と呼んでいます。
派生開発で行う各変更における変更特性を特定し、その特性に関するチェック項目だけを拾う。これで効率的にチェックリストを活用できるよういうことです。
これは別に、派生開発に特化したチェックリストでなく、既存のチェックリストからでも同じことができるとのことなので、まずは手元のリストに眺めて考えてみようと思います。
派生開発で行う各変更における変更特性を特定し、その特性に関するチェック項目だけを拾う。これで効率的にチェックリストを活用できるよういうことです。
これは別に、派生開発に特化したチェックリストでなく、既存のチェックリストからでも同じことができるとのことなので、まずは手元のリストに眺めて考えてみようと思います。
B1-2：派生開発における要求視点を活用した仕様欠陥検出方法の提案
株式会社 日立ハイテクソリューションズの鈴木孝輔さんによる発表。
上流工程でできるだけ品質を作り込むために、設計書の不良をしっかり取り除く必要がある。で、その設計書の不良の一部は、変更要求に至った背景の情報を与えることで、除去できるのではないか、という発想です。
上流工程でできるだけ品質を作り込むために、設計書の不良をしっかり取り除く必要がある。で、その設計書の不良の一部は、変更要求に至った背景の情報を与えることで、除去できるのではないか、という発想です。
そのために作るのが、「変更要求マトリクス」。通常の開発における成果物と、XDDPにおける成果物の1つである変更要求仕様書をマトリクスで紐付けることで、要求と変更内容の関係を、明確に表現しようという試み。
この工夫により、実装漏れ・テスト漏れの防止ができるとのこと。トータルの工数としてはあまり変わらないが、習熟に連れて工数の削減も期待できそうとの報告でした。
この工夫により、実装漏れ・テスト漏れの防止ができるとのこと。トータルの工数としてはあまり変わらないが、習熟に連れて工数の削減も期待できそうとの報告でした。
B1-3：変更要求仕様書を活用した未然防止方法の提案
株式会社 デンソーの安田隆司さんによる発表。個人的には、今回のシンポジウムで一番興味をもった内容でした。
XDDPは派生開発における方法論です。一方で、DRBFM（Design Review based on Failure Mode）は、デザインレビューの手法の1つで、「何を変えることでどんな壊れ方をするか」という故障モードをベースに心配点を潰していくもの。これも、ソフトウェアの変更の際に適用するものです。
つまり、XDDPとDRBFMは親和性が高そう。この発表では、DRBFMの適用における課題を、XDDPとDRBFMの成果物を結合することで解消しようというものです。
つまり、XDDPとDRBFMは親和性が高そう。この発表では、DRBFMの適用における課題を、XDDPとDRBFMの成果物を結合することで解消しようというものです。
安田さんが指摘されたDRBFMを使ううえでの悩みは、とても共感できます。「心配点」を洗い出す際に、先に実装上の欠陥（つまりバグ）から思いついて、その欠陥を作ったらどういう故障になるか、という流れになってしまう。それだとうまく、問題を挙げられません。
この流れを、正しくするために、「どう変更するか」ではなく、「何を、何故変更するか」という、お客様寄りのドキュメントから心配点を洗い出すことにします。
この流れを、正しくするために、「どう変更するか」ではなく、「何を、何故変更するか」という、お客様寄りのドキュメントから心配点を洗い出すことにします。
ここで注目するのが、「変更要求仕様書における「仕様」と、DRBFMにおける「変更」とは、同じものである」という点。つまり、2つのドキュメントはマージできるのです。これによって、DRBFMの要求視点と、XDDPの実装視点の両方から、問題点を洗い出すことができます。
わたし自身、年末ごろに1つ、派生開発がありそう。その基本設計の際には、この考え方を必ず適用してみるつもりです。DRBFMが形骸化する前に、必ず・・・！
わたし自身、年末ごろに1つ、派生開発がありそう。その基本設計の際には、この考え方を必ず適用してみるつもりです。DRBFMが形骸化する前に、必ず・・・！
次回は「定量的データの分析」のお話を書きます。
