日科技連ホームページへ
SQiP研究会
SQiP研究会とはサイトマップお問い合わせ
ホーム > 研究会-ソフトウェア品質管理研究会 > 特別講義 > 過去の特別講義(2016年度)
ソフトウェア品質管理研究会
特別講義 2016年度
過去の特別講義: 2016年 2015年 2014年 過去のテーマ: 一覧
 
例会
回数
例会開催日 活動内容
 2016年
1 5月20日(金)

特別講義

テーマ 資本主義、プロ精神、品質、そして職業倫理
講演者 大場 充 氏
(広島市立大学名誉教授)
2 6月10日(金)

特別講義

テーマ 自動運転社会を見据えた組込み技術者のミッションとは?
ー君の開発したソフトウェアは、技術者として安全だ!と言える? 言えない?ー

講演者 小谷田 一詞 氏
(一般財団法人 日本自動車研究所 ITS研究部 主席研究員)
3 7月7日(木)~8日(金) 合宿
4 9月15日(木)~16日(金) ソフトウェア品質シンポジウム2016 本会議(会場:東京・東洋大学)
5 10月14日(金)

特別講義

テーマ 業務効率向上のための「論理的伝達力」
講演者 濱口 哲也 氏
(東京大学大学院 工学系研究科機械工学専攻 特任教授)
6 11月25日(金)

特別講義

テーマ トヨタ式カイゼン~TPSに学ぶプロセス改善の極意~
講演者 古畑 慶次 氏
(株式会社デンソー技研センター 技術研修部 担当課長)
7 12月16日(金)

特別講義

テーマ アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方
講演者 永田 敦 氏
(ソニー株式会社 IP&S 品質保証・サービスオペレーション部門 PSシステムクオリティ部SQM課 品質エンジニアリングマネージャ)
 2017年
8 1月13日(金)

特別講義

テーマ 「IoT時代」のセーフティ&セキュリティbyデザイン
~アシュアランスケースとコモンクライテリア(ISO/IEC 15408)
によるセキュリティの品質保証を考える~
講演者 金子 朋子
(情報セキュリティ大学院大学 客員研究員)
9 2月24日(金) 分科会成果発表会
戻る

第1回特別講義 レポート
日時 2016年5月20日(金) 15:15 ~17:15
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「資本主義、プロ精神、品質、そして職業倫理」
講師名・所属 大場 充 氏(広島市立大学名誉教授)
司会 小池 利和 氏(ヤマハ株式会社)
アジェンダ
  1. はじめに:資本主義と経済のグローバル化
  2. プロフェッショナリズムとその精神
  3. 品質論とソフトウェアの品質
  4. 倫理学とソフトウェア技術者の職業倫理
  5. 日本の雇用制度と技術者育成の課題
  6. 日本のソフトウェア技術者とその育成
アブストラクト

本テーマは大場さんが執筆した「資本主義、プロ精神、品質、そして職業倫理」の書籍に関する内容であり、これからのソフトウェア技術者に対する提言である。
昨今、各種業界で不正問題が取り立たされているが、ソフトウェア技術者の倫理観、社会的責任に着目し、「プロとして働く姿勢」が重要であると御教示頂いた。

その中で、必要な能力として、

  • 他の技術者による設計を評価する能力
  • ユーザの要求を理解・納得し、抽象化する能力
  • 良い仕事をしようと可能な限りの努力をする姿勢
が重要であり、これからの日本のソフトウェア技術者は、特定分野のプロとしての「知識」と「やる気」、「職業倫理」が問われることを御教示頂いた。

知識の習得や技術向上も重要ですが、プロ意識について改めて考え直す良い機会を頂いた講演でした。ありがとうございました。

講義の要約

第1回の特別講演では、「資本主義、プロ精神、品質、そして職業倫理」と題して大場さんから御講演を頂いた。 資本主義の歴史を振り返り、米国と日本の品質論、倫理学を対比しながら、どのように日本のソフトウェア技術者を育成していくかの留意点を御説明頂いた上で、これからの日本のソフトウェア技術者は、特定分野のプロとしての「知識」と「やる気」、「職業倫理」が問われることを御教示頂いた。
講演の最後にお話頂いたアメリカの飛行機事故の現場で自分より先に近くにいた女性、子供の救助を優先し、その結果、命を落とされた医師のプロ意識の高さに敬意を表した次第です。ありがとうございました。

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

資本主義

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

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

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

技術者育成の枠組み

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

米国の技術者の育成

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

米国の技術者と雇用制度

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

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

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

産業革命と品質概念

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

産業化社会と品質概念

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

1970年代の品質概念

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

日本的品質概念

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

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

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

ソフトウェアの変化

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

ものづくりの変革(例)

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

ものづくりの変革

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

何がかわったか

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

根本的な問題

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

倫理の起源

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

中世倫理観の歴史的変遷

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

資本主義の倫理観

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

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

  • 自動運転のプログラムは車の寿命より長い期間動かなければいけない。
5.日本の雇用制度と技術者育成の課題

日本の技術者育成

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

新しい時代の到来

  • ドイツや日本でアジャイルは上手くいかない。働き方が違う。個として働かない。アジャイルはフィンランドが向いている。
6.日本のソフトウェア技術者とその育成

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

  • 他の技術者による設計を評価する能力、ユーザの要求を理解・納得し、抽象化する能力が必要となる。更に良い仕事をしようと可能な限の努力をする姿勢
おわりに
  • 1991年、アメリカで川に飛行機が墜落し、たくさんの人が亡くなる大きな事故があった。その時、レスキュー隊が溺れ掛けている男性に今からあなたを助けに行くと声を掛けたら、自分ではなく、近くにいる女性と子供を先に助けるように言った。次にその男性を救助に行ったらその男性は居なかった。後でその人は医師であったことが判明した。いつも人を助ける仕事をしていたその男性は、自分の命の危機が迫る場面でも最後までプロ意識を忘れなかった。
戻る

