iot 時代に対応するための - ipa•...

System Creates

Page© System Creates Inc., All rights reserved ［IoT 時代に対応するためのXDDPの効果的な活用］ 1

SEC高信頼化技術適用事例セミナー

IoT 時代に対応するための　　　XDDPの効果的な活用

派生開発推進協議会(AFFORDD)代表　清水吉男

http://affordd.jp/

株式会社システムクリエイツ代表取締役清水吉男　

URL=http://homepage3.nifty.com/koha_hp　(更新停止中） http://kohablog.cocolog-nifty.com/（ブログ）　

[email protected]

mailto:[email protected]?subject=

System Creates


自己紹介：清水吉男•株式会社システムクリエイツ代表取締役 •派生開発推進協議会代表　　　　　　プロフィール• 1968年からソフトウェアの世界に入り、企業の業務システムやオンラインシステムの開発を手掛ける。

XDDP

●「SEの仕事を楽しくしよう」（SRC）●「わがSE人生に一片の悔いなし」（技術評論社：新書）

USDM

• 2010年に派生開発推進協議会を設立し、これらの普及活動へ。• 『硬派のホームページ』主催者

• CMMとの出会いを機に、自ら考案した要求の仕様化技法(USDM)や派生開発向けの開発プロセス(XDDP)やプロセスの設計ツールとしてのPFDを提案し、1995年からプロセス改善のコンサルティングを開始。

• 1977年に組み込みシステムの世界に転じ、POSシステムやインクジェットプリンターなどの多くの製品の開発に携わる。

System Creates


agenda

1. IoT への時代のうねり

2.日本の開発現場が犯した過ち

3. XDDPによる派生開発の支援

4.「遷宮」の文化を参考に

XDDP： eXtreme Derivative Development Process の略．派生開発に対応するように開発したプロセスです．（参考文献②）USDM：Universal Specification Describing Manner の略．要求仕様がモレない表現方法として開発したものです．（参考文献①）PFD　： Process Flow Diagram の略．合理的なプロセスを設計するためのツールでDFDをアレンジしたものです。

CMM (R) 、Capability Maturity Model、およびCapability Maturity Modeling は、米国特許商標局に登録されています。CMMISM はカーネギーメロン大学のサービスマークです。

System Creates


1.IoT への時代のうねり• 機能の競争から価値の競争へ• ソフトウェアによる新しい競争へ• Software Defined 化の意味

• GEの選択に見るIoTの意味

System Creates


デフレの波に翻弄されている間に旧態依然とした産業構造

経済は沈んだまま官製円安

売れるものがない

IoTわーい！

新しいビジネスチャンスだ！

困ったなIoTって何をすればいいの?

そんな時に・・

政府主導成長戦略

System Creates


新しい時代の背景にあるもの

高速通信の環境

ディープラーニングなどのビッグデータ解析技術

IoT

高性能なセンサー技術

これらを使ってどのような「価値」を提供するか

安価なクラウド環境

機能の競争から価値の競争へ

ソフトウェア開発におけるQCDの同時達成技術

System Creates


IoT…新しい競争の時代へ• あらゆるものが「ソフトウェア」の上で成り立つ時代へ

IT

Device

Device

Device

DB(クラウド？)

IoTの構成イメージビジネスに勝つために何が必要か？

競争に勝つための統計処理故障の予防情報性能向上の情報ディープラーニング

Deviceの機能関連するデータの収集Device自身の診断データ

もっと便利な使い方を提供

System Creates

Page© System Creates Inc., All rights reserved ［IoT 時代に対応するためのXDDPの効果的な活用］

✦Software Defined XXX

8

「Software Defined XXX」での競争へ

①テスラモデルs のフロントパネルの様子

後から変更（改良）してDLで提供■ 火災対応➡緊急措置で車高操作を制限■ レーダークルーズコントロールの追加■ 電池切れ予防機能の追加■ 顧客要望：クリーピング機能を追加■ ガレージへの自動入出庫機能を追加■ 高速道路での自動運転を追加（有料）

早く買って後悔しない①　http://image.search.yahoo.co.jp/search?rkf=2&ei=UTF-8&p=テスラ+モデルs写真の出所

CarEngineMachineDeviceなど

• 継続的な価値の提供• デファクトスタンダード化• 価格競争に巻き込まれない

