« 2013年3月 | トップページ | 2013年5月 »

2013年4月

2013/04/29

マージ処理はコードを理解すべきである~チケット駆動開発の発展形

InfoQにマージツールの記事があったのでメモ。

【元ネタ】
関数を理解するマージツール

これは凄い。ソースコードを理解するマージツール「Semantic Merge」 | ソフトアンテナブログ

彼らの動機としては「優れたブランチは優れたマージから」という信念がある。
つまり、「タスクごとのブランチ」の考え方(トピックブランチ、フィーチャブランチなど)を強く支持しているが、結果的にブランチが乱発されてしまう弱点があり、もっと良いマージ機構が欲しかった、と。

だから、「マージ処理はコードを理解すべきである」という方針で、ツール自身がマージをサポートしてくれればいい、と。
Eclipseがリファクタリングをサポートしているように、ツールでもっと簡単にマージをサポートしたいのだろう。

彼らは、タスクごとにブランチ(Branch per Task)というブランチパターンを支持している。
つまり「イシュートラッカ(ITS)上のタスク単位で作業用のブランチを作る」アイデア。
イシュートラッカ(ITS)のエントリ(チケット)はひとつの変更、ひとつの新機能(バグ、機能、課題など)ごとに作られるから、それぞれにブランチが作られることになる。

この考え方は、ITSのチケット単位にタスクブランチ(トピックブランチ)を作ることと同義だ。
「チケット無しにフォークを許さない、マージを許さない」発想につながる。

この手法の利点は、真の並行作業になることから、trunkの品質を維持でき、新機能開発のためのコードフリーズがなくなるため、もっと素早いアジャイルな開発が実現可能になることだ。

ブランチとマージは表裏一体にある。
マージ機構がもっと強力になれば、ブランチがたくさんあっても構わない。

いつでも最新の機能、障害修正を取り込むことができる自信があれば、いろんな発想を実験したり、何度でもやり直しを行うこともできる。
つまり、真の意味での反復型開発をサポートするわけだ。

Gitが提供した強力なマージ機能とブランチ管理機能によって、XPが提唱したソースの共同所有というプラクティスを強力にサポートして、アジャイル開発の敷居をどんどん下げている。
開発インフラという技術がようやく時代に追いついてきたと実感している。

| | コメント (0)

実践反復型ソフトウェア開発の読書会ログ

実践 反復型ソフトウェア開発の読書会ログを見つけたのでメモ。

【元ネタ】
makopi23のブログ 「実践反復型ソフトウェア開発読書会 -反復1-」に参加しました

makopi23のブログ 「実践反復型ソフトウェア開発読書会 -反復2-」に参加しました

makopi23のブログ 「ビルド中心の開発 - タイムボックスと継続的インテグレーション -」に参加しました

実践 反復型ソフトウェア開発」は今の僕にとってバイブルの本。
構成管理、ビルド管理、障害管理の基本的な概念が一通り説明されていて、どのSCMやCIツール、ITSにも適用できる。
やっぱり用語があると、今までうやむやに運用していたやり方が整理されるのでありがたい。

2013年現在のソフトウェアの技術革新の場所はGitとAWSにあると思っているので、「実践 反復型ソフトウェア開発」のような本で更に追いかけてみる。

| | コメント (0)

テスト駆動開発は設計技法である~組み込みアジャイルコーチ James Grenning さんインタビュー

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」の著者のインタビューが公開されていたのでメモ。
幾つかの内容を抜粋しながら、ラフなメモ書き。

【元ネタ】
組み込みアジャイルコーチ James Grenning さんインタビュー ( 前編 )

組み込みアジャイルコーチ James Grenning さんインタビュー ( 後編 )

[ 技術書籍紹介 ] Test Driven Development for Embedded C

O'Reilly Japan - テスト駆動開発による組み込みプログラミング

なぜ Agile Japan 2013 の基調講演に James Grenning さんを呼びたかったか:An Agile Way:ITmedia オルタナティブ・ブログ

「テスト駆動開発における組み込みプログラミング」 - Yasuo's Notebook

【1】プロセスありきではなく、優秀な開発者ありきが大前提であり、優秀な開発者にプロセスを任せれば良い、という考え方がアジャイル開発の基本であると指摘している。
プロセスありきで、開発者を交換可能にするやり方は、プロセス標準化にもつながる。
いくら頑張って標準化して、属人化を排除しても、技術の進歩が早ければ、標準化された技術は陳腐化されてしまいゴミになる弱点がある。

(引用開始)
驚いたことの一つが、彼らの考え方はその当時主流だった考え方と違っていたことです。90年代に一般的だったのは「正しい開発プロセスがあれば、開発者はもっと上手くやるだろう」というものでした。しかし、アジャイルソフトウェア開発宣言を共に検討したメンバーの意見は「スキルのある優れた開発者がいれば、彼ら自身が学習して開発プロセスを決めれば良い」です。
それとは対象的に、多くの会社ではソフトウェア開発の管理や開発プロセスの改善の話をするとき、会社がやって欲しい通りに仕事をさせようとします。IT産業のやっていることは「うちには取り替え可能なプログラミングユニットの開発者がいる。彼らが開発プロセスに従えば、ソフトウェアの問題はなくなるだろう。」というもの。しかし、アジャイルソフトウェア開発宣言で我々が語っているのは人の重要性です。これは驚くべきものでした。
(引用終了)

【2】TDDのモチベーションは、バグの防止。プログラミングしながらバグを未然に防ぐ。

(引用開始)
私は、新しく TDD に興味を持った人に対してバグの防止を最重視していることを強調します。もし、TDD のアプローチに従うなら、実装中にバグが検出されるので、多くのバグを未然に防ぐことができます。全てではありませんが、多くは防げます。企業経営者に話をする時も、TDD がバグを防止する仕組み、そして debug later programming の問題について説明しています。もし、コードの欠陥によるリスクを取り除くができれば、開発はより良いものになるでしょう。
もう1つモチベーションがあります。手動テストが持続可能ではないということです [13]。テストを手動でやるなら、ちょっとした修正をやった時や新しい機能を追加する時に全ての機能を自分でテストする必要があります。こうなるとテストの工数が制御できなくなります。私の知っている限りでは、テスト工数を低く保つにはテストを自動化するしかありません。
他の影響として、適切に書かれたテストコードは実行可能なドキュメントになります。これは開発の後に得られる2次作用のようなものです。
(引用終了)

【3】TDDは最初は単体テストの観点で小さく始める。
しかし、QAのプロセスでは、反復的なアプローチを考える。
QA 担当者が各イテレーションにおいて開発者が作った成果物に対してテストを書くやり方。
開発者がイテレーションの仕事を 1~2 週間で完了し、QA 担当者がテストし、成果物の受け入れを行う。

QA 担当者がやるテストは、単体テストよりもレベルの高いテスト。
振る舞い駆動開発(Behavior Driven Development; BDD)、ストーリーテスティング、受け入れテスト駆動開発(Acceptance Test Driven Development; ATDD)、統合テストなどいくつかの呼び名がある。

「実行可能な仕様」を書くためのツールとして、FitNesse/CSlim 、Cucumber、robotframework などがあるらしい。

アジャイル開発でテスト駆動する時は、人を役割や境界で縛らない。
QA担当者の作業負荷が高ければ、開発者も自ら支援しに行く。
彼らの仕事をそのまま担当できなくても、手伝えることはある。

【4】モデリングやアーキテクチャ設計はTDD と密接な関係がある。
TDDは継続的な設計を促し、インターフェイス中心の考え方を徹底させる。

