NHKの「就職難をぶっとばせ！」を見て

2010年12月25日クリスマスの日にNHKで『日本の、これから「就職難をぶっとばせ！」』という2時間の討論番組がオンエアーされた。

もちろん、超氷河期と言われる就職活動がテーマなのだが番組を見終わって、これは学生の就職という限れれた範囲の問題ではなく、日本の社会全体の問題だと思った。学校で何を教えるのか、企業はどのように人材を採用し、そして社会はどのように人材を流動させる必要があるのかといった社会構造の変革時期に来ているということがよく分かった。

番組は三宅民夫アナウンサーが進行役で進み、就活中の学生（内定あり、就職のための留年を決めた人、既卒者など）や、経営者、人事担当、高校の先生、就職した先輩などが集まっていた。

ゲストは、下記のような方々で、勝間さん、海老原さん、宮本教授がそれぞれの持論を披露し、それについてディスカッションをした。

文部科学副大臣…鈴木寛，株式会社クラレ代表取締役会長…和久井康明，東京大学大学院教授…ロバート・キャンベル，経済評論家…勝間和代，株式会社ニッチモ代表取締役…海老原嗣生，放送大学教授…宮本みち子

勝間さんは次の2点を主張していた。

1. 日本の企業は新卒一括採用をやめて、アメリカのように不定期にエントリーレベルから採用したり、インターンシップによる採用をすべきだ。
2. 企業が社員を解雇しやすくする（=もっと人材を流動しやすくする）ように、セーフティネットを準備し、解雇された後の職業訓練や雇用手当を充実させる。

議論の中で重要だと思ったのは、日本の企業が新卒一括採用をする際のメリットについてである。企業側は新卒一括採用によって、新入社員研修をまとめて実施することができ、かつ、「同期」の意識を高めることで、同期同士での助け合い、競争、情報の共有といういろいろなメリットが生まれるということだった。ようするに企業は新卒一括採用によって新入社員教育のコストを抑えることができるということだった。

しかし、考えてみればアメリカのエントリーレベルのプログラマなどは年収200万円くらいだと聞く。そんな低賃金で雇えるのならば、不定期に個別トレーニングを受けさせてもコストアップにはならないだろう。

問題は、日本式で何十年もやってきた日本の企業がアメリカ式の雇用スタイルには簡単には変われないということだろう。司会の三宅さんは、番組の最後の方で「我々団塊の世代は、小中高大と学校を通り過ぎ、企業に就職して定年まで勤め上げるという、レールに長い間乗ってきた。今、このレールを降りなければいけない時代に来ているようだが、果たして降りられるだろうか。」と言っていた。

まさにそのとおり。日本人が高度成長期にやってきてうまくいっていたシステムを変えるためには、危機感がなければ変わるわけがない。右にならえでやってきて大きく失敗しないでここまでこれたのになんでシステムを変える必要があるのだと思っている経営者や人事担当は山のようにいるはずだ。

でも、いろいろな方面で日本が世界の一番でなくなってきた今、ひとと同じことをやっていてはグローバルな競争には勝てない。韓国や中国やインドの企業に負けて、仕事がなくなって今のポジションを守ろうと考える社員が多くなり、会社が潰れたり、合併されたりしてから問題に気がつく。

どうも、これまでの日本では周り同業他社を見渡しながら同じようなことをコツコツをやっていれば、なんだかんだいって売り上げは上がっていったらしいのだ。国全体が成長期にあったから、そうだったのだが今は違う。今は、日本の中でそんなことをやっていても、同業のアジアの会社には勝てないし、変化のスピードが早いので海外他社の成功を見てから真似しても間に合わない。その状況に日本人の多くが気づいていない。別な番組で、日本にいると SAMSUNG の驚異はあまり感じないが、東南アジアや中東、南米などに行くと明らかにSAMSUNGの台頭に驚くという。日本の平和ぼけは経済においてもボケのようだ。

新卒一括採用という制度は護送船団のように見える。人事部門は他の会社がやっていることを真似していれば大きな失敗もなく、経営者から怒鳴られることもない、学歴で学生を選ぶからひどい人材を採用する危険性も低いが、飛び抜けてユニークな大きな組織貢献をする可能性のある人材の採用もできない。そこから脱することもできるはずなのにみんなが周りを見渡して顔色を伺っているから、だれも動かない。

もう一つ、人材コンサルタントの海老原さんは、学生や親は大企業ばかりに目を向けないで、世界でも有数の技術を持つ中小企業などを探しなさいと主張していた。中小企業が学内でちょっとした飲み会のスポンサーになって、学生と直接話しをする機会を設けたらどうかという話しもしていた。マスコミを通すと中小企業の良さが伝わらないから、直接話しをする機会をできるだけ多く作ろうとう提案だ。

実際、今の学生は大手指向が強く、自ら狭き門に殺到している。従業員数1000人以下、300人以下という企業なら求人倍率は1倍を遙かに上回っている。

日本だけでなく、世界でのシェアも高い卵の選別をする機械を作る会社などは、せっかく採用したのに親に「そんな会社は聞いたことがないのでやめておきなさい」と言われ、内定を辞退する学生が少なからずいるらしい。だから、今では親子に対して会社の説明をする説明会をやるのだとか。

この問題提起に対するディスカッションで、大企業は安定しているし、何はともあれ就活サイトでは大企業の情報しか載っていないという話しがあった。優良な中小企業の情報自体が得られないというのだ。

コメンテーターから毎日新聞各紙を読んでいれば、中小企業の情報も入手できるという指摘があった。自分もそう思う。新聞だけではない、インターネットや業界のニュースサイトからだって情報は得られる。興味のある業界が特定されているのなら、業界新聞やその職種のひとが書いているブログを読むことだってできる。

今なら、PCの前に座って各方面の情報を探ればいくらでも情報は得られるのに、やっていないだけなのではないだろうか。誰かに情報の検索方法を教えてもらっていないから、他の学生はそんなことやっていないからしないのだろうか。

就活サイトという与えられた枠の中だけでしか情報を探していないのではないだろうか。これも右にならえ症候群の影響だろうか。

討論会の中で、就活学生はリスクについて考えた方がよいという話しがあった。大企業に就職した入社二年目の社会人の方がいて、同期が500人もいると自分がやりたい職種があっても希望どうりになる可能性は低い、大企業では会社に入ってからも競争が続くと言っていた。それが大企業のリスクだ。中小企業なら、社長と直接話しをする機会も多く、自分がやりたいことを主張すればその心意気を汲んでやらせてくれる可能性もある。英会話の能力を活かしたいと言えば、海外シェアの高い優良中小企業なら即海外営業担当になれるかもしれない。そこで自信がないと言うようではチャンスは巡ってこない。ただし、給料は安いかもしれないし、もしかしたらブラック企業かもしれない。それが中小企業のリスクだ。

どっちのリスクを取るのかだ。もしも、今自分が就活する学生なら、絶対に大企業のリスクは選択しない。ブラックでない将来性の高い中小企業を探して就職し、やりたいことを思いっきりやって、スキルが徹底的に伸ばし、もしも、その会社の器をはみ出しそうになるくらい成長したら、その実績を引っさげて別の会社に転職する。

討論会の中で悲痛の叫びを口にする学生さん達を見ていて思うのは、彼らは完全に「就職できないかも知れない」という恐怖におびえているということだ。そして、その恐怖を振り払うための方策として、受験勉強で使った方法を使おうとしている。

つまり、中学二年の間に中学三年生までの教科を終わらせて、中学三年生の期間は受験対策をする。大学1,2年から就職活動を開始し、4年生になったら面接のための塾に通ったりする。ようするに高校、大学の難関校を受けるときの戦略そのままだ。

企業には偏差値は付いていないから、よくコマーシャルや全国ニュースに出てくる大企業がいい会社だと考える。

この戦略の大きな間違いは、皆が同じ土俵で闘おうとしている点だと思う。共通テストや私立大学の入学試験は公正を期すために、できるだけ同じ土俵で学生達を闘わせようとしているが、企業は別に同じ土俵で闘う必要はないし、同じでないからこそ生き残れる世界もたくさんある。それなのに自ら競争相手の多い土俵に登りたがる心理が自分には理解できない。

一つは他の人が着目していないような優良な土俵を探すこと、つぎにその土俵で自分が勝つためには何をしなければいけないのかを考えることだ。どちらもひとと同じことをしていたらダメで、ひとがしていないことで自分のやりたいこととのオーバーラップを探す必要がある。日本ではそういう訓練はしてこなかったのだろう。

一昔前は大学への進学率は10～20%。今では50%を越えている。昔は、大学は学問を学びたい者が行っていたのだが、今では大学は限られた若者がいくところではなくなっており、彼らを全部就職させるためには職業訓練的なこともしなければいけないというVTRがあった。

これに対して、大学がアカデミズムの立場を崩すのはよくないという意見があったが、東京大学大学院教授　ロバート・キャンベル氏が、どんな分野であれ、学び、議論し、改善を模索するという行為を大学で学び取ることができればムダではないと言っていた。自分はロバート・キャンベルさんの言うことが好きだ。50%が大学へ進学する時代なら、アカデミズムもあり、職業訓練もありにしなければ結局は不幸な学生がでてくる。

大学では何でもいいから勉強する対象を通して、深く掘り下げて考え、分析したり、理論を打ち立てたり、問題を解決する力を養って欲しい。

そして、変えなければいけないのは学生と親が持つ価値感だ。働くことの意味はなんだ？ みんなが知っている安定した企業に就職することか？

20世紀の時代には大企業=安定の式はなりたったかもしれないが、21世紀ではまったく信用できないし、大企業のリスクも存在する。

「みんなと同じ」=「安心」「仲間はずれにならない」

という価値感はそろそろ捨てよう。親は子供に「友達と同じことをするな」「自分だけのオリジナリティを磨け」と言おう。みんなが黒のスーツを着ていたら、自分だけはグレーにしてみなさい。「なぜ、君はグレーのスーツなのか？」と聞かれたらラッキーじゃないか。

