Redmine

2019/04/07

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク

 

「プログラミングのできる羊とできない山羊を区別する方法」の記事をリンクしておく。
プログラミングの向き不向きに関する興味深い記事。

 

【参考】
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog

 

(引用開始)
実に多くの人がリンクしているこの論文(PDF)では、プログラムやプログラミング言語に触ったことがない学生達を対象に、「プログラミングのできる羊とできない山羊を区別する方法」を提案している。
おしなべてプログラミングの教師はプログラミングができる学生とできない学生の二つの山ができることに気付いている。それぞれの山は独立な正規分布を成している。プログラミング教育に関する研究のほとんどすべてが教授法についてのものである。すなわち、言語を変え、応用分野を変え、IDEの利用法や仕事へのモチベーションの維持について教えるわけだ。しかしそれらの試みはなかなか上手くいかず、二つの山は依然として残り続けている。
(中略)

 

この論文の著者は計算機科学における最初のハードルは以下のようなものになると仮定している。
代入と系列
再帰 / 繰り返し
同時並列性

 

上から順にハードルは高くなっていく。従ってテストは新米プログラマに対する最初のハードルである代入から始めていく。このテストの結果は3つのグループに綺麗に分かれる。
学生の44%は代入がどのように働くかについて一貫したモデルを持つに至る(たとえ正しくなくとも)
39%の学生は代入のモデルとして一貫したものを形成できない。
8%の学生はふてくされて回答を空白のままにする。

 

このテストは2回実施された。最初の一回目を何の説明もなしに行い、3週間後にもう一度行った。印象的なことは、一回目と二回目では実質的にグループの変化がほとんど無かったことである。つまり、一回目のテストであなたが心の中に一貫したモデルを得られるかどうかが最初のハードルになっている。
著者はプログラミングができることと一貫したモデルを心に持てるかどうかの間には極めて高い相関があることに気付いた。
(引用終了)

 

つまり、プログラミング教育の講座では、プログラミングにすぐに慣れる人と、プログラミングがずっと分からない人から成る正規分布の2つの山に分かれる現象らしい。
確かにそうかもしれない。

 

個人的に興味があるのは、小学生からプログラミング教育が義務化された状況において、プログラミングを知らない子供がどうやってプログラミングのスキルを習得していくのか、を観察してみることだ。
子供が母国語を自然に覚えるように、プログラミング言語を自然に習得できるのか?

 

それとも、40代を過ぎたおじさんがTOIEC対策のために英語習得に非常に苦労している風景と同じく、プログラミング初心者も、通常の論理体系とは異なるプログラミング言語を習得することに、非常に苦労するものなのか?

 

上記の記事を理解した後で振り返ると、数学の公理体系と同じく、それ自体は無意味な論理規則の集合体であるプログラミング言語をどうやって操れるようになるのか、その習得過程に興味がある。
それが分かれば、ソフトウェア開発の難しさという本質に触れられるような気がするから。

 

 

 

| | コメント (0)

2019/03/10

第19回Redmine大阪の感想 #redmineosaka

昨日の第19回Redmine大阪が無事に終了した。
スタッフの皆さん、参加者、そしてJiraやBacklogのパネラーの方、ありがとうございました。
感想をラフなメモ書き。
Mroongaはまだ分かっていないので、間違っていたら後で直す。

【参考】
第19回 Redmine大阪 - connpass

第19回 Redmine大阪(2019/3/9) #redmineosaka - Togetter

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

redmineエバンジェリストの会 メンバー4人がRedmine大阪へ

続・姫路IT系勉強会で

Node.js meets Redmine (第19回 Redmine大阪 LT発表内容)|足羽川永都(あすわがわえいと)|note

【1】今回の勉強会では、参加者層が多様だったので、大変盛り上がったように思う。
大阪圏の参加者だけでなく、東京・名古屋・福井・京都・神戸・姫路・松江・福岡などの遠方から多数の参加者があった。
また、Jiraのエバンジェリストの方も来て頂いて、チケット管理ツールに関する有用な議論もできた。

直前のキャンセルがあったにも関わらず、補欠の参加者が全員参加されて、参加率100%超になったのはすごいな、と思う。
それだけRedmineのニーズが広がっているのかな?

【2】@akahane92さんの講演では、特に全文検索プラグインの仕様と性能評価が興味を惹いた。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

clear-code/redmine_full_text_search: Full text search for Redmine

@akahane92さんの会社では、クリアコードさんと共同開発して、GitHubに公開されている全文検索プラグインに対し、RedmineのチケットやWikiなどの全文検索を更に強化した機能も含めて公開されている。
今後は、添付ファイルやSVNなどのリポジトリ情報も全文検索の対象としてプラグインの機能に含めていく、という。

【2-1】この講演内容を聞いて重要と考えた事は2つある。
一つは、メーカーという知的財産に非常にセンシティブな企業であっても、オープンソースの方が価値がある、という考え方に同意してくれていること。

もう一つは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルや構成管理ツールのリポジトリ情報もテキスト情報として全文検索の対象に含めること。

