Redmine

2018/02/21

Redmineのアンチパターンは2種類に区別できるのではないか

以前、Twitterで、日付カスタムフィールドに関するRedmineのアンチパターンが議論されていた。
その議論を読みながら、Redmineのアンチパターンには、プロジェクト管理の要件のブレかフィットギャップ分析の甘さの2種類に区別されるのではないか、と考えた。
ラフなメモ書き。

【問題の発端】
nekosanzさんのツイート: "難問。1つのプロジェクトではなく、1つのチケットにマイルストーンがほしい。こんなこと言われたの初めてだ"

門屋 浩文さんのツイート: "チケット割るか説明に書く!… "

nekosanzさんのツイート: "結論が日付カスタムフィールドを10個ぐらい追加してほしいという炎上物件… "

【問題の真因を突いている議論】
neta@筋肉 筋肉???さんのツイート: "Redmine の日付カスタムフィールドはあかん。ウチも『期日』という名称が気に入らなかったらしく、『希望納期』という残念なカスタムフィールドを作ってしまった。ガントには出ねーわ、リマインダーは効かないはマイッタマイッタ。今は反省している… https://t.co/MSqH2RmwwQ"

門屋 浩文さんのツイート: "日付のカスタムフィールドはあまり良くない 標準のガント使わなくなったのが実績日が出てこないからという理由なので… "

【アンチパターンに関する感想】
akipiiさんのツイート: "久しぶりにRedmine のアンチパターンを集めたいですなぁ笑… "

nekosanzさんのツイート: "みなさんおっしゃる通り。コミュニケーションツール不在の会社にRedmine 導入するとアンチパターンの温床になりえますね。… "

akipiiさんのツイート: "アンチパターンの種類にも、プロジェクト管理の要件を詰めきれてないことと、Redmine の機能を理解しておらずフィットギャップ分析が甘いこと、があるから区別したいな。… "

【1】チケットにマイルストーンが欲しい、という要望を元に、Redmineに日付カスタムフィールドを10個も追加してしまった、という事例。

おそらく、障害管理票、課題管理票のような類の帳票をチケット化した時、数多くの異なる日付を入力する必要になったのでは、と勝手に推測する。

しかし、上記の指摘の通り、Redmineチケットの「期日」を使わなくなると、ガントチャートに表示されないし、リマインダーのメール通知機能も使えなくなる。
よって、本来は、チームの要望にある「日付」の概念をRedmineの「期日」に合うように修正すべきだったのだろう。
あるいは、ja.ymlにある「期日」の文言をチームの組織文化に合った文言、たとえば「納期日」などへ修正しても良かっただろう。

【2】そういう話をふりかえると、Redmineのアンチパターンには、2つの観点で綺麗に分類できるのではないか、と思う。

【2-1】一つは、プロジェクト管理や開発プロセスの本来の設計思想に関する理解が浅いために、プロジェクト管理の要件を詰め切れていないこと。

よくある例は、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、どちらがいいのですか、という質問が相当するだろう。
この質問に関しては、下記の記事で明確に回答が述べられている。

WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

また、「チケット無しの作業不可」の運用ルールの理解が浅いために、作業履歴やレビュー履歴をチケットに残してナレッジを蓄積し、最終的にはプロセス資産になる、という思想まで考えが及ばない、という話もあるだろう。
その他にも、チケットの棚卸し、トレーサビリティなどの話も同じ論点ではないか、と思う。

つまり、Redmineのようなチケット管理ツールとは無関係な観点で、プロジェクト管理や開発プロセスの理解が甘いために、RedmineやJiraであろうが、どのチケット管理ツールも使いこなせていない、という結果になるのだろう。

すなわち、この観点のアンチパターンは、ツールとは無関係な一般論に近いレベルまで昇華できるだろう、と思う。

【2-2】もう一つは、チームの開発プロセスの要件とRedmineの機能について、フィットギャップ分析が甘いこと。
これは、今回の日付カスタムフィールドの話に相当するだろう。

他に、親子チケットの作り方、ロードマップの使い方などもあげられるのではないか。

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索

最近なら、デブサミ2018のRedmine利用事例の講演でも、アンチパターンに関する話があった。
その中で、@g_maedaさんの下記の話は、Redmineにおけるトラッカーを使いこなせていないアンチパターンがある事実を示唆している。

MAEDA, Goさんのツイート: "最近は、トラッカーの追加とは入力フォームを設計して追加することだと説明するようにしています。… "

