« 2013年11月 | トップページ | 2014年1月 »

2013年12月

2013/12/31

Redmineの裏の顔~開発基盤としてのRedmine

Redmineには、オープンソースのプロジェクト管理ツールという表の顔だけでなく、業務アプリケーションの開発基盤(プラットフォーム)という裏の顔もある。
アイデアを下記にまとめてみた。

【1】最近、Redmineを企業(IPAも含む)が機能拡張する事例が少しずつ増えている。
何故、Redmineをカスタマイズしてでも、使いたいのか?

Redmineは本来は、オープンソースのプロジェクト管理ツールという表の顔がある。
ソフトウェア開発の進捗管理を開発チームがやりたいなら、一通りの機能が揃っている。

特に、日本では、Redmineの人気が高いらしい。
その理由は、インストールして、プロジェクトやワークフローなどのパラメータを設定すれば、すぐに運用できるからだろう。
そして、実際の運用は各チームで微妙に異なる場合が多いけれど、その微妙な違いもRedmineで実装できるくらい、Redmineが柔軟な機能を持っている点があるだろう。
日本のSIerの運用例としては、障害管理(BTS)や課題管理(ITS)としてまず使い始めて、その後、全工程のタスク管理をRedmineで運用するパターンが多いだろうと想像する。

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

しかし、実際にRedmineを運用してみると、開発者よりもマネージャ層から、Redmineに対する不満が出ることが多い。
実際、僕が今までの現場でRedmineによるチケット駆動の運用を導入した時、その後の運用で不満が出てくるのは、特にマネージャ層だった。

マネージャ層の話を聞くと、Redmineは開発者の観点では使いやすいが、マネージャが欲しいデータを簡単に取得したり、操作するのが面倒なようだ。

Redmineチケットに開発チームの全ての作業データがあり、まさに生データなので、そのデータを進捗・品質・リスク・工数の観点で色々集計して、分析したい。
しかし、Redmineの集計機能は、チケットをフィルタリングするクエリ、ガントチャート、ロードマップ、サマリぐらいで、マネージャが進捗・品質・リスクを日々追跡するには物足りない。
結局、RedmineからチケットをCSV出力して、ローカルPC上のExcelで手集計して、時間をかけて分析しているのだ。

Redmineにせっかく溜まった生データをマネージャ向けの観点で分析したい、という要望こそが、企業がRedmineを機能拡張する動機なのだろうと思う。

【2】Redmineを機能拡張する方向性としては、Redmineを開発基盤と言うプラットフォームで考えると分かりやすいと思う。
つまり、Redmineをプロジェクト管理用ERPと見なして、どのように機能拡張すればよいか、という観点で整理できる。

すると、Redmineと言うプラットフォームでは、以下の4つの観点でカスタマイズする方法を分類できるだろう。

・外部接続I/F
・パラメータ設定
・プラグイン(アドオン)
・モディフィケーション

【2-1】外部接続I/F

Redmineには、外部接続I/Fを通じてデータ操作を行える仕組みが豊富に揃っている。
例えば、RESTによるWebサービス、リポジトリ管理用のWebサービス、受信メールによるWebサービス、rakeによるデータ移行、rakeによる期日間近のチケットの通知などがある。

Redmineの外部接続、データ移行の機能: プログラマの思索

RedmineのREST APIは素晴らしい~ビッグデータの手法をRedmineにも活用する: プログラマの思索

メールからRedmineのチケットを自動登録する時の注意点: プログラマの思索

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

期日が間近のRedmineチケットをメールで通知する: プログラマの思索

オープンソースなのに、これだけの種類の外部接続I/Fが標準で装備されているのは、本当に凄いことだ。
SIがスクラッチで受託開発する特定顧客向けの業務システムでも、これほどの外部接続I/Fを実装するのは、かなり工数がかかるだろう。

外部接続I/Fを使う状況としては、社内の会計システムや工数管理システムからRedmineにある工数データを取得したり、社内の品質管理システムからRedmineにある障害情報を取得する場合があるだろう。
つまり、Redmineにある元ネタを引っ張り出して、外部システムが取り込んで加工する流れになる。
特に、障害チケットやソース管理リポジトリ情報は、ビジネスインテリジェンス(BI)によって加工すれば、より意味のある観点で分析できるはずだ。
品質管理担当者ならば、障害データから品質の状況や傾向を分析したいし、マネージャならば、工数データから今後どれくらいコストが発生して、納期通りにプロジェクトが完了できるか、分析できるだろう。

このアイデアは、ソフトウェア・リポジトリ・マイニングというエンピリカル・ソフトウェア工学の方向に一致するだろう。

ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

但し、前提条件としては、既に使える外部システムがあり、その外部システムでRedmineのデータを取り込んで加工すれば解決できることがある。

ここで、Redmineの外部接続I/FはRESTなどのWebサービスが基本なので、HTTP接続によるリアル連携になる。
昔は、外部接続といえば、Cobolによる夜間の日次バッチ処理が主流だったが、リアル連携の方が最新データをいち早く取得できる利点がある。

注意すべき点は、HTTPによるリアル連携のため、大量データのやり取りには向いていないこと。
頻繁にリアル連携するならば、負荷テストで事前検証する必要があるだろう。

但し、開発チームの規模が小さく、プロジェクトで発生するチケットや進捗情報が少ないならば、例えば、5分おきのリアル連携でも問題ないかもしれない。

【2-2】パラメータ設定

普通のERPでは、最初に、特定顧客向け用パラメータを初期マスタとして登録する運用がある。
例えば、会計システムならば、企業が使う勘定科目は企業ごとに微妙に違うので、あらかじめ勘定科目データを洗い出して登録する必要がある。
あるいは、経費申請などのワークフロー管理システムならば、企業独自のワークフローで使えるように、あらかじめ帳票データや承認フローを登録する必要がある。

Redmineの場合、初期パラメータの設定は、ワークフローやユーザ、ロール、プロジェクトなどの初期設定の作業になる。
ここで一番重要な設定作業は、ワークフロー管理だ。

Redmineのワークフロー管理では、チケットの種類ごと、ロールごとにワークフローを自由自在に設定することができる。

RedmineとTracの機能比較: プログラマの思索

Tracのワークフロー: プログラマの思索

この機能こそがTracやMantisよりも優れている点であり、ワークフローを運用の場面に応じて変えれば、ソフトウェア開発のあらゆる作業をすべてチケットに置き換えることができる。
さらには、ソフトウェア開発以外にも、ヘルプデスクの問合せ管理やPC資産管理など、他業務へも適用できる利点がある。

【公開】講演資料「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索

逆に言えば、自分たちの開発チームではそもそもどれだけのワークフローが必要なのか、という問題を事前に洗い出しておく必要もある。
ワークフローは一度決めると、新規追加は簡単でも、運用中のワークフローを変更・削除するのは、過去の履歴データの扱いによっては、修正不可能な場合があるからだ。

ここで、ウォーターフォール型開発とアジャイル開発では運用スタイルが全く異なる。
この違いについては、詳細は「Redmine超入門」を読んでみると良いかもしれない。

「Redmine超入門 (日経BPムック)」が発売されました: プログラマの思索

Redmineのパラメータ設定が成功する前提条件としては、Redmineの標準機能だけでプロジェクト運営できる前提がある。
実際は、プラグインを幾つか追加して、機能拡張するのが普通だろうと思う。

【2-3】プラグインというアドオン

Redmineのプラグインは、Railsフレームワークのおかげでとても開発しやすい。
「設定よりも規約」「繰り返しの禁止」などのおかげで、少ないソースで簡単に作成できる。
また、プラグインのインストールも、rakeコマンドを叩いてRedmineを再起動するだけなので、とても簡単。

プラグイン開発ガイド - r-labs

プラグインの開発 ? Redmine.JP

プラグイン開発の特徴は、「標準機能のソースを修正する事無く」追加開発で機能拡張する点にある。
つまり、プラグインの利点は、Redmine本体のソースは基本は手を加えず、テーブルの新規追加などぐらいで、Redmine本体をパワーアップできる点だ。

Redmineを開発基盤として機能拡張(アドオン)したい場合、できるだけRedmine本体は触らずにプラグインの追加だけで対応できるようにしておきたい。
理由は、RailsもRedmineも頻繁にVerUpしていくには、Redmine本体に手を加えると、そのVerUpに付いていけなくなるからだ。

今までの経緯を見ると、Redmineはセキュリティに関するバグ修正は即リリースするので、できるだけRedmineは最新版で運用できるようにしておきたい。

だから、プラグインを開発して、マネージャ向けの機能を追加して反映するのが主流になるだろうと思う。
Railsを操る技術力さえあれば、マネージャを顧客と見なして、その要望をRedmineプラグイン化すれば、ソフトウェア開発のプロジェクト管理を全てプログラム化することもできるだろう。

【2-4】モディフィケーション

モディフィケーションは、「標準機能のソースを直接修正して」機能拡張する場合に相当する。
ERPを導入する場合、普通はパラメータ設定やアドオン追加だけでは足りず、どうしてもERP本体にも手を入れて修正する場合が多い。
特に大企業になるほど、独自の業務があったり、業務で発生するトランザクション量が多いために、独自実装せざるを得ないのだ。

Redmineを小さな開発チームで運用するなら、Redmineの標準機能といくつかのプラグインだけで問題ないかもしれない。
しかし、大手SIが組織全体・会社全体でRedmineを導入し、プロジェクトごとの進捗管理や品質管理、コスト管理、リスク管理を厳格に行いたい場合は、もっと機能が欲しくなる。

モディフィケーションの方向性としては、2つあると思う。
一つは、マネージャ向けに集計・分析機能を強化すること。
もう一つは、マネージャが操作しやすいユーザインターフェイスに機能改善したり、運用しやすいようにサービスもセットで提供すること。

前者は、IPAがオープンソースで提供しているEPM-Xが相当するだろう。
課題管理や品質管理の機能をもっと徹底的に使い倒して、リスクを追跡していきたいのだ。
イメージとしては、「チケット&計測でITプロジェクト運営の体質改善」に書かれている内容に相当するだろう。

チケット駆動開発を紹介した書籍一覧: プログラマの思索

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

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

後者は、アジャイルウェア(株)のLychee Enterpise製品シリーズや、ホロンテクノロジー(株)のソリューションサービス「Redmine for ITIL」があるだろう。

第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索

Redmine for ITILが解決するもの: プログラマの思索

Lycheeシリーズでは、ガントチャートのユーザインターフェイスを改善することで、マネージャがチケット中心ではなくガントチャート中心に進捗管理できるように操作を改善している。
他に、EVMによる工数管理や、チケットの親子関係・先行後続関係を表示するチケット関連図など、興味深い製品もある。
特に、EVMの実現方法は「Redmineによるタスクマネジメント実践技法」で詳しく書いたので、Lychee EVMがどれくらい、僕が考えたアイデアを実装しているのか、に興味がある。

「Redmine for ITIL」は、Hinemosと連携した運用保守のサービス・パッケージだ。
RedmineのようなITSは元々、障害管理ツールから発展したので、本番障害の管理がメインとなる運用保守とは相性が良い。
ITILというフレームワークをRedmineに実装して運用できるのではないか、というアイデアは「Redmineによるタスクマネジメント実践技法」に書いたけれど、そのアイデアが製品として実際に実現されたのは注目に値すると思う。

モディフィケーションの注意点としては、Redmine本体に手を加えているため、RedmineのVerUpで保守コストが発生する点だ。
RedmineのVerUpが頻繁に行われた場合、最新版に追いつくだけでも大変だ。
カスタマイズの量が多いほど、困難になるだろう。
実際、EPM-XはRedmineのVerUpに追いついているようには資料上見えない。

もう一つは、Redmine本体のソースを直接修正する場合でも、RedmineのWebサービスAPIを使用して改造する方向が良いことだ。
Redmine管理画面から「RESTによるWebサービス」「リポジトリ管理用のWebサービス」「受信メール用のWebサービス」「JSONP」を有効に設定できるので、これらの外部接続I/Fを通じてデータをやり取りすれば、スクラッチでデータ接続部分を作るコストを減らすことができるし、今後のRedmineのVerUpにも対応しやすくなる。
同様に、Redmine標準のrakeコマンドを真似て、データを一括処理するrakeコマンドを実装すれば、バッチ処理の代替にもなる。

モディフィケーションのアーキテクチャがうまく設計されているか否かで、保守コストに大きく関わってくると思う。

【3】Redmineをプロジェクト管理システムのプラットフォームとして扱う場合、以下のようにまとめられると思う。

(1)外部システムが既にあるならば、Redmineの外部接続I/Fを通じて最新データをリアル連携する。
(2)Redmineの運用は、初期パラメータ設定で可能か、事前検証しておく。
(3)機能拡張はできるだけプラグインで対応する。
(4)より高機能に使い倒したい場合は、Redmineのパッケージ製品を購入してみる。

以上のように考えてみると、Redmineを機能拡張してパッケージ製品として販売したり、チケット駆動開発の運用とセットにしたトータル・ソリューションで提供したりする方法は、今後増えるのではないか、と思う。

僕が一番興味があるのは、「Redmineによるタスクマネジメント実践技法」や「チケット駆動開発」で書いたアイデアが、どれだけ製品として実現されるのか、という点だ。
本を出版する時点ではあくまでもアイデアに過ぎなかったが、もう3年以上たった今、どのように実装されて運用されているのか、にとても興味がある。

今後も追いかけてみる。

【追記】
下記のTwitterを見つけたのでメモ。

Twitter / kimutansk: 内容の方向性自体はRedmineでなくても共通的な内容ですが、ここまで拡張ポイント充実してましたか。 / “Redmineの裏の顔~開発基盤としてのRedmine” http://htn.to/n8zRqU

Twitter / kimutansk: Redmineまとめ。ワークフローは他のでもできたような・・・ただ、それも慣れたから言える話なのかもしれませんね / “Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索” http://htn.to/Nw2E2H

Twitter / kimutansk: 最適解かどうかはさておき、こういう用途にも使えるわけですか。 / “「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」” http://htn.to/cF6DCS

Twitter / sakaba37: RedmineがJSONP対応だった件! RT @akipii: Webユーザエクスペリエンスのためのパターン集~Ajaxデザインパターン http://bit.ly/JKSFjq


| | コメント (0)

2013/12/29

論文管理ツールMendeley

論文管理ツールMendeleyというアプリを見つけたのでメモ。

【元ネタ】
Install instructions for Mendeley Desktop on Windows | Mendeley

便利すぎる無料の研究論文管理ソフト『Mendeley』 | AUTHORITY SITE

Mendeleyで論文を管理する | Res-Log

#Mendeley - "A Last.fm for Research" にハマってます - @keitabando のブログ

SNS的な共有もできる文献整理フリーソフトMendeley : 5号館のつぶやき

最強の文献管理ソフトはこれだ! - 化学者のつぶやき -Chem-Station-

論文、プレゼン、PDF資料のすべてを管理できるPapers 3 | Lifehacking.jp

日本語論文 to Mendeley

文献の探し方

大学生なら、卒論・修論・博士論文などを書く時に、必ず他の文献を引用しながら、自分の論文をまとめる。
文献を探す動機は2つあると思う。
一つは、自分が書きたい論文のアイデアを探すために、他の論文に記載された未解決問題や、論文の欠点を見つけて元ネタにすること。
もう一つは、自分が書く論文の主張とは直接関係しない概念や事例を書く時に、他の文献を参考にしろ、と書くことで省略したいこと。

しかし、その時に、参考文献を管理する必要があるが、この作業が結構面倒。
図書館で紙媒体しかなかったり、他の大学の図書館にしか論文集が存在しなかったりする時もある。
自分のアイデアを補強する論文を探すために、たくさんの論文をTexやPDFで落としては、メモして重要度を付けて整理しなくてはならない。

PCがない頃は、文献管理を全て紙で作業していたから、大変だった。
その作業そのものが学者で重要な作業だった。

人文系・社会系の昔の学者の本を読むと、カードに文献を書き出しては、メモを取り、それを箱に入れて整理していた。
梅棹 忠夫さんの本「知的生産の技術」などを読むと、京大式カードは本来は、文献管理に使いたかったのではないかと思う。

でも、紙のカードで収集して整理する方法は、物理的制約も大きいし、大量のカードからの検索も面倒。
文献カードの最新化も難しい。

また、PCが普及してからは、学者でない人も、自分が興味を持つPDFやドキュメントをローカルに貯めておくものの、それら文書が整理されていないために死蔵されてはいないだろうか?
それら文書を簡単に抽出できるようになれば、もっと創造的になれるのに、と思う時はよくある。

論文管理ツールないし文献管理ツールは有償無償で色々あるようだが、Mendeleyというソフトが使いやすいらしい。
UIもiTunesに似ていて、使いやすそう。

(引用開始)
【Mendeleyの特徴】
・論文のPDFファイルを突っ込むと文献情報を自動で作成する(間違いもあるのでチェックは必要)
・Web上の文献データベースから直接登録することが可能な場合も.
・様々なスタイルの引用リストを自動で作成して,Word等に突っ込むことが出来る
・専用のWebストレージ(無料プランなら500Mb)を介して複数端末間での同期が可能(Win/Mac/Linux/iphone)
・その他にも研究者用SNS機能等があります.
(引用終了)

個人的に興味があるのは、放り込んだPDFの論文から、Abstract、書誌情報、引用文献を自動的に抽出してくれる機能があること。
この機能は、昔の学者が、自分で文献情報を文献カードに書き込んで整理していた作業に相当する。
つまり、文献カード作成機能を自動化してくれるわけだ。
他にも、SNSと連携したり、文献情報をクリップボードへコピーするなど、使いやすそうなイメージがある。

この手の情報は貯めれば貯まるほど、重要な資産になる。
今後の知的生産者は、このような文献管理ツールが必須になってくるのだろうと思う。

改めて論文管理ツールMendeleyを考え直してみると、音楽ファイルを管理するitunes、epubファイルを管理するCalible、写真のような画像ファイルを管理するPicasa のようなソフトと同じであるように思える。
音楽ファイル、電子書籍ファイル、画像ファイル、論文などのPDFファイルを管理するツールが、作業を自動化してくれるだけでなく、個人の生活を豊かにしたり、知的作業をサポートしてくれるわけだ。

calibre - E-book management

Picasa

色々触ってみようと思う。

| | コメント (0)

2013/12/28

IntelliJのTasks機能でチケット駆動を実践する使い方

IntelliJのTasks機能でチケット駆動を実践する使い方の記事を見つけたのでメモ。

【元ネタ】
IntelliJのTasks機能とGitHubのIssuesを連携させてチケット駆動開発 - Qiita [キータ]

IntelliJ IDEA :: Tasks & Context Switching

IntelliJ IDEA | サムライズム

IntelliJという有償の開発ツールには、Tasksという機能があり、TracやRedmineだけでなく、GitHubやBitbucket、Trello、PivotalTrackerとも連携しているらしい。
つまり、IntelliJ上でソース修正したら、コミットする時に、各種ITSのチケットにリンクさせることができる。

EclipseでもMylyn機能で同様の操作が可能だが、IntelliJのGUIの画面を見ると、すごく使いやすそう。

(引用開始)
チケット駆動のチーム開発に限らず、GitHubを使って個人でプログラムを公開している場合でもチケットとコミットの紐付けは重要ですが、面倒な作業でもあります。コミット時のコメントをうっかり忘れたり内容を間違ってしまってIssueとコミットの関連がカオスな状態になってしまい、結局Issuesも使わないというのは私の過去の経験談ですが、Tasks機能を使うようになってからはそのような失敗も減りました。同様の経験をお持ちの方は是非一度試してみて頂ければと思います。
なお、この機能はFree版のCommunity Editionsでも使えるようですので是非一度お試しください。
(引用終了)

| | コメント (0)

パターン言語の構造と事例集

パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)」を読んでみたら、パターン言語はソフトウェア開発のベストプラクティス集を表現するのに有効ではないか、というアイデアについてメモ書き。
関係資料をスライドにまとめてみた。

【元ネタ】

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

デザインパターンをマインドマップで表現してみる:An Agile Way:ITmedia オルタナティブ・ブログ

問題をビジュアルに考え解決に導くフレームワーク

パターンランゲージのカンファレンス AsianPLoP 論文投稿は1月6日まで!パターンを書いて投稿しよう! - kawaguti の日記 (id:wayaguchi)

【1】「パターン・ランゲージ: 創造的な未来をつくるための言語 (リアリティ・プラス)」を読んで、パターン言語がパターンの関係の全体像を表した図であり、パターンの関係そのものもパターンであるという記述を見つけて、パターン言語についてようやく分かったような気がした。

パターンとは何か?
それは、ある状況における問題に対する解決策を提示した一連の実践知を、パターンという形式で表現した形式知。

ある「状況」においてどんな「影響力」が働いて「問題」を引き起こすのか。
その「問題」を「解決」する具体策を提示し、どのような「結果」を引き起こすのか。
それを名前付けしたのが「パターン」である。

パターンの利点は、現場で頻繁に使われる暗黙知や実践知に対して、形式知として整理して体系化されているため、その知識を再利用しやすいこと。
パターンという形式を使わなくても、日本でも開発プロセスやプロジェクト管理などの経験談をまとめて、たくさんの著書が出版されていたが、僕はいつも腑に落ちない感触を持っていた。
それらの知識は、他の現場で再利用できる知識として整理されていなかったからだ。
知識と言うよりも、年をとった人の経験談でしか、受け止められない感覚を持っていた。

逆に、従来のソフトウェア工学は、ウォーターフォール型開発をベースとしていたために、開発プロセスやその管理手法が古い気がしていた。
知識体系にはなっているけれど、現場でその知識を使えるとはあまり思わなかった。
その理由は、Excelなどを駆使する手作業の部分が多すぎたり、抽象的すぎて実際の現場ではメンバーのスキルやコストの観点から導入しにくいこともあった。

でも、それぞれの現場で起きるソフトウェア開発の諸問題と解決策をパターンとして整理・体系化できれば、パターンを利用できるだけでなく、パターンが使える状況が明確になっているので、パターンで全ての問題が解決できるわけではないことが分かる。

懸田さんが公開されているパターン・キャンパスを使えば、実際のパターンを作り出すこともできるだろうと思う。

また、パターン言語という全体像を示すことで、各パターンの関連も見えてくる。

あるパターンで、ある問題を解決したとしよう。
すると、パターンを解決する前とは違った状況(結果文脈)に変化する。
パターンを適用して問題が解決されたポジティブな側面もあれば、逆に、パターンの適用によって状況が変化したために新たな副作用が発生して、別の問題が発生するというネガティブな側面もある。

問題解決は別の新しい問題を生み出す。
でも、普通は、その別の新しい問題は、以前よりもレベルが1段上の状況に置かれているので、さらに高度な解決法を要求する時も多い。

【2】スライドでは、パターン言語を各事例でまとめてみた。

GOFのデザインパターンは23個あるが、それらも関係づけることでパターン言語になる。
オブジェクト指向における再利用のためのデザインパターン」には、パターン言語の全体図が蜘蛛の巣のように書かれているが、最初の頃は、それが何を意味しているのかよく分からなかった記憶がある。
各パターンがパターン言語で表現できるということは、パターンは有機的であるように思える。

組織パターン」からScrumフレームワークに使われるパターンを抽出したパターン言語の全体像も公開されている。
その図を見ると、Scrumは非常に上手く作られたフレームワークであることがよく分かる。

また、XPも、別の観点におけるプロセスパターンでありパターン言語であることも分かる。
XPの12のプラクティスは、バラバラの概念ではなく、それぞれが関連し合っていて、一体化して初めて大きな効果が得られる仕組みになっているわけだ。

そして、ドメイン駆動設計のナビゲーションマップは、ドメイン駆動設計で使われるパターンのパターン言語だ。

以前からずっと考えているアイデアとしては、チケット駆動開発で頻繁に使われるプラクティスをパターン言語としてまとめて整理したいことだ。
既にアイデアは色々公開しているし、「Redmineによるタスクマネジメント実践技法」にも書いている。
それらのプラクティスを一つのパターン言語として表現する事で、チケット駆動開発の構造をより明確にしてみたいと考えている。

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

XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」

| | コメント (1)

2013/12/22

BPMとワークフロー

BPMとワークフローについてリンクをメモ。
以下、ラフなメモ書き。

【参考】
BPMとワークフローの違い なぎさプランニンング

BPMシステムとワークフローシステムの違い - Cloud Workflow QUESTETRA BPM SUITE

BPMNのモデリング・ステップとBPMN 2.0適合基準 | 岩田研究所

岩田研究所 | ビジネスプロセスマネージメント(BPM)のフォーカスポイント ブログ

Eclipse BPMN2 Modeler

BPMはアクティビティ図の条件分岐をさらに詳細化しただけの記法のように思える。
Ecipseのプラグインを使えば、アクティビティ図と同じように書ける。

BPMの使い道は、業務のワークフロー分析だろう。
しかし、企業のワークフローはとても複雑だ。

例えば、経費の申請・承認、出張代金の申請・承認だけでも、組織や職層をまたがる場合、複雑なビジネスルールが発生する。
BPMでそこまで表現できるのか?

BPMがやりたい目的は、ユーザがワークフローを書いたら、モデルからソースを自動生成できること。
でも、エンドユーザのモデリング能力が低い場合、本来の要望とは異なるモデルを書いてしまったり、その後の機能拡張や保守がやりにくかったり、バグだらけだったりする時が多い。

フローチャートで描こうと頑張るほど、難しくなると思う。
BPMはプロセス指向モデリングであり、DOAでもないしOOAでもないと思う。
多分、BPMはOOAやDOA以前のプロセス指向モデリングへ先祖返りしようとして、破綻しているのではないかと思っている。

【追記】BPMとワークフロー管理について、まとまった記事があったのでリンクしておく。

BPMやワークフローについてのメモ - kawaguti の日記 (id:wayaguchi)

| | コメント (0)

2013/12/19

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ

SECIモデルを調べていたら、それは知識の再利用モデル、または、実践知を生み出すモデルに相当するのではないか、と気づいた。
ラフなメモ書き。

【元ネタ】
情報システム用語事典:SECIモデル(せきもでる) - ITmedia エンタープライズ

ナレッジマネジメント - Wikipedia

連載 オブジェクト指向と哲学 第14回 学習パターンとSECIモデル

連載 オブジェクト指向と哲学 第16回 パターン言語 - ソフトウェアへの浸透

SECIモデルはパターンランゲージの作成プロセスに似ている~第52回SEA関西プロセス分科会の感想 #seaagile: プログラマの思索

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

SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語

生成的開発プロセス・パターンランゲージ

【1】野中先生のSECIモデル(セキモデル)は、今まで何度聞いても分かりにくかった。
その理由は、SECIモデルを実際に使った具体例がイメージできていなかったからだと思う。

そこで、「SECIモデルは知識の再利用モデル、または、実践知の構築モデルである」という方針で、データマイニング・IT情報共有・見える化・Scrum・チケット駆動開発の各事例について、当てはめてみた。
すると、各プロセスにうまく当てはまりそうな感じがした。

【2】SECIモデルの具体例を実際に考えてみると、IT業界でよく言われるバズワード「情報共有」「見える化」とは、表出化プロセスに相当することが分かる。
つまり、チームや組織が何となく問題だな、何かおかしいな、という状況認識(暗黙知)を、ホワイトボードに書き出したり、メトリクスで出力して表示したり、無理やり形式知にしたプロセスである。

だから、表出化というプロセスはすぐに思いつきやすい。
しかし、見える化したからといって、それだけで問題が解決するわけではない。

見える化された問題に対して、どんな目標に向かって解決すべきかという課題へ洗練し(連結化)、その課題解決策ないし是正対策を各人が実施して解決しなければならない(内面化)。
実際は、この内面化のプロセスが難しいのだろうと思う。
是正対策を実施しなければならないことは分かっているが、本当にその対策が有効なのか、半信半疑だったり、躊躇したりして、その一歩を踏み出せない場合が多いと思う。

そこで、平鍋さんが提唱したプロジェクトファシリテーションが、行動を促進させる触媒として有効に活用できると思う。
連結化→内面化のプロセスで、プロジェクトファシリテーションを使って、メンバーのやる気を吸い出して元気づけて、メンバーが行動に踏み出すように促すのだ。

プロジェクトファシリテーションは、暗黙知を形式知へ変換させる表出化プロセスでも相性が良い。
「問題 vs わたしたち」という構造を作り出すことで、メンバーが暗黙的に感じていた問題点をどんどん吐き出す雰囲気を促進する。
朝会、KPTによるふりかえりが特に効果的だと思う。

Redmineでチケット駆動開発を実践していた時も、単にチケットを中心にタスクを回すだけでなく、プロジェクトファシリテーションを自然に使ってプロジェクト運営し始めた経験を持っているが、その理由はそんなところにあるのだろうと推測する。

もう一つ、注意するのは、形式知→暗黙知へ変換する内面化プロセスでは、形式知をそのまま現状に適用しても、思ったような効果が出ない場合が多い点だ。
その理由は、形式知が使える状況は限られているため、全ての現実に当てはまるとは言えないからだ。
つまり、パターン言語のように、パターンが使える状況(コンテキスト)を明確にしておく必要がある。
そうでなければ、形式知は生きた知識として、内面化プロセスを経た後に、自分たちのものとして所有できないだろう。

【3】Scrumを生み出したシュエイバーは、ScrumがSECIモデルに影響を受けていることを「アジャイルソフトウェア開発スクラム」で既に説明している。

Scrumでは、デイリースクラム(日次スクラム)が表出化プロセスを生み出す場になっている。
日次スクラムで、メンバーが持っている技術知識や経験をチームへ形式知として提供したり、問題となっている状況を障害(課題:Sprint Impediment)として表明したりする。
スクラムマスターは、日次スクラムで出てきた課題に対して、課題解決していく義務を背負っている。

Scrumでは自己組織化、自律化がキーワードになっているから、内面化プロセスが非常にスムーズに回る。
SECIモデルの観点では、Scrumは、表出化・内面化プロセスが自然に実践運用できる環境を作り出しているので、非常に上手く作られたフレームワークだなと改めて思う。

【4】では、チケット駆動開発をSECIモデルで見直すとどうなのか?

チケット駆動開発では、見える化のための手段が豊富だ。
例えば、チケットに起票したり、Wikiに書いて共有したり、ソースをコミットする時は必ずチケットに記録されるので、表出化するプロセスをツールが支援する。
また、朝会、KPTによるふりかえり、チケットの棚卸し、イテレーション計画の作成・変更のタイミングで、メンバーに技術検証の経験や課題を表明するような場、つまり表出化する場を生み出している。

そして、チケットが作業記録が更新される過程で、チケット消化に向けて、リーダーが課題解決を支援したり、他メンバーが環境構築や障害検証を行なって、一つのチケットにたくさんのノウハウがパッチとして更新されていく。
つまり、連結化プロセスに相当する。

そして、チケットが完了する過程で、どんどん知識と作業が一体化していく。
つまり、内面化プロセスに相当する。

最後に、イテレーションの全てのチケットが終了ステータスになれば、リリースが完了する。
そのイテレーションで得られた経験は、チームのナレッジ資産(PMBOKで言う組織のプロセス資産)となる。
つまり、内面化プロセスになる。

【5】同様に、パターンもSECIモデルで表現できる。
従来の狭義のソフトウェア工学は、再現可能なプロセスを創りだそうとして成功しなかったが、XPやScrumなどのアジャイル開発は、プラクティスとして実践知を再利用できることを発見し、成功したと思える。

つまり、プラクティスをプロセスパターンと見なせば、SECIモデルにうまく当てはまると思う。
チケット駆動開発も、使われているプラクティスをパターン言語として体系化できれば、XPやScrumのようなアジャイル開発のように、実践知の再利用モデル、あるいは、実践知を生み出すモデルとして、作り直せると思う。

それらについても考えてみる。

| | コメント (0)

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

チケット駆動開発の運用例を見つけたのでメモ。

【1】チケット駆動開発ってご存知ですか?

(引用開始)
コンピューター系の開発では有名なものなのですが、誤解を承知で平たく書くと、問題や、やらなくてはいけない事が発生したらそのチケットを書き全員でそれを共有しそれを全員で潰していくと言う開発手法です。
もっと平たく書くと、ToDoを共有してそれをみんなでやっていくやり方なのですが、この方法を建築で応用しようと現在がんばっています。
(引用終了)

2009年の記事で、建築業界にRedmineによるチケット駆動開発を運用しようとした話が載っている。
IT業界以外の業界でも、チケット駆動開発でタスク管理を行うアイデアは流用できるだろう。

但し、問題点は、上記の記事にもあるように、チケット管理ツールというソフトウェアよりも、実際の人の運用にある。

【2】「派生開発カンファレンス2013」プログラム

XDDPを加速させる開発プロセスに則したソフトウェア構成管理(ポスター)

(引用開始)
XDDPを加速させる開発プロセスに則したソフトウェア構成管理

発表者 : (株)テクマトリックス  会田 圭司

変更要求仕様書をベースとしたチケット駆動開発やトレーサビリティの確保を構成管理システムで実現する方法」をテーマとし、変更要求資料書の仕様をチケット化~疎粒度のTM図の生成までの流れをご紹介します。
また、過去のリリースソフトウェアへ対する影響分析を行う際などに効果を発揮する管理手法についても取り上げます。
(引用終了)

XDDPにチケット駆動開発を適用した事例。
XDDPとチケット駆動開発は以前から相性が良いと考えていた。
上記の事例では、チケット駆動開発におけるトレーサビリティとワークフロー管理に着目して、XDDPと組み合わせて運用しているようだ。

XDDPとAgile、TiDDは相性がいい: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

他にもあれば探してみる。

| | コメント (0)

2013/12/17

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例

JenkinsによるLinuxサーバの設定変更管理yggdrasilの運用事例を@tkusukawaさんが公開されていたのでメモ。

【元ネタ】
JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]

Home ・ tkusukawa/yggdrasil Wiki ・ GitHub

日々是精進。: yggdrasilを使ってみました。

ALMiniumによる yggdrasilサーバの構築: くすろぐ

Cacoo - yggdrasilの構成図

【1】JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]の記事がとてもよくまとまっているので、分かりやすい。

yggdrasilとは、Linuxサーバの設定ファイルをSVNでバージョン管理するためのコマンド(SVNのラッパー)。
Apacheの設定ファイルhttpd.confをSVN管理したい時、.svnなどの余分なファイルができてしまうので、yggdrasil サーバーに設定ファイルを同期した後に、SVNリポジトリへコミットする。

ygg check コマンドを使えば、対象サーバーとSVNリポジトリの設定ファイルのDiffを確認できる。
そのコマンドをJenkinsで定期的に動かし、差分が発生したら、メールで通知する仕組みを説明している。

本番サーバーの環境構築で嫌な問題は、設定ファイルが開発サーバーと違うために、ファイル名に日付を入れてバックアップしがちでゴミファイルが増えてしまうこと。
更には、どの設定ファイルが正しく動いていたのか分からなくなるために、サーバーのリプレース作業でゴミファイルを削除した後に必ず本番障害が発生しやすい問題もある。

yggdrasilの開発や導入は、その問題意識を持っている状況から生まれたようだ。

(引用開始)
【問題は概ね変更の中にある】

サーバの設定変更の問題が月日が経ってから発覚した、という経験はないでしょうか?
例えば、HDDの残量低下のアラートを受けてトレンドを確認したところ一ヶ月以上前に突然増加し始めていた、というような問題です。

ソフトウェア開発でバージョン管理システムを使っていると、試行錯誤した場合でも、どの部分をどう変えたのかを全て差分確認し、修正してみたけど結局は修正する必要が無かった箇所や、デバック用に入れたコードの戻し忘れをコミット前にきっちりチェックすることが出来ますよね。

サーバ設定の試行錯誤でも同様の手法が使えたら素晴らしいと思いませんか?
これを実現するのが yggdrasil になります。
全ての設定ファイルがSVNの リポジトリに反映されていれば 、設定ファイルの変更箇所を漏らさず確認することが出来ます。
意図しない設定変更は事故の元です。
明示的にコミット操作を要求することで変更に対する責任を明確にし、意図していない設定変更が混入することを回避できることになります。
(引用修了)

JenkinsによるLinuxサーバの設定変更管理(yggdrasil)の徹底 - Qiita [キータ]では、異常を見張って正常性を維持してくれる有能な執事:Jenkinsを使うことで、本番サーバーとSVNリポジトリの設定ファイルを同期するようにチェックする運用を強いる。

【2】「問題は概ね変更の中にある」という言葉はとても意味深い。
IT技術の本質は、常に変更が発生する点にある。
変更が必ず発生するという前提条件の元で、変更したがために、あるべき姿から少しずつ離れて、ある限界を超えると障害となって初めて現れる。

バージョンアップしないシステムやソフトウェアは、死んだ状態に等しい。
昨今は、ハードウェアやサーバーの性能向上、WindowsOSのバージョンアップが激しいため、3年おきにシステムリプレースないしハードウェアリプレースという無駄な作業が発生しがち。

その時に、過去に動いたシステムは変えずにハードウェアだけそのまま移行する(リホスト)はとても簡単な作業に思えるが、実際は、設定ファイルのゴミ掃除があったり、JavaやOracle、MySQLなどのミドルウェアのVerUpのために、プログラムのリコンパイルが発生したりする。
すると、システムの回帰テストの作業工数が発生し、うまく動かない機能が必ず出てくる。

例えば、昨今は、Windows7以降はIE11がデフォルトになってしまったために、クライアントアプリが正常表示しなかったり、正常動作しないケースがある。
こういう保守作業は、SIやベンダーにとってもあまりお金にならないし、ユーザも安定稼働するために無駄なお金を使うので、正直嫌なものだ。

いわゆるレガシーマイグレーションの落とし穴については以前書いた。

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい: プログラマの思索

システム移行の概念として、リビルド・リライト・リホスト・ラッピングの違いは抑えておくべき。

【3】サーバーの設定ファイルもバージョン管理しようという発想は、昨今のDevOpsで叫ばれている「Infrastructure as Code」にもつながる話だろう。

下記のBlogの内容が素晴らしい。

Infrastructure as Code - naoyaのはてなダイアリー

従来は、環境構築の手順書をExcelやVisioなどで作り、有識者でレビューした後に、環境を作り、構築テストを行なっていた。
だから、実際に作った後に初めて分かる障害も多かった。

でも、Chefのようなツールを使って、環境構築の手順そのものをプログラム化してしまえば、いつでも誰でも環境を再現できるようになる。
そして、環境構築プログラムそのものをコードレビューできるし、GitHubに入れて、Pull Requestを受け付けるようにすれば、複数人でテストしたソースをマージすることもできるようになる。
さらには、テスト自動化と継続的インテグレーションも入れれば、環境構築そのものもプログラミングと同じく、アジャイルに開発できる。

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

Chefのメモ: プログラマの思索

Chefで構築するRedmine環境: プログラマの思索

今後、DevOpsやクラウドは環境構築で必須の概念になるにつれて、クラウドデザインパターンというインフラ方式設計のベストプラクティス集も必要な知識になるだろうと思う。

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

今後も考えてみる。

| | コメント (0)

2013/12/14

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想

第28回関西IT勉強宴会でドメイン駆動設計の講演を聞いてきた。
講演よりも1時間の質疑応答の方がとても参考になった。
ラフなメモ書き。

【元ネタ】
第28回 関西IT勉強宴会 : ATND

関西IT勉強宴会のブログです: 2013-12-13(金)第28回関西IT勉強宴会 ドメイン駆動設計を知ろう

ドメイン駆動設計を知ろう(発表資料)

ドメイン駆動設計入門 - Digital Romanticism

ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築: プログラマの思索

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

SNSチームでのドメイン駆動設計の実践 | GREE Engineers' Blog

第53回 SEA関西プロセス分科会「ぐるぐるDDD/Scrum – モデリングと実装のうずまきをまわそう」-SEA関西

ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -: ソフトウェアさかば

【1】質疑応答は1時間ずっと続いたが、詰まる所「ドメイン駆動設計に出てくる「モデル」とは何ですか?」という質問に対して、延々と議論していただけだったように思う。

主催者の佐野さんから、ドメイン駆動設計に出てくるモデルは、WF型開発における外部設計または基本設計で出てくるモデルのように思えるが、そのモデルは分析モデルなのでソースコードではないから違うように思える、と質問があった。

ドメイン駆動設計では、モデルはソースコードで表現できるものと一致するので、コーディングできないモデルは含まれない。
つまり、ドメイン駆動設計のモデルは、システム化可能なモデルなのだ。

しかし、WF型開発であろうが、普通のシステム提案では、業務フローのうちシステム化する部分と従来の手運用の部分を分けて、システム開発の対象を絞る。
その段階のモデルには、帳票ベース、電話ベースの業務フローが含まれるので、システム化対象ではない。
なぜシステム化対象でないモデルも作るのか、という理由は、システムではなく、顧客の経営者の観点で、業務フローはどうあるべきか、を考えたいからだ。
だから、佐野さんの違和感はとても納得できる。

また、渡辺さんから、設計者としてのモデラーが見るモデルはどれか?という質問があった。
そこで僕が質問して、ドメイン駆動設計に出てくるドメインモデルは、渡辺式3要素分析法における機能構成ではないか。システム化されていない業務はドメイン駆動設計の範囲外ではないか、と話した。

渡辺式3要素分析法では、業務システムは、業務構成・機能構成・データ構成の3つの観点で作られる。
業務構成は業務マニュアルそのもので、ユーザ側から見たシステムのユーザインターフェイス層に相当する。
機能構成はプログラムそのもので、ドメイン駆動設計のアプリケーション層やドメイン層に相当する。
データ構成はデータ格納庫であり、ドメイン駆動設計のインフラストラクチャ層に相当する。
第28回 関西IT勉強宴会 : ATNDで佐野さんが説明されている通り、上記のようにDOAとドメイン駆動設計を対比させると分かりやすいと思う。

杉本さんからも、ドメイン駆動設計に出てくるモデルは実装モデルにすぎないのではないか、業務フローを分析するユーザの観点の分析モデルと開発者視点の実装モデルは一致しないのではないか、という質問があった。

お二人の意図は、ドメイン駆動設計に出てくるモデルは開発者視点の実装モデルにすぎないのではないか、だとすればユーザ観点の分析モデルとは一致しない。
すると、ドメイン駆動設計に出てくるドメイン(業務)はどのレベルでどのように説明しているのか、という内容だと推測する。

3人の方の話を聞くと、DOAの観点のモデルはユーザ観点の分析モデルであり、ドメイン駆動設計に出てくる実装モデルとは違う、と感じた。
だから、ずっと話が噛み合っていないから延々と議論していたのだと思う。

【2】これらの質問に対して、@sakaba37さんから、ドメイン駆動設計にもプロセスを含むのですね。
以前、原田騎郎さんのScrum+DDDの講演では、ドメイン駆動設計はインクリメンタルなプロセスでモデルを設計していくと聞いた。
つまり、ユーザ観点で最小の価値を実現する実装可能なモデルをコアとして作り、そこからモデルの境界を広げていく、と。

その話の観点では、ドメイン駆動設計のモデルは実装モデルを起点として作られるが、MVP(必要最低限の価値を持つ製品)から出発し、あるべきモデル、つまり分析モデルへ発展していくプロセスがドメイン駆動設計である、と理解することができる。
その実装モデルが分析モデルのレベルに到達した時、あるいは分析モデルと同等になった時が、ドメイン駆動設計に出てくる「ブレイクスルー」に一致するのだろうと思う。

つまり、ドメイン駆動設計では、分析モデルは作られるべき対象ではなく、実装モデルから発展した対象である、と理解できると思う。
その観点では、WF型開発の要件定義やシステム提案とは全く違う。

ドメイン駆動設計がそのようなモデルを必要として作られた背景としては、WebサービスやSNS、ゲームのように、最初から完璧に近いシステムを作るのではなく、最低限の機能を持つシステムを最初に作り、そこから少しずつ機能拡張していく状況にマッチしていることがあげられるだろう。

すると、ドメイン駆動設計を適用しやすい対象としては、ミッションクリティカルな基幹系業務システムや組み込みシステムではなく、スタートアップ企業のシステム開発の方が向いているのだろう。

【3】他に、UMLを使ったオブジェクト指向設計(OOA)とドメイン駆動設計は何が違うのか、という質問もあった。
確かに、ドメイン駆動設計はオブジェクト指向をベースとしており、何が違うのか、分かりにくい。

この質問に対しては、講演者から、ドメイン駆動設計はフレームワークのようにある程度、型が決まった手法であるのに対し、OOAはたくさんのやり方がある点が違う、と回答があった。

例えば、OOAの典型的な手法としては、ユースケースから概念モデルという分析モデルを作り、そこから実装モデルへ詳細化したら、ソースコードを自動生成してシステムを作っていくというモデル駆動開発(MDA)がある。
その観点では、コードと一体化した実装モデルの範囲や品質をイテレーティブに広げていくドメイン駆動設計と、分析モデルから作られる実装モデル(クラス図)を元にソースを自動生成して、設計から開発まで一気通貫で作るモデル駆動開発は全く違う。

【4】@sakaba37さんから、ドメイン駆動設計に出てくるユビキタス言語は、構造化設計で言うデータディクショナリと同じですか?という質問があった。
この質問に対して、講演者から、ユビキタス言語はデータだけでなく操作も含むので、データディクショナリ+αですね、と回答があった。

また、ユースケースはドメイン駆動設計に出てくるアプリケーション層に含まれるのか?と質問したら、講演者から、それは違う。ユースケースはドメイン層に含まれる。
エヴァンズは、ファウラーの定義であるドメインを拡張して、ドメインにはデータだけではなく操作も含むように定義した、と回答があった。

講演中に、ファウラーの本「エンタープライズ アプリケーションアーキテクチャパターン」のドメインはドメイン駆動設計では狭義の意味である、と話があったが、上記の意味であると思う。

いずれにしても、エヴァンズのドメイン駆動設計に出てくるドメインは、従来のオブジェクト指向設計よりも、かなり拡大定義しているように感じた。

【5】以上のように、僕も含めて、参加者のほとんどは、ドメイン駆動設計に出てくる「モデル」を理解できておらず、DOAや構造化設計、従来のオブジェクト指向設計の延長線上から理解しようとしていた。
だから、「ドメイン駆動設計に出てくる「モデル」とは何ですか?」という質問をずっと議論していた。

ドメイン駆動設計はメタ設計なので、話が抽象的で難しい。
にも関わらず、勉強会には40人もの参加者がいた。
ほとんどの参加者はドメイン駆動設計を理解できていないのに、何故、ドメイン駆動設計に惹かれるのか?
その理由は何だろうか?

僕の勝手な感想としては、ドメイン駆動設計には、XPやScrumに似たような匂いを感じる。
ドメイン駆動設計を読むと、「コンテキスト(文脈)」「境界づけられた文脈」「文脈の地図(コンテキスト・マップ)」「蒸留」などのプラクティスがあり、ナビゲーションマップのようなパターン言語らしき図もある。
そして、ドメイン駆動設計は、モデルの説明にコードを使っており、経験知に基づいた説明なので実践しやすい。

つまり、ドメイン駆動設計はパターン言語で語られている点が、アジャイル開発の構造に似ている。
XPやScrumはプラクティスというパターン言語として捉えられる。
プラクティス中心にアジャイル開発は説明されるので、開発者の観点では実践しやすく、とっつきやすい。

ドメイン駆動設計はパターン言語で語られているから、開発者はドメイン駆動設計に興味を持っているのではないだろうか?

僕がドメイン駆動設計に興味を持つ理由として、もう一つあげるならば、ソフトウェアプロダクトラインとの強い類似性を感じる点だ。
ドメイン駆動設計では、汎用的あるいは中心的なコアモデルから、個々のアプリケーションを作る方針の話が出てくる。
その観点は、コア資産を元に、少しだけ仕様が異なる派生した製品を作り出すプロダクトラインの話と構造的に同じだ。
あまり成功したとは言えないプロダクトラインをドメイン駆動設計の文脈で理論化したら、プロダクトラインにどのような価値を貢献できるだろうか?
その観点の思索を深めてみたいと思う。

| | コメント (0)

「Redmine超入門 (日経BPムック)」が発売されました

Redmine超入門 (日経BPムック)」が先日発売されました。
感想をメモ書き。

【参考】
Redmine超入門 《ITpro STORE/書籍》

shinagawa.redmine関係者が多数寄稿している「Redmine超入門」というムックが発売になりました。 - shinagawa.redmine

日経Systemsにredmineの記事を書きました: プログラマの思索

日経Systems2013年9月号にRedmineの記事が掲載されました: プログラマの思索

第5回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【1】日経Systemsに掲載された過去3年間のRedmineに関する記事を元に、Redmineに初めて触れるマネージャ向けに出版されました。
Redmine超入門 (日経BPムック)」はA4版でカラー付きなので、とても読みやすい仕上がりになっています。

(引用開始)
Excelでのプロジェクト管理はもう卒業!
導入現場急増中の注目ツールを使いこなそう

近年のIT現場で爆発的に普及が進んでいる、オープンソースソフトのプロジェクトマネジメント(PM)ツール「Redmine」の入門書です。
Redmineをこれから導入しようとしている現場、導入して日が浅い現場、活用をさらに進めたい現場向けに、導入・活用の手順およびノウハウをまとめました。

画面の流れに沿って操作方法を基本から解説しており、Redmine初心者でも迷わず導入が進めらます。
また、Redmineにさまざまな機能を付加するプラグインの解説、Subversion/Git/Jenkinsなどの他ツールとの連携設定の手順もわかりやすく説明しています。
さらに、これから職場や勤務先での利用を考えている方のために、スムーズな導入の勘所を開発の現場、運用の現場に分けて具体的にまとめました。
実際に導入して成果を上げている楽天やYahoo!の事例も詳しく紹介。プロマネやプロジェクト管理に携わる方は必読です。
(引用終了)

【2】個人的にお勧めの記事は、「IT現場のマストツールRedmine」、「お役立ちプラグインBest20」、「オールインワンパッケージEPM-X」です。

【2-1】「IT現場のマストツールRedmine」は、僕と@sakaba37さんの共著で、Redmineの概要を説明しました。
日経Systemsにredmineの記事を書きました: プログラマの思索で書いた記事を元に、Redmineの最新状況を反映しています。
Redmineで何ができるのか、WF型開発やAgile開発にどのようにRedmineを適用するのか、という内容がメインになります。

【2-2】「お役立ちプラグインBest20」では、Redmineの標準機能だけでは物足りない場合、利便性を向上させるプラグインを20個もあげています。
その中で、僕がRedmineを導入した現場で必ず入れるプラグインは、ImporterとWorkTimeの2つです。

Importerプラグインは、現場リーダーがプロジェクト立上げ時にWBSから詳細化したタスクをCSVで一括インポートする時に使います。
WorkTimeプラグインは、日々の実績工数を入力しやすくし、現場リーダーがタスクの予定/実績工数を週・月別に見たい時に重宝します。
上記2つのプラグイン共に、現場リーダーから使いたい、という要望が多いのが特徴です。
現場リーダーとしては、プロジェクト内のタスク全てをチケットで一括登録後、チケット管理を通じて、日々の開発者の進捗や実績工数を把握して、リスク管理したいと考えているからでしょう。

zh/redmine_importer ・ GitHub

WorkTime - Work Time - r-labs

もちろん、他のプラグインも導入できるならば、使った方がより便利になるでしょう。
但し、一部プラグインはRedmineのバージョン互換と合わない場合もあるため、事前検証のコストがかかりますので、注意が必要です。

【2-3】「オールインワンパッケージEPM-X」は、IPAがRedmineやTracをベースに開発したOSSのプロジェクト管理ツールEPM-Xに関する記事です。
EPM-Xについては、僕も興味を持っていて、ずっと追いかけていました。

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

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

チケット駆動開発を紹介した書籍一覧: プログラマの思索

記事では、EPM-Xを使った例として、下記の画面遷移でドリルダウンしながら、プロジェクト全体の進捗遅延の原因を究明していきます。

プログラム製造工程の進捗画面
→XXX機能製造の進捗画面
→単体テストで見つかった障害件数の推移
→障害の原因ランキング
→設計不一致が原因のタスク別障害検出件数

つまり、進捗が遅れた箇所を見つけたら、その箇所に関する情報は全てチケットとして蓄積されているので、工程別の進捗や品質の観点でメトリクス集計して原因を特定していく流れになります。
この手法は、特に、プロジェクトマネージャや品質管理者が分析に使いたい場面に相当するでしょう。

チケット&計測でITプロジェクト運営の体質改善」にも、EPM-Xを使って、ソフトウェア開発プロジェクトの進捗や品質を分析する事例が掲載されていて、参考になります。

僕はソフトウェア科学やソフトウェア工学を理論として習った経験はありませんが、ソフトウェア工学は本来、EPM-Xのようなツールを使って、定量的にソフトウェア開発プロジェクトを分析する手法を研究する分野であると考えています。
しかし、従来は、肝心のプロジェクトの定量データを収集しにくく、さらに集計するコストも大きかったという弱点があり、ソフトウェア工学は理論としては分かるが、実際に使えるのか、という疑問を僕も持ち続けていました。

でも、Redmineのような強力なITSをベースにしたチケット駆動開発が普及したからこそ、ソフトウェア工学は、従来は学者同士の議論に過ぎなかった部分があった状況から、開発現場のリーダーや開発者が使える学問になってきた方向へ変わりつつあると思います。

チケット&計測でITプロジェクト運営の体質改善」を読むと、個人的には、チケット駆動開発がソフトウェア工学へもたらしたインパクトはかなり大きいのではないか、という印象を受けているので、チケット駆動開発とソフトウェア工学の関係性についても今後考えてみたいと思います。


| | コメント (0)

2013/12/11

Jenkinsビルド後の処理でRedmineにチケット登録ができるJenkinsプラグインredmine-posttask-plugin

Jenkinsビルド後の処理でRedmineにチケット登録ができるJenkinsプラグインredmine-posttask-pluginの記事が公開されていたのでメモ。

【元ネタ】
Jenkinsビルド後の処理でRedmineにチケット登録ができるプラグインを作った話 - Qiita [キータ]

KokawaTakashi/redmine-posttask-plugin ・ GitHub

taskadapter/redmine-java-api ・ GitHub

(引用開始)
Jenkinsの「ビルド後の処理」に、「ビルド失敗時にRedmineにチケット登録をする」処理を追加できます。
(毎ビルド常にチケット登録する事も可能です)

ビルド結果の通知をメールではなくRedmineに登録してほしい場合や、ビルド失敗時の対応がSCM外にも発生する場合など、ジョブの実行結果に対する対応をRedmineに蓄積しておきたい場合に使う事を想定しています。
(引用終了)

上記の記事に書かれている通り、Jenkins上でビルド処理のジョブが失敗した時、Redmineへチケット登録する。
アーキテクチャとしては、Redmine REST APIを使っているみたい。

効果としては、Jenkinsのジョブが失敗した時、メール通知だけでなく、Redmineにもチケットが起票されるので、その後の障害対応がやりやすくなることがあるだろう。
ジョブ失敗のタイミングでチケットが起票されるので、障害の対応履歴がチケットに残り、その後のリリース作業や保守作業で参考になるだろう。

チケットにビルド失敗の履歴が蓄積されれば、その後の是正対策も取りやすくなるはず。
つまり、チケットはPMBOKで言う「組織のプロセス資産」(教訓)でもある。

| | コメント (0)

2013/12/07

iDempiereのインストール方法と画面キャプチャ

第9回Adempiere勉強会(アデンピエレ勉強会)に行ってきた。
オープンソースERPのiDempiereのデモ画面で受注→出荷→請求という基本操作を学んで、少しだけiDempiereの使い方を教わった。
iDempiere(アイデンピエール)のインストール方法と画面キャプチャをメモ。

【元ネタ】
iDempiere(アイデンピエレ)のインストール Windows7 - OSS ERP Compiere Distribution Lab

iDempiere(アイデンピエレ)の開発環境構築 - OSS ERP Compiere Distribution Lab

自分がやらねば誰がやる!:iDempiere

idempiere / iDempiere / ダウンロード ? Bitbucket

Open Source ERP Users Group / the 9th Meetup : ATND

Table of Contents ja - ADempiere ERP Wiki

ERPはなぜ難しいのか?~オープンソースERPで業務改革を試したい: プログラマの思索

iDempiereの資料: プログラマの思索

【1】Windowsへのインストール方法

JavaとPostgresSQL(またはOracleXE)が必要。

以下、PostgresSQLをインストール

PATHに
C:\Program Files\PostgreSQL\9.2\bin
を追加

PgAdminを起動
Postgersのサービスを起動する

C:\idempiere-server
に解凍する

PostgresSQLのSQL画面で、DBユーザを追加

# su - postgres
 $ psql
 # ALTER ROLE postgres with password 'postgres';
 # CREATE ROLE adempiere SUPERUSER LOGIN PASSWORD 'adempiere';
 # ALTER ROLE adempiere SET search_path TO adempiere, pg_catalog;
 # \q

コマンドプロンプトから、iDempiereのデータベース作成

cd C:\Program Files\PostgreSQL\9.2\bin

 $ createdb --template=template0 -E UNICODE -O adempiere -U adempiere idempiere
 $ exit

パスワード:adempiere を設定しておく。

C:\idempiere-server\setup.bat
を実行する。

初期画面に初期値を設定する。
テストボタンを実行して正常確認する。
下記参照。

00_idempiere_setup

cd C:\idempiere-server\data\seed
jar xvf Adempiere_pg.jar

psql -d idempiere -U adempiere -f Adempiere_pg.dmp
を実行して、テーブルと初期データをインポートする。
先ほど設定したパスワード:adempiereを入力する。
テーブルが約900個近く作られる。

C:\idempiere-server\idempiere.exe
を実行すると、Tomcatが起動して、サーバー側のiDempiereが起動される。

http://localhost:8080/
にアクセスして、
User「SuperUser」、Password「System」でログインする。

真ん中上にあるMenuボタンをクリック。
System Admin > General Rules > System Rules > Languageと辿る。

言語設定画面で日本語を選択する。
日本語は中間付近の50番台で画面送りが面倒なので虫眼鏡アイコンで検索した方が早い。

翻訳ファイルもインポートする。
System Admin > General Rules > System Rules > Translation Import/Export を選択後、
ClientとLanguageにそれぞれ「System」「Japanese」を選択し、Importボタンを押す。

「data」ディレクトリをダブルクリック。
「ja_JP」ディレクトリをクリックし選択状態として緑チェックを押す。

メニュー>一般ルール>システムルール>システム翻訳チェック で日本語を選択する。

ログアウトして、日本語で再ログイン

なお、iDempiereのクライアントは、Webブラウザからアクセスする場合と、Swingクライアントからアクセスする場合の2つがある。
業務システムの場合、リッチクライアントが好まれやすいから、ブラウザよりもSwingクライアントの方が使いやすいだろう。
なぜなら、大量の伝票データを入力して編集する場合が多いのに、ブラウザでは画面の状態を保持されないから誤って消えてしまうリスクがあるから。

【2】iDempiereの画面キャプチャ

iDempiereで、受注→出荷→請求の画面キャプチャを載せておく。
WebのUIは、アイコンがわりと直感的。
どのERPもユーザインターフェイスがとても使いにくい弱点があるが、iDempiereは多分すぐに操作に慣れるだろう。

販売管理だけでなく、生産管理や会計もある。
但し、僕はiDempiereの詳細はまだ知らない。
でも、ERPのほとんどの機能はあるので、業務システムを初心者が勉強する時、iDempiereを触れば分かるだろうと期待している。
デモの時に、萩原さんからいくつかアドバイスが合ったのでメモしておく。

01_idempiere

01_iDempiereログイン画面

必ず組織と倉庫を選択する。
倉庫を選択しないと、出荷できないチェック処理がiDempiereに入っている。
その理由は、倉庫に属さない担当者が勝手に入出荷(受払い)すると、業務もデータも何でもありになってしまうから。

02_

02_受注伝票入力

03_

03_得意先検索

iDempiereでは、「ビジネスパートナー」という概念が、得意先・取引先・従業員などのアクターを含む。
つまり、ビジネスパートナーと得意先・取引先・従業員は、ファウラーのアナリシスパターンである知識操作パターンに相当している。

04_

04_受注伝票明細入力

05_

05_受注伝票明細入力の詳細画面

06_

06_品目情報検索

07_

07_伝票ステータス更新

初期状態の伝票ステータスは「草案」。
ドラフトの意味であり、何度も修正や削除もできる。
伝票ステータスを「完成」へ更新した後は削除できない。
その理由は、内部統制上、一度起票した伝票は理由なしに消せないから。

08_

08_出荷伝票の選択

09_

09_納品書印刷

10_pdf

10_納品書出力

PDFで出力される。
帳票レイアウトはカスタマイズ可能。
印刷(レポート)アイコンを押せば、何度でもPDF出力できる。

11_

11_売上請求伝票検索

12_

12_請求書印刷

13_pdf_2

13_請求書出力

14_

14_売上請求伝票画面で転記ボタン押下

「入金済み」ボタンは押せない。
別画面で入金情報を入力してデータ連携されなければ、押せない仕組みになっている。
つまり、売掛金回収が必要。
すなわち、債権管理機能と連携している。

転記ボタンを押すと仕訳が作られる。
iDempiereの背後で、出荷時に既に仕訳が自動で作られているらしい。
(Tomcatで自動仕訳の別サービスが起動しており、ポーリングで動いている?)

請求画面で請求書を発行する時は、既に仕訳があるので、転記ボタンを押すだけで良い。
iDempiereはリアルタイムに自動仕分けされるのが特徴の一つ。

