« 2012年5月 | トップページ | 2012年7月 »

2012年6月

2012/06/30

SVNバックアップの復習

SVNバックアップのコマンドを記録しておく。

【元ネタ】
Subversionリポジトリのバックアップ( svnsync )

Subversionの履歴を保持したままリポジトリを移動するには - システム開発ブログ (システム開発のアイロベックス|東京都新宿区の業務システム開発会社)

■SVNリポジトリ同士を同期
svnsync init [移動先リポジトリ] [移動元リポジトリのURL]
svnsync sync [移動先リポジトリ]

■SVNリポジトリからダンプファイルを生成
svnadmin dump [移動元リポジトリのパス] > [ダンプファイル名]

■SVNリポジトリでダンプファイルを読み込む
svnadmin load [移動先リポジトリのパス] < [ダンプファイル名]

また、SVN→Mercurialへの変換方法は下記を参考にする。
SVNリポジトリをMercurialと同じPCに作ってsvnsyncで同期した後、hg convertした方が速い。

svn リポジトリをmercurialに変換 - Ian Lewis

Subversionの履歴をMercurialに引き継ぐ - 0xFF

| | コメント (0)

日本の製造業もアジャイルの概念が必要ではないか

世界で勝負する仕事術 最先端ITに挑むエンジニアの激走記」を読んで、半導体業界でさえもアジャイルの概念が必要であると分かった。
考えたことをラフなメモ書き。

半導体といえば、エルピーダ破綻のニュースが記憶に近い。
電子立国日本の自叙伝は当時とても面白かったが、今はそれも遠き栄光。
DRAMは廃れ、今はフラッシュメモリが全盛の時代。
著者は元東芝のフラッシュメモリの半導体エンジニア。

「走りながら考えることが重要」と著者は説く。
半導体工場は最初から完成形が見えているわけではない。
数年後に売れるイメージを浮かべながら、工場も製造装置も作っていく。
先にじっくり考えてから動き出すのではもう遅い。

この考え方はアジャイルソフトウェア開発に似ている。
顧客も開発者もシステムの完成形を最初からイメージできているわけではない。
顧客の要望を引き出し、実際に作ってみて、顧客の評価を受けながら、少しずつ改善していく。
あるいは、マーケットの状況をうかがいながら、Webサービスを少しずつ機能改善していき、時代の流れに乗る方向へ進化させていく。

最初に決めた計画通りに物事が進むという仮定で、ガチガチに進捗を管理していく方法は今の時代には向いていない。
しかも、IT業界だけでなく、半導体という業界でも同様という話が興味深い。

似たような話は、「グーグルで必要なことは、みんなソニーが教えてくれた」の辻野さんも指摘している。

ユーザの力を利用するアジャイル開発: プログラマの思索

元ソニーのエンジニアも「走りながらユーザーの力を利用して製品の完成度を継続的に上げていく」「ネットの群衆の英知を使って問題発見と問題修復をやっていく」ことの重要性を説いている。
この話はまさにアジャイルソフトウェア開発の概念そのものだ。

最初から完成形を作るのではなく、ユーザの力を利用して機能改善のアイデアを得たり、問題発見や問題修復のフィードバックをもらうことで、製品の完成度を高めていく。
辻野さんも「走りながら作っていく」姿勢の重要性を説いている。

この仕組みは既にアジャイルソフトウェア開発では、「小規模リリース」という概念によって既に明確化されている。
XPが発見し、Scrumがそれをプロセスフレームワークとして形式知にまとめた。
我々IT技術者は既に知っている考え方は、製造業では多分マイナーな考えで、誰も知っていないのかもしれない。

また、生態系という考え方も大事。
最初はデジカメの記憶媒体に過ぎなかったフラッシュメモリが、AppleのiPodによって一躍脚光を浴び、iPhone/iPadというスマートフォン市場が生まれることによって、主流となり技術革新が後押しされた。
スマートフォンがフラッシュメモリだけでなく液晶、CPUなどの部品の技術革新を各メーカーに促し、どんどん使いやすくなっている。
新製品が新しい需要を生み出し、更なる技術革新が発展していくという流れ。
そして、そのマーケットにたくさんのメーカーがしのぎを削りながら、参入してくるという生態系。

でも、どうして日本の製造業はこれほど優秀な人材をやすやすと手放してしまうのか?
青色ダイオードの中村さん、「世界で勝負する仕事術 最先端ITに挑むエンジニアの激走記」の竹内さん、「グーグルで必要なことは、みんなソニーが教えてくれた」の辻野さんのいずれの人も、優れた能力を持ちながら、社内闘争に巻き込まれて、本来の力を発揮することができず、結局会社を去った。

著者はこんなことを書いている。
日本国内に人材流動性がないため、国外に優秀な人材が流れてしまい、日本国内の競争力を貶めているという指摘。

(引用開始)
人材確保のために奔走していて最も強く感じるのは、優秀な人材がいないことではなく、優秀な人材が日本から出て行ってしまうことへの危惧です。
最近は日本のメーカーも簡単にリストラをしたり、早期退職者を募るようになりました。
国内にその受け皿がないため、そこから飛び出した優秀な技術者の多くは、韓国や台湾などの渡ってしまいます。切る側にとっては合理的な人材整理なのでしょうが、国全体から見れば貴重な人材の流出です。
(引用終了)

多分、半導体業界だけでなく、家電などの他の製造業の業界でも同様の傾向ではなかろうか?
著者は産学連携のように、企業で経営者になれなかった人は大学などの関連機関で教育や研究に携わってもらうような仕組みが必要ではないか、と言っている。
でも、この考え方は官僚の天下りと構造は全く同じ。
天下り構造は悪く言われるけれども、大学や産業界、官界との人材交流を活発化させるために必要なのだろう。

