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

2015年11月

2015/11/29

第9回東京Redmine勉強会の感想 #redmineT

第9回東京Redmine勉強会の感想をメモ。

【参考】
第9回勉強会 - redmine.tokyo

参加者は80名と過去最高の人数、そして渋谷dotsという素晴らしい会場のおかげで、内容の濃いRedmineの議論ができたと思います。
手作りのクッキーやコーヒーなども協賛のおかげで参加者に配布でき、リラックスした雰囲気で議論できたかなと思います。

勉強会の講演やオープンディスカッションで気づいたことはいくつかある。

【1】チケットに書かれた情報は管理情報とは異なる、という@sakaba37さんの指摘。
チケットには、開発チームで必要な情報が記載されているので、必ずしも管理上必要な情報が書かれているとは限らない。

例えば、障害の症状や解決方法、問合せの内容とその対応の経緯などは、作業者が必要だから記録しておく。
しかし、その作業の実績工数、対応時間などの情報、あるいは障害管理に必要な区分や種類などの情報は、現場の作業者にとって、それほど重要ではなく、きちんと入力するほど面倒。
しかし、その情報がなければ、いろんな観点のメトリクスを集計して分析するのは難しい。

そのトレードオフの関係があるのは僕も認識している。
そのトレードオフのデメリットを、チケット駆動の運用ルールや、Redmine本体のチケット入力の機能改善などである程度は改善できるのではないか、と思っている。

【2】親子チケットをツリー構造ではなく、多対多のような関係で表現したくなる場合の対処。
ゲームシーンでキャラクターが出る作業チケットの例を@agilekawabataさんがあげられた。

例えば、あるゲーム会社のゲームソフトを作る作業チケットがあったとする。
この時、キャラクター1は複数のゲームシーンで使われるので、複数のゲームシーンのチケットに紐付けて、進捗を管理したい場合があるらしい。

例:親1--子1--子2
ゲームシーン1を作る--キャラクター1を作る--キャラクター1の動作1を作る
ゲームシーン2を作る--キャラクター1を作る--キャラクター1の動作1を作る

対処方法としては二つあるだろう。
一つは、Redmineバージョンを親・子チケット全てに対応づけること。
そうすれば、ロードマップ画面で、EVベースの進捗率と見かけ上の進捗率の2種類で見れる。

もう一つは、「ゲームシーン1」配下の子チケット「キャラクター1」をコピー(複製)し、「ゲームシーン2」の配下に対応付けた後、コピー元の子チケットに「重複する」関連機能を持たせること。
すると、コピー元のチケットをCloseする時、コピー先のチケットも同時にCloseできるので、完了ステータスは同期できる。
但し、それ以外の属性情報は手作業で移す必要があるだろう。

MAEDA, GoさんはTwitterを使っています: "重複元をcloseすると重複先のチケットもcloseされる性質を利用 #redminet"

チケット同士の関連づけ | Redmine.JP Blog

この問題の根本解決方法は、チケットにエイリアスないしファントムのような機能があるといいのだろう。
つまり、オリジナルのチケットがあれば、そのチケットが更新されると、エイリアス先のチケットの進捗率やステータスも連動して欲しいわけだ。

【3】WF型開発における工程をチケットにマッピングさせるための方法。
@agilekawabataさんがあげた例では、①親子チケット、②バージョン、③トラッカーの3つをあげていた。

僕個人の経験では、MSProjectに慣れたマネージャは、親子チケットで階層化するタイプが多い。
つまり、親チケット=工程、子チケットに作業、機能、管理などを割り当てる。
進捗率が親チケット(工程)に集計されるメリットがある一方、ある工程に基づく子チケットを探すのが非常に面倒なデメリットがある。
但し、Ver3.1から、親チケットに紐付く子チケットを検索できるように改善されている。

Redmine 3.1新機能紹介: 親チケットおよび子チケットによるフィルタ | Redmine.JP Blog

アジャイル開発を知っているマネージャは、工程をバージョンに割り当てる。
僕個人もこちらの方法を勧めている。
Redmineのバージョンは「リリース予定バージョン」であり「XPのイテレーション(Scrumのスプリント)」であり「マイルストーン(進捗報告のタイミング)」である、という性質を利用して欲しいからだ。
但し、「工程単位のバージョン」というアンチパターンもあるので注意が必要。

【続】TiDD初心者が陥りやすい罠part2~工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

WF型開発にとらわれすぎたTiDDのアンチパターン #tidd: プログラマの思索

3つ目は、トラッカーに「基本設計」「詳細設計」「開発」「単体テスト」のように割り当てる方法。
トラッカーをワークフローではなく、作業の種類に割り当てる考え方。
チケットの画面を開いた時にチケットの種類がすぐに分かるメリットがある一方、似たようなワークフローのトラッカーが多くなりがちなデメリットもある。

