• S&Sの品質不良は時によって、企業存続のリスクにまで繋がることがある。
  ⇒自動車の急加速問題とされた一連の騒動で、売上・株価・リコール費用・信用等に大きく影響。
• 情報通信技術（ICT）の急激な進歩により、新概念のアプリケーションやシステムが生まれ、それらに対する品質向上のニーズが次々と出てきている。
  ⇒カーナビの迂回ルートに従うと、皆がそのルートに流れ、今度はそちらが渋滞する問題。
• 一方で、利用者の責任というのも重要視されてきている。
  ⇒いまやセキュリティソフトを導入するのは常識である。
• S&S利用の範囲が広がる中、一般市民やその他の利害関係者のリスクを考える必要が出てきている。（直接的な利用者のことばかり考えていてはいけない）
  ⇒東日本大震災における停電による信号機の停止。
  ⇒福知山線脱線事故における列車速度超過。
• リスク管理のプロセスとしても国際標準があり、PMBOK(R)やSEIなどが代表で国際的にも重要視されている。
• S&Sの種類によって、それぞれ重要視する品質特性は変わる。
  ⇒Interactive Consumer Software … 使用性、共存性
  ⇒Internet and Open Systems … セキュリティ、相互運用性
  ⇒Mission Critical Systems … 機能正確性、信頼性

• S&S品質の向上には次の6項目の対策が重要かつ有効である。
  ⇒組織として、品質向上技術戦略を確立し、その活用環境を整備し、組織的に対策を立て実行する。
  ⇒国際標準やJIS標準を参照し品質向上に役立てる。
  ⇒プロジェクト毎に、品質モデル及び品質測定法を用いて品質要求を明確に定義する。
  ⇒その定義に基づいて作り込むためのプロセスをデザインして実行する。
  ⇒テスト段階にて品質要求の優先度や重要度を考慮したテストケースを作る。
  ⇒問題発生に備えたリスク管理を考えていく。
• ソフトウェア（システム）品質とは、明示された状況下で使用されたとき、明示的ニーズ及び暗黙のニーズをソフトウェア製品（システム）が満足させる度合いと定義されており（SQuaRE 25010 品質モデル）、S&S製品に必要な品質要求は、品質モデルと品質測定量を用いて、品質特性及び品質副特性毎に定義するとよい。
• S&Sの品質は、内部品質、外部品質、利用時の３つの視点から、要求、測定、評価すべきである。
• システムの品質要求の実現には、ソフトウェアの機能要求に変換する必要のある場合が少なくない。
• S&S品質を向上させるための着眼点として、要求品質、プロセス品質、プロダクト品質、リソース品質、マネジメント品質が挙げられる。
• 常に高品質の製品を作る仕組みの構築として、例えば、SEI-CMMI、ISO/IEC 15504 SPA、ISO 9000シリーズなどを参考に活用すると良い。
• プロセスやプロダクトに関する国際標準があり、国際的にも重要視されている。
  ⇒組織能力・プロセスの評価・改善：SEI-CMMI、IEC/IEC 25504
  ⇒優秀なソフトウェア人材の教育・育成：ISO/IEC 19759（SWEBOK）、ISO/IEC 24773（ソフトウェア及びシステム技術専門家の知識・能力証明技術者の認証に活用）
  ⇒プロセス標準：S&Sライフサイクルプロセス（JIS X0160,X0170）、IPA/SEC 共通フレーム2013、ライフサイクルプロセス-リスク管理（JIS X0162）
  ⇒優れた技術・ツールの選択使用：ISO/IEC 14471 CASEツール（SC7/WG4）、ISO/IEC 19505 UML（SC7/WG19）
• S&S品質に関する国際標準があり、国際的にも重要視されている。
  ⇒プロジェクト管理の標準およびツール：PMBOK
  ⇒テスト技術：ISO/IEC 29119
  ⇒品質関連：品質マネジメントシステム（JIS Q 9000）
  ⇒S&S品質要求と評価：ISO/IEC 250nn SQuaREシリーズ

• SQuaREシリーズを作ったSC7/WG6は、1990年アメリカ・ワシントンDC会議で設立決定し、Title：Systems and Software Qualityとして、品質を高めるための標準を作ることを目的として設立した。
• SQuaREシリーズの狙いとして、ISO/IEC 9126シリーズ及び14598シリーズ標準の統合及び改定があり、1999年、SC7/WG6 金沢会議にて検討され、2000年SC7 Madrid Meetingに提案し、決定した。
• 標準品質モデル作業が1985年2月：SC7/WG3 ドイツ・ミュンヘン会議で開始され、品質を表す単語をKJ法要領で洗い出し、品質特性と品質副特性を作った。1991年：ISO/IEC 9126にて最初のモデルが出来上がって以降、何度かの統合改変を経て00年5月：マドリッド会議でSQuaREシリーズ化を提案し、承認を得た。
• ISO/TC97/SC7の歴史及び国際会議として、1974年 パリでのISO/TC97/SC7創設から始まり今日まで継続しており、日本でも過去何度か国際会議が開催され、2020年5月には日本（岡山）にて開催が予定されている。

• S&S品質の概念として、「明示された 又は 暗黙の必要性」を英語でどう表すかということで、"degree to which"、"ability of"、"capability of"が議論されている。S&Sの製品としての品質は"capability of"を適用し、ユーザビリティ、利用者の視点では"degree to which"で測ろうとしている。
• SQuaREシリーズの体系・構成とプロジェクトとして5つの部門から成り立っており、品質管理部門（ISO/IEC 2500n）と品質測定部門（同 2502n）と品質モデル部門（同 2501n）を中心にして、これらを品質要求部門（同 2503n）と品質評価部門（同 2504n）にて利用する構成となっている。また拡張部門として、ISO/IEC 25050~25099が用意されており、ISO 25051は品質認証制度（PSQ）の元として利用されている。また、ISO 25060~25066はユーザビリティのISO/TC159/SC4とSC7/WG28のJWGで作成されている。

• 品質モデルとは、品質特性を定義し、品質特性相互間の関係を示すモデルである。品質要求事項の仕様化として、定量的なクリア条件を品質特性毎に品質メジャーを使って要求定義する必要がある。
• 品質ライフサイクルモデルでは、現在使われているシステムに対して何等かの不平不満があり、こうあれば良いなというニーズ、そのニーズを分析して実現する内容が要求、すなわち利用時品質になる。それに対してどう作るのかを定義したものが外部品質、内部品質となる。外部品質はシステムとしてソフトウェアを動かした時のS&Sの行動に関する品質。内部品質はS&Sを動かす仕組みとして、システムアーキテクチャやソフトウェアアーキテクチャやプログラムコードを意味している。
• 現在の状態を望ましい状態に変えようとする際、実現するためにどういうシステムにしたら良いかという目標状態を先に決めてから提案システムをデザインしていくデザインアプローチと、現在のシステムを改善していく改善アプローチがある。
• 利用時の品質は人間のプロセスや機械系システムまでが対象にもなる。システムの利用時に対して、どういう利害関係者がいるか、配送に従事する人もトラックのドライバーも受け取る人たちも考慮する必要がある。
• 利用時品質モデルとしては、例えばリスク回避性の品質特性に対しては、システムがどういう行動するのか、経済リスク緩和性や健康・安全リスク緩和性などの品質副特性を考慮する必要がある。
• JIS X 25010 システム・ソフトウェアの製品品質のモデルとして、機能適合性や性能効率性、互換性、使用性、信頼性など品質特性を定義している。なお、ここでの使用性は、製品としての操作の単純さなどのcapabilityについて言っており、それと利用者がどう感じるかは別であるという点が、次の改定での論点となっている。
• ISO/IEC 25012 SQuaRE データ品質モデルとして、各品質特性に対して、データそのものを問題にする固有（Inherent）と、システムとしてDBMから得られるデータを問題にするシステム依存（System dependent）の2通りある。

• 測定できないものは、評価・制御・管理ができない。ただ、人間の感性を扱うのは難しいが、定量化するために様々な研究がなされている。
• 測定量には、基本測定量（Base Measure）として直接測れるものと、導出測定量（Derived Measure）として測ったものを何らかの関数にあてはめたものの2種類ある。例としてレビューをして見つけた欠陥数と、Kline当りでノーマライズした欠陥数の関係があてはまる。常に双方の測定量を考えて、情報ニーズとして適しているのか、繰り返し評価しても同じ結果が得られるのか、データ収集が容易であるかを考慮して品質測定量を決定していく。
• 測定方法には、主観的測定として人間の判断を含んだ定量化（フィギュアスケートの評点など）と、客観的測定として数値的な規則に基づいた定量化（アンケート調査による顧客満足度など）がある。また、直接測定として応答時間やモジュール内の欠陥数などと、間接測定として関数関係でKline当りの欠陥数などがある。
• 測定の尺度には、名義尺度として欠陥の分類、順序尺度として良いモジュールの順序、間隔尺度としてサイクロマティック数、比尺度としてコード行数などがある。
• 最終的な情報ニーズとして何を知りたいかが重要。情報ニーズに関連する特性として属性をあげ、属性をスケールに写像する測定方法をあてはめると基本測定量が得られ、測定の関数をあてはめると導出測定量が得られ、それを分析しモデルにあてはめると最終的な情報ニーズを満足する情報成果物が出てくる。
• S&S製品の品質は品質特性に分けられ、それに対応してさらに下位レベルの品質副特性があり、それに対応した品質属性に繋がる品質モデルの構造がある。その品質属性をQuality Measure Element（QME）として関数にあてはめた測定量に対し、総合評価・測定・分析を行っていく。
• 品質のゴール、何を知りたいかから始める技法としてGQM（Goal Question Metric）がある。
• 測定対象と測定技法の例として、S&S品質への影響要因には要員の経験や定義されたプロセスが評価対象となる特性例であり、またS&S内部属性には仕様書レベルが対象と考えられ、ソフトウェアはシステムとしての外部属性の対象であると言える。
• S&Sライフサイクルの各段階で利用可能な信頼性測定量は異なってくる。

• 要求には機能要求と非機能要求があり、非機能要求は品質要求と管理上の要求（価格,納期など）であり、SQuaREのテーマはこの品質要求にあたる。S&S品質要求定義は、ソフトウェア機能共有に反映すべきシステム品質要求と、設計・開発プロセスに反映する必要のあるS&S品質要求を考慮する必要がある。
• S&S製品には利用者を始め多様な利害関係者が関与する。例えば、ミッションクリティカルシステム（航空管制や原子力発電システム）では、利害関係者として一般大衆など、そのシステムの存在を知らないが問題が起きると甚大な影響を受ける者がいる。
• 利用者のニーズとは、製品を利用する際の、製品の効果に対する期待である。利用者とはシステムを直接・間接に利用する人を指し、一次利用者は直接操作、二次利用者は運用管理、間接利用者は出力情報を利用する人と定義している。製品利用の効果は、製品の機能と品質に依存し、また利用者のニーズは製品のアウトカムズをどう利用するかによって変化する。
• 多様な利害関係者が多様な製品へのニーズを持つ。それらのニーズを収集・分析・選別し、製品としての要求仕様へ転換しなければならない。システムとしての振る舞い、それに対するソフトウェアの振る舞いを利害関係者の要求事項に分けていく。それを製造する人に分かる様な形式で記述するとS&S要求事項・要求仕様書になる。
• S&Sの要求分析は、一般に問題の規模と複雑さが非常に大きく難しい。また、環境変化により要求も変化し続けるため、変化の予測および対応を考慮する必要がある。利用者と開発者のコミュニケーションは難しく、互いに異なる専門知識を前提として異なる言葉を使用する。また利用者は真のニーズを知らないことがある。
• 外部品質要求は、システムとしての振る舞いを考え、3グレード程度の重要度によって品質特性に優先順位をつけて仕様化するとよい。
• 内部品質要求は、設計レビュー、コードレビューの際に、チェックリストなどを用いて評価可能でなければならない。またプロセスデザインにて、レビュープロセスを作って、どれくらい時間をかけ、そのチェックリストをどう作るかを考慮しなければならない。

• 品質は品質要求に対応したアーキテクチャ設計、コンポーネント設計、開発、などのプロセスで作られる。品質の確認はデザインした品質確認、評価プロセスを実行して行われる。
• プロセスを詳細化するために、機能モデル毎の要求事項に対する作業項目をデザインする。例えば、使用性要求に対してであれば、適切度認識性、習得性、運用操作性、UI快美性などに分けて、それぞれについて実現プロセスをデザインしていく。

