はじめに
ソフトウェアエンジニアであるOz Novaさんは2017年、自身のblogに”You Are Not Google”というタイトルの記事を投稿した。 彼はこの記事でエンジニアリングにおける「カーゴ・カルト」、つまりGAFAMに代表される成功したBig Techが採用しているような”イケてる”技術を使うことで自分たちも大きな成功を掴めるはずだ、という迷妄に対し警句を述べているのである。
本稿ではNovaさんが上掲の記事中で示した問題解決の指針”UNPHAT”を見ていくとともに、UNPHATの核心にあたると著者が考える、問題を構造的把握する大切さについて記す。
What is UNPHAT?
UNPHATとは、以下の6項目からなるチェックリストだ。
- Don’t even start considering solutions until you Understand the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
- eNumerate multiple candidate solutions. Don’t just start prodding at your favorite!
- Consider a candidate solution, then read the Paper if there is one.
- Determine the Historical context in which the candidate solution was designed or developed.
- Weigh Advantages against disadvantages. Determine what was de-prioritized to achieve what was prioritized.
- Think! Soberly and humbly ponder how well this solution fits your problem. What fact would need to be different for you to change your mind? For instance, how much smaller would the data need to be before you’d elect not to use Hadoop?
引用元：https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
筆者なりに和訳してみよう。
- 問題を理解するまでは解決策の検討を始めない。私たちのゴールとはたいていの場合、問題の範囲内で問題を「解決」することであって、それは解決策の範囲内においてではない。
- 候補となる解決策をいくつか挙げよう。気に入った解決策だけを追ってはいけない。
- 解決策を検討するにあたり、文献があれば読もう。
- 解決策が設計、開発された歴史的背景を知ろう。
- 解決策の長所と短所を比較しよう。優先されたことと引き換えに、何が優先されなかったかを知ろう。
- 考えよう！ 私たちの抱える問題に対し、解決策がどれだけ適しているか冷静に深慮を巡らそう。考えを変えるためにはどんな事実が必要だろうか？ たとえば、Hadoopを使わないためには、データをどれだけ小さくすれば良いだろう？
これらのチェックリストは、端的に言えば「”私たちの問題”を深く理解した上で、最良の解決策を見つけるために数多の技術を冷静に評価せよ」というステートメントである。そして、これ自体は斬新なメッセージではない。
にもかかわらず、NovaさんがUNPHATを提唱するのは、我々がこのステートメントを実行できず、アーキテクチャ検討や実装の途上において容易に思考停止してしまうからだ。
問題を構造化しよう
業務上直面する問題には、解決が容易な問題と難問とが混濁している。そして、難問とは得てして「なんもわからん」状態で現前する。この状態の問題を理解するには、問題を構造的に把握しなければならない。この時点必要なのは解決策ではない。事実の収集と、有り合わせの事実から得られる”その時点で最良の”仮説だ。
例を挙げよう。Novaさんの記事では、直面する問題と深く向き合わずにtoo muchな解決策を選んでしまったケースとして、分散データストリーミング基盤であるApache Kafkaを中心にシステム構築したとある企業（仮にA社と呼ぶ）が引き合いに出されている。Kafkaは元々LinkedInが多様な種類の大規模データをスケーラブルかつ高スループットで処理するために開発した技術基盤だ。しかしA社のビジネスにとって、システムは1日に数十件、多くて数百件のトランザクションを処理するだけで十分だった。はたしてA社の技術選定は正しかったのだろうか。
A社は「ビジネスが要請するデータ処理を実現したい」という問題に対し、可能な限り事実を集めた上で仮説を立て、仮説を満たす解決策を選定できなかったのだろう。A社はLinkedInではないため、「ビジネスが要請するデータ処理を実現したい」という問題の実質も異なる。どう異なるかが「なんもわからん」場合、そのままでは五里霧中で先へ進めない。この状況はUNPHATのUに該当する。先へ進むため、また進んだ先が正しいかどうかを評価するためには、軸となる仮説を事実から導く必要がある。
問題と十分に向き合わず、判断軸（仮説）を立てないまま、目についた”イケてそう”な解決策に飛びついてはいけない。仮説がなければ、UNPHATのTに該当する、問題と解決策との比較検討作業が十分に行えないはずだ。
終わりに
Novaさんは記事を締めるにあたって、"How to Solve It"の著者、George Pólyaの言葉を引いている。
「It is foolish to answer a question that you do not understand. It is sad to work for an end that you do not desire.（理解していない問題に答えるのは愚かなことだ。望まない結末のために働くのは悲しいことだ。）」
問題を理解可能にしよう。そのために構造化する努力を惜しんではならない。つねに、仮説という”望まれた結末”を描いて働きたいものである。
