2016/08/24

Wiki ListsプラグインでRedmineをカード型DBと見なしRedmineをCRM化するアイデア

Wiki ListsプラグインでRedmineをカード型DBと見なすアイデアをメモ。
ラフなメモ書き。

【参考】
tkusukawa/redmine_wiki_lists: wiki macros of redmine to display lists of issues.

Wiki Lists - Wiki Lists - r-labs

RedmineCRM - Premium Redmine plugins, CRM, Helpdesk, Invoices

プロジェクト管理ソフトRedmine用プラグイン「RedmineCRM」を追加しました|新着情報|テガラ株式会社

RedmineはCRMソフトとして使えるか?Part2~RedmineをCRMソフトとして使うためのプラグイン: プログラマの思索

RedmineはCRMソフトとして使えるか?: プログラマの思索

第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

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

【1】カード型DBは名刺や年賀状の管理みたいなもの。
ITに詳しくない人なら、RDBよりもカード型DBの方が親しみやすいだろう。

3分でわかる!仕事に役立つExcelテクニック - データ入力は“カード型データベース”方式でお手軽に:ITpro

ASCII.jp:世界初!? クラウドベースのカード型データベース (1/7)

カード型DBのUIは初心者には分かりやすい。
入力したデータがそのまま一覧になるだけ。

カード型DBは名刺管理のように、顧客データ管理で使いたいものだ。
つまり、カード型DBのUIはCRMと相性がすごくいい。
すなわち、カード型DBで顧客の名刺から顧客データを登録し、打ち合わせや受注状況、請求やフォローなどまでデータを紐付ければ、CRMそのものになる。

【2】では、Redmineでカード型DBを実現できるだろうか?

@mattaniさんから、Wiki Listsプラグインを使うとRedmineをカード型DBと見なせるよ、という話を聞いて、これだ!と思った。
WikiListプラグインは、RedmineのWikiマクロを拡張して、チケット集計やクエリを実現してくれる。

【2-1】カード型DBの実現方法のイメージはこんな感じ。

「台帳」トラッカーのチケットを1枚作る。
次に、「名刺」トラッカーのチケットに、オペレータが顧客情報をどんどん登録していく。
もちろん、台帳トラッカーや名刺トラッカーは、カスタムフィールドを追加して、名刺や台帳用にカスタマイズすればいい。

最後に、名刺トラッカーを抽出するクエリを作り、台帳トラッカーのチケットの説明欄に、WikiListプラグインのWikiマクロでそのクエリを書けばいい。
すると、台帳トラッカーのチケットの説明欄に、名刺チケットの一覧が表示される。
もちろん、表示項目はWikiマクロで好きなようにカスタマイズできる。

また、Ver3.3から、トラッカー単位にチケット編集の権限を制御できるようになった。
つまり、管理者は台帳トラッカーを編集できるが、オペレータは名刺トラッカーしか登録できない、という運用も可能だ。

Redmine 3.3新機能紹介: トラッカーに対するロールベースの権限制御(チケットの閲覧/追加/編集/削除/注記の追加) | Redmine.JP Blog

【2-2】この方法によって、何が変わるのか?
つまり、「台帳◇--名刺」というチケット構造を表現できる。

たとえば、WikiListのマクロで、グループ単位の顧客リスト、地域別の顧客リスト、優先順位別の顧客リストで分けて、複数の台帳を作ればいい。
そうすれば、台帳トラッカーのチケットだけを管理すれば、全ての名刺を好きなように整理することができる。

【2-3】チケットの再帰構造をWikiListプラグインで実現する方法以外に、「親子」「関連する」「先行・後続」のチケット関連機能を使うやり方もある。

「親子」「関連する」「先行・後続」のチケット関連機能よりもWikiListプラグインが優れている点は、手軽さにあるだろう。
チケットの関連機能は、画面上で手作業で登録する必要があり、手間がかかる。
また、チケットの関連の整合性を取るのが面倒。

しかし、WikiListプラグインなら、SQLの感覚でチケットを簡単に抽出できる。
ちょっとWikiマクロを書くだけで、特定チケットに、配下のチケットをまとめることができ、すぐにリンクで詳細を見ることもできる。

なお、「親子」「関連する」「先行・後続」のチケット関連機能があれば、ガントチャートを綺麗に表示できるメリットがあるが、その保守は結構面倒だ。
ガントチャートを使う必要が無いならば、WikiListプラグインでカード型DBを実現する方が手軽だし、いくらでもチケットを登録しても好きな様に集計したり抽出することができるメリットがある。

【3】Redmineチケットをカード型DBと見なすことで、どんな利用シーンが増えるだろうか?
まず、Redmineのデフォルト機能のまま、CRMの機能をかなり実現できるのではないか?

たとえば、顧客データ管理用のRedmineサーバーを立ち上げて、ほとんどのチケットは名刺データそのもの。
台帳チケットは、地域別・グループ別・優先度別などの観点で名刺チケットを集めたもの。
打合せチケット、問合せチケット、案件チケットは、顧客の問合せなどのヘルプデスク管理に相当する。

つまり、チケット管理だけで、顧客の属性情報の管理だけでなく、顧客とのやり取りの履歴もRedmineで一元化できるはずだ。
最終的には、CRMだけでなく、帳票ワークフロー管理のようなBPMツールにも一般化できるだろう。

Redmineの面白さは、色んな事例や業務に適用できる点だ。
そのメリットの背後には、PMBOK、ITIL、ソフトウェア工学、CRM、BPMなどのアイデアが隠れているからこそ、面白いのだ。
色々考えてみたい。

