ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデア

ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデアをラフなメモ書き。

【参考】
ワークフローを利用したＱＭＳ（品質マネジメントシステム）の効果性・効率性の改善

概要 | ISO 9001（品質） | ISO認証 | 日本品質保証機構（JQA）

ISO9001のメリット・デメリットとは？ | ISO取得で成功する。

ISO内部監査（基本編） - ISO内部監査の改善術

【1】製造業なら、どこの会社でもISO9001は導入していて、何らかのQMS(品質マネジメントシステム)が稼働しているだろう。
「ウチは品質管理をきちんとやってます」と標榜するには、客観的な資格みたいなものが必要で、それが世界標準ルールであるISO9001だからだ。

昔の日本の製造業では、手作りで自分たちの品質管理の手順を標準化しており、日本製品の品質向上に一役買っていた。
しかし、ISO9001は1990年代頃から普及し始めて、どこのメーカーもISO9001の取得に躍起になったが、逆に品質管理そのものが悪くなったのではないか、とよく言われる。
どのメーカーの人に聞いても、ISO9001の評判は良くない。
あれは、日本の品質管理を潰すために外国から持ち込まれた黒船みたいなものだ、と聞いたこともある。

なぜISO9001の評判が悪いかというと、間接作業の負荷が高すぎるからだ。
ISO9001監査の季節になると、品質部門だけでなく、監査対象の事業部門も残業や休日出勤が多くなる。

ISO9001では、「是正処置や予防処置がきちんと行われているか」、その証拠を全部記録しなければならないし、その記録をいつでもすぐに取り出せなければならない。
すると、少しでも漏れや紛失がある書類があれば、修正や再作成が必要になるし、全ての書類を最初から最後までチェックし直すのは大変だからだ。

たとえば、ISO9001の監査を通すために、会社の人員の2割以上を使ってやっている所もあるらしい。
たとえば、従業員300人の中小製造業なら、約60人もISO監査に何らかの形で携わって作業しているわけだ。
しかし、ISO9001の監査が通ったからといって、すぐに売上が上がるわけでもないから、無駄な人件費が多くなるだけ。

しかも、製造業のコンサルタントのほとんどは、ISO審査に関係する人が多い。
つまり、製造業の生産部門で実務に携わっている人でも、管理職や役職に上がって現場から離れていくと、ISO審査のような間接作業に力を入れたり、そのノウハウを売ることで、生活していくようになるのだろうと推測する。
ISO審査は製造業にとって嫌なものみたいらしいが、それ無しで業務を回すのも現状は無理らしい。

【2】ISO9001の本来の目的は、品質管理をきちんと行うことだが、実情は、品質管理に関する全ての作業を記録に残し、その記録媒体の品質の維持にかなりのパワーを注力している。
すると、以前ならば、バインダーに挟まった大量の紙媒体で管理するか、大量のExcel帳票で管理するか、の双方で実現しているだろう。
だから、何がどこにあるか、すぐに分からなくなるし、その維持も大変だ。

また、その維持の仕組みは、QMS(品質マネジメントシステム)として会社ごとに作られて運用する方針になっている。
その考え方は、ちょうど、CMMIやPMBOKが汎用的な考え方を定めているだけであり、各企業は実装プロセスを実現してカスタマイズして運用しなさい、と言っている方向性と同じ。
そう、ISO9001は方針や考え方だけ言っているだけであり、その実現方法は何も言っていないので、上手く回すにはかなりのノウハウが必要なのだ。
そのノウハウを知らないメーカーはどこも苦労している。

【3】では、問題の本質はどこにあるのか？
資料「ワークフローを利用したＱＭＳ（品質マネジメントシステム）の効果性・効率性の改善」を参考にすると、いくつかのヒントが得られる。

(引用開始・一部編集)
【問題】
「仕事は文書で行う」「結果を記録に残す」という部分がうまくいかずに紙の量の増大、
それにともなう仕事量の増大と仕事の遅れを招いて、実質的な品質向上やサービス向上に結びついていない。

【解決の方向性】
ワークフロー（業務を情報技術を用いて行うこと、帳票をパソコンネットでまわすこと）を利用してＱＭＳの活動を行う。

【効果】
１．ＱＭＳ活動をスピーディにまわすことによりシステム個々の活動が速く確実に行える。
また、システム向上サイクル（ＰＤＣＡサイクル）のスピードアップができる。

２．記録を電子データとして一元管理することにより情報即時共有化と情報分析支援を容易にし、従業員の能力向上、顧客サービス向上に結びつく。

３．ワークフロー導入時に、もう一度業務の見直しが行われるので業務改善ができる。

【問題の本質】
このような企業の抱える問題点は、ワークフローを用いることにより、ほとんど解決してしまうのである。
ワークフローの世界では帳票がフローに従って瞬時にネットワーク上を流れる。
記録は社内の 1 箇所（メインサーバー）で持てば、社内のどこからでも、あらゆる角度から即時に検索でき利用できるのである。
(引用終了)

つまり、ISO9001の仕組みを実現するQMSを帳票ワークフローシステムと同じであると見なして、ワークフローをきちんと回して改善すれば良い、という方針らしい。
このアイデアをRedmineで実現してみると、Redmineではどこまで解決できるのか？

【4】QMSの業務を洗い出して、Redmineの機能とフィットギャップ分析ができたと仮定しよう。
すると、おそらく「是正処置」「予防処置」のようなトラッカーが作られて、「不適合品発生」「暫定対応」「根本問題抽出」「是正対策完了」「是正指示」「実施」「検証」「承認」「完了」などのステータスが作られるだろう。
そして、サポートデスク・対応者・検証者・承認者などのロールも作られるだろう。

Redmineでは、ロール毎のワークフロー制御をかなり複雑に設定できるので、たぶんうまくマッピングできるだろう。

つまり、RedmineでQMSワークフローを実現することで、一連の作業は可視化される。
すなわち、その作業ステータスや担当者をすぐに判別できるようになり、その進捗状況を管理すればいい。

また、必要な帳票は、Excel媒体をチケットに添付してもいいし、構成管理ツールで履歴管理してもいい。
その場合、チケットと帳票は必ず相互リンクするように運用したらいい。
そうすれば、監査対象となったインシデントに対し、チケットにある作業履歴や帳票を元に、監査報告が簡単にできるようになるだろう。

そして、帳票の入力項目はチケットのカスタムフィールドで実現してもよい。
たとえば、JAXAのRedmine運用の報告書でも「回答期間」「問合せ先」「ISO9001項番」などの項目がチケットに追加されている。

そもそも、品質管理システムとは、実質上、バグ管理システムとほとんど同じ機能だ。
だから、Redmineでなくても、普通の障害管理システム(BTS)をカスタマイズすれば運用できるはず。

実際、少し先進的な製造業は、自前のWebシステムで作って既に運用している。
しかし、技術のキャッチアップや運用の改善に自前のWebシステムが付いていけずに、システム保守にコストがかさんで大変になっている所が多いのではないか？

一方、Redmineは先進的なオープンソースのプロジェクト管理ツールであり、汎用的な帳票ワークフローシステムでもある。
頻繁なVerUpで機能改善も多く、ユーザ数も多く、ネット上の情報も多いので、色んなやり方を試せる利点がある。

【5】では、RedmineでQMSを回す時の課題は何か？
本当に、RedmineでQMSの問題は全て解決できるのか？
いくつか考えられる。

一つ目は、QMSの品質が改善されたという指標は何で見ればよいのか？
資料「ワークフローを利用したＱＭＳ（品質マネジメントシステム）の効果性・効率性の改善」では、下記の記載がある。

(引用開始)
ワークフローは“リードタイムの短縮”という点で企業の大きな武器になる。
そして、今回の事例では、ＱＭＳ個々の業務リードタイムの短縮が事業業績の結果であるクレーム低減や受注獲得に結びついた。
それだけ、“リードタイム”は大切なのである。
(引用終了)

つまり、改善されたという評価指標はリードタイムやサイクルタイムになる。
製造業におけるリードタイムの短縮とは、見積り問合せ～納期回答のリードタイム短縮、受注～出荷までの製造リードタイム短縮のことなので、顧客満足やコスト削減に直結する重要な指標だ。

資料「ワークフローを利用したＱＭＳ（品質マネジメントシステム）の効果性・効率性の改善」では、下記の記載がある。

(引用開始)
作業　改善前 改善後 短縮効果
不適合品発生～是正指示 １２日 １日 １１日
是正指示～完了 ５３日 ３１日 ２２日
(引用終了)

チケット管理システムではリードタイムやサイクルタイムはどのように定義されるか？
たぶん下記で定義できる。

各チケットのリードタイム＝チケットの登録日(≠開始日)～チケットの完了日(≠期日)までの日数
平均リードタイム＝sum(各チケットのリードタイム)/完了チケット数

各チケットのサイクルタイム＝前ステータスの更新日～後ステータスの更新日までの日数
平均サイクルタイムsum(各チケットのサイクルタイム)/後ステータス更新済みのチケット数

これらの指標を定期的に採取するような仕組みをRedmineの追加機能または外部スクリプトで作成すればいい。
REST APIを使えばすぐに実装可能のはずだ。

これらの指標を時系列にプロットし、リードタイムやサイクルタイムが短縮されるようになれば、今の運用ルールで改善できたことになるだろう。
すると、ある程度までは短縮できるが、それ以上の短縮は難しいという限界地点にたどり着くだろうと思う。

2つ目は、トレーサビリティは、No Ticket No Commitの運用で本当にカバーできるのか？
従来のExcel媒体を全てWeb化できればよいが、エビデンスや画像ファイルはどうしても残る。
また、チケットと相互リンクさせる運用は、各利用者への教育や指導がかなり必要になるだろう。
ITリテラシーが低い人には敷居が高いかもしれない。

三つ目は、監査に必要な資料や情報を即座に検索できるのか？
Excel帳票やチケットに全ての情報が記載されたとしても、即座に必要な情報を検索できるか？

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

Redmineでは、添付ファイルまで全文検索できない。
共有ファイルサーバー上のOffice書類を全文検索できる仕組みが必要になるだろう。
Alfrescoのような別のOSS製品と組合せる必要があるかもしれない。

公演資料公開！「Redmine（課題管理）とAlfresco（文書管理）の連携で、プロジェクトマネジメントを改善することができました」 | Alfresco | oss-comcre

プロジェクト管理を本質から変えるRedmine×Alfresco、オープンソース夢の連携　4-1 | Alfresco | oss-comcre

また、Redmineの全文検索機能は、チケットが20万件以上になると使いにくくなる現状がある。
但し、下記のプラグインを導入すれば、その問題も解決できるだろう。

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

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

おそらく、Redmineそのものの機能改善というよりも、Redmineの外部に必要な別システムを作り、それと連携する方が良いのではないかと思ったりする。

【6】ISO9001を帳票ワークフローシステムと見なしてRedmineで運用してみるアイデアを色々考えてみたけれど、もう少し深くフィットギャップ分析すれば、かなり良いレベルまで実現できるだろうと思う。

