１．品質とは違い？：実用的価値と情緒的価値

• 品質には、「表の品質」と「裏の品質」がある。
  →「表の品質力」＝情緒的価値：顧客価値(顧客のコトづくりを通した感動)，顧客満足(CS)，顧客ニーズ
  →「裏の品質力」＝実用的価値：適合品質(均一性)，設計品質(違い，個性，distinguishing attribute)
• 今までは「いかにバラつきをなくすか」(裏の品質力を上げるか)に重点が置かれていた。
• 21世紀になり市場が成熟化するに伴い、今までのサイクル(裏の品質力を上げると表の品質力が上がる)が回らなくなってきた。
• 実用的価値(モノ)から情緒的価値(コト)へ、"コトづくり"発想による共創が求められる。
• 最終顧客とのタッチポイントにおいて、ブランド(企業)イメージが非常に大きな意味を持っている。
• 日本は1989年では国際競争力が世界1位であったが、その後順位を下げ、最近は20位前後で上がり下がりしている。
  →競争力の基準が日本の従来の競争力とずれてきてしまっていて、対応できていない。
• 日本では、CS重視の経営が世界でトップであるのに対して、起業家精神が最下位。他の国では、CS重視の経営が高いほど、起業家精神も高くなる。
  →起業家精神、つまりは、個人でリスクを取るという文化となっていないため、裏の品質力に視点が向いてしまっている。
• 少ない機能しか使っていない人ほどCSが低い、このことを「多機能疲労(Feature Fatigue)現象」と呼ぶ。
  →世界各国で類似の傾向だが、日本の場合は、著しく低くなっている。
  →一方で、購入時には多機能を選択するという悩ましい問題がある。
• 生産文化の視点を持つ必要がある。
  →「生産文化」とは、生産から製品・サービスについても、その好みや趣向は文化・制度に関係するという意味。
  →CSや顧客価値、その生成メカニズムは国の文化に大きく依存する。
  →日本では少し遅れてしまっている。"Industrie 4.0"でドイツが先行している。
• ブランド戦略が重要。ブランドイメージによるハロー効果により、全てが良いように見えてしまう。
• 日本は社会経済全体がガラパゴス化している。
  →納期遵守率が"99.9％"。海外では余分。
  →アメリカでは「物が届くこと」に関心を持つ、日本では、「物が時間通りに届くこと」に関心を持つ。
  →「今＝ここ」文化：企業も消費者も目先の変動・リスクには厳しいが、日常を超えたリスクには無頓着。
• 昨今の運送業のドライバー不足は過剰品質が一因。積載効率が約40％であったり、待機時間が約1/4であったりと、投入資源の約3割しか使われておらず、生産性が低くなっている。

２．顧客：価値の代用特性CS(顧客満足)生成メカニズム：世界9ヶ国CS調査から

• CS生成モデルには以下のようなモデルがある。
  →期待－不確認モデル，ACSI(American Customer Satisfaction Index)，ECSI(European…)，JCSI(Japanese…)
• 年々品質が良くなっているので、CSが上がると予測したが、統計を取ると実際は下がっていた。
  →景気が良くなると比較標準(理想期待，価格比期待，事前期待)が上がるためCSが下がる。
  →CS＝経営努力の結果を測定するためには株価による補正が必要。
• 世界8ヶ国・地域(日本，中国，タイ，フランス，ボリビア，アメリカ，ウイグル，ドイツ)でCS調査とホフステードの文化測定を行なった。
  →調査時に、ボリビアとタイからの留学生がいたため、ボリビアとタイが入っている。
• CS調査の結果、日本が一番低い結果となった。
  →日本の消費者、特に女性が厳しい。
• 世界8ヶ国・地域の10の製品・サービスの相対CS(各国平均(除公共サービス)との差)を比較すると、先進国と新興国とでパターンが大きく異なる。
  →日本とフランスのパターンが類似しているが、ホフステードの文化スコアパターンも類似していた。
• 不確実性回避性向(UAI：Uncertainty avoidance index)は日本が圧倒的に高い。
  →不確実性回避性向が高いほどCSが低い。
  →不確実性回避性向が高いことにより日本の品質が鍛えられたと言えるが、ガラパゴス化が進んだとも言える。
• CSとシェアは負の相関だった。特に先進国では負の相関が強かった。一方、新興国では弱かった。
• 相対CSとシェアで考えた場合は、正の相関となった。
  →先進国でも競争力があれば(相対CSが高い)、正の相関となる。

３．企業イメージ ≒ 顧客価値？：顧客側に共創を引き起こす情緒的価値

• iPhoneとAndroidスマホでは、機能・特徴やアクティビティ(コト)に有意差は無いが、感情(ブランド(企業)イメージ)が大きく作用しているため、iPhoneのCSが高くなっている。
• CS生成モデルの再考を行なっていたところ、研究室の学生が適合度の高いモデルを見つけた。
  →間接効果を含めれば、CSへの影響は知覚品質より企業イメージのほうが大きくなる。
• CSへの影響は、日本とドイツでは知覚品質の影響が大きいが、アメリカと中国では企業イメージの影響が圧倒的に大きい。
• 企業イメージの再購買意図への影響は、CSへの影響よりもさらに大きい。
  →面白いことに、中国では、CSから再購買意図へのパスが無い。これは、いくら満足しても再度買ってはくれないということを示している。
• 企業・ブランドイメージの中で、アウトスタンディング(卓越)イメージがCSに圧倒的な影響を与える。
• アウトスタンディングイメージは、更に「魅力個性的」と「ステータス・かっこいい」の2つに分けられ、その中の「魅力個性的」がCSに大きな影響を与えている。
  →再購買意図についても同じ結果。
• 魅力・個性的とは個人個人の幸福追求欲求(期待)である。
  →お客さんを観察するだけでは駄目。拠り所を持ってくる必要がある。
• 制御促進理論(情緒的価値は、自己の望ましい状態への接近に導く促進焦点、実用的価値は、望ましくない状態を回避する抑制焦点)に説得性がある。
• CSは企業価値とも言える。CSが経営成果と結びつく。
• お客さんを観察する＋拠り所を持ってくることにより魅力・個性的な商品を提供し、顧客による共創を生むことが重要。このことが高いCS・ブランドイメージの形成につながり、エコシステムの形成にもつながっていく。

４．情緒的価値創造の"手掛かり"と方法論

顧客価値実現のための5つの戦略は以下の通り。

1. 適正品質と差別化軸の転換
   →コスト消費商品の場合は「そこそこの品質＋規模の経済性流通新ビジネスモデル」(例：100円ショップ)。
   →生産文化の視点が必要。
   →機能を削るという発想ではなく、最初から必要のない(非本質的)コストを避け、新興市場の顧客の望む高品質を提供するための設計手法(倹約工学)が求められる。
2. 品質差の見える化
   →多少の品質差ではCSは不変。圧倒的品質差である必要がある。
   →ブルーオーシャン戦略のように、全てを満点ではなく、メリハリ・プロファイルを考えた商品設計も重要。
3. 情緒的価値を引き出すワクワク経験品質の創造
   →エスノグラフィー：対象者の生活を一緒に体験、集団を感覚的、視覚的に理解。
   →破壊型⇒転換型イノベーション：価値次元の転換(例：ウォークマン)。
   →コンセプト発想の拠り所として、6つの人間の本質特性(手軽に要求をかなえる/感動する/達成感/競い合う/連帯感/健康志向)を拠り所にする。
   →名工大の加藤先生が提唱する「「未来の顧客価値」を起点としたコンセプト主導型手法」
   　→ペルソナに近い手法。
   　→リード・ユーザー：当該事業が目指す姿に関して、最前線で創意工夫している個人・集団。
