書籍の紹介後の引用文は、amazon, bookmeterに掲載した小川清の感想です。

Researchmapの連載の転載とリンク切れの補正の努力と、展開上関係者への配慮をしすぎた失敗の克服の記録です。

＜この記事は書きかけです。順次追記します。＞
This article is not completed. I will add some words in order.

XDDPへの道（1）アジャイル

すでに第2版がでていますが、まだ初版をうまくこなしていないので、
初版の方に関連する技術情報を記録します。

1　Agileへの逃避の問題(P6)への補足
2011年、Agileセミナを開催した際の、質疑の一部を採録します。

Q1) Agileでうまく言っている例になにがありますか？
A1-1) オープンソースの開発では、agileで動けば良いのではなく、試験まで完結した作業をする習慣が身に付いて成功している。
A1-2) 系列での仕事では、効率的になって時間が短くなったら、空いた時間に対して次の仕事が発注してもらえる場合が多いので、agileでうまくいっている場合がある。
A1-3) オープンソース、系列以外では、社長をはじめとする経営者が顧客から信頼されており、発注側に仕事の仕方の利点が説明できている場合に、うまくいく場合がある。

Q2) Agileでうまくいかない場合はどういう場合ですか？
A2-1) 効率的に仕事ができたものの、期間が見積もりより短くなったので支払いを値切られる。それならだらだらやっていた方がいいじゃんということになり終わる。
A2-2) 難しい問題をさっさと解決したら、そこで契約を打ち切られた。利益回収が可能なおいしいところは他社に切り替えられた。

Q3) Agileでむつかしいことはどんなことですか？
A3-1)　ペアプログラミングは、人間どうしの問題を含むので、どういうペアがどれくらい効率的かという問題がある。人数が少ない場合は可能なペアの数が少ないのでよいが100人くらいになるとどうペアを組むかが最大の課題になる可能性がある。

アジャイルサムライ−達人開発者への道−
Jonathan Rasmusson
オーム社(2011/07/16)
値段:￥ 2,730

どんな方法でも、別の方法を避けるための道具とすることはある。
逆に、どんな方法でも、別の方法と共存させたり、対応付けを取る事もできるかもしれない。

大事なのは前提条件、制約条件、境界条件をそれぞれ折り合いがつけてあるのかどうかではないか。
AgileはXDDPを避ける道でもないし、XDDPはAgileを防ぐ柵でもないと考える。

参考文献一覧

2012/1/19のセミナ
安全な製品作りのための自動車機能安全規格(ISO26262)適合の準備として書いています。

<この項は書きかけなので順次追記します。>
2012/1/12追記

2011年、「派生開発カンファレンス2011」においては
4.派生開発における継続的改善　　　　～ XDDPとAgile開発手法によるハイブリッドプロセスの考案～として、ソニーEMCS(株)の勝又淳さんの発表がある。

また、ソニーにおけるXPの取り組みは、
プロセス改善ナビゲーションガイドベストプラクティス編 (SEC BOOKS)
オーム社(2008/02)
値段:￥ 1,700

第3章の事例10にソニーによる「GDD(Genba Driven Development)現場主導によるアジャイル開発のすすめ」という事例報告がある。
また第3章の事例8には東京エレクトロにデバイスによる「派生開発による品質および開発効率の向上 XDDP・USDMの徹底」という事例報告がある。

XDDPへの道（2）CMM

P8に「CMMでみおとされたこと」とういう説明があります。

ソフトウェアプロセス成熟度の改善
ワッツ・S. ハンフリー日科技連出版社(1991/09) 値段:￥ 8,400
http://www.amazon.co.jp/dp/4817160330

CMM関連文献で、最初に読んだのが、「ソフトウェアプロセス成熟度の改善」でした。1994年頃です。当時、CMMを始めとするプロセス評価モデルの標準化として、ISO/IEC15504のTRをISO/IEC JTC1 SC7 WG10で審議していました。本書の翻訳者の藤野先生が、国内の委員会の主査をされていました。
優秀な技術者を集め、当時の技術の最高峰であるAdaを使っても、納期が守れない状況に対して、SEIが、日本などのソフトウェア工場的な仕事の仕方を調べて作成したのが成熟度モデルだといわれています。アメリカのような歴史の浅い国では、日本のような成熟した社会には学ぶものも多かったことが推測できます。
当初はISO/IEC 15504の内容も、経験的な事項で役に立ちそうなことが沢山書かれていました。その後、標準として他の規格との整合性を取ろうとして、形式的な記述が増えてしまったかもしれません。
ちょうど、2008年にJISが発行されました。約１５年かかったことになります。
JISを読む人も、この本も併せて読むとともに、PSP、TSP、PeopleCMMも併せて読むとよいかもしれません。
ps.
1993年にISO 9000のソフトウェアへの適用を検討していました。情報処理学会情報規格調査会の会員企業の方から推薦されて、ISO/IEC15504の標準化に取り組むことになりました。

ハンフリーが早稲田大学で講演した際に、PSPを題材にしたいということでした。
http://homepage3.nifty.com/koha_hp/process/Proc.Dr.Humphery.html
CMMが前提としていたこと、あるいは明文化してみると、
パーソナルソフトウェアプロセス技法―能力向上の決め手
Watts S. Humphrey 共立出版(1999/05) 値段:￥ 14,175
http://www.amazon.co.jp/dp/4320029291

ある勉強会で、演習問題をやっていったところ、最後までやった人は一人だけだったという話しを小耳に挟んだことがあります。
日頃、間接部門にいると、プログラムを書いていない人には、自分の能力をまずあげることが何よりも必要だということを痛感してもらえれば、大成功かもしれない。
CMMのようなモデルでは、人の能力が必ずしも上がるとは限らないことと、ソフトウェア開発には人の能力が重要で、CMMは能力のある人が集まってもうまくいかないときの課題を解決する方法である。

人の能力が大事だということを再確認したことがわかります。

