• ゴールドラット博士のTOC(Theory Of Constraints)開発
  TOC(Theory Of Constraints)は「手法」ではなく「理論」、つまり、予測することのできる普遍性をもつ体系的知識。TOCは物理学をベースとした再現性のある科学である。

• 「つながり」と「ばらつき」
  あなたの仕事は他の人や組織と、つながって行われていますか？
  それぞれの人や組織の能力は一緒ですか？ばらついてますか？
  →仕事は横に流れているのに、管理は縦で行われている
  →非常に非効率


• 制約→ボトルネック→希少リソース
  次のような流れで進んでいく作業があったとする
  例）あるハウスメーカー
  [市場]→営業→設計→生産管理→工場→工事→[売上]
  
  工程毎の1日の生産量が次のような状態だとしたら、全体の1日の生産量はいくつになるか
  20→15→10→12→16　 回答)10にしかならない
  他の部署が頑張れば頑張るほど、希少リソース(10の箇所)がひっ迫する
  
  全体の制約に集中することが全体最適となるTOC (Theory Of Constraints)
  非制約に力を注ぐことはムダとなるため、Focus =Not to do ＝「今はやらないこと」を実現する
  端的に言えば、みんなでよってたかって希少リソースを助けるということ


• 実験
  3つ同時に仕事がやってきたとする。（実際の現場でもよくあるパターンではないか）
  仕事A：1～20までを紙に書く
  仕事B：A～Tまでを紙に書く
  仕事C：△〇♢の順で紙に20個書く
  
  仕事を1つずつやれば60秒あれば完了する（20秒×3仕事）はずだが、上司から全部最優先という指摘をされる
  1,A,△,2,B,〇…の順で紙に書いていくと60秒では終わらない。
  →納期超過、品質劣化の原因


• 組織の中で最も重要なものは優秀な人の時間
  早く始めれば早く終わるというものではない
  仕事そのものは変えない。やらないものを決める。仕事の進め方を変える。
  的外れな改善は会社にダメージを与えることになる

• フルキット（Full Kit）という考え方
  コンセプトを定めて決めたもの以外は手を付けない


• 経済産業省「2005年版組込みソフトウェア産業実態調査」より
  
  品質トラブルの原因は？
  →3分の１はソフトが原因
  計画通りの品質のソフトが作れましたか？
  →3割が計画の品質を下回る
  仕様は守れましたか？
  →４分の１が開発途中で機能を削減
  納期は守れましたか？
  →半分以上が納期遅れ
  予算は守れましたか？
  →半分以上が予算オーバー
  
  15年経って、これらの課題は解決されているでしょうか？


• ソフトウェアの重要性は増している
  車、飛行機、スペースシャトルなど
  5年前と比べてあなたのプロジェクトは
  
  • ソフトの重要性はますます増してますか？
  • 仕様はますます複雑になっていますか？
  • 期限はますます厳しくなっていますか？
  • 不確実性はますます増していますか？
  • 一人でできることはより少なくなっていますか？
  • 組織をまたいで仕事をすることはより多くなってますか？
  5年後にはソフトウェア開発がボトルネックになる可能性がある。


• 業者天国の開発
  
  社員1人あたり、7～8人のパートナーで複数のチームに分かれて開発
  全体を考えずに重要度・難易度の高いものは後回しでできるところから開発
  何度も再検討や仕様変更が実施されソフトウェアは完成しない
  プロジェクト全体は進まないが、日々の進捗は進んでいる状態に陥る
  パートナー会社は儲かるが、現場の人は疲弊する
  これはソフトウェア技術者じゃなくても解決できる問題


• 具体的な進め方　（やるならつまみ食いせずに全部やる！）
  
  • 助けてボードを見えるところに張り付け、みんなで支援。つながりフローボード
  • 半日も待たない。とにかくすぐに対応する
  • 集中時間を設ける
  • 優先順位を定める（顧客への迷惑、工場への迷惑、自分のスケジュール）
  • 進捗会議は未来の話をする（過去は変えられない。未来は何とかなる）
    ＜具体例＞
    あと何日ですか？
    →毎日、現場の見積もり力を鍛える
    問題あるとしたら何ですか？※問題なしと報告があった場合でも注意して質問する
    →毎日、現場のリスク予知能力を鍛える
    何か助けられることはありませんか？
    →毎日、現場の考える力を鍛える


• PCDAサイクルは回っていない
  PCDAサイクルはみんな知っているけれどもきちんと回っている会社はほとんどない
  しっかりと計画立てること。やることとやらないことをきれいにすることが最も大切。
  
  PDCAのCA重視マネジャー
  
  →「これお願い。」と丸投げで仕事を依頼するのは楽、あとで文句つけるのも楽。
  　これだと仕事をしている感もあるし、優越感ある。
  →だけども組織にとってそれが本当に自分の望んだ未来なのか？
  →生産性は向上しない
  
  
  PD重視マネジャー
  
  →しっかりやっているのでトラブルも発生せず目立たない。

変えられない過去から、変えられる未来に！マネジメントが変われば、現場が変わる。
品質はプロセスで創られる。結果（不良）出てからでは遅い！
ソフトウェアを開発するのは人である。人の仕事の質向上なしに品質向上なし！
「銀の弾丸はない」かもしれないが、「金の知恵」はある！

＜質問＞
TOCの実施にはフルキットがカギとなるが、フルキットを使ったプロジェクトの進め方について工夫が必要な点があるか。（要求するものが大きくなりすぎてしまい、実現不可能になってしまう事が考えられるが、フルキットはどのように設定したらよいか。）

＜回答＞
ボーイング社では、ソフトウェアの欠陥の数を数えることをやめ、フルキットを実現できているか、作業者の集中時間が管理できているかという点に着目するようになった。
また、毎朝フルキットを確認し、懸念があるか？という質問を繰り返し、懸念がある場合影響の大きいものから解消している。
品質管理は担当者の作業がうまく流れているかをチェックし、仕事の質に着目している。
フルキットの設定は本人。なぜならば、その作業について、当事者本人が一番よく分かっているからです。

＜質問＞
品質管理のポイントは細かい技法や技術ではなくて管理と考えてよいのか
デミングの提唱するマネジメントに着目するという認識でよいか。

＜回答＞
その通り。マネジメント（仕事の進め方）に着目する必要があり、ここを改善していく。原点回帰が必要である。