(引用開始)
SOLID 原則を紹介している第11章「SOLID, Flexible, and Testable Designs」の中でいくつか責務 [4] の分割に関する設計を行なっています。ここで重要な原則の一つが「関心事の分離 [5]」です。書籍では蛍光灯の点灯や消灯のスケジュールを管理をするソフトウェアを設計する中で、全体を異なる関心事の領域に分割し、システムを構築する上で必要なインタフェースを用意する場所を特定しています。例えば、ここには蛍光灯のスケジューリングに関するロジックがあって、ここはスタブに置き換えられるようにしよう、というように。そういうわけで、いつどの程度やるかを明記していないだけで、一定量のモデリングはやっているわけです。設計や実装の活動の最初にモデリングを通じて、自分がどこに向かっているのか検討することは良いことだと思います。
(引用終了)

(引用開始)
多くの人がTDDのコード中心な側面を見て、「TDDは設計しない手法だ」と誤解しますが、実際に我々がやっているのは継続的な設計です。オブジェクトのインタフェースを定義する時はいつも、そのインタフェースを実際に使うテストを書きます。それは設計の活動です。私の書籍の例をいくつか見れば分かると思いますが、テストケースの作成によって最初にインタフェースを作ります。なので、最初の方のテストケースがインタフェース設計を駆動するのです。そして、後の方のテストケースで設計の詳細を検討します。
そして、私はコードに翻訳可能で実行可能なレベルの詳細なUMLモデルは書きません。個人的には時間の無駄だと思っています。モデルの適切な詳細さは、オブジェクトの名前、責務、そしてモジュールのいくつか代表的な属性や操作くらいです。C/C++コードのシグニチャレベルの詳細さが適切だと考えている人もいるでしょうが、私自身はそれは詳細すぎると考えています。
(引用終了)

(引用開始)
以前、アーキテクチャ設計を行うプロジェクトに参加した時に事前に大量のモデリングを行いましたが、それは間違っていると気づきました。私は堅苦しくモデリングするより、小さいモデルを書く方が好きです。設計が実際に動くかどうかを確かめるためにモデルを書くことも良いでしょうが、その代わりに私はテストを書いて確かめるのが好きです。テストはオブジェクトがどのように動くかを明確に示してくれます。そしてインタフェースが使いやすいかも示してくれます。これは私が長年の経験の中で得た結論です。
(引用終了)

【5】TDDで難しいのはシステムテストの運用。
単体テストは開発中にできても、ユーザ視点の受入テストやシステムテストをイテレーションに全て埋め込んでテストするのは難しい場合がある。
システムテストは別イテレーションを別途設けて、反復的に品質を上げていく期間を用意したほうがいいだろうと思う。

また、システムテストでは、受入テストケースの品質が肝になる。
テストケースの内容が曖昧な仕様になっていないか、テストケースの網羅性が担保されているか、などの観点で吟味する。
すると、例外系やたくさんの条件分岐の機能もテストが必要になってくる。
著者は、テストケースを詳細化しながら、設計を汎用化していく方法を勧めている。

(引用開始)
このように要求仕様を受け取って、テストケースでソフトウェアの仕事を詳細に表現するのです。最初のテストケースでは仕様で求められていることのうち狭い範囲をパスします。そして、テストケースが増えるにつれて設計を汎用化していきます。例えば、最初に月曜日のテストケースを作成し、月曜日にだけ動くようにします。次に火曜日のテストケースを作成し、任意の曜日に対して動く様に設計を汎用化していきます。
そういうわけで、私は設計に注意を払うというより、コードを汎用化してくれるようなテストケースを選んでいきます。テストケースを選ぶことで設計を汎用化していく過程を見れば、多くの人はTDDの設計の側面を理解してもらえると思います。テストケースがひと通り終わった時に汎用的な設計が完了しています。
おそらく、あなたの質問は「要求仕様を受け取った。さて、これからどう段階的にテストを進めていくのか?」でしょう。例えば、2週間で5つのストーリーを完了させるとします。実際にはもっとストーリーはあり、まだ開発していない蛍光灯のスケジューリングはずっと先にあるとします。最初のイテレーションでこれらのテストを完了する計画を立てます。受け入れテストがないと次のイテレーションにリリースするのが困難になるので受け入れテストも用意するでしょう。そして、実験室に行って実際のハードウェアにつないでテストできるようになります。ここがゴールです。それぞれのイテレーションの中で作業を完了していきます。
(引用終了)

【6】著者の本「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」では、組み込み系特有のテスト技法についても書かれているらしい。

組み込み系でTDDが難しい理由の一つは、C言語の言語仕様でテストしなくてはいけないことだ。
モック(Test Double)やリフレクションをそのまま実装できないため、テクニカルな技法が必要になる。
RubyやJavaなら簡単に使えるのに、C言語ではそれらのライブラリを用意しなくてはならない。

また、TDDはオブジェクト指向と密接に絡むが、オブジェクト指向の最大の利点であるポルモルフィズムをC言語で実装する場合、テクニカルな技法が必要になってくる。
インスタンスを構造体で表現したり、テスト対象の関数をインスタンスごとにポリモルフィックに表現したい時に関数ポインタで動的に表現する手法があるだろう。

また、組込系では、ハードとソフトをセットにしてテストする所が難しい。
そして、更に継続的にビルドしていく環境も準備するのも難しい。
それらについても、色々なノウハウが書かれているらしい。

XPJUG関西でも細谷さんや西さんが、組み込み系のテスト駆動開発について、技法を色々試されていたのを思い出す。
関西では組み込み系の技術者が多いので、「テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」は必須の本になってくるのではないだろうか?

【追伸】
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」のまえがきは平鍋さんが書いている。
平鍋さんはその本の主張や本来の意図を的確に詳しく書いてくれているので、平鍋さんが書いたまえがきやあとがきを読むだけで、本を全て読んだ気になるようになるから不思議だ。
以下、Amazonのレビューを引用。

(引用開始)
「日本語版まえがき」より

本書は、C言語を使う組み込み開発の現場用に書かれた、テスト駆動開発の具体的な指南書である。そう、C言語で! テスト駆動開発はオブジェクト指向言語が前提となることが多かったのに、本書は組み込み開発現場でのC言語を前提としている。この手法をあなたの組み込み開発に取り込めないだろうか? きっと試す価値はあるはずだ。組み込み開発のソフトウェア開発現場では、なかなか障害が収束せず、出荷ぎりぎりになってデバッグに追われる日々を強いられる状況も多い。そして、みんなそんな状況から逃れたいと思っている。ジェームズは、その1つの答えになるのがテスト駆動開発だと信じて本書を書いた(私もそう考えている一人だ)。チームや個人が自らのソフトウェアの品質をよりよくしたい、と考えているなら、ぜひすぐにでも試してみてほしい。組み込み開発の現場で日々ソースコードと格闘している、まさに、あなたのための手法だ。

私は著者のジェームズ・W・グレニング氏と数年来交流している。昨年は彼の開催するテスト駆動開発のワークショップにも参加し、実際に手を動かしてC言語のコードを書いた。そこで気づいたのは、彼のとても真剣な組み込みソフトウェア開発に対する情熱だ。彼は、ワークショップが始まる前に、参加者の全員に一人ずつ自己紹介をしながら資料を手渡していた。そして、ワークショップがはじまると、静かに、しかし熱く、組み込み開発の現場の悲惨な現状を語った。彼も組み込み開発の現場を変えたいと考えている。そして、その鍵がテスト駆動開発にあると信じている。

