部署ごとにバラバラだった開発会社の評価基準をチームで統一する

「Aさんが選んだベンダーは信頼できるが、Bさんが選んだベンダーはよく分からない」。100〜300人規模の会社で情シスチームが複数人になると、こうした感覚のズレが表面化してきます。ひとり情シスの時代は、発注判断の基準がその人自身の経験と勘の中にあり、それで十分機能していました。しかし担当者が2〜3人に増えると、同じ「良いベンダー」という言葉が、人によって指している基準がまったく違うという状態が生まれます。ある人は価格の安さを最重視し、別の人は過去の実績を重視し、また別の人は対応の速さを重視する。この基準のばらつきは、発注の質を不安定にするだけでなく、後から「なぜこのベンダーを選んだのか」を説明できなくなるリスクを抱えます。このガイドでは、部署・担当者ごとにバラバラだった開発会社の評価基準を、チームとしてどう統一していくかを具体的な手順で解説します。

なぜ評価基準の統一が必要になるのか

評価基準がバラバラなまま複数人体制を続けると、いくつかの実務上の問題が発生します。

1つ目は、選定結果の説明責任を果たせなくなることです。経営層や他部署から「なぜこのベンダーに決めたのか」と問われたとき、担当者の主観的な印象だけでは説得力のある説明ができません。100〜300人規模になると、システム関連の投資額も大きくなり、説明責任を求められる場面が増えてきます。

2つ目は、担当者によって選定の質にばらつきが出ることです。経験豊富な担当者は自然と多角的な視点で評価できても、経験の浅い担当者やチームに加わったばかりのメンバーは、何を基準に評価すればよいか分からず、表面的な情報(価格や見た目のよいプレゼン資料)だけで判断してしまうリスクがあります。

3つ目は、過去の選定結果を将来の判断に活かせないことです。評価基準が統一されていないと、過去にどのような基準でベンダーを評価し、どういう結果になったかを比較可能な形で蓄積できません。同じ失敗を繰り返すリスクが高まります。

評価基準の統一は、特定の「正解」を押し付けることが目的ではありません。誰が評価しても、同じ土俵で比較できる状態を作ることが目的です。

ひとり情シス時代の「勘」を評価基準に翻訳する

評価基準をゼロから作ろうとすると、大掛かりな作業に感じられ、着手をためらってしまうかもしれません。しかし実際には、ひとり情シスとして培ってきた「勘」の中に、評価基準の土台になる要素がすでに含まれていることがほとんどです。ゼロから理論的に作るのではなく、これまでの経験を言語化するところから始めると、着手のハードルが下がります。

具体的には、次のような問いを自分自身、あるいはチームメンバーに投げかけてみることが有効です。

• これまで「良いベンダーだった」と感じた案件で、実際に何が決め手になっていたか
• 逆に「失敗した」と感じた発注で、事前に見抜けたはずのサインは何だったか
• 発注前の商談や見積もりの段階で、無意識にチェックしていたポイントは何か

こうした振り返りを通じて出てきた要素を、前述の5軸(技術力・実績・コスト・対応・継続性)に当てはめて整理していくと、実務に根差した評価基準ができあがります。理論先行で作った基準よりも、実際の経験から抽出した基準の方が、チームメンバーにとっても納得感を持ちやすいという利点があります。

この作業は、ひとり情シスの時代に個人の頭の中にあった暗黙知を、チームで共有できる形式知に変換する作業そのものでもあります。評価基準の統一は、単に発注判断を効率化するだけでなく、これまで属人的に蓄積されてきた経験・知見をチームの資産として引き継いでいくプロセスでもあると捉えると、その意義がより明確になります。

評価基準を設計する前に整理すべきこと

評価基準を作る作業に入る前に、まず整理しておくべきことがあります。それは「何のために発注するのか」という発注の種類ごとの分類です。100〜300人規模の会社が発注する開発案件は、性質が大きく異なるものが混在しています。

• 新規システム開発: ゼロからの構築、あるいは大規模な刷新。金額も大きく、長期的な関係になりやすい
• 既存システムの保守・運用委託: 継続的な関係で、対応の安定性や信頼性が重視される
• 小規模な追加開発・改修: スピードとコストのバランスが重視される、単発性の高い案件
• SaaS導入時の導入支援: ツール自体の選定とベンダーの支援品質の両方が絡む