＜質問＞
毎朝の進捗で懸念点があるか？と聞くが、懸念点は現場が一番知っているということか。

＜回答＞
⇒その通り。現場が一番状況を理解しているので、それを聞き出して解決することが大切。

• ユーザーモデルとは
  ユーザーモデル=「人を知る」ための技術のひとつ。
  人のとる行動の内発的な動機となる感性や感情的な側面（“気持ち”の側面）を対象にしたモデルのこと。
  
  人を知ろうとする時、その人の持つ属性や何らかの履歴（購買履歴やアクセス履歴等）に基づいてその人を知ろうとすることが多い。
  　履歴=その人がとった行動の結果
  　行動=その人が対象に対して肯定的な“気持ち”になったことによって引き起こされた結果
  
  「ユーザーモデル」の考え方は、様々な行動や履歴の原因となっている人の“気持ち”を対象に、その人がとった行動の動機や原因を探り、より効果的なコミュニケーションを効率的に実現するために活用できるのではないかというもの。

• 着眼点はお客さまの気持ちの変化
  行動はお客さまの気持ちの変化により態度が変容したものであり、属性は行動の結果である。
  お客さまの価値観、消費者傾向、嗜好性を知ることで、行動の原因や動機を解明することができる。


• 消費者行動傾向に基づく4つのモデル
  人が何らかの購買行動を取ろうとする時に想定される「消費行動傾向」を切り口に「ユーザーモデル」の考え方を紹介する。「消費行動傾向」を表出させるために78の設問を設計して、対象者（国勢調査統計データに基づいて性別・年代・地域で割り付けた20歳～60歳代の社会人、1500名）から回答を得て分析を行った。その結果、消費者行動傾向は以下の4つのクラスタに分けられる。
  
  ① ついつい定番派→定番を買う
  ② 何と言っても実用性重視派→自分で判断し自分で買う人
  ③ こだわりのない成り行き派→情報収集しないで勢いで買ってしまう人
  ④ 開放的な積極的社交派→積極的に情報収集して自分がいいと思ったらとりあえず買ってみる人


• 消費行動傾向に基づくクラスタと基本属性の関係性
  4つのクラスタを「基本属性」（性別・年代・地域）でクロス集計し、その基本属性毎に検定（カイ2乗検定）を実施して、統計的に有意である基本属性を「特徴」として抽出を行う。
  
  基本属性との関係において、「性別」「年代」にはばらつきがあり有意性はみられるが、「地域」に有意性はみられない。また、他の属性「結婚・子供」「職業」「世帯年収」「住居形態」にも有意性がみられることがわかる。
  
  これらで分かること（一例）
  ・ついつい定番派は30代既婚主婦に多いことがわかる。
  ・何と言っても実用性重視派は子供ありの既婚者や年金生活者に多い。
  ・こだわりのない成り行き派は30代男性会社員に多い。
  

• クラスタを得るために
  クラスタを得るためには、「消費行動傾向」を表出させるための刺激（設問）を網羅的に準備し、その刺激にどのように反応したか（回答）を回収して、分析（多変量解析）する必要がある。
  
  コーヒー牛乳の味の違いのイメージ。
  同じコーヒー牛乳でも、甘い、ミルキー、テイスティーなど様々ある。
  これは成分の含有量の差で違いが表れている。
  つまり、コーヒー+ミルク+砂糖の割合の差が共通成分ということ。


• 分析するためのステップ
  分析は大きく3つのステップで進める。
  ①因子分析：回答に潜在的に影響を与えていると考えられる因子（共通成分）を抽出する。
  ②クラスタ分析：共通する成分の量（因子得点）の近さで塊を作る。
  ③判別分析：新しい人がどのクラスタに所属するのかを判定するアルゴリズムを作る。


• 消費者行動傾向に基づく分析
  「消費行動傾向」を表出させるために準備した78の設問群に対する回答結果を因子分析し、9つの因子（共通する成分）に分ける。例えば、開放的傾向因子、几帳面計画性因子など。
  
  この共通する成分の持ち方（因子負荷量から導き出された因子得点）の近さで塊を作りクラスタ分析を行う。9つの共通する成分の持ち方の特徴に基づいてできたのが4つのクラスタ（塊）ということになる。
  
  作られたユーザーモデルは、あくまでも、サンプリング調査によって作られたものであるので、クラスタ分類ができただけでは充分ではない。対象者の所属するクラスタや、対象者が共通成分を多く持つ人かどうかを判定（推定）する必要がある。


• ユーザーモデル構築プロセスまとめ
  共通成分を抽出する。【因子分析】
  　↓
  成分の組み合わせの似た人を集める。【クラスタ分析】
  　↓
  ユーザーモデル
  　↓
  所属するグループを予測する【判別分析】


• 食に対する意識に基づく5つのモデル
  もう一つの例で食に対する意識に基づくモデルを紹介。
  「食に対する意識」を表出させるために73の設問を設計し、これらの設問群に対する回答結果を因子分析することで10の因子に分けた。その因子に対する因子負荷量から導き出された因子得点を使って、5つのクラスタを導出した。
  
  ①適度に普通でいい派
  ②楽しく食べて健康維持派
  ③一人で自由に食べたい派
  ④こだわりない効率重視派
  ⑤食べることを大事にしたい派

• ユーザーモデルの活用の3つの側面
  [1] オファーの最適化
  [2] ターゲティングの効率化
  [3] コミュニケーションの活性化


• オファーの最適化
  人それぞれの持つ心理特性に応じてオファー（サービス・イベント等）を最適化するための活用。メッセージやデザイン表現も含めて考える。
  ユーザーモデルからオファーを最適化する。


• ターゲティングの効率化
  得られたそれぞれの人の持つ心理特性を、準備された（何らかの特性を持つ）オファーを受け入れてくれる原因や動機と親和性がある人を特定するために活用することで、オファーに対する受容性の高い人（ターゲット）を効果的に探していくための活用。
  オファーからユーザーモデルを予測する。


• コミュニケーションの活性化
  人それぞれの心理特性の類似度（対象に対する何らかの考え方が近いかどうか）に基づいて、人と人の間のコミュニケーションを活性化するための活用心理特性の近さでコミュニケーションを活性化するための活用。
  ユーザーモデル同士をマッチングさせる。

