« 2015年5月 | トップページ | 2015年7月 »

2015年6月

2015/06/30

マイクロサービスとドメイン駆動設計の設計思想のメモ

@yusuke_arclamp さん、@sugimoto_keiさんが、マイクロサービスとドメイン駆動設計の設計思想に語っているつぶやきが参考になったのでメモ。
以下は、疲れた頭で思いついたことを書き殴り。
間違っていたら後で直す。

【元ネタ】
マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い - Togetterまとめ

Martin Fowler氏がマイクロサービスの特徴について語る

マイクロサービス移行の代償

マイクロサービスとSOA

マイクロサービスアーキテクチャとは何か - arclamp

SOAとマイクロサービスを複合設計に当てはめると見えるもの: ソフトウェアさかば

マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで -: ソフトウェアさかば

さかばさんはTwitterを使っています: ".@akipii こんなのもあります。バズワードと考えると「うちはすでにこうやってる」というのがお決まりでしょうかね。/マイクロサービス,アプリケーション,システムを比較する http://t.co/pCTFSxO8r7"

【1】マイクロサービスとは結局、何なのか?

それは、@sugimoto_keiさんの下記のつぶやき「マイクロサービスの粒度は境界づけられたコンテキストと同程度」で、全ては言い尽くされていると思う。

杉本啓さんはTwitterを使っています: "マイクロサービスってのの元記事、初めて読んだ。サービスの粒度は、DDDで云うところの「境界づけられたコンテキスト」とだいたい同じ程度を想定してるんだね。「マイクロ」と呼ぶと、極端に小さな粒度を想定しているような誤解を与えないかね。http://t.co/VkJF8vQ7tV"

また、Webサービスの設計思想は、CORBA→SOA(例:SOAP)→マイクロサービス(例:REST)に至る歴史と同じ。
この辺りは、@yusuke_arclamp さんの記事「マイクロサービスアーキテクチャとは何か - arclamp」が詳しい。

今は、目的さえ合致すれば、オープンデータやマッシュアップのように、公開されたWebサービスのAPIを使ってすぐに手軽なWebシステムを作るのは簡単になっている。
その時の設計思想として、マイクロサービスという概念を用いることは有益だろう。

そして、マイクロサービスが過去のSOAと違って細かく使い勝手のいいAPIにしたい場合、ドメイン駆動設計の「境界づけられたコンテキスト」が使えるレベルにすればいいのだろう。
そうすれば、ドメインの枠内で一つのコンポーネントのように扱えるだろう。

【2】オブジェクト指向設計とデータモデリングの違いは何なのか?
一つの観点として、@yusuke_arclampさんのつぶやきが一つの解答になるのではないか。

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "そもそもオブジェクト指向は時間軸を表現するのは苦手。とはいえ時間軸をベースにする方式では集約がされずに再利用ができなくて効率が悪いという問題があります。だからモデリングによって時間軸における空間配置を検討し、適切なバランスを探すことが重要になります。"

たとえば、商品と倉庫というエンティティがあった場合、在庫はどんな概念として提示すべきか?という問題があったとする。
良くあるダメな例は、在庫エンティティを商品と在庫の連関エンティティで作ってしまう例だろう。
オブジェクト指向設計では、単純に、商品エンティティと倉庫エンティティの間に在庫エンティティを普通に作ってしまいがち。
在庫は、エンティティとして抽出すべきものではないと思う。

在庫は、商品の状態。
在庫から、どの時点の商品や倉庫に関連付けられるか、トレースできなければならない。

在庫は、倉庫の入出庫トランザクションから導出されるサマリテーブルとして作るべき。
つまり、在庫は、入出庫トランザクションから定期的にバッチで集計されるサマリテーブルであるべき。

オブジェクト指向設計は、「~マスタ」のようなリソース型エンティティを分析するのは強いと思う。
しかし、オブジェクト指向設計はトランザクションテーブルの分析は弱い気がする。

むしろ、データモデリングの方が、タイムスタンプを主キーに持たせることによって、トランザクションテーブルに時系列を強力に設置する仕掛けがあるような気がする。

| | コメント (0)

2015/06/28

Redmineは帳票ワークフローシステムであるというアイデア

@sakaba37さんから「Redmineは帳票ワークフローシステムである」という指摘を受けて、自分が持っていた疑問がかなりストンと落ちたので、メモ。
ラフなメモ書き。

【参考】
Redmineは帳票ワークフローシステム?: ソフトウェアさかば

【1】Redmineによるチケット駆動開発を研究して、それを広めたいと思っている僕にとって、Redmineに関する根本的疑問が二つある。

一つは、Redmineのチケットとは、そもそも何なのか?
もう一つは、なぜ、日本のSIや製造業のシステム子会社や情報システム部門で、Redmineの導入に興味を持ったり、運用しようとする事例が多いのか?

【2】Redmineのチケットが面白い点は、色んな業務に適用しやすい特徴があることだ。
元来、チケットは障害管理票だった。それがBTSになる。
そして、チケットは課題管理票でもある。それはITSになる。

【2-1】「Redmineによるタスクマネジメント実践技法」で書いた内容は、チケットはXPのタスクカードであり、作業指示書であるというアイデアから派生されるメリットや可能性をひたすら書いたこと。
アジャイル開発なら、チケットはタスクカードやストーリーカードに相当する。

【2-2】WF型開発なら、チケットはWBSになるだろう。
Redmineのチケットが親子チケットの構造を持ち、さらに無制限の階層構造を持つ特徴から、チケットをそのままWBSにマッピングできるからだ。

他の例では、ヘルプデスク管理やシステム保守サポートなら、チケットはインシデントまたはQA票になる。
あるいは、PC資産管理に使うなら、チケットはPC資産管理票になるだろう。

