使う側の視点と作る側の視点

新年、明けましておめでとうございます。

2013年の最初の記事に何を書こうかなあと考えている。

組織にいるときは「自分が組織を通じて社会に何を貢献できるのか」を、プライベートな立場では「個人としての自分が社会に何を貢献できるのか」についていつも考えるようにしている。

その中で、新人技術者の教育を始めるに際して、いつも話している事柄があるので、読者の皆さんにも役立つかもしれないと考え、これを紹介しようと思う。

技術者には使う側と作る側の両方の視点が必要

今の時代、社会人になる前にもの作りに触れる機会はかなり減ってしまったと思う。社会が成熟するにつれて、生活の中で不便と感じることを解決するデバイスが次々と供給され、不便がどんどん駆逐されている。

企業が次々と不便を便利に変える商品を投入していったことで、エンジニア予備軍となる若い人たちが、自分のアイディアで不便を便利に変えるくふうの機会が減ってしまった。

だから、多くの若い人たちは使う側の視点しか持たないようになり、かつ、もの=デバイスを使うことは楽しい=FUN という感覚が支配するようになった。

この流れは「当たり前にできていること」に対する関心を薄れさせ、「当たり前にできていること」の裏側にある仕組み、工夫に対する感動やそれを作った人への畏敬の念を忘れさせてしまう。

すべてのエンジニアがみんながそうなってしまったら、日本も終わりだなと思う一方で、そういう環境が若いエンジニアを変質させていることを認識して、じゃあどうすればいいのかを考えるのが我々の仕事だと思う。

だから自分は、冒頭の図を新人技術者たちに示して、これまでは使う側の視点しか持っていなかったかもしれないが、これからは作る側の視点を持ち、それまで自分たちが知らなかった「当たり前にできていることの仕組み」に感動できるようになりなさい、と諭している。

今やTOYOTA だって「FUN TO DRIVE, AGAIN.」なのだ。車は移動の手段ではなく、運転を楽しもうと言っている。

このスローガンは日本がいい意味でも悪い意味でも成熟してしまっていることをよく表していると思う。

こういう世の中で、もの作りをする技術者に不足しがちなのは「要求を実現するために必要な技術に対する飢え」だと感じる。何か足らないこと、不便に感じていることを自分が実現してやるというモチベーションが下がっている。

ある意味それは当然である。ユーザーが解決して欲しい問題はほとんど先人が商品化してしまっているからだ。先人が強いモチベーションで作った商品にちょっとした機能を付け加えたり、改変したりする仕事しかなかったら「よし、やったるぜ」という気持ちにはなれないだろう。

だからこそ、先人の技術者たちは商品を通じて社会やユーザーに何を貢献しようとしたのか、何が貢献できているのか、どんな工夫が貢献に結びついているのかを、新人技術者たちに説明する義務がある。

新人技術者は残念ながら商品を自分の手でゼロから作り上げる機会はほとんどないかもしれないが、商品開発の歴史や課程を知ることによって、貢献の疑似体験をするとよい。

自分が作った製品ではなくても、お客さんから「役に立っている」とか「これが便利だ」と言われれば自分のことのようにうれしいだろう。そして、「ここが良くない」とか「こうなると良い」といった意見を聞いたときに、作る側の視点で製品の中身（アーキテクチャ）が分かっていれば、「こうすれば解決できる」という感覚が思い浮かぶはずだ。

新人技術者の人たちには、いざというときに問題解決の方法が思い浮かぶようになって欲しいと思うし、そうなるためにはどんな技術を身につけなければいけないかを常に考えるようにして欲しい。

エンジニアが社会に貢献できるようになるためには、使う側の視点と作る側の視点を持ち、当たり前にできていることの裏側を理解し、それを自在に操れるような技術を習得することが必要なのだ。

P.S.

ここまでの記事を読み返して、新人向けにはよくても指導者向けにはちょっと掘り下げが浅いと感じたので追伸を書こうと思う。

百万行を超えるソフトウェアシステムが珍しくない昨今、新人の技術者に対して、ただ単にソフトウェアシステムのアーキテクチャを理解できるようになれというのは、あまりにも不親切なアドバイスだと思った。

現代のソフトウェアエンジニアはもしかしたら、好むと好まざるとに関わらず、システム全体の構成を設計するごくわずかなアーキテクトになる者と、システムの一部の開発を担当するか、変更要求に応じた設計をする者や、テストを専門に行うテスターなどに分業せざるを得ないのかもしれない。

皆がアーキテクトになれればハッピーかもしれないが実際には組織の中で実力でその地位を奪い取る競争をしなければならないだろう。

今の世の中それはしようがないとして、こんな時代にソフトウェアエンジニアはどこにモチベーションの源泉を求めればよいのだろうか。

それは、ソフトウェアシステム全体の中で自分がやっている仕事がどんなユーザー要求に貢献しているのかを理解し、システムの一部であっても自分が顧客要求を満たす価値を生み出していることに満足を感じることが大事なのだと考える。その貢献度が自分の成長とともに大きくなっていけば高いモチベーションを維持することができる。

そう考えると最初に必要なのはシステムの要求仕様を完全に理解することである。新人技術者は自分が担当する製品やシステムの要求仕様書を理解し、分からない言葉がない状態に早くなることをまず目指す。

そのためには要求仕様書の完成度が高くないといけないし、要求仕様に設計仕様やアーキテクチャの記述が含まれているとよくない。優れた要求仕様書はユーザーが理解できる言葉で記述されている。そして、どうすれば要求が実現できたのかを判定する判定基準が明確になっている。先人は、優れた要求仕様書を後の世代のために残すことが求められている。

そして、要求仕様が理解できるようになったら、次に若いエンジニアはアーキテクチャ設計書を読む。アーキテクチャ設計を理解するにはそれなりのスキルが必要だが、アーキテクトになりたいのなら要求仕様とアーキテクチャ設計の結びつきを理解できるようにならなければダメだ。要求仕様とアーキテクチャがばらばらであることに気がついたら、アーキテクトにのし上がれるチャンスがある。要求仕様とアーキテクチャが綺麗に整合するような設計ができるようになれば、アーキテクトとして認められる。そこまで到達しなくても、要求仕様とアーキテクチャの関係性に何らかの違和感を感じることができるようになれば、アーキテクトになれる可能性はある。

そのためにも、先人は現行システムのアーキテクチャが分かるような情報を残さなければいけない。言わずもがな、アーキテクチャ設計を説明する資料がないようでは、100万行を超えるソフトウェアシステムを維持し続けることはできないし、新人技術者に指導するのも無理だ。口づてで伝えられるような情報量ではないし、ソースコードでは階層的に理解を進めることができない。

現代の新人エンジニアを本気で組織的に育てようとするのなら、先人の技術者たちがソフトウェアシステムの上流工程のドキュメントをしっかり作り込まないといけないということである。

ベテランのエンジニアもこれまでの実績にあぐらをかいていたのでは、行く先が危ういのである。

「部下に任せないとダメだ」と考えさせられる一冊（その2）

小倉 広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。

小倉氏は CHAPTER 3 任せる、と伝える の中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。

【CHAPTER 3 「任せる、と伝える」 より引用】

部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。

「給料が上がるわけじゃないないし、だったら面倒だから断ろう」

このように考えるのがごく普通の判断というものだろう。しかし、もし、彼に将来の夢があったならどうだろう。例えば独立して社長になりたい。もしくは他社からスカウトが来るようなプロフェッショナルになりたい。そんな夢があったら、きっと判断は変わるに違いない。

「将来独立するためには、この経験はプラスになる。自己成長のために是非やらせてもらいたい。」そのように答えが変わってくるだろう。

【引用終わり】

小倉氏は組織人事のコンサルタントだったからこう書いているが、この話しはソフトウェアエンジニアにも全く同じように当てはまる。

ソフトウェアの開発効率や品質を高めるためには、高度なスキルを学んだり、自動化のシステムを構築したり、アーキテクチャを見直したり、プロセスを組み直したりするため一時的に仕事量が増える。日々忙しいのなら、さらに忙しくなるということだ。

ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）もそうだが、最初に再利用資産を構築する際には通常の作業よりも1.5倍くらいは軽く工数も時間もかかる。それを乗り越えて「今やろう」と決断できなければ、その先開発が楽になることはない。エンドレスの悪循環が待ち構えている。

エンジニア個人やプロジェクトにスキルアップや新しい取り組みを進言するとき、必ず聞かれるのは「それをやるとどれくらい工数や時間がかかるのか」だ。目先の損得だけで判断されると大抵は辞退される。だからこそ、エンジニアとしての将来の夢を語りたいのだが、なかなか自分自身がエンジニアとしてどう成長したいのかを頭に描いている人はいない。

新人は夢があっていいのだけれど、職場に配置されて1年もたつと、夢を語らなくなる。上記の引用のように、夢のないエンジニアに仕事を任せても成長のスピードが遅い。

本サイトでよく読まれ低r記事「問題解決能力（Problem Solving Skill)：自ら考え行動する力」の「どうせどうせ子ちゃん」や「評論家君」が多く、「問題解決キッズ」が少ないのだ。

小倉氏は、『任せる技術』のなかで「世の中には、明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たないと思う。これまで3万人の管理職に研修や講演をしてきた僕の実感値では、1～2%がいいところだろう。」と言っている。よって、上司は部下が自分の人生のビジョンを描くお手伝いをする必要があり、そのためには定期的な面談が欠かせないと書いている。

【CHAPTER 3 「任せる、と伝える」 より引用】

■ビジョンなし、なら今に集中

実際に部下と人生のビジョンについて面談するとわかることがある。それは何度質問を繰り返してもビジョンが見つからない部下がたくさんいるということだ。これまで彼らは「ベキ論」に縛られて生きてきた。だから突然、「どうしたい？」「どうなりたい？」と聞かれるとうろたえてしまうのだ。「やりたいことが見つからない」。そういう若者が増えているのだという。では、僕たちは彼らに対してどう接すればよいのだろうか？

これまで言ってきたことと矛盾するようだが、僕はその場合は、ムリしてビジョンを描かなくてもいいと思う。今、目の前にある仕事に120%集中するよう導いてあげればいいのではないか。

キャリア・ドリフト理論という考え方がある。キャリアはデザインするものではない。偶然に出会うものだ、という考え方だ。ただし、そのためには条件がある。今、目の前にある仕事に120%集中することだ。「自分には向いていないかもしれない・・・」などと言わずに、その仕事に集中するのだ。そのときに初めて偶然が、幸運が訪れる。

【引用終わり】

「明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たない」というのは悲しいことだ。そうなっているのは、人生のビジョンを描く訓練をしてこなかったからだと自分は信じたい。「ベキ論」に縛られることなく、やりたいことをやるにはどうしたらいいのかを考え、実行し、ダメだったらなぜそうなったのかを反省するそれを繰り返していけば、人生のビジョンを描けるようになると思う。