よく誤解されるのだが、テスト駆動開発は「テスト手法」ではない。ユニットテストをうまく利用して、よりよい設計を導くための手法である。この手法で開発されたソースコードは、「テストしやすい設計」になると同時に、動くユニットテスト群が同時に開発される、という優れものだ。このユニットテスト群は回帰テストで利用されるとともに、将来の設計変更を安全に導く基礎になる。私が本書で特に気に入っているのは、ボブおじさんこと、ロバート・C・マーティンのソフトウェア設計原則である「SOLID原則」にも章を割いて解説している点だ。テスト駆動開発は、テストしやすい設計を導く設計手法であり、ソフトウェア設計原則と不可分なのである。本書を読むことで、テスト駆動開発だけでなく、よい設計とは何か、というより大きな問題を考えるきっかけにもなるだろう。

さあ、本書を手に、すぐに試してみてほしい。テスト駆動開発のよさに感染するだろう。そして同時に疑問を抱くだろう。どうやったら自分の現場に適用できるか、と。そしたら、チームの仲間と勉強会をはじめてみてほしい。開発の仲間を作ることが、ソフトウェア開発の現場をよくすることの第一歩だから。組み込み開発のやりがい、そして楽しさ、を取り戻そう。
(引用終了)

| | コメント (0)

2013/04/28

エバンジェリスト養成講座の感想

XP祭り関西2013の懇親会で、希望者に配布した「エバンジェリスト養成講座」をさらっと読んでみたらとても面白かった。
感想をラフなメモ書き。


エバンジェリストとは、自社の製品やサービスを顧客に分かりやすく説明する人。
MSやIBMに多い。
AWSの玉川憲さんもそういう人。

エバンジェリストとは - はてなキーワード

第1回『エバンジェリストに必要なもの、それは』(1/3):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

【1】体験や経験を語ることがプレゼンテーション。
経験が大切。
製品の良い点も悪い点も経験しておけば、講演者の話に説得力も出てくる。
聴衆からの質問にも回答しやすい。

【2】プレゼンは伝われば成功。
何を伝えるのか?
伝えることがゴール。
だから、伝える内容を決めるために、シナリオを共有しておくことが大切。
営業マンと営業しに行くなら、何を伝えたいのか、営業マンとシナリオを共有しておく。
システム提案に行くなら、顧客に何を伝えたいのか、SEとシナリオを共有しておく。

【3】モノよりも人(講演者)の方が記憶に残る時が多い。
「スティーブ・ジョブズが話していたアレ」とか。
プレゼンターの雰囲気、立ち振舞、話しぶりが印象に残りやすい。

その意味では、プレゼンは自己表現。
単なる製品説明ではなく、製品と一緒に自分を売り込んでいる。

だから身だしなみも重要。
格子型、斜線模様のシャツやネクタイは避けたほうが良いとのこと。
理由は、Webで写真がアップされた時、ぼやけてしまうから、とのこと。

それゆえに、プレゼンターは、経営者などの上層部向け、つまり、トップアプローチを重視した方が良い、とのこと。
プレゼンは営業ではない。
チャンスを広げたり、興味を持ってもらうことが目的だから。

【4】7種類のプレゼンスタイルがある。
(1)オーソドックス型。
文章を箇条書き。
資料の中身で話す。
但し、身振り手振りで説明したり、事前に資料を配布したりしておく。

(2)ビジー型。
図や表を入れた詳細な資料。
A0やA1などの紙に印刷して、指さしながら説明する。
CIO一人相手に、数字や分析を絡めながら話す時に都合がいい。

(3)フラッシュ型。
高橋メソッドと同義。
例えば、60秒で27枚のスライドを使う。
内容がとても多く、効果的。
短時間でたくさんのことが話せる利点がある。
エレベータートークにも使える。
LTでとても有効なスタイル。

プレゼンの勉強になるので、プレゼンの初心者にとてもお勧めらしい。

(4)デモ型
(5)機能比較型
(6)完全比較型
文字通り。

(7)スティーブ・ジョブズ型
スライドに説明がなく、画像やイメージで伝える。
アドリブが全てなので、スライドやシナリオを丸暗記して復唱できるのが前提。

プレゼンテーションZenでも提唱されている手法。
最近の勉強会の発表では、このプレゼンスタイルが主流。
だから、とても垢抜けており、聴きやすいし、印象に残りやすい。

【5】プレゼンのシナリオの3つの視点
自分という製品担当者の視点。
神様という第3者の視点。
顧客という「皆さん」の視点。

プレゼンターは、顧客の視点を大切にしよう。
顧客視点のプレゼンが最も伝わりやすい。
更に自分が体験した内容が話しやすい。

【6】プレゼンはデートに似ている。
プロセスが評価される。

デートでは、女性は男性がエスコートしてくれることを期待している。
プレゼンも、聞く人は、どんな内容を話してくれるのか、期待している。

テーマの選択、時間の厳守、シナリオの決定、アドリブ、サプライズ。
いずれもデートの必要要素に似ている。

プレゼンはドラマ形式が良い。
よくあるパターンは、ホラーストーリー中心。
つまり、問題や課題を提示して、それをどのように解決していくのか、を説明するパターン。
システム提案でよく使われるITソリューションのパターンに近い。

もう一つは、サクセスストーリー中心。
他社の成功事例を中心に話す。
事例なので説得力があるし、経営者は他社の動向を知りたがっている。

【7】プレゼンの最初でアイスブレイクは重要。
いわゆる「つかみ」。
最初の5分で聴衆に興味を持ってもらうのが目的。

アイスブレイクの元ネタを数種類持っておくと良いかもしれない。

【8】プレゼンの話し方には幾つかの注意点がある。
言葉は言い切る。
話を切ったり、話を元に戻さない。
言葉の空白を作らない。

1分間に数字を3回入れると説得力が増す。

右肩上がりのグラフにする。
経営者にとって、売上が右肩下がりのグラフは見たくもない。

覚えて欲しい言葉は連呼する。
キーワードを刷り込ませる。

ペースメーカーを見つける。
聴衆から頷いてくれる人を見つけて、その人を見ながら話すと調子が上がる。

「皆さんならどう思いますか?」という文句を入れる。
QAを聴衆に促す。
聴衆を引き込む。考えさせる。

【まとめ感想】
LTで高橋メソッドのプレゼンをしながら、プレゼンスキルを上げていくやり方があるかもしれない。
プレゼン資料を作るだけでなく、話し方、シナリオにも注意する所は取り入れたいと思う。

| | コメント (0)

XP祭り関西2013の感想

昨日、XP祭り関西2013が開催され、盛況で終わった。
参加した感想をメモ書き。

【元ネタ】
XP祭り関西2013 - XPJUG関西wiki

XP祭り関西2013~プラクティス×プラクティス(2013年4月27日) - Togetter

XP祭り関西2013まとめ - Togetter

【1】僕は2年ぶりのXP祭り関西だったので、とても懐かしい感触だった。
2年前と比べて、客層が変わったなあという印象を持った。
@sakaba37さんも同様の感想を持っていたらしい。

Twitter / akipii: 今日のXP祭り関西は客層がアーリーアダプターではなく、アジャイルや技術に興味を持つマジョリティ層が多かったのが興味深かった。平鍋さんが最初に提唱し、草の根コミュニティが育てたアジャイルが、日本で確実に知名度を上げていることを実感した。#xpjugkansai

今回の祭りのテーマは、アジャイルプラクティス。
チケット駆動開発だけでなく、京都アジャイル勉強会やアジャイルサムライ道場やデブラブ関西などのコミュニティの人達の講演もあり、賑やかだった。

