マネジメントのきっかけは“炎上プロジェクト”。普通のエンジニアがPMにハマったわけ

実はもともとJavaエンジニアだった

浪川舞 氏（以下、浪川）：よろしくお願いします。私からは、プロジェクトマネジメントについてお話しします。

本日は名立たる企業のRubyistが並んでいますね。私はRuby界隈に参加することは少ないのですが、まいどる（@maidol_28）という名前でTwitterをやっているので、よかったらフォローしてください！

私は半年前に起業して、今はPeerQuestというシステム開発会社を3人でやっています。キャリアは、音楽大学卒業後に音楽の仕事に就いてたところから始まります。実はエンジニアになったのが5年ぐらい前の2014年と、わりと最近で、はじめの3年くらいはSIer（エスアイヤー）のJavaエンジニアで、その後、エンジニアリングのマネージャーを経て、マーケティングPRの部署を立ち上げ自社サービスを開発するようになりました。そこからRubyを触るようになったという経緯です。大きな声では言えませんが、もともとはRubyよりもJava派でした（笑）。

まずはPMの定義から

本日はPMの話をしますが、それについてnoteでもいくつか書いているので、よかったらあとで見てください。

PMと言ってもプロジェクトマネージャー、プロダクトマネージャー、プレイングマネージャーなど、いろいろな文脈がありますが、今日のPMの定義は、プロジェクトのマネジメントということで、進捗管理などの話ができればと思います。ただ私自身のキャリアとして、最初はプレイングマネージャーとして入ったので、そういった話も混じっていますが、ご了承ください。

まずは「そもそもPMって何だっけ？」というのを今回あらためて調べてみました。これが意外と難しく、「プロジェクトの計画と実行において総合的な責任をもつ職能」と、けっこう曖昧な感じでした。

では「プロジェクトマネジメントは何だっけ？」というところで見ると、計画の立案や日程表の作成、進捗管理などをする、とちょっと知っている用語がいくつか出てきました。最後に意外と大事なことが書いてあって、「システム開発を成功させるためには、プロジェクトを適切に管理することが求められる」。これが一番大事なんじゃないかと思い、完全に理解した！　となりました。

というところで、本日は私の最初にプロジェクトマネジメントをしたときの原体験と、それによって生じた副次的効果、あとは少し具体的なPMをするときに何を意識しているかという話をします。

マネジメントのきっかけは炎上プロジェクト

まずはエンジニア2年目におきた炎上プロジェクトについて。このスライドでは、ニワトリが当時のPMで、ヒヨコは全部新人なのですが、このように新人比率が8割ぐらいのプロジェクトに当時入っていました。そこにフリーランスのエンジニアもいて、ちょっとチームがだらけていました。なぜか株をずっとスマホで見ている人がいたりとか（笑）。

（会場笑）

あとは「新人ばかりでうんざり。やりたくない」みたいなフリーランスの人や、掛け持ちで余裕がなくて新人を見れない先輩エンジニアもいて、しまいには新人が新人の面倒を見るという状態も発生していました。PMは「もうみんながやってくれないから」と言って自分が設計しはじめるという、とんでもない状態になり、後々燃えましたと（笑）。

結合テスト直前に「そもそもできてないじゃん」という状態で。このときすでにPMが顧客窓口ですごく忙しくなっていて、要件の整理が大変だったため、「ちょっとフォローしてくれないか」と頼まれたというのが、私の最初のマネジメント経験です。

そこで頼まれたのが、朝会の定期開催や進捗管理の数字を分析してほしいということでした。あと、最初はちょっと意図がわからなかったのですが、「毎日メンバー全員の顔を見てね」と頼まれました。

朝会については、みんなのコミュニケーションが足りてないという感じが一番あったので、まずは毎日開催することにしました。全体の温度感の共有とか、あとは課題を抱えている人がいないかを確かめ合いました。全員の前で課題を見せ合うことで、1人の問題じゃなく全員で解決していくものだよ、という意識共有みたいなことをしました。

進捗の分析では、隣にいるエンジニアが何のタスクをやっているかわからない、いう状態が発生していたので、みんなの担当を明確化し、進捗率ではなく作業効率を重視して見るようにしました。

