1. はじめに：資本主義と経済のグローバル化

資本主義

• 働くということは最低限の食べ物を得られれば良く、余ったら教会に寄付するという教え。

グローバル化と経済環境の変化

• 日本経済が創出する70%はサービス関連である。
• 従来は勤務時間に対して対価を支払っていたが、それが成果に対するものに変わってきた。
• 企業は利益が目的であり、個人は良いものを作ることを目的としているため、価値観が変わってくる。

2. プロの知識と精神の育成、その労働倫理

技術者育成の枠組み

• ベテランのテスターは能力があるが、どうやってテスト項目を考えているかは説明ができない。そこで、実際にやってもらってテスト項目を書き起こす。こういったケースが多い。

米国の技術者の育成

• 米国は高等教育で質の高い基礎知識を教え、更にPBT(プロジェクトベーストレーニング)で演習を行い、インターンシップで実際経験を通して教えている。
• インターンシップは実務経験があるので採用しやすい。企業にとっても非常に良い労働力となっている。

米国の技術者と雇用制度

• 米国はインターンシップを通して採用する価値があることを解っている。
• 職務記述書(Job description)には資格と知識を定義する。
• 1980年代後半には200程度の仕事の最低賃金が決まっていた。但し、レンジの中でしか賃金は変わらない。
• 資格は職務記述書で決まるが、重要なのは学歴。大学の学科で認められている。(=アクレディテーション制度)

産業化社会の人材育成と労働者倫理

• アクレディテーション制度を日本でも導入しようと試みた時があったが、文化の違いもあり難しい。
• 日本では職務記述書は意味がない。一生その仕事(その会社)があるとは限らないため。
• 米国では自分の専門能力を継続に高める。一方、日本は企業の発展を目指すため、考え方が全く違う。

３．品質論とソフトウェアの品質

産業革命と品質概念

• 資本主義が出てきて初めて質の概念が出てきた。同じ1ポンドでも質の概念が変わってくる。
• 効用は財の量が増えると減少する。

産業化社会と品質概念

• シューハートは物理の実験で定量的な評価に興味を持っていたため、品質を定量化した。

1970年代の品質概念

• 全数テストをすると良い品質にはなるが、良い品質のものを作ると、コストが掛かり過ぎるため、価格競争に負ける。
• スペックに合っているか？合っていないか？ではなく、使いたい時に使えれば良い。

日本的品質概念

• 良いものを作れば、お客様はまた買いに来てくれる。これが長期的関係。よって、また質の良いものを提供する。
• ごく少数ではなく、多くのユーザが喜んでくれることが魅力的な品質。米国は当たり前の品質を上げることだけを考えていた。

新自由主義経済の品質概念

• 市場で1番売れているものが品質は良い。それを顧客満足度として測る。

ソフトウェアの変化

• 従来はバグが何個残っているかで品質が良いか、悪いかを判断していた。バグが100個残っていたら悪い、10個なら良い。

ものづくりの変革(例)

• (コックピットの例)プログラムがちゃんと動くということはパイロットの意思通りに動くかどうか？である。

ものづくりの変革

• 現在のインクジェットプリンタは単純な構造なので、部品があれば安く簡単に作れる。逆に昔のプリンタはメカの塊であった。

何がかわったか

• 人間は間違えることが問題の本質である。

根本的な問題

• 非決定性が問題である。ソフトウェアはメモリを使って、次の処理を行う。状態やタイミングが変われば動きが変わる。よって、膨大なテストパターンとなるため、テストでは品質が保証できない。

４．倫理学とソフトウェア技術者の職業倫理

倫理の起源

• 何のために生きるのか？=ソクラテスは徳を実践しなければいけないと言った。

中世倫理観の歴史的変遷

• 生きるために働き、神のために祈る。
• プロフェッショナル=天職である。

資本主義の倫理観

• プロテスタントは一生懸命働いて、余ったら教会に寄付しなさいと教えられていた。

ソフトウェア技術者の職業倫理

• 自動運転のプログラムは車の寿命より長い期間動かなければいけない。

５．日本の雇用制度と技術者育成の課題

日本の技術者育成

• 理論的な面は米国よりたくさん教えている。記述された経験は日本の企業内教育。

新しい時代の到来

• ドイツや日本でアジャイルは上手くいかない。働き方が違う。個として働かない。アジャイルはフィンランドが向いている。

６．日本のソフトウェア技術者とその育成

どんな能力が重要になるか

• 他の技術者による設計を評価する能力、ユーザの要求を理解・納得し、抽象化する能力が必要となる。更に良い仕事をしようと可能な限の努力をする姿勢

おわりに

• 1991年、アメリカで川に飛行機が墜落し、たくさんの人が亡くなる大きな事故があった。その時、レスキュー隊が溺れ掛けている男性に今からあなたを助けに行くと声を掛けたら、自分ではなく、近くにいる女性と子供を先に助けるように言った。次にその男性を救助に行ったらその男性は居なかった。後でその人は医師であったことが判明した。いつも人を助ける仕事をしていたその男性は、自分の命の危機が迫る場面でも最後までプロ意識を忘れなかった。

1. 機能安全との出会い

• 機能安全は何のため？
  →第三者への説明責任を果たすため。アセッサから指摘があってから資料を作るのはおかしくないか？指摘に対して、即設計書が出てくることを期待している。
• ISO9000は自分達が作ったものの品質を担保していることを確認するための道具、手段である。i
  →「皆さんの活動の目的は何ですか？」手段と目的が逆転しないこと。ここを良く意識して欲しい。
• ISO26262 is Japanese Supplier killer!!
  →ISO26262は何のために開発されたか？を誰に聞いても明確に答えられない。
• 日本は規格に準拠させようとする。欧州は必ずしも規格に準拠する必要はなく、ベースとなる品質を担保した上で規格に準拠する。