aDempiereやCompiereは、自動仕訳するか確認するボタンがあるらしい。
つまり、aDempiereやCompiereは、自動仕訳を主導でキックするかどうか、判断する機能がある。
仕訳のトランザクション量が多い場合、リアル連携よりもバッチ処理の方が良いので、そのような仕掛けが別途必要かもしれない。

15_

15_仕訳生成

単なる仕訳だけでなく、組織や品目、取引先などの会計ディメンジョンも追加されて生成されているので、管理会計の観点で分析も可能。

【3】iDempiereで今後知りたいのは、2つある。

一つは、オープンソースERPのマーケットである中小企業に対し、iDempiereの運用がどこまで可能で、どんな部分をカスタマイズすれば運用の範囲内におさまるのか?
iDempiereの導入コスト、カスタマイズのコストは、顧客である中小企業が耐えうる範囲内か?

もう一つは、iDempiereが持つ生産管理や所要量展開の機能は、実業務に耐えうる機能のレベルにあるのか?
本でしか知らないMRP2の理論が、実際にiDempiere上で操作できて実験可能であるか?

僕としては、理論でしか知らないMRPやら原価計算のロジックをオープンソースのツールで実験してみたい。
そして、実業務の運用に耐えうるのか、試してみたい。


| | コメント (0)

2013/12/06

MVCモデルのバリエーション

「ドメイン駆動設計はMVCモデルの後継者である」という指摘を見つけた時に、MVCモデルに幾つかのバリエーションがあるのに気づいた。
ファウラーのUIパターンが参考になる。
まとまりがないラフなメモ書き。

【元ネタ】
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - @IT

matarillo.com: UIパターン

MVVMパターンの常識 ― 「M」「V」「VM」の役割とは? - @IT

お世話になります。 MVCとMVC2の違いについて、質問させてください。 - Yahoo!知恵袋

- デザインパターンによる進化的設計

Interactive Application Architecture Patterns

エリック・エヴァンスのドメイン駆動設計に沿ってSymfony2でユーザー管理アプリを作ってみたsoichiro.org ブログ | soichiro.org ブログ

分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ - Memorandum by zerobase

【1】Smalltalkの古典的なMVCモデルでは、UI=ビュー、ドメイン(データとその振る舞い)=Modelに相当する。
Controllerは、パソコンなどからの入力に相当する。
Modelが更新されるたびに、画面のUI情報が即座に変わって表示される。
MVCモデルの基本は、ModelとViewの厳格な区別。
いわゆるObserverパターンがその根底にある。

matarillo.com: UIパターンによれば「Fowlerの説明では、GUIコントロールはビューとコントローラーがペアになっているらしい。」
だからこそ、Observerパターンで、モデルが更新されるとビューも更新される。

しかし、MVCモデルの問題点は、Modelの状態の保持や、UIの状態の保持をどの層で実装すべきか、にある。
そして、そこから派生した問題として、ビジネスロジックを実現するオブジェクトとデータ永続層の間で、ORマッピングのインピーダンス・ミスマッチが発生する点がある。
この問題が根底にあると分かれば、その後の流れの理解はさほど難しくない。

【2】J2EEのようなWebアプリの設計では、MVC2モデルがある。
MVC2モデルでは、View=JSP、Controller=リクエストの入出力処理、Model=業務ロジック+永続層になる。
普通は、Modelがドメイン駆動でなく、ListやMapを駆使した手続き型ロジックになりがち。
ORマッピングはJavaなら、かなりたくさんの種類があった。

RailsのようなフルスタックのWebフレームワークでは、ActiveRecordがORマッピングを吸収し、インピーダンスミスマッチをほぼ解決した。
但し、ビジネスロジックをどこにおくべきか、については、まだ論争があるようだ。

しかし、ドメイン駆動設計の4層アーキテクチャならば、下記のように整理されるので、MVC2モデルでもドメイン層が明確になる。

・ユーザーインターフェース層=Webシステムで言うView
・アプリケーション層=Webシステムで言うController
・ドメイン層: すべてのビジネスロジックを集約した実装
・インフラストラクチャ層=Webシステムで言うModel

【3】MVCモデルの問題点を解決するには、いくつかの方法がある。
以下、matarillo.com: UIパターン開発者が知っておくべき、6つのUIアーキテクチャ・パターン - @IT参照。

プレゼンテーションモデルは「ドメインロジックだけを含むモデルをラップし、プレゼンテーションロジックを含むようなモデル(=プレゼンテーションモデル)を用意すると言うもの。」
ドメインに関係する属性や振る舞いは通常のモデルに委譲する。
プレゼンテーションに関係する属性や振る舞いはプレゼンテーションモデルが担当する。
モデル側を改良したシンプルなパターン。

アプリケーションモデルは、プレゼンテーション関連のロジックは具象アプリケーションモデルに置き、アスペクトアダプターが具象アプリケーションモデルとモデルとのバインドを担当する。
最近のマイクロソフト界隈では、アプリケーションモデルの派生パターンであるモデル・ビュー・ビューモデル(MVVM)というUIパターンが語られているらしい。

モデル・ビュー・プレゼンター (MVP)は、コントローラの代わりにプレゼンターを導入し、プレゼンターがユーザー入力をモデルに伝える役割だけでなく、ビューを直接更新する役割を担う。
「ビューがモデルを監視するものを「監視コントローラ」、ビューがモデルを監視しないものを「パッシブ・ビュー」と呼んで区別することもある。」

これらのUIパターンを見ると、色んなモデルを用意して、それぞれの状況(文脈)に応じてMVCモデルの問題点を解決しようとしているのが分かる。

【4】これらUIパターンを整理したファウラーは、モデラーというよりも科学者のように思える。
その理由は、新しい概念を提唱するというよりも、コミュティやIT業界で知られているバラバラな経験や知識を整理して、それにネーミングして、新しいアイデアとして売り出しているからだ。

例えば、古くは「リファクタリング」「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)」、最近なら「エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)」「ドメイン特化言語」の本を思い出す。
これらの本は、一つの辞書のように使えて、その中でネーミングされたパターンを他の人に話せば、コミュニケーションが成り立ち、議論が進む。
例えば、「知識操作パターン」「勘定パターン」「ActiveRecord」「トランザクションスクリプト」などのパターンがあるだろう。

ファウラーは、既にある程度知られているノウハウや知識を、パターンという形式を用いて理論化して体系化するのが上手いように思える。


| | コメント (0)

2013/12/04

チケット駆動開発を紹介した書籍一覧

最近、チケット駆動開発に言及した本がチラホラ見かけられる。
内容と感想をラフなメモ書き。

【1】「アジャイル概論」「わかりやすいアジャイル開発の教科書

いずれもアジャイル開発の文脈でチケット駆動開発を紹介している。
わかりやすいアジャイル開発の教科書」はタスク管理の観点、「アジャイル概論」はバージョン管理との連携に焦点を当てている。
アジャイル概論」では、バージョン管理ツールにコミットした時、コミットログに記載されたチケットNoがpost commit-hookされる点も記載している。
つまり、No Ticket, No Commitの運用ルールが実現できること、さらにそこからJenkinsのようなCIツールへつながる点も説明している。
チケット駆動開発の特徴の一つであるツール間連携に繋がる話だ。

【2】「本当に使える開発プロセス

チケット駆動開発をタスク管理の観点だけでなく、ALM(Application lifecycle management)の観点に焦点をおいている。
すなわち、進捗や障害の見える化だけでなく、開発プロセス全体をカバーする基盤としてチケット駆動開発を説明している。
ALMにチケット駆動開発を適用できるアイデアは、「チケット駆動開発」の10.8節「Application lifecycle management」でも既に触れている。
おそらく、MicrosoftのTFSやIBMのRational Team Concertが最終製品になるだろうと思う。


【3】「チケット&計測でITプロジェクト運営の体質改善

【3-1】チケット駆動開発をソフトウェア工学におけるソフトウェアメトリクスの収集・集計・分析の観点に焦点をおいている。

従来のソフトウェア工学の問題点は、肝心のメトリクスの元ネタとなるデータの収集や集計そのものが大変である点だ。
障害管理票や課題管理票を紙ベースの帳票で運用していた時代では、メトリクスの元ネタとなるデータを帳票から手で集めて、更に集計し直す手間がかかっていた。
ソフトウェア開発の作業そのものがIT化・自動化されていなかったのだ。
だから、メトリクスを収集・集計する仕組みを導入しようとすると、開発者の作業コストが大きくなる問題がずっと続いていた。

だから、ソフトウェア工学を論じようにも、肝心のデータがないために研究の障害が大きかったのではないかと思う。

しかし、チケット駆動開発という仕掛けによって、チケットに作業や障害、課題などプロジェクト内部の情報が全て入力・蓄積される。
よって、そのチケットを色んな観点で集計すればいい。

すると、チケット管理ツールは2つの観点で語ることができる。
一つ目は、チケット管理ツールはPMBOKにおけるPMIS(プロジェクト管理情報システム)と同一であることだ。
つまり、チケット管理ツールは、ソフトウェア開発のERPなのだ。
その主張は「Redmineによるタスクマネジメント実践技法」の8.3節「Redmineと外部ツールを連携」で既に触れている。

もう一つは、チケット管理ツールはメトリクス収集ツールとしてソフトウェア・リポジトリ・マイニングに使えることだ。
つまり、ビジネスインテリジェンス(BI)の観点で、チケット集計結果を分析することができる。
その主張も「Redmineによるタスクマネジメント実践技法」の8.2節「測定できれば制御できる」で既に触れている。

【3-2】「チケット&計測でITプロジェクト運営の体質改善」では、IPAが作った定量的プロジェクト管理ツールEPM-Xを元にメトリクスを出力し、ソフトウェア工学の知識を使って、プロジェクトの進捗やシステムの品質を分析評価している。

定量的プロジェクト管理ツール(EPM-X):IPA 独立行政法人 情報処理推進機構

EPM-XはRedmineをベースに、データ変換やデータ分析などの機能を追加した大規模なチケット管理ツールだ。
読者対象はプロジェクトマネージャや品質管理者であり、アジャイル開発に興味を持つ人やプロジェクト管理に興味のない開発者ではない。
実際、アジャイル開発に触れた部分は数ページだけ。

むしろ、WF型開発にチケット駆動開発を導入した場合、どのように運用すればどのような効果が得られるか、についてEPM-Xを元に説明している。

【3-3】「チケット&計測でITプロジェクト運営の体質改善」で興味深い点はいくつかある。
一つは、チケットの2大機能として、「作業内容の分類と記録」「作業の指示・受け渡し」に分類している点。

前者の例は障害管理票や課題管理票など、入力項目の多い帳票が相当する。
管理者が集計結果を元に分析する機能に力点を置く。
だから、入力項目が多くなり、開発者の作業負荷が大きくなりやすい。

後者の例は、タスクカードやWBSにおける作業が相当する。
管理者が作業を指示し、開発者が作業指示書に基づいて作業する機能に力点をおく。
作業をスムーズに行うことに力点を置くため、集計・分析が弱い。

この分類は、チケットをメトリクス収集として扱うか、ワークフローで管理するものとして扱うか、という観点で分けているように思える。
つまり、チケットの使い道、使う目的が異なるのだ。

もう一つは、チケット発行契機として「フィーチャ型」「WBS型」に分類している点。

前者は機能単位の開発スタイル。
機能の実現に重きをおくため、運用保守やアジャイル開発に適用しやすい。
主な特徴しては、作業の経過は積極的に管理せず、開発が終了次第、順次リリースしていく点に力点を置く。

後者はトップダウンによる作業管理の開発スタイル。
管理者がプロジェクト全体の作業をWBSで洗い出して詳細化し、進捗やコストを管理していく。
普通はWF型開発に適用しやすい。
メトリクス収集ツールとしてチケット管理ツールを扱う場合、こちらの観点で運用する方が、たくさんのメトリクスを得られる。

この分類は、チケット駆動開発をアジャイル開発に適用するのか、WF型開発に適用するのか、という観点で分けていると考えた方が分かりやすいと思う。

【3-4】「チケット&計測でITプロジェクト運営の体質改善」を読んでいて思うのは、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」で著したアイデアが、実際の具体例で詳しく説明されている点だ。

チケット&計測でITプロジェクト運営の体質改善」では、チケット管理ツールから得られた進捗や品質に関するメトリクスを分析すると、どのような評価や結果が得られるのか、について、「第6章 計測事例に学ぶプロジェクト運営の体質改善」でとても詳しく説明している。
この章はとても参考になる。

