https://bizhint.jp/report/1110802?utm_campaign=20240909_post_news&utm_medium=email&utm_source=bizhint.jp&trcd=eml_pr_20240909_post_news_report01
社内業務や自社サービス管理の基幹システムとしてセールスフォース（Salesforce）を導入したものの、ITに明るい社員がおらず、コストに対して十分な活用ができていないまま10年以上利用。事業成長や働き方の変化に対し、業務システムを改善できないことを経営リスクと認識した株式会社ネタもと。コスト削減と業務効率化を目指し、kintoneへの移行が決まりました。そこでまず必要となったのがサポートしてくれるパートナー探し。40社以上をリストアップし、そこから1社を選ぶプロセスについて、精査の方法や選定の決め手、またkintone移行後の変化について、プロジェクトを推進した責任者にお話を伺いました。
株式会社ネタもと
管理部 リーダー 藤澤匠さん
株式会社ネタもと
広報の“自走化”を支援するPR支援会社。累計契約企業3100社以上、メディア関係者登録数4000人以上。従業員数約60名。
※本記事は2024年7月の取材に基づいて制作しております。各種情報は取材時点のものである旨、あらかじめご了承ください。
誰も触れない基幹システムに高額な固定費がかかっていた
――セールスフォースからkintoneへの移行。もともとの課題は何だったのでしょうか？
セールスフォースは社内業務や自社サービス管理の基幹システムとして10年以上利用してきたのですが、技術的に使いこなせる担当者が社内にいなかったこともあり、数多くの機能があるにも関わらず、それを十分に使いこなせていませんでした。
その一方で事業は成長し、また働き方も変わっていきます。当社としては、その変化に対応したシステムのアップデートが必要ではあるものの、それが叶わない…というジレンマを抱えていました。
さらには年間2000万円という多額の費用も、経営面で大きな課題でした。それだけの投資に見合う活用ができているか？という議論が経営層や部門長、そしてコンサルタントの間でありました。
そうして出た結論が 「より費用を抑え、自分たちでノーコードで機能開発ができるkintoneへの移行」 でした。
――藤澤さんがkintoneへの移行を担当された経緯は？
もともと私は新卒で営業として入社し、新規営業を担当していました。
しかし仕事をする中で、社内でのパソコンのトラブルやITまわりの困りごとの際には、いつの間にか私が対応するようになっていました。というのも、私は昔からパソコンやIT系のツールを触るのが好きで、自分で調べてやっていたんですね。それを社内でもやっていたら「ITのことは藤澤さんに聞けば解決する」という認識が広まり、そのような立ち位置になっていきました。
それで、セールスフォースからkintoneへの移行が決まった際に、社長から「責任者をやってみないか？」とお話をいただき、応諾しました。
現状、私を含め、当社は決してITリテラシーが高い組織ではありませんし、いわゆる情報システム部門といった専門部署もありません。
専門部署がなければ、それ以外の誰かが進めなければなりません。「ITを比較的知っている」「従来の社内のITまわりの困りごとをたくさん聞いている」といった背景から、私に白羽の矢が立つのは自然な流れでした。私としても、良いチャレンジの機会だと思っていました。
40社から1社への絞り込み。独自の評価フォーム8項目
――kintone移行の責任者として、何から始められたのでしょうか？
まず、kintone移行のプロジェクトチームを作りました。全16名で、事業部管掌役員・管理部管掌役員・部門長・現場営業担当者が参加しました。
社内にkintoneの開発ができる人材はいませんでしたので、外部の専門家の協力が不可欠でした。そこで、kintoneへのシステム移行や運用をサポートしてくれるパートナーを探すことから始めました。
それまで私は、簡単な開発案件で外部のパートナーとのやり取りをしたことはあったものの、本格的なパートナー探しは初めてでした。kintoneへの移行とそのパートナー選びはその後何年にもわたる会社の事業運営・業務効率に関わるものでしたので、腰を据えて進めました。
パートナー探しでは、2つのルートを使いました。
1つは「サイボウズのパートナーネットワーク」というサイト。そしてもう1つは、当社の経営層や部門長のコネクションを使い、kintoneの開発ができる方を募りました。
その中で対応いただけそうな企業のリストを作った所、40社ほどになりました。
そしてその40社に対し、プロジェクトのメンバーごとで担当を割り振り、当社が求める要件について相談しました。その要件というのが、大きく次の3つです。
1つ目が、kintoneの開発経験があり、kintoneと外部システムをつないだ仕組みを開発できること。
当社ではメディア各社とニュース発信企業とをつなぐ、ネタもとという自社サイトを運営しているのですが、このサイトとkintoneの連携は絶対条件でした。
そして2つ目は、当社が求める納期に間に合うこと。
3つ目は、プロジェクトマネージャーがプロパー（当社が開発を依頼する企業の社員）であること。 システム開発をする際には、発注した会社が他社に業務委託をするケースがあります。当社としては、そういった場合のコミュニケーションや、それが理由で起こるトラブルが不安でした。
前述の通り、当社にはITの開発がわかる社員やその専門家もいないので「何より円滑にコミュニケーションできること」「認識の齟齬なく、仕様通りのものを作る」ことを重視していました。
ですので、特に開発体制において「プロジェクトマネージャーは必ずプロパーにしてほしい」と伝えていました。
これらの要件と照らし合わせると、40社から20社ほどに絞り込みが進みました。そして、さらに各社と商談を進めていきます。
実際に商談を進めてみると、提案を依頼しても提案をいただけなかったり、いつの間にか返信が途切れたり…合う・合わないはあるのでしょうね。自然と絞られていくような形になりました。このあたりで6社くらいに絞り込まれました。
――そこから最後の1社に決められるプロセスは？
各社ごとに引き続き対面やオンラインで商談を重ねるのですが、このあたりから具体的なご提案をベースにした検討に入ります。
各社、私たちの想像以上の様々な提案をいただけて、それ自体とても勉強になりました。特に追加機能のような部分は各社ごとで思想が違うので、それぞれの意図など聞きながら比較していきました。
そして最終的には、移行プロジェクトのメンバー全員が「評価フォーム」を記入して比較しました。この評価項目はメンバーの意見を集め、Googleフォームで作成しました。
評価項目は全8項目。それぞれ5段階評価です。
- 仕様書通りの提案内容か？
- 要望をもとにプラスアルファのご提案をいただいているか？
- 納期は要望通りか？
- 開発体制は要望通りか？（人員が十分か、プロジェクトマネージャーはプロパーかなど）
- ネタもとのサービスと類似するサービスサイトの開発実績があるか？
- ネタもとサイトへの理解度の高さ
- 提案時のコミュニケーションは、当社に適切か？（専門的な内容を噛み砕いて話してくれる、説明を十分にしてくれるか？など）
- 当社の経営層とのコミュニケーションの相性はどうか？
この8項目に加え、見積額・特記事項も付与して比較を行いました。
パートナー選びの評価シートをGoogleフォームで作成。メンバーがそれぞれ評価する。
提案内容だけでなく、そのプロセスでもパートナーの姿勢がわかる
――それぞれの評価項目にはどのような意図が？
あくまで当社独自のものではあるのですが、いくつか補足説明をさせていただきますね。
「4.開発体制は要望通りか」については、ご提案をいただく際にプロジェクトマネージャー本人をご紹介いただくように依頼しました。提案時点では「プロジェクトマネージャーは未定です」という所もあったのですが、 どんな人がプロジェクトマネージャーになるかわからない、というリスクを当社は取れませんでした ので、お断りする形にしました。
そして、「7.ネタもとサイトへの理解度の高さ」は前述の通り、当社が運営するサービスサイトへの理解です。仕様通りに開発することはもちろん大切なのですが、ご提案を作成いただく時点で、 当社のビジネス・サービスをどれだけご理解いただけているかによって、ご提案の質に差が出ると考えていました。
実際、ご提案をいただくにあたって「ネタもとのサービスやサイトの仕様を教えてほしい」と積極的にご相談いただける企業もあれば、そういったことには触れずにご提案をいただく所もありました。当然、前者の提案のほうが実現可能性は高いですし、ポイントを押さえてくれていました。当社への提案を一緒に作っていく感じとでも言いましょうか…。 提案内容はもちろん、それを作るプロセスで明確な差がありましたね。
「9.経営層とのコミュニケーションの相性」は、やはり何かあった際には、当社の経営層とコミュニケーションいただくこともあると思いますので、そういった観点で設けました。
私たちが普段、当社の経営層と接している中で「この方々だったら一緒に、また丁寧に経営層に説明していただけそう」といった、少々属人的な項目ではあるのですが…キャラクターや相性のようなものかもしれませんね。
これらの評価フォームを経て6社から2社に絞り込み、そして最後の1社が決まるという経緯でした。
――最後の決め手は何だったのでしょうか。
最終的にはA社をパートナーとして選ばせていただいたのですが、決め手となったのは「安心感」でした。
まず、打合せは毎回当社まで直接訪問していただきました。コミュニケーションも含めて、開発業務はオンラインでも完結できると思いますが、何度も言うように、 私たちはITについては素人なので、実際に顔を合わせてお話しいただけるのは、すごく安心感がありました。
開発体制が社内で完結していることに加え、品質管理の資格を持つ独立組織があったこともありがたかったです。 品質に問題がないか、第三者の視点からフィードバックをしながらプロジェクトを進めていただける体制とのことで、当社にとっては安心材料でした。
また、ご提案をいただく前に、NDAを結んだ上で当社のサービスIDを発行し、実際のサービスの仕組み・仕様を見たいと仰いました。サービスを理解しようとする姿勢や、その結果としていただいたご提案は当社のニーズや現況を的確に汲んだものでしたし、素直に嬉しかったですね。
最後にもう1社残っていたのですが、そちらの商談はすべてオンライン。しかし価格が安いという点が大きな優位性でした。ただ当社の場合、今後数年以上にわたって使用する基幹システムをお任せする上では、A社の姿勢や安心感のほうが、優先度が高いと結論しました。
――貴社の経営層からの決裁については？
経営層の決裁のポイントとしては「当社のニーズや仕様にマッチしていること」と「費用感」の2つ でした。前者については私たちとしても十分に精査しましたし、またしっかり説明して理解を得られました。
あとは費用面なのですが…ここは正直、A社さんにもがんばっていただきました。ただ、それまでの比較検討の経緯や、他社と比較して価格相応の安心感・価値があること、そして何より自分たちが進めたいことを説明し、価格面も含め決裁をいただけました。
価格と価値の整合性を説明するのは本当に難しいのですが、やはりそれに値する比較検討を重ねてきたことと、それをもって自分がやりたいという意思を明示することが、当社においては重要だったのかな？と思います。決裁をいただけて、本当に感謝しています。
「伝え続ける」「現場の要望にすぐ対応」定着を進めるコツ
――kintoneへの移行にあたって、社内での定着はいかがでしたか？
基本的にはそれ以前と同じ作業をkintone で行うということですから、システムの移行自体は比較的スムーズだったと思います。
ただ、やはり見た目や操作性は大きく変わるので、移行直後は現場からいろいろな声が上がってきました。
そういった中で意識していたのが、現場からの声を都度聞いて、できるだけ早く対応・機能改善することです。 kintoneは自分たちでアプリ開発や画面の変更ができるので、不満や要望の声が上がったら、すぐに改善というサイクルを回していました。
現場の要望を聞き、それをすぐに改善というサイクルを繰り返した。
そしてもう1つ。あらためて大事だと感じたのが、目的を「言い続けること」 です。現場に新しいツールを使ってもらうには「なぜツールを変えたのか？ツールを変えてまで、何をしたいのか？」を理解してもらう必要があります。
今回のツール変更の目的は、コスト削減はもちろんですが、現場レベルでは「より効率的な働き方ができるシステムにする。それを自社で、自由に改善できるようにする」ということです。
だからこそ、現場から意見が上がればすぐに対応して行動や形で示していましたし、現場には「要望を上げてほしい。それこそが目的です」と言い続けました。
振り返ると当社は、お客様に対して「企業広報・メッセージを発信し続けることが大事」と言い続けてきた会社です。私含め社員は『言い続けること、伝え続けること』の大切さを身に染みてわかっています。そういった企業風土も、定着においてはプラスに作用したように感じますね。
――現場の声を聞くための工夫などされたのでしょうか？
最初は様々な形で届きました。文章でまとめて上がってきたり、チャットで連絡が来たり、直接口頭で言われたり…。
また、当社のオフィスは平場になっているので「使いづらい」「どうやればいいの？」といった話し声がどこからともなく聞こえてくるんですよ。 そうしたら駆けつけて、すぐに対応・改善できるものなのか、時間やコストをかけて対応すべきものかを判断していました。
そのうち、kintoneの使い方への疑問や改修の要望を聞くために、問い合わせ窓口のアプリを作りました。特に導入当初は、あちこちでエラーが起きたり、改善要望が上がっていたので、集約する場所を作って優先順位をつけていきました。
運用を始めてからの2年で、要望は200件くらいになっています。その都度、部門や関係者に確認して対応を決めているのですが、7割以上は解決できました。
kintoneの使い方への質問や回収要望の一覧
――現場の声から生まれた機能の例は？
事例の社内共有アプリはわかりやすいと思います。以前から当社では、朝礼や日々の業務の中でお客様の成功事例などを共有しているのですが、どうしても一時的な共有で終わってしまったり、他の部門との共有が難しかったりしていました。
それで現場から「全社の成功事例を一覧で見られるようにできないか？」という声をいただいて、新しくアプリを作りました。
このように 「要望を聞いて形にする」を繰り返していくと、自然と要望が集まるようになりました。 kintoneのようなツールの組織定着においては、現場の業務・困りごとを聞いて、それを解決する機能を、できるだけ早く、きちんと作る。この動きが重要だと感じますね。
――パートナーとの運用における関係性は？
自社でkintoneを触っているのは、主に社内業務に関する部分です。特に、当社のサービスとの連携が絡む部分はA社に対応をお願いしています。
A社の保守チームとの窓口は私で、それこそkintoneでやり取りをしています。社内業務の改善であっても、システムまわりのアドバイスをいただいています。
また、当社内の各部門長と現場の何人かの役職者、またお客様対応の部門のメンバーが参加しているグループチャットにも、A社に入ってもらい、社内の状況を共有しています。
人が入力する以上避けられない「誤入力」の課題
――移行にあたって、想定外だったことはありますか？
予想以上に多かったのが「データ入力の間違い」です。 これには本当に困りました。入力ルールを作成してマニュアルも作成したのですが、なかなか改善しませんでした。
結局「これはシステムや運用で解決するしかない」と腹をくくり、仕組みを整えていきました。「集計項目は自由筆記をなくし選択式に」「入力欄の下にルールを明示」というベーシックな対策はもちろん、入力後に第三者がチェックする運用フローを新設して「チェックを申請する」ボタンを作りました。
現状、 「人がデータを入力する」という業務がある以上、誤入力とそのチェックはどうしても外せない運用フローになりますね。
――kintone 移行の効果や、その後の組織の変化について教えてください。
まず、当初の目的であった費用面に関しては、年間の運用コストを10分の1に削減することができました。
また組織の変化としては、前述したことと若干被りますが、kintoneまわりに限らず、現場からの改善や業務効率化の意見が積極的に上がってくるようになりました。
以前は改善の声を上げても「（システム的に）できない」で終わってしまうことが往々にしてあったので、現場としても心理的ハードルが高かったことは否定できません。
しかしkintoneへの移行後、いろいろな要望に応えていくうちに、それが成功体験となって「こんなことはできないか？」という声が自然と集まるようになってきました。
特に「部門間の連携」のための改善要望が増えてきており、そのためのアプリをkintoneでいくつか作りました。あらためて、以前は部門間連携が不足していた、現場はもっと連携したいと思っていたのにシステム側がそれを叶えられていなかった、ということを逆説的に感じています。
もちろん課題もあります。今、kintoneの社内向け機能の開発は主に私を中心に行っています。しかし今後組織が大きくなり、またいろいろな情報をkintoneに集約して業務効率化・付加価値創出を進めていくことを考えると、kintoneで仕組みを作れる人材はやはり足りません。これを増やしていく必要があります。
私は全部門の広範な業務について、できるかぎり情報収集をしているつもりですが、やはりその業務を行う現場の人のほうが、より具体的な改善イメージを持っているはずです。ですので、業務上の「ちょっと不便だな…」といった気付きを解消できるスキルとして、kintoneを少しでも触れる人材を増やすことが、当社としてもう一歩、生産性を上げる上では必要だと考えています。
（文：安藤 ショウカ 撮影：松本 岳治）
0 コメント:
コメントを投稿