• オファーの最適化の事例
  事例１：ユーザーモデルの考え方をダイレクトメールのような大学の受験促進プロモーションに活用した事例
  
  ある中堅大学の次年度に実施予定の入学試験を想定した「オープンキャンパス」（7～8月）時に来場者の判別を行い、その将来や進学に対する意識や大学に求めることに基づいて「大学選びの考え方モデル」を作成した。
  「オープンキャンパス」来場者（約5,000名）のクラスタ判別結果を活用して、「資料請求者」（約40,000名）のクラスタ推定方法を抽出、分類を行い、その判定結果を「受験告知」（12月～1月）ダイレクトメールの作成と配信に活用した。


• ターゲティングの効率化の事例
  事例２：ユーザーモデルの考え方に基づく訪問ランキングをイベント後のフォローのプライオリティやWeb接客システムに活用した事例
  
  大きなイベントがあった際に、来訪顧客に答えてもらうアンケートに、来訪した顧客の特定の心理特性を推定するための判定アルゴリズムを前提とした設問を設置し、回答結果に基づいて、イベント後の訪問ランクを決定した。そのランクを特定のWebサイト内で稼働するアバターのインタラクションに設定して、接客への活用を進めた。


• コミュニケーションの活性化の事例
  事例３：心理特性の“近さ”を把握するためのアルゴリズムに活用して、Webサイト内での「情報推薦」（レコメンド）に展開したある口コミサイトの事例
  
  あるお店（主に飲食店）の口コミサイトで、利用者のアクセス履歴や口コミから訪問先が似た人が行っているお店を推奨するシステムに、 “好み”というフィルターを通して推薦を行えるようにした。口コミや訪問履歴と共に、利用者が好むお店のイメージを、嗜好イメージに基づいて作られたユーザーモデルの判定アルゴリズムを作成し、それを使って得られる40の数列に変換して蓄積を行った。新規の利用者にも同じ設問を行い、その回答結果から得られる数列と口コミをアップしてくれている利用者の数列との類似度に基づき、より類似度が近い利用者がより良い口コミを残したお店をより強く推薦するようにした。

ユーザーモデルは、人が様々な対象に対してもつ心理特性に基づいて、人の“気持ち”の解像度を上げるために作られるものである。その適用範囲は非常に広く、事例の中で紹介したように、活用もアイデア次第で広がっていく。

＜質問＞
ユーザーモデルを作る際に実施するアンケ―トの設問設定が重要と感じた。そこで気を付ける点や工夫があったら教えてほしい。

＜回答＞
質的な調査を多用すること。特性の違う人にインタビューを行い、多くの意見を招集し、設問設定には多くの時間をかけることが望ましい。

• クリストファー・アレグザンダーの問題意識
  アレグザンダーはオーストリアのウィーン出身の建築家。
  第2次世界大戦後、復興のために建てられる建築物は、人が住むことや人がどう動くか考慮されておらず質が悪かった。アレグザンダーは、そのような建築物では人がいきいきとしていないと考えた。


• アレグザンダーが初期にまとめた3部作
  • オレゴン大学の実験（1975）
    オレゴン大学のキャンパス再建の際に、学生や教授を意思決定に参加させた実験について書かれている。
    アレグザンダーは建築において、作る人と使う人が分断されてしまうことで、使う人が本当に欲しいもの、使いやすいものにならず、使う人自身がうまく直せないものになってしまうという問題意識を持っていた。そのため、建築家が要求通りに建てるだけではキャンパスを使う人がいきいきしないと考えた。
    
    学生や教授に参加してもらうことで、キャンパスをより良くするための設計要素、解決策がいくつか挙がった。
    例）駐車場を1箇所に作らない
    　　歩道を交わるようにする
  
  
  • パターンランゲージ（1977）
    キャンパス、ビル等建物を建てるときに、どのようなことを考えたらうまくいったかという例を集めたもの。253もの例が挙げられている。
  
  
  • 時を超えた建設の道（1979）
    作られた建築が長持ちするためには、どんな特性が必要か書かれている。


• パタンとは何か
  1つ１つのパタンは、身の回りで起きた問題とそれに対する解決策を示したもの。
  状況が変化した時にも見た人がすぐに使えるように具体的に記述される。
  パタンは、何回適用しても同じように起こる問題を解決してきた実績があるが、まったく同じ状況は無いため、適用方法は少しずつ違うはずである。
  
  例1）154. Teenager’s Cottage
  　　　問題：子離れ
  　　　解決策：敷地の中に子供が住むための小さい家を作る
  
  例2）155. Old Age Cottage
  　　　問題：親の面倒を見る
  　　　解決策：敷地の中の小さい家に親が住む
  
  パタンにはシーケンスという考え方があり、パターンランゲージでは、うまくいった事例でのパタンの適用順についても説明される。
  
  
  例）154. Teenager’s Cottageの後に、155. Old Age Cottageを適用することで、建物を長持ちさせることにつながる。


• パターンランゲージとは？
  • 順序だって適用できるパターンの集まり
  • パターン一つ一つが全体の質をよくする
  • まとまって、新たなパターンを生み出す可能性がある
  
  結果的に無名の質ができ、心地よくいきいきとしている状態が達成される。

大規模開発が広がる中で、ソフトウェアにもパターンを適用することができないか考えられるようになった。初期の段階では、ケント・ベックやウォード・カニンガムらがWikiWikiWebというWEBサイトで、ソフトウェア開発においてうまくいった話をドキュメント化し、共有した。また、PLoP（パターンについて話し合う活動）が行われるようになり、様々な成功したパターンが集められるようになった。

• 設計パターンとして
  • デザインパターン（Gang of Four、1994）
    どのような設計、プログラムだと作りやすいか、見通しが良くなるかについて書かれている。
  
  
  • アナリシスパターン（Martin Fowler、1996）
    どういう形でまとめておくと、ソフトウェアとして扱いやすくなるか書かれている。ある程度大きな規模のソフトウェアを作る場合には、有用なパターンとなる。
  
  
  • Extreme Programming Explained（Kent Beck、2004）
    うまくいったソフトウェア開発のパターン（プラクティス）の集まり。技術に関するものだけでなく、よいプログラマーになるための習慣について書かれている。
  
  
  • ドメイン駆動（Eric Evans、2003）
    アレグザンダーが目指した「作る人と使う人が一緒になって進める」という考え方をソフトウェアにもっていく方法を主張している。
  
  
  • エンタープライズアプリケーションパターン（Martin Fowler、2002）
    大規模システムをどうやって扱うべきか書かれている。
  
  
  • Enterprise Integration Patterns（Gregor Hohpe & Bobby Woolf、2003）
    大規模システムをどのようにつなぐか、どのようにつなぐことでうまく作ることができるか書かれている。現在のマイクロサービスの考え方のもとになるもの。


• 組織パターンとして
  • Development Process Generative Pattern Language（1995）
    組織構造やプロセスにもパターンが適用できることが書かれた論文。
  • Fearless Change （Mary Lynn Manns, Ph. D、Linda Rising Pd. D、2004）
    より良いソフトウェアを作るための組織づくりや組織自体を活発にするためのパターンが書かれている。
    例）食べながら話をする。
  • 組織パターン（James Coplien & Neil B. Harrison、2004）
    ソフトウェアをうまく作れる組織の形がパターンとして書かれている。


• パターンランゲージとしてのスクラム
  組織の作り方やうまくいったプロセスを集めて書かれたものがスクラムのもとになっている。スクラムはパターンランゲージとして書かれた。
  • A Scrum Book - The Sprint of the Game（The Scrum Patterns Group、2019）
    スクラムについてパターンランゲージとしてまとめたもの。


• アジャイル開発宣言について
  当時、大規模開発ではソフトウェアファクトリーが主流だったが、ソフトウェアファクトリーでなくても、パターンを集めることでうまく開発ができることが分かっていった。
  そして、作る人と使う人が一緒になって進めるほうが質の高いものができると考えられるようになり、そのように考えるコミュニティでの合意事項がアジャイル宣言となった。

• Product Organization Pattern Language
  ＜プロダクトオーナーに関するパターン＞
  Product Owner
  　問題：ステークホルダーが増えるほど、判断に時間がかかる
  　解決策：最終判断を一人が行う
  　↓
  Product Owner Team
  　問題：プロダクトオーナー一人がすべての判断を行うため、負荷が高くなる
  　解決策：プロダクトオーナーを支えるチームを作る


• Value Stream Pattern Language
  ＜スプリントに関するパターンの一部＞
  Sprint
  　↓
  Product BackLog
  　解決策：プロダクトバックログを作る
  　↓
  Refined Product BackLog
  　解決策：選ばれたバックログを作る


• スクラムにおけるプロダクトの品質
  スクラムには、出来上がったプロダクトの質を常に早く確認するための仕掛けがある。
  
  
  • Regular Product Increment
    プロダクトの増分をステークホルダーに見せて、価値を常に確認する。
  
  
  • レトロスペクティブ
    内部の設計やプロセスの質を確かめて、プロダクトと答え合わせをする。

• QA2AQについて
  QAが開発部門とは別の部門にある場合の組織パターン。今後、QAが全体として質を考える組織に変わっていくために必要なパターンランゲージが記述されることが望ましい。


• 利用者品質をパターンで記述してみる
  パターンを使って、品質をより良くするためにできることが記述されるようになってきた。
  例）使う人のパターン（ユーザーインターフェース）
  
  スクラムでは、ステークホルダーを巻き込んでレビューを実施し、プロダクトの価値を確かめるプロセスがあるが、良いプロダクトとは何か、利用者にとって良いプロダクトの作り方は何かについて、パターンで記述されていない。
  今後、ユーザーが使いやすいパターンが記述されれば、それらのパターンをもとに、開発者やオーナーがより良いパターンについては話合えるようになる。

ユーザーにとってよいプロダクトとなるパターンを書き、集めることが今後の展望。
パターンに基づいて作ったプロダクトのテストができる人は、パターンがうまくいったか確かめることができるはず。うまくいったパターンを書き残しておくことが望ましい。
定性的なものとマトリクスの両方があることは、ソフトウェア開発にとって大きなメリットとなる。

＜質問＞
「パターンを集めるときは全く同じものはない」ということは、パターンを集める際には似たものを集めていくのか。

＜回答＞
パターンのコミュニティが使っている方法は、KJ法に近い。カテゴリで集めるというよりは、それぞれのパターンが自然に集まってくるのを待つ。新しいパターンを作るのではなく、みんなが知っていることに名前を付ける。

＜質問＞
パターン≒使える事例の集積、ということであるか。

＜回答＞
うまくいくやり方が集まったもの。うまくいく順番や組み合わせを含めて書かれたのがパターンランゲージ。

＜質問＞
パターンとテスト設計は似ているか。

＜回答＞
似ている。「xUnit Test Patterns」という本があり、テスト設計もパターン集がある。

＜質問＞
KPIなどで振り返りした結果が組織としてのパターンになる可能性があるか。

＜回答＞
KPIもパターンに出てくる可能性もある。KPI自体もパターンと考えられる。

＜質問＞
パターン≒プロセスになってしまうが、パターンについてよい説明はないか。

＜回答＞
パターンの中にはプロセスとなっているものもある。
パターンは何度も使えるものである必要がある。うまくいかないパターンが出てくることがあるが、どこを改善すればうまくいくか考え、修正すればよい。スクラムパターンの本に出てくるパターンは、少なくとも3回以上書き直されている。

＜質問＞
パターンとモデルの違いは何か。

＜回答＞
モデルは対象物と関係する。パターンは状況に対する扱い方である。パターンは、コンテキストがあっていれば対象物が違ってもうまくいくことがある。モデルとしてパターンを書くのもよい。パターンとして正しいというよりも、パターンとして有効、役立つものであればよいのではないか。

＜質問＞
パトレットを公開し、うまくいったか共有するようなコミュニティがあれば教えてほしい。

＜回答＞
慶應義塾大学の井庭先生は、学習、プレゼンのパターンを集めている。鷲崎先生は、ソフトウェアに関わるパターンを集めている。本となって普及する前のパターンは様々なものがあるので、探してほしい。

• プロダクトライン開発とは、Product Line Engineering (PLE)のこと。
• なぜプロダクトラインで開発する必要があるのか。
• 低コスト、高品質、短納期が実現できる。
• 低コストに注目されがちだが、高品質というのがメリットとなる。
  →再利用部分は品質の保証が可能なため。
• 根幹は再利用（ソフトウェアの再利用、プロセスやモジュールの再利用など）
  →バージョン管理される製品が中心の考え方だが、そういった製品でなくても適用が可能。

• プロダクトラインはコア資産を作成するという考え方。
• コア資産から発生させて新しいシステムを作っていくようなイメージ。
• コア資産そのものもアップデートしていく必要がある。
• 共通性を基に資産を形成。可変性に着目して製品を導出していく。
• 具体的な導入例としてプリンタードライバーの開発があり、欠陥を96%減らすことに成功した。

• 製品で共通な機能や特徴（フィーチャ）を見つける。ここでいう共通な部分というのは概念的に共通というという意味である。
• プログラムモジュール単位で考えるのではない。概念的にとらえなるべく多くの共通点を見つける。その中で可変の部分はどの箇所になるのかをしっかりと見極める。
• 車で例えるならばエンジンがあるというのは共通性となる。しかしどのタイプのエンジンを使うかは可変性ととらえる。

• フィーチャモデルを使ってコア資産を表現する。
• フィーチャモデルはFORM方式で記載する。
• 簡単には作成できない。製品計画やマーケッティング顧客分析などあらゆる情報を集めて作ることが大切。
• フィーチャモデルを作ってから、アーキテクチャを作る。アーキテクチャが決まればコンポーネントが決まる。
• フィーチャモデルは表形式になったりツリー状になったりする。

• プロセスは2段階になる。
• まずはコア資産を開発する。それからアプリケーションの開発を行う。アプリケーションの開発からコア資産に戻すパターンもある。
• いきなり全部をやろうとするのではなく今ある社内の資産から順次実施していく。
• エンジニアレベルで考えて作成するものではない、もう少し上のレイヤーのメンバーを参画させて議論を進める。
• 2つのアプローチがある。
  ＜事前準備型＞
  あらかじめにコア製品を作る。初期投資が高く期間も大きい。また、関連ドメインを熟知していて安定していて初期投資の余裕がある企業に向いている。
  
  ＜都度対応型＞
  将来性や拡大が見込める場合に限りコア資産を作る。ピークを過ぎたら都度開発に戻す。


• 開発体制
  ＜中央統御型＞
  一元的に管理・開発ができるが、コストの問題が発生する。彼らは何かを作るわけではないため。利益を上げるまで時間がかかる。
  
  ＜協調開発型＞
  各部門で開発したものを全社で共有。費用は分散されるが、他部門のニーズにあうコア資産の開発や協調は難しい。スケジュールや責任問題。仕様変更などの課題がある。
• アジャイル開発では不要なものは作らないという考え方なので、製品全体の設計などを考えて開発を進める必要がある。
• 製品のライフサイクルが目まぐるしく変わるが、都度フィーチャモデルを見直して取捨選択をしていく必要がある。

• 既存の資産をコア資産化する。この時既存資産の改善・改修や整理は行わない。やってしまうと先に進めなくなる。
• 具体的には、①既存資産のコア資産化②フィーチャモデルの作成と資産登録③ポートフォリオや製品計画に従って開発するの3階層が望ましい。
• 狩野氏の品質モデルに従って資産化を進めるのもよい。
  当たり前品質→優先的にコア資産化。
  一元的品質→次にコア資産化　　　　…など

＜質問＞
PLEとマイクロサービスの考え方との違いについて教えてください。

＜回答＞
重なっている部分は多い。マイクロサービスもちゃんとやろうとしたら背後にあるサービス体系の理解が必要となる。どちらも目的は同じだが、実現方法や技術が異なる。

＜質問＞
バグ修正はコア資産に対して行い、個々の製品に対して個別に修正することはしない、という理解で正しいでしょうか？

＜回答＞
その通り。コア資産へ対応が基本となる。コア資産をベースとして各製品を対応していく。

＜質問＞
PLE の実践では、コア資産のファイル管理（SCM）が難しいと思います。Git や GitHub などでのリポジトリ管理どのようにすればよいでしょうか？ たとえば、どのような単位をリポジトリとするかなどです。

＜回答＞
統一して管理したいものをコア資産化して、なるべくまとめる（一つのファイルにしていく）。
バリエーションがある場合はインターフェースを同じにする。フィーチャモデルを部門ごとに作成し、階層化している企業もある。また、コンフィグなどを用いてルール化し、管理しやすくする。

＜質問＞
よいフィーチャモデルを作るためにはマネジメントや顧客をうまく巻き込んで「どういう価値が提供できるか、大切か」という共通ビジョンを確立する必要があるかと思います。
この辺をどう実践していけばよいか、経験やご意見をお聞かせください。

＜回答＞
利害関係者を巻き込んでどれだけ意見をあつめられるかというのが最終的なポイントとなります。よいシステムアーキテクチャを作るのと同じようなスキルが必要と考えます。

＜質問＞
「フィーチャモデル」とは、特にITベンチャーのような企業では、「ビジネスモデル」とほぼ同義なのかと理解しましたが、如何でしょうか？

＜回答＞
フィーチャモデルとビジネスモデルは両輪であると考えている。フィーチャモデルを「能力」レイヤーに加えるとより良いものが作成できる。

＜質問＞
「自動化」について紹介がありましたが、例えば、要求、設計資料、ソース、テストケース等、どの部分をどのように自動化すればよいでしょうか。

＜回答＞
Gearというツールなどがあるが、Gear以外にもツールは多く存在するので特性を踏まえて利用することが大切。システムやプログラムだけでなくドキュメントをプロダクトライン化しても効果はある。

• 設計・開発でのシステム観点とは
  モノを見るときには、先入観を持つことなく頭を真っ白にして現実を注意深く観察すべき。
  →そうしないと本当のものはみえてこない。
  
  我々はモノを見るときに普段から見ているものやいろいろな知識をベースにしてみている。


