Redmine開発者会議

Twitterで、Redmine開発者会議が4/30に開かれると言う呟きが流れていたのでメモ。

【元ネタ】
Redmine - DevMeetings - Redmine

Redmine - Proposal: Regular Meeting of Redmine Contributors - Redmine

詳細は良く知らないけど、IRCで全世界のRedmineのデベロッパー、コントリビューターたちが議論するみたい。
興味がある人は参加してみてはどうだろうか？

「派生開発カンファレンス2010」開催案内

派生開発XDDPのカンファレンス案内があったのでメモ。

【元ネタ】
「派生開発カンファレンス2010」開催案内

派生開発が必要とされるSW開発の対象は、組み込み製品やパッケージ製品などが多いだろう。
最終的には、ソフトウェアプロダクトラインのような製品ファミリー開発でXDDPは威力を発揮するだろうと思う。

製品ファミリー開発で最も成功した製品は、AppleのiPod/iPhone/iPadファミリー、MSのOffice製品だろう。
優れた製品があれば、その製品をプラットフォームとして、次々に似たような製品群を作り出していくビジネスモデル。
つまり、品質要求の中でも保守性や移植性を重視する開発が多いだろう。
XDDPは、そんな開発スタイルのヒントになるだろうと思う。

テストコードとソースの対比

テストコードとソースの対比について良い記事があったのでメモ。

【元ネタ】
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行 － Publickey

実際の稼動プログラムに対し、テストコードの方が行数は多くなる。
単体テストでも全ての分岐を網羅するだけで本数は増える。
更に、結合テスト、受入テストなど各種の観点も含めれば更に激増する。

テストコードは実際は殆ど似たようなロジックが多いから、テストデータを作りこむ作業に手間がかかる時が多い。
結局、プログラムを書いている時間よりもテストデータを作りこんでいる時間の方が長くなる。

テストの重要性は分かっているけれど、どこまで品質を作りこんで保障するのか、工数とのトレードオフだ。

RedmineのWikiに図面を入れる

PlantUMLで書いたUMLの図、graphvizで書いたネットワークのような図をRedmineのWikiに図面を入れるプラグインがある。
以下メモ。

【元ネタ】
Tracのwikiに図面を入れる（PlantUML編） - Basic

Redmine - Wiki External Filter plugin released - Redmine

MOONGIFT: ? テキストで記述して図に出力するUML記法「PlantUML」:オープンソースを毎日紹介

PlantUML

redmineの wikiマクロで graphviz その1 - あぁ そうだった

redmineの wikiマクロで graphviz その2 - あぁ そうだった

redmineの wikiマクロで graphviz その3 - あぁ そうだった

UMLのダイアグラムをWikiに貼りつけて、システムのアーキテクチャをメンバー全員あるいは新規加入したメンバーに読んでもらいたいと思う時がある。
そんな時に、上記のようなプラグインがあると便利。

PlantUMLやgraphvizでダイアグラムを出力するテキストを書いておけば、どこでも同じような図を出力できる。
画像ファイルではなく、画像ファイルを作るためのソースを管理すればいいので楽だろう。

僕は、Astahでさくっとラフに書いて、PNG出力したダイアグラムをWikiへ添付している。
色んなやり方があるので、各チームにあったツールを使えばいいだろう。

Agile2.0時代で必要な技法を示唆している資料

デブサミ2010に参加出来なかったけれど、Agile2.0時代で必要な技法を示唆している資料がSlideSareで公開されていたのでリンクしておく。

その資料は、Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティスとアジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点-の二つ。

Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス from 玉川憲 (Ken Tamagawa) - Amazon Web Services

アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- from Satoshi Masuda

これら二つの資料はとても示唆に富む。
チケット駆動開発を実践して、アジャイル開発の特徴や利点、その弱点、そして進化の方向をぼんやり考えていたけれど、上記二つの資料で、こういう概念だったのだな、と気付かされた点がたくさんあった。
「スクラムオブスクラム」「アジャイルリリーストレイン」「アジャイルテスト」のキーワードは必須。

考えたことは後で書く。

何故ファシリテーションが流行しているのか？

平鍋さんが提唱したPF(プロジェクトファシリテーション)やファシリテーションがじわじわと広まっている。
何故皆が興味を持っているのか、どんな方向へ進化しようとしているのか、メモ書き。
＃あくまでもラフなロジカルでないメモ書き。

環境がPFやファシリテーションを必要としている。
その理由は二つあると思う。
一つ目は、専門家集団による共同作業という仕事のスタイルが増えた事。
二つ目は、リーダーの資質、必要なスキルが変わった事。

それらの問題意識から、人間系の各種技法が生まれたように思える。

【1】前者は、時代がそうさせている。
特にSW開発は専門家集団による新製品開発だ。
実際、同じ製品を作る事はまずない。
しかも、プロジェクト形式だから、短期間に次々に新技術を使いこなしながら、新製品を作っていく。
つまり、短期間のうちに専門家集団をチームとして機能させなければならないが、この作業が非常に難しいのだ。

専門家同士はお互いの事を良く知らない時が多い。
業務に強い設計者、Webプログラミングに強い開発者、デザイナー、WebサーバーやDB構築が強い人、など色んな技術を持った人が集まるから、他人が作った成果物をチェックできない時も多い。
だから、互いの信頼関係、他人に作業をお願いできるような協調関係が重要になってくる。