課題もいくつか出てくるだろうが、RedmineがOSSでRailsで作られているがゆえに、カスタマイズもしやすいし、その改善ノウハウも得やすいし、Redmineの外部接続I/Fが豊富なおかげで外部システムと連携させることも簡単であるから、かなり解決できるだろうという感触を持っている。

JAXAのRedmine運用に隠れている運用ルール

JAXAのRedmineモデル、JAXAのRedmine運用ルールを読み直しながら、考えたことをメモ。

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

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【1】JAXAのRedmineモデルでは、Redmineの機能は、利用者の物理層とシステム管理者の論理層に分かれていて、細かく分ければ6層になると思う。
それぞれのレイヤの依存関係を紐解いた後、JAXAのRedmine運用ルール「ロールのORルール」「CFのANDルール」が編み出された。

その運用ルールを実施するには、幾つかの前提となる運用ルール、またはRedmineの設定があるのではないか、と考えている。
下記の3つの目的で、隠れている運用ルールを洗い出してみた。

(1)目的：WFの保守負担を減らす
・WFと権限の分離ルール
・ロール単位のWF分割ルール
・ロールのORルール

(2)目的：トラッカーを増やさずに流用する
・CFのANDルール
・業務単位のPJ分割ルール

(3)目的：PJメンバーにロール割当の負担を減らす
・グループ割当ルール

【2】JAXAの運用ルールでは、WFの保守負担を減らすために、あえてロールを増やす。
その場合、あるロールはワークフロー設定だけで権限のチェック無し、他のルールは権限のチェックはあるがワークフローのステータス遷移は無し、と分ける。
これが「WFと権限の分離ルール」。
たとえば、JAXA資料では、「文書係」「管理係」は文書登録やPJ設定の権限は持つが、ワークフロー設定はない。
一方、「承認係」はワークフロー設定はあるが、権限のチェックはない。

さらに、ワークフロー設定ありのロールでは、ステータス遷移の前半と後半を分離して、それぞれのロールを割り当てる。
これが「ロール単位のWF分割ルール」。
たとえば、JAXA資料では、「レギュラー」は「承認前」ステータスまで、「承認係」は「完了」ステータスに更新できる権限を持つ。

これらの前提があって初めて、「ロールのORルール」が意味を持つ。
つまり、複数のロールを組合せることで、プロジェクトリーダーのロール、開発者のロール、リーダーではないがPJ設定を保守できる権限を持つサブリーダー、のようなロールを分けることができる。

このようにあえてロールを増やすように、複雑にワークフロー設定や権限の設定を行う理由は、ワークフロー設定や権限設定の保守の影響範囲を狭めるためだ。
業務が変わったり、増えたりした時に、一部のロールのチェックを付けたり変更するだけで良いようにするためだ。

さらに、PJメンバーにロール割当の負担を減らすために、ユーザグループの単位でロールを一括アサインする。
そうすれば、数多くのユーザのロールを逐一編集する手間もなくなる。

利用シーンとしては、「管理者」「開発者」だけのロールでは不十分で、組織構造に応じた複雑なロールが多い場合、上記のような運用が必要になるだろう。
つまり、組織構造の複雑さが影響している。

【3】トラッカーを増やさないために、JAXAの運用ルール「CFのANDルール」を適用すると、最終的には、１プロジェクトに１個のトラッカーだけを配置するような運用になると思う。

実際、JAXA資料では、「レギュラー」トラッカー１個だけで、複数のカスタムフィールドの組み合わせをPJごとに行い、各PJで業務をチケット管理する。
すなわち、あるPJは是正処置、あるPJは問合せ管理、あるPJは作業支援のように、数多くのPJに分割される。
おそらく、それらのサブPJは、PJの階層化によってまとめられているのだろう。
これが「業務単位のPJ分割ルール」になると思う。

つまり、Redmineトップ画面の右上のPJメニュープルダウンが、トラッカーグループのような機能を持ち、自分の担当業務が階層化されたメニューとなる運用になるはず。
この運用によって、利用者は、各PJを選択するだけで、どの業務にどのトラッカーのチケットをアサインするか、ということを考えなくても良い。

この運用方法は、トラッカーのカスタムフィールドが微妙に違うが、ワークフローは全て同じ業務に対し、プロジェクトごとに業務を割り当てて、業務専用のプロジェクトとしてチケット管理する。
メリットは、トラッカーを増やさなくてよいこと、そして、PJ名が業務名なので区別しやすいことだろう。
デメリットは、PJが数多く作られてしまうことがあろうが、組織や業務の階層化をPJの階層化に当てはめれば、たぶん問題は解消されるだろう。

【4】以上のような運用ルールを考えると、Redmineに対し、多様な業務を複雑な組織階層で対応したい時、上記のような隠れた運用ルールと設定方法が必要になると思う。
したがって、このような複雑な設定を準備するには、事前に、現状の組織構造と業務内容を把握したうえで、Redmineの機能とフィットギャップ分析する作業が必要になるだろう。
その作業はERPの事前パラメータ設定作業と同じような内容になるだろう。

すると、業務ごとにRedmineの設定を登録したい場合、Redmine設定情報をXMLなどのような形式で保存できる仕組みが欲しくなる。
つまり、ロール・権限・ワークフローなどのRedmineの論理層だけの設定情報をXMLで保存しておき、新たなRedmineインスタンスを立ち上げる時は、そのXMLを読み込むだけで、すぐに業務のチケット管理が運用できるようにしたいのだ。

実際、汎用ワークフロー管理システムのパッケージ製品では、ワークフロー設定や組織情報はXMLやCSVなどの形式でインポート・エクスポートできる仕組みがあり、データ移行やバックアップで使われるような機能として提供されている時が多い。
Redmineもそのような機能があれば、たとえば、サポートデスク業務、勤怠管理の業務、課題管理の業務などのように、業務ごとのRedmine設定情報がXMLで提供され、そのXMLを読み込むだけで、すぐにRedmineで業務の運用が開始できるはずだ。

RedmineにはREST APIが既にあるので、論理層の設定情報をXMLやJSONで保持することは可能だし、その設定情報をGitHubで公開すれば、数多くのユーザにもメリットがあるだろう。

Redmineをソフトウェア開発の作業支援だけでなく、汎用的なワークフロー業務システムとして使うためにはどんな機能が必要なのか、改めて考えてみたい。

Redmineを勤怠管理システムで運用するアイデア

Redmineを勤怠管理システムで運用する記事を見かけたのでメモ。
これは面白いし、Redmineの利用可能性をかなり広げてくれそう。

【参考】
Redmineで勤怠連絡をしてみる

【1】こんな問題が提起されている。
派遣先、常駐先で働くメンバーが多い場合、確かにそういうニーズはありそう。

(引用開始)
・体調不良で休む際、常駐先から現場リーダ/営業/上司/上長…など複数人に報告をしなければならない。
・部下の勤怠管理をしなくてはならなかったが、報告がなかったため月末に出勤簿を提出されたときに初めて高稼働だったと気付く。
・日々、勤務時間を記録しなくてはならないが、月末になってあいまいな記憶で出勤簿を作成している。
・勤怠管理システムを導入したいが、多額の費用を払ってまでやる必要性を感じていない…etc

そこで、オープンソースのRedmineを用いて、簡易的な勤怠申請システムを構築してみる。
(引用終了)

【2】トラッカーやステータスの種類が興味深い。

(引用開始)
トラッカーの分類

・残業申請：残業が発生する場合に報告するチケット
・遅刻・早出：始業時間より遅く出社する場合に報告するチケット
・早退・遅出：終業時間より早く退社する場合に報告するチケット
・休日出勤：法定休日に出社する場合に報告するチケット
・休み：午前半休・午後半休・全休など休暇を取得する場合に報告するチケット
・出社退社の記録：出勤時間と退社時間を日々記録していくチケット(報告者用)
(引用終了)

(引用開始)
ワークフローの設定(ステータス)

・申請中：報告者、開発者、管理者
・承認済み(開発者)：開発者、管理者
・承認済み(管理者)：管理者　※終了したチケットに設定
(引用終了)

(引用開始)
トラッカー＝残業申請(例)

標準フィールド：担当者のみ
カスタムフィールド：申請日(カレンダー)、退社(テキスト)

トラッカー＝休み(例)

標準フィールド：担当者のみ
カスタムフィールド：申請日(カレンダー)、休暇種別(リスト)
(引用終了)

Redmineを簡易なワークフローシステムと見なせば、残業・休日出勤・夜間勤務などの申請フローは簡単に乗せることができる。
出勤時刻のような必要な項目は、「hh:mm」のような書式で設定して、カスタムフィールドで追加すればいい。

チケットの削除機能をOFFにしておけば、申請の記録が残り、消去されることもない。
チケットの実績工数を入力する運用も行えば、毎月の労働時間も記録することもできる。

【3】Redmineの運用ルールは下記で行われているらしい。

(引用開始)
例えば、電車遅刻した際に遅延証明書を添付しないと承認できないというルールを作ると、虚偽の遅刻などが減らせる。
常駐先では自社用でインターネットが利用できない場合が殆どだと思われるが、スマートデバイスがあればブラウザやRedmine専用のアプリから勤怠申請を行うことが可能である。

企業の就業規則や労働基準法に則った運用が必要なため、本格的に使用する場合は管理部門の承認が必要である。
まずは小規模組織内でのトライアル利用を推奨する。
(引用終了)

社外に常駐のメンバーが勤怠管理用Redmineにアクセスできる環境を作れば、気軽にRedmine上でコミュニケーションを取ることができる。
また、電車の事故で遅延証明書が必須になったら、iPhoneでカメラ撮影して、その画像をチケットに添付すればいい。

特に、最新バージョンのRedmineを使うべきメリットは、レスポンシブデザインになったので、スマホのようなクライアントでもRedmineのチケット操作がやりやすくなったことだろう。
もちろん、RedminePMのような専用クライアントを使ってもいい。

セキュアなRedmine環境を用意できれば、勤怠管理システムとして有効に使えるのではないか。

【4】では、勤怠管理システムとしてRedmineを使う場合、課題はあるだろうか？
課題があるとすれば、上記の記事の指摘のように、就業規則や労働基準法に即したルールを全て満たしているか、確認する必要があることだろう。

中小企業なら就業規則もそんなに複雑でないから、問題ないかもしれない。
でも、大企業の場合、労働組合が強かったりして、勤怠管理や労働時間の管理にはすごくうるさかったりする。
また、勤怠管理に付属するイレギュラーな運用フローもあるだろう。

たとえば、勤怠管理の業務では、出張申請は普通、特別な運用ルールになっている。
直行・直帰の場合、みなし労働と見なされるので、勤怠管理システムに特別なルールが埋め込まれている可能性がある。
実際、出張旅費規定にも絡むので、社内の経費精算システムとも連動する必要があるかもしれない。

あるいは、勤怠管理の情報と、実際の各プロジェクトで作業した工数を相互チェックして、整合性を取る必要があるかもしれない。
すると、勤怠管理システムと工数管理システムの二つのシステムに、作業時間を二重入力する手間がかかり、より煩雑になってしまう。
しかも、工数管理システムは普通、社内の原価管理システムや会計システムと連動しているだろうから、勤怠管理システムのデータの精度が高くないといけないし、後から改ざんできるようでは困る。
最終的には、勤怠管理システムは、内部統制システムの一部になるから、データの精度や保管に問題ないことを保証しなければならないだろう。

したがって、勤怠管理の月次締めのような機能が必要になるだろう。
その場合、Redmineの運用では、Redmineのバージョンを年月で指定し、前月度のバージョンは当月月初に「ロック」「完了」ステータスに更新して、チケットを更新不可に運用でカバーする必要があるかもしれない。

【5】そんなことを考えると、課題はいくつかあるだろうが、Redmineを勤怠管理システムとして使う運用は、社内の就業規則などのルールと矛盾がなければ上手くいくだろうと思う。

今まで、Redmineの運用パターンとして、ソフトウェア開発以外に、ヘルプデスク管理、工数管理、PC資産管理、事務処理ワークフローなどを収集してきたが、まだまだ他にも使える利用シーンがあるだろうと思う。
それを考えるのが結構面白い。

そんなことを考えると、Redmineは汎用的な帳票ワークフローシステムであり、一昔前にNotesで社内の事務処理ワークフローを実装して、BPRと称して業務を改善していったと主張した歴史とダブるような気がしている。

Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索

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

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

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

組織行動で知られている罠

「世界で最もイノベーティブな組織の作り方」を読みながら、組織行動で知られている罠についてメモ。
主張は特に無し。

【1】有能性の罠(competency trap)

起業家・経営者ファイトクラブ [まぐまぐ！]

BBIQモーニングビジネススクール

コンピテンシー・トラップとは？ : 現場を活かす企業経営

「満足水準を超えた利潤を得て、不満がない状況では、あえて現在よりも優れた戦略や方法を探索する動機づけが失われる」
「当面の事業が成功すればするほど、知の探索をおこたちがりになり、結果として中長期的なイノベーションが停滞するというリスクが企業組織には本質的に内在している」

従来のやり方で成功し続けると、そのやり方に固執して、現在よりも優れた方法を探索しなくなる。
特に、保守的な大企業ほど、創業以来のやり方に固執してしまいがち。

【2】訓練された無能(官僚制の逆機能)

官僚制とは | ビジネススクールならグロービス・マネジメント・スクール

官僚制の意味 - MBA経営辞書 - goo辞書

2/4 官僚制理論と官僚制批判理論その基礎 [社会ニュース] All About

ユニゾンのENSEMBlog : 訓練された無能

「「訓練された無能」とは、あまりに規則などに固執することによって、変化した状況に対応できなくなってしまうことです」
「おかれた状況が変化しているのにもかかわらず、同じ行動パターンを繰り返してしまう 」

保守的な大企業に長くいる人ほど、周囲の環境が変化して以前の常識が通用しなくなっているのに、同じような行動パターンを踏んでいるケースを見かける時がある。

【3】グループシンク（集団浅慮）

集団思考 - Wikipedia

グループ・シンクとは | ビジネススクールならグロービス・マネジメント・スクール

Educate.co.jp | グループシンク（集団浅慮）

なぜこんなに発言しにくい？　－集団浅慮 | GLOBIS 知見録 - 読む

「集団の圧力により、その集団で考えていることが適切かどうかの判断能力が損なわれる状況です」
「特に、集団の凝集性が高い場合や、外部と隔絶している場合、支配的なリーダーが存在する場合などに起きやすい」

特に日本人の一部の集団のように、集団の凝集性が高く、個人の異論を受け入れないような集団では、集団での意思決定が個人の意思決定よりも浅はかになってしまうリスクがある。

【4】リスキーシフト(集団極性化)

リスキーシフト - Wikipedia

基礎演習

意思決定の集団極性化の社会心理学｜経済界

集団極性化：心理学用語集 サイコタム

集団思考のワナ ー リスキーシフト｜レイデル の「心のエラー」と「脳のトラップ」

「組織での意思決定は極端な方向に振れやすい」
「集団極性化現象（グループ・ポーラライゼーション）とも呼ばれる」
「集団浅慮(グループシンク)の結末として、往々にしてリスキーシフトと呼ばれる現象が起こります。これは、グループでの意思決定は、極端な方向に振れやすいという現象です。」
「リスキーシフトは、集団で決めたことが、個人で考えるよりも危険性の高い決定になることをいいます。」

大規模な組織ほど、実は、リスクのある意思決定が行いやすい時がある。
個人の意思決定よりも集団の意思決定の方が極端にぶれやすい。

【5】コーシャスシフト

集団意思決定

集団思考のワナ２ ー コーシャスシフト｜レイデル の「心のエラー」と「脳のトラップ」

いじめ、暴行・・・集団心理が危険な結果を招くわけ [ストレス] All About

2/2 「いじめ」にかかわる集団極性化と傍観者効果
　いじめ、暴行・・・集団心理が危険な結果を招くわけ [ストレス] All About

「リスキーシフトとは真逆で、集団の意思決定が保守的で消極的な方向へ向かうものを言います」
「コーシャスシフトは、集団で決めた決定が、個人で決めるよりも、慎重でより安全志向になることをいいます」
「こうした集団心理の特性をよく理解し、小さな事件が大きな問題へとエスカレートする前に、今起こっている現象をよく検討する必要があります」

コンセンサスに重きをおくほど、ラディカルな企画や意見は、角が取れて、最終的な結論は何も言っていないに等しくなる場合がある。

日本の学校にけるいじめは、集団極性化現象そのものと同じだと思う。
個人では良い人なのに、集団になると、排除する力が大きくなりがち。

【6】バイアスの罠

番外その１４　「バイアス」の罠～人間の判断にはバイアスがかかっている～

選択バイアスの罠

意思決定のバイアス｜おりばーのブログ

「人間の意思決定は気づかないうちにさまざまなバイアスを帯びている」

バイアスの罠を意識しておかないと、他人の意見に左右されやすく、意思決定がぶれやすくなると思う。

【7】我々は、学校、会社、コミュニティという集団に必ず属している。
過去の日本の歴史をたどれば、官僚的な組織になるほど、上記の罠にハマったケースが見受けられるだろう。

また、自分が所属する組織において、「有能性の罠」「訓練された無能」「グループシンク」「リスキーシフト」「コーシャスシフト」の現象なのかな、と思う時もある。
そういう概念を知っているだけでも、落とし穴を避ける事もできるはず。

JAXAのRedmineモデル～Redmineはレイヤ構造になっている

JAXAのRedmine事例報告にあるRedmineモデルを自分なりに理解して書いてみた。
Redmineは綺麗なレイヤ構造になっていると感じた。
ラフなメモ書き。

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

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【1】JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒントの「Figure 8　Redmine の主な定義の構造」を引用して、RedmineのアーキテクチャをVer3.3の機能「Tracker role-based permissions」も含めて描いてみた。

Redmineは、幾つかのレイヤに機能を配置するように分割設計されているのがよく分かる。
※CC Atributionライセンスでダウンロード可能とした。

Jaxaのredmineモデル from akipii Oga

【2】Redmineのレイヤは大きくは2つ(論理層・物理層)、細かく分けると6層に分割できると思う。

物理層は、利用者がRedmineプロジェクトでチケット管理するレイヤ。
論理層は、Redmineシステム管理者が、チケット管理で使われるワークフローやロール、権限制御を行うレイヤ。

【2-1】物理層は、ユーザ層・ロール割当層・PJ定義層に分かれる。
幾つかのポイントがある。

一つ目は、PJメンバーにユーザを割り当てる時に、ロールをアサインするが、その時に「ロールのOR設定ルール」を使うと良い。
つまり、PJメンバーがチケット管理で操作できる権限の範囲はロールで決まるので、複数のロールを組合せることで詳細かつ、MECEに制御できる。
例えば、業務ごとに必要なロールに分割しておき、それら複数のロールを組み合わせて、チケット管理の操作権限の範囲を決めるようにすれば、Redmineのアクセス権限をより厳格に運用できるだろう。
また、新たな権限を登録する場合、ORルールのおかげで修正範囲が共通箇所になるように設定しておけば、保守作業も効率化できる。

二つ目は、PJで使われるチケットのカスタムフィールドは、「カスタムフィールドのAND設定ルール」を用いると良い。
つまり、PJで使われるトラッカーのCFは、PJごとにOn/Offを設定することで、CFの使用可否を制御できる。
例えば、同じトラッカーでも、PJごとに表示されるチケット属性の個数が異なるように設定できる。
この運用ルールを使えば、一つのトラッカーで、複数のカスタムフィールドの表示・非表示を組合せられるので、トラッカーの数を減らすことができる。

Redmineで運用するチームが増えて、業務の種類も増えると、どうしてもトラッカーが増大しがちだが、「カスタムフィールドのAND設定ルール」を用いることで、トラッカーの数に制限をかけることができるだろう。

3つ目は、モジュールや使用トラッカーをPJごとに割当できること。
不使用のモジュールやトラッカーはOFFにして、操作を簡素化できる。
特に、文書やフォーラムの機能を使わないならば、OFFにして、少しでも操作を簡単にした方が運用しやすい。

【2-2】論理層は、チケット定義層・ロール定義層・モジュール定義層に分かれる。

【2-2-1】チケット定義層は、ステータス・ワークフロー・トラッカー・標準フィールド、カスタムフィールドの属性とその関係が設定される。
このレイヤが明確に分離されていて、汎用的に作られている点がRedmineの最大の特徴だろうと思う。
だからこそ、事務処理・問合せ・資産管理などの多様な業務にRedmineを適用できるわけだ。

【2-2-2】ロール定義層は、ロール毎にモジュールやプラグインの権限の制御が設定される。
Ver3.3では、「Tracker role-based permissions」の機能が実現されたので、「ロールと権限」画面の下部に、ロール単位かつトラッカー単位にチケットの参照・登録・編集・削除・コメント追加の権限を細かく設定できるようになった。
この機能は、非常に面白いし、Redmineの運用方法のバリエーションを増やしてくれるだろうと思う。

例えば、事務処理ワークフローでは、Redmineに属するユーザ全員が参照できて、かつ、チケットの新規登録による申請はできるようにしたい。
しかし、その後の承認フローは事務処理PJに属するメンバーだけで回して、チケットを精査するような運用にしたい。
その場合、「Tracker role-based permissions」を使えば、「非メンバー」ロールのユーザは「チケット参照・登録・コメント追加」の権限だけ付与し、それ以外の権限は付与しない運用も考えられる。

あるいは、完了した障害チケットや問合せチケットは、コメント追記のみ権限を許可する、と言った運用も考えられるだろう。

つまり、ロール定義層で、ロール毎にRedmineのチケット操作、モジュール操作の権限を細かく設定することで、現場の業務フローにより近づけることも可能だろう。

