« 2015年12月 | トップページ | 2016年2月 »

2016年1月

2016/01/31

もう一つのRedmine製パッケージ製品ANKO REDMINE

Redmine製パッケージ製品ANKO REDMINEなるものをネットで見つけたので、メモ。
Redmineのパッケージ製品を提供しているのは、アジャイルウェア(株)やHolon(株)だけではないようですね。

【参考】
Ankosoft Redmine Jenkins SVN ALM PMS | ANKO REDMINE

Ankosoft Redmine Jenkins SVN ALM PMS | anko_gantt_chart

Ankosoft Redmine Jenkins SVN ALM PMS | anko redmineクラウド

ANKO REDMINEは、Redmineをベースにプロジェクト管理機能を強化したツールらしい。
要件管理と要件追跡表、プロジェクト別・ユーザ別の進捗のモニタリング、バグとリリース管理機能の強化、テスト管理、コードレビュー、ガントチャートの強化があるらしい。

興味を惹くのは、テスト管理、ガントチャートの機能だろう。
テスト管理の画面を見ると、TestLinkのようにテストケースを左ペインでツリー構造に操作できるみたいで、テストケースのフォーマットもTestLinkのそれに似ているみたい。
また、要件とテストケースが連動しているようなので、要件管理と要件追跡表の機能と連携できているのだろう。
つまり、要件からテストケースまでのトレーサビリティが実現できるのがウリなのだろう。

テスト結果のレポート機能がどんな画面なのか、見てみたい。

また、anko_gantt_chartでは、Redmineのガントチャートを以下のポイントで機能拡張しているらしい。
Redmineのガントチャート画面で、マウスドラッグで日付を変更したり、チケット操作できるのは便利。

(引用開始)
ポイント1:新規チケット登録
ポイント2:子チケット登録
ポイント3:日付の変更
ポイント4:チケット内容の変更
ポイント5:マウスドラッグによる日付の変更
ポイント6:担当者の表示
ポイント7:日付を表示
ポイント8:チケットの予定開始日と予定完了日表示
ポイント9:プラグインで提供
(引用終了)

但し、アジャイルウェアのLychee Gantt Chart Pluginに似ている感じだが、微妙に違うみたい。
今度、デモ画面で違いを見てみたい。

Lychee Redmine
Lychee Gantt Chart Plugin | Lychee Redmine

Redmineをサポートするベンダーが増えるのは、Redmineがエコシステムとして充実し、ユーザの利便性を高めるという観点で重要だろうと思う。
色々紹介していきたい。

| | コメント (0)

AgileMetrics入門がとても分かりやすい

太田健一郎さんの資料「Agile Metrics入門」がとても素晴らしいのでメモ。
以下は、資料を読んで自分の理解をラフなメモ書き。

【1】「アジャイル開発におけるメトリクス取得の目的」として、「チームとプロダクトの健康状態を確認する」点が挙げられているのは同意。

【2】「メトリクスのやってはいけない」点の列挙も同意。いわゆる、メトリクスの罠。
特に、マネージャはEVMや信頼度成長曲線が大好きなのだが、それだけではプロジェクトの詳細は分からない。
あくまでも、健康診断や人間ドックの診察結果にすぎない。

【3】アジャイルメトリクスの入力元として、チケット管理、バージョン管理、CIツール、デプロイツール、本番監視管理ツールが挙げられている。
これだけのデータがあれば、システムの品質や開発チームの開発速度のメトリクスも精度が高くなるだろう。

【4】興味を惹くのは、アジャイルメトリクスとして、どんなメトリクスを採用しているか、という点だ。
基本は、Velocityとストーリーバーンダウンを選択しているようだ。
他に、CIでのテスト通過率、テスト増加率、ストーリーポイントの実時間比などが挙げられていた。

個人的には、Velocityとサイクルタイム(ステータス間の更新時間間隔)、またはリードタイム(要望受付からリリースまでの期間)が基本的なメトリクスと考えていた。
上記に絞られた意図がもっと知りたい所。
たぶん、データの収集のしやすさ、メトリクスの有意性から、そのような決定がなされたのだろうと推測する。

【5】アジャイルメトリクスの評価の観点も面白い。

たとえば、ポイント単位のバーンダウン/日、テスト通過件数/日から、悪い傾向は、テスト不合格が増加するケース。
Velocity/日とメンバーの実作業時間/日から、悪い傾向は、Velocityは一定又は低下して、メンバーの作業時間が増えているケース。
スプリントのVelocity、実作業時間/ストーリーポイントから、悪い傾向は、Velocityは一定又は低下して、メンバーの1ストーリーポイントの実作業時間が増えているケース。

悪いケースのいずれの場合でも、そういう結果が出てきたら、開発者がどんな心境で、どんな作業をしているのか、経験者なら想像がつくに違いない。
そういう傾向をメトリクスでいち早く検知できるのも面白い。

【6】気になるのは、「OSS 主要ツールからメトリクスを収集して可視化 」というページで、measurementorというツールが紹介されていた点。
「現在、書籍"Agile Metrics in Action"の発売に備えて開発中」と書かれているが、アジャイルメトリクスの収集・集計ツールなのだろうか。

GitHub - cwhd/measurementor at development: The code from Agile Metrics In Action; A system to collect data & display metrics for application lifecycle intelligence.

下記の本なのだろうか?

Agile Metrics in Action: Measuring and Enhancing the Performance of Agile Teams: Christopher W. H. Davis: 9781617292484: Amazon.com: Books

情報がないか探してみる。

| | コメント (0)

TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法

TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法が公開されていたのでメモ。

【参考】
TestLinkで手動テストと自動テストを統合する : Jenkins編 - Qiita

TestLinkで手動テストと自動テストを統合する : JUnit編 - Qiita

TestLink

TestLink Cloud Hosting, TestLink Hosting - Installers and VM

TestLinkOpenSourceTRMS/testlink-code: TestLink Open Source Test & Requirement Management System

TestLinkのdocker imageをdockerhubにアップロードしてみた - Qiita

Unitils ?

TestLink Plugin - Jenkins - Jenkins Wiki

ootaken/TestLinkJenkinsIntegration: sample of integration of TestLink and Jenkins

(引用開始)
そのような徐々に自動テスト化していく中では手動テストと自動テストを同時にリグレッションテストやスモークテストとして行ったりするので、両方をまとめて管理したい、まとめて状況を見たいというお話をマネージャーさんからリクエストされることが度々あります。
私にそんな話が来るぐらいと言うことは世の中でもそういうニーズがあるに違いない、そもそもHPのQuality CenterやIBMのRational Quality Managerのような商用のテスト管理ツールにはそういう機能ありますね。
でも、そのためだけに商用を買うのも・・・っていうことで、俺たちのOSSテスト管理ツールのTestLinkにもそういう機能がありました。
というのでTestLinkの自動テスト統合機能を調査してみましたのでまとめてみます。
(引用終了)

上記の手法は、JUnitでテスト自動化した結果をTestLinkに取り込んだり、Jenkinsのビルド結果をTestLinkに取り込んで、そのテスト結果や分析結果をTestLink上で表示させる手法だ。
方向性としては、TestLinkにはAutomationという設定があり、自動テスト結果を取り込むAPIやUIが用意されているので、それを使うというアイデアだ。

なぜそんな手法が必要になるのか?
プログラマとしては、テスト結果は終わった結果なので、そこまで興味があるわけではない。
しかし、マネージャや品質保証部の担当者としては、最新のテスト結果が欲しかったり、日々のテスト結果の履歴から品質分析したいという要望がある。
つまり、マネージャなどの利害関係者向けに、テスト結果のレポートツールが必要なわけだ。

そこで、テスト結果のレポートツールとしてオープンソースのTestLinkがあり、TestLinkの自動テスト結果取り込み機能を使えばうまくいくわけだ。

上記の記事を読むと、設定方法には色々な試行錯誤がいるようだが、利害関係者に見せるには十分な機能だろうと推測する。

TestLinkに一度データが入れば、TestLinkに溜まったテストデータを解析すれば、色んな知見が得られる可能性もある。

最近の僕はTestLinkの情報を追いかけていなかったが、2016/1時点で、Ver1.9.14までマイナーバージョンアップされているようだ。
この辺りの情報も調べてみたい。

| | コメント (0)

2016/01/29

製造業の生産管理による標準化手法はソフトウェア開発に適用できない

製造業の生産管理による標準化手法はソフトウェア開発に適用できないのではないか、という考えをメモ。
ラフなメモ書きなので、ロジカルではない。
間違っていたら後で直す。

【1】製造業の生産管理に触れて、その中身を見ていくと、ソフトウェア業界に身を置く者としては、全く異質な感触を受けている。

例えば、Industorial Engineeringという手法がある。
IEという作業研究の手法を使って、工場での旋盤の加工方法、モノの運搬、納品物の受入検査などを効率化するために、人の手や体の動作、人と機械の配置とモノの流れなどを徹底的に情報収集し、分析する。
無駄な動きを省き、効率良くモノが流れるように、工程図やレイアウト、フローなどの図を書く。

IEのような手法は、工場だけでなく、ファストフード店、スーパーのレジ作業、旅館のサービスなど、労働集約的なサービス業にも適用できるだろう。
おそらく、大量の低賃金労働者を集めて、標準的なマニュアルに従って、大量の作業を効率的にさばくのに有効なのだろう。
しかし、そのような手法は、ソフトウェア開発に適用できるのか?

プログラムを書く時に、詳細設計書に書かれた日本語の仕様をそのまま書き写して1字1句間違えないようにプログラムを書く、などの作法を標準化して、プログラミングすべきなのか?
多分、そのやり方は20年以上前のソフトウェア開発のやり方だ。

ソフトウェア開発が、低賃金の労働者による労働集約的な産業ならば、それはできるかもしれない。
でも、現代ではありえない。
ソフトウェア開発の作業の標準化、属人性の排除は、日本企業は大好きなのだが、今まで成功した事例の話をほとんど聞かない。

【2】ある人から、Redmineで作業の生産性を測定したいという要望を聞いた。
僕は、作業ごとに、設計者が自分が書いた設計書を元に見積りして予定工数をチケットに記録し、開発者が与えられた仕様書を元に実装した実績工数を付けるだけだと思っていた。
しかし、話を聞くとどうやら違うらしい。

話を聞くと、予定工数、実績工数とは別に「基準時間」という概念をチケットに入れて、生産性を測定したいらしい。
では、基準時間とは何か?

たとえば、Javaや.NET、Cobolのような言語と、画面・帳票・バッチのようなシステム機能の組合せで、熟練した開発者ならば、これくらいの標準時間で作業できる、という指標を基準時間で定める。
その基準時間を元に、開発者の作業ごとの実績工数を採取して比較し、その差分から生産性の善し悪しを評価して、開発者への発注金額の評価に使いたいらしいのだ。

この発想は、生産管理における時間研究の標準時間の測定の考え方と同じだ。

たとえば、マクドナルドのようなファストフード店で、ビッグマックを作る場合に、熟練者なら標準的なマニュアルに従って、標準時間はこれだけかかるだろう、という基準時間をあらかじめ定めておく。
その基準時間に対し、あまり熟練していない作業者には、レイティング補正を行い、基準時間よりもやや長めに幅を持たせて、作業の標準時間を定めて、その作業者の生産性の指標に使うわけだ。
この手法を使うことによって、作業者毎の生産性や熟練度を評価できる。

そもそも、そんなやり方をソフトウェア開発に適用できるのか?

20年以上前なら、Cobolなら、何LOCで生産性はこれくらい、というメトリクスを計算できていたのだろう。
しかし、現代のようなソフトウェア開発で、Javaなら何LOCの規模で標準時間はこれくらい、Rubyなら何LOCの規模で標準時間はこれくらい、と測定がそもそもできるのか?
標準時間、基準時間という概念を現代のソフトウェア開発に実現できるのか?

ソフトウェア開発が、低賃金の労働者による労働集約的な産業ならば、それはできるかもしれない。
でも、現代ではありえない。
実際、ソフトウェア開発の見積り手法は、たくさんの知見はあるが、どれも一長一短であり、まともに使えない。

【3】製造業の生産管理の経験が深い人は、ソフトウェア設計や要件定義は、CADのようなツールを使って一気通貫でプログラミングできないのか、とよく言う。

CADで実物に近い製品イメージを作り、その内容を詳細化し、CAEを使って製品動作をシミュレーションして解析したりする。
自動車のモデルをCADで作り、自動車の衝突安全分析などをCAEでシミュレーションするイメージでいい。
そして、CADやCAEで製品仕様を固めた後、CAMで製品を生産するための工程設計に落とす。

似たようなやり方をソフトウェア開発に適用したとしたら、RADのようなツールでプロトタイプを作り、そのプロトタイプに対して色んなテストデータを投入してシミュレーションないしテストを行うようなプロセスになるだろう。
20年以上前に流行したRADみたいなやり方だ。

でも、現代のソフトウェア開発でそんなやり方ができるのか?
設計書だけ作れば、プログラミングなどせずに、プログラムはモデルから自動生成させるだけであり、必ず設計書のモデルと同期させるようにすればいいのかもしれない。
しかし、頻繁な仕様変更やバグ修正を行ううちに、ソースを直接修正するようになり、モデルとソースは乖離し、設計書は古くなっていく。
たとえば、ソース1行の修正なのに、モデルの修正の方が手作業でたくさん修正しないといけない場合も多い。

