「論文的思考のすすめ 〜今こそ問題解決できる組織へ〜」

清水 吉男氏　（株式会社 システムクリエイツ）

「SQuBOKガイド（ソフトウェア品質知識体系ガイド）の概要と活用のポイント」

町田　欣史氏　（株式会社NTTデータ）

「チームビルディング 〜プロジェクトを成功させるチーム作りの体験」

奥村 有紀子氏、林 眞弓氏、堀田 文明氏（以上、(有)デバッグ工学研究所）、栗田 太郎氏（(株)フェリカネットワークス）

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

「意識改革による成果を出すプロセス改善の方法〜『わかってくれない』『やってくれない』からの脱却 〜」

石橋　良造氏　（株式会社 R D P i ）

「形式手法って何？ 〜その特質と効用について〜」

荒木 啓二郎氏
　（九州大学大学院システム情報科学研究院）

1)「SI事業におけるUCDへの取組み」
2) 「優れたUXを実現するためのRIA活用」
3) 「アジャイルUXの潮流」
4) 講演者によるパネル討論とQ&A

1) 青木　博之氏（NECソフト株式会社）
2) 三井　英樹氏（RIAコンソーシアム運営委員長）
3) 川口　恭伸氏（アギレルゴコンサルティング株式会社）

「ソフトウェアプロダクトライン、そして品質種別」

日時

2011年5月20日（金）　10:00〜12:00

会場

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

テーマ

「論文的思考のすすめ 〜今こそ問題解決できる組織へ〜」

講師名・所属

清水 吉男氏　（株式会社 システムクリエイツ）

司会

第6分科会 派生開発 副主査  飯泉　紀子氏　（株式会社 日立ハイテクノロジーズ）

アジェンダ

１．私とSQiPとの出会い
２．品質について
３．私にとっての論文的思考
４．論文的思考から見た現状の問題
５．今回の研究員の皆さんへのメッセージ

アブストラクト

私自身，フリーでこの仕事をやって行くために取った行動が論文を読むことであった。たくさんの論文を読んでいるうちに、論文の構造が共通していて、それが問題を解決する思考のステップになっていることに気がついた。この論文の構造を使ってソフトウェア開発に必要な技術の習得や問題を解決してきた。
今日、多くの問題が組織の中に溢れているが、そこには「論文的思考」の欠如が問題を拡散させ、より複雑にしている面がある。
SQiPの研究会を通じて、ぜひ論文的思考を身につけて欲しい。

＜講義の要約＞
◆問題を解決できない組織の特徴
・組織の問題を定義する、あるいは解決方法を理解する能力が不足している。
・根本的にソフトウェア・エンジニアリングの技術が不足している。
・相手の評価よりも、欠点を指摘するような企業文化が蔓延し、自発的に活動する意欲が失われた受動的なスタッフが多い。

◆問題解決の取組み
１，問題分析
解決すべき現場の問題を集めて分類する。
２，課題設定
解決すべき問題と、問題を引き起こしている原因を推測する。
３，関連技術の収集
問題をその原因から解決するような新しい方法を、文献や論文から探す。
４，シミュレーション
新しい方法が現実に効果を発揮するか、自分の置かれている状況に合わせてプロセスを調整し、事前に机上でシミュレーションを行う。シミュレーション後、効果を確信した時点で現場への提案を行う。
５，実施と検証
事前にシミュレーションを行うことで、混乱無く新しい方法を実施できる。また原因をとらえて実施しているので概ね効果が出る。
６，残った課題の確認
効果を上げなかったケースを整理し、取組み方法を調整して次回の機会へと回す。
７，論文の形式で取組みを記録
効果を記録することで、取組みを確実なものにでき、他のスタッフによる水平展開も容易になる。

◆清水氏と論文との接点
・論文を読むことで、課題に対する解決方法を学んだ。
・数多くの論文を読むことで、そこに共通する問題解決の手順「論文的思考」があることに気付いた。
・現場で行った問題解決の内容を論文形式でまとめるようになってから、技術の習得を確実に行えるようになってきた。

◆品質は技術と心で実現するもの
品質は技術だけでは実現しない。スタッフ一人ひとりに知識や技術を継続的に学習しようとする心が必要になる。心を形作るのはその人の持つ人生観や職業観であり、プロとして人や社会に貢献する、顧客の要求に応えようとする心が重要である。一定の成果で満足していては成長が止まってしまう。

◆肯定眼、能動
・効果的な取組みを水平展開して行くには、人の優れたところを認めて学んでいく姿勢、すなわち肯定眼が不可欠である。肯定眼を持ち、人の優れたところを見つけて真似る行為が水平展開の出発点である。
・相手が出してきた成果に対し、良かった点をその理由を添えて指摘することで、周囲のスタッフの記憶にも残り、水平展開へと繋がっていく。

◆SQiP研究員への期待 〜論文的思考を身につける〜
・勉強時間をまず確保し残りの時間で生活することで、毎日確実に勉強する習慣を身につけて欲しい。
・論文の取組み方を身につけ、論文的思考の有効性を周囲にも伝えて欲しい。
・課題を持って研究活動に臨んで欲しい。
『この一年が研究員の皆さんにとって、人生の転機となることを願う。』

＜講義の感想＞
仕事で成果を出して行くには、現場の課題を見るだけでなく、自分の人生観や職業観についてもしっかりとした軸を持つ事が重要であると話されているのを聞き、とても感銘を受けました。自ら視野を狭くして成長が止まらないように、自分の生き方を問い続けて仕事や研究に取り組もうと思います。

日時

2011年6月17日（金）　10:00〜12:00

会場

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

テーマ

「SQuBOKガイド（ソフトウェア品質知識体系ガイド）の概要と活用のポイント」

講師名・所属

町田　欣史氏　（株式会社NTTデータ）

司会

第5分科会 テスト 副主査  秋山　浩一氏　（富士ゼロックス株式会社）

アジェンダ

１． SQuBOKガイドの概要
２． SQuBOKガイドの特徴
３． SQuBOKガイド活用のポイント
４．まとめ

アブストラクト