本当ならば、それを学生の時代に訓練しておいて欲しいのだが、その訓練をする機会もなく社会で出てしまった人達は大勢いる。だから、上司は部下に仕事を任せなければいけない。

【CHAPTER 3 「任せる、と伝える」 より引用】

■任せる、とういことは、自分の違うやり方に異を唱えないこと

任せた以上は、自分と違うやり方を許容しなくれはならない。
「オレだったらこうするのに・・・」
「そのやり方をすると後で必ず問題が起こるぞ。あ～。やっちゃった・・・」
そう思ったとしても、部下のやり方に異を唱えてはいけないのだ。失敗することも含めて部下に経験させなくてはならない。それが本当の意味での任せる、ということなのだ。

【引用終わり】

もう一つ、重要な教訓。

【CHAPTER 4 「ギリギリまで力を発揮させる」 より引用】

■相手に矢印を向ける人は成長しない

先にお伝えした通り、上司が持っていた仕事を部下に任せると、部下には大きなストレス負荷がかかる。能力以上の仕事にチャレンジする部下は思い通りにならない仕事にイライラを感じるのだ。これを心理学の言葉では認知的不協和と呼ぶ。

これは前にも説明したが、そのイライラを解消する時に常に選択肢は二つある。一つは自分に矢印を向ける方法。つまり、問題の原因を自分にあると考え、自分を変えることで問題を解決しようとするアプローチだ。これを選ぶ部下は成長していく。仕事を任せたかいがある、というものだ。

しかし、もう一つの選択肢を選んだ場合はそうはいかない。それが他人に矢印を向けるという方法だ。
「目標達成できないのは不景気のせい」
「期限内に提出物を出せないのは、仕事の量が多すぎるから」
「チームの目標達成率が低いのは、人員を補充してくれない人事部のせい」

そうやって問題をすべて他人のせいにすることで自己正当化する。自分は悪くない、悪いのは他人だ、と言って必死に自分を守るのだ。

当たり前にことではあるが、このタイプの人は成長しない。自分は変わる必要がない。すべては他人が悪いと思っているからだ。

【引用終わり】

相手に矢印を向けずに、「自分に矢印を向ける」ように指導する、これが難しい。どうすればいいかを考えるのも自分の仕事だ。

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世紀ではまったく信用できないし、大企業のリスクも存在する。

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

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

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

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

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

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

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

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

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

新人と就活

今年の新人達がプレゼンするのを聞いた。ものすごくうまい。本当に信じられないくらいうまい。最近は個人情報ということで、どの大学の何を専攻してきたのか、学卒か院卒かも公開されないからプロフィールがまるでわからないが、プレゼン慣れしているのは確かだと思う。

あまり人前であがらないというのは現代的な特徴かもしれないが、観客が自分をどのように見ているのかを客観的に把握できているように見える。

就活で鍛えたのだろうか？　最近の就職は非常に狭き門となっているらしく就職を控えた学生の諸君は大変だという話しをよく聞く。

『内定の出ない学生は何が間違っているのか～学生、企業、大学、親がすれ違う悲惨な現状』を読めば大変な現状が分かる。

しかし、日本の企業はどうして「新卒」にこだわるのだろうか。これまでずっと同じシステムでやってきたから、いまさら変えることに不都合があるのか。能力主義、成果主義に切り換えたといいながら、実は年功序列が実態なので新卒という枠を外すと問題が生じるのだろうか。

日本の企業は大学、新卒とう枠を設けることで、自分達が欲しい人材がどのような人間であって欲しいか考えることから逃れていると思う。

ようするに新卒であれば世代という観点では同じ評価指標で考えられる。その土俵で人選すれば選びやすい。ところが、新卒という条件を外したら、もっと評価指標が増えるし、また、どのような人材を求めているのかをもっと明確にしなければいけない。

その組織にあった人材ということだけではなく、今、不足している、これから始めようとする事業に有効な能力、ポテンシャルを持った人材を選らばなければいけなくなる。というよりは選べるようになるのだ。

キャリア採用と似ているが、キャリアは十分ではないだろうから、人材を必要とする事業やプロジェクトに投入する際にポテンシャルの高い人を探さなければいけない。今まで以上に人事部門が事業部門と情報を共有し、どんな人材が必要か常日頃からディスカッションしておかねければいけない。

新卒しか採用しないのは、人事部門が新卒という枠でしか技術者を評価できないからではなだろうか。

その組織に、その事業に、そのプロジェクトに必要な人材がどのような者か、どのようなポテンシャルを持っているべきかを考えられるようになれば、新卒にこだわる必要がない。

ちゃんとそのコンセプトを示し、いろいろな経験をした広い範囲から人材を選べるはずだろう。

プレゼンがうまいのがもしも就活のために訓練したのであれば、それもよいが、エンジニアとして組織が求めているポテンシャルが高いのかどうかはそれだけでは分からない。

就職する側の企業が変われば、大学の姿勢や受験も変わるのではないかと思う。現在の就職状況では、一芸に秀でた人材が埋もれてしまわないか、日本ではチャンスは新卒の一回しかないのかどうか心配になる。

問題解決の方法を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.

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

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

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

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

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

人は教育によってどれくらい変われるか？

4月5月は教育計画を立てる時期ではないだろうか？ その時期にいつも思うことは「人は教育によってどれくらい変われるか？」ということだ。

教育によって知識を増やすことは可能だ。しかし、知識を増やすだけでは組織内の問題はなかなか解決しない。今の世の中、知識を詰め込むトレーニングは意味がない。なぜなら、知識の多くはインターネットで検索できるようになってしまったからだ。

必要な知識は検索したりお金を払って手にいることができるようになった。人間に求められているのは、それらの知識を使ってさまざまな問題を解決することである。

今読んでいる『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年の筆者は主張する。リコールになりかねない「危ない」プログラムの例にも注目。

著者として短いながら当を得た書評だと思う。感謝！

練習が必要なのはオリンピック選手だけじゃない

バンクーバーオリンピックでは数々の名勝負が繰り広げられた。なかなか見応えがあったが、選手のみなさんがこれまでさぞたくさんのトレーニングを積んできたに違いない。

スポーツは練習しなければうまくならない。スポーツだけではない。人間がやるもの何でもそうだ。知識労働者だって知識だけ知っていれば仕事ができるとはいえない。特にソフトウェアエンジニアがスキルアップするに繰り返しの練習が必要だと思う。

そう考えるとソフトウェアエンジニアがスキルアップしていく様があるとすれば、それはスポーツ選手が技術を身につけていくのに似ているような感じではないかと思う。

どんなスポーツだって練習しなければうまくならない。そして才能のある選手には必ず優秀なコーチがつく。コーチは科学的な理論に基づいてどうやって選手を育てていけばいいのか考え、いろいろなトレーニングメニューを組み立てる。選手が出す成績にもとづいてトレーニングメニューを変えたりもする。

ソフトウェア技術者の教育も同じではないか。優秀なエンジニアに育て上げるには優秀なコーチが必要だ。また画一的なトレーニングではなく、選手一人一人に合わせたトレーニングが必要だと思う。

今、ソフトウェア技術者を取り巻く世界では選手とコーチと練習という環境ができていないのではないだろうか。

選手はいつだって自主練習のみ。自主練習どころか練習する時間も取れない。また、コーチは外部コーチで何人もの選手を一斉に面倒みるため、選手の個性に合わせたトレーニングメニューを用意することはできない。