| | コメント (0)

2016/08/17

MS Projectの基準計画の使い道

MS Projectの基準計画の機能についてメモ。

【参考】
MS Project を使おう!さんのツイート: "MS Projectを使うに当たって、「基準計画」を使いこなすことは非常に重要です。これがあって初めてアーンドバリューなどの進捗管理方法で予定と実績の比較が可能になります。 #MSProject"

STEP 5-1: プロジェクト計画の確定-基準計画の保存 | Quantum Harmony Corp.

プロジェクトが計画通りに進んでいるかどうか「基準計画の保存」で比較検証を行う(Microsoft Project) | 雑記 BOOOKs

MS-Project の使い方 | ins13の日記 | スラド

プロジェクトリーダーならば、普通はMSProjectが必需品だろう。
MSProjectは、計画を立てるのがやりやすい。
WBSをExcelでざっくり作り、MSProjectに貼り付けて、先行後続関係をつければ、とりあえずラフなスケジュールを立てることができる。
その後、担当者にタスクを割り振り、実績管理していく。

その時、基準計画時という機能で、プロジェクト計画時点やリスケ前に、計画情報一式を保存すると良い。
基準計画はベースラインと同義。

その時点の計画をベースラインとして保存し、予実管理だけでなく、当初の計画と現在の計画がどれくらい変化したか、比較評価する時に使う。

プロジェクト立上げ時では、開発者を確保できず、担当者未定だったりするが、テスト工程の1ヶ月以上前になれば、担当者を誰にするか決まってくる。
あるいは、顧客の仕様変更でリスケが発生し、予定工数も増えた場合も考えられる。

もちろん、当初の進捗よりも遅れてしまい、リカバリーせざるを得なくなる場合もある。

そんな時に、基準計画というベースラインを定期的に保存して、計画情報を比較評価できるようにしておけば、現実的なスケジュールを作りやすくなるだろう。

但し、MSProjectの古いバージョンでは、基準計画は11個しか保存できない、という制約があるので注意が必要かな。
Redmineにもそんな機能があるといいなと思ったが、何と、LycheeGanttChartにはそんな機能があると言う。

MSProjectに慣れたプロマネなら、Redmineに有償のプラグインを導入して、ガントチャートをMSProjectのように修正できると便利かもしれない。

【追記】
Kさんのツイート: "@akipii Redmine Easy GanttプラグインのPRO版=有償版にもベースライン機能があるので参考までに。 ▼URL https://t.co/itdMAcXNrH ▼動画(44秒〜) https://t.co/VipO4SqNyk"

| | コメント (0)

マイクロサービスアーキテクチャはなぜ最近になって注目されるのか~マイクロサービスは組織論の側面も持つ

「マイクロサービスアーキテクチャ」を読んだら、すごく面白かった。
ThoughtWorksの開発者が書いた本は、どれも随筆っぽく、個人的にはどれも面白い。
マイクロサービスに関するラフなメモ書き。

【参考】
akipiiさんのツイート: "「たぶんマイクロサービスは本当に組織論」という言葉がすごくイイ!ソフトウェア工学の理論で整理できないかな?マイクロにしすぎた結果がこれだよ! #architecture #golang https://t.co/3w5pY6aedt"

Yoshihito Kuranukiさんのツイート: "プログラミング、それも優れたソフトウェア設計で学んできたことは、経営をする助けになっている。組織とソフトウェアの構造は似るという「コンウェイの法則」を逆に考えれば、良いソフトウェアの設計を応用すれば、良い組織の設計ができる、とも考えられる。そもそも会社とはソフトウェアなのだから。"

akipiiさんのツイート: "逆コンウェイの法則。組織構造はアーキテクチャに合わせる。経営者の観点では、組織は経営戦略に従うのだから、アーキテクチャの下で組織構造を従わせる感覚は普通なのかもしれない。 https://t.co/8FYPiEDyjh"

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

マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング - Qiita

マイクロサービスを設計するときはエンジニアの発想を捨てる

今話題のマイクロサービス・アーキテクチャについて、本格的に実践中のビズリーチさんに聞いてみた! | HTML5Experts.jp

マイクロサービスの実際: 第 1 回 マイクロサービス入門

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

【1】マイクロサービスアーキテクチャはなぜ今頃、流行しているのだろうか?
@sakaba37さんにに、「マイクロサービスアーキテクチャ」の本が面白かったんですよ、とちょっと興奮気味に話したら、怪訝な顔をされた。

マイクロサービスというアーキテクチャの発想は既に知られているし、分割するのは当たり前だ。
でも、どの粒度まで分割すべきなのか、分からない。
従来のソフトウェアの分割統治の設計手法と何が違うのか?

マイクロサービスで、仮想環境や継続的デリバリーや自動テストの最新技術を取り入れて、早くリリースできるのは理解できるが、それら技術を使えば早くリリースできるのは他の設計でも同じ。
組織構造とマイクロサービスが密接に関連していて、マイクロサービス単位のチームを構成すべき、という観点も、従来のConwayの法則からして、当たり前ではないか、と。

確かに、そうだな、と思う。
では、従来の設計思想と何が違うのだろうか?

【2】マイクロサービスが今頃になって注目される理由は、「外部システム連携」「プラットフォーム」「組織構造」の3つの観点があるから、と思う。

