html5j パフォーマンス部

Session2ソフトウェア工学の基礎を学ぶ

2014年6月5日

大槻繁 株式会社一（いち）

http://1corp.co.jp

• 大槻 繁 （おおつき しげる）

• 大手総合電機会社の研究所にてソフトウェアエンジニアリングの研究開発に20年以上従事、以降独立し、2004年にコンサルティング会社一（いち）を設立。

• 2010年よりビジネス・ブレークスルー大学経営学部教授（ITソリューション学科ソフトウェア経済論）に就任。

• ソフトウェア開発支援ツール、開発方法論の研究開発、ソフトウェアエンジニアリング、プロジェクトマネジメントの教育を手がける。近年は、IT調達支援、ソフトウェア見積り評価、プロセス改善などに従事するとともに、新しいソフトウェア開発のパラダイム提唱、知識創造産業におけるアーキテクチャや社会的な仕組みを探求している。

• アジャイルプロセス協議会フェロー、同知働化研究会運営リーダ、実践的ソフトウェア教育コンソーシアムWG2（ソフトウェアの方法論に関する実践知と社会基盤）サブリーダなど。

• 著書に「ソフトウェア設計」（朝倉書店、共著）、「大丈夫かあなたの会社のIT投資」（NTT出版、共著）、「ソフトウェ

ア開発はなぜ難しいのか」（技術評論社）、「ずっと受けたかったソフトウェア設計の授業」（翔泳社、共著）など多数。

2

3

4

•

•

•

•

•

•

•

•

5

•

•

•

•

•

6

7

開発者

利用者 マシン

記述（言語）

本来独立した３つの世界にまたがる記述を中心とした知識

Java, C, 仕様記述言語, UML, 自然語, スクリプト言語, html5,

…

正しい作り方

8

科学と工学：理論と実践

ソフトウェア工学（ソフトウェアエンジニアリング）

＝ 組織論，心理学，人間工学，宗教，精神活動，躾，・・・

＝ 管理 ＋ 標準化 ＋ ε

＜工学（実学）＞ ＋ ＜科学（理論）＞

化学工学 ＋ 化学

機械工学 ＋ 静力学

電子工学 ＋ 電子物理学

ソフトウェア工学 ＋ ソフトウェア科学？

9

見積り手法（理論）の種類

主観 客観

ボトムアップ

トップダウン

アナロジー事例類推

作業展開(WBS)積み上げ

デルファイ法

COCOMO

単純推論

ユースケースポイント法

ファンクションポイント法

プロジェクト全体や大きな構成要素単位で見積もる手法

プロジェクトの構成要素ごとの見積りを積み上げていく手法

計測・算定者の属人性が高い手法

第三者の納得性が高い手法

同種のシステム開発データを適用して推定

コード行数予測と、人月あたりの開発コード行数実績から推測

複数の専門家の予測を集計

開発作業を分割・展開し、それぞれの個別作業のコストを集積

構成要素積み上げ

システムの構成要素のコストを集積

3点見積もり（PERT法）リスクを勘案して見積

もった悲観・楽観・最可能値を基に数式で算出

システムの外部特性を集積してシステム規模を計測

過去の開発データを回帰的に分析して作成したモデルを基に算出

10

11

1970 1980 1990 2000 2010

NATO会合 ライフサイクル論争 アジャイルソフトウェア開発マニフェスト

SEの

第１の波SEの

第２の波SEの

第３の波

農耕的 工業的 知働的

プログラム主体構造化機能中心

システム主体大量生産/大量消費分業/手順化/標準化

ドメイン主体知識社会

多様化/価値指向

ソフトウェアエンジニアリングのあゆみ：第１〜３の波

アルビン・トフラーの『第三の波』で提示されたパラダイムを、ソフトウェアの世界にあてはめてみました。

12

時代は「第３の波」なのに、「第２の波」に呪縛されている

個人能力相互作用

プロセスツール

