人とAI、共創の時代へ―― 要求を『見える化』せよ！ワークフロー可視化が繋ぐ発注者と開発者ソフトウェア工学の新潮流

ソフトウェア開発の世界は、日々目まぐるしく変化している。

技術の進歩と共に複雑化する要求、多様化するニーズ―― その中で、開発者たちは常に新たな課題に直面しているのだ。

放送大学の中谷多哉子教授は、この混沌とした状況に一石を投じる。要求工学の第一人者として、ソフトウェア開発の本質に迫る。

開発現場と発注側のギャップ、刻々と変化する要求への対応。これらの課題に、どう立ち向かうべきか？

時代が求める技術とスキルとは何か？ そして、ソフトウェア開発の未来はどこへ向かうのか？

中谷教授のインタビューを通じて、私たちは新たな視点を得ることができるだろう。ソフトウェア開発の世界に、新たな風が吹き始めている。

『何のため』を形にする―― 要求工学が拓くソフトウェアの未来

―――まずは、研究領域と研究テーマについて教えてください

私は現在、ソフトウェア工学の研究を行っています。

ソフトウェア工学とは、ソフトウェアの開発プロセス全体を対象とする学問分野です。まず初めに、要求を分析し、ソフトウェアに求められる機能や制約条件を洗い出します。

次に設計を行い、その設計に基づいてプログラミングによる実装を行うのです。実装の後はテストを経て、ソフトウェアをリリースし、お客様に提供します。

しかし、リリース後にも変更が必要になる場合があり、そのような場合には保守作業を行います。

ソフトウェアの保守は、機械の部品交換のような保守と同一ではありません。プログラムそのものは経年劣化しないからです。しかし、陳腐化への対処を保守で行います。また、時代の変化に合わせて機能を更新する必要が出てくることがあります。また、プログラムにバグが含まれていれば、それを修正する作業も保守に含まれるのです。

このように、ソフトウェア工学による技術は要求分析から運用・保守に至るまで、ソフトウェア開発の全工程が対象です。良質なソフトウェアを生み出すための手法や、品質を評価する指標の研究などが行われています。


私の専門は、ソフトウェア工学の中でも特に「要求工学」と呼ばれる分野です。要求工学は、開発の最初の工程である要求分析を中心に据えた研究領域になります。

近年では、要求分析に先立つビジネス分析なども含まれるようになってきました。具体的には、なぜそのソフトウェアが必要なのか、その目的を達成するためには何が求められるのか、どのような機能やユーザー向けの配慮が必要なのか、どのようなハードウェア環境で動作させるのか、アクセス数の見込みはどうかといった要求を分析します。

これらの分析を通じて、そのソフトウェアが満たすべき機能と品質要求が明確になるのです。実際の開発の中では、相反する要求が現れることがあります。

例えば、データ管理者からは「個人情報が含まれているのでセキュリティを強化してほしい」と言われる一方で、営業担当者からは「使いづらければお客様が離れてしまう」と言われてしまうのです。使いやすさとセキュリティの強化は典型的な相反する要求であり、パスワード入力を求めすぎればユーザビリティが損なわれてしまいます。しかし一方で、ユーザー認証がまったくないとセキュリティ上の問題が生じます。

そのため、相反する要求については、それぞれの要求をどの程度優先するのかを決める必要があるのです。この作業は要求分析の工程で行われます。その他、一連の作業のプロセスが要求工学で定義されています。設計技術者は要求仕様書に基づいて設計を行いますが、その設計が要求を満たしているかどうかを検証することができるのです。

同様に、プログラマーは設計仕様書通りにプログラムが作れているかをテストできます。しかし、要求工学の工程では、要求者が人間であるため、要求仕様書自体が妥当かどうかを検証することはできません。要求者に確認を取るしかありません。ここが難しいところです。

このような現在の状況で、さらに世の中の変化に対応できるようなソフトウェアを作ることはできるのでしょう。

『変更しやすさ』という生存戦略 – 激動の時代を生き抜くソフトウェア

―――昨今のソフトウェア開発における現状やトレンドについて教えてください。

現在、私たちは、変化し続ける社会の中でソフトウェアを作り、進化・変更させていかなければならない渦中にいます。数十年前のソフトウェア開発は、要求分析から運用・保守までを一通り行えば十分でした。しかし今日では、そうした従来の方式では満足できるソフトウェアは作れないでしょう。

ChatGPTのような新しい技術の普及スピードを見れば、その傾向は一層顕著です。研究者としても、そうした最新の動向を無視して研究を続けるわけにはいきません。

つまり、実際のソフトウェア開発においても、AIなどの最新技術をいかに取り入れていくかを検討し続ける時代になったということです。要求分析とテストを繰り返しながら、適切なタイミングで新技術を取り入れられるソフトウェア開発が求められています。

具体例を挙げると、最近の宅配便では署名や捺印が不要になりました。もともと法的に必須ではなかったそうですが、宅配業者は受け取り証拠を得るためサインを求めていたと思われます。

しかし、今は、配達員が荷物のバーコードと自身のバーコードを読み取ることで、データとしてコンピューターに配達完了を記録できるようになりました。ハンコや署名の意味がデジタル化されたのです。コロナ禍での対面回避の需要も、こうした変化を後押ししました。

つまり、リアルな現実世界の出来事をデジタル化してコンピューターに登録することで、どこまで業務をスムーズに行えるようにするか、がソフトウェアに求められる課題になったのです。

かつては紙があることでデジタル化が進まず、旧態依然とした作業が残っていてコストがかさみ、ミスも発生していました。そこで、DX(デジタルトランスフォーメーション)の必要性が叫ばれるようになりました。

DXは、これまでの習慣に疑問を投げかけ、旧来の作業を見直すことから始まります。例えば、要求者は、開発側からメリットやコストダウンなどの提案を受け、相互に要求を詰めて意思決定する必要があると思います。DXはデータのデジタル化が重要なのではありません。DXは、デジタル化の利点を活かし、それによって旧来の作業に費やしていた時間と労力を新しいビジネスやサービスの改善に注ぐための方策です。

また近年では、ソフトウェア開発の形態も多様化が進んでいます。従来は、SIer(システムインテグレーター)と呼ばれる大手のソフトウェア開発企業が、お客様からの要求を受けて、関連会社の技術者を集めてシステムを開発する形態が一般的でした。これは、伝統的な大規模開発の進め方です。

一方で、お客様と密接な関係を構築する小規模のソフトウェア会社も存在します。お客様ごとに専任の技術者が張り付き、相談に乗りながら様々な要望に対応するスタイルです。技術者が、システム構築、ネット接続設定、セキュリティへの対処、WebサイトやWebシステムの開発など、あらゆるサービスを提供します。

このように、ソフトウェア開発の形態が多様化する中で、要求者が自身のニーズに合わせた最適なアプローチを選べるようになってきました。

―――「ソフトウェア開発」と言っても何を作るのかによって、課題が変わってくると思います。最も深刻化している課題は何でしょうか？


先ほどSIerについての話がありましたが、SIerは大手のソフトウェア開発会社で、多くの関連会社と技術者を抱えています。この場合、要求者は、SIerとの対話を通じて、どのような作業をコンピューターに移行するか、あるいはコンピューターでどのような新しいサービスを実現するかを決めていきます。

しかし、開発側と要求者側の距離をもう少し近づける必要があるのではないかと感じています。

また、時代の流れに合わせてソフトウェアを変化させるためには、ソフトウェアを変更しやすいように設計することが重要なのです。これは、ソフトウェア工学でもよく議論される「可変性」と呼ばれる品質の問題です。ソフトウェアが可変か否かは、往々にして開発後に変更を加えてみて明らかになります。

開発時点で可変性の度合いを判断するのは困難だと言われてきましたが、現在は技術の進歩により、状況が変わりつつあります。例えば、データの提示方法は、グラフ、音声、動画など様々な形式があり多様化しています。多様性のある要求や変わりやすい要求は、要求者の発言の中に「〜とか」や「等」、「今のところは．．」、「．．でもよいです」というキーワードを伴って現れます。このような発言によって要求の変わりやすさが予測できたときは、それに対処するための設計技術を開発者は適用します。

一方で、変更に柔軟に対応できる設計が難しかったり､将来の要求変更を全く予測できなかったりする場合、開発の方法自体を変えるアプローチもあります。即ち、決まった部分から着手し、新鮮な要求に基づいて開発を進める方法です。

従来の要求分析、設計、実装という流れでは時間がかかりすぎて、完成時には要求自体が陳腐化する恐れがあります。そこで登場したのが、最新の要求に迅速に対応する「アジャイル開発」です。

アジャイル開発は、小規模な開発を繰り返しながら徐々にシステムを成長させていく手法で、変化の激しい環境下でも有効に機能します。例えば、非常に流動的で決定しづらい要素は後回しにしたり、変更の可能性が高いと分かっている部分は柔軟に変更できるよう設計したりと、状況に応じて設計の意思決定ができるのです。

