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

2012年10月

2012/10/30

Jenkinsのジョブフローを可視化

Jenkins勉強会で川口さんがJenkinsのジョブフローを可視化する資料を公開されていたのでメモ。

Jenkinsが実現するソフトウェア開発の絶え間ない自動化 ? 楽天TC2012 レポート(13) | ManasLink - EM ONLINE

(引用開始)
最後に、JenkinsのジョブのワークフローをBPMN(Business Process Modeling Notation)というOMG標準の表記法で可視化し、複雑なワークフローの見通しを良くするプラグインが紹介されました。
講演の冒頭で川口さんは「自動化を行う上では、XMLやJSONのような機械処理可能なデータ形式とバッチ処理が重要」と話していましたが、複雑なプロセスを可視化したいという欲求は常にあるようです。人間にとって都合の良いグラフィカル表現と、機械にとって都合の良いテキスト表現。状況に応じて両者を使い分けるのがポイントのようです。
詳しくは、第6回Jenkins勉強会で川口さんが発表した資料『Jenkins User Conference @SF』を参照してください。
(引用終了)

JenkinsのジョブのワークフローをBPMNで可視化するアイデアは面白い。
ジョブのワークフローとは、詰まる所、バッチ処理のジョブネット図そのものだ。
バッチ処理は複雑な集計処理や集計結果の帳票出力が目的なので、それらの処理をワークフローでグラフ化できれば、理解しやすくなる。

このアイデアは、Javaソースからクラス図やシーケンス図などのUMLダイアグラムへリバースするリバース・エンジニアリングの発想と同様だろう。
つまり、Jenkinsで特定目的のジョブフロー(例:リリース&デプロイ処理、自動テスト結果の集計処理、Apacheログの集計結果と出力、など)をプログラムで作った後に、設計書の補足資料としてリバース・エンジニアリングしたBPMNがあればジョブネット図の代わりに使える。

Jenkinsをジョブ管理ツールとして使う手法はもっと研究されるべきものと思う。

| | コメント (0)

jenkins-testlink-plugin

jenkins-testlink-pluginのチュートリアルを見つけたのでリンクしておく。

【元ネタ】
Twitter / croquette0212: JenkinsとTestLinkの連携について丁寧に書かれているpdfみつけた。 http://tupilabs.com/books/jenkins-testlink-plugin-tutorial/en/book.pdf

TestLink Plugin - Jenkins - Jenkins Wiki

Automatizando Testes Com Hudson e TestLink

continuous-integration-with-hudson

Jenkins TestLink Plug-in Tutorial

TestLink Java API

Test management tool = TestLink

jenkins-testlink-pluginは、Jenkinsが定期的にJUnitなどの自動テストを実施して、その結果をTestLinkへ記録するプラグインのようだ。
アーキテクチャとしては、 TestLink にあるXML-RPC APIで記録するようだ。

(引用開始)
The TestLink plug-in integrates Jenkins with TestLink.
TestLink plug-in uses testlink-java-api to access TestLink XML-RPC API.
With the information that you provide in the build step configuration the plug-in retrieves automated tests from TestLink.
With the plug-in, you are able to execute build steps that call testing tools.
It reads TestNG, JUnit and TAP test report formats, used to update TestLink test cases' executions.
(引用終了)

テストケースの実行結果を管理するTestLink、自動テストを定期的なジョブで実行するJenkinsの組合せが面白い。

| | コメント (1)

2012/10/27

Redmineの性能を検証した事例~ITS応答性能の調査結果と対策編を読んで #RxtStudy

第6回RxtStudy勉強会で、@akahane37さんがRedmineの性能を検証した事例を公開されていたのでメモ。
とても参考になる。

Twitter / akipii: Redmineの性能を検証した事例でとても貴重。RedmineがIT企業の基幹系業務システムになっているなら必読。 情報システム部門のタスク管理~ITS応答性能の調査結果と対策編 @akahane92 http://www.slideshare.net/kakahane/rx-tstudy6 …

Redmineは、5人ほどの小さなチームの開発や運用のタスク管理をするのが当初の想定だったと思えるが、機能改善のおかげで、100人以上の大規模組織でも、1個のRedmineでタスク管理の運用が可能になった。

だからこそ、Redmineを末永く使えるようにするには、単なる機能要件だけでなく、検索結果の応答性能や、障害に強いか又は障害から回復しやすいかという可用性などの非機能要件も重要になってくる。
たいていの業務システムも、導入当初から数年はまともに使えて業務改善の効果も出るが、5年以上経つと、システムが重くなったりするなどの非機能要件から不満が出てくるものだ。

最近は、RedmineがSI企業の基幹系業務システムと化している所も多く、Redmineがダウンしてしまうと、開発業務に支障が出る所も多いのではないだろうか?
エンタープライズ向けの業務システムでは、非機能要件というアーキテクチャ設計がとても重要であり、しかも設計当初にきちんと考えていないと、後から修正するのはとても難しい。

上記資料で興味深い点は、Redmineの非機能要件に焦点を当てて、RedmineがIT企業の基幹系業務システムとしてどこまで使えるのか、を調査していること。

アプリケーションサーバーは、Apache+Passengerが安定しているが、Apache+Unicornの方が高速であるらしい。
他にも、一つのサーバーにRedmineやSubversionなどのツールを集中して、外部へのHTTPアクセスが増えないようにする方がよいらしい。

チケットを2万~200万件まで断続的に増やした場合、どこでボトルネックになるか、を調査している。
その調査結果では、チケットが20万件になると、全文検索が20秒かかるため、別の検索サービスなどを導入するなどの機能改善が必要になるという。
また、チケットが70万件を超えると、MySQLの起動に5分以上かかるらしいが、対応方法はある、とのこと。
そして、チケットが200万件を超えると、チケット一覧を表示する処理時間が倍以上に増えてしまうため、MySQLのBufferPoolを増やすなど、MySQLのmy.cnfを改良する必要があるらしい。

調査結果から以下の結論を出している。

(引用開始)
ITSの耐用検証(応答基準)まとめ:
ITSと連動した全文検索の解決策と、16GBのメモリがあれば200万チケットの運用に於いても日常的に使用する画面・機能において100ms前後の応答性能をRedmine2.0系で期待できる。
(引用終了)

この調査結果を読む限り、Redmineは全文検索機能がすぐにボトルネックになるが、それ以外の運用は、メモリ追加などのハードウェアのチューニングやMySQLやWebサーバなどのミドルウェアのチューニングで改善効果が見込める。
このような貴重なRedmineの事例が公開されているのはとてもありがたい。

| | コメント (0)

2012/10/24

Jenkinsをジョブ管理ツールとして使うアイデア

@akiko_pusuさんのJenkinsの事例を読んで、Jenkinsをジョブ管理ツールとして使うアイデアについて考えたことをラフなメモ書き。
間違っていたらあとで直す。

【元ネタ】
Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあと

Monitoring external jobs - 日本語 - Jenkins Wiki

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

【1】基幹系業務システムの命は、Cobolで書かれたバッチ処理だ。
Webシステムやクライアントアプリから収集された業務データ、売上データは、夜間にバッチ処理で一括集計されて、日次や月次の商品有高帳、損益計算書、貸借対照表などを出力する。
これらの数値をにらめっこしながら、経営者は日々の経営方針を微修正しながら経営していく。
だから、経営者は細かい売上データや利益データにうるさい。

バッチ処理のアーキテクチャは、ジョブネットが基本だ。
ジョブネットは、バッチ処理というジョブをカレンダーやスケジュールの実行順序で実施する仕組み。

ジョブネットとは【job net】 - 意味/解説/説明/定義 : IT用語辞典

Cobolプログラムを直列につなげたものの集合がジョブになり、ジョブをスケジュール通り実行する順番につなげたものがジョブネット図。
バッチ処理のアーキテクチャは、ジョブネット図をいかに固めるかが大事。

ジョブの流れは、直列であるとは限らない。
ジョブは分岐するときもあれば、逆に合流するときもある。

例えば、2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあとに書かれているように、出荷ジョブから商品出荷→在庫引当という流れもあるし、出荷→出荷種別確認という流れもある。
逆に、複数のジョブがひとつのジョブに合流する場合もある。

すると、スケジュールに従って各ジョブが実行されて、ジョブが分岐するのは良いが、合流する時、合流してくる両方のジョブが正常に終わらなければ、滞留したまま停止してしまい、ジョブが異常終了する時がある。

つまり、ジョブネット図は、プロジェクト管理で出てくるPERT図のように、ジョブには先行・後行関係が存在し、その制約によって表現されるものである。
並列処理してよいジョブもあれば、先行のジョブが終わらなければ次に進めないジョブもある。
バッチ処理のアーキテクチャでは、そのような制約をジョブネット図へ全て反映しなければ、想定した動きにならない。

【2】ジョブネットを制御するジョブ管理システムの製品は、Tivoli、A-AUTO、千手などが有名だろう。
これらの製品は、当初はメインフレームで生まれ、オープン化の流れによって、WindowsServerやUnix上でも使えるようになった。

IBM Tivoli - Japan

A-AUTO って何?: プログラマの思索

ジョブ管理、ジョブスケジューラなら「A-AUTO」 - 株式会社ビーエスピー

運用管理ソフトウェア:Senju Family:NRI

これら既成の製品とJenkinsを比較して、ジョブ管理ツールとして必要な機能を洗い出してみよう。

【3】Jenkinsをジョブ管理システムとして使う場合、何が必要で、何に注意すればいいのか?
まず、Jenkinsでジョブに相当するものは何か?
それは、SCMからビルドする処理や、ログ集計する処理など、一塊のバッチ処理。

Jenkinsでジョブネットに相当するものは何か?
それは、JenkinsのBuild Pipeline Pluginのように、一連のジョブを実行順序で並べて表示した機能に相当するだろう。