動くソフト 文書

顧客協調 契約・交渉

変化対応 計画遂行

アジャイルな気持ち

アジャイルソフトウェア開発マニフェストは、それなりにインパクトがありました・・・

伝統的取組みの傾向

（Manifesto for Agile Software Development, 2001年2月）

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

13

ソフトウェア作りで大切なことを改めて確認

明確になった事項を、明確になったものだけ、速やかに実装する

開発プロセス ビジネスプロセス

協調/同期

狭義から広義のアジャイルへ

開発者側中心の視点顧客側とのコミュニケーションや確認を重視してはいるものの、あくまでも受動的

狭義のアジャイルプロセス

顧客側と開発側との同期全体での価値創出、ビジネスプロセスを能動的に考慮

開発プロセス

広義のアジャイルプロセス

14

アジャイルプロセスの取り組みは、最近ではビジネス連動が中心課題

計算機世界（開発者の世界）

プログラム

モデル仕様化

（モデリング）

実装（プログラミング）

検証

（モデル検証）

テスト

（実行）

計算機

業務世界（利用者の世界）

インタフェース（共有現象）

仕様記述言語によって記述

プログラミング言語によって記述

15

ユーザ企業

ベンダ

（WF、非WF/アジャイル等の受発注開発•保守）

ユーザ企業

ベンダ企業

調達プロセス 提案プロセス

システム

＜ビジネス＞

＜エンジニアリング＞

交渉（negotiation)

契約（contract）初期構築

保守

ビジネスプロセス

コミュニケーションギャップ

ベンダシステム部門

システム

俊敏な＜ビジネス＞

＜エンジニアリング＞

初期構築保守

ビジネスプロセス

受発注フレーム

内製化

フィードバック

16

アセットDB

ベストプラクティスDB

インシデント統計DB

インターネット計測DB

実践的な見積り技法

要求（システム、サービス）

機能要求

非機能要求NFR

組織戦略

ユースケース

サービス

規模

SLA/OLA

プロジェクト実績DB

各種チェックリスト価格決定モデル

各種特性・制約 コストドライバ

機能仕様

品質

工数、期間等

従量価格

ライフサイクル工数

必要作業、工数等

規模ベースの見積り技法

規模ベースではない見積り技法

事例ベース推論エンジン

データマイニング

統計分析

時系列工数等

マーケット主導・ユースケース駆動型

事例ベース推論型

従量価格算定型

アジャイルプロセス型

ベストプラクティス差分型

プロダクトライン型

フィーチャ

ソリューション

アセットベース型

プロセス積上げ型

ステージ別要求リソース工数等

SLA: Service Level Agreement, OLA: Operational Level Agreement

17

18

非機能要求＝品質体系

• 品質とは– ユーザやスポンサーの要求を満足させるために製品・サービスが持つべき特性

– ユーザや顧客にとっての価値、満足度

• ユーザ視点に立ったソフトウェア品質体系の規格としてJIS X 0129 = ISO/IEC 9126がある– 品質特性／品質副特性（外部特性）：ユーザ視点、ソフトウェア製品の評価を意識した特性

– 内部特性：開発者の視点、開発プロセスの評価を意識した特性

品質体系：品質特性／品質副特性【品質特性 (Quality Characteristics)】 【品質副特性 (Quality Subcharacteristics)】

機能性 (functionality) 合目的性 (suitability) 仕様に対する機能が適切であること正確性 (accuracy) 正しい結果、正しい効果をもたらすこと相互運用性 (interoperability) 他のシステムと相互作用できること標準適合性 (compliance) 規格、用法、法律、法規等の規則に遵守していることセキュリティ (security) プログラムやデータに対し不当なアクセスを排除すること

信頼性 (reliability) 成熟性 (maturity) 故障の頻度に影響する潜在する障害が少ないこと障害許容性 (fault tolerance) 障害部分の実行、インタフェースに違反した実行を許容すること回復性 (recoverability) 故障からの復帰、データの回復能力があること

