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

特別講義

テーマ システム×デザイン思考とアーキテクチャ思考による新価値創造
講演者 白坂 成功 氏
(慶應義塾大学大学院 システムデザイン・マネジメント研究科 教授)
2 6月14日(金)

特別講義

テーマ グラフィックレコーディングを使ったコミュニケーション
講演者 本園 大介 氏
(NTTテレコン株式会社)
3 7月11日(木)~12日(金) 合宿
4 9月12日(木)~13日(金) ソフトウェア品質シンポジウム2019 本会議 (会場:東洋大学(東京・文京区))(予定)
5 10月11日(金)

特別講義

テーマ プロジェクトリーダーのためのプロジェクト健全化技法
講演者 石谷 靖 氏
(株式会社三菱総合研究所 デジタルイノベーション事業本部 主席研究員)
清 雄一 氏
(電気通信大学 大学院情報理工学研究科 准教授)
6 11月15日(金)

特別講義

テーマ IoT時代のリスク評価・リスクコミュニケーション
講演者 佐々木 良一 氏
(東京電機大学 総合研究所 特命教授/本研究会 演習コースⅢ アドバイザー)
7 12月13日(金)

特別講義

テーマ プロセス改善とソフトウェア品質
講演者 山田 淳 氏
(株式会社東芝/本研究会 研究コース1 主査)
 2020年
8 1月10日(金)

特別講義

テーマ ソフトウェア疲労をアーキテクチャ設計で
講演者 山田 大介 氏
(ビースラッシュ株式会社 代表取締役)
9 2月21日(金) 分科会成果発表会
戻る

第1回特別講義 レポート
日時 2019年5月10日(金)15:15 ~ 17:15
会場 (一財)日本科学技術連盟・東高円寺ビル 地下1階講堂
テーマ システム×デザイン思考とアーキテクチャ思考による新価値創造
講師名・所属 白坂 成功 氏(慶應義塾大学大学院 システムデザイン・マネジメント研究科 教授)
司会 岩井 慎一 氏(株式会社デンソー)
アジェンダ
  1. はじめに
  2. 慶應義塾大学大学院SDMの紹介
  3. 慶應SDMが考えるイノベーティブ思考
  4. システム思考とは
  5. デザイン思考とは
  6. プラットフォームの創出
  7. まとめ
アブストラクト

昨今、AI/IoTなどの新技術を活用して新価値を創造することが強く求められていますが、実際に新価値創造を実現するのは容易ではありません。
本講義では、“イノベーティブさ”を意識しながらシステムをデザインするための方法論である“システム×デザイン思考”を解説するとともに、新価値創造のアプローチを紹介します。

講義の要約

講師紹介

白坂 成功 氏
東京大学大学院工学系研究科航空宇宙工学専攻 修士課程修了。
その後、三菱電機株式会社にて宇宙開発に従事。技術試験衛星VII型(ETS-VII)、宇宙ステーション補給機(HTV)等の開発に参加。特にHTVの開発では初期設計から初号機ミッション完了まで携わる。途中1年8ヶ月間、欧州の人工衛星開発メーカに駐在し、欧州宇宙機関(ESA)向けの開発に参加。「こうのとり」(HTV: H-II TransferVehicle)開発では多くの賞を受賞。現在、慶應義塾大学大学院 システムデザイン・マネジメント研究科 教授。


1.はじめに
  • 「Moonwalking Bearに気づかない」、「放射線技師の83%がゴリラを見逃した」などの例は、「白いシャツ」「がん細胞」のキーワードでバイアスをかけてしまい、人は無意識に情報を選択している。
  • 特定の集団は特定のバイアスにかかっていることが多い(専門家バイアス)。
  • 今の価値から新しい価値を見出す、つまり今までの価値から多様性を生かしながら積極的にバイアスがかかって見えないことを見に行くことでイノベーティブを見出していく。
  • バイアスがかかっている中で生活している日常から、必要な時にバイアス外の考えができるようにすることを目指す。
2.慶應義塾大学大学院SDMの紹介
  • SDM:System Design and Management
  • 慶應義塾大学大学院システムデザイン・マネジメント(SDM)研究科は、専門に特化するのではなく、マルチディシプリンを束ねるインターディシプリナリーな育成を行う大学院。
  • 大学院2年生 8割、1年生 7割が社会人で占めマネジメントが多く、文系よりの構成となっている。ベースはシステムエンジニアリングとし、ひとつひとつの専門性を追求するのではなく束ねることにより新価値を見出す。コンポネントな知とアーキテクチャルな知をもつ「ナブラ型人材」を目指す。
3.慶應SDMが考えるイノベーティブ思考
  • イノベーティブな思考は、システム思考をベースにしながらデザイン思考により創造的に思考することで生み出される。「システム×デザイン思考」。
  • 専門家バイアスがかかると観点が広がらない。一方、非専門家の場合は重要でないコメントも多いがバイアス外の観点、意見が出やすい。
    多様性の活かし方、集合知の出し方・原理を理解してイノベーションの価値を狙うことが大切である。
4.システム思考とは
  • システム思考には、広義の「システム思考」と狭義の「システム思考」があり、本講義ではシステムエンジニアリングの一部である広義の「システム思考」のことをいう。
  • システム思考とは、目的指向もって体系的に全体をとらえる(全体俯瞰)ことである。
    また一人で全体をとらえることは難しく、多様な人々の考えを統合してシステムアプローチの実践ができる。
  • 多様な人々が集まると気になることや観点が人によってことなり、議論の発散、ねじれが生じる。
    これを回避するために、①同時に複数のことを言わない、②伝えたいことを端的に伝える、③言葉だけでディスカスしないことが大切である。
    ①同時に複数のことを言わない…視点・観点を決め、議論のポイントを絞ることが重要。
    ②伝えたいことを端的に伝える…ポイントを抽出することで焦点が絞られ考えざるを得なくなる。
    ③言葉だけでディスカスしない…日本語は具体的な表現をするには不得意であり、構造化と可視化されたものに対して議論することで具体的な議論がしやすくなる。
  • 机を囲んで対面で議論するよりホワイトボード等を使うことで人間同士の対立構造が軽減でき、同じ側にたった議論がしやすくなる。
  • 単に人を集めるのではなく、思考の発散と収束を“適切なタイミング”で適切に組み合わせ、思考の流れをデザインすることでイノベーティブな思考ができる。
  • また多視点の議論、ブレストの過程であがった意見は、思考のトレーサビリティを活用することでSpiral Upができる。
5.デザイン思考とは
  • デザイン思考はもともとスタンフォード大学の学生たちに足りない所を追加するためのアプローチ。
  • アメリカ合衆国カリフォルニアのデザインコンサルタント会社のIDEOでは、デザイン思考はマインドセットであると言われている。
  • デザイン思考は①共感、②問題定義、③創造、④プロトタイプ、⑤テストの5つのModeで構成されている。
  • Stepとして順番にやるのではなく、Modeとして“適切なタイミング”で実施することが大切。

①共感

  • N社が大学に冷凍食品おけるインサイトを依頼した結果、「冷凍食品はめんどくさい」。
    1週間、N社冷凍食品生活を実施した結果、点線から開封する、電子レンジの設定が毎食になるとめんどくさいとの意見の他、高齢者もマニュアルの字が小さく読まずに失敗をすることで冷凍食品を食べなくなっていたことが分かった。つまり、消費者である人間中心の考えから外れていたことが分かった。
  • 単に共感するだけでなく、“これまでとは異なる”問題を定義する必要がある。

②問題定義(リフレーム)

  • 誰もが考えている課題にそのまま向かっても解決できない。→リフレーミング。
  • リフレーミングとは、「普通じゃないけど面白い、しかも重要」という問題に捉えなおす、魅力的で実行する価値がある領域を見つけ出すなど、問いかけや観点を変えることで解決策が変わってくる。

    例1. ホーブディング(自転車用のヘルメット)
    通常の問題:どのようにしたら人々は自転車にのるときにヘルメットをかぶってくれるか。
    リフレーム:髪の毛がぐちゃぐちゃにならないでヘルメットがかぶれるか、必要な時だけヘルメットがかぶれるか。

    例2. 地球で最も深いゴミ箱
     通常の問題:どのようにしたら公園のごみをきれいにできるか。
     リフレーム:どのようにしたら人々は喜んでごみをゴミ箱にいれてくれるか。

  • 慶應SDMでは、1.今あるものから考えてみる、2.当たり前を疑ってみる、3.問題の完全な解決を目指さない、4.上位の目的で考えてみる、5.分析的アプローチで考えてみる、の5つのアプローチをしている。