どこかの本で読んだけれど、このような状況は、アメリカの宇宙開発事業で生まれたらしい。
有人飛行などのプロジェクトで、物理・化学・ハード・ソフトなど各分野の専門家がチームを形成して、プロジェクトを立ち上げて、成功させなければならない。
だが、チームビルディングというプロセスを踏まないと、お互いの信頼関係が生まれないだけでなく、いつまで経っても共同作業によるアウトプットが出てこない。

この例から生まれたモデルが、タックマンモデルだろう。
タックマンのチームビルディング(組織進化)モデルでは、チームは形成・混乱・統一・機能・散会の5つのプロセスがあり、混乱を経てようやくチームは期待通りに機能してくる、と言われている。

PFは特にソフトウェア開発のチームビルディングに特化したプラクティス集であると言える。
PFでは、ニコニコカレンダー、KPTによるふりかえりなど、色んなツールが出てくるけれど、いずれもチームビルディングに役立つツールが多いというのはそれが理由なのだろう。

【2】後者は、リーダーのステレオタイプがカリスマ的な権威者から、利害関係者の間の調停者という役割へ変わったことだ。
以前は、たとえ小さなチームのリーダーであっても、経験やスキルの高い人が選ばれて、リーダーによるトップダウンのマネジメントが中心だったように思う。
しかし、今は、チームのメンバーはそれぞれの分野の専門家であり、特定の分野ではリーダーよりもスキルが高い人が多数集まって構成されている。
そのような専門家集団をマネジメントするには、リーダーの資質は、チーム内の専門家の間で発生する問題を調整し、信頼関係を通じて作業を指示する方向へ変わっているのが実情だろう。そうでなければ、自分よりも優れた専門家をチームのゴールへ目を向けさせることはできないだろう。

すると、リーダーの役割は、調停者と言う役割が強くなってきている。
リーダーの役割は、専門家にチームのゴールを意識させて共有させることだ。各専門家が別々の考えを持っていたとしても、チームとしてアウトプットを出すために、ベクトルを同じ方向へ向いていればいい。
実際、ファシリテーターの役割を持つリーダーは、権威主義的ではなく、周囲の人達に働きかけるやり方が必要になってきたのだろうと思う。

【3】そして、今後のファシリテーションの進化の方向は、スケールアップにあるように思う。
チームビルディングに特化するのではなく、チームメンバー以外の顧客や上司などのように、チームがコントロールできない集団や人間関係へ影響力を広げることができる技術を探ろうとするだろう。
チーム内の調停者の役割に特化するだけでなく、チーム外にいる顧客や上司も含めた人間関係にもファシリテーションの技術を応用して、より影響力を広める方向へ進化したいだろう。

PFやファシリテーションの最近の動向を見ると、何となくそんな気がする。

営業支援ツールSugarCRM

OSSの営業支援ツールにSugarCRMがある。
見つけた記事をメモ。

【元ネタ】
＠IT：SugarCRMの簡単なカスタマイズ（1/3）

【コラム】Yet Another 仕事のツール (88) SugarCRM - オープンソースで「ほう・れん・そう」 | エンタープライズ | マイコミジャーナル

[ThinkIT] 第1回：オープンソースCRM『SugarCRM』 (1/3)

PHP＋MySQLで作られている。
インストールは、BitNami :: SugarCRMから行うのが一番簡単だろう。
日本語化もされているようだ。

SugarCRMはまだ使いこなせていないけど、顧客情報を一括管理できるだけでなく、営業マンがどの顧客に対してアプローチしてどれだけの効果が出たのか、をダッシュボードで集計する機能などがある。
SugarCRMによって、営業活動の履歴を残して集計して、営業の精度を高めるのに使いたいのだ。
OSSなので、Redmineのように営業支援のベストプラクティスもあるだろう。

今の僕は、ツールによる開発プロセスの改善、業務の改善に興味を持っている。
我々IT技術者は受託開発によって、顧客の業務をシステム化する。
システム化すると、顧客の業務が変わるだけでなく、組織構造まで変わってしまう。
システム化によってデータの流れが変わり、ワークフローも変わり、権限も変わり、人員も不要になったりしてしまうからだ。
つまり、システム導入は単なるIT化ではなく、組織構造まで変えてしまう劇薬なのだ。

同様のことが業務支援ツールにも言える。
Redmineによって、SW開発のプロジェクト管理が劇的に変わり、現場リーダーの役割さえも変わる。
チケット駆動開発によって、現場リーダーのメインの仕事は単なるExcelのスケジュール保守ではなく、開発チームの作業方針を決める意思決定であると痛烈に変わる。

テスト管理ツールTestLinkはテストチームの作業そのものを変えるし、ビルド管理ツールHudsonもライブラリアンの仕事を劇的に変えてしまう。
営業支援ツールSugarCRMも多分そうだ。

ソフトウェアは単なるツールではない。
ソフトウェアを無意識に導入すると、当初の目的とは異なる副作用を起こすかもしれないのだ。
つまり、ソフトウェア導入と運用プロセスはセットで考えるべきなのだ。

簿記のオーディオブック

業務SEの必須スキルは、DBやモデリングだけでなく、会計の知識も必要だ。
以前、渡辺幸三さんから、SEは簿記3級の知識は必須ですよ、と言われた時がある。
又、大前研一や勝間和代も、英語・IT・会計は現代人の必須スキルと言っている。

