ブロントサウルスタワーへ行ってきた

暮らしと読書と珈琲と

Posted on 2015/12/8 by Kentaro

ブロントサウルスタワーへ行ってきた

『ライト、ついてますか - 問題発見の人間学』から学ぶ問題定義と解決策について、制作現場にありがちな問題や対処の考え方、ツリーを用いた問題定義&解決策の図解化などを紹介してみます。

『ライト、ついてますか – 問題発見の人間学』

良書でした、久々にたのしく本が読めました。
近頃のメソッド集のような本ではなく、考え方の根幹を説明してくれてます。本棚に置いて定期的に読み返したい系ですね。
最近この本を知人に勧めてもらったんですけど、タイトルの由来が面白くて興味を持ったんですよ。

タイトルの由来だけでも学びがある良本

タイトルの由来だけでも学びがある良本

あるトンネルで、トンネルを抜けた後でも車のライトをつけたままにしてしまい、出口先の観光地でバッテリー切れを起こすという事故が頻発していたんですね。この問題を解決するには、一体どんな解決法が適しているんでしょうか?

トンネルの出口に『ライトを消してください』という看板をつければ解決なのかな?…と思いきや、外が暗い夜間の場合はトンネルを出た後もライトをつける必要があるため、適していません。無灯走行で別の事故を引き起こしてしまいます。また、ライトを消した状態でトンネル内を走行しているケースも考えられたりします。
となると、設置する看板の文言は『日中の場合はライトをつけて、夜間の場合はライトを消して、ライトを消して走行している場合でかつ日中の場合は…』なんて長ったらしいものになってしまいます。こんなの走行中に読めたもんじゃありません。

そこで考え方を『そのそも目的は何だろう?』に変えると、目的はドライバーにライトを消せ付けろと指示する事ではなく、『トンネルから出た後のライトの状態が適していない』という問題を解決させる事だと気づきます。そしてドライバーは、ライトを適した状態に切り替える事は本来造作もなく行える事です。問題は『ライトの状態に意識がいってない』という、うっかりが原因だったんです。
そこで、トンネル出口に『ライト、ついてますか?』という文言の看板を設置し、ドライバーへライトの状態を意識してもらうようにしたら、ライトつけっぱなし問題は解決となりました。

…という例題の『ライト、ついてますか』が、そのままタイトルになっているんですね。
この、そのそもの問題点(目的)は何かという部分に焦点を絞る考え方は、ものすごく大事だと思うんですよね。解決法だけに焦点を絞っていては、手間だけかかってそもそもの問題が解決されない(目的が達成されない)事も多いって思うんです。

ブロントサウルスタワーは、ありがちな失敗例の集大成

ブロントサウルスタワーは、ありがちな失敗例の集大成

エレベーターの速度がやったら遅いと悪評高いブロントサウルス・タワー。入居者は団結して『エレベーターをなんとかしろ!』と言うが、オーナーは『お金がかかるからやらん!』とシカト状態。はてに入居者グループとオーナーで大戦争となり、いかにオーナーを叩きつぶすか、いかに入居者グループを黙らせるかに夢中になる始末。

論争の果てに焦点がすり替わってしまい、いつまでたっても問題が解決しないパターンですよね。両者悪者を決めてそれを叩く事に夢中になってしまい、本来の悪者であるエレベーターが放置状態という、一番やっちゃいけない失敗例の1つだと感じるんですよ。
これの画期的な解決案として行われた、問題点を『エレベーターを待つ時間に苛立ちを感じる』と定義し、待ち時間を有意義に過ごせるものをホールに用意する…というのも、本来の問題点(エレベーターが遅いこと)がスルーされているので、根解決にはなっていませんよね。結果としては問題が解決しているように見えるんですが、正しい解決とは言えないと思うんです。
(これは、後にエレベーター業者が定期点検で欠陥を発見し、本来あるべき速度で動くようになって根解決。正しい解決策は『エレベーター業者に点検を依頼する』だった…という皮肉で説明されてますが)

この本で言わんとしている事は、この最初の項で挙げられているブロントサウルスタワーに集約されていると思うんですよね。後に続く項は、例題は違えど部分部分を細かく説明してくれている補足のようなもので。
問題が発生した時に『そもそもの問題点が挿げ替えられてしまう』ことと『正しくない解決策に固着してしまう』ことがありがちなので、特に注意していく必要があると思うんです。

正しい問題解決の為に意識するゴール地点

正しい問題解決の為に意識するゴール地点

私の場合、制作や修正を行う時に『これは何のためのもの?』『誰に何を提供するもの?』、また『現状でどのような問題があるの?』『何を解決させる必要があるの?』って意識して行ってるんです。

あるあるなパターンですが、『指示通りに制作や修正を行ったのに、納得されなかったり再び修正が入った』というのを避けたいんですよ。
これが発生する原因は『目的達成の手段が不適切』か『目的そのものがズレている』のどちらかです。この状態で、メソッドだけを聞いてその通り行ってしまうと、その奥にあるゴールにたどり着きません。
何のために、何を行うか。この2つをセットにして確認する事が重要だと考えています。

例えば、Web制作で『記事一覧の表示に、カテゴリーとジャンルとレベルと機能別と投稿日時別それぞれから絞り込むページを作成。さらにカテゴリー別ページからはレベルと投稿日時別に絞り込むページに遷移し、ジャンル別ページからは機能とレベルと投稿日時と…』なんて依頼がきたとします。(想像しただけでも記事検索ページはしっちゃかめっちゃかですね)
しかし依頼は『行う行為』の指示だけで、『何のために』の説明が抜けています。
ここで『何故このような構成にするの?』と尋ねられれば、『細かい条件検索を実装して、的確な記事を表示させることでユーザーの利便性をアップさせる』なんていう理由(目的)が聞けたりします。それが目的なら、ページをいくつも遷移する結果になるこの方法は不適切で逆効果を生んでしまいます。サイドバーにタグクラウドなどを設置させる手段のほうが、ページ遷移数も少なく早く記事にリーチしてユーザーの利便性もアップ、作る側も少ない工数で効率よく目的が達成できます。より良い目的達成の手段を提案することで、ユーザーもクライアントも製作者も幸せになれます。

また『何故このような構成にするの?』と尋ねた際に『いいから指示通りにやれ!』などといった具合に、目的や理由を説明せずに指示の実行のみを求める人もいますよね。これも悲しいかな『あるある』ですが、これでは手段が目的に適しているかも不明瞭で、目的が『手段を実行する』ことにすげ替えられており、正しくゴールに到達するかもアヤしくなります。
(こんなこと言う人になっちゃあいけませんよ。怒鳴って従わせたところで、頭のいい相手ほど『問題解決意識が欠けているな』と見限られて離れていかれるのがオチです)

Don’t take their solution method for a problem definition.
『他人の解決方法を問題の定義としてはいけない』

この本で言っている、これですね。
『Aを解決するためにBを行え』『さてどうやってBを行うか』
ここでBを行うためのCを導き出す前に、Aをよりよく解決できるDは無いか、Eは無いか。またAの奥の目的であるαはないか。ここに意識を配ることが大切だと思うんです。

手段から目的を導き出して、抽象度を上げていく考え

『問題の正しい定義が得られたかどうかは決してわからない、問題が解けたあとでも』
『正しい問題定義が得られたという確信は決して得られない。だがその確信を得ようとする努力は、決してやめてはいけない』

要するに『何が本当の解決すべき問題かは永久にわからない(加えて、何が一番正しい問題解決手段かも永久に判明しない)けど、考えるのをやめちゃダメだよ、間違った問題定義(と解決案)にとどまり続ける原因になるからね』って事を言わんとしてると捉えました。

この『問題の正しい定義』を考え続けると、視点の抽象度が上がっていくと思うんです。

図1:初期の問題定義と解決策の考え方

例えば『映画のチケットを買う必要があるけど、お金がない』という問題の解決案を考えると、問題の下に手段(解決案)が並びます。
ここで『では、映画のチケットを買ってどんな問題を解決したいの?』と考えると、『彼女をつくるためにデートへ誘う手段がいる』という新しい問題定義が見つかります。今まで問題定義であった『映画のチケット』が解決案の1つとなり、同列に他の解決案が並びます。

図2:上位の問題を定義して抽象度を上げる

さらにこの目的を探っていくと、『年末のカップル推奨パーティーに出席するため』>『年末の連休におもいきり遊んで楽しむため』…と、抽象度が徐々に上がっていきます。

図解3:問題定義と解決策のツリー

この視点が完成すれば、根本の『年末の連休を楽しむ』という問題解決の方法はものすごく多岐にわたり、より都合のいい手段を自由に選べるようになります。
財布が寒くてチケットを買えないゆえに、手持ちのものを売ったり知人にお金を借りたり…という手段を選ばずとも、そもそも映画はやめて公園や無料イベントに誘うという手も考えられます。仲良しの友達に『すまん、この日だけ俺の彼女ってことになってくれ!』と頼み込むなんて方法も考えられますし、そもそも年末の連休にはパーティーではなく友達を誘ってドライブにいってもいいし、家族で鍋パーティーとかでもいいですよね。

技術にこだわる職種であるほど意識しにくい部分

こういう考え方って、技術屋(=特定分野を深く注視するのが仕事の人)は意識しづらいでしょうって思うんですよ。
技術屋さんは、自分が専門とする技術を用いて問題を解決するのが仕事なので、常日頃から専門分野を深く注視する習慣がついてます。視点がミクロ寄りになりがちで、マクロな視点はそれこそ専門外ですよね。
しかし、問題定義や手段のズレが原因で、せっかくの技術が意味をなさないようではたまったもんじゃありません。

技術をしっかり活かして、問題等を解決できるいいものを作るためには、この問題定義と解決策のマクロな視点が必須だと思うんですよ。木を見て森を見ずの状態は避けるべきなんです。

この記事ではツリーを用いた問題定義の図解化を例に挙げましたが、他にもマインドマップやバブルを用いた考え方など、やり方はたくさんあると思います。(それこそ、ツリーで考えること自体が目的なのではなく、問題定義を考えるための手段はなにかいいか、という問題定義ですよね)
マクロ視点から問題(目的)の全体像を俯瞰して、そこから狙いをさだめて要所要所の目的達成技術に注力する…しかし、もう一度全体を俯瞰して『正しいか?ベストか?』と見直しをする習慣は大事だと思います。

Thank you for reading! 読んでくれてありがとう!