タグ

マネジメントに関するkatzchangのブックマーク (11)

  • 迷ったら狩野さん!...狩野分析法による優先度付け - masayangの日記(ピスト通勤他

    追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか? まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件(フィーチャ)を開発していく」のが基だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的

    迷ったら狩野さん!...狩野分析法による優先度付け - masayangの日記(ピスト通勤他
    katzchang
    katzchang 2007/12/13
    全て1-5になる罠。でも、ある程度は捌けそう。
  • アメリカにはSIerなんて存在しない - GoTheDistance

    知人のmark-wadaさんのBlogからTB。 親子丼的ビジネス奮闘記(4) IT業界構造 SIerなんてものは無い 米国と日との大きな違いは、米国の企業は基的に内製なのだ。すなわち、社内のIT部門に開発エンジニアを抱え、そこでシステムの開発から運用を行なう。 ですから、米国のベンダーはそこに製品を供給する役割であり、日でいうSIerというのはほとんどなく、あっても企業でリソースが不足したらそれを補う役割でしかない。契約にしてもはっきりしますよね。提供されるプロダクトやサービスに対する対価を払えばよいわけで、かかった人月で支払ういう出来高払いのような形態は少ない。日のようにベンダーやSIerに丸投げして、できてからこんなはずではなかったなんて事態にははじめからならない構造なのだ。 親子丼的ビジネス奮闘記(4) IT業界構造 言われてみれば・・・、っていう感じですが改めて目が鱗です

    アメリカにはSIerなんて存在しない - GoTheDistance
    katzchang
    katzchang 2007/09/21
    外注化は機能単位ですると効果があるが、システムは1つの単独の機能ではなく、各機能をすべからく補助するものだから、外注化は難しい。ということかな。Code的に言うと、システムって経営方針そのものなんだよね。
  • 第2回 RFP作成には標準的な手順がある

    「始めよければ終わりよし」と言いますが,「最初の仕様があいまいなままプロジェクトを開始した」とか「簡単だと思って始めて深みにはまった」という失敗事例を,システム開発ではよく聞きます。これは,“プロジェクト開始の作法”が確立していないからではないでしょうか。 プラント建設のプロジェクトでは,“元請け”である「コントラクター(契約請負業者)」にとっての「プロジェクトの開始」は,オーナー(発注者)から「見積もり引合い書」が来た時です。この見積もり引合い書のことを,「RFP(Request for Proposal)」と呼びます(「RFQ(Request for Quotation)」や「ITB(Invitation to Bidders)」と呼ぶこともあります)。RFPの作成は,プラント建設では常識中の常識です。 RFPを作成する企業は,競争見積もりには参加しない プラント建設プロジェクトのRF

    第2回 RFP作成には標準的な手順がある
    katzchang
    katzchang 2007/09/18
    始めの契約の話。マネージャになりたくない人。なりたくない理由。システム開発は製造業よりは建設業よりなんだよなぁ。
  • メトリクスごっこ - @m_seki の

    最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 − @ITのモデル、おもしろいですね。1000人月の最適な工期は24ヶ月か。 投入人月から最適な工期が求まるとすると、最適な人数も求まるのかな。1000人月の最適な工期は24ヶ月なので41人くらいですよね。 ってことは、投入人数から最適な工期も求まるかもしれない。41人なら24ヶ月が最適な人数? RubyとKeynoteでグラフを描かせて、大人っぽくしてみよう。 工期から最適な人数を求めてみる。10年(120ヶ月)のプロジェクトがあるとは思えないけど。 20ヶ月だと30人、3年だと100人くらいが最適みたい。5年だと250人なり。 逆に人数から最適な工期を求める。1000人のプロジェクトがあるって噂を聴いたようなきがするので1000人まで。 50人では26ヶ月、100人では37ヶ月、1000人使うようなプロジェクトは10年くらいが

    メトリクスごっこ - @m_seki の
    katzchang
    katzchang 2007/07/10
    先のデータは実測値ベースの指標のなので120ヶ月とか1000人とかに適用できるとは限らない。が、こういうお遊びは大好きです。
  • プロジェクト・マネジメントにリーダーシップ論は要らない | タイム・コンサルタントの日誌から

    昨年、国内最大手のシステム・インテグレーターのPMOの方から依頼されて、そこの社内PMセミナーで講演する機会があった。どういう話をしようか、少し迷ったのだが、その冒頭で、私はこう切りだした。「プロマネを選ぶときに、リーダーシップの有無を最初に問題にするのはおかしいと思います。少なくとも、私の業界ではそういうことは議論になりません。」 ご承知の通り、私はエンジニアリング会社に勤務して、プラント系のプロジェクトとSI系のプロジェクトの両方を経験してきた。二足の草鞋をはき、両者を子細に比べてみて気づいたのは、技術的な要素が大きくちがうにもかかわらず、プロジェクト遂行のストラクチャーがずいぶん似ているということだ。いずれも受託型のビジネスである。スコープと納期とコストが主要なコントロール対象である。元請け-下請け構造で複数業者が関わっている。個別受注・個別設計である(とはいえ、客先の要件はじつは業

    プロジェクト・マネジメントにリーダーシップ論は要らない | タイム・コンサルタントの日誌から
    katzchang
    katzchang 2007/07/10
    マネージャに必要な能力について。リーダシップは危機管理対策。
  • 最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― @IT

    2007/07/05 日情報システム・ユーザー協会(JUAS)は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「(短

    katzchang
    katzchang 2007/07/06
    実績からの指標。
  • 「悪い報告がトップに即座に伝わっているか」,初代内閣安全保障室長の佐々氏が説く危機管理の基本

    「危機管理には“need to know原則”がある。情報は,知るべき人が知るという意味だ。知るべきでない人には知らせてはならない」---。初代内閣安全保障室長の佐々淳行氏は,セキュリティ・ベンダーのトレンドマイクロが7月3日から開催しているカンファレンス「DIRECTION 2007」の基調講演において,危機管理にとっては情報伝達ラインが極めて重要であるとの見解を示した。同氏の講演内容をまとめた。 企業組織は,課長や部長といった役職がピラミッドを形成している。長らく日の組織では,このピラミッド構造に沿って,情報の伝達が成されてきた。直属の上司への連絡を飛ばして,上司上司に当たる人へと情報を直接報告する行為は,組織においては厳禁とされてきた。 そもそも,良い報告であればピラミッド構造の情報伝達ラインに沿った形でも,何も心配することなく,すさまじい勢いで情報がトップへと伝わっていく。反対

    「悪い報告がトップに即座に伝わっているか」,初代内閣安全保障室長の佐々氏が説く危機管理の基本
    katzchang
    katzchang 2007/07/05
    Shoot The Messenger
  • iza:イザ!

    エラー内容 以下のいずれかの理由により、該当するコンテンツを表示することができませんでした。 コンテンツの公開が終了した。コンテンツが削除された。 指定したURLが間違っている。その他、やむをえない事情があった。 ご不便をお掛けして申し訳ございません。 何卒よろしくお願いいたします。 イザ! イザ!トップへ戻る

    katzchang
    katzchang 2007/07/05
    トラブル対処の一例
  • ブルックスの法則 - Wikipedia

    ブルックスの法則(ブルックスのほうそく)は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。 根拠[編集] ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる

    katzchang
    katzchang 2007/06/08
    問題全体を小規模のグループが担当できるサイズに分け、より上位のチームがシステムの統合を引き受けるというものだ。
  • JTPA: 私が米国の建設会社で働いている「長い」経緯

    « セミナー:Jobless Rate 8.5% 今企業が欲しがる人材 What's Hot, What's Not | Main | 「今企業が欲しがる人材 What’s Hot, What’s Not」アンケート結果 » 2003年08月12日 インタビュー , コラム : 私が米国の建設会社で働いている「長い」経緯 8年ほど前、日で設計事務所で勤務中、「コンストラクション・マネジメント」という言葉を聞きました。日には存在しない職能で、単語のとおり、建設を施主に代わって「マネジメント」するという仕事です。施主がコンストラクション・マネジメントを利用すると、建設費は下がり品質は向上され、工期も短縮されるとのこと。当時、日ではゼネコン絡みの汚職が問題になっており、USTR(US Trade Report)までもが日の建設費の高さを指摘する始末でした。どんなに誠実に設計をしても、設計

  • JINA -- Japanese IN America

    -- 小さい頃はどんな子供でしたか? 戸谷茂山さん 正直に申し上げてこれがよくわからないんですが…。自分ではおとなしかったと思うんですが、通信簿を見るとイタズラ好きと書いてあって先生に好かれるおとなしさではなかったみたいです。先生とは仲が悪かったというか相手にしていなかったので、先生に嫌われるおとなしさでしたね。ちょっと冷めた目で見ていたマセたガキだったんでしょうね。 -- 大学では建築を勉強されたそうですが、その理由は? 戸谷茂山さん これも難しいですね。日では高校の進路をまずどこの大学に入れるかというところから決めるじゃないですか?だから冗談みたいですが、進路相談の時に「オマエの成績だったら青山のフランス語科に行け」と言われたりしたんですね。それで進路を決めかねていたんですが、昔から割と絵が好きで美術に関係したことをやりたかったんです。でも芸術家になりたい気持ちはなかったので、芸術の

    katzchang
    katzchang 2007/05/21
    「日本でCMと呼んでいる人もいますが、あれはマネージメントではないですね。」が気になる。
  • 1