• 品質の確認はテスト及び評価プロセスで行われる。従って、品質要求をレビュー及びテストプロセスに反映することをプロセスデザインで定義しておく。
• 品質要求事項毎に品質を測定・評価・改善するために、品質要求事項に対応した品質測定量の選定が重要である。
• 品質要求事項の優先度を考慮してテスト・評価するために、スタティックテスト、ダイナミックテスト、フィールドテスト時に、それぞれ何をテストすべきか品質要求に対応したテストケースを作る必要がある。
• 評価要求を作成（評価要求の確立）し、それに従って何を対象にして評価するのかを設計し、評価対象の測定量選択、測定量の判定基準を定義（評価の明示）し、さらに評価を実施して結果を審査する必要がある。
• 品質評価基準の設定として、品質要求をもとに重要度の高いものから重点的に評価プロセスをデザインし実施していく。また品質副特性に対応する品質測定法（外部、内部）を設定する必要がある。
• JIS X25040-Annexでは、評価レベルを定義することを提案している。但し、評価レベルの決定にあたっては、品質問題がシステム全体で見る場合と、システム内の特定機能に特化して見る場合で異なり、必ずしもシステム全体で評価レベルを変えるのではなく、システムのアーキテクチャをベースにしたシステムコンポーネント毎に品質要求レベルを考えて決定する必要がある。
• 測定結果をレイティング（評定）して、予め定めたレイティングレベルに照らし合わせて評価結果（合格／不合格）を決定する。
• 総合評価として、測定及び評価結果を品質特性及び副特性毎に要約する。結果をグラフなどで可視化する。

• 国際標準刊行済み／JIS化：
  　TS 25011:SQuaRE ：新規、JIS化予定なし。サービス品質盛り込む。
  　ISO/IEC 25022:SQuaRE：JIS化作業中。
  　ISO/IEC 25023:SQuaRE：JIS化完了、発行済み。
  　ISO/IEC 25024:SQuaRE：JIS化完了、発行済み。
  【開発・改定作業中】
  　ISO/IEC 25020-2007:SQuaRE
  　ISO/IEC 25030-2007:SQuaRE
  【新規提案・改定準備中】
  　ISO/IEC 25010-2011:SQuaRE
  【参考】
  　ISO/IEC 25045-2010：JIS化予定なし。テクニカル文書として参考文献。
• ISO/IEC 25010:SQuaRE 品質モデルを3つのパート（品質モデル外観、プロダクト品質、利用時品質）に分冊化予定。
• 対象製品の利用者、利害関係者を拡張整理している。利用者（一次,二次）、間接利用者、一般市民。
• 主な課題として、SQuaREシリーズの対象、ステークホルダの分類、品質も枠組み、表現の統一などが挙げられている。
• 品質モデルの対象と品質測定量として、Hardware&Communication FacilitiesとSoftware ProductとDataを含めてICT Productに含める方向で合意してきている。それにUserとRelevant Environmentを包含してInformation Systemとして表して、その上位にICT-System（System of Systems）として多くのInformation Systemを包含すると共に、MachineやBuildingなども含めてその影響を考えようとしている。

• ISO/IEC 9126を作る過程で品質を表す単語をKJ法要領で洗い出しをされた際、欧米人はボトムアップで作る・機能的に作るよりは、トップダウンで作る方が好きなのかと考えているが、ポストイットなどで作り上げるKJ法 made in Japanのモデルに反発はなかったのか？
  →誰も反対しなかったし、紙やセロテープを使って一生懸命に皆やっていた。彼らにも代々培ったモデルはあったが適用できないので、自分たちでもっといいものを作ろうと前向きで、誇りをもってやってくれた。


• ISO/IEC 25010の改定作業中ということは、25022と25023の改定の可能性があると認識を持っておいた方がよいのか、それとも改定される見込みがなくMeasurementに関してはある程度の参考レベルになるのか、どちらの認識をお持ちでしょうか？
  →現在の傾向は、大体3つに分ける方向で了解されている。25022などは多少影響を受けるとは思うが、それほど個々の品質特性や副特性をバラバラ変えようという話ではない。利用者の利便を考えて3分冊すると共に、一部問題になっているところを書き直すという程度なので、Measurementに対しては大きな影響はないとの認識。

• マネジメントの考え方として、これまでの理論や客観に基づく“MBO（Management By Objectives）：目標管理のマネジメント”だけでは個人や組織が動かなくなってきており、主観や直感に基づく“MBB（Management By Belief）：思いのマネジメント”の重要性が増している。
  ⇒「考える現場を取り戻すためには、この主観をきちんと経営の中に位置づけることが必要だ。」
  　（一條和生、徳岡晃一郎、野中郁次郎：「MBB：“思い”のマネジメント」東洋経済新報社より）
  ⇒「論理によらない直感的な選択によって出された結論というのは、だれにも真似ができない。」
  　（福井謙一《1981年ノーベル化学賞受賞》：「哲学の創造」PHP研究所より）
  
  ⇒「客観的な知識は、ある種の目的を達成するための、強力な道具を提供してはくれますが、究極的な目標そのもの、およびそれに到達しようとする憧れは、他の源泉から生まれねばなりません。」
  （アルベルト・アインシュタイン：「晩年に想う」講談社文庫より）
• コンセプチュアル思考とは、そういった主観、直感に関わる部分を深く考え、掴む思考方法である。
• 哲学者カントが提唱した「知情意」の３つの心の働きで言うと、「意」に位置付けられる。
  ⇒知：ロジカル思考（鋭く分析する。賢く判断する。早く処理する。）
  ⇒情：デザイン思考（気持ちをくんで考える。五感豊かに考える。「美しい／快い」を表現する。）
  ⇒意：コンセプチュアル思考（深く洞察する。綜合してとらえる。意味を掘り起こす。）
• 「知」や「情」にあたる思考は、欧米で発展し、体系化されてきたが、「意」にあたるコンセプチュアル思考は、欧米でもまだ体系化できていないものになる。
• コンセプチュアル思考（スキル）の重要性は、ロバート・カッツ（*1）やダニエル・ピンク（*2）により唱えられてきたが、それが具体的に何かは述べられてきていない。
  （*1）Skills of an Effective Administrator（1955年）
  （*2）ハイ・コンセプト（2005年）
• 私が考えるコンセプチュアル思考とは、概念を起こす思考であり、観／ビジョンをつくる思考であり、意味／志を掘り起こす思考である。
  
  ⇒例えば、自分の生きる意義だったり、働く意義だったりを考え、本質を内面で掴むことがそうである。これは、ロジカル思考やデザイン思考では答えが出ない。
• コンセプチュアル思考の思考プロセスを「πの字思考」と呼んでいる。
  抽象化（↑）概念化（→）具体化（↓）の3つのプロセスによってπの字の形を描くからである。
• コンセプチュアル思考には4つのスタンスが必要だと考えている。
  「根源を見つめる」、「全体を観る」、「抽象と具体を往復する」、「客観を超えて主観を持つ」の4つである。
  
  ⇒客観を超えるというのは、客観は大前提だがそれだけでは不十分であり、そこを超えたところで研ぎ澄ませる主観を持つという意味である。
• コンセプチュアル思考の基本スキルには、定義化、モデル化、類推、精錬、意味化がある。
  ⇒今日の講義では、定義化、意味化にスポットをあてる。
• 定義には、客観的な定義と、主観的な定義がある。
  
  ⇒例えば、「事業とは○○である」という定義には客観的なものから主観的なものまでさまざま存在する。
  最も客観的な定義は、事業とは「一定の目的と計画とに基づいて経営する経済的活動」であるという、広辞苑<第六版> の定義であり、主観的な定義は、事業とは「人づくり」である（松下幸之助）など、人によって異なるものである。
• 客観的な定義（≒社会的通念）も、必ずしも固定的なものではない。
  ⇒「情けは人のためならず」という言葉は、「自分のためになる」から「その人のためにならない」へ変化した。
  
  ⇒客観的な定義を意図的にずらして（誘導して）、独自の概念を生み出すことは、商品やサービスの企画開発において有用なことである。
  （極北地の人に冷蔵庫を売る際、「冷蔵保管するもの」から「保温保管するもの」に定義を変えて成功した）

～ミニ演習：「成長」を主観的に定義する（πの字思考の実践）～

【抽象化（↑）】
①「自身のこれまでの成長体験、成長エピソード」「他者を通して見てきた人が成長・変化する姿」を思い浮かべる。
②「成長とは何か」「成長についての解釈」を自分なりの言葉で表す。
　※例）成長とは、「３方向に伸びること－広がる・高まる・深まる」である。
　※例）成長とは、見えなかったものが見えるようになることである。

【概念化（→）】
③「成長とはどういうものであるか」を図や絵で表す。

【具体化（↓）】
④成長を持続的に起こすための行動習慣としてどのようなものが考えられるか、３箇条にする。
　※例）何事も運営する側に回る。
　※例）リスクを負うことを怖がらず行動する。

• 本演習で定義した「成長」に対する「観」は、具体化した行動習慣を実践し、そこから気づきを得て、πの字思考を繰り返すことによって醸成される。
• 普段からこういった思考を繰り返して自分なりの「観」を醸成し、人としてぶれない軸を持つことが大事であり、そうでない人は、漫然とした仕事しかできず、漫然としたキャリアにしかならない。

～質疑応答～

• πの字思考の具体化のプロセスが、なかなかすんなりとできるようには思えないが、実際はどうなのか。
  
  →おっしゃる通り、すんなりとはいかないだろう。絵図化から行動習慣への過程で何度か紆余曲折を経て、現状の課題や問題点をしっかりと分析してから、行動に落とし込んでいく必要がある。

• キャリアを作る要素は、私は３層で捉えていて、「観・マインド」がその最下層にあたると考えている。
  ⇒1層（知識・スキル・資格・人脈）…have（何を持つか）
  ⇒2層（行動特性・態度・習慣）…do（どう行動に起こして、成果を出すか）
  ⇒3層（観・マインド）…be（どうあるべきか）
• 自分がどこに向かって進んでいくか、どのように仕事をするか、理想形はどっしりとした３層の「観・マインド」があり、その上で能力が生かされ志・目的の軸が力強く立ち上がり伸びているのが望ましいが、現実の多数はそうでなく、「観」がうやむやで１層、２層の能力だけで何となく仕事をしているケースが多い。
• 急に「観・マインド」を養おうとして、成功法・ハウツー本を読んだところで、自分なりの「観・マインド」に落とし込めていないため、根本的な解決にはなりにくい。
• 目標の先に目的がちゃんとあるかが大事。現実は損得の外発的動機に心が動かされ、数値目標に追われ目標疲れにおちいることが多い。目的を持って動いていると、内発的動機が生まれ、深く強い内発の力が湧き、困難に耐える力、乗り越える力、物事をとらえる次元、その意味に共感する人を呼び寄せるなど、そういったところに変化が生まれてくる。
  ⇒レンガ積みに対し、「何をしているの？」＞1人目「レンガを積んでいる」
  　目標：1日に●個レンガを積む。／目的：特にない。
  ⇒レンガ積みに対し、「何をしているの？」＞2人目「金を稼いでいるのさ」
  　目標：1日に●個レンガを積む。／目的：食うため。
  ⇒レンガ積みに対し、「何をしているの？」＞3人目「大聖堂を造っているんだ！」
  　目標：1日に●個レンガを積む。／目的：後世に残る建設事業に加わるため。


• 目的と手段（目的を実現するための要素・資源・行為・方法）の組み合わせは相対的である。
  より大きな目的が生まれるごとに、今までの目的は手段に替わっていく。
  これが繰り返されて高みを目指すのが理想だが、現実の企業においては、逆に低くなっていくケースが見られる。（数値目標という手段だったものが目的に落ちてノルマ化していく）
  ⇒《レベル1》目的：テストでよい点を取る。／手段：算数を習う、漢字を覚える。
  ⇒《レベル2》目的：希望の大学に入り、好きな研究をする。／手段：テストでよい点を取る。
  ⇒《レベル3》目的：専門を生かした就職をする。／手段：希望の大学に入り好きな研究をする。
  ⇒《レベル4》目的：仕事経験を積んで起業できる力を磨く。／手段：専門を生かした就職をする。
  ⇒《レベル５》目的：社会貢献事業をして人びとに役立つ。／手段：仕事経験を積んで起業できる力を磨く。

～ミニ・ディスカッション：お金は働く目的か？利益獲得は事業の目的か？～

①働く目的が「金を得るため」という考えに対し、賛成か反対か。
②私自身は働く目的をどう考えているか。
③なぜなら？

