システム開発プロジェクトにおいて部下とパートナーのマネジメントを通してパフォーマンスを上げる方法

~SIerおよびSES会社の経営に役立つ経営理論シリーズ：エージェンシー理論編②~

このシリーズは、入山章栄氏の『世界標準の経営理論』で紹介されたビジネスパーソンが最低限押さえておくべき経営理論のポイントを紹介し、SIer・SES会社をはじめとするシステム開発会社の経営において応用可能な点を考察するものです。

入山氏の解説
エージェンシー理論【解説動画】
人間が合理的だからこそ、組織の問題は起きる

本記事ではこの知見をシステム開発現場のマネジメントをエージェンシー理論のモラル・ハザード問題の観点で考察し、リスクを回避する対応策を解説します。

システム開発会社に関わる関係性をエージェンシー理論で俯瞰する

エージェンシー理論とは？

エージェンシー理論とは、依頼人（クライアント/プリンシパル）が代理人（エージェント）に特定の行為を代行することを前提とした事業活動のフレームワークです。次の表は、システム開発会社のビジネスを、エージェンシー理論にもとづき、依頼人と代理人の関係を整理したものです。

この理論は、プリンシパル（依頼人）がエージェント（代理人）に、システム開発などの任務や業務を代行させる際に生じる、情報の非対称性や利害の相違によって発生する問題点に焦点を当てます。

具体的には、エージェントがプリンシパルよりも任務に関して多くの情報を持っている状況（情報の非対称性）、そしてエージェントが自己の利益を最大化しようとする行動（利害の相違）が、プリンシパルとエージェント間の目標の不一致や「モラルハザード」、「代理問題」などを生じさせます。

エージェンシー理論における、モラル・ハザードとは、プリンシパルとエージェントの関係において、エージェントが自己利益を追求する行動を選択してプリンシパルの利益を損なうことです。

システム開発のビジネスモデルにおけるモラルハザードの例は、次の通りです。

SIerが直面するシステム開発現場におけるモラル・ハザードの問題とは？

システム開発の現場においてモラル・ハザード問題が、どのように発生するのかを説明します。

システム開発業においては、プロジェクト毎に開発の仕事が発生するため、プロジェクトメンバーを社内外から集めてくる必要があります。

まず、同じ社内のエンジニアであっても、一般的なプリンシパルとエージェントの関係は当然成り立ちます。とはいえ、自社の経営理念や、事業部としての目標などを共有している側面もあるため、「目的の不一致」はある程度解消できる可能性があります。

しかし、社外のパートナーからエンジニアを調達した場合、「目的の不一致」を減らすことは困難になります。そもそも社外の人と共通言語を持つためには、会社と会社の間で理念を共有するためにパートナー会社の経営陣や営業も巻き込んでいかなければなりませんが、そこまで実施しているSIerは少ないです。

また、「隠された行動」（契約後の情報の非対称性）については、社内か社外かに関わらず、常に発生する問題です。特にプロジェクト・マネージャーや業務SEなどは、顧客であるユーザーの事務所に伺い、打合せを行うことも多いため、開発現場のエンジニアとのコミュニケーションの時間が十分に取れないという問題もあります。

最近ではリモートワークが普及したことにより、何をしているのか動きが見えない、という問題が以前に増して加速しており、適切なモニタリングのルール作りと運用が必須になっています。

以下では、システム開発業界において「目的の不一致」を解消し、「契約後の情報の非対称性」を解消するために取りうる手段を解説します。

前回の記事において、モラル・ハザードの解決方法として

• 絶対評価
• 相対評価（報酬総額一定）
• 長期的関係に基づいた後払い式
• 一体化

という４つを紹介しましたが、ここでは「相対評価」（報酬総額一定）と、一体化について具体的な利用シーンを交えて解説・提案していきます。

なお、後払い式については、終身雇用や人事異動の裁量権を前提とした正社員との雇用契約で使われるもので、社内のエンジニアに対しては既にある程度使われており、個々のプロジェクト内でパートナーに対しては利用できないことから、本記事では対象外にします。

また、業績のみで報酬を判断するような完全な絶対評価についても、生産性を正確にはかることが難しいシステム開発の現場にはなじまないため、本記事では対象外にします。

