派生開発カンファレンス2010に参加してきた

休日出勤の代休を使って、派生開発カンファレンス2010に参加した。258名の申込み者とのことで、ぎりぎり参加できたようだ。なお、「インターネットなどを用いた、セッション内容の無断転載を禁止する」旨のアナウンスがあった(どこまで禁止するかは曖昧で、わからなかった)ため、内容についてのメモはしない。


なお「派生開発」とは、次のようにある。

ベースのソースコードに対して、機能追加や仕様変更を施して新しいバージョンのソフトウェアを生み出す開発パターンのこと
《[改訂第2版]要求を仕様化する技術・表現する技術, 2010/05/01, 技術評論社, p.11》より


セッションの内容は、基調講演以外は、XDDP*1の事例紹介が中心だった。特に、厚田 鳴海氏の公演『XDDPによる派生開発ソフトウェア品質向上の取り組み』は、XDDPの適用にあたって、苦労した点、各課題の解決方法、適用してよかった点などがわかりやすくまとめられており*2、大変よかった。XDDPをまわすには、USDM*3PFD*4が必要であり、これらについても(セッション全体を通じて)随所で触れられていた。これらは、次の2つの書籍にて、詳しく説明されている。

「派生開発」を成功させるプロセス改善の技術と極意

「派生開発」を成功させるプロセス改善の技術と極意

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?

[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?


今のプロジェクトに参画する前に、「要求を仕様化する技術・表現する技術」の第1版は購入していた。だが、設計フェーズの計画のことで頭がいっぱいで*5、読んでいなかった。今回、カンファレンスに参加するにあたり、第2版を購入し、読んだ。


あー、早く読んでおけばよかった。。


「要求を仕様化する技術・表現する技術」は、USDMについての解説なのだが、トリッキーな方法は一切説明されていない。(言われれば納得できるという意味で)あたりまえの内容ばかりだ。随所にちりばめられている具体例も、陥りがちなものばかり*6で、バッドプラクティス集としてだけでも価値がありそうだ。
開発プロセス云々の前に、こういう基本的な方法論と、それを実践できるスキルが必要だ。


世の中にはたくさんの開発プロジェクトがあると思うが、要件定義フェーズは、きちんとトレーニングを受けた(あるいは勉強した)人がやっているのだろうか。少なくとも、要件定義フェーズで何をどこまで行うかについて、明確なイメージがない人は、そのまま進めてはいけないと思う。正直、反省している*7
今ならもう少し(いや、けっこう)まともにできる。

*1:eXtreme Derivative Development Processの略。派生開発に有効な開発プロセス

*2:非常に入念に準備されていたのではないかと思われる。

*3:Universal Specification Describing Mannerの略。要求を仕様化する方法、記述する方法。

*4:Process Flow Diagramの略。プロセスを設計し定義するための記法。

*5:いや、それほどでもなかったかも。

*6:思わず、苦笑してしまった。

*7:言い訳なのだが、それでも基本設計の終わりには、大きく外れた成果ではなくした。。時間がなかったことだし、もっとつっこんで参加すべきだった。