派生開発カンファレンス2019参加レポート（３）
「XDDP導入してから3年たちました」
～現在どうなったでしょうか～
～目次～
XDDPの導入
問題
障害の再発防止策を行うたびに工数が肥大化
施策を講じても障害件数・手戻り工数は横ばい
多くの仕様書の関連整理に時間がかかっている
（仕様書が80冊の分冊から構成されている）
→ 整備工数がかかる
変更仕様書に改定欄はあるが、変更内容が混じっている状態
→ 変更箇所が散在しているため、変更モレの確認が困難
→ 結果のみの記載となっているため、変更理由が不明
部分理解のまま変更仕様書を作成
→ 複数の担当者が何度も同じプログラムを変更
文書化はコーディング後に実施
→ タイミングが不適切
→ 80分冊された仕様書の改定作業が順次入ってくる
XDDPの導入
→ 効果あり
- 障害件数：減少
- FL化率：向上
- コード生産性：向上
XDDPの適用結果を数値で見ることかでき、改善点とその有効性を数値ベースで知ることができ、すごく貴重なデータだと感じた。
こんな導入結果を紹介していただける資料があると、XDDP導入への不安を抑えることができる。
もっと事例が増えてくると、導入時の問題点やメリットを数値データで裏付けたノウハウとして蓄積でき、XDDPの利用を考えている人たちを後押しすることにつながると感じた
課題
XDDPの他案件への展開
試行6件から他案件へ拡大を目指す
→ 開発メンバー/管理者から反対の意見が発生
→ 説明会を開催
社内の人間が布教しても胡散臭く見られるので、
→ エクスモーションさまに説明会を依頼
第三者視点でプロセスに対する意見をもらった
障害一覧等を見てもらいXDDPによって改善可能と言い切ってもらった
成果物の取捨選択
→ 現場の意見も聞きながら効果のない成果物を廃止/統合
効果を定量的に示す
→ 誤り抽出率（FL化率）の推移を評価
→ グラフ化して説明することで、効果に対する反応を得られた。結果
3年間で98%の案件にまで適用率を拡大できた。
さらに
- 形骸化防止のため、フォローアップ研修を実施
- 品質関連のあらゆる資料に「XDDP」というキーワードを記載
- 社内品質改善発表会で報告
XDDPを組織に浸透させる上で、実績に基づくノウハウがたくさん詰まっていた。
まわりにどうアピールすれば賛同してもらえるのか、どうすれば現場のエンジニアは納得して賛同してくれるのか、そのための技術が詰まっていたと思う。
さらには、将来に向けて形骸化させないための施策も展開し、組織風土として根付かせるための工夫などとても貴重な意見を聞くことができた。
仕様書の改善
差分開発となるため、成果物が全体を表しておらず、
→ 作成しっぱなしとなっている
→ 次回の開発に活用されていない→ 効率が悪い
→ 派生開発ドキュメントが公式文書に活かされていない
詳細設計書の構成を見直し
→ 文書の構成をあらかじめ決めておき
改造ごとに追加する拡張部分を設けておく→ 変更設計書をそのまま活用できるようフォーマットを変更
元となる公式文書がない場合、最初は歯抜けの詳細設計書となるが、派生開発の回数を重ねるごとに歯抜けが減っていく
さらに
SPLを見越したソフトウェア仕様書を目指す
→ リバース分析により要求仕様を分析し、USDM化
→ USDMかすることで、他の機能と横並びで見えるようになった
→ 共通部が見れるようになった→ コア資産として順次蓄積
XDDPの成果物の扱いについて、しくみとして工夫できる部分があるということを知ることができたと思う。
公式文書と中間生成物の関係、さらにはコア資産として扱うことまで考慮すると、ソフトウェアプロダクトラインやアセットとしての扱いなど、いろいろと想像を掻き立てられた。
設計の改善
リバース分析時にアーキテクチャ崩れが浮き彫りになった
→ 最適なアーキテクチャ設計ができていないのでは？インプットの問題
→ 機能仕様を理解しやすいシステム仕様書の整備
プロセスの問題
→ 最適なアーキテクチャ設計ができていないまま詳細設計をしてしまっている
350KL規模のうち60KLのアーキテクチャ設計を見直し
（役割/責務で論理構造を見直し）
→ 従来エンジニア個々が裁量で行っていたアーキテクチャ設計を共通認識とすることができた→ 現在根本治療を継続中
最近似たようなことを仕事でやっているので、すごく親近感が湧いた。
派生開発で将来性を考える上で、アーキテクチャの根本治療というのは、避けたいけど避けれない問題なのかもしれない。
裏返すと、根本治療を達成した先の未来には希望が待っている？
なおさら根本治療の先を見てみたくなった。
Q&A
Q:定量的評価に利用したメトリクスと評価周期はどれくらいか？
A:メトリクスはいろいろと設定
今回は説明用にまとめています。
評価周期は月一くらい（報告会の都度）
品質保証活動計画書などに記載（課内/部内に展開）
Q:改善活動のモチベーション維持やステークホルダーへの働きかけの知見は？
A:社外に積極的にアピールすること
→ 開発者たちが評価を受けることができる
→ モチベーションが向上する
形骸化の恐れもあるため、フォローアップ等の施策も実施
Q:工数が含む作業スコープは？
A:設計から試験まで
手法の導入コストも含む
Q:抵抗層の割合は
A:2から3割りくらい
導入時にはあえて「改善」ということは言わなかった。
自発的に改善を始めた