第2回特別講義 レポート
日時 2016年 6月10日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ 「自動運転社会を見据えた組込み技術者のミッションとは?
-君の開発したソフトウェアは、技術者として安全だ!と言える?言えない?-」
講師名・所属 小谷田 一詞 氏(一般財団法人日本自動車研究所 ITS研究部 主席研究員)
司会 三浦 邦彦 氏(矢崎総業株式会社)
アジェンダ
  1. 機能安全との出会い
  2. 信頼性と安全性
  3. 自動車における機能安全とは
  4. 自動車用機能安全規格ISO26262
  5. 機能安全を通じて見えた物造りへのリスク
  6. これからの自動運転社会に向けて
アブストラクト

「自動運転社会を見据えた組込み技術者のミッションとは?-君の開発したソフトウェアは、技術者として安全だ!と言える?言えない?-」と題して、自動車用機能安全規格ISO26262をベースに他業種との共通の考え方や手法を御教示頂きました。

特に「思いもよらないユースケースに対処する要件抽出と、要件に対する妥当性確認に命をかける活動が重要」と提言しており、システムアプローチのスキルを持ったシステム技術者を目指して欲しいと期待されております。

多種多様な分野の技術者、管理者が集まる中で「機能安全」の本質と他業種への展開の方向性について学んだ講演でした。ありがとうございました。

講義の要約

第2回の特別講演では、「自動運転社会を見据えた組込み技術者のミッションとは?-君の開発したソフトウェアは、技術者として安全だ!と言える?言えない?-」と題して小谷田さんから御講演を頂きました。
小谷田さんはパナソニック(旧松下通信)出身でITS(Intelligent Transport Systems:高度道路交通システム)が特に強く、2012年に「機能安全」をきっかけにJARIに転職されました。
システムの企画から運用までを担当し、気象庁、鉄道、空港、放送局、警視庁、カーナビ、ITSシステム(AHS:自動運転の走り)等の実績があり、中でも車がとても好きで、自分で車検を取ってしまうほどであります。
今回は2020年に向けて自動運転が進んでいくので、「機能安全」という切り口で御講演頂きましたが、多種多様な分野の技術者、管理者が集まる中で自動車用機能安全規格ISO26262をベースに共通の考え方や手法を御教示頂きました。ありがとうございました。

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準拠。

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

戻る

第5回特別講義 レポート
日時 2016年 10月14日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 地下1階 講堂
テーマ 業務効率向上のための「論理的伝達力」
講師名・所属 濱口 哲也 氏(東京大学大学院 工業系研究科機械工学専攻 特任教授)
司会 小池 利和 氏(ヤマハ株式会社)
アジェンダ
  1. 背景と目的
  2. 単語
  3. 文章
  4. 論旨
  5. より伝わりやすい文章を書くために
アブストラクト

『業務効率向上のための「論理的伝達力」』と題して、日本語の特徴や日本の国語教育の問題点、英語との相違点などについて解説を頂いた上で、「いかに論理的に事象を伝えるか?」を御教示頂きました。
日頃、何気なく使っている日本語ですが、表現や使い方を間違えると齟齬が生じ、伝えたい内容が落ちてしまったり、曲がって伝わってしまいます。それは、プログラム開発の分野においても同様です。
そこで、「単語」、「文」、「文章」という切り口から注意点と使い方のテクニックを学び、身近な例題を用いて「論理的伝達力」の訓練をさせて頂きました。
今後、各分科会において論文を執筆しますが、その際にも大いに参考になる講演でした。ありがとうございました。

講義の要約

第5回の特別講演では、『業務効率向上のための「論理的伝達力」』と題して濱口さんから御講演を頂きました。
濱口さんには2014年度のSQiPシンポジウムで失敗学について御講演を頂きましたが、今回は「論理的伝達力」について御講演頂き、「日本語における論理性の重要さ」について御教示頂きました。
非常に勢いのあるアップテンポな講演でしたが、身近な例題を多用し、かつ時折ジョークを交えながら、楽しい雰囲気の中での講演会となりました。ありがとうございました。

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

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>
 つまり、日本の国語教育は「道徳教育、文学教育」であり、言葉の論理性をほとんど教えていない。日本国語(語学)の授業なのに。

  • 学校で習った国語、受験で勉強した国語は漢字と文法以外は今すぐ忘れるべき!
  • これを意識しないで社会人になるから、論理性が崩壊したままになる。
    →社会に出たら、学校とは全く異なる国語が要求されている!
2.単語
  • 単なる単語の間違いではなくて、概念まで壊してしまうことがある。単語を正確に使おう!
  • 言葉の概念を正確に理解すれば、明日から行う仕事の内容が変わるかも!「信頼性とは、問題と課題の違い」
  • 単語を使った論理性の訓練方法。「予防とは」。重要な気づきになることがある。
  • あまりうるさいことを言うと「うざい」と思われるから、そこそこに!

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

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

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

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

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

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

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

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

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

英語と日本語の相違点

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

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


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

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


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

4.文章
  • 接続詞の効果は大きい。論理に大きく関わる
  • あいまいな接続詞を極力排除し、論理的に接続しよう
  • 「接続詞さえ見れば、およその論旨が分かる」と言うほど、接続詞は重要!
5.論旨
  • 論理矛盾に気がつくようになろう、・しっかりした論旨を組み立て、それが素直に読めるようにする
  • 暗黙の了解を見える形にしながら、まず箇条書きで論旨を組み立てて、その後文章にして修飾する
6.より伝わりやすい文章を書くために
  • 論理的伝達力を発揮するための「勝利の方程式」
  • 比較して主張を明確にすることで説得力を増す。「一方…」
  • 抽象化:事例から概念へと言い換えて主張を明確にする。「つまり…」事例は概念を説明するためにある。
  • 抽象化:概念を説明することで言葉をはっきり定義する。「…という…」
  • 具象化:事例を示して説得力を増す。「例えば…」
  • 論理性を磨く訓練方法のご提案。教科書を使う。送信済みメールボックスを使う。TVに突っ込みまくろう。
まとめ

TVに突っ込みゲーム。

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

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

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