よく、OJT(On the Job Training）が大事というが、OJTというよりは、スキルが身につくまで繰り返しの練習をさせる環境が必要なのではないかと思う。よい練習問題を用意して、繰り返し繰り返し練習するのだ。プログラミングでもモデリングでもよい。同じような問題を繰り返しながら自分の血となり肉となるまで鍛錬する。人間の脳は一回教えただけで修得できるようなしくみにはなっていないのだ。（これは精神も肉体も同じ）

繰り返し練習をする時間はないとあきらめてしまうか、いろいろとやりくりして時間を作るかは遠い将来にメダルを獲得した自分や自分が育てている選手の姿を思い浮かべることができるかどうかで決まる。

ソフトウェアエンジニアもスポーツ選手と同じでハングリーな選手と実戦経験を積んだよいトレーニングメニューを持ったコーチが出会って初めて優秀な成績が残せるような気がする。

就職氷河期をブレークスルーすための就活作戦

日経ビジネスオンラインの時事深層というコーナーに『6万人の「大学は出たけれど」』という記事が載っていた。

【日経ビジネスオンラインの時事深層　『6万人の「大学は出たけれど」より引用】

「誰でもいいから欲しい」終焉

　厚生労働省の調査によると、来春卒業予定の大学生の就職内定率は、10月1日時点で62.5％と昨年の同じ時期に比べて7.4ポイント低下。3人に1人の就職先が決まっていないことになる。

　ところが、リクルートワークス研究所が調べた大卒者の求人倍率は1.62倍。求職者を求人が上回る状況が続いている。求人倍率が1を切った2000年3月卒業生の採用時でも、同じ時期の内定率は63.6％と、今年よりわずかながらも高かった。

　求人はあるが内定率は低いーー。これは何を意味しているのか。

　日本企業が「質」による学生の選別を強めていることが背景にある。「企業を引っ張っていける優秀な人材しか採らない」ことを示している。

【引用終わり】

ようするに、不景気なので採用側の余裕がなくなり、長い間従業員を抱え込む日本の企業においては、どうせ採るならより後々組織に大きな貢献をする学生だけを採ろうと考えるようになったのだ。

そうなったら、もう競争だ。ここで学生のみなさんにアドバイスしたいのは競争は就活の期間だけではないということだ。

そこで、「もし、自分が超就職氷河期の時代にいる学生だったら、どんな作戦を取るか」について考えてみた。

まずは、企業がどんな人材を欲しているかである。日経ビジネスオンラインの記事を読むとどうも「即戦力」が欲しい訳ではなく、将来組織の幹部になってもおかしくないような人材を採ろうとしているということだ。技術者の場合は、少なくとも技術部長クラス、技術でその部門をリードしていけるような人材ということだろう。

ただし、ソフトウェアエンジニアの場合は技術的に修得しなければいけないことが満載だから、学生が就職試験を受ける時点でそれらの技術を身につけている可能性はほとんどない。

組織内で技術者教育を提供する立場から考えると、学んで欲しいスキルは山のようにある。

• プログラミング言語（C, C++, C#, Java)
• テスティング基礎
• 設計プロセス
• リアルタイムOS
• 状態遷移設計
• 構造化分析・設計
• UMLモデリング
• オブジェクト指向設計
• リファクタリング
• ネットワーク
• データベース
• セキュリティ
• プロジェクトマネジメント

などなど。これらを学生時代に修得しておいてくれというのは無理だし、これらの技術は実際の仕事でどんなフェーズで何をやっているのかをよく見極めながら、現状の問題解決に必要な技術を習得させていかないと身につかないと思っているので、実践に入ってから学習した方がいいものも多いと考えている。

このような状況を考えると採用する学生に求めるものは何かということになる。

ひとつは、その組織が対象としている市場・ドメインに対して強い興味、関心を持っているかどうか、ふたつめは技術をスポンジのようにどんどん吸い込むポテンシャルがあるかどうか、三つ目はそれらの技術を組織内に展開できるかどうかだと思う。

3つめは技術リーダーになれるかどうかという指標なので、まずは置いておいて、ドメインへの関心とポテンシャルがあるかどうかについて考えてみたい。

ドメインへの関心は面接の際に趣味や質問攻勢によってすぐに分かってしまうだろう。面接官は企業ドメインのことを裏事情も含めて学生の何十倍もしっているから、知ったかぶりしてもすぐにばれてしまう。2チャンネルなどで情報を収集しようとしてもそのような薄っぺらい情報でやり合おうとするとかえって墓穴を掘る。となると、学生時代は好きなものをとことん追求するのがいいと思う。自分が熱中したことと、就活先の企業ドメインとの関係性が何かについてだけ抑えておいて、そこを説明し、メインは自分が何に集中したのかについて語るという作戦だ。（何も熱中したことがないのはその時点で難しい）

２つめの技術を吸収するポテンシャルがあるかどうかの判断は、履歴書や面接ではなかなかわからないしアピールするのも難しいと思う。そこで、自分が考えたのは学生時代に自分の成長のブログを作るという作戦だ。

例えば4年制の大学生なら2年～3年になったころから、自分の興味があることに対してどんな取り組みをしてどんな成果があったのかをブログに綴ってみるのだ。毎日でなくても毎週、もしくは月に2～3回でも更新を続け、どんなことに取り組み、どんな成果があったのか、何を反省しつぎに活かしたのかを写真や動画を入れて書いていく。

それって卒論、修論と同じだというかもしれないが、大学の先生の指導が入っていないぶんブログの方がその学生の実力がわかるし、日々の記録だからごまかしやうそ、見栄が効かない。その人の人生や姿勢が見える。

そして、そのブログの URL を人事担当に送るのだ。人事担当は技術のことが分からないから、採用を希望している部門の技術部長クラスあたりに打診するのではないかと思う。自分なら、そのブログをざっと見ればその人がどんな人間でポテンシャルがあるかないかをだいたい判断できると思う。

文章がだんだんうまくなているかどうかも指標の一つになる。ようするに一夜漬けではごまかせないレポートだと思うのだ。

以上、自分の成果をブログに書いて就活に活かすという作戦いかがだろうか？

ちなみに、転職を考える技術者も内部情報を出さずに純粋にどんなスキルを獲得したかを綴るブログを書きためておくと自己アピールに効果があるかもしれない。

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

なぜドキュメントを書かない？

久しぶりに『ジョエル・オン・ソフトウェア』を読んだ。Amazon で調べたら、最近、この本の続編である『モア・ジョエル・オン・ソフトウェア』が出たようだ。

ジョエル・オン・ソフトウェアの著者である Joel Spolsky はソフトウェア業界での豊かな経験を持つ開発者で、彼のウェブログ "Joel on Software" はプログラマ向けサイトとしては最も人気のあるものの一つで、彼はマイクロソフトの開発者だったころ Microsoft Excel 等多くの有名なソフトウェア製品の開発に携わった。

彼がブログで記事にしたことをまとめた最初の本が『ジョエル・オン・ソフトウェア』である。もともとはブログの記事であり。アメリカ人でないとわからないようなスラングや引用（例えばジョージ・ブッシュ大統領の口癖 Not gonna do it! 「それをやるつもりはない」等）がふんだんにちりばめられており、読みにくいと言えば読みにくいが、ところどころで「まさにその通り！」と膝を打ちたくなる部分がある。

まずは、『第5章 パート1：なぜわざわざ書く必要があるのか？　やさしい機能仕様』の一節を読んで欲しい。

【ジョエル・オン・ソフトウェア　第5章 パート1：なぜわざわざ書く必要があるのか？　やさしい機能仕様　より引用】

　私の考えでは、ちっぽけではないあらゆるプロジェクト（1週間以上のコーディング、あるいは2人以上のプログラマを要するようなもの）において、仕様書がなければ常に、より多くの時間を費やし、より品質の低いコードを作ることになる。理由はこうだ。

　仕様書の最も重要な役割はプログラムをデザインすることだ。たとえあなたがすべてのコードを1人で書いているのだとしても、純粋に自分自身のためだけに仕様書を書くのだとしても、仕様書を書くという行為自体によって－プログラムがどう機能するか詳細に記述することによって－プログラムを実際にデザインするように強いられるのだ。

－中略－

人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことにあるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせるこてはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになるのだ。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。

　これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くを想定されてるか知るために仕様書を読み、何をテストすればよいのかを理解する。

－中略－

　このコミュケーションは不可欠であり、あなたが仕様書を書いていない場合でも発生するが、その場合は行き当たりばったりに発生することになる。品質保証の人たちがしだいにあれこれとプログラムをいじり回し、そして何か奇妙なことが起きるたびにプログラマを邪魔して、どうなるのが正しいのかについてばかげた質問をする。これがプログラマの生産性を損なうという問題は脇に置いておくとしても、プログラマというのは「正しい答え」ではなく彼らがコードをして書いたことに即して質問に答える傾向がある。だから、品質保証の人たちは仕様に従っているかをテストするのではなく、プログラムの挙動に沿ってそのプログラムをテストすることになってしまうわけで、これは、なんというか、もう少しマシにやれたはずなのだ。

【引用終わり】

機能仕様書を含むソフトウェアドキュメントを書くことがムダである、役に立たない、その時間をプログラミングやデバッグに費やした方がマシだという声を間接的に聞くことがある。間接的にというのは、面と向かっては言わないが品質保証担当がいないときに、開発が遅れていることの理由としてやり場のない怒りに対して、要求されるドキュメントが多いということが開発が遅れる原因だとプロジェクトの内部で愚痴っているのだ。

自分がプロジェクトの遅れの原因にされているソフトウェアドキュメントだったら「それは、濡れ衣だ！」「 プロジェクトの遅れはドキュメントのせいじゃない！」と叫んでいるだろう。ドキュメントはしゃべれないから口をきけない者に問題の原因を押しつけているだけだ。ひどい話だ。

そう思っていたら、『ジョエル・オン・ソフトウェア』に上記のようなことが書いてあった。

ドキュメンテーションという行為はソフトウェアの設計に他ならない。いきなりプログラムを書き始めるのはもっともレベルの低い設計であり、自然言語や図表を使ってソフトウェアドキュメントを作るということがレベルの高い（抽象度の高い）設計行為だ。 Joel Spolsky が語っているドキュメントが必要な一つ目の理由が「ドキュメンテーションはプログラムをデザインすること」なのだが、2つ目の理由であるドキュメントがあることによって各部門とのコミュニケーションを効率的に行えると言う点は同意するものの、日本のソフトウェアプロジェクトでは難しい面があると感じる。

日本の小規模な組込みソフトウェアプロジェクトでは、プログラマが仕様も作成し、マーケティングもテストも品質保証もしなければいけないことが少なくない。品質保証という名が付く担当部門があってそこに担当者がいても実施的なソフトウェアの品質保証作業はプログラマがやっていることもある。

だれからも読まれないドキュメントを作るのは確かに辛い。誰かが読んでくれるから、自分や他の誰かのために役立つからドキュメントを書こうという気になる。

だから自分はレビューがあるときは事前に全部のドキュメントに目を通す。斜め読みするのは得意なので、数十ページのドキュメントでも10分くらいあれば問題点や「よく見てるね」と言われるような質問項目をピックアップすることができる。だから、レビューの数時間前に書類が送られてきてもへっちゃらだ。

的確に問題点や良い点を見つけてレビューで伝え、こういうときには何をチェックする必要があるのかをレクチャーする。時間かけて作ったドキュメントを読んで評価してくれる人がいれば次のドキュメンテーションの動機につながる。日本のソフトウェアプロジェクトがドキュメントを書かない理由のひとつに「誰も読んでくれない」ということがあると思う。

『あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。』という Joel Spolsky の主張はその通りだと思う。

これは個人的な感覚だが、自分はプログラムを書き直してプログラムがきれいになる、アーキテクチャが美しくなるのなら、今のコードを捨てることにぜんぜんためらいがない。（もちろん心に余裕だないとダメだけれど） 自分が作ったコードにきったないところがあって、後で誰かから「あれはないだろ」と言われるのは我慢がならないし、陰でクスクス笑われるのも嫌だ。やはり「いい仕事しているね」と言われたい。

だから、いつも自分がアウトプットした成果物をできるだけ第三者の客観的な目になったつもりで批評し、指摘されそうな部分があったらためらいなく直す。これを繰り返していると「ひとりピアレビュー（セルフレビュー）」ができるようになる。熟練すると質問されそうなことをいくつも想定できるようになるので、成果物をレビューされるときもスムーズな回答ができる。

ひとりピアレビューができるようになるのはそう簡単ではないので、やはりプログラマやソフトウェアエンジニアがモチベーション高く仕事を続けるためには、彼らの仕事を誰かがきちんと見て評価してあげないといけないと思う。成果物をほったらかしにせず、少なくともプログラムを作ったプログラマ以外の誰かが評価してあげることが、ドキュメントの必要性を理解させ、ドキュメントが役に立つことを体感させることにつながると思う。

P.S.

最近、昔作ったソフトウェアのことを聞かれ、10年前の日付が入っているドキュメントとソースコードを提供して再利用されたことがあった。ソースコードではなく、そのソフトウェアの元となる考え方自体が有用だったこともある。3年以上前に作ったソフトウェアだと自然言語で書いたドキュメントやモデルなどがあるととても助かる。こういうことがあると、あの時ドキュメントを作ったり、作らせたりして、キッチリいい仕事しておいて良かったと感じる。

ソフトウェアを教える学校

ハリー・ポッターの第６作『ハリー・ポッターと謎のプリンス』を見た。このところ地上波テレビでも旧作を放映していたため、我が家ではちょっとしたハリー・ポッターブームになっている。

ハリー・ポッターを見ていて、ソフトウェアエンジニアもホグワーツのように魔法（ソフトウェア技術）を学ぶ学校が必要かなあ、と思った。

ソフトウェア開発というよりはプログラミングは、こもろうと思えばかなりの部分自分の中にこもって仕事ができる。自分だけの世界の中で自分だけの価値観で突き進み、たまに外界から呼ばれたら「しようがないなあ」とつぶやきながら出て行って「はいはい」と適当に対応して、また自分の世界に戻るという時間の過ごし方も可能だ。

プロジェクトマネージャ、プロダクトマネージャの立場からすると、こういうエンジニアばかりいるととてもやりにくい。Aグループが作ったソフトウェア再利用資産をBグループのメンバーに利用させるとか、AグループとBグループとCグループの共通のインタフェース仕様を共同で策定するなどといった活動がなかなかうまく進まない。

ソフトウェアエンジニアを魔法使いに見立てれば、彼らは魔法使いとしては未熟な部分があり、集団生活、集団学習の中で、設計の規範や再利用の技術や、ソフトウェア工学を学ぶ必要がある。

自分を客観視できるエンジニアは書籍を先生に見立てて、自分自身で教室を開けるので学校にいかなくても、学校に行っているかのような環境を作り出すことができるし、組織内部で教育やトレーニングの環境、システムが整っているところは心配ない。

問題はそのような環境がなく、自分の中に閉じこもろうと思えばそうできてしまうような多くのソフトウェアエンジニアはどうすればいいのかということだ。

社会人が大学院で1年くらい学べるような環境が整っていればいいが、仕事を抱えているとなかなかそうもできない。社外研修やシンポジウムへの参加はできるものの、ホグワーツのような系統だった学習ではなく断片的な知識の習得になりがちた。日科技連などの長期的な学習カリキュラムもあるが、魔法学校のように学習すべき技術が体系化されていないためどれに参加していいのか困ることもある。

産学の間で「教えて欲しいこと」と「教えること」を合意し、将来を期待するソフトウェアエンジニアを定期的に送り出して魔法（技術）を教えてくれるような、ホグワーツのような学校ができないかなあと、ハリー・ポッターのシリーズを見ながら思った次第である。

【ホグワーツのようなソフトウェアエンジニアリング学校の条件】

• 学校の名前に権威があること。
• 優秀な魔法使い（エンジニア）を多数輩出していること。
• 実績のある教師を有していること。
• 実技実習も充実していること。
• 誰もが学びたいと思うような魅力があること。

貴重な情報ソースから見る「企業が学生に求める能力」

支援部門にいると組織に動いてもらわなければいけないときに提案書に相当するものを作る必要が出てくる。組織上位層と価値観を共有するためには、プレゼンテーションの資料に次のような内容を入れておくとよいというのもだんだんわかってきた。

1. お金の話し（○○をやらないと損失が大きい、△△をやると利益が上がる）
2. 他社、世の中のトレンドの話し（××社はこんなことやっている、世の中では＊＊が常識）
3. お客さんの話し（ユーザーがこのような不満を持っているから解決する必要がある）
4. 現場の話し（開発の現場では、○○のようなことが起こっており、△△をしないと開発期間が縮まらない）
5. 品質の話し（○○の指標でソフトウェアの品質が低下している。△△をして品質を向上する必要がある）

そんなこんなで、コンサルタントを生業にしている人たちが日頃どんな情報にアンテナを張り、上記のような話しをサッとプレゼン資料に盛り込めるようにしているのか何となく分かってきた。

人や組織を動かすとき、説得に使う情報はかなり重要だ。ソフトウェアのことを詳しく知らない人が財布と権限を握っているケースはハードウェアを扱う組込み系の企業には多い。この人たちを動かしていくには、ソフトウェアのことを相手が分かることばで説明し、かつ、相手の価値観に合わせて「それを今、実行することが必要である」と考えてもらわなければいけない。

そのために必要な情報ソースはいろいろあるが、今回は google でも引っかかりにくいが、かなり役に立ちそうなネタもとを見つけたので紹介しようと思う。

それは、社団法人 日本機械工業連合会（JMF: 日機連）のWEBサイトだ。ソフトウェアとは全く関係ないようでいて、実はそんなことはない。

日機連は、毎年度調査事業を行っており調査事情の報告はPDFで公開されている。工業会の調査報告など対した内容ではないだろうと思うかもしれないが、日機連の調査報告書は価値が高いことに最近気がついた。

その理由は、（推測によると）スポンサーに競輪とオートレースがあることが大きいと踏んでいる。要するに潤沢な資金を持つスポンサーが社会貢献のために日機連を通じて調査事業の費用を肩代わりしているのだ。そして、日機連が窓口になっていろいろなテーマについてさまざまな専門家を集めて200ページ以上の報告書を作成する。

報告書の作成にはその道のプロが仕事を請け負うことが多いが、調査をするのは各種の専門家であり、一般的な講演等では表に出てこない資料が報告書に載ったりすることもある。

試しに、日機連の調査報告書のページで平成15～18年度の報告書について「ソフトウェア」というキーワードで検索をかけてみた。

そこで、まずビビっときたのは『平成1 8 年度サービスロボット運用時の安全確保のためのガイドライン策定に関する調査研究報告書 』だ。普通企業は、ノウハウが少しでも含まれているような資料は一般にプレゼンテーションすることはあっても資料として公開することはめったにない。特許で権利が保護されているといっても、真似されたことを証明するのは困難だからである。

しかし、この報告書では National 屋外用自律走行型掃除ロボット SuiPPI の安全確保の構造について説明された資料がかなりくわしく掲載されている。さらに、滅多に資料が公開されることのない TOYOTA の資料「医療用介助ロボットのロボット運用に向けた安全確保に関するもの」も掲載されている。本業に関するものではなく、未来の事業について企業間を越えてディスカッションした内容だから公開OKとなっているのだろう。（その他 ALSOKのガードロボの情報も載っている）

今回、話題にしたいのは、この報告書のことではなく、『17高度化-13 ものづくり中核人材育成に関する調査研究報告書』のほうだ。ものづくり中核人材育成だから、その中に組込みソフトエンジニアも含まれている。

企業が求めるビジネス基本能力

項目/グループ	大学卒	大学院卒	短期大学卒	専修・専門学校卒
熱意・意欲	71.7	64.0	68.6	66.4
専門知識/研究内容	14.2	34.6	6.3	18.4
協調性	29.6	23.7	43.0	38.4
創造性	15.5	18.5	6.6	8.8
一般教養・教養	5.6	3.3	16.5	10.4
表現力・プレゼンテーション能力	21.5	17.1	14.0	13.6
実務能力	2.1	2.4	19.0	16.0
課題発見力	7.7	10.4	9.1	10.4
問題解決力	15.5	18.5	10.7	10.4
判断力	2.6	1.9	3.3	4.0
（学業以外の）社会体験	1.7	0.5	2.5	0.0
コンピュータ活用能力	1.3	0.9	4.1	4.8
論理的思考力	27.5	29.4	11.6	15.2
行動力・実行力	49.8	40.3	34.7	38.4
国際コミュニケーション能力	7.7	4.7	1.7	0.8
常に新しい知識・能力を学ぼうとする力	16.7	17.1	16.5	16.8
その他	6.9	7.1	10.7	9.6
回答(社数）	233社	211社	121社	125社

このデータ以外にも興味深い情報がたくさん載っているレポートなのだが、まずは是非これを見ていただきたい。企業が学生に求めているものは、「熱意・意欲」「行動力・実行力」「協調性」であり、次いで「論理的思考力」「表現力・プレゼンテーション能力」「常に新しい知識・能力を学ぼうとする力」「問題解決能力」「創造性」だということが分かる。

どこをどう見ても、小・中・高・大という長い14年の教育の中で子供がテストで評価されてきたものではない。本ブログサイト人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』は、おそらく学校では授業で教えていないが、少なくともコンピュータ活用能力よりは期待されている。

先日、NHKのクローズアップ現代で超氷河期と呼ばれる就職最前線で、企業がどのように学生をテストしているのかを紹介していた。テストとか面接とかそんなもんではない。今や、学生は面接で聞かれたときにどう答えると印象がよくなるのかをあらかじめシミュレーションしている。自分に能力があってもなくても、上記のようなことを期待されているのは分かっているから、その期待に添うことができるという回答をきちんと用意している。

そして、企業側も学生がそんな準備をしてきていることを知っているので、面接の受け答えを最重要視はしない。何をやらせるのかというと、例えば営業職ならば、商品の売り込みのロールプレイングをやらせるのだ。「実際に売ってみろ」と突き放し、「現場で問題が起こったとらどう行動するのか」を見るのだ。企業は人材を育成する時間と費用をセーブしたいと考えており、すぐに使える即戦力を欲しがっている。需要より供給の方が大きいから、応募してきた学生の中から、上記の表の能力を潜在的に持っている学生を選ぼうとしているのだ。

学生の方はたまったものではないだろう。テストでよい成績を取り、偏差値で評価されてきた評価指標とはまったく異なる土俵で勝負させらるのだ。

上記の表が示しているのは、画一的に教えられている勉強とは別に、自分で好きなものを見つけ、熱意意欲を持って探求し、問題が起これば課題を発見し、論理的思考力を使って問題を解決し、プレゼンテーション能力を活かして、協調性を持って創造力を使う訓練をしておけということだ。

こんなことができるスーパースチューデントは滅多にいないから、会社に入ってからも、これができるように訓練しておく必要がある。

組織内ではだれもそれが必要なんだよと面と向かって教えてくれないが、全体を見渡せる人が潤沢な資金を使って調査すると、実は組織がどんな人材を求めているのかがわかったりするのだ。

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

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

ソフトウェアエンジニアは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の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。

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

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

　

組織はソフトウェアエンジニアに投資できるか

このブログで、日本のソフトウェア技術者は試行錯誤的アプローチで組込みシステムのソフトウェアを作ってきたと書いてきた。それでも組込み機器の品質が保たれているのは、日本人に特有の「あたたかい人間関係の中のやさしい一員」という性質と職人気質、そして品質を心配する強い意識があるからだとも書いてきた。

これらの日本人の特性プラス「何かあったらソフトウェアをすぐ修正」という行動によって、日本の組込みソフトウェアは今のところかろうじて高品質を維持していると思う。しかし、これらの状況は、ソフトウェアの規模が小さいことと、日本のソフトウェア技術者が劣悪な環境を我慢（高収入を求めずにオーバーワークに耐えるということ）しているからまだ破綻していないのであって、システムソフトウェアの規模が増大（例えば実行コード行数ベースで30万行を超えるような規模）し、技術者がその過酷な労働に耐えきれなくなってきたときには、組込みソフトウェアの品質と開発効率が著しく低下し始めるはずだ。

もしも、ソフトウェアに関してどうにもならなくなってしまったら、組織はこの状況を打開するためにソフトウェア開発に対して何らかの投資をするしかない。今回は組織がソフトウェア開発（実際にはソフトウェア技術者教育）に投資できるかできないかの境界について考えてみたい。ソフトウェア開発に関して悪循環が始まっているかどうかの指標は、組織がアウトプットしているソフトウェアが結果的に利益を生んでいるかどうかで簡易的に判断できる。どのプロジェクトも利益を出せていないのなら、悪循環のフェーズに入っていると考えられる。利益が出ている商品、製品、プロジェクトと利益がでていない商品、製品、プロジェクトが混在している場合は必ずしも悪循環のフェーズに入っているとは言えない。

何はともあれ、ソフトウェアエンジニアという末端の立場から離れて、自分が経営者になったつもりでこの後の記事を読んでいただきたい。

なお、ソフトウェアは毎日のソフトウェアの活動で構築される。ツールにノウハウを隠蔽することはできるが、ツールを使いこなせるようにするにはトレーニングが必要になるから、結局はソフトウェアエンジニアに対する教育やマネージメント、インフラに対して投資をしなければ、ソフトウェアの品質や開発効率は上がらない。そう考えると、よっぽどの裏技を使わない限り、ソフトウェア開発に対して何らかの投資をしない組織のソフトウェア品質と開発効率は上がらない。

そして、プロジェクトマネージャーより上の立場の者は、まずは、ソフトウェアエンジニアに対する投資を組織からどうやって引き出すかについて考え、それが無理だと分かったとき、もしくは自分自身がエンジニアに投資を進言する立場にない場合は、組織を見限るか、それとも組織に留まって、どれくらい自己投資できるかどうかという方向に考えを切り替えるべきだと思う。

【組織がソフトウェアエンジニアに投資できるかどうかの境界】

1. 儲かっている会社は投資できる

当たり前だが、潤沢に利益を出している会社はソフトウェア技術者教育やツール、インフラ整備、プロセス構築、技術コンサルの導入などに投資できる。人を動かすだけで一見投資が必要ないように見える社内コンサルのような支援部隊を組織するような場合でも、人材を外から引き抜くのにお金がかかったり、現場から人材を外すことで工数の穴埋めをしなければいけなかったりするから投資は必要だ。

儲かっている会社はいろいろな手を打つ選択肢がある。ただ、気をつけなければいけないのは、ソフトウェアに関する投資ははっきりとした効果が見えにくいから、投資が役に立たなかったとしても口先だけで継続的に組織からお金を引き出そうとする人たちもいるということだ。

でも、儲かっている会社はある程度の無駄をしても原資があれば、何かしらの手を打ち続けることはできる。現在のように不況に陥ってしまうと、儲かっていた会社も利益が減ってしまい、ソフトウェア開発に対する投資を絞ってしまう傾向はあるだろう。

2. 儲かっていない組織でも技術者への評価に差を付けることで投資はできる。

利益がそれほどない組織でも、ソフトウェア開発に投資する意志とある程度の金（例えばソフトウェアエンジニア一人に対して年間最低10万円以上）を捻出できれば、新入社員や将来有望な技術者、今後、利益を生むアーキテクチャ（再利用資産を構築できるアーキテクチャ）を設計できるアーキテクトに対して集中的に投資するという方法はある。

アメリカではプログラム言語の書き方を知っている程度のスキルのエントリーレベルのソフトウェアエンジニアの年収は200万円以下だと聞いたことがある。そこから、スキルがアップするにつれて年収が上がっていく。日本も同じようにスキルがゼロに近い新入社員への報酬を減らしたら、優秀な技術者への投資分の数十万円/人くらいは出せるだろう。

しかし、このやり方は日本人にはなじまない。日本では長い間その組織、業務を経験させ、その時間の中で成長させるというところが多い。あえてこれを教育と呼ばないのは、組織的な戦略を持たずに現場に任せきりで、日々の業務をやらせているだけで技術を引き上げようという意志を持っているプロジェクトは多くないと感じているからだ。だから、組織が意識的に取り組む「投資」とOJTという名の実際には何もしていない状態は分けて考えている。

逆に、新入社員こそ組織として投資しやすい対象であるというのが日本の特徴だ。もっと、やってくれと言われることはあっても新入社員ばかり金をかけて不公平だという中堅、ベテランエンジニアはほとんどいない。

ソフトウェアエンジニアの中に年功序列ではなく、スキルの高さによって評価に差をつけて、実際にサラリーに差をつけて、そこから投資の費用を捻出するという方法は、よっぽど組織の上位層に強い意志と決断があって、目指すべきゴールがはっきりしていないとできるものではないと感じる。

なぜなら、日本人の「あたたかい人間関係の中のやさしい一員」という性質は人と人に差を付けるというのをいやがるからだ。自分もあまり好きではない。テストの点数で評価している訳ではないから、何をもって投資対象として選択されたのかについて技術者の中に疑念が生じると「あたたかい人間関係の中のやさしい一員」という性質を活かすことができない。

だから、技術者に格差を付けて集中的に投資する方法は日本の組織ではなじまない。

3. 自分で自分に投資する

組織がソフトウェアエンジニアに投資しない、選択的でも投資できないのなら、自分で自分に投資するしかない。お金をかけようとかけまいと冒頭のような状況でエンジニアに対して投資する気がないのなら悪循環からは決して抜けられない。（誰かがスキルアップするトレーニングを自分に提供してくれる筈だと考えるのは、そうならなかったときにスキルアップできないのは人のせいだと考え自己努力しなくなってしまうから危険だ）

自分自身の投資の仕方については次回の記事に回すとして、もしも、自己投資に成功してスキルアップした時に起きる問題について触れておこう。

何らかの投資の結果、自分のスキルが向上しソフトウェアの開発効率や品質をアップできるようになるとどうなるか。そもそも、組織が投資してくれないので自己投資しているのだから、スキルアップが成功したとしても、組織貢献を明確に示すことができないのなら、組織からの評価を期待することはできない。

自分のお金や時間でスキルアップして、組織貢献を実現できたのに評価されないかもしれないのだ。評価されないどころか、スキルアップして開発効率や品質向上を実現してできた余裕につけ込まれて他人の開発効率や品質の悪いソフトウェアを何とかする仕事を回されてしまう危険性さえある。

これはやりきれない。頑張ってスキルアップした技術者の努力が報われない社会、業界が発展する訳がない。

でも、現実はこんなもんだ。だから、頑張ってスキルアップできた技術者はその組織で報われないことが分かったとき、例えば組織を出てコンサルタントになり、1 の儲かって利益を出せている会社を助ける側に回ることになる。

そうなると、成長した技術者が去ってしまった組織が潤沢な利益を出せていなかった場合は、さらにソフトウェアの開発効率が悪くなり、品質も悪化し、残った技術者が残業することでしか対応できなくなる。

この論理だと、ソフトウェアエンジニアは自己投資でスキルアップしても報われないから、自己投資しないでじっとしていた方がいいのかということになってしまう。

そんな筈はないから、こう考えるしかないと思う。

組織がエンジニアに投資をしないのなら、エンジニアは自己投資してスキルを上げ、スキルアップしたことでソフトウェアの開発効率と品質を高め、顧客満足が高まったことに対して満足を感じるようにする。顧客満足を高めたことで自分のモチベーションを保ち、顧客満足を高めることに貢献したことを組織に示し評価を得、同じことを他の技術者もできるようにするには投資が必要であると説く。

4.  ソフトウェア開発やソフトウェアエンジニアに投資しないという選択

組織がソフトウェア開発に投資しない、技術者も自己投資しないとう選択肢はないのか。ないことはない。以下のようなケースが考えられる。

a) 投資せずに技術者に負担を強いる。

b) ソフトウェア部品を外から買い自組織では作らない。（サプライやにaを強いるか、逆にソフトウェア部品の価格をつり上げられるという問題あり）