業務システムで簿記の知識が必要になってくる理由は、業務システムは最終的には会計システムであるからだ。
つまり、日々の業務で行われるお金に関する取引データは、仕訳として起こされて、最終的には損益計算書や貸借対照表へ出力される。
業務システムでかき集められた業務データは最終的には、損益計算書や貸借対照表を作るためにあると言っても過言ではない。
そのために、残高補正や棚卸など決算期特有の業務がある。

そして、会計の知識が必要な理由は、単に業務システムを作るために必要であるだけでなく、管理職や経営者になる場合、日々の活動がどれだけの利益を生んでいるか、を分析して、上司へ説明するためにも必要だ。
だから、マネージャになると、嫌でも会計の知識は必須になってくる。

簿記は、3級は個人商店、2級は株式会社や製造業、1級は管理会計と幅広い。
簿記3級の知識は、個人商店の会計だからとても簡単だが、日々の仕訳から損益計算書や貸借対照表の作り方まで教えているから、初心者にとってハードルが高い。
仕訳→総勘定元帳→合計残高試算表→精算表→損益計算書や貸借対照表という流れを自力で計算できなければ、複雑な金融システム、例えばクレジットカードシステムなどは作れないだろう。

簿記のルールは、初心者には分かりにくい。
何故こんなルールなのか、説明がないからだ。
借方、貸方という概念も福沢諭吉が作ったけれど、実際に損益計算書や貸借対照表を作るときにはその概念の意味は殆ど無関係だ。
この辺りの説明は、渡辺幸三さんの本「業務別データベース設計のためのデータモデリング入門」の最後で触れられている。
会計の仕組みは、物理の法則とは違って、所与されたルールに従って、仕訳を切り貼りして損益計算書や貸借対照表を作るためにある、と。
「業務別データベース設計のためのデータモデリング入門」は業務SEにとって、とても分かりやすい本なのでお勧め。

簿記で最も基本的で重要な概念は、仕訳だ。
日々のお金のやり取りをすぐに仕訳に起こすことができれば、後はルーチンに従って、現金勘定なり、合計残高試算表なり、作ればいい。
勝間和代の本「無理なく続けられる 年収10倍アップ勉強法」によれば、会計士試験でも、仕訳を半年間徹底的に勉強したから一発で通ったと書いてあった。

簿記3級に出てくる勘定科目は決まっているので、それらの仕訳パターンを覚えるのが最短ルートだと思う。
本で勉強してもいいが、「音簿記」という簿記のオーディオブックがとても素晴らしいのでメモしておく。
30パターンの仕訳を解説してくれているので、通勤電車のお供にできるし。

“音”シリーズ　簿記・シスアド・宅建・FPに続き行政書士・社労士が新登場！ - 資格の総合スクール - LEC東京リーガルマインド

とは言え、ITが普及した現代は、仕訳パターンマスタにこれらの仕訳パターンは登録されているので、キーワードさえ覚えいれば、パートでも仕訳できる仕掛けになっている。

そして、会計システムとして経理業務がIT化された現代では、仕訳伝票・出金伝票・入金伝票のような紙でちまちまと仕訳を残す会社はもうないだろう。
会計システムでは、毎日の仕訳を日次バッチで自動仕訳して、リアルタイムに損益計算書や貸借対照表を出力できるようになっている。
しかも、部門単位やプロジェクト単位で損益計算書や貸借対照表を出して、社内の組織をコントロールしたり評価したりする管理会計の流れが主流になっている。
だからこそ、中間管理職はまるで中小企業の社長みたいに大変なわけだ。

この辺りの流れは、「グラス片手にデータベース設計 ~会計システム編 (DBMagazine SELECTION)」の本がとても分かりやすい。
DB設計の注意点も書かれているので参考になる。

Redmine CSV Import Pluginの使い方

プロジェクト立ち上げ時には、Redmineへ新規チケットを大量にimportしたい時がある。
Redmine CSV Import Pluginを使えばいいけれど、使い方に結構癖があるのでメモ。

【元ネタ】
Redmine CSV Import Pluginを試す - フジハラボ -- 目指せ！スーパーエンジニア

There are No Perfect Redmine

juno's redmine_importer at master - GitHub

僕はRedmine CSV Import Pluginを日本語化しているjuno's redmine_importer at master - GitHubを愛用している。

新規チケットをインポートする場合、下記のようなCSVをインポートすればいい。
但し、幾つかの注意点がある。

【新規チケットをインポートする場合のCSVの内容】
ステータス,プロジェクト,トラッカー,優先度,題名,担当者,カテゴリ,Target version,起票者,開始,期限,進捗 %,予定工数,説明
新規,project_main,バグ,通常,ハード障害,admin,カテゴリA,バージョン1,admin,2010/04/21,2010/04/22,0,16.0,ハードの障害です。

・CSVは、UTF8＋LFが無難。
・1行目はヘッダ。2行目以降にチケットの属性を書く。
・「プロジェクト」は、Redmineのプロジェクト設定画面で、ユニークなプロジェクト名を設定した時のプロジェクト名。上記では「project_main」
・トラッカー、ステータス、優先度などは、Redmine管理画面で設定した値。
・カテゴリ、バージョンはRedmineのプロジェクト設定画面で登録した値。
・担当者、起票者は、ユーザのログインID。つまり、ログインするときのID。上記では「admin」。
・日は「yyyy/MM/dd」でないとインポートしない。

