書籍執筆で継続的デリバリー

@kaorun55さんがJenkins勉強会のLT資料を公開されたのでリンクしておく。
記事や原稿、提案資料を書く人は、テキストから自動ビルドしてPDF、Wordなどの印刷媒体へ自動ビルドする手法が必要になった時代だと思う。

【元ネタ】

Jenkins Continuous Delivery from Kaoru NAKAMURA

オライリー・ジャパンのePUBフォーマットを支える制作システム - O'Reilly Japan Community Blog

Geekなぺーじ:svn＋TeXでcommitするとPDF - オーム社開発部の出版システムでの書籍執筆

sphinxで Wordファイル(docx)出力する．(Windows): 100ねんごの未来予想図

sphinx で word / epub / pdf で出力した結果(windows): 100ねんごの未来予想図

Overview ? Sphinx v1.0 (hg) documentation

Sphinxでドキュメントを生成する - Basic

epub出版システムの作り方: プログラマの思索

電子書籍の作り方part7: プログラマの思索

@kaorun55さんの環境は、Sphinx上でテキストベースの原稿を書き、CloudBees というクラウドホスティングサービスにあるJenkinsを使って、PDFやepubなどを自動ビルドで出力しているようだ。

この手法の利点はいくつかある。
一つは、原稿がテキストベースなので、SubversionやGitなどのバージョン管理と相性がよく、Sphinxのようなドキュメント生成ツールと組み合わせれば、PDFやepubなど各種媒体に出力できること。

この考え方は、昔のLaTexも同じような発想だと思う。
例えば、物理や数学の論文を書く人は、Texで英文の論文を書いて、雑誌に投稿する時にTexをビルドしてeps、dviなどに出力して渡していた。
今なら、SphinxやREViewのようなツールでテキストからPDFやepub、HTMLなど各種フォーマットへいくらでも出力できる。
しかも、blockdiagramなどのツールを使えば、ネットワーク図やシーケンス図などもテキストベースから変換できるので、バージョン管理と相性が良い。
@kaorun55さんの話では、PDFは印刷媒体として相性が良いが、iPadやiPhoneなどのスマートフォンで読む時はepubが相性が良いらしい。
確かに、スマートフォンでいつでも原稿を読めるようにしておけば、即座にフィードバックしてもらえるだろう。

でも、一つ疑問があるのは、Sphinxなどに索引や目次、引用文献などを生成する機能があるのか、という点。
Texには索引や目次、引用文献を自動生成する機能がある。
紙媒体やWordで原稿を書く時に面倒な作業は、索引や文献を抽出することだ。

だから、20年以上前のIT化されていない出版スタイルでは、索引や文献を手作業で抽出後、京大式カードなどで記録してファイリングしていた。
梅棹 忠夫さんの「知的生産の技術」の本では、そんな時代では索引作りが学者として重要な作業であったことを示している。

索引や文献も、原稿に何らかのポインタないしタグを付けておけば、プログラムで自動生成できる代物だ。
多分、そういうツールはあるだろうと推測している。

もう一つは、Jenkinsというビルド管理ツールを出版システムの中核機能に配置すること。
つまり、原稿というテキストをコミットした後、Jenkinsが検知して、Diffメールを送信したり、即座に自動ビルドしてPDFやHTML、epubで成果物を配布したり、索引や文献や目次を自動生成したり、出版フローのメトリクスを出力したりする。

この仕組みは、我々プログラマの仕事と全く同じ構造だ。
実際、テキストベースで書かれたプログラムをコミット後、ビルドされてサーバーにデプロイ後、システムとして稼働されて、ユーザが直接触ることができるようになる。
同様に、小説家が原稿をテキストで書いてコミットしたら、ビルドされてPDFないしHTMLなどの印刷媒体で出力されて、読者が直接読めるようになるフローと全く同じ。
その意味では、プログラマも小説家も同じ職業であり、クリエイターでもある。

個人的には、AntなどのビルドスクリプトでテキストをPDFやepubへ変換するツールをキックするようにすればいいと思う。
Jenkinsは強力なツールであるがゆえに、単なるビルドツールだけでなく、コードレビューや原稿のレビューをビルド前に組み込んで品質チェックしたり、コミットの差分をメールで流したり、ビルド失敗をメールで流すなどのやり方もある。
他にも、原稿を書く人ないし小説家のコミット履歴から、執筆に関するメトリクスを出力して、その結果から経験則を抽出できたとしたら面白いかもしれない。

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性

アジャイル開発はソフトウェアの品質特性のうち、機能性と信頼性の問題点をすり替えることによって、ソフトウェア開発特有の特徴をうまく取り入れているように思える。
考えたことをメモ書き。

【参考】
ソフトウェア品質特性(ISO/IEC9126)の解説

ソフトウェア品質特性について

ISO 9126 - Wikipedia

品質改善.com - 品質特性とは

アジャイル開発が重視する品質特性～保守性と移植性: プログラマの思索

【1】ソフトウェアの品質を話す時、普通は、機能性と信頼性が暗黙のうちに前提にされている。
仕様書に書かれた機能がシステムに反映されていてそもそも使えるのか、そして、システムの障害が少なくて安定稼働しているか、という点。

ウォーターフォール型開発では、詳細な仕様書を作り、手戻り作業がない前提でシステムを作り始める。
一括請負契約が理由でもあるが、外部設計で決定した仕様に基づいて開発するため、確定した仕様は全て実装しなければならない。
だから、機能性の評価は、仕様書通りに作られているか、というシステムテストや受入テストで検査される。

特に、ウォーターフォール型開発では、「仕様凍結」という言葉がキーワードの一つ。
そうでなければ、いつまでもあいまいな仕様のままで製造工程に入ることができないから、納期がズルズルと延びてしまうからだ。

【2】だが、アジャイル開発では、システムに全ての仕様が反映されているか、という観点ではなく、顧客にとって価値ある機能が実装されているか、という観点に置き換える。
つまり、無駄な機能を実装しても無意味であり、シンプルで使いやすいシステムであるべき、という思想がアジャイル開発にはある。