これらを同じ評価基準で測ろうとすると、無理が生じます。新規システム開発では技術力や提案力が重要になる一方、保守・運用委託では対応の安定性や連絡の取りやすさが重要になるというように、案件の性質によって重視すべき項目の重みは変わります。評価基準を統一するというのは、すべての案件に同じ基準を機械的に当てはめることではなく、案件の種類ごとに「共通の評価項目セット」を用意し、その中で重みづけを変えられるようにすることを意味します。

評価項目の設計:5つの軸で整理する

評価基準を具体的に設計する際は、次の5つの軸に分けて考えると、抜け漏れなく整理できます。

この5軸それぞれに、5段階程度のスコアリング基準を設けることで、担当者の主観に左右されにくい評価が可能になります。例えば「技術力・提案力」であれば、次のようなスコアリング基準が考えられます。

• 5点: 要件を深く理解した上で、独自の改善提案がある
• 4点: 要件を正確に理解し、妥当な提案をしている
• 3点: 要件通りの対応はできるが、提案性に乏しい
• 2点: 要件の理解に不安があり、確認のやり取りが多く必要
• 1点: 要件を誤解したまま提案してくる

こうした基準を言語化しておくことで、評価する担当者が違っても、大きくズレのないスコアがつけられるようになります。もちろん完全に主観を排除することは不可能ですが、「なんとなく良さそう」という印象評価から、「この項目でこの点数をつけた理由はこれ」という説明可能な評価へ移行できる点が重要です。

スコアシートの作り方と運用フロー

評価項目を整理したら、実際に使うスコアシートに落とし込みます。シートには次の要素を含めるとよいでしょう。

1. 案件名・発注種別(新規開発/保守委託/小規模改修/導入支援)
2. 評価対象ベンダー名(相見積もりの場合は複数列)
3. 5軸それぞれのスコアと、スコアの根拠となる具体的なコメント
4. 総合スコア(単純合計、あるいは案件種別に応じた重みづけ後の合計)
5. 評価者名と評価日

このシートは、評価者1人だけで完結させず、複数人でクロスチェックすることをお勧めします。100〜300人規模の情シスチームであれば、案件を主担当する1人がまず評価を記入し、もう1人が別視点でレビューするという二段階の運用が現実的です。1人だけの評価では、どうしても個人の好みや過去の付き合いといったバイアスが入り込みやすくなるためです。

スコアシートの運用でよくある失敗は、「作ったはいいが実際には使われない」というパターンです。これを防ぐには、発注の意思決定プロセスにスコアシートの記入を必須の手順として組み込むことが有効です。例えば、SOW（作業範囲記述書）の承認申請の際に、スコアシートの添付を必須とするようなフローにしておけば、形骸化を防ぎやすくなります。

案件の性質による重みづけの調整

前述の通り、案件の性質によって重視すべき評価軸は異なります。新規システム開発と小規模な追加開発を同じ重みで評価すると、実態に合わない結果になりかねません。案件種別ごとの重みづけの目安を、次のように設計しておくとよいでしょう。

• 新規システム開発: 技術力・提案力を最重視(重み高)、実績・信頼性も重視。コストは重要だが最優先ではない
• 保守・運用委託: 対応・コミュニケーションと継続性・保守体制を最重視。技術力は最低限の水準を満たしていれば十分
• 小規模な追加開発: コスト・契約条件とスピードを重視。実績の重要度は相対的に下がる
• SaaS導入支援: 対応・コミュニケーションとコストのバランスを重視。技術力はツール自体の機能に依存する部分が大きい

この重みづけをあらかじめチームで合意しておくことで、案件ごとに「今回は何を優先すべきか」を毎回議論し直す手間が省けます。ただし、重みづけの設計自体は一度決めたら固定するものではなく、実際の運用を通じて「この重みづけだと実態と合わない」という気づきがあれば、定期的に見直すべきものです。

相見積もりでの評価基準の使い方

評価基準を統一する効果が最も分かりやすく表れるのが、複数の開発会社から相見積もりを取る場面です。相見積もり自体は多くの会社が実施していますが、評価基準がバラバラだと、結局「一番安かったから」「担当者の印象が良かったから」という単純な理由で決めてしまいがちです。

統一された評価基準を使う相見積もりでは、次のような手順を踏みます。