EPM-Xはプロジェクト管理に役立つ情報を収集し、これらの情報をビジネスインテリジェンス(BI)を活用してグラフ化して可視化するシステムである、という指摘はまさにそうだ。(P.54)
Redmineによるタスクマネジメント実践技法」の8.2節「測定できれば制御できる」で既に触れている。

また、チケット管理ツールから得られたメトリクスを複数プロジェクトの異常検出で使う方法は、発電所の中央制御室に多数の表示器があり、特定の異常値を早く検出するために使われるのと同じという文章がある。それは、モニタリングツールのコックピット型活用方法であるという指摘はまさにそうだ。(P.105)
Redmineによるタスクマネジメント実践技法」の8.1節「PMBOKのEVM」で、パイロットが操縦する時の計測器に例えた内容と同じだ。

4.4 進捗管理では、EVMによる予実管理にも触れている。
EVMの実現方法のアイデアは「Redmineによるタスクマネジメント実践技法」で既に出しており、どのように実装するか、という点が興味があった。
但し、個人的に残念なのは、PV・AC・EVをチケットにどのようにマッピングするのか、という説明が省略されていた点だ。
特に、EVをチケットでどのように実現するのか、という点は、アジャイル開発とWF型開発では全く違う。
その違いについて、もう少し説明が欲しかったと思った。

「おわりに」では、今日のソフトウェア開発の最重要課題が「説明性と追跡性」であると書かれている。
この理由は、現代のソフトウェア開発では、単にプロダクトをリリースすれば良いだけではなく、正しいプロセスでちゃんと作れているか、というシステム監査の観点も重要であるからだ。
その観点はチケット駆動開発がサポートできるという点が本書の主張なのだろうと思う。

他には、参考文献のトップに「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」が記載されているのが正直嬉しかった。

他にも色々探してみる。

| | コメント (0)

2013/12/03

ドメイン駆動設計の意義~MVCモデルの後継、パターン言語で語られる、ソフトウェアプロダクトラインの再構築

@digitalsoul0124さんのBlogを読んで、自分は「ドメイン駆動設計」を完全に理解していないことに気づいた。
ラフなメモ書き。
論理的な文章でないので後で直す。

【元ネタ】
ドメイン駆動設計入門 - Digital Romanticism

モデルが息づく場所 - Digital Romanticism

戦略的デザインに関する意思決定のための6つのエッセンス - Digital Romanticism

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

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

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

ドメイン駆動設計を考え直す: プログラマの思索

【1】ドメイン駆動設計入門 - Digital Romanticismの記事を読むと、「ドメイン駆動設計」のエッセンスをとても鮮やかにまとめているのが分かった。

業務システム開発において問題になるのは、設計モデルをSEが業務の専門家であるユーザからヒヤリングして作り、開発者に設計書に従って実装してもらうやり方はとてもロスがあること。
プロジェクトの関係者全員が共通して理解し合える業務知識(ユビキタス言語)がないのだ。
そのために、コミュニケーションロスが発生しがちで、最後のテスト工程でその事実がようやく判明する。

ドメイン駆動設計では、ユビキタス言語という概念で、プロジェクトの全員が理解し合える業務知識を共有し、モデルを育てていく。
モデルが実装モデル(浅いモデル)から分析モデル(深いモデル)へ変わる瞬間はブレイクスルーと言われ、そのタイミングでモデルの品質が一気に上がる。

ドメイン駆動設計の第7章に出てくる「ブレイクスルー」は、

ウォーターフォール型開発では、アーキテクチャは計画される
RUPでは、アーキテクチャは成長すべきものだ
アジャイル開発(XP)では、アーキテクチャは出現する

の3行目を連想させる。

そんな背景を考えると、ドメイン駆動設計は開発者のための設計技法であるように思える。
業務の専門家や設計者が設計するのではなく、開発者が中心となって、モデルを設計し、コアドメイン(コア資産)を抽出(蒸留)していく。

ドメイン駆動設計」を読み直して改めて気づいた点は、「MVCモデルの後継者である」「ソフトウェアプロダクトラインの再構築に相当する」「パターン言語で語られる」の3つだ。

【2】ドメイン駆動設計はMVCモデルの後継者である

ソフトウェアのアーキテクチャ設計の基本は、レイヤ化モデルであり、MVCモデルであるように思える。
Smalltalkの実装技術から生まれたMVCモデルは、J2EEによるWebアプリではMVC2モデルに引き継がれた。
しかし、MVC2モデルでは、Controllerにロジックを書く労力が多すぎて、本来のMVCモデルではない。

ドメイン駆動設計入門 - Digital Romanticismでも書かれているように、「リクエストに対する処理を手続き型に記述するスタイルが、いわゆる「トランザクションスクリプト」」のスタイルが多い。
実際、「「モデルは業務処理を書く場所」と覚えて、アプリケーションの実装に入った方がほとんどだと思うのですが、そこで実際に書いているコードは、if/forを駆使してList/Mapを操作するというスタイルが多いのではないでしょうか。」

ドメイン駆動設計では、4つのレイヤー型アーキテクチャが提唱されている。
・ユーザインタフェース(プレゼンテーション)レイヤ
・アプリケーションレイヤ
・ドメインレイヤ
・インフラストラクチャレイヤ

@hatsanhatさんが言われるように、渡辺式三要素分析法(DOA)と対比させると、
・ユーザインターフェイス層:業務構成
・ドメイン層:機能構成
・インフラストラクチャ層:データ構成(ER図)
に相当する。
つまり、業務システムの設計モデルにおいても、MVCモデルで整理することができる。

この考え方では、システムを使うユーザ企業の担当者は、機能構成図(あるいはユースケース図)で示した機能からシステムを理解している。
また、業務システムのロジックは、業務フロー図などで表現されており、ドメイン駆動設計ならドメイン層、渡辺式三要素分析法なら業務構成で表現される。
この部分が設計の腕の見せ所。
インフラ層はデータ層であり、それはクラス図ないしER図で表現される。

MVCモデルをきちんと適用できれば、Controllerの肥大化やトランザクションスクリプトで設計・実装する必要もなく、もっと綺麗なモデルになるはず。

【3】ドメイン駆動設計はパターン言語で語られる、

ドメイン駆動設計」を改めて読み直すと、ユビキタス言語、境界づけられた文脈、文脈の地図、の説明文の中に「それゆえ」という単語があるのに気付く。
「それゆえ」の内容は、Coplienのパターンにおける解決策に相当しているのだ。

また、ナビゲーションマップがパターン言語になっているのが分かる。
ユビキタス言語、境界づけられた文脈、文脈の地図などの概念が矢印で結ばれているのは、それぞれの概念はバラバラではなく、一つの体系として見るとパターン言語になっていることを意味しているのだと思う。

実際、ナビゲーションマップは組織パターンに出てくるパターン言語の構造にとてもよく似ている。

そんな観点で読み直すと、「ドメイン駆動設計」は読んでいて、とても気持ちいい。
抽象的な設計技法の本ではなく、現場で試行錯誤しながら生み出された設計技法であると感じられて、共感できるからだ。

【4】ドメイン駆動設計はソフトウェアプロダクトラインの再構築に相当する

ドメイン駆動設計は単なるオブジェクト指向設計ではなく、ソフトウェアプロダクトラインの再構築ないし実装プロセスとして捉えるべきではないか、と思っている。

ソフトウェアプロダクトラインでは、多品種少量生産の開発プロセスとして提唱された。
例えば、AppleのiPod/iPhone/iPadのように、多数の製品系列は共通基盤の上に仕様が微妙に異なるアプリケーションを実装していくのに使われる。
ドメイン駆動設計で出てくる概念を下記のように、ソフトウェアプロダクトラインに当てはめてみると、とても理解が進む。

ソフトウェアプロダクトラインの概念としては、共通基盤となるモデルであるコア資産が、ドメイン駆動設計ではコアドメインに相当する。
そして、コア資産の抽出が、ドメイン駆動設計では蒸留というプロセスに似ている。
プロジェクト内部の全員が共有しているモデルはユビキタス言語で語られるが、これはプロダクトの業務知識に相当するだろう。
境界づけられた文脈は、モデルのコンテキスト(文脈)が適用できる有効範囲であり、その範囲を超えると別の意味になる場合がある。

ドメイン駆動設計の第14章「モデルの整合性を維持する」P.347に出てくる「境界づけられたコンテキスト内での分派を認識する」とは、ホノニムやシノニムに相当するだろうと思う。
つまり、一つの概念が、人によっては別の意味に捉えられてしまうことを意味しているのだろう。

それら文脈間の関係は文脈の地図で整理され、大局的に理解できるようにする。
それは、システムの業務知識を一つの地図として見渡せるようにすることに対応している。

システムが大規模になるにつれて理解しにくくなるが、システムのメタファを用いて、モデルの要素を表す具体的な比喩で理解して深める。
その理解を更に深めて蒸留して、ユビキタス言語に取り入れる。
本来はXPのプラクティスであるメタファから発生しているらしいが、モデルを理解するプロセス(メタファ→ユビキタス言語)に相当するだろうと思う。

このように、ドメイン駆動設計に出てくる概念はとても抽象的だが、ソフトウェアプロダクトラインにマッピングさせると、まさにソフトウェアプロダクトラインを実装しているかのように思える。
ソフトウェアプロダクトラインの弱点は、コア資産の抽出が難しいことと、技術の変化についていけずにコア資産が陳腐化してしまうことなどがあげられる。
でも、ドメイン駆動設計を使って、反復的にモデルを蒸留させていけば、うまくいく可能性があると思う。

但し、ドメイン駆動設計を適用できる有力な事例がソフトウェアプロダクトラインであるとすれば、ドメイン駆動設計はかなり敷居の高い手法であるかもしれない。
なぜなら、ソフトウェアプロダクトラインは10年以上前から研究されて実践されているのに、実際は、再利用できるコア資産の抽出が難しかったり、開発プロセスにコストがかかりすぎるなどの弱点を言われ続けてきたからだ。
ドメイン駆動設計がソフトウェアプロダクトラインの弱点をカバーできるならば、おそらくうまくいくのではないか?

そのアイデアも考えてみる。

【追記】12/13にドメイン駆動設計の勉強会があります。興味のある方はご参加ください。

第28回 関西IT勉強宴会 : ATND

| | コメント (0)

2013/12/02

CEGTestによる原因結果グラフの書き方

昨日開催されたシステムテスト自動化カンファレンス2013の資料で、「モデルベースドテスト入門 -テスト詳細設計を自動化しよう- #stac2013」がとても参考になったのでメモ。
ラフなメモ書き。

【参考】
12月1日 システムテスト自動化カンファレンス2013 #stac2013(東京都)

【1】原因結果グラフと他のテスト技法の比較

資料が下記で公開されている。
興味深い点は、設計書で記載された仕様(モデル)として状態遷移モデル、論理モデル、組み合わせモデルの3つがあり、それらをベースとしたテスト技法として、状態遷移テスト、デシジョンテーブルテスト、組み合わせテストに分類されることだ。

設計モデルをベースとしたテストなので、プログラムの内部構造は見ず、入出力び外部インターフェイスによるテストになるから、ブラックボックステストになる。
状態遷移テスト、デシジョンテーブルテスト、組み合わせテストのいずれも、モデルからテストケースを自動生成できる点が魅力的だ。

状態遷移モデルは、UMLのステートマシン図をastahで描いて、astahの品質スイートプラグインから遷移パターンのシナリオを出力できる。

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

状態遷移表プラグインを使って、電話のステートマシン図を作成・改善する ? astah-QualitySuite 1.2 documentation

論理モデルはデシジョンテーブルを作ればいい。
デシジョンテーブルは原因結果グラフと同値であり、CEGTestというツールを使うと、原因結果グラフからデシジョンテーブルを自動生成できる。

ソフトウェアテストの勉強室: 原因結果グラフ

ソフトウェアテスト技法ドリルの感想: プログラマの思索

組み合わせモデルは、HAYST法や直交表、All Pair法を使う。
簡単なツールとしては、PICTや、PICTをExcelマクロに取り込んだツールPictMasterを使えばいいだろう。

データパターンの組み合わせからテストケースを自動生成するツール: プログラマの思索

PICTで出力したテストケースをTestLinkへ取り込む: プログラマの思索
いずれもテストケースの元ネタを作成するツールがあり、かなり使える点が魅力的だと思う。
その中で、興味を持つのは、原因結果グラフだ。

