「Divide and Conquer」と「Begin with the End in Mind」

後出しですが、L5 Advent Calendarの6日目の記事です。

初日に書いて、どこかの空きでと思っていたら、予想以上に参加してくれる人が増えて、書きたかったことが書けなくなったので、6日目にねじ込みました。

さて、書きたかったことは、僕なりの仕事のやり方のコツです。
コツといってもとても抽象的な話になりますが、大事にしている（より正確に言えば、結果として大事にした選択をしている）ことは、「Divide and Conquer」と「Begin with the End in Mind」ということです。

Divide and Conquer

日本語では、「分割統治」と翻訳されることが多いと思います。

コンピュータ科学などでは教科書に載っているような一般的な話だと思いますが、wikipediaでは次のように説明されています。

分割統治法（ぶんかつとうちほう、英語: divide and conquer algorithm、D&C）は、そのままでは解決できない問題を小さな問題に分割することで、最終的に問題を解決しようとする考え方。また、その方法やアルゴリズム。
クイックソートやマージソートに代表されるようなソートでよく使われている。また、構造化プログラミングでも、この考え方に基づいている。
（Wikipediaより)

アルゴリズムの手法の１つとして説明されていますが、解きたい問題がそのままでは解決方法が複雑になりすぎる場合に、その問題をより小さな問題に分割し、それぞれを解決し組み合わせることで、本来の問題の解決策を導くという、ごく一般的に利用できるテクニックです。

ある種、万能な方法とも言えるのですが、利用するための条件が１つあります。

それは、 問題の分割を適切にできる ことが必須になります。

問題の分割が難しい場合

当たり前ですが、そもそも分割できないと小問題が何かすら分かりませんし、強引に問題を小問題に分割したとしても、その場合は小問題が解決したとしても、本来の問題が解決しません。

分割ができない場合は大きく次の３つがあると思います。

論理的思考が苦手

論理的に正しく分割しないと、小問題の解決が本来の問題の解決につながりません。

小問題が多すぎる

多すぎる小問題は、その全体像を見失わせます。
この場合は、適度な大きさの問題を間に作成し、幾層かに階層的に問題を分割することで解決できると思います。

そもそも問題が複雑すぎる

スキルではなく、問題が複雑なために、どう分割すると良いかが不明なので、この場合は、一筋縄ではいきません。

最初の2つについては、単なるスキルの問題です。センスがいい人であれば、すぐにできるようになると思いますし、苦手な人でも上司なり、先輩なりできる人に相談すれば解決するかと思います。
問題は、3つ目です。

問題が複雑過ぎる場合の対処方

これは僕自身の経験則的なところですが、主に2つの方針をとります。

情報を集める

問題が複雑に見えるということは、言い換えれば、現在の視点で解決することは難しいと言えます。
その場合は、問題について関連する情報を集めて、違う視点からのアプローチを検討します。

限定的に解決を目指す

これは情報の集め方の1つであるとも思いますが、問題をある解決しやすい条件下だけに限定し、その問題に取り組ます。これにより、その条件下での解にたどり着くことができれば、元の問題についても何かの知見を得て、視点を変えるきっかけになるかもしれません。
また、場合によっては、業務という観点で言えば、その条件下で解決すれば十分というケースもあります。それなのに、オーバースペックな問題に取り組む必要があるかは検討すべきでしょう。

Begin with the End in Mind

この言葉は、THE 7 HABITS OF HIGHLY EFFECTIVE PEOPLE(７つの習慣)で言われている、2番目の習慣です。日本語だと、「終わりを思い描くことから始める」、「目的を持って始める」という訳され方をします。

僕はこの習慣はとても大事なことだと思っています。
仕事をするとどうしても、What（何を？）、How（どうやって？）というプロセスに思考が行きがちです。
ですが、その裏には、必ず、Why（何のために？）という目的とか、意思があります。
プロセスは実施する時、場所、人によって最適解は異なり、変えていくべきですが、目的や意思はぶれると面倒です。

とある人が自分は社長だから朝令暮改は当たり前だということを言っていました。
この話を聞いて、納得する部分ととても嫌な部分と両方を感じました。多分、その答えはここなんだと思います。

プロセスは朝令暮改でも構わないと思います。むしろ、効率のためであれば、そうあるべきでしょう。
でも、目的や意思が朝令暮改の組織は組織として成立しないと思います。
（念のために言いますが「変えるべきではない」と言っている訳ではないです。）

ちょっと開発の話になりますが、ストーリーワークショップ、ATDD、TDDというのは、粒度の差はありますが、基本的にはBegin with the End in Mindを後押しする仕組み何だと思います。

特に熟慮した訳ではないですが、数個のクラスの設計をして説明をした際に、新人の人から、なぜその発想に到れるのか教えてもらえますか？という趣旨の質問をされました。

ぱっと思いついた答えは、それが自然だから、とか、それが美しいから、だったのでした。
では、なぜ、自然なのか、なぜ、美しいのかまで考えてみると、結局のところ、

これらのクラスが提供すべき機能があり、それを使う側から見て使いやすく（この定義も必要ですが、ここでは割愛）、それを充足する最小限のものというのが、少なくとも、どうも自然とか、美しいという言葉の定義に近い気がしています。

言い換えるならば、作成するクラスのEnd（どんな機能を誰にどんな風に提供するか？）を意識するところが大前提なのだと思います。

今回は小さなクラス群だったので、これを無意識にやっていたのですが、これを意識的にやる設計作業がTDDと言えるかと思います。

最後に

僕なりの重要視していることを2つのキーワードでまとめてみましたが、いかがでしたでしょうか？

7日目は、同じくバックデートして土方さんが埋めてくれるはずです。
よろしくお願いします。