日本の製造業もアジャイルの概念が必要ではないか?と思う。

| | コメント (1)

2012/06/28

Scrumの組織パターン

@kawagutiさんのBlogにScrumの組織パターンが載っていたのでメモ。

【元ネタ】
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti の日記 (id:wayaguchi)

パターン、Wiki、XPは良書: プログラマの思索

【1】@haradakiroさんから、Scrumはパターンランゲージであるという意見を聞いて正直びっくりした。
XPこそがパターンランゲージであると思っていたから。
でも、上記の記事を読んでその意味を理解した。

上記の記事のパターンは構造がラフすぎて、正直理解しにくい。
原本を読むと、パターンの背景が詳しく書かれているだろうか?
とても興味がある。

僕はパターンという考え方が好き。
ソフトウェア工学や開発プロセスのように、人が関わる活動を支配する法則を説明するのに、経験則をパターンという言葉で表現できるのはとても分かりやすいと思う。
パターンはどんな背景や文脈で有効で、逆にどのような状況では有効でないのか、をはっきり示してくれるからだ。

パターンという考え方は性格学に似ているように思う。
性格学にはユングやフロイトなどたくさんの流派があるが、人の性格がどの分類に当てはまるのかが重要なのではなく、分類した結果現れた類型(タイプ)がどんな本質を持っているのか、を示しているのが重要、という話を読んだことがある。
その考え方をパターンに当てはめると、我々の現場の問題に対してパターンをそのまま当てはめるよりも、そのパターンの背景や本質を理解することによって、問題をよりシンプルな形で解きやすくしてくれるものだと思う。

パターンは経験則から生まれた社会科学に似た法則だ。
だから、パターンはある特定の時代や場所に依存する。
物理学や数学の法則のようにいつでもどこでも通用するわけではないが、パターンはその時代や場所から生じる制約条件を明らかにしてくれると思う。

【2】パターンの考え方で面白い特徴は、複数のパターンを組み合わせると意外な効果が現れることだ。
XPには10個以上のプラクティスがあるけれども、ソフトウェア開発の全体進捗や品質について何一つ語っていない。
でも、テスト駆動や継続的インテグレーションなどのプラクティスを組み合わせることによって、ソフトウェアの品質を従来のやり方よりも劇的に高めることができる。
同様に、計画ゲームやイテレーション単位の小規模リリースなどのプラクティスを行うことによって、開発の進捗をコントロールしやすくなり、そこからVelocity(開発速度)というアジャイル開発特有の概念も生まれてくる。

すなわち、ソフトウェアの品質や開発の進捗などの概念は、その概念自体を追いかけても掴みどころがなく、むしろ無関係と思われるプラクティスを徹底的に行うことによって逆にその概念に迫ることができるのだろうと思う。

この辺りは色々考えてみる。

| | コメント (0)

2012/06/24

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか

SEA関西のドメイン駆動設計の講演を聞いてきた。
感想をラフなメモ書き。

【元ネタ】
第47回 SEA関西プロセス分科会「ドメイン駆動設計」#SEAKANSAI #kspinddd #dddjp - Togetter

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索

Twitter / masuda220: 今日の資料、公開しました。 ?#SEAKANSAI? ?#kspinddd? ?#dddjp? " ドメイン駆動設計 実践ガイド" http://www.slideshare.net/masuda220/ss-1 … @slideshareさんから

【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計」の本の目次に従って説明してくれたので、とても分かりやすかった。
OOAに関しては「実践UML」「アナリシスパターン」「ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML」などを2000年代前半に勉強会で読みこなしていたから、ドメイン駆動設計では、オブジェクト指向設計をどのように生かしているのか、が理解できたからかもしれない。

増田さんの職歴を聞いた所、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のシーケンスなどと同じだ。

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

また、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の重要性はもう一度再認識すべきだと思う。
自分の中でももう一度整理してみる。

【追記】
増田さんから下記の感想がありました。
上記はあくまでも一意見です(^^)

Twitter / masuda220: OOAとDOAって排他的な対立手法なのかなあ。私はたぶん厳密に区別せずにいっしょに使っている。RT @akipii: ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか http://bit.ly/Mjey6M

| | コメント (0)

2012/06/20

「はじめて学ぶソフトウェアのテスト技法」は良本

はじめて学ぶソフトウェアのテスト技法」を読み直して、いい本と思ったのでメモ。

【元ネタ】
はじめて学ぶソフトウェアのテスト技法 : 賢者の図書館 (Under Construction) : livedoor Blog(ブログ)

ソフトウェアの安全性を考える - Basic

Twitter / akipii: 「はじめて学ぶソフトウェアのテスト技法」を読んでみた。同値クラステスト、境界値テスト、デシジョンテーブルテスト、ペア構成テスト、パス制御テスト、状態遷移テスト、探索的テストなどの手法を丁寧に説明してくれている。良本。 http://www.amazon.co.jp/dp/4822282511

Twitter / akipii: テスト駆動開発や単体テストを実施する時、どんなテストをすれば良いのか、と聞かれる時がある。やみくもにテストメソッドを実装してもパスを網羅しなければそこからバグが出る。各種のテスト技法で効率的にテストできるし、テスト技法はテストメソッドの実装にも役立つ。

Twitter / akipii: IF文やループ処理のテストでは同値クラステストや境界値テストが有効だし、ライブラリやOSのバージョンの組み合わせならデシジョンテーブルテストやペア構成テスト、直交表が有効。シナリオベースなら状態遷移テストが有効。どの観点でテストして品質を確保するのかという戦略が重要。

