私にとって大変気が重い話しですが、今日のソフトウェア・エンジニア（以下ＳＥと呼ぶ）にかかる構造的な問題について触れることにします。
わが国のＳＥのレベルは、一部の特殊な分野を除いて、その技術水準の低さが問題になって久しいのですが、一向に改善される気配が見られません。それどころか平成に入っての開発期間の短縮という課題に対する対応のまずさから、多くのソフトウェア開発組織は疲弊しているものと思われます。
専業のソフトウェア開発会社だけでなく、製造業のソフトウェア開発部門も、短くなった製品サイクルやそれに関連しての開発期間の短縮などの市場の要請にも、そろそろ対応仕切れなくなっているのではないかと思われます。
それはプロセスを変えずに今まで通りのやり方で対応しようとしてきたことに大きな原因があると考えています。その結果、逆に品質を悪化させてしまう可能性もあり、そうなると、その後始末などで益々事態を悪くしてしまいます。完全な悪循環です。
このような状況に対して早急に手を打たなければ、ソフトウェア開発組織にとって大きな障害となることが予想されます。しかもこの問題は特定の企業の問題ではなく、恐らく日本中のかなりの企業、或いは殆どのソフトウェア開発部門に共通した問題と思われます。
このことを説明するために、今日のＳＥの背景から触れて見たいとおもいます。
今から１５年余り前に、通産省の旗振りから“情報処理技術者”の大量採用が始まりました。これは、コンピュータの能力が向上したことでソフトウェアを必要とする分野が広がり、コンピュータの言語もアセンブラから高級言語へとシフトし、開発の環境も良くなったこと等が背景にあるのですが、この他にソフト産業の立ち上がりを支援する意味も大きく、その結果としてもたらされたものは、若い情報処理技術者の現場への大量投入であり、それに反しての要員教育の立ち遅れでした。
それまでソフトウェアの分野に足を踏み入れるには、就業時間後に半年ぐらい専門学校に通うのが普通でした。社内にソフトウェアの分かる人がいない以上、その方法しかなかったのです。それだけに彼等には初めから備えがあり、多くの人は「自主・自活」の考えも持っていました。そのような人でなければ、仕事をしながらの半年間の通学に耐えられないのです。
それまでの企業内に於ける要員教育は、そのような人達が中心となって、どちらかというとマンツーマンで実作業を通じて訓練してきたのですが、大量採用によってそれまでのやり方は維持できなくなり、チームの中に組み入れる形が多くなりました。一人のリーダーが３人もの新人を預かることは出来ません。その結果、彼等新人は「仕事のスタイル」を継承することが出来なくなったのです。
そのチームは別に人が足りなかった訳ではなく、彼等新人は、現場とは別の「採用計画」に従って採用され、そのチームに配属されたのです。そこで彼等新人に対して為されたことは、既に居る人達の持ち分を削って分け与えることでした。そして彼等に対して“チームに慣れる”よう求めたのです。所謂、「集団指導体制」の下で指導されたのですが、この方法は、通常はその集団の下辺のレベルに合わされてしまいます。この結果、新人だけでなく彼等の先輩も、そのレパートリーを狭めてしまったのです。
こうした状態が５年、１０年と続いた結果、ソフトウェアの開発現場には「ＳＥ」と名のつくエンジニア（？）が溢れだしたのですが、彼等一人ひとりの守備範囲は一向に広がることなく、ソフト開発とは人手の掛かるものという概念を定着させるのに役立ったのでした。右肩上がりの経済も、そして「ソフトはハードよりコストが掛かる」という通説も、この神話の定着に一役買ったのです。
実際、そこで行われている作業は、大変な作業であり、彼等は必死になって目の前の仕事をこなしているのです。尤もそのように必死になっている割には、彼等は「部分」しか分担していないため、システム全体の仕掛けなどを知る機会は殆どありません。もちろん自らの意思があれば、それを知ることも可能だったのですが、非効率な作業で自分の分担をこなしながら、そこまで手を広げることは無理だったでしょう。
バブル景気の終焉によって、主に金融会社やコンピュータメーカー等に派遣されていたＳＥの中には、プロジェクトの中止や凍結によって戻されただけでなく、「要員」或いは「ソフトウェア技術者」としての職を失った人が数多くいました。残念ながら彼等の中には、大学を出て１０年経っても、システムを設計することが出来ない人が少なくなかったのです。１０年間、彼等はただ誰かが書いた仕様書に従ってソースコードに変換し、その動作を確認するためのテストをしてきただけなのです。彼等には「システムの全体」が見えませんし、おそらく全体を見る力を殆ど無くしているでしょう。システムを設計するには単なる経験だけでなく、「モデル化」「抽象化」の能力が求められるのですが、それを身に付ける機会は彼等にはなかった。
彼等はソフトウェアの開発工程の１つの「部分」、それもインプリメント作業を中心に１０年間携わってきたのです。
このことは、ソフト会社に所属するＳＥだけの問題ではありません。いわゆるメーカーに属するＳＥにも似た状況を見ることが出来ます。
この世界では今でも「３５歳定年説」というのが生きて？います。この言葉はＥＤＰの時代から言われてきた言葉です。たしかに初期の頃は管理者が不足していたために、３５歳位でプレーイング・マネージャーの役を兼ねる必要がありました。またアセンブラが中心で開発ツールも貧弱なため、ソフトウェアの開発作業そのものも過酷で、１０年も作業すれば、くたびれてしまうという事情もありました。「３５歳定年」はこのような事情を背景に生まれたものです。
日本にＳＥという職業が誕生して約３０年、今や鉛筆やテンプレートを使って作業している人は殆どいませんし、高性能な端末も１人に１台以上当てられています。１０Ｋ行のソースをコンパイルするにもコーヒーブレークを必要としません。このように今日では開発環境も大きく変化し、職場には大勢のＳＥが居るようになったにも拘わらず、「３５歳定年」という言葉は依然として生き続けているのです。
私には、環境がこれ程変化しているにも関わらず、ＳＥ一人当りの生産性は以前と比べてそれほど改善されているようには見えません。昔は、開発環境が貧弱であったため、作業そのものは非常に慎重に行われましたが、今は環境が整った分だけ逆に作業は“軽率”で、後戻りの作業（リワーク）が多すぎるのです。
今日使われている「３５歳定年」と言うのは、３５歳で現役のＳＥをリタイアするという意味で使われています。言い替えれば３５歳で現役をリタイアせざるを得ない程、当事者にとって現実のソフトウェア開発作業は相変わらず過酷であるということなのです。
この過酷さには、変化の過激さも含まれます。５年も経てばコンピュータの性能は飛躍的に向上し、これに呼応してソフトウェアの活躍する範囲は拡大し、複雑さも増していきます。また、ソフトウェアの開発方法やモデリングの方法も新しいのが提案されてきます。
そのような現実の中で、ソフトウェアの開発作業そのものが苦痛以外の何者でもないなら、そしてそこから仕事の喜びも完成に伴う感激も得られないのなら、皮肉なことですが、そのような人にとって「３５歳定年」は救いなのかもしれません。
今日、「３５歳定年」の背景にあるのは、明らかに「継続教育」の不足であり、さらに言えば、その根底にあるのは職業に対する意識の欠如ということになるでしょうか。もっとも、彼の周囲に、自分と同じレベルの人が一人もいなかったなら、彼も必死になって勉強したのでしょうが、残念ながら、周囲には自分とさほど変わらない（と思われる）人達が、同じ様な行動をしているのです。そして何となく毎日を過ごしているのです。
１０数年前と比べて、コンピュータ・サイエンスやソフトウェア・エンジニリングに関する書籍がこれだけ多く出版されているにも関わらず、それらの書籍を貪り読んでいるＳＥは多くありません。絶対数としてはそれなりに居るのでしょうが、ＳＥ全体に占める割合では逆に減っていると思われます。それを裏付けるかの様に、書店の棚には実用書ばかりが並んでいます。
『典型的なコンピュータプロフェッショナルは、２５歳で職について７０歳まで働き、４５年間就労することになる。（中略）退職時には基礎知識の６２％、抽象化の知識の２０％、実用知識の３％が有効であるに過ぎない。勤続の中間点では、それらの数字はそれぞれ８１％、４９％、１６％である。』これはＡＣＭ（The
Association for Computing Machinery）から報告された数字で、アメリカの大学に於けるコンピュータサイエンスのカリキュラムで基礎知識を重視する根拠となっています。特にこの“抽象化の知識”と言うものは、昨今の構造化分析やオブジェクト指向分析などの分析／モデリングに欠くことのできない知識・概念です。
現実にこのカリキュラムを受けて、４５年間コンピュータプロフェッショナルとして就労した人は現時点では殆どいないはずですが、それでも学生時代に習得した基礎知識の８１％が、そして抽象化の知識の４９％が、４０歳を過ぎた時点でも役に立つということは、それだけコンピュータの基礎知識や問題の捉え方がしっかりと身についているということでしょう。このような人達にとって「３５歳定年」は、何の意味も持たないことは言うまでもありません。実際に欧米では５０歳台のプロフェッショナルＳＥは大勢居ます。彼等には馬力はないかも知れないが、それを補って余るほどの「経験」という大きな武器があります。そして何よりも彼等はくたびれていないのです。
このことから、日本に於いて未だに「３５歳定年説」がまかり通っているのは、基礎知識や抽象化の知識を殆ど身につけていないからと言うことができます。実際問題として、情報処理関係の学部／学科を卒業してきた人でも、コンピュータの基礎知識を殆ど身に付けていませんし、ましてや抽象化の知識などは皆無に等しいでしょう。その上、「個性」を錯覚してか「真似る」ことを避けるあまり、人（先輩）の書いたものを見ないために、自分とは異なった発想や技術が殆ど身に付かず、まさに徒手空拳でプログラムと格闘するわけですから、１０年もやればくたびれ果ててしまうのは当然でしょう。
カール・ヒルティの「幸福論」（岩波文庫）の冒頭に、つぎのような文章があります。
『仕事の上手な仕方は、あらゆる技術のなかで最も大切な技術である。というのは、この技術を一度正しく会得すれば、その他の一切の知的活動がきわめて容易になるからである。それなのに、正しい仕事の仕方を会得した人は、比較的少ないものだ』
この国の大きな問題は、ソフトウェア開発に必要な技術や技法を、大学などの場で十分身に付けることなく実際の作業に入ってしまうことです。基礎知識や抽象化のノウハウを身に付けておけば良いことは分かっていても、仕事をしながらとなると、なかなか思い通りには行きません。また、周りの人たちも同じような状態にいることで、何となく安心してしまうところもあって、結果として、何時までも身に付けることが出来ないまま、力仕事でかわしてきたのです。
したがって、この問題をクリアするためには、先ず、仕事が上手くやれることです。とにかく、「今」所有している“技法”だけで、上手くやれるようにならなければ、新しいことを勉強する時間は手に入りません。
残念ながら現実には、この「仕事の仕方」は余りにも軽視されています。それよりもオブジェクト指向やＲＡＤやプロトタイピング手法といった、華やかな看板に目がいってしまい勝ちで、管理者もそれを手に入れれば仕事が上手く捗るのではないかと錯覚してしまうのです。
プロトタイピングの進め方を教わってきても、実際にそれに基づいて仕事を進める段に入ったときは、「仕事の仕方」の問題となるのです。この問題は、Ｗ．ハンフリーのプロセス成熟度の研究で既に答えが出ています。つまり、レベル１のプロセスでは、そのような手法を習ってきても、上手く使えないことが指摘されているのです。私のこれまでのコンサルティングの経験からもそのことは断言できるところです。レベル１のプロセス（簡単に言えば、約束できないレベル）で、プロトタイピングを使いこなしている組織はないと思います。
先ず「仕事の仕方」があって、その上で手法や技法が活きてくるのです。
また、仕事に疲弊しないためにも、この「仕事の仕方」が重要になってきます。この「技術」えお手に入れていない人たち程、「３５歳定年」は深刻なものとなっている可能性が高いと言わざるを得ません。
３５歳ということは、実質的に１０年程度しか開発に従事していないことになります。その間彼等は、これまで述べてきた状況を考えると、決して効率の良い作業をしてきたとは考えにくいのですが、多くのＳＥ達は３５歳を潮時と考えて、第一線から身を引き、管理的（？）な仕事に入っていくのです。丁度一つのエスカレータの終わりがそこにあるかのように、次々とそこで降りてしまうのです。確かに、彼等の先輩もそうしてきたのであり、彼等としては当然、そうするものと思って、今日まで過ごしてきたのかも知れません。しかしながら、彼らの先輩の時とは、時代が変わっているにもかかわらず、一つのイメージを抱いてきた可能性もあります。
この場合、必ずしも自分の意思で第一線から身を引くことを選んでいないのかも知れません。組織の中の一つの役割として、或いは人事制度上そのような役が回ってくるという状況も考えられますが、それでも現実にはそのことに強く抵抗する姿を見ることは稀です。管理的な仕事を自ら望んではいなくても、それ以上に元のＳＥの仕事に対する執着があるわけでもないし、寧ろ、これでソースリストとの戦いから“解放”されるという思いの方が強いのかも知れません。
一方、管理的な仕事を自ら選んではいないと言う意味は、そのような仕事に対する備えがないからでもあるのです。つまりこの段階で、彼等は自分の意思とは関係なく、もはやコンピュータ・プロフェッショナルとして、ソフトウェアの開発現場をリードし続けるだけの明確なバックボーンを失いかけているとすれば、そのような能力が直接問われない管理的な仕事にシフトせざるを得ないことも宜なるかなです。
でもそれは悲しいことであり、当人と組織の双方にとって不幸なことです。ソフトウェアの管理職は、容易に勤まるものではありません。基本的にはハードウェアの管理も同じなのですが、ハードに比べて、遥かに技術や技法の変動の激しい分野であり、１０年前に自分が体験し身につけてきた開発手法だけでは通用しなくなっていることもあるのです。このため、たとえ現役を退いたとしても、別の立場でより良い開発手法を求め、判断しなければなりませんし、これができるためには、コンピュータに関する基礎知識や抽象化の知識が必要になります。３０歳半ばにしてこれらの知識・技能の不足から、管理的な仕事にシフトせざるを得ない状況では、とてもこの様な役割をこなせない可能性があるのです。２１世紀の管理職をこなすためにも、手法の良否の「判断」ができる程度には、抽象化の知識や「仕事の仕方」などを手に入れておく必要があるでしょう。
先のＡＣＭのレポートでも、就業半ばにして管理職に転ずることにたいして「一部の人はうまくいくが、大多数の人にとっては、そううまく行かないこと明らかである。なぜなら、管理に携わる職が十分にあるわけではなく、また多くのコンピュータプロフェッショナルは、いずれにしろ管理者には不向きである」と言っています。卒業して２０数年経た後でも基礎知識や抽象化の知識の半分は役に立つという、あのＡＣＭの強力なカリキュラムを背景にしていても、安易に管理職に転ずることに警告を発しているのです。それよりも「継続教育」を実施して、コンピュータ・プロフェッショナルであり続けることを勧めているのです。
今日の「ミドルの受難」が、固定費の問題、或いは生産性や作業効率の低さにも起因しているとすれば、今日のソフトウェア開発現場で多くの管理的業務に携わっている、或いは携わろうとしているＳＥの人達も、その生産性、或いは作業効率を問われる時が来る可能性があります。
ソフトウェア開発部門だけが「効率」やコストを無視してもよいという道理は、今や何処を探しても存在しません。基礎知識や抽象化の知識を備えた人が現われたり、開発作業に方法論が採用され、実施されると、中間の「作業指示」は必要なくなります。そのような作業手順は方法論自身に含まれているのですから。
元より今日のように、情報処理機器の性能が飛躍的に向上し、ローカルネットワークやグループウェアが発達した状態で、これまでの様なピラミッド型の多段階管理層は、その存在意義を既に失っています。指示の伝達や報告などは、中間に人を介さなくても可能となったからです。
１０年前にＧＥで大規模な中間層の整理を実施しましたが、これは、実際に別の中堅企業で５層の管理者層の中間の３層を抜いても、企業の運営や業務の遂行に何ら悪影響を及ぼさないという、レポートを受けて実施されたものです。情報技術がそれを可能にしたのです。
これまで述べてきたように、コンピュータに関する基礎知識が十分でなく、抽象化の知識も殆ど持ち合わせていない、さらにはプロジェクト・マネージングも不十分という状況では、コンピュータプロフェッショナルとしても、また、ソフトウェア部門の管理者としても不十分なのです。このままでは、いずれソフトウェア開発部門において、彼等の存在が問題になってくることは容易に予想されることです。そしてそのような事態は、今回のミドルに対するより早く、彼等が４０歳位になった辺りから問題になる可能性があります。その理由は、彼等が「３５歳定年」で管理的業務に就くにしては、守備範囲が狭く、必要な知識や技能を欠いている可能性があるからです。
その他、管理者にとって重要な「人」の問題も、多くのＳＥはこれが苦手です。彼等はＳＥとして仕事をしていた間に、外部の人と接する機会が殆どなく、たとえあったとしても、外注先の営業担当かＳＥが殆どで、そこでは立場上、初めから優位に立っています。
また一般に彼等ＳＥにはＪＯＢローテーションが適用されません。それは職務の性格上止むを得ないことではあるのですが、その結果としてコンピュータやソフトウェア以外のことについては、殆ど意見を持つことが出来ない状態になっているＳＥが少なくありません。
この様なことからで「３５歳」で“何となく”エスカレータを降りたＳＥに、そのままではこれからのソフト部門の管理者が勤まらない危険があります。たとえかってそこにいたソフト開発部門であるといっても、管理的業務である限り、コンピュータやソフトウェアの知識だけでは勤まりません。「管理」である以上、物事を「決定」しなくてなならず、それには「見識」が必要であって、知識だけでは役にたちません
これからの会社が「効率」を求めて動くのは当然のことです。生産効率、開発効率、作業効率などの面で、適正な効率を発揮できないとすれば、その会社は存続を危うくすることになります。
また１０年後に「年功賃金」も「終身雇用」も今のまま存続し続けている可能性は小さく、その上、ソフトウェアの開発部門だけが「聖域」であり続けられるとは思えません。
それだからこそ、実も心も疲弊させてしまうことなく、効率よくソフトウェアを開発する方法（術）を身に付けていなければならないのです。
このように今日のソフトウェアの開発部門に潜む問題は、何も対策を講じられなければ、殆ど確実にここで指摘するような状態になると思われます。それは彼等ＳＥにとって死活問題となるだけでなく、企業も大きな負担を背負うことになりますし、社会問題となる可能性すら秘めています。
今、直ちに企業或いは開発組織が採るべき行動として、今後起こりうる事態を見極めた上で、
１）この現実を認識すること
２）その上で、企業或いは開発組織が、これから向かう方向を知らしめること
３）そしてＳＥやマネージャーの再教育に取りかかること
です。
これ以外にも、人事制度に関わる部分は事前に対応策が必要でしょう。実際問題として、昇進と昇給がセットになっている今の人事制度は、明らかにこの部門には適さないのです。
また、ここで“方向を示す”と言うことは、そこで作業する人（管理的業務を受け持つ人も含めて）の基準を設けるということでもあります。したがって、「継続教育」を実施する中で、既に管理的業務に就いている人に対して、一定の猶予期間を与え、その間に現場に復帰するか、本格的に管理職として踏み出すかを決める必要があります。
しかしながらこの様なアナウンスが為されても、まだ事態の緊急性を信じることの出来ないＳＥも数多く居ると思われます。彼等の頭には、“これまで何度となく「標準化」だとか「改善」だとかいって騒いでいたが、しばらくすれば元に戻ったではないか”、という先入主があって、今回もそれと同列に考えてしまうことでしょう。
また「皆で渡れば怖くない」という意識も作用しているかもしれません。元来、人は保守的な生き物で「改善」には消極的なものです。特に日本のように「減点主義」で「結果平等」の考え方が広まっている社会では、突出することは危険であると思われる状況を考えると、個人の努力に任せるのではなく、組織（企業）として「結果平等」を打ち壊し、「機会平等」を全面に押し出して、突出する人達を迎え入れる姿勢を示さなければなりません。そうでなければこの分野で明日の組織は作れないでしょう。
またこれからは、人が居るから仕事を与える、という行動も改めなければならないでしょう。この世界は、もはや誰でも出来る仕事ではなくなったのです。“人が居るから仕事を与える”と言う姿勢こそが、今日のようにＳＥの守備範囲を狭め、安直に管理的業務に追いやった元凶の一つなのです。少なくともソフトウェアの世界では、余計な人は参加しない方が生産性も向上するし、品質も維持できることははっきりしているのです。
当然、この様な施策にたいして「職場のモラールが低下する」という声が上がることが予想されますが、そこで論じられる「職場のモラール」とは「結果平等」の菌糸の上に伸びたキノコの様なもので、得体のしれない怪物という訳ではありません。もはや「結果平等」では、企業は立ち行かないことは疑う余地はありません。但し、手順を間違えると余計な胞子を撒き散らしてしまう危険はあります。各自が方向転換を果たすには１〜２年の期間を要するでしょうし、向こう岸に渡す船も小さめにして、何度か往復する必要もあるでしょう。
何れにしろ、今何も策を講じなければ、結果は衰退であり、そこにいるＳＥや管理者の人達も路頭に迷うことは明らかなのです。欧米のこの分野の動きを見ていると、今までとおなじような仕事の進め方をやっていては、とても対抗できないことは明白なのです。
此処での論はＳＥの人たちを追いやるものではありません、むしろ彼等の「活路」を開くものであることを理解していただきたいのです。こちらの岸に居続ける限り、これからはＳＥとしての仕事に携わることは出来なくなります。
今後求められるのは一口に言って「プロフェッショナルなＳＥ」です。コンピュータプロフェッショナルとして続けるにしても、途中からマネージャーに転ずるにしても、ソフトウェアに関わる基本的な部分は、途中までは殆ど同じ能力が求められます。
その「基本的な能力」として、コンピュータの基礎知識の他に特に必要なのは抽象化の知識であり、それを前提とした開発技法や「仕事の仕方」です。プロジェクト管理や見積りに際しても、抽象化の技術は不可欠なものです。
たとえば構造化手法もオブジェクト指向も、そのスタートはモデル化であり、抽象化そのものなのです。同時にこれらの手法は共通して“STRUCTURED”―即ち“手順化された”手法であり、それ自体に作業手順が含まれています。それ故に、対象システムを素早く分析し、適切なダイアグラムを使って表現することで、より精確な見積りができ、作業の割り当てもやりやすくなるのです。
少なくとも、今後はコンピュータの基本的なアルゴリズムの他に、この様な設計手法や更には分析手法を身に付けていることが、ソフトウェアの開発に携わる条件になってゆかなければなりません。
したがって、これからのＳＥはそれを前提にして対応することが求められます。そしてＳＥであることを「軸」に管理的な技量、延いては経営センス等を身に付けて行くことも可能です。何れにしろ“一時的なＳＥ”は必要なくなるでしょう。
そして、このような技術や技法を身に付けるためにも、「仕事の仕方」を身に付けて、仕事が「約束できる」ことが全ての前提条件になります。決して“逆”ではないことに注意して下さい。
一方、「協調性」も重要な要素となるでしょう。所謂「チームワーク」です。プロであることと協調性は決して相反するものでななく、むしろプロであることを活かすために、或いはプロであり続けるために協調性は欠かすことはできないものなのです。
しかしながら、現実の多くのＳＥ（特にある程度経験してきたＳＥ）は、コーディング・ルールを標準化することすらできないのです。自分がこれまで慣れてきた表現方法にこだわっているのです。実に次元の低いところで固執するのです。少なくともこの様な姿勢をとり続ける限り、時代に合わせて変化することは出来ません。
但し、注意しなければならないのは、「結果平等」を根底にした共同化社会を維持するための「協調」と、ここで求められている「協調」は性質を異にするということです。それだけに容易には身に付かないかもしれませんが、これを放置していてはこれからのソフトウェアの開発組織は成り立たなくなります。「チームワーク」は自分を圧し殺すためのものではなく、自分を活かすための枠組みなのです。
― ◇ ― ◇ ― ◇ ― ◇ ― ◇ ― ◇ ―
私は、数年前にこのことに気付きました。恐らく他にも何らかの形で気付いていた人もいるものと思われます。そしてその後の推移を見ていますと、事態は残念ながら私の警戒する方向へと向かっていると言わざるを得ません。
今まで、このような考えを広く伝える機会がなかったのですが、今回ホームページという手段を得た事で、改めてこのような私の見解を公表することにしました。
何度も言うように、この主張はソフトウェア・エンジニアやその関係者を怯えさせることが目的ではありません。目の前の仕事の忙しさを理由に、このことに目を閉じて現実を見ないようにするのは止めて欲しいのです。日本の置かれている現状や時代の流れを良く見て、何をしなければいけないのかを正しく認識し、早く舵を切って欲しいのです。そうでなければ、その繁みの向こうには道は通じていないのですから。
特に管理者の立場にある人達は、あらゆる機会を捉えて新しい時代に対応すべく取り組まれることを強く願いたいと思います。そうでなければ今日のミドルの問題は、数年後には間違いなくＳＥ自身の問題となって降りかかってくるのですから。