使用性 (usability) 理解性 (understandability) 論理的概念、適用方法の理解がしやすいこと習得性 (learnability) 適用（運用管理、入出力等）を習得しやすいこと運用性 (operability) 運用と運用管理がしやすいこと

効率性 (efficiency) 時間効率性 (time behavior) 実行の際の応答時間、処理時間、処理能力が高いこと資源効率性 (resource behavior) 実行の際の資源量、資源の使用時間が効率的なこと

保守性 (maintainability) 解析性 (analysability) 欠陥、故障診断、改訂部分の識別が可能なこと変更性 (changeability) 改訂、障害除去、環境の変化への対応が可能なこと安定性 (stability) 予期せぬ危険性への対応力があること試験性 (testability) 妥当性の確認がしやすいこと

移植性 (portability) 環境適応性 (adaptability) 異なる環境への適用が付加的な労力を伴わずに行えること設置性 (installability) 特定の環境に設置しやすいこと規格適合性 (conformance) 移植に関係する規格、規約を遵守していること置換性 (replaceability) 他のソフトウェアの代わりに置き換えて利用可能なこと

ソフトウェアの達成のレベルと使用する資源の量との間の関係に影響する属性の集合

仕様化された改訂を行うために必要な労力に影響する属性の集合

ある環境から他の環境へ移す際のそのソフトウェアの能力をもたらす属性の集合

ソフトウェアが必要性を満たすために何をするかを示すもので、明示的なもののみならず、暗示的なものも含む

ソフトウェアの達成のレベルを維持するソフトウェアの能力をもたらす属性の集合

利用者がソフトウェアを使用するために必要な労力、及び、個々の使用結果による評価に影響する属性の集合

19

品質体系：内部特性# 副特性名 英語名 説明1 完全性 (completeness) 要求機能が実現されていること2 追跡可能性 (traceability) 要求から実現されたものへの関連、及び、その逆を追跡できること3 一貫性 (consistency) 設計、製造の技法や表記法、用語、企業等が統一されていること4 自己記述性 (self-descriptiveness) 機能、及び、機能間の関連が完結していること5 無矛盾性 (coherence) 機能、プログラム、ドキュメントの間に矛盾がないこと6 計算正確性 (accuracy) 計算結果、出力が要求された精度を達成していること7 データ共通性 (data commonality) データをシステム内、あるいは、他システムと共通に使用できること8 通信手順共通性 (communications commonality) 通信手順やインタフェースが共通化していること9 アクセス可能性 (accessiblity) プログラムの機能や関連装置を選択して自由に使用できること

10 アクセス制御性 (access control) ソフトウェアやデータへのアクセスを制御できること11 アクセス監査性 (access audit) ソフトウェアやデータへのアクセス記録を残すことができること12 堅固性 (robustness) 誤った操作を行っても、データやプログラムが破壊されないこと13 整合性 (integrity) ソフトウェアの内部で異常が発生してもデータやプログラムが破壊されないこと14 モジュール性 (modularity) ソフトウェアが構造化され、変更、修正等が局所的に済むこと15 単純性 (simplicity) 仕様の実現方法が簡単であること16 計測性 (instumentation) プログラムの動作状況を観察、観測できること17 自己包含性 (self-containedness) 他のプログラムに依存しないで機能を満たすことができること18 統一性 (uniformnigy) 意味、表現、手順が一義的、同一的であること19 表現性 (expressiveness) 入出力や処理の論理、結果をモデル化して表現できること20 階層性 (hierarchy) 概要から詳細へ段階的に論理が構成されていること

・・・

20

品質体系：品質特性／品質副特性×内部特性品質特性

品質副特性

内部特性

合目的性

正確性

相互運用性

標準適合性

セキュ

リティ

成熟性

障害許容性

回復性

理解性

習得性

運用性

時間効率性

資源効率性

解析性

変更性

安定性