2007年に日本発のソフトウェア品質知識体系ガイドであるSQuBOK(R)ガイドが公開された。SQuBOK(R)ガイドは、ソフトウェア品質に関する古今東西のノウハウが凝縮、整理され、ソフトウェア技術者必携の書であると言える。本講義では、SQuBOK(R)ガイドの特長を11個にまとめて紹介するとともに、様々な立場の方がどのようにSQuBOK(R)ガイドを利用すればよいかについても言及する。
本講演の内容を参考に、多くの皆様にSQuBOK(R)を有効に活用していただきたいと思っている。

＜講義の要約＞
◆ SQuBOKガイドの概要
BOK(知識体系)とは、ある専門領域の知識の総和であり、
「SQuBOK(Software Quality Body of Knowledge）」とは、ソフトウェア品質に関わる実務者や研究者が有する知識体系である。
情報共有されず未整理であった知識を体系的に整理し、構造化、可視化したものが、SQuBOKガイドである。
SQuBOKガイド策定の目的は、人材育成やソフトウェア品質技術の認知度向上などがある。
SQuBOKガイドの知識構造は、「ソフトウェア品質の基本概念」「ソフトウェア品質マネジメント」「ソフトウェア品質技術」という、3つのカテゴリから構成されている。
また各カテゴリは、その下に副カテゴリ、知識領域、副知識領域、トピックスを持つ5階層の構成になっている。
ソフトウェア品質マネジメントとソフトウェア品質技術とで対応付けを行うなど、より読みやすく、わかりやすくするための工夫も行っている。
※第一版では、設計、実装はスコープ外となっているが、現在第二版改訂へ向けて活動を進めている。

◆SQuBOKガイドの特徴
11の特徴を紹介。
(1) SQuBOKは、「日本発」の知識体系
　　アメリカ・ドイツ・中国など、世界にも紹介している。特に中国で展開。中国語版の作成が今準備中。
(2) 多くの参考文献へのポインタとなっている
　　SQuBOKだけでも300ページ以上の書籍だが、参考文献・企画・表彰された論文を紹介している。
(3) 古いものから最新のものまで幅広く取り上げている
　　古典的なものも依然として有効である。
(4) 海外の情報も数多く取り上げている
　　品質マネジメントについては日本の情報が6割。日本の得意分野。
(5) 一流企業の実績ある技術を紹介
　　どこの企業で扱われているか、も明記されている。
　　事例ベースで、ある程度やりかたがわかるようになっている。
(6) 複数の異なる定義を掲載
　　同じ用語でも人によって解釈が違う。捉え方によって意味が違ってくる。
　　担当者内で合意、あるいはお客様と合意するときに、目指すところはこういうところだ、
　　というのを定義するのに活用してみてはどうか。
(7) 規格の概要を容易に確認可能
　　まずはSQuBOKガイドで確認してみる、ということができる。
(8) PMBOKやSWEBOKのソフトウェア品質に関する要素を抽出
　　「PMBOK（Project Management Body of Knowledge）」や「SWEBOK（Software Engineering Body of Knowledge）」を尊重しつつ、
　　対応しながらつくった。双方を見るとき混乱しないようにまとめた。
(9) 読者の皆様のご意見を反映して進めていく
　　SQuBOKユーザ会というのがある。活動はMLベース。気軽に参加いただきたい。
(10) 資格試験がある
　　JCSQE
(11) 日本的品質管理の特徴が垣間見える

◆SQuBOKガイド活用のポイント
SQuBOKガイドを、どう使えばよいのか？効果的な使い方を、ロールごとに紹介。
本当は全体を理解するのが望ましいが、まずは自分の担当する工程や関連領域から学び始める。
マネージャ：(プロマネ・品質管理マネージャ)
　　　工程や領域を学んでから、対応する技術を学ぶ。
開発者：
　　　個別のプロジェクトレベルから、対応するマネジメントを選ぶ。該当する技術を学ぶ。
標準化・改善の推進者：
　　　まずは組織としてすべきことを学び、
その後、品質保証の考え方、改善の考え方を学ぶ。基本に立ち返る。
　　　あるいはマネジメントや技術を確認。
ユーザ：
　　　品質はお客様の満足を満たす。ではお客様はどのような品質を要求しているのか？
　　　要求する品質を確認し、プロダクトやプロセスの品質の作り込みや確認について学ぶ。
新人・若手：
　　　辞書代わりにつかってもらう。
　　　知識を知っている、あるいは説明できる、というレベルを目指す。
　　　実際、新人研修でわからない用語について調べさせている。
　　　読んで意味を知るだけでは理解できないので、更に参考文献を読んでみる。
中堅社員：
　　　キャリアパスの実現に活用。
　　　今やっていることをより深く理解していく。あるいは、新しい分野、更に広げる。
ベテラン
　　　見直し、新たなチャレンジに利用。
　　　組織やプロジェクトの独自スタイルに慣れているため、考えややりかたが固まっている傾向がある。
　　　あらためて基本に立ち返るのがよい。基本はおろそかにしない。

◆まとめ
SQuBOKガイドは継続的に発展していく！
開発現場で活用していくことで、「知識」から「知恵」に変わっていく。
それらの知恵や実践結果を SQuBOKガイドにフィードバックしてほしい。
SQuBOKを海外へ発信してきたい。ソフトウェア産業を成長させていきたい。

＜講義の感想＞
SQuBOKガイドを読んだだけでは業務に使えるようにならない、という言葉は全くそのとおりであり、業務の中で活用していくためのポイントをロールごとに解説してくださったことで、非常に身近なものになったと感じました。

日時

2011年7月7日（木）　13:30〜16:00

会場

箱根ホテル小涌園

テーマ

「チームビルディング 〜プロジェクトを成功させるチーム作りの体験」

講師名・所属

奥村 有紀子氏、林 眞弓氏、堀田 文明氏（以上、(有)デバッグ工学研究所）、栗田 太郎氏（(株)フェリカネットワークス）

司会

第5分科会 テスト 主査  奥村 有紀子氏(（有)デバッグ工学研究所）

アジェンダ

・プロジェクト型チームの特徴とチームの形成
・チームビルディングのモデルと実践に向けて
・チームビルディング演習

アブストラクト

現代は製品価値達成に対し、チームの各メンバーが自主的に行動およびフォローしながら仕事を進める、「プロジェクト型チーム」の存在が鍵を握るようになってきた。そこでこの講義ではプロジェクト型チームのチームビルディングの重要性について焦点を当てて解説する。また、演習を通してチームビルディングを実体験する。

＜講義の要約＞
◆チームビルディングの必要性
現代のソフトウェア開発は定型的なマニュアルのない、知的な活動を必要とするプロジェクト型の仕事が増えてきた。また、一緒に仕事をしていくメンバーも様々な業種から流動的に集まるようになり、チームの立上げの早さが仕事の生産性に大きく影響するようになってきた。
プロジェクト型の仕事で必要なのは、自立したメンバー同士によるチームワークである。正解が不明確な作業上の問題に対し、メンバー同士で知恵を出し合い解決して行くことで、仕事を達成出来るようになる。
ただしチームワークは団体スポーツ同様、チーム訓練によって成長していくもので、チームビルディングの取組みがプロジェクト成功の鍵を握っている。チームを作る練習が必要であり、メンバー間の信頼関係を作ることが重要である。

◆チームの階層構造
チーム力を発揮するには、基盤として、まず自己紹介等を通じた「メンバー間の関係性」の成立が必要になる。次に、メンバー間でのコミュニケーションを通じた「ヒューマンコミュニケーション」の成立が必要になる。最後に、プロジェクト成功に向けたメンバー同士の積極的な取組みを通じて「詳細なテクニカルコミュニケーション」の成立が可能になる。

◆チームビルディング演習：スパゲティタワーの作成
チームビルディングを体験するために、スパゲティとメラミンスポンジを使用したタワー作成の演習が実施された。
【作業手順】
・チームメンバー同士による自己紹介
・チーム名、タワー名の決定
・建材（スパゲティとメラミンスポンジ）の特性調査
・タワーのスケッチ作成と工法のアイデア出し
・タワー作成の作業分担およびタワー作成の実施
・チームメンバー同士による作業の振り返り（KPT）

各作業においてはメンバー同士の知恵の出し合いが重要である。より高く安定したタワーを作成するには、作成過程で発生した問題の解決に向けて常時意見を交換しながら自主的に活動する必要があった。

◆職場でのチームビルディングの実践
職場のチームにおいて、合意が成立しにくい等の問題があるなら、まとまった時間を設けてタワー作りを実践するのもよいだろう。メンバー同士がそれぞれの考えや気持ちについて話せる関係が大事である。
まず自分自身がチームビルディング力を養い、次に自分が所属するチームを成功するチームへと成長させて、更にその流れを職場全体へと広げていくことで、より良い職場へと変化していく。

◆感想
チームビルディング演習では、私の所属したチームが最も高いタワーを作成できた。
その理由を考えてみると、タワーを分割して作成することで全員が無駄なく作業できたこと、軽量かつ強靱な工法を提案できたこと、バランス調整など即時の判断が必要な作業に対して各自が自律的に対応できたことなどが挙げられた。また振り返りとして、タワーの構造上の改善点や、積極性が若干不足してアイデアを伝えきれなかった点などが挙げられた。
今回の演習ではメンバー各自が相手の意見を尊重して更に洗練させて行った点に、チームワークの可能性を感じる事が出来た。また自己紹介の方法を工夫するなどして、メンバー同士のコミュニケーションを早期に活性化させる必要性を感じた。

スパゲティタワーの作成を通したチームビルディング演習では、知恵の出し合いや積極的な参加など、チームビルディングの効果と重要性を実感出来た演習だった。また演習は日用品で実施可能なので、是非社内でも実践する機会を設けていきたい。 

日時

2011年10月7日（金）　10:00〜12:00

会場

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

テーマ

「意識改革による成果を出すプロセス改善の方法
〜『わかってくれない』『やってくれない』からの脱却 〜」

講師名・所属

石橋　良造氏　（株式会社 R D P i ）

司会

特別コース 主査　小池　利和氏　（ヤマハ株式会社）

アジェンダ

・意識改革とは
・「やる気」の基礎知識
・内発的動機づけの３要素
・意識改革した人
・まとめ

アブストラクト

開発プロセス改善に代表される組織の仕組み作りは苦労が耐えない。仕組みを推進する側は現場の人たちが協力的でないことを憂い、現場側は余計な作業が増えると推進する人たちを遠ざける。味方である上司やメンバーとの間での意見の相違に悩むこともあり、やる気をなくすこともしばしばである。
忘れてはならないのが、仕組みを支えているのは個人であり、個人のやる気なしには
仕組みは機能しないということだ。推進する側も現場側も含めて関係者一人ひとりの
やる気を引き出すことが大切である。
本講義では、やる気を引き出すための意識改革の考え方、進め方を紹介する。組織の仕組みと個人の意識の両方に働きかけることが大きな成果につながることを理解し、実践する大切さを伝えたい。

＜講義の要約＞
◆ 意識改革とは
組織を形成しているのは個人であり、個人が成果を出すことが大切である。
しかし、「今、あなたが出せているパフォーマンスは何点か？」と問うと、高いパフォーマンスが出せていないことがわかる。
気分が最高(上機嫌)であれば、パフォーマンスも最高(Performance excellence)になる。当たり前のことだが忘れがちである。
上機嫌でいるために具体的に何をすればよいのかを知っていることで、やる気につながる。
意識改革とは、Performance excellenceのために上機嫌でいるためのココロの変革である。

◆「やる気」の基礎知識
「やる気」には、一時的なやる気である「テンション」と、継続的なやる気である「モチベーション」がある。またモチベーションは３つに分類できる。すなわち生きる上で必要な生存本能（モチベーション1.0）、報酬や罰にもとづく外発的動機付け（モチベーション2.0）、自分の内面から湧き出る内発的動機付け（モチベーション3.0）である。
やる気の内、仕事で最も必要になるのは内発的動機付けである。その理由は我々が日常行っている仕事は発見的手法を必要とする「ヒューリスティック」なものであり、ルーチンワークで解決する「アルゴリズム」的な仕事はほとんど無いからである。ヒューリスティックな取り組みを行うにはクリエイティビティが必要になり、その為には、重要だからやる、面白いからやると言った内発的動機付けによる働きかけが不可欠である。しかし多くの組織で行われているのはアメとムチ方式による外発的動機付けへの働きかけで、この方式ではヒューリスティックな取り組みに対しては逆効果であると言う実験結果も示されている。

◆内発的動機づけの３要素
内発的動機づけにより行動しているタイプの人は、自分の意志で行動を決め、意義あることの熟達を目指し、大きな目的を追求する。従って内発的動機づけに必要となるのは、「自律性」「熟達」「目的」の３つの要素である。
自律性のために必要なことは、「認知の仕組み」(「意味づけ」していること)を知ることと、「No Excuse」(自分で決める)こと。
脳が持っている認知機能のために、人は外部要因に対してネガティブな「意味づけ」を行ってしまう。これが上機嫌ではない状態を作ってしまう。フローブレイン(上機嫌の脳の使い方)を強化するためには、「意味づけ」していることに気づくことが必要である。気づくことで気分を良くするための対策がとれ、自分の意志で決断し行動するといった、自律した状態を作れる。
「No Excuse」を「言い訳しない」と訳すと、「言い訳」の時点で認知が働いてしまう。「自分で決める」ことが大切である。

熟達は、「どこまでもやれる」というマインドのことである。不可能と決め込むのは熟達のココロではない。
不可能が無い(Nothing is Impossible)ではなく、不可能があっても自分には関係ない(Impossible is Nothing
)という考え方をする。
目標に対する考え方からも「熟達」を知ることができる。人より優れた結果を目指す遂行目標ではなく、自分自身の能力を伸ばすことを目指す学習目標を持つほうが、熟達のマインドが強くなる。

目的に対するキーワードは「自分軸」である。
人は何かの仕事をするときに、先に方法を考えてしまい、自分の価値観やビジョンを忘れがちである。ビジョンとは夢ではなく、自分が実現したい未来である。
思考の傾向(未来or過去／快追究or苦回避／自分主役or他人主役)を把握した上で自分軸を考える。自分軸をもとに自分に見合う方法を考える。方法が自分に見合っていれば苦ではなくなり、やる気に繋がる。

◆意識改革した人
「現状追認」「目的(自分軸)」「自律性」「熟達」「成果」という5つのステップで、「意識改革をした結果どのような成果を出せたか」についての事例紹介があった。

◆まとめ
3つの質問とその答え
Q. なぜ意識改革が必要なのか？
A. 組織で成果を出すことがゴール。そのために個人のパフォーマンスが大事である。
　 Performance excellenceのために上機嫌の状態に持っていくことが意識改革である。
Q. なぜマインド(意識)を変えるのは難しいのか？
A. 認知脳(意味づけ)が自分のココロを縛っている。それは本能であり仕方が無いため、難しい。
　 難しさを知った上で、克服することが大切である。
Q. 具体的に何をすればよいのか？
A. 認知脳に関しては、気付くこと。上機嫌になるにはどうしたらよいだろうか？を考え、コントロールする。
　 ゴールを学習目標とする。
　 思考の癖を知った上で、工夫できるところを考える。

＜講義の感想＞
講義内容にキーワードが多く含まれていたことで印象に残りやすく、日頃心がけていく上でとても効果的であると感じました。また、自分自身の意識改革を行うヒントと、自分と関わっている周りの人の意識改革のためのヒントがいただけたことが嬉しく、是非現場で活かしていきたいと思います。
 

日時

2011年11月18日（金）　10:00〜12:00

会場

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

テーマ

「形式手法って何？ 〜その特質と効用について〜」

講師名・所属

荒木 啓二郎氏　（九州大学大学院システム情報科学研究院）

司会

栗田 太郎氏（フェリカネットワークス(株)）

アジェンダ

・ 形式手法の歴史
・ 形式手法の特質
・ 実践のポイントと適用事例

アブストラクト

形式手法（フォーマルメソッド）に対する認識を周りに聞いてみると、「新しいソフトウェアの開発技術らしい」、「難しい数学を使うらしい」など多くの誤解が見受けられる。今回はそれらの誤解を解いて、形式手法の出自や役割、国内外での適用事例、現場で実践する際のコツなどを紹介していく。(書記の小田部が記す)

＜講義の要約＞

◆形式手法の歴史
ヨーロッパでプログラムの正しさを検証しようと言う話が1960年代からあり、1970年代には検証理論に関する研究に発展し、様々な形式仕様記述言語や方法論、ツールが開発されていった。そして、形式手法における記述方法は、何時誰が見ても一意に記述内容を解釈出来るよう厳密に記述しようとする過程で、自然と数理論理学に基づくものとなっていった。
現在では30年以上の歴史と100種類以上の手法があり、分析や設計、検証など、様々な分野に適用されている。またソフトウェアの高信頼化に伴い形式手法の必要性は増し、ISOやIECなどの国際標準規格で形式手法が推奨され始めているので、国際的な活動をする際にも必要になって来ている。

◆形式手法に関する社会通念 (スライドからの引用)
[J.A.Hall:Seven Myths of Formal Methods, IEEE Software, Vol.7, No.5, pp.11-19, 1990]
以下の誤解が世間でよく言われている。
・ソフトウェアが完全であることを保証できる
・須くプログラムの正しさを証明するためのものである
・セーフティクリティカルシステムにのみ有効である
・高度に訓練された数学者を必要とする
・開発コストを増加させる
・ユーザに受け入れられない
・現実の大規模ソフトウェアには使われない

◆形式手法に関する事実 (スライドからの引用)
[J.A.Hall:Seven Myths of Formal Methods, IEEE Software, Vol.7, No.5, pp.11-19, 1990]
実際は以下の効果を期待できる。
・開発初期段階での誤りの発見に有効である
・開発対象のシステム自体を深く考えさせることに寄与する
・いかなる応用分野にも有効である
・数学を基礎とはしているものの、プログラムよりは理解しやすい
・開発コストを減少させる
・顧客が購入しようとしているものの理解を助ける
・産業界における実用プロジェクトに用いられて成功している

◆難しい数学が必要か？
形式手法のベースとなる知識には、基礎的な集合論、論理学、帰納法等である。これは基本情報技術者試験のレベル２のシラバスに載っている程度の知識なので、受講している皆さんの多くは問題なく形式手法を習得出来るだろう。

◆形式的（数理的）モデルの構成手順
要求定義書を読み、潜在的なデータ型と機能を抽出する。名詞に着目するとデータ型、動詞に着目すると機能が抽出できる。抽出したデータ型の詳細は未定のままでも抽象化モデルでは様々なことを記述できる。例えば名前や生年月日のデータ型が開発のある時点で決まっていない、または決められなかったとしても、その時に定めている範囲でデータを定義可能であり、データ同士の対応関係の記述が行える。その後必要になったときに具体化を行えばよい。
重要なのは、データ型の構成だけを考えるのではなく、システムをシステムたらしめるデータの制約条件を見つけて明記することである。記述上の注意点は、何をするのか（What）を記述することで、どう解を得るか（How）は記述しない。

形式手法では仕様記述段階での検証が可能になることで、従来はプログラムを動作させて初めて明らかになる不具合の除去が可能になり、手戻りを減らすことが出来る。また厳密に書かれた成果物を読み取ることで記述対象への理解と技術の習得が促進され、知識の共有と継承へとつながっていく。

◆実践のポイント
管理職の意識が重要である。最初は進捗していないように見えても我慢する。また形式手法への関心や期待が推進力となり、担当ドメインエキスパートの意欲へ影響する。
形式手法の厳密な記述と議論に対し最初は戸惑うが、理解が進むにつれ新鮮な感動へと変わってくる。形式仕様記述言語は読むのは難しくないが、書くには言語仕様や記述対象への理解、抽象化の能力、モデル化やイディオムの知識や経験が必要になる。また、慣れてきた段階で、チームビルディングなど維持継続の努力と支援が重要である。

日本語の教材も出そろってきたので是非学んでいって欲しい。また普段から相談相手がいることも重要である。社外のコミュニティなども活用して欲しい。

◆形式手法の十戒 (スライドからの引用)
[J.P.Bowen & M.G.Hinchey: Ten Commandments of Formal Methods, IEEE Computer, Vol.28, No.4, pp.56-63, 1995. ]
含蓄のある言葉なので覚えておいて欲しい。
・汝、適切な表記法を選ぶべし
・汝、形式化を行うべし、されど過ぐること勿れ
・汝、コスト予測をすべし
・汝、形式手法の師匠を身近に持つべし
・汝、従来の開発法を棄つること勿れ
・汝、十分に文書化すべし
・汝、自らの品質標準を危うくすること勿れ
・汝、独善となるなかれ
・汝、テストすべし、またテストすべし、さらにテストすべし
・汝、再利用すべし

◆検証例：単純な通信プロセス
例えばプロセスAとBが並行動作するシステムにおいて、AとBの2つのプロセス間でのメッセージのやりとりで問題が起こらないかについて形式手法を用いて検証することができる。「到達可能木」と呼ばれるモデルを用いると取り得る状態を網羅的に確認することが出来ので、そこからデッドロックの有無や通信チャンネルが溢れないか、また通信チャンネルにメッセージが残り続けないか等を証明することが出来る。

◆適用事例：モバイルFeliCa ICチップ
モバイルFeliCaの開発プロセスでは、仕様の記述と検証に形式手法を適用した。
VDM（形式手法の一つ）での仕様記述が約10万行、外部仕様書677ページ分とプロトコルマニュアル383ページ分、C/C++言語換算で約11万行分を記述した。成果としては、2010年9月の時点で不具合件数が「ゼロ」である。

◆講義に対する質問
Q：「要求定義書を読む」とあるが、資料の内容が抽象化可能なレベルに達していない場合はどうすれば良いのか？
A：要求仕様書と数理モデルを行き来してみる。そうすると曖昧な点や不明な点が出てきて、資料の内容そのものが改善される。また私のように開発対象に対する素人が訊いた方が質問しやすい場合もある。質問から今まで暗黙知や常識として捉えていたものが実はそうではなかったことが分かる事も大事である。また質問に対して「勉強不足」などと言わない／言われないルール作りも大事である。

Q：十戒の「テストすべし」は、必要なテストをするべしと言うことか？
A：形式手法はツール等の使用により、検証（Verification）が容易になる手法であるが、その一方で妥当性（Validation）の確認は苦手で従来通りのテストが必要になる。形式手法で何が出来るか知ることが重要である。

＜講義の感想＞
恥ずかしながら、私自身、講義を聴くまで形式手法が自分の仕事に利用できるとは考えていなかった。「形式手法で記述し直すことで、対象への理解がより深まる」「誰が何時読んでも内容が一意に伝わるように記述できる」点は、上手く使えばドメインの知識を整理した上で、距離が離れた相手同士でも誤解無くコミュニケーションがとれる可能性があり魅力を感じた。

 

日時

2011年12月16日（金）　10:00〜12:00

会場

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

テーマ

1)「SI事業におけるUCDへの取組み」
2) 「優れたUXを実現するためのRIA活用」
3) 「アジャイルUXの潮流」
4) 講演者によるパネル討論とQ&A