そして、Redmine CSV Import Pluginの確認画面では、CSVのヘッダ行とチケットの全ての属性を関連付けた方がいい。

Redmineへ間違ってインポートしても、チケット一覧画面でコンテキストメニューを表示すれば、簡単に複数チケットを一括変更できるから便利。
試してみて欲しい。

【告知】第42回SEA関西プロセス分科会「セーフウェア～システム安全とコンピュータ」

～～　第42回　SEA関西プロセス分科会のご案内　～～

テーマ１：セーフウェア ～ システム安全とコンピュータ
講師　　：松原 友夫 （松原コンサルティング）

テーマ２：ソフトウェア開発を多角的視点から考え直す
　　　　　　～ソフトウェア開発における美学原理、無形労働、要求開発
講師　　：岸田 孝一 （株式会社SRA 最高顧問）

主催　：ソフトウェア技術者協会 関西支部 プロセス分科会

日時　：2010年05月08日(土) 13:30～17:00

会場　：大阪市立大学文化交流センター
　　　　〒530-0001　大阪市北区梅田1-2-2-600
　　　　大阪駅前第２ビル６階　ホール
　　　　Tel　06-6344-5425　/　Fax　06-6344-5524
　　　　周辺略地図

内容　：

SEA関西プロセス分科会もスタート以来7年を経過し、通算40回を超える分科会を開催してきました．これまで10回毎の区切りとして、第10、20、30回は、複数の講師を招いての記念イベントとしてきました．昨年末の第40回については、通常の分科会としての開催となりましたが、次回の第42回は改めて「40回超記念」として、松原友夫さん、岸田孝一さんのお二人を講師としてお招きすることとなりました．
松原さん、岸田さんからは、SA関西プロセス分科会の発足当時より様々な御助力、アドバイスをいただきましたが、今回の講演では、ソフトウェア開発のあり方を改めて根本的に見つめなおす機会としたいと思います．

松原友夫さんからは、システムの安全とコンピュータ、ソフトウェアの関わりについて御講演をいただきます．
松原さんはコンピュータの関わるシステムの安全性に関する決定的な名著である"Safeware"（日本語版タイトル「セーフウェア　安全・安心なシステムとソフトウェアを目指して」）の翻訳・監修に携わられ、先年出版されました．
様々な分野でソフトウェアシステムが安全面でも極めて重要な要素なった現在、ソフトウェア開発に従事するものとして、システムの安全性に対してどのように関わり、取り組むかは開発者一人一人にとっての重要な課題となっています．
今回の講演では、Safewareが投げかける課題を中心にシステムの安全性について我々ソフトウェア開発者が何をなすべきか、松原さんの豊富な経験を踏まえての問題提起・提言をいただきます．

岸田孝一さんからは、ソフトウェア開発のあり方を、単に技術的・管理的な観点に留まらない、多角的な視点からの考察を促す内容で講演をしていただきます．
SEA関西プロセス分科会発足当初より岸田さんからは、ソフトウェア開発をプロダクト中心ではなくプロセス中心の観点から考えること、ソフトウェアシステムを完結したものではなく環境・社会に組み込まれた（Embedded）ものとして捉えること、ソフトウェア工学の観点だけに限定せず、美学、認知科学、社会学など多角的な視点で考察することなど、様々なアドバイスをいただいてきました
今回の講演も、このような視点から、ソフトウェア開発のあり方を根本的に見直す契機となる議論が展開することを期待しています．

なお、今回は会場にて、松原さん翻訳・監修による「セーフウェア」日本語版の割引販売を行います．
定価5,880円の３割引きの4,116円で会場での販売を行いますので、未購入の方は是非ご利用ください．
（申込み方法については、下記「申込方法」をご参照ください．)

プログラム
　13:30 - 14:30 講演1　セーフウェア～システム安全とコンピュータ
講演内容：
コンピュータの利用がミッションクリティカルなシステムに及ぶに従い、重大で広範囲な被害をもたらす事故が増えています。また、事故の原因を特定するのが困難になり、同じ原因の事故が、繰り返し発生しています。セーフウェアは、コンピュータに関わる事故の発生原因とその予防についてまとめた技術体系です。内容は幅広い分野にわたっていますが、その概要について、お話したいと思います。入門のつもりで聴いて下さい。
　14:30 - 14:40 質疑応答

　14:40 - 14:50 休憩

　14:50 - 15:50 講演2　ソフトウェア開発を多角的視点から考え直す
講演内容：
・E.Parrish が論文「教育システム設計における美学的原理」　で展開したアイデアをソフトウェア開発管理に読み替えたら　どうか.
・C.Floyd が指摘したパラダイム・シフトが現実のものになり、　無形労働としてのソフトウェア開発の本質が明らかになって　きた現在、要件開発にさいして我々は何を考えるべきか．
・B.Nuseibeh & S.Easterbrook の論文“Requirement Engineering:　A Roadmap” (ICSE2000)に提示された要求工学革新のための　3つのアイデアについての考察

　15:50 - 16:00 質疑応答

　16:00 - 16:10 休憩

　16:10 - 16:40 オープンディスカション

参加費用：
　SEA正会員：1,500円，SEA賛助会員：1,500円，
　学生：1,000円，一般：3,000円

定員　：120名

申込方法：
　以下のペ‐ジからお申し込みの受付を行っております．
　
　### 05/06（木）までにお申し込みください ###

