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

いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。

【CHAPTER1 ムリを承知で任せる より 引用】

そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。

部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。

【引用終わり】

耳が痛い。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。

小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。

• 部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。
• 部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。
• 部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。
• 部下に教えられるほどにノウハウが整理体系化されていない。
• 口べたであり、うまく部下に教えることができない。
• 部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。
• 仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。
• 部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。
• 上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。
• 部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。
• 部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。

まさに図星だ。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか？」という恐怖が強い。しかし、そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。

「自分がいなくなったら？」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。

【CHAPTER2 ムリをしなければ脳の筋肉はつかない　より引用】

「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。なぜ、やりがいがないの？　と聞くと返ってくる答えは2種類に大別される。

1つ目は「今の仕事が自分には向いていない」というものだ。例えば営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。

2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。だからあきらめて転職する、と言うのだ。

僕はその2つを聞くたびにこう思う。

「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。

「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。決して壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。しかし、先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。

【引用終わり】

部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。

【CHAPTER3 部下が失敗する「権利」を奪うな　より引用】

失敗が喉の渇きを引き起こす

なぜ人は「任される」と育つのだろうか。

もちろん答えは一つではない。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。

しかし、それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。つまり「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。つまりは、うまくやるための方法という「水」を求めて「喉が渇く」のだ。

そして様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。やがてうまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。そうして全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。

【引用終わり】

この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。また、ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。

さらに、大規模プロジェクトでは自分の作ったソフトウェアに失敗（＝バグ）があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。

自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。

「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。

失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。

コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。もっと、この本を読み進める必要がありそうだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクトマネージャ、プロダクトマネージャの立場からすると、こういうエンジニアばかりいるととてもやりにくい。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代中盤を過ぎるようになってきたら、若いエンジニアをどう育てるべきかということをいつも考えておかなければいけないと思う。

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

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

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

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

P.S.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【おまけの考察】

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

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

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

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