2008-12-07

進学塾のソリューションを考える

みなさんは、日本の小学生向けの進学塾のアプローチの仕方をご存じだろうか。簡単に言えば、小学5年生のうちに6年生のカリキュラムをすべて履修してしまい、6年生になったら志望校に合わせた受験対策のための勉強をするという方法だ。

それは小学生本人にとってはとても過酷な勉強方法であるが、やりきることができれば効果は絶大だ。なにしろ一年分も前倒ししてカリキュラムをこなし、一年間も受験の対策をするのだから、そんな勉強の仕方をしていない子供はなかなか立ちゆかない。

自分がこの状況に問題点を感じるのは、偏差値の高い学校に入学することをゴールにしていることもさることながら、目的を達成するためのソリューションを考えているのは進学塾サイドであり、生徒や親は提供されたソリューションに乗っかっているだけだという点だ。

問題を解決するための方法を自分で考えてないということ=問題解決力が低いということにならないだろうか。あらかじめ答えの決まっているテストに回答して得点を競うというということは、知識と回答のパターンの記憶の勝負とも言える。

『東大合格生のノートはかならず美しい』という本が売れているが、この本で紹介されているノートの書き方をまねしてしまったのではたぶんダメなんじゃないかと思う。ノートの書き方のくふうを考える→やってみる→調子を見る→改善してみる、といったP(Plan)→D(Do)→C(Check)→A(Action)を回して確立した結果がこの本で紹介されてる美しいノートなのではないだろうか。

だから、すでに確立されてしまっているソリューションをまねしただけでは効果は半分ぐらいしかないのではないかと思う。技は自分で苦労して編み出したときに最大の効力を発揮する。プロフェッショナルが考えたソリューションをただ単にまねするのではなく、少なくとも自分向けにテーラリングするくらいのくふうがないと力がつかない。

『問題解決能力』はこのブログサイトにたどり着くキーワードの常に上位にランクされている。過去に書いた『問題解決能力(Problem Solving Skill):自ら考え行動する力』の記事の影響だと思う。この記事にも書いたけれど、問題が何かを見据えて、その問題を解決する能力が高いと、その問題を解決するための知識やスキルは何かが分かる。要するに誰かから指示されなくても、自分で問題を解決し、問題解決のために必要な知識、スキルを身につけることができる。問題解決に必要のない知識、スキルを身につけなくてもいいから効率がいい。

問題解決能力が高いということは、自立した万能選手であることと同等だと思う。後は、その万能選手に燃料を与えてあげるだけだ。その燃料となるのがエンジニアに対するモチベーションであり、モチベーションは顧客満足と考えると組織の価値ともオーバーラップするからよいよとこのブログで言い続けている。

進学塾は自分たちのビジネスのために最大の努力をしており、そのソリューションは確かにすごいと感じる。ただ、問題はそのソリューションを使った教育は答えのない問題を解決する能力を高める訓練にはなっていないという点だ。

この問題を解決するにはどうすればいいのか。それには教育に対する顧客と顧客満足は何なのかを考える必要がある。教育サービスの顧客が子供の親であり、親が有名な学校に子供を入れることが顧客満足なら進学塾のアプローチは間違っていない。

教育の目的を、子供が成長したときに自立して生きていくことと考えるのなら、教育サービスが「子供が成長したときに自立して生きていくこと」につながっていかどうかを常に確認しておく必要があると思う。
 

2008-11-29

ツールの導入とは自分自身が変化するということ

Embedded Technology 2008 が終わった。5月のESECと11月のETは組込み系の首都圏で開催される2大イベントで、これらの展示会に行くことでツール類の情報や、開発方法論の情報などをチェックする。

日頃、ソフトウェア開発に関するツールについて、「ツール至上主義はいけない」とか「ツールベンダーの口車に乗ってはいけない」などと言っているが、ツールについて最新情報をチェックしていない訳ではない。何が本当に役に立つのか、立たないのかの判断基準を自分の中にしっかり持ってツールを見定めているし、ツールベンダーの話も聞くようにしている。

そういう目で展示会の会場を回っていると、ツールを通してエンジニアを助けてあげたいと思っているツールメーカー、ツールベンダーと、時流にのって売り上げを伸ばすことだけを考えているツールメーカー、ツールベンダーが見分けられるようになる。

ツールメーカーは純粋にソリューションを提供したいと考え、ツールベンダーは売り上げしか考えていないとか、ツールベンダーの営業員によっても目先の売り上げだけを考えている者と、ユーザーと長く付き合うために何とか要望を聞いてあげたいと考える者がいるので、一概にあの会社はいいとか悪いとか言えないが、好ましくないベンダーは好ましくないユーザーがいるからこそ生き残ってしまうのではないかと思うことがある。

ET2008の展示会場で 富士設備工業(株)電子機器事業部 の浅野さんと話しをしていたときのことだ。(富士設備工業なんて、およそソフトウェアと関係ありそうもないが、実は海外の開発ツールを積極的に導入しサポートまで提供している)

富士設備工業(株)電子機器事業部 では、ソフトウェアプロダクトラインの支援ツール pure::variants を取り扱っている。今でこそ、ソフトウェアプロダクトラインはメジャーなキーワードになりつつあるが、たぶん日本で初めて話題になったのは2003年くらいからだと思う。当時、自分はEEBOFでソフトウェアプロダクトラインのことを知り、CQ出版の Interface誌 2003年12月号で『具体例で学ぶ組み込みソフトの再利用技術』というタイトルで自分がモデレータとなってソフトウェアプロダクトラインにも関係する記事を書いた。浅野さんはこの記事をことを覚えていてくれて、当時ソフトウェアプロダクトラインの情報源のひとつとして役に立ったと言ってくれた。

浅野さんとソフトウェアプロダクトラインを日本で成功させるのは簡単ではないという話をしていたら、お客さんの中にはツールを導入しても結果的にうまくいかず、ツールやそのソリューション自体に対して役に立たないという烙印を押してしまい、その経験がトラウマになってしまう人たちもいるということを聞いた。

自分はツールを導入するきっかけは、技術者個人がある状態から別の状態に変化すること、あるいは変化したいと思うことにあると考えている。

現在の状態では問題がある、効率が悪い、品質が上がらないので、それらの問題を解決し、開発効率がよい状態、ソフトウェア品質が高い状態に移行したいと考え、ツールが状態変化に必要だから導入するという考え方だ。

みなさんによく考えて欲しいのはソフトウェア開発は基本的にはソフトウェアエンジニアの日々の活動の成果の積み重ねであり、ソフトウェアエンジニアの頭の中で考えたことが最終成果物になるということだ。
ソフトウェア開発で何か状態を変化させるということは、すなわちソフトウェアエンジニア自身(正確に言えばエンジニアの頭の中)がある状態から別の状態に変わるということなのだ。だから、自分自身が変わる気はさらさらなく、ツールがソリューションを提供し成果物を変化させてくれるはずだと考えているとたいてい失敗する。

一番成功する確率が高いのは、技術者が自分自身で状態の変化を手作業で実現し、その手作業の工程を自動でやってもらうといケースだ。手作業で業務なりプロセスなり、活動なりを改善し、その一部をツールに任さるためにツールを導入するケースだ。すでにやったことがあって効率化を図るという方法ならほとんどの場合成功する。

それとは逆に自分自身が変わる気がなく、ツールを魔法の箱にように見たてて期待していても何も起こらない。高い金払ったのだから何か出せと言っても何もでてこない。

ただ、ツールを購入したことをきっかけにして、ツールを使いこなせるようになることで自分自身の変化のきっかけにする人はいると思う。でも、自分自身の変化の必要性の認識とそのたいへんさが十分に理解できていないと結局は途中でくじけてツールはお蔵入りとなる。

世の中には操作者が何も考えなくてもインプットを与えて期待するアウトプットを出力するタイプのツールもたくさんある。でもソフトウェア開発に使うツールはソフトウェア開発自体がひとつの方法論には集約できないのでそんな単機能のツールなど存在しないし、そのような単機能なツールはあったとしても一般化されているのでESECやETで物色することもないのだ。

ソフトウェア開発ツールには結局は何かしらのソリューションが隠蔽されているのだけれど、利用者側はそのソリューションがどんな問題を解決する方法論からきているのかを理解する必要があるし、場合によっては自組織や開発製品に合わせてツールの使い方をくふうしたり、ツール自体をカスタマイズしてもらわないと問題解決に有効でないこともよくある。

ツールを使うユーザーが自分自身の変化について心の準備ができており、変化しなければならない目的が明確になっており、その目的のためには多少の犠牲も必要というそれなりの根性があればツールは活きてくる。そのようなユーザーに手厚く援助してくれるツールメーカーやツールベンダーを見つけないといけない。

その自信がないユーザーはまずは、ツールを買うのでなくソリューション自体を学習したり、手持ちの道具を使って問題を解決してみることを考えるとよい。解決できる見通しが立ってからツールを導入すれば失敗はしない。

