同感です。可読性については感情論になりやすく、議論にならない場合が多々あると思います。
保守性についても、ネット上では同様なのですが、実務においては気を使っています。
保守性と可読性を混同して、「ラムダ式は新人には分からないだろうから使うな」などと言う人がいます。
しかしながら、プロとしては基礎構文ぐらい読めて当たり前であって、プログラム言語を読めないのは問題外だと思います。
そうした発言は、可読性や保守性などと言った単語を使って逃げているだけであって、本当の意味での保守性は違うと思います。
例えば、保守性でプログラム言語に着目する場合、「今後この言語が廃れた時の事を考えて参考資料残しておこう」などと言った、建設的な話しになるかと思います。
ちなみに、可読性については、基礎的なお約束をある程度統一すれば、後は個人の判断で任せればいいだけの話しだと思います。
酷いプログラムは、リファクタリングされるので問題なしです。
保守性と可読性という単語が逃げに使われるせいで、本質が見えにくくなっているのではないでしょうか？

可読性も保守性も重要ですよね。ただ、25年もC/C++プログラマをやって
いると、難読化処理したソースでないかぎり、まぁなんとか読めるもんです。
日本人はわりとまめなので、自身が見た最悪のソースはMFCだったりします(笑)。

　経験から言うと2つの理由で5年以上前のコードを保守する目にあったことが
ありません。
　一つはソースの寿命で、たいてい数分～5年程度の間にあっさりと陳腐化
します。OSや言語自体が変化して、苦心のソースが土台から崩壊することも
何度か体験しました。また、対象のアプリ自体が陳腐化した例もあります。
つまり、ソースはせいぜい5年ほど動けばよろしいということになります。
　もう一つは、絶対化です。寿命が来る前に発覚した問題はそれまでに概ね
改善されて正しく動作するため保守の対象から外れていきます。
結局5年も正常に動作しているソースは、だれも変更したりしないという
ことになるわけです。

　また、保守性は将来を見据えてのことでしょうが、現時点でのテクノロジー
を前提とした、未来時点での保守性の議論にはやや疑問を感じます。
実際のところ、そのときでも人間がソースコードを修正しているであろう
という前提さえ、ちょっと怪しい気がします。実際にC/C++が主流となり、
十分に機能し始めた時点で、だれもそのアセンブラ出力を確認しなくなり
ました。HTMLをGUIで構築できるようになった時点で、ソースにコメントが
ないことを非難する人はいなくなりました。自分の書いたコードに、将来
これと同じことが起こる可能性は非常に高いと考えます。そのとき、
自分のソースが人間にとって読みやすいことは何の慰めにもならないかも
しれません。
　とは、言うものの、少なくとも一年後の自分を含めた誰か、それが
誰だかわかりませんが、その人に向けて、丁寧に書いていこうとは思っています。

コードの読みやすさ。確かに人によってその判断の仕方が、異なるでしょうが。より多くの人、と言うか素人の意見は無視するとして、プロが読みやすいと感じるコードというのはあると思います。問題はそれを客観的に数値化出来ないこと。数値できないと、それを評価として使いづらくなることになります。でも評価は大切ですので、プロジェクトのプロジェクトマネージャ、それが無理ならアーキテクトなりが独断と偏見で、評価する体制を作ればよいと思います。ちなみに私の基準は、全体像をどれだけ簡単に把握できるかです。メソッドの分け方、的確なメソッド名、変数名。まー、最近は、ＴＤＤのプラクティスにしたがって作っていれば、自然にコードは読みやすくなります。

保守性には細かく言うと、機能拡張性や性能・規模拡張性、デバッグやチューニングの容易性などが挙げられると思うのですが、私がこれまで経験した現場においては、これらの項目はシステム設計やモジュール・階層設計、データ構造設計、基底・抽象クラス設計、デバッグ機構やシステムパラメタ設計等々といった設計フェーズ、いわゆる上流工程で主に議論・吟味され、「ソースコード以外」のドキュメント上にて完結されることがほとんどでした。

コードそのものに向けられる観点といえばせいぜいコーディング規約やコメントくらいで、上流工程のそれに比べてあまりにも貧弱であり、そういう意味では保守性を考える際に、
”ソースコードだけに目がいきやすい”
というのは実際の現場においてはあまりないのではないか、というのが私の認識です。少なくとも保守性が「属人的な指標」であるというのは言い過ぎではないかと思います。なぜならデバッグロギング機構の有無のようなところでソフトウェアの保守性を語ることができるからです。

