« 2017年11月 | トップページ | 2018年1月 »

2017年12月

2017/12/30

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

下記の記事で、モデルの粒度とトレーサビリティの問題はモデリングツールではなくUMLそのものに真因がある、という事実に気づいたのでメモ。
以下、ロジカルでないラフなメモ書き。

【参考】
プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MONOist(モノイスト)

akipiiさんのツイート: "「UMLの使いにくいところと開発現場での実際的対応」の内容が本当に同感。UMLそのものが大規模案件で使うことが想定されてない問題があると思う。プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MO… https://t.co/qHIjmtpMKt"

【1】(引用開始)
UML/SysMLの使いにくいところと、それを使いこなすコツ
 UMLとSysMLは組み込み系開発で比較的多く使われていますので、ここではUMLとSysMLの使いにくいところと、開発現場でそれを克服して使いこなすコツを紹介していきます。

UMLの使いにくいところと開発現場での実際的対応

(1)階層記述ができない
 UMLで大規模なシステムをモデリングするときに、使いにくい欠点としては「階層記述」ができないという点を挙げることができます。大規模なシステムでは、ユースケースやクラス、オブジェクト、シーケンスなどの個数が膨大な量になり、ユースケース図やクラス図、シーケンス図などを描くときに階層記述ができないと非常に大きな紙が必要になります。A3用紙であっても描ききれなくなります。

 そこで開発現場では何らかの工夫をして、これらの図を階層記述をしているのが実情です。しかし、階層記述の方法が統一されていないため、各組織や各プロジェクト、さらに個人で違う記述をしていることがあります。結果として、階層記述の方法を確かめるところから、レビューを始めるということになります。

(2)要求図が弱い
 UMLで要求をまとめる図はユースケース図とそれを補間するシナリオ記述、さらに詳細に記述するためにアクティビティ図などを用いますが、要求図としての分かりやすさとしては不十分です。

 ユースケース図で要求とそれらの概略の関係は分かりますが、要求の一覧や要求間の関係、特に内包関係、要求の差分、要求の優先度などの記述は弱いものになっています。それを補間するシナリオ記述は基本的に自然言語で記述するため、モデラーの表現能力に大きく依存します。逆にアクティビティ図は機能がありすぎて、要求を記述すると別の図のようになってしまいます。

 開発現場ではユースケース図で要求の概略を表現し、詳細や一覧は昔ながらのExcelを使って自然言語で記述し、それに要求番号を振って、トレーサビリティを高めているような記述方法をよく見かけます。

(3)仕様が膨大で不統一
 UMLはその歴史から分かるように、モデル図と仕様が膨大になっていて、その思想も記述も不統一です。平たく言えば、図がばらばらで多すぎます。図が多いので、真面目なメンバー(融通がきかないメンバー)はどうしても多くの図を描いてしまいます。類似の情報を複数の図やその説明で見かけることになります。さらに悪いことにその用語や使い方がモデル図間で統一されておらず、同じ用語でもモデル図で違う情報になっていることもあり、どれを信用するか分からなくなります。まさしく魑魅魍魎な図になりがちです。

 開発現場では新規の開発よりも既存開発(改良開発)が多く、既存の多数のUML図をほぼコピペして再利用していることが多くなっています。コピペで低コストなのはいいことかもしれません(本当はそんなことはありません!)が、図が多いため、差分管理ができずに、全ての図の全ての部分を延々と保守続けることになります。いざ差分を探そうとすると、非常に面倒なことになります。

(4)トレーサビリティが弱い
 各モデル図で使用した要求やクラス、オブジェクト、シーケンスなどが他の図でどのようになっているかを追跡するときに、UMLでは弱すぎます。UMLツールによって、ある程度のトレーサビリティは保証されますが、図として見た場合は、トレーサビリティがなく、見にくくなっています。

 開発現場では、ここでもUML図とは別にExcelなどを使って、トレーサビリティを保証するようにしている場合が多くなっています。

(5)目的が総花的
 仕様が膨大という欠点と同様ですが、UMLを描く目的が曖昧になるとUMLで作ったモデルも総花的になりがちです。このため、モデル図は大きくなり、大きな紙(A3用紙)を必要とします。

(6)コード生成が弱い
 UML2.0になってコード生成は強化はされていますが、UMLでコード生成をするのは弱く、はっきり言って、使いものになりません。特に例外処理のコードも含めると面倒なことになります。最初の1回はコード生成をしても、その後、プログラムを変更する必要が生じたときに、モデル図から変更するのは骨が折れます。心が折れます。

(7)差分表記(相違性と共通性の表記)が弱い
 これはUML特有の欠点ではなく、多くの図的表現に当てはまりますが、以前のシステムとの差分、以前のモデル図との差分の記述が明示的にできません。ソフトウェアプロダクトラインエンジニアリング(SPLE)で使われるフィーチャー図のように差分を明示的に記述できません。開発現場では前のモデル図とどこが変わったのか、逆にどこが同じなのかを何らかの方法で記述し、共通部と差分(派生部)を明確に示す必要があります。

(5)その他のコツ
 UMLの各図では目的を絞って描く、コード生成には使わない、一覧表示などの管理は別にするなどがあります。
 ここではUMLの悪口とその対応の面倒くささを紹介した形になりましたが、これは逆に開発現場でUMLが定着し、使っている人が多いからこそです。この記事を読んで別のものを使おうとせずに(苦労はするかもしれませんが)UMLを使ってみてください。
(引用終了)

【2】astahをずっと使い続けてきて、モデルの粒度とトレーサビリティ、変更管理に関して不満があったので、その問題点について下記で考えていた。

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

しかし、上記の記事を読むと、モデリングツールの問題ではなく、UMLの仕様そのものに真因があるようだ。
UMLでは、アーキテクチャを描いたモデルの階層化やトレーサビリティに関する仕様またはプラクティスがほとんど見られない現状がある。

一方、実際の開発現場では、要件定義から基本設計、詳細設計へ工程が進むにつれて、モデルの粒度はどんどん詳細化していく。
もっとモデルを詳細化すべきだ、という認識になったら、普通は次フェーズの工程で作業するように予定する。
つまり、各工程の設計モデルに関する粒度については、基本は設計者の間で認識は統一されているのが一般的だ。

また、要件から画面帳票の詳細設計書に至るまで、普通は設計書の間でトレーサビリティを確保するように、開発プロセスを計画する。
なぜなら、各工程のアウトプットが次工程のインプットになるので、トレーサビリティを意識しなければ、詳細設計書の正当性を保証できないからだ。
一般に、Excelの管理台帳で、要件定義書、基本設計書、詳細設計書の一覧を管理し、それらの間の関係を何らかの形で保守し続ける。

そういう現実を考えると、UMLでは各工程の成果物の粒度やトレーサビリティに関する基本方針がない点に問題があるような気がする。

【3】では、なぜ、UMLでは粒度やトレーサビリティに関する問題点にあえて触れていないのか?

理由はおそらく、粒度やトレーサビリティに関する仕様は、各案件で多種多様な運用ルールがありうるので、標準化する作業そのものが難しいからだろう、と推測する。
もし、粒度やトレーサビリティに関する標準ルールを決めたとしても、抽象的すぎて、実際の現場では、その仕様に耐えうるテーラリングにすごく時間や労力を費やすしかないのではないか。

似たような事例として、過去に、IPAがソフトウェアタグという仕様を定めて普及しようと頑張っていた事例があったけれど、実際の現場にはほとんど影響しなかった。

IPA 独立行政法人 情報処理推進機構:ソフトウェアジャパン2009 IPAフォーラム

コンピュータソフトの開発過程が一目でわかる仕組みを世界で初めて規格化 複雑化、大規模化する製作状況に対応した「ソフトウェアタグ」|奈良先端科学技術大学院大学

理想論としては、ソフトウェアタグのような符丁をソフトウェア成果物に組み込めば、農産物や製品のトレーサビリティのような運用が可能なはず。
しかし、ソフトウェアはそれらモノとは違って、実体が曖昧で管理しにくいために、現実に運用しにくい。
結局、粒度やトレーサビリティに関するExcel管理台帳が余計に増えていくだけで、その保守コストが増えていくだろう。

【4】また、UMLで変更管理や構成管理の問題を解決するアイデアはないのか?
UMLの仕様に関する最新情報は知らないので、この辺りは分からない。

しかし、UMLでモデルをお絵描きしても、その後の保守で問題となるのが、構成管理や変更管理の話題だ。
実際、本番リリース後の保守フェーズで、細かな仕様追加や仕様変更が発生すれば、その都度モデルを修正していくコストが発生する。
その作業コストは意外とバカにならない。

また、仕様変更前のモデルと仕様変更で変わった後のモデルの差分を表示する機能がモデリングツールでは弱い。
だから、その後の保守作業で、作業者が頻繁に入れ替わったら、変更理由や本来の意図も分からなくなりがちだ。

さらに、Gitならフィーチャーブランチを切って、マージする時にプルリクエストを送ってコードレビューを依頼する、という一連のプラクティスをモデリング作業に適用しにくい。
つまり、モデリングのレビューは、昔ながらのレビュースタイルで実施せざるを得ない。

モデルの構成管理、変更管理に関する問題は、10年以上前からほとんど進歩がないように思える。

【5】さらに、UMLそのものにその弱点が内包されているとすれば、どんな影響が出てくるのか?

僕は、大規模システムでは特に、モデルの粒度とトレーサビリティに関する枠組みがなければ、現実的に運用しにくいだろう、と考えている。

たとえば、大企業向けのERPは、販売管理、発注管理、生産管理、会計管理、人事管理など数多くのサブシステムで組み立てられている。
それらサブシステム単位に要件から仕様まで数多くのモデルがあり、それらが階層化されて、トレースされていなければ、描いたモデルは設計書の代わりにはならない。

また、描いたモデルの粒度について認識が合わなければ、設計者と開発チームのコミュニケーションを促進されないだろう。
さらに、大規模システムでは、数多くのテーブル、画面帳票、バッチがあり、機能が複雑に絡み合っているので、元々混乱しがち。

10年以上前に、オブジェクト指向開発プロセスが流行していた頃、全ての設計書をEnterprise Architectのモデルで描いて、Javaで実装するWebシステム開発案件に加わっていたが、内実は混乱していたのを思い出す。

【6】このように、UMLの仕様そのものに、モデルの粒度とトレーサビリティ、変更管理の問題が内包されているので、その仕様そのものを実現したモデリングツールもその問題点をそのまま現状に反映しているだけ、と理解できる。
つまり、モデリングツールに罪はない、と僕は考えた。