c) 安い海外の労働力にシフトする。（「あたたかい人間関係の中のやさしい一員」という特性は使えない）

d) ソフトウェアでは勝負せず、真似できないハードウェア技術で勝負する。

以上、組織もエンジニアに投資を行い、エンジニアも自分自身に投資をし、投資の結果、ソフトウェアの開発効率と品質が上がり、顧客満足が高まり、それが自己満足につながって、組織にもその成果を認めエンジニアを評価し、投資の効果を確認するのが一番いい。それができないのならソフトウェアエンジニアは幸せにはなれないように思う。

次回は、お金をできるだけ使わないでソフトウェア技術者に対する投資をする方法について書こうと思う。

　

組込みソフトエンジニアの終焉

この時期、団塊の世代の方達の定年退職の送別会がいくつかあった。そのような方々のこれまでのエンジニアとしての人生を聞いていると一芸に秀でた技術者は最後は多くの人たちに感謝されながら見送られるのだと感じた。

実際、その方は電気系のエンジニアの方だった。そこでふと思ったのは組込みソフトエンジニアは現役を引退するとき、周りの人たちからどのような見送りを受けるのだろうかということだ。そもそも、ソフトウェアは表に見えにくいものだから、実績を語るのも難しいだろうなと思う。

やっぱりソフトウェアも同じで「○○の専門家」とか「品質保証のプロ」など、何か一芸に秀でるところがないと引退を惜しんではもらえないに違いない。または、後身を指導して人を育てたかどうかだ。現役バリバリのエンジニアという時期を越えて30代中盤を過ぎるようになってきたら、若いエンジニアをどう育てるべきかということをいつも考えておかなければいけないと思う。

