＜講義の要約＞

◆1章 ソフトウェア開発に

■ソフトウェア開発の課題
SQuBOKおける制約と品質にあるように『品質は経営層から現場に至るすべてのレイヤの体系化されたアクティビティにより追及すべきもの（経営層と現場が一緒になってやらなければうまくいかないもの）』である。しかしながら、昨今のソフトウェア開発事情は、経営層は品質を必須の条件と考えているが、現場は破ると見えやすい条件（納期）を強く意識している。要因は、コスト・納期は達成しなければならない数値が明示されていて、調整ができるが、品質は達成しなければならない数値が明示されず、調整もきかないことにある。品質を守りながら、コスト・納期も守るという制約条件で開発を進めるのであれば、品質を明確にならない限り、コスト・納期と同様にトレードオフすることはできない。したがって、品質向上策に取り組むためには、達成する“品質”は何か、単位を何にするのか、目標値をいくつにするかということが課題となる。

■達成する“品質”は何か、単位を何にするのか、目標値をいくつにするのか
SQuBOKのWeinbergの言葉にあるように、『品質は誰かにとっての価値である』例えば、ソフトウェアを1日8時間利用するユーザにとっては使い勝手のよさが高品質であるし、故障のたびに批判されるシステム管理者にとっては、ゼロ故障が高品質である。厳しい予算の制約下にあるプロジェクト管理者にとっては開発費用が少ないことが高品質である。したがって、『品質とは障害（機能単位の能力の縮退または喪失を引き起こす異常な状態）がないこと』と一意に定義できるものではない。

『品質とは障害がないこと』とした場合、障害の少なさを単位当たりの量で把握する。≪単位≫はコード行数やファンクションポイント、≪量≫は開発の工程（プロセス）ごとに検出された障害数を利用する。

世の中の平均、自社の実力、顧客の要求から品質の目標値を決める。例えば、「1ヶ月後までに300万円で要求事項を実現してほしい」という顧客の要求に対し、「割り当てられるリソースは4～5人なので、品質レベルは“B”で請け負う（品質レベル“B”とは・・・）」と定義して納期とコストを守る。

SQuBOKのMartinの言葉にあるように、品質の達成度は『システムが本稼働するとき、どこまで真のビジネス（ユーザ）ニーズにあっているかということ』である。そのためには、進化し続けるシステムを構築すること、時間とともに変化する顧客の要求を的確に把握し、その変化に可能な限り応えることが重要である。また、開発のスピードを上げながら、ユーザのニーズとの不一致を極力少なくする努力が必要である。したがって、品質は、何を達成しようとしているのか、状況に合わせて定義するものである。

◆2章 ソフトウェア品質向上の道筋
高品質とは“障害が少ないこと”と定義する。高品質を達成するための道筋は、ゴール設定、アプローチ検討、施策実施と結果確認である。単純ではあるが、どのように当てはめるのかはポイントがある。

■ゴール設定
ゴール設定には三つのポイントがある。
一つ目は、課題を設定し目的にあったゴールを設定することである。
二つ目は、「品質活動に関係者を巻き込む」ことである。そのためには、価値観を共有すること、もしくは、危機感を高めることが挙げられる。価値観を共有することは難しいが、危機感を高めることはできる。危機感を持った人が半数を超えていれば、品質活動は進めやすい。
三つ目は、みなが合意する問題を定義することである。ひとつの方法としてソフトウェア製品の不具合分析がある。
ソフトウェア製品の不具合分析を活用するためには、不具合情報が記録として残されていることが前提条件となる。その上で、不具合が発生している要因の仮説を立て、不具合情報を分析すれば、みなが合意する問題を見つけることができる。
例えば、弱い工程を探すのであれば、作り込んだ工程と発見すべき工程の統計を取る。スキル不足を探すのであれば、スキルのカテゴリ（個人、ベテラン、新人など）を設定して分類する。リスクの高い機能を探すのであれば、機能ごとに統計値を比較する。

■アプローチの検討
組織の特徴をSWOTに当てはめ、マネージメントコントロールフレームワークを活用して、期待されるように振舞いたくない原因を明らかにし、適合するアプローチでコントロールを決める。

○SWOTとは

強み（Strength）、弱み（Weakness）、機会（Opportunity）、脅威（Threat）の４つの要因を軸に事業の評価や目標達成のための戦略を練るツールである。

○マネージメントコントロールフレームワークとは

マネージメントコントロールフレームワークとは期待されるように振舞いたくない原因を明らかにし、適合するアプローチでコントロールする手法で、原因とアプローチには以下のものがある。
≪原因≫
(a)Lack of Direction：期待されることがわからない
(b)Personal Limitation：期待されていることを知っていてもそれに応えるスキルがない
(c)Lack of Motivation：期待されていることを知っていてスキルもあるのに、取り組まない
≪アプローチ≫
(1)Action Control：具体的な行動を示し、行動を促す
(2)Result Control：望ましい成果には報酬を与え、望ましくない成果には罰を与える
(3)People Control：人の性格や特性に働きかけ、行動を促す

■施策実施と結果確認
施策実施のために、施策推進体制を整え、関係者にオリエンテーションを実施する。施策実施の過程は（フィードバックできるように）記録する。また施策実施の効果を何にするか、どう測るかを決め、計測を実施する。結果確認は、関係者間で振り返りを行い、結果を共有する。

ソフトウェア品質向上策：事例1
＜機能仕様とテスト仕様の同時設計による見逃し防止＞　≪Lack of Motivation - Action Control≫

○動機
テスト工程が終わらず開発遅延する傾向が顕著になっていた。工程ごとのメトリクス（リソース／期間／不具合数など）を分析すると、手戻り作業が多発しテスト工程が終わらないことがわかった。

○要因
品質計画書（設計者が行う不良再発防止策とその実施工程を宣言した文書）による振り返りから、設計者の意識はテスト工程を見直すこと（テスト項目を追加すること）であった。
テスト項目が不足してしまった現状・背景は、仕様書に記述があるのに、対応するテスト項目がない。仕様書の記述が不備なため、テスト項目が抜けた。仕様変更による影響範囲を把握しきれず、テスト項目が不十分ということであった。
テスト品質に影響を与える要因は、開発リソース（ソフト規模増大によるアウトソーシング：仕様の誤解釈、翻訳誤り）、ソフトウェア開発プロセス（Vモデルに基づく設計：機能設計とテスト設計が時間的・人的に分離）、異なるドキュメントフォーマット（機能仕様とテスト仕様が別：レビュー時間がかかる／十分性・網羅性を確認しきれない）、ソフトウェア機能の複雑化（テスト項目が増大、トレーサビリティマトリクスの保守が困難）であった。

○解決策
機能設計とテスト設計が分離した開発スタイルを見直す。
設計者がテスト設計に責任を持ち、必要十分なテスト項目の設計／テスト数を考慮した設計／テスト可能な設計を実施する。
そのために、既存の開発プロセス（コーディング後のテスト工程でテスト設計を実施）するやり方を設計者がテスト設計にも責任を持つプロセス（上流設計段階でテスト設計も並行して実施）するやり方に変更する。また、上流工程でのテスト設計を支援するツール（機能仕様を書きながらテスト仕様を書くツール）を準備する。

○効果
QAへの持ち越し不良が軽減した。同時に、どのようにテストするか／テスト可能性を設計時から考慮するようになり、正確なテスト設計には明確な機能仕様が必須であると気付き、機能仕様書の品質が向上した。また、機能とテストの対応づけが不要となり、設計レビューでQA担当者からの指摘が増加し、レビューの品質も向上した。

○成功の秘訣
問題の要因を動的要因まで掘り下げたこと。機会を活用したこと（オフショア開発に適用）。組織的なアプローチを実施したこと。

ソフトウェア品質向上策：事例2
＜ドメイン知識の共有による組織的開発力強化＞　≪Personal Limitation - People Control≫

○動機
短期開発、安全性の欲求、他者との競合など外部要因の変化により、ソフトウェア開発環境は小数精鋭チームから他人数多様化したチームへと変化し、未経験領域のソフトウェア開発が実施されるようになった。
このような状況の中、あるシリーズ製品の過去の不具合を分類したところ、ドメイン知識に関する欠陥が約半数を占めていた。

○課題
ドメイン知識は個人の経験を通して個人の中に蓄積されていく。そのため、ドメイン知識を必要とする人は何を必要としているのかをうまく示せない。また、ドメイン知識を所有している人は、自らそれを表出できない。
ソフトウェアエンジニアに必要なドメイン知識は、対象分野を理解するための知識（顧客のビジネス、装置を導入する目的、顧客の業務フロー、法や規約改正などの社会的背景）、品質の良いソフトウェアの開発のための知識（要求や仕様の変遷、ハードウェア技術に関する背景、ソフトウェア技術に関する背景）である。今までは、これらの情報をOJTによって引き継いできたが、外部要因の変化によりOJTで引き継いでいくことが難しくなった。

○解決策
□ドメイン知識の共有
ソフトウェアエンジニア自身が実践できるように設計、チーム体制をとって、既存のドキュメントを利用した知識のフレームワークを構築、質問票を利用したインタビュー形式で知識を抽出する。
抽出したドメイン知識は、独学できるように解説書（文書）とドメインモデル図（関連図）で表現する。
□ドメイン知識の抽出手順
抽出する知識を定義→情報収集→収集した情報を整理し確認事項のリストを作成→専門家から質問票を用いて知識を抽出
□ドメイン知識の表現方法
抽出されたドメイン知識はソフトウェアエンジニアの限定された知識を補うために利用する。新規参入者がいつでも一人で学習できること、ドメイン知識の全体像とサブドメイン間の関係を把握できることを実現するため、解説書はユーザの視点で説明する（ソフトウェアの目的を説明する。設計根拠となる背景を述べる）。

○ドメイン知識の抽出と表現の実施
部長によるトップダウン、チームがドメイン知識の抽出・記述を実施、サポートチームがドメイン知識抽出のプロセスを支援した。

○ドメイン知識の共有（活用）・効果
ソフトウェアエンジニアリングの導入教育に活用したり、アクセスし易い場所に解説書を格納し各自の自習に活用したりしている。
また、既存の欠陥を使用した机上シミュレーション（今回抽出したドメイン知識を習得していれば、どれだけの欠陥を防げたかをシミュレーション）した結果、18事例のうち16事例を防止できることがわかった。

○成功の秘訣
機会（担当者がいなくなった危機間、知りたいという欲求）を活用したこと。過去の失敗の経験から、ノウハウをチームの成果物としたこと。組織的なアプローチを実施したこと。

◆3章 ソフトウェア品質技術の心得

■ソフトウェア品質技術者とは
以下のような人をソフトウェア品質技術者と呼んでいる。
・ソフトウェア品質向上に関する知識を、包括的かつ体系的に身に付けている人
・ソフトウェアの品質向上に対する効果的な策を、継続的に実施している人
・該当するキャリアが以下の人
品質保証スタッフ、開発者、テスト技術者、
プロジェクトリーダ・マネージャー、保守運用技術者、教育担当者、経営者
品質重視の組織文化を作るためにはソフトウェア品質技術者ひとりひとりの認識が必要で、ソフトウェア品質技術者は、品質重視の組織文化を作る種の役割がある。

■研究会は練習の場
研究会はソフトウェア品質技術者になるための練習の場である。「練習」は自らが繰り返したり、工夫したりして技術の向上をはかることである。研究会は調べる／考える／議論する／整理することを練習する場である。特別講義／指導陣の経験／研究員から世の中を知り、研究員同士のケーススタディから問題を把握する力がつき、それらを論文にすることで、成果を外へ発信できるようになる。

■論文とは
論文は論理的かつ分かりやすく整理した文書、外向けの文書である。論文の評価の観点には、有用性／信頼性／新規性／構成力がある。これらのうち、新規性は、全ての知恵と知識は先哲の業績の上に成り立っている。自分達の問題領域で、千哲たちのやってきたことに乗りながら、その上の新しい試みを見つければよい。

◆質疑応答
Q:成功にとらわれずに、みなに認められたことを壊して次に進められる（例えば、機能仕様とテスト仕様の同時設計による見逃し防止では、オフショア先にやらせるように変えていく）のは、何か秘訣があるのか？
A:壊したのではなく、壊れてしまった。続けていくうちに、テスト仕様は書けるようになったが、モチベーションを保つことが難しくなった。また、テスト仕様まで考えた機能仕様書をオフショア先に渡した場合に相手が同じように理解しているかということが不安になってきた。そこで、それをどのように変化させればよいかを考え、相手にやらせれば一石二鳥になるという結論になった。このように、継続要否は柔軟に考えることが重要であると考える。

Q:オリエンテーションに感銘した。このステップは飛ばし、知識レベルが異なるまま進めているが、担当者によって違う反応が返ってくることになり困っている。何かよい方法はないか？
A:特別なことはないが、オリエンテーションは、メンバーに意図を伝え、やってほしいことを理解してもらう場であると考える（なぜそれをやらなければならないかをメンバーで共有することが重要である）。

Q:ドメイン知識の共有による組織的開発力強化は、だれかが責任を持ってメンテナンスしていくことが必要であると思うが、それをどのようにしているか教えてほしい。
A:メンテナンスをしていくことは重要である。メンテナンスは決まった担当者に任せるとモチベーションが下がるので、前回の受講者を次回の講師とする事で自身の知識も振り返る事ができるようにしている。結果としてうまくいっている。

＜講義の感想＞
ソフトウェア品質向上の道筋を立てるコツとして、みなが納得する事実（過去不具合）を分析し、その結果を活用して組織長と現場に危機感を煽ることで、みなが同じ目的意識を持って行動できるようにしていく手順をご教授頂き、そのエレガントさに感銘しました。自社においては、組織長と現場の認識が異なることで、品質活動が思ったように進まないことに悩んでいましたが、組織長と現場の認識を一致させることが何よりの解決策であると認識できました。まずは自社の過去不具合分析から、みなが納得する事実を見つけ出し、組織長と現場の認識を合わせていきたいと思います。

＜講義の要約＞

◆今事業に求められるもの
これからの事業運営に最も求められるのは「スピード感」である。この命題に答えるためには、間接的な業務を最小限に抑える事が必要だが、実際はなぜなぜ分析に多くの時間をかけている現実があり、かつ問題の混入工程から以降の工程での分析では、例え対策を打てたとしてもそれまでに無駄なコストと時間を使い切っているわけであり本末転倒である。その対策として取り組んでいる内容を以下に示す。

◆なぜなぜ（なぜ３）の種類と目的
１）品質保証型なぜなぜ（プロセス実行型なぜなぜ）
開発プロセス実行中におけるインシデント発生時にリアルタイムで実施するなぜなぜであり、数値分析を併用する事により、品質改善は元よりコストカットも可能とする。これがNECグループにて展開中の取り組みである。

２）振り返り型なぜなぜ（プロジェクト振り返り型なぜなぜ）
従来の一般的な取り組みであり、失敗プロジェクト等の大きな課題に対して要因分析と対策を検討するものである。振り返り型なぜなぜは、組織の問題の掘り下げや事実確認を目的として反省会形式で風土創りや教育のために行われる。そのため、個々のインシデントに対して行うと過去の現場作業の振り返りとなり、無駄な作業を招く。

◆基本的な品質管理について
本講演の具体的内容に触れる前に、一般的な品質管理方法を確認しておく。

１）品質管理とは
 品質管理には「プロダクト品質の管理」と「プロセス品質の管理」があり、前者は結果の確認であり、重要なのは後者の手段としての開発手順の品質を管理する事により品質を保証することである。この手順重視の考え方が重要である。

２）一般的な品質保証の方法
一般的な品質保証の方法には「静的品質分析」と「動的品質分析」がある。
静的品質分析とは、ソフトウェアメトリクスによる定性的分析と指標との比較分析により工程終了判断に用いるものである。そもそも、指標の設定根拠自体が過去版の実績値に基づくものであるため、分析対象のプロジェクトに対し人的要素を考えた場合は曖昧であり、ある意味理想論である。
動的品質分析とは、障害発生数の収束状況を時系列的にグラフ化し、残障害数必要な試験件数等を予測するものである。信頼度成長曲線等を用いるが、そもそも試験項目内容により故障発生率が異なる事から、分析においては各試験実施時期の考慮が必要となる。

◆従来の品質管理手法の課題
ここまで述べたように、様々な分析理論はあるが、現実にはその理論通りには行かないのが実態である。
その理由として、前述した理論はハードウェアの開発における品質管理理論から来ているものであり、開発において人間の関与が大きなソフトウェア開発においては、これらの理論だけでは品質保証が難しいからである。

１）数値分析の課題
数値分析においては、工程判断基準値からの乖離を問題視するが、一方、乖離していない場合でも問題が潜在している場合がある。この分析理論においては、開発プロセス自体がきちんとやられている事が条件であり、「手抜き」「さぼり」等により作業プロセスに異常がある場合には意味を持たない。
さらに、一番品質に影響する「開発機能の難易度」「開発方式」「スキル」という要素は数値化が難しいジレンマがある。
また一般的に、開発規模とバグ摘出数は一次関数のグラフで表されるが、開発者のスキルを考慮した場合、特異値を分ける必要もある。つまり「だれが作ったか」が重要であり単純な式では表現できない。

２）バグ件数成長モデル（グラフ）の課題
グラフィカルで見やすいため関連者への説明に使われることが多いが、実は条件がむずかしい。各テスト項目の１件１件の内容が等価であることが大前提である。また、単体テストのように、次々と別の機能を試験する場合には収束はありえない。総テスト件数が少ないと試験対象によるぶれの影響が大きくなるため、試験目的を分けた試験は収束に意味を持たない。収束は視覚的な感覚なので、縦軸を縮小しただけでも見誤る場合がある。