つまり、Redmineに埋め込まれた本来のチケット管理の機能要件を理解できていないために、Redmineの優れた機能を発揮できない結果に陥る、という結果があるだろう。

すなわち、この観点のアンチパターンは、Redmineの設計思想とユーザが利用したい要件に関して、Remdineのフィットギャップ分析が甘い点に原因があるだろう、と思う。

【3】では、Redmineのアンチパターンを「プロジェクト管理や開発プロセスの一般論」と「Redmineのフィットギャップ分析」で分類したら、どんな面白い内容が出てくるだろうか?

【3-1】まず、僕は、「プロジェクト管理や開発プロセスの一般論」のアンチパターンは、Redmineが機能豊富になるにつれて、最終的にはどんどん難易度が高くなるのではないか、と思う。
一般論の話は、実際にチケット管理して経験して、失敗したり、成功してみたら、すぐに理解できて解決できる。

よって、Redmineに上手く当てはまれば解決できるアンチパターンは、Redmineが誕生して10年経った今、知見やノウハウとして、普通の経験者は理解できているだろう。
そして、じきに、本来のユーザ利用要件をRedmineに当てはめられなくなった、というレベルまでたどり着いて、改めて考えなくてはならない、という方向に落ち着くだろう。

つまり、一般論の話で解決できないアンチパターンは、ソフトウェア開発やソフトウェア工学に関する本質的な問題まで辿り着くのではないか、と思う。

たとえば、チケットの粒度に関する議論は、ソフトウェア工学における「ソフトウェアの本質的な複雑性」に由来するがゆえに、そう簡単に解決できる話ではない、と思っている。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

【3-2】一方、「Redmineのフィットギャップ分析」のアンチパターンでは、Redmineの標準機能で解決できる事例はどんどん公開されてしまい、最終的には、Redmineをカスタマイズすることでしか解決できないアンチパターンが多数出てくるだろう、と思う。

たとえば、最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索でもあげたが、ロードマップ画面におけるチケットの並び順をドラッグ・アンド・ドロップで制御する機能パッチは、アジャイル開発におけるプロダクトバックログ管理に相当する機能なのに、未だに実現されていない。
つまり、先進的なアジャイル開発のプラクティスをRemdineで運用したい、と思っても、Redmineの標準機能では不足しているのだ。

他に、MSProjectみたいにRedmineのガントチャートを使いたい、とか、色んな要望が出てくるだろう。

つまり、「Redmineのフィットギャップ分析」のアンチパターンを完全に解決するには、Redmineにプラグインを導入したり、Redmineそのものをカスタマイズする、という方向性が必要になる事例が数多く残ってくるのではないか、と思う。

【4】個人的には、Redmineのアンチパターンを上記の2種類の観点で区別した時に、下記のテーマがあると思う。

(1)既によく知られているアンチパターンは、上記2種類のどちらに分類されるか?

(2)未解決のアンチパターンの原因は、上記の考え方で合っているか?
そして、解決の方向性も、上記の考え方で進められるか?

この辺りも色々考えてみたい。

| | コメント (0)

2018/02/04

第18回Redmine大阪の感想 #RedmineOsaka

第18回Redmine大阪の感想をメモ。
疲れているので、ラフなメモ書き。
書きかけなので、また後で書く。

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

2018/2/3 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - Togetter

第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス!

【1】気象庁のRedmine利用事例の話は、本当に面白かった。
JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。

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

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

気象庁内のシステムには、天気の予測シミュレーション、PM2.5やら色んな気象データのデータ収集と分析、シミュレーションなどがある。
それらのシステムは、全て内製化されている。
つまり、気象庁の研究者がプログラマとなり、実際に開発している。
この点は、JAXAなど他の官公庁とは全く違う。

だから、気象庁では、数値予報官という役職だけでなく、「プログラマ」という名前の役職も公式に存在する。
この点も他と大きく異なるのだろう。

【1-1】気象庁内では、Fortran、シェル、Rubyが一般的なプログラミング言語。
数値予測などの科学計算は過去の開発資産があるので、Fortranが使われている。
一方、仮想サーバー構築、バッチ処理、インフラ構築などは、シェルとRubyがよく使われている。

