プログラマの思索

本日開催された第3回品川Redmine勉強会をUstで見た感想をメモ。

第3回shinagawa.redmine勉強会 : ATND

第3回勉強会 - shinagawa.redmine

shinagawa.redmine 第3回勉強会 - Togetter

【1】Redmineコミッタの@marutosijpさんが、RedmineをRuby1.8→1.9, Rails2.3→3.2へVerUpした経緯やその作業内容について解説してくれた。
僕としては、既存機能をデグレードさせずに環境周りをVerUpするいわゆるポーティング作業は地味だけれども難しい作業だと経験的に思う。

ポーティングとは【porting】（移植） - 意味/解説/説明/定義 ： IT用語辞典

RedmineがVer2.0でRails3へ移行予定: プログラマの思索

Twitter / @akipii: #47redmine ポーティングの例としてはCentOS5→6、JDK1.4→6、Apacheのセキュリティパッチ当て、WindowsUpdateなどたくさんあって、どれも結構神経を使う割には頭を使わない。面白くない作業だけどシステムの延命を考えるととても重要。

ポーティング作業の難しさは、テスト工数と納期のバランスを取ること、OSやライブラリのバージョンアップによってソースの修正が発生するバージョン管理の2点にあると思う。
既存機能に影響がないことをテストするために回帰テストすればよいが、古いシステムほどテスト自動化などないので、手作業のテストになり、どこまでテストすれば良いのか、判断を下しづらい。
だから、この機能は既にテストされたので品質は担保されている、などといった「みなしOK」の判断を下して、テスト工数を削減したりする。
でも、みなしOKの判断を誤ってテスト漏れが発生したりするから、サジ加減が難しい。

また、バージョンアップ前と後のソースを別々にブランチ管理する作業があったり、バージョンアップ前のソースからどのソースを最新の環境に持っていくべきか精査する作業が発生するため、バージョン管理が面倒になる。
だから、前者ではベンダブランチのような並行開発が必要になってくる。
後者は手作業で逐一ソースを精査するしかない。

でも厄介なのは、既存バグを発見したけれども、VerUp後のソースで直してしまうと、既存のソースにもバックポートする作業が発生する時だ。
特に、古い環境と新しい環境を並行稼動するような業務システムの例では、バックポートの作業を忘れると、せっかく直したバグ修正をバグとみなされてしまい混乱してしまう。
だが、古い環境で本番運用されている場合、すぐにバックポートの作業ができるわけではないから、既存バグをきちんと記録しておき、並行運用中に直すというやり方を採用するときもあるだろう。

バックポートとは【backport】 - 意味/解説/説明/定義 ： IT用語辞典

他に、下記のような意見もあり、僕はすべての現場を知らないので何とも言えない。
でも、他の言語やフレームワークなどのポーティング作業(例：CentOS、JDK、Apache、Androidなど)は、今はそんなに楽になっているのだろうか？
例えば、MSがWindowsOSの後方互換性の維持にこれだけ大きな手間をかけているのを見ると、ポーティング作業がそれほど楽なようには思えない。
最近では、AndroidOSのバージョンの違いや後方互換性で、スマートフォンメーカーが苦しんでいるように見える。
とは言え、RailsはVerUpで大きく変わりすぎたし、Redmineインストールに苦しんでいる人が多いのを見るとそうなのかもしれない。

Twitter / @sakaba37: 同意！ RT @akipii: Rubyだからこそアジャイルに開発できたのかも RT @kondoujp: Redmine 2.0 はよく頑張った! って思うし、素直に褒め称えられる。しかし、背景を考えると Ruby や Rails 捨てた方がいいようにしか思えない。

Twitter / @kondoujp: @akipii アジャイルなスタイルで開発を行うことと仕様の不安定さは全く層が異なる話です。はっきり言って、ユーザーとしては使いたいものはサービスであって、Ruby であるとか Rails であるというのはどうでもいいんです。その点で「よろしくない」と思いますよ。

Twitter / @kondoujp: @akipii 他の言語/フレームワークでは、バージョンアップにここまで手間がかかる事の方が不思議なんですけど。「これだけ短期間に VerUp できた」ではなく「VerUp にここまで時間がかかった」という認識です

【2】@tech_machiiさんのLotusNotesからRedmineへの移行作業の事例も興味深かった。
僕の感想は下記に書いた。

Twitter / @akipii: #47redmine　Redmineは中途半端に万能・・なるほど。Redmine導入はERP導入やCMMI導入に似ているなあと後で思います。導入工数と運用のバランスかなあ。。

Twitter / @akipii: #47redmine　redmineのRails3.2へのポーティング、現行業務をチケット駆動へデータ移行という発表を聞くと、こういう地味な開発が現場の業務システム開発でも多いのに気づきます。人の話は役立ちますね。

RedmineはOSSの割には高機能なので、何でもできそうなイメージがあるが、実際はどの業務をRedmineで代用し、他の業務を従来の手運用ないしExcel運用でカバーするか、という切り分けが難しい。
移行作業の工数は無限にあるわけでもないし、納期もあるから、いかに短期間で成果を出していくか、という戦略が大切になる。
似たような話として、ERP導入やCMMI導入では、導入や運用の失敗事例の話が山ほどある。

