制約プログラミング：方法論と事例

1. 制約プログラミング：方法論と事例 NTTデータセキスイシステムズ システム開発統括部第一開発グループ 山崎　雅史 http://www.constraint.org

2. 本発表の構成と内容 • 目次 • 背景 • 開発方法論からみた制約プログラミング • 開発事例の紹介 • 開発プロセスからみた事例の評価 • まとめと今後の課題 • 参照文献 内容 • 制約プログラミングを、実用的なソフトウェア開発プロジェクトでの利用という実務家の立場で扱う。 • プロジェクトで制約プログラミングを使う場合のメリット・注意点を開発方法論の観点から整理。 • 実際の開発事例について、開発プロセスを中心に紹介。 • 制約プログラミングが実用上非常に有効な技術であることを検証。 • 問題解決技法としての側面も、開発プロセスに影響を及ぼす範囲で言及。

3. 1.背景

4. 解法か開発手法か • 制約プログラミングは、「難しい問題」を解くための技術と考えられている。 • 問題解決手法とした見た場合、適用可能な問題領域が共通する手法が競合手法として考えられる。 • 競合技術の例 • LP(線形計画法), MIP(混合整数計画法),タブーサーチなどのメタヒューリスティクス, NN(ニューラルネットワーク), GA(遺伝的プログラミング)などの進化論的手法 • 制約プログラミングの定義には揺れがある。 • 狭義では制約伝播手法をベースとした技術に限定される。典型的なのは演算領域をFD(有限領域)に限定した手法。cf.[BARTAK98] • 制約プログラミングをパラダイムとして捉える視点もある。この場合には、宣言的な制約を用いた問題のモデル化の側面が重視され、様々な解法が包摂される。cf. [山崎01]。また、パラダイムとしての制約充足問題については、例えば[西原97]参照。 • 実務上は定義の問題には拘泥しないが、「パラダイムとしての制約プログラミング」が実用上有効かどうかを検証することは必要。 • 解法として優れていることは、実用的な開発手法であることとは別。 • 制約プログラミングは「実用的な」技術なのか？ • イノベーションを強調することだけでなく、生産性の高い、安心して使える技術であることの確認も必要。

5. 実務家の視点から • 実用性は、以下の視点から考えなくてはならない。 • 開発者にとっての効率：「使いやすさ」「生産性の高さ」 • ユーザーにとっての効率：「費用対効果」 • 実務家にとっては、実際の開発プロジェクトの中でうまく利用でき、結果が出せることが重要。 • ますます強まる開発サイクルの短期化に対応できるか？ • モデル化や実用性の検証にじっくりと時間をかけていられない。 • 投資した時間(工数)対得られる成果の観点も重要。 • 「難しい問題」に取り組むこともあり、見積り精度への影響も考慮すべき。 • 単なる解法としての性能の優劣だけを論じるのは不十分 • ここでは開発方法論上、制約プログラミングを使うことの持つ意味合いを確認したい。

6. 開発方法論からの検討の先行事例 • 解法としての視点が先行し、開発方法論的な検討は必ずしも多くない。 • 制約プログラミングの開発方法論的な検討の先行例： • [CHIC95] DassaultとBullによる　“CHIC Lessons on CLP Methodology” • [FRON94] Fron “Programmation par contraintes” の一部（第9章） • 自社の成果報告の中での評価報告： • [森95]「制約ベース的アプローチによる勤務計画・工程計画立案システムの設計」 • 開発方法論から制約プログラミングに言及している例(国内)： • [青木93] 「オブジェクト指向システム分析設計入門」

7. 2.開発方法論からみた制約プログラミング

