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

2012年8月

2012/08/31

「チケット駆動開発」の感想を集めてみたpart3

@SugiTKさんが「チケット駆動開発」の感想をTwitterで流していて、とても参考になったのでメモ。
ありがとうございます。
感想をラフなメモ書き。

【元ネタ】
Twitter / SugiTK: 「チケット駆動開発」を読んでます。ようやく6章まで。少なくとも15年以上前には、FreeBSD Project で CVS + GNATS + make での「三種の神器」が揃っていました。ツールは変わりましたが考え方はほとんどそのままと言えると思います。

Twitter / SugiTK: そういう昔からのOSSでの開発手法が一般の企業活動にもようやく採用されるようになってきたというのはここ5年ほどのことだと思います。ツールはそれぞれ改良されて git + Redmine + Jenkins が最強だと思いますが、根本はさほど変わってないように感じます。

Twitter / SugiTK: 13年前に某社に新卒で入社したときにCVSはこんなに便利で日付とか担当者別に毎回全部をコピーしなくてもいいんですよ、とプレゼンしたことがあったんですが、「複数の担当者で一つのコードをいじるほうがおかしい」と一笑に付されたのをよく覚えてます。

Twitter / SugiTK: 他のことでもよくあることなのですが、一部の人にはよく知られていてそれまでの常識ではないことというのは、なかなか理解されません。いいか悪いか考えてもくれず即却下ということも普通にあります。

Twitter / SugiTK: 中身は同じでも、何かわかりやすい単語や概念を作って広めるのが好きな人に広めてもらうというのはかなり有効なんですよね。多くの人に手に取ってもらって、ようやく検討してもらえるという。いい考え方だったりモノだったりすると、やっとそこから進化していくんですよね。

Twitter / SugiTK: まだ半分も読んでないところでの感想なのですがこの「チケット駆動開発」は少々読みにくいです。学術的すぎるという印象があります。よくまとまっていて人に紹介しやすいというところもあれば、それはあまりにも古いですよ、などというところも。後半ものんびり読み進めます。

Twitter / akipii: 玄人の人達が解説してくれればと笑 RT @SugiTK: まだ半分も読んでないところでの感想なのですがこの「チケット駆動開発」は少々読みにくいです。学術的すぎるという印象があります。よくまとまっていて人に紹介しやすいというところもあれば、それはあまりにも古いですよ、など

Twitter / akipii: アジャイルの概念追加が新しい観点と思います RT @SugiTK: 「チケット駆動開発」を読んでます。少なくとも15年以上前には、FreeBSDでCVS+GNATS+makeでの三種の神器が揃っていました。ツールは変わりましたが考え方はほとんどそのままと言えると思います

Twitter / SugiTK:なるほどです。ただ、FreeBSDも十分アジャイルな開発をしていたと思います。短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリなどです。ずっと変わらないので効率の面から置いて行かれた感はあります… RT @akipii アジャイルの概念追加が新しい観点と思います

Twitter / akipii: 仕様書も同じ文脈ありました @SugiTK 13年前に某社に新卒で入社したときにCVSはこんなに便利で日付とか担当者別に毎回全部をコピーしなくてもいいんですよとプレゼンしたことがあったんですが「複数の担当者で一つのコードをいじるほうがおかしい」と一笑に付されたのをよく覚えてます

Twitter / akipii: ソフトウェアが時代にようやく追い付いたのだと思う @SugiTK 昔からのOSSの開発手法が一般の企業活動にもようやく採用されるようになってきたのはここ5年ほどのことだと思います。git+Redmine+Jenkinsが最強だと思いますが根本はさほど変わってないように感じます

Twitter / akipii: 素晴らしいですね @SugiTK FreeBSDも十分アジャイルな開発をしていたと思います。短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリなどです。 @akipii アジャイルの概念追加が新しい観点と思います

Twitter / akipii: チケット駆動開発が古いツールでアジャイルの価値観と方向性を示したことが新しいと思います。同じか。@sakaba37 いや、アジャイルっぽい事も昔からあって、整理された事が新しいかと。 RT @akipii: アジャイルの概念追加が新しい観点と思います

多分、BTSというWebシステムが出現する以前から、障害管理と変更管理、ビルド管理を組み合わせた手法を実施していた現場は存在していただろう。
そのようなツールの組み合わせが生まれた理由は、現場でそんな開発環境が必要だったからという欲求があったからだと思う。
@SugiTKさんのように、随分以前からCVS + GNATS + makeのようなツールを組み合わせて、「短期間でのリリース目標設定、日々の回帰テスト、継続的デリバリ」を運用してアジャイルに開発していた現場はかなり慧眼の目があったに違いない。

その頃とチケット駆動開発が生まれた現在を比較してみると、CVS + GNATS + makeからgit + Redmine + Jenkinsというツールへ成長して変わっただけとも見えるが、僕はそう思っていない。
チケット駆動開発がアジャイルという概念と密接に連携しただけでなく、ソフトウェア開発に新しい観点を提示した点が大きいのではないかと思っている。
そして、そのようなツールが必要となるマーケット(開発現場)とチケット駆動開発というアイデアが結びついたからこそ、静かに普及していったのだと思う。
従来型開発へのテーラリングは、その一連の流れのバリエーション(派生・先祖返り)に過ぎないかなと思ってる。

最近思うのは、ソフトウェアがようやく時代に追いついたという感覚。
TwitterやFacebookが普及した頃から、各地の開発現場のノウハウを勉強会やコミュニティで共有しやすくなり、色んな人達が切磋琢磨するような環境が生まれたように思う。

チケット駆動開発は、ITSやバージョン管理などのツールの使い方という観点と、アジャイル開発への適用という観点がある。
その観点が意味するのは、ソフトウェアでソフトウェア開発のプロジェクト管理の諸問題を解決できるという事例が増えてきていることを意味していると思う。
プログラミング技術が優れていれば、それをベースにより少人数でアジャイルに開発できる環境が整いつつあるからだ。
そうでなければ、短期間で頻繁にリリースしていくアジャイル開発を安定して運用することはできないだろう。

そして、安定してアジャイル開発できるようになれば、そこから開発のリズムが生まれ、自分たちの運用を改善していけるようになり、マネジメント技術も身に付けていくことができると思っている。
プログラマがいきなりチーム運営できる立場に立つことはあまりないだろうが、アジャイル開発を経験することで、マネジメント能力を向上できるきっかけが生まれると思う。
より良い環境を自ら作り出せば、能力を向上できるチャンスがどんどん生まれる時代なのだと思う。

他にも探してみる。

| | コメント (0)

2012/08/28

組織パターンとプロセスパターン

コプリエンの組織パターンとプロセスパターンをオブジェクト倶楽部のHPから探したのでメモ。

【元ネタ】
- 組織パターンとプロセスパターン

パターン、Wiki、XP」によれば、アレグザンダーのパターン・ランゲージの発想をソフトウェア開発の組織やプロセスに当てはめた場合、どんなパターンが出てくるか、という観点で作られたらしい。
それらのパターンを読むと、XPのプラクティスととても良く似ているのが分かる。
実際、「パターン、Wiki、XP」によれば、ケント・ベックはコプリエンの組織・プロセスパターンやワードカニングハムが作ったパターンを元にXPを生み出したとのこと。

イノベーション・スプリントに行けませんでした - かおるんダイアリーでも、コプリエンの組織パターンとプロセスパターンについて、とても分かりやすい指摘をされている。

(引用開始)
Scrumはこの組織パターンに当てはめてフレームワークを作成した、ということがよくわかった。
例えばScrumにおけるスクラムマスータは、組織パターンにおけるFirewallsである。
(引用終了)

Firewallsとは「マネージャ・ロールを作り,開発メンバを外部のロールからの情報や批判から保護する」パターン。
つまり、スクラムマスターは、「鶏と豚」の喩え通り、外部にいる部外者の批判や監視から開発者を守る役割であると言える。

