« これはあなたの人生です | トップページ | OSSのMSProjectクローンProjectLibre »

2015/03/22

Redmineの理想と現実~RxTStudy #12 「ITS活用最前線~現場からの実践報告」の感想

第12回RxTStudy「ITS活用最前線~現場からの実践報告」で司会&モデラーをしてきました。
大手SIのRedmine導入事例が聞けたこと、本音ベースのパネルディスカッションができて、参加者からも満足度が高かったように感じました。
以下ラフな感想。

【参考】
RxTStudy #12 「ITS活用最前線 ?現場からの実践報告?」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

RxTStudy #12 「ITS活用最前線 ~現場からの実践報告?」 - Togetterまとめ

題12回RxTstudy「ITS活用最前線 〜現場からの実践報告〜」 - Togetterまとめ

【1】前田さん

【1-1】Redmine本家の話が興味深い。
前田さんは、最近コントリビュータになられたので、Redmine本家にある3千~4千ものチケットを整理したりしている。
実質コミッタ2人で運営されているので、人が足りない気がしている。

Redmine本家のチケットでは、バグ、機能、パッチの3つ。
パッチとバグの使い分けが曖昧な所が惜しい。

チケットのResolutionは、コミッタなど一部の人だけが更新できるようにするために、ワークフローの設定により、権限制御で更新できないようにしている。
この話を聞くと、ワークフロー設定画面でカスタムフィールドの更新制御や、ロールによるステータス遷移の制御の機能がある理由は、Redmine本家の運用に役立てているからだろう、と推測する。

基本的なワークフローは、New→Resolved→Closed。
起票→SVNのTrunkへコミット→チェリーピックしてリリースブランチへマージ→Closeの流れ。
つまり、コミッタの作業状況やブランチのステータスに合わせたフローにしており、すごくシンプル。

カテゴリは、Redmineの機能単位で運用している。
開発者や起票者にとって、すごく使いやすいらしい。

Redmineチケットは約3千~4千個オープンされている。
そのうち、重要なチケットをバージョンに対応付けて、小さなToDoリストにしている。

【1-2】口座振替の請求処理をRedmineで運用している。
MyRedmineのサービスが当初より増えて作業が煩雑になったので、Redmineを導入した。

振替データ確定締切日=バージョンに設定している。
つまり、事務処理の締め日=バージョンに対応している。

この話を聞くと、Redmineバージョンは、基本的にはマイルストーンと対応しており、事務処理では締め日で対応づけると、運用が回りやすいという事実を示していると思う。

【1-3】ヘルプデスク処理は、メールによるチケット登録から、顧客が問合せチケットを登録する運用に切り替えた。
利点は、無駄な挨拶文が減ったこと。

工夫した点はいくつかある。
一つは、チケットの項目を減らして、チケットをメールフォームに似せるようにして、顧客の心理的負担を減らしたこと。
もう一つは、他の顧客のチケットを見れないように権限制御を行ったこと。
つまり、情報セキュリティの運用が非常に重要な要件であること。

実際は、不要項目は非表示にしたり、読み取り専用にすることで、チケットをメールフォームに似せた。
さらに、ロールの「表示できるチケット」=作成者か担当者であるチケット へ設定して、他のお客様が作ったチケットは見れないようにし、顧客は自分のチケットしか見れないように設定した。

また、プロジェクトのメンバー一覧で、顧客のロール=「非メンバ」に設定して、チケットの担当者プルダウンに他の顧客が出ないようにした。
Redmineでは、チケットの担当者プルダウンに、非メンバーは出ない仕様だから。

上記の話を聞くと、「非メンバー」「表示できるチケット=作成者か担当者であるチケット」のように、Redmineのデフォルトの機能を非常にうまく運用していると感じた。

【2】赤羽根さん

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

島津製作所内の業務システム運用、IT全般統制にRedmineを導入した事例のお話。
昨年のSQIPの経験事例に相当する。

前提条件として、Redmineに登録される情報としては、事案関係モデル 3.6万件/年、ソース修正2万コミット/年もある。
つまり、1年で3.6万件のチケットが登録更新され、SVNコミットが2万リビジョンもある事実を意味する。
約5年もRedmineを運用されているらしいので、チケット数はゆうに10万は超えている。

だから、この環境でのRedmineでは、チケットの検索や使い勝手など、性能要件が非常に重要視されるだろうと推測される。
赤羽根さんはRedmineの性能検証で優れた検証結果を公開されているので、最新のRedmine3.0でどれだけ性能要件が良くなったのか、聞いてみたい。

【3】陸野さん

パナソニックの組み込みソフトウェア開発で、Redmineを運用した事例のお話。
昨年のSPESでベストプレゼンテーション賞を受賞された経験事例。

【3-1】陸野さんはSEPGとしてCMMI/PSP/TSP、アジャイルなど数多くのプロセスを導入、運用されてきた。
その過程で、現場にたくさんパッケージ製品のプロジェクト管理ツールを入れてきたが、そのたびに失敗した。

パッケージ製品のプロジェクト管理ツールは、作った会社のプロセスが織り込まれている。
しかし、ツールを使う会社の現場のプロセスにはなかなかフィットしない。
だから、現場の抵抗も強く、ツールのメリットがなかなか出ない。