個人的には、超高速開発ツールにも似たような匂いを感じる時がある。
モデルはたしかに重要だが、実装とかけ離れたモデルは無意味だ。

【4】日本の製造業が生み出したリーン生産方式、TPSのような考え方をソフトウェア開発に適用することでアジャイル開発のような考え方を生み出した、という話を聞いてきたし、そうなのだろうと思っていたが、最近は、何か違うような気がしている。

欧米の人は、製造業における生産管理、品質管理の考え方をそのまま取り入れるのではなく、何かしら一工夫を入れてからソフトウェア開発に適用したのではないか。
ソフトウェア開発と製造業という産業構造の違いがあるために、リーンやTPSの考え方は参考になるものの、そのまま適用できず、何かアレンジして、本来の製造業の生産管理や品質管理とは全く違う異質の開発スタイル、アジャイル開発を見出したのではないか。

何かモヤモヤしているけれど、製造業の生産管理や品質管理とソフトウェア開発の中身は異質だと思う。
プログラミング作業そのものの標準化、時間研究による標準時間の規定、CADやCAEによるソフトウェア設計の自動化作業などの考え方は、製造業で成功したやり方に影響を受けすぎていて、そのまま当てはめてもうまくいかない。

生産管理ではよく、5Sや5ゲン主義などの話を聞く。
その発想は確かにソフトウェア開発にも適用できるかもしれないが、ソフトウェア開発はクリエイティブな仕事である、という真理とずれている気がする。
ソフトウェアはクリエイティブな人がその能力を発揮できて初めて良い物が作れる、という真理から外れているからではないか、と直感する。

| | コメント (0)

2016/01/22

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

Ver3.2で、Redmineの検索機能が改善されていたのでメモ。

【元ネタ】
Redmine 3.2新機能紹介: チケットのフィルタ「説明」追加 チケット一覧を説明欄のキーワードで絞り込み | Redmine.JP Blog

【参考】
Redmine 3.0新機能紹介: 検索機能の改善 | Redmine.JP Blog

Redmine 3.0新機能紹介: 前後のチケットに移動するためのアクセスキー | Redmine.JP Blog

Redmine 1.3新機能紹介: チケットのフィルタにおける日付指定 | Redmine.JP Blog

Redmine 0.9 新機能紹介(7): チケット一覧画面の改善 | Redmine.JP Blog

第8回東京Redmine勉強会の感想 #redmineT: プログラマの思索

Redmineの性能を検証した事例~ITS応答性能の調査結果と対策編を読んで #RxtStudy: プログラマの思索

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

@akahane92さんは以前から、Redmineの弱点の一つとして、Redmineの画面の右上にある検索ボックスから全文検索する時にチケット数が20万件を超えると応答時間がすごく遅くなる、と指摘されていた。

受託開発、研究室、デザイナーのタスク管理など、たくさんの作業や障害、QAの履歴がチケットで蓄積されていくと、いつか数万件どころか数十万件のレベルになる。
すると、全文検索が使いにくくなるという弱点が出てくるらしい。

だが、RedmineコミッタのJPLはおそらく、この問題の存在に気づいており、検索UIを改善することで対処しようとしていると思われる。

たとえば、Redmineの全文検索画面には、「未完了チケットのみを対象とした検索」「添付ファイルのファイル名・説明欄の検索」の検索条件を入れたりしている。
また、チケット画面のフィルタに「説明」を追加できる機能がリリースされたおかげで、特定プロジェクトに絞れば、チケットの説明だけに特化した全文検索が可能になる。
また、検索結果の件数を管理画面から指定して動的に変更できるような仕掛けもある。
つまり、デフォルトの検索機能が全文検索にならないように絞り込み検索機能を強化しているようだ。

Redmineのあらゆる画面で検索機能を強化することは、チケット管理システムとして、とても重要な要件だ。
なぜなら、チケットやWikiに蓄積された作業記録やノウハウを、後からいつでも簡単に取り出せる仕組みがなければ、せっかく蓄積されたナレッジを活用できないからだ。
欲しい情報をすぐに取り出せなければ、チケット管理システムの意味が無いだろう。

個人的には、@akahane92さんが指摘されたように、RedmineのデフォルトDBMSをPostgresSQLに変更して、PostgreSQLのマテリアライズドビューを使うようにすれば、トップ画面右上の検索ボックスからの全文検索でも、性能要件がボトルネックになる問題は根本解決できるだろうと思っている。

幸いなことに、Redmineはバージョンアップするたびに、全文検索やチケット画面の検索機能を強化し続けている。
今後の機能改善の内容にも注目していきたい。

| | コメント (0)

研究室の雑務にRedmineを使った事例

研究室の雑務にRedmineを使った事例が公開されていたのでメモ。

【参考1】
研究室にRedmineを導入するメリット - kengo700のブログ

研究室のRedmineの概要 - kengo700のブログ

Redmineのチケットで研究室の物品管理 - kengo700のブログ

RedmineのWikiで用語集 - kengo700のブログ

RedmineのWikiで研究室の学位論文リスト(ファイルサーバへのリンク) - kengo700のブログ

おそらく大学の研究室で、Redmineをどのように使っているか、という事例が詳しく記載されているのが興味深い。

1)ホーム画面に頻繁にアクセスするリンクを貼っておき、使い勝手を良くする。

2)研究の知識やノウハウを蓄積・共有するために、knowledgebaseプラグイン、Wiki、用語集 / Glossaryプラグインを駆使して記録する。

3)研究に関わるイベントをチケット化し、チケット一覧のクエリに「イベント一覧」を作っておく。
たとえば、研究室の進捗報告会、学会、全体ミーティングなど。
イベントをチケット化しておけば、ガントチャートで表示できるので、スケジュールが一目で分かる利点もあるのだろう。

4)研究室の各種装置・設備をチケット化し、「装置・設備一覧」「購入リスト」「実験スペース 」「共有PC」「工作機械」「オフィス機器」「ソフトウェア」などのチケット一覧をクエリ化しておく。
@kusukawaさんによる事例「サーバー機器管理台帳をチケットで管理する」方法と似た考え方。

5)研究室の雑務も別プロジェクトにしておく。
たとえば、ファイルサーバ管理、メールアカウント管理、内部ネットワーク管理、ライセンス管理など。

6)研究室に留学生が多いので、日本語だけでなく英語でも表記しておく。
Redmineは多言語対応しているので、いろんな国の言語で表示できるのが利点だ。

7)学位論文リストのように、Redmineからファイルをダウンロードできるような仕組みを作る。
具体的には、Wikiやチケットに添付、「ファイル」「文書」機能を利用、redmine_wiki_uncプラグインによるUNC パスを利用などがある。
上記の例では、Redmineのサーバからファイルサーバをマウントする手法を使ったらしい。

なお、「redmine_wiki_uncプラグインでUNC パスを利用する方法ではChromeなどのブラウザでは対応していなかった」というコメントがあったが、下記のChrome extensionを使えば、UNCパスからファイルを開くことができた。

DatAnswers Chrome Local File Opener - Chrome ウェブストア

Firefoxのアドオンでも、UNCパスが開けるらしい。

Firefoxアドオンを使って UNCパス からフォルダを開けるようにしてみた。 - ICT備忘録

【2】この研究室が上手いと思うのは、イベントに関わるチケット、装置・設備に関わるチケット、研究のノウハウを蓄積するWikiをそれぞれ別プロジェクトで分離して管理している点だ。
つまり、用途が全く異なる業務は、別プロジェクトで分離して管理できるようにしておく。

そうすれば、せっかくチケットに記録しているのに、情報が散乱して探しにくくなることもないだろう。
Redmineが多種多様なワークフローによって色んな業務に使える特徴と、複数プロジェクトで別々にチケット管理できる利点を上手く組み合わせている。
すなわち、Redmineというサーバーが1台あれば、イベント管理も設備管理もノウハウの蓄積も一元管理できるわけだ。

【3】下記の記事の「Redmineを運用するメリット」が興味深い。

研究室にRedmineを導入するメリット - kengo700のブログ

(引用開始)
Redmineを使うと何がいいのかについて、具体例を使って説明します。
例1:トラブル対応の効率化
例2:物品管理の効率化
例3:研究の効率化
(引用終了)

「例1:トラブル対応の効率化」では、研究室で稼働しているサーバや他の機器などにトラブルが生じた場合のRedmine導入前・後の業務フローがシーケンス図で書かれていて分かりやすい。
やはり、メールや報告書でノウハウが死蔵されてしまい、そのノウハウは誰も使えない。
「チケットがそのまま作業報告書になる」点が最大の利点なのだろう。

「例2:物品管理の効率化」では、共有パソコンの貸し出し履歴をWikiで管理していたが、Wikiの表は編集しにくく、使いづらいデメリットがあった。
物品管理をチケットに置き換えることで、「チケットはWikiに比べて編集しやすい」「チケットは探しやすい」「履歴が残るのでトレーサビリティ(追跡可能性)を使える」「業務連絡メールが自動的に送られる」というメリットが出てくる。

「例3:研究の効率化」では、研究の資料を共有ファイルサーバーで、ファイル名を「yyyyMMdd_xxxx.pdf」のように管理していたらしい。
もちろん、ファイルが散乱して、引き継ぎ資料をまとめるのが大変というデメリットがある。
研究資料をRedmineとGitLabで管理することによって、「チケットに関連情報をまとめられる」「作業記録がそのまま引き継ぎ資料となる」「複数人での作業において、役割分担、進捗、期限などを共有できる」というメリットが出てくる。

そんな話を読むと、チケットに何を対応させて、どんな業務を回したいのか、を深く突き詰めて考えているのかな、と想像する。

【4】最後に下記のリンクが公開されていたので、今後の執筆記事もすごく期待したい。

Redmineに関する記事の執筆予定(またはリンク集) - kengo700のブログ

| | コメント (0)

RedmineでPlantUMLを使う事例

RedmineでPlantUMLを使う事例が流れていたのでメモ。

【参考1】
akipiiさんはTwitterを使っています: "後で読む。RT @aiminginc: Aiming開発者ブログにて、Redmine + PlantUML を活用した技術仕様書作成の取り組みについての記事を公開しました。 是非ご覧下さい! https://t.co/1e261F9DnM"

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

GitHub - dkd/plantuml: PlantUML Plugin for Redmine

PlantUML : Open-source tool that uses simple textual descriptions to draw UML diagrams.

UMLの絵をWikiに貼り付けて、システムの設計思想やアーキテクチャをチームで共有したい時がある。
その時に、PlantUMLを使って、テキストからUMLのダイアグラムを生成して表示する手法もある。

上記の記事によれば、PlantUMLをメリットは、UMLのダイアグラムを生成するテキストのDiffが取れるので、設計の変更履歴として残せる点がある、とのこと。
そういう使い方もあるのは面白い。

(引用開始)
図をテキストで書くことのメリット

・ペイントソフト・ドローツールの使い方に明るくなくても
・プログラムみたいに図が描ける
・エンジニア間だけでなく、プランナーとの情報共有にも活用できる。図なので!
・Redmine Wiki の履歴がテキストで残る。つまり、図の差分が把握できる
・クラス図なんかは そのままソースコードの雛形として使える
・設計段階からコードの全体像を意識することができるので、設計と実装を分離して考えることにもつながる
・順番の入れ替え、追加削除が容易なので仕様変更に強い
(仕様が変わって矢印をマウスで一つ一つ引き直すみたいな経験…ありますよね)
(引用終了)

【参考2】
ソースコードからモデルの絵を自動生成する: プログラマの思索

RedmineのWikiに図面を入れる: プログラマの思索

redmineの wikiマクロで graphviz その1 - あぁ そうだった

redmineの wikiマクロで graphviz その4 - あぁ そうだった

astah*で図を書いて redmineの wikiに埋め込むプラグインを考える その2 - あぁ そうだった

tckz/redmine_wiki_astah - Ruby - GitHub

以前、RedmineのWikiに、graphvizで生成した図や、Astahの絵を表示するプラグインを見つけて使っていた。
Redmineの強みは、プログラム開発を支援するツールとして、単にチケット管理だけでなく、Wikiの強化プラグインも豊富にある点だろう。

今後も色々探してみる。

| | コメント (0)

2016/01/20

RedmineにSSL接続で設定する方法のリンク

Redmineに簡単にSSL接続で設定する方法をリンクしておく。
自分のためにメモ。

【参考】
RedmineにSSLを設定した時のメモ - Linuxとかネットワーク関連の備忘録

【背景】
RedmineにSSL接続させたい理由としては、社外から社内のRedmineサーバーへアクセスするときにセキュアな接続としたいから。
たとえば、ベンダーに開発を委託している場合、社外で作業しているベンダーがRedmineにチケット登録できる環境にすれば、問合せや仕様のQAにすぐに対応できるし、進捗も把握しやすい。

但し、Redmineをセキュアに使う設定方法は、きちんとまとめた方がいいだろう。

【概要】
Redmineの設定ではなく、Apache側の設定で済む。

【環境】
CentOS
Redmine
Apache+Passenger

【手順】
SSL証明書を生成する
(無料で作るので、オレオレ証明書)

