ノーコード・ローコード開発においてどこまで設計書を作るか

ノーコード・ローコードプラットフォームでは非常に簡単に開発ができるため、設計書は必要か？メンテコストがかかるだけではないか？という議論が出ます。これについて、日々ノーコード・ローコードプラットフォームであるServiceNowで開発している経験をもとの考えたのでシェアします。なお、この記事は社内システム開発を前提としています。

結論:
・要件と開発物が近い場合（自然言語を書くように開発ができる場合）は設計書は不要だが、距離がある場合は必要
・開発物（コンポーネント）同士の繋がりを示す設計書は必要

前提 要件定義の要否について

そもそも要件定義すらいらず、まずモノを作ればよいという人もいますが、私はこちらについては反対で、システム導入には投資が発生する以上、そのシステムによって誰がどう嬉しくなるか、どうなったら納得できるか、というゴール（要件）が明確になっているべきだと考えます。ただし、かっちりとしたものである必要はなく、概念的な図であったり、ユーザーストーリーでも構いません。システムが提供する価値が明確になっていればよいと思います。

以前先輩から「要件定義」ではなく「価値定義」をしたら後はシステムを作ればいいじゃんという話を聞きました。この意味であれば要件定義は不要と言ってもよいかもしれません。

前提 ノーコード・ローコード開発の特長

設計書の要否を考える前提として、設計書の有無を考える上で重要になるノーコード・ローコード開発の特長について書いておきます。

■ 開発の少人数化
ノーコード・ローコード開発では開発それ自体が圧倒的に簡単になるため、より少ない人数で開発ができるようになります。何千、何万人の全社員が使うシステムを2,3人で作るということも珍しくありません。

■ 要件とシステムの距離が近い
プロコード開発（スクラッチ開発）では、自然言語で書かれた要件が最終的にプログラミング言語に翻訳される必要があったので、その翻訳機として設計書を作成する必要がありました。しかし、ノーコード・ローコード開発では、システムが画面上での設定によって作成でき、場合によってはその設定は自然言語を読むように読めるため、要件とシステムの距離が近くなったと言えます。

前提 ガバナンス

こちらでも書いたように、ノーコード・ローコードでは開発が簡単なため、トレーニングやプラットフォームの統制強化が行われていないと無秩序な開発が行われてしまいます。こうなると、今どのような開発が行われているか把握されていないとか、互いに影響調査などもされずに好き勝手システムが作られリリースされるという設計書を作る作らないどころの騒ぎではなくなってしまう可能性があるので、ここではプラットフォームについて十分な知識を有している人が開発標準（開発規約）に従って開発を行っている、ガバナンスが効いた状態を前提とします。

ここからはなぜ設計書を作る必要があるか？という観点ごとに、各観点におけるノーコード・ローコード開発における設計書の存在意義を考えます。観点については下記の記事を参考にさせていただきました。

我々は、なぜ設計書を作成するのか

観点 完成イメージを共有する　⇒　不要

ノーコード・ローコード開発においてこの意味での設計書は下記3つの理由から不要だと思います

不要な理由① そもそもイメージを共有する必要がない場合も多い
設計書を作ってイメージを共有する必要があるのは、要件とシステムとの間のギャップが大きかったり、要件がシステムとして実現されるまでに多くの人の手を介するからです。しかし、前提で述べたようにノーコード・ローコード開発では要件とシステムの距離が近く、関わる人数が少ない場合が多いため、イメージがずれる可能性が少ないです。

不要な理由② プラットフォームによるアーキテクチャ制約があるため、完成イメージがずれにくい
これはプラットフォームにもよりますが、ノーコード・ローコードではそのプラットフォーム特有のアーキテクチャが存在し、スクラッチ開発に比べ自由度が少ないです。そのため、要件をどのようにシステム化するかといった完成イメージがずれにくいと言えます。開発標準・開発規約が用意されている場合はなおさらです。

不要な理由③ 仮にイメージがずれていても手戻りコストが小さい
これが最も大きな理由です。ノーコード・ローコード開発では実際に開発するのにかかる時間が圧倒的に少ないため、すぐに動くシステム（プロトタイプ）を作り、それを使って完成イメージをすり合わせるほうが、丁寧に設計書を作成するよりも早い場合が多いです。

観点 開発者への指示書としての設計書（詳細設計書）　⇒　場合による

この意味では、要件とシステムが近い場合（自然言語を書くように開発ができる場合）は設計書は省略可能だが、距離がある場合は必要だと思います。

要件とシステムが近い場合（自然言語を書くように開発ができる場合）
こちらは具体例を挙げます。下記はServiceNowでメールなどの通知を送信するための設定です。

この画面を見れば、ServiceNowの知識が全くない人でも「ユーザテーブルに新しいadmin権限を持つユーザ作成されたとき」にメールが通知されるんだな、ということがわかると思います。この場合、要件がほぼそのままシステムに落とし込まれるため、設計書るだけ時間の無駄と言えます。

要件とシステムが遠い場合
こちらはどうでしょう。ユーザ情報をインポートする際の、インポート側のカラムとユーザテーブル側のカラムとマッピングです。

インポートデータの"Source field"の値がユーザマスタの"Target field"に入りそうだということはわかりますが、"Coalesce"、"Choice action"はServiceNowの仕様を知っていないと理解できないと思います。このような自然言語の要件とシステムの間にギャップがある場合は、いわゆるデータマッピングシートなどの設計文書が必要です。

観点　運用・保守の負担を軽減する　⇒　必要

この意味での設計書は依然として必要だと考えています。

新たな保守メンバが入ってきたときや、システムを改修する際など、現在動いているシステムの仕様を理解したり、変更による影響を調査する必要があります。

プロコード開発（スクラッチ開発）の場合、例えばあるテーブルにレコードが挿入され得る箇所を特定したければ、コード全体で特定のSQL文を実行している箇所を検索すれば洗い出すことができるでしょう。

一方で、ServiceNowの場合、例えばあるテーブルにレコードが挿入されるのは、ワークフローから自動で挿入される場合もあれば、別のテーブルのCRUDをトリガとするスクリプトの中でレコードが作られる場合もあれば、ユーザがフォームから挿入する場合もあり、これらは一括で検索することができません（実際の処理を行うコードはプラットフォーム側に隠されている）。そのため、設計書がなければ考えられる設定箇所をしらみつぶしに当たっていく必要があります。実際の処理を行うコードがプラットフォーム側に隠されるという性質上、これはServiceNowに限らず多くのノーコード・ローコードプラットフォームで困っている人がいるのではないでしょうか。

このような場合を考えると、コンポーネント図のような、開発物（コンポーネント）同士がどのようにかかわっているか、を示す設計資料がは必要ではないかと考えます。

結論

冒頭の繰り返しですが、以上を踏まえると現時点での私の考えとしては下記の通りです。
・要件と開発物が近い場合（自然言語を書くように開発ができる場合）は設計書は不要だが、距離がある場合は必要
・開発物（コンポーネント）同士の繋がりを示す設計書は必要

補足　成果物としての設計書

最後に補足として「成果物としての設計書」にも触れておきます。主にITベンダが開発を行う際に「我々はこの仕様で合意し、このように設計し導入をしました」という成果物・証跡として設計書を残すことがあります。ユーザ企業側も検収の条件として設計書を含む包括的なドキュメントを求める場合があります。実際の現場では、こうした実際にシステム開発に役立つかとは別の契約上の理由で設計書を作ることが多いと思います。今回はこうした現実は理解しつつも、あくまでノーコード・ローコード開発を効率的に行うために設計書は必要か？という観点で考えてみました。