# ソフトウェア工学知識体系 ## 定義 SWEBOK(Software Engineering Body of Knowledge、ソフトウェア工学知識体系)とは、ソフトウェア工学が正統な工学分野・認知された専門職として確立するために専門職コミュニティが合意すべき中核的な知識の集合を指す。1998年の *Guide to the Software Engineering Body of Knowledge – A Straw Man Version* は、その合意形成を目指す4年計画(Straw Man → Stone Man → Iron Man の3段階発展計画)の第一段階報告書であり、知識領域(Knowledge Area)と関連分野(Related Discipline)の草案リストを提示することを主目的とする。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 1 Introduction]]) なぜ中核的知識体系への合意が必要かは、Starr の専門職正統性論に基づいて説明される。専門職としての正統性は、(1) 専門職の知識と能力が同僚集団(peers)によって検証されていること、(2) その知識が合意された合理的・科学的根拠に立脚していること、(3) 専門職の判断と助言が実質的な価値へ方向づけられていること、の3要件(collegial・cognitive・moral)から成り立つ。核となる知識体系への専門職コミュニティによる合意は、この正統性の要件を満たすための避けて通れない第一歩であり、software engineering カリキュラムの開発・大学課程の認定(accreditation)基準・専門職の免許(licensing)/認証(certification)基準と試験の開発という3つの下流の取り組みすべてに影響を与える。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]]) 知識体系への合意が専門職化とどう関係するかについては、Ford and Gibbs(1996)の8要素成熟度モデル(初期専門教育制度・認定・技能開発機構・認証・免許・専門職能開発プログラム・倫理規定・専門職団体)がひとつの評価軸を与える。このモデルで software engineering 専門職を分析すると、professional development と professional society の2要素のみが ad hoc の段階を超えており、他の6要素はいまだ未成熟である。SWEBOK プロジェクトは、この未成熟な6要素のうち特に認定・認証・免許の基盤となる「核となる知識体系」の欠如を埋めることを狙いとしている。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]]) ## 知識領域の同定結果とISO/IEC 12207との対応 第4章の識別方法論(教科書24冊の目次・大学課程29件の必修/選択科目の調査)を実際に適用した結果が第5章のTable 1・2・3である。「一般に受け入れられた(generally accepted)」とみなすための有意な数は6(教科書24冊の4分の1)に設定され、これを満たしかつISO/IEC 12207のライフサイクルプロセス・活動分類とよく収束するトピックはTable 1で網掛けにより明示される。網掛けされた活動は Requirements Analysis・Detailed Design・Coding・Testing・Maintenance Process・Configuration Management・Quality Assurance・V&V・Management Process・Improvement Process の10件であり、いずれもISO/IEC 12207の Primary/Supporting/Organizational の各プロセス類に属する。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) ISO/IEC 12207とうまく収束しないトピックは、基準を満たすか否かでさらに2つの表に分けられる。基準を満たす非収束トピック(Table 2)には Software Development Methods(Object Oriented・Formal Methods・Prototyping を含む)・Software Development Environments・Software Engineering Overview & Definition・Measurement/Metrics・Software Reliability が並ぶ。基準を満たさない非収束トピック(Table 3)には Software Products・Software Reuse・Real-Time/Embedded Software・Reengineering・Human Factors・Standards・Fault-Tolerant Software・Ethics・Legal Aspects・Software Security/Safety が並ぶ。この2×2の整理(ISO/IEC 12207との収束×一般に受け入れられた基準の充足)が、SWEBOK Straw Man 版が提示する知識領域候補リストの骨格をなす。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) 有意な数を6に設定した理由は2つ述べられている。識別方法論はできるだけ包摂的であるべきで知識領域は少なすぎるより多すぎる方が望ましいという判断、および多くのトピックが目次に現れないまま教科書本文で扱われておりより詳細な分析をすればさらに実態を反映できるという判断である。また大学課程の情報は、調査対象の課程の種別(学部/大学院、専門職/研究)が多様であることを理由に選定基準そのものには含めていない(ただし Industrial Advisory Board の審査には有用としている)。提案リストの解釈にあたっては、英語かつインターネット上で入手可能な教科書のみを対象としたこと、カテゴリ間の重複計上があること(例: Formal Methods は独立トピックとライフサイクル分類の双方に現れうる)、専門的トピックの重要性が過小評価されている可能性があることなど、複数の限界が明示されている。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) ## 知識体系とその Guide の区別、および段階的合意形成の設計 「知識体系(Body of Knowledge)」と「その Guide」は同じではない。前者はソフトウェア工学という専門職内に存在する知識の総和を指す包括的な語であり、法律・医療・会計などの専門職と同様、知識体系そのものは実務者と学術者に宿る。新興分野であってもその全体を1つの文書に収めることは通常できないため、一般に受け入れられた部分集合すなわち核となる知識体系を識別・記述する Guide が要請される。あわせて、知識体系とカリキュラムも同じではないという区別が置かれる。プロジェクトの目標はソフトウェア工学者が知るべき事柄すべてを目録化することではなく、ソフトウェア工学の核を成すものを識別することであり、それ以外を定義する責任は免許・認証・カリキュラム認定に携わる他の組織にある。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]]) 合意形成は総期間4年の三段階(Straw Man → Stone Man → Iron Man)で設計される。この設計は、開発過程そのものを公開・文書化するという透明性の原則と、産業界・専門職団体・標準化団体・学界にわたって時間をかけて合意を築くという合意形成の原則の2つに立つ。第2段階(Stone Man、1999年半ば完成見込み)の戦略は Industrial Advisory Board・専門委員会(subcommittee)・広範なコメント収集と合意形成の過程という3要素を核とし、第3段階(Iron Man、Stone Man 完成のおおむね2年後)ではコメント収集と合意形成の過程がさらに徹底される。すべての版はインターネット上で無償公開される。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]]) ## Stone Man 段階への引き渡しと構造化枠組み Straw Man 版は、その識別方法論が**知識領域を提案するには足りるが、各知識領域内のトピックを識別し参考資料を選定するには不十分である**と自ら認めたうえで Stone Man 段階へ引き渡す。拡張が必要な理由は5点挙げられる: 教科書の目次の粒度のばらつき、教科書の刊行年の幅、調査した大学課程の種別の幅、課程ごとのコース数の違い、そしてシラバスや教科書の章そのものではなくコース名と目次項目を分析したにすぎないこと。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]) 引き渡しにあたって提案される具体的な手順は、Appendix A の最新の一般教科書6冊の統合からトピック案を起草し、それを [[Walter Vincenti]] の工学設計知識のカテゴリ(fundamental design concepts / criteria and specifications / theoretical tools / quantitative data / practical considerations / design instrumentalities)の適応版で分類し、各専門委員会が審査・改善して参考資料を選定する、というものである。この枠組みを選んだ理由には、確立した工学分野(航空工学)の歴史分析に基づくこと、特定カテゴリにおける知識体系の**空白とそれを埋める取り組みが可視化される**こと、カテゴリが汎用的なので各知識領域内の知識が進展しても枠組み自体は安定に保たれることが挙げられる。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]) ## 横断的知見 - 第3章は「なぜ核となる知識体系への合意が必要か」を専門職正統性論・成熟度モデルという理論的根拠から論じるのに対し、第5章はその合意を得るための具体的な同定手続き(教科書・大学課程の調査、6という頻度閾値、ISO/IEC 12207との収束判定)と、その結果得られた知識領域候補の実際のリストを提示する。第3章単独では「知識体系への合意がなぜ専門職化の前提となるか」は分かるが「具体的にどの知識領域が候補になるか」は分からず、第5章単独では候補リストは分かるが「なぜそもそも合意が必要か」という理論的動機は分からない。両章を合わせて読むと、SWEBOK Straw Man 版が抽象的な専門職論から出発しつつ最終的には教科書・カリキュラムという経験的データに基づく具体的なリスト作成に着地する構成になっていることが分かる。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) - 第1章・第3章は「一般に受け入れられた」という基準が専門職正統性の要件(同僚集団による検証)と結びつく概念であることを示すのに対し、第5章はこの基準を「教科書6冊以上」という定量的な閾値に落とし込む。定性的な正統性論と定量的な選定基準の間には、後者が前者を完全には演繹できないという緊張がある。第5章自身が「教科書は英語かつインターネットで入手可能なものに限られる」「専門的トピックの重要性が過小評価されている可能性がある」といった限界を明示している点は、この定量化が正統性論からの厳密な導出ではなく実務的な近似であることを本書自身が認めていることを示す。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) - 第1章は「専門職化の活動(1993年以降の Joint Steering Committee 設置、認定基準草案・倫理綱領草案の作成)がすでに進行中である」という既成事実を提示するのに対し、第3章はその活動がなぜ核となる知識体系への合意を前提とするのかという論理的根拠(Starr の専門職正統性論、Ford and Gibbs の8要素成熟度モデル)を与える。両章を合わせて読むと、SWEBOK プロジェクトは「専門職化はすでに部分的に進行しているが、その基盤となる知識体系の合意はまだ存在しない」という認識のギャップを埋めるために着手されたことが分かる。第1章単独では「なぜ知識体系が必要か」の論拠は示されず、第3章単独では「すでにどこまで専門職化が進んでいるか」の事実は示されない点で、両章は相補的である。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 1 Introduction]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]]) - 第2章は「Guide が知識体系の一部(一般に受け入れられた核)だけを扱う」と範囲を限定するのに対し、第5章はその核の候補を教科書頻度という単一の量的指標で切り出す。第2章が置いた「知識体系 ⊃ 核となる知識体系 ⊃ Guide の記述対象」という三重の入れ子は概念的には明快だが、第5章の実装では最も外側と内側の境界だけが操作可能になっており、中間の「核」がどこまで独立した実体として扱われているかは曖昧なまま残る。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]]) - 第2章は Stone Man 段階の体制(Industrial Advisory Board・専門委員会・コメント収集過程)を**組織の設計**として示し、第7章は同じ段階を**方法論の設計**として示す。両者を並べると、Straw Man 版が引き渡したものは知識領域のリストそのものよりむしろ「リストをどう精緻化するかの手続き」であることが見えてくる。第7章が識別方法論の不十分さを 5 つの理由とともに自ら明示している点は、この文書が結論ではなく手続きの提案として設計されていることの裏づけである。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]) - 第3章は [[Walter Vincenti]] を「工学は応用科学以上のものである」という**論拠**として引くのに対し、第7章は同じ Vincenti のカテゴリを Stone Man 段階の**作業枠組み**として引く。同一の出典が、専門職論の正当化と実務手続きの設計という 2 つの異なる役割で使われており、本書が理論的主張を方法論へ変換する経路の一例になっている。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]) > [!contradiction] > 第7章 p.27 の提案知識領域リスト(および Executive Summary の同じリスト)には **Management Process が含まれていない**。しかし第5章の Table 1 では Management Process が教科書20冊・必修20課程・選択10課程という高い頻度で網掛けされ、「一般に受け入れられた」と判定された活動として明示されている。表の判定と要約リストの間に食い違いがある。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]) ## 未解決の問い - 第7章の要約リストから Management Process が落ちているのは単純な脱落か、それとも「マネジメントはソフトウェア工学固有の知識ではない」という判断が背後にあるのか。Appendix J は Parnas がプロジェクト管理をソフトウェア工学固有の知識体系から除外すべきだと主張していたことを記録しており、この論点自体は当時から存在した。本書内には判断の明示がない。 - 核となる知識体系への専門職コミュニティの合意は、実際にはどのような手続き(投票・Industrial Advisory Board のレビュー等)で確認・更新されるのか。第5章は Industrial Advisory Board が知識領域の審査・承認に大学課程情報を利用しうると述べるにとどまり、具体的な承認プロセスは記述していない。 - Table 2で Formal Methods は独立トピックとして9冊の教科書に現れるが、第5章の脚注は「ライフサイクル分類に含められることもある」と述べる。Appendix I(Formal Methods の詳細分類)を読めば、この二重計上がどう解消・整理されているかが分かる可能性がある。 - Table 1で網掛けされなかった Architectural Design(教科書2冊)は、脚注21で「Detailed Design に分類されたトピックの多くは Architectural Design に分類することも妥当」と述べられている。より詳細な章単位の分析を行えば Architectural Design も有意な数(6)を超えていた可能性があり、網掛けの有無がどこまで安定した結果かは未検証である。 - Straw Man → Stone Man → Iron Man という3段階の進化の過程で、提案された知識領域・関連分野の中身はどの程度変化したか。後年の SWEBOK Guide(2004年版・v3・v4)との比較は本 ingest のスコープ外(1998年時点の記述のみを扱う)だが、比較のための橋渡し文献としては有用な問いである。 ## 関連 - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 1 Introduction]] / [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]] / [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]] / [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]] / [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]] - [[SWEBOK Straw Man Version]] — 本概念のハブとなる書籍 entity - [[Walter Vincenti]] — Stone Man 段階の構造化枠組みとして採用が提案された工学設計知識カテゴリの提唱者 - [[ソフトウェア工学の関連分野]] — 知識体系の外側にある隣接分野の境界画定 - [[IEEE Computer Society]] / [[ACM]] — 知識体系策定を主導した合同委員会の母体 - [[専門職化と資格認定]] — 知識体系が支える認定・認証・免許の3区分 - [[ISO IEC 12207|ISO/IEC 12207]] — 第5章の知識領域候補の分類基盤となった国際規格 - [[一般に受け入れられた知識]] — 「一般に受け入れられた」の選定基準そのものを扱う概念(第4章担当) ## 出典 - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 1 Introduction]] - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 2 The Guide to the Software Engineering Body of Knowledge Project]] - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 3 Context and Relationships]] - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 5 Proposed Knowledge Areas]] - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 7 Summary and Next Steps]]