【2-2-3】モジュール定義層では、プラグイン情報やチケットトラッキングなどの設定が行える。
チケットトラッキングは、より詳細な設定ができるようになっている。

・異なるプロジェクトのチケット間で関連の設定を許可
・異なるプロジェクトのチケット間の親子関係を許可
・チケットをコピーしたときに関連を設定

上記の設定は、特に製品の並行開発、派生開発、事務処理ワークフローの申請チケット複製で威力を発揮するだろう。
派生元のチケットを元に、関連するシステムの作業を親子チケットにしたり、関連チケットにしたり、複製したりすることが可能になる。
また、事務処理ワークフローでは、過去に使った完了チケットを複製したい時が多いが、「チケットをコピーしたときに関連を設定」が「都度選択」に選択しておけば、不必要な時は「重複する」関連を付けない運用もできる。

・親チケットの値の算出方法

「親チケットの値の算出方法」の設定では「子チケットから算出」にすれば、「WBS100%ルール」を当てはめられるし、「子チケットから独立」を選んでおけば、「WBS100%ルール」が適用されない。
特にWF型開発でWBSを詳細化して、かなり深い階層で作った場合に、「WBS100%ルール」を当てはめたくない時に使える。
「親チケットの値の算出方法」の設定を「子チケットから算出」にしておくと、親チケットに記入した当初の予定情報が、子チケットを登録したタイミングで消えてしまうリスクを無くすことができるからだ。

・進捗率の算出方法

「チケットのフィールドを使用」ではなく「チケットのステータスに連動」へ設定しておけば、「90％進捗シンドローム」「停滞したチケット」にはまることなく、明確な進捗管理ができるようになる。

【2-3】このように見ると、利用者はプロジェクト定義層の機能を主に使うが、その設定情報の保守は、論理層で行われている。
その論理層はシステム管理者が、業務に応じてRedmineのパラメータを色んなバリエーションで設定しているわけだ。

おそらく今まで適用しにくかった業務にも、Redmineを当てはめることができる可能性が出てくるだろう。

【3】Redmineの初期設定は、ERPのパラメータ設定に似ている。
この設定方法を上手く使えば、多様な業務のワークフローを実現できる。

すると、業務ごとに、Redmineの設定を保存できないか？という思いが出てくる。
例えば、設定情報をXMLで出力し、後でインポート可能にしたいのだ。
つまり、事務処理、問合せ、資産管理などの業務ごとにPJ初期設定情報を保存し、Redmineインスタンスごとにインポートすることができれば、業務ごとのRedmineテンプレートを配布する事もできるだろう。

実際、ワークフロー管理のパッケージ製品などでは、ワークフロー単位に初期設定情報を出力したりインポートする機能が普通は付いている。
設定情報はXMLであり、複雑な機能はJarなどのコンポーネントを登録することもできたりする。
その機能があるおかげで、データ移行やシステム移行がすごく楽になる。

同様に、Redmineでも、業務ごとにPJ設定情報をXMLで出力したり、インポートできれば、データ移行が楽になるかもしれない。

【4】このようにRedmineはきれいにレイヤ化されているメリットは何か？
機能が明確にレイヤ化されていることで、機能追加やカスタマイズがやりやすくなるメリットがある。

Redmineは誕生して10年経ったが、機能拡張が漸進的に行うことができた理由の一つは、機能を明確にレイヤ化された設計が当初からなされていたことではないだろうか。
そして、そのような設計思想を、JAXA担当者の方のモデルを見て初めて知ったことを思うと、JPLは、そんな設計思想を最初から持っていたのだろうと推測する。

@sakaba37さんにそんなことを話してみたら、JPLはヨーロッパ人なので、アメリカ人よりも、ソフトウェアアーキテクチャに対して美的意識が強いのでしょう、と聞いた。
なるほど、そうなのかな、と思ったりする。

実際、JPLは自動テストコードのカバレッジにすごくこだわっているから、ソフトウェアの品質にも美的意識が強いのだろうと推測する。

Redmine build status
Redmine code coverage

JPLに一度、Redmineの設計思想を聞いてみたい気がする。

【追記】
的確な意見があったのでリンクしておく。

yojikさんのツイート: "ここで言われてる論理層、物理層という言葉、アナリシスパターンにおける知識レベル、操作レベルですな。 (パターンが忘れ去られることによって用語の統一が失われる問題) / “JAXAのRedmineモデル～Redmineはレイヤ構造…” https://t.co/hMhFCnp2WF"

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

Redmineへの機能改善の要望への対処、保守コスト増に対する対処について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。

【1】下記2点について考えてみる。

2)機能改善の要望への対処
3)保守コスト増に対する対処

大規模組織におけるRedmineを巡る諸問題～組織構造がRedmineに与える影響: プログラマの思索

【2】Redmineの機能改善の要望は、ガントチャートとメトリクス集計が多い。
普通、マネージャやPMO、品質保証の立場の人から、下記の要望がよく出る。

ガントチャートでWBSをExcelやMSProjectのように綺麗に表示したい。
ガントチャートをもっと分かりやすく表示できないか。

毎月の部長向け報告で、各案件の作業実績、障害件数、QA件数をサマリで報告したい。
Redmineにある情報を一発で上手く取得できないか？

個人的には、都度対応している。

【2-1】ガントチャートはパッチで対応している。
ガントチャートの日付表示パッチ(但し、Ver3.2からデフォルト機能なので不要)、ガントチャートの左欄の枠の幅を広げるパッチを直接ソースにパッチを当てたりする。

vividtone/redmine_gantt_with_date: replace cweek with day on the gannt chart.

Redmineでガントチャートの幅を広げるパッチ: プログラマの思索

他にも、ガントチャートの左欄の枠に担当者を表示したい、ガントチャート画面上で編集したい、などたくさんの要望もある。
このレベルになると、パッチ当ては不可能。
既に有償プラグインがいくつか公開されているので、プラグインを入れる方が早いし、安定するだろう。

Redmine Lychee Enterpriseシリーズの解剖part1～Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

Redmine本家にも以前から、ガントチャート上の編集機能の要望チケットはあるので、いつかは取り込んで欲しい。

Feature #2024: gantt chart editing - Redmine

【2-2】メトリクス集計は、二つやり方があると思う。
一つは、サーバーサイドで、REST APIを使ったスクリプトで集計処理を行うこと。

松谷さんのやり方のように、Redmineサーバー上でREST APIでチケット情報を取得、集計するシェルスクリプトを買いて、gnuplotでビジュアルに表示するやり方が上手いと思う。
サーバーでCSVを出力できれば、gnuplotで色んなグラフで描画できるし、外部サーバーのBIツールにCSVを食わせてビジュアル表示させることもできる。

Redmineでメトリクスを見える化する方法

Mattani/MetricsTools_for_Redmine: Perl and gnuplot scripts for calculating Metrics for Redmine

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

RedmineのチケットデータをRedmine外部のBIツールで表現するアイデア: プログラマの思索

もう一つは、全チケットをCSV出力して、Excelマクロで加工すること。

プロジェクトリーダーは、自分の管理作業を楽にするために、自作のExcelマクロを持っている人が多い。
例えば、ガントチャートを表示したり、EVMを出力したり、工数管理する集計マクロを持っている。
そういうツールを持っているから、彼らはプロジェクト管理を効率化するノウハウを自分なりに蓄積しているのだ。
特に、週次・月次レベルで、障害件数やタスクの消化率を報告する場合が多いので、Excel上でvlookupを使ったり、ピボット集計する場合が多い。

すると、彼らに元ネタとなるCSVを渡せば、好きなようにいくらでも集計してくれる。
そのような運用でカバーした方が早いと思うし、Redmineシステム管理者の保守の作業負荷も下がると思う。

【2-3】つまり、メトリクス集計のような機能は、Redmineの外部で実装した方がいいと思う。
その方が、Redmine本体のVerUp、Redmineの性能悪化などの影響を受けにくいからだ。
たとえば、RedmineのチケットデータをCSVで出力し、外部のBIツールに食わせて、ビジュアルに表示させる方法も一つの手段として実現できる。

しかも、RedmineのREST APIでデータをやり取りするように、Redmineとメトリクス集計機能を疎結合な設計にしておけば、カスタマイズもやりやすいはずだ。

【3】他に、Redmineの保守コストが大きくなっている、という指摘も多い。

【3-1】実際、一つのチームで10人以下でRedmineを運用しているなら、保守コストは、一つの案件の管理作業の中に含められるだろう。
しかし、Redmineを長く使っていくと、普通のWebサーバーの保守作業が必要になってくる。
例えば、バックアップ、リストア、VerUp、移行作業など。

なお、バックアップ作業は下記が参考になる。

Redmineなど汎用的に使えるバックアップ処理（shellscript+cron+rsync） - Qiita

Redmineのバックアップ処理: プログラマの思索

特に、VerUp作業のコスト増が大きな問題になってくるだろう。
なぜなら、Redmine本体のVerUpが頻繁にあるものの、プラグインを入れているとそう簡単にVerUpできなくなるからだ。
本当は、VerUPによって、数多くの機能改善がなされているから、その恩恵を受けたいのに。

また、VerUp作業を行うには、Redmine自体を一時的に停止する必要が出てくる。
すると、Redmineが開発業務の基幹系システムと同じような重要性になってしまった場合、そう簡単にサービスを停止することも出来ない。

Redmine以外にも、RubyやRailsのVerUpも激しいために、RedmineのVerUpはそれなりに難しいかもしれない。

【3-2】Redmineの保守コストが大きいと感じられてくると、Redmineの保守作業を専門化するチームを設けたり、外部に委託したくなってくる。
その時に、Redmineを捨てて、他のパッケージ製品に切り替える判断も出てくるだろう。

BacklogやJiraの製品では、Redmineからの移行ツールも用意しているみたい。

「JIRA Redmine Importer」プラグインで Redmine からインポート - Atlassian Japan

Backlogへの移行ツール作るためにScalaとAkkaを使ったら便利すぎた！ - ヌーラボ [Nulab Inc.]

【3-3】Redmineがこれらのパッケージ製品よりも保守作業が楽である、という特徴を出すには、何が必要なのか？

RedmineのVerUp作業を楽にするには、昨今の継続的デリバリに関するノウハウを生かして、「ブルーグリーン・デプロイメント」「Immutable Infrastructure」の仕組みを導入するとか、色々あるだろうと思う。

継続的デプロイ＆ダウンタイムなしのデプロイのために - Qiita

DevOps時代の開発者のための構成管理入門（終）：継続的デリバリ／デプロイを実現する手法・ツールまとめ (2/2) - ＠IT

【4】メトリクス集計の機能追加、保守作業の効率化などを考えると、Redmine本体を一つのマイクロコアないし開発基盤として独立させて、カスタマイズしたい機能はRedmineの外部で実装できるような仕組みが必要ではないか、と思う。
つまり、Redmineを開発基盤にして、追加機能は着脱可能コンポーネントにしてしまいたいのだ。

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

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

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

