進め！要件定義の道

概要

最適化問題をアニーリングマシンで解くということを現実の課題に適用する場合、最終的な目的は、最適化処理によってユーザの業務を改善することです。

ユーザが持つ現実の課題の要件定義を経て、定式化、そしてアニーリングマシンの実行と一連の流れの経験のある技術者であっても、要件定義に困難さを感じているようです。最適化処理の要件定義では、業務知識（ユーザが持つ専門知識）と最適化処理の知識（技術者が持つ専門知識）を互いに出し合い、解決へ向けて深く議論する必要があります。そのような場合においては、机上で最適化問題をアニーリングマシンで解くことでは直面し得ない様々な困りごとが起こります。

このコラムでは、厳密な話ではありませんが、最適化処理の要件定義ならではの困りごとを紹介し、実務をより身近に感じて頂ければと思います。

要件定義ってなに？

要件定義とは、システム開発などにおいてもよく使われる言葉です。どんなシステムを作る場合でも、まずはユーザがシステム開発によって何を実現したいかを開発者が把握し、検討項目を詳細化しながら、ユーザの業務に沿った必要な機能や性能、また予算やスケジュールを満たすための方針を固めます。要件定義が終わったらシステムの場合、外部設計と呼ばれる工程に進みます。

最適化処理の要件定義は、システム開発の場合とどのように違うでしょうか。システム開発では、ハードウェアやその制御ソフトなど、あらゆる機能を開発するため工数が膨大になることも多く、最初にできるだけ正確に要件定義することが求められます。

一方、最適化処理を行う際の要件定義は、一度で定義できない条件などもあるため、完璧でなくとも定式化、実行と進み、再び要件定義に戻るというアジャイル開発に近いやり方がうまくはまることが多いと言えます。

ユーザの業務要件を満たしながらアニーリングマシンの性能を最も効率的に引き出すことができる定式化を行うためには、要件定義→定式化→要件定義、また、定式化→実行→定式化というように、何度も最適化フローを回し、完成度を高めて行くことが望ましいのです。

あるある要件定義① 要件は後から出てくる

COVID-19の流行により、日立の研究所でシフト勤務最適化を行った時はどのようなことがあったか、例として挙げてみましょう。出社人数を制限する必要がある一方で、実験のため出社が必要な人も多く、誰をいつ出社させるかを決める必要がありました。

当初は、部屋の人数上限を決めて、そこに各研究者の希望（この日は絶対実験したい、または、絶対というほどではないができれば実験したい、等）を入力し、アニーリングマシンを実行してシフトを決定する、という運用を始めました。

しかし実際に運用を始めてみると、一緒に働かせる人の制約（例えば、新人と指導員とか）、逆に一緒に働かせたくない人の制約（例えば、マネージャ2人が同時にコロナに罹ると困るので、同時に働かせない）といった希望が出てきました。また、勤務日は指定しなくてもいいが、週のうち少なくとも3日は勤務したい、といった希望も出てきました。

このように、研究者の希望をもとに新たな制約を取り込みながら、シフト最適化アプリがバージョンアップしていきました。

また、このようなイジングモデル化に関することだけヒアリングするのではなく、業務として運用するための調整も求められます。今回のケースでは1週間分のシフトを最適化により作成することになりましたが、前週の木曜日までにシフトがほしい、という人もいれば、一方で希望の提出を木曜日まで待ってほしい、と言う人も現れました。実際には、木曜の夕方に希望の入力を締め切り、翌日金曜朝にはシフトを公開しました。

このように、要件定義の段階では、最適化のための定式化だけではなく、業務で運用する上で必要な条件を考慮することが必要です。そうしてこそ実際に適用した時にユーザが「改善できた」と感じることができるのです。結果として、最適化処理の迅速さがあるからこそ研究所のシフト勤務が成立し、効果があるということを実証することができました。

あるある要件定義② 最適化したい指標がわからない

イジングモデルのコスト関数を作るため、ユーザに「何を最適化したいか」をヒアリングしても、ユーザが即答しづらいケースもあります。たとえば、時間割の最適化をしたいユーザがいたとして、技術者が時間割というものを知らなかったとしたら、ユーザにこのように尋ねるかもしれません。

「制約はたくさん挙げてもらったのですが、最適化したい指標が何かをまだ聞いていません。あなたは何を最適化したいのですか？」

こう尋ねられてユーザはしばらく悩んだ後、「時間割を作りたいだけなのですが…。一体何が知りたいのですか？」と言いたくなるのではないでしょうか。

どういうことかというと、この技術者はイジングモデルのコスト関数を作りたいがために、最小化あるいは最大化したい指標を知りたがっているのですが、時間割問題というのは、制約ばかりの問題であることが多く、このユーザが作りたい時間割も〇〇を最大化したい、〇〇を最小化したいというような性質の問題ではなかったということになります。

さすがに時間割を知らない技術者はあまりいないので極端な例ですが、技術者が初めて見るような組合せ最適化問題をユーザから与えられることも考えられるため、ヒアリングの際は思い込みを捨てて挑むことが大事だと言えます。また、どのような最適化問題があるかという事例を蓄積し、世の中で共有していくことが重要ということがわかります。

あるある要件定義③ どうやら線形です

今、アニーリングマシンの最適化技術の存在が世に知られるようになってきて、これまで人の手で組合せを考えていたような業務に、アニーリングマシンを適用しようとユーザが試みる機会が増えてきています。しかしアニーリングマシンで解くことをめざして要件定義を進めた結果、線形の問題であることが分かってくるケースもあります（詳細は、アニーリングマシンのための数学の項を参照）。

定式化したところ2次の項が出てこないのであれば線形問題であり、2次の項が出てきたのであればアニーリングマシンが得意、となることが基本ですが、解いてみて効果の度合いを比較してみないとなんともいえないということもあります。実行までしてみたけれど最適化手法を選定する段階に戻って始めから検討することも視野にいれて、最適化フローを回すことがプロジェクトを前進させます。

膨大なコミュニケーションを通じて多くの手がかりを得た成果である要件に対し、最適な手法を適切に適用することがユーザの価値に繋がるのです。色々な問題を経験することで、アニーリングマシンを効果的に使える問題がわかり、ユーザ価値だけではなく、世の中に貢献する新しい成果となる事例の創出に繋がることでしょう。

まとめ

最適化処理の要件定義においては、最初から完璧にすることが重要ではなく最適化フローを回すことによりアップデートされ、要件の完成度を高めていくことができる。
最初の要件定義の段階ですべての要件を出し切ることは難しく、新たな要件が後から見つかり、追加されることもある。それは定式化や制約にかかわることばかりではなく、業務運用上の要件も含まれ、ユーザ価値の創出のために考慮すべき情報となる。
ユーザがかかえる課題をヒアリングする際は、思い込みを捨てて挑む。
何度でもスタート地点に立ち戻り最適化フローを回すことが、ユーザの価値創出に繋がる。