Redmineを見積書や経費などの簡単な申請承認フローで使うならば、チケットは申請書に相当する。

【2-3】以上の例のように、「~票」「~カード」「~書」のたぐいのものは全て、Redmineのチケットに置き換えることができる。
つまり、下記のイメージだ。

チケット→対応するシステム
.----
1)障害管理票→障害管理システム(BTS)
2)課題管理票→課題管理システム(ITS)
3)タスクカード→アジャイル開発のタスクボード
4)WBS(作業指示書)→WF型開発の作業管理
5)インシデント票→ヘルプデスク管理、製品保守サポート
6)資産管理票→PC資産管理
7)申請書→事務処理の申請承認ワークフローシステム

【3】なぜ、Redmineのチケットはこれほど多様な場面に適用できるのか?
その理由は、Redmineには柔軟なワークフロー管理機能があること、ガントチャートのような強力なチケット集計機能がデフォルトであること、チケットやプロジェクトが無制限の階層構造を持つこと、バージョン管理と連携してトレーサビリティを実現できる、という特徴があるからだろう。

@sakaba37さんによれば「Redmineは帳票ワークフローシステムである」。
その意味は、たぶん、帳票はほとんどRedmineチケットにマッピングでき、帳票のステータス制御はRedmineのワークフロー管理で実現できることだ。

実際、帳票の各項目はカスタムフィールドを使えばいい。
帳票の種類ごとに、トラッカーを対応付けて、ワークフロー管理すればいい。

つまり、簡易なワークフローであれば、Redmineでほぼ実現できてしまうのだ。
但し、「簡易なワークフロー」という意味は、「ある申請書は5万円未満は課長決裁、5万円以上は部長決裁」などのような複雑な分岐を実現するワークフローではないこと。

Redmineは事務処理の申請承認ワークフローに使えるか?: プログラマの思索

すなわち、Redmineのチケットは帳票そのものであり、Redmineは帳票ワークフローシステムとして使われるべき対象。

すると、Redmineチケットは、フローなのか、ストックなのか、という議論も出てくる。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

【4】Redmineに至るまでの歴史を辿ってみると、日本人は帳票が大好きな組織文化があるのではないか、という仮説がある。

例えば、「Redmineによるタスクマネジメント実践技法」にも記載しているが、80年代頃から日立では、ソフトウェア開発の作業をB票・P票・C票という帳票で制御していたらしい。

swtest.jp/wiki/tools - PukiWiki

それらは、障害管理票(B票)、仕様変更管理票(C票)、プログラム変更票(P票)に対応する。
彼らは、紙ベースで障害管理・変更管理・構成管理のプロセスを標準化し、運用していたのだ。

【4-1】このうち、障害管理票(B票)はBTSに自然にマッピングできる。
すなわち、障害管理プロセスに相当する。
僕の考えでは、障害管理こそがソフトウェア開発の基本的なプロセスだろうと思っている。

【4-2】仕様変更管理票(C票)は、変更管理プロセスから生まれるものである。

実際、障害管理やソフトウェア保守をやっていれば、仕様変更は自然に出てくるワークフローなので、障害管理のワークフローにおいて、ステータスの読み替えで運用することで対処できる。
ワークフロー管理の機能が不足していたMantisやTracではよくやっていたことだ。

しかし、「ステータスの読み替え」は、開発チームごとのローカルルールになりやすく、新規参入の開発者は混乱するし、開発プロセスとしても標準化しにくい弱点があった。

【4-3】プログラム変更票(P票)は、プログラムのバージョンアップなどの構成管理に関するたぐいのもの。
構成管理プロセスに相当する。

しかし、構成管理で発生した作業内容と、本来の要件や仕様変更と結びつける作業は手作業でやっていたから、非常に煩雑だった弱点があった。

こういうやり方を帳票やExcelを使って、開発プロセスを標準化した人たちはすごいな、と思う。

【4-4】@sakaba37さんの話を聞いて、理解した流れは下記になる。

そういう状況に対し、MantisやBugzillaがBTSとして表れて、障害管理はWeb化された。
しかし、変更管理はステータスの読み替えという弱点が残り、構成管理とチケットの連携はプラグインによる対応という弱点が残ったままだった。

そして、Tracは、「チケット」という概念に昇華することで、障害管理だけでなく変更管理も一つのタスク管理に含めてしまった。
また、SVNリポジトリブラウザやWikiを内蔵することで、構成管理とその発端となった要件や仕様を連携する機能を編み出した。
しかし、Tracではワークフローをカスタマイズするのが難しい弱点は残ったままだった。

そんな中で、RedmineがMantisやTracよりも優れている点は、Tracの機能をクローンにするだけでなく、ワークフローをWeb上でいくらでも追加編集できるようにして、ガントチャートをデフォルト機能に含めてしまったことだ。
これによって、Redmineは進捗管理できる特徴を持ち、進捗管理のプロセスが入り込んだ。
すると、Redmineはプロジェクト管理全般に適用できるようになる。

つまり、障害管理、変更管理、構成管理をRedmineという一つのツールでカバーできるだけでなく、進捗管理できることから、プロジェクト管理そのものを実現する方向へ発展した。

Redmineのチケットにソフトウェア開発に関するあらゆる情報が集約され、蓄積されることで、スケジュールや品質、コストに関する情報をいくらでもチケット集計すれば、欲しいメトリクスを出力できるのだ。
すなわち、Redmineでプロジェクト管理のQCDをすべて収集し、コントロールできるようになる。

個人的には、Redmineでプロジェクト管理を全て済ませるようにしたいならば、アジャイルウェア(株)が販売しているLycheeEVMやLycheeGanttChartのようなツールの機能が必要になるだろうと思う。