可読性を議論する際に注意が必要なのは、その論点がコーディングスタイルだけに限定されがちで、これをもって「属人的な指標」と言われてしまうことです。これは可読性のメリットの多くが拡張性や保守性とセットになることが原因で、例えばMVCモデルのようなアーキテクチャはコードの可読性向上に大きく貢献しましたが、拡張性のメリットの影に隠れてあまり語られることがないように思えます。

またリファクタリングの目的の大半が可読性向上による保守性の維持であり、例えば冗長なロジックの最適化やクラス・関数構造の見直し、共通モジュール化といった修正がほどこされますが、このような修正がはたして「属人的な指標」と言えるのでしょうか。

プログラマの教育は多くの現場で可読性の領域までなされることはなく、個々人の独学に委ねられています。プログラミングスキルが水準に達していないプログラマは、グローバル変数の乱用や複雑な条件分岐など一般的に見て悪いコードと評価できるくらい可読性の低いコードを量産します。一番の問題はこうしたコードが現場において公に問題視され議論されないことで、これを引き継いだ担当者は修正の複雑さやリファクタリングにかかるコストを一人で背負わされている現状があると思います。また可読性の低いコードを作った本人のスキルがいつまで経っても向上しないというのも問題で、基礎教育の観点においても議論が必要なのではと感じています。

玄米茶さんの意見には一理あると思うのですが、実際に議論を行おうとするとどうにもなりません。
その理由は、異常なほど逃げ言葉として使用されるからです。
私のブログにも、並列処理とオブジェクト指向の観点から言っても「グローバル変数の使用を避けよう」と書いただけで「文章の意味が分からない」などと自称プロの人に攻撃される始末です。
しかも会話にすらなりませんでした。
酷い時には「俺の知らない専門用語を知っている奴はプロじゃない」などと粘着されました。
他にも、「俺が知らないから間違っている」などと駄々をこねられた事も多々あります。
それは議論以前の問題だと思うのですが、この手の人はどうしようもありません。
そういった経験から、少なくともネット上では議論にならないと思います。
日本人はよく議論が苦手だと言われる理由が体感出来ました。
感情論と理論の区別がつかない人が居て、そうした人が議論を台無しにしてしまうのです。
非ネット空間の会議では、この場にふさわしくないとして退場を促せますが、ネットではそうはいきません。
相手があらゆる卑怯な手段に徹して、誹謗中傷などの行為をしてくるので、害をこうむる事になります。
ですから、玄米茶さんの言及した所まで、話しが進まないのが現状だと思います。
誰も害をこうむってまで、無駄な時間を費やしたくないです。

私のブログの、オブジェクト志向に関するエントリで、興味深いコメントがされたことがあります。そのコメントを読んで、折に触れて考えているのが、可読性を、どの方向から求めるか、ということです。
　コードの書き方には、２つ（以上）あると思います。ひとつは、コードのその場面でしなければいけないことを、「どうやって実現しているか」を書くこと。ひとつは、コードのその場面で、「何を実現しているか」を書くこと。コードで、How to が表現されているものと、What あるいは Why （なぜそのコードが書かれたか）が表現されているものと、どちらが読みやすいのでしょう。
　この２つの考えのもとになったコメントは、「オブジェクト志向では、コードがあちこちに分散していて見にくい」という物でした。このコメントをくださった方は、コードの可読性に「どうやって実現しているか」を求めていると考えました。私は、オブジェクト志向というか、構造化されたコードとは、「何を実現するか」がわかれば、「どうやって実現するか」は問題ではないと考えています。
　ただ、最近、net-snmp のコードを見ているのですが、まぁ、テストで期待しない値が出てくるのでその原因を追いかけているわけですが、こういう時は、「どうやって実現しているか」が分かり易い方が、ありがたいですね。難しいです。
　あ、私は oriented の「関心を向ける」の意味を強調するため、「指向」ではなく「志向」の字を使っています。

保守性については、どちらかというと設計段階で議論されるべきだと思います。経験上、ソースコードの可読性が良いからといって、保守性に優れているとは思えません。拡張性や再利用性に難があると、ソースコードの可読性はせいぜいリファクタリング対象箇所を特定しやすくする程度しか効果がないと思うからです。

