アールスリーインスティテュート
内製開発をプロとしてサポートする　サブスクリプションサービスを提供

　アールスリーインスティテュートは、サイボウズが提供する「kintone」を活用したシステム開発で実績があるベンダーだ。システムの受託開発だけでなく、kintoneのユーザー企業が自らカスタマイズできるノーコードツールである「gusuku Customine」（グスク カスタマイン、以下Customine）を開発し、ユーザー企業に提供している。

　同社の金春利幸・取締役Chief Innovation Officerは、Customine開発の背景を、次のように説明する。

　「当社はkintoneのカスタマイズ開発を長年手がけてきた。kintoneはそれ自身がノーコードツールであり、基本的な機能を活用したシステム開発はユーザー企業自身で行うことができる。しかし、一部をカスタマイズしようとすると一般の企業では難しく、我々のような開発会社が受託して作ることになる。そこに矛盾を感じていた」
 
　元々ユーザー自身の手で開発を行えるツールなのに、カスタマイズのために外注のプロセスとコストをかけるということに、当事者として違和感を覚えていたというのだ。ならばカスタマイズも内製でできるようなツールを作ればいい。それがCustomineというサービスを始めた動機だ。

　実際、同社が多くの企業からkintoneのカスタマイズを請け負っている中で、共通するカスタマイズの項目は非常に多かった。それらをまとめてサービスとして提供することで、多くのユーザーのニーズに応えられるという考えもあった。現在、典型的なカスタマイズ項目として約50種類のテンプレートを用意している。

　Customineによって、企業ユーザーは自分でkintoneをカスタマイズして自社の業務改善に利用することができるようになったが、課題はまだあった。Customineではチャットによるサポートも提供しているが、チャットだけでは問題が解決しないユーザーが多いということに気が付いたという。

　そこで同社では、企業のkintoneの導入と開発を支援するサブスクリプションのサービスプランである「gusuku Boostone」（グスク ブーストーン、以下Boostone）を開始した。

　これは、kintoneによるシステム開発をプロの立場で支援するサービスで、相談窓口の設置をはじめ、CustomineやJavaScriptによるカスタマイズのアドバイスや、実際の開発も可能だ。五つの料金プランがあり、高くなるほど高度な開発を依頼することができる。

　「kintoneは基本料金が非常に安価なので、そのカスタマイズを当社に依頼いただいてもお客様の予算とマッチしないケースが多くあった。それなら料金を抑えて、当社は開発は行わないが、プロとしてのアドバイスをする、というサービスが一番いいだろうと、Boostoneを開始した」（金春取締役）

　同社も当初は、内製化支援メニューを拡充すると、受託開発の事業に影響を及ぼすのではないかという懸念があったという。だがフタを開けてみると、それは取り越し苦労だった。

ツールの提供でマーケットが広がった

　「そもそも自分で開発しようという意思のある企業はシステム開発を外注する気がなく、内製化する気がない企業は引き続き外注を好みます。きれいに分かれていて干渉することはなく、結果的に当社としては市場が拡大した格好です」（金春取締役）

　同社のCustomineとBoostoneのユーザー企業で、大規模に導入を進めているのが、日清食品ホールディングスだ。同社では業務フローのデジタル化を進めるに当たって、開発の内製化を特に重視していた。検討の結果、社内でノーコード開発ができるツールとしてkintoneを選定。同時に、CustomineとBoostoneを活用し、アールスリーインスティテュートのサポートによる内製化を進めている。「（日清食品HDへの支援では）一つの課題を解決する場合に、設定は簡単だが高度なスキルを要するものと、設定は面倒だがスキルレベルが低いものの2種類を提案することもある。内製化を前提としたとき、あえてスキルの敷居を下げることで、カスタマイズの属人化を避けることを意識している」（サービスグループ gusukuユニット リレーション＆フィールドセールスの築山春木氏）
 
　Customineは、他社が開発したkintoneアプリケーションの内製カスタマイズ用としても利用され始めている。ユーザーの声でわかったニーズに応えるため、リリース以来のアップデート回数は41回を重ねている。有償契約数は、現在約400社。kintoneのユーザー数である1万8000社からするとまだまだ少ないが、それだけに伸びしろは大きいと見ている。

JBCC
大規模開発をスピーディに行うため　ローコードツールを積極活用する

　JBCCは、一般的なアジャイル開発手法に独自の改善を加え、基幹システムなどの大規模開発にも適用可能とした「JBCCアジャイル」を、2014年から提供している。そこで高速な反復開発を可能にしているのが、ローコード開発ツール「GeneXus」（ジェネクサス）だ。20年11月現在、JBCCアジャイルによる開発案件は224件に達しているが、そのうち30社弱に対しては、サービスイン後ユーザー企業自身による保守・開発が行えるよう、内製化支援サービスを提供しているという。

