<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="../../../../../css/rss/feedRss1.xsl" media="screen" type="text/xsl"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xml:lang="ja">  
  <channel rdf:about="http://rssblog.ameba.jp/pmbok/rss.html"> 
    <title>わかりやすいプロジェクトマネジメント</title>  
    <link>http://ameblo.jp/pmbok/</link>  
    <description>プロジェクトマネジメントってそんなに難しいことなんでしょうかねぇ～？？</description>  
    <dc:language>ja-jp</dc:language>  
    <items> 
      <rdf:Seq> 
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10012474773.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10011905622.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10005694932.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10000371700.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10004464396.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10004435764.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10001765823.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10001340791.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10001260284.html"/>  
        <rdf:li rdf:resource="http://ameblo.jp/pmbok/entry-10001259557.html"/> 
      </rdf:Seq> 
    </items>  
    <atom:link xmlns:atom="http://www.w3.org/2005/Atom" rel="self" href="http://feedblog.ameba.jp/rss/ameblo/pmbok" type="application/rss+xml"/>
  </channel>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10012474773.html"> 
    <title>プロマネとナレッジマネジメント</title>  
    <link>http://ameblo.jp/pmbok/entry-10012474773.html</link>  
    <description><![CDATA[<p>プロジェクトにおいてナレッジの共有というのは非常に大事なこと。

そもそもPMBOKもプロジェクトマネジメントのナレッジを共有するために体系化されたモノです。


そのナレッジは大きく分けて二つに分類されます。




・暗黙知


個人が持っているナレッジで、このナレッジは共有されていない為に、そのナレッジを所有する個人によって利用されるナレッジである。




・形式知


少なくとも組織レベルで共有されるナレッジ。文書化されていたりするため、個人だけでなく組織レベルでの利用が可能なナレッジ
</p>]]></description>  
    <dc:date>2006-05-15T04:25:21+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10011905622.html"> 
    <title>モチベーションコントローリング</title>  
    <link>http://ameblo.jp/pmbok/entry-10011905622.html</link>  
    <description>久しぶりの更新となってしまいました。申し訳ありません。 これからはもう少し頑張ろうと思いますm(_ _)m プロジェクトマネジメントで大事な事はたくさんあります。その中で今回はモチベーションについて書いてみようと思います。 プロジェクトを遂行するにあたり、プロジェクトメンバーのモチベーションが高いか否かでそのプロジェクトの成功率は格段に変わります。 こんなプロジェクトやってられるかｺﾞﾗｧ (-_-ﾒ) とか、 どーせ上手くいかネェだろ ( ´△｀)ｱｧ- というメンバーばかりだった</description>  
    <dc:date>2006-04-29T03:06:43+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10005694932.html"> 
    <title>PMとしてWin-Winな関係を築く</title>  
    <link>http://ameblo.jp/pmbok/entry-10005694932.html</link>  
    <description>Project Managementをするにあたり、各関係部門との関係で、Win-Winな関係を築くことが重要です。 そのWin-Winの関係を築くにはどうしたらよいか??と言うことを考えなくてはなりません。 その考え方としては、「一つのリンゴを2人に均等に分けるにはどうすればよいか?」という問題を解くことで解決することができます。 PMとしては、どのような心構えでWin-Winな関係を築く必要があるのか・・・ それについて考えてみました。 詳細についてはこちらを参照下さい http://0</description>  
    <dc:date>2005-11-01T10:24:21+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10000371700.html"> 
    <title>PMBOK紐解き 目次 (9/21更新)</title>  
    <link>http://ameblo.jp/pmbok/entry-10000371700.html</link>  
    <description>01.プロジェクトマネジメント 02.はじめに　-PMBOKとは？？- 03.PMBOK 第一章　序論(1) -PMBOKの目的- 04.PMBOK 第一章　序論(2) -プロジェクトとは何か- 05.PMBOK 第一章　序論(3) -有期性・独自性・段階的詳細化- 06.PMBOK 第一章　序論(4) -プロジェクトマネジメントとは- 07.PMBOK 第一章　序論(5) -他のマネジメント分野との関係、関連業務- 08.PMBOK 第二章 2.1 -プロジェクトフ</description>  
    <dc:date>2005-09-21T10:11:06+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10004464396.html"> 
    <title>PMBOK 第二章　2.1.1 -プロジェクト・フェーズの特性-</title>  
    <link>http://ameblo.jp/pmbok/entry-10004464396.html</link>  
    <description>ということで、プロジェクトはいくつかのプロジェクトに分けてマネジメントする必要があるのですが、 いったい、どうやって分けるといいの?? という疑問が出てきます。ただ闇雲にフェーズ分けをするのでは当然だめです。 ではどうしたらいいのでしょう? プロジェクトを進めていけば、なんかしらのものを作ることになるでしょう。例えば、システム開発においては要件定義書や内部設計書。製造においては、設計図面や試作品などのことを言います。 これら、作られたもののことを要素成果物と言い、これら要素成果物の完了を持っ</description>  
    <dc:date>2005-09-21T09:51:40+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10004435764.html"> 
    <title>PMBOK 第二章　2.1 -プロジェクトフェーズとプロジェクトライフサイクル-</title>  
    <link>http://ameblo.jp/pmbok/entry-10004435764.html</link>  
    <description>さて、久しぶりに紐解き再開です。今日より二章をを開始します(お待たせしました)。 2.1節　プロジェクトフェーズとプロジェクトライフサイクル プロジェクトという業務は独自性があり、ある程度不確実性を伴うことは今まで説明してきた通りです。つまり、 プロジェクトでやっている業務は初めての内容で、成功するかどうかなんてわかりゃぁしない!! というモノなのです。 もちろん、プロジェクトに関わっている人は失敗するつもりで取り組んでいるわけではなく、少なくとも成功するために努力しているわけです。 だ</description>  
    <dc:date>2005-09-20T11:09:31+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10001765823.html"> 
    <title>複数のプロジェクト</title>  
    <link>http://ameblo.jp/pmbok/entry-10001765823.html</link>  
    <description>プロジェクトマネジメントを行う上で、プロマネが実施するプロジェクトは1名につき1プロジェクトというのが理想的です。 しかし、現実的にはプロマネが1つのプロジェクトだけに参画している例は少ないと思います。 私はいわゆるITスタッフと呼ばれる、企業の中のシステム開発部門に所属しています。 昔は情報システム部門と呼ばれ、自分達でプログラムを書きシステムを開発するという業務内容でしたが、近年はプログラミング等はパートナーさんに任せ、プロジェクトをマネジメントすることが業務となっております。いわゆる、社</description>  
    <dc:date>2005-05-12T11:57:54+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10001340791.html"> 
    <title>お詫び</title>  
    <link>http://ameblo.jp/pmbok/entry-10001340791.html</link>  
    <description>4月末から約1ヶ月ちょっとこのブログを更新しておりませんでした。 転職先の会社で1年が経過したのと、昇進(たいした昇進ではないです)があったため業務内容が少し変わり、忙しくなっていたのでサボっていました。 激励のメールや、催促のメールをいただきありがとうございました。おかげで、やる気になり更新を開始します。 今後は、皆さんがもっと楽しんでいただけるよう、毎日とは言わず、1週間に一回は更新できるように努力するつもりです。 今後もよろしくお願いします!!!</description>  
    <dc:date>2005-05-12T11:52:35+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10001260284.html"> 
    <title>4月は異動の季節</title>  
    <link>http://ameblo.jp/pmbok/entry-10001260284.html</link>  
    <description>4月は異動の季節ですね。私の回りでも異動する人が多いです。 ・あるプロジェクトの旗振り役の部長級の方が異動 ・あるプロジェクトのマネージャーが異動 ・あるプロジェクトの現場を引っ張っていた方が異動 おいおい、この「あるプロジェクト」はどうなるんぢゃい?? といった状況になりました。 本来であれば、プロジェクトのコアメンバーはプロジェクトが完了した時点で外れるのが理想。 しかし、企業の辛いところはプロジェクト人事と社内人事がリンクしていないこと。 昔からの企業はプロジェクトに対する考え方がま</description>  
    <dc:date>2005-03-24T11:08:38+09:00</dc:date> 
  </item>  
  <item rdf:about="http://ameblo.jp/pmbok/entry-10001259557.html"> 
    <title>ゼロベース思考</title>  
    <link>http://ameblo.jp/pmbok/entry-10001259557.html</link>  
    <description>昨日から、「問題解決プロフェッショナル」という本を再読しています。 これは、4年くらい前に購入した本。それ以来、一度も開けていません。 これくらい期間が空いていると、読んで理解する部分も異なるかもしれないと思い、また読むことにしました。 さて、ここの一章に書いてある内容なのですが、「ゼロベース思考」というものがあります。結構大事なことなので、ここにメモりたいと思います。 ゼロベース思考とは、 「既成の枠を取り外して考えるということ」 です。なーんだ、そんなことか、と思う人も多いと思います。</description>  
    <dc:date>2005-03-22T11:23:10+09:00</dc:date> 
  </item> 
</rdf:RDF>
