hetareDAIOの日記: 学ぶと教わる 8
問題発見と問題解決のプロセス (1):「思考力ゼロ人材の生産」という記事を読んで、思ったことを。
よくよく思い返してみると、私はコンピューターに関しては、誰からも教わってはおりません。すべて、自分で学習しました。仕事についても、そもそもゲーム製作会社へバイトにいって「よし、おまえにはサウンドを任せた」と肩たたきされて以来、仕事の進め方とかも一切教えてもらうことはありませんでした(というか聞く相手もいなかったw)。今にして思うと、高々一バイトに任せた!ってのは本当に無茶苦茶なことで、今のご時世ではまずあり得ない話ではあります。まぁ、時代に恵まれていたと言えます。その流れからいつの間にか契約社員となり、複数の転職を経て今に至るわけで、一度も新人扱いされたことはありません。新人研修なんて受けたことありません。ですので、いまでも名刺の扱いとか電話応対とかよくわかっていませんw
だからといって、今まで不利だったかというと、全くそういうことはない訳でして。名刺の扱いが悪かろうが、仕事には一切影響はしていません。なので、今でもそんな「ビジネスマナー」なんてのはどうでもいいと考えています。電話の応対は見よう見まねでやってきたので、そこまで変でもないとは思いますが、ちゃんとはできてないと思います。それでも、今までそれが不利に働いたことはありません。ただ、他人からは指摘されたことは何度かあります。けど、「実は教わっていないので」と言い訳したことはありません。「ご指摘ありがとうございます(だから何?)」とは言ってきましたけど。
そういう中で、私が仕事を通じてやってきたことは、「自分で考える」ことです。考える癖がつきました。というか、考えないと仕事にならなかったので、お金を得るためには考えざるを得ませんでした。別の言い方をすると、周りに本当に恵まれていて、私に考える機会を、周りが存分に与えてくれました。あいつならなんとかするやろ、と放置していたとも言いますがw
で、ここ数年ほど、今所属している会社が「人材育成」に力を入れています。ソフトウェアに関しても教育対象になっていて、会社が建てたプランに対して、私がそのうちの一部を講師として会社からお金をもらって担当しています。ソフトウェアに関しては社内で一番という評価をもらっているので、講師の依頼を受けたときはやらざるを得ないやろなと思って引き受けました。一応仕事なので、それなりのことをやってはいますが、常に頭をよぎるのが、冒頭に上げた記事に書いてある、「学ぶ」と「教わる」の違いについてです。そう、今会社が建てたプランに沿う形だと、「教えてる」ことになります。が、本当に出席している輩のためになっているのか?と自問すると、いやなってへんやろ、1ヶ月もしたら忘れとるやろこいつら、と自答してしまいます。ですので、プランから脱線しない範囲で手を動かしてもらおうとカリキュラムを工夫はしていますが、「考える時間」としては、たぶん少ないだろうなぁとは思っています。でも時間が決まっているので、これではいかんよなぁとは思いつつ結局答えを教えることも多々あります。
一応、会社には「場所と時間さえ与えて、後は会社が用意した機材とかつかって自由になにかさせてやる方がいいですよ」とは何度も進言しているのですが、なかなか理解はしてもらえません。今週末も講師役として仕事があるわけですが、果たして今のやり方でいいのか、もうちとやれることはないのか、常に考えている今日この頃です。
いやほんと、ビジネスマナーなんてどうでもいいって。仕事ができなきゃ意味ないって。ソフトウェアの設計は、記事にもある通り「非定型業務」なんだし。考えて学ばないとだめよね。それと、私も環境を提供できるようにならないとだめね。
自分はまともに教育受けなかったから (スコア:0)
今の新人も放任するのが唯一の正しいやり方だというその発想がまさに老害そのもの。
仕事は盗んで覚えろとかほざいて廃れた手工業や伝統芸能から何一つ進歩してねえ。ていうか職人連中を批判してただろうがお前ら
Re:自分はまともに教育受けなかったから (スコア:2)
理解できないなら黙っててもらえないでしょうか?考えてください。
ほえほえ
Re:自分はまともに教育受けなかったから (スコア:2)
worker向けの指導は楽だろうけど、specialistやprofessionalにするとなると、教えるのが格段に難しくなる予感。
Re:自分はまともに教育受けなかったから (スコア:2)
難しいどころか、教えることに意味はないでしょう、そういう分野は。自分で考え、自分で方向を決めて、自分で結論出してナンボの仕事ですから。教えてもらう要素がないかと。
ほえほえ
Re:自分はまともに教育受けなかったから (スコア:1)
『成果物』や『基準』が決まっているなら、最適解を[教えて]あげれば良いけど、
ソフト屋の場合、毎回異なるゴールになるから(毎回基準が異なるから)常に最適解は変動し続けるのです。
こんなのを[教える]事ができるとお考えなら(そして効率良く仕事を進められると主張なさるなら)是非とも『御教授』いただきたいものです。
notice : I ignore an anonymous contribution.
Re: (スコア:0)
そもそもソフトウェア開発に,最適解は存在しないと思う
# パレート最適解なら存在するだろうけど
車輪の再発明禁止 (スコア:0)
「最適解そのもの」を教えるのは無理でも、「どうすれば最適解に近づけることができるか」という方法論は教えることができるでしょう。
ていうか、「何を学べばいいかわからない」ような人に対して「何を学ぶべきか」を教えるのが重要。
たとえば、「無意味に三重や四重のループを回したあげくに、動作が遅いのを改善しようと全然無関係なところをいじくりまわす」といった感じの話は時々聞くものですが、こんなのは計算量理論を少しでもカジっていれば簡単に避けられる話。でも、人に教えられずに、自発的に「計算量理論を学ぶ」人は少数派でしょうし、だからこそそんなネタが散見されるわけで。
#最近は富豪的プログラミングでもなんとかなる場合が多いですが、分かっていて富豪的な(その代わりにシンプルで保守性の高い)コードを書くのと、分からないまま結果的に富豪的なコードを書くのでは大違い。
Re:車輪の再発明禁止 (スコア:2)
教えることはできますが、教えられた側がその通りにしか動けなくなるのが問題なんですよ。そもそもその方法論は、一般的に一意に決まるものではないでしょ?間違いなく複数ありそうです。そのいずれが正しいのかなんてのはケースバイケースでしょう。なので、自分で考えよう、考えさせよう、という話。
そんなの重要じゃないですよ。何を学ぶべきかわからないのであれば、学ぶべきことがわかっていることを頑張ればいいと思います。教えてあげるようなものじゃないと思います。悩んでいる人に聞かれたら助言することはあるでしょう。
というか、車輪の再発明の何がいけないのかよくわかりません。何度も自分の頭で考えて再発明すればいいじゃないですか。失敗すればいいじゃないですか。経験したことは無駄にはなりません。一見道が外れてたとしても、あるとき外れてた道とリンクすることもあります。新しい知見は、そういうところから発生するものだと思いますけどね。
ほえほえ