Redmine本体を一つの開発基盤を見なす考え方は、以前発表したことがあったけど、もう少し深く考えてみたい。
Redmineを電源コンセントやUSBポートみたいに、簡単にプラグインを抜き差しできるような仕組みとして考えてみたいのだ。

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

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine～Redmineをカスタマイズするポイント」　#47redmine: プログラマの思索

大規模組織におけるRedmineを巡る諸問題～組織構造がRedmineに与える影響

大規模組織におけるRedmineを巡る諸問題について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。

【1】最近は、Redmineに組織構造がどのように影響して、Redmineのプロセスや運用ルールが変形されるか、という問題意識を持っている。
下記3点について考えてみる。

1)Redmineプロジェクトに組織構造が出てくる点

但し、下記2点は後回し。

2)機能改善の要望への対処
3)保守コスト増に対する対処

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

【2】最近は、Redmineプロジェクトはシステム単位に作るべきなのか、組織単位で作るべきなのか、という問題を改めて感じている。

以前から、Redmineの複数プロジェクト機能のおかげで、製品の並行開発や製品の派生開発がやりやすい特徴があった。
しかし、大人数のユーザで使用し始めると、組織構造の影響がモロにRedmineに出てきて、逆に運用ルールが複雑化しがち。
特に、Redmineでは、プロジェクトツリーをいくらでも深く作れるので、Redmineプロジェクトをその時々の判断で作ってしまいがちだ。

そもそも、Redmineプロジェクトはどの基準で作るべきなのか？

【2-1】本来のRedmineの設計思想を振り返ると、Redmineプロジェクトはリポジトリと1対1に対応すべき、と考えられる。
Ver1.4までは、Redmineプロジェクトにリポジトリを1個しか追加できなかった。
その後、複数のリポジトリを追加できるようになり、GitもSVNも複数のSCMリポジトリも登録可能になったので、その設計思想があやふやになったけれど、たぶん変わっていない。

すると、その設計思想では、Redmineプロジェクトはシステム(ビルドモジュール)単位になる。
実際、ソフトウェア開発案件のタスク管理では、システム単位にプロジェクトを作る場合が多い。

さらに、その設計思想では、Redmineプロジェクトのライフサイクルは、SCMリポジトリが新規登録されて、システムが廃棄される期間と一致する。
すなわち、Redmineプロジェクトはシステムの生存期間と同期するので、Redmineは特定の期限を持つ案件の管理に向く。

【2-2】逆に、Redmineプロジェクトを組織と対応付ける運用はやりにくい。
組織内にはたくさんの案件があり、作業の種類も多いので、一つのRedmineプロジェクトでチケット管理すると、すぐに発散する。
かと言って、小さくプロジェクト分割しても、組織のメンバーの入れ替わりも激しかったりするので、放置されやすい。
僕の経験では、Redmineプロジェクトを組織に対応付けた場合は、上手くいった経験があまりない。

【2-3】この発想を突き進めると、Redmineでタスク管理を行うと、開発チームはプロジェクト型組織になりやすい。
つまり、開発チームのメンバーは、別々の組織のメンバーであったとしても、Redmine上では、あたかも一つの有機的なチームとして活動する雰囲気になる。
これは、Redmineが組織に与える「良い影響」だ。

たとえば、業務系Webシステムの開発がメインのSIならば、一つの事業部内では、インフラチーム・アプリチーム・デザイナーチームのように機能別組織に分かれている場合が多い。
インフラ・アプリ・デザイナー担当者に要求されるスキルや技術は全く違うからだ。
(と言っても、最近のWeb開発では、アプリ担当者がインフラもデザインも全て担当するようになってきているが)

そして、実際の受託開発案件では、案件ごとにインフラ・アプリ・デザイナーの担当者が一つのチームを形成するようにアサインされて、作業を開始する。
Webサーバーの構築、画面のモックやデザイン配置、実際の業務ロジックの実装など、それぞれの役割分担で、作業しなければならない。
すると、各担当者は、その組織に応じた考え方や、特有のスキルに応じた考え方を持っているために、別組織の担当者と衝突しやすい。
インフラ・アプリ・デザイナーは機能別組織に所属しているから、そう簡単に融合できないのが普通だろう。

しかし、Redmine上では、一つの作業チケットを複数人のメンバーがやり取りして、完了まで持っていく。
そういうチケットのやり取りを何度も消化していくうちに、各担当者のコミュニケーションが生まれ、各担当者同士でお互いの背景や考え方の認識のズレに気付き、協調して、一つの作業を完了していく。

つまり、Redmine上では、自分の組織の役割を主張し合って衝突するよりも、チケットのやり取りを通じて、あたかもペア作業のような雰囲気が生まれて、一つの有機的なチームが形成されやすい。
Redmineではアジャイル開発のプラクティスを適用しやすかった、という僕の経験は、おそらくそのような構造があったからだろうと思う。

【2-4】しかし、Redmineの運用対象はプロジェクト型組織が向いているからと言って、いつも、サイロ型組織の悪習を打破できるわけではない。

実際、Redmineプロジェクトをシステム単位ではなく、組織単位に作ってしまう場面もたくさん見てきた。
「工程単位のプロジェクト」はRedmineの一つのアンチパターンと僕は思っているが、そのような作り方をやりたい時もある。

例えば、ある大規模な受託開発案件で、製造フェーズのみ外注のオフショアベンダーに発注したとする。
すると、設計・結合テストは国内チーム、製造フェーズはオフショアベンダーのように、工程ごとに組織が分断される。

すると、Redmineプロジェクトは、設計・製造・結合テストのように工程ごとのプロジェクトに分割したくなる。
実際、1個のRedmineプロジェクトで管理したとしても、前工程のチケットが交じると作業しにくいからだ。

また、障害チケットを発行する時、その障害の発生工程がどこであるか、を記入する事が重要になるが、それが当たり前の時、記入するのも面倒だ。
特に、オフショアベンダーから納品後のプログラムをテストして障害が出た時、その障害チケットは、他工程の障害チケットと明確に分けて、目立つようにしたい。
なぜなら、障害修正の責任は国内チームではなく、オフショアベンダーにあるので、そのコストをベンダーに押し付けたいからだ。
たいていの場合、オフショアベンダーの仕様の理解が甘かったり、国内チームの設計が甘いという色んな理由で、ベンダー納品のプログラムの障害は多発しがち。

すると、単純なトラッカー名「障害」ではなく、「障害(ベンダー名)」とか「障害(結合テスト)」のようなトラッカーを作ってしまいがちだ。
トラッカー名を他の名前と変えて、大きく目立たせるようにしたいから、そのような運用になってしまう。
つまり、トラッカーやワークフローも増加してしまい、より複雑になりがち。

また、そんな雰囲気になると、Redmine上では、障害修正やその対応に関するQAのやり取りで、メンバー全員が疲弊してしまう雰囲気になる。
Redmineがプロジェクト型組織を促し、メンバー同士のコミュニケーションを活性化させて、有機的なチームを形成するような影響も出てこない。

【2-5】いろんな事例を見てくると、Redmineプロジェクトがシステム(機能)単位なのか、組織単位なのか、という観点は、下記の基準で評価できると思う。

Redmineプロジェクトをシステム単位に設定したい時は、メンバーが地理的にも組織的にも分散せずに、一つのチームで固まっている場合だ。

Redmineプロジェクトを組織単位に設定したい時は、工程単位に国内チームとベンダー、オフショアチームのように、地理的にも組織的にも分割されている場合だ。

そのように考えると、ソフトウェアアーキテクチャだけでなく、開発プロセスも組織構造に大きく影響を受けてしまう事実がよく分かる。
まさに、コンウェイの経験則の正しさがRedmineでも感じられるのだ。

Redmineを会議室予約システムにしてしまうredmine_meeting_room_calendarプラグイン

@endo_5501さんのつぶやきで、Redmineを会議室予約システムにしてしまうredmine_meeting_room_calendarプラグインを見つけたのでメモ。
これはすごく役立ちそうで面白い。

【参考】
dro123/redmine_meeting_room_calendar: Qburst's meeting room plugin for redmine

えんどー5501さんのツイート: "この会議室予約プラグイン、なかなかよい感じ。EXCELよりずっと良いのでは。試してみよう / “GitHub - dro123/redmine_meeting_room_calendar: Qburst's meeting ro…” https://t.co/Cd27mgx1v3"

詳細は、GitHubの説明を読めばいい。
画面キャプチャがふんだんに使われているので、すごくイメージできる。

仕組みとしては、
・トラッカー＝「Meeting」
・カスタムフィールド＝「Room」(部屋をリスト形式)
・カスタムフィールド＝「Start time」「End time」(開始・終了時刻をリスト形式)

を事前に作り、プラグイン設定画面で幾つかの初期設定を行い、必要なロール(参照・編集権限)やワークフローを設定する。
Redmineのカレンダー画面をカスタマイズしているのか、カレンダーではなく、1日の時間帯別に会議室を予約・解除できるような画面が用意されている。

画面キャプチャを見る限り、一昔前にNotesで作られた会議室予約システムに似ている気がする。
こういうツールがRedmineで手軽に実現できるのはすごく面白い。

惜しむらくは今はja.ymlがないので、ja.ymlを自分で作れば簡単に日本語化も可能だ。

個人的に最近思うのは、ソフトウェア開発とは全く関係ない事務処理ワークフローやPC資産管理、蔵書管理などの業務にRedmineを適用したい場合、別のRedmineインスタンスを立てた方が良いのではないか、と思っている。
理由は、Redmineプロジェクトのライフサイクルが全く違うし、トラッカーやステータスなどのワークフローも全く別物だからだ。

1個のRedmineにソフトウェア開発の業務と事務処理などの庶務的な業務も全て詰め込むと、ソフトウェア開発はプロジェクト型案件なので一定期間だけ使われる場合が多いのに対し、庶務的な業務は会社が続く限り、ほぼ永遠に使われるので、Redmineプロジェクトの寿命が全く違うからだ。
また、ステータス名やカスタムフィールド名も全く違うし、トラッカー名も全く異なるので、そもそも分けた方が運用しやすいのではないか。

もし、複数のRedmineを相互リンクさせたい時は、リンク型カスタムフィールドを使えばいいだろうと思う。

Redmineのリンク型カスタムフィールドの使い方: プログラマの思索

Feature #1358: Link_to for Custom Field - Redmine

プロセスフロー図をRedmineチケットで表現するアイデア～Lychee Association Chartで実現できるか

@u6k_yu1さんのつぶやきから、プロセスフロー図をRedmineチケットで表現するアイデアを得たのでメモ。
以下は、まとまりのないメモ書き。

【参考1】
PFD(プロセスフローダイアグラム)で開発プロセスを設計する: プログラマの思索

PFDによる開発プロセスのモデリング - 千里霧中

Association Chart | Lychee Redmine

プロセスフロー図(PFD)作成アドインについて