個人的な考えですが、いかに（顧客の要求を満たしつつ）保守性にすぐれたシステム（ソフトウェア）を設計するかがシステムエンジニアの品格で、可読性の高いソースコードでそれを実現するかがプログラマの品格で、どちらが妥協してもエンジニアが期待するものは得られないと思います。コスト的に落としどころを模索する必要はあると思いますが…

ソースコードの可読性については、他人に教わって身につくものだとは思えません。大工の棟梁が弟子にこと細かく指導しないのと同様に…結局、他人のソースコードを読み、自分の書いたソースコードを客観的に見返したときに、自分の至らなさを実感しないかぎり、いくら可読性の必要性を説いたところで聞く耳を持ってくれないのではないでしょうか？

>> プログラム言語で言うと、C#は読みやすいがVBは読みづらい、
>> SQLが読みづらい、アセンブラが読みづらい、など

慣れや得手・不得手はあると思いますが、プログラミング言語の違いに可読性は左右されないと思います…読みづらいコードになりやすいプログラミング言語はあると思います。個人的にVB/VBAは、他の言語以上に可読性に気をつけてコーディングしますし、必要以上に技巧的なPerlのソースコードは理解する気が失せることがあります。

可読性に関して属人的だ、といっているようでは
まだまだプロセス改善は望めないでしょう。

可読性に関する簡単な指標の1つとして「どれだけ
コーディング規約に従っているか」があります。
定量化して測定することも可能ですね。

要するに、できるだけ記述を規格に合わせて
誰が読んでも分かることを心がけるということ
ですね。

卑近な例を挙げると、「オブジェクト指向」は
オブジェクト指向であって、けしてオブジェクト
志向ではない、そういうことです。

遅くなりましたがみなさんコメントありがとうございます。
色々なスタンスの方々が意見を述べてくださるのは非常に有難い事だと感じています。

全体を通して感じているのは、恐らくここにコメントくださる方々で議論することがあれば、もっとすんなり話は進むというところかと思います。これが例えばこのような場所に意見を出さないような方々が相手となると途端に難しくなる。小さい企業でも大きい企業でも、社内で意思を統一させることは非常に難しいですよね。

>そうした発言は、可読性や保守性などと言った単語を使って逃げているだけであって、本当の意味での保守性は違うと思います。
(インドリさん)

そうですね。私も色々見る、社内で議論するなどを経験した上で同じように感じることがあります。保身的な意味合いを含めて上記のような言葉を使われるのは私も止めてほしいと思います。

>とは、言うものの、少なくとも一年後の自分を含めた誰か、それが誰だかわかりませんが、その人に向けて、丁寧に書いていこうとは思っています。
(仲澤＠失業者さん)

この言葉が非常に大事だと感じました。将来このプログラムに携わることになる誰かのことを考え丁寧に書いていこう、私も改めて注意していこうと思います。

>問題はそれを客観的に数値化出来ないこと。数値できないと、それを評価として使いづらくなることになります。でも評価は大切ですので、プロジェクトのプロジェクトマネージャ、それが無理ならアーキテクトなりが独断と偏見で、評価する体制を作ればよいと思います。
(yamamotoさん)

客観的な指針というのを可読性や保守性に関しては非常に用意しづらい、と私は考えています。実際に私の業務においては立場的なこともあり、私が独断的な指標を用意して実装することにしていますが、その難しさというのは日々感じています。メンバーが多くなるにつれ、その度合いは高くなるように思えています。

>またリファクタリングの目的の大半が可読性向上による保守性の維持であり、例えば冗長なロジックの最適化やクラス・関数構造の見直し、共通モジュール化といった修正がほどこされますが、このような修正がはたして「属人的な指標」と言えるのでしょうか。
(玄米茶さん)

玄米茶さんのコメント、私も自分の姿勢や思想についてはそれほど変わりありません。恐らくは私と玄米茶さんとの環境の違いが大きいのかな、と感じています。企業規模の大小が原因ではなくそこにいる人々の質が原因になるとは思うのですが、リファクタリングですらまだまだ実施していない企業というのがあります。上流工程のドキュメントも、実際に納品し稼働しているAPと異なる状態のまま放置されているということも多々あります。「それはシステム屋としてどうよ？」と思われるような話ですが、残念ながら現実に私はそのような環境に身を置いています。
そのような環境では声の大きさで保守性について議論が終わってしまう事も結構多かったりします。

>そのコメントを読んで、折に触れて考えているのが、可読性を、どの方向から求めるか、ということです。
（Jittaさん）