③創造

  • 単にブレストしてもなかなか発散できない場合は、違和感をブレストすることで違和感の特徴量を利用してアイデアを創出(強制連想法)することで枠外の発想を生み出すことができる。
  • 人間は生まれながらにしてクリエイティブであるが、否定や批判されることでクリエイティブさが少なくなっている。
  • 仕事でも、落とし所を見つけることでイノベーションできなくなっている。→ 大丈夫、できるという信念を持たせることが大切である(クリエイティブマインドセット)。

④プロトタイプ、⑤テスト

  • プロトタイプでは分からないからやってみることが大事。
    知らないこと、知らない領域に挑戦するためにまずはやってみること、そしてやってみて分かったことを見つけることがプロトタイプの役目で、トライ&エラーの繰り返しである。
  • ピポットではアイデアは創出できない。インサイト(面白さ、新しさ)を実現するアイデアは多様であり本来のピポットである。つまりインサイト中心のプローチ。
  • インサイトとは今まで誰も知らなかった「洞察」「気づき」
  • インサイト中心の進め方:分たちが知らないことを知るために、作りながら手を動かしながら考える。
  • インサイトの例:見守りロボットをわざと段差にひっかけることで、ひっかかったロボットを老人が助けることで見守り機能を実現する。
  • インサイトはどこを確認、確度をあげたいかを意識しないと意味がない。
  • 二階建て経営において、既存事業では計画通り進めることがKPIであり、新規事業ではトライ&エラー施行の数がKPI、どちらのKPIかを業務ごとに考えてマネジメント実施するが、知っているつもりで分かっていないことが最も面倒となる。


  • プロセスフレームワークを試行錯誤で調査していき、システム思考が抜けないようにすることが大事であり、5つのモード、アビリティ、マインドセットの組み合わせが大切である。
  • イノベーティブ思考能力には、考えつける、見つける、説明できる 要素が必要であり、“見つけること”と“説明すること”は訓練できる。
  • イノベーティブさを説明できることで、既存のアイデアの横展開をすることができる。
  • 既存のいい事例はそのアイデアのポイント(良さの理由)を抽出した上で持っておくと横展開ができる。
6.プラットフォームの創出
  • 必要とされる力は、そもそも何を作るのか(What to meke)を考えるだけでなく、どう作るのか(How to make)も考えられる力が要求される。
  • システムと外界との関係性、システムを構成する要素とその構成要素間の関係性をアーキテクチャと定義する。
    さらに、時間要素(過去、現在、未来)の関係性も見なくてはならない。
  • エンジニアリングの方法であるサイエンスは数式で構成されるため、インプットが同じだとアウトプットも同じになる。またアーキテクティングの方法であるArtは人への依存度が大きく結果が安定しないため、ルールや手順を決めるより人材育成が重要である。 参考著書:The Art of Systems Architecting
  • 多様な考え方を統合する。
  • 多様な業をつなげる人たちとディスカスする場合は、「構造化」と「可視化」つまりアーキテクチャが必要で多様な意見を得ることができる。
  • ものごとの何をどう変えるかはもともと何がどうなっていたかを知る必要があり、アーキテクチャは多様な“業”をつなげるSociety5.0の土台となる思考法となる。
  • プラットフォームを創出するには、デザイン思考的なアプローチだけではうまくいかない場合が多く、業を超えた繋がりを作ることで価値を提供することができる。
  • 業と業をつなげるという意味で「System of System」として扱われる。
  • 業は今まで縦割りで扱われており、横串がされてなかった。これまでの業とは違う切り方を示す=業の再定義が必要であり、プラットフォームの検討に活用できる。
    例えば、災害プラットフォームでは、避難者の見積りや電力状況の復旧予測、緊急車両の手配などの判断に活用できる。
7.まとめ
  • デザイン思考は4つのマインドセットを持つために体系化されたもので、ベースの違いを加味したアプローチが必要。
  • 日本では「多様性が機能する仕組み」、「システム的なアプローチの追加」することで、より「新価値創造」をガイドする方がよい。実際には、What to make / How to make を行き来して考える。
  • プラットフォームの創出では人間中心的なデザイン思考以外にアーキテクチャ思考が必要。
質疑応答
  • アジャイルとデザイン思考は同じように感じます。違いはありますか?
    ⇒アジャイルとデザイン思考は似ていて共通項はあるが、全く同じ思考ではない。

  • 品質とデザイン思考はリンクしますか?
    ⇒デザイン思考はユーザーにとって本当に価値があるかの観点が中心で、品質は全体的な観点でシステム思考が入ってくるため、直接的には関わってきません。
戻る

第2回特別講義 レポート
日時 2019年6月14日(金) 10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階講堂
テーマ グラフィックレコーディングを使ったコミュニケーション
講師名・所属 本園 大介 氏(NTTテレコン株式会社)
司会 金山 豊浩 氏(株式会社ミツエーリンクス)
アジェンダ
  1. グラフィックレコーディングについて
  2. なぜ今「グラフィック」なのか
  3. グラフィックXのいろいろ
  4. 顔の描き方
  5. まとめ
アブストラクト

議論や話し合いにおいては多様性を重んじた上で合意形成をし、より良い結論に至ることを目指す一方、現実では往々にして対立や軋轢が発生します。
本講義では会議やミーティングなど様々な立場の人が集まる場所で行われる議論をグラフィックで可視化する「グラフィックレコーディング」の解説とワーク実践により、より良い対話をもたらし、課題解決に導く手法を紹介します。

講義の要約

講師紹介

本園 大介 氏
大手通信関連会社でシステムエンジニアとして活動しながら、独学でグラフィックレコーディング(グラレコ)を学ぶ。現在企業に勤めながら、企業でのグラフィックレコーディングチームを組織しており、組織を横断する活動を実施。
また社外活動としても年100件以上のグラフィックレコーディングをこなす傍ら、講座等も行いグラフィックレコーディングの普及に寄与している。
受講生の中からグラフィック・レコーダーとして活躍する人が生まれるなど人材育成にも力を注ぐ。


1.グラフィックレコーディングについて
  • 「グラフィックレコーディング(Graphic Recoding)」とは、リアルタイム(-ing)に絵(Graphic)で記録(Record)することである。
  • 世界では当たり前の世界で2004年以前から使われている手法で、日本では2014年頃から流行し出している。
2.なぜ今「グラフィック」なのか
  • 今までは左脳思考(数理、論理)が主流だった。
  • イノベーションが求められ多様化する社会の中、最近では右脳思考(感覚、感性)が求められてきており、徐々に広まってきている。
3.グラフィックXのいろいろ
①グラフィックレコーディング
  • 話し手の内容を順次記録する、情報の流れが一方通行、話に介入しないような場面で使う。
  • グラフィックレコーディングは、講演、講座、対談などに利用できる。

②グラフィックファシリテーション
  • 絵やアイコンを使う点では、グラフィックレコーディングと同じ。
  • 話しながら記録する、情報の流れが双方向、常にやりとりしながら進行するような場面で使う。
  • グラフィックファシリテーションは、会議、ヒアリング、ワークショップなどに利用できる。

③グラフィックコミュニケーション
  • 絵やアイコンを使って対話を可視化すること。
  • 聴き、そして話しながら記録する、情報の流れは1:1の双方向、時には相手に描いてもらうこともあるような場面で使う。
  • グラフィックコミュニケーションは、会話、カウンセリング、コーチングなどに利用できる。

  • まとめると
    スケッチノートテイク:一人でコツコツ記録を残す。
    グラフィックレコーディング:一人で絵を使って記録する。
    グラフィックコミュニケーション:絵を使って1対1で会話する。
    グラフィックファシリテーション:絵を使って1対多で会議する。

  • 【ワーク】 “せん” をテーマにグラフィックレコーディングしてください。
    <結果>
    単線、数字の1000、1000円札、コルク栓等々、人によって描くものが異なる。
    よって絵で示すことによって共通認識を持つことができる。

  • 「絵が苦手」の本質は、「みんなと同じ」でないから恥ずかしいということ。
    つまり、「うまい」「下手」ではなく「違う」だけであり、いろいろな「違い」を吸収して知識を広げることが成長の伸びしろとなる。
  • 外国人からしたら漢字だってアートと思うように、大事なのは発想力であり、引き出しを増やすことである。

  • 【ワーク】 「品質」/「ソフトウェア」で連想する言葉を共有してください。
    <結果>
    連想する言葉が他の人と異なることが多い。つまり人の頭の中は見えない、スキーマである。

  • 「普通」「常識」は人によって大きく異なる、ということを念頭に入れて、人とコミュニケーションをとっていった方が良い。

  • 悩み
    言いたいことが伝わらない、なぜか誤解される、伝わったような、ないような・・・という悩みの原因は、「イメージ言語間変換のずれ」であり、バイアスをかけてしまうからである。
  • 概念
    左脳(言語)と右脳(絵)のバランスをとりながらコミュニケーションとるのが大切である。
