« 2016年1月 | トップページ | 2016年3月 »

2016年2月

2016/02/27

XP祭り関西2016~アジャイル15周年ふりかえりの感想 #xpjugkansai

「XP祭り関西2016~アジャイル15周年ふりかえり」が無事に終わりました。
約60人もの参加者、木下さんの基調講演、山根さんと土屋さんのアジャイルラジオコンビ、スクラム道関西の4人、藤井さんのDtoD、パネルディスカッションと盛り上がりました。
参加者、講演者、スタッフの方、お疲れ様でした。

以下は、僕個人のラフな感想。

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

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

XP祭り関西2016~アジャイル15周年ふりかえり(2016/2/27) #xpjugkansai - Togetterまとめ

fkino diary(2016-02-27) "XP祭りin関西2016 に参加しました"

【1】今日の基調講演は、木下さんの「5分で分かるアジャイルムーブメントの歴史 拡大版」。
日本のアジャイル15年の歴史を凝縮した内容で、とても素晴らしいと思います。
僕は、XPJUG関西に10年以上関わってきたので、とても感慨深くて、色んな思いがありすぎて。

日本のアジャイル本の歴史を辿ると、3回のうねりがある。
1回目はXPブーム、2回目はScrumブーム、そして今3回目。

2000年代前半のXPブームでは、開発者がXPに熱くなっていた。
東京のXP祭りに参加して、あの雰囲気を関西でもやりたいと思って、XPJUG関西で企画したのがXP祭り関西2006。
それから10年も続いている。

2008年頃からのScrumブームでは、プロジェクトリーダーがScrumをチーム運営へ導入して熱くなっていた。
田口さんが、僕はScrumを導入して今まで失敗したことがない、と発言されていたのも思い出す。
未知の領域、新しい技術を取り入れた開発でScrumは大きな威力を発揮する、という趣旨を言いたかったのだろうと推測する。

そんな中、永和システムマネジメントとチェンジビジョンしかXPをやっていないのではないか、という疑惑から、平鍋さんが「アジャイル止める宣言」。
そこからAgileJapanが発足し、マネージャ層、経営層向けにターゲットを絞り込む。
また、IPAも「非ウォーターフォール型開発」という名前でアジャイルの研究会と資料を公開し、最初はIPAでもアジャイルと言えなかったのが、アジャイルという言葉が解禁になった。

そして今、ITがビジネスの中心になっているWebサービスやベンチャー企業では、アジャイル開発が当たり前の環境。
アジャイルでない従来型のSIもあるけれど、ネット上にもプラクティスやアンチパターン、事例が溢れていて、少なくとも知識の上ではもう差別もない。
そんな気がしている。

【2】山根さん&土屋さんのアジャイルラジオコンビのお話。
山根さんがJavaの開発で使ったツールやフレームワークの変遷の話は、僕もすごく同感して、感情移入してしまって。

僕も山根さんと同じく、ファウラーの「リファクタリング」本から入った。
僕は2002年頃、「リファクタリング」本を夢中で読んでいた。その頃はJavaプログラムを書ける初心者レベルだったから、こんな風に使うんだ、という知的刺激が楽しくて。
Eclipse上で、リファクタリングやデバッグ、しかもリモートデバッグまでできるのも楽しくて。

Antも随分使っていた。
WindowsでもUnixでも、同じビルドスクリプトが動くので、単体テストでもテスト環境でも本番環境でも同じようにビルドスクリプトを流用できる。
Strutsに初めて触れた時も、これだ!と思っていた。
今はもう、レガシーなフレームワークだけれど。

JUnit、DBUnitなどのテスティングフレームワークも書いていて楽しかった。
Javaでリフレクションはこういうふうに使うのか、モックはこういうものなのか、という気付きが楽しかった。

でも、あの山根さんも最近の技術のトレンドに少しずつ遅れてきていると感じている。
だから、コミュニティに顔を出して、新しいトレンドを取り入れようとしている、と。

【3】田口さんのKPTのプラクティスの事例も興味深かった。
普段はプラクティスの話はしないんだけど、と話しながら。

KPTは良くできたフレームワーク。
長所だけでなく、問題も洗い出して、対策まで考えさせる。

でもKPTを毎回やると飽きる時がある。
だから、他の色々なファシリテーションのツールを使う。
良かったこと・悪かったことをアイコンの周囲に付箋で書き出す。
モスバーガーの店前の掲示板を真似て、朝会の前に、いじりキャラの若手に小さなホワイトボードにその日の気分を書かせて、朝会の雰囲気をほぐしたり。

【4】パネルディスカッションのテーマは「アジャイルの達人に聞く~ソフトウェア開発の質問コーナー」。
僕がモデレータと言いながら、自分が一番聞きたい内容を質問形式にして、パネラーと議論できればと思っていた。
質問は、典型的なWF型開発しか知らない、というSIの立場であえて書いてみた。
5つの質問を用意していたが、最初の質問1個だけで1時間以上も費やしてしまった笑。

【5-1】「要件定義で注意しているポイント」を質問として投げかけた所、藤井さんから、その問題はアジャイルでは既に解決している。
アジャイルでは要件のように機能詳細は定義せずに、ユーザストーリーでまとめる。
1~3ヶ月おきにリリースすることで、ユーザーストーリーを検証・評価して、顧客に価値あるシステムを提供していく。

でも、要件定義が必要なのは、見積りの元ネタになるから。
見積りが契約内容と見なされてしまう。

【5-2】土屋さんいわく。
見積りは2種類は出すようにしている。オプションは2種類作り、双方にメリット・デメリットがあるように説明すれば、お客さんも納得してくれる。
松竹梅、という3種類の見積りあるよね、と。

【5-3】木下さんいわく。
うちは、インセプションデッキが作れるまで開発を始めない。
ユーザとは準委任契約を結んでいるので、要件定義で固定スコープの一括委託契約はしない、と。
顧客はうちの開発力を信用しくれているし、うちも顧客の信頼を崩さないようにと思って、信頼関係を大事にしている、と。
この点は、委任契約にある善管注意義務の発想と全く同じ。

他に、価値創造契約のように、準委任契約ではなく、システムの開発と運用を一体化した契約スタイルもある。

また、ユーザ側の担当者がアジャイルを受け入れてくれる人か否か、を判断している。
ユーザ企業の担当者が上司にお伺いを立てるような人ではダメで、俺がすべての要件を決める、と言う、プロダクトオーナーの役割を自覚する担当者でないと上手くいかない。

【5-4】田口さんいわく。
うちはゲーム会社なので、受託開発案件はそうない。
ゲームでは、ユーザが楽しいと思うものを作る、というふわっとした要件が多いので、要件定義という発想がゲーム業界自体にあまりない。
やってみないと分からないから。
そういう未知のソフトウェア開発では、Scrumがすごくマッチする。
Scrumを導入して今まで失敗したことがない。

でも、たとえば、ゲームのキャラクターを作るという作業の場合、キャラクターの図面を作る、キャラクターのエフェクトを付ける、などの作業を複数人のデザイナーが担当して作業する場合がある。
その場合は、Scrumではなく、タスクかんばんでワークフローとして作業を流す。
その方が回りやすい、と。

【5-5】参加者からの質問も多くて、その内容もすごく共感できて。

準委任契約と言っても、実際は要件定義は実施済みで、どんなモノを作るのか、という仕様が決まっているから、一括請負契約と変わらない場合がある。
そんな場合でもアジャイル開発はできるのか?と。

パネラーからは、顧客と信頼関係を築いていれば、準委任契約でも、スコープを固定せずとも開発は可能。
ある一定期間で、これだけの予算の範囲で作る、という条件があるので、その範囲内でベストなソフトウェアを作る。
その条件の範囲内で、顧客の要望に基づき、フィーチャを取捨選択して、オプションのように取り扱う、と。

でも、質問者の方は何となく納得できていないような雰囲気を感じた。
そして僕自身も、質問者と同じく違和感を感じていて、質問者とパネラーの間で、準委任契約の意味やその背後にある現実にズレがあるように感じた。