Redmine本家では、添付ファイルの全文検索も機能追加するチケット(Planio提供 #306)があるが、@g_maedaさんや@akahane92さんに聞いた所、Redmineの検索機能が更に劣化する可能性があること、パッチの規模が大きすぎることから入らないのではないか、とのことだった。
しかし、全文検索プラグインでその機能が実現されるならば、問題はない。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

つまり、全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイル・リポジトリは全て検索対象となり、Redmineを真のナレッジ基盤として実現できるわけだ。

(引用開始)
Redmineのファイル内容 全文検索
添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
想定される課題は3点:

1)検索処理時間
実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、このままでは厳しい。
→ Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイルの索引型高速全文検索」により改善できる(もうすぐ)
2)検索結果の精度
SQL検索では探している情報が大量のデータに埋もれてしまうため、見つけるまでに時間がかかってしまう。
→ Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索ができず、効率が悪い。
→ Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容の索引型高速全文検索」により改善できる(予定)
(引用終了)

【2-2】@akahane92さんに聞いた所、Redmineの全文検索プラグインでは、プロジェクト単位に全文検索できる仕様が重要である、という点が興味を惹いた。

なぜなら、プロジェクトは新製品開発など、情報アクセスに厳しい制約があるため、Redmineユーザは所属しないプロジェクトにアクセスできない仕様が必要だからだ。
おそらく、ISOやISMSの制約上、重要な機密情報は限定されたユーザだけがアクセスできるような仕組みが必要なのだろう。
Redmine本体の検索機能には、既に検索時の絞り込み条件が設定されているので、問題ないわけだ。

【2-3】全文検索プラグインの実装仕様、特に機械学習によるAI検索について、@akahane92さん、@ryouma_nagareさんの説明を聞いて、ようやく概要を理解できた。

チケット登録時に、チケットの情報とともに、Mroongaが検索用インデックスを保持する。
Redmineで全文検索を行う時、その検索用インデックスを使うので検索時間はかからない。

また、Mroongaが保持する検索アルゴリズムは、定期的にメンテナンスする。
例えば、Redmineの外で、GPUを使った特別のサーバーを用意して、AIエンジンで別途、機械学習させて、その学習結果をMroongaに週1回または月1回のように定期的に取り込む。
したがって、Mroongaの検索アルゴリズムは定期的にアップデートして、Redmineの検索精度を高めるように運用すればよい。

僕はMroongaを機械学習エンジンと勘違いしていたが、そうではなく、全文検索用の語彙表テーブルとインデックスカラムを自動生成してくれるミドルウェアだと理解した。

他に、お話を聞くと、MroongaはRedmineのver3.4, 4.0にも対応済みらしい。
そしてOSS化されている事から、MroongaはRedmineの最新版に追随してくれることが期待できる。

【3】アジャイルウェアの堂端さんのGitHub連携プラグインのデモも興味深かった。

仕掛けとしては、RedmineでGitHubの接続情報を設定しておくと、Redmineサーバー上にGitHubのBareリポジトリが作られて、そのリポジトリをRedmineが参照すること。

agileware-jp/redmine_github

【4】JiraとBacklogパネラーを含めたパネルディスカッションも面白かった。

BacklogやJiraが向いていない利用シーンは、大規模なWF型開発の案件です、という発言を聞いて、Redmineのチケットやプロジェクトの階層無制限の機能がそこに有効に作用している、という点を改めて認識した。
つまり、日本の企業でRedmineが好まれているのは、従来のWF型開発にとてもフィットしているツールとして使われているからだろう。

【5】今回の勉強会を一スタッフかつ一参加者の立場で楽しんだ後、Redmineコミュニティは今後どのように進んでいくのだろうか、と思った。
懇親会でも、最近の東京Redmine勉強会は盛り上がっているが、Redmine大阪はどうなんですか、という質問もあった。

僕は、JiraとBacklogのパネルディスカッションを聞きながら、2011年当時のチケット管理ツール大決戦のイベントを思い出していた。
2011年のRedmine勉強会発足当時、大阪や東京のRedmineコミュニティではアジャイル開発者が率先して試行錯誤していた。
たとえば、以前は、@daipresentsさん、岡本さん、小久保さんなど数多くのアジャイル実践者は、Redmineでいかにアジャイル開発を運用するか、を試されていた。
その過程で、Scrumのプラグインを作られたり、Gitと連携するプラグインを作られていた。

しかし、その後、Redmineのユーザ層が変化したように思う。
実際、最近のRedmine勉強会のユーザは、PMOやSEPG、情報システム部門のユーザが多い。
また、Redmineを全社で展開しているので、Ruby開発者よりもインフラ関係のエンジニアが多いように思う。

つまり、Redmineのユーザ層は、アジャイル開発者ではなく、日本のソフトウェア開発や現場の業務に合うように実運用する立場の人達に変化した。
そんな流れを振り返ると、日本のユーザはRedmineが自分たちのニーズに向いていることに気づき、多種多様な現場に片っ端から適用してみることで、Redmineをより深く理解しようとしているのではないか、と思った。
今回の勉強会では、そんな気づきがあった。

| | コメント (0)

2019/02/24

RedmineとAIエンジンを連携する事例のリンク

RedmineとAIエンジンを連携する事例があったのでリンクしておく。
以下は自分が理解した内容のラフなメモ書き。
間違っていたら後で直す。

【参考1】
その問い合わせ、AIが解決します!~Redmineチケットレコメンドシステムのご紹介~ | Future Tech Blog - フューチャーアーキテクト

