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