********************************************************************** SWEST/DAS 共同基調講演 テーマ:XDDP:派生開発専用の開発アプローチ -XDDPの考え方について- 講師:清水 吉男(株式会社システムクリエイツ) 日時:2010/9/2 13:15〜14:35 参加人数:開始時 約220名 ********************************************************************** ■アジェンダ ○1.混乱する派生開発 ○2.XDDPの特徴 ○3.XDDPにおける追加機能要求仕様書 ○4.変更プロセスにおける「3点セット」 ○5.XDDPの効果 ■イントロ XDDP,USDMの人気が出てきている。 これまで1500回ほどしゃべってきた。 SWEST12 のテーマ「組み込み技術者すごくない?」が好き。 ○自己紹介 夢を持ってこの世界に入ってきた、でもすぐにやめる。 しばらくするとやはり戻ってくる。 原因はよくわかっていた。「顧客の要求をどう引き出すか?」 睡眠時間4時間 この中でUSDMがでてくる ・要求と仕様を使い分ける。 ・理由と背景をしっかりとつかむ。 この2点に気がつくことで、ここから仕様について顧客と問題が起こること・納期遅れ が出ることが一件もなくなった。 組み込み転向後2年でアメリカとの顧客と派生開発の仕事 初めての ・言語 ・ドメイン プライド ・納期遅れなし ・問題なし この時に現在の XDDP とほとんど同じものが出来上がった。 週35時間以内しか投入していないけれど上を実現 Extreme Programming 週40時間以内の触れ込み 私のほうが5時間少ない。 8時には家に帰っていた。 ■用語 USDM:Universal Specification Describing Manner 要求仕様がもれない表現方法とし て開発したもの。 XDDP:eXtreme Derivative Development Process 派生開発に対応するように開発した プロセス。 PFD:Process Flow Diagram 合理的なプロセスを設計するためのツールでDFDをアレンジ したもの。 ■1.混乱する派生開発 派生開発は組み込みに限定したものではない 現実は表現が違うだけでほとんど派生開発 XDDPは派生開発の1手法  保守開発をきれいに内包する。 現実  新規開発はほとんどない  機能追加が特徴 プロセスが不明確 ソースコードがどんどん劣化していく  本来は劣化するはずでないのに  劣化するとバグに追われる  勉強の時間が取れない  悪いループに入る 設計書・機能仕様所  設計しながら見つけていくものだという認識がされてしまっている。  ソースと仕様書が食い違っていく  変更箇所を見つけた→修正箇所を見つけた(7〜8割はあっているけど2〜3割は間違い。)  →2〜3割の間違いのうちの7割程度は気づくが、他は残る。  正しいと勘違い  何日か前の変更箇所を思い出せない、仕様書に反映する手段がない、記録できない  思い出す行為を繰り返す 本当に必要な箇所はどれだけだったのか考えてみましょう! p.7 ○機能追加と移植でトラブル 会計システムはがらっと変わる。  保守開発の世界で扱いきれない 改良保守が追かされたが  実際の追加がやっかい  (改良)保守開発が提唱される←この行削除 ・ベースのソースコードに新しい機能を追加しようとした場合、仕様書にうまく反映できない ・移植 もともと移植できるように開発されていない  臓器移植とまったく同じ  これを見越してある程度冗長性を持たせた設計をしなければならない  高度な設計技術が要求される p.8 変更を実現する方法は一種類ではない お客さんは気にしていないけれど 例:1〜4を表示していたけれど、条件がそろったときにc欄に表示  対応1:表示だけ変える。わかりやすい  対応2:データ区分を変更して対応。ひねくれてる  対応3:データ区分とは別に表示区分のコードを導入。本来やるべき対応 どこでどの実現方法を選択するか。 変更には明確な設計手法がない、「レビューするタイミングがない」ということが問題。 p.9 「全体理解」という言葉が飛び交うけれどそれって本当?  開発期間は限られている。  それさえできれば、できるはず。  できない、無理。最初からあきらめなさい。  思い込み、勘違いは入ってしまうもの。だからやっかい。  本人だけでは解決できない。  レビュー(ほかの人の目)が必要。  時間は有限だから、必要最小限の成果物と最小限の時間で行いたい。 p.10 私はおそらくCMMIを薦めた最初の人  大半は現場での導入の仕方がまずい。  SDS(ソフトウェア開発基準)がワンパターンになっている。  どこにそんなことが書いてある?どこにもない。  最も合理的な方法がなぜか通らない。  SDSとの間で不整合が起こるから。 ■2.XDDPの特徴 XDDPはそれのみで成立するわけではない p.12 ○XDDPトライアングル ・XDDP ・PFD 元はDFD。成果物が非常に読みづらかったものをアレンジ。  コーディング以降に有効 ・USDM  仕様をどうまとめるか  過去のコーディングの生産性は必ず生かせる。  「プロセスを定義する」だと「そのまま使う」ように感じる。  昔は私も使っていた言葉ですが、今は使いません。  今は、今回の要件に合うようにプロセスを「デザイン」する、と言っています。 p.13 ○2種類の要求仕様書 ・追加要求仕様書 ・変更要求仕様書 追加要求仕様書ではビフォーとアフターがある。  追加要求仕様書では「追加する」という表現を使ってはいけない!  追加に関しては追加用、変更に関しては変更用の開発アプローチを用いる。 p.14 ○派生開発アプローチ(上位) 1変更を扱う 2追加を扱うプロセス 追加があると変更要求仕様が必ずでる ・追加するという変更があるから 変更だけということはある、けれど変更がないことはありえない。 変更しかない場合は追加機能仕様書は不要。 p.15 ○派生開発アプローチ(変更を扱うプロセス) 1.1仕様などの資料からわかる変更部分 1.2ソースコードを見ないとわからない変更部分 1.3機能追加による変更部分   どこを変更しなければいけないか、どこを変更して対応するか   組み込みだとメモリの容量が足りないという独特の要求が。   応用ソフトのプログラマはスタックという概念がない   スタックのせいで動かなくなる。   スタックを含めてメモリをかき集めなければいけない。   機能追加だけではなく、メモリを集めるなどの変更を抽出する。 1.4変更要求TM の作成 1.5変更設計書の作成(直し方を考える) 1.6実施する   1時間何行の変更になる。この段階で90%先が見えている。   先が見えることが重要。普通のやり方では何時間かかるかはかれない 普通のやり方では1.5, 1.6 をいきなりやるために記録が残らない。 これだと後戻りが難しい。記録が残っていれば簡単に振り返られる。 p.16 ○派生開発アプローチ(機能追加を扱うプロセス) 2.1追加機能要求仕様書の作成 2.2以降はXDDPの管轄外。   自由な手法を使って。 p.17 ○3点セット ・変更要求仕様書what ・TM where ・変更設計書 how 普通は、what,where,how を同時に考えている。 what,where を考えた後に、 how を考えられるから、効率的。 変更方法を考えながらいじると、以前修正した箇所をもう一度 いじりなおす状況が発生しうる。 元に戻して位置から考え直す必要がある。 ■3.XDDPにおける追加機能要求仕様書 非常に重要なもの ・これがもたつくと変更の作業に時間がかかる ・精度が悪いと、あとで、変更箇所が変わってしまう。  次の開発で変更箇所に対してサイド変更が入ることになる。 成功する条件:1発できれいに仕上げる p.19 ○追加機能要求仕様書 基本的に新規開発の要求仕様書と同じ ・要求仕様書は作るための文書だから、一般の人に見せるわけではない。 ・関係者が特定(specify)できる表現であれば以前と変わっても構わない。 ・一般的な書き方にする必要がない Aさん、Bさんの想像することが一致させられる(specify)=合意 fix は不要。fix はあとで要求が変更されるということ。 CMMI で要求仕様書の内容について評価できない 「お客様を黙らせる方法は?」と聞かれた。  お客様が悪いと思っている。それはおかしいでしょう? p.20 仕様はどこにあるか?仕様は要求の中の ・「動詞」 ・「目的語」 にある。 振る舞いの中に動詞がある。動詞の裏には仕様が必要。 動詞を見つければ仕様をもらすことがなくなる! 動詞をうまく見せながら要求を書く。 範囲が広い・狭い=(動詞が多い・少ない) 数百の仕様を抽出するのは難しい。 ・インドのソフト会社は一度動くものを作ってから不足する仕様を足していこうとする ・USDMでうまく要求仕様書を作成すると1発でいける p.21 ○範囲の広い要求は分割・階層化 ・赤いところが動詞 ・動詞さえ見つけてしまえばOK 動詞を抽出するという考えに立てば、作成者がほとんど混乱しない。 一般に書かれている方法では途中から仕様の担当者を増やすことは非常に危険  書き方が変わるから。 USDMでは要求と仕様をしっかりとわける 仕様の漏れは実は  要求漏れ、もしくは要求の中の動詞もれ 仕様の変更率が0.5%に抑えることさえできる。 それだけうまく書ける。 p.23 ○要求仕様の条件 「 ・仕様は要求から導出 ・実現可能性が見える ・検証可能性が見える ・品質要求も求められる 」  ↑これらが揃うと、確認の質問をしなくてOKという段階 p.24 ○仕様の抽出 認定仕様:「このレベルにおいてもう詳細化する必要がない」という場合、      「□□□」チェックボックスを要求につけて仕様と認定した。 要求に「□□□」がついていると仕様とみなしたということ。 「□□□」はレビュー済み、テスト済みなどのチェックに使う。 要求仕様書は慣れてくるととても簡単に書ける。ある種のテクニック。 うまくやることで変更プロセスに余裕を作り出せる バージョンアップ時にも要求仕様書が役に立つ。 ■4.変更プロセスにおける「3点セット」 ○変更要求仕様書とは プロジェクトで変更したいことについて、選ばれた関係者が 「どの変更方法で」ということを含めて合意した文書 ・変更仕様は必ずソースコードレベル(関数仕様のレベル)で記述 p.27 ○変更要求の範囲と理由 ・変更には必ず理由がある ・理由なく変更するのであれば、元が悪い、「元が悪いという理由がある」ね。 理由を知ることで変更が無意味だとわかる場合がある。 ・商品一覧と在庫確認リスト(←範囲) ・類似商品を解決するために写真を追加   写真を追加することで、その問題は解決する?   類似しているのに? この問題に気がつかないといけない。 牧野富太郎の植物図鑑はすべて手書き。写真は一切ない。 特徴を強調して描かれている。写真では見えない。 本当に伝えたいときは写真よりもデッサンの方が良いことがある。 変更に関しては全て before, after をちゃんと書く。 追加・削除はそれ自体が before, after を含んでいる。 ・変更の場合は  before がある。 ・追加の場合は  before がないので、どこに追かするのか見失わないように注意。 p.32 TMのマトリクスの枠の中には最終的には関数名が入る。 p.35 ソースコードは一気に変更 事前に行数が見積もれている 焦ることがない 変更に必要な時間が分かっている もし、1人の人が全工程を担当していれば、ソースコードを3回見ることになる。 ・what ・where ・how の観点で。 開発終盤で人員の追加投入は一般的にはタブーだが、 この手法なら大丈夫。 公式文書は最終的に確信がもてるまで一切触るな。 ■5.XDDPの効果 p.38 ○遅れない仕組み before,after を探す際のコストは変わらない。 普通は、ここでどう直すかに入ってしまう。 その前に1手間かける。  「言葉で表現するのが難しいが、コードでなら大丈夫!」  ↑嘘だ。言葉で表現できないのは、確信をもてていないからでしょう? XDDPを使用すると  1時間あたりのコード記述量(生産性)が非常に高くなる。  きちんとした必要最小限のプロセスで、きれいな文書を残して、バグも少なく、  バグの修正にかかる時間も短くなる。 派生開発では、もともとのプログラムは動いていた。  修正した箇所が残っていればバグつぶしが楽。 p.39 ○2種類の生産性 「生成行数/全工程の工数」あまり使い道がないが、念のためとっておいてください。 「生成行数/実装工程の工数」の生産性を上げていく。1時間当たり130行の生産にできる。 140行の実績もあり。 p.40 ○「一人プロジェクト」の問題の回避・複数チームでの開発 みんなで協力できる p.42 XDDPで従来かかる時間の3割程度の時間が余る。  →次回に備える。  ほとんどは派生開発だから 派生開発がうまくできなければ明日はない。 ■質疑応答 ○Aさん 質問1  単一の企業で行うならばこの手法が使えると思います。  会社間をまたぐ例はありますか? 回答1  またぎっぱなしになっていて、確認のプロセスがないことが多い。  それだと問題。うまくいかない。これが1点。  もう1点は、なぜ会社をまたぐのか。  会社をまたぐ必要がある時点で実はおかしい。  生産性が十分に高ければ外注する必要がない。 コストダウンはオフショア開発では解決しない  オフショアしたところで、発注側に人は残っている。  人が余っていれば解雇しなければいけない。  外注するだけでコストダウンはできないよね。 1994,1995に最後のプロジェクト(2つ)を同時に担当 ・外部に情報を漏らさないでやるプロジェクト ・内線システムのプロジェクト 両方とも納期を守った。 ○Bさん 質問2  社内でXDDPを試してみようとした。  簡単にできるというけれど、実際やってみると難しかった。  清水さんなら簡単?高度なレビュアーが必要?  コンサルタントに入ってもらえますか? 回答2  本を読んだらできますよ。  「ここまで書いたらコンサルタントいらないじゃないか?」  と怒られるくらいの勢いで書いています。  コンサルタントを呼ぶのは簡単ですが、コンサルタントに甘えると、  コンサルタントがいなくなったときに何もできない。  その事を分かった上でコンサルタントを呼ぶなら良いのではないでしょうか。 ○Cさん 質問3  以前ソフトウェアプレスの記事を読んだ。  組織では対応できなかった。  個人的に変更要求仕様書、変更設計書、TM を書いてやってみた。  TMを見せたら関数レベルで書いてあってレビュアーがショック状態に。  細かすぎてレビューできないといわれた。 回答3  どのレベルで変更しているのだろう?  関数名で書いているけど、見ているレベルは変わらない。  それがわからなければ、組織の能力の限界かもしれない。  そこを解決しないといけないかも。 2つの提案 ・開発陣に女性を入れる   男性はできない理由を考える。女性は避ける方法を考える。 ・これで見れないなら、どれなら見れるのか?   どこまでならできるのか?がわかれば前進する。 女性を入れるのはお勧め ○Dさん 質問4  わかりやすかったけれど、分析のところが属人性が強いのでは?  バックグラウンドを知っていなければできないのでは? 質問5  6月にキックオフがあったけれど半分がコンサルを受けていない組織。  コンサルを受けていない組織の能力はどの程度だった? 回答5  すごいです。相当な能力を持っている。  それぐらいのレベルを本来持っているべき。 回答4  無知見プロジェクトが1つの解決法。  ドメインも知らないソースも知らないという人でも、  ソフトウェアエンジニアリングに習熟していればOK.  ソースコードを理解するということは、ソースコードから別の形にしなければいけない。  ソフトウェアエンジニアリング手法の中には表現手法がたくさんある。  誰かがこの技術を持っている 設計技術があると非常に助かる。 すごい例を出すよ。 ある会社で、A社が受注。  3つのモジュールがある。  3つ目に人が足りないと相談された。3人必要だといわれた。  1,2とは別個に切り分ける。  3つ目のみに集中して担当。  設計技術を持ったドメインまったく知らない20代の技術者にXDDPを教えて開発  50時間未満で7000行。  1時間120行程度。  この担当者のバグは1件もない。関係者が指摘した点のみが7個のバグに。  担当者は気づいていた。  1人で済ませてしまった。その時点でA社はまだモジュールが完成できていない。 ○Eさん 質問6  ベースが1つで複数のXDDPが平行して開発するという形は可能か?  複数のベースがある場合は? 回答6  モデルとしてわかれていて、先行チームと後発チームが出てくる。  混乱を発生させないためには、  ソースコードをいじるのを最後にしなければならない。  ずらしてやると先行チームと同じ箇所の変更点が出てくることがある。  その時点で、お互いに協議して解決方法を考える。  先行チームがバグを出した場合、後発チームに相談をしながら直す。  2モデルからの4個を五月雨式開発したら3個は成功。  1個だけ失敗したけれど、原因はXDDPを知っている人が足りなかったため。 質問7  公式文書どういったものでしょうか? 回答7  派生開発では公式文書を早い段階でいじっている。  新規開発でまだ要求仕様書は仕掛品、設計書も確定していない  派生開発なら追加要求仕様書が仕掛品。  まだ、これらは公式文書ではない。  レビューを終えてぎりぎりまで遅らせてソースコードを先に直す。  その後、公式文書をいじる。  それまでは公式文書は見るだけ。 ■まとめ はじめに派生開発が重要になり、今後も派生開発が重要な位置を占めていくことを説明した。 そして、XDDP の特徴を説明し、追加要求仕様書・変更要求仕様書について解説しながら、 派生開発のアプローチに触れた。 変更プロセスにおける「3点セット」の成果物について解説し、XDDP による生産性の 向上について実例を用いて説明した。 以上。