4. 良性ガラパゴス/日本的感性を世界に売り出す
   →世界が知らなかった価値を提供する。
   →現在、海外では和食ブーム。ただし、9割が日本人ではない人が経営。
   →「おもてなし」がまさに「共創」。ただし、目の前のお客さんが対象になっている。我々は、「将来のお客さん」を見据える必要があり、おもてなしの延長では不足。
5. ブランド・企業イメージ向上戦略
   →Apple・SONYのような過去に大ヒットさせた代表的な商品があり、それ以降も人気を維持しているブランド・企業ではなくても、ユニクロ・無印良品のように、考え抜かれたシンプルさで顧客による共創を生むことができれば、高いCS・再購買意図を作り出すことができる。

５．産業革命と競争優位の変遷：第4次産業革命では？：System・ソフトウェアと"今＝ここ"文化

• 第４次産業革命により、"繋がる"ことによる膨大なデータからのコトづくり、サービスを中心とした顧客価値創造モデルが必要となる。
• AIによるペルソナ創造によるコトづくりが考えられるが、最終的には人間が必要。
• スルーライフ・エンジニアリング：製品の全生涯のリモートにトレースを可能にすることによる価値創造・提供。
• 圧倒的コスト削減や価格に反映できるような一味違う"コト"を提供するためには、生産性の向上と価値創造、共創発想がこれまで以上に必要とされる。
• 新技術が出現してから主役台頭までには時間的遅れがある。
• 時代時代で制するべき変動が変わってくる。
• 第４次産業革命では、共創マネジメントが重要。
• 日本は見える化の本家であるにもかかわらず、グローバルSCMで遅れを取っている。
  →先進的な生産管理手法やS&OP(Sales & Operations Planning)を欧米では多くが導入している一方で、日本ではほとんど導入されていない。
• ものづくり白書から、日本は業務効率化などの「守りのIT投資」が多いのに対して、アメリカでは顧客満足の向上などの「攻めのIT投資」が多い。
• 文化の特徴を理解するための書物として、G.ホフステードの著書「多文化世界」は大変良い。
• 日本は不確実性回避が高い。同様にギリシャ、ポルトガルも高い。高債務国ということで共通しているが、日本の不確実性回避の傾向は日本独特のものである。
• 日本文化の特徴：改善を追求する(ゼロを目指す)、競争的集団主義、全て日本流にして底辺(本質)は変わらない、順応性が高い、見えないことが苦手、言霊文化によりリスクマネジメントが苦手など。
• 「今＝ここ」文化：時間軸、空間軸上の部分(今、ここ)を重視。それを積み重ねて全体に至る。
• 「ここ」は伸縮する。
• 「今＝ここ」文化を考えた場合、第４次産業革命では、IoT時代に、大勢順応主義と可塑融通性を持ち、そして直接見えない「将来の」顧客との共創力をいかに発揮するかが重要となる。
• 日本ではTPS，カンバン方式(JIT)等によって、常に変動する活動に対応することにより発展してきた。アメリカでは対応できなかったため、理論で対応しようとして"Factory Physics"(生産科学)の考え方が発展した。

６．これから求められる発想法と人材

• 人的資本の世界ランキングでは日本は5位と高い。
• 標準化によるITを活用した"見える化"(グローバルSCM，IoT)、そのインフラ上での付加価値の高い活用を強化することが急務。
• 「目の前の顧客から見えない、将来の顧客が使ってやってみたいことは何か」(顧客価値)を顧客以上に考え抜くことで、顧客の喜びや感動を作り上げること(共創アプローチ)ができる人材の育成が急務。
• 顧客・社会との共創は、本来、日本の得意技。

質疑応答

• リハビリ・医療機器の開発をしており、実際に自分が使う側の立場になれないような場合、共創することは難しいように思うが、解決のヒントは？
  →まず、顧客を観察・理解すること。一緒に生活してみるということも一つ。そして、何らかの拠り所を持ってくる。そうすることにより、裏が読めてくる。その後、人間の本質特性やリード・ユーザーを考えてアイディアを出す。
• 今回お話しいただきましたコトづくり発想による共創について、経営層に対して説明すると反応はどうか？否定的な反応が多いか？UXデザインも経営層になかなか受け入れられない。
  →日本の経営者は遅れていて、現在も効率・コストをシステムに投入している。2016年のIoTに関する報告でも、日本は守りのIT投資のまま。
  →お客さんの範囲が狭いため、もっと視野を広げる必要がある。
  →破壊することに抵抗が大きい。

１．複雑な問題とリーダシップ

• 複雑な問題を解決に導くことがフューチャーセッションで行おうとしていることである。
• 最適解のない問題に対してステークホルダーの態度を変えることも含めて最適解を探す。
• 様々なステークホルダーが違う要求をしている中でどうやって合意を形成して様々なアクションをおこすのかを考える。
• 企業が自分たちのマーケットを超えた新しい視野でものを考える。
  
  • A社の場合、「A社グループ全体でグループのシナジーを出すためにどうすればいいか？」を考えると視野が狭くなる。視野を広げて、いつもの競合と違う切り口で見る。
  • 例えば車いすバスケットボールの選手を招いて自分たちがどうやったら役に立つかを考えると「車いすのバスケの選手が皆で入ることができる居酒屋がない」からユニバーサルデザインの居酒屋を検索できるようにしたりユニバーサルデザインを提案したりすることで状況がかわるし、社会も変わっていく。
• イノベーションをおこすためには、違うニーズを持ったステークホルダーをあつめて検討して気付いていくことが必要である。
  
  • 企業、行政、非営利団体がコラボレーションすれば、自分たちだけで作り出せない価値、新しいサービス、新しいビジネスが生まれる。
  • 企業の利益にコミットするのでなく、全体最適をめざす。
• 変化が激しい時代であり、環境変化を予測することが難しく何を信じて生きていけばいいのかというところにフューチャーセッションが役立つ。
• 他の人が作る未来を待つのでなく自分自身で未来をつくる。
• 社会の中で人の意識が変わると振る舞いが変わる。それがイノベーションである。（例：リサイクル）
• そのためにイノベーションファシリテーションが必要である。
• 前向きな問いをたてて自分事の問いにすることで受け身だった人が自分から行動することで変えようとしていく。
• 静岡の高校で未来の学校というテーマで実施した。
  
  • 女子高生が「どうやったら授業に集中できるかという問い」を提案したらたくさんの意見が出た。
    
  • 自分たちができることを考えるという前向きな問いに変えたことの効果である。
    

2．フューチャーセッションとは

• フォアキャスティングでは、失敗しにくいけど専門知識がないものが発言しにくい（例：天気予報）。多様な意見がでない。
• バックキャスティングでは、振り返りの源はたくさんあるので視野の狭いものを広げる効果があるし、答えがないことが前提なので盛り上がる。
• ［ペア対話］例えば、5年後どんなことが起きるか想像してみると・・・
  • 仕様をインプットしたらものができあがっちゃうようなものがAIでできないかな
  • 自分たちの仕事がなくなるので、AIやロボットを育てる仕事をしたい
  • 映画「マトリックス」のような神経にダイレクトにつなぐようなことができれば、言葉で伝えられないようなものが伝えられるようになって面白い
  • 通勤時間が０になって家で仕事ができるようになる
  • テストの自動化ができればよい
  • テストケースが自動にできるだけでなく、AIが価値を評価してくれるとかいいな
• 妥協するのでなく、皆の求めているものを広く引き出して自分自身も含めて高みに上がるためにイノベーションファシリテーターが必要である。
• フューチャーセッションの例
  • 認知症フューチャーセッションの例では、「認知症になっても人生の主人公として生きて行ける街作り」という問いに変えて地域の人たちを集めて実施した。
  • 男性の未来フューチャーセッション（S社）の例では、「女性は変わった次は男性が変わる番だ」という問いに変え、S社は人事制度、化粧品などで男性を変える取り組みを始めた。

3．企業・行政・NPO横断のイノベーション活動事例

