「ET2014」パネルディスカッション議事録

2014年11月21日(金) ET2014スペシャルセッションにて行われました、パネルディスカッションの様子をご紹介します。

パネル議事録：

自己紹介

斎藤　　コントローラ開発部門の開発企画グループに所属し、SPI(プロセス改善)活動などの推進組織を担当しています。XDDPはそのSPI活動の中で導入しており、USDMはXDDP導入の一環で取り組みました。

高橋　　主にお客様のコンサルティングをしています。要求が明文化されていなくて困る等の声が多く、既存システムの要求をUSDMで洗い出す支援をしています。前職(メーカ)の要求分析チームではユースケース記述で纏めていましたが、実現仕様までは書かないので混乱することがありました。USDMだと要求分析工程で実現レベルの仕様まで検討することができ、混乱が減ると考え、導入を推進しています。

鈴木　　以前は内部支援者としてUSDMを組織に導入しようとしてみました。その後は、外部から導入支援をしています。
「要求」と「仕様」では「要求」の立場にあります。組込みよりもエンプラ寄りの業務が多く、(USDMについては)清水さんのコンサルを受けておらず独学です。現場からの声でUSDMに取り組んだという経緯です。

既存のドキュメントとの関係

林　　皆さんがUSDMを導入された結果、(USDMではない)既存のドキュメントはどうしていますか？

南部　　既存のドキュメント(公式ドキュメント)はそのソフトウェアに関して全範囲が書いてあります。それに対し、派生開発時に変更するところのみをUSDMで記載しています。そして、ソースコード変更後に公式ドキュメントに反映するという作業を行っています。

斎藤　　（XDDPの）変更３点セット_(注3)と既存ドキュメントとの対応は導入当初の課題の一つであり、XDDPに一気に切り替えるわけにはいきません。
テスト担当へ、変更３点セットを見せて(テスト実施)可能か聞き、いろいろな調整をケースバイケースで行っています。決定的な方法はないので、現場の工夫でやっている感じです。つまり、変更３点セットはドキュメンテーションではなく「コミュニケーションツール」と考えており、既存のドキュメントとは作成の目的が異なるものと捉えています。ただし、記述するという作業において、既存ドキュメントとの内容重複は発生すると思います。

林　　それは、２度手間にならないですか？

斎藤　　どのフェーズで書くかは現場の判断でやっています。手のあいたときに公式ドキュメントに反映している、などです。

林　　その取り組みにより、効果がでていますか？

斎藤　　いま進めているのでまだ効果がわかるところまでは、いっていません。

高橋　　手が空くことは、本当にありますか？

斎藤　　（一連のプロジェクト全体で見れば）手戻りが減るので大丈夫だと思います。その余力をマネジメントが(別のプロジェクト対応などに)取り上げたりしなければですけどね。

　　一同　笑

南部　　私のところでは、３ヶ月フェーズでモノを作っています。そのフェーズでは公式ドキュメントを更新することはできません。ただし、１年に１回タイミングを決め、公式ドキュメントを更新する時間を取るようにしています。

鈴木　　１年に１回だとテストで問題がおきそうな気がしますが、どうですか？テストでは（派生開発の既存部である）ソフト全体を無視できません。

南部　　既存のテストケースの方も、派生しています。

斎藤　　テストチームに渡すとき、変更３点セットには差分しか書かれていませんよね。テスト担当は、システム全体の仕様は前任機の公式ドキュメントを理解し、今回の差分（変更仕様）を合わせて理解してもらう必要があります。それで彼らがテスト可能かが問題となります。ただ、弊社テスト担当からは概ね「差分がハッキリするのでよりよい」という前向きな意見が多いです。

高橋　　(南部さんのところでは)テスト仕様書の変更も、TM_(注3)でやっているということですか？

南部　　いいえ。それは良い案ですね、やってみたいと思います。

実践していてどうだったか？

南部　　（派生開発の仕様である）差分だけを書くというところが、ウォーターフォール文化の人には難しいようでした。

斎藤　　要求の背景（理由）を考える習慣が、効果として大きいです。（現実起こっている問題は）仕様モレよりも要求モレの方が多いと思いますので、隠れた要求を掘り出すことには効果的です。また、表記法として仕様をBefore/Afterで書くのが良いです。多くの人は、How（実現方法）を考えてしまう傾向があります。Howから入るとBefore/Afterでは書きにくいのです。最初にHowから入ってしまうと思い込みが含まれてしまいます。ただし、HowではなくWhatのところにどう思考を持っていくかが課題です。

高橋　　既存システムからUSDMをおこすと、ベテランの知識を掘り起こせることがあり、より良い要求・仕様の検討になることもあります。ただ、実践するには文章力・整理力といったスキルが必要であり、（定着させるには）その点がネックになると思っています。

林　　標準プロセスへの対応はどうしていますか？

南部　　私のところでは、親会社（要求元）との間でプロセスが跨ることがあります。その場合、要求の文書化を親会社と一緒にやってしまいます。

斎藤　　仕様化しているときに要求の変更が見えることは良いことです。（標準プロセスなど）規則はあるが、要求分析と仕様化のプロセスは状況に応じて行き来しながら柔軟に進めています。

