若手エンジニアの教育について考えていたのですが、組織開発コンサルの知り合いに教えてもらったことが面白かったです。
教育という観点では、この10年間で「自主性」というのが大きなキーワードになったそうです。ファシリテーションのような「学びの自主性」を促進するような考え方が大学などの教育現場に使われるようになったのが10年前ぐらい。僕（33歳）が卒業した後ぐらいから広がり始めたそうです。
そのため「講義スタイル（ただ聞く）」という形態が受けない。ていうか、すぐに飽きる。「なぜこれを学ぶのか」という目的を与えてあげないと、すぐに興味がなくなってしまうそうです。
だから「自分で学びを作る」というようにしてあげる。つまり、まずは自分たちでやらせてみる。そして、それを振り返らせて、相互にフィードバックさせる。
さて、こうした「学びの自主性」ということが重視される一方「マニュアル好き」という面もある。曰く「早く正解を教えろ」と。世の中にあるパターンとかメソドロジーとか、そうした"形式"を知ることが学びだと思っている。まぁ、たまに極端な人がいますよね。
こうした「学びの自主性」と「マニュアル好き」という2つを両立させた教育をする必要があります。ポイントは2つ。1つ目は自主的にやらせる時間を短いイテレーションにすること。あまり長い時間やらせると飽きてしまう。2つ目は振り返りやフィードバックが7割ぐらい進んだところでマニュアル（パターンや既にあるノウハウ）があれば提示してあげる。こうすることで、学びの自主性を失わせずにマニュアルも理解していけます。
面白かったのが、知り合いがやったマナー研修。マナー研修なんて講義と実技だけだろうと思ったら、そこにも学びの自主性を取り入れる。どうやると思います？僕はなるほど！と思わされたのですが「マナー研修のマニュアルを自分たちで作りなさい」というもの。グループごとにマニュアル作りを自分たちで実施し、ある程度できたら互いにフィードバックさせる。マナー研修のマニュアルなんて、そこらにあるモノだからこそ、こういうコロンブスの卵というか、うまいやり方が大事なんでしょうね。
ただし、こうした学び方にも問題はあります。それは「遅い」こと。体育会のように「うるせぇ、まずはやれ」みたいなことができないから、詰め込めない。まずはなんらかの体験があった後に学びの時間が訪れる。
学びのスピードを促進するには競争させることが大事。グループ演習で、あえてグループ間の比較を演出することによって競争意識を醸成する。そうやって互いのスパイラルで学びの速度を上げられるそうです。
なお、組織によって草食系（安定志向）と肉食系（挑戦志向）の割合が違います。ここら辺の違いも見極めつつ、教育のあり方も考える必要がありそうです。
僕がシステム開発を始めた（＝入社した）1997年というのはインターネット普及元年（インターネット就職の第1期）であり、企業システムが急速にインターネット化していく時期でした。技術的にはJavaやiモードが登場し、その後はOSSの興隆がありました。ビジネス的にはAmazonやeBayなどネットサービスが立ち上がり、SCMや企業間連携を含めて数え切れないほど新たな業務要件が生まれました。こうした中で、複雑化する技術や要件と戦いながら学んできたわけです。
そこから12年が経ち、今、新たにITを学ぶひとは、何を、どう学ぶべきなのか。なかなか悩ましい問題です。