可読性の方向、というのは驚くとともに納得しました。可読性という一つの言葉で表しているので一つの思想や一つの事象を表す、というのが既に頭が固くなっているのだなぁ、と。もう少し頭を柔らかくし広く物事を見つめなおすことができるように注意しなければいけませんね。

>個人的な考えですが、いかに（顧客の要求を満たしつつ）保守性にすぐれたシステム（ソフトウェア）を設計するかがシステムエンジニアの品格で、可読性の高いソースコードでそれを実現するかがプログラマの品格で、どちらが妥協してもエンジニアが期待するものは得られないと思います。コスト的に落としどころを模索する必要はあると思いますが…
(かるたやさん)

エンジニア、プログラマの品格。いい話を提示していただいたと感じました。自分達はコスト意識を持ちながらも、出来るだけのことをやらなくてはいけないですよね。自分ももっと意識していかなければならないです。

>可読性に関する簡単な指標の1つとして「どれだけコーディング規約に従っているか」があります。定量化して測定することも可能ですね。
(みのがわさん)

私の環境において、プロセス改善が望めないのは残念ながら重々承知しています。全くもって仰られる通りです。
コーディング規約についてですが、確かにこれを用いることで測定することも可能です。FxCopなどのツールもあることですし、機械的な判定が可能だと思います。
ただしそのコーディング規約というのが、言ってしまうと「その企業において」というルールであり、企業が変わればルールも変わるものです。一つの環境に限定して話をするのであれば、可読性や保守性はまだ指針を決めることが可能だと思いますが、その枠をもう少し広げた場合どうなるのでしょうか？

コメントを書きながら改めて皆さんの意見を拝読させてもらいました。非常に鋭い視点からの意見で、物凄くためになります。本当にありがとうございます！

Ahf様

少しキツい言葉遣いをしてしまいすみません。FxCop というのは寡聞にして知りませんでした。参考になります。ありがとうございます。

さて「コーディング規約は一つの環境に限定して話をすればOKだが、それを広げたときはどうなのか?」というご指摘に対して回答しましょう。

「一つの環境に限定して話をすれば十分な場合が多く、まずはそれをテッテーすべし」です。

環境を超える必要がある場合は、調整が必要ですね。多くの場合は、業界標準を採用することになるでしょう。例えばオープンソースの世界であればGNU coding standard,レガシー環境だとK&R? (古過ぎ?, ムムムjust kidding)、昔はハンガリアンなんちゃらというのもありました。

まあこれも「枠を拡げた一つの環境」にすぎないわけです。

例えば(こういう例えを出すと「不適切な例えだ!」とキーキー言う方が出てくるかもしれませんが)、この掲示板だって「日本語でやりとり」しているでしょう? これがグローバルな議論であれば、多分、英語になるでしょう。もちろん、英語でやりとりする必要がなければ日本語でやっていればよろしい。

「企業が変わればルールも変わる」というのは、ある種の甘えと私は考えます。企業活動において「枠の拡大」を目指す企業であれば、より共通文化を踏まえたルールを制定すべきで、まあ自然とそうなっていくはず。

「俺あ、お山の大将でよかんべ」という企業であれば、マイルールでも全く構いません。そういうところとたまたまプロジェクトが一緒になったなんて場合には、外部の参加者は苦労しそうですけどね。

うーん、議論の前提にすら立っていない回答で少々残念な気持ちです。

ちなみに私はリファクタリングが行われているようなプロジェクトに携わったことはありません。
ほんとにそんな工数のかかるようなことが許されるしっかりしたプロジェクトなんてあるの？　と疑っているクチです（笑）

みのがわさん、再度のコメントありがとうございます。

まずは一つの環境に限定して話を進める、非常にわかりやすい内容だと感じました。そして異なる考えが現れた時には調整を行う、これを続けることで統一的な認識を作り出していこう、ということなのですね。

企業が変わればルールも変わるというのを「甘え」と言われた事をしっかりと意識・注意していきたいと思いました。

玄米茶さんコメントありがとうございます。
そしてよい返答をできなくて申し訳ありません。今回の返答で望まれている内容に近ければいいのですが・・・。