◆ミッションクリティカルシステムでの考慮点
ここまで述べた課題事項を基に、ミッションクリティカルなシステムの開発における考慮点を整理する。
１）体制として多くの人間で開発すること。
事例としては大規模プロジェクトだが小さなプロジェクトでも同じであり、「仕事を軽くして品質を向上させる」事が目標である。
手段として、全員が「やるべき事をサボらないようにする」必要がある。そのためには、「担当者の手順
にできない事を入れさせない」事が重要である。
その確認として「きちんとやったかをチェックできる仕組み」が必須である。これを実現するためには、随時できなかった場合のポイントを分析して、できる手順に改善するという地道な取り組みが必要である。精神論でやらせるのではなく、個々の人としてできる手順に落とし込む事が重要である。

２）今まで経験の無い高品質の開発を行うこと。
今後の日本のソフトウェア開発の担うポジションは「超短期開発」「超高品質開発」である。その他はオフショアに出さざるを得ない。
この達成には、一般的には高いレベルのプロセス標準が必要と考えるが、経験の無い環境、目標に対し最初から標準を用意する事は不可能である。そのため、とにかくプロダクトを早く動かして確認しチューニングする事とし、全体を止めないという手段が良い。例として、NECが開発した惑星探査機「はやぶさ」は、未知の宇宙において想定外の事が起きても手直しを可能とする補助エンジンを搭載する事で補正により目標を達成した。

３）利益を出してビジネスとして成り立つこと。
この命題達成には後戻り工数を減らす事が最重要である。大規模開発でかつ短期開発の場合、手戻りが発生してからではビジネスそのものが成り立たなくなる。再レビューにより現場開発者は元より、運営の間接工数の増加は一番の無駄である。

◆対策としての「プロセスベースの品質保証」の適用
以上の考慮すべきポイントに対し対策を以下に述べる。
１）プロセスベースの品質保証
以下の取り組みを最上流工程から継続実施する事が大事である。問題発生時には、プロセス上の課題を追求し発生した当該工程の中で横展開までを完了する。そのためには、非常に短期間の分析とアクションが必要である。

２）なぜなぜ分析時の注意事項
必ず混入工程を意識し、例え次工程以降に持ち越したバグでも作りこみ工程へ立ち返り分析が必要である。作り込み工程が明確になったら、その工程の問題を招いたプロセスを明確にする。この場合作り込み担当者本人にヒヤリングする事が必須である。プロセス上の真の原因が明確になれば、それを裏返しプロセスの改善と横展開を行う。

３）うっかりミスの扱い
人間の作業にはうっかりミスもある。この場合数値分析により、多発ではなくかつ特定の人や機能に集中していない場合は次工程での様子見とする。うっかりミスに対してもプロセス改善をやろうとするとプロセスが動かなくなるため、「うっかりミスかどうかの見極め」が重要である。

４）なぜ３ができる条件
・やるべき事から何が外れているかを追求することであり、これが明確でないとなぜなぜはできない。これを明確にするには担当者の目線に合わせる事が重要であり、目線合わせができない管理者には、正しいなぜなぜを実施できないのである。
・誤ったなぜなぜ、つまり、現象ベースのまま対策を実施する事は大きな無駄を招く。正しいなぜなぜにより、ピンポイントでの対策が実施でき最小の工数で対策が可能となる。

５）なぜ３のコツ
・正しい原因追求があって始めて対策が決まる。つまり、正しい原因追求ができる人がいる事が重要となる。よって重大な問題が発生時には自ら現場に出向きなぜなぜを実施している。
・なぜなぜの回数は多いほうが良いと言われるが、原因を裏返してピンポイントの対策になれば回数は関係ない。
・事後だからわかる事ではなく、事前に防げる対策でないと意味が無い。
・なぜなぜにおいて上司の意見に押し切られる場合が多いが、現場目線になれず無駄な対策になる場合が多い。
・本質の問題と偶然見つけた問題を分ける事が重要である。本来のなぜなぜができるのは一つの問題についてである。よって、二次的に派生した問題は別途整理して対策を打つ事が重要である。
・先入観を捨ててヒヤリングする事が重要であり、過去の経験とか常識論から誘導しそうな立場の人はヒヤリングを実施すべきではない。

◆プロセスカイゼンの考え方
・なぜなぜをやるほど、仕事が楽になり生産性も上がるようにするには、安易にチェック項目を増やすのではなく、チェックを如何に簡単にさせるかを重視した対策にすることが重要である。また、問題を作り込まないことをも重視した対策にすることも重要である。
・標準やルールを事細かく規定してしまう事が多いが担当者の稼動を増やす事となり逆効果である。担当者が如何に必要な要所を押さえられるかが重要であり、そのためには担当者の立場を理解することが重要である。
・一つ一つの改善は妥当な内容でも、積み重なると重くなる。結果として担当者がサボる原因になる。よって、ほとんどの担当者が守れる「単純」「簡単」なプロセスとすることが重要である。
・全ての担当者が守れる事を目的に底下げする事は本来ではない。ほとんどの人ができるレベルとし、それに満たない人は個別に指導するのが良い。
・カイゼンとは、目的を理解しやり方を変える事である。カイゼン内容は具体的でやさしい言葉で表現し、相手に目的や価値を理解してもらうことが大事である。
・カイゼンはタイミングが重要であり、一部で試行してみて随時チューニングしていくことも良い。

◆忙しい人を更に忙しくするジレンマ
・なぜなぜの原因追求結果で「工数が無い」は相応しくない。こういう人にいくら時間をあげても別のことをするので無駄である。「工数が無い」から「何をサボったのか」がプロセスの原因であり、工数が無いのが原因ではないからである。
・元々の作業が溢れていている状態で発生した問題のカイゼン策として新たに作業を追加することは、新たにサボるものを増やすこととなり悪循環を招く。対策は今の仕事をカットするかトレードオフしないと解決に結びつかない。

◆有識者の苦悩
「次回は有識者を入れてレビュー実施」という対策は無くすべきである。有識者とは業務や技術に長けた人ではなく、過去に一人で泥をかぶり苦労して何かを少しだけ掴んだ人である。つまり、本来ではない事を記載して責任を擦り合うばかりであり価値が無い。

◆良いチェックシートとは
セルフチェックにおいて失敗事例として「やってはいけないこと」をA４一枚で記載する。多くの過去事例は羅列しない。これであれば曖昧な回答は無くYES/NOで回答できる。セルフチェックをサボった要因、セルフチェックを行う際に根拠資料を確認していなかった理由、改造の場合は変更箇所しかチェックしなかった理由を明記しチェックさせる。つまり、過去事象ではなく過去の混入要因を挙げる事がポイントである。

◆なぜ３の適用範囲
なぜ3はソフトウェア開発以外でも使える。例えば、進捗管理では、通常頁数の出来高で管理するが、その場合仕様追加変更等で母数が変われば意味が無い。よって課題管理が重要である。残課題数、残課題内容の重要度の把握が大事だしこれを管理する事が進捗管理である。

◆現実のスピード感を考慮しての対策制御
品質保証をするには分析工数がかかる事は当然である。しかしながら、これと「面倒くさい」ということは別である。現実のプロジェクトではスピード感が必要であるし、そのためには理想論による対策は不要である。今できてない事を全て把握した上でそれら全てを短期間で実施するのは困難である。よって、「今からベストなことをやって品質を保証できる自信がある事だけをやる。」その上で、更に問題が出た場合には原因の分析有りきでピンポイントで対策を打つ。

◆大局観によるカイゼンの重要性
カイゼンを要するプロセスの流れの中の一箇所に対策を打ってもその前後のプロセスへの影響が考慮できていなければ効果が出ない。つまり大局観の感性を鍛え、周りとの関係を大切にすることが重要である。

◆コミュニケーション能力の重要性
ソフトウェア開発は人間が行う以上、一番必要となるのはコミュニケーション能力だし、それにより「現場の痛みがわかること」が重要である。これにより分析をするまでもなく、日々のコミュニケーションで問題がわかることが多い。なお、コミュニケーション能力を鍛えるのはリーダクラスに成ってからではなく、担当者の時点から積み上げて行くものである。

◆適材適所で、かつ助け合える要因配置
人は得意不得意があるのは当然である。管理者は技術的な視点からの人員配置ではなく、担当者個々人の得意不得意性格を把握した上で体制を組む事が重要だし、これにより個々人の能力の補完や助け合いにより単に足し算以上の能力が発揮される。

◆権限委譲によるチーム力の発揮
管理者が全て指示により作業をやらせると、指示できる範囲のうちはいいがこれからあふれた途端に破綻する。大切なのは人をきちんと見て権限委譲をしてチームとしての力を破棄することである。つまり、「実行力として多くの人に動いてもらえる」事が重要である。ただし、投げっぱなしでなくやり方と結果の確認は必須である。

◆当事者意識の重要性
第三者的な評論は不要である。カイゼンを推進する者は一人称で当事者とのコミュニケーションによって行うべきである。

◆部下の育成
管理者は部下を「育成」しなければならない。最初から出来そうにもない事をやらせるのが「投げっぱなし」、最終的に出来なかったら責任を取る覚悟で渡すのが「育成」である。そのためには、やり方を教えるのではなく、「考え方」や「目的」、「繰り返し」で結果が出せるようにしてあげる根気と忍耐が必要である。

◆マネジメントの役割とは
マネージャーは「教師」であり「刑事」であり「医者」でもある。何れも「相手の立場や気持ちの理解」が出来ないと勤まらない。例え、医者の腕で患者の生存率を上げても、最後は患者の治す気持ちが無いと助からない。つまり、医者は患者に対し十分な事前説明をして「同じ目標」をもって取り組む事が重要なのである。

◆内部摩擦の無駄
技術者として正しいものを作るにはどうしたら良いかを目標に体制や役割を決めるべきであり、似非商人や似非法律家は不要であし、これに類似したメンバーが増えると内部摩擦が生じる。我々は技術者集団である事を肝に銘じて磨きをかけるべきである。

◆楽しく仕事をするということ
楽しく仕事をするには、嫌なことを減らすということも大切である。例えば価値もわからない帳票を作成したり、時にこれが誤ったなぜなぜ分析票だったりするのだが。これらに目をつぶらずに、楽にする努力を惜しまない事が大切である。

◆風土を作ることの重要性
カイゼンの実現には、プロセスを変える技術論のみではだめで、「やるべき事をちゃんとやる」風土を作ることが重要である。プロセスを変えても守らなければ意味が無いからである。そのためには、管理者は「何事にも逃げない姿勢を自ら実践」し、担当者は「自ら考えプライドと責任を持つ」必要がある。「風土が作れず現場が目をつぶったらおしまい」であるし、立場に関係なく「正しいことが正しいと言える風土作り」が大切である。

◆質疑応答
Q.なぜなぜ分析で「偶然見つけた問題」とは、どんなものなのか？
A.例えば、バグレベルのなぜなぜをやっている時に、「これはもともと設計書の記載が不十分だからである」といった方向に脱線して見つかる問題である。つまり、本来コーディングレベルの分析であるのに「思考が日ごろの思いの方向に流れる」ことで見つかる別の問題のことである。

Q.本日説明いただいた内容の動きが出来れば本当に組織は良くなると思うが、黒岩様レベルの人を育成するのは現実には難しいと思う。なぜなぜ塾を開講して育成しているそうだが、具体的にはどのようなやり方をしているのか教えてほしい。
A.例えば何千人もの戦略プロジェクトでなぜなぜを広げるために、実際どうしたかと言うと、最初は私しか出来なくて他のプロジェクトリーダーは「ど素人」だった。そこで、なぜなぜ分析結果を現場から直に私に持って来るように指導した。そしてグループリーダには、私が赤入れした結果を見て勉強するように指導した。これで作業を回しておき「この人は出来る」と私が判断した人には赤入れを権限移譲した。要はプロジェクトマネージャの仕事が権限委譲できる人を育てていくことが大切である。そして、権限委譲できるスタッフは専門職化して組織上の上司とも対等に戦えるようなスタッフとすべきである。

Q.「私は面倒くさがりやだから・・・は嫌だ」という言葉を多く聞かれたが、その反面、「人を育てないとみんなが幸せになるラインを決めて、そこから下の人は個別に指導すればいい」とも仰っておられる。そもそも「個別に指導」は外から見ると面倒くさいことだと思うが黒岩様はそのようには見えない。「何を面倒くさいと思うか」が大事なキーポイントのように思うがこの基準は何か？
A.「レビューが嫌い」とか「設計は嫌だ」とか言ってはいるが、私は逆にこれらが好きな人を見つけて組んでいる。つまり完全な権限委譲をしている。
逆に現実的ななぜなぜ分析とか対策の検討については非常に細かく実施している。実際、担当者が気づかないレベルまで実施しているが、これが出来るのは私が好きだからである。つまり私の個人的な感覚で面倒くささを判断している。これによる誤りもあるので他人の意見を聞く耳はいつも大切にしている。
大切なのは組織上の立場ではなく、「現場を良くすることに対し何をすべきか」という尺度である。そのために私は常に現場目線である。つまり面倒くささの定義はしにくいし、多くの人が私のように感覚論で動くのは組織的に難しい。各組織に数名で良いと考える。

◆感想
黒岩氏が一貫して掲げるのは、「人中心のマネージメント」である。開発に携わる個々人のモチベーション高揚が個々人の仕事の楽しさにつながるし、結果的に短期間での高品質なソフトウェア開発につながる事が理解できました。その手段として、正しいなぜなぜに回帰する事が必須であると認識しました。
従来、誤ったなぜなぜにより不用意に対策を追加し、そもそもあふれた作業のために誤りを作り込んだのに、さらに追い討ちをかける対策で負のスパイラルに入り込むという経験は多く経験してきました。また、対策としてのチェックシート活用については、現場のためではなく報告書に記載するがためのチェックシートが多く氾濫しており、今回紹介されたような、現場担当者の作業目線で真の原因まで落とし込みされた最小限のチェック項目は、どこの社でもそのまま使える事項ではないでしょうか。
ソフトウェア開発は大組織化するにつれ、上部と現場との距離感は増すばかりです。だからこそ、組織の層を跨いだ又は意識しないコミュニケーションが重要であるし、建前の理想論ではなくゴールに向かうためには、何をすべきかという橋渡しの取り組みをする黒岩氏のようなエバンジェリストの存在が重要であると感じました。

＜講義の要約＞

◆「モデル」とは
（配布資料からの転記）
「ファッションモデル」「プラモデル」「統計モデル」」「モデル駆動工学」というように、日々の様々な場面で「モデル」という言葉が使われている。
「モデル」には以下のような意味がある。
・手本、模範、鑑（かがみ）、規範、（比較の）基準となるべきもの
・（...の）模型、原型、範型、見本
・（自動車・模型などの）型、形式
コンピュータ用語は、英単語本来の意味から比喩的に使われているものが多い。
例えば「アドレス」という用語は本来「住所」という意味であるが、そこから「番地」というイメージを彷彿させることから、「番地」に相当するものを「アドレス」と呼んでいる。

◆チームビルディングとその必要性
チームビルディングとはミーティングの形体のひとつである。
日本語における「会議」「打ち合わせ」は「報告をする／報告を受ける」「皆が理解していること確かめる」「アイデアを探る」「支援を得る」などを目的に実施される。一方、欧米（英語）における「ミーティング」は"Meeting of the minds"（マインドを合わせること）を意味しており、議論、問題解決、意思決定、相互理解を目的に実施される。

チームビルディングの目的は、「チームを形成すること」「コミュニケーションを図り、相互に理解し、そしてお互いの信頼を深めること」にある。
例えば、具体的な議論、問題解決の実習、チームが直面している課題の対応案を練るブレストなどを実施し、新しいアイデアやプランを考える場合と、ゲームなどを実施して、メンバー同士の親睦を図る場合がある。
親睦の基本は、挨拶に始まり、お互いが自分のことを話し、他人の話を傾聴し、ポジティブな認識・関心をフィードバックし合うことで相互理解が深まり、全員が全員の他己紹介をすることができるようになる。
チームビルディングは、1日～2日の日程で、日常の職場環境から離れ、セミナー形式で、日々の業務とは異なる活動を実施すると効果的である。
主催は自分達でもできるが、専門技術であること、客観性を持たせる点で、社外の方にファシリテーションをお願いすることが一般的である。

プロジェクトのチームビルディングを繰り返すことが「プロジェクトとして共有された価値観」を醸成し、プロジェクトを成功に導く。
同様に、組織としてのチームビルディングを繰り返すことが「組織として共有された価値観」を醸成し、会社の文化を作っていく。

システム開発ではコミュニケーションが重要視される。コミュニケーションが必要なのは、システム開発に限ったことではないが、人が関わる以上、複数の人の意見を聞きながら、合意を得て進めていく必要があるためである。
現代のチームには「様々な事情を抱えた人々が集まること」「移り行く状況、目的に即座に対応していくこと」「連絡方法を工夫すること」「個人の自立と専門性と倫理を基礎とすること」が求められる。
チームワークの状態を確認する指標としては「課題に焦点を当てる」「お互いの声を聞く」「お互いに寛容で、違いについて議論を続ける」「明快で単純な言葉を使う」「お互いの人間的、法的な権利を約束する」「相互作用を促進し、葛藤を弱めていく」「個人的にもお互いを知る」などが挙げられる。
チーム形成の手順は、メンバーの特性を把握し、チームを構成する。そして、チームを活性化していく。

チームビルディングとは、チームで目的を達成するために必要となるコミュニケーションの活性化を図るために行う日々の取り組みである。
チームビルディングはいつも現在形で「チームが抱えている課題は何か」そのために「何をしたらよいのか」についてチームで考え、チームで課題と向き合っていく。「あなた vs. 私」から「問題 vs. 私達」へ変えることである。こういう時にはこうしたほうが良いという「正解」はないが、これまでの人々が経験してきたことから、どのように考えたら良いのかというHow Toはある。