【5】また、日本のソフトウェア開発では、スクラッチ開発も多いが、実際はソフトウェアの改造や保守がかなり多い。
すると、改造作業や保守作業では、トレーサビリティがすごく重視される。

たとえば、なぜこんなソース修正が必要なのか、本来の要件や仕様へ辿って検討する必要がある。
これは、前方追跡に相当するだろう。

あるいは、この要件や仕様に対して、機能は実装されているのか、リリースされたのか、をチェックする必要もある。
あるいは、OSやDBのバージョンアップに対し、この機能はどこまで保証されていて、どこを修正したのか、をチェックする必要もあるだろう。
これは、後方追跡に相当するだろう。

すなわち、元々あるシステムに対し、仕様追加や障害修正などで手を加える場合、変更管理や構成管理のプロセスを整備しなくてはならない動機がある。
つまり、Redmineの特徴の一つである「チケットと構成管理の連携」を使って、トレーサビリティをシステム的に実現する仕掛けを使って解決すればいい。

【6】そんなことを思うと、Redmineは日本人に向いたソフトウェアなのかもしれない。
つまり、日本には帳票文化があり、改造作業の案件が多い状況では、オープンソースでありながら、十分に多機能であるRedmineが適用しやすい場面が多いのだろう。
その仮説を他の事例でも検証してみたいと思う。

| | コメント (0)

2015/06/20

Redmine3.0.3をWindows7にインストール時はJRubyを使うと上手くいく


Redmine3.0をWindows7にインストールする手順をメモ。

【参考】
RedmineをWindowsにインストールする手順: 9th Ghost

Windows の Ruby で native extension を使う - akishin999の日記

Azure Web Apps 上で JRuby を使って Redmine 3.0.3 を動かす - しばやん雑記

Redmine2.5をwar化してTomcatで動かしてみた~warbler | Scimpr Blog

Redmine 3.0.0をJRubyで動かす→ダメだった… | u6k.log()

akipiiさんはTwitterを使っています: "Windows のインストールはBitnami 以外はあきらめた方が良いです。RT @mzsm_j: Redmineのインストール方法を調べるたびに「面倒くさいしもういいや…」って感じになってる"

【1】結論を言うと、Windows7にRedmine3.0.xをインストールするのは失敗した。
すごくハードルが高くなった。

Rails4.2をインストールするのに、Development Kit がいるみたいだが、いつも失敗する。
Ruby2.2もダメで、Ruby1.9に落としても、僕の環境ではうまくいかなかった。
gemのインストールでいつも失敗する。

【2】CRuby+Windowsの環境はなかなか作れないが、JRuby+Windowsの環境はさくっと作れた。
その時のメモを残しておく。
但し、JavaVM、JRubyはできるだけ最新バージョンにしておくと良いみたい。
古いバージョンのJRubyでは、インストールに失敗する時がある。

【2-1】セットアップ情報

OS:Windows7 SP2 64bit
JRuby:jruby1.7.20.1 (1.9.3p551) 2015-06-10 d7c8c27 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_11-b12 +jit [Windows 7-amd64]
XAMP:1.8.3

+ Apache 2.4.4
+ MySQL 5.5.32 (Community Server)
+ PHP 5.5.11 (VC11 X86 32bit thread safe) + PEAR
+ phpMyAdmin 4.0.4
+ OpenSSL 1.0.1e
+ ADOdb 5.18
+ Mercury Mail Transport System v4.62 (not included in the portable version)
+ FileZilla FTP Server 0.9.41 (not included in the portable version)
+ Webalizer 2.23-04 (not included in the portable version)
+ Strawberry Perl 5.16.1.1 Portable
+ Tomcat 7.0.41
+ XAMPP Control Panel Version 3.2.1 by hackattack142 (Great Thanks!!))
See: http://www.apachefriends.org/f/viewtopic.php?f=16&t=46743
+ XAMPP Security
+ XAMPP mailToDisk 1.0 (write emails via PHP on local disk in \mailoutput. Activated in the php.ini as mail default.)

Redmine Environment:
Redmine version 3.0.3.stable
Ruby version 1.9.3-p551 (2015-06-10) [java]
Rails version 4.2.1
Environment production
Database adapter MySQL

【2-2】Redmine on JRubyのインストール手順

事前にJRubyをPATHに登録しておく。

mysql.exe -uroot
create database redmine303 character set utf8;

redmine/database.yml
を開き、database: redmine303 へ修正

jgem install bundler --no-rdoc --no-ri

jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install activerecord-jdbcpostgresql-adapter

cd %REDMINE_ROOT%
jruby -S bundle install --without test development sqlite3

次のメッセージが出るが無視する。

io/console not supported; tty will not be manipulated
Using rake 10.4.2
Using i18n 0.7.0
Using json 1.8.3
Using minitest 5.7.0
Using thread_safe 0.3.5
Using tzinfo 1.2.2
Using activesupport 4.2.1
Using builder 3.2.2
Using erubis 2.7.0
Using nokogiri 1.6.6.2
Using rails-deprecated_sanitizer 1.0.3
Using rails-dom-testing 1.0.6
Using loofah 2.0.2
Using rails-html-sanitizer 1.0.2
Using actionview 4.2.1
Using rack 1.6.2
Using rack-test 0.6.3
Using actionpack 4.2.1
Using globalid 0.3.5
Using activejob 4.2.1
Using mime-types 2.6.1
Using mail 2.6.3
Using actionmailer 4.2.1
Using actionpack-action_caching 1.1.1
Using actionpack-xml_parser 1.0.2
Using activemodel 4.2.1
Using arel 6.0.0
Using activerecord 4.2.1
Using activerecord-jdbc-adapter 1.3.16
Using jdbc-mysql 5.1.35
Using activerecord-jdbcmysql-adapter 1.3.16
Using coderay 1.1.0
Using thor 0.19.1
Using railties 4.2.1
Using jquery-rails 3.1.3
Using net-ldap 0.3.1
Using protected_attributes 1.0.9
Using ruby-openid 2.3.0
Using rack-openid 1.4.2
Using bundler 1.10.4
Using sprockets 3.2.0
Using sprockets-rails 2.3.1
Using rails 4.2.1
Using rbpdf 1.18.5
Using request_store 1.0.5
Using tzinfo-data 1.2015.5
Bundle complete! 27 Gemfile dependencies, 46 gems now installed.
Gems in the groups test, development, sqlite3 were not installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.

