プロジェクトマネジメント

2017/02/27

Redmineの親子チケットの功罪

RedmineのFAQとアンチパターンを整理していると、最近は、親子チケットに絡む内容が多いような気がした。
Redmineは先進的なプロジェクト管理を行う実験場であり、まだまだ改善の余地はたくさんあると思う。
考えたことをラフなメモ書き。

【1】最近、ソフトウェア開発者以外の人達から、Redmineを業務に使えないか、質問を受ける場合が多い。
彼らの目的は、タスク管理や、昔のNotesの代わりの事務処理ワークフローに使いたいみたいだ。
Excel帳票やExcel管理台帳が溢れていて、それを何とかしたい、という動機みたい。

そういう場面に、Redmineは導入しやすいし、運用して効果も期待できる。
OSSで無料だし、小さく運用を始めて様子見した後、大人数へ横展開することもできる。

特に、大規模に使っていく場合、Redmineのメリットがとても良く出てくる。
つまり、Redmineのメリットである「親子プロジェクトの階層は無限」「親子チケットの階層は無限」を上手く適用できれば、多数の組織も管理できるし、多数の作業もまとめて管理できる。

換言すれば、Redmineの「プロジェクトやチケットの階層が無限に作れる」特徴は、とても柔軟な機能なので、いろんな業務に適用しやすい。
だから、色んな人達が色んな業務にRedmineを適用しようと試している。

しかし、話を聞くと、業務がRedmineに完全にフィットしない場面もあるらしい。
どうやら、特に親子チケットの作り方に問題があるような気がしている。

【2】では、Redmineを実際に運用した場面で、親子チケットを使った時にどんな問題が噴出しているのか?
色々集めてみた。

【2-1】親子チケットにし過ぎる

個人のToDoを子チケットで登録して、親チケットにぶら下げる人がいる。
他の人には不要なチケットだ。
チケットが乱発されて、登録した本人ですら、チケットの棚卸しができなくなる。

根本問題は、チケットの粒度があまりにも細かすぎる点だと思う。
解決策としては、他人と共有すべき作業内容に限定する運用ルールを作る。

僕が最も推奨するのは、TODOレベルは、チケットにチェックリストを追記する運用に変更することだ。
なぜなら、個人のToDOレベルのタスクが全て終わったことが、その人のチケットの完了条件とみなせば、他人と進捗状況を共有しやすくなるからだ。
つまり、個人のToDOはチェックリストにすべきだ。

たとえば、Checklistsプラグインを入れてもいいかもしれない。

Checklists - Plugins - Redmine

但し、チェックリストを作ったとしても、チケットに未チェックが残っても、チケットが完了できてしまうリスクもある。
その場合は、下記のように、完了できなくなるパッチを当てればいい。

Redmine Checklists pluginで未チェックの検証を雑に行う - Qiita

あるいは、プライベートチケットを使う方法もあるだろう。
プライベート機能を使えば、他人には見えないから、ToDOチケットは邪魔にならない。
しかし、共有すべきチケットが存在すれば、埋もれてしまうリスクもある。

【2-2】親子チケットで、開始日・期日・予定工数のロールアップを止めたい

よくある例は、WF型開発の案件で、親チケットにSEが開始予定日・終了予定日・予定工数を入力した後、子チケットにPGが実績の開始日・終了日・自分で見積もった予定工数を入力すると、親チケットの開始日・期日・予定工数が消えてしまう問題だ。

Redmineの本来の仕様は、「WBS 100%ルール」であり、WBSに漏れがあってはいけないから、親チケットは子チケットの情報をロールアップする。
しかし、WBS 100%ルールは、実運用に合わないケースが多い。
結局、WF型開発も綺麗に運用できるわけではない。

SQIP2015の講演後の質問でも、この質問が最も多かった。

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

実は、対処としては、RedmineのVer3から、Redmineの設定画面で「子チケットから独立」を選択することで解決できる。
また、親チケットの予定工数と、子チケットの予定工数の合計は別カラムとして表示されるので、問題なくなった。

しかし、この運用が本当に良いかどうかは分からない。
WBS 100%ルールを止めるということは、WBS作成の基本ルールを破棄していることだから。

【2-3】未完了のチケットが残っているのに、親チケットが完了できてしまう

これは、WBS 100%ルールではありえない問題だが、Redmineの機能には実装されていない。
実は、RedmineのVer3.4で対応済みだ。

2016年11月のRedmine開発状況 | Redmine.JP Blog(Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止)

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

Feature #10989: Prevent parent issue from being closed if a child issue is open - Redmine

「Feature #10989: 未完了の子チケットを持つ親チケットのクローズを禁止」のパッチによって、WBS 100%ルールが実現できるおかげで、親チケットのステータスを明確に判別できる。

【2-4】親子チケットでどこまで深く階層化するか?

Redmineの実運用では、ExcelのWBSのように5~10階層までブレイクダウンしたい目的が多い。
つまり、ExcelやMSProjectみたいに、WBSの深い階層をRedmineチケットで表現したい。

しかし、WBS 100%ルールを厳格に運用するとデメリットが大きくなると感じている。

普通、タスクは階層化しやすい。
しかし、障害やQAは階層化に合わない。

そして、深い階層のチケットは、チケット一覧画面では見通しが悪い。
むしろ、ガントチャートが向く。
ガントチャートならば、階層構造が綺麗に表現されるからだ。
だが、Redmineのガントチャートで編集できない弱点がある。

また、深い階層のチケットのデメリットはいくつかある。
一つは、 性能が悪くなること。
浅い階層では問題ないが、かなり深い階層とか、数千件の子チケットを持つチケットの操作のパフォーマンスが悪くなるらしい。
そのパフォーマンス改善のパッチがRedmine本家に提供されたが、Ver3.4ではリジェクトされている。