Apacheのhttpd.conf を修正して、extra/httpd-ssl.confにSSL接続の設定を書く

Redmineの設定画面で、HTTPSを設定する

強制的にhttps通信できなくするならば、
production.rbに
config.force_ssl = true
を追加する。

| | コメント (0)

2016/01/12

Redmineを利用した製品のメモ、そしてエコシステムに関する考察

Redmineを利用したSIの製品のメモ、そしてエコシステムに関する考察をメモ。

【参考1】
品質の作り込みについて - Fujitsu

「Redmineによる品質管理」のページを読むと、品質予実管理という機能をRedmineプラグイン化したらしい。
おそらく、障害件数やテストケース件数の予実管理を行うために、表形式やグラフで表示する機能と思われる。
チケットのカスタムフィールドを指定して、チケット集計する仕様さえ決まれば、多分実装できるだろう。

効果としては、品質情報の定量化・共有による属人化管理からの脱却、グラフ化により品質問題の予兆に対して早期対応が可能、という結果があったらしい。

【参考2】
他システムとの連携 - Redmineと構成管理ツールの連携|AccuRev -プロセス改善ソフトウェア構成管理・変更管理ツール-|テクマトリックス株式会社

ムービー|AccuRev -プロセス改善ソフトウェア構成管理・変更管理ツール-|テクマトリックス株式会社

ソフトウェア構成管理・変更管理ツールのパッケージ製品AccuRevとRedmineを連携した記事が記載されている。
詳細は分からないけれど、Redmineの構成管理ツール連携機能を利用した製品ではないかと推測する。

【参考3】
日々のいろいろ: [ソフトウェア品質技術]定量的プロジェクト管理ツール(EPM-X, IPF Tools)をインストールしてみる (Redmine用一括インストーラー編)

日々のいろいろ: [ソフトウェア品質技術]定量的プロジェクト管理ツール(EPM-X, IPF Tools)を使ってみる

Redmine, Tracを使った「定量的プロジェクト管理ツール」の紹介

IPAの定量的プロジェクト管理ツールEPM-Xを実際にインストールして、使ってみた事例が記載されている。
これは面白い。
チケット&計測でITプロジェクト運営の体質改善」と照らし合わせながらEPM-Xを使ってみれば、EPM-Xの用途がよりはっきりしてくるのではないだろうか。

【備考】
最近、Redmineのエコシステムという観点で、熱心なユーザとコミッタだけでなく、Redmineの機能拡張や運用サービスを支援するベンダーも重要な存在ではないか、と感じている。

たとえば、Redmineがソフトウェア企業や普通のユーザ企業におけるタスク管理や課題管理で使われるだけでなく、業務そのものに直結する基幹系業務システムになっている場合が多く見られる。
すると、自社でRedmineのサーバーや運用を保守するやり方もありだが、ベンダーの支援を借りるという手段もありえるからだ。

むしろ、普通のユーザ企業はRedmineが支障なく運用することに力を注ぎたい訳ではなく、Redmineそのものを使って業務を円滑に回す方に注力したいものだ。
つまり、Redmineのサーバー保守、運用保守はベンダーに任せたほうが楽な場合もあるだろう。

もちろん、Redmineはオープンソースなので、有償プラグインを作ったり、自社のパッケージ製品と連携させたり、本体自体をカスタマイズすることも問題ない。
こういうベンダーも含めて、コミッタ・ユーザ・ベンダーの三者でRedmineという一つのエコシステムが作れると面白いだろうなあと思う。

たとえば、LinuxやRubyのように、当初は開発者の興味から生まれたツールが、たくさんの人に使われて、エンタープライズ分野にも広く使われるようになり、最終的には、コミッタ・ユーザ・ベンダーの三者によるエコシステムが作られた事例はたくさんある。
ベンダーが大量に参入することで、ユーザの利便性も高まるし、ベンダーの支援によって、オープンソース本体の開発にも好影響をもたらしている部分はある。

ベンダーが参入してビジネスのやり取りが増えるデメリットもあるが、ユーザの観点では、オープンソースのツール自体が永遠に存在し続けて欲しいと思う部分もある。
つまり、RedmineもLinuxやRubyのように、永続的なオープンソースという世界に発展する可能性も秘めているのではないか。

RedmineもLinuxやRubyのように、コミッタ・ユーザ・ベンダーの三者によるエコシステムへ発展できる素質はあるはずだと思っている。

【追記】
以前、こんなコメントがあった。
彼が言うことは正しくて、ベンダーもエコシステムの中の一つの利害関係者にすぎない。
オープンソースのツールは、ベンダーよりも前に、コミッタやユーザが存在して初めて存在するはずだから。

amidaikeさんはTwitterを使っています: "先日とあるRedmineに対しての勉強会にて、会の主催者が「Redmineは富士通や日立などの大手がサポートしていないから使うのに躊躇う」と話し始めた。こいつアホかと思ったが、それに賛同する参加者たちにこいつら大丈夫かと思った。"

| | コメント (0)

Rails製次世代型CRMのFat Free CRM

Rails製次世代型CRMと記載されていた「Fat Free CRM」のリンクをメモ。

【参考】
Rails製、次世代型CRM・Fat Free CRM MOONGIFT

fatfreecrm/fat_free_crm ・ GitHub

Rails Hub情報局: いま読みたいRuby on Rails3アプリ 10選

Fat Free CRM - Ruby On Rails-based open source CRM platform

日本Cloud Foundryグループ ブログ: Fat Free CRM を Cloud Foundry で動かす

どんな中小企業でも、個人事業主でも、営業していたら、見込客や既存顧客の状態を管理したくなってくる。
そこで、CRMに見込み客や既存顧客を登録しておき、営業で見つけた情報や引合の情報を登録して、後で精査したい。

フリーのCRMと言えば、SugarCRMやvTigerCRMが有名だろう。
でも、Railsアプリと言えば、RedmineやGitlabが有名だろうが、Rails製CRMがないか、探していた。
そんな時に見つけたのが、Fat Free CRM。

(引用開始)
今回紹介するオープンソース・ソフトウェアはFat Free CRM、次世代型のCRMを標榜するソフトウェアだ。

Fat Free CRMはRuby on Railsで作られたソフトウェアで、SQLite3やMySQLで利用できる。ごく手軽に導入できるのが利点だ。インタフェースは非常に見やすい。ラベルが色分けされているだけで随分見やすさが変わってくることが実感してもらえるはずだ。