【2-1】僕がマイクロサービスに興味を持つのは、社内の数多くの業務システムを開発したり保守していると、「外部システム連携の設計手法の一つ」としてマイクロサービスアーキテクチャが必要になってくる場面が多くなっているからだ。
以前は、外部システム連携と言えば、無数のバッチをフローでまとめたバッチ処理が主流で、ジョブフローのどこかが止まればバッチ処理が止まってしまう。
バッチ処理で設計すると、リランや運用フォローで必ず手作業の運用手順が入り込んで、更に作業が複雑になる。

そこで、外部システム連携をマイクロサービスでオンラインでリアルタイムにやり取りできるようにすれば、運用もかなり楽になる。
機能追加もやりやすい側面がある。

従来はバッチ処理でしか設計できない場面が多かったが、最近はサーバーの高性能化やクラウドのおかげで、マイクロサービスで作りやすくなった経緯もあるだろう。

【2-2】外部システム連携をマイクロサービスで作るようになると、元のシステムは、外部システムと連携しやすいようなAPIを多数作りこむ必要が出てくる。
そのAPIがマイクロサービスに相当するように作る場面が多い。

すると、元のシステムは「プラットフォーム化」してくる。
つまり、外部のシステムから見れば、マイクロサービスのAPIを提供するシステムは、重要なデータが蓄積されたデータ基盤である。
そのデータを取得したいために、マイクロサービスというAPIが必要になってくる。
その外部接続用APIは、リアルタイムに取得できるI/Fが良い。
たとえば、REST APIがその一つだろう。

そんな事を思うと、Redmineは一つのプラットフォームであるように思えてくる。
なぜなら、Redmineはソフトウェア開発案件の作業情報が蓄積された一つの情報系システムであり、そのデータはREST APIで好きなように外部システムから取得できるからだ。
たぶん、Redmineが日本で普及した理由の一つは、データが蓄積されるほど有用なシステムであり、そのデータをREST APIでいつでも取得できて、外部システム内でデータを加工できる点にあると思う。

【2-3】システム機能をマイクロサービスで設計してみると、システムは複数のサブシステム(マイクロサービス)に分割され、それらサブシステムが連携して一つのシステムとなるような設計になってくる。
つまり、システム構造はより複雑になる。
すると、それぞれのサブシステム毎に開発チームが作られて、システム単位の並行開発になってくる。

そういう側面を見ると、マイクロサービスごとに開発チームという組織構造が現れる。
Conwayの法則は「アーキテクチャは組織構造に従う」であるが、マイクロサービスの設計思想が浸透すると、「アーキテクチャ(マイクロサービス)に合わせて組織(開発チーム)が従う」という逆コンウェイ戦略の思想が自然に出てくる。
この部分がすごく面白いと個人的に思っている。

なぜなら、開発者主導で組織構造が変化する場面に遭遇することができて面白いからだ。
普通は、経営者が自分の戦略に基づいて、トップダウンで組織構造を定める。
開発者は、その組織構造に従って作業するしか無い。

でも、マイクロサービスアーキテクチャでは、マイクロサービスに合わせたチーム構成が自然であり、そのような組織構造を作ることが推奨される雰囲気になる。
マイクロにしすぎた結果がこれだよ!の中で「たぶんマイクロサービスは本当に組織論」という言葉が出てくるけれど、おそらくそんな感触なのだろうと推測する。

【2-4】アーキテクチャと組織の密接な関係は、知っている人は当たり前の概念みたいだが、僕にとっては、そんなに当たり前の概念でもない。
現代の日本のソフトウェア工学、ソフトウェアプロセスの問題の真因を探ると、結局、組織論の問題になってしまう場合が多いのではないか、と思ったりする。

組織構造は一度定めると、組織慣性が働いて、組織内部のメンバーはもちろん、経営者ですらも組織を変更できなくなる場合が多い。
たとえば、官僚制組織が最たる例だ。
つまり、組織構造は一旦作られると、それを変更するのは難しく、人々は組織に嫌々ながら従わざるをえない。

【2-5】一方、作られたシステムの設計に従って作られたチームがどんどん肥大化して大規模組織となり、その組織設計が経営戦略の障害になる事例もある。

たとえば、「マイクロサービスアーキテクチャ」の本では、こんな話があった。

大規模インターネットが出現する前の時代に、Webサイトを持つ大手印刷会社はCMSを作った。
そのCMSは、料金を支払った第三者がコンテンツを入力するシステム、そのデータを加工する中央システム、一般大衆が閲覧できるフロントシステムの3つに分割されていた。
当時は、入力・中核・出力の3つのシステムと密接に連携した組織が、小規模ではあるが、部門として作られた。

当初は、オンデマンドのビジネスは小さかったが、じきにCMSを中核としたオンデマンドのビジネスが従来の印刷事業を上回るようになった。
すると、組織構造が事業の成長に合わなくなってきて、不都合になってきたのだ。

つまり、事業のIT側の3つの部門はそれぞれ、入力・中核・出力の3つのシステムに一致しており、それぞれの部門で別々のデリバリーチームがあった。
この組織構造がシステム設計よりも前に存在しておらず、実際にシステムを中心に組織が形成されていった、ということを誰も自覚していなかったのだ。

しかし、組織構造をすぐに変えることは難しい。
上記の事例で組織変革が難しい理由は、組織の元になる入力・中核・出力の3つのシステムを変えなければ、組織をいくらいじっても、逆に業務に支障が生じてしまうためだ。