8. 制約プログラミングを使ったソフトウェア開発制約プログラミングを使ったソフトウェア開発 • プロトタイプ手法との相性は良い。 • プロトタイピングのツールとしては強力。 • ユーザーに対する説明がしやすいモデルが作れる。 • 「説明原理」としての制約プログラミング cf.[橋田94] • スパイラル開発との相性が良い。 • プロトタイプ段階での実データを用いたフィージビリティの検証、実システム開発での実データを用いた性能向上が成功の鍵。 • 性能改善や状況の変化に対応した条件変更に対して柔軟で頑健。 • 初期開発だけでなく、保守・改良まで考えた場合に、長期間にわたり使い続けられるシステムを提供できる。

9. [参考]FP(ファンクションポイント)の観点から • FP法[児玉99]からみた場合の特性は、解法自体ではなく、問題領域の固有性に由来する部分が大きい。 • 他の解法でも対象問題が同じなら、ほぼ同じ傾向になる。 • FP法の精度を上げるためには、モデリングが重要 • 制約プログラミングは有利。 • 入出力(特に入力)のインタフェースは複雑 • 様々な情報を集約し、多様な条件を考慮した計画作成を行うことから。 • システム特性の「処理の複雑性」「変更の容易性」→重み大。 • 「性能条件」「エンドユーザーの効率性」→目標設定が重要。 • システムの規模にインパクトを与える因子となる。 • 制約に関連したメトリクスを追加することを検討すべき。 • 制約の数・密度・探索空間や解空間の大きさ・密度など。 • 主として「処理の複雑性」に関連し、より厳密な評価が可能になる。 • 現状では定性的な考察のみ、今後定量的な検証が必要。

10. 開発プロジェクトで制約プログラミングを用いる際の留意点開発プロジェクトで制約プログラミングを用いる際の留意点 • プロジェクトの中での量的な割合 • 全体のプロジェクト規模は様々だが、制約プログラミングを用いた問題解決プログラムは、システム全体の一部に過ぎない。 • 制約プログラミングを用いた設計・実装を行うのは少人数。 • 経験上、スタンドアロンシステムであっても開発工数の過半は各種インタフェースの開発にあてられる。 • 他のシステムとのインタフェースや、ユーザーインタフェースの設計・実装の重要性が、通常のシステムよりも低いということはない。 • フィージビリティはプロトタイプ時点で解決すべき問題で、実システム開発は通常と同じ。 • 手法の習得・技術移転の問題 • 習得の困難さが言われるが、程度問題。 • 習熟には時間が必要なのは他の解法も同じ。 • 他の技法に比べて、直感的なわかりやすさがあるため、ハードルは低い。 • 実装プログラミング言語の壁はない。 • 当初論理プログラミングベース(Prologなど)だったが、現在の商用の開発ツールの主流はC++, JAVAなどのクラスライブラリ。 • 技術移転の問題はある。特に完成した実用システムを維持・改善するには結局、解法と問題領域の両方についてのノウハウが必要。 • 専門技術を持ったチームが初期から導入後の維持管理まで担当するのが望ましい。顧客の体制では維持できなければ、アウトソーシングになる。

11. ユーザーとの対話性 • (1)分析・設計の段階 • 条件が複雑で、解の評価も簡単でない「難しい問題」を解くため、ユーザーとの対話性は実用上重要。 • 制約プログラミングは宣言性の高さと表現が直観的であることが特徴で、説明能力が高い。 • 問題領域のエキスパートとの対話がスムーズに進むため、プロジェクトの初期段階での意思疎通不足による設計不良がおきにくい。 • 人工知能の産業応用で問題になった知識獲得の問題は解消されたわけではなく依然として存在するが、表現力の豊かさは、分析、モデリングのレベルでは大きな武器になる。 • (2)実装の段階 • 実装上の対話性の確保は別の問題。 • 解が見つからない場合への対応。 • ユーザーが適切なアクションを取れるような情報の提供。 • 「何故このような解になったのか」のユーザへの説明。 • 開発者にとっては、デバッグの困難さの問題でもある。 • 制約プログラミングのみの問題ではなく、複雑な問題解決を行う手法共通の問題。 • 問題解決能力を全面に押し出すと、ユーザー(特に現場)が反発。業務支援システムという立場の強調が必要。 • ユーザーとの対話性を重んじたシステムが好ましいが、ユーザーの介入の仕方については設計上工夫が必要。 • 利用者の知識や習熟度を想定しない設計は事実上困難。