2. 信頼性と安全性

• 自分で実績を上げて来た結果（権利）がある為、若者に「何を考えて設計しているのか？」と言える。
• 昨日まで、ある会社でアセスメントをしてきたが、何でこんな設計になっているのか？という指摘に対して、エビデンスを示して欲しい。世のおじさん達はこれからの若い連中のために残して欲しい。
• 安全は、性悪説
  →こける、バグがある、故障する、ミスをする…
• 本質安全と言う言葉はリスクをゼロにすることを言う。用語としては、本質的安全が正しい。
• 現在は「安全」に関する学会がない。講師は早急に設立するよう提言している。
• 欧州のコンサルはテンプレートビジネス。この通りやれば良い。これで失敗したら、欧州のコンサルを選んだ方が悪い。
• QMSはいかに開発現場が受け入れるか？がポイントである。現場が使えるものにすることを第一に考える。次回改善に向けて必ずアンケートを取ってフィードバックする。
• 2015年度死亡事故が増加した。事故を如何にして減らすか？今、自動車業界は機能安全より、予防（能動的）安全に力を入れている。

3. 自動車における機能安全とは

• 自動車業界では、OEM：自動車製造業者。トヨタ、日産、ダイムラー等の車両製造メーカー
  の下にTire1：1次下請け製造業者DENSO、アイシン精機、BOSCH等の部品製造メーカー
  その下にTire2：2次下請け製造業者Tire1にソフトウェアを供給するソフトウェアハウス
• 事故の危険性(リスク)を特定→分析→評価
  →自動車特有の安全分析・評価ISO26262 Part-3 Concept Phase(フェーズ)
• 3.11の原子力発電所の事故について、建てる時に機能安全の考え方はなかったのか？安全は1つ事故が起きると、これまでの安全が全てひっくり返る。
• 松下もパナソニックに変わったときに文化が変わった。だから、講師はあえて松下と言う。何かあったら隠蔽するのも会社の文化。
• コントローラビリティ評価例
  →30代の男性25名、50代の女性25名をアルバイトで集めて、実際に評価してデータを集める。
• ASILは「安全機構（SM）や安全方策によって低減すべきリスクの大きさ」を表す。
• H&Rから安全目標導出までの流れ。安全目標→安全状態には停止、縮退、継続の3つがある。危険事象が発生してから安全状態へ持っていくのが、安全機構。
• 60kmでコーナリング中にパワステが壊れた場合の例。日本はASILD、欧州はQM。ドイツ人はコントローラビリティを重視。腕っ節が強いので、コントロールできると主張する。同じ事象でも組織によって考え方が違う。
• カンファレンスは聞きに行くだけではだめ。話して情報を得ること。人と人は50：50。決まったことを守るのが日本人。ドイツ人はどんどん先へ進める。
• 決定論的原因故障(システマティック故障)をいかに減らすかが重要。QMの世界で徹底的にたたく(排除する)。
• ISO9000、ISO15504、CMM、CMMI、SPICEがQM。開発プロセスが大事。
• ISO26262を実施する第1ステップはSPICE活動であると明言
• 決してISO26262はJapanese Supplier Killerではない。
  →安全であることの説明責任を果たすツール。安全に対する議論の文化が存在している、構築されている。
• キーワードはState of the Art。これは覚えておく。

4. 自動車用機能安全規格ISO26262

• ISO26262規格の構造
  →Part1：用語集があるが、言葉の定義はとても重要である。言葉が合っていないと話が噛み合わない。
• FIT値：自動車は1ロット当たり何百万台でその内故障は1～2台程度である。
• 安全分析の手法として、HAZOP、FTA、FMEAがある。

5. 機能安全を通じて見えた物造りへのリスク

• 日本の物造りはどうなんだ？
  →組込技術者とは「自動車に搭載される情報制御システムを開発している人」の意味。
  →要求に設計が混在している。要求はWhat、設計はHowと言われる。
• ドキュメントは重要。なければ、リバースで作る。設計書があるからテストができる、設計と違うからバグだと言い切れる。
• 品質を担保する特効薬はソフトを作らないこと。
• HELLA：SEooC開発では開発コストの削減、市場投入までの時間の短縮、保守作業の削減、複雑さに対処、開発コストの増加予測、顧客のメリットがある →競争力向上に繋がる。

6. これからの自動運転社会に向けて

• IPA/SECの資料。出荷後の不具合原因はソフトウェアの不具合が40～50%。資料が古いので、本年度中に改訂して提示するとのこと。
• 自動車業界はソフトウェアに無関心。これから取り組む分野は、ソフトウェア満載。これをリスクと考えない、(良く分からない)文化。利益が計上されているうちは…。サプライヤは大変なことになるというリスクを持っている。
• 予防安全技術のてんこ盛り→自動運転へ
• 要件抽出⇔妥当性確認に時間を掛ける(時間が掛かる)、それ以外はドンと来いにしておかなければいけない。
• もし自動運転になったら、妥当性確認に11,415年時間が掛かる。これまでは41日間。
• 「自動運転社会を見据えた組込み技術者のミッションとは？－君の開発したソフトウェアは、技術者として安全だ！と言える？言えない？－」
  →昔は、カンと経験と根性。ISO9000認証を受けていれば、CMM、 CMMI、Automotive SPICE レベル3(疑念だらけの認証)、ISO26262準拠。

質問：
講師が考えるアーキテクチャの意味とは？
→要求をどうやった手段で実現するか？作ったアーキテクチャに対して、特にパフォーマンスを気にする。理路整然と説明できること。組織も同様。アセスメントでは組織のアーキテクチャも見る。組織のアーキテクチャとソフトのアーキテクチャは一緒。美しいものから美しいものが出来上がる。