このやり方に近い現場では、チケットのタイトルに「【詳細設計】」のようなプレフィックスを入れる運用もあった。
つまり、トラッカーはワークフローに合わせるが、工程名をチケットのタイトルに入れることで、一目で分かるようにしたい意図がある。
アジャイル開発のように短期間の高速開発よりも、工程にこだわった開発が主流の場合は、こちらの方がやりやすいのかもしれない。

似たような話として、@mattaniさんの講演で、親子プロジェクトを案件の中で「課題管理」「インシデント管理」「障害管理」に分けているのに使っているという話があって、面白いなと思った。
つまり、チケットの種類をワークフローやカテゴリではなく、Redmineプロジェクトで表現しているわけだ。

逆の意見としては、@akahane92さんの話のように、一つの製品開発では親子プロジェクトは使わず、一つのプロジェクトで管理し、チケットのコメントに作業の履歴を記録していく、という運用ルールもある。
製造業では、受託開発で多い製番管理が主流だが、製番をRedmineプロジェクトに対応付けて運用する方が管理しやすい、という主張。
この意見も、僕も納得しているし、そのように運用している。

【4】他のスライドはコチラ。

| | コメント (0)

2015/11/23

Redmineの合計予定工数と合計作業時間の表示機能

Redmineの合計予定工数と合計作業時間の表示機能についてメモ。

【参考】
Redmine 3.1新機能紹介: 予定工数・作業時間の仕様整理と合計予定工数・合計作業時間の追加 | Redmine.JP Blog

Redmineは実績工数管理システムになりうるか: プログラマの思索

Redmine 3.1新機能紹介: 親チケットの値(優先度・期日など)を子チケットと連動させない設定 | Redmine.JP Blog

Redmine3.1では、チケット一覧画面やチケット画面、工数集計の画面で、合計予定工数と合計作業時間が集計表示されるらしい。
仕様としては、下記になるらしい。

親チケットの工数(予定・実績)=子孫チケットの値の合計値 + 親チケットの値
子チケットの工数(予定・実績)=そのチケットの値

この機能はとてもありがたい。

以前のRedmineでは、WBSの100%ルールによって、親チケットの属性情報は子チケットの属性の和になる制約があった。
この制約はプロジェクト管理では当たり前の話だが、実際の運用では、親チケットに最初の予定工数を書いていた後で、子チケットをぶらさげると消えてしまう弱点があった。
当初の予定情報は残したい場合があるのだ。

また、WBSの階層構造であっても、親チケットは、工程かつタスクである場合もあるので、子チケットとは別に予定・実績工数を残しておきたい場合もある。

上記の仕様に統一されたことによって、Redmineを保守案件や要件定義フェーズの実費請求案件に適用して、実績管理システムとして扱う運用はかなり現実的になったように思う。

具体的なアイデアは、Redmineは実績工数管理システムになりうるか: プログラマの思索に書いたけれど、少なくとも、ユーザ別・日別・タスク別に予定・実績工数を集計できればいい。

具体的には、Redmineチケットに予定・実績工数を記録しておけば、DBから直接SQLを叩いて集計することで、いくらでも欲しい工数一覧を出力することができる。

SIのプロジェクトリーダーとしては、請負契約だけではなく、工数委託や派遣契約、実費請求の案件の管理もすごく重要だ。
しかも、それらの作業は実際はすごく煩雑な作業だ。
それら作業がRedmineというプロジェクト管理ツールによって自動化ないし効率化できないか、という要望が意外に多いのではないか?

色々考えてみる。

「Redmine Cookbook」英語版が発売されるらしいのでメモ。

【元ネタ】
Redmine.JPさんはTwitterを使っています: "Redmineによるプロジェクト管理技法など90のレシピを紹介する書籍 "Redmine Cookbook" (英語) が2016年2月に発売されます。 https://t.co/8vzrFcWlV2 https://t.co/XX38F74FG0"

Redmine Cookbook | PACKT Books

"Over 90 hands-on recipes to improve your skills in project management, team management, process improvement, and Redmine administration"

Redmine Cookbook: Amazon.co.uk: Aleksander Pavic: 9781785286131: Books

内容が気になるね。

| | コメント (0)

2015/11/12

経済学と法律に関するメモ

経済学やビジネス実務法務を勉強し始めてみて、感じたことをラフなメモ書き。
間違えている部分は後で直す。

【0】経済学や法律の内容を読み込んでみると、その背景にある思想や哲学は、自分の常識と違うロジックや観点に基づいているのに気付く。

【1】経済学の理論の前提では、人間の行動基準に仮定を置く。
つまり、人間は経済人モデルであると仮定を置く。

例えば、人間はすべての情報の完全性にもとづき、 合理的な意志決定を行う全知の人間である。
例えば、人は経済活動において合理的に利益を追求する。