戻る
第6回特別講義 レポート
日時 2016年 11月25日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ トヨタ式カイゼン~プロセス改善の極意~
講師名・所属 古畑 慶次 氏(株式会社デンソー技研センター 技術研修部 担当課長)
司会 猪塚 修 氏(横河ソリューションサービス株式会社)
アジェンダ
  1. 今、なぜTPSか?
  2. TPSとは何か?
  3. TPSにおける改善
  4. ソフトウェア開発への適用
  5. プロセス改善の本質
  6. まとめ
アブストラクト

『トヨタ式カイゼン~プロセス改善の極意~』と題して、カイゼンの留意点や本質的な成果について、御教示頂きました。
現場では、日々改善活動を進めておりますが、問題の所在の顕在化やムダを見分ける「モノサシ」の定義までは適切に行えていないことが多いため、その勘所を御教示頂きました。
又、管理者の積極的な支援により、技術者のモチベーションが上がり、部門、ひいては会社全体の成長へと繋がるため、「管理者も一緒に考えること」の重要性を理解しました。
漠然としていたTPSの良さ、素晴らしさを、具体的なケースを用いて技術者に主眼を置いて御教示頂いた講演でした。ありがとうございました。

講義の要約

第6回の特別講演では、『トヨタ式カイゼン~プロセス改善の極意~』と題して、古畑さんから御講演を頂きました。古畑さんは、主業務は教育研修がメインですが、各種セミナーやフォーラムでの講演や「デンソーにおける人づくり、価値づくり、ものづくり」という書籍も共同執筆され、多方面で御活躍されております。本講演では、テクニックと言うより、本質的なカイゼンの成果についてお話をして頂きました。ありがとうございました。

1.今、なぜTPSか?

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


1.1 今なお注目されるトヨタ式(1)

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

1.2 アジャイルの源流

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

1.4 派生開発中心のソフトウェア開発

  • トヨタが目指したのは「多種少量生産」。TPSは多種少量生産を低コストで実現するシステム。ソフトウェア開発の大半は派生開発であり、多種少量となり、マッチする
2.TPSとは何か?
  • 古畑さんの個人的な見解で概略の説明があった。
3.TPSにおける改善

3.1 競争力とリードタイム

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

3.2 継続的改善

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

3.3 ムダの徹底排除

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

3.4 標準化

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

3.5 人の育成のメカニズム

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

3.5 人の育成のメカニズム

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

4.1 人材育成

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

4.1 人材育成の事例

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

4.2 ムダの排除:Just In Time

  • プロセス分析により、問題の所在を顕在化させる。重複や後工程で使わないドキュメントが存在する場合がある。
5.プロセス改善の本質
  • 人間尊重に基づいた改善。昨今の事件のように、人の命を使って作ったものは売れない。
  • 改善活動を成長の機会に。現場の目の色が変わる。人の成長が全てを変える。

5.1 人間尊重に基づいた改善

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

5.2 改善活動を成長の機会に

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

5.3 プロセス改善モデル

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

TPS:トヨタ生産方式

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

戻る
第7回特別講義 レポート
日時 2016年 12月16日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階 講堂
テーマ アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方
講師名・所属 永田 敦 氏(ソニー株式会社)
司会 中谷 一樹 氏(TIS株式会社)
アジェンダ
  1. アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方
  2. アジャイル開発の実態
  3. DevQA
  4. DevQAの改善事例
  5. アジャイル開発のメトリクス
  6. ポイント
  7. 課題
アブストラクト

『アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方』と題して、アジャイル開発の現場で起きている問題点、QAが現場に入り込む際の障壁などについて解説を頂いた上で、Developer(開発)とQAの協働の有り方とその効果について、実践から得られたノウハウや、成功事例を紹介頂きながら、御教示頂きました。
IoT時代に突入し、要件が決めきれない開発が増えていく中、アジャイル開発への取り組みは、今後ますます注目されていくと思います。永田さんは、いち早くからアジャイル開発の現場にQAの立場として寄り添い、品質改善を推進して来られました。開発とQAの間の見えない壁から生じる様々な課題に向き合い、苦労や工夫を重ねて来られた経験やノウハウ、そしてDevQA(開発とQAの協働)を広めたいという熱い想いが詰まった実践的で有意義なご講演でした。また、アジャイルの本質を改めて認識させられることもあり、多くの気付きを与えて頂けたご講演でした。ありがとうございました。

講義の要約

第7回の特別講演では、『アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方』と題して、永田さんから御講演を頂きました。
永田さんは、品質保証部にご所属で、主にアジャイル・コーチングを実施し、アジャイル開発の品質改善や、アジャイルRCAによるソフトウェア障害の要因分析と対策などを実践されておられます。また、国内・国外の各種ソフトウェア品質会議等で、アジャイル開発と品質保証の取り組みについてご発表されたり、世界で唯一の“アジャイル・インスペクション・マエストロ”の称号をお持ちであることから、ソフトウェア品質業界では、「アジャイルおじさん」、「世界のナガアツ」とも呼ばれています。
今回は、「DevQA(開発とQAの協働)」について御講演頂きました。開発とQAの信頼関係の構築、そして、その信頼関係の中で互いにフィードバックを得ることで、素晴らしい効果を生み出すことを御教示頂きました。ありがとうございました。

1.アジャイル開発の成功を握る、テスト・品質保証担当と開発チームの考え方
  • 2011年から取り組んでいるアジャイルテスティングやQAの取り組み、考え方の紹介。
  • DevQA(でぶきゅーえー)を流行らせて、開発とQAがコラボして品質が高いものを提供したい。
  • 「品質を良くすることができなければ、アジャイル開発は成功しない」
    →テスティング、QAが支えていかなければいけない。
