前回のプロジェクトでは上位の管理者に進捗状態を定量的に報告するためにEVMスケジュールを作成した。前回のエントリで書いたように、デスマ過ぎて途中で管理を放棄せざるを得なくなってしまったけれど、意外と簡単に作れることがわかった。
MSProjectのようなソフトがあればそれに越したことはないんだけどね。

簡易EVMスケジューラの構成

報告用のサマリシート
進捗入力用シート

のみのシンプル構成。
各アクティビティ(最小単位)のACと進捗率を記入すると、全体、各タスクのコスト指標、スケジュール指標等が自動で算出される。
サマリシートには、指標に対する分析結果、その週に発生した問題と状況、今後発生するかもしれない問題も一緒に書いておく。

常駐先で貸与されたPCで作成したものだから持ち出すことが出来ず、雛形は藻屑となってしまい。。。

フリーのEVMソフトは
http://www.vector.co.jp/soft/win95/personal/se452778.html
これ以外みかけないなあ。

2010-01-22

Trac運用の反省点、というより、それ以前の問題に対する反省

Trac プロジェクト管理

昨年、サブシステムの性能改善チームのリーダーとして2人の後輩社員と共に、とある大規模プロジェクトに参画した。
メンバー間の情報の連携、タスク指示には「Trac」を導入したのだけど、全然運用できなかったので反省点をまとめてみる。

Trac運用の反省点

１．運用する余裕がない。

　そもそもの問題点として、無茶苦茶な納期で上からの作業指示が来るものだから管理工数が捻出できない。チケット発行して、更新して、進捗管理して、とやるより、目の前にある作業をこなすことに忙殺されてしまった。　

よって、Tracは全然悪くない。Tracどうこうの問題ではない。
「納期が厳しいなら、リーダーの責任で調整すればいいじゃない。」
正しい。それは、確かに正しい。しかしながら、そのような傍から見ればもっともな申し立てが通じない環境は実際に存在する。経験上、大規模プロジェクトにその傾向は顕著に見られる。いくつにも階層化された指示系統を逆流することは想像以上に困難で、どこかで弾き返されてしまう。顧客に提示したマスタスケジュールは絶対であり、プライムの面子としてこれを遅らせることは余程の事情がない限りは出来ない。このようにして、末端には無数の屍が築かれていく。

　さて、そうした環境の中、リーダーとして出来ることは

成果物は必要最低限になるよう交渉する
上位のリーダーに要員を増やしてもらうなどの相談を行う

ぐらいしかなかった。もっとうまいやり方がないか、常に模索していく必要があるね。メンバーを守るのはリーダーの責任でもあるし。

２．Tracの効果を伝えられない。

　納期に余裕があり、きちんと管理工数が工面できていたと仮定して、思うように運用できていたかを考えてみる。

　おそらくは、こちらが期待する運用にはならなかったと想像する。それはプロジェクト参画当初の、Trac導入直後の様子から伺える。Trac導入のメリットとして、作業がチケット駆動となりWBSと対応させて作業の指示漏れが防止できることや、作業の進捗状態や履歴が把握しやすいなどが挙げられる。やや乱暴な言い方をすると、これは管理者視点でのメリットであり、実際に頻繁に更新するであろうメンバーにとっては面倒な作業が増えただけで、メリットをあまり感じられない。メリットが感じられないのだから動機付けが弱い。動機付けが弱いから、Tracの存在感が薄くなる。そして、段々更新しなくなる。

　メンバーに「ちゃんと更新しろ」と指示する事はいたって簡単なのだけど、根本的解決にはならない。たぶん、続かない。それどころか、「Trac嫌い」になる可能性の方が高い。

「Tracを使うと便利だ！」と体感してもらう、あるいは、理解してもらわなければ意味がない。プロジェクト管理を経験したことのある位のメンバーならば導入メリットを感じるところだろうが、若いメンバーに対してどのようにメリットを伝えていくべきかは考えていく必要があると思った。今後の課題。

2010-01-21

IT用語-トランザクション関連

IT 用語

ロックベース同期制御における代表的な用語

ミューテックス

ミューテックス(Mutex)とは、クリティカルセクションでアトミック性を確保するための同期機構の一種。Mutexという語はMUTual EXclusion(相互排他)の略である。セマフォをクリティカルセクションの排他制御に用いる時、セマフォでは(初期値が1でなければ)複数のタスクがクリティカルセクションへ入ることを許可するのに対し、ミューテックスでは同時に一つのタスクしかクリティカルセクションに入ることを許されない(ここで言うタスクとは、スレッドまたはプロセスを指す)。挙動はセマフォ変数の初期値を1にする事と等価。

セマフォ

セマフォ(Semaphore)は、コンピュータにおいて、古典的でかつ現在も利用される同期機構の一種。

　Mutexでは、資源利用可能なタスクは1つのみに限定されるが、セマフォの場合は資源利用可能なタスク数をセマフォ変数として任意に設定できる。

ロックベース同期制御の問題点

ロックベース同期制御では、資源を獲得しようとするタスクが多ければ多いほど待ちが発生し性能が劣化してしまう。
デッドロックを考慮して処理を実装する必要がある。実装、テストにコストがかかる。

上記の性能問題を解決するひとつの手段として「ソフトウェアトランザクショナルメモリ」がある。

ソフトウェアトランザクショナルメモリ

データベーストランザクションに似た並行性制御機構であり、並列計算を行う際の共有メモリへのアクセス法である。この機構はロックベースの同期の代替手段として機能し、普通はロックフリーな方法で実装される。

以下のような流れで処理される。楽観ロックみたいなもんだ。

