ソフトウェア品質技術研究
～あなたを変える、組織を変える、社会を変える～

機能安全を切り口としたソフトウェア品質改善文化構築について

小谷田　一詞氏（日本自動車研究所）

チームビルディングの実践と理論～組織とコミュニケーションのモデリング～

栗田太郎氏（フェリカネットワークス）
林眞弓氏（デバッグ工学研究所）
増田礼子氏（フェリカネットワークス）

ソフトウェア品質シンポジウム2011（会場：東洋大学/東京）

UX（ユーザーエクスペリエンス）の考え方とアプローチ

アジャイル開発での品質向上への取り組み

細谷　泰夫氏（三菱電機株式会社）

構造化知識の活用による設計不具合の予測と未然防
～ソフトウエア不具合の知識化と気づきについて考える～

田村　泰彦氏（株式会社構造化知識研究所）
野々村　望氏（レシップ株式会社）

ITアーキテクチャ設計とITアーキテクトの着眼点

分科会成果発表会

日時

2012年5月11日（金）　10:10～12:00

会場

日本科学技術連盟・東高円寺ビル　地下1階講堂

テーマ

「ソフトウェア品質技術研究～あなたを変える、組織を変える、社会を変える～」

講師名・所属

野中　誠氏（東洋大学）

司会

SQiP研究会運営委員長　秋山 浩一氏　（富士ゼロックス株式会社）

アジェンダ

1. ようこそ、SQiP研究会へ
2. ソフトウェア品質技術が生み出す「価値」
3. ソフトウェア技術者への期待：品質技術の研究
4. ソフトウェア品質技術研究の例：メトリクスの基礎と応用研究

アブストラクト

　ソフトウェア品質技術は、さまざまな「価値」を生み出す有用な技術です。すなわち、顧客にビジネス価値をもたらし、安心・安全な社会を実現し、組織の強みを増幅させ、そして、あなた自身の成長につながります。
　しかし、ソフトウェア品質技術にはまだ未成熟な部分があり、研究の余地が多く残されています。より優れた「価値」のためには、ソフトウェア技術者である皆様が、現場のニーズを踏まえて品質技術を考え、実践することが求められます。
　この講義では、SQiP研究会のキックオフとして、まずは研究員の皆様に期待したいことをお話しします。また、ソフトウェア品質技術の一つであるメトリクスを取り上げ、その基礎と、定量的管理への応用について、私の研究成果や技術動向などを交えてご説明します。

＜講義の要約＞
◆ようこそ、SQiP研究会へ
SQiPは、実践的で実証的なソフトウェア品質技術・施策の研究・普及を目的として設置された、ソフトウェア品質向上のための推進組織である。お金を払った人だけが関われる閉じた世界ではなく、「ソフトウェア品質を良くしたい」という思いを共有する方なら誰でも参加できるオープンな場で、コミュニティもある。
SQiPの「P」には、高度な教育訓練を受けた専門的職業を意味する「プロフェッション(Profession)」という語をあてている。ソフトウェア技術者は聖職者・弁護士・医師に次ぐ「第4のプロフェッション」となるべく自覚を持って行動する時期にきている。
SQiP研究会は、その先にある、SQiPシンポジウムや世界ソフトウェア品質国際会議(WCSQ)などの広範なソフトウェア品質活動への「入口」である。また、オープンイノベーションを起こせる場でもある。オープンイノベーションとは、企業内部と外部のアイデアを有機的に結合させ、価値を想像することである。ソフトウェア品質もオープンイノベーションが必要である。自社の取り組みや情報を社外には出せないため論文が書けない、という話を聞くが、取り組みを社外に出したところで、他社はそう簡単には真似できない。実際、組織に根付かせ、効果がでるまで長い歳月がかかる。研究会は外部のアイデアを得るよい場である。是非ベストプラクティスの共有をしていただきたい。

◆ソフトウェア品質技術が生み出す「価値」
ソフトウェア品質に対する取り組みは、顧客に価値を提供する全社的な取り組みである。顧客にどのような価値を提供するかを定義し、その価値により高い顧客満足度を維持し続けるために、組織として、また個人単位で取り組む「必要な活動」を定義し、実践する。必要な活動として、顧客価値を提供／創造できるソフトウェアは何か？を考える。
開発スピードを加速させるために、欠陥の検出・除去・混入予防に必要な活動を定義する。単にレビューやテストに時間をかけるだけではなく、そもそも設計をどうするか？を考えることで混入予防につながる。また、混入をさせてしまうメカニズムはいろいろなところにある。単に作りこみ過程だけでなく、組織体制などにも問題があるだろう。品質部門と開発部門の役割が分かれ過ぎていると、「あとはやってくれるだろう」と甘えがちになる。
この段階のテスト、レビューでは、どういう観点で行うべきだろうかを考えることも必要である。
価値提供の結果を評価し、欠陥に学ぶことで、意味のあるフィードバックができる。一連のフィードバックを積み重ねることで組織は賢く、強くなれる。賢く、強くなった組織は、幸せになる。
品質にしっかりと取り組めば、開発コストを下げられる。安易な品質コストの削減は、取り返しのつかないところまで組織能力を衰退させる。

◆ソフトウェア技術者への期待：品質技術の研究
東洋大学の「社会人力ノート」に記載されている、社会人心得と技術者心得についての紹介。
社会人心得には、発信力、傾聴力が大切であることと、柔軟性、情況把握力、規律性、ストレスコントロール力が必要であることが書かれ、技術者心得には、手と機械と心を一体化させることや、知識と智慧を身につけること、世界観を持つこと、心で現象を見ることの大切さなどが書かれている。
ソフトウェア品質技術・施策を研究するにあたり、「社会人心得・技術者心得」を心に留めてほしい。
研究会での皆さんのアイデアや貢献を、SQuBOKへ位置づけたい。

◆ソフトウェア品質技術研究の例：メトリクスの基礎と応用研究
なぜメトリクスが必要なのか？「よそが測っているから」ではなく、「必要な情報」を得た上で意思決定をするために必要である。「必要な情報」として、主観的情報だけではエビデンスとして説明責任が果たせない。メトリクスを定めることで、必要な情報を効果的に一貫して収集でき、組織やメンバーに説明可能な根拠情報として利用できる。
しかしメトリクスは万能ではない。実世界で測定できることは、測定したい概念のごく一部にすぎない。メトリクスの限界を理解した上で“Informed decision”に役立てる。
測定には信頼性と妥当性が求められる。具体的には、信頼性は「誰が何度測定しても同じ結果が得られるか」、妥当性は「測定したい概念を正しく捉えているか」「意思決定や予測に役立つか」「測定したい概念を十分カバーしているか」が挙げられる。また、メトリクスを用いて何を評価したいのか、目的を意識すること。実体把握に用いるなら、目的によって要求される精度は異なる。予測や計画に用いるなら、精度は粗くてもよいが手順の再現性を重要とする。評価に用いるのなら、高い精度が必要となる。

上流工程までの欠陥除去率を評価しようとして、上流工程までの欠陥除去数を欠陥総数で割ると、上流工程での欠陥除去率が実際より低くなる場合がある。これは下流工程で混入した欠陥数も総数に含めてしまった結果である。下流工程で除去した欠陥については、混入工程を把握しておく必要がある。また、目標値を意識するあまり、実際の欠陥の粒度を変えて件数を増やし数字合わせをするというような、期待外れな行動にでてしまうことがある。欠陥の粒度のガイドラインを定めておく必要がある。欠陥を管理している組織は多いが、欠陥の粒度定義と測定精度の確認を行なっている企業は少ない。
欠陥の数え方は、組織によって様々である。また、欠陥1件の粒度について、IEEE標準やISO規格では特に言及していない。ここでソフトウェア欠陥1件の数え方の例を挙げる。開発プロセス全体で欠陥の粒度に一貫性をもたせ、欠陥除去工程のパフォーマンスを正しく評価したい場合、プロダクトの原因部分で集約して1件と数える。プロセス単位で集約してしまうと、何もかも1件として集約されてしまう可能性が高まる。あくまで見逃した欠陥はいくつか？を考える。
欠陥識別のタイミングをどこにするか？非公式レビューにおける指摘も欠陥数に含めるのか？欠陥識別のタイミングについて「原則」を定めることは難しい。
欠陥測定の信頼性を高めるには、開発プロセスと欠陥メトリクスを紐付けることも重要である。欠陥の混入と除去に関連するアクティビティを定義する。
欠陥の数を扱う前に考えなければならないことは、「何に関する欠陥なのか」と「どこまでを欠陥とするのか」である。欠陥には計算ミスなど現時点で修正が必要な機能性欠陥と、コードの読みやすさなど将来の機能性欠陥につながる発展性欠陥がある。欠陥除去のフロントローディングを議論するときは機能性欠陥に着目する。また、発展性欠陥は、早い段階で除去する。欠陥のタイプに応じて、どのタイミングで指摘し、欠陥除去するべきかを考えることが重要である。

DRE(Defect Removal Efficiency)は各工程またはプロセス全体の欠陥除去率で、欠陥除去能力の低い工程を特定し重点的に改善する目的で用いる。PDCE(Phase Defect Containment Effectiveness)はフェーズ欠陥阻止率(各々の欠陥除去工程で除去すべき欠陥をどれだけ除去できたか)で、見逃した欠陥に着目し、レビュー技法やチェックリストの改訂を行う目的で用いる。どちらも終わったプロジェクトに対して測定する。プロジェクト中に介入し判断したい場合、欠陥除去率の分母は予測値になる。

ソフトウェア欠陥数の予測に、欠陥数と相関の高い変数を用いて予測精度を高めることは可能であるが、因果関係の有無を確認しないまま用いている場合もある。なぜ相関が高いのかまで分析して用いることが大事である。
有用そうな変数について、箱ひげ図を描いて欠陥数に影響する要因を探ってみる方法もある。ただし、相関係数を高くすることにこだわりすぎて、変数の入れ替えに専念してしまってはいけない。

fault-prone(欠陥が含まれていそうな)モジュールの予測のイメージを説明すると、コーディング／単体テストが終わった時点で、ソースコードから測定可能なプロダクトメトリクスやプロセスメトリクスを用いて、機能テスト／システムテストで欠陥が見つかりそうなモジュールに対してレビューやテストの優先度／重要度を決め、効率／効果を高める。

欠陥修正の有無を何らかのメトリクスで予測する事例の紹介。
データ分析により、複雑度重み付き規模(WMC)、結合度(CBO)、凝集度の欠如度合い(LCOM)の3つの変数により、欠陥修正の有無を高い精度で予測できた。100%ではないが、どのモジュールに対し欠陥が発生したのか、ある程度説明できるものがでてくる。

メトリクスをとる上で大事なことは、分析をしたところから踏み込めること。レビューやテストなどのアクションや品質に繋げられること。そこから根っこのしっかりした議論ができる。
John Maynard Keynesの言葉に「精密に誤るよりも、漠然と正しくありたい」というものがある。メトリクスの取り組みで忘れてはいけない基本姿勢である。取り組んでいるうちに、精密に相関係数を見だしたり、相関係数が高くなることにこだわったりしてしまうが、それが狙いではない。あくまで「このメトリクスでこういうことが得られたから、ではこういうアクションを取ろう」という正しい意思決定に役立つことが目的である。

◆質疑応答
Q. いろいろなメトリクスをとろう、という活動を、これからはじめる会社もあると思う。
その場合、どこから手を付けるのがよいか？なにを測るのがよいか？
メトリクス初心者用のおすすめのメトリクスはあるか？
A. まずはテストでみつけた現象や、レビューの指摘数を測り、「その件数が少なくなること」を見ることから始めてみてはどうか。

Q. 欠陥の数え方について、重み付けがあると思う。もっと複雑ではないか？
同じ「1個」ではなく、どこでみつけたか、で、重みが違う。（あとで見つけると大変だから今見つかってよかった、というものは重みがある。）
A. DREを用いて見てみると、圧倒的に上流で除去されるほうがインパクトが抑えられるのがわかる。しかし、重みが表に出ない。道理を解釈して数字を見る。
あるいは、実際いくらかかったのか？を計算する。システムテストで出たバグについて、工数を計算することでインパクトの大きさが明らかにでてくる。そのような値と紐付けるという手もある。

Q.マネージャに対して、メトリクスとは何なのか（メトリクスは何のためにとるのか）を、説明するには？
A. 意思決定に役立たせたい。これがベースだと思う。例えば、なにがどうまずいのか？わかりやすく伝えられる。過去の統計からすると、絶対無理だろう、ということが示せる。
そのために、意思決定に使えるようなものをとる。何を見ておけば、説明できるだろうか？を考えておく。

＜講義の感想＞
欠陥の測定を中心に、様々なメトリクスの測りかたや測る上で留意することを紹介いただき、大変参考になりました。また、研究を行う上で、目標や目的を意識することと根拠や効果を示すことの大切さを改めて気付かせてくださる講演内容でした。情報を集めて整理することで満足してしまったり、メトリクスをとることに必死になってしまったりで、本当は何を示したいのか、どんな成果を伝えたいのか、そのあとどうしたいのか、ということを忘れがちになると思います。今後研究を進めていく中で、常に意識していこうと思います。

日時

2012年6月15日（金）　10:00～12:00

会場

日本科学技術連盟・東高円寺ビル 2階講堂

テーマ

「機能安全を切り口としたソフトウェア品質改善文化構築について」

講師名・所属

小谷田　一詞氏（日本自動車研究所）

司会

阪本 太志氏（東芝デジタルメディアエンジニアリング 株式会社）

アジェンダ

1. プロフィール
2. 機能安全との出会い
3. VDA conference発表と日本での活動
4. JARI activity
5. 日本の技術者に贈る言葉

アブストラクト

"ISO26262 is Japanese supplier killer!"　これが、私の機能安全に対する最初の 印象でした。
この「最初の印象」の実体を検証するためにドイツで開催されたVDA Automotive-sys conference で発表、情報を収集しました。
その結果、この「最初の印象」が誤りであり、かつ、ISO26262が「訴訟リスク低減のために説明責任を果たす事を目的としたツール」であり、さらに「我々技術者のスキル向上に役立つツール」であるとの結論に達しました。
また、欧州で機能安全活動の基本となっているのはSPICE活動であり、この活動を有効に推進するための安全文化(Safety culture)が重要であることを知りました。
日本では、たびたび手段が目的となる傾向があります。
機能安全も本来の「目的」である「QCDを遵守し訴訟リスクを低減すること」が忘れられ、「手段」であるべき「機能安全に対応すること」が「目的」となる事を危惧しています。
機能安全は我々技術者の生産活動にとって余計なことではありません。
積極的に取り込み、我々技術者のスキル向上のツールにしましょう。

＜講義の要約＞
◆プロフィール
30年間ソフトウェア開発技術者として従事し、その内27年間を家電メーカー、残り3年を情報系メーカーで勤務した。主な開発実績としては、電車の自動放送システム、電話の高密度音声処理装置、カーナビなど多岐にわたる。またPMO・コンサルティング業務実績としてはFULL HD（H.264）ムービー開発、プロセス改善関与活動に関しては機能安全実装済プロセス定義書開発などを経験してきた。

◆機能安全との出会い
CMM推進活動に携わっていた関係で、あるメーカーが欧州のOEMからサプライヤ選定アセスメントを受けることになりアドバイスを請われた。そこで自作のプロセス定義書を用意してプロセス改善計画等の説明を行った。その過程でISO26262の存在を知り、まずはドラフト版の規格書を手に入れて勉強を始めた。

ISO26262を最初に手に取った印象は「ISO26262 is Japanese Supplier killer」だった。
日本人にありがちな間違いとして、真面目すぎて手段が目的になってしまう点がある。ISO9000の時代にはQCD達成よりも如何に準拠するかが目的となってしまった組織は多い。その再来なのかと疑問が出てきた。
そこでISO26262が開発された理由を調査する必要性を感じ、欧州へ赴くこととした。欧州では毎年春に３つのカンファレンスを開催しており、その内の VDA（ドイツ自動車工業界）が主催する VDA Automotive SYS Conference では予稿の応募が受理されたため、機能安全の啓蒙活動も兼ねて自社のプロセス改善活動の紹介を行うこととなった。

◆VDA conference発表と日本での活動
VDAカンファレンスでは開発した機能安全を実装したソフトウェアプロセス定義書および機能安全活動の紹介を行った。小谷田氏が作成したプロセス定義書は1タスク1アウトプットなど開発者の視点で作成しており、Automotive SPICEのベースプラクティスを基に考えられている他の発表者からは大きな興味を持たれた。

ISOの成立ちを考える上で、日本と欧州における文化の違いを理解する必要がある。欧州は大陸と陸続きであり、他国からの侵略に備える必要が昔からあった。その備えが規格であり、対して日本は海に囲まれているおかげで侵略への備えを欧州ほど意識する必要がなかった。
また欧州においてはISO標準化委員会で決めたことを現場でパイロットプロジェクトとして展開し、そのフィードバックを返す協力関係が長年続いている。現場では機能安全文化が醸成され、プロセス改善の文化が定着しているため、アセスメントにも抵抗がない。
日本は規格を展開するだけでは上手く行かない、どう取り入れるか計画を立てて活動を進めて欲しい。

欧州に調査へ赴いたことで、ISO26262は「Japanese Supplier killer」でない事が分かった。ISO26262に対応するメリットとしては、国際標準に従った品質確保の活動による訴訟リスクの低減、またISO26262対応の部品を使用することによる自動車保険料の軽減などが挙げられる。今後欧州に商品を販売する際に必要な規格となるだろう。

ドイツではVDA指導の基に業界が動いている。また「ISO26262を実施する第一ステップは、SPICE活動である。」と明言し、業界をあげてプロセス改善活動を基礎とした活動が根付き、「Safety Culture」が形成されている。

日本に戻ってからは機能安全に関する講演を実施し、各社の要望や悩みを収集した。そこで出てきた悩みとしては、機能安全活動に対する認識不足や機能安全の前にSPICE活動が根付いて無いことなどが挙げられる。

機能安全への取組みにおける課題は2つある。1つは「Safety Culture」に対する虚弱性で、過去の商品開発実績に対する自負や個人レベルの頑張りに支えられた開発形態から、会社組織活動としての品質（QCD）改善文化が重要になってくる。もう1つは機能安全教育に対する脆弱性で、欧州コンサルタントの英語講義における非効率な通訳や教育コンテンツの不足などが挙げられる。

そこで日本の自動車業界の用語を使用したSPICE活動の考えを盛り込んだ教育コンテンツを開発するため、JARI（日本自動車研究所）に転職することとした。

◆JARI activity
ISO26262に関して、JARIでは日本のOEMとサプライヤが集まって共同研究する場を作った。またJAMA（日本自動車工業会）など他の団体とも連携をとり、All Japanでの研究活動を行っている。現場にとってすぐに役立つ教育コンテンツを作っていきたい。

日本でISO26262に準拠する際の問題点について欧州の関係者に相談すると、日本は元々高品質の製品を開発しているのだから別に対応しなくてもよいのではないか、自分で工夫して新しく規格を作ればよいのではないかと返事が来た。だがISO26262を利用しない手はない、ISO26262に日本の文化を取り入れていきたい。

◆日本の技術者に贈る言葉
私が関与したプロジェクトは一つも失敗していない、その理由は成功するようにプロセスを設計して管理しているからである。また計画を立てることもプロジェクトの成功にとって重要である。

なぜ計画を立てるのか、その理由は3つある。
1番目はプロジェクトに要求されたQCDを守るためである。計画したQCDが全て守られたら成功であり、その為にはQCDを明確にする必要がある。もし達成不可能な要求なら、その根拠を明示して判断を仰ぐべきである。

2番目は次回のプロジェクト開発の計画策定を精度良くするためである。常に次の機会を考え、規模、工数、コスト、品質を計画時に見積もり、実績値との差異を分析する。見積もりの際は過去の類似プロジェクトを参考にすると良い。

3番目はソフトウェアプロジェクトの進捗管理に使用するためである。計画があることで実績と比較してずれを直ぐに認識することが出来る。またずれを認識するには数値で比較可能にする工夫が必要である。そのずれをどう埋めるかは進捗会議で決定する。

◆質疑応答
Q：国外で決められた規格を国内で導入しようとすると、やらされ感や準拠すること自体が目的になってしまうなどの弊害も出てくる。いっそ日本独自の規格を作った方が現場に合ったものが出来ないか？

A：日本と欧州とでは文化が異なり、日本では規格作成に向けて音頭を取る人が出てこない。それよりも既存の規格に対する日本の影響力を増加する方向に働きかけてみてらどうか。ISO26262も改訂中で、そこに日本の知恵を取り入れていく方が良いのではないか。

◆感想
小谷田氏の講演中に何度も出てきた言葉に「根拠」と「プロセス設計」があります。規格の根拠を明らかにするため欧州へ渡り歴史を遡った話や、プロジェクトが成功するようにプロセス設計していった結果、関わったプロジェクトは一つも失敗させなかった話などから、技術者としてのスキルの高さと日本の産業界全体のことを考えているスケールの大きさに感銘を受けました。まずは自社のプロセスについて、実績と比較できるように計画とプロセス定義を行っていきたいと思います。

日時

2012年7月19日（木）　13:30～16:00

会場

箱根ホテル小涌園　蓬莱

テーマ

「チームビルディングの実践と理論　～組織とコミュニケーションのモデリング～」

講師名・所属

栗田　太郎氏（フェリカネットワークス株式会社）
林　眞弓氏（有限会社デバッグ工学研究所）
増田　礼子氏（フェリカネットワークス株式会社）

司会

演習コースII 形式手法と仕様記述 主査　栗田　太郎氏（フェリカネットワークス株式会社）

アジェンダ

1. [簡単な解説]　「モデル」とは
2. [簡単な解説]　チームビルディングとその必要性
3. [ワークショップ]　手はじめ・手ならい
4. [ワークショップ]　自己のモデリングと紹介
5. [簡単な解説]　シリアスプレイとは
6. [ワークショップ]　チームでのモデリング
7. [簡単な解説]　コンストラクショニズムとシリアスゲーム
8. [簡単な解説]　チームビルディングとコミュニケーション

アブストラクト

モデリングやコミュニケーション、チームビルディングに関する基本的なことがらを確認したあと、個人やチームでブロックを用いたモデリングを行いながら対話をしていくことで、自己紹介やチームビルディングを試行し、研究会におけるチームの形成と、ひとりではできないソフトウェアの品質確保に向けたコミュニケーションの重要性の再確認を行う。 

＜講義の要約＞
◆「モデル」とは
「ファッションモデル」「プラモデル」「統計モデル」「モデル駆動工学」というように、日常の様々な場面で「モデル」という言葉が使われる。辞書で「モデル」という用語を調べると、模範、模型、見本、形式、といった意味を持つことがわかる。
コンピュータ用語は、英単語本来の意味から比喩的に使われているものが多い。例えばCPU等に用いられる「アドレス」という用語は本来「住所」という意味だが、そこから「番地」というイメージを彷彿させることから、「番地」に相当するものに対し「アドレス」と呼んでいる。

◆チームビルディングとその必要性
チームビルディングは以下の特色を持つ。
・ チームを形成するために行う
・ コミュニケーションを図り、相互に理解し、信頼を増すことを目的とする。
・ 具体的な議論、問題解決の実習、ゲーム、チームが直面している課題の対応案を練る、などといったことを行う。
・ 新しいアイディアやプランを考える場合と、メンバー同士の親睦を図る場合がある。
・ 1日か2日、日常の職場環境から離れて、セミナー形式で、日々の業務とは異なる活動を行うと効果的。
・ 専門技術であることと、客観性を持たせる点で、社外の方にファシリテーションをお願いするのが一般的である。
チームビルディングの必要性は、ソフトウェア開発は一人ではできないから、というところにある。チームで様々な情報を寄せあい、深く考え決めることで、プロジェクトは、より良くなる。
今回のワークショップは、チームでの活動の練習である。「チームで楽しみ、議論し、アイディアを出し、実現する」ということについて考え、試行する。

◆[ワークショップ]手はじめ・手ならい／自己のモデリングと紹介
ワークショップの前に、コンストラクショニズムの解説が行われた。
コンストラクショニズム(構築主義)とは、MITのシーモア・パパート教授の提唱する、「人は、ものを使って考える、あるいは手を動かして考えるときに、多くの大人がかつて子供だった頃に持っていたのに用いることを忘れてしまった創造的な力、思考、ものの見方が引き出される」という考えである。

ワークショップはブロックを用いて行われた。まず個人演習から始まった。
最初に「手はじめ・手ならい」として、任意の40個のブロックを所定のブロックの上に積んだり、未来の乗り物を25個のブロックで作ったりすることで、まず手を動かし、手を動かしながら考えることを試行した。
次に、「信頼」を示す色のブロックを選びその理由をチームのメンバーに語り、更に「品質に対する追究の態度・姿勢を示すアバター」を作成し、自己のモデリングをチームのメンバーに紹介するという演習を行った。

◆ シリアスプレイとは
個人演習の次はチーム演習についての事前説明を受けた。
この演習はシリアスプレイ(遊びやゲームを真面目に取り組むこと)のひとつで、大人の深刻な関心ごとに対して、遊びを通して想像力や活力、インスピレーションを喚起し、比喩的なイメージの三次元モデルの作成を行うものである。
コンセプトの一端として、以下の事項が挙げられる。
・ 個人やチームの内観を(内省も)表す。
・ まず手を動かしてみる。ものを使って考える。手を動かして考える
・ 論理から(だけ)入らない。
・ 三次元で表現。いろいろな角度から見ることができる。
・ 常識的な立場にとらわれない。
・ 具体や抽象のモデリング
(形あるものの表現／形がないものの表現／形があるものとないものをつなぐ)。
・ 作品・問題 vs. 私たち
(「あなた vs. 私で議論」ではなく「問題に対して私達が取り組む」)。

◆ [ワークショップ]チームでのモデリング
続いてグループワークを行った。
「ソフトウェア品質を追究していく理想の研究会、職場」をコンセプトに、個人演習で作成したアバターを登場させ、チームメンバー全員でひとつの作品を作り上げた。
30分で作成させた後、各チームの作品を観賞しあった。

◆ コンストラクショニズムとシリアスゲーム
シーモア・パパート教授は、子供たちの数学の授業が、美術の授業と同じくらい創造的であるにもかかわらず、数学を学ぶ文化が身近にないことに問題を感じ、コンストラクショニズムを考え始めた。1968年より、子供向けプログラミング言語LOGOを開発し、1980年代にはLEGO LOGOプロジェクトに発展した。
コンストラクショニズムの反対語がインストラクショニズムであり、どちらも重要である。
現在の職場において、チームで知識を構成していくにはどうしたら良いか？自分たちの仕事は美術の時間(コンストラクショニズム)なのか数学の時間(インストラクショニズム)なのか？プログラミングは楽しく(知的に刺激的で)創造的な行為か？を考えてみるとよい。

◆チームビルディングとコミュニケーション
チームビルディングは、仕事から離れて、しかし仕事の時間に行うこと。また、関係者全員が集まることが必要。ファシリテーションは社外の方にお願いするのが一般的だが、自分たちでも主催はできる。
仕事が困難になる前に行うべきだが、後からでも手遅れではない。また、組織や人の動機づけの低下や新陳代謝に合わせて繰り返し行うことが重要である。
職場でやってみたらどうなるか？是非やってみてほしい。
今回のワークショップは親睦を図ることを目的としたが、この後、プロジェクトの課題に対する議論、技術的なコミュニケーションに関する議論、コミュニケーションや議論に関する議論など、「チームが直面している課題に関する議論」を行なっていく。
「あなた vs. 私」から「問題 vs. 私達」へ 、"I think"から"We think"へ変えていく。
ソフトウェアの品質確保や研究の追究は一人ではできない。チームで技術的で建設的な議論や、皆がしあわせになる研究会や職場を作ろう。また、見えないソフトウェアをモデル化して、チームで考えていくということを志向しよう。
利用者や利害関係者と円滑な、さまざまな形態のコミュニケーションを図ろう。
まずは挨拶と自己紹介からはじめ、やってみる。そして継続していくこと。最初は小さな一歩でもいい。

＜講義の感想＞
昨年度の合宿もチームビルディングの演習でしたが、今回は演習目的が異なり、また新鮮な気持ちで取り組めました。
モデルを作成することで自分の考えやイメージを伝えやすくすることができること、しかしモデルだけですべてを伝えることはできないこと、手を動かすことでイメージが促進されること、チームで納得しあうこと、協力しあうこと、一緒につくりあげることの素晴らしさを実感できました。この先一緒に研究をしていく仲間とこのような体験ができたことで、お互いをより理解し、今後の活動が行いやすくなったことと思います。
各チームの作品はどれもチームワークと楽しさを感じさせるもので、素晴らしいものでした。
今回学んだことで、職場でなにか小さなことでも行えることがあるか考え、機会を探してみようと思います。

日時

2012年10月12日（金）　10:00～12:00

会場

日本科学技術連盟・東高円寺ビル 2階講堂

テーマ

「UX（ユーザエクスペリエンス）の考え方とアプローチ」

講師名・所属

安藤 昌也氏　（千葉工業大学 工学部 デザイン科学科）

司会

金山 豊浩氏　（(株)ミツエーリンクス）

アジェンダ

・“体験”こそ製品　　　　　　　　　　　
・UXとUXD
・サービス経済から経験経済へ
・UXは本当に上手くデザインできるのか？
・様々な視点からのUX
・UXDを小手先なものにしない３つのポリシー
・実利用の評価を左右する心理的要因
・まとめ

アブストラクト

昨今、ユーザ体験を意味するユーザエクスペリエンス（ＵＸ）に関する議論が様々なところで行われています。確かに、よいユーザ体験を作りこみ、実現することは製品やサービスづくりの目標である
ことに異論がある人はいないでしょう。しかし、ＵＸの捉え方によっては、よい製品づくりにつながらない可能性もあります。また、ユーザビリティとの違いにも混乱があるかもしれません。本講演では、ＵＸ
に対する考え方を整理するとともに、具体的な製品・サービスづくりにおいて留意すべきポイントについてお話します。

＜講義の要約＞
◆前置き
UX（ユーザエクスペリエンス）はその評価方法に現時点で決定打は無く、国際的な課題となっている。本講義では評価方法の代わりにUXをどう評価するかの観点を説明していく。またUXとUXD（UXデザイン）を分けて説明する。UXはユーザ体験であり個人の話であるが、UXDは作り込みについての話になる。
UXは定義を求めるより“観点”を理解することが重要である。世界のUX研究者が集まり基本コンセプトを整理した議論の成果を「User eXperience White Paper」にまとめた。その邦訳も「UX白書」で検索出来るので目を通しておいて欲しい。

もしUXについて専門的に学びたい場合は、以下の産業技術大学院大学の履修証明プログラム「人間中心デザイン」への参加を検討して欲しい。
　http://aiit.ac.jp/certification_program/hcd/index.html

◆“体験”こそ製品
1888年イーストマン・コダックが開発したフィルムカメラは、その技術よりも体験そのものが革新的だった。それまで撮影前後に必要だった多くの作業が軽減され、誰でも手軽に撮影に集中できるようになった。

◆サービス経済から経験経済へ
ユーザのニーズはサービスから経験へと移りつつある。サービスの消費の場合、生活における不足や不満などのニーズは企業が提供する商品やサービスによって充足され、サービスの価値は企業によって与えられていた。経験の消費の場合、生活における自己創造の欲求は、企業が提供する商品やサービスを手段とした経験を通して実現され、経験の価値はユーザ自身が生み出している。

経験経済は製品購入にも大きく影響している。製品購入前の体験機会が少なかった時代は購入後に初めて製品を評価可能だったが、現代は口コミなどの擬似的な体験機会が購入判断に影響を与えている。

◆様々な視点からのUX
UXと言う言葉は様々な場面で使われているが、UXを利用期間の観点で整理すると明確になる。

・利用前：「予期的UX」（経験を想像する）→ 例：CMや口コミ
・利用中：「一時的UX」（経験する）→ 例：製品操作
・利用後：「エピソード的UX」（ある経験を内省する）→ 例：サービス
・利用時間全体：「累積的UX」（多種多様な利用期間を回想する）→ 例：ブランド

◆実利用の評価を左右する心理的要因～SEPIA法の視点
インタラクティブ製品の場合、その評価はユーザの利用意欲に左右される。また利用意欲は操作する事への積極性・自信と言った「自己効力感（SE）」と、製品ジャンルへの興味・知識と言った「製品関与（PI）」の二つで構成される。この二軸・四象限でユーザを分類し分析（A）するのがSEPIA法である。各ユーザグループで調査結果の傾向が異なってくるので、調査前のグループ分けが重要である。

(1)ミニマム利用ユーザ（製品関与：低、自己効力感：低）
製品に慣れると期待先行ユーザや冷静・合理的利用ユーザになる。

(2)期待先行ユーザ（製品関与：高、自己効力感：低）
製品に対する満足度は高いが、製品知識不足などによる不満足度も大きい。我慢していることやユーザ側で補っている課題の解消が重要である。

(3)冷静・合理的利用ユーザ（製品関与：低、自己効力感：高）
製品に対する満足度は高く、不満足度は低い。諦めていることや使いこなし方に関する課題の解消が需要である。

(4)マニアユーザ（製品関与：高、自己効力感：高）
製品のファン。熟達までに超えるべきハードルの明確化が重要である。

◆UXとUXD
UXは個人の体験であり、どんな体験をして貰うかの計画と、その体験が量産・再生産される仕組みをデザインすること（UXデザイン（UXD））が重要である。

以下はUXDの議論を始める前に押さえておくべき三つの事柄である。
(1)主観的評価
UXは個人の体験である。体験の感情的な評価をどこまで意識してデザインするかが重要である。

(2)消費者とユーザの連続性
消費者として製品を購入し、ユーザとして製品を利用する。消費体験から利用体験までをどう連続的にデザインするかが重要である。

(3)時間的・長期的視点
ユーザが意欲を持って製品を長く使い続けてもらえるよう、どうデザインするかが重要である。

◆UXは本当に上手くデザインできるのか？
エクササイズビデオを例にユーザビリティとUXDの違いを説明する。

ユーザビリティの場合は、主な目的はトレーナーと同じ動きが出来るようになることで、その為にビデオの構成は段階的に上達できる教材としての役割を持つ。

UXDの場合は、主な目的はユーザ自身が決めるので、ビデオの構成はユーザの熟達度や気分に応じて目標を決められるように踊りの上手な人やそうでない人など様々な人物を登場させたり、飽きずに続けられる様に演出を工夫したりしている。

◆UXDを小手先なものにしない３つのポリシー
(1)“体験コンセプト”を明確に定めること
銀行サービスの例なら、「いつでも確認しながらやりとりできる」を体験コンセプトとして、そこから「ATMで落ち着いて操作できる体験」→「自分の操作に誤りがないことを確認できる」→「フィードバックを○○にする」と段階的に詳細化していく。

(2)アクティビティ指向でプロダクトを発想すること
機能を先に考えるのではなく、アクティビティ（ユーザ活動）に合った機能を考える。体験コンセプトを定め、ペルソナを設定し、サービス体験シナリオを作成するなどしてコンセプトを詳細化していく。また寸劇などでユーザが実際に利用するシーンを再現してみるのも効果がある。

(3)ビジュアル・モーション指向でUIを発想すること
文章表現より漫画形式などのビジュアル表現がUXDに合っている。また操作についてはモーションでの因果関係や操作を検討する。一度でも使えば分かる操作方法や、各情報へのリンクが分かりやすい構造などを設計することが重要である。

◆まとめ
「使いやすいシステム」から「ありがたいシステム」を設計することで継続的にシステムが利用されるようになる。
UXは過去に企業がユーザのために提供していたモノを改めて明確にしている活動であり、何か特別なものではない。UXと言う名前に惑わされないで取り組んで欲しい。

◆質疑応答
Q：車の安全装置など人命に関わる製品には、UXよりも安全性が優先されるのではないか？

