今の会社での肩書は プロジェクトマネージャー の下條です。この3, 4年ほどプロジェクトマネージメントの仕事をしてきて学んできたことを今回は少しだけ共有いたします。

本記事の読者想定

本記事は特に以下の方をターゲットに書きました。

• 最大10人程度のチームでメンバー全員を見ているプロジェクトマネージャーの方
• プロジェクトマネージメントに興味がある方

なお、チームメンバーが10人を超えてくるとプロジェクトマネージャーが全てのメンバーを見られなくなり、プロジェクトマネージャの下にリーダー的な人を立てることが多くなってくると思います。私はそのような形のプロジェクト全体を見た経験はほとんどなく、今回の記事ではそのようなケースについては一部当てはまらない部分もありますのでご了承ください。

今回は大枠として、

1. メンバーのアサイン
2. リスクコントロール
3. 品質コントロール

の3つの観点から書いてみたいと思います。

1. メンバーのアサイン: メンバーの個性を活かす

メンバーは当然ながら個性があります。

• 開発力
• 得意分野・不得意分野
• 好き嫌い: ○○の技術はあまりモチベーションがわかないといった技術的な好き嫌いや、単純作業を好む好まないといったタスクの性質の好き嫌い

まずはメンバーの個性を把握しておくことが重要です。

プロジェクトにおいては様々な性質のタスクがわいてきますので、上記を踏まえて可能な限り適任と思われる人に任せるようにします。技術的に適任かどうかはもちろんですが、タスクの内容的な好き嫌いもモチベーションに直結しますので考慮します。
ただし、プロジェクト単体で適任かを判断するだけではなく、今後の別のプロジェクト運営も見据えることも多くあります。ある分野を伸ばしてほしいといったメンバーがいたら、必ずしも現状最適でなくても敢えてその分野のタスクをアサインしたりもします。

また、メンバーの個性の把握ですが、

• 開発力: 何個か開発タスクに取り組んでもらった上で、コードレビューを通して把握します。
• 得意分野、不得意分野や好き嫌いについては普段の雑談の中で聞いたりするほか、プロジェクトの初期等にヒアリングする時間を設けることもあります。

のように行っています。

2. リスクコントロール

プロジェクトには様々なリスクがあります。プロジェクトマネジメントはそのリスクを次第に減らしていく仕事ということもできます。

2-1. 仕様的な不透明性
2-2. 技術的な不透明性
2-3. メンバーの体調不良など各種要因

2-1. 仕様的な不透明性リスクに対するコントロール

弊社でプロジェクトを受託開発する際には、まずはAdobe XDなどを利用してお客様と機能仕様の認識合わせを実施してから開発をするケースが多数です。ただ、当然ながらAdobe XDレベルでの合意をしたのみでは、実際にできあがったプロダクトを納品すると、思っていたものと違うというケースは発生してきます。最終納品時にそのような問題が発生するのはお客様にとっても弊社にとっても幸せなことではありません。したがってこういったケースをいかに少なくするかが腕の見せ所となります。

じゃあ具体的にどうするか。要件定義の方法などいろいろとコツはあるのですが、一番大事なのは、アジャイル開発を理解されている方であれば自明かと思います。それは、実際にできたプロダクトをできるかぎり早くお客様に確認してもらい、フィードバックをもらうことです。

弊社の受託プロジェクトの形態として準委任/一括請負のいずれかが主ですが、いずれの場合でも早期フィードバックをもらうことは強く意識しています。準委任契約であればその時点で柔軟に仕様変更をすることも可能です。一括請負の場合は、あらかじめ定義した仕様を元に実装する形ではありますが、手戻りを防ぐという意味で非常に重要なプロセスです。また、定義した仕様が不十分であることも多々ありますので、そこを埋めていくプロセスとしても非常に重要です。

2-2. 技術的な不透明性リスクに対するコントロール

新規で採用する技術がある場合や、どのように実装すればいいか見当もつかないといったケースです。

これに対する対応としては、プロジェクトのできるだけ早いフェーズでお試し実装をするのがよいです。そして、さらにそのお試し実装は最終的に捨て去るものではなく使えるものであることが理想です。

達人プログラマーの本に書いてある、いわゆる閃光弾と言われるものです。ちなみに、達人プログラマーは私のソフトウェアエンジニア人生で最も影響を受けた本のひとつです。

2-3. メンバーの体調不良など各種要因

あらかじめ対策をするのが難しいリスクではあるのですが、当然ながらメンバーを疲弊させるようなプロジェクト運営をしてしまえばリスクは大きくなります。したがって、既に書いたようなリスクコントロールをしながらスムーズなプロジェクト運営をしていくのがひとつの対応方法です。

また、メンバーを精神的に追い込まないことも心がけていることのひとつです。自分の中で進捗まずいな、、、と思っている場合、発破をかけることはありますが、過度にメンバーにストレスをかけるようなことはしません。マネージャーがネガティブな態度を取ってしまうとメンバーに悪影響を与えてしまいますので、マイナスな感情を表に出さないことを常に心がけています。

あとは、何かあったときの代替案を常に考えておくということも大事です。そうすれば何があっても慌てることはありません。ただ、それでも予測不可能な問題が起こったりはするわけですが、、、

その時は元プロレスラー長州力さんが
逆境？それ、チャンスだよ
とおっしゃっている通り、まさに逆境はチャンスと捉えて立ち向かうのみです。

3. 品質コントロール

お客様の品質要求レベルに応える

品質は良いに越したことはないのですが、過剰品質はコストおよび納期に跳ね返ってくるのが一般的です (QCDの考え方によります) ので、お客様の求める品質要求レベルを担保することがゴールとなります。
既にお付き合いのあるお客様については品質要求レベルがわかりやすいので、コントロールもしやすいのですが、初めて関わるお客様については品質要求レベルがわかりづらいケースがあります。

これに対する対処としても仕様的な不透明リスクに対するコントロールと同一となります。実際に動作するアプリケーションを早い段階で受け入れ確認をしてもらい、それに対するお客様のレビューによりお客様の品質要求レベルを把握した上で、後述するコードレビュー等で品質コントロールをしていくことになります。

コードレビューに参加する

最近はコードを書くことはほとんどなくなりました。ただ、コードレビューには参加するようにしています。その目的は以下の通りです。

• 品質コントロール: 特に機能仕様的な部分は各メンバーよりもプロジェクトマネージャーのほうが全体像を把握していることが多いですので、機能仕様的な部分について最も力を入れてレビューしています。
• 進捗状況の把握: 各タスクはチケット化して進捗管理していますが、実際のコードを見ていれば進捗はひと目でわかります。
• メンバーの開発力の把握: これは先にも書きましたが、新規メンバーがどの程度の開発力を持っているか把握することも目的にしています。
• 将来のために実装を知っておく: 大まかな実装を把握しておくことで、仕様変更・納品後の保守・追加機能の見積もりなど自分でもある程度見えるようになります。それらのタスクを自分で実際にやるやらないは別として、少なくともメンバーとの会話が非常にスムーズになります。

コードレビューへの参加は個人的感覚としては10人程度のチームぐらいまでであれば可能だと思いますが、より大きなプロジェクトを見るようになるとおそらく手が回らなくなる部分かもしれません。

まとめ

まだまだ色々とありますので、また別の機会に書いてみたいと思います！

shimo