業務に最適化されたはずのシステムが、かえって現場の足かせになる。そんなジレンマに心当たりのある方は少なくないのではないでしょうか。発注側と開発側のすれ違いは、仕様書に書ききれない「業務の本質」にこそ原因があるのかもしれません。
そこで今回、放送大学の中谷多哉子教授に、要求工学が支える業務改革とシステム開発の合理化について独自取材を通じてお話を伺いました。
業務の変革と合理化を無理なく進めるために、関係者は何を共有すべきなのか、中谷教授のお話からヒントを探っていきましょう。
放送大学 情報コース
中谷多哉子(ナカタニ タカコ) 教授
東京理科大学理I学部応用物理学科を卒業後、
東京大学大学院総合文化研究科広域科学専攻広域システム科学系にて博士(学術)を取得。
2001年に有限会社エス・ラグーンを設立、取締役社長に就任。その後、2015年より現職に至る。
〈研究分野〉
情報通信・ソフトウェア
〈著書・論文〉
中谷多哉子, 中島震著「ソフトウェア工学(’25)」，放送大学教育振興会(2025)
中谷多哉子，大西淳著「要求工学(’24)」，放送大学教育振興会(2024)
情報サービス産業協会編著, 要求工学知識体系REBOK , 近代科学社(2011)
要求工学とは何か—業務改革とシステム開発における基礎的視点
カードローンの窓口合同会社 編集部：ソフトウェア開発の場では、「要求工学」という単語を耳にすることがあります。この「要求工学」とは一体何か、ソフトウェア開発における役割なども含めて教えていただけますか？
中谷教授：前提として、ソフトウェア開発というのは、単にプログラムを書くことではありません。
「何をどう作るのか」という前段階、つまり「何が必要か」を定義するところから始まります。
その「何を作るか」を定義する領域が、まさに要求工学の担う部分なのです。
カードローンの窓口合同会社 編集部：最初にしっかりと「作るもの」を決めることが、その後のすべてに繋がるわけですね。
中谷教授：そうです。ここが曖昧なままスタートしてしまうと、「業務上のどこが問題なのか」「どこを改善したいのか」「どのように効率化を図るべきなのか」といった点が明確になりません。
結果的に、業務上のどのような問題を解決したのかが分からないシステム」ができあがってしまいます。
だからこそ、ソフトウェア開発の入り口にあたる「要求定義」と呼ばれる工程が非常に重要なのです。
カードローンの窓口合同会社 編集部：要求定義をおろそかにすると、その後の工程にも大きく影響が出てしまうのですね。
中谷教授：はい。とはいえ、最初の要求定義がしっかりしていても、「どう作るか」の設計工程でミスがあれば、仕様変更が難しくなり、業務改革に柔軟に対応できなくなってしまいます。
また、プログラミングの段階で外部からコピーしてきたコードを使った場合、それに不具合が含まれていれば、そのままシステムに不具合が引き継がれることになります。
つまり、ソフトウェア開発では、要求定義・設計・実装・テストといったすべての工程が重要で、どこか1つでも手を抜くと、後々大きな障害に繋がるのです。
カードローンの窓口合同会社 編集部：要求定義はソフトウェア開発の土台ですが、その後の工程もすべて欠かせない大切な要素なのですね。ちなみに、実際の現場ではどのように要求定義を行っているのでしょうか？
中谷教授：最初にするのは「誰に聞くべきかを決めること」です。
そして次に、「その相手に何を聞くのか」を明確にしてから、インタビューに臨む必要があります。
これを曖昧にしたまま進めてしまうと、後で情報の食い違いや誤解が生じやすくなってしまうからです。
カードローンの窓口合同会社 編集部：たしかに、現場では担当者ごとに違う意見が出ることもありますよね。
中谷教授：そうですね。Aさんはこう言っていたけれど、Bさんはまったく逆のことを言っているというケースはよくあります。
ただ、その時に「両方の意見を反映させましょう」としてしまうと、要求同士が矛盾してしまい、開発がうまく行かなくなってしまうのです。
だからこそ、要求分析者は間に入って調整、つまりネゴシエーションをして、「両者が納得できる落としどころ」を探し、両者の合意を取り付けていく必要があります。
カードローンの窓口合同会社 編集部：単にヒアリングして記録するだけではなく、意見のすり合わせも要求分析者の大事な役割なのですね。
中谷教授：はい。ネゴシエーションは非常に重要です。要求工学の中では、「どうやって相手の立場を理解し、合意に持っていくか」が求められますよ。
カードローンの窓口合同会社 編集部：なるほど。そうしたインタビューを経て作成する「要求仕様書」についてもお聞きしたいのですが、あれは具体的にどのような構成で作られるものなのでしょうか？
中谷教授：仕様書を作る際には、まず「目次の構成」をしっかり設計する必要があります。
どの項目をどの順番で書くのか、そしてそれぞれに何を書くのかということを決めてから書き始めないと、読み手にとっても開発者にとっても使いにくいドキュメントになってしまいます。
カードローンの窓口合同会社 編集部：構成の設計自体がすでに要求工学の一部なのですね。
中谷教授：その通りです。そして、作成した仕様書が「どれくらい良く書けているか」をどう評価するのかも重要です。
要求工学の研究者の中には、「仕様書の品質評価」「ヒアリング対象者の選定方法」「ネゴシエーションの進め方」など、さまざまなテーマに取り組んでいる人がいます。
要求工学が網羅する領域は広いですよ。
カードローンの窓口合同会社 編集部：同じ研究分野でも、そのテーマがこんなにも違うのは驚きですね！そんな要求工学は近年、業務改革でも重要だと伺ったのですが、実際にはどのような役割を果たしているのでしょうか？
中谷教授：前提として、業務改革、あるいは業務改善と呼ばれる領域では、「今どのような業務が行われているのか」「どの業務にどれだけの負荷やコストがかかっているのか」といった現状を把握するところから始めます。
その上で、「どこを情報システムで代替すれば、業務はどの程度変わるのか」「サービスの質をどの程度改善できるのか」といった分析を行い、そこから要求が生まれてくるのです。
カードローンの窓口合同会社 編集部：業務の可視化や課題の整理は、要求定義にも繋がりそうですね。
中谷教授：そうです。私は、「要求定義は業務改革の一部である」と考えています。
業務改革の目標を達成するためには、どのような情報システムが必要かを分析していく必要があります。
単に「こういう機能が欲しい」ではなく、「業務のこの課題を解決するには、どんな仕組みが必要か」という問いから始めないと、開発された情報システムが現場にフィットしなくなります。
カードローンの窓口合同会社 編集部：なるほど、目的が曖昧なままシステムだけを先に導入しようとすると、現場で活用されないという事態にもなりかねませんね。
中谷教授：まさにその通りです。要求工学が業務改革において重要な理由は、単なる聞き取りではなく、「何が本当に必要かを構造的に見つけていく」作業を支えるからです。
そのためにも、ヒアリング・ネゴシエーション・仕様書の構成・品質評価など、多様な視点と技術が求められますよ。
カードローンの窓口合同会社 編集部：ありがとうございます。先ほど「関係者にインタビューすると、矛盾する意見が出てくる」というお話もありましたが、実際の現場ではどういった矛盾が生じやすいのでしょうか？
中谷教授：典型的なのは「セキュリティ」と「使いやすさ」の対立ですね。
例えば、最近の金融システムでは、本人確認を厳格にするためにワンタイムパスワードをメールで送って、それを入力して認証を行う、という仕組みが導入されています。
これはユーザーIDの乗っ取りなどのリスクを回避するために必要ではありますが、ユーザーにとっては煩わしく感じるものでしょう。
カードローンの窓口合同会社 編集部：セキュリティを強化すればするほど、使い勝手は悪くなるというジレンマですね。
中谷教授：はい。金融のようにセキュリティを最優先すべきシステムであれば、それは当然として受け入れられるかもしれません。
しかし、一般的な業務システムなど、そこまでの厳格さが求められない場面でも同じ仕組みが求められると、ユーザー側としては「ここまでは必要ないのでは」と感じることもありますよね。
カードローンの窓口合同会社 編集部：利用者の立場からすれば、「もっと簡単に使いたい」と感じるのも自然だと思います。
中谷教授：システム開発の場面でも、「毎回パスワードを入力するのは面倒だから、もう少し簡略化できないか」といった声は出てきます。しかし、それを許すと当然セキュリティの水準は下がってしまうのです。
そのため、要求定義の際は「乗っ取られた場合に業務にどのような影響があるのか」「社会や顧客にどれほどの損害が出る可能性があるのか」といった視点から、丁寧に分析していく必要があります。
カードローンの窓口合同会社 編集部：たしかに、現場の背景や利用目的を無視して一律に設計してしまうと、かえってトラブルに繋がりそうです。
中谷教授：その通りです。実は最近の「備蓄米の供給遅れ」の問題も、構造としては非常に似ています。
あの問題は、複数の利害関係者がそれぞれの立場から「これが正しい」と信じて動いたことが発端です。その中で意見がぶつかり、全体として機能不全に陥りました。
ところが、政治的な判断で方向性が定まった途端に、状況が急に動き出しましたよね。
これはまさに、それぞれの「要求の優先順位」が矛盾していたことで起きた混乱の典型例だと思います。
カードローンの窓口合同会社 編集部：なるほど。要求定義というのは、あるべき正解を見つけるというよりも、現場の矛盾や違いを整理していく作業に近いのかもしれません。
中谷教授：おっしゃる通りです。だからこそ私は、「ヒアリングで得られた要求を鵜呑みにしてはいけない」と学生にも強く伝えています。
その要求がなぜ生まれたのか、どういう背景や価値観があるのかを読み解かなければ、本質にはたどり着けません。
例えば、「なぜこの複雑な経路を通さなければいけないのか」「本当にこの方法でなければならないのか」という疑問を持って掘り下げていく。そして、別の関係者にも聞きに行く。
そうした繰り返しの中で、初めて「何が最優先なのか」という判断ができるようになります。
カードローンの窓口合同会社 編集部：なるほど。聞き取った要求をそのまま仕様に落とし込むのではなく、その意味や背景まで深掘りすることが大切なのですね。
中谷教授：そうです。そして、要求定義の役割は「要望をまとめる」ことにとどまりません。
特に、セキュリティと利便性のように明確に対立する要求がある場合こそ、関係者の信念や前提を丁寧にすり合わせながら、ビジネス全体の目的に沿った「優先順位づけ」を合意形成していく必要があります。
そうしたプロセスを支えるのが、要求工学の本質的な意義だと私は考えています。
業務の個別最適が招くシステム開発の課題
カードローンの窓口合同会社 編集部：企業や組織がそれぞれの業務のやり方に独自性を持たせようとすることで、結果的にシステム開発が複雑化・高コスト化してしまうという話をよく聞きます。こうした事態が起きる背景や、典型的なパターンについて教えていただけますか？
中谷教授：そうですね。「うちは独自の運用をしている」と言う企業・組織は少なくありません。
実際、業務システムを導入しようとした時、「この機能は他と同じだから使えない」と言われることもあります。
そこから独自の機能を追加するためにカスタマイズが始まり、気が付くとシステム全体のコストの大半が「調整費用」になってしまうのです。
実際、本来であれば汎用的なパッケージで十分な部分までカスタマイズで対応しようとした結果、システム導入費の8～9割はがカスタマイズ費用に充てられた、というケースもあります。
カードローンの窓口合同会社 編集部：それだけ特注にしてしまうと、保守や将来的な改修も難しくなりそうですね。
中谷教授：はい。こうしたカスタマイズを重視する設計は、一見すると現状のやり方にぴったり合ったシステムに見えます。
しかし、いざ業務が変わったり、新しいニーズが出てきたりしたときに、柔軟に対応できなくなってしまうことがあるのです。
そのため、最近では「こだわりを捨てて、パッケージに業務を合わせて運用する」という考え方も広がりつつあります。
細かなこだわりは手作業や他の方法で補い、標準的な機能で回せる部分はそのまま活用する。それだけでも、システムの複雑化や高コスト化を防げるのです。
カードローンの窓口合同会社 編集部：とはいえ、パッケージに業務を合わせるには、組織側の意識転換も必要になりますよね。
中谷教授：そうですね。まずは「今までこうやってきたから」ではなく、「これからどうしたいか」を起点にすること、そして、開発したシステムを変更する運用コストまでを含めて開発の計画を考えることが大切です。
特に、社会状況の変化──例えばコロナ禍のような出来事があった時、既存のルールやシステムが足かせになることもありました。
カードローンの窓口合同会社 編集部：本来なら柔軟に対応すべき状況で、「システムの都合」に業務が縛られてしまったわけですね。
中谷教授：はい。例えば、大学ではリモート対応が求められた際に、「従来の時間割に沿わないとシステムが動かない」といった問題が起こることもありました。
しかし、それは本来、業務側で判断すべきことです。システムが業務を制限するようでは、本末転倒とも言えます。
カードローンの窓口合同会社 編集部：なるほど。「現行の運用を守る」ことよりも「将来の変化に備える」という観点が、システム選定には欠かせないのですね。
中谷教授：その通りです。システム選定をする際は、業務に合わせてシステムを作るのではなく、「業務を変えていけるシステム」を選ぶことが大切です。
一度システムにがんじがらめにされると、長期間変更できなくなる可能性もあります。まずはパッケージソフトを上手に活用して、必要に応じて他の方法を利用するところから始めてみても良いのではないでしょうか。
カードローンの窓口合同会社 編集部：ありがとうございます。やはり、最終的には「人の意識をどう変えていくか」が重要になりそうですね。
中谷教授：その通りです。業務改革においては、システム以前に考え方の転換が求められます。
例えば、「自分たちはこうしてきたから」と過去のスタイルに固執していると、どれほど優れたシステムでも力を発揮できません。
技術は日々進化しています。すべてを自分たちで抱えるのではなく、使えるサービスを柔軟に取り入れ、繋ぎ合わせていく。そういう考え方こそが、これからのシステム開発には必要なのではないでしょうか。
業務の「見える化」と共通理解—納得感のあるシステム開発のために
カードローンの窓口合同会社 編集部：これまでのお話でも、発注側と開発側の間で「要求仕様書だけでは意図のズレが生じやすい」という課題が指摘されました。このようなギャップを防ぐためには、どのようなアプローチが効果的なのでしょうか？
中谷教授：前提として、開発側は「どう作るか」という点に強い関心を持っています。例えば、登録・参照・更新といった機能要件を、仕様書に明確に記述することを重視するのです。
一方で、発注側が本当に知りたいのは、「システムが導入されることで業務がどのように変わるのか」という点です。ただ、そうした業務の変化について、発注者自身が明確に説明できないケースも少なくありません。
カードローンの窓口合同会社 編集部：たしかに、「どんな機能をつけるか」ではなく、「それで業務がどう変わるのか」のほうが重要だと感じる発注者は多そうですね。
中谷教授：だからこそ、システム開発では要求分析者という役割が重要になります。
要求分析者は、発注者の業務や環境を理解した上で、「何がどのように変わるのか」を整理し、それを開発側に正確に伝えられる仕様書を作っていきます。
カードローンの窓口合同会社 編集部：開発者と発注者、それぞれに渡すべき仕様書は異なるということでしょうか？
中谷教授：はい。例えば、ビジネス側との対話を通じて作成されるのが「ビジネス要求仕様書」、複数の関係者の意見を集約したものが「ステークホルダー要求仕様書」です。
これまでは、こうした文書が存在しないまま、いきなり「ソフトウェア要求仕様書」だけで開発が始まるケースが多くありました。
カードローンの窓口合同会社 編集部：そうなると、ビジネス的に譲れない部分が伝わらないまま、開発が進んでしまう可能性も出てきそうです。
中谷教授：そうですね。例えば、「年間でどれだけの停止時間が許容されるか」や、「どの部分までが保守対象か」といった稼働条件は、発注者にとっては非常に重要です。
しかし、それが仕様書に書かれていないことも多く、開発側に正しく伝わっていないという問題が発生しがちだったのです。
カードローンの窓口合同会社 編集部：お互いの目的や価値観がかみ合っていないまま話が進んでしまうのですね。
中谷教授：はい。だからこそ、要求分析者が間に入って「どういう世界を実現したいのか？」と問いかけ、関係者間の矛盾があれば調整し、合意形成を進めていく必要があります。
その上で、必要な機能やパッケージ構成を整理し、「システム要求仕様書」にまとめます。
さらに、その中の開発対象部分を技術的に詳細化した「ソフトウェア要求仕様書」を作成していくわけです。
カードローンの窓口合同会社 編集部：なるほど。こうした体系的な文書整備は、今後のシステム開発には欠かせなくなっていきそうです。
中谷教授：そうですね。現在、私が所属している情報処理学会ソフトウェア工学研究会の「要求工学ワーキンググループ」でも、「ビジネス要求」「ステークホルダー要求」「システム要求」「ソフトウェア要求」の4種の文書を、どのように構成し、どう記述すべきかを研究しています。
カードローンの窓口合同会社 編集部：技術の進展とあわせて、ドキュメントの在り方も変わっていくわけですね。
中谷教授：そうです。現在のソフトウェア要求仕様書は、開発者には読めても、発注者には「これって本当に私たちの話なのか？」と感じられてしまうこともあります。
だからこそ、「自分たちの業務が正しく伝わっている」と実感できるような文書にしていく必要がありますし、それを支援する方法論の整備も重要になっていきます。
カードローンの窓口合同会社 編集部：ありがとうございます。共通理解を促す手段としては、図やモデルといった「可視化手法」が有効だとされていますが、実際にそういった手段は効果的なのでしょうか？
中谷教授：例えば、「朝起きてから寝るまでの行動を説明してください」と言われたとします。
人によっては「起きて、着替えて、朝ご飯を食べて……」と順序立てて話すかもしれません。
しかし、時間がない日は朝食を抜いたり、休日はパジャマのままで過ごしたり、状況は人によっても日によっても変わるはずです。
これを言葉で説明しようとすると複雑で曖昧になりますが、図にして流れを可視化すれば、平日と休日の違いや抜けるステップも含めて、一目で把握できるようになります。
カードローンの窓口合同会社 編集部：たしかに、行動の分岐やパターンを可視化すると、自分でも気づかなかった癖や非効率が見えてきそうです。
中谷教授：実際、私自身も昔は朝30分で家を出ていたのに、今は1時間半かかっている。なぜか分からなかったのですが、モデルにしてみたら「ああ、ここでダラダラしているな」「ここはやらなくてもいいかも」という気づきが得られました。
業務も同じです。ワークフローを図にして、「この作業はなぜここまで時間がかかっているのか」と問い直すことで、ボトルネックが見えてきます。
さらに掘り下げていくと、「この工程はパッケージで置き換えられる」「ここは自動化できるのでは」といった改善のヒントが見つかることも多いです。
カードローンの窓口合同会社 編集部：なるほど。図やモデルがあると、関係者全体で認識を揃える上でも役立ちそうですね。
中谷教授：はい。特に冷蔵庫の制御システムのような組み込み系ソフトウェアでは、状態遷移をモデルで正確に表現しないと、動作保証ができません。
ただ、「Aの部品がこの状態で、Bがこの状態だったら、どんな信号が出るか」といったことを、自然言語で書いていたらわけが分からなくなります。
それを図で表し、モデルとしてコンピュータに読み込ませれば、「2つのプログラムが互いに妨害しあうデッドロックが起きるか？」「無限ループの恐れがあるか？」といったモデル検査も自動で行えるようになるのです。
さらに、要求分析者が「私はこのように理解しています」と図で示すことで、発注者が「それは違う」「その業務は別の担当が行っています」といった具合に、具体的な指摘をすることができるようになるので、正しい修正がしやすくなります。
そうやってやりとりを重ねることで、ようやく「きちんと伝わった」と言える状態に近づいていくのだと思います。
カードローンの窓口合同会社 編集部：たしかに、文章だけでやりとりしていると、気づかないまま話がズレてしまうことがありますよね。
中谷教授：はい。自然言語は、どうしても曖昧さを含んでしまうものです。
しかし、図にするとその曖昧さが見えてきて、「これは違う」とか「ここはこう書き換えよう」といった話がしやすくなるのです。
ですから、共通理解を促す上で、可視化はとても効果的な方法だと思いますね。
カードローンの窓口合同会社 編集部：ありがとうございます。では最後に、これからシステム導入や業務改革に取り組もうとしている企業の担当者や、現場のエンジニアの方々に向けて、意識しておくべき視点やメッセージがあればお願いいたします。
中谷教授：まず、発注者の方にお伝えしたいのは、現在こだわっている業務やルールについて、「なぜそれにこだわっているのか？」という問いを一度立ち止まって考えてみてほしいということです。
本当に変えてはいけないことなのか、それとも実は変えても問題ないことなのか。そうした発想の転換から、業務改革は始まるのではないでしょうか。
これはある本に紹介されていた話ですが、とある動物園の駐車場では、「車のライトを消し忘れる人が多く、バッテリーが上がる」という問題があったそうです。
駐車場の手前にトンネルがあり、そこを通ると自動的にライトが点く仕組みになっていたため、ライトをつけたまま駐車する人が続出していたとのことでした。
カードローンの窓口合同会社 編集部：たしかに、トンネルを出た後だと、ライトがついていることを忘れてしまいそうですね。
中谷教授：はい。そこで「ライトを消してください」といった注意書きを出そうとしたものの、夜間の利用者には危険になってしまうという課題が出てきます。
「昼間だったら消してください。夜間はそのままで結構です」と書く案もありましたが、それでは説明が長く、分かりにくくなってしまう。
最終的に選ばれたのが、「ライトついてますか？」という短い一言だったそうです。
カードローンの窓口合同会社 編集部：シンプルですが、見る側に考えさせる工夫がされていますね。
中谷教授：その通りです。「どう書くか」ではなく、「どう気づかせるか」。
これは設計にも通じる考え方です。変化を受け入れにくいものを強引に変えるのではなく、「どうすれば自然と変われるか」という視点を持つことが大切なのだと思います。
もうひとつ、エレベーターに関する例もあります。
エレベーターの中や前に鏡があるのを見かけることがありますよね。あれは、「待ち時間を感じさせにくくする」ための工夫なのです。
鏡を見てネクタイを直したり、身だしなみを整えたりしている間に、時間が経っている。結果として、エレベーターの待ち時間に対する不満が減るのです。
カードローンの窓口合同会社 編集部：速度そのものを改善するのではなく、待つことへの感じ方を変えているのですね。
中谷教授：はい。つまり、「うちはこうしてきた」「このやり方が伝統だ」といった考えをいったん脇に置いて、その背景にある本当の目的や意図を見直してみることが必要だと思います。
そうすれば、「別のやり方でも本来の意図は守れるかもしれない」という柔軟な発想が生まれてくるのではないでしょうか。
また、エンジニアの皆さんは、「システムは社会や現場を変える力」を持っています。
技術はあくまでも手段です。その手段をどのように活かし、社会や業務をより良い方向に変えていくのか。そこに関心を向け、想像力を働かせてほしいと思います。
取材・記事執筆：カードローンの窓口合同会社 編集部
取材日：2025年6月6日