　同社SI事業部 SIイノベーション本部の金光剛右・本部長によれば、同社の顧客企業のIT部門では、内製化の方向性を示す動きが強くなっているという。ただし、その際の課題や対象領域は、企業ごとに異なる。「JBCCアジャイルによる開発を始める際、企業側のIT部門からもメンバーが参加して、内製化への意欲を示される場合もある。開発は当社とチームを組んで進め、稼働後の小さな改修は内製で進めようというケースや、大規模なバージョンアップを内部でやっていこうと考えている企業もある。まずはお客様の課題を共有いただき、それに合わせて内製化の進め方も検討している」

　最近では、従来のプログラミング言語をスキルセットとして持ち続けていくことに不安を抱き、ローコード環境に移行することを検討する企業が多いという。「古いスキルセットを更新していくのでなく、ローコードツールよって新しい技術を吸収させていく形をとりたい企業も増えていると思う」（金光本部長）
 
　昔のように、特定の開発言語をマスターしていればシステムが開発できた時代と違い、今の開発者はWebやクラウドなど、さまざまな新しいスキルが必要になる。それらを全て網羅し、アップデートすることはリソース的にも難しい。それならばコードを書かない開発環境に移行し、ツール側で処理させることで、開発者の負担を減らすことができる。金光本部長が言う「スキルセットの吸収」とはそういう意味だ。

　「企業がシステムの変革を強いられる一番の要因は、スピードではないか。予測不能なビジネス環境の変化に対して、素早く対応していかなければいけない。それが外注から内製化への動きを加速し、品質の高いシステムを素早く開発するための環境であるローコードの採用へと向かわせている」（同）

　JBCCがローコード開発環境としてGeneXusを選んだ理由は、業務システムを100％ツール上で開発できたことが大きいと話す。

　「他のツールでは、7～8割の開発はツール上で行えても、残り2～3割を手作業で作る必要があった。当社としては、その部分が開発速度や品質を下げる要因になると判断し、GeneXusに決めた経緯がある」

　一部が人の手によるコードの場合は、属人化を生み、バグの原因にもなる。ツールが100％自動生成したプログラムであれば、そうした不確定要素を排除できる。スピードを重視するアジャイル開発にはその点が欠かせなかったという。

内製化支援でSIビジネスは伸びる

　さて、今回の取材では、ユーザー企業が内製化に向かうことで、SIerのビジネスは減るのではないかという質問を各社にしている。JBCCの答えも、他社と同じく「縮小ではなく広がる」だった。その理由を金光本部長は次のように説明する。

　「表面的には、内製化によって外注先は必要がなくなるように見えるが、実は逆。これまでの受発注の関係では、仕様書は共有できても、（顧客がソフトウェアの）中身まで理解することはできなかった。これからはユーザーとベンダーが、同じプラットフォームの上で同じ“言葉”（＝ツール）を使って会話ができるようになる。我々が作った内容をお客様側でも理解できるようになる」

　同じツールで作られているシステムは、仮にJBCCがタッチしていない部分に、途中から入っていく場合も把握しやすい。ユーザー企業はベンダーとの関係をより柔軟にコントロールできるようになり、ベンダー側にとってもビジネスチャンスは広がるというのが、JBCCの考えだ。

　金光本部長は、企業が内製化を進めるべき部門やシステムについて、次のように語る。

　「今後は、コモディティーと呼ばれている人事給与や会計の領域をスクラッチで開発する企業はまず存在しないと考えられる。ではどこを内製で開発するのかといえば、やはりビジネスの領域で他社と差別化する部分になる。自分たちの強みを打ち出していける領域に対して、スピーディーに開発できる体制を整えるべきだと思う」

ローコード／ノーコードツールを見極め、
内製と外注、人とシステムの共存を進める

　今回見てきたように、ローコード／ノーコード開発ツールは進化している。IT部門が主に用いるツールと、現場の業務部門が用いるツールで性質は異なるが、DX推進に向けた要求を満たすだけの機能や品質を備えるに至っている。

　ただし、ツールは万能でない。何ができて、できないか。限界を見極めることが重要だ。内製化にこだわりすぎて、かえって効率が悪化したということにならぬよう、注意しなければいけない。客観的な判断を下すためには、業務とITに精通した専門家のアドバイスを受けることが必要だろう。

　内製化とは、ユーザーがベンダーと手を切ることではない。内外をバランスよく使い分けることである。そこにいち早く気づいたベンダーは、SIビジネスの今後を見据え、内製化支援の動きを強化しているのだ。