一方、モデリングツールがUMLの弱点を解決していく、という方向性もあるのではないか、と考えている。
つまり、モデルの粒度とトレーサビリティ、変更管理に関する問題は、むしろ、モデリングツールが積極的に解決できる分野ではないか、と考えている。

実際、業務フローやアーキテクチャをモデリングしていたら、モデラーは自然に、自分が描いているモデルの粒度を揃えたり、詳細化していく時にトレースしながら仕様を詰めているはずだ。
よって、モデリングツールが、モデラーの思考行為そのものを支援するように操作性を向上させることは可能なはずだ。
つまり、モデリングツールは、モデラーのモデリング作業を補完する統合設計環境であるべきだろう。

その辺りも今後考えてみる。

【追記】
モデル駆動開発の考え方について、良い記事があるのでリンクしておく。

モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン)

akipiiさんのツイート: "モデル駆動開発用ツールBridgePointを使って、クラス図とステートマシン図を作成して実際にシステムを動かすお話。面白い。モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン) https://t.co/StxjQjZ8pg"

| | コメント (0)

2017/12/27

安全性解析手法STAMP/STPAセミナーの感想

先日、安全性解析手法STAMP/STPAセミナーに行ってきた。
ラフな感想をメモ書き。

【感想】
安全性解析手法STAMP/STPAセミナー@大阪(ソフトウェア高信頼化 SECセミナー )-SEA関西

安全性解析手法STAMP/STPAセミナー@大阪

「はじめてのSTAMP/STPA(実践編)~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

【1】最近のIT業界だけでなく、メーカーでも、IOTやAI、ビッグデータがバズワードになっている。
家電製品は既にソフトウェア化されてしまって価格破壊と鮮度劣化が激しいけれど、ついに自動車にもEVの波が押し寄せてきたように、メーカーが製造するあらゆる工業製品もソフトウェア化が迫ってきている。

しかし、従来のメーカーの品質管理手法は、そういうソフトウェア化の環境変化に対応しきれていないと考えている。
メーカーの品質管理手法は、統計的品質管理を主体とした、量産品の品質管理技法だと思う。
つまり、品質が保証された製品を大量生産するために、品質のばらつきを管理図などのQC技法で潰し、歩溜まりを上げて、経験曲線効果を活用して、コスト低減と品質向上を目指す。
この手法が以前まで、日本の製造業は品質で世界一だ、という評価をもたらしてきた。

しかし、製造業における、大量の資金投入による投資と生産設備の最新化、大規模化、という規模の経済の考え方は、ソフトウェア開発では全くと言っていいほど通用しない。
ソフトウェア開発は徹頭徹尾、労働集約的な産業だと僕は思う。

たとえば、人月の法則で言われるように、大量の開発メンバーが加わるほど、システム開発は遅れる。
他に、コンウェイの法則のように、大人数の組織は、その複雑な組織構造がソフトウェア設計にも反映されて、ソフトウェア構造がより複雑化され、ソフトウェアはエントロピー増大にさらされる。

そこで、アジャイル開発、そしてスクラムでは、規模の経済をベースにした製造業の開発スタイルではなく、サーバーントリーダーシップや自己組織化の理念の元で、小規模な開発チームで状況変化に素早く対応できる仕組みを提唱してきた。
よって、ソフトウェア開発をビジネスの主体とするならば、たとえメーカーであろうとも、アジャイル開発の導入は避けては通れないはずだ、と僕は思っている。

【2】でも、ソフトウェア開発の仕組みを製造業にそのまま取り入れたとしても、上手く行かない部分がある。
それが、安全性という品質特性だろう。
特に、フェールセーフという安全性の品質だろうと僕は思う。

たとえば、鉄道の踏切、交差点の信号、レンジやドラム缶式洗濯機などでは、人が事故に合わないように、安全が保持できる方向へ切り替わる仕組みが考えられ、昔からその機能が提供されてきた。
しかし、ソフトウェアが製品に組み込まれると、ちょっとしたバグが人命の危機にさらされるリスクが増大する。
そして、ソフトウェア開発者なら誰でも知っているだろうが、全ての潜在バグを潰すことは事実上不可能だ。
つまり、ソフトウェアが組み込まれた製品は、安全性に関して、何らかの不安が残る場合がある。

そういう課題は以前からずっと認識されてきたようで、たとえば、自動車の電子制御系に関する機能安全規格はISO 26262として最近公開された。
ついに自動車でもISOとして安全性という品質が業界標準で決まったために、組込ソフトウェアにおける安全性の研究は現在ホットな状況なのだろう、と思う。

IPAでも、この分野の研究が重要と認識しているようで、セーフウェアの本の著者であるナンシーさんとも共同して、安全性解析手法STAMP/STPAという手法を作り、日本のメーカーに広げようとしているようだ。

今回は、そんなセミナーに行ってきた。

【3】正直な感想を言うと、僕は門外漢なので、安全性解析手法STAMP/STPAがどこまで有効なのか、分からない。
でも、こういう安全性解析手法がどんな考え方をしているのか、というイメージは持つことができた。

一言で言えば、部品単体レベルの品質向上を目指すのではなく、もっと抽象的なレベルを上げて、製品とそれに関わるステークホルダーの関係に注目する観点で、安全性を議論しようとしている。
下記の絵が分かりやすい。

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

一般に、メーカーの品質管理の考え方では、下請け業者から仕入れた部品の品質を徹底的に管理し、それら高品質な部品を組み立てて、最終製品の品質を維持しようとする。
しかし、製品が複雑な構造になると、部品単体の品質が良くても、それら部品の関係や依存性で品質が悪くなる時がある。
その話は、部分の合計は全体と一致しない、むしろ全体よりも大きくなる、という集合論の話を連想させる。
バナッハ=タルスキーのパラドックスだったかな。

バナッハ=タルスキーのパラドックス - Wikipedia

ソフトウェアが混じってくれば、なおさら、プログラム単体ではなくシステム全体として機能させた場合の方が品質に大きく関わってくる。
つまり、部品レベルではなく、製品全体、製品とそれに関わるユーザとの相互作用を考慮した「システム」のような考え方が必要になってくる。

【4】この考え方にはいくつか特徴があると僕は思う。

【4-1】一つは、製品のI/Fがユースケースになること。
たとえば、電気自動車を考えた場合、ユーザは電気自動車に何を期待するのか、という観点から、電気自動車に必要な機能を考えていくことができる。
この考え方のメリットは、ユーザの価値や便益を起点に機能を考えるので、ユーザに優しい製品になる可能性が高いことだろうと思う。
つまり、ソフトウェア開発の企画や要件定義の手法を取り入れているように思う。

すると、製品とユーザの接点は、製品のI/F機能、またはユースケースと考えることができる。
なぜなら、ユーザが製品を使う利用シーンを考えるようになり、それを表現しようとすると、ユースケースの概念が自然に現れてくるからだ。

また、ユースケースの概念が現れてくると、「SysML」本のコンテキスト図のように、製品に関係するステークホルダー全てがアクターとして現れ、その中心に製品が配置されるような図が作られることになる。
つまり、この考え方では、アクターを漏れなく抽出すること、アクターと製品に関わるI/Fとなるユースケースを自由な発想でどれだけ考えられるか、という観点が重要になってくるだろう、と思う。

そして、そのコンテキスト図を元に、安全性の観点を組み込んで製品の機能を付けていくことになるはず。

ただし、アクターやユースケースが漏れると、その後の工程で検出することは不可能なので、自由な発想を補強するようなプラクティスが必要になってくるのではないか。

【4-2】もう一つは、製品のハード設計がなくても議論できること。

一般に、ハード屋さんはどうしても実際のモノの設計図から考えたがる。
しかし、企画段階ではモノがないので、イメージにしくい。

だが、製品にはこんな機能があるとユーザにとっていいよね、という観点で、製品のI/Fを洗い出していくことができるし、それらI/Fを整理することで、製品のおぼろげなイメージが出てくる。
たぶん、iPodやiPhoneのような製品も、プロトタイプ製品はあったとしても、ユーザの利用シーンから色々考えて作られたのではないだろうか。

すると、製品のハード設計図がない状態で製品の機能を作り出し、安全性の品質の議論ができるようになる。

なお、SysMLのメリットは、ハード設計図がなくても、ソフトウェア層の観点で抽象的なレベルで要件や機能をイメージできること、という話を聞いたことがあったが、たぶん、その内容とほぼ似たことなのだろう。

実際、IPAの方の講演でも、抽象的なレベルで考えることでより広く安全性を考えることができる。
部品レベルのような粒度の細かい観点で考えると、安全性を考慮すべき観点が漏れやすいから、あえて、抽象度をあげて幅広く議論するのだ、という話があったから。

【5】上記の内容は素人の考えなので、どこまで正しいのか分からない。
でも、安全性の品質に関する議論を、箱と矢印の図で行おうとする方向性を見ると、ハード設計図のレベルではなく、SysMLのようなソフトウェアのレイヤーで抽象的なレベルで設計しようとしているように思える。

この手法がどこまで通用するのか、僕は分からない。
でも、ソフトウェア開発がハード設計でも重要になってくるならば、具体的なモノがない状態で機能を設計する必要性は出てくるだろう。
すると、ソフトウェア設計のように、要件や仕様を決めていく技法やプロセスが必要になってくる。
それら技法は、たぶん今までのハードのやり方は通用しないだろう、と思う。

そして、アジャイル開発を取り入れた場合の品質保証は、どのような観点に考慮すれば効果的なのか?
そういう課題も考えてみたい。

【追記】
STAMPについての分かりやすい記事が紹介されている。

STAMP/STPAとは何か (4/4) - MONOist(モノイスト)

| | コメント (0)

2017/12/26

第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」

来年2月3日に開催予定の第66回 SEA関西プロセス分科会&第18回 Redmine大阪の見所を書いておく。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

【1】(引用開始)
テーマ~「チケット管理システムによるソフトウェア開発支援と今後の課題」

今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。

気象庁|数値予報課報告・別冊 第63号(平成28年度) 数値予報モデル開発のための基盤整備および開発管理

気象庁におけるソフトウェア開発プロセスの事例で興味深い点は3つあります。

まず、一つのサーバー上で複数のRedmineインスタンスが運用されていて、各部署がそれぞれのRedmineインスタンスで異なる運用ルールを実施している点です。

次に、Redmineの特徴を十分に理解した上で下記のような運用ルールを展開している事が挙げられます。

(1)チケットの粒度は最初は気にせず、まずはチケットを作成して試行錯誤することを勧める事
(2)「No Ticket, No Commit!」ルールを徹底周知し、開発成果の信頼性向上や情報共有に役立てる事
(3)親子チケットによる進捗管理では、子チケットを五月雨式に作成しない点に留意する事

さらに、RedmineとGitを連携してgit-flowの開発プロセスを利用されているように、並行開発やコードレビューの仕組みを取り入れている点です。

以上のように、気象庁の事例報告を読むと、数値予報モデルの開発基盤と開発管理に、昨今のOSS開発では普通に行われているモダンな開発プロセスを上手く取り込んで運用されていることがよく分かります。

気象庁の担当者の方の事例講演を次回も聞くチャンスはそうありませんので、Redmineの初心者から、ソフトウェア開発プロセスに興味のある方まで、ぜひお越しください。

講演1
「気象庁の数値予報モデル開発における開発管理ツールの活用」

講演者:原旅人 様(はら たびと・気象庁予報部数値予報課予報官)

概要:
現在の天気予報は、スーパーコンピュータによる気象シミュレーション(数値予報)の
結果をもとに作られていて、そのためのソフトウェアのほとんどを気象庁の職員が
自らプログラムを作って開発しています。これらのソフトウェア開発は気象庁内で
組織横断的に、そして継続的に長いスパンで行われることが多いため、情報共有、
議論や作業の記録が大変重要であり、その支援ツールとして Redmine やバージョン
管理ツールを活用しています。

本講演では、気象庁の業務を簡単に紹介したのちに、気象庁におけるソフトウェア開発、
Redmine やバージョン管理ツールの利用の背景と経緯、およびその活用などについて
紹介します。
(引用終了)

【2】このたび、気象庁のRedmine利用事例を講演して頂けることになった。
個人的に聞きたかった内容ばかりなので、とても嬉しい。

上記の参考資料の通り、気象庁の開発プロセスでは、RedmineやGitなどの開発支援ツールを積極的に取り入れて、コードレビューや複数ブランチの並行開発、進捗管理などを効率化し、最近のオープンソース開発で主流となっている開発スタイルを実践されている。
気象庁というお硬い役所でも、モダンな開発スタイルを実践されているのに、未だにExcel主導のWF型開発に囚われた古い開発スタイルをやっているSIの方が多くて、時代遅れに感じてしまう時がないだろうか。

また、実際の開発業務では、気象庁の担当者自らがプログラミングして、天気予報の予測などの業務に役立てているのを読むと、自分たちの業務系システム開発とは違った別の側面が見えてきて、とても面白い。

たとえば、「Rubyは数値予報ルーチン関連のツールでも利用されている言語であり、管理者育成でも比較的少ない人的教育コストで管理可能という面を持ち合わせている」という記載から、気象庁にRedmineを導入しようとする壁は低かったのだろう、と推測する。
他に、欧米の気象庁に相当する官庁では数値計算にPythonを使うのが普及している、という事例を参考にして、Pythonスクリプトを記載していたりして、昨今の開発トレンドを積極的に取り入れようとする姿勢がよく伺える。

【3】そんな内容を考えると、気象庁では、先進的な技術を積極的に取り入れるという先取り精神が旺盛なのではないか、と思える。
実際、RedmineやGit等の先進的な開発支援ツール、RubyやPython等のプログラミング言語やライブラリを積極的に取り入れて、天気の数値シミュレーション等の業務に役立てているからだ。

Redmineコミュニティに関わるスタッフの立場としては、JAXAや気象庁という日本の大手官公庁でもRedmineを相当研究して利用されている、という事例が公開されることで、より普及が促進される効果もあるだろうと思う。

当日は、資料に記載されているRedmineやGitの開発ワークフローの背景、実際の気象庁の業務についても、色々詳しく聞いてみたいと思っている。

【追記】
ツイートした感想。

akipiiさんのツイート: "気象庁のRedmine 事例報告書を読み直してるけど、非常によく、Redmine によるチケット駆動の特徴を生かしてると思う"

akipiiさんのツイート: "Redmine チケットの粒度は最初は気にせず、チケット作成に躊躇せず、まずは試行錯誤してみたらいい。そのうち、チーム毎に運用は固まる、と。だから、あえてRedmine インスタンスを部署毎に立てて、運用とプロセスを任せている。"

akipiiさんのツイート: "気象庁では、チケット無しのコミット不可のルールを徹底周知して、Redmine とGitを連携し、さらにgit-flowに似たモダンな開発プロセスで運用されてる。お堅い官公庁の開発部署の方が民間企業より最先端かもしれない笑"

akipiiさんのツイート: "気象庁では、Redmine の親子チケットかんりでは、むやみに子チケットを五月雨式に作らない事に留意するよう促してる。そりゃそうだ。進捗率が90%になったのに安易に追加して50%に下がったり、仕様変更によるスコープ増大のチケットがどれか分からなくなる。アンチパターンでありそう"

| | コメント (0)

2017/12/23

仕様書にもExcel脱却が求められている

現代は、タスク管理や障害管理だけでなく、仕様書にもExcel脱却が求められている記事があったのでメモ。
ラフなメモ書き。

【参考1】
エクセルで手順書を作るのはきっとやめた方がいい - Qiita

(引用開始)
ある製品のインストール手順書を作ることになり、参考資料として過去の案件で作ったものをもらったのだが、それはエクセルファイルだった。
どういうものだったかを端的に述べると以下の通り。

目次がない
シート名に番号はついていない
各シートにも番号の記載はない
各シートの中身はスクリーンショットの羅列
スクリーンショットについての説明がほぼない
間違った手順のスクリーンショットも混ざっている
操作の結果を確認する手順が漏れているケースがある

この時点で大分げんなりするが、具体的に辛い点をあげる。

1. 全体像が掴めない
2. 順番に確信が持てない
3. コマンドの内容やインストール先のディレクトリもスクリーンショットに埋まっている
4. インストールがうまくいったかの判断材料がない、それを見つけられない
5. 再利用できない
6. 修正したときに差分がわからない
7. レビューするのが困難
(引用終了)

【1-1】一般に、要件定義書、設計書、テスト仕様書などはExcelで書かれている時がほとんどだ。
しかし、Excelのドキュメントは色んな点で弊害が出てくる。

僕の観点では、Excelファイルは構成管理と相性が悪い、という点が最大の弱点ではないか、とずっと思っている。

まず、GitでExcelを管理してもバイナリファイルは差分が分からないので、履歴管理する効果が薄い。
また、GitHubで管理できないと、コードレビューしにくいし、ユーザからのプルリクエストによるフィードバックも受付できない。
つまり、GitHubがもたらしたソーシャルコーディングという手法を適用できず、アジャイルにドキュメントを修正しにくい。

次に、Excelドキュメントは再利用しにくい。
罫線があったり、画像があったり、レイアウトが特殊だったりすると、修正するだけでかなりの手間がかかる。
特に、シートや節を1個追加すると、インデックスや目次が変わってしまうが、じきに誰も保守しなくなる。
すると、Excel設計書の全体イメージが把握できなくなり、ブラックボックスのような仕様書が残るだけ。

結局、共有ファイルサーバーに、いつ修正されたか分からない状態のExcelドキュメントがたくさん散在することになる。

【参考2】
Atom と PlantUML で快適シーケンス図駆動開発ライフ | Developers.IO

(引用開始)
「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。

…3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす?DRYじゃないですねえ。

そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてくれるツールやサービスはたくさんありますが、

描画ツールを使いたくない
差分管理ができないのが辛い
メンテするのがいやだ。どこにあるかわかりづらくなる
というのが私の感想です。
(中略)
テキストで書けると差分管理できるようになる点が良いです。履歴が残ります。GitHubの機能が使えます。つまり、変更に対して レビューをしてもらえ、コメントをもらえます。 描画ツールでやろうとするとレビュー方法に工夫が必要ですし、もらったコメントの管理が大変です。GitHubの仕組みに乗せてしまうことでそのあたりの課題が一気に解決できます。

シーケンス図は強い
UMLには種々の図がありますが、こと設計~開発段階においては シーケンス図 が強力です。どのようなコンポーネントがあって、それらがどうやりとりするかを視覚的に捉えることができるためです。

シーケンス図というとオブジェクトがあって、そのオブジェクトのメソッドを実行すると他のオブジェクトが生成される…といったような図をイメージするかもしれませんが、「コミュニケーションをとりつつ進める設計段階」ではもっと大きな粒度、データベースや、外部APIといった粒度をオブジェクトにします。クラスやメソッドレベルのやりとりはコードで十分表現可能 である一方、コンポーネント間のやりとりは外部仕様として日本語ベースになっている ことが多く、後者はたとえ厳密だとしても可読性が低いです。シーケンス図はそれを補完するのに役立ちます。次の図は「ニュースの一覧を外部から取得してクライアントに返すAPI」のシーケンス図です。
(引用終了)

【2-1】設計書にUMLのシーケンス図を書きたい時がある。
なぜなら、たとえば、詳細設計書で仕様の意図を伝えたい時、オフショア開発チームにコンポーネント間の処理のイメージを伝えたい時があるから。
そんな場合、シーケンス図でラフに描くことには意義がある。

しかし、お絵描きするUMLモデリングツールで出力した画像ファイルを設計書に載せると、仕様変更のたびに修正が発生してしまう。
設計書のメンテナンスという作業に、保守PJではかなりの工数を費やされている場合が多いのではないか。

ここでも、たとえば、UMLのシーケンス図をplantUMLでテキストで残し、GitHubで管理し、設計レビューで使う、という運用が紹介されている。
UMLで描いた設計の絵はテキストファイルで保持できるなら、GitHubに載せることで、プログラミングの時と同じような効果が得られる。

【2-2】下記の記事では、設計書は全てテキストで書き切る、という方法が紹介されている。

AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ

設計書そのものもMarkdownやAsciiDocでテキストで保持しておけば、Jenkinsで定期的にビルドして最新版のドキュメントを出力する、という手法も採用できる。
つまり、設計書もプログラミングと同様に、最近の開発スタイルを適用できるはず。

Redmineに作業内容をチケット起票
→設計書をExcelでなくテキストで作成
→Gitにコミット
→GitHubやGitlabで設計レビュー、再修正してGitにコミット
→Jenkinsで定期的にビルド
→納品時に、タグ付けした版を成果物として納品

「設計書は全てテキストで書き切る」ことにより、設計書も構成管理の配下になり、アジャイル開発の各種プラクティスが適用できるし、その恩恵も受けられる。