@haradakiroさんから、「Scrumは組織パターン言語」という話を聞いた時があったが、多分それは上記の文脈だったのだろうと推測する。

Scrumの組織パターン: プログラマの思索

重要なテクノロジーは10名以下のチームで作られた ~ Innovation Sprint 2011(後編) - Publickeyを読むと、「Scrum is simple framework」という図がある。
この図の構造は、コプリエンの組織・プロセスパターンによく似ている。

SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語にある「図2. SCRUMパターン言語の束」を見れば、スクラムマスターはFirewallというパターンと関係している。
同様に、Scrmで定義されているロール・ミーティング・成果物は、コプリエンの組織・プロセスパターンと関連付けられるように説明できるのだろう。

つまり、Scrumはコプリエンの組織・プロセスパターンを忠実に再現したプロセスフレームワークであると言う主張が出てくるのだろう。

イノベーション・スプリントに行けませんでした - かおるんダイアリーでは、こんな言葉もある。

(引用開始)
プログラム言語も同じだが、「それ」が必要な背景(何を解決するために存在するのか)を知ることでより深く理解することができるんだと思う。
(引用終了)

XPやScrumが提唱するオリジナルの原則がどこから発生したのか?
そして、その原則は何を解決しようとして、何を導こうとしたのか?

パターンで面白いのは、必要最低限のパターンの集合から多数の効果が得られること。
この特徴は「生成的(generative)」と呼ばれる。
つまり、複数のパターンを組み合わせることで、ソフトウェア開発を抜本的に変えてしまう効果が出てくること。

数学で言えば、必要最低限のパターンの集合は公理系、生成(generative)された効果は公理から演繹される定理や系、命題、事例と言えるだろう。
つまり、必要最低限のパターンを徹底的に運用すれば、色んな効果が出てくるはずだし、生成された効果が本質的なのではない。

この辺りの考え方をチケット駆動開発に適用することはできないのか?
色々考えてみる。

| | コメント (0)

2012/08/27

「チケット駆動開発」の感想を集めてみたpart2

倉貫さんが『チケット駆動開発』のまえがきを公開してくださいました。
推薦文の執筆ありがとうございます。

【元ネタ】
書籍『チケット駆動開発』が出版されました - Social Change!

(引用開始)
チケット駆動開発を実践するようになると、それ以前の開発がどうしていたのか思い出すのも困難になってしまいます。それほどチケット駆動開発は、ソフトウェア開発の現場にフィットするし、プロジェクトの進め方のスタンダードを変えてしまうものなのでしょう。

私が代表を務める会社ソニックガーデンはソフトウェア開発の会社ということもあり、現場のすべての開発をチケット駆動開発で行っています。開発の作業をする際には、必ずチケットにしてから取りかかるルールが出来ています。もしチケットにない作業をしたとしても、仕事をしたとは認められず、仕事の成果は必ずチケットによって表現されるという厳密さです。そうすることで、今誰がどれだけの作業を進めていて、これまでチームでどれだけの仕事をしてきたか、そして、これから先どれくらいのペースで仕事ができるのかを共有することができます。

どんな仕事であっても少しずつ積み重ねていくことでしか大きな仕事は成し遂げられません。チケットという小さな単位にまとめながら、チームで共有して、ひとつひとつのチケットをつぶしていくことで、前に進めることができます。特に、ソフトウェアのような目に見えないモノを作ろうというときには、チケットという形に見える化することは大事です。そして少しずつ進めていけば、途中での軌道修正がしやすくなり、無駄な開発を避けたり、変化にも柔軟に対応することができます。それはまさしくアジャイル開発です。

アジャイル開発の多くの現場では、チケット駆動開発を採用しています。チケット駆動開発と言っていなくても、タスクの見える化をして、壁に張り出して進捗を全員で共有する、そんな風に進めているならば、それは本質的にはチケット駆動開発に近いことを行っています。そこからRedmineやtracのようなツールを導入したとしたら、より効率的にうまくプロジェクトを進めることができるでしょう。逆に、チケット駆動開発のエッセンスを知らずにツールを使うだけでは、うまくいかないことも多いはずです。

チケット駆動開発は、特定のツールに依存したものではありません。しかし、ツールをうまく使うことで、よりプロセスを成長させることが出来ると考えています。本書では、筆者である小川さん阪井さんの経験をもとに、チケット駆動開発のエッセンスから、ツールの使い方の応用まで非常に丁寧に書かれています。プロジェクトをうまく進める改善のヒントを求めるすべての人にお勧めします。
(引用終了)

倉貫さんの会社では「現場のすべての開発をチケット駆動開発で行っています」とのこと。
Pivotal Trackerでチケット管理されているでしょうから「No Ticket, No Release」を運用されているでしょうし、「もしチケットにない作業をしたとしても、仕事をしたとは認められず、仕事の成果は必ずチケットによって表現されるという厳密さです」ということですから、「No Ticket, No Work」も運用されているのでしょう。
おそらく、理想的なチケット駆動開発に近いのではないかと想像します。

また、「アジャイル開発の多くの現場では、チケット駆動開発を採用しています」という言葉は我が意を得たり、という思いです。
ツールであってもアナログであっても、何らかの形で「チケット」という概念は自然に現れていて、それをうまく使うことで作業の管理をしている現場が多いと思ってます。
そのチケットは「タスクカード」や「ストーリーカード」と呼ばれたり、PostItで実現されている所もあるでしょう。
その時に、チケット管理のノウハウは必要で、単にチケット管理を真似ただけでは、本来の効果が出ないでしょう。
Redmineによるタスクマネジメント実践技法」「チケット駆動開発」では、チケット管理のプラクティスやアンチパターン、アジャイル開発への適用の注意点を詰め込めんだので、参考になるかと思ってます。

| | コメント (0)

2012/08/24

「チケット駆動開発」の感想を集めてみたpart1

平鍋さん、前田剛さん、藤原さんが「チケット駆動開発」の感想をBlogで公開してくれています。
ありがとうございます。

書籍「チケット駆動開発」8月23日発売 | Redmine.JP Blog

(引用開始)
チケット駆動開発の考え方、チケット駆動開発を行うためのRedmineなどの課題管理システムの使いこなしなどが詳説されています。ツールの使い方ではなく運用を解説した資料は少ないので、著者のお二人の経験をもとにチケット駆動開発を論じた本書は大変貴重だと思います。
以下、発売元である翔泳社のwebサイトの紹介文です。

TiDDと呼ばれるチケット駆動開発手法は、「国内の」「現場で」編み出され、実践のなかで確立されてきた大きな特徴をもっています。本書ではその経緯に深く関わりながら、多くの実践例や勉強会、講演などを経てチケット駆動開発の開拓をリードしてきた二人による、まさに定番、原典ともいえる一冊です。チケット駆動開発の基本や考え方から、Mantis、Trac、Redmineなど代表的なツールによる導入事例、高度な運用方法、FAQ/アンチパターン集、用語集まで、チケット駆動開発を知り尽くし実践するための全てが収まっています。
(引用終了)

チケット駆動開発でツールを『使う』から『使いこなす』へ | 世界 - daipresents!!

(引用開始)
『チケット駆動開発』を献本いただきました。小川さん、阪井さんありがとうございます。
本のレビューにも参加させていただくことができましたが、実際に本になると感慨深いですね。初めてこの本を読んだ時に、ツールを活用したタスク管理の考え方がまとまった良書だなぁと思いました。
タスク管理に迷える子羊をみかけたら「ツール使っただけで『アジャイルだ』とか言う前に『チケット駆動開発』を読め」って言ってみようと思います。
(引用終了)

書籍『チケット駆動開発』が出版されました。:An Agile Way:ITmedia オルタナティブ・ブログ