JenkinsとGitとSpockで独り継続的インテグレーション - Log for Backup - Naoki_Rinの学習

Jenkins でビルドパイプライン - エンジニアきまぐれTips

何もわからない / Jenkins でビューを色々いじると仕事が捗る #jenkinsci

しかし、Build Pipeline Pluginを見る限り、既成のジョブ管理システムのジョブネット修正ツールに比べると、機能は貧弱な点がある。
Jenkinsにジョブネットを表現し、制御できるような機能が追加されると良いだろうと思う。

また、バッチ処理で注意すべき点は、ジョブ同士でやり取りするデータ。
例えば、電文のような128byteとか512byteのような文字列のテキストファイル、またはCSVファイルやログのようなテキストファイル、またはRDBのテーブルだったりする。
この時、電文やCSVなどのテキストファイルの場合、データをソートしたり、集約化したりするなど、SQLでやる操作をプログラムで自作する必要があったりする。
Cobolのような原始的なプログラミング言語は、リスト処理がさほど強力でないので、正直実装しにくいと思う。
むしろ、PerlやRubyのようなスクリプト言語の方が実装しやすいと思う。

【4】ジョブ管理ツールの機能としては、ジョブのスケジューリング、ジョブの異常を検知するなどのジョブ監視、ジョブの実行ログを収集するなどのメトリクス収集機能があげられるだろう。

このうち、3番目のジョブの実行ログを収集したり集計したり表示する機能は、Jenkinsは十分に必要な機能が実装されている。
不足したメトリクス集計表示の機能は、簡単に自作できる。

ジョブのスケジューリングは、月末のMM月DD日実行とか、毎日HH時に実行などのジョブ実行をスケジュール化する機能。
この機能はCronに相当する。
つまり、ジョブネットで表現された各ジョブは、Cronで実行すればいい。

但し、実際の業務のスケジュールは毎月のように変わる。
業界や会社ごとに、営業日は異なるから、毎月のスケジュールをきちんと作ることは重要だ。
例えば、日本の会社は月に1回、請求締めで顧客から売掛金をまとめて回収したり、仕入れ代金を一括払いするから、それらをジョブのスケジュールに組み込んでおく必要がある。

従って、Cronをそのまま埋め込むのは多分保守しづらい。
既成の製品は、スケジュールをインポートしたりエクスポートする機能があるので、Jenkinsでもそのような機能があれば、例えば、開発環境で実施したスケジュル設定情報を本番環境へそのまま移行する作業が簡単になる利点がある。

ジョブの監視をJenkinsで実現するには、Monitoring external jobs - 日本語 - Jenkins Wikiを使えばよいらしい。

また、Jenkinsでは、ビルドエラーが発生したらメール送信する機能が元々あるので、ジョブの異常を検知したら即メールする機能へ流用することもできる。
つまり、異常検知を関係者へフィードバックする機能はJenkinsに既にあり、そのまま流用できるし、Redmineへメールを送信したら、チケットが自動登録されるような仕組みへ発展させることもできる。

但し、ジョブの数が多いと、ジョブ監視の実装をそれぞれ行うのは手間がかかる。
Jenkinsのジョブ監視の設定も、既存の製品のように、もっと手軽に実現できるとよいだろう。

【5】以上のようにJenkinsをジョブ管理ツールと見なす場合、流用できる機能は結構あるが、まだ不十分な機能も多い。
だが、JenkinsはOSSなので不足した機能は自作すればいい。

特に、JenkinsはGroovyというスクリプト言語と相性が抜群に良いので、Groovyを使って実装する方法もあるだろう。
Jenkinsのプラグインは数えきれないほどたくさん作られており、ネット上でノウハウも公開されているので、不足した機能は皆でどんどん作っていけばいい。

Jenkinsには、たくさんの可能性が秘められていると思う。

| | コメント (2)

2012/10/21

Redmine on JRuby part3~RedmineはJRuby+Tomcatで動かす方が簡単

別Blogを参考にして、Redmine2.1.2をwar化してTomcatに入れたら、すぐにセットアップできたのでメモ。
JRubyすごい!

【元ネタ】
u6k Apps開発ログ: Redmineをwar化 (1) とりあえずRedmine+JRubyを動かす

u6k Apps開発ログ: Redmineをwar化 (2) warblerでwar化する

u6k Apps開発ログ: Redmineをwar化 (3) Tomcat上で動作させる

redmine.warの作り方が分からない人は、以下からTomcat付きでダウンロードして、Tomcatを起動すればいい。
http://localhost:8080/redmine/ にアクセスするだけで、すぐにRedmineを試すことができる。

u6kapps / redmine-war / Downloads ? Bitbucket

上記のBlogを真似て自分もredmine.warを作ってみた。
Javaに慣れている開発者ならば、30分もかからないだろう。

【環境】
Windows7
JDK1.7.0_06-b24
JRuby1.6.8
Redmine2.1.2
Tomcat7.0.23

【JRubyのWebrickで動かす手順】
jgem install bundler --no-rdoc --no-ri

%REDMINE_HOME%\config\database.ymlを修正。
この例では、DBは、MySQLではなく、sqlite3にする。

production:
adapter: sqlite3
database: db/production.sqlite3

bundle install --without development test

cd %REDMINE_HOME%
rake generate_secret_token

rake db:migrate SET RAILS_ENV=production

jruby script/rails server webrick -e production

http://localhost:3000/
でアクセスすればOK。

【redmine.warをTomcatで動かす手順】
jgem install warbler

cd %REDMINE_HOME%
warble config

database.ymlの修正は上記と同じ。
warble.rbを修正
config.dirs = %w(app config lib log vendor tmp db files plugins)

warble

redmine.warができる

Tomcatのwebappsにredmine.warを配置する。
startup.batでTomcat起動。

http://localhost:8080/redmine/
にアクセスすればOK。
アクセスした設定画面は以下の通り。

Redmine212onjruby

3~4年前はJRubyでRedmineを動かすために四苦八苦していた。
その頃の試行錯誤は以下に書いている。

Redmine on JRuby: プログラマの思索

Redmine on JRuby part2: プログラマの思索

でも、最新のJRubyとRedmineを使えば、簡単にデプロイできる時代のようだ。

CentOSはRubyのライブラリが古いため、RPMを自作したり、gemのバージョン依存に苦しんだりしていまいがちだが、JRubyならば、JDKさえ入れていれば簡単に動く。
しかも、JavaのWebアプリケーションサーバーはどれも業務システムで10年以上の歴史があるので運用ノウハウも多いし、保守できる技術者も多い利点がある。

Redmineのバージョンアップに伴い、RubyのライブラリをVerUpするのは結構面倒だが、JRubyならば、JRubyのバージョンごとに作ればいい。
Redmineをwar化できるならば、Redmineのバージョンごとにwarを作って移行検証するのも可能になる。

今後のRedmineの動作検証は、Redmine on JRubyでやってみようと思う。

| | コメント (0)

Jenkinsをバッチ監視ツールとして運用する事例

@akiko_pusuさんが公開されたJenkinsによる運用事例の資料が素晴らしいのでリンクしておく。
Jenkinsはたった一つのツールに過ぎないが、たくさんの可能性を秘めていると思う。

【皆のつぶやき】
Twitter / 検索 - 20121019-jenkins-akiko_pusu.pdf

Twitter / udzura: 凄く心に響きました…… / “20121019-jenkins-akiko_pusu.pdf” http://htn.to/m5MjUJ

Jenkinsの元々の目的は、ソースのビルド管理だろう。
だが、「高機能なCron」という隠れた機能がある。
この機能を使って、Unixのパイプラインのように、定型的な処理をバッチ処理のジョブでつなげる。
すると、定期的に決まった日や時間帯に動くバッチ処理になる。
この発想は、日々のバックアップ処理や、サーバー間のデータ転送、ログ監視やログ集計などにも適用できる。

上記資料の中にあるフレーズがとても印象深い。
「それまで単純に個々のサーバのCronやバッチ処理という扱いだったものが、成果物を出すための一連の「ビルド」という考え方に変わっていきました」
「データソース=SCM」
「SQL・解析処理=ビルド」
「レポート=成果物」
「レポート配布=Continuous Deliverly」
「Continuous Deliverlyに近いのかな、と感じています」

最後の一文は、PMBOKで言うならば「実績報告プロセス」「情報配布プロセス」に同一視できるだろうと思う。
進捗・実績レポートをPM自らが配布するのでなく、システムで自動化する仕組みを作ってしまえばいい。

基幹系業務システムでは、バッチ処理はまさにシステムの生命線だ。
例えば、日次で日々の売上データを集計したり、月次で在庫を確定して、毎月の損益計算書や貸借対照表を出力する。
部門別やグループ別、商品別、補助科目別の試算表は、経営者が一番気にする部分だろう。
それらのデータを元に、経営状態を精査して経営方針を微修正していく。

経営者と同じように、サーバー保守の担当者も、日々の定型的作業をバッチ処理のジョブとしてプログラム化してしまい、Cronで実行するように自動化すればいい。
更に、ログを収集して、日時や月次報告の資料の元ネタになるように、整形出力してもいい。
毎月のログ集計結果から、リスクを検知したり、予防対策を立てることに役立てることもできる。

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

基幹系業務システムのバッチ処理は普通はCobolが今も主流だ。
でも、Jenkinsをバッチ監視ツールとして使う場合、AntやMavenやGradleのようなビルドスクリプトだけでなく、PerlやRubyのようなスクリプト言語の方が相性がいい。
なぜなら、テキストファイルを作成・削除したり、正規表現で検索・置換するなどの処理が多いので、スクリプト言語の方が書きやすいからだ。

上記資料は、ツールがプロセスを改善するだけでなく、組織も変えてしまう事例の一つとして興味深い。