◆[ワークショップ]手はじめ・手ならい
ワークショップの前にコンストラクショニズムの説明があった。
コンストラクショニズム（構築主義）とは、MITのシーモア・パパート教授の提唱する、人はものを使って考える、あるいは手を動かしているときに、多くの大人がかつて子供だった頃に持っていたのに用いることを忘れてしまった創造的な力、思考、ものの見方が引き出されるという考えである。

ワークショップはブロックを使い、コンストラクショニズム（「手を動かしてみる」「ものを使って考える」「手を動かして考える」こと）を体験した。
最初に、30個のブロックを所定のブロックの上に積み上げた。
次に、20個のブロックで未来の乗り物をモデリングした。
また、6色の中から「信頼」を表す色のブロックを選び、その理由をメンバーに語る演習の紹介があった。

◆[ワークショップ]チームでのモデリング
最初に、ソフトウェア品質を追求する自分自身をモデリングしたアバターを作成し、お互いに自己紹介した。この時に自分が知っている「チームビルディング」アクティビティについて話し、皆で共有した。
次に、品質と自分、自分の分科会のテーマとの関係を表したものを組み合わせ、チームの作品を作成した。
50分間で作品を作り、その後で各チームの作品を鑑賞し合った。

◆コンストラクショニズムとシリアスゲーム
（配布資料からの転記）
MITのシーモア・パパート教授は、子供たちの美術の授業の様子と数学の授業の様子の違いに愕然とし、数学を学ぶ文化が身近にないことに問題を感じてコンストラクショニズムを考え始めた。
1968年より子供向けプログラミング言語LOGOを開発し、1980年代にはLEGO LOGOプロジェクトに発展した。

◆チームビルディングとコミュニケーション
（配布資料からの転記）
チームビルディングは仕事から離れるが、仕事の時間に行い、関係者全員が集まることが必要である。社外の方にファシリテーションをお願いすることが一般的であるが、主催は自分達でもできる。
そして、参加者の皆が楽しむことができるワークショップとなるように、仕事と連動させて目的を明確にし、チームの形成やコミュニケーションのモデル、構造、装置を作ることが重要である。
なお、仕事が困難になる前に行うことが原則だが、後から実施しても手遅れではない。
また、組織や人の新陳代謝に合わせて繰り返し行うことが重要である。

まずは、「親睦を図る。お互いを知る」ことから始め、この後、プロジェクトの課題に対する議論、技術やその移転に関する議論、技術的なコミュニケーションに関する議論、コミュニケーションや議論に関する議論など、「チームが直面している課題に関する議論」へと発展させていく。
「あなた vs. 私」から「問題 vs. 私達」へ、"I think"から"We think"へ変えていく。

◆最後に
ソフトウェア品質確保や研究の追究は一人ではできない。チームで、技術的で建設的な議論や、皆が幸せになる研究や職場を作ろう。見えないソフトウェアをモデル化して、チームで考えていくことを志向しよう。
また、利用者や利害関係者と円滑な、様々な形態のコミュニケーションを図ろう。様々な人達と話そう、活動しよう。
先ずは、挨拶と自己紹介から始めよう。考えたことをやって、継続していこう。最初は小さな一歩でもいい。

＜講義の感想＞
「モデルを作成することで自分の考えやイメージを伝え易くなること」「手を動かし、ものを使って考えることにより、イメージが創出されること」「チームで話し合い、納得し、協力し、ひとつのものを作り上げることの爽快さ」を体感することができました。研究メンバー同士がこのような体験をしたことで、お互いの理解が深まり、今後の議論をするための土台が作られたと思います。
各チームの作品は、どれも独創的でチームワークと楽しさを感じるものでした。
チームビルディングは、プロジェクトの立ち上げ時に実施するものというイメージが強かったのですが、プロジェクト実行中の方がより重要であることを認識しました。自分の周りのプロジェクトに目を向け、できそうな小さなものを見つけ、継続することを目標に、行動してみようと思います。

司会者：鷲崎氏からの講演への着目点のご案内
「アジャイル開発とかリーン開発を適用したいんですがどうしたらいいのでしょうか」という質問をよく受けますが、「質問が違うのじゃないですか？」と答えます。開発方法を適用する事が目的ではなく、「あなたの中にどういう問題があって、それを解決するためにはどうすれば良いかを一緒に考えましょう」とアドバイスします。
本日の内容も、そのまま使ってみようというのではなく、根底の中にある考え方はどういうもので、それが皆様の中に抱える問題であるとか、仕事のやり方であるとか、マネジメントの仕方であるとかとどういう関係があるだろうかということを考えながら聞いていただければ幸いです。

＜講義の要約＞

【１】リーンから、リーン(ソフトウェア)開発へ
・リーンの語源
「リーン（LEAN）」の意味は、その直訳の通り「筋肉質で贅肉がない」とう意味ですが、筋肉だけという意味ではなく「無駄がない」という意味が当てはまるでしょう。機敏に動けて力も出せるというイメージです。

・リーンの起源
１９８０年代世界の景気が停滞する中,、ヨタだけは大きな伸びを示していました。この生産方式にMITのジェームズ・P・ウォマック氏、ダニエル・T・ジョーズ氏らが着目し研究する中でトヨタにおける作業の仕方を表す言葉として提唱されたものです。この時代からトヨタ生産方式が世界に知れ渡っていた事は素晴らしいことです。

