LASSIC Media らしくメディア

設計レビューの場で「このロジックは宣言的に書けないか」と指摘され、返答に詰まった経験を持つIT事業部の担当者は少なくないでしょう。宣言型と命令型は、プログラミングの考え方を語るときにたびたび登場する対比です。実装の細部まで踏み込まない立場からすると、両者の違いがどこにあり、何を基準に見極めればよいのか分かりにくいところがあります。本記事では、この二つの考え方の違いを身近な例とともに整理し、発注やレビューの場面でどう活きるかをまとめたものです。専門用語の暗記ではなく、コードや設計を見るときの視点として持ち帰っていただける内容を目指します。エンジニアとの会話で頻出する対比だからこそ、一度整理しておく価値があるテーマといえるでしょう。

宣言型と命令型でつまずくポイント

エンジニアからの提案書や見積もりの説明で「宣言型で書くと保守性が上がる」「ここは命令型で細かく制御している」といった言葉が出てくることがあります。言葉自体は難しくないものの、具体的に何を指しているのかが曖昧なまま議論が進むと、レビューの論点がずれてしまいがちです。よくあるつまずきは次の三つに整理できます。

• 命令型・宣言型という言葉を、特定のプログラミング言語や製品名だと誤解してしまう
• 「どちらが優れているか」という優劣の話だと捉え、技術選定の対立構造として受け止めてしまう
• コードの見た目（行数の多さ・少なさ）だけで判断し、意図が読み取れているか確認しないまま通してしまう

たとえば、あるレビュー会議で「この在庫チェックの処理、条件が入れ子になっていて追いにくいので、宣言的に書き直せませんか」というコメントが出たとします。実装担当ではない参加者からすると、この一言だけでは何を直してほしいのかが伝わりにくく、議論が止まってしまうことがあります。ここで求められているのは、決められた文法や製品を使うことではなく、「どの条件で在庫を数えたいのか」という結果を先に言葉にし、手順の枝葉を後から整理するという発想の転換です。用語の意味を押さえておくと、こうしたコメントの意図を素早くつかめるようになります。逆に、用語だけを覚えて実際のコードと結び付けられないままだと、レビューの場で相槌を打つだけになってしまい、判断材料としては活用しきれません。

宣言型・命令型は特定のツールや製品を指す言葉ではなく、処理の「書き方のスタイル」を指す概念です。まずはこの前提を押さえておくと、以降の説明が理解しやすくなります。実際のレビューの場では、この分類そのものよりも「なぜそのスタイルを選んだのか」という理由の方が、保守性の議論において重みを持ちます。言葉の定義を追いかけるだけで終わらせず、判断の背景を尋ねる材料として使えるかどうかが実務上のポイントになるでしょう。

命令型と宣言型、それぞれの考え方

両者の違いを一言でまとめると、命令型は「どうやるか（手順）」を書くスタイルであり、宣言型は「何が欲しいか（結果）」を書くスタイルです。手順を細かく指定するか、結果だけを示して手順は処理系に委ねるか、という視点の置き方の違いといえます。

命令型プログラミングとは

命令型は、目的の結果にたどり着くための手順を一つずつ順番に記述するスタイルです。「まずこれをして、次にこれをして」という具合に、コンピューターに対して逐一の操作指示を与えていきます。料理でいえば、レシピを一手順ずつ実行していくイメージに近いところがあります。「鍋に湯を沸かす」「野菜を切る」「湯に入れて三分煮る」というように、作業の順序と方法を自分で組み立てて指示する形です。手順を自分で組み立てる分、細部までの制御が利く一方、記述する分量は増えやすくなります。書き手は「途中でどんな状態になっているか」まで常に把握しておく必要があり、手順が増えるほど頭の中で追う要素も増えていきます。

宣言型プログラミングとは