| | コメント (2)

2012/10/20

【公開】第6回RxtStudy発表資料「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」 #RxtStudy

本日の第6回RxtStudy発表資料をCCアトリビューションライセンスで公開します。

【1】最初に断っておくと、本資料は完成版ではない。
TiDDを原則・価値・プラクティスなどで体系化した場合、どのように表現できるか、作業仮説として作成している。
だから、説明不足や不整合の部分もある。
特に、発表時間が25分枠だったため、言いたいことをかなり濃縮しているので、行間を読み取ってもらえると嬉しい。

体系化の方針としては、ツールに依存しないように説明することと、プラクティスをパターン言語で表現することに注力した。
TiDDはRedmineでもアナログでも運用可能であるし、そのような事例も既にある。
だから、ツールに依存しないように抽象化した概念でより普遍的に説明できないかと思っている。
また、プラクティスを特定の状況の問題に対する解決法として提示することによって、Aさんの現場では通用したプラクティスがBさんの現場では通用しない、という理由を綺麗に説明できるはずと思っている。

【2】TiDDの原則として「最初にチケットありき」「成果物は構成管理に従う」の2つをあげた。
TiDDはチケットとバージョン管理ツールが必須であり、その2つを前提として価値やプラクティスを展開しようと思っている。

チケットがツールやアナログによらない概念とすれば、それは一体どのように定義されるのか?
チケットは「プロセス」だと思う。
チケットは「タスク」「課題」「障害」などで種類分けされるが、それらはソフトウェアの変更に関わる対象プロセスと言える。

すると、プロセスには必ず「作業中」「完了」というステータスが現れ、それは状態遷移を形成し、それはワークフローと呼ばれる。
つまり、「チケットはワークフローに従う」。

従って、チケットはプロセスであるからには、チケットは成果物や仕様ではない。
成果物や仕様は、その変更履歴が重要であり、バージョン管理すべき対象のものだ。
つまり、「成果物は構成管理に従う」。

【3】構成管理とは一体何なのか?
この疑問はIT業界に入ってからずっと考えてきた。
何となく、構成管理がソフトウェア開発プロセスの本質に触れるような気がしていたから。

今は、構成管理はソフトウェアという資産を管理する仕組みだと思っている。

構成管理が資産を管理する仕組みならば、その資産の増減を記録する必要がある。
例えば、倉庫で在庫になっている製品や商品は、その資産の増減は商品有高帳で記録される。
ソフトウェアの変更はすべて記録する必要があり、「成果物は構成管理に従う」という原則になる。

また、資産は定期的にラベル付けされて、スナップショットが取得されて保存される。
例えば、在庫対象の製品や商品は、月次で締められて棚卸資産として計上されて、貸借対照表へ出力される。
リリース可能なソフトウェアになれば、リリースタグが付与されて、価値あるものとして顧客へ提供される。
つまり、「Iteration is Version」というプラクティスが出てくる。

構成管理は特にここ数年、ツールの進化が最も激しい部分であり、今皆が試行錯誤しながら新しい使い方を試そうとしている。
今流布しているプラクティスも、ツールの進化に合わせて、有効でない場面が増えたりしているし、逆に新しいプラクティスが生まれたりしている。
その部分の話は今日はできなかったけれど、またどこかで話そうと思っている。

【4】他にも書いたけれども、まだ作成中の部分が多い。
そして、西さんや他の人からも、フィードバックを受けた。
このアイデアをもっと成長させていこうと思ってる。

【追記】
第6回RxtStudyのTwitterログが以下で公開されている。

2012/10/20 第6回 RxTstudy まとめ #RxTstudy - Togetter

今後発表資料は、RxTstudyで公開されるでしょう。

| | コメント (0)

Redmineのガントチャート機能改善の要望チケット

@marutosijp さんがRedmineのガントチャートにイナズマ線を表示するパッチを投稿されていたのでメモ。
ラフなメモ書き。

【元ネタ】
Twitter / g_maeda: Redmineのガントチャートでイナズマ線を表示する、 @marutosijp さんによるパッチ。Redmine本体に取り込まれて欲しいので+1しといた。 http://www.redmine.org/issues/12122 pic.twitter.com/ivSmCEqf

Twitter / akipii: ガントチャートの進捗管理は日本のマネージャしか興味ないのかな? RT @g_maeda: イナズマ線パッチに対するJPLの反応が薄い。もしかして海外ではイナヅマ線はあまり使われていない? http://www.redmine.org/issues/12122

Feature #12122: Gantt progress lines (html only) - Redmine

Feature #3436: Show relations in Gantt diagram - Redmine

スケジュールを見ればマネージャのレベルが分かる: プログラマの思索

Redmineのガントチャート改善part2: プログラマの思索

MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmineをマネージャ向けに売り出す時の謳い文句の一つが、「チケットに登録してくれれば、ガントチャートを自動生成できますよ」。
そもそもガントチャートは、タスクの開始日・終了日・進捗率さえ分かれば表示できるビューに過ぎない。

だが、MS Projectに比べると、Redmineのガントチャートは貧弱だ。
MS Projectならば、先行後行(FS)関係や、イナズマ線、リソースグラフなども出力できる。

Redmineのガントチャートにイナズマ線を表示できる機能改善は、日本の開発現場でマネージャ向けに売り出す時に重要な機能の一つかもしれない。
#12122のコメントに、@marutosijp さんがこんなことを書かれている。

Gantt progress line needs in Japanese enterprise.
Customer always requires it to developer.

まさに、日本では顧客やマネージャがガントチャートにこだわっているといえるかもしれない。
@g_maedaさんも、MS Projectを引き合いに出してパッチの目的を説明されている。

Microsoft Project has same feature. Please check the following url for the description of progress lines.

しかし、JPLの反応はイマイチ。

I don't really see the benefit of this feature, maybe displaying precedes/blocks relations (#3436) would be a better option to start improving the gantt chart.

#3436はガントチャートの各タスクにFS関係の矢印を入れる機能改善のチケット。
そちらのチケットの方が良い選択肢かも、と言っている。
この機能は、redmine_better_gantt_chartプラグインで既に実装できているはず。
(但し、Redmineの最新版に対応しているかどうかは知らない)

個人的には、イナズマ線だけでなく、ガントチャートに曜日を表示したり、見栄えやUIに関する機能も改善して欲しいと思う。

MS Projectではガントチャートだけでなく、タスクの依存関係を表すPERT図や担当者の作業負荷を表すリソースグラフなども表示してくれる。
マネージャは、単なる線表だけでなく、タスクの依存関係や作業負荷も考慮しながら、プロジェクトの作業をWBSに落とし、精密化しながら、プロジェクト運営のイメージを描く。
新版 SEを極める50の鉄則 マネジメント編」の著者である馬場さんは、マネージャならば500ぐらいのWBS要素まで分割できなければならない、と言われていた。
リーダーやマネージャならば、それぐらいのマネジメント能力を要求されているのかもしれない。

個人的には、Redmineのガントチャート機能に限らず、Redmineのチケット集計機能はもっと改善の余地があると思う。
Tracの方が自分でクエリを書くことができる分、各種のチケット集計のビューを作り出せる利点がある。

他の人達は、Redmineのチケット集計機能をプロジェクト運営に有効に使えているだろうか?
アジャイル開発で使われるビューだけでなく、プロジェクト運営のそれぞれの場面で有効に使えるビューを洗い出し、どのように役立てるか、今一度整理してみたい。

| | コメント (0)

2012/10/15

市販のプロジェクト管理ツールが使いづらい理由

市販のプロジェクト管理ツールが使いづらい理由を的確に指摘しているつぶやきを見つけたのでメモ。
ラフなメモ書き。
【追記】@kaorun55さんから「 (TFSも使ってみてください)」のご意見もあり、文章を修正しました。

【元ネタ】
Twitter / process_ok: SPI JAPAN のメモ。ある発表でそのチームでRedmineを採用している理由として、「市販の管理ツールは、どうしてもそれを作った会社のプロセスの色が出てしまい、事情が異なる会社では使いにくい。その点Redmineは自由にいじれるのがいい」と言っていたのがよかった。

Twitter / sakaba37: 他のツールは開発した会社のプロセスが入っていて、定着しなかった。Redmineはシンプルで、色々出来るので続いている。チケットがきちんとできているかや、色々な可視化でのチェックもして、細かく言う。言ったらやってくれる。

Twitter / tanka_1976: SPIJapanで不在にしている間に、メンバがRedmineによるTiDDを実践していた! すべてのアクションがRedmineに集約され、やるべきことが見える化されつつある! 後は、管理者層が頭の中に持っている作業項目のみだ!#RedmineJP #TiDD

どんなソフトウェアにもプロセス(手順)が混じっている。
ソフトウェアを使いこなすには、そのソフトウェアの機能に沿った手順に、ユーザは必ず従わなければならない。
つまり、ソフトウェアの機能に込められた開発者の設計思想に、知らず知らずのうちにユーザは従属させられる。

WindowsPCしかり、CentOSしかり、iPhoneしかり、iPadしかり。
新しいツール、新しいソフトウェアは、従来のやり方とは違ったプロセス(手順、やり方)に慣れる必要があり、それに慣れなければ、期待する効果は出てこない。
逆に、ソフトウェアを使いこなすのが目的になってしまい、ツールに振り回されてしまう場合が多い。

市販のパッケージ製品、特にプロジェクト管理ツールが使いづらいと思う時が多い理由は、その会社のプロセスが組み込まれており、そのプロセスを取り入れるのが難しいから。
過去にたくさん出てきたCaseツールは特にそうだろう。