2016年12月のRedmine開発状況 | Redmine.JP Blog (Defect #23318: 大量の子チケットを持つチケットで #lock_nested_set メソッドが遅い問題の改善)

実際、Redmineの実ソースでは、子チケットを表示する時に、select ~ for updateを使っているみたいだ。
つまり、ロックを故意にかけているので、性能が悪くなる可能性はある。

もう一つは、親子チケットを一括登録しようとすると一手間かかることだ。
実際、親チケットを採番しないと子チケットを一括インポートできない。
なぜなら、親チケットNoを採番しなければ、子チケットの親チケットNoを指定できないからだ。
すると、階層の数だけ、一括登録のインポート処理を繰り返し、その都度、親チケットNoを取得してはセットする手間が必要。
手作業で親子チケットは簡単に作れるが、MSProjectで作った5階層のWBSを一括インポートしたい需要はあるだろう。
どこかのツールで手軽に実行できないかな?

さらに、深い階層の親子チケットは、チケット保守が大変になる。
親子構造を変えにくかったりする。

また、バージョンが古いRedmineでは、WBS 100%ルールが実運用に合わないことは前に触れた。

そして、深い階層の親子チケットでは、WBS漏れを検知できるか?
要件チケットから成果物までのトレーサビリティをRedmineは実現できるのが、もう一つのRedmineのメリットだが、階層の深いチケットを作ると、WBSがどこかで漏れていたとしても、Redmine上ではすぐには分からない。
結局、CSV出力して、Excel上でWBS漏れを探した方が早いだろう。

あるいは、Lychee LACという有償プラグインを使って、Redmineの階層構造とトレーサビリティをツリー構造で図で表示する方法があるかもしれない。

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part3~Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

【2-5】チケットの棚卸しがやりにくい

親子チケットにすると、チケットの棚卸しがやりにくそうに感じる。
最下層の子チケットを棚卸ししなければ意味がないが、どうしてもチケットが多すぎるからだ。
駄目なプロマネはRedmineのチケット一覧で頑張ろうとして、溢れたチケットに溺れてしまう。

チケット一覧で棚卸ししようとして詰まるみたい。
すると「放置されたチケット」「停滞したチケット」「乱発されたチケット」のようなアンチパターンが生まれてしまう。

個人的には、親子チケットを使わすぎず、ロードマップを使う方が良いと思う。
つまり、バージョン=納品日、締切日として運用して、ロードマップ画面でチケットを取捨選択する運用に切り替えるわけだ。
僕がRedmineを運用して、これがアジャイル開発の本来のマネジメントなのだ、と気づいた機能の一つ。

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

Redmineのロードマップ画面では、右クリックでチケット編集コンテキストメニューを出せるので、ロードマップ画面上で優先度を考えながら、チケットの属性を編集できる。

しかし、Redmineのロードマップ画面も機能不足と感じる。
ロードマップ画面で、チケットの優先順位を付ける機能がないからだ。

現状では、下記の3つしかやり方がない。
しかし、チケット枚数が増えるとロードマップ画面でも厳しくなる。

1・チケットの優先度を設定する
→なる早が増える

2・先行・後続の関連を付ける
→チケット操作が複雑。ガントチャート画面で編集できない。

3・バージョンを設定する
→チケット枚数が増えるとチケットが溢れる。本来は、チケットの並び順で優先度を付けたい。

本来は、ロードマップ画面で、チケットをD&Dして並び替えて、チケットの並び順で優先度を付けたいのだ。
このパッチは、実はRedmine本家で既に提供されている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

2016年9月のRedmine開発状況 | Redmine.JP Blog(Feature #22802: バージョン内のチケットをドラッグ&ドロップで並べ替え)

ここで、Scrumのプロダクトバックログでは、タスクカードの並び順が作業順序である。
つまり、開発者は、バックログの一番上からタスクカードを取り出して、作業をこなしていけばいい。
開発者は優先順位について考える必要はない。

一方、プロジェクトオーナーやプロダクトオーナーは、プロダクトバックログを常に精査して、どのフィーチャの実現を優先すべきか、取捨選択して、並び順を優先順位として考えればいい。

つまり、Redmineのロードマップ画面はもっと改良できる余地がある。
Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineでは、ロードマップ画面の並び順だけでなく、チケット一覧画面の並び順も考慮すべきでは?という議論があるが、それはナンセンスだ。

チケット一覧画面は、クエリによってある特定の検索条件でチケットのリストを抽出だけの機能だ。
しかも、ソート順も検索条件の一つになっている。
そもそも、D&Dでチケットの並び順を変更する必要もない。

一方、ロードマップ画面はリリース計画で使うべき機能だ。
この画面こそが、チケットの取捨選択を行うべきRedmineの中核機能だ。
だからこそ、Redmineにもっとアジャイル開発の特徴を取り込みたいのだ。

個人的には、Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmineに数多くの人が「+1」のコメントを付けて、Redmineの機能の一つとして実現して欲しいと思う。

【3】こう考えてみると、Redmineは先進的なプロジェクト管理を行う実験場であり、機能面でも運用面でもまだまだ改善の余地はたくさんあると思う。
チケット管理には、プロジェクト管理を効率化させる可能性がまだまだ秘められていると思う。

【追記】
皆さんのツイートがとても興味深いので、メモしておく。
もっと、皆さんの経験に基づいた奥深い議論がしたい。

門屋 浩文さんのツイート: "@akipii WBS関連で親子関係についてはいつも議論になりますがプロジェクトのベースを合わせることを意識した説明、意識づけをしてます ロードマップは合わないかなと思い説明はしてません"

akipiiさんのツイート: "@MadoWindahead 個人的には、ロードマップ画面こそがRedmineの中核機能と思います。でも機能が足りない。チケット一覧画面で皆頑張ろうとしすぎ。親子チケット、親子PJの運用方法はまだまだ改善の余地がある。"

ニートン 岩崎さんのツイート: "親子チケットは罪しかないので、親子チケット作らないようにして、それに該当するのはカテゴリやマイルストーンで代用してる https://t.co/vx7eXRiBPZ"

akipiiさんのツイート: "@neeton_iwasaki Redmineの親子チケットや親子PJは、メーカーのような機能別組織にとてもマッチしてます。親チケットは設計部門が作り、製造部門が子チケットにタスクをぶら下げて、進捗管理するとか。多分、日本のSIやメーカーは親子チケットが好きなのでしょう笑"

| | コメント (0)

2016/09/23

ソフトウェア開発でバグ管理はなぜ必要なのか

「品質・バグ管理はなぜ必要なのか」という質問があって、回答が面白かったのでメモ。
以下は、深く考えずにラフなメモ書き。

【参考】
Redmine - 品質・バグ管理の必要性についてご意見をお聞かせください。(10612)|teratail

BTSを制する者がソフトウェア開発を制する: プログラマの思索

akipiiさんのツイート: "数人の回答が面白い。僕なら「BTSを制する者がソフトウェア開発を制する」という言葉で回答するかな。「品質・バグ管理の必要性についてご意見をお聞かせください。故障票などに記載(Redmine的なものです)」 https://t.co/L5LKK7hDEd #teratail"

【1】(引用開始)
タイトル通りですが、品質管理・バグ管理の必要性について質問させてください。
個人的には、「100%必要ない!」とは思っていませんが、厳重に管理したバグ票やらを必死に分析して最終的に何に使うのでしょうか?
(中略)

例えば、「あるexceptionによるシステムエラー」が起きたとしたら
1.なぜバグが起きたのか?
→exceptionをキャッチしていない
2.なぜcatch文をいれていないのか?
→設計書から見落とした
3.なぜ見落としたのか?
→凡ミス
4.なぜ凡ミスが起きたか?
→疲れていた、作業効率の低下、特に理由なし

ここで最後の回答をしたところで、管理者は「なるほど、気をつけて」としか言いようが無いし、作業者としても「疲れていた」とは言いにくいものもあります。
バグの内容にもよりますが、明らかに大したバグではない、凡ミスのようなものに追及していく必要はあるのでしょうか?
それより、さっさと改修しても良い気もします。
一つの現場だけでなく、だいたいどの現場も同じ漢字なので不思議です。
(引用終了)

ソフトウェア開発でバグ管理が重要な理由は、障害管理のプロセスがソフトウェア開発の全てのプロセスの根幹をなすからだ。
つまり、BTSを使いこなす者はソフトウェア開発を制する。
以前、Blogにその考えは書いた。

BTSを制する者がソフトウェア開発を制する: プログラマの思索

Bugzilla、MantisからTrac、Redmine、Jiraに至るまでのBTSには、世界中のソフトウェア開発者のベストプラクティスが埋め込まれている。
だから、できるだけ最新のBTSに慣れた方がソフトウェア開発のスキルも向上できるはず。

【2】なお、製造業の品質管理とソフトウェアの品質管理は別物とみなした方がいいと最近は思っている。
製造業の立場から見れば、ソフトウェアの品質管理は、正直笑ってしまうぐらいの低レベルと思えてしまうだろう。

製造業の品質管理が知りたいなら、たぶん、QC検定2級レベルの知識を一度見てみればいいと思う。
彼らは、大量生産される工業製品の品質管理を統計学的手法で、細かな部分までコントロールしようとしている。
統計学における仮説検定、相関・回帰分析などが必要とされるので、相当にレベルは高い。

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

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

製造業の品質管理は、管理図を使って、製品の規格のばらつきを抑えるように、工程や作業を改善するのが王道だと思う。
たとえば、ネジを作っていて、そのネジの大きさや長さにバラつきがあれば、どの作業工程でそのバラつきが発生したのか、どの人が担当するとばらつきが大きいのか、などを細かく突き止め、原因を把握して、作業方法を改善していく。

一方、ソフトウェアの品質管理は、製造業の品質管理を真似ようとして色々試されているが、そのレベルまで到達しているようには思えない。

とは言え、ソフトウェア工学では経験則としていくつか知られている知見はある。
たとえば、人月の法則とかコンウェイの法則、リーマンの法則とか。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

【3】製造業とソフトウェアの品質管理が全く違うように思える理由は、生産プロセスが全く違う観点で存在するからではないかと思う。
製造業は徹頭徹尾、WF型開発のように、生産計画重視で大量生産が王道。

大量に仕入れして原材料費を安く交渉し、大量に販売して売上を大きく稼ぐ。
大量生産するには、見込生産が必要で、そのためには、どの程度の需要があるか、計画段階で決めなければならない。
さらに、大量生産するための土地や工場、機械が必要なので、膨大な額の設備投資という資金も必要。
半導体産業が典型例だろう。

akipiiさんのツイート: "アジャイル開発はソフトウェア開発特有の考え方。製造業とは全く違う。 @koshian: アジャイルもスクラムも日本の製造業から来たものなのになぜ日本始めアジアで普及しないと言われてしまうのか。アジャイルはなぜアジアで普及しないか” https://t.co/2UtpidH2zo"

akipiiさんのツイート: "アジャイル開発が日本で普及しない原因の一つは、予算取りや設備投資の発想にあると思う。製造業は、工場への設備投資で、規模の生産性を生かして、大量に安く作り、市場を独占して先行者利益を得たい。政府も、設備投資は不景気のカンフル剤として有効だから、金利を下げて煽る。"

一方、ソフトウェア開発は、大量生産と言うよりも、個別受注生産して、その製品を長く保守することで売上を確保する。
つまり、ソフトウェア開発プロセスは、ビジネス上も保守プロセスの方が重要なのだ。

そのためには、BTSのように、ソフトウェア保守のために特化したツールが必要で、そんなツールがなければ効率化できない。
ソフトウェアの品質管理が低レベルと言っても、BTSチケットに本番障害を記録していけば、何らかのルールは見出だせる。
また、障害修正のワークフローは、仕様変更や派生開発、新規開発にも拡張できるので、BTSをしっかり運用できる開発チームは、他のプロセスにもすぐに馴染むと思う。
その考えの中に「チケット駆動開発」というアイデアも含まれる。

【4】個人的には、製造業で言われる5S活動(整理・整頓・清掃・清潔・躾)とか、3S(単純化、標準化、 専門化)という概念や活動は、ソフトウェア開発には適さないと思う。

たとえば、製造業の人は「標準化」という言葉が大好きで、確かに、生産プロセスでは標準化活動がすごく効果を持つ。
しかし、ソフトウェア開発に「標準化」という概念を適用しようとすると、すぐに標準化されたプロセスや技術は陳腐化してしまう。
プログラマの創造性を逆に阻害する遠因になりやすい。

製造業の生産管理による標準化手法はソフトウェア開発に適用できない: プログラマの思索

そもそも、メーカーと無関係のソフトウェア企業で、5S活動を社内で推進している所はあるのだろうか?
5Sの順番にも意味がある、とか、3Sの順番にも意味がある、とか、そういうことまで理解して活動しているのだろうか?
少なくとも、日本の製造業の人たちは理解しており、そこまで細かく管理しているが、ソフトウェア企業はそこまでやっているのか?
たぶんやっていないし、創造性が重視される場のソフトウェア開発ではたぶん必要ではないかもしれない。

| | コメント (0)

2016/09/15

OSSのMSProjectクローンProjectLibreの使い方

OSSのMSProjectクローンProjectLibreの使い方に関するWebページを見つけたのでメモ。

【参考1】
ProjectLibreのインストールと使い方、基礎、入門 - SEO対策 大阪

OSSのMSProjectクローンProjectLibre: プログラマの思索

づめメモ Projectlibreで日付の書式を変える方法

MS Projectの基準計画の使い道: プログラマの思索

ProjectLibreを使ってみたら、MSProjectとほぼおなじアプリと考えていい感じだ。
実際、ProjectLibreでガントチャートをXML出力すれば、MSProjectで読み込んで開ける。
つまり、プロジェクトリーダーはMSProject、MSProjectのライセンスを持たないユーザはProjectLibreで使い分ける、という運用は可能だ。

僕が使う操作はこんな感じ。

ExcelでWBS、予定工数、担当者を作る

ProjectLibreにプロジェクトを新規作成

ProjectLibreのガントチャート画面でWBS、予定工数、担当者をコピペする

ProjectLibreのリソース画面で担当者全員もコピペする

ProjectLibre上で、WBSを階層化する。

ProjectLibre上で、WBSの先行後続関係をマウス操作で付けて、綺麗にして入力完了

MSProjectの最大の利点は、WBSの先行後続関係がマウス操作だけで簡単にできることだろう。
ProjectLibreも同様に、WBSで先行後続関係を結ぶには、先行タスクをドラッグして、矢印線を後続タスクへロドップすればいい。
そうすると、鎖アイコンが表示されて、先行後続関係のリンクが貼られる。

ProjectLibreのガントチャート画面で作業負荷の山崩しをやりたいならば、ビュー>ヒストグラムを画面下部に表示させて、100%以上の負荷のタスクをずらすか、担当を変更すればいい。
この辺りもMSProjectと似たような操作感で簡単にできる。

他に、タスク>更新で実績入力できるし、タスク>ベースライン保存で、基準計画を保存できる。
基準計画の個数も11個あり、MSProjectと全く同じなのが何となく笑える。

MSProjectに慣れたマネージャなら、ProjectLibreは全く問題ないと思う。
但し、無料版ではイナズマ線やクリティカルパスは表示されないので注意。

個人的には、MSProjectにある機能は全てRedmineのガントチャート機能で実現して欲しいと思う。
そうすれば、Redmine上でプロジェクト計画も実績管理も全て一元管理できる。

最近はRedmineのガントチャートを機能拡張した有償プラグインが続々出ているので、取り入れてみたらいいと思う。
たぶんMSProjectのライセンスよりも安いだろうと推測する。

【参考2】
MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

Redmine Lychee Enterpriseシリーズの解剖part1~Redmineの本来あるべきガントチャート機能 Lychee Gantt Chart: プログラマの思索

Redmineのもう一つのガントチャートプラグインEasyGanttのリンク: プログラマの思索

もう一つのRedmine製パッケージ製品ANKO REDMINE: プログラマの思索

| | コメント (0)

2016/08/17

MS Projectの基準計画の使い道

MS Projectの基準計画の機能についてメモ。

【参考】
MS Project を使おう!さんのツイート: "MS Projectを使うに当たって、「基準計画」を使いこなすことは非常に重要です。これがあって初めてアーンドバリューなどの進捗管理方法で予定と実績の比較が可能になります。 #MSProject"

STEP 5-1: プロジェクト計画の確定-基準計画の保存 | Quantum Harmony Corp.

プロジェクトが計画通りに進んでいるかどうか「基準計画の保存」で比較検証を行う(Microsoft Project) | 雑記 BOOOKs

MS-Project の使い方 | ins13の日記 | スラド

プロジェクトリーダーならば、普通はMSProjectが必需品だろう。
MSProjectは、計画を立てるのがやりやすい。
WBSをExcelでざっくり作り、MSProjectに貼り付けて、先行後続関係をつければ、とりあえずラフなスケジュールを立てることができる。
その後、担当者にタスクを割り振り、実績管理していく。

その時、基準計画時という機能で、プロジェクト計画時点やリスケ前に、計画情報一式を保存すると良い。
基準計画はベースラインと同義。

その時点の計画をベースラインとして保存し、予実管理だけでなく、当初の計画と現在の計画がどれくらい変化したか、比較評価する時に使う。

プロジェクト立上げ時では、開発者を確保できず、担当者未定だったりするが、テスト工程の1ヶ月以上前になれば、担当者を誰にするか決まってくる。
あるいは、顧客の仕様変更でリスケが発生し、予定工数も増えた場合も考えられる。

もちろん、当初の進捗よりも遅れてしまい、リカバリーせざるを得なくなる場合もある。

そんな時に、基準計画というベースラインを定期的に保存して、計画情報を比較評価できるようにしておけば、現実的なスケジュールを作りやすくなるだろう。

但し、MSProjectの古いバージョンでは、基準計画は11個しか保存できない、という制約があるので注意が必要かな。
Redmineにもそんな機能があるといいなと思ったが、何と、LycheeGanttChartにはそんな機能があると言う。

MSProjectに慣れたプロマネなら、Redmineに有償のプラグインを導入して、ガントチャートをMSProjectのように修正できると便利かもしれない。

【追記】
Kさんのツイート: "@akipii Redmine Easy GanttプラグインのPRO版=有償版にもベースライン機能があるので参考までに。 ▼URL https://t.co/itdMAcXNrH ▼動画(44秒〜) https://t.co/VipO4SqNyk"

| | コメント (0)

2016/07/23

Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例

Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。
チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。

【参考】
golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log

Big Sky :: コマンドラインからredmineを扱える「godmine」作った。

【1】(引用開始)
SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします.

面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....etcです.

実装担当者はRedmineを使う運用で問題なかったりするのですが,役職持ちの方から「Redmineはわからないから」とか「移動中にExcelで見たいから」などと言われると断れないのがサラリーマンの辛いところです.

あとは受託だとユーザとか元請にRedmineを強要できないので結局Excelになったりします.(しません?)
(引用終了)

【2】Redmineのようなチケット管理ツールを、開発チームがボトムアップで使っているのではなく、上司や経営者が上から目線で導入させたとしよう。
すると、Redmineは確かに現場に導入されるが、現場ではRedmineが必要で導入したわけではないから、なかなか根付かない。

一方、Redmineが普及して、会社の上司や経営者もPJ状況を見て欲しい、と思ったとしよう。
しかし、部課長や社長クラスの人は、管理作業や営業などで忙しすぎるので、Redmineをわざわざ触って、見る暇もない。
むしろ、メールで報告させたり、Excelを送ってもらって、印刷したプリントで見た方が楽だったりする。

すると、上司や経営者から、Redmineを見るのは面倒なので、メールで報告してくれ、とか、ExcelでPJ状況を出してくれ、と言われたりする。
そのための進捗報告書を作成するのに、プロジェクトリーダーは無駄な工数がかかったりする。
せっかくのRedmineが、上司や経営者の目には届かないのだ。

【3】その状況は、営業支援システムの事例でも聞いたことがある。

営業マンが顧客にアポを取ったり、契約状況を記録するために、営業支援システムを作り、営業担当者に日報を書かせて、上長がその日報を読んで管理できるような素敵なシステムを開発した。

しかし、営業部の課長クラスは、自身も営業しているし、打合せも多いので、営業支援システムにわざわざログインして、大人数の営業担当者の日報を毎日読む暇もない。
すると、営業担当者にとっては、日報入力という無駄な作業が増えているのに、その日報を上司が少しも読まないし、反応もない、と分かると、誰も営業支援システムを使わなくなった、と。

結局、メールやExcelベースの情報連携に戻ってしまった、という事例。

他にも、ERPに蓄積された財務情報やPJ情報を経営者向けに見える化したい、という情報系システムを多額の資金を投資しして開発したものの、経営者はそんなにシステムに明るくないし、システムの操作も最初から覚えるのは面倒なので、結局使われない。
すると、大金をはたいた、経営情報の見える化システムも使われなくなってしまう、という話もよく聞く。

【4】結局、会社の上司や経営者が、情報系システムを使いこなさなければ、現場に定着しない、という身も蓋もない話。
経営者向けの情報系システムは、大金をはたいた割りには、使用頻度が低く、誰も使わないシステムになりやすい。

いくらBIツールでビジュアルに見える化したとしても、彼らはそもそも情報系システムを使いこなそうという動機はさらさらないのだ。
個人的には、古い頭の日本の大企業に多い症状のような気がする。

そんなことをふりかえると、「見える化」という言葉は経営者は大好きだが、実際に使いこなせていない場合がすごく多い。
むしろ、現場主導で、自分たちの現場がやりやすいように、使いこなした方が賢明だ。
無駄なメトリクスの抽出、見える化プログラムの実装は、不要だと思う。

【追記】
言いたかったのは下記のコメントの通りかな。

はてなブックマーク - 岡崎良徳 のブックマーク - 2016年7月23日
(引用開始)
見ないものを見える化するのは無駄だよね、というお話。
(引用終了)

| | コメント (0)

2016/06/19

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響

大規模組織におけるRedmineを巡る諸問題について、色々考えている。
以下、ラフなメモ書き。
特に主張なし。

【1】最近は、Redmineに組織構造がどのように影響して、Redmineのプロセスや運用ルールが変形されるか、という問題意識を持っている。
下記3点について考えてみる。

1)Redmineプロジェクトに組織構造が出てくる点

但し、下記2点は後回し。

2)機能改善の要望への対処
3)保守コスト増に対する対処

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【2】最近は、Redmineプロジェクトはシステム単位に作るべきなのか、組織単位で作るべきなのか、という問題を改めて感じている。

