« 2017年3月 | トップページ | 2017年5月 »

2017年4月

2017/04/28

第12回東京Redmine勉強会の見所

来たる5月の第12回東京Redmine勉強会の見所をメモ。

【参考】
第12回勉強会 - redmine.tokyo

redmine.tokyo 第12回勉強会 - connpass

【1】今回のテーマは『みんなでRedmineプラクティスをシェアしよう』。

最近、IT業界にかぎらず、メーカーなどの他の業界でも、Redmineという言葉を聞く機会が多くなってきた。
チケット管理の適用シーンが増えていて、そのメリットを感じられる利用シーンも増えているのだろう。

そこで、Redmineの導入や運用の観点と、Redmineを支える技術面の観点の二つから、Redmineの利用事例を紹介できることになった。

【2】Redmineの導入や運用の観点では、まず、@Madowindaheadさんの「Redmineを活用したプロジェクトマネジメント技術向上について」がある。
@Madowindaheadさんは、PMOの立場として、プロジェクト管理の標準化や運用推進を担当されているとのことで、Redmineをベースにしたプロジェクト管理の社内説明会を過去2年以上実施されている、とのこと。
社内でRedmineの利用を推進して展開していくためのノウハウや、落とし穴に関するお話が聞けることを楽しみにしている。

過去のRedmine勉強会の参加者からも、社内でRedmineを使ってもらうにはどうすればいいか、という初歩的な質問も多い。
だから、Redmineを実際に導入したものの、全社的に展開していくためにはどんな手順やノウハウが必要なのか、という観点で聞けば、参考になるものが多いのではないか、と期待している。
3月のRedmine大阪のLT資料がダイジェスト版らしいので、参考にしたらと思う。

Redmineを活用したプロジェクトマネジメント教育について(ダイジェスト版)

【3】次に、宮本 陽一さん の「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」の講演がある。

「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

JDMF2016講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になる: プログラマの思索

ソフトウェア開発における派生開発やプロダクトライン開発にRedmineが有効に使えるのではないか、というアイデアについては、僕も過去に色々考えてきた。
たぶん、同じように感じている人達も多いと思う。

派生開発やプロダクトライン開発については、昔から沢山の人が開発プロセスは考えられてきたけれど、そのプロセスの実装が非常に煩雑、という問題があると思う。
その問題点は、複数の開発ブランチを並行開発できる構成管理と、要件からソース修正に至るまでのトレーサビリティの2点をいかにプロセスとして実装するか、という点で置き換えられると思う。

つまり、その2つの問題点は、Redmineの構成管理ツール連携と、チケット管理のトレーサビリティというRedmineの特徴を活かせば、たぶん解決できるはず、と直感している。

また、派生開発やプロダクトライン開発の別の観点では、複数の組織をまたがったプロジェクト管理をどのようにプロセスとして実装すべきか、という問題もある。
たとえば、複数の製品開発チームとコア基盤の開発チームがいかにスムーズに連携しながら、並行開発しながら、順次リリースしていくべきか。
たぶん、たとえアジャイル開発であったとしても、そのプロセスの実装はそう簡単ではないはずだ。

なぜなら、派生開発やプロダクトライン開発では、マトリクス型組織になりやすいため、ワンマンツーボスシステムの組織になりがちで、メンバーの観点では二人のボスの指揮命令系統に従わざるを得ず、混乱しがちだから。

この問題点に対しても、Redmineの複数プロジェクト機能を組織構造と上手く対応付ければ、運用するプロセスの実装はかなり楽になるはずだ、と直感する。

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

すなわち、Redmineの柔軟な機能を上手くプロセスと組み合わせれば、プロセスの運用ルールをガチガチに固めなくても、自然に運用できるような雰囲気を作れるだろう、と直感している。
そういうことを考えながら、講演を聞いてみたいと思う。

【3】次に、須藤功平(@ktou)さんの「GroongaでRedmineを高速全文検索」の講演がある。
Redmineの全部検索を高速化するプラグインを実装公開されているので、利用者の観点でお話して頂く予定。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

下記でも書いたけれど、Redmineのようなナレッジを蓄積するシステムでは、全文検索機能は他のシステム以上に重要な機能であると考える。
なぜなら、チケットやWikiにどんどん過去の作業の経緯や技術情報が記録されて蓄積されたとしても、その内容を即座に検索できなければ、過去の知見を有効活用できないからだ。
たとえば、3年前の障害に関連する情報を全文検索しようとして、3分以上も待たされたら、正直使いものにならない。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