ひとと違うことを突き詰めるのは「自分にはムリ」と言うのならば、職業訓練をしよう。学生のうちに、企業が興味を持つ分野のエキスパートになってしまおう。それが自分の好きなことと一致していればそれに越したことはないが、絶対にイヤだというわけではないのなら、何かの道を選んで一流と言われるまでスキルを高めてみたらいい。

『日本の、これから「就職難をぶっとばせ！」』を全部見て一番バカだと思ったのは、世界のトップシェアの中小企業に内定をもらっていながら入社を辞退した学生とその親だ。

本当にその親の顔を見てみたいし、「聞いたことがない会社だから」という理由で断った学生も親も親なら子も子なのだろう。

番組キャスターの三宅さんも言っていたがこの問題は就活学生だけの問題ではない、今一度我々は自分自身に「何のために働いているのか」という疑問を問い掛けてみる必要がある。

そして、その答えと今の社会のシステムにズレがあるのなら、未来の日本をしょって立つ若い人たちのために変える行動をしなければいけない。批判したり、評論したりするだけではだめだ。何かしらの行動をしなければいけない。

行動できなければ、それはひかれたレールから降りられないということだからだ。だれもレールから降りないのなら、さびれたレールは残り続け乗客はいなくなり廃線になるだけだ。

さしあたり、自分ができるのは学生向けにこのブログを通して情報を発信して「みんなと同じ」症候群から脱出する方法を授けることかな。

人財と人罪

あるセミナーでおもしろい図を見た。「じんざい」を四つの象限で表した図だ。縦軸はモチベーション、横軸はスキル。

1. モチベーションが高く、スキルもある場合は組織の財産という意味で人財
2. スキルは高いが、モチベーションが低い場合は単なる材料という意味で人材
3. モチベーションは高いがスキルが低い場合は、居るだけだから人在
4. モチベーションも低く、スキルもない場合は居るだけで罪だから人罪

もう一つの図。会社がリストラの必要性に迫られたときに、誰を残すかという指標。縦軸はビジョンを共有。横軸は仕事ができる。

1. 組織とビジョンを共有し、仕事ができる社員は残す。
2. ビジョンを共有できているが仕事はできない社員も残す。
3. 仕事ができるがビジョンが共有できない者は会社を滅ぼす。
4. ビジョンも共有できず、仕事もできない者は不要。

【楽に生きていきたいと思っていると楽に生きていけないというロジック】

1. 楽に生きていきたい
2. 責任を負いたくない
3. 会社・相手に責任を転嫁する
4. 信用が落ちていく

1. 楽に生きていきたい
2. 面倒は避けたい
3. 処理が遅れる
4. 信用が落ちていく

1. 楽に生きていきたい
2. チャレンジする意欲はない
3. やれることしかやらない
4. 信用が落ちていく

1. 楽に生きていきたい
2. 自分の利益が最優先
3. 他は利用すべきもの
4. 信用が落ちていく

結果として楽に生きていけない。依存型の人間にどのようなよい仕組みを与えても、依存型は依存型としてこれを利用する。

【自立型人材のモデル】

1. 自分を活かして充実して生きていきたい
2. 率先して取り組む
3. 責任は自分が取る
4. 自分への信用が増す

1. 自分を活かして充実して生きていきたい
2. 面倒なことから逃げない
3. 処理が早い
4. 自分への信用が増す

1. 自分を活かして充実して生きていきたい
2. チェレンジしたい
3. 自ら新たな状況を作る
4. 自分への信用が増す

自分への信用が増すことにより、楽しく充実した人生が送れる。

【コンピテンシーモデル】

職能資格制度の欠陥を払拭するために高業績者の成果達成の行動特性（業績・成果と連動した顕在的能力）を重視したコンピテンシーモデルが有効である。

タワーズ・ペリン社のコンピテンシー ※1

1. コミュニケーション
2. チームワーク
3. 顧客志向性
4. 成果達成志向
5. 革新性/創造性
6. ビジネス感応性
7. リーダーシップ
8. 自身及び他者の能力開発/育成
9. 意志決定
10. 順応性/柔軟性
11. 問題解決

※1 コンピテンシーの定義の例　「継続的にその職務に求められる達成すべき最終成果責任を生み出すための効果的な行動を選択し、実際に行動に結びつけるという行動にフォーカスした能力で、しかも顕在的で他社から観察しうる行動レベルでの発揮能力」

【達成動機が強い人には成果に対するフィードバックを示すべし】

達成動機の強い人は成功報酬よりも個人的な達成感に関心を示すとともに、難しい問題に取り組んだり、解決すること自体に関心を示す。達成動機の強い人は自分たちの成果に対して具体的なフィードバックを求めることを強調している。

これは同感。解決すべき問題が部門間にまたがっているような場合、ルールやプロセスの変更が素早く承認されると達成感、満足感が生まれる。

ここまでの話し、どう考えても義務教育の学校では教えていないことばかりのような気がする。教えていないところか、正反対の依存型の人材を一生懸命作ろうとしていないだろうか？

改めて問題の根（依存型の社会人が多いという現状）は深いように思った。

問題解決の方法を100パターン作っておかないと動けない人材

今、組織が欲しい人材は、目的を示すことで自分の持ち駒（経験）を組み合わせて実現する方法を見つけ出すことができる人だ。

その対極に具体的な手順を示さないと動けない人がいる。例えば、目的はひとつ、工程が2つあって、それぞれの工程内での活動の選選択肢が10パターンずつあったら、サンプルのパターンを一つか二つ例示するのではだめで、今自分が置かれている立場にぴったり合う10×10=100のパターンの中から最も近い一つを示せと言われてしまうケースだ。

その程度はまちまちで、いくつかのケーススタディをするだけで済む場合もあれば、手取り足取り手順を示さないと動けない場合もある。

問題解決能力が高い人は、経験値が低くても工程を何回か繰り返すうちに具体的な手順から抽象度の高い解決方法を体系化することができる。

だから、組織は問題解決能力の高い人材が欲しい。

【1. 問題解決能力を身に付ける方法】

1. 達成すべき目的や要求を伝え「なぜ」も含めて合意する
2. 集中できる環境だけ用意して解決方法は示さない
3. 定期的に進捗を報告させてアドバイスを与える
4. 成果を当事者以外（一番いいのは要求を出した人）に評価してもらう
5. 2～4を何周か繰り返す