１．背景と目的

• 今、日本で何が起こっているか、・どんな教育が必要か、・本セミナーの目的、・日本の国語教育の問題点
• 論理は言葉で構成され、言葉は概念を表し、概念は行動となって現れる

Case1｢部下から提出された報告書、何を言いたいのかさっぱり分からない｣

• 上司が論理的に説明できていない。部下は上司からの指摘を言葉の好みとしか思っていない。
• 書類の往復ビンタ！

Case2｢提出されたヒヤリハット報告書、誰が何をしたのか経緯すら分からない｣

• 前後の余分な説明が多く、時系列を追って説明できていない。
• 登場人物2人までは上手く説明できるが、3名以上になると説明できない。
• 状況説明が多く、失敗の説明がないケースが多い。失敗しない人間はいない。原因は機械ではなく、人間にある。
• 発見の経緯(物理現象)には興味はない。原因に興味がある。
• 決して、受動態で書かない。神様がスイッチを入れたのか？
• 否定形は全て結果論。「～が出来ていなかった」は原因ではない。失敗学は何故それをしたか？である。

Case3｢顧客の話がまったく分からない。何度質問しても要領を得ない｣→聞き手にも論理性が必要！

• 顧客のニーズを掴んでいないわけではない。聞き手の整理ができていなかっただけ。

Case4｢お客様の要望をきちんと実現したはずなのに！出来上がってきたのは見当外れのシステムだった｣

• 失敗の発生源は顧客と合意した契約書、企画書、仕様書にバグだらけ。日本IBMは日本語の論理チェックをする専門のレビューワがいるため大赤字にならない。コンピュータのテクニックとは無関係。
• プログラムはifチェック。ここへの分岐は書いてあるが、これではない場合はどうするか？は書いていない。

今、日本で何が起こっているか

• 世界で最も文脈依存性が高い日本語文化。すべて明確に表さなくても、文脈から意図を汲み取ってくれる。
• 思考までもあいまいになっていることに気付いていない。
• 「暗黙の了解」に気付いていない。
• 原稿は飛ばさずにきちんと書く。喋る時は飛ばしても良い。ソフトウェア開発も同様である。
• 誤った言葉や文、造語・新語の氾濫。概念を共有できていないカタカナ言葉、バイト敬語（～でよろしかったでしょうか？、～のほう、大丈夫です、～になります）の氾濫、マスコミの影響大
• あまり意味も考えずに直感的な言葉を用いている
• 対面コミュニケーションの減少。業務効率向上、IT技術の進化→メールでの伝達が爆発的に増加
• 雰囲気を読めない、一方通行のメールで伝達するから

<Point>
人間は言葉を使って思考し、言葉を使って伝達する→言葉を思考と伝達の両方に大きく関与している。

本セミナーの目的

論理的思考に基づく論理的な論旨×論理的で明快な言葉や文章＝論理的伝達力

本セミナーで目指すのは

• 正しく表現されている
• 論旨が素直に繋がっている
• 100人が読んで100人とも勘違いを起こさない文や文章であり、その正しい論理性である
  →人間は言葉を使って思考し、言葉を使って伝達する。
  →論理は言葉で構成され、言葉は概念を表し、概念は行動となって現れる

ヒューマンエラーは｢人間だから｣で発生する。

• やらなければならないことを｢忘れた｣で表現するのは間違い。｢ヒューマンエラー｣は覚えなければ良い、｢誤認識｣はマーキングする、｢漏れた｣は左から順番に締める、｢不理解｣は教育する。
  →会社で使っている言葉はいい加減！

論理的とは

• 論理的とは？→思考を進める道筋・脈絡が整っている様
  理論→Theory、論理→Logic
• 論理的の反意語は？→感情的、感覚的
• 社内の会話、伝達、書類、意思疎通はすべて論理的である。感情的で仕事はできない。
• 社内だけではなく、社会生活においても同じ。
• 社内のすべての文書に論理性が必要
  →ソフトウェア開発の8割は日本語で書かれている。だから日本語が重要。

日本の国語教育の問題点

• メロスは走った！→美しい友情ですね！
  →道徳の時間にやってくれ！今は国語の時間だ！国語は何を学ぶべき時間なのか未だに分からない。
• 著者の意図を述べなさい。
  →出版社の締め切りに間に合わせよう！あながち間違いではない。幾通りも回答があることを問題にしている。

<Point>
　行間を読むことばかりを教えられた。
→ビジネス文書や理系の論文では最低の文章。はっきり書け！

• 感想文に点数を付ける先生
  →こう感じてはいけない！と言われたことになる。「感想小説文」、「感想表現文」という課題表現に変えるべき。
• 起承転結
  →ビジネス文書ではありえない構成を、全日本人が教わった。
  　A=B、B=C、…ところが本当はB=Cではない！実はB=Dである。ビジネスではあり得ない。
  →起承転結は小説の中にある。感動を目的とした教育である。
• 社会では｢結起承結｣があたりまえ！
  →但し、優秀な欧米人は序説で転を使うことはある。自論を論ずる時に転はいらない。順接で結べ！

<Point>
　つまり、日本の国語教育は「道徳教育、文学教育」であり、言葉の論理性をほとんど教えていない。日本国語（語学）の授業なのに。

• 学校で習った国語、受験で勉強した国語は漢字と文法以外は今すぐ忘れるべき！
• これを意識しないで社会人になるから、論理性が崩壊したままになる。
  →社会に出たら、学校とは全く異なる国語が要求されている！

２．単語

• 単なる単語の間違いではなくて、概念まで壊してしまうことがある。単語を正確に使おう！
• 言葉の概念を正確に理解すれば、明日から行う仕事の内容が変わるかも！｢信頼性とは、問題と課題の違い｣
• 単語を使った論理性の訓練方法。｢予防とは｣。重要な気づきになることがある。
• あまりうるさいことを言うと｢うざい｣と思われるから、そこそこに！

言葉は概念を表し、概念は行動となって現れる。

→単語を馬鹿にしない。単語にこだわる。

• 公開文書やビジネス文書では、間違った単語を書かないで下さい！
  →言葉は変化していくものである。年配も若者も言葉の使い方を分かり合って欲しい。
• 論理性の訓練を始めるときに、単語から入っていくと入りやすい。
• 単語を考察すると、重要な気付きにつながることがある。
• 失笑→辞書を引くと、大爆笑という意味。知っているか知らないかゲームではない。
• 対策とは→対抗策であり、～対策と言うときには「～」には「望ましくないこと」が入るべき。
  防災対策は言葉としてはおかしい。正しくは震災対策、防災策。
• 他に防寒対策、節電対策、防犯対策、省エネ対策、復興対策、復旧対策、安全対策、被災者支援対策もおかしい。
  全て「対」は不要。対策に対する対抗になっているので逆の意味になる。
• 全商品100円割引！→正しくは全商品100円値引き！割引は適切ではない。

<Point>
日常会話の中で単語に対する突っ込みゲームをする。但し、声に出すと嫌われるので、頭の中で考えるだけ。それが訓練になる。

• 超～とは→めっちゃではない。「一線を越えてしまってもはや～ではない」という意味、「very」ではない。
• 効率とは→（出力/入力）という割合のこと。高い・低いという概念は含まれていない。
  　業務/の効率化→高効率化、高率化
  　～のほうが効率的である→効率が良い、効率的には良い
• 難易度が高い→難度が高い。難易度という言葉は「難」だけを指すわけではない。
• ～化→「駅冷房化工事実施中。ご協力をお願いします」→駅冷房工事実施中
  　　　成果の「見える化」→「可視化」という美しい日本語にある。動詞に「化」をつけるな！
  使い方の判断方法は？（濱口さんの自論）
• AのB化と言うときは、（多くの場合）AとBは質が同じ言葉
• AがBに成る、と言い換えても成立すればOK
• 「化」を取って成立するものには「化」はいらない
• 方向を表す言葉に「化」はいらない
• ～のほう→使い方としては、何かとの比較、漠然と方向性を指すとき。敬語ではない。
• よろしかったでしょうか？→何故、過去形で表現したがるのか？「御確認頂けますでしょうか？」
• ～になります→何かに変身するのか？「～で御座います」あるファミレスチェーン店のマニュアルから。

単語を使った論理性の訓練方法

①違和感を感じたら、ピッタリ合う言葉を捜してみる。
②ピッタリ合う言葉を見つけたら、元の言葉との違いを説明してみる。
③その差を論理的に説明できれば考えが進み、さらに他人を説得できる。（伝達力向上）

<Point>
予防とは、異常の早期発見ではなくて、正常の持続努力である。確認は単なる発見行為であり、既に異常は発生している。

３．文

• 主語と述語の関係をはっきりさせろ！格助詞を間違えたら通じない。｢が｣は怪しい！
• 修飾関係や否定関係をはっきりさせろ！｢動詞＋動詞足＋ない｣に要注意！
• 文型を意識しろ！日本語だって第1～第5構文しかない！
• 余計な表現を取り去って、シンプルにして考えてみよう

英語と日本語の相違点

• 格助詞＝俗に「てにをは」と呼ばれる
  →「食べたい、ラーメンを、私は」でも日本語は通じる。英語に格助詞はないから順番を間違えると通じない。
  →日本語は格助詞を間違えるな！
• 「～が」は怪しい→極力「が」を使わない努力をする。使うな！とまでは言わない。
  →ラーメンが食べたい、の主語は？→私はラーメンを食べたい。
  →象は鼻が長い、の主語は？→象の鼻は長い。
  →ねずみは体が小さい、の主語は？→ねずみの体は小さい。
  →うには春先がおかしい、の主語は？→春先のうにはおいしい。
  →メロンパンはメロンが入っていない、の主語は？→メロンパンにはメロンは入っていない。

<Point>
英語が優れている訳ではなく、論理的に使っているだけ。決して、日本語は劣っている訳ではない。

受信の試験をしている為、以下の使い方は誤っている。実際にTVで放映された表現。

今、正しく映っているテレビは問題ありません。
今、正しく移っているご家庭は問題ありません。

※時間切れの為、講義はここで終了！

４．文章

• 接続詞の効果は大きい。論理に大きく関わる
• あいまいな接続詞を極力排除し、論理的に接続しよう
• ｢接続詞さえ見れば、およその論旨が分かる｣と言うほど、接続詞は重要！

５．論旨

• 論理矛盾に気がつくようになろう、・しっかりした論旨を組み立て、それが素直に読めるようにする
• 暗黙の了解を見える形にしながら、まず箇条書きで論旨を組み立てて、その後文章にして修飾する

６．より伝わりやすい文章を書くために

• 論理的伝達力を発揮するための｢勝利の方程式｣
• 比較して主張を明確にすることで説得力を増す。｢一方…｣
• 抽象化：事例から概念へと言い換えて主張を明確にする。｢つまり…｣事例は概念を説明するためにある。
• 抽象化：概念を説明することで言葉をはっきり定義する。｢…という…｣
• 具象化：事例を示して説得力を増す。｢例えば…｣
• 論理性を磨く訓練方法のご提案。教科書を使う。送信済みメールボックスを使う。TVに突っ込みまくろう。

まとめ

TVに突っ込みゲーム。

• ニュースのフリートークを聞きながら、3行を1行にまとめてみる。要約するだけで訓練になる。

組織力向上のためのリーダーシップ・マネジメントセミナー