jruby -S bundle exec rake generate_secret_token

次のメッセージが出るが無視する。

io/console not supported; tty will not be manipulated
NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us f
inish 4.2 support - check http://bit.ly/jruby-42 for starters

jruby -S rake db:migrate RAILS_ENV=production

jruby bin/rails server webrick -e production

新しいバージョンのRailsでは、Webrickの起動方法が「script/rails」から「bin/rails」変わったみたい。
次のメッセージが出るが無視する。

io/console not supported; tty will not be manipulated
NOTE: ActiveRecord 4.2 is not (yet) fully supported by AR-JDBC, please help us f
inish 4.2 support - check http://bit.ly/jruby-42 for starters
=> Booting WEBrick
=> Rails 4.2.1 application starting in production on http://localhost:3000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server

http://localhost:3000/
にadmin/adminでログインしてOK

【2-2】但し、2015/6時点のJRubyには、@marutosijpさんの指摘のように問題がある。

Toshi MARUYAMAさんはTwitterを使っています: ".@shibayan @akipii JRubyのARがサポートしてないのでサポートしてません。 https://t.co/WG86r9ejkt"

akipiiさんはTwitterを使っています: "@marutosijp @shibayan 「JRubyはサポートしていない」のが正しいわけですね。own my Riskということですね。"

実際、Redmineのビルド状況を見ると、Ver3.0.3はJRubyに正式対応していない。
つまり、JRuby+Redmine3.0.xは自己責任になる。

Redmine build status

【2-3】ついでに、warbleを使って、redmine.warを作ってTomcatにデプロイしたら、成功した。
Ver3.0.3でも、RedmineをWar化できるみたい。
但し、Rails4.2でのAR-JDBCの問題は残っている。

事前に、Redmine3.0.3をインストール済み

gem install warbler

cd %REDMINE_ROOT%
warble config

%REDMINE_ROOT%\config\warble.rb
を修正

config.dirs = %w(app config db lib log script vendor tmp)
config.bundle_without = ["development", "test"]

warble

%REDMINE_ROOT%にredmine.warが作られる

%XAMPP%\tomcat\webappsへredmine.warを配備する

XAMPコンパネからTomcat起動

http://localhost:8080/redmine
でログインできた

【3】でも、Windows上のRubyはかなり手ごわい。
たぶん、RubyはMacやUnix上で使うもの、という前提があるのだろう。

もはや、Windows上では、BitnamiのRedmineをインストールするしか方法がないのかもしれない。

【追記】
2016年前半時点では、「Redmine does not support JRuby because some gems do not support Rails 4.2.」という記載がある。あくまでも自己責任で。

RedmineInstall - Redmine

| | コメント (0)

LycheeのWebページに住友電装株式会社のRedmine運用事例があった

LycheeのWebページに住友電装株式会社のRedmine運用事例があった。
ラフなメモ書き。

【参考】
住友電装株式会社の事例 | Lychee Enterprise

(引用開始)
【問題点】
・Excelの表組みでは要件、計画、構成管理の進捗反映がリアルタイムに行えない
・ファイル共有ではファイルが壊れたり誤記が発生
・プロジェクトで作成した文書やプログラムのファイル改変履歴を別表で管理しているため、一元管理できない

【課題】
・ファイル破損、誤記の要因を排除したい
・管理状況が即座に更新・共有でき、進捗確認を円滑に行いたい
・改変履歴の管理なども一元化し、管理対象を集約したい

【導入効果】
・業務効率化によるコスト削減
・マネージャーと現場メンバーの認識を統一
・プロジェクト情報を複数名が同時に更新でき、正確な情報共有が実現
・タスクの細分化、関連性、担当者などが明確に
(引用終了)

【1】名古屋の会社で自動車関係の部品生産に携わっている事業内容からして、ソフトウェアにも機能安全などの品質保証が厳しく要求されている背景があると推測される。
もちろん、ソフトウェア開発でも、標準の開発プロセスに則り、システム監査にも耐えれるような仕組みを要求されているのだろう。

そんな現場にRedmineを導入し、さらに、アドオン製品Lycheeを入れて導入効果をあげたらしい。

個人的に興味深かった点はいくつかある。

【2】一つは、「当社では長らくExcel帳票を用い、工夫しながら計画管理・要件管理・プロセス管理・構成管理を行ってきました」という点。
Redmine導入前から、Excel帳票で大変だったろうとはいえ、ソフトウェア開発に必要な管理作業はプロセスとして標準化されていたと推測される。
勝手な憶測では、CMMIレベル3の管理されたプロセスまで到達していたのではないだろうか。

つまり、現場では既に、ソフトウェア開発の作業手順や構成管理などが整備されていたので、Redmineというツールを導入しやすい雰囲気があったのだろう。
Redmineを導入したがなかなか根付かないという話を聞く時、よく内容を聞いて見ると、それはRedmineの問題以前の話だよね、というツッコミを入れたくなる時が多い。