以前から、Redmineの複数プロジェクト機能のおかげで、製品の並行開発や製品の派生開発がやりやすい特徴があった。
しかし、大人数のユーザで使用し始めると、組織構造の影響がモロにRedmineに出てきて、逆に運用ルールが複雑化しがち。
特に、Redmineでは、プロジェクトツリーをいくらでも深く作れるので、Redmineプロジェクトをその時々の判断で作ってしまいがちだ。

そもそも、Redmineプロジェクトはどの基準で作るべきなのか?

【2-1】本来のRedmineの設計思想を振り返ると、Redmineプロジェクトはリポジトリと1対1に対応すべき、と考えられる。
Ver1.4までは、Redmineプロジェクトにリポジトリを1個しか追加できなかった。
その後、複数のリポジトリを追加できるようになり、GitもSVNも複数のSCMリポジトリも登録可能になったので、その設計思想があやふやになったけれど、たぶん変わっていない。

すると、その設計思想では、Redmineプロジェクトはシステム(ビルドモジュール)単位になる。
実際、ソフトウェア開発案件のタスク管理では、システム単位にプロジェクトを作る場合が多い。

さらに、その設計思想では、Redmineプロジェクトのライフサイクルは、SCMリポジトリが新規登録されて、システムが廃棄される期間と一致する。
すなわち、Redmineプロジェクトはシステムの生存期間と同期するので、Redmineは特定の期限を持つ案件の管理に向く。