また、個人と組織で決めたことがあっても、個人をどうつないで行くかが、
TSPガイドブック:リーダー編 (IT Architects'Archive)
ワッツ・S・ハンフリー翔泳社(2007/01/17) 値段:￥ 3,780
https://www.amazon.co.jp/dp/4798112909

CMM, PSPでも解決しな問題を、チームでお互いにうまくやっていくことについて抽出したもの。
CMM,PSPでうまくいかない場合に、まず、ここから取り組むとよいかもしれない。

前提条件の明文化は、文化依存で、周知のことを文書化するとは限らないことに留意すれば、異なる文化のモデルを使う場合に注意するとよいことが分かるかもしれません。

<この項は書きかけなので順次追記します。>

2011年、「派生開発カンファレンス2011」においては

導入障壁の克服についての取り組み　～T1研究会活動報告～
においてCMM/CMMIとの関係の説明があります。

作業標準(process standard)が１つであることがよいことか。
作業標準の抽象度はどれくらいか。
現場の状況に応じて仕立て(tailoring)ることをしていないのか。
作業標準と現場の対応図面を作る(mapping)ではだめなのか。
仕立てた結果がXDDP/USDMではだめなのか。
作業または診断(assessment)の際に、専門的に着付け(fitting)るのではだめか。

というあたりが鍵だと思われました。

XDDPへの道（3）　USDM(Universal Specification Description Manner)と仕様漏れ

P11に
USDM(Universal Specification Description Manner)
という単語が出てきます。

ここでは「万能仕様記述方法」と呼びます。

P10に
「仕様を誰が書くか」
という節があります。

後々には、仕様を何で書くか　と関係づけて考えてみます。

P30に現状認識として4つの課題を記載しています。

1）仕様の記述漏れ
2）読み手が仕様を誤って解釈してしまう仕様の誤解釈
3）その仕様が自分に関する仕様と気づいていないという認識不足
4）テストの段階に入ってようやく発見される仕様間の衝突

まず、この仕様の記述漏れに絞って考えてみます。

p231に「ユースケースだけでは仕様を拾いきれない」とあります。
利用事例（ユースケース）は、１つの事例を、時間または空間的に確認するための道具で、網羅性を確保するための道具ではありません。カタカナ語で喋っている弊害かもしれません。道具は道具の機能を表す名前で呼ぶとよいかもしれません。

それでは利用事例（ユースケース）は意味がないかというと、図を使ってHAZOPすると、つぎつぎ仕様の漏れが見つかることがあります。ただし、時間軸は１つの例だけになることがあるので、いろいろな事例を漏れなく検討することが必要かもしれません。

1）の仕様の記述漏れを防ぐ方法を考えてみます。
図で書いても、仕様記述言語で書いても、範囲、詳細について漏れる可能性はあります。
自然言語で書く場合と、図、仕様記述言語で書く場合の差が何かを示すとよいかもしれません。
自然言語で書く場合には、仕様の要素が書式として決まっていれば、漏れが少なくすることができるかもしれません。仕様の要素が決まっていないと、図、仕様記述言語、自然言語のどれで書いても漏れるかもしれません。

自分の経験上、よく漏れている仕様を記載します。

1）動作温度
コンピュータなどのハードウェアにはそれぞれ動作温度があります。
システム全体のうち、最も動作温度の狭い範囲でしか動作しないことを想定して、
システムの動作温度を記載してあっても、
ソフトウェアの挙動と、システムの置かれている環境によって、
動作温度を超えることがあります。

再現性のない不具合が起きる場合、また再現性があるが原因が分からない場合に、
動作温度を監視していなかたり、一番温度が上がる部分を測定していなかったり、一番弱い部分を測定していなかったことがありました。

あるICで、ネットワーク処理以外は正常に動作しているため、
温度が原因であることが分からないことがありました。
一部だけ、温度で動作が不適切になっていることがあるかもしれないと思うと、
温度の記載のない仕様（部品についても）は、心配になります。

これはハードの仕様で、ソフトの仕様じゃないと思うかもしれません。
温度監視するソフトウェアまたは温度によって処理を縮退するソフトウェアが必要かどうかを判断すると、ソフトウェアの仕様が変わってくるかもしれません。

場合によっては、温度を直接測定するフィードバックではなく、
電流を制御するフィードフォワードで実現するかもしれません。
フィードバックかフィードフォワードかでソフトウェアの作りが異なるかもしれません。

2）起きて欲しくない事象
ハードウェアでは設計上、同時に起きると挙動が不定になる場合がしばしばあります。
仕様としてハードウェア、システムとして、同時に起きると困ることの記載がない場合があります。

ある部分の対応可能な最大値はAで、別の部分のの対応可能な最大値がBであった場合、
AとBが同時に起きても対応可能かどうかの記載がない場合があります。
また、システム固有の特異点についても記載がない場合があります。
例えば、分母になる可能性がある値は0にならないことが必要かもしれません。

最近では、システムとして起きて欲しくない事象の洗い出しにHAZOPを使っています。
動作温度の情報も、起きて欲しくない事象の１つですが、しばしば起きるので、優先順位をあげています。

電源の安定性の確保、ノイズの影響もシステムの起きて欲しくない事象の１つです。

3）根拠、理由
法律に基づいているのか、商慣習なのか、自社の方針なのか、物理法則なのか、物理現象の限界なのか、仕様を決める根拠、理由の記載がないと、矛盾する根拠に基づいた仕様は、実際に利用する可能性のない組み合わせのものを作るかもしれない。

例えば動作温度だけ決まっていて、
なぜ、その動作温度なのかの理由が分からないと、
部品の変更によって動作温度が変わるかどうかが判定できないかもしれない。

同時に起こらないことがはっきりしていることは、同時に起きることを想定しなくてもいいが、同時に起こらないことの理由がはっきりしないと、状況の変化に対応できないかもしれない。

<この項は書きかけなので順次追記します。>

参考文献一覧

2012/1/19のセミナ
安全な製品作りのための自動車機能安全規格(ISO26262)適合の準備として書いています。

2011年、「派生開発カンファレンス2011」においては、
インターンシップにおける要求分析の試行　東京エレクトロン九州(株)　秋山浩司
として分析して仕様を書くまたは分析した結果として仕様を書く演習の報告があります。
これまで、ソフトウェア技術者の教育で、仕様の書き方や分析が欠けていたかもしれないことが確認できました。

XDDPへの道（4）仕様の誤解釈

1 図で誤解釈を防ぐ。
自分では、プログラミング言語のソースコードを仕様記述言語として利用する方法を模索してきた。
だから、ソースコードが仕様で、ソースコードが設計なので、誤解釈が生じないという主張をしてきたことがある。これは主にプログラマ用のツールやライブラリを作っていたこととも関係がある。
仕様としてのプログラミング言語のソースコードの記述方法を習得していない利用者がいない状況だからだ。

プログラミング言語のソースコードで意思疎通できない人とは、図を使うのが一番よいことがHAZOPなどの実習で身に付いて来た。

機械設計、電気回路設計などについての設計審査などにも参加するようになると、みんな図で議論している。
プログラマの場合には、フローチャートを使う人達と、状態遷移図、シーケンス図を使う人達で、うまく意思疎通していないことに遭遇することがある。図の抽象度の違いが相互に理解できていない場合などである。

相互理解がないことを含めて、まず図で確認する。
図での確認の際には、HAZOPの実施を推奨している。

P243に階層構造の表示の説明の図がある。
図での仕様が、誤解釈しにくいものにしていることの例のように読めました。

ところで、機械でも、電気回路でも、図を誤解釈しにくいように決まりがあります。
電気回路であれば、論理的な等価回路であっても、物理的に等価ではないように、図の抽象度についての誤解があると誤解釈の原因になるかもしれません。

P107 「GUIツールで仕様を引き出せるか」
これもユースケースの場合と同様、１つの事例を扱っているだけだという意識していることが大切なのかも。ただし、自動でいろいろな場合を模擬試験して不具合を確かめることができる場合もある。自動化がどこまで確かかで、何のための道具として使うかが明確になっているとよいかも。

2 図と表を変換する（場合によっては文章とも）

P219で「ディシジョンテーブル」の例がある。表は図よりも漏れを発見しやすいことがある。

状態遷移図から状態遷移表への変換のように、図だけだと漏れが確認しにくいものが表で確認しやすい場合もある。

3　派生開発について
派生開発の場合の誤解釈に、全体を知らない人と、部分を知らない人との間の会話に時々遭遇する。

P38 「曖昧な仕様で作業に入っている」
という指摘の事態が、双方が全体と部分を知っていれば、まだ傷が浅いのかもしれない。
発注側は全体は知っているが部分は知らない、受注側が前回と異なる人が担当したため全体を知らずに、担当する部分だけ勉強してなんとかしようとすると、とても危険だということが想定できる。

例えば、P67で提示している「トレーサビリティマトリックス」などの方法で、誤解釈を防ぐための仕掛けが大切だと思われます。

4　文書にする
図を見て合意しても、立場が違うと、見ているところが違うかもしれません。
図をもとに文書にしてみると、図とは違う視点が見えて来るかもしれない。
文書を図にするよりも、最初に図にしてから文書にした方が楽かもしれない。

図と表の変換も合わせれば、図と表と文書の相互変換ができるとよいかもしれない。
ついでにプログラムとも変換できれば、どこかの表現で漏れに気が付くかもしれない。

<この項は書きかけなので順次追記します。>

参考文献一覧

2012/1/19のセミナ
安全な製品作りのための自動車機能安全規格(ISO26262)適合の準備として書いています。

XDDPへの道（5）自分に関係する仕様の認識不足

自分に関係する仕様の認識不足を防ぐには、P67で提示している「トレーサビリティマトリックス」などの方法で、関係部分の確認を行います。

関連を自動的に検査したり、ある部分に手を加えた場合に影響を見る道具類もいろいろあるようです。

道具そのものの検査と、道具を磨くことを忘れると、道具に振り回されるだけになるかもしれません。

「トレーサビリティ」の道具の使い方として、仕様が半分も網羅していないのに、トレーサビリティを確認しているのを見ると、なんだかなという気がすることがあります。

分析の段階で、関係者があつまれば、どの部分が関係するか分かります。
例えば、一人HAZOPを実施して、班HAZOPすると、自分の認識不足を補えるし、他の部署の認識不足を補ってあげれる。

分析の際は、文章ではなく図を使うのが基本。

利用事例を書いて、利用者と意見交換したり、
GUIの道具で事例の具体的な現れ方を表示して、意見交換したりするとよいのではないでしょうか。

現物が大事なので、現物で分析するのが一番よい。
モックアップや、プロトタイプを使って分析してもよい。

図を使って分析するのは、より現物に近いものを想定して分析したいから。
現物が大事だということを忘れることがないように。

仕様の出来具合に応じて、分析時間を決めるのもよい。
仕様が十分でないと、分析時間を長くとっても効率が下がる可能性がある。

仕様を十分にするための作業があれば、手分けして、再度集まった方がよいことがある。

P36「正常系を先に実現し、ある程度落ち着いたところで異常系の仕様を考えようとするときにも起きてしまいます。」

というのを防ぐのにHAZOPがよいかも。
どの段階であれば、正常系と異常系の境界をはっきりさせ、どういう測定方法があるか、どういう対策が可能かを考え、網羅的に洗い出すので。

<この項は書きかけなので順次追記します。>

参考文献一覧

2012/1/19のセミナ
安全な製品作りのための自動車機能安全規格(ISO26262)適合の準備として書いています。

第1回「アフォード・フォーラム2011」
USDM による要件抽出漏れゼロへの挑戦～ USDM で乗り越えるユースケース記述の限界～

関連情報：
利用事例（ユースケース）は、顧客との分析、確認に用いる。
設計図としては、時系列（シーケンス）、刻時（タイミング）、状態遷移（ステート）図を用いる。利用事例だけで漏れを防ぐことは想定していない。

XDDPへの道（6)仕様の衝突