そもそも、障害管理票を書いた経験がない、とか、SVNとかバージョン管理って何?、とか、WBSによるスケジュール管理はどうやるの?とか、そういう質問が、Redmine以前にあるのだ。
つまり、ITリテラシー不足、プロジェクトマネジメント経験不足のために、Redmineを導入しても、思い通りに効果を上げることができない、という結果になりがち。
すると、Redmineを使いながら、障害管理や課題管理の運用方法を説明して慣れること、GitやSVNを使いながらRedmineに慣れていくことが必要になってくる。

幸いなことに、Redmineは色んな運用パターンが可能であるので、あるチームは障害管理、別のチームは課題管理から運用を始める、と言ったPJ管理が可能だ。
また、SVNやGitでソース管理を初めてRedmineと連携させると、すぐにその利点も分かってくる。

すなわち、ERP導入と同じように、ERPの機能に含まれているベストプラクティスに慣れるように運用すれば、自然に良い開発作法も身に付く。

Redmineも同様に、Redmineの機能に含まれているベストプラクティスに慣れた方がいい点もあるし、色んな利用シーンに応じて運用パターンを変えることができる点が、Redmineのメリットの一つ。

【3】2つ目は、「Redmineに関してはマニュアルを配布したり、説明会を行ったりしましたが、Lycheeについては説明会を開く必要もなく、導入後に操作がわからないという問い合わせもなかったので、システム導入担当者としては負担が軽いと感じています」という点。

いくらRedmineやLycheeが良いと分かって導入したとしても、現場には初心者もいる。
その人達のために、説明会を開いたり、マニュアルを作ったりする必要がある。
ERP導入の場合、普及促進の活動のコストが結構大きいのだ。

だが、上記のコメントを読むと、RedmineやLycheeはさほど標準化活動のコストが低いように見受けられる。
実際、Lychee製品のデモに触れてみると、特に、Lychee GanttChartはUIがとても直感的で操作しやすい。

例えば、先行後続関係を引きたい時、最初は戸惑うが、ダブルクリックして「+」ボタンが出てきて、別のガントバーへ線を引けるようになる。
他に、ガントバーそのものをドラッグ&ドロップで移動できたり、右クリックしたらチケット編集できるなど、結構面白い。

最近、ユーザエクスペリエンスやアジャイルUXなど、ユーザインターフェイスの重要性をよく聞くが、マニュアル無しで操作できるのは、標準化担当者の人にとってはすごくありがたい。
Lychee製品はどれも、マニュアル無しでも直感的に操作できる点が素晴らしいと思う。

【3】3つ目は、「機能安全の観点から言うと、それがソフトウェアのどの機能に盛り込まれていて、それが妥当か否かを保証することがサプライヤとしての責務だと考えているからです。要件トレースツールとしてタスクの担当者がLycheeAssociation Chartを使用していて、ツリー構造で各タスクの紐づいている状態を親子関係で見られるという点で重宝しています」という点。

LycheeAssociation Chartでは、チケットの階層構造や関連チケット、リビジョンの一覧を表示してくれる。
このプラグインを使うことで、納品時に成果物の漏れがないかチェックしたり、内部統制やシステム監査で、正しいプロセスに則って正しく成果物が作られているか、をチェックするのに使われる。

自動車業界のように製品そのものの安全性を重視されている場合、機能や成果物がきちんと網羅されて、抜け漏れがないことをチェックするのは重要であるが、その作業はかなり大変だ。
LycheeAssociation Chartを使うことで、一覧表示されるから、自動チェックではないが、目検でのチェック作業は確実に楽になるだろう。

但し、LycheeAssociation Chartの運用だけで内部統制の要件を満たすかどうかは分からない。
この辺りは、@akahane92さんのSQIP2014発表資料「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」と比較して、内部統制にRedmineを使う場合の必須要件を洗い出してみたい。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

| | コメント (0)

2015/06/15

Redmineは事務処理の申請承認ワークフローに使えるか?


Redmineを事務処理の申請承認ワークフローに使えるか、考えたことをラフなメモ書き。

【参考】
RedmineをBPMツールとして使うアイデア: プログラマの思索

Redmineにワークフローエンジンとして必要な機能~ワークフローに組織マスタの情報を持たせる: プログラマの思索

【1】事務処理の申請承認ワークフローは簡単な仕組みなのだから、Redmineのワークフロー管理機能とチケット管理機能でほとんど実現できるのではないか、と思ってしまいがちだ。
実際、つい10年くらい前までは、LotusNotesで簡易なワークフロー管理は実現できていた。

例えば、見積書の作成・承認、旅費申請、事務用品の購買申請、他部署への作業依頼などがあるだろう。
しかし、業務を詳細にヒヤリングして分析してみると、意外に複雑だったりする。
特に、古い大企業や古いメーカーほど、縦に長い組織階層とサイロ型組織、昔ながらの業務に引きずられて、申請承認フローがものすごく複雑になりがちだ。

特に、組織構成がしっかりしすぎている大企業ほど、部署間の連携が難しいので、申請承認フローが必要になってくる。

旅費・経費・事務の申請承認フローを対象に、Redmineの機能にどれだけフィットできるか、フィットギャップ分析をしてみる。
以下は、思いついた評価項目を並べただけ。

【2】申請書

【2-1】普通は、業務で使う帳票を元に、チケットの項目に当てはめれば良い。
出張旅費精算書、経理申請書、見積書の申請書など、既にExcelの帳票を元に、データモデリングの技法を使って洗い出せば良い。
おそらく殆どの項目は、Redmineのカスタムフィールドで実現できるだろう。

