YU2TA7KA's BLOG ~take one step at a time~

派生開発、組み込み開発周りのこと。

「XDDP」の入門 の感想

はじめに

昨日(2018/12/23)、AFFORDDの「XDDP」の入門 チームのオンラインMtgがありました。そこでXDDPの基本について講義いただきました。それに関する感想です。結論としては、でどうやって現場にいれるんよ!です。XDDPそのものについては、下記が参考書です。



変更と追加を分ける

派生開発では機能要求が「変更」「追加」のいずれであるかをまず判別する。そして、「変更」「追加」はそれぞれ異なるプロセスで対応する。XDDPでは特に「変更」についてのアプローチ方法を提示した手法である。下記資料のP13,14が参考になる。
http://creative-1st.com/doc/110_DevelopmentProcess/xddp_overview_vsn.0.1.pdf

派生開発では、「変更」要求のほうが多いため、こちらにフォーカスしているのだと考える。実際現場でも「変更」のほうが多い。特に組み込み開発では、ハードウェア仕様が変わることに対応するための「変更」要求が多い。そのため、ハードウェア仕様書とハードウェアチームから「変更」要求を抽出するところが最初の壁だと感じている。

小さなプロセスを回す

「変更」のプロセスは、おおまかに「変更箇所を探す」→「変更方法を考える」→「ソースコード変更」という流れである。この3つのプロセスごとに小さく回す必要がある。前のプロセスへ戻ってはいけない。

f:id:yuji-tanaak:20181224212821p:plain
変更プロセスの3ステップ


「小さく」と表現されるととっつきやすいように思えるが、各プロセスごとで行うというのは非常に難しく思える。私だけかもしれないが、要求時に設計のことなど、次のプロセスのことを考えてしまう気がする。しかし、XDDPではこれはご法度のよう。各プロセスで求められるアウトプットをしっかり出すように注意する必要がある。そのためにも、全体像を把握した中で、「変更」のプロセスのどこを実施しているかをメンバ間で共有しておく必要がある。
やっぱり実践は難しそう。


3点セットを作るプロセス

「変更」の3プロセスを通して、「変更要求仕様書」「トレーサビリティマトリクス」「変更設計書」の3つのアウトプットを作成することがXDDPでは求められる。「変更箇所を探す」で「変更要求仕様書」「トレーサビリティマトリクス」、「変更方法を考える」で「変更設計書」を作成する。

このプロセスをいきなり現場に持ち込むのは難しいと考えている。これは、ソースコードを変更するまでに多くの時間を要する手法であり、マネジメント観点では実装着手が遅れているように見えやすくなってしまう。そのため、XDDPによる遅延をマネージャーへなにがしか説得する必要がある。
そこで現場に持ち込む手法として、デバッグ対応プロセスに入れ込めないかと考える。不具合が発生し、その対応方法の検討に用いるのである。現場では不具合に対して、原因がわかればすぐにソースコードを変更し、効果確認し、問題なければ正式対応、としてしまうことがある*1。この場合、対応ドキュメントが無いし、変更内容が妥当かの検討もされないままとなってしまう。そこで、頑張って*2「変更」のプロセスを実践するのである。これが後々よかったという実感が得られれば、設計プロセスにおいても導入がしやすくなると考える。

おわりに

「XDDP」の入門 オンラインMtgの感想をざっと書きました。ここからまた共有、議論を進めいろいろ発展させられればと思います。特に私は、どのように現場に導入するかという観点に興味があります。「障壁の克服方法」という研究チームもAFFORDDにはあるので、そちらに参加するのが良いのかもしれません。

そして、昨日のMtgで気になったこととして、このXDDPは開発受注(ソフトウェアベンダ)側のプロセスを想定して考案されているということ。私は開発発注(メーカー)側の人間なので、この前提の食い違いはなかなかに大きいと感じています。発注側からベンダの開発プロセスへいろいろ要求するのは他社への要求であり、導入する場合工夫が必要かなと。以前、少し仕様書の書き方変更を要求したら、普通に反発されました。また、参考書にはXDDPを導入すると開発成功率が90%になると記載がありますが、それは受注側の観点で成功と言っているだけで、発注側からは失敗とされている事例もあるのではないかと疑っています。
で、やっぱりそんなことはどうでもよくて、いかに現場の生産性を上げられるかってことを考えていきたいです。とっちらかっていますが、以上です。

*1:多少レビューされたりもするが、早急対応が求められずさんになりがち

*2:この「頑張って」の手段を研究したい