4.顔の描き方
  • 顔を描くのは難しいという思いを払拭するための手法を紹介する。
  • 人間の感情を表す顔は、眉、目、口の組み合わせだけで表すことができる。
  • 【ワーク】 「喜」「怒」「哀」「驚」を絵で表現してください。
    <結果>
    喜:口半開きにする 怒:眉毛を内側にたてる 哀:眉毛をねかす 驚:口が開いている
  •                
  • 【ワーク】ありえない顔を描いてみてください。
    <結果>
    左右対称で描いている限り、あり得ない顔はなく、何かの表情になってしまう。

  • 困り顔から笑顔などイメージの変化を表すことで意識共有がしやすくなり、ミーティングなどで使えてアイデアや発想が出やすくなる。
  • 似顔絵はその人のワンポイントのキャラクタを作る。そして“名前”をつけてデフォルトにしてしまう。
  • 眼鏡は眼鏡フレームの下半分だけで表現できる。
  • 眉毛を上げ気味にする:賢そうな表情、下げ気味にする:優しそうな表示にできる。
  • 目の下に三本線をつけることで可愛さを表現できる。
5.まとめ
  • グラフィックを活用することで、話し手、聞き手が気持ちよくコミュニケーションをとることができる。
質疑応答
  1. 絵を描いているツールはなにか?
    ⇒“プロクリエイト”というツールを使用している。

  2. 表情が読めない、笑っているような方の表現の仕方
    ⇒気持ちをグラフ状(上り気味、下がり気味)で示すことでコミュニケーションにも使える。

  3. 偉い方、上司の方を絵に描いて関係が悪くならないか?
    ⇒ナナメ線など危ない線をかかなければ関係悪くなることはないと思う。
     キラキラ度を増やすなどもサービス精神も忘れずに。

  4. 絵が得意な人など、記録する人が一人に偏ってしまうのではないか、偏ってしまってよいのか。
    どう受け止めたか、どう理解したかを可視化することが目的であるため、3、4人など複数で描くほうが望ましいと考える。

  5. ふざけているように思われないか
    ⇒チームメンバーなど小さいグループから徐々に活動範囲を広げていく方がよい。

  6. 似たような集団時の描き分け方はないか?
    ⇒その人の特徴的な感情を特徴的なイラストにすると見分けがつく。あとは名前で分けてしまう。一生懸命、似顔絵を描く必要はない。

  7. Windows系のハードウェアが必要か?
    ⇒ホワイトボードでも大丈夫。

  8. 色使いなど工夫点はあるか?
    ⇒黒と黄色と青を使うとよい。赤は見えにくいので避けたほうがよい。
戻る

第5回特別講義 レポート
日時 2019年10月11日(金)10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階講堂
テーマ プロジェクトリーダーのためのプロジェクト健全化技法
講師名・所属 石谷 靖 氏(株式会社三菱総合研究所 デジタルイノベーション事業本部 主席研究員)
清 雄一 氏(電気通信大学 大学院情報理工学研究科 准教授)
司会 猪塚 修 氏(横河ソリューションサービス株式会社)
アジェンダ
  1. プロジェクトマネジメントにおける課題
  2. プロジェクト健全化の課題
  3. プロジェクトのセルフ診断と課題抽出の実践方法
  4. プロジェクトの課題解決の実践方法
  5. まとめ
アブストラクト

プロジェクトマネジメントは永遠の課題です。特にシステム開発プロジェクトの成功率が低いと言われ続けています。
しかし当然のことながら、すべてのプロジェクトが失敗しているわけではありません。成功を重ねているプロジェクトマネージャを身近に見られることも多いでしょう。
成功するマネージャは知識や経験から自らのマネジメントスタイルを確立して、成功に導いています。共通しているのは、プロジェクト開始においてポイントを見極め準備万端にし、プロジェクトは常に状況が変わるものとして最重要ポイントのモニタリングとコントロールを続けていることです。
ご紹介する技法は、このような熟練者の視点・活動をモデル化したものです。電子政府立国として世界トップのデンマークでやはりプロジェクト失敗が続き、国を挙げてプロジェクト診断・解決モデルを開発したものです。今回これを日本で活用できるようにアレンジ・詳細化した「健全化技法」について考え方のみならず、実践方法までご紹介します。


※聴講後、自由に使っていただけます。

※参考文献:「プロジェクトをうまく進めるための17の鍵~ImprovAbilityによるプロジェクトリーダのためのプロジェクト健全化技法~」、2017年8月、オーム社

講義の要約

講師紹介

石谷 靖 氏

1988年株式会社三菱総合研究所に入社。
設計支援環境や品質メトリクス収集ツール等の構築を行うとともに、ユーザー企業におけるソフトウェア調達関係の要求定義や見積り等のガイドライン作成に従事。その後、プロジェクトマネージャとして開発や調査プロジェクトの統括・実施。特に、ソフトウェア開発プロジェクトにおけるマネジメントやプロセス改善に関する実態調査や技術調査に従事。その一環として、情報処理推進機構(IPA)とソフトウェア・エンジニアリング・センター(SEC)の設立を支援。
2004年4月から2007年3月までIPA/SECに出向、エンタープライズ系 サブ・リーダー。この間、2004年5月~7月 ドイツIESE(実験的ソフトウェア工学研究所)に派遣・滞在。 2007年以降SIerおよびITユーザー企業におけるプロジェクト診断、コスト評価、調達マネジメントおよび生産性向上を中心に支援し、最近はサービス設計の高度化の支援を展開。
今回のテーマに関して、2011年からデンマークDELTA社(現在はWhiteBox社)で開発されたImprovAbilityモデルをプロジェクト診断で活用開始し、現在に至る。

清 雄一 氏

2009年株式会社三菱総合研究所に入社。アジャイル開発調査や金融システム開発等に従事。
2013年より電気通信大学。エージェント、人工知能、プライバシ保護技術の研究を実施し、現在に至る。


[第Ⅰ部]モデルのご紹介

1.システム開発プロジェクトの課題

  • 最近は失敗より残念(ユーザーに感謝されない、使われない)なシステムの増加している。
  • 「感謝されるシステム」と「残念なシステム」の違いは何だろうか?
  • 熟練者は経験的に「成功のツボ」を知っている。

2.プロジェクトの成功のツボとそのモデル化

  • 上記経験者の成功のツボを「4つの力 17の視点」にモデル化した。
  • [4つの力]
    1)IT構想力
    2)IT構築力
    3)IT活用力
    4)IT基幹力
  • [17の視点]
    1)IT構想力
    ① プロジェクトコンテキスト
    ② アイデアの吟味
    2)IT構築力
    ③ チームの状況
    ④ プロセス
    ⑤ コンピテンスとナレッジ
    ⑥ 優先順位づけ
    ⑦ プロジェクトの目的とゴールの明確さ
    ⑧ マネジメントのサポート
    ⑨ 関係者の関与
    3)IT活用力
    ⑩ IT展開戦略
    ⑪ IT品質
    ⑫ IT展開手段
    ⑬ IT展開の役割と責任の明確さ
    ⑭ 保守と運用
    4)IT基幹力
    ⑮ 期待管理
    ⑯ ナレッジマネジメント
    ⑰ マネジメントコンピテンス

3.ImprovAbilityモデルの特徴

  • 目的は使えるシステムを実現することである。
    このために、プロジェクトを自己診断して、解決に向けての対策立案をサポートする。
  • キーワード
    (1)準備万端:分析と予測により準備万端にして成功の確立を高める。
    (2)リアルタイム改善:常に状況変化を察知し適切な対策を講じる。
  • 簡易なモデルと明確な手法
    17の視点でチェック、重要な項目の絞り込み、解決データベースを参考に対策を立案する。

4.開発経緯

  • 「成功のツボとは何か」を事例調査・分析。
    2003年~2006年のTalent@ITプロジェクトを集約し、54の基本パラメーターから20個のパラメーターへ。
    →プロジェクト診断では17個にした。
    ※ISO化:ISO/IEC TR 33014(2013年12月発行)

5.ImprovAbilityモデルのチェックポイント

  • 4つの力、17の視点と51の診断項目を参考にセルフチェックを行う。

6.課題抽出と解決策設定までの手順

  • 課題分析(51の診断項目での達成度判定表とプロジェクト特性要因評価))→評価(パラメーター重要度判定表)→課題絞り込み(達成度判定・重要度集約表)→解決策案(解決候補データベース)→解決案実行。
    ※(  )内は本TOOLのワークシート名

7.ImprovAbilityモデルのツール

  • ①チェックシート
    ②プロジェクトタイプ設定
    ③解決策データベース
[第Ⅱ部]ImprovAbilityの活用
  • プロジェクトリーダーのセルフ診断・解決の流れは次のとおり。
    第1ステージ「分析・評価による課題特定」
    第2ステージ「課題解決」
    両ステージを通して実際に自己診断、解決策候補を導き出すまでの流れを体験できた。
まとめ
  • ポイント:
    ①準備万端
    ②リアルタイム改善
  • ツボを押さえるためツボをモデル化したのがImprovAbilityである。
  • 実践のためのツールなのでぜひ、広く活用・フィードバックいただきたい。
質疑応答
  1. 自己診断で診断者はぶれないのでしょうか。
    ガイドラインは4段階で示しているが、解釈の違いが出る可能性はある。先輩などが問いかけて確認する必要がある。
  2. 診断の頻度・タイミングについて教えていただきたい。
    →開始時(準備万端)。大きなマイルストーン(要件完了で開発前、詳細設計前など)
    経験的には後ろに行けば行くほど、問題がわかっても解決が難しい。
    このため開発時にみて手を打つ、手を打たないものも可視化されているので気にしておける。
  3. 第三者レビューでの活用することは可能でしょうか。
    →可能である。もともとのモデルはアセッサー用のモデルなので活用は可能である。
    日本ではデンマークのモデルを自己診断できるようにしている。
  4. PJT特性はデンマークと同じものなのでしょうか。
    →PJT特性は同じ。変えてしまうと判断基準が不明になるので同じにしている。
  5. 計画で出ないものは後からでよいのでしょうか。
    →実施に展開することを最初考えてないことがあるため、できるだけ計画を早く考える必要がある。
  6. 期間の評価 12か月で3点とあるが、もっと長いのが多いのではないでしょうか。この点に関して、議論はあったのかご教示いただいたい。
    →日本だとすべてが重要になるので、デンマークと議論した。データ収集の観点もあり、条件を変えないという結論に至った。
  7. PJTの成功率が低いとあったが、このツールを使った場合の成功率はどれくらいでしょうか。
    →2011年から活用しており、アセスメントで使った15PJTで、結果的に失敗はない。
    ただし、診断を頼むPJTは問題意識があるので条件は同一ではない。
  8. エンタープライズ、組み込みの差はあるのでしょうか。
    →両方で使える。ただし、一部エンタープライズの言葉になっているので読み替えていただきたい。

講演者のご厚意により、本講義資料ならびにツールを公開しております。


【講義資料】

【ツール】

※本ツールはチュートリアルの演習用のツールであり、本来Excelで自動的に設定できる箇所も手動で入力する形式となっておりますこと、予めご了承ください。

戻る

第6回特別講義 レポート
日時 2019年11月15日(金)10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階講堂
テーマ IoT時代のリスク評価・リスクコミュニケーション
講師名・所属 佐々木 良一氏(東京電機大学 総合研究所 特命教授/サイバーセキュリティ研究所長/本研究会 セーフティ&セキュリティ アドバイザー)
司会 金子 朋子 氏(情報セキュリティ大学院大学/本研究会 セーフティ&セキュリティ 主査)
アジェンダ
  1. サイバー攻撃の動向
  2. 従来のリスク評価・リスクコミュニケーション
  3. 多重リスクコミュニケータMRCの基本方式
  4. 多重リスクコミュニケータMRCの拡張
  5. IoT時代のリスク評価・リスクコミュニケーション
  6. おわりに
アブストラクト

ITシステムは、社会の重要基盤の一つとなっており、その安全性が失われる影響は非常に大きなものになってきた。講演者らは、ITシステムに対する適切なリスク対策を可能とするためITリスク学の名のもとに、リスク評価・リスクコミュニケーション支援手法や支援システムの開発を行うとともにいろいろな実適用を行ってきた。IoT時代を迎え、従来の方式だけでは不適切であると考え、IoT時代に適したリスク評価・リスクコミュニケーション支援手法・ツールを開発するとともに、医療用IoTシステムなどへ適用した。本講義では、これらの研究結果について解説する。


講義の要約

講師紹介

佐々木 良一 氏

1971年3月 東京大学卒業。
1971年4月 株式会社日立製作所 入社

システム開発研究所にてシステム高信頼化技術、セキュリティ技術、ネットワーク管理システム等の研究開発に従事。
2001年4月~2018年3月 東京電機大学教授。
情報セキュリティの研究と教育に従事。
2018年4月 現職。


1.サイバー攻撃の動向

サイバー攻撃の歴史

  • セキュリティにとっての第一のターニングポイント:2000年 科学技術庁などのホームページの改ざん事件。
  • セキュリティにとっての第二のターニングポイント:2010年 Stuxnetの出現(遠心分離機への攻撃)
  • 第一と第二では攻撃目標が異なり、第二からは標的型に移ってきており、攻撃技術も高くなっている。

今後、増加が予想される攻撃

  1. 被害の大型化
    仮想通貨580億円相当の不正流出する事件
  2. 被害形態の多様化:機密性の喪失から完全性や可用性の喪失へ
    脅威の分類
    (1)機密性(Confidentiality)の喪失: 表法を不当にみられる
    (2)完全性(Integrity)の喪失:情報を不当に破壊、改ざんされる
    (3)可用性(Availability)の喪失:不当な利用によりデータやコンピュータパワーが使えなくなる
  3. 攻撃対象の多様化: PCなどからIoTなどへ
    IoTの特徴とセキュリティへの影響: IoTには、
    (1)脅威の影響範囲・影響度合いが大きい
    (2)IoT 機器のライフサイクルが長い
    (3)IoT 機器に対する監視が行き届きにくい
    (4)IoT 機器側とネットワーク側の環境や特性の相互理解が不十分
    (5)IoT 機器の機能・性能が限られている
    (6)開発者が想定していなかった接続が行われる可能性がある、
    という性質があり、セキュリティ対策がより重要になっている。また、IoTではセキュリティがセーフティに及ぼす影響を考えていく必要性が出てきている。
    例) 「制御装置: 電力会社へのサイバー攻撃で140万世帯が停電」、「自動車: Blackhatでの自動車の遠隔操作法の発表」、「電子掲示板: 交通標識が『ゴジラ来襲』と警告」
    また、製造工程からバックドアが設置されるなどのサプライチェーンにおける脅威もある。
  4. 愉快犯から経済犯・組織犯へ:犯罪組織の高度化
    昔は個人(愉快犯)が多かったが、今一番多いのは金銭入手である。サイバー犯罪者組織では役割の分化も行われている。