社内ヘルプデスクをAIで! | Future Tech Blog - フューチャーアーキテクト

【1】後者の事例は、チケットの内容をAIエンジンが自動判断して、カテゴリ振り分けを自動設定する。
前者の事例は、チケット登録時の情報を元に、AIエンジンが類似チケットを自動で関連付ける。

上記の例で興味深い内容は、下記の点だ。

(引用開始)
検索アルゴリズムは、「類似文書検索」と「キーワード検索」のハイブリッド手法を用いることにより、より精度を向上させる試みを行いました。
類似文書検索は、機械学習のトップカンファレンス1 で発表されたSCDV(sparse Composite Document Vector)と呼ばれるEmbedding手法を用い、キーワード検索は現在有力とされているBM25を用いました。
本システムのもっとも肝な部分は、SCDV(文書検索)×BM25(キーワード検索)のハイブリッドアルゴリズムを実装した点にあります。
(引用終了)

なるほど、類似文書検索とキーワード検索を元に、チケット内容の類似度の度合いを相関関数で測定して、精度を高めているわけだ。
類似文書検索だけ、キーワード検索だけ、ではなく、2つを組み合わせた多重度分析にして重みを教師あり学習で精度をさらに高めている点は、面白いな、と思った。

【2】アーキテクチャとしては、AWS上にRedmineとJenkinsとAIエンジンがあって、Jenkinsが定期的にRedmineをポーリングしてAIエンジンに連携し、カテゴリ振り分けや類似チケットを推定して、Redmineへ情報を返却する流れみたい。
Redmineのチケットにカテゴリ振り分けや類似チケットを関連チケットとしてリンクさせる処理は、RedmineプラグインまたはREST APIで実装しているみたい。

確かに、Redmineの外側にAIサーバーを置いて、Redmineのデータを定期的に渡すようにするサーバー設計ならば、既存の仕組みを組み合わせるだけで作れそうな気がする。
Redmineのデータをやり取りするI/Fの部分だけは、REST APIやRedmineプラグインで実装すればいい。

この発想は、Redmineの外部にBIサーバー(例えば、Tableauとか)を置いて、Redmineのデータを定期的に集計表示させる仕組みにも似ている。
つまり、Redmine単体はチケットというデータ収集基盤とみなし、AIサーバーやBIサーバーがRedmineのチケットを定期的に取得して、類似データを分析したり、いろんな観点のメトリクスを集計する仕組みが作れるわけだ。

【3】上記の事例は非常に面白い。
なぜなら、「少人数・短期間で、簡単に構築することができた」からだ。
つまり、RedmineとAIエンジンを組み合わせる手法は、昨今のOSSライブラリを上手く流用できれば、そう難しくないのだろう。

現在、Redmineを長年運用してチケット枚数が数万~数十万件まで蓄積された開発現場はたぶん、割と多いのではないか、と思う。
AIサーバーで類似チケットを自動設定したり、カテゴリ振り分けを自動設定したりする事例があるならば、他に、別のチケット振り分けの観点でチケットの属性にデータを設定する機能も実現可能だろう。
つまり、@ktohさんが以前話していたように、Redmineにスマートナビまたはコンシェルジュのようなエンジンを実現することで、チケット入力者に事前に情報を提供したり、チケット入力を支援することも可能だろう。

この辺りのアイデアは色々考えてみたいと思う。

| | コメント (0)

2019/02/11

RedmineユーザはRedminersと呼ぼう~We are Redminers!

RedmineユーザはRedminersと呼ぶらしいのでメモ。

We are Redminers! というフレーズは何かカッコイイね。
「ルビーを掘る人」「赤いのを掘る人」という意味なわけか。

【参考】
たかのあきこ@devsumi15-D-6さんのツイート: "I am really happy to receive 100 stars. Even it took almost 7 years.... Thanks to all the Redminers and kindly communities! #redmine… https://t.co/31xibjfZV4"

MAEDA Goさんのツイート: "I have installed your really nice plugin to hundreds of Redmine instances. Thank you for creating and maintaining redmine_issue_templates!… https://t.co/qtSGqUFA8p"

akipiiさんのツイート: "Redmine ユーザーをRedminersと呼ぶのですね。初めて知りました笑… "

昌。さんのツイート: "初めて知りました。笑 使おう。がんばれベアーズみたいでカッコいい… "

門屋浩文@redmineエバンジェリストの会??さんのツイート: "積極的に使っていきます WE are Redminers!… "

たかのあきこ@devsumi15-D-6さんのツイート: "ルビーを掘る、という意味でRedmineと思ってます^^ フォーティナイナーズも金採掘にちなみますよね。世代的に49年生まれの方もマッチするかな。… "

齋藤さんのツイート: "なるほど。元々「赤いのを掘る」であってるのか。赤いのを掘る人=redminers ですね。ふむふむ。… "

| | コメント (0)

2019/01/31

RedmineのGit連携機能に関する議論

Redmine本家で、Git連携機能に関する議論があって、興味深いのでメモ。
結論のないラフなメモ。

【参考】
Feature #14961: Reconsider moving from svn to git &GitHub - Redmine

Feature #30069: Integrate Redmine with GitLab (or other free CI system for open source) to run tests - Redmine