試験性

環境適応性

設置性

規格適合性

置換性

1 完全性 ◎ 〇 ◎ △ △2 追跡可能性 ◎ ◎ ◎ △ △ ◎ ◎ 〇 △3 一貫性 〇 〇 ◎ 〇 ◎ ◎ ◎ 〇 〇4 自己記述性 ◎ ◎ ◎ ◎ ◎ ◎ 〇 〇5 無矛盾性 〇 ◎ 〇6 計算正確性 ◎ 〇7 データ共通性 〇 ◎ △ ◎ ◎ ◎ ◎8 通信手順共通性 〇 ◎ △ ◎ ◎ ◎ ◎9 アクセス可能性 〇 △ 〇 〇

10 アクセス制御性 ◎11 アクセス監査性 ◎ ◎12 堅固性 〇 ◎ 〇13 整合性 ◎ 〇14 モジュール性 ◎ ◎ 〇 ◎ ◎ 〇 ◎ ◎15 単純性 ◎ ◎ ◎ ◎ 〇 〇16 計測性 ◎ ◎ ◎ 〇 ◎17 自己包含性 ◎18 統一性 ◎ ◎ ◎19 表現性 ◎ 〇 ◎20 階層性 ◎ ◎ 〇

◎：強い相関がある 〇：相関がある △：弱い相関がある

保守性 移植性機能性 信頼性 使用性 効率性

21

品質体系：品質特性／品質副特性×内部特性 続き

品質特性　　　品質副特性

内部特性

合目的性

正確性

相互運用性

標準適合性

セキ

ュリティ

成熟性

障害許容性

回復性

理解性

習得性

運用性

時間効率性

資源効率性

解析性

変更性

安定性

試験性

環境適応性

設置性

規格適合性

置換性

21 説明性 〇 〇 ◎22 比喩性 ◎ 〇 ◎23 完備性 ◎ ◎ ◎24 注目性 ◎ 〇 ◎25 適時性 〇 〇 ◎26 適量性 〇 ◎ ◎27 簡潔性 ◎ ◎ ◎ ◎ ◎ △28 選択性 〇 〇 ◎29 誘導性 ◎ ◎ ◎30 安全性 〇 〇 ◎31 省力性 〇 ◎ ◎32 環境適合性 〇 〇 ◎33 動的効率性 ◎ 〇34 資源使用性 〇 ◎35 拡張性 〇 〇 △ △36 製品管理性 △ ◎37 ソフトウェアシステム独立性 〇 〇 〇 ◎ ◎ 〇 ◎38 マシン独立性 〇 〇 〇 ◎ ◎ 〇 ◎39 データ独立性 ◎ ◎ ◎ ◎40 伝達性 △ △ △

◎：強い相関がある 〇：相関がある △：弱い相関がある

保守性 移植性機能性 信頼性 使用性 効率性

22

リ ファ クタ リ ングの効果

0

25

50

75

100

1 2 3 4 5 6 7 8 9 10

時間

工数

母体劣化の場合

リ ファ クタ リ ングを行う 場合

年

億円

COCOMOによるシミ ュレーショ ン（ 試算）

23

COCOMO=COnstructive COst MOdel

24

25

価値

価値

技術

技術

天動説

地動説

知働説

人働説人月の神話

ソフトウェアとは《実行可能な知識》である

Executable Knowledge

ソフトウェアとは実行可能な知識を紡いだ《様相》であるTexture

中心は《機能》から《様相》へ

人働説から知働説へ

「作る」と「使う」は本質的に同じ

知働化研究会は、アジャイルプロセス協議会のWGとして、2009年6月に設立されました。コンセプトリーダ：山田正樹氏（メタボリクス社）運営リーダ：大槻繁、現在メンバ数30http://www.exekt-lab.org/

R

I

T

S

Λ

Ｖ

インタフェース

コンピュータ世界

実世界（問題領域）

コンピュータ（ソフト、ハード、ネット、・・・）