2.アジャイル開発の実態
  • スクラムの手法についての詳細な説明は、本日は割愛する。(聴講者の中で「スクラムを聞いたことがない」という方はいないため)
    スクラムを中心とした話にはなるが、スクラム=アジャイルではないということは理解して頂きたい。
  • 用語の定義に書かれていることは、本当に実現可能なのか?
    プロダクトバックログ:プロダクトに必要なものがすべて上げてあるリスト
     →最初に必要なものをすべて上げることができるか? →できない!
    スプリントバックログ:プロダクトバックログの項目を完成させるために必要な作業の計画
     “完璧な”必要な作業の計画を立てられるか? →立てられない!
    ※初めから、プロダクトに必要なものをすべて上げること、完璧な作業計画を立てることは、不可能である。
     スプリント計画を行う理由、デイリーミーティングを行う理由は、そこにある。
  • デイリーミーティングは、計画通りに行かないから実施する。
    「昨日実施したこと、今日実施することの報告」そんなことをするためだけにやるのではない。
    リスクや問題を明らかにして共有し改善していく。短い一定周期で改善活動を回すことが重要。
    →自ら現場が改善活動を回していく。これがアジャイルである。
  • 要求のクリープは、PO(プロダクトオーナー)とSM(スクラムマスター)が同一人物の時に起きやすい。それは、チームを健康に保とうとするSMの意識よりも、売上向上のために要求を受け入れようとするPOの意識の方が勝ってしまうためである。
    →POとSMは別々にしなくてはいけないが、実際は同一人物のケースが多い。
  • ストーリポイントとは、スプリントバックログを見積る際の単位。プランニングポーカーと呼ばれているが、必要な作業の大きさを相対値で表す。例えば、ある入力画面の構築を5としたら、編集画面の構築は3くらい、というように相対的な大きさを感覚で出す。
    →工数(時間)で見積る方が正確なように思うかもしれないが、個人差が出るし、プレッシャーにも弱い。
  • Velocityとは、イテレーションあたり、開発チームがDoneしたスプリントバックログのストーリポイントの合計、すなわち、チームのイテレーション当たりのパフォーマンスである。
    →Velocityは増えていくものだと考える人がいるが、容易に増えるものではない。改善活動以外では増えない。
  • QAが、早期からのシステムテストの実施に介入する。
    →システムテストをイテレーションでちゃんとやる。パフォーマンス問題が出荷前に分かったのでは遅すぎる。
  • QAが、設計フェーズに飛び込み、早いタイミングで評価しよう。
    →しかし、本来の設計をやりたいのに、QAが設計に入ってくると、あれを出せ、これを測れ、あれを直せと言われて、余計な負荷がかかる。そのため、設計リーダのガードは固い。
    では、どうすれば良いか? 暗黙知で会話しているチームの輪に、どうやったらQAが入り込めるのか?
    そこで、登場するのがDevQAの考え方である。
 
3.DevQA
  • DevQAの形成。
    →QAは設計をサポートし、チームとして働く。テストや品質測定を行いフィードバックしてあげて品質の見える化を行えるようにする。設計の邪魔をされるのではない、ということに気付いてもらう。
  • アジャイルで、できるだけ短い時間間隔でリリースを行うのは、フィードバックを早く得たいからである。
  • 本当の価値は顧客からのフィードバックからしか得られない。紙ベースでは要求が正しく取れないため、顧客からフィードバックをできるだけ早く得たい。本当に顧客がほしい価値をデリバリしたいため、モノを早く出してフィードバックをもらう。それがアジャイル開発の本質である。
  • これからは、ドキュメントに書けない時代である。IoTは、もやもやしている。そんな中でも、新しいアイデア=価値を速く市場に出したい。しかし、セキュリティ障害は起こせないし、品質は妥協できない。ところが、自分たちだけでなく、他のシステムとの協業、他社との協業が必要なため、仕様は変わるし決まらない。
  • DevQAループの設計・成立のために重要なのは、何をフィードバックするのか、そのために必要な情報は何かを説明すること。相手が合意すれば、時間を割いて、その情報、成果物を用意してくれるはずである。
  • テストでは、何をいつどのようにテストするのかを説明し、そのテストをするためにどんな情報や成果物が必要かを説明する。すなわち、テスト計画である。
    →テスト計画が立てられないと、DevQAループは回らない。
  • QAがどうやってテストベースを手に入れるかという課題があるが、待っていてはダメ。
    →QAが開発に入り込んでいく。ドメイン知識を学び、スクラムのイベントに必ず参加する。
4.DevQAの改善事例
  • SM(スクラムマスター)がQAの人と一緒にQAを実施した事例。SMが主導でユーザストーリー単位のテスト設計を実施し、そのテスト設計にQAが主導で評価観点を肉付けした。テスト設計で足りないインプットが見つかりQAからPO(プロダクトオーナー)にフォードバックするようSMが促す。
    →フィードバックループによって、結果的にPOはQAと開発からフォードバックを受けるようになった。
  • "仕様通り"という理由で開発から返されるバグ報告の量が2割から1割以下に減少した。
  • 開発が、QAのテスト設計をレビューするようになった。
    →テスト項目が多いが、無駄なテストはないだろうか?
  • 開発とQAが同じ場所で作業していると、バグの修正内容をチケット更新だけでなく口頭で伝えられるので、バグ発生時の動作が把握し易い、というメリットがある。
  • 設計とQAの信頼関係が重要。暗黙知だけでなく、形式知とセットで共有する。
 
5.アジャイル開発のメトリクス
  • ウォーターフォール開発でも進捗会議をしているが、Velocityや計画と実績の差異を細かい周期では見ていない。そのため、QA-in判定間際で火を噴く。
  • Velocityは上げようとしてもなかなか上がらない。人が減ると下がるが、人を増やしても下がる。 Velocityを上げるためには、振り返りとカイゼンが必要である。
  • Velocityに対するアンチパターン。
    →長時間残業、休日出勤はダメ。無知見開発は派生開発の特に悪いパターン。
  • 大事なのは、チームが健康であること。健康は品質に関わるため、ストレスに敏感になること。
  • バックログのDoneの定義には、必ずQAも関わること。
  • QA-in以降のバグの分布を見ると、本事例では、基本機能のバグは、QA-in前の評価で取られている、または、始めから入り込んでいない。
  • QAが作成するテストケースが、製品の詳細な振る舞いの仕様書となり、開発部隊はテストケースを開発のゴール(神様)と見なすようになった。すなわち、開発がQAの価値観を信頼するようになった。
 
6.ポイント
  • 一晩でできたことではない、最初は不完全なもの。QAを巻き込み、フィードバック、振り返りを繰り返し少しずつ変えていった結果である。
 