Feature #8363: Git: Pull requests - Redmine

QA #910: RedmineでPullRequestを使いたい - Unofficial Redmine Cooking - redmine.tokyo

【1】RedmineのGit連携に関する問題は、実は2つの論点があると思う。
1つ目は、RedmineにGitHubやGitLabクローンの機能を入れて、Redmine上でプルリクエストを行いたい事。
2つ目は、Redmine本体の開発は、Gitのプルリクエストを使い、数多くの開発者のパッチによる貢献を取り入れやすくする事。

この2つの論点が混じっているので、議論が込み入っているのではないか、と思う。

【2】実は、Redmineのパッチ開発者の多くは、Redmine本体をGitの構成管理の配下に置き、自由に開発ブランチを派生させて実験したり、プルリクエストをコミッタに送りたい、という要望が大きいのだろう。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、Taiki I さんがこんなコメントをされている。

(Google翻訳の引用開始)
こんにちは恐竜、
この問題が発生してから5年が経過しました。全世界がGitに移行したかどうかはわかりませんが、OSSプロジェクトがPull RequestsとGitによる寄付を集める主流になりました。
Redmineにプルリクエストを実装するかもしれませんが、これは容易ではないでしょう。
まず最初に、RedmineのリポジトリをGitに移動し、プルリクエストを受け付けるようにします。そして、貢献のハードルを下げ、貢献の門を広く開きます。競合品を使っても。
幸いなことにGitLabには「外部課題追跡システム」があります。これで、GitLabのGit管理とプルリクエスト(マージリクエスト)を使用しながら、Redmine.orgの多くの問題をそのまま使用し続けることができます。
この問題についてもう一度話し合いますか?
(引用終了)

但し、その実現が容易ではないことは、Redmineユーザなら皆知っている。

Feature #14961: Reconsider moving from svn to git & GitHub - Redmineで、@g_maedaさんがこんなコメントをされている。

(Google翻訳の引用開始)
現在の状況が気に入らなくても、皆さん全員が紳士的であることを願っています。
何年もRedmineの開発に時間を費やしてきた人々を落胆させてRedmineを改善することはできません。
(引用終了)

【3】僕は、GitHub連携プラグインがRedmineに組み込まれれば、不満はほぼ緩和できると思う。
つまり、プルリクの機能はGitHub上で使い、Redmineのチケットにはその履歴を残す、というように、利用場面を使い分けることだ。
また、Redmineチケットにパッチを添付するのではなく、GitHubのプルリクの内容がRedmineチケットに自動複製されると、もっと良い。

これは完全な解決方法ではないが、プルリク機能の実装は非常に難しいと思う為だ。

【4】この議論のチケットを読みながら、OSSコミュニティを発展させるには、OSSコミッタのモチベーションが最重要であることを思い出した。

オープンソースソフトウェアを開発する日々をハッピーに ― あるいは、OSSコントリビュータに感謝を伝えるためにできること | POSTD

Redmineに不満が出て、数多くの不平を言ってしまうこともあるだろう。
その行為がOSSコミュニティにとって良いことなのか?

下記の文章が心に残った。

(引用開始)
オープンソースに関わる誰かに、シンプルに肯定の意を伝えることです。
メールや、あるいはIRCを通して、はたまたプロジェクトの貢献者に直接会うなど、手段を問わず文字通り誰かに「ありがとう」と伝えることは、とても大きな意味を持つのです。
これが取るに足らないことだとは承知していますが、長い時間をかけてオープンソースに貢献している人たちは、基本的にネガティブな人、あるいは誠意はあるけれども人から何かをしてもらおうとする人たちに相対してきたことを忘れてはいけません。
人にずかずかと要求せず、「ありがとう」と言ってくれる人がいることは、バグ修正などの要求に応えたからのお礼ではなく、プロジェクト全般が感謝されていることが分かるはずです。

この2つの感謝の違いは、愛する人のために何かをしてあげ、相手があなたに感謝の気持ちとしてハグをしてくれることと、同じ人がただ単にあなたが好きだからという理由で不意にハグをくれる、この2つのハグの違いと同じなのです。
前者のハグもすてきですが、後者のハグはあなたをより特別な気持ちにしてくれます。
(引用終了)

最近、Matzさんもこの論点の記事を書かれていた。
Rubyに対する不満がRubyクローンを生み出したこともあったらしい。

Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 - Publickey

そして、Matzさんの回答の一つは、Ruby開発のITSであるRedmineに、提案して欲しい、と。

【5】OSS開発の活発さとOSSコミュニティの活発な議論には相関関係があると思う。
さらには、@t_wadaさんの指摘どおり、OSS開発の活発さと良いソフトウェア設計には密接な相関関係があると思う。
Redmineの良さの一つは、RubyとRailsという柔軟な開発基盤のおかげで、カスタマイズしやすいので、色んな議論ができることだろうと思う。
そのバランスはどこにあるのだろうか?

OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

| | コメント (0)

2019/01/26

第19回Redmine大阪の見所 #redmineosaka

第19回Redmine大阪の見所を書いておく。

【参考】
第19回 Redmine大阪 - connpass

(引用開始)
テーマ~「次世代プロジェクト管理システム Redmine の未来を考える」
約1年ぶりに、待望のRedmine のメジャーバージョン4.0がリリースされました。
今回の勉強会では、さらに機能改善されたRedmineの解説だけでなく、下記の内容を提供します。