初心者はRubyやJavaなどのプログラミングから入るけれど、テスト技法の習得も重要。
書いたプログラムが正しく動いているという正当性は、テストした結果を見せなければ誰も信用しない。

はじめて学ぶソフトウェアのテスト技法」では、各種のテスト技法を具体例を付けながら丁寧に説明してくれている。

個人的には、テスト技法を使いこなしているかどうかの簡単な基準は、同値クラステストと境界値テストだと思う。
テストで使われるテストデータは、同値分析によってかなり減るのに、無駄にたくさんのデータを使って同じテストをしている人もいる。それは労力の無駄だ。
プログラムのバグは、境界値で発生する時が多いが、境界値付近のテストが不十分な人も多い。

また総合テストやシステムテストのように、シナリオベースないし本番環境に近いデータを使う場合、データの組み合わせを十分に考慮する必要がある。
その場合、ペア構成テストや直交表を使いこなせると威力を発揮するだろう。

日本の品質管理は世界でもトップクラスだと思うが、その理由は、詳細な仕様書をあらかじめ作っておき、その仕様書を元に、ペア構成テストや直交表を使って、想定される本番運用のテストデータを作りこんでテストする方法でやってきたからだと思う。
TestLinkを使った時に感じたことは、テスト技法はプログラミング技法とは異なる技術であり、どうしてもアジャイル向きと言うよりも計画駆動になりやすい。
アジャイル開発と組み合わせたテスト技法はもっと色々研究される余地があるように思う。

| | コメント (0)

2012/06/19

3ウェイマージというマージアルゴリズム

分散バージョン管理のマージコマンドが優れているのは、3ウェイマージが使われているのではないか、と思った。
3ウェイマージに関する記事をメモ。

【元ネタ】
変更をマージする ? Bazaar v2.6.0dev2 documentation

JapaneseTutorialConflict - Mercurial

マージ (バージョン管理システム) - Wikipedia

競合の編集~TortoiseMerge

第3章 TortoiseMergeの使い方

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の違いは単なるツールの違いではない。
バージョン管理ツールにおける機能や設計思想が根本から異なっているのだ。

| | コメント (0)

2012/06/18

分散バージョン管理はバージョンではなくリビジョンを管理する

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できることによって、マージ作業の失敗を恐れることなく、何度でも試すことができる。

Mercurialの黒魔術: プログラマの思索

マージコマンドで一番簡単なものは、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のたった一つの機能改善に過ぎないが、この機能を有効に活用することで、ソフトウェア開発で最も制御しづらい並行開発を手なずける可能性もあるだろう。
アジャイル開発もその背景には並行開発という難しさが隠れているのだから、分散バージョン管理とチケット駆動開発を組み合わせることで、より強力にアジャイルに開発できる可能性もある。

色々考えてみる。

| | コメント (0)

2012/06/16

分散バージョン管理の可能性

InfoQに分散バージョン管理の可能性の記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
InfoQ: エンタープライズ分野での分散バージョン管理システム

(引用開始)
DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30分もかかっていた巨大なコードベースのブランチが2秒で済むようになり、マージも信頼できるようになった。
(引用終了)

(引用開始)
分散バージョン管理の本当の利点はブランチとマージを使って平行開発を推し進めることができる点にある。フィーチャーブランチ、タスクブランチ、リリースブランチというよく知られたブランチの切り方などを使えばとても優れた開発手法になる。この手法は前世代のSCMが適切なブランチやマージができなかったために忘れられていたものだ。
(引用終了)

【1】上記の解説の通り、GitやMercurialのような分散バージョン管理の利点は、ブランチとマージを自由自在に使った並行開発にある。
trunkをマスターのブランチとした場合、障害修正や機能追加など特定目的の開発は別ブランチで開発して、後でマージすればいい。
以前のCVSやSVNはマージ作業にとても神経質にやるしかなったが、GitやMercurialはマージコマンドが豊富で、コミット後の履歴すら後で改変することもできる。

Mercurialで独立並行リリース管理: プログラマの思索

Mercurialの黒魔術: プログラマの思索

Mercurialリポジトリの統合と分割: プログラマの思索

その場合、どのようなブランチ管理をすればいいのか?
拙著「Redmineによるタスクマネジメント実践技法」で紹介したのは、ソフトウェア構成管理パターンを参照したやり方。
パターンによるソフトウェア構成管理」の内容は今となっては古くなっているが、構成管理パターンを明確に解説している本はこの本ぐらいしかない。

brainremix: ソフトウェア構成管理パターン

第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はメインラインへ別ブランチが合流するようなイメージのマージ作業のため、メインラインの履歴が改変されることなく維持される。

rebaseのイメージ: プログラマの思索

以前、まちゅさんから、PushやPullよりもrebaseを使った方がいいというアドバイスをもらった時があり、その意味を以前はきちんと理解できていなかったけれど、上記のやり取りを通じてrebaseの利点が何となく分かったような気がする。

【3】Redmineでは、Ver1.4からマルチリポジトリ機能が実現されたので、1プロジェクトで複数のリポジトリを追加できるようになった。
この機能によって、trunkから派生したトピックブランチ、リリースブランチ、タスクブランチなどは1個のプロジェクトにまとめることができる。
つまり、ブランチの寿命がとても短く、ブランチが派生された製品ではない場合、マルチリポジトリ機能を使うと、製品の機能改善や障害修正のブランチの履歴も同じプロジェクトのチケットから辿ることができる。

以前の僕は、Redmineの複数プロジェクト機能でブランチ管理するようにしていたが、この手法は派生したブランチが派生した製品に対応する場合だけで有効であり、トピックブランチのように寿命が短いブランチでは有効ではなかった。
子プロジェクトがたくさんできてしまい、逆に管理しにくくなったからだ。