【2-2】逆に、Redmineプロジェクトを組織と対応付ける運用はやりにくい。
組織内にはたくさんの案件があり、作業の種類も多いので、一つのRedmineプロジェクトでチケット管理すると、すぐに発散する。
かと言って、小さくプロジェクト分割しても、組織のメンバーの入れ替わりも激しかったりするので、放置されやすい。
僕の経験では、Redmineプロジェクトを組織に対応付けた場合は、上手くいった経験があまりない。

【2-3】この発想を突き進めると、Redmineでタスク管理を行うと、開発チームはプロジェクト型組織になりやすい。
つまり、開発チームのメンバーは、別々の組織のメンバーであったとしても、Redmine上では、あたかも一つの有機的なチームとして活動する雰囲気になる。
これは、Redmineが組織に与える「良い影響」だ。

たとえば、業務系Webシステムの開発がメインのSIならば、一つの事業部内では、インフラチーム・アプリチーム・デザイナーチームのように機能別組織に分かれている場合が多い。
インフラ・アプリ・デザイナー担当者に要求されるスキルや技術は全く違うからだ。
(と言っても、最近のWeb開発では、アプリ担当者がインフラもデザインも全て担当するようになってきているが)

そして、実際の受託開発案件では、案件ごとにインフラ・アプリ・デザイナーの担当者が一つのチームを形成するようにアサインされて、作業を開始する。
Webサーバーの構築、画面のモックやデザイン配置、実際の業務ロジックの実装など、それぞれの役割分担で、作業しなければならない。
すると、各担当者は、その組織に応じた考え方や、特有のスキルに応じた考え方を持っているために、別組織の担当者と衝突しやすい。
インフラ・アプリ・デザイナーは機能別組織に所属しているから、そう簡単に融合できないのが普通だろう。

しかし、Redmine上では、一つの作業チケットを複数人のメンバーがやり取りして、完了まで持っていく。
そういうチケットのやり取りを何度も消化していくうちに、各担当者のコミュニケーションが生まれ、各担当者同士でお互いの背景や考え方の認識のズレに気付き、協調して、一つの作業を完了していく。

つまり、Redmine上では、自分の組織の役割を主張し合って衝突するよりも、チケットのやり取りを通じて、あたかもペア作業のような雰囲気が生まれて、一つの有機的なチームが形成されやすい。
Redmineではアジャイル開発のプラクティスを適用しやすかった、という僕の経験は、おそらくそのような構造があったからだろうと思う。

【2-4】しかし、Redmineの運用対象はプロジェクト型組織が向いているからと言って、いつも、サイロ型組織の悪習を打破できるわけではない。

実際、Redmineプロジェクトをシステム単位ではなく、組織単位に作ってしまう場面もたくさん見てきた。
「工程単位のプロジェクト」はRedmineの一つのアンチパターンと僕は思っているが、そのような作り方をやりたい時もある。

例えば、ある大規模な受託開発案件で、製造フェーズのみ外注のオフショアベンダーに発注したとする。
すると、設計・結合テストは国内チーム、製造フェーズはオフショアベンダーのように、工程ごとに組織が分断される。

すると、Redmineプロジェクトは、設計・製造・結合テストのように工程ごとのプロジェクトに分割したくなる。
実際、1個のRedmineプロジェクトで管理したとしても、前工程のチケットが交じると作業しにくいからだ。

また、障害チケットを発行する時、その障害の発生工程がどこであるか、を記入する事が重要になるが、それが当たり前の時、記入するのも面倒だ。
特に、オフショアベンダーから納品後のプログラムをテストして障害が出た時、その障害チケットは、他工程の障害チケットと明確に分けて、目立つようにしたい。
なぜなら、障害修正の責任は国内チームではなく、オフショアベンダーにあるので、そのコストをベンダーに押し付けたいからだ。
たいていの場合、オフショアベンダーの仕様の理解が甘かったり、国内チームの設計が甘いという色んな理由で、ベンダー納品のプログラムの障害は多発しがち。

すると、単純なトラッカー名「障害」ではなく、「障害(ベンダー名)」とか「障害(結合テスト)」のようなトラッカーを作ってしまいがちだ。
トラッカー名を他の名前と変えて、大きく目立たせるようにしたいから、そのような運用になってしまう。
つまり、トラッカーやワークフローも増加してしまい、より複雑になりがち。

