正しく問題を単純化する

正しい単純化とは

単純化は短絡化とは異なります。

一般に物事を単純化することはあまり良いことではありません。 複雑なこと、多面的なことをあたかも単純であるように取り扱うのは通序う問題のある行為です。

しかし、複雑であることが正しくないこともあります。

問題は表面的に複雑であっても個々の部分でみればそこまでの複雑性はない、ということもあります。

問題を解決しようとするとき、問題がどのようなものであるかを正しく認識することは極めて大事なことです。 Mimir Yokohamaは「問題をいかに定義するか」という点において秀でており、これにより省コストで迅速かつ快適な解決策を実現できています。

ではそれはどのように行うのでしょうか。いくつか例を見てみましょう。

おばあさま、おじいさまの携帯電話問題

ここ数年ないのですが、以前はご高齢の方が初めて携帯電話を持ったものの、使い方がわからないというご相談を多くいただきました。

これはフィーチャーフォンの話ですが、多くの場合、メールや電話帳の使い方がわからないことが問題でした。 携帯電話が便利であることを力説されるものの、依然として使い方がわからず家の電話のほうが実際としては便利である、というお話をよく聞きます。

このページをご覧の方は携帯電話は使える可能性が高いと思われますが、 使える立場としては「携帯電話より家の電話が便利である」ということは同意しかねるでしょう。

しかしながらこのことに対して「携帯電話のほうが便利だから覚えるべきである」と主張することは解決になりません。

ここで考えるべきことは「電話が使えないわけではなく」「家の電話よりも携帯電話のほうが不便であると考えている」ということです。

電話は使えている状態で比較して携帯電話が不便であるということをUI的な理由で言っている(つまり、高度な意味で言っている)わけでないのであれば、問題は「家の電話でできることができないから不便である」という意味になるでしょう。

そして、この「できない」は「使い方が覚えられない」に起因します。

「わからない」と「覚えられない」はちょっと違います。 「わからない」の場合は教えれば良いということになりますが、「覚えられない」はその方法がよくないか、もしくは覚えるためのコストが高い、あるいは覚えるための前提知識がない、となります。

高齢の方は現在中年の方にとって「馴染みのあるUI/UX」が馴染みがない可能性があります。 これは「前提知識がない」に相当します。この解決には前提となるそれらの経験を積む必要性を示します。

しかしここで問題があります。 ご高齢の方になると覚えるために必要なコストは若い方よりも多くなります。 かつ残りの人生で払うことができるコストがあまり多くありません。

「未知のITによる利便性」というのは、「先に多くのコストを払ってあとの労力を省略することでそのコストを回収する」性質のものであり、「残りの人生の量」に大きな影響を受けます。

そのため、ご高齢の方の場合、「それが明らかなメリットをもたらすのでなければコストを最小化する」という考え方が必要になります。

このことから、この問題には一旦は電話帳について説明をしますが、

のであれば、電話帳の説明がピンとこない時点で、「電話帳を使わない」という選択肢に切り替えます。

問題を改めて考えてみましょう。 「電話帳を使えないために自力で電話をかけることができず不便である」という状態にあるわけです。

もちろん、クイックダイアル登録によって操作を単純化するという方法もありますが、それは行動を制限する結果になり、望ましくありません。 であれば、この場合最善と思われる解決策は「電話帳を使わない」です。

ご高齢の方でもプッシュダイアルは使ったことがあるでしょうし、なかったとしてもプッシュダイアルのUIを習得するのは難しくないでしょう。 電話帳を使わなくても電話番号を押す、という行為は家の電話と変わらない操作であり、容易にできると思われます。

「元々提案した人にとって便利で当たり前になっている機能を使わないことを提案する」というのがポイントです。 別に電話帳がなくても紙の電話帳や記憶している電話番号があるわけですから、習得に問題があるのであれば、「習得を阻害する問題をできるだけ小さくする」のが困難さそのものを低下させることにつながります。 だったら電話帳はなくても使えるのだから電話帳は覚えなくても良い。ただ発信と切断の手順だけ覚えておけば元々できていたことはできるはずだ、と考えられます。

この場合付加的には「番号を押してから発信する」が一般的(間違いを防ぐ意味で多くの人がそうする)ですが、発信キーを押してんからでもかけることはでき、手順として現在と対比したほうがわかりやすいため、説明して混乱をきたすようならそれを一旦忘れてもらって完全に対比しながら説明するようにしています。

Shift JISで文字化けする文字を探す

コンピュータにおける文字表現は現在はUnicode(特にUTF-8)が主流ですが、以前は日本語WindowsではShift JISベースのCP932が使用されていました。