また、チケット駆動開発のメリットであるトレーサビリティを設計書の変更管理に利用できるようになる。
そうすれば、システム保守での元々の要件の調査、仕様変更の影響範囲の調査に大いに役立つはず。

【3】ちなみに、Redmineでもmermaidやplantumlのプラグインが提供されている。
RedmineのWikiに、設計概要やノウハウを集約できるので、便利になるはず。

Redmine Mermaid Macro Plugin

Mermaid Macro - Plugins - Redmine

「mermaidプラグインで始める構成図管理」 20171117 redminetokyo13

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ

plantuml - Plugins - Redmine

【4】しかし、仕様書をExcelでなくテキストで全て書いて、ソース管理と同様にGitの構成管理に置くというやり方は、まだ試行錯誤している所だろう。
たくさんの課題がまだ残っているだろうが、いわゆる上流工程でも下流工程と同様に開発プロセスもIT化していくべきだ、という方向性へ進化せざるを得ないと思う。

【追記】
ソフトウェア開発の設計書のExcelテンプレートを公開した記事について、数多くのはてなブックマークが寄せられていた。
ここにも、上記の問題点が背後にあるのだろう。

はてなブックマーク - 無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき

akipiiさんのツイート: "皆苦労してるんだな笑。RT @mandamgame: RedmineのAPI叩いて未完了チケットを表にするExcelください。 / 他154コメント https://t.co/jXdGcJ3iFe “無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき”… https://t.co/MBWCoh8mBQ"

akipiiさんのツイート: "@MadoWindahead @mandamgame いえいえ、Excel設計書のテンプレートなので、PJ毎の設計書が作られるため構成管理すべき対象になります。今の時代は、plantUMLでmarkdown形式でクラス図やシーケンス図で詳細設計書を書いたり、ドキュメントは全てmarkdownで書いた方がGitで管理しやすい、と思います https://t.co/UpnoEEDcbj"

| | コメント (0)

2017/12/16

Friends of astah*になりました

このたび、Friends of astah*になりました。
とても嬉しいです。

【参考】
Friends of astah*

振り返ると、自分は10年以上前からastahを使っていたんですね。

【再考】GanttProjectとFreeMindとJude: プログラマの思索

astah*Professionalファーストインプレッション: プログラマの思索

本格的にastahを使い始めたのは、Redmineによるチケット駆動開発の開発プロセスをUMLで分析してみよう、と思い立って色々描いていた時。
その頃は、アクティビティ図とステートマシン図、配置図がメインだった。

我流のプロセス分析をしながら、色んな気づきがあった。
たとえば、プロセスの例外処理はJavaやVBスクリプトの例外処理に似ているなあ、と思った。
また、プロセスが複雑な理由は組織の構造や権限をそのまま反映しているからだ、と気づいた。
つまり、コンウェイの法則そのままじゃないか、とか。

また、要件定義でシステム構成図、機能構成図、業務フロー、データモデルを書きながら、それぞれのダイアグラムにトレーサビリティという関連があること、粒度を保ちながらレイヤ化という思想で詳細化していく、という発想も身を持って体験できた。

こういう体験は、モデリングツールがあったからこそ、できたのだろうと思う。
なぜなら、Excelやパワポで絵を描くと、ちょっとしたレイアウト変更だけで労力を費やして、本来明示したい設計思想を忘れてしまいがちだから。
また、ダイアグラムを試行錯誤して描くことで、複数の観点でモデルを分析することが自然に身に付くし、各ダイヤグラムのトレーサビリティや粒度を気にするようになるから。

一般に、日本企業では、設計書は日本語という自然語で記述するのが普通。
しかし、日本語では主語が明示されていない、構造が明確化されていない、などの弱点があるので、いくら詳しく書いても必ず漏れる。
巻物みたいなExcel設計書をたくさん書いても、その後のマイグレーション案件では役立たない。

むしろ、A3の1枚用紙に描いたシステム全体概要の方が役立つ時もあったりする。
そんな経験もあって、自分の理解も深めるために、astahを重宝している。

しかし、astahも10年以上使っていると、こういう機能も欲しい、という思いも強くなってくる。
そんな思いも書いてみた。

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

また、XPJUG関西メンバーの後押しもあり、astah関西というコミュニティも立ち上げてみた。
来年度も、Redmineコミュニティと合わせて、色々活動してみたいと思う。

astah関西 第1回勉強会 - connpass

個人的には、ソフトウェア工学の実験ツールであるRedmineと同様に、astahも、ツールがモデリング技術の可能性を高める部分が沢山あると思っている。

ツールがプロセスを改善していく。
ツールが開発プロセスに新たな利用シーン、想定していなかった副次効果をもたらす。
ツールがモデリング技術の新たな可能性を開拓していく。

そんなアイデアを色々考えてみたいと思っている。

| | コメント (0)

RedmineをMSProcjetっぽく使う事例

第2回Lychee Redmineユーザ会で、MSProjectのようなガントチャート運用のようにRedmineを使っている事例の資料があったのでメモ。

Redmineが日本企業に受入れやすい理由の一つは、従来のWF型開発でガチガチのガントチャート管理をチケット管理で実現しやすいためだろう。
なぜなら、親子チケットで階層化すれば、WBSをそのまま実現できるからだ。

しかし、Redmine標準のガントチャートでは、予実管理までの機能はなく、MSProjectに付随しているベースライン管理、リソース管理、PERT図のような機能まではないから、MSProjectをバリバリ使っているプロジェクトリーダーの観点では不満があるだろう。

上記の資料では、Lycheeガントチャートという有償プラグインを導入することで、MSProjectの大半の機能をRedmine上でも同様に利用することで運用しようとしている。

興味深い点は3つある。

一つ目は、 開発プロセス用トラッカーは、測定項目を共通化し4種類に集約していること。
明示されていないけれど、分析、設計、実装、検査の項目と思われる。
一般にプロセスをトラッカーにするのはあまり推奨されていないけれど、小規模チームならば問題ないと思う。
個別PJだけのチケット管理の運用ルールに特化しているから。
つまり、チームの運用に合わせるようにRedmineを当てはめて、タスク管理をスムーズに実行することを目的としているから。

2つ目は、チケットの基本項目や測定項目を全て必須入力とし、工数、検査項目数、NG数などの入力漏れを無くし、 承認待ちステータスを入れて責任者が最終確認して完了する運用を徹底したこと。
たぶん、完了したタスクに対し、設計プロセスで仕様漏れが発生していないか、その仕様漏れが後工程まで引きずっているか、というメトリクスも収集し集計したい意図があるのだろう。
特に、組込み製品開発では、後工程の手戻りがあるとコスト増加に大きく響いてしまうから。

また、承認ステータスを入れることで、「いつの間にかタスクが完了していた」という事態をなくせる。
おそらく、必ずプロジェクトリーダーの承認を経てタスクをクローズする運用を徹底することで、当初の計画通りに成果物が作られたのか、という検査をきちんと記録に残すことができ、システム監査で説明できる資料にしたいためだろう。

3つ目は、 ベースライン保存機能で保存したスケジュールのスナップショットと、現在のスケジュールを同時表示 し、スケジュール変更前後を比較可能とし、打ち合わせ時にチケット棚卸しを実施していること。
MSProjectでは、基準計画という機能があり、たとえば顧客都合の仕様追加でリスケが発生したら、リスケ前とリスケ後のスケジュールを別々の保持する機能がある。
この機能を使えば、リスケ後に、顧客に、これだけの工数が追加したので別請求で代金を支払って下さい、と請求できる根拠を示せる。
また、開発者にも、リスケ後にこれだけ工数が追加で発生したと説明できるし、どれだけの実績工数の差異が発生したのか、を追跡できるようになる。

一般に、受託開発案件は一括請負契約が多いので、こういうスコープ変更に伴う追加代金の請求の根拠となる資料はとても重要だから。

上記の資料ではオフショア開発にRedmineを展開していたようなので、資料に書かれていない内容でたくさんの苦労があったのではないか、と勝手に想像する。

こういう資料を読んでいると、日本のSIではPJ管理にすごく苦労しているんだろうな、と感じる。
資料の背後に隠されている泥臭い作業をイメージできてしまうから。

できれば、開発チームのメンバーのフィードバック、開発チームや開発プロセスの効果も聞きたかかったな。

Redmineがそういう作業を全て解決できるか否かは分からない。
でも、そういうPJ管理の問題点が見える化されることで、根本原因は何か、真の解決策は何か、を考えるきっかけになる気はする。
そういう問題点、根本原因を明確にすることで、解決策がメンバーと共有されて、解決されていくと思うから。

| | コメント (0)

Redmineの普及促進にはRedmine警察やRedmineマイスターという役割の人達が必要

打ち捨てられていたRedmineが復活するまでの軌跡 - Qiitaという記事で、Redmine警察とRedmineマイスターが共同でチケット運用する方法が書かれていたのでメモ。
非常に分かりやすい。
感想をラフなメモ書き。

【参考】
打ち捨てられていたRedmineが復活するまでの軌跡 - Qiita

【1】上記の記事で気になったポイントはいくつかある。

一つ目は、チャットツールとRedmineの使い分けや連携方法に関するノウハウを持つべきこと。
二つ目は、「Redmine警察」「Redmineマイスター」という役割の人達が、Redmine運用の浸透に欠かせない、という点に早く気づくこと。

【2】チャットツールに依存しすぎるとRedmineが使われなくなるし、技術や仕様のノウハウがチャットに埋もれてしまい、ナレッジとして蓄積されない問題は、東京Redmine勉強会でも話題に上がっていた。
しかし、現在の開発現場では、Slackのようなチャットツールは普通だし、必須だろう。
チャットツールを無くすことは不可能。

上記の記事でも、下記の問題点があげられていた。

(引用開始)
チャットに情報が集約されることの問題点
この状況の一番の問題は、重要なコミュニケーションが全てチャットのタイムライン内に散逸してしまうことです。これにはいくつものデメリットがあります。

異なるトピックがランダムに折り混ざり、問題の切り分けがしにくい
古いトピックの状況や結論を忘れる
メンバー外への情報共有がはかどらない
(引用終了)

そこで、いくつかの対策を講じている。
チャットツールとRedmineの使い分けのルール策定はもちろん、チャットツールとRedmineを連携するプラグインを導入して、Redmine→チャットという情報の流れを作っている。
Redmineにノウハウを集約するのは大事だが、チャット文化を否定するのではなく、情報が一元化されたRedmineからチャットへ情報を流してチャットも有効活用する、という方針は、この問題の一つの解決策だろう。

sciyoshi/redmine-slack: Slack notification plugin for Redmine