【2-2】但し、例外の仕様もある。
ある欄は、申請者は記入できず、総務部や経理部が記入できる仕様にする、など、ステータスやロールによって、項目の表示・更新制御が必要な場合がある。
特に、お金に関する承認欄は、経理部長や総務部長が最終承認ないしコメントが必須だから、改ざんされてはいけない。

Redmineでは、ワークフロー設定画面で、チケットの各項目をロールごとに必須入力・ReadOnlyなどに設定できる。
また、「チケット作成者に追加で許可する遷移」「チケット担当者に追加で許可する遷移」など、チケットの作成者や担当者ごとにステータスの遷移を分ける機能もある。

この仕様はRedmineでカバーできるだろう。

【3】ワークフロー

申請承認の単純なワークフローならば、Redmineのワークフロー機能で十分だろう。
しかし、市販のワークフロー製品のように、複雑なワークフロー機能はRedmineでは実現できない。
例えば、下記のような機能があるが、Redmineで実現するのはカスタマイズが必要になるだろう。

1)ビジネスルールによる分岐
出張旅費精算や経費申請では、3万円以上は課長決裁、20万円以上は部長決裁などのルールがある。
つまり、申請金額というカスタムフィールドの値に応じて、承認ルートが課長や部長に増える仕様が必要。

Redmineのワークフロー機能にはそんな機能がないので、分岐が発生するパターン分のワークフローを作らなければならない。

2)根回し

申請・処理した案件の情報を、申請者・処理者が任意のユーザに通知する機能。
普通は、申請に対し、承認者全員が承認しなければ通過できない制約条件を課す。
よくある例は、ある予算稟議は、すべての部門の部長の承認が必須、みたいな例。

3)投票

申請に対し、複数の承認者のうち、ある一定数以上が承認したら、フローを通過する制約。
事例が思いつかないけれど、こういう機能が欲しい会社もあるみたい。

4)相談

承認者が承認する前に、別のユーザに申請チケットの情報提供やアドバイスを求めて、コメントさせる機能。
普通は、相談している行為自体は、他の人から見られないようにする機能になっている。

この機能は、ある特定のユーザグループだけがRedmineのプライベートチケットでやり取りできるようにして、申請チケットに関連づければいいだろう。

Redmineに関する課題と展望: プログラマの思索

5)代理申請・代理承認

例えば、長期出張で不在の課長の代わりに、部長や別の課長が代理承認する。
あるいは、客先に長期駐在の社員に対し、課長が代わりに申請する。

Redmineには代行ログインの機能がないので無理だろう。

6)一括申請・一括承認

複数の案件を一括で申請したり、一括承認する機能。
例えば、経理部長が月末に、複数の部署の社員の出張旅費を一括承認して精算する場合があるだろう。
すると、大企業の経理部では、数件レベルではなく、数十件、数百件を一括で承認処理したいケースが出てくる。

Redmineでは、チケット一覧で右クリックすれば、ステータスを一括変更できる機能があるので代用できるだろう。

7)動的承認

「動的承認」とは、申請(処理開始)後に、特定のフロー上の処理対象者の追加、もしくは削除などを設定することができる機能。
つまり、申請した後で、承認者を動的に追加・削除出来る機能。
大企業では、動的承認を使いたい状況もあるらしい。

【3-1】但し、Redmineのワークフローに分岐やロジックを追加するプラグインredmine_custom_workflowsを使えば、上記の機能はほぼ実現可能だろう。
たとえば、稟議申請の金額によって、承認者を部長と社長で分ける、といったロジックは上記プラグインで簡単に実現できるだろう。

Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索

anteo/redmine_custom_workflows: Allows to create custom workflows for Redmine

【追記】
管理者が他人に成りすますことができるプラグインがあったので、代行ログインも実現可能かな。

alpcrimea/redmine-spectator-plugin: Redmine plugin to change user after login

【4】メール通知

申請や承認行為をしたら、関係者にメールで通知する。
さらに、できれば、督促メールも出す機能も欲しい。

Redmineでは、チケット更新のイベントで通知メールを出せる。
また、rakeコマンドでリマインダーメールを送信する機能があるので、例えば、期日3日前とか、期日遅れのチケットがあればリマインダーメールを自動送信すればいいだろう。

RedmineReminderEmails - Redmine

【5】集計

申請状況や承認状況を日次・月次・部署別などで色々集計したい。
例えば、旅費の精算が多い部署、経費の無駄が多い部署などを特定して、経理部が把握したい。
あるいは、部署ごとの申請状況に応じて、ワークフローシステムの運用保守費用を部署ごとに分担する場合もあるので、集計結果は費用負担に直結する場合もある。

Redmineでは、チケット集計機能はいくらでも追加できるし、簡単にカスタマイズできる。
但し、リアルタイムな集計に過ぎないので、バッチ処理を組んで、日次・月次で集計結果を保持する仕組みを作った方がいいだろう。
その場合、MySQLのテーブルに直接アクセスする方法が取られるだろう。

【6】認証

普通の大企業では、シングルサインオンや外部認証の仕組みがあるので、それを流用したい。
IDやPWを一元管理したい動機がある。

RedmineにはLDAP認証やOpenID認証の機能があるらしいので、多分実現できるはず。

LDAP認証 ? Redmine Guide 日本語訳

RedmineでOpenID連携: プログラマの思索

【追記】
Redmineのユーザマスタを既に運用中で、その後でLDAPへ移行する場合の事例があった。
参考になる。

[ REDMINE ] 運用中の Redmine のユーザアカウントを Active Directoryと認証連携する | LEAP ARROWS | Developer Blog

【7】マスタ登録