Redmineプロジェクトとブランチ管理、ソフトウェア開発の組織構造の間には、密接な関係がある。
それは下記で書いた。

チケット駆動開発がもたらした新しい観点part1~Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索

チケットがRedmineプロジェクトに登録されたリポジトリに関するソース修正と関係するのだから、チケットの集合体であるRedmineプロジェクトは、リポジトリからビルドされるモジュールの変更管理を行なっていることになる。
Redmineプロジェクトはビルドモジュール、つまり製品と1対1に対応すると考えた場合、「アーキテクチャは組織構造に従う」というConwayの法則が自然に浮かび上がってくる。
つまり、製品のアーキテクチャや製品の変更に関するタスク管理の範囲は、Redmineプロジェクトと比例しており、その性質をうまく使えば、変更管理の見通しが良くなると思う。

分散バージョン管理は、この手法をもっと洗練化させてくれる可能性があるように思っている。

| | コメント (0)

2012/06/15

プロジェクト型開発は本当にビジネス価値を提供しているのか~IPAの非ウォーターフォール型開発の分析報告

IPAが非ウォーターフォール型開発の分析結果を公開されていたのでメモ。
平鍋さんも分析プロセスで加わっているみたい。

【元ネタ】
プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から - Publickey

Twitter / kimutansk: 確かに、プロダクト開発の方がアジャイルの方法論は適用しやすいですねぇ>プロジェクトという形態は下火になり、プロダクト開発が台頭している。IPAの調査から - Publickey http://www.publickey1.jp/blog/12/ipa.ht …

Twitter / hiranabe: おお、このまとめはすごい。RT @orangesystem: 妥当な分析になってると思う。外注丸投げとアジャイル開発は水と油。: IPA、「海外における非ウォーターフォール型開発の拡大」に関する分析結果を発表 http://bit.ly/KouK8l

非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 (非ウォーターフォール型開発の海外における普及要因編)を公開

Twitter / yusuke_arclamp: 大変、悲しい内容。なんだかなぁ "@publickey: ブログ書きました: 海外でなぜアジャイル開発が普及しているのか? IPAが分析と提言 http://bit.ly/KyxoF7 "

最近、マネージャ層や経営層からも、アジャイルな開発スタイルに関する言葉を聞くようになった。
特に経営者は、平鍋さんが提唱されているリーンの発想から理解して話している人が多いように思う。

上記の報告書では、海外の事例と日本を比較している部分が面白い。
中国は日本の影響を受けて、アジャイルがあまり普及していない指摘は参考になった。
日本では、業務システムの受託開発が主流のため、アジャイルな開発スタイルは導入しづらい部分が多い。
また、そういうビジネスが主流のために、ウォーターフォール型開発でどのように進めると良いか、というノウハウはそれなりにある。
特に品質管理は、他国に比べて優れている部分がある。

でも、日本の利点が海外とのソフトウェア開発の競争力に直結していないのが不思議な所。
クスマノの「ソフトウエア企業の競争戦略」でも、日本企業は品質がとても優れているのに、ソフトウェアの世界では目立った動きがないと指摘していた。
多分、過剰品質の開発スタイルが現代のソフトウェアビジネスに合わなくなっているのではないかと思う。

また、プロジェクトを成功させることとビジネスで成功するのがそもそも完全に一致していないのではないか、という指摘をある人から受けた。
ソフトウェア開発はほとんどがプロジェクトなので、始まりがあって必ず終わりがある。その期間は正直短い。
その限られた短い期間で開発を終了させるのが目的となってしまい、顧客が求める本来の目的、つまり、プロジェクトで作られたシステムを有効利用することで顧客のビジネスを成功させるという観点が薄れてしまうのではないか、と。
実際、プロジェクトが始まったら、開発で手一杯で、まともに動くシステムに持っていくだけで精一杯だからだ。
むしろ、ウォーターフォール型開発で一発リリース直後のシステムはバグだらけで、開発チームも顧客もアップアップな状況の方が多い。

そんなことを思うと、そもそもプロジェクト型ビジネス自身が現代のビジネスにマッチしていなくなっているように思う。
ビジネス価値にすぐに直結しないシステムがどんどん作られているのではないか。
平鍋さんの会社が提供する価値創造契約、倉貫さんが提唱する納品しない受託開発は、その動機と似通っているように思う。

プロジェクト型開発でビジネス価値を確実に提供できる方法はあるのか?
僕はまだよく分からない。

【追記】これが日本のソフトウェア品質? - Basicでは、日本のソフトウェア開発の高品質が世界で競争力を持たないのか疑問であるという指摘がある。

(引用開始)
日本についていえば、ソフトウェア開発における高い生産性と品質が、なぜ世界のソフトウェア業界での、より傑出した地位に繋がらなかったのかという謎が依然としてある。この問題は、我々の調査に回答を寄せた日本の大企業の開発文化に起因しているのだろう。
(引用終了)

| | コメント (1)

2012/06/14

Jenkinsで静的コード解析を常時自動化する

Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。
これは使い道があると思う。

【元ネタ】
Twitter / akipii: テスト自動化ができなくても静的コード解析を回帰テストのように使うのは効果的という指摘。ガラクタのレガシー資産プロジェクトで有効かもしれない。Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 http://goo.gl/rpTq7

Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記

Twitter / akipii: Antのbuild.xmlをSonarが読み込んでソースの各種メトリクスを出力し、更にJenkinsと連携してCronのように使う手法。SonarがMavenだけでなくAntも使えると便利。Ant,Jenkins,Sonarの導入手順 http://goo.gl/wXJYS

Ant,Jenkins,Sonarの導入手順 - Software Development Memo

findbugsをAntで使う。 - 東京のシステムエンジニア

第6章 FindBugs Ant タスクの使用法

Checkstyle - Ant タスク

AntでPMDを実行する - てんぷらメモ

Ant を使ってプロジェクト・ビルドを自動的に生成する

Coberturaでテスト対象範囲を調べる


(引用開始)
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にはたくさんの可能性が秘められていると思う。
色々試してみる。

| | コメント (0)

2012/06/13

TestLinkに似た機能を持つRedmineプラグインImpasse

TestLinkに似た機能を持つRedmineプラグインImpasseが公開されていたのでメモ。
まだインストールしていないが、とても気になる。

【元ネタ】
Twitter / kawasima: Redmineで出来るソフトウェアテストマネジメント。もうすぐ他のプロジェクトで使い始めるので、v1.0.0のリリースしました。Redmine2.xには今のところ非対応です。 https://github.com/kawasima/redmi …

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のベストプラクティス~日本の品質管理技術を見直そう」: プログラマの思索

| | コメント (0)

2012/06/10

CIツールはビルドスクリプトのプログラミングに依存している

Jenkinsではじめるビルド職人入門 | Gihyo Digital PublishingをiPod touchに入れたらとても読みやすかった。
考えたことをラフなメモ書き。

【元ネタ】
Jenkinsではじめるビルド職人入門 | Gihyo Digital Publishing

Antを見直す:プログラマの思索

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ツールとビルドスクリプトの関係はもっと考えてみる。

【追記】
ビルドスクリプトの言語はシステムを実装する言語に依存しない例もあるという意見もありました。
上記はあくまでも一意見としてお読みください。

Twitter / beakmark: ところで、Cならmake JavaならMaven/ant Rubyならrake みたいな記載があってちと誤解を招きそうな気が。うちはC++メインだけどrakeをビルド言語として使ってる。

| | コメント (0)

Scrumの公開資料

Scrumの公開資料を@ryuzeeさんがまとめてくれていたのでメモ。

【元ネタ】
Scrumに関する無料の日本語資料のまとめ | Ryuzee.com

Twitter / akipii: これはありがたい。アジャイル開発の説明にも使える。Scrumに関する無料の日本語資料のまとめ http://www.ryuzee.com/contents/blog/ … @ryuzeeさんから

最近、日本でもアジャイル開発が大手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 / ryuzee: 待っててください! RT @akipii: 日本人が書いたScrumの辞書みたいな本が早く出版されて欲しい。Scrumの概念を引用する時はこの本を参考にして、みたいにしたい。間違った理解でScrumの概念を説明されるとコミュニティの人も困るだろう。

Twitter / akipii: XPやリーンソフトウェア開発は@hiranabeさんや長瀬さん達が数多くの翻訳本を出版してくれているので、文献を参考にすれば用語を理解しやすい。Scrumも同様に日本人が翻訳するなり著作するなりして、アジャイル開発の普及の弾みにして欲しい。やっぱり書籍は重要!

Twitter / hiranabe: @akipii スクラムの日本語書き下ろしの本が、来年ぞくぞくと出るらしいよ!

Twitter / akipii:@ryuzee @hiranabe Scrumに出てくる独特な用語、(プロダクト)バックログ、スプリント、スクラムオブスクラム、チームリード、Velocityなどを1冊の本で解説して欲しいのです。日本の大手SIがアジャイルに注目した今、Scrum解説本は重要度を増してます。

Twitter / akipii:@ryuzee @hiranabe 日本の大手SIがアジャイル開発を導入しようとする今、日本のアジャイルコミュニティからScrum解説本やアジャイルの実践ノウハウ本をもっと多く出すべきと思います。間違った理解によるアジャイル開発の失敗例がCMMIのようにたくさん出てきそう

翻訳では「アジャイルな見積りと計画づくり」「アジャイルサムライ」という優れた本があるのは知っている。
でも、Scrumやアジャイルも本来は日本発祥なのだから、日本人が書いた実践ノウハウ本が出版されて欲しいと思う。
日本でもScrumのコミュニティは活発に活動されているし、認定スクラムマスターも100人以上超えていると聞くと、日本人が書いたScrum解説本を欲しがるマーケット状況は整ってきていると思う。

@hiranabeさんや@ryuzeeさんがそんなScrum解説本を出版されるのを期待しています。

| | コメント (0)

2012/06/08

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart16 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。
励みになります。

【元ネタ】
Twitter / knaka:読了。主として Redmine と TestLink の組み合わせを中心とした、ソフトウェア開発プロセスのノウハウ本。 ∥ 小川明彦「Redmine によるタスクマネジメント実践技法 - チケット駆動開発+テスト工程管理のAtoZ」 http://www.amazon.co.jp/gp/product/479 …

Twitter / knaka: (承前)出版から時間が経過したので、対象としているバージョンが少々古いものの、そんなことはどうでも良いほど力強く、普遍性を持ったチケット駆動によるアジャイル型開発の一スタイルを提案する一冊。後書きにもあるように、モデル化やあるべき論ではなく、現場叩き上げのツールと方法論。 \

Twitter / knaka: (承前)イテレーションに含めるチケットの粒度や、安定版と開発版を同時メンテする際のブランチの切り方、関連プロジェクトどうしの同期方法など、いちいち説得力があり、その手法への賛否はともかく、一読の価値はあると思います。 \

Twitter / knaka: (承前)ただし、Redmine 自体の使い方については扱いが薄めなので、インストールとセットアップは済ませて、触りつつ読んだ方が良いかも知れません。右記、SQlite3 で入れてみました。 ∥ Mac OS X 上で開発インフラを構築 http://www.ayutaya.com/sys/os-x/devin … \