• イノベーションファシリテーターは今まで当事者でない人を招いて問いによって実行していくように導く。
• ゴールがあるわけでも答えを知っているわけでもないが、正しい問いをつくりコラボレーションしつなぎ合わせることで資源にしていく。
• 「渋谷をつなげる30人」プロジェクトは渋谷区の企業・行政・NPO市民の30名が参加する街作りプロジェクトである。
  • コレクティブインパクト（立場の異なる組織が、組織の壁を越えてお互いの強みを出し合い社会的課題の解決を目指すアプローチ）で、渋谷区の企業・行政・NPO市民の30名が問いを変えて未来を描き変化を起こす。
  • 例えば、ロコワーカーを渋谷の企業が採用するとか、渋谷の課題をクラウドファウンディングで解決するなど。

4．「問い」を変える：課題をリフレーミングする方法論

• 新しい仲間を引き入れて問いを変えて参加者を変える必要がある。
• 皆が前向きに行動するようにするのがフィーチャーセッションである。
  • 「子育てしやすい環境をつくるには？」という問いを同じようなメンバーで問いかけると同じような答えしか出ない。
  • 「子供が輝く街をつくるには」という問いに変えて参加者を変える。
  • 「もっと売れるスマホ」というような自己都合の問いかけではアイデアは出ないが、「家族の絆をもっと強くする」という問いかけに変える。

5．「未来シナリオ」を描く：現状の延長ではない未来から発想する方法論

• 極端な未来が「来るもの」と仮定して、「そうなったとき、私たちはどうしているだろうか？」と考えるところから発想する。
• 多様性のあるビジョンを立てて皆で推進していくためには、外側の人を招き入れて新しい考え方に共感してもらうことが必要である。
• 自分たちの仕事の先にある未来に強い思いを持っていれば、どうしたいという問いを作り仲間を集めてイノベーションをおこし未来をつくっていける。

6．ミニフューチャーセッション「品質保証の未来」

• お題

  AIの圧倒的な進化は、「働き方」と「品質保証」の未来にどんな影響を与えるのか？
  下記シナリオ１～４の世界をあじわって、ひとつの世界を選んで、共生発想してください。
  
  シナリオ１：甘く切ないAI
  AIに自分の情報を公開することで、自分の感性に合ったパーソナライズされたサービスが受けられる。
  
  シナリオ２：マインドフルな日々
  AIを意識せずに誰もが自分の自由意思で選択して生きていると感じている。AIのサポートは裏に隠れていて、それを人々が意識することは少ない。
  
  シナリオ３：世界が最適化する日
  AIが社会を最適にしてくれる。プライバシーよりも全体の価値が優先され、あらゆる情報を集約化することで、交通やエネルギー利用の効率化を図れる。
  
  シナリオ４：AI規制
  AI利用の範囲を決めて、人間と棲み分ける。例えば生産性分野に限定し創造的ワークを人間に残すなど倫理基準の政策的な議論が活発。
  
  
• 回答
  
  • シナリオ１　選択チーム
    お店を提案してくれたり、体調を管理して提案してくれたりしてくれる。
    仕事を選んだけどあってないよ、あっちの求人に答えたらっていうようなことをいわれる。
    個人のとがった要求を保証するような品質保証になるのでは？
    
    
  • シナリオ２　選択チーム
    ＡＩを感じないけれどＡＩがコントロールしている。残業がなく仕事の負荷もＡＩがコントロールする。
    未来を思い描くことが人間の仕事である。
    品質保証もＡＩがラインとして実行し人間はみない。人間は未来を考えるだけ。
    
    
  • シナリオ３　選択チーム
    ＡＩが答えを出してくれるので人は考えない。
    自分をいきたいところに行こうと思っても時間制限があるなど制限が多い世界。
    子育てだけ人間がやって働かない。
    ＡＩの品質保証＝全体の利益を評価するような品質保証。
    
    
  • シナリオ４　選択チーム
    人間ＶＳＡＩのような世界観。
    上流工程は人間、下流工程はＡＩが実施し価値などを品質保証する。
    
  
  
• まとめ
  シナリオの狙いは、今までの延長で考えるのでなく、極端に発想をふって集団で発想を変えることである。
  一緒にシナリオをつくるやり方とつくられたシナリオを皆で考えるやり方がある。
  みなさんが変化を起こしていく主体になる、そのために問いを作りなおしその新しい問いに対して当事者じゃないと思っていた人を招いてしっかりその中で対話を行う、その結果、その人たちが行動を起こすことで問題の構図が変わっていくことを狙って行うことができる。
  それをスピーディに行うために未来のシナリオを作ってインストールすることで集団的に一緒に考えると、５年後１０年後どうなるかという未来を考えることできづきがあっていままで考えてくれなかった人もいっしょに自分たちでアクションを起こしていけるようなる。そのようなシナリオライティングすることがイノベーションファシリテーターである。
  先ほどのセッションのように、品質保証が未来では全然違うものになるのではというアイデアがでてきたのなら、会社で、皆で考えようとなっていける。

質疑応答

• 正しい問い、別の観点をだすのは難しいがこつのようなものはあるか？
  →おかしいと思うことをおかしいと感じること、ステークホルダーのおかしいと思うことに素直に耳を傾け、前向きに考えるための問いを考えることが大事である。
  企業の中の常識があたりまえと思ってしまうため、外部の新たなステークホルダーを招くことが大事である。
  
  
• 招かれる立場の場合、なにが会社の利益になるかわからずに参加することになる。利益を示さないと上司の承認がもらえないが参加者はボランティアでくるのか？
  →学びの立場で参加される方が多い。すべてのステークホルダーが利益を考えていると交渉になってしまう。
  最初はボランティアでアウトプットはないが、具体的なアイデアになると会社として何ができるかにつながっていく。
  
  
• 管理プロセスに問題があってそれを改善していきたいという場合は？
  →当事者でも当事者意識が持っていないことが多い。どうしたら当事者意識が持てるのかという問いに変える。
  自分たちで変えないとだめだよねという当事者意識がでるようにもっていく。
  
  
• 自社はいいだしっぺがやれという文化でいいだしっぺがつぶされることが多かったが？
  →社内のステークホルダーが会社を変えないといけないではなく、自分が影響範囲を及ぼせる範囲で、自分自身が問いを考えて自分たちで考えたいと思わせるように問いを伝える。
  外部コンサルとしてはその人自身が孤立せず上司と対話するようにもっていくようにしている。
  
  
• 他部署の人をまきこんだ場合、数が多くなると場をコントロールしにくくなるが少ないほうがディスカッションできるのでは？
  →大人数でやる場合は、アウトプットをださずに同時にこれについて考えて行動が変わることをサポートする。
  デジタルツールとしてスマホのアンケートツールを利用することもあるが、対話に集中するのはツールより実際に話して事務局がまとめるほうがうまくいく。
  
  
• 未来に向かって実行していくにあたり、途中のフィードバックをどうしているのか？
  →バックキャストで出てきたゴールなので間違っている可能性もある。途中途中でＰＤＣＡまわしていく、あっているか確認する対話を実施する、収束するツールと広げていくツールを使い分ける、すすまない理由を考えるセッションをするなどがある。
  
  
• 仕事の大きな枠組みを考え直す時にこのようなやりかたがつかえるか？
  →枠組みをきめて行動するときステークホルダーを巻き込んで行動するというところに使えると思う。

１．最も厳格で欠陥検出効果が高いレビュー手法