最新バージョンのRedmineでのチューニング結果報告
国内で代表的なプロジェクト管理ツール Redmine・JIRA・Backlog の有識者を招いて、プロジェクト管理ツールについてディスカッション

Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

1年ぶりの勉強会の見所は、次の3つがある。

【1】@akahane92さんの「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂4版」

Redmineチューニングに関しては、世界トップクラスの@akahane92さんが最新バージョン4.0の性能評価、チューニング技術に関して報告して頂く。
特に興味深い点は、全文検索プラグインを使った性能評価だ。

Redmineの全文検索プラグインが、Redmineにとってとても重要な理由は、Redmineをナレッジシステムとして実現する為に重要な機能であるからだ。
その理由は下記に書いた。

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

Redmineの全文検索プラグインには、Redmineに蓄積された過去のチケット、Wikiなどの情報を高速に検索できるだけでなく、GoogleのPageRankのように重要度の高い順にソートしたり、Amazonのお勧め商品のように類似チケットを表示する機能などがある。
この機能がRedmineに組み込まれれば、システム保守や顧客問合せなどのデータをRedmineに蓄積するほど、Redmineにその会社のナレッジが蓄積されていくので、Redmineは有用なナレッジシステムになる。
さらに、昨今の機械学習や人工知能のライブラリをアドオンで組み込むなどすれば、より的確な情報を提供するだけでなくアドバイスすることも可能になるだろう。

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

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

@akahane92さんの講演内容は今後、詳細が明らかになっていくと思うが、既にRedmineをIT全般統制(ITSMS)に適用して実運用されている背景を考えると、Redmineの全文検索プラグインがIT全般統制の内部監査で重要な役割を担っているのではないか、と推測される。

すると、ISO9001やITSMSのマネジメントシステムにRedmineをうまく当てはめる事が出来れば、Redmineの導入対象は、ソフトウェア企業だけでなく、製造業などの会社にも導入できることになり、Redmineの活用範囲が広がるだろう。
実際、既にITILとRedmineは相性が良いのは知られているので、ISO規格にあるマネジメントシステムとのフィットギャップ分析さえできればいい。
その辺りも色々聞いてみたい所。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想: プログラマの思索

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

そうなると、今後の課題は、Redmineの添付ファイルも全文検索プラグインの対象に入れて、Redmineを真のナレッジシステムにすることになるだろう。
なぜなら、RedmineのチケットやWikiだけでなく、チケットに添付されたExcelファイルまで全文検索の対象になれば、より重要な情報を的確にいつでも高速に抽出できるからだ。
そうすれば、Redmineにどんどん情報を蓄積していこう、というユーザの動機付けにも役立つだろう。

Ver4.1で、添付ファイルを全文検索する機能が提案されているので、今後の動向も要チェックだ。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

【2】アジャイルウェア 堂端さんの「GitHub連携プラグイン」

Redmineの課題の一つには、Git連携がやりにくい、という点が10年前からあった。
現状の機能では、Bareリポジトリを手動で作ったり、Gitlabと連携できるように構築するなど、手間がかかる場合が多い。

今回の講演では、GitHub連携プラグインを提供されるということ。
このプラグインは、Redmineユーザにとってメリットが大きいと思う。

GitHub連携プラグインのメリットは2つある。
一つは、GitHubとRedmineと連携できることで、チケット管理はRedmine、プルリクやフォークなどのソース修正はGitHubという使い分けが簡単に実現できること。
以前から、RedmineとGitlabの連携は試みがされてきたが、GitHubでも使い分けが可能になる。

もう一つは、GitHubが無料のプライベートリポジトリを使用可能にしてくれたおかげで、個人のソース管理やドキュメント管理はGitHub、プライベートなタスク管理はRedmine、で置き換えられること。

GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか: プログラマの思索

マイクロソフトがGitHubを買収した後、GitHubが非常に使いやすくなったので、GitHub連携プラグインはとてもタイムリーな内容だと思う。

【3】「プロジェクト管理ツール Redmine・JIRA・Backlog によるうちの子の良い所、他の子の欲しい所」

現在調整中だが、Redmine、Jira、Backlogという著名なプロジェクト管理ツールのエバンジェリストをお呼びして、それぞれのツールの良い所を紹介してもらい、自由に議論してもらおう、という企画。
企画の隠れた目的には、そういう議論の内容をRedmineの機能改善に役立てたい、という気持ちも込められている。
個人的には、とても楽しみな内容。

なお、このパネルディスカッションの企画を手伝っている時に、過去の「チケット管理ツール大決戦」の企画を思い出していた。
2011年のデブサミで、チケット管理ツール大決戦という企画が非常に盛り上がって、その企画がユーザ投票で3位にランクインされたのを思い出す。

チケット管理システム大決戦第二弾 Trac vs Redmine vs JIRA vs Backlog を開催しました!勝者は? - I18n and L10n in My Life

デブサミ2011レポート~チケット管理システム大決戦: プログラマの思索

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi: ソフトウェアさかば

2/17: デブサミ 2011 / チケット管理システム大決戦

チケット管理システム使用状況の調査結果(デブサミ) | Atlassian Blogs

【資料公開】チケット管理システム大決戦 第二弾 | Ryuzee.com

Excel大好きな日本企業の組織文化は、たぶんその頃から変わっていないように思う。
だから、それぞれの製品のメリットを強調するだけでなく、世の中の業務の問題解決にプロジェクト管理ツールが役立てればいいなあ、と思っている。

【4】既に満員御礼になっていますが、懇親会は人数を増やせるので、懇親会からの参加もOKです。

| | コメント (0)

2019/01/21

RedmineをフォークしたOpenProjectのリンク

下記の記事で、RedmineをフォークしたOpenProjectなるものを知ったので、リンクしておく。

【参考】
「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita

ExcelおじさんとGitHub若者が共存するためのタスク管理法 ? Be full stack?? | SI からフリーランス

【1】@g_maedaさんのツイートによれば、OpenProjectは、Redmineをフォークしたらしい。
よって、OpenProjectは、Redmineをコア基盤としている訳ではなく、Redmineとは別で発展しているみたい。

akipiiさんのツイート: "後で読む。Redmine のVerIpに追随できるのか、気になる。RT @diffshare: こういうのもあるのか https://t.co/60moUClq42 「近代化Redmine」ことOpenProjectでスクラム開発のプロジェクト管理"

akipiiさんのツイート: "詳細は知らないけど、コア基盤がRedmine なら、バージョンアップに追随できないと運用は難しいかも。Planioサービスは上手くバージョンアップに追随して、凄いと思います。… "

やっさん🍶さんのツイート: "#OpenProject のプラグインが #Redmine のがベースになってるぽいので、Redmineクローンなのかも。 openproject-local_avatars/local_avatars.rb https://t.co/htY5Qtnbda opf/openproject: OpenProject is the leading open source project management software. https://t.co/iISR8GZPy4… https://t.co/SOdVSfhRUV"

MAEDA Goさんのツイート: "2011年にRedmineをフォークしてChiliProjectができました。 https://t.co/35fGcR87fd さらに2012年にChiliProjectをフォークしてOpenProjectができました。 https://t.co/WOvyOEtHGm 現在はOpenProjectは独自に進化していて、Redmineのバージョンアップには影響されないと思います。… https://t.co/pB0P50Enmz"

【2】OpenProjectの特徴は、RedmineのVer2時代のBacklogsプラグインの拡張版として捉えられることだろう。
ScrumやかんばんをRedmine上で使いたい人には、朗報かもしれない。
今どき、Excelでプロジェクト管理するのはしんどいからね。

(引用開始)
こんな人におすすめ

今までRedmine + Backlogプラグインで頑張ってた人
・スクラム開発用に「かんばん」と「バックログ」が欲しい
・プロジェクト管理用に「ガントチャート」も欲しい
・でも、Redmineにプラグインを入れる苦行は回避したい…
・日本語化されててほしい
・簡単に環境構築したい
ExcelおじさんとGitHub若者が共存するためのタスク管理法 - Qiita みたいな環境の人
(引用終了)

Dockerで簡単にインストールできる点もいい。

詳細はまだよく分からないが、「微妙な点」の内容が面白い。
「推奨環境がメモリ4GB」となかなか豪快、とか、SPAが微妙、とか、Redmine臭がすごい、とか、まあそういう面はありそう。

RedmineをフォークしたChiliProjectは廃れてしまったが、OpenProjectの動向も追ってみたいと思う。

【追記】
Redmine BacklogsプラグインはScrumプロセスを忠実に実現しようとしている: プログラマの思索

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

| | コメント (0)

「Git と Redmine を用いた気象研究所共用海洋モデル」の論文のリンク

@g_maedaさんのツイートで、「Git と Redmine を用いた気象研究所共用海洋モデル」の論文を知ったので、リンクしておく。
引用文献に、「ファーエンドテクノロジー: redmine.jp」が掲載されているだけでなく、「Redmine によるタスクマネジメント実践技法」も掲載されているのが嬉しい。

【参考】
GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

Git と Redmine を用いた気象研究所共用海洋モデル - 日本海洋学会

数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

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

akipiiさんのツイート: "後で読む!RT @g_maeda: Redmineの活用に関する論文を見つけた。 GitとRedmineを用いた気象研究所共用海洋モデル「https://t.co/zwcaQuOKca」の開発管理 https://t.co/5BfubPtHsJ"

【1】論文の内容は、気象庁の研究者が、海洋大循環モデルのソフトウェア開発にRedmineとGitを適用することで、開発プロセスを標準化し、効果を上げた、という事例みたい。

海洋大循環モデルのシステム維持はとても大変、という問題意識があったらしい。

(引用開始)
(海洋大循環)モデルの維持・開発はより困難になってきているのが現状である。世界的にモデル開発者数は減少する一方で,モデルのソースコードは日毎に大規模化・複雑化している。
このため,バグの混入や意図しない影響の抑制,つまりソフトウェア品質の維持は非常に難しくなっている。
(中略)
ソースコードは全体で 10 万行を超え,100 近いコンパイルオプションと数 100 に及ぶ実行時オプションがある。
加えて,仕様を変えずにバグ修正だけが必要な現業目的と,次々に機能を追加する必要がある研究目的の両方に対応するため,安定版と開発版の2 系統を維持しなければいけない。開発が始まってからおよそ 20 年が経過し,過去の絡み合ったソースコードの整理・再構成も必要である。
これらソースコード自体の複雑さに加えて,その利用が多様化しているという問題もある。長い開発期間の結果として,MRI.COM は,日本沿岸海況監視,季節予報,将来気候予測など,気象庁と気象研究所の多様な現業と研究の基盤モデルに用いられ,それぞれの幅広い要望に対応して,同時並行的に開発が進められている。
このような複雑な状況の下で,ソフトウェア品質を維持しながら様々な機能を次々にソースコードに加えていくことが,少人数の開発チームに求められている。
(引用終了)

そこで、GitとRedmineを導入することで、下記を狙ったらしい。

・複数のブランチに対するソースコードの開発履歴を管理する
・作業過程の記録と進捗状況の把握を一元的に行う
・これらのツールを基盤に用いることで,開発者各人がそれぞれのやり方で開発する状況から脱して,システマティックな開発手順を導入する

【2】興味深い点は、Gitの運用フローが詳細なこと、Redmineの運用フローに特徴があること、だと思う。

Redmineの実際の運用フローは以下の通り。
プログラミング作業とコードレビューがチケットの主要な使い方みたいだ。

(引用開始)
1)開発者はまず Redmine チケットを作成し,Fig. 4 のように簡潔に開発内容を記す(いわゆるチケット駆動開発,小川・阪井,2010)。
2)開発者は他の開発メンバー 1 名を「レビュアー」に指名し,ソースコードを編集する前に,変更内容と実装方針について相談する(ただし,簡単なバグ修正であれば必須ではない)。
3)相談結果を踏まえ,開発者がローカルでコード変更の作業を始める。
4)ローカルでコード変更を完成させ(Fig. 2 の手順 2 に相当),レビュアーにレビューを依頼する。
5)レビュアーがコード変更のレビューとテストを行う。レビュー結果は Redmine のチケットのコメントやGit の修正コミットとして開発者にフィードバックされる(Fig. 2 の手順 3,4,5)。
6)コード変更を開発メンバー全員に公開し,チェックとテストを受ける(Fig. 2 の手順 7,8)。
7)検証が終わったコードを幹とする(Fig. 2 で Ver.1.1を確定することに相当)。
これで 1 つのチケットの開発は終了し,確定した歴史となる。
(引用終了)

Redmineの運用のメリットは以下の通り。

(引用開始)
具体的なメリットを以下に挙げる。
1)他人に見られることを前提にしてタスク内容を明文化することで,開発方針が明確になる。
2)担当者や期日が明示されることで,各タスクの優先度の誤認などを防ぐ。
3)実装方針など開発に関する議論が残されることで,他の開発者と将来の開発者はコード変更についての理解が容易になる。開発過程のデータベース化は,次世代の開発者にとって大きな財産となる。
4)開発内容とソースコードが関連付けられ,どのような目的で,どのようにコードが変更されたかを誰もが見えるようになる。これにより,モデル利用者に対して,なぜそのような変更を行ったのかを説明する責任を果たすことになる。これは,現業使用や外部提供もされる MRI.COM にとって重要である。
5)Redmine でチケットを一覧表示させることで,モデル開発の全体の進捗を共有できる。
(引用終了)

気になる点は下記がある。

(引用開始)
上記 5)で挙げた開発進捗の共有は特に重要であるので,実際の MRI.COM の開発について,チケットを一覧表示した Fig. 5 を例にして,より詳しく説明する。
MRI.COM では 1 ヶ月単位のリリース・サイクルを採用しており,例えば 2014 年 5 月末に Ver.3.3.15,2014 年 6 月末にVer.3.3.16 をリリースした。Fig. 5 に示す Redmine でのチケット表示もリリース・バージョンに紐付けられ,Ver.3.3.15 では 16 件の開発事項があったことが分かる。
MRI.COM ではこれらチケット内容をまとめることで,例えばバグ修正 4 件,機能追加 3 件,それ以外が 9 件などの「リリースノート」を,新しいバージョンのソースコードと同時に公開している。
(引用終了)

上記の内容は、ロードマップ画面をリリース計画またはリリース履歴と用いることで、「開発者は自分の作業だけでなく全体の開発の進捗状況も簡単に把握できる。」メリットが得られた、ということ。
「これはチーム開発にとって必須の機能である。」と念押ししているように、ロードマップ画面の機能を十分に理解されていると思った。

さらに読み進めると、スーパーコンピューターのリプレースに向けたモデルの移行作業など、色んなプロジェクトにもRedmineを適用して運用しているらしい。

【3】まとめとしては、下記の通り。
GitとRedmineを非常に上手く運用していることがよく分かる。

(引用開始)
まず,ソースコードの開発履歴を管理するバージョン管理システム「Git(ギット)」と,開発のタスクを管理するプロジェクト管理システム「Redmine(レッドマイン)」を導入した。
そのうえで,開発のステップを,課題の設定,他メンバーへの説明,コーディング,レビュー,テスト,リリースと区分し,そこで行うことを具体的に定める「開発手順の標準化」を行った。これらの取り組みにより,バグの混入や意図しない実験結果の改変を抑制しつつ,モデルの集団開発を効率的に進める体制が確立された。
これによるメリットは多々あるが,とりわけ,複数の開発者による並行開発の円滑化,開発過程のデータベース化,ある変更を本体に取り込む前に他の開発者がチェックする「コードレビュー」の必須化,安定版と開発版の 2 系統維持,テスト自動化は,モデル開発において有益である。
また,開発手順の標準化は,他部署や他機関の人が行ったバグ修正や開発も通常の手順で幹のソースコードに取り込む体制が確立されたことを意味する。
(引用終了)

