文系管理職の絶妙な笑顔
「文系管理職なのに〜♪ 画期的な業務アプリを♫ チャチャっと作れちゃう♩ オレ」
製品よりも豊川悦司さんの絶妙な表情の方が印象に残りそうなCMです。
このCMに象徴されるように、情報システム開発の世界では、ノーコード・ローコードのシステム開発プラットフォームがその活躍の場を増やしているようです。
私たちも冒頭のプラットフォームではありませんが、一部のノーコード・ローコードツールを、私たちが開発するシステムの一部として使っています。
ノーコード・ローコードプラットフォームのメリット・デメリットは、様々なサイトに書かれており、一般的には以下のようなことが挙げられています。
【メリット】
(1) システム開発を内製化できる／非IT部門を開発戦力化できる
システム開発の専門的なスキルがなくても開発が「可能」なので、外注していたものを自社開発したり、システム開発部門でなくても開発が「可能」になる
(2) 開発時間を短縮できる
コードを書く必要がないので、その分短時間で開発が可能になる傾向がある。
(3) 比較的低コスト
外注するのに比べれば、技術料が無いことや開発時間の短縮によるコスト削減が「可能」。
(4) エラーやバグが起こりにくい
プラットフォームが装備している完成した機能のみを使うためエラーやバグが起こりにくく、安定したシステム構築が期待できる。
【デメリット】
(1) プラットフォームに全面依存している
ホスティング環境・サーバー・データベースからプログラムまですべてをプラットフォームに依存するので、「プラットフォーム側に何かあった」際には打つ手がない。
(2) 思うような改善ができない(場合がある)
プラットフォーム側で用意している機能しか使えないので自由度が低く、思うような改善ができない場合がある。
(3) 大規模開発や複雑な開発には不向き
同様に大規模な開発や複雑な要件を持つ開発はできない場合が多い
このようなデメリットがあるとはいえ、比較的シンプルな管理システムなどではメリットがそれを補って余りあると言えそうです。
IT人材不足が懸念される今、日本企業のDXに向けて大いに活用が期待されるものであることは間違いないと思います、などと少々上から目線で書くのはおこがましいですね。
とにかく「すごい」です。皆さん、よくここまでプラットフォーム化された、と思います。
この稿はメリット・デメリットを詳細に述べることが目的ではありません。
ノーコード・ローコードプラットフォームをめぐって、私たちが経験したことをご紹介したいと思います。
システムは液体ではない
お客様のニーズにジャストフィットするカスタムメイドのシステムのご提供を主事業のひとつとしている弊社は、デメリットの(2)(3)が障害となって、全面的にノーコードに依存することは難しいのですが、使う場面もあります。
今ほどノーコード・ローコードのプラットフォームが充実していない時期のことではありますが、お客様のご要望にお応えしようとすると、どうしてもすんなりとはプラットフォームで実現できない部分がでてきました。
通常の開発ならシステムに合わせた器を作ることができますが、ノーコードでは器の形状が決まっている、というイメージでしょうか。
ところがシステムは液体や気体ではないのです。
システムの設計に加えて、各パーツやロジック、データをどうプラットフォームに「入れる」かという問題が出てきた、というわけです。
形がきまっている器に液体でないシステムを当てはめるための設計とプログラムの作成をしなければならなくなって・・・
結局、システム構築にかかった時間と手間は通常の開発以上だった、という苦い経験があります。
システム開発は「設計」にあり
システム開発の「キモ」はどこにあるのでしょうか？
「プログラミングできる人たちがそれを専門技術としてやっているのだから、プログラミングじゃないの？」
私たちは違うと考えています。それは「設計」にあるのです。
ノーコードプラットフォームを使って自社で顧客管理のシステムを作ろうしていた企業から、「開発の状況を見てやってくれないか」と相談を受け、開発についてアドバイスをしに行ったことがあります。
行ってみて、ひっくり返りました。
顧客データに「顧客ID(顧客ごと付すユニークな番号またはコード)」がない？！
確かに何万というような量のデータを扱うシステムではありませんが・・・
「IDがなくて、どうやって顧客を特定するのですか？」と尋ねたところ
「社名があるからわかるじゃないですか」とのお答え。
「社名が同じだったら？」
「今同じ社名の会社はないし、住所見ればわかるし」
・・・エクセルでやっている分にはそれでもいいでしょうけれど・・・
「今後もし同じ社名の会社が複数になった場合、システムにそれをやらせるためには、社名と住所両方を参照させなければなりませんよ」
「・・・？？？」
まあこれは極端な例ですが。
メリットのところで「可能」とあえて「」つきにしたのは「理論的には可能」という意味です。
情報システムがどう動くのかについて一定の理解と知見がなければ開発はできないのだな〜、と。
極端な言い方をすれば、ノーコードツールがやってくれるのはプログラミングであって設計ではない、ということでしょうか。
また数年前、ある企業が社内業務の開発を打診してくださいました。
比較的シンプルなシステム要件でしたが、ちょっと予算感があいませんでした。システム部門を持っているような企業ではありませんでしたので、私たちは「♩よせばいいのに〜♫」、あるノーコードプラットフォームを紹介し、「これなら内製でできるかもしれませんよ」と余計な(「余計な」の理由はあとでわかります)アドバイスをしました。
すぐにそのように方針が決まり、ある「目端が効く」営業担当の方がノーコードツールでの開発を担当されることになりました。
もちろんシステム開発のご経験はありませんでした。
３ヶ月後くらいにご様子をうかがいに行きましたが、「まだできていない」とのこと。
周囲の人も含めて話をきいてみると、この方システム開発に時間をとられて本業の営業の方も奮わなくなっているとのこと。
しかもシステムもできあがらない、ということで、上司や経営陣からの目が厳しくなっているらしい、とのこと。
8ヶ月後、この方から連絡がありました。
「退社することになりました」と。
何故退社されるのか、詳しい事情は聞けませんでしたが・・・
営業としては優秀な方だったのに、会社は人材を１人失うことになりました。
内製化してもコストがかからないわけではないのです。
結構大きなコストがかかっているかもしれないのです。「担当者の時間」というコストが。
極端な例をご紹介しましたが、多くの企業がノーコードプラットフォームを使ってDXの第一歩を踏み出しているのも確かです。
豊川部長も本来業務の部長の仕事がおろそかになっていないことを願うばかりです。
代表 松下正寿
