複雑化は気分によるものであり、シンプルさは意志によるものである

システムは気分で判断していくと、どんどん複雑化していく。シンプルにするためには意志が必要だ。

悲観主義は気分によるものであり、楽観主義は意志によるものである
「アランの幸福論」より

アランの幸福論

「ユーザーが選択できる」という複雑化

たとえば、あるアプリのホーム画面についてこんな議題があったとする。

ホーム画面の背景色は何色にしようか？

これに対していろいろな人がいろいろな見解を言う。

・馴染みのある白がいいと思います。
・クールに黒でしょう。
・優しい雰囲気を出したいから緑。

そして、すべてを飲み込むこんな言葉が登場する。

じゃあ色を選択できるようにしましょう。

「ユーザーが選択できる」という言葉は非常に強力で、あらゆるものを飲み込む。「白 or 黒の二択」も「色を選択できる」の前では、まるで不自由に見えてしまう。

正直、この色の選択だけなら、まったく複雑化しない。自由な選択肢が必要なときも、もちろんあるだろう。

ポイントは「ユーザーが選択できる」という案が、無条件で採用されることだ。

「可能ならユーザーが選択できる方がいいよね」
「あらゆるパターンに対応できるように」
「開発工数があまり変わらないなら、自由に選択できるようにしよう」

これらの台詞が飛び交ったら黄色信号だ。

なぜ「ユーザーが選択できる」が採用されるのか

ユーザーがなぜ自分たちのサービスを利用してくれているのか。真の課題を理解していないと「ユーザーが選択できる」が採用される。「自由に選択できた方がユーザーもうれしいはずだ」という考えを疑うことは難しい。

経験値だが次のような考え方が広く浸透していると「ユーザーが選択できる」が選択されやすい。

１．課題への共通認識がない
２．目的は売上
３．すべてが優先という名のカオス
４．木をみて森もみるが、根は見ない

１．課題への共通認識がない

課題を理解しようという姿勢がないと、課題はファンタジー化する。担当部署ごとにファンタジーな課題をもって、議論に望むことになる。

課題を解決するため、新機能や機能改善という矢を放つ。が、課題がファンタジーのため、その矢をどこに打てば良いかわからない。だから、考えうる場所に矢を放ちまくる。矢は「ユーザーが選択できる」という魔法のコトバにかわる。

２．目的は売上

課題がファンタジーだと、目的が売上になりやすい。売上はファクトだからだ。なんとなくイイ感じになる。目的が売上だと、極論としては手段はなんでもOKになる。

なんでもOKと「ユーザーが選択できる」は相性がイイ。だって、なんでもOKなのだから。

３．すべてが優先という名のカオス

何に取り組むべきか。優先順位を決めましょう。この問いに対するアンサーのひとつに「すべてが優先」という気合のコトバがある。

優先度を決めよう
低 → 中 → 高 → 最高 → 超最高 → 超最高＆緊急 →超最高＆緊急＆ゼウス！

こうなると優先度「高」は、真ん中より下になる。なんて言葉は空虚なのだろう。いや、逆に美しいのかもしれない。「嗚呼 月がきれいですね」

すべてが優先な世界では「ユーザーが選択できる」もまた美しい。

４．木をみて森もみるが、根は見ない

木をみる。目の前の機能を充実したものにしよう
森もみよう。サービス全体も考えよう
だが、どちらにも根がある。根がない木々は脆く倒れやすい。

ここでいう根とはバックオフィスのことだ。

キャッシュポイントが増えることは売上があがるポイントではあるが、その分、売上を管理する仕組みがひとつ増えることにもなる。

・条件によって基本料金が違う 　
条件ごとの料金パターン管理せよ

・さまざまなオプション料金もある 　
基本料金 × オプションで、可能性は拡大

・例外にも数パターンある 
例外の例外の例外の例外・・・果てなき旅は続く

複雑化した根をシンプルにするのは、葉を整えるよりも困難だ。根は土を掘りかえさないと見えない。掘りかえすには、根気も必要だ。泥臭いタスクを繰り返してようやくたどり着く場所。

いざ整理するときに、誤って根幹を切ってしまうリスクが常に潜む。根を失った木はすぐに倒れてしまう。だから、慎重に丁寧に。

でも、まわりからみると、まるで進んでいないように見えるだろう。「おーい！今なにやってるの〜？」

複雑化がもたらすもの

選択できる項目が増える　→　条件分岐が増える　→　想定すべきパターンが増える　→　複雑化へ

自由に選択できる項目、設定値といえるようなものが増えていくと、あっという間にシステムは複雑化していく。まるで自然体でいると複雑化するようでもある。

上から流れてきた水の行く手に、石を置くと水は左右にわかれる。その先にも石を置くと、さらに左右にわかれる。結果、上から流れた水がどこに流れ着くのか、ついに予想不可能になる。

条件分岐が少ない場合は、どんなに多くの水が流れてきても、左右のどちらかに流れ着くことがわかる。だから、水の流れを目でおえる。

システムを複雑にするとどうなるのか、実際の現場の粒度でも考えてみよう。

１．考慮すべきことが増える
２．少しの手直し、多くの手順
３．コア機能が磨けない

１．考慮すべきことが増える

新しい機能や画面を追加するとき、考慮すべきことが増える。「誰にも選ばれていない選択肢」であっても、その選択肢も考慮しなければならない。

２．少しの手直し、多くの手順

少し手直ししようと思っても、多くの手順を踏まなければならない。少しの手直しであっても、上流の条件分岐は、下流に大きな影響を与えているからだ。

おっと上流に置いてある石の形を変えてしまった。流れは一斉にかわる。さぁぜんぶを受け止めなければ。

３．コア機能が磨けない

サービスのコアな機能は、何度も改善を繰り返して磨いていく。１回リリースしてOKなはずがない。１００点満点で表現するならば、リリース前の最高得点は５０点。もう５０点は使ってくれる人がいて、はじめて獲得できる得点だから、本質的に１回のリリースで１００点満点は獲得できない。

だけど、考慮すべき点が多く、少しの手直しでも多くの手順を踏む必要がある。「コア機能の改善にまで手が回らない」・・・なんて皮肉な言葉なんだろう。自分で書いていて胸が痛い。

意志をもってシンプルに

部屋は何もしないと散らかっていく。意志をもって整理整頓に踏み出す必要がある。システムのシンプルさを保つためにも意志が必要だ。要点を見つけ出し、それ以外を「削る」必要がある。

多機能への恐怖がなければ「追加」の判断に時間はかからない。万能薬ならぬ万能言葉「あってもイイ」は思考をとめる作用がある。さあさあ追加しよう！

一方、多機能に恐怖を覚え、シンプルさを保とうとすると、「削る」「やらない」判断が必要だ。それには観察と考察、それをおこなう時間。そう勇気も必要だ。うむ…削ろう。

つまり、こういうことかもしれない。

・”シンプル”な手順の先にある複雑なアウトプット
・複雑な手順の先にあるシンプルなアウトプット

最後に「人間は考える葦である」で有名なパスカルが、友人への手紙にそえたとされる一文を。

時間がなかったため、この手紙が長くなりました。