リーダーシップを論理的に語ります。10月26日(水)に初リリースします。

１．今、なぜTPSか？

※TPSとは｢トヨタプロダクションシステム｣の略である。

１．１　今なお注目されるトヨタ式（１）

• 本日の講義は「トヨタ生産方式―脱規模の経営をめざして―（大野耐一著）」から抜粋している。

１．２　アジャイルの源流

• SCRUM、リーンソフトウェア開発はTPSを源流としている。

１．４　派生開発中心のソフトウェア開発

• トヨタが目指したのは「多種少量生産」。TPSは多種少量生産を低コストで実現するシステム。ソフトウェア開発の大半は派生開発であり、多種少量となり、マッチする

２．TPSとは何か？

• 古畑さんの個人的な見解で概略の説明があった。

３．TPSにおける改善

３．１　競争力とリードタイム

• 「いい仕事」とは、お客様に認めてもらえる仕事＝認める価値のある仕事（顧客第一）
• 改善とは、原価（工数）を小さくして、売り上げを大きくすること。
• 生産性の向上とは、工数を変えずにリードタイム（開発期間）を短縮すること。
• リードタイムを短くするには、開発における付加価値を生まないムダを排除する。
• 現場の問題意識を確認するために、問題、原因、対策、効果、ものさしを聞くことが有用である。

３．２　継続的改善

• ギャップ分析から解決すべき問題の順序を決め、「維持→改善」を繰り返す。どれから、どういうステップで進めるかが重要。
• １００点を狙わない。まずはバッターボックスに立つこと。０打数０安打より、１０打数１安打の方に価値がある。
• 改善はいつでも、だれでも、どこからでも。
• ソフトウェア開発では、原因と問題は複雑に絡み合っている。見えるのは症状だけのため、何が根本原因なのか現状を分析する。

３．３　ムダの徹底排除

• 作業をする上でなんら必要がない＝ムダ、付加価値はないが、今の作業条件下ではやらなければならないもの＝付加価値のない作業がともにムダである。
• ムダの徹底排除は、ムダを定義するところから始まる。
• 一般的な形でムダを定義しても具体的なムダの排除につながらない。ムダを見分ける「モノサシ」の定義が必要。
• 大野耐一氏の「ムダ」への考え方は、
  『「ムダというものはいったい、なぜ発生するのか」の問を一つ発することによって、それこそ企業存続の条件である利益の意味を問うことにもなるし、ひいては人間の働きがいの本質についても自問自答することになる。』
  であり、ムダの排除とは、利益の意味／働きがいの本質の追求である。

３．４　標準化

• 「標準」とは自ら作り出すものであり、オリジナリティや工夫が結集されたもの。
• 「標準」は「進歩」を助けるもの。現場の当事者が設定しなければ「進歩」のための標準にはなりえない。
• 日常管理（維持向上）はSDCA、方針管理（改善・革新）はPDCA。「標準」なくして「改善」なし＝"SDCA"なくして"PDCA"なし。（S：Standardize（標準化）、D：Do、A：Act、P：Plan）
• 標準化は標準活動後の歯止めの活動。改善活動が後戻りして効果が維持できないことを防ぐ（防止策）
• 標準は改善のベースライン。

３．５　人の育成のメカニズム

• トラブルを通して人を育てる。１個流しをして、学習せざるを得ない状況に追い込む。

３．５　人の育成のメカニズム

• 大野氏の指導は現場の人間を怒ることはなかった、管理者、スタッフには厳しかった。現場が勝手に失敗したのではなく、管理者がどう指示をしたか？
• 現地現物から５ゲン主義へ。机上の空論ではなく、ソフト屋なら設計書やソースコードを見る。

４．ソフトウェア開発への適用

４．１　人材育成

• 育成すべき人材像を決定する。
• 積極的支援。研修生と講師が課題解決に一緒に取り組む。上司がきちんと指導する。
• 人材像の定義。ソフトウェア開発を主導できる技術者として、「技術」、「実践」、「哲学」の観点で育成目標を定義する。

４．１　人材育成の事例

• 中堅社員を対象にハイタレント研修を実施。資料は事前送付し、講義は廃止した。質疑とディスカッションがメインの研修。
• 答えは教えない指導（支援のみ）→「こうしたらどうか？」。答えは技術者の頭の中にある。
• 最近の技術者は自分のやっていることを説明できない人が多い。

４．２　ムダの排除：Just In Time

• プロセス分析により、問題の所在を顕在化させる。重複や後工程で使わないドキュメントが存在する場合がある。

５．プロセス改善の本質

• 人間尊重に基づいた改善。昨今の事件のように、人の命を使って作ったものは売れない。
• 改善活動を成長の機会に。現場の目の色が変わる。人の成長が全てを変える。

５．１　人間尊重に基づいた改善

• 「仕事の喜び」、「仕事のやりがい」…「Joy of Work」の実現。管理者がその人を作る。

５．２　改善活動を成長の機会に

• 改善活動により、技術者、管理者、会社の成長を促進する。

５．３　プロセス改善モデル

• 現場の声に耳を傾け、現実を把握し、問題解決に立ち向かう。管理者も一緒に考えること。

６．まとめ

TPS：トヨタ生産方式

『人間の能力を十分に引き出して、働きがいを高め、設備や機械をうまく使いこなして、徹底的にムダの排除された仕事を行うというごく当たり前の、オーソドックスかつ総合的な経営システム』
『トヨタ生産方式は、量とスピードを追求するあまり、いたずらにロスを生み出してしまうマス・プロダクションとマス・セールスへのいわばアンチ・テーゼである。』

１．アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方