7.課題
  • SM(スクラムマスター)への依存度が高く、自立できていない。
  • Velocityがなかなか上がらない。人がやめるなどコントロールできない面がある。しかしマネージャーは無闇に上げたがる。
  • 人の育成が重要。自立的に動ける人材が必要。但し、時間が掛かる。
  • このようなアジャイルチームになるまで2年かかった。アジャイルの普及活動も含め時間が掛かる。
 
最後に
  • 「品質とは誰かにとっての価値である。」ジェラルド・ワインバーグ
  • ATDD(Acceptance test-driven development)
    顧客の真に求める価値を理解し、表現、(測定)できなければ保証はできない。
    →ビジネスモデル、要求開発の世界へ
 
質疑応答
① ATDDにおいて、詳細の振る舞いはQAが作るとのことだが、設計が作るのではないのか?
→設計では例外処理が弱い。設計ではリストや条件、タイミングの記載はあるが、QAでポイントを抑えた振る舞いのテストケースが出来上がるはず。

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

③ 実践アジャイルテストでペアテストがあるが、開発者が開発したら隣ですぐにQAが機能テストをしているイメージメージで良いか?
→大切なのは、何をテストするか?どんな品質にするか?をプランニングした上でフィードバックしないと、意味がない。QA観点でどういう観点で品質を見ていくか?を狙っている。  
戻る
第8回特別講義 レポート
日時 2017年 1月13日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 地下1階講堂
テーマ 「IoT時代」のセーフティ&セキュリティbyデザイン
~アシュアランスケースとコモンクライテリア(ISO/IEC15408)によるセキュリティの品質保証を考える~
講師名・所属 金子 朋子 氏(情報セキュリティ大学院大学 客員研究員 公認情報セキュリティ監査人)
司会 栗田 太郎 氏(ソニー株式会社)
アジェンダ
  1. つながる世界の開発指針~安全安心なIoTの実現に向けて~
  2. IoTの特徴と開発の課題
  3. セキュリティ・バイ・デザイン
  4. セキュリティ設計 主な分析技法・リスク評価手法
  5. セキュリティ設計の評価・認証
  6. ロジカルな設計品質の説明
  7. アシュアランスケースによるセキュリティ要件の見える化
アブストラクト

『「IoT時代」のセーフティ&セキュリティbyデザイン~アシュアランスケースとコモンクライテリア(ISO/IEC15408)によるセキュリティの品質保証を考える~』と題して、昨今のセキュリティ問題に対する対策について、御講演頂きました。

その中で、セキュリティ設計の重要性に触れ、セキュリティ・バイ・デザインの考え方のもと、主な分析技法・リスク評価手法、評価・認証、Protection Profileの適用、見える化のためのアシュアランスケース等について、御教示頂きました。

これまで、セキュリティ対策は必須であるとの漠然とした認識はありましたが、具体的に、どのような方法で品質保証をするかまでは確立されていなかったため、今回大変貴重な情報を御教示頂きました。

尚、第33年度ソフトウェア品質管理研究会から、「演習コースⅢ:セーフティ&セキュリティ開発」が新設されるため、興味のある方は是非とも参加して頂きたいと思います。
ありがとうございました。

講義の要約

第8回の特別講演では、『「IoT時代」のセーフティ&セキュリティbyデザイン~アシュアランスケースとコモンクライテリア(ISO/IEC15408)によるセキュリティの品質保証を考える~』と題して、金子さんから御講演を頂きました。
金子さんは、10年ほど前から情報セキュリティ大学院大学で学んでおり、公認情報セキュリティ監査人(CAIS)でもあります。又、産官学の組織に同時に所属している貴重な存在であり、多方面で御活躍されております。
以前、ソフトウェア品質管理研究会の特別コースに参加した経験もあり、研究者視点で丁寧に御説明頂きました。ありがとうございました。

1.つながる世界の開発指針~安全安心なIoTの実現に向けて~

<ビデオ講義>

  • IoT:Internet of Things(インターネットオブシングス)の略。
  • 17の指針
    例)
    • 保守:アップデートを自動的に実施。ログの分析・保管。
    • 運用:パスワードが出荷時のまま、アップデートされていなかった。つながるリスクへの周知。
  • IPAにおいて、17の指針の続編を策定中であり、2017年3月以降に発行予定。
2.IoTの特徴と開発の課題
  • 設計がまとまってからセキュリティの対処を検討するのではなく、もっと企画・設計の前段階から考えることが重要である。
  • 米国で14歳の少年がATMのハッキングをした事件があったが、幸いにもホワイトハッキングであり、脆弱性を発見してもらったこともあって後で表彰された。
  • IoTハッキング技術を身につけ、実践を始めるハッカーが増加する一方で、ハッキングコンテストを実施して脅威に対応している組織もある。
  • IoTセキュリティの対象となる機器やシステムに対する脅威には様々なものが想定されるが、全て洗い出されていない。更に、業界、製品、システムごとに要件が異なるため、セキュリティ対応レベルが異なり、標準化の動向も異なっている。
    →故に、IoTのセキュリティを確保するための技術や手法、標準、基準はまだ確立されていない。
3.セキュリティ・バイ・デザイン
  • セキュリティ・バイ・デザインとは、「情報セキュリティを企画・設計段階から確保するための方策」である。
  • 平成28年8月26日に内閣府サイバーセキュリティセンターから発表された「安全なIoTシステムのためのセキュリティに関する一般的枠組」はIoTの憲法と言われている。
  • セキュリティ・バイ・デザインのメリットは、以下である。
    ①手戻りが少なく納期を守れる
    ②コストも少なくできる(運用時のセキュリティ対策コストは、設計時を1とした場合の100倍)
    ③保守性の良いソフトウェアができる
    セーフティの観点だけでなく、セキュリティの観点も追加して、総合的観点で問題の解決にあたることが重要。