hokkey/redmine_chatwork: A Redmine plugin to notify updates to ChatWork rooms

【3】「Redmine警察」「Redmineマイスター」を導入している、という話は、Redmineの普及促進には、社内にRedmineエバンジェリストと言うべき役割の人達が必要である、という事実を示唆していると思う。

(引用開始)
僕は今LIGでフロントエンドエンジニアとして働いていますが、同時に社内随一のRedmine警察であることも自負しています。

LIGではプロジェクト管理ツールとしてRedmineを導入していますが、僕の入社当初はほとんど打ち捨てられたも同然の状態で放置されかけていました。そのような状況をどうやって改善し、社内にRedmineの運用を浸透させていったかについて、経緯や施策を説明します。
(引用終了)

(引用開始)
Redmine警察としてみんなの運用の相談にのる
「この案件のタスクはどんな粒度で起票すれば良いか」「バージョンと子チケットの棲み分けはどうするべきか」といった微妙な問題があれば、立ち話で相談に乗るようにしています。また、ITSの運用に慣れている同僚をRedmineマイスターに認定し、Redmine警察と共同でチケット運用の普及に努めています。
(引用終了)

たとえば、以前、@sakaba37さんが、CMMI運用の頃にも、CMMIの普及とレベル向上には、プロセスチャンピオンという名の役割の人が必要、と話されていた。

[#xpfes12] 先駆者の集まりから、プロセス・チャンピオンの集まりに - XP祭り関西2012 -: ソフトウェアさかば

また、以前の東京Redmine勉強会の講演でも、社内にRedmineエバンジェリストがいたから、すぐにAWSにRedmineを環境構築してくれて、ベストプラクティスも持っていたから、すぐに運用を開始できた、という話もあった。

RedmineがIoT企業に異常にマッチしてしまった話 - 僕のYak Shavingは終わらない

(引用開始)
ただここで大事なことを言っておくと、やはり導入にはRedmineエバンジェリストみたいな人が必要だと思います。 正直いなかったらやってなかったですね。
(引用終了)

その話と同様に、Redmine警察としてRedmineの運用を見張る(笑)、Redmineマイスターとしてチーム内の質問に対応する、という役割の人達がたくさん必要なわけだ。

そう言えば、BTSを使っていなかった頃、ある案件の結合テストフェーズで、開発チームのリーダーは特に何も担当せずに自由に開発者の相談やフォローに乗る役割を担っていた時があった。
そんなリーダーは、開発メンバーから、ポリス(警察の人)みたい、と言われていたのを思い出した。

Redmine警察も似たような役割かな。

【4】「Redmineが社内になかなか普及しない」と嘆く現場では、たぶん、Redmineエバンジェリスト、Redmine警察、Redmineマイスターのような人達がいないか、そういう役割を担う人が少なすぎるのだろう。

僕は、各部署に品質保証担当の人がいるならば、彼にRedmine警察やRedmineマイスターを名乗る役割を与えて、普及促進に務める、という組織的対応も必要だろうと思う。

スタッフ部門だけがRedmineを促進しようとしても難しいのではないか。
また、Redmineエバンジェリストとは言えなくても、Redmine警察やRedmineマイスターを社内に育成することは可能ではないだろうか?

結局、人を通じてしか、プロセスは変えられないから。

【追記】
Redmine警察はお巡りさんのイメージ。

akipiiさんのツイート: "@MadoWindahead お巡りさんのように見回る人もいるでしょ笑 PMOがそんな役回り?"

門屋 浩文さんのツイート: "@akipii そんな役回りです 必要! 損な役回り(嘘"

@madowindaheadさん主催の「redmineエバンジェリストの会」でも議論してくれるだろう、と勝手に期待してる。

redmineエバンジェリストの会発足! | MadosanPlace 新しい風をプラス!

| | コメント (0)

2017/12/13

Redmineにおけるトレーサビリティの課題は何か?

Redmineにおけるトレーサビリティの現状と課題について考えたことをメモ。
ロジカルでないラフなメモ書き。

【参考】
現場の声からプロセス改善を深掘りする(3):要求から成果物へのトレーサビリティ (1/2) - MONOist(モノイスト)

保守性・拡張性に優れたシステムを作る(11):キミの設計に「トレーサビリティ」はあるか (2/2) - ITmedia エンタープライズ

アジャイルプロジェクトにおけるトレーサビリティ・マトリックス

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

チケット駆動開発におけるトレーサビリティのチートシート: プログラマの思索

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

アジャイル開発と要件管理: プログラマの思索

日本でモデリングツールが使われない背景: プログラマの思索

【1】ソフトウェア開発におけるトレーサビリティがいかに重要であるか、という点は、システム開発をやっている人なら痛感しているはず。

たとえば、チケット駆動開発の最大のメリットはトレーサビリティだ、という意見がRedmineによるタスクマネジメント実践技法 - プログラマーな日々で紹介されている。
派生開発や、受託開発で本番リリース直後の混乱を経験している人ならば、納得するのではないか?

(引用開始)
チケット駆動開発の効用は、何といってもトレーサビリティ(追跡可能性)の確保だろう。

ソースの変更と変更理由の結束の保証。
一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。
顧客の「いつどんな理由でこの変更をしたのですか?」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。

問題は導入コストだろう。
この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感じた。

段階的導入は可能だろうか?
まずはタスクのワークフローとして使ってみるとか。導入コストは非常に大きな問題だ。
どうにかしてメンバーが前向きに取り組めるようにしないと、やらされていると感じているうちは導入は遅々として進まないだろう。

結論。開発者はもちろん、マネージャにこそ読んでほしい本だ。
(引用終了)

しかし、チケット駆動でトレーサビリティを実現できる基盤がある、と言っても、それを効果的に運用できるか否かは、その組織の成熟度に大きく依存している。

【2】トレーサビリティの利用シーンを洗い出してみる。
トレーサビリティが保証された開発プロセスでは、下記の利用シーンで大いに役立つはず。

【2-1】コードレビュー

Redmineならば、チケットにソース修正履歴があるので、レビューで修正箇所を追跡できる。
機能単位、障害単位にコードレビューしやすい。

【2-2】バグ修正や仕様変更時に、過去の要件を探る

修正対象のソースにある複雑に混み入ったIF文を勝手に修正してよいか?
本番リリース直後の混乱時に、沢山の人のパッチが当たって、何とか収束したパッチなのに、勝手に手を入れてよいのか?
意味不明なパッチにも実は過去の障害修正を引き継いでいる。
触らぬ神に祟りなし。
Redmineならば、仕様変更で修正するソースの修正履歴にチケットNoがあるので、過去の要件と仕様確定の理由を探って、修正要否を判断できる。

【2-3】顧客問合せで、現状の機能や要件の経緯を調査する

この機能はなぜ実装されたのか? という顧客問合せ。
Redmineならば、全文検索して、チケットから要件と要件確定の経緯を探れる。

【2-4】リリース履歴として公開する

Redmineならば、リリースバージョン→チケット→ソースへドリルダウンして、成果物のソースまで追跡できる。
顧客に説明しやすくなる。
リリース後の保守作業で、開発メンバーもシステムの変更履歴を探しやすくなる。

【2-5】仕様変更のインパクト分析

仕様変更があった時、関係する機能はどれくらいの影響を受けるのか?
対象ソースを直したら、修正が発生するソースの範囲、デグレしていないことを確認すべき回帰テストの対象機能の範囲はどれくらいか?
つまり、インパクト分析で使いたい。

【2-6】トレーサビリティマトリクスの元ネタ

原理的には、縦軸が要求、横軸が機能のトレーサビリティマトリクスを出力できる。
トレーサビリティマトリクスがあれば、派生開発でソース修正を行う時、どれくらいの修正箇所があるのか、影響を受けるソースはどれだけか、回帰テストすべき対象範囲はどれくらいか、を把握できる。
たとえば、XDDPのトレーサビリティマトリクスも、原理的にはRedmineから出力できるはず。

古いプラグインだが、下記のイメージ。

Traceability matrix - Plugins - Redmine

また、トレーサビリティマトリクスを使えば、テスト工程における要件カバレッジやテストカバレッジにも利用できる。
テスト工程の中盤で、どの範囲の要件はテストで品質が保証されたか、テストで網羅できた機能や成果物はどれだけの範囲なのか、を把握できる。
しかも、時系列でトレーサビリティマトリクスや要件カバレッジ、コードカバレッジを出力できれば、品質保証の範囲の時系列の変化を見ることができて、有意義なはず。

【2-7】成果物そのものから、成果物の変更履歴を除去できる

昔は、Excel設計書の修正のたびに変更履歴を追記したり、吹き出しを書いたりしていたが、そういう変更履歴はGitのような構成管理ツールがあれば不要。
変更履歴のようなメタ情報は、構成管理ツールで管理すべき対象だから。
よって、設計書やソースから変更履歴のようなガラクタのコメントは除去されて、最新版で状態維持されているので、成果物がシンプルになる。

SCMコミットログはファイルのメタ情報: プログラマの思索

【3】しかし、トレーサビリティの実現はやはり難しいと思う。
以下、トレーサビリティの課題をあげてみる。

【3-1】トレーサビリティの保証は、手動の運用ルールだけで十分か?

チケット駆動開発の運用ルール「No ticket, No Commit」が徹底されているならば、チケット経由で「要件→チケット→成果物(ソース・設計書)」のトレーサビリティが実現される。
その運用を支える基盤は、構成管理ツール連携というRedmineの一機能で実現できている。

しかし、スキルの低いメンバーでは関連付けの意識が薄く、徹底できない場合も多い。
コミットログに書かれたチケットNoが間違っている時、漏れている時はないか?

但し、Redmineでは、コミット後に関連づけを編集する機能があるので、トレーサビリティを正しい状態へ修正する方法は残されている。

Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

トレーサビリティは自動で生成できるか?
AIを使ったり、機械学習を使ったり、とか。

でも、自動生成されたトレーサビリティが本当に全て正しいの?という疑問がいつもある。
経験上、自動化しても多分あまり意味がないと思う。
モデル駆動開発におけるソース自動生成のアンチパターンと同じ。
自動生成に頼った運用は、メンバーのモチベーションを高めないから。

【3-2】トレーサビリティを実現する他の方法はあるか?

最も簡単かつ、今後発展性のある機能は、全文検索機能だ。
実際、アジャイルプロジェクトにおけるトレーサビリティ・マトリックスの記事でも「バージョン管理ツールや変更をトラッキングするツールを使用せよ」だけでなく、「シンプルな検索ベースのトレーサビリティ(「Googleで検索するだけ!」)」が紹介されている。

Redmineなら、全文検索プラグインを使うのが一つの解決方法。

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

Redmineでもっと高速に全文検索する方法 - ククログ(2017-09-25)

全文検索プラグインでは、チケット画面に類似チケットが表示される機能がある。
類似チケット機能は、Redmineというシステムそのものがトレーサビリティを補完する機能と見なすこともできる。
さらに、チケットにスマートフォンのスマートナビのような機能が実現されれば、面白いだろう。

【3-3】チケット関連図を作りたい

要件→チケット→ソースのマップが見たい。
つまり、Lycheeのチケット関連図のような機能がRedmineに欲しい。
この機能は、後方追跡性に相当する。

チケット関連図 | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

利用シーンとしては、仕様変更のインパクト分析で使いたい。
たとえば、セキュリティ強化に関する要件に紐づく機能から、実装すべき機能チケットやソースへ追跡して、ソースの修正量、開発工数を測定したい。
そこから、修正見積りに使いたい。

また、プロセス保証にも使いたい。
たとえば、機能安全に関する要件に紐づく機能は本当に実装されているのか、作成された設計書やソースを追跡して、成果物に漏れがないことを確認したい。
そこから、製造物責任法や機能安全規格に関する要件を満たしていることを説明したい。

実現方法としては、親チケット=要件、子チケット=タスク、リビジョン=成果物の変更スナップショット、で対応付けできれば良い。
その後、要件→チケット→ソースのリビジョンのツリー構造の絵、つまりチケット関連図を紙で出力できればいい。
また、それら要件は、リリースバージョンでグルーピングすれば、ロードマップ画面がそのままリリース履歴になる。

しかし、いくつか問題も出てくる。
大規模な要件の場合、チケット関連図にあるツリー構造は非常に複雑になるだろう。
A3の紙1枚に収まらないかもしれない。
そうなると、漏れがないのか、確認するのも大変だ。

つまり、要件となる親チケットをグルーピングしたチケット関連図が欲しくなる。
その場合、どんな内容を出力すればいいのか?

一方、ソース→チケット→要件への前方追跡性はどう実現するか?
利用シーンとしては、手を入れるソースを元に影響するソースの範囲、要件の範囲を知りたい。
そこから、ソースの修正量、回帰テストの範囲、修正工数を測定して、見積りに使いたい。
これも一つのインパクト分析。
むしろ、リスク分析にもなる。

派生開発や保守案件のリーダーにとっては、前方追跡性の方が重要だろう。
見積り作業の効率化に直結するからだ。

Lycheeのチケット関連図には、そこまでの機能はないみたい。

【3-4】トレーサビリティマトリクスを作りたい

トレーサビリティマトリクスを作っても、要求や機能の項目が多くなると、A3の1枚資料に収まらなくなる。
要求チケットやソースが多すぎると読みにくくなる。
だから、要求や機能をカテゴリ化する必要が出てくる。

これもチケット関連図の問題点と同じ。

【3-5】チケット関連図やトレーサビリティマトリクスのスナップショットを保持したい

従来は、チケット関連図やトレーサビリティマトリクスを手作業でExcelで作っていた。
しかし、仕様変更やリリースが増えるたびに、これらExcel設計書の保守コストがすごく大きくなる。
度重なる仕様変更を要件管理で反映することすら大変なのに、チケット関連図やトレーサビリティマトリクスを保守するのはもっと大変だ。

本来は、Redmineのようなツールが、チケット関連図やトレーサビリティマトリクスをいつでも欲しい時に自動生成すべきだ。
なぜなら、Redmineにトレーサビリティに関する情報は全て一元管理されているからだ。
それらは、手作業で保守して維持すべき成果物ではない。

一般に、チケット関連図やトレーサビリティマトリクスは、リリースバージョンの単位でスナップショットを残し、記録していくのが良いだろう。
つまり、リリース履歴と一緒に、チケット関連図やトレーサビリティマトリクスも出力されて、要件カバレッジやコードカバレッジも出力できる。
そうすれば、リリースのたびに、システムの要件や機能が時系列でどのように増えていっているのか、その変化を見ることもできるだろう。
たとえば、今回の仕様変更で機能やコード量が大幅に増えたね、とか、一目で分かるはず。

【4】以上のように、Redmineにおけるトレーサビリティの課題を思いつくままあげてみた。
おそらくRedmine標準の機能だけでは、トレーサビリティに関する運用は不十分だろう。

しかし、Redmineによるチケット駆動開発に埋め込まれている「構成管理ツール連携」「全文検索」という機能には大いに可能性が秘められていると思う。
Redmineという一つの箱に全てのデータが一元管理されて集約されているのだから、チケット関連図やトレーサビリティマトリクスのような要望は、チケット集計するだけのRedmineの一プラグインとして実現できるはずだ。

また、全文検索プラグインが提供する「類似チケット」のような機械学習の機能は、もっと色んなアイデアで発展できる余地がある。
Redmineのデータマイニングは、所詮はテキストマイニングに過ぎないのだから、現在のライブラリを流用して色んなことができるはず。
自分たちの会社のRedmineに蓄積された作業ログはその組織文化に依存しているのだから、その会社特有の隠語やコンテキストを事前に把握できれば、効率的に機械学習できるはず。

アイデア段階にすぎないが、トレーサビリティにまつわる機能は、Redmineがあるからこそ、その利用シーンや実現可能性を色々考えることができる。

従来は手作業でトレーサビリティに関する成果物を作成していたが、これがRedmineというツールで手軽に実現できるようになると、開発プロセスにどんな効果を与えてくれるのか?
Redmineによるトレーサビリティのプロセス基盤は、CMMIレベル4やレベル5のようなプロセス保証をどこまで、低コストで実現してくれるのか?

色々考えてみたい。

| | コメント (0)

2017/12/09

日本のRedmineコミュニティの活動報告と今後の抱負

Redmine Advent Calendar 2017 - Qiitaに初参加です。
日本のRedmineコミュニティの活動報告と今後の抱負を書きます。

私が書くのは恐れ多いと思いますが、改めて、Redmine大阪スタッフとredmine.tokyoスタッフの皆さんに大変感謝です。

【参考】 Redmine Advent Calendar 2017 - Qiita

【1】日本のRedmineコミュニティ

現在活動中の日本のRedmineコミュニティは、Redmine大阪とredmine.tokyoの二つがあります。
Redmineは誕生して11年も経ちますが、どちらのRedmineコミュニティも2011年に創立されたので割と浅いです。

Redmineの9年間の歩みを振り返ってみる

Redmine 10周年記念 10年ふりかえり

私はその二つのコミュニティでスタッフとして関わっているので、その立場から生い立ちとその歴史を簡単に振り返ります。

【2】Redmine大阪

Redmine大阪 - connpass

RxTstudy

過去のイベント - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

【2-1】勉強会の発端は、2011年6月に、@pinkmacさんが「【緩募】関西でRedmineをタスク管理に使いたい勉強会を開催したら参加/発表してみたいという方!」というTwitterが流れたことです。
あっという間にスタッフや講演者、参加者が集まり、「RxTStudy~Redmineとタスクマネジメントに関する勉強会」というコミュニティとして発足しました。
「RxTStudy」は「Redmineとタスクマネジメント(Task)に関する勉強会(Study)」という意味です。

その後、Redmineが日本で知名度が上がる中、「RxTStudy」という名前では分かりにくいという声があったため、2016年に地域名を付けた「Redmine大阪」にコミュニティ名を変更して、今に至っています。

【2-2】第1回目の経緯は下記に書いています。

【告知】Redmineでのタスク管理を考える勉強会@大阪で発表します #RxTstudy: プログラマの思索

記念の1回目の勉強会は、その頃にRedmine本を出版した前田剛さん、倉貫さん、阪井さんと僕が講演したこともあって、定員50人があっという間に埋まり、当日の模様がUStreamで中継されてたいへん盛り上がったことを覚えています。
また、僕が講演した内容「RedmineのFAQとアンチパターン集」は、当時はすごく反響が大きかったことを覚えてます。

それから、最近は年2回ペースで開催され、現在は17回まで続いています。

【2-3】勉強会の内容は、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)@daipresentsさんの「チームにRedmineを適用せよ! #RxTstudy」では、楽天における1000人という当時は大規模なRedmine利用事例でした。

