体系群や開発の現場に対する、急がば回れ
（体系を理解する目的として..２）

つづきです。

体系群や開発の現場に対する、急がば回れ


　業務システム開発だけを考えても数多くの体系が存在します。
　ＩＴＩＬの分野、具体的な開発技術の分野、プロジェクトマネジメント、 ＢＡＢＯＫの分野、元技術屋がハズしがちな営業の分野（ビジネスとしての視点）、これら全体を統括することになるであろうプログラムマネジメント、どれも ＰＭＢＯＫと同等であったり、はるかに大きいボリューム、複雑さの体系が存在しています。

　このとき、プロジェクト・マネジャーとして、さらに上 位のマネジャーとして、業務システム開発全体がうまく機能することを対象に「急がば回れ」と考えたらどうなるかということです。
　前々回あたりに自衛隊での例をあげましたが「関連する全ての体系を実務者レベルで理解している」ということが理想のはずです。「そりゃ、不可能だ」「冗談じゃない」そう思うのもムリはないですが、理想はそうです。


　目指すべきです。少なくとも配下で働く人々のためにその姿勢をはっきりと見せるべきです。

より良く変えていくだけ。それが役目

　仕様策定者やプログラマ等は、特定の企業の業務や様々な言語体系をを徹底的に理解して、初めて設計やプログラミングができるわけです。現在の Ｗｅｂプログラミングでは、複数の言語体系の理解を組み合わせないと作れないようなことも沢山あります。しかもプログラマはバグ１コから責められます。

　 このあたりの全ての業務を実際に行ってきた者としては、プロジェクト・マネジャーやさらに上位のマネジメントが上記を目指して日々勉強するのは当然の事だ と思っています（だって、私もプロジェクト・マネジャーのときはそうであるように、直接的にモノをつくらないでピンハネするんですから..笑）。

　 「オレの時だってツラかったが、出世して解放(!)された。だからおまえらも同じようにツラい思いをしろ。それが勉強だ」とかいってると、「日本にはリーダーがいない」なんて言われちゃうんだろうなと思います。

　自分よりラクされるのがイヤな人は、何かがラクになっても次に必ず相応の壁があるものなんでそう考えましょう（本当にラクになったら、それは仕事として報酬がもらえなくなるんだし）。

　そして、そう言ったセコい考えはやめて、後に続く人達が、どんどん良く、ラクになって、次の課題にぶつかっちゃえるように変えて行きましょう。そうすれば、後に続く人達なりの思い出が沢山つくれます。全く同じ事で苦しんでるんじゃ、新鮮味がなくて思い出にもなりません。

　そのためには、それぞれが勉強して伝えられる事は徹底的に勉強して伝え合うという事でしょう。

なかなか伝わらなくても、繰り返し、繰り返し。