　書籍「セーフウェア」日本語版を定価5,880円の３割引きの4,116円で会場にて販売致します．
　ご購入希望の方は、申込みフォームの最後の「分科会のテーマに関するご要望などをご自由にどうぞ」の欄に「セーフウェア書籍購入希望」とご記入下さい．
　（複数ご購入の場合は「セーフウェア書籍３冊購入希望」の様にご記入下さい．）
　現金引き換えにて当日お渡しします．
　（お釣りが不要なようにご準備お願いします．）
　★注意★
　　　出版社との手続きの都合上、セーフウェア購入での参加申込みは04/25（日）までにお願い致します。
　　　また、欠席で当日お渡しできなかった場合は後日発送させていただきますが、送料はご負担願います。

　ご注意）
　・受付は先着順で，定員になり次第〆切とさせていただきます．
　　申込受付後のキャンセルは原則としてお断りします．
　・メール，FAXなどWebページ以外からの申し込みは受け付けておりません．
　・お申し込みの受付け後，確認メールが自動的に返送されます．
　　確認メールを印刷し，当日受付時に持参ください．
　・申し込み手続きについて不明点などございましたら下記までご連絡ください．
　　
　・参加費は当日会場受付にて現金でお支払いください
　 領収書が必要な方は，申し込み時に「領収書要」にチェックしてください．

アジャイルテストの４象限

「実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)」を抜粋している良い資料があったのでメモ。

アジャイルテスト -高品質を追求するアジャイルチームにおけるテストの視点- from Satoshi Masuda

XPが提唱するテスト駆動開発(TDD)は確かに素晴らしいプラクティスだが、テストはそれだけではない。
テストの自動化が有効な箇所は、単体テストや結合テストなど、開発者視点の機能テスト。

TDDだけに視点が偏ると、ユーザの観点の受入テストや性能要件を評価する負荷テストまで意識が届かない。
受入テストはTestLink、負荷テストはJMeterなどのツールが別途必要になるだろう。
テストケース管理、テスト結果の管理まで考えれば、TestLinkがアジャイルテストの４象限全てで必要になるだろう。

The Haskell Road to Logic, Maths and Programming

形式手法とアジャイル開発を絡めた手法を試している人もいる。
形式手法を使える状況は、VDMのように設計工程で仕様の整合性のチェックに使うか、SpinやLTSAのようにテスト工程で状態遷移図を使ってデッドロックのバグを見つけるのに使うかだろう。
つまり、設計書の品質向上に使えないか、下記で色々模索したが、自分の中では消化できてない。

形式手法とHaskellについてメモ: プログラマの思索

Haskellの環境づくり: プログラマの思索

とある方から、形式手法ではなくHaskellでもやれるよ、と「The Haskell Road To Logic, Maths And Programming (Texts in Computing)」という本を聞いたのでメモ。

PDFも無料で公開されている。

The Haskell Road to Logic, Math and Programming

論理式や形式手法を使うのは正直楽しくないが、Haskellで仕様を書くならば、関数型プログラミングの勉強にもなる。
ちょっと読んでみようと思う。

Haskellを勉強するなら「Real World Haskell―実戦で学ぶ関数型言語プログラミング」がサンプルが多いので便利。

Real World Haskell (jp)で日本語版が公開されている。

チケット駆動開発が楽しい瞬間

まちゅさんの記事を読んで思ったことをメモ。

【元ネタ】
「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06)

今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました - SiroKuro Page

「申請書を書いて上司の判子もらわないと svn commit すらできない」場合もある - まちゅダイアリー(2010-04-06)のような状況は、僕も経験した時がある。
本番ソースはRational Clearcaseで厳格に管理されているため、開発チーム内部ではSubversionでソース管理していた。
そして、全て出来上がったら申請書を出して、承認してもらった後、全員で手分けしてClearcaseへ一括コミットする。
やりにくくて仕方ない。

まちゅさんの言う通り、ソフトウェア開発で厳格に管理すべきワークフローを間違えているのだと思う。

ところで、Redmineでチケット駆動開発を運用し始めて楽しいと思う瞬間は2つある。
一つは、チケットをどんどん消し込んで、ロードマップ画面でイテレーションの進捗率が上がっていく場合。
最初はたくさんのチケットを一括インポートするから進捗は0％だが、皆で手分けしてチケットをCloseしていくと、毎日の進捗は少しずつ上がっていく。
毎朝と退社間際にロードマップ画面で、取引線がたくさん付けられたチケットを見るのが楽しい。

もう一つは、新しいワークフローを見つけて、新しいトラッカーを追加した場合。
現状のワークフローでは作業しにくい、という話が上がった時、どのステータスを追加するか、どのようなフローにするか、議論して、ワークフロー設定画面でトラッカーを追加する。
そして新しいトラッカーをメンバー全員に説明して、運用してうまく回り始めると、やった！と思う。
何故なら、新しいワークフローを身に付ける事で自分の開発スタイルのバリエーションが増えるからだ。
新しいワークフローは、現場リーダーの一つの武器になる。

僕の数少ない経験上、新しいトラッカーは、テストやレビューなど、二人以上の作業者が交互にペアプロしながら品質チェックするワークフローで生まれやすいように思う。
理由は、Redmineのデフォルトのワークフローでは、ペアプロのような複雑な作業フローは設定されていないからだ。

