ソフトウェアの複雑さはどのように制御すべきか？

ソフトウェアやシステムのアーキテクチャ設計では、ソフトウェアの宿命と言える複雑さをどのように制御すべきか、という根本問題を孕んでいる。
考えたことをラフなメモ書き。

【１】「スティーブ・ジョブズ II」の自叙伝では、ジョブズが携帯音楽プレーヤーのあるべき姿を述べている。

(「スティーブ・ジョブズ II」から要約)
iPodを本当に使いやすくするには、iPodでできることを制限する必要がある。
iPodで制限した機能（プレイリストの作成など）はコンピュータ側のiTunesに持たせる。
リオのような機器があんなに役立たずなのは複雑だからだ。
アップルの場合、iTunesソフトウェアとiPodという形でコンピュータと機器を協力させられるから、複雑な部分をあるべき場所（iTunesソフトウェアとそれを操作するMac）に持っていけた。

ジョブズは、ユーザが触れるiPodは極力シンプルにして、PCで操作するiTuneソフトウェアに複雑さを移行しようとした発想で開発している。
そのおかげで、ユーザはワンクリックないし簡単な操作だけで、音楽を簡単に聞ける。
プレイリストを作ったり、曲を同期したり、メモや写真を同期する処理は、PC上で操作した方が簡単だ。

Android携帯が使いにくいのは、iTunesのようなソフトウェアがないために、必要な情報の同期処理が難しい点もあるのだろう。
でも、クラウド経由で同期する方法もあるから、今後変わるかもしれない。
とは言え、ユーザが触れるインターフェイスはシンプルにして、複雑さを別の場所へ移すという発想で設計している。
その思想があるからこそ、複雑なハードウェアを作る必要がないので、iPhoneやiPadなど次々に新製品を作り出すことができたわけだ。
最近流行しているアジャイルUXという考え方も、この発想と似ているかもしれない。

【２】渡辺幸三さん著「販売管理システムで学ぶモデリング講座」の227頁では、「複雑な機能と複雑な業務のバランス」節で、ソフトウェア設計の複雑さをどこに配置すべきか、という渡辺さんの観点が書かれている。

例として、帳簿在庫と実在庫の差異が発生した時、出荷指示を画面にどのように表示すべきか、という問題が提示されている。
状況としては、例えば、月末に倉庫で、小売店の商品や工場の製品を実地棚卸ししてみたら、帳簿(システム)と実際の在庫数が違っていた時に相当する。
原因としては、間違って記録していたり、繁忙期の在庫引当や仕入れの記録を忘れていたりする時もあるだろう。
あるいは、生鮮食料品のように腐ってしまったり、醸造酒や醤油などのように保管していたら蒸発して減ってしまった場合もあるだろう。

「販売管理システムで学ぶモデリング講座」では2つの方法が提示されている。
一つは、実棚で差異が発生したならば、出荷予定を取り消して、在庫数を確定させるように修正した後、もう一度出荷指示を作り直す方法。
これは、実棚の差分を認めず、理論在庫と実在庫を一致させる作業を重視する方法。

もう一つは、実棚の差異があっても、ユーザの指示次第で、システムが在庫数を調整して都合よく出荷予定を作り直す方法。
これは、実棚の差分を認めて、システムが在庫確定よりも出荷指示を優先させる方法。

「販売管理システムで学ぶモデリング講座」では前者の方法を勧めているが、現状の業務設計では前者が必須要件だ。
何故なら、在庫数が間違っているまま業務を進行させるということは、商品有高帳引いては貸借対照表の数字を狂わせることにつながり、内部統制や会計監査でNGを食らう可能性があるからだ。

「販売管理システムで学ぶモデリング講座」に説明があるように、実在庫と理論在庫が一致するような運用品質を求めるように、ユーザ企業の担当者が業務のレベルを高めるように持っていくべきだ。
そうでなければ、いつまで経っても、日々の在庫を確定させる動機がなくなってしまう。
小売業ひいては製造業における業務管理の基本は、在庫のズレをなくすように運用すること。

在庫管理がザルでは、自分たちが今どれだけの資産を管理しているのか、を理解できないことにつながる。
普通は、倉庫の棚に置かれた商品や製品が散らかっていれば、数えることすら手間がかかる。
ここから、トヨタ生産方式における５Sの整理整頓などの改善活動が生まれるのだろう。

この話に関して、システム設計では、データモデルと業務モデルを複雑にして、機能モデルを単純化する方針を「販売管理システムで学ぶモデリング講座」では勧めている。
理由は、機能の開発・保守はコストがかさむし、複雑すぎる機能は業務や体制の硬直化を招くから、と。

ここでは、機能モデルは画面などのユーザインターフェイスを指すと思われる。
つまり、ユーザが触れる画面は極力シンプルにしておき、めったに起きない状況に対処するための複雑な運用はマニュアルに書いて参照するようにした方がコストが安く済む。
年1回の例外的な運用は、手運用でカバーするように手順化しておけば、無駄にシステムを作って複雑化する必要もない。
この辺りはシステム開発と運用業務のトレードオフかもしれない。

【３】「販売管理システムで学ぶモデリング講座」では、システムが宿命的に負うべき複雑性をいかに分散して全体のコストを最小化するかというBPR的な観点が必要と述べている。
iPod開発にしても、業務システム設計にしても、ユーザが触れるインターフェイスは極力シンプルにして、システムの複雑さはソフトウェア内部に押し込めてしまう方法を勧めている。

システムの複雑さは、エントロピーみたいなものであり、複雑さ保存の法則みたいなものがある。
つまり、システムの複雑さは減らすことができるわけではなく、常に一定であるがゆえに、その複雑さをどこへ配置して、ユーザとシステムを一体化した世界でコストを最小化し、価値を高めるか？という問題をいつも孕んでいる。
全体最適という観点は、複雑さの再配置(これこそがBPRかもしれない)という見方も含んでいると思う。