• 答えは人によって変わり、正解はない。（「観」が異なる）
• ドラッカーは、利益は企業の目的ではなく、事業を継続・発展させていくための「条件」であると言っている。
• 松下幸之助は、利益は「企業使命達成に対する報酬」であると言っている。
• 自らの存在意義を「提供価値」で考える必要がある。生命を維持する＝処し方を問う具体次元（技術・稼ぎ）の先に、存在を開発する＝在り方を問う抽象次元（ビジョン・想い）に向けて、最終的に成し遂げたいこと＋それをやる意味：提供価値をコンセプチュアル思考で見出してゆく。

～ミニ・ディスカッション：私の提供価値宣言、我が社の提供価値宣言～

①私は仕事を通し、「　　　」を売っています（を届けるプロでありたい）
②我が社は事業を通し、「　　　」を売っています（を届けるプロ集団でありたい）

• 保険会社のライフプランナー：「経済的リスクヘッジによる安心」
• 自動車メーカーの開発者：「快適な移動空間／道具」
• レストランのシェフ：「幸福な舌鼓の時間」

• 絶え間ない変化の中で何を変え、何を変えないか。
  製品やサービスの外形要素は時代の流れとともに変えていかざるをえないが、その提供価値は不変なものがある。
  
  ⇒例えば、オーディオ製品では、カセットテープ、光学ディスク、半導体と外形を変えてきたが、音楽を楽しむライフスタイルを提供するという価値は変わっていない。
• プロジェクト（集合離散型の協働形式）を渡り歩く時代において、自分の働く環境も変わっていく。

• 「観・マインド」を養うように働きかけたいが、同一現場に長くいるような人の場合、今までの習慣が強く根づいていて、思考が凝り固まってしまっている。そういった人たちに対してはどのようなアプローチをしていけばよいか。
  
  →社外や組織外のプロジェクトに参画させて新しい人と接触させる、大きな仕事を丸ごと任せるといったことをすると、刺激を受けて「観・マインド」がほぐれるケースがある。

• 実践の言葉の定義
  ソフトウェア工学におけるプラクティス（Practice）とは、作業や設計に使用される効果的な技法／手法や、時間をかけて多くの人に使用されてその効果が証明されているものを言う。一方で、よく似た言葉にパターンがあり、ソフトウェア工学におけるパターン（Pattern）とは、色々な作業や設計において、比較的共通に発生する状況、又は共通によく使用されるノウハウのことを言う。また、パターンのうちダークサイドに陥るものをアンチパターンと呼ぶ。
  ⇒“プラクティス”と“パターン”の関係性イメージ
  　［モデル（幹細胞）：方法論］ ［プラクティス：方法／技法］ ［パターン：ノウハウ（プチテク）］
  　 　理論的←------------------------------------------------------------------------------→実践的
  
  ⇒“実践”の一般的な意味は、主義・理論などを実際に自分で行うこと（Goo辞書より）とある。XDDPやUSDMなどの理論があれば一度実際に使ってみることと理解している。
  ⇒実践と理論の関係を言い表す言葉として、「実践なき理論は空虚であり、理論なき実践は無謀である」（ピーター・ドラッカー）があるが、考えるには難しいが感覚的には分かる。
• 理論と実践は、対極関係として語られるが、理論と実践の間をスムーズに繋ぐのが“練習”であると考える。
  　理論　⇒　練習（訓練）　⇒　実践（本番・実戦）
• “実践”ではなく“実行”ではダメ。実行は失敗を容認する（ダークサイド）が、実践は成功を目指す（ライトサイド）活動と考える（イメージとして）。
  失敗が許されない特に医学（医療現場）の世界では、医学知識⇒練習（研修）⇒実践、の流れが必要で、本番で最高の能力を発揮するために、理論と実践の間には必ず訓練（練習）が必要である。
• Doctor Xの大門未知子が失敗しない理由は何か？
  
  ⇒起こりうるすべてのケース、障害を予想して完ぺきな準備をしていたから。ただ大門未知子も想定内と想定外の領域を持っているはずで、想定外との戦いをしている。

• 不具合、不祥事が起こる度に使われる言い訳として、“記憶にございません”、“想定外でした”が常套句だが、物事には、「想定外」で済まされないものがある。容易に想定できるものも「想定外」といって逃げる人が多い。このような人たちは反省しないので、同じことが繰り返される（再発）。
• 想定外の例
  ⇒四国高松市　琴電高松築港駅　駅真横の高松城のお堀にいる魚は鯉ではなく鯛。お堀が海。
  ⇒アメリカ　想定外の2.7m、470kgの巨大イノシシが捕獲された。
  ⇒中国　常識を外れた過積載のトラック。
  ⇒インド　常識を外れたバケツを過積載しているオートバイ。
  ⇒日本　東電　福島第一原発事故　電源喪失に備えた電源設備（2系統）が地下に設置されており、津波で水没。
• “想定の範囲（想定）”と“想定の範囲外（想定外）”の中間にある“想定すべき範囲（予見可能範囲）”は想定外といえるのか。製品に問題があったときの裁判所の考え方で言えば、本来の使い方（想定）に対して、誤った使い方が予見可能範囲であれば想定外とは言えず、そこで発生した問題は想定不十分となる。
  　想定外　＞　予見可能範囲（予見範囲含む）⇒　そこで発生した問題　＝　想定不十分

①実践は理論通りにはいかないことが多い

⇒“課題”に対する“結果（答え）”を導き出す際、何等かの“理論（方法論）”を使って“実践”することになるが、この実践には必ず“制約”条件を伴っている。実践とは制約の中で成り立つ答えを導き出すことである。

⇒例）理論：NOT回路（反転）
実践：理論通りギリギリの設計では市場で不具合が出る。
リアルな世界では遅れ／バラつき／ノイズがあり、非機能要求の制約を盛り込んだモノづくりが必要。

②矛盾を解決することがエンジニアリング
⇒作用すれば反作用がある。薬には副作用がある。陽が当たれば、陰になる所がある。
⇒例1）愛知県田原町　表浜（小島海岸） 消波ブロック
　砂浜の浸食→消波ブロック設置→海ガメ産卵の妨げ→海ガメの減少（絶滅の加速）
　砂浜の浸食→放置（不作為）→砂浜の浸食の拡大→海ガメの産卵場所の減少→海ガメの減少
⇒消波ブロックを設置しても設置せず放置しても、いずれも海ガメ減少に繋がるジレンマ。
⇒消波ブロックを全面設置から部分設置に変え、砂浜浸食の抑止と海ガメ産卵場所確保の双方を両立。
⇒Sweet Spot Thinking（SST）
　メリットとデメリットの折りあいをつける。
　　許容範囲　＞　最小工数　へ近づけて行くシステム思考をする。
⇒例2）愛知県田原町　表浜（小島海岸）堆砂垣（たいさがき）
　砂浜の浸食→堆砂垣（たいさがき）部分設置⇒砂浜浸食の抑止と景観確保の双方を両立。

⇒例3）ネックストラップの事故防止装置
強い力が加わると事故防止パーツが分離してストラップが外れる仕組みであるが、強度が強すぎると人命に関わり、弱すぎるとセキュリティに関わるという、相矛盾する問題を解決。

③要求はある意味制約である（特に非機能要求）
⇒要求には機能要求と非機能要求がある。
　機能要求：製品やサービスが遂行すべき働き（機能）に対する要求
　非機能要求：製品やサービスが遂行すべき働き（機能）の良さや制約に対する要求
　例）機能の発揮方法、性能、信頼性、使い勝手など
⇒非機能要求が決まらないとアーキテクチャ（手段の基本構成）が決まらない。

例）要求：地点Aから地点Bに行きたい
機能要件：人と荷物を乗せて移動する
非機能要求：どこまで？（移動距離）、いつまで？（移動時間）、いくらで？（移動コスト）、安心できる？（安全性）
アーキテクチャ：移動手段　空を飛ぶ（飛行機）、海を渡る（船）、陸路を走る（車）

④実践には複眼を持つことが大切　－複眼思考の勧め　複眼は福眼に通ずる－
⇒あるワークショップから「テスト」における課題とその解決方法について議論して分かったこと。
（1）テスト工程の中だけで全ての課題の解決が困難である。（プロマネ、上流工程の課題が多い）
（2）開発プロセス全体を対象とする複合視点、システム思考での課題解決が必要である。
（3）「総合診療医」のような製品開発全体を診療する「総合エンジニア」が必要である。
⇒以下のような背景がある。
　ソフトウェア開発の大規模化・複雑化→分業の促進（自分の担当しか分からない）→狭い範囲での解決困難化
※ありきたりの常識や紋切り型の考えに囚われずに、広い視野から多視点で物事を捉える必要がある。

⇒総合診療医（ドクターG）とは、病気を心身から全体的に診療する医師。病気の予防にも携わる。患者の特定臓器に着目するのではなく、全体的な健康問題に向き合って治療を行う。
診療　＝　診察　＋　治療
診察：医師が患者の体を調べて病状・病因などを探ること←課題形成
治療：病気やケガを治すこと←課題解決

⇒総合エンジニアの提言：総合エンジニアとは、製品開発における特定のプロセス（技術）に着目するのではなく、開発プロセス全体を複眼で捉え、システム思考（※）で課題解決を行うエンジニア（エンジニアGと呼ぶ）。
※システム思考と、物事のつながりを構造として捉えること。
CO2増加⇒地球温度上昇⇒北極の氷現象　－因果律（時系列的連鎖）－

⇒どんな装置でも得手／不得手があり、いくつかの装置を組み合わせて用いることで補完している。
例1）自動運転車
　　カメラ、ミリ波、ライダー、クリアランスソナーといった複数のセンサーを組み合わせて実現する。
　　（同じセンサーでも搭載場所によって使い方や用途が違ってくる）
例2）ガン検診
　　レントゲン、CTスキャナー、PETを組み合わせて診断する。

⑤実践力　－ある制約条件のもとで、価値を生み出す力－

⇒実践の6W。6ワークで、価値（Value）を生み出す。
(1)ヘッドワーク：よく考えて行動する。（但し、タイミングを外すな）
(2)チームワーク：チームを組む。（一人でやれることには限界がある）
(3)フットワーク：やると決めたら即行動する。
(4)ネットワーク：外部の情報網、支援網を活用する。
(5)フィールドワーク：問題は現場で発生している。（`現地`に行き・`現物`を見て・`現実`を知る）
(6)不惑：迷わない。（一度決めたことはやり遂げる）

⇒不惑については、「やりたいこと」、「やるべきこと」、「やれること」の関係性を識別し、どう折り合いをつけるかが大事となる。目的「やるべきこと」と現状「やれること」の差のGAP、「やるべきこと」と「やりたいこと」のベクトルのGAPの認識が必要。

⑥アンチパターンは実践のポイント
⇒我々の周りに潜在しているアンチパターンを切り出して、戒め・警句、改善のポイントとする。

⇒例）「憲章炎」患者の実例
ある会社の機能安全担当者からの質問で「アジャイルプロセスの採用で困った」こと。
アジャイルプロセスの採用が決定→アジャイルではドキュメントは書かない（※1）→機能安全ではアカウンタビリティが重要→エビデンスが必要（※2）

⇒（※1）と（※2）で矛盾が発生。アジャイル憲章は、「ドキュメントを書かなくてもいい」とは言っていない。必要なドキュメントは後になっても必ず作るのが正しい。
名称：憲章炎（けんしょうえん）
内容：アジャイル憲章を正しく理解していないこと。
対策：ダークサイドに落ちた人にアジャイル憲章を正しく教える。

欧州でのプロセス実装事例

⇒LLD（Low Level Design）にアジャイル開発を適用している。
HLD（High Level Design）は古典的な「反復型開発モデル」のまま。開発者をアーキテクト（HLD対応）、設計者（LLD対応）、テスターに区分している。
アーキテクトが設計者の仕事の管理をしている。

⇒ツールによる設計支援が充実している。
ツールの中で全ての仕事をしている。ツールが統合されて、すべてのタスクをカバーしている。
ドキュメントを作成する必要がない。必要なドキュメントはツールが吐き出してくれる。
但し、過度なツール依存は別のリスクを持っており、ツールが止まれば全てのSW開発がストップすること、ツールのエキスパートチームが日々ツールの保守・改良をする必要がある。

プロセス改善あるある“8”

⇒製品開発の5大リスク（PASSO）。
Process：製品開発プロセス能力の要求に対応しなければならないリスク。
AT：Advanced Technology：人口知能（AI）、機械学習などの先端技術の導入によるリスク
Safety：機能安全の国際規格ISO26262対応を充分な体制を構築し満足しなければならないリスク
Security：セキュリティがセーフティに大きく影響を与えるリスク
OSS（COTS）：OSSのライセンス違反やOSSの選定を誤ったことに対する訴訟リスクや製品の改修リスク

⇒Processは他の4つの基盤技術であり、その整備が肝である。不完全な開発プロセスのもとは、設計活動はうまくいかない。

⇒プロセス改善の8つのアンチパターン（A-SPICEをベース）
プロセス改善がうまくいかない理由には多くの原因が考えられるが、特に目立つ共通の8つのアンチパターンを紹介する。

（P.1）視野狭窄
症例：A-SPICEの適用範囲の誤解。
症状：プロセスの構築と改善活動が不十分なのでOEMによるプロセス監査の準備は間に合わない。
　　　システム／ハード／ソフト間の連携した活動が不完全である。

原因：A-SPICEはソフトウェアのみに適用されると誤解している人が多い。特にシステム技術者。
システム／ハード／ソフトの各ドメインが個別最適活動をしているため、製品（システム）として品質保証するという意識が希薄である。

処方箋：A-SPICEの”plug-In” conceptを正しく理解する。

（P.2）レベル崇拝
症例：プロセス改善活動の目的がプロセス能力レベルの認定
症状：認定されたA-SPICEの能力レベルより実際のプロセス能力のほうが低い。
　　　組織の標準プロセスが開発チームの現状と合わない。
原因：目標のプロセス能力レベルを取ったら、プロセス改善活動を止める。
　　　プロセスは定義された時から陳腐化する。（いつかテーラリングでは吸収できなくなる）
処方箋：開発環境の変化に対応するために、継続的なプロセス改善活動を可能とする仕組みを作り運用。
　　　　レベルの取得は手段であって目的ではない。プロセス改善の目的は、設計の品質と生産性の向上である。

（P.3）支援過多
症例：一方的支援と一方的依存

症状：改善スタッフは開発チームにとって過剰又は不十分などの不完全なプロセスを開発チームに提供。
改善スタッフから提供されたプロセスを遵守しても、設計の生産性と品質向上が難しい。

原因：改善スタッフは、開発チームの実情を考えることなく、開発チームに対してプロセス改善活動を一方的に支援している。（一方的支援）
開発チームは「改善スタッフがプロセス改善活動の担当である」と考えているので、開発チームは自主的にプロセス改善活動をすることがない。（一方的依存）

処方箋：開発チームはプロセス改善活動の主体でありEPGは開発チームのプロセス改善活動を支援するものであると認識すること。支援のための重要な観点は自発性を育てること（自分で考えて行動することが大切）。

（P.4）“why”の蒸発
症例：ルールの意図やチェックの目的の欠落

症状：ルールやチェックリストの中に、なぜこのルールが存在しているのか、またなぜこのチェックをしなければならないのか、その理由が理解できないものがある。これが、不十分なチェックやルール遵守を誘発し、品質低下の一因となっている。

原因：組織標準やチェックリストには、ルールやチェック項目（What, How）が記述されている。しかし、ルールやチェック項目の存在理由（why）が記述されないことが多い。また文書を簡略化（洗練）すると、後で「なぜそうなったのか」が分からなくなる情報欠落のリスクがある。
処方箋：管理のための組織標準やチェックリストに、ルールやチェック項目の存在理由（why）も記述すること。後で保守メンテできるようにする。

（P.5）PPT／EXCEL症候群
症例：開発ツールがEXCELに偏重し過ぎである

症状：構成管理、変更管理、問題管理、トレーサビリティ管理に多くの工数が必要であり非効率である。また、ミスが発生しやすいので信頼性が低い。

原因：EXCELが利便性の高い専用ツールの代わりに、管理ツールとして多く使用されている。したがって、管理が属人的になっている。

処方箋：管理のための専用ツールを使用して属人性を廃する。WORD（正式文書）／EXCEL（表計算）／PPT（プレゼン）の本来の使い方を理解して利用する。属人的であることがリスクであることを認識し、ツールを使っていないこと自体、非効率かつ作業品質が悪い証拠である。改善がうまくいかない理由として、十分な装備・ツールを与えずにPPT／EXCELだけで無理なルートを綱渡りしている。

（P.6）ノウハウの蒸発
症例：アウトソーシングへの過度な依存

症状：設計者の設計スキルやノウハウが低下するので、設計変更や問題が発生した場合、設計者はそれに対応できなくなってしまう。

原因：設計をする機会が減少するので、スキルやノウハウが蓄積されない。特にアウトソーシングの多重化と“丸投げ”が良くない。

処方箋：1）組織の取得戦略（内製／外注の判断基準）を定義する。
　　　　2）外注先を管理し、“丸投げ”をしない。丸（○）投げは、“バツ（×）投げ”。
　　　　　　アウトソーシングはコントロールされ、かつ管理されなければならない。
　　　　3）アウトソーシングの多重レベルを制限する。
　　　　　　多階層になるほどノウハウが蒸発するので品質コントロールが難しくなる。

（P.7）テーラリング不全
症例：テーラリングが不完全（うまくできていない）

症状：人によってテーラリング方法がばらつき、テーラリングされたプロセスのタスクに過不足が発生し、プロセス品質が安定しない。

原因：テーラリングガイドラインが不十分（又はそれが存在しない）、又はテーラリングの理解不足。

処方箋：1）テーラリングに対する正しい理解を持つこと。
テーラリングとは、プロジェクトによって仕事の内容、制約条件が違うので、製品特性及びプロジェクト特性をパラメータとして、テーラリングガイドラインに従って、組織の標準プロセスをプロジェクトに実際に適用するプロセスに変換することである。

　　　　2）十分なテーラリングガイドラインを定義し、運用すること。
プロジェクト毎の勝手なテーラリングを許すと、プロセスの管理を難しくする。テーラリングガイドラインを用いて、テーラリングの管理に制約を設ける。

（P.8）部分最適
症例：機能間協調の乱れ
症状：手戻りや不具合の発生による、製品開発の開発効率や品質の低下。

原因：システム／ソフトウェア／ハードウェアの設計間の連携した活動が不十分（マネジメント層がマネジメントしていない）で、各々が自己中心的な活動をしている（部分最適）。

処方箋：1）システム／ソフトウェア／ハードウェアの各設計部署間の役割分担の明確化、
及び必要十分な組織間インターフェースの確立。（例えば合同の進捗会議や合同の検証活動の充実）
バラバラな活動は開発効率の悪化と品質の低下を招く。

　　　　2）システム設計／ソフトウェア設計／ハードウェア設計間の統括管理の　実施（全体最適）

　⇒あなたはどの世界に住んでいますか？

[天上界：ボヤすら起きない] [人間界：ボヤで済む] [修羅界：火消しで何とか鎮火] [地獄界：そこら中 火の海]
品質リスクLow←--------------------------------------------------------------------------→品質リスクHigh

プロセス改善は状況（住んでいる世界）によっては有効とは限りません。状況によっては外科手術も必要です。
1)プロセス改善は体力の増進に相当します。
　状況を良く見定めて、適切な対処をすることが大切です。
2)プロセスは定義された時から陳腐化が始まる。
　継続的なプロセス改善をして、プロセスの老化を防止しよう！
　この時にプロセス改善のアンチパターンが役に立つでしょう。
3)アンチパターンは他にもたくさんあります。
　アンチパターンに気を付けて、継続的改善活動を推進してください。

SQiP研究会「派生開発」分科会（旧第６分科会）

25SQiP（2009年）~32SQiP（2017年）の8年間、派生開発における課題形成力と解決力の育成の場として活動。

⇒派生開発の様々な問題を取り上げ、その解決策を考案する。
派生開発における問題として、変更箇所、変更の影響の特定に起因する問題が多い。
活動の進め方として、以下の手順で課題形成と課題解決を行う。
メンバーの抱える問題や経験の整理→共通課題の明確化→解決方法の考察→解決方法の効果の検証

⇒問題解決のために、XDDP・USDM・PFD・論文思考 などの手法を効果的に活用する。
「XDDP」機能追加と変更を異なるプロセスで対応する（追加機能要求仕様書、変更要求仕様）
「USDM」要求に理由を付けて仕様を階層構造で表現する
「PFD」多様な要求を満たすための合理的なプロセスを設計する
「論文思考」論文とは課題形成／解決の一連の過程とその成果を論理的に文章として纏めたもので、これをフレームワークとして課題形成と課題解決を行う

⇒8年間の活動成果として、
研究員数：75名、報告書：18件、最優秀賞：6件、優秀賞：3件、SQiPシンポジウム採録7本。

論文構造を活用した課題解決方法

論文を書こう。論文構造を活用した課題解決方法を提案する。

⇒論文とは？
　論文と聞くと壁が高くて登れないイメージがあるが、階段があれば登れるのではないかと考えた。
　論文の定義「課題形成と課題解決の一連の過程とその成果を論理的に文章としてまとめたもの」
　→論文の章・節構造が階段の役目を果たせるのではないか。
　→論文を書きながら課題形成・課題解決することができる。

⇒課題形成／解決モデル（WH-2Why）
　問題と課題の違いは何か？
　　問題：現状とあるべき姿との間にあるギャップ。現在発生している好ましくない状態、不都合のこと。
　　課題：問題（ギャップ）を解決するために取り組むもの。目的を達成するために、解決すべき問題。
　　現状 → 現状の把握 → 問題（抱えているもの） → 課題の選定 → 課題（解決すべき問題）

　　課題形成とは：現状抱えている問題の中から、課題を決定すること。
　　課題解決とは：課題に取り組み、ゴールを達成すること。

課題形成／課題モデル（WH-2Why）とは、課題形成／解決をWhat, How, Whyでモデル化し、起承転結をマッピングしたもの。
課題形成：「起」現状抱えている問題の中から
　　　　　「承」解決すべき問題（What）←何故その課題なのか？（Why）
課題解決：「転」具体的な解決方法（How）←何故その方法なのか？（Why）
　　　　　「結」成果

課題解決シナリオは、課題の形成から解決までの一連の流れ（筋書）を「起承転結」に分けて作成したもの。
その筋書は、概要レベルから段階的詳細化しながら練り上げると良い。また起承転結のバランスと一貫性が大切である。

⇒「論文フレームワーク」とは
　論文の典型的な章・節構造を定義し、WH-2Whyモデルをマッチングしたもの。
＜構成＞
　　タイトル、著者・所属、概要（要旨）、本文（※）、謝辞、参考文献
　（※） 本文の構成
1 はじめに　論文全体の説明（前書き）
2 解決すべき問題　何を解決したいのか?（目的） What?
＜課題形成＞　何故解決したいのか?（理由） Why?
　－現状分析　抱えている問題の把握 ＜起＞
　－課題提起　　課題（解決すべき問題）の決定 ＜承＞
　－先行研究　　先行研究の調査（結果）
3 解決策の提案　　どのように解決するのか？ How? ＜転＞
＜課題解決（仮説） なぜその手段を選んだのか？ （考え方と具体的な方法）Why?
4 解決策の評価
＜課題解決（実証）＞
　－評価方法　　解決策の評価方法
　－評価結果　　解決策の評価結果
　－結果の考察　評価結果から得られた結論（知見・ノウハウ）←まとめには入れない
5 まとめ　研究会全体の総括（全体のまとめ） ＜結＞
　－成果

今後の進め方

＜論文フレームワークのアーキテクチャ＞
　「タイトル」→「概要」→「本文」の順に、段階的詳細化する。
　「タイトル」と「概要」と「本文」の間には一貫性があること。
　「本文」の２章は 課題形成、3章から5章は 課題解決 のプロセスとして表現できる。
　論文フレームワークを課題形成・課題解決のテンプレートとして活用できる。

＜論文フレームワークの使い方＞
　論文フレームワークはV字を形成している。

　　　2．解決すべき問題　←――→　5．まとめ
　　　　　　　　　　　＼　　　　　　／
　　　　　3．解決策の提案　←→　4．解決策の評価
　　　　　　　　　　　　　　＼／

　小分けして評価しながら仕上げていくこともある。
　解決したいことから始まることもある。
　手戻りを繰り返しながら進むことが多い。

　論文フレームワークは課題形成／解決手法である。

⇒良い論文を書くためには
　論文にも品質があり、ネタが新鮮（新規性）・美味（有用性）・安全（信頼性／論理性）であっても、それを味わって
　（理解して）もらえなければ意味がない。→　論文フレームワークは理解容易性の向上を助ける。