http://d.hatena.ne.jp/hayamiz/20080529/1212043766
transactional memoryにおけるトランザクション

  1. トランザクション開始
  2. 共有資源の読み書き
  3. トランザクション中で操作したメモリが、
     トランザクション開始時点から
     (他のトランザクションによって)更新されているかチェック
          * 更新なし：コミット&トランザクション成功
          * 更新あり：ロールバック&トランザクション失敗

ソフトウェアトランザクショナルメモリ方式の問題点

　このようなアルゴリズムは False Positive（偽陽性）という問題（あるいは ABA問題）に対処しなければならない。古い値を読み取った後、CAS命令を実行するまでの間に、そのメモリ位置の内容が複数回書き換えられて偶然もとの古い値と同じビットパターンになっている可能性がある。

→比較するデータに一意性を持たせることによって判別は可能。

2010-01-21

クラウドを理解する上でのキーワード

CAP定理

http://el.jibun.atmarkit.co.jp/forest1040/2009/06/caporacle-rac12.html

CAP定理とは、以下の３つを同時には満たせないという定理です。

C：Consistency（データの一貫性）
　　データの更新後、ほかからそのデータを参照した場合、必ず更新後のデータが参照できることを保証すること。
A：Availability (システムの可用性)
　　どのような状態であっても、データの参照が可能であること。例えば、ロック待ちにならない。
P：Tolerance to network Partitions (ネットワーク分断への耐性)
　　データが複数のサーバに分散されており、1つのサーバに障害が発生し、データが破損した場合でも、別サーバのレプリケーションにより、データが参照可能であること。

クラウド環境では、今回説明するCAP定理により、システム全体としてACIDを完全に満たすことは難しいため、BASEという考え方でシステム設計を行います。

BASEトランザクション

http://labo.mamezou.com/special/sp_001/sp_001_005.html

Basically Available（基本的に利用可能）
Soft-state（柔らかい状態）
Eventual consistency （最終的な一貫性）

これは、可用性が最重要視され、緩い状態を基本として、最終的に一貫性が取れる、という事を意味しているようです。

Oracle RACで理解するCAP定理

http://el.jibun.atmarkit.co.jp/forest1040/2009/06/caporacle-rac-2.html

2010-01-20

Doctor Belee@みなとみらいクイーンズスクエア

日記

昨年は余裕で過労死認定される程度の残業をしつつも、暇を見つけてはお気に入りのシャツはないものかとネットやお店を徘徊しておりました。
もう唯一の楽しみ、と言っても過言ではなかったです。ウフフ。

カラーが白い「クレリック」と呼ばれるタイプのシャツが好きなもので、そればかり買い集めていたのですが、もっとデザイン性豊かなクレリックはないものかと常々思っておりました。

そんな中、先日クイーンズスクエアにて『Doctor Belee』というビジネスシャツ専門店を発見したのでございます。
琴線に触れまくるデザインのシャツがてんこ盛りで感涙。
もうアタイここでしか買わないんだから！！

2008-12-14

管理ドキュメント2

プロジェクト管理 Trac

前回のエントリー12/7 管理ドキュメントの続き。
今回のプロジェクトで運用するドキュメントについて。

Trac
要件管理表
課題管理表
問題管理表
問い合わせ表
EVMスケジュール

要件・課題・問題管理表

ExcelReportExport

以前のエントリータスク管理の方法でsyo様より紹介頂いた「チケットをExcelに出力するプラグイン」(http://syo.cocolog-nifty.com/freely/trac_excelreportexport.html)を使ってみた。
コマンドプロンプトを開き、解凍後に作成されるディレクトリに移動し、「python setup.py install」でインストール。(後で調べなおしたら(http://discypus.jp/trac/sandbox/wiki/TracPlugins)、eggファイルなるものを先に作るらしい。けど、作らなくても使えてる。)

感想

結論としては、これを使えば管理表３種を別で作成する手間が省けそう。
Excelに出力される帳票はカスタムクエリの検索結果なので、分類で絞り込めば「要件だけ出したい、課題だけ出したい、課題と問題だけ出したい。」という要求にも簡単に対応できる。
ユーザーの我儘を言わせてもらえば、出力対象のカラムが指定できると出力後の手直し作業が減るので、あれば助かるな、と。

レイアウトに関して、少し利用者側の工夫がいるかも。
これはExcelの仕様の話なので、プラグインの問題じゃないんだけど、一つのセルに長文が入っちゃうと縦に長くなっちゃって、場合によっては画面に表示されてるのが2チケット分くらいの情報量になってしまう。今は、チケットの説明やコメントに、メール本文のコピーを貼ってるので、どうしても長くなりがちになってしまう問題がある。出力したそのままだと、一覧性が良くないという問題。

チケット一覧のサマリ情報と、チケットの詳細情報を別にしたらどうだろう。「サマリ情報として1シート、チケットの詳細情報としてN個のシート」にして、相互参照。
この資料を使う会議で、どこまで詳細な情報を必要としているの？っていうところがグレーだから、分割型の方がいい、とは言い切れないし、対応するにしてもプラグインの修正が必要でちょっと敷居が高い。

現在の構成をそのまま使う場合、「長くなりがちなコメントは非表示(必要に応じて表示)」にした上、「チケットの説明を簡略化」すれば、縦にビロ〜ンと伸びるのを回避できそう。メールなり議事録なりの必要最低限の部分だけ編集して、説明に書くようにして容量を減らす。根本解決にはなってない気はするけど。

というわけで、また来週から試行錯誤。

問い合わせ表

これも、チケットの分類で「問い合わせ」というのを作って、いくつかカスタムフィールドつくって、Excel出力しちゃえばいらなくない？と思った。プラグインでカスタムフィールドの出力ができるかは実験する必要がある。チケットのコメントは履歴そのものだから、問い合わせの経緯を追うのも楽だよね。それをサマリしちゃえばいい。

次はEVM。