また、そんな雰囲気になると、Redmine上では、障害修正やその対応に関するQAのやり取りで、メンバー全員が疲弊してしまう雰囲気になる。
Redmineがプロジェクト型組織を促し、メンバー同士のコミュニケーションを活性化させて、有機的なチームを形成するような影響も出てこない。

【2-5】いろんな事例を見てくると、Redmineプロジェクトがシステム(機能)単位なのか、組織単位なのか、という観点は、下記の基準で評価できると思う。

Redmineプロジェクトをシステム単位に設定したい時は、メンバーが地理的にも組織的にも分散せずに、一つのチームで固まっている場合だ。

Redmineプロジェクトを組織単位に設定したい時は、工程単位に国内チームとベンダー、オフショアチームのように、地理的にも組織的にも分割されている場合だ。

そのように考えると、ソフトウェアアーキテクチャだけでなく、開発プロセスも組織構造に大きく影響を受けてしまう事実がよく分かる。
まさに、コンウェイの経験則の正しさがRedmineでも感じられるのだ。

| | コメント (0)

2016/06/17

プロセスフロー図をRedmineチケットで表現するアイデア~Lychee Association Chartで実現できるか

@u6k_yu1さんのつぶやきから、プロセスフロー図をRedmineチケットで表現するアイデアを得たのでメモ。
以下は、まとまりのないメモ書き。

【参考1】
PFD(プロセスフローダイアグラム)で開発プロセスを設計する: プログラマの思索

PFDによる開発プロセスのモデリング - 千里霧中

Association Chart | Lychee Redmine

プロセスフロー図(PFD)作成アドインについて


【参考2】
u6k_yu1さんのツイート: "ゴールの成果物から逆順に作業・成果物を算出して、プロセスフロー図を作成する。 →図の作業を親チケット、成果物を子チケットとしてRedmineチケットを発行する。 →成果物とそれを必要とする作業にチケット関連を設定する。 →成果物に成果物定義をなるべく細かく書く。 →"

u6k_yu1さんのツイート: "@u6k_yu1 →動かせないマイルストーンを起点に、各作業の期間を設定する。 という手順で、作業チケット、成果物チケットを発行している。難点は、 ・期間設定をガントチャートで直接操作したいけど、プラグインが必要。 ・Redmineでプロセスフロー図を直接描きたい。"

u6k_yu1さんのツイート: "@u6k_yu1 うーん、やはりプロセスフロー図の作業、成果物とRedmineチケットを直接関連付けたいなぁ。"

akipiiさんのツイート: "@u6k_yu1 Lychee Association Chartが近いかな。プロセスフロー図は書けないけど。Graphvizを使ってスクリプトにするか。"

【1】PFD(プロセスフローダイヤグラム)はXDDP提唱者の清水吉男さんが編み出したもので、開発プロセスを一瞥するのにすごく良い。
プロセスと成果物を紐付けて、プロジェクトの開始から終了まで、一連の作業を図示できる。

たとえば、複数の成果物(例:テーブル設計書、画面設計書)がなければ、プログラミングできない、とか、一連の作業のボトルネックを把握するのに役立つ。
あるいは、結合テスト前までに、検証用環境を構築しておく必要があるとか、検証用環境を構築するために事前にパッケージ製品を購入して事前に検証しておく作業が必要とか、色んな作業をあぶり出すのに使う。

しかし、普通の案件では、WBSを作成して、それで終わりという所が多い。
スケジュール管理はWBSを洗い出したら終わりという気はしない。
むしろ、プロセスと成果物の一連のイメージがWBSでは湧きづらい。
だから、WBSだけ見ても、何が遅れて問題になっているのか分かりにくい。

WBSという無味乾燥なExcelの表形式の内容を、もっとビジュアルに表現して、何がボトルネックになりやすいか、をイメージしたいのだ。

【2】Redmineでは、WBSをチケットに置き換えることで、階層化されたガントチャートを自動表示できる。
つまり、WBSをチケットで一度表現してしまえば、ガントチャートだけでなく、色んなビューで表現できる可能性がRedmineにはある。
実際、WBSがチケットで一度登録できれば、EVMやリソースヒストグラム、PERT図でも表現することは理論上可能だ。

その発想をPFDにも適用して、Redmine上でPFDを表現できないか?

【3】たぶん、PFDのイメージに近いプラグインは有償ではあるが、Lychee Association Chartが近いだろうと思う。

Lychee Association Chartでは、チケットの親子関係や先行・後続の関連チケットを1枚の図に表してくれる。
つまり、PFDにおけるプロセスの先行・後続関係は、Redmineチケットの先行・後続関係に対応付けできる。

また、Lychee Association Chartでは、チケットとリビジョンを紐付けた関係も図示してくれる。
つまり、チケットにコミットされたソースやドキュメントが自動で紐づくので、チケットを成果物に対応付ければ良い。

すなわち、PFDにおけるプロセスの流れは、Redmine上で、チケットの先行後続関係、プロセスと成果物の関係は親子チケットと構成管理ツール連携で実現できるはずだ。

【3-1】Lychee Association Chartを使っている事例を読むと、作業と成果物の漏れがないか、点検するのに使っているようだ。

住友電装株式会社様における業務プロセスの見える化 | Lychee Redmine

もし、PFDがRedmineチケットで実現できるならば、計画したプロセス(=チケット)に対して、実績としての成果物(=SCMリビジョン)が紐付いていなければ、成果物が作られていないか、成果物の完了報告が漏れていることが考えられる。
そうであれば、品質保証部のチェックが入るまでに、Lychee Association Chartで出力した図を元に開発チーム自身でチェックできるし、そうすることで成果物の漏れを無くしたり、品質向上に役立つ可能性がある。

つまり、PFDのメリットである「開発プロセスを設計する」「設計された開発プロセスを検証する」という発想をRedmine上で実現しているわけだ。

【4】しかし、PFDをRedmineチケットで実現する場合、生のRedmineの機能では操作しづらいだろう。

チケットの先行後続関係、チケットの親子関係が複数レイヤになった場合、チケット一覧画面で、親チケットの番号を入力するとか、先行するチケットの番号を入力するなどの操作は非常に面倒だろう。
できれば、ガントチャート画面上でチケットの先行後続関係を簡単に操作したい。

Lychee Association Chartならば、操作方法についてはいくらか解決できるだろう。

【4-1】しかし、さらに、PFDを階層化したい場合、Redmine上で上記のやり方を一貫して行えるか?

たとえば、大規模受託開発案件の場合、複数のサブシステム単位に設計書が必要だし、他のサブシステムの設計書ができてから自分たちのサブシステムの設計書が作れる、というような依存関係もあるだろう。
あるいは、1個の画面を作るために、複数の成果物が必要だったり、その成果物を階層化したい時もあるかもしれない。

すると、PFDで表すプロセスフローは非常に複雑になるだろう。
チケットの枚数もかなり多くなるし、それらチケットを手作業で関連付ける事自体がかなりの手間だ。
また、先行後続で関連付けられたチケットを階層化する場合の運用ルールや考え方も事前に決めておく必要があるだろう。

たとえば、先行後続関係は親チケット同士に限る、とか、成果物チケットは必ず最下層の子チケットに配置する、などの運用ルールが必要になるだろう。
たぶん、チケットの枚数は数百~数千枚程度まで膨れ上がるかもしれない。
その場合に、PFDで表した数百枚、数千枚のチケットをRedmine上でそもそも保守できるのか、という疑問もある。
Lychee Association Chartを使ったとしても、PFDを実際に使ったノウハウがなければ、きれいに運用するのは難しいのかもしれない。

【4-2】とは言え、PFDをRedmineチケットで表現するアイデアは、色んな可能性を秘めていると思う。

プロセスと成果物の一連の関係をチケットで表現してしまえば、ガントチャートで進捗管理できるし、リソースヒストグラムでメンバーの作業負荷をチェックできるし、EVMでプロジェクトの採算や完了時点の最終コストを予測することもできる。
また、プロセスと成果物の関係は本来、PERT図で表現できるものだから、XDDPのプロセスフローダイアグラム(PFD)に置き換えることは理論上簡単なはずだ。

つまり、チケット集計による様々なビューを実現することによって、プロジェクトリーダーは、案件の状況を色んな角度から分析できるはず。