装置

もの

情報

人

ドメイン

要求

現象

接続

Semantics（意味）

Requirements（要求） Test（テスト）

Implementation（実現）

Ｖ字モデル

Λ字モデルラムダ

26Ｖ字モデルとデザイン論の枠組みを接合することによって、『ΛＶモデル』ができあがります。これは、ソフトウェア（システム）、対象領域（実世界）、要求との関係も明確に位置づけて、全体を俯瞰することができます。

I1

R1

S1

T1

I2

R2

S2

T2

I3

R3

S3

T3

I4

R4

S4

T4

I5

R5

S5

T5

I6

R6

S6

T6

時間

2週間

時間

注文（バックログ）

セル（チーム）

It

St

要求の発生プロセス

アジャイルプロセスのタイムボックス方式（ソフトウェアセル生産方式）をΛＶモデルで分析することができます。要求の発生プロセス（受注生産であればクライアント側）を明確にしていく必要があります。

27

マネジメントのプロセス（マイクロプロセス）

顧客

管理

計画 と再計画

作業定義 仕事の割り当て

プロダクト開発

システムエンジニアリング

構成管理

検証と検査

制御予測

データ保持

測定報告プロジェクト報告 状況報告

要件

問題報告と変更要求

統制

28

Webパフォーマンス改善のプロセス

Webシステム

KeynoteSystems計測ツール

RUM:Real User MonitoringSynthesis MonitoringServer side Monitoring・・・

Web分析ツール

アクセス解析ツール検索エンジン関連ツールSNS関連ツール・・・

命題

目標、法則、定理改善策

新要求

新実装 KGI:経営目標達成指標KPI:業務評価指標

ログ

計測データ

作業仮説

調整

検証

実証

データマイニング

定量化

確率・統計学

統計解析ツール

ビジネスアナリシス

ユーザエクスペリエンス

SAS,R,Mathematica,…

29

29

30

31

全体化

創造化

経営化

実世界、業務世界と連動し、かつ、経営上の観点（バリューチェーン）、経済・富の評価を伴う意思決定へ

個別蛸壺ではなく、全体（組織全体、ステイクホルダ全体）、初期構築と運用の統合化視点へ

生産性向上より商品力向上（価値指向）へ、デザイン思考や創造性中心

方法論

ツール

BAの導入

本当のビジネスモデル策定と評価

構築・運用の統合

プロジェクトごとより組織全体論

自動化されない世界の創造性思考暗黙知の定式化

本当のMISKPI設定・測定経営の自動化

広義の構成管理組織横断証跡機能

発想・認知支援プロトタイピング

これからの方向性

社会＋IT含めた

モジュールの再構成が起きている

31

Goal

pullpushgeneration evaluation

分析

表現構成

《図案表現型》

《問題解決型》

《理想追求型》

デザインイメージ

デザインイメージ

内的な感性から生み出される 目標をたよりに概念が生み出される

現状認識駆動, 現在指向

記憶駆動, 過去指向感性駆動, 未来指向

デザインの型（パターン）

32

『デザインの創造性と概念生成』（田浦, 永井）より

ソフトウェアのデザイン

ユーザの理解についてのデザイナーの理解

内部の力動性

デザイナがユーザのインタフェースについて持つ理解

意味ユーザの理解

予期する感覚行為

現実の欠如する引き起こす

そこに展開される

換喩的に喚起する

予期する

混乱

問題にする

外部的なもの

発生の原因となる

結果

インタフェース

人工物

分類名称 説明 典型的対象分野

抽象的 高設計自由度 全般

不確実 確率・非決定的 予測、フィルタ

曖昧 未認識・未定義対応 全般

相対的 言語ゲーム的 社会、対話

進化的 メタ・状況適応 パターン認識

計算限界 近似解 レイアウト、検索

未解明項 調整・フィードバック 制御、ログ解析