4.セキュリティ設計 主な分析技法・リスク評価手法
  • そもそも、セキュリティ設計ができていないのではないか?
    →セキュリティ設計の基本方針・設計ルールを明文化している組織は多くない。分母は少ないが、調査対象の約半分が「明文化されたものはない」というデータがある。
  • セキュリティ設計プロセスは、要件定義、設計の各フェーズで脅威分析(セキュリティ要求分析)を実施して、随時反映する。
  • セキュリティ機能は「非機能要件」であり、お客様に納得していただき、ギャップを埋めることが難しい。
  • セキュリティ特有の課題として攻撃者の存在があるが、世の中には良い人しかいない訳ではなく、悪い人もいる前提で考える。
  • 脅威の特定・分析手法として、以下の例がある。
    • STRIDE:マイクロソフトが定義する脅威モデル
    • ミスユースケース:ユースケースに攻撃者を追加したミスユースケース図
    • Attack Tree:攻撃者のゴールを設定し、ゴールに至る攻撃手順をツリー上に展開
  • 脅威に対するリスクの見積もり及び評価には、以下の例がある。
    • ハザード分析を利用したリスク評価:FTA、FMEA、HOZAPなどのセーフティ手法
    • CVSS:情報システムの脆弱性に対するオープンで汎用的な評価方法
    • i*(LIU法):ゴール指向要求分析の1つである i*手法を拡張したセキュリティ要求分析手法
    • SARM:攻撃と通常のシステム機能との間のセキュリティ上の関係を分析するための要求分析手法
5.セキュリティ設計の評価・認証
  • 「保証」を英語で言うと、「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(セキュリティターゲット)で再利用可能である。
6.ロジカルな設計品質の説明
  • セーフティとセキュリティの概念:セキュリティはセーフティを含む。
  • セキュリティ・バイ・デザインの考え方はセキュリティだけのものではない。セキュリティで脅かされるセーフティも守ることができる。
  • セキュリティ設計プロセスの「脅威分析(セキュリティ要求分析)」とセーフティ設計プロセスの「ハザード分析」は一緒にやる。
    →双方が“設計品質を見える化”して、持ち寄ってすり合わせを行う。
7.アシュアランスケースによるセキュリティ要件の見える化
  • アシュアランスケース(ISO/IEC15026)とは、テスト結果や検証結果をエビデンスとしそれらを根拠にシステムの安全性、信頼性を議論し、システム認証者や利用者などに保証する、あるいは確信させるためのドキュメントである。
  • GSNは代表的なアシュアランスケースの表記法であり、保証のための構造化された議論の記述ができる。
  • 日本で主流のウォーターフォールモデルはイテレーションがないため、セキュリティ・バイ・デザインを実現しにくい。
    →外注によってソフトウェアを作ると、ウォーターフォールになりがちであり、要件が頻繁に変わることに対応し辛い。
  • 設計、QAの双方でセキュリティに関するケースを作成し、それをぶつけることによって脆弱性を発見する。
全体的なPoint!
  • セキュリティ・バイ・デザインは企画・設計段階から!
  • セーフティ設計とセキュリティ設計の擦り合わせ!
  • その設計によって目標が達成されることが事実に基づき論理的に説明されていること!
  • 設計の見える化、変化するリスクへの対応、セーフティとセキュリティの擦り合わせ!
ソフトウェア品質管理研究会新設コースの案内
  • 第33年度ソフトウェア品質管理研究会(2017年5月~2018年2月)から、演習コースⅢ:セーフティ&セキュリティ開発が新設される。
    主査:金子 朋子(情報セキュリティ大学院大学)
    副主査:高橋 雄志(株式会社トレドシステム)
    アドバイザー:勅使河原 可海(東京電機大学)
質疑応答
  • 「セーフティとセキュリティの特徴の比較」の発生頻度において、脅威の洗い出しをするが、それに対してどのような優先順位で対策を取捨選択するのか?
    →現在基準がないが、確立しようと研究中の人もいる。発生頻度よりも、重要度の方が重要と考えており、そちらに重み付けをして対処することも考えられる。
    →現場では、たくさんリスクを洗い出すが論理的に洗い出せない。又、やりっ放しで定着しない傾向が強いため、合理的な選択基準があると良い。
  • セキュリティとセーフティは全く考え方の空間が異なる。リスクを全て洗い出すことができない。そもそも、リスク認識ができないのではないか?
    →総当りでやらなければいけないのは事実。システムエンジニアリングの技法等で全体の構造を書いていかなければならない。AIに頼るべきという人も居る。
    →攻撃側の心理が解っていないと対策が出来ない。心理学的ところではないか?
    →何が目的でこういう攻撃をするのかの意図を把握することが重要でそれに対して対策を確実に実施できるのが理想である。攻撃者は脆弱性の穴を1つ見つければ良いが、守る方は全てに対応するので大変である。そうは言っても、悪意のない人間の方が多い。またセーフティに比べ、セキュリティは機能がはっきりしているという利点もある。
第32年度SQiP研究会 成果発表会ルポ
〜ソフトウェア品質技術の領域を拡大し、適用する一年〜

大島 修(エプソンアヴァシス株式会社 第32年度SQiP研究会書記)

2017年2月24日(金)に日本科学技術連盟 東高円寺ビルにて、第32年度(2016年度)SQiP研究会の成果発表会が開催されました。今回はその成果発表会の模様とSQiP研究会の紹介、1年間の研究活動を通して感じたことを記載します。

SQiP研究会とは

ソフトウェア品質管理研究会(SQiP研究会)は、ソフトウェアの品質管理への入門としての位置づけから、高い管理技術、開発技術を目指した議論・学習できる場として、幅広い要請にこたえる内容と品質管理分野の第一人者を指導者として高い評価を得て、今年32年目を迎えます。毎年、各企業からソフトウェア品質の向上を目指し約100名を超える方々が参加されています。本研究会のメインの活動である分科会では「問題発見」、「解決手段」、「実践」という3つの視点からソフトウェア品質技術を研究、調査、実践していきます。分科会の他にも、特別講義(計6回)や箱根での1泊2日の合宿、そしてSQiPシンポジウムを通じ、体験し気付きを得ることで、成果を出す仕組みとなっています。

