- PM(バックエンド)
- Goエンジニア/フルリモート
- 開発PM(Flutter)
- Other occupations (18)
- Development
- Business
フルリモート/フルフレックスのエンジニア集団、K.S.ロジャースでは、世界中どこにいても情報やノウハウをシェアしあえる体制づくりを目指し、さまざまな勉強会に取り組んでいます。
そこで今回、PMたちの悩みの種でもあり腕の見せどころでもある「プロジェクトがうまく進まない問題」に斬り込んだ、実例や経験を元にした勉強会がある…ということで、採用広報担当として潜入してきました。
趣旨とスピーカーの紹介 これは絶対面白い!
勉強会の大きな目的は、PMを中心にプロジェクトに関わるメンバーの知見・ノウハウ共有と交流です。日頃は自立して働いていても、自分以外のメンバーがどうしているのか…は気になりますよね。
そこで今回選ばれたテーマは、
プロジェクトマネジメント〜100件以上の難航案件からわかった「失敗しがちなPMの特徴」と「うまく進める極意」〜。
スピーカーは現在ベルリンに在住し、フルリモート/フルフレックスで働いている、PM/技術投資部門責任者の島田篤東さんです。数々の現場課題に直面し解決してきたからこそ話せる、有意義なノウハウをお持ちとのこと。
期待が高まります!
そもそも、プロジェクトをこじらせるPMの特徴は?
前半は、島田さんによる基礎レクチャー。
さっそくリアルなお話が始まります。
「そもそも、難航しやすいプロジェクトの条件やPMの特徴は、カテゴライズできます」
「しかし自分に該当する例が出てきても、大丈夫です。多くの失敗を経験した人は強い心を持ちます。誰もパーフェクトではありません」
聞いていた非エンジニアの私でもドキッとしましたから、参加のPMたちはなおさらだったのではないでしょうか。
島田さんによるレクチャーを抜粋してみます。
「計画的ではないPMは、プロジェクトを難航させる」
ー 細分化できていない、もしくは細分化し過ぎるPMはNG
ー 計画通りに進むにプロジェクトなんて1%もない
ー WBS(作業分解構成図)を綿密に作成しても、うまくいくとは限らない
「進め方が具体的ではないPMも、プロジェクトを難航させる」
ー 計画の細部まで目が行き届かないPMはNG
ー 大雑把な決定で、プロジェクトを進めてはいけない
「忙しいPMもNG」
ー PMとは、関係者が何を進めているのかを常に把握すべき立場
ー メンバーの作業の先を見て動くべし
ー クライアントとも、先を見て調整をすべし
ー 忙しいと手元しか見えず、傷に絆創膏を貼る作業しかできなくなる
ー PMは暇で、天井のシミを数えているくらいがちょうどいい
すでにとても勉強になりますね。
ここからはもっと具体的になります!
プロジェクトで課題が出てきたら…?
島田さんによると、プロジェクトの課題は2つに大別できるとのこと。
ひとつ目はよくある「納期の課題」、もうひとつは「人の課題」です。ここからは「人の課題」にフォーカスした話題が続きます。
「PMとの相性がイマイチで手が動かない、手伝ってくれるエンジニアが見つからない、ということは実際ありますよね」
ではどうすればよいのでしょうか。
「正しく権限委譲をする」
ー「よしなにやっておいて」という丸投げは一番NG
ー 納品後に問題が発覚しても、エンジニアのせいにするのは絶対ダメ
ー 範囲を明確にして、権限委譲しつつ全体把握を怠らない
「当事者意識を持つ」
ー 自分ごとにできているかどうか。「このプロジェクトの責任者である」という意識を持つ
ー 主役であるプロジェクトメンバーが活躍できるかどうかはPMにかかっていると、程よく自身にプレッシャーをかける
「エンジニアメンバーの言動をよく見る」
ー クライアントから理不尽なことやキツいことをいわれていない?
ー メンバーのメンタルケアを怠ると、プロジェクトは進まない
「PMは絶対に手を動かさない」
ー PMの仕事は現状把握。時間をかけ、細かいところまで洗い出す
ー コードを書くより、メンバーのケアに時間を割く
島田さん曰く、課題には必ず原因があるけれど「誰のせい」を探してはいけないとのこと。「すべてPMの責任」と受け止め、進め方が悪くて申し訳ないとメンバーに正面から向き合うと、次に何をすべきかが見えてくるといいます。
「開発を縮小するのか、納期を伸ばすのか。クライアントと調整するためにも、手を動かさずに現状把握に注力してください」
そもそも、スムーズに進めるにはどうしたらいい?
島田さんレクチャーの最後は「プロジェクトのスムーズな進め方」でした。
「メンバー間での目標認識が大切です」
「3か月間のプロジェクトなら、まず1か月ごとに分割。最初の1か月は、2か月目以降のことを考えません。なぜなら1か月目で、後半の計画が変更されることが多いからです」
「その上で、1週間ごとにマイルストーンを設定し、都度修正していきます。変更する前提で分解していくのがいいですね」
「もし2週間目で遅れが発覚しても、全体から見ると小さな修正で終わります」
「クライアントからの情報待ちで止まっているなら、『こう進めますね』とこちらから提案し、進めていきます。そのためにもPMが仕様を完璧に把握している必要はありますね」
メモの手が止まりません。
参加者からの質疑応答で、全体の学びが深まる
後半は参加者からの質疑に、島田さんが答えるスタイルで会が進みます。学びの深い回答をいくつか抜粋します。
Q:自分はNGタイプに当てはまりました。WBSを書かないと自信がなくて…
A:WBSを書くこと自体は悪くありません。最初にすべて書いてしまわず、第1階層まで決めたらマイルストーンに落とし込み、こまめ計画を見ていくといいですよ。
Q:忙しすぎるPMはNGとのことですが、余裕を持つために意識すべきことは?
A:計画段階では、手書きをしてみてください。Excelなどはキレイに効率的に整えようという意識が出てしまいます。最初の手書きアウトプットが、余裕をつくる第1歩です。人間の脳はそんなに賢くないですから、書き出さないと整合性を把握できません。メモやマインドマップを活用してみてください。
Q:プロジェクト前半でクライアントに「こう進めましょう」と伝えても、クライアントがよく分からないまま合意して、後半に計画が変更されるケースはあると思います。コミュニケーションをとる上で気を付けるべきことはありますか?
A:前提条件として、クライアントのOKはプロジェクトのOKとイコールではありませんよね。たとえば初めのうちにFigmaで完成イメージを提案し、仕様書で説明しなくてもシステムの未来像が見えるようにしておくと大どんでん返しは大幅に減ると思います。ちょっとした変更には、「次のフェーズでやりましょう」と提案しています。
Q:プレイイングマネージャーとして参画することが多いので、PMが手を動かしてはいけないと分かっていても、抱え込みがちになってしまいます
A:自分が手を動かす方が早くても、PMが止まるとメンバーが全力発揮できなくなります。まずは皆が作業しやすいようにissueを分かりやすく書く。次の準備が終わったら自分の作業を差し込む。自分が担当するのは小さな機能に留める、という工夫ができれば、楽になるのではないでしょうか。
その他も「メンバーのメンタルケアは?」「PMの定義は?」などの質問と、島田さんのリアルな回答が飛び交いました。オンラインでも熱気あるセッションができるのは、素晴らしいことですね。
島田さん、そして参加した皆さん、お疲れ様でした!
まとめ
勉強会の締めは、恒例の写真撮影です。画面越しから参加者の「いい時間だったな」という気持ちが伝わってきました。
フルリモート/フルフレックスのエンジニアが世界中から集まるK.S.ロジャース。
自由に働きながらも、濃い議論やノウハウ共有ができる体制が整っています。勉強会は今後もどんどん実施予定ですので、お楽しみに!
あなたも、K.S.ロジャースで活躍してみませんか?
気になる方はぜひ一度ご面談に参加してみてくださいね。