Index: [Article Count Order] [Thread]

Date:  Mon, 2 Jul 2001 10:34:27 +0900
From:  "Kenichiro Oota" <oota_ken@....com>
Subject:  [XP-jp:02054] ソフトウェア工学研究会参加レポート
To:  <extremeprogramming-jp@....jp>
Message-Id:  <OE20f3yXvEbjkyqU7a0000015b9@....com>
X-Mail-Count: 02054

 太田です。運良く代休でしたので、平鍋さんの発表されたソフトウェア工学研究会
に参加してきました。Tシャツというラフな格好で変な質問ばかりしまくり失礼いた
しました。

 TEFのメーリングリストにも送りましたが、参加レポートを書いてみましたのでご
参考にして下さい。一応XPにも関係あると思います。なにやら変な報道記事のような
中身の無いものになってしまいました。


第132回 ソフトウェア工学研究会
特集:新しいソフトウェア工学の実践と課題

主催:情報処理学会ソフトウェア工学研究会 ACM日本支部
協賛:情報サービス産業協会

日時:2001年6月28日(木)13:00〜18:00
会場:TIME24ビル TIME24ビル 1F タイムプラザ

参加者:70人程、産が2/3、学が1/3という感じ
プログラム

13:00〜13:10 挨拶      玉井 哲雄 (東大)
13:10〜14:45 基調講演
  「ソフトウェア工学の実戦経験に基づく知識体系の確立」
   Victor R. Basili  (University of Maryland. USA)
15:00〜17:00 ソフトウェア工学の新しいスタイルと課題  司会:青山 幹雄(南山
大)
15:00〜15:30 e-ビジネスソフトウェア開発の展望   上原 三八 (富士通)
15:30〜16:00 通信系組み込みソフトウェアの開発経験から 藤森 隆 (NEC)
16:00〜16:30 XP(エクストリームプログラミング)の現状  平鍋 健児 (永和シス
テムマネジメント)
16:30〜17:00 オープンソース開発:Apache SOAP/Axisの開発経験から 中村 祐一
 (日本IBM)
17:00〜17:50 総合討論:ソフトウェア工学の挑戦
  討論者:青木 利晃 (北陸先端大)、松下 誠 (阪大)と講演者
17:50〜18:00 まとめ      青山 幹雄 (南山大)

各プログラムの内容とそれに対するコメント

基調講演「新しいソフトウェア工学の実践と課題」

内容

 ソフトウェア工学の権威として名高いBasili博士の講演である。内容は以下のとお
り。
ソフトウェア工学を実践に生かすためには他の分野の工学が行ってきたように、仮説
を立て、その仮説を現場で実施、検証し、その結果を元に仮説を洗練していくという
プロセスが必要である。現在のソフトウェア工学ではこのプロセスがうまく機能して
いない。銀の弾丸のようなツール、方法論が次々と打ち出され、企業はそれらが有効
な状況を理解しないまま用いて、失敗するということを繰り返している。重要なのは
それらの解決方法を適応する際に考慮した制約、前提条件、結果を記録、分析し、ど
の状況で有効なのか分類したり、その解決方法を組織に合わせて変更していくことで
ある。Basili博士はこの実験を実プロジェクトに適応し、ドキュメント・リーディン
グの分類を行ったところ、大きな成果を得ることが出来た。
解決方法は単に文書化し、共有するだけでは不十分である。状況は刻々と変化してお
り、もはやその解決方法は有効でないかもしれない。したがって、解決方法自身も状
況の変化に応じて進化する必要がある。そのためには継続的な継続とフィードバック
が欠かせない。この作業はすぐに直接の利益を生むわけでないため、営利を伴う企業
だけで行うのは困難である。そのためにそのような分析を得意とする学の協力が必要
となってくる。産はこの協力によってベストプラクティスの充実を図ることが出来、
学は打ち立てた仮説が現実に役立つこと確かめることが出来る。そして、このプロセ
スは我々全員の使命であるといえる。

コメント

 ソフトウェア工学という学問が現れて30年ほどになるが、ソフトウェア開発の現場
は他の産業に比べると今だ泥臭い。測るべきものが測られておらず、他の分野では考
えられてない根性論がまかり通っていたりする。また逆に、用いるべき適切な状況を
考慮しないで、標準がやたらに強調されることもある。このような中で必要なのは講
演にもあるとおり、実際に測定してみることである。週40時間労働が本当に夢なの
か、毎回、最後の2週間徹夜という結果になってしまうのはなぜか、なんとなくでは
なく、モデルを作り、検証してみるのである。その結果、もしかしたら漠然と感じて
いた経験則とは全く異なる結果が得られるかもしれない。しかし、それこそが改善の
機会である。プロジェクト全体で行うのが困難ならば、PSP(Personal Software
Process)のように個人レベルから始めてみるのも良いかもしれない。ほんの少しの計
測とフィードバックから最終的には大きな変化をもたらすというのは、スポーツの世
界では良くあることである。努力と根性で語られることが多かったスポーツですら現
在は計測とフィードバックが常識になっている。ソフトウェア開発でもそれを行わな
い手はない。忙しくてそのような事を行っている時間はないというときこそ、立ち止
まって自分の作業を冷静に見つめなおす必要があるといえる。

e-ビジネスソフトウェア開発の展望

内容

 XML、SOAPを初めとする新たなソフトウェア開発の展望についてである。XMLの登場
によって開発対象がWebサイトからWebサービスに変化したことに言及。サービス自体
をコンポーネントとして利用する新たなソフトウェア開発が今後の主流となる。それ
に対応した新たなソフトウェア開発技術が必要となるのではないか。

コメント

 XML、SOAP、UDDIについては世の中でよく言われていることで特に新規性はない。
サービス自体をコンポーネント化することは技術的には可能になっただろうが、本当
にそのサービスを部品として使うかは別問題である。企業がサービスをそのまま利用
するには、ビジネス・モデルそのものの変更を迫られることも多く、リスクが高い。
そのため、依然として企業にあわせたカスタム・ソフトウェアが主流という時代が当
分続くような気がする。

通信系組み込みソフトウェアの開発経験から

内容

 組み込み系ソフトウェア開発特有の問題とそれに対する解決策について。解決策と
は再利用を3段階に分ける、スパイラル型の適応、設計モデルとアルゴリズムの統合
などである。今回は定量的な評価は行っていないとのことである。

コメント

 再利用のレベルを3段階に分けるという考え方は興味深い。私は組み込みの分野は
詳しくないのでなんともいえないが、単に再利用が進まないと嘆くのでなく、このよ
うに戦略レベルと戦術レベルに分けて再利用を試みる、部分的にでも良いからオブ
ジェクト指向を適応してみるなどの地道な努力が最終的な再利用技術につながってい
くのだと思う。

XP(エクストリームプログラミング)の現状において

内容

 最近、日経系の雑誌にも取り上げられ話題となっているXPの日本における実情であ
る。XPの14のプラクティスをすべて満たすことは難しく、ユニットテスト、リファク
タリング、コーディング標準などが適応しやすいプラクティスであるということだっ
た。逆に最も難しいのがオン・サイト・カスタマーである。これは日本における商習
慣の問題であり、フルスペックのXPを日本で実践する際の課題である。また、ペア・
プログラミング、週40時間労働も課題である。これらの問題をどう克服するのか、あ
るいは日本の実情に合わせたXPを考えるべきなのか、皆で考えていきたいとのことで
ある。

コメント

 XPの各プラクティスの中には参考になるものも多いが、全部を同時に実践するのは
難しいというのが会場の声であった。私も同様であり、プラクティスの一部を採用
し、別の何かを付け加えた独自のXPがあっても良いと思う。ただし、それによって簡
潔さが失われるのならもはやXPとはいえないだろう。開発の一部を外注するという形
を取ることが多い日本の開発体制に合わせたXPというのも面白そうである。

オープンソース開発:Apache SOAP/Axisの開発経験から

内容

 日本IBMの東京基礎研究所で行われているオープンソース開発の状況を語ったもの
である。結局、オープンソース開発も従来のソフトウェア開発同様、ソフトウェアの
方向性を決める良いリーダーが必要であり、その意味では従来のソフトウェア開発と
は何ら変わることがないという。また、製品として興味を引く力が低いもの、具体的
な動くコードがないもの、アーキテクチャが固まっていないものはプロジェクトとし
て失敗する可能性が高いとのことである。最後に企業とオープンソースの関係につい
てであるが、これは微妙である。企業が単なる自社の利益のためにオープンソースを
利用しようとする失敗する可能性が高いとも述べていた。

コメント

 オープンソースのメリットについて聞きたかったのだが、少々当てが外れた。品質
保証という観点からは、最終製品のコードをだれでも見られるということから、開発
者自身のモラルが向上するという考えを持っているがここら辺の話は聞けなかった。

ソフトウェア工学の挑戦

内容

 XPとオープンソース開発を踏まえた新たなソフトウェア開発方法が議論の大半を占
めた。XPの個々のプラクティスは日本では昔から行われてきたものだ、XPの適応範囲
は小規模に限られるのではないか、10年位前の個人開発はXPに似ていた、企業では
オープンソース開発のように開発の途中で開発方法を決定していくなどというのは無
理だからこそ、具体的な開発方法論を求めていくのが学の使命ではないか、XPやオー
プンソース開発など開発者のモチベーションが高い開発方法はうまくいって当たり
前、XPやオープンソース開発が人気を集める今、だれでもそれなりのことが出来るよ
うにというソフトウェア工学の努力は意味があったのか、いやXPはソフトウェア工学
の成果を最大限に受けている、などの議論が交わされた。

コメント

 個人的にはここが一番面白かった。XPについてはソフトウェア工学の成果を最大限
に受けているというのは事実だと思う。XPはオブジェクト指向と再利用可能なコン
ポーネントを前提としている。CやアセンブラでXPは無理であろう。要求を目に見え
る形にするのが容易な抽象度の高い言語とライブラリがあって初めてXPは成り立って
いる。その意味で言えば、ソフトウェア工学は十分役立っている。
 これまでのそうとウェア工学は普通の技術者を使っていかに品質を上げるかを焦点
にしていたが、そもそも普通のレベルの技術者を何人集めたところで、数人の優秀な
技術者には勝てないのかもしれない。その数人の優秀な技術者の開発効率を最大限に
高めるのがXPであるとのことだが、こういうアプローチもソフトウェア工学として
あっても良いのではないか。また、スポーツの話題となるが、優秀な人材でも方法を
間違えれば、うまくいかないというのは野球やサッカーでも良く聞く。だからこそ、
集団が最大限に力を発揮できる戦略、戦術を考えていく。これは普通の集団の戦略と
はやはり異なっているはずである。その特徴を分析し、最適な解決策を提案していく
のもソフトウェア工学の役目であると思う。もしかしたら、その結果は普通の技術者
の集団にも役立つかもしれない。


We need testing, We like patterns, so We write
http://c2.com/cgi-bin/wiki?TestingPatterns
Kenichro Oota oota_ken@....com