サブプライム問題、耐震偽装、防衛利権……私たちの身のまわりには、多くのリスクが存在する。それはエンジニアも同じ。商品開発から会社での生活、さらには転職まで、あらゆる活動にリスクは付きモノ。そんなリスクをかわし、しなやかに世の中を駆け抜けるための方策を探る。 （取材・文／井元康一郎　総研スタッフ／関洋子）作成日：08.01.08

Ｔｅｃｈスナイパー・井元康一郎 鹿児島県出身、年齢不詳。経済誌や自動車誌などで、自動車、宇宙、航空……などを得意とする技術＆マニア系ジャーナリスト。技術をこよなく愛すがゆえに、Ｔｅｃｈスナイパーに。心優しき音楽家という別の顔ももつ。

「ロールアウト直前に設計ミスが見つかって対処できない!!」「自分が身につけてきたスキルがオールド化して役に立たなくなった!!」「開発に追われているうちに彼女にフラれた!!」――世の中のありとあらゆることには、さまざまなリスクが存在する。何も企業経営や政治・外交戦略といったマクロ的なものだけではない。エンジニアのごく普通の日常の中でも、身のまわりはリスクだらけと言っていい。リスクを想定し、それに対する備えをしておかないと、危機に見舞われて泣きながら右往左往するハメにも……。果たしてエンジニアはどのようなリスクマネジメントを実行しているのか。これまでの人生において無数のトラブルに見舞われ、リスクコントロール、リスクマネジメントの必要性をイヤというほど痛感させられてきたＴｅｃｈスナイパーが、エンジニアのリスクマネジメントの実態にロックオン!!

仕事、プライベートともさまざまなリスクに囲まれているエンジニア。当然いらない苦労や身の破滅を招きたくはないとあって、多くのエンジニアがそれなりにリスクコントロールを行っている。「プログラムなど常に見ていないと忘れたりするので、スキルを保つためにも、家でもスキルアップを図る」「常にメモをとって、コピー、pdfファイルなどで証拠を残す」「社内キーマンと考えられる人とは情報交換や連絡を日常からとり、アクシデントに見舞われたときも助けを得たり協力できる体制をとっている」「常に周りに情報を発信し、間違った方向に進んでいないことを、確認しながら仕事を進める」……。 　が、それでもリスクのもたらす厄災に見舞われてしまうのが人生というモノ。果たしてリスクの影響を最小限にとどめ、いいエンジニアライフを送るためにはどうしたらいいのだろうか。リスクコントロールの極意をリスクコンサルタントの草分けといわれる牛場靖彦氏に聞いた。

		仕事や日常生活を何となく平和に過ごしている私たちだが、一寸先は闇。いつどのようなリスクに見舞われるか、わかったものではない。果たして、どのようにリスクマネジメントを行えば、より良い人生が手に入るのだろうか。 　 リスクコンサルタントの草分け的存在として知られる牛場氏は、意外なことに、リスクを恐れるべきではないと語る。 「ビジネスマンの人生にはおおむね3つの道があります。第1は今いる会社に定年まで居続け、そこで功績を挙げて出世するという道、第2は自分にとってよりよい道を探すため、転職や社内でのジョブチェンジを模索する道、第3は独立して一国一城の主となる道です。そのいずれにもリスクはある。安全な道などないんですよ」 　安定志向で、会社で定年まで勤めようとしても、途中で業績が悪くなったり倒産するかもしれない。転職したらしたで、新しい職場が肌に合わなかったりイジメに遭ったりする可能性もある。独立して成功すれば利益は自分の総取りだが、失敗すれば借金の山ができてしまう。 「それらのリスクをどう最小化するかですが、その判断の決め手となるのは教養、知恵なんです。これはとても重要なことですが、知識と知恵は違います。今はインターネットが発達していることもあって、知識なんか誰でもいくらでも手に入る。でも、そんなものは本当の意味では役に立たない。自分でいろいろと試して失敗して痛い目に遭って、そこからはい上がって初めて知識が知恵になる。知識を実際の生活やビジネスに応用できる知恵をもち、その知恵の蓄積である教養をもつこと。これがリスクマネジメントには大切なんです」（牛場氏）		牛場靖彦氏 1960年慶應義塾大卒業後、三菱商事に入社。88年独立し、牛島事務所を設立し、現在に至る。ヘルスケアアドバイザー、ノンフィクション作家、エッセイスト、モデル、大相撲解説者、映画・ミュージカルプレイ・モダンジャズ解説者など多数の肩書をもつ。本業であるリスクマネジメントについては、レオナルド・ダ・ヴィンチ風に「少々たしなむ程度」という。
		牛場氏は昔から、ビジネスマンを2つのタイプに区分けしている。さもしく、活気がなく、いつも利己的にしか振る舞うことしか考えない「ZOMBIE（ゾンビ）族」と、自分はもちろん世の中にとってもプラスになるような夢をもつ“利他的利己主義”者「ALIVE（アライブ）族」である（ゾンビ族、アライブ族は表を参照）。 「会社にいると、それこそゾンビみたいな上司や同僚がたくさんいる。これは会社や自分が儲かりさえすればあとはどうでもいいという人たち。ゾンビにも階級があり、最上位に意図的に利己主義で人をたぶらかすゾンビマスターがいて、その手下に悪知恵を働かせるゾンビゼネラル（参謀）がいる。そんな彼らの下で夢をもたずに『俺の人生はこの程度なんだ』とあきらめてしまうと、その人もゾンビになってしまう。それではダメ。ゾンビに立ち向かう、他人のために良く、自分にはさらに良くという“利他的利己主義”で行動できるアライブ族を目指すべきです」 　人生における最大のリスクは、何のために生きたのかわからないような過ごし方をして、そのことを後悔しながら虚無的に死ぬこと。転職・独立をする、しないにかかわらず、生き生きと人生を過ごすためには、利他的利己主義を実現させ、アライブ族になれと牛場氏は言うのである。 「みんな本当は、生き生きと生きたいはずです。そうするためには、先にも述べたように知恵、教養を身につける努力をすべきです。腕力では1人かせいぜい数人を相手にすることしかできないが、知恵をもってすれば1000人にだって勝てる。会社や上司は別に神様じゃないんだからみだりに尊敬をしてはダメ。自分はどう生きるかというスタンスをきちんと決めて、より良く生きることを目指してほしいですね」（牛場氏）

牛場氏が語った社会人としてのリスクに加え、開発業務、社内の上司・部下や同僚との人間関係、キャリアアップなどエンジニアの身のまわりには、実に多様なリスクがひしめいている。エンジニアは実際問題として、どのようなリスクを負い、どのような対処を行っているのだろうか。Ｔｅｃｈ総研は読者アンケートを実施し、リスクのパターンや対処法の実態を探った。

職場の人間関係についてのトラブルで圧倒的多数を占めるのは、やはり上司、部下の関係。上司の無理解に憤る若手も多いが、部下のいい加減な仕事ぶりに悩まされている上司もそれに負けないくらい多い。エンジニア人生において、人間関係のリスクマネジメントは極めて重要だ。 　人間関係を司るのは、基本的に相互理解だ。この手のトラブルの背景をよく調べてみると、若手が大した実績でもないのに自信過剰になっていたり、ベテランがやたらと上司風を吹かせ、若手のやる気をみすみすそいだり、不要な摩擦を生んでしまったりする。 　どんなにイヤミな上司でも、あるいは生意気な部下でも、普段から相手を尊重する姿勢を見せていれば、いざというときにあしざまに言われることはない。人間関係がちょっとね……と思っている人は、普段から相手とよく話をするようにしてみるのも手だ。人間関係が円滑になれば、職場の雰囲気も180度違って見えることウケアイである。

ちゃんと報告しているのに、ちょっとした手違いで1点報告が少し遅れただけで、課長は激怒。顧客と合意ずみのプロジェクトの進行を妨げられた。 開発についてウソの進捗報告を部下から受け、それを信じた結果スケジュールに狂いが生じ、クレームも発生した。 話のわかるさらに上の役職の上司に相談して、課長の顔を立てながら、うまく事を収めてもらった。 （回路・システム設計、36歳） 回避策として、その後は必ず自分の目で結果（記録）を確認するようにした。 （Web開発、41歳） すべてを仕切りたがる上司は意外に多いもの。性格を読んで普段から十分ケアしておくべし。 同種の回答はほかにもいくつも見られた。部下が報告しやすいような人間関係をつくるのも上司の務めかも。

毎日のようにどうでもいいことでネチネチと愚痴る上司。そのせいで時間は止まり、リカバリする時間もなく、毎回、開発が遅れる。 同じ部署の女性の先輩は日々あれこれとやたら命令する。初めは我慢していたが、4カ月もたつと精神的に参り、軽いうつ病のようになってしまった。 あまりに度が過ぎていたので、社内のポータルサイトに自分の名前とその人物の名前を書いて糾弾した。 （社内システム開発、32歳） さらに年上上司に相談し、その女性と一緒に仕事をしないですむように、自分の仕事のテーマを変えてもらった。 （素材、29歳） 糾弾で一応愚痴は止まったようだが、後のことを考えるとなるべく穏便な手段で対処しよう。 異性の上司、部下は思わぬところであつれきが生じることも。周囲への速やかな相談が幸運の鍵。

開発プロジェクトにおいて、最初に想定したモノが何のトラブルもなくロールアウトされるというのは理想だが、現実は仕様や開発スケジュールなど、多くの点について変更に次ぐ変更のオンパレードだったりする。変更は開発者にとって、まさしくリスクの火種だ。アンケートを見ても、ソフトウェア、ハードウェアともに、仕様変更がもとでプロジェクト全体に影響が及んだというケースが目立つ。 　リスクマネジメントの観点からは、開発前にあらかじめどういう事態が想定されるかというシミュレーションを行うとともに、途中での仕様変更をどれだけ受け入れやすくするかという、柔軟性のある開発体制を工夫することが求められよう。また、ニーズと合わない開発になっていることが自覚されながらなかなか修正できないケースも案外目立つ。ここについても対策が求められよう。

製品と同じような機能だと思い込み、要求も仕様書も確認せず製品を開発した。できた製品はまったくうまく動かなかった。 開発段階では旧型仕様のユーザーが多く、旧型で開発を進めていたが、市場での新型仕様の浸透が想像以上に速く、ニーズに合わなくなった。 最初の仕様打ち合わせからやり直して納品。既に納品していたものはすべて回収して、自分で営業して販売した。 （サービスエンジニア、40歳） 開発途中で方向性を迅速に変えることができず、結局開発が完了した後に、急遽仕様を変更した。 （機械・機構設計、41歳） 現場視察はモノづくりの基本だが、慣れだけでは相手のニーズをくみ取れない。担当者との直接対話を。 市場ニーズと製品開発のかい離は珍しくない。臨機応変な開発のための方法論をもっているかどうかが分かれ目に。

クライアントからの矢継ぎ早の仕様変更で、内部設計と表面の設計にそごが発生。どんどん性能が落ちていった。 外部から派遣されてきた開発スタッフが、経歴詐称とまではいえないものの、スキル不足で予定していた開発が大幅に遅れた。 ニーズの把握や仕様の変更について、営業任せにしていたのがよくなかった。最後は上級SEが客先に直接出向いて説明し、相手も納得して解決した。 （Web・オープン系システム開発、35歳） あらかじめ状況ヒアリングの回数を増やすなどして、管理を注意深く行った。それでもまかないきれない部分は、開発期間を延期してカバーした。 （オープン系システム開発、35歳） システム開発では仕様変更は日常茶飯事だが、技術的に限度があるという認識を顧客に共有してもらおう。 スケジュールを左右する協力会社の情報収集は大事。日ごろから社内で共有する仕組みをつくるなどしよう。

アンケート結果では、会社の業務にかかわっているうちに全体的な技術トレンドがわからなくなって道の選択を誤った、ひとつの技術にこだわり続けているうちにいつの間にか時代の流れから取り残されたといった“忙殺型”と、ついつい勉強を怠ってしまってスキルを身につける機を逸したという“怠慢型”の2つに大きく分かれた。 　技術は生き物であり、常に変化していくものだ。自分がかかわっているテクノロジーが、それを土台に大きく発展していくタイプのものなのか、あるとき別の優れたモノに取って代わられるようなタイプのものなのかといった将来展望を冷静に認識しておく必要があろう。社内や業界内の評価だけでなく、別分野のエンジニアと交流して意見を求めるなど、積極的な情報収集を行うことが、より正確な情報を得るためのコツだろう。

痛恨の判断ミスは、電子系からWeb系プログラマに転向したこと。当時は旬の仕事だったが、今は将来が不安な仕事のひとつになってしまっている。 同じ技術ばかりに携わっていたので幅が狭く、技術的な深みのない経験ばかりが身につき、つぶしの利かない技術者となってしまった。 判断ミスをしないためには、技術、人脈ともに、常にアンテナを最大限に広げておくこと。 （Web系システム開発、31歳） 今はやりたいことをやるために経験を積んでいる。ひとつのことにこだわることは大切だが、同時に全体を見て、事を進めるように心がけている。 （機械・機構設計、38歳） 技術トレンドの読みはエンジニアにとって死活問題。流行で判断せず、将来の技術展望などを最大限収集したい。 ひとつのことに熱中して、自分のスキルの幅を狭めてしまうのは、エンジニアが陥りがちなだけに気をつけよう。

現場のプロジェクト進行に熱中していたら、社長をはじめ幹部の横領や乱出費に気づかず会社が倒産した。 会社から言われた仕事ばかりしていたら結局、トラブル対応ばかりの仕事になってしまい、運用、保守に関して通常の業務に精通する機会を失ってしまった。 どんな局面にも対処できるよう、常に逃げ道をつくっておくべき。 （サービスエンジニア、37歳） 上司に交渉し、自分の目標とする道に進めるような仕事をアサインしてもらっている。 （運用・保守、42歳） 会社の業績が悪化したり倒産したりということは珍しくない。経営状態にも注意を払うことは大事です。 便利屋にならないためにも、キャリアパスを思い描き、自分の希望を会社にきちんと伝えよう。

エンジニアの日々の仕事においては、上記以外にも、実に多種多様なリスクが存在する。 　例えば、足の引っ張り合いに近いいざこざ。「懸案事項に関して間違った感情的な指示を出されたが、あえて指示に従った（素材、39歳）」「上司が学歴を気にする。配置換えをしてもらった（ファームウェア系システム開発、35歳）」など。いざこざが起こった場合、後のことを考えて決して感情的になるべきでないことはいうまでもない。 　上司の仕事がいい加減で、仕事のミスが誘発されたり、そのとばっちりを食らったりというリスクもある。「業務内容を理解していない上司が、新人に安易な指示をしてプログラムが消失、リカバリで私が徹夜する羽目になった。新人はショックを受けてしまい、フォローするのが大変だった（Web系システム開発、33歳）」「顧客の追加要件を安請け合いされ、自分の業務が増えてしまった。結局、休日出勤などで対応し解決した（Web系システム開発、35歳）」など。自分の仕事さえちゃんとやっていればいいというのではなく、周辺の仕事についてもきちんと視野に入れておきたいものだ。 　モノづくり面でのリスクもさまざま。開発過程におけるリスクだけでなく、いいモノを作っても、「新しく開発し今までにない機能付加、性能アップをして発売したが、通常の製品との見栄えが違うため受け入れが悪かった。機能、性能だけではなく、見栄えも重要だと感じた（生産技術、32歳）」など、消費者のちょっとした気分や発売時の社会的雰囲気でも売れ行きが左右されてしまうといったことも多々ある。開発、企画、営業といった業務が縦割りになっていると、トレンドを読むための情報交換もままならなかったりする。組織改正を要望するなどの自衛策が求められるところだ。

プライベート面でのエンジニア的トラブルとして圧倒的に多かったのは、家族や恋人との人間関係。商品開発が遅れてリカバーに追われたり、自分の研究開発のテーマが面白くて没頭したりといった理由で残業続きになるにつれて、付き合う相手との関係悪化というリスクは飛躍的に増大する。 　仕事のストレスはとくに要注意。「仕事のイライラが原因で彼女とけんかになった」「仕事で機嫌が悪く、彼女に八つ当たりした」など、破局の直接原因につながりかねないケースが多数見受けられた。休日にはきちんとストレス発散をしておくべし。「仕事が忙しくて長期間連絡しなかったら相手がキレた」ということも。もっとも「浮気がばれた」「不倫で慰謝料を請求されそうに」などは自己責任だろう。 　たとえどんなに忙しくとも自分の時間を確保し、将来設計を立てて行動することが、人間関係をはじめプライベート面におけるリスクマネジメント上、極めて大切だ。

彼の誕生日だというのに、急な残業でデートができなかったため、すっかり彼の機嫌を損ねてしまった。 ある女性と一緒にいたとき、同時期に付き合っていた別の女性の名前でその女性を呼んでしまったことがあり、彼女に問い詰められた。 その場は電話でひたすら謝り、翌週に埋め合わせの超豪華デートをした。 （ネットワーク、34歳） 結局、元カノということで押し通し、半信半疑ながらも彼女の怒りは収まった。 （研究、特許、33歳） これはエンジニアにとって、よく起こる問題。恋人の機嫌をいつでも直すような台詞は用意しておきたい。 このケースの場合はうまく収まったようだが、リスク管理的には失格。本音が出やすいエンジニアは要注意である。

多忙で情報収集もママならないのに、株式投資をし、大損。結果、妻と大げんかに。 ある女性のことを好きになりすぎて心が見えなくなり、彼女の一挙手一投足が気になり、疑心暗鬼に。また仕事にも身が入らず、結局振られた。 離婚まで考えたが、最後にはなんとか謝り倒して離婚を回避した。 （パッケージソフト開発、33歳） しばらくの間、忘れられなかったが、いろいろな人と付き合うことでなんとか忘れられた。 （Web系システム開発、40歳） 日々動く投資は、多忙なエンジニアにとってはリスクも大きい。情報収集できる余裕をつくってから取り組もう。 猪突猛進型の多いエンジニアが陥りやすい恋の罠だろう。気をつけたいが、気をつけられないのが恋。仕方ないかも。

日常的にいろいろなリスクに遭遇する私たちは、経験的にリスクに対して萎縮してしまいがちだ。どうせ理解されないから黙って従っておけばいい、無難に業務をこなせばとりあえずその場はしのげる、といった具合だ。が、リスクコンサルタントの牛場氏は、それではリスク回避にならないと一喝する。 　リスクに直面したときになすべきことは何か。嘆いたり逃げ腰になったりすることではなく、そのリスクにどう対処するか、最善の方法を迅速に導き出すことなのだ。そうしてさまざまな経験を積み、知恵をつけることで、リスク回避能力は上がり、またリスクをある程度予測する力もつくことだろう。リスクマネジメントは小手先の逃げの技術ではなく、より良く生きるための能動的な生き方の問題なのである。 　2008年も始まったばかり。より良い1年を過ごすためにも、今一度、リスクマネジメントを根底から見直してみよう。