特に、日本ではXDDPの手法は一部でよく知られており、組込みソフトウェア開発における派生開発で既に実績もかなりある。
また、Redmineは元来、複数プロジェクト機能のおかげで派生開発の進捗管理もしやすい。
つまり、複数の製品開発(ソフトウェアプロダクトライン)や製品の派生開発のプロジェクト管理は、元々、Redmineに向いている部分がある。

したがって、そのXDDPの手法の一つであるPFDをRedmine上で実現できれば、成果物の漏れを無くすように開発プロセスの品質を強化できるし、派生開発のプロジェクト管理をより楽にできるように運用できる可能性があるはず。

色々考えてみる。

| | コメント (0)

2016/06/11

7/30土の第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいこと #redmine

7/30土に開催される第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」で議論してみたいことをメモ。
ラフなメモ書き。

【参考】
第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」 - RxTStudy~Redmineとタスクマネジメントに関する勉強会 | Doorkeeper

(引用開始)
7/30に第65回 SEA関西プロセス分科会&第15回 RxTstudy 「チケット管理システムによるプロセス支援と今後の課題」を開催します。
今回の勉強会のメインセッションは、JAXA様の担当者の方にRedmine運用の事例報告を講演して頂きます。

JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

JAXA様のRedmine運用事例報告を読むと、発注業務以外にISO9001も見据えた運用フローの標準化、ならびに、大規模な組織や多様な業務に対応できるようにRedmineの機能を十分に評価検証したことがよく分かります。
JAXA様の事例講演を次回も聞くチャンスはそうありませんので、ご興味のある方は是非ご参加下さい。
(引用終了)

【1】最近、Redmineの運用をいろんな場所で展開している時に思う問題意識は、二つある。
一つは、大規模な組織形態や多様な業務に対して、一つのRedmineインスタンスでカバーするには、Redmineにはどんな機能が必要で、どんな運用ルールが必要なのか。

もう一つは、組織構造とRedmineの相互関係を整理したいこと。
つまり、複雑な組織構造がRedmineやその運用プロセスにどんな影響を与えてしまうのか、ならびに、Redmineの導入と運用によって従来の硬直した組織の雰囲気を打破できる可能性はあるのか、を事例とその背後にある経験則を編み出したいこと。

【2】第10回東京Redmine勉強会のディスカッションで偶然聞いたグループでは、「闇Redmine」という言葉が出ていた。
つまり、一つのRedmineインスタンスでは他種類の部署の運用、多様な業務に耐え切れないので、自分たちのチームだけにこっそりとRedmineインスタンスを作り、自分たちのチームのソフトウェア開発プロセスの管理に使っている。

第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

ツール主導ではなく、自分たちのプロジェクトで成果を出すためにツールを使うのだから、このやり方はおかしくはない。
しかし、自分たちのチームで上手くいったRedmineを隣のチーム、自分の部署のすべてのチーム、他の部署へ展開していくと、Redmineはどんどん複雑化していく。
特に、ワークフローやカスタムフィールドは、野放しに複雑に設定してしまいがちだ。

また、自分たちのチームのプロセスが、保守案件や問合せ管理、事務処理ワークフロー、サーバー資産管理、購入機器の管理などの多様な業務をカバーできるとは限らない。
むしろ、一つのRedmineですべての業務をカバーする方が無理があるのかもしれない。

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

【2-1】JAXA様のRedmine運用事例では、こういう運用の複雑さに対する解決策として、「ロールのOR設定ルール」「カスタムフィールドのAND設定ルール」を提唱されている。
このやり方は、ERPのパラメータ設定のノウハウに似ている気がする。
少ないパラメータ設定で、多様な業務、多様な要件に対応するために必要な運用ルールなのだ。

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【2-2】以前のRedmineでは、ロール単位のアクセス権限の機能が弱いと言われていたが、随分改善されてきた。
Ver3.3では、トラッカーごとにチケット編集・参照の権限を付与する機能が追加される。

akipiiさんのツイート: "これは便利!RT @g_maeda: Redmine 3.3.0に入るのが確定。 ? Feature #285: Tracker role-based permissioning https://t.co/vImWQN2OZy https://t.co/CwSfqamCc2"

Feature #285: Tracker role-based permissioning - Redmine

アクセス権限管理の強化は、Redmineがエンタープライズ分野で利用されるに従って、重要なテーマになるだろうと思う。

【2-4】個人的には、@akahane92さんの思いと同じく、Redmineの機能をベースに、多様な業務に適応するための「ITSガイドライン」のようなものが作れるといいなと思う。
つまり、Redmineというプロジェクト管理用ERPのパラメータ設定の汎用的なノウハウをまとめてみたい。

「ロール設定のORルール」と「フィールド設定のANDルール」はもちろんその中に入るし、他にもたくさんあるはずだ。

akipiiさんのツイート: "面白そう。RT @akahane92: redmine 等のITSのトラッカー設計について、みんなどうしてるのかな。「ITSトラッカー設計ガイドライン」があればいいな。RxTstudyの参加者がトラッカーを持ち寄って、少人数グループで議論して持ち寄ると作れるかな。広く役立ちそう。"

Kuniharu AKAHANEさんのツイート: "@akipii 直感的で有効なステータス名、トラッカーとの組み合わせ、興味深いです。/背景と要求(例: 利用・運営者の組織文化、ITSによる問題解決の対象領域, 等)によるふれ幅がどの程度あるのか。/ケーススタディーの対象にしたとき、参考となるどのようなケースを引き出せるのか。"

neta@とんこつしかたべないさんのツイート: "@akahane92 @akipii いいですね!ウチはほとんど『依頼』、『課題』ですが、『課題』からそのまま解決のための『依頼』になってるチケットも多く、分ける必要なかったと思ってます。"

一つのRedmineインスタンスで、大規模組織でも多様な業務にも耐えれるような運用ルールを策定できれば、Redmineの利用範囲はもっと広がるだろうと思う。

【3】「組織構造とRedmineの相互関係」については、最近色々感じるものがある。

【3-1】従来から経験していることは、トラッカーやステータスは、そのチームの文化、その組織の文化が色濃く反映されることだ。

例えば、オフショア開発チームとRedmineでやり取りしていた時、「課題」トラッカーは使いにくく「QA」トラッカーの方が使いやすい、と言われた時があった。
ワークフローは同じなのに、トラッカー名が変わるだけで、メンバーのモチベーションもかなり上がった。

逆に、障害トラッカーで「リリース済」「対応済」ステータスを使っていたら、そのステータスにアサインされた担当者は何をすれば良いのか、直感的に分からないので、チケットが放置される場合もあった。
「~済」というステータスは、タスク完了なので、自分はやらなくていいんだよね、と思ってしまうらしい。

また、メーカーのように、営業部隊・設計部隊・製造部隊が組織として分かれていると、チケットが組織をまたぐ場合に別のステータスが必要になるという場合もあった。
チケットをやり取りするボールは誰が握っているのか、をステータスで明確にしたいのだ。
すると、メーカーのような機能別組織の場合、一つの製品、一つのソフトウェアを出荷するには複数の部門が関連するために、ステータスがかなり多くなってしまい、チケットが放置される危険が高くなりやすい。

一方、SIならば、普通は一つのチームが要件定義からリリースまで担当するので、一つのトラッカーに含まれるステータスの個数はそれほど多くはないし、多くする必要性もない。
チケット駆動で回したいならば、トラッカーに含まれるステータスの個数は少ない方が回しやすいからだ。

そんな経験を振り返ると、Redmineは機能が豊富な特徴、機能が柔軟である特徴があるがために、逆に、縦割り組織の文化をそのまま持ち込んで、複雑なパラメータ設定になりがちだ。

特に最近、ISO9001やITILの運用プロセスをRedmineに乗せて運用できないか、という質問を受ける時がある。
彼らとしては、Redmineの柔軟なワークフロー機能やREST APIによるチケット情報の取得の容易さ、Redmineの展開のしやすさを生かして、ISO9001のような硬いプロセスを実現したいみたいだ。

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 トラッカーやステータス・進捗率のからみは、組織やプロジェクトの癖がもろにでますね。何もなければ、このルールでやろうねと教育はしているののの、、、プロジェクトごとの癖をみて、ちょこちょこメンテナンスしたりしてます"

門屋 浩文さんのツイート: "@akipii @netazone @akahane92 ちなみに、トラッカー「WBS」「障害」「課題」「要望」「質問」「レビュー記録」、ステータス「新規」「受付」「作業中」「停滞」「確認中」「差戻し」「完了」「却下」です。きっと組織によってぜんぜん違うんでしょうね"

【3-2】一方、Redmineでチケット管理し始めると、チームの雰囲気や組織文化が少しずつ変わっていくという経験もある。