オープンソースのツールが優れている点の一つは、オープンソースのツールの機能に、数多くの開発者の要望を取り入れられているからだろう。
ユーザ自身が機能を追加したり改善するパッチをコミッタに送ってもいい。
特にGitHubが普及してから、PullRequestという手法によって、パッチを簡単に送付してマージするのが簡単になった経緯もある。
つまり、コミッタだけでなく、ユーザ自身もソフトウェアを「使う」立場だけでなく「改善する」役割を担うことができる。

オープンソースのコミュニティという場で、コミッタとユーザが有意義な議論を行って、ソフトウェアを漸進的に育てていく。
ソフトウェアのあるべき姿がアジャイル開発と重なっているように思える。

| | コメント (0)

2012/10/14

セールスとエンジニアのためのIT提案戦術~SIベンダーの営業方法

セールスとエンジニアのためのIT提案戦術」を借りて読んだ。
受託開発中心のSIで、顧客折衝が多いSEやシステム提案の機会が多いPMにとっては必須の本だろうと思う。
感想をラフなメモ書き。

【1】システム提案プロセスの問題

普通のシステム提案プロセスでは、発注者がRFIを作ってベンダーに提示し、ベンダーは実現するシステムの内容や見積金額をRFPで発注者に提案する。
日本ならば、ユーザ企業がITを使って経営革新や新しいビジネス戦略を行うための道具としてITを使いたいので、ベンダーにシステム構築だけでなく、ITを使ったソリューション、つまりコンサルティングも求める時は多い。
そして、SIが作ったシステムの運用保守もユーザ企業ではなくSI任せになりやすい。
だから、どうしてもユーザ企業がSIへ丸投げしてしまいがちという日本特有の特徴が出るように思われる。

システム提案プロセスの問題としては、ユーザ企業にとってもSIにとっても、お互いにWin-Winの関係を作るにはRFPをどのように作り、選定するためにどのように使うか、ということがあげられるだろう。
ユーザ企業は自分たちのビジネスに合致するシステム構築のために、どんな観点でSIベンダーを選定すべきなのか?
SIは、売上や利益のためだけでなく、顧客と共存共栄していくために、システム提案プロセスでどんな点に注意すべきなのか?

この本では、RFPをSIの営業が使う道具だけでなく、発注者がSIが書いたRFPを見抜く観点も提供している点で面白い。
特に、著者の経験談が含まれているケーススタディのコラムが断然面白い。
いくつか興味深い箇所だけ書き留めておく。

【2】慢心を詫び再構築を依頼する

ユーザ企業が既存ベンダーを見切るかどうかいつも見極めているよ、というお話。
あるユーザ企業のSCMは度重なるシステム追加で複雑化し、いつか抜本的な再構築が必要になると、開発を請け負ったSIは思っていた。
だが、なかなかSIからは過去の経緯もありずっと言い出せなかったが、ユーザ企業の動きに何やら不穏な動きがあるように見えた。
そこで、SIのチーム内で議論した所、意見が2分されたが、再構築する方向で提案することにした。
SIは再構築の提案をユーザ企業に持って行き、なかなか再構築を切り出せなかったお詫びと提案をお話した。
すると、ユーザ企業のマネージャは、実は既に4社ほど当たって、再構築の提案をもらっていた。その提案を貴社から来るのをずっと待っていた、と。

既存ベンダーはユーザ企業の基幹システムを一度作れば、なかなか離れられなくなるという自惚れを抱きがちだが、実はユーザ企業も賢いんだよ、という指摘。
逆に言えば、新規営業のベンダーも既存ベンダーの隙を狙う機会はある。

【3】RFIで受注ベンダーを絞り込む

ある部品メーカーの調達システムにおけるベンダー選定のお話。
そのシステムはかなり特殊な部品を調達管理するために、普通のパッケージ製品には向いていないということが分かった。
そういう事情を書かないでRFIをSIへ送ると、見当違いのRFPが届いて、ユーザ企業も困る。
そこで、RFIに、業務が分かる人向けにこういう特徴を持つEDIが欲しいと書いて、20社ほどのベンダーに送ってみた。
すると、各社のRFPは効果てきめんで差が歴然としていた。
ごく一般のEDIソリューションという的外れなRFPもあれば、見事に的を得たEDIソリューションを提供するRFPもあるし、こちらの業務の特徴や問題を推測してRFIに書かなかった部分まで提案してくるRFPもあった、とのこと。
しかも、RFPのうちの1社は、特注品に特化した調達EDIを扱う開発部隊を持っていたことまで分かったとのこと。

このケーススタディでは、ユーザ企業もRFIをきちんと書かかなければ、ユーザ企業の要望に本当に見合うSIは見つからないということ。
まさに人間のお見合いみたいなもので、いくら安い提案をされても、ユーザ企業の要望に釣り合わなければ、お互いが不幸になる。

【4】意外に多い的外れ提案

個別指導塾のユーザ企業に、教育ソリューションを持つ有力SIベンダーがシステム提案にやってきた。
ところが、その提案内容は、集合教育を想定したソリューションであり、ユーザ企業の要望に全く合致しておらず、座がいっぺんにしらけてしまった。
その原因は、ベンダーが今売り込み中のパッケージ製品を売るために、安易に考えて自分たちのソリューションを押し付けたのが真相らしい。
ユーザ企業にとっても、有力SIベンダーの脱落は選択肢を狭めてしまうということで痛い損失だった、と。

他業界の営業マンでも、顧客は欲しがっていないのに、自分たちの商品の押し売りはよく見受けられる。
当たり前とはいえ、SIの商品は数百万~数億円もする高い買い物だからこそ、的はずれな提案は禁物。

【5】良い提案書とは

以下の9つの条件があるらしい。
・形式要件を満たす
・依頼内容に対して正しく回答している

ここまでは最低ライン。

・RFPの漏れやあいまいさをフォローしている

付加価値の部分。
システムを実現する(フィージビリティ)上でどの部分が課題なのか、そしてその課題に対してどんな対策があり、その対策の効果はどう評価されるか、などを書くことが大事。
いわゆるアーキテクトの観点が重視される。

・具体性があり分かりやすい

差別化の部分。
特に業務系基幹システムは具体的な代物が想像しにくい。
「使いやすい」「処理速度が速い」「サポートが充実」などを具体的に分かりやすく実例や場面をRFPで説明するとよい。
アーキテクトの観点に含まれる。

・良い話だけでなくリスクも考慮している

バランス感覚の部分。
「動かないコンピュータ」という日経の記事が流行したが、夢の部分だけ語った提案書は嘘臭い。
システムを実現できたら、利点もあるが、逆にリスクや弱点もあるという観点もRFPに入れると、バランスが取れたものになる。
いわゆるアーキテクチャ設計のトレードオフの観点。

・よく考え、悩んだ形跡がある

信頼感、技術力の証明の部分。
できるSEは、要件を仕様化する時に、行間を読み解いて、実装方法だけでなく、仕様が矛盾したり不整合の部分を洗い出して突き詰めていく。
ユーザ企業の課題を完全に解決できる正解はないし、全てを解決しようとするのはコストや納期の観点で非現実的ということはよくある。
だからこそ、そういう試行錯誤を経たRFPは、苦心の跡を見つけることができ、プレゼンの場で鋭いツッコミに遭遇しても、ごまかしや言い逃れではない真摯な回答をしてくれるので、ユーザ企業も高く評価する。
まさに、アーキテクトやストラテジストの観点が重視される。

・見積金額の根拠に合理性がある
・熱意が感じられる
・お客様の視点で書かれている

これらも必須ポイント。

【6】実は当て馬ではなかった

複数ベンダーによるコンペは、当て馬になるSIや出来レースのコンペがあったりする。
特に、既存ベンダーが圧倒的に有利な立場にいる時は特にそう。
とはいえ、ユーザ企業の要望と釣り合いが合うSIが受注しなければ、お互いに不幸だったりする。

ベンダーA社はユーザ企業のシステムを20年もサポートしてきたが、最近いくつかの問題を起こした上に、ユーザ企業の信頼関係を損なっていた。
とある案件で、A社以外にも数社のベンダーがコンペに参加したが、どのベンダーも消極的だった。
著者はユーザ企業の立場でRFPの作成支援をしていたが、このままでは期待しているC社が脱落してしまうと懸念を抱いた。
そこで、著者はQ&Aの終了後帰り間際に、C社のリーダーの肩をしっかり掴み、あなたが思っている以上にお客様は貴社に期待していますよ、と囁いた。
すると、C社リーダーはびっくりしたものの、真意を察し、後日再びQ&Aの場で再提案した。
すると、その議論は白熱して、夜遅くまで及ぶ中身の濃い議論になった、と。

出来レースであっても、既存ベンダーとユーザ企業の関係は実は信頼関係が崩れていたりする。
営業ではよくあることだが、自分たちの技術力を示して、種を蒔いておくことは大事。

【7】リアルな見積が安さに勝つ

3社のコンペで、著者がリアルな見積り金額を提示して受注できたケーススタディ。
お客様はこっそり著者へ予算金額を伝えて便宜を図ろうとしたが、著者は何を思ったか、ちゃんと見積りを計算しますから大丈夫です、と断ったらしい。
著者は後で後悔したが、腹を決めて一からスケジュールを作り見積りを計算してみた。
4ヶ月の工程で、要件定義のヒヤリングはいつやって、どんなミーティングを開き、どんな成果物をどれくらい作るか、を具体的に現実的に計画を立てていくうちに見えてきた。

コンペでは、著者を含む3社ともお客様の予算の枠内の数値になったけれど、著者が受注できた。
後で聞くと、他のA社はお客様の予算金額に合わせてざっくり90%で見積り、B社は無理をしても受注したいがために値引きして合わせてきたらしい。
お客様に、著者がお客様の予算の枠外で高かったらどう判断するか聞いた所、著者が作ったRFPとその計画書はとてもリアリティがあり魅力的だったので、予算の枠内に収まる再提案をお願いしたでしょう。他の2社とは格が違っていたから判断しやすかった、と。

この話では、SIがリアリティのある見積りをすればお客様も理解してくれるし、逆にリアルな見積ができなければ、SIは最初から失敗案件を受注してしまうことを意味している。
お客様の要望に見合ったシステムを開発できる技術力を持つSIをお客様も欲しがっているし、システムの実現可能性(フィージビリティ)に見合った見積りでなければ、お客様もSIも不幸という指摘。

システム提案で改めて思うのは、システム提案は、ビジネスや業務に詳しいだけでなく、システムの実現可能性(フィージビリティ)を突き詰めて考えることができるアーキテクトの観点も必要なこと。
たくさんの技術の選択肢から最適なものを選択し、組み立てる能力が必要とされる。
他のケーススタディも興味深いので読んでみると良いだろうと思う。

| | コメント (0)

2012/10/12

【告知】第6回RxtStudyで「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」を話します #RxtStudy

第6回RxTstudyで「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)」を講演します。

【参考リンク】
第6回RxTstudy : ATND

RxTstudy公式サイト

第4回shinagawa.redmine勉強会 : ATND

【タイトル】
チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ(ダイジェスト版)

【概要】
先日「チケット駆動開発(TiDD)」本を先日出版し、他に入門Redmine 第3版が出版されるなど、日本の開発現場でTiDDが少しずつ実践されているように思います。
しかしながら、日々実践されているTiDDのノウハウは開発現場ごとにバラバラに散らばっていて、TiDD初心者が参考にしづらいように感じます。
本講演では、TiDDの経験知をパターン言語で体系化することで、TiDDを実践する時に頻出する典型的な問題やそれに対する解決策を分かりやすく分類して、利用できるようにするアイデアについてお話しします。

RxtStudyへの参加は、昨年夏の第1回勉強会以来になります。
今回の講演では、最近考えている問題「チケット駆動開発をパターン言語で表現すると、日本の数多くの現場で実践されているTiDDのノウハウをどのように形式知としてまとめることができるか?」について、そのアイデアの部分だけを話す予定です。

RxtStudyではわずか25分の講演なので、端折った内容は第4回shinagawa.redmine勉強会で話したいと思います。
興味のある方は、講演後でよいので、僕がまだ知らないけれど自分たちだけが持っているノウハウとかフィードバックについて聞かせてください。

| | コメント (0)

2012/10/11

Coplienの開発工程の生成的パターン言語を読むpart1

コプリエンの組織パターンを読み直している。
XPやScrumが生まれる前に、アジャイル開発の構造をパターンという形で既に明確に定義しているように思えた。
理解できたパターンをラフなメモ書き。
間違っていたら後で直す。

【元ネタ】
生成的開発プロセス・パターンランゲージ Introduction

生成的開発プロセス・パターンランゲージ patternindex.htm - info

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

パターンランゲージの形式と正当性: プログラマの思索

組織パターンとプロセスパターン: プログラマの思索

【1】組織と環境の依存関係

アーキテクチャは組織に従う Conway's Lawが一番有名だろう。
コンウェイの法則が出てきた由来としては、コンパイラを4つのチームで作ったら、4パスコンパイラで作られてしまい、複雑な構造になってしまった、という話が有名だ。

「もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。」という言葉は、アーキテクチャ設計が固まる前に大人数で開発に取り掛かると、その組織構造を反映した複雑なソフトウェアを作ってしまう、という意味だろうと思う。
つまり、アーキテクチャが固まるまでは少数精鋭で設計し、アーキテクチャが固まった後に開発チームを組むといいことを示唆しているのだろう。

他に組織と関連するパターンとして、組織は場所にしたがう Organization Follows Location組織は市場にしたがう Organization Follows Marketがある。

【2】組織に必要な役割

コプリエンの組織パターンで面白いと思った点は、象徴的な役割を抽出していること。
パトロン Patronとは、開発チームには擁護者が必要というパターン。
パトロンの役割は、「パトロンは進捗を妨げるようなプロジェクトレベルでの障壁を取り除く責任があり、組織の“戦意”(うまくいっているという感じ)維持の責任を持つ」。
開発チームを保護する経営者ないしプロマネが相当するだろう。

ファイアーウォール Firewallsとは、開発チームを邪魔する害虫から守る守護者が必要というパターン。
「この役割の責任は“病原菌を遠ざける”ことである」という言葉がとても分かりやすい。
スクラムマスタがその役割に相当するだろう。

門番 Gatekeeperとは、開発者・顧客・上司の間で情報を翻訳して説明する役割。
「この人は、外部からの最新の情報や雑多な情報をプロジェクトに関連する言葉に翻訳してプロジェクトメンバーに広める。(中略)この役割は、開発とマーケティングや全社管理組織とのインタフェースを管理することもできる。」という言葉から、ソフトウェアプロダクトラインのアーキテクトという役割を連想させる。
システムをユーザ目線で顧客価値の観点で話すときもあれば、開発者目線で実装レベルで話すときもあるし、上司にはコスト面やアーキテクチャ設計の観点で話すときもある。
それぞれの立場の人に複数の観点で情報を翻訳する能力を必要とする。

「ゲートキーパーは有用な情報の流れを促進するパターンである。一方、ファイアーウオールは価値のない情報の流れを制限する。」という指摘から、小規模チームではプロジェクトリーダーがアーキテクトの役割も担う時が多いため、プロジェクトリーダーは数多くの役割を果たさなければならない事が分かる。

【3】開発者の役割を重視

開発者はプロセスを統制する Developer Controls Processとは、機能別に開発者をプロセスの中心に置くこと。
つまり、システムの機能ごとに担当された開発者が責任と大きな権限を持つことを意味する。

「設計は作業全体のことであり、設計者と呼ばれるような役割はない。」「完全に理解できていない設計分野であり、開発にとって繰返しがキーとなっている。」というコンテキストから、設計・開発・テストのような工程ごとに分断した開発スタイルはソフトウェア組織に向いていないことを示唆している。
XPやScrumから始まったアジャイル開発では、開発者が開発チームの中心であり原動力であることを強調しているが、それはこのパターンでも裏付けられる。

【4】アーキテクトの役割

とはいえ、開発者とは異なるアーキテクトという役割もソフトウェア組織では必要とされる。
開発者はプロセスを統制する Developer Controls Processアーキテクチャ設計者は製品を統制する Architect Controls Productのパターンは表裏一体。
「経験的にいえば、彼らは危機的な状態を除けばプロセスを統制しているようには見えない。開発者はプロセスを統制し、一方、アーキテクチャ設計者は製品を統制する。」という言葉は、アーキテクトは正しい製品を作る役割であり、開発者は製品を正しく作る役割であることを示唆している。

「彼らは、要求仕様を理解し、システム構成の大枠を決め、その構成の長期的な進化を統制する責任を持つ。」という言葉から、アーキテクトはアーキテクチャ設計に大きな役割を持つ。

但し、この2つのパターンだけを強調すると、アーキテクトは開発チームでかなり大きな権限を持ち、開発者との間で緊張関係をもたらす。
そのため、アーキテクチャ設計者もソフトウエア実装に参加する Architect Also Implementsアーキテクチャをレビューしなさい Review the Architectureのパターンで、その緊張関係を柔らげるように組織パターンでは勧めている。
「全体主義的なアーキテクチャ設計者に対して恨みが発生することもある。このような傾向をやわらげるためには、アーキテクチャをレビューしなさいのパターンなどを利用しなさい。」

【5】名前が付けられた安定したバージョン Named Stable Basesは、ブランチ上のリリースタグやリリースバージョンを意味しているように思う。
「結合と結合の間の時間が長すぎると、以前の結合バージョンの制約により、開発者の進捗が滞ってしまう。」ために、1週間ごとにリリース可能な品質のバージョンを用意することを勧めている。
「安定の度合いに応じて、同時に複数個の結合バージョンを持つことが有効である場合がある。」
「例えば、あるAT&Tのプロジェクトは、毎晩ビルドし(コンパイルされたことが保証されているのみ)、週毎に結合テストのためにビルドし(システム全体に渡る確認テストが保証されている)、そして(隔週程度で)テスト完了版のビルド(QAのシステムテストに対しても十分安定なもの)を提供した。」

XPのイテレーション、Scrumのスプリントの源流は、このパターンにあるのではないか?
なぜなら、「変更が1週間に1回を超えないように、システムインタフェース(アーキテクチャ)を安定させなさい。システムインタフェース以外の部分についてはそれより頻繁に変更があってもいいし、結合されてもよい。」という言葉から、安定した開発を行うには、定期的な間隔でシステムインタフェース(アーキテクチャ)を安定させる必要があるからだ。
そうでなければ、デグレードなどの症状が多発して品質が劣化しやすくなり、いつまで経っても安定したソフトウェアにならないことを示唆しているように思える。

【感想】
僕はまだコプリエンの組織パターン42個を全て理解はしていない。
でも、幾つかのパターンを読んでみると、自分の経験上、過去にこんな場面があったな、とか、過去にこんな問題があったな、とか、過去にこんな解決方法を知っていればもっと明確に説明できたのに、というデジャブ(既視感)を感じた。

Scrum: 超生産的ソフトウェア開発のための拡張パターン言語を読むと、Scrumが編み出したスクラムマスタ・プロダクトオーナ・バックログ・スプリントレビュー・デイリースクラムが有効である理由は、組織パターンから説明できると簡単ではあるが概略が示されている。
読んでいてとても面白い。

【追記】
2013年1月にCoplienが来日するらしい。
時間が取れれば行きたいなあ。

Scrum Alliance Regional Gathering Tokyo 2013

【追記2】
2004年に続編「Organizational Patterns of Agile Software Development」が出版されている。