そうしないと、若い技術者を育てるどころか、世の中の新しい技術に追いついていけず、若い人たちの足を引っ張るだけの役に立たないおじさん、おばさんエンジニアになってしまう。

人を育てることを考えるときには、自組織で生き残れるスキルだけでなく、世の中に放り出されてもきちんと食べていけるようにするには何を教育すればよいかを考えよう。そうすれば、自ずと組織の外に目が向いて外の世界から見た自分を見つめ直すきっかけにもなる。

若いエンジニアを一人前に育てることができ、そんな技術者が徐々に増えていくようなら、現役の組込みソフトエンジニアを引退するときにも感謝してもらえるに違いない。

人から感謝されるためには、自分の周りにも組織にも社会にも貢献しなければいけない。

P.S.

『働くことの本質は貢献であるという考え方』の記事も参照されたし。

侍ジャパンとサムライエンジニアを重ねてみる

WBC決勝でアジアの列強がレベルの高いいい試合をした。めずらしくスポーツ新聞を買って隅々読んでみたら、張本勲氏が次のようなことを書いていた。

　私にとって日本プロ野球は「育ての親」。逆に韓国プロ野球にとって私は「生みの親」になる。1982年、李容一初代事務総長、李虎憲同次長と3人で立ち上げた。当時の目標は、日本とアジアのチャンピオンを争えるレベルまで持っていくこと。そのために何十人もの選手やコーチを韓国に送り込んだ。その韓国が昨年の北京五輪金メダルに続いて大リーガーが参加するWBCで決勝に進出。ここまできただけで感慨無量、私としてはどちらが勝ってもよかった。

