RedmineもOSLC規格を導入してトレーサビリティを強化すべきか

@agilekawabataさんが、RedmineにOSLC規格を実装すべきでは、と提案されていたのでメモ。
詳細は知らないので、ラフなメモ書き。
間違っていたら後で直す。

【参考】
Feature #8678: Provide OSLC support - Redmine

（引用開始）
Open Services for Lifecycle Collaboration（OSLCまたはオープンサービスとも呼ばれます）は、ライフサイクルツールを組み合わせて使用しやすくすることで、製品ライフサイクルとアプリケーションライフサイクルの間の障壁を解消するためのオープンコミュニティです。
（引用終了）

Kawabata Mitsuyoshiさんのツイート: "チケットによく気付きましたねー。 ツール連携の標準規格です。JIRAは対応してて、こういうのが世界標準としては必要だなあと。 https://t.co/RV0KgGh56u… "

Kawabata Mitsuyoshiさんのツイート: "自動車業界など、欧米の大手企業には必須な感じです。ただ、RedmineもWebAPIがそれなりに揃ってるので、もしかしたら対応できてるのか、どこまで対応すれば良いのかがよく分からない。。… "

Kawabata Mitsuyoshiさんのツイート: "規格に対応することで、他のツールが標準で連携をサポートするようになり、複数のツールによってシステム構築するような大手には導入が進みます。JenkinsやGitHubと連携するようなことと同じです。世界的に広めるには結構重要な要素だと思います。… "

Open Services for Lifecycle Collaboration

OSLC CM Plugin - Jenkins - Jenkins Wiki

OSLC Japan Wiki : 1.OSLC とは

【1】OSLCとは、アプリケーションライフサイクル管理（ALM）でツール連携する時の公式規格のように思える。

OSLCの利用 - Enterprise Architect 13.5 日本語版 ヘルプ

(引用開始)
Open Services for Lifecycle Collaboration (OSLC) とは、ツールを統合するための仕様を定義するオープンなコミュニティです。
この仕様により、利用者の設計開発プロセスにおいて、さまざまなツールを連携させ設計データとワークフローを統合した環境を作ることができます。

OSLCはW3C Linked Dataに基づいています。OSLCでツール間を繋ぐ主要な技術の一つは、HTTPでデータを繋ぐことです。HTTPやRDFのような標準的な技術で、データの作成・参照・編集・削除を実現します。
HTTPのGETやPOSTのような標準的な方法で内容を編集できます。
(引用終了)

OSLCに対応したアプリ一覧では、Jira、Bugzilla、Mantis、Jenkinsなども含まれる。
よって、ツール連携する時に、この規格を使うことも可能。

Software - Open Services for Lifecycle Collaboration

【2】では、このOSLC規格を使うと、何が嬉しいのか？
僕は正直分からない。
今の所、OSLC規格がなくても、Redmineの運用で困った経験はない。

しかし、2012年の古い記事だが、自動車業界の安全規格ISO26262に準拠するために、このOSLC規格を持つALM管理ツールは必須だ、という主張があった。

ISO26262 日本IBM インタビュー：規格準拠は“入場券”にすぎない、ISO26262をきっかけに製品開発力の強化を (2/2) - MONOist（モノイスト）

(引用開始)
MONOist　オープンという意味では、「Redmine」のようなOSS（Open Source Software）ベースのプロジェクト管理ツールも候補になりませんか。

根城氏　OSSベースのツールを組み合わせてトレーサビリティを確保することもできますが、プロセスが複雑になります。その上、ISO 26262のPart.8で求められる「Qualification of Software Tools」を満足させるための情報入手が困難です。
　また、ISO 26262に準拠するということは、その製品の企画から廃棄まで最低でも20～30年はデータを管理し続ける必要があります。そのISO 26262と関連するツールも、長期間のサポート継続が確保されていなければなりません。
　小規模の企業のツールやOSSベースのツールは、このサポート継続に不安があります。これに対して当社は、DOORSやRTCについて継続的なサポートを約束していますし、世界的な大企業であることから買収の恐れもありません。
(引用終了)

上記の意見に僕は納得できていないが、そういう発想もあるのだろう。

【3】ここで、上記のOSLC規格の背後にある意図を推測すると、チケット管理・ビルド管理・構成管理の全ツールで、OSLC規格に準拠していて、このOSLC規格が使いやすいものになれば、ツール間連携でトレーサビリティを明示しやすくなる、というメリットを導き出したいのだろう、と思う。

なぜなら、自動車業界の安全規格ISO26262では、機能や要件から成果物に至るまでのトレーサビリティを明示することがプロセス管理の観点で重要である事により、OSLC規格を満たすツール同士を連携して、要件から成果物までを明示的にトレースできますよ、と言った事がやりたいのだろう、と推測されるから。

但し、その方向性をOSLC規格で解決できるのか否かは分からない。
過去にも、SOAPやらソフトウェアタグやら、WSDL・UDDIなど、数多くの規格が提唱されては、消えていった歴史があった。
OSLCは残っていく規格なのか？

【4】Redmineにおけるトレーサビリティについては、Redmineを使い始めてから、トレーサビリティの可能性、そして、トレーサビリティを実現できる範囲をどこまで拡張できるか、をずっと考えてきた。
未だに僕の中では解はない。

Redmineにおけるトレーサビリティの課題は何か？: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

Redmineをもっと強化できるポイントpart1～上流工程のトレーサビリティ強化: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張: プログラマの思索

実際、僕自身、Redmine大阪でも、Redmineでのトレーサビリティの実験結果を発表したが、まだまだたくさんのハードルがあって、思い通りの結果は得られていない。

Redmineにおけるトレーサビリティ管理の現状と可能性(第66回 SEA関西プロセス分科会＆第18回 Redmine大阪) #RedmineOsaka

いろいろ考えてみる。

【追記】
akipiiさんのツイート: "内容を聞きたい。そもそも今必要な規格か？RT @ir9: ぶっちゃけ当時そこそこ関係する（糞な）ソフトを創っていた（ぉ // RedmineもOSLC規格を導入してトレーサビリティを強化すべきか https://t.co/mJwHYSu4j6"

いろきゅうさんのツイート: "直接OSLCには関わらないお話で恐縮ですが… リンク記事のようにその昔の車業界の一部では、仕様書からソースまでを紐付けて仕様変更時の影響範囲を知りたい…という飯ネタがあり、そのようなソフト開発に関わってました。「そのうちOSLC対応する」と意識していましたが対応はしていません（申し訳ない… https://t.co/PygxMeoimR"

いろきゅうさんのツイート: "作成してたツールとしては… たとえば、EAのアプリ上にあるUML要素を選択して「関連要素検索」→「wordのxx章 / Excelのyy表 が関連」等出てるのは便利感ありましたが…… アプリ超えた要素の紐付け作業が面倒というのが正直な所でした…… "

akipiiさんのツイート: "ありがとうございます。やはり規格倒れな感じですかね。JenkinsのOSLC対応プラグインも2012年から更新停止だし。Redmine への実装優先度はかなり低そうですね。… "