ワークフローシステムを動かすには、ユーザマスタや組織マスタなど各種マスタを事前登録しなければ使えない。
普通は、インポート・エクスポートする機能を持っている。

Redmineの場合、ユーザ一括登録のプラグインはVer3.0で下記が対応しているらしい。

shrkw/redmine_user_import

チケットの一括登録は、下記のプラグインがある。

zh/redmine_importer

Redmineチケット★一括★の詳細情報 : Vector ソフトを探す!

RedmineはREST APIがあり、かなり使える品質なので、マスタ登録に使ったほうが良いだろうと思う。

【8】組織階層

大企業になるほど、ピラミッド型の組織階層を持ち、申請承認ルートが複雑になる。
申請書の金額が高いほど、部長決裁や社長決裁の案件も増えてくる。

組織階層の仕様では、いくつか気を付けるべきポイントがある。

一つは、組織変更の履歴を保持する仕組みがあった方が良い。
なぜなら、社長の思いつきで組織変更は頻繁に発生するため、組織変更の履歴や組織変更適用日などを持たないと、毎回組織マスタを洗い替えするリリース作業が発生してしまう。
マスタ洗い替えは、結構危険な作業だし、リリース作業中は業務を止めてしまうから影響が大きい。

2つ目は、組織階層は一つではなく、複数の非公式な階層構造があったり、正式ではないローカルな階層構造があったりする。
例えば、プロジェクト型の案件では、正式な部署の承認ルートを使わず、そのプロジェクト内の承認ルートを使う場合がある。

あるいは、地方の営業所では、部長以上がいないために内部で承認決裁できるように特別にローカルなルールを作っている場合がある。
あるいは、工場では、工場内の特定の業務やプロジェクト型の業務に対し、正式な組織階層ではなく、有識者による申請承認フローを使ったりしている。

Redmineには組織階層の概念がない。
敢えて言えば、ユーザに対し、カスタムフィールドで組織のロールを割り当てる事は可能。
しかし、本来の組織階層の仕様は実現できない。

【9】ロール

Redmineでは、ロールはいくらでも作れるので、ある程度は対応できる。
しかし、いくつかの仕様はRedmineでは実現できていない。

一つ目は、ある職務を兼務している人の考慮があるか否か。
例えば、新規事業の部署では、他の部署の部長が兼務したりする。
すると、同一の人が複数の役職を持つので、そういうワークフローの仕組みを実装できるか?
2つ目は、代理申請や代理承認。

【10】アーカイブ

出張旅費精算や経費申請は、大企業になると年間数十万件、数百万件までトランザクション量が発生する。
昨今は、海外の工場への出張なども多い。
すると、不要な申請データはアーカイブして、性能を落とさない仕掛けが必要になってくる。

普通のワークフローシステムでは、1年経った申請データは参照用スキーマへアーカイブしてデータ量を減らす。
あるいは、8年以上経った申請データは物理削除する機能もあったりする。

Redmineでは、不要なプロジェクトは、物理削除したり、書庫へアーカイブする機能もある。
あるいは、更新しないと判明したチケットは、参照用プロジェクトへ移動し、プロジェクト内の全文検索の性能を確保する運用もあるだろう。

【11】検索

ワークフローシステムでは、申請書の全文検索が結構重要。
しかし、年間数十万件、数百万件も申請データが発生すると、当然検索は遅くなる。

Redmineでは、全文検索はチケットが20万件までは問題なし。
それ以上は何らかの対策が必要。
@akahane92さんの資料が全て。

【12】帳票・CSV出力

日本企業は帳票にこだわる。
PDFのレイアウトや文字列が少しでも狂っていると、すぐに指摘が入る。

RedmineのPDF出力は、@naitohさんのおかげでほぼ問題ない品質になった。
チケット出力、チケット一覧の出力も問題ない。

ワークフローシステムの帳票出力で気になる機能は、電子承認だろう。
今までは、いくらワークフローシステムを使っていても、紙で印刷して、部長の押印が必要だった。
でも、電子印鑑でペーパーレス化するのが最近の流行。

【13】IT内部統制(J-SOX)

ワークフローシステムのデータは、普通はIT内部統制の対象になるだろう。
会計監査やシステム監査の対象になるから。
つまり、ワークフローシステムにあるデータは勝手に改ざんしてはいけないし、セキュリティも厳しく運用する必要がある。
Redmineに内部統制を適用した事例は@akahane92さんの資料がすごく参考になる。

RedmineはITソリューションの一つ~情報システム部門のタスク管理とIT全般統制 #RxTstudy: プログラマの思索

【14】まとめ
以上をまとめると、Redmineである程度はワークフローシステムを構築できる。
しかし、複雑な業務には対応しづらい。

でも、幸いな事に、RedmineはREST APIなどの外部接続のI/Fの品質がよく、DBの構造も綺麗なので、機能拡張のカスタマイズはさほど難しくないだろうと推測する。
Redmineを事務処理の申請承認ワークフローシステムとしてパッケージ製品として売り出す会社も出てくるかもしれない。

| | コメント (1)

2015/06/14

【告知】「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」がついに出版

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」が来週6/22に出版されます。
過去に出版されたRedmine本の中で、幅広い読者層と記載内容の広さは、一番だと思います。
その分、本の値段も過去のRedmine本の中で一番高価です笑

僕も、Redmineの運用方法やチケット駆動開発の解説など、一部の章を支援しました。

【参考】
「Redmine実践ガイド」が出版されます - 推薦文公開 -: ソフトウェアさかば

【目次】Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント(株式会社アジャイルウェア) | 書籍 本 | ソシム

Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」の内容は、Redmine初心者からプロジェクトマネージャや上級者まで広い読者層を対象に、利用手順から実践技法、国内製造大手のRedmine運用事例まで書き切ってます。
過去のRedmine本と比較すると、下記の特徴があります。

