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

プロジェクトマネジメント - project management

スポンサード リンク

2004年4月24日 (土)

DateBk5 + Progect でのリソース別タスクチェック

ここ最近Palmの使い方で思案しているのは「リソース別のタスクのチェック」。 ここでリソースとは仕事上のスタッフのこと。 スタッフをリソースと呼ぶのはちょっとひっかかる部分もあるが、プロジェクトマネジメントツールとかではそうくくってしまうのでそれに合わせて呼んでおくことにする。

プロジェクト毎のチェックリストProgect を使ってみているが以下の点で困っていた。

  • 複数のプロジェクトに同じスタッフが参加している場合(複数のProgectプロジェクトデータベースに割り当てを入力してある場合)、誰がどのタスクを掴んでいるのか見通すことができない。
  • Progect 上のアクションを To Do とリンクさせられるのだが、スタッフに割りあてたアクションを何も考えずにどんどんリンクさせていくと To Do が溢れて逆にわかりづらい。自分自身の To Do やスケジュールが埋もれてしまう。

で、次のような方法を考えてみた。

  • To Do に「プロジェクト」カテゴリを作成
  • スタッフに割り当て済みのアクションは Progect 上で項目名に《スタッフ名》を含むようにする。あるいは、アクションを《スタッフ名》を含む階層の中に入れる (これで To Do にリンクした際に、その To Do に《スタッフ名》が含まれるようになる)。
  • このアクションのカテゴリを「プロジェクト」にして、ToDo Link する。
  • 優先度は、重要なものは1、それ以外は 2以上にしておく。

Progect で指定したカテゴリと同名のカテゴリが To Do にあると、そのカテゴリに To Do が作成される(同名のカテゴリがないと未分類)。

次に、DateBk5 側。

  • 今まで使用してきた「ビジネス」カスタムビューで、「ビジネス」カテゴリだけを表示していたところに加えて、「プロジェクト」カテゴリで優先順位1のものも表示するようにする(「ビジネス」カテゴリは自身の To Do、スケジュールが書かれている。ここにはスタッフのタスクを表示したくはないが、重要なものだけは表示できるようにしておく)。
  • 「プロジェクト」カスタムビューを作成し、「プロジェクト」カテゴリだけを表示するようにする。

これで特定のスタッフに割り当てられているタスクは、DateBk5 で「プロジェクト」カスタムビューから「リスト表示」を選択し、《スタッフ名》でフィルタリングすることでピックアップできるようになった。

カテゴリ名は「リソース」や「スタッフ」等でもいいのだが、項目名(あるいは階層に)【プロジェクト名】を含ませておいて、この文字列でフィルタリングして指定したプロジェクトのタスクのピックアップということも考えたので「プロジェクト」というカテゴリ名にしてみた(一つの仕事上のプロジェクトを、「テスト」や「マニュアル」とかいったくくりでProgect 上の別プロジェクトデータベースにわけていることあって、これらを横断的に眺めたいなというのもあって)。

スタッフについてタスクレベルまで管理するつもりはないのだが、頼んだことを自分自身も忘れてしまうことがあるのでそれのチェックにうまくこの方法が使えればいいかなと。

スポンサード リンク
[ 4月24日全て ]

2004年10月25日 (月)

第2章 リスク管理はおとなのプロジェクト管理

チーム・リーダー 「この件については明日会議を開きますが、事態は悪化しそうです」

プロジェクト・マネージャー 「では会議をやめよう」

(熊とワルツを p.15)

新幹線の中で読む。

いつもながらトム・デマルコの著書は明快。 普段プロジェクトではっきりとしないけれど何となく心にひっかかっているものが、しっかりと書かれている。 素晴しい。

[ 10月25日全て ]

2004年12月27日 (月)

Project@Hand 2 購入

来年のプロジェクトのスケジュール/タスクを検討中。

先週末から GanttProject 1.0.3 を使ってちょこちょこ線表を書いて考えているのだが、まだこのソフト自体完成度が高くないのでいまいちタスク設定に集中できない。

  • スクロールの勝手が悪い。
  • リソース別の表示ができない。
  • 休日の処理が強くない。
  • 印刷もいまいち。画像でチャートを出力する際も出力範囲がいい感じに指定できない。

(印刷以外において)これらの点で以前試した Project@Hand 2 が結構良かったのを思い出す。 もう一度インストールして試用してみる。

Palm OS 上での作業になるので画面は狭いものの表示が良くまとまっているので、小・中規模のプロジェクトなら十分。 前回の試用では使ってみなかったが、フィルター機能で指定したリソースだけ表示したりリソース未割り当てのタスクだけ表示だけできる。

プロジェクトのタスクのチェックに Progect も使ったりしているが、こちらはリソースの割り当て状況を確認するといった用途には向かない。

来年は Project@Hand 2 で行ってみるか。

ということでライセンス購入。$29.95 (USD) 也。

今後は

というコンビネーションで。

[ 12月27日全て ]

2004年12月31日 (金)

私的10大ニュース2004 [ work ]

今年の大事件、マイブームなど。

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

入社して満3年。今年は随分仕事の内容が変わってきた。 トム・デマルコの本を読んでみたり。 事後評価セッションを実施してみたり。

サーバ移行

DNS サーバメールサーバ、Web サーバを一斉入れ換え。Debian GNU/Linux に移行。 RAIDではまる。

RAIDまわりが何かよろしくないようだし、ホスト自体以前デスクトップとして使っていたPCなので安定したものに置き換えたい。

飲み会

私的10大ニュース2004 [ comp ]

cool programs

Palm OS 生活復活

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

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

http://www.naney.org/img/2004/X/X2004-03-05-0003.jpg http://www.naney.org/img/2004/X/X2004-03-14-0004.jpg http://www.naney.org/img/2004/X/X2004-04-10-0001.jpg

[ 12月31日全て ]

2005年5月27日 (金)

新給与通知

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

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

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

[ 5月27日全て ]

2005年10月19日 (水)

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

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

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

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

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

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

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

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

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

モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

[ 10月19日全て ]

2006年11月22日 (水)

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

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

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

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

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

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

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

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

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

[ 11月22日全て ]

2007年4月23日 (月)

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

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

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

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

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

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

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

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

TaskJugglerUI

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

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

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

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

印刷

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

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

面倒な点といえば

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

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

ということで

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

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

[ 4月23日全て ]

2013年3月6日 (水)

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

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

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

XMind をチョイス。

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

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

[ 3月6日全て ]

2017年2月23日 (木)

「Inspired 入門」 (第1回)

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

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

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

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

話題から

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

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

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

Inspired より

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

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

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

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

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

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

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

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

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

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

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

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

[ 2月23日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.052718s / load averages: 0.46, 0.53, 0.52
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker