右、左のいずれの道に進むか、二者択一を迫られる場面では、各々を選択した際の『メリット』『デ・メリット』を明確にした上で、どちらに進むべきであるかを決定する。至極当たり前の行為である。しかしながら、目標を達成するためのプロセスの中では、この分岐点は、とても厄介で、時には、最終的な目標や目的を見失うことさえある。

私の場合、目標を達成するための大まかなプロセスを、『出発点（現状把握）』→『通過点』『分岐点』→『着地点（目標・目的）』と、定義している。 上記のプロセスを作る中で、最初に決めるのは、当然、『着地点』である。これは、理念であったり、数字であったり、その時々によって違う。多少、余談になるが、私の場合、『着地点』は、遠い将来どうなっていたいか？が、起点となっている。だから、短期のプロセス作りにおいては、例えば、一年後の『着地点』は、『通過点』とも言い換えられる。 基、次に、『出発点』は、現状把握を行う。そして最後に、『通過点』を決めて行く。『通過点』は、経験や知識を基にした、期限や数値の設定が中心。と、ここまでは、誰でもやっていることだ。『分岐点』は、なかなか、想定し辛く手を出しにくいものである。 超能力がある人は別であるが、将来、自分にどんな『分岐点』が訪れるかは、誰にも分からない。だからと言って、『分岐点』を想定しないのは、論外である。では、どうやって、『分岐点』を見つけ出すのか？ それを可能にするのは、『情報』であると思う。ここでは、『知識』や『経験』も、全て総称して『情報』と呼ぶことにする。この『情報』が、『分岐点』を炙り出してくれる。『分岐点』は、『情報』の集合体でもある。しかし、『情報』だけでは、『分岐点』とは言えない。『分岐点』を明確にするためには、一つ一つの情報に対して、《調査×検討×取捨選択》を行う。更に『分岐点』は、時に深度を伴ったりする。深度とは、『分岐点』の先に『分岐点』があったりすること。これを解決する作業は、時間のかかる、骨が折れる作業である。それが解決したら、『分岐点』は、もう『分岐点』ではない。『通過点』と化しているのである。表現が下手で申し訳ないが、プロセス作りでの『分岐点』は、結局、『通過点』の単なる過程なのかも知れない。 こうやって、目標を達成するためのプロセス作り（＝グランドデザイン）が、出来上がることになる。そして、それを実行をして行くことになる。 プロセスを実行している中でも、必ずと言って良いほど『分岐点』はやって来る。『情報』の質や量で、出現する頻度は様々である。これには、一つ一つ対処して解決を図るしかない。対処方法は、前述と同じ。 この突然の『分岐点』の出現回数が多いと、期限内に『着地点』に到達出来る可能性は低くなる。判断ミスも怖い。深度が増すほど、『着地点』が遠く霞んで行くのに焦りを感じながら、事に当たる。同時に、『着地点』を見つめ直す作業を行う。これは、『分岐点』の解決策が、妥当かどうか（＝目標＆目的を前提として進んでいるか）をチェックするためにとても重要な作業である。原点回帰と言った方がわかりやすいかも知れない。それをやることで、最悪、着地点の変更を強いられることになるかも知れない。着地点の変更は、プロセス作りの失敗を意味する。それは、知識や経験を含む情報量が不足したとも言えるだろう。まぁ、失敗は、大概の場合、リカバリーは効くし、今後の良い経験にもなる。 プロセス作りに失敗しないように、おっと、失礼･･･。本末転倒であった。目標を成就するためには、プロセス作りは、最も重要な作業であるので、十分な時間を使って、実行中に訪れる、突然の『分岐点』を減らすように努力しなければならない。