「ある事物について『知る』とは、その原因を知ることである」——アリストテレス
要件定義でつまずくたびに、この言葉が気になります。顧客の要望を、機能一覧に整理し、仕様書に落とし込む。その過程で私たちは、そのシステムをどれくらい『知って』いるのだろうか。
後工程で浮上する抜け漏れの多くは、表面的なヒアリングでは見えないところにあります。「なぜこの要件が落ちていたのか」と頭を抱える経験は、誰もが一度はあるのではないでしょうか。
本稿では、2500年前のアリストテレスが整理した「四原因説」を、要件定義の実務に接続し、抜け漏れの正体を構造として可視化するための、ひとつの思考の型として紹介します。
1. なぜ 2500 年前の哲学が、現代の要件定義に効くのか
まず、違和感を先に解いておきたいと思います。
古代ギリシャの哲学と、現代のシステム開発は、一見まったく別の世界のものに見えます。ただアリストテレスが取り組んだのは、「あるモノが、なぜ・どうやって・何から・何のために存在するか」を言語化する作業でした。これは、システム開発で要件を取りにいく仕事と、実は同じ種類の作業です。
要件定義の現場で起きているのは、顧客の頭の中にある「作りたいモノ」を、複数の角度から言語化して整理することです。どこか一角度だけを見てしまうと、別の角度の情報が落ちる。哲学が扱う思考の枠組みは、こうした「モノを多角的に捉えて言い当てる」ための道具として、現代でも機能します。
アリストテレスが『自然学』と『形而上学』で示した 四原因説 は、モノの存在を四つの側面から捉え直すフレームです。
- 質料因（Material Cause）：そのモノを構成する素材・要素
- 形相因（Formal Cause）：そのモノの形・構造・本質
- 作用因（Efficient Cause）：そのモノを生み出す・変化させる働き
- 目的因（Final Cause）：そのモノが存在する理由・最終的な目的
古代ギリシャでは、机や彫像、家屋の成り立ちを説明する枠組みでした。これをシステムに置き換えると、要件定義で落とすと致命傷になる観点が、ほぼそのまま現れます。
2. 四原因の欠落が引き起こす、見えない抜け漏れ
四つの原因のどれかが検討から抜けると、要件には特徴的なパターンの穴が空きます。ここでは、それぞれの欠落がもたらす実務上の症状を並べます。
目的因の欠落：「何のために作るのか」が曖昧なまま進む
ビジネス成果や利用者の課題が共通言語化されないまま、機能の詰め合わせだけが先に決まる状態です。プロジェクト途中でスコープクリープが頻発し、稼働後に「期待と違う」という声が上がる典型パターンです。
抽象的な「業務効率化」「DX 推進」だけが共有されていて、成功を測る指標が誰にも言えない、という徴候で見つかります。
形相因の欠落：全体像・構造への視点が後回しになる
個別機能の要件は細かく出ているのに、それらがどう連携してひとつのシステムになるかが考えられていない状態です。UI/UX の一貫性が失われ、機能どうしの整合に齟齬が生まれやすくなります。
「機能を全部書き出せば要件定義は終わる」という誤解が温床です。全体として何の形をしているかの問いが抜けます。
質料因の欠落：データ・技術の土台が見落とされる
扱うデータ項目やその構造、既存システムとの連携、選定する技術スタックが議論されないまま進む状態です。開発中盤でデータ移行の難しさが露呈し、再設計が必要になる展開が起きます。
専門性が高い領域ほど「当たり前」と見なされて深掘りされにくく、土台の前提確認が抜けるのが特徴です。
作用因の欠落：処理ロジックと非機能が甘いまま進む
機能ごとの処理フロー、性能・セキュリティ・可用性といった非機能要件、運用・保守のプロセスが定義されていない状態です。本番稼働して初めて運用が回らないことに気づく、という厳しい展開になりがちです。
見えにくく後回しにされやすい領域ですが、どう動かし続けるかを問う作用因の視点は、運用品質を決める分水嶺になります。
要件定義における「見えない抜け漏れ」の正体は、四原因のどれか——または複数——が十分に検討されていない状態にある、と整理できるのではないでしょうか。
3. 明日から使える、四つの問いの型
この四つの視点は、要件ヒアリングやドキュメントレビューの場面で、実際の問いに翻訳できます。以下は一例です。顧客がアリストテレスを知らなくてもまったく問題ありません。問いの型だけを自分の手元に置いて、ヒアリングのチェックポイントとして使うのが実用的です。
目的因：何のために作るのか
- このシステムで、利用者はどんな課題を解決できますか
- 導入によって、具体的にどんなビジネス成果を目指していますか
- プロジェクトの成功を測るための、最も重要な指標は何でしょうか
目的因の問いは、プロジェクト開始時と、中盤のスコープ判断で効きます。「これは本当に目的に貢献するか」という判断軸がここに宿ります。
形相因：どういう形・構造で実現するか
- このシステムで、もっとも重要な機能やユーザーに不可欠な操作は何ですか
- システム全体の見た目や操作感について、どのようなイメージをお持ちですか
- 情報はどのような流れで処理されていくイメージでしょうか
形相因の問いは、全体像の絵を描くフェーズで使います。部分最適が進みすぎる前に、システムの姿そのものを言葉にする工程です。
質料因：何で作るのか（データと技術の土台）
- このシステムで管理・利用する情報にはどんなものがありますか
- 既存のシステムで、今後も連携が必要なものはありますか
- データの保存・管理について何か要望はありますか
質料因の問いは、基盤設計と既存資産棚卸しの場面で効きます。ここを浅くすると、後で必ずコストに跳ね返ります。
作用因：どう動かし続けるのか
- この機能は、具体的にどんな手順で動作する必要がありますか
- 応答速度や同時アクセスなど、性能についての要件はありますか
- 障害やトラブルが起きたとき、どんな対応を想定しますか
作用因の問いは、詳細設計と運用設計のフェーズで効きます。動くことだけでなく、動き続けることまでが視野に入ります。
四つの問いは、同時に使うのではなく、フェーズに応じて重みを変えるのが実務的です。構想段階は目的因を深く、基本設計では形相因と質料因を往復、詳細設計では作用因を丁寧に。
顧客がこの枠組みを知らなくても、質問として投げかければ自然に会話が成立します。「〇〇のために、何をどうやって、何で動かすか」という流れは、どんな業界でも通じる構造なのではないでしょうか。
4. 四原因の向こう側にあるもの
「すべての人は、本性上、知ることを欲する」——アリストテレス『形而上学』冒頭
アリストテレスが四原因説に進んだのは、彼自身が「知りたい」という欲求に正直だったからです。整然としたフレームに見える四原因は、もともと彼の知的好奇心を形にしたものであり、答えというより問いの整理箱でした。
要件定義で私たちが握っているのは、同じ箱です。四つの角度から問うのは、網羅のためではなく、顧客の中にあるシステムを本気で知ろうとしているという姿勢の表明なのかもしれません。
フレームに従うよりも、この姿勢が先にあるほうが、抜け漏れは静かに減っていきます。四原因は目的地ではなく、「知ろうとする」ことの形を取り戻すための道具として置かれている——そう読み直すと、2500年の時差が急に近く感じられます。
まとめに代えて
アリストテレスの四原因説は、要件定義のためのチェックリストではありません。システムというモノを、どれだけ多角的に『知ろうとしているか』を自分に問い直す、思考の足場です。
明日の要件定義で、質問を投げる前に一瞬だけ立ち止まる。「この要件は、四原因のどこを扱っているのだろう」と自分に問う。それだけで、抜け落ちやすい視点に気づく確率が変わってきます。
2500年前に書かれた言葉が、今日のプロジェクトのどこを照らしているのか。その接続に手応えを感じられたなら、それ自体が要件定義の質を少しだけ底上げしているのではないでしょうか。
