PMが足りない、そんな時はDMを用意しよう

こんにちは、株式会社ispecの島野です。
今回は、弊社で行っている、チームビルディングについて共有してみたいと思います。
弊社では、プロジェクトの責任者としてPMとは別にDM(Develop Manager)を設けています。あまりDMという名前を使っている会社はいないかと思いますが、なぜか弊社ではそのように読んでいます。一般的な名前として近いのは、リードエンジニア・テックリードなどでしょうか？

特に記事を読んでほしい人

開発チームを抱えていて、複数プロジェクトありPMが足りていない会社・団体

PMに求められること

• 機能要件定義
• 信頼関係構築
• 請求業務
• スケジュール管理
• タスク管理
• 技術選定
• 品質管理

などたくさんありますね。どの仕事も経験が豊富で、知見を持ちつつ、感覚として素早く処理をしていく必要があるので、なかなか採用もできないし、教育も難しいというのが実情だと思います。

今回おすすめしたいことは、PMが行っているマネジメント業務の一部をPMから切り出し、PMとは別にDM(Develop Manager)を用意することです。

PM・DMが負う業務のことを、アカウンタビリティと呼んでいます。

オススメするアカウンタビリティの切り分け方

PMのアカウンタビリティ

• 信頼関係構築
• 業務要件定義・機能要件定義のレビュー
• 契約・請求
• 品質管理(テストケース作成・実行)
• スケジュール・タスク管理(全体)

DMのアカウンタビリティ

• 機能要件定義
• スケジュール・タスク管理(エンジニア稼働分
• 品質管理(コードレビュー、テストコード作成・管理)
• 技術選定

アサインするPM・DMの経験・スキルによって、切り分けるアカウンタビリティを変えることは柔軟に行うと良いと思います。
上記のアカウンタビリティのうち、PMとDMでどこが違うの？と思われる部分について、説明します。
参考になる点があれば幸いです。

信頼関係構築

PM業務の中で、重要なものとして、信頼関係構築があると思います。
ある種、プロジェクトに参加するもの、全員に必要なスキルと言えますが、特にPM・DMにフォーカスして考えてみましょう。

メンバーの振る舞い・発言・約束などを把握し、信頼関係を崩さないようにするアカウンタビリティを持つのが、PM。
DMは、エンジニア・デザイナーなどが出すアウトプットに対して期待値を超えられるようなものを出し、このDMなら質の高いアウトプットを出してもらえるだろうという信頼を勝ち得るのがDMと考えてよいと思います。

業務要件と機能要件

業務要件とシステム要件という言葉が出ていますが、私は以下のように理解をしています。

1. 業務要件定義とは、業務フロー(体験の順序)の書き出し・必要な入出力項目の洗い出しを行い、”実現したい体験の方向性” を定める。
2. 機能要件定義は、業務要件を元に、WFなどでビジュアルイメージを作成し、さらに実装方法を考え、尚且つどのようなパフォーマンス(処理速度や、セキュリティ要件)を実現するかを決める。

機能要件定義は、エンジニアやデザイナーではないとイメージが難しいが、業務要件定義であれば非エンジニアであっても担当することができます。業務要件をまとめるというスキルさえ身につければ、技術者ではなくてもできるので、これもPM採用をする上での課題に対する突破口になると言えますね。
PMが業務要件をまとめ、DMが機能要件をまとめた段階で、PMがレビューを行い、どのような体験が実現されるかを確認する。違和感がある場合、それに対して議論を行い、Fixをしましょう。

品質管理

品質管理は、主にQAと呼ばれる作業です。
QAで大切なことは、システムが要件を満たしているか、ということです。

PMがテストケースを作成し、実行することが多いが、これだけでは不十分である。
そもそも、内部ロジックが悲惨で、1箇所の修正を行うと複数箇所に影響が出るようなコードでは、どんなに項目に基づきテストを行っても、バグが一生絶えない状態になってしまう。

PMはテストケースの充実に目を向け、ユーザの想定する動作に対して漏れなくテストケースを作成し、QAチームに依頼をする。
DMはコードレベルでのレビューと、テストコードの管理を行い、コードレベルでの品質担保を行う。後のバグは、PMに任せてしまう。
ただ、コードレベルの品質を管理する必要があるので、バックエンド・フロントエンドなどで開発が別れる場合は、それぞれに1名ずつDMをアサインすることが望ましいですね。

スケジュール・タスク管理

タスクに対してスケジュールを引くので、スケジュール管理とタスク管理は同じアカウンタビリティとして考えてみます。
PMは、全体のスケジュールを管理するのに対して、DMはエンジニアのタスクを管理します。
開発工程の細かい部分についてPMは把握せずに、そこはDMに任せてしまいます。

スケジュールを大きく分けると、
要件定義、デザイン作成、開発、テストなどがあると思いますが、開発部分についてはDMにタスク管理を任せるようなイメージです。
そうすることで、PMは品質管理やクライアントとの期待値調整などに主に時間を使うことができるだけでなく、全体の仕事量も大きく減るので、複数プロジェクトの掛け持ちも可能になってきます。

まとめ

以上、アカウンタビリティの分け方についてでした。弊社でも、これは一例に過ぎないので、実際にはアカウンタビリティの分け方がプロジェクトごとに大きく異なることもあります。PM・DMのスキル・経験に合わせて柔軟に対応していきましょう。
次回は、どのような人がDMになれるのか、DMはどのように教育するのかについて、お話ししたいと思います。