(2)@akahane92さんの「情報システム部門のタスク管理とIT全般統制 ~ Excel管理からの脱却 ~ (ITS Redmine #RxTstudy #5)」では、島津製作所の基幹系業務システムのタスク管理とIT全般統制にRedmineを導入して運用して効果を上げている事例でした。
その後、JaSSTやSQIPなどでも講演されて一躍有名になりましたね。

(3)陸野さんの「Redmineの活用事例‐多様なプロジェクト管理に対するツールの適用」では、パナソニックにおける組込みソフトウェア開発にRedmineを導入運用した事例でした。
従来まで数多くのプロジェクト管理のパッケージ製品を導入してきたけれど、パッケージ製品には販売元の会社のプロセスが埋め込まれていて、自分たちの組織に合わない、という指摘に改めて刺激を受けたことを思い出します。

(4)JAXAの藤田さんの「JAXAスパコン"JSS2"の運用を支えるチケット管理システム"CODA"」では、JAXAスーパーコンピュータ活用課にて、業務の管理にRedmineを利用している事例でした。
実際のRedmine画面を見ることができて大変貴重でした。

(5)@ktouさんの「全文検索でRedmineをさらに活用!」では、Redmineの全文検索の機能強化と今後の可能性に関する事例でした。
Redmineに機械学習や人工知能などの技術を組み込むと、新たな可能性が広がる、というワクワク感が満載でした。

【3】redmine.tokyo

概要 - redmine.tokyo

【3-1】勉強会の発端は、僕がちょうど東京にいた頃、東京にいる熱心なRedmineユーザが集まって、勉強会を開こう、という話があがったことでした。
2011年当時は、@nobiinu_andさん曰く「東のTrac、西のRedmine」と言われるぐらい、東京ではTracコミュニティが活発だったので、Redmineもコミュニティが欲しいなあ、という雰囲気があったためです。

Shibuya.trac Wiki - Shibuya.trac - OSDN

nobiinu_andさんのツイート: "ですね! USTあるとイイなぁ… 実は東のtrac、西のredmineという状況だったりして RT @akipii: @nobiinu_and Redmineでのタスク管理を考える勉強会@大阪で議論できると思います。http://t.co/X2o1jPF #RxTstudy"

たしか、キックオフ飲み会が暑い8月に行われた時、当時はRedmineで唯一の日本人コミッタである@marutosijpさんも来られて、Redmineを話題に盛り上がったのを思い出します。

記念の第1回目の勉強会は、IPAで場所をお借りして開催されました。
第1回目の内容は、下記に書いています。

【告知】第1回品川Redmine勉強会を開催します #47redmine: プログラマの思索

当初は「品川Redmine」という名称でしたが、参加者から限定的なコミュニティのイメージを持たれることもあり、2014年から地域名を付けた「redmine.tokyo」にコミュニティ名を変更して、今に至っています。

それから、ほぼ年2回ペースで開催され、現在は13回まで続いています。

【3-2】勉強会の内容は主に、講演が数本、ライトニングトークスやグループディスカッションです。

redmine.tokyoの最大の特徴は、参加者がすごく多い点でしょう。
@naitohさんがまとめてくれているアンケート資料「Redmine.tokyo 13 questionnaire」を見ると、過去は参加者が100名超えの時もありました。
よって、いつも大変盛り上がっているのが印象的です。

また、@tkusukawaさんたちがボランティアで、UstreamやYoutubeで講演をリアル放映してくれています。
そのおかげで、いつも満員御礼になっているにも関わらず、参加できなかった人や東京以外の地方のRedmineユーザも視聴できます。
いつもありがとうございます。

【3-3】勉強会の内容はRedmine大阪と同じく、Redmineの利用事例からRedmineのカスタマイズ方法、最新バージョンの機能紹介など多岐にわたります。
今までの中で、僕の記憶に残る主な講演は下記かな。

(1)Takashi Okamotoさんの講演「RedmineとGitとスクラム」では、当時最新の使い方であったRedmineとGit連携の事例でした。

(2)@akahane92さんの講演「Redmineチューニングの実際と限界 - Redmine performance tuning」では、100万チケットでも耐えれるRedmineのチューニングノウハウの紹介でした。

(3)@netazoneさんの講演「ある工場のRedmine +(Plus)」では、製造業におけるRedmineの運用事例でした。
当時の環境では、プラグインが23個もあるのが驚異的でした。

(4)@onozatyさんの講演「View customize pluginを使いこなす」では、View customize pluginによるRedmineのカスタマイズ事例でした。
この発表後、View customize pluginの利用が広まったように思います。

(5)@kazuphさんの講演「IoT企業とRedmine // Speaker Deck」では、IOT企業のハード製造部門とソフト開発部門、サポートデスクの3部門におけるRedmine利用事例でした。
かんばんとガントチャートを使い分けている点が興味深ったです。

(6)JAXA木元さんの講演「CODAの定義・運用の現在 - 2017年版 -」では、JAXAにおけるRedmineのノウハウを惜しみなく公開した事例でした。

【4】参加している人たち

【4-1】参加者は、実際にRedmineを使ってプロジェクト運営しているSIのプロジェクトリーダー、Redmineのパッチを作ったりプラグインを開発する人達、SIでRedmineのサーバーのインフラを管理する人、などが多いです。
さらに、参加者層を分析すると、開発プロセスに興味がある人たちだけでなく、Redmineのパッチを作ったり、プラグイン開発者が割と多いことが特徴的だろうと思います。

つまり、素のRedmineを運用してみて不足している機能はプラグインで開発して、それをGithubで公開されている人が多いように感じます。
たとえば、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさんたちです。
また、@naitohさんのように、PDFの日本語化Gemを開発して貢献されている方もいます。

【4-2】Redmineコミュニティに携わるスタッフの立場では、プロジェクト管理や開発プロセスに興味を持つ人たちだけでなく、Redmineの機能強化につながるプラグイン開発者は非常に重要と思います。
なぜなら、Redmineの不足機能をプラグインで代替できるようにオープンソースで提供してくれているからです。

そのおかげで、ユーザはRedmineを自社の組織文化に合わせてカスタマイズすることが容易になります。
つまり、ユーザ自身が設計したプロセスへツールを合わせるように運用しやすくすることで、自然にプロセス改善の雰囲気がチーム内に発生し、チーム自身で問題解決していくという自律化の雰囲気を醸し出すメリットもあるのだろう、と感じるからです。

【4-3】最近は、勉強会の参加者層は幅広くなったように感じています。

グループディスカッションで聞いてみると、IT業界に限らず、製造業やゲーム業界、Webデザイン業界、など幅広い業界の人たちが参加しているようです。
また、Redmineを長年使っている人たちだけでなく、PMOや品質保証部に在籍する上層部の人や、興味があるから来てみたという初心者も増えているようです。

背景には、Redmineが日本でかなり知名度が上がり、実際に使われている場面が多くなっているからでしょう。
実際、日本国内におけるGoogleトレンドを見ると、現時点ではTracやJiraよりもRedmineが上位に上がるケースが多いようです。

Redmine 10周年記念 10年ふりかえり

【5】今後の抱負

Redmineコミュニティに携わるスタッフとして、今後の個人的な抱負は2つあります。

【5-1】一つ目は、Redmineコミュニティの参加者の多様化を図る事です。

Redmineが持つ特徴として、二つの側面があります。
まず、プロジェクト管理を柔軟に運用できるプロセス基盤または、ソフトウェア工学の理論を実験できるメトリクス収集・集計基盤であること。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」

次に、汎用的なプロジェクト管理ツールの開発基盤であること。

第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」

すなわち、Redmineの利用者層は、前者の観点では、プロジェクトリーダーやPMO、品質保証部のような立場でプロセスを構築し運用する人達である一方、後者の観点では、プラグインを開発したりRedmineをカスタマイズするRuby開発者という二つの側面があるのです。
そして、その両方に詳しい技能を持つ人は非常に少ないでしょう。

よって、全く異なる技能を持つ人達が集まることで、プロジェクト管理やソフトウェア工学で困っている問題がプラグインやカスタマイズで解決できたり、新たなプラグイン提供によってプロジェクト管理の新たな使い方が生み出されることもあるでしょう。
つまり、プラグイン開発者とプロセス管理者がお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展できるはずと考えます。

そういう化学反応、シナジー効果を提供する場を構築したいと考えてます。

【5-2】2つ目は、Redmineのエコシステムを作る事です。

日本の企業でRedmineがかなり普及している現在、Redmineは日本のSIにおける事実上の基幹業務システムではないか、と思います。
すると、Redmineは今後も安定的に機能改善されて保守されて欲しい。

幸いなことに、Redmineの歴史をたどると、自動テストが整備されたおかげで、RubyやRailsのバージョンアップにも追随しており、セキュリティパッチも早急に対処されています。
そのおかげで、Redmineの品質は割と高いのではないか、と思います。

Redmine build status

Redmine code coverage

また、性能面でも、Redmine大阪第17回勉強会に参加した - Basicに記載あるように「機能が増え続けるRedmineの処理の重さを、RubyやRailsの足回りが地道に改善してカバーしている」ように進化しています。

しかし、現在のRedmineのコミッタはJPLを含めて3人しかいない。

今後の夢としては、オープンソースの成功事例であるLinuxやRubyのような永続的なオープンソースとして確立して欲しい、と思っています。

たとえば、LinuxやRubyも当初は、開発者のおもちゃと見なされて、エンタープライズでは使えない、と思われた時期もありました。
しかし、コミュニティが発展してマーケットが広がっていくうちに、エンタープライズ界隈にも広がり、今ではむしろ、オープンソースで無いと保守され続けなくなるリスクがあるように見受けられます。
そして、LinuxやRubyも、コミッタと熱心なユーザだけでなく、ベンダーもユーザの一部として加わり、マーケットが拡大する方向へ成長している状況があります。

よって、RedmineもLinuxやRubyのように、コミッタ・ユーザ・ベンダーの三者が良好な関係を保ち、成長のらせん構造を昇っていけるような環境をいつか作りたい、と思っています。

| | コメント (0)

2017/12/04

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿

astahを使いながら、モデルの粒度とトレーサビリティのあるべき姿について考えたことをメモ。
以下は、最終的には、astahへの改善要望になるだろう。
ラフなメモ書き。

【参考】
astahによるモデリングのメモ: プログラマの思索

派生開発における変更指示をモデルで表現する(問題編) - Qiita

【1】個人的には、astahは好きだ。

astah* オンラインマニュアル

理由は2つある。
一つ目は、他のモデリングツールに比べて、操作が直感的でサクサク描けるから。
astahでUMLのダイアグラムを書く時に、迷うことがないし、サクサク描けるので、アイデアが無くなることも少ない。
一方、他のモデリングツールでは、UMLの各種ダイアグラムを描く時に、どうやって書けばいいんだっけ、と迷う時間が多いと、その間にアイデアは消えてしまう。
また、線を引っ張る時、保存する時にプログレスバーが出て待たされるようでは、イライラしてしまう。

二つ目は、一つのモデルを複数の観点で分析する考え方が自然に身につくことだ。
UMLでは約7種類、他にER図やDFD、マインドマップもあるので、一つのシステム像を表現したい時、静的なモデルだけでなく、動的なモデル、物理的な配置図、論理的なモデル、DOA的な視点、などでも自然に考えるようになる。
複数の観点でシステムの要件や機能を考えることによって、モデルの整合性やトレーサビリティにも気づきやすくなる。

そんな経験をしながら、モデリング技法のあるべき姿について考える時がある。
astahで色々書いていると、まだ何か足りない気がしてくるのだ。

【2】では、astahでモデルを書いていて、何が足りないと感じるのか?
不足していると感じる観点は、モデル間のトレーサビリティと粒度、変更管理に関する内容だ。

【2-1】モデル間のトレーサビリティ

たとえば、要件定義フェーズで、業務フローをアクティビティ図で描いて分析したら、その後、どこをIT化すべきか、という方向に分析が進む。
すると、業務フロー図に出てくるアクターがシステムである箇所で、アクティビティがあれば、そのアクティビティがユースケースに対応付けられる。
それらユースケースを集めると、ユースケース図になり、システムの全体像が定まる。

つまり、業務フローの各アクティビティ→ユースケースへの詳細化が後方追跡性に相当する。

また、各ユースケースは、論理モデルや実装モデルの観点で、クラス図やシーケンス図に分解されていく。
つまり、ユースケース図の各ユースケース→クラス図、シーケンス図への詳細化という後方追跡性が発生する。

しかし、アクティビティ図→ユースケース図→クラス図、シーケンス図へトレーサビリティが発生するのに、それらモデルのトレーサビリティを表現する方法がastahでは直感的に表現されていない。

モデラーの観点では、アクティビティ図のアクティビティをクリックしたら、対応するユースケースに遷移して、さらにユースケースをクリックしたら、対応するクラス図やシーケンス図を選択して表示される、という利用シーンを実現して欲しい。
そうすれば、要件定義→設計へモデルが詳細化されていく作業をトレーサビリティの機能によって補完することができる。

では、なぜそんなにトレーサビリティが必要なのか?
なぜなら、モデル間のトレーサビリティを考えることで、モデル要素の漏れや矛盾に気づきやすくなり、モデルの精度を上げられるからだ。
おそらくどのモデラーも、概要レベルのモデルを描いた後で、詳細化したモデルは別に描き、それらの整合性をどこかで考えているはず。
そういうモデル間の整合性を考える作業を支援する機能が欲しいのだ。

一方、現状のastahでトレーサビリティに相当する機能は、ハイパーリンク機能に相当するだろう。
つまり、モデル要素のリンク機能で十分だ。
モデル要素をクリックしたら、別のモデルへ遷移するように、ハイパーリンク情報を設定すればいい。

しかし、ハイパーリンク情報を設定するには、詳細画面を開き、遷移先のモデルを選択して更新する、という操作が発生し、とても面倒。
この操作を1クリックで操作できるようにしたい。
つまり、遷移元のモデル要素(ダイアグラム)を遷移先のモデル要素にドラッグ・アンド・ドロップすると、自動で相互リンクするようにハイパーリンク情報が設定される、といったイメージだ。
たとえば、アクティビティ図にあるアクティビティをドラッグして、ユースケース図へドロップすると、相互リンクが設定される、というイメージ。

すなわち、ハイパーリンク機能を流用したトレーサビリティの実現は、そんなに難しくないだろうと思うし、その効果はすごく大きいだろう、と考えている。

なお、モデラーの観点では、トレーサビリティの制御は手動の設定で十分だ。
ラフなスケッチでモデルをたくさん描いていくので、そんなに難しい機能は必要ないから。

【2-2】モデル間のレイヤ化、モデル間の粒度

業務システムの設計を開始すると、サブシステムの観点で、作ったモデルをグルーピングして整理したくなってくる。
たとえば、ECサイトなら、注文システム、商品検索システム、バックエンドのマスタ管理システムなど。
すると、普通は、パッケージをフォルダ代わりに使ってモデルをグルーピングして、モデルをどんどん深掘りしていく。
つまり、パッケージによるグルーピングは、モデルの粒度を揃えて整理する作業に相当する。

しかし、astahではパッケージ図でモデルをまとめた時に、モデルの内容が表示されないし、モデルへリンクする機能がない。
モデラーの観点では、パッケージ図に、パッケージでまとめたモデル名(ダイアグラム)が表示され、表示されたモデル名をクリックすると遷移する、という機能が欲しい。
そうすれば、モデルの粒度を揃えながら、モデルのトレーサビリティ機能を使って、モデルの漏れや整合性を考えやすくなる。

なぜ、モデルのグルーピング後のリンク機能が必要なのか?
なぜなら、モデルの粒度を揃えながら、モデルをレイヤ化する作業を行い、各レイヤ間のモデルのトレーサビリティを考えることで、モデルの精度を上げようとしているからだ。
こういうレイヤ化の作業は、設計作業だけでなく、プログラミングにおいても普通に行われている。
レイヤを一つ増やすことで、絡み合った仕様を整理し、ソフトウェアの複雑さを軽減していく手法は非常に重要だし、モデリングツールがそういう作業を支援するようにして欲しい。

しかし、astahではパッケージ図があるものの、EnterpriseArchitectのように、パッケージにモデル要素を表示してリンクする機能がないので、レイヤ化や粒度による整理がやりにくい。
逐一、構造ツリーでポチポチ開いて確認するしかない。
こんなイメージ。

ビュー

なお、現状のastahでは、パッケージやパッケージ図そのものにもハイパーリンク機能があるので、相互リンクさせることは可能だ。
但し、トレーサビリティの相互リンクと同じく、操作回数が多いので、イライラしてしまう時がある。

Enterprise Architectにはこの機能はあるので、astahにあともう少し機能があれば、という所だろう。

追跡(トレーサビリティ) - Enterprise Architect 13.5 日本語版 ヘルプ

ダイアグラムのトレーサビリティについて スパークスシステムズジャパン フォーラム - ユーザー掲示板

【2-3】モデルの変更管理と構成管理

要件定義では、顧客打合せをしながら、要件や仕様をモデルに反映していく。
その反映作業は、ソースにパッチを当てていく感覚と同じだ。
そして、モデルへのパッチ当ての作業は、行ったり来たりする場合も多い。
顧客の要望、実現すべき機能、実装可能な技術の選択、スコープと納期・コストとのトレードオフを考慮しながら、要件を固めていくので、手戻りはよく発生する。

この作業中に、当初作られたモデルはたくさんのパッチが当てられて、どんどん変化していく。
これがソースコードならば、Gitで構成管理されるので、変更理由のRedmineチケットと相互リンクされてどんどんコミットされていく。
そのコミット履歴から、ソースコードの変更箇所が特定できるし、どういう変更の経緯から発生したのか、という変更理由もチケットから辿ることができる。

しかし、モデルは普通は構成管理されていないので、変更履歴が残っていない。
モデルをGitで管理したとしても、差分箇所を表示できないので、日次バックアップにしか過ぎない。

また、各モデルが変更された時に、どんな変更理由で変わったのか、というRedmineチケットとモデルが相互リンクされていない。
よって、なぜモデルのこの部分が変わったのか、という理由を、後から辿ることが難しい。

本来は、モデルであろうとも、Git等の構成管理ツールの配下におき、変更履歴を管理し、チケット経由でトレーサビリティを実現したい。
しかし、その手法が現実的でないならば、せめて、モデルのメタ情報に、変更が発生したチケットNoを埋め込んでリンクする機能が欲しい。

そういう機能がないと、モデルに数多くのノートが作られて、いつどんな理由で変更された、というコメントがたくさん混じりこんでしまう。
この症状は、ソースコードにガラクタのコメントがたくさん残っている状況と同じだ。
残骸となったコメントは後からリファクタリングするのが難しくなるから、そういうコメントは不要。

さらに、メリットとして、Redmine上でモデルの変更履歴を全文検索できるので、保守フェーズで別の開発者が過去の要件や仕様を探しやすくなる。
また、Redmineにモデルの変更履歴が一元管理されるので、そこから、たとえば、レビュー指摘事項の修正件数や手戻りの設計工数などのメトリクスを集計して分析することもできる。

なお、現実的な機能としては、モデルを描いた後で、astah画面右下(拡張ビュー)でチケット登録できて、登録したチケット一覧が表示される機能があればよい。
そして、拡張ビューのチケット一覧で、チケットNoを押下すると、Redmineチケットへ遷移する機能があれば十分。
実際は、RedmineのREST APIキーとURLをastahで保持しておき、astahのモデル上でチケット情報を入力したら、Redmineでチケットが新規作成されて、拡張ビューに新規チケットが表示される、という流れになるだろう。

この機能が実現できれば、モデルの変更理由の一覧がRedmineチケット一覧と同一視できるので、開発工程以後でモデルの変更理由を探す時に役立つだろう。

Enterprise ArchitectにもRedmine連携プラグインがあるので、astahでも同様に実現できるはず。

Enterprise Architect-Redmine連携アドイン

あるいは、Backlogのastahプラグインがあるので、同様にRedmineプラグインをastahで作れるはず。

Backlog Connector for astah

【3】以上をまとめると、幅・深さのトレーサビリティと変更管理という要望にまとめられる。

1)幅のトレーサビリティ→同じ粒度のモデル間のトレーサビリティ

