角待ちは対空」でした。最近はこんなことをしています。はてなダイアリー日記はてなダイアリー終了とブログへの統合、利用いただいているユーザーのみなさんへの影響も大きいですし、15年続いたサービスの終了とコンテンツの移転はプロジェクトとしても大きいものです。オープンなプロジェクト計画というわけで、わりと雑な僕でも本プロジェクトについては、利用していただいているユーザーの方にも、社内にも、チームメンバーにもプロジェクトの意義を説明できるように、プロジェクト計画書を作り、社内に公開し、さらにそれを作る過程も社内に公開しながら進めました。そこから得られた知見や気付きをブログにもまとめてみようと思い、本エントリを書いています。Knowledge)を参考にしました。Wikipedia15年続くはてなダイアリーは、社内外にステークホルダーも多く、十分な整理が必要と感じたので、より教科書的なアプローチを試み、それを社内に共有しよう、と思ったのでした。5個のプロセス群PMBOKはプロジェクトマネジメントの知識体系であり、扱う範囲は大きいです。具体的には以下の5つのプロセス群に大別されます。今回はひとまず、この1,2番目の「立ち上げ」「計画」両プロセス群について、PMBOKを参考に「プロジェクトマネジメント計画」を立てるということをしました。10の知識エリアまたPMBOKは各プロセスをマネジメントの対象により10のプロジェクトマネジメント知識エリアとして分類しています。プロジェクト統合マネジメントプロジェクト・スコープ・マネジメントプロジェクト・スケジュール・マネジメントプロジェクト・コスト・マネジメントプロジェクト品質マネジメントプロジェクト人的資源マネジメントプロジェクト・コミュニケーション・マネジメントプロジェクト・リスク・マネジメントプロジェクト調達マネジメントプロジェクト・ステークホルダー・マネジメントプロセス群と違い、知識エリアについては、全ての知識エリアについてプロジェクトの計画を行います。プロジェクトマネジメント計画書PMBOKに沿って、10個の知識エリアについて考えそれぞれについてのマネジメント計画を「プロジェクトマネジメント計画書」として作成しました。書いてみて思った、特に意識した知識エリアについてピックアップしてみます。プロジェクト統合マネジメント各プロセスを束ねるためのマネジメント、メタな感じですね。このエリアにおいて「プロジェクト憲章」を定め、プロジェクトに迷いが生じた時に立ち戻れるポリシーを定めることが大事です。実際のプロジェクトにおいて、日々の判断が必要であり、その判断の根拠となりうる、プロジェクトの価値観を明らかにすることは非常に大事だと思っています。リーダーが間違った判断をすることがあっても、価値観をチームで共有できていればメンバーから「それは違う」と言い出せます。いうチームが良いチームだと思います。プロジェクト・スコープ・マネジメントプロジェクトのスコープ、つまり何をするかを定義することは、逆に「何をやらないか」を定義することでもあります。定義が曖昧な時、しばしば起こるのは「作りすぎ」だと思っています。世の中はやれるならやった方がいい事に満ち溢れていますが、全部やってたら終わらないのです。プロジェクト品質マネジメント」があります。必要な品質を満たし、でも過剰品質とならないこと、を意識します。プロジェクト・リスク・マネジメントプロジェクトの想定されるリスクについてマネジメント計画を立てます。4タイプに分けて、想定されるリスクに対して対応戦略を考えます。しては「単純に工数をもってくる」とか、「軽減」対応として「ある程度の仕様について諦める」といった態度が考えられます。プロジェクト計画の段階で、リスクに対する対策を決めておくのは、実際にリスクが顕在化したときにスムーズな判断を助けてくれます(くれました)。プロジェクト・ステークホルダー・マネジメントプロジェクトに影響する人を特定しておき、マネジメント戦略を立てます。このプロジェクトでは「ユーザーさん」から社内の各部署まで、多数のステークホルダーを設定し、関係性を明確にしました。歴史のあるサービスは当然関係者も多く、何かの決定が思わぬ影響を及ぼしたりすることがままあり、ステークホルダーを整理しておくことで、連絡漏れとか思わぬ影響といった事故を未然に防ぎたいです。その他の知識エリアと、4つほど取り上げてみましたが、その他のエリアも重要ですので、軽視せずプロジェクト計画したいですね。プロジェクト憲章とインセプションデッキさて、プロジェクト憲章を作るに当たって、チームメンバーから「インセプションデッキを作ろう」という声が偶然タイミングよく出てきました。そこで、プロジェクトマネジメント計画書における「プロジェクト憲章」をインセプションデッキとすることにしてみました。インセプションデッキは「アジャイルサムライ」で紹介されたことでも有名な、プロジェクトの開始時に定義すべき10個の質問・回答集です。何がどれだけ必要なのかこれは、実際に立ててみたプロジェクトマネジメント計画書の項目とほぼ一致するものでした。「やらないことリスト」は「スコープ・マネジメント」、「プロジェクトコミュニティ」は「ステークホルダー・マネジメント」、「夜も眠れなくなるような問題」は「リスク・マネジメント」そのものですね。そもそも体系化されたプロジェクトマネジメント知識は、アジャイルな開発における計画においても有効であり、参考にされているものだということですね。ちなみに、PMBOK6版においてはアジャイルについての解説が強化されています。両方やって思ったことは、以下のようなことです。PMBOKにおける「プロジェクトマネジメント計画書」は、方法論がしっかりしていて、これに沿って書きやすい、と感じた。一方で扱うプロジェクトの範囲が、小さなものから大きなものまで幅広いため、資源やコストのマネジメントについては(今回は)オーバースペックに感じた「インセプションデッキ」は、要素としてはPM計画書とにているが「わかりやすく相手に伝えるツール」として優れていると感じたという意味で、今回両方を実際に書いてみてそれぞれの特徴を感じました。プロジェクト計画の共有とアップデートさて、プロジェクト計画において大事だと感じることは、その計画をちゃんとステークホルダーに共有すること、そして、計画を更新することだと思います。PMBOKはウォーターフォール型のプロジェクトもアジャイルなプロジェクトも扱います。計画段階においては、どちらも計画は大事です。計画を実行するにあたって両者に生じる違いは、手戻りが難しいウォーターフォールに比べて、アジャイルは定期的に振り返り、プロジェクト自体を改善していくことができることだと思います。その意味で、「精緻な計画を立ててそれを実施する」というのではなく、「書けるところからでも計画を書いてみる。それを定期的に振り返り、計画自体をアップデートする」ことがアジャイル開発においては特に大事だと考えます。今回のプロジェクトでは、四半期で計画の振り返りをし、大事に思っていたことが実現できたか、当初と想定が違い優先順が変わることはなかったか、ステークホルダーの見落としがなかったかといったことを確認し、文書をアップデートし、その内容についてチームメンバーから意見も求め、結果を共有しました。これは四半期と言わず毎月くらい実施しても良かったですね。まとめ計画を立てて、チームの意識を統一する、リスクへの対策を考えておくことは、プロジェクトが大きくなるほど大事ですが、小さいプロジェクトでも軽視せず、意識することが大事だと思います。インセプションデッキは必ず作る習慣をつける、とか。最後に、ブログ統合のプロジェクト憲章(インセプションデッキ)に掲げた文章を紹介します。はてなのコンテンツプラットフォームサービスの未来に向けた開発を行う近頃、複数のサービスの終了のニュースが続いていますが、ユーザーさんのコンテンツを扱う、コンテンツプラットフォームサービスは、はてなの柱であり、その未来に向けた開発をしていきたい、そのための準備としての整理のつもりです。今後のはてなにどうぞご期待ください。日)はてなスタッフの大西です。夢日記はてなブログをはじめよう!onishiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。