クラウド資格は開発会社選びの材料になる？見てよい範囲・見てはいけない範囲

「AWS資格保有者が在籍しています。」——提案書の定番だ。学習意欲の信号にはなる。だが本番の設計責任・障害対応・体制の代替にはならない。

資格をゼロ評価する必要もない。使い方を間違えないことが大事だ。

資格は下限の参考。選定の本体は、制約付き事例と誰が実務に入るかだ。

結論：使ってよい／いけない

使ってよい	見てはいけない（主根拠にしない）
チームに基礎知識があるかの下限	資格数が多い＝安全
学習文化のヒント	個人の合格＝案件の設計責任者
会話の入口	資格だけで他社より高い見積もりを正当化

赤旗

• 提案の大半がバッジ画像
• 合格者と実アサインが別と明示されない
• 障害・移行の失敗談がなく、資格話だけが詳しい

代わりに聞く質問

1. 同種制約（規制・規模・移行）での役割は何か
2. 本番障害の一次とエスカレーションは誰か
3. 資格者は週何時間この案件に入るか
4. アカウントと権限の設計責任は社内／貴社のどちらか

事例

匿名化した一例。資格保有を重視して採択。実作業は別チームで、レビューも薄い。本番前に権限設計の穴が発覚し、別ベンダーが入り直した。分岐点は「誰がこの案件に名前で入るか」を契約に書けなかったことだ。

別の一例。資格は参考に留め、移行の失敗事例と再発防止を深掘りして選定。単価は中位だったが、手戻りが少なかった。

判断軸

資格を加点してよい	無視して他を見る
基礎知識の下限確認として使う	提案の主根拠が資格だけ
アサインとセットで説明がある	合格者と実務者が分離したまま

次に確認すること

1. 資格者とアサインは同一か
2. 制約付き事例を聞けたか
3. 障害対応の体制は書いたか
4. 資格を必須条件にしすぎていないか
5. 見積もりの差を資格で説明させていないか

まとめ

クラウド資格は悪くない。悪くなるのは、選定の主語にしたときだ。下限として見たあと、すぐに事例とアサインの話に戻す。

---

開発会社選びの相談は、お問い合わせフォーム からどうぞ。