要求を仕様化する技術・表現する技術 - 入門＋実践仕様が書けていますか?
清水吉男
技術評論社(2005/10/07)
値段:￥ 2,709

仕様の衝突はP35 に、1.2.3 仕様の衝突（矛盾）として紹介がある。

仕様の衝突を検出するには、仕様記述言語で記述してみて整合性を確かめる方法がある。

JAXAでは、自然言語で記述した仕様書の衝突などを検出するソフトウェアの日本語化を行ったことがあるとお聞きしたことがある。

仕様を文章ではなく、図にしてみると矛盾に気が付くことがある。

図として推奨できるのは

1）利用事例（ユースケース）図
利用者と議論するのに便利
2）時系列図（シーケンス）図
対話、通信の手順の矛盾、衝突を見つけやすい
3）刻時（タイミング）図
回路の制約などによる矛盾、衝突を見つけやすい
4）状態遷移（ステート）図
計算機械そのものの原理に基づいているので、抜け漏れ、矛盾、衝突の発見に役立つ。

4つの図が揃えば申し分ないかもしれません。

これらの図は、そのまま試験の仕様にもなります。

図を書いただけでは、かならずしも矛盾、衝突を見つけられるとは限りません。

そのため、HAZOPによって、誘導語（ガイドワード）によって、抜け、漏れ、矛盾、衝突の発見をするために分析をします。

