非エンジニアの学生PMを育ててみた

初めまして、株式会社ispec CEOの島野です。
株式会社ispecは、「全ての人に挑戦の機会を」という理念を元に、コンサル型の開発事業を行なっております。

私は普段、ispecの経営をしながらも、複数のプロジェクトマネジメントや、PMの教育、採用などに携わっています。
これまでに累計で20を超えるプロジェクトのマネジメントをしてきました。

今日は、社会人経験の無いメンバーを採用して、0からPMとして教育をした話をします。
もちろん、今も絶賛成長中の彼ですが、0から納品まで出来るようになるまでのストーリーとして、この記事を執筆します。

PM: 鈴木悠太

株式会社ispec ITコンサルタント兼プロジェクトマネージャー
慶應義塾環境情報学部 休学中
趣味は、楽器演奏。アルトサックスをメインで担当し、自ら複数のバンドのリーダーを掛け持ち演奏をしている。

特にこの記事を読んでいただきたい人

• エンジニアではないけど、PMにチャレンジしてみたい人
• 社会人経験がないけど、PMっていきなりできるの？と思っている人
• エンジニアでPM経験が無いけど、スキルアップとしてPMをやってみたい

きっかけは、バンドの打ち上げで

鈴木と島野は、大学1年の頃にジャズ研で出会い、初対面でTHE CHICKENのセッションをした。その後、時が過ぎ大学2年の後半にとあるビッグバンドの打ち上げの席で酔っ払いながら話した。

鈴木「俺そろそろマーケティングのインターン始めようと思うんだよね、何かオススメある？」
島野「うちオススメだよ」
友人A「いいじゃん、入りなよ！」
鈴木「わかった！」

こんな感じで、彼のジョインが軽く決まった。みんな酔っているから意思決定が鬼速。

島野が、彼を採用した理由は、単純だ。
”リーダーシップを同期の誰よりも感じたから” だ。

リーダーシップというのは、ポテンシャルが必要だが、実務経験があって始めて実力が確認される。
鈴木は、数々のビッグバンドを自分で企画・運営し、毎回成功させてきた。
ビッグバンドを運営するには、数々のスキル・仕事が必要となる。

• 人事 約20人(サックス5人, トランペット5人, トロンボーン4人, リズム隊5人？)
• 選曲
• 出場ライブの選定・申し込み
• 場合によっては、ライブハウスの予約

つまり、20人規模のメンバーのマネジメントを行い、かつ毎回のプロジェクト(演奏)を成功に導く仕事をしている。鈴木は、１バンドやったとかではなく、複数プロジェクト成功させてきている、だから島野は、即決で採用をした。もちろん人柄、ビジョンや理念・価値観も酒を飲み交わしたから、共有できている。

マーケティングインターンとしてjoin

鈴木は、ispecでマーケターインターンとしてjoinした。
データ分析基盤を作り、それを元にマーケティングの意思決定を行う任務を任せ、弊社CTOをメンターとしてプロジェクトを始めた。

一つ一つ任務は遂行してくれていたが、タスクの質が濃いわけではなく、彼自身の成長に大きく貢献できるような環境を与えられているかというと、正直満足な状態ではなかった。要因としては、当時のispecは開発案件として、受注をしていたので、データ分析・マーケティング周りはその中からispecで予算を割いた挑戦だったこともあり、タスク自体の優先順位が下がっていたことがある。

こんな状態がしばらく続いてしまっていたものの、鈴木はispecで出てくる開発以外のタスクを前向きに取り組んでくれた。

業務フローの作成を手伝ってもらった

そんなある日、鈴木が取り組んでくれた仕事の中で、業務フローを作る仕事があった。当時の島野がテキストベースでヒアリングしたお客様の業務フローを、パワポで綺麗にするお仕事。
鈴木が前向きに取り組んでくれたので、お願いをしてみたら、とても綺麗にまとまっていた。要点を抑え、かつみやすい資料を完成させてくれた。

これはコンサルティングという仕事が純粋に向いているのかもしれない。彼はもっと上流でお客様の課題を整理し、的確なソリューションを提案する=コンサルタントを目指してもいいんじゃ無いかと思った。

初めてPMに

そして、とある開発案件で鈴木をコンサルとしてプロジェクトにアサインした。
開発案件ではあるものの、要件定義が済んでいるわけでもなくて、課題からソリューションを考えなくてはいけない段階のものだった。