・TPS（トヨタ生産方式）の家
トヨタ生産方式を俯瞰するものとして、書物「ザ・トヨタウェイ」に示されたTPSの家が有名です。後述するトヨタ生産方式のリーン思考の原則を家の構造に例えて図示したものです。
( http://jp.fujitsu.com/family/lsken/activity/work-group/09/abstract/pdf/2009abstract-11_tps.pdf )

・リーンソフトウェア開発
トヨタ生産方式に基づくリーンの思考をソフトウェア開発へつなげる考えをメアリー・ポッペンディーク氏らがまとめて、2003年に「リーンソフトウェア開発」として出版されたのがソフトウェアへの考え方の導入の起源です。それ以来いくつかの書物が出版されてきましたが、開発現場からは遠い内容でした。再度現場への適用の考え方をまとめた「リーン開発の現場（カンバンによる大規模プロジェクトの運営）」がこの１０月に出版されます。

【２】リーン開発で重視する「品質」
・品質の定義
品質の定義は一般的には様々な規格または研究者によって定義されていますが、現在は「ユーザの満足を最終ゴール」とする事で概ね世界的に合意が得られています。そしてこの考え方は、石川馨氏他による「消費者志向」の考え方の影響が大きいのです。

・SQuBOK(ソフトウェア品質)とリーン開発との接点
この両者の接点は以下の事項の相性が良い事と考えられます。
「プロダクトの特性が顧客のニーズに応える事で満足を提供する」「品質は収益と結びつく」「不備（障害や誤り）から免れる」「よりコストがかからない」そしてこれらはTQMにもつながる事項ですし、品質がよければ儲かるという事にもつながります。

・納品後のソフトウェアの機能の利用度
2002年のアジャイルカンファレンスのジム・ジョンソン氏の報告によると、納品後の機能の利用度はせっかく苦労して開発し納品しても約半数の機能は全く使われていないし、実際に使われるのは全体の１／３、よく利用されるのは１／５です。つまり多くの無駄な機能を納品しているわけです。ただし、受託して作る側から言うと使われようが使われまいが作ることにより収益を得られるので、表面上は満足しているように見えますが、「役に立たないものを作っていた、ゴミを作っていた」と考えると何とも辛い思いとなります。これは、契約形態が人月いくらという形態である事が問題でありビジネス構造の重要な問題です。

・システムは陳腐化する
従来、開発においては要求を早く固定する事を良しとしてきました。しかし昨今の要求事項の価値の変化速度の激しい時代では、開発しているうちにすでに提供価値の陳腐化が進みます。つまり要求を早い時期に固定すると、その製品の完成時期にはすでに価値の多くが劣化してしまうことになります。
これを防ぐためには、要求の固定を遅らせる事が必要になります。しかしながらこれでは開発期間が短くなり現実的では有りません。この相反する条件を満たす手段として「保守開発」という考え方があります。つまり、保守しながら小刻みで要求を反映し続ける事で提供価値を維持し続ける事が可能となります。これを実現する手段としてリーン開発の考え方が必要となります。

【３】リーン開発
・リーン開発とは
しばしば開発手法と間違われますが、手法ではなくトヨタ生産方式を手本としたより良いソフトウェア開発を
考える思考ツールです。書物「リーンソフトウェア開発」においては、７つの原則と２２の思考ツールが紹介されています。主旨は、プル生産方式の考え方とそれの現場への適用のし方です。
また、書物「リーン開発の本質」では、現場への適用の考え方の中で、「アイデアをいかに早くお金に換えるか」という視点で紹介されています。

・前提とするビジネス環境
リーン開発が注目されだした理由は、ビジネス環境の変化の影響が大きいのです。前述したように、市場に供給したものが市場ニーズに合致する事が成功条件でありますし、そのためにはニーズの変化にいち早く対応する事が必要となります。つまり、要求の固定を遅らせ短周期での開発を実施する必要があります。そして更に難しい条件として「自らが供給したシステムによって利用者のニーズそのものも変化を受ける」という複雑な連鎖もあります。このようにシステム開発には多様なリスクが潜んでいます。

・ニーズに合う商品を提供するために
これらニーズに関する影響を最小に抑えるためには、市場ニーズを把握してからそれを実現する周期の短縮を図る必要があります。そのためには、時間軸上のムダを省いてニーズの獲得から商品提供までを如何に素早く行うかが命題となります。これの実現のためにリーンの考え方が必要となるわけです。

【４】リーン開発の原則
リーン開発を語る上で難しいのは、そもそも思考なので抽象論である事です。よって、自身の経験を付け加えて説明します。
・リーン思考の原則（リーン開発の本質）
リーン思考の原則は、以下の７つです。これら全体に共通する考え方は「良い状態を保つための思考フレームワーク」です。
・原則１：ムダをなくす、・原則２：品質を作りこむ、・原則３：知識を作り出す、・原則４：決定を遅らせる、
・原則５：速く提供する、・原則６：人を尊重する、・原則７：全体を最適化する
以下に各原則を説明します。
・原則１：ムダをなくす
生産工程での７つのムダが定義されています。その中で代表的なムダは以下です。
在庫のムダ、作りすぎの無駄：使われない機能のモジュールはこれに相当します。
動作のムダ：掛け持ちで複数作業を実施する場合、タスク切り替えにムダが生じます。
では、ムダの定義は何でしょう。ここで大切なのは、顧客視点のムダと開発側視点のムダは異なる部分がある事です。お客様視点のムダとは、「お客様にとって価値のないもの」であり、例えば開発側では必須であると思い込んでいる品質確保の手段としてのデバッグは、お客様視点ではムダと見なせます。こう考えると目指すのは、「開発側のムダを無くし」、「お客様視点のムダを如何に減らすか」ということになります。そしてこのムダ取りにより開側のムダをゼロにし、その分をお客様の付加価値に回せば大きな生産性向上が望めるのです。
ここで開発側のムダを排除する方法を紹介しましょう。この比較評価にはバリューストリームマップが有効です。製品の要求分析からお客様へのリリースまでの各工程を時間軸で評価します。お客様目線で見た場合の価値とムダを工程ごとに時間軸で書き出だしてみます。ここに紹介した例では、工程トータルで価値は２時間４０分、ムダは６週間と４時間になりました。さて、全工程に要した時間とお客様の価値を比較して、それを効率とすると何と１％と見なせます。つまりお客様視点から評価すると９９％はムダなのです。

【タスク切り替えのムダを体験するワーク】
開発組織のムダを体験するために、タスク切り替えのムダをワークで体験してみましょう。手元にお配りした表に倍数を書き込んでいくワークです。１回目は上の表は２，４・・・と記入していき３０秒経ったら下の表に９，１８・・・と３０秒間記入していきます。２回目は１分間で上の表と下の表を交互に倍数を記入していきます。さて、１回目と２回目の比較でどちらが多くの数字を記入できたでしょうか。多くの方は１回目の方が多くの数字を書き込めたと思います。つなり、このような単純な作業でも上下の表に書くというタスクを切り替える事で効率が落ちる、つまりタスク切り替えのムダが判る訳です。

・原則２：品質を作りこむ
ここで大切なことは、作って最後で直すのではなく直さないように作ることです。例えば、各工程の中で小刻みなチェックを入れる事で大きな手戻りを無くすのもこれに相当します。また、ムダなコードを無くすには、「テスト駆動開発（TDD）」の適用も効果的です。テストコードをまず書く事で実行可能なユニットテストを作りながらのプログラミングが可能となります。早い段階でチェックするという意味では、ピアレビューもこれに相当します。チームの中の身近な者にまずチェックしてもらう事で早い段階で欠陥を直し手戻りの最小化が見込めます。

・原則３：知識を作り出す
通常の開発プロジェクトですと当該プロジェクトが完了時点で振り返りを実施し、何を継続すべきか、何を改善すべきか、そして今後のチャレンジすべき事は何かについて次のプロジェクトへの申し送りする場合が多いのですが、これですと学習サイクルが大きいために学びのタイミングも遅くなります。そこで、日々の作業の中でこのサ
イクルを小刻みに回しながら進めれば、開発完了時期を待たずに学びながら進めることができます。学習のみではなく、例えば、PDCAを１週から４週程度の期間で回せば、つまりアジャイル的なイテレーションですが、例え失敗しても早く小さな段階で失敗を発見できアクションを実施できるわけです。

・原則４：決定を遅らせる
大胆な考え方です。従来、開発プロセスの常識として仕様は開発早期に決定すべきといわれてきました。ところが、先に述べたように取り巻く環境の動きの速さが顕著になってきた昨今では、早く決定すると出荷時にはすでに陳腐化してしまうのです。よって、決定のデッドラインを決めた上でぎりぎりまで決定を遅らせることにより盛り込める知識が増え、ぎりぎりまで磨けることとなります。
これを助ける手段として、「継続的インテグレーション」という言葉があります。開発中のソフトウェアを常に出荷可能な状態に保った上で新たな機能を追加していくやり方です。これによりビッグバン結合試験が可能となり、テスト期間の短縮によりコスト削減にもつながります。

・原則５：速く提供する
前にも述べましたが、短期間での開発が可能となれば、要件の決定時期を極限まで遅らせる事ができ、相対的に要件の実現を早くできたのと同じこととなります。これにより、より多くの付加価値を付ける事が可能となるわけです。

・原則６：人を尊重する
トヨタ生産方式において常に触れられる事に「人を尊重する」という言葉があります。これは、「人は機械ではないのだから各人が自発的に動く事が大事である」という思想に基づくのです。これの手助けをするのがリーダーです。逆に、全てリーダーが指示し管理する組織を作ってしまうと、「言われたから行動する」とか、逆に「言われないから行動しない」といった事になり、リーダーの責任問題となります。つまり、リーダーがボトルネックになってしまいます。こうなるとだれもリーダーには成りたくないといった消極的な組織となります。逆に、メンバーが自発的に行動し、メンバー間も自立的に協働するという仕組みを作るのがリーダーの仕事です。
次に、「見える化」についても重要なキーワードです。異常を見えるようにし、自然にアクションをとるような仕組みです。決して管理のための道具にしてはいけません。例えば、個人の査定に使うのは最悪で、こうすると嘘の情報があがるようになるので破綻してしまいます。
見える化のサイクルは現場のチーム内で回さないとうまくいきません。つまり、可視化した事によりチーム内の担当者が問題に気付き、チームで改善策を検討し実施する事が大切です。もしもリーダーが先に問題に気付いてしまうと、リーダーの改善策が現場に伝わらないか、もしくはやらされ感に陥ってしまうのです。
見える化の道具として「タスクボード」があります。タスクの状態を未実施（ToDo）・実施中（Doing）完了（Done）の３つの状態に分けて配置します。各タスクが今どの状態にあるのかを明示する事で各人の状況が常に見えます。ここで大切なのは「だれかが困っているのか」が見えれば「即座に助け合う風土をつくる」事です。このタスクボードを導入しただけで生産性が３０％も向上した事例もあります。
また、バグの見える化ツールとして「バグレゴ」があります。バグが出るとレゴブロックで自由に形を作り並べるのです。レゴにはバグのチケット番号とバグ概要を付箋紙に書き込み貼っておきます。例えば、影響度大のバグであればお手上げの人形を載せたりし、一目で状況が見えるようにするのです。この施策によりバグを隠さなくなったとの事例があります。もしもこのボードがバグで埋まってしまって置く所がなくなれば、一旦試験を止めてバグ解決に集中しようと宣言します。この取り組みは、ゲーミフィケーションの考え方が入っているとも思われます。つまり、普段の活動の中に小さい目標管理とか小さい報酬を入れて仕掛けを継続していこうもしくは自発的に行動する仕組みを維持しましょうという考え方です。

・原則７：全体を最適化する
各工程をつなぐプロセスが有る場合、先のプロセスに塊（仕掛品）ができてしまう場合があります。つまり滞留が生じてるわけです。この滞留は無駄なわけで、これをスムースに流れるようにしましょうという考え方です。まさにTOC（Theory of Constraints : 制約理論）の考え方です。
最近、この状態をタスクボードに入れて分析する動きがあります。制限付きのタスクボードと言いますが、各工程の仕掛品の量に制限を設けることにより、制限値以上に滞留をさせないという考え方です。タスクの状態を未実施（ToDo）・実施中（Doing）完了（Done）の３つの状態に分けて配置したものです。後工程のタスクが完了しない限りいくら前工程からタスクを送り込んでも、在庫（仕掛品）Readyのタスクが増えるばかりで完了タスクは増えないので、全体としては価値がない事となります。では、先の工程のタスクが制限値に達した場合、自分の工程
では何をやるかと言うと、他のネックとなっている工程のタスクを手伝いに回るというものです。実際には、自分の担当以外のタスクも実施できることが前提にはなりますが、これができると全体としての生産性はあがります。つまり、各担当が自分の担当のみ頑張るのではなく、全体を見渡してうまく流れている事を確認しながら進めるのが大事です。例えば、仕掛のタスクがある状態で前工程のタスクについて変更要望があった場合、その仕掛タスクはやり直しになる場合も考えられます。まさにムダです。

【５】リーン開発はアジャイル開発か？
・アジャイル開発とは
ソフトウェア要件の理解からリリースまでのサイクルを素早く回すための開発手法や技術の総称です。

・代表的なアジャイル開発手法
アジャイルという言葉が生まれたきっかけは、2001年2月にKent Beck らにより宣言された「アジャイルソフトウェア開発宣言」によります。この内容は、当時軽量級と呼ばれていた開発手法でもちゃんとした結果を出している事を宣言したもので、各開発手法の共通点をまとめてアジャイル宣言としたものです。つまり、個々の手法を明確に示すものではなく、活動といった方が当てはまります。
広義のアジャイルと狭義のアジャイルの定義がありますが、狭義では前述した宣言文に署名しているかどうかです。リーン開発の著者であるBob Charette氏、Mary & Tom Poppendieck夫妻はこの宣言に署名をしていませんので、そういう意味では、リーン開発はアジャイル開発ではないと言えます。ただし、個々の取り組みを見ると類似のものがありますので、広義にはアジャイル開発といえます。これらの議論はあまり意味がないのですが、各人が現場に帰った際に実際何が役に立つかを見極めて対応してほしいです。
注意すべきは、われわれは開発手法を議論するのが目的ではないので、アジャイルかそうでないかは議論の的ではありません。「開発現場で本当に役立つやり方は何だろう」という議論が大切で、それを議論する中でそれぞれの手法を参考にして考える事が大切です。そしてその中で、「収益を上げよう」とか「組織をどう考えよう」という場合にリーンの考え方にヒントが多いし、「チーム運営をどうしたら良いか」という場合にはスクラムの考え方が役立ちます。またXPは「テスト駆動開発「とか「継続的インテグレーション」とか「ペアプログラミング」といった、実際の現場での技術的手法として参考になります。
大切なのは「自分たちが使いこなせる事」であり、皆さんが「現場で役立つやり方は何か」を考えてほしいのです。これら手法は提唱者の関心事でまとめたものに過ぎないからです。

・アジャイル開発とリーン開発の関係
Developers Summit 2013において、川口恭伸氏が発表した「Agile and Lean」の資料の紹介です。
  ( http://sssslide.com/speakerdeck.com/kawaguti/agile-and-lean-from-altitude-12-000-feets )
アジャイルと日本の製造業とリーンの関係が示されており、リーンはTPSの影響を受けており、アジャイルに対しては影響を与えているという図です。他の手法もリーンで表現しようとすれば可能な事が多いのです。つまり様々な提唱がされているが、考え方では共通するものが多いのです。

【バリューストリーム分析と７つの原則の理解を深める演習の紹介】
・バリューストリーム分析
自分の仕事をバリューストリーム分析で実際に分析してみようというものです。開発の各工程を時間軸で並べてみて、その各工程に実際の価値のある作業はどれ位で、どれだけの無駄な時間があるか、待たされている作業は無いかを明示するものです。この図を描こうとすると一人では描けません。このため社外も含めた関連者皆で話をしなければならない、これにより様々なムダが見えてきます。簡易に試すのであれば、自分の前後の仕事を描いてみるのも良いでしょう。

・７つの原則の理解を深める
そもそも原則なので日常作業の至る所に眠っている事項です。皆で「うまく言っているところ」、「ここは何かおかしいな」という気付きが大切です。例えばレビューのやり方です。「従来なぜ最後にまとめてレビューしていたのだろう」という気付きが得られました。日次ミーティング・朝会、振り返りの会とかでどんな原則が含まれているかを議論してみるのが良いでしょう。これらの説明はIPAから出ているものがあります。

【６】リーン開発的なソフトウェア開発の分析
今回は説明は省きましが、下記事項について議論してみるのが良いでしょう。
・バリューストリーム分析、７つの原則、日次ミーティング、ふりかえり、リファクタリング

【７】リーン開発を取り巻く世界
・「リーン思考」を身に付けると待ち行列が見えてくる！
仮説を説明してきたがこれを考えていますと、何が動いていて何が溜まっているかが見えてきます。例えばレビューの実施を考えると、レビュー結果により何度も何度も修正する事で、その前後に待ち行列が増加している事が見えてきます。これはレビュー?修正のサイクルが過度に回りすぎている可能性があるからです。その場合、やはり作る段階で対策を打つ必要性が見えてきます。

・タスクボードの例（人毎の作業を把握）
ToDoに個人単位にタスクを固定し助け合いが無いと、タスクが溜まる者と空きの者とが出てきます。そこで人に固定しない共通タスクのカテゴリを設けると、空きができた者は共通タスクを実施する事で全体が最適化されます。この場合、まずはだれでもできるタスクを切り出すのですが、育成も利用して徐々にだれでもできるタスクを増やして行くことが改善につながります。

・ファーストフード店の座席稼働率の問題
座席が込んでいる場合、注文をとる前に座席を確保する方が居ます。これが増えると食事をする前から座席の占有時間が増えてしまい本来の座席の稼働率が落ちます。改善するには注文数に制限を設け、座席の空きを確保しておく、つまり後工程の処理能力を基準にして前工程の処理能力を落とすことで座席の稼動率が向上し最適化されます。

・リーンスタートアップと学習サイクル
予算が少ない中で、いかに身軽に素早く導入を進めるかです。簡易なプロダクトをターゲットにして回してみてその結果から学びを得てふくらまして行くやり方です。ここでプロダクトを作る段階でアジャイルの考え方が注目されています。リスクを考えればスモールスタートでやるのが良いがその場合にもアジャイルの考え方が役に立ちます。

◆質疑応答
Q1.　バリューストリームMAPについてですが、このMAPを作って、価値を生む仕事がどの位で実際どの位時間がかかるかは考える場合、MAPの一番下の欄の待ち時間がありますが、これは悪であると言う視点だと思います。それがリーン開発の視点と考えてよろしいでしょうか？
A1.　要は早くリリースしたいと言うことです。早くリリースするためにはどうするかと考える事が大前提です。そのために待ち時間が合ったら遅くなります。そこでまずは待ち時間を削減する事からはじめれば楽だと言う事です。TOCと同じでボトルネックを探してやり易い所から取り組んで行くのが良いでしょう。

Q2.　原則４の「決定を遅らせる」についてですが、部下とか回りのメンバーに影響する仕事をしている場合に、自分の決定を遅らせると回りに影響が出てくるし、出荷間際に作りこんだものは回りにも影響が出てしまって品質も保てないのではないでしょうか？そこで解釈は以下で宜しいでしょうか。方針の決定、及び主要な機能の改造追加はしておき、出荷に向けたチューニングは出荷間際に実施する。という事でしょうか？
A2.　方針も遅らせるほうが良いです。リリースに間に合えば良いのでそのためにどこまで遅らせられるかが大事です。ゴールできる範囲で如何に決定を遅らせるかということです。

Q3.　 タスクボードを試したがうまくいきませんでした。人の常として自分のノルマを守ろうという考えが強いからだと思いました。最終的に関連者全体がうまく回るという事を伝えて普及させるにはどうしたら良いでしょうか。
A3.　タスクボードの使い方のみを学んでもうまくいきません。タスクボードに貼るタスクを皆で考えることが大切だからです。見積もり、プランニングについて関連者で議論し考え方を共有する事が大事なのです。
自分はこう思うが他人は考えが違う場合でも「こうするとうまくいく」というコミュニケーションが図れる事が良いのです。タスクボードを監視のツールにしてはいけません。どう知らしめていくかと言うと、タスクボードの使い方が若干甘かったからかも知れません。叱る役を置くのも良いでしょう。母親のように成長につながるように叱るのがコツです。

Q4.　バリューストリームマップの書き方で「価値」の行、「ムダ」の行の書き方について教えてほしい。
A4.　特に決まった書き方は無いのですが、「正味の作業」と「付帯作業、待ち時間」を表せば良いです。
それにより価値とムダを明示できることが目的ですので。

◆感想
まず、冒頭で本日の講演内容についてご案内いただきました鷲崎氏の発言に強く同調しました。ソフトウェア開発に関わる思想・手法につきましては、キーワードを耳にすればまずは紐解かないと気が済みませんし、書物を読めば自らの課題はさておき試して見たくなるのが人情ですし、そこで間違いが起こる事を再認識いたしました。
開発の思想、手法については様々な場で議論もしましたし、書物も手にしたのですがどうも「腹に落ちない」状態が長く続いておりました。本日の講演のキーワードはリーン開発なのですが、トヨタ生産方式をはじめとし、アジャイル開発等、昨今のキーワードまで含めてその経歴・関連について紐解いていただき、霧が晴れた思いです。特に「思想」と「手法」の違いを明示していただいた事で、現場の課題と適用すべき思想、方針が見えてきました。
司会者であられます鷲崎様、貴重な講演をしてくださいました天野様に深く感謝いたします。

＜講義の要約＞

◆品質の観点からゲーム産業を俯瞰
ビジネス状況は、2013CESAゲーム白書によると、国内メーカはハードウェアが好調で、売り上げは1兆4,000億円である。10年くらいのトレンドを見ると、ハードウェアとソフトウェアを合わせて1兆円、ソフトウェアはその半分の5,000億円で、国内と海外が半々といった構造になっており、海外が無視できない状況にある。

上記のようなビジネス状況において、ゲーム業界ではQCDがどのように考えられているのかについて紹介する。

「C：コスト」を占める順位は、人件費、広告宣伝費、運営費、開発環境整備費、管理費、製造費などである。いちばん掛かるのはソフトウェアエンジニア、シナリオライタ、デザイナなどを雇用する人件費で、次いではコンシューマに製品を通知するための広告宣伝費である。
次いで掛かるのは運営費で、ネットを使ったゲームが増えるにつれて、サーバを構え管理するケースが増え、ユーザを飽きさせないように、新たなサービス、イベント、アイテムを追加する派生開発の費用が増えている。次いでは、開発環境整備費、管理費である。いちばん掛からないのは製造費で、ダウンロード版ではゼロである。

「D：納期」は基本的に短納期が求められる。コストの大半は人件費なので、コストを抑えるために、短期間で制作することが必要で、同じ内容（アイデア）のゲームであれば、出来るだけ早く販売したものが勝者になる。投資効果が見込める大規模タイトルは十分な投資と時間を掛けて制作することができるが、新ジャンルは出来るだけ短い期間で制作し出来るだけ早く販売することが求められる。

「Q：品質」の要求水準は、ユーザ視点（需要）と事業者視点（供給）で決まる。
ユーザ視点は、ゲームとして面白く、ソフトウェアとしてちゃんと動くことであり、事業者視点は、事業として儲かることである。
コンピュータゲームが評価されるのは、シナリオのよさで、ソフトウェアはシナリオを楽しめるレベルで動くことが求められる。取り残したバグがあった場合でも、統計的に発生頻度が小さく、ユーザへの影響が無視できるレベルにあれば、修正しないことがある。一方、ゲームのデータがセーブできなくなるハングアップなどの深刻な問題を防止するために、プラットフォーマ（プラットフォームを持っているメーカ）の厳しい品質チェックに合格しないと販売できない縛りがある。ソーシャルゲームの品質チェックはかなり緩い。
実際のユーザの視点を知ることは難しい。ゲームを制作した当事者の評価は偏った評価であり、コンシューマに受け入れられるものを評価しているとは限らない。ソーシャルゲームはゲームで遊んでいる間の操作がサーバに送られユーザ動向の調査に活用される。ゲームメーカはユーザ動向を分析し、よく使われている部分を拡張、使われていない部分を削除するなどして、ユーザがより魅力を感じる方向にゲームを進化させ続けることがトレンドになっている。
ユーザ視点の「面白い」を定量的に評価することは難しく、ユーザ動向の指標で代用している。最近ではKPIを活用してソーシャルゲームを運用する取り組みがある。ユーザ動向とソフトウェア品質の相関はそれほど高くない。また、ユーザ動向の指標は時系列の増減のみ有意で拡大解釈は危険である。ひとつのメジャータイトルを時系列的に比較することは意味があるが、複数のメジャータイトル（別ジャンル）同士をKPIで比較することに意味はない。KPIで分かることは【儲かるか／儲からないか】なので、これに頼りすぎると、最近のソーシャルゲームのようにカードゲームばかりとなる状況に陥る。
コンシューマ【ゲーム専用機向けの(ROMで提供される)ゲーム】においては、昔は指標を取るすべがなかったので相対的にソフトウェア品質に留意した開発をしてきた。そして、出荷媒体はROMしかなくROMの出荷品質がクリティカルであった。今では最初にROMで出荷しても後からインターネット経由でアップデートできるため、昔よりもクリティカルではなくなった。
ソーシャルゲームはサービス開始時の品質はクリティカルではない。ソーシャルゲームの新ジャンルは、アーリーアダプタの目に付く場所で遊んでもらいながらゲームを進化させ、儲けられるレベルに到達したら、広告宣伝費を掛けてコンシューマに伝えている。
このように、品質に関してはコンシューマ【ゲーム専用機向けの(ROMで提供される)ゲーム】とソーシャルゲームには温度差がある。

◆コンピュータゲーム開発の現状について
○アーキテクチャ
ゲームの設計がすごいということはない。リアルタイムで動くメインの部分については、タスクシステムという枯れたアーキテクチャが存在し、アドベンチャー、シューティングについては、スクリプトでプログラムを制作する。このアーキテクチャは10年以上、基本は変わっていないので、作法を知っている人がきちんと制作すれば品質はそんなに悪くはならない。
最近ではタスクエンジンの論理的なアーキテクチャをパッケージ販売している。以前は非常に高価であったが手頃な価格となり、ライセンスも販売数がある数を超えてから発生するものがあるので、タスクエンジンを使って自分の望むゲームを制作できるようになった。タスクエンジンは知見のある高度な技術者が制作しているので、自分達がゼロから制作するよりも、タスクエンジンを採用する方が投資効果がよい。

○開発の自動化（ツールの活用）
1)静的解析ツール
ゲーム業界の大手はソフトを外注化して自社ブランドで販売することがある。そのような場合、外注から上がってきたソースをレビューしなければならないが、レビューアを長時間確保することは難しいので、静的解析ツールを活用してレビュー効率を高めている。

2)CI（継続的インテグレーション）
ゲーム開発は、ソフトウェアエンジニア、シナリオライタ、デザイナなどの協業で制作を進めるため、ゲームのシナリオやデザインに何らかの変更があった場合に、ソフトウェアエンジニアがいなくても、ビルドが実行できるように、JenkinsなどのCIツールを活用してビルドを自動化し、最新版で結合試験できる環境を実現している。

○開発プロセス
開発プロセスを効率化して品質担保の取り組み実施するためにAgileを導入している。ゲーム開発は納期が決まっているので、開発プロセスはウォータフォールのように見えるが、ゲームが面白いのかを考えながら制作するので、必然的に反復開発をしてきた。そのような文化とAgileは相性がよく、多くのゲームメーカがAgileを広めたいと考えている。
Agileの取り組みのほとんどは、大規模システムの開発においてプロセスの縛りが厳しい所を緩めれば周りがよくなるということであるが、元々プロセスの縛りが緩い所にAgileを導入して引き締めることは、考えの方向が逆となので、そのことを理解しているかいないかで、導入が成功するか失敗するかが決まる。
Agileが有効か有効でないのかを数学的に考えるために、ソフトウェア開発は問題解決であるとする。そうすると、問題と解答はある空間の座標で表現され、その座標に対する点数を示す評価関数で表現できる。空間を2次元だとすると評価関数をf( )として解答=f(問題)となる。
f( )が時間とともに変化しないで固定されている場合は、同じドメインで仕事すればするほど、今まで見えていなかったf( )がはっきりと見えるようになり、どこがピークになるのかを特定できるようになる。このような場合は、Agileを導入する必要ななく、ピークを狙った計画を立案し、実施すればよい。同じIPで10年間やっていて、ユーザもある程度決まっていて、有名なデザイナがやっている場合がこれに当たる。
これに対して、f( )が時間とともに変化する場合は、どこがピークになるのかを特定できない。このような場合はAgileを導入する価値がある。前はシューティングゲームを制作したが、次はロールプレイングを制作するような場合、ソーシャルゲームの新ジャンルの場合などがこれに当たる。

〇ゲームとしての品質
ゲームとして面白いかどうかは、昔はよく分からないことだったが、最近はユーザ動向の統計処理が手軽にできるようになり、統計処理の観点からゲームの面白さを評価する取り組みがある。また、認知科学からの観点からゲームが面白いかどうかについての取り組みがある。
複数ユーザがマップの中でゲームをする場合、ユーザはどの位置で何をしたのかをサーバに吸い上げ、それをヒートマップとして視覚化したものを使って、現状のゲームが設計通りに遊ばれているのかを分析し、マップを改善することに活かしている。

◆コンピュータゲーム開発のこれからについて
○ゲームソフトウェアの特徴
枯れた論理的なアーキテクチャを使ったゲームエンジンの上に、ゲームを制作するDSL（ドメイン固有言語）が組み込まれており、効率的な制作が行えるようになっている。