1)Redmineの利用者・プロジェクトリーダー・システム管理者の観点で、Redmineの使い方や設定方法を解説。
入門Redmine」と内容は似ている部分があるが、使用者の観点で書いているので、ストーリーは違う。

2)Redmineでアジャイル開発・WF型開発・チケット駆動開発を一通り解説している。
また、Redmineの運用方法として、課題管理・障害管理・ヘルプデスク管理・PC資産管理なども解説している。
さらに、島津製作所や三菱電機など、日本の大手製造業で実際にRedmineを導入・運用した事例も紹介している。

Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の内容と似ている部分があるが、Redmineの使用者の観点で網羅的に記載している点と、実際の日本の大手企業の事例を詳細に記載している部分は違う。
特に、日本の企業の事例では、Redmineの特徴をすごく生かしている会社もあれば、Redmineに頼り過ぎない方が良い部分もあると冷静に分析している会社もあり、すごく参考になると思います。

3)Redmineシステム管理者の観点でRedmineのインストールや移行方法、利用者の観点で数々のプラグイン紹介、開発者の観点でRedmineプラグイン開発のコーディング方法を詳しく解説している。

Redmine超入門 増補改訂版」「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック)」と比較すると、記載の範囲が広く、プラグイン開発者にとっては貴重な解説資料になっている。

というわけで、是非手に取って読んで頂ければと思います。

今年は「入門Redmine」「Redmine超入門 増補改訂版」「Jenkins、Chef、Redmine、Dockerで業務効率アップ 10倍速の開発・運用ツール (日経BPムック)」についで、4冊も日本でRedmine本が出版されたことになります。
これだけRedmineを利用する読者層が日本に多くなっている事象を見れば、日本でもRedmineの利用事例が増えており、チケット管理ならびにチケット駆動開発のメリットやデメリットも把握しているのだろうと思います。

その辺りも、RxTStudyやredmine.tokyoのようなRedmineコミュニティで皆と共有したいと思います。

【追記】
目次が下記で公開されていますのでご参考下さい。

【目次】Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント(株式会社アジャイルウェア) | 書籍 本 | ソシム

| | コメント (0)

2015/06/11

GitHubはオープンソースのプロセスを標準化した

「GitHubはオープンソースのプロセスを標準化した」記事の感想をメモ。

【参考】
GitHubはオープンソースのプロセスを標準化した。これからはコード開発以外にも使われていく。AWS Summit Tokyo 2015 - Publickey

akipiiさんはTwitterを使っています: "そうなのか?RT @koyhoge: Redmine にパッチを投げる不便さを解決するところから GitHub は生まれたのか。 #awssummit #key02"

akipiiさんはTwitterを使っています: "ふむー。RT @toshihirock: Github以前、svnにもアクセスできないからソースコードをダウンロードして、パッチ作ってみたいな大変。そしてやりとりをredmineで。そして個人的な功績は残らない。しんどい #AWSSummit"

akipiiさんはTwitterを使っています: "同感。RT @mesaka2009: 昨日のGithubの人の講演。たった10年でこれだけ変わった。と言う事の一つに、Redmineでやり取りしていたのがGithubになった。とあったけど、日本の企業にはまだまだRedmineは現役だぞい!"

GitHubの偉大さは、Publickeyの記事の通り、オープンソースの開発プロセスの事実上のデファクトスダンダートになったことだろう。
オープンソースで何かしらの貢献をしたい開発者は、GitHubにアカウントを持ち、フォークしてパッチを送る方法をプルリクするやり方を学ぶ必要がある。
GitHubにないソースの保守は、とても面倒だ。

上記の記事の通り、以前は、diffコマンドを作り、patchコマンドでtrunkにDiffパッチを取り込むやり方を行なっていた。
そして、メーリングリストでダラダラとやり取りしていた。

あるいは、ReviewBoardというコードレビューWebシステムがあったが、その機能は、Subversionのtrunkに対し、patchを添付するとWeb上でDiffが表示されて、そのDiffを中心にコミッタと開発者がコメントし合うやり方だった。

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

ReviewBoardを使うプロセスとは?: プログラマの思索

でも、GitHubのおかげで、全てはプルリク駆動の開発プロセスで標準化された。
好きなだけフォークして、ブランチを作り、マージ依頼をプルリクすればいいだけ。
このやり方で、より高速な開発が可能になったし、ソースに関するすべての作業がWeb上で公開されているので、開発プロセスの透明化にもつながった。

但し、Redmineを過去の遺物で紹介されたのはちょっと違和感があった。
RedmineとGitHubは、利用シーンも使い方も目的も全く違う。

GitHubはソース中心のプルリク駆動開発であり、Issue管理の機能は正直弱い。
チケット集計機能もないし、Issueにコメントをやり取りするのが中心で、ステータス管理もシンプル。
チケットはフロー型。
チケットは完了したら捨てる。
チケット管理の機能はそもそも不十分だし、それでいいと割り切っている。

逆に、Redmineはチケット管理機能がすごく充実している。
Redmineのチケットはストック型。
チケットに作業や課題、障害などの情報を記録し、後で検索できるように蓄積していくべきもの。
Redmineは「チケット駆動開発」が本来の使い方だと僕は思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

つまり、RedmineとGitHubの違いは、チケット駆動開発とプルリク駆動開発の違いであり、その優劣を言い合っても意味が無い。
使う用途が全く違うのだから、利用シーンに応じて使い分ければいい。

| | コメント (0)

« 2015年5月 | トップページ | 2015年7月 »