2.従来のリスク評価・リスクコミュニケーション
  • 社会のITシステムへの依存: ITシステムへの依存は増大しており、情報セキュリティの問題が重要
  • ISMSとPDCA: リスクマネジメントの仕組みとしてISMS(Information Security Management System)がある。ISMSとは、組織のマネジメントとして、自らのリスクアセスメントにより必要なセキュリティレベルを決め、プランを持ち、資源を配分して、システムを運用することである。(https://isms.jp/isms/)
  • リスクとは「将来の帰結に対する現在における予測」という見方が下敷きになっており、常に不確実性とをもなう。工学分野ではリスク=損害の大きさ×損害の発生確率で定義されるが、情報分野ではリスク=資産価値×脅威×脆弱性で定義される。
  • リスク社会: 自然災害などをコントロールするためのシステムが新たなリスクとして問題になってきている。
  • 誤ったリスク認識の例: 2001年の9・11後、飛行機が危険との認識で、自動車の利用者が増えたが、それによって、自動車事故の死亡者数が増加。飛行機による事故の約6倍であった。
  • 日本人のリスク感の特徴: ①リスクに極めて敏感でゼロリスクを求める傾向、②安全よりも安心を重視する傾向、③リスクに対しあきらめてしまう傾向
  • リスク社会学者などが指摘するようにリスクを制御するのは限りなく難しい。しかし、そこにリスクがある以上、当事者は万全の注意を払ってリスクに対応し続けるしかない。そのためITリスクに応じてどう対応すべきかを明確化していく必要がある。
  • リスク評価法の分類
    1. リスク分析のアプローチの方向
      ①ボトムアップ型(情報資産の洗い出し):チェックリスト法など
      ②トップダウン型(情報システム上の脆弱性の洗い出し):アタックツリー法など
    2. リスク分析における量的扱い
      ①定量的アプローチ:例) 指紋認証に関するアタックツリー分析法
      ②準定量的アプローチ:例)JPDECのリスク算出式、25マスによる準定量的分析方法
      ③定性的アプローチ:例)チェックリスト利用法、質問票利用法、シナリオ分析法
    3. リスク評価の目的と範囲
      ①リスクの大きな情報資産やシステムの明確化
      ②上記+必要なリスク対策の明確化:こちらが望ましい
3.多重リスクコミュニケータMRCの基本方式
  • 基本的認識とアプローチ
    1. ゼロリスクはないので定量的リスク評価が不可欠である。
    2. ITシステムのリスクは多様であるので、ITシステムが扱う情報の安全だけでなく、ITシステムそのものの安全や、ITシステムが行うサービスの安全も同時に扱う必要がある。
    3. リスク対策が別のリスクを引き起こすことがあるので「リスク対リスク」「多重リスク」への考慮が不可欠である.
    4. 多くの関与者がおり、パラメータの設定などに不確実性を伴うのでリスクコミュニケーションの導入が不可欠である
  • リスクコミュニケーションが必要になった背景
    (1)人はリスクの存在そのものを認識できないのではないか。
    人はリスクに直面し判断せざるを得ない場合は少なくないが人知を超える判断はいずれにしろできない。
    (2)リスクの存在を認識できたとしてもフランク・ナイトが指摘するようにその事象の発生確率は測定できない場合が多い
    (3)事象の発生確率やその損害の大きさを推定できたとしてもそれらの値そのものに不確実性が残る。
    ナシーム・タレブが指摘するようにすべての確率は主観確率。よって、各人の主観を明確にしそれらのあいだの合意形成を図るしかない
  • リスクコミュニケーションの分類と目的
    ・リスクコミュニケーションのフェーズ分類
    (フェーズ1)そのリスクに関連する情報を提供するフェーズ
    (フェーズ2)対象となる事象や対象システムが受け入れられうるものかどうかの検討のためのフェーズ
    (フェーズ3)そのままでは受け入れられないとすれば、どのような対策をとるべきかを決めるフェーズ
    ・リスクコミュニケーションの目的
    目的① 個人的選択:例)禁煙の実施、インフルエンザワクチンの接種
    目的② 組織内合意形成:例)工場の環境対策、オフィスの省エネ対策
    目的③ 社会的合意形成:例)原発再稼働の可否、BSE対策のための全頭検査
  • 多重リスクコミュニケータMRCの対象は目的②の組織内合意形成である。
  • MRCの背景
    背景1.多くのリスク(セキュリティリスク、プライバシーリスクなど)が存在⇒リスク間の対立を回避する手段が必要
    背景2.ひとつの対策だけでは目的の達成が困難⇒対策の最適な組み合わせを求めるシステムが必要
    背景3.多くの関与者(経営者・顧客・従業員など)が存在⇒多くの関与者間の合意が得られるコミュニケーション手段が必要
  • MRCにおける対応
    ①多くのリスクやコストを制約条件とする組み合わせ最適化問題として定式化
    ②関与者の合意が得られるまでパラメータの値や制約条件値を変えつつ最適化エンジンを用い求解
  • 関与者間のリスクコミュニケーションの一例
    1. 制約条件に関するもの
      (1)もっとコストをかけてもいいのではないか (従業員代表の意見)
      (2)情報の漏洩確率は、半分ぐらいにできないか (顧客代表や経営者の意見)
      (3)プライバシー負担度をもっと小さくしてほしい (従業員代表の意見)
      (4)利便性負担度をもっと小さくしてほしい (従業員代表の意見)
    2. 対策案に関するもの:この対策案は使いにくくて困る。外した場合の対策案最適組あわせを求めてほしい (従業員の意見)
    3. 対策効果などに関するもの:この対策はそんなに効果はないと思う
  • 納得のプロセス
    ①説明を聞くことによる納得(確かにそういうような対策案はあるな、確かにそういうような制約条件はあるな)
    ②条件を変えて再計算を行った結果による納得(パラメータの値を変えても最適の対策案はあまり変わらない)
    ③相手に対する信頼による納得(彼の言うことだから間違いないだろう)
4.多重リスクコミュニケータMRCの拡張
  1. リスクコミュニケーション法の拡張

    (1)合意形成対象者が1000人を超すような問題への適用
    ・合意形成対象者が1000名を超すような社会的合意形成問題には従来のMRCは適用できない。
    ・オピニオンリーダ向けの従来MRC支援システムであるMRC-Studioと一般関与者の意見を導入するためのMRC-PlazaからなるSocial-MRCを開発
    ・Social-MRCを青少年への情報フィルタリング問題に試適用。一般関与者20名のうち75%がSocial-MRCはこの問題に関する対策案の合意を形成するのに有効と回答。一般関与者の85%が最終回は合理的なものであると回答

    (2)経営者とのリスクコミュニケーションも考慮した多重リスクコミュニケータ

  2. リスク評価法の拡張

    (1)標的型攻撃等多段にわたる攻撃のリスク評価のためのリスク解析法(EDC法)の開発
    ・従来はアタックツリーを用いてリスク分析を行っていたが、EDC法を開発。
    ・イベントツリー分析とは、標的型攻撃メールなどの初期事象から時系列順に攻撃事象の成功・失敗を追うことでそれぞれのシーケンスの発生確率を求める分析手法。またそれぞれの発生確率にその影響度をかけることで定量的にリスクを求めることができる。
    ・発生確率を求めるために、ディフェンスツリー分析を用いる。
    ・東京電機大学の次期セキュリティ対策に対してEDC法を実適用し、リスクとコストが最少となる対策案を最適解として適用。

    (2)被害発生防止対策と復元対策の両方を考慮した対策案最適組合せ法
    ・イベントツリー分析法を採用することにより、確率と影響の大きさの両方の扱いを可能化
    ・PERT手法を用いることにより影響の大きさの推定を可能に

    (3)動的リスクを考慮した多重リスクコミュニケータ

    (4)発生確率の不確実性を考慮した多重リスクコミュニケータ
    ・発生確率をあいまいであると考えて、最適な組み合わせを求める。
5.IoT時代のリスク評価・リスクコミュニケーション
  • Society5.0:サイバー空間(仮想空間)とフィジカル空間(現実空間)を高度に融合させたシステムにより、経済発展と社会的課題の解決を両立する、人間中心の社会。IoTが中心となって入ってくる。
  • IoTの特徴とセキュリティへの影響: IoTには、
    (1)脅威の影響範囲・影響度合いが大きい
    (2)IoT 機器のライフサイクルが長い
    (3)IoT 機器に対する監視が行き届きにくい
    (4)IoT 機器側とネットワーク側の環境や特性の相互理解が不十分
    (5)IoT 機器の機能・性能が限られている
    (6)開発者が想定していなかった接続が行われる可能性がある
    という性質があり、セキュリティ対策がより重要になっている。また、IoTではセキュリティがセーフティに及ぼす影響を考えていく必要性が出てきている。
  • IoTシステムでは対象によってセキュリティ対策が大幅に異なる。
  • IoTシステムのリスク評価法の開発
    ・方式1:制御型IoTシステムに対するセキュリティとセーフティを考慮したリスク評価法
     例) インスリン注射システム
    ・フィードバックがあるので従来のアタックツリーのようなものだけではアンセーフな事象の適切な抽出が困難 → STPA手法によりハザードを導き出す
    ・従来のSTPAにはサイバー攻撃が入っていない → STPA手法にサイバー攻撃を追加
    ・STPAでは対策案までは対象としていない → 多重リスクコミュニケータを改良し、対策案の最適な組み合わせを求められるようにする
    ・方式2:センサー型IoTシステムに対するMSSを考慮したリスク評価法
     例)敷布型マルチバイタルIoTモニタ
    ・システム導入によるメリットとデメリットを考慮する
