教育によって知識を増やすことは可能だ。しかし、知識を増やすだけでは組織内の問題はなかなか解決しない。今の世の中、知識を詰め込むトレーニングは意味がない。なぜなら、知識の多くはインターネットで検索できるようになってしまったからだ。
必要な知識は検索したりお金を払って手にいることができるようになった。人間に求められているのは、それらの知識を使ってさまざまな問題を解決することである。
今読んでいる『20歳のときに知っておきたかったこと スタンフォード大学集中講義』（5/5現在でアマゾンのランキング1位！）には次のように書いてある。
【『20歳のときに知っておきたかったこと スタンフォード大学集中講義』p21-22より引用】
教師はたいてい、学生に知識を詰め込むことが自分の仕事だと思っています。教室のドアは閉められ、机と椅子は教師に向かって固定されています。学生は、後で試験に出ることがわかっているので、熱心にノートを取ります。教科書を読んでおくことが宿題として出され、学生は黙々と予習します。大学を出てからの生活は、これとはまったく違います。社会に出れば、自分が自分の先生であり、何を知るべきか、情報はどこあるのか、どうやって吸収するかは、自分で考えるしかありません。実社会での生活は、出題範囲が決められずにどこからでも出される試験のようなものです。ドアは大きく開かれているので、何か問題にぶつかったとき、職場や家庭で問題が起きたとしても、友だちとの悩み事も、世界全体の問題を考えるときも、身の回りの資源をいくらでも利用できます。【引用終わり】
そうなると『20歳のときに知っておきたかったこと スタンフォード大学集中講義』に書いてあるように、イノベーションを起こせるような思考トレーニング、行動が必要であり、それがないと組織改善につながらない、ルーチンワークをこなすだけならルーチンワークのやり方を教えることでトレーニングは終わってしまう。多くの組織では中堅から上級の社員に対してはそれでは足らないと言われる。
しかし、プロジェクトリーダーの立場で考えると「人間はそう簡単には変わらない」と思う。上記の引用のようには考えていない大学の先生が大半ならいいが、現実はそうではないし、アメリカの大学でできることと日本の大学でできることは異なる。
人間何十年も生きてくれば育ってきた環境やこれまで関わってきた人々の影響を何らかの形で受けている。360度のうち1度、2度、3度くらいは変わることがあっても、10度、20度、30度も変わることはそうはない。
そう考えると、今いるプロジェクトメンバーに対して組織が欲しいと思う理想の型にはめ込もうとするのはあまり効果的ではないんじゃかと思う。どちらかと言えば、その人の特長、良さを引き出すようなマネジメントが効果的だと考える。
かねてからピーター・F・ドラッカーや、トム・デマルコはそれぞれの著書でそういっていたと思う。
仮面の忍者赤影（古い？）やゴレンジャー（まだ、古い？）や A Team や、幽遊白書のように、チームの中でそれぞれが特技、役割を持ちそれらを活かしてチーム全体としてのパフォーマンスを上げるのが一番いいと思う。
しかし、現実的な問題は解決すべき問題に対してどうしても現在のメンバーでは足らないスキルがあるときだ。こういうときにオールラウンドプレイヤーがいるとプロジェクトリーダーはとても助かる。プロジェクトのパフォーマンスを最大にすることできる。
そういうオールラウンドプレイヤーやキープレイヤーがいないときは、一時的にでも外から連れてこなければいけないのだが、そういうことができないときもある。だから、プロジェクト設立のときの人選はとても重要であり、それがうまくいくかどうかで7割方プロジェクトの成功が見えると思う。
このようなプロジェクト運営のやり方で起こる問題として次のようなことがある。
- それぞれに得意な仕事を割り振った後に残った誰もがやりたくない仕事を誰にやってもらうか？
- どうしても現メンバーでは足らないスキルがある。
- 他のメンバーの足を引っ張るようなチームの和を乱すものがいる。
「やりたくない仕事」は見習いレベルの者がいれば「すべては修行」と言ってやらせるし、中堅、ベテランばかりのときはチームとして必要な仕事であることを説明したときに理解し同意してくれる者にやらせるべきだろう。そういう者はいずれ上位に上がっていく。
どうしても現メンバーでは足らないスキルがある場合こと、トレーニングのときだが、トレーニングしてもダメな時はダメなものだ。データベースの設計をやったことがないメンバーに一週間くらいのトレーニングに行かせてもデータベースの設計はできない。
多くの場合、そういうときはお金を払って外部の協力会社に開発を委託するのだが、お金がでないときはどうするか、自分の場合はプレイングマネージャーとして自分がそのスキルを身につけるようにしている。一時的負荷は増えるが新しいことを学ぶことは楽しいし、オールラウンドの範囲が広がる。
チームに悪影響を与えるような者がいる場合、JaSST'10 Tokyo の基調講演で、Ms. Johanna Rothman （Rothman Consulting Group, Inc.) は、早めにクビを切れ（実際には転職先を探してあげたそうだ）と言っていた。
そういうもろもろの複雑な事情含めて考えると、問題解決能力の高いメンバー、新しいことに対して臆せず取り組んでくれるメンバーがいかに貴重であるかがわかる。
そういう人材を高く評価し、さらに伸ばす仕組みが社会的に確立されるといいなと思う。それは、ヒューマンスキルではないんだよね。ITSSたETSSなどソフトウェア系のスキルスタンダードは整備されてきたが、イノベーターとしてのポテンシャルを測るスケールがなかなか世の中にないから『20歳のときに知っておきたかったこと スタンフォード大学集中講義』が売れているんじゃないだろうか？
P.S.
日経コンピュータ 2010.4.28 号の書評に『リコールを起こさないソフトウェアのつくり方』が載ったので紹介しておく。
高品質・高信頼なソフト開発手法の解決書。トヨタ自動車がブレーキ制御ソフトの問題で大々的なリコールを実施したのは記憶に新しい。ソフトは大規模・複雑になるにつれ品質維持が困難になる。解決にはプロジェクト管理の改善とソフトの資産化が肝要と、組込みソフト開発歴20年の筆者は主張する。リコールになりかねない「危ない」プログラムの例にも注目。
著者として短いながら当を得た書評だと思う。感謝！
0 件のコメント:
コメントを投稿