一般には、組織変革が失敗する理由は、組織慣性が働くために、経営者ですらも組織構造やそれに基づく組織文化を変えることが出来ないからだ。

上記の事例では、システム設計の欠点に気付き、組織構造を変更するためにシステム移行を行なっているらしい。
しかもその移行プロセスは、何年も経ったのに、今も進行中らしい。

そんな話を読むと、頑固な組織構造や組織文化の背後には、時流に合わないシステム設計がその根本原因である場合もある、ということに気づく。

【3】マイクロサービスが今頃になって出てきたのは、上記だけでなく、技術がようやく揃ってきたこともあるのだろうと思う。
開発環境や本番環境の仮想化がやりやすくなり、AWSのようなクラウドにすぐに乗せることができて、コミットできれば即リリースできるような仕組みが整ってきた。
つまり、継続的インテグレーション、継続的デプロイ、継続的デリバリーのような技術とマイクロサービスはすごく親和性が高い。

そのおかげで、マイクロサービスアーキテクチャというボトムアップの設計手法が注目されるようになったのだろう。

【4】でも、マイクロサービスが全ての問題を解決するようなバラ色の手法ではない。
たまたま設計してみたら、マイクロサービスという共通の設計手法が作れるのでは、という感じだ。

「マイクロサービスアーキテクチャ」の本でも、最初からマイクロサービスで分割する設計をするよりも、ある程度システムの機能が揃ってきた後に、マイクロサービスに分割するようにリファクタリングすることを勧めている。
つまり、最初からマイクロサービスで設計できる場面はそう多くないらしい。
実際、たとえば、Redmineもある程度チケット管理の機能が揃ってきた後で、REST APIが次々に作られて公開された歴史がある。
最初からマイクロサービスで作ろう、という発想はなかったのだろう。

一方、SOAはトップダウンの設計手法であり、最初から外部接続できるようなAPI設計をすべき、という思想が貫かれている。
SOAとマイクロサービスは共通点もあるが、相違点も多い。

個人的には、マイクロサービスを再利用可能なコンポーネントとみなして、デザインパターンのような設計パターン集が作れるといいなあ、と思っている。
Webシステム、Webサービスのより良い設計手法は発展途上であり、その手法はぐちゃぐちゃで整理されていないからだ。

【5】個人的には下記2つの資料がすごく分かりやすい。

| | コメント (0)

2016/08/13

ViewCustomizeプラグインでRedmineをマイクロコア化できるか

ViewCustomizeプラグインの使い道に関してメモ書き。

【参考】
Redmineのプラグイン「view customize plugin」のカスタマイズ例 - Qiita

onozaty/redmine-view-customize: View customize plugin for Redmine

onozaty/redmine-view-customize-scripts: Script list for "Redmine View Customize Plugin"

【1】ViewCustomizeプラグインは面白いプラグインだ。
CSS+JQueryを知っていれば、RedmineのUIを好きなように修正できる。

たとえば、「ある文字列を赤字にして強調したい」「背景色を変えたい」「障害チケットのテキストエリアを広げたい」「サポートチケットが起票されたら担当者はサポートユーザグループに設定したい」「二つのプルダウンリストの選択肢に制約を付けたい」などの場面に使える。

neta@とんこつしかたべないさんのツイート: "Redmine で特定PJのデフォルト期日を今日から10日後にする、できたぁああ! またこれで一つユーザ要望を叶えたので、社内Redmine導入が捗る。 ありがとう View customize plugin! https://t.co/BAJh8tEWKl"

ViewCustomizeプラグインのメリットは、他に、Redmineの再起動が不要な点だ。
また、画面UIの修正だけのプラグインをどんどん追加していくと、RedmineのVerUPも難しくなる。

つまり、画面UIの挙動を変えたいだけのプラグインを入れるよりも、ViewCustomizeプラグインで解決した方が、Redmineサーバーを再起動するなどの稼働時間を短縮させる必要もない。

ViewCustomizeプラグインが生まれた背景として、「個人が使っている Redmine用のステキなUserScriptをプロジェクト全員に適用できないか? 」という動機があったというのが興味を惹く。

【2】ViewCustomizeプラグインを使いこなせるようになれば、Redmineの画面UIをユーザが自分達の場面ごとに自由にカスタマイズできるようになる。

では、ViewCustomizeプラグインの発想を推し進めると、Redmineはどのように変化するのか?

【2-1】おそらく、RedmineをMVCモデルと捉えた時、RedmineはModel層を中心とした基盤であり、View層やController層はユーザが自由にカスタマイズできるような開発基盤として位置づけられるだろう。
つまり、Redmine自体はマイクロコアであり、画面UIや各機能は、マイクロサービスのように自分達で自由にコンポーネントやサービスを追加できるような開発基盤にできるのではないか。

このアイデアは、Redmineを開発基盤とみなせるのではないか、という考えで以前書いた。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

u6k_yu1さんのツイート: "@u6k_yu1 思うにRedmineてマイクロコア化して構造を安定化して、プラグインで色々実現してくれた方が良いのではないかな。"

akipiiさんのツイート: "Redmine のマイクロコア化はそういう発想か。RT @forenoonM: 以前に「RedmineをMVC構造のModel層としてのみ使って、ViewとControllerを自前で作ってもいいかも」みたいな話を誰かが言っていたような。"

akipiiさんのツイート: "@u6k_yu1 RedmineをEclipseやiDempiereのように、Redmine本体は開発基盤としてVerUpしながらも、追加機能はプラグイン化で対応し、追加機能のプラグインは本体のVerUpに依存しないアーキテクチャが理想なんでしょうね。"