もう一つの問題として、要求者自身のこだわりがあります。「わが社は特別だ」という意識から、汎用的なシステムを拒み、独自仕様のシステム開発を求めるケースです。

このようなこだわりはDX（デジタルトランスフォーメーション）を進める上での障壁となっており、多大なコストを生んでいます。ゼロから独自開発すると、法改正などの社会全体の変化にも自前で対応せざるを得ず、ソフトウェアの保守の負担が大きくなります。

一方、共通のシステムを利用していれば、一箇所の変更で全利用者が恩恵を受けられるだけでなく､開発経費は折半になりますから、どちらが得策かは明白でしょう。 最近では会計システムなど、企業のコアビジネスではない領域のシステムについて、こだわりを捨て、汎用化・共通化を進めてコストダウンを図ることが多くなっていると思います。

例えば、ある大学では「本学は他大学とは異なる」という考えのもと、独自の教務システムの開発に数億円もの費用をかけました。一方、別の大学では既存のパッケージソフトウェア、つまり汎用的に利用可能な教務システムを全面的に採用することにしました。そして、大学の業務プロセスをそのパッケージに合わせて変更しました。

結果として、教務システムの導入には数千万円程度の投資で済んだそうです。この事例は、独自へのこだわりがいかに多大なコストを要するか、場合によっては高品質の既存サービスを利用する方が賢明だということを如実に示しています。

日本全体のIT化を一気に推し進める原動力となり得るのは、むしろこうしたシステムの共通化のアプローチではないでしょうか。

要求を『見える化』せよ！ワークフロー可視化が繋ぐ発注者と開発者

―――開発を依頼するクライアントと開発者にある課題があれば、教えてください。

現在の日本のソフトウェアビジネスの主流なビジネスモデルは次のようなものです。まず、エンジニア（開発者）がクライアント（要求者、発注者）から要求仕様書を受け取ります。この仕様書は開発者側のエンジニアが作成することも少なくありません。

その後、受注者側と発注者側で合意を取り、契約し、開発を進めていきます。開発が完了し、開発者が要求者に成果物を提示すると、往々にして「これも必要だった」「あれも必要だった」という新たな要求が出てくるものです。要求者にとっては､ソフトウェアが具体的な形になって初めて見えてくる部分があるためです。

そうすると、開発会社は「それは要求の変更なので、追加の費用が必要です」と主張します。一方、要求者は「いや、それは仕様の誤りではないか」などと反論し、時には訴訟に発展することもあります。

このソフトウェア開発というビジネスのモデルの問題点は、ソフトウェアの開発会社にとって、要求の変更を全て追加の収益と捉えることができる点にあります。 つまり、最初に作成した要求仕様書に顧客がOKを出せば、それに忠実に作ればよいという考えになります。

たとえその仕様に誤りがあったとしても、修正は追加の仕事になるため、要求仕様書の品質を高める努力をしなくなってしまうのです。要求仕様書の品質を向上させることは、開発後の収益を減らすことになりますから。しかし、発注者と受注者の力関係が逆転し、発注者側が強い立場にあると状況は一変します。「君たちは大学の業務システムに詳しいと言っていたはずだ。なぜこんな仕様になるんだ」といった叱責を開発者が受けることになるかもしれません。

すると今度は、ソフトウェア会社が無償でシステムの改修を余儀なくされます。発注側もソフトウェアのリリース時期が遅れるために、時間を浪費することになります。これでは誰も幸せにはなりません。この問題を解消するには、関係者全員が、要求分析工程の重要性に対する意識を高める必要があります。

より綿密に要求者と擦り合わせをする必要があると言うと、開発者は「そんな時間はない」と反発するかもしれません。しかし、後で失敗して開発のやり直しをするよりは、要求分析に時間をかけ、相互理解を深めて、円滑に開発を進める方が賢明です。急がば回れです。

つまり、「（開発者）必要なのはこういうものでしょうか」「（要求者）これを使うと、どう仕事がよくなるの？」「（開発者）こういう点がよくなります。このような変化の影響は、どこまで及びそうですか」．．．「（要求者）なるほど．これなら皆喜ぶだろう」といった相互理解を進めながら、開発を進めていくのです。アジャイル開発では、常に要求者（発注者）がそばにいることを推奨しています。そうすれば、要求者にも開発の苦労が分かりますし、「ここで要求を決めないと開発できない」という切迫感も共有できるようになり、協力の度合いも高まるはずです。

また、「前はこれが欲しいと言ったけれど、今思いついたこちらの要求の方が重要だということがわかりました―― そのため対応してもらえますか？」といった意見に対しても、要求の優先順位付けを再度行うなど、コストや納期を守りながら、柔軟な対応が可能になります。開発者が要求者の環境や業務を理解していないと、使い勝手の悪いソフトウェアができあがることもあります。

DXを進めるときも、同様です。その場合は、「良質な設計」とは、企業で働く人々や顧客を含めた企業システムをより良くする設計も含まれています。良いソフトウェアを作るには、要求者と開発者が相互に理解し、協力して新しい世界を作っていく必要があると考えています。そのため、要求工学が重要だというのが私の意見です。良質な要求を収集できれば、良質な設計も可能になるでしょう。

大切なことは利用者のシナリオを考えること

―――依頼側が、どのような機能を持ったシステムを作成するのかイメージできないまま、発注するケースもあると思います。このような問題を解消するために、発注者側が知っておくべきことは何かありますか？

相互理解を深めるためには、双方が共通して理解できるものが必要不可欠です。自然言語だけでは、文章を読み込まないと理解できず、一目で意見や解釈の相違点を把握することは困難です。

そこで私が主張したいのは、要求を可視化する必要性です。依頼側の要求は往々にして抽象度が高く、「便利なシステムが欲しい」といった曖昧なイメージで発注されることがあります。これでは受注側が困惑するのは明らかです。

そのため、そのイメージの具体的な内容を記述し、提供するメディアが必要だと考えています。我々はこのメディアを「モデル」と呼んでおり、実際には図や絵を描くといったようなことです。例えば、顧客企業の業務フローを可視化します。「まずこの作業をして、次にこれをして」「顧客からこんな連絡が来たら、こういう順序で対応する」といった仕事の流れ、つまりワークフローを図示するのです。

そうすると、開発者側は現状を把握した上で、「どの部分で苦労されていますか？」と具体的に質問できるようになります。そして、「ここと、ここと、ここは間違いが多くて大変なんです」という回答を得たら、「それなら電子化すれば、すべてチェックできますよ」といった提案ができます。

「ではどう変わりますか？」と問われれば、図を描きながら「こんな風に変わります」と説明できるでしょう。このようなやり取りができれば、システムを使っているイメージが明確になり、かつ、発注者と受注者の双方がそのイメージを共有できるようになりますから、より良いシステムの構築につながるはずです。

ソフトウェア工学では、こうした図の描き方の集合を UML（Unified Modeling Language）と呼んでいるのです。例えば、ワークフローは黒丸から始まり二重丸で終わる図で、その間を四角い枠と矢印で結ぶといったルールがあるとします。私は、この UML の中でも特に「アクティビティ図」と「状態図」の2つを発注者側には、是非、理解してほしいと考えています。

なぜなら、これらを使えば開発者とのコミュニケーションがスムーズになるからです。この2つの図を描くことで、発注者が理解している現実世界の状況を表現でき、それが開発に大きく寄与すると思います。さらにもう一つ、最近注目を集めている「ユーザーエクスペリエンス（UX）」の分析にも、こうしたモデル化は有効です。

UX分析では、利用者のシナリオを記述し、各場面での感情を分析して問題点を見つけ、改善するというアプローチを取ります。例えば、「お客さんが店に入り、コーヒーを注文し、別のカウンターで待つよう指示され、番号か商品名で呼ばれ、受け取ったら席を探す」といったシナリオです。

事前に業務のワークフローを図示した上で、「具体的にどういう時に困っているか」というシナリオを書いてみます。そして、現状で最も困っている箇所と、ソフトウェア導入後の状態を比較して描く。これにより、どこが問題かを可視化でき、課題を開発者に明確に伝えられるのです。「なんとかかんとかで困っている」といった曖昧な表現よりも、はるかに正確でインパクトのある伝え方ができるでしょう。

―――AIが進化する昨今、エンジニアやソフトウェア開発者に求められることは何でしょうか？



一般の方々は、「AIを使えばいいじゃないか」と安易に考えているのではないかもしれません。一方、様々な場面で耳にする話を聞いていると、「AIにそんなことができるわけがない」といった意見も多く、テレビのコマーシャルやニュース番組を見ていてもそう感じることがあります。しかし、実際のところ、ソフトウェア開発者自身が、例えばChatGPTのようなAIツールをどこまで活用できるのか、現在まだ模索している段階なのです。

確かに、AI技術は日進月歩です。しかし、開発の現場では依然として試行錯誤の連続です。データを学習させようとしても、思うように学習が進まないこともあります。

その際、開発者はデータ内のゴミやノイズを取り除く「データクレンジング」や、何が悪影響を及ぼしているのかを突き止める地道な調査を行う必要があります。 また、モデルが訓練データに過剰に適応してしまう「過学習」の問題も常に念頭に置かなければなりません。