宣言型は、欲しい結果そのものを記述し、そこに至る手順は言語や処理系（実行してくれる仕組み）に委ねるスタイルです。レストランで料理を注文する場面に近いたとえになります。客が伝えるのは「野菜多めのパスタを一つ」という欲しい結果であり、実際の調理手順（湯を何分沸かすか、どの順番で炒めるか）は厨房に任せます。欲しいものを言葉にすれば、手順の組み立ては相手が引き受けてくれる、という関係です。読み手からすると、途中経過を追わずに「最終的に何が実現するか」だけを読み取ればよいため、規模が大きいコードほど見通しの良さにつながりやすい傾向があります。

両者の違いは、コードを読むときの視点にも表れるところです。命令型のコードを読むときは、上から順に処理を追いながら頭の中で状態を再現していく必要があります。宣言型のコードを読むときは、個々の手順よりも「何を宣言しているか」を捉えれば、全体像をつかみやすくなるでしょう。この違いが、後述する可読性の差につながっていきます。読み手にとっての負担がどこにあるかを意識しておくと、コードレビューで指摘すべき箇所も見えやすくなるはずです。

この対比を表に整理すると次のようになります。

なぜこの区別が実務に役立つのか

この区別を知っておく利点は、コードの良し悪しを議論するときの共通言語が手に入ることにあります。「読みにくい」「直しにくい」という感覚的な指摘だけでは、次にどう直すべきかまでは伝わらないものです。そこで「この部分は手順が多すぎるので、欲しい結果を先に定義してから手順を整理し直せないか」という具体的な問いかけに変換できると、レビューが建設的な方向に進みやすくなります。逆に、無理に宣言的な表現へ寄せようとして、かえって読みにくくなるケースもあるため、区別を知ることは「宣言型にすべき」という結論を急ぐためのものではなく、選択肢を広げるための視点だと捉えておくとよいでしょう。

境界がはっきりしない例もある

ここまで命令型・宣言型をはっきり分けて説明してきましたが、実際のコードでは境界が曖昧な書き方も多く存在します。たとえば、一件ずつ処理する繰り返し部分を、あらかじめ用意された部品（一覧から条件に合うものだけを取り出す、といった処理をまとめた命令）に置き換えると、内部では繰り返しが行われていても、書き手から見ると「欲しい結果の条件」を並べているように見える書き方になります。これは命令型の要素を土台にしながら、宣言型に近い読み味を持たせた中間的な例といえるでしょう。分類そのものにこだわりすぎず、「今読んでいるコードは、手順を追う必要があるか、結果だけを追えばよいか」という視点で捉えると、実務では扱いやすくなります。

身近な例で見る違い

言葉の定義だけを追っていても実感がわきにくいため、ここからは日常的に目にする技術要素を例に、命令型・宣言型のどちらに近いかを具体的に見ていきましょう。自社のシステムやWebサイトの構成要素と照らし合わせながら読むと、理解が定着しやすくなるはずです。

身の回りの技術要素にも、命令型的な書き方と宣言型的な書き方の両方が存在しています。代表的な例を並べると、次のように整理できます。

この表からも分かるように、宣言型に分類される例は「見た目」「問い合わせ」「あるべき状態」といった、結果そのものを言葉にしやすい領域に多く見られます。反対に、業務の細かい分岐や、外部システムとのやり取りの順序が重要になる処理では、命令型の書き方が残りやすいでしょう。どちらが多いかはプロジェクトの性質によって変わるため、一概にどちらの比率が望ましいとは言えません。

同じ「有効な明細の金額を合計する」という処理を、命令型と宣言型それぞれの疑似コードで書き比べると、視点の違いがつかみやすくなります。

命令型（擬似コード）

合計 = 0
for (i = 0; i < 明細件数; i++) {
  if (明細[i].ステータス == "有効") {
    合計 = 合計 + 明細[i].金額
  }
}

宣言型（擬似コード・SQL）

SELECT SUM(金額) FROM 明細 WHERE ステータス = '有効';

