派生開発カンファレンス2018 事例発表編

 派生開発カンファレンスに参加した。

概要はこちら。

「派生開発カンファレンス2018」開催報告

昨年は大阪だったが、今年は横浜に戻ってきてくれたので、参加。

今年はいろいろと感慨深い年としての開催だったかもしれない。

それは、プログラムにも表れている。

「派生開発カンファレンス2018」プログラム

「清水代表を偲ぶ」・・・ここの対談は、また別のブログにまとめようと思う。

事例発表部分の簡単な私的見解満載の紹介ですが、参加されていない方などの参考に少しでもなりましたら幸いです。

上記プログラム内に、発表された資料も掲載してあります！！

 派生開発カンファレンス

私が参加したプログラム

1. 　XDDP導入に躊躇する開発チームへのアシストとは
   　　　アンリツエンジニアリング(株)　中村 勝志
2. USDMでマネジメントシステムを派生開発する
   国際標準規格(ISO/IEC/IEEE29119)を組織標準に的確に取り込む改訂作業を例に
   IT検証産業協会 林 祥一
3. 私が始めた“働き方改革”～USDM、PFDで仕事は変わる！～
   (株)デンソー　石井 育美、古畑 慶次
4. スクラムXの提案　
   ～MDD/MBD開発へアジャイルXDDP適用提案、および、ライトなUSDMの提案～
   派生開発推進協議会 T6研究会　 佐々木 俊正

私見満載の所感

　清水吉男さんが考案なさったXDDP。この手法の 支援ツールといわれている「PFD」「トレーサビリティマトリクス（TM）」「USDM」。

この支援ツールを使いながら、変更設計書などの成果物を作成することで混乱やリスクをなるべくつぶしていく。しかしながら、短納期の要求などもあって、XDDP「3点セット」をフルセットで作成する時間、スキル確保をする余裕などがない現場が多い。
　そんな背景からか、各支援ツールや成果物を「部分最適で」利用する事例発表が増えてきた。今年の事例は、XDDPでのお作法を別の目的で使ってみた、というものが多かった。
　
　市場の流れが速いビジネスドメインが多く、成果物の作成を効率的にしたり、設計のやり方・プロセスのあり方に注目をしている部門･プロジェクトが多くなってきている。そういった「効率化」「ある手法のほかドメイン・目的への転用」などに注目すべき時期に来ていると思う。
　
　昨年11月に清水さんが逝去され、残された思想・ツールなどは今後さまざまな場所で改良され、その事例も多く発表されていくものと思われる。

特にUSDM、PFDは流用領域が大きいので、今後の事例には、今まで以上にキャッチアップしていく必要がある。

個別感想

　１．XDDP導入に躊躇する開発チームへのアシストとは　

http://affordd.jp/conference2018/affordd_conference2018_p1.pdf

　　EPGの改善活動の心得的な内容だった。共感できる内容だった。

• XDDPの導入を躊躇するチームの導入「アシスト」にフォーカスした発表
• 「サポート」ではなく、「アシスト」
  伴走者として、一緒に中に入ってXDDP手法を導入する。共同責任を負う。
• 改善活動をするときに、部門から出る言葉「失敗したら誰の責任？」
  ⇒上長を巻き込み、アシストチームが合意にもって行き、改善を行う土壌を作る
• 改善内容（XDDP導入）のやる気を向上させる
  ⇒・行動をほめる、ひたすらほめる。
  　・困っているところを見つけ、積極的に解決への道筋を作っていく⇒信頼される
• 一番の成功ポイント：始める前に、キックオフを行い、なぜXDDPを導入したいのか、という問題を共有でき、少しでも疑問をいただくメンバーには納得いくまで話をした。何のためにやっているのか、を合意できたことである。

 

２．USDMでマネジメントシステムを派生開発する

　国際標準規格(ISO/IEC/IEEE29119)を組織標準に的確に取り込む改訂作業を例に

http://affordd.jp/conference2018/affordd_conference2018_p2.pdf

　

国際標準29119をUSDMに落とし込んだという事例発表。
特に、国際標準は、手段ばかりが書いてあり、理由が書いていない。
その理由を考えて埋めていくことが一番苦労した点だったとのこと。
この事例発表が自分にとっては一番のヒットだった。

自分の仕事への適用も密かに計画をすすめていこう・・・。

 

• マネジメントシステムの派生開発。ヌケモレのない品質保証ができるか？
• ２９１１９は、汎用的なフォーマットとしてモデルとして規定しているので、Beforeが作れない。想定できる具体的な仕様がはっきりしている”もの（対象）”がないから。ここが、XDDPの支援ツールを使うということで苦労した部分。
• USDMの「理由」を書くところは、自分たちで考える。目的と理由が取り違えられやすい。目的は復元する。
• 「２９１１９で規定されているから」は理由ではない。プロセスを守ってやることが目的と書いてあるが、違うと考えている。理由は、要求の出どころである。目的ではない。（「～のため、～する」の「～のため」にはきれいごとしか書かれない。）

３．私が始めた“働き方改革”～USDM、PFDで仕事は変わる！～

http://affordd.jp/conference2018/affordd_conference2018_p3.pdf

　　　
仕事のプロセスをPFDを使って見える化し、無駄の排除、コミュニケーションの効率化を図ったという事例発表。石井さんという方は、総務の2年目の方だとのこと。そういった、技術部門ではないところでもXDDPの支援ツールは使えるんですよ、ということを証明する事例発表だった。内容がとてもよいものだった。
　　　
　　　　　　
４．スクラムXの提案　
　～MDD/MBD開発へアジャイルXDDP適用提案、および、ライトなUSDMの提案～

http://affordd.jp/conference2018/affordd_conference2018_p5.pdf

この発表の中で興味深かったのは、アジャイルUSDM。

実際に、アジャイルじゃない現場でこれをつかうとどうなるのかやってみたい気がした。（天邪鬼）

アジャイルUSDMは、ツイッターでチョットつぶやいたら、反応がすごかった！

 　　・スクラムX　スカウターが影響範囲を見極める。

　　・アジャイルUSDM　ユーザストーリーをふるまい観点形式でうめていく。

　　・モデルで影響範囲分析をする

　　・モデルベース開発　変更設計書はモデルレベルまで記載をした。

 いじょ！