Twitter / knaka: (承前)ところで、学生症候群についてはサブタスク化によってチケットを小さくする方向で対策できそうですが、パーキンソンの法則対策はどうしましょうね? 朝会で都度訊いて、短縮するしかないかしら?

Twitter / puppymugi: TiDD初心者が陥りやすい罠~バージョンをCloseしないRedmineはVelocityが分からない http://bit.ly/mdvBf0 Redmineのこと調べるといっつもここ出てくる。そして勉強になる! ?#puppymemo?

既にRedmineもVer2.0.2、TestLinkもVer1.9.3になっていて、出版時のバージョンはかなり古いです。
ですが、ツールを使ってアジャイルに開発する手法について解説しているので、バージョンが古くてもそのエッセンスを読み取ってくれるだろうと思っています。

僕はチケット駆動開発を運用してみて、アジャイル開発の利点と運用時に失敗しやすい点を理解できた経験をしましたが、それは一事例に過ぎません。
XPやScrumは随分前から一部では既に運用されていて、その長所や運用時のアンチパターンもアジャイルコミュニティでは既に知られていました。
同様に、PMBOK、ITIL、CMMIなどもマネージャ層ならば、その良さや運用の難しさを既に知っている人も多いでしょう。
また、テスト管理手法や構成管理パターンもその界隈では既に知っている人も多いでしょう。

「チケット駆動開発」という概念が日本でこれほど普及した今、この本に書かれている内容は既に当たり前で、もっと先進的な使い方を行なっているチームや会社もあるかもしれません。

ですが、それらのノウハウをチケット駆動開発の上でアジャイルに開発する手法のコンテキストでまとめた点がこの本の良さだと思います。

そして、チケット駆動開発の経験から、アジャイル開発がソフトウェア開発の特徴に一番うまく適応しているという感触を持っています。
その感触をもっと理論的に他人に説明できるように、今後もまとめていきたいと思っています。

| | コメント (0)

2012/06/07

高速道路で走る車の速度はエンジンに依存する~ツールが良くてもプロセスの成熟度はチーム次第

@hiranabeさんや@ryuzeeさんのTwitterを見かけて、ツール・プロセス・チームの間で別の観点の関連があるような気がした。
ラフなメモ書き。

【元ネタ】
Twitter / hiranabe: Yes! RT @_dot: アジャイル開発だからパフォーマンスがあがるということはなくて、どのくらいのパフォーマンスが出せるかはあくまでチームの力に依存する。アジャイル開発はチームの力をスポイルしないというところがメリット。

Twitter / ryuzee: 高速道路が簡単に手に入るから乗ればいいけど、そこで何キロで走るかは、積んでるエンジンに依存するみたいな。(開発プロセスとツールとチームの話)

Twitter / akipii: 高速道路と能力の比較のメタファの意味がわかった。 [書評]アジャイルソフトウェアエンジニアリング http://www.ryuzee.com/contents/blog/ … @ryuzeeさんから

[書評]アジャイルソフトウェアエンジニアリング | Ryuzee.com

2006年以降のソフトウェア開発で感じることは、開発プロセスやチームをサポートする強力なツールが揃ってきたこと。
RedmineやTrac、GitやMercurial、Jenkinsなどのツールをうまく使いこなせば、以前はできなかったこと、以前は手作業が多くて労力がかかりすぎたことが随分解決できる。
高速道路が普及したことで遠方へ気楽に行けるようになった状況に似ている。

でも、強力なツールを使いこなしたからと言って、それでソフトウェア開発の諸問題が全て解決するわけではない。
チームで開発する場合、開発プロセスとツールをセットで運用することが大事になってくる。
その時、そのバランスが悪ければ、チームのパフォーマンスにせっかくのツールの良さが反映されない。
ツールを使うこと自身が目的になってしまって、本来のソフトウェア開発の成果物につながらない危険がある。

それは、高速道路が準備されたからと言っても、目的地に着くには、高速道路で走る車の性能、車のエンジンに依存しているのと同じ。

アジャイル開発の良さの一つは、チームやメンバーの力を引き出すことにフォーカスしていること。
特に平鍋さんが提唱されたプロジェクトファシリテーションは、ソフトウェア開発チームのチームビルディングを重視する点がとても優れていると思う。
とても面白い時代になってきたなと思う。

| | コメント (0)

2012/06/02

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り

エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。
@sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。
ラフなメモ書き。

【元ネタ】
ドメイン駆動設計: プログラマの思索

ドメイン駆動設計よりもパターン本が好き: プログラマの思索

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索

DOAとOOAの違い: プログラマの思索

Agile開発に足りないもの~モデリング技術: プログラマの思索

ドメイン駆動設計の本の違和感は二つある。
一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。
もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。

前者は、「ドメイン駆動設計」というタイトル通り「ドメイン分析」の内容ではない。
第1・2部では、アナリシスパターンに似たパターンを解説して、第3部ではモデルの揺さぶり、第4部はソフトウェアプロダクトラインに似たチームによるモデリングと戦略などを解説している。
つまり、解説の対象は業務分析ではなく、オブジェクト指向設計が対象になっている。

普通は、分析と設計は本質的に違う。
特に業務分析では、顧客が自分の業務で抱える問題点に対して、何らかのソリューションを提供するために、現実の業務を分析した後、あるべき業務の姿を定義して、業務システムのモデルを作る。
これが分析モデルであり、普通は、AsIsモデルを作った後に、実現可能性(フィージビリティ)やコスト、納期、顧客の要求などを加味して、ToBeモデル(分析モデル)を確定する。
その後、分析モデルは詳細化されて設計モデルとなり、実装工程に入っていく。

