来年のプロジェクトのスケジュール/タスクを検討中。
先週末から GanttProject 1.0.3 を使ってちょこちょこ線表を書いて考えているのだが、まだこのソフト自体完成度が高くないのでいまいちタスク設定に集中できない。
(印刷以外において)これらの点で以前試した Project@Hand 2 が結構良かったのを思い出す。 もう一度インストールして試用してみる。
Palm OS 上での作業になるので画面は狭いものの表示が良くまとまっているので、小・中規模のプロジェクトなら十分。 前回の試用では使ってみなかったが、フィルター機能で指定したリソースだけ表示したりリソース未割り当てのタスクだけ表示だけできる。
プロジェクトのタスクのチェックに Progect も使ったりしているが、こちらはリソースの割り当て状況を確認するといった用途には向かない。
来年は Project@Hand 2 で行ってみるか。
ということでライセンス購入。$29.95 (USD) 也。
今後は
というコンビネーションで。
今年の大事件、マイブームなど。
入社して満3年。今年は随分仕事の内容が変わってきた。 トム・デマルコの本を読んでみたり。 事後評価セッションを実施してみたり。
DNS サーバ、メールサーバ、Web サーバを一斉入れ換え。Debian GNU/Linux に移行。 RAIDではまる。
RAIDまわりが何かよろしくないようだし、ホスト自体以前デスクトップとして使っていたPCなので安定したものに置き換えたい。
PEG-TJ25を購入し、Palm OS 生活復活。 最初はおもちゃのつもりで買ったのだが、プロジェクトマネジメントなどにシフトした仕事のスケジュール管理などで大活躍。
PDA 市場の明るい話はあまり聞かないが、末長く製品が出て続けて欲しい。
先月発表のあった給料アップの正式な通知が届いた。 貢献度を評価し算出したとの事なので、いわゆるベースアップだけではなくて査定昇給とセットになっているようである。
プロジェクトマネジメント的な役割などより責任のある仕事が増え、ここ数年いろいろ新しい手法を試行しつつやってきた。 その辺りを含めて評価してもらっているようなので、その点は満足である。
しかし好きなオモチャをガシガシ買えるようになるには、まだまだ満足のいく額とはいえない。 さて、今年はより攻撃的にしかけて組織をもりあげていきますかね。
会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。
社内にはコミットメントをコアにした管理手法もあり、 その優位性は十分に認めている。 しかし、単純にガンチャートがすきなのである。 特に見た目、がね。 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より
とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。
ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。
ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。
どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。
コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。
逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。
ソフトウェア開発で線を引いてみたときの感想
現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。
必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。
ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。
会社の後輩から問われた。
答えがあればこちらが知りたい。
プロジェクトマネージャーには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトプロジェクトマネージャーは答えの決まっていない問題の解決をしていかなければならないのだから。
もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が~~で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。
ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。
ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。
ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。
ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。
ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。
Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。
TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。
あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。
書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。
とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。
TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。
さながら Eclipse でコードを書いているような感じ。
下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。
ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。
GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。
面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。
あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。
ソフトウェアエンジニアには使いやすいツールだと思う。
マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。
マインドマップを書く時、最近は(といってもしばらく書いてないけど) iPad 用の iThoughtsHD を使ってる。直感的に使えるしエクスポート結果も綺麗だし、クラウド連携も良くできてる。
ただ難点があって iPad 2 が手元に無い時は使えない。PC だとたまに FreeMind とか使ってたけどちょっと表現や出力がモダンじゃなくて高まらないので、別のを探してみることにした。
XMind をチョイス。
Eclipse ベースなので見た目も綺麗だ。気にいった点はマトリクスが書けること。多次元マインドマップツールとまではいかないけれど、表が書けて、別のツリーからその表上のトピックに関連線をつけられる! ひゃっほー。こういう図が書きたかったのよという感じ。
フリーだと PDF 出力が無いのはちょっと惜しい。Gantt View も使える XMind Pro 2012 が気になるんだけれど $99 なんだよねぇ。ちょっと高い。でも PDF 出力のためだけに $79 の XMind Plus 2012 のライセンス買うのものなあ。しばらくはフリーで使い込んでみよう。
プロダクトオーナーやプロダクトマネージャー(PM)の必読書と言われているらしい「Inspired: 顧客の心を捉える製品の創り方」の内容を理解し、実践・共有することで力をつけていきましょうという「Inspired 入門」勉強会に参加してきました。今日が第1回。渋谷界隈でネットサービスを行っている4社から参加者が集まりました。
各社ネットサービスを展開していますが、お互いにビジネス領域が被らないためざっくばらんに話ができそうです。企業毎に組織体制や文化が異なり、プロダクトマネージャーの仕事・役割もそれぞれ違うよねということをあらためて感じました。取り組みや課題などをお互いに情報交換することで、いろいろ学びがありそうです。CS 部門経験者の方も何名かいて、ぐっと親近感がわきました。
今回は幹事役をしてくれた方が資料を用意してくださっていてそれを使いながらファシリテーションしてくれました。感謝。
ある方のところでは、ユーザーに影響のある施策についてはコンセプトシートを書くとおっしゃっていました。他の方はリーンキャンバスを作るようにしているとのこと。自分のチームではプロダクトバックログ上にストーリーを書いて済ませることも多いのですが、少し大きいサイズのものはこういったものを書いた方が良いなと今回感じました。
PM という役職・肩書のある会社はというお題については、ほとんどの方がないということでした。
それからユーザーストーリーマッピングを1日かけたという話をしてくれた方は「エンジニアも一緒に参加することで、作る側の納得感が出て良かった」とおっしゃってました。なるほどです。
今回は1章から3章がトピックだったので以下個人的なメモ。
第1部は「ソフトウェア製品の開発に関わる人たち」。人・プロセス・製品という3領域の中の「人」。その役割と責任について。
まずは役割の説明。プロダクトマネージャーのやることとして以下を挙げています。
プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。
プロダクトマーケティングも兼務になっていることが多々あるがまったく別の技能が必要なので、兼務は非常に難しいとしています。この点は第2章で詳しく取り上げられています。プロダクトマーケティングが分離されていると助かります。
プロダクトマネージャーは5〜10人のエンジニアに対して1人必要とのこと。スクラムチームの人数ともだいたい同じ規模感。
「プロダクトマネジメントとプロダクトマーケティングをそれぞれしっかり」「製品の最終責任者を明確に」「プロダクトマネジメントは専任で」
プロダクトマネージャーの役割とプロダクトマーケティングの役割をきちんと区別するのが大切。
ここではさらにプロダクトマネジメントとプロジェクトマネジメントを区別しましょうという話。
みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。
項目名を整理して決めておくと楽なのでちょっと書き出してみました。
比較的軽量にまとめる時。
プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。
ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。
スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。
ちょっとしたタスク。
他には以下のような形式もあります。
[ プロジェクトマネジメント ]
あるプロジェクトのプレイングマネージャーが抜けることになってから、プロジェクトがうまく進まなくなってきた。プレイングマネージャーがメインでやってしまっている間は良かったけれど、そうでなくなった今も週1回30分のミーティングのスタイルのままでスローダウンしてしまったように思える。
なので
クネビンフレームワークで言うところの「複雑な領域」のプロジェクトだから、もっと密接にチームメンバが連携して「検査と適応」をしていかないと、進まないし成果も出ないよね。
という話をした。
開発プロジェクトではないけれどスクラムがいいんじゃないかなと思っているので取り入れてみるつもり。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。 それとは別に nNote にもちょっとしたノートがあります。
※内容は個人的見解であり所属組織とは関係ありません。