R言語の解説記事で、下記の記事がわかり易かったのでメモ。
【参考】
飯島の雑記帳 - Rゼミ/R初心者ゼミ
個人的には、R言語をSQLみたいに扱えるか試してみたが、ちょっと感覚が違っていた。
CSVをInputにして、データの抽出や集計はできるが、R言語のメリットは統計処理とグラフ表示。
やっぱり統計量の意味が分かっていないと面白くない。
でも、CSVのデータをすぐに2次元の図にプロットできるのは、視覚的に分かりやすいので、メリットだと思う。
ネットで探してみたら、統計検定みたいな資格もあると知った。
こういうので統計学の勉強をした方がいいのかな？
統計検定：Japan Statistical Society Certificate
もう少し試してみたい。
経済学の勉強では、石川先生の速習マクロ経済学・ミクロ経済学が有名らしい。
リンクをメモ。
【参考】
フリーラーニング Free-LearninG For Your Extention ≫ 速習！マクロ経済学
フリーラーニング Free-LearninG For Your Extention ≫ 速習！ミクロ経済学
《数学and経済学》経済学をはじめる君へ - NAVER まとめ
【診断士一次】 ⑥経済学・経済政策 勉強法まとめ - NAVER まとめ
YouTubeで石川先生の経済学の講義の初回を見た。
経済学なんて何も知らない僕でも、初心者の観点で説明してくれるのがいい。
「速習!マクロ経済学―試験攻略入門塾
僕は、経済学は本当に科学なのか？という疑問を持っていたが、こんな解説があった。
経済学では、何らかの仮定を元に、理論を立てて、その理論を現実に当てはめて、その経済現象を説明しようとする。
すると、経済学の理論では最初に仮定が逐一あって、うざいなあ、と思う人がいるが、それは間違い。
仮定は前置きではなく、重要なステップなのだ、と。
仮定があるということは、世の中の現実のうち、ある観点で絞って理論を作ろうとしているのであり、仮定があるから理論を単純化できる。
仮定が間違っていれば、その理論は最初からおかしい。
仮定が現実離れしていれば、理論そのものも現実離れしてしまう。
例えば、経済学では普通は、人は経済的合理性を求める、という仮定から理論を導こうとする。
人は、ブームやおまけなどでモノを買う、という仮定はなかったりする。
実際は、ブームで不要なものを買ってしまったりする事例もある。
しかし、経済的合理性を持つ、という仮定は、現実のある程度の事象は説明できるだろう、と。
但し、ブームで購入しようとする経済事象は、その理論では説明できないので、別の仮定から導かれる理論が必要になるだろう、と。
こういう経済学の基本的な考え方を、無料でYouTubeで見れるのはすごくありがたい。
世の中には色んな学問があるけれど、その学問を腹落ちするまで最終的に理解するには、その学問が成立するに至った根本問題を知ることか、その学問が当初からずっと抱えていて未解決の根本問題を知ることだろうと思っている。
そこに、その学問の基本的な姿勢、背景にある考え方が出てくるのだろうと思っている。
数学や物理はまさにその典型例。
経済学もそうだろうし、ソフトウェア工学も同じだと思っている。
UMLのモデルで法律を理解するアイデアをメモ。
第1回 編集者ガチンコバトル、お勧めモデリング本！ | Think IT（シンクイット）
【1】「UMLモデリングレッスン
このクラス図を見ながら、刑法の条文を読むと、ああなるほど、と何となく腑に落ちた。
【1－1】上記では、「刑罰法規が犯罪構成要件を規定する」「～という行為が犯罪構成要件に該当する」という文言がそのままクラスとその関連名に当てはまる。
犯罪になる行為として、「違法行為」「非違法行為」の2種類があり、非違法行為になる条件として「違法性阻却事由」を持つことが当てはまる。
つまり、刑法の条文はとても冗長な文章であるが、その本質となる文章をそのままクラスと関連名に当てはめれば、概念モデルになりうる。
これは面白い。
おそらく理系の人は、こういう法律の文章はとても苦手だと思うので、こういうやり方で理解する方法もあるのかもしれない。
【1-2】上記の概念モデルをER図としてRDBに落とし込んだ場合、どのようなテーブル構成になるか？
僕の勝手な憶測では、下記のようになるだろう。
IDEF1Xで書けば、「●---」の向きで外部キーによる参照制約、「△---」の向きで派生関係を表す。
刑罰法規マスタ●---犯罪構成要件マスタ
行為トランザクション---●犯罪構成要件マスタ
(※但し、行為テーブルには、複数個の犯罪構成要件マスタを外部キーとして持てる)
行為トランザクション△---違法行為トランザクション、非違法行為トランザクション
非違法行為トランザクション---●違法性除却理由マスタ
UIとしては、行為データを登録・検索する画面と各マスタ保守画面がいるかな。
帳票としては、ある期間の行為データを印刷する帳票がいるかな。
【1－3】また、「UMLモデリングレッスン
例えば、上記のような概念モデルを用いて、政府や裁判所の要請に基づき、犯罪履歴や事例を検索したり保守するシステムを作る案件はもちろんありうる。
似たような例として、電力・ガス・電話などの事業会社やクレジットカード・保険会社の契約条文をビジネスルールとしてソフトウェアシステムに実装する場合がある。
これらの会社では、ビジネスの基本的な約束事は約款として定められており、そのビジネスルールがシステムの要件や制約に反映されるからだ。
例えば、クレジットカード会社や携帯電話会社では、カードやスマフォの契約時に、違法性がないか、ビジネスルールを課しており、そのルールを満たす人だけが契約できる。
そしてその契約情報は記録され、後から検索したり、契約延長や契約破棄などの保守ができるように、システムを作る必要がある。
そう考えると、携帯電話会社や銀行・カード会社と契約を結んだ時に約款として渡される大量の資料の背後には、彼らの会社の基幹システムにはビジネスルールとして実装されているのだろうと推測できる。
【2】この発想を推し進めれば、例えば、日本の特許庁のシステムリプレースでも、こういう概念モデルが必要だったのだろうと勝手に推測する。
実際のニュースを見ると、破綻した理由は他にもあるみたいだが。
News ＆ Trend - 2012年の特許庁システム開発中止、開発費全額返納のなぜ：ITpro
【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ - NAVER まとめ
UMLのモデリング技法を用いて、ビジネスルールを概念モデルで表してみる手法は今後考えてみたい。
Redmineにワークフローエンジンとして必要な機能が一つ漏れていたのでメモ。
ラフなメモ書き。
【参考】
Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索
RedmineをBPMツールとして使うアイデア: プログラマの思索
【1】Redmineを申請承認フローのような汎用的なワークフローシステムとして使う時、色んな留意点があるが、一番重要な指摘を忘れていた。
それは、ワークフローのステータス遷移のフック処理がRedmineに無いこと。
例えば、稟議書の申請書を書いたら普通は、申請ボタンを押せば次の承認者へ回される。
しかし、Redmineでは、チケットに申請書の内容を記載した後、承認者を指定して、ステータスを承認待ちへ変更して、更新ボタンを押す必要がある。
つまり、逐一、次のステータスへ遷移する情報を手作業で設定しなければならない手間がかかる。
すると、次の担当者やステータスを間違えると、本来の申請承認フローに乗らない危険がある。
こういう誤操作は起きやすい。
本来の申請承認フローのワークフローエンジンとしては、申請ボタンを押せば、自動で次の承認者が背後で決定され、ステータスも承認へ変更して欲しい。
【2】このようなワークフローエンジンの機能をRedmineで実現する場合、どんな設計方式が必要なのか？
【2-1】一つは、申請書を次のステータスへ遷移する時は、ステータスの遷移先を1個に絞っておけばいい。
つまり、申請→課長承認→部長承認→経理承認→完了のように、ステータス遷移を厳格に設定する。
一時保存の場合は、ステータスを変更しなくて良い。
【2-2】もう一つは、次の担当者を設定しなくても良いように、ステータスごとに担当者を設定する機能が必要になる。
一般に、ワークフローシステムでは、ステータスごとに組織のロールが設定されていて、申請者に属する組織のロールを経由して申請承認が回るような仕組みを作っている。
例えば、ある組織に、部長・課長・ヒラ社員のようなロールを作る。
そして、組織には複数の部署がある場合、部署Aでヒラ社員が申請書を起票したら、部署Aの課長に相当するA1さんに課長承認前ステータスが設定されるようにすればいい。
すなわち、組織マスタを別途作成し、部署や職制上のロールを細かく登録しておき、それをワークフローに紐付ける必要がある。
一般に、申請書の種類ごとに、申請承認フローに相当する組織マスタの情報を設定しておく。
例えば、休日出金申請ならば、申請→課長承認→総務承認のステータスとワークフローを作り、各ステータスに社員→課長→総務職員という組織のロールを割り当てておく。
あるいは、経費申請ならば、申請→課長承認→部長承認→経理承認→完了のステータスとワークフローを作り、各ステータスに社員→課長→部長→経理担当者という組織のロールを割り当てる。
そして、ステータスを指定したら、申請者の部署に属するロールを指定し、そのロールに該当するユーザを自動で設定するように、フック処理を実行すればいい。
つまり、ワークフローごとにロールなどの組織マスタの情報を保持し、ステータスを指定したらそのロールに紐付くユーザをセットするフック処理が必要になる。
普通のワークフローシステムでは、ワークフローごとにステータスと組織のロールを持たせるマスタを保持しているので、一括登録すればマスタを整備できる。
また、ステータス遷移後のユーザ指定のフック処理は、redmine_custom_workflowsプラグインを使えばいいだろう。
Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索
【2-3】但し、この手法の注意点は、組織マスタの情報がきちんと整備されているか否か、にかかっていること。
会社の業務の運用フローをヒヤリングしてみると、実は、ワークフローが組織のロールではなく、特定の個人に依存したワークフローがあったりする。
実際、僻地の営業所、工場内の業務、子会社との事務のやり取りなど、イレギュラーな運用は意外に多い。
すると、そのワークフローに紐づく組織マスタにはロールではなくユーザ情報を持たせるようになってしまい、人事異動があるたびに組織マスタを保守する手間がかかるようになる。
だから、組織マスタには特定のユーザIDを登録するのではなく、非公式なロールをいくらでも作れるような仕組みが必要。
すなわち、組織マスタには公式な職制だけではなく、特定の業務の運用に即したロールも設定する必要があるから、組織マスタでは、一人のユーザは複数のロールを持っているような仕組みが必要になる。
しかし、組織マスタのようなマスタの整備は、一から作るのはとても大変。
今後の運用を見据えた組織マスタの整備はきちんと考えた方がいい。
そんなことを考えると、ワークフローシステムはERPと同じく、マスタの整備が非常に重要ということがよく分かる。
Redmineのビューをカスタマイズするプラグインのメモ。
【参考】
Redmineの少機能設定 - より良い環境を求めて
Redmine でチケット一覧にデフォルトのカスタムクエリを設定できるプラグイン - Qiita
Redmine startpageプラグインでトップページを任意のWikiページなどに設定する - torutkの日記
画面をJavaScript/CSSで簡単にカスタマイズできるRedmineプラグインを作成しました (Redmine view customize plugin) - Enjoy*Study
onozaty/redmine-view-customize
(引用開始)
「Redmine Default Custom Query」プラグインで、チケット一覧の初期表示を変える
「Redmine Startpage plugin」でトップをマイページまたはチケット一覧に変える
「View Customize plugin」で
サイドメニューを隠す ( http://blog.enjoyxstudy.com/entry/2015/03/23/000000 )
ヘッダーのhomeやhelpを隠す
プロジェクトへのリンクに /issues を付け足して、初期画面はチケット一覧にする
issues/new$ の条件で、新規チケットの初期値を設定する
(引用終了)
確かに、Redmineのデフォルトクエリを設定したくなったり、トップページのURLを好きな画面にリダイレクトしたくなったりする時がある。
ちょっとした使い勝手の改善で、メンバーの拒否感も減ったりするので、TIPSと知っておくと良いかもしれない。
Redmine Backlogsプラグインを今頃になって入れてみた。
実際に試してみたら、Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしているように思えて、すごく感動した。
自分が理解できた部分までメモ。
＃すべての機能はまだ分かっていないので、後で書く。
【1】インストール方法
下記の環境に入れた。
Windows7
java version "1.8.0_11"
jruby 1.7.20.1 (1.9.3p551) 2015-06-10 d7c8c27 on Java HotSpot(TM) 64-Bit ServerVM 1.8.0_11-b12 +jit [Windows 7-amd64]
Redmine2.6.6
XAMPP
JRubyでRedmineBacklogsプラグインを動かす: プログラマの思索
【2】Redmine Backlogsのカード印刷の設定
タイトルとか決めてないけどこのままでもいいかもしんない: Redmine Backlogsのカード印刷(card printing)設定が有効化できない場合の対応
Redmine BacklogsでストーリーカードをPDF出力する時の文字化けを防ぐ方法 - HOW TO GO
redmine\plugins\redmine_backlogs\lib\labels\labels.yaml
を作る
↓
redmine\plugins\redmine_backlogs\lib\ttf
にIPAフォントを入れる
【3】基本的な使い方の参考リンク
詳細は、下記を参考にした。
Redmine Backlogs :: Usage: Product Owner
Redmine Backlogs :: Usage: Scrum Master
Redmine Backlogs :: Usage: Team Member
Redmine Backlogsで簡単スクラム！プロダクトオーナーとして使う編 | 世界はどこまでもシンプルである
Redmine Backlogsで簡単スクラム！スクラムマスターや開発チームとして使う編 | 世界はどこまでもシンプルである
かんばん！～もし女子高生がRedmineでスクラム開発をしたら（4）：「Redmineでスクラム実践！」～アジャイル開発始めました～ (1/3) - ＠IT
かんばん！～もし女子高生がRedmineでスクラム開発をしたら（4）：「Redmineでスクラム実践！」～アジャイル開発始めました～ (3/3) - ＠IT
かんばん！～もし女子高生がRedmineでスクラム開発をしたら（1）：「高校生になって初めてスクラムを始めました」～「ストーリー」で何を作るかまとめよう (1/3) - ＠IT
Ruby - redmineのプラグインredmine_backlogsの(個人的な)設定のお話 - Qiita
【4】Scrumフレームワーク
重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） － Publickeyによれば、Scrumのフレームワークは下記になる。
a)Scrumのプロセス
・スプリント計画
・デイリースクラム
・スプリントレビュー
b)Scrumのロール
・プロダクトオーナー
・スクラムマスター
・チーム
c)Scrumの成果物
・プロダクトバックログ
・スプリントバックログ
・バーンダウンチャート
【5】基本的な使い方
以下、理解できたことを箇条書きで書いてみる。
【5－1】プロダクトオーナーの使い方
* バックログ画面で、プロダクトバックログから「新しいスプリント」でスプリントを新規作成できる。
スプリントはRedmineバージョンに対応している。
注意すべき点は、プラグイン設定画面で、Redmineバージョンに開始日も追加できる。
スプリント名は｛スプリント番号｝_｛そのスプリントの到達目標点｝にすると良いらしい。
* 「バージョン」を選ぶとRedmineのバージョン画面に遷移する。
* 「Wiki」を選ぶと、バージョンのWikiに遷移する。
スプリントのテンプレートWikiを事前に作っておけば、プラグイン設定画面の「スプリントのテンプレートのWikiページ」にWikiページ名を書いておくと、スプリント生成時にバージョンのWikiをテンプレートからコピーして生成してくれる。
Ruby - redmineのプラグインredmine_backlogsの(個人的な)設定のお話 - Qiitaを参照。
* 「新しいストーリー」でストーリーカードを新規作成できる。
作ったストーリーに対して受け入れ条件を説明欄に記入する。普通はPOが書く。
* ストーリーポイントを付ける。ストーリーポイントは、プラグイン設定画面で、フィボナッチ数で登録しておく。
ストーリーポイントは持ち帰ってチームと相談して付けるか、チームに付けてもらう。
* スプリント内のストーリーは、優先順位は並び順になる。プロダクトオーナーが優先順位付けする。プラグイン設定画面で、Redmineの優先度も別途追加できる。
プラグイン設定画面で「新しく作成されたストーリーが追加される位置」で「下に」を選べば、新規ストーリーは最下位に登録される。
チームは上から順にストーリーをタスク化して消化する。Redmineのチケット一覧画面よりも、優先すべきタスクが分かるので良い機能。
* リリース画面
複数のプロダクトバックログを管理する画面。
「リリース」を新規作成すると、プロダクトバックログの中で、開始日・終了日ごとにカテゴライズできる。
* リリース配下のストーリーをスプリントへ移動すると、リリースとスプリントが紐づけられる
* リリースマルチビュー：複数のリリースを束ねたビュー。「リリース」タブから、該当リリースに含まれているストーリー、スプリントの情報が表示される。
例えば、「1次開発」マルチビューの下に「6月リリース分」「7月リリース分」のリリースを紐付ける。
* 「リリース」を使うと、プロダクトオーナーは各スプリントで実施する前の計画段階で、一つの製品のリリース計画を「リリース」ごとにカテゴライズして計画できる。
但し、Redmineのロードマップ機能とは関連付けられていない。
* スプリントの状況を確認するには、バーンダウンチャートを選ぶ。
かなり細かい情報が表示される。
理想時間：残のストーリーポイント数。デフォルトでは、理想時間の計算からは土日が外されている。プラグイン設定画面で「土曜と日曜をバーンダウンに含める」をONにすれば土日を含めることも可能。
残り時間：ストーリーの残り時間の合計。タスクカードの残り時間から計算。
承認されたポイント：ストーリーポイントの増加をグラフで見る。スプリントの途中でストーリーが増えてうまくスプリントが回らない場合に使うと良い。
着手すべきポイント：POにリジェクトされて受け入れられなかったストーリー。
解決すべきポイント：解決していないチケット。「着手すべきポイント」「解決すべきポイント」のチケットはいずれも、プロダクトオーナーなどにCloseを確認してもらう。
* スプリントの終了は、Redmineのバージョンを「完了」にする。
スプリントのWikiに、打合せやレビューなどスプリントに関する情報を記録する。
終了しないストーリーは、チケットの「コピー」を選択するとチケット編集画面に「元のストーリーへのリンクを含める」「タスクをコピー」を選択できる。つまり、次スプリントにストーリーをCopyするだけでなく、発生元のリンクも残してくれる。
* 「リセット」はスプリントを途中で中止する機能。警告メッセージがとても丁寧。
「このスプリントをリセットする際の注意！！
本当にスプリントをリセットしますか? スプリントのリセットは
ストーリーとタスクに次の影響があります:
* 作成日はスプリントの開始日に設定されます
* コメントを除いた全てのストーリーとタスクの変更は削除されます
* 現在の値は、全てのストーリーとタスクの初期値になります
* ステータスはチケットのデフォルトのステータスになります」
【5－2】スクラムマスター・開発チームの使い方
* スプリントメニューから「かんばん」を押すと、該当スプリントのかんばんに移る。
担当者ごとに異なる色でタスクは表示される。
* ストーリーカードが左欄に表示され、プラスボタンを押すとタスクカードを登録できる。
裏では、ストーリーカードが親チケット、タスクカードが子チケットになっている。
タスクカードには残り時間を記入できる。残り時間はTOCのバッファ管理に使えるだろう。
タスクカードの担当者、作業者のユーザID、コメント、作業時間も入力できる。
作業時間はRedmineチケットのデフォルト機能の実績工数。その時の作業者の工数が作業者のユーザIDに対応する。
かんばん上でドラッグ＆ドロップでタスクカードを移動できる。毎日、常時最新化する。
* タスクの担当者の色は、Redmine右上の［個人設定］で［バックログ］の［Task color］でタスクの色を変更できる。
* プラグイン設定画面で「タスクの状態へのストーリーの追従」で「全てのタスクがクローズされたときクローズ 」を設定すれば、フック処理が動くので、ストーリーカードを逐一、終了ステータス更新する必要がなくなる。
* 「スプリント障害事項」は、タスクカードを妨害する発生源の課題。
「スプリント障害事項」チケットのブロック欄にチケットIDをカンマ付きで登録すると、Redmineの関連チケットの機能「ブロックされている」で紐付く。これは凄い。
つまり、ブロック元の課題チケットが解決されなければ、タスクカードは完了ステータスにできない機能をRedmineの機能で実現している。
プラグイン設定画面で「バックログとかんばんの自動リフレッシュの間隔」を設定すれば、かんばんのタスクカードを最新化した時に自動的にその状態がバックログにも反映される。これは便利。
* スクラム統計：
リリースやスプリントに関する最新の進捗報告書に近い。
【6】他の機能
Redmine Backlogs :: Advanced topicsに書いてある機能が完全に分かってない。
Redmine Backlogs :: Releases
→「リリース」機能。
リリース計画に相当する。
Redmine Backlogs :: Release graph
→「リリース」機能に関するバーンチャート。
プラグイン設定画面で、「リリースバーンアップチャート (実験的機能)」をONにする。
リリースグラフから何が分かるのか？
「リリース」に関係付けられたストーリーの集合から、各スプリントのVelocityやストーリー消化具合が分かるが、それが何を意味するか？
「リリース関係」にある「追加」「継続」「初期」「自動」の使い道が分かってない。
Redmine Backlogs :: Release multiview
→リリースマルチビューは複数の「リリース」を束ねたもの。
複数のリリースのバウンチャートを組合せたい要望から生まれた。
リリースマルチビューのリリースバーンチャートから何が分かるか？
プロジェクトの進捗、スコープ変更の内容とどのように関連付けられるか？
Redmine Backlogs :: Sharing sprints/releases
→プラグイン設定画面で「バックログの共有」をONにする。
「新しいスプリントを共有」で選べる項目はRedmineバージョンの継承設定と同じ。
下記の説明がある。
新しいスプリントは、ユーザーとプロジェクトのパーミッションに従い共有されます。
システムで共有できるスプリントは管理者のみ作成できます。
階層とツリーで共有されたスプリントは最上位プロジェクトのパーミッションが必要です。
たぶん、スクラム・オブ・スクラムを実現するツールと思われる。
例えば、「Single team, multiple projects」は1個のチームが複数システムを保守している場合。
例えば、「Multiple teams, single project」は大規模受託案件で、サブシステム単位に各チームが担当している場合。
【7】上記のように、Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている。
個人的には「スプリントのリセット」がデフォルト機能に含まれているのに感動した。
実際のプロジェクトでは、プロジェクトの中止の判断は開発チームにもプロジェクトリーダーにも存在しないから、走り出したら止まらない、という怖い一面がある。
特に、要件定義や受注の段階で、失敗する可能性の高い案件は山ほどあるだろう。
だから、ごく稀だろうが「リセット」する勇気も必要な時もあるだろう。
また「リリース」「リリースマルチビュー」「リリースグラフ」機能のように、リリース計画の作業をサポートするような機能を付けているから、使いこなせれば、かなり効果が上がるのではないか？
但し、Scrumで感心すると同時に難しいと思う点は、Velocityの計測とVelocityの安定だ。
つまり、バーンダウンチャートを綺麗に表示させること。
Velocityを毎回計測することによって、リリース計画の精度は理論上良くなる。
しかし、実際の作業では、毎回のスプリントのVelocityを安定させるのは難しいはずだ。
スプリント中のタスクの順序や依存関係、リスクを常に把握できていればよいが、その判断が大きく間違ったら、Veclocityは大きく狂ってしまう。
Velocityが安定しなければ、リリース計画に響くし、顧客などのステークホルダーの信頼関係にも響く。
この辺りのノウハウはまたまとめてみる。
Redmineを導入したいという話を受けて、Redmineを導入した時、後で気づくのは、ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか、という問題。
ラフなメモ書き。
結論はなし。
よしむさんはTwitterを使っています: "@kawanishi_ameya プロジェクトによって運用具合もバラつきがありますし、管理者次第というところが影響してくるんですね・・・（泣）"
僕個人の経験では、Redmineというツールを導入した後に、こういうふうにプロセスを回すのだな、と気づきながら運用していた。
だから、ツールを使いながら、あるべきプロセスを導き出したように思う。
でも、実際はそうではなかったかもしれない。
ツールの導入前は、アジャイル開発を実践した経験はほとんど無かったけれど、アジャイル開発の知識は持っていたし、こういうふうに運用したい、という思いはあった。
WF型開発できちんと変更管理するやり方も、色んなSIを渡り歩きながら、学んでいた。
SIer特製の障害管理Webシステムへの障害票の書き方、コミットする時には障害管理番号を記載すること、CVSのコミットログに変更理由を記入すること、などの運用ルールはある程度分かっていた。
だから、Redmineを障害管理からタスク管理へ発展させて使う方法はマッチできた。
実際は、プロセスが確立されたイメージを持ってツールを導入していたのだろう。
ツールは高速道路であり、上手く使えば、ゴールまで速く到達することはできる。
でも、高速道路の走り方も多少はあるし、車のエンジン(＝チームの能力)が性能を出し切れなければ、国道を走っている時と変わらないかもしれない。
色々考えてみる。
【追記】
下記の記事が参考になる。
NotesのDB設計ができる人はチケット管理システムのプロジェクトへの適用にアドバンテージを持っている - 室長のひとりごち
(引用開始)
ところで、Notesってあったでしょう。あ、今もあるか。アレのDBの設計を経験したことがある人は、チケット管理システムのビューやフォームの設計のハードル皆無だと思います。
ラベルをもったデータ項目を追加するか、標準のデータ項目を使いまわすことで、システム開発手法で管理したい情報を持たればいいとか、開発プロセスごとで見たい情報をビューで見せることができるとか、そういったことがわりとすんなりイメージできます。
(中略)
そのときのワタシの頭の中にあったことは「問題解決をするためにツールの導入を考えていたのか」と聞かれれば答えは「ノー」です。問題はプロセスにあると見切り、その問題のあるプロセスままだと潜在化したままで進行してしまうので「可視化」が問題解決の決め手と思った、と当時判断したと思います。今でもそうすると思いますが。
そこには、そう判断した根っこにはチケット管理システムはプロセス管理システムとして使える、と思ったんですね。そのおおもとを辿るとNotesもその1つの要素なのかもしれません。
その点から言えば、確立した開発プロセスのイメージを持っているから、適用するプロジェクトの課題解決のための1つの手段としてツールを導入することを判断した、のではないかと思うのです。
(引用終了)
第42回IT勉強宴会「話題のRedmineの魅力を知ろう」の感想をメモ。
【参考】
第42回IT勉強宴会 話題のRedmineの魅力を知ろう : ATND
7/17に第42回IT勉強宴会「話題のRedmineの魅力を知ろう」が開かれます: プログラマの思索
Redmineチョット入門 - 話題のRedmineの魅力を知ろう- #benkyoenkai: ソフトウェアさかば
話題のRedmineの魅力を知ろう<第42回IT勉強宴会> | ＩＴ勉強宴会blog
【１】昨日の大阪は台風の余波で大雨になり、夜のJR京都線は河川増水で最終列車に乗れなかった人が多かったらしい。
そんな中、第42回IT勉強宴会には参加者がたくさん来て、Redmineブームの凄さを感じた。
参加者の2/3はまだRedmine未経験者だったから、まさにこういう人達に聞いてもらって良かった勉強会だったと思う。
@g_maedaさんの講演は３本立て。
Redmineの利用紹介、Redmineへの貢献、そして、日本におけるRedmineのふりかえり。
【２】Redmineの利用紹介では、Fax受信からのメールによるチケット登録機能の話が面白かった。
ある企業は、取引先からの受注処理が全てFax受信だった(今でもあるのか！)状況に対し、Redmineのメールによるチケット登録機能を使って、Fax受信機からメールでFax内容をPNGで添付して送信し、Redmineチケットで管理する方法が紹介されていた。
今時、受注処理が全てFax受信というのもすごいが、Fax受信機のメール送信機能をうまく流用している。
【３】Redmineへの貢献では、@g_maedaさんの思いが込められていた。
Redmineにコントリビュータとして貢献するのは、自社サービスMyRedmineのサービス向上もあるし、自社の顧客を増やすためでもある。
特に、ja.ymlへの反映は、自社サービスのユーザの使い勝手に影響するので、いち早く対応するようにしている。
しかし、自社のサービスには、日本のRedmineユーザの１％くらいしか来ていないでしょう。
まずは、Redmine利用ユーザを増やせば、パイが広がるから、自社のサービスに来てもらえるユーザも増える、と。
でも、それ以外でも、Redmineにパッチを送るのは楽しい。
Redmineの認知度は低い。
もっとRedmineを広めて、普通の人が知っているようなレベルにしたい。
だから、Redmine.JPの更新やRedmineの情報発信は重要なんですよ、と。
そんな話を聞くと、@g_maedaさんはRedmineのエバンジェリストなんだな、と思う。
【４】日本におけるRedmineのふりかえりも興味深かった。
【4-1】2006年にRedmineが出現した時、Bugzilla、Mantis、Tracなどの先発のBTS・ITSが既に普及していた。
RedmineはTracクローンと呼ばれていた。
但し、Redmineには波があった。
一つは、2005年に、Railsなら10分でWebアプリを作れる動画が公開されていて、JavaやPHPよりもすごい、と注目されていた。
他方、2009年頃からRubyコミッタがRuby自身の開発管理にRedmineを採用して、RubyistならRedmineという雰囲気が出ていた。
【4-2】2007年から@g_maedaさんがRedmineを使い始めた。
使い始めた理由は、勤務先の現場はソフトウェア保守の仕事が多く、Redmineの複数プロジェクト機能がとても便利だったから、と。
その頃から、Redmine.JPで日本語の情報を発信し始めた。
Redmine.JPの月間PVは現在約28万PVくらい。
他に、Redmine.JP.BlogなどのWebサイトを含めれば月間約30万PV以上。
自社宣伝や広告をしなくても、仕事のお話が舞い込んでくるらしい。
2008年に世界初の「入門Redmine
それから第4版まで出版されて、合計約2万部まで販売された、とのこと。
【4-3】2008年に@akipii(僕)が「Redmineでチケット駆動開発を実践する」という講演をした。
この講演資料の公開によって、日本の企業でもRedmineが使える、ということが分かり、その先駆けになったらしい。
2010年に@sakaba37さんとの共著「Redmineによるタスクマネジメント実践技法
【4-4】2011～2015年にかけて、日経Systemsが断続的にRedmineの特集記事を掲載し始めた。
特に「新三種の神器」の記事が公開された後、Redmine.JPへのWebアクセスが急増したらしい。
「日経」ブランドのおかげで、日本の企業の大半にも、Redmineの名前が浸透し始めた。
調査で分かった！ITの現場「新3種の神器」 - Redmine導入・活用法：課題管理や問い合わせ管理で実践してみよう：ITpro
【4-5】2014年末に「入門Redmine」、2015年には3冊のRedmine本「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント
ネットでも書籍でも、日本語で情報がかなりあるので、初心者でもRedmineを導入して運用しやすくなってきた。
【5】Redmineが日本で広く普及した理由としては、たくさんの日本人の貢献や活躍があるから。
Redmineコミッタに@marutosijpさんがいるので、日本語の文字化け対応や2バイトコード対応など、日本人向けの改善に対処してくれる。
また、@marutosijpさんはRedmineのテストコードの実装にすごく熱心で、昨年のコミット数の半分は@marutosijpさん。
テストコードが十分にあるおかげで、RubyやRailsの頻繁なバージョンアップにRedmineは追随できるのだろう。
@naitohさんがRedmineのPDF出力機能で日本語の文字化け対応のパッチを送り続けたおかげで、RedmineのPDF出力機能は日本語の出力は問題がなく、完成度が高い。
@g_maedaさんも、Redmineのバージョンアップ時に日本語化に素早く対応されることで、Redmineの日本語化に大きく貢献されている。
また、@akipii(僕)がRedmineの運用方法などをBlogに書き続けたことも、少しは役に立っているらしい。
他にも無数のたくさんの日本人がRedmineの普及に関わっている。
@g_maedaさんの話を聞くと、Redmineは日本のSIの利用ユーザがやはり多い。
最近は、日本の大企業でも、ソフトウェア開発だけでなく、業務の課題管理やタスク管理にRedmineを導入する事例が多いらしい。
【6】RedmineのGoogleトレンドを見ると、日本では、2010年を境にして、RedmineがTracを逆転して、ITSの利用度合いが広がった。
しかし、全世界を見ると、Tracが圧倒的で、直近ではJiraが急速に普及してTracを少しだけ逆転している。
世界の観点では、チケット管理システムのデファクトスタンダードはRedmineではなくJiraであるらしい。
Redmine - プロジェクト管理ツール調査 - Qiita
GoogleトレンドでRedmineの普及度合いを見ると、日本・韓国・ロシア・アジアなど世界の東半分で利用ユーザが多い。
Redmineは約50言語に対応しているため、非英語圏の人達が自分たちの言語で使えるので、非英語圏で人気が高いようだ、と@g_maedaさんは言われていた。
最近はブラジルでRedmineの利用度が増えているらしい。
改めてRedmineを振り返ると、長い歴史を持っているんだな、と感じた。
Conwayの法則の拡張版として、「運用は組織に従う」「ワークフローは組織に従う」という経験則があるように感じた。
ラフなメモ書き。
【参考】
システム設計よりも業務プロセスの設計をやっている: プログラマの思索
業務システム設計の隠れた要件～会計監査やシステム監査: プログラマの思索
Conwayの法則～アーキテクチャは組織にしたがう: プログラマの思索
「アーキテクチャは組織構造に従う」という経験則には2つの意味がある: プログラマの思索
(引用開始)
別名：
アーキテクチャは組織にしたがう
問題：
組織とアーキテクチャの整合
コンテキスト：
アーキテクチャ設計者と開発者チームが集まった。アーキテクチャは結構うまく設計されている。
影響する事柄：
アーキテクチャは組織の中での情報交換の経路を形作る。
デファクトな組織構成は、形式的な組織構成を形作る。
形式的な組織構成がアーキテクチャを形作る。
初期段階におけるアーキテクチャにしたがった定型化は、単に近似であり不安定である。
解決策：
組織を製品のアーキテクチャに当てはまるようにしなさい。このパターンランゲージにおいて、ここでは、組織がアーキテクチャに影響をおよぼすべきであるというよりも、アーキテクチャが組織に影響をおよぼすべきであるといえるだろう。
結果として生じるコンテキスト：
組織と製品アーキテクチャが整合する。
論理的根拠：
このパターンは歴史的なものである。
Gerard Meszaros (BNR)は、人々はアーキテクチャが安定してから組織をアーキテクチャに合わせようとしたがる、といっている。もし、早すぎる時機に組織をアーキテクチャに合わせると、アーキテクチャの変化の流れは個々人の統制の範囲の間での干渉を引き起こす。
(引用終了)
【1】端的に言えば、Conwayの法則とは「どんなソフトウェアであれ、それを作った組織の構造を反映する」という経験則。
ソフトウェアのアーキテクチャ、ソフトウェアの複雑さは、それを作った開発した組織、利用する組織の組織構造がそのまま反映されてしまう。
よく言われる例として、コンパイラを作る開発者が4つのチームに分かれていたために、4パスコンパイラという無駄なアーキテクチャになってしまった、という事例がある。
「組織構造がソフトウェアの複雑さに反映されてしまう」というConwayの法則は、他の場面にも拡張できると思う。
【2】「ワークフローは組織に従う」経験則を感じる場面は、Redmineをいろんな現場に導入する際に、現場特有の事情からワークフローが複雑になっていく状況で痛感する。
本来は、ワークフローはシンプルでいい。
「タスク」「バグ」などのトラッカーのワークフローは、本来はそんなに複雑にすべきではない。
しかし、開発現場によっては、開発チーム以外に、品質保証部や他部署の開発チーム、オフショアの開発チームとやり取りする状況があり、複雑になりがち。
例えば、国内の開発チームが設計した設計書に従って、オフショアの開発チームがコーディングし、そのプログラムを国内の開発チームが受入する場合がある。
すると、国内の開発チームの作業のワークフローはシンプルで良いが、オフショアへ開発作業を依頼してから受入するまでの作業を進捗管理したい場合、ステータスが増えてしまい、ワークフローも複雑にならざるを得ない。
例えば、受入担当者も、仕様レビューもあれば、開発標準のレビューもあるから、担当者が変わるし、その状態に対応するようにステータスも増える。
関連する組織が増えるほど、作業の状態を表すステータスが必要になり、ワークフローも長くなっていく。
僕もステータスが10個以上あるようなワークフローを実際に見たことがある。
それは「スタンプラリー」というアンチパターンにつながると思う。
でも、関連する組織構造があれば、ワークフローに反映せざるを得ないのだ。
そうでなければ、Redmineの運用が回らないから。
【3】「運用は組織に従う」経験則を感じる場面は、システム設計ではなく運用設計を考えている時に痛感する。
ERPを導入したら、そのERPを現場でどのように使うべきか、担当者ごとに業務ごとに役割や作業内容を決めていく。
しかし、システム設計の観点でトップダウンで決めると、現場の業務担当者から総スカンを食らう。
「その作業は私の業務ではありません」と言われてしまうのだ。
大企業ほど、組織がサイロ型になっているので、自分の担当範囲以外の作業を押し付けられるのを嫌う。
すると、現場の意見を聞きながら、ERPの運用を導入すると、こんなメリットがあるから、むしろ作業した方がいい、とか、この作業は年数回しかないからマニュアルを見てやれば問題ありません、などのように、運用フローの同意を得ていく必要がある。
こんなまどろっこしい作業が必要な理由は、現状の運用フローは組織構造に従った職務分掌で決まっており、それを修正することは、組織構造を変更することにつながると直感的に感じているからだろう。
運用フローが変更されることで、作業が増えるのは拒否されるのは当たり前。
だが、現状の運用フローが変更されると、現場は混乱してしまいがちなので、拒否反応を起こしがち。
最悪なのは、ERP導入によって、担当の業務がなくなると分かったとしても、以前の部署が残り続けることで、ERP導入の反対者になってしまう状況だろう。
そんなことを思うと、現場の運用フローをシステム設計の観点で変更するのは、あちこちの部署に同意を取る根回しが必要になり、非常に面倒だ。
運用フローは組織構造を反映しているから、そう簡単に変更できないのだ。
この辺りのノウハウや経験則もプロジェクトマネージャには必要なのだろう、と今更ながら感じる。
Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflowsを見つけたのでメモ。
【参考】
anteo/redmine_custom_workflows
Custom Workflows - Plugins - Redmine
RedmineをBPMツールとして使うアイデア: プログラマの思索
Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索
RedmineをBPMツールとして使うアイデアに書いたように、申請承認フローやBPMを実現するには、最低限の機能として、ワークフローを色々カスタマイズできる機能が必要。
上記のredmine_custom_workflowsプラグインを見ると、管理画面でWorkflow scriptsエリアに、Rubyスクリプトで分岐やロジックを直接書くことで、ワークフロー処理にフック処理を入れるみたいだ。
プラグインの画面はこんな感じ。
例えば、下記のようなスクリプトがサンプルとして登録されている。
(引用開始)
Set up a correlation between the start date, due date, done ratio and status of issues.
* If done ratio is changed to 100% and status is "In Process", status changes to "Resolved"
* If status is "New", "Resolved" or "Feedback" and done ratio is changed to value less than 100%, status changes to "In process"
* If status is changed to "In process" and start date is not set, then it sets to current date
* If status is changed to "Resolved" and end date is not set, then it set to due date
To use this script properly, turn off "Use current date as start date for new issues" option in the settings as this script already do it own way.
if @issue.done_ratio_changed? if @issue.done_ratio==100 && @issue.status_id==2 @issue.status_id=3 elsif [1,3,4].include?(@issue.status_id) && @issue.done_ratio<100 @issue.status_id=2 end endif @issue.status_id_changed?
if @issue.status_id==2
@issue.start_date ||= Time.now
end
if @issue.status_id==3
@issue.done_ratio = 100
@issue.start_date ||= @issue.created_on
@issue.due_date ||= Time.now
end
end
上記のフック処理では、例えば、進行中(ステータスID＝2)かつ進捗率＝100％の状態でチケット更新したら、解決ステータス(ステータスID＝3)へ自動更新される。
また、解決ステータスで期日が空欄の状態でチケット更新したら、期日に今日日付へ自動更新される。
期日なしでチケット更新されると、ガントチャートにチケットが表示されないので、強制的に期日に日付を入れて自動更新されるフック処理があると良い時もある。
あるいは、終了ステータスへ更新する時に、進捗率も100％へ自動更新する処理を入れることもできるだろう。
なお、Redmine3.0.xでも、redmine_custom_workflowsは正常動作するみたい。
上記のRubyスクリプトを見る限り、トラッカーごとにワークフロー処理にフック処理を入れることは可能だろう。
例えば、トラッカーごとに、あるステータスでは分岐処理を入れたり、根回し・投票などの機能を入れたりすることも可能だろう。
つまり、ワークフロー処理をカスタマイズすることで、複雑な事務処理フローをRedmineで実現することは敷居がかなり低くなるに違いない。
Rubyを自由に操れる開発者がチームにいるならば、redmine_custom_workflowsプラグインにRubyスクリプトを挿入して実際に試してみてもいいかもしれない。
色々試してみたい。
Redmineを事務処理の申請承認ワークフローシステムとして使うとか、帳票ワークフローシステムとして使うアイデアを考えているうちに、RedmineをBPMツールとして使うアイデアについて考えてみた。
以下、ラフなメモ書き。
【元ネタ】
Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索
Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索
Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索
【1】BPMは、普通は、定型業務などの申請承認ワークフローをシステム化するもの、というイメージで捉えている。
その発想を更に進めて、既存の業務フローをBPMツールで全て見える化し、不要なプロセスや業務を削除して、あるべき姿の業務プロセスを定める、というBPRの側面も持つ。
Bonita BPM - オープンソースBPMジャパン株式会社
オープンソースのワークフローエンジンActivitiの感想: プログラマの思索
BonitaBPMを動かしてみた感想～BPMツールに必要な必須機能: プログラマの思索
BPMツールとして必要な機能は何か？
それは、「ワークフローエンジン」を持つことだろう。
ワークフローエンジンとは、Redmineは事務処理の申請承認ワークフローに使えるか？に書いたように、申請承認フローを制御するワークフロー管理機能と、分岐やビジネスロジックなどのビジネスルール機能を持つもの。
例えば、決裁金額によって承認フローを切り替える、とか、稟議・根回し・投票・相談などの特殊なワークフローが相当する。
【2】では、BPMツールの機能はRedmineで実現できるか？
下記で書いたように、簡単な申請承認フローならば、Redmineで実現可能だ。
しかし、幾つかの重要な機能がRedmineには不足している。
Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索
Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索
個人的には、Redmineに不足していると思う重要な機能は、ワークフローエンジンと組織マスタ管理だろうと思う。
【2-1】Redmineのワークフロー管理機能は、他のITSに比べれば、Web画面上でいくらでも種類を増やせるし、いくらでもステータスを追加できる利点がある。
また、トラッカーごとにカスタムフィールドを紐づけできるので、チケットに足りない項目を増やすこともできる。
このメリットこそが、日本のSIが持つ独自の複雑な開発プロセスを実現できる点につながり、Redmineを使っている状況が多いのだろう。
しかし、BPMのワークフローエンジンはもっと複雑であるのに対し、Redmineのワークフロー管理機能は初歩的すぎる。
他のBPMツールのワークフローエンジンのように、分岐・稟議・根回し・投票・相談・代行申請・代行承認などの機能も実現できなければ、日本企業の申請承認フロー全てに対応できないだろう。
もし、ワークフローエンジンをRedmineが持つとすれば、他のBPMツールのように、GUI画面でワークフローをVBライクに描いて設定できたり、ワークフロー設定情報をXMLでインポートしたりエクスポートできる機能が必要になるだろう。
【2-2】Redmineが他のITSに比べてメリットである点は、ロールによるユーザの操作制御が細かくできるし、ユーザグループによってユーザをカテゴライズする機能があることだ。
例えば、Redmineでは、ロールをいくらでも増やせるし、それぞれのロールごとに、Redmineのデフォルト機能だけでなく、プラグインの機能も操作を制限したり、参照権限しか付与しない、などという設定ができる。
しかし、市販のBPMツールは、組織マスタという人事情報とワークフローエンジンが密接に絡んだ機能を提供している。
大企業になるほど、組織階層は複雑になるし、役職も多いから、そのような状況に耐えれるような組織マスタ管理の機能が必要だ。
組織マスタ管理の機能は、実際の業務に当てはめると正直奥が深い。
イレギュラーな機能がかなり多いのだ。
例えば、大企業では、一人の人が複数の部署に兼務するケースがある。
すると、ログイン時に、どの役職や部署でログインするか、という制御が必要で、その役職や部署に応じた画面遷移や操作の制御が必要になる。
同様に、出張した社員に対し、上長が代わりに代理申請したり、代理承認する機能も業務上は必要だ。
このようなイレギュラーな業務にもシステムとして対応する必要がある。
【2-3】また、正式な組織構造だけでなく、非公式な組織構造を複数個持つ状況もある。
例えば、工場内では正式な役職名ではなく、その工場内だけでしか通用しない非公式な役職を作っていて、その役職に応じた業務があったりする。
特に生産ライン、品質管理の業務で多い。
あるいは、遠方の営業所では、部長以上の上級職がいない時に経費を決裁できるように、非公式な承認フローが必要だったりする。
他にも、グループ会社や海外の子会社の社員が混じっていれば、彼らの人事情報は、親企業の組織構造とは違って、別の小会社の組織情報が必要になったりする。
他に、社内の特別のプロジェクト型組織なども当てはまるだろう。
すなわち、組織情報は一つだけマスタ管理すべきものではなく、非公式な組織構造も別で保持できるようなマスタ管理の機能が必要だ。
さらに、組織情報には変更適用日を持たせるようにしたい。
例えば、4月の期首には、普通の大企業は大幅な人事異動があるが、普通は1ヶ月前には内示が出ていて、人事異動は確定している。
すると、4月1日に組織マスタを全て洗い替える作業を行うと、大企業になるほどデータ移行は1日では終わらない。
そのデータ移行のために、BPMのシステムが1日以上止まってしまうのは、本末転倒だ。
だから、組織情報に変更適用日を持たせて、4月1日に新たな組織情報に切り替わるような仕組みは必須だ。
【3】以上のように、RedmineにBPMツールの機能を実現するには、最低限、ワークフローエンジンと組織マスタ管理は必要だろう。
【3-1】しかしながら、BPMツールが本来のBPRを目指すツールであるならば、「標準ワークフロー基盤」と言うべき機能が必要であると思う。
「標準ワークフロー基盤」とは、事務処理の申請承認フローだけでなく、販売管理や購買管理、生産管理などでワークフロー機能が必要な時に、業務フローの中で申請承認する裏では、BPMツールのワークフローエンジンの機能をバックグラウンドで動作させることだ。
一般に「標準ワークフロー基盤」は、販売管理・購買管理・生産管理などの業務フローのうち、ワークフローの機能だけはBPMツールとSOAPなどのWebサービスでやり取りする方式で実現する場合が多いだろう。
すると、販売管理・購買管理・生産管理などの業務システムで使われる申請承認データは、BPMツールである標準ワークフロー基盤へWeb経由で流れこんで、一括で管理されるようになる。
この利点は、溜まった申請承認データを集計して分析することによって、業務の改善に役立てることができることだ。
ワークフローのどこでボトルネックになっているのか、どの業務やロールが無駄であるのか、という情報が得られるから、それによって、業務を改善するフィードバックが得られるのだ。
これこそが本来のBPRなのだろう。
【3-2】幸いなことに、Redmineは外部接続I/Fの機能が豊富なので、標準ワークフロー基盤として扱うことはできると思う。
例えば、RedmineのREST APIは、チケットを参照・更新できるし、プロジェクトやユーザ情報も取得したり更新もできる。
また、rakeのI/Fを実装すれば、例えば、マスタデータのバッチ処理や一括メール送信など、バッチ処理を実現できる。
すなわち、Redmineの外部接続I/Fを流用すれば、外部の業務システムからのデータとのやり取りは簡単に実現可能だろうと思う。
Redmineの裏の顔～開発基盤としてのRedmine: プログラマの思索
Redmineの外部接続、データ移行の機能: プログラマの思索
すると、標準ワークフロー基盤の役割を担うRedmineは、事実上、企業内のワークフロー基盤として、ワークフローに関するデータが一括集約され、そのデータを集計する機能をカスタマイズすれば、BPMツールとしてかなりいい線で製品化できるのではないか。
【4】Redmineについてこんなことを夢想していると、Redmineというツールは面白いなあと思う。
以前の僕は、Redmineはチケット駆動開発を実践することでアジャイル開発を実践できると考えていた。
他に、PMBOKのEVMやクリティカルパスを実現することで、RedmineはPMBOKで言うPMIS(プロジェクト管理情報システム)になりうると思っていた。
【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索
RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索
チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索
RedmineのガントチャートはMS ProjectのWeb版になりうるか？: プログラマの思索
さらに、Redmineをヘルプデスク管理として使うことで、CRMの代替にもなりうるのでは、と考えていた。
第8回勉強会の感想～RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索
RedmineはCRMソフトとして使えるか？Part2～RedmineをCRMソフトとして使うためのプラグイン: プログラマの思索
そして、Redmineを申請承認フローや帳票ワークフローシステムとして使えるならば、BPMツールを実現することもできるだろう。
そんなことを考えると、たった一つのオープンソースのツールに過ぎないRedmineがこれほどまでの可能性を秘めているツールであることに気づいて、ワクワクしてくる。
もう一度、Redmineでアジャイル開発が可能かどうか、フィットギャップ分析している。
僕はPivotal Trackerを仕事で使ったことがないので、あくまでも理解した範囲内で、考えたことをメモ書き。
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント | Social Change!
ユカイ、ツーカイ、カイハツ環境！（27）：いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門 (2/3) - ＠IT
Redmine Backlogsで簡単スクラム！プロダクトオーナーとして使う編 | 世界はどこまでもシンプルである
(引用開始)
ただし、Pivotal Trackerでは［Chore］［Bug］にポイントを付けることを強く否定しています。ひと言で理由を説明すると、［Chore］［Bug］はビジネス価値を提供しないからです。
(引用終了)
(引用開始)
作業(Chore) は必要ではあるものの、顧客の価値に直結しないストーリーです。たとえば「位置情報サービスへのサインアップ」「自動テストが長時間かかる原因を探し出す」などが作業です。作業には「コードの技術的負債」や他のチームに依存する箇所をあらわすことにも示せます。
(引用終了)
(引用開始)
そういった場合は、Pivotal Trackerではストーリーのカテゴリーに「Chore」と呼ばれるものがあり、それを設定します。歯車のアイコンで記されたChoreのチケットは、アクセプトが不要のワークフローが設定されています。つまり、プロダクトオーナーには関係なく、プログラマの作業が終わったら、それで終了になります。
(引用終了)
【1】Redmineでチケット管理をやり始めると、必ず問題になるのが、チケットの粒度だ。
特に、チケットをタスクカードと見なす場合、個人のToDoまで書くべきかどうか、必ず問題になってくる。
本来は、チケットはチームで共有すべき作業や課題を書くべきであり、自分一人だけのToDoはチケットに書く必要はない。
自分一人だけの作業までチケットに記載し始めると、チケットの枚数が極端に増えるデメリットがあるし、チームでチケットの棚卸しをする時にそれが対象になるのはおかしい。
でも、自分の忘れたくないタスクをチケットに書きたい時もある。
一つの解決方法は、Redmineのプライベートチケット機能を使って、自分だけのToDoは他の人に見せず、自分だけで管理するやり方がある。
そうすれば、他の人はプライベートチケットは管理の対象外になる。
もう一つの方法は、PivotalTrackerのように、内部タスクや顧客に価値を提供しないタスクは、別のトラッカーとしてチケットに登録するやり方もある。
【2】Pivotal Trackerには、Feature、Bug、Chore、Releaseの4つのトラッカーがある。
PivotalTrackerでは、顧客に価値を提供する作業は、Featureというトラッカーになり、ストーリーポイントによる見積り対象になる。
Featureのチケットは、プロダクトオーナーがストーリーをバックログに入れて、プログラマが上から順に取り出す。
プログラマがFeatureのチケットをDoneしたら、プロダクトオーナーにAcceptされて、OKならばリリースされて終了するし、NGならRejectされてPGへフィードバックされる。
一方、内部タスクを意味するChoreは、顧客に価値を提供しないタスクを意味する。
例えば、開発環境を作る、フレームワークをバージョンアップする、データ移行する、など、開発にとって重要だが、顧客にとっては価値とは思えないタスクを意味する。
ChoreのチケットはPGが自らチケットを作れるし、PG自らがDoneできる。
つまり、Choreのチケットの完了条件はプロダクトオーナーの承認が不要。
さらに、Choreのチケットはストーリーポイントによる見積り対象外になる。
なぜなら、顧客に価値を提供しないタスクなので、見積りに入れると、顧客の価値のサイズが狂ってしまうからだ。
すなわち、FeatureとChoreのチケットはトラッカーが異なるし、ワークフローも異なる。
【3】Redmineでも、Pivotal TrackerのFeatureとChoreの違いを取り入れて、チケット管理してもいいだろう。
その場合、トラッカーを区別し、ワークフローも区別する運用が良いだろう。
Pivotal Trackerを見ると、改めて、よくできているタスク管理ツールだと思う。
UIが直感的で、複雑な機能もない。
また、ストーリーポイントによる見積りを入力できるので、各スプリントのVelocityを収集できる。
過去の実績のVelocityが溜まってくれば、次回のスプリントでチームがどれだけのアウトプットを期待できるか、予測しやすくなる。
Pivotal Trackerが単なるタスク管理ツールだけでない理由は、Velocityを収集できるので、スプリントの見積りの精度が上がることと、それによってスプリント計画を立てやすくなることがあるのだろう。
この点は、WF型開発やPMBOKよりも優れている点だろうと思う。
WF型開発やPMBOKでも、PDCAサイクルを短く回す方法を何とか編み出そうとしているが、手続きやプロセスが重量過ぎることと、計画からリリースまでのサイクルが長すぎるために計画の変更がやりにくいことが弱点になるだろう。
実際、計画を変更しようとしても、過去の実績の数値は前工程の情報に過ぎず、後工程の見積りに使いづらいからだ。
【4】後もう一つの解決方法は、RedmineのBacklogsプラグインを入れて、RedmineでScrumを運用することだ。
Backlogsプラグインを入れれば、プロダクトバックログやスプリントバックログを管理できるし、親チケットをストーリー、子チケットをタスクとして登録できる。
また、課題はImpedimentとして、別のトラッカーとして管理できる。
さらに、ストーリーは予定工数で見積り可能なので、Velocityを計測することも可能だ。
【5】Redmineでアジャイル開発を実践する場合、基本はチケット駆動開発で十分に対応できると僕は思っている。
しかし、あえて弱点があるとすれば、下記3点があると思う。
1)チケットの粒度にバラつきが出やすい。
本来は、ストーリーカードとタスクカードは親子チケットにし、内部タスクは別トラッカーで管理するなどの工夫がいる。
2)チケットに優先「順位」を付けることができない。
Redmineチケットのデフォルト機能である優先度は、正直使いづらい。
「最優先」のチケットが2枚以上ある事実は基本はありえないから。
そうだとしたら、優先順位を付けていないのと同じ。
3)Velocityを計測しにくい。
予定工数、実績工数を入力し始めると、作業者はどうしてもバイアスがかかってしまい、予定工数を多めに余裕を持って見積もってしまいがち。
すると、その予定工数は余裕時間が多すぎて、正しい見積もりにならない。
いずれの弱点も、BacklogsプラグインやPivotal Trackerの良い部分を真似るのが一つの解決策。
この辺りをもう少し考えてみたい。
Windowsでは最近のCRubyと相性が悪い。
JRubyでRedmineBacklogsプラグインを動かす方法が成功したのでメモ。
Redmine Backlogs :: Installation
BitNami Redmine に Backlogs プラグインをいれてみた - daidai7の日記
Redmine3.0.3をWindows7にインストール時はJRubyを使うと上手くいく: プログラマの思索
【環境】
Windows7
java version "1.8.0_11"
jruby 1.7.20.1 (1.9.3p551) 2015-06-10 d7c8c27 on Java HotSpot(TM) 64-Bit ServerVM 1.8.0_11-b12 +jit [Windows 7-amd64]
Redmine2.6.5
XAMPP
【手順1：Redmine2.6.5をインストール】
mysql.exe -uroot
↓
create database redmine265 character set utf8;
↓
%REDMINE_ROOT%/config/database.yml
を開き、database: redmine265 へ修正
↓
cd %REDMINE_ROOT%
jgem install bundler --no-rdoc --no-ri
↓
jruby -S gem install activerecord-jdbcmysql-adapter
jruby -S gem install activerecord-jdbcpostgresql-adapter
↓
jruby -S bundle install --without test development sqlite3
↓
jruby -S bundle exec rake generate_secret_token
↓
jruby -S rake db:migrate RAILS_ENV=production
↓
jruby script/rails server webrick -e production
↓
http://localhost:3000
admin/adminでログイン成功
【手順2：RedmineBacklogsをインストール】
cd %REDMINE_ROOT%
↓
jruby -S gem install holidays --version 1.0.3
jruby -S gem install holidays
↓
jruby -S bundle exec rake db:migrate RAILS_ENV=production
を実行すると、次々にGemが不足しているというエラーが出る。
本来は、RedmineBacklogsプラグインのGemfileをbundlerで読み込ませるべきだったのではないか、と思う。
cd %REDMINE_ROOT%
jruby -S bundle install --no-deployment
↓
jruby -S gem install icalendar
jruby -S gem install open-uri-cached
jruby -S gem install prawn -v 0.12.0
jruby -S gem install inifile
jruby -S gem install chronic
jruby -S gem install ZenTest -v4.5.0
jruby -S gem install autotest-rails
jruby -S gem install faye-websocket -v0.4.7
jruby -S gem install poltergeist
jruby -S gem install cucumber-rails
jruby -S gem install culerity
jruby -S gem install database_cleaner
jruby -S gem install rspec -v2.11.0
jruby -S gem install rspec-rails -v2.11.0
jruby -S gem install simplecov
jruby -S gem install spork
jruby -S gem install timecop -v0.3.5
jruby -S gem install capybara -v1.1.0
jruby -S gem install poltergeist -v0.6.0
jruby -S gem install cucumber -v1.1.0
jruby -S gem install cucumber-rails2 -v0.3.5
↓
BitNami Redmine に Backlogs プラグインをいれてみた - daidai7の日記を参考にして、
%REDMINE_ROOT%\Gemfile
の冒頭に、
gem "rake"
を追加する。
↓
jruby -S bundle exec rake db:migrate RAILS_ENV=production
↓
jruby -S bundle exec rake tmp:cache:clear
jruby -S bundle exec rake tmp:sessions:clear
↓
jruby -S bundle exec rake redmine:backlogs:install RAILS_ENV=production
io/console not supported; tty will not be manipulated
io/console not supported; tty will not be manipulated
2.6.5.stable. You are running backlogs v1.0.6, latest version is 1.0.6
=====================================================
Redmine Backlogs Installer
=====================================================
Installing to the production environment.
Fetching card labels from http://git.gnome.org...done!
Configuring story and task trackers...
-----------------------------------------------------
Which trackers do you want to use for your stories?
1. バグ
2. 機能
3. サポート
Separate values with a space (e.g. 1 3): 2
You selected the following trackers: 機能. Is this correct? (y/n) y
-----------------------------------------------------
Which tracker do you want to use for your tasks?
1. バグ
2. サポート
Choose one from above (or choose none to create a new tracker): 2
You selected サポート. Is this correct? (y/n) y
Story and task trackers are now set.
Migrating the database...io/console not supported; tty will not be manipulated
** Invoke redmine:plugins:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute redmine:plugins:migrate
** Invoke db:schema:dump (first_time)
** Invoke environment
** Invoke db:load_config (first_time)
** Execute db:load_config
** Execute db:schema:dump
io/console not supported; tty will not be manipulated
** Invoke redmine:backlogs:fix_positions (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute redmine:backlogs:fix_positions
done!
Installation complete. Please restart Redmine.
Thank you for trying out Redmine Backlogs!
↓
http://localhost:3000
admin/adminでログイン成功
↓
管理＞ロールと権限 で、RedmineBacklogsの全機能をONにする。
管理＞プラグインで、色々設定できる
↓
プロジェクト作成後、設定＞モジュールで、RedmineBacklogsを選択する。
【注意】
【1】RedmineBacklogsプラグインは、今の所、Redmineの一つ前のバージョン2.6.xでしか対応していないようだ。
【2】WindowsでCRuby2.2を動かそうとすると、MySQLのドライバ更新でいつもエラーが出る。
Rubyの開発はもやはWindowsでやるのが無理なのかもしれない。
【3】RedmineBacklogsのGitHubを見ると、もう1年間も更新がない。
RubyやRails、Redmineの度重なるバージョンアップに、RedmineBacklogsも耐え切れなくなったのだろうか？
こういう事例を見ると、RubyやRailsのアプリ開発は、後方互換性を維持するのがとても大変ではないか、という気になってくる。
VBやJavaでさえ後方互換性を維持するのが大変なのに、Rubyのバージョンアップの速度は異常に速いので、追いつけないアプリが多いのではないか、と推測する。
そんな状況でも、Redmineが追随しているのは大したものだと思う。
たまたま読んだ小さな会社を強くする ブランドづくりの教科書
ネットで調べたら、中小企業診断士の事例2「マーケティング」の参考図書だったらしい。
以下は、琴線に触れた言葉をメモ。
【1】日本の技術力は高いと言われる。
しかし、モノづくりでは勝ったのに、ブランド作りで負けた企業が多いのではないか。
強いブランドは名前も品質も超える。
日本は、90年代はコストダウン、2000年代からブランドづくりへ。
守りの経営から攻めの経営へ。
ブランドは言葉だけではない。
ブランドはイメージ。
ブランドは意味。
【2】ブランド力の強い企業ほど好業績。
その理由として、4つの要因がある。
数量プレミアム効果。
品質が同じでも、競合製品よりも選ばれやすい。
価格プレミアム効果。
消費者の価格の受容度が高いため、高い価格を設定できる。
リピート効果。
ブランドが、リピート顧客を増やす。
口コミ効果。
ブランドが、口コミによって顧客が顧客を呼ぶ。
つまり、数量プレミアム効果 *価格プレミアム効果 *リピート効果 *口コミ効果 ＝好業績 になる。
【3】小さな会社を強くする ブランドづくりの教科書
たとえば、アメーラのブランドイメージは「最高品質の高糖度トマトで、おいしさの感動をお届けします」。
ブランドアイデンティティである価値生(最高品質)、独自性(高糖度)、共感性(おいしさの感動)を伝えている。
強いブランドはコトを伝える。
消費者は財布の余裕ができると、モノからコトに向かう。
「トマトの購入」よりも「食の安全性」「美味しさの感動」の方が、購買額が高い。
「化粧品の購入」よりも「美しくなるため」「健康になるため」の方が、購買額が高い。
人々にモノを売り込むのではなく、コトを提供する。
それがブランドを強くする。
【4】ブランドを作るには、大きな市場の2番手よりも、ニッチな市場で1番手になること。
ポジショニングマップで、ブランドを対象とするマーケットや顧客を明確にすること。
ブランドイメージを擬人化すると分かりやすい。
例えば、一般的なトマトのイメージは「明るく元気な20代の女性」。
アメーラのイメージは「やさしく穏やかな大人の女性」。
ブランドパーソナリティが明確であれば、一貫性を持ったブレないブランド戦略が可能になる。
すると、パンフレットや広告、ロゴのイメージのすり合わせがやりやすくなる。
【5】強いブランドの土台は品質。
しかし、企業が提供する品質と消費者が求める品質は違う。
たとえば、アメーラというトマトの場合、「ヘタがない」「皮が厚い」というデメリットがある。
しかし、それを「ヘタがないので形が美しい」「ヘタがないのでゴミが出ない」「ヘタがないので弁当に使いやすい」「歯ごたえが楽しめる」「ぱきっとした食感がある」と読み替えればいい。
ブランドが持つ高い品質を、消費者が求める品質に合わせて伝えるようにすること。
【6】目に見えないブランド価値。
ブランドの具体的な表現要素をブランド要素と呼ぶ。
消費者は目を通して、ブランドを味わう。
ブランド要素では、ロゴ、パッケージングが重要。
たとえば、アメーラでは、白い箱にプラスチックの透明カップにミニトマトを入れて、おしゃれにした。
これが、女性層に受けた。
ブランド要素で重要なのはハーモニー。
ブランド要素間の統一感が大切。
強いブランドには色がある。
スターバックス、コカ・コーラ、アップルには色がある。
たとえば、アメーラには、赤いトマトと黄色いトマトがある。
でも、ブランドの拡張は諸刃の剣。
アメーラというトマトのブランド拡張なら、トマトジュースやトマト料理などがあるだろう。
【7】広告に頼らないブランドつくり。
中小企業は、宣伝広告にかける費用が少ない。
でも、現代は、SNSによる口コミ効果が大きい。
スタバ好きの人の周囲には、スタバ好きが多い。
類は友を呼ぶ。
コカ・コーラ、アップル、ソニー、ルイヴィトン、ディズニーランドなど。
広告よりも口コミの方が影響力が大きい。
また、口コミで獲得した顧客はリピータになりやすい。
そのブランドを気に入った人の周囲には、似たような人が多いので、ブランドと相性が良い人が多い可能性が高い。
口コミの促進を活発化させる方法は何か？
体験が口コミを促進する。
口コミの種を蒔く。
口コミを利用したブランドづくりでは、インフルエンサーを特定し、その人達の力を活用するのが最も有効。
インフルエンサーと自社の距離を縮めてもらうことが大切。
【8】強いブランドの価格戦略は、セールやディスカウントをしないこと。
低価格戦略ではなく、価値で顧客を惹きつける。
価格で惹きつけた顧客は、価格で逃げていく。
100万円のワインはなぜ美味しいか。
認知的不協和の理論。
人は、無意識でつじつまを合わせる。
ブランドが強くなると、価格の好循環を達成できる。
強いブランドは、価格競争に巻き込まれることもない。
【9】ブランドが失敗する10の理由。
品質管理がしっかりしていない。
戦略がない。
共感性の欠如。
コミュニケーションに一貫性がない。
無関係なブランド拡張。
なんでも屋になる。
消費者の声を聞かない。
値引き競争をする。
感性に訴えない。
チャレンジせず、現状維持で良しとする。
ブランドも定期的に健康診断すべき。
【10】感想
自分が何かしらのソフトウェア製品を作っていて、販売したいとする。
その時、その製品にどんなブランドを持たせて、販売すべきか、というように考えると、すごく身近に感じる。
ブランドづくりの話は、ビジネスフレームワークの4Pそのものだなあ、と思う。
4Pの製品戦略、価格戦略、物流戦略、販促戦略にそのまま展開される。
小さな会社を強くする ブランドづくりの教科書
中小企業の方が、とんがった製品にブランドイメージを作って販売することに向いている。
大企業はしがらみも多いし、既存の製品が逆に新製品の邪魔になる場合もあるから。
同著者の「スモールビジネス・マーケティング―小規模を強みに変えるマーケティング・プログラム
今度また読んでみる。
7/17に第42回IT勉強宴会「話題のRedmineの魅力を知ろう」が開かれます。
【元ネタ】
第42回IT勉強宴会 話題のRedmineの魅力を知ろう : ATND
(引用開始)
日時 :2015/07/17 (金) 18:30 to 20:30
定員 :35 人
参加費 :無料
会場 :JAC Recruitment 大阪支社会議室（大阪市北区梅田2-2-2 ヒルトンプラザウエスト 12F）
話題のRedmineの魅力を知ろう
最近、Redmineという名前を良く聞くとは思われませんか？私は昔Mantisを障害管理システムとして使った事がありました。その時にRedmineも調べたのですが、Mantisを選びました。ところが最近はRedmineばかり耳にします。
Wikiによると RedmineはRuby on Railsで開発されている、Webベースのプロジェクト管理ソフトウェアである。 だそうです。
Amazon.co.jpで「Redmine」と調べると21冊ヒットします。今年まだ出る予定だと聞いています。いったいRedmineのどこがそんなに広がっている理由なんでしょう？
幸いなことにIT勉強宴会の常連さんに最近出たRedmine本の著者がおられるので教えてもらう事にしました。また日本でRedmineをインターネット上で提供されている「Redmine.jp」を運営されている社長さんにもお越し頂ける事になりました。
・Redmineを聞いたことがない方は参加してシッタカ（知ったかぶり）しよう
・使おうか迷っている初心者には必ず参考になります
・普段使っている方は極めた方と情報交換しましょう
・極めている方は飲み会でRedmineを広めましょう
(引用終了)
個人的には、関西のモデラーの勉強会にも、Redmineが話題にのぼってきた、というのが驚きであり、興味深いです。
@sakaba37さんが言うように、Redmineはキャズムを超えて、マジョリティも興味を持つようになったのでしょう。
6月は、「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント
【告知】「Redmine実践ガイド 理論と実践、事例で学ぶ新しいプロジェクトマネジメント」がついに出版: プログラマの思索
先日、関西IT勉強会でブリビオバトルがあった。
その時に、ブルーオーシャン戦略の本の感想を聞いて、ようやくその意味を理解できたのでメモ。
以下は疲れた頭で、ラフなメモ書き。
【参考】
N's spirit ブルーオーシャン戦略とは 戦略キャンバス
【1】アイデアに基づく製品をどのマーケットに売り出すべきか、あるいは、こんな商品があるがどう売り出したらいいか、その戦略を考える時に、ブルーオーシャン戦略が役立ちそうな気がする。
【2】「ブルー・オーシャン戦略
アクション・マトリックスでは、製品の原型に対し、「取り除く」「減らす」「付け加える」「増やす」ことによって、新たな価値を生み出す。
つまり。、アクション・マトリクスは、アイデアから生み出された製品の原型に対し、まずは機能やデザインのうち不要なものを取り除き減らす。
そこから、新たな機能やデザインを付け加えて増やす。
この考え方は、MVP(minimum viable product)に似ている。
リーンスタートアップに出てくるMVPは、製品の機能は必要最低限として、市場のフィードバックを得ながら仮説検証していく。
最初から機能てんてこもりではないのだ。
【3】戦略キャンパスは、横軸に顧客に提供する価値、縦軸に顧客が享受するメリットのグラフを描くこと。
ポイントは、横軸に、アクション・マトリックスで見出した新たな価値観を追加することで、他のライバル企業の差別化を図る。
まだ誰も販売していない未知のマーケットに売り出せれば、それがブルーオーシャン。
「ブルー・オーシャン戦略
戦略キャンパスの考え方は、ポジショニングマップの描画に使えるのではないか、と思う。
ポジショニングマップは、実際は結構書きにくい。
肝心の縦軸・横軸の評価項目をなかなか洗い出しにくい。
でも、戦略キャンパスは、数多くの評価項目を抽出してくれるので、効果的に使えそうな項目を選んで、プロットする内容が散らばるようにできればいい。
ポジショニングマップを描けば、ブルーオーシャンのマーケットは、必ずどこかのエリアに存在し、そこはまだ手つかずの領域でもあることが如実に表現される。
【4】「ブルー・オーシャン戦略
ファイブフォース分析の概要とやり方 | カイロスのマーケティングブログ
5フォース分析（5つの競争要因）［ITCサンシャイン・ブレインズ］
ファイブ・フォース分析は、特定業界の外部環境を分析するのに使われるが、「市場の境界を引き直す6つの視点」と被っているような気がする。
その理由は、双方ともに、外部環境の分析に使われるからだろう。
１．代替産業に学ぶ→代替品の脅威
２．業界内の他の戦略グループから学ぶ→既存企業同士の競争、新規参入者の脅威
３．買い手グループに目を向ける→買い手の交渉力
４．補完財や補完サービスを見渡す→サプライヤーの交渉力
５．機能志向と感性志向を切り替える
６．将来を見通す
最近のコメント