(引用開始)
この本は、チケット駆動開発(TiDD)について書かれた本の、待ちに待った二冊目です。小川さん、阪井さん、おめでとうございます。

本の出版にあたって、まえがき、を書かせてもらいました。ここに、紹介文として掲載します。ぜひ、本を手にとって見てください。

日本でも「アジャイル」という言葉がよく聞かれるようになりました。その中の1つの手法である「スクラム」という言葉を先に知ったという方も少なくないでしょう。アジャイル開発では、チームが協調して動くソフトウェアを育てます。チームは現在の状況を透明化して共有し、顧客にも伝えます。状況共有の手法に「ストーリ」、「かんばん」、「バックログ」、「バーンダウン」等がありますが、これらを積極的なツール支援によってより分かりやすく、チームが使いやすい仕組みにしよう、というのがチケット駆動開発です。

逆に言えば、チケット駆動開発では、「チケット」という概念を一番先頭にもってくることによって、アジャイルに必要なルール(規律)を現場中心に作り出し、開発全体を進める(駆動する)手法だということができるでしょう。

具体的な行為と結びついたチケットは分かりやすく、「アジャイル」という言葉のように時に漠然とした議論に陥ることがありません。アジャイル開発をしているかどうかは判断が難しい場合が多いですが、チケット駆動開発をしているかどうかは、はっきりと分かるでしょう。ですから、アジャイル開発を始めるのに、チケットをまず使ってみる、という使い方も、よい出発点だと思います。

さらに、チケット駆動開発はアジャイルだけに特化した手法ではありません。ウォーターフォールのように行程を区切った開発を支援する手法としても十分使えるのです(本書の中ではAdaptable Waterfallという呼び名で呼ばれています)。このことも、日本での利用シーンの想定を広くしています。

私自身も、アジャイルの中のチームビルディング、コラボレーション、ファシリテーションのエッセンスを抜き出して、それをウォーターフォール開発でも実践できるようにと「プロジェクトファシリテーション」(本書の中にも何度か登場します)という手法を作って日本で多くの人たちに伝えてきました。チケット駆動開発もまた、急激にアジャイル開発を実践できない現場でも、取り入れることが可能で、かつ、メリットをすぐに享受できる手法なのです。

ちなみに、私はすべての開発がアジャイルであるべきだ、とか、アジャイルがどんな場面でも最も優れた開発手法だ、という風には思っていません。開発現場がそれぞれ違うのですから、それぞれが自分たちで手法を選択し、さらに適用を考えるべきです。その意味で、チケット駆動開発は分かりやすく、自分たちのやり方を考えるよい出発点になるでしょう。
(引用終了)

平鍋さんの記事にはいつも色々考えさせられます。
チケット駆動開発とは「「チケット」という概念を一番先頭にもってくることによって、アジャイルに必要なルール(規律)を現場中心に作り出し、開発全体を進める(駆動する)手法」とも言えるわけですね。

僕の考えでは、「アジャイルに必要なルール(規律)」が「No Ticket, No Commit」「Ticket First」に代表されるプラクティスないし運用ルールだと思っていて、その運用ルールを徹底すると「自然に」アジャイルの効果が湧き出てくるのだと思っています。
それは、XPのプラクティスを組み合わせて実践することで、XPのプラクティスでは語られていないソフトウェアの信頼性などの品質や開発の効率性が「自然に」出現してくる現象と同じだと直感しています。

Twitter / akipii: @sakaba37 テーラリングという場合、標準プロセスが既に定義されていて、標準プロセスを加工修正するというトップダウンの意味合いで捉えてます。チケット駆動開発はツールを使っていたら自然にプラクティスが現れてそれが運用ルールになったというボトムアップの感覚です。

Twitter / akipii:@sugimoto_kei アジャイル開発の個別のプラクティスは品質や効率、進捗管理について何一つ説明していないにも関わらず、複数のプラクティスを組み合わせて初めて高品質で高速な開発が実現されます。アジャイル開発のテーラリングは多分ありえないと思うのです。

Twitter / akipii:@sugimoto_kei はいアジャイル開発は標準プロセスのテーラリングでは断じてなく、プラクティスというパターンの組み合わせから発生すると思うのです。チケット駆動開発も同じ文脈で説明するようにしたいです。

Twitter / akipii: そうなんです。リーダーシップさえもプラクティスを実践すれば「自然に」身につくのです。RT @sugimoto_kei 特にXPでは、チームやメンバの主体性さえ、最初に与件として前提されているのではなく、プラクティスの中から「立ち上がってくる 」という面があるんですよね。

最初はスキルがなくても、知識がなくても、プラクティスを実践していれば、「自然に」アジャイルに慣れて、スキルが「自然に」身につくはず。
なぜなら、プラクティスとは、過去の開発者が苦労して編み出した経験知が含まれているから。
プラクティスは、アレキザンダーの言うパターン・ランゲージであり、人の心の中に生まれながらに持っている暗黙知だから、という気がしている。

平鍋さんがプロジェクトファシリテーションをアジャイルなプラクティスの集合知として提唱され、実際の現場で役立つ実践ノウハウとして紹介されているように、チケット駆動開発もアジャイル開発をサポートするプラクティス集として説明できるようにしたいと思ってます。

| | コメント (0)

2012/08/23

8月はアジャイル本の当たり月

8月はアジャイル本の当たり月のようです。

【元ネタ】
Twitter / akipii: 今月はアジャイル本の当たり月。チケット駆動開発もあり光栄です RT @minitasca: チケット駆動開発とサービスデザインパターンは予約した。Reading...プログラマなら買って損なし!今月発売される注目の技術書5冊 http://buff.ly/PH8Qhd

プログラマなら買って損なし!今月発売される注目の技術書5冊 | Act as Professional - hiroki.jp by HIROCASTER

チケット駆動開発 no ticket, no commitは誤解 | Act as Professional - hiroki.jp by HIROCASTER

サービスデザインパターン SOAP/WSDLとRESTful Webサービスの基本的な設計ソリューション」「プログラマのためのサバイバルマニュアル」「アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理」「WEB+DB PRESS Vol.70」が8月に出版されるらしく、どの本もお勧めだそうです。
個人的には、江端さんが翻訳された「アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理」が一番気になります。

Twitter / ebacky_ja: アジャイルなゲーム開発の内容で「もっと詳しく」「よく分からない」等、何かあれば気軽に聞いて下さい。クリントンや私で回答できる事なら回答します。ちなみに質問を質問で返す事もありますw 後、誤字脱字もw 読んで終わりではなく、仲間と議論して理解を深め、より良い開発方法を探求して下さい

Twitter / ebacky_ja: アジャイルなゲーム開発は、キッカケや通過点にして頂きたい。「読んで終わり。実践しても上手くいかないから終わり。内は特別だから出来なくて仕方ない」等ではなく、最初から上手くいなくて当たり前。上手くいかない時の参考書に。仲間との議論のネタに。使って下さい。本書より、良い開発方法もある

Twitter / ebacky_ja: アジャイルなゲーム開発を出版して終わりではなく、読んで頂いた方の「私はコウ考える」「別の方法のが良い」「これでは上手くいかない」等のご意見を伺い、意見交換や議論して、より良い開発方法を探求したい。本書は、知識を得るための物ではなく、コミュニケーションのキッカケとなるツールだから

もちろん「チケット駆動開発」も含まれてます。
こんな引用がありました。

(引用開始)
チケット駆動開発を提唱する2人の著書なので、ソフトウェア開発でBTSのチケットをもっと効率よく扱いたいと考えている日本全国のプログラマの皆さん必見の書籍になるかと。
(引用終了)

今年の夏は読書の夏になるのでしょうか?

【追伸】
江端さんから、認定スクラムマスター・認定プロダクトオーナー研修が下記日程で行われる案内を頂きました。
興味のある方は申し込まれると良いかもしれません。
大阪で開催される認定スクラムマスター研修は、要注目かもしれません。