• 2011年から取り組んでいるアジャイルテスティングやQAの取り組み、考え方の紹介。
• DevQA(でぶきゅーえー)を流行らせて、開発とQAがコラボして品質が高いものを提供したい。
• 「品質を良くすることができなければ、アジャイル開発は成功しない」
  →テスティング、QAが支えていかなければいけない。

２．アジャイル開発の実態

• スクラムの手法についての詳細な説明は、本日は割愛する。（聴講者の中で「スクラムを聞いたことがない」という方はいないため）
  スクラムを中心とした話にはなるが、スクラム=アジャイルではないということは理解して頂きたい。
• 用語の定義に書かれていることは、本当に実現可能なのか？
  プロダクトバックログ：プロダクトに必要なものがすべて上げてあるリスト
  　→最初に必要なものをすべて上げることができるか？　→できない！
  スプリントバックログ：プロダクトバックログの項目を完成させるために必要な作業の計画
  　“完璧な”必要な作業の計画を立てられるか？　→立てられない！
  ※初めから、プロダクトに必要なものをすべて上げること、完璧な作業計画を立てることは、不可能である。
  　スプリント計画を行う理由、デイリーミーティングを行う理由は、そこにある。
• デイリーミーティングは、計画通りに行かないから実施する。
  「昨日実施したこと、今日実施することの報告」そんなことをするためだけにやるのではない。
  リスクや問題を明らかにして共有し改善していく。短い一定周期で改善活動を回すことが重要。
  →自ら現場が改善活動を回していく。これがアジャイルである。
• 要求のクリープは、PO（プロダクトオーナー）とSM（スクラムマスター）が同一人物の時に起きやすい。それは、チームを健康に保とうとするSMの意識よりも、売上向上のために要求を受け入れようとするPOの意識の方が勝ってしまうためである。
  →POとSMは別々にしなくてはいけないが、実際は同一人物のケースが多い。
• ストーリポイントとは、スプリントバックログを見積る際の単位。プランニングポーカーと呼ばれているが、必要な作業の大きさを相対値で表す。例えば、ある入力画面の構築を5としたら、編集画面の構築は3くらい、というように相対的な大きさを感覚で出す。
  →工数（時間）で見積る方が正確なように思うかもしれないが、個人差が出るし、プレッシャーにも弱い。
• Velocityとは、イテレーションあたり、開発チームがDoneしたスプリントバックログのストーリポイントの合計、すなわち、チームのイテレーション当たりのパフォーマンスである。
  →Velocityは増えていくものだと考える人がいるが、容易に増えるものではない。改善活動以外では増えない。
• QAが、早期からのシステムテストの実施に介入する。
  →システムテストをイテレーションでちゃんとやる。パフォーマンス問題が出荷前に分かったのでは遅すぎる。
• QAが、設計フェーズに飛び込み、早いタイミングで評価しよう。
  →しかし、本来の設計をやりたいのに、QAが設計に入ってくると、あれを出せ、これを測れ、あれを直せと言われて、余計な負荷がかかる。そのため、設計リーダのガードは固い。
  では、どうすれば良いか？　暗黙知で会話しているチームの輪に、どうやったらQAが入り込めるのか？
  そこで、登場するのがDevQAの考え方である。

 

３．DevQA

• DevQAの形成。
  →QAは設計をサポートし、チームとして働く。テストや品質測定を行いフィードバックしてあげて品質の見える化を行えるようにする。設計の邪魔をされるのではない、ということに気付いてもらう。
  
• アジャイルで、できるだけ短い時間間隔でリリースを行うのは、フィードバックを早く得たいからである。
• 本当の価値は顧客からのフィードバックからしか得られない。紙ベースでは要求が正しく取れないため、顧客からフィードバックをできるだけ早く得たい。本当に顧客がほしい価値をデリバリしたいため、モノを早く出してフィードバックをもらう。それがアジャイル開発の本質である。
• これからは、ドキュメントに書けない時代である。IoTは、もやもやしている。そんな中でも、新しいアイデア=価値を速く市場に出したい。しかし、セキュリティ障害は起こせないし、品質は妥協できない。ところが、自分たちだけでなく、他のシステムとの協業、他社との協業が必要なため、仕様は変わるし決まらない。
• DevQAループの設計・成立のために重要なのは、何をフィードバックするのか、そのために必要な情報は何かを説明すること。相手が合意すれば、時間を割いて、その情報、成果物を用意してくれるはずである。
• テストでは、何をいつどのようにテストするのかを説明し、そのテストをするためにどんな情報や成果物が必要かを説明する。すなわち、テスト計画である。
  →テスト計画が立てられないと、DevQAループは回らない。
• QAがどうやってテストベースを手に入れるかという課題があるが、待っていてはダメ。
  →QAが開発に入り込んでいく。ドメイン知識を学び、スクラムのイベントに必ず参加する。

４．DevQAの改善事例

• SM（スクラムマスター）がQAの人と一緒にQAを実施した事例。SMが主導でユーザストーリー単位のテスト設計を実施し、そのテスト設計にQAが主導で評価観点を肉付けした。テスト設計で足りないインプットが見つかりQAからPO（プロダクトオーナー）にフォードバックするようSMが促す。
  →フィードバックループによって、結果的にPOはQAと開発からフォードバックを受けるようになった。
• "仕様通り"という理由で開発から返されるバグ報告の量が2割から1割以下に減少した。
• 開発が、QAのテスト設計をレビューするようになった。
  →テスト項目が多いが、無駄なテストはないだろうか？
• 開発とQAが同じ場所で作業していると、バグの修正内容をチケット更新だけでなく口頭で伝えられるので、バグ発生時の動作が把握し易い、というメリットがある。
• 設計とQAの信頼関係が重要。暗黙知だけでなく、形式知とセットで共有する。

 

５．アジャイル開発のメトリクス