IPAが定義したITSSスキルモデルでは、分析工程はITストラテジスト、設計工程はITアーキテクトが担当するわけで、分析と設計は作業内容もロールも異なる。
この手法は典型的なWF型開発の分析・設計技法だ。
だから、外部設計・内部設計という言葉で作業や工程を使い分ける。

そもそも「ドメイン」という概念は分析すべきものであるのが普通だ。
実際の用語としても「ドメイン設計」よりも「ドメイン分析」の言葉のほうを多用するからだ。

だが、ドメイン駆動設計では、設計モデルを開発者がドメインエキスパート(業務の専門家)と一緒に何度も洗練させていくと、分析モデルになっていくと言う。
第3部の191ページに「深いモデル」「浅いモデル」という言葉が出てくる。
Agile開発に足りないもの~モデリング技術: プログラマの思索で@sugimoto_keiさんは、浅いモデルはビジネスモデル、深いモデルは帳簿モデルと呼んで区別されていたが、上記の考え方に従えば、深いモデルは分析モデル、浅いモデルは設計モデルに相当する。
つまり、開発者がシステムを実装対象として捉える場合は設計モデルという浅いモデルであり、顧客やアーキテクトがシステムを抽象化した本質的なモデルとして捉える場合は分析モデルに相当するわけだ。

そして、設計モデルから分析モデルへモデルが変化するタイミングは、第8章の「ブレイクスルー」と呼ばれる。
つまり、開発者が設計モデルを作っている最中はまだ本質的な概念を見いだせていないが、そこから本質的な概念を見出してモデルをより汎用的・抽象的な分析モデルに変換できた時を指すわけだ。

実際、第3部では、設計モデルから分析モデルへ変換できた例として、貨物輸送システムと利息計算サービスの2つの例が出てくる。
貨物輸送システムのモデルでは、荷物の物流が本質的な問題(ドメイン)ではなく、荷物の権利(つまり船荷証券という勘定科目)が本質的な概念に相当し、それがオブジェクトとしてモデルに自然に出てくる。
また、利息計算サービスでは、単なる利息の計算式が本質的な問題ではなく、発生主義会計(つまり、前払保険料、未払利息などの経過勘定科目)の概念がモデルに自然に出てきて、モデルがより抽象的に整理される。
すなわち、ドメインという本質的な概念がモデルのオブジェクトとして現れたタイミングが、設計モデルから分析モデルへ変わったブレークスルーというわけだ。

後者としては、ドメイン駆動設計では分析と設計を一体化することに特徴があり、要件定義から設計に至る上流工程を全て一つの作業にまとめてしまうこと。
過去のオブジェクト指向設計では、業務分析した業務をユースケース図で洗い出し、そのユースケースから概念モデルを作り、実装に近い設計モデルへ詳細化してプログラムになっていくので、分析と設計を明確に分けていたように思う。
実際、概念モデルの粒度はとても荒くて設計モデルへ詳細化しなければ、実装できない。

オブジェクト指向設計の最大の利点は、要件定義から分析、設計、実装までオブジェクト指向の観点で一気通貫で作れる点にあると言われてきた。
しかし、たとえオブジェクト指向設計であっても、実際のソフトウェア開発では、分析モデル、そして実際のプログラムはどんどん乖離していく。
分析モデルをいくら頑張って作っても、実際に作ってみると、システムとして実現するには仕様そのものに矛盾がある場合は多く、開発工程で妥協して作る時が多い。
そしてリリース時には、当初の分析モデルとは微妙に違ったシステムとして完成して、実際の運用に入っていく。
つまり、分析モデルから実際に運用されいているプログラムまでのトレーサビリティを担保するのは実際はとても難しい。
作ってみて初めて顧客が想像していた仕様とプログラムが異なるのはよくあることだ。

だが、ドメイン駆動設計では分析モデルと設計モデルは同じ工程で作るべきものであり、一体化しているので、プログラムにとても近いから、モデルとプログラムにさほどの差は出てこない想定になっているのが利点の一つだろう。
つまり、ドメイン駆動設計は、本来のオブジェクト指向設計の先祖返りとも言える。

そして、ドメイン駆動設計がやりやすいシステム開発の対象は、プロダクトアウト指向よりもマーケットイン指向の製品開発やサービス開発だろう。
つまり、実装前にきちんとした仕様が確定しているプロダクトアウト指向の開発ではなく、マーケットにいち早くサービスや製品を投入しながら、売れ行きに応じて機能を変えていくマーケットイン指向の開発の方が向いている。
実際、マーケットイン指向の開発では、分析モデルは実装前に確定しているわけではないから、プログラミングしながら分析モデルもブラッシュアップせざるを得ない。
例えば、変化の激しいWebサービスやスマートフォンのようなVerUpの激しい製品の開発にドメイン駆動設計が向いていると言えるのかもしれない。
だから、設計を重視するアジャイル開発者がドメイン駆動設計に注目しているのだろう。

でも、僕の感想としては、ドメイン駆動設計をいきなり勉強するよりも、オブジェクト指向設計(OOA)やDOAを習得した後に手を出す方が理解しやすいと思う。
実際、ドメイン駆動設計に出てくるパターンは、アナリシスパターン実践UMLに出てくるパターンに似ているからだ。
例えば、勘定パターンはアナリシスパターンにあるし、腐敗防止層は実践UMLのファサードパターン(純粋架空物:Pure Fabrication, 間接化:Indirection)そのものだ。

また、設計モデルから分析モデルへ抽象化していく場合、業務知識がなければ変換できないだろう。
僕が見聞きした限り、DOAの設計者は会計システムや生産管理に詳しい人が多いが、彼らは実際の業務経験が豊富なため、分析モデルを設計モデルに詳細化できるし、設計モデルから分析モデルへ抽象化していくこともできる。
特に日本では、業務システム開発とDOAを組み合わせた歴史があるので、業務分析と設計をミックスした手法がたくさんある。
例えば、日本のDOAには、渡辺さんが提唱するDOA、T字型ER、TH法など各種の流派がたくさんある。

大半のDOAの設計者は業務経験が深いがゆえに、分析モデルと設計モデルの違いやモデリングの技法についてたくさんのノウハウは持っているので、ドメイン駆動設計に書かれているモデルの意味は理解しやすいだろうと思う。

とは言え、ドメイン駆動設計に書かれている分析モデルの例はとても実用的で面白いし、理解できれば実際の仕事にも役立つだろうと思う。

【追記1】
個人的には、第3部が一番面白いと思う。
第1~2部はアナリシスパターン実践UMLなどに出てくるパターンの焼き直しに過ぎない。
第3部は、設計モデルから分析モデルへ質的に変換する事例が出てくるので、この本の一番の見所だと思う。
第4部は、ソフトウェアプロダクトラインに似たモデリングプロセスの解説のような感想を持った。
「蒸留」という概念は、SPLで言うコア資産の抽出プロセスに似ている。
チームによるモデリング戦略は、アーキテクチャやモデルは組織構造に依存しているというConwayの法則の焼き直しのように思える。

【追記2】
関西でドメイン駆動設計のセミナーが6月にあります。
アジャイル開発で設計や業務分析に悩んでいる人、オブジェクト指向設計をもっと勉強したい人にはお勧めです。

第47回 SEA関西プロセス分科会-SEA関西

6月23日 第47回 SEA関西プロセス分科会(大阪府)

日々精進 - スパークスシステムズ ジャパン代表のBlog:セミナー情報2点 - livedoor Blog(ブログ)

| | コメント (0)

2012/06/01

形式手法の使い道

形式手法はブレイクするはずとずっと言われながら、なかなか普及しない。
その理由は形式手法の使い道が限られているからだと思っている。
考えたことをメモ書き。

形式手法は各種の手法があるが、モデル検査が一番わかりやすい。
モデル検査のやり方は、実際のプログラムから状態遷移図というモデルをリバースして、本来の仕様と状態遷移図を比較検討して、ありえない状態遷移があればそれはバグになることを説明するのに使う事例が多い。

モデル検査の分かりやすい例としては、以前出題されたソフトウェア開発技術者試験の午後問題があげられる。
下記の問題2に相当する。

平成20年度春期試験ソフトウェア開発技術者試験(SW)午後Ⅰ

問題では、ある関数のフローチャートから状態遷移図を生成する。
その状態遷移図に対して、不具合を発見するために、不具合が存在しない条件式つまり本来の仕様を定義した後、モデル検査ツールを使って状態遷移図を網羅的にチェックして、条件式を満足するかどうか判定する。
当然、条件式を満たさない場合、バグになる。
そのバグは、モデル検査ツールが状態遷移図の経路に相当するので、不具合を再現する事が可能になるという流れ。

上記の問題にも書かれているが、モデル検査の特徴はいくつかある。
一つは、従来のテストのように大量のテストデータを準備する必要はない。
状態遷移図さえモデル化できれば、モデル検査ツールを使って、すべての経路計算をすればいい。
ソフトウェアテストが難しい理由の一つは、多種多様なテストデータの作り込みに手間がかかることだから。

もう一つは、再現しづらいバグや複雑な仕様の組みわせで発生するバグを発見しやすいこと。
この種類のバグは、探索的テストで発見する時が多いが、限られた工数で探索的テストを実施して、非常に稀だが重大なバグを発見できるとは限らない。
むしろ、モデル検査ツールを使って、総当たりで自動計算した方が効率が良い場合もある。

だが、モデル検査ツールは既存のプログラムから状態遷移図を自動生成してくれるとは限らない。
そもそもシステムの状態遷移図をきちんと作るのはかなりの技術力を要するし、労力もかかる。
また作成した状態遷移図の精度が高くなければ、当初の目的である再現しづらいバグを見つけることができない。
もちろん、状態の数が多いほど計算は爆発するので、いくらコンピュータの性能が良くなったと言っても、すべての状態の経路を計算し尽くすことができない場合もある。

このように、形式手法の1種類であるモデル検査の使い道は、ソフトウェアテストの中でも探索的テストを補完するような使い道しかない。
信頼性が品質要件で非常に重要なプロジェクト、例えば人工衛星や社会的インフラの場合では、モデル検査による再現しづらい不具合探しも重要だろう。
だが、ソフトウェアテストの本質的な問題に焦点を当てているとはいえないと思う。

形式手法はもちろんこのような使い道だけではない。
形式手法の本来の使い方は、プログラミングに入る前の設計工程で、SEが作った詳細な設計書に書かれた仕様を形式手法でモデル化して、矛盾や不整合を洗い出すことにある。
IPAが組込ソフトウェア開発の品質改善で形式手法を適用できないか、長年研究している理由はそこにある。
しかし、そのやり方はまだうまくいっているとは言えないと思う。

また、この発想はウォーターフォール型開発特有の考え方だ。
何故なら、前工程の手戻り作業をできるだけなくすために、プログラミングせずに設計工程の品質をあげようとするやり方だから。
この発想は、ソフトウェア開発を工程単位に分断せず、設計もプログラミングもテストも一体化して開発を進めるアジャイル開発とは本質的に異なる。

とはいえ、形式手法とアジャイル開発を組み合わせて実践されている細谷さんの事例もある。
色々探ってみる。

| | コメント (0)

« 2012年5月 | トップページ | 2012年7月 »