主な機能はタスク、キャンペーン、顧客情報、案件のステータスなどを一元的に管理できる。顧客に対してタスクを紐づけることで、どの顧客が工数が多くなっているのか等も分かる。検索は各アクションに沿ってフィルタリングが可能で、細かく検索できるようになっている。
(中略)
一般的なCRMというと入力項目がとても多く、面倒な感じがしていたがFat Free CRMについてはすっきりとしたインタフェースも手伝ってそんな印象はない。また、スケジュール管理とかぶる機能が多いのも一般的なCRMでは多かったが、Fat Free CRMではタスクくらいだ。次世代型にふさわしい、進化したCRMと言えそうだ。
(引用終了)

パッケージ製品のCRMは、どうしてもUIが使いにくいし、見栄えも良くない。
一方、Rails製のCRMの方がUIも先進的だし、最新の技術も反映しやすいはず。
Fat Free CRMの画面キャプチャや概要を読むと、使いやすそうに見える。

DBに顧客情報や問合せ情報が登録されていれば、そのDBを直接参照することで、他システムとも連携しやすくなるはず。
個人的には、CRMにおけるサポートデスクの問合せ管理はRedmineの方が使いやすいと思うので、Fat Free CRMとRedmineが相互連携できるといいなあと思ったりする。
色々調査してみたい。

| | コメント (0)

2016/01/08

XP祭り関西2016が2/27土に開催されます〜アジャイル15周年ふりかえり〜 #xpjugwest

2/27土にXP祭り関西2016が「アジャイル15周年ふりかえり」というテーマで開催されます。
もうすぐ正式申込が開始されますので、是非お越しください。

【参考】
XP祭りin関西2016 - XPJUG関西wiki

XP祭り in 関西 2016 ?アジャイル15周年ふりかえり? - 日本XPユーザーグループ関西 | Doorkeeper

(引用開始)
今年のテーマは、『アジャイル15周年ふりかえり』
アジャイル開発手法が世に発表されてから既に15年が経過しました。
XPJUG関西では、ここで一度、アジャイル開発手法について振り返ってみたいと考え、「XP祭りin関西」でその場を提供できないか議論を重ねて来ました。

今回、現場で長年アジャイル開発手法に携わっていらっしゃる方々をお招きし、この15年がどうであったか、また、現在、そして未来のアジャイル開発手法がどうなるのか、或いは、どうあるべきなのか、ソフトウェア開発の現場の目線で様々な角度から振り返ってみたいと考えています。
(引用終了)

XP祭り関西も2006年、そして2009年から継続して開催されてきました。
今年は、アジャイル界隈で大物の方(?)をお呼びしてます。

まず、基調講演は東京から関西出身の木下さん。
永和システムマネジメントでは、アジャイル事業部を立ち上げられ、事業部長として、ビジネスでもアジャイルを実践されているのだろうと思います。
どんな内容が講演されるのか、楽しみです。

そして、関西からは、アジャイルラジオで活躍された土屋さんと山根さん、そして、スクラム道関西の方々にアジャイルに関して語って頂きます。

土屋さんと山根さんはXPJUG関西で創立当初から活躍されていて、約5年前からアジャイルラジオというPodCastを流されてました。
アジャイルコミュニティのごく一部では、すごくマニアが多かったように思います。
どんな裏話が出てくるのか、楽しみです。

また、スクラム道関西は、ここ数年とても活発に活動されている関西のアジャイルコミュニティです。
講演者が4人も登壇されるので、どんなサプライズがあるのか、気になりますね。

さらに、企業セッションには、オージス総研の藤井拓さんが講演されます。
藤井拓さんと言えば、オージス総研でアジャイル開発に関する研究所を作られ、その所長をされていると聞いています。
また、オブジェクト指向やRUPからアジャイル開発まで、幅広くソフトウェア設計・開発・工学に関する研究や講演、出版もされています。
講演内容はまだ未定ですが、昨今日本で流行しているドメイン駆動設計などにも触れられるのでしょうか?

最後に、パネルディスカッションでは、私がモデラーの立場で、講演者の方をパネラーにお呼びして、「関西から日本のアジャイルの未来を語る」というテーマで議論する予定です。
久しぶりに、大物のパネラーが多いので緊張しますが、パネラーの体験談を元に、日本のアジャイルの未来とあるべき姿をパネラーに思う存分語ってもらう予定です。

ワクワクした方は、是非お申込み下さい。

| | コメント (0)

2016/01/03

技術的負い目の記事がすごい

技術的負い目の記事がすごいのでリンクしておく。

【元ネタ】
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。
そう簡単にリファクタリングしにくい。
そんな中で色んな対応をされている。
以下、自分が今後参考にしたいためにメモ。

【1】JDKが古い。

古いJDKはセキュリティホールもあるだろうから危険。
性能要件も低いだろう。

→JDK6からJDK8へバージョンアップ。
 Gradleでビルド環境を作る。
 ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。

【2】コード重複率も多く、デッドプログラムも多い。

長年運用したシステムは、デッドプログラムが多い。
でも、リスクがあるから、デッドプログラムをうかつに消去できない。

→リファクタリング、Jenkinsで単体テスト自動化、Sonarでソース解析、Githubフローで開発プロセス改善で30万行を削除。
 その結果、その後の機能改善もやりやすくなった、と。

【3】エラーログ件数が3000件以上もあり、エラーが常態化している。

この状況もよくある。
エラーログが全く使いものにならないから、本来の障害を検知しにくいし、代わりのエラー検知の手作業が増えてしまい、システム運用のコストが大きくなる。

→エラーログ件数のグラフ化して見える化。
 エラー件数が多いエラーをパレート分析して、1つずつ対処していく。
 ログレベルをFatal~Debugまで整理。
 エラーログから検知した内容は、ChatWorkに通知する。
 その結果、一日平均50件ほどまで減らすした、と。

【4】デプロイによってシステムが一時的に壊れる

古いシステムほど、リリース作業のプロセスもデプロイツールも古いままなので、手間がかかりやすい。
その分、リスクも大きい。

→Tomcatを停止する前に、ロードバランサーにワーカーを切り離させる。
 trunkのみでの運用をやめ、プルリクエストベースの開発プロセスとした。
 Tomcatの起動後にアプリケーションがリクエストを処理できるようになるまで待機する処理を入れた。
 リリース内容はChatWorkに通知する、と。

他にも、認識されていない単一障害点、ワイルドなバッチ処理など、たくさんあって、技術とプロセスの両方で改善されたテクニックやプラクティスがすごく参考になる。

| | コメント (0)

ITの地殻変動はどこで起きているのか~技術革新の流れはWebから機械学習やデータマイニングへ

2015年になって、ITの地殻変動がどこに起こっているのか?を考えてみる。
自分の理解が浅いのは承知のうえで、以下は、妄想を含めたラフなメモ書き。
間違っていたら後で直す。

【参考】
機械学習をこれから始める人に押さえておいてほしいこと - Qiita

Pythonでデータの分析を出来るようになりたい(その1) - Qiita