12. システムの品質 • 短期間の開発で高品質の結果が得られることは実証済み。 • 特にカスタムメイドの受託システムでは、全自動・半自動で、人間の専門家と同等かそれ以上の品質を出せた事例が多数ある。 • 制約プログラミングは工期（予算）と達成品質の目標のトレードオフに対して柔軟に対応できる。 • どちらかといえば、短期間で初期開発をして、現場の声を聞きながらシステムを改善するやり方に適している。 • 最初から厳密に最適化の方向が定義できるなら、品質上他の手法の方がすぐれている可能性はあるが、現実には困難が大きい。 • 制約プログラミングは「実用的な」開発手法といえる。 • 実データによる検証・チューニングは実装方式の検証・品質の向上のために不可欠。 • 可能な限りプロトタイピングの段階で実データを用いた検証を実施すべき。 • 検証環境の整備には、ユーザーの協力が不可欠。 • ユーザーに安心感を与える側面も大きい。

13. 他の手法との関係 • オブジェクト指向との相性は良い。 • 自社事例：工程スケジューラ開発のフレームワークとしての制約つきオブジェクトクラスライブラリ(半導体ラインの工程計画など) • UMLでの制約の扱い。OCL(Object Constraint Language)の提供。[UML02]参照。 • パラダイムとしての制約プログラミングは、様々な解法を統合するフレームワークとなる。 • cf.[HECS]分散協調制約解消システムHECS(番原、田村、井上、川村、玉置) • 線形計画法などのORの手法は代替として常に検討すべき。 • 制約伝播ベースの制約プログラミングでは、解を探索する必要があり、ヒューリスティクスの導入は必須。cf.[BARTAK98] • 自社事例：Tabuサーチ的な探索制御(生産計画など) • 自社事例：local searchを使った解の改良（配送計画など） • 参考：標準化推進の現場から • PSLXコンソーシアム(http://www.pslx.org)での生産計画システムインタフェース標準化での議論。cf.仕様書パート3[PSLX3-06] • 「制約」は追加可能だが、標準としては定義されない。 • 要するに、現場では不可欠だが、多様性が大きすぎて標準にはできない。 • 実用になるシステムを開発するためには、このギャップを埋める方法論(モデリングの手法・解法)が必要。 • 実用的な観点から、制約プログラミングは評価されている。

14. 3.事例（１） 屋根パネル積載計画システム[山崎98][山崎01]

15. 2階 1階 6 トラック２ トラック１ 5 4 10 3 9 2 8 1 7 問題・システム化の目的と条件 • 屋根パネルをトラックに積載する計画。 • どのように複数のトラックに分載するか。 • どのような順序で積載するか。 • 目的：屋根パネル積載計画を自動的に作成することにより、省力化を図る。 • 人手での作業では、 • 熟練が必要。 • 時間がかかる（最大10～15分／邸）。平均5分として150邸／週の計画を週一度作成するので、1人日では作成できない。確認作業も含めると2~3日必要。 • ミスが発生する可能性がある。 • 条件： • 基本的に全自動。バッチ処理。 • 人間は結果の確認のみ。 • ＰＣ上で、一回の立案で最大150邸前後の処理ができること。確認も含めて1日で完了。 • 商品のタイプの増加を考慮する。 • 順序決定の条件の変化に対応しやすい枠組みが必要。

16. 階混載しない＝トラック3台 階混載する＝トラック2台 例）8段積み ② ① 2階：10枚 棟違い下優先 1階：6枚 軒先の突起は交互に 計画作成の目標 • 輸送時のパネルの破損を防止し、かつ施工現場の作業が行いやすい順序に積載する。 • 制約条件の例 • 軒先の突起は交互に積む。 • 棟違い下側のパネルを上に積む。 • 天窓・太陽電池などの付属品付きパネルは山の一番上。 • 長いパネルの下に短いパネルは置けない。 • 施工作業動線は短いほうがよい。 トラックの台数はできるだけ少なくしてコストを削減する。

17. モデル化 • 直観的なモデル • パネルをオブジェクトとして定義。 • 制約条件に関わる属性をオブジェクトのプロパティとして定義。 • パネルの順序とパレット組(複数のトラックに分載に対応)に対して制約を設定。 • 制約条件を充足するパネルの積載順序とパレット組を計算する。 • トラックの台数・施行時の作業動線の最小化などの複数の選好条件を重み付けして線形に結合した目的関数を定義し、最適化を行う。 • 変数の数が少ないため近似的な最適化は可能。 • 最適化フェーズの打ち切りはタイマーで制御。

18. 3.事例（２） 屋根パネル自動分割システム[山崎01]

19. 問題・システム化の目的 • 問題 • 屋根面をパネルに自動的に分割する。 • 開口の有無・位置や、隣接屋根面の形状により、分割位置が決まる。 • パネルのサイズの上限・下限・標準サイズなどの条件がある。 • パネルの枚数・パターンの異なり数など、幾つかの最適化条件がある。 • システム化の目的 • グリッド単位の自由なプランに対して、基本的に自動的なパネル分割を行うシステムを目指す。 • 基本的な規則の適用によって多様なプランに対応できるシステムを目指す。 • パネル分割方式についての設計支援シミュレーターとして利用できるようにする。 • システム設計上の前提 • 射影平面（屋根伏せ図）上での問題として解く。 • 分割は、原則として軒線に対して垂直にのみ行う。 • 隣接する屋根面間の対称性を考慮する。

20. モデル化①線分分割問題として定式化 • １つの屋根面を属性を持った点により構成される１本の射影線分として表現することができ、屋根パネル配置問題は、この線分の分割の問題として扱うことができる。 • 分割についての条件として、以下のものが考えられる。 • 点の属性による分割についての制約条件、優先度などが定義される。 • 積載・施工・性能などの条件により制約条件、優先度などが定義される。 • 巨視的なさまざまな最適化条件が与えられるため、問題は、制約最適化問題として定義される。

21. モデル化②制約条件・最適化の条件と方法 • 制約条件 • 個別の制約条件については追加・削除を随時行って調整していく。（設計支援シミュレーション） • 構法上の条件 • 開口の条件 • 輸送条件（道路交通法・積込問題上の制約条件） • 施工条件（吊り下げ回数、据え付けの容易性など） • 原板サイズ（歩留まり）などの生産条件 • 断熱性能などの性能条件 • 最適化 • 下記の例のような条件につき、優先度づけを行って、最適化の目的関数を構成する。優先度づけは、評価を行いながら、変更していく。 • 隣接屋根面での対称性 • 枚数 • パネル形状数 • パネル種類数（寸法・属性含む） • 標準パネル出現率最大 • 最適化にあたって、邸全体ではなく、一部の屋根面のみ解の改良を行ないたい場合などに対応するために、最適化ステップでは、以下のような割付方法を採用した。 • 既に得られている解の変更したくない部分のみ、先に結果を領域変数に割り付けてしまう。 • 通常のように制約を設定する。 • 通常の残りの部分について、すでに求まっている評価値を上回るという制約を追加した上で探索を行なう。

22. 4.開発プロセスからみた事例の評価

23. 事例(1)屋根パネル積載計画システム

24. 事例(2)屋根パネル自動分割システム

25. その他の事例 • 複雑な工程条件を持った生産ラインの工程スケジューリング(加工系や半導体など) • パッケージベンダへのエンジンのOEM供給。カスタマイズ要望への柔軟な対応。 • 自社製のスケジューラ向けオブジェクトを備えた制約クラスライブラリ(C++)を用いた受託開発。高速プロトタイピング。 • 積み合せ・積み降ろしなどの現場の条件に対応した配送計画 • メタヒューリスティクスとの組み合わせ。 • 要員の勤務条件やスキルなどの特性を考慮した要員計画 • パッケージ開発・販売(「快決！シフト君」)。

26. [参考]事例にみる制約プログラミングの使われ方[参考]事例にみる制約プログラミングの使われ方 • 他の解法との融合：パラダイムとしての制約プログラミングの実践。 • 通常のシステム開発環境との調和。 • 制約プログラミングを「カプセル化」する。

27. 5.まとめと今後の課題

28. まとめ 制約プログラミングは開発現場にあった実用的な手法。 • 生産性が高い。 • 開発サイクルの短期化に対応可能。 • 近年主流となっているオブジェクト指向との親和性の高さも魅力的。 • プロトタイピング、スパイラル開発との相性が良い。 • フィージビリティの確保や性能向上を考えると早期から実データを用いた検証を繰り返すのが望ましい。 • ユーザーにとってわかりやすい設計ができる。 • 問題領域のエキスパートとの対話がスムーズに進むため、プロジェクトの初期段階での意思疎通不足による設計不良がおきにくい。 • 柔軟で変化に対する対応力が大きい。 • 初期開発だけでなく、保守・改良まで考えた場合に、変更に対して頑健な、長期間にわたり使い続けられるシステムを提供できる。

29. 今後の課題 • 制約指向の開発方法論の確立。 • 実用的な技術として存在をアピールし、適用プロジェクトを拡大。 • FP法の適用事例の蓄積や分析による精度の向上。 • 統合パラダイムとしての制約プログラミングの探求 • 制約伝播ベースの狭義の制約プログラミングと他の手法との組み合わせの推進。(LP, メタヒューリスティクス, NN, 進化論的計算 etc.)

30. 参照文献 • 制約プログラミングについてのより一般的な情報については、http://www.constraint.org/を参照。 • [CHIC95] Chamard, Fischer, Guinaudeau, Guillaud, “CHIC Lessons on CLP Methodology” (1995), http://eclipse.crosscoreop.com/eclipse/reports/CHIC_Methodology.html • [FRON94] Fron, “Programmation par contraintes”, Addison-Wesley France (1994) • [青木93] 青木「オブジェクト指向システム分析設計入門」, ソフトリサーチセンター (1993) • [UML02]ランボー, ヤコブソン, ブーチ, (石塚監訳)「UMLリファレンスマニュアル」, ピアソン・エデュケーション (2002) • [児玉99]児玉「システム開発の見積りのための実践ファンクションポイント法」,日本能率協会マネジメントセンター(1999,改訂版2006) • [BARTAK98] Bartak, “Guide to Constraint Programming” (1998), http://ktiml.mff.cuni.cz/~bartak/constraints/ • [HECS]番原,田村,井上,川村,玉置, 「Javaによる分散協調制約解消システムHECS」(2005), http://kaminari.istc.kobe-u.ac.jp/hecs/ • [PSLXV2-3] PSLXコンソーシアム, 「標準仕様バージョン2　第3部　業務オブジェクトモデル　勧告候補版」(2006), http://www.pslx.org/ • [西原97] 西原「制約充足問題の基礎と展望」, 人工知能学会誌, Vol12, No.3 pp.351—358 (1997) • [橋田94] 橋田「知のエンジニアリング」, ジャストシステム (1994) • [森94] 森, 山崎, モリコン「制約ベース的アプローチによる勤務計画・工程計画立案システムの設計」1995年度関西経営システム協会懸賞事例集(1995) • [山崎98] 山崎, 森「制約解消系を用いた屋根パネル積込システムの開発」大分統計談話会第17回(1998) • [山崎01] 山崎「制約プログラミングは計画系システム開発に役立つか」,COM・APS研究部会第4回研究会 (2001)