ET2014 パネルディスカッション
2014年11月21日(金) ET2014スペシャルセッションにて行われました、パネルディスカッションの様子をご紹介します。
ディスカッションテーマ： USDMで良かったことと困ったこと
パネル参加者
- パネリスト ： 南部妙水 (アンリツエンジニアリング) ... 技術の利用者・内部推進者，技術者
- パネリスト ： 斎藤芳明 (富士ゼロックス) ... 技術の利用者・内部推進者，マネジャー
- パネリスト ： 高橋久憲 (エクスモーション) ... 技術の提供者・推進者，外部支援者
- パネリスト ： 鈴木三紀夫 (MRTコンサルティング) ... 技術の提供者・推進者，内部支援経験あり
- モデレータ ： 林好一 (SRA)
※ パネリストのお名前の後は、本ディスカッションにおける立ち位置を表しています。
パネル議事録：
自己紹介
林 パネリストの皆さんの自己紹介から。それぞれ USDM (注1) に関するご経験や導入時のご苦労などご紹介ください。
南部 私は、プロジェクトの１メンバーという立ち位置にあります。 (派生開発のプロセスとして)ウォーターフォール崩しでは限界があり XDDP (注2) を導入しました。USDM は XDDP に取り組む際に、その手法の一部として採用しています。 現在、社内ワーキンググループを組織し、導入支援の立場にもなっています。 XDDP、USDM を採用するプロジェクトは、直面した問題の解決策を求めて切羽詰まっているので、導入への障壁は感じていません。
斎藤 コントローラ開発部門の開発企画グループに所属し、SPI(プロセス改善)活動などの推進組織を担当しています。 XDDP はその SPI 活動の中で導入しており、USDM は XDDP 導入の一環で取り組みました。
高橋 主にお客様のコンサルティングをしています。要求が明文化されていなくて困る等の声が多く、既存システムの要求を USDM で洗い出す支援をしています。 前職(メーカ)の要求分析チームではユースケース記述で纏めていましたが、実現仕様までは書かないので混乱することがありました。 USDM だと要求分析工程で実現レベルの仕様まで検討することができ、混乱が減ると考え、導入を推進しています。
鈴木 以前は内部支援者として USDM を組織に導入しようとしてみました。その後は、外部から導入支援をしています。
「要求」と「仕様」では「要求」の立場にあります。組込みよりもエンプラ寄りの業務が多く、(USDM については) 清水さんのコンサルを受けておらず独学です。 現場からの声で USDM に取り組んだという経緯です。
既存のドキュメントとの関係
林 皆さんが USDM を導入された結果、(USDMではない)既存のドキュメントはどうしていますか？
南部 既存のドキュメント(公式ドキュメント)はそのソフトウェアに関して全範囲が書いてあります。それに対し、派生開発時に変更するところのみを USDM で記載しています。 そして、ソースコード変更後に公式ドキュメントに反映するという作業を行っいます。
高橋 私の場合は、変更するところのみを書くというよりシステム全体の要求仕様を USDM で書いています。 それにより既存ドキュメントを USDM で置き換えられるという期待をするクライアントもいますが、既存のドキュメントにも役割があって捨てることは難しいです。 必要な場合はツールを導入するなど、情報の重複はしないようにして既存ドキュメントと、USDM の両方を活かしています。
斎藤 （XDDPの）変更３点セット (注3) と既存ドキュメントとの対応は導入当初の課題の一つであり、XDDP に一気に切り替えるわけにはいきません。
テスト担当へ、変更３点セットを見せて(テスト実施)可能か聞き、いろいろな調整をケースバイケースで行っています。決定的な方法はないので、現場の工夫でやっている感じです。 つまり、変更３点セットはドキュメンテーションではなく「コミュニケーションツール」と考えており、既存のドキュメントとは作成の目的が異なるものと捉えています。 ただし、記述するという作業において、既存ドキュメントとの内容重複は発生すると思います。
林 それは、２度手間にならないですか？
斎藤 どのフェーズで書くかは現場の判断でやっています。手のあいたときに公式ドキュメントに反映している、などです。
林 その取り組みにより、効果がでていますか？
斎藤 いま進めているのでまだ効果がわかるところまでは、いっていません。
高橋 手が空くことは、本当にありますか？
斎藤 （一連のプロジェクト全体で見れば）手戻りが減るので大丈夫だと思います。その余力をマネジメントが(別のプロジェクト対応などに)取り上げたりしなければですけどね。
一同 笑
南部 私のところでは、３ヶ月フェーズでモノを作っています。そのフェーズでは公式ドキュメントを更新することはできません。 ただし、１年に１回タイミングを決め、公式ドキュメントを更新する時間を取るようにしています。
鈴木 １年に１回だとテストで問題がおきそうな気がしますが、どうですか？テストでは（派生開発の既存部である）ソフト全体を無視できません。
南部 既存のテストケースの方も、派生しています。
斎藤 テストチームに渡すとき、変更３点セットには差分しか書かれていませんよね。テスト担当は、システム全体の仕様は前任機の公式ドキュメントを理解し、今回の差分（変更仕様）を合わせて理解してもらう必要があります。 それで彼らがテスト可能かが問題となります。 ただ、弊社テスト担当からは概ね「差分がハッキリするのでよりよい」という前向きな意見が多いです。
高橋 (南部さんのところでは) テスト仕様書の変更も、TM (注3) でやっているということですか？
南部 いいえ。それは良い案ですね、やってみたいと思います。
実践していてどうだったか？
南部 （派生開発の仕様である）差分だけを書くというところが、ウォーターフォール文化の人には難しいようでした。
斎藤 要求の背景（理由）を考える習慣が、効果として大きいです。（現実起こっている問題は）仕様モレよりも要求モレの方が多いと思いますので、隠れた要求を掘り出すことには効果的です。 また、表記法として仕様を Before/After で書くのが良いです。多くの人は、How（実現方法）を考えてしまう傾向があります。 How から入ると Before/After では書きにくいのです。最初に How から入ってしまうと思い込みが含まれてしまいます。 ただし、How ではなく What のところにどう思考を持っていくかが課題です。
高橋 既存システムから USDM をおこすと、ベテランの知識を掘り起こせることがあり、より良い要求・仕様の検討になることもあります。 ただ、実践するには文章力・整理力といったスキルが必要であり、（定着させるには）その点がネックになると思っています。
鈴木 USDM は要求記述の技術です。要求獲得等は別だが、開発者は要求獲得もできると思ってしまっています。 また、多くの人は設計しながら仕様を考えているため、仕様と設計の分離が難しいようです。
それから、最大のネックはプロセス改善が必要な点でしょう。要求と仕様を分離すると”どの工程でどちらを書くのか？”等の問題が発生します。 清水さんのセミナーでは「要求定義工程で仕様化まで行いましょう」という話があります。すると結果、要求定義工程が長くなります。 標準プロセスや契約条件に適合しないこともあり、これは大きな問題です。
林 標準プロセスへの対応はどうしていますか？
南部 私のところでは、親会社（要求元）との間でプロセスが跨ることがあります。 その場合、要求の文書化を親会社と一緒にやってしまいます。
斎藤 仕様化しているときに要求の変更が見えることは良いことです。 （標準プロセスなど）規則はあるが、要求分析と仕様化のプロセスは状況に応じて行き来しながら柔軟に進めています。
高橋 クライアントによって標準プロセスが違います。ただ、標準プロセスは新規開発用が多いようです。 派生開発は XDDP が標準ですとしてしまうとよいようです。
林 皆さん、要求獲得はどうしていますか？
南部 親会社との間では要求獲得はあまりやっていません。 ほかの会社との間での要求獲得にも、USDM は使っていません。
斎藤 要求獲得は専門部門があります。
高橋 要求獲得に戻るような経験はあまりないです。
林 （斎藤氏のコメントに）変更３点セットがドキュメンテーションではないとありましたが、これはどういう意味ですか？
斎藤 弊社開発者は、仕様書を十分に書ききらないとレビューしたがらない傾向があります。
USDM 記述のトレーニング演習でも、レビューしながら記述内容を特定していく練習なのに、「まだレビューできる段階ではない」となかなかレビューを始めてくれなかったりします。
レビューのために USDM を作成するのであり、USDM を作成すること自体が目的ではないことを強調する意味で、あえてドキュメンテーションとは言わないようにしています。林 慣れてない人に対して、どう対応していますか？
南部 元々は、章立てでドキュメンテーションする文化でした。その中で、How から考える人は下（=詳細な部分）から書き上げていくので、出来上がらないとサーバアップしない傾向があります。 そのため、私は後ろから PC を覗いて指摘するようにしています。最初から「こう書く」というのを指摘すると、手が止まってしまうこともあるので、書いている部分にコメントするという対応です。
鈴木 ちょっとずつ書いてみて ＆ レビューを繰り返してコツを掴んでもらう、という事ですね。 一番大変なのは理由です。何を理由とするかの記述が、大切です。
USDMの記法について
鈴木 一部の仕様を抽出しにくいと感じています。 設計をせずに仕様を書く、そのため「参照モデル」を使っています。 USDM 本に載っている、参照モデルの例を使っています。アーキテクチャテンプレート、時系列分割、構成分割などです。 参照モデルとフィットすると仕様が出せると思うが、そうでないと難しいようです。参照モデルがないものの例としては「非機能要求」が代表的です。
高橋 要求の分割、詳細化ができる所がこの表記法の良い所です。仕様の抜け漏れを防げます。 しかし、テキストベースなので処理全体の流れ等はわかりづらいです。アクティビティ図等と組み合わせることで補っています。 また、要求間が複雑な場合は、その関係性を明示しづらいです。Excel だと図や表が扱いにくいので、ハイパーリンク等を使って工夫したりしています。
斎藤 書くのが難しいところは慣れが必要です。やはり How を考えると書きにくいのでしょう。 「何を特定するのか？」を意識すべきです。問題解決等でも How 思考（対策が先行）ってよくやりがちですが、How から入る設計の文化を変えるのがキーポイントでしょう。
リスクマネジメントにも応用が効きます。多くのリスクマネジメントが難しい要因は「リスク事象が特定できていない」ことにあります。 リスクの特定に USDM を応用すればよいと思います。
南部 （派生開発の仕様を表記するのに）USDM に拘る必要はないと思います。 書けない人の言い訳に「日本語で書けない」がありますが、書くのに困って手が止っている人だったら、別の方法（形式手法等）でもよいと思うのです。
それから、英語だと変更仕様の Before/After を一文で書きにくいです。私のところでは、Before と After の欄を作り、差分を赤字にしてもらう等で対応しています。 清水さんは USDM の仕様欄を分けるのを推奨していませんが、英語の場合はこの方が文体として見やすいです。
林 全く慣れない人（書けるようにならない人）っていますか？
斎藤 今のところ出会ったことはないです。今迄のノウハウは基本的に伝えるようにしています。
高橋 今のところ経験はないです。ただ、弊社で USDM のトレーニングをしたときに、すぐに書ける人と書けない人がいます。 この差は頭の中が整理できているかどうかだと思います。頭の中の整理にマインドマップ等を使うとよいでしょう。
鈴木 私の周りの人はモチベーションがあるので書けないということはないです。 かつて、自分自身は「書けない」方の人でした。自分自身の書き方（要求工学の知識等）を元々持っていて、それと USDM との対応が最初取れなかったのでつまづきました。
今後、USDMをどうしよう（どう使おう）としている？
南部 レビューのためのものと考え、今まで通りガンガン使っていくつもりです。 日本語を書くのにも慣れが必要です。Excel よりも良いツールがあれば乗り換えたいとは思います。
斎藤 要求の質を上げるために使い倒したいです。
高橋 USDM にはメリットがあり、USDM を導入しているクライアントが増えている印象があります。 図・表が扱いづらい等の問題は解決していきたいところです。
鈴木 従来の要求工学と違うところや独自のところがあると思います。 そのために「飛び込めない」人がいるので、そのような人のために対応表を作りたいです。
林 会場の皆さん、パネリストの皆さん、長い時間のディスカッションありがとうございました。
注1： USDM (Universal Specification Describing Manner）
「要求」と「仕様」を記述する、表記方法。要求を階層的に表現し、要求の下に仕様を記述する。
参考：[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか? 清水良男 著
注2： XDDP（eXtreme Derivative Development Process）
派生開発の特徴に特化した、開発プロセス。変更３点セット（注３）と呼ばれる中間成果物を使用し、変更仕様の問題や、変更箇所の間違いを早い段階でレビューによって見つけるプロセスを推奨。
参考：「派生開発」を成功させるプロセス改善の技術と極意 清水良男 著
参考：「困っていませんか？派生開発 〜XDDPはじめの一歩〜」 第２版 AFFORDD T3研究会 著
注3： 変更３点セット
XDDPで使用する特徴的なドキュメント。変更要求仕様書と、変更設計書、これらの間と繋ぐトレーサビリティマトリクス（TM）をあわせて、「変更3点セット」と呼ぶ。変更仕様書は、USDM の表記法を使用し、変更前/後が明確に解るような記述を推奨。
注4： TM（Traceability Matrix）
XDDPの成果物、変更3点セットの一部。「変更要求仕様書」と「変更設計書」とのトレーサビリティを確保するためのマトリクス形式文書。