XPの計画ゲームの背景には、2～4週間の間隔で常にストーリーを吟味して、必要な機能は追加するが、優先度の低い機能は思い切って削るという意思決定も含まれている。
この考え方は、ウォーターフォール型開発に慣れている人ならば、過激な思想だと思う。
何故なら、外部設計で決まった仕様であろうとも、開発途中で顧客が不要と判断したならば、その機能は削除するオプションが含まれるため、当初の見積りと狂ってしまうからだ。

でも、アジャイル開発では、そもそも作られた機能の大半はユーザに使われないという経験則を元に、ソフトウェアの機能を定期的に見直しながら、頻繁にバージョンアップして機能拡張も品質改善もしていく。

この考え方はソフトウェアの特徴をよく表していると思う。
ソフトウェアはそもそも頻繁にVerUpするものであり、VerUpしないソフトウェアは死んだも同然。
常にVerUpする要因によって変化するものであるならば、機能は凍結すべきではなく、頻繁に見直しをかける仕組みが必要だ。

Scrumのバックログという概念はこの手法をうまく表したネーミングだと思う。
顧客の要望はバックログに一旦入れておき、常に優先順位を付け直して、優先度の高い機能から実装していく。
機能性の評価は、仕様凍結した仕様で評価されるのではなく、変化の激しいビジネスの状況を反映すべき、という観点で置き換えられる。

【3】また、ウォーターフォール型開発では、障害を起こさないようにバグを摘み取り、稼働率を高めようとする。
つまり、障害故障間隔（MTBF）を長くすることによって稼働率を高める。
この考え方は、ハードウェアのような製品の品質管理の手法を受け継いだものといえる。

だが、アジャイル開発では、障害修復時間(MTTR)を短くすることによって稼働率を高めようとする。
その考え方は以前書いた。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

アジャイル開発と品質管理の関係: プログラマの思索

SRATSの使い方: プログラマの思索

つまり、障害が発生したとしても、即座に障害を修復できるならば、高い稼働率を保持することができる。
この発想は、XPのリファクタリングで保守性を高めたシステムだからこそ容易でもあるし、テスト駆動開発で常に即座に自動テストできる環境があるからこそ可能だし、AmazonEC2のようにサーバーインフラがクラウド化されたことによって、常に稼働できるような仕組みが整ったからこそ、実現できるもの。

昨今は、iPhoneや携帯のシステムアップデートのように、後から機能追加だけでなくバグ修正も反映する仕組みができたので、障害があったとしても後から直すことが容易になった。
「後追いテスト」というテスト手法も、組み込み機器のソフトウェアアップデートが可能になったからこそ選択できる手法と言える。
また、継続的インテグレーションを発展させた継続的デプロイ、継続的デリバリーの概念によって、ワンクリックでデプロイできれば、より楽になる。

つまり、最近の技術革新のおかげで、壊れないシステムを作るよりも、素早く問題修復できる仕組みが実現されたことで、逆転の発想が可能になったとも言える。
特に、オープンソースソフトウェアのように、ユーザの力を利用して問題発見のフィードバックや問題修復を図ることができたことも大きい。

【4】機能性や信頼性の問題点をアジャイル開発は意図的にすり替えた背景は何か？
現在のビジネスの状況は、あらかじめ全てが分かった状況で開始できることはあまりない。
むしろ試行錯誤しながら開発せざるを得ないし、突然金融危機が起きて状況が一変するような時代だからこそ、途中で変更できるオプションが欲しいもの。
そして、仕様があらかじめ確定しているマーケットアウトの製品よりも、市場の反応を見ながら少しずつ機能拡張していくマーケットインのWebサービスの方が、今のビジネスに向いている背景があるのだろう。

アジャイル開発は、機能性の問題を「全ての仕様が反映されているか」から「必要な機能が実装されているか」、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えた。
その意義はとても大きいと思っている。

RedmineはITソリューションの一つ～情報システム部門のタスク管理とIT全般統制 #RxTstudy

第5回RxTStudyで @akahane92さんのスライドが素晴らしいのでリンクしておく。
@daipresentsさんの楽天の事例と同じくらいのインパクトがあると思う。

【参考】

情報システム部門のタスク管理とIT全般統制 ～ Excel管理からの脱却 ～ from Kuniharu AKAHANE

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索

RxTstudy

情報システム部門のタスク管理やシステム監査、内部統制などにRedmineを導入した事例について講演されている。
ここまで自社のRedmineの運用事例を詳しく細かく公開されているのは非常に参考になる。

面白いと思った点は二つある。
一つは、ITSが持つチケット管理の特徴をうまく業務に当てはめていること。
一つの事案を複数のチケットに対応づけたり、チケットの種類やワークフローに相当するトラッカーを4種類に絞って運用したり、作業履歴やトレーサビリティをシステム監査に使うなど、ITSの特徴を理解して、業務に適用している。
いわゆるERP導入におけるフィットギャップ分析を、自分たちの情報システム部門の業務とITSに当てはめて実践されたのだろうと思う。
その意味では、RedmineをERPとみなした事例として、かなり成功した事例に相当するのではないだろうか。

もう一つは、社員の行動が局所最適化から全体最適へ変わったこと。
最初は単にチケットに記入して記録するだけかもしれない。
だが、チケットに作業履歴が残ることによって、他メンバーとコミュニケーションできる共有の基盤ができる。
いつでも過去の作業を検索できることによって、現状の作業をより深く理解することを促すこともできる。
つまり、きちんとしたインフラさえあれば、メンバーは自ら行動して、目の前の問題を自発的に解決していくようになる。
ファシリテーションでよく言われる「解けない問題を解ける問題に変換すれば人は自然に問題を解決する方向へ動き出す」という言葉を連想させる。

個人的には、どんなチケット集計機能が有効だったのかを知りたい。
蓄積されたチケットはナレッジないし資産であり、その資産を有効活用するには、いろんな観点のビューがあると便利だ。
それらのビューを意思決定の支援のために使うのが本来の目的だから。

アジャイル開発でも品質管理でも、有効なビューは既に提示されている。
例えば、アジャイル開発なら、タスクボード・バーンダウンチャート・パーキングロットチャート・バックログなどのビューがあり、そのビューはどの状況で使うと有効なのか、は既にその界隈では知られている。
品質管理でも、信頼度成長曲線、管理図、テストケース消化曲線などのビューをどのように使えば有効なのか、も既に知られている。

