プロジェクトマネジメントをアプリの開発ベンチャーで7年ほど経験して、必要だと感じたこと、実践してきたことをまとめおこうと思います。
Contents
1:プロジェクトマネジメント（PM）で一番大事なことは、クライアントと認識をすり合わせること
一言で言えば、これに尽きると思います。
クライアントと認識があっていれば、ある意味どんなアウトプットでも問題ないと言えます。なぜなら「そういうものが出来上がる」とクライアントと認識が合っているので、成果報酬と成果物はイコールの関係で成り立つためです。クライアントと問題になるのは「なんか違うんだよなぁ」と思われること、成果報酬に対して成果物がノットイコールになってしまった場合に問題が発生します。クライアントが自身で作る代わりに我々が作っている、という姿勢を忘れてはいけません。
しかし、結婚もうまくいかないように人と認識を合わせることは至難の技です。人は一人ひとり違っていて、頭の中を見ることができないので、人と人とが100%分かり合えることはまず不可能です。ですので、成果物をなるべくイメージしてもらえるよう、あれこれの努力やテクニックを行って、クライアントの要望を満たすのです。
ここまでで理解できた方は、ここで読むことを終えて実務に戻ってよいと思います。以降はそのために行うこと、行うべきでないことを五月雨式ですが記載します。
※ただし…
クライアントワークである以上、第一条件のクライアントの要望を満たすことが最大の優先順位ですしかし、2番目の優先順位はもちろん世の中の役に立つものを作ることです。
クライアントの要望通りに作った場合、もう一つ上の要望（例えばサービスの継続性であったり、売上向上であったり）が満たせない場合は、クライアントには提案すべきですし、役に立つものを作れるよう誘導や啓蒙をすべきだと思います。それが、作るものとしての良心であり、より質の高い仕事をするための心構えだと思います。逆にそうしないと、仕事はおそらく続かないし、信頼は築けないと思います。
クライアントの言った通りに作ったのに、と不満を言うようでは3流で、本当に求めていることを汲み取って実現できる成果物を作るのが1流の仕事だと考えます。
ということを補足で記載させていただきます。
1-1:クライアントが本当に求めていることを探る
一番大事なのはコレです。最初の「クライアントと認識をすり合わせること」とほぼ同義です。
クライアントが本当に求めていることを把握しないと、クライアントと認識が合うことはありません。何を目的としているのか、その背景を明確にしないと本当に作るものがこれでよいのか、正解がわかりません。これを無しに要件だけで具体化した場合には「なんか違う…」とか「確かにできたけど、思った成果が出ない…」といった不満に、高確率につながります。
これを避けるために行っていたことが
・形にしたものをひとまずぶつけてみる
・ワークショップを開いてみて、ともにアイデアを考えることで本心を探る
・ブレスト的な会議を開いて、求められている本質を浮き彫りにする
という方法です。
「言われたままではなく、お客さんと一緒になって作る」というスタンス、同じ目的を目指す仲間（チーム）です、という関係の築き方が、最もよい関係で仕事ができると思います。
これができれば、信頼も得ることができて心配なことはなくなると思います。その一方で、一番重要だから難しい…
これ以降はさらに具体的な戦術です。
1-2:プロジェクトの成功の基準を定義する
クライアントが本当に求めていることを探ることで、プロジェクトの成功の基準というものが自ずと定まります。単純に要件通りのものを作ればいいのか、作ったもので実現したい未来があるのか。未来を担保することはできないので、実現したい未来を目指すために、こういう風にしましょう、という結論になります。目指す未来があることで、サービスを具体化する時に方針を最適化できます。与えられた要件でよいのかの材料となりますので、ひとつ先の逆提案が可能になります。もしクライアント側にエンジニアがいない場合、エンジニア視点でより良い形があることが多いので、この逆提案はあることが普通だと思います。私は「この要件ではダメです」と、かなり逆提案する方でした。言われたまま作るより、その方が楽しいと思います。
1-3:期待値をコントロールする
クライアントが本当に求めていることを把握して、プロジェクトの成功を定義したら、次の肝は期待値をコントロールすることだと思います。すごく簡単なところで説明しますと、例えば「ここまでやれます！」と約束した後に「やっぱりダメでした」となると、相手はがっかりしますよね？なので「ここまではできますが、ここ以上は努力目標とさせてください」とリスクヘッジをする感じです。期待を上げた後に下げるとがっかりして信頼を失う一方、下げすぎると不信感を抱くので「上げすぎず、下げすぎず」で、コントロールします。これを各所で行います。
例えば、スケジュールは当然妥当な線を引きますが、頑張って前倒ししました！という形で対応すれば好感度は上がると思いますし、成果物についても「努力目標だったこの部分について、頑張って対応しました」と言えば、相手は人間ですので多少は情に訴えることができると思います。
簡単に一言で言うと「誠意を持って接する」と言い換えることができると思います。確証の持てないことはできると言い切るべきではないし、よりよいプロジェクトにするために最大のパフォーマンスを出す、ということです。一方でやりすぎれば「何も言わなくてもやってくれるし、タダでどこまでもやってくれる」と期待値が上がり勘違いされてしまいますので注意が必要です。「ここまではサービスできますが、これ以上は費用をください、もっと時間をください」と、事情を説明することも誠意です。「誠意を持って接する」と言うと、何でもサービスする方向に考えがちなので、やはり「期待値をコントロールする」という言葉が一番適切だとこの文章を書いていても思います。
1-4:資料を作る
これはかなり基本に立ち戻りました。
なんでも資料にして共有するとクライアントの信頼度が上がります。議事録を送る、電話で話した内容は最低でもメールで折り返す、打ち合わせには何らかの資料を必ず持参する、といったことです。資料にまとめることで、クライアントも自身の考えがまとまったりするので、資料にしておくのは手間をかけてでも行うことをおすすめします。
1-5:課題管理表を作る
これは必須ではないですが、不確定な事項が多い場合は課題表を作成した方が安定します。下のようなものです。
これには以下のような効果があります。
・課題を漏れなく管理できる
・課題のステータスを一覧できる
・クライアント側の要望も記載することで、ちゃんと受け止めている感、安心感を演出できる
特に3つ目の「ちゃんと受け止めている感、安心感」というのは大事で、問題なのはできていても相手に伝わらないことです。それはもったいない。特に多くの意見や要望を持っているクライアントの場合、作るとよいと思います。
結構手間がかかるので、やる時には手間がかかるし、一番多いのは作ったけど更新しなくなった、という状況です。これをやると埋もれて課題がわからなくなるので、一日何分かは見る時間を作るなど、業務に工夫が必要になります。
1-6:画面仕様書を作る
これは成果物のイメージの共有のためです。こんな機能でこんな画面になりますよ、という共通認識のための資料です。アジャイル開発形式で作ってすぐ見せるようやり方の場合は不要だと思います。一方で、一人で作るために共通認識を作るのが不要でも、どんな画面かはイメージを作っておくほうが手戻りが少なく、良いものが作れると思います。例えばレゴでお城を作るときに、何もない状態から試行錯誤無しで組み立てるのは難しいように、設計図はある程度作っておく方が効率的だと思います。
1-7:開発の言葉ではなく、ユーザーの言葉で説明する
クライアントはエンジニアで無いことが圧倒的に多いので、当然ですがエンジニアの言葉で伝えても理解できません。「このユーザーデータは、NSUserDefaultsにあるので、このタイミングでは取り出せず…」なんて説明は的外れになります。プロジェクトマネージャーとしてできることは、開発とクライアントの橋渡しで、エンジニアの翻訳です。取りうる選択肢がサービスにどのように影響して、メリット、デメリットを上げて、できれば最善案を提示する。これができないとPMとしている意味が無くなってしまいます。
この部分でもクライアントの本音を把握していることで、最善案を採択しやすくなります。
1-8:プロトタイプを作る。デザイン案を作る
画面仕様書と似たような役割ですが、プロトタイプを作る。デザイン案を作るということも有効です。しかし一方で、プロトタイプ、デザイン案を作る予算が無い場合もありますので、その場合には工夫が必要です。大きく認識の齟齬が無い前提で進めてまうか、簡単にペーパープロトタイピングだけでも作るか、プロジェクトにより複雑さの肝が違うので共通の答えはありません。
最近では手軽にプロトタイプを作ることができるツールがたくさんあるので、それらを利用して作るのが基本的には良いように思います。
1-9:クライアントを満足させる。そのために複数案提出する、逆提案する
これまでの経験上、クライアント自身で選択したりブラッシュアップした経緯がある方が、満足度は高いし成果物に対する不満も少ないです。
レストランで料理を作るのと料理教室で料理を作って食べるのとの違いに例えられるように思います。レストランでは、出てきた料理に文句を言うことはありますが、料理教室で作った料理に文句を言うことはあまり想像できません。もちろんレストランと料理教室では、目的が違うため全く当てはまることではありませんが「参加する」ということが満足感に影響を与えるのだと思います。
また、指摘をしたり自身の考えがいくらか反映されないと満足しない方もいます。そういった方のため、とは言いませんが逆提案を行ってよりよいと考える案を提示することは、クライアント自身で考えて選んだり、指摘をしたりできるようになるため、クライアントの満足度はより高いものになると思います。
一方で、クライアントの迷惑になったり失礼になったりするのでは？という懸念もあると思います。私自身は、迷惑になったり失礼になったりした、ということはありませんでした。提案の仕方に気をつけて「こういう案もあるし、こちらだとこういったメリットがある」という選択肢を提示する見せ方にして、あくまで選んでもらうというのがだとよいかと思います。押し付けられる提案は誰でも嫌でしょう。
1-10:懸念はあらかじめちゃんと伝える。社内の特にエンジニアの声を大事にする
企画しているときににありがちなのが、クライアントの要件通りに企画を作成していざ開発となった時に、実は技術的に実現できない内容が含まれていた、なんて場合です。この場合、なんとか近い代替案で進めがちですが、正直に伝えた方が後でもめることは少ないです。しかも出来る限り早い段階で伝えた方がダメージは少ないです。
私自身も、開発中に実現できない機能が発覚して、その機能は目立つところではなく無くても成立する部分だったので、仕方無く納品時に伝えたところえらくもめました。結局、根本的な設計を変えないと実現できない内容だったので、開発は大きな手戻りをして一部作り直しということになってしまいました。そんなことが起こらないためにも、問題は発覚した時点で相談すべきことだし、それが誠意ある対応だと学びました。
もっと言えば、企画の段階でエンジニアに確認することでこの問題は発生する確率が大きく下がります。下げられるリスクは下げるべきなので、早い段階でエンジニアに相談することは行うべきでしょう。
1-11:スケジュールは確率。長過ぎる納期の場合はフェーズを分ける
スケジュールは、作業者にとっては守るべき納期ですが、マネジメント視点では確率です。完成する確率が一番高い最短日数が納期になるので、途中で問題があれば当然遅れますし、だいたい問題は発生するものと見込んだ方がよいです。途中で問題の発生しないプロジェクトは、作っているもの自体に大きな問題があり、納品後に発覚するくらいの心構えがちょうどよいと思います。ですので、問題が発生した時点で、スケジュールへのインパクトを確認しクライアントと調整を行うのはPMとしては織り込み済みの仕事です。
また、長すぎる納期の場合「開発開始！では2ヶ月後完成したら会いましょう」ではまずうまくいきません。夏休みの宿題と同じで、最後の一週間でなんとかすればよいと考えるエンジニアもいるので、日々の進捗管理はマイクロマネジメントにならない範囲で行うべきです。
おすすめとしては、機能ごとにフェーズを分けて、その単位で社内でテストを行うことです。機能グループが1,2,3と分類できる場合、グループそれぞれでスケジュールを区切って、グループ1が完成した後はグループ2の対応と平行してグループ1のテストを行う、という形です。可能であれば客先ともフェーズを分けての納品を相談して、段階的に完成版に近づけていく方が、リスクが減ると思います。最後に大きな塊でドン！より小さく分けて小出しにした方がクライアントの負担も減るはずです。
最後にテストを残しておくと、そこで初めて確認して「全然違う！」ということにもなりかねません。分散して納品することで、例えば最初の納品でちょっと方針が違う、なんて時にそれ以降の対応にその修正を反映できたりします。クライアントへの確認がこまめになることでリスクが減らせます。
1-12:コミュニケーションはまめにとる。少なくともすぐに応答する
このあたりは基本中の基本なので、あえて事細かに書くことは省略しますが、質問に対するお返事として、内容の確認も含め時間がかかる場合は、せめて「確認してご連絡します」くらいの応答をすぐに送るべきかと思います。できればいつまでに回答するかを送れると相手は安心します。応答がなければ、相手は自分の投げかけが届いているか不安になるので、このあたりは人と人とのコミュニケーションとして普通のことですよね。
また、単純接触効果もあるので、まめなコミュニケーションは大事だと思います。
2:逆にプロジェクトマネジメント（PM）でなるべくやらない（方がよい）こと
2-1:打ち合わせ
打ち合わ好きな人や、打ち合わせが無いと進められない人がいますが、開発という観点では打ち合わせは極力減らすべきです。少なくとも、打ち合わせをする意味を常に意識して、打ち合わせごとに成果を出す必要があると思います。というのも、打ち合わせの一番の問題は「仕事した気になる」ということです。開発の仕事ではプロダクトを作ることが仕事なので、会議室では1mmも進行していない、ということを忘れてはいけません。
また、対面での打ち合わせは認識を擦り合わせた気になっても、ずれていることが多いためPMとしては管理の難しいワークになります。一番ありえるのは言った、言わないの問題で、議事録に残せるのは打ち合わせの一部なので、録音でもしていない限り追求不可能になります。録音で管理する場合でも確認や文字起こしをする労力が甚大になります。
そもそも言った、言わないでもめている時点でクライアントとの信頼の形成に失敗しているので、その原因となることは避けるべきだと思います。打ち合わせは、手軽に仕事をしたつもりになるので陥りやすいですが、あくまで資料ベースで、どうしても顔を合わせる必要がある時以外は、打ち合わせは避けるべきだと思います。
2-2:自身で作業すること（コーディング / デザインなど）
自身で実務の作業をすることも出来る限り避けるべきだと思います。というのも、実務を行う時にはある程度の集中力が必要で、その間マネジメントができなくなります。その時問題が発覚したら？相談しようにも実務に没頭していて対処できなかったら？問題の対処により自身の作業が遅延したら？
マネージャーには業務が集中しやすいので、自身がボトルネックになる可能性は下げるべきです。見込まれている作業であれば割り振りましょう。大丈夫です、想定外の作業は必ず発生してその対応に追われることになります。
2-3:察して欲しい、と思うこと
プロジェクトにおけるすべてのことを管理するのがPMなので、クライアントに対してはもちろん、チームのメンバーに対しても気持ちや状況を察して欲しいとは思ってはいけません。むしろ効果的に伝えて動かしていくことが重要です。
また、文章、図案化されていないことについて、クライアントから了解を得ているとは思ってはいけません。書いてないじゃん、と言われたら終わりです。押さえておかなければいけない事項はすべて資料化し、加えてクライアントが認識できるように伝える必要があります。
そうして伝えなければいけない状況をチームに共有し、伝えなければいけない仕様、機能をクライアントに伝えて起きうるコミュニケーションミスを全部潰すこと、それは弾幕シューティングのように山のように押し寄せてきますが、それでも捌いてうまくコントロールすることがプロジェクトマネジメントだと思います。
3:プロジェクトマネジメントは、プロジェクトにおけるすべての責任を自身で背負うこと
最後に、プロジェクトマネジメントはプロジェクトにおけるすべての責任を自身で背負うこと、という言葉で締めくくりたいと思います。誰かのせいにはできると思います。会社がよくない、景気がよくない、市場がよくない、チームがよくない…しかし責任転嫁の場所を見つけても事態は改善されません。プロジェクトにおけるすべての責任を自身で背負う覚悟をすること、その時に初めてプロジェクトが自分のものになるのだと思います。
これは人生でも同じで、自分の人生の責任を自身で背負い、自身でハンドルを握ることで初めて自分の人生が始まります。私がプロジェクトマネージャーになって学んだ一番のことはこれです。
大変むずかしいことではありますが、これを見ているプロジェクトマネージャーの皆様、ともに頑張りましょう。