　　：

　プロ野球75年の歴史を有する日本に対し、韓国は27年。野球部のある高校が4000以上ある日本に対し、約50しかない。そんな中でよくぞ・・・。「アッパレ！」である。

　　：

　堅い守りを中心として、恵まれた体格とパワーだけに頼る野球を粉砕したアジアの野球。これを機に日本、韓国の野球がより発展することを願ってやまない。

この記事で感じたのは日本は4000もの高校の野球部が甲子園を目指して日々トレーニングを重ねていて、その下支えがあってWBC優勝という栄光を掴むことができたということだった。

野球選手は、なぜ厳しい練習を続けてそれほどまでにうまくなりたいのか、また、辛くてもがんばれるのか。一つは今回のWBCのようなスポーツの祭典で活躍する選手達を見て自分もいつかそうなりたいと思うからだろう。誰しもヒーローになってみんなから祝福をされたいと思う。

ただし、自分の欲望のためだけでなく、プロフェッショナルのアスリートとしては、自分のプレーを観客に見せ感動し満足してもらいその対価として年俸を受け取るという職業人としての側面も忘れてはいけない。

松坂はWBCの期間中もメジャーリーグのシーズンでも十分に力を発揮できるように自分のコンディションを気遣っていたという。松坂のコメント「代表でも（メジャーリーグの）チームでも両方で結果を残さなければプロではない」。レッドソックスのフランコナ監督は「通常の調整ではないし、急に球数を増やして98球を投げた。帰ってきたら彼にとってベストの（調整）方法を話し合う。」と不機嫌だったそうだ。どちらもプロのプレーヤーとして本業の顧客への満足度が下がらないように気を遣っている。

エンジニアはプロのアスリートのように表舞台に上がることは滅多にない。特に日本では組織を渡り歩くようなコンバートもほとんど発生しないため、技術者としての力を内外に示す機会がほとんどない。

WBCの戦いの中で岩隈は「松坂さんの登板間隔での準備の仕方、当日の試合前のブルペン、そしてマウンドへ・・・。その背中を見て勉強しました。」といい、ダルビッシュも藤川からクローザーとしての気持ちの持ち方や調整方法について教わったと語った。超一流のアスリートの話ではあるが、スポーツの世界ではここぞという場面で勝ったり負けたりしながら、いろいろなことを学び、自分を成長させる機会がある。

エンジニアにはなかなかそういう機会がない。エンジニアの能力を伸ばし、鍛えるためには、組織がチャレンジする機会、チャレンジしたことに対する評価を与える機会を用意する必要がある。アスリートもエンジニアも生身の人間だから、スキルを身につけるために練習する機会が必要という点は同じだ。もしも、組織がその必要性を認識することができないのなら、職場で上司や先輩がそういう場面を作るしかない。チャレンジした結果、評価がプラスであればなおよいが、マイナス面であってもエンジニアにとっては教訓になるから無駄ではない。

大事なのは遠くの目標を見据えて指導することだろう。スポーツ選手はうまくなるために必ずトレーニングをする。そうしないと生き残れないし、高いスキルを得ることができないからだ。ところがソフトウェアエンジニアはどうだろうか。知識労働者としてトレーニングを積んでいると答えられる者が周りに何人いるだろうか。

忙しいからトレーニング（勉強）する暇がないというのは簡単だ。仕事の中でもトレーニングはできる。ソフトウェア開発の方法論についてわかりやすく書いてある書籍を探し、通勤電車の中で読み、自分の仕事に試してみることはやろうと思えばできる。誰かから指示されていないからやらない、試してみていいといわれていないからやらないというのは自分の深層にプロのエンジニアとしての自覚が育っていないからだ。

WBCなどで世界中から優れた選手が集まって一緒にプレーすれば、自ずとプロ意識は高まる。勝負だからやらなければやられる。エンジニアの世界には勝負はないのか？　そんなことはないだろう。日々ライバル会社と戦っているはずだし、自分との戦いに勝てば組織の中で発言力を高めることもできるし、高見を目指してコンバートも可能だ。出世することが戦いだとは思わないが、ライバル会社に勝る商品を開発してより顧客満足を得ることができれば、それはエンジニアにとっての勝利だと思う。

現在スポーツのトレーニングは根性だけではなく科学的な要素も取り入れられている。システマティックにやらなければ十分な効果がないし、実際にはよいトレーニングを受けるには費用もかかる。

ソフトウェアに関するトレーニングも同じで、根性だけではスキルは身につかない。費用を抑えたいのなら、よい書籍を複数購入して試してみることが効果的だが、トレーナーが横についてくれる訳ではないのでトレーニングを続けるためには精神力が必要になる。野球なら試合に勝ちたいとか、甲子園に出たいとか、WBCで活躍したいとかいった明確な目標を立てやすい。ソフトウェアエンジニアの場合は自分の中で気持ちがくじけてしまわないような目標を立てるのが難しい。

今仕事で困っていることを解決するためのトレーニングをしようというのは直接的でわかりやすいが、この考え方はあまりおすすめしない。身につけた方法論が目的になってしまう危険性があるからだ。目標を持つならWBCで優勝するみたいな大きな目標がいい。イチローのような尊敬できるプレーヤーに相当するエンジニアを超えるといった目標でもいいかもしれない。

ともあれ、ソフトウェアエンジニアもトレーニングをして自分を鍛えることを続けていかないと決して一流にはなれない。ソフトウェアの世界の変容のスピードは速いのでトレーニングを数年間休んでしまうとすぐにおいて行かれてしまう場合もある。（逆に普遍的なスキルを身につけると陳腐化しない）

WBCを見て思ったのは、みんなを満足させるプレーを見せる（＝多くの人を満足させる商品を世に出す）ためには、日々のトレーニングといざ勝負しなければいけないとき※の精神力を磨き続けることが必要なんだということである。

※例えば、顧客満足に背反するような選択をプロジェクトや組織が取ろうとしたときに勇気を持って反対しなければいけないときなど。

P.S.

侍ジャパンを命名した原監督は新渡戸稲造の名著「武士道」を熟読したそうだ。「野球道は武士道に通じる」と語り、選手のあり方についても「誠実、素直、朗らか」をよしとした。エンジニアの方もサムライエンジニアを目指したいものだ。

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

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

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

日本でも工場では手順書による作業指示があるので、マクドナルドのマネージメントと似ているように見えるが、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)：自ら考え行動する力』の記事の影響だと思う。この記事にも書いたけれど、問題が何かを見据えて、その問題を解決する能力が高いと、その問題を解決するための知識やスキルは何かが分かる。要するに誰かから指示されなくても、自分で問題を解決し、問題解決のために必要な知識、スキルを身につけることができる。問題解決に必要のない知識、スキルを身につけなくてもいいから効率がいい。

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

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

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

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

組込みソフトってなに？（高校生の質問から）その３

また、匿名の高校生さんからお題をもらったので答えていきます。

匿名 さんのコメント...

面白くて、わかりやすかったです。あと、いいホームページももらいました。ありがとうございます。確かに、自分が作った組込みソフトが組込 み機器に搭載され、お客さんに満足してもらえるならうれしいですね。将来の夢のために、もっと頑張らないと......学校の勉強でそれに最も関連のある 教科とか、最も使える知識とかはありますか。知りたいです！このやりとりで、ますます組込みソフトに興味を持つようになりました(笑)。普通の会話みたい に何の違和感もなく、すごく楽しいです。これからもお願いします。

さて、質問に答える前に組込みソフトの楽しさを全国の高校生に伝えようとしている二上貴夫さんから、君に向けて情報やアドバイスをもらったので伝えておきます。

まず、高校生向けの組込みソフト教育に関する状況について。マジカルスプーンは当初工業高校向けにカリキュラムを開発しており、その後、普通科の高校生向けの情報科学の教材としてのカリキュラムを開発していく予定とのこと。

都内の普通科の高校でデモンストレーションを行った結果、情報処理に強い興味を持った生徒がいて、彼らに対して特別カリキュラムを秋から実施するそうです。工業高校向けに少し専門的な組込みシステム開発の教育を飛行船を題材に実施することも企画中とのことです。（これ必ずしも自分の会社の仕事とは直接関係ない計画だからその情熱たるやすごいよね。こういう人たちが利益度外視でがんばっていることに感謝して、与えられた機会を有効に使って欲しいと思う。）

二上さんは、高校生の頃に社会人から情報を仕入れるのは良いことだと思うと言っています。また、君のように自分がやりたいことを外に向かって発信できる人は、よい組込み技術教育の教材を紹介すれば、かなりのところまで自分で学習できてしまうだろうと見ています。組込みの世界でアーキテクト（建築で言うところの設計士）として活躍しているエンジニアの生い立ちを紐解くとみなそのようなタイプだそうです。

また、前回紹介したETロボコンの他に Hamana というロケット打ち上げの実験プロジェクトや、MDDロボットチャレンジという取り組みも是非見て欲しいとのこと。

マジカルボックスのプログラミング教室というのをSESSAMEのメンバーでもある舘 伸幸さんが計画しているそうです。

ちなみに、自分が住んでいることろからイベント開催場所が離れている場合は、SESSAMEが費用を補助することも考えようと思っているので、資金のことで今一歩踏み出せないでいる高校生諸君は一度 SESSAMEの相談窓口 query@sessame.jp に「組込みソフトイベント参加の相談」という件名で相談メールを出してみて欲しい。

以下は二上さんの直接のメッセージ

私からのアドバイスとしては、7月、8月に出たCQ出版のボード付雑誌を買って（酒井注釈：CQ出版のInterface誌でたぶん7月号、8月号ではない。定価が高い号がボード付きの号。こちらから探すべし。）、自分で組み立ててこらん。わからなくなったら、著者に質問状を書こう。私から著者に取り次いであげるから。ただし、君が高校3年生で大学受験するつもりなら、ボードの組み立ては来春に私の実験室で一緒にやろう。（酒井注釈：東海大学 組込み技術研究科 組込み技術専攻 を受験して大学で一緒に勉強しようということだと思う）

【「（組込みソフトの仕事に就くには）学校の勉強でそれに最も関連のある教科とか、最も使える知識とかはありますか。知りたいです！」の質問へのアドバイス】

まず、アドバイスの前に伝えておきたいことがある。それは、「人から言われたことをそのまま鵜呑みにしちゃいけないよ」ということだ。これは「人を信じるな」「必ず疑ってかかれ」ということではない。人にはいろいろな考え方があって、僕が正しいと思ったことはもしかすると他の人はそうではないと考えているかもしれない。世の中にはいろいろな考え方があって答えがひとつではないことがたくさんあるということを認識して欲しい。

現に、組込みソフトってなに？の回答に対して、stpete97 さんはもっと違う組込みソフトの世界もあると書いている。（こちらの記事） 21世紀の組込みソフトの世界という意味ではセンサーやアクチュエータを使わないような世界もある。組込みソフトといっても何しろ幅が広いので「コレが組込みソフト」と一刀両断では答えられない。だから、ひとつのアドバイスを鵜呑みにしてはいけないし、最後はいろいろな意見や考え方を聞いた上で、自分が持っている価値観に照らし合わせて咀嚼することが必要だ。ただ、高校生という年代は自分の価値観を構築する時期でもあるので、いろいろなことに首を突っ込んで世の中の多くのことにアンテナを張り巡らせ感度を高めておくことがよいと思う。

次に、考えて欲しいのは自分の人生という長い年月のことだ。例えば、君が80歳まで生きるとしよう。そうするともし君が今17歳なら人生はまだ、全体の21%しか進んでいないことになる。この後大学に進んだとして、就職して仕事について定年を迎えるとすると、社会人として働く期間はだいたい38年間で一生の48%となる。だからこそ、人生の約半分を費やす社会人として期間どんな仕事をするのかを選択するのは非常に重要な選択だ。

ただ、よくよく考えてみて欲しいのは、それでもその38年間は人生の約半分に過ぎないということだ。社会人を卒業してからの人生も20年近くある。また、30歳くらいで結婚したとしたら人生の62.5%は新しい家族との生活があるということになる。

何が言いたいかというと、人生を80年と考えれば、17歳くらいの君が学んでいること、過ごしている時間で何に役立つかはそう簡単には言えないということだ。

そのことを前提にして、今人生の約半分くらいまで来ている自分が過去を振り返って、君が学んでいることが何に役に立つかについて自分の考えを書いてみたいと思う。（鵜呑みにしちゃいけないよ）

【英語】

実は中学、高校、大学と一番きらいな教科が英語だった。なぜかというと、自分は英単語を覚えるのが苦手だったからだ。必ずしも記憶力が悪いということではなく、今後の人生において役に立ちそうにないと思うとやる気がなくなって学習する意欲が低下し、結果として勉強が進まなかった。あまり我慢強い性格じゃなかったんだ。

その当時、自分は日本を出て海外で働くような夢はなかったし、そうしたいと思ったこともなかったし、英語が分からないことで得られない情報などないと思っていたから、英語は大人になっても使うことはないというちょっとした自信があった。

でも、社会人になってから以外に必要だということが分かってきたね。その当時、社会人の人たちに英語は使うから勉強しておいた方がいいよと言ってもらいたかった。だから君には英語は勉強しておいた方がいいよと言っておくよ。

何に使うのかというと、まず、海外で作られたハードウェア部品やソフトウェア部品のカタログや取扱説明書は英語で書かれていることが多く、日本語に翻訳されていない場合もあるから英文を読む必要がある。また、日本で作った商品を海外で売るためには、国際規格を理解しないといけないことがあるけれど、この国際規格はフランス語と英語で書いてある。

さらに、インターネット上の情報で特定の分野においては日本語のサイトよりも英語圏のサイトの方が圧倒的に多くの情報が存在するケースがある。例えば、ソフトウェアの構築方法について書かれたソフトウェアアーキテクチャ（Software Architecture)については、英語サイトの方が情報量が多い。だから、英語が分かっていると最新の情報をゲットできる可能性が高い。

もう一つ、場合によっては君は外国人と仕事をすることがあるかもしれない。グローバルな世界で部品や商品を売り買いしていると、自ずと海外の人たちとメールを交わしたり、打ち合わせしたり、出張したりする機会も出てくる。そのときに英語が話せるととても楽だ。

ということで学生時代、なかなか身につかなかった英語は、社会人になってからお金も使いつつ、ちょっとずつ勉強している。いまではどんなことに役立つのかイメージがわいているので、辛いながらも意欲は持ちながら勉強できているのでまあいいかと思うけど、学生時代に英語が自分の人生の中で役に立たないと決めつけてしまっていたことは間違いだったと素直に認めるね。

全然関係ないけど、英語の授業で今でも覚えているのは中学生のときの先生がテープレコーダを毎回持ってきて英語の歌を生徒に聞かせてみんなで歌えるようにしてくれたことだ。

もちろん、そんなことは学習指導要領には書いてないから先生のオリジナルの授業だった。そのとき歌った歌は次のようなもの。

「花はどこへ行った」（原題 Where have all the flowers gone?）

ザ・ブラザース・フォア が歌ったものを先生は聞かせてくれた。そのときは何のことを言っているのかまったく分かっていなかったし、先生もわざわざ解説しなかったけど、大人になってから知ったのはこの曲は世界で一番有名な反戦歌でフォークの不朽の名曲だったんだ。

「We　shall　overcome」　アメリカ公民権運動のテーマ・ソングのように歌われた歌で、アフリカからヨーロッパを回って奴隷としてアメリカへ連れてこられた人たちの、船上での労働歌のようなものだったという歌。その当時はそんな背景はまったく知らなかった。

「Country Road」 ジョン・デンバーの作詞作曲で、このときはオリビア・ニュートン・ジョンが歌っていた。最近では宮崎駿監督の耳を澄ませばで挿入歌として使われていたね。

中学生レベルでネイティブな英語の歌詞を歌えるようになるのは至難の業だったけれど、今でも覚えているんだからもっともインパクトのある授業だったと思う。

【国語】

ソフトウェアとはまったく関係がないように見えて実は大いに関係があるのは国語だと思う。プログラムもアセンブラというコンピュータが解釈するための言語で書いていたときはそうでもなかったけれど、C言語などの高級言語と呼ばれる、より自然言語（もちろん英語）に近い言語でプログラムが書かれるようになって、プログラミング＝やりたいことを文章で書き表すに近くなってきた。

だから、極端に言えば分かりやすい文章を書く人は分かりやすいプログラムを書く傾向があるように思う。自分自身にしか分からないようなトリッキーなプログラムを書く天才プログラマーと呼ばれるエンジニアも中にはいるけれど、そういう人が書いたプログラムは多くの場合その人しかメインテナンスできないので、チームで仕事をしたり、同じ人がずっとその製品の担当になれない場合が増えてきた現在では、分かりやすいプログラムを書くことがもとめられている。

また、ソフトウェアは市場やユーザーの要求を図や文章で書き表し、それをもとにしてプログラムを書くことになるので、文章の読解力や作文の能力は高い方がよい。

先人の成功や失敗が体系化されたソフトウェア工学を勉強する際には書籍を読むことでそれらの知識を吸収することも多いから、長文読解能力は特に求められる。「こいつは何を言いたいんだ」ということができるだけ早く分かるようになることが重要なんだ。また、ソフトウェアでは他の人が書いたドキュメントをチェックするレビューという行為を頻繁に行うのだけれども、このときもいかに大量のドキュメントを斜め読みして、重要なポイントがどこかあたりを付ける能力が求められる。

【数学】

数学は言わずもがなソフトウェアの世界ではよく使う。ソフトウェアの世界では解を求めるときに総当たりで見つけ出すのが得意で、大きな数字同士の最大公約数を求めるような問題は自分でやるとうんざりするけれど、コンピュータは繰り返し演算させてもイヤだとはいわない。

そういう意味では個人が使っているようなパソコンの計算の仕方で美しくないなあと思うことはある。例えば、分数を使った演算は分数のままで表しておけば割り算をしないので誤差はゼロだが、一般的なコンピュータでは途中の計算でどんどん割り算を繰り返してしまうので誤差が生じてしまう。誤差を最小限に抑えるために浮動小数点演算を行うこともできるけど、誤差がゼロになるわけではない。そういう観点から分数演算は美しいと思うし、ソフトウェアの世界は最新の数学の世界に追いついていないところもまだまだあるように思う。

【物理】

組込み機器でセンサーやアクチュエータを使う可能性があるのなら物理学は必ず使う。自然界で起こる現象を物理法則で表して、その法則をもとにセンサーやアクチュエータを動かすことになるからだ。

【生物】

生物はどんな組込みソフトの分野に進むのかによってはとても重要な学問となる。あんまり詳しくはいえないけど、自分の仕事では生物学はとても重要だし、生物学が一番好きだったから今の仕事を選んだとも言える。なぜ、生物が好きだったかというと、それは自分自身の体の中で起こっていることが説明されていたからだ。そこには内なる宇宙が広がっていて、信じられないような精巧なメカニズムで生命を維持する活動が行われている。植物は地球上で光合成により最も効率よく光のエネルギーを化学エネルギーに変換し、二酸化炭素から酸素を作りだし、夜は夜で呼吸によりエネルギーを作れる。

その頃は勉強しなければいけないからではなくて、おもしろいから教科書や参考書を何度も読み直したし、25年以上たっても DNAの情報からミトコンドリアがタンパク質を作り出すしくみなんかは覚えている。

【地理・歴史】

地理や歴史もソフトウェア開発には役に立たないと思うだろう。確かに、ソフトウェアエンジニアには必須の教科ではないかもしれない。でも、最初に書いた人生80年のことを思い出して欲しい。

人生80年の中で、必ずしも仕事の関係だけではなく日本国内のいろいろな地域の人、または海外の人と交流することはある。そのときに大事なのは、その人の地域のことについてある程度知っていることと、さらに大事なのは自分の地域や日本のことについて説明できるということだ。

海外の若者は自分の国のことを説明することがうまいのに、日本人は日本のことをうまく説明できないと聞く。そういう場面に慣れていないのかもしれないが、日本人として誇りのようなものを持つことがピンとこない、そんなことをしなくても普通に暮らしていけるからだろう。でも、今後商品作りは間違いなく世界が市場になる。大田区の町工場でロケットの先端部分が作られていることからも分かるように、世界のどこの人々から部品を入手し、どの国の人々へ商品を届けることになるのかはわからない。

ソフトウェアエンジニアはそんなことを知らなくてもいいかと言えば、知っていていろいろな国のいろいろな業種の人々とコミュニケート出来るようになっていた方が当然のことながら自分の器が大きくなる。

海外のエンジニアと親交を深めることで飛躍的にスキルがアップすることもあるだろう。

【問題解決能力】

学校の授業で教えるようなものではなく、社会人になると必要になる能力、それが問題解決能力だ。簡単に言うと、学園祭でバンドをやりたい、メンバーを募ってライブを盛り上げたいと思い、幾多の障害を乗り越えながら成功させるといった経験を積むことでこの能力は高まっていく。

何か作りたいものがあって、いろいろな情報源や道具を使いながら自分の力だけで完成させるというのも問題解決能力を高めることにつながる。