でも、それ以外の場面でチケット管理システムを使う場合、どんなビューを使うと便利なのか、というノウハウはまだまだ足りない。
例えば、IPAが公開した定量的プロジェクト管理ツールは、その一つの事例を示していると言えるだろう。

Redmineをアジャイル開発に適用するだけでなく、IT企業の業務全般へ適用するノウハウはもっと可能性があると思う。

【告知】「チケット駆動開発」ハンドブックを出版します

2012/8/24に@sakaba37さんと「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」を出版します。
前作「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説本になります。

過去5年間、チケット駆動開発とは如何なるもので、一体何ができるのか、という根本的な問題をずっと考えてきた結果を全て書きました。

元々は@machuさんがTracのチケット管理から提唱したアイデアを参考にして、故意にそのアイデアを拡張して、Redmine上でアジャイル開発を実践できるように、自分なりのノウハウを詰め込みました。
その後、チケット駆動開発について講演したり、コミュニティで議論しながら、アジャイル開発だけでなく、技術や開発プロセス全般、ソフトウェア工学など色んな観点で分析するように努めてきました。
そして、チケット駆動開発に関する技法や適用方法、適用範囲などについて、一通りまとめて出版することができました。
そのため、約350ページの分量に膨れ上がりました(笑)

あらかじめ断っておくと、Redmine・Trac・Mantisなどのツールの説明もありますが、インストール方法には全く触れていません。
あくまでもツールの背後にあるチケット駆動開発というプロセスに焦点を当てて、色んな観点で解説しています。

「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」の目次は下記になります。

第1部　チケット駆動開発の基本
第1章　プロジェクトの混乱から洗練へ
第2章　障害管理
第3章　構成管理とツール
第4章　障害管理ツールMantisの運用例
第5章　障害管理からチケット駆動開発へ

第2部　チケット駆動開発でプロジェクトを成功に導く
第6章　プロジェクトを成功に導くチケット駆動開発
第7章　チケット駆動開発がもたらすアジリティの向上
第8章　アダプタブル・ウォーターフォール開発、
第9章　アジャイルブームを超えて

第3部　チケット駆動開発による開発力の向上
第10章　チケット駆動開発の高度な運用方法
第11章　チケット駆動開発のFAQとアンチパターン集
第12章　チケット駆動開発のテーラリング

第4部　用語集

今回の出版では僕は、2つのことを念頭に執筆しました。
一つ目は、チケット駆動開発のハンドブックになるように、「チケット駆動開発とは如何なるもので、一体何ができるのか」について解説することです。

チケット駆動開発という概念は前作「Redmineによるタスクマネジメント実践技法」で初めて書籍として紹介されただけで、ツールの運用と一体化したため、どうしてもツール依存の話になりがちでした。

今作は、チケット駆動開発がBTSから発展した歴史を詳しく解説し、チケット駆動開発が今後どんな方向へ発展していくのか、について提示しました。
また、チケット駆動開発をアジャイル開発だけでなく障害管理・タスク管理・課題管理・インシデント管理・ストーリー管理など各状況に適用するためのノウハウを整理してまとめました。
(追記：「テーラリング」という言葉は好きではないので外しました)
そして、用語集をつけて、前作と今作で引用した用語や概念、運用ルールを索引から探せるようにしたので便利になったと思います。

もう一つは、チケット駆動開発に関わる日本人開発者の言動を意図的に数多く引用したことです。
そもそも、チケット駆動開発のアイデアは僕や@sakaba37さんだけで編み出したわけではないです。
むしろ日本のアジャイルコミュニティに関わる人達と議論して得られた実践的ノウハウを集めたものに近いです。

例えば、XPJUG関西やSEA関西、そしてRxTStudyやshinagawa.redmine、shibuya.tracなど数多くのコミュニティの人達がいなければ、実践的ノウハウは深く掘り下げられなかったでしょう。
そして、RedmineやTracなど各種ツールのコミッタやプラグイン開発者が活発に行動しなければ、今作のようにここまで深い内容で書くこともなかったでしょう。

それ故に、チケット駆動開発に貢献された数多くの日本人開発者の言動を引用することで、チケット駆動開発が著者の独りよがりのアイデアではなく、日本のアジャイルコミュニティが現場で実践して編み出した日本的なアジャイル開発の事例として紹介できるようにしたかったのです。
丁度、平鍋さんが10年以上前に初めて日本にeXtreme Programmingを紹介した後、プロジェクトファシリテーションという日本的なアジャイルの概念を提唱し、日本の開発現場で実践できるようなプラクティス集としてまとめたように、チケット駆動開発も日本人開発者にフィットしやすいアジャイル開発の実践的な技法としてまとめたかったのです。

日本の歴史を紐解けば、日本人は海外の文化を輸入した後、自分たちに適合しやすいように洗練させてきました。
奈良時代に中国の文化を遣唐使が持ち帰った後、ひらがなや源氏物語、鎌倉仏教などのように日本的な文化に変化させました。
明治時代に西洋の近代文化を取り入れた後、例えば自然科学は日本人自身が自分のものとして理解するようになり、ノーベル賞やフィールズ賞を受賞するぐらい高いレベルがあります。
同様にソフトウェアの世界でも、最初は欧米からその概念もハードウェアも輸入したかもしれないけど、日本人開発者はソフトウェアを自分たちのものとして理解し、そこから新しいものを生み出す能力を持っています。

アジャイル開発という概念もまだ日本では普及しているとは言えないし、日本の現場に適用しやすいノウハウはまだ足りない気もするけれど、そんな状況でもたくさんの日本人開発者が試行錯誤しながら挑戦している。
その流れの一つの文脈として、チケット駆動開発を捉えてくれれば、著者としてはとても嬉しいです。

アジャイル開発が重視する品質特性～保守性と移植性

ソフトウェアで出てくる品質はとても掴みどころがなく、測定できたとしても意外に役立たない。
そして、従来のWF型開発が重視する品質に対し、アジャイル開発は別の観点の品質特性を重視することによって、ソフトウェア開発のあり方を変えようとしているように思える。
考えたことをラフなメモ書き。

【元ネタ】
Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索