分析は、設計前でも、設計後でも、両方やってもよいでしょう。
ここでは分析といっていますが、設計後に実施する分析は設計審査（デザインレビュー）ということもあります。

設計前と設計後では、作業の深さ、関与する人の範囲、権限などが違います。

参考文献一覧

2012/1/19のセミナ
安全な製品作りのための自動車機能安全規格(ISO26262)適合の準備として書いています。

文書履歴(document history)

ver. 0.01 初稿　　20230819

最後までおよみいただきありがとうございました。

いいね　💚、フォローをお願いします。

Thank you very much for reading to the last sentence.

Please press the like icon 💚　and follow me for your happy life.

XDDPへの道

XDDPへの道（1）アジャイル

XDDPへの道（2）CMM

XDDPへの道（3）　USDM(Universal Specification Description Manner)と仕様漏れ

XDDPへの道（4）仕様の誤解釈

XDDPへの道（5）自分に関係する仕様の認識不足

XDDPへの道（6)仕様の衝突

関連文書(Related document)

自己参照

文書履歴(document history)

最後までおよみいただきありがとうございました。

Thank you very much for reading to the last sentence.

XDDPへの道

XDDPへの道（1）アジャイル

XDDPへの道（2）CMM

XDDPへの道（3） USDM(Universal Specification Description Manner)と仕様漏れ

XDDPへの道（4）仕様の誤解釈

XDDPへの道（5）自分に関係する仕様の認識不足

XDDPへの道（6)仕様の衝突

関連文書(Related document)

自己参照

文書履歴(document history)

最後までおよみいただきありがとうございました。

Thank you very much for reading to the last sentence.

XDDPへの道（3）　USDM(Universal Specification Description Manner)と仕様漏れ