※たぶん、これがよく言う PBL(Project Based Learning/Problem Based Learning）なのだろう。

【2. 問題解決能力の低い人の学習環境（予想）】

1. 問題が指定される
2. 解決するために必要とされる一般的な知識を教わる
3. 試しに一つの解決方法を教わる
4. 複数の問題を解かせる
5. 採点して落第だった場合は補習をする

※この学習方法で訓練されると、そのパターンで解けない問題がくると最初から解けないと「問題」と「ソリューション」は一対一だと決めつけられてしまい、ぴったりくる解決方法が記憶の引き出しにないとさじを投げられてしまう。

問題解決能力があるかないかを判断するには、答えのない問題を実際に解決してみてもらえばすぐに分かる。

2の学習方法しかやってこなかった人は比較的早くあきらめて、解決方法を教えてもらえるまで指示を待つ。1の訓練を受けている人は、少なくとも解決方法の提案をレビューしてくれといってくる。自信があるものは問題解決に着手する。

Process （工程）を Activity （活動）や Task（仕事）に分解して Procedure（手順）に落とし込むというアプローチは問題解決能力が低い人にも成果を期待できる反面、不測の事態への対応が十分にできない。手順になれてしまうと、手順から逸脱する行為は悪と見なされる。

同じ品質のものを効率的に生産しなければいけない工場の生産ラインはこの方法でよい。製品ごとに手順は変わるので、工場の中でも手順を作る側の人は問題解決能力が高くないといけない。

商品を作る側の技術者は、新しいものを創造するのだから、不測の事態への対応能力は高くないとまずい。ただ、もしかすると要求仕様が固まった後のコーディングだけを行うプログラマの場合は、手順通りに手を動かしていればいいのかもしれないが、一生その仕事ではたまらないだろう。

技術者はProcess （工程）を、分解された Activity （活動）や Task（仕事）を Procedure（手順）に従って開発を進めることが求められる一方で、不測の事態、変化しなければいけない状況下では、Process や Activity, Task を柔軟に変更できる能力も求められている。

P.S.

日本の組織では「強くお願い」と「強制」の垣根がないと思うことがしばしばある。「強制」とはそれに従わなければクビということだが、日本の組織ではそれはないし、「ヤレ」と言われてやらないで、何もとがめられないこともある。それが「あたたかい人間関係の中のやさしい一員」という特性だ。

そういう環境下では「強くお願い」と「強制」の垣根がないので、権限がなくても「強くお願い」すれば、それを義務ととらえる者が多い。「何の権限があってそんなことを要求するのか」なんてことを言う人を見たことがない。

たぶん、普段から自分の責務もあいまいしているから、それを言ってしまうと自分に返ってきてしまうからだろう。

責任と権限が曖昧な日本の組織では頭ごなしに「強制」するのではなく、徹底的に「強くお願い」するのが効果的だと感じる。どっちもやることは同じなんだけどね。

ようするに誰かに言われて動いたという形になっていた方が安心して行動できるということ。（それって責任回避の心理？）

エンジニアに投資しない組織にいて成長するには

エンジニアに投資しない、投資できない、投資する必要があると考えない組織はそこら中にある。技術者への投資がどのように組織にフィードバックされるのか、人材を育てることに金や労力を使わないと組織がどのようにやせ細ってしまうのかイメージできない人に技術者への投資を提案するとそれにかけた費用に対する効果を説明せよと言われる。そこで「分かってないな」と思うのは当然だが、だからといってエンジニアへの投資をあきらめてはいけない。

ソフトウェアエンジニアは100%知識労働者である。「プログラムコードを何行書いてなんぼ」などと考えていると、すぐに優秀なコンパイラやツールに仕事を奪われてしまう。新しく入っている若い世代のソフトウェアエンジニアが持っていないスキルを常に身につけていかなければいつの日か組織からいらないと言われる日がくる。

組織の中で誰からも計画的なスキルアップの道筋を提示されないエンジニアは辛いが、心配しなくてもいい。ほとんどの技術者がそんなものだ。小・中・高・大おまけに塾では手取足取り何を勉強すればいいのか、次は何に取り組めばいいのか、四六時中先生や親がかまってくれたが、社会人になるとそのようなケアは激減する。そのような環境に計16年もいれは、社会人になっても新人教育のアンケートで「もっと教育を提供してください」「まだまだ教育が足りません」と書いてくるのもうなづける。新入社員研修が終われば、ほとんどの組織では後はOJTで何とかしろと突き放される。ソフトウェアは周りから何やっているのか見えないから、自分で「ここが分かりません」とか「ここはどうやったらいいのでしょう」などと積極的に聞いていかないと、「どれどれ苦労しているようだね」と誰かが声をかけてくれる確率は低い。そして、どんなに未熟な技術者でも何百回も試行錯誤でプログラムをいじくり回していればいずれ動くようになる。実は、それが一番怖い。中身ぐちゃぐちゃで、すべてのテストケースを検証しておらず、爆弾入りのプログラムがひっそりとソフトウェアシステムの中にビルトインされてしまうのだ。

新人の時期を過ぎればソフトウェアエンジニアは教育という側面から見れば孤独だ。それまでの人生と比べてその突き放され感にショックを受ける者もいるだろう。

技術者教育を計画できない、実施できない自転車操業の組織にいて、それは自分が悪いのではなく組織が悪いのだと考えるのは簡単だが、残念ながらそのままほおっておいても何も変わらない。学校や塾のように成績が悪くなると家庭教師を付けてくれたり、「もっと勉強しろ」と尻を叩いてはくれない。ETSSというスキルのものさしでエンジニアのレベルを計測し、それによって弱いところをトレーニングするという取り組みは始まっているが、それができるのはエンジニアに投資できる組織であり、今回と前回の記事の対象外としている。（これを実行するには人・モノ・金がいるから大企業で儲かっていないと難しい）

技術者に投資しない、投資できない組織はたくさんある。そのような組織の中で技術者が何もしないでいると、ソフトウェアに依存する組織の業績はじりじりと下がり技術者に過度な負担がかかるようになる。このような状況でも組織が生きながらえていられるのは次のような原因があると考えられる。

1. ソフトウェアエンジニアの需要が供給を上回っている。（不景気な今もそうだろうか？）
   
2. その組織、そのプロジェクト、その技術者しか知らない、対応できないドメイン知識を持っているから切られる心配がない。（組込みの世界ではよくある話し）
3. 過度な負担（例えば残業月100時間以上とか）に対して技術者がまだ耐えられるレベルにある。

1と3は放っておけばいつかは破綻するときが来る。問題は2だ。2は実際かなりのアドバンテージであり、曖昧な仕様でしか仕事を出せない組織では特に特定の技術者に蓄積されたドメイン知識や経験は重要であり、このような人に頼った製品開発が行われことは多い。しかしながら、そのアドバンテージは永遠には続かない。

製品に使用されるハードウェアデバイスの使いこなし方や商品にまつわるドメイン知識だけで生きながらえているソフトウェアエンジニアは、大規模ソフトウェアシステムを効率的かつ品質高く開発する技術を持ち合わせていないから、いつの日か破綻するときがくる。ドメイン知識と試行錯誤のアプローチで開発できるソフトウェアシステムの規模はだいたい決まっている。自分の経験では実行コード行数で30万行を超えてくると、何かしらのソフトウェアエンジニアリングの技術を使わないと品質を確保できなくなってくる。

よって、どのようなソフトウェアを作っていたとしても、いずれはソフトウェアに関する設計、検証の技術は身につけなければソフトウェアエンジニアに明日はない。日本で今若い人たちがソフトウェア開発技術者に魅力を感じられないのは、自転車操業の組織で試行錯誤のアプローチでしか仕事をしておらずどんどん疲弊していく技術者の噂を耳にするからだろう。

前置きが長くたっぷりと危機感をあおってしまったので、ここからはエンジニアに投資しない組織いて、スキルアップの方策を組織に期待できない場合、どうやって自己投資すればいいのかを考えていきたい。

1. 仕事の中で鍛える

多くの組織がこれ（要するにOJT：On the Job Trainning)で技術者は成長すべきだと考えている。大工の棟梁が弟子を一人前にするという徒弟制度をイメージしてもらえばよい。20年前の組込み機器開発は、メカもエレキもソフトもそうやって技術者は成長してきたし、その経験をしたエンジニアが組織の中でプロジェクトリーダーやプロダクトマネージャや技術部長になっているのだから、そう考えるのは当然といえば当然だろう。

しかし、21世紀の組込み開発において、特にソフトウェア開発において、20年前の徒弟制度的な棟梁と弟子の関係が組織のあちこちで成り立っているだろうか。エンジニアに手取足取り技術を伝承する時間や機会を組織は先輩技術者に与えているだろうか。今ではかなりの割合を占める協力会社のソフトウェア技術者に仕事を丸投げし技術伝承の流れを切ってしまってはいないだろうか。

実際、組織内で伝承するソフトウェア技術が減っている感覚がある。ソフトウェアの世界ではいつの日か技術は伝承するものではなく、技術者が自分で修得するものになってしまったような気がする。

ただ、一部の技術者は自分の仕事の体験から、どうすればうまくいくか、どうすれば失敗しないかという法則を体系化している組織、プロジェクトもある。まったくのゼロからでなくても、書籍や雑誌、友人からのちょっとしたヒントにより有効な方法論を確立できる技術者がわずかながらいる。このように具体的な事象から抽象的な法則（例えば、設計の規範となるコーディングルールの策定や、ソフトウェアシステムをブロック図で表現することなど）を編み出すことのできる技術者はそんなに多くはないがいると思う。こういう改善の気質がある技術者はできるだけ組織の外にもアンテナを張っておいた方が効率がいい。

上記の例では、設計の規範なるコーディングルールのヒントはIPA SEC が副読本としてまとめたものがあるし、ソフトウェアシステムの概観を表す方法としては、構造化分析手法におけるDFDや、オブジェクト指向設計で利用するUMLなどの表記法、ツールがすでに存在している。これらの表記法や分析・設計の方法論は先人が自分たちの経験をもとに構築し、多くの技術者に支持されたものだから、それらに乗っかる、もしくは自組織向けにテーラリングすると、ゼロから構築するよりも早い。

自己投資の必要性を認識したソフトウェアエンジニアが、自己投資の結果をすぐに自分の仕事に結びつけることができればこれに超したことはない。すでにスキルを身につけている先輩や社員が近くにいるのならこれほどラッキーなことはない。スッポンのようにくっついていろいろ教えてもらい技術を盗めばよい。資金がなくても「ありがとうございます」の感謝のことばだけで自己投資できる。「あたたかい人間関係の中のやさしい一員」という特長を持つ日本人の中では、教えを請えば見返りを要求されることなく喜んでいろいろ教えてくれるはずだ。教えた相手がスキルアップしても給料に差が付くようなことはないから安心して技術を教えてくれる。

ちなみに、そのような学ぶべきスキルを持った技術者が近くに見あたらないときは、以降に書く2や3で知識を仕入れて、今の自分の開発に一番役立ちそうなものを上手にピックアップして試してみることが必要になる。このとき、何を持って試してみるかという選択の目がどれだけ肥えているかどうかが成功のカギとなる。ただ、どんなに優れた目利きでも失敗を繰り返して経験を重ねていくので、最初は小さい成功と失敗を積み重ねるように心がけるとよいと思う。いきなり大上段に構えて、高度なことに挑戦するのはやめた方がよいだろう。

2. 本

もっともポピュラーな自己投資の方法は、本や雑誌を読むことだ。ここでは2つだけアドバイスを書いておきたい。一つ目は、問題解決のために買う本や雑誌は同じ分野の違う視点の本を2冊以上用意するということ。ソフトウェア工学は自然科学とは違うので一つの方法が普遍的にどの開発にもどの時代でも効果があるとは限らない。そのことを忘れずに、実際の問題解決に適用する際の可能性の幅を広げる意味でも同じテーマに対して別々の視点があることを認識することは重要だと思う。一冊本命の本を買って、もう一冊は図書館で借りるというのもよいかもしれない。

二つ目は、本や雑誌に書いてあることを、どんな形でもいいから必ず自分の仕事の中で使ってみるということだ。これをしないのなら自己投資ではなく、単なる読書だと思った方がいい。問題解決のために本や雑誌を使わないのなら自己投資の意味がない。流行の手法が解説されている本や雑誌を読んだだけなら、それは単なる自己満足に過ぎない。「○○について書かれた本を読んているのはウチの中では自分くらいだろう」などと思っているだけでは何も解決しない。評論家くんにはなれても問題解決キッズにはなれない。（『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事参照）

本や雑誌を買う行為を常日頃、自分が抱えている問題を解決するための自己投資だと考えているとだんだん目が肥えてきて、自分にとって使えない本や雑誌には手を出さなくなる。無駄な投資が減る。仮に購入した本を参考に自分の仕事に適用してうまくいかなかったら投資に失敗したと考えれば、次回は同じ失敗を繰り返さないようになる。本や雑誌の購入が自分に向けての大切な自己投資だと考えていると、投資に成功したときの本と失敗したときの本の違いが見えてくるはずだ。

本や雑誌の書き手側からすると、そういう読者が増えるとライター側もどんどん淘汰されてスキルが上がっていくので、読み手と書き手の両方が切磋琢磨して成長できるのだ。（消費者の目が厳しい市場では技術が成長する）

3. コミュニティに参加する

1で自分の身の回りに高いスキルを持った人がいないときは、自分が抱える問題を共有しているであろう人が集まっているコミュニティを探して、そこに積極的に参加するのも手だ。その中に解決する手段を知っている、解決した実績を持っている人がいる確率が高い。

