ノーコードを経験して、それでも私がコードを書く話


先日、親から連絡がありまして。

祖父母の家を親が引き継ぐことになり、30年近く借りていた家を出ることになったとのことでした。
要するに、実家がなくなりました。
祖父母の家なので、親も私も勝手知ったるところはあるため不安はないですが、「幼き頃から過ごしたあの家には、もう帰れないんだなぁ」なんて思ったりしました。郷愁。

そのため、ここ数週間は週末のたびに実家の片付けに行っていたのですが、押し入れの下やら上やら、漁れば漁るだけ出るわ出るわ。
修学旅行で買った木刀、どこかのお土産の般若の面、小学校の通知表、英語の聞き流しCD......。

「これ、いる?」と自分に問いかけてみましたが、答えは出ませんでした。
捨てるには惜しい。でも使い道があるかどうかもわからない。「持って帰る?捨てる?」という宙ぶらりんな問いが残りました。

プログラミングもそう!
ノーコードの時代に、コードを書く技術って、必要なの?

というわけで、今回はこちら!

ノーコードを経験して、それでも私がコードを書く話

目次

  1. ローコードの本当の強みは
  2. コードを書いてわかったこと
  3. アルマゲドン
  4. だから、うちのチームはこうしている

1. ローコードの本当の強みは

PowerAppsで感じた「速さ」の快感

私はここ数年、Power Platformをメインに仕事をしてきました。
最初に触ったときの感動は今でも覚えています。

画面をドラッグ&ドロップして、ボタンにちょっとした式を書いて、気づいたら動くものができている。
「え、もう動くの?」って、本当に最初はびっくりしました。

大仰なコードを書かなくても、ロジックが組める。DBも繋がる。承認フローも作れる。
「これがローコードの世界か」と感動した記憶があります。

本当の価値は「企業が安心して使えるエコシステム」

でも、使い続けるうちに気づいてきたことがあります。
ローコードの本当の強みは「速さ」じゃない、ということです。

PowerAppsをはじめとするMicrosoft Power Platformは、企業がそのまま安心して使えるエコシステムの上に乗っています。具体的に言うと:

  • セキュリティが標準で担保されている:Microsoft Entra IDによる認証、条件付きアクセス、DLP(データ損失防止)ポリシー、監査ログが最初から組み込まれています。フルスクラッチで同じことをやろうとすると、全部自分で実装しなければなりません。
  • Microsoft 365との連携が深い:SharePoint、Teams、Outlookとシームレスに繋がります。これをフルスクラッチで実現しようとすると、Graph APIへの対応が必要で、工数が大きく跳ね上がります。
  • 現場の人間が自律的に動ける:IT部門への依頼なしに、業務を知っている現場の担当者が自分でアプリを作れる。DXの文脈で見ると、これは巨大な価値です。

「速い」は結果であって、本質は「企業の土台の上で、安全に素早く動ける」ということなんです。

それでも、限界はある

何年か使っていると、フルスクラッチ開発との境界線がぼんやり見えてきます。

例えば、あるプロジェクトで大規模なメール送信処理が必要になったとき。
Power Automateでやろうとしたのですが、件数が増えると処理が安定しなくなり、結局Azure Functionsを使って、キューを使って、SendGridを呼び出してみたいな開発になりました。

別のプロジェクトでは、大量のデータを扱って、長期間安定稼働させて、改修も続くようなシステムを作ることになりました。
ノーコードで始めてみたのですが、規模が大きくなるにつれて「ここをこう変えたい」「ここに処理を追加したい」という要望に、柔軟に応えることが難しくなってきました。
この条件であれば、フルスクラッチ開発と同じくらいの運用コストが必要で、場合によってはフルスクラッチ以上に深いMicrosoftのサービス群への知識量が要求される場合もあります。

弊社では両方の知見が溜まっているため、適材適所の提案やサポートをさせていただいておりますが、市民開発者の方がその境界線を知らずに踏み越えてしまうと、せっかくのDXなのに保守運用コストが増えてしまうような、本末転倒な結果になってしまいます。

2. コードを書いてわかったこと

「動かす」と「わかる」は別物だった

コードを書くようになって最初に気づいたのは、「動かす」と「わかる」は全然別のことだ、ということでした。

Observerパターンというものがあります。
「誰かが何かを見張っていて、変化があったら教えてくれる」という仕組みです。C#では event キーワードや IObservable<T> / IObserver<T> インターフェースで実現できます。

最初にパターン名を聞いたとき、正直ピンとこなかったんですよね。
「Observer? 見張り人? 何を見張るの?」という感じで。

とりあえず event を使って実装してみました。書いて、動かして、「あ、動いてる」という状態にしました。
でもその時点では、「なぜこう書くのか」はまだ腹落ちしていなかったんです。

しばらくして、「イベントが発火したときにDBに保存したい」という要件が出てきました。
調べながら async void で書いたら、とりあえず動きました。ところが、例外がどこかに消える・処理の完了を待てない、という問題に直面して。

さらに調べると、async void はイベントハンドラ専用の例外的な書き方で、本来は async Task を使うべきだとわかりました。
同期と非同期で書き方が変わる。でも、「変化があったら通知して、受け取った側が処理する」という概念はまったく同じ。

そこでやっと、「あ、これはこういうことか」と腹落ちしたんです。

その瞬間の気持ちよさは、今でも覚えています。

変わるのは「自由度」じゃなくて「問題の見え方」

コードを書く価値を「自由度が上がる」と表現する人は多いです。でも、私が経験から感じているのは少し違います。

コードを書いた本当の価値は、「どこが壊れるかがわかるようになった」ことです。

async void で詰まって、async Task に辿り着いた。あの体験の価値は「コードが動いた」ことではなく、「なぜ壊れたかがわかった」ことにある。

「なぜ壊れるかわかる人間」は、ローコードの限界が来たときにも、問題の輪郭を早く掴めます。
「ここの処理がおかしい」「このAPIとの繋ぎ目に問題がある」という判断が、コードを知っている人間のほうが格段に速い。

ノーコードツールは多くのことを抽象化してくれます。それが便利さの理由でもあるのですが、裏を返すと「中身がわからない」ということでもあります。
コードを書いた経験は、そのブラックボックスを自分の言葉で確かめる力を育ててくれます。

弊社では、ローコードもコードも両方経験しているエンジニアが多いんです。
それは「どちらも使える」というより、「限界が見えているから選べる」ということだと思っています。

3. アルマゲドン

ちんたらと私が考えている間に、世界が変わりました。
AIの登場です。
天変地異、アルマゲドン、ノブレスオブリージュ。
ローコードが速いとか言ってる場合じゃない世界が来ております。

でも、ここまで読んでいただいた通り、ローコードの強みは速さだけではもちろんなく、フルスクラッチの強みも自由度だけではありません。

ローコードは、その安全な基盤を元にあります。
もちろんAIを用いた開発も可能ですが、現状ではそこまで連携は強くなく、ローコードならではのつまりどころを抑えながら使用していく必要があります。

フルスクラッチでは、壊れる場所を察知できるようになったと書きました。
これはすなわち、先回りして地雷をつぶしたり、AIに作らせる場合でも要件に入れておくことで問題の発生を防ぐことができます。
もちろん問題が発生した後からエラーコードをAIに渡して対処することもできるでしょう。でも、問題の輪郭を掴める人間がいるのといないのとでは、対応の速さや精度が大きく変わります。

4. だから、うちのチームはこうしている

AIが「速さ」を民主化した今、差別化は2つのところにあると思っています。

ひとつは、どのエコシステムの上で安全に動かせるか
もうひとつは、問題が起きたときに輪郭を掴める人間がいるか

弊社では、ローコードとフルスクラッチの両方を組み合わせた開発の中に、AIを活用しての開発を進めています。
それができるのは、両方を経験し、酸いも甘いも嚙み分けてきたエンジニアが揃っているからです。

「ノーコードで始めたけど、どこかでコードが必要になる気がする」
「どちらで作るべきか判断できない」
そういう場面でも、「どちらで作るべきか」の判断から一緒にできる、というのが弊社の強みだと思っています。

実家がなくなっても、修学旅行の木刀は手元に残っています。
コードを書く理由も、今はもうはっきりしてきました。「手放せないから」じゃなくて、「これが必要な場面を、自分たちは知っているから」です。
物干し竿として、木刀は今も我が家で活躍しています。

最後に

弊社では、ローコードとコードの両方を扱えるエンジニアが一緒に働いています。

「ノーコードで始めたけどコードが必要になってきた」「どちらで作るべきかわからない」----そういった判断の段階から、ご一緒できます。PowerPlatformのエコシステムを活かしながら、限界が来たときのフルスクラッチ開発まで、一気通貫でご支援できるのが弊社の強みです。

また、「ノーコードもコードも両方やってみたい」「手を動かして、なぜ動くかを確かめることが好き」という方とも、ぜひ一緒に仕事がしたいと思っています。そういう姿勢を大事にしているチームです。

開発のご相談でも、採用のお問い合わせでも、ぜひ弊社にお声がけいただけたらと思います。

お気軽にご依頼・ご相談ください

前へ

ナイーブデザインとは?AIが"完璧"を量産する時代に、あえて"不完全"を選ぶ理由