○DSLのうれしさ
DSLを使う利点は、文法の規模が小さいため、DSLのツールを用意しやすいことにある。また、DSLでビジネスロジックを書くことができるので、ゲームの実装（画面を表示してキャラクタを動かすのかといった処理をCやJAVAで書くこと）から離れて、ゲームの内容を形式的に扱うことができる。そして、シナリオの矛盾点をDSLのツールを使ってDSLレベルで検証することができる。

DSLを使ってシナリオの矛盾点を見つけるデモ
アドベンチチャゲームのシナリオ進行をモデル検査する例
簡単なアドベンチャーゲームを、LTSAというモデル検査ツールで矛盾点を探すデモが実施された。
一つ目：
プログラムコード中にLTSAを活用するためのモデル式、変換式を出力する検査コードを組み込み、検査コードの出力結果をLTSAに読み込ませると、シナリオ進行が状態遷移図で表示される。これと設計したシナリオ進行の状態遷移図を比較し、状態遷移図からシナリオの矛盾点を特定することができる。
二つ目：
シナリオの透過性（例えば、面ごとに鍵を見つけてドアを開けるといったシナリオにおいて、１面目で鍵を見つけると、2面目は鍵を見つけなくてもドアが開けられてしまうといった矛盾）は、あるべき姿（正しい姿）をテストプロセスとして検査コードを組み込めば、テストプロセスとシナリオの出力結果を使い、LTSAで矛盾点を特定することができる。
三つ目：
キャラクタの関係性（例えば、AキャラとBキャラはお互いに知らないシナリオにおいて、AキャラとBキャラがお互いに知っているといった矛盾）も、あるべき姿（正しい姿）をテストプロセスとして検査コードを組み込めば、テストプロセスとシナリオの出力結果を使い、LTSAで矛盾点を特定することができる。

◆質疑応答
Q：日本はゲーム産業が強いと思っていたが、海外で作られたシステマティックなゲームエンジンを導入して仕事を分業している状況に驚いた。昔はソフトウェアエンジニア、シナリオライタ、デザイナが、ひとつのチームひとつの部屋に集まって擦り合わせながら開発していくスタイルであったが、今は会社の中で求められるスキルセットが変わって自分のスキルを活かせていない人がいるのではないかと思った。そして、そんなこんなことをしているうちにゲーム産業が衰退してしまうのではないかと心配になったが、その辺りの状況を教えてほしい。

A：欧米ではサブプライムの時に多くのスタジオがリストラを実施した。リストラされた彼らの多くは、他の仕事に就くのではなく、数人が集まってインディゲームを制作するようになった。
一方、日本ではレイオフされることがシビアではない。会社の仕事は大規模タイトルの一部しかやらせてもらえない状況かもしれないが、昔に比べて家に帰れるようになったため、家に帰ってから自分の好きなインディゲームを制作し、コミケとかプレイストアとかアップルストアとかで販売している人達がいる。こういったインディの中からヒーローが出てきてほしいと期待している。

Q：LTSAなどのモデル検査の中で、例えば、最初に戻るとか、もう一回やってみるといったことは、テスト観点でいうとテストデザインに相当すると思うが、シナリオからどこをテストするのか、どのような検査コードで、どのような条件で組み上げていくのか、ということを、どのように設計しているのか教えてほしい。

A：モデル検査に限ったことではなく、ユニットテスト（テスティングFW）の上で自動検査コードを出す取り組みと似ている。
最後まで行ったらフラグに矛盾があるといった経験的に積み上げられるテストケースは、今のツールにアドインしていくことできる。
これに対し、キャラクタ間の関係性の矛盾を検出するようなテストケースは、シナリオごとに用意しなければならない。シナリオライタが頭の中でやっていることを知見化できれば、LTSAのようなモデル検査ツールに組み込むための補助ツールを準備できるかもしれない。

＜講義の感想＞
コンピュータゲーム開発におけるQCDの考え方、アーキテクチャ、開発の自動化、開発プロセスについて、とても興味深く聞くことができました。
特にAgileの適用のポイントを数学的なモデルでご説明頂き、適用が成功するか／失敗するかを決める前提条件を明確に理解することができました。現場に適用する時の方針が見えてきました。
また、ゲームエンジンの上に、ゲームを制作するDSL（ドメイン固有言語）が組み込まれているアーキテクチャは、ソフトウェア開発の未来を見ているようで、エンタプライズ系、組み込み系においても、注目される技術になることを予感できました。今後の展開が楽しみです。
司会者の金山様、貴重な講演をしてくださいました長久様に深く感謝いたします。

司会者：鷲崎氏からの講演への着目点のご案内
昨今システムズエンジニアリングというキーワードを耳にする機会が多い。
伝統的なソフトウェアエンジニアリングの捉え方には最近限界があり、例えばソフトウェアシステム全体における要求であるとか、設計であるとか、或は運用であるとか、ソフトウェアの中に閉じていないシステム全体のとらえ方が今大切になってきている。
また、産業界などでもIEEE26262とか、個別のキーワードであったり規約等の取り組みが最近出てきている。本日はこれらをきちんと俯瞰して、システムズエンジニアリングという全体の位置付けと、その中での個々の技術を深堀していただくための非常に良い機会であると考える。

＜講義の要約＞

◆はじめに
本　　本日はシステムズエンジニアリングとソフトウェアエンジニアリングという観点で話を進めていく。
日本においては、本日話すようなシステムズ工学の書物は少ない状況である。システムズ工学というと制御理論とかの本が多いが、むしろプロセスの議論である。問題とソリューションを反復的に関係つけていくという考え方が、欧米のエンジニアリングの概念であるということを紹介する。またシステムズエンジニアリングに関連する知識ということで、エンタープライズアーキテクチャの話も紹介する。運用と品質という観点から最近取り組んでいるアシュアランスケース（保証ケース）、これはISO26262では安全性というような呼び方がされているが、基本は同じなのでこういった基礎的な話もする。

◆１．システムズエンジニアリングとは
１）９０年代の社会システム
　 社会システム方法論は、９０年代にイギリスで考案されたものです。
IEEE1220 systems engineering processについては、入力から要求分析→要求確認→機能分析→機能検証がありその全体をコントロールするシステム分析と制御である。この部分はマネージメントと言った方がよいかも知れない。そして、設計検証を経由して出力が出る。よって、ソフトウェアの開発プロセスとほとんど同じと思えるが、これがシステムズエンジニアリングのプロセスである。

２）Soft Systems Methodology(ソフトウェアシステム方法論)
IEEE software systems engineering process は所謂Vモデルである。システム分析→システム設計→ソフトウェア要求分析→ソフトウェアデザインそして反対側にTestingが並ぶ。システム全体の分析をして、その後にソフトウェアの分析をする。これはソフトウェアだけのモデルだが、このカウンターパートとしてハードウェアの分析設計もある。

３）２１世紀systems Methodology（システムズエンジニアリングの情報）
・システムエンジニアリングの情報
　 システムズエンジニアリングの基礎的な概念が良く整理されているサイトがある。「 http://se.rdy.jp/incose_thema.html」慶応大学の白坂先生が整理されたものである。本日この後述べるCONOPSの内容も説明されている。

・社会システム
　 社会システムについて分析すると、自然科学と人文科学に分けられる。日本では人材を理系と文系に分けるが、システム方法論の中では自然科学と人文科学という分け方がされている。自然科学は因果関係を分析するが、人文科学は目的関係に着目して統合（インテグレーション）を分析する。そしてソフトウェア開発は人文科学に近いのである。つまり、ソフトウェア開発者は理系の方が多いが、この考え方だと、実際にやっている仕事は文系の仕事だと考えられる。
　 以上からわかることは、社会システムは自然科学と人文科学を統合する必要があるということである。

・システムの階層
　 システムには階層があるが、最近良く目にするSystem of Systems(以降SOSと表す)がある。SOSは、自律したシステムが互いに相互連携して構成される複合システムである。
　 エンタープライズはSOSを更に包含する様なより大規模で複雑なシステムである。人、プロセス、技術、システム、更にそれ以外の資源を複数の組織、地域を跨って相互結合して、ある共通のミッションを実現するような構造体である。

最近は従来のシステムズエンジニアリングよりも更に複雑な問題を解決するための新たな技術が、エンタープライズシステムズエンジニアリングと言われている。よって、企業の為のシステム工学ではなくて、社会全体で相互結合されるようなシステムをどうやって開発していくかと言うことである。　　
　 そう言う意味では最近のネットワーク環境はまさにエンタープライズシステムだと言える。通信事業者が提供するネットワークの上に更にそれを使うアプリケーションサービスロバイダーが居るので、そのプロバイダーのアプリケーションをたくさんの人が使うことによって障害がおきる事例が多く出てきている。これは、どのようなアプリケーションサービスプロバイダーが居て、アプリケーションサービスをエンドユーザがどのように使うかという事を、通信サービスプロバイダーがある程度マネージメントしなければならない時代になったと言う事である。例えば、３０年前頃には通信をNTTが独占していたので、NW全部が計画通りに動いていたわけだが、そんなことは全くできない時代になったと言う事である。
　 そういう意味で、SOSとかエンタープライズとは何かについて我々がイマジネーションを働かせておかないと、システムの品質が保証できない事があるという事である。そのための新しい技術がシステムズエンジニアリングである。これは従来のトラディショナルなシステムズエンジニアリングではなくて、新しい時代のシステムズエンジニアリング、例えばエンタープライズエンジニアリングが必要になったと言う事である。

・５階層のシステム工学
　 この新しいシステムズエンジニアリングの一つの手法として、Hitchins氏らが提唱しているのが「５階層システム工学」である。プロジェクトが作り出すもの、そして事業・エンタープライズが生み出すもの、産業界全体が生み出す物、さらに社会経済的なシステムといった枠組み（階層）が提唱されている。

・外部ループ・内部ループ
Hitchins氏の著書に「外部ループ・内部ループ」の図が提唱されている。問題空間に対してソリューションを設計するのが外部のループ、そのソリューションの中の特定のシステムの設計をするのが内部ループである。そういう意味で新たなSOSに対するシステムズエンジニアリングなどでは、外部ループを中心に考えるということである。
　 つまり、社会経済的な問題を解決するシステムをどのようなシステム群によって解決していくかということである。このシステム群の中にはコントロールできないものがある。例えばネットワークサービスプロバイダとかである。この考え方はオープンイノベーションの考え方ともつながると考えられる。つまり、自分が全てのシステムを完璧に設計できる時代ではないということである。外部パートナーが作ったコンポーネンツをうまく活用して我々の解くべき問題を解決するシステムのアーキテクチャを開発する時代になったと言える。

・発展と変革
　 Hitchins氏らの方法論の中で問題の解き方が提唱されている。まず問題に対してシステム方法論を使って理想的なシステムの解を作る。つまり変革(Revolution)である。一度この解が得られれば、今あるシステムとこの理想的なシステムを使って、問題を起こしていたシステムを置き換える活動が出てくる。でもそのシステムもやがて現実のシステムになっていく。よって次に新たな問題が出てきた時には新たな理想的なシステムとの差を見て改善できる場合は発展（Evolution）させる。それもできなくなった場合にはまた変革がはじまる。こういうようにしてシステム自体も継続的に発展させていくというプロセスがある。これも一種の古いシステムと新しいシステムから構成されるSOSと考えることができる。

・システム科学の類型
　 もうひとつの新しいシステム工学の本の中で、システム科学、複雑系のシステムの科学がある。これとエンタープライズシステムズエンジニアリングと対比させて分析した図がある。組織化された複雑性と組織化できない複雑性、組織化された単純性と組織化できない単純性を類型として示している。　
　 組織化された単純側はニュートン力学の方程式で表すことが可能なものである。対する組織化できない複雑性は、例えば気象などのように式で表すのは難しいが統計学が使える部分である。つまり、バラバラなのでランダム性をうまく使う事で予測できるということである。しかし組織化された複雑性、まさにEnterprise of systems engineeringの領域であるが、組織化されているために、そしてその組織化が均一でないために、そのゆがみで複雑になっていく。しかしながら統計的に平均的な特性の分析はできない。よってこの組織化された複雑性の部分も新しいシステム工学が必要な領域である。

・扱いにくい問題の統治
Enterprise of systems engineeringとは何かと言うと、「技術」と人間を扱うような「非技術」とを統合しようとするものです。これはあたかも自然科学と人文科学の対比に良く似ていて、この両者を統合しようとするものです。古典的システム工学（TSE:Truditional system engineering）は技術の事しか考えていませんでした。
つまりソシオテクニカルなシステムを分析する技術が必要になります。

・分析と合成
　 Rebovich氏らは、分析と合成の表を提唱した。これは自然科学と人文科学の対比に良く似ている。分析は物事の内部に入り込んでいき、システムを分解して分析した後に再結合する。対して合成は全体の振る舞いや性質を分析して説明する。個別に分けることができなく、全体が絡み合った時に不具合が起きる。全体が絡み合うと言う事はどういう事かを合成的にシステム全体を考え、環境とどう相互作用をするかを分析する。これが合成的な考え方である。

４）Enterprise Systems Engineering　（以降、ESEと略記）
・ESEの対象領域
　 Ribovich氏著のESEに関する書籍が出たのは2011年であり、この辺りから議論がされている。例えば「POET：Political、Operational、Economical、Technical」という標語があるが、これは「政策」「運用」「経済状況」がシステムに影響を与えている事を示している。このPOETについてしっかりと考えて戦略的な技術計画が必要であるということである。
　 エンタープライズの統制においては、個人と組織の成功基準のバランスが重要であり、個人の成長とコミュニティをどのようにして統治し確立していくのかというテーマがある。ESEのプロセスとしては組織学習が関係する。ビジネスプロセス、エンタープライズシステムズ、内部プロセスを明確にするということである。

◆２．関連知識（具体的な関連分野の知識）
CONOPSとは、Concept of Operationと言うことで、ITIL V3においても記載されている。最近標準化された新しい要求工学の規格であるITIL V3 ISO/IEC29148の中でシステム要求の開発プロセスを紹介する。
　 数年前に遭遇したスパコンのトラブルの時に作った運用要求の記述手法を紹介する。
　 エンタープライズアーキテクチャのフレームワークとしてTOGAF（The Open Group Architecture Framework）を紹介する。

１）運用概念の事例 ConOps
・システム工学の概念設計とCONOPS(Concept of Operation)
　 システム工学の概念の「概念構成要素」と「問」と「説明」について表にしたものを示す。システム工学の教科書で、A.Kossiakoff氏らによるSystem Engineering Principles and Practis,2011年版からの抜粋である。
　 Why:「なぜシステムを運用せねばならないのか？」が運用要求、What/How mach:「何を運用するのか？」が機能・性能要求、How/Who:「システムの集合体がどのように運用されるか」が運用概念、Where/When:「どこでこのシステムは運用されるのか？」が運用コンテクストである。
この中で、運用概念（How/Who）において、特定のシステムの運用概念がCONOPSである。ここで注目すべき事項は、SOSに対する運用概念ではなく、特定のシステムの運用概念であるという事である。
　 CONOPS自体は古い概念であり。1980年代頃から提唱されている。ただし、日本では注目されてこなかった経緯がある。

・CONOPSの構成要素
　 構成要素は以下である。
　 目的すなわちなぜこのシステムが必要なのか、他のシステムとの関係、情報の入力源と出力先、それ以外の関係や制約の要素を持つ。
　 CONOPSの簡単な説明にはデーターフローダイアグラムが適する。このフローの最上位レベル、つまり、システムと外部環境との相互作用を明示した図であり、これがCONOPSの構成要素と対応している。

・Concept of Operations(CONOPS)文書
 CONOPSは最終的には成果物である。作る時期は、要求定義の初期に作成し、システムがどこでどのように使われるのか、何をなぜするのかを書くのだが、「なぜ」は目的なのでミッション定義がここに書かれる。つまり、重要な最上位の性能要求や目的を明らかにするものである。

・プロダクトラインに対するCONOPS
　 プロダクトラインについてもCONOPSが記述できる。ここで、プロダクトラインは何かと言うと特定のシステムではなく製品系列だが、それに対するCONOPSの拡張も提案されている。これについてはカーネギーメロン大学のSEIのページに公開されている。

（http://resources.sei.cmu.edu/asset_files/TechnicalReport/1999_005_001_16745.pdf）
SEIにおいては、「どのように使われるのか」「プロダクトラインに参加するのは誰か、組織、活動はどんなものが有るか」「プロダクトラインの運用がどういう順序で定義されているかについて運用モデルのプロセスは」について記述すべきであると定義されている。

・CONOPS文書の位置付け例
　 CONOPS文書の位置付けの例の図がカーネギーメロン大学のSEIのページで公開されている。
（http://www.sei.cmu.edu/productlines/ppl/concept_of_operations.html）
Product LineのCONOPSから、Production Plansへ、一方はBusiness Case、Scope、Requirementがつながっている。
　 この体系でCONOPSの位置から、そもそもこのProduct Lineのビジネスシナリオがどうなっているか及び生産計画を説明するための文書であることがわかる。

・プロダクトラインのためのCONOPS文書の構成例
　 CONOPS文書のテンプレートを示す。
（http://www.sei.cmu.edu/productlines/ppl/concept_of_operations.html）
章立ては「概要」「アプローチ」「背景」「組織的考慮事項」「技術的考慮事項」「推奨事項」「Q&A等の付録」となっている。

・CONOPS文書の内容例
実際のCONOPS文書に書くべき内容を説明したものが下記にある。Nicole Robertsらにより公開されている。
（http://www.dtic.mil/ndia/2008systems/7191roberts.pdf　P16参照）
これは、Product Lineではなくて、システム一般に対するCONOPS文書のテンプレートとして使えるものである。システムが置かれる外部環境を明確にする事と、システムの目的、問題定義等を明らかにするものである。

・CONOPSの定義対象
CONOPSでよく書かれている内容が下記に示されている。
（http://www.dtic.mil/ndia/2008systems/7191roberts.pdf　P11参照）
システムの利用シナリオ、環境とシステムの相互作用、システム自体が多くを占め、システムの詳細については多くは書かれていない。つまり、システム利用とシステムを取り巻く環境及びシステム事態の高水準の機能を記述したものがCONOPSである事がわかる。

・CONOPSの活用工程
CONOPSをどういう工程で利用するかが下記に示されている。
（http://www.dtic.mil/ndia/2008systems/7191roberts.pdf　P11参照）
要件定義、システム設計、試験計画で利用されている事がわかる。

２）要求工学標準IEEE29148におけるシステム要求
・ISO/IEC/IEEE 29148:2011
　 IEEE29148が捉える要求が下記に示されている。
　 （ http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171）
　 この中にもCONOPSが入っている。最初に作るのは「システム要求」ではなくて「ステークホルダ要求」である。つまりお客様の要求を定義する。この場合、エンドユーザは不特定多数なので把握できないという意見が必ず出るが、エンドユーザの代弁者の力を借りてステークホルダの要求を定義する事は可能である。
次にシステム要求、ステークホルダの要求を解決するためのシステムの要求を明らかにする。次にこれに沿ってソフトウェアの要求を開発する。この中で、システムの運用については、お客様がシステムをどう使うかを明らかにしておく必要がある。ここでは、CONOPSは二つあり、一つは「組織の観点での運用概念」、もう一つは「システムの概念での運用概念」である。組織の観点とは、ビジネスプロセスである。システムだけではなくそれを含んで業務全体をどのようにオペレーションするのかが組織の観点のCONOPSである。

・ステークホルダ要求（StRS）の構成例
「ビジネスマネジメント要求」「ビジネス運用要求」「ユーザ要求」「提案システムの概念」の章でCONOPSが出てくる。ソフトウェアエンジニアリングの観点から言うと、CONOPSはステークホルダ要求のドキュメントの中に含まれる事がわかる。

・システム要求の構成例
システムのコンテキスト、ユーザ要求が書かれているが、この中にはITIL V3 29148にはCONOPSは出てこない。これは、ステークホルダ要求でCONOPSが明確になっているので、その次のシステム要求の中ではCONOPSは省略されている事がわかる。

３）システム運用知識の抽出方法（実例からの考察）
　 数年前に発生したスパコントラブル事例からの考察をした。
運用者にヒヤリングしたところ、運用マニュアルが無かった。そこで、現場の運用者でも作れるような運用知識を再構築する事となった。

・運用の限界
　 問題が発生した場合にその証拠を保存していない場合が多い。発生後しばらくしてから異常に気付く事が運用上のトラブルである。例えば、昨今のクラウドサービスのデータベース紛失の問題は、無くした時には気が付かず、お客様が使おうとした時に使えないということになる。この場合何があったかの証跡が残っていなければ分析もできない。これは運用中だが、運用停止の場合には何か想定外の事が起きるという可能性の分析もできない。これは運用手順が無いからである。運用手順があればその手順上のリスクの分析が可能である。つまり、手順が無い場合は、全て都合良くやった事になっているわけである。
次に運用組織の文化については、情報隠蔽している組織が新聞で暴露されると、そんな馬鹿なことをやっているからと批判するが、自分自身の胸に手を当てると自分もそうなっている可能性がある。説明責任も曖昧である。日本では説明責任を果たしたと言われるのはテレビの前で社長が頭を下げた時だが、それは説明にはなっていない。つまりこういった状況を明確にするには、様々な主体があるが関連する対象との間の依存関係を定義しておく必要がある。本来定義すべきことができていないからこういった問題が発生する事となるわけである。

・運用前の要求品質の確保とその記載方法
運用要求に対し誰がどういう状況の時に何を定義してしその手順を実施するのか、その時の入力情報と出力情報、そしてそれを実施した時の結果はどこに報告するのか。また、事後状況としてどういう状況が成立すれば良いかについて表で書きませんかという事を提案した。これについては現場の保守者に同意していただき進めることができた。

・運用要求定義票と運用要求の抽出法
（http://www4.atpages.jp/sigksn/conf07/SIG-KSN
（http://www4.atpages.jp/sigksn/conf07/SIG-KSN-007-02.pdf　P3参照）
一部「事前状況」「運用規制」「事後状況」「役割分担」についてはITILのガイドブックには記載が無く、新たに追記した。
表にした事により定義の抜けが明確になる。よって、これを記載する事で可視化ができ抜けを防ぐ議論ができる事となる。

・運用活動知識の構成と運用活動定義票の付随資料例
運用活動定義表を記述すれば全てかというと、これは一部である。特定のタスクは定義表一枚一枚に記載するが、その相互のつながりがわからない。よって、定義表を書けばそれを使う手順、シナリオの必要性が見えてくる。
更に、この活動の必要性の根拠としてのドキュメントが必要となる。そこで規約を作る事となる。これら、付随資料を整理すると「体制」「管理台帳」「ルール」「システム構成」「書類」を大項目とした付随資料のTreeができる。つまり、運用活動定義票を作ると、これに紐づいて抜けがある事に気が付くので芋づる式にドキュメントがそろっていく。
恐ろしい事にこういうものが無くても運用できていたと言うことはどういうことかというと、問題がない時はいいがトラブルが有ったら対処できないのが現実である。よって、この定義表は簡単なものでは有るが、埋めていけばいいので文章を書かなくて良いし、運用知識の可視化ができた。従来は経験がある者にしか運用ができなかった事がわかる。

４）アーキテクチャフレームワーク事例 TOGAF（The Open Group Architecture Framework）
・主なEAフレームワーク
 Enterprise Architecture(以降 EAと記述)は、1987年にIBMのシステムジャーナルにおいてZachmanが提唱している。これが世界を変えた論文である。単に解説的な論文であったが、整理が如何に大切かという事である。

・Zachmanフレームワーク
（http://en.wikipedia.org/wiki/Zachman_Framework）
単なる表であるが非常にわかりやすく定義されている。この時点ですでに「運用」も入っていた。これがベースとなって、複数の企業に存在するシステムを最適配置し、また最適な計画を立てる仕組みがEAである。つまり、EAはSOSなのである。大企業だとその企業の中にシステムが100以上あるのが普通で1000のシステムがある場合もある。その場合、戦略的な計画が無ければマネージメントは不可能である。つまりこの戦略計画がシステム設計する以上に非常に重要である事は明白である。

・変換分析
現状からあるべき姿へ発展させるためにはどうしたら良いか。EAの基本は現状の理解とあるべき姿を明示して、このギャップを埋める活動がEAによる開発である。
Hitchinsらの提唱の説明で述べたように、現状のシステムをあるべき姿のシステムで置き換えるという考え方である。

・TOGAFの主要なアクタ関係
TOGAFはThe Open Group Architecture Frameworkである。Open GroupはLinuxの標準化を中心に活動しているグループである。主要なアクターは、ステークホルダ、スポンサー、アーキテクチャ委員会、EAチーム、実装プロジェクトであり、役割を持った複数の人達の間の関係が整理されている。よって、TOGAFは複数のシステムを最適設計していくための仕組みなので、アーキテクチャを整理する上で複数システムを前提にして総合的な最適性を追求するものである。

・TOGAFのステークホルダ
TOGAFのアプローチは必然的に社会技術的なアプローチとなるので関連する組織は多く有る。よって、単純になるからと言って、システムのアーキテクチャ設計の技法と解釈するとうまくいかない。なぜならアーキテクチャビジョンをまず作り、そのビジョン段階でビジネスシナリオを検討する。つまり、このシステムを実現するもしくは品質良く作るだけが目的ではないという事である。

・ADM（Architecture Development Method）フェーズと技法の関係
（https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605　P68）
TOGAFに沿った開発手法は初期からSOSを対象にしている。次に変革即応性評価つまりケイパビリティ評価である。これはその企業組織を改革したいと思っているかということである。システム開発のケイパビリティも同じだが、能力のない者にはシステムは作れない。

よって、プロジェクトを成功させる秘訣は一つしか無い。目的を実現できる能力を持った者を集める事である。そうでないと途中で放棄される。もう一つのやり方は、自分の組織だけでやるのであれば、そのメンバーの能力に応じた目的だけを定義する事である。こういう議論を開発現場ですると夢が無いと言われるが、実際は非現実的な夢を見れば失敗するのである。では、自分達の能力を超えた夢を達成するために何をしたら良いかと言えば能力を持った外部パートナーと協業するべきである。

こういった考慮をするために最初に作るのはビジネスアーキテクチャである。ビジネスアーキテクチャとは、ゴールの定義とビジネスプロセスの定義である。これはまさにCONOPSでやるところである。つまり、運用回りの明確化、情報システムのアーキテクチャ、テクノロジーアーキテクチャ（情報技術基盤）の設計である。情報システムアーキテクチャの中で、データアーキテクチャとアプリケーションアーキテクチャを定義する。次に、機会とソリューションとの対応でどういう可能性があるか分析する。これがわかるとこの中でトランジションアーキテクチャが明確になる。変換分析では、現状から有るべき姿をどう実現するかを分析する。ここでケイパビリティ計画が必要となる。つまり、実現可能なリソースがあるか、さらに配置はどうするかということである。

次に移行計画を作成し、実装ガバナンスへ入り、実際のシステム開発に入る。最後にアーキテクチャ変更管理を実施するがここが最重要である。通常システムを作ったら終わりと考えていないだろうか。作り上げた次の段階から運用が始まるわけで、システムのゴールを定義したがこの定義したゴールがシステムの運用によって、本当に達成されたかどうかをモニタリングする必要がある。

この時に実装されたシステムが目的を達成できていなかったら、二つの場合がある。一つはシステムの実装が誤っている。二つ目は目的を間違えている。つまりビジネス環境の中でこういう目的を立ててシステムを作ったが、その目的は仮説でしかない。ビジネスが変化していれば、あるいはビジネスの捉え方を誤っていれば目的が正しく達成できない事が有る。その時は目的を変える必要が有る。つまり、新たな目的のためにアーキテクチャビジョンを再設計する必要が有る。よって、TOGAFでもHitchins氏らの提唱の紹介で説明したような外部ループがここで回っているという事である。

TOGAFはアーキテクチャとかソリューションをしっかりと定義するので、それをビルディングブロックとしてリポジトリに入れておき再利用するようにするという仕組みを提案している。よって、ZachmanのEAと比較するとかなりにプロセス寄りになっていることがわかる。具体的にどのようにアーキテクチャを開発するのかという方法がADMである。これら各フェーズが繰り返されるわけである。

・TOGAFのエンタープライズ連続体
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P75)
アーキテクチャ、ソリューション、実装があり、アーキテクチャ連続体は、固有なものから汎用のものまでが連続的に構成されている。これは、個別の知識から汎用の知識までが連続的に発展していくという考え方である。こういうコンセプトが欧米にはあり、よって欧米は標準化が重要との意識が強い事がわかる。

・ケイパビリティとアーキテクチャ
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P76)
管理、構成、要素、成果物のカテゴリの各々の中身をうまく組み合わせて、全体をできるだけ標準的に一貫性がある形で設計していくという事が、TOGAFの考え方である。

・TOGAFアーキテクチャ要求仕様の構成と開発工程
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P60)
基本項目としてゴールが有り、重要なものとしてアーキテクチャの原則方針、アーキテクチャを設計する場合に守らねばならない方式がある。
この枠組みは日本人にとっては難しい。実際、要件定義、設計の基本原則が無いからこそ人によって視点がずれていき問題を起こす。海外ではこういったアーキテクチャの構成を大切にしている。システム個別で設計してはバラバラになってしまうような所を中核として、これだけは絶対に守らなければならない所をまず先に書くという事である。

・FEAの概要（紹介のみ）
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P64)
Federal Enterprise Architectureを紹介する。

・Gartnerフレームワークの工程（紹介のみ）
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P64)

・アーキテクチャフレームワークの比較
(https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16195&folder_id=4605  P64)
各フレームワークの特徴をフレームワークで比較したものである。用語体系が突出しているのがZachmanであり、TOFAFのV9は全体を平均的にカバーしている。Gartnerのモデルは、ビジネス価値と参照モデルに重点を置いている事がわかる。

◆３．保証ケースによる品質の確認手段
保証ケースによりどのように品質の保証ができるかについて研究結果を説明する。

１）非機能要求グレードと保証ケース
　 保証ケースによって、どのようにソフトウェア品質を保証できるかについて説明する。

・保証ケース（D-Case）の例
（https://acs.is.nagoya-u.ac.jp/index.php?module=User&action=DownloadFile&id=6797&file_id=16673&folder_id=4806　P19）
ゴール ストラクチャリング ローテーションと言い、イギリスのキムケリー氏が提唱した手法である。まず、図形の説明であるが、四角はゴール、丸四角は前提、菱形は戦略、丸は証拠である。ゴールが成立する事を証拠で説明するという事である。しかしながら、ゴールが直接説明できない事があるので、戦略により上位の大きなゴールを下位の複数のサブゴールに分解して、そのサブゴールであれば証拠があるので成立する、という事を説明している。つまり、証拠を使って主張が客観的に論理的に説明できるかを議論するための図が保証ケースである。
　 なぜ、「主張」「戦略」「証拠」の３つに説明できるかを示すために、コンテクスト（前提）がある。この前提条件の元でこの上位の主張は３つに分解できるという事である。

・D-Caseの５つの役割
保証ケースの事を、Dependability Caseと呼んでいる。この役割は以下の四つの要素であるので、お客様との間で合意を形成する場合に便利に使える。(1)主張を明示的に書ける、(2)証拠を明示的に定義できる、(3)主張の前提条件を明示できる、(4)物証により主張を論理的に説明できる、(5)標準的な表記法なので客観的な説明が可能である。

・D-Case実装評価研究会：４回開催、述べ130名が出席（http://www.dcase.jp）
　 D-Caseは初心者には書きにくい。初心者でも書けるようにするに、初心者の目線での習熟評価のため「実証評価研究会」を立ち上げた。この研究会において参加者からの意見をいただき普及活動を実施している。これは文部科学省の研究開発プロジェクトであるが、2014年3月で終了となる。よって今後は次の書籍を参考にすると良い。「主張と証拠　2013/4 山本修一郎著」、「実践D-Case 2013/3 松野裕・山本修一郎著」

・D-Case活用事例
（http://dcase.jp/example.html）
保証ケースであるが、どの位使われつつ有るのかをしめしたものがこの事例である。自動車のエンジン制御、衛星制御、ロボット制御、金融パッケージミドル等の動作保証を客観的に説明するために用いられている。

・安全性ケースを作成する上での課題
まず、ゴールには何を書いたら良いか。日本人には馴染まない。なぜかと言うと、日本の教育は問題に起因した解き方しか教えないし、作文も感想文を書かされるのみ。よって、自分の意志を持って何かを主張するという作文をしていないからである。そこで戦略からいくつのサブゴールに分解すれば良いのか、また証拠も残してないので何を書くべきかわからない。つまり、展開幅とかどこまで深度を求めるかもわからない。また、各要素の間の関係も線で結んだものの、その正否が判断できない。

・議論分解パターンの構成
保証ケースを書くのに、初心者でもわかるようにしたものが議論展開パターンである。これを分類するパターンとして、「説明対象システム」「説明する議論の構造」「どういう証拠を使うのか」「正しい事が確認された再利用時の確認のし方」がある。この４つのカテゴリーに分けてパターンを整理する事を提唱している。

・議論分解パターンの分類
議論分解パターンを用いて、保証ケースを作成する上での分解問題の種類と、それに適用できる保証ケースの種類を対応付けることができるので、保証ケースの分解方針と解決策の再利用が期待できる。

・パターン事例
議論のパターンをまとめると５０を超えた。これだけの事例があればほとんどの問題は記述可能であるし、記述対象毎にパターンをつくったものを見ると、記述モデルの構造が決まっているのでその構造があればそれに対して保証ケースを書けば良い事が解ってきた。更に記述法が増えれば新しい記述パターンを追加すれば良い事がわかってきた。よって、さらにパターンを拡充しようとしている。

・パターンの記述例
2014年3月に予定されているパターンの国際会議AsianPLoP 2014に関連して、パターンの記述実態をスライドとして追加した。パターン毎に情報を記入しており、なぜそのパターンが必要なのかという状況、解決策が配置される前提条件等を持ってパターン化した。これに基づいて記載したパターン記述例を紹介する。分解問題、分解状況、解決策、例えば複雑な問題に対してD-Caseを作る必要が有る。

分解状況はアーキテクチャが明確になっているときである。アーキテクチャが明確になっていない場合はアーキテクチャ分解パターンは使えない。解決策はシステムのアーキテクチャが二つのサブシステムによって構成されているとすると、サブシステム間に相互作用が有る。その場合、システムが保証されると説明されるためには、少なくともサブシステムの両者が保証されていると説明されていること、更に、サブシステム間の相互作用が保証されているという事が説明できる事が条件である。そのときの前提はシステムアーキテクチャの定義である。

また、各説明要素はand条件である。なぜかと言うとシステムの安全性や妥当性を保証するためのものだからである。つまり、条件が成立する時もしない時もシステムは安全でなければならないからである。