時間がなかな取れない上に余計な仕事をもらってしまうのがイヤとか、どんな人がいるのか分からないから恐いとか、自組織が認めてくれないという理由で尻込みしているのなら、コミュニティへの参加は自己投資だと考えればよい。2と同じで自己投資にならないと分かったら、あまり迷わずにコミュニティを去ればいい。コミュニティは無理に留まる義務はないところが会社組織とは異なる。

ただ、遊びの集まりではないから、何かしらのタスク、ミッションはこなす必要がある。それらが、自分自身の仕事や問題解決に少しでも役立つと思うのならポジティブにこなしていけば必ずスキルアップにつながる。

例えば、自分はSESSAMEで、WEBサイトの構築を買って出たり、ワークショップのレポートを書いたり、e-Learning コンテンツを開発したりして、結果的にそれらを訓練することになり技術が身についた。一見ソフトウェア開発にはまったく関係ないような事ばかりだが、自組織においてそれらの技術はとても役立っている。

座談会や講演を録音したテープを文字に起こすような作業は誰もがやりたくないと思うかもしれないが、その内容に興味があったり、自分の勉強のネタだったりすると繰り返し聞くことで話している内容が頭の中に刻みこまれていく。

下働きみたいな仕事でも、その中から何か役に立つものを盗んでやろうという目を持っていると、決してその時間は無駄にはならないのである。

さてこれまで紹介した1,2,3の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。

でも少ない自己投資でスキルアップという効果を得る醍醐味を一度味わうことができると、問題解決のスキルはどんどん上がる。問題解決のスキルが上がると、自分の仕事を効率化したり、品質を高めたり、より評価の高い組織に移籍するなどいろいろな選択肢を選べるようになる。

自分に取ってどんな自己投資が効果的かこれを期に考えてみて欲しい。

　

人と人をつなぎまくると物事はスムーズに流れる

今日の話題は、『人と人をつなぎまくると物事はスムーズに流れる』というテーマで、「あたたかい人間関係の中のやさしい一員」という特性を持った日本人が形だけ「創造性と個性にあふれた強い個人」のシステムを使おうとするとどうなるかという一例を紹介したい。

さて、今日「TBSラジオの久米宏　ラジオなんですけど」を聞いていたら、大分トリニータの社長 溝畑宏さんがゲストに来ていて、大分トリニータがナビスコカップで優勝を遂げ、地元に定着して地域振興に貢献するようになるまでの苦労と、サッカーチームをベースにして地域振興にかける溝畑さんの熱い想いを語っていた。

溝畑さんは、東京大学法学部卒、１９８５年自治省（現総務省）入省、１９９０年大分県に出向して、役人らしからぬ強い思いで大分をサッカーで盛り上げようと考える人だ。2006年に総務省を退職して、大分トリニータの社長として身を粉にしてチームと地域のために働いている。

お父様は溝畑茂　京都大学名誉教授、お母様は放送局のアナウンサーだったそうだ。父からは「厳しい道と楽な道があったら、厳しい道を選べ」と言われ、母からは「下を向かずに上を見て目立ちなさい」と言われて育った。

若干30代中盤の溝畑さんが大分で大分トリニータの設立等を進めているときに、県のお偉いさんたちに「溝畑さん、田舎では身の丈以上のことをしようと思ったらダメなんですよ」と言われカチンときて「あんた達の身の丈はこれくらい(20センチくらい）かも知れないが、自分の身の丈はこれくらい(2メートルくらい）なんだ。そんな考えだから、地方が活性化しないんだ。」と叫んだそうだ。

その後の溝畑さんの活躍を見れば分かるように、溝畑さんは「あたたかい人間関係の中のやさしい一員」という特性を持った日本人の環境の中で、親から教えられた「創造性と個性にあふれた強い個人」のとしてのリーダーシップを発揮することで、閉塞した環境をブレークスルーしたと考えられる。

今、まさに不況のまっただ中でプロサッカーチームを運営するのは非常に苦しいらしい。しかし、溝畑さんは「逆境よ、ようこそ」という気持ちで、人の3倍働くことで乗り越えるつもりだと語っていた。これまでも7回ほど、もうダメだという逆境があったが、それを乗り越えることで成長してきたと言う。逆境がなければこれほど成長もしなかったと。

今回の話しは、溝畑さんの話に比べるととてもスケールの小さいちっぽけな話しだが、本質は近いところがあるように思う。組織内で問題解決のためのシステムがうまく機能せず、人と人をつなぎまくって問題を解決したという話しである。「創造性と個性にあふれた強い個人」の世界で構築されたシステムを「あたたかい人間関係の中のやさしい一員」が導入しただけでは物事は流れていかないという例だ。

さて、例えば、ある組織で組織内のインフラをサポートするための部署を作ったとする。ITが発達した今日、対外的なITサポートも増加する一方、組織内のITサポートも個々の担当者レベルでは対応しきれなくなってきた。

そこで、ITサポート部隊は会社対会社で行われているようにサポート窓口（電子的な窓口）を作って、そこからいろいろなリクエストを受け付け対応するようにした。昔なら依頼書で動くところを、電子的な申し込みに対して、電子的に回答をするというシステムだ。やりとりの履歴がすべて残るので後々データを整理したりする際には便利である。

そこで、ITインフラを担当する部門に動いてもらわないと解決しない問題が発生した。いろいろな問題が絡み合っているのは分かっているが、残念ながら担当部門の中で誰が何の役割を担っているのか分からない。普段なら問題の解決についての情報を知っている人にあたりを付けて、そこにアクセスしながら情報を探り全体像を明らかにしていくのだが、今回に限って言えば誰にアクセスすればいいのか今ひとつ見えてこない。そこで、電子的なサポート窓口を使って調査依頼を出した。

後で分かったのだが、担当部門には複数のチーム（例えばAチーム、Bチーム、Cチーム）があり、今回の問題はBチームとCチームが動かないと解決できない問題だった。ところが問い合わせを受けたAチームは解決すべき問題の全容を理解していないため、BチームとCチームに相談することをせず、部門内でも電子システムをメッセンジャーとして使い、解決したい目的を理解せずに現象だけをBチームやCチーム別々に伝え、埒があかないという現象が発生した。

相手がブラックボックスの組織ならどうしようもないが、同一組織内の他部門ならもっとなんとか打つ手はあるはずだ。結局、いろいろなことを聞きまくることで、BチームとCチームが問題解決に関係していることがわかり、彼らに直面している障害を伝え協力してもらうことで問題は解決するめどが立った。

実は、この件は自分自身の直接的な業務の問題ではなかった。ある開発現場の効率を高めるために取り除く必要がある障害だった。当事者ができないことを解決する方法が分からなくてあきらめているのをみて、コーディネートしたのだ。「あたたかい人間関係の中のやさしい一員」の技術者は自分達の不便は自分達が我慢することで何とかなると考える人たちが大勢いる。「あたたかい人間関係の中のやさしい一員」のマイナス面だ。顧客満足向上という遠くの目標達成のために、取り除くべき障害があっても、そのままにして効率の悪い状態を放置してしまうのだ。こういう状況は放置しておくと巡り巡って技術者自身の残業の増加や顧客に対するコストアップなどの不利益となって降りかかってくる。結果的に不利益が生じることをはっきり認識している訳ではないので未必の故意(※)とは言えないかもしれないが、決してほめられたことではない。

※未必の故意 - 実害の発生を積極的に希望ないしは意図するものではないが、自分の行為により結果として実害が発生してもかまわないという行為者の心理状態。

このような各部門の各技術者が抱えているちょっとしたあきらめを見つけて、誰がどこまでを認識していて何を認識していないのか、誰と誰を結びつけると解決しそうかを調査して、関係者が断片的に持っている情報を総合的に分析して人と人をつないであげると物事がスムーズに流れ改善が進む。

誰と誰をつなぎ合わせると問題を解決できるのか分かってくると、逆にどうしてこんな簡単なことで多くのことが滞っているのか、改善の機会を止めてしまっているのかが見えてきて、そんなくだらないことで立ち止まっているのかとだんだんバカバカしくなってくる。

同じ部門内の中でちょっとだけ話しをすれば解決できる問題も、システムを通すとつなぎがうまくいかなくなることがある。これはシステムを都合良く利用しながら、システムを隠れ蓑にして問題解決の勇気や義務を放棄して「あたたかい人間関係の中のやさしい一員」の特長を殺している人間がいるからなのだ。

システムが組織内でうまく機能しない場合は、うまく言っていない点を報告し是正を要求する。これを繰り返すことで、システムは生き続けることができる。改善のプロセスが重要視されているのはそのためだ。逆に言えば、改善のプロセスを回すことができない組織がシステムを導入するとシステムは必ず形骸化する。システムの裏で技術者は「あれは役に立たない」とささやきながら、自分達のやり方で物事を進めようとする。

「創造性と個性にあふれた強い個人」の世界では責務を果たしていない個人や部門があることが分かったら、状況を発見した個人や部門には是正を要求する義務がある。是正を要求しなければ改善は進まないというシステムなのだ。それを理解していない組織はシステムを形骸化させる。

何からしらの「システム」を導入して、なぜうまくいかないのだろうと悩んでいる方がいたら、「あいつらが自分達の責務を果たしていないから」と愚痴を言っているのではなく、是正を要求しないとシステムの本来の効果が活きてこないし、放っておくとシステムが腐ってくる。

システムを改善していくのもいいが、日本人の「あたたかい人間関係の中のやさしい一員」という特長を活かすのなら、まずは人と人とをつなぐことで問題を解決することを推奨したい。単に人と人をつなぐだけでなく、AさんとBさんがいがみ合っている場合は双方に「あちらは、こちらがこんな事をしてくれるととても助かる、いつも感謝しているといっていましたよ」などと言うと流れがよくなることがある。「あたたかい人間関係の中のやさしい一員」の世界では是正を要求するよりも、問題解決に必要な人と人をつなぐ方が改善が進むスピードが速いことが多い。

「あたたかい人間関係の中のやさしい一員」の特性を活かして、物事を滞らせている原因を探偵になったつもりでヒアリングにより調査し、人と人とつなぎまくることで情報の流れをよくし問題を解決する。これがうまくいくと、うまく行かなかった原因がいかにバカバカしい小さなことであるかがわかり、「あたたかい人間関係の中のやさしい一員」の世界で必要なリーダーシップとは何かが見えてくる。コーチングとかティーチングといったテクニックではなく、当事者達とコーディネータとなる自分という関係性の中で、どの情報を誰にどうやって伝えれば問題解決するのか、ケースバイケースで最善策を考える。

「あたたかい人間関係の中のやさしい一員」の世界の中で人と人とつなぎまくることで、問題が解決されると、つなぎまくって問題を解決した人はそれまで困っていた人たちに感謝される筈だ。セクショナリズムが蔓延し、たこつぼ状態になっている組織では、コーディネータの役割を担おうと立ち上がった者が「これは自分の仕事ではない」とか「自分が動くとバカを見る」と思ってしまうと組織の硬直化はますます進んでしまう。

そうなると、コーディネータのエネルギー源は、困っている人の問題が解決したときの当事者からの感謝の言葉や、顧客満足を高めることができたときの満足感でしかないのだ。コーディネイトすることで問題解決を請け負っている人はコーディネイト成功の感謝の気持ちを対価に置き換えることができるが、組織内の場合はお金は動かないから感謝の気持ちを糧にするしかない。

「人と人をつなぎまくると物事はスムーズに流れる」、これは「あたたかい人間関係の中のやさしい一員」の世界だからこそ有効なアプローチだと感じる。逆に「人と人をつなぎまくると物事はスムーズに流れる」が通りにくい組織は黄色信号が点っていると考えた方がいいだろう。日本では人と人をつなぐ心やその役目を担う人がいないとせっかく導入したシステムもいずれは死んでしまう。死んでしまったシステムの利用者達にヒアリングして調査すればセクショナリズムやたこつぼ化が組織に蔓延しているのがわかるはずだ。

PS.

「創造性と個性にあふれた強い個人」と「あたたかい人間関係の中のやさしい一員」の元ネタを知りたい方はこちらの記事をお読みください。

　

技術伝承の鎖が切れてしまった組込みソフト開発の現場

製造業における技術伝承は、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続けるというものだ。

一方でマニュアルを使って一律に技術習得させるという方法もある。マクドナルドがよい例だ。マクドナルドはマニュアルによる指導、トレーニングを徹底させるために世界のどこのマクドナルドに行っても同じレベルのサービスを受けることができる。これはまさに欧米的な技術の習得方法だと感じる。

日本でも工場では手順書による作業指示があるので、マクドナルドのマネージメントと似ているように見えるが、QC活動などでマニュアルを逸脱した独自のくふうも許しているところがちょっと違う。逆に言えば、一応手順書やマニュアルはあるものの、実際には冒頭で紹介したベテランが初心者に対して技術を習得できるまで指導し、その指導の方が手順書よりも優先されることが多い。

トレーニングの方法として学校でスキルを身につけるというやり方もある。料理学校などは、料理を作る行為自体は学校でやることも、実際に就職した先の店でやることも基本的には同じだから、料理学校で受けたトレーニングは即現場で役立つ。

さて、それでは、ソフトウェアの開発技術はどうだろうか。日本の多くの学校ではソフトウェア工学を現場で使いこなせるまで指導できるところは非常に少ない。先生の中には実際の現場でソフトウェアを作った経験がある人が少ないこともあるし、昔ソフトウェアを搭載した製品を作ったことがある人でも、現役を離れてから10年もたつとソフトウェア開発の方法論自体が変わってしまうこともある。

そこで、先人が成功と失敗から体系化したソフトウェア工学を日本のソフトウェアエンジニアが修得する5つの方法について考えてみる。

【日本のソフトウェアエンジニアがソフトウェア工学を修得する方法】

1. 雑誌、書籍、学会、シンポジウム等の情報から学ぶ（独学）
2. 学校やセミナーで学ぶ
3. 組織内で上司や先輩から学ぶ
4. コミュニティの知り合った友人から学ぶ
5. コンサルタントから学ぶ

この5つの方法をいずれか、単独、もしくは組み合わせでスキル修得して現場に適用できる技術者は実際にはほんの少ししかいない。今回の記事は「それは何故か？」の分析である。

【「雑誌、書籍、学会、シンポジウム等の情報から学ぶ（独学）」と「学校や、セミナーで学ぶ」が難しい理由】

日本のソフトウェア開発の現場は方法論を自分達の案件でやって見せてあげないとできるようにならない。自分達だけで、抽象化された方法論を自分達の問題にテーラリングして取り込むことができるプロジェクトはほんのひとにぎりしかない。なぜなら、製造業における技術伝承は、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続ける方法であり、自分一人ではそれができないからだ。

別な言い方をすると、日本のソフトウェア技術者は抽象化された方法論を自分自身の具体的な問題に展開する能力が低い。なぜ、低いのかというとそういうトレーニングを受けてこなかったからだ。『問題解決能力（Problem Solving Skill)：自ら考え行動する力』の記事参照のこと。もう少し、正確に言えば公式に具体的な数値を代入することはできるが、公式よりももっと抽象度の高い方法論になってしまうと、目の前に具体的な問題がころがっていても、何をどう当てはめていいのかわからないし、何となくわかったとしても、失敗するのが恐く、試してみる勇気がないので、問題解決の経験値が上がらない。現場の技術者が失敗に対して恐れを感じているというのを最近特に強く感じる。おそらくプロジェクトに余裕がなくなって失敗を許さない雰囲気があるのだろう。

だから、問題解決の経験値が上がらない技術者は本や雑誌を読んでも、セミナーに行っても、学会に行っても、シンポジウムに参加しても、そこで示されている抽象化された方法論を現場に展開することができない。まれに、それがうまくいくケースは二つあって、よっぽど分かりやすい手順が示されている場合と、よっぽどその人の気持ちを揺り動かすことができて試してみる勇気がわいたときだけだ。ただ、前者の分かりやすい手順というのは、逆に言えば少しでも問題の対象にマッチしないところがあると先に進めないというデメリットがある。2つのめの気持ちを揺り動かすという方法は、「時間がない」とか「周りが賛同しない」とか「予算が付かない」などさまざまなハードルが現場にはあるので、気持ちを揺り動かすことができても時間がたつと急速にやる気が萎えてしまう場合もある。

このような理由から残念ながら独学で問題を解決できるところまで持って行ける技術者は非常に少ない。逆に言うとそういう人は希少価値であるため、いずれ自分自身の存在が希少であることに気づき、その価値を最大限活かすために独立したりコンサルタントになったりする。

※宗教的な熱狂に周りを巻き込むことで問題を成功に導く方法もあるが、本来ならば行動の目的や自分達のあるべき姿を見据えた上で、熱狂的ではなく静かな闘志を燃して事にあたるようにしたいものだ。

【「組織内で上司や先輩から学ぶ」方法が難しい理由】

これは簡単で、上司や先輩が現場の問題を解決するために必要な技術を知らない、もしくは、技術伝承する能力がないからだ。もしも、上司や先輩が現場の問題を解決する技術を身につけていて実際に解決できるだけの実力があるのなら、この状態が最も問題解決の成功確率が高い。なぜなら、「ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続ける」という昔からあるアプローチが使えるからだ。この方法は日本の製造業の世界ではスタンダードな技術伝承の方法だから、そのやり方を否定する人はいないし、ハードウェア出身のマネージャもその有効性や効果を十分に理解できる。まわりに反対する人は現れない。

だから、一度組織やプロジェクトが問題を解決する技術を身につけてしまえば、後は新しく入ってきた後輩達にせっせとその技術を伝承していけばよい。ところが、いつの日か、現場の技術者達が新しい問題を解決するための技術を習得することを怠ってしまったために、技術伝承の流れ（鎖）は切れてしまったのだ。ソフトウェア系の外部協力会社に仕事を任せるようになったころから、技術伝承の鎖の途切れが始まったのかもしれない。当時から、役割分担が明確であればよかったものの、徐々に丸投げの度合いは進み始め、メーカーサイドはドメインの知識とソフトウェア工学を結びつけることができなくなり、ソフトウェア受託開発会社は社員にソフトウェア工学を身につけさせるのではなく、より多くの時間働かせることが組織と社員の共通の利益であると考えるようになってしまった。

だから、特に組込みソフトウェア開発の世界では「組織内で上司や先輩から学ぶ」方法が難しくなってしまったのだ。

【「コミュニティの知り合った友人から学ぶ」方法が難しい理由】

実は、実際にやってみて一番有効なのはこの方法だ。自分自身、SESSAMEやEEBOFというコミュニティで知り合った友人から多くを学んだし、コミュニティに積極的に参加している人ほど、ソフトウェア工学を自組織に適応できているように思う。うまくいく理由は、「時間がない」とか「周りが賛同しない」とか「予算が付かない」などさまざまなハードルをコミュニティのメンバーがちょっとした励ましの言葉やヒントで支えてくれるから乗り越えられる確率が高くなるのだ。みんな、自分たちの境遇に憂いを感じていて、何とか問題を解決したいと考える技術者が集まるので、苦しいときは助け合おうという状況が作れる。

では、すべての多くの技術者がその方法で成功できていないのか。ダメな理由は簡単で、ひとつは組織の中で鎖国状態を作ってしまいコミュニティの存在自体を知らないのと、コミュニティに参加していてもROM状態から一歩も踏み出せない人が多いからだ。

組込みソフトエンジニアが自組織の中で鎖国状態に陥り、ゆでガエルになるのは、人が流動しないから、自組織の外にどんな世界が広がっているのか知らないからだろう。今はインターネットで何でも調べられるのに、「調べてみよう」という気が起こらないのがとても不思議だ。google でいろいろなキーワードを打ち込んでいくと、どのような世界が外に広がっているのかだんだんわかってくる。毎日自組織の狭い世界の情報だけにさらされていると、外の世界も同じだろうと思い込んでしまうのだろうか。

【「コンサルタントから学ぶ」のが難しい理由】

現場で起こっている問題を解決する方法を知っている技術者にコンサルテーションしてもらう方法は、技術伝承の鎖が切れてしまった組織においても問題解決に成功する確率が高い。なぜなら、ベテランが初級者にくっついて実際に作業をやらせ、失敗を繰り返しながら技術が習得できるまで指導を続けるというやり方でコンサルタントから技術を習得することができるからだ。抽象化された方法論を実際に現場で起こっている問題にどうやって適用すればいいのかを教えてくれて、かつ、問題を解決するまで、技術が伝承されるまで指導してくれる。

ではなぜ、みなコンサルテーションを頼まないのか。理由は簡単で、組込みソフトウェアの開発現場では技術伝承の鎖が切れてしまっている現在でも、組織内の先輩から後輩への技術伝承によって問題を解決することが正しいと考えられており、それができないのは技術者の怠慢であると考える経営者や上司が多いからである。だから、コンサルタントを頼む予算が付かない。

もちろん、現場の問題を解決し、いったん切れてしまった技術伝承の流れを復活させる力のあるコンサルタントは非常に少ないし、コンサルタントの力だけでなく現場の技術リーダー達の協力がなければ技術伝承の鎖を結び直すのは難しい。何はともあれ技術伝承の鎖を復活させることが必要だということが組織の上位層に理解されなければ、コンサルタントの助けを求めることはできない。

【おまけの考察】

JaSST'09 の基調講演で『実践ソフトウェアエンジニア』の著者であるロジャー・S・プレスマン氏は「自分達が作ったソフトウェア（方法論）以外は信用できないシンドローム」は未だになくなっていないと言っていた。それを聞いて「なんだ、それは日本だけじゃなかったのか」と思った。「自分達が作ったソフトウェア（方法論）以外は信用できないシンドローム」が蔓延している組織、プロジェクトで従来のやり方から脱却するためには、かなり強いリーダシップが必要になる。

昔、日本の職人の中には棟梁という存在がいた。今、日本の組込みソフトウェアプロジェクトで求められているのは、棟梁的なリーダーシップを発揮できる人材だ。棟梁的なリーダーシップとは、しがらみや制約条件の中で舵取りができる決断力を持ち、アーキテクチャの善し悪しを判断し悪い所を指摘し、良い例を提示できる実績と経験を持っているということだ。必ずしも、声が大きいとか、人を引きつける能力があるという訳ではない。

技術伝承の鎖が切れてしまった状況では、問題解決に必要な技術を身につけ、棟梁的なリーダーシップを発揮できる人材が組織やプロジェクトの中にいないと改革を進めることができない。

「そんな人いないや」と思った人は「自分がなるしかないんだ」と思ってもらうしかない。そうしないと明るい未来がくる可能性は残念ながらない。

　

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

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

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

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

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

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

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

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

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

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

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

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

エレキの分かる組込みソフトエンジニアの育て方

今回は、まっさらな新人が入ってきて組込みソフトエンジニアとして育てたいとき、どんな学習方法を取り入れるとよいかという提案をしてみたい。

ちなみに、ここで紹介する方法はたぶんデジタル系の電気系技術者の教育にも使えると思う。

【前提条件】

・複数人の新人を教育する場合に有効。（できれば4人以上がよい。チームを2つ以上作れるので）
・3ヶ月以上は現場から隔離できることが望ましい。（集中して課題に取り組んでもらいたいから）
・プログラミングの経験は必要なし。・電気回路設計の経験も必要なし。
・Word や Excel や PowerPoint 、インターネットブラウザでの検索等は使えること。

【教材】

1. CPUの創りかた











2. 電子回路シミュレータ TINA7(日本語・Book版)で見てわかる デジタル回路の「しくみ」と「基本」










3. 電子回路シミュレータ TINA7（日本語・Book版2）で見てわかる 電子回路の「しくみ」と「基本」

※純粋にソフトウェアしかやらないのなら3は省いてもよい。








【ねらい】

「CPUの創りかた」は秋葉原で買えるロジックデバイスを組み合わせて CPU を自分で作ってしまおうという本だ。イラストはちょっと怪しいが中身はいたってまじめであり非常にていねいに解説してあるので、本に書いてあるように進めていけばシンプルなCPUを自作することができる。

何をするにもはじめに原点を追求しておくのはよいことだ。CPUをディスクリートで自作し、実際にプログラムコードの読み出しやアキュームレータの動きをテスターやオシロスコープを使いながら確かめることは、組込みソフトウェアエンジニアにとっても、デジタル回路設計技術者にとっても貴重な経験となるはずだ。

次に、電子回路シミュレータ TINA7 は実機がなくても、回路を書いてその動きをシミュレーションすることができる。回路に電源を供給して回路上の不特定の端子ポイントをバーチャルオシロスコープで観察することもできる。東京電機大学高等学校教諭の小峯龍男先生は、このTINA7を使った学習本の中で、「ひとつだけ残念に思うことは、TINAでは回路の組み立てに失敗しても、コンデンサをパンクさせたり、抵抗器の被覆焼け焦げたり、ICのパッケージが火傷するほど熱くなるという経験をできないことです。」と書いているが、『CPUの創りかた』で実際にCPUを作ってしまうことで、その欠点を補おうというのが今回の作戦となる。

電子回路シミュレータ TINA7(日本語・Book版)には、機能限定で TINA7のCDがついているので安価に学習ができる。

3つの本を使って、各チームにそれぞれCPUボードを作るという目標を達成させる。（Project Based Learning）

教育とマネージメントする側はPCの用意などインフラの整備、最低限のルールの規定、ポイントポイントで進捗をチェックする以外は基本的にチームに運営を任せる。

スケジューリング、材料リストの作成、道具の購入、予算管理、材料収集、回路シミュレーション、一次試作、製品制作をすべてチームに任せることで、製品開発工程のミニチュア版を体験させる。（本番と比べると商品企画と自分たちで考える回路設計だけが欠けている）

【学習方法】

まず、新人を複数のチームに分けて、各チームのリーダを決めておく。いい加減に決めるのではなく、できるだけ人物をよく観察して適性がありそうな者を指名しておく。

次に、PCやインターネットなどのインフラを使えるようにして、プロジェクトの主旨を説明し、まずは『デジタル回路の「しくみ」と「基本」』を頭から読んで、回路シミュレーションをやらせてみる。

しばらくしたら、CPUを作るための簡単な工程の説明をして、スケジューリングをさせる。（スケジューリングするためのツールとしては、GanttProject などのフリーツールを指定してもよい）

毎週一回週末に各チームの代表1人に10分間で、その週に学んだこと次週の予定などをプレゼンさせる。（週報プレゼン）　また、月末には30分のプレゼンをさせる。（月報プレゼン）

【CPU制作プロジェクト】

CPU制作は、『CPUの創りかた』に書いてあるとおりにやれば出来るはずだが以下の点を考慮するとよい。

【材料収集と予算管理】

• 必要な材料と道具のリストを作らせ、大まかな価格をインターネットで調べさせる。
• 部品の購入方法について検討させる。（首都圏なら秋葉原で購入する）
• 部品は一台ぶんではなく、一次試作ぶんと製品ぶんの2セット以上を購入させる。
• 予想価格と実際に購入した価格の差を明確にさせる。

この後の工程の注意については、また今度本ブログで紹介したいと思う。
　
【この学習方法の良いところ】

• 管理者サイドの工数がほとんどかからない。
• チームが複数あるとそれぞれの様子を見て、良い点を取り入れようとする。
• 週報プレゼン、月報プレゼンをさせることで学習の進度や進捗が分かる。
• 製品の開発工程を体験させることができるので、現場に出たとき何かと役に立つ。
• CPUの動きの原点を学習できる。
• 早い段階で回路デバッグを経験させることができる。
• 一発では完成度の高い製品レベルの制作は難しいことが分かる。
• 教材費が安い（本3冊で1万円以内。CPU制作費はたぶん数万円）
• 新人は最初とてもまじめなので黙々と学習に取り組み学習効率がよい。
• まだ現場の仕事をしていないため割り込みの仕事がほとんどなく集中できる。
  

とてもよい教材本を作成してくれた『CPUの創りかた』の著者 渡波 郁氏と『電子回路シミュレータ TINA7(日本語・Book版)で見てわかる デジタル回路の「しくみ」と「基本」』『電子回路シミュレータ TINA7（日本語・Book版2）で見てわかる 電子回路の「しくみ」と「基本」』の著者 小峯 龍男先生に感謝したい。

ぜひ、お試しあれ。
　

山崩しなんて本当にできるのか？

組込みプレス Vol.10 が発売になった。特集1 『できるエンジニアの“頭の中”徹底解剖』の記事が今回のブログで言いたいことと大いに関係あるのでまず、紹介しておきたいと思う。

特集1 『できるエンジニアの“頭の中”徹底解剖』の執筆者は、福田 英徳さんで、『C/C++による組み込みソフトウェア開発技法（ソフトバンククリエイティブ）』の著者でもある。『C/C++による組み込みソフトウェア開発技法』は、組込みに限らずソフトウェアに関する開発技法の多くが解説されており、自分はソフトウェア開発技法の辞書代わりに使っている。さまざまな開発技法の具体的な使い方が掲載されており、机上の空論ではない著者が実際に使ってみた開発技法のポイントが書かれている。

さて、組込みプレス Vol.10 の特集1『できるエンジニアの“頭の中”徹底解剖』の一節を紹介しよう。

【『できるエンジニアの“頭の中”徹底解剖』より引用】

　：
　ソフトウェア開発プロジェクトにおける問題を解決する能力は、ほとんどのソフトウェアエンジニアが身につけることが可能な能力です。普遍的な能力といってよいでしょう。必ずしもそうとは限らないのでは？と思われるかもしれませんが、問題解決に必要な力は、実は一つだけなのです。それは問題を解決しようとする意志の力です。必ずこの問題を解決してやろう、という確固とした意志そこが、問題解決に最も必要な力です。
　：
　筆者は、強い意志されあれば、問題解決には必ずしも知識・スキルを「あらかじめ」身につけておく必要があるとは必ずしも考えてはいません。もちろん実際の問題解決にあたっては、土台となるさまざまな知識があった方が遙かに効率的ですので、今持っていないスキルは学習によって身につけることが求められます。
　：
　ソフトウェア工学の知識は、数え切れないほどの過去のソフトウェア開発プロジェクトで発生したさまざまな問題を解決するために、優秀なエンジニアが能力を振り絞って悪戦苦闘した結果の中から、優れた手法と認められたものだけを蓄えた知識体系です。ソフトウェア工学を学ぶことは、過去（あるいはまだ現役かもしれません）に活躍した最優秀なエンジニアの能力の一部を身につけること、といっても過言ではないでしょう。

【引用終わり】

引用した部分だけだと、ヒューマンスキルの話しか書いていないように見えるが、そんなことはなくて　エンジニアリング、マネージメント、リーダーシップのことがまんべんなく語られており、かつ、『C/C++による組み込みソフトウェア開発技法』で紹介されている状態遷移設計、構造化設計、オブジェクト指向設計などの開発技法についても触れられている。

ピックアップしたところは、特に問題解決能力に関して書かれた部分であり、これに関しては自分は福田さんとまったくの同意見であり、「問題解決能力（Problem Solving Skill)：自ら考え行動する力」の記事に同じようなことを書いたのでこちらも読んでいただきたい。