講師名・所属

1) 青木　博之氏（NECソフト株式会社）
2) 三井　英樹氏（RIAコンソーシアム運営委員長、株式会社ビジネス・アーキテクツ）
3) 川口　恭伸氏（アギレルゴコンサルティング株式会社）

司会

第4分科会 主査　金山 豊浩氏　（株式会社ミツエーリンクス）

テーマ１
アジェンダ

1．はじめに　-弊社プロフィール、UCD取組みの背景と目標
2．活動の進展
　　（1）普及活動と教育・人材育成
　　（2）プロセス体系化・開発効率化の技術開発
　　（3）定常体制化と次期アプローチ
3．まとめ・評価　

テーマ１
アブストラクト

ＳＩ事業における顧客の満足度向上のためには、狭義のＳＷ品質向上だけではなく、「新しいソフトウェアの開発技術らしい」、「難しい数学を使うらしい」など多くの誤解が見受けられる。今回はそれらの誤解を解いて、形式手法の出自や役割、国内外での適用事例、現場で実践する際のコツなどを紹介していく。(書記の小田部が記す)

テーマ２
アジェンダ

1. RIA(Rich Internet Application)とは
2. User Experience の要素
3. ユーザビリティにおける開発プロセス
4. RIAの開発ツール
5. RIAを取り巻く状況
6. 課題となる「品質」とは

