企業にもPMにもチームにも嬉しい、コスパの良い省エネマネジメント

私はあんまり働きません。

なんて言うと語弊がある気がするんだけれど（笑）本当に、持っている案件のわりには稼働工数は少ない人材だと思います。

受託開発でプロジェクトを進めるにあたって、小規模な案件であればあるほど、クライアントの予算も上限が少なめ・・・ってことはよくある話。
私はその限られた予算の中で、一番結果が見える形でパフォーマンスを発揮するには、開発工程に最大限予算を使うことが一つの正解だと思っています。

今回は、全体の予算を開発工程に最大限投下するために、私がどのようにしてマネジメント工数を減らしているか、予算配分の戦略をどう考えているか、一例として紹介していきます！

予算が少ないプロジェクトとは？

ここでは、「やりたい要件規模に対して一般的なシステム開発手法で実現するための予算が低めだが、全く足りないわけではない」という課題を抱えたプロジェクトについて言及します。

これらは、企業のお財布事情で出せる金額に上限がある場合はもちろん、予算はあるにはあるが、できることなら最小にして他にも投資したい、というケースもあり得ると思います。

この辺りは自分も経営者である以上理解できる考え方ではあるし、それならそうでお互いの持ってるリソース（ヒト・モノ・カネ）を上手に駆使して最適解を見つければいいと思っているので、「予算が足りないなら何もしません！」とは思いません。
かといって、受託する側が不足分を背負ってあげて無理して受注するのは違うし、最終的にパフォーマンスが悪くなるだけなのでよろしくない。

自分たちの首を締めることなく、クライアントにも喜んでもらえるよう、プロジェクト開始時点から調整力が重要になってきます。

相手の温度感をはかる

全体的に使える予算が少ない、できるだけ抑えたい、といった場合に考えられるケースはいくつかあります。

• 当たるかどうかわからないアイデアなので試しに作ってみたいだけ
• 追加開発でグロースさせていきたいけど様子見ながら進めたい
• 助成金や補助金によって成り立っているサービスで上限が決まっている
• 企業の事情が先立って、決まった予算ありきで開発投資をしている（予算消化したいから何かしら作りたいetc.）

どれも「予算」という範囲内で開発したい、というのは同じですが、本質的に目指しているゴールは実は違う。クライアントのお財布事情にも踏み込んでヒアリングして、予算配分をマネジメントするのが良いコストパフォーマンスを実現する第一歩です。

試しに作ってみたいだけ

まだ売上が立つかどうかわからない段階では予算もかけづらいのはごもっとも。

こんな場合は、まずプロトタイプ開発の分だけ予算をいただいて進めます。
もしくは市場調査など、もっと前段階のお手伝いに予算投下してもらっても良いかもしれません。
この段階では、詳細設計書などの手のかかったドキュメントや細かいテスト仕様書などが求められるケースはほとんどないので、削減できる工程を提案した上で、必要な工程のみ時間をかけて進めます。

様子見しながら追加開発したい

毎月の売上変動が不安定で、一気に予算投下できない状況の企業などで多いです。
それでも改善したり前に進めることはしたいわけなので、そんな時は、あえて稼働時間を固定せず、流動的にアサインできる副業メンバー等で調整します。

受ける側も空き時間での対応を前提とすることで他の案件も効率的にまわし続けられますし、クライアントとしても実際に必要になった工数の費用だけで抑えられます。

助成金や補助金で上限が決まっている

このパターンは、「決まった中でできることをする」しかないのですが、その「できること」をどう設定するかで動き方は変わってきます。

2年目、3年目も見据えた長期的なプロダクトなのか、1回作りきりで終わるのか（キャンペーンサイトなど）にも左右されます。

それらをヒアリングした上で、長期であれば毎月メインディッシュに一番工数をかけられる方針で進めていけばよし、1回作りきりであれば優先度をつけて完成させる対象を絞っていくしかないですね。追加したい機能は、助成金とは別に予算が出るかどうか次第で・・・

予算消化したいだけ

正直、いらないかもしれないモノを開発するのは誰も幸せにならないのでオススメはしません。。。が、相手の事情も汲み取った上で、その予算内で少しでも世の中に役立つサービスが生まれるのであれば、進める価値はあると思います。

このパターン、予算ありきでコトが進んでしまっている分、相談いただいた時点では意外とまだ要件策定の余地が残ってたりします。会社規模にもよりますが、消化したい予算は上流工程に使って、残りを次期以降の予算で組んでもらう方向に持っていくのもアリ。（この辺りは営業テクニックの話になってきますね）

どうやって工数を減らすのか

さて、クライアントの温度感がわかって予算も決まったところで、どう工数を減らしていくのか。

これは経験ありきの部分ももちろんありますが、私が特にPM工数を削減できているポイントを洗い出してみました。

テンプレートの流用

まずはプロジェクトスタート時の工数削減。
これまでに大小さまざまなプロジェクトを経てきたからこそできる準備ではありますが、過去に必要となった資材をテンプレートとしてすぐ使えるように準備しています。（以下例）

• 工数見積もり表
• WBS、ガントチャート
• 進捗管理表
• 要件ヒアリング一覧
• 機能一覧、ユースケース一覧
• 基本設計、詳細設計書、テスト仕様書
• クラウドサーバー構成
• アプリケーション構成

それらを、対象のプロジェクトで必要な工程に応じてセットアップして使いまわしています。

管理・連絡ツールの一元化

使用ツールもクライアントに合わせ始めるとキリがないくらい増えていくもの。セキュリティ的な事情で決まったツールしか使えない企業も多いですが、それらを踏まえてもクリアできそうな妥協案でツールはいくつかに絞るようにしています。

そうすることで、お互いあちこちツールを徘徊して確認する必要をなくしたり、後から情報を見つけやすくすることで細かい工数を削減します。

権限範囲の移譲

あくまで顧客窓口と全体進行に集中するため、エンジニア・プログラマが考えられる仕様策定などはあまり口を挟まずメンバーにお任せします。
お願いするメンバーのスキルセットにもよりますが、細かい仕様調整もできるメンバーであれば直接クライアントとやりとりしてもらいます。

PMとして状況把握はしておくし、いつでもフォローに入れる体制にはしておくけれど、つきっきりで一緒に検討することはしません。

絶対に握らなければいけない仕様レビューのみPMとして確認し、コードレビューなど内部的なことはメンバーに任せられる体制を整えます。

適切な期間で設定された定例MTG

最後に最近工数を減らせたと感じているのはMTGです。そもそも予算が少ないプロジェクトなので、あまりに細かくMTGしなければいけないほどの大規模なシステムであることは少ないです。

定例MTGというと、なんとなくで週1、とか決めてしまいそうになりますが、毎週大きな進捗もないのに1時間拘束されるのは意外と無意味です。

システム規模に必要な範囲で、隔週であったり10日ごとであったり、プロジェクトに合う設定をしています。

ただ、MTGが少ないことで別のリスクが潜在化されることは避けなければいけません。私は特に以下には気をつけています。

• テキストコミュニケーションは常に身近に感じられるよう即レス
• いつでも相談できるよう音声チャットやテレビ会議ツールのURLを共有
• 何してるの？で不安にさせないようslack等のステータス設定
• 進捗があればその都度すぐに管理ツールにも現状をアップデート

誰にとって、どんな風に良いのか

このように、私はなるべく自分のプロジェクトマネジメント工数を垂れ流さないように意識しています。
振り返ってみると、この体制は自分に余裕ができるだけでなく、多方面で良い影響があるんじゃないかと思うんです。

クライアント企業

• PM1人月まるまるではなく、本当に必要な分の稼働に対してのみ報酬支払いとなるのでコストを削減できる
• お金だけ払ってやってもらうことがない、等のリスクから逃れられる
• 予算を超えてしまう怖さがなく範囲内で安心して併走できる

プロジェクトマネージャー

• 1つのプロジェクトに割く工数を減らしつつ、パフォーマンスを凝縮できる
• 複数プロジェクトを並行し、動ける案件を多くできることで経験値が溜まる（そしてまた横展開できる）
• 作業タスクに追われることがないのでリスク検知されたらすぐにフォローに入れる
• 何より、仕事やプライベート全体に余裕ができる

チームメンバー

• 権限移譲がうまくいくと、チームが自走してみんな仕事が楽しくなる
• クライアントと「一緒に」進めている意識ができる
• 専門技術の領域だけじゃない経験ができるので新たな得意が見つかったり、キャリアの幅が広がる
• PMに余裕があるのでリスクが発覚した時にすぐ相談して助けを求められる
• 予期せぬ自体が発生しても「予算」優先でコトが進むので無理難題をやることになりにいくい

チームは専門家の集まり

私の好きな言葉のひとつに「餅は餅屋」という表現があります。

何事においても、それぞれの専門家にまかせるのが一番良いということのたとえ。また、上手とは言え素人では専門家にかなわないということのたとえ。

故事ことわざ辞典

プロジェクトチームを作る上で、PMを含めたチームメンバーそれぞれには必ず得意・不得意があるはずです。（もしかしたらスーパー最強なフルスタックPMエンジニアもいるかもしれないですが稀でしょう・・・）

1人が時間をかけて不得意領域を頑張るより、それを得意としているメンバーが担当したほうが時間も費用も削減できます。
なので、私はいつもそれを意識してチーム編成を考えることが多いし、進める上で「あ、これは自分がやらないほうがいいな」と思うことは潔く手を引きます。

例えば私はワイヤーフレームとか手書きでバーっと描くところまでは早いし好きですが、それをAdobeツール使ってデータ化するのは苦手です。
そこまでできていたら、専門家であるデザイナーにお願いしたほうが早い。ここで私が無理して頑張る時間は、無駄に予算を使ってしまうかもしれないし、誰も幸せじゃありません。

そういった、誰のためにもならないけどこだわって時間がかかってしまうような作業って色々あると思いますが、予算も時間も有限です。
限りがある中で、一番実りある成果を出せるよう、これからも日々マネジメントを考えていきたいです。