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

JISA Digital Masters Forum2016 「～Digital Business in Action～いまこそ、ソフトウェアで「!(革命)」を～」というフォーラムが10/21金に東京で開かれるらしい。
その中の講演『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』が気になるのでメモ。

【参考】
JISA Digital Masters Forum2016 「～Digital Business in Action～いまこそ、ソフトウェアで「!(革命)」を～」

JISA Digital Masters Forum 「JDMF2016」タイムスケジュール

JDMF2016プログラム詳細～ 『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』

JDMF2016プログラム詳細PDF

(引用開始)
22 経験報告
『チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験』
宮本 陽一（三菱スペース・ソフトウエア株式会社 鎌倉事業部 宇宙第一技術部）

当社既製品の派生開発では、非効率な再利用（場当たり的な再利用）という課題に直面している。
再利用性の効率を上げるアプローチとしてプロダクトライン型開発への早期移行を試みる中、当社の開発を支える開発手法や環境（チケット駆動開発基盤）にプロダクトライン型開発を融合させる方法（Feature on TiDD）を見出した。
本報告は、その融合方法と評価実験を行った結果に関する事例報告である。
(引用終了)

下記に簡単な説明を付したシステム設計一覧のPDFが公開されている。

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

【1】チケット駆動開発基盤で使われるツールがRedmineであると仮定した時、プロダクトライン型開発とは、仕様が微妙に違うが似通っている多数の組込ソフトウェア製品の開発であろうと推測する。
チケット駆動開発とプロダクトライン型開発の相性が良いだろう、という考えは以前たくさん書いた。

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

マルチプロジェクトのWF型開発にはRedmineのどんな機能が必要なのか: プログラマの思索

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

【2】チケット駆動開発とプロダクトライン型開発の相性が良い理由はいくつかある。
一つは、開発チームの組織構成とRedmineのプロジェクト構造が密接に関連すること。
むしろ、Redmineを導入することで、プロダクトライン型開発に向いた組織構造が目に見えるようになり、チーム形成が促進されるメリットがあると思う。

「Conwayの法則」「逆Conway戦略」なる言葉があるように、ソフトウェア工学的にはとても面白い部分。

【3】もう一つは、プロダクトライン型開発を支える開発基盤に構成管理が重要な要素を占めていること。
たとえば、プロダクトライン型開発の一番わかりやすい例は、iPod/iPhone/iPadのようなAppleの製品ファミリー群だろう。

製品は違うが、コアとなるOSや部品のほとんどは共有化されており、再利用が促進されるメリットがある。
しかし、製品仕様はほとんど同じだが微妙に異なるプログラムをそれぞれできちんと構成管理していくのは、実は非常に難しい、という経験はソフトウェア開発者ならば誰でも知っているはずだ。

メインラインモデル、Git-flowモデルのようなブランチモデルで製品系列ごとのプログラムを構成管理し、マージ作業していく必要があるだろう。

ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係: プログラマの思索

アジャイル開発とソフトウェアプロダクトラインの関係: プログラマの思索

ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索

ソフトウェア再利用の概念: プログラマの思索

ソフトウェアプロダクトラインが解決しようとするもの～品質と再利用: プログラマの思索

【4】一方、部品や共通ライブラリが共有化されているために、一つのバグが他製品にも影響し、マージするのも大変だし、それぞれの製品のリリース日にも影響してくる。

つまり、マージ作業だけでなく、リリース計画の整合性を取るのが管理作業として大変なのだ。
その部分は、Redmineのチケット管理のコピー機能を上手く使えば、一つのチケットから派生したタスクに対し、製品ごとにリリース日が異なっても、作業チケットは漏れ無く管理することはできるだろう。
しかし、それ以外の運用ノウハウも色いろあるはず。

つまり、メインラインモデルのような構成管理だけでなく、複数の製品系列のリリース計画の管理という部分も考慮に入れる必要があるだろう。
この辺りは組織や製品や案件ごとに制約条件が違うので、細かなノウハウを聞いてみたい。

Redmineの画面レイアウトの微修正にこだわる改善要望はViewCustomizeプラグインを使え！

RedmineのGoogleGroupメーリングリストを見ていると、Redmineの画面レイアウトの微修正にこだわる質問が多かった。
たぶんViewCustomizeプラグインでほとんど解決できるのではないか？

新規チケットをデフォルトでプライベートにしたい。 - Google グループ

(引用開始)
プロジェクトで使用していると、途中まで入力中、これは公開したくない情報がどうしても出てきます。プライベートにチェックを入れれば良いのですが、入れ忘れて登録してしまうことがあるため、初期値でチェックが付かないものかと悩んでいます。
(引用終了)

カスタムフィールドに登録された順序に並び替えを行う - Google グループ

(引用開始)
現在、書式が『リストから選択』のカスタムフィードを使用しています。
チケット一覧画面で、このカスタムフィールドをソートすると、AtoZ順で並び替えられてしまうようです。
(中略)
これを、登録順（6 -> 7 -> 10 -> 11）で並び替えることはできるでしょうか？
(引用終了)

Redmine2.6でチケット一覧の項目幅を都度自由に変更したい - Google グループ

カスタムフィールドをたくさん作成する場合、見やすくするためにタブのようなものを作りたい - Google グループ

(引用開始)
チーム間での作業依頼票としてRedmineでチケット管理する要件があります。
カスタムフィールドをたくさん作成する必要があり、
とても見づらくなってしまします。

そこで、１つのチケット内でタブを作って、担当部署ごとに入力するフィールドをまとめたり
もしくは、まとまり毎に「展開ー折り畳み」する。というようなことが出来ないかと
思案しておりますが、ネット検索しても思うような情報が得られず困っています。
(引用終了)

akipiiさんのツイート: "面白いなあ。RT @mattani: @onozaty ご無沙汰しています。Redmineで、右クリックのコンテキストメニューに項目を追加して、サーバー側でシェルスクリプトを実行する、ってview customizeで出来ますかね？"

akipiiさんのツイート: "後で読む。RT @onozaty: はてなブログに投稿しました Redmine: チケット一覧のコンテキストメニューに、サーバにリクエストを送る項目を追加する https://t.co/5SAgJAhcXk https://t.co/Oy01iEWBHL"

y503Unavaiさんのツイート: "CF1列化提案 、本家3543にありました。 RT @akipii: Redmine のカスタムフィールドのユーザーインターフェイスは改善の余地がありそうだな。 https://t.co/VZSNCzJ6s3"

y503Unavaiさんのツイート: "@y503Unavailable Redmine本家に全く同じ案件あり、チケット1248,6331,7444,5195,19824 7444のパッチを参考にして暫定対処しよう。hard-codingで構わないし。 こういうソースレベル解決策の糸口が見つかる事はOSSのメリット"

対応方法としては、CSSの特定パターンのセレクタに対し、JQueryでイベント発火時に処理をフックさせればいいと思う。
下記の記事を参考にして、自分で色々試してみればいいのではないだろうか？
必要なスキルは、JQueryとCSSだけだから。

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

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

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

View customize pluginを使いこなす

View Customize Pluginで出来ること

view customizeプラグインを使いこなせるようになると、画面レイアウトのように個別の改善要望が多い機能はユーザが自由にカスタマイズできるような仕組みが欲しくなる。

おそらく最終的には、Redmine本体は開発基盤(マイクロコア)とみなして、画面UIはマイクロサービスのように、ユーザが自由に機能修正できるような仕組みが必要になるだろう。
その場合、Redmineの再起動無しで機能修正が反映できると良い。
そのアイデアは下記に書いた。

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

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

Redmine自体をマイクロコアとマイクロサービスに分解して再構築することは可能だろうか？
あくまでも妄想だが、Railsという優れたフレームワークが進化することで可能になるかもしれない。

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい～技術は人やチームに残る

SPIJapan2016の資料「現場から始めるアジャイルの技術プラクティス」資料が素晴らしいのでメモ。
個人的なラフな感想。

【参考】
SPI Japan 2016 | イベント | 日本SPIコンソーシアム

akipiiさんのツイート: "良い資料。「技術は超大事」「技術は人/チームに宿る」たぶん僕は技術指向、ボトムアップ指向の方が好きなんだな。組織変革、トップダウンは好きじゃない。現場から始めるアジャイルの技術プラクティス https://t.co/dzCclCA0CA"

akipiiさんのツイート: "聞きたかった！RT @Taka_bow: 今年のアジャイル関連の発表は基調講演の影響が大きくて「先ほど平鍋さんが言っていましたが…」「昨日平鍋さんも仰っていましたが…」という接頭辞が付きまくり。みんな、気にするな！笑 #spijapan2016"

akipiiさんのツイート: "ソフトウェア工学は未熟なプラクティスによって重大な阻害を受けてる、か。RT @hiranabe: 本日の講演資料こちらです。 #spijapan2016 https://t.co/PvOFlDC2cV"

現場から始めるアジャイルの技術プラクティス from Takuya Okamoto

アジャイル開発を日本の現場に導入する時、どこから手を付ければいいのか？
上記の資料では、「テスト駆動から始めよう」。
テスト自動化に反対する上司はいない。

テスト駆動の技術プラクティスは、他の技術プラクティス(CI、より良い設計)や品質改善、コスト改善にも良い影響がある。
なるほど、確かにそうだ。
他の技術プラクティスやマネジメントに目が向いてしまいがちだが、改めて初心に戻るような主張だった。

「アジャイルとかWFとか関係ない」
「技術プラクティスはプロセスに依らない」
「WFでもやれば良い (やるべき) 」
「技術は人/チームに宿る」
「チームを作り上げるには手間と時間が必要」
という主張はすごく同感。

プロセス改善、プロセス標準にどうしても目が向いてしまいがちだが、IT技術者である限り、技術にこだわって進んでもいいのではないか。
技術やプロセス改善のノウハウは、大きな組織やドキュメントに残るのではない。
人やチームに残るのだ。

だから、人やチームを大切にすること、人やチームを成長させる意識を持つことが大事。

個人的には、こういうボトムアップ的な改善方法が好きだ。
トップダウンの指導、標準化は、僕の経験上、上手く言った試しがない。
「選択と集中」という標語は良いが、日本人には向いていないのではないか。

たぶん、日本人は製造業のQC活動のように、ボトムアップのプロセス改善の方が当てはまりが良い気がする。
上から言われるのではない、自分たちの手元にある道具を使って改善できないか、という、ちょっとした動機から、最終的な良い製品を作り出す。
たぶん、そんな方法の方が上手くいく気がする。

Ｔ字形ER手法の手順書のリンク

Ｔ字形 ER手法の手順書のリンクがあったのでメモ。
分かりやすい資料。
自分が理解したことをメモ書き。間違っていたら後で直す。

【参考】
TM の最新 バージョン （TM2.0）

Ｔ字形 ER手法 使用上の注意点

僕はSQLをこう学んだ | mah365

(引用開始)
T字形ERというデータモデル設計法

上記のようなテーブル設計とは別に、かなり興味を持って勉強していたのがT字形ERというデータモデル設計法です。

たまたま前にいた会社の自由参加型の研修に応募したときに出会った考え方なのですが、佐藤正美という先生がなかなかヘンクツで面白い人で引きこまれたのでした。

太っ腹なことに、研修で使っているテキストも公開してくれています：
(中略)

T字形ERはRailsでのテーブル設計と相性が良い考え方でもあるので、また折に触れて整理した状態でご紹介したいです。
(引用終了)

Ｔ字形 ER手法のテキストのリンクは、TM の最新 バージョン （TM2.0）にある。

手順はこんな感じと理解した。