テーマ２
アブストラクト

RIA(Rich Internet Application)の歴史と考え方の紹介を通じ、「使われるアプリケーション」のために何がなされているのかを紹介する。得てして過小評価されるデザインの領域がどのようにビジネスに関わるのか、また激動の環境変化の中で、それを開発の現場に取り込んでいくことの難しさも伝える。それらを通じて、従来のソフトウェアの開発プロセスや品質の定義体と、何が同じで何が異なるのかを考える場としたい。

テーマ３
アジェンダ

1．はじめに
2．アジャイルUCD研究会
3．ユーザエクスペリエンスデザイン (UXD)とは
4．アジャイルUXの潮流
5．Passionate Product Design プロセス

テーマ３
アブストラクト

＜講義の要約＞

【テーマ1】
◆UCD取組みの背景と目標
会社として過去20年以上「SW品質の高さ」を最重要価値と考え、事業に取り組んできたが、CS調査における「操作性」「性能」等の満足度が相対的に低く、ユーザビリティ品質向上が最重要課題となった。
以下、ユーザビリティ開発プロセスのことをUCD(User Centered Design)プロセス(ユーザ中心設計プロセス)と呼ぶ。
当時、UI設計の作業標準や教育コースはなく、UI品質の水準に大きなバラつきがあった。そこで全社的にユーザビリティ品質向上の活動を行うため、2007年にユーザビリティ推進室を発足、自分たちのUCDスキル取得から開始し、全社のベースラインを上げる。3年を目標に推進活動にあたった。