こうした作業は、実際にやってみると予想以上に時間がかかるものです。そのため、これらの工程の見積もりが適切にできなければ、ビジネスとして成立しません。

学習の精度をどこまで高められるか、そのためにどれだけの時間とリソースが必要かといった点も、プロジェクトの成否を分ける重要な要素となります。大規模言語モデルの仕組みを見ると、同じサービスや同じ品質のサービスを常に提供できるとは限らないことがわかります。

つまり、工学的にソフトウェアを開発する際に、AIをどの程度まで利用できるのかを慎重に検討する必要があるのです。ここが現在の主要な課題だと言えるでしょう。 工学的な分析においても、AIの能力の限界がまだ明確でない中、現状は発展途上の段階と言えます。

それにもかかわらず、AI技術は急速に進歩しているため、その進歩に追いつくのが困難な状況です。この発展途上の段階で、いかに工学的に検討を進めていくかが、AI自体のエンジニアリングや、ソフトウェア開発に求められる重要な要素の一つになっていくでしょう。

ChatGPTを使って自動的に要求仕様書を作成させるといった試みも行われています。あるいは、与えられた要求文やシナリオから、AIが要求事項を抽出する試みもあります。このように、AIの活用については様々な角度から研究が進められています。

AI技術の急速な発展と、それを適切に制御・活用するための工学的アプローチとの間にはまだ大きなギャップがあることも事実です。今後は、このギャップを埋めていくための取り組みがより一層重要になってくるでしょう。そして、その際には、AIの開発や運用に伴う現実的な課題—データの前処理、モデルの調整、精度の向上など—をいかに効率的に解決できるかが鍵を握ることになると思います。

AIができること、できないことー人間にしかできない真価を探す旅へ

―――最後に、読者の皆様にメッセージをお願いします！

ソフトウェア開発は、開発者だけの努力で成し遂げられるものではありません。優れたソフトウェアを作るためには、関係者が同様に尽力する必要があることを、すべての人々に自覚してもらいたいと考えています。

開発者は、お客様から仕様書を受け取った時点で、「これで十分だ」と安易に考えてはいけません。その仕様書を叩き台として、そこから本格的な要求抽出が始まるのです。

開発というのは、要求分析も含めた包括的なプロセスであり、その視点で取り組むべきだと私は考えています。データサイエンスのリテラシー教育に関しては、近年、環境が大幅に整備されてきました。

しかし、ITリテラシー教育については、まだまだ改善の余地があると感じています。世間には、ITリテラシーとはプログラミングを教えることだと誤解している人が多く、次に多いのは「論理的思考力を育てる教育だ」と主張する人です。

私は、別の案を持っています。ITリテラシーとは、社会においてデジタル技術をいかに活用するかという視点で社会システムを見ることでもあります。

デジタル技術は「あるから使わなければならない」のではありません。我々の社会をより便利に効率的に、過ごしやすくするために使いたいものです。例えば、高速道路のETCについて考えてみましょう。

私自身、導入当初はかなり抵抗がありました。自分の車に機器を取り付けてまでして、ETCを利用する意義はあるのでしょうか。あるとき友人に「ETCは便利だ。雨の日に車の窓をあけなくてよいからね。」と言われ、即、ETCの機器を車に取り付けました。ITシステムを人々に笑顔で使ってもらうには、それを使う人に、どのようなメリットがあるのかを分かりやすく伝えなければならないと思います。

デジタル活用の真の意義は、デジタルシステムを利用することで、関係するすべての人々が従来抱えていた苦労から解放される社会を作ることにあります。そのような視点で社会を見られるような知識こそが、本当のITリテラシーだと思うのです。そして、それは小学生の頃から身につけてほしいスキルです。

簡単なことではないかもしれませんが、例えば、「なぜこれをしなければいけないのか」と疑問を持つ。宅配便の荷物を受け取る際に、「なぜサインしなくてよいのか」、段ボールに貼られた紙の二次元バーコードの役割は何かと考える。そして、それらが存在することでどのようなメリットを享受できるのかを意識する。

そういった疑問や気づきこそが、リテラシーの第一歩だと考えています。このような視点を持てば、AIによって人間が制御されたり管理されたりするのではないかという不安は自然と払拭されるでしょう。そもそも、そのような心配は杞憂です。

AIに管理できることはAIに任せればよく、それは人間がする必要のないことなのです。AIによるメリットを人間が手に入れるということは、今度は逆に、「AIにはできない、人間にしかできないことは何か」と考えられるようになると思います。