可読性について私の思うところは、コーディングスタイルも含めて可読性、というところです。言われるように「そこにだけ目がいきがち」というのはあると思いますが、反対にそこを抜きにしても議論にならないのではないかと思います。メソッドが短いから可読性が高いか、と一概に言い切ることもできないと思います。何を持って冗長と受け取るか、この時点ですでに個々人の感性による影響から逃れられないのではないでしょうか。
保守性にも近いものがあり、アーキテクチャとして変更を行いやすい形をそう呼ぶのか、コードを取り巻くドキュメント等を用意してそう呼べるのか、はたまたそれら全てなのか。このあたりも人によって意見が異なるところかと思います。

つきつめていくと私も玄米茶さんと同様「教育・成長」にたどり着くと考えています。ですがそこには非常に難しい問題を抱えているとも思います。世の中で保守性・可読性が低いと思われるコードを書かれる人たちというのは必ず存在します。ではその人たちは可読性が低いと認識しながらロジックを作成しているかといわれると、恐らくは違うのではないでしょうか。ある人が問題と思っている事でも、別の人にとっては問題とならない事というのは実際に存在すると思います。このあたりに認識を統一する事の難しさがあるのではないでしょうか。

私の中で属人的と言った大きい理由は、これらの前提条件が個々人の感性から逃れられないというところにあります。前提条件が異なっている状態で、続く議論だけを行うことはかなりの危険をはらんでいるのではないでしょうか。

そうなると、これら前提条件をどのようにして認識のすり合わせを行っていくのか、となるのですが・・・試行錯誤な毎日です。

あまりまとまりのない回答で申し訳ありません。

Ahfさんこんにちは。
気になったのでコメントします。

>私の中で属人的と言った大きい理由は、これらの前提条件が個々人の感性から逃れられないというところにあります。前提条件が異なっている状態で、続く議論だけを行うことはかなりの危険をはらんでいるのではないでしょうか。
>そうなると、これら前提条件をどのようにして認識のすり合わせを行っていくのか、となるのですが・・・試行錯誤な毎日です。

この件についてなのですが、もし実務で悩んでいるのであれば、組織的な問題があるかと思います。
属人的な部分は権限を持つ人がすぐさま決定。
属人的でない部分は理論的に議論、結論は権限を持つ人が決定でOKではないでしょうか？
そういった意思決定が正しくなされていないのであれば、それは組織的な問題であって、プログラミング上の問題ではないと思います。
ちなみに、属人性の有無は「論拠があるかないか」と「それでないと実装作業が出来ないか否か」で判別可能だと思います。
むろんそれを判断するのは、最終的に権限を持つ人の仕事です。
教育上の問題については、それ専用のコラムを書いて頂きたいと思います。

どっちかといえば「教育・成長」よりも「採用」時点で決してしまうんじゃないかなと、
議論を発散させるような茶々を入れてみる。

人間性とかコミュニケーション能力（ああ単語の後ろに（笑）を付けたい）重視で
素養の無い人入れておいて、「教育・成長」でどうにかなるかといえば・・・
ほとんど定型のプログラムしか書かせない前提なら良いんですけど。

返答を強要させるような言い方をして、大変申し訳ありませんでした。
言葉遣いを誤ったと深く反省しております。

私が考えているのはどちらかというと、Ahfさんのおっしゃるようにどのように前提条件を揃えるのかとか、そもそも問題の認識はあるのか、みたいなほんとに入り口の議論を想定してたんですよね。

ただいかなる理由においても、一切の議論を否定してしまうのはどうかなと思いまして、コメントさせていただいたしだいです。可読性の問題は多くのプログラマが実際に経験しているにもかかわらず、「議論もするな」じゃいつまで経っても問題が解決の方向に向かわないと思うんです。

私の考えはインドリさんと同じで、属人的な部分とそうでない部分を分けることで、少なくとも属人的でない部分については理論的な議論が可能だということです。特にスキルレベルとか教育といった観点と密接に関連した議論ができるんじゃないかなぁ、と漠然と思っています。要するに低スキルが招く可読性低下の部分です。

また、低スキル者自身も問題ですが、実はそれを指導する側の問題もあって、指導する側は技術力はもちろんのことそれを明確に説明できる説明力という高いスキルが必要とされるので、実際の現場ではこのような教育は十分行き届いていないだろうというのが私の推測です。

意味なくメンバ変数をstaticにしてたら誰だって指摘しますよね。でも明確になぜかを説明できる人って意外と少ないんじゃないかと思ったりしてるんです。

玄米茶さんのコメントが興味深いので、コメントします。
私はこの手の話題が好きです。

