費用・ライセンス形態

　ライセンスによってはボリュームディスカウントが効くため、社内の需要を集約して見積もりを出す必要があります。代理店を一カ所に集約し、異なるサービスのライセンスや法人携帯回線などと合わせて金額交渉することも有効です。

　一方、「Amazon Web Services」などの利用では、財務経理部から事業部や子会社ごとに利用分を分けて管理してほしいと要望を受けることがあります。契約前は、想定される請求金額をイメージして各組織と事前に交渉しておくとよいでしょう。

法務チェック

　扱うサービスや監査の状態によっては法務チェックが必要です。私が在籍していた企業は監査法人が厳しく、利用規約のチェックが必須でした。規約によっては文章量が多いものもありますし、海外の規約は読解時間もかかるため、余裕を持ってチェックする必要があります。

　加えてサービス提供企業への反社チェックも必要なケースがあります。過去に、どうしても利用したいサービスが一人しか在籍していない企業により提供されており、企業情報がなくて往生したことがありました。結局、「事業が当該サービスに依存することがなければよい」という理由で特別に許可が降りました。

　事業への影響が大きいサービスの場合、利用するサービスのSLA（Service Level Agreement）やサポート状況もチェックしなければなりません。以前、「Facebook」に依存したサービスを運用しましたが、一時期は頻繁にFacebookのAPIにつながらなくなる障害があり、大きな問題になりました。他に代替案がない場合、プログラムや社内オペレーションで対応する必要があります。

　また、サービスのSOC（System and Organization Controls）報告書が必要な場合もあります。法務や監査部門と連携し、契約前に必要書類が出せるかどうか、出せない場合の妥協点はあるのかどうかを確認しましょう。

セキュリティリスク

　セキュリティサービスを提供する企業であれば入念なチェックが求められがちです。そうでない場合も、システムのアップデート状況や、今後のサービス継続予定などをチェックしておきましょう。

　稀にトラブルになるのが、アップデートされなくなった古いフリーウェアです。インストールを自由にしている組織の場合、チェックが漏れるため放置されやすい傾向があります。セキュリティニュースをチェックしつつ、気になるものがあれば資産管理システムで利用者をチェックする体制が望ましいです。キーマンズネットでもセキュリティチェックに関する特集がありますので併せてご覧ください。

代替案の調査

　大抵のサービスには何かしらの競合サービスが存在します。機能や費用の観点で優劣が見られるため調査しておくことが重要です。また、既にライセンスを持っていたり、利用実績があったりするのであれば、管理コストの観点から集約することをお勧めします。

　従業員によっては「前職で使い慣れていた別のサービスを使いたい」と導入済みサービスを利用拒否することがあります。その結果、Notion、Confluence、esa、Kiberaといったドキュメント管理ツールが乱立していました。

　ドキュメントにアクセスするために有料アカウントの発行が必要な場合もあり、コスト的にも無視できません。強いこだわりがある人が対立すると“宗教戦争”のような様相を呈することになるため厄介です。知識を共有するという観点から、トップダウンの指示を使ってでも統一すべきです。

プロアクティブな提案

　情シスは、事業部の申請をトリガにサービス導入するだけでなく、より適切なサービスや、現状の事業で必要となるサービスを積極的に提案しましょう。

　常に事業の状況と市場にあるサービスについての情報収集が必要ですが、事業理解ができていると自身の評価が上がる可能性があります。

組織別サービス選定のアンチパターン

　次に、サービスを全社で利用する場合とエンジニアのみが利用する場合の2パターンに分けてアンチパターンを紹介します。

全社で利用する場合

　古くは海賊版などと言われ、有料ソフトウェアがISOイメージとパスワードがセットでインターネット上に転がっていました。中には意図的にウイルスが含まれているものがあり大きな問題になりました。今は各社がライセンス管理を厳格化しているため、悩むシチュエーションは少なくなりました。

　インターネット黎明期からあるのが「シェアウェアのライセンス管理問題」です。有名テキストエディタのライセンス有効化パスワードを“なぜか知っている”非IT職が散見され、無邪気に使っていることがありました。非常にリスクのある行為なので、作業内容をヒアリングした後にフリーウェアに入れ替える必要があります。

　メーラーも鬼門です。私が遭遇したケースですが、メールが顧客管理システムになっている部署があり、新しい人が入ってくると案件単位でメールボックスがエクスポート／インポートされていました。こうした運用で10年以上使われた秘伝のメールボックスが存在することで、POPからも脱却できない組織がありました。現場の課題だけでなく、業務フローにも言及しないとサービス選定は不可能であると痛感しました。

エンジニアのみ利用する場合

　細かく言い始めるとプログラムで用いられるライブラリ全てをチェックしなければなりません。私が上場審査に向けて対応した際は、法務や監査法人と「aptコマンドで入手できるOSSは不問」「ただしセキュリティの問題が発生した場合は速やかに対応する」などとレギュレーションを定めました。

社内利用実績のモニタリングをしよう

　サービスは導入したら終わりではありません。

　ある自社サービスを運営する大手企業のCIOとお話をした時のことです。就任してから全社の有償サービスを棚卸したところ、1000種類ものサービスが利用されていたそうです。もちろん全てが利用されて事業に貢献していれば問題ないのですが、そうではなかったためコストカットに寄与したとのことです。

　また、ある人材紹介系企業のシステム構成を見たとき、複数の高価なサービスが使われていることが分かりました。本来はCRMとして利用されるHubSpotがメルマガ配信システムになり下がっていました。この企業はお金には余裕はあるものの専門職が居ないため、このように断片的に高価なシステムを組み合わせている状態になっていました。

　この2点は象徴的な怪談話ではありますが、多かれ少なかれ各社で耳にするお話です。実は使えていなかった機能が生きることも少なくありません。そうした機能面にも注目しながらサービス選定をするようにしましょう。

著者プロフィール：久松 剛（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito