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

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

ディスカッションテーマ: USDMで良かったことと困ったこと

パネル参加者
パネリスト:
・南部妙水 (アンリツエンジニアリング)  … 技術の利用者・内部推進者,技術者 
・斎藤芳明 (富士ゼロックス)  … 技術の利用者・内部推進者,マネジャー
・高橋久憲 (エクスモーション)  … 技術の提供者・推進者,外部支援者
・鈴木三紀夫 (MRTコンサルティング)  … 技術の提供者・推進者,内部支援経験あり

モデレータ:
・林好一 (SRA)

※ パネリストのお名前の後は、本ディスカッションにおける立ち位置を表しています。

パネル議事録:

自己紹介

  パネリストの皆さんの自己紹介から。それぞれUSDM(注1)に関するご経験や導入時のご苦労などご紹介ください。

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

  それは、2度手間にならないですか?

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

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

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

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

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

  一同 笑

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

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

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

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

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

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

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

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

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

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

鈴木  USDMは要求記述の技術です。要求獲得等は別だが、開発者は要求獲得もできると思ってしまっています。また、多くの人は設計しながら仕様を考えているため、仕様と設計の分離が難しいようです。
それから、最大のネックはプロセス改善が必要な点でしょう。要求と仕様を分離すると”どの工程でどちらを書くのか?”等の問題が発生します。清水さんのセミナーでは「要求定義工程で仕様化まで行いましょう」という話があります。すると結果、要求定義工程が長くなります。標準プロセスや契約条件に適合しないこともあり、これは大きな問題です。

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

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

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

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

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

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

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

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

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

斎藤  弊社開発者は、仕様書を十分に書ききらないとレビューしたがらない傾向があります。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)
派生開発の特徴に特化した、開発プロセス。変更3点セット(注3)と呼ばれる中間成果物を使用し、変更仕様の問題や、変更箇所の間違いを早い段階でレビューによって見つけるプロセスを推奨。
参考:「派生開発」を成功させるプロセス改善の技術と極意 清水良男 著
参考:「困っていませんか?派生開発 ~XDDPはじめの一歩~」 第2版 AFFORDD T3研究会 著

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

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