Redmineの裏の顔~開発基盤としてのRedmine: プログラマの思索

その頃のアイデアと違うのは、Redmineが提供する外部接続I/F、たとえば、REST APIやrakeやリポジトリ・メールのWebサービス、とは異なり、ViewCustomizeプラグインがRedmineのView層だけのカスタマイズに特化している点だ。

この特徴は、今後のRedmineの発展に役立つのではないか、と想像する。
なぜなら、Redmineの画面UIは誕生当初から十年近くほとんど変わっていないため、そろそろ現代風なUIに変えたいというユーザの要望が多いので、その実現に役立つのではないか、と思うからだ。

たとえば、JenkinsもVer2で画面UIを一新し、今風のUIで再構築しようとしている。
同様に、Redmineも今後のバージョンでは、もっとリッチで使いやすいUIにできるはず。

JenkinsのUXをモダンにする新プロジェクト「Blue Ocean」登場。統一的デザインのためのJenkins Design Language(JDL)も開発中 - Publickey

その時に、ViewCustomizeプラグインのような発想で、基盤としては核(コア)となる画面UIの骨格をCSSやJS、Railsのフック処理として作る。
ユーザは、基盤として提供されたView層の核(コア)はいじらず、核が提供する骨格をAPIとして認識して、画面UIを自分達の現場に合わせてカスタマイズすればいい。

つまり、ViewCustomizeプラグインは、Redmineの画面UIをカスタマイズする一つのマイクロサービスとして捉えれば良い。

【2-2】この発想をさらに推し進めると、どうなるか?
おそらく、Redmineの画面UIだけでなく、Redmineの各機能も開発基盤の核を提供して、ユーザが自由にカスタマイズできるように、マイクロサービス化できればなお良い。

実際、RubyやRailsはフック処理に別の処理を挿入する黒魔術のメタプログラミングが得意なのだから、Redmine自体がマイクロコアという開発基盤を提供できればよい。

そして、ViewCustomizeプラグインと同様に、Redmineを再起動しなくても、機能を自由に追加できればよい。

【2-3】では、Redmineのマイクロサービスはどのように実現できるのか?

一つのアイデアは、ViewCustomizeプラグインと同様に、Redmineの設定画面上にスクリプトを書いて実行できるようにすることだろう。

たとえば、Redmineのワークフロー管理機能に分岐やロジックを追加するプラグインredmine_custom_workflows: プログラマの思索のようなプラグインで既に実現できている。

Custom Workflows - Plugins - Redmine

anteo/redmine_custom_workflows: Allows to create custom workflows for Redmine

custom_workflowsプラグインもなかなか面白い。
ワークフローの中で、分岐や特定の処理を入れることができるのだ。
たとえば、「完了ステータス時に、進捗率を100%にして、期日に更新した日を設定する」という処理は、redmine_issue_completionプラグインで実現できるが、custom_workflowsプラグインでも同様に簡単に実現できる。

Redmineチケットの完了時に進捗率と期日を自動更新するプラグインredmine_issue_completion: プログラマの思索

他にも、稟議トラッカーでは、経費カスタムフィールドの値が20万円以上なら、部長承認が必要だが、20万円以下なら部長承認は不要、などの分岐条件も簡単にスクリプトをcustom_workflowsプラグイン上に設定できる。

このような発想を推し進めれば、他の機能も同様に、ユーザが設定画面でスクリプトを書く方法で修正可能になるはず。

【2-4】さらに、ViewCustomizeプラグインやcustom_workflowsプラグインでいくつかの独自スクリプトを設定した場合、それら独自スクリプトをXML出力したり、XMLをインポートするような機能があれば良いかなと思う。

つまり、画面UIカスマイズやワークフローカスタマイズの独自スクリプトは、DBに保存するだけでなく、XMLで保存できたり、インポートできる機能を設けることで、それら設定情報(XML)をシステム移行やデータ移行で流用したり、他の会社でも使えるようなベストプラクティスのテンプレートとして流用したいのだ。

【2-5】但し、ViewCustomizeプラグインやcustom_workflowsプラグインのデメリットもあるだろう。
デメリットとしては、カスタマイズされるソースがプラグインのDBに埋め込まれているため、プログラム単体ではどの機能がカスタマイズされたのか分かりにくいことだ。
特に、システム移行やVerUp作業時に、これらプラグインでカスタマイズした内容も考慮に入れておく必要があるだろう。

【3】とはいえ、Redmineを開発基盤として捉え直し、ちょっとした機能追加はViewCustomizeプラグインやcustom_workflowsプラグインで対応する方法は、マイクロサービスやマイクロコアという最近のアーキテクチャ設計の流れに対応しているように思える。

この辺りのアイデアも色々考えてみる。

| | コメント (0)

2016/08/03

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説

第15回RxTStudy勉強会で、「大規模組織や多様な業務におけるRedmineの課題」を講演してきた。
話し足りなかったことをラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

Redmineを運用している規模について - Google グループ

Redmineの運用が大規模化していく上での課題~@Will_meaningさんとのやり取り - Togetterまとめ

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

【1】今の自分のテーマとして、「Redmineが組織構造に与える良い影響は何か、そして、どうやってそれを引き出すのか」「組織構造がRedmineを従属させるとしたら、どんな影響が出るのか」がある。