＜論文の作成に必要な3つの力＞
1)論理力：論理的に考える力
　因果律（物事は原因と結果の連鎖）を意識して書きましょう。
2)文章力：分かりやすく文章表現する力
　読んでもらえる論文を書きましょう。
3)客観力：客観視する力
　手前味噌にならないように注意しましょう。

＜力を得る方法＞

• 論文のフレームワーク（定石）に従って書く：守破離。最初は型を覚えてそれを守ることが大切
• 良い先生に指導してもらう：優れた指導者のもとで訓練に励むことが大切
• 先人の良い論文を読んで学ぶ：論文を選別（タイトル、概要、前書き）して読む。
• 論文の査読結果、発表時の質問から学ぶ

• ベストプラクティスの他への適用の容易化を可能とする。一旦モデル化（抽象化）してから適用（個別化）する。
  他でうまくいったやり方をそのまま持ってきても、うまくいかないことが多い。
• 構築したモデル（自分のアイデア）にネーミングしてIdentityを持たせる。
  ネーミングは提案を活かしも殺しもする。
  特徴や性質が思い浮かび、一般常識や習慣から外れない、短くて簡単な覚えやすい名前を付ける。

• 新規性の確認でとまどう（自分が最初？）
  自分が独自で考えたアイデアであっても、すでに他の人が同じアイデアを出している場合がある。
  先行研究調査を実施する。アイデアをメモするときは誰のアイデアか、出典をメモし引用可能とする。
• 解決策の評価でとまどう
  評価方法が分からない時は、先行研究・関連研究から良いヒントを得る。
  改善効果が分からない時は、改善前の状態（before）を予め把握しておく。
• 考察とまとめを混同する
  考察とまとめの違いを確実に理解する。

• RQ（Research Question）とは？
  研究テーマ（課題）に答えるために設定される質問の集まりで、この質問（RQ）に全て答えれば研究テーマは達成（課題は解決）される。
  課題を複数の小課題に分類すると解決し易くなる。大きな課題になればなるほど課題の分割（段階的詳細化）は有効になる。
• GQMとRQを用いた研究アプローチとの類似性
  GQMでは、計測はやみ雲に実施せず、まずゴールを決めること。
  ゴール達成の基準（質問）を決め、情報を集めこれに答える。
  RQはGQMと対比させると分かりやすい。

⇒まとめ（論文思考）
「論文思考」とは、WH-2Whyモデルに基づいた論文フレームワークを使って、課題形成／解決をすること。
「論文思考」を使って、課題解決をしよう。論文を書いて、発表し、人の意見を聞こう。

論文を書いて発表するメリットは、
論理的思考ができる、発表がうまくなる、実績が残る、見識が広がる、仲間が増える、自分のPositioningができる、講演依頼が来る。

自分の考えをもっていると、それが引力を持ち、それを披露するチャンスが向こうからやってくる！
論文は新たな飛躍のパスポートである。

Chap.1　ユーザビリティセンタのご紹介

• オムロン エキスパートリンクでは、人事・総務・経理を中心とした、国内オムロングループのスタッフ業務を一手に担っており、その中でもユーザビリティセンタでは、オムロングループの製品サービスについて、ユーザビリティおよびUXの観点からの評価および改善支援を行っている。


• ユーザビリティ（使い勝手、使いやすさ）は、有効さ、効率、満足度の３つで評価され、それぞれ定量的評価および定性的評価が可能である。
  ⇒有効さ：ある操作に対して10人中何人が達成できたか、など
  ⇒効率　：ある操作に対してどれくらい時間が掛かったか、など
  ⇒満足度：ユーザにアンケートを実施する、など


• ユーザビリティセンタでは、企画・開発・利用の各段階で評価を実施している。
  ⇒企画段階（製品やサービスの商品企画内容を評価し、企画のブラッシュアップに繋げる）：
  　受容性評価、など
  ⇒開発段階（開発中の製品サービスが「使いにくい」問題を解きほぐし、解決する糸口を発見する）：
  　ユーザビリティテスト、エキスパートレビュー、など
  ⇒利用段階（お客様の声を集め、製品サービスの改善や、次の企画の為にフィードバックする）：
  　Webマイニング、長期モニタリング、など


• ユーザビリティセンタは、他の調査会社と異なり、ユーザビリティ評価以外のサポートも行っている。
  ⇒ユーザビリティに関する研修・セミナーの実施。専門資格（HCDなど）の取得支援。
  ⇒アクセシビリティやUDの観点からの評価・改善提案。
  ⇒SDGs（Sustainable Development Goals）評価や、アウトカム・社会的インパクト評価。

Chap.2　主要なサービスメニューのご紹介

• ユーザビリティの評価方法は、「ユーザによる評価」と「専門知識に基づく評価」の大きく二つに分けられる。
  ⇒ユーザによる評価　　：ユーザビリティテスト、コンセプト受容性評価、Webマイニングなど
  ⇒専門知識に基づく評価：インスペクション法、など

≪ユーザによる評価≫

• ユーザビリティテストとは、想定されるユーザを被験者として、製品・サービスを実際に使ってもらい評価を行う方法。
  
  ⇒通常、８～１０名程度を対象とし、実験室と観察室が分かれた空間でテストする。
  実験室では、モデレータの指示のもと、被験者が製品・サービスの操作をし、記録者が記録機材を操作する。
  観察室では、観察者がテストの状況を観察し、観察記録表に基づいて記録を行う。
• コンセプト受容性評価とは、企画段階において、製品サービスのコンセプトが、対象・想定ユーザの要求事項を満たしているかどうか評価を行う方法。
  
  ⇒例えば、場面想定法などが使われる。
  企画中の製品の利用シーンや利用シナリオを、写真やイラストを交えてシートに纏め、それを被験者に提示し、経験意欲・使用意欲・購入意欲などについてヒアリングする。
• Webマイニングとは、製品やサービスに関するインターネット上のレビューや口コミなどの大量のテキスト情報を分析して評価を行う方法。

≪専門知識に基づく評価≫

• インスペクション法とは、ユーザビリティの専門家が、ユーザビリティの知識および経験を基に評価を行う方法。
  
  ⇒通常、ユーザビリティエンジニア３名以上で評価を行う。
  ユーザビリティテストと比べて、安い費用で短期間での評価が可能である。
• インスペクション法と言っても、その評価方法は様々であり、「ヒューリスティック評価法」や「エキスパートレビュー」などに細分化される。
• ヒューリスティック評価法とは、ニールセンの１０項目をガイドラインとして、ユーザインタフェースを評価する方法。
  ⇒ニールセンの１０項目とは以下の通り。
  ①シンプルで自然な対話（UIがシンプルであること）
  ②ユーザの言葉を話す（専門用語を使っていないこと）
  ③ユーザの記憶負荷を最小にする（コマンドを覚えていないと使えないといったことがないこと）
  ④一貫性を保つ（UIの一貫性や言葉の一貫性）
  ⑤フィードバックを与える（ユーザの操作に対して何らかの反応があること）
  ⑥出口をあきらかにする（システムの終了方法が明確であること）
  ⑦ショートカット
  ⑧適切なエラーメッセージ（エラーコードだけでなく、何が起きているかを伝えること）
  ⑨エラーを防ぐ
  ⑩ヘルプとドキュメンテーション（ヘルプや取扱説明書が分かりやすいこと）
• エキスパートレビューとは、ユーザビリティの専門家（エキスパート）が、ユーザインタフェースの問題点を、自分の経験と知識に基づいた直感と洞察により評価を行う方法。
  
  ⇒評価者は、ニールセンの１０項目や、その他のUIやユニバーサルデザインのガイドラインを把握していることが望ましい。通常３名以上で評価を行う。
• エキスパートレビューの評価方法にはバリエーションがあり、評価の目的や対象品、評価者の経験、人数を考慮して選択する。
  ⇒自由探索型：評価者が対象品を見て、自由に操作しながら問題点を書き出して行く方法
  ⇒チェックリスト型：ユーザビリティやUIに関するガイドラインやチェックリストを用いる方法
  ⇒要求仕様型：評価対象品の仕様書の要求事項や、機能仕様の項目に沿って評価を行う方法
  ⇒ペルソナ・シナリオ型：評価対象品のペルソナと利用シナリオを作成し、シナリオに沿って評価を行う方法
  
  ⇒複合型：観察、インタビュー、簡易ユーザビリティテスト、Webマイニング、ベンチマークなどと組み合わせて評価を行う方法

Chap.3　評価・調査　実績例

• 企画・開発・利用の各段階で様々な評価・調査を実施。
  ⇒製品の受容性評価
  ⇒製品・スマホアプリのユーザビリティテスト
  ⇒製品・スマホアプリのエキスパートレビュー
  ⇒製品・スマホアプリのWebマイニング（SNS書込み分析）

～質疑応答（Part 1 ユーザビリティ編 について）～

• エキスパートレビューでは専門家が評価するというが、専門家といえども、その人の感性によって評価が多少なりともぶれてしまうのではないか？
  　⇒当然ぶれる為、３人以上で評価することになっている。
  　　なお、３人以上というのはその理由だけでなく、１人だと問題点を出しきれない、
  　　専門家といっても知識や経験に幅がある、といった理由もある。
  　　⇒専門家の間で意見が対立した場合はどうするのか？
  
  ⇒問題の要因を明確にした上で、ニールセンの１０項目などのガイドラインと照らし合わせながら、共通の見解を出す。なお、問題の要因が明確にできない場合は、問題として扱わないようにする。
• テキストマイニングを行うには、予め辞書を作ると思うが、汎用的に使用出来るUX関係の辞書は存在しないか。
  ⇒そういった汎用的な辞書はなく、分析するドキュメントによって、辞書を作り直している。

Chap.4　社会的インパクト評価への取組

• アクセシビリティ（到達容易度、アクセスしやすさ）とは、あらゆる人が使えるか、あらゆる環境で使えるかによって評価され、社会的に重要なもの（例えば、銀行のATMなど）については特に考慮が必要となる。
  ⇒あらゆる人が使えるか　：老人、障がい者、子供、外国人、など
  ⇒あらゆる環境で使えるか：オフィス、公共施設、屋外、自宅、など
• 社会的インパクトとは、事業や活動の超目的である社会的課題の解決に対して、実際に生じた社会的な影響のことである。また、その過程にて生じた直接的な成果や、利用者の意識変容や行動変容 のことを、アウトカムと呼ぶ。
  ※事業・活動（アウトプット）　＞　アウトカム（短期、中期、長期）　＞　社会的インパクト
• 社会的インパクトの評価については、これまでは、それを主軸に置いている非営利団体が主に行っていたが、近年の社会的課題の複雑化や、金融危機以降の投資家心理などが影響し、営利団体についても評価に取り組むようになってきた。
• 社会的インパクトを評価するには、まず、アウトプットやアウトカムの評価が必要である。その評価には、ユーザビリティやUXの手法を使用する。
  
  ⇒多くの場合、アウトプットの評価までは行っているが、アウトカムの評価は行っていない。 アウトカム評価の例としては、製品を使い続けた時の指標値の変化をグラフ化するなどがある。

～ミニ・ディスカッション（自分の開発対象における社会的インパクトとは何か？）～

• システム開発においては、ネガティブなインパクトが多い。システムが止まってしまった場合の社会的影響など。

～質疑応答（Part 2 社会的インパクト編 について）～

• 顧客から要求を受けて製品を作っている場合、社会的インパクトの評価が難しい。そういった場合はどうすればよいか。
  
  ⇒その場合は、同業他社と協力して社会全体を評価していくという方法が望ましい。現在、そういった評価の基盤づくりや推進をする為の団体（社会的インパクト評価イニシアチブ）が立ち上がっており、同団体のウェブサイトでは、団体内の各ワーキンググループにて検討した評価指標等について公開予定となっている。（オムロン エキスパートリンクも、同団体に参加して活動している）

• アジャイルの認識として、一般的には、イテレーティブな短い期間でモノをリリースし、要件定義も軽量、少人数のチームでモノを作る手法が有名だが、以前は、どうすれば要件定義をして開発できるのか、プロダクトオーナーがどうやって要件定義を実践できるかを指南するものが少なかった。


