システム開発におけるプロジェクトマネージャーの三種の神器は、スケジュール・体制・進め方の3つです。この3つを見るだけで、プロジェクトの危険度がある程度分かります。中でもチーム構成と役割を決める体制は、システム開発プロジェクトの成否を左右する重要なものです。システム開発プロジェクトでは、プロジェクトリーダー、プロジェクトマネージャー、サブプロジェクトマネージャーなど、会社の役職の序列に従ってポジションを用意していたり、PMが二人いたりして、いったい誰が責任者なのか分からないことがあります。 また、チーム構成がとられておらず、いわゆる文鎮型の体制もよく見ます。
この記事では、体制を見るだけで危険なプロジェクトを判定できるポイントと、よりパフォーマンスをあげるための体制上のアイデアについて記載します。
かんたんイラスト（記事を読む時間のない人へ）
危険な体制とは
あなたが参画しているプロジェクトの体制図を見てください。下記の一つでも当てはまるものがあれば、そのプロジェクトは危険です。
１．プロジェクトマネージャー周辺の責任があいまい
プロジェクトのマネジメント層に沢山の人がいることがあります。例えば、プロジェクトリーダー、プロジェクトマネージャー、サブプロジェクトマネージャーがいて、さらにプロジェクトマネージャーが2名併記されている。加えてプロジェクトマネージャーの取り巻きとしてPMOチームが存在し、そのPMOにもリーダーが存在する。これでは、各自の役割もあいまいで責任範囲も不明確です。大企業のプロジェクトではたまにありますが、ハレーションが起きないように体制図上には名前を記載しておくけど、実態として責任者は誰か明確に決まっている、ということであれば良いのですが、役割も責任もあいまいなままだと、相当危険です。このような体制では、例えば、承認を誰がするのか、相談をどこまで持ち上げるのかが不明確になりがちで、報告回数が増えるだけでなく、相談や承認のための資料作成にもそれなりの稼働が必要となり、とても効率が悪いです。また、判断に時間がかかるため、プロジェクト運営が後手後手に回る危険性もあります。
２．チーム名が抽象的
そもそもチーム構成が定義されていない体制図は話になりません。俗にいう文鎮型の体制です。プロジェクト規模や開発手法によっては良いこともあるので一概に駄目なこともないのですが、非効率な面はあります。一般的に、1人のリーダーがしっかり見られるのは3～5人程度と言われていますので、10名以上のプロジェクトとなれば、当然、複数のチームで構成されているべきです。そのチーム名を見て、各チームがどういうミッションで何をやるチームかわかりますか？
日本の会社には、第一営業部や製造第二部など数字を使った部署名が普通にありますが、このような意味のない数字の部署名は、社内の人間であれば分かるかもしれませんが、社外の人にとっては全く分からないでしょう。
システム開発におけるプロジェクトの体制図についても部署名と同様で、例えば、チーム名が「開発Aチーム」「開発Bチーム」など意味を持たない名称がついている場合は危険です。これでは、各チームがどのような役割かわからないですので、監査報告、ステアリングコミッティ、マネジメント報告会や新規参画者のオリエンテーションなど、イベントの度にプロジェクトの全体像をいちいち説明しないとならず非効率です。
また、チーム間の役割分担も不明確になりがちで、チームメンバーも担当領域があいまいなまま開発を行うことになりかねません。
３．メンバーに役割名が付いていない
中規模以上のプロジェクトとなると一つのチームに10名以上のメンバーがいることもあります。実態としてサブチームやセルといった単位で体制が構造化されていれば問題ないのですが、単にメンバーを羅列している場合は危険です。一人ひとりの役割がわからないと、他チームの人から見ても個々人がどういう役割で何が得意かもわからないですし、もしも新規参画者が入った場合も同様に、不明点を誰に聞いたら良いかわからないことになり効率的ではありません。また、メンバー自身も責任の自覚を明確に持てないので、モチベーション面でも懸念があります。
パフォーマンスを上げる体制上のアイデア
前述の体制上の危険なポイントに対して、不安要素を解消して、さらに個々人のパフォーマンスを引き上げるためのアイデアを４つ挙げます。
１．カウンターパートを決める
責任者問題は、いつの時代も多くの会社でよく聞かれる問題です。沢山の人がプロジェクトのマネジメント層に名を連ねていることが必ずしも悪いわけではなく、責任があいまいな事が良くないのです。良くない理由の一つは、報告が増えることにより非効率となること。もう一つは、責任を負っていない人は無責任に言いたいことを言う状況になりがちだからです。クライアント企業の意見の相違は、クライアント側でまとめてくれればよいのですが、システム開発会社側の責任があいまいなのは、開発品質を下げる要因にもなるので、よくありません。開発の状況を考えずに出来もしないことに対して「やります」と言ってしまったら、後から訂正するとしても面倒ですし、無駄な稼働が発生します。これを解消するためには、システム開発会社側のマネジメント層も責任を明確にすることが必要ですが、この責任の明文化は意外と難しいです。責任を分かりやすくするアイデアとしては、システム開発会社の体制とクライアントの体制を紐づけてカウンターパートとなる相手を決めてしまうのも一つの手です。例えば、クライアント側のプロジェクトリーダーの発言には開発PMが応える、クライアント側のリーダーの上司である部長の発言には、開発側もPMの上司が受け答えするなど、カウンターパートを決めてしまうことで、自ずと責任が明確になっていきます。
２．分かりやすいチーム名を付ける
分かりやすいチーム名を付けることは、プロジェクト全体にとっても大切です。では、チーム名にはどのような名前を付けたらよいのでしょうか。システム開発プロジェクトにおいてチーム名を付ける簡単な方法は、機能分類か工程、あるいはその組み合わせが分かりやすいです。例えば、主な機能分類として「フロントエンド」「バックエンド」「管理機能」があれば、その機能分類に工程を組み合わせて、「フロント設計チーム」「バックエンド開発チーム」「管理機能テストチーム」のようなチーム名になります。
このようなチーム名だと、外部の人もマネジメントも体制図を見ただけで、いまプロジェクトでは何をやっているのか、誰がどの機能領域のリーダーか一目でわかります。また、分かりやすいチーム名は、チームで達成すべき目標が明文化されるため、そのチームに属する人は自分のミッションを自然と自覚できますし、他チームとの役割も明確になるので、プロジェクト全体としてプラスの効果が生まれます。まさに、名は体を表すです。
３．個々人にも役割名を付ける
分かりやすいネーミングによる効果は、チーム名だけでなく個々人の役割にも使えます。例えば、オンラインショッピングサイトの開発プロジェクトだと、フロントエンド設計チームの中でも、ショッピングカート担当、決済サービス担当など、バックエンド開発チームにはリコメンド担当など、出来るだけ個々人にも役割を明確に与える方が良いです。その個々人の役割を体制図上の個々人の名前の後に(決済サービス担当)とか記載して、チーム内における個々人の役割を強く認識させましょう。役割が明確になると他人から必要とされる存在意義を感じられるため、自然と責任感を持つようになり無意識のうちにパフォーマンスが上がる効果も期待できます。
４．チーム横断的な観点で役割名を付ける
大規模プロジェクトになると、例えばショッピングカート担当とはいえ複数人いることがあります。そのような場合でも、なるべく多くの個々人に責任感を持ってもらうためのアイデアはあります。それは、複数のチームを横断するような共通的な機能や重要な観点の役割を与えるのです。以前かかわったプロジェクトでは、大臣と名付けて役割を与えていました。例えば、
金額大臣：金額に関する項目(算出方法や利用箇所)の把握・整合性を取る責任者
金額大臣は、そのシステムで扱う金額に関する全ての項目に責任を持つ役割です。例えば、前述の例のオンラインショッピングサイトであれば、金額に関する項目は、チームを横断して、カートでも決済でも使いますし、バックエンドの支払い処理などでも扱い、しかも算出方法もそれぞれ異なります。金額は非常に重要で神経質に扱う必要があるため、金額に関する整合性を担保するための責任者を任命しました。テストケースレビューや追加開発や仕様変更で金額項目に影響する場合は、必ず金額大臣のレビューをするルールとしていました。
性能大臣：機能設計や開発における性能観点の相談役
性能大臣は、設計や実装の段階で性能に関して相談・レビューする役割です。システム開発において性能試験は、終盤に行われることが一般的ですが、性能が重要な要件となるシステムの場合は、設計や開発・単体テストの工程から性能を担保することを考えなければなりません。とはいえ、性能のチューニングには、アプリ・SQL・DBなど幅広い分野の知識が必要となり、設計者や開発者全員がそのスキルを持っていることはありませんので、性能面に精通しているエンジニアを性能大臣に任命して、設計時点から性能観点のレビューや大量件数を扱う機能のコードレビューを行うなど、性能に関しての責任者として役割を持たせました。
この大臣制は、チーム内の役割とは別にプロジェクト全体を見る役割であり、所属チームを超えて横断的な責任者となるため、プロジェクト全体での存在感を実感しやすくなります。その結果、より強い責任感が生まれて、個々人のパフォーマンスはもちろん、プロジェクト全体のパフォーマンス向上にも効果を発揮します。
まとめ
プロジェクトマネージャーは、プロジェクトメンバー全員が最大のパフォーマンスを発揮するように考えることが重要です。システム開発において不明瞭な役割分担は、検討漏れなど時にトラブルを引き起こします。少しでもそのリスクを減らすためにも、チームの役割を明確にすることが大事で、その一つのアイデアがチーム名や役割名のネーミングの工夫です。プロジェクトメンバー一人ひとりに役割を与えると、個々人がより責任感を持つようになり、その結果、プロジェクト全体のパフォーマンス向上も期待できます。
モチベーション管理や1on1などの活動も大切ですが、チーム名と役割名を明確にするだけで効果はありますので、プロジェクトマネージャーには、ぜひ考えて欲しいと思います。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