Pythonでデータの分析を出来るようになりたい(その2) - Qiita

Pythonでデータの分析を出来るようになりたい(その3) - Qiita

Pythonでデータの分析を出来るようになりたい(その4) - Qiita

「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

Google、脳のシミュレーションで成果……猫を認識 | RBB TODAY

データサイエンティストを目指すというかデータ分析を生業にするなら読んでおきたい初級者向け5冊&中級者向け12冊(2015年冬版) - 東京で働くデータサイエンティストのブログ

クリスマスイブに「さくらの聖夜」というイベントに行ったら、とんでもない発表が行われていたw #さくらの聖夜 - Blog::koyhoge::Tech

「統計学が最強の学問である」の感想: プログラマの思索

機械学習に関するメモ: プログラマの思索

「データサイエンティスト」の感想~データマイニングが自然科学を再定義し直す: プログラマの思索

教育学は人工知能の研究者によるデータ主導で置き換えられつつある: プログラマの思索

【1】最近思うのは、オープン化、Web2.0、スマフォ・タブレットと進化し続けたWebの進化よりも、データマイニングの技術革新の方がすごく勢いがあるように感じることだ。
今や、スマフォは手のひらサイズのPCであり、Unixであり、これ以上の究極の進化形はないのではないか。

【2】一方、データマイニングの技術は、ようやく必要な機能が一通り揃ってきたように見える。

1)HadoopやStackなどのMapReduceの技術がこなれてきた。
これらの技術によって、データ解析の技術基盤が揃ってきた。

2)データマイニングの開発環境は、クラウドですぐに作れる。データ容量が増えても、スケールしやすい。

3)IoTの概念によって、HWのセンサー機器から大量のデータを収集できるようになった。
他にも、皆が持っているスマフォから、位置情報やSNS情報を収集できる。
あるいは、ドローンやRaspberry Piなど、数多くの機器からも、大量のデータをリアルタイムに収集できる。

4)R言語のような統計学に特化したプログラミング言語が普及してきた。
今なら、R言語よりもPythonの方がもっと手軽に書けるだろう。

5)他にAIの復活。機械学習がAIを復活させたように見える。

【3】機械学習やデータマイニングが今のトレンドになっている理由は、R言語やPythonなどでプログラミングしやすくなり、クラウドで大量データをスケールしやすくなったことだけではないと思う。
機械学習やデータマイニングの背後には、統計学という理論でそれら成果の裏付けが保証できる、という点が最大の理由だろうと思う。

つまり、IoTでセンサー機器から大量のログを収集できた後、それら大量データを帰納法を使って見出した因果関係は、その正当性を統計学が保証できる仕組みがあるからだ。
すなわち、統計学が機械学習から得られた知見の確からしさ、正当性を保証してくれるわけだ。
その因果関係の真の意味は後回しで良く、理論づけはその後で良い。

統計学が最強の学問である」に書いてあるように、昔の統計学は退屈な学問だった。
つい最近まで、せいぜい電卓を使うぐらいで、コンピュータの性能も低く、大量データを手計算で処理するには限界があった。
だから、限られたデータ量から、いかに少ない手数で計算して、因果関係を推測するか、という手法ばかり発達していた。
つまり、統計学の本来のメリットが生かせていなかったわけだ。

しかし、プログラミング言語やMapReduceなどの技術、クラウドなどの開発基盤、センサー機器やドローンやスマフォなどのデータ収集機器が揃ってきて、ようやく大量データから帰納的な理論を打ち立てることが可能になってきた。
そして、誰もが手軽に、センサー機器を組み立てたり、ドローンを飛ばしたり、PythonやRでデータマイニングのプログラムを書くことができるようになってきた。
それらから得られた知見は、統計学を上手く利用すれば、その正しさを保証できるはずだ。

【3】「機械学習やデータマイニングで得られた知見は統計学で保証できるはず」という考え方は、僕にとって既視感を感じる。
つまり、「既存の理論をバックにして、新しい技術を使って試す」というやり方がすごく既視感。

例えば、チケット駆動開発というアイデアは、既に枯れたツールであるBTSやITSをアジャイル開発に適用するという発想から生まれた。
そこから更に発展させて、汎用的な機能を持つBTSをアジャイル開発だけでなく、PMBOKやソフトウェア工学に適用させて、既に知られているプラクティスや理論上の概念を実際に試して評価することもできた。

理論を完全に理解できていなくても、既知の理論にあるプラクティスや概念を片っ端から試してみれば、ノウハウがたまるし、理論のメリットやデメリット、適用の限界なども見えてくる。

同様に、統計学で既に知られている概念やメソッドを実際のプログラムで実現し、実際に機械学習で試してみれば、色んなノウハウが得られるだろうし、理論を使えばもっと良い方法が見つかる可能性もあるだろう。

例えば、「統計学が最強の学問である」では、POSデータ解析でよく使われるバスケット分析は、統計学におけるカイ二乗検定の方が優れている、という指摘がある。
実際、グーグルの共同設立者も「バスケット分析よりも統計学的な相関分析の方がいい」という論文を書いているらしい。

つまり、システム開発で試行錯誤して相関関係を見出したアルゴリズムよりも、統計学にある既存の概念を使った方がはるかに効率的に因果関係を見いだせる場合があるわけだ。

その理論を知っている人なら当たり前のことでも、現場の人はそういう理論は知らない。
逆に、理論を知っている人は、ビジネス経験や実際の応用事例が不足しているから、世間に向けて効果のある知見を披露できない。
だからこそ、プログラミングという強力な武器を持っているプログラマは、理論を少しかじってみるだけでも、新しい知見を見出し、社会に貢献することが可能なはずだ。

【4】とは言え、統計学の手法を実際の応用事例に生かす、という手法は、IT業界以外でも既に幾つか知られている。
例えば、製造業の品質管理技法では、統計学を応用する手法は既に行われている。
実際、製造業では、出荷時に全数検査はできないので、一部の標本を抜き取って品質をチェックする抜き取り検査を行わざるをえない。
その時に、抜き取り検査で得られた品質評価の結果が、他の残りの全ての製品でもほぼ同じで問題ない、という箇所で統計学の推定・検定を使っているわけだ。

品質管理技法は、日本では昔から、QC検定で既に資格化されている。

QC検定 | 一般財団法人 日本規格協会

QC検定2級って奴 受けてみた - Pass Hunter

また、最近ならば、マーケティングにも統計学を応用する動きが見られる。
レコメンドエンジン、バスケット分析、CRMなど、購買分析や顧客分析にも使えるし、ビジネスにより直結する。

統計学検定という資格もあるらしく、3級は高校卒業程度らしいので、理論を習得するのに丁度良いかもしれない。

統計検定:Japan Statistical Society Certificate