Organizational Patterns of Agile Software Development pdf free ebook download from artax.karlin.mff.cuni.cz

| | コメント (0)

2012/10/10

クラウドデザインパターン~インフラ方式設計のベストプラクティス集

AWSクラウドデザインパターンというパターン言語を見つけたのでメモ。

【元ネタ】
AWS-CloudDesignPattern

クラウドアーキテクティング原則 - AWS-CloudDesignPattern

「クラウドアーキテクティング原則」。クラウドデザインパターンの背後にある、システム設計の原則とは - Publickey

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

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

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

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

【1】AWSクラウドデザインパターンは、Webインフラの方式設計(アーキテクチャ設計)のベストプラクティス集と言える。
クラウドという概念は抽象的に分かった気になったとしても、実際にどう使えば効果的なのか、はすぐには分からない。
そこで、パターン言語という形式で、どんな問題に対して、どんな解決方法があり、どのように実装すればいいか、そしてパターンを適用した利点やトレードオフは何か、を明確にカタログ化している。
だから、料理のレシピ集のように、自分が抱えている問題や解きたい問題に当てはまるパターンをカタログから探し出せばいい。

パターンの良さは、クラウドの専門家でなくても、例えば、顧客へシステム提案する立場のSIの営業マンにはとても役立つ。
その理由は、AWSクラウドデザインパターンのAmazonの読者の感想にも書かれている。

(引用開始)
 この本は必読です。技術メンバーはもちろんですが、ITに関わるSalesは読むべきだと思います。webシステムにおいての、お客様の課題、それをクラウドがどう解決できるか、実装方法、利点などがパターン毎に纏められていて、頭が整理されます。顧客との会話の品質をあげるためにも、営業こそ読んで欲しいなあと思いました。
(引用終了)

問題(Problem)と解決(Solution)をセットにしたパターンは、クラウドによるITソリューションを売り物にするSIの営業マンにとって、ノウハウの塊のようなもの。
問題意識を持つ人ならば、AWSクラウドデザインパターンでインスピレーションが働くだろうと思う。

【2】クラウドアーキテクティング原則 - AWS-CloudDesignPatternを読むと、クラウドの本質というかクラウドの使い方について、とてもよく考えられているのが分かる。

(引用開始)
◆できるだけサービスを利用
例えばAmazon S3というインターネットストレージのサービスを考えてみる。これは耐久性が高くて便利なオブジェクトストレージなので、Amazon EC2を使って似たような機能を実装するよりも、S3を使った方がいい。キューイングにしても、Amazon SQSというサービスがあるので、EC2にキューイングソフトを入れて自分で管理するよりも、このサービスを使った方が良い。すでに存在しているサービスのメリット/デメリットを正確に理解し、使いこなせることが大事。利用者としては、車輪の再開発はしないほうがいい。

◆机上実験よりも実証実験
机上実験に終始して「このシステムでこの負荷だと、インスタンスタイプはどれを何台使えばいいのか」と悩んで、そこで時間をかけすぎてしまう、もしくは、止まってしまう。クラウドの良さは瞬時に安く調達できることなので、その場ですぐに実際に試してみればすぐに分かるし、よりカイゼンができる。

◆スモールスタートからスケールアウト
クラウドは、小さなサイズのシステムから始めて、簡単にサーバを増やせる。逆もまた然り。突発的なトラフィックが来る場合でも、最初から十分にサーバを立てておいて、それで間に合ったら後で減らしていけばいい。

◆変化に対し全レイヤで対処
クラウドならインフラレイヤからさまざまな選択肢がある。データベースの性能が足りないときには、チューニングで対処するだけではなく、サーバのインスタンスの大きさも変えてみる、データベースそのものを変えてみる、といった、インフラも含めた対処が容易になった。

◆故障のための設計(Design For Failure)
バグは出さない方がいいし、サーバは故障しない方がいい。しかしあらゆるものは壊れるのだから、壊れたときどうするかという対応品質を高めるのが大事。クラウドを使うと対応品質が上がる。例えば、サーバが落ちたらすぐ別のサーバを起動して対応し、障害復帰できる。

◆最初だけでなく周期的なカイゼン
WebサービスやWebアプリケーションが完成して運用フェーズに入っても、インフラレイヤまで踏み込んで周期的に改善したほうがいい。いままでは、すでに購入してしまったサーバにまで踏み込んだ改善は難しかったけれど、クラウドではサーバの大きさや数にまで踏み込んで改善を検討できるようになっている。
(引用終了)

「できるだけサービスを利用」は、SOAの本来の思想を連想させる。
サービスを一から作るのではなく、既存のサービスを流用する発想はまさにSOA。

「机上実験よりも実証実験」「最初だけでなく周期的なカイゼン」はまさにアジャイルの発想。
クラウドの本質はインフラ管理のIT化: プログラマの思索にも書いたように、クラウドとはインフラ管理をプログラマブルにすることだ。
本番環境が仮想サーバないし仮想環境として提供できるならば、机上で負荷や性能を熟考した後に1回だけ実験するよりも、実験しながらチューニングしていく方がノウハウがたまりやすい。

ウォーターフォール型開発は、開発環境や本番環境がプログラマブルでない状況という古い時代の制約で育ったように思う。
現代のようにプログラミング技術がテストや設計、インフラも凌駕するならば、アジャイル開発のように小規模リリースしていくやり方の方がより確実だ。

面白いと思ったのは「故障のための設計(Design For Failure)」。
これは、「故障しない設計よりも故障を考慮した設計を重視する」アジャイル開発の思想につながる。
また、セーフウェアに書かれているフェイルセーフ、フォールト・トレランスという品質の重視にもつながるだろう。
つまり、アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索にも書いたように、信頼性の問題を「いかに壊れないシステムを作るか」から「いかに素早く直せるシステムにするか」に置き換えていることが重要だ。
バグ無しのシステムを作るのはもちろん重要だが、故障したとしてもすぐに回復できるシステム設計がより重要になってきている時代なのだ。

【3】AWSクラウドデザインパターンは40個以上もあり、全てを理解していないけれど、クラウドに依存しないインフラ方式設計の考え方も入っている。
だから、クラウドに限らず、仮想環境を作る時にとても役立つだろう。

一通り目を通して興味を引いたパターンは「CDP:Bootstrapパターン - AWS-CloudDesignPattern」。
CDP:Bootstrapパターン - AWS-CloudDesignPatternは、仮想イメージを作る時に、初期設定の値をパラメータとして外出しにして、仮想イメージを起動する時にパラメータを読み込むようにするパターン。

この手法は、Chefのrecipeを連想させる。
つまり、Webサーバーの環境を仮想イメージにした場合、DNSやIPなどのネットワーク設定、Apacheなどのライブラリのバージョンや設定ファイルなどを初期設定ファイルとしてパラメータ化し、仮想イメージの起動時に動的に作れるようにすること。
このパターンを使えば、仮想イメージのライブラリがバージョンアップした時や、FirewallやDNSなどのネットワーク設定が変わった時に、簡単に修正したりスケールアップすることができる。

そんなことを考えながらクラウドデザインパターンを眺めると、最近広く知られてきた継続的デリバリの概念を実装する時にクラウドデザインパターンの考え方が役立つように思える。
クラウドデザインパターンは今後要注目だろうと思う。

読者が好きなクラウドデザインパターンは一体何でしょうか??

| | コメント (0)

2012/10/08

チケット駆動開発の運用例part4

Redmineによるチケット駆動開発、タスクボードやバーンダウンチャートによる運用事例を見つけたのでメモ。
僕は、以下の事例のように、実際の現場で試行錯誤しながら自分たちの運用を見つけていくボトムアップのやり方が好きだ。
パターン言語の発想に通じるものがある。

【元ネタ】
ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第一回)

ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第二回)

ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第三回)

ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第四回)

ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第五回)

ASE アドヴァンスト・ソフト・エンジニアリング|タスクボード、バーンダウンチャートの運用(実際にやってみて)(第六回:最終回)

【1】以下の記述から経験談が始まる。
詳細なお話は上記のリンクを読んで欲しい。

(引用開始)
余談ですが、当時はワクワクと胸を躍らせながら始めていた気がします。
なお、チーム内では既に「チケット駆動開発」を取り入れており、そのツールとして「Redmine」を利用しておりました。また、アジャイルの手法には、Scrumを採用しています。ただし、残念ながらお客様との契約形態は「請負」であり、その中で開発フェーズをアジャイル開発で実施していました。以下の内容はそれを利用している前提で記述しています。
(引用終了)

(以下抜粋)
胸をワクワクしながら始めたタスクボードやバーンダウンチャートですが、残念ながら多くのアジャイルを始めた同士達と同じ様に「ハマリ」ました。そんなハマった事象をご紹介したいと思います。
この時に発生した事象としては、以下のようなものがありました。

・このタスクなにするんだっけ?
・このタスクのボリュームは?
・ぱっとみで分からない
・収束しないタスク
・0にならないバーンダウンチャート
・タスク持ち越し
・優先度が分からない
・関連がわからない
・粘着率が悪い
・朝ミ・夕ミなげーよ
・今する話じゃないだろう
・打ち合わせ眠くなる。。。
・それ俺には関係ない話だな
・それ俺には出来ない話だな
・とったけど出来ませんでした
・テストって残るよね

以下、掴み取った転機の一覧です。
・色分けだー
・バーンダウンの種別わけだー
・TRYの貼りだしだー
・優先度に応じたチケット移動だー
・タスクの粒度はこれだー
・皆で何するか決めるんだー
・ちゃっちゃと終わらせちゃれ
・タスク無いならこれやって
・必要だからこれ先にやって
・気合よりも仕組みを!
・間に合わない。だったら客と死ぬ気で交渉