「受注入力」画面又は帳票を準備
→「受注入力」の勘定科目のT字形勘定を作り、左側に一意となるキー、右側に従属項目、のように仕訳(仕分け)する
→さらに正規化していき、「顧客」「商品」「受注」のような勘定科目のT字形勘定に仕訳する
→エンティティ(勘定科目)をリソース、イベントで分類し、イベントは時系列に左から右、リソースはイベントの上下に配置する。
→リソース、イベントに関連(参照制約・複合制約)を付ける
→さらにサブセットで分解して、NULL値を除去する

興味深い点は、簿記のT字形勘定を真似ていること、RDBに格納されたデータが命題であることから集合論の知識(1階述語論理とか)が使えること、イベントは全順序でリソースは半順序の関係にあること、みなしエンティティは「共存」の継承関係を使ってNULL値を除去していること。
DOAは色んな流派があるけれど、突き詰めると、機械的な設計手順となるT字形ERに落ち着くのかもしれない。

但し、Ｔ字形 ER手法 使用上の注意点に記載があるように、T字形ER手法は相当練られているので、自己流に解釈してカスタマイズしないように、と注意書きが書かれているので要注意。

組込みソフトウェア開発のプロセス改善の違和感

先日、組込みソフトウェア開発現場のプロセス改善の講演を聞いてきて、何となく違和感を感じた。
以下は感想とラフなメモ書き。
箇条書きなのでラフなメモ。

【1】こんな講演ストーリー。

【1-1】組込みソフトウェア開発組織での課題。
経営層がソフトウェア開発を分かっていない。
工場のモノづくりと同じような感覚でマネジメントしようとして、思い通りにならないことに苛立っている。

なぜ、そんなにコストがかかるのか？　コストやロスを見える化できないのか？
これだけの開発規模で、もっと安く作れないのか？　開発効率を向上できないのか？
人材を計画的に育成して、もっと良い人材を揃えたい。IOTやビッグデータ、AIなどが分かる技術者を揃えたい。

(感想)
メーカーの経営者から見れば、ソフトウェア開発はブラックボックスなのだろう。
モノづくりのように、なぜもっと作業を標準化して、資本(資金)と労働者を大量導入して、大量生産できないのか？と思っているのだろう。
ソフトウェア開発は労働集約的な産業であり、規模の生産性が効かないのを知らないだけ。

【1-2】では、開発者にとってのプロセス改善はどうか？

プロジェクトリーダーにとって、憂鬱な仕事。
現場は、プロジェクトを回すのに手一杯で、これ以上、管理作業を増やしたくない。
SQA審査は無駄、時間の浪費としか思えない。

ソフトウェア開発を失敗しないやり方、うまいやり方はないのか？
しかし、銀の弾丸はないのだから、最終的には、自分達にあったやり方を見出すしか無い。

【1-3】開発標準の目的は、ソフトウェア開発を手順化して、管理できるようにして、効率的なやり方を定着させたい。
製造業の生産工程の標準化、３Sと同じ発想。

SQA審査では、開発標準に定めたルール、それに沿ったチェックリスト、テンプレート資料で、ドキュメントを精査する。
しかし、この開発標準は実質的に機能していない。形骸化している。

現場にとって負担が大きいだけで、効果が薄い。
CMMIのようなプロセスモデルの要求事項を満たすだけのために導入された資料作り、という感触が強い。
では、手間がかかるデータの収集にツールを導入して解決できないか？

(感想)
本当にその通り。
CMMIやISO9001のようなプロセス改善のための資料作りは、審査を通すだけのための作業と化しており、本来の品質維持にあまり役立っていない。
実際、リリース後に、設計書を整備したり、テスト結果を整理する作業をまとめて行う場合が多い。

【1-4】開発の計測として、工数、開発規模、欠陥抽出数というメトリクスがある。
たとえば、下記がある。

欠陥検出密度＝欠陥検出数(件)/開発量(kStep)
開発効率＝開発量(kStep)/工数(人時)