たとえば、Redmineには最初のバージョンの頃から、複数プロジェクト機能があった。
この機能を使うと、ソフトウェアプロダクトラインのような複数製品の並行開発、一つのパッケージ製品を顧客ごとにカスタマイズする派生開発に適用しやすいことは、従来から知られていた。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

この機能を使い始めると、メンバーは縦割り組織に属している感覚よりも、複数のプロジェクトで作業している感覚になる。
つまり、組織の建前としてはピラミッド型の組織構造かもしれないが、現場のメンバーにとっては、プロジェクト型組織に属しているような雰囲気になる。
すると、自分の役割や権限が広くなるので、能力のある若手はたくさんのシステムに触れる経験を得やすく、どんどん成長していく事例をよく見かける。

また、プロジェクト型組織になると、プロジェクト内でコミュニケーションが活発化する。
一つのプロジェクト内で、一つのチケットをやり取りして完了させるまでに、色んな部署の人達と連携しなくてはいけない。
だから、自分は○○組織の一員だから、という意識よりも、○○プロジェクトの一員という意識になり、縦割り組織の雰囲気をぶち壊し、風通しの良い組織文化を形成してくれる。

【3-2】また、チケットの構造がチーム内の組織形態を規定する事例も見かける。

若手のプロジェクトリーダーからよく聞く質問は、WBSやチケットは、機能単位で作った方がいいのか、作業ベースで作った方がいいのか、という内容だ。
設計・プログラミング・テストのような単位で作業をグループ化すべきなのか、それとも、画面単位や帳票単位で作業をグループ化すべきなのか、迷うらしい。

会社の研修で教わるやり方は、設計・開発・テストのような工程単位の作業管理だ。
このやり方は、元々、製造業で規模の経済を生かすための作業管理手法であるから、ソフトウェア開発に馴染まない、と僕は常々思っている。
メーカーの組織が営業・設計・製造・品質保証の部門に縦割りになっていて、機能別組織になっているのは、設備投資を有効活用し、製品を低コストで大量生産するために、規模の経済を生かすためにそのような組織構造になっているのだ。

しかし、ソフトウェア開発の場合、人月の経験則のように、作業メンバーを増やすほどプロジェクトはどんどん遅延していくことが既に知られている。
つまり、ソフトウェア開発は規模の経済が通用しない。
むしろ、機能単位に作業を分割した方が管理しやすい。
機能単位ならば、機能の粒度を小さくすることで、小さなチーム構成にすることが可能だからだ。

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索にあるように、工程単位のWBSと機能単位のWBSでは、PERT図の構造が全く違うし、WBSを管理しやすくするための組織構造がWBSに規定されてしまうのだ。

すなわち、チケットの構造は、プロジェクト型組織の役割分担を規定する。
チケットを階層化するほど、WF型開発っぽくなるし、チケットをバージョン単位でグループ化して小規模リリースを優先するなら、アジャイル開発っぽくなる。
開発プロセスは、逆に、組織形態を規定しまうのだが、それに気づかない人も多い。

【3-3】「ソフトウェアアーキテクチャは組織構造の影響をもろに受けてしまう」という経験則は、Conwayの経験則として既に知られている。
この考え方は、組織構造がソフトウェアアーキテクチャ、開発プロセスを規定することから、アーキテクチャやプロセスの複雑さの遠因には、ソフトウェア組織にあるということだ。

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う: プログラマの思索

一方、平鍋さんの記事で「逆コンウェイ戦略」という概念を知って、気づいたことがある。

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

「逆コンウェイ戦略」の発想は、より良いアーキテクチャに合わせて、チーム構成を作るべきというもの。
その発想を受け継ぐならば、より良いプロセスに合わせて、組織構造やチーム構成を決めてもいいのではないか。

実際、Redmineの導入によって、チームの文化や組織の文化は変わる。
その変化は良い方向性の場合が多い。
だから、積極的に、Redmineというツールの背後に隠れたプロセスを使って、縦割り組織を打破することも可能ではないだろうか。

【4】第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」のパネルディスカッションでは、上記のような経験や事例を元に、組織とプロセスの関係と、相互に与える影響について、パネラーや参加者の知見をまとめてみたいと思っている。


| | コメント (0)

2016/05/26

逆コンウェイ戦略のメモ~望ましいアーキテクチャを促進するためにチームと組織構造を進化させる

平鍋さんの記事で「逆コンウェイ戦略」という概念を初めて知ったのでメモ。
まだ消化不良なので、ラフなメモ書き。

【参考】
逆コーンウェイ戦略とDevOps, Microservices, Agile | an Agile Way

ThoughtWorks Technology Radar 2014年7月版

Inverse Conway Maneuver | Technology Radar | ThoughtWorks

James Lewis/Martin Fowlerの"Microservices"日本語訳 - 自由課題

分散スクラム

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク: プログラマの思索

第10回redmine.tokyoの感想~Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索

Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点: プログラマの思索

【1】(引用開始)
(8) Inverse Conway Maneuver (Trial) (逆コンウェイ戦略)
「望ましいアーキテクチャを促進するためにチームと組織構造を進化させること」、理想的にはテクノロジとビジネスのアーキテクチャが同じ形になることを提案する。
(引用終了)

(引用開始)
拙訳:
逆コーンウェイ戦略は、自分たちの望ましいアーキテクチャ設計を促進するように、チームと組織側を機動的に進化させることを推奨する。理想的には「技術的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。

現代流に言えば、
DevOps をやるなら、Dev と Ops を同じ組織にせよ。
Agile やるならワンチームで。
複数の Agile チーム構成にするとき、でビジネスに分かりやすい機能(フィーチャ)を重視するなら、コンポーネントチーム(ソフトウェアの部品に着目したチーム構成)でなく、フィーチャーチーム(機能縦割りのチーム構成)で。
Microservices アーキテクチャを採用するなら、小さなAgileチームをたくさん。
ということになると思います。

要するに、「人間や組織間のコミュニケーション(情報流)」というものがソフトウェア開発には決定的なインパクトを与える、ということをまず認め、それを積極的に活用するように、ということです。
「ソフトウェアは会話でできてる」(Software is made of conversations) という、このブログのテーマそのものだったので、ちょっと嬉しかったのです。
(引用終了)

【2】最近、Redmineの運用が大規模になっていくと、会社の既存の組織の枠組みが組織慣性となってしまい、軽量プロセスとして思うように運用できない場面に遭遇する時がある。
5人だけの1チームでチケット駆動でやっていても、ユーザ100人で50個以上のプロジェクトが運用されていれば、メンバー同士やチーム間だけでなく、会社としての開発業務がどのように運用されるべきか、という問題まで発展する。

そもそも、Redmineでは、Redmineプロジェクト=ソース管理の1リポジトリ=1システムという設計思想で作られている。
僕は、その思想を受け継いで、Redmineプロジェクトを階層化していけば何とかなると思っていた。

しかし、ソフトウェア開発のタスク管理以外に、ソフトウェア保守やサポートデスク、事務処理ワークフローまでRedmine運用を拡大すると、どうしてもRedmineの機能に不満が出てくる時もある。
そもそも会社としてどのような運用ルールが必要なのか分かっていないことが根本問題になってくる。
たぶん、RedmineやJira、Tracなどのチケット管理ツールだけの問題ではなくなってくるのだ。

つまり、組織構造に見合った運用フローをRedmineに適合させようとして、上手く適合できていない症状が現れていると思う。
その根本原因は、大規模運用に見合ったRedmineの機能不足もあるだろうが、むしろ、組織構造に見合った運用フローが組織内で明確化されてメンバー全員に共有されていない事の方にあると思う。

【3】Conwayの法則は「4チームでコンパイラを作れば4パスコンパイラとして無駄に複雑に作ってしまう」という経験則。
この経験則は、身近なソフトウェア開発組織でもよく見られる。
「鈍重な組織構造は鈍重で複雑なソフトウェアシステムを作る」とも言い換えられる。

(引用開始)
チーム メンバーが物理的に近接していない場所で作業している場合は、チーム内のコミュニケーションは確実により複雑になり、チームが作成するソフトウェアにも同じことが当てはまります。
1968 年に、Melvin Conway (メルビン コンウェイ) 氏は次のように説明しました。
システムを設計する組織には、その組織のコミュニケーション構造を反映した設計を作り出すという制約が課されます。