6.おわりに

まとめと今後の方向

  1. リスク評価方法の推移と最近の動向を紹介
  2. 特に、定量的リスク評価に基づき、対策案の最適組み合わせを求める多重リスクコミュニケータとその改良版について詳しく紹介
  3. 最近はIoTシステムのリスク評価方法や、サプライチェーンを考慮したリスク評価方法が大切になってきている
  4. 今後はAIシステムのリスク評価も重要に

質疑応答

  1. EDC法の東京電機大学への適用にかんして、セキュリティをどれだけのコストをかけるか:コスト試算について、どのように一般化していくらと分配したのか?
    →実際の分析は一回では終わらず、複数回行う。一回目はざっくりおこない、2回目以降はベンダーも決まってくるので、コストや効果が細かくわかってくる。
戻る

第7回特別講義 レポート
日時 2019年12月13日(金)10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 2階講堂
テーマ プロセス改善とソフトウェア品質
講師名・所属 山田 淳 氏(株式会社東芝/本研究会 研究コース1 主査)
司会 小池 利和 氏(ヤマハ株式会社/本研究会 運営小委員会委員長)
アジェンダ
  1. はじめに
  2. あるある問題(症状)1:プロセスが硬直化して「抜けガラ」に?
  3. あるある問題(症状)2:データを集めてはいるのですが…「モヤモヤ」?
  4. あるある問題(症状)3:どんな効果があるの???
  5. あるある問題(症状)4:モチベーションが上がらない(下がってしまう)!?
  6. おわりに
アブストラクト

ソフトウェアのプロセスを改善する基本的な目的は、要求仕様や設計、検証内容など総合的にソフトウェアの品質を改善・向上させ、再設計や不具合修正、再テストなどの後戻りの作業を削減し、開発のコストと期間を計画内に収めやすくしてQCDの三つをバランスよくコントロールすることにある。そしてユーザーや顧客が、望む時点で適切な費用で快適に利用して目的を達成でき、ユーザーや顧客の満足度の向上につなげる。しかしながら、実際にはプロセス改善が、このような、ユーザーや顧客、また開発チームや担当者へ提供できる効果や価値とうまく結びつくように行えるとは限らない。このような課題を取り上げながら、どのようにすればソフトウェア品質を向上させるプロセス改善となり得るのか、プロセス改善を推進し支援する「プロセスエンジニア」としての役割と活動とは何か、またファシリテーションというアプローチで進めるプロセス改善、そして、プロセス改善活動をより良いものにする方策について、考察し、紹介する。

講義の要約

講師紹介

山田 淳 氏
1984年、東芝に入社、ソフトウェア品質管理技術に関して、品質メトリクスを始めソフトウェア品質測定・評価技法、ソースコード品質分析手法・ツールの開発と普及に従事。その過程でソフトウェア品質特性モデルの標準化活動にも参加。さらに品質管理技術の適用支援・展開の過程で、ソフトウェア開発プロセスの改善に関する活動を始める。
1994年よりSW-CMM、2000年頃からCMMIなどのプロセス改善モデルも用いたプロセス改善・診断に携わっており、現在も主に東芝及び関係グループへ向けてのプロセス改善支援に従事している。


1.はじめに
  • ソフトウェアプロセス改善と品質とはどのように「関係させるか?」がポイントである。ドラッカーは「生産性の本質を測る真の基準は、量ではなく、質である」と述べている。
  • 一昔前、ソフトウェア品質保証活動はデバックや単体テスト以降のソフトウェア開発工程の後半に行われていた。
    • ソフトウェアの品質が良い ⇒ バグがない、動作中にバグが出ない。
    • 作ったソフトウェアから、どうやってバグを除去するか?
  • 今は開発中の工程内でできるだけ品質を作り込むため、ソフトウェア品質活動はすべての開発工程で行われるようになっており、プロセスの改善も進められている。
    • ソフトウェアの品質が良い ⇒ 顧客・ユーザーが実際に利用しているときに満足させられる。
    • どうやって品質を作り込みながら、ソフトウェアを作っていくか?
  • ソフトウェアプロセス改善(SPI:Software Process Improvement)は品質を作り込むためにある。
  • しかし、開発グループと品質グループとの間には「距離」「川が流れている」などがあるといわれている。品質保証担当からは、ソフトウェアやプログラムの設計・技術の観点から、品質上の問題点や対策方法、検証方法の詳細が分かりにくい → どの程度まで十分に品質を作りこめているかを十分に把握できない
    • 開発部門と品質部門とで品質作りこみ活動のコラボレーションができないか? → SPI活動
      • プロセスグループ(SEPG:Software Engineering Process Group:SEPG)を結成、組織化することになった。
    • 開発部門で品質向上のためにSEPGでSQAG (Software Quality Assurance Group) を結成し、SEPGとSQAGで開発部門と品質部門をブリッジしている。
  • SPI活動の役割と組織化:SPI活動の推進体制モデル(コラボレーションのための役割分担)
    • プロセス SEPG:プロセスを作成・改善する
    • 開発グループ:プロセスを実行して、開発・保守・運用サービスを行う
    • 品質 SQAG:プロセスの実行が適切かを確認する
  • SEPG、SQAGは役割:誰もがSEPGとしてSPIできる。 SQAGとしてSQAができる。 → 皆が参加できる。
2.あるある問題(症状)1:プロセスが硬直化して「抜けガラ」に?
  • 症状:プロセスが形だけになってしまう。
  • 原因:「自分たちのプロセス」だと思うことができないから。
    • 「全てを決まったとおりに、やりさえすればよい」ではうまくいかない。自分たちがプロセスの作成に参加しないまま、どこかで決められて、与えられたプロセスだけでは、「自分たちのプロセス」にならないからである。
  • 治療1:「自分たちのプロセス(作戦)」になるよう見直す。
    • 機能に割り当てられた品質要求に対応させて、機能別の設計・評価プロセスを設計する。
      • 既知・既存の機能は、通常のプロセスで開発・改造(開発全体をまとめる)
      • 途中で評価して改良するのが、品質向上に得策な機能は、先行して開発
      • 何度も繰り返し作成・評価するのが、品質向上に得策な機能は、反復開発
  • 治療2:ソフトウェア品質要求仕様のレビューからプロセスを作る・見直す。
  • 品質要求レビューに参加する。
  • 品質要求分析を支援する。
  • 品質課題・リスクを共有する。
  • プロセス(作戦)見直しを相談する。
  • 組織の標準プロセスの適用で注意したい点
  • プロセスの遵守実行方法は、意図・目的・成果を重視して、複数可にする。
  • 選択肢を提供し、取捨選択できるようにする。
  • 変えられるルールを提供、皆でちゃんと見直す。
  • プロセスは「作戦」:プロセスはC(コスト)とD(期間)制約の下で最大限にQ(品質)を作りこむための「作戦」である。
3.あるある問題(症状)2:データを集めてはいるのですが…「モヤモヤ」?
  • 症状:データを集めているが、うまく使えていない、データを取らされている感、がある。
  • 原因:「開発・品質のデータは、最初に開発チームメンバ自身が自分たちで使うもの」だと思うことができないから。
    • 平均値としきい値の比較は要注意:平均値よりバラツキに注目
    • すぐにデータを判断材料として使えるようにする。
  • 散布図、度数分布図などグラフにして過去/他と比較する。
  • 平均値だけでなく、ばらつき、にも着目する。
  • どこから問題点の調査を優先するか、選択する。
  • データを使って攻めない!人を評価しない!
  • 治療1:データは開発チームが自分たちでも使える、が大切である。
  • 治療2:データを「自分」も見て、取捨選択の判断材料にすることで、「自分たちのデータ(判断の根拠)」にする。
  • データは「判断材料」:データは最大限にQ(品質)を作りこむための「判断材料」である。