Redmine導入はERP導入に似ている #tidd: プログラマの思索

ポーティング作業や移行作業の事例を聞くと、業務システムの受託開発に似ているなあと思う。
案件は、いつも綺麗な新規開発ではなく、ポーティングやデータ移行などの地味でつまらない案件も多い。
でも、そのような案件は特にプロジェクト管理の質が良くないと失敗しやすいように思う。

【3】IPAの定量的プロジェクト管理ツールのお話もあった。
RedmineやTracを定量データの収集場所とみなし、データを集計してプロジェクト管理に役立てる発想として作られたらしい。
過去のソフトウェア工学やエンピリカルアプローチは、本来はこのようなツールを基盤として研究されるべきではなかったのか、と思う。
何故なら、RedmineやTracのようなツールがなければ、データ収集に工数がかかりすぎて肝心のプロジェクトの進捗に害があるからだ。

IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索

Twitter / @akipii: #47redmine redmineの利点：SCMリポジトリとBTSの両方のデータを一括集計できる。更新履歴が必ず残るのでシステム監査や追跡に使える。Webのデータマイニング機能で、開発者の作業ログを緩やかに収集・集計する仕組みがある。

Twitter / @akipii: #47redmine　RedmineやTracが無かった頃の人は、どうやって定量データを収集してメトリクスを集計していたのか気になります。多分帳票やExcelを自ら手作業で収集して、手作業でExcel集計(又は手計算)していたのだろうなあ。。昔の人はよくやっていたと思う。

チケット駆動開発の面白さは、アジャイル開発と相性が良い点だけでなく、マネージャをサポートするソフトウェアメトリクスの出力という一面もある。
メトリクスの分析や使い方は罠や癖があるけれども、見える化の一部として使えるだろうと思う。

メトリクスを使った品質管理の技法は、従来の日本の製造業が得意とする開発スタイルだ。
RedmineでWF型開発を行う場合、メトリクスを使う品質管理は相性が良いだろうと思う。

【4】@g_maedaさんのお話も興味深かった。
Redmine.jpにはいつもお世話になっています。

Redmine.JP

Home | Redmine.JP Blog

Twitter / @hell0_wor1d: 前田さんの優しい話し方、Redmine愛を感じる #47redmine

Twitter / @akipii: #47redmine OSSの貢献はソースコードの公開だけでなく、ツールの紹介や情報公開もあるというお話。実際に行動されているだけあって説得力あります。

Redmineが日本でこれだけ普及した理由の一つは、Redmine.jpがポータルサイトとなっていて、初心者から上級者まで誰もが参考に出来る情報が発信されていることだと思う。
単なるリンクの羅列、Wikiの日本語訳、VerUpされた内容の掲載だけでもとても役立つ。

Redmineコミュニティの利点は、日本人コミッタ(@marutosijpさん)がいることと有用な情報が一箇所に集まっているポータルサイト(Redmine.jp)があることだと思う。
コミュニティがツールの発展を支える良い事例の一つになっているのかなあと思う。

他にも@tkusukawaさん、@basyuraさんのお話も興味深かったです。

【5】個人的には、ChiliProjectがA Successful branch modelを採用して一部混乱した時があったという指摘、そして、Redmineではrebaseを多用してtrunkのリビジョンが一直線になるメインラインモデルを採用して混乱なくVer2.0をリリースできたという事実について、その背景を聞きたかった。

Twitter / @cointoss1973: 今日の #47redmine の個人的テーマ: Redmineと連携するリポジトリは、(Gitよりも)Mercurialがオススメという理由がよく理解できていないので、まるやまさんに聞いてみたい

Twitter / @akipii: 明日の予習。いかにRedmineのメインラインを守ってきたのかというバージョン管理の考え方が分かる。　Redmine 2.0 リリース ? shinagawa 20120519 v0.1 documentation　http://goo.gl/PvRds

Twitter / @akipii: trunkはrebaseを使うべきだ、ChiliProjectのRevision graphはdirtyと言う指摘に対し、git-flowモデルだから同意しないという回答。価値観の違い。ChiliProject - Bug #127 http://goo.gl/cTxI9

Twitter / @akipii: git-flowのバージョン管理手法は小規模プロジェクトでしか通用しない。pull requestは大規模オープンソースプロジェクトにはそぐわない。メインラインモデルが一番という指摘がある。明日のRedmine勉強会資料は参考になる　http://goo.gl/PvRds

A Successful branch modelの考え方はgit-flowというGitツールで実装されている。
その考え方はとても面白かったので、いろいろ考えていた。

git-flow による構成管理とRedmineの関係: プログラマの思索

しかし、そのモデルは小規模プロジェクトでしか通用しないという理由がきちんと分かっていないので、経験者から聞いてみたかったなあと思う。
実際、GitHubにあるChiliprojectとredmineをクローンしてコミット履歴を見れば、その違いがよく分かる。

Twitter / @akipii: GitHubからChiliprojectとredmineをクローンしてgit logを見た。Chiliprojectのリビジョンブラフは分岐が多くたくさん手が入って複雑。redmineのリビジョングラフは一直線でコミットログにマージ作業が書かれているので分かりやすい。

この点は資料を解読してみる。