ペアプロで行うワークフローは、作業者とその作業をチェックする設計者の2人の作業になるので、そのチケットを消し込むのは時間がかかる。
しかし、このワークフローを使うべき工程では、ミスが許されない部分が多いから、厳格に管理する時が多い。
例えば、バグ修正＆検証、デザインレビュー(設計レビュー)など。

新しいトラッカーを見つける作業をしていると、ソフトウェア開発の業務分析をしている気分になる。
ソフトウェア開発は、新規開発もあれば、既存システム上の2次開発や保守、サーバーインフラの監視による運用保守など、色んな開発スタイルがある。
それぞれの開発スタイルでワークフローは違う。
どれだけワークフローを持っているか、が現場リーダーの手腕の見せ所。

我々IT技術者は受託開発で、顧客の業務を分析して、システム化する。
同様に、ソフトウェア開発の業務分析をきちんと行えば、どこを厳格に管理すべきか分かるはずだ。

Redmineのチケット登録をITILへ応用する

Redmineのチケット登録機能をITILへ応用するアイデアをメモ。

【元ネタ】
Redmine.JP | メールによるチケットの登録

Redmine for ITIL: プログラマの思索

Redmineでは、メールを送るとチケットに登録する機能がある。
この機能を使えば下記のように、ITILによる運用保守プロセスに応用出来る。

サーバーを監視するツールが、障害や異常を検知
↓
異常の内容を運用担当者へメールすると同時に、Redmineへ同じ内容をメールで送る
↓
Redmineのチケットが起票される。
更に同時に、Redmineチケットが起票された旨のメールが流れる。
↓
運用担当者はメールで異常を検知した後、Redmineチケットで障害対応の作業履歴を残す。
↓
障害対応後、RedmineチケットをCloseする
↓
月末にRedmineの集計機能を使って、障害分析を行う

障害検知と同時にRedmineチケットが起票されるのがミソ。
この運用フローを生かせれば、障害対応の作業履歴や障害分析に役立てることもできるはず。

Redmineのニコカレがいい感じ

Redmineのニコカレのプラグインredmine_niko_caleを見ると、アイコンがリアルでとてもいい感じ。
どんどんバージョンアップして良くなっているみたい。

【参考】
redmine_niko_cale-0.8.0.png

redmine_niko_cale-0.7.4.png

ニコカレは毎日付けると楽しくなる。
是非試して欲しい。

アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る

「アジャイル開発をスケールアップさせるには何が必要か？」という思索を深めている時に、とてもぴったり来た本が「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」だった。
「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」の本をざっくり読んでみて、考えたことをメモ。

【元ネタ】
Developers Summit 2010：CodeZine（コードジン）

Jazz 日本ユーザコミュニティ - デブサミ2010参加レポート「Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス」

Developers Summit 2010：CodeZine（コードジン）

なんかの日記: デブサミ2010 二日目にいってきた。

steps to phantasien(2010-02-20)

19-B-2 Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス／玉川憲 - しあわせプログラマ

「塹壕よりScrumとXP」

「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」の中で最も重要な概念は「アジャイルリリーストレイン」と「スクラムオブスクラム」だと思う。
アジャイルリリーストレインは、複数のサブチームのイテレーションの同期を取りながら、全コンポーネントを小規模リリースしていくこと。
まさに、複数の列車が同じ時刻表に従って同期しながら、同じタイミングで発車するイメージ。

スクラムオブスクラムは、複数のサブチームがある時、開発チームのリーダーであるスクラムマスターを集めたチーム。
スクラムオブスクラムはデイリースクラムと同様、各サブチームの状況や課題を報告し、サポートする。
この会議PMBOKのCCB、ITILのCABに似ている。
つまり、サブチームのリーダーが集まって、各チームの課題を棚卸する場に近い。

この2つが重要だと思う理由は、複数のアジャイルなチームを制御するには、お互いのイテレーション計画を同期して、サブチーム内で解決できない問題はもう一つ上の層で解決する仕組みが必要だからだ。
各サブチームのイテレーション計画がバラバラで統制が取れない場合、一つのチームの生産性が良くても、一番効率の悪いチームに巻き込まれてしまうから。
又、自チームで解決できない問題が出た時に、複数のサブチームのリーダーが互いに協力しあう場がなければ、すぐにチームは混乱するだろうから。

特にアジャイルリリーストレインが重要だと思うのは、組み込み製品の開発やパッケージ製品の開発でも、イテレーション計画の同期を取る状況がよく現れるからだ。
組み込み製品の開発では、HW開発チームとSW開発チームで、お互いにHWとSWを結合しながらテストしていくしかないが、その時に同期が取れないと、品質は安定しない。
パッケージ製品の開発でも、コンポーネント単位に開発チームが存在するから、全チームのコンポーネントの同期を取る時に、ビッグバンという結合テストでいつも大きな障害が発生しやすい。
だから、イテレーションの同期を取るのは非常に高度な技だと思う。

「塹壕よりScrumとXP」でも、スプリントの同期を取ることの重要性を述べている。

Redmineによるチケット駆動開発を導入すれば、更にアジャイル開発のスケールアップを支援できると思う。
僕なら、Redmineの複数プロジェクト機能を使って、各サブチーム単位で、タスク管理と課題管理の各プロジェクトをRedmineに作る。
日々の作業はタスク管理のプロジェクトで管理する。
チーム内で生じた問題や質問などは課題管理のプロジェクトにまとめて、チーム内で基本は処理するが、解決できない場合は、CCBやCABのような課題管理会議の場で、複数のサブチームのリーダーが議論して棚卸しする。
つまり、スクラムオブスクラムを実施して、一つの大規模プロジェクト内部で発生した各サブチームの課題を解決していく。