SIerがモラル・ハザード問題を回避する方法は？

同じプロパー（正社員）の部下の場合

プロパーの場合は、既にある相対評価を活用した人事評価システムが適切に機能しているかどうかが問題になります。

まず、同じ部署・課の中で複数の部下に対して共通の評価指標を用いて、その相対評価の結果に応じて、部長・課長が報酬の割り振りをできるかという問題があります。

もしも複数の異なる部署において、全て同じ評価指標を使えるのであれば、部署横断で相対評価をした方がより比較対象のサンプルが増え公平性も増すため望ましいといえます。

しかし、会社全体の利害調整等を人事部が一元管理して行う必要があり、表立って従業員に報酬の根拠をすべて説明することができないような操作を加える場合は、「評価」と「報酬」の間に乖離が生じるようなこともあります。

この場合、それぞれの従業員は、日ごろからの上司や人事部とのコミュニケーションにより、ある程度「仕方がない」と納得している状態であれば、理想的です。対して、十分なコミュニケーションがとれず、自分の評価に比べて報酬が少ないという不満を持ち続けている場合は離職防止やモラル・ハザードによる手抜き防止のための対策が必要になります。

結論としては、既存の相対評価・絶対評価の適用対象が妥当かどうかを確認し、相対評価については「成果」にこだわりながらも、全員が努力を続けられるようなインセンティブを与えるために、公平性や納得性を追求していく必要がある、ということになります。

パートナーの場合

相対評価（報酬総額一定）の導入

パートナーに対してはそもそも「評価」の運用がなされていないケースがほとんどです。これは自社内の従業員に対するものではなく、社外に対する評価になるので、一律にやりづらいという事情があります。

しかし、取引額に応じたパートナーのランキングを作成し、多くの貢献をしているパートナーを表彰するといった取り組みだけでは、すべてのパートナーに適切なインセンティブを与えることはできません。

やはり共通の評価基準により、相対評価を目指すことで、より良いパフォーマンスを出してくれるパートナーを正確に認識し、そのパートナーに対して報酬面の改善や委託業務の増加など行うことで、パートナーシップの強化につなげる必要があります。

報酬面の改善については、パートナー全体の報酬総額を変えないまま、パフォーマンスの悪いパートナーについては、要員交代をするか、報酬を減らす交渉を行います。仮に報酬を減らすことができた場合は、相対的にパフォーマンスがよいパートナーの報酬を上げることになります。

このような調整は、パフォーマンスを上げているパートナーの営業担当から値上げ交渉された後に、調整可能な範囲で別のパートナーの単価を下げて、値上げ交渉された分を捻出するといったことが現実になされています。通常は同じプロジェクトの中の別のパートナーで留まることが多いはずです。

これを、同じ部署・課の中で横断的におこない、しかもパートナーからの値上げ交渉の前に仕組みとして実現することで、パートナーからの値上げ交渉幅を抑えることも可能になります。

パートナーからすれば、１つのプロジェクトの中だけではなく、顧客の部署・課や会社全体の中での他のパートナー会社との競争にさらされているということを意識できるため、パートナーにとっての利益のみを追求するといったモラル・ハザードを回避することができます。

相対評価の導入は、SIer業界で一般的となっている140時間～180時間の間は固定の報酬となるような、上下限付きの稼働時間に応じた精算方法による弊害も解消できます。この精算方法は、実質的にSIer側のコストを平準化する目的で使用されているため、固定報酬制度の一種と言えます。上限を超えてエンジニアが働いた場合は、報酬が増えるものの、それが継続すると健康を害するリスクが生じます。

エンジニアとしては

・残業代を稼ぎたければ色々な問題を発見して高稼働にする

・残業はしたくないが課題が多いため仕方なく高稼働になる

・とにかく残業はしたくないため、出来る限り稼働を抑えて全額もらえるようにする

といった複数の事情を抱えている可能性があります。

いずれの場合においても、SIerとしては上限時間（180時間など）までに稼働を抑えてもらいつつ、成果物をあげてもらうことがベストとなります。しかし、個々のエンジニアの行動の全ては観察できず、予算も固定となっている場合がほとんどのため、エンジニアに正しい努力・行動をしてもらうためのインセンティブを与えることが困難です。

そこで、パートナー間の相対評価を導入することで、エンジニアおよびパートナー会社としては、「期限通りに納品できているか」「残業を減らし、コストの抑制に貢献できているか」といった共通の評価指標に関して、よりよい評価をえるための努力を促すことができます。そして「チーム全体の生産性向上に貢献しているか」といった指標も合わせることで、よりよいパフォーマンスを促し、相対評価が高まることで報酬アップや次案件の優先紹介などのインセンティブを与えることもできます。

一体化に近い状態を実現する方法

部署や会社全体でパートナーの相対評価が出来ない場合であっても、個々のプロジェクトマネージャーに出来ることがあります。

プリンシパルとエージェントの垣根を失くすために、関連記事の「婿養子を迎えた同族企業」のやり方を応用できます。

具体的には、パートナーの担当営業に「このエンジニアはうちのエース候補で、是非あなたのもとで学ばせていただきたい」といって送り込んでもらう、という方法になります。

パートナーのエース候補は自社の将来を担っているので、自社の取引拡大という目的をもっていますが、同時に上のような形で紹介されると、顧客のプロジェクトマネージャーと師弟関係を結び、師匠のメリットになることを全力で追求するようになります。例えば、自社の短期的な取引拡大にはこだわらず、長期的な視点で拡大すればよいという覚悟があるため、無理な要員追加の提案などは避けることができたり、自社の体制の中のパフォーマンスが良くないメンバーに関して責任を持ってフォローするようになります。

また、パートナー会社はエース候補の人材をじっくり育てようとするため、簡単に異動になることもありません。SIerのプロジェクトマネージャーにとって、自社のプロパーの部下で、人事部や開発本部に人事権を握られていて簡単に異動になってしまう場合よりも、パートナーのエンジニアの方が安定してついてきてくれる可能性が高まります。

したがって、SIerとしてはこのような「うちのエースで、是非あなたのもとで学ばせていただきたい」と言ってもらえるような人をどれだけより多くのパートナー会社から提案してもらえるかが長期的な視点での競争優位の源泉になります。このような関係は、パートナーからすると他の顧客にも何回も言えるような内容ではないため、競合のSIerも簡単には真似のできない人間関係を構築できることになり、持続可能な競争優位につなげることができるといえます。

では、このような関係性を実現するためにはどうすればよいのでしょうか。

比較対象として、パートナーの担当営業がエンジニアの紹介の際に「うちのエースですが、引く手あまたなので、いつ提案できるかはわかりません」と述べた場合を想定すると違いが見えてきます。SIer側がこのような紹介を受ける前にパートナーとの間で取引を積み重ねており、パートナーと一緒に修羅場も乗り越えており、SIer側が良いマネジメントをしていたかどうかが重要になります。過去に良いマネジメントをしていればエース人材を紹介されるし、杜撰なマネジメントであればエース人材を紹介される可能性は下がります。

これを実現するためには、逆説的ではありますが、重要なプロジェクトであればあるほど、既存のパートナーだけではなく、新規パートナーも意識的にいれるようにして、その新規パートナーのエンジニアに対してはマネジメント上ベストを尽くすことが大事になります。そのエンジニアが実際はマッチング度がそこまで高くなかったとしても、そのアンマッチを乗り越えるためにパートナーの営業といろいろ対策を打つ過程があり、そこでパートナーの営業から信頼を得ることができれば、将来の取引においてエース人材を提案される可能性が高くなります。

対して、既存パートナーのみを相手にしている場合、既存パートナーとしては既にある程度取引の規模があるため、エース人材を採用できたとしても、新規の別の顧客との信頼獲得を優先してしまい、そもそも既存プロジェクトには提案してこない可能性があります。（もちろん、既存の体制の中のリーダーが抜けるなどの事情があれば、エース級のエンジニアを後任として育てることはあります。）

したがって、SIerのPMとしては、自身の日ごろからパートナーのマネジメントはベストを尽くし、自身の将来のより重要なプロジェクトでエース級を提案されるように準備をし、実際にエース級の片腕を社外に持てる機会があれば、今度は自身が転職をしてもそのままついてきてくれるような人を作り上げることが自身の成長にとっても、会社の業績向上にとっても重要になります。