過去8年以上、数多くの現場でRedmineを導入してきた。
その経験を振り返ると、Redmineを導入して、チームが活性化して上手くいった現場もあれば、期待通りの効果が得られず、Redmineが廃れていった現場もある。
その違いは何なのか、を考えると、その現場にある組織構造とそれに由来する組織文化が大きな要因ではないか、と気づいた。

組織文化が重要、と言うのは誰でも分かる。
でも、その組織文化を生み出した組織構造は、会社ごとに非常に異なる。
その部分を経験を元に整理してみたのが、上記の資料。

【2】一般に、会社という組織は、機能別組織・事業部制組織・PJ型組織・マトリクス型組織の4つに分類される。
どの業界のどの会社も、どこかに当てはまる。

【2-1】SIで多いのは、事業部制組織だ。
たとえば、パッケージ製品の事業部、受託開発専門の事業部、発注元の業界別の事業部などのように、採算単位に組織が分かれている。

事業部制組織の特徴は、分権型組織でありながら、かなり集権的な組織であることだ。
事業部長が事実上、中小企業のオーナーに近い独裁権限を持ち、事業部の売上・コストに最終責任を持ち、事業部内の事業ボートフォリオの決定に大きな影響をふるう。

SIの事業部制組織では、マネージャ、プロジェクトリーダー、プログラマ、デザイナー、インフラ担当者など全てのリソースが揃っているので、自分たちで自由にやり繰りできる。
しかし、その中の業務は標準化できず、一人の担当者が複数の仕事を掛け持ちして忙しすぎて、逆に作業効率が悪くなっている場合が多いように思う。

【2-2】一方、メーカーや古い体質の企業で多いのは、機能別組織だ。
たとえば、営業部、生産計画部、製造部、品質保証部などのように、一つの製品を計画・製造・出荷するプロセスを複数の部署が縦割りに分割する。

機能別組織の特徴は、人の専門化、業務の標準化によって、業務の効率化を重視した集権型組織であることだ。
いわゆる「範囲の経済」「規模の経済」を活かした組織構造になる。
すると、縦割り組織なので、その部署内で業務は局所最適化されるが、会社全体としては、横のつながりが非常に悪いので、全体最適になっていない場合が非常に多いと思う。

【2-3】機能別組織では、横のつながりが悪いので、Redmineを導入すると、Redmineプロジェクト上であたかも、複数部署の担当者が一つの有機的チームを形成するような雰囲気が出てくる。
たとえば、チケットのやり取りでペア作業したり、ノウハウをチケットやWikiに集約したり、自分たちで自発的にチケットを起票したり棚卸しするようになってくる。

つまり、Redmineが公式の機能別組織とは別に、PJ型組織という非公式な組織構造を擬似的に実現して、組織を再活性化してくれるメリットがあるのだ。

一方、事業部制組織は、内部である程度自由があり、その雰囲気が好きであれば仕事しやすい。
でも、作業の効率化ができていないので、Redmineを導入してみるのは有効だろう。
特に、Redmineでチケット駆動開発を実践すれば、アジャイル開発の運用がスムーズにいく。

また、パッケージ製品の派生開発や、組み込みソフトウェアのプロダクトライン開発では、Redmineの親子プロジェクト機能を使って、似たような案件だがタスクは別管理したい時にRedmineが有効に使える。
たとえば、コア基盤の親プロジェクトに、派生開発の子プロジェクトや、顧客向けにカスタマイズしたシステムの子プロジェクトを配置することで、リアルタイムにチケット管理しやすくなる。

つまり、Redmineが公式の事業部制組織とは別に、マトリクス型組織という非公式な構造を擬似的に表現して、作業の効率化をRedmineがサポートしてくれるのだ。

【2-4】一般に、昨今のように、ビジネスの不確実性が高まる状況では、従来の機能別組織や事業部制組織といった「規模の経済」の論理で作られた組織構造では、柔軟性がないことが既に指摘されている。
すなわち、たくさんの人員を、ヒエラルキーに基づいた中央集権的な組織で管理することは向いていないのだ。
むしろ、PJ型組織やマトリクス型組織、タスクフォース、スクラムチームといった柔軟でフラットな組織形態が望ましい、とよく言われる。

その傾向によって、Redmineの利用場面が多くなってきたのではないか、と思う。

【3】そんな経験を整理すると、RedmineはPJ型組織やマトリクス型組織に有効ではないか、という仮説が思いつく。

【3-1】PJ型組織やマトリクス型組織の特徴は不確実性が非常に高い状況で有用な組織であることだから、不安定で不確実性が高い状況では、Redmineが有効ではないか、という仮説に至る。

その理由は、本来、Redmineは障害管理ツールから発展したツールなので、突発的に発生した障害やタスクを簡単に登録し、更新し、作業状況をリアルタイムに管理できる特徴を持つからだろう。

【3-2】また、Redmine本来の設計思想では、1プロジェクト=1リポジトリの前提がある。
ver1.xの頃は、マルチリポジトリ機能がなかったので、Redmineプロジェクトに対し、SVNやGitリポジトリを1個しか設定できなかった。
逆に言えば、Conwayの法則に従うように、1個のシステムは1個の案件だけに対応付けるべき、アーキテクチャ(システム)は組織・管理上の単位に従わせるべき、という発想だったのだろう。

この特徴は、RedmineプロジェクトがPJ型組織と本来調和していることにつながっているのだろう。