【1】アジャイル開発の本質は小規模リリースだと思う。
いきなり大きな物を作るのではなく、実際に動くものを小さく作り、小刻みなVerUpによって機能拡張も品質も改善していく手法。
その利点は、顧客やマーケットに対し、不完全であってもいち早くリリースできることで、インパクトを与えることができること。
仕様が完全に固まって作るプロダクトアウトの製品よりも、マーケットの動向に合わせて柔軟に計画や方針を変えていくマーケットインの製品に向いている。

小規模リリースの特長としては、イテレーションの単位でリリースしていく点がある。
定期的なリリースサイクルをプロセスに埋め込むことで、安定してVerUp出来る体制を整える。
小規模リリースを支えるXPのプラクティスで重要なものは、継続的インテグレーションだ。
常時リリース可能なSCMリポジトリがあるからこそ、いつでもリリースできるからだ。
その開発スタイルを支える構成管理手法としては、trunkをメインラインとして目的に応じたブランチを派生させるメインラインモデルがある。

【2】従来のWF型開発では、機能性と信頼性という品質特性を重視する。
つまり、仕様書に書かれた仕様がシステムに全て反映されているかという機能性、そして、製品が壊れにくい、あるいはシステムのバグが少ないという信頼性を重視する。
従来型開発をベースとした論文では、「高信頼性なシステムを作る効率的な開発」という謳い文句がよく出るが、それは重視する品質特性を背景としているからだと思う。

それに対し、チケット駆動開発でアジャイル開発を実践してみて気づいたことは、アジャイル開発で重視する品質特性は保守性と移植性であること。
WF型開発とアジャイル開発は、重視する品質特性が全く違う。

【3】保守性は、機能拡張のしやすさ。
XPでは、リファクタリングというプラクティスによって、ソフトウェアの可読性を上げ、構造を綺麗にする。
見た目の機能は変わらなくても、プログラムの構造がシンプルになることによって、将来の機能拡張を容易にしてくれる。
保守性のメトリクスとしては、ソフトウェア複雑度が有名だろう。
複雑度が大きいほど、そのプログラム保守しづらく、潜在バグの可能性が高い。

複雑度と単体テストケース数の相関関係: プログラマの思索

平鍋さんは保守性をテスタビリティ(テストの容易さ)という概念で説明しようとされていたが、保守性はテスト駆動開発と密接に関係する。
XPでは、リファクタリングの正当性をテスト駆動開発で保証する。
内部構造を綺麗にするための改造作業でデグレードを起こさないために、自動テストで回帰テストしやすくして、デグレードを防ぐ。
テスト対象のプログラムが巨大な塊であったら、メンテナンス(保守)しづらいし、そもそもテストしづらいだろう。

「テストしやすい」ことが、良い設計(EoT=Ease of Testing)：An Agile Way：ITmedia オルタナティブ・ブログ

「変更しやすい」ことが、良い設計 (EoC=Ease of Changing)：An Agile Way：ITmedia オルタナティブ・ブログ

ここで、古くからのテスト手法の一つとして、スタブとドライバという概念が出てくる。
テスト駆動開発では、ドライバやスタブを使って、テスト対象プログラムを簡単にテストできるような戦略を取る。

ソフトウェアテスト - テストドライバとテストスタブ - Weblio辞書

スタブは、テスト対象のプログラムをより小さな部品(サブルーチン)を組み合わせた構造にして、そのサブルーチンをテスト用プログラムとして扱うこと。
JUnitでは、テスト対象のプログラムの内部にあるExceptionのテストのために、Exceptionを故意に発生させるモックオブジェクトを作る時が多いが、それはスタブに相当する。
スタブはオブジェクト指向でない言語でも可能だが、オブジェクト指向言語の方がポリモーフィズムやオーバーロードを使えるのでやりやすい。

ドライバは、テスト対象プログラムを実行するために、外側からテスト対象プログラムを呼び出すためのプログラム。
普通は、サブルーチンのような小さなプログラムを作ったものの、単独では動作しない場合、ドライバに相当するプログラムを作り、入力データを幾つか用意して実行してテストする。
特にCやshのような一昔前のプログラミング言語ではよく使われるだろう。

テスト駆動開発という概念はXPが大きく普及させたけれど、テスト技法と絡めたやり方はあまり見かけない。
境界値分析、同値分析などのテスト技法と合わせて実施しなければ、そのテストが本当に全てのロジックを網羅しているのか、保証しにくいはずだ。

同値分割 － ＠IT情報マネジメント用語事典

境界値分析 － ＠IT情報マネジメント用語事典

【4】移植性は、ライブラリなどの移植のしやすさ。いわゆるポーティング。
移植性のよくある例は後方互換性。
例えば、Windowsなら最新OSでサポートされている機能やセキュリティパッチは過去のOSにも適用される。
この後方互換性維持のためにMicrosoftは多大な苦労を強いられている。
Androidではそもそも後方互換性が怪しいので、スマートフォンメーカーはOSのバージョン単位に開発しなければならないから、製品作りにとても苦労しているように思える。

ポーティングとは【porting】（移植） - 意味/解説/説明/定義 ： IT用語辞典

XPでは、継続的インテグレーションが回帰テストを自動化するので、後方互換性や移植したプログラムが正常動作することを常時保証してくれる仕掛けがある。
後方互換性を維持するための概念として、バックポートという考え方がある。
バックポートは、最新の機能やセキュリティパッチを過去のバージョンにも取り込む移植作業を指す。

バックポートとは【backport】 - 意味/解説/説明/定義 ： IT用語辞典

なぜバックポートが必要になるのか？
それは、過去のバージョンを使っているユーザのために、提供する必要があるからだ。
特にセキュリティパッチは、システムの品質要件に絡むだけでなく、社会的な道義にも関わるので、結構面倒。
WindowsOSもRedmineも、セキュリティパッチというバックポートの作業に大きな負担を感じているだろうと思う。

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【5】ソフトウェア開発のプロジェクトでは、移植性に絡む案件は、リプレース案件とよく呼ばれる。
よくある例は、昔に作ったCobolシステムを最近流行のWebシステムに変えたい、とか、VBで作ったクラサバを最新のWebシステムに変えたい、とか。
顧客としては、機能は同じで中身を最新の技術で作り替えて欲しいだけで、仕様は今動いているシステムを見ればいいのだから簡単でしょ、とよく言う。

だが、リプレース案件は曲者だ。
ほとんどのリプレース案件はデスマーチになりやすい。

システムのリプレース案件が最も危険な理由: プログラマの思索

何故なら、実際に動くシステムには既存バグがあるのに運用でカバーしているので、それを直すべきのか、逐一確認しなければならないし、一度直すとなると仕様を最初から作りなおさなければならない。

あるいは、既存プログラムがあまりにも汚いのでその構造やインターフェイスを作り替えた場合、今までに運用してきて実績という運用品質を捨ててしまうため、とても危険だ。
たとえ汚いプログラムでも、長年の運用の中でたくさんのパッチが当てられて、稼働してきた歴史があるのだから、それらを全て理解できるとは限らないからだ。

【感想】Kanasan.JS prototype.js CodeReading#4: プログラマの思索

また、仕様は同じでも、プログラミング言語もハードウェアもライブラリも変われば、その組み合わせできちんと動くのか、実装するよりもテスト工数が膨れ上がり、そう簡単に作れないからだ。

顧客は簡単と思っても、過去に動いていた機能を最新の環境でも動かすようにするという移植性を担保するのは、頭を使わない割りには、神経をひどく使う。
ソフトウェア開発が何故こんなにも難しいのか、という理由の一つは、移植性を保証するのがとても難しいからだと個人的には思っている。

人間の臓器移植でも、そのまま臓器を移植すると、免疫機能が働いて拒否反応を起こす。
ソフトウェアのライブラリも同様に、インターフェイスが合わなければ改造せざるを得ず、そこから潜在バグが生まれるし、テスト工数が発生し、工数が膨れ上がっていく。

移植性は、再利用性に密接に関係する。
別システムのソースを移植する例のように、再利用な可能なインターフェイスになっていれば、移植するリスクは小さい。
移植性の問題は、いかに再利用可能なライブラリや部品を作れるか、という問題に置き換えることもできる。
すると、ソフトウェアプロダクトラインのように、コア資産と呼ばれる再利用可能な共通部品作りが移植性の問題に大きく関わってくる。

清水吉男さんが提唱するXDDPという派生開発では、移植性という品質特性を重視している。
組込製品では特に保守性や移植性というマイナーな品質特性が実は、プロジェクトの進捗や品質に大きく影響していることは皆薄々気づいているはずだ。

アジャイル開発は保守性と移植性が重要である事実を再発見し、その品質特性に対し、各種プラクティスでその有効性を提示した。
その考え方とその適用方法、適用範囲はもっと研究されてよいものだと思う。

モデリング再復習DOA編part1～情報無損失分解と結合の罠

DOAに関する技法で理解できた内容をまとめるために今後いくつか書き留める。
1回目は、情報無損失分解についてラフなメモ書き。

【1】DOAの基本はテーブルの正規化だ。
第1～5正規化まであるが、どのDOA本も無味乾燥で、本質的なことを書いていないように思う。
第3正規化で十分とか、関数従属性からどのように正規化していけばいいのかという手法まできちんと説明した本はあまりない。
また、正規化しすぎると良くないので、あえて正規化を崩す技法を勧める時もあり、正直分かりにくい。

特に思うのは、ほとんどのDOAの本の内容が20年前の時代のまま変わっていない気がすること。
そもそもDBサーバーの性能や価格も大幅に変わったし、DBMSも高機能化してオープンソースDBMSも業務系システムに十分に使える時代になったのだから、DOAの技法もどんどん進化していいはずだ。
OOAですら、UMLと絡めたモデリング手法からドメイン駆動設計へ内容も着実に進化しているのに。

【2】正規化する理由は「1 Fact 1 Place」を保持するため。
一つの事実というデータを一つのテーブルに保持するために、関数従属性の観点でテーブルを正規化する。

だが、正規化には落とし穴がある。
本来のデータを正規化して分割した後、分割したテーブルのデータを結合させると元のデータを復元できるようにしなければならないのに、実は関数従属性の保持の観点が漏れている場合がある。

この時、情報無損失分解とは、あるリレーションにおいてその分解成分の自然結合をとると元のデータを復元できることを指す。
つまり、正規化したテーブル設計の正当性は、情報無損失分解であるかどうかという観点で評価できる。

第1正規系　初心者用データベース入門

実際の具体例を考えるには、下記の例が分かりやすい。

平成22年 春期 データベーススペシャリスト 午前II 問6

発注伝票 ( 注文番号(PK), 商品番号(PK), 商品名, 商品単価, 注文数量 )

を情報無損失分解になるように正規化する場合、下記になる。

　発注 ( 注文番号(PK), 商品番号(PK), 注文数量 )
　商品 ( 商品番号(PK), 商品名, 商品単価 )

商品 ( 商品番号(PK), 商品名, 商品単価, 注文数量 ) とか、発注 ( 注文番号(PK), 注文数量 )　に分解すると、分割した2個のテーブルを自然結合しても本来のデータが復元されない。
その理由は関数従属性を見落としているからだ。

このように、正規化したテーブルを自然結合しても復元されず、怪しげなリレーションが現れる現象を「結合の罠」と呼ぶらしい。

【3】実は、データベース情報処理試験の過去問題を解いてみると、テーブルの正規化が情報無損失分解になっていない解答が幾つか見られる。
正規化したテーブル設計が正しいことを説明するために、情報無損失分解であることを証明するのは、机上では結構難しいと思う。

例えば、DB試験のH22年度午後問題1、H21年度午後問題1で、正規化が情報無損失分解になっていないのではないか、という指摘をiTECの解説から見つけた。

情報処理推進機構：情報処理技術者試験：問題冊子・配点割合・解答例・採点講評（2010、平成22年）

情報処理推進機構：情報処理技術者試験：問題冊子・配点割合・解答例・採点講評（2009、平成21年）

例えば、H22年度午後問題1設問2(1)では、正規化した解答は下記になっている。

(1)
中問(中問ID(PK)、中問作成日時、コースID、制限時間)
中問小問(中問ID(PK)、小問番号(PK)、小問ID)
大問中問(大問ID(PK)、中問番号(PK)、中問ID)
出題(大問ID(PK)、大問作成日時)

しかし、情報無損失分解を考慮すると下記の正規化になるのでは、という指摘がある。

(2)
大問(大問ID(PK)、大問作成日時)　←　上記の出題テーブルと同じ
中問(中問ID(PK)、中問作成日時、コースID、制限時間)
中問小問(中問ID(PK)、小問番号(PK)、小問ID)
大問中問(大問ID(PK)、中問番(PK)号、中問ID)
出題(大問ID(PK)、中問番号(PK)、小問番号(PK))　←　漏れているテーブル。上記の出題テーブルとは中身が違う。

漏れているテーブルは、(2)の出題テーブルという全てのキーが候補キーとなっているテーブル。
机上で普通に正規化していくと、(1)のような結果になるだろう。
しかし、(1)のテーブルで結合させると、本来は存在しないタプル(データ)が出現してしまう。
つまり、(2)の出題テーブルというリレーションがないため、おかしなデータが復元されてしまうわけだ。

テーブルの正規化で第4正規化や第5正規化と言う概念が出てくるけれど、その理由の一つは、情報無損失分解になるように正規化すると、上記のような候補キーだけのテーブルが現れて、そのテーブルを更に正規化するために必要になるからだと思う。

【3】ネットで検索しても、DOAの本を見ても、情報無損失分解という概念はあまり見当たらない。
第1～5正規化まで無味乾燥な説明が多い割には、その正規化が正しいという正当性を説明している部分が少ない。

情報無損失分解は当たり前の概念だが、結合の罠という概念が示すように、正規化を誤ると本来のデータが復元されない。
そして結合の罠はとても陥りやすい。

正規化の他の注意点については、ボイスコッド正規化には2次識別子を使うという渡辺幸三さんの指摘もある。

2次識別子を使ったデータモデリング: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

正規化の話をするなら、DOA本はこのような実業務に役立つテクニックを解説して欲しい。
正直、DOAはOOAに比べると、進化が止まっている部分があるのではないかと思ったりする。
色々調べてみる。

Redmineの初心者向け資料

Redmine.JPに初心者向けRedmine資料が公開されていたのでメモ。

Redmineとは | Redmine.JP

はじめる! Redmine

View more presentations from g_maeda

(引用開始)
はじめてRedmineに触れる方向けに、Redmineとは何か、Redmineを使うと何が便利になるのかを紹介するスライドです。
(引用終了)

ソフトウェア開発者以外の人にRedmineを使ってもらおうとする場合、IT技術者の立場を押し通すと多分使ってくれないだろう。
普通の人がイメージするタスク管理は、RememberTheMilkやGmail ToDoのイメージであり、Redmineは入力項目が多すぎるし、たくさんの機能があって理解しにくいようだ。

Redmineによるチケット駆動開発が障害管理ツールから発展した歴史を考えると、チケットは本来は障害報告票ゆえに、どうしても入力項目は多くなる。
でも、きちんとチケットに作業内容を記録してもらえれば、強力かつ多種多様なチケット集計機能によって、色んな観点でタスクの進捗状況を分析することができる。
特に、アジャイル開発で出てくるかんばん、バックログ、バーンダウンチャート、パーキングロットチャートなどのような集計ビューは、IT技術者以外の人に取っ掛かりがいいだろう。

そして、チケット駆動開発が単なる障害管理やアジャイル開発と違う点は、No Ticket, No Commitの運用ルールを生んだバージョン管理連携機能だ。
IT技術者以外の普通の人はそもそもバージョン管理の概念を知らないし、使ったことすらないだろう。

だが、プログラムだけでなくWordやExcelのドキュメントもバージョン管理することによって、いつでも過去の修正版に戻せるようになるから、少しずつ修正して推敲することができる。
すると、どんな理由でプログラムやドキュメントを修正したのか、という変更理由が重要になってくる。
修正した事実には必ず何らかの意図があり、その意図を深く掘り下げていくことで、成果物の品質を高めていくからだ。

ここで、チケットに変更理由を必ず作業履歴として残すようにし、そのチケットにバージョン管理の履歴を記録すれば、いつでも変更理由を探すことができる。
RedmineのようなWebアプリのもう一つの利点は全文検索が容易な点なので、チケットに書かれた作業コメントも簡単に検索できるし、Wikiに共有情報をまとめておけば、更に役立つ。

プログラマだけでなく、本や論文、記事を書く人やデザイナーは全員、バージョン管理ツールとチケット管理ツールを使いこなす技術が必須になってきた時代になってきたのだろうと思う。

【追記】
下記の資料でも、Redmineで何ができるのか、を丁寧に説明してくれている。

Redmineを使ってみよう～No Ticket, No Work #tidd : プログラマの思索

Redmineを使ってみよう

View more presentations from mrgoofy33 .

アジャイルの概念を取り入れたCMMI

岡本 隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。
ラフなメモ書き。

【元ネタ】
徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント

CMMI | CMMI Solutions | Translations | CMMI 日本語翻訳版

上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。

ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。
「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。
Scrumが認定スクラムマスターや認定プロダクトオーナーなどの制度を導入した理由の一つは、ここに発端があるのだろうと思う。
ScrumがCMMIに影響を受けたのが良いのかどうか分からないが、認定制度を取り入れたことで、Scrumが急速に普及していった理由の一つになるだろうと思う。

とはいえ、僕が、アジャイルの概念を取り入れようとしているCMMIに対する違和感は下記に書いた。

CMMIはアジャイル化できるのか？: プログラマの思索

上記のPDFをきちんと読んでいないけれど、小規模リリースという考え方を取り入れる時、CMMIはその本質をうまく表現できるのか、という懸念を持っている。

また、似たような例として、アジャイル検定という試験が最近公開されたが、平鍋さんと同じ意見を僕も持っている。
少なくともScrumでは認定制度の中でワークショップが開催されているとは聞いている。

Twitter / hiranabe: アジャイル検定には強い違和感を感じる。せめてワークショップを含めるとか、実プロジェクトの体験記を書いてどう改善するか考える、とか、入れて欲しい。

今後、アジャイル開発が注目されるにつれて、自分たちに都合の良い解釈が流行して、本来のアジャイルの概念が曲解される危険もある。
今後もその動向に注目していく。

【追記】
アジャイル開発とCMMIなどの他プロセスの比較検証・評価については、「アジャイルと規律 ～ソフトウエア開発を成功させる２つの鍵のバランス～」で既に色々と書かれている。

