派生開発のXDDPとかの話を、USDMの清水氏から聞いてきた！

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「派生開発をリーンにするXDDP」をメモメモ
XDDPとUSDMの清水吉男氏ともう一人（だれだったっけ？）のかけあいの形で講演してました。

---

派生開発をリーンにするXDDP

■派生開発推進協議会（AFFORDD：あふぉーど)の紹介
　　２０１０年２月
・派生開発カンファレンス（次回６／６）
・１０テーマほどの研究会
　　・調整の克服方法
　　・USDMの入門
　　・XDDPの入門など
・研究会主催の「フォーラム」
・XDDPやUSDMに関する勉強会

■派生開発とは
・組み込みの現場では使われていた言葉
　　→改造（保守という言葉はつかわれなかった）
　　→既存のソースコードをベース
　　　機能追加が入る
　　　　→背景：競争＝予想できない→くずれていく
・派生どれくらい？
　組み込みの９０％以上は派生開発

・派生開発の課題とは？
　新規開発だと、工数と予算がつく
　でも、派生開発だと→変更＝納期がシビア
　　→変更行数で見積もられたら大変！
　要求仕様を書いて・・・
　　派生開発はそういううパターンではない
　　　　機能追加と変更がまじっている
　　　　変更のところで大きく
　　　　　→プロセスが合わない
　　新規開発くずし
　　　　変更箇所を完成させていく
　　　　　文章を完成させるように変更
　　ソースコードしかない会社
　　　　ソースコードをいきなり変更
　　→変更に対するデグレード：品質低下

・ソフトでリーンというと、アジャイル開発
　　XDDPとスクラムで発表されている
　　成果物が伴っていないと
　　変更という考え方がアジャイルでは対応しにくい

XDDPとは
・XDDP機能追加と変更依頼＝仕様知ってる人、国内にいない
　　→保守のプロセスではできない

・部分理解を前提としたレビュー中心の手法
　　→この方法でいける！
　　　ソースコードが分からないケースでも

・機能追加と変更を異なるプロセスで
　　AをBに変更→それいがいの箇所を探す
　　要求が異なる
　　変更３点セットの最小限の成果物を作る
　　　　変更箇所：Before→After
　　　　　Before：担当者の理解

・XDDP：コーディングをすぐしない

XDDPとリーン
・無駄をなくす
・品質を作りこむ

・知識を作り出す
　　AをBに直す→思わぬところに不具合＝わからない
　　　関係ないならバグでないはず！
　　　変更箇所を残している＝後ろから探れる
　　　→知識がたまる

・決定を遅らせる
　　いきなり変更：早く片付けたい→変更量を見積もっていない
　　　→変更同士が絡み合う：さっさと変更することが早くならない
　　　→１つの条件：見積もれている
　　　→生産性データを使う→ここまで遅らせるということがわかる

・似ている考えかた
　　手戻りを減らしたい
　　LAMDAプロセス→レビューを小さくまわす

ソフト
　　依存性が高い：XDDP
　　依存性が低い：アジャイル
ハード
　　依存性が高い：リーン製品開発
　　依存性が低い：リーン生産（TPS)

派生開発
　　変更してバグになった→ばんそこはってなおす
　　　→ソースコードは劣化している

レビュー
　変更要求仕様書：ここを、なぜ
　変更方法を考える：トレーサビリティマトリックス
　変更する
レビュアー：自分のシマにはいってしまう
トレーサビリティ　マトリックス（TM)
　原則、全部立てる。並べ方を変えない　

ソフトウェア開発を加速させるリーン開発の原則

昨日、リーンカンファレンス２０１４にいってきた。その中の講演の１つ「ソフトウェア開発を加速させるリーン開発の原則」をメモメモ

---

・リーン開発の原則
　ソフトウェア開発の現場で継続的な改善のきっかけを見つける視点を提供

・スピーカー：天野　勝　氏
　　これだけKPT（振り返りのときに使う）
　　日経コンピューターで連載

・会社
　　福井県にあるのが売り

・リーンソフトウェア開発とは
　リーンから、リーンソフトウェア開発へ
　リーンの日本語
　　　がりがり？
　　　贅肉を落とした（ほそまっちょ？）○

　リーンの起源
　　　トヨタ生産方式の研究
　　　TPSの家（出展「ザ　トヨタウェイ（上巻）」
　　　トヨタウェイ→ジャストインタイム、自働化

・リーン思考の原則
　　リーンシンキング
　　　製造、製品開発の原則：７つの原則
　　　→応用可能（金融業務、保険、医療）

・リーンソフトウェア開発
　　　日本だと２００５
　　　２００９年に本質 from concept to cash
　　　　→儲かるのが正義
　　　　　アイデアをいかにカネに変えるか