以前から、テストケース生成ツールとして、astah品質スイートプラグイン、PICTを実際に使ってみた。
しかし、エンタープライズ系の業務システムでは、仕様が確定している状況でシナリオベースのテストが多く、その場合はデシジョンテーブルを使う時が多い。

状態遷移テストや組み合わせテストは探索的テストで使うケースが多い。
会員の状態遷移を探索テストしたり、クライアントのOSとブラウザの組合せで回帰テストしたりする時には使えるが、主流のテストではない。
結合テストやシステムテストで、仕様に基づいた外部インターフェイスのテストをしたいのだ。
その時、仕様を原因結果グラフで描いてデシジョンテーブルに落とし、テストケースの品質を上げるという方向を試せるのではないかと考えている。

【2】softest.jp | 原因結果グラフ技法の解説(1)

原因結果グラフの書き方は、CEGTestの作者である加瀬さんの公開資料が分かりやすい。
ソフトウェアテスト技法ドリル」にも原因結果グラフの説明がある。

原因結果グラフは、初心者にとって難しい。
ソフトウェア開発者は手続き(フロー)の順に考えるのが普通なので、集合ベースで考えるとか、論理回路のような絵で考えるのは、頭の使い方が違うので、すぐには使いこなせないのが普通だと思う。
だから、実際にサンプルを使って、たくさん書いて慣れるのが良いと思う。

原因結果グラフのサンプルとして、下記で色々公開されているので、試してみると面白い。

ソフトウェアテストの勉強室: 原因結果グラフ


【3】CEGTestで原因結果グラフを描く時の注意点をまとめてみた。

CEGTest - 原因結果グラフからテスト条件を作成するツール


・ノードをつないで、原因と結果をつなげる。
・AND、OR制約は、ノードのプロパティから選択できる。
・NOT制約は、線を選択して、ノードを2回クリックして「NOT原因」を表示し、結果とつなげる。
・ONE~MASKの制約は、メニューから選択する。

・CEGTestでは、UNDO、REDOが実装されていない。
 (UNDOはメニューにあるが「未実装」と表示された)
 だから、逐一エクスポートしてバックアップした方がいい。

・原因結果グラフやデシジョンテーブルはCSV出力できる。

・ノードのプロパティにある「観測可能」は、ノードの真偽がテスターが観測できるか否かの判定を表す。
 中間ノードの真偽が決定しない場合に使う。
 使い道はよく分からない。

【4】原因結果グラフの注意点

上記のサンプルを見ると、簡単な例におけるテストケースでもかなり複雑な原因結果グラフになる。
例えば、Meyersの三角形のテストもそうだ。

原因結果グラフが複雑になりやすい理由の一つは、ONE~MASKなどの制約が発生するからだろうと思う。
単なるAND・OR・NOTだけで、テストケースが完成するのではないのだ。

制約の内容については、下記が詳しい。

softest.jp | 原因結果グラフ技法の解説(1)

ONE制約は、唯一つがTRUEの制約。
必ず一つの要素(ノード)が入力条件になる。
例えば、必須のラジオボタン、必須のプルダウン。
男性・女性など。

EXCL制約は、高々一つがTRUEの制約。
0個または1個の要素(ノード)が入力条件になる。
例えば、必須でないラジオボタン。
6歳以下、65歳以上など。

INCL制約は、少なくとも一つがTRUEの制約。
1個以上の要素(ノード)が入力条件になる。
例えば、必須で複数個選択できるチェックボックス。
所有PCの種類として、Windows、MacOS、Linuxなど。

REQ制約は、Aが真であるにはBが真であることが必要という制約。
例えば、商品画面で商品を購入するには、商品ボタンが表示されることが必要。

MASK制約は、Aが真であればBの真偽は不明という制約。
例えば、クリップボードにデータがなければ、右クリックの貼り付け機能はDisableになる。

これらの制約の注意点は下記の記事が詳しい。

原因結果グラフの「制約のテスト」: ソフトウェアテストの勉強室

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その1


ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その2

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その3

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その4

原因結果グラフを描くのが難しい理由はいくつかある。
まず、「ソフトウェアテスト技法ドリル」にも書かれているが、中間ノードを見出すのが難しい。
良い中間ノードがでないと、ケースに不備が多い。
解決策としては、結果ノードから原因を追いかけるようにして、中間ノードを作り出す。

そして制約条件を付けるのが難しい。
制約条件を上手く利用すれば、テストケースを減らすことができる。
少なくとも、ONE、EXCL、INCLの制約は使いたい。

ソフトウェアの品質を学びまくる:原因結果グラフとCEGTestに関する考察 - その1において、の『ソフトウェアテスト技法ドリル』の例題「ロック状態の携帯電話を解除するには、指紋認証を行うか端末暗証番号を入力する。」に対し、「A:指紋認証パス」と「B:暗証番号パス」にEXCL制約をつけた場合、カバレッジ表には「AもBも偽」というケースがそもそも現れないと書かれている。
その理由は、EXCL(A + B)とは、AまたBの結果が真でありかつ高々1個という制約だから、AもBも偽であれば、矛盾するからだ。

REQは、前提条件を満たさなければ、結果を選択できない場合に使う。
例えば、注文ボタンの表示や、優遇会員の登録などが思いつく。

MASKは、入力条件を変えると結果ノードがDisableないし非表示になってしまう場合に使う。
例えば、「ソフトウェアテスト技法ドリル」では、期間検索で終日チェックボックスを押すと、時刻テキストボックスが消える例が載っている。
WebのUIで、何かのチェックボックスを選択すると、テキストボックスが消えたり、ボタンが押下不可になる場合があげられるだろう。

原因結果グラフを使いこなした場合、どこまでテストケースの品質を向上できて自動生成できるか考えてみる。


| | コメント (0)

2013/12/01

第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy

第9回RxTstudy勉強会の感想をラフなメモ。

【元ネタ】
第9回RxTstudy : ATND

第9回RxTstudy Redmineやタスク管理を考える勉強会@大阪 - Togetter

Lychee Gantt Chart Plugin | Lychee Enterprise

【1】井垣先生の講演は、Tracによるチケット駆動開発を教育に適用した事例。
4日間の合宿で、学生にソフトウェア開発だけでなく、ソフトウェア工学やアジャイル開発も経験してもらう目的があるみたい。
プロジェクトベースの教育(PBL:Project Based Learning)では、成果物やプロセスの評価が難しい点と、一部の学生に負荷が集中して学生全員に教育の機会が均等にならないという課題があった。

チケット駆動開発を導入すると下記2点が解決される。
一つは、チケットに作業情報が記録されるため、リアルタイムないしその日のうちに、成果物やプロセスのメトリクスを計測でき、フィードバックできる。
2つ目は、受講記録がチケットに残るため、早めにフィードバックすることで、学生に的確に指導できる。
たとえば、チケットに見積り工数、実績工数、タスクの種類、ステータスが記録されるので、バーンダウンチャートで即座に残タスク量を出力できる。

ソフトウェアメトリクスがチケット駆動開発で簡単に計測できる点を上手く利用している感想を持った。

興味深かったのは、Scrumというアジャイル開発フレームワークがPBLという教育スタイルにとても合っている点。
その理由は、Scrumはフレームワークとしてプロセスが定義されているので教えやすいことと、スプリントレビューやふりかえりという活動がフレームワークとして定義されているので教員や学生がフィードバックできる機会がある点があげられた。

チケット駆動開発を教育に適用した事例としてとても興味深かった。

【2】@daiskyさんの講演は、Gitの続きのお話。
Gitを正しく使いこなせなかったために、GitHubにおけるブランチの絵が東京メトロ線のように複雑になってしまっていた。
質問で聞いたら、masterとプライベートブランチをPullで同期せず、そのままPushしてコンフリクトが起きてしまい、一括マージ(sqush)やさくらんぼ摘みマージ(cherry-pick)で修正しようとして逆に被害が拡大したらしい。

そこで、「入門Git」を全員で読みなおして、Gitをまともに使えるようになったら、GitHubのブランチの絵もかなりすっきり綺麗になったらしい。

資料にある複雑なマージの絵は、再現できないものもあったらしい。
確かに複雑過ぎる。

質問タイムで聞いて印象に残ったのは、チケット駆動開発の観点では、Gitを使うと過去のコミット履歴が改変できてしまうため、No Ticket, No Commitの運用ルールが使えなくなること。
ブランチにコミットしてチケットNoを残しても、最後に一括マージしたり、つまみぐいマージしたり、リベースしたりしたら、コミットログに過去のチケットNoを書き足さないといけない。
また、チケット単位にトピックブランチを作る運用(No Ticket, No Fork)もそこまで手間をかけるほどの理由がなかったとも言っていた。

つまり、GitとRedmineを組み合わせた場合、チケット駆動開発の根本的な運用ルールであるNo Ticket, No Commitを活かしづらい場面がある。
この点は、今後のチケット駆動開発の課題となるだろう。

現実的な解決方法としては、git-svnを使って、masterは中央集権管理としてチケットNoを残すようにする方法も考えられる。
トレーサビリティという利点をいかに生かすか、という観点で、Gitの運用方法は再考する必要があると思った。

【3】川端さんのスポンサーセッションでは、RedmineのガントチャートのUIを大幅改良した機能が公表された。

Lychee Gantt Chart Plugin | Lychee Enterprise

RedmineのガントチャートをMSProjectのように使えるように、Redmine上でタスクを移動できたり編集できたりするように改良したらしい。
このような機能が売れる理由としては、大企業でMSProjectのライセンスを一括導入する場合、数十万~100万円もかかることがあげられる。

MSProjectはガントチャートだけでなく、PERT図やリソースグラフ、リソースの平準化などの豊富な機能があるけれど、おそらく普通のマネージャはガントチャートぐらいしか使いこなせていない。
だから、Redmine上でガントチャートを自由自在に編集できれば、開発者のタスク管理と連動しているので、作業しやすくなる利点があるのだろう。

勉強会のデモで興味深かったのは、EVM PluginとAssociation Chart Pluginだ。
Redmineのチケット集計機能を使えばEVMを実現できることについては、僕のBlogで何度も書いてきた。

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

【公開】講演資料「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索

マネージャとしては、スケジュール管理だけでなくコスト管理もとても重要な仕事だ。
EVMをRedmine上で実現できれば、コスト管理も行えるだけでなく、スケジュール管理はガントチャート、リスク管理はチケットによる課題管理を使うことで、プロジェクト管理に関わる全ての作業をRedmine上で一括作業できる。
ExcelやMSProjectに進捗データをインポートして、残業しながらシコシコ作業する必要はないのだ。

また、とAssociation Chart Pluginは、関連チケットの関係をグラフ化した機能を実現している。
Association Chart Pluginプラグインを入れると、「親子」「関連」「先行」「後行」などのチケットの関係をグラフ化できる。
例えば、親子チケットで要件と作業をWBSとして階層化した場合、一つの要件から発生した作業の漏れがないか、と言うチェックにも使えるだろう。

Association Chart Pluginの今後の使い方としては、「先行」「後行」のチケットの関係がグラフ化されるので、MSProjcectのPERT図のように表現して、クリティカルパスを見つけるという使い方にも発展できる。
すなわち、ガントチャートというビューは、PERT図と同値であるので、ビューを切り替えることで、色んな観点で進捗を分析できるはずだ。

そのアイデアについては、以前Blogで書いた。

チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索

Redmineのガントチャート機能改善の要望チケット: プログラマの思索

以前のBlogでは、チケットの先行・後行関係をGraphvizで変換してグラフ表示するアイデアを披露したが、上記のプラグインでかなり綺麗に実現できている。
Association Chart Pluginが更に良い点は、Association Chart Plugin画面上でチケットの関連を編集できるので、クリティカルパスを考えたり、WBSの詳細化を考えながら、PERT図やWBSを修正できる点だ。

RedmineでWF型開発を行う場合、Association Chart PluginやEVM plugin、ガントチャートを使いこなせれば、Redmine上でプロジェクト管理の作業の殆どを操作できるだろう。
つまり、Web上でプロジェクト管理の作業を全て実現できる可能性を秘めている。

以前のBlogで書いたように、MSProjectの全ての機能はRedmineで実現できると確信している。

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

MSProjectとRedmineの機能比較、フィットギャップ分析は今後の主要な課題になるだろうと思う。
Redmineが日本で普及していくうえで、重要なきっかけであると考えているからだ。

久しぶりのRedmine勉強会だったが、今後のRedmineやチケット駆動開発の課題に気づかせてくれて面白かったと思う。

| | コメント (0)

« 2013年11月 | トップページ | 2014年1月 »