よって、このRedmineの全部検索プラグインは、Redmineをナレッジシステムとして有効活用するために、またそう感じることで利用ユーザのモチベーションを高めるためにも重要な機能であると思う。

また、@ktouさんは、Rubyコミッタの方でもある。
そして、Ruby本家もバグ管理をRedmineで運用されている。
色々お話が聞けるのでは、と楽しみにしている。

kou (Kouhei Sutou) - Ruby Issue Tracking System

OOエンジニアの輪! ~ 第 39 回 須藤 功平さんの巻 ~ | オブジェクトの広場

Rubyist Magazine - Rubyist Hotlinks 【第 36 回】 須藤功平さん

【4】その他にも、@g_maedaさんの講演やLT7本もあるので、盛りだくさん過ぎるほどだ。
参加者も既に定員オーバーで、静かに盛り上がっている。
当日の勉強会が盛り上がるのを楽しみにしている。

【追記】@ktouさん、@Madowindaheadさんの資料が既に公開されている。

| | コメント (0)

2017/04/13

Redmineを帳票ワークフローツールとして強化するstatus_buttonプラグインが面白い

Redmineでステータスに応じた担当者を自動設定するstatus_buttonプラグインなるものがあると知ったので、メモ。
稟議書申請・承認のような事務処理ワークフローで役立ちそうで面白い。

【参考】
QA #312: Redmineの画面上で、編集操作を行わずにステータスを変更+ステータスに応じた担当者自動設定 - Unofficial Redmine Cooking - redmine.tokyo

Status Button - Plugins - Redmine

fanzai0403/status_button: redmine plugin status_button

(引用開始)
Status Button プラグインで対応可能です。

・ステータス変更はボタン押すだけ(特に承認者)
・権限外のステータス変更は実行不可(標準のWF操作と同じ)
・次の担当者は最初にまとめて設定できる。(起票者が設定しておく)
(引用終了)

以前、Redmineを稟議書申請・承認のような事務処理ワークフローとして使いたい場合、どんな機能が必要なのか、を考察した時があった。

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

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

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

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

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

Redmineの現状の機能でも、簡易な帳票ワークフローツールとして十分に使える。
しかし、細かな操作性が不足しているので、そこが気になる場合がある。

僕が一番気になる点は、ステータスごとに担当者を絞り込んで表示して欲しい機能が不足している点だ。
課長承認、部長承認、経理承認のようなステータスでは、役職や権限を持つ人は限定されているので、その人達だけが担当者に表示されて欲しいのだ。

この問題は、上記のプラグインで解決できるみたい。
status_buttonプラグインで面白い点は、管理画面であらかじめ、ステータスごとにロールを設定する点だ。

つまり、課長・部長・経理のようなロールをあらかじめ作っておき、status_buttonプラグインの管理画面で、課長承認、部長承認、経理承認のようなステータスに各ロールを割り当てておく。
そうすれば、各PJでロールを人別に設定できるので、ステータス遷移できるロールの人だけ、承認操作ができる。
次のステータスは誰か、逐一考えながら設定する必要はない。

また、status_buttonプラグインでは、完了までの全ステータスが表示されているので、今後、どのようなワークフローを経由するのか一覧できて便利だ。

このような機能がRedmineに取り込まれたら、事務処理ワークフローとしてRedmineはほぼ使えるレベルになるだろうと思う。

Redmineが面白いのは、Redmineのデフォルト機能で、タスク管理以外のありとあらゆる雑務をWeb化して一括管理できる可能性を秘めている点だ。
業務改善というBPRの観点で、Redmine導入や運用を考えてみると、さらに面白いかもしれない。

| | コメント (0)

2017/04/03

チケット管理システムは作業の構成管理と同じ

Redmineのようなチケット管理システムは「作業の構成管理」という機能を提供しているのではないか、というアイデアをメモ。
ラフなメモ書き。

【1】2000年頃に「達人プログラマー」という黒本を買った。
当時は一流のプログラマになるためのバイブル本だった。

その中の一節に「ソースコード管理システムは、ソースのUnDo機能を提供するシステムである」という文言があり、すごく印象に残った時があった。

実際のプログラミングでは、自分の思考内容をソースコードに表すが、最初から一番良いソースが書けるわけではない。
試行錯誤しながら、ロジックを切り貼りしたり、分割したり、いじくったりする。
すると、その履歴を残したくなる。
途中で、テキストエディタでUndoやRedoするように、ソースコードも過去に遡ったり、途中のソースに戻りたくなるからだ。

つまり、ソースコード管理システムは「プロジェクトレベルでのタイムマシンというべき一つの巨大なUnDoキー」なのだ。