【参考2】
u6k_yu1さんのツイート: "ゴールの成果物から逆順に作業・成果物を算出して、プロセスフロー図を作成する。 →図の作業を親チケット、成果物を子チケットとしてRedmineチケットを発行する。 →成果物とそれを必要とする作業にチケット関連を設定する。 →成果物に成果物定義をなるべく細かく書く。 →"

u6k_yu1さんのツイート: "@u6k_yu1 →動かせないマイルストーンを起点に、各作業の期間を設定する。 という手順で、作業チケット、成果物チケットを発行している。難点は、 ・期間設定をガントチャートで直接操作したいけど、プラグインが必要。 ・Redmineでプロセスフロー図を直接描きたい。"

u6k_yu1さんのツイート: "@u6k_yu1 うーん、やはりプロセスフロー図の作業、成果物とRedmineチケットを直接関連付けたいなぁ。"

akipiiさんのツイート: "@u6k_yu1 Lychee Association Chartが近いかな。プロセスフロー図は書けないけど。Graphvizを使ってスクリプトにするか。"

【1】PFD(プロセスフローダイヤグラム)はXDDP提唱者の清水吉男さんが編み出したもので、開発プロセスを一瞥するのにすごく良い。
プロセスと成果物を紐付けて、プロジェクトの開始から終了まで、一連の作業を図示できる。

たとえば、複数の成果物(例：テーブル設計書、画面設計書)がなければ、プログラミングできない、とか、一連の作業のボトルネックを把握するのに役立つ。
あるいは、結合テスト前までに、検証用環境を構築しておく必要があるとか、検証用環境を構築するために事前にパッケージ製品を購入して事前に検証しておく作業が必要とか、色んな作業をあぶり出すのに使う。

しかし、普通の案件では、WBSを作成して、それで終わりという所が多い。
スケジュール管理はWBSを洗い出したら終わりという気はしない。
むしろ、プロセスと成果物の一連のイメージがWBSでは湧きづらい。
だから、WBSだけ見ても、何が遅れて問題になっているのか分かりにくい。

WBSという無味乾燥なExcelの表形式の内容を、もっとビジュアルに表現して、何がボトルネックになりやすいか、をイメージしたいのだ。

【2】Redmineでは、WBSをチケットに置き換えることで、階層化されたガントチャートを自動表示できる。
つまり、WBSをチケットで一度表現してしまえば、ガントチャートだけでなく、色んなビューで表現できる可能性がRedmineにはある。
実際、WBSがチケットで一度登録できれば、EVMやリソースヒストグラム、PERT図でも表現することは理論上可能だ。

その発想をPFDにも適用して、Redmine上でPFDを表現できないか？

【3】たぶん、PFDのイメージに近いプラグインは有償ではあるが、Lychee Association Chartが近いだろうと思う。

Lychee Association Chartでは、チケットの親子関係や先行・後続の関連チケットを1枚の図に表してくれる。
つまり、PFDにおけるプロセスの先行・後続関係は、Redmineチケットの先行・後続関係に対応付けできる。

また、Lychee Association Chartでは、チケットとリビジョンを紐付けた関係も図示してくれる。
つまり、チケットにコミットされたソースやドキュメントが自動で紐づくので、チケットを成果物に対応付ければ良い。

すなわち、PFDにおけるプロセスの流れは、Redmine上で、チケットの先行後続関係、プロセスと成果物の関係は親子チケットと構成管理ツール連携で実現できるはずだ。

【3-1】Lychee Association Chartを使っている事例を読むと、作業と成果物の漏れがないか、点検するのに使っているようだ。

住友電装株式会社様における業務プロセスの見える化 | Lychee Redmine

もし、PFDがRedmineチケットで実現できるならば、計画したプロセス(＝チケット)に対して、実績としての成果物(＝SCMリビジョン)が紐付いていなければ、成果物が作られていないか、成果物の完了報告が漏れていることが考えられる。
そうであれば、品質保証部のチェックが入るまでに、Lychee Association Chartで出力した図を元に開発チーム自身でチェックできるし、そうすることで成果物の漏れを無くしたり、品質向上に役立つ可能性がある。

つまり、PFDのメリットである「開発プロセスを設計する」「設計された開発プロセスを検証する」という発想をRedmine上で実現しているわけだ。

【4】しかし、PFDをRedmineチケットで実現する場合、生のRedmineの機能では操作しづらいだろう。

チケットの先行後続関係、チケットの親子関係が複数レイヤになった場合、チケット一覧画面で、親チケットの番号を入力するとか、先行するチケットの番号を入力するなどの操作は非常に面倒だろう。
できれば、ガントチャート画面上でチケットの先行後続関係を簡単に操作したい。

Lychee Association Chartならば、操作方法についてはいくらか解決できるだろう。

【4-1】しかし、さらに、PFDを階層化したい場合、Redmine上で上記のやり方を一貫して行えるか？

たとえば、大規模受託開発案件の場合、複数のサブシステム単位に設計書が必要だし、他のサブシステムの設計書ができてから自分たちのサブシステムの設計書が作れる、というような依存関係もあるだろう。
あるいは、1個の画面を作るために、複数の成果物が必要だったり、その成果物を階層化したい時もあるかもしれない。

すると、PFDで表すプロセスフローは非常に複雑になるだろう。
チケットの枚数もかなり多くなるし、それらチケットを手作業で関連付ける事自体がかなりの手間だ。
また、先行後続で関連付けられたチケットを階層化する場合の運用ルールや考え方も事前に決めておく必要があるだろう。

たとえば、先行後続関係は親チケット同士に限る、とか、成果物チケットは必ず最下層の子チケットに配置する、などの運用ルールが必要になるだろう。
たぶん、チケットの枚数は数百～数千枚程度まで膨れ上がるかもしれない。
その場合に、PFDで表した数百枚、数千枚のチケットをRedmine上でそもそも保守できるのか、という疑問もある。
Lychee Association Chartを使ったとしても、PFDを実際に使ったノウハウがなければ、きれいに運用するのは難しいのかもしれない。

【4-2】とは言え、PFDをRedmineチケットで表現するアイデアは、色んな可能性を秘めていると思う。

プロセスと成果物の一連の関係をチケットで表現してしまえば、ガントチャートで進捗管理できるし、リソースヒストグラムでメンバーの作業負荷をチェックできるし、EVMでプロジェクトの採算や完了時点の最終コストを予測することもできる。
また、プロセスと成果物の関係は本来、PERT図で表現できるものだから、XDDPのプロセスフローダイアグラム(PFD)に置き換えることは理論上簡単なはずだ。

つまり、チケット集計による様々なビューを実現することによって、プロジェクトリーダーは、案件の状況を色んな角度から分析できるはず。

特に、日本ではXDDPの手法は一部でよく知られており、組込みソフトウェア開発における派生開発で既に実績もかなりある。
また、Redmineは元来、複数プロジェクト機能のおかげで派生開発の進捗管理もしやすい。
つまり、複数の製品開発(ソフトウェアプロダクトライン)や製品の派生開発のプロジェクト管理は、元々、Redmineに向いている部分がある。

したがって、そのXDDPの手法の一つであるPFDをRedmine上で実現できれば、成果物の漏れを無くすように開発プロセスの品質を強化できるし、派生開発のプロジェクト管理をより楽にできるように運用できる可能性があるはず。

色々考えてみる。

RedmineのGitリポジトリはmirrorオプションで同期するメモ

Redmineサーバーに外部のGitリポジトリを同期させる設定についてメモ。
自分が知っている情報が古かったので、少しハマった。

【参考】
リポジトリ ? Redmine Guide 日本語訳

RedmineRepositories - Redmine

github のリポジトリを redmine の入っているサーバーにミラーリングする | T.T.Soft Code Blog

redmineとgithubの連携 - katashiyo515's diary

RedmineのGitリポジトリ設定は、bareリポジトリしか認識しない。
だから、「git clone --bare」でGitリポジトリをクローンしていた。
すると、ブランチ削除の内容が同期されないみたい。

Redmine.JPのリポジトリ設定の説明ページを読むと、Gitリポジトリ設定の箇所の最後に、mirrorオプションの説明が載っていた。
(見落としていた！)

＃Gitリポジトリをmirrorオプションで同期する
cd /var/redmine/git_repositories
git clone --mirror git://github.com/ook/donebox.git donebox.git
↓
＃ブランチ確認
cd donebox.git
git branch

branch
* master

masterブランチだけで運用をする場合、bareでcloneをすればほとんどの場合で対応できる。
しかし、厳密にブランチ管理を行う場合、リモートリポジトリを追跡させる必要がある（bareでは追跡できない）ので、mirrorオプションが必要になるのではないかと思われる。
ちょっとハマった。

Gitのmirrorオプションの説明は下記を参照。

Git の mirror 関連のオプションや設定 - Qiita

GitHubのGitリポジトリを同期するなら、redmine_github_hookプラグインを使えばいい。
GitHubのPushを検知して、Redmineサーバーに同期してくれる。

koppen/redmine_github_hook

社内のGitサーバーと同期する場合、hookシェルを書くか、Cronで同期するか、どちらの方法がある。
Cronなら、下記の手順を参考にすればいい。

自前のredmineで外部のgitリポジトリを追加してcrontabで更新する - Qiita

リポジトリ ? Redmine Guide 日本語訳

7/30土の第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいこと #redmine

7/30土に開催される第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいことをメモ。
ラフなメモ書き。

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

(引用開始)
7/30に第65回 SEA関西プロセス分科会＆第15回 RxTstudy 「チケット管理システムによるプロセス支援と今後の課題」を開催します。
今回の勉強会のメインセッションは、JAXA様の担当者の方にRedmine運用の事例報告を講演して頂きます。

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

JAXA様のRedmine運用事例報告を読むと、発注業務以外にISO9001も見据えた運用フローの標準化、ならびに、大規模な組織や多様な業務に対応できるようにRedmineの機能を十分に評価検証したことがよく分かります。
JAXA様の事例講演を次回も聞くチャンスはそうありませんので、ご興味のある方は是非ご参加下さい。
(引用終了)

【1】最近、Redmineの運用をいろんな場所で展開している時に思う問題意識は、二つある。
一つは、大規模な組織形態や多様な業務に対して、一つのRedmineインスタンスでカバーするには、Redmineにはどんな機能が必要で、どんな運用ルールが必要なのか。

もう一つは、組織構造とRedmineの相互関係を整理したいこと。
つまり、複雑な組織構造がRedmineやその運用プロセスにどんな影響を与えてしまうのか、ならびに、Redmineの導入と運用によって従来の硬直した組織の雰囲気を打破できる可能性はあるのか、を事例とその背後にある経験則を編み出したいこと。

【2】第10回東京Redmine勉強会のディスカッションで偶然聞いたグループでは、「闇Redmine」という言葉が出ていた。
つまり、一つのRedmineインスタンスでは他種類の部署の運用、多様な業務に耐え切れないので、自分たちのチームだけにこっそりとRedmineインスタンスを作り、自分たちのチームのソフトウェア開発プロセスの管理に使っている。

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