LTで興味を引いたのは、アジャイルラジオの発起人の方の話。
35歳になって初めて技術系の勉強会に出てみたら、楽しかったが、あちこちの勉強会で、アジャイルはいいよ、とか、アジャイルの話題が必ず出てくる。
そこから、アジャイルって何だろう、と興味を持って、アジャイルを勉強し始めた、とのこと。

なぜか、以前、日経コンピュータで読んだ記事を思い出した。

Twitter / akipii:1月24日号日経コンピュータのマネックス証券CTOの記事が面白い。「OSS、アジャイル開発といった新技術を取り入れることが、結果的に優秀な技術者が集まり、プロジェクトの成功が高まる」

アジャイルやオープンソースを取り入れることが会社の技術力を高めることにもつながる、という経営者の意識と、何故か似通っているのが面白い。

【2】村田さんが作成したアジャイル双六も好評だった。
和室の会場で僕も体験してみて、とても良く考えられているなあ、と思った。

Twitter / ryo1116: アジャイル双六ゲット? ...

C#からRubyまでのいずれかの札を選択後、1~6までのカードをめくって、人生ゲームのように進めていく。
途中でアジャイルとウォーターフォールに分かれる分岐点がある。
ウォーターフォールの道では、単体テストや結合テストや受入テストで、手戻りが原因で元の工程に戻る時が多い。
アジャイルの道では、イテレーションごとに無理やり一時停止させられ、作業増加が原因で1回休みが多い。
僕はアジャイルの道を選んで進んでみて、結果的にウォーターフォールの人よりも早くゴールできた。

懇親会で村田さんに聞いてみた所、アジャイル双六は10分ほどで簡単にできるように、色々改善されたらしい。
また、村田さんが今まで関わってきたソフト不ウェア開発の経験を踏まえて、アジャイルとウォーターフォールでありがちな現象をアジャイル双六のマス目に入れ込んだ、とのこと。
アジャイルの道では、チケット駆動開発やチケット管理のこともアジャイル双六のマス目に入っていたので、ちょっぴり嬉しかった。

【3】2年前に比べると、関西でも東京と同じくらいあちこちで勉強会が開かれていて、活発に活動している人が多い。
大阪だけでなく京都や神戸でも毎週のように勉強会があり、横の連携もある。
技術者同士の交流が盛んになることは、お互いに切磋琢磨しながら技術を底上げしていくきっかけになるから、今後、関西でも大きな動きが出てくるかもしれない。

| | コメント (0)

2013/04/20

部品表と工程表と製造指示の関係


渡辺幸三さんの記事を読んだ。
僕は製造業の生産管理システムの開発経験はないけれども、小売業とか他の業界の基幹系業務システムに携わった経験がある人ならば、下記の記事の奥深さにしびれると思う。
ラフなメモ書き。
間違っていたら後で直す。

【元ネタ1】
製造指示の設計と実装 (1)日程化: 設計者の発言

製造指示の設計と実装 (2)開始と完了: 設計者の発言

製造指示の設計と実装 (3)外作: 設計者の発言

BOMプロセッサの開発完了: 設計者の発言

実際の製造指示のプロセスで、TOCの概念を導入する点はとても興味深い。
ボトルネックとなるプロセスの稼働率が全体の稼働率を決めるわけだから、むやみに全工程の稼働率を上げても無駄に在庫を増やすだけ。
製造指示書は仕掛かんばんを連想させる。それはリーンSW開発にもつながるし、チケット駆動開発にもそのアイデアを投入できるだろう。

作業区はワークセンターという意味。
生産管理・原価管理システムのためのデータモデリング」(P.113)の作業区の解説では、工程作業を実行するための設備(工作機械)や場所という意味だが、「生産管理・原価管理システムのためのデータモデリング」(P.117)では、作業区は生産能力という特徴も持つ。
だから、製造前に作業区を割り当て、作業区に必要なリソース(時間、材料、人員、製造指示)を手渡すわけだ。

また、製造指示書は材料や仕掛品に添えることでかんばんの役目も果たす。
かんばんによって、現物と情報が必ず一致して流れるわけだ。
そして、製造指示書は材料出庫指示書にもなるから原価管理や会計データにもつながる。
つまり、入出庫という受払によって、原材料購入による仕入や仕掛品、製品などの搬出による売上などという仕訳が出てくるわけだ。

外作という外部企業に委託製造する時のDB設計と業務の解説も興味深い。
製造指示の設計と実装 (3)外作: 設計者の発言にも書いてあるように、「無償支給による製造委託」「材料の有償支給にもとづく製造委託」では、業務内容が大きく異る。
有償支給では、外部企業にモノを渡して(売上)、作ってもらったモノを受け取る(仕入)ので、それぞれの時点で仕訳が発生するからだ。

生産管理・原価管理システムのためのデータモデリング」(P.110)で、「有償支給の場合、外注業者が支給された資材をムダなく使おうとしてくれる利点がありますが、事務手続きは複雑になる欠点があります」という文章があるが、その意味は上記の記事の解説であるわけだ。
また、「生産管理・原価管理システムのためのデータモデリング」(P.113)に出てくる「外注加工仕入」という債務は、まさに上記の記事の有償支給後に完成品を外部企業から仕入れる業務の時に発生する負債科目なわけだ。

【2】渡辺さん著の「生産管理・原価管理システムのためのデータモデリング」が優れている点は、単なるデータモデリングの解説だけではなく、業務の背後にある仕訳も絡めて、モノや情報(業務)とお金(会計・仕訳)の流れを統一的に解説してくれていることだと思う。

梅田弘之さん著「グラス片手にデータベース設計~販売管理システム編」に出てくるデータのターンアラウンド(ある業務で入力されたデータは他業務では重複して入力しない)にもつながる。
データのターンアラウンドという観点では、業務という水平のデータの流れと、会計という垂直の流れがある。
例えば、受注→出荷→売上→請求→入金という業務の流れの背後では、売上処理で「売掛金//売上」、入金処理で「当座預金//売掛金」という仕訳が発生している。
この業務ではどんな仕訳が発生しているのか、を意識しながら業務フローを読み解くと分かりやすくなると思う。

この辺りはもう一度まとめてみる。

| | コメント (0)

社会統計学は面白い

社会統計学のサイトの内容がとても面白かったのでメモ。
ラフなメモ書き。

【元ネタ】
社会実情データ図録 Honkawa Data Tribune

社会の動向を知りたい時、経済活動や社会活動の数値を計測して比較検証するやり方はよく使われる。
その場合、棒グラフや円グラフのように、時系列の推移や全体における割合などで比較したりする。
このサイトでは、QC活動で出てくる相関図を頻繁に使って、2つの変数を元にグラフ化して変数間の関連度合いを見る。

現代は各省庁やIPAなどの公的団体などのHPから数値データを収集できるので、こういう比較検証がやりやすくなっていると思う。

【1】図録▽経済成長率の推移(日本)
図録▽経済成長率の推移(日本の戦前及び戦後直後)

日本の経済成長率を見ると、高度経済成長期から一貫して下がってきているのが分かる。
90年以降、マイナス成長率が結構ある点がとても目を引く。
国全体が貧乏になったわけだから、平均的な日本人の所得も減っているわけだ。
90年代以降に働き始めた人達にとっては、デフレという経済現象を身を持って実感しているのではないだろうか?

興味深いのは、戦前の経済成長率を見ると、ジグザグで不安定なこと。
10%も伸びた年度の翌年にはマイナス成長率になっていたりする。
これだけ不安定な経済であれば、社会不安も多いだろうと統計からも推測される。