【1-5】「欠陥検出密度＝欠陥検出数(件)/開発量(kStep)」は、どの工程で測定するか、で意味合いが異なる。
たとえば、「設計レビュー」「結合テストのテストNG数」「総合テストの障害数」なら、バグ率。
バグ率を使って、品質を良くするためのプロセスを取り入れることで、開発期間中のプロセス制御に使える。

しかし、レビュー指摘数が多いほど欠陥検出密度は大きくなり、品質が悪く見えるので、レビュー指摘を躊躇する人が出てしまい、悪循環になる場合がある。

一方、製品出荷後なら「流出不具合率」になる。
ハードの製品なら、出荷後の不具合は、PL法(製造物責任法)の制約でメーカーの無過失責任になる可能性があるから、一方的にコスト負担になりがち。
だから、流出不具合率はできるだけ低く、ゼロにしたい。

しかし、流出不具合率は、開発完了後、一定期間を経過しなければ測定できないデメリットがある。
また、開発期間内に欠陥があると分かっていて、その欠陥は品質に問題なしという評価で、出荷する場合もあるが、それは流出不具合率に含めるのか？

(感想)
欠陥検出密度は、テスト前に、他の類似案件を元に計画値を定めて、実績はそれとほぼ同じか、少し低いぐらいの数値になるように収める、みたいなやり方が多い。
でも、欠陥検出密度の測定方法はいくらでも改ざんできるので、あまり意味が無いと思う。
「これは障害ではなく、顧客要望の仕様変更です」と言って省くこともできるから。

【1-6】「開発効率＝開発量(kStep)/工数(人時)」は、開発する対象や領域によって傾向が大きく異る。
プロジェクトや製品ごとに違うために、比較しにくい。

また、流用開発や派生開発では、新規開発よりも開発効率の値が低くなりがち。
たとえば、流用率が高いほど、新規作成のソース行数は少ないが、工数は新規開発とそんなに変わらない。

話を聞くと、普通は、5step/時間、800step/人月くらいらしい。
1時間で5ステップ、または5行とは、かなり少なすぎるが、デバッグやテスト、障害修正を考えると、そうなるのだろう。

だから、経営者から見れば、ソフトウェア開発は効率が悪すぎる、と見てしまいがち。
つまり、開発効率は数字がひとり歩きしがちだが、比較は意味が無い。

(感想)
開発効率を使いたい場面は、子会社のオフショア開発者の生産性評価に使いたい場面が多い。
もちろん、開発効率が良い開発者が評価が高い。

しかし、実際は技術の習熟度、プロジェクトの習熟度に依存するので、ほんとうに正しいかどうか分からない。
メーカーのモノづくりならば、生産工程における単純な組立作業、ライン上の作業の開発効率として評価しやすいし、あまりブレない。
むしろ、生産工程の「標準時間」として抽出し、「生産標準」として「この生産工程ではこれくらいの作業時間が標準だ」と定めて、未熟練労働者を指導することもできる。
しかし、ソフトウェア開発でそんなやり方が通用するのか？

【1-7】そんな状況で、プロセス改善活動をやっているが、現場で蓄積するノウハウを展開していきたい。
組織のルールが自分達のプロジェクトに合わなくても、柔軟に解釈して運用する方が良い。
無理に合わせるため必要以上に時間を使わない。

(感想)
現実的にはそうなるだろう。
しかし、そうであれば、プロセス改善活動を進める立場の人の意義は、結局何だろうか？
プロセス改善部署がなくても、現場は回るのではないか？

【2】組込みソフトウェア開発のプロセス改善の話に違和感を感じたのは、製造業の品質管理の技法をそのまま当てはめようとしても、実際はうまくいかない、と思うからだ。
その違和感については、過去に書いた。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

ソフトウェア開発でバグ管理はなぜ必要なのか: プログラマの思索