島野も営業としてお客様の前に立ったが、彼にお客様の課題を整理しソリューションを提案するという業務を丸ごと任せた。
プロジェクトの背景・目的から整理をして、要件を絞りながら、ワイヤーフレームを作り、お客様と何度も幾度となく議論を重ねた。

そうしてめでたく受注が決まり、鈴木は正式にPMとなった。
要件定義書のFix, 契約書の作成・送付, メンバーのアサインなどを済ませ、プロジェクトは始まった。

5ヶ月に渡るPMで立ちはだかる困難

いざプロジェクトが始まると、困難が数多く立ちはだかっていた。
鈴木はPMをやったこともないし、エンジニアでも無い。何をすればいいのか全くわからない、わからないこともわからない状態。

島野は、鈴木の行動全てに対してFBを行い続けた。

• お客様へのメールのFB(送信前のチェックを2ヶ月ほど続けた)
• エンジニアとのコミュニケーションで気になったことをFB
• 少しでも間違った・危険なコミュニケーションをしていたら即座にDM or 電話
• スケジュール管理の徹底、考え方のFB
• 機能要件について、意思決定理由をFB

などなど、ありとあらゆるPMがやるべき業務について、しつこくレビューを続けた。
最初は、何もわからない状態でも、レビューした業務については徐々に出来てくる。

これが、 PMという仕事の正体だと島野は考えている。

PMというのは、お客様との期待値調整を行いながら、社内のリソース・スケジュール管理をしなくてはならない、いわば中間管理職のような仕事。基本板挟みで、常に1mmずれたら燃え上がってしまうような繊細な仕事である。

必要なことは、実践・実践・実践。本当にこれだと思う。
島野も、PMについてのインプットをしたことは殆ど無い。気づいたら自分で営業をしていて、気づいたら自分以外のチームのメンバーがいて、気づいたら納期がきている、これを繰り返していくうちにPMというものは育っていく。

納品

ついに、5ヶ月たち、鈴木率いるプロジェクトは納品を迎えた。
結果は。お客様とのすれ違いを少し残したまま納品をしてしまった。

すれ違いの内容としては、

• バグが残っている

というものだった。
本来、ispecでは社内でQAを行う決まりがあり、プロジェクト以外のメンバーで結成されたQAチームで品質確認をすることになっている。
だが、このプロジェクトではその工程を除き、受け入れテストを早めることにより、プロダクトの改善に時間を使い、検修期間にQAは回すことという合意を取っていた。バグが出ても、直せばいい、その温度感をispec側は完全に信じ切ってしまっていた。
と言っても、納品時にいくつかのバグが存在し、お客様に完全な満足を得てもらえないということが発生してしまった。それは当然だ。バグってプログラムが全く動かなければそれはプロダクトとして成り立たない。バグの程度にも寄るが、満足してもらえなかったという結果が全てだとも言える。

その結果の要因としては、いくつかの途中の工程での遅れや、ミスコミュニケーションが発生したことだ。

それをちゃんと鈴木は挽回し、最後までコミュニケーション・QA・チームのマネジメントを諦めることなく、最終的にはクライアントさんに満足してもらうことに成功した。

PMになるために必要なこと

それは「実践」です。

PMをしたことがある人の元で、その人の技を盗み・アドバイスをもらい、最前線で戦い抜く。そうしていくつかのプロジェクトを行う中で、たまに炎上することがあったとしても、一歩ずつ強くなれる。これが、PMである。

これに加えて武器になることは、「少しの事例」。
プロジェクトの成功例、どんなプロジェクトが過去にあったのか調べ、また人に聞き、自分が行うプロジェクトに近いものは無いか、徹底的に調べる。ここは、事例が社内に大量にある、大手コンサルファームが強い理由である。

先ほども書いた通り、プロジェクトマネージャーには、

• 要件のFix
• お客様との期待値調整
• 社内のリソース・スケジュール管理
• 品質担保

など業務は多岐にわたるが、どれも1mmの意思決定の差で、プロジェクトの成功と失敗の差が開いていってしまう。
例えば、追加要件を1回無償で許してしまったことにより、永遠と追加要件を請ける羽目になった。一つのバグが原因でお客様との関係性に上下が発生し、金額を下げて、なおかつ追加の要件をうけなくてはならなくなった。など。どれもたった1mmの意思決定で生死を分けるのだ。

だからこそ、持久力・瞬発力などを常に身につけ続けることが、プロジェクトマネージャーには必要である。

インプットに偏りすぎず、また武器や装備が無い状態で戦場にいくこともせず、バランス感覚を保ちながら、一歩一歩進んでいきましょう。