実は、Excel や Word やフリーのツールなどをくふうすることで解決できてしまう問題はたくさんある。そういう努力を日々やっていると、「なんで、わざわざこんなツールを作るの?」とクビをかしげたくなるようなツールも見えるようになってくる。
 

2008-11-22

人生は実験

『広い心で聞く』の続きで、米国シリコンバレーを中心に経営コンサルタントとして活躍するKimberly Wiefing 氏のインタビュー記事の最終回である。
Life is an Experiment

Wiefling: Some people tell me, “Kimberly, this kind of listening, this kind takes a long time. I’m very busy person.” Here’s the problem, though. Do you ever have a conversation with somebody, and you have the same conversation over and over and over again? This takes a lot of time. When somebody says something, if they think you didn’t hear them, you know what they do? They say it again. And if they don’t like the conversation, they come back and have another conversation with you. So what we find is spending this time on these kind of critical conversations actually is a lot faster than trying to rush through the conversation with non-generous listening skills.
Listening seems very passive, and sometimes it’s hard for people to understand how powerful it can be. When we’re listening, we’re sitting quietly. This is very difficult for some people to understand. How can listening be great leadership? It’s something you just have to try.
When you start really listening to people, they feel valued. When they feel valued, they start contributing more. When they start contributing more, more ideas come, they have good feedback about their performance, and everything improves in that working relationship and in the team. I and listen to somebody that you haven’t listened before.

ウィーフリング:「キンバリー、こういった聞き方は時間がかかる。私はすごく忙しいんだ」と言う人たちもいます。でも、そこに問題があるのです。あなたは、誰かと話をして、同じ会話を何度も繰り返したことがありませんか? これは大変時間がかかる行為です。何か言って、相手が聞いていないと思ったら、その人がどうするか、おわかりですか? また同じことを言うんです。また同じことを言うんです。会話に満足しなかったら、戻ってきて、もう一度話しをします。ここでわかるのは、実際、こうした決定的な会話にはそれなりの時間を割いた方が、ジェネラス・リスニングのスキルを用いないで会話を急いで切り上げようとするより、ずっと早く済む、ということです。

 聞くという行為は、大変受け身なことに思われますし、それがどれほどの威力を持ち得るのか、理解しにくいこともあります。人の話を聞いているとき、私たちは黙って座っています。そのことがなかなか理解できない人々もいるのです。話を聞くことが、優れたリーダーシップであるものか、とね。それは、あなたがとにかく試してみるべきことなんです。
 あなたが人の話を心から耳を傾け始めたら、相手は自分が重んじられていると感じます。重んじられていると感じると、人は今まで以上に貢献し始めます。貢献度が増せば、より多くのアイデアが浮かび、自分の業績についていいフィードバックがもらえる。そうすれば、そうした職場の人間関係やチームにおいては、あらゆることが向上していきます。私は皆さんに「やってみてください」とアドバイスするんです。人生は実験です。時間をかけて、試してください。これまで耳を傾けたことのなかった人の話に耳を傾けてください。
キンバリー・ウィーフリング氏の話を聞いてみて感じるのは自分の主張がはっきりしており、説得力があることだ。もちろん、主張の裏付けもある。

振り返って、日々の仕事の中で感じるのはエンジニアやマネージャの自信のなさだ。うまく回っていないプロジェクトほどサンドバッグのように右から叩かれると左に振れ、左から叩かれると右に触れてしまう。もちろん、広い心も持てないのでプロジェクトリーダーはジェネラス・リスニングもできない。

問題を解決しようと思っても誰も決断できない、誰かが話を切り出すのを待っている、誰かがダメだししてくれるのを待っている。日々の発言や行動に明確な根拠を持っていないからそうなる。

そういう状況でもキンバリー・ウィーフリング氏のような優秀なコンサルタントはネガティブな言い方はしない。必ずポジティブに自信を持って攻める。

結局、ダメだしして受動的に動いているようではダメだしする人がいなくなった瞬間にプロジェクトは立ちすくんでしまう。自立できるようにしなければ意味がないのだ。

エンジニアが自立するためには自分の発言や自分の行動に自信を持てるようにならなければいけない。ジェネラス・リスニングは技術者に自信を付けるのに役立つと感じる。時間をかけてジェネラス・リスニングを行うのは、相手に自信を付けてもらい、自立させて自分でどんどん問題を解決でききるようになってもらうためでもあると思う。

『問題解決能力(Problem Solving Skill):自ら考え行動する力』も参照されたし。