【1-2】気象庁では、部署もあるが、開発はシステムごとに、各部署を横断してプログラマや研究者が集まって担当する。
そのシステムに携わる集団を開発コミュニティと呼ぶらしい。
僕の理解では、マトリクス型組織のように思えた。
つまり、研究者やプログラマは部署に所属するが、天気予報、シミュレーション、共通基盤などの各システムの開発に携わるので、クロスファンクショナルなチーム構成になる。

但し、プログラマはどこか一つのコミュニティに属する運用になっているので、複数のコミュニティに所属することはほとんどない。
つまり、各開発コミュニティは縦割り組織に似たような雰囲気になっているみたい。

【1-3】最近は、欧米の気象庁ではPythonを使って数値予測プログラムを書く事例が多くなってきたので、彼らから、なぜまだFortranを使っているの、Pythonなら他言語のライブラリや資産も簡単に呼び出して使えるので、Pythonがいいよ、と言われているため、Pythonをこっそり試し始めている、とのこと。

この辺りの話を聞くと、海外の研究動向にも追随しながら、最先端の技術を導入しようという雰囲気が既にあるのだろう。

【2】気象庁では、各開発コミュニティごとに「あえて」Redmineインスタンスを複数個立ち上げた意図

バージョン管理は、2000年代からCVS、Subversion、Gitへ移行してきた。
2008年頃から、各コミュニティが独自にTracやRedmineを使い始めた。
原さんが海外の動向を踏まえて、各開発コミュニティがバラバラな開発基盤を持つのではなく、共通の開発基盤で運用すべきだ、と提案して、2014年頃から、RedmineとSubversion、Gitを共通の開発基盤として各コミュニティに提供する運用になったらしい。

その時、1台の物理サーバーに1個のRedmineインスタンスで運用する案も考えられたが、一つのRedmineの運用ルールに縛ることを目的とすると、各開発コミュニティから反発が起きるかもしれないことと、各開発コミュニティの組織文化を尊重することも考慮して、複数個のRedmineインスタンスを各開発コミュニティごとに立ち上げることになったらしい。

【3】2段階コードレビューの意図

【3-0】Redmineを導入した動機

そもそも、RedmineやSVNを開発基盤として導入しようという契機になったのは、コードレビューをしっかりやるべきだ、という考え方が、原さんだけでなく、各開発コミュニティでもそのような気運が盛り上がっていたから。

たとえば、天気予報の数値予測シミュレーションのようなプログラム開発では、理論物理や流体力学など科学理論から導かれる機能要件から、それに基づくプログラム実装が行われる。
しかし、かつてはバージョン管理すらなかった時代では、なぜそのような機能が実装されたのか、なぜそんなソースコードになったのか、記録が残っていない。
しかも、科学理論の発展やソフト・ハードの進化に伴うプログラム修正の履歴やその変更理由も残されていない。
だから、システムのリリース後に障害が発生して、トラブルが起きることがあったから。

【3-1】2段階コードレビューの意図

Redmineではコードレビューのプロセスはワークフローの一部として運用されている。

興味深い点は、気象庁のコードレビューでは、2段階レビューが踏まれていること。
まず、サイエンティフィック・レビューでは、科学者の観点で、数値シミュレーションが物理法則や物理の理論に基いた要件でコードが実装されているか、レビューされる。
おそらく、研究者同士の議論に近い雰囲気なのかもしれない。

次に、ソースコードがプログラミングの観点できちんと書かれているか、という立場でコードレビューされる。
Fortranのコーディング規則に従っているか、エラー処理、とか、この部分は我々のコードレビューと同じだろう。
また、物理法則の要件に従って実装されたプログラムを、実際に膨大な気象データに基いてシミュレーションするテストも行う。
このテストには、半日で終わることもあれば、数週間かかることもあるらしい。

たとえば、そこで性能が出なかったりすることが分かれば、その要件の実装はソフトウェア的に実現可能性が低いので、別の代替案を考える、などのフィードバックがコードレビューで行われる。

つまり、単なるコーディング規約のチェックだけでなく、たとえば性能要件を満たすかテストしてみた結果をフィードバックする、などの作業も行われている。

この辺りは、アーキテクチャのフィージビリティ・スタディ、つまり、アーキテクチャ実装のコスト・品質・納期のトレードオフを評価しているのと同じように思える。

これら2段階レビューは、既に欧米の気象庁では行われているので、日本でもやるべきだ、という提案があり、徐々に浸透しているらしい。
そういう内容を聞くと、Redmineチケットにコードレビューの結果を記録し蓄積していくことは非常に有意義な作業であることが理解できる。

