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

pdumpfs
- 年初に買った外付けHDDへのバックアップは Linux、Windows とも pdumpfs で。
Memcached
- 簡単・高速なキャッシュシステム。使える。
Firefox
- Galeon がだんだん使いにくくなってから Mozilla へ。その後正式リリースされた Firefox に乗り換え。
Subversion
- 将来的に CVS から移行する事を考えて試験的に導入。良い。Windows でも TortoiseSVN のおかげで簡単に利用できる(CVS にも TortoiseCVS が出て便利になった)。
影舞
- 今年前半のプロジェクトで活躍。
PAR
- Windows 向けのプログラムを Perl で書いて気軽に配布できるようになった。素晴しい。wxWidgets + wxPerl を使えば Windows / UNIX のどちらでも使えるGUIアプリケーションが作れる。そういう意味で Java 以外の選択肢として選べるようになった。最も wxWidgets はまだきちんと使い込んでいないけれど。
NSIS
- 前述の PAR で exe 化したプログラムのインストーラを作成するのに活用。
Template Toolkit
- Webアプリケーション開発プロジェクトで採用。www.naney.org の静的コンテンツの生成でも使い始めた。

Palm OS 生活復活

PEG-TJ25を購入し、Palm OS 生活復活。最初はおもちゃのつもりで買ったのだが、プロジェクトマネジメントなどにシフトした仕事のスケジュール管理などで大活躍。

PDA 市場の明るい話はあまり聞かないが、末長く製品が出て続けて欲しい。

[ permalink ]

[ 12月31日全て ]

2005年5月27日 (金)

新給与通知

先月発表のあった給料アップの正式な通知が届いた。貢献度を評価し算出したとの事なので、いわゆるベースアップだけではなくて査定昇給とセットになっているようである。

プロジェクトマネジメント的な役割などより責任のある仕事が増え、ここ数年いろいろ新しい手法を試行しつつやってきた。その辺りを含めて評価してもらっているようなので、その点は満足である。

しかし好きなオモチャをガシガシ買えるようになるには、まだまだ満足のいく額とはいえない。さて、今年はより攻撃的にしかけて組織をもりあげていきますかね。

[ permalink ]

[ 5月27日全て ]

2005年10月19日 (水)

コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。コミットメント・リスト派とはまさに私の事である(多分)。いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。「ガントチャートは駄目」だとも思っていない。以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。両方同時に使っているケースもあるであろう。またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

作業時間がある程度精度よく見積もれる
作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

ガントチャートを利用したマネジメントの特徴

マネージャーからのトップダウン的なスケジュール向き
リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
比較的多人数のチームでもいける
リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
人月計算/コスト積算できる
プロジェクト外からの割り込みの発生によって狂いやすい
成果がみにくい
チェックしにくい
- 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
ぱっと見、計画できている気がする
期間が長いと、チャートが見にくくなる
1日単位で見積もりたくなる
休日が気になりだす

コミットメント・リストを利用したマネジメントの特徴

担当の裁量を尊重・重視
コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
期日前にせっぱつまりやすい
依存関係が複雑だと把握しにくい
専用のソフトウェアがなくても可能
他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
線表派からみると計画だと思ってくれないかも

自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

スケジュールの変更があった時に面倒
現状とあわなくなってくるとだんだん見なくなった
結局だんだんメンテナンスしなくなってしまう
進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

コミットメント・リストでうまくいっている点

成果が達成できているか、そうでないかが明確
達成できていないコミットメントのチェック、フォローができている
担当自身が忘れていたコミットメントもクロスチェックで再認識できる
コミットメント一つ達成するたびに「いい気分を味わえる」

まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。自分が扱っているプロジェクトがそういうものではないのだなと。

[ permalink ]

[ 10月19日全て ]

2006年11月22日 (水)

「プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャーには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトプロジェクトマネージャーは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が～～で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

技は盗むもの - 早朝会議革命

とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

問題発見力、問題解決力 (思考法)
意思決定力
リーダーシップ力
コミュニケーション力
- コーチング
- ファシリテーション
プレゼンテーション力
(リスク管理力)
以下に関する知識
- 開発ガイドライン
- ソースコード管理 (リビジョン管理)
- バグトラッキングシステム
- ビルド管理
- リリース管理
- ドキュメンテーション
- ソフトウェアテスト
- ソフトウェア見積もり
- ソフトウェアライセンス
- ピアレビュー

[ permalink ]

[ 11月22日全て ]

2007年4月23日 (月)

ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。渋い。

TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

http://www.taskjuggler.org/

[ permalink ]

[ 4月23日全て ]

2013年3月6日 (水)

マトリクスが書けるマインドマッピングソフト XMind に惚れた

マインドマップを書く時、最近は(といってもしばらく書いてないけど) iPad 用の iThoughtsHD を使ってる。直感的に使えるしエクスポート結果も綺麗だし、クラウド連携も良くできてる。

ただ難点があって iPad 2 が手元に無い時は使えない。PC だとたまに FreeMind とか使ってたけどちょっと表現や出力がモダンじゃなくて高まらないので、別のを探してみることにした。

Mindjet: プロジェクトマネジメント的な機能までついていて高機能だがべらぼうに高い。
XMind: Windows でも OS X でも Debian でも動く。ポータブルアプリケーション版もある。
MindMeister: ASP タイプ。有料だと月 $4.99 から。個人ではいいけど、仕事ではちょっとまずいかも。

XMind をチョイス。

http://www.xmind.net/

Eclipse ベースなので見た目も綺麗だ。気にいった点はマトリクスが書けること。多次元マインドマップツールとまではいかないけれど、表が書けて、別のツリーからその表上のトピックに関連線をつけられる! ひゃっほー。こういう図が書きたかったのよという感じ。

フリーだと PDF 出力が無いのはちょっと惜しい。Gantt View も使える XMind Pro 2012 が気になるんだけれど $99 なんだよねぇ。ちょっと高い。でも PDF 出力のためだけに $79 の XMind Plus 2012 のライセンス買うのものなあ。しばらくはフリーで使い込んでみよう。

[ permalink ]

[ 3月6日全て ]

2017年2月23日 (木)

「Inspired 入門」 (第1回)

プロダクトオーナーやプロダクトマネージャー(PdM)の必読書と言われているらしい「Inspired: 顧客の心を捉える製品の創り方」の内容を理解し、実践・共有することで力をつけていきましょうという「Inspired 入門」勉強会に参加してきました。今日が第1回。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。

各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。CS 部門経験者の方も何名かいて、ぐっと親近感がわきました。

今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。感謝。

話題から

ある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。

PdM という役職・肩書のある会社はというお題については、ほとんどの方がないということでした。

それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。なるほどです。

Inspired より

今回は1章から3章がトピックだったので以下個人的なメモ。

第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。

第1章: 製品開発の鍵を握る担当者とその役割

まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。

プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。

プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。

プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。

第2章: プロダクトマネジメントとプロダクトマーケティング

「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」

プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。

第3章: プロダクトマネジメントとプロジェクトマネジメント

ここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。

Inspired: 顧客の心を捉える製品の創り方

[ permalink ]

[ 2月23日全て ]

2018年7月27日 (金)

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

タイトル
概要 (What)
目標 (Goals)
背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

プロダクト名
プロダクトビジョン
- 概要
- 目標
- 背景と目的
- 成果物
- 完了条件
- スコープ(含むの・含まないもの)
- (opt) 依存するプロジェクト・制約条件
- (opt) リスク
- (opt) 予算
- (opt) メンバ
概要レベルのプロダクトバックログ
プロダクトロードマップ