4.あるある問題(症状)3:どんな効果があるの???
  • 症状:どんな効果があるの???
  • 原因1:日常の仕事では、意識的に効果を感じようとする機会がないと、気が付かないから。
  • 原因2:そもそも「何を今より良くしたいか?」に、組織も開発プロジェクトチームもメンバーも???だから。
  • 治療1:開発チームメンバが自分でよくしたいことへの効果を、身近に考える機会、場を作る!
    • 効果を身近に実感する機会を作る:KPTで「ふりかえり」:プロジェクトメンバがミーティングして各自から提案する。
      • 先ず良かったので続けたいこと(Keep)
      • 次に経験した課題、問題点(Problem)
      • 課題解決のためにやってみたいこと(Try)
  • 治療2:自分たちが開発・保守しているソフトウェアが、システムや、さらに上位/未来のシステムの品質(価値)にどう貢献できる(支えられる)か?の改善ストーリーを持つことで効果を意識!
    • ソフトウェアが、そのシステム、さらに上位のシステムの品質(価値)にどう貢献できる(支えられる)か?:あなたのソフトウェアが搭載されたシステムは、誰かのシステムのサブシステム
    • 自分たちはシステムにつながる、どんなソフトウェア品質課題を改善したいか?:今より良くしたいことを見える化
    • 未来へ準備するために改善!:バックキャスティング:未来の時点で、どんな姿になっていたいかを想い描くことで、今から、その準備を始めると考えると、変えていこう(改善しよう)とする機会や好機を活かし易い
    • 自分たちの改善ストーリーを持つ
      • 上位/未来のシステムへ貢献できる(支えられる)ような、ソフトウェアの品質(価値)のゴールは何か?
      • そのために、開発中に用いるプロセスが、どのような品質(価値)を成果としてアウトプットするとよいか?
    • 改善ストーリーをもつ:身近な効果を感じられるよう日常の目線から、また、何をどう支えたいのかを、全体を鳥瞰する高い目線から見よう。
5.あるある問題(症状)4:モチベーションが上がらない(下がってしまう)!?
  • 症状:モチベーションが上がらない(下がってしまう)。
  • 原因:組織内の「単に一人の作業者」として、指示され、扱われ、評価され、何かあると責められがち、と感じるから。
  • 治療1:互いにリスペクトしている、されていると、感じられることが大切である!
    • 肯定眼でリスペクト(尊重)
      1. 避けたいネガティブな否定的な思考と態度
        1. そんなやり方ではダメダメだ(頭からダメ出し)。
        2. ○○さんが原因じゃないの?(人を責める)
        3. モデルの通りにしないと何も対策が進みません。
        4. 絶対に○○にならなくては、いけない。
  • 治療2:自らの気づき、自発的な提案を促すよう、ファシリテーション(例えばツールや手法の施行・自動化を援助)
    • プロセス改善のファシリテータとして振る舞う:心理的安全な組織文化へ
      1. 相談、傾聴、気づきを促す。
      2. 雰囲気、場、機会を作る。
      3. なぜそのプロセスなのか、を伝え、共に考える。
  • 治療3:プロセスを改善していくことで、自分の能力を開発し、発揮するチャンスが増えることを伝える。
  • あなたはファシリテータ:ソフトウェアプロセス(SPI)改善活動は、ファシリテーション、SEPG&SQAGはファシリテータ
6.おわりに
  • これからのプロセス改善と品質は?:これからもプロセスで人と技術を結び付ける。
  • 誰もがプロセス改善!
    • ソフトウェアのプロセスもソフトウェア(オスターワイル教授)
    • ソフトウェアを作るとき、そのプロセスも設計して実行し、見直して改良!
    • さらに、皆さんが開発しているソフトウェア、システム、サービスも顧客やユーザーの仕事や生活のプロセスの改善・変更・革新を提案し実現しようとするもの!

質疑応答

Q1.プロセス改善の効果の確認はどのようにしていくのがよいか?モニタリングの工夫は?

A1.身近に何が改善効果かを考えることが必要。軽くすることで何がよくなるのか、レビューは軽くしたいが、どうしても見つけたいものは何か、を考えて改善をする。プロセス改善だけの話ではないが、変えたことでの効果を1対1でピタリと当てはまることはない。効果は何年もかかることもある。あまりデータ、データしない方がよい。きっかけは意思である。

戻る

第8回特別講義 レポート
日時 2020年1月10日(金)10:00 ~ 12:00
会場 (一財)日本科学技術連盟・東高円寺ビル 地下1階講堂
テーマ ソフトウェア疲労をアーキテクチャ設計で改善する
講師名・所属 山田 大介 氏(ビースラッシュ株式会社 代表取締役)
司会 岩井 慎一 氏(株式会社デンソー/本研究会 ソフトウェア品質保証の基礎 主査)
アジェンダ
  1. ソフトウェア開発の状況
  2. ソフトウェア疲労
  3. アーキテクチャ設計と設計技法の違い
  4. アーキテクチャ設計
  5. アーキテクトの役割とスキル
  6. 三階建て設計改善
  7. まとめ
アブストラクト

IoT時代のソフトウェア開発は複雑さへの対応と素早い出荷の両立を求められています。開発現場では、動いているプログラムを使い続けることで、資産価値は低下し在庫化しつつあります。それらを解決するためにアーキテクチャ設計が有効です。アーキテクチャ設計では、複数のビューでモデル化を行い、設計意図を伝達します。今回は、アーキテクチャ設計の要点とそれを推進するアーキテクトの育成について紹介します。

講義の要約

講師紹介

山田 大介 氏
1990年~ 構造化技法/オブジェクト指向分析設計
1998年~ ソフトウェア部品化再利用/ドメインエンジニアリング
2003年~ プロダクトライン開発/リファクタリング
2007年~ アーキテクチャ設計/アーキテクト育成


1.ソフトウェア開発の状況

●デジタル化を起点として、組み込みソフトウェアの規模が増大。

●マネジメントとしては、プロセスやプロマネを強化する方向へ

  • 「エンジニアリングなきマネジメント強化」は悪循環を招くことも

●近年、ネットワークに接続する製品の開発が増加 → IoTでは製品を取り巻く周辺の状況変化が発生している。

●ソフトウェアの資産価値が在庫化している?

  • 在庫: ソースコードは複雑で説明困難。信頼できるドキュメントは存在しない。保守コストが膨れていく
  • 属人資産: ソースコードはシンプル。設計ドキュメントがそろっていない。個人主導の開発
  • 半組織資産: ソースコードは複雑。設計ドキュメントはそろっている。マネジメント主導の開発
  • 組織資産: ソースコードがシンプル。設計ドキュメントは整備されている。予測可能な開発
  • 戦略資産: ソースコードと設計ドキュメントが統合。戦略的な資産活用ができる

●ソースコードの変更と改善のジレンマ

  • 機能追加・削除: 局所的な機能追加で当初の設計意図が埋没してしまう。
  • 障害対策: 局所的な修正の積み重ねでスパゲッティ化に陥る
  • 性能最適化: 設計構造を崩すことも。
  • 再利用資産化: 機種ごとのコンパイルスイッチはアドホックに追加
    →「ソフトウェア疲労」が発生している → 抑制には設計改善による「可視化&洗練化」が必要

2.ソフトウェア疲労

ソフトウェア疲労【静的】

  1. 一筆書き: 一つの巻子やファイルが長い。作った人にしかわからない
  2. クローン: 同じコード断片が点在。修正漏れが発生する。grep検索が最も便利な開発ツール
  3. 神様データ: 全てを支配しているデータが存在する。修正の波及範囲が大きい。
  4. 中央集権: 一つのファイルにたくさんの関数がある。いつも同じファイルを修正している
  5. スパゲッティ: いろいろな関数を呼び出している。副作用が発生する。
  6. 老舗温泉旅館: 階層を超えた呼び出し/命名規則がない。引継ぎができない
  7. 一枚岩: #includeしているファイルが多い。分割コンパイルができない

⇒想定原因

  • 1, 2: そもそも設計していない
  • 3~5: 設計技法を使いこなしていない
  • 6, 7: 全体を見ていない。アーキテクト不在

●構造設計の基本

  • 一筆書きは設計ではない。フローチャート/コーリングシーケンスはモジュール化はできているが、レベル化ができておらず、これも設計ではない
  • 構造設計には箱(Whatの名称)、線(利用関係)、配置(水平垂直分割)が必要である。