【3-2】そして、git-flowによる並行開発とコードレビューが組み合わされて、上手く運用されるようになっているらしい。
つまり、ある要件を開発する場合、trunkからブランチを派生し、そのブランチ上で修正して、コードレビューが完了になれば、trunkにマージされる。
そのブランチはRedmineチケットと対応付けられて、Redmineチケットに要件や仕様、コードレビューの結果などが全て記録される。

【3-3】気象庁のRedmineでは、チケットのカスタムフィールドは使わないし、複雑なワークフローも設定されていないし、プラグインもほぼない。
Redmineのチケットに、コードレビューの指摘、結果、対応の記録を残すことに注力している。
そのおかげで、海外派遣で2年間、気象庁から離れた研究者も、帰国した後、Redmineのチケットを検索するだけで、すぐにプログラム開発の仕事に復帰できた、と言っていたらしい。

つまり、気象庁のRedmineは、進捗管理用のRedmineではなく、ナレッジ資産の為のRedmineなのだ。

【4】複数個のRedmineインスタンスで運用されるデメリットは、原さんによれば特に感じていない、と言われていた。
もし、他コミュニティのRedmineを参照したい場合、RedmineにはRSS機能があるので、RSSをフィードすれば、リアルタイムにチケット更新の状況を把握できる。

【4-1】また、Redmineという開発基盤が普及した後、Redmineの副次効果がいくつかあったらしい。
たとえば、あるコミュニティで、コードレビューはプログラム実装後に行うのではなく、プログラム実装前に関係者が集まって事前に内容を協議する運用を始めた所、他コミュニティでも、その運用はもっともだ、という意見があり、他コミュニティにも徐々に反映されたらしい。

つまり、あるコミュニティのRedmineのベストプラクティスが他コミュニティにも自然に横展開された、という事実を示唆している。

また、気象庁がいくら先進的な官公庁であっても、やはり役所なので縦割り組織の雰囲気がある部分はある。
しかし、Redmineを利用することで、コミュニティ内では、チケット経由のやり取りによって、研究者の知見やソース修正の履歴が記録されて、メンバー間の情報共有がスムーズになったらしい。

【4-2】さらに、データ処理など共通の処理を行う基盤担当のコミュニティがあり、そのコミュニティは気象庁の各コミュニティと関係するが、そのコミュニティのメンバーは、各コミュニティのRedmineにログインできる。
すると、各コミュニティでRedmineやコードレビューの運用ルールが微妙に違うので、同じように運用したい、という声が上がっているらしい。

つまり、現状はあえてコミュニティ単位の複数Redmineインスタンスで運用しているけれど、現場から、ボトムアップでRedmineの標準化を図るべきだ、という声が上がっているわけだ。
将来は分からないけれど、いつか、単一の標準Redmineにサーバー統合される可能性があるかもしれない。

【4-3】この点に関して、参加者からは、Redmineではトラッカーやカスタムフィールドがグローバル変数のような性質のために、使いづらくなっている。
Redmineにも、サイトのような機能を持たせて、各プロジェクトごとのトラッカーやワークフローを定義できるようにすれば、一つのRedmineインスタンスで、各プロジェクトごとにトラッカーやワークフローの自由裁量の権限を与えて運用できるのではないか、という指摘があった。
この意見は全くその通り。

以前も、東京Redmineでも似たような議論があった。

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

【4】個人的には、Redmineは単一インスタンスの運用だけでなく、複数インスタンスの運用もベストプラクティスの一つになりうる、という発見があって、改めて深く考えさせられた。
この点はまたまとめる。

akipiiさんのツイート: "#RedmineOsaka #seakansai 気象庁の事例ではRedmineをナレッジ基盤として使う運用を目的としたら、色んな副次的効果も出てきた。単一の標準Redmineがベストの先入観があったけど、Redmine の複数インスタンスでも成功事例があるのは改めて衝撃を受けた。奥が深いね。"

【追記】
今回のRedmine大阪で、気象庁における開発管理の取り組みの公開資料に基いて、Redmineのチケット管理やGitによるブランチ管理やコードレビューについて数多く質問したのだが、「テストハーネスを用いたテスト自動化」の内容は聞き漏らしてしまった。
おそらく、Fortranプログラムをシェルからバッチで起動して、入力データと出力データを差分比較するようなテストを自動化する仕組みを取り入れていると思われる。
この部分のノウハウも聞きたかった。

