SVNバックアップのコマンドを記録しておく。
【元ネタ】
Subversionリポジトリのバックアップ( svnsync )
Subversionの履歴を保持したままリポジトリを移動するには - システム開発ブログ （システム開発のアイロベックス｜東京都新宿区の業務システム開発会社）
■SVNリポジトリ同士を同期
svnsync init [移動先リポジトリ] [移動元リポジトリのURL]
svnsync sync [移動先リポジトリ]
■SVNリポジトリからダンプファイルを生成
svnadmin dump [移動元リポジトリのパス] > [ダンプファイル名]
■SVNリポジトリでダンプファイルを読み込む
svnadmin load [移動先リポジトリのパス] < [ダンプファイル名]
また、SVN→Mercurialへの変換方法は下記を参考にする。
SVNリポジトリをMercurialと同じPCに作ってsvnsyncで同期した後、hg convertした方が速い。
「世界で勝負する仕事術 最先端ITに挑むエンジニアの激走記
考えたことをラフなメモ書き。
半導体といえば、エルピーダ破綻のニュースが記憶に近い。
電子立国日本の自叙伝
DRAMは廃れ、今はフラッシュメモリが全盛の時代。
著者は元東芝のフラッシュメモリの半導体エンジニア。
「走りながら考えることが重要」と著者は説く。
半導体工場は最初から完成形が見えているわけではない。
数年後に売れるイメージを浮かべながら、工場も製造装置も作っていく。
先にじっくり考えてから動き出すのではもう遅い。
この考え方はアジャイルソフトウェア開発に似ている。
顧客も開発者もシステムの完成形を最初からイメージできているわけではない。
顧客の要望を引き出し、実際に作ってみて、顧客の評価を受けながら、少しずつ改善していく。
あるいは、マーケットの状況をうかがいながら、Webサービスを少しずつ機能改善していき、時代の流れに乗る方向へ進化させていく。
最初に決めた計画通りに物事が進むという仮定で、ガチガチに進捗を管理していく方法は今の時代には向いていない。
しかも、IT業界だけでなく、半導体という業界でも同様という話が興味深い。
似たような話は、「グーグルで必要なことは、みんなソニーが教えてくれた
元ソニーのエンジニアも「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」ことの重要性を説いている。
この話はまさにアジャイルソフトウェア開発の概念そのものだ。
最初から完成形を作るのではなく、ユーザの力を利用して機能改善のアイデアを得たり、問題発見や問題修復のフィードバックをもらうことで、製品の完成度を高めていく。
辻野さんも「走りながら作っていく」姿勢の重要性を説いている。
この仕組みは既にアジャイルソフトウェア開発では、「小規模リリース」という概念によって既に明確化されている。
XPが発見し、Scrumがそれをプロセスフレームワークとして形式知にまとめた。
我々IT技術者は既に知っている考え方は、製造業では多分マイナーな考えで、誰も知っていないのかもしれない。
また、生態系という考え方も大事。
最初はデジカメの記憶媒体に過ぎなかったフラッシュメモリが、AppleのiPodによって一躍脚光を浴び、iPhone/iPadというスマートフォン市場が生まれることによって、主流となり技術革新が後押しされた。
スマートフォンがフラッシュメモリだけでなく液晶、CPUなどの部品の技術革新を各メーカーに促し、どんどん使いやすくなっている。
新製品が新しい需要を生み出し、更なる技術革新が発展していくという流れ。
そして、そのマーケットにたくさんのメーカーがしのぎを削りながら、参入してくるという生態系。
でも、どうして日本の製造業はこれほど優秀な人材をやすやすと手放してしまうのか？
青色ダイオードの中村さん、「世界で勝負する仕事術 最先端ITに挑むエンジニアの激走記
著者はこんなことを書いている。
日本国内に人材流動性がないため、国外に優秀な人材が流れてしまい、日本国内の競争力を貶めているという指摘。
(引用開始)
人材確保のために奔走していて最も強く感じるのは、優秀な人材がいないことではなく、優秀な人材が日本から出て行ってしまうことへの危惧です。
最近は日本のメーカーも簡単にリストラをしたり、早期退職者を募るようになりました。
国内にその受け皿がないため、そこから飛び出した優秀な技術者の多くは、韓国や台湾などの渡ってしまいます。切る側にとっては合理的な人材整理なのでしょうが、国全体から見れば貴重な人材の流出です。
(引用終了)
多分、半導体業界だけでなく、家電などの他の製造業の業界でも同様の傾向ではなかろうか？
著者は産学連携のように、企業で経営者になれなかった人は大学などの関連機関で教育や研究に携わってもらうような仕組みが必要ではないか、と言っている。
でも、この考え方は官僚の天下りと構造は全く同じ。
天下り構造は悪く言われるけれども、大学や産業界、官界との人材交流を活発化させるために必要なのだろう。
日本の製造業もアジャイルの概念が必要ではないか？と思う。
@kawagutiさんのBlogにScrumの組織パターンが載っていたのでメモ。
【元ネタ】
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti の日記 (id:wayaguchi)
【1】@haradakiroさんから、Scrumはパターンランゲージであるという意見を聞いて正直びっくりした。
XPこそがパターンランゲージであると思っていたから。
でも、上記の記事を読んでその意味を理解した。
上記の記事のパターンは構造がラフすぎて、正直理解しにくい。
原本を読むと、パターンの背景が詳しく書かれているだろうか？
とても興味がある。
僕はパターンという考え方が好き。
ソフトウェア工学や開発プロセスのように、人が関わる活動を支配する法則を説明するのに、経験則をパターンという言葉で表現できるのはとても分かりやすいと思う。
パターンはどんな背景や文脈で有効で、逆にどのような状況では有効でないのか、をはっきり示してくれるからだ。
パターンという考え方は性格学に似ているように思う。
性格学にはユングやフロイトなどたくさんの流派があるが、人の性格がどの分類に当てはまるのかが重要なのではなく、分類した結果現れた類型(タイプ)がどんな本質を持っているのか、を示しているのが重要、という話を読んだことがある。
その考え方をパターンに当てはめると、我々の現場の問題に対してパターンをそのまま当てはめるよりも、そのパターンの背景や本質を理解することによって、問題をよりシンプルな形で解きやすくしてくれるものだと思う。
パターンは経験則から生まれた社会科学に似た法則だ。
だから、パターンはある特定の時代や場所に依存する。
物理学や数学の法則のようにいつでもどこでも通用するわけではないが、パターンはその時代や場所から生じる制約条件を明らかにしてくれると思う。
【2】パターンの考え方で面白い特徴は、複数のパターンを組み合わせると意外な効果が現れることだ。
XPには10個以上のプラクティスがあるけれども、ソフトウェア開発の全体進捗や品質について何一つ語っていない。
でも、テスト駆動や継続的インテグレーションなどのプラクティスを組み合わせることによって、ソフトウェアの品質を従来のやり方よりも劇的に高めることができる。
同様に、計画ゲームやイテレーション単位の小規模リリースなどのプラクティスを行うことによって、開発の進捗をコントロールしやすくなり、そこからVelocity(開発速度)というアジャイル開発特有の概念も生まれてくる。
すなわち、ソフトウェアの品質や開発の進捗などの概念は、その概念自体を追いかけても掴みどころがなく、むしろ無関係と思われるプラクティスを徹底的に行うことによって逆にその概念に迫ることができるのだろうと思う。
この辺りは色々考えてみる。
SEA関西のドメイン駆動設計の講演を聞いてきた。
感想をラフなメモ書き。
【元ネタ】
第47回 SEA関西プロセス分科会「ドメイン駆動設計」#SEAKANSAI #kspinddd #dddjp - Togetter
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り: プログラマの思索
【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計
OOAに関しては「実践UML
増田さんの職歴を聞いた所、OracleのデベロッパーからJavaなどのオブジェクト指向設計へ転向したとのことなので、DOAの良さもOOAの良さもよく理解されているのだろう。
また、ドメイン駆動設計だけでなく、ICONIXやSpringによる実装も組み合わせたオブジェクト指向設計なので、要件定義から外部設計、実装に至るまでの経験が豊富なことは感じられた。
【2】ICONIXを解説している本は「ユースケース駆動開発実践ガイド
EnterpriseArchitectというツールを使った開発でこの本を参考にした。
ICONIXの手法では、ロバストネス図がユースケースと実装に近い設計モデル(クラス図、シーケンス図)の間のミッシングリンクになるという主張が根底にある。
ロバストネス図なので、要件を設計モデルに落とす時に、バウンダリ・コントローラ・エンティティでシステムを設計していくとオブジェクトが見えてくるというのが肝。
OOAの利点である「要件から設計、実装まで一気通貫で開発できる」特徴が詳しく書かれている本だろう。
しかし、モデルの品質は本当に良いのか？という正当性は、ICONIXでもドメイン駆動設計の本でも弱いだろうと思う。
ドメイン駆動設計では、ドメインの専門家と開発者がモデリングしていったら、あるブレイクスルーで設計モデルが分析モデルに変わるという話があるが、ではその条件は何かと言われたら、正直きちんと書かれていないのではないと思う。
実際、増田さんの話では、AsIsモデルをモデリングするのであり、ToBeモデルはモデリングしないというお話もあった。
そのコンテキストは忘れてしまったが、多分、AsIsモデルを設計し、顧客の要求を聞き耳を立てて収集して考えていけば、AsIsモデルを修正していくに従ってToBeモデルへ変わっていくという考え方なのだろうと推測した。
でも、僕としては、多分その考え方は根本的な解決ではないだろうと思っている。
あるべきシステムのモデル(ToBeモデル)を作り出すには、OOAとかDOAとかそういう次元の問題ではないと思っている。
【3】増田さんのドメイン駆動設計の話を聞きながら、僕はER図の設計に置き換えたらどうなるか、と解釈しながら聞いていた。
概念モデルに相当するクラス図の設計に、ER図におけるエンティティ抽出の技法は有効に使えると思う。
「ドメイン」という単語自体がユーザが理解できる業務用語を抽出したオブジェクトであり、それはDOAならリソースというマスタ系テーブル又はイベントというトランザクション系テーブルに相当するだろう。
オブジェクト同士の関連は、DOAなら、外部キーという参照関係又は複合キーという連関テーブルに相当する。
双方向の関連つまり多対多の関係は3つ目のオブジェクトを入れるという解決法を示されたが、DOAなら連関テーブルという組み合わせテーブルを作るだけのことだ。
また、ValueObjectは記録したデータを修正せず履歴を残していくパターンらしいが、DOAなら注文や請求などのトランザクションテーブルは、修正する時に赤黒伝票を作って訂正仕訳を起こすのと同じだ。
また、エンティティで重要なのはユーザが識別できる一意な番号を知っているかどうか、という話は、DOAなら自然キー(natural key)やT字型ERのIdentifierの概念と同じだ。
内部的なシーケンス、OIDはオブジェクトの識別子とならないという話は、DOAなら代理キー(サロゲートキー)やOracleのシーケンスなどと同じだ。
また、Entitiesの例の例として、伝票と記帳、残高の更新、人、組織、もの、場所があげられていた。
エンティティの洗い出しのパターンとしては、OOAならば「ストリームラインオブジェクトモデリング
オブジェクトは12個の種類に分類でき、その関連も全てパターン化されるというお話。
SL＝StreamLine Object Modeling: プログラマの思索
面白い指摘は、場所の識別は問題が複雑だということ。
場所エンティティを使いやすいモデルとして作るには、勤務者が利用しやすい所、利益が出るために最適な場所などの観点を入れる必要があるため、試行錯誤する必要があるらしい。
「Read the boook」(その手の本を読め)という話は、モデリングするには業務知識が必要という指摘に過ぎない。
典型的な業務知識は簿記や生産管理があげられるだろう。
個人的には、簿記3級と2級の知識があれば、小売業や製造業などの基本的な業務知識は身につくと思う。
それらの業務であるモノや情報の流れの背後には、必ずお金が絡んでいて、どの時点で売上や売掛金、買掛金や仕入れが発生するのか、という観点の仕訳が出てくるからだ。
クラスが多くなったら、クラスをまとめたモジュール図を重視するという話は、UMLならパッケージ図、コンポーネント図に相当するだろう。モジュールにまとめてモジュール間の関係を整理したいから。
JavaのJarの依存関係、WindowsのDLLの依存関係との話と同じ。
つまり、再利用可能な一つのコンポーネントとしてJarやDLLとまとめて、他プログラムから呼び出す機能の塊にするわけだ。
【4】OOAは2000年代前半はとても盛り上がっていたのに、最近はあまり広まっていない。
何故なのだろう？
でも、Railsが出現して以来、OOAよりもDOAの必要性が逆に高まっていると思う。
何故なら、テーブル設計さえできればすぐにマイグレーションを実行して、テーブル生成や新規データ投入後、すぐにCRUD画面ができてしまうからだ。
つまり、テーブル設計さえしっかりしていれば、残りの業務ロジックはRubyでサクサク作ってしまえばいい。
JavaのSAStruts、PHPのCakePHP、PerlのCatalystなどのようにRubyのRailsクローンと呼ぶべきWebフレームワークが主流となった今、モデリングにおけるDOAの重要性はもう一度再認識すべきだと思う。
自分の中でももう一度整理してみる。
【追記】
増田さんから下記の感想がありました。
上記はあくまでも一意見です(^^)
「はじめて学ぶソフトウェアのテスト技法
【元ネタ】
はじめて学ぶソフトウェアのテスト技法 : 賢者の図書館 (Under Construction) : livedoor Blog（ブログ）
初心者はRubyやJavaなどのプログラミングから入るけれど、テスト技法の習得も重要。
書いたプログラムが正しく動いているという正当性は、テストした結果を見せなければ誰も信用しない。
「はじめて学ぶソフトウェアのテスト技法
個人的には、テスト技法を使いこなしているかどうかの簡単な基準は、同値クラステストと境界値テストだと思う。
テストで使われるテストデータは、同値分析によってかなり減るのに、無駄にたくさんのデータを使って同じテストをしている人もいる。それは労力の無駄だ。
プログラムのバグは、境界値で発生する時が多いが、境界値付近のテストが不十分な人も多い。
また総合テストやシステムテストのように、シナリオベースないし本番環境に近いデータを使う場合、データの組み合わせを十分に考慮する必要がある。
その場合、ペア構成テストや直交表を使いこなせると威力を発揮するだろう。
日本の品質管理は世界でもトップクラスだと思うが、その理由は、詳細な仕様書をあらかじめ作っておき、その仕様書を元に、ペア構成テストや直交表を使って、想定される本番運用のテストデータを作りこんでテストする方法でやってきたからだと思う。
TestLinkを使った時に感じたことは、テスト技法はプログラミング技法とは異なる技術であり、どうしてもアジャイル向きと言うよりも計画駆動になりやすい。
アジャイル開発と組み合わせたテスト技法はもっと色々研究される余地があるように思う。
分散バージョン管理のマージコマンドが優れているのは、3ウェイマージが使われているのではないか、と思った。
3ウェイマージに関する記事をメモ。
【元ネタ】
変更をマージする ? Bazaar v2.6.0dev2 documentation
JapaneseTutorialConflict - Mercurial
Mercurial 2.0?: graft: 3-way マージアルゴリズムを使った cherry-picking - tcha.org
分散バージョン管理はバージョンではなくリビジョンを管理する: プログラマの思索
SVNからMercurialに移行するべき8つの理由: ニュースの社会科学的な裏側
(引用開始)
SVNのブランチの様にTruncとBlanchを分ける場合は、リポジトリを別に分ける事になる。SVNのブランチも有効に使っていない開発チームも少なくない。分岐バージョンはリポジトリを分けると言うのは、シンプルで分かりやすい方法だ。しかし、ブランチ間の関係を示す情報が失われるため、2-way mergeをせざるをえなくなる。GitやMercurialが使う3-way mergeに比較して、SVNの2-way mergeは衝突を起こしやすい。
(引用終了)
2-way mergeと3-way mergeの定義は、Wikipediaを見よ。
競合の編集～TortoiseMergeの説明が分かりやすい。
マージのデシジョンテーブルは、変更をマージする ? Bazaar v2.6.0dev2 documentationにそのパターンが書かれている。
SVNでは、ブランチを分岐する時にリポジトリを分けてしまう運用をしてしまいがち。
すると、ブランチの派生元が不明になるため、現行・最新ファイルの2ファイルの差分比較のため、2-way mergeをせざるを得ない。
GitやMercurialでは、リビジョン自身を管理しており、リビジョンの派生元(親リビジョン)は必ず存在している。
だから、派生元・現行・最新ファイルの3ファイルで差分比較できるから、3-way mergeを使うことができ、それがマージ作業の信頼性を高めている。
Mercurial 2.0?: graft: 3-way マージアルゴリズムを使った cherry-picking - tcha.orgによれば、hg graphコマンドによる3-way マージは、rebaseに似ている。
つまり、現行のリビジョンに対して、親リビジョンからの履歴を引き継ぎながら、合流するようにマージする。
そのおかげで、コミット履歴が理解しやすくなる。
分散バージョン管理はバージョンではなくリビジョンを管理する: プログラマの思索で書いたが、GitやMercurialはリビジョン地震を変更管理の対象とすることによって、リポジトリの同期作業やマージ作業が高速になるだけでなく、マージ作業自身の信頼性も高めている。
3-way マージツールは、ToritoseMergeやWinMergeが有名だろうが、Perforceで使われているp4Mergeも高機能らしい。
TortoiseSVNでマージする方法: プログラマの思索
TortoiseSVNの差分比較でWinMergeを使う: プログラマの思索
SVNとGitやMercurialの違いは単なるツールの違いではない。
バージョン管理ツールにおける機能や設計思想が根本から異なっているのだ。
InfoQの分散バージョン管理の記事を読んだ後に、もう一度、JoelがMercurialについて書かれた記事を再読して、ようやく分散バージョン管理が従来のバージョン管理ツールと何が違うのか分かったのでメモ。
ラフなメモ書き。
殴り書きの部分は後で直す。
【元ネタ】
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project
JoelもMercurialを使っている: プログラマの思索
InfoQ: エンタープライズ分野での分散バージョン管理システム
(前略)
分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。
重要なのは、このシステムが「バージョン」ではなく「変更」(注釈：リビジョン)で物事を捉えているということだ。
(中略)
Subversionユーザからこんな話を聞かされたことが何度あったかわからない。「コードをブランチしようと思って、それはうまくいったんだけど、マージする段になったら、もうまったくの悪夢で、すべての変更を1つひとつ手で再び当て直さなきゃならなかった。こんなこと2度とやるものかと誓って、ブランチの代わりにif文を使う新しい手法を開発したんだ」
時には彼らが自分の開発したトランク1つのやり方を誇りに思っていることさえある。自分の使っているバージョン管理ツールが本来果たすべき役割を果たさない問題を回避したのが美徳でもあるかのように。
分散バージョン管理では、マージは簡単で、うまく機能する。だから安定版ブランチと開発版ブランチを作ったり、あるいはデプロイ前にQA チームがテストするための長期間存続するブランチを作ったり、ちょっと新しいアイデアを試して具合を見るための短期的なブランチを作ったりすることができる。
これは見落としてしまうにはあまりに重要だ。私がここで文章を書くようになってからの10年間に起きた、ソフトウェア開発技術における最大の進歩かもしれない。
(後略)
MercurialがSVNよりも高速な理由の一つは、各リビジョンをパッチで保持しているから、という話を聞いたことがある。
それは、リビジョン全体を保持するのではなくリビジョンの差分をツール内部で保持しているが故に、ログ表示や差分比較、クローンなどの処理が速くなることを意味しているのだろう。
バージョン(つまり、タグ、リリース済みバージョン、ベースライン)ではなく、リビジョン自体を変更管理の対象としていることに分散バージョン管理の本質がある。
ローカルでリポジトリを作れたり、分散した場所でリポジトリを同期できることが重要なのではない。
リビジョン自身を管理しているが故に、コミット履歴の改変と言う分散バージョン管理の黒魔術も生まれる。
ソース管理の本質は、ソース修正のUndo/ReDoが自由に行えること。
同様にコミット履歴をUndo/ReDoできることによって、マージ作業の失敗を恐れることなく、何度でも試すことができる。
マージコマンドで一番簡単なものは、PushやPullだろう。
GitHubのPullRequestは、masterから派生したブランチ上でパッチを育んだ後、masterに取り込んでもらうための機能だが、この機能によって開発者が自由にフォークして、コミッタに取り込んでもらうことが楽になった。
でも、PullやPushはマージコマンドとして一番基本的な処理であり、masterの履歴を置き換えてしまう危険がある。
Redmineコミッタの丸山さんが話されているように、PullRequestよりもrebaseを多用する方が良いだろうと思う。
1???Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentationの「1.36 Mercurialの名前付きブランチ」に、黒色と緑色のリビジョングラフが表示されている。
黒色：default、緑色：stableのブランチと見なすならば、defalutが開発者が触る最新の機能があるブランチ、stableがリリースブランチないし保守ブランチと見なせる。
すると、stable→defaultへマージされた時に、merge with stable のコメントあり。
つまり、stableの修正をdefaultへmergeした。実質はrebaseと思われる。
rebaseの意義は、リビジョンを一直線にすること。
特に、SVNをmasterにしている場合、MercurialやGitのように複数のheadを保持できないため、リビジョンを一直線にせざるを得ない。
すると、masterであるSVNへパッチを取り込む時、rebaseを多用して、masterにパッチを含むトピックブランチを合流させるようにする。
rebaseの利点は、masterの改変履歴をベースにパッチを加工して履歴を維持してくれること。
GitやMercurialでは、単なるソースのマージだけでなく、過去のコミット履歴を判断してコンフリクトを起こさずにマージできる機能があるからこそ、rebaseが実現される。
リビジョン自体を管理対象としているからこそ可能なのだ。
@cointoss1973さんのMercurialのhgsubversion資料でも、リビジョンを一直線にするためにrebaseを使うことを示唆されている。
Mercurialのhgsubversion資料: プログラマの思索
分散バージョン管理はRedmineのようなチケット駆動開発ツールととても相性が良い。
特に、RedmineがVer1.4からマルチSCMリポジトリ対応になって、より相性が良くなった。
従来は、RedmineプロジェクトとSCMリポジトリは1対1対応の設計思想だった。
以前の僕は、trunkという新規開発のコードラインとリリースブランチという保守ブランチをRedmineの複数プロジェクト機能で分けて管理することで、一つのコードライン上の変更作業をプロジェクト単位でまとめて、タスク管理をやりやすくできるようになると考えていた。
しかし、この手法は、ブランチの寿命がかなり長い場合しか有効でない。
トピックブランチのように、特定目的のパッチを作る場合は、ブランチの寿命はとても短いので、ブランチ単位にRedmineプロジェクトを作る方法では、タスク管理がやりやすくなるとは言えない。
だから、マルチSCMリポジトリ機能によって、trunkから派生したトピックブランチやタスクブランチを一つのRedmineプロジェクトでまとめる事ができるので、一つの製品(システム)の変更作業は全て一つのRedmineプロジェクトで管理できる利点がある。
GitやMercurialで、実験的なブランチを自由に作ったとしても、そのブランチをRedmineプロジェクトのリポジトリに追加しておけば、trunkと実験的ブランチの派生関係を記録して残すことができる。
マルチSCMリポジトリ機能はRedmineのたった一つの機能改善に過ぎないが、この機能を有効に活用することで、ソフトウェア開発で最も制御しづらい並行開発を手なずける可能性もあるだろう。
アジャイル開発もその背景には並行開発という難しさが隠れているのだから、分散バージョン管理とチケット駆動開発を組み合わせることで、より強力にアジャイルに開発できる可能性もある。
色々考えてみる。
InfoQに分散バージョン管理の可能性の記事があったのでメモ。
ラフなメモ書き。
【元ネタ】
InfoQ: エンタープライズ分野での分散バージョン管理システム
(引用開始)
DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30分もかかっていた巨大なコードベースのブランチが２秒で済むようになり、マージも信頼できるようになった。
(引用終了)
(引用開始)
分散バージョン管理の本当の利点はブランチとマージを使って平行開発を推し進めることができる点にある。フィーチャーブランチ、タスクブランチ、リリースブランチというよく知られたブランチの切り方などを使えばとても優れた開発手法になる。この手法は前世代のSCMが適切なブランチやマージができなかったために忘れられていたものだ。
(引用終了)
【1】上記の解説の通り、GitやMercurialのような分散バージョン管理の利点は、ブランチとマージを自由自在に使った並行開発にある。
trunkをマスターのブランチとした場合、障害修正や機能追加など特定目的の開発は別ブランチで開発して、後でマージすればいい。
以前のCVSやSVNはマージ作業にとても神経質にやるしかなったが、GitやMercurialはマージコマンドが豊富で、コミット後の履歴すら後で改変することもできる。
Mercurialで独立並行リリース管理: プログラマの思索
Mercurialリポジトリの統合と分割: プログラマの思索
その場合、どのようなブランチ管理をすればいいのか？
拙著「Redmineによるタスクマネジメント実践技法
「パターンによるソフトウェア構成管理
第3回 成果物や組織の管理方法「マネジメント・パターン」：ITpro
Redmineと構成管理パターンを組み合わせる場合、プロジェクトとブランチを対応付ける場合と、チケットとブランチを対応付ける場合の2種類がある。
後者はトピックブランチと相性がよい。
そのアイデアは以前書いた。
ReviewBoardとMercurial＋TiDDは相性が良い？: プログラマの思索
Mercurialによるチケット駆動開発は強力だ！: プログラマの思索
【2】ブランチ管理に関しては、「A successful Git branching model」というブランチ管理のモデルがGitで提唱されており、git-flow というコマンドを使えば実現できる。
git-flow による構成管理とRedmineの関係: プログラマの思索
A successful Git branching model: プログラマの思索
チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索
また、この手法は、ブランチで作ったパッチをtrunkにPullすることでマージするため、GitHubのPullRequestに似た機能と密接に関係する。
以前はこのやり方が優れていると思っていた。
PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索
しかし、Redmine勉強会で丸山さんの発表資料を読んで、PullRequestという機能は実際の開発に向かないのではないか、と思っている。
第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索
Redmineの以前のコミッタEricと丸山さんのやり取りで、二人のマージに対する観点の違いが下記に記されている。
ChiliProject - Bug #127: Anonymous and Non member roles are not translated - ChiliProject
(引用開始)
Eric Davis が1年以上前に更新
Toshi MARUYAMA wrote:
Main line should use rebase. Revision graph is very dirty.
I disagree, see ChiliProject Repository for the details.
(引用終了)
ChiliProject - ChiliProject Repository - ChiliProject
1???Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentation
ChiliProjectは「A successful Git branching model」を採用しているが、複数人の開発者がパッチをtrunkへ直接Pullしているため、リビジョンを追いかけるのがとても煩雑。
PullやPushというマージコマンドは、コードラインにパッチをそのまま追加してしまうため、履歴があちこち分散してしまいがちになりやすい。
それに対して、Redmineのtrunkを見ると、trunkには唯一の開発用コードラインから必ずrebaseされる仕組みになっていて、リビジョンの履歴がとても分かりやすい。
また、rebaseする時に必ず定型的なコミットログが書かれているので、どのタイミングでrebaseされたのか、理解しやすい。
rebaseのイメージは、@yusuke_kokuboさんのつぶやきを参考にしたらとても分かりやすかった。
rebaseはメインラインへ別ブランチが合流するようなイメージのマージ作業のため、メインラインの履歴が改変されることなく維持される。
以前、まちゅさんから、PushやPullよりもrebaseを使った方がいいというアドバイスをもらった時があり、その意味を以前はきちんと理解できていなかったけれど、上記のやり取りを通じてrebaseの利点が何となく分かったような気がする。
【3】Redmineでは、Ver1.4からマルチリポジトリ機能が実現されたので、1プロジェクトで複数のリポジトリを追加できるようになった。
この機能によって、trunkから派生したトピックブランチ、リリースブランチ、タスクブランチなどは1個のプロジェクトにまとめることができる。
つまり、ブランチの寿命がとても短く、ブランチが派生された製品ではない場合、マルチリポジトリ機能を使うと、製品の機能改善や障害修正のブランチの履歴も同じプロジェクトのチケットから辿ることができる。
以前の僕は、Redmineの複数プロジェクト機能でブランチ管理するようにしていたが、この手法は派生したブランチが派生した製品に対応する場合だけで有効であり、トピックブランチのように寿命が短いブランチでは有効ではなかった。
子プロジェクトがたくさんできてしまい、逆に管理しにくくなったからだ。
Redmineプロジェクトとブランチ管理、ソフトウェア開発の組織構造の間には、密接な関係がある。
それは下記で書いた。
チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索
チケットがRedmineプロジェクトに登録されたリポジトリに関するソース修正と関係するのだから、チケットの集合体であるRedmineプロジェクトは、リポジトリからビルドされるモジュールの変更管理を行なっていることになる。
Redmineプロジェクトはビルドモジュール、つまり製品と1対1に対応すると考えた場合、「アーキテクチャは組織構造に従う」というConwayの法則が自然に浮かび上がってくる。
つまり、製品のアーキテクチャや製品の変更に関するタスク管理の範囲は、Redmineプロジェクトと比例しており、その性質をうまく使えば、変更管理の見通しが良くなると思う。
分散バージョン管理は、この手法をもっと洗練化させてくれる可能性があるように思っている。
IPAが非ウォーターフォール型開発の分析結果を公開されていたのでメモ。
平鍋さんも分析プロセスで加わっているみたい。
【元ネタ】
プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から － Publickey
非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）を公開
最近、マネージャ層や経営層からも、アジャイルな開発スタイルに関する言葉を聞くようになった。
特に経営者は、平鍋さんが提唱されているリーンの発想から理解して話している人が多いように思う。
上記の報告書では、海外の事例と日本を比較している部分が面白い。
中国は日本の影響を受けて、アジャイルがあまり普及していない指摘は参考になった。
日本では、業務システムの受託開発が主流のため、アジャイルな開発スタイルは導入しづらい部分が多い。
また、そういうビジネスが主流のために、ウォーターフォール型開発でどのように進めると良いか、というノウハウはそれなりにある。
特に品質管理は、他国に比べて優れている部分がある。
でも、日本の利点が海外とのソフトウェア開発の競争力に直結していないのが不思議な所。
クスマノの「ソフトウエア企業の競争戦略
多分、過剰品質の開発スタイルが現代のソフトウェアビジネスに合わなくなっているのではないかと思う。
また、プロジェクトを成功させることとビジネスで成功するのがそもそも完全に一致していないのではないか、という指摘をある人から受けた。
ソフトウェア開発はほとんどがプロジェクトなので、始まりがあって必ず終わりがある。その期間は正直短い。
その限られた短い期間で開発を終了させるのが目的となってしまい、顧客が求める本来の目的、つまり、プロジェクトで作られたシステムを有効利用することで顧客のビジネスを成功させるという観点が薄れてしまうのではないか、と。
実際、プロジェクトが始まったら、開発で手一杯で、まともに動くシステムに持っていくだけで精一杯だからだ。
むしろ、ウォーターフォール型開発で一発リリース直後のシステムはバグだらけで、開発チームも顧客もアップアップな状況の方が多い。
そんなことを思うと、そもそもプロジェクト型ビジネス自身が現代のビジネスにマッチしていなくなっているように思う。
ビジネス価値にすぐに直結しないシステムがどんどん作られているのではないか。
平鍋さんの会社が提供する価値創造契約、倉貫さんが提唱する納品しない受託開発は、その動機と似通っているように思う。
プロジェクト型開発でビジネス価値を確実に提供できる方法はあるのか？
僕はまだよく分からない。
【追記】これが日本のソフトウェア品質？ - Basicでは、日本のソフトウェア開発の高品質が世界で競争力を持たないのか疑問であるという指摘がある。
(引用開始)
日本についていえば、ソフトウェア開発における高い生産性と品質が、なぜ世界のソフトウェア業界での、より傑出した地位に繋がらなかったのかという謎が依然としてある。この問題は、我々の調査に回答を寄せた日本の大企業の開発文化に起因しているのだろう。
(引用終了)
Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。
これは使い道があると思う。
Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記
Ant,Jenkins,Sonarの導入手順 - Software Development Memo
findbugsをAntで使う。 - 東京のシステムエンジニア
(引用開始)
Jenkinsにビルドとユニットテストまでしかやらせてないっていう話を結構聞くので書いてみました。
そこまで自動化できているのなら次のステップの静的コード解析までやらせちゃっていいのになぁと。導入コストも低いですし。
「レガシーなのでユニットテストないからウチはCIなんて無縁だよ」っていうのもよく聞きますがユニットテストなくても
とりあえずJenkins立てて静的コード解析を継続的にかけさせるのがいいんじゃないかと思います。
CPDでどれだけコピペコードがあるのか分かりますし、FindBugs、PMD、CheckStyleでよくないコードがどれだけ含まれているのか、どんな内容なのか傾向を探れます。
自動で継続的に解析しておけば "これ以上警告が増えたら通知する" とか設定でできますし。
解析ツールの結果は常に絶対ではありませんが充分参考にはなります。
また結果が時系列にグラフになることで変化に気付くことができます。
「最近警告が減ってきているのでイイネ」とか「昨日極端に増えたけどどんな変更した？」とか。
プロジェクトやチームによりけりだとは思いますが個人的にはビルド、ユニットテスト、静的コード解析まではとりあえず導入していいんじゃないかと思います。
設定さえ頑張ればJenkinsが勝手にやってくれますし。
(引用終了)
テストコードがそもそも存在せず、ガラクタのようなレガシーコードが溢れているプロジェクトはとても多い。
そのようなプロジェクトに限って、リプレース案件とかデータ移行作業、システムのVerUpというポーティング作業が結構多い。
すると、まともに既存バグはもちろん、潜在バグのあるシステムを何とか頑張ってVerUpないし再構築し直さなければならない。
こういうプロジェクトは、作業の内容はとても分かりやすいが、デスマーチに陥りやすい。
何故なら、VerUpないし別の環境へシステムを移植することによって、潜在バグが出たり、環境に依存するライブラリとインターフェイスが合わないなど、面倒なバグが多発するからだ。
しかも、自動テストの環境がないので、手作業でテストするしかなく、延々とバグを手作業で潰すしかない。
そのようなプロジェクトの正攻法はテスト自動化のためにテストプログラムを書くことだろう。
それ以外にも、静的コード解析で自動化することによって、VerUpされたコンパイラやライブラリとの相性を早めに検知することもできる。
Jenkinsはプラグインが豊富であり、特に静的コード解析のレポートを即座に画面に出力してくれるのは便利。
特にFindBugsやCheckstyleは有名だ。
面白いのは、JenkinsのDRY Pluginで、コピペソースをチェックしてくれるそうだが、これはSW工学の論文でよく見かけるコードクローンと同じ内容だろうと思う。
似たようなソース、ロジックがあちこちに散らばっていると、必ず修正漏れが出て、バグの温床になる。
DRY Plugin - Jenkins - Jenkins Wiki
個人的には、これらの静的コード解析はビルドスクリプトで書くようにしたい。
MavenはJavaのEJBのように複雑すぎるため、Antで簡単に書ける方がいい。
ビルドスクリプトが必要な理由は、ビルド作業の一環として、静的コード解析や自動テストを行うのが本来の姿だと思うからだ。
ビルドされたシステムは納品対象であることから、単にコンパイルが通るだけでなく、自動テストで単体テストの品質はクリアされているのは当然だし、静的コード解析でコーディング規則に従っている検査をパスするのも当然だからだ。
つまり、ビルド作業、更には継続的インテグレーションとは、単純にビルドするだけでなく、常時リリース可能なシステムをいつでもワンクリックで出力して、顧客へ納品できることを指す。
この考え方が、常時デプロイ可能という継続的デプロイ、更には継続的デリバリーへ発展していく。
SonarとJenkins、Antを組み合わせるやり方もあるようだ。
Jenkinsにはたくさんの可能性が秘められていると思う。
色々試してみる。
TestLinkに似た機能を持つRedmineプラグインImpasseが公開されていたのでメモ。
まだインストールしていないが、とても気になる。
redmine_impasse/README.ja.rdoc at master ・ kawasima/redmine_impasse
(引用開始)
インパスはRedmineのプラグインとして動作するテストマネジメントツールです。
テストケースの管理
テスト計画の管理
テスターのアサイン
テスト予定日の登録
テストの実行管理
バグ票の起票
テスト進捗・メトリクスの取得
などの機能をもちます。
インパスではまずアプリケーション全体のテストケースを作り、この中から各バージョンと関連したテスト計画を作り、その中にテストケースを投入します。 テスト計画として登録されたケースには、テスターや実行予定日の割り当てを行いスケジュールを把握できるようにします。
テスターは自分に割り当てられたケースを実行し、その結果を記録します。実行した結果が不合格であれば、その内容をRedmineのissueとして起票できます。 テスト計画のメトリクスをメンバー別や日別の集計結果として参照することもできます。
使い方
設定
テストケースの管理
テストケースは、テストスイートと呼ばれる単位でグルーピングができます。 テストスイートの中にテストスイートを入れることもできるので、細かい分類も可能になります。
テストケースを新たに作るには、テストスイートを右クリックしコンテキストメニューを開き「Create」->「TestCase」を選択します。 そうするとテストケースの内容を入力するためのダイアログが開くので詳細を入力します。 テストステップは、そのテストケースを実行するための操作内容と期待する結果を順に記述します。 ドラッグ＆ドロップで順序を入れ替えることができます。
入力が完了したら保存を押してください。
(引用終了)
redmine_impasseのテーブル数は12個なので、TestLinkのそれに比べるとかなり少ない。
だから、TestLinkよりも簡易な機能と推測される。
しかし、テーブル名を見る限り、テストスイートでテストケースを管理できたり、テスト計画の管理、テスターのアサイン、テスト結果の管理、バグとテストケースの連携などができるようだ。
つまり、テスト管理で必要最低限の機能は実現されていると思われる。
テスト管理が普通の開発フェーズと異なる点は、大量のテストケースを保守したり、予定と実績の結果を出力して進捗管理したり、障害管理と連携する点だ。
TestLinkを運用してみて、テスト管理の難しさとTestLinkの有効性は十分に分かったけれど、TestLinkそのもののUIや機能がイマイチ使いづらいため、正直残念な部分がある。
上記のRedmineプラグインには少し期待してみたい。
なお、TestLinkについては過去の記事や資料を参考にしてみてください。
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索
【公開】SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」: プログラマの思索
Jenkinsではじめるビルド職人入門 | Gihyo Digital PublishingをiPod touchに入れたらとても読みやすかった。
考えたことをラフなメモ書き。
【元ネタ】
Jenkinsではじめるビルド職人入門 | Gihyo Digital Publishing
Jenkinsではじめるビルド職人入門 | Gihyo Digital Publishingでは、Jenkinsの使い方の前に、AntやMavenなどのビルドスクリプトのプログラミング作法を詳しく解説している。
事前知識がない人が読んだら、何故Jenkinsの解説よりも先にAntやMavenの解説があるのか、不審に思うだろう。
継続的インテグレーション(CI)を実施するには、SCMリポジトリのソースをビルドする必要があるが、ビルドするにはビルドスクリプトが必要だ。
ビルドスクリプトの技術としては、Cならmake、JavaならAntやMaven、Rubyならrakeがある。
しかし、ビルドスクリプトはmakeやAntやMavenのように少し毛並みの違うプログラミング作法が必要なので、すぐに書けない時も多い。
CIが普及していない原因の一つは、ビルドスクリプトのプログラミング技術があまり重視されていないことがあるように思う。
特に、Cのmakeをプログラミングするには慣れがかなりいる。
ビルドスクリプトの使い道としては、自動テストやテストレポート、カバレッジ、FindBugsやLintなどコーディング規則や潜在バグをチェックする静的コードチェック結果などもビルドスクリプトで出力できる。
つまり、ソースコードをビルドする時に、ソースコードの静的品質チェックや単体テストも実施することによって、ソフトウェアの品質を高める事もできる利点がある。
だが、CIツールのレポート機能を使えば、静的チェックやレポート出力はJenkinsで代用することもできるだろう。
Jenkinsはかなり高機能なので、メトリクス収集ツールやバッチ監視ツールとして扱うことも可能。
Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索
チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張: プログラマの思索
その場合、ビルドスクリプトでメトリクス収集やバッチ監視のような複雑な処理を実装できるのか、という疑問がある。
Jenkinsではじめるビルド職人入門 | Gihyo Digital Publishingでは、Groovyを使ったビルドスクリプトの例が書かれているが、最終的には、軽量で強力なスクリプト言語でビルドスクリプトを書くような手法が必要になってくると思う。
その流れを考えると、Rubyのrakeは自分自身のビルドやデプロイもRubyで書かれているので、汎用性が高い。
ソフトウェアを実装するプログラミング言語は随分発展してきたが、ビルドスクリプトのようにソフトウェア自身をプログラミングするための技法はまだまだ発展途上のように思える。
その技法はメタプログラミングにも関係してくるのではないか？
CIツールとビルドスクリプトの関係はもっと考えてみる。
【追記】
ビルドスクリプトの言語はシステムを実装する言語に依存しない例もあるという意見もありました。
上記はあくまでも一意見としてお読みください。
Scrumの公開資料を@ryuzeeさんがまとめてくれていたのでメモ。
【元ネタ】
Scrumに関する無料の日本語資料のまとめ | Ryuzee.com
最近、日本でもアジャイル開発が大手SIでも注目されている。
下記のニュースが最近は特にホットだろう。
若手リーダー層を対象としたアジャイル開発研修を開始 2012年4月17日 | ニュースリリース | NTTデータ
NTTデータのアジャイルは現場への警告であり、日本のソフトウェア産業の大きな1歩である | Act as Professional - hiroki.jp by HIROCASTER
XPやリーンソフトウェア開発は、「XPエクストリーム・プログラミング入門
でも、Scrumの解説本が日本ではあまりない。
「アジャイルソフトウェア開発スクラム
その理由は、Scrum特有の用語である(プロダクト)バックログ、スプリント、スクラムオブスクラム、チームリード、Velocity、ストーリーポイントなどを統一的に解説してくれる辞書であり、実践ノウハウが書かれた本が日本では出版されていないからだ。
何故、Scrum解説本が今頃になって必要になってきているのか？
その理由は、下記のTwitterで書いた。
すなわち、大手SIの観点では、マネジメントのフレームワークの一つとしてScrumを導入しようとしているが、アジャイル開発の誤った理解、特にScrumの誤った理解で今後アジャイル開発の失敗事例が多発しそうだからだ。
Twitter / hiranabe: @akipii スクラムの日本語書き下ろしの本が、来年ぞくぞくと出るらしいよ！
翻訳では「アジャイルな見積りと計画づくり
でも、Scrumやアジャイルも本来は日本発祥なのだから、日本人が書いた実践ノウハウ本が出版されて欲しいと思う。
日本でもScrumのコミュニティは活発に活動されているし、認定スクラムマスターも１００人以上超えていると聞くと、日本人が書いたScrum解説本を欲しがるマーケット状況は整ってきていると思う。
@hiranabeさんや@ryuzeeさんがそんなScrum解説本を出版されるのを期待しています。
「Redmineによるタスクマネジメント実践技法
励みになります。
既にRedmineもVer2.0.2、TestLinkもVer1.9.3になっていて、出版時のバージョンはかなり古いです。
ですが、ツールを使ってアジャイルに開発する手法について解説しているので、バージョンが古くてもそのエッセンスを読み取ってくれるだろうと思っています。
僕はチケット駆動開発を運用してみて、アジャイル開発の利点と運用時に失敗しやすい点を理解できた経験をしましたが、それは一事例に過ぎません。
XPやScrumは随分前から一部では既に運用されていて、その長所や運用時のアンチパターンもアジャイルコミュニティでは既に知られていました。
同様に、PMBOK、ITIL、CMMIなどもマネージャ層ならば、その良さや運用の難しさを既に知っている人も多いでしょう。
また、テスト管理手法や構成管理パターンもその界隈では既に知っている人も多いでしょう。
「チケット駆動開発」という概念が日本でこれほど普及した今、この本に書かれている内容は既に当たり前で、もっと先進的な使い方を行なっているチームや会社もあるかもしれません。
ですが、それらのノウハウをチケット駆動開発の上でアジャイルに開発する手法のコンテキストでまとめた点がこの本の良さだと思います。
そして、チケット駆動開発の経験から、アジャイル開発がソフトウェア開発の特徴に一番うまく適応しているという感触を持っています。
その感触をもっと理論的に他人に説明できるように、今後もまとめていきたいと思っています。
@hiranabeさんや@ryuzeeさんのTwitterを見かけて、ツール・プロセス・チームの間で別の観点の関連があるような気がした。
ラフなメモ書き。
Twitter / ryuzee: 高速道路が簡単に手に入るから乗ればいいけど、そこで何キロで走るかは、積んでるエンジンに依存するみたいな。（開発プロセスとツールとチームの話）
[書評]アジャイルソフトウェアエンジニアリング | Ryuzee.com
2006年以降のソフトウェア開発で感じることは、開発プロセスやチームをサポートする強力なツールが揃ってきたこと。
RedmineやTrac、GitやMercurial、Jenkinsなどのツールをうまく使いこなせば、以前はできなかったこと、以前は手作業が多くて労力がかかりすぎたことが随分解決できる。
高速道路が普及したことで遠方へ気楽に行けるようになった状況に似ている。
でも、強力なツールを使いこなしたからと言って、それでソフトウェア開発の諸問題が全て解決するわけではない。
チームで開発する場合、開発プロセスとツールをセットで運用することが大事になってくる。
その時、そのバランスが悪ければ、チームのパフォーマンスにせっかくのツールの良さが反映されない。
ツールを使うこと自身が目的になってしまって、本来のソフトウェア開発の成果物につながらない危険がある。
それは、高速道路が準備されたからと言っても、目的地に着くには、高速道路で走る車の性能、車のエンジンに依存しているのと同じ。
アジャイル開発の良さの一つは、チームやメンバーの力を引き出すことにフォーカスしていること。
特に平鍋さんが提唱されたプロジェクトファシリテーションは、ソフトウェア開発チームのチームビルディングを重視する点がとても優れていると思う。
とても面白い時代になってきたなと思う。
エリック・エヴァンスのドメイン駆動設計
@sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。
ラフなメモ書き。
【元ネタ】
ドメイン駆動設計: プログラマの思索
ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索
Agile開発に足りないもの～モデリング技術: プログラマの思索
ドメイン駆動設計
一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。
もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。
前者は、「ドメイン駆動設計
第1・２部では、アナリシスパターン
つまり、解説の対象は業務分析ではなく、オブジェクト指向設計が対象になっている。
普通は、分析と設計は本質的に違う。
特に業務分析では、顧客が自分の業務で抱える問題点に対して、何らかのソリューションを提供するために、現実の業務を分析した後、あるべき業務の姿を定義して、業務システムのモデルを作る。
これが分析モデルであり、普通は、AsIsモデルを作った後に、実現可能性(フィージビリティ)やコスト、納期、顧客の要求などを加味して、ToBeモデル(分析モデル)を確定する。
その後、分析モデルは詳細化されて設計モデルとなり、実装工程に入っていく。
IPAが定義したITSSスキルモデルでは、分析工程はITストラテジスト、設計工程はITアーキテクトが担当するわけで、分析と設計は作業内容もロールも異なる。
この手法は典型的なWF型開発の分析・設計技法だ。
だから、外部設計・内部設計という言葉で作業や工程を使い分ける。
そもそも「ドメイン」という概念は分析すべきものであるのが普通だ。
実際の用語としても「ドメイン設計」よりも「ドメイン分析」の言葉のほうを多用するからだ。
だが、ドメイン駆動設計
第３部の191ページに「深いモデル」「浅いモデル」という言葉が出てくる。
Agile開発に足りないもの～モデリング技術: プログラマの思索で@sugimoto_keiさんは、浅いモデルはビジネスモデル、深いモデルは帳簿モデルと呼んで区別されていたが、上記の考え方に従えば、深いモデルは分析モデル、浅いモデルは設計モデルに相当する。
つまり、開発者がシステムを実装対象として捉える場合は設計モデルという浅いモデルであり、顧客やアーキテクトがシステムを抽象化した本質的なモデルとして捉える場合は分析モデルに相当するわけだ。
そして、設計モデルから分析モデルへモデルが変化するタイミングは、第8章の「ブレイクスルー」と呼ばれる。
つまり、開発者が設計モデルを作っている最中はまだ本質的な概念を見いだせていないが、そこから本質的な概念を見出してモデルをより汎用的・抽象的な分析モデルに変換できた時を指すわけだ。
実際、第3部では、設計モデルから分析モデルへ変換できた例として、貨物輸送システムと利息計算サービスの2つの例が出てくる。
貨物輸送システムのモデルでは、荷物の物流が本質的な問題(ドメイン)ではなく、荷物の権利(つまり船荷証券という勘定科目)が本質的な概念に相当し、それがオブジェクトとしてモデルに自然に出てくる。
また、利息計算サービスでは、単なる利息の計算式が本質的な問題ではなく、発生主義会計(つまり、前払保険料、未払利息などの経過勘定科目)の概念がモデルに自然に出てきて、モデルがより抽象的に整理される。
すなわち、ドメインという本質的な概念がモデルのオブジェクトとして現れたタイミングが、設計モデルから分析モデルへ変わったブレークスルーというわけだ。
後者としては、ドメイン駆動設計
過去のオブジェクト指向設計では、業務分析した業務をユースケース図で洗い出し、そのユースケースから概念モデルを作り、実装に近い設計モデルへ詳細化してプログラムになっていくので、分析と設計を明確に分けていたように思う。
実際、概念モデルの粒度はとても荒くて設計モデルへ詳細化しなければ、実装できない。
オブジェクト指向設計の最大の利点は、要件定義から分析、設計、実装までオブジェクト指向の観点で一気通貫で作れる点にあると言われてきた。
しかし、たとえオブジェクト指向設計であっても、実際のソフトウェア開発では、分析モデル、そして実際のプログラムはどんどん乖離していく。
分析モデルをいくら頑張って作っても、実際に作ってみると、システムとして実現するには仕様そのものに矛盾がある場合は多く、開発工程で妥協して作る時が多い。
そしてリリース時には、当初の分析モデルとは微妙に違ったシステムとして完成して、実際の運用に入っていく。
つまり、分析モデルから実際に運用されいているプログラムまでのトレーサビリティを担保するのは実際はとても難しい。
作ってみて初めて顧客が想像していた仕様とプログラムが異なるのはよくあることだ。
だが、ドメイン駆動設計
つまり、ドメイン駆動設計
そして、ドメイン駆動設計
つまり、実装前にきちんとした仕様が確定しているプロダクトアウト指向の開発ではなく、マーケットにいち早くサービスや製品を投入しながら、売れ行きに応じて機能を変えていくマーケットイン指向の開発の方が向いている。
実際、マーケットイン指向の開発では、分析モデルは実装前に確定しているわけではないから、プログラミングしながら分析モデルもブラッシュアップせざるを得ない。
例えば、変化の激しいWebサービスやスマートフォンのようなVerUpの激しい製品の開発にドメイン駆動設計
だから、設計を重視するアジャイル開発者がドメイン駆動設計
でも、僕の感想としては、ドメイン駆動設計
実際、ドメイン駆動設計
例えば、勘定パターンはアナリシスパターンにあるし、腐敗防止層は実践UMLのファサードパターン(純粋架空物：Pure Fabrication, 間接化：Indirection)そのものだ。
また、設計モデルから分析モデルへ抽象化していく場合、業務知識がなければ変換できないだろう。
僕が見聞きした限り、DOAの設計者は会計システムや生産管理に詳しい人が多いが、彼らは実際の業務経験が豊富なため、分析モデルを設計モデルに詳細化できるし、設計モデルから分析モデルへ抽象化していくこともできる。
特に日本では、業務システム開発とDOAを組み合わせた歴史があるので、業務分析と設計をミックスした手法がたくさんある。
例えば、日本のDOAには、渡辺さんが提唱するDOA、T字型ER、TH法など各種の流派がたくさんある。
大半のDOAの設計者は業務経験が深いがゆえに、分析モデルと設計モデルの違いやモデリングの技法についてたくさんのノウハウは持っているので、ドメイン駆動設計
とは言え、ドメイン駆動設計
【追記1】
個人的には、第３部が一番面白いと思う。
第１～２部はアナリシスパターン
第３部は、設計モデルから分析モデルへ質的に変換する事例が出てくるので、この本の一番の見所だと思う。
第４部は、ソフトウェアプロダクトラインに似たモデリングプロセスの解説のような感想を持った。
「蒸留」という概念は、SPLで言うコア資産の抽出プロセスに似ている。
チームによるモデリング戦略は、アーキテクチャやモデルは組織構造に依存しているというConwayの法則の焼き直しのように思える。
【追記2】
関西でドメイン駆動設計
アジャイル開発で設計や業務分析に悩んでいる人、オブジェクト指向設計をもっと勉強したい人にはお勧めです。
形式手法はブレイクするはずとずっと言われながら、なかなか普及しない。
その理由は形式手法の使い道が限られているからだと思っている。
考えたことをメモ書き。
形式手法は各種の手法があるが、モデル検査が一番わかりやすい。
モデル検査のやり方は、実際のプログラムから状態遷移図というモデルをリバースして、本来の仕様と状態遷移図を比較検討して、ありえない状態遷移があればそれはバグになることを説明するのに使う事例が多い。
モデル検査の分かりやすい例としては、以前出題されたソフトウェア開発技術者試験の午後問題があげられる。
下記の問題2に相当する。
平成20年度春期試験ソフトウェア開発技術者試験（SW）午後Ⅰ
問題では、ある関数のフローチャートから状態遷移図を生成する。
その状態遷移図に対して、不具合を発見するために、不具合が存在しない条件式つまり本来の仕様を定義した後、モデル検査ツールを使って状態遷移図を網羅的にチェックして、条件式を満足するかどうか判定する。
当然、条件式を満たさない場合、バグになる。
そのバグは、モデル検査ツールが状態遷移図の経路に相当するので、不具合を再現する事が可能になるという流れ。
上記の問題にも書かれているが、モデル検査の特徴はいくつかある。
一つは、従来のテストのように大量のテストデータを準備する必要はない。
状態遷移図さえモデル化できれば、モデル検査ツールを使って、すべての経路計算をすればいい。
ソフトウェアテストが難しい理由の一つは、多種多様なテストデータの作り込みに手間がかかることだから。
もう一つは、再現しづらいバグや複雑な仕様の組みわせで発生するバグを発見しやすいこと。
この種類のバグは、探索的テストで発見する時が多いが、限られた工数で探索的テストを実施して、非常に稀だが重大なバグを発見できるとは限らない。
むしろ、モデル検査ツールを使って、総当たりで自動計算した方が効率が良い場合もある。
だが、モデル検査ツールは既存のプログラムから状態遷移図を自動生成してくれるとは限らない。
そもそもシステムの状態遷移図をきちんと作るのはかなりの技術力を要するし、労力もかかる。
また作成した状態遷移図の精度が高くなければ、当初の目的である再現しづらいバグを見つけることができない。
もちろん、状態の数が多いほど計算は爆発するので、いくらコンピュータの性能が良くなったと言っても、すべての状態の経路を計算し尽くすことができない場合もある。
このように、形式手法の1種類であるモデル検査の使い道は、ソフトウェアテストの中でも探索的テストを補完するような使い道しかない。
信頼性が品質要件で非常に重要なプロジェクト、例えば人工衛星や社会的インフラの場合では、モデル検査による再現しづらい不具合探しも重要だろう。
だが、ソフトウェアテストの本質的な問題に焦点を当てているとはいえないと思う。
形式手法はもちろんこのような使い道だけではない。
形式手法の本来の使い方は、プログラミングに入る前の設計工程で、SEが作った詳細な設計書に書かれた仕様を形式手法でモデル化して、矛盾や不整合を洗い出すことにある。
IPAが組込ソフトウェア開発の品質改善で形式手法を適用できないか、長年研究している理由はそこにある。
しかし、そのやり方はまだうまくいっているとは言えないと思う。
また、この発想はウォーターフォール型開発特有の考え方だ。
何故なら、前工程の手戻り作業をできるだけなくすために、プログラミングせずに設計工程の品質をあげようとするやり方だから。
この発想は、ソフトウェア開発を工程単位に分断せず、設計もプログラミングもテストも一体化して開発を進めるアジャイル開発とは本質的に異なる。
とはいえ、形式手法とアジャイル開発を組み合わせて実践されている細谷さんの事例もある。
色々探ってみる。
最近のコメント