はじめまして

はじめまして、サービス戦略企画室の原 美恵と申します。
2015年3月に入社して、とあるプロジェクトのPM（プロジェクトマネージャ）を担当しています。
私がITインフラ業界に足を踏み入れたのは2011年のことです。奇しくも、AWSが日本リージョンを開設し、東日本大震災が発生した年でした。それ以降、あらゆるクラウドサービスが急速に普及し、大変な過当競争にあります。今や非常にタフな市場となりましたが、それでも、私たち（このブログを読んでいるエンジニアのあなたも含めて）は、プロジェクトを立ち上げ、日々変化するニーズに対してプロダクトを届けなくてはなりません。
プロダクトに対する要件は常に変化し、放っておくと無限に増え続けてしまいます。要件が多くなれば、必要な時間とお金はあっという間に膨れ上がります。こうなるともう手が付けられません。いわゆる「炎上」です。プロジェクトが炎上しないよう、世のPMは常に「要求」と対峙することとなります。これが「PMはしんどい」と言われる原因です。でも、本当にプロジェクトマネジメントはしんどいだけなのでしょうか。(しんどいことは事実だけども！)
プロジェクトの関係者は皆、顧客が喜ぶものを届けたいはずです。では、顧客が喜ぶものとは、具体的にはどんなものなのでしょうか。
我ながら難しいテーマだと思うのですが、今日はここで頭を抱えなくても大丈夫です。この課題は毎日誰もが取り組んでいて、ちゃんとプロダクトは届けられているからです。にわかには信じられないかもしれませんが、騙されたと思って、夕飯の準備を始めましょう！
 

「きのう何食べた？」

昨日の夕飯は何を食べましたか？
家族が作ってくれたおいしい料理、自分で手早く作った料理、忙しくてコンビニのお弁当で済ませた方もいるかと思います。我が家は夫と私の2人暮らしで、夕飯はおもに私が作っています。つまり、私は毎日、夫が帰宅するまでに（納期）、食費（予算）を気にしつつ、好みや栄養バランス（要件）に合わせて夕飯（プロダクト）を作っているわけです。これって、プロジェクトマネジメントそのものですよね。食事とは非常に小さなプロジェクトであり、調理とはプロジェクトマネジメントの実践に他ならないのです。
 

「PM、キッチンに立つ！！」

エプロンを身に着けたら、調理を始める前に確認しておくことがあります。
すなわち、

1. 誰のために
2. いつまでに
3. なぜ作るのか

この3点です。

• 誰のために
  これは当然、料理を食べてくれる人（顧客）です。どんな人が何人、食卓を囲むか。言い換えれば、どんな人がそのプロダクトで喜んでくれるのか。我が家はたいてい夫と私の2人ですが、ご家庭によっては友人や親戚を招くことがあるかもしれません。ゲストの年齢、食の好み、生活習慣など(ペルソナ)を把握しておくと良いでしょう。
• いつまでに
  家族の帰宅時間を把握し、絶妙なタイミングで料理を提供できるようにしておきます。納期は否が応でも気になるものですね。
• なぜ作るのか
  実はこれが一番重要です。手作りの夕飯で、どんな食事シーンを実現したいでしょうか。賑やかな飲み会、栄養バランスのとれた食生活、お祝い事など、その食卓で成し遂げたい内容をしっかりイメージしておくことが重要です。

この3つは、プロジェクト立ち上げの段階でメンバーと必ず共通認識を持っておかなくてはなりません。プロジェクト憲章やインセプションデッキの内容に相当しますが、どんな形式でも構いませんので、メンバー全員がプロジェクトの全体像を理解できるようにしましょう。ここがPMの腕の見せ所です。
 

「すべてが献立になる」

さて、そろそろ献立を考えましょう。
調理を一度でもしたことがあれば、献立を決めることの難しさがわかるかと思います。一緒に食事をする人の数だけ好き嫌いがありますし、栄養や食費も気になるところです。また、気温や時間によっても献立は変わります。さらに困るのが、「今日は何が食べたいですか？」と聞いても、たいていの場合、「何でもいい」とか「おいしいもの！」とかそんな回答しか得られないことです。とはいえ、どうにかして要望をまとめ、どのような料理(プロダクト)を作るのかを決めなくてはいけません。この献立作りこそ、食事における要件定義にあたります。
私が献立に困ったときは、下の図のようなマトリクス（献立マップ）を思い浮かべるようにしています。

この図では横軸に料理の種類が示されていて、食事が左から右へ進むことを示しています。青い四角（カード）には、料理に対する要望を書き込んでいきます。要望は以下のひな型に沿って、端的に書きましょう。

たとえば、こんな感じです。

この段階ではまだ具体的な料理名を記入してはいけません。また、どう作るかという議論ではなく、誰がどんな料理を食べたいか、という観点が重要です。要望はいくつあっても構いません。書けるだけどんどん書きましょう。要望が増えてきたら、今度は優先度順に上下を並び替えていきましょう。（優先度の高いものほど上方になるようにしましょう）
出来上がりはこんな感じになるはずです。なんとなく食べたい料理のイメージがまとまってきました。

ところで、この記事の初めに、私は「PMは様々な要求と対峙する」といいました。そして、それは結構しんどいと。
では、献立マップを振り返ってみましょう。どうですか、様々な要求が整然と並んでいると思いませんか？青いカードには食材、温度、栄養、調理時間など多様な要望が書かれており、マップ全体で「だれが」「何を望んでいる」のかが網羅的に示されています。優先度も一目瞭然ですね。さらに良いことに、左から右へ食事の流れがあることです。例えば、前菜に「牛肉を使う」という要望があり、主菜にも「豚肉を使う」という要望が記載されていたとします。左から右に向かって視線を動かせば、肉料理が多すぎるということが容易に想像できますよね。あれこれと難しいことを考えずとも、献立マップは要望を整理し、食事の全体像(シーン)を具体的に描き出してくれるものなのです。
献立マップは、実はアジャイル開発において「ユーザーストーリーマッピング」と呼ばれるもので、プロダクトバックログ(要件)を書き出すためにしばしば用いられる手法です。ユーザーストーリーマッピングはシンプルでありながら非常に奥深いので、ぜひ関連書籍をご一読いただければと思います。(私のおすすめは、O’Reilly社 Jeff Patton著『ユーザーストーリーマッピング』です)
実際のプロジェクト現場でも、ホワイトボードにユーザーのアクティビティを左から右にむかって書き(Narrative Flowといいます)、その下に要望(ユーザーストーリー)を並べていきます。ユーザーストーリーは以下のように書かれることが多いです。

要件の根拠も書き添えることで、そのストーリーを書いた人にいちいち理由を尋ねる手間を省くことができます。

ユーザーストーリーはポストイットに書きます。もしストーリーが増えたり、減ったり、変更があっても貼り直せるからです。そして、ストーリーそれぞれについて、プロジェクト関係者とたくさん議論を交わしましょう。モレがないか、流れが破たんしていないか、リスクはどうだろうか、何より、顧客が望むシーンを実現できるかどうか。議論の時間は規模によりますが、一通り書き出すのに半日から丸々2週間かけることもあります。メンバー全員の参加が必須です。

話を夕食に戻しましょう。
献立マップから、次のような献立にしてみました。いい感じです。

• おつまみ　レタスのナムル　（お酒に合う簡単おつまみです）
• 汁物　　　 かきたまスープ　（卵を使った薄味の温かいスープです）
• 主菜　　　 プルコギ　（お肉も野菜もたっぷりの主菜）
• デザート　柿のヨーグルト和え　（ビタミンCを多く含む柿をデザートに。低カロリー）

「我々の間には定例会や議事録は存在せん。有るとすればSlackで生じる会話だけだ」

定例会が必要だなんて思っていた時期が私にもありました…。でも実際は全く必要ありません。少なくとも、わたしが担当しているプロジェクトでは定例会が行われたことは一度もありません。最初にキックオフミーティングを開き、その後は30分ほどの打ち合わせを2回行っただけです。それ以外のすべての会話は社内チャットSlackで行われています。
前段でも書きましたが、プロジェクトにはメンバー間の共通認識が必要不可欠です。そのためには、会話と情報公開が行われなければなりません。しかし、悲しいかな、定例会ではどちらも叶えることはできません。なぜなら、定例会で活発な議論が行われることは滅多にありませんし、欠席者がいれば大抵、その人へ情報が行き届かないからです。一方、Slackならば何時でもメンバーと議論ができます。議事録は不要です。過去レスを見れば何についての議論なのかすぐにわかるからです。(気になることがあれば、ホワイトボードにユーザーストーリーを加えておけばいいだけです)
Slackについては、弊社テックブログにも関連記事がありますので、ぜひご覧ください。
・slackの操作系Tips10選 -前編-
・slackの操作系Tips10選 -後編-

「そんなの絶対おかしいよ！」

「ユーザーストーリー」という言葉でちょっと風呂敷を広げてみましたが、献立を考えるなんて誰もが（スマホを使えない私の母ですら）毎日やっていることです。にもかかわらず、要件定義をサービス開発で行うと途端に迷宮入りしてしまいます。何故でしょうか。
ここは議論の余地が大いにありますが、私としては全体像の共有ができていないということが大きな原因だと考えています。サービスやソフトウェアは目に見えないがために、「どんな技術で」「どんなツールで」というような、画面や技術の話をしてしまいがちです。夕飯作りで考えてみれば、これがいかに奇妙か、すぐにわかるはずです。「いちょう切りがしたいから味噌汁を作ろう」とか「泡立て器を使いたいからクリスマスケーキを作ろう、ついでに何か祝っておこう」なんて、考えないですよね。（考えることがあったとしても、それが理想の食卓には結びつくはずがありません）

「こういうのでいいんだよ、こういうので」

アメリカのeBay社で製品企画担当を務めたマーティ・ケーガンは「価値があり、使いやすくて、実現可能な製品を見極めなければならない」と言っています。この発言は全く正しいのですが、これを満たす全機能を最初から提供する“完璧なリリース”は相当難しいです。夕飯づくりもまた然り。毎日、毎食を完璧な食卓にすることはまず不可能です。(共働きならば尚更)

こんな日もあれば

こんな日もある

では、要求に対してどのくらい応えれば十分と言えるのでしょうか。これもまた難しいテーマなのですが、私としては、顧客が「こういうのでいいんだよ、こういうので」と言ってくれるところまでだと考えています。最初にイメージした食事風景と比べて全く違う料理では困りますが、最低1つの目的が達成できていれば、まあ「こういうのでいいんだよ」と思えるのではないでしょうか
ごちそうさま、と食事を終えたとき、はじめて今日叶えられなかったユーザーストーリーに気付くはずです。でもがっかりしないでください。明日もきっと夕食をとるでしょう。今日実現できなかったことは、次のリリース(翌日の夕食)でがんばればOKです。
プロダクトは少しずつ磨かれるものです。今は「これでいい」と言われたとしても、いつか「このプロダクトがいい。これじゃなきゃダメなんだ」と言われるようになったら、それはPM冥利に尽きるというものです。そんな日がくるよう、これからも精進していきたいと思います。