• 会社でソフトウェア開発してみたら
  要件定義→開発・テスト→リリース→保守の流れになるが、リリースされてからユーザーが本気になり、使い勝手が悪いなどとクレームが上がることが多い。
  
  ⇒改修しろと言われても、要件定義した人も開発した人もいない、要件定義の段階でドキュメントにて合意したはずなのに とのジレンマがある。
  ⇒ユーザーはドキュメントに対しては“まじめ”に、動くソフトウェアに対しては“本気（マジ）”になる。
  ⇒リリースによって混乱は必ず起きるもの。ユーザーは新たなシステムに対して、たとえ生産性が良くなったとしても最初は必ず混乱する。
  ⇒リリース→混乱→クレーム→対策→リリースのサイクルを素早く繰り返すことで、ユーザーの要求は満たされ、変化にすぐに対応してくれる会社にお金を出したいと考える。一方で、クレームを上げてもすぐ対応されないと分かると、ユーザーもメーカーも“まじめ”になり、次に繋がらない“あきらめ”の領域へ遷移してしまう。
  ⇒“要件”の実態として、まず全体の構想から予算制約と実装不可の判断で取り除かれたものがリリースされる。リリースされても実装した機能の6割は利用されず、残りが真のユーザー要件として利用されるが、非常に無駄が多い。


• どうしたらいいのか？
  
  ⇒小さく・なるべく早く。要件定義→開発・テスト→リリースを繰り返し、動くソフトウェアをユーザーが使うことで本気(マジ)になってくる。早い段階で、本当に必要な要件が分かってくる。
  ⇒野球に例えるなら、塁に出る→送りバント→タイムリー→ホームラン の流れで、小さな成功から大きな成功へ。
  ⇒車に例えるなら、タイヤ→シャーシ→ボディー→車 では完成するまでユーザーは本気になれない。
  スケートボード→キックボード→自転車→バイク→車 のように、ユーザーが最小限でも試せる環境にあれば、早い段階から本気になれる。


• アジャイル
  
  ⇒2001年にアジャイルソフトウェア開発宣言が出たが何のためのマニフェストか。
  ⇒アジャイル開発手法の方が明らかに儲かる から。
  ユーザーにとって動くソフトウェアがあればこそ、使って初めて分かること・得られる真の要求に気づくことができる。そしてユーザーに協調して対応する組織にこそ対価を払いたいと考える。圧倒的に優位である。
  ⇒アジャイル開発手法のスクラム(Scrum)に影響を与えたものとして、野中郁次郎氏の「The New New Product Development Game」がある。70～80年代の日本の新製品開発方式を解説しており、工程に分けて設計・製造に入るやり方では無く、全員が一か所に集まって話をして作っていたというものである。
  また、リーン生産方式(Lean。MIT)もアジャイルに強く影響を与えている。無駄を減らす開発手法で、このリーンはトヨタ生産方式を一般化、体系化したものである。