たとえば、1つのユースケースに含まれるクラス図、シーケンス図、ステートマシン図は相互リンクで行き来できる。

2)深さのトレーサビリティ→別レイヤのモデル間のトレーサビリティ

たとえば、パッケージ図において、グループ化されたパッケージに含まれるモデルへ深掘りしながら、リンクして行き来できる。

3)モデルの変更履歴

たとえば、モデルの変更履歴は、外部サーバーにあるRedmineチケットへリンクして確認する。
つまり、モデルの変更履歴の内容は、astahのモデルそのものに書くのではなく、メタ情報として外部サーバーのRedmineへ蓄積され、参照されるようにして、モデルから分離できる。
変更履歴がモデルから分離されることで、モデルは常に最新版の状態だけ保持すればよく、シンプルなモデルになる。

【4】レイヤ化されたモデル間のトレーサビリティが強化されれば、一つの全体的なモデルとして網の目状に紐付けられた成果物になる。
そして、astahのトレーサビリティマップの機能を使えば、相互リンクで紐付けられた状況を一目で見ることも可能なはずだ。

トレーサビリティマップ 【p】

[pro] トレーサビリティマップ

最終的には、さらに、トレーサビリティマトリクスが生成できるといい。
つまり、全てのモデル間で相互リンクがあるか否かを一目で確認できるクロス集計表が出力できればいい。
この機能は、XDDPのトレーサビリティマトリクスに相当するものだろう。