・10月10日〜12日に東京で、CSPO研修
Scrum Alliance - Certified Scrum Product Owner

・10月18日〜19日に大阪で、CSM研修
Scrum Alliance - Certified ScrumMaster

・11月13日〜15日に東京で、CSM研修
Scrum Alliance - Certified ScrumMaster

| | コメント (0)

2012/08/21

コードレビューの歴史

コードレビューの歴史に関して良い記事があったのでメモ。

【元ネタ】
コードレビューいろいろ - steps to phantasien

コードレビューは非同期ペアプログラミングとも言える。
二人の目を必ず通すことで、ソースの品質をチェックする。

ソースインスペクションを真面目にやるGoogle、MS: プログラマの思索

コードレビューはペアプログラミングの代替手段: プログラマの思索

コードレビューでよくあるのは、ウォークスルー。
コードレビューされる人が司会者となり、別のレビューアにコードレビューしてもらう。
ウォークスルーは、司会者によほどの力量がない限り、あまりうまくいかない。
一人の人の役割が大きすぎるからだ。

Code Complete第2版―完全なプログラミングを目指して」のような本では、インスペクションが推奨されている。
インスペクションは、モデレータ、書記など役割分担がはっきりしており、事前準備の計画、議事録、レビュー後のチェックなどのプロセスが定義されている。
厳格なだけに実施するための準備が多いし、インスペクションの経験者がいなければうまく回らないだろう。
CMMやTSP、清水吉雄さんが提唱されているXDDPでよく使われていると思う。

コードレビューをサポートするツールは、Googleが自社開発のために作ったMondrianが一番有名だろう。
そこから各種のオープンソースツールが生まれた。
多分、ReviewBoardが一番有名だろう。
今なら、Gitと一体化したGerritが有名かもしれない。

コードレビューで多いスタイルは、コミット前のレビュー。
ReviewBoardではプレコミットレビューの機能が既にあり、充実している。

ReviewBoardでプレコミットレビュー: プログラマの思索

コミット後レビューで多いのは、Diffメール。
SVNにコミットしたら、その差分をメーリングリストに流す。
Diffメールを使うプロジェクトは今でも多いだろうし、Diffメールからコードレビューに発展する時も多いだろう。

コードレビューいろいろ - steps to phantasienの記事で面白かったのは、Bugzillaに既にパッチの差分ファイルを添付することでコードレビューする機能がプラグインとして提供されていたこと。
BugzillaのプラグインSplinterを使うと、差分表示してくれるらしい。

Splinter ? patch review for Bugzilla ≪ fishsoup

また、Bugzillaにはパッチのレビューのステータスを管理する機能もあるとのこと。
この機能があるだけでも、全く違ってくるだろう。

(引用開始)
Bugzilla は Mozilla によって開発され, WebKit でも使われている. Bugzilla にはファイルを添付できる以上の大仰なレビュー支援機能はない. そのパッチがレビュー要求であること, パッチのレビューが受理されたことを, フラグとして管理できるだけ. でもフラグをはじめとするメタ情報を検索でフィルタできるから, メールよりはレビューの進捗を把握しやすい.
(引用終了)

RedmineやTracなら、パッチの添付ファイルは差分表示してくれるし、コードレビューそのものをチケット化することで、一つの作業とみなせる。
ツール自身もどんどん進化している。
だが、コードレビュー専用のツールの方が使いやすい場面も多いかもしれない。

| | コメント (0)

2012/08/20

「チケット駆動開発」ハンドブックの詳細目次と感想

チケット駆動開発」ハンドブックの詳細目次が公開されたのでリンクしておく。
なお、8/18から東京の一部の大型書店で既に販売されている。
(全国の一般書店では8/24から販売と聞いてます)

チケット駆動開発 - 小川明彦/阪井誠/翔泳社:SEShop.com

なお、既に一部の方から感想があがってます。
ありがとうございます。

Twitter / mkt_: 現段階でチケット駆動開発の解説ならこれを読まない手はないです。ただ、自分はBTS時代からWeb上での作業フローを確立させてたので大丈夫ですが、初心者にはちょっと情報量が多すぎるかも~(*´Д`) http://www.amazon.co.jp/dp/4798125067/ref=cm_sw_r_tw_dp_QQImqb0RMAQSF … 「チケット駆動開発」(小川 明彦/坂井誠)

Twitter / mkt_: @akipii @akipii 私は大丈夫なのですが会社の子に勧めるのはちょっと躊躇してしまう感じです。まだチケット駆動開発の利点を理解出来る程、作業フローのチューニングに対して意識が向いていないようなので。個人的にはもう一段初心者向けの書籍も欲しかったりします。なかなか難しいですが(*´Д`).

Twitter / akipii: @mkt_ @mkt_ 初心者向けなら@g_maedaさんのRedmine本がお勧めですね。チケット管理やバージョン管理、チケット駆動開発の基本的な考え方が優しく書かれています。入門Redmine 第3版: 前田 剛: http://www.amazon.co.jp/dp/4798034401

Twitter / goyoki: ツールって使い方の情報は豊富だけど、現場での運用方法の情報は限定的な場合が多いよね。チケット駆動開発はITSやVCSの洗練された運用方法そのものなので、貴重で勉強になる

【詳細目次】
プロローグ ーチケット駆動開発はプロジェクトを元気にするー
チケット駆動開発との出会い
チケット駆動開発はXPを改善する
いざ実践!
チケット駆動開発のプロセス
なぜアジャイルが判るか
なぜ「チケット駆動開発」と呼ぶか
チケット駆動開発はプロジェクトを元気にする
第1部 チケット駆動開発の基本
第1章 プロジェクトの混乱から洗練へ
1.1節 プロジェクトの混乱と従来の対策方法
1.2節 それでもプロジェクトが混乱する理由
1.3節 チケット駆動開発のビジョン
1.4節 チケット駆動開発とは
1.5節 チケット駆動開発は現場から始まった
1.6節 ツールによる自動化・デジタル化
1.7節 チケット駆動開発はどのようにプロセスを洗練するか
第2章 障害管理
2.1節 障害票としてのチケットの流れ
2.2節 障害報告の留意点
2.3節 開発担当者の心がけ
2.4節 管理者の役割
2.5節 チケット駆動開発における障害管理
2.6節 統計情報による管理
第3章 構成管理とツール
3.1節 バージョン管理ツールの基本機能
3.2節 ベースラインと変更管理
3.3節 タグとブランチ
3.4節 障害管理ツールとバージョン管理ツールの連携
第4章 障害管理ツールMantisの運用例
4.1節 帳票が抱える障害管理の問題
4.2節 Mantisの特徴
4.3節 Mantisの運用サイクル
4.4節 Mantisの初期設定
4.5節 Mantisのチケツト
4.6節 Mantisのワークフロー管理
4.7節 MantisとCVS連携
4.8節 Mantis のレポ一ト出力
4.9節 Mantisのロードマップと変更履歴
4.10節 Mantis の利点と課題
第5章 障害管理からチケット駆動開発へ
5.1節 BTSからITSへ
5.2節 チケット駆動開発の特徴
5.3節 チケット駆動開発の意義
5.4節 ソフトウェア開発の三種の神器
第2部 チケット駆動開発でプロジェクトを成功に導く
第6章 プロジェクトを成功に導くチケット駆動開発
6.1節 チケット駆動開発の有利な点
6.2節 チケット駆動開発はプラクティス?
6.3節 チケツト駆動開発のビジヨン再び
6.4節 プ口セスモデリング
6.5節 プロセスをプログラムとして考える
6.6節 プロセスモデリングにおけるチケット駆動開発の可能性
6.7節 完全型と補完型
第7章 チケット駆動開発がもたらすアジリティの向上
7.1節 チケッ卜駆動開発で気付いたアジャイル開発の仕組み
7.2節 チケット駆動開発はプロセスを軽量化する
7.3節 チケット駆動開発がもたらすプロセス
7.4節 チケットの管理
7.5節 プロセスの形式化
7.6節 開発のリズム
7.7節 現場力の向上
7.8節 ソフトウエア開発で重要な三つのこと
7.9節 チケット駆動開発における生産性、リスク、品質の考慮
7.10節 チケット駆動開発で自律的な組織を目指す
第8章 アダプタブル・ウォーターフォール開発
8.1節 従来法の限界とアジャイルの利点、そしてチケット駆動開発
8.2節 チケット駆動でAdaptable Waterfall開発!
8.3節 二つのアダプタブル・ウォーターフォール開発
8.4節 チケット駆動開発とコーチング
8.5節 デジタル化の効果
8.6節 チケット駆動開発は従来型開発とアジャイルの隙間を埋める
8.7節 ツールでできること
8.8節 チケット駆動開発でプロジェクト改善!
8.9節 ソフトウェア工学の課題とチケット駆動開発の可能性
第9章 アジャイルブームを超えて
9.1節 不確実コーン
9.2節 アジャイル開発が注目される理由
9.3節 リスク低減とチケット駆動開発
第3部 チケット駆動開発による開発カの向上
第10章 チケット駆動開発の高度な運用方法
10.1節 チケット駆動開発の適用範囲
10.2節 チケットの粒度とチケット集計機能の関係
10.3節 ワークフローの考え方
10.4節 バージョンの考え方
10.5節 プロジェクトの考え方
10.6節 SCM連携の強化
10.7節 チケット駆動開発の導入はERP導入に似ている
10.8節 Application Lifecycle Management
第11章 チケット駆動開発のFAQ とアンチパターン集
11.1節 チケット編
11.2節 ワークフロー編
11.3節 構成管理編
11.4節 バージョン編
11.5節 プロジェクト運営編
第12章 チケット駆動開発のテーラリング
12.1節 テーラリングの対象
12.2節 テーラリングの観点
12.3節 テーラリング方法を考えるポイント
第4部 付録用語集
エピローグ:コミュニティがチケット駆動開発を支える
参考文献
参考リンク