特に、昨今は、GitHubやGitを使っていると、masterとは別に、ブランチ上で新しい機能を実験しやすくなった。
また、たくさんのブランチを派生させても、あるタイミングでマージするためにプルリクエストを送ればいい。

【2】チケット管理システムがないプロジェクトで、作業管理を見ていると、作業の履歴やUnDo、ReDoが欲しくなる時がある。
ISO9001のQMSの運用を行なっている現場で、そんな状況を見た時がある。

ISO9001の品質管理マネジメントシステムでは、全ての作業は記録として残さなければならない。
普通は、作業依頼書のようなExcel帳票に、作業発生から作業終了までの履歴を記録する。

しかし、普通は作業依頼書だけでは話は終わらない。
Excel帳票としては、作業依頼書と、仕様変更の設計書やリリース手順書のような作業手順書とペアが必要になる。
実際の細かな仕様、詳細なリリース手順は、作業依頼書には書ききれないからだ。

それら2個のExcel帳票を、作業状況ごとに管理する必要があるが、これが結構面倒だ。
普通は、作業中のステータスで滞留しがちで、なかなか終了しにくい。
依頼する人と作業する人は別々なので、作業連携がすごく悪いからだ。
今、どの作業ステータスにあるのか、最新状態が反映できていない。

この問題の原因は、作業のステータス管理ができていない点にある。
それは、Excelの作業依頼書には判子欄があるが、それはRedmineのチケットのステータスと同じだ。
Redmineでやれば、すぐに解決できる。

また、Excel帳票の版管理で、依頼する人と作業する人が混乱する場合もある。

依頼する人は設計書を用意するが、割り込みの要望や考慮漏れで設計書を書き直したりする。
すると、どの設計書が最新版なのか、作業する人は混乱しがち。

この問題の原因は、設計書の版管理、つまり設計書のバージョン管理ができていない点にある。
結局、Excelの設計書もSVNやGitでバージョン管理すべき対象なのだ。

Excel帳票で作業依頼書と設計書をやり取りしているISO9001の運用では、プロジェクト数が増えるほど、混乱しがちになる。

【3】そんな状況を見ると、Redmineのようなチケット管理システムは、設計書のバージョン管理と同じように、作業のバージョン管理を提供しているように思える。

設計書のバージョン管理が必要な理由は、設計書の最新版がどれなのか、を明確にする必要があるからだ。
リポジトリを見れば、タグ付けされた設計書が作業対象だ。
設計書の履歴は、リポジトリのリビジョン履歴を見ればいい。

同様に、作業依頼がチケットとして発行されれば、チケットのログに全ての作業履歴が記録される。
作業中に課題が発生したり、設計者と実装手段を議論したり、間違った実装を障害として把握して直したり、色々あるだろう。
そういう履歴があるからこそ、作業依頼書の内容に記載された「作業」は、過去にいつでもさかのぼれる。

つまり、チケットは「作業内容のタイムマシン」だ。
「昔にさかのぼって、どんな作業が行われたのか、を追跡できる」点がチケット管理システムの最大のメリットだ。
これは「トレーサビリティ」という機能を提供している。

チケット管理システムが持つトレーサビリティは、本番稼動後の派生開発や障害修正で、大きな威力を発揮する。
本番稼動中の汚いソースコードには、過去の障害修正によるパッチの意図がある。
その変更の意図を無視して、ソースを勝手に弄ってはいけない。

また、プログラマは派遣契約で出入りが激しい。
3年前に書いたプログラマがいなくなれば、そのソースコードは、どんな意図で書かれたのか、その仕様はどういう経緯で決まったのか、誰も分からなくなる。
しかし、チケットにその作業履歴が残っていれば、その作業履歴に紐付くソースの変更履歴を辿ることで、パッチの意図を把握することができる。

ソフトウェア構成管理は、ソースコードのバージョン管理だけでは足りない。
作業の構成管理というべきチケット管理システムも必要だ。

IT化されていないISO9001のQMSで、作業依頼書と設計書という2種類のExcel帳票が運用上必要であるという事実は、ISO9001の背後にある構成管理には、成果物のバージョン管理と作業の履歴管理という2種類の構成管理が必要なのだ、という思想が背後にあるように思う。

【追記】以前、岡本さんから、「Gitポケットリファレンス新版」を頂きました。
構成管理の仕組みを理解する上で、Gitが分かれば、過去のバージョン管理ツールも分かるだろうし、チケット管理システムの必要性も見えてくるのではないか。
Gitポケットリファレンス新版」は、Gitを知る上でとても読みやすい本でお勧めです。

| | コメント (0)

« 2017年3月 | トップページ | 2017年5月 »