『できるエンジニアの“頭の中”徹底解剖』の特集記事では、開発手法の話の前にヒューマンスキルが大事と書いている。この点が非常に共感できるところであるし、今日のブログのテーマである「山崩しなんて本当にできるのか？」の疑問につながる。

では今日の本題に入りたいと思う。

Microsoft Project などのプロジェクト管理ツールを使ったことのある方は多いと思う。まず、仕事を細分化し、期間や工数、誰をアサインするのか、どの順番で仕事を進めるかをガントチャートに書いていく。

このツールを使っていて引っかかる点がいくつかある。一つは、ある仕事に技術者をアサインするときに、その人の工数の何パーセントを使うのかを入力することだ。

技術者は大抵、複数の仕事を抱えているので、抱えている仕事のうちどの仕事にどれくらいの時間を振り分けるのかを決めるという理屈はわかるが、振り分けられた技術者はAの仕事に20%、Bの仕事に80%工数を使えといわれてその通りにできるのだろうか？

人間は同時に複数の仕事をこなすことはできないから、例えば1日10時間働くとして、2時間をAの仕事に8時間をBの仕事に割り当てれば、その通りになるが、本当にそんな働き方をするのか？

自分は未解決のAの小さい仕事とBの大きい仕事があった場合、どっちの仕事にしても中途半端の状態のままで別な仕事に移るのは嫌いだ。中途半端にしたAの仕事が気になって、Bの仕事に集中できない。

こういうときは、Aをできるだけ集中して早く片付けでまず一通り完成させてしまう。そして、Bに取りかかりBも一通り完成させる。この時点でAの仕事もBの仕事も完成させるという責任を果たすめどが立って精神的に落ち着く。

そして次に、納期までの余った時間でAとBの仕事をもう一度見直してさらに完成度が上げられないか考える。時間の許すかぎりイテレーションを繰り返し、成果物を洗練させる（リファクタリングする）。

そんな仕事のやり方をする自分にとって、技術者にAの仕事に20%、Bの仕事に80%工数を使えと指示することに強い違和感を感じる。

どちらかと言えば、Aの重要度はこれくらいで、Bの重要度はこれくらいと伝え、どんな工数の使い方をしてもいいから期限までに仕上げてくれと言いたい。

実際にC君がAとBの仕事に使った工数配分を後から分析し、似たようなA'やB'の仕事をお願いする際に、どれくらいかかるのか予測する際に工数配分の数字を使うのはいいが、これから取り組む仕事に対して工数の配分をパーセンテージで示すのはまるで人間を人格のない機械のように見ているようで嫌いだ。

これと同じような話で、「工数の山崩し」というのがある。

Microsoft Project でガントチャートを書いて、プロジェクトメンバーの工数を入力していくと、リソースの配分を別画面で眺めることができる。

ようするに誰に仕事が集中し、誰の仕事が少ないのかをグラフで把握できるのだ。

このときプロジェクト管理ツールは「工数の山崩し」を行う機能を持っている。仕事の集中している人の仕事を仕事の少ない別のメンバーに自動的に振り分け、プロジェクトメンバーの工数を平均化する機能だ。

自分は、この機能を一度も使ったことがないし、この機能ほどナンセンスなものはないと感じている。

少人数のプロジェクトしか経験していないせいか、誰にどんな仕事を任せるのかは、その人の性格やスキルを見て決める。多くの場合、Aの仕事は技術者αにやってもらうのが適しており、Bの仕事は技術者βにやってもらうのかよいなどと判断して割り振る。その結果、技術者αに仕事が集中することも少なくないが、だからといってαに任せようとした仕事をβに振り分けるとうまくいかないことは多い。

「プロフェッショナルの条件」の記事で書いたように、20世紀、21世紀の世の中は肉体労働者よりも知識労働者の方が圧倒的に多い。工数の山崩しの論理は知識技術者を肉体労働者のように考えていないか？

これが10名ほどの小さいプロジェクトではなく100人規模のプロジェクトで、サブプロジェクト単位でのタスクの山崩しなら、もしかしたらあり得る話なのかもしれない。山崩しの対象が技術者個人ではなく、サブプロジェクトであり、サブプロジェクトごとに仕事の配分を変えるというのであれば、サブプロジェクトのリーダーが技術者の性格やスキルを考えながら誰にどの仕事を任せるべきか調整することができるので理解はできる。

しかし、エンジニアの視点で山崩しという行為を考えたとき、同じようなスキルを持ったエンジニアがプロジェクト内に何人もいて、同じ仕事をAさんからBさんにスイッチできるような職場ってあるのだろうか？

ETSSでスコアが同じエンジニアなら仕事をAからBにスイッチできるのか？

ピーター・F・ドラッカーが『プロフェッショナルの条件』で書いているように、知識労働者がメインの現代では、現在のプロジェクトメンバーの構成員をよくみて、それぞれの得意な部分を最大限に生かしてできることを考えた方が、まず、目標ありきで苦手でも必要とされる仕事をメンバに強要するより、より大きな成果に結びつく可能性が高い。

もちろん、技術者の特長を把握し、その特長を最大限活かすようなプロジェクト運営をするには、洞察力の高いプロジェクトリーダーが必要になるが、プロジェクトメンバーや協力会社のエンジニアをまるで物のように扱うプロジェクトリーダーでは、どんなにスキルの高いメンバーがそろっていたとしても、高い成果、品質のよいソフトウェアをアウトプットできるような気がしないのだ。

人はものじゃない。ものじゃないから知識やスキルを組み合わせるだけでは成果をあげることはできない。逆に言えば今知識やスキルを持っていなくても可能性はある。

そういうスタンスに立つと、新しいプロジェクトメンバーを補充しようとするとき、現在スキルを持っているかどうかではなく、足らない技術を身につけるポテンシャルを持っている人材がいないかという視点で人を見るようになる。

自ら足らない点を補い技術を身につける行動を取れる自立したエンジニアであれば、現時点でスキルを持っていなくてもいい。

これと同じことを、組込みプレス Vol.10 の特集記事 『できるエンジニアの“頭の中”徹底解剖』で福田さんが書いているというわけである。
　

問題解決能力（Problem Solving Skills)：自ら考え行動する力

正月休みに『世界一やさしい問題解決の授業』（渡辺健介著）という本を読んだ。

いつものように、まえがきを紹介したいと思う。

【世界一やさしい問題解決の授業のまえがきより】

　みなさんの将来の夢は何ですか？　今どのような悩みがありますか？　壁に直面したとき、自分の力で乗り越え、人生を切り開いていけるという自信はありますか？　それとも、あきらめてしまいそうですか？
　この本で紹介する「考え抜く技術」、そして「考え抜き、行動する癖」を身につければ、たとえば苦手な教科を克服する、部活でよい成績を残す、文化祭を盛り上げるといった、日常生活で直面するさまざまな問題を解決できるようになります。そして、自分自身の才能と情熱が許すかぎり、夢を実現する可能性を最大限まで高めることができるようになります。
　つまり、自ら責任が持てる人生、後悔しない人生を生きることができるようになるのです。
　どんなに大きく複雑に見える問題でも、いくつかの小さな問題に分解すれば解けるのです。一度そのことに気がつけば自信がつくし、前向きになるし、精神的にも余裕ができます。そして、自ら考え、決断をし、行動することの楽しさを知り、人生を切り開くために必要な癖が身につくのです。
　この本を紹介する問題解決の手法は、ぼくがかつて働いていたマッキンゼーという経営コンサルティング会社で活用されているものを基にしています。マッキンゼーは企業の社長さんや政府・非営利団体のリーダーの方々にアドバイスする会社で、日本や世界を代表する企業の戦略を立てるときにも、この手法が使われています。それだけでなく、これは個人の問題を解決するためにも必ず役に立ちます。ぼくは22歳でこの思考法と出会い、そのとき、「これが『考える』ということなのか！　なぜこれをもっと早く教えてくれなかったんだろう」と強く思いました。そして、なるべく多くの人にこの思考法を伝えられればと思い、この本を書くことにしたのです。
　この本では、最低限必要なものに絞って、シンプルに紹介してきます。
　1限目では、自分で問題を解決することのできる人を「問題解決キッズ」と名づけ、それはどのような人なのか、問題解決の流れはどのようなものなのかを、ひととおり説明します。
　2限目では、中学生バンド「キノコLovers」がより多くの人にコンサートに来てもらうためにはどうすればよいかを、問題解決の手法を使って解く例を紹介します。
　3限目では、CGアニメの映画監督になることを夢見るタローくんが、まずパソコンを手に入れるために具体的な目標を立て、達成する方法を考え出す例を紹介します。
　問題解決能力を身につけることは、けっして、人の感情がわからない「冷たい論理的な人」になるということでも、口が達者で自分のことしか考えない「個人主義で身勝手な人」になるわけでも、日本人的なよさを失い「欧米的な考えをする人」になることでもありません。
　自分の力で考え抜き、行動をする人になる、自分の力で人生を切り開く人になるということなのです。
　さあ、一緒に問題解決の思考法を楽しく学びましょう！
　みなさんも一歩踏み出す力がきっと身につくはずです！