【4】今後の課題として、下記が挙げられている。

(引用開始)
1 つ目は,開発管理を担っている開発管理サーバーに,セキュリティの制約により外部からアクセスできないことである。2013 年から実施している JAMSTEC,東京大学,九州大学とのモデル開発に関する共同研究では,JAMSTEC のサーバーで Git と Redmine が稼働している。将来的には,より広い共同開発のために,海外主要モデルで行っているように github 等のインターネットでアクセスできるシステムを利用するのが望ましいように思われる。
2 つ目は,ソースコード公開の制約と著作権である。外部ユーザー向けの貸与制度を 2012 年に開始したのに加え,上記の共同研究の参加研究機関内ではソースコードを共有している。しかし,原則として,MRI.COM のソースコードは非公開である。日本の研究コミュニティの支持を得るには,抜本的な変更が必要になると考えられる。
3 つ目は,ユーザー向けサポートである。第 4 節で述べた MXE の作成や,力学フレームワークと主要なオプションを解説したマニュアルの公開などがおこなわれているが,MRI.COM 習熟のハードルは高く,よりきめ細かいサポートが必要である。
(引用終了)

オンプレでGitとRedmineを主体とした開発管理サーバーを運用されているので、外部に公開する時の懸念点が今後の課題として挙げられている、と思った。

【5】3/2に、気象庁の方がSEA関西プロセス分科会で講演されるので、色々聞いてみようと思う。

天気予報を支える数値予報システムの技術 第71回 SEA関西プロセス分科会 - connpass

| | コメント (0)

2018/12/20

Redmine 4.0.0 released !!

ずっと待ち続けていたRedmineのVer4.0がついに先日リリースされた。
ラフなメモ書き。

【参考】
Redmine 4.0.0, 3.4.7 and 3.3.9 released - Redmine

Redmine3.4.0 Released !: プログラマの思索

Redmineの新機能開発チケットの記事のリンク: プログラマの思索

【1】今回のリリースで最も重要な点は、Rails5に対応したことだろう。
最新のRubyやRailsに追随することで、セキュリティパッチや最新ライブラリへの対応などがやりやすくなるはずだ。

【2】リリースされた機能改善のうち、個人的に重要と思うチケットは下記がある。
一つは、メールを非同期的に送信する機能改善だ。

Feature #26791: Send individual notification mails per mail recipient - Redmine

Redmineを導入すると、時々、チケット更新が遅いと言われる時がある。
たいていの原因は、チケット更新のメール送信時にメールサーバーとやり取りしてタイムラグが発生する場合だ。
たとえば、大量のチケットを一括更新すると、メール送信が完了するまで次画面が表示されない症状が発生する時がある。
よって、今回の機能改善により、Redmineの性能改善に役立つ可能性が非常に大きくなる。

もう一つは、Wikiのシンタックスハイライトが100個以上の言語に対応されたこと。

Feature #24681: Syntax highlighter: replace CodeRay with Rouge - Redmine

以前から、VBやC#などのソースがコードハイライトされない問題があった。
だが、CodeRayからRougeへ変更されたことで、この問題も解決された。

よって、チケットやWikiに技術情報をたくさん残そう、というユーザの動機づけにも役立つだろう。
Redmineに情報が集約されれば、いつでも誰でも共有できるからだ。

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

Redmineの次期バージョン3.4の見所: プログラマの思索

【3】リリースニュースの中で、Bernhard Rohloffさんのコメントが最も興味を惹いた。

(引用開始)
Thanks to JP and all the people who made this release possible!
Redmine 4.0.0 will be a great base for further improvements in the future and keeps the community vital.
(引用終了)

(超意訳)
JPLとリリースを可能にしたすべての人々に感謝します!
Redmine 4.0.0は、将来のさらなる改善のための偉大な基盤となり、Redmineコミュニティの存続を維持させてくれます。

特に、日本では、Redmineがプロジェクト管理システムとして、事実上ミッションクリティカルな状況になっているので、Redmineが活発に開発されていくことには重要な意義がある。

今後もRedmineを安定運用したいならば、ソフトウェアの寿命が長持ちするように、Redmineコミュニティもずっと活発で居続けなければならない。
そのためには、熱心なユーザと活発にパッチ貢献する開発者、そして活発にコミットするコミッタの三者の活動が鍵を握る。

幸いなことに、Redmineコミュニティは、プロジェクトマネージャとRuby開発者という、人的属性が相異なるユーザ層から成り立っているので、開発プロセスの運用事例や技術的なカスタマイズ事例だけのテーマに偏ることなく、多様な観点で議論できる強みがある。

今後もRedmineをウォッチしていく。

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

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

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

チケットの粒度と進捗ビューの関係: プログラマの思索

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

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

Redmineインスタンスとプロセスの関係~Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

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

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

より以前の記事一覧