1. 案件の発注種別を確定し、対応する重みづけを適用したスコアシートを準備する
2. 各社への要件説明・質問対応の内容を可能な限り揃える(説明の質にばらつきがあると、提案内容自体の比較が不公平になる)
3. 各社の提案・見積もりを受領後、複数人でそれぞれ独立にスコアを記入する
4. スコアをすり合わせ、大きく割れた項目があれば理由を議論する
5. 総合スコアと、金額・納期などの定量情報を並べて最終判断を行う

ここで重要なのは、スコアが割れること自体は問題ではないという点です。むしろ、担当者によって評価が割れる項目こそが、チームとして議論すべき論点です。例えば技術力の評価が割れた場合、単に個人差ではなく、提案書のどの部分をどう解釈したかという認識の違いが背景にあることが多く、その議論を通じて評価基準の言語化がさらに精緻になっていきます。

また、相見積もりを取る社数についても、チームでの目安を決めておくとよいでしょう。案件の規模が大きいほど比較検討の重要性は増しますが、社数を増やしすぎると各社への説明対応や評価の工数が膨らみ、チームの負荷が高まります。新規システム開発のような大型案件では3社程度、小規模な追加開発では既存の付き合いのあるベンダーへの直接依頼で済ませる、というように案件規模に応じた社数の目安を決めておくことが現実的です。

部署間で評価基準への合意を得るプロセス

100〜300人規模の会社では、システム発注の判断に情シス以外の部署(利用部門・経営企画・経理など)が関わることも多くなります。評価基準を情シスチーム内だけで決めてしまうと、他部署から「その基準は現場の実情を反映していない」という反発を受けることがあります。

これを避けるためには、評価基準の設計段階から、主要な利用部門の意見を取り入れるプロセスを組み込むことが有効です。具体的には次のような進め方が考えられます。

• 評価基準のドラフトを作成した段階で、直近1〜2年でシステム発注に関わった主要部署にレビューを依頼する
• 特に「対応・コミュニケーション」の軸については、実際にベンダーとやり取りする現場担当者の声を反映する
• コストの評価基準については、経理・財務部門と目線を合わせておく(見積もりの妥当性の判断基準が情シスと経理で食い違うことがあるため)

このプロセスを経ることで、評価基準が情シスだけの「内輪のルール」ではなく、全社で合意された発注判断の物差しとして機能しやすくなります。特に金額の大きい新規システム開発では、経営層の承認を得る場面でも、この合意形成のプロセスを経た評価基準を提示することで、説明の説得力が増します。

評価基準とベンダーへのフィードバックの関係

評価基準を導入すると、選定されなかったベンダーへの対応も変わってきます。評価基準が明確であれば、不採用となったベンダーに対しても、具体的な理由を伝えることが可能になります。

「今回は他社の提案がより要件に合致していたため」といった曖昧な説明ではなく、「技術力の評価は高かったが、保守体制の説明が具体性に欠けていた」というように、評価項目に基づいた具体的なフィードバックを行うことで、ベンダー側にとっても次回の提案改善につながり、結果的に自社にとっても今後の相見積もりの質が上がるという好循環が生まれます。

ただし、フィードバックの内容は社内の評価シートをそのまま開示するのではなく、要点を整理した上で伝えることが望ましいです。評価シートには他社との比較コメントなど、対外的に出すべきでない情報も含まれるため、共有する範囲は事前にチームで決めておく必要があります。

過去の発注実績データを評価に活かす

評価基準を統一する取り組みは、新規のベンダー選定だけでなく、既存ベンダーとの関係を評価し直す場面でも活用できます。100〜300人規模の会社では、複数のベンダーと並行して取引しているケースが多く、それぞれのベンダーのパフォーマンスを定期的に比較評価することで、契約更新の判断材料にもなります。

このとき重要なのが、選定時のスコアシートと、実際の稼働後のパフォーマンスを紐づけて記録しておくことです。選定時には高い評価をつけたベンダーが、実際の対応では期待を下回るということは珍しくありません。逆に選定時のスコアは平均的だったベンダーが、長期的な関係の中で高い信頼を積み上げていくこともあります。

• 選定時のスコアと、稼働後6ヶ月・1年時点での実際の評価を並べて記録する
• スコアと実態がズレた場合、その原因(評価基準の甘さ、案件特性の見落としなど)を振り返る
• 振り返りの結果を、次回の評価基準の見直しに反映する