• 「レビュー」について、各人で認識が異なっていたり、言葉が合わなかったりすることがあり、議論がかみ合わないことがある。
• 「レビュー」とは、プロジェクトの成果物を作成した人以外が見て、問題が無いかチェックする活動。
• 基本的には間違いを探すことが目的だが、教育したり、修正方法を検討したりすることもある。
• レビューの開催方式としては、隣の人に聞くようなものから会議室に集まって行なうチームレビューまで色々と存在する。
• レビュー対象の特性やタイミングによって、どの方式を採用するか決める。
• レビューは上流工程で行なうことが多いが、下流工程でも行なうことができる。
• レビューを行なう理由は様々あるが、手戻りコストの削減と品質の向上が大きな理由として挙げられる。
• 後工程になるほど手戻りコストが膨れ上がるため、早い工程で、更には工程内でも早い内に修正したほうが良い。
• 手戻りコストを把握しないと、改善効果が分からないため、手戻りコストを測るべきである。
• 作成者は「自分が間違えるはずはない。」という思いから、欠陥に気付けないことがある。
• 欠陥の情報を横展開したり、次のプロジェクトで利用したりすることにより、欠陥予防を行なえる。
• 手戻りコストの削減や品質の向上が大事なことは、作成者も同じ思いであるはずなのに欠陥に気付けない。
  
• 良いレビューを行なうために、「欠陥検出スキルを磨く」「技法・テクニックを使う」「プロセス・やり方を工夫する」「マインドを高める」という4つのことを考え、研究会でも研究している。
• レビューで最も厳格なものは「インスペクション」であり、欠陥の検出効果が最も高いと言われているが、実際に現場で導入できるかと言われると、導入できるほどの余裕が無い現場がほとんどだと思われる。
  →ただし、レビューはどうあるべきかと言うことを考える上では、インスペクションは大変勉強となる。
  
• インスペクションでは、役割(進行役、読み手、検証者、記録係、作成者)が定義されている。
  →実際の現場では、作成者が進行役・読み手・記録係を行なうことが多いため、大変忙しく余裕が無い。
  →二人で行なうレビューで、例えば、読み手は作成者が行なうが、進行役と記録係は検証者が行なうというレビューを行なった場合、若干スムーズに進むなどの効果があった。これ以外にも役割の組み合わせを変えてみるとそれなりの効果がある。
• レビューアは、「作成者」に目を向けるのではなく、「レビュー対象」に目を向けることが重要。
• インスペクションでは、7種類のプロセス(計画、概要説明、準備、集合会議、修正、フォローアップ、振り返り)も定義されている。
• インスペクションの特徴としては、「振り返り」があること。
  →「振り返り」で、欠陥情報を蓄積して次に活かすことができるため、「振り返り」は重要なプロセスである。
• 「進行役」は、レビューの前に、レビューの目的を把握して、時間配分、参加者の調整などを行なう。
• 「作成者」は、質問に答える。また、「読み手」が説明した内容が自分の意図した内容と異なる場合、自分で欠陥に気付ける。
• 「検証者」は、事前にレビュー対象を読んでいることが前提。軽微な欠陥は一覧にして置いておいて、会議の場では、重要な欠陥のみを指摘する。
  →指摘の伝え方は「どこ」「なぜ」「どうなる」の3点セットで伝えると伝わりやすくなる。
• 「読み手」は、事前に読んで理解しておく。会議の場では、分かりやすく丁寧に伝える。
• 「読み手」のポイントは、「事前に」読んで理解して、指摘する時は「大枠から」捉えて詳細に入っていき、「自分の言葉」で言い換えること。
  →読み替えをすることによって、読み手の解釈と検証者の解釈、作成者の意図が合っているのか確認できる。
• 練習問題：「パラパラ漫画付き音楽プレイヤー」の説明を読み、欠陥を探してみる。
  →参加者からの回答：「どんなイラストが出るのか分からない。」「止め方が分からない。」「音がどこから出るのか分からない。」「電源ボタンがどこにあるのか分からない。」「ボタンを押した時に反応するのか、離した時に反応するのか分からない。」
  →読む人によって解釈が変わってくる。読み手は、自分の解釈した言葉で言い換えて説明することが重要。

２．レビューの現場で困っていることとは？

• 質問：レビューについて、現場で何が課題ですか？
  →参加者からの回答：「参加者が集まらない。」「形式的で工夫がない。」「工数が取れない。」「適切な人が参加できない。」
• レビューオリエンテーションキット作成メンバー内で検討して、レビューで大事なことを4つのカテゴリーに分け、それぞれベスト6を選んで、合計24個リストアップした。
  →課題そのものもあるが、解決へのヒントもある。
  →覚えるのが大変なので、「レビューカルタ」を作ってみた。
  →何かキーワードを出して、改善する方法が何か無いかをレビューカルタを使用して考えると良いのではないか。
• レビュー分科会で課題の調査を行なったところ、「プロセス」に関する課題が一番多かった。
• プロセスの課題として、そもそもレビュー工数の指標が無いというものがあった。
• 指標があれば、計画に盛り込めるので工数が確保できる。
• テクニックの課題として、属人性があるというものがあった。
  →優秀なレビューアに仕事が集中してしまうため、その人だけが忙しくなってしまう。
  →色々な人が、欠陥の検出能力が上がれば、優秀なレビューアも少しは楽になるはず。
• スキルアップの課題として、若手が育たないというものがあった。
  →そもそもレビューの教育を受けたことが無いという人が多い。
  →自社では、最近、レビューの教育に力を入れるようになってきている。
• マインドの課題として、レビューがつらいというものがあった。
  →司会者が「お互い尊敬して言葉遣いには気を付けましょう。」など一言言うだけでも雰囲気が大きく違ってくる。
• 一番の課題は、「課題が無い」ということ。課題があるのに気付いていないということ。
• 課題を可視化して、みんなで共有することが重要。
• 社内では、「あるある診断ツール」を使用して課題の可視化を行なっている。
  →どこに課題があるかが分かる。また、メンバー間で各々が持つ課題の偏りを発見することができる。

３．レビュー分科会で考案した解決策

• レビュー分科会で考案した解決策の詳細については、成果報告やSQiPライブラリを参照していただきたい。
  ※SQiP研究会 成果報告：http://juse.or.jp/sqip/workshop/report/index.html
  ※SQiPライブラリ：http://www.juse.jp/sqip/library/
  
• プロセスに対する解決策として、レビュー戦略マニュアルを作った。(2013年度)
  →そもそも具体的なレビュー計画を立てていないプロジェクトが存在する。
  →単に計画を立てるだけではなく、もっと戦略的に立てましょうと言うもの。
  →社内で見てもらったところ、「何を書けば良いのか分かった。」「観点の絞り込み方が分かった。」「レビューを分割で行なうなどのやり方が分かった。」などの声が聞かれた。
• プロセスに対する解決策として、レビュー会議の可視化を行なった。(2016年度)
  →レビューの中でどのような会話が行なわれているか可視化することにより、レビュー会議が目的通りに行なわれているのか把握できる。
• テクニックに対する解決策として、仮説駆動型レビュー手法(HDR法)を考案した。(2012年度)
  →優秀なレビューアは、重大な欠陥をピンポイントで早く見つける。
  →優秀なレビューアは、まず兆候を見つけようとする。そして、狙いを付けて見に行く。ただし、ゆっくりではなく、様々な兆候を捉え、たくさんの仮説を立てて検証を行なっていくという作業を高速で行なっている。
  →後続研究で、普通の人でもできるように「欠陥連鎖チャート」を考案した。
• スキルアップに対する解決策として、欠陥パターンと検出テクニックのトレーニング法を考案した。(2015年度)
  →CHOCO-TRE(チョコ・トレ) ：兆候欠陥パターンドリル。
  →こういう欠陥ならばこういう風に見つければ良いというというテクニックをドリル形式で学習していく。
  →設計書の場合、ある機能とある機能を比較して、一方の機能では記載されているが、もう一方の機能では記載されていないということをマトリクスにして見つけるテクニック。
• スキルアップに対する解決策として、ドメイン知識を向上させるトレーニング法を考案した。(2014年度)
  →実際の成果物と実際に出た欠陥情報から教材を作成してトレーニングする。
  →欠陥情報にはポイントが付いている。重大な欠陥には高いポイントが付いており、ポイントの高い欠陥を見逃した場合、その見逃した欠陥の影響度を確認することにより、失敗の疑似体験ができる。
  →同じ失敗を3回体験すれば覚える。
• スキルアップに対する解決策として、レビューア向けの思考能力トレーニング法を考案した。(2016年度)
  →基礎となる能力とは何かを考え、「要約力」と「仮説力」がレビューアには必要であると考えた。
  →社説を使って、5分で要約することにより要約力を高める。また、社説と自分の持っている知識を利用して何らかの仮説をどんどん立てていくことにより仮説力を高めるというトレーニング法。
  →今年の研究員に対して行なったところ、「仮説を立てる思考の癖が付いた。」「欠陥の発見スピードが上がってきた。」「欠陥につながる仮説がたくさん出てくるようになった。」という声が聞かれた。
• 質問：レビューアに必要な能力は何だと思いますか？
  →参加者からの回答：「どんな使われ方をするのか、文章の中に書いていないことと書いてあることをつなげた時に妥当なのかを想定する力としての「発想力」。」「思いやり。」「作成者の思いを想像する力。」
• マインドに対する解決策として、レビューオリエンテーションキットを考案した。(2011年度)
  →初心者向けの教材。
  →注目すべきところは「心構え」について書かれていること。
• マインドに対する解決策として、作成者の抵抗感を軽減する手法を考案した。(2016年度)
  →特に第三者がレビューした場合、なかなか聞き入れてもらえない。
  →事前に問診によって作成者やプロジェクトの状況を把握して、抵抗感を軽減させる工夫を行なう。
  →伝え方も大事である。
• 質問：現場で使えそうなものはありましたか？
  →参加者からの回答：「インスペクションは難しい。ただ、一度試してみて、部分的に取り入れてみたい。」「作成者の抵抗感をなくす手法は取り入れてみたい。」「ちゃんとレビュー計画を立てて、レビューを行なっていくべきだと思った。」「レビューカルタは使えそう。」「レビューア向け思考能力のトレーニング法は取り入れてみたい。」
• 自身も以前、インスペクションで読み手を行なったことがあった。
  →しかし、読み手が作成者に聞きに行って、事前に認識合わせをしてしまい、インスペクションにならなかった。

４．レビューの現場でどうすればよいか？

• やはり、勉強は大事。
  →過去の知見を得ることは重要。
• 現場の現状を把握すること。
  →何となく課題に思っていても何ともならない。
• 意味のあるメトリクスを取っていくことが重要。
• 正しいデータを使わないと、分析しても意味がない。
• 新しい手法の発明が必要。
• 現場で実践してみることが必要。
  →仲間を見つけて一緒にやる。
• レビューではマイナスの部分ばかり言うが、レビューアはマイナスの部分以外にも色々と考えているはずなので、そのことをぜひ伝えてほしい。
  →自分の思考を隠さないで、ぜひオープンにしてほしい。
  →プラスもマイナスも口に出して伝えてほしい。
  →マイナスが無くなった時、みんなの願いが叶う。
• "CHANGE"は"CHALLENGE"の中にある。
  →より学んで、みんなを導いて、品質意識を高めていただきたい。
• リーダー(最初に行動を起こす人)は異質な存在かもしれませんが、「いいね！それ！」と言ってくれる人を見つけたら、その人を大事にして、一緒に進めていくことが重要。また、自分がリーダーにならなくても、何か良いことをやっている人を見つけたらフォローすることが重要。
• SQiP研究会での経験を重ねていって、現場のリーダーやフォロワーになっていただきたい。

質疑応答

• (講義中に行なった)手品の種明かしをしてほしい。
  →トランプのJ,Q,Kは、全部で12枚ある。代表者に最初に渡した6枚と、1枚選んだカードを当てる場面で渡した5枚は別物である。5枚の中に抜いたカードは当然無いので、代表者に「何を選びましたか？」と聞くと、答えを教えてくれる。そこで、「あなたの選んだカードはこれですね。」と答えを聞いたカードを示す。
  →言いたかったのは、作成者は選んだカードに集中しているので、周りのことは気にしないということ。
• 読み手の役割は非常に重要だと思うが、読み手の解釈がずれすぎてしまった場合はどのように収拾するのか？
  →読み手のレベルが低いという問題に対しては、レビューの目的に合った人を割り当てるということが重要。レベルを合わせる必要がある。
• 「俺はこう思う」と強く言うような人が出てきて話がまとまらなくなるというような場合はどうすれば良いか？
  →その点に関しては、心構えの部分だと思う。「誰が正解だと決める場ではないですよ。」などとレビューの心構えを事前に言っておくしかないと思う。
• 立場的に強い人が話を全て持って行ってしまうような場合はどうすれば良いか？
  →事前にある程度チーム内などで一回揉んだ上で、チームの合意ということで話を持っていく。それでも何か言われたら、どこまで受け入れるかは一度持ち帰ってチーム内で検討するというような対策を取ってみると良い。
  →ピアレビューを行なう際は、「仲間内で行なうレビューなので、上司の方は参加しないでください。」というのも一つ。
  →実際は、上司が有識者などの色々な役割を持っていることが多いので、「今日は有識者として参加してください。」などというのも一つ。
• レビューの準備という点で重要なことは何か？
  →インスペクションでは、レビュー対象を事前に提出するということが原則。
  →開始基準をきちんと設定して、まず見るかどうかをチェックする。「このレベルだとレビューできません。」というように全部をレビューしないことも大事である。

１．今、何が起きているのか　～プロジェクトを取り巻く環境とその変化～

VUCA時代（現在の社会環境が極めて予測困難な状況に直面している時代）なので、ＰＭも明日何がおこるかわからないという状況を背負っている。
システムトラブルのニュースも多いが、要件定義の不備など昔から原因は一緒で進歩しているとはいえない。
また、他の業界から見ると同じミスを繰り返す理由が理解できないと思われる。
工業製品と比べて人為的なミスが入り込む余地が多いことや、とりあえず作って直すというIT業界の体質も要因である。
状況を根源的に変えられなければ、グローバルにも取り残され、日本のIT産業はこのまま厳しい状況に追い込まれる。

２．今、何が求められるのか　～PMの素養と立ち振る舞い～

• 顧客企業が私たちに求めることは、顧客が作ろうとしているサービスの価値を一緒になって考え、システムのデリバリを安定的に導くリーダーシップを持った人材または企業である。
• その中心をなす存在がPMであり、優秀なPMを求める声は以前にもまして大きい。
• 今日のPMは、実に多くの能力が求められるが、能力開発の面では、未開拓の領域もまだまだ多い。今後は特にVUCAの時代ならではの柔軟性、俊敏性、創造性も必要となるだろう。
• PMの作業の実態の調査を行なったところ、理想と現実の乖離があり、思うように仕事ができていないということが分かった。
• 私はPMの能力は、Resourcefulness（人としての魅力、振る舞い、情熱、責任感、使命感：ビジネスパーソンとしての地盤の強さ）をベースに、Skill（見聞を広め知識を高める力：個々人の知識量の査定結果を利用する軸）、Performance（変化に対応し結果を出す力：成果主義的な観点に加え、変化に柔軟に適応できる能力を示す軸）、Knowledge（知恵や実績から知恵を生み出す力：経験や実績を通して利用可能なナレッジ、知恵を生み出す能力を示す軸）の３つの軸の総量（R＋S×K×P）で定量化できるのではないかと考えている。
  しかし、現状のPMの育成はS軸一辺倒であるという偏りがある。
  また、Rの領域を定量化している会社は少ない。
  KとPの領域は個人で取り組むには限界があり、チーム・組織・企業・社会で取り組めればよいが現時点では課題である。
  どの軸も固定ではなく、時代によって変化する。
• 能力モデルを整理したことで、知恵と実践の強化の必要性が浮き彫りになった。

<質疑応答>

• ４つの軸というのは共感できるが、R軸、K軸、P軸を定義することができるのか？自社の取り組みでパフォーマンスを上げるツールを導入したが、説明をドキュメント化すると堅苦しくなり、実際には使われにくいものとなってしまったことがある。
  →定義をドキュメント化するとしたら、シンプルなものになると考えている。実際の取り組みとしても会議で出る意見をホワイトボードに書いてもらうと、はじめは聞いたそのままを記載するが、徐々にまとめられるようになり、ヒアリング力が上がったり表を書く力が上がったりする効果があるなど、原始的な取り組みがきくと考えている。

３．常に勝てない理由とは　～想いと行動の間にあるカベの正体～

• プロジェクトを成功させるために、企業は様々な取り組みをおこなってきたが、冒頭で示したように、トラブルは後を絶たないのが現状である。
• 逆に仕組みや道具立てがありすぎて、思考停止になっている組織が多いことは、そもそも問題であろう。
• さらに業界の悪しき慣習（とりあえず作って直す）が構造的な問題を引き起こしている可能性も否定はできない。
• 一方、プロジェクトと一口に言っても、その形態はさまざまで、特性をしっかり見極めることが極めて重要である。（ここの理解が進まないこともトラブルの一因）
• ここでは、常勝を考えるうえで突破しなければならない組織側の論理に目を向け、例えば、「プロジェクトの特性に合わせた丁寧な体制づくりができないか」をテーマに、思考停止の壁を破る一案を探ってみた。
• 思いと行動にはカベがあり、行く人、行かない人、前のめりに行く人などがいる。なんで行かなかったのかというカベの正体を知り、カベを破って踏み出さないといけない。論理・理性だけでは勝てない時代だが、ビジネスはロジカル一辺倒で直感的にとらえる感覚を置き去りにしている傾向がある。PMは直感的なところで気づく場合もあるので、直感で動いてデータで確かめる必要がある。データで語ると相手が行動する。
• PMは地べたにいるのではなく、おかしいなと思ったら全体像を上空10メートルで見渡す感覚が大事である。
• PMのアサインは論理性を欠く場合が多い。業界、金額規模などプロジェクト特性が変化するのであるからPM特性も変わるはずである。プロジェクトの特性に応じた丁寧なオーダーでPMをアサインし、チームを作るのが大事である。 プロジェクトの特性に合わせた丁寧な体制づくりができないか？

４．知恵と実践は伝承可能か　～プロジェクト版マネーボール考～

• 多様なプロジェクトを、不確実な環境下で成功に導くには、PMを個人として育てるのではなく、ひとつの機能群として捉え、組織やチーム全体で成功確率を上げていくのが妥当と思われる。
  →チームのスキル総量が上がるようにする。
• このような考え方では、知恵と実践のバリエーションをそろえ、その再現性を上げていくことが急務となる。
  そのためには、向かう方向を明らかにし、わかりやすい指標でクイックに行動を導くことが、PMチームの最重要課題となる。
• ここでは、マネーボール型アプローチの取り組みを紹介し、知恵と実践の再現法への理解を深めていただくようにした。
• 映画「マネーボール」は、ブラッドピッドが主演した、米メジャーリーグの弱小貧乏球団を強くするため、野球界に革命を起こす様子を実話に基づいて描いた映画である。
  それまでは、熟練のスカウトが経験と勘で採用していたのを、出塁率が高くて年俸が安い人を採用し、年俸が高くて出塁率が低い人を放出するということを実行し、最後にワールドシリーズを制覇するというストーリーである。
  ITプロジェクトでも、ビジネスにおけるねらいに対して、目的を明確化→本質的な要素を発見→対象が見つかって手ごたえを得られるまで繰り返す、ただし、目的につながること以外は無視するということをすればいいのではないか。
  PM個人でなく、機能群としてとらえ、組織やチーム全体で成功確率を上げるのが大事である。
  知恵と実践のバリエーションをそろえ、再現性を上げ、向かう方向（優勝）、わかりやすい指標（打率）で行動を導くというマネーボール型アプローチのプロセスをやってみてほしい。
  常勝PMの育成は可能かという問題の結論として、PMの育成からPMチーム（共同体）として育成し知恵と実践の再現性を向上するアプローチをとることで可能となると考える。
  環境・文化・雰囲気をはぐくんでプロジェクトを健康体にしましょう。
  まずは行動しよう。

<質疑応答>

• 「プロジェクトの全体像を上空10メートルで見渡す」というが、この「10メートルの高さ」のイメージがつかないがどういうことか？自社では地べたで先頭を走る人か雲の上で観察しているかの両極端で、PMの関わり方のイメージがわきにくい。
  →羊飼い型、後ろから追い立てる型などマネジメントスタイルは色々だが、全体をみえてないといけないということ。やるべき目的は一緒なのでいろいろやってうまくいったものをのこしていくしかない。
• 体系的なＲやＰを育てる方法があるか？
  →Ｒは勉強できることではないので座禅とかマインドフルネスとかやって自分を育てるしかない。
  Ｐは、観ること聴くことは難しい。
  自分の体験談であるが、街角のスターバックスから複数人で、行きかう人々の観察した結果を持ち寄ると、観ていた部分が皆ばらばらだった。
  しかし、観ることを続けるといずれ結果が出る。五感を使って感性をあげていくというようなイメージだと考えている。

１．人工知能とソフトウェア工学の歴史

• 「ソフトウェア工学」という言葉が初めて出てきたのは、1968年のNATO会議。
• 当時、「地球に住む人類全員がプログラマーになっても足りないのではないか」という「ソフトウェア危機」が叫ばれていた。
• 1970年代は、構造化プログラミング、構造化設計、構造化分析などが行われていた。
• 1980年代に入ると、プログラミングからソフトウェア開発・品質管理へという輪が広がっていった。
  また、日本では、ソフトウェアをシステマティックに作りましょうという「ソフトウェア工場」という考え方が広まっていった。
• 1990年代に入ると、オブジェクト指向、CMM、PMBOKが出てきた。
• 2000年代に入ると、アジャイル開発、ソフトウェア分析・検証技術の実用化が行われていった。
• 2010年代に入ると、IoTでつながる世界のソフトウェア工学が発展してきた。また、クラウドネイティブやDevOpsという考え方が広まってきた。
• ソフトウェア工学の発展によって、生産性に対するソフトウェア危機は解消したが、ディペンダビリティ(信頼性)が大きな課題として残っている。
• ビジネスがあってサービスがあってソフトウェアがあるため、ビジネスデザインが重要となってきている。
• 「人工知能」と一口に言っても、人間の推論や意思決定過程を真似る「狭義の人工知能」と通常の計算処理を用いて人間が考えて行った結果と同じ結果を生成する「広義の人工知能」がある。例えば、計算機での人間の作業の自動化は、「人工知能」とは言い難いように思うが、この定義に当てはめれば「(広義の)人工知能」であるとも言える。
• 「人工知能」は、1956年のダートマス会議で初めて提唱された。
• 1960年代に、第1次人工知能ブームが起きた。
• 1970年代に、「エキスパートシステム」(専門家の思考や判断を計算機上でシミュレートするシステム)が開発された。
• 最初の頃に出てきたエキスパートシステムは、医者が行う診断を代わりに行ってくれるシステムだった。
• 1980年代に、第2次人工知能ブームが起きた。
• 1990年代に、データマイニングの技術が発展したり、掃除機の「ルンバ」のような自律ロボットの初期型が登場したりするようになってきた。
• 2000年代に、ビックデータの活用や深層学習(ディープラーニング)の提案が行われた。
• 2010年代に、第3次人工知能ブームが起きた。
• 深層学習が実用化され、今では音声認識や画像認識、AlphaGo、IBMワトソンなど実用例が多数存在する。
• 最近では、人工知能ツールがオープンソース化されている。
• 「人工知能」には、人間の脳の機能全体をシミュレートするような「汎用人工知能」と特定の領域で知的な処理を行う「特化型人工知能」があるが、本講義では後者を対象とする。