• ウォーターフォール開発でも進捗会議をしているが、Velocityや計画と実績の差異を細かい周期では見ていない。そのため、QA-in判定間際で火を噴く。
• Velocityは上げようとしてもなかなか上がらない。人が減ると下がるが、人を増やしても下がる。 Velocityを上げるためには、振り返りとカイゼンが必要である。
• Velocityに対するアンチパターン。
  →長時間残業、休日出勤はダメ。無知見開発は派生開発の特に悪いパターン。
• 大事なのは、チームが健康であること。健康は品質に関わるため、ストレスに敏感になること。
• バックログのDoneの定義には、必ずQAも関わること。
• QA-in以降のバグの分布を見ると、本事例では、基本機能のバグは、QA-in前の評価で取られている、または、始めから入り込んでいない。
• QAが作成するテストケースが、製品の詳細な振る舞いの仕様書となり、開発部隊はテストケースを開発のゴール（神様）と見なすようになった。すなわち、開発がQAの価値観を信頼するようになった。

 

６．ポイント

• 一晩でできたことではない、最初は不完全なもの。QAを巻き込み、フィードバック、振り返りを繰り返し少しずつ変えていった結果である。

 

７．課題

• SM（スクラムマスター）への依存度が高く、自立できていない。
• Velocityがなかなか上がらない。人がやめるなどコントロールできない面がある。しかしマネージャーは無闇に上げたがる。
• 人の育成が重要。自立的に動ける人材が必要。但し、時間が掛かる。
• このようなアジャイルチームになるまで２年かかった。アジャイルの普及活動も含め時間が掛かる。

 

最後に

• 「品質とは誰かにとっての価値である。」ジェラルド・ワインバーグ
• ATDD(Acceptance test-driven development)
  顧客の真に求める価値を理解し、表現、(測定)できなければ保証はできない。
  →ビジネスモデル、要求開発の世界へ

 

質疑応答

①　ATDDにおいて、詳細の振る舞いはQAが作るとのことだが、設計が作るのではないのか？
→設計では例外処理が弱い。設計ではリストや条件、タイミングの記載はあるが、QAでポイントを抑えた振る舞いのテストケースが出来上がるはず。

②　スクラムの構成は？
→大規模開発のアジャイルの適用は難しい面がある。20人以上になってくると、コミュニケーション面で上手く回らないため、バックログを細分化してグループ化する。但し、バックログ間で齟齬が起きないような対策が必要。

③　実践アジャイルテストでペアテストがあるが、開発者が開発したら隣ですぐにQAが機能テストをしているイメージメージで良いか？
→大切なのは、何をテストするか？どんな品質にするか？をプランニングした上でフィードバックしないと、意味がない。QA観点でどういう観点で品質を見ていくか？を狙っている。  

１．つながる世界の開発指針～安全安心なIoTの実現に向けて～

<ビデオ講義>

• IoT：Internet of Things（インターネットオブシングス）の略。
• 17の指針
  例）
  
  • 保守：アップデートを自動的に実施。ログの分析・保管。
    
  • 運用：パスワードが出荷時のまま、アップデートされていなかった。つながるリスクへの周知。
    
• IPAにおいて、17の指針の続編を策定中であり、2017年3月以降に発行予定。

２．IoTの特徴と開発の課題

• 設計がまとまってからセキュリティの対処を検討するのではなく、もっと企画・設計の前段階から考えることが重要である。
• 米国で14歳の少年がATMのハッキングをした事件があったが、幸いにもホワイトハッキングであり、脆弱性を発見してもらったこともあって後で表彰された。
• IoTハッキング技術を身につけ、実践を始めるハッカーが増加する一方で、ハッキングコンテストを実施して脅威に対応している組織もある。
• IoTセキュリティの対象となる機器やシステムに対する脅威には様々なものが想定されるが、全て洗い出されていない。更に、業界、製品、システムごとに要件が異なるため、セキュリティ対応レベルが異なり、標準化の動向も異なっている。
  →故に、IoTのセキュリティを確保するための技術や手法、標準、基準はまだ確立されていない。

３．セキュリティ・バイ・デザイン

• セキュリティ・バイ・デザインとは、「情報セキュリティを企画・設計段階から確保するための方策」である。
• 平成28年8月26日に内閣府サイバーセキュリティセンターから発表された「安全なIoTシステムのためのセキュリティに関する一般的枠組」はIoTの憲法と言われている。
• セキュリティ・バイ・デザインのメリットは、以下である。
  ①手戻りが少なく納期を守れる
  ②コストも少なくできる（運用時のセキュリティ対策コストは、設計時を1とした場合の100倍）
  ③保守性の良いソフトウェアができる
  セーフティの観点だけでなく、セキュリティの観点も追加して、総合的観点で問題の解決にあたることが重要。

４．セキュリティ設計　主な分析技法・リスク評価手法

• そもそも、セキュリティ設計ができていないのではないか？
  →セキュリティ設計の基本方針・設計ルールを明文化している組織は多くない。分母は少ないが、調査対象の約半分が「明文化されたものはない」というデータがある。
  
• セキュリティ設計プロセスは、要件定義、設計の各フェーズで脅威分析（セキュリティ要求分析）を実施して、随時反映する。
  
• セキュリティ機能は「非機能要件」であり、お客様に納得していただき、ギャップを埋めることが難しい。
• セキュリティ特有の課題として攻撃者の存在があるが、世の中には良い人しかいない訳ではなく、悪い人もいる前提で考える。
• 脅威の特定・分析手法として、以下の例がある。
  
  • STRIDE：マイクロソフトが定義する脅威モデル
  • ミスユースケース：ユースケースに攻撃者を追加したミスユースケース図
  • Attack Tree：攻撃者のゴールを設定し、ゴールに至る攻撃手順をツリー上に展開
