「ライト、ついてますか―問題発見の人間学」理想と現実と問題解決の副作用
一人アドベントカレンダー2日目です
問題とは何かから、前提のリフレーミング、別の視点で見方まで色々記されているこの本だが、一番面白いのはやはり語り口調だろう。他の書籍だと難しく書かれているリフレーミングや視点の変え方の方法を、面白みのある具体例で表現している。あまりに面白み(現実味のなさ)が強いため、読み終わった後に自分の身に起きたこと・起きていることで考えてみるとしっくりくる作りになっている。
個人的に好きだなーと感じたところをつまんで書いていきます。
問題とはなにか
本書では問題を以下のように定義している。
問題とは、望まれた事柄と認識された事柄の間の相違である ~ 3章より
これの良いところは、問題を「望まれた事柄」と「認識された事柄」に分解できることにある。「望まれた事柄」とは何なのか、本当に望んでいるのは何なのかと、分解されていることで事柄を多角的にみることがしやすくなる。
また、「認識された事柄」も分解されることで、それがどのように問題なのか・そもそも問題なのかということを考えることができるようになる。
問題について考える
私はそれを本当に解きたいか？ ~ 20章より
問題について考える時、最初に考えるべき問いが上記だ。
あなたが本当にそれを問題に思えるか・腹おちして考えることができるかだ。例えば発生頻度が1年に1回の問題を解きたいと思うだろうか、その時にとても面倒臭い対応を迫られるならば解きたいと思うだろう。
また、その問題が顧客に対して利益が生じるものであるならば、自分が顧客になった時その問題を解決されたいかを考えるのも重要になる。様々な視点から「その問題に解く価値があるか」を考えてから問題に向き合わなければ不毛な解答を作るだけになってしまう。
問題は誰の問題か・またはどこからきたのか ~ 4&5部
問題が発生する時、様々な人がそこにはいる。問題を生んでいる人・問題の被害を受けている人・問題を見逃している人・問題に気づいていない人などだ。
問題を解こうとするときは、それらの人々に対して「私たちの問題だ」と実際に問題を味わい・皆で問題を解くといい。
誰かの問題だと棚上げすれば不満が出るのは当然だ、それを私たちの問題として全員で解決していく。この辺りは現代の開発の「個人ではなく、システムやフローの問題にする」という全体最適に通じるところだろう。
解決が問題を生む
すべての解答は次の問題の出所 ~ 7章より
エンジニアならばとても実感することだろう。
もし「これから1ヶ月一切のバグを出さないでくれ」と言われたらどうするだろう。「でしたら新機能のリリースを1ヶ月やめます」というだろう。私もそうする。
問題を解決するとき、その副作用がどのように生じるかを認識することは非常に重要である。
もし新しい機能を追加したとき、あなたはどのような副作用が思いつくだろう？
- 新しい機能がバグを内包しているかもしれない
- 新しい機能によって、画面の動線がわかりづらくなるかもしれない
- 機能が増え、新しいユーザーにとっては情報がわかりづらいかもしれない
- 機能が増えたことで、コードの依存関係が強くなっているかもしれない
上げ出せばもっと出てくる。この時、重要になるのは「解決策と付き合わなければならない人間に合う解決策」にすることだ。どんな解決策であれ、割を食うのは、設計者より利用者なのだ。
問題解決の沼にどっぷり浸かった人同士で話し合うより、問題を知らない人・実際に問題を体験している人に聞く方が良い解決策に巡り合えるだろう。