なぜかと言うと、例えば進捗が90パーセント出ていたとしても、0から80パーセントになるときと、80から90パーセントになるときで作業効率が落ちていたら、それはその課題で何か問題が起きているということです。そういうことをみんなでキチンと拾えるように作業効率を重視していました。

あとはバーンダウンチャートをみんなで共有する。バーンダウンチャートはプロジェクトで使ったことがある人も多いと思いますが、全員で見ることで、少しゲーム感覚のようにプロジェクトを進めていく。ユーモアも忘れないようにやりました。

毎朝メンバー全員の顔を見ろというのは、最初ちょっと何を言われているのかよくわかりませんでしたが、今ではすごい大事だなと思っています。なにか不安を抱えている人がいたり、疲れちゃっている人がいると、大事なときに病気になってしまうよりは、休んでもらったほうがいいと判断する場合もあります。そういう意味で、当たり前のことですが、みんなと接触するように心がけていました。

先ほど話した燃え盛っていたときを今でも思い出すんですが、これで少しは状況が整理され、プロジェクト全体が見える化されたので、何をやるべきかがハッキリして、心もスッキリしました。

プロジェクトマネジメントにとって大事なこと

次は、それによって起きた副次的効果を紹介します。最初に感じたのは、問い合わせ対応が非常にスムーズになったことです。というのも、もともと混沌としていた情報が整理されたので、一次回答までの工数が短縮しました。あとは不具合の報告が上がってきたときも、担当が明確になっているので、エスカレーションしやすくなった経緯があります。

さらに、これに付随して、誰でも休みが取りやすくなったんですね。ゴールが今まで見えなかったので、闇雲にがんばって土日もやっていましたが、そういうこともなくなりました。属人化していないから、誰かが休んでも誰かができるという状態になったのです。結果、自然に業務改善されたので、工数が削減されて、結果的に個人にもいいことが起きたよね、というのがまとめです。

ここからは少し具体的な内容になるのですが、私がプロジェクトマネジメントをするときに、今でも大事にしていることをいくつか紹介します。

一番は「基本を大事にしよう」というのがあるんですが、セオリーの活用とか数値も、先ほども話したように分析したり、あとはコミュニケーションに重きを置いています。セオリーの活用で言うと、PMBOKとかITILという……ちなみにこの辺の言葉を聞いたことがある人どれくらいいます？

（会場挙手）

8割ぐらいの人が挙げていますかね？　一応PMの体系的な知識だと、こういったデファクトスタンダードと呼ばれるような知識体系があります。こういうところから、はじめはインプットしていったり、また実際にITILという情報整理をするプログラムを導入したりしていました。

あと数値分析のところは、何事も数字で根拠を裏付けることを今も大事にしています。例えば「この機能を作ってほしい」とビジネスサイドから言われたとき、それが明日までにできるのか1週間後にできるのかというのがわからないと、ビジネス的な話とか開発のスピード感がわかりません。何事も見積もりと実績を常に把握するようにしています。

それを繰り返すと、見積もりの精度が上がっていきます。この見積もりに関しても、スクラムをやったことがある人は使ったことがあるかもしれませんが、エンジニアを巻き込んでプランニングポーカーみたいなものを使ってを、エンジニアみんなで楽しくできるように工夫しています。

先ほどの話も、実はメチャクチャ共感して頷いていたんですけど、コミュニケーションがやはりプロジェクトマネジメントで一番大事だなと思っています。

とくに最近取り入れているのが、上下関係を無視した1on1です。普通はマネージャーとエンジニアという1on1が多いんですけど、そうではなくて技術者同士で1on1をしてもらって、情報の共有を図るとかをしています。会議のファシリテーションも誰か一人にやらせるんじゃなくて順番にやってもらっています。

また自分とメンバーの特性を知ることも大事だなと思っていて、ストレングスファインダーのようなもので自己分析した結果をみんなで共有し合って、誰が何を得意としているのかを把握するようにもしています。

マネジメントを知ると開発が楽しくなる