研究員の職場の問題発見

  • 最先端を知る(特別講義・指導陣)
  • 他社からの新たな視点 (研究員)
  • 客観的な意見 (指導陣・研究員)

解決手段

  • 専門的知識 (指導陣)
  • 豊富な実践経験 (指導陣)
  • 深く考える (指導陣・研究員)

職場での実践

  • 相談ができる (指導陣)
  • 心の支えになる (研究員)
  • 一生付き合える仲間

今年度は、マネジメントとエンジニアリングの両面をカバーする7つの分科会と3つの演習コース、1つの特別コースが設けられ、個人や組織において有用な新技術の発明、および、既存技術の整理、実問題へのノウハウの蓄積と展開について成果を上げました。

成果発表会の模様

冒頭、小池委員長から、来賓の研究員の上司の皆様方に向けて「業務ご多忙の中、ハードワークなこのSQiP研究会に部下の皆様を派遣していただき、誠にありがとうございました。」と挨拶が行われました。その後、昨年度のアンケート結果から、アイスブレイクが必要と判断し、2人1組となって話す側は研究の中で良かったこと、嬉しかったこと、感動したことをお話していただき、聴く側は少々オーバーに傾聴する機会を設けました。アイスブレイクは場の雰囲気を和らげることは勿論ですが、「苦しい思い出だけでこの研究会を去っていくのは申し訳ないため、良いイメージでお帰りいただくこと」が目的でした。短時間ではありましたが、研究員、上司の皆様方も終始にこやかに会話を交わし、小池委員長のご配慮によって、和やかな雰囲気の中で成果発表会に入りました。

成果発表会は、1発表につき15分間のプレゼンテーションと5分間の質疑応答により実施されました。今回は16件の論文報告と4チームの活動報告がありました。各チームとも、この一年のSQiP研究会の活動の集大成としての成果報告であるが故に、いずれも完成度の高い、緊張感のあるプレゼンでした。

SQiP研究会の成果発表会は、従来は発表の中で寸劇が行われたり、楽器の演奏をしたりするなど、趣向を凝らした発表が行われてきたようですが、今回は比較的オーソドックスなプレゼンが目立ちました。それだけ今回は演出に拘らず、内容を重視したプレゼンをしようと考える研究員の意気込みが感じられました。

発表者から一番近くの席で書記として携わった立場で述べると、いずれのチームの発表も質問時間を含めて制限時間内で収めるための工夫がなされており、プレゼンの構想をとことん練り上げ、練習に練習を重ねて本番に臨んだ努力が感じられました。

発表の様子
 

また、昨年度からの取り組みとして、来賓の上司の皆様方と指導講師との昼食懇談会、並びに成果発表会終了後の情報交換会の二回、直接的なコミュニケーションの機会がありました。派遣する際のお気持ちや部下の取り組み・成果について指導講師とリラックスした雰囲気でお話されていました。お忙しい中、参加していただいた上司の皆様方には終日参加する事は難しい方も多かっただけに、この昼食時の懇談会は好評だったようです。

懇談会の様子
上司の皆様と指導講師の皆様

成果発表会の終了後、表彰式が行われ、その後の各分科会・コースでの反省会をもって、今年度のSQiP研究会活動が終了しました。

最後は、来賓の上司の皆様方も含め全員参加による情報交換会が開催されました。締めは、長年このSQiP研究会に携わっていただき、この度SQiP研究会から離れられる第2分科会副主査の板倉 稔 様からご挨拶をいただき、閉会となりました。

今年度の受賞結果

審査方法は、成果発表会で発表された16本の各論文に対して、担当分科会以外の3名の指導講師が査読を行い、「有用性」「信頼性」「構成力」「新規性」を観点に審査を行いました。その後、一旦集計をして、全てのコメントを精読し、表彰に値するか審議を行い、そして現実と懸け離れていないかプレゼンを聞いて最終確認を行いました。
審査結果について、鷲﨑副委員長から「最優秀賞1件、優秀賞1件、技術奨励賞1件」が発表され、以下のとおり3本の論文について小池委員長から表彰されました。

【最優秀賞】
第6分科会(派生開発):Bグループ
『派生開発での時間効率性劣化を変更要求から検出する方法』
<鷲崎副委員長からのコメント>
変更があった場合の性能の劣化を取り扱っており、身近で現実的な問題にチャレンジしている。それに対する有用性の高いソリューションになっており、論文自体もきちんと書けている。今後、更に研究を進めていただきたい。

【優秀賞】
第3分科会(ソフトウェアレビュー):トレーニングチーム
『レビューア向け思考能力トレーニング法の提案-仮説力と要約力で、重大欠陥の検出効率向上-』
<鷲崎副委員長からのコメント>
レビューア向けに社説などから推測をしてレビューの能力を鍛えていく内容であったが、論文としてよく書けており、筋も良い。実際にレビュー能力の増強に繋がるかはこれから実証していくことになるが、そこに期待する。

【技術奨励賞】
第7分科会(欠陥エンジニアリング):Team KuKuRu
『ソフトウェア欠陥の共起性を利用した欠陥推定手法の提案~共起欠陥推定アプローチによる潜在欠陥の捕捉~』
<鷲崎副委員長からのコメント>
意欲的な研究として奨励し、今後の期待を込めて表彰させていただく。
技術的なチャレンジが良い。ユニークだが王道のテーマである。本当に有用かどうかは今後しっかり実証していって欲しい。1年後に有用であったか是非とも発表していただきたい。

<小池委員長から総括>
第32年度の論文には3つのジャンルがあった。
1つめは、ソフトウェア技術の応用
2つめは、トレーニングやコミュニケーションといった人の問題
3つめは、既存のソフトウェア技術に新しい技術を加える。(一網打尽、テキストマイニングなど)
SQiP研究会としては、使えそうだ、有用性といった観点が重要視される。今後はSQiP研究会の内輪だけではなく、対外的な学会や各種団体へも発信できるようにしていきたい。未来誰かがやってくれるのではなく、自分達でやり続けて欲しい。

 
最優秀賞

第6分科会(派生開発):Bグループ
『派生開発での時間効率性劣化を変更要求から検出する方法』

