エンジニアを理解し、スムーズな進行管理を！今日からできる、プロジェクトマネジメント実践

こんにちは、採用広報の木下です。

Web開発において、開発の実務を行うエンジニアはもちろんですが、実際にプロジェクトの中心に立ち、クライアントとエンジニアの間に立つ存在であるプロジェクトマネージャー（以下PM）は必要不可欠です。

今回は、PMのみなさんに向け、Webシステム開発の手法や、エンジニアとのコミュニケーションやマインドセットを紹介します！

PMってどんな仕事？

PMは、プロジェクトの責任者としてゴールに向け、いつまでにどうやって作るのかを計画・実行・管理する役割です。

主な実施内容は以下の3点。

プロジェクトのスケジュール策定
プロジェクトのスコープ調整
開発メンバーのリソース管理

対エンジニアの調整が必要とされるため、エンジニアと協働するためにWeb開発の流れや基本的なシステムに関する知識が必要となります。

本記事では主に工程管理にフォーカスし、Webシステム開発プロジェクトのPMにとって重要なポイントを紹介していきます。

エンジニアを味方につける

プロジェクトにおいて、実際にものづくりをするのはPMではなくエンジニアです。エンジニアはWebシステム構築における開発の要のポジションとなるため、基本的にはエンジニアがいないとシステムを作ることはできません。

プロジェクトで困ったとき、職人であるエンジニアを連れてこられるかはPMにとっての大事な資産の一つです。エンジニアと信頼関係を構築することがプロジェクト成功の近道となります。

エンジニアを管理する

エンジニアだけでもWebシステムを作ることができるのに、なぜPMは必要なのでしょうか？

エンジニアが専門性を発揮する領域は、「設計・開発」です。プログラムやシステムをどう構築するかを検討整理し、ソースコードを書き、システムを動く状態にするなど、開発の専門家としてプロジェクトにコミットしてもらう必要があります。

一方で、エンジニアに効率的に専門性を発揮してもらうための環境作りは、PMが専門性を発揮する領域とも言えます。仕様や要件、タスクの整理、優先順位・担当者決め、プロセスの整理、スコープの調整など、プロジェクトにまつわる多岐にわたるマネジメントが必要です。

エンジニアのリソースは限られているため、エンジニアの専門性を活かすこともPMの仕事です。

PMの専門性とは、エンジニアをはじめとするプロジェクトに関わるメンバーが迷子にならず、モチベーションを高く持ちプロジェクトを完遂させることです。

エンジニアの仕事や特性を理解する

エンジニアの傾向を知る

PMとしてエンジニアと仕事をする上で、仕事や特性を理解することは非常に重要です。

Webシステムの開発に従事するエンジニアは、積極的に新しい技術や手法をインプットしていく傾向にあります。インターネット上で情報が共有され、情報感度が高いエンジニアは非常に多いです。

PMはプロジェクトを管理していく上で、エンジニアにやるべきことをやってもらい、プロジェクトの適切な進行管理を行わなければなりません。一方で、エンジニアのやりたいことを殺さず、成長機会を作ることでモチベーションを上げるという点も、非常に重要なミッションと言えます。

エンジニアとの向き合い方・考え方

Webシステム開発のプロジェクトにおいて、PMがエンジニアの特性の理解を深めるために重要な考え方を紹介します。

ブランチ方針

各メンバーが開発した内容をどう管理していくか、PMの独断で判断するのではなく、エンジニアとディスカッションをし、方針を決めてから運用していくと良いでしょう。

スプリント

スクラムと呼ばれるアジャイルソフトウェア開発概念の一つです。ユーザー提供するストーリを決め、一定期間（1〜4週間）に区切って集中して開発する反復期間のことを指します。目標に集中することで、素早く成果を出すことが可能です。

KPT(Keep-Problem-Try)

スクラムの中の振り返り工程において、ディスカッションのツールとして使用される手法です。Keep（良かったこと）、Problem（悪かったこと・問題点）、Try（続けること・改善すること）を洗い出し、振り返りを行います。

1on1

PM1人に対し、1人のエンジニアおよびメンバーと30分〜1時間の時間をとり、話をすることです。プロジェクトメンバーからのヒアリングをすることが趣旨となります。一人一人のモチベーションの把握と、課題の吸い上げが1on1の重要なポイントです。

リモートワーク全盛の時代で、オフラインで働くよりもコミュニケーションの取り方が難しくなっています。ただ、オンライン会議も含めた対面でのコミュニケーションに手を抜かないことは、情報を効率よく伝えるコツです。

ビジネスサイドにいるPMと技術者のエンジニアは使役の関係ではなく、互いにプロジェクトを構成する人員です。お互いリスペクトを忘れずに、気持ちよくプロジェクトを進めていきましょう。

実践的な開発ルーティン

ここからは、PMがWeb開発の現場において実行すべき、実践的な開発のルーティンについて紹介していきます。

ステップ1：仕様・要件を整理する

機能一覧を作成する

機能一覧とは、システム開発の対象機能のことを指します。つまり、何を作るべきかを一覧化する作業です。

機能一覧ができていないと、仕様・要件が整理されていないことになってしまいます。

仕様・要件が整理されていないのであれば、直ちに整理・作成しましょう。また、機能一覧を作成する中で、不明な機能や機能に落とすことができないものは、仕様をプロダクトオーナーと調整することも必要です。

画面遷移・ワイヤーフレームを作成する

プロジェクトにもよりますが、Web開発のプロジェクトにおいては基本的に画面が発生することが一般的です。プロジェクトにデザイナーがアサインされている場合は、作るものを見える化するため、画面遷移とワイヤーフレームを作成してもらいましょう。

Figmaなどのデザインツールで作成されていると、後々、エンジニアとデザイナーとのコミュニケーションが楽になるためおすすめです。

PMは、デザイナーが作成した画面遷移とワイヤーフレームが機能一覧の機能を網羅しているかチェックしていきます。

ドキュメント作成

システム全体図やアーキテクチャ図など、他に設計図化しておきたいものはたくさんあります。

資料として作り込むのがリソース的に難しい場合、ざっくりでも良いので簡易的な設計図として落としておくと作りたいもののイメージがつきやすくなります。その際の設計粒度は、エンジニアとも相談しつつ進めていきましょう。

ステップ2：計画する

マイルストーンを洗い出す

マイルストーンとは、重要な目標地を意味します。たとえば、リリース予定日、β版リリース、お客様へのデモ、社内向けデモなどです。

お客様に向けたデモであれば、デモのシナリオが必要となり、デモのシナリオを実施するための機能がわかります。

時間があれば何でもできますが、プロジェクトには期間があります。マイルストーンを設定し、何をいつまでにすべきか明確を明確にしましょう。

機能の優先度付けを行う

マイルストーンから、いつまでに何をやらないといけないかを把握した後は、マイルストーンごとに機能の優先度付けを行います。

たとえば、「β版にはこの機能は必要だが、この機能は不要」というような判断です。

優先度を付けてもすべて必要な機能となってしまう場合、サービス利用者にとって最低限サービスを提供できる状態を想像することが重要です。

機能は全て盛り込みたくなってしまいますが、開発すべき機能はミニマムにしていく判断をすることもWeb開発における重要なポイントです。

機能一覧からタスクを洗い出す

機能の優先度付けのあとは、優先度の高い機能からタスクを洗い出していきます。

PMがすべてやる必要はありません。エンジニアが具体的なタスクをイメージできるレベルまで細分化することが重要になります。タスクの洗い出しもエンジニアと相談しながら行いましょう。機能によっては分解しすぎると意味をなさないこともあるため、その点も注意が必要です。

タスクを明確にし、やるべきことがわかればエンジニアは設計・開発に集中することができます。

ステップ3：実行する

スプリント期間を決める

チームの活動頻度や人数によっても変わっていきますが、1週間から長くても2週間に設定します。あまりにも期間が短すぎると開発が進まないため、開発が進む期間の設定が必要です。一方であまりにも期間が長すぎるとだらけてしまうため、プロジェクトごとに適切なスプリント期間の見定めを行うこともPMの手腕と言えます。

スプリントの目標を決める

スプリントの期間が確定したら、その中でどこまで開発するかを具体的に決めていきます。

「○○機能を実装する」でもいいですし、「開発環境を用意すること」でもいいです。

まずは、チームとしてマイルストーンに少しでも近づくための目標を設定していきます。

ここでは本格的なスプリント開発のように、必ずしもリリースを目標にする必要はありません。小さい目標でも良いので、チームが一丸となり向かうべき方向を示すことが重要です。

発生した課題の整理

開発が進行していく上で、課題の発生はつきものです。課題の内容は、「仕様に起因するもの」「能力に起因するもの」「組織に起因するもの」とさまざまでしょう。

PMは課題をエンジニアから吸い上げ整理し、対応策を考えなるべく早く実行することが求められます。課題をそのままにしておくと負債がどんどん溜まっていってしまいます。

ステップ4：振り返る

スプリントを計測する

1スプリントが完了するごとに定量的に計測しましょう。「全体として、タスクをどれだけ消化することができたのか」、「個々人のタスクの消化スピードはどうだったか」、「前のスプリントに比べて、開発スピードは上がっているのか下がっているのか」などです。

スプリントを計測していくにつれて、プロジェクトの進みが明確になり、管理もしやすくなります。定期的に計測することで、今後の見積もりの確実性も増していきます。

リスクを棚卸しする

スプリントが終わり、プロジェクトが見えてきたことによって将来的に発生しそうなリスクや問題はないでしょうか？「人手が足りるか」、「機能の抜け漏れがないか」、

「実現不可能ではないか」など、さまざまなリスクに対して、事前に手を打っておきましょう。杞憂でもいいので、常に悲観的にリスクをシミュレーションし、闘い続けることが後々効いてきます。エンジニアが通る道に存在する障壁を事前にPMが排除し、スムーズにプロジェクトを進めていきましょう。

ステップ1〜4を繰り返し行うことで、プロジェクトの確実性も上がっていきます。PMがこれらを実行することで、エンジニアも開発に集中できるため、プロジェクトとしても健全に周ります。一方で、いずれのステップもPMの独断で実行はできません。エンジニアとの協働は必須となるため、プロジェクトメンバー内の密なコミュニケーションは必要不可欠です。