Webサイトの構造を設計するとき、多くの人は画面とそのあいだの関係（遷移、ハイパーリンク）から考えるでしょう。僕は、このやり方は正しいと思っています。画面（ページ）という概念がないWeb APIの場合でも、画面をクライアント状態に代えて、クライアント状態とその遷移から考え始めるのは良い方法です。
最終的な出力／結果から考える、ってことですね。これは処理の順番とは逆なので、入力データや処理を考えたがる人には違和感があるかもしれません。実は僕自身が「入力データや処理を考えたがる人」でして…。なので、結果から逆向きに考えることが苦手です。意図的に、「結果から考える」「出力を先に決める」と自分に言い聞かせてないと、入力と処理に引きづられます。
入力と処理から考えると、得られた結果は“欲しかったモノ”というより、“出てきたモノ”です。誰でも潜在的には“欲しいモノ”があるので、入力と処理から“出てきた結果”を見て「あんれー、なんか違うな」と思うことがあります。
もちろん、入力と処理を無視するわけにはいきませんが、はじめに“欲しいモノ”＝出力／結果を明確にして、それを得るために必要な入力や処理へと逆向きに考えていったほうがうまく考えがまとまるようです。
これは、プログラムのなかの関数を1個作るようなミクロな状況でも同じで、戻り値の型を先に決めたほうがいいですよ。多くのプログラミング言語で戻り値は1つですが、入力は引数以外の環境、それもさまざまなスコープの環境から取れたりするので、その多様性が負担になったりします。欲しい戻り値がハッキリと決まっていれば、多様な入力からの選択に指針が生まれます。
「結局最終的にはどうなるの？」というイメージを持つことが大事、みたい。