• 科学哲学では
  1900年頃「先入観のない注意深い観察が科学知識を生み出す」といわれていた
  　↓
  1958年　「観察は理論依存的である！」N.R.Hanson
  同じ現象が網膜に写し出されても、みるものは経験や理論に依って異なる。
  (見る⇒視る）
  
  観察とは見ることだが、認識の枠組みに依存している。
  対象システムを見るときに何らかの認識モデルを頭に描きながら対象物を見ている。
  その人の接したモノや生活によって、同じ見えるものでも変わってくる可能性がある。


• システム観点とは
  
  • 多様な視点から対象物をみて初めて真実の姿がみえる。
    →一つの観点からみると間違ってしまう可能性がある。
  • 創発特性に着目すること
    創発特性とは、分解すると説明ができない性質のこと。
    →構成要素の組合せ・相互作用で発生する性質

• 創発故障とは
  正常な構成要素の組合せで発生する故障
  （1）○○と××の相互作用
  　　　電気ストーブの誤点火、自動ブレーキの誤作動
  （2）組合せ部品の相性
  　　　人工呼吸器事故
  （3）○○と△△の継ぎ目(接点故障）
  　　　エアバッグハーネス、航空機火災、パンタグラフ落下
  →高信頼度のものを組み合わせても安心しない
  上の階層で信頼性・安全性を確保する。

• 経験を活かした設計での落とし穴
  問題は3つ。
  
  （1）設計工夫・変更の根拠なき導入
  　これまでの実績、経験に基づき、勝手な思い込みで導入すること。
  　→エビデンスは存在しているか、真に効果のある設計かが重要。
  
  ①冗長化による高信頼化
  機器が独立に故障する想定は立てられているが、
  2つの機器が両方同時に故障する想定も立てなければいけない。
  ②安全装置への過信・思い込み
  安全装置があるから大丈夫ではない。
  シナリオ分析重要性、実証実験の必要性、前提条件の確認が重要。
  
  （2）状況把握と理解の欠如（認識の限界）
  　　現状を正しく把握し、理解しているか。
  
  ・使用想定（使用者・使用状況）に変化はないか。
  ・使用環境（周囲環境）に変化はないか
  
  　　→変化がある場合は設計、仕様を変えるべき
  
  （3）トラブルを予見欠如（予測の限界）
  　　適切に起こりえるトラブルは予見・予測できているか。
  
  ・新方式の導入時のリスクは想定できているか
  ・設計変更に伴う従来リスクは回避できているか
  　　→リスク意識が高ければ予見可能


• 安全性向上で操作が変わる
  人間は安全性が向上すると行動が変わりリスクが高くなる傾向がある。
  →安全性が向上してもリスクレベルは不変。
  
  今の状況で設計を変更しても人間は行動が変わってしまうため、その後のリスクも想定しなければならない。

• 大きく3つある。
  （1）ユーザーの経験・知識の想定
  
  ・従来とは異なる（逆方向の）モノ
  　　メーカーの意図とユーザーの解釈が異なる。
  ・従来方法の類推では使用を誤る場合
  ・バージョンアップ時の危うい設計変更
  　　バージョンアップ前後の商品が混在してしまい、使い方を誤った
  ⇒ メンタルモデルの一致が重要
  
  （2）自動化でのユーザーとの意図のずれ
  
  ・操作者と自動機器の意図が違い操作を誤ってしまう
  ⇒自動化意図（設計者の意図）の透明化を実施する。
  　使用者を安心させるための工夫。
  
  （3）運用管理者との情報共有
  
  ・設計者と運用担当者との間、設計者と保全技術者との間で情報が共有されていないことが多い。
  ・情報を伝達する、相手の立場を理解するだけでは不足。
  ⇒ 異種組織（立場）の人の「観点」を想定することは難しいため、
  相手の作業を体験することで移植組織間のコミュニケーションを円滑にする。


• 設計者と運用者の情報共有を実現するために
  　・相手の作業を体験する。
  　・重複所属を取り入れる。
  　　　一部担当者を重複させる（人の共有）と、情報共有を行うことができる。
  　　　作業を重複させると見落としの回避ができる。
  　・情報共有と情報伝達の使い分けを行う。

• ダブルチェックの効果の実験
  
  ・実験内容
  300人の名前、住所、郵便番号を書かれたリストと宛先を書き写した封筒を用意する。
  その中に3通間違えたものを入れておく。
  人が目視で確認し、住所エラーの封筒がみつかるかの実験を1重～5重で確認する。
  
  ・結果
  　住所エラーの検出率
  
  1重：65％
  2重（ダブルチェック）：80％
  3重（トリプルチェック）：65％
  4重：55％
  5重：60％
  　→多重性は逆効果であることがわかった。大人数だと社会的手抜きが起こりやすい。
  　　多重性の効果は独立性が前提。


• ダブルチェック方法の比較
  
  ・実験内容
  先ほどのダブルチェックの実験を異なるやり方で行う。
  ① 1人シングル型：リスト→封筒のチェックを行う。
  ② 1人連続型：リスト→封筒のチェックを2回行う。
  ③ 1人双方向型：リスト→封筒のチェック、封筒→リストのチェックを行う。
  
  
  ・結果
  エラー数と平均作業時間は以下
  ① 1人シングル型：低精度、所要時間は最小
  ② 1人連続型：中精度、所要時間は①の2倍弱
  ③ 1人双方向型：高精度、所要時間は①の2倍強
  
  　→視点を変えることによって、精度があがることがわかった。
  　　同じことを複数回実施するのではなく、やり方を変える。

＜質問＞
多重チェックの問題と、メールの多数に㏄で送ると誰も読んでいない問題との相関性に関する研究はありますか。

＜回答＞
「メールの多数に㏄で送ると誰も読んでいない」は他の人に依存してしまうということで、社会的手抜きと同じ問題だと思う。みんなでをやると誰かがやってくれると思ってしまい、誰もやらないという最悪なケースが生まれる。その相関性に関する研究はわからない。

＜質問＞
人と人の意図のずれについて、現場の技術者が仕事として、よりよく実施していのはどのようにすすめていけばよいと考えますか。

＜回答＞
自分がどのように考えていて、相手がどのように考えているか、どういうのを意図して設計しているのかの設計図の裏側をどれだけ理解できるかだと考える。
設計書を見ただけではなく、共有や質問できる場があるのが望ましいと思う。

＜質問＞
「フィーチャモデル」とは、特にITベンチャーのような企業では、「ビジネスモデル」とほぼ同義なのかと理解しましたが、如何でしょうか？

＜回答＞
フィーチャモデルとビジネスモデルは両輪であると考えている。フィーチャモデルを「能力」レイヤーに加えるとより良いものが作成できる。

＜質問＞
「自動化」について紹介がありましたが、例えば、要求、設計資料、ソース、テストケース等、どの部分をどのように自動化すればよいでしょうか。

＜回答＞
Gearというツールなどがあるが、Gear以外にもツールは多く存在するので特性を踏まえて利用することが大切。システムやプログラムだけでなくドキュメントをプロダクトライン化しても効果はある。

• なぜAIに品質が必要か？
  今は日々の生活・人命をソフトウェアによる制御に預けている。
  →航空機や鉄道車両、自動車、家電、インフラなどはコンピュータによって制御されている。
  
  最近はソフトウェア構築に、機械学習のソフトウェアが入ってきており、機械学習AIに命を預けるという状況が目前まで来ている。


• なぜAIが必要か？
  機械学習は現状では品質管理に不利で、不安要素を解消できないが、従来のソフトウェア構築に限界が来ているため、機械学習が必要とされている。
  
  • 品質管理に不利
    従来の品質管理手法が通用しない。なぜ上手くいったのか説明できない。
  • 不安要素を解消できない
    次の開発でも正しく動くことを保証できない。
  • 従来のソフトウェア構築に限界
    ・扱う問題の複雑さが増し、従来の構築手法では追従できなくなっている。
    ・勘や経験、総合的な判断が必要な場合などを記述できない。
    ・人ができないことを計算機にやらせたい。


• 社会からみたAIへの恐怖と要求
  AIの「得体の知れなさ」や「社会的影響」への恐怖も顕在化している。
  最近は規制や合意をもって制約をかけていく方向になっている。
  
  • 人間中心のAI社会原則
    　セキュリティ（安全性・信頼性を含む）や公平性・説明責任・透明性の確保についても記述されている。
  • OECD Principles on AI
    OECDの各国における、AIに関するルール化などの方向性についての合意文書。
    公平性と公正性の確保や、堅牢・セキュア・安全性とリスクアセスメント、開発運用者責任について記述されている。
  
  ＜法律・ガイド層の各国の取り組み＞
  
  • アメリカ
    NISTがAIリスクマネジメントフレームワークの作成に向けて関連情報を募集。
    法律ではないが、政府調達の要件に入れることで社会に影響を与える。
  • 欧州
    欧州委員会がAIの規制法案を公表。使用方法や使用できない場所などを定義している。
    施行された場合、欧州向け市場で影響が大きい。
  • 日本
    AIガバナンスガイドラインを発表。
    ガイドラインで共通認識を形成することで、自主的な取り組みを促進している。


• ビジネスからみたAIと品質
  ＜問題点＞
  • 顧客に安心して買ってもらえない。PoCから先の開発に進めない。
  • 誤作動時の責任問題。どこまで責任を負うのかわからない。
  • 売買契約において不利になることがある。


• AIの品質・セキュリティリスク
  AIシステムもITシステムの一種
  →全く違うプロセスで行うべきではない。ITシステムとして品質を説明する必要がある。
  
  なぜAIシステムの品質が難しいか？
  →環境の多様性が大きすぎる（サイバーフィジカルシステムの難しさ）。
  　ソフトウェアとしての構造が特異で、機械学習にすることによって生まれるリスク。


• 従来のソフトウェアの品質の考え方
  システムが構造的に構築されることに対応して、品質も構造的に作っていく考え方。
  すべてのリスクに対策を実現した＝安全であるという思想で、開発プロセスに抜けがないことを担保する。


• 機械学習ソフトウェアの特異点
  • リスクの要因をすべて学習させても正しく判断するとは限らない。
  • テストをしても網羅性が分からない。
  • 修正をした場合、ほかの部分への影響を避けられない。


• 高品質な機械学習ソフトウェアへ向けて
  従来のソフトウェア工学の前提が崩れている。
  →機械学習AIに合わせて新たな「品質の作りこみ」の枠組みを作る必要がある。

機械学習AIの品質を「作りこみ」「確認し」「説明する」ためのガイドライン。
・主な想定読者
　機械学習の製品やサービスの提供者や機械学習のソフトウェアの開発者
・2次的な想定読者
　サービスの利用者、第3者評価機関

• 取り組みの狙い
  ・社会全体で受容性が高まり、安全性が向上すること。
  ・競争力強化、品質を見えるようにする。
  →ユーザに納得して使用してもらえるようにする。


• ガイドラインの位置づけ
  人間中心の社会原則の下に入る位置づけで、どのように作るかを定義している。
  将来的には業種別にガイドラインを作り、各企業のガイドラインのベースにしてもらう。


• 検討の主体は機械学習品質マネジメント検討委員会。


• 品質管理の対象と考え方
  ガイドライン内で着目する品質は、利用時品質、外部品質、内部品質。


• 外部品質：3項目✕レベル
  機械学習のコンポーネントが達成すべきことを3つに整理
  ① リスク回避性
  危険につながる判断をしない（する確率を一定以下に抑える）。目標レベルは7段階。
  従来の安全性基準（IEC 61508 SIL）準拠の4レベルと、従来SIL0に対応するものとして3レベル。高い安全性が必要なものはSIL評価が必要とされる。
  ② AIパフォーマンス
  全体として平均性能を高く保つ性質。目標レベルは3段階。
  ③ 公平性
  入力の属性に依存して、統計的に望まない偏りがないこと。目標レベルは3段階。


• 内部品質
  ＜整理の仕方＞
  
  • ボトムアップ・アプローチ
    AI学会が注目している技術に着目する。
    →技術的に実現できること、何をやるべきと思っているかが判る。
    →積み上げても十分かはわからない。
  • トップダウン・アプローチ
    AIが誤動作したときの原因を仮想的に分析。
    →対処できるかわからないが、方向性としては正しいはず。
    →ガイドラインでは、トップダウン・アプローチの中に、ボトムアップ・アプローチを組み込んで整理している。


• 内部品質9項目
  
  A) 問題の分析に基づくあるべきデータセットの設計
  A-1問題領域分析の十分性、A-2問題に対する被覆性
  ・従来開発の要求分析・テスト設計に対応。
  ・どういう観点で品質を問うかを決める。
  B) 設計に合致する良いデータセットの確保
  B-1データセットの網羅性、B-2データセットの均一性、B-3データセットの妥当性
  ・十分なデータが均一にあること。
  ・レアケースに対しても設計すること。
  ・データセットの個別のデータが妥当か。
  C) 良いデータセットから得られる良い機械学習モデル
  C-1機械学習モデルの正確性、C-2機械学習モデルの安定性
  ・データセットから良い訓練済み機械学習モデルを作る工程。
  ・正確性・安定性は分けて考える必要がある。
  D) 信頼できるソフトウェア
  D-1プログラムの健全性
  E) 品質を維持する運用
  E-1運用時品質の維持性
  ・テストまでうまくいっていたモデルが運用中に品質劣化する可能性がある。
  ・更新方法には、オフライン更新、オンライン更新がある。
  

  ・ソフトウェア・レグレッション…あらかじめ運用方針を決めておく必要がある。また、テストでの確認も必要である。


