easeプロジェクト
                          English

イベント

第1回EASE国際フォーラム Q&Aセッション(補足)


第1回EASE国際フォーラムに多数参加くださいまして誠にありがとうございました。
当日は、フォーラム中にお配りした各講師陣への質問票を利用させて頂き、Q&Aセッションとしましたが、 限られた時間の中ですべてにお答えすることができませんでした。
この場を借りて、特にご質問の多かったものについて回答させていただきます(一部準備中)。

Q 「出せないものは要求しない」とあるが、分析可能か?分析ツールが提供されて、企業で分析すれば良いか?企業の生データのセキュリティについて、どの様に保護を考えているか?
A 分析ツールを含めてすべてのツールは社内で走ります。データは一切、社外に出す必要はありません。

Q 現実的アプローチとして観測データをプロダクトベースのものとの仕切りがされている点が気になる。生産性改善という面からは、コスト又は工数データの測定が必須と思われるが、この点において、どの様に考えるべきか?
A プロセスやコストは、ある程度、プロダクトから推察できる部分があります。例えば、毎日1回、各作業者がレポジトリにチェックインすると仮定します。そうすることによって、作業者がその日、何の作業をしていたか、判定する事ができます。さらに、何人の作業者が、どのプロジェクトにその日従事していたかを調べる事ができます。そういうふうに推定する事により、ある程度、プロセスデータやコストデータをえる事ができます。また、別の方法、例えば人手による申告で得たプロセスデータやコストデータも、このレポジトリに取り込めるように今後する予定です。

Q 企業の立場からは即効性のある分析、フィードバックを期待したいが、この為にはある程度のレベルの生産性改善取り組みをされていることが、適用する企業側の条件として求められる。適用対象に望まれる条件とはどの様なものがあるか?
A 特に条件があるわけではないですが、生産性や品質に関心があり、そのために新たなチャレンジをしようとする組織であれば、可能と思います。開発環境の違いや開発者のマインドの違いなどは、大きな問題ではないと考えています。 一人のプロジェクトから大規模なものまでカバーしています。例え一人のプロジェクトであっても、日々の作業をCVSに蓄積し、問題をGNATSで記録する事によって、有益なデータを残せる事になります。そのためのオーバーヘッドは、開発者にとっては、ごくわずかです。

Q EPMのユーザーになるための資格は?
A 特にありません。2004年3月末をめどに、配布版の開発を進めております。ライセンスの携帯は、現在検討中ですが、多くの方に使ってもらおうと思っています。ただ、ある程度、CVS, SQL, Javaなどの基礎的な知識があると、いろいろな対処ができると思うので、便利です。また、現在のデモ版はZeeSourceという会社のCorporate SourceというGUIに依存して作られていますので、それを導入すると現在のデモ版も動くようになります。

Q エンピリカル環境を構築のためのコストは?
A 基本的にフリーソフトで構築できます。ただし、使い方など学ために、例えば1週間程度、ラボに来て頂いて習得されるのがいいと思います。上記のCorporate Sourceを利用する場合は購入する必要があります。

Q 更新時期とチェックアウト数を測って関連を調べられるようにする科学的根拠/仮説は何であって、どうやって思いついたのでしょうか?
A 近年、オープンソース開発に用いられるプロジェクト管理法が、企業内でも順次取りいられつつあり、CVSやClearCaseなどのツールが利用されるようになってきています。それを有益な情報源とみなすのは、比較的自明なことと思っています。また、ICSMやIWPSEなどの国際会議では、すでに数多くの研究でCVSのログ情報からプロジェクトの特性を抽出する研究や事例が報告されています。

Q エンピリカルなソフトウェア開発(工学)と言うのは、非常に自然な発想で分かりやすいと思うが、何故今までエンピリカルでなかったのか?
A これまで、既に多くのエンピリカルなアプローチが実践されてきています。例えば、海外講師の皆さんは多くの論文を発表されています。また、日本でも多くの論文が発表されています。今回はじめて産官学の共同プロジェクトとして、「エンピリカルソフトウェア工学」という題目をあげ、これまで以上に真剣に取り組もうとしております。

Q エンピリカルなソフトウェア工学と言った場合、その規模によらず人間についての関心、知見が必要かと思うが、社会学、人類学と言った分野の知見を活用しているのか?
A 人間についての評価というのは確かに重要です。Boehm先生のCOCOMOモデルにおいても、開発チームや開発者の能力が生産性・品質に影響を与えるということが指摘されています。開発者の能力を定量的に評価する研究も実施されています。また、ソフトウェア開発の改善においては、認知心理学や社会学も重要であるということも述べられています*。
*V.R.Basili and J.D.Musa: “The future engineering of software: A management perspective,” IEEE Computer, Vol.24, No.9, pp.90-96(1991).

Q 明らかに無効、もしくは有害と実証された手法等はあるのか?
A 論文、国際会議、専門書等で提案されている手法であれば、その手法が得意としている分野では、何らかの効果はあると思います。逆に言うと、あらゆるケースで有効な手法というのもないと思います。

Q エンピリカルソフトウェアの取り組みに参加するようなプロジェクトは、比較的に目標の課題がはっきりしている傾向にあると思われる。その結果、効果も求めやすく、改善もしやすい事もあるかと思う。このことによるデータの歪みをどのように考えているのか?現世界で泥沼化してしまうプロジェクトの多くは、何を作るのかすらはっきりしないまま始まるもので、それでも顧客の要請で始めなければならない。このようなケースはソフトウェア工学対象としては問題外なのか?
A まず、何故そのようなプロジェクトが存在するのか、何故毎回同じことを繰り返すのかという原因を明確にする必要があります。例えば、要求がはっきりしないうちに作らねばならないというのであれば、スパイラル的なやり方、アジャイルなやり方を使うという方法もあります。しかし、一般に、ソフトウェアに限らず、要求がはっきりしないまま作り出すと、プロジェクトは泥沼化すると思われます。

Q ソフトウェアプロジェクトの正当な評価に利用できるような数値化された指標はないのか?組み込みのソフトはKSOL数が多いことは必ずしもほめられた事ではない。また、順調に進んで何も問題を起こさなかったプロジェクトの評価は、難しい課題をクリアしても必ず高くならないという現状がある。むしろ、ある程度は問題を起こした方が上司にアピールできて評価が高かったりする。
A 何に対して正当であるかというのが問題です。組織内部であれば、そういう指標は、組織毎に持つべきものです。同業他社に対してというのは、現状では公開されているものはほとんど無いと思います。指標を実現するためには、データ収集と分析を継続的に行わなければなりません。コンサルティング会社によっては、ベースラインになるようなデータを持っていることが報告されています*。EASEでもそのような指標となるデータを提供できることが目標の一つであると認識しています。
*Software Assessments, Benchmarks, and Best Practices (Addison-Wesley Information Technology Series) Capers Jones (著)

Q 日本の産業界では、コンピュ-ターサイエンスの基盤が必要とされていない。数週間の言葉の意味論のトレーニングの後、仕事を始めている。そのような技術者たちが本当にエンピリカルな仕事をすると思われるのか?私はいくつかの資格テストがデータ-を集めるにあたって必要だと思う。
A 実際には、コンピュータサイエンスの基盤が必要とされていないというよりも、コンピュータサイエンスの基盤を持っていない人を雇う/雇わざるを得ないということはないのでしょうか。確かに、コンピュータサイエンスの基盤を持たない技術者に対して、そういう適格者を認定するための資格はあった方がよいと思います。しかり、さしあたりは有賀様もおっしゃられていたように、仕事としてやるという気構えも必要なのではないかと思います。

Q 私はUML.の社内導入をおこなっていますが、正直なかなか上手くいかない。エンピリカルアプローチに欠けていたせいだった。明日からどんなアプローチを取るべきか?具体的にどんなデータ収集、分析が入るのがいいのかお伺いしたい。
A 何がうまくいかないのかが述べられていませんので、エンピリカルアプローチに欠けていたとは一概に言えないかも知れません。まずは、原因を明確にする必要があります。例えば、何らかの技術を社内へ導入することを考えた場合、勤務時間内に業務としてやるのと勤務時間外の自習としてやるのとでは、対象者のやる気も変わってくると思います。実際に、技術導入を行う場合、勤務時間外での自習の場合は完了率が悪いという報告もあります。

Q 知識をどのように分解され、異なるコンテキストで再利用できるように表現されるのか、単純なデータとの違いを教えて欲しい。
A ある方法論についての知識とは、その方法論がどのようなコンテキストで有効であったか、あるいは、効果がなかったかということの事例データの蓄積と分析から導かれるものだと思います。従って、単にデータを集めるだけではなく、その際のコンテキストも一緒に集める必要があります。

Q データの分析から得られた教訓の具体例をご教示頂きたい。
A 数多くの論文が出版されています。各講師のホームページをご参照ください。
[HP: Prof. Victor R. Basili] [HP: Prof./Dr. Dieter H. Rombach] [HP: Prof. Barry W. Boehm] [HP: Prof. Ross Jeffery] [HP: 井上教授]

Q 必要なメダデータ、コンテキストをどのように定義すべきか?
A 有効な手法として、Bsili教授のGQMパラダイムがあります。GQMパラダイムについては、Bsili教授のホームページに多くの文献が提示されていますので、ご参考にしてください。[HP: Prof.Victor R. Basili]

Q 品質、生産性に対するアプローチは良くわかったが、ユーザーニーズの多様化によるソフトウェア規模についてエンピリカルの立場から見て良いアイディアはあるか?
A ソフトウェア規模を何に使うか書かれていないので何とも言えませんが、例えば、ファンクションポイントは、LOCでは測りきれないソフトウェアの規模を計測する手法であると考えています。様々な計測手法が提案され、得意なコンテキスト毎に使い分けられていると思います。しかし、測るだけでは駄目で、計測のコンテキストを明確にして、継続的にデータ計測と分析を続けないと、実際の目的には使えないと思います。

Q データと状況記述について実証的であること、データに基づくことは大変重要だと思う。ただ私共自身これまでデータは集めたが結局使えなかったという苦い経験をした。今回は何か新しいアプローチを考えているのか? ソフトウェア開発の場合、データというものをより広くとらえて「状況記述」というものを入れてそれをやるのが有効ではないかと考える。例えば、ファーブルの昆虫記のようなものだ。開発過程を記述、記録するのだ。単なる数値より本質的なデータになるのではないか。
A 何故集めたデータを使えなかったかということが重要だと思います。データの収集はあくまで手段ですので、何をするかという目的にあったデータを集めないと失敗することは明らかです。例えば、Basili教授らが提唱しているGQMパラダイムパラダイムというフレームワークがあります、これは、計測の目的を明確にした上で、どういうデータを収集すればよいかを決定することを支援するフレームワークです。
また、ご指摘の開発過程をすべて記述記録するという方法ですが、資源が十分あれば最もよい方法だと思います。しかし、それを再現するには、実際の開発と同じだけの時間が必要となりますので、実際には、データ収集の目的を明確にして、収集データを選別する必要があると思います。

Q 見積りということについて現在おこなわれているファンクションポイント法などの見積り法についての今後の可能性、或いは限界についてお伺いしたい。
A 実際に世界中で多くのソフトウェア開発組織が導入を始めており、ISO標準にもなりつつありますので、手法としては、かなり有効だと思います。ファンクションポイント計測方法には複数ありますので、当然ですが、コンテキストに合わせて導入する必要があると思います。見積もりに使うためには、十分の基礎データが必要となるので、うまくコンテキストに合わせてデータを収集することが重要です。

Q エンピリカルアプローチはまだデータを収集している段階のような印象を受けた。この活動を進めていくと、何かプロジェクトに応じてプロセスを決める基準のようなものが体系化されるのか?メタプロセスみたいなものか?世の中に数多くのツールがあり、プロジェクトによってそのツールを使うのが適切か判断するのが難しい。プロセスが科学的であっても、そのプロセスの決め方が勘と経験に頼るのは不安に感じる。
A 継続してデータを計測、分析することでプロジェクトに応じてプロセスを決める基準は体系化されると思います。例えば、Basili教授らの成果は、NASAのソフトウェア開発プロジェクトにおいて、様々な基準の導入に利用されています。

