NaITE #15「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」に参加しました

2016/6/25(土) NaITE #15「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」に参加してきました。

connpass
http://nagasaki-it-engineers.connpass.com/event/31984/

場所は「エセナおおた」です。自宅から自転車で１０分かからないくらい。
参加者は２０名くらいでしょうか。

自社の業務で開発プロセスの整備・適用推進を担当しているのですが、その中に保守に関するガイドがあり、XDDPの要素を取り入れています。
清水さんの本もじっくり読みました。

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

posted with amazlet at 16.07.02

清水 吉男
技術評論社
売り上げランキング: 50,551

Amazon.co.jpで詳細を見る

そんなわけでXDDPに興味があり、会場も近かったので、ちょうど良い機会ということで参加しました。
今回は「派生開発カンファレンス2016」で実施したワークショップの再演だそうです。

---

オープニング

NaITE#15オープニング資料 from Akira Ikeda

主催が「NaITE（長崎ＩＴ技術者会）」となってますが、東京でやっている勉強会だそうなｗ

---

えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ

この日のワークショップ資料一式は↓でZIPが公開されています。
http://naite.swquality.jp/doc/NaITE15_doc.zip

派生開発カンファレンス2016の再演ということで、その時の資料は↓で公開されていますね。
http://affordd.jp/conference2016_program.shtml#subject9



以下、当日取ったメモ。
---

派生開発とは？

• 世の中の93%が派生開発。
• 母体の仕様欠落が特徴。派生開発には母体ソースコードがある、という特徴がある。ベースがある。
• 往々にして母体の仕様の一部もしくはすべてが失われている
• 短納期：　作る量があんまり多くない。なので納期が短いことが多い。
• 合わないプロセス：　派生開発のやりかたが世の中にあんまりない。V字とかを少し改変してることが多い。プロセスがない。
• 丸投げ：　「短納期」、「合わないプロセス」から、丸投げになることが多い。一人プロジェクトが多い。
• デグレード：　新人とか他から来た人とかは母体の中身を知らないので、デグレードとか手戻りが起こる。
• それで品質が下がって納期遅延になって、ヤル気が低下する。

派生開発の課題とは？

• なぜうまく行かないのか。
• 普段、我々がどうしてるか、を考えてみる。
• 高品質で納期を守らないといけない。
• そのためには部分理解でコーディングする。「部分理解」というのはXDDP提唱者の清水さんが好きな言葉。
• 全部を理解する時間がない。なので見つけ次第コーディングする。

---

ワークショップ１： 「XDDPゲーム」

いったん講演を中断し、XDDPを適用する場合としない場合を体験してみるワークショップをやりました。
題材は派生開発カンファレンス2016のページに公開されてます。これが中々面白いｗ

まず「母体仕様書」が渡されます。

次に「変更要求仕様書①」が渡され、そこに書かれている変更要求を上から下へ順にやっていきます。
上から下に順にやっていくと手戻りが頻発するシナリオになっていて、なんども手戻りが発生して右往左往します・・・

次に「変更要求仕様書②」が渡され、合わせてTM（トレーサビリティマトリクス）も渡されます。
今後はTMを使って、変更箇所を先に洗い出してから母体に変更をかけていきます。

結果として、前者よりも後者の方が、時間は５分ほど速く、不正解の数も減りました。
こーゆうワーク、良いですね。
「見付け次第コーディング」の弊害について、楽しみながら本質に迫ることが出来ます。

---

再度、講演

ワークショップ終了後、再度講演の続きです。

新規開発崩し

• 「品質を高めないとね」といくことで、「全体を理解してやりなさい」という話になる。
• そこで「新規開発崩し」をやる。これは清水さんが好きな言葉。

部分理解

• 納期厳守と高品質、両方はできない。XDDPは「部分理解しか無理」という思想。
• XDDPは部分理解を前提としたレビュー中心の手法である。

見付け次第コーディング

• 「ながら」作業なので無駄になる
• 元に戻しにくい　→　コード劣化
• 1個前にロールバックするのはそれほど面倒くさくないけど、3つ前ににロールバックとかは面倒くさい。
• コーディングするのを少し止める、のがポイント。
• すぐコードを触りたがる人が多いので、けっこう抵抗される。

ワークショップの結果

• さっさやったワークショップで、XDDPを適用することでバグが2.8→1.93に減った。
• 更に、時間が5分くらい早くなった。
• つまり、コーディングを遅らせたりTMを作らせたりしても、時間は遅くなってない。

清水さんの言葉

• 最後にやる「変更」にかかる時間を計測することで、数字として取れるはず。
• 「変更」にかかる時間は事前に予想できるのだから、それ以外の時間は「分析」に当てよ。

変更プロセス

• 変更プロセスは、V字の新規開発プロセスとは全然違う。
• フロー右の「機能追加プロセス」は、クラスとかメソッドとかの単位で考える。
• フロー左の「変更プロセス」は、コードの行単位で直す。

• 完全なプロセスはXDDPは謳ってない。

XDDPの３点セット

• USDM、TM、変更設計書

USDM

• 動詞から仕様グループを出す。全部の動詞を書きましょう。
• 基本的には処理なので動詞で書けるはず。必要な処理を動詞で抜き出して漏れを探す。

変更設計書

• before/afterを書きましょう。afterだけ書くのはダメ。
• 何を何に直す、と書く。
• 認識のズレとかを無くす。

TM

• USDMにTMをくっつける。
• USDNとTMの粒度を合わせないといけない。
• USDMがゆるいと、ＴＭに全部○が付いてしまったりする。
• TMの横軸に全部のモジュールを書く。全部書かないと漏れる。書く位置は、機能単位とかで固定する。
• TMがでっかくなる、どうしたらいいか、というのがよく問題になる。
• TMという名前もよくない。マトリクスを塗りつぶしたくなる人がいるので・・・。そうじゃない。
• TMは、「私はここに影響があると思います」という調査の戦略を寝るためのもの。
• 「そこ、ぬけとるやん」と言わせるためのもの。

---

ワークショップ２：　「明日からXDDPを始める」と想像してみよう

XDDPを導入に関して、「①良くなる点　②悪影響　③導入を妨げる障害　④導入の中間目標」という4象限について考えるため、インジェクションマトリクスというものを作りました。　
各個人でいったん考えてインジェクションマトリクスを作り、それを1人1人発表していって、講師の八木さんが纏めてくださいました。
纏め結果はワークショップ資料一式（ http://naite.swquality.jp/doc/NaITE15_doc.zip ）の中に入ってます。

その中で出た意見をいくつかピックアップしてみる。

• 変更時間の見積りを間違えると何もかもできてない可能性がある
  • →　確かに見積もりをミスると痛いので、パイロットをやるのがいい。

• 「変更」の速度が出ないのは、前のドキュメントが悪い。そのまま進むとダメ。
  • 変更設計書の作りが悪いなら、変更設計書を作り直すべき。

• 「全体」についてはXDDPの外枠で考えなければならない。XDDPはあくまで「差分のみ」に着目する。
  • 総合テストで全体をテストする。
  • 清水さんの本は、テストのことは２行くらいしか書いてない。
  • TMの右横に、テスト資産もつけておくと良い。
  • 全体感のあるテストが必要になる。

• 保守性、リファクタリングの変更要求を入れろ、と清水さんは言ってる。

---

感想

講演もワークショップも充実していて、とても学びが多く楽しいヒトトキでした。
XDDPの本質を再認識する良い機会でした。

八木さん、関係者の皆様、ありがとうございました。