デザイン論の大御所であるクリッペンドルフは著作『意味論的転回』の中で、左図のような意味、行為、感覚の関係を提唱しています。これは、ソフトウェアをデザインの対象とした時にも成立します。

33

R T

S Semantics（意味）

Requirements（要求） Test（テスト）

インタフェース

Λ

対象システムのアーキテクチャに関する理論的原理（進化型：Evolutional-Type）

ユースケース分析

フィーチャ分析

進化型ソフトウェアの構造

34

ソフトウェアが生み出す価値とそれを生み出す方法（解）との関係

35

組織（マネジメント）

不確実性（変化への対応）

進化・適応（学習と成長）

抽象化（定式化）《数学》

自動化（実行）

《オートマタ》

モジュール化（構造化）《社会学》

ビジョン、戦略

知識主導ドメイン抽象、実装抽象

実行可能知識

手順化機械化、ツール化、リターン

産業モジュール

セル生産アセット、コンポーネント化

オプションとリスク

確率予見,保険,プロダクトライン

進化論、パラダイム論

進化型ソフトビジネス駆動、技術駆動

アジャイル(スピード,俊敏)

軽量化並行化,イテレーション,計測

コミュニケーション/確認

協調インタフェース,調整,交渉

パラダイムシフト,適応

ライフサイクル保守,自律化,TOC

再(脱)構築

改革クロスファンクション,再構成

価値の局面

解の方向

価値と解のマトリクス

35

ベースラインとしての組織（マネジメント）に始まり、アジャイルプロセスでは不確実性・変化への対応、そして、次に、進化・適応の方法に向かっています。

36

ソフトウェア工学人工物（artifact)のデザイン手法

37

『新ソフトウェア宣言』は、通称『呪縛宣言』とも呼ばれています。

2010年6月9日〜11日に横浜開港記念館で開催されたソフトウェアシンポジウム2010の中の

ワーキンググループ「ソフトウェアエンジニアリングの呪縛WG」に集まった賢人たちが、これか

らのソフトウェア、および、ソフトウェアエンジニアリングの方向性について議論したものが元になっています。

最終的には、「呪縛WG」の二人のコーディネータである大槻繁と濱勝巳氏によって、WG終了

後議論が重ねられ、今の７項目からなる形に集約されました。

http://www.exekt-lab.org/Home/newsoftdecl

新ソフトウェア宣言従来のソフトウェアに関わる諸活動の呪縛から解放され、新たな世界を築いていくためには、新たな呪縛に捕われ、新たな中心を設定していかなくてはなりません。我々は、以下の関心の候補が有望であると確信しています。

１．ソフトウェアは、数学的理論探求の上に成り立つ

２．ソフトウェアは、部分に還元することが不可能な全体である

３．ソフトウェアは、実行可能な知識である

４．ソフトウェアは、学びの副産物に過ぎない

５．ソフトウェアは、制約条件下で創造される美しい人工物である

６．ソフトウェアは、富を生む経済活動の資源である

７．ソフトウェアは、言語ゲームである

上記、基盤化、全体論、知働化、進化論、意匠論、経営論、遊戯論などの広範で、かつ、相互補完的アプローチが、新しい物語を生み出し、新たなる地平を切り開いていくことでしょう。

大槻繁，芝元俊久，高野明彦，竹内雅則，時本永吉，夏目和幸，萩原正義，羽生田栄一，濱勝巳，本橋正成，山田正樹，綿引琢磨

2010年6月11日横浜にてJune 11, 2010 at Yokohama

38

html5jパフォーマンス部

Session2

ソフトウェア工学の基礎を学ぶ

2014年6月5日

大槻 繁　株式会社一（いち）

http://1corp.co.jp

http://1corp.co.jp

http://www.ichicorp.biz/secondary/

一（いち）について＋ いくつかの随想など

http://www.agileprocess.jpアジャイルプロセス協議会

http://www.exekt-lab.org/Home知働化研究会

参考URL