2017年10月31日

「自動」は簡単ではない


初めての方はこちらを「はじめに

今回は「自動」という仕様についてです。
結構気軽に自動で何かをする機能を盛り込もうとする場面を良く見受けますが、少し注意する必要があるというお話です。

自動の特徴


みなさんも「こことここは自動で設定してしまえばいいんじゃないですか?」といったような意見に出くわす場面は良くあると思います。今までAとBとCを設定していたものを一発で全部自動的に設定してしまうといった具合です。確かにその時はもっともな意見に聞こえて「確かにそうだな」と思えます。

しかしその時に将来にわたって「こことここ」の設定だけで済んでいるのかはなかなか考えないものです。その辺が落とし穴という訳です。
自動というのは「こことここ」といった手動で複数回操作していたものを一度で済むようにする様な操作の省力化の機能と言えます。従って操作が減るだけであって基本的には元々の(手動の)機能が少なくていいという事ではありません。元々の手動の機能は要件から導き出された「やりたい事」のはずだからです。

例えばデジカメで写真を撮った時にカメラがシャッタースピードとか露出とか色々なパラメーターを自動で設定してくれたりします。しかしだからと言ってシャッタースピードとか露出とかの機能が要らなくなる訳ではありません。やはり手動で細かく設定したいというニーズは発生します。

この様な手動と自動との関係性から次の様な難しさが発生します。

自動にする範囲の難しさ


一つにはどこまでを自動とするべきかの判断です。
逃げ手として手動の機能を用意していたとしてもほとんどが手動で操作するようでは自動をサポートした意味がありません。ユーザーは僅かの省力化の為に新しい機能、操作を覚える様な事はしないものです。従って大体の使い道においては自動で済むようでなければ折角用意しても使われません。仕様的にその閾値がどのあたりなのかを適切に見極める必要があるという事です。

普段からリリース後にほとんど要望が挙がらない様な仕様のレベルが達成出来ているならば特に難しい話では無いと思います。しかしリリース直後から要望が挙がって度々バージョンアップを余儀なくされるようなレベルでは難しいかもしれません。もしデジカメの場合に自動の仕様を晴れの時だけ上手く撮れるようなロジックでリリースしたとしたら、きっとすぐに「曇りの時も対応してください」と言われるはずです。そして曇りの時の対応をすると今度は「夜の時も対応してください」という要望が来て「一体どこまでやれば満足を得られるのか…」という話になって行きます。これは最初に晴れの時にしか対応していなかったのでユーザーが「使えない」と思ってしまったからです。本来は最初から精度は別にして仕様の範囲としては晴れでも曇りでも撮れるようになっていなければならなかったのです。

作りの難しさ


もう一つは作りの難しさです。
今述べてきたように作りの上で手動ありきで自動を考えるならばいいのですが、そうではなく目先の自動化に囚われて機能を作りこんでしまうと後々様々な困難に陥ります。例えば要望の対応が大変になったり、手動の機能との不整合が発生して「自動でしか出来ない機能」とかが現れたりします。

一つ例を挙げます。
Excelでセルにデータを入力するとカーソルが下に行きます。特に自動と関係無いと思うかもしれませんがそうではありません。これはExcelがデータ入力後に「自動」でカーソルを移動させていると考えられます。それが証拠にオプションで入力後のカーソルの移動は設定できて、移動させないという事も出来ます。
53N032_001.jpg
なのでデータ入力とカーソル移動は機能としては独立していて、それを自動で合わせてやっていると考えられます。

勿論、中の作りが見える訳では無いのであくまで推測です。ただ、ここではその正しさが問題ではないのでその仮定で話を進めます。
つまり最初にこのオプション設定が無く自動ありきで、入力後にカーソルを下に移動するという仕様と一対一で機能を固定的に作り込んでしまっていたらその後の対応はどうなるでしょうという話です。もし最初にそういう風に作り込んでいたら、次には「カーソルを右に動かしたいパターンもあるらしい」という事になって、更に次には「いやいやそもそもカーソルを動かさないパターンもあるらしい」という話になって行きます。その度に「入力後に下」いう固定的なコードを修正してどうにか対応して行く事になる訳でどんどんコードが汚くなって行きます。本来は層が別れていて下の基本的な層にデータ入力とカーソル移動があってその上位層に「データ入力+カーソル移動」という自動の機能があるべきです。
53N032_002.jpg

自動はあくまで使い勝手の機能に過ぎなくUI的な機能に過ぎません。なので「検証システムのすすめ」で少し説明した様にUI部分ではなく本体部分の機能こそが本来の機能としてサポートするべきものです。つまりここでいうと本体の機能は下の層の基本的なデータ入力とカーソル移動という事になります。

これは設計の汎用性の話と近いものがあります。(設計における汎用性とは)「入力後カーソル下」という専用機能で作ってしまうのではなくてより汎用的なデータ入力とカーソル移動に分離して作る必要があるという事です。'なので「設計における汎用性とは」で述べたような難しさがつきまといます。

その他の例

似たような話は至る所に見出せます。
例えばWindowsにデフォルトで入っている、画像を表示するフォトビューアーというソフトウェアがあります。
53N032_003.jpg

これは非常にシンプルでカーソルの左右でディレクトリー上の画像ファイルを前、次と切り替えて表示するだけのものです。それ以外の機能としてはスライドショーがあります。このスライドショーなども自動とみなせます。なぜならスライドショーは「全画面+画像切り替え」だからです。なのでこの機能を適切に設計するならば、Excelの時と同じように基本的な機能と自動との二層に分かれていて、下位の基本的な機能には画面サイズに関するブロックと画像切り替えのブロックがあるような形になると思われます。
53N032_004.jpg
もしこの様に設計されているならば、今後「全画面+手動で画像切り替え」といった仕様を追加しようとした場合も無理なく対応出来る事になります。(現状は自動で画像が切り替わる仕様しかありません)

自動に対する考え方


結局自動の落とし穴というのは以下の様なイメージに集約できるかもしれません。
53N032_005.jpg
上の様に自動だけの機能として作ってしまうと後々他にやりたい事が出て来て対応しきれなくなります。下の様に基本的な機能を整理してそれらを積み上げた上に自動を実現して初めて将来も安泰になります。しかしその為のパワーは仕様から単純にイメージした見積もりよりは随分多くかかります。その差はこの図の通り上は棒を立てるだけの量に対して下は山を築く様に裾野も含む量になります。

今回挙げた例は他愛もないものなので勿論こんなに大袈裟な論議は必要ありませんが、自動というものには規模に関わらず常にこういう注意点があるという事です。例えば最近は良く車の自動運転の話題がニュースになりますがそういったものでも同様です。手動の上に自動を積み上げる必要があります。ニュースを見ると各社は完全自動運転、つまり人間が一切運転しなくていいという自動運転を目指しているようですが、恐らく「人間が運転しない」というのは「人間は運転できない」という事では無いはずです。もしそうではなく人間が運転する機能がサポートされないのだとしたらそれは無謀と言っても良い位にハードルが高い事に思えます。飛行機にしろ船にしろ自動運転は既に実現されていますが手動で運転できないなどという事は聞いた事がありません。いずれもデジカメ同様自動で対処できない事態になれば人間が手動で操作します。手動を提供せずに全てを自動で対処するという事は極めて大変な事です。

一覧


メニュー

関連


事例:ボーイング737MAXの墜落事故


記事を広める



posted by 善 at 20:59 | Comment(0) | 仕様 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。