そして、Redmineのバージョン継承機能を使って、全チームへ同期すべきイテレーションを継承して、全チームに意識させる。チーム内では、同期すべきイテレーションよりも短いサイクルでイテレーションを回しても良い。
これによって、アジャイルリリーストレインを浸透させることができる。

最後に、RedmineのSubtasking機能を使って、ストーリーカードとタスクカードに親子関係を導入する。
ストーリーカードは顧客へ提供する価値の観点で集計できるし、タスクカードは開発チーム内部の詳細な進捗管理として集計できる。

これらの機能を使えば、大規模プロジェクトにアジャイル開発を適用させやすくなるだろう。
Redmineのエンタープライズ機能はアジャイル開発のスケールアップを強力に支援してくれるはず。

IBMの記事を読む限り、アジャイル開発のスケールアップに関してかなりのノウハウを持っているように思われる。
色々追いかけてみたい。

IPAが書いたアジャイル開発の研究会報告書

IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。
IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。
運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。
気になる文言をメモ。

【元ネタ】
情報処理推進機構：ソフトウェアエンジニアリング

調査報告書[1.68MB]

研究会報告書[924KB]

成果概要資料[702KB]

・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、このことはチャンスである。
↓
共通フレームは、経産省がまとめた日本版のIT標準プロセス。(←さかばさんの指摘を受けて修正)
共通フレームを作った人はアジャイル開発をどのように見ているのか参考になる。

・IBMやMicrosoft がALM (agile application life cycle management)の分野に出てきたのは、Rally やVersionOne がこのツール市場のリーダーになってきていて、世界的にも市場が広まってきたことが動機である
↓
IBMやMSが何故アジャイル開発ツールを積極的に販売しているのか？
時代の流れ。
マーケットの推移。

・当社ではWIP (works in progress) limit（仕掛り制限） の様なものを、Redmine で実装しようと試みている。また、この機能に内部統制要件も加えて、JSOX 監査にも対応出来るタスク・承認・証跡管理の統合ツールにしようとしている。

・どこまでやるかはあるが、SVN (Apache Subversion), Hudson, Maven (いわゆるCI環境)で出来るだろう。Redmine まで組み合わせれば、開発者のタスク数までトラッキング出来る。
↓
IPAの研究報告書からRedmineが出てくるとは意外だった。
アジャイル開発は、ホワイトボードやPostItなどのアナログでしかプロジェクト管理できない、と思われがちだが、チケット駆動開発を使えば、ソフトウェア開発プロセスそのものをIT化できて、開発そのものをより自動化出来るはず。

・現在、私は、添付の論文にある「形式手法のアジャイルへの適用」に、以前から興味をもち、勉強しているところである。
・FormalMethod のアジャイルの適用についてだが、有望な観点だと思う。
↓
一部の人達は形式手法の可能性を色々試している。
形式手法とアジャイル開発の関係は僕はよく知らないので、調査してみたい。

・韓国のサムスンSDS とLG CNS（韓国の２大SIer）にヒアリングに行ったととき、彼らは通常、システムを３回作ると言っていた。設計－開発－テストのプロセスを大きく３回繰り返している。
・(日本の)ソフトウェアの国際競争力に関して、関連業界団体が共同で試算した輸出入額（2000年まで）で計算すると、限りなくマイナス１に近い。つまりまったく競争力がない。
↓
ソフトウェア開発とハードウェアの開発の違いは、バージョンアップにあると考えている。
ソフトウェア開発は、1回のプロセスでドカーンと一発リリースすると必ず失敗する。
3回リリースして初めて品質も使い勝手も良くなる。

韓国が最近目立ってきているのは、ソフトウェア開発の特徴を熟知していて、ソフトウェアプロダクトラインのような開発スタイルの研究が進んでいるからではないかと思ったりする。
それに比べて、日本のSIは未だにWF型開発のまま、20年以上何も変わっていないのではないだろうか。

・IT 産業(特にSIer)は、知識集約型のはずなのに、あいかわらず労働集約型である。某米国IT ベンダの方にアーキテクトは育成するのか？」と質問したことがあるが、「育成なんてしない。だって、アーキテクチャ設計ができる人を採用するから。」という単純明快なご回答であった。
・私が気になっているのは１点のみ。日本式多重下請け構造のままで、世界と戦えますか？ということである。
↓
昔から言われている問題。
業界や会社が状況を変えるのは無理だと思う。
オープンソースやコミュニティがその状況を変える可能性を秘めていると思う。

僕はアジャイル開発こそ、ソフトウェア開発の特徴を最も表していると考えている。
つまり、システムを頻繁にリリースしてバージョンアップしながら、システムの品質も使い勝手も改善していくスタイルがソフトウェア開発なのだ、と。
そして、頻繁なリリースに耐えうる技術、プロセスを支える基盤の一つにチケット駆動開発があると確信している。

【公開】第13回すくすくスクラムIN大阪～スクラムを体感しよう第一弾～

XPJUG関西とすくすくスクラムの共催でセミナーが開かれます。
奮って応募下さい。