２．論理に基づくソフトウェアの設計・検証

• もともとソフトウェア開発は人間の知的な作業であるため、それを計算機で支援するということは「(広義の)人工知能」そのものであると考えられる。
• 人工知能のためのソフトウェア工学の議論として、人工知能(機械学習で獲得したモデル)に基づくシステムの品質はどうやって担保すれば良いのかという議論がある。
• 第2次人工知能ブームの頃に「Readings in Artificial Intelligence and Software Engineering」(人工知能とソフトウェア工学)という内容が非常に良くまとまった本が出版された。
• 究極的なプログラミングの自動化は、話をしていれば汎用人工知能がプログラムを作ってくれることだが、大変難しい。
• 自動化のレベルも曖昧な顧客ニーズからプログラムを生成する、顧客の要求仕様から生成する、ソフトウェア設計仕様から生成するなど色々ある。
• 仕様からプログラムを生成する手法として、定理証明という数学的手法を利用した手法がある。
• 定理証明手法によるプログラミングは、プログラミングとは仕様を満たす解を証明するということであり、証明過程自体がプログラムとなっているという考え方に基づいている。
• 研究としては良かったが、仕様を論理式で全て書くことは難しい。
• ただし、プログラムはプログラムで書いて、満たすべき性質(仕様)は論理式で書いて仕様に対するプログラムの正しさを検証するというアプローチは有効であり、実用化されている。
• 1996年当時、論理回路の方ではモデル検査法が使われていたが、ソフトウェアで使ったのは日本では我々が最初ではないかと思われる。
• プログラム変換とは、人間にとって分かりやすいプログラムをより効率的なプログラムに、正しさを保証しながら変換すること。コンパイラもこれに近い。
• 例からのプログラム生成とは、プログラムの入力と出力の例を大量に入れると、与えられた例を満たすプログラムが生成されるという手法。機械学習にもつながる手法である。
• 超逐次プログラミングとは、並列処理も極めて高度な逐次処理としてプログラミングすることで並列処理によるデッドロック問題を回避する手法を提案したもの。この手法には試験したデータ以外のデータが入ってきた場合に回避する仕組みをプログラムに埋め込んでいる。ただし、試験したデータのみでしか動かないとなると、使い物にならないので、ある程度動く範囲を拡張する必要があり、その許容範囲の設計が要点となっていた。
• 知的なプログラミング支援の例として、CASE(Computer-Aided Software Engineering)がある。
• 人工知能システムのためのソフトウェア開発技術がソフトウェア工学の発展にも貢献してきた。
• プロジェクトマネジメントへの人工知能の応用は、1980年代から取り組みが行われてきた。

３．ソフトウェア工学・品質管理における機械学習の活用

• 実証的ソフトウェア工学(Empirical Software Engineering)とは、ソフトウェア開発に関するデータを収集し、その定量的/定性的分析に基づき、ソフトウェアの品質や生産性の改善を行う工学である。
• 見積りを人工知能や協調フィルタリング法で行おうという研究も行われている。
• 研究室の学生の研究で、品質ドキュメントの記述レベルと障害率の関係を調べたところ、きっちりと障害管理票を起票して運用しているプロジェクトほど、障害率が低くなることが分かった。障害管理票の中身は調査せず、形式が正しいかだけを調査しただけであるにもかかわらず、このような結果が出たことは興味深い。人工知能で障害管理票を集めて形式を認識することだけによっても品質を予想できる可能性がある。
• 研究室の別の学生の研究で、要件や仕様の変化によるプロジェクトの工数等への影響を調べ、要件や仕様の変化による変動の可視化を試みた。この研究では人工知能は利用していないが、人工知能が利用できれば大量のデータを処理することが可能となり、精度を高くできるのではないかと思われる。
• ソフトウェア工学への機械学習の適用例として、予測と推定、ソフトウェアの特徴の抽出、ソフトウェアの変更、テストケース作成、再利用ライブラリの活用、要求獲得、ソフトウェア開発知識の獲得が挙げられる。
• 機械学習による予測と推定の例として、バグの多いモジュールの推定、ソフトウェアの規模の予測、開発コスト/工数の予測、メンテナンスの工数の予測、ソフトウェアの信頼性の予測、再利用性の推定等が挙げられる。
• 2018年発表予定の論文で、ソフトウェアの欠陥の予測に深層学習(ディープラーニング)を使うと精度が上がったという報告があった。
• 従来型のモデルはモデルの説明が可能である場合が多い。解釈可能性があるということが重要。
• ニューラルネットや深層学習で出てきた結果に対しては解釈可能性が低い。
• 機械学習(予測・推定)の結果を利用する場合、機械的に利用するだけではなく、人間が解釈して利用したり、気づきの支援として利用したりすることが重要。
• 論理アプローチ、機械学習(データアプローチ)、経験アプローチの3つのアプローチに対して役割分担を明確にして、仕組みとして作り上げていくことが今後のプロジェクトマネジメントでは重要となってくる。
• 2017年3月のプロジェクトマネジメント学会でも、人工知能を活用したプロジェクトマネジメント支援についての発表があった。
• IBM Watsonは、自然言語をうまく使えるメカニズムがあるところが従来の機械学習と大きく異なる。
• 富士通では、「KIWare」というSEが持つ知見を体系化した業務支援ツールを開発したことを公表している。
• 機械学習による定量的管理にはまだ困難や課題が多い。例えば、人間の経験など計測が難しい要因があることや過去のデータを扱っているため、想定外の事象には対応が難しいということ等が挙げられる。

４．サイバー・フィジカルシステムのためのソフトウェア工学・品質管理

• サイバー・フィジカルシステム(CPS:Cyber Physical System)では、データがクラウド側に行って処理されるということが重要。
• クラウド側で行う知識処理は、情報収集(データ→情報)、情報分析(情報→知識)、情報活用(知識→価値)の3種類が存在する。
• つながる世界となってくると、色々なシステムと連携して動くことになる。また、こちらからは制御できなかったり、動的にシステムが変化したりする。このような中で品質保証をどのように行っていくのかということが課題として大きくなってきている。そこでは「オープンシステム・ディペンダビリティ」の概念が重要になる。
• 「オープンシステム・ディペンダビリティ」とは、実環境の中で長期的に運用されるシステムが、その目的や環境の変化に常に対応し続け、システムに関する説明責任遂行を継続的に支援しつつ、利用者が期待するサービスを継続的に提供し続ける能力のことである。
• DEOS(Dependability Engineering for Open Systems)プロセスは、予めゴールを設定しておけば、想定外の状況が発生した場合でも問題をシステマティックに判定することができ、時間をかけることなく対応することができるだろうというコンセプトで開発された。
• 運用時のモニタリングは機械学習の得意とする分野。
• つながる世界の品質保証については、ぜひ日科技連でも検討してみると良いのではないか。
• ミッションクリティカルシステムで機械学習を利用する場合、品質をどのように担保するのかということが大きな課題となる。
• 機械学習を行う人工知能の品質管理を考える場合、学習・テストデータの品質、機械学習アルゴリズムの品質、アルゴリズム・モデル実装時の品質、人間系を含むシステムとしての品質を考える必要がある。
• 学習・テストデータの偏りの例として、自動運転のアルゴリズムに対する学習データとして日本の交通事情を使用した場合、このアルゴリズムをインドで利用しようとすると、交通事情が異なるため使えないということが挙げられる。
• 表計算ソフトの操作ミス等でインプットするデータに加工ミスがあっても、統計的に有意であれば、ミスであることに気付けないといった問題がある
• 機械学習にはオーバーフィッティング問題が存在する。つまり、与えた学習・テストデータに対しては非常に良い結果が得られるが、入れなかったデータに対しては極端な結果を返す場合がある。
• アルゴリズムの妥当性を何らかの方法で可視化して確認する必要がある。
• 想定外の状況が発生した場合のフェールセーフの仕組みを考えていかなければならない。
• これからは、ビジネスモデルの品質保証が大事になってくると思われる。お客様にとって魅力的であることや、ビジネスをするお客様が儲かる仕組みになっているかというところまで確認する必要性が増す。
• 我々は、アイディアを生んで、それをシステムに落とし込んで、ビジネスモデルを作るというプロセスを同時並行的に行うという「イノベーションデザイン」を提案している。
• イノベーションデザインとその検証には、ウォーターフォール開発に基づくVモデルは適さない。ビジネスのゴール(仕様)とシステムと外部環境という三つの要素間に生じるギャップを監視しながらギャップを検出・分析して埋めていくことで開発するべきであると考える。この開発モデルを我々は「ダイナミックYモデル」と名付けて提案している。
• DevOpsの時代になってくると、極端な話では、朝思いついたアイディアが昼に実装され、夜になったらリリースされるという状況になり得る。このような場合に、どのように品質保証を行うのかということが課題となってくるので「ダイナミックYモデル」の適用が必要となってくる。
• まとめとして、ソフトウェア工学への人工知能の適用は実は昔から行われてきており、今はその延長線上である。
• 従来型の人工知能と人間の気づき(を支援するシステム)とをシステマティックに組み合わせて、人工知能をもったシステムを品質保証して利用できる仕組みを考えていくことが今後重要性を増す。
• 第2次人工知能ブームの時にできたユーザーインターフェースが当たり前になっているように、今後出てくる技術が、10年、20年後の品質管理の当たり前になっていると思う。

