こんにちは！株式会社ジャパン・エンダストリアルの杉山純一です。

今日は、自分自身のコーディングにおける基本方針を改めて言語化しておこうと思います。

私は普段、Power Apps や Power Automate などのローコードツールを使って、社内外の業務課題を解決するためのアプリや仕組みを構築しています。技術的にはそこまで難しいことをしていなくても、設計や実装の方針によって、完成するシステムの質や使いやすさ、将来の保守性は大きく変わってきます。

たとえば、「とりあえず動けばいい」という姿勢で作ったアプリは、納品直後こそ問題なく見えても、数ヶ月後に機能追加や仕様変更が入ったときに破綻することが少なくありません。逆に、シンプルだけれど意図が明確で、再利用や修正がしやすいコードは、時間が経っても価値を持ち続けてくれます。

アプリ開発でも業務自動化でも、「コードを書くこと」は目的ではなく手段です。私たちが本当に目指すべきなのは、「そのコードによって現場の業務がどれだけ楽になるか」「誰が使っても迷わないように設計されているか」といった成果の部分です。

だからこそ、効率的で、分かりやすく、無駄のないコーディングを日々意識していきたい。
そんな想いから、今回は自分のコーディング方針を振り返り、整理してみました。

その中で私が大切にしているのが、次の3つの原則です。

これは世界で広く使われている「コーディングの鉄則」

実はこの3つの原則は、私が個人的に思いついたものではなく、ソフトウェア開発の世界で広く知られた有名な考え方です。

  • YAGNI（You Aren’t Gonna Need It）：今必要じゃない機能は作らない
  • DRY（Don’t Repeat Yourself）：同じコードを繰り返さない
  • KISS（Keep It Simple, Stupid）：シンプルに保つ

これらはアジャイル開発やプログラマ向けの名著でもたびたび登場する「基本中の基本」。
ローコードやノーコードの開発であっても、十分に通用する、再現性と保守性を高めるための普遍的なルールだと感じています。

1. 今必要じゃない機能は作らない（YAGNI）

You Aren’t Gonna Need It＝「どうせ使わない機能は作るな」

「いつか必要になりそうだから」と手を出しそうになる機能、ありますよね。
でも私は、「そのときが来たら作ればいい」という考え方で進めています。

  • 将来の予測は大抵外れる
  • 今の開発やテストが複雑になる
  • メンテナンスコストが増える

現場でよく言われる「まず動くものを作る」の実現にも、この考え方はつながっています。

2. 同じコードを繰り返さない（DRY）

Don’t Repeat Yourself＝「同じことを何度も書かない」

コードをコピペして似たような処理をあちこちに書いてしまうと、後で変更するときに大変です。
一箇所直しても、他を直し忘れてバグが起きることも。

Power Apps なら 変数（Set, UpdateContext）やカスタム関数を使ってまとめる、
Power Automate なら スコープ化や再利用可能なサブフローを活用する、などの工夫が有効です。

3. シンプルに保つ（KISS）

Keep It Simple, Stupid＝「とにかくシンプルに」

複雑な処理や凝ったUIを作っても、それを使う人・直す人が混乱してしまっては本末転倒です。

  • 条件分岐を整理する
  • 不要な装飾や処理を削ぎ落とす
  • 誰が読んでもわかる構造にする

「自分が1か月後に読んでもすぐ理解できるか」を意識しています。

おわりに

この3つの原則（YAGNI・DRY・KISS）は、私にとっての開発に向き合う姿勢そのものです。
とくにノーコード・ローコードの開発現場では「とにかく早く動くものを出す」ことが求められる一方で、
その裏側にある設計や整理の力がプロジェクトの成功に直結します。

地味かもしれませんが、こうした基本を忘れないことが、チームやユーザーにとって一番の優しさになると信じています。

今後はこれらの原則を活かして、Power Apps や Power Automate における具体的な事例も共有していきますね。
ご興味があれば、ぜひまた読みにきてください！