世の中の「活動」を抽象化すると

抽象化すると、楽です。うん、楽。

何が楽って、理解がしやすくなるし、「記憶」しなければならない具体的なノウハウも「知識」で覚える必要はなく、根源的な「理解」の再利用で済むようになります。

活動を「する」と決めてからの流れは、一番シンプルかつ、確実に成功するために必要な作業を抽象的な形で残すと、次のようになるでしょうか。

ＵＭＬ（Unified Modeling Language）のアクティビティ図を使ったものですが、アクティビティとは直訳で「活動」や「作業」と言う意味合いがあり、アクティビティ図は、そうした活動などを図（diagram）にしたものと言う意味です。

個人活動においても、集団活動においても、そしてそれが仕事であっても、スポーツであっても、遊びであっても、抽象化すると、すべてこの図と同じか似たようなものになります。

ならなければいけません。

当然、ソフトウェア開発におけるプロジェクト活動も同様です。教育をする際にも、新人が相手であっても、ベテランが相手であっても、まぁほとんど同じでしたね。

おそらく、これらの行動のうち１つでも欠けていれば、必ず何かしらの弊害を生みます。たとえば…

　・事前に情報を収集しなければ、
　　勝てる勝負も勝てなくなるでしょう
　・誰とも関係を持たない活動であればまだしも、
　　誰かに関係したり影響するものであれば、
　　事前に確認しておかなければ、予想外の事故につながりかねません。
　・無計画のまま行き当たりばったりで行動すれば、
　　失敗確率はグンと跳ね上がります
　・実行しなければ、成果は得られません
　・振り返りを行わないということは、経験を活かさないということです。

遊び、料理、旅行、仕事、スポーツ、etc.…何をするにしても、しっかりと成功を収めたいのであれば、すべてこのフレームワークに当てはめなければなりません。もちろん、次からも失敗したい人は、この図から大きく外れた方法を取ればよいということになります。

ですが、自分で考える癖をつけていない人は、おそらくここでこう言い訳します。

　「事前に全ての情報が集まるなんてことはない」
　「確認や承認が行われずに仕事が進むことだってある」
　「なんでも既定路線で思い通りにいくわけではない」

上記のフレームワークは、フレームワークだからこそ、細かい具体的な部分を取り除いています。これをどのように手段や手法に落とすかは、個々人あるいは組織次第となります。である以上、状況によって最適化（テーラリング）するのは当然のことです。

条件が整わなければ、整いやすいように調整しますし、整いやすく調整しても整わなければ、条件が整わなくてもいいやり方に変えます。そんな都合のいいやり方が無ければ、スケジュールで調整しますし、それすらも困難な条件であればお客さまも含め、ステークホルダー全体を巻き込みます。

"目的"や"目標"を見失わなければ、"目的"や"目標"を満たすために用意された数多くの『手段』を最適化すればいいだけです。

行動とは、常に"目的"や"目標"を達成させるために行うものですから、起こした行動自体が無駄にならないよう、安易に"目的"や"目標"を変えていいものではありません。変えるということは、行動そのもののアイデンティティを失うことになるからです。

それでも『自分で考える』ことがなかなかできない人のために、少々具体的に落とし込むと、たとえば次のようになります。

事前準備が予定通り進まないケースの場合であれば、こうなるでしょうか。たいていのプロジェクト活動では、このようになることが一般的に多いのではないかと思います。こんな感じで少しずつ日頃の経験を追記していくと、いずれ完璧なフレームワークができそうです。

ちなみに、私はこんな感じでほとんどの行動アルゴリズムは定まっていて、定めた選択肢にないものは都度検討しながら、成功も失敗もどんどん追記して、拡充していってます。だから、２度目以降はノータイムで判断が可能になるんです。１度目はどっちが失敗かなんてわからないので、ノータイムで突撃してますが。

　・お客さまの要求が定まらない（仕様が決まらない）
　・お客さまとの合意がなかなか得られない
　・他業者からの回答が返ってこない

などによって、スケジュールに影響が出ているにも関わらず、ずっと止まっているわけにはいかないため、手戻り覚悟で進捗を進めるしかないようなケースなわけですね。

みなさんのプライベートな過去の中にも

　「事前情報の収集を怠った」
　「関係者に確認を取らなかった」
　「無計画のままで始めてしまった」

によって、同じような面倒くさい事態になったことはあると思います。明らかに自分たちの責任ではなかったとしても、ギリギリまでスケジュール調整し、期限までの影響を最小限にするのは、スケジュールマネジメントをおこなうマネージャーやリーダーの責任です。

それでも、先述のようなシンプルなフローと比べると、

　「スケジュール通りの実行および管理」と
　「残課題のスケジュール管理と調整」

を並行で行わなければならない負担は、２倍３倍どころではありません。これができないと、マネージャーとしての力量は低く見られるばかりでなく、メンバーへ相当量の負担がかかり、場合によっては私生活すら乱されることにもなりかねません。

実は、マネジメントで最も大変なのは、この並行タスク管理なのです。だからこそ、事前準備をどれだけしっかりやっておいて

　・事前情報の不備・不足がないか
　・お客さまを含む利害関係者(=ステークホルダー)との合意形成が十分か
　・先の見通しがハッキリしている計画が十分に検討されているか

を重要視することには意味があるわけですね。シンプルなフローで作業を進めたいか、複雑なフローで大変な作業を進めたいか、それを決めることができるのはマネージャーだけなのです。

たとえば、新人や経験不足のみなさんは、早々にリーダーやマネージャーを任されることはないでしょう。しかし、先人（先輩や上司）たちの仕事の仕方やマネジメントの仕方は、その気になればとても間近で見ることができるはずです。

　どんな進め方をすれば、どれほど大変になるのか。
　どんなコントロールをすれば、どれほど楽になるのか。

一挙手一投足を見て、今のうちに学んでおくと良いでしょう。まずは自分の行動および活動について、こうしたコントロールができるように努力してみるといいでしょう。最初は見よう見まねでいいのです。

自分１人の仕事をマネジメントする(=セルフマネジメントと言う)だけでも、
相当の努力が必要になるはずです。

しかし、自分１人のマネジメントすらできない人間は、決して他人を含む大勢のマネジメントはできません。今のうちから先人たちのやり方を見て、少しずつでも学んでおくことはとても重要なことなのです。

おそらく新人のみなさんの多くは、

「そうは言っても、まずは実務から」
「実務で最低限のことができないと、他のことまで割いている余裕はない」

と言って、こうした課題は二の次、三の次となるでしょう。そして、そう言ったテーマがあることも忘れて、２年、３年と過ぎていくと思います。配属された先で活動することになりますが、そこで上長となられる人たちが、常にこうしたことにまで気を割いてくれているとは限りません。

自らが忘れずにタスク管理しておく必要があるのです。

そのためにも、こうした仕事のフロー（流れ）は図表化しておくと良いでしょう。そして、失敗を繰り返しながら、少しずつ図を更新、拡張していくのです。そうすれば、いつか「失敗しない（成功しかしない）」活動フローが出来上がるでしょう。

さらに具体的過ぎず、抽象化しておくと、他でも転用できるようになります。個別に一つひとつ覚える必要が無くなるのです。

モデル化／抽象化は、応用力を鍛えるうえでもとても大事な能力です。機会があれば、訓練してみると良いと思います。