System Creates


GEの Industrial Internet の狙い✦ GEは「Industrial Internet」で何を狙っているのか① 製品のパフォーマンスを最適にする② 補修の必要性を細かく予測し実質的に故障しない製品にする③ 当該製品を含むトータルのパフォーマンスを最適にする

航空機のエンジンや医療機器の「製造」も「外」に出し、GE本体は「ソフト会社」に転身 !

•デジタル化の取り組みをアウトソースしてはならない•製造業でCIOが主役になる時代が到来した　　　　　　　　　　　　　ジェフ・イメルト（GE会長）

IoT は GEにこれだけの決断をさせた！

Wikipediaより引用

System Creates


日本の企業に突きつけられた課題

このような市場の要求に対して、日本の企業（製造業を含む）はどのように対応するのだろうか？

企業のトップは、自社のソフトウェアの開発現場の状況を正しく認識しているだろうか？

System Creates


2.日本の開発現場が犯した過ち• 80年代の取り組みのミス• オフショアの後遺症• 技術力の低下• オフショアからの回帰• ブルーカラー化の問題

若い世代は、このような歴史を知らない？

System Creates


80年代に品質要求への対応ミス■ 1980年代の品質要求への対応ミスで、90年代以降の納期やコストの要求に対してプロセスで対応できない事態に陥った

時代市場の要求支援ツール・考え方等日本の対応

80年代品質への要求 F•クロスビー「Quality is Free」ISO、CMM、6Σ

テスト工程で品質に対応この後の全ての対応に悪影響

90年代前半

＋納期の短縮要求 EA，SPL，スケジューラー自動生成ツール、CASEツールパッケージソフトBPR

ツールに合わせてプロセスを変化させることができなかった外注化と一人の分担を狭くして人海戦術で対応

90年代後半

＋コスト削減要求開発拠点の分散プロセスの多様性　　→　agile開発へ

プロセスの必要性を見極めることができなかった一層の外注化と「オフショア」へソースコードの劣化と開発技術の空洞化

2000年以降

QCDの同時要求機能から価値へ

agile開発クラウド、IoTなど

???（何をすればいいのかわからない？）

System Creates


プロセスで品質要求に対応すべきだった

当時の日本の品質は「テスト」によって獲得したもの

■ 「Quality is Free」 (フィリップ・クロスビー )◆ 「最初から正しく仕事をすれば高品質は確保できる」◆ 「品質コスト（予防コスト＋評価コスト＋失敗コスト）は、ものごとを正しく行わないことの代償」

「品質」に対して強い要求世界はプロセスで対応

ISO、6Σ、CMM（CMMI）支援

80年代

多くの組織では、プロセスを変化させる技術も　変化させたプロセスを安定させる技術も習得せず

プロセスを「固定」した

System Creates


■ 納期短縮要求＝人海戦術で細分化過度な外注（オフショア）化の後遺症

「Device」では新規開発が避けられない！

■ コスト削減要求＝外部（オフショアを含む）へ委託

CASEツールパッケージソフト

要求仕様も書けないソースコードの劣化

開発技術の空洞化

RTOSも搭載していない見積もりもできない

派生開発を外注で回しているだけで新規開発もやったことがない

BPR

90年代～

もスルーした

外注管理もできない

System Creates


IoTもオフショアでやるつもりですか？

企業の収入源の開発は自前で対応すべき！

企業の収入源派生開発の技術で他社に負けない技術が必要

新機開発で競争力を組み入れる派生開発で

機敏で効率的に価値を提供し続ける

Device

ITDB

•「IoT」で勝つための仕掛けが必要• 劣化したソースコードへの対応も• RTOSだって搭載しなくちゃ• 保守性にも対応しないと・・・

System Creates


「IoT」に対応できるエンジニアがいない！「日本のソフトウェア業界はブルーカラーを作ってきた　これは、ソフトウェアイノベーションを阻害するもの」

ロバート・コール（CA大学バークレー校名誉教授／同志社大学大学院）

この状態で、誰が「IoT」の構想を考え出せるのか？

人海戦術で狭い守備範囲

ソフトウェアエンジニアリングの本も読んでいない

外注任せで要求仕様も書けない

長いこと設計もしていない

System Creates


こんな状態で新規開発できますか？

すぐには新規開発できない

自社で派生開発に対応へ