命令型の側では、変数の初期化・繰り返しの範囲・条件分岐・加算という手順を一つずつ自分で組み立てています。宣言型の側は「有効な明細の金額を合計してほしい」という結果だけを示し、実際にどの順で走査し、どう加算するかはデータベースのエンジンに委ねている形です。どちらも最終的に得られる値は同じですが、書き手が背負う範囲が異なる点に注目してください。

この違いは、仕様変更が入ったときにより分かりやすくなります。たとえば「今月に発生した明細のみ合計したい」という条件が追加されたケースです。宣言型のSQLでは、条件を一つ書き足すだけで済みます。

SELECT SUM(金額) FROM 明細 WHERE ステータス = '有効' AND 発生月 = '今月';

一方、命令型の擬似コードでは、条件分岐の中にさらに判定を追加する必要があり、既存の繰り返し処理そのものに手を入れることになります。

合計 = 0
for (i = 0; i < 明細件数; i++) {
  if (明細[i].ステータス == "有効" && 明細[i].発生月 == 今月) {
    合計 = 合計 + 明細[i].金額
  }
}

結果として得られる値は同じでも、変更が入る箇所の性質は異なります。宣言型では「条件」という宣言の中身を書き換えるだけで完結しますが、命令型では手順の内部に条件を組み込む作業が発生し、既存のロジックに手を加える範囲がやや広がる傾向があります。仕様変更のたびにどちらの負担が大きくなりやすいかを意識しておくと、設計相談やレビューの際の判断材料になるでしょう。

ここまでの内容を図にすると、命令型は手順を一段ずつ積み上げていく縦の流れとして、宣言型は欲しい結果を示した先に処理系が控えている構図として捉えられます。次の図では、左側に命令型の三段階の手順を、右側に宣言型で「欲しい結果」を示すとその先の処理を処理系が引き受ける流れを示しています。

メリットとデメリットを整理する

どちらの書き方にも、得意な場面と不得意な場面があります。片方だけを採用すればすべてが解決するというものではなく、それぞれの強みと弱みを踏まえたうえで組み合わせていく発想が求められるでしょう。発注やレビューの判断材料として、次の整理が参考になります。

宣言型は「何を実現したいか」が読み手に伝わりやすく、レビューの負担を軽くする効果が期待できます。一方で、細部までの調整が必要な処理では、命令型の方が扱いやすい場面も残ります。優劣というより、場面ごとの向き不向きとして捉えるのが妥当でしょう。

先述の合計処理の例で考えると、条件の追加や変更が頻繁に発生する業務ロジックであれば、宣言型に寄せた書き方の方が変更の見通しが立てやすくなります。反対に、処理の途中経過ごとにログを残したい、特定のタイミングだけ例外的な扱いをしたいといった細かな制御が求められる場面では、命令型で手順を明示した方が意図を伝えやすいこともあります。どちらのスタイルを選ぶかは、変更の頻度や制御の粒度といった観点から検討するとよいでしょう。

レビューの場でどちらのスタイルが選ばれているかを確認するときは、次のような観点で質問を投げかけると、判断の背景を引き出しやすくなります。

こうした観点を用意しておくと、コードの見た目だけで良し悪しを判断するのではなく、選択の背景まで踏み込んだレビューがしやすくなります。

現場での使いどころと注意点

両者が混在するのが実際の姿

実際のシステムでは、宣言型と命令型が一つのコードベースの中に混在しているのが通常です。画面の見た目はHTML・CSSで宣言的に組み、データの取得はSQLで宣言的に問い合わせ、業務ロジックの細かい分岐は命令型のコードで書く、というように使い分けられています。どちらか一方だけで作られたシステムはむしろ珍しいものです。フレームワークや部品が宣言的な記述をサポートしている領域では宣言型に寄り、業務固有の細かな例外処理が求められる領域では命令型が残る、という濃淡が生まれるのが自然な状態だといえるでしょう。

レビューでの活用場面