この難題に挑戦します。
>意味なくメンバ変数をstaticにしてたら誰だって指摘しますよね。でも明確になぜかを説明できる人って意外と少ないんじゃないかと思ったりしてるんです。

説明：staticは静的変数を意味します。静的変数とは、インスタンスではなく、クラスそのものの状態を表します。つまり、staticにするという事は、個々の状況ではなく、概念（オブジェクト）そのものが状態を持っている事になります。
今回のオブジェクトは○○であり、このstatic変数は、○○の情報を意味しています。
しかしながら、この情報はクラスそのものに属しているのでしょうか？
そして、その情報を使用するメソッド○○は、クラスだけに依存する処理をするのでしょうか？
違いますよね。ですから、この変数○○は、クラスに属するものではなく、個々の状態であるインスタンスに属する事になります。
従って、静的変数ではなく、メンバ変数にするべきです。
こんな感じになるかな？
人によって説明の仕方を変えてなくてはならないので、いざ文章にすると難しいですね。

おっと失礼。
メンバ変数は間違いで、インスタンス変数と言うべきですね。

またも返答が遅くなって申し訳ありません・・・
なお、強要されているとは全く思っていないどころか、返答できるのは非常にありがたいと思っていますので、お気になさらなくても大丈夫です。

※ただ私がピントをハズした返事をすることがあるので、その時は思い切りつっこんでいただければ。

>どっちかといえば「教育・成長」よりも「採用」時点で決してしまうんじゃないかなと
（Choirさん）

このご意見はかなり業界の問題を表しているように思えます。
ご時世というのもあるかと思いますが、即戦力を求める企業が増えてきているのではないでしょうか。即戦力だけ、とは言わないまでも「まずは即戦力」とせざるを得ないというか。色々と後塵に伝えていく程の余力が、企業から無くなってきているのではないか、などと感じています。

>この件についてなのですが、もし実務で悩んでいるのであれば、組織的な問題があるかと思います
（インドリさん）

あまり深くこのあたりを書いてしまうのも色々とありまして・・・
「組織的な問題はあります」とだけ書いておきます。勿論これは私の環境特有の話題だと思いますが・・・。

教育系についても、もう一度改めてまとめてみたいですね。

>属人的な部分とそうでない部分を分けることで、少なくとも属人的でない部分については理論的な議論が可能だということです。
（玄米茶さん）

なるほど、それはその通りですね。どの部分が属人的なのか、どの部分がそうでないのかを明確に出来れば建設的な議論になると思います。その土台を作る事（非常に大変なことだとは思いますが）を進めていくことが、まず必要なのだと感じました。

個人的には「その開発が対象とする領域（○○系とか）」「開発言語」は前提としておく必要があるのではないか、と思います。というのも、可読性というのはそれ以外の要素がベースとなっていて成り立つ要素ではないか、と考えています。そう考えたための属人性という表現でした。「読みやすいプログラムであるならば修正を行いやすい」という考え方です。

これは前提として必要ではないでしょうか？

話は少しずれますが、最近別の業界のプログラミングについて話を聞くことがあったのですが、そこではガベージコレクションを利用するようなプログラミングは「やってはいけない」というものがあります。基幹システムなどの業務系とは真逆の事が存在していますが、このあたりも前もって抑えておかないと「今の言語ではそれほどインスタンス生成・破棄に（最低限の部分さえ理解していれば）気を使う必要がない」と決めつけてしまうこともあるかと思います。

こういう事柄を見ていると、なおのこと「物を伝える・教える」ということはどれほど難しいかというのを感じます。

う、一言足りなかった・・・即戦力という意味ではなく、
素養があるかどうかという方向の話です。

例えとして多少不適切かもしれませんが、
ポインタや再起を扱えるようになるまで何年も教育し続けられるほど
リソースに余裕のある企業なんてそう多くないと思うんですよね。

教育の仕方が悪かったんだと自省するのは楽だけど、
本当にそれは教育担当のせいなのかと:-P

あぁ、誤読してしまいました、すいません。

教育的な部分もあるだろうけど、それ以前に素養（素質？）の面で問題があるのではないか、ということですね。その通りだと思います。

仕事として行う場合、メンバー全員を一定以上のレベルに引き上げるというのは理想として正しいが、現実としては難易度が高すぎると思っています。個人個人が意識を持って自発的に努力するのであれば叶いそうですが、それを望むのもまた難しいというか・・・