nDiki : プロジェクトマネージャー

プロジェクトマネージャー (project manager)

2004年10月25日 (月)

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

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

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

(熊とワルツを p.15)

新幹線の中で読む。

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

[ プロジェクトマネージャー ]

スポンサード リンク
[ 10月25日全て ]

2005年6月15日 (水)

すごい会議」と問題解決のスコープ

前回は松下君と2人で。 2人だとホワイトボード1枚で書ききれて、ある程度手書きでノートできる範囲。 3人を越えると厳しくなってくる印象。

今日は別のプロジェクトで、体調不良のプロジェクトマネージャーと飛び入り総務部スタッフ。 2時間で「いま直面している問題はなにか?」+「コミットメント・リスト作成」まで。 過去3回と同じ進み具合。

若手出席者中心で適用してみた今までとは違い、今回は「いま、うまくいっていることはなにか?」「達成したいことはなにか?」「この会議で、達成したいことはなにか?」はサクサク進んでいく。 この辺りは年の功か。

この方法でミーティングを進めていくと核心をついた問題解決に辿りつけるのだが、スコープが大きくなりすぎるきらいがある。 プロジェクトの範囲を越えて、組織の体制のプロセスの改善まで包含してしまうものもしばしば。

裏を返せばそこから改善しないと適切な問題解決にならないということで、それを実行すれば効果も大きい。普段なおざりになっている部分も出てくるし。

しかしながら労力とコストも結構なものになるので、どの程度までやっていくかのバランスが難しいところだ。

[ 6月15日全て ]

2005年10月19日 (水)

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

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

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

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

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

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

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

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

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

モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

[ 10月19日全て ]

2006年11月22日 (水)

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

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

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

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

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

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

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

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

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

[ 11月22日全て ]

2007年6月3日 (日)

コンサルタントの秘密」

コンサルタントの秘密

いわゆる情報系の仕事をしている人で、プログラマからアーキテクトやプロジェクトマネージャーを経て、コンサルタントへというキャリアプランを持っている人は少なくないと思う。 また特にそう考えていなくても、気がつけばやっている仕事がそのような流れでシフトしていると感じている人も多いのではないか。

また明確に「コンサルタント」を目指していなくても、結局のところ計算機屋の仕事には多かれ少なかれはコンサルティングの要素が含まれている場合がほとんどであろう。

本書はG・M・ワインバーグ氏による、コンサルタントに関する有名な本である。日本語訳の本書が出たのは1990年なのでもう定番書の域に入っている本だ。 コンサルティングを行う上で、理解していなければならない要素が沢山つまっている。

文章はシニカルで、単純なハウツー本とは違う。読者がよく考えながら言わんとしているところを読み取り、会得する必要がある。

随所に書かれている法則につけられている法則名がワインバーグ氏の体験にもとづく名前で他の人(私)には覚えにくいのと、訳が直訳気味のせいかすらすらと読めなかったという点はあるものの、書かれていることは非常に核心をついたものばかりである。

コンサルタント」「コンサルティングをする人」「コンサルティングっぽいことをちょっとでもする人」は読んでおいて損のない1冊である。


[ 読書ノート ] [ お薦めの本 ]

[ 6月3日全て ]

2008年6月23日 (月)

Task CoachGTD

今月の頭あたりから仕事関係の GTD プロジェクトを手帳から Task Coach に移して GTD を運用していた。

手帳から Task Coach にした理由だ。

RTM で済ませられればそれでいいのだが、RTM はサブタスクツリーが作れないのが致命的につらい。

プロジェクトリスト

Task Coach 上のタスク・サブタスクを使って、プロジェクト・サブプロジェクト・次の行動とブレイクダウン。

次の行動リスト

次の行動用に「Action」というカテゴリを作っておき、Task list view を Action カテゴリでフィルタリングすることで、次の行動リストが得られる。 その状態で HTML エクスポートして Web ブラウザ印刷すれば、次の行動リストシートができる。

完了予定日

完了予定日を設定することで、タスクリスト・タスクツリーを日付順にソートできる。 期限のあるプロジェクト・アクションをを優先的にレビュー・実行していくことができる。

総評

ということで2週間ちょっとやってみた。 その後 ThinkingRock に出会ってしまったため、移行してしまうことにした。

やはり GTD 用にデザインされたツールの方が、一般用のタスク管理ツールよりも運用しやすいことを実感。

[ 6月23日全て ]

2008年8月14日 (木)

Joel on Software - 必読書

Joen on Software

スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。

ソフトウェアプロジェクトマネージャーソフトウェア開発者必読書の1つだね。

扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。

3章 ジョエルテスト

3分でできるソフトウェアチームの良さを評価する有名なテスト。

5章 やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?

仕様書の最も重要な役割はプログラムをデザインすることだ。p.51

仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。

6章 やさしい機能仕様 パート2: 仕様書とはどんなものか?

サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。

8章 やさしい機能仕様 パート4: ヒント

そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79

これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。

ルール5: テンプレートは有害である p.86

9章 やさしいソフトウェアスケジュール

ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。

「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」

あたりが参考になる。なおこの記事は Webアップデートされている。

12章 5つの世界

開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。

14章 アーキテクチャ宇宙飛行士たちに脅かされるな

抽象化ばかり考えて意味のないところまでいかないこと。

21章 報奨金有害論

つい最近うちの会社でも表彰式があったばかりなんだけれども……。

マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188

多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189

23章 人のタスク切り替えは有害であると考えられる

一つのプロジェクトに専念したいね。

人々に同時に1つより多くの作業をさせるべきではない。p.202

24章 あなたが絶対すべきでないこと PART I

スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

25章 氷山の秘密、明らかに

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210

これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。

31章 下っ端でも何かを成し遂げる方法

多くの人は自分が下っ端だと思ってモンモンとしている。

  • 戦略1 実行あるのみ
  • 戦略2 じわじわ広めていく
  • 戦略3 優れた人間を作り出す
  • 戦略4 間抜けを無力化する
  • 戦略5 邪魔を避ける
  • 戦略6 かげがえのない存在になる

まずは不満を持つだけでなくて、個人ででも実行しようということ。

[ 読書ノート ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ] [ マネージャー ]

[ 8月14日全て ]

2017年1月31日 (火)

第13回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

  • チームを編成する
  • チームを育てる
  • 環境を合わせてなじませる
  • 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

[ 1月31日全て ]

2017年2月17日 (金)

Developers Summit 2017 2日目 #devsumi

今年は「人工知能とは」「機械学習とは」を繰り返し聞きました。

10:00~10:45 【17-B-1】 きゅうり農家から保険会社まで、機械学習を「民主化」するTensorFlow

グーグル株式会社 佐藤一憲(@kazunori_279)氏

  • 「テンサーフロー(発音)」
  • ニューラルネットワークでチーターを見つけられるかも?
  • Google 検索: RankBrain

わかりやすくわくわくする発表でした。簡単に出来ちゃうと感じさせるトークでしたが、製品に適用していくには泥臭いトライアンドエラーとリリース後の保守が待っているのだなあというのも想像しながら聞いてました。

ハードウェアの話を聞いていると、もはや超大手の手のひらの上で学習させていくしかないのかなーと感じさせられちゃいます。

11:05~11:50 【17-C-2】 教育、医療、もの書き市場で戦うプロダクトマネージャーの考え方 ~訴求ファーストとこだわり駆動開発とは?~

株式会社ジャストシステム 宮崎哲哉(@miya2tetsu)氏 大島教雄氏 岡美香氏

  • プロジェクトは「訴求ファースト」
  • スマイルゼミ。企画の話。訴求シート。あまり驚きのない内容。
  • JUST DWH。訴求シート。
  • 一太郎。ユーザー調査をしっかりやったという話。

自社製品の訴求セッション。デブサミじゃなくてもという感じではありました。

12:10~12:40 【17-A-L】 ママセキュリティエンジニア奮闘記 ~ 子供と一緒にラズパイで遊んでみた♪ ~

ソニーデジタルネットワークアプリケーションズ株式会社 吉田万里子氏

エンジニアとしての思いと親としての思いを叶えるためにラズパイで遊んでみるという話。子供の成長についていろいろ考えていらっしゃって素敵だなと感じました。

後半にだんだん技術的に具体的な話にきちんともっていく構成も上手いなと。

13:05~13:50 【17-D-3】 リーンスタートアップとスマートなエンジニアリングの葛藤

グロースエクスパートナーズ株式会社 関満徳(@fullvirtue)氏

  • プロダクトマネージャープロジェクトマネージャーの分業化。
  • 日本的プロダクトオーナー(幅広い業務範囲)
  • リーンから見た葛藤。リーンのサイクルとスクラムのサイクル。
  • オポチュニティバックログ。
  • Done の定義は最近は「ストーリーテスト」。
  • スプリントに入れないようなタスクのためのかんばんを作る。ToDo/Ready/In Progress/Done/Feedback
  • そのかんばんをどれくらい捌いていくか(FAQ)。→ 経験則で。アジャイルだから学習していく。リリース日を含むスプリントはかんばんの方多め、そうでなければプロダクトバックログの方多めがやりやすい。

準備完了なプロダクトバックログアイテムを準備完了にしていくためのサイクルやタスクをどうするかなと思っていたので参考になるかもしれないなと思いました。複雑になるので今のチームの状態でやるべきかは見極める必要がありそうですけれど。

14:10~14:55 【17-A-4】 C#で簡単にモバイルアプリを作ろう!

日本マイクロソフト株式会社 千代田まどか(@chomado)氏

一つ前のセッションを見終えてからいったらもう満席でした。

15:15~16:00 【17-C-5】 コミュニティとエンジニアの生き方

TickleCode 代表 小林由憲(@yoshiii514)氏 関西Javaエンジニアの会 阪田浩一(@jyukutyo)氏

勉強会コミュニティの始まりと成長。」

勉強会の話。

「Javaコミュニティを作ったら人生変わった」

「運営に関わろう、なければ作ろう」

なりたい人に近づくといいよという話と、貢献しなよという話。

16:20~17:05 【17-B-6】 インテリジェンスで挑むサイバー攻撃の最前線

株式会社インターネットイニシアティブ 穴吹健一氏

  • 今後はリアルタイムモニタリングとインシデント発生時の迅速な対応、リスク管理、ユーザの教育。
  • カラオケでのレコメンド(セキュリティ?)。
  • IIJ の情報分析基盤。Hadoop とか Zeppelin とか。
  • IP(アドレス)のレピュテーション情報の生成。

最後は IIJ のセキュリティビジネスの話に落ち着いて終了。さすが IIJ 的な内容のトークはあまり無かったです。

17:25~18:25 【17-E-7】 すべてのIT屋は全力で反省しろ!『ITは本当に世界をより良くするのか?』発刊記念トーク

株式会社ワークスアプリケーションズ 井上誠一郎氏 株式会社ノーチラス・テクノロジーズ 神林飛志 株式会社セゾン情報システムズ 小野和俊氏

お互いにレスペクト感があるなかでの軽快な対談を楽しみました。

[ 2月17日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

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

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

follow us in feedly

月別インデックス
Process Time: 0.093647s / load averages: 0.28, 0.32, 0.49
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker