1 開催概要
2016年6月25日 NaITE#15を以下のように開催しました。
| 開催日時 | 2016/06/25（土）
13:45 ～16:45 |
||
| 開催場所 | エナセおおた | ||
| メインテーマ | えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ | ||
| キーワード・タグ | 派生開発
XDDP USDM TM PFD |
||
| プログラム | 13:45〜14:00
|
オープニング「開会のご挨拶」
|
NaITE 運営スタッフ
|
| 14:00〜16:30
|
セッション「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」 | 八木 将計 氏
(日立製作所) |
|
| 16:30〜16:45
|
クロージング「閉会の挨拶」 | NaITE 運営スタッフ | |
| 受付サイト | http://nagasaki-it-engineers.connpass.com/event/31984/ | ||
2 勉強会の様子
今回は派生開発手法であるXDDPをテーマに開催しました。
今回も参加者は満員となり、盛況な勉強会になりました。
XDDPに関して、ある程度の知識を持った参加者が多かったのですが、ワークショップを通じて改めてXDDPの有用性を確認出来たのではないかと思います。
2.1 オープニング
オープニングではNaITEスタッフから本イベントの注意事項、NaITEについての紹介、当日のプログラムについて説明をいたしました。また，長崎で行われる下記イベントの紹介がされました。
- 10月7日（金）に長崎ブリックホール（長崎市）にて開催する「長崎QDG2016」についての説明と予定しているプログラム。
- 7月30日（土）にメルカつきまち（長崎市）にて開催する「Agile Japan長崎サテライト with NaITE」についての説明と予定しているプログラム。
その他現在活動中のSIG、活動を完了したSIGについての案内も実施いたしました。活動を終了した「マインドマップから始めるソフトウェアテスト読書会」の成果物は、近日無償公開されるということがアナウンスされました。
2.2 セッション「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」
セッションは「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」という内容で、日立製作所の八木将計氏に講義頂きました。
XDDPとは何かという概要の説明と、その後実際にワークショップを通してXDDPの考え方の体験、XDDPを導入する際の障害についての議論などを行いました。
■XDDPとは
派生開発とは、既存のシステムに新規の機能を加えるという形の開発です。現在行われているソフトウェア開発では、93％が派生開発であるという説明がありました。派生開発では、短納期であることが多く、ソフトウェア構造のすべてを理解することは時間的に難しいため、知っている範囲の理解（部分理解）で対応する必要があるとのことでした。
しかし、部分理解でソースコードを見つけ次第修正していくと修正の抜けが発生し、余計な作業が生まれる上に、品質の低い成果物が出来上がるとのことでした。
XDDPはソフトウェア構造の部分理解で、高品質なソフトウェアを開発するための手法であり、効率的なレビューを行うことにより部分理解を全体理解に近づけるというものであるということでした。
■ワークショップ1
ワークショップ1は、全員に「母体仕様書」、「変更要求仕様書」が配られ、母体に変更を加えていくというものでした。最初に母体仕様書から簡単な記号を組み合わせた母体モジュールを作成しました。その後、変更要求仕様書を上から順番に母体モジュールに適応していくというものでした。
変更要求仕様書の後半に、「この変更は他の変更より優先される」という変更要求があったため、変更のやり直しを余儀なくされるワークであり、会場からはため息などが聞こえてきました。
このワークでは、1人を除く全員がバグを作りこむという結果になりました。一見簡単そうに見えるのですが、実際にやってみると難しいワークとなっていました。
■ワークショップ2
ワークショップ1の終了後にXDDPのツールの一つであるトレーサビリティマトリクス（以下、TMと表記）についての説明がありました。
派生開発では、見つけ次第にコーディングで直していくというのは修正の間違いが起こりやすく、ソースコードを元に戻しにくくなるということでした。しかし、ソースコードを変更する前にTMに書き出すことで、修正を整理し修正内容を見やすくなるということでした。TMはマトリクス形式で記載されますが、自分の修正が必要だと思ったところを書き出すものであり、すべてを埋める必要はないとのことでした。修正の抜けに関してはTMを使用して有識者でレビューを行うことで、抜けを減らす事が出来るとのことでした。
XDDPでは、ソースコードを編集する前にTMというドキュメントを作成するため余計に工数が掛かりそうに感じるかもしれませんが、その分ソースコードを記述する時間が短縮されるので工数は変わらないとのことでした。
ワークショップ2を始める前にTMを作成する為の用紙が配られ、変更要求仕様書で母体モジュールを変更するのではなく、一旦TMに変更内容を書き出してから母体モジュールに変更を加えるというワークを行いました。
その結果、ワークショップ2では全体を平均してバグ数が2個減り、修正時間も平均して5分ほど短縮されるという結果になりました。
また、参加者からはワークショップ1の時とは違い、TMを使用したことで修正時に感じる不安感などがなくなり心理的に楽になったとの声がありました。
■ワークショップ3
ワークショップ3では「明日からXDDPを始める想像をしてみる」というワークでした。想像をしてみて、始めることで現れる「良い所」「悪い所」「障害」について出しあい、悪い所と障害についてどうすれば良いかの議論が行われました。
以下に、「悪い所」で出た意見と八木氏による回答について記載します。
- 変更内容をTMに書き出すため、見積もり時間を間違えると期限に何も出来ていない可能性がありそう。
→ 最初の導入はパイロットプロジェクトでやってみる。開発速度がでないのであれば、前のドキュメントの品質が悪い可能性がある。
- 巨大なプロダクトに対してTMを適応しようとすると、TMが巨大化する不安がある。
→ モジュールをまとめるなど工夫してみると良い。
- 長期の派生開発プロジェクトで実践すると、ドキュメント量が膨大になりそう。
→ ドキュメントの量が膨大になる可能性はある。状況を見て、ドキュメントを統合させられるときに統合させると良い。
- 現状のプロセスに合わないため、反対意見が出そう。
→ 自分の身の回りの人から導入してみると良い。XDDPという名前で敬遠されることもあるため、XDDPという名前を出さないでツールを導入してみる方法もあり。
- 見えている修正部分のみのテストしか行わなくなりそう。
→ テストに関しては全体を考えることも必要。そこはプロジェクトの後半の段階で別途行う必要がある。XDDPではプロジェクトの修正範囲を特定する段階がメインスコープである。
- 長期間XDDPで開発を行っていると、差分だけのドキュメントが増えて、最新の状態の確認が難しくなりそう。
→ XDDPのプロセスに正式文書の更新の段階もある。
- XDDPを実践しても、現状のプログラムの構造は改善されない
→ XDDPは現状のプログラムをなるべく汚くしないで修正を加える手法である。最新のUSDMバージョン２では品質要求に対しても記載されている。
3 参考情報・リンク等
当日の発表資料等は以下をご参照下さい。
・OP資料
http://www.slideshare.net/Ikedon/naite15
・ワークショップ演習資料一式
https://naite.swquality.jp/doc/NaITE15_doc.zip
4 次回の予定等
次回は8/20「マインドマップから始めるソフトウェアテスト 読書会SIG 活動報告会」をテーマとして開催の予定です。
2015年10月〜2016年3月にかけて行なわれたNaITE SIG活動「マインドマップから始めるソフトウェアテスト 読書会SIG」の活動内容とその成果について、SIGメンバーより報告いたします。ぜひ参加をご検討ください。
以上
－－－－－
2016年7月4日作成
報告者：角田 俊（NaITE 運営スタッフ）