【2】日本と世界の国々のGDPや経済成長率の比較も面白い。
90年代以降、日本の経済成長率は、韓国や中国だけでなく、アメリカやEUよりも低い事実が上記ページから読み取れる。

図録▽1人当たりGDPの歴史的推移(日本と主要国)

図録▽経済成長率の推移(各国比較)

図録▽時事トピックス:中国がGDP世界2位、日本が世界3位に

【3】図録▽ヨーロッパの超長期人口推移
図録▽ヨーロッパ地域別人口分布の超長期推移

(引用開始)
ローマ帝国、フランス革命、ロシア革命とヨーロッパ最大の歴史事件は、それぞれ、南欧、西欧、ヨーロッパ・ソ連と当時の最大人口地域で起こっていることに気づかされる。
「人口の最大の集中地域は、一般に政治的・経済的支配を達成した地域にあった。今日、ヨーロッパ最大の人口国がソ連であることは興味深いことである。」
(引用終了)

ヨーロッパという地理を見ると、アラビア・インド・中国と比較して、半島のようにとても複雑な地形をしているのに気づく。
そして、各時代の人口増減によって、戦争があったり、革命があったりしている。

【4】日本の人口推移も見てみると面白い。
江戸時代はほとんど人口が増えず、幕末は畿内よりも北陸の方が人口が多いという事実が興味深い。

図録▽人口の超長期推移(縄文時代から2100年まで)

図録▽地域別人口分布の超長期推移(縄文時代から1995年まで)

幕末に北陸が経済的に盛んだった理由は、日本海を中心とした北前船という船舶による航路が発達していたかららしい。
今でも、福井や金沢、富山は、共働き世帯が多く、大家族中心の家庭が多いという話も聞いた時があるが、その理由はそんな歴史的経緯があるからかもしれない。

図録▽北前船の盛衰

図録▽北前船の船主たち

この統計サイトは、いろんな観点の統計数字で比較論評しているので、今まで常識と思っていた内容がそうでもないという事実が判明したりして、読んでいると引き込まれる。

| | コメント (0)

物理学は一つの認識論

偶然見つけた初心者向けの物理学のサイトが面白かったのでメモ。
理解できたことをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
EMANの物理学

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

【1】高校時代に学んだ物理学は公式だらけで正直面白くなかった。
物理学を本当に理解するには、微積分と微分方程式の解法が必要であり、そこまでのハードルが高かったから。
だから、公式を覚えるしか無かった。

でも、公式の背後に隠れた思想を理解していくと、過去の偉人が自然をどのように見て考えていたのか、どのように認識していたのか、という一つの哲学(認識論)にぶち当たる。
物理や数学は、背景にある思想や直観を元に、数式で厳密に表現していく手法を組み合わせて発達してきたと言える。

【2】EMANの物理学・解析力学・物理法則の形式

物理法則には3種類の形式がある。
一つは「微分形式」であり、「ある瞬間の状態からスタートして微小な時間経過の後に状態がどのように 変化するか、または、ある一点の状態から微小な距離だけ離れたところでは 状態がどのように変化するか、を記述するやり方」である。
例えば、ニュートンの運動方程式や、電磁気のマクスウェル方程式など、有名な物理法則が微分方程式で書かれている。
モノの小さな挙動から、全体を把握しようとする考え方。

もう一つは「積分形式」であり、「部分にはこだわらずに、全体として見た場合に どんなことが成り立っているかを書き下すやり方」である。
例えば、エネルギー保存則や、電磁気学に出てくる積分形のガウスの法則がある。

だが他方、「変分原理」「最小作用の原理」と呼ばれる形式がある。
これは、開始状態と終了状態を指定後、自然は開始状態から終了状態までどのような経路を選択して進むのか、という観点で法則を記述する。
例えば、光の屈折や、量子力学で出てくる経路積分などが相当する。

「変分原理」の発端は、ニュートンが解いた最速降下線問題にある。
ベルヌーイという大陸の学者が、「質点がある点 A からスタートして 滑らかな斜面を転がり落ちるとき、最短時間で別の点 B まで 辿り着くには斜面をどのような形にしたら良いだろうか。」という「最速降下線問題」を提起した後、ニュートンが問題を受け取った日の一晩で解いたという逸話が有名。
最速降下線問題の解答も有名で、サイクロイドになる、というもの。
ニュートンは変分原理という考え方で最速降下線問題を解いて、ここから解析力学が始まった。
解析力学が量子力学へ応用されたことで、変分原理の考え方が現代物理学の骨格となるわけだ。

ちなみに、僕が大学時代に読んだ「物理数学の直観的方法」には、最速降下線問題の内容が詳しく書かれていた。

【3】EMANの物理学・量子力学・シュレーディンガーの猫

EMANの物理学・相対性理論・アインシュタインの指針

量子力学や相対性理論は正直に考えるほど、分かりにくいと思う。
理由は、哲学の認識論みたいに、モノをどうやってヒトは認識するのか、という観測問題を孕んでいるからだと思う。

古典力学では、デカルトの認識論のように、ヒトの認識はカメラ方式のように、実在を客観的に認識でき、実在そのものに言及する。
でも、量子力学や相対性理論のような現代物理学では、観測する立場で見え方が変わる、という観点で話を進める。
相対性理論で出てくる光速度不変の原理、量子力学で出てくる不確定性原理にしても、観測者の場所によって認識ないし観測した事象が違ってくるという点を注意すれば、世間の一般常識から離れた思想を理解しやすくなるのではないか。

【4】EMANの物理学・力学・力とは何か
EMANの物理学・力学・エネルギーとは何か

力やエネルギーは、運動量という概念で考えると分かりやすい、という指摘はとても参考になった。

EMANの物理学の著者は、初心者向けに2冊の本「趣味で物理学」「趣味で相対論」を出版しているらしい。

| | コメント (0)

Redmine 2.3の新機能

Redmine 2.3が先日公開されて、かなり機能拡張されている。
内容をリンクしておく。

【元ネタ】
Redmine 2.3のCHANGELOG (新機能のみ・日本語訳付き) | Redmine.JP Blog

【1】Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

今回の大きな目玉は、ガントチャート機能の強化だと思う。
Redmineを初めて導入する時、Redmineならガントチャートが使えますよ、と言う謳い文句をよく使うので、正直ありがたい。
イナズマ線でタスクの遅延が一目でわかるし、チケットに付けられた先行・後行の関係がガントチャートで表示されれば、MSProjectのように扱うこともできる。

とはいえ、チケット管理していくと自然にアジャイル開発に近くなっていくため、チケットをWBSと同一視して、計画重視でやっていくのは向いていないだろうと思う。

@yusuke_arclampさんが「チケット駆動開発で作業管理はしないほうがいい - arclamp」で述べているように、WBSとチケットはアンマッチ。
チケットという概念そのものが、WBSのようなガチガチの概念とアンマッチな部分があるから、と思っている。

WBSはそもそも管理者の観点で全体的に抜け漏れないように管理したいのに対し、チケットは開発者の観点で都度発生したタスクを起票し、その後の作業内容を記録していくためのもの。

チケット駆動開発では、そもそもビューの観点が違うのだ。

【2】Redmine 2.3新機能紹介: 親プロジェクトのメンバーを子プロジェクトで継承 | Redmine.JP Blog

Redmineでチケット駆動開発を実践していると、バージョンやプロジェクトをどのように使いこなしているか、という観点でチケット管理の習熟度合いが見れると思う。

アジャイル開発の最大の特徴であるイテレーション単位のタイムボックス開発が分かっていないチームは、バージョンという機能を理解していない。
だから、リリース計画という概念が希薄であり、そこから派生したVelocityという概念も出てこない。

バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠: プログラマの思索

TiDD初心者が陥りやすい罠~マイルストーンの役割を誰も理解していない: プログラマの思索

TiDD初心者が陥りやすい罠~バージョンをCloseしないRedmineはVelocityが分からない: プログラマの思索

また、複数チームのプロジェクトや、会社ないし事業部全体でRedmineを使っている場合、Redmineプロジェクトをどのような観点で分割すべきか、という問題がある。
チケット駆動開発の基本的な考え方としては、Conwayの法則に従うように、技術よりも機能の観点で分けた方がいいと思う。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

レイヤの多い組織は無駄に複雑なシステムを作る~Conwayの法則: プログラマの思索

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

【3】他にも使い勝手が改善されている。

Redmine 2.3新機能紹介: ドラッグ&ドロップでのファイル添付 | Redmine.JP Blog

Redmine 2.3新機能紹介: プロジェクトの全メンバーにニュースを通知 | Redmine.JP Blog

今後の機能改善にも注目していく。

| | コメント (0)

入門Gitの著者のインタビュー

入門Gitの著者である濱野さんのインタビュー記事が公開されていたのでメモ。

【元ネタ】
OSS開発者に聞く!コミュニティー活動の実際 - Linus君がボクを後継者に指名した理由:ITpro

記事で目を引いた内容は下記の通り。

(引用開始)
引き継ぎを頼まれた時には、このインタビューの最後の段落で彼が言っているのとほぼ同じコトを言われました。「単にお前が一番たくさんパッチを送ったからではない、お前が他の開発者のパッチをレビューしたり、開発者間の意見の差を調停したりしているのを見ていて、開発者に必要な全体的なセンスが良いと思うから頼むんだ」と。
(引用終了)

(引用開始)
ボクが見たLinus君の一番の特質は「優秀なリーダー」であること、ですね。
 自分で良いデザインができる、自分のか他人のかにかかわらず良いデザインがあったらそれをきれいなコードに書ける、という「優秀な開発者」はたくさんいます。でも、他の開発者それぞれの得意分野とか興味とかを知っていてその人たちをうまく使える、とか、プロジェクトの目標に照らして「この部分はこれでもう十分」とか「この部分は徹底的に丁寧に作らなきゃだめ」という判断が本能的にできる、とか、さきに上げたインタビューで彼が言っている「goodtaste」(日本語では「センスが良い」ですね)をプロジェクト管理に上手に適用できる「優秀なリーダー」は希少です。
 「優秀なリーダー」に率いられたプロジェクトでは、参加している開発者たちがそれぞれ満足感を持って仕事をしてもらうことができます。そういうコミュニティを育てる能力が「優秀なリーダー」であること、だとボクは思っていますが、Linus君には卓越したものを感じます。
(引用終了)

優秀なリーダーは進捗管理が上手いという意味ではなく、システムのあるべき姿(ToBe)をイメージできていて、更にメンバーをその方向へ引っ張っていける力量があるという意味で述べているように思える。

入門Git」の「あとがき」でも、Linusは中核となる機能をプログラミングしておき、興味を持つコミッタに機能拡張のプログラミングを促し、Linuxが考える方向へコミッタをうまくのせて仕事してもらう手法を見たし経験した、と書かれている。

Linusのような人こそが、本来の意味での「コミュニティマネージャ」であるのかもしれない。
コミュニティという場をコントロールできる人だけではなく、コミュニティをあるべき姿へ成長させていけるようにメンバーを引っ張っていける人、という意味かなと思ったりする。

【追記】
Gitに触り始めて、Git本の中で僕が良いと思う本は「入門Git」と「Gitポケットリファレンス」。
Gitの設計思想を知りたいなら「入門Git」、Gitのコマンドを調べながら実際に使いこなしていく時は「Gitポケットリファレンス」がお勧めだと思う。

| | コメント (0)

2013/04/14

製造業やソフトウェア開発における根本問題~在庫とは何か、リードタイムとは何か

3/30に浜松で開催された関西IT勉強会で、佐藤知一さんが話された「製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~」の講演が公開されている。
感想をラフなメモ書き。

第22回関西IT勉強宴会 「製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~」 - YouTube

関西IT勉強宴会のブログです: 2013-03-30(月)第22回関西IT勉強宴会 & スケジューリング学会 合同シンポジュウム

【1】内容は、製造業におけるBOM(部品表)の話なのだが、個人的には「在庫とは何か」「リードタイムとは何か」という問題が隠れているような気がした。
製造指示書や伝票を発行したり、部品表を保守したり、月末にBS・PL・商品有高帳を作るのは、結局、今自社にどれだけのお金があるのか、売上をあげるために必要な商品(製品)はいつまでに作り、必要な部品や原材料はいつまでに納品すべきか、という問題を解決するためにあると思うからだ。

在庫は基本的にはなくてよいもの。
在庫がたくさんあるということは、ムダにたくさん作りすぎていることを意味する。
佐藤知一さんの記事「在庫問題の構造を把握するために(佐藤知一) - BLOGOS(ブロゴス)」に書いてあるように、倉庫に寝かせている仕掛品(在庫)の滞留時間が長いほど、金利がかかってくるために、在庫高以上のコストが無駄に発生しているわけだ。

逆に、必要な時に在庫がなければ、販売機会を失い、本来の売上を失う。
つまり、本来必要な在庫高と失った売上という2倍以上の損失が発生していることを意味する。
だから、必要な時に適正な在庫を持つことはビジネス上重要だし、在庫を管理していくプロセスに普通の会社はかなりの労力を割いている。

貯蓄できない個人が自分の残高を認識していないのと同じように、自社の在庫を把握できない会社は駄目だ。

そのために、売上の元になる商品(製品)の元ネタとなる部品表とそれを作る工程(作業手順)が必要だし、そこには必ず標準リードタイムがセットされているので、必要な製品はいつまでに作るべきか、いつまでに必要な部品を仕入れるべきか、が導き出される。

しかし、この在庫をシステムで見える化するはとても難しい。
まず、作るべき製品の部品をすべて洗い出し、その部品の数量と、いつその部品が必要になるかという納品日といつまでに注文して仕入れるべきかという発注日を計算する必要がある。
普通はその部品の種類は多く、取引先もビジネス環境によって変化する。
そして、一度作った製品製造計画もビジネス環境によって、1か月後には状況が変わってしまう。

そして、必要なリードタイムを計算するロジックは複雑怪奇で開発するのも大変だし、ビジネスの変化で常に変わるため、保守するのはもっと難しい。
1個の部品の発注日が変わると、その部品を使う全ての製造工程に波及するため、影響がとても大きくなるのでリードタイムの再計算で発注日を更新SQLが15分たっても返ってこず、タイムアウトになる場合もある。

在庫の把握とリードタイムの計算は、業務上最重要であるだけでなく、システム上の実装の難易度も一番難しい部類に入ると思う。

【2】TPS(トヨタ生産方式)を元にソフトウェア開発へ応用したリーンソフトウェア開発でも、在庫とリードタイムの概念は自然に現れる。
ソフトウェアはサービス業なので、在庫という概念は本来無いし、在庫としてモノを事前に仕入れるために必要な情報であるリードタイムももちろん無い。

しかし、ソフトウェア開発の各工程で必要となる作業や成果物を在庫として見なせば、そこから必要な成果物はいつまでに必要で、そのためには前工程の成果物はいつから作るべきか、というリードタイムの計算が必要になってくる。
ソフトウェア開発も製造業と同じように考えることができるわけだ。