ソフトウエア改造力 - 第6回 改造の影響を調べる:ドキュメントをまとめ作業計画をレビューする:ITpro

XDDP成果物:USDM、トレーサビリティマトリクス、変更設計書

『XDDP』では「トレーサビリティマトリクス(TM)」で変更箇所を特定

このトレーサビリティマトリクスを生成できれば、特に派生開発やソフトウェア保守で、影響箇所の調査にすごく役立つだろう。
設計フェーズの事前調査で、あらかじめ仕様変更によるモデルの影響箇所を即座に把握できるようになるからだ。

また、モデルの変更履歴がRedmineに蓄積されることで、モデルから不要なコメントがなくなり、モデルは常に最新版だけ保持されるようになる。
残骸となった変更履歴のコメントはモデルには不要。
変更履歴の内容は本来、構成管理ツールで管理すべきだからだ。

なお、トレーサビリティの設定はモデラー自身が手動で設定すればいい。
実際、RedmineとGitなどの構成管理ツール連携によるトレーサビリティも、手動でチケットNoを入力することで対応しているので、違和感はないから。

【5】以上のような事を考えると、モデリングツールはまだまだ改善の余地があるし、換言すれば、数多くの可能性を秘めているのだろうと思う。
Redmineのように、ツールを使いながらプロセスを改善していくアイデアが思いつくように、モデリングツールを使いながら設計技法を改善するアイデアは、もっとたくさん出てくると思う。

| | コメント (0)

« 2017年11月 | トップページ | 2018年1月 »