| | コメント (0)

2012/08/17

平鍋さんの記事が熱い~日本のアジャイル10年、人々とコミュニティの私的物語

平鍋さんが2011年に『Ultimate Agile Stories - Iteration 1』へ寄稿された記事が公開されていたのでメモ。
日本のアジャイル界の第1人者である平鍋さんの観点から眺めたら、日本のアジャイルの歴史はこんな風に見えるというのがよく分かる。
チケット駆動開発も交えて、ラフなメモ書き。

【元ネタ】
日本のアジャイル10年、人々とコミュニティの私的物語:An Agile Way:ITmedia オルタナティブ・ブログ

- eXtreme Programmingの魅力を探る

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

平鍋さんが2000年にXPを初めて日本に紹介してから、日本のアジャイルの歴史が始まったと言っても過言ではないと思う。
多分、数多くの日本人開発者がアジャイルという言葉に、詳しい意味は分からなくてもそのエッセンスに惹かれて熱狂的に支持したのだと思う。
そして、日本XPユーザグループ(XPJUG)というコミュニティが生まれて、日本のITコミュニティの中でアジャイルが一つの分野として確立された。

だが、実際の現場では、なかなかXPもアジャイルも成功事例として普及しなかった。
今振り返ると、XP原理主義に走ったり、アジャイル開発を支える開発インフラが不十分だったり、組織体制が開発チームをバックアップする体制でなかったのも理由の一つだったように思える。

そんな中、管理職層に向けて、日本人向きのアジャイル精神を吹き込んだPF(プロジェクトファシリテーション)を平鍋さんが2005年頃提唱された。
PFは一つのブームとなり、PFP関西などPFに関するコミュニティが生まれて活発に活動し始めた。
今までアジャイルのターゲットは開発者層に限定されていたから、管理職層に向けたマーケティングとしては大成功だったと思う。
実際、PFで重視するチームビルディングは現場リーダーにとってとても重要な要素があると思う。

そして、最近はリーンソフトウェア開発やリーンスタートアップのように、経営者向けのアジャイル的なアイデアも提唱されて、アジャイルのマーケットが格段に広まった。
特に、IPAは非ウォーターフォール型開発の一例としてアジャイル開発に関する研究報告書をたくさん公開している。
この報告資料の中身にも平鍋さんたちが関わっているけれど、そんなことは関係ないぐらい、とても中身が充実していて、とても勉強になると思う。

IPAが書いたアジャイル開発の研究会報告書: プログラマの思索

アジャイル開発の契約スタイルに関するIPAの報告書: プログラマの思索

IPAから日本のアジャイル事例報告: プログラマの思索

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

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

また、もう一つ忘れてはならないのが、2008年頃から急激に認知され始めたScrumの普及だろう。
XPが技術重視なのに対し、Scrumはアジャイル開発に関する組織や役割とそのプロセスに注目して、XPが発見した概念をより明確にフレームワーク化した点がとてもすごいと思う。
でも、日本におけるScrumの位置づけや歴史はあまり綺麗にまとまっていない。
日本のScrumとアジャイルの歴史の対応関係を誰か読みやすい文章でまとめてくれると嬉しいなと思う。

また、チケット駆動開発もそんな日本のアジャイルの歴史の一つに入っている。
平鍋さんの文脈では、PFのデジタル化の一手法としてチケット駆動開発が紹介されている。
でも、僕はチケット駆動開発はアジャイル開発のIT化だけでなく、アジャイル開発の一実装例としてうまく説明できるようにしたいと思っている。

TiDD:チケット駆動開発: ソフトウェアさかばに書かれているように、オブジェクト指向も最初はSmalltalkコミュニティから育まれ、プログラミング技術の一手法から、OOAのような設計技法、RUPのような開発プロセスまで発展した。
アジャイル開発も、ケントベックが現場で編み出した開発プロセスの一つの手法として提唱され、PFのような管理職層向け、リーンソフトウェア開発のような経営者向けまで拡張された。

チケット駆動開発も最初は現場の一事例に過ぎないかもしれないけど、より多くの開発者と一緒に切磋琢磨して、ソフトウェア開発の次元を切り開けるようになったらいいな、と思っている。

| | コメント (0)

2012/08/13

DevOps~Webサービスの開発と運用の一体化という再パッケージングの概念

DevOpsという言葉を最近よく聞く。
DevOpsとは、Webサービスにおける開発と運用の一体化という意味で理解している。
感想をラフなメモ書き。

【元ネタ】
開発と運用の新しい関係、「DevOps」とは何か? - Publickey

DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 - Publickey

DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 - Publickey