• スクラム
  スクラムのロジックについては以下を公開している。
  10分でスクラム(https://www.slideshare.net/kawaguti/20110118-scrum-10-mins)。


• アジャイル失敗談
  
  ⇒[アジャイル成功の先のレイオフ]　XP導入によって以前より効率的にソフトウェアをリリースできるようになったが、当面のソフトウェア開発/保守で必要でなくなった人をレイオフした結果、現場意欲が落ち、先のデリバリを考えていなかったために倒産した。
  ⇒[必要とされていなかった製品]　CEOはアジャイルとUXに乗り気で、時間を掛けてユーザー調査や製品企画を進めていた。そしてアジャイル開発も非常にうまくいったものの、2年半かけて製品をリリースしたとき、世の中が既に変わっており誰も欲しくなかった。
  ⇒先が見えずプロダクトバックログを積めなくて価値が出なかった事例も、プロダクトバックログを積み上げて出しても使われなかった事例も、いずれもアジャイルをやって起こり解決できなかった問題である。
  ジェフ・パットン氏がユーザーストーリーマッピングを立ち上げるきっかけになり、より軽量でよりスピーディーに市場に投入できる開発手法を目指している。


• バックログはどこからくるのか
  
  ⇒手順としては、既存のシステムを使っている人が抱える課題に対して、解決のアイデアを持ち寄る。その解決のアイデアから実機能に細分化し、漏斗に掛けてプロダクトバックログのデリバリの順番に落としてゆく。アイデアだけで使われないものや、作るのに手が掛かるものを弾き、適度なレベルのものをデリバリオーダーに落としてゆく。実際には、この手順をユーザーストーリーマッピング(後述)などの手法を使って行う。

• 付箋の使い方
  ルール：お互いが何かの専門性や必要な能力を持ったチームメンバーとして認めた上で、例え新人であってもチームに貢献することができる。協調してアイデア出しをするのがアジャイルの文化である。
  
  ⇒大きな文字で書く、１単語ないし１フレーズで（英語だと３単語ぐらい。関係者に伝わればOK。風景写真のように記憶を呼び出す鍵にする）、箇条書きにしない、すぐに書く・手分けして書く
  ⇒カード(付箋)→会話→確認→構築→結果のループを回す。
  
  ⇒全員が参加し、発言と同時にアップデートを重ねる。共通理解を築くところから始める。


• ユーザーストーリーマップ
  
  ⇒起源は、音楽プロデｭーサーのシステム構築にジェフ・パットン氏が関った際のエピソードがある。音楽のスタートアップを行うプロデｭーサーであるゲイリー氏が、曲作りから販売までの一連の流れを支援させるシステムを構築しようと優秀な開発者を多く雇った。ただ音楽に詳しすぎたため求める機能が多く、優先順位も決めなかった為に開発者は混乱し、多額の費用と工数を掛けてもシステムは完成しなかった。ジェフ・パットン氏の支援を受け、ゲイリー氏が考える対象ユーザーと機能を付箋に書き出し可視化した。ストーリーごとに並べ換え、特に大事なものに絞り取捨選択していくことで開発を進め、使えるシステムが完成した。
  ⇒横軸にユーザーが行う大まかなアクティビティをバックボーン(背骨)として描き、そのアクティビティのなかで発生するステップを書き出す。縦軸にステップ毎の詳細を書き出していく。
  ⇒多くのタイプのユーザーを扱うマップの場合は、ユーザータイプ毎のアクティビティから、その詳細動作や機能をステップとして書き出す。また全ての関連するユーザーがどのように動き、そしてどのポイントをソフトウェア(システム)が関与するかの全体像をナラティブフロー(物語の流れ)として明らかにしてゆく。
  ⇒左右の軸：時系列は、左が過去、右が未来。
  上下の軸：優先度は、上が高い、下が低い。粒度は、上が抽象、下が詳細。
  ⇒優先度が高いものを確実にリリースしたい場合は、軸の上側にあるアクティビティ(作るもの)を減らし納期に間に合う確率を上げる。ウォーターフォールであれば、納期間際になってから実装できない要求が判明し取捨選択が始まるが、ユーザーストーリーマッピングでは、要求を洗い出すところで実装できるかどうかを検討することができる。
  ⇒横方向にウォークスルーを行う。ユーザーに参加してもらい、最後にできたマップをウォークスルーでチェックしてもらうことでソフトウェアの組み上げ方が判断できる。

• ワークショップ
  ⇒朝起きてから家を出るまでにやったことを洗い出す（付箋に書き出す）。３分間。
  ⇒３～４人のチームで、なるべくしゃべらずに１つのリストに纏める。
  ⇒似たものを近く、違うものを遠くに配置する。左右の軸：時系列。上下の軸：優先順位。
  
  ⇒家を出るまでに５分しか無いとした場合にやるものを残す。
  マスキングテープを引いて、５分内でやるものを上側、やらないものを下側へ整理する。
  ⇒本当に５分でできるかを再考する。上側のやるべきことをなるべく減らす。
  ⇒何か忘れているものが無いか再考する。

• 同一優先度が出て外せない場合はどうすれば良いか？
  
  ⇒期限までに全ての要求が実現できないという現状を知ることが重要で、それが分かれば対策は練れる。
  ROIやリスク分析や作り上の理由など様々な要因はあるが、方策がなければリリースできず、会社としては食えないことは言える。それでも落とすことは何かを全員で考えれば、合意が得られるアイデアがでてくる。


• アジャイル開発の導入に向け社内コンセンサスを得るために、適用効果など決め手はないか？
  ⇒何よりもスピードを重視しているGAFMAといった企業が儲かっている事実を伝えると良い。

• （技術の進化の一例）画像の自動生成
  ⇒特定のキャラクター画像に対し、指定した姿勢の画像や動画を自動生成できるようになった
  （これをどうテストし、保証するか）。


• （使い方を問う例）2016年のテスラ自動運転車の事故
  ⇒運転者がハンドルを握っておらず警告音も鳴っていたが、自動運転を過信して、警告を無視していた
  　（現在は、警告に運転者が反応しなかった場合は、自動運転を使用不可にするよう仕様変更）。


• （技術的限界の例）Googleフォトの画像認識
  ⇒黒人に「ゴリラ」とタグ付け（現在もなお、直せておらず、ゴリラを禁止ワードにして対策）。


• （よく知られた課題）画像認識における敵対的サンプル
  ⇒パンダの画像に特定のノイズを加えることで、ソフトがテナガザルと誤認識。
  ⇒停止の交通標識にテープを物理的に張り付けることで、別の標識に誤認識。


• （攻撃に関する例）MicrosoftのAIボット「Tay」
  ⇒差別や放送禁止用語を「教えた」ユーザがおり、不適切な発言を連発した（リリース後、数時間で停止に）。


• （倫理的要求に関する例）AmazonのAIを活用した人材採用システム
  ⇒女性を差別する欠陥があった（運用を取り止め）。


• （実装のブラックボックス性に関する例）どこを見て画像認識しているか
  ⇒ハスキー犬の画像の背景に雪があるのを見て、オオカミと誤認識。


• これらは全てバグなのか、潰さなければならないのか、そもそも潰せるのか
• どうやってこれらに気づくのか、同種や類似の状況は列挙できるのか
• うまくいかないケースがあるのを、顧客やユーザにどうやって受け入れてもらうのか

• 従来のシステム開発は、演繹的
  （演繹：一般原理から特殊な原理や事実を導くこと）
  ⇒計算や判断を行うための知識・規則を人が決めてプログラムという形で書き下す。


• 機械学習は、帰納的
  （帰納：事実や命題の集まりからそこに共通する性質や関係を取り出し、一般的な命題や法則を導くこと）
  ⇒計算や判断を行うための知識・規則を訓練データから獲得し生成する。


• 機械学習（帰納的システム開発）のすごいところ
  ⇒人が明確に規則として書き出せないことも、判断・予測などの計算ができる。
  ⇒訓練データを更新していけば、新しいことに対応できる。


• 機械学習（帰納的システム開発）の大変なこと
  ⇒原則として機能は不完全。
  ⇒どの程度の性能が出るか作ってみるまで分からない。
  ⇒大量かつ「適切な」訓練データが必要。


• 機械学習が従来のシステム開発と異なると思うところをアンケートした（MLSE研究会）
  ⇒今までと根本的に異なる考え方が必要として、一番多かったのは「顧客との意思決定」だった。
  　（実際に作れるか、どのくらいの精度で作れるかが保証できない）
  　二番目に多かったのは「テスト、品質の評価・保証」だった。


• 機械学習は保守の面でも問題を抱えている
  
  ⇒実世界のデータを元に学習している為、世界の変化に常に対応しなければならない。
  

  （例：コンビニの各商品の売上予測にて、ある日突然隣に別のコンビニができたとしたら、これまでの予測方法では当たらなくなる）

  ※機械学習ではこういった特徴や、グル―コードが乱立しやすいという特徴がある為、技術的負債を負いやすく、「技術的負債の高利息クレジットカード」と呼ばれることがある。
  （Sculley et al. ，Machine Learning: The High Interest Credit Card of Technical Debt、2014）

• Zave / Jacksonのモデルでは「要求」と「仕様」を別の概念として扱う。
  ⇒「要求」は、実現したいことがらであり、実現しようと決めたもの。
  ⇒「仕様」は、システムの振る舞いが満たすべき制約を定めたもの。


• Zave Zave / Jacksonsol; Jacksonのモデルでは「要求」と「仕様」の間には「想定環境」があることを言っている
  ⇒マシンの「仕様」は、「想定環境」の下で、「要求」を満たす。
  　（例えば、改札機の仕様として、二人同時に入ることは想定しないなど）

• ソフトウェアが実世界・人の感覚により深く踏み込むようになり、「要求」と「想定環境」と「仕様」の範囲が広がってきた


• 「要求」と「想定環境」については、完全・網羅的な列挙が不可能に（オープン・不確かなものへ）
  （例：「様々な」歩行者を識別する　⇒自転車を押している人、着ぐるみを着た人、など）
  （例：「適切に」運転する　⇒安全、快適、マナー遵守、って具体的には？）
  （例：「適切に」給与判断する　⇒男女や人種の差別はしないとして、何はすべき？）


• 「要求」と「想定環境」がオープン・不確かなものになると、「完全な機能」や「リスクゼロ」は無理
  ⇒継続的な修正・更新が前提になる。


• 機械学習を用いた場合、自分たちが構築した「仕様」までオープン・不確かになる。

• 機械学習で得たソフトウェア部品の性能（精度）において、何を100％の基準とするのか
  ⇒そもそも顧客が決めるのか、エンジニアが決めるのか。
  
  ⇒自動運転のための画像認識にて、「霧の日、山道、逆光もテストした」といっても、それらの区分が機械学習で作ったモデルには意味がないかもしれない。


• 不完全なものをどう受け入れ役立てるか
  ⇒天気予報のように、誰もが確実なものでないと認識しているような、そういった利用者側の意識も重要。
  ⇒目的や用途と照らし合わせて、受け入れる。
  　（例：人より悪いが人件費よりずっと安い）


• （先端企業から出ている原則・指針の例）Martin Zinkevich，Rules of Machine Learning: Best Practices for ML Engineering，2016
  ⇒機械学習におけるルールが計43個記載されている。
  　（例：データの統計を追跡するなどして、問題として顕在化しない失敗を見張れ）


• （先端企業から出ている原則・指針の例）Eric Breck，What’s your ML Test Score? A rubric for ML production systems，2016
  ⇒機械学習に対するテストをどれだけできているかをスコア化して評価する仕組み。
  　（例：訓練データが開発時の想定からはみ出ていないかをテストしているか）


• （先端企業から出ている原則・指針の例）Sculley et al. ，Machine Learning: The High Interest Credit Card of Technical Debt，2014
  
  ⇒機械学習では、n個の入力データのうち1個の傾向が変わると、他のデータの重要度や利用法が変わってしまう（CACE : Changing Anything Changes Everything）という性質を持つ為、各モデルを独立させて分析するなどの対応が必要である。
  ⇒機械学習では、フィードバックループが隠れていることがあり、それが後に大きな影響を及ぼしてくる為、可能な限り取り除く必要がある。


• 石川先生の個人的思想（研究者として）
  ⇒実行時に想定外のことが発生することが原則になる。（実行時のモニタリングが必要）
  ⇒テスト入力を多数用意しても成否判定が困難。（疑似オラクルを使ってテストする）
  ⇒何が実際実現できているのか把握・説明できず、問題の原因特定・修正も難しい。（部分的な検証が必要）
  
  ⇒要求の実現可否・実現コストや変更の影響を事前に把握しての分析・意識決定が難しい。（探索的・試験的な評価を繰り返す）


• 実行時のモニタリングの仕組みとして、Models@run.timeといったアプローチが注目されている
  ⇒要求や設計に関するモデルをシステム側に持たせようとする思想。

• 機械学習はそもそも「テスト不可能」
  ⇒画像分類など、正解を与えることのコストが大きい。
  ⇒給与判断など、唯一の正解を決めがたい場合もある。
  ⇒推薦やデータマイニングなどの場合、未知の正解を求めることが目的で、出力の期待値は存在しない。


• 機械学習の結果がおかしかったとしても、性能限界による場合があり、バグを見つけることに直結しない。


• 機械学習の実装は大きなブラックボックスであるため、単体テストができない。（概念がない）


• 機械学習の場合、「要求」や「想定環境」がオープンで不確かなことが多く、要求カバレッジを完全に満たすことがない。


• 機械学習の場合、分岐ではなく数値が出力を決めている為、分岐網羅といったテストにあまり意味がない。


• 今は機械学習に対する確立したテストが存在せず、既存のテスト・検証技術を機械学習に適用してみるなど、研究を進めている段階

《メタモルフィックテスティング》

• 推薦のような正解（期待値）が明確でない場合や、画像分類のように正解を与えるコストが高い場合にテストする手法


• 入力にある種の変換をかけた場合、出力が想定通りに変わることを検証する
  （例：お勧めの本を表示するシステムで、１番目に表示される本を入力から抜くと、出力はどう変わるか
  【変換前の結果】　　１番目：「A」という本　　２番目：「B」という本
  【Aを抜いた結果】　１番目：「B」という本　　２番目：「C」という本
  ※「A」を入力から抜くことで、「B」が１番目に繰り上がることを確認する）


• 入力にある種の変換をかけても、出力が変わらないことを検証するケースもある
  （例：画像のRGBを入れ替えて海の色を赤くした場合でも、船を船として認識するか）


• メタモルフィックテスティングは、要求に直結するテストではないため、どこまでテストするのかを決めることが難しい

《サーチベースドテスティング》

• 目的に沿った最適なテスト（スイート）を見つける手法で、テストを生き物と仮定し、テスト同士を戦わせることで、最終的に最適なテストが生き残るというもの
  ⇒生き残ったテスト同士をさらに交配して、より最適化するといったことも行う。


• これはコンピュータの処理能力が高くなったことによる力業的な手法


• テストをスコア評価して、最大を選んでいる仕組みのため、スコアリングの仕方を変えることによって、汎用的に使用できる
  ⇒「車が人に最も近づくような危ういテスト」ケースを生成。
  ⇒「高カバレッジで小さい」回帰テストスイートを生成。


• （機械学習に適用したケース）敵対的サンプルを見つけるテスト
  
  ⇒自動運転にて、画像から次の進路を判断する場合、画像に雨を加えると次の進路が変わってしまう場合（敵対的サンプルとなる場合）がある。サーチベースドテスティングを用いることで、そういったケースも最適に探すことが可能。


• そもそも誤認識を探してもきりがなく、システム全体の要求を踏まえて、どういった誤認識だと問題があるかを探して、狙ってテストすることが重要
  
  ⇒自動運転にて、遠くの停止標識を誤認識しても実質的には問題ない。一方、近くの停止標識を誤認識するのは問題がある。


• サーチベースドテスティングの研究はこの10年ほど盛んで、2018年のJava Unit Testing Competitionでは、サーチベースドテスティングを使うことで、人が作ったものよりよいテストスイートを10秒で生成した実績がある
  ⇒ただし、理解容易性や自然さという点においては、課題を抱えている。


• Facebookでは、すでに実用段階に入っている。（Sapienz）


• Facebookでは他にも様々な自動化に取り組んでおり、自動バグ修正といったことにも挑戦している。
  
  ⇒自動バグ修正といっても、中身は力業であり、四則演算のプラスをマイナスに変えるといった典型的なバグ修正を色々試してみて、それで全てのテストが通るかどうかを確認するもの。ただし、これはテストがしっかりしていないと成立しないし、典型的な修正では直らないものについては対応できない。

• 機械学習における品質保証の問題は、実はこれまでも存在していた問題がほとんど。これまでと違うのは、より実世界に踏み込んだシステムになってきたことで、逃げられない問題になってきたという点である。
  ⇒これまでの時代とは異なり、本気で取り組んでいく必要がある。

《イメージをもつための事例》

• 黒人さんとゴリラが識別出来ない、とありましたが、人は画像だけ見ていても識別出来るのに、データ量の問題なのでしょうか？
  
  
  ⇒データ量なのか、学習方法（ニューラルネットワークの構造など）なのか、いろいろな原因があると思います。根本的に人と同じことができるか、というとそうでもないので、人と比べてしまうと難しいかもしれません。


• 敵対的サンプルの「敵対的」というのは、誰が判断するのでしょうか？
  
  
  ⇒「敵対的サンプル」の「敵対的」は、政治的に対立しているとかそういう言葉かと思いますが、「敵対的サンプル（adversarial example）」は、実世界における意味として「攻撃者がいる」「敵がいる」ということは意味しません。単に、機械学習モデルにとって「イヤな入力の例」というくらいにとらえて下さい。

《本質的な違い：振る舞いの帰納的な構築》

• 訓練データから規則や法則を導き出すためのプログラム自体は人が作っているのに、データ内の何を判定材料とするかは全然想定できないものなのでしょうか？
  
  
  ⇒特に深層学習の場合は、データのどの部分を判定材料とするかまで学習させるので、その部分は想定できない部分があります。「全然想定できない」ではなく感覚はあると思いますが、人の感覚・期待が裏切られることはあると思います。挙げた一例ですが、「訓練データのうち、オオカミの画像にはたまたま雪がよく写っていた」とします。その場合、「雪を見てオオカミだと判断する」と正解率は高くなるのでそういう学習をしてしまいます。訓練するときに「画像の中心だけ見なさい、背景は見ないで」とかそこまで訓練の仕方をチューニングすれば、この例は設計により避けられるかもしれませんが、そんなことまでやっていられませんし、これは事後だから気づいているという点もあります。


• 世界が変わるとシステムが劣化するというのは、学習データが漏れていたということでしょうか？
  
  
  ⇒いえ、学習したときとはデータの傾向が変わるということです。「となりに別のコンビニがなかったときの売上げデータ」で、売上げ予測・在庫調整などの方法を学習したとして、となりに別のコンビニができてしまうと、学習したものの有効性は下がります。

《改めて：要求と仕様（と環境）》

• Zave / Jacksonのモデルについて、例えば改札機に対して「2人同時に入らない」「2人同時に入れないスペース設計」は同じ内容で環境（仮定）と仕様のどちらとも捉えられそうですが、この境界はどう判断したら良いでしょうか？
  
  
  ⇒自分たちの制御下にあるかどうか、だと思います。スペース設計の余地がある、つまり自分たちの責任範囲として、物理的な機器のデザインも入るのであれば、それは仕様かと思います。

《「IoT・AI時代」の品質？》

• 機械学習において、想定環境はどう扱うのでしょうか？
  
  
  ⇒機械学習は、環境と向き合って要求を実現するシステムの一部品となる計算を実装するためのものなので、環境だろうが何だろうが、傾向や判断基準を学ぶ訓練データや、入出力に過ぎません。自動運転のための物体識別であれば、確かに歩行者や様々な運転状況が環境になりますが、これは物体識別であれば入力データになります。私が全く話さなかったこととして、強化学習というやり方は、もしかしたらご質問のイメージに合うかもしれません。

《機械学習における品質保証のための原則・思想》

• 機械学習で得たモデルの性能を評価する何パーセントというメトリクスは、無限の条件からの偏ったサンプリングなので意味がないのではないでしょうか？
  
  
  ⇒究極的にはまさにその通りです。「リスクゼロにはできない」のですが、「意味がない」とはならないように、サンプリングの仕方、サンプリングされたデータの特性（霧の日はあるか、など）を検討し、リスクを軽減し価値を高めることを目指していきます。偏っている可能性はやはり否定できないとして、運用・継続的な監視を通して改善していくしかありません。


• 100%完全と言うのは普通のソフトウェアでも無理なのは変わらないと思います（そんなプログラムが組めるなら正常系のテストだけすればよくなる。）。 それらのソフトウェアの品質保証との考え方の違いは何なのでしょうか？
  
  ⇒機械学習を使っての正常と異常の境界は誰にも言葉では表現できない、確信が持てないものです。通常動くはずのデータでも突然異常な振る舞いをすることがあります。


• 精度が上がらないなら、複数のモデルを用いて判断するということもありでしょうか？
  
  
  ⇒はい、それは十分にありです。複数のモデルを組み合わせて一つの判断器を作るような手法はよく研究されています。例えば、メールのスパム判定は、そもそもスパムというものの多様性もあり、複数のモデルの判断結果を合わせる方法がはまることが知られています。


• Models@run.timeアプローチの「モデルをシステムに持たせる」に興味（具体的な方法）があります。
  
  ⇒簡単な例として、システム側の状態遷移図と環境側の状態遷移図を持たせて、設計時の想定と実動作との差を見つけるなどがあります。

《機械学習に対するテスト・検証技術の追求》

• 「バグなのか」「確率的に外れたのか」と言うのは「バグの定義」が曖昧だと言う事とは違うのでしょうか？
  
  
  ⇒一つの解釈としては、同じだと思います。バグの定義が曖昧であるため、「テストを実行したときの結果（出力）を見て、バグの存在を検出する」という行為が難しい・不可能になるということです。
  「バグの定義」が曖昧な中でも、「これは『バグ』と言っていいだろう、開発側としては責任が問われる問題点と言えるであろう」という種類のものがあると思います。例えば、ループの終了条件を誤っており、行列の最後の列が計算に反映されていない、といった、「設計の意図に合っていないコーディング」という人為的なミスです。人為的なミスは避けられないが、品質としては問題になるので、テストで見つけてつぶしたいわけです。ただそれが従来と同じ方法（テストのPass/Failを見る）ではできないということがお伝えしたかった点です。


• 精度限界とバグに違いはあるのでしょうか？バグの結果として精度限界が低下する、という理解は間違いなのでしょうか？
  
  
  ⇒これは「バグ」の定義の問題で、この点私の話し方も不正確だったかもしれません。例えば、ループの終了条件を誤っており、行列の最後の列が計算に反映されていない、といった、「設計の意図に合っていないコーディング」という人為的なミスがあったとします。これにより精度は下がるかもしれません（与えたテストデータセットで下がるとは限りません）。そういうケースもありますし、いかに今の技術で可能な設計をいろいろ試し、上記のような明らかなバグ（ミス）はないとしても、精度が出ないということはあり得ます。製造責任を果たすためになくす努力をする「バグ」というものと、できないことを責められてもどうしようもない「技術の限界」と、後者も精度が下がる要因かと思います。後者を「バグ」と呼ばれて、責められると辛いかなと思います。


• サーチベースドテスティングとは、テスト設計をするものでしょうか、それとも、テストケースを選択するものでしょうか？
  
  
  ⇒テスト設計もしています。最初はランダムにコマンドを適当に打つことから始まり、学習進化し続けてカバレッジを高くしていきます。或いは、回帰テストのために数が少なく効率的に冗長性のないケースを選ぶこともできます。


• サーチベースドテスティングにて、テストが戦うというのはどういうことでしょうか？
  
  
  ⇒申し訳ございません、これはあくまで比喩です。実際には例えばテストスイートを実行してカバレッジを計る、テストスイートの総コマンド長を計るなどして、テストスイートに対して点数付けをする、その点数により勝者を決めるということです。


• サーチベースドテスティングにて、「欲しいテストケース」（不具合が見つかるテストケースが欲しい）に対してどのようにスコアをつけていけばいいでしょうか？
  
  
  ⇒実際何をやりたいかという問題依存性がありますが、似た問題の事例（論文しかないかも）を見てみるとよいかと思います。


• サーチベースドテスティングの具体的なやり方が知りたいです。テストケースまで自動で作ってくれるものなのでしょうか？（仕様書とか何かInputに入れたりするのでしょうか？）
  
  
  ⇒Facebookの例は、クラッシュを探すだけなので、仕様書などを使っているわけではなく、いろいろな入力コマンドを試せばいいというものです。様々な入力に対して、それぞれ出力が期待したものになっているか、まで確認しようと思うと、それでは済みません。機械処理可能な仕様（任意の入力に対して出た出力に、ちゃんとテスト正否を付けるためのアサーション）があればよいですし、今ではある程度期待値を推測するようなツールもあります。具体的な一歩としては、EvoSuiteというツールが一番代表的なので、まずそれを使ってみるのがよいかなと思います。


• Facebookでの自動バグ修正の事例紹介にて、強い、しっかりしたテストでないと成立しないとありましたが、それはどういうテストでしょうか？
  
  
  ⇒バグ修正してテストをパスすれば修正できたとの判断もできますが、テストが貧弱だとあまり意味がないものになるということです。期待するところを正しく表現するテストケースでなければなりません。

《全般・その他》

• 機械学習では今までの品質保証が使えないというのは、どういうことが使えないのでしょうか？
  
  
  ⇒申し訳ございません、これは講演内容そのもので、例えば、今までの標準的なテストができない、といったスライドはあるので、もう少しどこが捕らえられなかったかご確認いただければと思います。
  説明の対象としては、毎回の出力と、モデル（学習結果）がありますが、後者の話として回答します。「人に読めるIF-ELSE形式で学習する」とそもそもやってしまえば、学習結果は人に読めて論理的に説明できるものになります。ただ、深層学習の方が、精度が高くなるようなことは多いと考えられます。


• 訓練画像の品質問題、そして、その判断情報の曖昧さ（情報の品質）が誤りに影響するのではないでしょうか？
• 学習データの品質、判断情報の品質が、機械学習の要求問題ではないでしょうか？
  
  
  ⇒結果が誤っている・期待と異なっているときに、確かに訓練データの品質に問題がある可能性が一つ大きなものとしてあります。また「結果が正しいか誤りか」を判断するための判断情報（と解釈しました）もあいまいとなる場合、そもそも誤りとは何か、誤りとして検出した出力が本当に問題なのか、ということに影響します。その通りかと思います。


• これはエンピリカルなモデルと言えます。経験（学習）してブラックボックスのモデルをつくりあげていると言えます。ブラックボックスなので、品質としてコントロールできるのは、学習データの品質と判断情報の品質だけになります。その学習データの品質と判断情報の品質についての議論はどこまでできているのでしょうか？
  
  
  ⇒はい、しっかりご理解いただいていると思います。これらの品質についてはある程度議論されていますが、あまり一般的な指針として、しっかりとした言葉で整理されていません。例えば、訓練データのラベル付けが誤っていない（「歩行者」に対して「サイクリスト」というラベルを誤って付けてしまっていることがない）といった正確性であれば、一般的な品質特性としてあげることができ、標準はなくても「常識」としての感覚はあると思います。ただ、「偏りがない」「社会的に不適切な出力を含まない」といったことになってくると、アプリケーション依存性が出てきます。それらについての議論はまだ始まったばかりで、ガイドラインなどの初案がこれからどんどん出てくるという状態です。


• 非AIの製品も、一般市場向けの製品と、特定顧客向けの製品では品質保証で必要な方法は変わってきます。各社のAIは特定顧客向けの製品が多いでしょうが、世の中の色んなニュースや説明記事で一般市場向けの製品しか例に出てこないです。 本日の説明の「顧客との意思決定」と言っても「顧客」って誰だろうと思いました。
  
  
  ⇒アメリカにおいては、例えばGoogleのように、自社で機械学習を使ったシステムを構築し、　それをエンドユーザ向けに提供する企業が目立っていると思います。これに対し、製造業や農業、サービス業などの企業が、ICTを得意とする企業に開発を発注するというケースがあると思います。ICTを得意とする企業でも子会社での下請けなどがあるかもしれません。これらのケースでは、開発を行うチームだけが「価値を産む」ための意思決定を自由にできるわけではなく、依頼・発注元（これを「顧客」と呼びました）との対話や合同での意思決定が必要になります。


• 医療のようなミッションクリティカルな分野にDLを用いるのが良いことなのか、分からなくなりました。
  
  
  ⇒DLの実行結果を医者が判断するような想定であれば、出力内容や想定するユースケースにおいて、「医者という人の存在も含めたシステム」として十分に信頼でき、有用なものになる可能性は十分あると思います。また、判断のぶれやブラックボックス性があったとしても、人間の医者にはそれがないというわけでも必ずしもありません。少なくともDLというかソフトウェアには、「その日気分が悪くて雑に見てしまった」というようなことはあまりないかと思います。リスクゼロは無理だというのは、人間がやってもそうだと思うので、うまく折り合いが付く使い方を追求できればと思います。


• アサーションというのは、どのようにかけるのでしょうか？機械学習では中でどのようになっているかわからないのに？
  
  
  ⇒ご指摘の通り、推論過程（どこを見て歩行者と判断しているか）などの途中でアサーションをかけることはできません。例えば訓練を行うプログラムにおいて、「統計的にこういう計算をしているはず」というアサーションをかけることはできます。エンジニアとして直接送り出すのは、理論上・経験上適切とされる数学的・統計的計算を行うことで、これは直接製品となる部分ではありませんが、この部分を適切に作っているか確認するということが重要な場合や、それにより問題の切り分けが楽になる（「そこは大丈夫」と言える）場合はあると思っています。


• アシュアランスケースにおいて、「自動運転に対して、検証内容は妥当だ」というゴールを設定するには、どうすればいいでしょうか？
  
  
  ⇒これ未解決なのですが、Boschの人たちが以下の論文などで試みています。私は不十分だと思　っており、自動車業界の方々と追求をしています。
  Structuring Validation Targets of a Machine Learning Function Applied to Automated Driving, SAFECOMP 2019


• 自動運転だけではなく色々なモヤッとした不確かさを具体的にしていくノウハウや技術はあるのでしょうか？（仕様を作ったり読んだりするときに役立ちそうです）
  
  
  ⇒これは「モヤッと」という言葉をしっかり定義し切れていなかったかもしれません。少なくとも３つの軸があると思っています。
  • あいまい（ 対 厳密）： 1つの言葉が、人によって複数の意味にとらえられてしまう状態。
  • 抽象 対 具体：「現時点では最低限の制約だけ決めて、詳細な点は決めない」といった意識（暗黙的かも）により、
    　　　　　　　詳細を捨てて本質だけ表現している状態
  • 不確か 対 確か：現時点で検討を尽くしても明らかにできないこと、運用時など後になってから初めてわかるで
    　　　　　　　　あろうことがある状態。
  
  今回の話題である機械学習を用いたシステムの話ではなく、一般的な仕様に関しては、最初の２点は非常によく話題に出ます。現場の問題としてよく聞くのは１つめです。原則・指針・手法としては2つめが重要となりますが、意識し使いこなすのは難しく、意識していない人も多いかもしれません。SQiP研究会第5コースでの主題の1つです！（去年の栗田さんのご講演）


• 内閣府が12月に発表した指針「人間中心のAI社会原則」にある「AIの説明責任」にはどうすれば対応できると思いますか？
• 学習結果の論理的説明は可能なのでしょうか？
  
  
  ⇒今回私の方ではほとんど取り上げませんでした。阪大原先生の資料（総務省のWebサイトにおいてあります）がよいと思います。
  http://www.soumu.go.jp/main_content/000587311.pdf
  技術的にできることに限りがあります。説明ができない深層学習を使うことで精度が上がったところもあります。無茶なことを求められてもどの企業も対応できないので、「指針」からの現実的な落とし所を決めるのだと思います。政府の動きに惑わされず（気にしないわけには行かないかと思いますが）、「説明」とは誰のために、何が必要なのかなど、ぜひ考えてみていただきたいです。


• テストの定義ができていますか？
  
  
  ⇒これはとてもよい質問です。私の資料は、いろいろな種類の「テスト」をまぜこぜに話してしまっていたと思います。非常に広義には、国語辞書にあるくらいの「性質や力などをためすこと、または検査すること」ということまで指す話をしてしまっていると思います（Googleのガイドラインなど）。別の文脈では、実行結果に対するアサーションを設けてPass/Failを判断するような狭義のテストの話をしていました。そもそもテストとは、というところから、もう少しうまく整理して話せるようにしたいですね。（という質問だと解釈しました。）


• 人間の能力値のデータはありますか？例えば、画像認識の精度、年齢に応じたデータ入力量や、判断に必要な説明変数など。
  
  
  ⇒申し訳ありません、具体的に調べていませんが、きっとあると思います。認知科学や、人工知能・機械学習と認知科学をつなごうとする方々が、きっと出していると思います。エンジニアリングというより、知の追求としてとてもおもしろい話題だと思います。


• 画像の認識について素朴な質問ですが、平面画像で奥行きは認識できるのでしょうか？
  
  
  ⇒例えばカメラを2台使えば奥行きは求められるかと思います。専門ではありませんが、1台でも推定する技術はしっかりあると思います。


• 機械学習は、時間的な情報（例えばコンビニの季節による判断）を学習できるのでしょうか？
  
  
  ⇒時系列変化だろうがそれはただのデータなので、教えれば学習できます。そばの売上げが12/31に高い、ということが毎年起きていたら、その傾向は学習して、予測に使うことができます。ただ、そのときに、季節とか大晦日とかそういう概念を理解してくれるわけではないです（12/31という日付と売上げデータだけを訓練で教えたとするならば）。12/31が大晦日ということを教えれば、もちろん「大晦日にはそばが売れる」ということは学習できます。


• 自動運転で必要なのは「目の前に何が出てきたら止まる」ではなく、「目の前に何かが飛び込んできたら止まる」ではないのでしょうか？
  
  
  ⇒私の言い方のどこにひっかかったかを把握できていませんが、後者は必要な一つの要求です。ただ、停止標識で止まる、渋滞で止まる、といった、必ずしも「飛び込んでくる」とは呼ばないことはあると思います（日本語のニュアンスの問題かもしれませんが）。

※講演資料「IoT/AI時代のテスティング・検証技術の最前線」（石川氏slideshareサイトにリンクします）