日本統計学会認定「統計検定2級」に合格しました - akiyoko blog

【5】機械学習やデータマイニングで気になることは、Pythonの隆盛であり、Rubyがやや遅れているように見える点だ。

例えば、Rubyは、Railsという強力なWebフレームワークのおかげで、Webの世界では大きな影響力を持つ。
また、Chefなどクラウドに関するインフラ技術においても、Rubyという技術は必須であるように見える。
しかし、今のトレンドである機械学習やデータマイニングの世界では、Rubyの影が薄いように見える。

個人的には、Rubyはたくさんのポテンシャルが秘められていると思うので、この方面にも拡張して欲しいと思う。

| | コメント (0)

2016/01/02

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文

JAXAにおけるスーパーコンピュータ活用課でのチケット管理ステムの経験論文がPDFで公開されていたのでメモ。

【参考】
※参照リンクを修正しました。
JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

akipiiさんはTwitterを使っています: "気になる。RT @g_maeda: なんだこれ ? CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム : Redmineの事例と利用のヒント https://t.co/9QlySYSzZk"

MAEDA, GoさんはTwitterを使っています: "@akipii @y503unavailable @takenory JAXAの資料のPDF見つけました https://t.co/msKI89zsCh"

akipiiさんはTwitterを使っています: "@g_maeda @y503Unavailable @takenory これはすごく興味深いRedmineの論文ですね! JAXAにおけるスーパーコンピュータ活用課でのチケット管理ステムの経験論文なわけですな。"

MAEDA, Goさんのツイート: "JAXAのRedmine利用事例の論文( https://t.co/xcay83LGeB )の英語訳が公開されています。 https://t.co/3pt5OnnPXe"

【1】論文の概要は下記の通り。

(引用開始)
Redmine はさまざまな業務に利用できる優れたチケット管理システムで,近年注目されている OSS の一つである.
JAXA スーパーコンピュータ活用課では,2014 年の JSS2 SORA スーパーコンピュータ導入を機に Redmine をベースにした CODA システムを構築・運用している.本稿では,Redmine の利用事例として CODA を紹介する.
合わせて,Redmine を一層効果的に活用するため,CODA の構築・運用経験から見いだされた定義や設定,運用の工夫を紹介する.
(引用終了)

【2】JAXAのスーパーコンピュータ活用課では、運用や支援のための情報共有・進捗管理のために、Redmineをベースにした業務管理アプリケーションを構築したらしい。
論文を読むと、Redmine導入前の運用支援システムには以下の課題があったらしい。
どこも同じような問題意識があったわけだね。

(引用開始)
(1) ドキュメンテーションが不足しており,トラブル時の対応が困難である.
(2) システム種別などの選択肢がソースコード内に散在する,生成されるレポートの形式が固定である,など,新たなシステムの運用に合わせた改修やニーズの変化に対応しにくい.
(3) Web ブラウザ画面の作成に使用している XUL(XML User Interface Language)が特定の Web ブラウザを前提としている上,そのブラウザのバージョンアップに伴って次第に不具合が顕在化するようになった.
(引用終了)

【3】Redmine導入の決定の理由も論文に詳しく書かれているが、その理由の中で興味を惹くのは、下記3点だ。

(引用開始)
・特定の開発や運用の方法論やスタイルを前提としてそれに依存していない
・書籍やインターネットでの情報,特に日本語での情報を入手しやすい
・バグ修正や機能の追加などの開発が活発で,議論がオープンである
(引用終了)

つまり、Redmineがチーム開発における非常に汎用的な機能を持っていること、オープンソースで活発にVerUpされていて、日本のRedmineコミュニティや日本語の書籍の出版が活発である点がすごく評価されている。
こういう内容を読むと、オープンソースのツールの発展は、単なるソースの公開だけでなく、コミッタとユーザが相互に依存関係があり、活発にやり取りして、ツールそのものを進化させていくことが非常に重要であると再認識させられる。
また、Redmineの背後にある「チケット駆動開発」という概念は、アジャイル開発やWF型開発、ISO9001にも適用でき、非常に柔軟性が高いのだろうと思う。

【4】JAXAにおけるRedmineの利用内容も興味深い。

【4-1】日々のイベント・作業の記録・連絡、管理帳票、会議の準備,議事録,To Do 項目、納品物本体 + 目録などの管理で使っているのは、ある程度想像できる。
興味深いのは、ISO-9001 に即した品質保証のプロセスをRedmine上で実現しようとしていることだ。

ISO-9001 の「継続的改善」に規定のある「是正・予防処置」は、Redmineのワークフロー機能と、Wikiや文書機能で具体的に実現できるだろう。
つまり、PDCAのサイクルで確実に作業して検査を終了した、という事実をRedmineのワークフロー機能で実現し、その過程で作られた成果物はチケットの添付ファイルやRedmineの文書機能、Wikiへの議事録・インスペクションの打合せ内容、で実現できるだろう。

そのような内容を考えると、ISO9001や内部統制に準じたプロセスをRedmine上で実現し、そのシステム監査もクリアできるようなノウハウを蓄積して整備することも可能だろう。
そうすれば、RedmineのチケットやWikiの情報の精度が高くなるから、データマイニングによって、障害分析や課題分析、稼働分析などに応用でき、新たな知見をソフトウェア工学へ貢献することも可能だろう。

【4-2】他に、「ロール設定の OR ルール」「カスタムフィールド設定の AND ルール」「プロジェクトの分割の目安」「カテゴリ標準フィールドの活用」など、細かな運用ルールを定めている点は、「組織としてプロセスの標準化を推進する」意識から出ていると推測される。
Redmineの機能をよく研究していると思う。

【4-3】JAXAでのRedmineの利用頻度は、ユーザ数が約 35 名、チケット数は約 3100(2014/1~2015/12)、月々約 300 件程度のチケット登録と記載がある。
数万~数十万のチケット数になれば、Redmineに溜まったチケットはISO9001に即しているおかげで品質がいいだろうから、ソフトウェア工学の研究がやりやすいだろうと推測する。

【4】「Redmine への期待」を読むと、JAXAではRedmineは非常に満足できると評価されている。
「Redmine 本体及びエコシステムという観点から現状と今後の期待を述べる」所で、「OSS の利用を考えるとき,開発が活発か,コミュニティが充実しているか,は非常に重要である.この点,Redmine は活発な開発が行われており,書籍の発行やコミュニティ活動も多い.今後も機能追加や使いこなしの情報が順調に増えると期待できる.」と評価してくれている。
Redmineコミュニティに携わる一スタッフとして、ちょっと嬉しい部分だ。

どこかで発表してくれないかな?

| | コメント (0)

« 2015年12月 | トップページ | 2016年2月 »