バリューチェーン分析では、最終的に出荷可能は製品を作る工程と作業内容を洗い出し、価値ある成果物を作るために必要な作業時間を見える化することによって、開発工程のムダな作業を認識する手法。
リーンソフトウエア開発」や「リーン開発の本質」を読むと、ソフトウェア開発で価値あるモノを作る作業時間は、全体の作業時間の1割ほどしか無い事例もあったりして、いかに無駄な作業が多いか、を明確に説明しているのが分かりやすい。

また、リーンソフトウェア開発では、Velocityとサイクルタイムという概念が現れてくる。
Velocityは1週間に開発した機能の数であり、サイクルタイムは1機能にかかった開発時間を表すのが普通。
つまり、Velocityはある一定のイテレーションにおける開発チームの生産能力を表し、サイクルタイムは一つの機能を開発するためのコストを表す。

単純に考えると、Velocityが大きいほど生産能力が高いわけだから、製品の出荷量を調整しやすい。
つまり、ビジネスの都合上、製品の出荷量の増量が突然必要になったとしても、生産能力に余裕があるので、出荷量の変動に強い。

同様に単純に考えると、サイクルタイムが小さいほど、一つの機能(部品)に関わる作業時間が短いので、製品に必要な各機能(部品)のリードタイムは短くなり、製品の出荷を早めることができる。
つまり、出荷ギリギリまで開発を先延ばしできるので、マーケットの事前調査や選択肢を増やしてリスクを減らすことに注力できるから、マーケットの状況の変化に強くなる。

僕はまだリーンソフトウェア開発というものを全く分かっていないけれども、ソフトウェア開発における在庫とリードタイムという概念はVelocityとサイクルタイムを使えば表現できると直感している。
その方法で表現できれば、Velocityとサイクルタイムを開発プロジェクトで常に計測すればよいし、その2つはソフトウェア開発にとってとても基本的なメトリクスの一つなので、多分そう難しくないはず。

【3】TPSでは「かんばん」という概念もある。
「仕掛かんばん」は製造指図書、「納入かんばん」は外部の仕入先に対する発注書みたいなもの。
必要な時に必要な数量の部品を準備するために、在庫をできるだけ減らすためのアナログなやり方。
かんばんには、インプットとアウトプット原材料や部品の数量と納入日が書かれているので、作業者がどの部品を使って作るのかという作業指示書にもなるし、原価管理にも使える。

工場現場では、かんばんによって現物と情報が常に一致しているからこそ、かんばんが流通することで、工場内の工程が見える化される。
流通するかんばんの数量を故意に減らせば、在庫が減るし、在庫が減ることでボトルネックとなる工程や問題を噴出させ、改善を強要する。

ソフトウェア開発でもソフトウェアかんばんとしてその概念は実現されている。
ソフトウェアかんばんに貼られるストーリーカード、タスクカード(抽象化した概念として「チケット」)は、ソフトウェア開発の各工程で使われる機能や作業指示書に相当する。
それらに、納入日や見積り工数、実績工数を入力すれば、実績集計によって原価管理にも使える。

だが、「実践 反復型ソフトウェア開発」にも書いてあるように、ソフトウェア開発における障害管理票(チケット)と仕掛かんばんは同様に見なせるとしても、大きな違いもある。
ソフトウェア開発の作業や障害は、突然の仕様変更や障害によって増える時が多いために、流通するチケット(障害管理票)の数量を故意に増減させることが難しい。
そして、チケット(障害管理票)には、どのように実装すべきか、という仕様が書かれておらず、まず障害を再現させてから原因を調査して初めて修正方法が分かる時も多い。
だから、製造業のかんばんがそのままソフトウェア開発へ適用できるわけではない。

でも、製造業のかんばんをソフトウェア開発へ適用する手法は沢山の人達が実験中で試行錯誤している。
従来のアジャイル開発を補強する一つの手法と考えているからだろう。
チケット駆動開発も、デジタルかんばんとしてソフトウェア開発の作業を見える化する手法を提示している特徴もある。
まだまだ改善の余地があるので、色々考えてみる。

| | コメント (0)

2013/04/06

実践反復型ソフトウェア開発を読む part2~マージの戦略

実践 反復型ソフトウェア開発」のマージの概念は、Gitのコマンドをイメージしながら読めば、よく分かる。
ここでは、ポート(ブランチ間のマージ)の用語を抜き出してみる。
理解できたことをメモ書き。

【1】ポートの種類
実践 反復型ソフトウェア開発」では、あるブランチにコミットしたチェンジセット(複数のソースの変更)を親子関係にあるブランチへ適用してコミットする操作をポートと呼んでいる。

似たような言葉として、ポーティング(移植)もある。
ポーティングは、製品の移植やWindowsの後方互換性のように、ある製品のソフトウェアを他の製品でも動作するように移植して修正・再構築する作業を指す。

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

ポートは2種類がある。単にマージの向き先が違うだけ。

・バックポート:サブブランチ→メインラインへのポート。
 例えば、リリースブランチ上のセキュリティパッチやバグ修正のパッチをメインラインにも反映する場合、あるいは、製品の後方互換性維持のために、過去バージョンのI/Fに関わる修正パッチを最新バージョンの製品にも取り込む場合に使われる。

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

・フォワードポート:メインライン→サブブランチへのポート。

【2】複数のチェンジをポートしたい場合、下記の用語がある。

・バルクポート:範囲を指定して、複数のチェンジセットをまとめてポートする。
 例えば、Gitならば、4abcae1から99daed2までのチェンジセットをマージしたい場合、
 git cherry-pick 4abcae1..99daed2 のようなコマンドに相当するだろう。
 あるいは、topicブランチの全チェンジセットをmasterへまとめてマージしたい場合。
 git merge --squash topic のようなコマンドになるだろう。

・さくらんぼ摘みポート(cherry-pick port):必要なチェンジだけをポートする。
 例えば、Gitならば、4abcae1と99daed2だけのチェンジセットをマージしたい場合、
 git cherry-pick 4abcae1 99daed2 のようなコマンドに相当するだろう。

普通は、さくらんぼ摘みポートよりもバルクポートを利用した方が、追跡する手間が減る。
実際は、ユーザブランチやリリースブランチからメインラインへのポートはcherry-pick、機能ブランチなどの開発ブランチからメインラインへのポートはバルクポートを使う時が多いだろう。

【3】ベースラインとリベース

ベースライン:ビルドが一定の品質に達した時点のスナップショット(タグ)。
リベース:ブランチを作った後に、メインラインの新しいベースラインへ移動する操作。

リベースの本来の意味は、ベースラインを移動する操作のこと。
実践 反復型ソフトウェア開発」のリベースの例として2つある。

一つ目は、バルクポート(FI)によるリベース。
メインラインから開発ブランチが派生した後、最初のベースライン(サブブランチが派生した時点)から次のベースラインまでにコミットされたメインラインのチェンジ全てを開発ブランチへバルクポートする場合。
「Gitのrebaseコマンド例1」に相当する。
このパターンは、開発ブランチへメインラインの最新の修正内容を同期させたい場合に相当するだろう。
作業対象となる開発ブランチを乗り換える必要もなく、開発ブランチ名も変わらないので、運用しやすい。

2つ目は、ブランチの切り直しによるリベース。
例えば、メインラインから、ユーザブランチ(あるユーザ専用の修正を製品に入れるためのブランチ)を切った後に、カスタマイズ前の古い製品がバージョンアップした時、古いカスタマイズ前の製品ブランチからユーザブランチへバルクポートする場合。
「Gitのrebaseコマンド例4」に相当する。
ユーザブランチに、カスタマイズのための修正パッチをマージできるので、運用しやすい。