当面は、派生開発で回すしかないが

新規開発への準備も必要

派生開発も自前でやっていない

現行製品のバージョンアップを続ける必要がある

新規に作り直す必要もある・・

System Creates


3.XDDPによる派生開発の支援• XDDPとは• 機能追加と変更とで異なるプロセス• 最小限の秩序で派生開発の混乱を抑制• 変更３点セットの効果• 新規開発の機会確保

XDDPなどの書き方の詳細は、参考文献をご覧ください。本稿では、XDDPという派生開発向けのプロセスが、IoT 時代においてどのよう活用できるかという点について説明します。

System Creates


２通りの対応• ベースのソースコードに機能追加と変更を加えてバージョンアップする方法に２通りある

系列開発派生開発

SPLE XDDP

• IoTの要求に応えるのに、いつまでも派生開発で回し続けることができるか？

バージョンアップのソースコード

バージョンアップのソースコード

「系統図」ができる

「コア」部分はXDDPで維持

機能追加と変更

ベースのソースコード

System Creates


混乱する派生開発• 「保守」と比べても「派生開発」は混乱しやすい

• 特に「変更」作業では「秩序」が失われている

追加機能の要求仕様書

変更の要求仕様書は？

追加機能を受け入れるための変更は？

どこをどのように変更して、追加機能を受け入れるかは、追加機能の担当者に任されている

該当箇所を事前にレビューせずに見つけ次第にソースコードを変更して混乱しているここが混乱！

変更

競争

機能追加

System Creates

Page© System Creates Inc., All rights reserved ［IoT 時代に対応するためのXDDPの効果的な活用］ 21DFDを使ってプロセスを設計する方法を持っていた

1978年にXDDPを考案

XDDPを考案•変更と機能追加を別プロセス•変更３点セットに書き出す•before / after で情報を表現•レビューを終えてから変更

依頼主は海外初めてのドメイン初めて見るソースコード言語も初めて

要求に応える新しいプロセスを考え出す

依頼＝40数項目の機能追加と変更を３ヶ月で！

変化＝DFDで今回のプロセスを設計安定化＝DFD上でシミュレーション

USDM機能追加と変更の要求仕様書に対応

幸運

System Creates


機能追加と変更では求められていることが違う• 「XDDP」では機能追加と変更を異なるプロセスで対応する

追加機能要求仕様作成

統合テスト

追加機能分の設計

追加機能分の実装

追加機能分テスト

受入れ方法　

公式文書の更新

コードの変更

変更分のテスト

変更要求仕様書とTMの作成

変更設計書の作成

変更３点セット① 変更要求仕様書② TM（Traceability Matrix)③ 変更設計書

変更要求仕様書はすべての「変更」を扱う

XDDPとは

System Creates


変更プロセスですべての変更を扱う■ ソースコードしかない状況で、できることは限られる■ この状況で作成できる必要最小限の成果物とそれを作成する順序を工夫

変更要求書1.1

変更箇所を仕様書に記述する

追加機能要求仕様書

1.4変更要求TMを作成する

1.5変更設計書を作成する

1.6ソースコードを一斉に変更する

スペックアウト資料*

設計書等モジュール情報

事前調査/スペックアウト

資料*変更設計書

更新後ソースファイル

（参照）

1.2変更箇所についてソース等を調査検討する

1.3追加要求の変更仕様を抽出する

補助資料他、関連資料

元のソースファイル*



変更要求

変更仕様TM

変更仕様

変更仕様TM

スペックアウト情報

ソースファイル単位

（参照）

TM情報

交点情報

追加要求

変更要求

　　　　　　　　　　　　TM

変更要求仕様書

調査情報

XDDPとは

System Creates


「変更３点セット」で「部分理解」を緩和する■ 「変更箇所」を「before / after」で表現することで担当者の理解した状況が見える

■ 効果的なレビューによって担当者の「部分理解」の状態を緩和する

• 「影響箇所」に気づく機会を得てバグも減少する

成果物カバー範囲記述内容レビュー機会

変更要求仕様書 What（Why）

今の振る舞いをどのように変更するかなぜ、変更するのか？before / after で記述する

○○

ＴＭ Where 変更する仕様がどこにあるか？ ○

変更設計書 How 具体的な変更方法を記述する原則として before / after で記述 ○ ○