• 脅威に対するリスクの見積もり及び評価には、以下の例がある。
  
  • ハザード分析を利用したリスク評価：FTA、FMEA、HOZAPなどのセーフティ手法
  • CVSS：情報システムの脆弱性に対するオープンで汎用的な評価方法
  • i＊（LIU法）：ゴール指向要求分析の1つである i＊手法を拡張したセキュリティ要求分析手法
  • SARM：攻撃と通常のシステム機能との間のセキュリティ上の関係を分析するための要求分析手法

５．セキュリティ設計の評価・認証

• 「保証」を英語で言うと、「assurance（アシュアランス）」である。
  
• 汎用的で広く認知されたセキュリティ基準として2つの国際規格がある。
  
  • CC（ISO/IEC15408）=ITセキュリティ評価標準  →セキュリティ機能を評価する規格である 　
  • ISMS（ISO/IEC27001）=セキュリティ・マネジメント規格  →セキュリティ機能を評価する規格ではない
• 一般のIT機能は実際に利用してみることで保証されていることを確認できるが、セキュリティ機能は不測の事態を発生させて正確かつ有効に動くことを確認することは困難である。
• 開発者がセキュリティ保証を検証しなければならない。このセキュリティ保証を確認するのが第三者によるセキュリティ評価である。
  →セキュリティ評価の国際規格：コモンクライテリア（CC）の保証
• 具体的にはCC（ITセキュリティ評価の国際標準）を基にセキュリティ仕様を書いて、評価する。
• CCRA：セキュリティ評価における相互認証を実現しており、日本を含む17カ国が認証書生成国、8カ国が認証書受入国となっている。
• CCは日本においては、電子複合機などの特定の製品の認証が多く、広く普及しているとは言えず、コストが掛かることを批判する人もいるが、認証制度運用方法と認証の方式や参照とする基準は分けて考えるべきである。又、セキュリティ機能要件というツールボックスと保証要件の規定という優れた点がある。
• PP（Protection Profile）とは、特定の製品分野のために用意されるセキュリティ要件であり、想定されるセキュリティ課題、機能要件を定義し、調達者、業界団体等が開発し、調達要件として活用するものである。
  →実際のPPはIPAのサイトから参照可能であり、誰でも見ることができる。
• PPは評価対象のタイプ（OS、ファイアウォール、スマートカード等）に対するセキュリティの設計仕様書であり、具体的な実装方法に依存しないため、多数の製品・システムのST（セキュリティターゲット）で再利用可能である。

６．ロジカルな設計品質の説明

• セーフティとセキュリティの概念：セキュリティはセーフティを含む。
• セキュリティ・バイ・デザインの考え方はセキュリティだけのものではない。セキュリティで脅かされるセーフティも守ることができる。
• セキュリティ設計プロセスの「脅威分析（セキュリティ要求分析）」とセーフティ設計プロセスの「ハザード分析」は一緒にやる。
  →双方が“設計品質を見える化”して、持ち寄ってすり合わせを行う。

７．アシュアランスケースによるセキュリティ要件の見える化

• アシュアランスケース（ISO/IEC15026）とは、テスト結果や検証結果をエビデンスとしそれらを根拠にシステムの安全性、信頼性を議論し、システム認証者や利用者などに保証する、あるいは確信させるためのドキュメントである。
• GSNは代表的なアシュアランスケースの表記法であり、保証のための構造化された議論の記述ができる。
• 日本で主流のウォーターフォールモデルはイテレーションがないため、セキュリティ・バイ・デザインを実現しにくい。
  →外注によってソフトウェアを作ると、ウォーターフォールになりがちであり、要件が頻繁に変わることに対応し辛い。
• 設計、QAの双方でセキュリティに関するケースを作成し、それをぶつけることによって脆弱性を発見する。

全体的なPoint！

• セキュリティ・バイ・デザインは企画・設計段階から！
• セーフティ設計とセキュリティ設計の擦り合わせ！
• その設計によって目標が達成されることが事実に基づき論理的に説明されていること！
• 設計の見える化、変化するリスクへの対応、セーフティとセキュリティの擦り合わせ！

ソフトウェア品質管理研究会新設コースの案内

• 第33年度ソフトウェア品質管理研究会（2017年5月～2018年2月）から、演習コースⅢ：セーフティ&セキュリティ開発が新設される。
  
  主査：金子 朋子（情報セキュリティ大学院大学）
  副主査：高橋 雄志（株式会社トレドシステム）
  アドバイザー：勅使河原 可海（東京電機大学）

質疑応答

• 「セーフティとセキュリティの特徴の比較」の発生頻度において、脅威の洗い出しをするが、それに対してどのような優先順位で対策を取捨選択するのか?
  →現在基準がないが、確立しようと研究中の人もいる。発生頻度よりも、重要度の方が重要と考えており、そちらに重み付けをして対処することも考えられる。
  →現場では、たくさんリスクを洗い出すが論理的に洗い出せない。又、やりっ放しで定着しない傾向が強いため、合理的な選択基準があると良い。
• セキュリティとセーフティは全く考え方の空間が異なる。リスクを全て洗い出すことができない。そもそも、リスク認識ができないのではないか?
  →総当りでやらなければいけないのは事実。システムエンジニアリングの技法等で全体の構造を書いていかなければならない。AIに頼るべきという人も居る。
  →攻撃側の心理が解っていないと対策が出来ない。心理学的ところではないか?
  →何が目的でこういう攻撃をするのかの意図を把握することが重要でそれに対して対策を確実に実施できるのが理想である。攻撃者は脆弱性の穴を1つ見つければ良いが、守る方は全てに対応するので大変である。そうは言っても、悪意のない人間の方が多い。またセーフティに比べ、セキュリティは機能がはっきりしているという利点もある。