[資料公開]Chefの下準備 (#DevLove Chef de DevOps) | Ryuzee.com

リーン・スタートアップが生む価値――「Just do it!」の無駄を省く

リーン・スタートアップが示す「5つの原則」

リーン・スタートアップの実践――ソニックガーデンは2度ピボットした

about DevOps… ≪ すでにそこにある雲

サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 - Publickey

Twitter / akipii: 「カバレッジは収穫逓減モデル」。メトリクスも同じ。ソフトウェアメトリクスは役立つがそれ以上ではないという指摘。右手に感情、左手に数値 - カバレッジを味方にしよう - t-wadaの日記 http://d.hatena.ne.jp/t-wada/2011120 …

Twitter / akipii: 開発=Developmentと、運用=Operationを組み合わせた言葉。開発と運用の新しい関係、「DevOps」とは何か? - Publickey http://www.publickey1.jp/blog/11/devops …

Twitter / daipresents: システムの計測として「Ticket system」というのが面白い StoryはPivotalで生産性として計測してTicketはムダの数って感じかな / “DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps…” http://htn.to/ydZBxw

Twitter / akipii: クラウドとはアジャイルインフラストラクチャの考え方から来た。DevOpsとはどんなもので、何が議論されているのか(後編) - Publickey http://www.publickey1.jp/blog/12/devops …

Twitter / akipii: Metrics Driven Developmentという考え方。チケット駆動開発もメトリクス収集ツールを基盤とするから適用できるはず。クラウドの登場でDevOpsは変わっていく、メトリクス主導へ - Publickey http://www.publickey1.jp/blog/12/devops …

システムの開発と運用の一体化という考え方は、業務システムの開発でも同様だ。
特にSIならば、苦労して新規開発した後、運用で定期的に保守料という形で現金を受け取り、売上を確保するビジネスが多いだろう。
では、従来のソフトウェア保守とDevOpsでは何が違うのか?

上記のpublickeyの記事を読むと、特にWebサービスの分野で、アジャイル開発やリーンソフトウェア開発、リーンスタートアップの概念を取り入れて、Webシステムを小刻みに開発しながら即運用していくビジネスモデルをサポートしているようだ。
DevOpsとは、Webサービスの開発と運用の一体化のアイデアであり、従来のソフトウェア保守の再パッケージングの概念とも言える。

僕が注目する内容は二つある。
一つは、信頼性の要件のうち、MTTR(障害修復時間)を重視すること。

DevOpsを実践する企業に共通すること。DevOps Day Tokyo 2012 - Publickeyには下記が書かれている。

(引用開始)
運用については、MTTR(Mean Time to Repair)つまりどれだけ早く復旧できるかが大事になっている。壊れることを予期しておくことが大事だ。
(引用終了)

つまり、HDDやネットワーク機器などは定期的に壊れることを前提として、復旧時間を短くできるように運用体制を整えておくこと。
また、ソフトウェアの障害修正や機能追加を定期的にアップデートできるような仕組みを取り入れておくことで、頻繁なVerUpができるアーキテクチャに設計しておくこと。
すなわち、壊れないシステムを作る発想よりも、素早く修復できるシステムの方が価値があるという考え方へ根本的に変わっている事実がある。

アジャイル開発のアイデアを製品開発、Webサービスへ発展させる: プログラマの思索

障害を故意に起こさせるツールで耐障害性を高める: プログラマの思索

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

特に最近は例えば、iPhoneや携帯のソフトウェアアップデート機能のように、ソフトウェアのアップデートだけでなく、OSそのもののアップデートも可能になったため、MTTRを短くするという考え方を実現しやすくなった状況がある。
また、たとえ壊れたとしても、信号機が壊れた時に必ず赤信号に倒すという例のフェイルセーフ、子供が誤ってシステムを誤動作させても怪我をさせないという例のフールプルーフ(チャイルドプループ)、システムを冗長化して稼働率を維持するという例のフォールトトレランスなどのような耐障害性を持つアーキテクチャ設計が重要になってきている。

現代は、ハードウェアは所詮は箱物であり、その中にあるソフトウェアやデータに価値があるのだ。
だからこそ、壊れないハードウェアを作るよりも、定期的に進化し続けるソフトウェアの方が重要になってきている。

もう一つは、DevOpsを支えるためのツールが揃ってくると、メトリクスが重要になってくるという話。
ここでは、従来のソフトウェアメトリクスではなく、リーンソフトウェア開発やリーン生産のアイデアを用いて、サイクルタイムやフィードバック時間、デリバリ効率などのメトリクスを収集して、開発チームにフィードバックし、運用を改善していくことを目指している。

DevOpsによるビジネスの改善をメトリクスとして計測する方法。DevOps Day Tokyo 2012 - Publickeyの記事を読むと、リーン生産のアイデアを用いるだけでなく、メトリクスに上限と下限を用いる管理図も使っているようなので、色々アレンジしているように見える。
そして、ここからMetrics Driven Developmentのような考え方が出てくる。
つまり、改善のヒントになるようなメトリクスを収集していくことによって、ノウハウを蓄積し、継続的イノベーションが行えるような環境を整えていくこと。

多分、チケット駆動開発もこの流れの上で運用することも可能だろう。
例えば、運用中に発生した障害やインシデント、問合せを全てチケットに記録して定期的に集計することで、直近の傾向やリスクを分析でき、そこから運用を改善していくこともできるだろう。

DevOpsについても色々探してみる。

| | コメント (0)

2012/08/12

アジャイル開発のアイデアを製品開発、Webサービスへ発展させる

最近、アジャイル「ソフトウェア開発」の考え方をソフトウェアの領域から製品開発やWebサービスのビジネスへ発展させようとする流れがある。
僕はリーンスタートアップもリーンソフトウェア開発も正直理解していない。
考えたことをラフなメモ書き。

【元ネタ】
Twitter / akipii: アジャイル開発とは相異なる専門技術者が顧客を巻き込んでチームを形成し漸進的にシステムをリリースしていくこと。 RT @smec925: アジャイル生産とは、コアコンピタンスをもつ複数の企業が連携して、特定の顧客のために高品質の製品をスピーディーに開発し、限られた量を生産する方式

アジャイル生産とは ~ exBuzzwords用語解説

リーン・スタートアップが生む価値――「Just do it!」の無駄を省く

リーン・スタートアップが示す「5つの原則」

リーン・スタートアップの実践――ソニックガーデンは2度ピボットした

【1】「リーン・スタートアップ」が最近、経営者の間ですごく流行している。
2012年現在の日本では、ほとんどの業界の大手企業の売上高も頭打ちか、むしろ大幅減少の時代。
だから、新規ビジネスに挑戦して売上高を増やして行かないといけないのに、毎年のように環境がめまぐるしく変わる状況では、従来のような5年、10年のような長期計画を立てても評価のしようがない。
せいぜい、2~3年の中期計画を立てて評価するしか、経営ノウハウを貯めようがない。

すると、リーンスタートアップのように、新規ビジネスを小さく始めて、マーケットの動向を見ながら、少しずつ改良を重ねてビジネスを大きくする手法が経営者は欲しくなってくる。
倉貫さんが最近盛んに提唱されているリーンスタートアップを使ったWebサービスのビジネス手法、平鍋さんが提唱されるリーンソフトウエア開発もこの流れになるように思える。

僕が以前読んだ本で、アジャイル開発を製品開発へ発展させようとした優れた本は「アジャイルプロジェクトマネジメント」だ。
アジャイルプロジェクトマネジメント」では、アジャイル開発の概念を流用して、最小限のプラクティスからアジャイルに製品開発するために必要な結果を生成できる、という信念で書かれている。
だから、アジャイル開発とビジネス、製品開発の違いが逆に分かりにくかった。

アジャイル開発の基本的な考え方は、日本の製造業が従来行なってきた多重下請構造から生まれたとよく言われる。
アジャイル生産とは ~ exBuzzwords用語解説にあるアジャイル生産の考え方は、下請け会社の部品を元請け企業がいかに効率良く自社製品の製造に使うか、という発想から生まれたように思える。

【2】上記の記事を読むと、アジャイル開発の概念に慣れている人ならば、リーンスタートアップはアジャイル開発のアイデアとマーケティングの概念をミックスさせた手法のように思えてしまう。
でも、従来のアジャイルソフトウェア開発とリーンスタートアップは何が違うのか?

リーンスタートアップで特徴的な概念は「MVP」「ピボット」という二つがある。
MVPはminimum viable product:実用最小限の製品。
このアイデアは、必要最低限の機能をリリースすべきであり、不要な機能は思い切って削ってシンプルにすべきだ、というXPの計画ゲーム、Scrumのプロダクトバックログを連想させる。
最初は小さく、徐々に大きく製品開発していく場合、最初から時間と労力をかけてリリースするのはリスクが大きいからだ。

ピボットは製品・サービス開発の方向転換のこと。
アジャイル開発では頻繁に現状を計画へ反映して変更して、実施しながら改善していく。
リーンスタートアップでは、マーケットの動向を見ながら、仮説検証スタイルで製品開発の方針を変えていく。
その時、計画を変更して実施していくタイミングをピボットと呼んでいるようだ。
つまり、やみくもに計画変更していくのではなく、マーケティングの要素を絡めて計画変更しているようだ。
リーンスタートアップでは仮説検証スタイルがよく言われるが、仮説にマーケティングを注入して計画変更の理由を強化しているように思える。

【3】僕が理解できていないのは「革新会計(イノベーション・アカウンティング)」だ。
「革新会計」は従来の管理会計とは異なり、リーンスタートアップのビジネスの価値や評価基準を定めるものらしい。
そもそも、リーンスタートアップで成功するとは限らないし、すぐに価値が生まれるとは限らない。
最終的に花形製品や主力製品になった時、それまでの下積み期間をどのように評価すべきか、という観点が必要になってくる。

プロダクト・ポートフォリオマネジメントの考え方によれば、問題児→金のなる木→花形製品の流れで製品を成長させて、「金のなる木」から得た収益を「問題児」に投入して「花形製品」に育てるお金の流れが原則になる。
リーンスタートアップの製品は最初は問題児であるから、どのように早く金のなる木へ変身させていくか、が重要になってくるのだろう。

プロダクト・ポートフォリオマネジメント - @IT情報マネジメント用語事典

TOCでもスループット会計という概念を導入して、会計の評価基準を変えようとした。
同様に、リーンスタートアップでも、その概念に見合った会計の評価基準がなければ、とても小さいけれど利益が出ていない製品開発をいつまでサポートした方がいいのか、判断しにくいだろう。

リーンスタートアップについては色々考えてみる。

| | コメント (0)

2012/08/11

障害を故意に起こさせるツールで耐障害性を高める

Amazonクラウド上でわざとシステム障害を起こすためのツールChaos Monkeyの記事があったのでメモ。
故意に障害を起こして、サービス障害発生時の運用を想定するためのテストにも使えるだろう。
でも、開発者にとって障害がたとえ想定されるテストであったとしても、マゾっぽい気もする(笑)

【元ネタ】
サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 - Publickey

about DevOps… ≪ すでにそこにある雲

Twitter / akipii: 故意に障害を起こして障害のフォローを想定したテストも可能になる。設計手法がどんどん変わりつつある。 サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 http://goo.gl/163yj

最近、Webサービスの開発と運用を一体化したDevOpsの概念が提唱されているが、実際の運用では、障害発生時の対応が非常に重要だ。
下手をすれば社会的信用を落とす。
だから、ITILなどの技法を取り入れて障害発生時のエスカレーション手順を厳格に定めたり、その手順をシステムテストなどで障害フォローの手順をテストしたりして、対処したりしているだろう。

最近の技術傾向を振り返ると、二つの特徴があるように思う。
一つは、監視ツールなどインフラをサポートするツールが普及してきたこと。
特にWebサービスはずっと稼働し続けるのが普通なので、障害を検知したり、ログをリアルタイムに解析したりするツールを導入して、インフラ管理をサポートするのが大切。

about DevOps… ≪ すでにそこにある雲というBlogでは、ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)
と言う本が紹介されている。
まだ読んでないので、機会があれば読みたい。