以下、課題の一覧です。
・それでも残るタスク
・増やさない努力はいつから行うべきか
・誰にとっての優先度
・誰でもできるもの、彼らにしかできないもの
・作業時間、見積もり時間
・誰がネックになるのか、特定の人だけなのか
・ちゃっちゃと終わらせちゃれ
(抜粋終了)

【2】読んでいて興味を引いた点はいくつかある。
一つ目は、綺麗なバーンダウンチャートを運用するのは難しいこと。
バーンダウンチャートを表示するには、イテレーション開始時に総予定工数を見積りし、イテレーション終了まで残工数を常に入力し、計測する運用が前提条件だ。
その前提条件を満たしながら運用するのは、僕自身も経験があるが、至難の業だ。

実際の現場では、イテレーションの途中に割り込みで作業が増えざるを得ない状況が発生しやすい。
すると、最初の総予定工数そのものが狂ってしまう。
また、残工数をメンバーに逐一入力させるのは結構面倒だ。その作業だけで退社間際に1時間以上の労力をかけてしまいがち。
しかも、その結果を集計し、バーンダウンチャートへ毎日プロットしていく作業をリーダーが残業してやるのだから、溜まったものではない。

だから僕のチームではRedmineのロードマップを毎日の朝会で確認しながら、直近のバージョンをまず100%完了するまでに持って行く事を最優先とした。
綺麗なバーンダウンチャートを運用するよりも、納期までに確実にリリースするのを最優先したからだ。

上記の記事では、バーンダウンチャートがイテレーション終了時に0にならない時がほとんどだったという。
その理由は詳しく書かれていないが、推測するに、タスクを完全に完了するには顧客へ仕様を再確認する場合があったり、リリースはできたものの新たなリスクが発生したため暫定対応となり完全に障害が解決できていない場合があるのだろうと思う。
そのような状況は、チケット駆動開発であってもよくある事例だと思う。

その場合は、残タスクやリスク、課題をタスクから切り離して、次のイテレーションないしバックログ、アイスボックスへ回す運用でカバーするしかないだろうと思う。
ソフトウェア開発は1回だけの本番リリースで、物事が全て解決する状況は殆ど無い。
例えば「マイクロソフトの製品はバージョン3になって初めて使える」と揶揄された時があったけれど、その言葉が意味することは、ソフトウェアは複数回のリリースを経てやっとまともに使えるようになるということだ。
だから、最初から完璧なソフトウェアを目指すよりも、自分たちの可能な範囲で少しずつ改良していく戦略を取る方がいい。
そのためには、残タスク、残課題、将来へのリスクを忘れずに検知しておき、しかるべきタイミングで1つずつ潰していくしかないのだと思う。

【3】2つ目は、「気合よりも仕組みを!」という言葉。
KPTによるふりかえりをやった経験がある人は分かるが、Tryには次回のイテレーションにチャレンジする内容を書く。
その時に、具体的な対策を挙げるときもあるが、「~したいな」という希望だけで終わる時もあるし、以前からずっと同じTryがあがる時がある。
すると、単なる希望的観測だけでTryが終わってしまい、本来の運用改善につながっていない時がある。

KPTの本来の意図を平鍋さんに質問した時があったけれど、ふりかえりではあくまでもメンバーから意見を引き出し、メンバーへ気づきをフィードバックするのを重視するため、希望的観測であれ、意見が出るのはいい。
「自分たちは~のようにありたい」という意見をまず出さなければ、どの方向へ改善するか分からないから。

しかし、この問題は正直難しい。
チームの成熟度が低ければ、ふりかえりは単なる反省会に過ぎない。
つまり、メンバー自身が自らの課題を認識し、それに対して対策を立てて実施し、実施した結果の評価を行うだけでなく、実施した対策そのものの評価と課題を見つける作業を訓練した経験がなければ、そう簡単には改善できないだろう。
つまり、改善していく仕組みを作らなければ、自己満足で終わってしまう。

そして、いずれにしても、現場の状況(コンテキスト)は各チーム、各プロジェクトで異なるため、他のチームの運用が全て効果的になるように当てはまるとは限らないことだ。

だから、正直、この問題にはこれと言った解決策はない。
でも、チケット駆動開発の利点の一つは、プロセスを定量化する手段を付与してくれる点なので、改善の糸口を見つけやすいことがある。
例えば、残作業が溜まり過ぎるならば、チケットの優先度や重要度を工夫したり、スコープ管理を意識して思い切ってチケットを削ったりする。
あるいは、課題や障害のうち、重要度が高いものは予防対策を立てたり、重要度が低いものは都度対応で無視する運用にしたりする。
あるいは、コードレビューや障害検証をペアで作業するように工夫して、品質を互いにチェックするだけでなく、メンバーのプログラミング技術や業務知識を共有できるように運用したりする。
他にも色々あるだろう。
自分たちが生み出した対策の評価を必ずまとめて、ノウハウを地道に貯めていくしかないのだろうと思う。

【4】逆に、自分たちの現場で編み出した運用ルールは、実践した経験に基づくため、とても価値あるものになる。
何故なら、自分たちのチームだけとはいえ、チームで実証された効果的な運用ルールだから。
その運用ルールが抽象化され、他のチームで運用して効果が出れば、パターン言語になる。

「チケット駆動開発」という言葉が広く知られるようになり、あちこちで実践されている状況を聞くと、それら現場で効果があると知られた経験をプラクティスという名のパターン言語で、再利用可能な形式知としてまとめたくなってくる。
ツールに依存しないチケット駆動のプラクティスを収集するために、他にも事例を集めてみる。

| | コメント (0)

チケット駆動開発におけるトレーサビリティのチートシート

@sakaba37さんが、「チケットによる情報の関連付け」という分かりやすいチートシートを公開されていたのでメモ。