上記の講演では出て来なかったが、僕が一番違和感を持つ言葉は「標準時間」「開発原単位」だ。
製造業では、開発効率の単位となる「標準時間」、開発コストの単位となる「開発原単位」をメトリクスとして抽出するのが一番重要であり、そこから計画を立てて、正確な見積を行おうとする。

なぜなら、数億～数千億円のような製造装置、製造ライン、工場を建てる場合、正確な見積がなければ、設備投資できないからだ。
しかも設備投資の意思決定は、実際のプロジェクト開始の1年前に決まっている。
だから、早めに開発効率やコストの原単位を計算する必要性がある。

しかし、ソフトウェア開発では、「標準時間」「開発原単位」は計算できるのか？
ソフトウェア技術者の能力によって、生産性や10倍以上違うのだから、標準時間も10倍以上違ってしまう。
開発原単位も、技術者の人月単価は30万円から200万円まで幅がありすぎるし、標準時間も10倍以上も差があれば、見積りのブレは大きくなりすぎ。
つまり、ソフトウェア開発では、「標準時間」「開発原単位」を計算しても、その正当性を説明しづらいのだ。

そもそも、アジャイル開発では、そんなものは計算しないし、計算しようとする動機も持っていない。

一方、日本の製造業では、実際の生産は外注に出している場合が多いので、外注によるアウトソーシングでどれだけコストメリットが出るか、品質が良いか、という評価が必要になる。
その時に、「標準時間」「開発原単位」という指標が外注ベンダー単位に必要なのだ。
そうすれば、今後の発注にも、見積りとして使えるし、納入された製品の品質評価にも使える。

そのやり方をソフトウェア開発にそのまま取り入れてもうまくいくとは到底思えない。

RedmineのSaaSサービスPlanioを使ってみた感想

RedmineのSaaSサービスPlanioを使ってみた感想をラフなメモ。
とりあえず画面キャプチャを貼っておく。

【参考】
お問合せ | Planio

Planio Japanさんのツイート: "Redmineを美しく高機能にしたプロジェクト管理SaaS「Planio」の日本向けサポートは認定パートナーのファーエンドテクノロジーが担当します。お問い合わせお待ちしてます! https://t.co/0mxVRD99c0 https://t.co/KHFNTh3lvI"

akipiiさんのツイート: "@Will_meaning さんの話を受けてさっそくRedmine Planioにアカウント作ってみた。スクロールしてもヘッダ固定とか、プロジェクト一覧画面で「展開」「折り畳み」とかUIがイケてる感じ。アカウント作成直後はSilver有償プランなのでBronz無償に変更した"

akipiiさんのツイート: "後で試す。RT @Will_meaning: 時間ができたのでPlanioを試して見る。Redmineをベースにしたプロジェクト管理SaaSとのことだけど、とりあえず、登録してから30秒と待たずにすぐに利用開始できたっす。 https://t.co/Seb6CzMLSG"

akipiiさんのツイート: "RedmineのUIを確認する。RT @Will_meaning: Planio触り始めて、すげー、やべー、これ、あのプラグインじゃん！マジかよ、こんな機能もあるの？(楽しい)」の4つのセリフで完結しそうなくらいエンジョイしている。 https://t.co/IZ00IdS3fc"

akipiiさんのツイート: "スクロールしてもヘッダ固定はスティッキーヘッダと呼ぶのか。なるほど笑。RT @Will_meaning: Redmineとの違いを言語化するのは私には難しいのですが、スティッキーヘッダーっていうんでしたっけ？Planioのはスクロールしてもメニューがついてきていて素敵です。"

【1】現在は、1プロジェクト2ユーザまでは期限なしの無料なので、Redmineインスタンスを自分で作りたくない人はお勧めかもしれない。

ざっくり触ってみて、面白そうと思った機能をメモ書き。