定量的プロジェクト管理ツールはIT企業の基幹システムを目指す

IPAが出版していると思われる雑誌にチケット駆動開発の記事を見つけたのでメモ。

【元ネタ】
SEC journal_No28

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索

「定量的プロジェクト管理ツール(IPF)の紹介」の記事で、IPAが作った定量的プロジェクト管理ツールがどのような目的で作られて、どの範囲を適用しようとしているのか、を解説している。
その記事の中で、このツールがRedmineやTracを元ネタとして、プロジェクトの状況を各種のメトリクスで出力する時に、チケット駆動開発のアイデアを適用していると書かれている。

本来、チケット駆動開発は軽量なプロセスであり、チケットをタスクカードとして扱うという簡単な発想から発展してきた。
だが、このアイデアを突き詰めると、定量的プロジェクト管理ツールのように、IT企業の基幹システムのようになっていくのだろうと思う。
つまり、SI企業の各プロジェクトの進捗や品質の状況をリアルタイムに把握するために、開発者個人の入力データから集計し、その集計結果をマネジメントの判断材料として扱いたいわけだ。

定量的プロジェクト管理ツールの記事を読んで思うことは2つある。
一つは、これはIT企業のERPだな、という点。
機能が豊富だが、入力項目がたくさんありカスタマイズ可能なので、自分たちの会社やチームにどのように当てはめると効果的か、そしてどのように運用すればいいか、見極めることが重要。
ERP導入時のフィットギャップ分析と同じように、どの機能を流用し、どの機能をカスタマイズするか見極めないといけない。

フィットギャップ分析 － ＠IT情報マネジメント用語事典

実際のERP導入では、コストや納期のバランスで見極めるのが難しい。

もう一つは、RedmineやTracなどWebフロントで入力されたデータを元に、バッチ処理で集計処理を行なっている点。
普通の会社では月末に請求締めや会計締めなどを行なって、在庫の確定や売上を計上し、損益計算書を作る。
IT企業でも同様に、プロジェクトもマイルストーン単位に、進捗の情報から今どれだけの工数を消費して、どれだけの利益が出るのか、を知りたいものだ。
すると、月次バッチのような機能が必要になり、それは定量的プロジェクト管理ツールのように一定期間ごとに各種メトリクスを出力する機能が必要になるだろう。
EVMのように実績工数からコストや利益を計算する仕様はあるから、それを月次バッチで実装すればいいだけのことだ。

こういうツールに触れて思うのは、IT企業ほどIT化が遅れている業界はないのでは？と言う点。
銀行や証券のような金融業はITシステムの装置産業と言ってもいいし、製造業でも生産計画や在庫計算などはMRPなど既にシステム化され尽くしている。
小売業もPOSなどでリアルタイムに商品の売れ筋情報を管理するようにシステム化されている。
なのに、IT企業は自分たちの売上や費用の確定があいまいで、蓋を開けてみないと分からない時が多い。

世の中の企業がシステム装置産業へ変化している情勢ゆえに、IT企業もその流れに組み込まれていくではないかと思っている。

【追記】
定量的プロジェクト管理ツールはアジャイル開発のタスク管理をサポートすることにも使えるらしい。
そういう目的で作られたとは思わなかった。

情報処理推進機構：ソフトウェア・エンジニアリング

(引用開始)
Redmine、Tracを使った「定量的プロジェクト管理ツール」の紹介

アジャイル型開発においては、頻繁なリリースに対応するための機能追加やバグ修正、あるいはリファクタリングによるソース修正をコントロールするために、ソース修正に対するタスク管理を行うことが重要です。ところが、イテレーション計画が頻繁に変更されるため、リアルタイムなタスク管理を行うことが難しくなっています。この問題に対応するため、IPA/SECでは、ソース修正の自動収集を行い、さらに定量データに基づきプロジェクト管理とバグ管理を行うツール「定量的プロジェクト管理ツール」を開発し、オープンソース・ソフトウェアとして公開しました。本セミナーでは、同ツールの概要について説明します。
(引用終わり)

アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要

オージスさんのアジャイル開発の事例を見ていたら、アジャイル開発に向くスコープ変動型開発契約には機能規模の見積が必要という指摘があって面白かった。
考えたことをラフなメモ書き。

【元ネタ】
OGIS Scalable Agile Method の真髄（前編）

OGIS Scalable Agile Method の真髄（後編）

ざっくり読んだ感じでは、RUPをベースにオブジェクト指向設計に基づいたモデリングを行い、反復型開発でシステムを構築していくような開発スタイルを提唱している。
オージスさんはオブジェクト指向設計の老舗であり、モデリング力があるからこそ、アジャイル開発にオブジェクト指向設計を組み合わせた開発スタイルを提唱できるのだろうと思う。

興味深い点は、アジャイル開発のように、契約時の要件が固まっていない場合、「発生する変更の規模を測定する」考え方から見積りを行う点だ。

(引用開始)
機能規模測定手法を用いて、スコープの変化を許容するソフトウェアの調達方法としては southernSCOPE [12] というものが提案されています。この方法は、オーストラリアのヴィクトリア州における情報システムの調達において開発されたものです。
southernSCOPE の実行手順は以下のとおりです。

(1)ソフトウェアを調達する際に、顧客はスコープマネジャーを雇う
(2)スコープマネジャーは、FP (Function Point) 法により初期の費用とスケジュールを見積もる
(3)顧客は、機能概要や制約を記述したRFPを作成し、入札にかける
(4)顧客は、調達先と機能規模あたりの単価に合意する
(5)分析フェーズを実行することで、要求仕様書を作成する
(6)要求仕様書に基づいてスコープマネジャーが機能規模を算出し、顧客は予算とスケジュールを考慮してどの機能が必要かを決める
(7)開発途上での変更について、 スコープマネジャーが費用に対する影響を算出し、顧客と開発者が合意する
(8)開発が完了した時点で、顧客は納品されたソフトウェアと変更に対する費用を支払う
(引用終了)

上記の方法では、設計フェーズを反復しながらモデルを洗練化していき、出来上がったモデルに対し、FP法(ファンクションポイント法)で機能規模を計測する所が重要。