気象庁における開発管理の取り組みの公開資料のP.52で下記の引用がある。

(引用開始)
asuca については、トランクへの変更がなかった場合も含めて、テストハーネスと呼ばれる仕組みを毎日自動で実行している。
これは
・ 理想実験
・ 石田ほか (2014) で述べられている、2 次元定常山岳波、周期境界条件における重力波、暖気塊のテスト、重力流、St-MIP
・ 静止大気実験
・ 2 次元スカラー移流
・ 3 次元モデル 3 による狭領域実データ実験
・ 局地解析
・ 接線形モデルチェック
・ 随伴モデルチェック
・ 局地予報
・ メソ予報
といった様々なケースについての実験 4 が、最新のトランクを用いて行われる。
入力データは毎日同じものを用いるため、入出力システムの変更等、予報結果を本質的に変える変更でない場合には、結果はビットレベルで一致する。
自動実行されたテストハーネスの結果は毎日メールで報告され、結果が前日とビットレベルで合わない場合にはそのようなメッセージが付加され、開発者が覚知することができる。
このため、トランクへのマージを行う改変については、テストの段階で開発者が自らテストハーネスを実行し、その結果についてもチケットに記録する。
また、変更の前後で結果が一致しない場合には、その理由や差の妥当性(分布図で見た場合の評価等)も含めて、記録を行う。
(引用終了)

| | コメント (0)

2018/01/31

Redmineに2要素認証のパッチが提供されている

Redmineに二要素認証のパッチが提供されているのでメモ。
次期バージョン4.0で設定されているので、じきに実装されるのでは、と推測する。

Patch #1237: Add support for one time passwords or two-factor authentication - Redmine

@g_maedaさんがレビューしてコメントされている。

(翻訳開始)
パッチを共有してくださったFelixとPlanioに感謝します。
2FAはアカウントを安全に保つのに役立ち、最新のクラウドベースのアプリケーションでは必須の機能なので、これは非常に優れた拡張機能だと思います。
多くのユーザーがこの機能を歓迎する必要があります。
私はパッチを試しました。 それは非常にうまく動作します。
(翻訳終了)

2要素認証方式は、ネットバンキングでも身近だ。
たぶん、スマホでセキュアなクラウドサービスを使っているならば、この認証方式が普通だろう。

実は知られていない、2段階認証アプリの落とし穴について | 仮想通貨のあるとこ

Redmineに2要素認証が追加されるメリットとしては、Redmineをよりセキュアに使いたい利用シーンで役立つだろう。
たとえば、社外へ公開しているRedmineでは、認証操作が甘いと、Redmineの情報が漏れてしまうリスクがある。
そのリスクを軽減するために、二要素認証をユーザに課すことは考えられる。

また、RedmineをSaaSで提供しているクラウド事業者にとっては、2要素認証の機能は非常に重要な機能要件になるだろう。
アプリそのものがよりセキュアに作られている、という証拠にもなるからだ。

パッチ後の管理画面を見ると、オプション機能で全ユーザに対し2要素認証の設定を各ユーザアカウント画面で有効・無効にできること、バックアップ用のQRコードを作成する機能があるようだ。
2要素認証では、スマホのようなクライアント機器が水没したりして無くなると、非常に困るので、バックアップ用QRコードは助かる。(それが漏れるとリスクありだが)

こういうセキュリティ強化につながる機能がどんどん実装されることで、Redmineがよりエンタープライズな業務やユースケースでも利用範囲が広がれば、Redmineの信頼性も増すだろう。
今後も注目していく。