ツール主導ではなく、自分たちのプロジェクトで成果を出すためにツールを使うのだから、このやり方はおかしくはない。
しかし、自分たちのチームで上手くいったRedmineを隣のチーム、自分の部署のすべてのチーム、他の部署へ展開していくと、Redmineはどんどん複雑化していく。
特に、ワークフローやカスタムフィールドは、野放しに複雑に設定してしまいがちだ。

また、自分たちのチームのプロセスが、保守案件や問合せ管理、事務処理ワークフロー、サーバー資産管理、購入機器の管理などの多様な業務をカバーできるとは限らない。
むしろ、一つのRedmineですべての業務をカバーする方が無理があるのかもしれない。

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

【2-1】JAXA様のRedmine運用事例では、こういう運用の複雑さに対する解決策として、「ロールのOR設定ルール」「カスタムフィールドのAND設定ルール」を提唱されている。
このやり方は、ERPのパラメータ設定のノウハウに似ている気がする。
少ないパラメータ設定で、多様な業務、多様な要件に対応するために必要な運用ルールなのだ。

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【2-2】以前のRedmineでは、ロール単位のアクセス権限の機能が弱いと言われていたが、随分改善されてきた。
Ver3.3では、トラッカーごとにチケット編集・参照の権限を付与する機能が追加される。

akipiiさんのツイート: "これは便利！RT @g_maeda: Redmine 3.3.0に入るのが確定。 ? Feature #285: Tracker role-based permissioning https://t.co/vImWQN2OZy https://t.co/CwSfqamCc2"

Feature #285: Tracker role-based permissioning - Redmine

アクセス権限管理の強化は、Redmineがエンタープライズ分野で利用されるに従って、重要なテーマになるだろうと思う。

【2-4】個人的には、@akahane92さんの思いと同じく、Redmineの機能をベースに、多様な業務に適応するための「ITSガイドライン」のようなものが作れるといいなと思う。
つまり、Redmineというプロジェクト管理用ERPのパラメータ設定の汎用的なノウハウをまとめてみたい。

「ロール設定のORルール」と「フィールド設定のANDルール」はもちろんその中に入るし、他にもたくさんあるはずだ。

akipiiさんのツイート: "面白そう。RT @akahane92: redmine 等のITSのトラッカー設計について、みんなどうしてるのかな。「ITSトラッカー設計ガイドライン」があればいいな。RxTstudyの参加者がトラッカーを持ち寄って、少人数グループで議論して持ち寄ると作れるかな。広く役立ちそう。"

Kuniharu AKAHANEさんのツイート: "@akipii 直感的で有効なステータス名、トラッカーとの組み合わせ、興味深いです。／背景と要求（例: 利用・運営者の組織文化、ITSによる問題解決の対象領域, 等）によるふれ幅がどの程度あるのか。／ケーススタディーの対象にしたとき、参考となるどのようなケースを引き出せるのか。"

neta＠とんこつしかたべないさんのツイート: "@akahane92 @akipii いいですね！ウチはほとんど『依頼』、『課題』ですが、『課題』からそのまま解決のための『依頼』になってるチケットも多く、分ける必要なかったと思ってます。"

一つのRedmineインスタンスで、大規模組織でも多様な業務にも耐えれるような運用ルールを策定できれば、Redmineの利用範囲はもっと広がるだろうと思う。

【3】「組織構造とRedmineの相互関係」については、最近色々感じるものがある。

【3-1】従来から経験していることは、トラッカーやステータスは、そのチームの文化、その組織の文化が色濃く反映されることだ。

例えば、オフショア開発チームとRedmineでやり取りしていた時、「課題」トラッカーは使いにくく「QA」トラッカーの方が使いやすい、と言われた時があった。
ワークフローは同じなのに、トラッカー名が変わるだけで、メンバーのモチベーションもかなり上がった。

逆に、障害トラッカーで「リリース済」「対応済」ステータスを使っていたら、そのステータスにアサインされた担当者は何をすれば良いのか、直感的に分からないので、チケットが放置される場合もあった。
「～済」というステータスは、タスク完了なので、自分はやらなくていいんだよね、と思ってしまうらしい。

また、メーカーのように、営業部隊・設計部隊・製造部隊が組織として分かれていると、チケットが組織をまたぐ場合に別のステータスが必要になるという場合もあった。
チケットをやり取りするボールは誰が握っているのか、をステータスで明確にしたいのだ。
すると、メーカーのような機能別組織の場合、一つの製品、一つのソフトウェアを出荷するには複数の部門が関連するために、ステータスがかなり多くなってしまい、チケットが放置される危険が高くなりやすい。

一方、SIならば、普通は一つのチームが要件定義からリリースまで担当するので、一つのトラッカーに含まれるステータスの個数はそれほど多くはないし、多くする必要性もない。
チケット駆動で回したいならば、トラッカーに含まれるステータスの個数は少ない方が回しやすいからだ。

そんな経験を振り返ると、Redmineは機能が豊富な特徴、機能が柔軟である特徴があるがために、逆に、縦割り組織の文化をそのまま持ち込んで、複雑なパラメータ設定になりがちだ。

特に最近、ISO9001やITILの運用プロセスをRedmineに乗せて運用できないか、という質問を受ける時がある。
彼らとしては、Redmineの柔軟なワークフロー機能やREST APIによるチケット情報の取得の容易さ、Redmineの展開のしやすさを生かして、ISO9001のような硬いプロセスを実現したいみたいだ。

門屋　浩文さんのツイート: "@akipii @netazone @akahane92 トラッカーやステータス・進捗率のからみは、組織やプロジェクトの癖がもろにでますね。何もなければ、このルールでやろうねと教育はしているののの、、、プロジェクトごとの癖をみて、ちょこちょこメンテナンスしたりしてます"

門屋　浩文さんのツイート: "@akipii @netazone @akahane92 ちなみに、トラッカー「ＷＢＳ」「障害」「課題」「要望」「質問」「レビュー記録」、ステータス「新規」「受付」「作業中」「停滞」「確認中」「差戻し」「完了」「却下」です。きっと組織によってぜんぜん違うんでしょうね"

【3-2】一方、Redmineでチケット管理し始めると、チームの雰囲気や組織文化が少しずつ変わっていくという経験もある。

たとえば、Redmineには最初のバージョンの頃から、複数プロジェクト機能があった。
この機能を使うと、ソフトウェアプロダクトラインのような複数製品の並行開発、一つのパッケージ製品を顧客ごとにカスタマイズする派生開発に適用しやすいことは、従来から知られていた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版～運用は組織に従う、ワークフローは組織に従う: プログラマの思索

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

この機能を使い始めると、メンバーは縦割り組織に属している感覚よりも、複数のプロジェクトで作業している感覚になる。
つまり、組織の建前としてはピラミッド型の組織構造かもしれないが、現場のメンバーにとっては、プロジェクト型組織に属しているような雰囲気になる。
すると、自分の役割や権限が広くなるので、能力のある若手はたくさんのシステムに触れる経験を得やすく、どんどん成長していく事例をよく見かける。

また、プロジェクト型組織になると、プロジェクト内でコミュニケーションが活発化する。
一つのプロジェクト内で、一つのチケットをやり取りして完了させるまでに、色んな部署の人達と連携しなくてはいけない。
だから、自分は○○組織の一員だから、という意識よりも、○○プロジェクトの一員という意識になり、縦割り組織の雰囲気をぶち壊し、風通しの良い組織文化を形成してくれる。

【3-2】また、チケットの構造がチーム内の組織形態を規定する事例も見かける。

若手のプロジェクトリーダーからよく聞く質問は、WBSやチケットは、機能単位で作った方がいいのか、作業ベースで作った方がいいのか、という内容だ。
設計・プログラミング・テストのような単位で作業をグループ化すべきなのか、それとも、画面単位や帳票単位で作業をグループ化すべきなのか、迷うらしい。

会社の研修で教わるやり方は、設計・開発・テストのような工程単位の作業管理だ。
このやり方は、元々、製造業で規模の経済を生かすための作業管理手法であるから、ソフトウェア開発に馴染まない、と僕は常々思っている。
メーカーの組織が営業・設計・製造・品質保証の部門に縦割りになっていて、機能別組織になっているのは、設備投資を有効活用し、製品を低コストで大量生産するために、規模の経済を生かすためにそのような組織構造になっているのだ。

しかし、ソフトウェア開発の場合、人月の経験則のように、作業メンバーを増やすほどプロジェクトはどんどん遅延していくことが既に知られている。
つまり、ソフトウェア開発は規模の経済が通用しない。
むしろ、機能単位に作業を分割した方が管理しやすい。
機能単位ならば、機能の粒度を小さくすることで、小さなチーム構成にすることが可能だからだ。

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索にあるように、工程単位のWBSと機能単位のWBSでは、PERT図の構造が全く違うし、WBSを管理しやすくするための組織構造がWBSに規定されてしまうのだ。

すなわち、チケットの構造は、プロジェクト型組織の役割分担を規定する。
チケットを階層化するほど、WF型開発っぽくなるし、チケットをバージョン単位でグループ化して小規模リリースを優先するなら、アジャイル開発っぽくなる。
開発プロセスは、逆に、組織形態を規定しまうのだが、それに気づかない人も多い。

【3-3】「ソフトウェアアーキテクチャは組織構造の影響をもろに受けてしまう」という経験則は、Conwayの経験則として既に知られている。
この考え方は、組織構造がソフトウェアアーキテクチャ、開発プロセスを規定することから、アーキテクチャやプロセスの複雑さの遠因には、ソフトウェア組織にあるということだ。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版～運用は組織に従う、ワークフローは組織に従う: プログラマの思索

一方、平鍋さんの記事で「逆コンウェイ戦略」という概念を知って、気づいたことがある。

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

「逆コンウェイ戦略」の発想は、より良いアーキテクチャに合わせて、チーム構成を作るべきというもの。
その発想を受け継ぐならば、より良いプロセスに合わせて、組織構造やチーム構成を決めてもいいのではないか。

実際、Redmineの導入によって、チームの文化や組織の文化は変わる。
その変化は良い方向性の場合が多い。
だから、積極的に、Redmineというツールの背後に隠れたプロセスを使って、縦割り組織を打破することも可能ではないだろうか。

【4】第65回 SEA関西プロセス分科会＆RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」のパネルディスカッションでは、上記のような経験や事例を元に、組織とプロセスの関係と、相互に与える影響について、パネラーや参加者の知見をまとめてみたいと思っている。

Redmineインスタンスはチームの組織文化や慣習を表す

Redmineインスタンスはチームの組織文化や慣習を表すという指摘が非常に参考になったのでメモ。
アイデアの途中メモ。

【参考1】
Redmineを運用している規模について - Google グループ

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

(引用開始)
私自身、【結局、「Redmineだめじゃん」】って言われるのを避けたくて、
いろんなプラグインを入れて、こういう使い方できますよと宣伝しながら
各プロジェクト単位でいろんなモジュール選択できる＝いろんな使い方ができるように環境を整えてきましたが、
結局、自分の所属するチーム以外に文化として根付かせるのに失敗しております。

