2024年3月13日、AnityA主催のイベント「サイボウズはどこまでkintoneを使い倒しているのか？ 情シス本部長がIT戦略とシステム構成を大公開！」が開催された。本イベントの前半ではサイボウズ 執行役員 情報システム本部 本部長 鈴木秀一氏に、同社におけるkintoneを使った内製開発の歴史や成果などについてプレゼン形式で紹介してもらった。その内容は別途「サイボウズではkintoneをどう使ってる？ 自社で生まれた”失敗事例”を成功に変えるまで」にて紹介しているので、未読の方はまずそちらをご一読いただきたい。
イベントの後半では、このプレゼンの内容を受けて、サイボウズ システムコンサルティング本部 副本部長 萩澤佑樹氏とAnityA 代表取締役 中野仁を交えた3人によるフリーディスカッションが行われ、イベントの参加者から寄せられた質問に3人が答えるQ＆Aコーナーも設けられた。本記事では、その内容をダイジェストでお届けする。
情シスがリードして全社横断のデータ連携やマスタデータ整備を進める
中野： 鈴木さんのプレゼンでは、サイボウズさんの社内システムアーキテクチャが紹介されましたが、かなり広い範囲のシステムをkintoneで内製開発されていることを知って非常に驚きました。最近では、管理会計や勤怠管理、契約管理などのシステムはSaaSを使う企業が多いのですが、これらをすべてkintoneを使って内製開発しているというのはかなりの驚きでした。
さらにはSFAやカスタマーサポート、製品サポートのシステムもkintoneで開発していますし、面倒になりがちなワークフローのシステムまでkintoneで実現しているというのはかなり珍しいと思いました。
これらのシステムの開発は、2018年に情シス主導の内製開発の体制を本格的に立ち上げてから着手したのですか？ それとも、それ以前からもともとシステム自体は何らかの形で存在していたのでしょうか？
鈴木： 現在のようなきちんとしたシステムの形になっていたものは、もともとはほとんどありませんでした。各部門独自の取り組みとしてCSV上で簡単なデータ管理を行っていたり、kintoneで簡単な仕組みを作っているところはありましたが、やはりアプリケーション間のデータの連携や、入力データのバリデーションなどの機能は明らかに不足していました。そこで情シスの業務改善専門チームが各部門に直接アプローチして、これらを整理する形で本格的なシステムへと発展させていきました。
中野： 情シスが関与せずに現場に開発を任せっきりにすると、どうしてもデータ連携の部分が抜け落ちてしまうんですよね。自分たちが欲しい機能しか見えないので、社内システムを横断したデータの連携や一元管理という発想が出てこない。
鈴木： 実は情シスが内製開発をリードするようになった当初も、まずはデータ連携のことはあまり考えずに、個々のアプリケーションの開発に注力していました。しかし、さまざまなアプリケーションの開発を支援しているうちに、やはり「同じようなデータを使い回しているのだから、マスターデータベースをきちんと整備した方がよさそうだ」という声が自然と上がるようになってきました。そこでkintoneを使ってマスタデータ管理やデータハブの機能を開発することになりました。
こうしてマスターデータベースが整備されてアプリケーションからAPI経由でデータを容易に利用できるようになると、「このデータを使えばこんなアプリケーションを実現できるのでは？」というアイデアが自然と業務部門から出てきて、また新たなアプリケーションの企画が立ち上がるといったように、アプリケーション層とデータ層を行ったり来たりしながらシステム全体を発展させていくサイクルが回るようになりました。
情シスが業務部門の内製開発を積極的に支援して早期に成果を出す
中野： kintoneの開発元であるサイボウズさんといえども、kintoneを社内に導入した当初は一部の社員にしか使われなかったというエピソードもかなり意外でした。でも、サイボウズさんに限らずどの会社でも、新たな取り組みを始めた最初の3年間は種まきの期間で、そこを越えてからようやく成果が刈り取れるようになりますね。
鈴木： そうですね。ただ、実際には種まきをやっていたという自覚はあまりなくて、むしろ「素晴らしいツールを入れて専任チームも作ったのに、なぜ使ってくれないのだろう？」と理想と現実のギャップに頭を悩ませていたというのが正直なところです。
このまま、ただじっと待っていても仕方がないので、情シスの方から業務部門に対して内製開発による業務改革を積極的に提案するようにしたところ、ようやく動き始めたというのが実際のところです。
中野： そのようないわゆる「社内マーケティング」の活動は、とても重要ですよね。ただ情シスは普段マーケティングやセールスの仕事からは遠いところにいるので、自分たちの活動を外に向けてアピールすることが苦手ですよね。
ちなみに萩澤さんはユーザー企業のkintone導入を支援するプロフェッショナルサービス部門を率いる立場にいらっしゃいますが、kintoneの導入や活用に成功している企業に共通して見られる傾向のようなものは何かありますか？
萩澤： 先ほどの鈴木のプレゼンの中で、「エバンジェリスト」を中心に内製開発の輪を広げていくことの重要性が語られていましたが、実は最初にエバンジェリストになってくれる人を見付けるのはさほど難しくありません。ただし、エバンジェリストの呼びかけに呼応して一緒に盛り上げてくれる2人目、3人目の「フォロワー」がなかなか現れずに、思うように活動が進展しないというケースはよく目にします。
逆に、エバンジェリストの周りに自然とフォロワーが集まってチームが形成されると、そこを中心に活動の輪が広がっていきます。この「エバンジェリストの後に続くフォロワーが見付かるかどうか」が1つの分岐点になるような気がしますね。
中野： そうやって内部で活動の輪を徐々に広げていくためには、やはり3年ぐらいはどうしてもかかってしまうのでしょうね。でも企業の経営陣の立場から見ると、やはり早期に投資対効果を得るために「3年も待てない！ お金をかけてもいいから1年でやり切れ！」というようになりがちです。事実、経営から「1年で結果を出せ！」と言われてローコード／ノーコードツールを使った内製開発を始めてみたものの、やはり1年という短い期間では目に見える結果が出せずに、結果的に頓挫してしまうケースも多いと思います。
その点、サイボウズさんでは、なるべく早期に目に見える成果を上げて、エバンジェリストやそのフォロワーの人たちのモチベーションを維持させるために、情シスが積極的に介入して開発を支援する方針を打ち出したわけですね。
システムと向かう前にまずは人としっかり向き合うことが大事
鈴木： 情シスが支援するといっても、保守までを情シスが行うとなると到底手が回らなくなってしまいますから、あくまでも業務部門が主体となって開発・運用してもらうことが大事ですやはり業務プロセスを最もよく知る現場の人が、業務の改善を直接手掛けるのが一番いいに決まってますから。
そうやって情シスの支援を得ながら業務部門の中でシステムに詳しい人が育っていって、最終的には技術的な難易度がさほど高くないシステムについては業務部門が単独で開発・運用できるようになるのが理想です。
中野： そのように業務部門を導いていくためには、情シスはただ単に業務部門に言われたものを作るだけではなく、自ら能動的に提案していく能力が求められますよね。言ってみれば「社内コンサル」のような役割が求められることになりますが、サイボウズさんの情シスのメンバーは当初からそのような能力を獲得できていたのでしょうか。
鈴木： 必ずしも初めからそのような動きができていたわけではなくて、むしろ業務部門とともに業務改善に取り組んでいく中で「一緒に育っていった」というのが実際のところでした。
その際、メンバーに言い続けてきたのが、「システムと向き合う前に、人と向き合おう」ということと、「相手に対して共感を示そう」ということでした。
技術者は得てしてシステムとばかり向き合うあまり、対人コミュニケーションの重要性を軽視する傾向があります。例えば事業側の人から「これが大変なんですよ」と相談を持ち掛けられても、単に「それ、システムでは無理です」とファクトを淡々と述べるコミュニケーションに終始しがちです。そうではなくて、たとえ技術的に難しいと思っても、まずは「大変なんですね！」と共感を示すことが大事だとメンバーには言い聞かせました。
中野： 情シスのミッションとしては、確かに技術的にできることとできないことをしっかり切り分けることはとても大事ですけど、事業側に寄り添いながら課題解決や価値創出を目指す「DX推進」「企画推進」といった立場の人たちは、技術だけではなくてむしろ事業に対する理解の方が重要な場面も多いですよね。同じ情シスであっても、この両者はかなり異なる発想や動き方が求められると思います。
鈴木： そうですね。後者は、技術力の前にまずはコミュニケーションスキルが求められるので、やはり両者の能力やポテンシャルを同じ評価軸で測るのは難しいと思います。こうした考えから、弊社ではいわゆる「守りのIT」と「攻めのIT」を担当するチームを完全に分けるようにしました。
法令対応が求められる業務領域にはローコード／ノーコードは向かない
中野： では、参加者の皆さんから寄せられた質問にお答えしていこうと思います。
「市民開発において、ツールの教育はもちろんですが、ユーザーが業務課題にアンテナ（改善意識があるか）を張っているかがポイントかと思います。業務課題発掘系の教育をされているのか、チェンジマネジメント的（文化？）なことをやっていれば教えていただきたいです」という質問をいただいています。
鈴木： 業務部門のユーザーにとって、「何をシステム化したいですか？」という質問はそもそも難易度が高すぎると思います。そこで弊社では、ユーザーに普段行っている業務をいったん書き出してもらって、それを「イライラ度」「業務量」という2軸でマッピングしてみるという社内研修を行ったことがあります。こうすることで、自ずとシステム化すべき業務の優先度が見えてきます。
中野： 実際に「量が多くてイライラする業務」がシステム化されると、「ああ、システム化すると本当に楽になるんだ」「情シスに相談すると、こんなにいいことがあるんだ」という意識が業務部門側にも芽生えて、より情シスに相談を持ち掛けやすい雰囲気が醸成されますよね。
萩澤： もともとサイボウズは、どの部門でも「自ら業務を改善しよう」というマインドが強い会社だと思います。その点「文化」という面では、他社と比べていくらかアドバンテージがあるのかもしれません。
中野： 文化やチェンジマネジメントは、その組織の歴史や人、経営者の思想などが深く関わってくるので、なかなか一朝一夕で変えられるものではありません。一方、業務課題を可視化・抽出する方法論に関しては、既にさまざまなメソッドが確立されていますし、サイボウズさんのやり方もほかの会社にとって大いに参考になると思います。
では、次の質問に移ります。
「がんばってkintoneを入れると、ここまでいろんな業務で使えるとのことですが、この領域は禁止、この用途は禁止といった制約はありますか？ 例えばJ-SOX対応が求められる領域はアプリの変更管理手順が厳格なので、kintoneは不向きなのではないかと思います」
こちらはいかがでしょうか？
鈴木： kintoneに限らずローコード／ノーコードツール全般に言えることですが、厳密さが求められる領域、特に法令対応が求められる領域にはあまり向いていないと思います。法令が変わるたびにそれに迅速に対応していく必要があるので、内製開発でキャッチアップしていくのはかなりハードルが高いですね。
萩澤： そのような「自社の独自性が薄くて、型にはまっている領域」に関しては、その分野の専門システムやSaaSアプリケーションの方が明らかに向いていますね。逆に自社の独自色が強くなればなるほど、ローコード／ノーコードの強みが生きてくると思います。
エバンジェリストを孤立させないための施策が不可欠
中野： 「エバンジェリストを育てると、『kintoneは○○さんがやってくれるから、私はいいや』みたいな格差が発生して困っています。サイボウズではkintoneは自社製品だからそこまでのことはないかもしれませんが、RPA等のITソリューション含め、実際のところはどうでしょうか」という質問もいただいています。
鈴木： サイボウズでも、似たような状況にはなっていますね。実際には、各本部ごとに「kintoneならこの人」というエバンジェリスト的な立場の人がそれぞれいるのですが、たしかにその人たちに負荷が集中しがちな傾向はあります。そこでこういう人たちが孤立してしまわないよう、エバンジェリスト同士の社内コミュニティを作って互いに情報交換できる場を設けています。
中野： エバンジェリストだけがいくら頑張っても、周囲からの理解がなかなか得られないと、やがてはモチベーションが低下して「こんなことをやっていても到底割に合わない」「自分のスキルをもっと高く評価してくれる会社に転職しよう」と考えるようになってしまいます。こうしてエバンジェリストが抜けていってしまうと内製開発の取り組み自体も大きく後退してしまいますから、やっぱりエバンジェリストを孤立させないための施策はとても重要だと思います。
次の質問は「業務改善専任情シスはもともと情シスの方ですか？ それとも業務部門出身の方ですか？」というものです。こちらはいかがでしょうか。
鈴木： ちょうど半々ぐらいですね。もともと業務部門でITを使った業務改善をやっていた人が情シスに転じるパターンもありますし、もともと情シスにいた人が業務改善をやりたくて手を挙げるパターンもあります。
中野： エンジニアリング能力が足りない場合は外部のSIerを頼ればいいのですが、業務課題を解決する能力は外部から調達するのはなかなか難しいですよね。従ってもともと業務部門にいて業務のプロセスや課題に詳しい人は、業務改善専任チームのようないわゆる「DX推進」的なポジションには向いていると思います。
萩澤： 実際にkintoneを導入いただくお客さまも、業務部門の方が圧倒的に多いですし、導入プロジェクトでもエンジニアリング能力に長けた人より、むしろ業務プロセスをしっかり把握されている人の方が活躍されている印象があります。
中野： これがSalesforceやServiceNowのように、エンジニアリング能力がある程度高くないと適切に運用できない製品だと話は違ってくるのでしょうが、その点kintoneは業務現場が直接触るローコード／ノーコードツールとしてちょうどいい塩梅の製品なのだと思います。
