エンジニアに投資しない、投資できない、投資する必要があると考えない組織はそこら中にある。技術者への投資がどのように組織にフィードバックされるのか、人材を育てることに金や労力を使わないと組織がどのようにやせ細ってしまうのかイメージできない人に技術者への投資を提案するとそれにかけた費用に対する効果を説明せよと言われる。そこで「分かってないな」と思うのは当然だが、だからといってエンジニアへの投資をあきらめてはいけない。
ソフトウェアエンジニアは100%知識労働者である。「プログラムコードを何行書いてなんぼ」などと考えていると、すぐに優秀なコンパイラやツールに仕事を奪われてしまう。新しく入っている若い世代のソフトウェアエンジニアが持っていないスキルを常に身につけていかなければいつの日か組織からいらないと言われる日がくる。
組織の中で誰からも計画的なスキルアップの道筋を提示されないエンジニアは辛いが、心配しなくてもいい。ほとんどの技術者がそんなものだ。小・中・高・大おまけに塾では手取足取り何を勉強すればいいのか、次は何に取り組めばいいのか、四六時中先生や親がかまってくれたが、社会人になるとそのようなケアは激減する。そのような環境に計16年もいれは、社会人になっても新人教育のアンケートで「もっと教育を提供してください」「まだまだ教育が足りません」と書いてくるのもうなづける。新入社員研修が終われば、ほとんどの組織では後はOJTで何とかしろと突き放される。ソフトウェアは周りから何やっているのか見えないから、自分で「ここが分かりません」とか「ここはどうやったらいいのでしょう」などと積極的に聞いていかないと、「どれどれ苦労しているようだね」と誰かが声をかけてくれる確率は低い。そして、どんなに未熟な技術者でも何百回も試行錯誤でプログラムをいじくり回していればいずれ動くようになる。実は、それが一番怖い。中身ぐちゃぐちゃで、すべてのテストケースを検証しておらず、爆弾入りのプログラムがひっそりとソフトウェアシステムの中にビルトインされてしまうのだ。
新人の時期を過ぎればソフトウェアエンジニアは教育という側面から見れば孤独だ。それまでの人生と比べてその突き放され感にショックを受ける者もいるだろう。
技術者教育を計画できない、実施できない自転車操業の組織にいて、それは自分が悪いのではなく組織が悪いのだと考えるのは簡単だが、残念ながらそのままほおっておいても何も変わらない。学校や塾のように成績が悪くなると家庭教師を付けてくれたり、「もっと勉強しろ」と尻を叩いてはくれない。ETSSというスキルのものさしでエンジニアのレベルを計測し、それによって弱いところをトレーニングするという取り組みは始まっているが、それができるのはエンジニアに投資できる組織であり、今回と前回の記事の対象外としている。（これを実行するには人・モノ・金がいるから大企業で儲かっていないと難しい）
技術者に投資しない、投資できない組織はたくさんある。そのような組織の中で技術者が何もしないでいると、ソフトウェアに依存する組織の業績はじりじりと下がり技術者に過度な負担がかかるようになる。このような状況でも組織が生きながらえていられるのは次のような原因があると考えられる。
- ソフトウェアエンジニアの需要が供給を上回っている。（不景気な今もそうだろうか？）
- その組織、そのプロジェクト、その技術者しか知らない、対応できないドメイン知識を持っているから切られる心配がない。（組込みの世界ではよくある話し）
- 過度な負担（例えば残業月100時間以上とか）に対して技術者がまだ耐えられるレベルにある。
1と3は放っておけばいつかは破綻するときが来る。問題は2だ。2は実際かなりのアドバンテージであり、曖昧な仕様でしか仕事を出せない組織では特に特定の技術者に蓄積されたドメイン知識や経験は重要であり、このような人に頼った製品開発が行われことは多い。しかしながら、そのアドバンテージは永遠には続かない。
製品に使用されるハードウェアデバイスの使いこなし方や商品にまつわるドメイン知識だけで生きながらえているソフトウェアエンジニアは、大規模ソフトウェアシステムを効率的かつ品質高く開発する技術を持ち合わせていないから、いつの日か破綻するときがくる。ドメイン知識と試行錯誤のアプローチで開発できるソフトウェアシステムの規模はだいたい決まっている。自分の経験では実行コード行数で30万行を超えてくると、何かしらのソフトウェアエンジニアリングの技術を使わないと品質を確保できなくなってくる。
よって、どのようなソフトウェアを作っていたとしても、いずれはソフトウェアに関する設計、検証の技術は身につけなければソフトウェアエンジニアに明日はない。日本で今若い人たちがソフトウェア開発技術者に魅力を感じられないのは、自転車操業の組織で試行錯誤のアプローチでしか仕事をしておらずどんどん疲弊していく技術者の噂を耳にするからだろう。
前置きが長くたっぷりと危機感をあおってしまったので、ここからはエンジニアに投資しない組織いて、スキルアップの方策を組織に期待できない場合、どうやって自己投資すればいいのかを考えていきたい。
多くの組織がこれ（要するに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の方法はほとんどお金を使わない自己投資の方法だが、セミナーに行ったり、組織のお金でコンサルタントを頼むなど、お金をかけることで高付加価値、高効率の自己投資は可能だし、そっちの方が成功する確率は高いと言える。
でも少ない自己投資でスキルアップという効果を得る醍醐味を一度味わうことができると、問題解決のスキルはどんどん上がる。問題解決のスキルが上がると、自分の仕事を効率化したり、品質を高めたり、より評価の高い組織に移籍するなどいろいろな選択肢を選べるようになる。
自分に取ってどんな自己投資が効果的かこれを期に考えてみて欲しい。