Shift JISは日本語文字を定義したJIS X(0201/0208)に基づいていますが、UTF-8は世界中の文字を網羅するUnicodeに基づいており、UTF-8のほうが圧倒的に多くの文字を利用できます。 しかしながらWindowsで動作する少し前に作られたプログラムはCP932を想定しており、一方最近のExcelはUnicodeに基づくUTF-16LEで書かれているため、「Excel上では正常に表示できるけれどもそのデータを渡すと文字化けする」というケースがあります。

そこで文字化けする文字を予め検出する、というプログラムを作ったことがあります。 実際のプログラムはより多くのケースに対応していますが、ここでは「JIS X上にはない文字を使用しているためUnicode系列の文字表現から変換したら確実に失われる文字を検出する」という部分に限ってお話します。

もちろん、Unicodeテキストの文字をひとつずつJIS X上に同意文字のあるものか照合する方法もありますが、最適解とは言えませんし、低速です。

Mimir Yokohamaがとった方法は「変換してしまう」ということでした。

Rubyにおいて文字表現を変換したとき、変換できなかったらどうするかというのは指定することができます。 そして、その標準の動作として変換できない場合はEncoding::UndefinedConversionErrorという例外を発生します。

この変換した結果を使う、使わないにかかわらず、変換処理だけをしてしまいます。

begin
  text.encode("CP932")
rescue Encoding::UndefinedConversionError
  puts "変換失敗"
else
  puts "変換成功"
end

プログラミング言語処理系の機能として文字表現の変換があり、その機能では変換できないケースが想定されています。 そこで、変換した結果を使わないとしても変換してしまい、変換できなかったという結果が発生するかどうかをチェックしているわけです。

結果としてこの機能は極めてシンプルに書くことができました。

PureBuilder Simply

PureBuilder Simplyは非常に有用なソフトウェアですが、実のところコードを記述する実装難度は非常に低く、ビギナーでも書けるようなコードになっています。

PureBuilder Simplyの機能性は大部分が設計によってもたらされており、問題を単純化したことによって「簡単な構造と実装」が実現しています。 これは先代(PureBuilder2)において「設計がうまくいっていないものの実装でカバーする」という状況であったものを、設計が成功したために成功したのだと言えます。

PureBuilder Simplyの核となっているのは「Pandocで文書を生成する」ということです。 Pandoc自体は大型のソフトウェアで、決して単純なつくりをしていません。 そもそもPureBuilder Simplyがやろうとしていることは決して単純ではなく様々な機能をフォローしなければならないため、当然ながら全体でみれば非常に複雑なものになります。

このような場合には「直交性のあるコンポーネントに分割する」ことが大事です。 オールインワンにしてしまうと余計なコードを書く手間は減りますが、メンテナンスが困難で複雑なソフトウェアが出来上がります。

PureBuilder Simplyはウェブサイトを構築するソフトウェアですが、「より簡単な形式で文書を書き、それをウェブ文書に変換する」という機能があります。 ウェブサイトを構築するために「複数の文書に渡ってそ処理を行う」ということと、「インテックスページなどを生成する」という処理もありますが、これは「文書を生成する」という機能とは直交しています。

従来、これはPureDocという専用のフォーマッタを利用していました。また、PureBuilder2ではKramdownライブラリを使ったフォーマッタをPureBuilder2自身が持っているという構造でした。

PureBuilder Simplyではこの「文書を生成する」という機能をPandocに全面的にまかせています。

PandocはKramdownと同じくMarkdown形式で文書を書きますが、ずっと高機能で様々なことができ、複雑で難しいPureDocを利用する必要性がなくなりました。 PureDocはコードとしても構造としても複雑だったので、これがなくなるだけで解決しなければならない問題は随分すっきりします。

さらにPandocの場合、「自由な形式でメタデータを書くことができる」「テンプレート機能がある」という特徴があります。 そこで「特別な機能を必要とする場合メタデータで与える」「Pandocのテンプレート機能を使って特殊な形式を生成する」「Pandocで足りないものはテンプレートレベルでのeRuby拡張、さらに前処理/後処理プラグインによって加工可能にする」といった方法で機能を追加し、Pandocでは不足する機能を補ってPandocベースでも十分にPureBuilderとしての役目に足りるようにしています。

結果としてPandocを中心として段階的処理を行うことができるようになり、個々の段階での処理は単純なものになりました。 問題が整理されているため、機能を追加するときにもどの段階の処理を変更する、あるいはこの段階とこの段階の間に追加するといったことが容易にできます。

結果として同様のプログラムの中でも圧倒的にコンパクトでありながら強力で使いやすいものになりました。

«