【引用終わり】

この本、ダイヤモンド社から1200円（+税）で2007年6月に出版されているのだが、4ヶ月でなんと13刷りまで増刷されている。まえがきからも分かるように、子供もターゲットの中に含まれている点が幅広い層から支持されているのだと思う。

著者の渡辺健介氏は、デルタスタジオをいう会社を作って、この問題解決の授業を実際に子供達に教える活動も行っている。

さて、冒頭に掲げた絵はこの本の中での子供達の分類を表している。子供になぞらえているが実際には大人の世界で考えた方がよりリアリティがある。

【「図1-1 問題解決キッズは最短距離でゴールにたどり着く」より】

「どうせどうせ」子ちゃん

• 考えないし行動もとらないので、ゴールにはたどり着かない。
• やってみないから何も学ばないし、自信もつかない。
• グチを言って日々過ごす。

「評論家」くん

• 何が問題か、だれが悪いか、何をすべきかは言えるが、自分では行動しない。
• リスクや結果に対する責任をとらない。

「気合いでゴー」くん

• わき目もふらずに前進あるのみ！　へこたれずにがんばるが、ムダが多く、ゴールに最短距離でたどり着けない。
• 行動した結果から学ばないので、進化するスピードが遅い。

「問題解決キッズ」

• 適度に考えて、行動して方向修正して・・・を繰り返し、最短距離でゴールにたどり着く。
• 実行の結果から毎回何かを学び、進化していく。

【引用終わり】

みなさんの周りにも「どうせどうせ」子ちゃんや「評論家」くん、「気合いでゴー」くんがいるのではないだろうか。自分は「問題解決キッズ」だと自負している人でも、一時的に「どうせどうせ」子ちゃんや「評論家」くん、「気合いでゴー」くんになることはある。しかし、いかに「問題解決キッズ」が少ないことか。子供の世界でも、あらかじめ答えのある問題しか解かせていないせいか「問題解決キッズ」は少ない。

渡辺氏は、「問題解決キッズ」は他の3人と「進化するスピード」がまったく異なると主張している。スタート地点では、全員100の力があると仮定し、「考え抜き、行動する癖」がある人とない人の進化のスピードをシミュレーションしている。

Aさんの進化のスピードが毎月1%、Bさんは5%、Cさんは10%で進化するとすると、3年後にはAさんとCさんでは22倍、BさんとCさんでも5倍の差が付く計算になる。10年、20年と人生を積み重ねていけば、その差は果てしなく広がる。「考え抜き、行動する癖」を身につけているか否かがその差になる。

さて、この本では問題解決の流れを 次のような工程で説明している。

【問題解決の流れ】

1. 現状の理解
2. 原因の特定
3. 打ち手の決定
4. 実行

この順列はプロジェクトマネジメントで提唱される P(Plan)→D(Do)→C(Check)→A(Action）の流れにも似ているが、PDCAのP(Plan）の部分がより詳細に、「現状の理解」「原因の特定」「打ち手の決定」と分解されている点に注目すべきだと思う。

別な言い方をすれば、問題解決のためには分析の工程がポイントであり、十分に分析しないでPDCAのサイクルを回してしまうと問題解決に時間がかかる可能性がある。PDCA回しているのに「気合いでゴー」くんになってしまう危険性もあると思う。

『世界一やさしい問題解決の授業』では、問題解決のためのツールとして

• 分解の木
• はい、いいえの木
• 課題分析シート
• 仮説の木
• 意志決定ツール

などを紹介して分析工程の充実を図っている。日本にも品質管理の世界ではQC7つ道具とか新QC7つ道具といった分析ツールが使われており、課題解決の際に重宝している。でも、このような分析ツールは実際にどれだけ使われているだろうか。自分の実感としては、日本では特に「考え抜き、行動する癖」が欠落し、問題を分析する機会が減っているように思う。

さて、実際の問題解決の方法論については『世界一やさしい問題解決の授業』を読んでいただくとして、この本で紹介されている。中学生バンド「キノコLovers」がより多くの人にコンサートに来てもらうためにはどうすればよいかの問題解決の手法と、CGアニメの映画監督になることを夢見るタローくんが、まずパソコンを手に入れるために具体的な目標を立て、達成する方法を考え出す例を読んだ感想を書きたいと思う。

まずは正直にいってげっそりしてしまった。なぜかというと、題材は子供向けではあるが、実際にやっていることはプロのイベント屋さんがやっているマーケティングや、ファイナンシャルプランナーの理論であり行動なので、何しろ「重い」。

自分が中学生になったつもりで問題解決の手法を実行することを想像してしまうと「重い」し、途中でくじけそうな気がしてしまう。

そう考えると、問題解決のための手法はこの本を参考にして身につけたとして、一番大事なのは問題解決の意志、モチベーションを問題が解決するまで高く持ち続けることができるかどうかだと思った。

だからこそ、この本の問題解決の例題が「キノコLoversがより多くの人にコンサートに来てもらうため」であり「CGアニメの映画監督になることを夢見るタローくんがパソコンを手に入れる」なのだ。当事者にとって何としても達成したい目標があるからこそ、問題解決の手法を使って行動する活力が沸いてくる。

自分はイマイチ、キノコLoversやタローくんに感情移入しきれなかったため、げっそりしてしまったが、自分自身の達成したい目標が課題なら気分はまた違う。

組込みソフトエンジニアにとって、問題解決の実現する活力（モチベーション）をどこに持って行くのかが実は難しい。

例えば、サラリーアップのような目標は問題解決を実現するモチベーションにはなりにくい。問題を解決しなくても、上司にゴマをすることで目標を達成できてしまうかもしれない。

組込み製品開発における問題は品質、コスト、納期、制約条件のクリアなどさまざまだが、組織としての最終目標は製品を完成させて製品が市場に受け入れられること、もっとストレートに言えば商品が売れることだ。

でも、商品が売れることに個人のモチベーションを重ねるのはどうかと感じる。そこで、提案したいのが顧客満足を問題解決を実現する活力（モチベーション）とするという考え方だ。

提供した商品をお客さんに満足してもらうこと目標に掲げ、問題解決を実現する活力になれば、商品開発で発生するさまざまな課題を問題解決のツールを使いながら乗り越えることができるし、エンジニア自身がみるみる進化する。商品の品質は顧客満足であるという考え方があるように、顧客満足を高めることは組織の目的にも合致する。顧客満足を高めることを個人の目標にできれば、組織の目標にもなるので都合がよい。

実際、自分自身はこのことがETSSで定義されるような技術的なスキルよりも大事だと考えている。それがこの記事のタイトルにした問題解決能力（Problem Solving Skill)だ。問題解決を実現する活力（モチベーション）を保ちながら、問題解決能力（Problem Solving Skill)を高めることができれば、エンジニア個人も進化するし、商品開発も成功に近づく。極端に言えば、問題解決能力（Problem Solving Skill)が高ければ、技術的スキルは最初なくても、当然必要であることに気がつくためいずれ身につく。

もう一つ、エンジニアの考え方として大事なのは「貢献」だと思う。自分は何にどのような貢献ができるのかと考える。例えば、組織に対して、社会に対して、家族に対して、コミュニティに対して。

貢献という視点は、所属する範囲の中の自分を意識し、その役割を意識することにつながる。だから、自分がやりたいことをやるのではなく、何が貢献できるのかという視点で考え、行動すると、成果は必ず評価されるはずだ。

これを機会にみなさんにも、問題解決能力（Problem Solving Skill)と問題解決を実現する活力（モチベーション）、貢献の視点、この3つについて考えていただきたい。　

P.S.

『世界一やさしい問題解決の授業』の著者、渡辺健介氏は、あとがきで、次のように述べている。

【あとがきより引用】

　問題解決能力に似たクリティカル・シンキングは、英米の一部の学校で、国語や歴史などの授業を通じて教えられています。次世代リーダーを育てるために、まず感情を揺さぶるような刺激を与えて問題意識を持たせたうえで、「問題の本質は何なのか」「自分だったらどうするのか」を問いかけることで、リーダーとしての責任感や意志決定能力をみにつけさせ、個人の価値観を結晶化させるのです。
　私自身、中学校二年生からアメリカで教育を受けたのですが、最も衝撃的だったのがグチニッチハイスクールでの米国史の授業でした。
　たとえば、公民権運動を取り上げる際には、黒人差別の映像－子供も女性も圧力ホースで吹き飛ばされ、警察犬にかみつかれる様子－を、あらゆる人種が混在するクラスメイト全員で見るのです。生々しい感情や体験を目の前につきつけられました。さらに、キング牧師の自伝はもちろん、弾圧する側だったKKK（クー・クラック・クラン）の資料や、関連する小説を読み、多様な視点で考えることを求められました。

【引用終わり】

日本の教育や生活の中で圧倒的に不足しているのが、このような感情を揺さぶるような刺激を受けて問題を考えることのように思う。テレビの中では議論は交わされているが、視聴者はそれをただ見ているだけ。ただ、米英の教育をまねすることがいいのか、そうすると日本人のアドバンテージが失われてしまうのかどうかはまだよく分からない。

ただ一つだけ言えるのは、問題解決能力の低い人間を寄せ集めても、物事はちっとも先に進まないということだ。