SPEAK-IPA を用いた設計指向による公開アセスメントの試行 佐藤克,山内一資,福田仁志,石津和紀,倉田智穂,村上孝,近藤聖久,北野敏明,小川清† Trial and report on design oriented open process assessment with SPEAK-IPA. Sato Masaru, Yamauchi Kazumoto, Fukuda Hitoshi, Ishidu Kazunori, Kurata Chiho, Murakami Takashi, Kondo Kiyohisa, Kitano Toshiaki, Ogawa Kiyoshi ねらい 基本的な社会調査手法に基づいて、オープンソースが高い信頼性を要求される大規模複雑なシステ ムの一部に利用される為の課題抽出を公開アセスメントにより試行した。 キーワード アセッサ，改善，オープンソース，内部関与，外部観察， Target: Extraction challenge for is used for part of a larger complex system open source high reliability is required with public assessment based on the basic social research methods, Keywords: assessor, improvement, open source, Internal involvement, External observation,. １．想定する読者・聴衆 ソフトウェア・システムの設計者，利用者をはじめ ソフトウェア部品，ツールなどの購入担当を含むすべ ての関係者。 3．課題 ●オープンソース プロセスアセスメントなどの社会調査では，診断す る組織の外部(組織に関係のない)から見て診断する外 部観察法と、診断する組織の内部から見て(共に作業を 2．背景と目的 オープンソースはその特質上不特定多数の利用を想 定し、時には自動車の様な大規模複雑なシステムの一 部に組み込まれ、高い信頼性が要求されることもある。 しかし公開される情報はソースコードのみである事が 多く、オープンソースの設計ではソースコードが設計 書であるという考えも有る。 そこでオープンソースである TOPPERS/ssp を対象に、 SPEAK-IPA を用いてアセッサ資格やそれに相当する技 術を用い、インタビュー又は文書レビューにより以下 の 2 点を公開アセスメントする。 1)成果物がソースコードだけの場合、設計意図を理解 するために不足している情報があるのか 2)設計の方向性を定めるにはどうするか(設計指向) 公開アセスメントのアセッサは、特定の企業からで はなく、システム技術研究会に参加する様々な企業の メンバーによって構成した。 実施して)診断する内部関与法という二つの手法があ る。オープンソースである TOPPERS/ssp は Web 上に情 報が公開されている。この様に公開された情報を基に 診断を行う外部観察法だけでなく、インタビューしな がら実際に作業を一緒に行う内部関与法を行えば，入 力と出力の両方を確認でき，実施の証拠を別に用意す る必要はないという主張を確認できる。しかし TOPPERS/ssp プロジェクトは大規模なチームでではな く、優秀な設計者が個々にソースを書いている状況で あり、プロジェクトへの内部関与は難しい。また、開 発現場が散在しており、利用しているツールや成果物 の確認、インタビューは困難である。更に、TOPPERS/ssp はオープンソースプロジェクトであるが，その設計活 動を支援する出資者，情報提供者によっては，すべて の活動を公開できないという制約条件もある。 ●アセスメント 企業間をまたぐアセッサチームでは、用語の違いな ど、メンバー間に認識のずれが大きくなるとう課題が ある。 † シ ス テ ム 技 術 研 究 会 System Engineering Study Group, Nagoya Municipal Industrial Research Institue, 3-4-41 Rokuban Atsutaku Nagoya, 456-0058 Japan a) E-mail: [email protected] ●ソースコードと設計書 TOPPERS/ssp の中には、オープンソースのプログラマ 1 [テキストの入力] [テキストの入力] にとってはソースコードが設計書であるという考えが [テキストの入力] バーでの理解がしやすくなった。 ある。オープンソースの利用者にとって、その主張が ●ソースコードと設計書 許容出来ているのか明確ではない。その一方でプロジ ソースコードが設計書であるという主張ではあるが、 ェクトの中には HDL(ハードウェア記述言語)において 利用を大規模複雑な、或いは/及び高い信頼性が要求さ 言語での記述が設計で、HDL が回路図になるように，ソ れる領域を含めるのであれば、利用者側の視点を考慮 ースコードもなんらかの図表があった方が理解しやす すると、設計検証を行うには十分とは言えない。利用 いという考え方もあり、見解が明確ではない。 者とのコミュニケーションにおいて、ソースコード(テ キスト)だけでなく、アセスメントの結果と同様、テキ 4．提案・実験 ●オープンソース 外部観察法と従来のアセスメント手法である、内部 スト以外の図が有効である。 6．まとめ・今後の課題 事情に詳しいプロジェクトメンバーへのインタビュー TOPPERS/ssp のオープンソースを自動車等の、高い信 を行う。オープンソースでは作業の時間も比較的自由 頼性が要求される大規模複雑なシステムの一部に利用 であり、成果物は既に公開されていることから、アセ される為には、設計書はソースコードだけでなく、利 スメントによるプロジェクトへの負担は大きくない。 用者側が求める設計書を提示する必要がある。ソース 毎月１回のインタビューを 3 回(9 月～11 月)行う。 の利用方法や規模によっては、ソースのみで許容でき ●アセスメント る部分も有るかもしれない。しかし、利用選択の初期 アセスメントメンバー間の認識のずれを極力小さく の段階でソースコード以外の成果物が無い事が選択肢 するために、従来のアセスメントには無かった図も用 いてコミュニケーションを行う。 から外れる要素になるリスクは低くない。 今回は残念ながら内部関与法によるアセスメントは ●ソースコードと設計書 実現できなかったが、オープンソースの web 上の利用 TOPPERS/ssp が今後高い信頼性要求を含む大規模複 者に視点をおけば、web 上の利用者と同じ視点での外部 雑なシステムに利用されていく為に，ソースコードの 観察法によるアセスメントは有効であると考える。し ようなテキストでは表現が難しい状態遷移図，シーケ かし、オープンソースを材料としてプロジェクトに参 ンス図、ユースケース図等，作業を効率的にする文書 加して利用する企業にとっては、内部関与法によるア 化の意味を検討する。 セスメントではない為、少し物足らない結果となって いるかもしれない。 5．結果 公開アセスメント，オープンソース，企業間をまた ぐアセスメントチームという普段と違う３つの制約条 ●オープンソース 件の中で編成されたアセッサチームの活動は，より複 外部観察法と従来のアセスメントの併用によりアセ 雑な事業への対応経験をするために有効であった。 スメントを行った結果、インタビューによる情報のエ ビデンスを公開情報から得られない場面が多かった。 公開情報がソースコードであることから、特に管理プ 文 [1] (SEC BOOKS) 情報処理推進機構ソフトウェアエンジニアリ ロセスのエビデンスは皆無であり、インタビューから の情報に依存する結果となった。 ●アセスメント オープンソースを題材にし、公開アセスメントにより、 アセスメントの工夫を表に出す事が出来た。具体的に は、従来のアセスメント報告書は文章のみの報告だっ 献 プロセス改善ナビゲーションガイド―プロセス診断活用編 ングセンター ,2007 [2] ISO/IEC 15504 part5, ISO, 2008． [3] 情報処理推進機構,SPEAK,2012 [4] プロセス改善ナビゲーションガイド ベストプラクティス編 (SEC BOOKS)情報処理推進機構ソフトウェアエンジニアリン グセンター ,2008 たが、企業をまたぐアセスメントチームで実施した事 により、事業目標とのつながりが見える実用的な図が 開発できた。この模式図によって、業種が異なるメン 2
© Copyright 2024 ExpyDoc