他には、masterがSVNリポジトリのために、リベースを使ってコードラインを一直線にせざるを得ない場合もある。
「Gitのrebaseコマンド例2」に相当する。
例えば、masterからF1ブランチを派生させて、F1ブランチ上で新機能を開発していて、masterでも修正が発生していたとする。
その場合、最初にF1ブランチのベースラインをmasterの最新リビジョンへ変更させるようにリベースする。
次に、F1ブランチをmasterへFast-fowardマージでそのままマージすれば、F1ブランチのリビジョンがそのまま取り込まれて、masterは一直線になる。
git-svnを使う場合は、このパターンが多いはず。

git rebase F1 master
git checkout master
git merge F1

他には、孫ブランチを子ブランチと同じベースラインへ変更して、マージしやすくする場合もある。
「Gitのrebaseコマンド例3」に相当する。
リベースされた孫ブランチを親ブランチ(master)にFast-fowardマージすれば、masterを一直線にできる。

git --onto master F1 F2

【4】チェンジのプロモーション

チェンジセット:チェンジ(ソースの変更箇所)の集まり。
ペイロード(積み荷):チェンジセットの集まり。

バルクポートの対象となる指定した範囲のチェンジセットは、ペイロードである。

チェンジのプロモーションとは、あるブランチの修正(チェンジ)をより安定したブランチへポートすること。
ポートの向き先(バックポート、フォワードポート)によって、RIとFIがある。

【RI(Reverse Integration)】
バックポート(ブランチ→trunk)の方向へバルクポートする。
(1)コミットポリシー(ビルドエラーを起こさない etc)を適用する。
(2)定期的にRIテスト(CIやスモークテストに近い)を行う。

【FI(Foward Integration)】
フォワードポート(trunk→ブランチ)の方向へバルクポートする。
(1)更新ポリシー(ソースを最新化する etc)を適用し、trunkと頻繁に同期する。

2つのブランチ間でポートを繰り返すことを双方向マージ、はしごマージ、階段マージと呼ぶ。
双方向マージは、メインラインから派生した兄弟ブランチ、親子、子孫のブランチ間のポートを手作業ではなく、SCMツールで実施できなければ相当に面倒になる。

merge tracking機能が強いGitやMercurialなら、どのチェンジセットがポート済みで、いつ誰がポートしたのか、を覚えてくれるので簡単に操作できる。
SVNはVer1.5からmerge tracking機能をサポートしたが、おそらく使われていない機能ではないだろうか?

| | コメント (0)

実践反復型ソフトウェア開発を読む part1~ブランチの戦略

実践 反復型ソフトウェア開発」は、僕にとってのソフトウェア開発のバイブルのような本だ。
構成管理、ビルド管理、障害管理、テスト管理の概念が綺麗に整理されていて、何度も読み直している。
理解できたことをラフなメモ書き。

【1】日本の書籍では、構成管理に関する良い本がとても少ない。
ブランチ管理やコミットポリシー、マージポリシーなどは、現場でよく使われているにも関わらず、あいまいな経験知として流布されているだけで、現場ごとにルールが大きく違う。
CVSからSVN、そしてGitへバージョン管理ツールが大きく進化しているのに、肝心の構成管理の考え方は整理されて共有化できていないように思える。
だから、CVSやSVNというツールに囚われすぎたやり方が主流となっていて、Gitのような最新ツールを生かしきれていない場合も多いと思う。

実践 反復型ソフトウェア開発」では、おそらくマイクロソフトが長年蓄積してきたソフトウェア開発の基盤に関するノウハウが凝縮されている。
丁寧な説明と、補足説明した脚注もあり、とても役立つ。

ここでは、ブランチ管理とポート(ブランチ間のマージ)の用語を抜き出してみる。

【2】ブランチの分類

・メインライン
全ての変更が最終的に集まり、ずっと進化し続けるブランチ。
開発ブランチ的な性質も持つが、ビルドが壊れるようなコミットはしない。
但し、メインラインは1本とは限らない。
(例:統合ブランチ、ベンダーブランチ、コンポーネントブランチ)

ここで、ベンダーブランチは外部製品のソースを管理するブランチ、コンポーネントブランチは自社製品の部品のソースを管理するブランチとして分けている。

・保守ブランチ
リリース済の製品を管理するブランチ。
メインラインよりも厳しく管理され、深刻なバグ修正以外はコミットしない。
メインラインから保守ブランチへのバルクポート(FI)はしない。
(例:リリースブランチ、リリース準備ブランチ、ユーザブランチ)

・開発ブランチ。
開発作業用のブランチ。
活発にコミットされるため不安定になりがちなので、安定した時にまとめてメインラインへバルクポート(RI)される。
(例:タスクブランチ、トピックブランチ、フィーチャブランチ、バグフィックスブランチ、リファクタブランチ)

例えば、製品に対して大掛かりなリファクタリングをしたい時、共通インターフェイス修正によって影響範囲が広い時、メインラインとは別のブランチ上で作業した方が、他の開発者に影響を与えることがない。
普通は、タスクブランチ(作業ブランチ)を作って開発し、テストして安定した段階になったら、メインラインにマージして、タスクブランチを廃止する運用になる。

タスクブランチには幾つかの種類がある。

トピックブランチ:より短期にマージすることを意図した小さなタスクブランチ。
フィーチャブランチ:ある機能を実装するためのブランチ。
バグフィックスブランチ:バグ修正するためのブランチ。
リファクタブランチ:リファクタリングを目的としたブランチ。

これはA successful git branching model と考え方が同じ。
チケット駆動開発とセットで運用している場合、タスクブランチの名前にチケット番号を入れておくと分かりやすくなる。
「チケット無しではフォークできず、マージできない」運用ルールもセットにすれば、メインラインをより安全に保証することもできるだろう。

【3】上記のブランチ管理がメインラインモデルと言われる。
メインラインという主流のブランチから他のブランチが派生されては廃止されるので、最新のソースがどこにあるのか、ブランチの目的は何なのか、が分かりやすい。

逆にプロモーションモデルのように、メインラインモデルからどんどん派生していく場合、どれが最新のソースなのかわかりづらく、保守しにくい。

但し、メインラインは1本とは限らない。
大規模開発では、統合ブランチを使って、メインラインへ各チームのソースをマージする前に、統合ブランチへマージして、テストして安定した段階で、統合ブランチからメインラインへマージするのが普通。

よくあるパターンは、段階的統合ブランチのように、開発ブランチ・受入テストブランチ・リリースブランチの3本がメインラインとして存在して使い分ける。
開発ブランチは、各開発チーム単位で持つ開発作業用ブランチで、活発にコミットされる。
受入テストブランチは、リリース前に受入テストを実施して動作確認するための統合ブランチ。
受入テストブランチへ各開発ブランチからマージされて、テストされて検証OKになったら、ようやくリリースできる。
その時、開発ブランチからリリースブランチへパッチをマージして、本番リリース用のソースをタグ付けしてリリースする。

このやり方はA successful git branching model におけるフィーチャブランチと統合ブランチの考え方と同じ。
A successful git branching model では数多くの種類のブランチがあるが、段階的統合ブランチでは、各チームの開発ブランチを統合するためのブランチとして受入テストブランチが用意されている。
普通は、受入テストブランチは、ユーザないしプロダクトオーナーの役割を担う人が受入テストするための環境に相当するだろう。

| | コメント (0)

« 2013年3月 | トップページ | 2013年5月 »