ここにいる人に、さらにプロジェクトマネジメントにハマってほしいので、いくつかインプットしたものを紹介しますね。PMについてはnoteも書いていますが、そこでもいくつか書籍を紹介しているので、よかったらあとで見てください。

この中で私がよく読み返したりするものは、以前メチャクチャ流行った『もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら』です。

これは本当に基本原則としてのマネジメントを読みやすくライトに書いてあるので、自分に置き換えて読んだりすることもできて、すごく良書だと思います。

最後のこれ、『ゲーム開発 プロジェクトマネジメント講座』が一番紹介したい資料なんですけど、エンジニアにとって「これはすごい納得できる！」という部分が多いんですよね。『ファイナルファンタジー』などを担当されたスクエア・エニックスの元CTOの橋本さんが書いたもので、資料自体は2011年と少し古いんですが、今でも使えるアジャイルの手法などについても言及されています。

こういった身近な事例でマネジメントを知ると、もっと開発が楽しくなるなと思います。私は、マネジメントを知らなかった最初の2年と、マネジメントをいろいろ知るようになってからのエンジニア人生は、後者のほうがすごく楽しいと思っているので、ぜひみなさんにもプロジェクトマネジメントの勉強をしてもらって、「プロジェクトマネジメント沼にようこそ！」と言えたらいいなと思っています。

ご清聴ありがとうございました。

（会場拍手）

プロジェクトをうまく回すためにやっていること

司会者：どうもありがとうございました。質問がある方は挙手をお願いします。

質問者1：プロジェクトをうまく回すためには、メンバーのモチベーションを高く保つことがとても大事だと思うんですが、具体的に何かやっていることがあれば教えてください。

浪川：今私は、いくつかプロジェクトをやっていて、自社サービスの開発やクライアントワークでの受託製作みたいなものをやっているのですが、どのプロジェクトに関しても、ビジネスのOKR（Objectives and Key Results、目標とそのカギとなる成果指標）をメンバーで共有するようにしています。

同じタスクを全員でやっているわけではないのですが、目標は絶対に一緒なはずです。その目標を共有して、それを軸に今のタスクをやっているということを朝会などで共有するようにしています。

質問者1：ありがとうございました。

司会者：他には質問ありますか？

質問者2：プロジェクトマネジメントをやっていると、チームだけじゃなくて顧客だったりステークホルダーだったり外部の要因でいろいろプロジェクトが炎上したりすることがありますよね。例えばその顧客の要望が、すぐに変わったりとか、あるいはすごい追加の要望をあとから言われて、「うわっ！」とかなることがあると思うのですが、そういうのはどう解決していますか？

浪川：実は今もあって、昨日もなんか……（笑）。この前までAという機能と言ってたのに、いきなり「AにA'とB'とC'も追加してください」みたいなのがあって「あぁ……」と。あるはあるんですけど、気を付けているのは、基本的にこういうことを言われたという内容をあまり間を開けずに、みんなにフィードバックしています。

ただ「焦らないでいいよ」とは言っていて、それをどうしていくのか決めるのがプロジェクトマネジメントだと思うので、私が決めるまでは焦らなくていいけど、今こういうことが生まれているという状況だけをまずは共有して、そこから線を引き直すようにしています。

質問者2：なるほど！　ありがとうございます。

司会者：あとおひとり、さっきほど手を挙げた方……。

質問者3：先ほど話していた横とか斜めの1on1について知りたいのですが、上司と部下といった縦の1on1だと得られないようなメリットって、何かあったりしますか？

浪川：私もやり始めたのが2ヶ月ぐらい前なので、まだ正直効果についてキチンとヒアリングはできてないんですけど。ただ、いろいろやってみて感じているのが、上の人相手だとどうしてもいいところを見せなきゃと思ってしまう部分が出てきたりして、本音の悩みが言えない状況が発生していると思っています。同じフラットな関係同士だと、実は「このタスクがまだできてないんだよね」とか、そういった潜在化されていたものが浮き彫りになっていると感じてます。

司会者：最後にまいどるさんに大きな拍手をお願いします。ありがとうございました。

（会場拍手）