で、ふとRedmineを使い始めてからの挫折の流れを自分の経験から追って考えてみたのですが、、、

--------------------------------------------------
①Redmineが使える環境を準備するのが大変だった。
→Bitnami Redmineで簡単にインスタンスはたてられるようになった。
　→でも、デフォルトのままでは組織や業務にマッチしていないので、、、
　↓↓↓
②Redmineのプラグイン導入で苦戦した。
→基本的には手順は同じなので、慣れれば大丈夫だけれど、
　たまにプラグイン同士が競合したりすると、自分でパッチを当てたりしていた。（諦めたこともあります）
　→でも、めちゃくちゃ便利そうなプラグインが現在のバージョンに対応していないことがわかり、、、
　↓↓↓
③Redmineのバージョンアップで苦戦した。
→データ損失が恐怖なので、バックアップとリカバリの手順を、他のサーバで完全再現できるまで念入りに確認しました。
　その環境上でプラグインの依存関係の確認もして、バージョンアップしました。
　→さあ、これだけ充実したRedmine、ぜひ他の人にも使ってもらいたい、、、
　↓↓↓
④他チームへの展開で失敗した。
→Redmineやプラグインの動きは、私のチームは①?③までの経験で見識を広げることができたけれども、
　他の人からすると、いきなり選択肢が多すぎて、それらを取捨選択して活用する道筋が見えませんでした。
　→すると、どうしてもそのチームの既存プロセスをRedmineに当てはめる傾向になりがちで、
　　Redmineに変えた意味ってあったんだっけ？って思われてしまいました。（最終ログイン日時が止まっているという・・・涙）
--------------------------------------------------

自分のチームと比較した時に何が違ったかというと、
Redmineがデフォルトの状態からバージョンアップやプラグイン導入などで改良されるにつれて、
チーム内のRedmine成熟度もあがり、利用プロセスも改良されていったことのように思います。
(中略)

それ故に、うまく動いているRedmineについ相乗りしたくなりがちですが、
1つのインスタンスそのものがチームの文化や慣習のようなものと考えれば、飛び込んでカルチャーショック受けるよりも、
デフォルトの状態からそれぞれのチームでRedmineのインスタンスを立てて、
チームと一緒に文化を成熟していくのがシンプルに上手くいくのかなぁと今は考えております。

そして組織や文化の問題を除けば、②や③のポイントでつまづきにくいような
新鮮な情報やサポート、こういう場のQAがこの先もっと潤えばいいなぁと思います。（「Redmine実践ガイド」はその1つですね）
(引用終了)

【1】最初は、自分のチームだけのためにRedmineを導入して、チケット駆動の運用がうまくいくと、隣のチームも相乗りして使いたくなる。
あるいは、自分が担当する他のプロジェクトも、Redmineに作業や障害の情報を集約して、運用を拡大していく。

そして、Redmineの運用規模が、当初想定していた数人の利用者から、100人以上の利用者で100個以上のプロジェクトまで増大していく状況はよく見られるし、僕自身も何度も経験してきた。

すると、小規模チームで有効だったチケット駆動開発という軽量プロセスの運用ルールが、大規模なチームや大量の案件、ソフトウェア開発以外の業務の作業管理へ拡張していくに連れて、どんどん複雑になってしまう。
特に、トラッカーやカスタムフィールドは、案件の種類、業務の種類、組織構造の影響を受けやすいので、肥大化しがちだ。
例えば、同じようなワークローであっても、ステータスの呼び名が違うと、別の部署の人は混乱しがちで、使いづらい、と苦情を言いがちだ。

上記の指摘では、「Redmineインスタンスはチームの組織文化や慣習を表す」のだから、業務や組織構造の観点で、複数のRedmineインスンタンスに分けて運用した方が良いのでは、と言う。
その意見は同感だ。

【2】Redmineの運用は、正直楽しい。
トラッカーやワークフローを考える作業は、自分がチームのプロセスを一から作っていることに相当する。
自分たちがやりやすいプロセスに改善する方法を考えて、Redmineに適用してみたら、その成果がすぐに現れる。
その試行錯誤が楽しい。

RedmineはRuby on Railsで作られているので、ソースのカスタマイズも簡単だし、RubyスクリプトでREST APIを呼び出して、好きなだけチケット集計機能を作りこんでも良い。

RedmineインスタンスはBitnamiで簡単に作れるので、チームのRedmineに反映する前に、事前に自分のローカルPCでプラグインを事前検証することも可能だ。

Windows版Bitnami Redmineをインストールする - Qiita

そのように、Redmine上にプロセスを作りこんで、Redmineをカスタマイズしていくと、Redmineインスタンスには、自分たちのプロセスが埋め込まれている。
自分たちのソフトウェア開発や業務がやりやすいように、最適化されたRedmineになっている。
だから、他チームや他部署が使いづらい、と苦情を言うのは当たり前だし、その苦情を受け入れていくほど、Redmineの設定もワークフローも複雑化していく。

今はサーバーは安いのだから、一チームに1個のRedmineを渡しても良いのではないか？

【3】でも、一つのRedmineインスタンスで、大規模運用したい動機もある。
例えば、ISO9001や内部統制に即した運用プロセスをRedmineで実現したい場合、1個のRedmineインスタンスに全ての作業情報を集約し、トレーサビリティと全文検索を実現したいのだ。

そうすれば、Redmineに蓄積された作業情報から、ISO9001や内部統制の内部監査でも、必要な資料を即座に探し出し、その障害や事案の発生元の要件まで追跡する事が理論上できる。
今までの内部監査のプロセスでは、これらの作業を大量の紙媒体やExcel資料を使って運用をカバーしてきたのだから、IT化して作業を効率化したい、と思うのは普通だろう。

実際、今の日本の製造業を中心とする大企業は、こういう無駄な管理作業に、大量の人員とリソースをかなり費やして、ビジネスのスピードを落としている現状があるからだ。

しかし、Redmineは元々、障害管理ツールから生まれたツールなので、ISO9001や内部統制に必要な機能要件や性能要件を全て満たしているとは限らない。
もう少しかゆい所の機能も改善して欲しい部分もある。

【4】今、僕が考えている課題は「多様な案件かつ多様な業務を一つのRedmineインスタンスで運用するには、どんな機能やどんな運用ルールが必要なのか」だ。

Redmineで、ソフトウェア開発のほとんどの開発業務はカバーできるし、他業界のタスク管理や問合せ管理や資産管理などにも運用を拡張できることは、経験してきたし、かなり上手くいく。
Redmineの特徴である、多様な機能と柔軟性、Railsのおかげによるカスタマイズによる機能拡張のしやすさ、というメリットが大きく効いている。

例えば、日本の製造業に多く見られる機能別組織構造は、どうしてもサイロ型組織になりがちで、部署間の風通しも悪い。
しかし、Redmineを導入することで、Redmineプロジェクトにアサインされた複数部署のユーザがあたかもプロジェクト型組織に属するような雰囲気になり、チケットのやり取りを通じて、メンバーの信頼関係を育み、チームのプロセスを改善していく雰囲気も生まれるメリットがある。

でも、Redmineも業務プロセスを改善する一つのツールであるがゆえに、自分たちのプロセスがRedmineに埋め込まれているし、一度埋め込んだプロセスに関する設定を、後から大きく変更することは容易ではない。
JAXA担当者が編み出した「ロールのORルール」「カスタムフィールドのANDルール」は、Redmineの運用が大規模化していく過程で、Redmineの複雑さを軽減する一つの方法。

Redmineインスタンスに埋め込まれた、チームのノウハウというべきプロセスの思想、そこから生まれるチームの文化や慣習を、どの範囲まで拡大運用できるのか？

ZabbixからRedmineにチケット登録してインシデント管理する方法

ZabbixからRedmineにチケット登録してインシデント管理する記事があったのでメモ。
特に主張はなし。

【参考1】
監視ツール × Redmineで実現する自動インシデント登録システム - Qiita

【参考2】
障害発生時にも漏れなし！ Zabbixの監視アラートでRedmine上にチケットを起票する仕組みをつくろう (1/4)：CodeZine（コードジン）

Zabbixコラボ企画「第２弾　Redmineと連携しよう！！～Part１～」｜zabbix｜クラウド関連技術ブログ｜クラウドデザインのFL.OPS

Zabbixの監視アラートでRedmine上にチケットを作っちゃおう

ZabbixとRedmine連携の記事のリンク: プログラマの思索

Zabbixの監視アラートでRedmine上にチケットを作っちゃおう

【1】Zabbixのようなサーバー監視ツールで、エラー検知したら、Redmineに障害チケットを自動登録させたい。
一度チケット登録されれば、通常の運用フローで、オペレータからインフ担当者、問題管理プロセスで開発チームが抜本的なソース修正のように回せるから。

外部システムからRedmineチケットを自動登録させる方法は2種類あるだろう。
一つは、メールによるチケット自動登録。
もう一つは、REST APIによるチケット登録。
両方共に、シェルスクリプトやCronコマンドを書けば対応できるので、実現方法も運用も難しくはない。

では、違いは何があるか？

【2】メールによるチケット自動登録の場合、メール本文にチケットの属性やカスタムフィールドの変数名を対応付けておけば、チケットの属性に自動登録してくれる。
最新版では、Pop3sに対応するとか、チケットの基本属性だけでなくカスタムフィールド、ウォッチャーの登録もできるなど、数多くの機能が改善された。

RedmineReceivingEmails - Redmine

Wikiを見ると、Cronよりも下記のGemを使った方がrakeタスクが速くなるという文章があるので、色々試してみてもいいだろう。

RedmineReceivingEmails - Redmine

なお、メールによるチケット自動登録機能は、以前よりもかなり高機能になっているので、できるだけ最新バージョンを使った方がいいし、Redmine本家のドキュメントを見て、コマンドを確認した方が良い。

【3】REST APIの場合、メールによるチケット自動登録機能よりも数多くの操作が可能だ。
たとえば、チケットに実績工数を付けたり、ファイル添付も可能だ。

Ver3.3から、検索APIも提供されるらしいので、Redmine本家のドキュメントを見て、コマンドを確認した方が良い。

Rest api - Redmine

上記の記事を読むと、REST APIからチケット登録用のシェルスクリプトを1本作った方が色々カスタマイズしやすい。

【4】個人的には、Zabbixからのインシデント管理は、別のRedmineインスタンスで管理した方が良いように思う。
理由は、サーバー監視ツールからのエラー検知は大量に発生しがちであり、通常の運用におけるインシデント管理で起票したチケットに混じってしまうと、Redmineチケットが膨大に増えて、ゴミ箱になりがちと思うからだ。

neta＠とんこつしかたべないさんのツイート: "Zabbix→自動起票やめました。『対応 が必要なものだけ起票させる』が困難で、ゴミが大量に上がったので。今はThunderbirdメールからアドオン https://t.co/5TCIIoj5VA で手動作成 #redmine https://t.co/InO7D1CXiv"

この辺りの運用も色々やり方があると思うので、試してみる。