Q 議論したい内容:効果的な産学連携を実現するための最も重要なKey Factorは何か?
(1) 産→学 学の立場から、一般則を構築する為に必要なデータを上手く入手するためのKey Factorは何か?
(2) 学→産 これまでの経験データ分析結果をどのように産業界に見せることが効果的か?産業界にとってメリットのある形(品質、生産性、利益率)で、理論、一般則をフィードバックする上で最も重要なことは何か?
A (1) データ収集・分析の重要性をベンダーに分からせる必要がります。例えば、政府発注の場合には、データ収集のための予算を上乗せするという方法もあるのでは無いでしょうか。 Basili先生らは、予算の約一割をデータ収集予算として追加されていました。
(2) きれいな理論や一般則をフィードバックするというよりは、まずは具体的な事例を多く集め、どのようなコンテキストでどのようなことが明らかになったかということを地道に分析していく必要があると思います。

Q 実践しながら、且つ繰り返し適用していくエンピリカルアプローチはCMMやSPAのプロセス管理の仕組みと非常に一致すると思うが、どのような連携、関係させているのか?
A CMMなどと比較した場合、仕組みは非常によく似ている。適用する際には、CMMと同様に、プロセス改善を目的としたグループを作成し、CMMと同じような方法論を利用することで、導入をスムーズに行うことができると考えている。

Q 現在私は、リバース技術を勉強しながら新しい事業を立ち上げているが、ソフトウェア工学に資産再利用型システム開発のアプローチにこのエンピリカルデータを有効に活用する考え方、展開について、ご意見を頂きたい。(レガシー資産が日本には非常に多い現状から)
A いろいろな会社が参加しているレガシー資産の場合でも、同様な手法が適用可能だと思っている。その際には、データを分析する際に、共通の要因、違う要因を見つけることが重要である。比較などを行う際には、知見として得られた変化要因がなるべく小さくなるように考慮すべきである。また、誤解を取り除くためフィードバックを頻繁に互いにとることが重要であると感じている。

Q Experience Factoryで企業の商品開発を本当にやってみたことはあるか?(現実の制約、プレッシャーの下で)例外的なプロジェクトと違うデータや教訓がえられるのでは?
A 実際の商品開発においても、GQMを適用した例がある。その際、開発者に「生データを収集する」ことを伝えることで、質が向上するということを感じた。また、現実の開発現場においては、誤解を取り除くため得られたデータの解釈などのフィードバックを頻繁に互いにとることがきわめて重要であることもわかった。

Q 多くの日本企業では改善のため組織有していると思う。産学による取り組みも重要だと思うが、全てのプロジェクトの対象とはできない。自社によるエンピリカル的な改善を実施したいという要望もある。社内改善活動におけるエンピリカルアプローチについてご意見があればお伺いしたい。
A ・データを分析する際には、いろいろな要因を考慮して加味することが重要:データの違い(ばらつき)を生み出す要因を見つけること、パターンを見つけることが重要となる。
・モチベーションの維持と、強制が重要:データを取ることがいいことだと周知させないと続かない。また、仕事の一部であることを徹底させることも重要である。 解釈は全員がかかわれるようにすることが重要です。
・データの精錬は、進化的なサイクル(データとり⇔仮説の形成)を実現するため:データの精錬は正確性向上のためもあるが、初期の段階ではパターンを見つけることが重要です。

Q アメリカではリサーチグループへの各企業からのデータ出し渋りに対する対策は講じられているか?企業が自分たちの売りを他企業に増やして伸ばしたい場合の対策は考えられているか?
A データを提供する側に対して、データ提供の目的や、どういうことがわかりどういう改善が可能となりうるかをはっきりさせることが、一番の対策になると考えている。後者に関しては、自己組織の進化的な改善が最終的な目標となるため、あまりそういうことはないと考えている。自分たちの売りが他の人たちにも有効であると考えられれば、自然と広まるであろうし、その逆も同様であると考えている。