| | コメント (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

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/11/30

Redmineをもっと強化できるポイントpart2~コミュニケーションツール連携・かんばん機能

Redmineをもっと強化できるポイントpart1~上流工程のトレーサビリティ強化」の続き。

【1】障害チケットの活動ログをSlackのようなコミュニケーションツールと連動させる

結合テストや総合テスト工程では、従来は、朝会や夕会でメンバー全員を集めて、障害の優先順位付け、障害の担当者割り振り、修正状況の進捗確認などが行われていた。
メンバー全員の手が一時的に止まるので、結構ロスも多かった。

そこで、Jiraでは、Hipchatでチャットルームを作り、Hipchatに障害チケットの更新通知を流し、議論のやり取りをチャットにしてしまう運用があった。
つまり、Hipchatのチャットルームは、いわゆるWarRoom。
この運用で、総合テストの朝会や夕会で全メンバーが集まり、進捗状況を確認する運用がなくなった、とのこと。
なぜなら、オンライン上でリアルタイムに作業状況や進捗状況がやり取りできるので、全員が集まる必要がないからだ。

この運用は、RedmineからSlackへ障害チケットの更新通知をリアルタイムに配信し、Slack上でコミュニケーションを取ることで解決できるのではないか。

たとえば、テスターが障害チケットを起票したら、Slackに流れて、誰かがその障害を担当するか、Slack上でやり取りして決める。
決まったら、障害チケットに担当者が正式にアサインされ、その後の修正と動作確認はチケットのコメントで残す。

また、大規模プロジェクトでは、各チームの障害チケットがSlack上に流れるので、どのチームの障害が多いのか、どの人がどんな仕事をしているのか、というやり取りが全て見える化される。
見える化するような仕組みづくりは不要になる。

最近のソフトウェア開発では、Slackのようなコミュニケーションツール上で、仕様を議論したり、進捗状況を確認したりする時が多い。
なのに、逐一メール通知で気づくというやり取りは、情報連携のスピードが遅い。

SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ

歴史あるSI企業でSlack導入に成功した方法――そして社内の風通しが良くなりムダや停滞感も消えていった (1/3):EnterpriseZine(エンタープライズジン)

今後は、Slackのようなコミュニケーションツールとチケット管理システムの連携が重要になってくるだろう。
RedmineにもSlack連携プラグインがあるが、最新バージョンでも動くのかな?

redmine-slack プラグインを使ってみたメモ - Qiita

sciyoshi/redmine-slack: Slack notification plugin for Redmine

【2】ガントチャートだけでなく「かんばん」も標準機能にして、場面ごとに使い分ける

Redmineが使えない、という人たちは、チケット一覧画面を多用しすぎる。
無造作に蓄積された多量のチケットに途方に暮れている。
乱発されたチケットを定期的に棚卸しする工夫を行わないと、すぐにチケットは放置されて、ゴミ箱になる。

だから、チケット駆動開発では、大量のチケットが発行されるので、何らかの方法でチケットをグループ化したり、他のチケット集計ビューを使ったりすることで、チケット管理を行うのが普通。

また、日本の普通のSIやメーカーのプロジェクトリーダーは、ガントチャートによるチケット管理が大好きだが、メンバー個人の立場ではガントチャートは使いにくい。
むしろ、小規模チームやメンバー個人では、タスクかんばんの方が作業しやすい。

たとえば、以前の東京Redmine勉強会の講演でも、IOT企業では、ガントチャートとかんばんを使い分けてチケット管理している、という事例があった。

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

「RedmineがIoT企業に異常にマッチしてしまった話」の記事がすばらしい: プログラマの思索

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

Redmineでは、複数プロジェクト機能があるので、かんばんもプロジェクト単位に分割できる一方、上位プロジェクトで横断的にかんばんのチケットを見ることもできるのがメリットになる。

よって、Redmineのようなチケット管理ツールでは、従来のマネージャ層向けのガントチャートと、メンバーが自身の担当状況を把握するためのかんばんの2つのチケット集計ビューが必須だろうと思う。

残念ながら、Redmine標準でかんばん機能はないので、実現されて欲しいと思う。

【3】「上流工程のトレーサビリティの強化」「コミュニケーションツール連携」「かんばん機能」は、最近の有償のチケット管理ツールにはどれも付属しているだろう。
これら機能は、プロジェクト状況の見える化、情報共有を現代風に強化したものと思える。

これら機能の効果は、以前よりも大規模な人数による大規模開発や、地理的に離れた開発チームによるオフショア開発がやりやすくなることだ。
つまり、大人数の開発者同士、地理的に離れた開発者同士のコミュニケーションをリアルタイムに行えるようにして、情報共有、さらには信頼関係を促進する方向へ、チケット管理ツールがどんどん進化している。

従来のソフトウェア工学では、コミュニケーションパスが増えるほどソフトエアの複雑性も非線形で増大するが、その問題を根本的に解決する方法はない、みたいな話があったように記憶する。
しかし、チケット管理ツールはその問題の症状を和らげて、より大規模かつ地理的に広範囲なチームでもソフトウェア開発できる環境を整備しようとする方向へ進化している。

この流れをRedmineの機能にも盛り込んでいきたい。

| | コメント (0)

より以前の記事一覧