この振り返りのサイクルを回すことで、評価基準そのものの精度が徐々に上がっていきます。評価基準は一度作って終わりではなく、実績データを踏まえて継続的に改善していくものだという認識を、チーム全体で共有しておくことが大切です。

評価をチームに定着させるための工夫

どれだけ精緻な評価基準を作っても、チームメンバーがその意義を理解し、日常的に使わなければ意味がありません。定着させるための工夫をいくつか紹介します。

まず、評価基準を作った直後に、実際の過去の発注案件を題材にして、チーム内で評価の練習をしてみることが有効です。同じ案件を複数人でそれぞれ評価してみて、スコアにどれくらいズレが出るかを確認します。大きくズレる項目があれば、その項目の評価基準の言語化が不十分である可能性が高く、基準そのものを見直すきっかけになります。

次に、評価シートの記入を「面倒な追加作業」ではなく「発注判断を後から振り返れる資産」として位置づけることです。評価シートがあることで、後任者への引き継ぎがスムーズになったり、契約更新の判断根拠として使えたりするというメリットを、チーム内で共有しておくと、記入への抵抗感が下がります。

評価基準は「ベンダーを採点するための道具」であると同時に、「発注判断のプロセスを後から検証可能にする道具」でもあります。

最後に、評価基準そのものを固定化しすぎないことも重要です。事業のフェーズが変わったり、発注する案件の性質が変化したりすれば、評価すべき項目や重みづけも変わっていきます。半年〜1年に一度は評価基準自体を見直す機会を設け、実態に合わなくなった項目がないかをチームで確認することをお勧めします。

増員フェーズごとの評価基準の育て方

評価基準の統一は、チームの人数規模に応じて段階的に育てていくものだと捉えると、無理なく導入できます。

情シス担当が1人から2人になったばかりの段階では、まずは5軸の評価項目を簡易的に決め、大きな案件だけスコアシートを使ってみるところから始めるのが現実的です。すべての案件にいきなり厳密な評価プロセスを適用しようとすると、日々の業務に追われて形骸化しやすくなります。

3人程度に増えた段階では、案件種別ごとの重みづけを整備し、相見積もりの際のクロスチェック運用を本格化させるとよいでしょう。この頃になると、過去の発注実績もある程度蓄積されてくるため、評価基準と実際のベンダーのパフォーマンスを突き合わせた振り返りも始めやすくなります。

4〜5人規模になり、チーム内である程度役割分担が進んでいる段階では、評価基準の運用そのものを一人の担当者が主管し、定期的な見直しのサイクルを回す体制を作ることが望ましいです。この段階まで来ると、評価基準は単なるチェックリストではなく、チームの発注判断の質を担保する重要な資産として機能するようになります。

いずれの段階においても共通して言えるのは、評価基準を「完璧な状態で最初から作ろう」としないことです。最初は粗くても構わないので運用を始め、実際に使いながら精度を上げていくという姿勢の方が、結果的に定着しやすくなります。

評価基準の運用を止めないための最低限のルール

評価基準を導入した直後は意欲的に運用されていても、日々の業務に追われる中で徐々に運用が緩んでいくことは珍しくありません。運用を止めないための最低限のルールとして、次の2点は特に押さえておくことをお勧めします。

1つ目は、一定金額以上の案件については評価シートの記入を例外なく必須にすることです。「今回は急ぎだから省略しよう」という例外を一度でも許容すると、その後も同様の理由で省略が常態化しやすくなります。金額の閾値をあらかじめ決めておき、それを超える案件では機械的に評価シートを必須とすることで、判断の余地をなくしておくのが有効です。

2つ目は、評価シートの記入を発注プロセスの最後の任意作業にしないことです。発注が決まった後に振り返りとして記入する形にすると、優先度が下がり後回しにされがちです。むしろ、ベンダー選定の意思決定そのものを評価シートに基づいて行う、つまり評価シートの完成が発注承認の前提条件になるようなプロセス設計にしておくことで、記入自体が業務フローの一部として自然に組み込まれます。

よくある失敗パターン

評価基準の統一に取り組む際、実際によく起こる失敗パターンを整理します。

評価項目を細かく作りすぎて、記入自体が負担になり使われなくなった。

評価項目は多ければよいというものではありません。5軸程度に絞り、それぞれをシンプルなスコアリングにとどめることで、継続的に運用できる負担感に収めることが重要です。項目を増やしたくなったときほど、本当にその項目が発注判断に必要かを一度立ち止まって検討する習慣を持つとよいでしょう。

