とって返して、開会挨拶が始まる前に、清水吉男氏から一言、コメントを取っておきたかった。さきほど清水氏とは会釈を交わし、講堂に通じる廊下の脇で来場者の様子を眺めていることは確認済み。ここでわざわざ触れるのも何だが、こういうカンファレンスを取材する際は、オープニングの直前がカンジンなのだ。主催団体の中心人物や基調講演の招待者が出番に備えて揃っているので、ピンポイントのコメントを取る絶好のチャンスといっていい。
清水氏は入口の同じ位置に立っていた。相変わらずのダンディぶりで、知らなければ評論家かニュースキャスターで通じるかもしれない。氏とまともに言葉を交わすのは、昨年6月、福井市で開かれたソフトウェアシンポジウム2012（SS2012）以来だろうか。
――盛況ですね。参加者はSSのほぼ3倍といったところでしょう？
さっき受付けで仕入れた情報で話のとっかかりを作る。
清水 何とか。実行委員会の皆さんが頑張ってくれました。参加者はご覧のように、SSと比べると若いエンジニアが多いし、参加費も安いし。それに横浜ですからね。
――それだけに実践的というわけですよね。
清水 XDDPという手法に限れば、ですね。
――第1回は2010年でしたよね？
清水 ずっとフリーのプログラマというかシステムエンジニアというか、どこにも所属しないでやってきたでしょう。ずいぶん前から、自分なりに考えた手法でいいはずだ、という自信はあったんだけど。世の中がなかなか評価してくれなくてね。
――いまはずいぶん普及しているじゃないですか。
清水 実はね、60歳になったとき、引退するつもりだったんですよ。そうしたら本が意外に好評でね。田中さん（一夫氏）とか古畑さんとかがカンファレンスをやろう、と。それで引退できなくなってしまった。
なるほど、そんな経緯があったのか。 そこに、SRAの林好一氏がやってきた。黒のシャツジャケットに細身の黒のジーンズ。この人もカッコいいオジサンで、外見からはとてもプログラマやシステムエンジニアとは思えない。
――受託開発業のエンジニアはどれくらい参加してるんですか？
清水 ユーザー系、メーカー系が多いでしょうね。
林 XDDPが使われているのは組込み系ソフトが多いですから。
――受託系ソフト会社がもっと参加しないとね。受託ソフト会社が目先の利益を追いかけるようになって、ソフト工学から目を背けているのはマズイでしょう。古い話かもしれないけれど、服部さん（故人：構造計画研究所所長、ソフトウェア産業振興協会会長）が生きていたら怒られますよ。
林 服部さんね。（服部氏の名前が出るとはちょっと想定外だったようだ）
――それはともかくとして、受託ソフト会社エンジニアは現場でタコ壷状態に陥っているんじゃないですか。こういう場所に来て、知識を広げる。会社はそういう機会を与えるべきですよ。
林 仰るとおり。
――ただし、エンジニアは逃げ場にしててはいけない。
林 いや、そうとも限らないんじゃないですか。最初は逃げ場だったとしても、こういう場にくることによって視野が広がるし、いろいろな考え方があることが分かる。
清水 いろんな人と知り合える。それだけでも意味がありますよね。
――あ、なるほどね。
清水氏が言うように、「派生開発カンファレンス」と銘打ち、主催は派生開発推進協議会となっているものの、実態は清水氏が編み出した開発方法論「XDDP」（eXtreme Derivative Development Process）のユーザー会といっていい。午前中にデンソーの古畑慶次氏がチュートリアルで行ったのは、まさにXDDPを実践するためのノウハウ講座だったし、午後のセッションは小グループに分かれての実践トレーニングだった。そのように書くと、このイベントが「XDDP」のプロモーションイベントだからイカンと言っているように聞こえるかもしれないが、さにあらずなのである。
※XDDPの詳細はhttp://www.xddp.jp/about_xddp1.shtml
講堂で行われた本セッションは、
「XDDP導入を断わることのできない提案」（八木将計氏：日立製作所）
「混乱からの目覚め〜USDMとの出会い〜」（岩松洋史氏：日本電気通信システム）
「ソフト開発ほど計画的にできる職業はない！〜硬派のホームページと出会って4年間 ほぼ残業なしをどうやって実現したか〜」（加藤貴裕氏：たのしいソフト開発研究所）
「ソースコード主体の派生開発からモデル主体の派生開発へ 〜設計の見える化による設計品質の維持と改善〜」（渡辺滋氏：日立情報制御ソリューションズ）
など、XDDPから“派生”したシステム設計・開発における工学的アプローチの研究成果にほかならない。
筆者がフルに聴講できたのは八木将計氏の「XDDP導入を断ることができない提案」のみだったが、「抵抗」を克服する手法として紹介された「マフィアオファー」はたいへんに面白いものだった。システム設計やソフトウェア開発に方法論やツールを導入するに際して、必ず抵抗が起こる。ソフトウェア技術者もしくはソフトウェア技術者で構成する組織というのは、意外に保守的なもの――とは、しばしば耳にすることである。その抵抗の構成要素を「問題」「方向性」「解決策」「副作用」「障害」「恐怖」の６階層に分解し、その一つ一つを説得したり抑えこんでいく。そうすると誰もが最後には「わかった」といわざるを得なくなる、というのだ。「抵抗」の質を解析したうえで説得したり抑え込むという
※関連情報は http://www.juse.or.jp/software/167/attachs/6_a_report.pdf
派生開発について、清水氏の言葉を http://www.xddp.jp/about_xddp1.shtml から引用しておく。
最近のソフトウェア開発では新規開発の機会はほとんどなく、多くは現行のソースコードを変更したり、新しい機能だけをコーディングして追加したり、別の製品やシステムで稼働しているソースコードを一部切り出して移植・流用したりして使い続けています。その背景には、プログラム言語の寿命が長くなったことや、製品のリリース間隔が短くなっていること、ソフトウェアの規模が大きくなって新規に開発するリスクが高くなったことなどがあります。もともと「保守開発」という領域があるのですが、今日行われている開発の状況は「保守開発」の領域を超えるケースが増えています。たとえば、かつての「携帯電話」が「ケータイ」に変遷する状況や、多様な機能が追加されてきたデジカメの状況などは「保守」では説明しにくいのです。実際、組み込みシステムの世界では「保守開発」という言葉を耳にすることはなく「派生開発」という呼び方が広く使われています。もちろん、出荷後のバグだけを訂正してリリースすることもありますが、ほとんどが新規機能の追加を伴います。エンタープライズの世界でも新しいビジネス要求の実現や規格の変更などに伴って大きな機能追加が頻繁に行われています。
派生開発にはいくつかの特徴があります。たとえば１ヶ月とか３ヶ月というような「短納期」で完成が求められたりします。この納期が短いということが、必要なプロセスや成果物を省く圧力になっています。またそこにある機能仕様書や各段階の設計書などの公式文書が、必ずしも適切な状態になく、これまでの派生開発の中できちんと更新されていないことが多く、どうしてもソースコードに依存することになります。その結果、「部分理解」すなわち全体を理解できていない状態で変更作業が強いられることによる「思い込み」と「勘違い」の問題に見舞われます。思い込みや勘違いは、その時点では担当者は正しいという認識ですので、第３者によるレビューなどの手段を持ち込まないかぎり、事前に発見することは難しくなります。それにもかかわらず、いきなりソースコードを変更されてしまうと、第３者の目を取り入れる機会を失い、結局テスト工程で多くのバグとなって発見されることになります。中にはテストをすり抜けるものも出てくるでしょう。
派生開発の問題は、多くの現場で行われている開発プロセスが、このような派生開発の要求にマッチしないために起きているのです。その中で多くのバグに見舞われ、繰り返される手戻り作業によってソフトウェア技術者の疲弊を招いているのです。このような状況に対処するには派生開発の要求にマッチした開発プロセス（開発アプローチ）が必要です。「XDDP（eXtreme Derivative Development Process）」はこうした時代的背景の中で提案されたものです。