僕が知っている準委任契約は、実費請求の準委任契約であり、作業報告書がなければ開発費用を請求できない。
顧客の依頼に基づいて作業した、という契約。
その契約内容は、事実上、一括請負契約とあまり変わらない。

一方、パネラーの場合、顧客との信頼関係があり、顧客はチームの開発力を信用しているし、チームも顧客の要望がスコープに入るかどうか十分に吟味して回答し、その範囲内できちんと結果を出す。
その差は、要件定義がアバウトであっても、顧客がチームを信頼していて、チームも必ずアウトプットを出す、という信頼関係があるか否か。
その差は大きい。

や16ぁさんはTwitterを使っています: "挙げている例が当てはまりすぎててそのままワイに突き刺さる #xpjugkansai"

kawanotronさんはTwitterを使っています: "でも@akipiiさんの悩みよくわかる。 #xpjugkansai"

【5-7】他に、アジャイル開発ではドキュメントを作らないのか?という参加者からの質問もあった。

木下さんいわく。
ドキュメントはうちもほとんど作っていない。
でも、ユーザ側の担当者が変わると、そんな話は俺は聞いていない、と言い出す人がいて、大変になったこともある、と。

【6】アジャイル開発が当たり前の知識になったとしても、実際の現場でアジャイル開発が使えていなかったり、契約や要件定義でアジャイル開発を生かすノウハウがなかったりする。
今日のような場で、その辺りの本音の議論が少しでもできて、参加者の心に残ってくれたらいいなと思う。

| | コメント (0)

2016/02/26

Redmineのチケット管理のアンチパターン事例

チケット管理のアンチパターン事例が公開されていたのでメモ。
二つの記事共にとても参考になる。

【参考】
redmineを使ったチケット管理の失敗のさせ方 - 文系プログラマによるTIPSブログ

チケット管理のアンチパターンとベストプラクティス - Javaプログラマーのはしくれダイアリー

二つの記事に記載されているアンチパターン、プラクティスのタイトルだけを拾ってみた。
タイトルを見るだけでも、ああそうだなあ、とうなずくものがある。

(引用開始)
【チケット管理のアンチパターン1】
・進捗率をユーザの裁量で更新させる
・対象バージョン「なるはや」
・チケットの内容が途中から変わる
・増殖するプロジェクト固有のトラッカー
・「本日は打ち合わせありがとうございました」
・対象バージョンの書式がバラバラ
・チケットに添付されまくる仕様書
・チケットの題名が「仕様調査依頼」
・社内redmineと社外redmineのテーマが同じ
・既に退場した人のユーザが沢山残っている
・ステータス「保留」
・「単体テスト」と「単体試験」
・wikiにある「チケットの更新フロー」
・何故か私はこのチケットが終了できないんですよね
・乱立するredmine
(引用終了)

(引用開始)
【チケット管理のアンチパターン2】
・運用フローが複雑
・使われていない項目がある
・テンプレートがない
・抜け穴が多い(チケットが起票されない)
・チケットのコメント数が多い
・チケットがポエムになっている
・チケットのコメントで別の問題解決が進行している
・チケットの粒度が大きい
・チケットからの外部リンクが死ぬ
・日々集計されていない
・チケット棚卸しマンがいない
・チケットに対して作業しているのにチケットが更新されない
・一見してチケットの主張がわからない、解決に必要な情報が不足している
(引用終了)

(引用開始)
【チケット管理のプラクティス】
・運用フローはシンプルにする、もしくは分担を明確にする
・使われていない項目は無くす、もしくは必須とする
・テンプレートを用意する。オリジナリティがあるチケットが生まれてきた場合は新たなテンプレートを検討する
・チケット起票を作業の開始とする、もしくはタスク一覧などと1:1の関係にしておく
・チケットのコメント数が多い場合は別チケットにするなど趣旨の整理をする
・チケットにポエムが書かれた場合はヒアリングし、wikiに書くなどする
・別の問題が進行し始めた場合、別チケットを起票しリンクする
・外部リンクはなるべく死なせないするためN年後生きているかなどを考える
・チケットの集計は日次や週次で行う
・チケット管理棚卸し会を開く、もしくは棚卸しマンを呼ぶ
・進めているチケットに対して更新をルール化する(1日1回など)
・障害チケットにexerciseとactualとexpectedを。タスクにはstoryとgoalを書く
(引用終了)


「本日は打ち合わせありがとうございました」「チケットがポエムになっている」「ステータス「保留」」「乱立するredmine」は、すぐに笑い出してしまった。
似たような例として、「チケットタイトル:お世話になっております」(@agilekawabataさん)もある。

また、チケットにメール文化を持ち込ませないようにすれば、メール本文よりもチケットの文章量は10分の一に削減できる、と@g_maedaさんが言っていたことも思い出す。

チケット管理のプラクティス、アンチパターンは、僕も過去に何度も書いてきたし、Redmine勉強会でも数多くの事例が披露されてきたが、もう一度、整理して経験知としての知識体系にできたらいいなあ、と思う。

| | コメント (0)

ガントチャートの光と影

プロジェクト管理といえば、ガントチャート。
ガントチャートの良い部分と悪い部分についてメモ。

【参考】
下記の連載記事は、初心者向けのガントチャートの記事で読みやすい。

初めてのガントチャート(1):ガントチャートって何ですか? - @IT

初めてのガントチャート(2):いまさら聞けない8つのガントチャート基礎用語&タスクを洗い出すときの注意点 (1/2) - @IT

初めてのガントチャート(2):いまさら聞けない8つのガントチャート基礎用語&タスクを洗い出すときの注意点 (2/2) - @IT

初めてのガントチャート(3):Excelガントチャート作成の基本&関数とグラフで負荷状況を「見える化」する (1/2) - @IT

初めてのガントチャート(3):Excelガントチャート作成の基本&関数とグラフで負荷状況を「見える化」する (2/2) - @IT

【1】ガントチャートは、作業が予測しやすく、工場のラインのような流れ作業では威力を発揮すると思う。
最初に、計画時点で、バシッとタスクをすべて洗い出し、タスクの先行・後続の関係、タスクの詳細化ができれば、すごく扱いやすい。

ガントチャートの利点は、予実管理が一目で分かることだ。
MSProjectのように、ガントバーが予定、実線が実績を表すから、イナズマ線を表示すれば、どのタスクが凹んで遅れているのか、がすぐに分かる。

また、ガントバー=WBSなので、担当者をアサインしておけば、プロジェクトの負荷状況も自動計算できる。
上記の連載記事では、日付別・タスク別に、担当者が作業する点をプロットしておけば、「=COUNTA(F4:F:44)」という計算式で簡単に負荷状況を計算できる。
MSProjectならもっと綺麗に表示してくれる。

作業の負荷状況は、プロジェクトリーダーにとって重要なビューの一つだ。
PJ別、週別、担当者別に作業予定表を事前に作成しておくことで、今引合中の案件に誰をアサインできるか、これから開発・テスト工程でたくさんのメンバーが必要になるプロジェクトにどれだけのリソースを確保すべきか、を予測したいからだ。

【2】しかし、ガントチャートはソフトウェア開発の作業に向いているようで向いていない部分が多いように思う。
理由はいくつかあると思う。

【2-1】一つは、見積もり時や受注直後では、プロジェクトの作業全てを洗い出せない場合、ガントチャートが作りにくくなることだ。
ソフトウェア開発では、初めて取り扱うアーキテクチャやフレームワークとか、初めての顧客の開発では、どうしても不明点が多い。
全てのリスクを洗い出せないし、リスクの広さや深さも正直分からない。
エイヤーで見積り、スケジュールを大まかに引いて、作業を始める。
そして、ズルズルと作業が延びてしまい、納期間近になって、火を噴くことがすべての関係者に知れ渡る。

本来、ガントチャートは、製品組立ラインのように、たとえば、旋盤→組み立て→梱包のように各工程がオーバーラップしない場合は扱いやすい。
特に製造業では、各工程の作業時間そのものを全て統一化することで、流れ作業をやりやすくし、作業効率を高める手法を取る。
いわゆるラインバランシングだ。

しかし、実際のソフトウェア開発はもっと汚くてドロドロしている。
顧客や上司に見せるときには有効だが、実際の開発では、タスクかんばんのように、チケット単位で作業する方が開発者は作業しやすいように思う。

【2-2】もう一つは、作業の粒度が小さくなるほど、ガントチャートが保守しづらく、ガントチャートの精度が逆に悪くなることだ。

PMBOKでは、一つのWBSの単位は約2週間位の粒度を勧めていた。
それ以上小さいと逆に細かすぎて管理しにくくなる。
また、顧客や上司の観点では、そんな詳細レベルの進捗ではなく、機能(フィーチャ)単位の進捗が知りたいのだ。

しかし、実際の開発では、週レベル、日レベルにもっと細分化しないと、開発者は作業しにくい。
すると、WBSを5階層くらい細かく階層化して詳細化していく。
そうすれば、作業しやすくなるが、WBSの変更や最新化が非常に大変になる。
WBSに先行・後続の依存関係をつけていれば、なおさら、一つの変更が他のWBSにも影響してしまい、整合性が取れなくなる。

たとえば、50人月や100人月の案件では、WBSは簡単に数千行くらいに膨れ上がってしまう。
Excelで管理しようとすると、とても把握しきれない。

だから、週末に必ず、Excelのガントチャートに予定と実績を開発者に入力させ、その後に、ガントチャートのExcelを集計する担当者がExcelマクロを使って、綺麗なガントチャートを出力したり、予定・実績工数を集計したりする運用をやっている。
今時、そんな運用をしているの?と思ってしまうが、大規模案件では、進捗管理のためだけの要員を確保するコストも確保できるから、実際にやっている場合が多い。
毎週または毎月、バーンダウンチャートを綺麗に作るために、PMOが頑張っている案件を見たこともある。
そんな作業は正直、コストの無駄遣いだろうと思う。

個人的には、綺麗なWBSを作って管理するよりも、2週間~1ヶ月くらいのマイルストーン単位で区切って作業する方が、進捗管理も楽だし、開発者もゴールが見えやすいと思う。

【2-3】さらに、ガントチャートでは、QAや障害などの管理が漏れやすいことだろう。

仕様書の文言の不備、あいまいな要件、テストで突然発覚したバグなどは、当初の計画からは予測できない。
WBSで1つずつ行を追加していくと、管理できそうな気がするが、どれが完了していて、どれが優先すべきなのか、が分かりにくい。
さらに、QAは何度もやり取りしてFixされるものだから、進捗率もコロコロ変わる。
QAや障害は、進捗率よりもステータスで管理すべきものだ。

すると、ガントチャート以外のExcel管理表に記載して、まとめて管理するようになってくる。
Excelのガントチャート、QAのExcel管理表、Excelの障害管理表と、どんどんExcelの管理書類が増殖していく。
しかも、Excelの管理表を開かないと、実際の進捗状況も分からない。

@sakaba37さんが提唱されている「アダプタブルWF」では、WF型開発から漏れているこれらの課題管理・障害管理こそ、チケット管理すべきだ、という発想になる。
チケット管理は、作業よりも、QAや障害の管理の方が相性はいい。

【3】個人的には、ガントチャートが悪いのではなく、ガントチャートはプロジェクト管理で必要なビューの一つに過ぎない、という点を見落としているだけだと思う。
ガントチャートだけで、プロジェクト管理が全て可能である、と思い込むこと自体が間違っているのだ。

ガントチャート、リソースヒストグラム、EVM、信頼度成長曲線、かんばん、バーンダウンチャート、累積フロー図(CFD)など、色んなビューがあるが、それらはチケット集計という機能にすべて置き換えて、必要なタイミングでビューをそれぞれ切り替えれば、もっと管理作業は楽になるだろうと思う。
作業はチケットに置き換えれば、チケット集計で多様なビューを表現できればいい。
ガントチャートは、所詮、チケット集計における1個のビューにすぎないのだ。