条件選択に対する信頼性も用意されている。矛盾を解決する時のパターン、代替案と比較するパターン、参照モデルのパターン、DEOSプロセス等が用意されている。なお、DEOSプロジェクトとは、システムが通常運用されている時も安全で、システムが変革対応する時も安全、更にシステムが障害を起こした時も迅速対応できる、つまりシステムが全体で信頼できるという考え方である。よって、DEOSプロセスは運用を前提としたような考え方になっている。

IPAが数年前に非機能要求のグレード表を作ったが、その非機能要求に応じた形で、確かにこのサービスは非機能要求を満たしているという事を示すというためのパターンである。 Availability（可用性）をシステムは達成していますという事をまず主張する。次にAvailabilityの複数の各品質特性を達成している。その品質特性を達成している事を試すために、特性評価指標が定義されており、その特性表か指標が達成されている事が主張になり、その主張を満たすための情報が証拠になる。達成結果つまりテスト結果証拠文書等がエビデンスになる。

・Dimensions of Assurance Integrity Level（保証の一貫性レベル）
どの程度まで保証ケースによってシステムの信頼性を保証したのか、そしてその次元の考慮である。議論の網羅性、エビデンスの信頼度、証拠の信頼性、前提条件の完全性と言った次元が必要である。よって、保証ケースの研究課題であげた、「書かれた保証ケースの妥当性」の吟味がいるという事である。

・欠陥分析手法と安全性ケース
「保証ケースは昔からやってきた事の繰り返しではないのか」との意見を良く聞くが、回答はノーである。従来は欠陥分析、つまり「ここへこういう対策をする」で終わっているはずである。保証ケースは安全性を保証する手法なので欠陥分析手法によって明らかになった問題原因、それに対する対策案、システムの中に組み込まれていてその証拠はここに有るというのを説明するのが安全性ケースである。具体的には、欠陥がどこに有るかと見て２００個並んだとすると、その１００の欠陥に対して安全対策がそのシステムの中で実現していますという安全を示す証拠を示すのが安全性ケースである。

２）ISO26262と安全性ケース
・ISO26262による安全性ケース
ISO26262は10分冊有り、その中のPart10に安全性ケースをしっかりと書くべきという事が述べられていて、Goal Structuring Notationつまり、今まで保証ケースの例で書いてきたものである。これが安全性ケースを記述する手法として記載されている。また、重要な点は、プロダクトについての議論と、プロセスについての議論をするべきであるという事である。プロダクト面だけで安全であるという事は不十分であり、製造プロセスや運用プロセスも安全であるという事を確認すべきであり、それを保証するドキュメントをつくるべきである。
システムの安全性を保証するために、安全性ケースを書くとシステムのリスクが発見できたとすると、システムの設計を変更する、それに応じて安全性ケースも更に変更する。このサイクルが重要である。

・ISO26262の概要
ハード製品開発とソフトレベル製品開発が有り、その前にシステムレベル製品開発がある。その前の段階において、機能安全性の管理が必須である。

３）非機能要求グレードと保証ケース
・名古屋大学ポータルサイトのNFR(非要求)グレード
　 信頼性特性のカテゴリとして「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「環境・エコロジー」が定義されており、各々に特性仕様項目が有り、その指標の合計は１６２項目がある。

・主張の定量評価尺度定義法
「非機能特性を達成している」という主張を各特性項目毎に分解して説明からその証拠、つまり特性指標の達成報告までを説明するための一つの定義多ターンである。

４）O-DA標準の概説（TOGAFのdependability拡張としてのO-DA技術標準）
TOGAFのADMを損来の高いものにする取り組みをしており、20131年8月に国際標準でTOGAFが認められた。その内容について紹介する。