質疑応答

• 遺伝的プログラミングとは何か？
  →遺伝のメカニズムを利用した最適化手法。ある問題があった場合に、プログラムを遺伝子のように見なして、かけ合わせることにより、最適な解を見つけ出す手法。山登り法という手法があるが、最適解ではなく、局所解に行ってしまう場合もあるという問題があるので、このような最適化手法が提案された。
  
• 第3次人工知能ブームでは、サイバー・フィジカルシステムやオープンシステムの品質保証が課題という話があったが、第2次人工知能ブームの時に、このことが想定されていたか？
  →第2次人工知能ブームの時から、世の中の知識をコンピューター上に落とそうという議論はあった。
  →現在の人工知能ブームで言われていることはある程度は想定内であった。
  　→ただし、オープンシステム・ディペンダビリティという考え方は無かったと思われる。
  　　→自分達もWebが使われ始めた頃は、ここまでつながる世界が拡がるとは考えていなかった。
  
• 内平先生の研究室に来ている社会人学生の年代や勤務先での所属部署は？
  →東京で開催している社会人コースでは、情報メインのところとマネジメントメインのところがある。
  　→情報の方は若い方が比較的多いが、マネジメントの方は平均年齢が42歳となっている。
  　→マネジメントの方にはリタイア間際の方も在籍しており、企業の中で長年培ってきた知識を体系的に整理して論文として残し、後輩に伝えていきたいという想いの方もいる。
  　→役職としては、係長・課長・部長の方が多い。
  　→業種としては、IT系が半分だが、ホテルや建設会社などに勤めている方々もいる。

１．ソフトウェア工学の中の要求

• 1968年のNATOの報告書で「ソフトウェアエンジニアリング（SE）」という用語が導入された。
• その後、SEより広範囲な言葉として、「SystemsEngineering」という言葉が使われるようになった。
• 2001年にIEEEとACMがソフトウェアエンジニアリングの知識体系を“SWEBOK”として整理し、2013年にVersion3.0を発行した。
• “SWEBOK”は重量級であるため、自分は、「Software Engineering 10thEdition」（Ian Sommerville）をよく使う。

２．要求とは何か

• “Requirements”は、システムがなにを提供してくれるのか、その制約は何かを示したものである。
• “Requirement”や「要求」は、辞典によってさまざまな表現をされ、「要求」や「要件」も人によってどう使い分けているのかが異なる。
• 要求を理解することは、開発者にドメイン知識がないと難しいが、開発者も要求者である場合（例：ウォークマン）、自分の要望が入ってしまうことで、それを邪魔してしまうこともある。
• ビジネス要求やプロダクト要求をシステム要求、ソフトウェア要求にかえ、それを機能要求、非機能要求にしていくことが大事である。
• 要求がなぜ大切なのかは、失敗プロジェクトの原因が要求である場合が多々あり、その場合、修正コストが高くつくことからも明らかである。
• 世界的には上流志向だが、日本では多くが下流志向である。
• どの段階の変更でどれだけのコストがかかるかをデータとして取得していると、要求にかける意気込みが違うものになると考えている。
• 自社では、スマホのボタンをいつどれぐらい押しているかのデータをとったり、ロシアとかイギリスとかブラジルとかの一般家庭に訪問して聞き取り調査したり、WEB上のコミュニティーサイトでユーザーを巻き込んだりした結果を要求に反映している。

３．要求工学の項目、とくに要求の仕様化について

• 自社の組織において、要求および要求工程の課題として何があるのか、要求の概要はどのようなものかというようなことを網羅的にしっかり考えるのは大変だが、やる価値があることである。
• 要求のプロセスは、“Requirements elicitation” “Requirements specification”“Requirements validation”の3つの柱があり、順番に実施していくとドキュメントが生まれる。
• Wモデルによる開発を実施して、仕様の妥当性を早い段階で考えていく必要がある。
• アジャイル開発手法の一つであるSCRUM開発では、要求はプロダクトバックログが要求やアイデアが蓄積されたものであり、スプリントごとに、5-10％の時間をかけて、バックログのRefinementをする。
• 皆さんの仕事で要求のプロセスを考える場合、まずは仕事全体がどういうプロセスとなっているか考えてから、要求に関係するプロセスを取り出してどうなっているのか考えることが大事である。
• 要求獲得の方法として、「エスノグラフィー」という　フィールドで起きていることをモデル化する手法がある。
• そのソフト、アプリ、製品を使う人のところに行って観察したり、会社に行ってみて一緒に仕事してみてどういうシステムがあればいいかを考えるといいものができる。
• ユーザーストーリーマッピングという手法もあるが、2018年12月14日に楽天川口様に特別講義をしていただく予定である。
• 「体験」というのはユーザーの個人のものであり、どんな「体験」をしてもらうか計画し、体験が量産、再生産される仕組みを作ることへ変化していると感じている。
• 要求の仕様化には、自然言語による文、構造化された制約した自然言語（USDM、SBVRなど）、図記法（UMLなど）、数学的記法（形式手法など）があるが、どう組み合わせて記述するかは課題の一つである。
• IEEE830の「SRS(Software Requirements Specification;要求の仕様化)」に対する推奨プラクティスをおさえておくとよい。
• 仕様の課題として、要求と仕様がまざるなどの問題がある。
• 仕様を構造化することが重要である。
• 文書体系の構造化の項目の例として機能名、概要、入力、出力、事前条件、事後条件、不変条件の項目などがある。
• 手段として、数学的記法がある。
• 仕様化する場合は、最初に抽象度を決める必要がある。内容を曖昧にするか厳密にするかの調整を行ったとしても、抽象度は変更してはいけない。
• 仕様書は、仕様(What)のみを記載して、設計(How)は混在させず、抽象度が同じであるべきである。
• 自社で、要求の仕様化はどうやっているのか、　要求の妥当性確認はどうやっているのか、要求の管理をどうしているのかなどを考えてほしい。

４．聴くことについて

講義の持ち時間が無くなってしまったため本テーマの講義手前で終了。

<小池委員長から>
要求の分野は、理系スキルから文系スキルまで広範囲のスキルが必要であるが、ぜひ、来年度のSQiP研究会で一緒に学びましょう。