つまり、人間は、オマケやブーム、偏った情報に基いて恣意的に行動する存在ではない、と勝手に決める。
感情的に行動を決めるのではない、と。
そこから、利潤極大化や費用最小化のロジックに進んで、一つの経済モデルを作り上げる。

しかし、人間を全知全能で合理的な意思決定を行う存在であると限定するのは、現実的でない場合もある。
だから、そういう場面では、経済人モデルに基づくモデルは現実の経済現象を説明できない。
そこで、別の仮定から経済モデルを作り、何とか現実の経済現象を説明しようとする。

すると、結局、どの経済理論が正しいのか、分からなくなる。
実際、ケインズ学派、新古典派、マネタリストなどたくさんの学派があるが、どれも、ある程度の現象は説明できるが、すべての経済現象を一つの理論でカバーできていないように思える。

経済学には、古典派経済学の第一公準とかコースの定理のように、まるで数学の公理体系に当てはめたかのような用語が出てくるが、とても怪しい。
数学の公理体系を理論として打ち出す場合、そもそもそれら公理がwell-definedであるか、つまり、無矛盾でないかを検証して、一連の補題や定理を導こうとする。

しかし、経済学の公準がそもそもwell-definedであるかどうか、検証しているフシもない。
すると、経済学の公準にはそもそも矛盾が入り込んでいるのではないか?
数学や物理のように、論理的な基盤の上に緻密な理論を作りあげようとしているが、実際はそこまで到達できていない気がする。

でも、マクロ経済学もミクロ経済学も、現代では知っておかねば食い物にされてしまうような気がする。
政治の場でも、ほとんどが景気対策や経済対策に関することばかり議論していることからしても、経済学の知識は必須になっているように思える。

【2】法律の基本である民法のロジックを読んでみると、人間は自然人モデルであると仮定を置く。
例えば、人は売買契約などを自己の意思基づいて、自由に承諾したり拒否することができる能力を持つ、と考える。
つまり、人は、社会の中で自由に契約を結ぶ時に、詐欺や脅迫、間違いなどに巻き込まれても、それに対抗して正しい判断を下せる、という前提を持っているように思える。

例えば、詐欺にあった時、善意の第三者に自分の財産が渡されてしまったら、自分の手に戻すことが基本はできない。
実際、新聞でも、詐欺にあった高齢者は、自分の財産(土地とか株とか色々)が他の第三者に渡った場合、取り戻せないから泣き寝入りしているような記事も見かける。

つまり、法律を読んでみると、だまされた人はスキがあるから、責任を追うべき(帰責)みたいな思想があるように思える。
すなわち、人は自由意志を持ち、自分で正確に判断できる能力を持っているのだから、騙される方が悪い、みたいな発想があるような印象を受ける。

これも一つの人間の見方なのかな。
人間という存在をどんな観点で評価するのか、という違いで、理論が分かれて、色んな結論が出てくる。
そういうことを考えると、自然科学ではなく、人間を対象にした学問は、人間が多様な存在であるがゆえに、たくさんの理論がありすぎて分かりにくい部分があるなあ、と思ったりする。

| | コメント (0)

2015/11/03

【告知】11/28土に第9回redmine.tokyo勉強会が開催されます

11/28土に第9回redmine.tokyo勉強会が開催されます。
5月以来、半年ぶりの開催になります。

【参考】
第9回redmine.tokyo勉強会 - dots. [ドッツ]

第9回勉強会 - redmine.tokyo

第9回redmine.tokyo勉強会 懇親会 (二次会) - connpass

(引用開始)
redmine.tokyo の第9回勉強会を開催します。

今回の勉強会のテーマは「お菓子を食べながらRedmineを語ろう」です。
具体的には、下記のテーマになります。

Redmineを運用している時の落とし穴はどんなことがある?
Redmineによるチケット駆動開発の導入・運用はどんな点に注意すると良いか?
Redmineのインストール方法やプラグインの使い方の注意点は何があるか?
オープンディスカッションからは、お菓子を食べながら、Redmineの使い方や運用の問題について語り合いましょう。
(スポンサーのご好意でお菓子を提供します)

普段恥ずかしくて聞けない初歩的な質問から、現場への導入方法や運用していて困っている事の解決方法など、何でも聞いてみましょう!
(引用終了)

今回は、Redmineの初心者や中級者向けに、幅広いテーマで議論できるように、渋谷dotsという素敵な場所を借りることができました。
ちょっとしたお菓子もありますので、くつろいだ雰囲気の中で、Redmineに関する初歩的な質問や、導入や運用に関する悩みなども意見交換できると思います。

今年は、Redmineに関する著作が4冊も出版されて、日本ではRedmineがかなり注目されている状況なので、1年の締めくくりとして、Redmineの今後の発展についても議論できたらいいなと思います。
興味のある方はぜひご参加下さい。

| | コメント (0)

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