◆活動の進展
（1）普及活動と教育・人材育成
ユーザビリティの重要性について、社内へ理解・認知させることを目標に、各部門へ推進活動を行った。
実践を混じえた教育コースを開発。今は新入社員を対象に講演している。
ユーザビリティ適用効果の実証のために、各部門からの要望に基づき、プロジェクトに対しUCD適用支援を継続的に実施した。
（2）プロセス体系化・開発効率化の技術開発
社内への適用。業種ごとに最適なものを作ろうとしている。
UCDプロセスの定義として、UCDプロセスのWBSを定義。プロジェクト計画時にPMがUCDのアクティビティを明確化できるようにした。
UCD開発標準類整備として、UI設計ガイドの下位ドキュメント(手順書・ガイドライン、チェックリスト、画面パターン等)を整備し、改善・強化したうえで情報提供した。
システム基本設計、概要設計に対して、ユーザビリティ設計支援ツールの開発を行った。
（3）定常体制化と次期アプローチ
3年経って、このペースでやっていけばうまくいくだろう、という目処がついた。
今後は推進室活動から、定常ラインの活動へ移し、従来の推進メンバーの活動は、より高度なユーザビリティ専門家としての活動へ移る。(顧客提案時のUCD活動、RIA技術導入やデザイナとの連携、スマートデバイス向けUXの技術開発など。)