　ソフトウェア（ITサービス）の特徴
　　・開発のメインは設計
　　　　製造やデリバリーの開発／コストはわずか
　　　　　製造：コンパイルする、コピーする
　　　　　デリバリー：サーバーに配布する、利用者がサーバーにアクセスする

　　・リリース後の改修コストが低い
　　　　　回収は不要

　　・物理法則が及ばない
　　　　　重さ、大きさがない
　　　　　劣化しない
　　→製造の考え方は、そのままは通用しない

・リーン開発で重視する「品質」
　　品質の定義　SQuBOKから
　　　　→人の名前がはいっている（～がいった）
　　品質が高ければ儲かる：不具合があるかないかではない
　　余分な機能の無駄→まったく利用されない機能４５％

・リーン開発
　　言ったもん勝ち？
　　ニーズ→システム
　　　システム開発にはさまざまなリスクが潜んでいる

・ニーズに合う商品を提供するために
　　無駄を省いてニーズの獲得から商品提供をすばやく行う

・アジャイル開発
　　技術の総称：ひっくるめて！
　　アジャイルソフトウェア開発の誕生
　　　　→アジャイルソフトウェア開発宣言
　　AKB：事務所はちがうけど、同じ名前で
　　アジャイル：さまざま手法違うけど、同じ名前で

　　ポペンディック夫妻：この宣言の人ではない

　　アジャイルとリーンの関係
　　　図がある

・リーンソフトウェア開発の原則
（１）無駄をなくす
　　　ポペンディックさん「ソフトウェア７つの無駄」もかえている
　　　無駄に３つの種類
　　　　　お客さんの無駄：レビュー（レビューせずにいいものができれば）
　　　　→生産性があがる
　　　　　　組織の無駄を０にすれば、付加価値にあがる

　　　バリューストリームマップでプロセスの無駄を見る

（２）品質を作りこむ
　　作って直すのではなく、直さないように作る
　　→テスト駆動開発
　　　後で直すより、早く直せば安くつく

（３）知識を作り出す
　　学習サイクルをまわしながら進める
　　　　振り返り
　　　タイマー駆動／イベント駆動
　　　イテレーション内でPDCA

（４）決定を遅らせる
　決定を遅らせた分だけ知識が増え、ぎりぎりまで磨ける
　　　→ぎりぎりがどこまでか？
　　　→継続的インテグレーション　VS　ビッグバン結合
　　　　　モジュールを少しづつ足す

（５）早く提供する
　提供能力を上げる
　イテレーションからフローへ
　　　→カンバン、継続的デリバリーを自動で

（６）人を尊重する
　　ともに働く人
　　リーダーシップのあり方
　　　　支配型リーダーからサーバント型へ
　　見える化
　　　　異常を見えるようにし、行動を誘発する仕組み
　　　　カイゼンの道具で管理の道具ではない
　　タスクボード
　　KPT(けぷと）
　　バグレゴ
　　振り返り会で出た　「机を取り払う」を実行

（７）全体を最適化する
　　全体が滞りなく流れる
　　KANBAN＝タスクボード＋流量制限

　　システム開発からビジネス開発へ
　　　→ビジネスとシステムは一体

テスト要求分析とテスト観点

昨日、西先生の「テスト観点によるテスト要求分析モデルの構築」
について聞いてきたので、メモメモ

---

■テストには、テストのための要求分析が必要である

テストする

５年位前
　テスト設計（ですと計画）、テスト実施

今どき
　テスト要求分析
　テストアーキテクチャ設計
　テスト詳細設計
　テスト実装
　テスト実施


■テスト開発プロセスの基本的考え方
・品質を高めないといけないプレッシャーは意外とさらされていない
・仕様で明記されていない非機能特性を考えていない

■テスト要求分析で考える
１）要求の源泉の準備
　　→自分たちでステークホルダーになりきって
　　　ブレーンストーミングや仮想ヒアリング
２）要求獲得と分割
　　エンジニアリング要求とマネジメント的要求をわける

３）モデル

■テスト観点
　・機能：テスト項目の鳥が
　パラメータ
　状態
　タイミング
　組み合わせ
　性能
　信頼性
　GUI
　出荷先
　障害対応性
　セキュリティ
　（いくつかぬけた）

■テスト観点をモデリングする
　マイヤーず
　システムの振る舞い

■テスト観点
　　因子？
　　要求？
　　テスト目的？

・テスト観点
　　→正三角形
・テストケース
　　→１，１，２、　１，２，３

・テストスクリプト
　　→ぱそこん・・・

テスト観点図（NGT)
VSteP

漏れをなくす→ステレオタイプ

詳細化の種類を限定して

テスト観点図に書き直す
条件ベース：抜けがある
　　リコメンデーション部分のテストがない
　　あいまい記述が抜ける
　　おいしくないが抜けている
観点ベース：抜けがない