A：まずその質問が出て来た背景を考えてみて欲しい。ユーザが「安全体験」を求めているか調査したことがあるだろうか？ 先進運転支援システムの「EyeSight」は安全を可視化することで人気が出た。ユーザは安全を求めている。安全が可視化されていないことが潜在的なニーズで、求められている安全をどう経験させるか、そのデザインが求められている。

◆感想
ユーザの視点から体験をデザインする、最初は奇妙に聞こえた話でしたが講義が終わる頃にはすっきりと納得できました。まずは身の回りの製品をUXの観点でどうデザインされているのか考察した上で、自分の仕事にも反映していきたいと思います。

日時

2012年11月16日（金）　10:00～12:00

会場

日本科学技術連盟・東高円寺ビル 2階講堂

テーマ

「アジャイル開発における品質向上の取り組み－フレームワーク、プロセス、型－」

講師名・所属

細谷　泰夫氏（三菱電機株式会社）

司会

SQiP研究会運営委員長　秋山 浩一氏（富士ゼロックス株式会社）

アジェンダ

1.アジャイル開発とは？
2.スクラムの概要
3.型、プロセスの例
4.アジャイルテストをプロセス、型という観点で考える
5.ドキュメンテーション
6.まとめ

アブストラクト

ここ数年、ソフトウェア開発においてアジャイル開発が採用される事例が増加しています。
一方で、初めてアジャイル開発に取り組もうとする組織では、アジャイル開発の中で、どのような品質向上活動をしていけば良いか？ 今まで行っていた活動と同等の品質を確保できるのか？ という疑問を感じているかもしれません。
本講義では、アジャイル開発の中での品質向上の取り組みについて、紹介するとともに、皆さんのそれぞれの組織でアジャイル開発に取り組む際に、どのような品質向上活動をしていけば良いかを考えるためのポイントを解説します。

＜講義の要約＞
冒頭で、聴講者が3～4名のグループを形成し、「アジャイルと品質について知りたいこと」を共有し、中でも最も知りたいことを一つ付箋紙に記載した。その後、黒板を「タスクかんばん」にして、左側を「ToDo」右側を「Done」とし、左側(ToDo)に付箋紙を貼っていった。