◆まとめ・評価
従業員のセルフアセスメントによれば、およそ半数の要員がレベル2(他の指導・援助を得て、当該技術を実践できる)以上のUCD設計スキルを保有できた。

【テーマ2】
◆RIA(Rich Internet Application)とは
RIAとは、豊かな表現力を持ち、より機能的で、操作性の良いWebの仕組みのこと。
定義が邪魔にならないように、定義は暫定的としている。
RIAを生み出した最初のシステムを紹介。以前は3つの画面が順次出てくる仕様だったのを、3画面同時に表示することでユーザが一度ですべてを見られるようにした。
Web開発はユーザビリティが重要である。「選ばれた人しかつかえない」から、「普通の人が使える」→「普通の人にも使いやすい」へ移行している。

◆User Experience の要素
Jesse James Garrettの開発プロセスとUX(User Experience)の概念モデルを紹介。
ユーザビリティだけでなくホスピタリティ(おもてなし)も必要。店員の対応は「おもてなし」に入れる。

◆ユーザリティにおける開発プロセス
ユーザビリティ研究者の第一人者であるJakob Nielsen博士は、デザインプロジェクトにおけるユーザビリティ向上の費用対効果についての調査結果から「良い成果を挙げているプロジェクトでは、予算の10%をユーザビリティ検討に投じている」と結論づけている。
問題のあるプロジェクトでは、設計初期においてはユーザビリティ設計より他の設計を優先させられる。設計末期になるとユーザビリティ設計をしようにも今更変更できないと言われる。その結果、ユーザにとって使いにくいものとなってしまう。また、ユーザは色々いる。開発者がすべてテストしきれるのか？
真剣に考えるべき4つの要素は「何のために」「何を」「誰に」「どのように」である。
ANAの予約システムを例に細部へのこだわりについて説明すると、予約画面で左下のウィンドウをゆっくり上方向にスライドさせながら約款を表示することで注目させ、あえて隠し、再度見るように促すタブ表示だけ残している。

◆ RIAの開発ツール
RIAの開発環境を紹介。
開発スキルとしては、Webの基礎知識を持ったうえで、デザインスキルとシステム開発スキルを持ち合わせる必要がある。

◆ RIAを取り巻く状況
レスポンスに対する期待値が上がっている。限りなくリアルタイムを要求される。
マルチデバイス対応が必要になる。
コンピュータを持てなかった時代から、誰もがコンピュータを持てる時代、そしてクラウドコンピューティング出現でコンピュータを持つ必要が無い時代(持ってはいけない時代)へ移ってきている。
作り手としての生き残りのために、顧客が望んでいる「こと(分野)」「機能」「価値」の各領域から、自社は提供できるが競合他社は提供できない領域を考える事が重要である。

◆課題となる「品質」とは
作っても、「動作しない」「使われない」→プロダクト品質(動作bug)
作っても、「使われない」「売れない」→プロジェクト品質(企画bug、ブランドbug、勘違いbug)
試作を開発プロセスの前のほうから行うのがポイントである。