高橋　　クライアントによって標準プロセスが違います。ただ、標準プロセスは新規開発用が多いようです。派生開発はXDDPが標準ですとしてしまうとよいようです。

林　　皆さん、要求獲得はどうしていますか？

南部　　親会社との間では要求獲得はあまりやっていません。ほかの会社との間での要求獲得にも、USDMは使っていません。

斎藤　　要求獲得は専門部門があります。

高橋　　要求獲得に戻るような経験はあまりないです。

林　　（斎藤氏のコメントに）変更３点セットがドキュメンテーションではないとありましたが、これはどういう意味ですか？

南部　　元々は、章立てでドキュメンテーションする文化でした。その中で、Howから考える人は下（=詳細な部分）から書き上げていくので、出来上がらないとサーバアップしない傾向があります。そのため、私は後ろからPCを覗いて指摘するようにしています。最初から「こう書く」というのを指摘すると、手が止まってしまうこともあるので、書いている部分にコメントするという対応です。

鈴木　　ちょっとずつ書いてみて＆レビューを繰り返してコツを掴んでもらう、という事ですね。一番大変なのは理由です。何を理由とするかの記述が、大切です。

USDMの記法について

鈴木　　一部の仕様を抽出しにくいと感じています。設計をせずに仕様を書く、そのため「参照モデル」を使っています。USDM本に載っている、参照モデルの例を使っています。アーキテクチャテンプレート、時系列分割、構成分割などです。参照モデルとフィットすると仕様が出せると思うが、そうでないと難しいようです。参照モデルがないものの例としては「非機能要求」が代表的です。

高橋　　要求の分割、詳細化ができる所がこの表記法の良い所です。仕様の抜け漏れを防げます。しかし、テキストベースなので処理全体の流れ等はわかりづらいです。アクティビティ図等と組み合わせることで補っています。また、要求間が複雑な場合は、その関係性を明示しづらいです。Excelだと図や表が扱いにくいので、ハイパーリンク等を使って工夫したりしています。

斎藤　　書くのが難しいところは慣れが必要です。やはりHowを考えると書きにくいのでしょう。「何を特定するのか？」を意識すべきです。問題解決等でもHow思考（対策が先行）ってよくやりがちですが、Howから入る設計の文化を変えるのがキーポイントでしょう。
リスクマネジメントにも応用が効きます。多くのリスクマネジメントが難しい要因は「リスク事象が特定できていない」ことにあります。リスクの特定にUSDMを応用すればよいと思います。

林　　全く慣れない人（書けるようにならない人）っていますか？

斎藤　　今のところ出会ったことはないです。今迄のノウハウは基本的に伝えるようにしています。

高橋　　今のところ経験はないです。ただ、弊社でUSDMのトレーニングをしたときに、すぐに書ける人と書けない人がいます。この差は頭の中が整理できているかどうかだと思います。頭の中の整理にマインドマップ等を使うとよいでしょう。

鈴木　　私の周りの人はモチベーションがあるので書けないということはないです。かつて、自分自身は「書けない」方の人でした。自分自身の書き方（要求工学の知識等）を元々持っていて、それとUSDMとの対応が最初取れなかったのでつまづきました。

今後、USDMをどうしよう（どう使おう）としている？

南部　　レビューのためのものと考え、今まで通りガンガン使っていくつもりです。日本語を書くのにも慣れが必要です。Excelよりも良いツールがあれば乗り換えたいとは思います。

斎藤　　要求の質を上げるために使い倒したいです。

高橋　　USDMにはメリットがあり、USDMを導入しているクライアントが増えている印象があります。図・表が扱いづらい等の問題は解決していきたいところです。

鈴木　　従来の要求工学と違うところや独自のところがあると思います。そのために「飛び込めない」人がいるので、そのような人のために対応表を作りたいです。

林　　会場の皆さん、パネリストの皆さん、長い時間のディスカッションありがとうございました。

注1： USDM (Universal Specification Describing Manner）
「要求」と「仕様」を記述する、表記方法。要求を階層的に表現し、要求の下に仕様を記述する。
参考：[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?　清水良男 著

注2： XDDP（eXtreme Derivative Development Process）
派生開発の特徴に特化した、開発プロセス。変更３点セット_(注3)と呼ばれる中間成果物を使用し、変更仕様の問題や、変更箇所の間違いを早い段階でレビューによって見つけるプロセスを推奨。
参考：「派生開発」を成功させるプロセス改善の技術と極意　清水良男 著
参考：「困っていませんか？派生開発 ～XDDPはじめの一歩～」　第２版　AFFORDD T3研究会 著

注3： 変更３点セット
XDDPで使用する特徴的なドキュメント。変更要求仕様書と、変更設計書、これらの間と繋ぐトレーサビリティマトリクス（TM）をあわせて、「変更3点セット」と呼ぶ。変更仕様書は、USDMの表記法を使用し、変更前/後が明確に解るような記述を推奨。

注4： TM（Traceability Matrix）
XDDPの成果物、変更3点セットの一部。「変更要求仕様書」と「変更設計書」とのトレーサビリティを確保するためのマトリクス形式文書。