Conway の法則は、ただの格言ではなく、より実証的な説明です。
ソフトウェア開発チーム内では、測定可能な動的要因になる可能性もあります。
ある研究では、チーム分散という事実がシステム アーキテクチャに及ぼす影響を測定して、Conway の法則が実際に影響力を持つことが実証されました。
チーム メンバーが分散している場合は、ソフトウェア開発者が互いを分離しようとして、コード内でより多くの抽象化レイヤーを作成する傾向に陥りがちです。
(引用終了)

一方、逆コンウェイ戦略は、この経験則を逆手に取って、アーキテクチャに見合った組織構造になるように戦略的に組織構造を作り直すべきだ、と考えられる。
アジャイル開発をやりたい、マイクロサービスで開発したい、と思うならば、そのアーキテクチャに適合する組織になるように、戦略的に意図してチーム構成を考えるべきだ、とも言い換えられる。
面白い発想だと思う。

【4】この発想をRedmineによるチケット駆動開発に適用すると、どのような思想になるだろうか?

Redmineのプロジェクト、バージョン、チケット、トラッカー、ロール、カテゴリは、逆コンウェイの法則に即した組織構造とどのようにマッピングされるのか?

チケット駆動開発に逆コンウェイの法則を適用した場合、アジリティを活かした組織構造はどのようにあるべきか?

数多くの機動的なチーム(例:スクラムチーム)で運用する場合、数多くのチームがバラバラにならないように見通しが良くなるように統制する方法をRedmineの機能で提供できるのか?

| | コメント (0)

2016/05/18

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる

WBSの作り方は組織構造に依存するという記事がとても参考になったのでメモ。

【参考】
WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

【1】ガントチャート初心者からよく聞かれる質問は、「WBSは工程単位に作った方がいいですか?それとも機能単位に作った方がいいですか?」だ。

話を聞くと、工程単位にチケットを作ってみると、実際の開発フローに合っていない感触があり、途中で、機能単位にチケットを作り直す時が多いらしい。
WBSの作成方法は、工程単位と機能単位のどちらが正しいのだろうか?

(引用開始)
さて、3つの機能モジュール×3段階の作業プロセスだから、合計9個のアクティビティからなるプロジェクトである。
これをWBSに構成するとき、二種類の表現が考えられる(IT系の仕事になじみのない人は、「システム設計」「プログラミング」「テスト」をそれぞれ、「コンセプト開発」「製品設計」「量産準備」だとか、「機械設計」「資材調達」「製造」とか、自分に理解しやすい業務におきかえてみてほしい)。

WBS・案1
1 モジュールA
1.1 モジュールAを設計する
1.2 モジュールAをプログラミングする
1.3 モジュールAをテストする
2 モジュールB
2.1 モジュールBを設計する
2.2 モジュールBをプログラミングする
2.3 モジュールBをテストする
3 モジュールC
3.1 モジュールCを設計する
3.2 モジュールCをプログラミングする
3.3 モジュールCをテストする

WBS・案2
1 設計
1.1 モジュールAを設計する
1.2 モジュールBを設計する
1.3 モジュールCを設計する
2 プログラミング
2.1 モジュールAをプログラミングする
2.2 モジュールBをプログラミングする
2.3 モジュールCをプログラミングする
3 テスト
3.1 モジュールAをテストする
3.2 モジュールBをテストする
3.3 モジュールCをテストする

さて、上記二つの案のうち、どちらをとるべきだろうか? あるいは、両者は互換的(convertible)で、内容的に差はない、と考えるべきだろうか。
(中略)
ところが、両者は実務的には大違いなのだ。プロジェクトの生みだす成果物の品質や納期だって、大きな差が出るだろう。なぜだろうか?
(引用終了)

僕は今まで、案件の状況に合わせて切り替えたら、と答えていたが、上記の記事では、この質問の本質をズバリ言い当てていた。

(引用開始)
そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのWBSをとるか判断するべきなのである。
たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。
逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。
もしもこれが逆だったら、いかに仕事がやりにくいか、想像に難くない。
(引用終了)

【2】すなわち、工程単位・機能単位のWBSをPERT図に書いてみると、PERT図の構造は全く違う。

工程単位なら、工程ごとに合流して派生するから、工程に属する全てのタスクは全て同じ終了日までに確実に終わらなければならない。
つまり、工程内部では並行開発になるので、それぞれのタスクの同期が非常に重要になる。

普通は、SEチームが設計、開発チームが開発・単体テスト、SEと開発者の両チームが結合・総合・受入テストを行うようなチーム編成になるだろう。
すると、各工程ごとに開発要員の変動が大きく起きるので、チームを去っていく作業者の引き継ぎ作業が重要になってくる。

また、工程内でクリティカルパス上のタスクが一つでも遅れると、開発案件の全体の納期がすぐに遅延してしまう。
だから、残業や休日出勤で、その遅延をリカバリーせざるを得なくなる。

一方、機能単位なら、最初と最後だけ派生・合流し、途中の進捗は各機能でばらばらになる。
実際のチーム構造は、機能単位のチームになるので、チームは自分たちだけの機能の進捗を管理すればいい。
但し、他のチームと同期が取りにくいので、CCBやスクラムオブスクラムのようなリーダー会議を設けるなどして、機能間のI/Fや共通ライブラリの開発を調整したり、共同作業する場をもうける必要があるだろう。

つまり、WBSの構造は、チーム内のメンバーの役割と開発体制に影響させるし、その影響から離れられないのだ。

【3】上記の話をRedmineに当てはめてみるとどうなるのか?

工程単位にチケット管理したい場合も、機能単位にチケット管理したい場合も、チケットに書く作業は同じ。
チケットの先行・後続の関係を付ける場合、工程単位と機能単位ではPERT図の構造が異なるので、その内容が反映されるだろう。

また、工程や機能という概念をチケットのどの属性に当てはめるか、という運用も重要だろう。
たぶん2つある。
一つは、対象バージョン、もう一つは、親子チケット。

工程をバージョンに紐付けるのは直観的で分かりやすい。
工程の終了日までに、工程内のタスクを全て終わらせないといけないから、その制約条件と対象バージョンの意味合いは合致しやすい。
しかし、レビュー漏れ、仕様変更などで手戻り作業が何度も発生すると、設計工程がリオープンされてしまい、いつまで経っても設計工程が終了できない、という状況はよくある。
工程単位のWBSはとてもきれいな構造であるが、変化の激しい開発には合わないと思う。

そのせいか、MSProjectに慣れた人ほど、親子チケットでWBSを表現しようとする人が多い。
Redmineの最新バージョンでは、WBS100%ルールの設定ON/OFFができるようになったので、故意に子チケットを親チケットへロールアップする設定を外すこともできるので、柔軟な運用は可能になった。
親子チケットで階層化すれば、ガントチャート画面の見栄えは良くなる。
但し、チケットの階層が深くなるほど、メンバー全員で運用するのは難しくなるのでトレードオフになる。

一方、機能を対象バージョンに割り当てる方法は、FDDの言うパーキングロットチャートの機能と同じだ。
過去に@daipresentsさんが試されている。
機能の粒度が小さければ、パーキングロットチャートで表現すると分かりやすい利点はあるだろう。

Redmineプラグイン開発 ? パーキングロットチャートプラグインリリース

Redmineにプラグインを入れる - ソフトウェアエンジニアリング - Torutk

同様に、機能ごとに親子チケットでWBSを表現することも可能だ。
この場合、WBS100%ルールを使って、親チケットは子チケットの進捗情報をロールアップするように設定した方が進捗が分かりやすくなる。

但し、複数の機能に関する障害とか、仕様変更が発生した場合の作業は、チケットでどのように表現すべきか?という課題は残る。
実際は、それぞれの障害や仕様変更の単位でチケットをその都度作成する運用になるから、機能単位にWBSを作るのも、そんなに綺麗なやり方にはならないだろう。

個人的には、作業ごとにチケットを起票し、リリース日ごとにチケットをグループ化して小刻みにリリースしていくアジャイルな開発スタイルがチケット管理に最も向いていると思う。
WBSを綺麗にチケットに表現して管理していこうとすると、予期しないトラブルや仕様変更に耐え切れない。

【4】「機能単位・工程単位のWBSがプロジェクトの組織構造を規定する」法則をRedmineチケット管理に当てはめると、どちらでも運用できるし、WF型でもアジャイル型でも運用できる柔軟性はある。

つまり、WBSが組織構造を決めるという流れではなく、自分たちの開発体制にRedmineを合わせるという流れに持ち込みやすい。
換言すれば、Redmineは運用を非常にカスタマイズしやすいことを示唆していると思う。

Redmineの機能と組織構造、開発体制の依存関係については、他の観点でも色々考えてみる。

| | コメント (0)

より以前の記事一覧