【テーマ3】
◆アジャイルUCD研究会
アジャイルUCD研究会は、アジャイル開発とUXの複合領域に興味を持つ開発者、デザイナ、リサーチャのための情報交換の場である。

◆ユーザエクスペリエンスデザイン (UXD)とは
1990年代中頃にD.A.ノーマン博士が提唱した。システムを使用するときに人がどのように感じるか？その全体像をカバーする概念。「性能」よりも「喜び」や「価値」に着目する。はっきりとした定義/枠組み/要素は、未だ進歩中である。(http://en.wikipedia.org/wiki/User_experience より、川口氏が翻訳)
iPhone体験を例に解説すると、購入前(店舗の外観)から購入後の箱を開けるときの体験までが、喜びや価値につながる。
利用されている状況について、観察を踏まえて設計する。
ユーザビリティエンジニアが「いっしょにやりましょう」と設計に入り込むことが大事である。
生産性の改善として、人を減らさないでどうやって生産性を上げるか？を真剣に考える。より少数での開発を可能にする代わりに、その結果余った工数および人員で新製品を開発する。
作るものを増やすか？ではなく、「ユーザが使うことでアウトプットが増える」ことを利用し、間接的に生産性向上を目指す。

◆アジャイルUXの潮流
EMZero Vol.5およびEnterprise Zine (http://enterprisezine.jp/article/detail/2664)に詳細が掲載されている。

【パネル】
（川口氏）UXについて、業界の中で必要と思うが、「いらない」「やろうと思っているが、なかなかできない」という声を聴きたい。
聴講者について：品質管理側が1/3、作り手側が1/3、デザイナはいない。
聴講者の中で、UXを進めている企業は？→5名程度と少ない。
聴講者の中で、UXを進めたいが、会社が・・・という方は？→半数程度。

Q.（聴講者）ユーザビリティ設計支援ツールの詳細を教えていただきたい。
A.（青木氏）Visioベースで画面部品を概要図として設計し、見える化したい。
ツールからHTMLやCSSを出す機能がある。
画面を読み込ませて、チェックリストで自動でチェックできるような開発をしている。

Q.（金山氏）啓蒙活動ということで、UXに関する社内展開やお客様への訴えかけに対し、どういう工夫をしているか？
A. （青木氏）(社内に抵抗はなかったか？の問いを受けて)抵抗があるというわけではないが、本当に使えることがわかるまでは、自分から試す人は少ない。(現場で)効果を出してもらい、成功事例を集めて、社内に広げていく。
A.（三井氏）（裸足の文化圏に靴を売りに行く話を例えに出し）「ここに売る余地はない」と思うか「全員がマーケット」と思うかで変わる。自信満々に「いらない」と言う相手に、怒らせないで伝えるにはどうすればよいか？「ここまでできるんですよ」と事例を出して伝える。
A.（川口氏）経営者はつかいやすさにパッションを持っているが、デザイナを雇えというと、マネージャーは困る。人事の人は認めてくれないだろう。どうやって食わせていくのだろう？という悩みも出る。
一方、下の人は、デザイナとどうやって付き合っていいのかわからない。
自分から歩いて、コンサルをする。これくらいならできる？という見積もりを行い、仲立ちをすることから始めた。

Q.（金山氏）品質管理の人のノウハウを、どうやって使うか？
　現状では、ユーザビリティで、品質管理の立場はいらないのか？
A.（川口氏）ユーザビリティの知見を持っている人は少ないため、自分で調べるしか無い。その際、シンポジウムなど外の力を利用する。
ユーザビリティの人不足に対しては
・社内に兼任を雇う(専門の部署をおく)
・社内に教える(困ったら聞ける場所を用意する)
品質管理(Quality Assurance)から、Quality Engineerにさせて、現場に配置させた。
A.（三井氏）普段(ソフトウェアの使用中に)自席でぶつぶつ言っているのを、うまく集約できるとよい。Twitterのような直感を拾える仕組みや「直感を言ってよい」という雰囲気作りを行う。
デザイナ独特の風紀(ジーパン、ピアスなど)の問題がある。価値の違う相手が社長に会うことで、心理的障壁がでる。多様性を受け入れること、本音を言い合えることが重要。
A.（青木氏）品質自体も、一番最初は仕様と実装の齟齬(をなくすこと)から始まり、やがては、要求仕様、顧客要求と仕様がきちんとなっているかの確認が必要。
もっと商品が売れるように、ユーザビリティの品質を確保するには、要求通りに製品ができているかをみる。
必要だったら、ユーザビリティのテストをやる。
運用状況をモニタリングして、使いやすさという意味でのサービス提供ができているか、品質管理が必要。

＜講義の感想＞
UCD、RIAという言葉は恥ずかしながら初めて聴きました。ユーザビリティに限らず、なにが魅力につながるのかを考えて商品をつくるということは、プロジェクトに関わるすべての人が考える必要がある、と強く感じました。内容だけでなく、講義中に黒板に要約を書いていくという川口氏の聴講者を意識した行動も非常に参考になりました。

日時

2012年1月20日（金）　10:30〜12:10

会場

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

テーマ

「ソフトウェアプロダクトライン、そして品質種別」

講師名・所属

林 好一氏　（株式会社SRA）

司会

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

アジェンダ

・SPLE（Software Product Line Engineering）とは
・品質の種類
・今日から始めるプロダクトライン

アブストラクト

＜講義の内容＞
■SPLE（Software Product Line Engineering）とは
◆ソフトウェアプロダクトラインとは
Software Product Line Engineering（SPLE）を直訳すると、ソフトウェア「製品系列」の作り方、となる。これは類似するソフトウェア集約型システム群の開発において、ソフトウェア再利用を体系的・計画的に行い、低コスト、高品質、短納期でソフトウェアを開発しようという考え方である。

◆SPLEとXDDP（派生開発）の違い
派生開発もSPLE同様「再利用」で低コスト、高品質、短納期を実現することを目指しているが、下記の点がSPLEと異なっている。

・XDDPは過去のシステムを基に再利用を検討する（作ったものを再利用する）
・SPLEは将来のシステムを基に再利用を検討する（再利用するものを作る）

例えば類似したアプリケーションAとBをA→Bの順で開発する場合、派生開発ではアプリケーションAを再利用してBを開発する。つまり過去の資産（A）を再利用して次の資産（B）を開発する。一方SPLEは大本にコア資産（再利用可能な資産の集まり）を持ち、コア資産を利用してアプリケーションAとBを開発する。つまりコア資産からワンステップで各資産（AとB）を開発する。

◆SPLEの開発プロセス
SPLEの開発プロセスは、コア資産開発と、そのコア資産を用いたアプリケーション開発の二段階に分かれる。どのようなコア資産を開発するかは、規定した製品系列から導かれる。またアプリケーション開発では、コア資産がもっと使い易く、開発しやすくなるようフィードバックを行うことで品質が向上していく。

◆共通性と可変性
コア資産の持つ共通性の種類は、市場や顧客が求めているもの、事業の中核となるもの、自組織の強みなど様々である。共通性（コア資産）は中長期的に事業展開を長く広く支えて勝つための道具である。可変性（アプリケーション）は短期的に市場やユーザーのニーズに対応することで勝つための道具である。

◆SPLE導入による効果
SPLE導入時はコア資産の開発によりコスト増加する場合もあるが、その後は開発コストの削減を期待できる。ヒューレット・パッカードの例では、ファームウエアその他をコア資産化することで、SPLE導入前より欠陥数（品質）を20分の1、開発の人的リソース（コスト）を4分の1、開発期間（期間）を半分以下に削減出来た。

SPLEは導入する目的を考えることが重要である。例えば類似したアプリケーションの企画提案と開発の共通部分を一本化すると、共有部分を再開発しないので納期短縮とコスト削減を実現できる。また効果のでない典型例としては、実際には使われない「再利用できるはず」のものを作っている場合が挙げられる。

■品質の種類
◆品質種別
狩野氏らによる研究では、品質は大きく4つに分類される。
・一元的品質：品質達成度と顧客満足度が比例する
・当たり前品質：達成しないと満足度が大きく下がるが、達成されても満足度は上がらない
・魅力品質：達成しなくても満足度は下がらないが、達成されれば満足度が大きく上がる
・無関心品質：達成度に関わらず満足度は変わらない

SPLEにおいてはまずコア資産の当たり前品質を徹底的に確保する。また一元的品質を各スケール（価格帯、品質水準など）で使えるようコア資産の対応範囲を広げていく。アプリケーション開発では費用や開発期間などの制約から当たり前品質の程度を決める。また個々のターゲットに合わせて魅力品質を付加する必要があるが、広く長く使われそうな魅力品質については別途コア資産化していく。無関心品質の内、内部品質については使い易さ、テストし易さ、再利用のし易さなど、開発者にとって重要な品質である。

◆SPLEの試験プロセス
試験プロセスはコア資産のプロセスとアプリケーション開発のプロセスの２つに分かれる。
コア資産の試験では、早期に品質を確保することが重要である。またアプリケーション試験で同じ試験をしないで済むよう、開発プロセス全体にとって効率的な試験プロセスと再利用可能な成果物（コア資産）を開発する。
アプリケーションの試験では、アプリケーション自体の品質確保と、コア資産を最大限活用することが重要である。
活用の際は、類似アプリケーション間の共通部分に関してはコア資産をそのまま使う。一部が可変の場合は可変部分をコア資産に反映してから使用する。アプリケーション固有の部分のみ新規に試験ケースを作成していく。

■今日から始めるプロダクトライン
◆PL化の進め方
・Partial SPLE：要求開発や設計などの資産から一部をPL化し、その後に範囲を広げていく
・抽出式SPLE：既存の開発成果物からコア資産を抽出し、その後に可変性の追加やコア資産の追加と保守を行っていく
・Partial ＋ 抽出式 SPLE：一部の資産を抽出式でPL化し、その後範囲を広げていく

コア資産の対象はソースコードの他にもモデルやアーキテクチャ、市場分析結果なども含まれる。ただし闇雲な多種対応には意味がない。事業が効率化するようにPL化する範囲を選択すること。
Partial SPLEに着手する際は、チーム内、部門内、全社など、どの範囲を目標にするかについて想定しておく。もしチームより広い範囲にPL化を進める際は、非エンジニアに対して技術用語・専門用語を使わずに技術的な話しを伝達できる説明力が必須になってくる。

■QA
Q：自社でもSPLEに取り組んでいるが、コア資産の見極めが難しい、どうやって抽出すればよいか？
フィーチャーモデル（類似アプリケーション間で、何処が共通で何処が可変なのかを表現できるモデル）だと具体的すぎて共通なところが見えない。どの抽象レベルで共通化するべきか？
A：それでもフィーチャーモデルを使いましょう。
共通箇所を見つける方法はトップダウンとボトムアップの2通りがある。ボトムアップでは変更要求仕様書や変更ログなどから変更が集中している箇所を特定し、可変部分を抽出する。トップダウンは事業面からフィーチャーモデルを構成し、稼働環境やドメイン特有の技術、実装で使うバリエーションなどを挙げていく。
一例としてエレベータ制御の場合、速度プロファイル制御に使われる様々な方式の技術の内、どれを使うかが可変性になる。

Q：標準的な部品の開発とそれを利用したアプリケーション開発を行っているが。これはPLと言えるか？
A：PLと言えるか分からないが、PLで使われているパターンの一つではある。PL成立の鍵は、現場からの知見やノウハウや変更要求などのフィードバックを標準部品の開発担当者が受け付けるかどうかである。

Q：コア資産化の対象を考えると、当たり前品質よりも自分たちの強みを重視したくなるのではないか？
A：今持っている強みはコア資産化する。これから作る強み（魅力品質）はいきなりコア資産化しようとすると手間取ることがあるので、最初はアプリケーションでの対応をお勧めする。

＜講義の感想＞
私の主な業務はソフトウェアテストなので、テストケースの抽象化、テストする機能とテストケースのセット作成、類似製品の不具合情報の活用など、まずは一人で進められる範囲でSPLEの考え方を導入したいと思います。