【元ネタ】
4月25日 第13回すくすくスクラムIN大阪～スクラムを体感しよう第一弾～

今回は関東を飛び出し、大阪で勉強会を開催します。
関東では見えない事や出会えない方と一緒に楽しく探求したい！

スクラム（Scrum）について探求されることはありますか。
スクラムは簡単に始められますが、やりかたやありかたは千差万別。
実は、スクラムは奥が深い。
素晴らしいスクラムもあれば、残念ながらそうでないスクラムもあります。
この差って一体、なんでしょうか。

スクラム（Scrum）について探求することで新たな知見がえられたり
もしかすると、あたなのチームや現場の活性化、現場改善のヒントが見つかるかもしれません。
一緒に、楽しみながら現場改善のヒントを探しませんか？
---------------------------------------

今回のすくすくスクラムのテーマは、「スクラムを体験しよう」
講師に（株）Odd-e Japan の Agile Coach : 江端一将（ebacky） さんをお迎えします。

内容は「各スクラムの基礎理論から、その理論を体験・探求するワークショップ」を行います。

1. 各スクラム基礎理論
2. その理論の体験・探求ワークショップ
3. その理論の振り返り
4. 1. ~ 3. を時間内繰り返し
5. 当勉強会全体の振り返り

参加資格は、一緒に楽しく現場改善を探求したいというお気持ちの方
知識なんて不要です。一緒に楽しくわいわい探求しましょう！
ぜひぜひ、お知り合いの方をお誘い合わせて、ご参加下さい。

Agile2.0は何を解決しようとしているのか？

Agile2.0について再考してみる。

【元ネタ】
第二期アジャイルムーブメント ～ アジャイル開発の商業的取り組み と Agile2.0 ないし 「２週目の世界」 について - kawaguti の日記　(id:wayaguchi)

XPが登場してアジャイル開発の利点は数多く知られてきた。
そして、多くの人達がアジャイル開発を現場で実践してきた。
しかし、アジャイル開発の弱点でよく言われるのは「アジャイル開発は大規模プロジェクトに適用しにくい。スケールアップが難しい」というもの。
実際、素のままのアジャイル開発では、サブチームが2個以上になると途端に難しくなるように思う。
又、その運用ノウハウも公開されていない。

そんな中、昨今は「2週目のアジャイル」「Agile2.0」と呼ばれる動きがあり、アジャイル開発が復権した流れが起きている。
僕の理解では2つの流れがある。
一つは、Scrumやリーンソフトウェア開発など、プロセス面からアジャイル開発を補強しようとする流れ。
もう一つは、Wikiや高機能化したITS、分散バージョン管理などのツール面でアジャイル開発を補強しようとする流れ。
当然、チケット駆動開発も後者の流れの一つにある。

前者では、Scrumの影響が大きい。
一言で言えば、ScrumはXPの計画ゲームをきちんとしたプロセスで表現したもの。
Scrumが導入した概念やプロセスによって、大人数のチームでも規律のあるアジャイル開発に取り組むことができる。
でも、Scrumがアジャイル開発に大きな影響をもたらした点は、イテレーション計画の作り方に一工夫がいるよ、という指摘にあると思う。
アジャイル開発を大規模プロジェクトでも適用しようとするには、イテレーション計画やリリース計画の作り方、そしてその運用に一工夫がいる。
Scrumの書籍はいくつか出ているけれど、それに関する内容はないので残念。

後者は、ツールが構成管理だけでなくプロジェクト管理やビルド管理など、ソフトウェア開発に関わる手作業の部分を自動化してくれる点に利点がある。
チケット駆動開発は、高機能なITSをアジャイル開発のプロジェクト管理に使おうという発想から生まれた。
最初は単純に、チケットをXPのタスクカードのように扱うことで、アジャイル開発のタスク管理を補完するだけだった。
けれど、チケット集計出力機能を強化すれば、チケット駆動開発はプロジェクト管理全般をサポートできる。
チケット駆動開発はプロジェクト管理を効率化するだけでなく、現場リーダーの意思決定支援システムを目指している。
その意味には、たくさんの可能性が秘められているように思う。

チケット駆動開発も元々は5人ぐらいの少人数チームで有用だけれど、大規模プロジェクトではなかなか運用ノウハウがないのが実情。
しかし、Redmineがエンタープライズ系機能を強化している方向を見ると、大規模プロジェクトでも適用できるような仕掛けが隠されている。
例えば、無制限の階層構造を持つ複数プロジェクト機能、バージョンの継承機能、チケットに親子関係をもたらす機能などだ。
大規模プロジェクトにおけるサブチームの編成、サブチームごとのイテレーション計画の編成に、Redmineの新機能を上手く当てはめれば、大規模プロジェクトでもチケット駆動開発を運用できるだろう。
そうすれば、チケット駆動開発の最大の利点である強力なチケット集計機能を最大限に生かすことができるだろう。

僕が見るに、Agile2.0は初期のアジャイル開発で克服できなかった問題「アジャイル開発のスケールアップ」を解決する方向へ進化しているように思える。
このテーマについてもっと考えてみたいと思う。

【追記】
かおるんさんのBlogで「『Agility@Scale（アジャイル開発のスケールアップ）のポイント』＠玉川さん」の紹介記事があり、みんな同じようなことを考えているんだろうな、と思う。

Tech Fielders セミナー東京[Agile Day 2]でLTしてきました #msagile - かおるんダイアリー