第6分科会(派生開発)Bグループ
指導講師・メンバーと小池委員長・鷲﨑副委員長
優秀賞

第3分科会(ソフトウェアレビュー):トレーニングチーム
『レビューア向け思考能力トレーニング法の提案
 - 仮説力と要約力で,重大欠陥の検出効率向上 -』

第3分科会(ソフトウェアレビュー)トレーニングチーム
指導講師・メンバーと小池委員長・鷲﨑副委員長
技術奨励賞

第7分科会(欠陥エンジニアリング):Team KuKuRu
『ソフトウェア欠陥の共起性を利用した欠陥推定手法の提案
 ~ 共起欠陥推定アプローチによる潜在欠陥の捕捉 ~』

第7分科会(欠陥エンジニアリング)Team KuKuRu
指導講師・メンバーと小池委員長・鷲﨑副委員長
 

また、成果発表会でのプレゼンテーション内容についての審査も行われ、以下のチームがベスト・オブ・ザ・プレゼンテーション賞を受賞しました。

【ベスト・オブ・ザ・プレゼンテーション賞】
第4分科会(ユーザエクスペリエンス(UX)):リライトチーム
『ユーザのぼやきから始める使い勝手の問題箇所導出手法の提案』

演習コースⅡ(形式手法と仕様記述)
『さまざまな視点に合わせた仕様書の作成・維持の支援手法』

<小池委員長から総括>
プレゼンテーション技術の完成度が高い第3分科会と聴衆を惹きつけるような演出力の高い第7分科会で票が割れたが、最終的にはプレゼンの「わかりやすさ」が決定打となった。

 
ベスト・オブ・ザ・プレゼンテーション賞

第4分科会(ユーザエクスペリエンス(UX)):リライトチーム
『ユーザのぼやきから始める使い勝手の問題箇所導出手法の提案』

第4分科会(ユーザエクスペリエンス(UX))リライトチーム
指導講師・メンバーと小池委員長・鷲﨑副委員長
ベスト・オブ・ザ・プレゼンテーション賞

演習コースⅡ(形式手法と仕様記述)
『さまざまな視点に合わせた仕様書の作成・維持の支援手法』

演習コースⅡ(形式手法と仕様記述)
指導講師・メンバーと小池委員長・鷲﨑副委員長

SQiP研究会の活動を振り返って

第32年度ソフトウェア品質研究会
エプソンアヴァシス株式会社
品質管理部 大島 修 氏

 日科技連の「品質保証部長の会」に所属している上司からの薦めもあり、SQiP研究会に初めて参加させていただきましたが、第7分科会欠陥エンジニアリングの研究員と書記を担当する中で多くの学びがありました。
まず、分科会については、複数名の研究員で白紙の状態から1つの研究テーマを導き出し、そのテーマに対して深く追求すると言う経験がなく、要所でグループワークの難しさを痛感しました。特に「用語の定義」については顕著であり、各企業で日常的に使われている用語の意味が異なり、その認識を合わせるところからスタートしました。
 更に研究を進めると、自身の知りたいことと、他の研究員の知りたいことに微妙な乖離が生じ、メーリングリストや直接的なコミュニケーションに多くの時間を費やしました。年末年始休暇も最大限利用し、指導講師のお二人の熱心で的確なアドバイスによって何とか論文を書き上げましたが、当初想定していた壮大なスケールではなく、まさに誰も足を踏み入れたことのない分野に切り込み、納得のいく論文が書き上がりました。最終的に苦楽をともにした第7分科会の他のチームで技術奨励賞をいただいたことも大いに励みとなりました。
それと並行して、他の2つのチームとの連携や応援の言葉が心に残っており、新しい技術や手法の研究のみならず「人間力の醸成」についても良い機会となりました。ここに来なければ会えなかった人、ここに来なければ行かれなかった場所、全てが人生の財産です。SQiP研究会の本当の醍醐味は、そこにあるのではないでしょうか?
 日本中の企業でSQiP研究会への参加に対して二の足を踏んでいる上司がいらっしゃいましたら、人材育成を目的とした参加でも十分成果は得られると思います。ご検討下さい。
第33年度SQiP研究会については、当社から新たな1名を派遣することが決定しており、私自身、特別講義(計6回)の申し込みをさせて頂きました。第32年度の成果発表会は終了しましたが、それと同時に第33年度SQiP研究会、そして我々研究員の果て無き研究がまたスタートしました。
 このSQiP研究会から、日本、そして世界を驚かす研究が発表される日が来ることを心より祈念しております。貴重な経験を本当にありがとうございました。

 

おわりに

SQiP発足から33年目となる2017年度も今年度に引き続き「ソフトウェア品質技術の領域を拡大し適用する一年」と いうメインテーマを掲げ、既に研究員の募集も開始されています。2017年度から「要求と仕様のエンジニアリング」、「セーフティ&セキュリティ開発」、「品質技術の実践」の3つの分科会が新設され、研究の幅も更に広がります。
SQiP研究会は、3年前から(1)研究成果の質の向上、(2)習得スキルの実務適用、という2つの方向性で運営されています。

(1)を目指す研究員は、SQiPシンポジウムや他の学会への論文投稿へのチャレンジもサポートしていきます。
(2)を志す研究員に対しては、1年間の活動終了後にも、実務に適用した経験を共有できる場を設け、研究会卒業後も刺激を与えあうような関係性を維持する仕掛けを作ります。

つまり、品質管理に関するベテランでも、初学者でも各自のレベル、指向にあった場が提供されているのが、SQiP研究会なのです。是非、初学者の育成や職場の将来を担うリーダーの育成としてSQiP研究会を活用していただければ幸いです。

戻る
研究会
ソフトウェア品質管理研究会
ソフトウェア品質知識体系ガイド
 
 
日本科学技術連盟

SQiPは、ソフトウェア品質管理技術・施策の調査・研究・教育を通じて、実践的・実証的な
ソフトウェア品質方法論を確立・普及することにより、ソフトウェア品質の継続的な向上を目指します。

 
 
Copyright© 2015 Union of Japanese Scientists and Engineers. All Rights Reserved.