もう一つは、障害を起こさないようなアーキテクチャ作りも大切だが、むしろ、フェールセーフないしフールプループのような障害が起きたとしても安全なシステムになるようなアーキテクチャを重視するようにあらかじめ設計すること。
あるいは、メインのシステムがダウンしても、待機系のシステムがすぐに稼働して、通常の業務に支障が出ないようにシステムを冗長化(フォールトトレランス)すること。

つまり、障害が起きた時に重大な事故を起こさないように安全な運用に倒すフェールセーフ、初心者がシステムを誤動作させても安全に保つフールプルーフ、システムの冗長化というフォールトトレランスな設計が重要になっている。
これは、セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)でもよく言われていたことだ。

セーフウェアが必要な理由~ソフトウェアが凶器になる時: プログラマの思索

フォールト・アボイダンスからフェイルセーフ、フォールト・トレランスへ: プログラマの思索

障害が起きないような高信頼性のシステム作りよりも、障害がたとえ発生したとしてもすぐに修復できれば、稼働率を変えることなくWebサービスを運用することができる。
クラウドサービスが、HDDを使い捨てのように扱うことで、ハードディスクが定期的に壊れる前提で運用するように、このような発想のシステム作りが最近よく研究されているように思う。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

| | コメント (0)

2012/08/07

ソフトウェア部品化の幻想

@kuranukiさんと@yusuke_arclampさんのやり取りが面白かったのでメモ。
考えたことをラフなメモ書き。

【元ネタ】
ソフトウェア開発プロジェクトをとりまく6つの誤解?プログラミングを経験しないとわからないこと - Social Change!

「ソフトウェア開発プロジェクトをとりまく6つの誤解」は真実でもある - arclamp

「ソフトウェア開発プロジェクトをとりまく6つの誤解」をとりまく@yusuke_arclampさんとのやり取り - Togetter

僕はお二人とも知っており、尊敬している。
@kuranukiさんは自社のWebサービスを持つ経営者の観点、@yusuke_arclampさんはアーキテクトないしマネージャの観点で議論されている。
二人が経験されている現実をもっとぶつければ、何に引っかかっているのか、もっとはっきりするのになあ、と思ったりする。

@kuranukiさんの指摘は、現場の開発者の立場ではとてもよく理解できる。
違うコンテキストだが、ソフトウェアの品質特性について、従来の製造業の品質管理とは異なる観点が必要ではないかという意識を持って、下記を書いた。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

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

@kuranukiさんがあげた6つの誤解のうち、「既にあるソフトウェアを流用した方が速く作れる」「共通部品から先に作ることが出来る」は移植性、「ソフトウェアはハードと違って後から容易に直せる」は保守性の品質特性に強く関係する。

移植性の問題は、OSやソフトウェアの後方互換性、あるいは、ERPやパッケージ製品、組込製品のような製品系列のソフトウェアでよく出てくる。
ある顧客向けに作ったWebシステムの評判が良かった場合、他の顧客にも若干カスタマイズして販売すれば安上がりに売れるだろう、と思って開発するパターンはとても多い。
だが、ERPのような大型パッケージ製品は、カスタマイズという名のデスマーチ案件が非常に多い。

また、MicrosoftのOffice製品のように、PersonalベースからProfessional、Enterprise向けに機能を追加して価格帯を変えて販売するようなソフトウェアプロダクトラインをやっている会社も多い。
だが、このようないわゆる派生開発は意外に難しく、プログラミング工数はほとんどないのに、テスト工数ばかり膨れ上がる案件が非常に多いだろう。

清水吉男さんが提唱されているXDDPという派生開発プロセスでは、移植性や保守性という品質特性を特に重視している。
移植可能なソフトウェアでなければそもそも派生開発がとてもやりにくいし、カスタマイズしていくに従って保守性がどんどん悪くなっていくからだ。
だから、派生開発の要件に、保守性という品質特性も入れるべきだ、という主張をされているが全く同感。

移植性は再利用性とも密接に関係する。
共通部品は再利用できるからこそ「共通」部品なのであり、数多くの顧客や長年の本番運用で使われているから品質が保証されている。
しかし、ERPの部品のようなビジネスオブジェクトのレベルの部品はなかなか再利用できるほどの品質にも使い勝手にもならない。
EJBやCORBAなど今後流行するだろうと言われた再利用ソフトウェア部品は、結局使い物にならなかった現実がある。

その理由は下記の記事にうまく書かれている。

「ソフトウェアの部品化」が失敗する理由 - @IT