●設計品質の原則: 凝集度

  • 機能的、逐次的、通信的はOK。手順的、一時的、論理的、偶発的はNGである。


ソフトウェア疲労【動的】

  1. 末広がり: 処理の起点からフラグ判断を積み重ねて動く。変更は、流れを追いかけないとできない。
  2. 裏取引: 後からアドホックに追加されたフラグ変数が多い。改修時に思わぬ副作用が出てしまう
  3. 状態迷路: 状態数やイベント数が20を超えている。状態やイベントを追加削除することが大変
  4. 途中で待つ: ボタン操作が効かない。イベントの順番が変わると動かなくなる。
  5. データ競合: セマフォでデッドロック。スレッドセーフの連続でパフォーマンス遅延
  6. タスク過多: タスクの数が意味もなく多い。サイクリック実行型ではループの増殖
  7. 凸凹API: IFプロトコルが煩雑。IFの順序が分かると動かなくなる

⇒想定原因

  • 1, 2: そもそも設計していない
  • 3~5: 設計技法を使いこなしていない
  • 6, 7: 全体を見ていない。アーキテクト不在

●制御仕様をそのままプログラミングすると「末広がり」になってしまう。コードレベルで改善しても、他の例にあてはめられない。構造化すれば設計図で説明できるようになる

●プログラミングスタイルの違い: アセンブラ的Cからモジュール的Cへと変わってきており、動解析ファーストではなく、静解析ファーストへと移ってきている

3.アーキテクチャ設計と設計技法の違い

●多面化と詳細化
アーキテクト: 多面的に図面化し設計意図を伝達する
設計担当者: 設計を詳細化しプログラミングを行う

●アーキテクチャ設計とコンポーネント設計

  • アーキテクチャ設計は、構造と意図を明確にして人に伝える
    • 重要な部分から明確にしていく
    • 未記述部分(TBD)があってもよい
  • コンポーネント設計は、ソースコードに直結する設計
    • 設計書を最新に保つコツは、設計とコードを同期させること

●そもそも「設計」とは?

  1. 実装する前に: 要求分析: 要求を正しく理解し、設計することで、手戻りをなくす
  2. 全体像を明らかにして: 静的構造: 全体を構造的に俯瞰することで、適用範囲を明確にする
  3. 問題点を検討し: 動的構造: 構造要素と要素間の問題を、あらかじめ検討する。わからないことを明確にする。
  4. 複数の関係者の認識を合わせる: 文書化: 設計意図を伝達し、開発の方向性を合わせる

●設計図とは

  • 静的構造図と動的構造図の両方が必要
  • 全体を俯瞰できる粒度で静的構造を表現する

●「設計力」= 分離 + 構造化 + 図解。設計力があれば、いろいろな設計図を読み書きすることができる。そして、次第にいろいろな手法を使いこなすことができるようになる

4.アーキテクチャ設計

●組込みシステムの5つのビュー: 静的構造を中心に、動的構造と実装構造を設計

  • 目論見: 製品の特徴や売り
  • 設計方針: 目論見を実現するための設計方針
  • 静的構造: 責務や機能の単位
  • 動的構造: 並行動作するタスク要素、タスクや割込みという実行要素単位
  • 実装構造: ファイルの構成単位、設計規約

●動的ビューと静的ビュー

  • システムを複数の視点(ビュー)でとらえる。複数視点の図面を統合化することで方式設計する

●各ビュー間の関係

  • 目論見を実現するための設計方針
  • 目論見、設計方針を具現化する静的構造
  • 静的構造を下敷きにして、動的構造/実装構造を記述
5.アーキテクトの役割とスキル

●アーキテクトの役割

  • 正しく判断し、プロジェクトを成功に導く
  • 技術支店のリーダーシップを発揮する人

●アーキテクトの基本スキル

  • 複数のビューポイントで対象を図表化する
  • 複数の図表を統合して一冊の空きてくちゃドキュメントにする
  • 様々なステークホルダを巻き込んで、リーダシップを発揮する
    • プロマネは売上増大、アーキテクトは利益率向上に貢献する

●システムズ・アーキテクト

  • システムズ・アーキテクトに求められること: アーキテクトが経営とテクノロジをつなぐ
    1. 異ドメインの接続: ヘテロジニアスな全体像をつかむ
    2. ビジネスへの補助線: コンセプトやバリューを考える
    3. 本質を見抜くスキル: 抽象化できる人材の育成

●IoTシステム開発を成功に導く要素

  • ビジネス価値のプロト開発(PoC)から、素早くゴールに到達(アジャイル)し、運用までを考慮(DevOps)することで、ビジネスを成功に導く
    • これを支えるのが、システムズ・アーキテクト
      • 必用となるスキル: 仮説検証スキル、統合スキル、解析スキル、抽象化スキル、モジュール化スキル
6.三階建て設計改善

●ソフトウェア疲労の再発防止

  • 開発プロセスに設計エンジニアリングを組み込む

●三階建て設計改善

  • ソースコードを直接修正するのではなく、設計図上で原因を特定し、アーキテクチャの方針に従って、設計図を修正し、ソースコードを回収する。

●アーキテクチャ設計原則

  1. モジュール化: モジュール(変数/関数/ファイル/フォルダ)の識別性。Whatの名称であり、内部にデータを隠蔽している。
  2. 高凝集: モジュールが単一目的を持っている。まとまりのあるデータ群を持っている。
  3. 疎結合: グローバル結合していない。一覧できるスコープを超えない。
  4. レベル化: BOSSを作り、指示<->報告の上下関係を作る。上位がクライアント、下位がサーバの利用関係。
  5. 水平分割: 上位が論理、絵画物理。データの受け渡しは、求心/遠心で。
  6. 垂直分割: 基本系列と横断的関心及び異ドメインを分離する。横断的関心としては初期化やエラー処理。異ドメインはUIなど
  7. 静動分離: 周期起動部(動的)と機能実現部(静的)に分ける。制御スレッドは走りきる。フィードバック処理の最小化
  8. 状態連動: 複数の状態が連動して動く。ひとつの状態遷移は状態数を7個以内にする
  9. 固定変動(資産化): 共通部分のライブラリ化やフレームワーク化。変動部分の特定とアーキテクチャ上へのマッピング
7.まとめ

●エンジニアリングで全体を俯瞰: エンジニアリングすることで現状打破。図面化と設計の原則原理

●在庫から脱却し、戦略資産へ: 資産価値を向上させる

●ソフトウェア疲労【静的】/【動的】を改善する

●アーキテクトが「丸投げ」をつなぐ

  • まずは「コードに近い設計」、最終的に「アーキテクチャで繋ぐ」

●ソフトウェアの資産化アプローチ

  • 既存資産を起点として戦略的な開発の実現へ
    • ボトムアップ: 既存コードを部品化して、洗練化・資産化していく
    • トップダウン: 設計意図を明確にして、ソースコードへ反映していく

●悩むエンジニアから、考えるエンジニアへ: コード中心から設計中心へ


<質疑応答>

Q1: アーキテクチャの大切さはわかるが、マネジメント層にどう伝えるとよいか?例えば、ソフトウェア疲労を防ぐためにリファクタリングをするための工数をどう得るのがよいか
A1: 在庫という言葉を使うことでマネジメント層に伝えると理解できる人が多い。構造を図で見せるのもよい。中間マネジメントが阻止することも多いので注意が必要。

****************

Q: 組み込みで今後、海外のOEMを相手にする場合、アセスメントでビジネスチャンスを逃すことが多い。ドイツのドキュメントの差は?
A: ドイツではリファレンスモデルが当たり前。トップダウン流のリファレンスモデルをまじめに作るしかない。ドイツはかなり厳密に作っている。

****************

Q: リファクタリングはいつ挟むのがよいのか?
A: リファクタリング目的のリファクタリングはしない。修正、移植の目的のために前段階でリファクタリングするのがよい。

  1. 修正のタイミングでリファクタリングする。リファクタリングをしてから、修正する。
  2. 移植のタイミングでリファクタリングする。

戻る

研究会
ソフトウェア品質管理研究会
ソフトウェア品質知識体系ガイド
ソフトウェア品質シンポジウム
ソフトウェア品質保証部長の会 10周年記念サイト
 
 
日本科学技術連盟

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

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