【3-3】さらに、Redmineの生誕当時から複数プロジェクト機能を持っていた特徴により、マトリクス型組織にも向いている特徴が自然に出てきたのだろう。
たとえば、派生開発やプロダクトライン開発のように、ある製品の作業が、そこから派生した製品の作業に影響するが、開発要員のスケジュールの違いやリリース日の違いによって、別々に管理したい場合がある。

そんな時に、Redmineプロジェクトを親子関係で分ければ、子プロジェクトごとに作業を別々に管理し、親プロジェクトで子プロジェクトのチケットも含めた全てのチケットを集計することで、一括で進捗管理できるようになる。

その場合、チケットのコピー機能やチケットの関連機能が重要になってくるだろう。
理由は、派生先のチケットに対し、派生元のチケットからコピーしたり、派生元チケットに関連付けることで、派生先チケットがどこから発生したのか、が分かりやすくなるからだ。
つまり、一つのインシデントに対し、関連するシステムの影響範囲をチケットで表現した場合、チケットのコピーや関連チケット機能で実現できることを意味している。

たとえば、Apacheの不具合パッチをリリースするインシデントが発生した場合、影響する他システムにも同様のチケットをコピーないし関連付けるが、システムごとにリリース日が異なるから、別々に管理することができるようになる。

この運用が徹底できれば、作業後の品質管理で、インシデントのインパクト分析に役立てることもできるだろう。

【3-4】他にもRedmineの特徴として、ペア作業、構成管理ツールと連動したトレーサビリティ、小規模リリースを実現するタイムボックス開発、等がある。
これらのプラクティスも取り入れれば、より一層の効果が出るはず。

【3-5】しかし、組織がRedmineに悪影響を与える時もある。
複雑な組織構造がRedmineの設定にモロに反映されると、運用プロセスが複雑になりがち。

よくある例は、ステータスやロールが多くなり、その結果、ワークフローが複雑になり、トラッカーが増えてしまうことだ。
組織をまたぐ時に、誰がボールを持っているか、を明確にするためにステータスが必要になるので、縦割り組織が多いほど、ステータスは多くなる。

また、組織のロールをそのままRedmineに反映すると、ロールの数もロールの設定箇所も増える。
特に、社内だけでなく、外部のベンダーが絡むと、チケットや成果物のアクセス権限を制御する必要があるため、ロールを増やして、アクセス権限を制限する必要が出てくるからだ。

【4】そんなことを考えると、Redmineに向いた組織構造や組織文化は、「PJ型組織」「マトリクス型組織」のような不確実性の高い状況の組織に向く、と言えるのではないか。
逆に言えば、不確実性の高い状況で作業せざるを得ない組織では、Redmineを積極的に導入してみてはどうか、と推薦することもできるかもしれない。

組み込みソフトウェア開発のように、本来はメーカーの開発スタイルであるWF型開発が中心である組織であっても、派生開発やプロダクトライン開発に取り組まざるをえない状況では、Redmineが適している部分があり、Redmineの特徴を上手く引き出せれば、有機的なチームの雰囲気や文化を作り出すことができるはず。

その辺りの事例も集めてみたいし、ノウハウも整理してみたい。

逆に、複雑な組織構造はRedmineの設定を複雑にする。
Redmineが複雑な設定になってしまうパターンも整理してみたい。

| | コメント (0)

2016/07/31

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想

JAXAのRedmine利用事例に関する講演会が無事に終了。
多数の参加者の皆さんも満足できたと思います。
スタッフとしても、講演者と参加者の方に感謝です。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

JAXAのRedmineモデル~Redmineはレイヤ構造になっている: プログラマの思索

第65回 SEA関西プロセス分科会&RxTStudy15 「チケット管理システムによるプロセス支援と今後の課題」 #RxTStudy - 日々の御伽噺

【1】JAXA様のRedmine利用事例の講演では、実際の画面の一部も見せてもらうことができて、JAXAの運用ルールが非常に理解できた。
JAXAの動機としては、マネージャの観点では、経営層に、投資対効果のメリットをアピールするために、Redmineでデータを収集して、定量データを報告したい、ということがあったらしい。

だから、カスタムフィールドを増やして、カスタムフィールドで集計しやすくする運用は必須だった。
しかし、ワークフローを複雑にしたくなかったので、トラッカーとロールを増やさないようにしたかった。
そこで、ロール設定のORルールやカスタムフィールドのANDルールを生み出した、と。

僕の疑問は、カスタムフィールドを増やしたがるのはマネージャの観点であり、入力項目が多いと億劫になりがち。
そのようなデメリットはないかと思ったが、JAXAの回答としては、過去のお手製BTSでは、入力項目がテキストボックスでデータの揺らぎがあり、集計しづらかった。
だから、Redmineのカスタムフィールドで入力項目の書式を定型化して、集計しやすくするルールは必須だった。

また、カスタムフィールドのANDルールによって、各プロジェクトごとにカスタムフィールドのON/OFFを制御しているので、ユーザにとっては必要なカスタムフィールドしか表示されていないので、あまり気にならないメリットもあると理解できた。

【2】パネルディスカッションでは、ISO9001やIT内部統制をRedmineで実現して、実際にコストを削減できるか、という点も質問してみた。
ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア: プログラマの思索にも書いたけれど、日本のメーカーではISO9001の導入は必須の会社が多い。
しかし、ISO9001のプロセスが重荷になり、逆にコスト増になっているのではないか、という現状が多いのではないか。

JAXAの回答では、ISO9001をRedmineで運用するのはうまく回っている。
ISO9001は指針をしめしているだけであり、QMSの実装は現場ごとに実現して良い。
ISO9001やQMSの目的を十分に理解できていれば、その手段をRedmineで実現してもいいし、実際にそれで運用を上手く回す事ができる、と。
逆に、そんな質問は、ISO9001の目的と手段を取り違えて運用しているのではないか、という指摘を頂いた笑。

僕の感触としては、RedmineでISO9001で運用する場合の課題は、チケットの全文検索と、証憑などのエビデンスというOfficeファイルのファイル検索にあると思っている。
監査の時に、必要な情報をRedmineの全文検索からチケットを抽出できるか、その証憑となるExcelファイルを共有ファイルサーバーから取り出せるのか。

JAXAの方や@akahane92さんの話を聞くと、Redmineチケットに情報を集約し、チケットの関連付けや構成管理ツールのリポジトリ連携によって、トレーサビリティは実現できるし、検索もできる。
また、JAXAの運用では、DMSFプラグインを入れることで、ファイル検索と必要な情報の分類もできている、とのこと。
たしかに、DMSFプラグインでその課題はクリアしているわけだ。

【3】僕の発表資料「大規模組織や多様な業務におけるRedmineの課題」では、僕が理解しているJAXAの運用ルールの紹介と、組織構造がRedmineに与える影響事例としてPJ分割ルールについて話してみた。
JAXA運用ルールの噛み砕いた紹介は、参考になったという声があって、良かった。
また、機能別組織・事業部制組織・PJ型組織・マトリクス型組織という4つの組織構造に対し、Redmineが有効に使える部分の提示、そして、Redmineプロジェクトと組織構造の関連の説明も、一部の人にとっては、すごく参考になった、という声も聞いて、作った甲斐があった。

個人的には、組織構造がプロセスやツールに影響を大きく与えているのは確かだし、日本では、自社の組織構造や組織のルールに、プロセスやツールを従わせるようにしたい欲求が強い。
そういう状況において、Redmineの機能の柔軟さ、豊富さがメリットになっている部分を感じている。

【4】他の資料はコチラ。

| | コメント (0)

2016/07/23

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。
チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。

【参考】
golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log

Big Sky :: コマンドラインからredmineを扱える「godmine」作った。

【1】(引用開始)
SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします.

面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....etcです.

実装担当者はRedmineを使う運用で問題なかったりするのですが,役職持ちの方から「Redmineはわからないから」とか「移動中にExcelで見たいから」などと言われると断れないのがサラリーマンの辛いところです.

あとは受託だとユーザとか元請にRedmineを強要できないので結局Excelになったりします.(しません?)
(引用終了)

【2】Redmineのようなチケット管理ツールを、開発チームがボトムアップで使っているのではなく、上司や経営者が上から目線で導入させたとしよう。
すると、Redmineは確かに現場に導入されるが、現場ではRedmineが必要で導入したわけではないから、なかなか根付かない。

逆に、Redmineが普及して、会社の上司や経営者もPJ状況を見て欲しい、と思ったとしよう。
しかし、部課長や社長クラスの人は、管理作業や営業などで忙しすぎるので、Redmineをわざわざ触って、見る暇もない。
むしろ、メールで報告させたり、Excelを送ってもらって、印刷したプリントで見た方が楽だったりする。

すると、上司や経営者から、Redmineを見るのは面倒なので、メールで報告してくれ、とか、ExcelでPJ状況を出してくれ、と言われたりする。
そのための進捗報告書を作成するのに、プロジェクトリーダーは無駄な工数がかかったりする。
せっかくのRedmineが、上司や経営者の目には届かないのだ。

【3】その状況は、営業支援システムの事例でも聞いたことがある。

営業マンが顧客にアポを取ったり、契約状況を記録するために、営業支援システムを作り、営業担当者に日報を書かせて、上長がその日報を読んで管理できるような素敵なシステムを開発した。

しかし、営業部の課長クラスは、自身も営業しているし、打合せも多いので、営業支援システムにわざわざログインして、大人数の営業担当者の日報を毎日読む暇もない。
すると、営業担当者にとっては、日報入力という無駄な作業が増えているのに、その日報を上司が少しも読まないし、反応もない、と分かると、誰も営業支援システムを使わなくなった、と。

結局、メールやExcelベースの情報連携に戻ってしまった、という事例。

他にも、ERPに蓄積された財務情報やPJ情報を経営者向けに見える化したい、という情報系システムを多額の資金を投資しして開発したものの、経営者はそんなにシステムに明るくないし、システムの操作も最初から覚えるのは面倒なので、結局使われない。
すると、大金をはたいた、経営情報の見える化システムも使われなくなってしまう、という話もよく聞く。

【4】結局、会社の上司や経営者が、情報系システムを使いこなさなければ、現場に定着しない、という身も蓋もない話。
経営者向けの情報系システムは、大金をはたいた割りには、使用頻度が低く、誰も使わないシステムになりやすい。

いくらBIツールでビジュアルに見える化したとしても、彼らはそもそも情報系システムを使いこなそうという動機はさらさらないのだ。
個人的には、古い頭の日本の大企業に多い症状のような気がする。

そんなことをふりかえると、「見える化」という言葉は経営者は大好きだが、実際に使いこなせていない場合がすごく多い。
むしろ、現場主導で、自分たちの現場がやりやすいように、使いこなした方が賢明だ。
無駄なメトリクスの抽出、見える化プログラムの実装は、不要だと思う。

| | コメント (0)

«有効な併買ルールを見つけ出すバスケット分析のアルゴリズムのリンク