- - PR -
便利な道具と人を育てること
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-09-04 01:58
objectです。
とても重要な問題であり、 また、 今迄、ここのサイトで提起されたスレと 「底通する問題」 でもあると思いますので、少しだけ書きます。 例) 便利な道具 ⇒ 便利なら良いのか? 動くアプリ ⇒ 動けば良いのか? 「便利な道具」という表現が「何を意味しているのか」 これを、もう少し分析的に捉え直さないと、 「議論は発散するばかり」 だと私は思いますよ? #さらに、 #この問題(ソフトウエアに係わる)を、個々の人間の能力に迄、 #関連させて一緒に論じると、本質を見誤ると思います。 私は、 「便利な道具」⇒「必要性だけで作られた道具」 と考えています。 重要なのは 「事・物の本質」 だと思います。 別の表現をすると 「必要十分な事項」 と言っても良いと思います。 道具に限らず、 「必要性」 だけで進むと、その過程で必ず 「不純な事・物」 を内包してまいます。 #最悪なのは、「不純な事・物」は、必ず時の流れと共に、存在しなくなるという事実です。 #これは、最初から「本当の意味では存在価値が無い」訳ですから、言わば当然の帰結です。 そして、ソフトウエアの場合で言えば、 この「不純な事・物」は 「ソフトウエアの基礎が不十分な人には致命的に働く場合がある」 と私は考えています。 #その典型例が「VBで起きている」私は思っています。 特に所謂「ツール」で考えた場合、対極にある例が 「VBのツール」⇔「Delphiのツール」 ではないでしょうか? 1)VBは、ツールが 「便利であると開発者が考えると、見境無く採用している」 様に、私には見えます。 #何処までも、必要性だけで突き進んでいる。 #さらに悪いのは、 #時代と共に、必ず変化が発生しますが「基本的には変化を受け入れない」体質が #あり折角のVB.NETも、VB2005では、明らかに旧VBに回帰している。 #VC++のウィザードにも同種の問題を孕んでいるものがあると思います。 一方、 2)Delphiは、ツールを通して、 「概念を整理しつつ、明確化し、意義があれば、それを言語として規定する事に努力している」 と私には見えます。 #絶えず、必要性と十分性をセットで考え、尚且つ、言語としてその概念を明確化しようとしている。 #Delphiの「.NET」での対応は除外します。 最後に、 1)2)は、態度・考え方(方法論)に起因するものだと私は思います。 従って、もし、人間個々に影響するものがあるとすれば、 これら態度の違いは、 「技術者としての考え方にかなり大きな影響を与える」 と思います。 また、この問題は 「今のソフトウエア」 全体の問題でもあるんだと思います。 私が アーキテクチャ 会議室:「ソフトウエア科学・工学」と「断片化」 で提起したスレは、現在のソフトウエア界の混乱が 「必要性だけで進んできた」⇒「複雑性の増大」⇒「断片化」 だという提起にもなっています。 補足: この 「必要性駆動(私の造語)が、企業の利潤追求と密接な関係がある事」 を認識する事は、とても重要だと思います。 このままでは、 「資本主義が情報科学・工学を駄目にした」 と言われる日が来るのかも知れません。 #これは又、実用主義とも多少関係しているのかも知れません。 | ||||||||||||||||
|
投稿日時: 2006-09-04 02:04
企業として便利な環境になったこの時代、新人や後輩をどのように指導していけばよいのか
という非常に答えのでない投稿に対してたくさんのご意見ありがとうございます。 色々な方のご意見を拝見していますと、「新人教育とはどこまで教えるのか?」、 という認識の違いが色々と見えて、大変参考になっております。 私の中では「この企業での開発業務を行うために必要な基本能力を身につけさせるまで」 と考えております。それ故に「便利な環境がない案件でも少しは対応できる」レベル へと育てる事も含まれるのではないか、と考えています。 (この時点で色々とズレが発生している、というのは重々承知の上でです) しかし皆さんの書き込みより「そこは実際に業務に携わってから学ぶ事」という ご意見が多いことが「別の問題として認識したほうがよい」という考え方も有効な事を 改めて思いました。一人の技術者としては「ある程度色々な環境で仕事ができるように なってほしい」という希望はありますが、実際問題それはとても難しい話ですよね。 次の新人が入社する頃には、皆さんのご意見を思い出しながら四苦八苦してみよう と思います。 (そういえば来年はついに平成生まれが新人になる可能性があるんですよね・・・) | ||||||||||||||||
|
投稿日時: 2006-09-04 02:29
こんな深夜にも書き込みを有り難うございます。
引用部にとどまらず興味深いご意見だと思います。VBやDelphiなど開発プラットフォーム に関する部分は一概にそうとも言い切れないとは思いますが。そこまで含めてしまうと、 恐らく私の発言よりも本題よりずれてしまうかとも思われます。 ただ、曖昧な定義にて進めてしまうが故に書き込まれる多種多様な意見、これが 「広く意見を集めることに有効ではないか」、と勝手ながら考えております。 ソフトウエア業界全体として捉えられたObjectさんの視点は、非常に共感できる部分も ありますね。また同じような意見を持たれる方も、かなり居ることと思われます。 | ||||||||||||||||
|
投稿日時: 2006-09-04 02:47
これは、やり方次第でしょう。 中高生に勉強させるような教え方をしていたら、 伸びようとしなくなるでしょうけど。 たとえば。 上司が、講習会の案内を定期的に、ふるってご参加ください、 と言って出すというやり方なら、 むしろ、やる気を出す方に働くと思いますし。 もうちょっと教育っぽいやり方にしても、工夫次第でいろいろと。 当人がちょうどやる気を出してできる程度の難易度の課題を出して、 できたら褒める、とか。 教えるほうが大変ですけどね。 効果が出るなら、やる価値はあると思います。
その定義は正しいでしょうか? お客様から頂いたお金は。技術者の人件費にのみ使っているわけではないですよね? 社長の給料も、事務員の給料も、そこから出ています。 そしてそれを出さなければ。 十分なサービスは出来なくなります。 このように、サービスの質を維持するために必要なら、 それはお客様から頂いたお金から出すのではないですか? 教育コストがそれに含まれるかどうかは、会社の方針にもよるでしょうが。
そういう判断をするなら、それはそれで正解だと思います。 ただ、会社にとって必要かどうかを最終的に決定する要素は、すっきりするかではなく利益などですから、 別の判断もありえます。 たとえば私の話をすれば、技術力を高めることのほうが、会社の利益になると判断します。 生産性は、明確に物理的に表れますが、すっきりするかどうかは、個人の思考方法によると思いますから。
私がいっている「会社の方針」というのは、会社全体の方針、という意味ではないです。 すみません。紛らわしかったですね。一度補足説明がいるとは思っていたのですが。 会社の立場に立った方針、という意味です。 一部署の責任者でも、一社員でも、会社の利益を考えればこうするべき、という方針をたてて行動します、よね? そういうことです。 まあ、社長命令で業務中の教育活動は一切禁止、とかいわれたらどうしようもないですけど。 方針による、というのはそういうことです。 | ||||||||||||||||
|
投稿日時: 2006-09-04 07:15
「やり方次第」には異論はありません。 各個別でケースバイケースになると思います。 褒める=お給金UPって発想はついて回りますが、 この辺も加味してくださいね。 当人に合わせるのが面倒なため、画一的な教育になって来た背景があると思います。 なので、企業にしてみればコストUPなんですよね。 やる気を出したところで報われない・・・と言う状況の打開にはつながらないと思います。 「費用対効果で削ってきたもの」を取り戻すのは難しいです。 業界全体で正常な流れになるまでは、まだ紆余曲折しそうです。
定義についてですが、お客様からしたら、教育なんてどうでも良いわけで、 望むものが手に入るかどうかが主たる関心になります。 お客様の視点から考えて、 「出した利益でやればいいんじゃない?」 って議題はすぐに出てくると思います。 TOTALで見てどうこうと言うのは、経営者的視点かもしれませんが、 現場的視点からしたら、お客様を納得させられなければ、 お金は入ってこないんですよ。 営業的な視点って感じですかね? もう少し考えてみて頂きたいです。 [編集] ・明らかに自分定義と思われる言葉の排除 ・誤字の修正 [/編集] [ メッセージ編集済み 編集者: るぱん 編集日時 2006-09-04 07:58 ] | ||||||||||||||||
|
投稿日時: 2006-09-04 09:55
上記考え方だと社内に適正技術保持者が居なかった場合、どう対応するのでしょうか? タスク遂行に必要な技術を取得≠勉強という事でしょうか? 外部から一時的に技術者を確保するのでしょうか? | ||||||||||||||||
|
投稿日時: 2006-09-04 10:06
これも一般論としては正しいと思いました。 しかし、やはりこのスレッドの中では、正しいとは思えないのです。 まりもさんは一般論でお話されているので、少し僕とはズレが生じているようです。 なので、このスレッドの最初の投稿内容を僕なりにまとめてみました。 ・会社内で開発した資産モジュールを利用することで、高い生産性を実現している。 ・同時に、.NetFramework(コントロールクラスなどを含む)によっても、高い生産性を実現できている。 ・最近、このような便利ツールが多いため、新人には宜しくない環境ばかりだ。 ・人を育てるために宜しくないが、これらの便利なツールを使わなくなることは生産性の低下につながる。 ・はて、どうしたものだろうか?、皆さんならどうしますか? というように理解しました。 これに対して、僕は「今のままで良いでしょう。」と言っているのです。 スレ主さんの仰る便利ツールというものは、便利ツールと言うよりはコード資産です。 (これは購入することで権利を得た .NetFrameworkに含まれるクラスモジュール郡も含みます) つまりは、現在のところ、会社単位で過去に開発したコード資産の流用による生産性の向上が果たせているということです。 これは、現在のポリモーフィズムの目指すところでは無いでしょうか? 会社というのは法人とも言います。 「上記の場合に限って」言えば、法人が既にもっているコード資産があるにも関わらず、個人レベルでこれが無い場合を想定する必要もありませんし、 個人の技術力を向上させる目的で、既にあるコード資産の開発技術を法人が学ばせる必要性がどこにあるのでしょうか? と言うことです。 #その後、ソフトウェア業界全体のお話が入ったり、他社のコードを受け取ってメンテナンスをする場合に・・・などという話も混ざってきましたが、これらは論点が違うというものです。 余談ですが、僕は裏で N-Basic のソースを仕事で書いています。 この言語はローカル変数はありませんし、構造化プログラミングも困難です。 ファイルも低レベルの入出力機能しかありません。 でも、グローバル変数しか使えない場合のコーディングのノウハウや、レコードへの高速アクセス技法や、インデックスファイルの更新技法などの教育を新人にしようとは思っていません。 必要になった時に学べば良いのですし、既に僕が作ったサブルーチンやコード資産が良いサンプルになると思うからです。 この業界に限らず、技術屋が「人を育てる」ということは、有識者が新人に教育を施すことではなく、どのすれば一人前の技術屋になれるのかを教えることだけだと僕は思います。 #そりゃ聞かれれば教えますけど、自分から手取り足取り教えるくらいなら、こっそり会社の時間で自分の技術向上を目指しますw | ||||||||||||||||
|
投稿日時: 2006-09-04 10:43
下請け業務が多い私としては、まったくわけのわからんプログラムを渡されて
改造を数日でと頼まれるときがあります。 そのときはトレースもそこそこに、時間に追いまくられ動くことだけを確認する こともあるのですが、しかし、精神的に悪いことは著しいですね。 そのような仕事が新人のうちから続くなら、器用な便利のいい人材になっても開発者には なれないでしょう。 分業といってしまえばその通りのですが、その会社もしくはその部署で必要とされる人材は どのような人物でスキルなのかで扱いは変わってくると思います。 またその人の適応能力も判断する必要があるでしょう。 目先の金だけで流れ作業のベルトコンベアの前に立つだけのソフト開発者を 必要とされる時代かも知れませんが、何かが足りないような気がします。 |