◆アジャイル開発とは？
アジャイル開発には広い意味があり、定義できない。また、人により重視する点が異なる。
共通点を見出そうとすると、アジャイルマニフェスト(http://agilemanifesto.org/iso/ja/)に同意していたらアジャイルではないか。という結論に達する。

◆スクラムの概要
アジャイルのやりかたの解説を行うにあたり、ある程度全員で共通意識をもつために、今回はスクラムに絞り込む。
スクラムには、「3つの原則」「4つのミーティング」「3つのロール」「3つのアーティファクト」がある。
スクラムの3つの原則は、「透明性」「検査」「適応」である。アジャイルは透明性を重要視する。悪い報告も包み隠さない。また、アジャイルはメトリクスと相性が悪いと誤解されているが、そのようなことはなく、メトリクスを重視し、常に計測をして振り返る。
スプリント(イテレーション)単位で行われる、スクラムを駆動する4つのミーティングが、「スプリント計画ミーティング」「デイリースクラム」「スプリントレビュー」「ふりかえり」である。
3つのロールは、スクラムプロセスがうまくいくように外部からチームを守る「スクラムマスタ」、製品に対して責任を持ち機能に優先順位を付ける「プロダクトオーナー」、プロダクトの開発を行う「チーム」である。チームは、製品の成功に向けて最大限の努力をコミットする。
3つのアーティファクトは「プロダクトバックログ」「スプリントバックログ」「バーンダウンチャート」である。プロダクトバックログは、「今見えている最終的な製品に必要な要求」をストーリー形式で記載しリスト化したものであり、リストには決して重複しない優先順位が付けられる。順位決定はプロダクトオーナーに課せられる。スプリントバックログはスプリント期間中に行うタスクのリストで、このタスクは一つひとつ順番に行われる。バーンダウンチャートはスプリントタスクの進捗を示すチャートであり、「推定残り時間」を更新してグラフにプロットする。

プロダクトの品質が悪くなる原因の一つとして、階層式の組織とオーバーコミット(スコープに対しコストや期間がアンバランスな状態でのコミット)が組み合わさった時がある。
問題は開発の上流から下流に流れやすく、スコープに対するコストや期間の矛盾が実行部隊に降りてくる。上を見直すには逆流となり、時間がかかりやすく精神的に消耗する。オーバーコミットに対して問題を下から上にあげて、それが軽減されるまで現場は「突貫工事」になる。突貫工事ではプロダクトが汚くなる。一回汚くなったものを綺麗にするのは難しい。
スクラムには、オーバーコミットを発生させないための3つのルールがある。
・プロダクトオーナーは、プロダクトバックログの優先順位を付けることができる
・チームのみがプロダクトバックログ項目を見積もることができる
・スクラムマスタはスクラムのルールを壊す存在を排除する権限を持つ
ルールに対しルール違反として、「プロダクトオーナーや組織がチームの見積りを否定する」「スプリントの期間を延長する」「チームが情報を隠す」の3つがある。

スプリントのスコープを器に例えると、器の大きさが見積りとなる。見積りは、ほとんど自動的に決まるのが理想である。器に対して「優先順位の高いストーリーから入れていく」「いつまでたっても終わらないと言って器を大きくしない(オーバーコミットをしない)」「見積りどおりチームが淡々とつくる」ほうがトータルとして効率がよいという考え方があり、それを破ることを徹底的に排除する。
「プロジェクト初期には誤差が大きくプロジェクトが進むにつれて誤差が減る」という見積りの性質を示す不確実性コーンは、アジャイルでも無くなるわけではない。最初のスプリントでは誤差がひどいが、徐々に誤差が減る。
スクラムでしばしば採用されている見積りのやり方に「プランニングポーカー」がある。これはストーリーの規模を相対的に見積るものである。一つのストーリーに対して即決あるいは数分で決める。

フレームワーク、プロセス、型について、サッカーを例に解説すると、「ルールに従って行う」ことがフレームワークの部分であり、よいゲームをするにはプロセスや型が必要である。型は「ヘディングがちゃんとできるか」というような基本動作を示す。ソフトウェアで言えば「コーディング規約に基づいてプログラムができるか」「同値分割を適切に行えるか」といったものである。プロセスや型はチームメンバーのスキルによって変わってくる。

◆型、プロセスの例
SQiPシンポジウム2012の経験発表「アジャイルプラクティスを活用したチームとしての品質確保の取り組み 」をもとに、事例を紹介された。
経験の少ないメンバーを教育しながら品質を確保するという取り組みで、要求分析や方式設計については経験知が必要だが、経験者だけで行ってしまうと伝承にならない。そのような作業はチームで行う。実装は適切なプロセス支援を与えてペア作業をさせ、レビューを行う。ペアプログラミングの際にナビゲーションするためのマップとして、予め原因結果グラフを作成した。その結果、欠陥が少なく出来上がり、教育もできた。このように、チームや事情によってやり方を考えていくことが大事である。

◆アジャイルテストをプロセス、型という観点で考える
アジャイルテストの四象限(テストを四象限に分けた上でそれぞれのテストをどのように実行するかを表したもの)と、自動化の費用対効果を示すテスト自動化ピラミッドを紹介された。
四象限やピラミッドはプロセスや型そのものではない。指針であり、指針をもとに自分たちでプロセスや型(何に対して、どんなことを、どんな方法でテストするか)を考えていく。

◆ドキュメンテーション
ドキュメントは型(基本動作)やプロセス(フォーメーション)と密接な関係があるため、ドキュメンテーションとの付き合い方を知っておくことが重要である。そのためには、誰のためのドキュメントか？ を考える必要がある。また、ドキュメンテーションは、相手と何かを共有することが目的であるため、ドキュメンテーションだけでなくFace to Face のコミュニケーションと組み合わせる必要がある。
無駄なドキュメントを書かず、最低限にするためには、どの情報を、誰が、いつ必要なのかを考える。実装のための情報であれば、チームでの共有からソフトウェアとして実現できるための時間の長さが鍵になる。例えば「話し合って3日で実装」ならドキュメンテーションがなくても作ることができる。合意形成のための情報であれば、契約、投資価値判断など目的に対する必要性により作成するかどうかを判断する。保守のための情報であれば、使う時点で最新の情報が必要なため、今作成する必要はない。
通常の開発では、徐々に論理性が高まることが多く、要求分析の段階では、本質的に論理性のギャップが存在する。アジャイルは1つのユーザーストーリーを数日単位で実装することを繰り返す仕組みで、最初から論理性を高めている。そうでなければドキュメンテーションをすることで論理性を高める必要がある。重要なのは何を共有するかであり、迷いなく作れるようになるまでチームで共有する。

◆まとめ
型とプロジェクトの習熟について話した。
スクラムマスタは審判員であり、レフリングされたゲームをつくる存在である。レフリングされた中でよいゲームをするには、実践しながら練習を繰り返し行う必要がある。そして頭ではなく、体に型をなじませる。千本ノックのような基本動作の反復練習を習慣化させる。自分たちのプロジェクトに合わせて考えて実演する。
特にアジャイルプロセスの場合は明確にこだわっているが、ウォーターフォールにも共通して大事なことと言える。自分達のプロセスや型を考える必要がある。

最後に講演の振り返りとして、「ToDo」に貼った付箋の中で「すっきりとはいかなくても何かしら得るものがあった」事項について、付箋を書いたグループに問いかけながら軽くまとめ、「Done」に移していった。

＜講義の感想＞
講演の中に「タスクかんばん」を取り入れ、全体的にわかりやすく講演されていたことで、とても楽しめました。内容はスクラムやアジャイルに限定したものではなく、どのやり方であっても共通のことで、開発を行なっていく上で意識していく必要性を強く感じました。また、オーバーコミットの対応や教育を取り入れるときのヒントなど、非常に興味深いことを学ぶことができました。

日時

2012年12月21日（金）　10:00～12:00

会場

日本科学技術連盟・東高円寺ビル 2階講堂

テーマ

「構造化知識の活用による設計不具合の予測と未然防止」

講師名・所属

田村　泰彦氏（株式会社構造化知識研究所）
野々村　望氏（レシップ株式会社）

司会

阪本 太志氏（東芝デジタルメディアエンジニアリング(株)）

アジェンダ

1.不具合に関する設計知識の問題点と構造化の狙い
2.不具合に関する構造化知識の獲得方法
3.不具合に関する構造化知識の活用方法

アブストラクト

設計変更により、ある品質特性が悪化し、設計開発でそれに気づけないために不具合が発生するとい
うことを私たちはしばしば経験します。このような不具合を防ぐ活動を効果的に行うには、変更点に
関わる設計対象の機能・処理・構造上の関係知識、システムで生じる望ましくない挙動の知識が必要
です。
不具合に関する経験や一般的知見から再利用可能な知識を構造化し、構造化知識を用いて不具合の予
測と防止を行う考え方をご紹介します。また技術要素の可視化が難しいソフトウエアの各開発段階に
おける不具合予測の考え方やそのための知識のあり方について、ハードウエアとの比較を交えて皆様
と議論させて頂きたいと思います。

＜講義の要約＞
◆本日の特別講義で説明する3つの話題
その1：不具合に関する設計知識の問題点と構造化の狙い
その2：不具合に関する構造化知識の獲得方法
その3：不具合に関する構造化知識の活用方法

■その1：不具合に関する設計知識の問題点と構造化の狙い
知識構造化シンポジウムでのアンケート結果によると、ほぼ全ての組織が不具合に関する記録を行っているが、その記録を再発防止活動に活かしている組織は多くない実態が明らかになった。

不具合に関する記録を、今後の未然防止や再発防止の活動に再利用するためには、不具合情報をどう活かすかという観点で記録しないと情報共有や知識伝承が上手くいかず、以下の問題が発生する。
・不具合情報の記述が不十分で設計に利用しにくい
・不具合の情報が抽象化されず、再利用しにくい
・不具合情報が散在していて体系的に引き出せない
・不具合情報が膨大で必要な情報を検索できない

不具合に関する知識の構造化とその運用の狙いは以下である。
・知識のモジュール化や一般化による再利用性の向上
・解析ニーズに応じた、設計や計画時に必要な知識の検索性向上
・知識の一元化や設計情報の関連づけなどによる、不具合情報の基盤整備
・構造性の観点による、論理的な思考の質向上

■その2：不具合に関する構造化知識の獲得方法
知識の再利用性を高めるために考慮すべき性質は以下の3点である。
１， 知識の分節性
予測や未然に防止すべき因果連鎖内の各不具合事象の発生メカニズムが、将来、それぞれ設計・評価する対象とライフサイクルの単位で切り出されて、整理されていること。
例：機器全体に対する故障や製造工程上のミスなど、設計アイテムやライフサイクルなどの観点で不具合情報を区切って整理する。
 
２，知識の一般性
各不具合事象が様々な対象に水平展開されるように、その事象の発生に関わる一般的な設計属性に基づいて整理されていること。
例：あるコンデンサで不良が発生した場合、どのような種類のコンデンサに特有の不良か整理することで、同じ種類のコンデンサに対して不具合情報を活かせるようになる。
 
３，知識の関係性
将来の予測・未然防止活動に必要な不具合事象の要因間の関係や分節間のつながりを構築し、また不具合対策や詳細解析のための知識との対応を関連づけること。
例：ある部品の故障に関する知識を、製造工程や部品の素材または設計内容など、多様な知識と関連づけし検索可能にする。
 
◆構造化知識の抽出イメージ
・個々の不具合事例から、再利用の対象や望ましくない事象の発生要因などを抽出して整理する
・望ましくない事象の発生要因を更に掘り下げて、部品単位などで同様の抽出作業を行う
・抽出した知識同士は関連性が分かるように整理する

◆SSM（Stress-Strength Model:ストレス-ストレングスモデル）
SSMとは、不具合の発生原因の多くは自然科学的なメカニズムの因果連鎖による点に着目し、製品や工程に起こりうるトラブル発生メカニズムの知識を将来の設計・計画に再利用できるように構造的に表現するモデルを指す。

SSMの知識分節は以下で表現している。
・定義属性（再利用する対象）
・不具合モード（望ましくない事象発生）
・不具合モード発生要因
・ストレス（使用条件・異常入力）
・ストレングス（耐性・狙いのまずさ）
・制御属性（設計パラメータ要因）

また発生要因を新たな不具合モードとして、関連する構造化知識の抽出作業を行っていく。

◆不具合モードの発生メカニズム
構造化知識を抽出する際の、不具合モードの発生メカニズムに対する解釈パターンは以下の3通りになる。

１，相対的因果メカニズム
定義属性の対象において、制御属性要因で作り込まれるストレングス要因の大きさと、ストレス要因の大きさの相対的な関係に基づいて、不具合モードが発生する。
例：「O-RINGシール部の漏れ」
・定義属性：O-RINGシール部
・不具合モード：O-RINGシール部の漏れ
・制御属性：O-RINGの高度が小さい
・ストレス：圧力の過大な上昇
・ストレングス：O-RINGシール部の耐圧不足
 
２，絶対的因果メカニズム
定義属性の対象において、ストレス要因または設計計画要因（ストレングス／制御属性）いずれか片方のみの要因に基づいて、不具合モードが発生する。
例：「配線が板金端部に接触する」
・定義属性：配線処理
・不具合モード：配線が板金端部に接触する
・制御属性：配線引き回し箇所の指定がない
・ストレス：※不要（考慮するまでもなく、常に不具合モードが出やすい状態になっている）
・ストレングス：板金端部接触防止不足 
 
３，断片的因果メカニズム
定義属性の対象において、分かる範囲で断片的に把握されている不具合モード発生要因によって、不具合モードが発生する。
例：「データの重複登録」
・定義属性：伝票読込みソフト
・不具合モード：見かけ上同じ番号のデータが重複登録される
・制御属性：※省略（情報不足）
・ストレス：番号の前後に空白文字や改行文字が含まれる
・ストレングス：※省略（情報不足）
・設計要因：番号の前後に対するトリム処理漏れ
 
◆不具合の因果連鎖の知識構造
ある知識分節のストレス、ストレングス、制御属性の内容を新しい分節における不具合モードとして表現し、不具合の因果連鎖の知識構造を構築する。

例：リレーの接点障害
・知識分節(1)
・不具合モード：電気接点の導通不良
・ストレス要因：電気接点上に絶縁被膜（酸化シリコン）が形成される

・知識分節(2)（知識分節(1)のストレス要因を不具合モードとして表現）
・ストレス要因：電気接点付近に低分子シロキサンが発生する

・知識分節(3)（知識分節(2)のストレス要因を不具合モードとして表現）
・ストレス要因：（電気接点開閉時の放電繰り返しにより）環境温度が高いとシリコーン材から低分子量のシロキサンが揮発する
 
◆ソフトウェアSSMの基本構造
SSMの考え方をソフトウェアに適用した場合の基本構造を2点紹介する。
１，ソフトウェア動作の技術知識
要求分析・設計・コーディング・テスト等に反映できる技術的な設計教訓を抽出する。
・定義属性（設計対象）：ソフトウェアの機能やデータ構造など
・不具合モード：各種不具合現象
・ストレス要因：環境条件やユーザの操作条件など
・設計要因：仕様の問題点プログラムのバグなど
 
２，開発プロセス業務上の知識
設計開発の進め方の教訓を抽出する。
・定義属性（開発業務内容）：要求仕様分析や設計仕様書作成など
・不具合モード（業務上エラー）：フォールトを作り込む業務上のエラー
・業務上制約要因：ユーザ要求仕様変更や納期変更など
・業務対応要因：設計業務やプロセス管理上の問題点など

■その3：不具合に関する構造化知識の活用方法
ソフトウェア開発での活用事例として、既存のクレーム情報をSSMのフォーマットへ移行した事例の紹介があった。移行する際は定義属性をキーワードリストから選択可能にして利便性を向上させたり、設計要因には開発担当者が「その時の設計のまずさ」を記載したり、担当者独自の切り口で検索を絞れるようにするなどの工夫を取り入れた。また抽出した知識は再発防止リストとして各工程でのチェックに利用した。

※その他、活用ツールとしてSSM master を紹介していた。
http://www.ssm.co.jp/software/index01.html

◆QA
質問1：ExcelやAccessなどでSSMのデータ管理は可能か？
回答1：可能、検索マクロ等を作成したこともある。ただしデータが増えてくると、専用ツールでなければ管理が大変になってくる。

質問2：知識構造化の具体例についての情報は何処を調べればよいか？
回答2：知識構造化シンポジウムに参加すると、具体例についての発表を聞くことができる。

質問3：ある項目の内容を記述する必要がない場合でも、不要な理由を書いておかないと後日問題にならないか？
回答3：連携している他の分節を参照すれば、不要な理由が分かる構造になっている。

質問4：DBの作成は誰がどのタイミングで行うのが適切か？
回答4：品質保証部でDBを作成する場合でも、設計者も巻き込んで作成しないと使えるDBにならない。専任でDBを作成することは難しいので、目的を理解してもらい手分けして作成することが重要。部署毎のDB作成率を競った事もある。

◆感想
不具合情報を集めただけでは活用は難しい理由がよく分かりました。話を伺うと現場毎にDBに記録する項目数や内容を工夫しているそうなので、どのように活用するかを関係者で集まって方針を決めた上で、方針にあった不具合情報の収集と整理を行うことが重要なのだと感じました。

日時

2013年1月18日（金）　10:00～12:00

会場

日本科学技術連盟・東高円寺ビル 2階講堂

テーマ

「ITアーキテクチャ設計とITアーキテクトの着眼点」

講師名・所属

榊原　彰氏（日本アイ・ビー・エム株式会社）

司会

SQiP研究会第3分科会主査　細川 宣啓氏（日本アイ・ビー・エム株式会社）

アジェンダ

1. アーキテクト、アーキテクチャそしてアーキテクティング
2. ITアーキテクチャの構築
3. ITソリューションの構築手法決定
4. ITソリューションの最適化
5. ビジネス戦略・課題の領域からIT 領域まで
6. ニュー・パラダイムへの挑戦

アブストラクト

本講義ではITアーキテクチャ設計の基本からはじめ、アーキテクトの思考法、使い
こなすべきテクニックを解説する。また、ITアーキテクチャ設計がより効力を発揮
するために、ITの視点のみならずビジネス的な観点からの最適化、講演者が現在取
り組んでいるスマーター・シティ施策におけるアーキテクチャ設計の位置づけまで
を論ずる。 

＜講義の要約＞
◆アーキテクト、アーキテクチャそしてアーキテクティング
アーキテクチャとは、「コンポーネントを統合したシステムの基本的な編成、コンポーネント相互およびコンポーネントと環境間の関係、そしてシステム設計と進化を導く原則(IEEE Std.1471-2000)」である。つまり、全体をどう切り分け、分けたものをどう関係付けるか、という「分け方とつなぎ方」である。
ソフトウェアやシステムで一般的に言われることであるが、アーキテクチャは目に見えないため、アーキテクチャ記述を書くことで目に見えるようにする。アーキテクチャ記述を読みやすくし、物事を明確に共有するために、モデル(共通のルールで表現されたもの)を用いる。
アーキテクトとは、アーキテクティング(アーキテクチャを構築する活動)を実践し、アーキテクチャを構築するプロフェッショナルを指す。
大規模なプロジェクトでは、アプリアーキテクト、インフラアーキテクト、データアーキテクトといった複数のアーキテクトがそれぞれアーキテクチャの意思決定を行う。そしてプロジェクト全体においてアーキテクチャの調整を行うのがリードアーキテクトである。リードアーキテクトはプロジェクトが終わった後もシステムがそのライフサイクルを通じてきちんと動くことに対する責任を持つ。プロジェクトマネージャとシステムに関わるタイムスパンが異なるのである。
ソリューション・アーキテクチャとは個々のアーキテクチャの集合であり、ビジネス・アーキテクチャ、アプリケーション・アーキテクチャ、配置(データサービス/アプリケーション)、インフラストラクチャ・アーキテクチャ等が含まれる。また例えば企業社内において複数のソリューション・アーキテクチャがつながりを持つ様に全社的にまとめたものがエンタープライズ・アーキテクチャである。
ステークホルダーとは、「システムに関して興味または関心事を有する個人、チーム、組織(IEEE Std.1471-2000)」である。アーキテクトがアーキテクチャ記述する事でステークホルダーの関心事を根拠付ける事が出来る。関心事を細かく分けるとビューポイント(特定の視点)になる。ビューポイントをもとにビューを作成する。
変更の難しいアーキテクチャに関しては開発の初期段階で意思決定を行う必要がある。しかし最初の時点では実際のシステムは存在せず、少ない情報の中でアーキテクチャ上の意思決定を行わなくてはならない。そのために過去の情報収集やパイロットプロジェクトでの検証が必要となる。また、決められたチェックポイントで再評価を行い、いかに段階的・継続的にリスクを減らしていくかを考える。

ITアーキテクトが押さえるべき4つのアプローチは以下である。
・ ITアーキテクチャの構築
・ ITソリューションの構築手法決定
・ ITソリューションの最適化
・ ビジネス戦略・課題の領域からIT領域まで

◆ITアーキテクチャの構築
ステークホルダーに対し対象システムの本質を表現し理解させるためには、複数の適切な視点(ビューに基づく表現)が必要となる。
ビューとは、「関連する一組の関心事の視点からシステム全体を表現したもの(IEEE Std.1471-2000)」であり、ビューポイントとは「ビューを作成し、使用するための約束事の詳細仕様(IEEE Std.1471-2000)」である。また、ビューポイントとは「ビューの目的や利用者を明確にして、それぞれのビューを作成するためのパターンもしくはテンプレートであり、それらを作成し分析するためのテクニック(IEEE Std.1471-2000)」である。
一般的にビューに基づいてダイアグラムが描かれる。しかしこのダイアグラムそのものがモデルではなく、ダイアグラムで表されるものがモデルである。複数のダイアグラムで一つのモデルを表すことも、一つのダイアグラムが複数のモデルを表すこともある。
ビューポイントには要求ビューポイント、機能ビューポイントといった、独立した基本ビューポイントと、セキュリティービューポイント、パフォーマンスビューポイントといった、基本ビューポイント全体に対する横断的ビューポイント(パースペクティブ)がある。基本ビューポイントと横断的ビューポイントの組み合わせにより必要な成果物を決めて作成に取り掛かる。
アーキテクチャの構築対象となるシステムの特徴により、作業時に重点をおくところは異なる。従ってアーキテクチャ記述で重要なのは、メリハリをつけたアプローチである。具体的には、既知のベストプラクティスの適用や未経験の領域への挑戦、先進技術の適用などには重点を置く必要がある。例えば新しい技術を取り入れるならばどこでリスクを解消するか、ということも記述する。また、採用した技術についてその選択根拠を記載することもある。

アーキテクチャは多様な側面から設計する必要がある。例えば家を建てるための設計図は平面図や外観図など複数必要になる。システムも同じである。全体をいかに「切り分け」て、いかに「組み合わせ」るかが重要となる。また切り分けることで各アーキテクトに設計を割り振ることが出来る。アプリケーションアーキテクトは機能モデル、インフラアーキテクトは配置モデル、データアーキテクトはデータモデルを成果物(ワークプロダクト)として作成する責任を持つ。これらのモデルをまとめ、リードアーキテクトは成果物としてアーキテクチャ評価、アーキテクチャ上の判断、アーキテクチャ概要、アーキテクチャ構想実証、ソフトウェアアーキテクチャ文書などを作成する。

アーキテクチャの機能的側面を表現するときにはコンポーネントをベースとして考えると良い。コンポーネント設計においては、いくつかの重要な設計原則があり、Open-Closed Principle(「(モジュールは)拡張に関してして開いており、修正に関して閉じていなければならない」というBertrand Meyer氏が提唱した原理)や、GRASP( General Responsibility Assignment Software Patterns:汎用責務割り当てパターン(5つの基本パターンと4つの応用パターンを定義している))などが挙げられる。

ITアーキテクチャ設計の手順としては、まず概念モデルから設計し、詳細モデルへ、そして物理モデルへと落としこんでいく。それぞれ機能的側面と稼働的側面があり、両者に対しNFR(非機能要求)の考慮が必要になる。
アーキテクチャ設計プロセスはフェーズに分け、フェーズごとにタスクがあり、アクティビティを行う際は常にタスクを参照する。タスクはロールにより実行され、ロールは成果物の作成を行い、成果物に対し責任を負う。各タスクでの記述内容としては、目的、ロール(主担当と副担当)、入力、出力、ステップ(具体的に行う事)、アーキテクトのロール(詳細な役割)等が挙げられる。
アクティビティには要件定義アクティビティとアーキテクチャ作成アクティビティ等がある。

例えば、予約システムを対象として具体的に各アクティビティを説明すると以下の様になる。
・ ビジネスエンティティ・モデルを用いてビジネスプロセス・モデルを描き、ビジネスルールを明らかにする
・ システムコンテキスト図を描き、利用者と対象システムが繋がる外部システムを明らかにする
・ ユースケース図を描いたうえでユースケース記述を行い、機能要求と非機能要求を書き出していく
・ アーキテクチャ概要図とアーキテクチャ上の意思決定(課題に対する候補と選択された案および案を正当とする理由)の記述を行う
・ BCE分析(Boundary(境界)Control(制御)Entity(エンティティ)で責務を識別)でラフにコンポーネントを導出する
・ コンポーネントをアーキテクチャ・パターンへマッピングする

アーキテクチャ構成の基本原則として以下の4つの事項が挙げられる。
・ 機能要求のモデル化(コンポーネントベースでの分析・設計)
・ テクノロジー・セレクションのためのモデル化(インフラ設計の抽象化)
・ コンポーネントをどのようにノードに配置するか(配置実装)
・ 関心事の分離(Separation of Concerns)

アーキテクチャの稼働インフラ側面を表現する際に、インフラ設計の抽象化を行う。プロキシやサーバ、クライアント等はノードと呼ばれる。ノードはロケーション(本社、視点、データセンターといったものが含まれる)に配置される。ロケーションにはゾーニング(内部ネットワーク、外部ネットワークなどといったゾーン分け)がある。ノード間にはコネクション(二重化させる、迂回させる、などのつなぎ方)がある。
ノードに対して、機能的責務をもたせる。その後、ノード間をつなぐためにシステム上必要なテクニカルノード(ファイアーウォールやルータ等)が必要になる。テクニカルノードは詳細化する時点で追加すればよい。

このような稼働インフラ・アーキテクチャを表現するモデルとして、オペレーショナル・モデルがある。オペレーショナル・モデルとは、システムのユーザーや関連する外部システムとシステムの構成要素及びその配置や相互の関係を表現した、新システムの全体像を示すものである。
オペレーショナル・モデルには、静的な関係(システムの構成要素の配置)を示すノード構成図と、動的な関係(システムの構成要素間の協調)を示すエンド・トゥ・エンドでのメッセージ検証図がある。エンド・トゥ・エンドでのメッセージ検証図により、システムの動作を検証する。例えば「ここでこの程度時間がかかるから相当のハイバッファが必要だ」という事を検証する。

このようにすべての設計に対し、筋道をたてて根拠を示すことが、アーキテクチャ構築の最重要課題である。言い換えればアカウンタビリティ(説明責任)を重要視するのである。
構築したアーキテクチャは後に評価される必要がある。初期の要求と制約を満たし運用が可能なアーキテクチャであることを確認する。また、ステークホルダーの承認を得るために、客観的な根拠を提示する。

◆ITソリューションの構築手法決定
開発規模と負荷の相関について説明する。開発規模が小規模であれば負荷の大きさは個人差による影響が大きくなる。大規模の場合は個人差よりも欠陥除去作業による負荷が大きくなり、また開発全体に占める負荷の割合自体も大きくなる。開発規模を上手く小さくするように努力する。きちんとしたコンポーネント分割をしていれば、救いの道がある。
IT構築は基本的に手探りで進むため、実装終了間近まで要求の実現可能性を確信しづらい。Standish Group "Chaos Report 2007"によれば、プロジェクト成功率は28%である。このような背景から、ITソリューションの構築手法の選択はリスクヘッジの組み込みでもあると言える。リスクヘッジの手法には、プロトタイピング、モデル駆動型開発、反復型開発プロセス、スモールリリースと継続的インテグレーション、ビジネスプロセス・モデリングとシミュレーション等があり、軽減したいリスクに対応した手法を選択することが肝要である。

◆ ITソリューションの最適化
ITソリューションの最適化として、ITソリューション実現のコストや方法の最適化だけでなく、顧客の本質的な要求を解決するためにソリューション自体のパラダイムチェンジを行う場合もある。例えば自販機の在庫管理で説明すると、当初顧客から自販機に缶を補充する際の最適経路を計算するシステムが要求されたとする。このシステムは実現が難しく、改めて顧客の本質的な要求を調査したところ「売り切れによる機会損失を無くしたい」という要求が見えてきた、そこで自販機から在庫情報を自動送信する仕組みを構築することで当初よりも安価でシンプルなITソリューションを実現する事が出来た。このように適切なアーキテクチャは、パラダイムを変えて問題を解くソリューションを提供する。
最適なソリューションを生むために必要なものとして、ドメイン知識、実現技術を選択するための知識、問題分析とパターン化の知識(要求工学プラクティス)が挙げられる。
NFRの特徴として、主観的(人により解釈と評価が異なる)、相対的(対象システムの特性により重要な点が異なる)、相互干渉的(一つのNFRを達成しようとすると他のNFRを損じる)ということが挙げられる。扱いが難しいが、システムの重要成功要因として大きな比重を占めている。

◆ビジネス戦略・課題の領域からIT領域まで
アーキテクチャは、何もITシステムに限った話ではない。
ビジネスとITライフサイクルは、表裏一体がよい。ビジネスのミッションを達成するためにシステムを作り、ダメであれば修正する。そういった大きな改善のサイクルがある。ビジネス駆動型でなければならない。アーキテクトはビジネス・アーキテクチャをも把握しておく必要がある。

◆ニュー・パラダイムへの挑戦
新しい技術はアーキテクトが「やろう」と言う責任がある。プロジェクトマネージャは、新しいことへの挑戦を決断しにくい立場にあるからである。
クラウド・コンピューティングはアーキテクチャ設計技術に大きな変化をもたらすであろう。APIを備えているPaaS( Platform as a Service)の急成長に伴い、開発スピードが上がる。そのことにより運用のスピードが早くなる必要がある。インフラ構成も、プログラムで書きそのコードを構成管理する時代となった。Infrastructure as Codeという技術がある。そしてDevOps(開発と運用の一体化)により要求をタイムリーかつ継続的に実現する。DevOpsの狙いとしては、開発と運用の連携不足による「老朽化で全面更新」の防止であり、継続的なデリバリーによるシステムコストの平準化である。また、データは時間的にも空間的にも細かな精度で得られるようになり、流動するビッグデータの解析に速さが求められるようになっている。
ITが進みすぎて、企業システムの価値や求められる優先順位が変化している。QCDというキーワードの時代は過ぎ去りしものとなり、フォーカスされなくなっている。近年はAgility(連続的な変化への柔軟かつ迅速な対応)が必要とされてきている。更に将来は Dynamic / Optimization(動的な最適化)が必要になるだろう。

技術の変化に追随しつつ、技術の断片に惑わされない原則を身につけることが、アーキテクトの醍醐味である。

＜質疑応答＞
Q：要求分析の工程では、アーキテクトはどのように関わるのか？
A：可能な限り、アーキテクトがITにおける実現を考えながら要求を分析する。
デザインパターン、テクノロジーの他に、対象システムのドメイン知識が頭に入っていなければできない。
Q：リードアーキテクトは、ドメイン知識の他にどのようなスキルが求められるか？
A：ドメイン知識よりも、ビジネスモデルがどのように構築されるか？を考慮する必要がある。
ビジネスモデルを構築するための勉強が必要。
Q：バージョンアップによりアーキテクチャが崩れていくことや、ビジネスのアジリティに追いつけないことがある。新しいものを導入するのが良いかこれまでのものを利用するのが良いか悩むこともある。どうしたらよいか？
A：アプリケーション・システムの特性により最初から満点でいかなければならないものもあるが、多くのものは「最初から１００点満点を作らない」という方に向かうと思う。ネットワーク化されることでアップデートが簡単になる。ネットワーク化されるかどうかがカギとなる。
APIで保護(システム動作が保証)される必要がある。バックエンドを入れ替えてもプログラムに何の影響もでない、というケースが増えていくと思う。
Q：アーキテクトは成果物に対しフィードバックを受けて評価するということだが、具体的にはどうするのか？
A：ATAMなど評価の方法は様々だが、アーキテクチャそのものを評価するものではなく、どう判断したのかを評価する手法もない。また、アーキテクチャそのものを評価しても、その上に載るアプリが機能していなければならない。
「どこでどのような判断をして決定したか」という事に対して、本当にそれで良かったのか？軌道修正の必要があるか？などを評価する。
Q：ITアーキテクトの評価をするガイドラインはあるか？
A：昇進プロセス上では上位のアーキテクトがインタビューを行なって評価するが、実際は業務や成果物を直接目で見る必要がある。また、知識よりも説明責任をきちんと果たせるかが重要である。
Q：ビジネスモデルに対する発想を広げる前に、説明能力を鍛えることが必要か？
A：説明能力が欠如しているときちんと伝えられないため、一定以上の規模をリードすることができない。
ビジネスモデルに対する発想が豊かであるかどうかは、業務経験の多さだと思う。多くの業界で多くの経験を持つほうが良い。

＜講義の感想＞
アーキテクチャ設計とはどんなことをするのか？アーキテクトはどのような役割を担当するのか？今まで理解することが難しかったことをわかりやすく丁寧に解説していただき、理解が深まりました。また、アーキテクトが様々な経験や知識や技術を備える必要があることもよくわかりました。現場を見ていても、根拠を示したうえでステークホルダーが納得するように説明できることは非常に大切なことだと思います。そしてアーキテクチャの構築はアーキテクトに任せておけば良いというものではなく、プロジェクトに関わるすべての人がもっと関心を持つことでよりよいプロジェクトになるのではないだろうか、と感じました。