Redmineでは、ガントチャートがデフォルト機能だが、それ以外のビューももっとあったらいい、と思う。
そして、どのビューがどんな時に有用であるか、をもっと整理してみたい。
その考えは、チケット駆動において有用なメトリクスとは何か、という問題につながると思っている。

【追記】
参考になるつぶやきを見つけたのでメモ。

三浦 元さんはTwitterを使っています: "@akipii ガントチャートは現場での管理に向いているが、立案や変更検討には向いていない。そちらはPERTがはるかに使いやすい。僕はPERTで立案してガントで現場展開することをやっていたが、問題はまともなPERTツールが三菱ソフト製を除いて市場から消えてしまったこと。"

三浦 元さんはTwitterを使っています: "@akipii ガントでもPERTでも、ステータス管理となるタスクを表現・管理しづらいのは同意。最遅終了日を設定して完了かどうかで管理することになるだろうな。"

| | コメント (0)

2016/02/10

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

Redmineの運用フローが上手く回らないという声を聞く時がある。
その理由を探ってみると、結局は、組織構造に原因がある時が多い。
以下、メモ書き。

組織は戦略に従う。そして、戦略は組織に従う。

戦略が先か、組織が先か | 組織用語 | 山内翼のサイト | yamauchi283.com

【1】経営学の有名な言葉に、「組織は戦略に従う。そして、戦略は組織に従う」がある。

「組織は戦略に従う」という命題はチャンドラーが言い出した。
本来の意味は、大企業が多角化戦略で数多くの事業に展開する時、それぞれの事業ごとに事業部制組織を作る傾向があることから、経営戦略に従って事業を作り出すタイミングで組織が生まれる、ということらしい。

僕が「組織は戦略に従う」という言葉を強く意識する場面は、社長が期首に組織変更の発表をしたがる時だ。
社長は常に経営戦略を考えており、管理職だけでなく、社員全員にもその意図を伝えたい。
しかし、実際は多数の社員に逐一説明するわけにもいかないし、社員も社長の意図をすぐに理解できるわけではない。
だから、組織変更を通じて、社長の意図である戦略を社員に伝えているわけだ。
組織変更があれば、社員も自分の職務に直接的に影響するし、組織のミッションを通じて経営戦略の意図を感じ取ることができるからだ。

一方「戦略は組織に従う」という命題はアンゾフが言い出した。
本来の意味は、大企業が多角化経営を実施したとしても、新規の戦略は既存の組織から反発を食らい、組織の抵抗によってほとんど結果が出ない、という傾向があることらしい。
なぜなら、大企業ほど官僚制組織に近くなるために、組織慣性が強くなりがちで、自己変革の行動を起こすよりも安定性を求めてしまうからだ。
サイロ型組織、地理的に離れたチームが多い組織では、どうしても組織構造の制約が経営戦略の幅を狭めてしまう。

【2】そんな言葉をRedmineに当てはめてみると、どうなのか?

僕個人の思いとしては、Redmineが本来持っているチケット駆動開発をそのまま運用すればいいはずだと思っている。
しかし、実際は、その開発現場の制約条件がRedmineの運用をかなり歪めてしまう場合が多いと感じる。

過去の経験では、組織構造の複雑さがRedmineのプロジェクト構造やワークフロー設計にそのまま反映される。

【2-1】僕が過去に経験した事例では、プロジェクトの階層が5個、ワークフローは20個が最大だった。
そのような事例では、ITILのようなフレームワークをそのまま当てはめようとして、ステータス遷移がすごく複雑になってしまった時もあった。
ITILという戦略にRedmineが従属させられていた。

【2-2】既存の組織構造や案件をRedmineのプロジェクト構造に対応づける時に、組織の問題がのぞく。

たとえば、普通のSIでは事業部制組織なので、Redmineプロジェクトは案件単位またはシステム単位に作る。
つまり、契約で定められたプロジェクト、売上対象のシステムがRedmineプロジェクトになるから、開発者にとって作業しやすい。
受託開発案件、保守しているシステムの中で、作業や障害対応は普通は閉じているからだ。

しかし、製造業のように機能別組織の場合、縦割り組織になっているために、Redmineプロジェクトが組織単位になる場合が多い。
すると、組織をまたがった作業がすごくやりにくい。
たとえば、開発部署が隣の営業部署や品質保証部と一緒に作業する時、別組織の上長の承認を得る必要があるから、稟議がやたらと多くなる。

また、営業・設計・開発・品質保証のように部署ごとにサイロ型組織に分かれていると、ワークフローが複雑になりやすい。
なぜなら、ステータス遷移のタイミングが組織をまたぐ場合に発生するからだ。
たとえば、一つの作業をやる時に、複数の人達の承認を得る必要が出てくる。

この状況は、製造業でなくても、SIで、開発チームとインフラチーム、オフショア開発チームのように数多くの部署が分かれている時にも同様に発生する。
組織構造が、Redmineが本来持つ、柔軟な運用フローであるチケット駆動開発を分断してしまうのだ。

【2-3】あるいは、社内にISO9001や内部統制(JSOX)の法的ルールが存在しているために、その法的ルールの範囲を越えてRedmineを運用できなくなることだ。

特に、品質保証部が率先してRedmineを導入・運用し始めると、ワークフローが複雑になり、ステータス遷移が多くなりがち。
また、「~してはいけない」というルールばかり、はびこってしまい、多種多様な開発・保守案件の作業管理にRedmineが逆に対応できなくなってしまう。
そして、Redmineのチケット登録そのものが億劫になって、障害管理表やQA表というExcel管理表が共有フォルダに復活してしまうのだ。

ガチガチの社内ルールは、闇Excelを蔓延させる。
ISO9001やJSOXが、Redmineが本来持つ、柔軟な運用フローであるチケット駆動開発の良さを消してしまうのだ。

【3】そんな事例を見ると、「Redmineは戦略に従う」「Redmineは組織に従う」という思いが強くなる。

Redmine導入時に、社内の標準プロセスとのフィットギャップ分析するのはいい。
でも、やり過ぎると、現状(AsIs)の組織構造や社内ルール、運用フローに引きずられて、あるべきRedmine(ToBe)の運用フローは成立せず、現状の闇Excelの作業データを流しこむだけのRedmineになってしまう場合がある。

あるいは、現状の組織構造が複雑なために、プロジェクト構造が複雑化したり、ワークフローの設計が複雑になったりする場合がある。

こうなっては、本末転倒だ。

業務システムの要件定義では、AsIsの運用フローに引きずられすぎず、ToBeの運用フローの作成に時間を書けるべき、というアドバイスをよく聞く。
Redmineのシステム運用フローの背後に組織構造を感じるとき、このアドバイスをいつも連想する。

| | コメント (0)

2016/02/07

【告知】3/5土にRxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」を開催します

3/5土にRxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」を開催します。

【元ネタ】
RxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

Redmine 3.2.0 released!: プログラマの思索

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

(引用開始)
2015/12にRedmineのVer3.2がリリースされました。
最新バージョンでは、CSVインポート、レスポンシブ対応によるスマートフォン・タブレット対応、ガントチャートの日付表示など、エンタープライズ向け機能が強化されており、日本のSIの開発現場でも、より使いやすくなっています。
今回の勉強会では、Redmineエバンジェリストの前田剛さんをお呼びして、Redmineの最新バージョンの機能を紹介して頂きます。
また、赤羽根さんからRedmineのチューニング事例、あきぴーさんから工数管理システムの事例を紹介した後、Redmineの現在の機能や運用、そして今後の動向について、パネルディスカッションで議論します。
ふるってご参加下さい。
(引用終了)

半年ぶりに大阪でRedmine勉強会を開催します。
上記のテーマと概要の通り、Redmineの最新バージョンの機能紹介やチューニング事例をメインでやります。

大阪と東京のRedmine勉強会も既に5年以上開催が続けられていますが、Redmine本体もその間、活発にバージョンアップされています。
特に、2015/12にリリースされたVer3.2では、エンタープライズ向け機能が大きく強化されています。