与えられた問題をひたすら解いていい点数を取ることでは、決して身につかない。くわしくはこちらの記事を読んでもらいたい。

【放課後】

さて、組込みソフトエンジニアとしての道を進みたいと考えた場合、大きな分岐点があると思う。それはプログラミングすること＝ソフトウェアを作ることが好きなのか、それとも何か特定の分野のことが好きで、その分野の中でソフトウェアエンジニアになりたいのかという選択肢だ。

前者の仕事をする一つの例としてサプライヤーと呼ばれるソフトウェアの受託開発会社がある。ソフトウェアの開発を請け負って、ソフトウェアをクライアントとなる商品開発メーカーなどに納めるような場合。また、技術者の派遣会社に入って、ソフトウェア技術者としていろいろな会社に派遣される仕事に就くこともある。

非常に規模の大きい会社でどんな分野の商品を作ることになるか分からないけれど、例えばソフトウェアエンジニアとしてのスペシャリティを活かして商品作りに関わる人もいる。

一方で、車好きな人、鉄道が好きな人、宇宙ロケットが好きな人、音楽が好きな人がそれらの分野の会社に入って、その分野の商品を作り上げる過程において組込みソフトエンジニアとして働くということもある。

自分はSESSAMEのメンバーでTEACの國方さんという人を知っているが、TEACは自分の中では音響機器（特に録音機器）の会社で、國方さんは音楽が好きな組込みソフトエンジニアだ。SESSAMEではバンドを組んだり、技術者の教育教材を作るためのセミナーで講演者の音声を自分が開発した機材を使って録音したり、後で聞きやすいように編集したりしている。

ようするにある分野に強い興味があって、その分野において組込みソフトエンジニアとして働きたいのなら、当然のことながらその分野のことは徹底的に詳しくないとよい製品を作ることはできない。

音楽機材を作る仕事がしたいのなら音楽のことを知らないといけないし、自動車作るのなら自動車のしくみ、鉄道の仕事するのなら鉄道の知識といった具合だ。

これは、どっちかというと勉強しなければいけないことではなくて、今君が何に興味を持っていて人から言われなくても調べてみたい、知りたいと思うことは何かということだ。

ちなみに、現時点で興味があるのはソフトウェアや組込みソフトウェアであり、後から関心の強い分野が出てくる、もしくは、その仕事に就いた後からその分野が好きになるということもあるので、今すぐに何が好きか決めろということではない。

だから、教科別の最後のアドバイスはあまり範囲を狭めるのは得策ではなく、若いうちは興味があると思ったら飽きるまで徹底的に突っ込んで満足いくところまでやってみるという経験を重ねておくことが大事だということを言いたい。

そうなると、学校の授業も大事だし、それ以上に放課後に何をするのかということも大事になる。SESSAMEのメンバーが仕事を持ちながら、プライベートな時間に活動しているのと似たような話で、一見関係ないような活動でも、実はそれぞれが相乗効果になっていることも少なくない。

全部精一杯頑張れというような内容になってしまったけれど、まあ、いろいろチャレンジしてみることだね。組込みはやってみないことには楽しさはわからない、これは間違いないと思うよ。今の時期は「クリエイティブで楽しい」「クリエイティブでおもしろい」という経験をたくさん積み重ねることがもっとも大事だと思う。小さい楽しい、おもしろいを経験すると、より大きな楽しい、おもしろいを経験したくなる。そうなると技術的な壁が現れるけれど、最初に楽しい、おもしろいという体験を持っていると、一時期辛くてもその壁を意欲をもって乗り越えることができるんだ。

そのことを学生のうちに経験しておけば、その経験は間違いなく社会人になったときに役に立つことは保証します。

組込みソフトってなに？（高校生の質問から）つづき

匿名の高校生さんから追加情報をもらった。

3 コメント:

匿名 さんのコメント...

すみません、初めてのコメントです。実は私、高校生なんですが、組込みソフトに興味を持っています。今、私たちの生活の中で(身近なところ)よく使われている組込みソフトってなんですか。答えてくれるならすごくうれしいです。お願いします。

sakai さんのコメント...

組込みソフトウェア工房の管理人です。

たぶん一度では答えられないので何度かやりとりしましょう。

「組込みソフトとは何か？」これに答えるにあたって一番の大事なのは高校生の君がなぜそれを知りたいと思ったのか・・・これが問題です。

1. 学校の授業で「組込みソフト」の話がでてきたから
2. 何かおもしろそうな感じがするのでどんなものか知りたいから
3. 進路について組込みソフトの仕事につくことも考えているから
4. 親が組込みソフトの仕事をしているのだけれど教えてくれないから
5. その他の理由

この中のどれ？　例えば、1とか2なら組込みソフトでワクワクするイベントや教材を紹介するし、3や4ならどんなところが楽しいのか、どんなところが大変なのかを中心に答えを考えます。

こんな日記風の説明もありますが、もう少し情報をください。

匿名 さんのコメント...

※組込みソフトってなに？（高校生の質問から）を読んで

ありがとうございます。わかりやすかったところもありますし、少しわかりにくいところもありました。私は元々ソフトウェアに興味を持っていて、将来 ソフトウェアに関する仕事につきたいと考えています。その中でも、特に組込みソフトに強い関心を持っています。ってことは、2. 3.ですね(笑)。ぜひ、組込みソフトについていろんな話を聞かせてください。

もしも、君が組込みソフトに興味を持っていて、将来組込みソフトの仕事につきたいと思っているのなら、おすすめのアプローチは『習うより慣れろ！』作戦だ。

まずは昔話から

実は組込みソフトは社会人になってからでしか始められないかというと、今はそうではない。30年前は高校生が組込みソフトをやってみたいと思っても難しかったね。

実 際、自分が大学生のとき日本で初めて個人でも使えるパーソナルコンピュータPC-8001がNECから発売された。もともと外国製では Appleのコンピュータがあったけど何十万円もしてとても手が出なかった。PC-8001も高かったので結局は買えず、その弟ぶんのパソコン PC-6001が出たとき7万円くらいで買った。これは家庭にあるテレビにつないで画面を見るタイプのパソコンでプログラムはなんとこれも自分が持ってい るテープレコーダに音声情報として録音していたんだ。

このときはパソコン雑誌に載っているプログラムのリストをキーボードから打ち込んで は実際に動かして遊んでいた。でも、打ち込むプログラムがだんだん多くなってくるとプログラムリストを紙に打ち出したくなる。でもプリンタが高い。モノク ロでしかも一行ずつ文字しか打てないインクリボン式のプリンタがパソコンと同じく7万円もしたんだよ。でも、どうしても欲しかったからアルバイトしてお金貯めて買ったなあ。

パソコンの価格だけは時がたつにつれて安くなるので驚きだね。いまや7万円で高性能なディスプレイ付きのパソコンが買えるし、カラーのインクジェットプリンタは1万円台で買える。（消耗品のインクで儲けているからプリンタはほとんどタダ同然でもいいんだ）

だから、君はすでにパソコンを持っているという前提で話しをするよ。

君 がパソコンを持っていてインターネットに接続する環境があるのなら、プログラムを作ってみる方法はたくさんある。今はインターネットで世界中がつながったことで、無償でソフトウェア開発の環境を提供してくれる個人や企業もたくさんあるし、わからないことがあったら親切に教えてくれるしくみもそろっている。

だけど、君が組込みソフトに興味を持っているのなら、おすすめのコースは別にある。

前回の記事に書いたように組込みソフトはセンサーとアクチュエータがあると格段におもしろい。センサーとアクチュエータを積んだ組込み機器に自分が作ったプログラムを載せて、いろいろ試してみると自分が作ったプログラムの通りに組込み機器が動くから楽しい。

実は、こんな教材を高校生向けに考えてプロデュースしている二上 貴夫というおじさんがいるんだ。この人はとてもおもしろい人で、サラリーマンとして仕事を持っていながら組込みソフトの楽しさを多くの人に伝えることができるのなら寝食を忘れてがんばっちゃう人なんだ。

科学の楽しさをわかりやすく子供達に伝える活動をしている米村でんじろうさんは知っていると思うけど、二上 さんは組込みソフトの世界では有名な組込みソフトの楽しさを伝える伝道師なんだよ。

その二上さんが最近開発した飛行船をプログラムで制御するキット「マジカルスプーン」というのがある。

現在はマジカルスプーンシミュレータが約7千円で通販で買える。二上さんは今マジカルスプーンリアルを開発していてもうしばらくすると買えるようになるよ。

マジカルスプーンはスプーンをたたいて出る超音波で命令コードを作り（＝プログラム）をセンサーでこの超音波を拾って飛行船を制御するんだ。なんだか、わくわくするでしょ。

簡単な説明は、自分も所属している組込みソフトの教育を考えるコミュニティSESSAMEのこのページを見て欲しい。

また、二上さんに負けず劣らず、組込みソフトの楽しさを伝えるのにがんばっちゃっているおじさん、おばさん（おねえさんと言わないと怒られるかも）達は何人もいて、この中の舘 伸幸さんたちがマジカルスプーンのことをWEB上で連載記事として書いているのでこれも読んでみて欲しい。

最後にもう一つのおすすめは、もし君が関東近県に住んでいるのなら、レゴで作った車にプログラムを載せて動かすETロボコンのチャンピオンシップ大会がパシフィコ横浜で11月19日～21日のどこかであるのでこれを見てみたらどうかと思う。チャンピオンシップ大会は平日になるので学校の先生に正直に話しをして休みをもらって見学しに行こう。組込みソフトに夢中になっている学生や社会人達の情熱が伝わってくると思うよ。

以上、これが組込みソフトを知る『習うより慣れろ作戦』の全貌です。また、何かもっと聞きたいことがあったらコメントをください。このやり取りのことは仲間のおじさん達にも伝えておくので後でアドバイスをもらっておきます。

そ れと、『習うより慣れろ作戦』で組込みソフトの楽しさを満喫したら、次は職業として組込みソフトエンジニアになることについて真剣に考えてみて欲しい。 仕事で組込みソフトを作るのは自分が楽しければいいってもんじゃないから、時には辛いことも乗り越えなければいけない技術的な壁もある。でも、自分が作っ た組込みソフトが組込み機器に搭載されお客さんに満足してもらえることが分かると、喜びや辛さを繰り返しながら、それらの壁を乗り越えることができる。だから、まずは何が楽しいのか、おもしろいのかを実感した上で、職業としての組込みソフトと組込みソフトエンジニアについて考えて欲しいと思う。
　

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

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

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

【前提条件】

・複数人の新人を教育する場合に有効。（できれば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）で見てわかる 電子回路の「しくみ」と「基本」』の著者 小峯 龍男先生に感謝したい。

ぜひ、お試しあれ。