・O-DA（安全・高信頼性検証国際標準）を発表　8/7日(米国時間6日)
(http://www.opengroup.or.jp/pdf/pressreleaseFinal_Update20130806.pdf)
(http://www.opengroup.or.jp/pdf/nikkeisangyo20130808_O-DA.pdf)
TOGAFについて日本の機関が貢献したのはこれが最初の標準である。

・O-DA標準の構成
「定義」は保証・高保証アーキテクチャ・保証ケース、次に「O-DAフレームワーク」は障害対応サイクル・変化対応サイクル・通常運用サイクル・保証ケースの説明がある。基本的には用語の説明と形式手法の説明である。これは証拠として使う。証明がされている事によってシステムは信頼できるという事が証明可能となるという事である。

・Open Dependability through Assuredness Framework（変化対応サイクル）
O-DAのサイクルには、要求プロセス、アーキテクチャ設計・開発がある。その時にそれぞれのプロセスが信頼できるという事をケースとして保証する。障害対応サイクルでは、問題検知がされたら原因究明し迅速対応する。目的環境変化対応では、ビジネス環境が変わると目的がそぐわなくなるので、新たに要求プロセスを再度回す事に成る。これも二重サイクルでは有るが、一つのシステムに対してこのDEOSのプロセスが有るという事である。前述したHitchins氏らの提唱した二重サイクルとは異なる。Hitchins氏らのサイクルは、内部サイクルが特定のシステムのサイクルである。でもよく見るとこのサイクルは運用を前提にしているので、この運用の中で複数のシステムが運用されている可能性もある。すなわち、システム自体がOpen化されているとすると、このモデルはSOSに対して適用すればHitchins氏らのモデルに近くなるとの見方も有る。

・高信頼性（Assuredness）の言葉の意味・定義
アーキテクチャの実装すべき要求が満たされている。その事をあるレベルの証拠によって定義しているという事について、ステークホルダが合意していますという事がAssurednessである。よって、ステークホルダが認めた要求をアーキテクチャが達成しているという証拠があるという事である。つまりステークホルダが合意した要求になっているという事である。

・高保証アーキテクチャの言葉の意味・定義
Assurableな要求を達成したアーキテクチャーが高保証アーキテクチャである。そのために、保証ケースを使うという事が規格の中で述べられている。

・説明責任の言葉の意味・定義
サービスを継続的に提供できてかつ説明責任を遂行できる能力がディペンダビリティである。説明責任能力がある事によって説明責任を定義している。説明責任が信頼性の構成要素に成っているという定義である。

・保証内容メタモデルの言葉の意味・定義
要求が拡張されており、証拠付き要求という概念が必要になっている。つまり、要求は単独で定義すれば良いわけではなくなっており、信頼性の有る要求、つまり達成されたという証拠のついた要求が必要である。通常の開発では要件定義を最初にやりその者は終われば居なくなるが、システム開発が終わり運用中に確かにその要求は保証されている、達成されているという証拠が必要である。つまりこの証拠は運用されないと残らないわけである。また運用中にこの要求が達成されなくなる事があるとも言える。よって、要求は常に存在しているという定義に拡張されているわけである。開発中から運用中を含め常に監視対象になっているという事である。これがないと要求が達成されなくなったという事を確認できないわけである。

・高信頼ADMの概要
O-DAでは、前に述べたADM（アーキテクチャビジョンからアーキテクチャ変更管理まで）が全て高信頼化される必要があるという事を述べている。
これをどう実現するかというと、アーキテクチャビジョンでは「ディペンダビリティのスコープの定義」「主張の定量的評価尺度の定義」「保証ケースの作成能力」等を定義する。ビジネスアーキテクチャ、情報システムアーキテクチャ、技術アーキテクチャ、ソリューションの４つを保証ケースを使って、確かにそのアーキテクチャが妥当であるという事を確認する事が求められるようになった。

運用についても運用管理の保証ケースを作る事が明記されている。よって、運用している時もこの運用は問題なく実行されているという証拠を残す必要があるという事である。つまり、運用プロセスが定義されている事が条件なので、運用要求記述票の説明で述べたように、運用活動とは何か、運用活動におけるリスクとは何かを明確に定義して、運用リスクを解消する対策がとられているという事を確認する必要がある。これが達成できれば、保証ケースが作成できる事になる。そのために、ITILについての保証ケースを作る必要がある。

５）ITILと保証ケース
ITILに対する保証ケースを使った品質保証の仕組みを説明する。

・運用活動の妥当性確認例
現状のITILは非常に拡張されていて運用だけではない。サービス戦略、設計、移行、運用、サービス改善まで含んでいる。これはTOGAFとも非常に似てきている。開発と改善のサイクルが絶対に必要だという事がわかる。なぜかというと、TOGAFにも有るしITILにも有るからである。

・ITサービス継続性管理の活動
サービス設計の中に記述されている「ITサービス継続性管理活動」が有り、この内容を使いどのように妥当性を確認するのかを紹介する。
　 ４段階に整理され各々の段階毎の活動内容を示す。段階とは、「開始」「要求と戦略」「導入」「継続的な運用」である。この各段階に対して全６５項目の具体的な活動項目が決まっている。

・開始段階のチェックリストの例
各段階の活動項目全てを満たす必要があるので、チェックリストができる。各活動項目毎にどういう状況が達成される必要が有るのかという事を明らかにするとチェックリストが作成できる。

・ITサービス継続性管理に対する開始段階に対するD-Case
各活動項目のチェックリストに対してサービス継続性管理を、先に述べた「主張」「前提」「戦略」「証拠」の４段階に分解するパターンができる。このようなパターン化をするとシステマティックに運用プロセスの妥当性評価ができる事が解る。

６）テストと保証ケース
（http://www4.atpages.jp/sigksn/conf13/SIG-KSN-013-04.pdf）
テストの十分性、どこまでテストすれば良いのかに対して保証ケースが適用できるかについて説明する。

・D-Caseとテストの関係
全てのプロセスの妥当性を保証しようとすると、要件定義や設計だけではなくて製造やテストもその工程の十分性の確認方法が問題になる。

・テスト十分性に対する保証ケース作成手順
テスト項目だけを見ても、そのテストが妥当かの判断はできない。どこまで遡る必要が有るかというと、要求である。つまり、要求に対してこのテスト項目で本当に要求がシステムによって実現されたかを確認できるかを確認する必要がある。すなわち、システムが問題なく動くという事を確認する事ではなくて、システムが要求を実現している事を確認する必要が有る。

・要求記述表
（ http://www.bcm.co.jp/site/youkyu/youkyu108.html）
要求仕様に着目して要求記述表を記述しておく事が大切である。この要求記述表はISO29148の記述項目を使っている。
要求記述表は、通常１行しか書かない場合が多いが、ISO29148で要求されているのは、「システムの主体は誰か」「何を対象にシステムが実行されるのか」「実行の契機」である。つまり何を対象にその要求は実行されるか、その要求が実行される契機は何かという事を書けないとテストはできない。機能として、状態変化とかイベントの入力からどういう出力を出すかという事を分析する事でありこれが正確な要求分析表である。

・要求逸脱分析表
この要求が記述できたら、次に要求の欠陥が発生するのはどこだとの事に着目して要求逸脱分析をする。これにより作られるのが例外系のテスト項目である。

パラメータは要求記述表の各記述項目のそれぞれに対して、HAZOP(Hazard and Operability Study)のガイドワード（逸脱の条件）を用いて、必要とされる以外の情報が入る可能性があるとか、部分的で完全ではないとかの逸脱の条件を分析して記載する。その逸脱の重要性をリストアップして重大な事項についてはテストをする。それ以外はテストしない。なぜかというと、システマチックに網羅的にあげる事ができるようになるため、この条件網羅の結果は非常に多数となる。その結果多数のためにテストができなくなるからである。

・テスト十分性確認 D-Case(一般形)
（ http://www.bcm.co.jp/site/youkyu/youkyu108.html）
トップレベルのテスト十分性のD-Caseのテンプレートを示す。まずは要求毎にテストを実施する。次に正常系・例外系を分類する。異常系要求逸脱表で挙げた物を全て並べていく。

７）具体例
・要求仕様の例
 　要求仕様の例として、ビデオレンタル会員がビデオを借りる場合を例としてあげる。通常正常系しか記述されていない。これについてテスト項目を考えてみる。

・要求記述表の例
この要求を記述表に書くと要求仕様には記載されていない、条件・機能・制約の明確化が可能となる。こういう用にして考慮漏れが無いかを洗い出す。

・要求逸脱分析表の例と・テスト十分性確認 D-Case(具体例)
そもそも、システムが起動できないとかメニュー以外の画面が表示された場合とかの逸脱条件の洗い出しが可能となる。条件項目が挙がったら、お客様と議論をして必要な条件を選択し合意すれば良い。これで必要なテスト項目の決定ができる。

◆Q＆A
Q1_ITILと保証ケースの説明で、ITサービスについての分析をしてそこからD-Caseが導出される部分について、D-Caseとその前の分析のつながりが解らない。D-Caseのゴールはどういう流れで出てきたのか。

A1_段階毎に分類した活動の大分類があるが、まず活動内容に分解する。その活動内容の結果全てが最下段の証跡になる。同様に全ての段階毎の活動結果を証跡として並べた物であり、この条件全てを満たせば、サービスの継続性が維持できる事を証明できるということである。

Q2_システムのある観点で分解して、andで満たしていくという考え方のみだと、Open systemまでの保証はできるが、Enterpriseになると更に複雑な相関関係も考慮が必要なので、そこまではカバーできないように考えるがいかがか。冒頭のシステムの階層の説明で、「Enterprise」「System of systems」「System」の階層が示されているが、SOSまでは、システムとシステムの相関であるので個々のシステムも満足、つまりdependableかどうか確かめていけば全体としてもdependableだという考え方と理解した。しかし、Enterpriseは更に複雑との理解だがいかがか。

A2_結局は階層性が有ると言う事なので、Enterpriseの中に複数のSOSがある事である。環境とも相互作用があるし、システムと環境の作用も有る。環境の中自体はわからないとしても、環境とシステムの間の関係の分析はある程度できるし、それを分析しておかないと想定外の事が起きた時にどうするかがわからない。リスクマネージメントの根本はシステムが想定した条件の下ではただしく動作する事が確認できる。想定している範囲で条件からの逸脱が有っても対処している。つまり例外入力に対して対応ができる。それは例外処理が有るからである。では最後に何が残るかというと、想定した例外以外の何かが起きるCaseでそれは書けない。では起きた時にどうするかというと運用プロセスで対応する。よって、それが最後の歯止めになる。運用プロセスにおいてシステムが困難な状況に陥ったら、「このようにしてここまでは何とかして継続性を保証します」と記載されていれば、その訓練はできる。「何が起きるか解らないが何か重大な異常が起きた時にはこのようにしてシステムの継続性を保証します。」という証拠は作成可能である。よって、このようにすればEnterprise系のシステムでもAssurance Caseを適用できる。

Q3_システムエンジニアリングとして運用についてお客様に対し契約をアプローチするが、契約に結びつかない事が多い。特にお客様側が想定していない状況を条件としても交渉が難しい状況である。よってこういう運用についての提案は誰が出すかが重要と考える。ステークホルダを誤ると突然否定される恐れもある。よってこういった取り組みはお客様側と共に検討していく以外無いのか。

A3_その通りである。正しいお客を見つける必要が有る。間違ったお客様がステークホルダだと思い込む場合もある。逆に言えば、間違っていると判断した場合には適切なステークホルダを探しに行く必要が有る。

Q4_Dependability Caseはあくまでも証拠があるという事であって、運用するシステムは正しいとか安全だと言う保証ではないと考えて良いのか。つまり現実の運用の中で確かに安全であるとかDependableであるという事は、D-caseなどに照らして判断して、間違いが有れば見直して行くという事か。もしも前提が間違っている場合は、Caseの見直しもあり得るのか。

A4_その通りである。システムが安全だという説明ドキュメントがAssurance Caseである。説明の中にはシステムが安全だという証拠がある。という事である。つまり、なぜ安全だと言えるのかという事を説明する文書である。前提が間違っていればCaseを見直す。必要な議論が抜けている場合も有るし、必要な証拠がそろっていない場合も有る。最悪の場合証拠が偽造の場合もある。

Q5_証拠能力の内容で、SNSとかIDサービスでは「如何に受けているか」とか「如何に沢山の人が使っているか」という尺度が、品質が良いという尺度よりもビジネス要件として重要である。これを本日の手法で検証しようとした場合、アクセス数をエビデンスとして使うべきと考えるが、企画の段階で取れるアクセス数と、サービス立ち上げ後の階で把握できるアクセス数との間では、ユーザの層の違いとかで中身が異なる。その場合証拠として正しいかどうかが危ういと見られる恐れが有る。このように同じ手法で把握したとしか主張できない場合もある。その場合は企画の段階で何を正とするかを合意した上で進める必要があるという事か。

A5_そうならないように企画段階でしっかりとAssurance Caseを書くという事である。つまり、アクセス数がこの手法によって収集されますと定義する事である。
　 アクセス数の把握条件が異なっていた場合でも、そのアクセス数によって確かめられる上位の主張が正しいのかどうかという議論ができる。実装する前にそういうAssurance Caseを書く事により、この主張はこのアクセス数によって保証できるのかどうかを事前に議論した方が良い。アクセス数を収集できれば良いという考えだと、どのような実現手段でも良いという事である。つまり、実装された時のアクセス数が本来とるべきアクセス数と乖離していたという事を提起する事である。

Q6_安全性は大事なコンセプトだが、「謝ってしまえば良い」というサービスも多く有る。そういう風土に対して金券を配れば良いとか、値段の交渉にも発展する場合もある。また、電子書籍を出した時にユーザがAPLをInstallできなかった時に、社長がNGは２割か３割でしょと言ってしまったものとかもある。こういった事例は社会をダメにしていると思う。こういった事例も含めプロセスだけでなく社会全体の状況を見ていく必要が有ると考える。しかしながら風潮としては謝ってしまえば良いという方が強まっていると感じるがいかがか。

A6_コストパーフォーマンス的には謝って済む場合はその方が良いかも知れない。逆に、それによって失う信用もあるのでそういった事について議論すべきと考える。つまり信頼性を保証すべき対象の選択について保証ケースを使って議論をすべきと考える。よって、全てを徹底的に実施するという事ではないと考える。すなわち、保証対象の選択という議論がある。もう一つは、謝る謝らないに依らず罰則規定が有るようなものもある。つまり法律は守る必要が有る。この範囲で守っていますという事についての説明をする必要が有る。そしてその事についてAssurance Caseを書くことができる。

◆感想
昨今の複雑化するシステム運用環境において、その実態の認識は有るものの抜本的な対策は構想も出来ず、個々のサブシステム単位での対策に終始しているのが運用現場・開発現場で良くある状況との認識です。この重大でかつ複雑な課題に対してシステマティックな俯瞰手段と解決に向けた検討経緯と具体的な手段までを紐解いていただき、非常に感動的な内容でした。特に安全高信頼性検証のホットな標準化内容としてO-DA標準のご紹介をいただけたことは、我々としてこれを契機として今後の普及への命題をいただけたものと思います。
　 さらに、今回の講演内容の現場への適用手段としてテンプレートを紹介いただけた事で理論から実適用への導きもしていただけました。
今後の課題としまして、今回の命題であるHitchins氏らの定義する外部ループを捉えた俯瞰による改革もしくは改善の活性化には、サブシステムを開発する立場ではなく、外部ループを仕切れるステークホルダの思考を変革していく事が重要な課題であるとの認識です。
内容の濃い貴重な御講演に深く感謝いたします。

＜講義の要約＞

◆エンジニアリングとは
エンジニアリングとは科学に裏打ちされた技術活動、学問体系である。我々のソフトウェア品質技術活動は正統なエンジニアリングであろうか。正統なエンジニアリングであるためには、まずはコミュニティ（SQiP研究会やSQuBOK策定委員会など）が不可欠である。そしてコミュニティには知識の妥当性・有効性・適用領域などを判断できる環境が存在し、コミュニティにおいて知識が共有され、それらが科学的基盤の上に成り立っていることが必要となる。その上で、ひとり一人の職業人が社会の中で果たす判断、行為、助言などが社会にとって意味のある価値を提供していることが必要となる。

知識体系としてSQuBOKがあると何が嬉しいのか。我々は知識を得るために、書籍を読んだり講習会に参加したり様々な場面を通じて、知識を高めたり深めたり広げたりしているが、これだけでプロフェッショナルとしての価値を形成することは難しい。なぜならベストプラクティスに裏打ちされたプロフェッショナリズムを高めるためには、知識だけではうまくいかず、経験やガイドが必要となるからである。
知識が整理されずに孤島のように散々としていると、知識の紐づけを考えることは困難となり、プロフェッショナリズムの達成は遅くリスクが高い。知識が整理され体系として存在し、その上にパターン、プラクティス、手法を持ち、それを活用することができれば、我々はより良く早くプロフェッショナリズムを達成することができる。

◆品質の知識体系の活用
○知識体系 Body Of Knowledge
知識体系BOKとは、妥当と認められた知識群を整理・構造化した全体、専門領域の定義づけである。多くのものは以下のように構造化されている。

BOKガイド（知識へのガイド）

カテゴリ（知識領域の大分類）

知識領域（知識の技術・プロセス上の分類）

トピックまたは知識項目（技術・プロセス知識）

文献（知識の詳細記述・実体）

ソフトウェアを取り巻く世界を、組織、ビジネス、システム、ソフトウェアという階層で考えると、以下のものがあり、相互に関係している。

SQuBOK:ソフトウェア品質知識体系ガイド→ソフトウェア
SWEBOK:ソフトウェア工学知識体系ガイド→ソフトウェア、システム
SEBOK:システム工学知識体系ガイド→システム、ビジネス
REBOK:要求工学知識体系ガイド→システム、ビジネス
PMBOK:プロジェクト管理知識体系ガイド→システム、ビジネス、組織
BABOK:ビジネスアナリシス知識体系ガイド→ビジネス、組織

今後BOKは増えていくことが予想される。大事なことは、BOKが扱っている範囲を知って、自分達が高めたい、深めたい、広げたいと思っている知識が、何であるのかをBOKから見つけ出すことである。

○SWEBOKについて
SWEBOKはソフトウェア工学に関する知識体系である。
知識領域（KA:Knowledge Area）は、要求、設計、構築、テスティング、保守、構成管理、マネージメント、プロセス、ツールおよび手法、品質で構成される。
SWEBOKにおけるソフトウェア品質はソフトウェアエンジニアリングのいたる所に関わる問題のことで、知識領域にはソフトウェア品質KAだけでなく他のすべてのKAも関係する。ソフトウェア品質の基礎概念、ソフトウェア品質マネージメントプロセス、実践上の考慮事項で構成される。
KA間にはリンクがあり、双方向に行き来することで、品質のきっかけを得られるようになっている。特に重視しているのは、ソフトウェア品質保証のプロセスとV&Vの設計・検証で、それをサポートする計測やマネージメントが含まれる。
SUEBOKでは倫理的な側面を明確にしており、海外では重視する傾向にある。
SWEBOKはv3として2014年に改訂予定である。トピックは以下の通りである。

全体

新設KA:プロフェッショナル実践、経済、計算基礎、数学基礎、一般基礎
※昔ながらの狭いソフトウェアではなく、広く知っておくべきKAが追加される
※社会的な要請からも知っておく必要がある

既存のKAでの拡充・新設

テストKA

拡充：テスト目的（ユーザビリティ・インタラクションテスティング、テスト駆動開発）
拡充：入力ドメインに基づく手法（ペアワイズテスティング）
新設：モデルベーステスティング手法
新設：テスティングツール

品質KA

拡充：安全性（セーフティ）：セーフティハザード分析技法など
※社会的な要請からも知っておく必要がある

拡充：品質ツール

SWEBOKはソフトウェア工学を広く扱っており、ソフトウェア品質については浅い部分もある。ソフトウェア品質に絞って深堀されたものが必要で、そのためにSQuBOKがある

○SQuBOKについて
SQuBOKはソフトウェア品質に関する知識体系である。
SQuBOKはソフトウェアの重要性が大きくなるという位置づけの変化、品質事故が発生するという実情の中、日本のソフトウェア品質の暗黙知を形式化、最新のテーマを整理・体系化、品質技術の認知度向上、ソフトウェア品質技術者資格制度、人材育成・組織支援を目的に、品質保証に携わるエンジニア、ソフトウェア技術者・管理者を対象に、2007年に第1版が出版された。
その後、業界変化に伴う品質技術拡充や概念変化への対応が必要となった。スマートホン、iPadなどの新デバイスの隆盛、Twitter等の新玉コミュニケーション手段の流行、クラウドコンピューティングによるビジネスモデルの変化などがこれに当たる。2014年に第2版を出版予定である。ポイントは以下の通りである。

1. 最新化：国際規格、IT業界変化への対応
※早く出して随時お客さんと直していくといった新しい領域への対応が必要になっている。

2. 樹形図や品質用語を見直し、一貫性と網羅性を確保
※不具合・欠陥は文脈によるが基本的にFault、Failureを包括している。
※バグはプログラム記述中のFaultである。

3. （第1版では着手することのできなかった）開発領域の拡充

※すべての人（V&V開発の前半に携わる人）に品質の意識を広げる
・要求分析、基本設計、詳細設計、実装に対する品質の検討・組み入れ技術を追加
・個々のプロセスについての管理サイクル（計画→実践→評価）を追加
 要求分析のマネージメント、設計のマネージメント、実装のマネージメントなど

また、具体的な追加・改訂は以下の通りである。

ソフトウェア品質の基本概念
品質のマネージメントの概念【改】
ソフトウェアの品質マネージメントの特徴【追】

ソフトウェア品質マネージメント
ライフサイクルプロセスのマネージメント【改】
品質管理、トレーサビリティ管理、情報文書管理【追】
プロジェクトマネージメント【改】
要求分析のマネージメント、設計のマネージメント、実装のマネージメント、リリース可否判定【追】
運用のマネージメント、保守のマネージメント【改】

ソフトウェア品質技術
モデル化の技法、形式手法、設計の技法、実装の技法【追】
ユーザビリティ、セーフティの技法、セキュリティの技法【追】
要求分析の技法、レビューの技法、テストの技法、運用の技法、保守の技法【改】

記述内容に注目すると、知識の【定義】以外に【目的】【方法】【効果】【参考文献】【関連トピック】を併記している。ハンドブックのイメージで活用できる。

◆知識体系の活用
知識体系を活用するシーンは以下の3点である。
・ソフトウェア品質の全体を俯瞰するポータルとして活用する。
・ソフトウェア品質の辞書として活用する。
・厳選された文献ガイドとして活用する。
別の見方をすると、自分が携わっているものから入って、それが全体の何処にあり、それが合致しているのかを判断することができる。そして、それが関連している技術を見つけ、別の領域へと知識を広げることに活用できる。
過去10年分のSQiP研究会の報告書を、SQuBOK第2版の知識領域に沿って整理し、SQiPライブラリとして公開している。
また、SQuBOK活用ノウハウの共有、SQuBOKユーザの声をSQuBOKガイドへフィードバックを目的に、SQuBOKユーザ会が活動している。

◆SQuBOKにみる開発技術と品質
○工程に共通の品質技術
メトリクスに加え、モデル化の技法、形式手法を追加している。モデル化の技術では、離散系のモデル化技法(UML,SysML,構造化アートPAD)、連続系のモデル化技法(Matlab,Simulink)、ドメイン特化言語を取り上げている。形式手法には、形式仕様の技法、形式検証の技法を取り上げている。
現実世界の何かを直接的に扱うことが経済的・安全的に効率よくない場合、それを代替するものがモデルである。ソフトウェアシステム開発においても、様々なモデルが活用されている。
アプリケーションにおいては、離散系のモデリングが使われ、ソフトウェアモデリング言語やUMLを使って設計、検証・シミュレーション、コード生成を実施している。制御系においては、連続系のモデリング使われ、ブロック線図やSimulinkを使って設計、検証・シミュレーション、コード生成を実施している。
また、機械や電気を含めたシステム全体としての検討が必要な場合、システムモデリング言語のSysMLやアーキテクチャ記述言語のADLで設計、シミュレーションが可能である。

活用事例：JAVAスクリプトのアプリケーションに内在するバグ検出
コードを見ながらアプリケーションのバグを見つけることは難しいが、コードが現実世界、状態遷移がモデルと考えて、コードから状態遷移図を自動生成し、これを見ながらバグを見つけると、網羅的に状態空間を形式的に検証することが可能となるので、バグを見つけやすくなる。

○工程に個別な品質技術（前半）
工程に個別な品質技術（前半）には以下のものがある。

要求分析の技法
要求抽出：ステークホルダ識別、要求開発・Openthology(*)
要求分析：機能要求分析、非機能要求分析、品質機能展開、要求可変性分析
要求定義：USDM
要求の妥当検証確認

設計の技法
方式設計の技法：部品化の技法、アーキテクチャパターン、

アーキテクチャ方法論（品質駆動設計・評価ほか）、DSM、フレームワーク

詳細設計の技法：テスト駆動開発、デザインパターン、設計原則

(*)Openthology（コタツモデル）：ステークホルダが（コタツに入って）膝を突き合わし一緒に仕様を定義していく開発スタイルのこと

活用事例：リダイレクトシステム開発
要求の段階では、品質要求を明確化するために、品質シナリオ、ゴール指向分析を活用した。設計段階では、品質を着実に組み入れるために、パターン、品質駆動設計・評価を活用した。

品質シナリオとは品質に特化した分岐のない物語のことである。ある刺激源から刺激が成果物に到着したら、成果物から応答が出て、その応答を何らかの方法で測定する。この時、成果物がどういう環境（状態）なのかを記述する。例えば「（環境）通常稼働時に、（刺激）リダイレクト情報に変更があった場合、（応答）運用を止めずに反映できる」「（環境）通常稼働時に（刺激）高負荷をかけた場合（応答）HTTPリクエストを秒間1000トランザクション処理できる」などである。これを活用すれば、品質要求を明確にできる。

ゴール思考分析は、実現すべき機能のゴールと品質のゴールを据え、そのためには何が必要で、そのためには何が必要というように、単純に必要なものを上げていく。これを活用すれば、定義したモジュールがゴール対してムダ・モレなく貢献できていることを確認できる。

アーキテクチャ設計時やコンポーネントの詳細設計時に、品質を組み込む方法として品質駆動設計がある。品質駆動設計では、品質要求に対して、成果物の中の形を設計する時に、実績のある、実現手法、アーキテクチャパターンを活用する。これらを活用するに当たって配慮すべきことはトレードオフである。ある品質に注力すると他の品質に影響が出る。例えばセキュリティを重視するとパフォーマンスは落ちる。また、これらの過程を残しておくことに価値がある。将来の機能追加や修正の時に影響範囲を特定する資料として活用できる。

○工程に個別な品質技術（後半）
工程に個別な品質技術には以下のものがある。
実装の技法

コーディング規約、リファクタリング、防御的プログラミング・契約による設計、
統合開発環境、継続的統合CI

運用の技法
データ品質、仮想化、クラウド、ソフトウェア若化

保守の技法
プログラム理解、リエンジニアリング、リバースエンジニアリング、コードクーロン分析

活用事例：開発と運用に見える次の"ABCD"
「A:アジャイルとD.DevOps」は「継続的統合CI」と「タスク・チェット開発」、「B.ビックデータとC.クラウド」は「モニタリング」と「データ解析」と密接に関わっていると整理できる。
また「B.ビックデータとC.クラウド」は「A:アジャイルとD.DevOps」を支える「プラットフォーム」や「フィードバック」の役割を負っていると整理できる。

○専門的品質特性の品質技術
専門的品質特性の品質技術には以下のものがある。

ユーザビリティの技法
ユーザビリティテスティング

セーフティ（安全性）の技法
リスクアセスメント技法(ISO/IEC 31010)、リスク低減法

セキュリティの技法
セキュリティ要求分析、セキュリティ設計(SDL、脅威分析・モデリングなど)、セキュリティパターン、
セキュアコーディング、セキュリティテスティング

活用事例：セキュリティパターン
要求では脅威・対策はどうするか、設計では構造はどうするか、実装ではコードはどうするか、セキュリティを専門としていない人が判断することは難しい。世の中で知られている認可パターンを活用することで、早い段階からの作り込が可能となる。

◆まとめと期待
・本日取り上げた事例をSQuBOK上にマップすると、何と何がつながっているのかを認識できる。
・SQuBOKには品質技術と品質特性と結び付ける表はないが、表を起こすための情報は入っている。
・開発計画の立案時にSQuBOKを参照すれば、今回の開発はどの段階でどの技術を活用するのがよいのかを検討できる。
・SWEBOK/SQuBOKの中から、パターン、プラクティス、手法を選び、組み合わせて活用することができるようになった現在、重要となるのは、活用した結果をこれらにフィードバックし、スパイラルに発展させていくことである。
・異なる知識体系群を結びつけ活用するためにSEMATメソッドアーキテクチャがある。エッセンス（言語、カーネル）といった共通の基盤の上で、プラクティス、手法・プロセス（UPやアジャイル）を比較することができる。
・ISO/IEC 24773（2008）では、様々なコミュニティのBOKをSWEBOKベースでマッピングし、技術資格者の共通化、フレームワーク化している。
・現状のBOKはクローズド（オーナーはあくまで単一コミュニティ）である。今後はBOKを相互横断的に活用できるようにオープン（知識体系の接続）であることが必要となる。

◆質疑応答（コメント含む）
C:モデルを作る理由は、経済性や安全性の視点で、実態を取り扱うことができないものを対象とする場合であることが腑に落ちた。コードを見て確認するのと、状態遷移図を見て確認するのとでは、どちらが優位なのか、モデルを作ったことのない人にとってモデルは余分な成果物かもしれないが、どちらが経済的なのかを考えるとモデルの価値は高いことが認識できた。

Q1:個人的に技術者の倫理に触れる機会があり、世の中には、エレベータの話、自動車の話などがあるが、ソフトウェアは見えてこない。今後これらがSWEBOKに含まれる可能性はあるのか教えてほしい。

A1:海外ではBOKを据えた上で同業者コミュニティをソサエティとして扱っている。昔のギルドみたいなイメージでそれがBOKに反映されている。情報処理学会などでも倫理の話は出ている。今後のソフトウェア品質認定試験に入ってくるかもしれない。

Q2:倫理は重要なので、他の人がどのように考えているかを知りたい人もいる。そのような情報があるのか教えてほしい。

A2:SQuBOKには入ってはいない。いずれは考える必要がある。現状のソフトウェア認定試験に倫理規定は入っていないが、いずれは倫理規定を遵守する成約をした上で資格認定することが必要となる。
全体のハードウェアを含めた品質管理の世界では倫理規定があって、QC検定にでは取り入れられている。そこには普遍的なことが書いてある。

鷲崎氏から補足：
SQuBOKの一番身近なのは　SQiPライブラリである。以前は参照しずらかったが、新しい体系で公開するようにしたことで参照しやすくなった。
また、SqiP研究会の論文は実際に取り組んだものである。SQuBOKの参考文献となるような論文が出てきてほしい。

＜講義の感想＞
SWEBOKやSQuBOKの知識体系は「辞書」としての認識が強かったのですが、具体的に業務で活用するポイントとして「自分が携わっているものが全体の何処にあり、それが自分達の目的と合致しているのかを判断すること」や「それが関連している技術を見つけ、別の領域へと知識を広げること」を解説して頂いたことで、より身近なレベルで利用できる「ハンドブック」であることを認識できました。目の前にあるプロジェクトの活動を確認してみようと思います。
司会者であられます小池様、貴重な講演をしてくださいました鷲崎様に深く感謝いたします。