Q ソフトウェア開発プロジェクトは1つ1つ異なる特性を持っているが定量的な検証はどれほどの精度が期待できるのか?
A 検証の対象が具体的に書かれていませんのでお答えにしくいですが、EASEプロジェクトの目標の一つである、何千・何万というプロジェクトからデータを集めることができれば、過去に類似するプロジェクトと比較して予実管理のみならずコミュニケーション不足の問題等の指摘も可能になると考えられます。また、データを分析する際には、様々な要因を考慮して分析を行う必要があります。そして、プロジェクト間で共通の要因を見出すのと同様に、異なる要因を見出すことも重要です。共通要因・変化要因を特定し、徐々にデータを精錬するサイクルを生み出すことで、検証の精度を高めていくことが重要なのです。

Q (1)EASEを適用するプロジェクトの規模はどのようなものか?SWスタッフ数、開発人数、社員数
(2)FCSの例が多くありましたが、国防関係の場合の守秘などは確保しているのか?
A (1)EASEのアプローチで適用できるプロジェクトの規模は、特に制限はありません。1人でOSS開発を行うような場合であっても、他のOSSプロジェクトのデータを参考に開発プロセスの改善に役立たせることができます。また、大規模な開発の場合であっても、蓄積されていく膨大なデータを活用してプロジェクト管理を行うことができます。
(2)当然、守秘に関する契約を結んだ上で、活動をおこなっています。

Q IT産業では半導体産業がムーアの法則にのっとって高度の生産性を挙げている。実証的アプローチはソフトウェア産業のムーアの法則になりえるのかなりえるとしたらどのようなものとなるのか?
A 半導体産業と違って、ソフトウェア産業では結局最終的に人の作業が絡んでくるので、「ムーアの法則」とまではいかない。しかし、人の作業効率が生産性に絡んでいるような自動車産業において、データ提供とフィードバックをもとに同種の試みが過去になされていたが、大きな成果を挙げることができており、それと同種の効果が期待できると考えられる。

Q どんな優れた手法であっても企業側で繰り返し使うアプローチを継続しなければ失敗するとあったが、最近の技術や方法論の進化が速い環境下にこれらを可能とするために効果的施策はあるか?
A 新しい手法を導入した際、手法とは別の要因によりプロジェクトが失敗する場合もあります。よって、技術や方法論の進化が速い環境下では、プロジェクトの最終結果だけでなく、開発途中の詳細なデータも収集し、失敗の原因を分析し、次のプロジェクトで改善することが効果的と考えられます。

Q EASEがソフトウェア開発において有効である事は理解できるが、開発後のフェーズ(維持、運用、改善等)、又再構築のフェーズにおいても有効性があるか否か。あるとすれば、どのような内容か教えて頂きたい。
A 開発後のフェーズにおいても有効であると考えています。例えば、下記の文献では保守工程で計測された様々なデータを分析し、Code Decay(コードの腐食)の予測にはプロダクトデータよりもプロセスデータが有効であったという結果を示しています*。
*Stephen G. Eick, Todd L. Graves, Alan F. Karr, J.S. Marron, and Audris Mockus, “Does code decay? Assessing the evidence from change management data,” IEEE Transactions on Software Engineering, vol. 27, no. 1, Jan. 2001.

Q メタデータ、コンテキストデータを集めることは重要だと思うが、具体的にそのようなデータを集めるのか、具体例を示して欲しい。
A 例えば、application domain of target systems, intended user group, developer’s experience, 用いられているsoftware development technology (including development process, e.g. waterfall-style or iterative)などに関するデータが挙げられる。

Q 実証データの具体的な内容は、どのようなデータを中心に収集するべきか、企業はあくまでも事業拡大、利益追求である。その中で、収集すべきデータの質により大きく開発の展開が姿ってくる。文化の違いはあるが、企業のノウハウ的なデータは流さないと思いますがご意見を伺いたい。
A 収集すべきデータの決定は、目的志向(Goal Oriented)で行うことが重要である。データを利用するシナリオ(usage scenarios)をまず考え、そのシナリオに必要なデータを収集すべきである。ノウハウ的なデータも企業内で共有することが重要である。


ページトップへ