• システムライフサイクルプロセス
  規格段階から運用・利用終了までの総合的な品質マネジメントを想定して整理。
  品質のチェックポイントを明確化させる意図がある。
  
  ガイドラインの提案するプロセスは「抽象的モデル」
  →PoCと最終開発は頭を切り替える必要がある。1度は仕様を固定する必要がある。


• 従来の規格との関連性
  安全性が重要な分野ではSILおよび分野別詳細規格への対応はほぼ必須。
  →AIバックグラウンドの人は規格についてほとんど知らないことが多いため、
  　ガイドラインでは両立できるような記述となっている。


• 機械学習品質マネジメントガイドライン
  ・日本語第2版：2021年7月公開
  ・英語版第1版：2021年2月公開→第2版は近日公開予定。

• 国際標準化の流れ
  
  • ISO/IEC JTC 1/SC 42（Artificial Intelligence）
    WG1で基本用語集の検討、WG3（Trustworthiness）で基本的な議論、データ品質、AI開発ライフサイクル、品質指標モデルなどの議論も開始された。
  • ISO/IEC TR 29119-11、IEEE P7003、NIST等での活動


• TR 5469
  IECと合同で進めており、テクニカルレポートの公開に向けて検討中。


• 国際標準化の現状方針
  当面は、TR 5469に沿った実装をする際のガイドラインとなるよう準備している。