[#TiDD] チケットによる情報の関連付け: ソフトウェアさかば

チケットはソフトウェア開発の情報を経由する中核であり、その情報をどのように追跡できるか、というトレーサビリティにつながる考え方だと思います。

| | コメント (0)

2012/10/06

DSLの使い道は継続的デリバリ~AntやMavenからGradleへ

JavaのビルドツールがAntやMavenからGradleへ少しずつ変化しようとしているように思える。
考えたことをラフなメモ書き。

【元ネタ】
IT検証ラボ - ビルドツールの移行性、MavenからGradleへの乗り換えは容易か:ITpro

ビルドシステムの選択肢 - Gradle 1.0 リリース

ビルド・リリース自動化への足掛かりとしてのGroovy・Gradle・Spock|サイバーエージェント 公式エンジニアブログ

O'REILLY 「Building and Testing with Gradle」Kindleハイライトまとめ - Togetter

Antはビルド作業をTaskで定義してパイプのようにつなげるようにビルドスクリプトを書く。
XMLゆえに長文になりがちだが、書きやすい。

Mavenはライブラリの依存関係も考慮して、大規模なシステムの構築として使える。
Mavenのビルドした成果物の構造はとても奥が深く優れているが、EJBのように複雑すぎる。

今やプログラミング言語の実験場がJavaからRubyへ移ったように、Rubyのビルドツールは、Ruby自身で書かれたrakeでとても書きやすい。
また、RubyではRSpecやCucumberのように、テスト駆動(TDD)から振るまい駆動(BDD)へ、テスト駆動の考え方も進化している。
それに対してJavaのビルドツールはあまり進歩がなかったように思う。

だが、Groovyを使ったビルドツールGradleは、rakeのように、ビルドスクリプトを書けるのが特徴みたい。
また、JUnitでテストプログラムを書く場合、モックオブジェクトやDI、リフレクションなどを使う時も多く、結構書くのが面倒なのだが、Groovyでテストプログラムを書く方がもっとシンプルなようだ。
しかも、テストプログラムが受け入れテストケースの文章になるように、振るまい駆動(BDD)で書くこともできるらしい。

ビルドスクリプトという言語スタイルは、Cのmake以来、その重要性は大きいにも関わらず、今までさほど注目されて来なかった歴史があると思う。
XPはテスト駆動や継続的インテグレーションのプラクティスを提唱することによって、ビルドスクリプトの重要性を再認識させた点が素晴らしいのではないか、と思っている。

rakeやGradleは、継続的デリバリを実現する有効なツールなのだろう。
そして、継続的デプロイ、継続的デリバリへビルド管理が進化した場合、ビルドスクリプトで表現できる範囲をもっと広げたいものだ。
それらビルドスクリプトは、Jenkinsという強力なビルド管理ツールと連携させれば、単なるリリース作業だけでなく、メトリクス収集やバッチジョブ制御などにも使えるだろう。

これらの技術も今後着目してみる。

| | コメント (0)

2012/10/04

Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPlugin

Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPluginが公開されていたのでメモ。

【元ネタ】
Jenkinsでプロジェクトの状況をウォッチする - mitoma_ryoの日記

mitoma/redmine-metrics-plugin

RedmineMetricsPluginはJenkinsのプラグインで、Redmineのチケット情報を元にバージョン単位にステータスごとのチケット推移を表示してくれるらしい。
このプラグインを有効活用するには、バージョンをフィーチャないしビジネス要求単位に作る方がグラフが意味あるものになるだろう。

似たようなメトリクスとしてパーキングロットチャートがある。
パーキングロットチャートはバージョンをビジネス要求に対応付けて、バージョン単位にざっくり集計したメトリクスを出してくれる。
それに対して、RedmineMetricsPluginは同じビジネス要求単位だが、ステータスごとの遷移を出力するのでより詳細なメトリクスを表示してくれることになる。

TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?: プログラマの思索

ユーザ機能駆動開発FDDを再考: プログラマの思索

@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine: プログラマの思索

RedmineMetricsPluginプラグインを作成した背景は以下のように書かれている。

(引用開始)
システムの開発現場では「プロジェクトのタスクがどのように推移していて、どのようなフローで消化される傾向にあるか。今どれぐらいのタスクが残っているのか、それらのチケットのステータスはどうなっているか」が知りたい場面が多いです。

特にリリース直前のリリース判定会などでは「今、残不具合はN件でM日で修正できる予定です」という報告をもらっても「M日で修正できるならリリースに間に合う」という判断を行うには材料が足りません。

「不具合は今日までにどのような勢いで発生しているのか、日々不具合が報告されているのか、既に報告される数は落ち着いているのか」が分からないと、現在のチケット数だけでは正しい判断ができないのです。(それが分かったから正しい判断ができるかというとそういう訳でもないのですが。)

で、なぜJenkinsのプラグインになったかというとアイデア元は「Jenkinsをメトリクス収集ツールとして使うアイデア」です。

<JenkinsはSVN・Mercurial・GitのようなSCMリポジトリをインプットにするが、RedmineやTracのようなITSのDBもインプットに入れれば、ITSのDBからデータをロードしてバッチ処理を行うことも可能のはずだ。
ITSのチケット集計機能はリアルタイムな集計しかできないけれども、そのようなアイデアを実現出来れば、バッチ処理を行う集計結果も可能になる。>

ITSの機能でチケット数の推移やそのOpen/Closeの割合まではグラフ化することができるものもありますが、チケットのステータスの推移を見るにはバッチ的に集計する必要があるので、高機能なCronであるJenkinsの方がいいということです。
(引用終了)

僕のアイデアが役立ったのなら、とても嬉しいことだ。
個人的には、JenkinsはRedmine以上に色んな可能性を秘めていると思っている。

| | コメント (0)

2012/10/03

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

チケット駆動開発」の感想を見つけたのでメモ。
感想ありがとうございます。

【元ネタ】
チケット駆動開発の感想 - ブクログ

(引用開始)
チケット管理を中心とした開発手法。

規律による管理、たとえばExcelの台帳で「上手くやる」とか「気をつける」とかいうのには限界がある。
人は失敗するものだし、独自フォーマットなら学習コストもかかるし、経験を積むとともに共にサイズも大きくなってスケールに対応できない。
ファイル管理だと安易に派生して収集つかないこともあるしね。

本書ではまず障害管理ツールの例を挙げてメリットを整理し、
そこからSCMやCIツールと連携したチケット駆動開発のスタイルを紹介している。
個人的にITSとSCMとの連携は使用したことがあるが、あらゆるソース変更に対してその理由が追跡可能なのは責任感を強く感じるとともに、達成感もある。そして成果物に対する自信にも繋がるし、使って損はない。

途中は入門や実践っていうより概論って感じの本だけど、
後半は具体的な運用例や、ツールを目的としない、状況に応じた適用について良く書かれているので、これからの人にもおすすめできる本だと思う。
応用運用のところからは、恐らく実体験からくるRedmineへの依存や妥協を感じるので、これが全てというより今はこういう例もあるよと割りきって読むといいかな。

前著の「Redmineによるタスクマネジメント実践技法」については読んでないのだが、
本書はその振り返りのようになってるので、折を見てぜひ読んでみたい。
(関心を持った当時はTracを使用していたため、より機能が充実してそうなRedmineは隣の芝だと思って読まなかった。そんな自分を少し恥じる。)
(引用終了)

@sakaba37さんと話していたのですが、「Redmineによるタスクマネジメント実践技法」と「チケット駆動開発」では読者層が違うのでは、という印象があります。

Amazonにも感想がありました。

(引用開始)
日本から世界に向けて発信しているIT技術は決して多くはありません。このチケット駆動開発はその数少ない日本発のIT技術に関する2冊目の書籍です。チケット駆動開発は、障害管理(バグトラッキング)の手順をプロジェクト全体に適用しようとする方法論です。表紙に書いてある「No Ticket,No Commit!」という言葉がすべてを表しています。この単純な言葉を守るためには様々な「現場の」工夫が必要です。それを丁寧に記述した本です。

私がこの本を読んでもっとも重要だと感じたのは次の2点です。

1.アダプタブル・ウォーターフォール開発(P.177)

著者はお二人とも大企業の技術者ですから、ウォーターフォール開発についての造詣が深いです。チケット開発をウォーターフォールに適用するためのアイデアをいくつか出されています。私のように30年間も基幹業務システムを創り続けてきたSEから見ると、XPだとかアジャイルだとかは私が若いころに当たり前だと思っていたことの先祖がえりという部分も多いものです(SCRUMは少し違います)。50人だとか100人だとかのプロジェクトはウォーターフォールでしかコントロール出来ません。そのウォーターフォールを、もしかすると進化させてくれる可能性のある方法論が久しぶりに出てきたように感じました。正直ここに書かれている適用だけではまだまだですが、今後様々な提案をしてくれるだろうと期待が膨らみます。

2.チケット駆動開発は現場から始まった(P.17)

ウォーターフォールでは、マネージャがWBS(Work Breakdown Structure)を作成し、作業者が実行するという進め方になります。これでは現場で発生するタスクが表に出てきません。それに対してチケット駆動開発はプログラマーがチケットを入力します。プロジェクトリーダーはそれを利用して報告するだけです(P.249)。この動きがすすむと、日本のIT業界の最大の悪慣習である「多重下請け構造」が緩和される可能性があると期待しています。

この方法論は机上の空論でなく本当に現場から生まれてきたものです。そのためにツールの画面やフォーマットが豊富に出てきます。ただそのことと裏腹ですがMantisやRedmineというツールの説明に引きづられた部分があるので読みにくくなっています。その点でマイナス1点としました。
(引用終了)

チケット駆動開発にはたくさんの可能性があると僕も思っています。
チケット駆動開発を今後考えていく上で、単なる開発プロジェクトへの適用だけでなく、組織構造への変化にも着目してみようと思っています。

他にも色々集めてみる。

【追記】「Redmineによるタスクマネジメント実践技法」がついに電子書籍として発売されました。

Redmineによるタスクマネジメント実践技法 - Google Play の書籍

| | コメント (0)

2012/10/02

アトラシアンブログに「チケット駆動開発を上手に運用するためのプラクティス」の記事を書きました

アトラシアンブログで、私が寄稿したチケット駆動開発の記事が公開されました。
Part1は@sakaba37さん、今回はPart2になります。

チケット駆動開発を上手に運用するためのプラクティス(ゲストブログ) | Atlassian Japan

なぜ日本ではチケット駆動開発が注目されるのか?(ゲストブログ) | Atlassian Japan

さっそくブログにコメントがあり、以下のように返信しました。

(引用開始)
はい、チケット化する時の運用ルールは大事ですね。
割り込み作業があったとしても、別チケットに登録して、今の作業に「集中」することも可能になります。
(注:Scrumの価値「専念(Focus)」のイメージです)

また、チケット駆動のプロジェクト運営に馴染むと、乱発放置されやすいチケットを整理する技法が鍵になります。
是非、経験を元にチケット駆動に合った運用ルールを見出していきましょう。
(注:「現場の経験を元に」のイメージは、パターン言語でプラクティスを再構築するイメージです)
(引用終了)

今回の記事で紹介したチケット駆動のプラクティスは以下の7つです。

プラクティス 1. チケット無しのコミット不可 (No Ticket, No Commit)
プラクティス 2. チケット無しの作業不可 (No Ticket, No Work)
プラクティス 3. イテレーションはリリースバージョンである (Iteration is Version)
プラクティス 4. チケットは製品に従う
プラクティス 5. タスクはチケットで分割統治 (Divide and Conquer)
プラクティス 6. チケットの棚卸し
プラクティス 7. ペア作業 (Pair Work)

他にも「Ticket First」「成果物はバージョン管理に従う」などのプラクティスも考えています。

第4回品川Redmine勉強会の私の講演「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」で、チケット駆動開発のプラクティスのアイデアを詳細に話す予定です。
興味を持つ人は是非聞きに来てください。

第4回shinagawa.redmine勉強会 : ATND

第4回勉強会 - shinagawa.redmine

| | コメント (0)

2012/10/01

【告知】第4回品川Redmine勉強会で「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」を話します

【告知内容】
第4回shinagawa.redmine勉強会 : ATND

第4回勉強会 - shinagawa.redmine

日時
2012/11/10(土) 13:00~17:50

場所
〒113-6591
東京都文京区本駒込二丁目28番8号 文京グリーンコートセンターオフィス13階

ハッシュタグ
#47redmine

Twitter / akipii: 第4回品川Redmine勉強会の見所1:@marutosijpさん「Redmineのブランチ戦略」と@LightningXさん「Redmine + Git + スクラム = ALMinium」はMercurialやGitのブランチ管理とRedmineへの連携方法の講演で楽しみです

Twitter / akipii: 第4回品川Redmine勉強会の見所2:私の講演「チケット駆動開発のフレームワーク~現場の経験知からパターン言語へ」ではTiDDを価値・原則・プラクティスで体系化し、その効果や課題を話します。オープンディスカッションでは、参加者の経験を元にチケット駆動の可能性を議論する予定です

Twitter / akipii: 第4回品川Redmine勉強会の見所3:@yusuke_kokuboさんにも来て頂き、Redmineのカスタマイズ事例をお話してもらう予定です。勉強会のスケジュールは多分18時まで内容が濃くて目一杯になりますので、盛り上がるのを楽しみにしています。

【追記】
今年の10~11月は関西のアジャイルコミュニティが活発に動きます。
AgileTourOsaka2012やDevLOVE関西2012Driveの講演者を見ると、東京から大阪へアジャイル民族大移動が起きているみたいです(笑)

10/20(土)
第6回RxTstudy : ATND

11/3(土):
11月3日 AgileTourOsaka2012 in Minoh 箕面の滝からこんにちは(大阪府)

11/10(土):
DevLOVE関西2012Drive - DevLOVE関西

| | コメント (0)

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