スコアシートを作ったが、最終的な意思決定は結局特定の担当者の一存で決まっていた。

評価シートがあっても、意思決定のプロセスにそれを組み込む仕組みがなければ、形だけのものになってしまいます。承認フローにスコアシートの提出を必須化するなど、プロセスとして組み込むことが必要です。

評価基準を作った担当者が異動し、基準の背景にある考え方が引き継がれなかった。

評価基準そのものだけでなく、「なぜその基準にしたのか」という設計意図も文書として残しておくことで、担当者が変わっても基準の運用がぶれにくくなります。設計意図の記録は、評価シートの冒頭や別紙に数行程度でよいので、必ず残しておくことをお勧めします。

評価基準とチームの役割分担の関係

評価基準の統一は、単独で完結する取り組みではなく、チーム内の役割分担とも密接に関わります。誰が評価シートを記入し、誰が最終的な意思決定を行うのかという役割が曖昧なままだと、せっかく統一した評価基準も機能しません。

現実的な役割分担の型としては、次のようなパターンが考えられます。

• 案件の主担当者: 要件のヒアリングからベンダーとのやり取り、評価シートの一次記入までを担う
• レビュー担当者: 主担当者とは別の視点で評価シートをレビューし、スコアの妥当性を確認する
• 最終承認者: 一定金額以上の案件について、スコアシートと合わせて最終的な発注可否を判断する(チームリーダーや情シス責任者が担うことが多い)

この役割分担が明確であれば、評価基準はチームの意思決定プロセスの一部として自然に組み込まれます。逆に役割が曖昧なままだと、評価シートを作った担当者の判断がそのまま最終決定になってしまい、統一基準を作った意味が薄れてしまいます。役割分担そのものの設計については、チーム全体の体制設計の一部として捉える必要があり、詳細は別のガイドで扱っています。

また、評価基準を運用する中で、案件によっては主担当者が明確な結論を出しにくいケース(複数社が僅差で、最終判断に迷うようなケース)も出てきます。こうした場合にどう最終判断を下すか、判断が割れたときに誰が決定権を持つかというルールも、評価基準とあわせてあらかじめ決めておくと、意思決定が停滞するリスクを減らせます。

評価基準を既存の台帳・一覧と連携させる

評価基準の運用を単独の仕組みとして孤立させず、すでにチームで運用しているベンダー一覧やシステム管理台帳と連携させることで、日々の業務に無理なく組み込めます。

例えば、ベンダー一覧の「過去のトラブル履歴」や「直近のやり取りの要約」といった項目は、評価シートの「対応・コミュニケーション」軸の判断材料になりますし、逆に評価シートで蓄積されたスコアは、契約更新のタイミングでベンダー一覧を見直す際の判断材料になります。2つの仕組みを別々のツール・別々のタイミングで管理してしまうと、せっかく蓄積した情報が分断され、活用しきれません。

理想的には、案件ごとの評価シートと、ベンダーごとの一覧を相互に参照できる形で管理することです。スプレッドシートであれば、シートを分けつつもベンダー名で紐づけられるようにしておく、専用ツールであればタグやリンク機能で連携させておく、といった工夫が考えられます。この連携ができていると、あるベンダーとの契約更新を検討する際に、「このベンダーは過去にどんな評価を受けてきたか」を一目で振り返ることができ、更新判断のスピードと質の両方が上がります。

まとめ

部署ごと・担当者ごとにバラバラだった開発会社の評価基準を統一する取り組みは、100〜300人規模で複数人の情シスチームが機能するために欠かせない土台です。技術力・実績・コスト・対応・継続性という5つの軸で評価項目を整理し、案件の性質に応じた重みづけを設計し、過去の実績データと突き合わせながら基準そのものを継続的に磨いていくことで、属人的な発注判断から、チームとして説明可能な発注判断へと移行できます。評価基準の統一は一度作れば終わりではなく、実際の運用を通じて磨き続けるものだという前提を持つことが、長く機能する仕組みを作る鍵になります。ひとり情シスの時代に培った経験や勘を土台にしながら、チームで共有できる形式知へと少しずつ翻訳していく姿勢こそが、この取り組みを形骸化させずに続けるための一番の近道です。焦らず、小さく始めて育てていく意識を持ちましょう。