派生開発セミナー「XDDP関西勉強会」に参加してきた

先週の金曜日(2012/8/3)はXDDPの勉強会に参加してきた。得るものが多かったので、その内容を紹介したい。

• http://kokucheese.com/event/index/44223/

講師は派生開発(XDDP)でお馴染みの清水吉男氏。会場は50人近い参加者で満員の状態だった。以下、講演のメモより抜粋。

• 「機能追加」と「移植」でトラブルが多いのは、追加機能を受け入れるための「変更」がどこにも記述されていない為。また、すり合わせで作り上げたものを、他に流用するのは容易ではない。
• ソフトウェアは「現状」でバランスが取れているのだから、その一部を変更すれば他の箇所に影響が出るのは当然のこと。
• 保守性など「作り方に対する品質要求」が忘れ去られている。外注先にも変更作業に対して「保守性」を要求しない結果、「財産の毀損」が起きている。
• 「部分理解」の制約の中で変更作業を強いられる以上、担当者の「思い込み」「勘違い」の混入を防ぐことは出来ない。レビューで指摘できるのは一部に過ぎない。
• 変化する要求に対してプロセスを固定させることは危険。むしろ、プロセスを自在に設計するスキルが求められる。
• 変更要求は必ず"before", "after"で表現する。その差異から、変更の様子（量、難しさ、拡散状況）をイメージしやすくなる。
• （XDDP導入の障壁への反論として）決まったことを頑なに守って実施するのがCMMIではないはず。新しい方法を導入して減るところ、増えるところを見極めることが必要だろう。

清水氏の講演を聴く機会は他にも何度が有って、その話ごとにいろいろと新しい発見がある。今回の話はXDDPの具体的な方法論というよりは、むしろそのような開発手法を導入して実践していくための開発プロセスに重点が置かれていたように感じた。一つのプロセスにこだわるのは危険、プロセス自体を変化させて環境や要求の変化に即応していくことが大切なのだという主張には大いに共感を覚えた。開発対象や内容が変化してきているのに、そのプロセスは旧来のままという組織が意外に多いのではないだろうか。

自分自身はXDDPのやり方に特にこだわっている点は無いのだけど*1、例えばRedmineのチケットのコメントに記載する時には「変更前」「変更後」を必ず併記するようにしているし、変更箇所のトレーサビリティ確保には気をつけているし、仕様書には変更理由の明記や箇条書きによる形式的な記載を行うようにしている。実現方法や形態はやや異なるとはいえ、清水氏の方法論に強く影響されていることは紛れも無い事実だ。XDDPを始めとする清水氏の開発手法が現場で受け入れられるのは、コンサルタントしての豊富な現場経験が有り、現場に即した内容だからなのだろう。大学の先生が主張する机上の空論とは全く異質な方法論だと思う。

なお、今回の講演の中で最も印象深かったのは「XDDPで現場の混乱を抑えて、次の新規開発に繋げることが大切」という主張だ。現場レベルの地道な改善活動は、いかにも日本人が好みそうな方法論なのでこれはこれで確かに効果が有るものの、実際問題としていくら品質だけを上げても市場競争に勝つことが出来ない。新規開発を行わなければ勝つことが出来ない、その為の準備として今の改善が必要になるのだ。日本のITが国際競争力を失って久しいが、そのような状況を憂う清水氏のメッセージを強く感じることが出来た勉強会だった。

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

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

---

• JaSST'11Tokyoに参加してきた - Basic
• 派生開発カンファレンス2010に参加 - Basic
• ソフトウェア品質シンポジウム2008に参加 - Basic

*1:単にExcelフォーマットの仕様書が好きではないという理由かも知れない。