発注やレビューの場面では「この処理は宣言的に書けないか」という問いかけが、保守性を高める議論のきっかけになります。たとえば、複雑な条件分岐が積み重なった命令型のコードを見たとき、「欲しい結果」を先に言葉にしてみると、本来の目的と手順の枝葉が整理され、レビューの論点が明確になるでしょう。逆に、細かな制御が求められる処理を無理に宣言的な書き方へ寄せようとすると、かえって分かりにくくなる場合もあるため、目的に応じた判断が求められます。

見積もり段階では、宣言的に書ける範囲が広い機能ほど、後々の仕様変更に対する追従コストを抑えやすくなるでしょう。逆に、命令型の記述が多く残る見込みの機能については、変更が入るたびにどの手順まで手を入れる必要があるかを、事前にエンジニアと確認しておくと、追加開発の見積もりのブレを小さくしやすくなります。

見積もりやドキュメントでの伝え方

提案書や仕様書に「宣言的に実装する」「命令的な制御が必要」といった表現が出てきた場合は、その部分がどのような性質を持つ処理なのかを確認しておくと、後工程での認識のずれを防ぎやすくなります。具体的には「その処理は今後どのくらいの頻度で条件が変わりそうか」「変更の際に手を入れる範囲はどこまで広がりそうか」という二点を尋ねてみると、記述スタイルの選び方が実際の開発負荷にどうつながるかが見えてくるでしょう。ドキュメントに残す際も、専門用語をそのまま転記するのではなく、「条件を追加するだけで対応できる部分」「手順そのものを見直す必要がある部分」という言い換えを添えておくと、非エンジニアの関係者にも共有しやすい資料になります。

差別化のための補足

なお、本記事は特定のIaC（インフラ構成管理）ツールや構成自動化の導入解説ではなく、宣言型・命令型という記述スタイルの概念と考え方に焦点を当てるものです。構成管理ツールの選定や導入手順を検討する際は、別途その領域に特化した情報を参照してください。

PMや発注担当者の立場では、実装の細部まで理解する必要はありません。ただし「どちらのスタイルで書かれているか」「なぜそのスタイルを選んだのか」をエンジニアに尋ねる視点を持つだけで、見積もりの妥当性や保守性についての会話が具体的になっていきます。専門用語を暗記することよりも、判断の理由を聞き出す姿勢の方が、日々のプロジェクト運営では役立つはずです。

エンジニアとPM・発注担当者の間で、こうした記述スタイルの話題が共通の話題として扱えるようになると、レビューの往復回数や仕様変更時の認識合わせにかかる時間を抑えやすくなります。技術的な正しさだけでなく、チーム内でどう伝え合うかという観点からも、宣言型・命令型という区別は覚えておいて損のない考え方だといえるでしょう。今後、提案書やコードレビューのコメントでこの言葉に出会ったときは、まず「結果を示しているのか、手順を示しているのか」を確認するところから会話を始めてみてください。

まとめ

宣言型と命令型の違いは、専門用語として暗記するものではなく、コードやドキュメントを読むときの視点として身につけておくと役立つ考え方です。要点を次のように整理しておきます。

• 命令型は「どうやるか（手順）」を、宣言型は「何が欲しいか（結果）」を記述するスタイル
• 身近な例では、ループ処理は命令型、SQL・HTML/CSS・設定ファイルは宣言型に分類される
• 宣言型は可読性に強みがあり、命令型は細かい制御に強みがある
• 現実のコードは両者が混在しており、優劣ではなく目的に応じた使い分けが基本
• 仕様変更のたびにどこまで手を入れる必要があるかは、スタイルによって範囲が異なる
• レビューでは「宣言的に書けないか」という視点が保守性の議論に役立つ
• 本記事はIaCツールの導入解説ではなく、記述スタイルの考え方そのものを扱う内容

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

出典

本記事の記述にあたり参考にした一次情報は次のとおりです。

• MDN Web Docs 用語集「CSS」（Mozilla）
• MDN Web Docs 用語集「SQL」（Mozilla）
• React公式ドキュメント日本語版「stateを使って入力に反応する」

Tweet