共通部品の開発、そして再利用できるほどの品質保証、そして、再利用できる部品開発を支える経営資源の確保まで幅広く問題が横たわっている。
個人的には、ソフトウェアの品質特性の中では移植性が一番難しく、移植性の難しさがソフトウェアの特徴をうまく言い当てているように思っている。

| | コメント (0)

2012/08/04

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない

森崎さんのBlogを読んで、ソフトウェアもエントロピー増大の法則を避けられないのだなあと思った。
だが、ソフトウェアはハードウェアとは違う特徴がかなりあると思う。
考えたことをメモ書き。

【元ネタ】
ソフトウェア保守の法則(リーマンの法則)、ご存知ですか?:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ

バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ

Googleのバグ予測アルゴリズム: プログラマの思索

リーマンの法則とは、上記記事にもある通り、ソフトウェア保守に関する経験則。
元々は5つあるそうだが、「ソフトウェア工学・システム工学ハンドブック―エンピリカルアプローチによる法則とその理論」によれば次の3つにまとめられると言う。

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

リーマンの第1法則は、よく使われるシステムはVerUpによって変化させられることを示す。
第2法則は、ソフトウェアのVerUpによって、ソフトウェアもエントロピー増大の法則から逃げられないことを示す。
第3法則は、ソフトウェアの変化やVerUpは、ユーザの声やハードウェアなどの環境の変化を取り込むことによってその方針が決まることを示す。

いずれも考えてみればあたり前のことだが、経験則としてまとめることによって、一つの知識として捉えることができる。
上記の3つの法則を読むと、改めてアジャイル開発がその法則をうまく取り込んでいるように思える。

アジャイル開発では「変化を抱擁せよ」の言葉があるように、ソフトウェアの変化を前提として受け入れる。
WF型開発が仕様凍結をキーワードとして、変化しない環境で開発するように持っていくのとは別の発想だ。

そして、ソフトウェアの変化は通常はVerUpによってもたらされる。
VerUpの理由は様々だ。
例えば、WindowsOSのVerUpに対応したり、新しいiPhoneに対応したり、機能を新規追加したり、致命的なバグを修正したり、など。
だが、Googleのバグ予測アルゴリズム: プログラマの思索にも書いたけれど、直近に頻繁に修正しているほどバグが埋め込まれている可能性が高い。
バグ修正のソースが、実は新しいバグを埋め込む危険性は実は非常に高いという事実が経験則として知られている。
Googleはその経験則を元に、バグアルゴリズムを作った点が素晴らしい。

さらに、ソフトウェアのVerUpの方向性を決めるためには、周囲からのフィードバックが大きな条件になる。
ユーザからの要望が高い機能、ユーザが見つけた致命的な障害は修正・反映する方が、ソフトウェアの価値が上がる。
ソフトウェアが動く環境、つまりWindowsOSやiPhoneがVerUpしたならば、それに合わせてVerUpした方がより高速になるし、使い勝手も上がる。
ビジネス環境が突然大きく変化したならば、以前決めたVerUpの機能も見直して、大胆に不要な機能を削って、別の機能を追加したりしたいものだ。

つまり、ソフトウェア開発ではフィードバックプロセスをいかにコントロールして、どの機能拡張や品質改善をソフトウェアに反映していくか、という仕組みがとても重要。
オープンソースソフトウェアの開発では、熱心なユーザの力を利用して、β版として新機能を使ってもらったり、問題の早期発見や問題修復を手伝ってもらう仕組みがある。
それは、ソフトウェア開発の特徴をうまく利用していると思う。

同様に、商用のパッケージ製品やWebサービス、受託開発でも、その仕組みをうまく利用したいものだ。
アジャイル開発では、XPのオンサイト顧客、Scrumのチーム/スクラムマスター/プロダクトーナーという組織体制などのように、ソフトウェア開発の組織体制にも従来のハード製品の開発とは違った仕組みを取り入れようとしているように思える。

色々考えてみる。

| | コメント (0)

2012/08/03

AWSで使うRedmine ALMinium

RedmineプラグインALMiniumを元に、AWSへインストールするスクリプトAWS-ALMiniumが公開されていたのでメモ。
これは面白い。

Twitter / angelndxp: Redmineを開発者向けカスタム済みで一発展開できるソリューション「ALMinium」を、AWSで高信頼に運用するスクリプトを開発しました。AWSの応用例です。GitHubで公開しています。 http://bit.ly/OGPYKZ

Twitter / angelndxp:@LightningX ALMiniumがもともとAmazonLinux上に「一発展開」できるものだったので、勝手にパラメーターを上書きすれば、高信頼運用に化けないか?と思って作ってみました。BitNamiや、ClouFormationのRedmineより使えますよ。

angelndxp/AWS-ALMinium

軽量チケット開発ツールALMinium

クラウドの本質はインフラ管理のIT化: プログラマの思索

AWS MarketplaceでRedmineも動く: プログラマの思索

(引用開始)
<これは何?>
 GitHubで公開されているRedmineを一発展開できるOSS「ALMinium」を、Amazon S3、Amazon RDS、Amzon SESを利用して高可用構成にしよう!というものです。 リポジトリ保存ディレクトリと、FilesディレクトリがS3に、データベースがRDSに、システムメール配信がSESに変更されます。使うには各リソースの事前準備が必要です。
<事前準備>
Amazon EC2のAmazon Linuxインスタンスを立ち上げてください。(64ビット、スモール以上を推奨)
Amazon S3のバケットをあらかじめ準備しておいてください。
Amazon RDSを、MySQLでセットアップしておいてください。
Amazon SESをセットアップし、メール認証を完了させておいてください。
(引用終了)

Redmineのインストールが難しいと言う人は多い。
色んな原因があるだろうが、OSやライブラリのバージョンとRedmineのバージョンが微妙にずれているためにうまく起動しない場合をよく聞く。
本来は、綺麗なCentOSなどLinuxのサーバーに初期設定からクリーンインストールするのが一番安全だろう。
普通は、ALMiniumを使って、Redmineに必要なRubyやMySQL、RubyGemsをワンクリックでインストールすればいい。

でも、初期設定のクリーンなLinuxサーバーを用意できない場合も多い。
既にRubyやMySQLなどがインストールされている環境では、それらをアンインストールして入れ直す手間がかかる時もあるだろう。

Redmineのようなツールを苦労せずにインストールしたいなら、仮想VMないしクラウド上にインストールするのが手っ取り早いと思う。
仮想VMなら、環境をいくらでも複製できるので、失敗したとしても以前のバックアップから作り直せばいい。
また、綺麗なOSが入った仮想VMからALMiniumでインストールすれば、楽にインストールできるはず。

その意味では、AmazonEC2上にRedmineをインストールするスクリプトであるAWS-ALMiniumはとても興味深い。
クラウド上だから、初期状態のインスタンスを用意すれば、AWS-ALMiniumでワンクリックでインストールできる。
そして、クラウド故に、スケールアップも簡単だ。
ディスクが増えたら増やせばいいし、CPUが足りないならもっと増やせばいい。
物理的にハードディスクやメモリ、CPUをいじらなくても、自動的にスケールアップしてくれる。

Redmineのデータを移行したり、Redmineをバージョンアップしたいなら、別のインスタンスを作ってデータ移行を検証したり、別のインスタンスで新しいバージョンのRedmineを試験運用してもいい。
つまり、クラウドならインスタンスを複製したり、新規作成が簡単なので、環境構築後の検証がやりやすい利点がある。

Webサーバーのようなインフラは自前で保つ必要はなく、クラウド上で管理する方が運用も楽になるし、スケールアップもやりやすい。
従量制課金だから、使った分だけコストを支払えばいいのも魅力。

ALMiniumとAWSの組み合わせは色んな可能性があると思う。

| | コメント (0)

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