XDDPとは

System Creates

Page© System Creates Inc., All rights reserved IoT時代の派生開発（１） 25

■ XDDPでは、効果的なレビューでソースコード変更前に問題に気づく

XDDPはバグを根元から断つ

機能追加

• USDMを使うことで、精度の高い要求仕様が書ける→ベースライン設定後の仕様変更が減る→以降のバージョンアップでも変更が減る

変更

• すべての変更箇所を書き出してレビューを可能にする• 効果的なレビューで「部分理解」を状態を緩和する• すべての変更箇所を把握したあとで変更方法を考える• より良い変更方法に気付いた時は躊躇なく対応を変える

バグを減らして工数を余らせる

XDDPの効果

System Creates


■ 1978年～1994年：30例ほどの派生開発に対応■ 異なるドメイン■ 社員が扱いたくないソースコード■ 外注には厳しい納期

XDDPにおける私の経験

XDDPで全てON Schedule

ドメインや要求の特徴に合わせてXDDPのプロセスを調整

XDDPの基本のプロセスは不変

合理的な調査プロセス変更３点セット時間差レビュー変更行数の見積もり実装生産性の計測

•メインの顧客には　週35時間以内で対応

•余った時間で「次」に備えてきた

XDDPの効果

System Creates


■ 多くの事例の中から最高の結果が出た理由は？■ 逆に、この事実からXDDPの効果が出ない理由が見える

（客先で）最高の結果が出た事例と理由状況「S1」「S2」「S３」の３つのサブシステムの派生開発をまとめてA社が受注しばらくして、「S3」の要員が３名足りないという申し出あり

提案

「S3」の要求をヒアリングした結果、１名（要設計経験）で足りると判断「S3」をA社から切り離し、別の外注業社から探すこと、A社には受注金額をそのままに「S1」「S2」に範囲を限定することを提案

準備新規開発の経験のみの５年目の若手XDDPのトレーニング、ドメインやソースコードの説明に３週間（2~3日／週）

結果

作業着手から「2.5ヶ月」で完成。ソースコード変更工数＝50時間変更行数＝7000行（削除＝1500行）。実装生産性＝140行／H（110行／H）担当者の責任バグ＝０件。この時、A社の作業はまだ終了せず

XDDPの効果

System Creates


XDDPで新規開発の機会を確保• 現実問題として派生開発を中断できない• その中で、新規開発の準備を進めるしかない

派生開発

派生開発：べからず集の作成

派生開発

新規開発

競争に勝つ仕掛け

一部再利用も

勝つための仕掛けを組み込む機会

新規開発の準備

XDDPで捻出した工数

アーキテクチャ設計の知識

要求仕様や機能設計の技術

シミュレーションによる検証

System Creates


■ 高度なレベルで保守性を満たすための設計方法■ 派生開発の中で苦い経験が生きる■ 保守性を意識した状態遷移のいろんな実現方法■ グローバルデータを使わない方法

■ 短期間でアーキテクチャを再構築する方法■ 既存システムであることを生かした再構築法

■ マルチタスクの各タスクを単体でテストする方法■ 一人で複数のタスクを担当するための支援

■ アーキテクチャを側面から支援する設計ルール■ など

新規開発の準備とは新規開発に備えて派生開発の合間に考えること

System Creates


4.「遷宮」の文化を参考に• 新規開発と派生開発を持つ組織へ

System Creates


■ 新規開発の要員を確保できる■ 派生開発と両方に対応できるように育成■ 新規開発を意識することで時代の変化に敏感になる■ 勝つためのアーキテクチャの研究を継続できる■ 社内の技術ロードマップに沿って教育できる

一定期間で新規開発するメリット方針＝５～１０年で作り変える

「派生開発」のあり方も変わる

組織の文化へ

System Creates


新規開発と派生開発の両方の技術を• IoTの時代では、比較的短い間隔で新規開発が必要になる可能性がある

「遷宮」の考え方を活用

派生開発（XDDP）新規開発

ソフトウェアの開発⼒力力なくして事業は成り⽴立立たない

勝ち続ける組織へ

ソフト開発の世界にも応用

System Creates


IoT 時代において派生開発（XDDP）が重要かおわかりいただけたでしょうか

短い時間でしたが・・・

iot 時代に対応するための - ipa•...

Documents