• 活動の全体像
  • 機械学習AI品質管理ガイドライン
  • 産業分野別AI品質リファレンスガイド
  • 品質管理テストベッド（Qunomon）
  • 評価ツール


• 品質管理テストベッド（Qunomon）
  高品質AIを実現するための品質開発環境で、テストを評価レポートとしてまとめる、再利用性を高めることのできるツール。


• 応用別のリファレンスガイド
  ガイドラインを実際に製品に適用するためのこうすればできる、という事例集。
  民間企業の具体的事例を共有知にする。
  • 対応内容
    データラベルの設計やラベル付けの精度・ツール支援
    コーナーケースの分析・モデルの安定性などの検証
  • 品質アセスメントシート
    製品全体の安全性管理と連携させるためのチェックシート


• 具体的な品質管理技術の研究開発
  QA/QCのための具体的な技術の追求。新しい機械学習技術の研究。


• ガイドラインの社会展開：これまでの反響
  • ビジネスへの適用
  • ほかのガイドラインへの埋め込み
  • 問い合わせや情報交換

機械学習の品質は作りこむだけでなく、確認し、説明することも大事である。それを目指すために機械学習品質マネジメントガイドラインを提供している。ガイドラインは、ソフトウェアを作る人だけに使われるのではなく、社会全体でAIを安心して使ってもらうための基準や認証の基盤としての利用も期待している。

＜質問＞
ガイドラインに出てくる言葉が難しい場合など、ガイドラインを読む前段階に読んでおくべき資料、おすすめの資料はあるか。

＜回答＞
現状、そこまで対応できていない。必要性を感じており、問題意識は共有している。

＜質問＞
AIを作るための本は数多くあるが、AIの品質保証に携わるうえで、一通り学んでおく必要があるのか、もしくは最低限の理解でもよいのか。

＜回答＞
ショートカットは可能だと考えている。品質管理の担当者がAIの品質管理をやることになるケースも多い。AIそのものの理解も必要となるが、品質マネジメントの構造を理解していれば、品質管理の培ってきた経験を活かせると思う。今のAIの品質にはそれが大事だと感じている。

＜質問＞
AIのリスクマネジメントは、従来のリスクマネジメントとどのような点が違うのか。どのようなリスクマネジメントプロセスになるのか。リスク分析や対策のプロセスは変わらないのか。

＜回答＞
リスクマネジメントで培ってきたプロセスは出来る限り変えるべきではないというコンセプト。従来のリスクマネジメントプロセスの外側には大きなエコシステムがあるため、モノづくりの違いによる変更だけが必要と考えて、ガイドラインを作成している。一番の変更として、テストのやり方については適応させる必要があるが、それ以外は出来る限りプロセスを変えていない。PoCでリスクを特定し潰せるようになるなど、効率的にリスク特定もできるようになればよいが、地道なリスクマネジメントプロセスが不足している場合は社会に受け入れられないと思われる。また、ネガティブリスクが重要な分野はしばらくの間変わることが難しいと考えている。ポジティブリスクの分野に関しては、新たな方法があってもよいと思うが、現時点で方法は考えられていない。

＜質問＞
データの均一性とはどういうことか。コーナーケースを考えるとすると、問題のところは局所的だと感じる。

＜回答＞
機械学習のデータの準備の難しい点として、コーナーケースを言語化できる場合とできない場合がある。リスク管理としては言語化できるところは言語化して押さえ、言語化できない場合はコーナーケースをデータ量でカバーしたり、未知のケースにも対処したりする必要がある場合もある。被覆でとってきて点が入っているか確認するだけでなく、均一にデータが入っていることがセーフティからみたときの均一性への要求である。もう一つ、機械学習はいいサンプリングになっていないとうまく学習しない話もあるが、リスク管理からすると言語化できていないリスクを抑えたいというのがメインである。均一性を満たしていても、コーナーケースのデータが0ではデータとして不十分のため、両方を満たしていることをチェックすることがポイント。

＜質問＞
AI開発案件の契約段階の留意点として品管や事業部メンバーが読んでおくべき図書としておすすめはあるか。経産省の契約ガイドラインやディープラーニング協会のハンドブックよりさらに一段ブレークダウンした資料（IPAの非機能要求グレードのような一覧）があれば具体的理解に役立つと考えている。

＜回答＞
ガイドラインの今後の取り組みで拡充していきたい。ガイドラインは、受託の構造に関わらずに共通にいえることを抽出しているため、発注者・受注者で分けて考えた時に間に何があるのか、などの観点では読みづらくなっている認識がある。非機能要求グレードのような形という点では、システムとレベルの対応については機械学習品質マネジメントガイドラインで記述されている。契約段階の切り口では提供できていないが、全体で何をすべきか俯瞰する品質アセスメントシートは役に立つと思う。使う際には、必要な箇所を切り出す必要はある。今後、参考にできるデータを出していきたい。