戦略的な丸投げ

上記のプリンシパルとエージェントの一体化という方法と併用できる手段として「戦略的な丸投げ」が考えられます。

SIerに対してパートナーへの「丸投げ」が批判されたりすることもありますが、本来は特定の業務を委託しているので「丸投げ」は当然のことです。おそらくプロジェクトマネジメントなどの管理業務についても丸投げにしてしまうケースが問題となりますが、プロジェクトマネジメントに関しても委託対象に含めてしまえば、必ずしも丸投げが問題だとはいえません。

そもそも準委任契約をおこなう場合は、請負契約と同様、業務を委託しているため、開発メンバーの管理はパートナーの業務遂行責任者が行うことになり、むしろ「丸投げ」しなければならない側面もあります。

また、モラル・ハザードが発生する原因の一つに「隠れた行動（契約後の情報の非対称性）」があり、その解決のための基本的な考え方として「モニタリング」がありますが、これを実行するにはコストがかかるという問題がありました。

参照） エージェンシー理論におけるモラルハザード問題とは？ Ver.4

しかし、パートナー企業に対して準委任契約による業務委託ができれば、各開発メンバーのモニタリングは法的にも丸投げしなければならなくなり、モニタリングを実行するコストも最低限に抑えることができます。

つまり、プリンシパル（SIerのPM）とエージェント（開発メンバー）の間に仲介をする者（パートナー会社の業務遂行責任者）を立てることで、モニタリングがやりやすくなります。

ここで、重要なのは、パートナー会社の業務遂行責任者がしっかりとモニタリングをしてくれるかどうか、という点になりますが、ここで前述の「一体化」ができていれば業務遂行責任者が自分と同じ目線に立って、質の高いモニタリングも行ってくれるようになります。

このように、SIerとしてマネジメントする対象を開発メンバー全体ではなく、一部の業務遂行責任者（リーダー）のみにしてモニタリングコストを下げつつ、業有無遂行責任者のインセンティブ設計は手厚く行う、という状態が実現できていれば「戦略的な丸投げ」として肯定的に捉えべきだと言えます。

逆に「一体化」が実現できないような場合は、「相対評価（報酬総額一定）」を検討する必要があります。

パートナーに対して適切な評価を継続的に行うためのシステム開発業界向けのサービス

モラル・ハザードを回避するためには「インセンティブ設計」と「モニタリング」を通して、エージェントに対して「適切な評価」を与え続けることが大事になります。

また、「リスクとインセンティブのトレード・オフ」制約や、流動性制約を踏まえても、全てのパートナーに対して共通の評価指標で相対評価を可能にしたり、他の現場に逃げ道があるという状態を少しでも減らす必要があります。

そのためにはまず適切な評価を確実に継続するための仕組みが必要です。

これを実現するためには、スフィアネット株式会社が提供するAperport（アペルポート）が役に立ちます。

https://aperport.com/

AperportはSESや派遣契約を締結した後のサービスに対する評価を自動化する仕組みにより、会社間でPDCAを回すためのコミュニケーションを促したり、エンジニアに対して目的の共有やそれを達成するためのインセンティブを促すきっかけを作ることができます。

また、定期的に行われるモニタリングの結果が将来のエンジニアとプロジェクトのマッチング度に影響するため、エンジニアとしては自身が宣言したスキルレベルに対して顧客から適切な評価をもらうようにするため、オフラインでの自発的な報告・情報共有も期待することができます。

そして、相対評価を行うためのデータを用意することができます。

相対評価を行うためには、スキルレベルの異なるものを比較してしまうと不公平感がでてしまうため、同じようなレベルの人の間で比較する必要があります。Aperportの評価は、個々のプロジェクトのポジションごとに求められているレベルに応じてパートナー会社のサービスの品質を評価する仕組みであるため、同じ土俵にのせて評価したデータの蓄積が可能になります。

他方で、パートナーの担当営業からすると、定期的にフィードバックを返してくれる顧客はあまりいないため、仕組み化されたシステムでフィードバックを得られれば自然と有望なエンジニアを提案したいという動機を醸成することができます。

興味のある方はこちらよりお問い合わせください。