しかし、Redmineなら、組み込みエンジニアも拒否感がない。スムーズな導入ができた。
実際、Redmineを見て、陸野さんも上司の方も、Redmineなら現場の拒否反応も少ないだろう、いろんな場面に適用できるのでは、という感触を持ったらしい。

【3-2】事例としては、オフショア開発チームと国内のチームがRedmineで障害管理を運用した事例、設計~結合テストまでの大規模組み込みソフトウェア開発の事例、社内の別のBTSとRedmineの連携などの事例が紹介された。

Redmineの利点はいくつかある。
一つは、Redmineはデータや運用の切り替えが簡単なこと。
たとえば、最初は一つのプロジェクトで10人で運用し始めた後、人数が増えてきたら、サブプロジェクトを作って、メンバー数に応じたタスク管理に分割して、切り替えて運用できる。
あるいは、過去のチケットデータをエクスポートして、修正してインポートしやすい。

つまり、柔軟な運用がRedmineでは非常にやりやすい。
他のプロジェクト管理ツールでは、途中で運用ルールを変更するのが難しい状況が多いから。

もう一つは、Redmineを運用すると、ツールを皆で使っている感覚になること。
たとえば、Redmineのガントチャートは担当者が出なかったり、日別の表示がなかったり、ちょっと使いづらい。
だから、チケットをCSV出力して、Excelマクロで簡単なガントチャートを表示するツールを作る人も出てきた。
つまり、Redmineが使いくい状況があったとしても、自分たちで工夫してプロジェクト管理を楽にしようとする雰囲気が出てくる。

他にRedmineを機能拡張した事例として、チケット生成ツール、顧客側BTS連携、ガントチャート生成、メトリクスシート生成、工数登録モニタリングなどがあった。
ほとんどが、RedmineチケットをCSV出力して、Excelマクロでガントチャートやメトリクスを生成したり、逆に、Excelでチケットの元ネタを作ってCSVを吐き出してRedmineにインポートする、とか。
あるいは、RedmineからCSV出力したチケットデータを顧客側BTSのフォーマットへ変換してインポートするツール、とか。
Redmineプラグインも10数個は社内で開発されたらしい。

【3-3】さらに、Redmineを運用して、担当者を必ず入れることで、信頼関係が強化されたこともあった。
オフショア開発チームがQAをチケット登録した時、問い合わせる担当者が誰か分からない、と言われた時があった。
そこで、国内チームで担当者を決定し、QAの回答をスムーズに行えるように調整した。
つまり、必ず、担当者を決めて回答させるようにした。
そういうやり取りが蓄積されて、オフショア開発チームとの信頼関係が良くなった、という効果もあった、と。

【3-4】Redmineにスクラムを組合せて運用した事例も興味深かった。
組み込みソフトウェア開発では、工場やハードウェア部門の権限が大きいから、彼らの信頼を得ることが非常に大切。
だから、ソフトウェア開発者は必ず期日を守るように運用したい。
しかし、実際は難しい。

スクラムを導入した時、計画時にタスクをRedmineチケットで一括登録し、1週間単位の進捗管理を導入したら、計画後の是正対策で早めに動けるようになった。
運用サイクルとしては、毎週金曜に進捗のふりかえりを実施し、1週間の作業内容を精査し、来週の作業計画を修正する運用だったらしい。

また、ユニット(チーム)単位でサブプロジェクトを作り、サブリーダーに進捗管理を担当させたら、各チームで自発的な改善がしやすくなった、と。

この辺りの感覚はとてもよく分かる。
Redmineのロードマップ機能は、アジャイル開発ととても相性が良いからだ。

【4】サンデル教授の白熱教室みたいなパネルディスカッション

昨年のredmine.tokyoのパネルディスカッションを真似て、関西でもお題に対し、パネラーや参加者の意見を話してもらいました。
僕はモデラーと言っても、議論を発散させるだけで割と楽な運用でした。

議事録が取れなかったので、思い出したことだけ書いておく。

・現実的には補完チケット方式だが、理想は完全チケット方式という意見が多かった。

・Redmineは最初はオープンソースの開発方式を元に作られているので、アジャイル開発と相性が良い。
しかし、その後の機能拡張をふりかえると、エンタープライズ系の観点の機能追加が多い。
JPL自身も、ユーザのリクエストでも、エンタープライズ系の要件が多いのだろう。

・Redmineのチケットは基本は社内なら、協力会社でも顧客でも公開してアクセスできるようにしている。
但し、新製品の機密情報はRedmineのプライベートチケットで運用し始めている。

今後は議事録を取るようにしたい。

【5】RedmineのチケットをCSV出力した後、CCPMの観点でメトリクス集計した事例を@nmrmsysさんが発表された。
Excelマクロなどのツールでコンバートすればいいから楽だろうと思う。

RedmineとExcelを使ってCCPMっぽい事をしてみる - X-Projects with CCPM

他の感想は別で書く。

【追記】
他のスライド資料はコチラ。

|

« これはあなたの人生です | トップページ | OSSのMSProjectクローンProjectLibre »

コミュニティ」カテゴリの記事

Redmine」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« これはあなたの人生です | トップページ | OSSのMSProjectクローンProjectLibre »