チケット一覧をスクロールしてもついてくるスティッキーヘッダー。
チケット一覧でサイドバーを広げたり畳めたりする三角印。
メニュー項目もページング機能で横切れしない。
AgileBoardプラグインがあるので、チケットをかんばんみたいにドラッグ・アンド・ドロップで移動できるし、見やすい。
チャットやチャットログの機能があるので、メールはいらない。
「TrackTime」はタイマーみたいな機能なので、工数(時間)を正確に付けることが可能。

プロジェクト設定＞モジュールには、Redmineのデフォルト機能だけでなく、Agile、CRM & Helpdesk(有料)、
Team Chat(有料)がついている。
CRMプラグインがあれば、顧客との打合せ管理と底から派生したタスク管理がやりやすくなるだろう。
リポジトリ設定では、GitHubやBitbucketなどのWebサービスと連携できるので、Redmineのチケット管理と協調して使えるだろう。

【2】画面はこんな感じ。
Redmineのテーマとは全く違っていて、今風の柔らかいデザインやUI。
Redmine初心者なら、使って見る価値はあるかもしれない。

Redmineの文書ファイルを全文検索するプラグインのリンク

Redmineの文書ファイルを全文検索するプラグインをリンクしておく。

【参考】
DMSF - Plugins - Redmine

GitHub - danmunn/redmine_dmsf: Fork of svn repository for redmine_dmsf

Redmine2.0のDMSFファイルをHyper Estraierで全文検索 | Scimpr Blog

Redmine2.0にファイル管理プラグインを導入～redmine_dmsf | Scimpr Blog

ElasticSearchで添付ファイルを検索対象にするプラグイン?elasticsearch-mapper-attachments | Scimpr Blog

GitHub - elastic/elasticsearch-mapper-attachments: Mapper Attachments Type plugin for Elasticsearch

第２回品川Redmine勉強会（日本語全文検索） from Masanori Machii

Redmineはチケット管理やリポジトリ管理がとても優れているが、課題となる機能は3つあると思う。
課題となる機能は、Git連携、全文検索、そして、文書ファイルの全文検索だ。

Git連携、全文検索については下記で書いた。
Redmineのプラグイン導入で解決できる見込みだ。

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

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

RedmineとGitを巡る疑問点～Gitとの連携機能の強化がRedmineの課題: プログラマの思索

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

文書ファイルの全文検索機能が欲しくなる状況は、Redmineチケットの添付ファイルの中身を検索したり、文書ファイルを検索したくなる時だ。
たとえば、本番障害のログや画面キャプチャ、課題の発端となった顧客メールのテキスト、改善要望の発端となったExcelやパワポ資料などを添付したくなる。
しかし、添付しただけでは、添付ファイル名はRedmineの全文検索に引っかかるが、添付ファイルの中身まで検索してはくれない。

本来は、Redmineチケットだけでなく、添付ファイルや文書ファイルなど、Redmineに蓄積されたデータや添付データ全てを全文検索できてほしいのだ。
そうすれば、Redmineは一つのナレッジDBになりうる。

現在のRedmineにはそんな機能はないが、DMSFプラグインとElasticSearchを導入することで、文書ファイルの中身を全文検索できるようになるらしい。

DMSFプラグインは一部のユーザは熱烈に使っている。
たとえば、Redmine本家のプラグインサイトDMSF - Plugins - Redmineを見れば、2012年頃から注目を集めているのが分かる。
日本でも、redmine.tokyoスタッフのMasanori Machiiさんが、NotesからRedmineへデータ移行するために、日本語の全文検索ができるような設定を試されていた。(それが上記の資料)

また、RxTStudy勉強会のJAXA講演でも、JAXAではDMSFプラグインを導入したらしい。
理由は、ISO9001の文書管理に使いたいから、とのことだった。

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

但し、DMSFプラグインはRedmineの最新版に対応しているが、日本語の全文検索に対応しているかどうかは不明。
多分、技術的には解決できるはず。

こういうRedmineの枠外の機能に関する課題も、色んな人達のアイデアやプラグイン実装で解決を試みようとしている動きは、見ていて楽しい。