Redmine 3.2.0 released!: プログラマの思索

CSVインポート、ガントチャートの日付表示、チケット一覧画面の予定工数/実績工数の合計時間表示など、マネージャ向けの機能が大きく強化されている点が注目されるべき内容でしょう。
それらの機能を使いこなせるようになれば、ソフトウェア開発の現場、あるいは、ホワイトカラーの事務作業でも、より効果的にタスク管理できるようになるでしょう。

オープンソースのプロジェクト管理ツールで、Redmineほど機能が豊富で、品質も安定しているアプリはそう多くはないと思います。
また、たとえば、JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索のように、いろんな現場で、Redmineが使われて、その事例のノウハウも公開されています。
そのおかげで、Redmineの機能を現場の特徴に合わせて上手く使えば、より効果的に使いこなすこともできるでしょう。

私は、今回はRedmineによる工数管理システムの事例を講演します。
既に、Redmineの運用パターンについては、過去に2回ほど講演してきましたが、工数管理システムとして使いこなす内容はまだ発表していませんでした。

【公開】講演資料「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集~問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

というのも、工数管理のUIがRedmineに既に存在するのですが、まだ運用するには難しい点があると思っていたからです。
ですが、Redmineの最新の機能を使えば、運用ルールさえ徹底できれば、上手く使えるのではないか、という印象も持っています。
その辺りも話してみたいと思います。

| | コメント (0)

2016/02/03

Redmineの全文検索にPostgresSQLを使ってLike検索を高速化するRedmine PostgreSQL Search plugin

Redmineの全文検索にPostgresSQLを使ってLike検索を高速化するRedmine PostgreSQL Search pluginを見つけたのでメモ。

【参考】
Postgresql Full Text Search - Plugins - Redmine

jkraemer/redmine_postgresql_search: PostgreSQL full text search plugin for Redmine

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

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

Redmineチューニングの実際と限界(@akahane92)

PostgreSQLの日本語対応全文検索モジュールpg_bigmとPGroongaを検証してみた - CreateField Blog

【1】Redmine PostgreSQL Search pluginは下記の機能を持つらしい。

(引用開始)
Redmine PostgreSQL Search Makes Redmine search use PostgreSQL full text search instead of LIKE queries.
(引用終了)

(引用開始)
This plugin changes the default Redmine search to use PostgreSQL full text indices.

Search results will be sorted by relevance instead of modification date, hits in titles / names will generally score higher than hits in desciption / body text. Term (foobar) and Prefix Queries (foob*) are supported, the usual Redmine options (titles only and all words) work as expected.
(引用終了)

【2】Redmine PostgreSQL Search pluginが興味を引く理由は、Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索に書いたように、チケットが数十万件を超えると、Redmineの全文検索機能の応答時間が大きくかかるようになり、業務に支障が出る状況になるからだ。

当初は、一つのチームでこっそり始めたRedmineも、たくさんのチーム、たくさんの部署に使われて、運用が広がると、チケット数はどんどん増えていく。
増大するチケットの検索の性能要件が悪くなると、いつでもすぐに情報を取り出せなくなるから、チケットやWikiに情報を蓄積できるというチケット管理システムの意味がなくなる。

【3】Redmine PostgreSQL Search pluginは、PostgresSQLのフルテキストエンジンを使って、RedmineのLike検索を高速化できるようだ。
興味深いのは、日本語、ドイツ語などのように、各言語でpg_catalogを作れる点だろう。
つまり、非英語の言語であっても、全文検索できるような仕組みがあるらしい。

実際、下記のrakeコマンドでPostgresSQLにインデックスを作成するらしい。

bundle exec rake redmine_postgresql_search:rebuild_index

運用方法としては、毎日夜間または、Cronで定期的ににインデックスを作り直すといいかもしれない。
そうすれば、最新のインデックスを元に高速検索できるだろう。

検証できていないので、情報を集めてみたい。

| | コメント (0)

« 2016年1月 | トップページ | 2016年3月 »