FP法は、InputとOutputのデータの内容が決まれば、そのシステムの規模を測定できるという見積りの仕組み。
FP法は従来から長い歴史があり、計測方法や機能規模に関するデータもたくさん蓄積されているので、持続的に計測できれば、規模見積りに役立つだろう。

更に重要な点は、機能規模をファンクションポイントで客観的に計測できるようなモデルを作る能力があるのが前提だ。
オージスさんのように、長年モデリングに携わって、モデリングの経験が深いからこそ、FP法は生きる。

児玉公信さんの「システム開発の見積りのための実践ファンクションポイント法」では、ER図とDFDからFP法を計測する事例が載っていて、とても勉強になる。
そもそもFP法は、データモデリングと相性が良い。
ER図からテーブルのCRUD表が作れれば、ILF・EIFのようなデータをすぐに洗い出せるし、ILF・EIFを参照・出力するようなプロセスを考えれば、FP法ですぐに計算可能だからだ。

FP法で業務モデルを計測する: プログラマの思索

オブジェクト指向設計はおろか、DFDやER図をまともに書けないようでは、FP法で計測することすらできないだろう。

個人的には、DOAを標榜する人達は何故、自分たちが作ったモデルに対してFP法で機能規模を見積もる手法を展開させなかったのか、不思議だ。

そもそも、モデルをシステム提案という早い段階から設計する理由の一つは、ざっくりでもいいから、早めにシステムの規模を見積り、開発コストを見積りたいからだ。
だからこそ、優れたモデリング能力があれば、曖昧な要求からある程度のモデルを導くことができるので、FP法で即座に見積りできるはず。
機能規模をFPで計測できれば、過去の計測データを用いて、かなりの精度で見積りができるはず。

アジャイルに開発するには、要求が変化するにも関わらず、優れたモデリング能力と見積り能力が必要になるという指摘が面白い。

SQIP2012の見所

SQIP2012のプログラムが公開されていたのでメモ。

【元ネタ】
ソフトウェア品質シンポジウム2012【SQiP2012】

日科技連 | ソフトウェア品質 | 第28回 ソフトウェア品質シンポジウム2009
（SQiP(スキップ)シンポジウム）

チケット駆動開発- BTSでExtreme Programmingを改善する-

僕もSQIP2009でチケット駆動開発を講演しました。
SQIP2012のプログラムで驚いたのはチケット駆動開発に関する発表があること。
チケット駆動開発について経験発表するぐらい事例が増えていて、普及しているということなのでしょうか？
発表内容が気になります。
普通は資料がPDFで公開されるので、楽しみに待っていようと思います。

他にも、細谷さんによるアジャイル開発事例や、XDDPとScrumを併用した事例という興味深い話もあるようです。

(引用開始)
A2-3【経験発表】
チケット駆動型進捗管理システムによるカーナビゲーション開発管理の効率化
藏本　英彦　氏

【概要】
我々が開発しているカーナビゲーションは、ソフトウェアの開発規模が1,000万行を超え、1,000人以上が関わる大規模製品となっている。開発を取り巻く環境として、短納期開発、低コスト、仕様が固まらないなどの外部要因を抱えおり、要件変更が頻繁に起こる。これは従来の製品開発で適用されているウォーターフォール型開発では、手戻りを発生させる要因となる。
要件変更が頻繁に起こる開発でも、手戻りの影響を減らす新たなプロセスの構築が必要であると考えた。そこで、変更にすばやく適応することに主眼をおくアジャイルソフトウェア開発に着目した。一般的にコミュニケーションを重視するアジャイル開発は、大規模開発には不向きとされている。しかし、開発対象を細かな機能に分割し、開発のスコープをコミュニケーション可能な規模にすることで、アジャイル開発の適用が可能と考えた。
ウォーターフォール型開発にアジャイル的な要素を組み込む際に、進捗管理システムにチケット駆動型管理システムを採用した。機能の開発計画を管理する計画チケットと、工程で発生する作業をコミュニケーション可能な粒度で管理する作業チケットに層別した。
本発表では、上記要件を備えたプロセスの構築と、それを製品開発に適用するためのプロジェクト進捗管理システムについて報告する。

A2-1【経験発表】
アジャイルプラクティスを活用したチームとしての品質確保の取り組み
細谷　泰夫　氏

【概要】
ソフトウェア開発の経験が浅いメンバーが大半を占める場合、以下のような課題がある。
(1) 経験の浅いメンバーの成長をどのように促していくか？
(2) 製品の品質をどのように確保するか？
アジャイル開発手法では、短期間の反復開発を実施する。要求分析～テストまでのプロセスを何度も繰り返しフィードバックを受けることは、経験の浅いメンバーの設計、実装スキルを向上させる効果が高いと考える。
一方で、経験の浅いメンバーが含まれる中でも製品の品質をしっかりと確保する必要がある。
本発表で紹介する事例では、アジャイルプラクティスがカバーするレビューの範囲、必要なスキルに着目し、既存のレビュー手法、テスト手法と組み合わせることで、製品の品質を確保する工夫を行った。
本発表では、各プラクティスをどのように組み合わせて品質を確保したか、計測したメトリクスを交えた実施結果を紹介する。

A2-2【経験論文】
XDDPとSCRUMによるチーム型派生開発の取り組み事例
勝又　淳　氏

【概要】
昨今の組み込み機器は、製品競争の激化により高機能・高品質・短納期・低コストへの要求が強く、これらの課題解決が急務となっている。しかしながら、長きにわたる景気低迷によりヒト・モノ・カネといったリソースが潤沢に割かれるわけではない。派生開発においては、新規開発に比べてその傾向が強いことが多い。
そこで我々は、派生開発において、迅速かつ最適の人員で高品質なソフトウェアを開発する手段として、派生開発における技術的なアプローチ(XDDP)と自律型チームによる継続的改善アプローチ(SCRUM)の２つのアプローチを適用することで課題解決に取り組んだ。
その結果、品質面・納期面・コスト面・メンバのモチベーション面において非常に良い結果を得ることができた。これは、この２つのアプローチが、お互いの特徴を打ち消すことなく良好に作用した結果であるといえる。
本稿では、この２つのアプローチがどのように作用して、品質向上・納期遵守・高動機づけに繋がったのかを考察する。
(引用終了)